Well the problem I see is that of dependencies being added to the jvm.
Fundamentally javax.activation should be scope "provided"... as it's
up to the consumer of your api to ensure it is available.
The api that is dragging in javax.activation has it as scope
"compile"... which is why it is ending up transitively as a
dependency.
The issue is that we have not got documentation which indicates what
modules are in the java run time classpath.
If Maven had that knowledge, then you could flag, at least for unit
tests and launching by Maven, that the dependency has not been
provided either explicitly or by the jvm's rt
The consumer of your code, though, still has to ensure that they
provide the api's that are required by your code, i.e. those with a
scope of provided.
I think you maybe confusing running your code from within Maven with
running outside of Maven.
If ANT "has greater capability" it is to hide this classpath
complexity from you (as a developer) while developing... once you turn
around to deploying in a mixed environment, ant will have hidden the
problem from you very much and you will be more stuck than before.
One way out of your problems that I see would be to have a
jdk6-backport artifact with a number of classifiers, one for each jdk
that you want to support. The backport artifact can be an empty jar
with just dependencies on the missing modules that the earlier jdks do
not have (w.r.t. jdk6)
Thus each system need only pull in it's backport artifact as a
dependency. a central dependencyManagement section in the common
parent pom that is activated based on the jdk would then select the
appropriate classifier for your runtime environment, and each child
module need only declare a scope runtime dependency on the
jdk6-backport artifact (without providing version or classifier) thus
indicating this complex relationship
On Feb 5, 2008 11:34 PM, Martin Gainty <[EMAIL PROTECTED]> wrote:
> looking for scenarios which will work for all jvm versions (and not forcing
> the implementor to individually handle jvm specific scenarios)
> ANT certainly has greater capability (at least with this scenario)
>
> but still looking forward to a maven based solution
>
> Thanks
> Martin
> ----- Original Message -----
> From: "Stephen Connolly" <[EMAIL PROTECTED]>
> To: "Maven Users List" <users@maven.apache.org>
>
> Sent: Tuesday, February 05, 2008 5:18 PM
> Subject: Re: javax.mail and javax.activation in Java 6
>
>
> > Look, maven only works on JDK 1.3 or higher...
> >
> > you have three profiles
> >
> > <dependencies>
> > <dependency>
> > <groupId>javax.mail</groupId>
> > <artifactId>mail</artifactId>
> > <version>1.4.1</version>
> > <excludes>
> > ... (see documentation) ...
> > </excludes>
> > <dependency>
> > <dependencies>
> > <profiles>
> > <profile>
> > <id>jdk13</id>
> > <activation>
> > <jdk>1.3</jdk>
> > </activation>
> > <dependencies>
> > <dependency>
> > <groupId>javax.activation</groupId>
> > <artifactId>activation</artifactId>
> > <version>1.1</version>
> > </dependency>
> > </dependencies>
> > </profile>
> > <profile>
> > <id>jdk14</id>
> > <activation>
> > <jdk>1.4</jdk>
> > </activation>
> > <dependencies>
> > <dependency>
> > <groupId>javax.activation</groupId>
> > <artifactId>activation</artifactId>
> > <version>1.1</version>
> > </dependency>
> > </dependencies>
> > </profile>
> > <profile>
> > <id>jdk15</id>
> > <activation>
> > <jdk>1.5</jdk>
> > </activation>
> > <dependencies>
> > <dependency>
> > <groupId>javax.activation</groupId>
> > <artifactId>activation</artifactId>
> > <version>1.1</version>
> > </dependency>
> > </dependencies>
> > </profile>
> > </profiles>
> >
> > Which is actually quite elegant, as each jdk includes more than the
> > previous, so if there are dependencies that are in JDK 1.5 but not JDK1.4,
> > you can add them only to jdk14 profile, etc.
> >
> > Quit with the environment variable stuff as your build will not be
> > reproducible... if you want to do that kind of stuff I'd either switch to
> > ANT or write a plugin
> >
> >
> > On Feb 5, 2008 9:41 PM, Martin Gainty <[EMAIL PROTECTED]> wrote:
> >
> > > the only possible suggestion is to set JAVA_VERSION environment variable
> > > to
> > > whatever_it_is..(probably implement this in .profile for login..?)
> > > and then test it thru a Character Data script i.e.
> > > <profiles>
> > > <profile>
> > > <activation>
> > > <jdk>
> > > <![CDATA[
> > > ${env.JAVA_VERSION} < 6]]>
> > > </jdk>
> > > </activation>
> > > </profile>
> > > </profiles>
> > >
> > > Anyone else?
> > > M-
> > > ----- Original Message -----
> > > From: "Stephen Connolly" <[EMAIL PROTECTED]>
> > > To: "Maven Users List" <users@maven.apache.org>
> > > Sent: Tuesday, February 05, 2008 4:12 PM
> > > Subject: Re: javax.mail and javax.activation in Java 6
> > >
> > >
> > > > And you know what, Google _Is_ Your Friend:
> > > >
> > > >
> > >
> http://maven.apache.org/guides/introduction/introduction-to-profiles.html
> > > >
> > > > The follwing configuration will trigger the profile when the JDK's
> > > version
> > > > starts with "1.4" (eg. "1.4.0_08", "1.4.2_07", "1.4"):
> > > >
> > > > <profiles>
> > > > <profile>
> > > > <activation>
> > > > <jdk>1.4</jdk>
> > > > </activation>
> > > > ...
> > > > </profile>
> > > > </profiles>
> > > >
> > > > So if you are using generics (i.e. don't have to worry about jdk 1.4)
> > > you
> > > > just have the profile to add the dependency back in activated by <jdk>
> > > 1.5
> > > > </jdk>
> > > >
> > > > if you have to worry about 1.4, you'll need two profiles... and if,
> God
> > > > forbid you need to worry about 1.3, three profiles all adding it back
> in
> > > >
> > > > On Feb 5, 2008 9:09 PM, Stephen Connolly <
> > > [EMAIL PROTECTED]>
> > > > wrote:
> > > > > profile activation based on jvm... i'll do a quick GIYF
> > > > >
> > > > >
> > > > > On Feb 5, 2008 8:53 PM, Martin Gainty <[EMAIL PROTECTED]> wrote:
> > > > > > I'll ask the dumb question..how do you do test the JVM version
> with
> > > > maven?
> > > > > >
> > > > > > ?
> > > > > > M-
> > > > > > ----- Original Message -----
> > > > > > From: "Stephen Connolly" <[EMAIL PROTECTED]>
> > > > > > To: "Maven Users List" <users@maven.apache.org>
> > > > > >
> > > > > > Sent: Tuesday, February 05, 2008 3:30 PM
> > > > > > Subject: Re: javax.mail and javax.activation in Java 6
> > > > > >
> > > > > >
> > > > > > > Nooooooo!
> > > > > > >
> > > > > > > don't go abusing the system path for that
> > > > > > >
> > > > > > > Go with the exclude by default and add back in if jvm is < 6
> > > > > > >
> > > > > > > On Feb 5, 2008 7:49 PM, J Douglas Donohoe <[EMAIL PROTECTED]>
> > > wrote:
> > > > > > > > Thanks for the suggestion. That led me down the right path.
> It
> > > > looks
> > > > > > like the 'system' scope is more appropriate because in this case,
> > > the
> > > > > > classes are part of the rt.jar. I used the following profile:
> > > > > > > >
> > > > > > > > <profiles>
> > > > > > > > <profile>
> > > > > > > > <id>Java 1.6</id>
> > > > > > > > <activation>
> > > > > > > > <jdk>1.6</jdk>
> > > > > > > > </activation>
> > > > > > > > <dependencies>
> > > > > > > > <dependency>
> > > > > > > > <groupId>javax.activation</groupId>
> > > > > > > > <artifactId>activation</artifactId>
> > > > > > > > <version>1.1</version>
> > > > > > > > <scope>system</scope>
> > > > > > > > <systemPath>${java.home}/lib/rt.jar</systemPath>
> > > > > > > > </dependency>
> > > > > > > > </dependencies>
> > > > > > > > </profile>
> > > > > > > > </profiles>
> > > > > > > >
> > > > > > > > To verify this worked, I used the following command:
> > > > > > > >
> > > > > > > > $ mvn dependency:build-classpath
> > > > > > > >
> > > > > > > > The javax.activation jar no longer appears on the classpath,
> but
> > > > rt.jar
> > > > > > now appears (presumably because this plugin defaults to the build
> > > > > > classpath).
> > > > > > > >
> > > > > > > > If I do:
> > > > > > > >
> > > > > > > > $ mvn dependency:build-classpath -DexcludeScope=system
> > > > > > > >
> > > > > > > > Then I get the classpath I want.
> > > > > > > >
> > > > > > > > Thanks for your help.
> > > > > > > >
> > > > > > > > One question on the use of 'system path' in dependency. Why
> is
> > > this
> > > > > > necessary at all? If it is part of the system, doesn't javac
> and/or
> > > > java
> > > > > > know where to find it by default?
> > > > > > > >
> > > > > > > > -Doug
> > > > > > > >
> > > > > > > > *Note: I'm not sure the system path above will work quite
> right
> > > on
> > > > a
> > > > > > Mac. It depends on how Apple decides to package things when they
> > > > release
> > > > > > 1.6.
> > > > > > > >
> > > > > > > >
> > > > > > > > ----- Original Message ----
> > > > > > > > From: Simon Kitching <[EMAIL PROTECTED]>
> > > > > > > > To: Maven Users List <users@maven.apache.org>
> > > > > > > > Cc: Doug Donohoe <[EMAIL PROTECTED]>
> > > > > > > > Sent: Tuesday, February 5, 2008 10:57:05 AM
> > > > > > > > Subject: Re: javax.mail and javax.activation in Java 6
> > > > > > > >
> > > > > > > >
> > > > > > > > ---- Doug Donohoe <[EMAIL PROTECTED]> schrieb:
> > > > > > > > > Hi Maven Community:
> > > > > > > > >
> > > > > > > > > I have added this dependency in my POM:
> > > > > > > > >
> > > > > > > > > <dependency>
> > > > > > > > > <groupId>javax.mail</groupId>
> > > > > > > > > <artifactId>mail</artifactId>
> > > > > > > > > <version>1.4.1</version>
> > > > > > > > > </dependency>
> > > > > > > > >
> > > > > > > > > Which is retrieved from java.net using this POM definition:
> > > > > > > > >
> > > > > > > > > <repositories>
> > > > > > > > > <repository>
> > > > > > > > > <id>java.net</id>
> > > > > > > > > <url>http://download.java.net/maven/1</url>
> > > > > > > > > <layout>legacy</layout>
> > > > > > > > > </repository>
> > > > > > > > > </repositories>
> > > > > > > > >
> > > > > > > > > The POM for javax.mail declares a dependency on the Java
> > > > activation
> > > > > > > > > framework. However, I am using Java 6 (1.6.0_02), which
> > > already
> > > > > > > > > includes the activation framework.
> > > > > > > > >
> > > > > > > > > My question: Is there a way in maven to conditionally
> define
> > > a
> > > > > > > > > dependency based on the JDK you are using?
> > > > > > > > >
> > > > > > > > > If there is, what is the best way for me to use such a
> > > mechanism.
> > > > > > > > > Ideally, the POM at java.net would be updated, but assuming
> I
> > > > can't
> > > > > > > > > figure out how to get them to update that, how do I override
> > > there
> > > > > > > > POM?
> > > > > > > > >
> > > > > > > >
> > > > > > > > Try defining a profile called "java6" in your pom. Set its
> > > > activation
> > > > > > > > section so it only activates for java1.6. Then in the profile
> > > > define
> > > > > > > > that problem dependency with scope=provided.
> > > > > > > >
> > > > > > > > I think that will do the job. Dependencies declared directly
> in
> > > a
> > > > pom
> > > > > > > > always override those pulled in transiently. That definitely
> > > occurs
> > > > for
> > > > > > > > version-numbers, and I *think* it works for scope too.
> > > > > > > >
> > > > > > > > Regards,
> > > > > > > > Simon
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > ---------------------------------------------------------------------
> > > > > > > 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]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
