artifacts and types: summary

[Brett Porter <br...@apache.org>]

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.

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.

2) how do we upload them?

For primary artifacts and those derived from it (eg ejbclient), the artifact
handler should be able to tell the install/deploy plugins that its got X things
to install.

For secondary artifacts made by goals (eg distribution), the dist plugin will
probably be calling install/deploy as part of a dist:install/dist:deploy goal,
and can pass in X artifacts to send up.

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.

I think here the user just reruns the normal stuff but overrides some plugin
parameters to generate something different. If they want to automate generating
both, then a custom maven.xml is needed.

The only problem here is that the filename might want to be modified in the
repository, so we need to be able to tell install/deploy to modify it. Something
along the lines of the ArtifactTypeHandler I just put into m1 would do the job here.

What I don't think we can do here is make a new "debug" plugin that builds a jar
with debug turned on... this is asking for trouble and can't be combined with
other modifications.

There are more usecases for this: JDO plugins that modify the generated JAR for
example - you may want to keep both.

This also starts to lead back to the branch types where I discussed building
different artifacts for different branches and different operating systems.

Anyway, the last one is a whole new kettle of fish. I'll put all this into
confluence.

Cheers,
Brett