Skip to end of metadata
Go to start of metadata

Having hashed through all this, I think at the moment we can keep the creation of new types which are dependency-only types for the secondary artifacts, but leave ourselves open to a derivative tag if we find it unworkable. See below for history.

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.


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.

  • No labels

1 Comment

  1. Michal:
    It's even more difficult.then I though:

    For example both EJB clients or RMI clients might only require limited set of dependecies as they are "exporting" interfaces.
    Implementation of those interfaces might require some addititional liblaries.

    In such cases we really might need to have an additional pom.