maven-m2-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Maczka Michal <>
Subject RE: artifacts and types: summary
Date Thu, 24 Jun 2004 08:09:47 GMT

> -----Original Message-----
> From: Brett Porter []
> Sent: Thursday, June 24, 2004 1:07 AM
> To: Maven 2 Developers List
> Subject: artifacts and types: summary
> Hi,
> I felt I should sum up where we are at with this now, as 
> after talking with
> Jason I now realise the problem is much simpler.
> Firstly, we must be able to customise the artifact name in 
> the repository, in
> the filename. David and Emmanuel have demonstrated this 
> clearly in emails today.
> ie ejbs should be built to /ejbs/foo-1.0.jar and 
> /ejbs/foo-1.0-client.jar. the
> jars directory is for jars that are not special, not for 
> wars, ejbs, etc.

I am not yet convinced about ejb ad ejb-client :)
IMO ejb-client is not tha "special" to deserve new type.

Only EJB jar is. We might as well go for: 
/ejbs/foo-ejb-1.0.jar (ejb)
/jars/foo-1.0.jar (ejb-client)

> Now, we have a 1:1 mapping of project type to a primary 
> artifact. So projects
> make one thing.
> Everything else is a secondary artifact produced as a side 
> effect of the build
> process: documentation, distribution, ejb client, even the 
> pom itself. Some of
> these are built into maven (the pom is generated for 
> everything), some into the
> artifact handler (ejb knows to generate -client) and some are 
> custom goals
> (distribution, documentation).
> Either way, the only requirement for these secondary artifact 
> types is that we
> can upload/download them from the repository. Wheteher they 
> are generated should
> just be controlled by its source (properties of the ejb 
> plugin might say "don't
> make a client", properties of dist plugin will allow you to 
> customise what dists
> are made, but none of this is core to the POM).
> I think we all agree on this.
> What we need to resolve:
> 1) how do we download them?
> 2) how do we upload them?
> 3) how do we handle the use case Michal raised where a jar 
> gets changed by a
> plugin to generate something different?
> These are my thoughts on each:
> 1) how do we download them?
> I say we utilise the <filename/> (I think that is what jar 
> was renamed to?)
> element of the dependency, or modify version/artifactId like 
> we already do. This
> seems to work well.

I do belive that we must try to stay with tags we have. 
I even believe that when artifact handlers will be in place we won't even
need to have <filename> tag.

That's why I am so pertinacious that ejb client jar should be seen as any
other jar.

We should have:

(e.g. maps to path baa/ejbs/foo-ejb-1.0.jar)


(ejb-client is a normal jar so maps to path baa/jars/foo-1.0.jar)
IMO we should do whatever we can to limit the number of types.

> 2) how do we upload them?

> 3) how do we handle the use case Michal raised where a jar 
> gets changed by a
> plugin to generate something different?
> This is the trickiest. I don't think this should be built 
> into the POM in any
> way. Basically, we are talking about something jumping in to 
> the middle of the
> build process - in most cases different parameters to the 
> compiler, or a custom
> compiler to obfuscate the code.

After thiniking about it a bit I don't think anymore that it's that hard to
deal with situation when jars needs to be modified.
For that we might easly create other project which will use some jars from
local repository and modify it.

Quite similar thing can be probably done in the situtation when sources are
We can have other project which will reference sources which may sit in
other project.

Say that really both debug and normal jars are needed. I guees that we might
create 2 projects for that.
One which will generate nomal jar and other one which will use the sources
of first project and generate debug jar 
(just compile plugin needs to have different parameters).

The same thing can be done for rmi client/server jars. Sources can be


View raw message