Part of the fanr feature will be ability to view and query by pod metadata. We actually already have quite a bit of pod metadata, but I'd like to explore standardizing a bit more before we all start posting pods into repositories.

Currently Defined

Summary from the Pods chapter:

• pod.name: name of the pod
• pod.version: Version of the pod
• pod.depends: list of semicolon separated Depend strings
• pod.summary: overview decription for pod
• pod.isScript: was the pod compiled in script mode
• pod.docSrc: should documentation include source code
• pod.docApi: should pod be included in documentation
• pod.native.java: does pad use native Java code
• pod.native.dotnet: does pad use native .NET code
• pod.native.js: does pad use native JavaScript code
• fcode.version: binary format version of the fcode
• build.time: compile time formatted as DateTime
• build.platform: compile env platform formatted as sys::Env.platform
• build.host: compile env host name, see Env.host
• build.user: compile env user name, see Env.user
• build.compiler: compiler pod version

Of course anybody can add their own meta props and they will be accessible by fanr. But I think we probably want to standardize a couple more things.

Organization

I propose that we use "org." props for metadata related to the organization, with two key props:

• org.name: name of the organization
• org.uri: web site URL of the organization

The org.name should be consistently used across pods as the org key with the exact string. The org.name may be used for web repositories for security purposes.

The core Fantom team which is currently Andy and myself will use:

org.name=Fantom
org.uri=http://fantom.org/

Projects

Often many times a project will include multiple pods. For example our sidewalk framework contains half a dozen pods. We will use "proj." prefix for project related pod meta:

• proj.name: name of the project
• proj.uri: web site URL of the project home page

Like org.name, the proj.name will need to be formatted using exact same string across the board so that it can be used as a key.

For all pods developed as part of the Fantom core:

proj.name=Fantom Core
proj.uri=http://fantom.org/

Licensing

We will use "license." prefix for licensing terms of intellectual property:

• license.name: license name
• license.uri: web page with license contract (omit for common ones)

Since we want everybody to use the same strings for their license, I'd like to find a canonical list of names we can use. I've poked around different places and haven't found anything great. Any ideas?

If you have commercially licensed pods the license string should be "Commercial".

Version Control System

The term "vcs." will be used for version control system metadata:

• vcs.name: name of system "Mecurial", "Git", "Subversion"
• vcs.uri: URI of the public repository

Other Ideas?

The ones above seem the ones we should standardize. Plus they provide a logical top-level grouping for new standard or customized props.

Any other ideas for props we should standard?

I think that before standardisation, there should be an exercise to map each key to maven's pom. While I don't love maven, it has done decent work in defining project metadata that Fantom should reuse.

I'd also strongly recommend against having solely "name" values. Anything key that is named "name" is one I would assume that the value is meaningless, whereas you intend to match on it as a key. Please name it "key or "id":

license.key = Apache v2

The name could be kept if desired for human readable stuff:

license.name = The Apache Software License v2 (really great dude!)

(The OSI is the best location for open source licenses. I don't know of a canonical list, but you could try asking JFrog as they have done some license work recently).

You'll need a webpage (and perhaps a RESTful service for IDEs) with standard values.

One final thought. Why isn't the language version itself just another dependency???

While I don't love maven, it has done decent work in defining project metadata

I looked and didn't see much in the way of docs where all this stuff is defined? You have a URL?

The name could be kept if desired for human readable stuff:

What we have been doing is using name to mean programmatic name which is consistent with something like "pod name". For human display strings we use dis. That seems to work well.

One final thought. Why isn't the language version itself just another dependency?

If you mean core Fantom I think you get this with your depend on sys? But am I anot sure I follow...

You might want to reconsider "org." as a prefix. I'm sure the first new person to show up will think, "OH, my domain is fred.com, I'll use com.fred...", by analogy to the whole java "reverse your domain..." thing for packages.

While I might think of "pom.name" as being important, I wouldn't think of "license.name" as anything other than descriptive. I'd strongly recommend something other than "name". BTW, if I saw "dis", I wouldn't know what it was.

Maven POM described at http://maven.apache.org/pom.html

BTW, if I saw "dis", I wouldn't know what it was.

It's a city where all the code is really bad :-)