Actually, Maven 2 supports "secondary" or "attached" artifacts, where the inputs are basically the same but the output differs because of the build configuration. This is such a case.
What would happen is the retrotranslator plugin would build the 1.4 JAR, give it a classifier, and attach the artifact, so that deployment deploys them both. And example is the sources plugin, or the javadoc:jar goal. the beginnings of a retrotranslator plugin is here: http://cvs.codehaus.org/viewrep/mojo/trunk/mojo/mojo-sandbox/retrotranslator-maven-plugin - Brett On 4/20/06, Matthew L Daniel <[EMAIL PROTECTED]> wrote: > > We have a project, JBoss Webservices. This project has one source tree > > and is set up as a single project. We build a jar using jdk1.5. > > Next we retrotranslate that jar to run on a 1.4 version jvm which > > produces a second artifact webservices1.4 version. Of course, this > > defies the one artifact rule for the project structure. > > Technically, "webservices1.4" would _depend_ on "webservices1.5" and the > "build" goal for "1.4" would run this magic process upon the artifact > from "1.5" and (presumably) stash the output in ${maven.build.dir}, to > await installation and deployment via their respective goals. > > IMHO, of course. > -- /v\atthew > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
