Classifier and dependencies

2007-11-19 Thread Emmanuel Hugonnet
Hi,
I have a project that I need to build for different JDKs; Because we use
JAXB on jdk1.4.2, 5 and 6I need to specify different dependencies for the
JAXB version from 1.0.6 to 2.0.5. So I have different profiles for each jdk
version target.
I have set a classifier so that I get 3 different articfacts. My problem is
: I have only on pom as a result instead of 3 (one per artifact) . this
causes my dependencies resolving to go wrong if the installed/deployed pom
doesn't match the artifact I am using. How could I have the classifier set
on the pom when I am installing or deploying ? How should I proceed?
Thanks,
Emmanuel


Re: Classifier and dependencies

2007-11-19 Thread Emmanuel Hugonnet
Currently, I have set my version tag to :
version${parent.version}-${classifier}/version

and I set the classifier property in my profiles but this doesn't feel good.

2007/11/19, Emmanuel Hugonnet [EMAIL PROTECTED]:

 Hi,
 I have a project that I need to build for different JDKs; Because we use
 JAXB on jdk1.4.2, 5 and 6I need to specify different dependencies for the
 JAXB version from 1.0.6 to 2.0.5. So I have different profiles for each
 jdk version target.
 I have set a classifier so that I get 3 different articfacts. My problem
 is : I have only on pom as a result instead of 3 (one per artifact) . this
 causes my dependencies resolving to go wrong if the installed/deployed pom
 doesn't match the artifact I am using. How could I have the classifier set
 on the pom when I am installing or deploying ? How should I proceed?
 Thanks,
 Emmanuel



Re: [m2-b1] classifier-specific dependencies colliding with generic dependencies

2005-09-28 Thread John Fallows
On 9/28/05, Brett Porter [EMAIL PROTECTED] wrote:
 I think its because the project you are depending on is in the
 reactor, and its probably a bug.

 Basically, its trying to use the built version of that project, but
 projects are only identified by group:artifactId

Okay - filed issue MNG-1041.

http://jira.codehaus.org/browse/MNG-1041

Kind Regards,
John Fallows.

 On 9/28/05, John Fallows [EMAIL PROTECTED] wrote:
  Folks,
 
  It seems like there is a collision between dependencies from the same
  project but with different classifiers, causing only the main
  dependency artifact to be present on the compilation classpath.
 
  This example will look familiar to anyone following a previous public
  mock api thread. :-)
 
  project/
api-module/
impl-module/
 
  The api-module generates 2 artifacts, one with classifier mock.
  The impl-module depends on both of these artifiacts, one with mock
  classifier at test scope and the other with no classifier at the
  default compile scope.
 
  During compilation of the impl-module tests, classes from the
  api-module mock artifact are not found on the classpath.
 
  It seems as though the mock artifact and the regular artifact are
  colliding, causing the mock artifact to be removed from the test
  compilation classpath.
 
  Both the mock and regular artifacts from the api-module have type
  jar.  Even when the mock type is changed to zip, the same
  problem occurs.
 
  Perhaps dependency classifiers are ignored while constructing the
  compilation classpath?
 
  Kind Regards,
  John Fallows.
 
  -
  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]



[m2-b1] classifier-specific dependencies colliding with generic dependencies

2005-09-27 Thread John Fallows
Folks,

It seems like there is a collision between dependencies from the same
project but with different classifiers, causing only the main
dependency artifact to be present on the compilation classpath.

This example will look familiar to anyone following a previous public
mock api thread. :-)

project/
  api-module/
  impl-module/

The api-module generates 2 artifacts, one with classifier mock.
The impl-module depends on both of these artifiacts, one with mock
classifier at test scope and the other with no classifier at the
default compile scope.

During compilation of the impl-module tests, classes from the
api-module mock artifact are not found on the classpath.

It seems as though the mock artifact and the regular artifact are
colliding, causing the mock artifact to be removed from the test
compilation classpath.

Both the mock and regular artifacts from the api-module have type
jar.  Even when the mock type is changed to zip, the same
problem occurs.

Perhaps dependency classifiers are ignored while constructing the
compilation classpath?

Kind Regards,
John Fallows.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [m2-b1] classifier-specific dependencies colliding with generic dependencies

2005-09-27 Thread Brett Porter
I think its because the project you are depending on is in the
reactor, and its probably a bug.

Basically, its trying to use the built version of that project, but
projects are only identified by group:artifactId

- Brett

On 9/28/05, John Fallows [EMAIL PROTECTED] wrote:
 Folks,

 It seems like there is a collision between dependencies from the same
 project but with different classifiers, causing only the main
 dependency artifact to be present on the compilation classpath.

 This example will look familiar to anyone following a previous public
 mock api thread. :-)

 project/
   api-module/
   impl-module/

 The api-module generates 2 artifacts, one with classifier mock.
 The impl-module depends on both of these artifiacts, one with mock
 classifier at test scope and the other with no classifier at the
 default compile scope.

 During compilation of the impl-module tests, classes from the
 api-module mock artifact are not found on the classpath.

 It seems as though the mock artifact and the regular artifact are
 colliding, causing the mock artifact to be removed from the test
 compilation classpath.

 Both the mock and regular artifacts from the api-module have type
 jar.  Even when the mock type is changed to zip, the same
 problem occurs.

 Perhaps dependency classifiers are ignored while constructing the
 compilation classpath?

 Kind Regards,
 John Fallows.

 -
 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]