incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <>
Subject [DISCUSS]Incubator podling mvn pom files...
Date Thu, 22 Feb 2007 10:08:14 GMT

While looking at the Trinidad stuff, I had some thoughts about requirements 
around pom files for Apache stuff and what "requirements" should be imposed.

There are several things in a pom file that could affect how things appear 
when someone takes a dependency on an Apache project.   Thus, we need to make 
sure these things are correct:

1) organization element:  Somewhere up the heirarchy, we need to have:
        <name>The Apache Software Foundation</name>
2) licenses element: Somewhere up the heirarchy, we need to have:
            <name>The Apache Software License, Version 2.0</name>

NOTE:  Both (1) and (2) can be taken care of by having the org.apache:apache:3 
artifact as the parent.    Should that be a requirement?   (Actually, should 
there be an incubator parent that lives in the middle?)

3) <name> Element - I think these should start with "Apache PODLING".  The 
basic reasoning for this is when someone runs a dependency report or similar, 
the name is printed.   We really need to make sure they see the proper Apache 
branded name there.   For example (not to pick on anybody in particular, this 
is just the first of many examples I found), if I depend on commons-logging, 
my report just says:

Commons Logging is a thin adapter allowing configurable bridging to other, 
well known logging systems.

I think we should make sure the proper Apache branding is used.

4) <url> element should be there and point to the proper homepage

5) (optional) <inceptionYear> element filled in.  (remote-resources uses this 
for copyright dates)

The Maven team has been working on creating new tools and such that use all of 
the above information when it's available.   (one example is the 
remote-resources stuff that can create the NOTICE files.   Another example is 
a tool that can check the licenses for all dependencies to make sure they all 
match a certain list of "accepted" ones.)   That said, there are a LOT of 
crappy poms in the repository (*cough*sun jars*cough*) that the tools will 
stumble on, but I think we should make sure all that information is there and 
correct for our stuff.


J. Daniel Kulp
Principal Engineer
P: 781-902-8727    C: 508-380-7194

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message