buildr-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Assaf Arkin" <>
Subject Re: specifying metadata for an artifact
Date Thu, 14 Aug 2008 04:46:38 GMT
On Wed, Aug 13, 2008 at 2:35 PM, Alex Boisvert <> wrote:
> On Wed, Aug 13, 2008 at 1:16 PM, Assaf Arkin <> wrote:
>> I think the metadata belongs in the file (OSGi), not something
>> separate (Maven), and should propagate through the artifact.  Separate
>> from how you get it into the artifacts.  Projects are a good way to
>> inflict common meta-data on packages, which we already do (e.g.
>> manifest and META-INF files) often by inheritance.
> I have different use-cases as well.
> One would be to annotate artifacts with licensing information (something
> that few artifacts have in the wild), and when I package these artifacts I'd
> like to include the license file in the .war, .aar, etc.

License is a good example.  Good hygiene means putting it in all your
packages.  I don't think you want to annotate any of your packages:
it's easier -- read: more likely to be done right -- to specify that
information once in the project and have all the packaging tasks pick
up on it.

Right now, for Java packaging only, you can specify licensing stuff
for manifest/meta-inf in the project definition and the packaging
tasks pick on that and do the right thing.  You don't have to annotate
the artifacts.

That's something I would like to see improved, a more specific method
for dealing with licensing information (license file, copyright,
vendor name, etc) that's easier to use and would work with all sort of
packaging types.

> Another one is packaging different .jars in a .war or .ear file depending on
> the appserver.   I'd like to be able to annotate the artifact and say that
> it's provided in Tomcat and Jetty, but not in Websphere.

See OSGi.  It's super uber complicated, but the metadata does allow
you to specify all sorts of interesting conditions and use these to
select a subset of packages.


> There are other ways in which I can achieve this, but I've found the
> metadata approach to be the most practical in keeping things DRY and
> isolated to a single definition point.
> alex

View raw message