maven-m2-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett Porter <>
Subject Re: artifacts and types: summary
Date Fri, 25 Jun 2004 00:34:31 GMT
I won't go over it again, but other emails have clearly defined that we need:
a) to not split into multiple projects to generate these extra derivatives
b) to make sure these derivatives have a unique filename so they can be bundled
inside a RAR/EAR/etc alongside their counterparts.

The filename in the repository should be the filename you would generally use,
so the form:
seems to be generally accepted as the best (Where [] indicate that part is the
difference between the client and the original)

> I know it is bit confusing from the point of view of ejb developers.
> I just want to remove any confusion from the point of view of Maven.
> One of the key requirement which we have is that we can associate each
> dependency with its pom. 

This is exactly why I think that type should be the primary type and nothing
more. And why I thought an extra <derivative/> (or <kind/> as originally
suggested last year apparently) is a good idea. I think derivative is a better
name as it clearly indicates that it is derived from the primary artifact.

> Other requirement which I am trying to defend here is that is that it
> will be nice to have a single way of declaring dependencies
> If we will have artifacts like jars/foo-client-1.0.jar in repository
> people may define a dependency on it in the following ways:

Because of the way the files are looked up, you will always have this problem,
as this would work:

You would need to enforce the presence of a POM and check the values against it
to enforce a single way of declaring the dependency. Again, you would need type
to be unique as above. <derivative> can be added to the filename, but ignored
from the enforcement point of view (unless we go to the extent of defining
derivatives that are valid for each type, which is definitely an option).

> Both requirements can be easly satisfied in type ejb-client will be
> required and we will have directory for ejb-client jars like now we have
> for jars.

This means the filename needs to go back to not having -client in it, which will
need to be modified when included in a RAR. This seems like the wrong time to do
it - keep the filenames the same the whole time from end to end I say.

> People are used to use files foo-client-1.0.jar and  foo-1.0.jar and are
> not used to use foo-1.0.jar (client), foo-1.0.ejb (ejb) or
> foo-ejb-1.0.jar (ejb)
> So probably this is very valid argument against my objections :)

As I said above, it's not just what they are used to using: the filenames will
clash when outside the repo.

My suggestion that still seems to satisfy all requirements is:

- make type only be primary artifact types, and dependency.type = pom.type
- add derivative to the dependency element. Valid derivatives are defined by the
artifact handler
- allow the artifact handler to generate any of its derivatives as controlled by
properties to that plugin
- unique identifier for a project remains groupId:artifactId:type
- filename for a derivative is /groupId/types/artifactId-derivative-version.type
by default where derivative is optional.
- artifact handlers can define custom repo filename mappers to change the
filename as necessary. The only use fo this I see is to change the extension: so
maybe the artifact handler just defines an extension instead.

I'll add this to docs.codehaus.


View raw message