incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matthias Wessendorf" <>
Subject Re: [DISCUSS]Incubator podling mvn pom files...
Date Thu, 22 Feb 2007 10:30:35 GMT
> 1) organization element:  Somewhere up the heirarchy, we need to have:
>     <organization>
>         <name>The Apache Software Foundation</name>
>         <url></url>
>     </organization>
> 2) licenses element: Somewhere up the heirarchy, we need to have:
>     <licenses>
>         <license>
>             <name>The Apache Software License, Version 2.0</name>
>             <url></url>
>             <distribution>repo</distribution>
>         </license>
>     </licenses>
> 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?)

+1 to a requirement for "org.apache:apache:3" as being the parent.
I think it was already discussed the incubator parent thing. I am fine
w/ the "org.apache:apache:3" artifact.

> 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:


> Logging
> 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

isn't <url> optional ?

> 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.


(I hope the Trinidad stuff isn't that crappy ;))

> Thoughts?
> --
> J. Daniel Kulp
> Principal Engineer
> P: 781-902-8727    C: 508-380-7194
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Matthias Wessendorf

further stuff:
mail: mwessendorf-at-gmail-dot-com

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

View raw message