This is only because the artifact ID was changed, so there would be no pom written for it and the default gets used instead.
If you want transitive dependencies (and to retain the entire pom), keep the same artifact ID, but change the "classifier" element of the artifact. This would give: jboss-webservices-1.0.jar jboss-webservices-1.0-retro.jar Cheers, Brett On 4/25/06, Ruel Loehr <[EMAIL PROTECTED]> wrote: > Right! This is the course I was thinking of....The only problem of I > see that is if I have two artifacts > > 1) Jboss-webservices-1.0.jar (built using 1.5 jdk) > 2) Jboss-webservices-retrotranslated-1.0.jar (retrotranslated using 1.4 > jdk) > > Later projects can choose which of these jars it would like to build > against (based upon profile config) but, if I choose #1 I get the > transitive dependencies, if I choose #2 I won't get them. > > Is this a bug? Attached jars will not resolve transitive dependencies > in maven. > > Ruel Loehr > JBoss QA > > ----------------------------- > 512-342-7840 ext 2011 > Yahoo: ruelloehr > Skype: ruelloehr > AOL: dokoruel > > -----Original Message----- > From: Brett Porter [mailto:[EMAIL PROTECTED] > Sent: Wednesday, April 19, 2006 7:13 PM > To: Maven Users List; [EMAIL PROTECTED] > Subject: Re: Retrotranslation and the everpresent 1 artifact > > 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/retrotransl > ator-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] > > > --------------------------------------------------------------------- > 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]
