Ok, I understand better now.
So, ignoring the issue of needing different dependencies for different JDKs,
I could use classifiers.
In the jdk1.5 profile I would configure the jar plugin to produce jars with
a classifier "jdk1.5". If there are dependencies between modules, I would
have to
redefine the deps in this profile as well using the "classified" artifacts.
Let's assume the module for artifact2 depends on artifact1.
The default profile would define a dependency to artifact1 like this:
<groupId>...</groupId>
<artifactId>artifact1</artifactId>
<version>...</version>
The jdk1.5 profile would define it like this:
<groupId>...</groupId>
<artifactId>artifact1</artifactId>
<version>...</version>
<classifier>jdk1.5</classifier>
Correct?
Still a bit ugly, but it could work...
Thanks,
Holger
Stephen Connolly-2 wrote:
>
> OK, the first idea when Maven 2 was being designed is that you would use
> different classifiers to differentiate between the different JDKs... thus
> you could go
>
> <dependency>
> <groupId>com.foo.foo</groupId>
> <artifactId>bar</artifactId>
> <classifier>jdk15</classifier>
> </dependency>
>
> in order to use the jdk15 version, rather than the default with no
> classifier....
>
> Why they did not see the problem at this point is beyond me... which is
> the
> default??? is it the jdk13 version? the jdk16 version?
>
> You'd really need everything to have a classifier and not allow default
> classifiers....
>
> Then enter NMaven which points out that you could want multiple
> classifiers...
>
> This could even apply in Java...
>
> On top of all of this, you have that for transitive dependencies,
> everything
> uses the one POM.xml
>
> So if I have a jdk15 and a jdk16 set of artifacts that use JAXB.... for
> jdk16 I should not list JAXB as a transitive dependency (as it is included
> in jdk16) but I need it for jdk15... the jdk14 stuff needs some other
> stuff
> added as well, and the jdk13 stuff even needs me to swap in a whole lot of
> other stuff to work around JAXB and roll it all myself
>
> i.e. dependencies are a problem when you use classifiers.
>
> That problem has not been solved yet.... it may have to wait until Maven
> 3.0 (as it might require a schema change)
>
> OK, so you're fine that classifiers cannot be used to solve the problem
> (BTW
> either adding the classifier config or the build helper plugin can be used
> to attach the builds using classifiers... but I suggest that you ignore
> that
> approach)
>
> Now you realize that you cannot do everything from one artifact.... you
> need
> more than one artifact...
>
> So you create two projects foo-jdk15 and foo-jdk16
>
> in foo-jdk15 you also build the source-jar and attach that to the reactor
>
> in foo-jdk16 you use the dependency plugin to extract
> foo-jdk15-sources-${project.version}.jar into target/generated-sources/jar
> and use the build helper plugin to add this source path...
>
> That should do what you need and allow you to differentiate the
> depenencies
> required for each platform (jdk15 vs jdk16)
>
> 2008/9/25 Holger Brands <[EMAIL PROTECTED]>
>
>>
>> Stephen,
>>
>> I don't quite understand your tip.
>> My main problem is not compiling. I don't need different JREs to link
>> against, I just have to specify a different target compiler option. Just
>> in
>> case I wasn't clear about that.
>> The problem is to tweak the artifactIds to have a suffix. The generated
>> artifacts should reflect the changed names as well as the deploy plugin
>> should respect them in the deployed poms and with regard to the
>> deployment
>> target directory.
>>
>> Thanks,
>> Holger
>>
>>
>> Stephen Connolly-2 wrote:
>> >
>> > I want to say classifiers....
>> >
>> > but that only works if the dependencies have not changed.
>> >
>> > Perhaps what you want is a different project that depends on the first
>> one
>> > and unpacks it's -source.jar and does a recompile with the different
>> jdk
>> >
>> > On 25 September 2008 12:00, Holger Brands <[EMAIL PROTECTED]> wrote:
>> >
>> >>
>> >> I've a multi-module build that is compiled with target 1.6 and
>> deployed
>> >> to
>> >> our company repo with artifactIds "artifact1", "artifact2" and so on.
>> >>
>> >> Now, what I want to achieve is the following:
>> >> I want the same multi-module build optionally to be compiled with
>> target
>> >> 1.5
>> >> and deployed to our company repo with artifactIds "artifact1_java15",
>> >> "artifact2_java15" and so on.
>> >>
>> >> So, ideally
>> >> - "mvn deploy" should deploy the default build artifacts compiled with
>> >> target 1.6.
>> >> - "mvn -Djdk=1.5 deploy" should deploy the derived build artifacts
>> >> compiled
>> >> with target 1.5.
>> >>
>> >> I know how to use profiles/properties to set the desired compiler
>> >> options.
>> >> But how to tweak the artifactIds?
>> >>
>> >> Is there an easy way to accomplish this?
>> >> If not, what's the recommended way to deal with this requirement?
>> >>
>> >> I'm using Maven 2.0.9 on Windows XP.
>> >>
>> >> Sorry, if this has been asked before.
>> >>
>> >> Thanks,
>> >> Holger
>> >>
>> >> --
>> >> View this message in context:
>> >>
>> http://www.nabble.com/deploy-multi-module-artifacts-with-derived-artifactIds-tp19667309p19667309.html
>> >> Sent from the Maven - Users mailing list archive at Nabble.com.
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> >> For additional commands, e-mail: [EMAIL PROTECTED]
>> >>
>> >>
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/deploy-multi-module-artifacts-with-derived-artifactIds-tp19667309p19671027.html
>> Sent from the Maven - Users mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
>
--
View this message in context:
http://www.nabble.com/deploy-multi-module-artifacts-with-derived-artifactIds-tp19667309p19676404.html
Sent from the Maven - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
