date:20101210

Hi,

I'm pretty new to Java and Maven, so my question may be very naive
and/or stupid, apologies for that.
I'm trying to compile an open-source project (if that matters, it's
https://plugins.atlassian.com/plugin/details/4832 ), which is supposed
to be built with Maven. I've got Maven 3 installed (Apache Maven 3.0.1
(r1038046; 2010-11-23 10:58:32+)). This pretty small project
depends on a larger one (Atlassian JIRA), which has some Maven
support, but the public repos are not well maintained, and there are a
lot of broken dependencies, therefore the dependency resolution
process fails.
However, I have all of the first level (direct) dependencies resolved.
As far as my knowledge goes, it's enough to have the first level
dependencies to compile a Java project, and that's exactly what I
want. Is there a way to tell Maven to stop resolving 2 level
dependencies, and just try compiling the project? I tried to Google
for this, no luck; and the guides on mvn dependency resolution don't
help either.

Thanks,
Mate

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Maven create JAR

2010-12-10 Thread madeOfStarStuff


Hi, I'm sure this will be simple one...

My pom.xml is configured to create a jar; which is does. However, I've added
some config to inlude and exclude certain files etc.  When I do this, none
of the class files are added (i.e. package folders).

pom.xml (snippets):
project xmlns=http://maven.apache.org/POM/4.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd;
modelVersion4.0.0/modelVersion
groupIdcom.mypackage.me/groupId
artifactIdmyapp/artifactId
packagingjar/packaging
version1.0-SNAPSHOT/version
namemyapp/name
urlhttp://maven.apache.org/url
dependencies
dependency
..

build
pluginManagement
plugins
plugin

artifactIdmaven-compiler-plugin/artifactId
configuration
source1.5/source
target1.5/target
/configuration
/plugin
plugin

groupIdorg.apache.maven.plugins/groupId

artifactIdmaven-jar-plugin/artifactId
configuration
archive
manifest
mainClass

com.mypackage.me.ClassWithMainMethod
/mainClass
/manifest
/archive  

includes

includespring-context.xml/include
/includes
excludes

exclude/*.properties/exclude
/excludes 

/configuration
/plugin
/plugins
/pluginManagement



using mvn clean install 

myapp-1.0-SNAPSHOT.jar
   - META-INF
   - spring-context.xml
   - NO package folders?

Any advice?
Many thanks..


-- 
View this message in context: 
http://maven.40175.n5.nabble.com/Maven-create-JAR-tp3300215p3300215.html
Sent from the Maven - Users mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Maven create JAR

Well, you're only including spring-context.xml with that config so Maven
does what you're telling it to. :-)
I think you would get what you want if you just remove the includes snippet
(and keep the excludes).

/Anders
On Fri, Dec 10, 2010 at 13:18, madeOfStarStuff solksjae...@hotmail.comwrote:


 Hi, I'm sure this will be simple one...

 My pom.xml is configured to create a jar; which is does. However, I've
 added
 some config to inlude and exclude certain files etc.  When I do this, none
 of the class files are added (i.e. package folders).

 pom.xml (snippets):
 project xmlns=http://maven.apache.org/POM/4.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
 http://maven.apache.org/maven-v4_0_0.xsd;
modelVersion4.0.0/modelVersion
groupIdcom.mypackage.me/groupId
artifactIdmyapp/artifactId
packagingjar/packaging
version1.0-SNAPSHOT/version
namemyapp/name
urlhttp://maven.apache.org/url
dependencies
dependency
 ..

build
pluginManagement
plugins
plugin

  artifactIdmaven-compiler-plugin/artifactId
configuration
source1.5/source
target1.5/target
/configuration
/plugin
plugin

  groupIdorg.apache.maven.plugins/groupId

  artifactIdmaven-jar-plugin/artifactId
configuration
archive
manifest
mainClass

  com.mypackage.me.ClassWithMainMethod
/mainClass
/manifest
/archive
includes

  includespring-context.xml/include
/includes
excludes

  exclude/*.properties/exclude
/excludes
/configuration
/plugin
/plugins
/pluginManagement

 

 using mvn clean install

 myapp-1.0-SNAPSHOT.jar
   - META-INF
   - spring-context.xml
   - NO package folders?

 Any advice?
 Many thanks..


 --
 View this message in context:
 http://maven.40175.n5.nabble.com/Maven-create-JAR-tp3300215p3300215.html
 Sent from the Maven - Users mailing list archive at Nabble.com.

 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org

Re: Limiting dependency resolution depth

2010-12-10 Thread Tamás Cservenák

Hi,

Okay, but to be able to help, we need more:

1) where are the sources you try to build? (especially POM)
2) what is the failure? dependency resolution fails as missing a
dependency or what?
3) check for network failures on your side, and repeat builds with -U to
force maven to try again (the fact that a dep was not found is cached)


Thanks,
~t~

On Fri, Dec 10, 2010 at 1:22 PM, Mate Varga mate.va...@gmail.com wrote:

 Hi,

 I'm pretty new to Java and Maven, so my question may be very naive
 and/or stupid, apologies for that.
 I'm trying to compile an open-source project (if that matters, it's
 https://plugins.atlassian.com/plugin/details/4832 ), which is supposed
 to be built with Maven. I've got Maven 3 installed (Apache Maven 3.0.1
 (r1038046; 2010-11-23 10:58:32+)). This pretty small project
 depends on a larger one (Atlassian JIRA), which has some Maven
 support, but the public repos are not well maintained, and there are a
 lot of broken dependencies, therefore the dependency resolution
 process fails.
 However, I have all of the first level (direct) dependencies resolved.
 As far as my knowledge goes, it's enough to have the first level
 dependencies to compile a Java project, and that's exactly what I
 want. Is there a way to tell Maven to stop resolving 2 level
 dependencies, and just try compiling the project? I tried to Google
 for this, no luck; and the guides on mvn dependency resolution don't
 help either.

 Thanks,
 Mate

 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org

Re: Limiting dependency resolution depth

Hello Tamas,

1) Sources are checked out from SVN to the local drive.
2) Yes, missing dependencies. The problems stem from things like
missing maven-metadata files in the public repos. (I've checked that,
the repo maintainers do know about the inconsistencies, but they
refuse to fix it.)
3) I've done all of that, and I've manually checked the online repos
-- the dependency chain is broken, -U, :purge-local-repository does
not help, and my network connection is all right.

I could go and fetch all the required jars/wars/etc. manually and
deploy them into my internal repo, but I want to avoid that if it's
possible.

Udv,
Mate


2010/12/10 Tamás Cservenák ta...@cservenak.net:
 Hi,

 Okay, but to be able to help, we need more:

 1) where are the sources you try to build? (especially POM)
 2) what is the failure? dependency resolution fails as missing a
 dependency or what?
 3) check for network failures on your side, and repeat builds with -U to
 force maven to try again (the fact that a dep was not found is cached)


 Thanks,
 ~t~

 On Fri, Dec 10, 2010 at 1:22 PM, Mate Varga mate.va...@gmail.com wrote:

 Hi,

 I'm pretty new to Java and Maven, so my question may be very naive
 and/or stupid, apologies for that.
 I'm trying to compile an open-source project (if that matters, it's
 https://plugins.atlassian.com/plugin/details/4832 ), which is supposed
 to be built with Maven. I've got Maven 3 installed (Apache Maven 3.0.1
 (r1038046; 2010-11-23 10:58:32+)). This pretty small project
 depends on a larger one (Atlassian JIRA), which has some Maven
 support, but the public repos are not well maintained, and there are a
 lot of broken dependencies, therefore the dependency resolution
 process fails.
 However, I have all of the first level (direct) dependencies resolved.
 As far as my knowledge goes, it's enough to have the first level
 dependencies to compile a Java project, and that's exactly what I
 want. Is there a way to tell Maven to stop resolving 2 level
 dependencies, and just try compiling the project? I tried to Google
 for this, no luck; and the guides on mvn dependency resolution don't
 help either.

 Thanks,
 Mate

 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Limiting dependency resolution depth

2010-12-10 Thread Wendy Smoak

On Fri, Dec 10, 2010 at 7:22 AM, Mate Varga mate.va...@gmail.com wrote:
 However, I have all of the first level (direct) dependencies resolved.
 As far as my knowledge goes, it's enough to have the first level
 dependencies to compile a Java project,

Not necessarily... it depends on whether the project developers are
relying on transitive dependencies to bring in other stuff they need.

For example, I can declare a dependency on Struts and then use
BeanUtils classes in my code, because I know the Struts dependency
will give me BeanUtils transitively.

In any case, you can't just 'turn off' transitive dependency
resolution in Maven.

You mentioned you have an internal repo already, so if the maintainers
of the remote repos you're trying to pull from won't cooperate, put
the needed artifacts in your own repo and you'll be good to go.

-- 
Wendy

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Limiting dependency resolution depth

Thanks.

 You mentioned you have an internal repo already, so if the maintainers
 of the remote repos you're trying to pull from won't cooperate, put
 the needed artifacts in your own repo and you'll be good to go.

Yeah, that's what I wanted to avoid. I will do it if there is no other
way, but I find it a bit annoying that it is not possible to cut off
the dependency chain at a certain point.


 For example, I can declare a dependency on Struts and then use
 BeanUtils classes in my code, because I know the Struts dependency
 will give me BeanUtils transitively.

Well, my view is that if you're directly referencing a type, then it
should be a direct dependency in your project -- because the project's
dependencies are not part of the interface, e.g. if Struts' deps get
changed, then your project might break even the interface remains the
same.


 In any case, you can't just 'turn off' transitive dependency
 resolution in Maven.

:(

Thanks,

Mate

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Maven create JAR

2010-12-10 Thread madeOfStarStuff


Thanks for the reply.  The problem is that NO .class files are being included
in the .jar file.
-- 
View this message in context: 
http://maven.40175.n5.nabble.com/Maven-create-JAR-tp3300215p3300312.html
Sent from the Maven - Users mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Limiting dependency resolution depth

2010-12-10 Thread Stefan Seidel

Hi Mate,

you can, as a workaround, download the pom.xml of your dependency and copy 
those dependencies into your own pom.xml (or another one which only contains 
those). Then change/add the scope of all those dependencies to provided, 
which should effectively disable deeper dependency resolution.

Stefan

On Fri, 10 Dec 2010 12:56:49 +
Mate Varga mate.va...@gmail.com wrote:

 Hello Tamas,
 
 1) Sources are checked out from SVN to the local drive.
 2) Yes, missing dependencies. The problems stem from things like
 missing maven-metadata files in the public repos. (I've checked that,
 the repo maintainers do know about the inconsistencies, but they
 refuse to fix it.)
 3) I've done all of that, and I've manually checked the online repos
 -- the dependency chain is broken, -U, :purge-local-repository does
 not help, and my network connection is all right.
 
 I could go and fetch all the required jars/wars/etc. manually and
 deploy them into my internal repo, but I want to avoid that if it's
 possible.
 
 Udv,
 Mate
 
 
 2010/12/10 Tamás Cservenák ta...@cservenak.net:
  Hi,
 
  Okay, but to be able to help, we need more:
 
  1) where are the sources you try to build? (especially POM)
  2) what is the failure? dependency resolution fails as missing a
  dependency or what?
  3) check for network failures on your side, and repeat builds with -U to
  force maven to try again (the fact that a dep was not found is cached)
 
 
  Thanks,
  ~t~
 
  On Fri, Dec 10, 2010 at 1:22 PM, Mate Varga mate.va...@gmail.com wrote:
 
  Hi,
 
  I'm pretty new to Java and Maven, so my question may be very naive
  and/or stupid, apologies for that.
  I'm trying to compile an open-source project (if that matters, it's
  https://plugins.atlassian.com/plugin/details/4832 ), which is supposed
  to be built with Maven. I've got Maven 3 installed (Apache Maven 3.0.1
  (r1038046; 2010-11-23 10:58:32+)). This pretty small project
  depends on a larger one (Atlassian JIRA), which has some Maven
  support, but the public repos are not well maintained, and there are a
  lot of broken dependencies, therefore the dependency resolution
  process fails.
  However, I have all of the first level (direct) dependencies resolved.
  As far as my knowledge goes, it's enough to have the first level
  dependencies to compile a Java project, and that's exactly what I
  want. Is there a way to tell Maven to stop resolving 2 level
  dependencies, and just try compiling the project? I tried to Google
  for this, no luck; and the guides on mvn dependency resolution don't
  help either.
 
  Thanks,
  Mate
 
  -
  To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
  For additional commands, e-mail: users-h...@maven.apache.org
 
 
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org
 


-- 
Mit freundlichen Grüßen,

Stefan Seidel
Software-Entwickler

VUB Printmedia GmbH
Chopinstraße 4, 04103 Leipzig
tel.+49 (341) 9 60 50 93
fax.+49 (341) 9 60 50 92
mail.   ssei...@vub.de 
web.www.vub.de

VUB Printmedia GmbH
HRB Köln 24015
GF Dr. A. Preuss Neudorf, Dr. C. Preuss Neudorf

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Limiting dependency resolution depth

Thanks, that's a good idea.

On Fri, Dec 10, 2010 at 2:07 PM, Stefan Seidel ssei...@vub.de wrote:
 Hi Mate,

 you can, as a workaround, download the pom.xml of your dependency and copy 
 those dependencies into your own pom.xml (or another one which only contains 
 those). Then change/add the scope of all those dependencies to provided, 
 which should effectively disable deeper dependency resolution.

 Stefan

 On Fri, 10 Dec 2010 12:56:49 +
 Mate Varga mate.va...@gmail.com wrote:

 Hello Tamas,

 1) Sources are checked out from SVN to the local drive.
 2) Yes, missing dependencies. The problems stem from things like
 missing maven-metadata files in the public repos. (I've checked that,
 the repo maintainers do know about the inconsistencies, but they
 refuse to fix it.)
 3) I've done all of that, and I've manually checked the online repos
 -- the dependency chain is broken, -U, :purge-local-repository does
 not help, and my network connection is all right.

 I could go and fetch all the required jars/wars/etc. manually and
 deploy them into my internal repo, but I want to avoid that if it's
 possible.

 Udv,
 Mate


 2010/12/10 Tamás Cservenák ta...@cservenak.net:
  Hi,
 
  Okay, but to be able to help, we need more:
 
  1) where are the sources you try to build? (especially POM)
  2) what is the failure? dependency resolution fails as missing a
  dependency or what?
  3) check for network failures on your side, and repeat builds with -U to
  force maven to try again (the fact that a dep was not found is cached)
 
 
  Thanks,
  ~t~
 
  On Fri, Dec 10, 2010 at 1:22 PM, Mate Varga mate.va...@gmail.com wrote:
 
  Hi,
 
  I'm pretty new to Java and Maven, so my question may be very naive
  and/or stupid, apologies for that.
  I'm trying to compile an open-source project (if that matters, it's
  https://plugins.atlassian.com/plugin/details/4832 ), which is supposed
  to be built with Maven. I've got Maven 3 installed (Apache Maven 3.0.1
  (r1038046; 2010-11-23 10:58:32+)). This pretty small project
  depends on a larger one (Atlassian JIRA), which has some Maven
  support, but the public repos are not well maintained, and there are a
  lot of broken dependencies, therefore the dependency resolution
  process fails.
  However, I have all of the first level (direct) dependencies resolved.
  As far as my knowledge goes, it's enough to have the first level
  dependencies to compile a Java project, and that's exactly what I
  want. Is there a way to tell Maven to stop resolving 2 level
  dependencies, and just try compiling the project? I tried to Google
  for this, no luck; and the guides on mvn dependency resolution don't
  help either.
 
  Thanks,
  Mate
 
  -
  To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
  For additional commands, e-mail: users-h...@maven.apache.org
 
 
 

 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org



 --
 Mit freundlichen Grüßen,

 Stefan Seidel
 Software-Entwickler
 
 VUB Printmedia GmbH
 Chopinstraße 4, 04103 Leipzig
 tel.    +49 (341) 9 60 50 93
 fax.    +49 (341) 9 60 50 92
 mail.   ssei...@vub.de
 web.    www.vub.de

 VUB Printmedia GmbH
 HRB Köln 24015
 GF Dr. A. Preuss Neudorf, Dr. C. Preuss Neudorf

 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Limiting dependency resolution depth

2010-12-10 Thread Ron Wheeler

Mate,
You might get more help if you actually provided some details about what
is your build is actually saying and what repos are broken.

Ron

On 10/12/2010 9:07 AM, Stefan Seidel wrote:

Hi Mate,

you can, as a workaround, download the pom.xml of your dependency and copy those dependencies into
your own pom.xml (or another one which only contains those). Then change/add the scope
of all those dependencies to provided, which should effectively disable deeper
dependency resolution.

Stefan

On Fri, 10 Dec 2010 12:56:49 +
Mate Vargamate.va...@gmail.com wrote:

Hello Tamas,

1) Sources are checked out from SVN to the local drive.
2) Yes, missing dependencies. The problems stem from things like
missing maven-metadata files in the public repos. (I've checked that,
the repo maintainers do know about the inconsistencies, but they
refuse to fix it.)
3) I've done all of that, and I've manually checked the online repos
-- the dependency chain is broken, -U, :purge-local-repository does
not help, and my network connection is all right.

I could go and fetch all the required jars/wars/etc. manually and
deploy them into my internal repo, but I want to avoid that if it's
possible.

Udv,
Mate

2010/12/10 Tamás Cservenákta...@cservenak.net:

Hi,

Okay, but to be able to help, we need more:

1) where are the sources you try to build? (especially POM)
2) what is the failure? dependency resolution fails as missing a
dependency or what?
3) check for network failures on your side, and repeat builds with -U to
force maven to try again (the fact that a dep was not found is cached)

Thanks,
~t~

On Fri, Dec 10, 2010 at 1:22 PM, Mate Vargamate.va...@gmail.com wrote:

Hi,

I'm pretty new to Java and Maven, so my question may be very naive
and/or stupid, apologies for that.
I'm trying to compile an open-source project (if that matters, it's
https://plugins.atlassian.com/plugin/details/4832 ), which is supposed
to be built with Maven. I've got Maven 3 installed (Apache Maven 3.0.1
(r1038046; 2010-11-23 10:58:32+)). This pretty small project
depends on a larger one (Atlassian JIRA), which has some Maven
support, but the public repos are not well maintained, and there are a
lot of broken dependencies, therefore the dependency resolution
process fails.
However, I have all of the first level (direct) dependencies resolved.
As far as my knowledge goes, it's enough to have the first level
dependencies to compile a Java project, and that's exactly what I
want. Is there a way to tell Maven to stop resolving2 level
dependencies, and just try compiling the project? I tried to Google
for this, no luck; and the guides on mvn dependency resolution don't
help either.

Thanks,
Mate

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Maven create JAR

Yes. Did you try removing the includes part of you config? You're actually
telling the jar-plugin to only include the spring-context.xml file. No
wonder there are no .class files included.

/Anders

On Fri, Dec 10, 2010 at 14:54, madeOfStarStuff solksjae...@hotmail.comwrote:


 Thanks for the reply.  The problem is that NO .class files are being
 included
 in the .jar file.
 --
 View this message in context:
 http://maven.40175.n5.nabble.com/Maven-create-JAR-tp3300215p3300312.html
 Sent from the Maven - Users mailing list archive at Nabble.com.

 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org

Re: Limiting dependency resolution depth

Ron,

I didn't want to dump mvn output here -- I know what the problem is,
namely that some repositories are not properly set up (for example:
https://maven.atlassian.com/content/repositories/public/com/atlassian/jira/atlassian-jira-webapp/3.12-SNAPSHOT/
-- there is no valid metadata file here, so you can't use this repo as
a proper remote repo). It seemed that a) I deploy the jars manually b)
I can somehow break the dependency chain. As b) is not (really)
possible, I've got to do a).

Mate

On Fri, Dec 10, 2010 at 2:21 PM, Ron Wheeler
rwhee...@artifact-software.com wrote:
Mate,
You might get more help if you actually provided some details about what is
your build is actually saying and what repos are broken.

Ron

On 10/12/2010 9:07 AM, Stefan Seidel wrote:

Hi Mate,

you can, as a workaround, download the pom.xml of your dependency and copy
those dependencies into your own pom.xml (or another one which only contains
those). Then change/add the scope of all those dependencies to provided,
which should effectively disable deeper dependency resolution.

Stefan

On Fri, 10 Dec 2010 12:56:49 +
Mate Vargamate.va...@gmail.com wrote:

Hello Tamas,

I could go and fetch all the required jars/wars/etc. manually and
deploy them into my internal repo, but I want to avoid that if it's
possible.

Udv,
Mate

2010/12/10 Tamás Cservenákta...@cservenak.net:

Hi,

Okay, but to be able to help, we need more:

Thanks,
~t~

On Fri, Dec 10, 2010 at 1:22 PM, Mate Vargamate.va...@gmail.com
wrote:

Hi,

Thanks,
Mate

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Limiting dependency resolution depth

2010-12-10 Thread Tamás Cservenák

Hm,

ping Atlassian to clean-up their Nexus ;)

Also, if you specify an exact dependency with some version (let's say the
timestamped one in this repo) in the depMgt of the POM you are building, it
should override all transitive deps your build tries to pull in.

Thanks,
~t~

On Fri, Dec 10, 2010 at 3:44 PM, Mate Varga mate.va...@gmail.com wrote:

Ron,

I didn't want to dump mvn output here -- I know what the problem is,
namely that some repositories are not properly set up (for example:

https://maven.atlassian.com/content/repositories/public/com/atlassian/jira/atlassian-jira-webapp/3.12-SNAPSHOT/
-- there is no valid metadata file here, so you can't use this repo as
a proper remote repo). It seemed that a) I deploy the jars manually b)
I can somehow break the dependency chain. As b) is not (really)
possible, I've got to do a).

Mate

On Fri, Dec 10, 2010 at 2:21 PM, Ron Wheeler
rwhee...@artifact-software.com wrote:
Mate,
You might get more help if you actually provided some details about what
is
your build is actually saying and what repos are broken.

Ron

On 10/12/2010 9:07 AM, Stefan Seidel wrote:

Hi Mate,

you can, as a workaround, download the pom.xml of your dependency and
copy
those dependencies into your own pom.xml (or another one which only
contains
those). Then change/add the scope of all those dependencies to
provided,
which should effectively disable deeper dependency resolution.

Stefan

On Fri, 10 Dec 2010 12:56:49 +
Mate Vargamate.va...@gmail.com wrote:

Hello Tamas,

I could go and fetch all the required jars/wars/etc. manually and
deploy them into my internal repo, but I want to avoid that if it's
possible.

Udv,
Mate

2010/12/10 Tamás Cservenákta...@cservenak.net:

Hi,

Okay, but to be able to help, we need more:

1) where are the sources you try to build? (especially POM)
2) what is the failure? dependency resolution fails as missing a
dependency or what?
3) check for network failures on your side, and repeat builds with -U
to
force maven to try again (the fact that a dep was not found is cached)

Thanks,
~t~

On Fri, Dec 10, 2010 at 1:22 PM, Mate Vargamate.va...@gmail.com
wrote:

Hi,

I'm pretty new to Java and Maven, so my question may be very naive
and/or stupid, apologies for that.
I'm trying to compile an open-source project (if that matters, it's
https://plugins.atlassian.com/plugin/details/4832 ), which is
supposed
to be built with Maven. I've got Maven 3 installed (Apache Maven
3.0.1
(r1038046; 2010-11-23 10:58:32+)). This pretty small project
depends on a larger one (Atlassian JIRA), which has some Maven
support, but the public repos are not well maintained, and there are
a
lot of broken dependencies, therefore the dependency resolution
process fails.
However, I have all of the first level (direct) dependencies
resolved.
As far as my knowledge goes, it's enough to have the first level
dependencies to compile a Java project, and that's exactly what I
want. Is there a way to tell Maven to stop resolving2 level
dependencies, and just try compiling the project? I tried to Google
for this, no luck; and the guides on mvn dependency resolution don't
help either.

Thanks,
Mate

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: How can I tell Hudson to build the modules instead of the jobs?

2010-12-10 Thread Wayne Fay

 Sure, that will work but I was hoping for some kind of setting in
 hudson or the job treat modules as jobs or treat this job's modules
 as jobs.

In that case, wouldn't this conversation be more productive on the
Hudson Users mailing list rather than Maven Users??

Wayne

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

alternating plugin executions in the same phase

2010-12-10 Thread Nick Bonatsakis

Hi Everyone,

I'm attempting the first step of migrating a project from ant to maven and
am running into an issue. Note that I'd ultimately like to solve this by
improving the modularity of the project, but for now, I'm trying to closely
mimic what ant was doing.

I have a collection of SQL scripts and several Java command line utilities.
I need to have these executed all in the pre-integration-tests phase in an
alternating pattern, i.e:

   - maven-sql-plugin - run scripts
   - maven-exec-plugin - run java util
   - maven-sql-plugin - run some more scripts
   - maven-exec-plugin - run a different java util

The problem is that maven will always execute the plugin executions in
groups, all the sqls, then all the execs. I know this entire thing is
counter to the maven way, but can anyone suggest a way to accomplish this?

This is under Maven 2.2.1.

Thanks!

-- 
Nicholas Bonatsakis
Software Engineer

Re: Maven create JAR

2010-12-10 Thread Wayne Fay

                            includes
                                    includespring-context.xml/include
                            /includes

As Anders has told you repeatedly now, this include line in your
config tells Maven to only include the following file(s) in my jar
and that is exactly what Maven is doing.

Remove the include, leave only the excludes, and your classes should
magically appear in the jar file.

Wayne

Re: How can I tell Hudson to build the modules instead of the jobs?

2010-12-10 Thread Laird Nelson

On Fri, Dec 10, 2010 at 10:12 AM, Wayne Fay wayne...@gmail.com wrote:

  Sure, that will work but I was hoping for some kind of setting in
  hudson or the job treat modules as jobs or treat this job's modules
  as jobs.

 In that case, wouldn't this conversation be more productive on the
 Hudson Users mailing list rather than Maven Users??


Goodness.  Andreas, there's a checkbox in the Hudson configuration that says
Build only changed modules.  That will probably do what you want.

Best,
Laird

Re: How can I tell Hudson to build the modules instead of the jobs?

2010-12-10 Thread Andreas Wederbrand

That box doesn't do what I need. Sure, only changed modules get built
(in the same build I might add) but it also makes all other jobs that
have dependencies to any of the modules downstream jobs so commiting
any change to any module will force a complete rebuild of all
dependent modules (and not just dependent on the changed module).

I'll try the hudson list, perhaps it's better there.


On Fri, Dec 10, 2010 at 16:31, Laird Nelson ljnel...@gmail.com wrote:
 On Fri, Dec 10, 2010 at 10:12 AM, Wayne Fay wayne...@gmail.com wrote:

  Sure, that will work but I was hoping for some kind of setting in
  hudson or the job treat modules as jobs or treat this job's modules
  as jobs.

 In that case, wouldn't this conversation be more productive on the
 Hudson Users mailing list rather than Maven Users??


 Goodness.  Andreas, there's a checkbox in the Hudson configuration that says
 Build only changed modules.  That will probably do what you want.

 Best,
 Laird




-- 
Read my blog @ http://www.raven.nu/blog

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

A classpath issue ?


Hi,

I have a maven build that is doing fine on my old linux box.

Trying now to run it in the new iMac environment, I get an issue with a
spring xml file not being found.

It feels like the classpath is not correctly set.

The pom.xml file is:

project xmlns=http://maven.apache.org/POM/4.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd;
modelVersion4.0.0/modelVersion
groupIdcom.thalasoft/groupId
artifactIdlearnintouch/artifactId
packagingpom/packaging
version1.0-SNAPSHOT/version
namelearnintouch/name
urlhttp://www.thalasoft.com/url
modules
modulecore/module
/modules
properties
spring.core.version2.5.6/spring.core.version
hibernate.version3.6.0.Final/hibernate.version
test.source.dirsrc/test/java/test.source.dir
/properties
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-compiler-plugin/artifactId
configuration
source1.6/source
target1.6/target
encodingUTF-8/encoding
/configuration
/plugin
/plugins
testSourceDirectory
  ${test.source.dir}
/testSourceDirectory
/build
  profiles
profile
  iddefault/id
  activation
activeByDefaulttrue/activeByDefault
  /activation
  properties
  /properties
  build
filters
  filtersrc/main/filters/data-source.properties/filter
/filters
resources
resource
  directorysrc/main/resources/directory
  filteringtrue/filtering
/resource
/resources
  /build
/profile
profile
  idintegration-test/id
  properties
test.source.dirsrc/integration/java/test.source.dir
  /properties
  build
filters
  filtersrc/integration/filters/data-source.properties/filter
/filters
resources
resource
  directorysrc/integration/resources/directory
  filteringtrue/filtering
/resource
/resources
  /build
/profile
profile
  idmysql-test/id
  properties
test.source.dirsrc/integration/java/test.source.dir
  /properties
  build
filters
  filtersrc/main/filters/data-source.properties/filter
/filters
resources
resource
  directorysrc/integration/resources/directory
  filteringtrue/filtering
/resource
/resources
  /build
/profile
  /profiles
repositories
repository
idJBoss repository/id

urlhttps://repository.jboss.org/nexus/content/groups/public-jboss/url
/repository
repository
idUsertype/id
urlhttp://repo1.maven.org/maven2/org/jadira/url
/repository
/repositories
dependencyManagement
dependencies
dependency
groupIdjunit/groupId
artifactIdjunit/artifactId
version4.4/version
scopetest/scope
/dependency
dependency
groupIdlog4j/groupId
artifactIdlog4j/artifactId
version1.2.16/version
/dependency
dependency
groupIdjavax.mail/groupId
artifactIdmail/artifactId
version1.4/version
  /dependency
dependency
groupIdjoda-time/groupId
artifactIdjoda-time/artifactId
version1.6/version
/dependency
  dependency
groupIdorg.jadira.usertype/groupId
artifactIdusertype.jodatime/artifactId
version1.7/version
/dependency
dependency
groupIdjavax.transaction/groupId
artifactIdjta/artifactId
version1.1/version
/dependency
dependency
  groupIdorg.hibernate/groupId
  artifactIdhibernate-entitymanager/artifactId
version${hibernate.version}/version
  /dependency
  dependency

Separate executions for maven-compiler-plugin

2010-12-10 Thread lilyevsky


I need help with configuring the maven-compiler-plugin to run compiler twice,
with different set of source roots and/or different settings for
includes/excludes. Based on the documentation, it seemed to be a simple
thing to do, but somehow I cannot make it work.

It started with the other problem I had (see my other post
http://maven.40175.n5.nabble.com/Using-annotationProcessor-in-maven-compiler-plugin-td3298435.html
) . That one I got working, though it feels like magic.
Basically I have a class A.java that uses some special annotation, and I
have an annotation processor that will create another class A1.java based on
A. I also have class B.java that uses A1. Obviously the processor should do
its job before the main compilation. Everything worked with this simple
configuration:


org.apache.maven.plugins
maven-compiler-plugin
2.3.2

1.6
1.6

my_processor




Except one minor annoying thing: while doing the annotation processing, it
tried to compile all classes, including B.java, which uses A1 that does not
exist yet. So it gave a message that looked like an error, but it was not a
stopper for the further processing.
So I thought that in some other situation it may become critical, and I
wanted to solve this problem. I actually need to run the compiler two times: 
1. Do annotation processing, by setting proc=only, and compile only A.java,
with B.java excluded.
2. Compile everything, including A1.java (which is sitting in a different
tree target/generated-sources/annotations), and B.java.

I know that I need to define separate executions, and the manual says that I
can configure default-compile execution. I tried various configurations,
but could not make it work: the default-compile execution could not see the
target/generated-sources/annotations root, no matter what I tried.

I would really appreciate if somebody can give me an example of how this is
done.
-- 
View this message in context: 
http://maven.40175.n5.nabble.com/Separate-executions-for-maven-compiler-plugin-tp3300553p3300553.html
Sent from the Maven - Users mailing list archive at Nabble.com.

Re: A classpath issue ?


The file does exist in the source directory:

stephane:learnintouch$ ll core/src/main/resources/

-rwxr-xr-x  1 stephane  staff   607  9 déc 17:34 spring-data-source.xml

But it is nowhere to be found in the target directory:

stephane:learnintouch$ll core/target/classes/

drwxr-xr-x  3 stephane  staff   102 10 déc 17:43 com
-rw-r--r--  1 stephane  staff  5359 10 déc 17:43 spring-hibernate-dao.xml
-rw-r--r--  1 stephane  staff  2760 10 déc 17:43 spring-hibernate.xml
-rw-r--r--  1 stephane  staff   529 10 déc 17:43 spring-service.xml

stephane:learnintouch$ll core/target/test-classes/

drwxr-xr-x  3 stephane  staff  102 10 déc 17:43 com

stephane:learnintouch$

The file has not been copied into the target directory.

Strange..
-- 
View this message in context: 
http://maven.40175.n5.nabble.com/A-classpath-issue-tp3300543p3300609.html
Sent from the Maven - Users mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: A classpath issue ?


I'm running the following version of maven:

stephane:learnintouch/$ mvn -version
Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200)
Java version: 1.6.0_22
Java home: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
Default locale: fr_FR, platform encoding: MacRoman
OS name: mac os x version: 10.6.5 arch: x86_64 Family: mac
-- 
View this message in context: 
http://maven.40175.n5.nabble.com/A-classpath-issue-tp3300543p3300635.html
Sent from the Maven - Users mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Can't resolve dependency with version range

On Thu, Dec 9, 2010 at 11:37 PM, Anders Hammar and...@hammar.net wrote:
 Did you try forcing an update (-U) with Maven 2? I don't know if that
 should have worked, but I would have tried it...

Interestingly, today it is working, even without a -U or anything.

I wonder if there is some kind of time frame where Maven 2.x won't
look at remote repo until a certain time has passed.  I could
understand that kind of behavior for snapshots, but I don't understand
doing it for version ranges.

Phillip

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Can't resolve dependency with version range

I tried starting from scratch with similar steps that I was using to
reproduce it yesterday, and now I can't reproduce it anymore.

But if I do reproduce it again, I'll try the -U option to see if it helps :)

Phillip

On Fri, Dec 10, 2010 at 10:11 AM, Phillip Hellewell ssh...@gmail.com wrote:
 On Thu, Dec 9, 2010 at 11:37 PM, Anders Hammar and...@hammar.net wrote:
 Did you try forcing an update (-U) with Maven 2? I don't know if that
 should have worked, but I would have tried it...

 Interestingly, today it is working, even without a -U or anything.

 I wonder if there is some kind of time frame where Maven 2.x won't
 look at remote repo until a certain time has passed.  I could
 understand that kind of behavior for snapshots, but I don't understand
 doing it for version ranges.

 Phillip


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Cleanup to SNAPSHOT version handling

2010-12-10 Thread Benjamin Bentmann


Hi,

as part of MNG-4893 [0] an inconsistency in the way a version string is 
treated as a snapshot or release was detected. In short, the issue is 
about what suffix exactly marks a snapshot version.


The current intention is to revise the logic such that the suffix 
-SNAPSHOT (note the leading hyphen) and not just SNAPSHOT is 
required to denote a snapshot.


This mail is meant as a heads up for users that unintentionally use 
irregular SNAPSHOT versioning and allow them to adjust their builds. If 
changing the builds to use -SNAPSHOT isn't possible, we would like to 
hear the technical reasons for this.


Thanks


Benjamin


[0] http://jira.codehaus.org/browse/MNG-4893

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Reasonable use of profiles?

2010-12-10 Thread KARR, DAVID (ATTSI)

I've heard talk about the debatable value of profiles, and I wanted to
describe one use I might have for profiles, although I'm still in the
initial stages of converting a large Ant environment to Maven, so things
may change.  I'd appreciate any comments.

I think one basic reason that profiles become useful is that we can't
control every aspect of our environment.

This environment as I describe it, consists of a large enterprise web
application, although there are actually 2-3 different EARS that are
built for different but related purposes.  The applications are composed
of a bunch of modules that are divided on functional and team boundaries
(front-end Java, back-end Java, web modules, middleware, et cetera).

When developers build the present system, they have to check out all of
the modules that contribute to the EAR, and they have to check them out
with their default name, because the build has hard-coded references to
the directory names.

The work for each release, about every month, is done on a branch named
for that release.  If the work for a release includes changes in a
particular module, then that module is branched so that developers can
do the work required for it.  Developers often have to do some work on
more than one branch, in the same module.

So, in order to do a complete Ant build, you have to have all the
required module names checked out with their default names.  Some
modules can do unit and even integration unit testing without building
the EAR (back-end and middleware modules), so that doesn't require
checking out the module with the default name.

A typical strategy is to create separate Eclipse workspaces, each of
which has all the required modules checked out, but for different
branches.  Personally, I find it a pain to switch workspaces in Eclipse,
because I have a lot of modules, and startup takes quite a while.  As a
result, I often end up checking out many modules with a name like
default-branchname, especially if I don't have to build the EAR
with that module, but just be able to inspect the code, or get
unit/integration tests working.

So, in converting this to Maven, I envision an almost 1-1 correspondence
between the Ant projects and Maven projects, except the build project
will just run the build (previously, we had sort of a chain system,
where module builds chained to the next required module), and ear
projects will specify just the needed dependencies and the assembly
phase, not to mention a parent POM or two.

I want to allow for the possibility of not requiring modules to be
checked out with their default names, so I want to have module
references that reference property values, instead of hardcoded names.
It seems to me that if I define a profile in my settings.xml that
corresponds to a branch, I can define the property values for each
module name, and then I can either specify the profile on the command
line, or if I'm working for a few hours on one branch, I can just change
the default profile.  I think this can work.

Another desire I have is to allow for developers not even building most
of the modules, and just letting the ear project pull snapshot
artifacts from the Nexus repo (built by the release team or continuous
integration).  I could do this with multiple build projects, including
different sets of module elements.  That seems messy, however.  I wish
I had different options for setting that up, perhaps in a profile, but I
don't see how that could work.

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Reasonable use of profiles?

2010-12-10 Thread Kalle Korhonen

On Fri, Dec 10, 2010 at 9:20 AM, KARR, DAVID (ATTSI) dk0...@att.com wrote:
 Another desire I have is to allow for developers not even building most
 of the modules, and just letting the ear project pull snapshot
 artifacts from the Nexus repo (built by the release team or continuous
 integration).  I could do this with multiple build projects, including
 different sets of module elements.  That seems messy, however.  I wish
 I had different options for setting that up, perhaps in a profile, but I
 don't see how that could work.

Overall, I'd say this sounds better than trying to (mis-)use profiles.
Nothing you said indicates to me that the EARs are functionally
equivalent, and therefore I'd create different modules for different
EARs. One of the Maven ground rules is one artifact per module.
Typically you deviate from that plan only if you need to build
different versions of the same module (packaged differently, for
different OSes/JVMs etc.) and often you use profiles for the desired
effect. I'd further say using profiles should never be your first
option. Reserve profiles for the time you really need them.

Since you are going to re-work the build, I'd mercilessly refactor it
into a modular build now. Since Maven is so good at versioning things,
your build doesn't have to be monolithic. Snapshots are ok, but it's
far better if you can identify common, stable areas of the codebase
and simply release them separately. Then your top-level builds are
mostly assembling things together rather than compiling/building them.
Personally, I'd put my efforts on making the build modular, automating
version migration and doing more continuous integration  testing
rather than trying to force Maven the same logic as your Ant build.
Depending on the size of the project and your team, it would likely be
beneficial to pay somebody who really knows Maven to assist you in the
migration at this point (if you can get it approved, I know how it
is). It would save you from a lot of grief later.

Kalle

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Reasonable use of profiles?

I'd second the very good points that Kalle made.  To add some practical 
experience from this end, I just last night learned the power of using the 
module element within a profile element...

 profiles
 profile
 idall/id
 modules
 moduleweb/module
 modulecore/module
 modulemessaging/module
 modulesecurity/module
 /modules
 /profile
 profile
 idweb/id
 modules
 moduleweb/module
 modulemessaging/module
 modulesecurity/module
 /modules
 /profile
 profile
 idcore/id
 modules
 modulecore/module
 modulemessaging/module
 modulesecurity/module
 /modules
 /profile
 /profiles

I use Spring for the IoC container on my projects, and in an optional project 
for core, have a stubbed command bean that is defined once in the web project, 
then with a full implementation again in the core project, but with the 
primary attribute on the bean definition set to true.  This transparently 
overrides the central command message interface with a real implementation, 
connecting the two projects together at runtime.  

The messaging and security projects are obviously needed by either project, 
whether they run separately or together.  The messaging project contains the 
message classes that are sent to the stub or the core depending on what gets 
loaded, and the core project accepts those messages, thus creating a dependency 
from both.

Brian


On Dec 10, 2010, at 12:57 PM, Kalle Korhonen wrote:

 On Fri, Dec 10, 2010 at 9:20 AM, KARR, DAVID (ATTSI) dk0...@att.com wrote:
 Another desire I have is to allow for developers not even building most
 of the modules, and just letting the ear project pull snapshot
 artifacts from the Nexus repo (built by the release team or continuous
 integration).  I could do this with multiple build projects, including
 different sets of module elements.  That seems messy, however.  I wish
 I had different options for setting that up, perhaps in a profile, but I
 don't see how that could work.
 
 Overall, I'd say this sounds better than trying to (mis-)use profiles.
 Nothing you said indicates to me that the EARs are functionally
 equivalent, and therefore I'd create different modules for different
 EARs. One of the Maven ground rules is one artifact per module.
 Typically you deviate from that plan only if you need to build
 different versions of the same module (packaged differently, for
 different OSes/JVMs etc.) and often you use profiles for the desired
 effect. I'd further say using profiles should never be your first
 option. Reserve profiles for the time you really need them.
 
 Since you are going to re-work the build, I'd mercilessly refactor it
 into a modular build now. Since Maven is so good at versioning things,
 your build doesn't have to be monolithic. Snapshots are ok, but it's
 far better if you can identify common, stable areas of the codebase
 and simply release them separately. Then your top-level builds are
 mostly assembling things together rather than compiling/building them.
 Personally, I'd put my efforts on making the build modular, automating
 version migration and doing more continuous integration  testing
 rather than trying to force Maven the same logic as your Ant build.
 Depending on the size of the project and your team, it would likely be
 beneficial to pay somebody who really knows Maven to assist you in the
 migration at this point (if you can get it approved, I know how it
 is). It would save you from a lot of grief later.
 
 Kalle
 
 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org
 
 


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: alternating plugin executions in the same phase

2010-12-10 Thread Hilco Wijbenga

On 10 December 2010 07:18, Nick Bonatsakis nbonatsa...@gmail.com wrote:
 I'm attempting the first step of migrating a project from ant to maven and
 am running into an issue. Note that I'd ultimately like to solve this by
 improving the modularity of the project, but for now, I'm trying to closely
 mimic what ant was doing.

I tried this strategy when I was doing what you're trying to do. In my
opinion, for any fairly sizable project moving from Ant to Maven
directly is much harder than (at least partially) modularizing your
code base first. What we did was extract the easy modules first and
break up the build that way. Eventually, the hard modules became
easy (or at least easier) too.

The very first step is to simply call your Ant build from Maven. Then
you add the Maven Ant tasks to your Ant build so you can depend on the
modules/JARs/projects that you are going to extract. As you progress,
you'll have less and less Ant and more and more Maven.

You have a number of options. You can either build a multi-module
build with Maven or have your modules be separate projects with their
own release cycles. I very much prefer the latter but it's totally up
to you. Naturally, you can combine the two approaches: some single
module projects and some multi-module projects.

With this small-steps approach, I believe you'll be much more likely
to succeed than with a big-bang approach where you all of a sudden do
everything in Maven. I started with the big-bang approach but was
quickly overwhelmed by the complexity of the build. So I created a
script that could run the current build and the current build + a
small change to compare the results. From then on, I could make
changes to the build and be reasonably sure I had not broken anything.
An added benefit was that everybody was using the same build so
everything was out in the open and I could easily keep up with any
other changes that were occasionally needed.

 I have a collection of SQL scripts and several Java command line utilities.
 I need to have these executed all in the pre-integration-tests phase in an
 alternating pattern, i.e:

   - maven-sql-plugin - run scripts
   - maven-exec-plugin - run java util
   - maven-sql-plugin - run some more scripts
   - maven-exec-plugin - run a different java util

 The problem is that maven will always execute the plugin executions in
 groups, all the sqls, then all the execs. I know this entire thing is
 counter to the maven way, but can anyone suggest a way to accomplish this?

If you follow my suggestions above, this should no longer be an issue.
Otherwise, there's always the maven-antrun-plugin.

Good luck,
Hilco

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

RE: Reasonable use of profiles?

2010-12-10 Thread KARR, DAVID (ATTSI)

 -Original Message-
 From: Kalle Korhonen [mailto:kalle.o.korho...@gmail.com]
 Sent: Friday, December 10, 2010 9:58 AM
 To: Maven Users List
 Subject: Re: Reasonable use of profiles?

 On Fri, Dec 10, 2010 at 9:20 AM, KARR, DAVID (ATTSI) dk0...@att.com
 wrote:
  Another desire I have is to allow for developers not even building
 most
  of the modules, and just letting the ear project pull snapshot
  artifacts from the Nexus repo (built by the release team or
 continuous
  integration).  I could do this with multiple build projects,
 including
  different sets of module elements.  That seems messy, however.  I
 wish
  I had different options for setting that up, perhaps in a profile,
 but I
  don't see how that could work.

 Overall, I'd say this sounds better than trying to (mis-)use profiles.
 Nothing you said indicates to me that the EARs are functionally
 equivalent, and therefore I'd create different modules for different
 EARs. One of the Maven ground rules is one artifact per module.
 Typically you deviate from that plan only if you need to build
 different versions of the same module (packaged differently, for
 different OSes/JVMs etc.) and often you use profiles for the desired
 effect. I'd further say using profiles should never be your first
 option. Reserve profiles for the time you really need them.

To clarify the use case I'm talking about here, let's say the EAR requires 20 
principal artifacts to construct the EAR (not to mention the numerous 
third-party dependencies).  These have a 1-1 correspondence to modules.  Some 
developers will work on one set of those modules (one or more), and other 
developers will work on other sets.  No developers will work on all of the 
modules, but all developers need all of the produced artifacts in order to 
produce an EAR.  So, if I only do work on one module, I could produce a build 
project that just has two modules, the module I work on, and the EAR module.  
I would get the other artifacts from the Nexus repo.  Other developers would 
have to use a different build project, with a different set of modules, 
including the EAR module.  Other developers would have a build project with a 
still different set of modules, including the EAR module.

From what I can tell, my only option is to create these numerous very similar 
build projects, all with different permutations of the available modules.  
Release management would never use these, these are just for developers.

I'm simply looking for a better way to manage this.  I envision if I somehow 
had a list property, consisting of module names, defined in settings.xml, a 
developer could easily add or subtract from this list, and a single build 
project would use that property.  I just don't know how to get something like 
this to work with Maven.

 Since you are going to re-work the build, I'd mercilessly refactor it
 into a modular build now. Since Maven is so good at versioning things,
 your build doesn't have to be monolithic. Snapshots are ok, but it's
 far better if you can identify common, stable areas of the codebase
 and simply release them separately. Then your top-level builds are
 mostly assembling things together rather than compiling/building them.
 Personally, I'd put my efforts on making the build modular, automating
 version migration and doing more continuous integration  testing
 rather than trying to force Maven the same logic as your Ant build.
 Depending on the size of the project and your team, it would likely be
 beneficial to pay somebody who really knows Maven to assist you in the
 migration at this point (if you can get it approved, I know how it
 is). It would save you from a lot of grief later.

What I have the leeway to produce is a structure that is compatible with Maven, 
but will still work with the Ant build.  I can't bring down the entire 
development process while I single-handedly construct the Maven infrastructure. 
 It was hard enough to get permission to even examine Maven.  Each of our 
individual projects will produce a single artifact, whether from Ant or Maven, 
and the responsibility for assembling the EAR is now separated into a separate 
build project.  That will allow me to integrate Maven with less pain after 
the slightly transformed Ant build is working.

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

RE: Reasonable use of profiles?

2010-12-10 Thread KARR, DAVID (ATTSI)

 -Original Message-
 From: Brian Topping [mailto:topp...@codehaus.org]
 Sent: Friday, December 10, 2010 10:13 AM
 To: Maven Users List
 Subject: Re: Reasonable use of profiles?

 I'd second the very good points that Kalle made.  To add some
practical
 experience from this end, I just last night learned the power of using
 the module element within a profile element...

  profiles
  profile
  idall/id
  modules
  moduleweb/module
  modulecore/module
  modulemessaging/module
  modulesecurity/module
  /modules
  /profile
  profile
  idweb/id
  modules
  moduleweb/module
  modulemessaging/module
  modulesecurity/module
  /modules
  /profile
  profile
  idcore/id
  modules
  modulecore/module
  modulemessaging/module
  modulesecurity/module
  /modules
  /profile
  /profiles

Interesting.  This could go into the build project POM, but if a
developer needed a custom list of modules, they could define that in
their settings.xml.  I guess that could work for what I'm looking for.

 On Dec 10, 2010, at 12:57 PM, Kalle Korhonen wrote:

  On Fri, Dec 10, 2010 at 9:20 AM, KARR, DAVID (ATTSI)
dk0...@att.com
 wrote:
  Another desire I have is to allow for developers not even building
 most
  of the modules, and just letting the ear project pull snapshot
  artifacts from the Nexus repo (built by the release team or
 continuous
  integration).  I could do this with multiple build projects,
 including
  different sets of module elements.  That seems messy, however.  I
 wish
  I had different options for setting that up, perhaps in a profile,
 but I
  don't see how that could work.

  Overall, I'd say this sounds better than trying to (mis-)use
 profiles.
  Nothing you said indicates to me that the EARs are functionally
  equivalent, and therefore I'd create different modules for different
  EARs. One of the Maven ground rules is one artifact per module.
  Typically you deviate from that plan only if you need to build
  different versions of the same module (packaged differently, for
  different OSes/JVMs etc.) and often you use profiles for the desired
  effect. I'd further say using profiles should never be your first
  option. Reserve profiles for the time you really need them.

  Since you are going to re-work the build, I'd mercilessly refactor
it
  into a modular build now. Since Maven is so good at versioning
 things,
  your build doesn't have to be monolithic. Snapshots are ok, but it's
  far better if you can identify common, stable areas of the codebase
  and simply release them separately. Then your top-level builds are
  mostly assembling things together rather than compiling/building
 them.
  Personally, I'd put my efforts on making the build modular,
 automating
  version migration and doing more continuous integration  testing
  rather than trying to force Maven the same logic as your Ant build.
  Depending on the size of the project and your team, it would likely
 be
  beneficial to pay somebody who really knows Maven to assist you in
 the
  migration at this point (if you can get it approved, I know how it
  is). It would save you from a lot of grief later.

  Kalle

-
  To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
  For additional commands, e-mail: users-h...@maven.apache.org

 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

RE: Reasonable use of profiles?

2010-12-10 Thread Yanko, Curtis

An area we've been successful with in using profiles is to distinguish
between local builds and CI build to toggle Fat v Skinny WARs



Curt Yanko | Continuous Integration Services | UnitedHealth Group IT 
Making IT Happen, one build at a time, 600 times a day
 

 -Original Message-
 From: KARR, DAVID (ATTSI) [mailto:dk0...@att.com] 
 Sent: Friday, December 10, 2010 12:20 PM
 To: Maven Users List
 Subject: Reasonable use of profiles?
 
 I've heard talk about the debatable value of profiles, and I 
 wanted to describe one use I might have for profiles, 
 although I'm still in the initial stages of converting a 
 large Ant environment to Maven, so things may change.  I'd 
 appreciate any comments.
 
 I think one basic reason that profiles become useful is that 
 we can't control every aspect of our environment.
 
 This environment as I describe it, consists of a large 
 enterprise web application, although there are actually 2-3 
 different EARS that are built for different but related 
 purposes.  The applications are composed of a bunch of 
 modules that are divided on functional and team boundaries 
 (front-end Java, back-end Java, web modules, middleware, et cetera).
 
 When developers build the present system, they have to check 
 out all of the modules that contribute to the EAR, and they 
 have to check them out with their default name, because the 
 build has hard-coded references to the directory names.
 
 The work for each release, about every month, is done on a 
 branch named for that release.  If the work for a release 
 includes changes in a particular module, then that module is 
 branched so that developers can do the work required for it.  
 Developers often have to do some work on more than one 
 branch, in the same module.
 
 So, in order to do a complete Ant build, you have to have all 
 the required module names checked out with their default 
 names.  Some modules can do unit and even integration unit 
 testing without building the EAR (back-end and middleware 
 modules), so that doesn't require checking out the module 
 with the default name.
 
 A typical strategy is to create separate Eclipse workspaces, 
 each of which has all the required modules checked out, but 
 for different branches.  Personally, I find it a pain to 
 switch workspaces in Eclipse, because I have a lot of 
 modules, and startup takes quite a while.  As a result, I 
 often end up checking out many modules with a name like 
 default-branchname, especially if I don't have to build 
 the EAR with that module, but just be able to inspect the 
 code, or get unit/integration tests working.
 
 So, in converting this to Maven, I envision an almost 1-1 
 correspondence between the Ant projects and Maven projects, 
 except the build project will just run the build 
 (previously, we had sort of a chain system, where module 
 builds chained to the next required module), and ear
 projects will specify just the needed dependencies and the 
 assembly phase, not to mention a parent POM or two.
 
 I want to allow for the possibility of not requiring modules 
 to be checked out with their default names, so I want to 
 have module references that reference property values, 
 instead of hardcoded names.
 It seems to me that if I define a profile in my settings.xml 
 that corresponds to a branch, I can define the property 
 values for each module name, and then I can either specify 
 the profile on the command line, or if I'm working for a few 
 hours on one branch, I can just change the default profile.  
 I think this can work.
 
 Another desire I have is to allow for developers not even 
 building most of the modules, and just letting the ear 
 project pull snapshot artifacts from the Nexus repo (built by 
 the release team or continuous integration).  I could do this 
 with multiple build projects, including different sets of 
 module elements.  That seems messy, however.  I wish I had 
 different options for setting that up, perhaps in a profile, 
 but I don't see how that could work.
 
 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org
 
 

This e-mail, including attachments, may include confidential and/or
proprietary information, and may be used only by the person or entity
to which it is addressed. If the reader of this e-mail is not the intended
recipient or his or her authorized agent, the reader is hereby notified
that any dissemination, distribution or copying of this e-mail is
prohibited. If you have received this e-mail in error, please notify the
sender by replying to this message and delete this e-mail immediately.


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Reasonable use of profiles?


On Dec 10, 2010, at 1:30 PM, KARR, DAVID (ATTSI) wrote:

 Interesting.  This could go into the build project POM, but if a
 developer needed a custom list of modules, they could define that in
 their settings.xml.  I guess that could work for what I'm looking for.


It's not possible to put the module element in settings.xml, if that's what 
you are thinking.  But given that you can specify multiple profiles for a build 
and individual profile IDs can be used in multiple projects, you might consider 
making a different profile ID for each root component that made sense to be 
selectable.  IntelliJ lets developers persistently select profiles for a 
project, so it would not be hard to do an a la carte like this without using 
settings.xml.

I am in the midst of getting Nexus and SVN to play nice from LDAP, so developer 
access can be granted or revoked from a UI as a part of their master access 
profile.  Nexus privileges can also be set up for everything but source jars, 
so CI can publish source to Nexus but not everyone can get it.

Nexus isn't hard to set up like this, but getting SVN to work through Atlassian 
Crowd for fine-grained repository access still needs a little work it seems.  
Definitely experiment with this dummy projects before jumping in though, SVN 
authz is not a trivial setup to deploy, get it working and confirm that there 
aren't leaks.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Reverse dependency tree

What is the best tool out for generating a reverse dependency tree?

Also, can anyone give some hints on where to look to set up Hudson or
something else to trigger automatic builds of reverse dependencies
(i.e., continuous integration).  Of course, it would have to not only
build the reverse dependencies, but also update their pom.xml files.

Thanks,
Phillip

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Reverse dependency tree

2010-12-10 Thread Wendy Smoak

On Fri, Dec 10, 2010 at 4:02 PM, Phillip Hellewell ssh...@gmail.com wrote:
 What is the best tool out for generating a reverse dependency tree?

 Also, can anyone give some hints on where to look to set up Hudson or
 something else to trigger automatic builds of reverse dependencies

Apache Archiva (repository manager) has a Used By tab that shows who
has a dependency on the artifact you're viewing.

If you want to build the latest of everything against the latest of
everything else, you might have a look at Apache Gump.  (I haven't
looked but I imagine it has Maven support by now...)

-- 
Wendy

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

RE: Reverse dependency tree

2010-12-10 Thread Yanko, Curtis

We use Sonar and it's Library look up mechanism to do *impact analysis*
if that's what you mean by reverse dependency.

From a build standpoint AnthillPro support both Push and Pull style
dependency triggers. Since we are a CI shop we use Push to trigger the
build of the item(s) that use what we just built and keep pushing on up
the tree.



Curt Yanko | Continuous Integration Services | UnitedHealth Group IT 
Making IT Happen, one build at a time, 600 times a day
 

 -Original Message-
 From: Phillip Hellewell [mailto:ssh...@gmail.com] 
 Sent: Friday, December 10, 2010 4:03 PM
 To: Maven Users List
 Subject: Reverse dependency tree
 
 What is the best tool out for generating a reverse dependency tree?
 
 Also, can anyone give some hints on where to look to set up 
 Hudson or something else to trigger automatic builds of 
 reverse dependencies (i.e., continuous integration).  Of 
 course, it would have to not only build the reverse 
 dependencies, but also update their pom.xml files.
 
 Thanks,
 Phillip
 
 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org
 
 

This e-mail, including attachments, may include confidential and/or
proprietary information, and may be used only by the person or entity
to which it is addressed. If the reader of this e-mail is not the intended
recipient or his or her authorized agent, the reader is hereby notified
that any dissemination, distribution or copying of this e-mail is
prohibited. If you have received this e-mail in error, please notify the
sender by replying to this message and delete this e-mail immediately.


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Can't resolve dependency with version range

On Fri, Dec 10, 2010 at 10:16 AM, Phillip Hellewell ssh...@gmail.com wrote:
 I tried starting from scratch with similar steps that I was using to
 reproduce it yesterday, and now I can't reproduce it anymore.

 But if I do reproduce it again, I'll try the -U option to see if it helps :)

I ran into it again, and adding -U sure enough worked.

I don't understand why I should need -U though.  I mean, if it can't
find it in the local repo, of course it ought to look in remote repos,
and most the time it does.  Oh well, whatever is going on appears to
be fixed in Maven 3.x, so I won't worry about it too much.

Phillip

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Can't resolve dependency with version range

Maven 3.0 rocks! :-)

/Anders
On Fri, Dec 10, 2010 at 22:36, Phillip Hellewell ssh...@gmail.com wrote:

 On Fri, Dec 10, 2010 at 10:16 AM, Phillip Hellewell ssh...@gmail.com
 wrote:
  I tried starting from scratch with similar steps that I was using to
  reproduce it yesterday, and now I can't reproduce it anymore.
 
  But if I do reproduce it again, I'll try the -U option to see if it helps
 :)

 I ran into it again, and adding -U sure enough worked.

 I don't understand why I should need -U though.  I mean, if it can't
 find it in the local repo, of course it ought to look in remote repos,
 and most the time it does.  Oh well, whatever is going on appears to
 be fixed in Maven 3.x, so I won't worry about it too much.

 Phillip

 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org

Re: A classpath issue ?

That's because you haven't configured that folder in the profile. This is
what you have configured:

   resources
   resource
 directorysrc/integration/
resources/directory
 filteringtrue/filtering
   /resource
   /resources

This replaces the resources section defined outside the profiles.

Execute this and check the effective pom:
mvn help:effective-pom -P integration-test

/Anders
On Fri, Dec 10, 2010 at 17:16, Stephane-3 mittiprove...@yahoo.se wrote:


 Hi,

 I have a maven build that is doing fine on my old linux box.

 Trying now to run it in the new iMac environment, I get an issue with a
 spring xml file not being found.

 It feels like the classpath is not correctly set.

 The pom.xml file is:

 project xmlns=http://maven.apache.org/POM/4.0.0;
 xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
 http://maven.apache.org/maven-v4_0_0.xsd;
modelVersion4.0.0/modelVersion
groupIdcom.thalasoft/groupId
artifactIdlearnintouch/artifactId
packagingpom/packaging
version1.0-SNAPSHOT/version
namelearnintouch/name
urlhttp://www.thalasoft.com/url
modules
modulecore/module
/modules
properties
spring.core.version2.5.6/spring.core.version
hibernate.version3.6.0.Final/hibernate.version
test.source.dirsrc/test/java/test.source.dir
/properties
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId

  artifactIdmaven-compiler-plugin/artifactId
configuration
source1.6/source
target1.6/target
encodingUTF-8/encoding
/configuration
/plugin
/plugins
testSourceDirectory
  ${test.source.dir}
/testSourceDirectory
/build
  profiles
profile
  iddefault/id
  activation
activeByDefaulttrue/activeByDefault
  /activation
  properties
  /properties
  build
filters
  filtersrc/main/filters/data-source.properties/filter
/filters
resources
resource
  directorysrc/main/resources/directory
  filteringtrue/filtering
/resource
/resources
  /build
/profile
profile
  idintegration-test/id
  properties
test.source.dirsrc/integration/java/test.source.dir
  /properties
  build
filters
  filtersrc/integration/filters/data-source.properties/filter
/filters
resources
resource
  directorysrc/integration/resources/directory
  filteringtrue/filtering
/resource
/resources
  /build
/profile
profile
  idmysql-test/id
  properties
test.source.dirsrc/integration/java/test.source.dir
  /properties
  build
filters
  filtersrc/main/filters/data-source.properties/filter
/filters
resources
resource
  directorysrc/integration/resources/directory
  filteringtrue/filtering
/resource
/resources
  /build
/profile
  /profiles
repositories
repository
idJBoss repository/id
url
 https://repository.jboss.org/nexus/content/groups/public-jboss/url
/repository
repository
idUsertype/id
urlhttp://repo1.maven.org/maven2/org/jadira/url
/repository
/repositories
dependencyManagement
dependencies
dependency
groupIdjunit/groupId
artifactIdjunit/artifactId
version4.4/version
scopetest/scope
/dependency
dependency
groupIdlog4j/groupId
artifactIdlog4j/artifactId
version1.2.16/version
/dependency
dependency
groupIdjavax.mail/groupId
artifactIdmail/artifactId
version1.4/version
  /dependency
dependency
groupIdjoda-time/groupId
artifactIdjoda-time/artifactId
version1.6/version
/dependency
  dependency
groupIdorg.jadira.usertype/groupId
artifactIdusertype.jodatime/artifactId
version1.7/version
/dependency

Re: A classpath issue ?

Hmm, I now see that you say it works on Linux. Maybe the resources section
outside the profiles isn't being replaced but added to? Check the effective
pom and you'll know for sure.

/Anders

On Fri, Dec 10, 2010 at 22:52, Anders Hammar and...@hammar.net wrote:

 That's because you haven't configured that folder in the profile. This is
 what you have configured:


resources
resource
  directorysrc/integration/
 resources/directory
  filteringtrue/filtering
/resource
/resources

 This replaces the resources section defined outside the profiles.

 Execute this and check the effective pom:
 mvn help:effective-pom -P integration-test

 /Anders

 On Fri, Dec 10, 2010 at 17:16, Stephane-3 mittiprove...@yahoo.se wrote:


 Hi,

 I have a maven build that is doing fine on my old linux box.

 Trying now to run it in the new iMac environment, I get an issue with a
 spring xml file not being found.

 It feels like the classpath is not correctly set.

 The pom.xml file is:

 project xmlns=http://maven.apache.org/POM/4.0.0;
 xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
 http://maven.apache.org/maven-v4_0_0.xsd;
modelVersion4.0.0/modelVersion
groupIdcom.thalasoft/groupId
artifactIdlearnintouch/artifactId
packagingpom/packaging
version1.0-SNAPSHOT/version
namelearnintouch/name
urlhttp://www.thalasoft.com/url
modules
modulecore/module
/modules
properties
spring.core.version2.5.6/spring.core.version
hibernate.version3.6.0.Final/hibernate.version
test.source.dirsrc/test/java/test.source.dir
/properties
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId

  artifactIdmaven-compiler-plugin/artifactId
configuration
source1.6/source
target1.6/target
encodingUTF-8/encoding
/configuration
/plugin
/plugins
testSourceDirectory
  ${test.source.dir}
/testSourceDirectory
/build
  profiles
profile
  iddefault/id
  activation
activeByDefaulttrue/activeByDefault
  /activation
  properties
  /properties
  build
filters
  filtersrc/main/filters/data-source.properties/filter
/filters
resources
resource
  directorysrc/main/resources/directory
  filteringtrue/filtering
/resource
/resources
  /build
/profile
profile
  idintegration-test/id
  properties
test.source.dirsrc/integration/java/test.source.dir
  /properties
  build
filters
  filtersrc/integration/filters/data-source.properties/filter
/filters
resources
resource
  directorysrc/integration/resources/directory
  filteringtrue/filtering
/resource
/resources
  /build
/profile
profile
  idmysql-test/id
  properties
test.source.dirsrc/integration/java/test.source.dir
  /properties
  build
filters
  filtersrc/main/filters/data-source.properties/filter
/filters
resources
resource
  directorysrc/integration/resources/directory
  filteringtrue/filtering
/resource
/resources
  /build
/profile
  /profiles
repositories
repository
idJBoss repository/id
url
 https://repository.jboss.org/nexus/content/groups/public-jboss/url
/repository
repository
idUsertype/id
urlhttp://repo1.maven.org/maven2/org/jadira
 /url
/repository
/repositories
dependencyManagement
dependencies
dependency
groupIdjunit/groupId
artifactIdjunit/artifactId
version4.4/version
scopetest/scope
/dependency
dependency
groupIdlog4j/groupId
artifactIdlog4j/artifactId
version1.2.16/version
/dependency
dependency
groupIdjavax.mail/groupId
artifactIdmail/artifactId
version1.4/version
  /dependency
dependency
groupIdjoda-time/groupId
artifactIdjoda-time/artifactId

Re: Reasonable use of profiles?

I very much second Kalle here.
Stay away from profiles as much as possible - most often they are used in
the wrong way. Also, if you're migrating a large system I would very much
recommend that you get someone with good Maven knowledge to help you get
things right. I very often come to projects where some senior developer has
created a Maven build setup which is just completely wrong. Having to
refactor that costs possibly two-three times more than doing it right from
the beginning. It often also upsets the developers as they often have to
change the way they work.

/Anders

On Fri, Dec 10, 2010 at 18:57, Kalle Korhonen kalle.o.korho...@gmail.comwrote:

 On Fri, Dec 10, 2010 at 9:20 AM, KARR, DAVID (ATTSI) dk0...@att.com
 wrote:
  Another desire I have is to allow for developers not even building most
  of the modules, and just letting the ear project pull snapshot
  artifacts from the Nexus repo (built by the release team or continuous
  integration).  I could do this with multiple build projects, including
  different sets of module elements.  That seems messy, however.  I wish
  I had different options for setting that up, perhaps in a profile, but I
  don't see how that could work.

 Overall, I'd say this sounds better than trying to (mis-)use profiles.
 Nothing you said indicates to me that the EARs are functionally
 equivalent, and therefore I'd create different modules for different
 EARs. One of the Maven ground rules is one artifact per module.
 Typically you deviate from that plan only if you need to build
 different versions of the same module (packaged differently, for
 different OSes/JVMs etc.) and often you use profiles for the desired
 effect. I'd further say using profiles should never be your first
 option. Reserve profiles for the time you really need them.

 Since you are going to re-work the build, I'd mercilessly refactor it
 into a modular build now. Since Maven is so good at versioning things,
 your build doesn't have to be monolithic. Snapshots are ok, but it's
 far better if you can identify common, stable areas of the codebase
 and simply release them separately. Then your top-level builds are
 mostly assembling things together rather than compiling/building them.
 Personally, I'd put my efforts on making the build modular, automating
 version migration and doing more continuous integration  testing
 rather than trying to force Maven the same logic as your Ant build.
 Depending on the size of the project and your team, it would likely be
 beneficial to pay somebody who really knows Maven to assist you in the
 migration at this point (if you can get it approved, I know how it
 is). It would save you from a lot of grief later.

 Kalle

 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org

Re: Reasonable use of profiles?

2010-12-10 Thread Peter Schuller

 I very much second Kalle here.
 Stay away from profiles as much as possible - most often they are used in
 the wrong way. Also, if you're migrating a large system I would very much
 recommend that you get someone with good Maven knowledge to help you get
 things right. I very often come to projects where some senior developer has
 created a Maven build setup which is just completely wrong. Having to
 refactor that costs possibly two-three times more than doing it right from
 the beginning. It often also upsets the developers as they often have to
 change the way they work.

So on that topic, is there good material that covers doing it right?
I've read the sonatype maven book and while it's good as far as it
goes, it doesn't really cover the intended workflows in various
situations and the intent of various abstractions. Googling is kind of
problematic because there is a lot of cargo cult information floating
around.

Is there a book of other material that truly goes through the intended
way to deploy Maven in an organization,  including not just stuff like
here's how you install nexus, but things like release management,
the relationship between maven release management and VCS tagging,
what to do about multiple branches of development, etc, etc.

Suppose you want to build an eco-system of tens or hundreds of
projects in an organization and deploy/build them scalably (in terms
of administration/build costs) using maven in a clean and maintainable
fashion without hacks or non-idiomatic mistakes. What material does
one preferably read?

-- 
/ Peter Schuller

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Reasonable use of profiles?

2010-12-10 Thread Kalle Korhonen

Beyond the basics and the core principles, it's difficult to write
down the exact instructions for a large scale deployment and use of
Maven because the situations are vastly different. Even if one would
document the best practices for some particular situations, the issue
for the novice is identifying the right case for your situation.
Between the company's SCM of choice, preferred branching patterns
(release / feature branches), development velocity, maturity of the
codebase, the type of software (libraries, service, pre-packaged apps)
and programming languages used (plain Java, native libs w/ OS-specific
languages, scripting), development methodology etc. there are too many
variations to be able to confidently arrive at an optimal solution
just by reading about it. For somebody with experience though, it's
typically simple to re-organize even larger builds to follow best
practices in a matter of few days. However, you often end up spending
much much longer in real time, because first, you want to go at it
alone and second, you always discount the level of resistance to
change.

Kalle


On Fri, Dec 10, 2010 at 2:19 PM, Peter Schuller
peter.schul...@infidyne.com wrote:
 I very much second Kalle here.
 Stay away from profiles as much as possible - most often they are used in
 the wrong way. Also, if you're migrating a large system I would very much
 recommend that you get someone with good Maven knowledge to help you get
 things right. I very often come to projects where some senior developer has
 created a Maven build setup which is just completely wrong. Having to
 refactor that costs possibly two-three times more than doing it right from
 the beginning. It often also upsets the developers as they often have to
 change the way they work.

 So on that topic, is there good material that covers doing it right?
 I've read the sonatype maven book and while it's good as far as it
 goes, it doesn't really cover the intended workflows in various
 situations and the intent of various abstractions. Googling is kind of
 problematic because there is a lot of cargo cult information floating
 around.

 Is there a book of other material that truly goes through the intended
 way to deploy Maven in an organization,  including not just stuff like
 here's how you install nexus, but things like release management,
 the relationship between maven release management and VCS tagging,
 what to do about multiple branches of development, etc, etc.

 Suppose you want to build an eco-system of tens or hundreds of
 projects in an organization and deploy/build them scalably (in terms
 of administration/build costs) using maven in a clean and maintainable
 fashion without hacks or non-idiomatic mistakes. What material does
 one preferably read?

 --
 / Peter Schuller

 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Can't resolve dependency with version range

On Fri, Dec 10, 2010 at 2:45 PM, Anders Hammar and...@hammar.net wrote:
 Maven 3.0 rocks! :-)

Would you recommend it in a production environment?

Phillip

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re : A classpath issue ?


I just ran the following command, on the Linux box:

mvn help:effective-pom -Pintegration-test

And it gives the following output:

  
sourceDirectory/home/stephane/dev/java/project/learnintouch/src/main/java/sourceDirectory^M

  scriptSourceDirectorysrc/main/scripts/scriptSourceDirectory^M
  
testSourceDirectory/home/stephane/dev/java/project/learnintouch/src/integration/java/testSourceDirectory^M

  
outputDirectory/home/stephane/dev/java/project/learnintouch/target/classes/outputDirectory^M

  
testOutputDirectory/home/stephane/dev/java/project/learnintouch/target/test-classes/testOutputDirectory^M

  resources^M
resource^M
  filteringtrue/filtering^M
  mergeIdresource-0/mergeId^M
  
directory/home/stephane/dev/java/project/learnintouch/src/main/resources/directory^M

/resource^M
resource^M
  filteringtrue/filtering^M
  mergeIdresource-1/mergeId^M
  
directory/home/stephane/dev/java/project/learnintouch/src/integration/resources/directory^M

/resource^M
  /resources^M
  testResources^M
testResource^M
  mergeIdresource-2/mergeId^M
  
directory/home/stephane/dev/java/project/learnintouch/src/test/resources/directory^M

/testResource^M
  /testResources^M
  directory/home/stephane/dev/java/project/learnintouch/target/directory

I shall now run it on the iMac machine.








De : Anders Hammar [via Maven] ml-node+3301035-833614543-63...@n5.nabble.com
À : Stephane-3 mittiprove...@yahoo.se
Envoyé le : Ven 10 décembre 2010, 22h 55min 14s
Objet : Re: A classpath issue ?

Hmm, I now see that you say it works on Linux. Maybe the resources section 
outside the profiles isn't being replaced but added to? Check the effective 
pom and you'll know for sure. 

/Anders 

On Fri, Dec 10, 2010 at 22:52, Anders Hammar [hidden email] wrote: 


 That's because you haven't configured that folder in the profile. This is 
 what you have configured: 
 
 
resources 
resource 
  directorysrc/integration/ 
 resources/directory 
  filteringtrue/filtering 
/resource 
/resources 
 
 This replaces the resources section defined outside the profiles. 
 
 Execute this and check the effective pom: 
 mvn help:effective-pom -P integration-test 
 
 /Anders 
 
 On Fri, Dec 10, 2010 at 17:16, Stephane-3 [hidden email] wrote: 
 
 
 Hi, 
 
 I have a maven build that is doing fine on my old linux box. 
 
 Trying now to run it in the new iMac environment, I get an issue with a 
 spring xml file not being found. 
 
 It feels like the classpath is not correctly set. 
 
 The pom.xml file is: 
 
 project xmlns=http://maven.apache.org/POM/4.0.0; 
 xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; 
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
 http://maven.apache.org/maven-v4_0_0.xsd; 
modelVersion4.0.0/modelVersion 
groupIdcom.thalasoft/groupId 
artifactIdlearnintouch/artifactId 
packagingpom/packaging 
version1.0-SNAPSHOT/version 
namelearnintouch/name 
urlhttp://www.thalasoft.com/url 
modules 
modulecore/module 
/modules 
properties 
spring.core.version2.5.6/spring.core.version 
hibernate.version3.6.0.Final/hibernate.version 
test.source.dirsrc/test/java/test.source.dir 
/properties 
build 
plugins 
plugin 
groupIdorg.apache.maven.plugins/groupId 
 
  artifactIdmaven-compiler-plugin/artifactId 
configuration 
source1.6/source 
target1.6/target 
encodingUTF-8/encoding 
/configuration 
/plugin 
/plugins 
testSourceDirectory 
  ${test.source.dir} 
/testSourceDirectory 
/build 
  profiles 
profile 
  iddefault/id 
  activation 
activeByDefaulttrue/activeByDefault 
  /activation 
  properties 
  /properties 
  build 
filters 
  filtersrc/main/filters/data-source.properties/filter 
/filters 
resources 
resource 
  directorysrc/main/resources/directory 
  filteringtrue/filtering 
/resource 
/resources 
  /build 
/profile 
profile 
  idintegration-test/id 
  properties 
test.source.dirsrc/integration/java/test.source.dir 
  /properties 
  build 
filters 
  filtersrc/integration/filters/data-source.properties/filter 
/filters 
resources 
resource 
  directorysrc/integration/resources/directory 
  filteringtrue/filtering 
/resource

Re : A classpath issue ?


And the same command on the iMac machine:

 
 
sourceDirectory/Users/stephane/dev/java/projects/learnintouch/core/src/main/java/sourceDirectory

  scriptSourceDirectorysrc/main/scripts/scriptSourceDirectory
 
 
testSourceDirectory/Users/stephane/dev/java/projects/learnintouch/core/src/integration/java/testSourceDirectory

 
 
outputDirectory/Users/stephane/dev/java/projects/learnintouch/core/target/classes/outputDirectory

 
 
testOutputDirectory/Users/stephane/dev/java/projects/learnintouch/core/target/test-classes/testOutputDirectory

  resources
resource
  filteringtrue/filtering
  mergeIdresource-2/mergeId
 
 
directory/Users/stephane/dev/java/projects/learnintouch/core/src/integration/resources/directory

/resource
  /resources
  testResources
testResource
  mergeIdresource-3/mergeId
 
 
directory/Users/stephane/dev/java/projects/learnintouch/core/src/test/resources/directory

/testResource
  /testResources
 
 
directory/Users/stephane/dev/java/projects/learnintouch/core/target/directory


Indeed, the standard resources directory is missing.







De : Anders Hammar [via Maven] ml-node+3301035-833614543-63...@n5.nabble.com
À : Stephane-3 mittiprove...@yahoo.se
Envoyé le : Ven 10 décembre 2010, 22h 55min 14s
Objet : Re: A classpath issue ?

Hmm, I now see that you say it works on Linux. Maybe the resources section 
outside the profiles isn't being replaced but added to? Check the effective 
pom and you'll know for sure. 

/Anders 

On Fri, Dec 10, 2010 at 22:52, Anders Hammar [hidden email] wrote: 


 That's because you haven't configured that folder in the profile. This is 
 what you have configured: 
 
 
resources 
resource 
  directorysrc/integration/ 
 resources/directory 
  filteringtrue/filtering 
/resource 
/resources 
 
 This replaces the resources section defined outside the profiles. 
 
 Execute this and check the effective pom: 
 mvn help:effective-pom -P integration-test 
 
 /Anders 
 
 On Fri, Dec 10, 2010 at 17:16, Stephane-3 [hidden email] wrote: 
 
 
 Hi, 
 
 I have a maven build that is doing fine on my old linux box. 
 
 Trying now to run it in the new iMac environment, I get an issue with a 
 spring xml file not being found. 
 
 It feels like the classpath is not correctly set. 
 
 The pom.xml file is: 
 
 project xmlns=http://maven.apache.org/POM/4.0.0; 
 xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; 
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
 http://maven.apache.org/maven-v4_0_0.xsd; 
modelVersion4.0.0/modelVersion 
groupIdcom.thalasoft/groupId 
artifactIdlearnintouch/artifactId 
packagingpom/packaging 
version1.0-SNAPSHOT/version 
namelearnintouch/name 
urlhttp://www.thalasoft.com/url 
modules 
modulecore/module 
/modules 
properties 
spring.core.version2.5.6/spring.core.version 
hibernate.version3.6.0.Final/hibernate.version 
test.source.dirsrc/test/java/test.source.dir 
/properties 
build 
plugins 
plugin 
groupIdorg.apache.maven.plugins/groupId 
 
  artifactIdmaven-compiler-plugin/artifactId 
configuration 
source1.6/source 
target1.6/target 
encodingUTF-8/encoding 
/configuration 
/plugin 
/plugins 
testSourceDirectory 
  ${test.source.dir} 
/testSourceDirectory 
/build 
  profiles 
profile 
  iddefault/id 
  activation 
activeByDefaulttrue/activeByDefault 
  /activation 
  properties 
  /properties 
  build 
filters 
  filtersrc/main/filters/data-source.properties/filter 
/filters 
resources 
resource 
  directorysrc/main/resources/directory 
  filteringtrue/filtering 
/resource 
/resources 
  /build 
/profile 
profile 
  idintegration-test/id 
  properties 
test.source.dirsrc/integration/java/test.source.dir 
  /properties 
  build 
filters 
  filtersrc/integration/filters/data-source.properties/filter 
/filters 
resources 
resource 
  directorysrc/integration/resources/directory 
  filteringtrue/filtering 
/resource 
/resources 
  /build 
/profile 
profile 
  idmysql-test/id 
  properties 
test.source.dirsrc/integration/java/test.source.dir 
  /properties 
  build 
filters 
  filtersrc/main/filters/data-source.properties/filter

Re : A classpath issue ?


And, again on the iMac, if this time I don't specify the integration-test 
profile on the command line

mvn help:effective-pom

I get

 
 
sourceDirectory/Users/stephane/dev/java/projects/learnintouch/core/src/main/java/sourceDirectory

  scriptSourceDirectorysrc/main/scripts/scriptSourceDirectory
 
 
testSourceDirectory/Users/stephane/dev/java/projects/learnintouch/core/src/test/java/testSourceDirectory

 
 
outputDirectory/Users/stephane/dev/java/projects/learnintouch/core/target/classes/outputDirectory

 
 
testOutputDirectory/Users/stephane/dev/java/projects/learnintouch/core/target/test-classes/testOutputDirectory

  resources
resource
  filteringtrue/filtering
  mergeIdresource-2/mergeId
 
 
directory/Users/stephane/dev/java/projects/learnintouch/core/src/main/resources/directory

/resource
  /resources
  testResources
testResource
  mergeIdresource-3/mergeId
 
 
directory/Users/stephane/dev/java/projects/learnintouch/core/src/test/resources/directory

/testResource
  /testResources
 
 
directory/Users/stephane/dev/java/projects/learnintouch/core/target/directory


with the specified profile replacing the standard resources directory.

Stranges this is happening on this OSX maven..






De : Anders Hammar [via Maven] ml-node+3301035-833614543-63...@n5.nabble.com
À : Stephane-3 mittiprove...@yahoo.se
Envoyé le : Ven 10 décembre 2010, 22h 55min 14s
Objet : Re: A classpath issue ?

Hmm, I now see that you say it works on Linux. Maybe the resources section 
outside the profiles isn't being replaced but added to? Check the effective 
pom and you'll know for sure. 

/Anders 

On Fri, Dec 10, 2010 at 22:52, Anders Hammar [hidden email] wrote: 


 That's because you haven't configured that folder in the profile. This is 
 what you have configured: 
 
 
resources 
resource 
  directorysrc/integration/ 
 resources/directory 
  filteringtrue/filtering 
/resource 
/resources 
 
 This replaces the resources section defined outside the profiles. 
 
 Execute this and check the effective pom: 
 mvn help:effective-pom -P integration-test 
 
 /Anders 
 
 On Fri, Dec 10, 2010 at 17:16, Stephane-3 [hidden email] wrote: 
 
 
 Hi, 
 
 I have a maven build that is doing fine on my old linux box. 
 
 Trying now to run it in the new iMac environment, I get an issue with a 
 spring xml file not being found. 
 
 It feels like the classpath is not correctly set. 
 
 The pom.xml file is: 
 
 project xmlns=http://maven.apache.org/POM/4.0.0; 
 xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; 
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
 http://maven.apache.org/maven-v4_0_0.xsd; 
modelVersion4.0.0/modelVersion 
groupIdcom.thalasoft/groupId 
artifactIdlearnintouch/artifactId 
packagingpom/packaging 
version1.0-SNAPSHOT/version 
namelearnintouch/name 
urlhttp://www.thalasoft.com/url 
modules 
modulecore/module 
/modules 
properties 
spring.core.version2.5.6/spring.core.version 
hibernate.version3.6.0.Final/hibernate.version 
test.source.dirsrc/test/java/test.source.dir 
/properties 
build 
plugins 
plugin 
groupIdorg.apache.maven.plugins/groupId 
 
  artifactIdmaven-compiler-plugin/artifactId 
configuration 
source1.6/source 
target1.6/target 
encodingUTF-8/encoding 
/configuration 
/plugin 
/plugins 
testSourceDirectory 
  ${test.source.dir} 
/testSourceDirectory 
/build 
  profiles 
profile 
  iddefault/id 
  activation 
activeByDefaulttrue/activeByDefault 
  /activation 
  properties 
  /properties 
  build 
filters 
  filtersrc/main/filters/data-source.properties/filter 
/filters 
resources 
resource 
  directorysrc/main/resources/directory 
  filteringtrue/filtering 
/resource 
/resources 
  /build 
/profile 
profile 
  idintegration-test/id 
  properties 
test.source.dirsrc/integration/java/test.source.dir 
  /properties 
  build 
filters 
  filtersrc/integration/filters/data-source.properties/filter 
/filters 
resources 
resource 
  directorysrc/integration/resources/directory 
  filteringtrue/filtering 
/resource 
/resources 
  /build 
/profile 
profile 
  idmysql-test/id 
  properties

RE: Reasonable use of profiles?

2010-12-10 Thread Bryan Loofbourrow


  Another desire I have is to allow for developers not even building
 most
  of the modules, and just letting the ear project pull snapshot
  artifacts from the Nexus repo (built by the release team or
 continuous
  integration).  I could do this with multiple build projects,
 including
  different sets of module elements.  That seems messy, however.

You don't need separate projects for this. You just need a bunch of 
developer-facing pom files with different modules lists. They can certainly 
live in the same directory. This is something we definitely take advantage of, 
for producing interesting developer build sets.

This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement,
you may review at http://www.amdocs.com/email_disclaimer.asp

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Reasonable use of profiles?


On Dec 10, 2010, at 8:08 PM, Bryan Loofbourrow wrote:

 You don't need separate projects for this. You just need a bunch of 
 developer-facing pom files with different modules lists. They can certainly 
 live in the same directory. This is something we definitely take advantage 
 of, for producing interesting developer build sets.

What is the semantic difference between multiple POMs and a single POM 
containing the different module lists in profiles?  It seems like the former is 
harder to support because a change outside the module sets requires changing 
every POM.



-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

RE: Reasonable use of profiles?

2010-12-10 Thread Bryan Loofbourrow


 What is the semantic difference between multiple POMs and a single POM 
 containing the different module lists in profiles?  It seems like the former 
 is harder to support because a change outside the module sets requires 
 changing every POM. 

Well, one difference is a separation of developer concerns from the concerns of 
the consumers of your artifacts. This is especially applicable if the pom 
containing the profiles is the parent pom of your project, that actually gets 
deployed to a repository and consumed by those who consume your software.

More subtly, I'd argue that the profiles are magic beans, things for which 
you have to introspect your source code to know what's going on, and not really 
knowing, without extensive examination, whether these profiles have any effect 
on any of the projects in the child tree. In contrast, a developer-facing pom 
is a distinct file whose purpose can be made quite clear at the file system 
level, and whose purpose is unambiguously contained entirely within the file 
itself.

Descending down to the final level of abstract mysticism, I'd also say that the 
profiles represent a last resort in the context of The Maven Way, a thing 
you do not use unless you must. Yes, we use them -- for things like telling the 
build to execute integration tests that depend on the presence of an active 
database whose location you have defined in a settings.xml file. But for a 
trivial purpose like this, they are overkill.

-- Bryan

-Original Message-
From: Brian Topping [mailto:topp...@codehaus.org]
Sent: Friday, December 10, 2010 5:37 PM
To: Maven Users List
Subject: Re: Reasonable use of profiles?


On Dec 10, 2010, at 8:08 PM, Bryan Loofbourrow wrote:

 You don't need separate projects for this. You just need a bunch of 
 developer-facing pom files with different modules lists. They can certainly 
 live in the same directory. This is something we definitely take advantage 
 of, for producing interesting developer build sets.

What is the semantic difference between multiple POMs and a single POM 
containing the different module lists in profiles?  It seems like the former is 
harder to support because a change outside the module sets requires changing 
every POM.



-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org


This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement,
you may review at http://www.amdocs.com/email_disclaimer.asp

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Reasonable use of profiles?

2010-12-10 Thread Ron Wheeler

On 10/12/2010 1:24 PM, KARR, DAVID (ATTSI) wrote:

-Original Message-
From: Kalle Korhonen [mailto:kalle.o.korho...@gmail.com]
Sent: Friday, December 10, 2010 9:58 AM
To: Maven Users List
Subject: Re: Reasonable use of profiles?

On Fri, Dec 10, 2010 at 9:20 AM, KARR, DAVID (ATTSI)dk0...@att.com
wrote:

Another desire I have is to allow for developers not even building

most

of the modules, and just letting the ear project pull snapshot
artifacts from the Nexus repo (built by the release team or

continuous

integration).  I could do this with multiple build projects,

including

different sets of module elements.  That seems messy, however.  I

wish

I had different options for setting that up, perhaps in a profile,

but I

don't see how that could work.

Overall, I'd say this sounds better than trying to (mis-)use profiles.
Nothing you said indicates to me that the EARs are functionally
equivalent, and therefore I'd create different modules for different
EARs. One of the Maven ground rules is one artifact per module.
Typically you deviate from that plan only if you need to build
different versions of the same module (packaged differently, for
different OSes/JVMs etc.) and often you use profiles for the desired
effect. I'd further say using profiles should never be your first
option. Reserve profiles for the time you really need them.

To clarify the use case I'm talking about here, let's say the EAR requires 20 principal artifacts to 
construct the EAR (not to mention the numerous third-party dependencies).  These have a 1-1 correspondence to 
modules.  Some developers will work on one set of those modules (one or more), and other developers will work 
on other sets.  No developers will work on all of the modules, but all developers need all of the produced 
artifacts in order to produce an EAR.  So, if I only do work on one module, I could produce a build project 
that just has two modules, the module I work on, and the EAR module.  I would get the other 
artifacts from the Nexus repo.  Other developers would have to use a different build project, with a 
different set of modules, including the EAR module.  Other developers would have a build project 
with a still different set of modules, including the EAR module.

 From what I can tell, my only option is to create these numerous very similar 
build projects, all with different permutations of the available modules.  
Release management would never use these, these are just for developers.

I'm simply looking for a better way to manage this.  I envision if I somehow had a list property, 
consisting of module names, defined in settings.xml, a developer could easily add or subtract 
from this list, and a single build project would use that property.  I just don't know how to get 
something like this to work with Maven.

Since you are going to re-work the build, I'd mercilessly refactor it
into a modular build now. Since Maven is so good at versioning things,
your build doesn't have to be monolithic. Snapshots are ok, but it's
far better if you can identify common, stable areas of the codebase
and simply release them separately. Then your top-level builds are
mostly assembling things together rather than compiling/building them.
Personally, I'd put my efforts on making the build modular, automating
version migration and doing more continuous integration  testing
rather than trying to force Maven the same logic as your Ant build.
Depending on the size of the project and your team, it would likely be
beneficial to pay somebody who really knows Maven to assist you in the
migration at this point (if you can get it approved, I know how it
is). It would save you from a lot of grief later.

What I have the leeway to produce is a structure that is compatible with Maven, but will 
still work with the Ant build.  I can't bring down the entire development process while I 
single-handedly construct the Maven infrastructure.  It was hard enough to get permission 
to even examine Maven.  Each of our individual projects will produce a single artifact, 
whether from Ant or Maven, and the responsibility for assembling the EAR is now separated 
into a separate build project.  That will allow me to integrate Maven with 
less pain after the slightly transformed Ant build is working.

I am still trying to figure out how your development process is so 
abnormal that the normal Maven way will not work out-of-the-box.

We have over 70 projects that build our portal application that includes 
standalone batch jobs, web services, servlets and portlets.

We use no profiles and have very simple POM files.

I can not see any reason in what I get from reading your description of 
your environment that makes me think you are doing anything so far 
outside normal development projects.
I would suggest that you start with Mavenizing your utilities and then 
convert each project.

I am not sure why this is something that would take very long to do.

Keep it simple.
Stay away

Re: Reasonable use of profiles?

2010-12-10 Thread Ron Wheeler


On 10/12/2010 9:19 PM, Bryan Loofbourrow wrote:

What is the semantic difference between multiple POMs and a single POM containing the 
different module lists in profiles?  It seems like the former is harder to support 
because a change outside the module sets requires changing every POM.

Well, one difference is a separation of developer concerns from the concerns of 
the consumers of your artifacts. This is especially applicable if the pom 
containing the profiles is the parent pom of your project, that actually gets 
deployed to a repository and consumed by those who consume your software.

More subtly, I'd argue that the profiles are magic beans, things for which 
you have to introspect your source code to know what's going on, and not really knowing, 
without extensive examination, whether these profiles have any effect on any of the 
projects in the child tree. In contrast, a developer-facing pom is a distinct file whose 
purpose can be made quite clear at the file system level, and whose purpose is 
unambiguously contained entirely within the file itself.

Descending down to the final level of abstract mysticism, I'd also say that the profiles represent 
a last resort in the context of The Maven Way, a thing you do not use 
unless you must. Yes, we use them -- for things like telling the build to execute integration tests 
that depend on the presence of an active database whose location you have defined in a settings.xml 
file. But for a trivial purpose like this, they are overkill.


+1.

Ron

-- Bryan

-Original Message-
From: Brian Topping [mailto:topp...@codehaus.org]

Sent: Friday, December 10, 2010 5:37 PM
To: Maven Users List
Subject: Re: Reasonable use of profiles?


On Dec 10, 2010, at 8:08 PM, Bryan Loofbourrow wrote:


You don't need separate projects for this. You just need a bunch of developer-facing 
pom files with differentmodules  lists. They can certainly live in the same 
directory. This is something we definitely take advantage of, for producing 
interesting developer build sets.

What is the semantic difference between multiple POMs and a single POM 
containing the different module lists in profiles?  It seems like the former is 
harder to support because a change outside the module sets requires changing 
every POM.



-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org


This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement,
you may review at http://www.amdocs.com/email_disclaimer.asp

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org





-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Re : A classpath issue ?

2010-12-10 Thread Wayne Fay

 And, again on the iMac, if this time I don't specify the integration-test
 profile on the command line

 with the specified profile replacing the standard resources directory.

 Stranges this is happening on this OSX maven..

Run mvn -X help:effective-pom and compare the versions of EVERYTHING.
Surely there is a difference that you just haven't noticed in a plugin
or something.

Once you find the difference, come back and tell us about it.

Wayne

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Reasonable use of profiles?