specifying metadata for an artifact

[Ittay Dror <it...@gmail.com>]

Hi,

How can I add metadata to an artifact spec so it can be used by plugins? 
(in my case the same artifact is used in different ways according to 
this metadata). I thought specifying the artifact as a hash would allow 
me to put keys that the plugin will use, but those specs pass through 
several stages of sanitation which leaves just the standard attributes.

I'd appriciate your suggestions,
Ittay

-- 
--
Ittay Dror <it...@gmail.com>

Re: specifying metadata for an artifact

[Ittay Dror <it...@gmail.com>]

Assaf Arkin wrote:
> On Wed, Aug 13, 2008 at 6:04 AM, Ittay Dror <it...@gmail.com> wrote:
>   
>> Hi,
>>
>> How can I add metadata to an artifact spec so it can be used by plugins? (in
>> my case the same artifact is used in different ways according to this
>> metadata). I thought specifying the artifact as a hash would allow me to put
>> keys that the plugin will use, but those specs pass through several stages
>> of sanitation which leaves just the standard attributes.
>>     
>
> A spec is an identifier of the artifact, much like a URL it tells you
> how to locate the artifact, it doesn't tell you anything else about
> the artifact.  Artifacts are designed around one particular naming
> scheme, coupled to the way they're located in remote and local
> repositories.
>
> If you want to change the task itself, it's just a Ruby object that
> you can easily extend or include other modules in there.
>   
yes, but the user specifies the artifacts and metadata.
> Assaf
>
>   
>> I'd appriciate your suggestions,
>> Ittay
>>
>> --
>> --
>> Ittay Dror <it...@gmail.com>
>>
>>
>>
>>     

-- 
--
Ittay Dror <it...@gmail.com>

Re: specifying metadata for an artifact

[Assaf Arkin <ar...@intalio.com>]

On Wed, Aug 13, 2008 at 6:04 AM, Ittay Dror <it...@gmail.com> wrote:
> Hi,
>
> How can I add metadata to an artifact spec so it can be used by plugins? (in
> my case the same artifact is used in different ways according to this
> metadata). I thought specifying the artifact as a hash would allow me to put
> keys that the plugin will use, but those specs pass through several stages
> of sanitation which leaves just the standard attributes.

A spec is an identifier of the artifact, much like a URL it tells you
how to locate the artifact, it doesn't tell you anything else about
the artifact.  Artifacts are designed around one particular naming
scheme, coupled to the way they're located in remote and local
repositories.

If you want to change the task itself, it's just a Ruby object that
you can easily extend or include other modules in there.

Assaf

>
> I'd appriciate your suggestions,
> Ittay
>
> --
> --
> Ittay Dror <it...@gmail.com>
>
>
>

Re: specifying metadata for an artifact

["Ittay Dror (Freiman)" <it...@gmail.com>]

On Wed, Aug 13, 2008 at 10:01 PM, Alex Boisvert <bo...@intalio.com> wrote:
> On Wed, Aug 13, 2008 at 6:04 AM, Ittay Dror <it...@gmail.com> wrote:
>
> So I'm in favor of supporting artifact metadata... although I think it
> should be separate from the artifact object itself.  Maybe we could attach
> it to the project (with inheritance)?
>

that is what i intended to do. something like:
metadata :artifact_id, whatever_data

but it will be nice if this was done through the artifact namespace
mechanism, since artifact namespaces can be attached to projects (so
you get artifacts not only through inheritance)

ittay

> alex
>

Re: specifying metadata for an artifact

[Assaf Arkin <ar...@intalio.com>]

On Wed, Aug 13, 2008 at 2:35 PM, Alex Boisvert <bo...@intalio.com> wrote:
> On Wed, Aug 13, 2008 at 1:16 PM, Assaf Arkin <ar...@intalio.com> 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.

Assaf

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

Re: specifying metadata for an artifact

[Alex Boisvert <bo...@intalio.com>]

On Wed, Aug 13, 2008 at 1:16 PM, Assaf Arkin <ar...@intalio.com> 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.

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.

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

Re: specifying metadata for an artifact

["Ittay Dror (Freiman)" <it...@gmail.com>]

On Wed, Aug 13, 2008 at 11:43 PM, Assaf Arkin <ar...@intalio.com> wrote:
> Why not have tasks specifically for addressing include, libs and other
> relevant directories, which in turn could use artifacts to download
> the package?

i do. however, if two projects want to link with an artifact in the
same way, i want to be able to specify this in a short way.

so i *don't* want something like 'compile.with libs('a.so', 'b.so',
:from => :xxx)'
i want something like 'compile.with :a_b_xxx'
where i can define a_b_xxx in a namespace like 'artifact_ns {|ns|
ns.a_b_xxx = lib('a.so', 'b.so', :from => :xxx)}'

i want to use artifact namespaces because buildr already has the
implementation to manipulate them, attach to projects and inherit from
parent projects.

but i guess there is not enough need for this in general, so i'll create my own

ittay


>
> Assaf
>
>>
>> Ittay
>>
>>>
>>> Assaf
>>>
>>>>
>>>> alex
>>>>
>>>
>>
>

Re: specifying metadata for an artifact

[Assaf Arkin <ar...@intalio.com>]

On Wed, Aug 13, 2008 at 1:26 PM, Ittay Dror (Freiman)
<it...@gmail.com> wrote:
> On Wed, Aug 13, 2008 at 11:16 PM, Assaf Arkin <ar...@intalio.com> 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.
>
> This is not my use case. My use case is this: I want to compile C++
> code. To that effect, I need 3rd party packages. Usually the
> convention is to have a xxx-dev package containing headers and
> libraries of a particular application. So I download the package and
> unpack. So far, all is well. Now I want a project to link with *some*
> libraries from the package. Linking with all creates conflicts. So the
> metadata I want is something like :xxx => ['a.so', 'b.so']. (meaning,
> my project will link with a.so and b.so from package (artifact) xxx).
> Other projects may wish to link with other libraries.
>
> So far, this is indeed something that looks per project, but usually,
> these things tend to repeat (other projects will link with the same
> libraries). So what I would have liked is to be able to define
> something like :a_and_b_from_xxx and then use it in 'compile.with' of
> the projects that need it.
>
> Other examples can be turning on preprocessor defines.
>
> All of these are not part of the artifact, but part of how to use the artifact.

Why not have tasks specifically for addressing include, libs and other
relevant directories, which in turn could use artifacts to download
the package?

Assaf

>
> Ittay
>
>>
>> Assaf
>>
>>>
>>> alex
>>>
>>
>

Re: specifying metadata for an artifact

["Ittay Dror (Freiman)" <it...@gmail.com>]

On Wed, Aug 13, 2008 at 11:16 PM, Assaf Arkin <ar...@intalio.com> 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.

This is not my use case. My use case is this: I want to compile C++
code. To that effect, I need 3rd party packages. Usually the
convention is to have a xxx-dev package containing headers and
libraries of a particular application. So I download the package and
unpack. So far, all is well. Now I want a project to link with *some*
libraries from the package. Linking with all creates conflicts. So the
metadata I want is something like :xxx => ['a.so', 'b.so']. (meaning,
my project will link with a.so and b.so from package (artifact) xxx).
Other projects may wish to link with other libraries.

So far, this is indeed something that looks per project, but usually,
these things tend to repeat (other projects will link with the same
libraries). So what I would have liked is to be able to define
something like :a_and_b_from_xxx and then use it in 'compile.with' of
the projects that need it.

Other examples can be turning on preprocessor defines.

All of these are not part of the artifact, but part of how to use the artifact.

Ittay

>
> Assaf
>
>>
>> alex
>>
>

Re: specifying metadata for an artifact

[Assaf Arkin <ar...@intalio.com>]

On Wed, Aug 13, 2008 at 12:01 PM, Alex Boisvert <bo...@intalio.com> wrote:
> On Wed, Aug 13, 2008 at 6:04 AM, Ittay Dror <it...@gmail.com> wrote:
>
>> How can I add metadata to an artifact spec so it can be used by plugins?
>> (in my case the same artifact is used in different ways according to this
>> metadata). I thought specifying the artifact as a hash would allow me to put
>> keys that the plugin will use, but those specs pass through several stages
>> of sanitation which leaves just the standard attributes.
>
>
> For what it's worth, we did something similar back in the days of Maven1 and
> it was very useful to associate metadata with artifacts in the project
> itself.   This approach avoids having to explicitly propagate the metadata
> to plugins so the user doesn't have to worry about "wiring" plugins.
>
> The Maven2 way is to define the metadata in the POM (a separate artifact)
> but the disadvantage is that sometimes deployed POMs have missing/invalid
> information and you want to change the information without redeploying new
> artifacts, or the metadata is project-specific instead of being inherent to
> the artifact.  Overall, it doesn't work very well in practice.

>From the Maven experience I learned that we should start with tools
that let you easily generate good meta-data, then provide ways to read
and fix broken meta-data.

> So I'm in favor of supporting artifact metadata... although I think it
> should be separate from the artifact object itself.  Maybe we could attach
> it to the project (with inheritance)?

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.

Assaf

>
> alex
>

Re: specifying metadata for an artifact

[Alex Boisvert <bo...@intalio.com>]

On Wed, Aug 13, 2008 at 6:04 AM, Ittay Dror <it...@gmail.com> wrote:

> How can I add metadata to an artifact spec so it can be used by plugins?
> (in my case the same artifact is used in different ways according to this
> metadata). I thought specifying the artifact as a hash would allow me to put
> keys that the plugin will use, but those specs pass through several stages
> of sanitation which leaves just the standard attributes.


For what it's worth, we did something similar back in the days of Maven1 and
it was very useful to associate metadata with artifacts in the project
itself.   This approach avoids having to explicitly propagate the metadata
to plugins so the user doesn't have to worry about "wiring" plugins.

The Maven2 way is to define the metadata in the POM (a separate artifact)
but the disadvantage is that sometimes deployed POMs have missing/invalid
information and you want to change the information without redeploying new
artifacts, or the metadata is project-specific instead of being inherent to
the artifact.  Overall, it doesn't work very well in practice.

So I'm in favor of supporting artifact metadata... although I think it
should be separate from the artifact object itself.  Maybe we could attach
it to the project (with inheritance)?

alex