Use case - Secondary artifact types

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.