AW: how can I change ${basedir}
Simple: because I have a project directory with a subdir for IDEA, Together
and (hopefully) Maven, instead of having the project files cluttering around
in the basedir. Therefore it would be nice not to have to change all
settings when moving the project file but only one.
I just wanna know whether this is possible and how it can be achieved.
-- Daniel
-Ursprüngliche Nachricht-
Von: Brett Porter [mailto:[EMAIL PROTECTED]
Gesendet: Donnerstag, 15. April 2004 02:27
An: 'Maven Users List'
Betreff: RE: how can I change ${basedir}
I don't understand why you want this - putting .. In a lot of
places is not that much of a hassle and it is less confusing
that something that looks like a relative path but isn't
because of some magic override.
- Brett
-Original Message-
From: Daniel Frey [mailto:[EMAIL PROTECTED]
Sent: Thursday, 15 April 2004 9:58 AM
To: 'Maven Users List'
Subject: how can I change ${basedir}
I would be interested in the same subject. No response
since over one
year on that?
Daniel
Date: Mon, 17 Mar 2003 15:08:32 -0500
From: Justinus Menzel [EMAIL PROTECTED]
Subject: how can I change ${basedir}
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hi,
I moved project.xml, maven.xml etc. into a seperate build
directory.
Now I have to put a lot of ../ in places. Wouldn't it be
easier to
just say basedir=..
in project.properties:
or
baseDir../baseDir
in the POM.
or
maven -d ..
doesn't change ${basedir}, so I don't really know what it does.
or
project basedir=..
...
/project
(like with ant)
Any idea? Many thanks
Justinus
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
smime.p7s
Description: S/MIME cryptographic signature
RE: how can I change ${basedir}
Its possible to move the project file (I understand why you want that), but
not possible to move basedir. You'll have to edit project.xml and
project.properties to include '..'
Alternatively, you could set myBaseDir=${basedir}/.. And use ${myBaseDir}
instead of ${basedir} in your project.
- Brett
-Original Message-
From: Daniel Frey [mailto:[EMAIL PROTECTED]
Sent: Thursday, 15 April 2004 5:53 PM
To: 'Maven Users List'
Subject: AW: how can I change ${basedir}
Simple: because I have a project directory with a subdir for
IDEA, Together and (hopefully) Maven, instead of having the
project files cluttering around in the basedir. Therefore it
would be nice not to have to change all settings when moving
the project file but only one. I just wanna know whether this
is possible and how it can be achieved.
-- Daniel
-Ursprüngliche Nachricht-
Von: Brett Porter [mailto:[EMAIL PROTECTED]
Gesendet: Donnerstag, 15. April 2004 02:27
An: 'Maven Users List'
Betreff: RE: how can I change ${basedir}
I don't understand why you want this - putting .. In a lot of
places is not that much of a hassle and it is less confusing
that something that looks like a relative path but isn't
because of some magic override.
- Brett
-Original Message-
From: Daniel Frey [mailto:[EMAIL PROTECTED]
Sent: Thursday, 15 April 2004 9:58 AM
To: 'Maven Users List'
Subject: how can I change ${basedir}
I would be interested in the same subject. No response
since over one
year on that?
Daniel
Date: Mon, 17 Mar 2003 15:08:32 -0500
From: Justinus Menzel [EMAIL PROTECTED]
Subject: how can I change ${basedir}
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hi,
I moved project.xml, maven.xml etc. into a seperate build
directory.
Now I have to put a lot of ../ in places. Wouldn't it be
easier to
just say basedir=..
in project.properties:
or
baseDir../baseDir
in the POM.
or
maven -d ..
doesn't change ${basedir}, so I don't really know what it does.
or
project basedir=..
...
/project
(like with ant)
Any idea? Many thanks
Justinus
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: how can I change ${basedir}
Good idea. Thanks a lot.
-- Daniel
-Ursprüngliche Nachricht-
Von: Brett Porter [mailto:[EMAIL PROTECTED]
Gesendet: Donnerstag, 15. April 2004 09:55
An: 'Maven Users List'
Betreff: RE: how can I change ${basedir}
Its possible to move the project file (I understand why you
want that), but not possible to move basedir. You'll have to
edit project.xml and project.properties to include '..'
Alternatively, you could set myBaseDir=${basedir}/.. And use
${myBaseDir} instead of ${basedir} in your project.
- Brett
-Original Message-
From: Daniel Frey [mailto:[EMAIL PROTECTED]
Sent: Thursday, 15 April 2004 5:53 PM
To: 'Maven Users List'
Subject: AW: how can I change ${basedir}
Simple: because I have a project directory with a subdir for IDEA,
Together and (hopefully) Maven, instead of having the project files
cluttering around in the basedir. Therefore it would be nice not to
have to change all settings when moving the project file
but only one.
I just wanna know whether this is possible and how it can
be achieved.
-- Daniel
-Ursprüngliche Nachricht-
Von: Brett Porter [mailto:[EMAIL PROTECTED]
Gesendet: Donnerstag, 15. April 2004 02:27
An: 'Maven Users List'
Betreff: RE: how can I change ${basedir}
I don't understand why you want this - putting .. In a
lot of places
is not that much of a hassle and it is less confusing
that something
that looks like a relative path but isn't because of some magic
override.
- Brett
-Original Message-
From: Daniel Frey [mailto:[EMAIL PROTECTED]
Sent: Thursday, 15 April 2004 9:58 AM
To: 'Maven Users List'
Subject: how can I change ${basedir}
I would be interested in the same subject. No response
since over one
year on that?
Daniel
Date: Mon, 17 Mar 2003 15:08:32 -0500
From: Justinus Menzel
[EMAIL PROTECTED]
Subject: how can I change ${basedir}
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hi,
I moved project.xml, maven.xml etc. into a seperate build
directory.
Now I have to put a lot of ../ in places. Wouldn't it be
easier to
just say basedir=..
in project.properties:
or
baseDir../baseDir
in the POM.
or
maven -d ..
doesn't change ${basedir}, so I don't really know
what it does.
or
project basedir=..
...
/project
(like with ant)
Any idea? Many thanks
Justinus
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Maven - Local inter-project dependencies and Eclipse
According to the docs this should be in version 1.3 Added dependency functionality between projects sandeep --- robevans [EMAIL PROTECTED] wrote: What version of the eclipse plugin is required for this to work? I'm using 1.4 and was expecting to see something like the following in my project's .project.xml: projectDescription ... projects projecteman.infra.jms/project /projects ... /projectDescription The project reference was never created for me. -Original Message- From: Ryan Sonnek [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 14, 2004 11:20 AM To: Maven Users List Subject: RE: Maven - Local inter-project dependencies and Eclipse add the property maven.eclipse.dependency to you're B project.xml and you'll be set. just set the property, regenerate your eclipse .project and .classpath, and project A will be setup as an eclipse dependent project. any code changes in A will be immediately picked up by B. this property should REALLY be documented on the maven site, but unfortunately it's not. ex: dependency groupIdgroupId/groupId artifactIdA/artifactId versionSNAPSHOT/version properties maven.eclipse.dependencytrue/maven.eclipse.dependency /properties /dependency Ryan -Original Message- From: James Shute [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 14, 2004 1:13 PM To: [EMAIL PROTECTED] Subject: Maven - Local inter-project dependencies and Eclipse I'm looking at converting our system over to using Maven and am wondering if anybody can suggest how to set up our projects to do what we want. At a simple level we have 2 projects, A and B, where B depends on A. Currently we have an eclipse project for each, and a project dependency set up in eclipse. Then for our automated build we have a script that parses the eclipse project files, generates Ant build.xml files and goes from there.* From what I've seen so far Maven flips this model on it's head, so we'd generate the eclipse project files from the Maven project.xml. Now I've managed to set up 2 Maven projects so that B depends on the jar generated by A, but this doesn't translate very well into the Eclipse projects. This is mainly because the reference in Eclipse for project A is to the jar built by Maven, not the actual eclipse project A. So if in Eclipse I make a change in project A that affects some code in project B I end up with the red-underlining errors, and no amount of Rebuild All in Eclipse sorts it - I have to go and do the Maven build. This isn't exactly ideal - it does mean that the usage of Eclipse is less intuitive than it used to be - I've got to sell this change to a team of developers who'll definitely moan about this! Can anybody think of a way to set this up? Or would it require an enhancement to be made to the eclipse plugin to generate the reference in the .classpath as a project ref rather than a jar? thanks in advance James * for those of you wondering why we do this, the script basically does things like parsing the ant results to build up a set of web pages / mail the dev team if there are errors etc. All these things seem to be things that Maven plugins can do for us, so it seems sensible to move to a standard product, rather than a custom perl script _ Use MSN Messenger to send music and pics to your friends http://www.msn.co.uk/messenger - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Tax Center - File online by April 15th http://taxes.yahoo.com/filing.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Maven - Local inter-project dependencies and Eclipse
Actually I looked at the source code and it is eclipse.dependency not maven.eclipse.dependency. it works for me and my plugin says 1.6 sandeep --- Sandeep Takhar [EMAIL PROTECTED] wrote: According to the docs this should be in version 1.3 Added dependency functionality between projects sandeep --- robevans [EMAIL PROTECTED] wrote: What version of the eclipse plugin is required for this to work? I'm using 1.4 and was expecting to see something like the following in my project's .project.xml: projectDescription ... projects projecteman.infra.jms/project /projects ... /projectDescription The project reference was never created for me. -Original Message- From: Ryan Sonnek [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 14, 2004 11:20 AM To: Maven Users List Subject: RE: Maven - Local inter-project dependencies and Eclipse add the property maven.eclipse.dependency to you're B project.xml and you'll be set. just set the property, regenerate your eclipse .project and .classpath, and project A will be setup as an eclipse dependent project. any code changes in A will be immediately picked up by B. this property should REALLY be documented on the maven site, but unfortunately it's not. ex: dependency groupIdgroupId/groupId artifactIdA/artifactId versionSNAPSHOT/version properties maven.eclipse.dependencytrue/maven.eclipse.dependency /properties /dependency Ryan -Original Message- From: James Shute [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 14, 2004 1:13 PM To: [EMAIL PROTECTED] Subject: Maven - Local inter-project dependencies and Eclipse I'm looking at converting our system over to using Maven and am wondering if anybody can suggest how to set up our projects to do what we want. At a simple level we have 2 projects, A and B, where B depends on A. Currently we have an eclipse project for each, and a project dependency set up in eclipse. Then for our automated build we have a script that parses the eclipse project files, generates Ant build.xml files and goes from there.* From what I've seen so far Maven flips this model on it's head, so we'd generate the eclipse project files from the Maven project.xml. Now I've managed to set up 2 Maven projects so that B depends on the jar generated by A, but this doesn't translate very well into the Eclipse projects. This is mainly because the reference in Eclipse for project A is to the jar built by Maven, not the actual eclipse project A. So if in Eclipse I make a change in project A that affects some code in project B I end up with the red-underlining errors, and no amount of Rebuild All in Eclipse sorts it - I have to go and do the Maven build. This isn't exactly ideal - it does mean that the usage of Eclipse is less intuitive than it used to be - I've got to sell this change to a team of developers who'll definitely moan about this! Can anybody think of a way to set this up? Or would it require an enhancement to be made to the eclipse plugin to generate the reference in the .classpath as a project ref rather than a jar? thanks in advance James * for those of you wondering why we do this, the script basically does things like parsing the ant results to build up a set of web pages / mail the dev team if there are errors etc. All these things seem to be things that Maven plugins can do for us, so it seems sensible to move to a standard product, rather than a custom perl script _ Use MSN Messenger to send music and pics to your friends http://www.msn.co.uk/messenger - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Tax Center - File online by April 15th http://taxes.yahoo.com/filing.html - To
attainGoal
What do exactly the attainGoal tag?? I can't found some documentation about it. Someone can help me??? Raphael Philipe Mendes da Silva DSB - Diretoria de Soluções em Billing CPqD Telecom IT Solutions Tel.: +55 19 3705-6957 www.cpqd.com.br [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Maven - Local inter-project dependencies and Eclipse
My initial problem was caused by the bad artifact properties. -Original Message- From: Sandeep Takhar [mailto:[EMAIL PROTECTED] Sent: Thursday, April 15, 2004 5:23 AM To: Maven Users List Subject: RE: Maven - Local inter-project dependencies and Eclipse Actually I looked at the source code and it is eclipse.dependency not maven.eclipse.dependency. it works for me and my plugin says 1.6 sandeep --- Sandeep Takhar [EMAIL PROTECTED] wrote: According to the docs this should be in version 1.3 Added dependency functionality between projects sandeep --- robevans [EMAIL PROTECTED] wrote: What version of the eclipse plugin is required for this to work? I'm using 1.4 and was expecting to see something like the following in my project's .project.xml: projectDescription ... projects projecteman.infra.jms/project /projects ... /projectDescription The project reference was never created for me. -Original Message- From: Ryan Sonnek [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 14, 2004 11:20 AM To: Maven Users List Subject: RE: Maven - Local inter-project dependencies and Eclipse add the property maven.eclipse.dependency to you're B project.xml and you'll be set. just set the property, regenerate your eclipse .project and .classpath, and project A will be setup as an eclipse dependent project. any code changes in A will be immediately picked up by B. this property should REALLY be documented on the maven site, but unfortunately it's not. ex: dependency groupIdgroupId/groupId artifactIdA/artifactId versionSNAPSHOT/version properties maven.eclipse.dependencytrue/maven.eclipse.dependency /properties /dependency Ryan -Original Message- From: James Shute [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 14, 2004 1:13 PM To: [EMAIL PROTECTED] Subject: Maven - Local inter-project dependencies and Eclipse I'm looking at converting our system over to using Maven and am wondering if anybody can suggest how to set up our projects to do what we want. At a simple level we have 2 projects, A and B, where B depends on A. Currently we have an eclipse project for each, and a project dependency set up in eclipse. Then for our automated build we have a script that parses the eclipse project files, generates Ant build.xml files and goes from there.* From what I've seen so far Maven flips this model on it's head, so we'd generate the eclipse project files from the Maven project.xml. Now I've managed to set up 2 Maven projects so that B depends on the jar generated by A, but this doesn't translate very well into the Eclipse projects. This is mainly because the reference in Eclipse for project A is to the jar built by Maven, not the actual eclipse project A. So if in Eclipse I make a change in project A that affects some code in project B I end up with the red-underlining errors, and no amount of Rebuild All in Eclipse sorts it - I have to go and do the Maven build. This isn't exactly ideal - it does mean that the usage of Eclipse is less intuitive than it used to be - I've got to sell this change to a team of developers who'll definitely moan about this! Can anybody think of a way to set this up? Or would it require an enhancement to be made to the eclipse plugin to generate the reference in the .classpath as a project ref rather than a jar? thanks in advance James * for those of you wondering why we do this, the script basically does things like parsing the ant results to build up a set of web pages / mail the dev team if there are errors etc. All these things seem to be things that Maven plugins can do for us, so it seems sensible to move to a standard product, rather than a custom perl script _ Use MSN Messenger to send music and pics to your friends http://www.msn.co.uk/messenger - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Infamous Junit classloader bug
Hello, Has anyone managed to patch the infamous JUnit classloader bug when running their unit tests with maven ? (the bug is documented here : http://junit.sourceforge.net/doc/faq/faq.htm and fixes are http://www.artima.com/forums/flat.jsp?forum=121thread=7886 and here http://users.rcn.com/scottstirling/2003/07/19.html but it's not been released as a JUnit build yet) Because my unit test cases use the DOM classes, I get the following error when running maven test:test : -- BUILD FAILED File.. file:/C:/Documents and Settings/bcopy/.maven/plugins/maven-test-plugin-1.4/ Element... junit Line.. 94 Column 39 Class org/w3c/dom/Element violates loader constraints Total time: 29 seconds Finished at: Thu Apr 15 16:30:32 CEST 2004 -- I tried to change a few properties here and there, but it's either the taskdefs cannot be found, or this classloader problem. Funny thing, the bug doesn't occur when I launch maven jcoverage - my tests complete succesfully. Has anyone managed to integrate a patch for this bug in the maven classpath ? (I could patch the official junit 3.8.1 JAR file distributed with Maven, but I'd rather not - I know the patch for this bug is in JUnit CVS - but yet unreleased) Thanks for any hints on the subject, Brice - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Infamous Junit classloader bug
The problem mentionned above is solved. I came across http://maven.apache.org/faq.html#unit-test-14 and added maven.junit.fork=yes to my project properties. Perhaps the FAQ could be more precise, and include a sample error message like : Class org/w3c/dom/Element violates loader constraints Cheers Brice - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Maven and Development Process
Hello guys, I am trying to convert our system from Ant to Maven, I managed to succesfully migrate all the projects into Maven but right now i am facing the problem of the development process integration. I saw there is a Snapshot feature that upload the latest build to the repository, but I am not really sure how does it work? From my understanding if i am working on a project composed of several sub-project, like i do, i need to set in each project.xml file the version as x.y-dev and then install the articaft produced as install-snapshot or deploy-snapshot for the remote repo Now in each project that depends on that one, we need to update the version tag of the dependancy to SNAPSHOT and when we build, Maven automatically download the latest snapshot between the 2 that are in the local and remote repo When our development is completed we just need to change all the dependancy version number from snapshot to x.y and the main project.xml version from x.y-dev to x.y as well and there restart the cycle Is it correct or not? There is a better way to handle the development process? Thanks a ton for your help Massimiliano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven and Development Process
Somewhat unfortunately (because it does amount to a lot of work), that is the current best practice, I believe. At any rate, this is exactly what we do. -john On Thu, 2004-04-15 at 12:12, Amato Massimiliano (TLAB) wrote: Hello guys, I am trying to convert our system from Ant to Maven, I managed to succesfully migrate all the projects into Maven but right now i am facing the problem of the development process integration. I saw there is a Snapshot feature that upload the latest build to the repository, but I am not really sure how does it work? From my understanding if i am working on a project composed of several sub-project, like i do, i need to set in each project.xml file the version as x.y-dev and then install the articaft produced as install-snapshot or deploy-snapshot for the remote repo Now in each project that depends on that one, we need to update the version tag of the dependancy to SNAPSHOT and when we build, Maven automatically download the latest snapshot between the 2 that are in the local and remote repo When our development is completed we just need to change all the dependancy version number from snapshot to x.y and the main project.xml version from x.y-dev to x.y as well and there restart the cycle Is it correct or not? There is a better way to handle the development process? Thanks a ton for your help Massimiliano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- John Casey [EMAIL PROTECTED] CommonJava Open Components Project http://www.commonjava.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Maven and Development Process
If you use XML entities to define your version numbers rather than hard coding them in the project.xml files, the process of switching between snapshot and release versions becomes much easier. See http://wiki.codehaus.org/maven/EnsureProjectConsistencyWithEntities for more details. -Original Message- From: John Casey [mailto:[EMAIL PROTECTED] Sent: April 15, 2004 1:46 PM To: Maven Users List Subject: Re: Maven and Development Process Somewhat unfortunately (because it does amount to a lot of work), that is the current best practice, I believe. At any rate, this is exactly what we do. -john On Thu, 2004-04-15 at 12:12, Amato Massimiliano (TLAB) wrote: Hello guys, I am trying to convert our system from Ant to Maven, I managed to succesfully migrate all the projects into Maven but right now i am facing the problem of the development process integration. I saw there is a Snapshot feature that upload the latest build to the repository, but I am not really sure how does it work? From my understanding if i am working on a project composed of several sub-project, like i do, i need to set in each project.xml file the version as x.y-dev and then install the articaft produced as install-snapshot or deploy-snapshot for the remote repo Now in each project that depends on that one, we need to update the version tag of the dependancy to SNAPSHOT and when we build, Maven automatically download the latest snapshot between the 2 that are in the local and remote repo When our development is completed we just need to change all the dependancy version number from snapshot to x.y and the main project.xml version from x.y-dev to x.y as well and there restart the cycle Is it correct or not? There is a better way to handle the development process? Thanks a ton for your help Massimiliano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- John Casey [EMAIL PROTECTED] CommonJava Open Components Project http://www.commonjava.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
multiproject:site issues
Hello. I could swear there have been messages about this on the list but I'm just not sure of the fix for it. I am using rc1 and when I run maven site from the top level of my multiproject I get the following: -- xdoc:generate-from-pom: [echo] Generating xdocs from POM ... BUILD FAILED File.. file:/home/charvey/.maven/plugins/maven-xdoc-plugin-1.5-SNAPSHOT/ Element... velocity:merge Line.. 394 Column 9 null:-1:-1: null null Total time: 5 seconds Finished at: Thu Apr 15 15:02:02 EDT 2004 -- When I run maven multiproject:site I get this: -- multiproject:create-nav: [echo] Producing aggregate navigation... BUILD FAILED File.. file:/home/charvey/.maven/plugins/maven-multiproject-plugin-1.2-SNAPSHOT/ Element... velocity:merge Line.. 119 Column 11 null:-1:-1: null null Total time: 3 seconds Finished at: Thu Apr 15 15:07:53 EDT 2004 -- When I run maven site in a project that isn't multi it runs just fine. If it works in a regular project it makes me think that I'm doing something wrong, but I just don't know what. If anyone has any clues I would be greatful. Charlie P.S. - I tried the same thing with rc2 and got the same errors. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Maven and Development Process
On Thu, 2004-04-15 at 14:38, Mark Langley wrote: If you use XML entities to define your version numbers rather than hard coding them in the project.xml files, the process of switching between snapshot and release versions becomes much easier. See http://wiki.codehaus.org/maven/EnsureProjectConsistencyWithEntities for more details. Do a lot of people actually use this mechanism? Is it simply because maven1 doesn't support recursive inheritance? Maven2 support recursive inheritance well so would anyone still really need to use entities like this. Ultimately I suppose it doesn't matter how the POM comes together but I would like support to come from Maven itself and not the use of entities which I would consider a workaround. -Original Message- From: John Casey [mailto:[EMAIL PROTECTED] Sent: April 15, 2004 1:46 PM To: Maven Users List Subject: Re: Maven and Development Process Somewhat unfortunately (because it does amount to a lot of work), that is the current best practice, I believe. At any rate, this is exactly what we do. -john On Thu, 2004-04-15 at 12:12, Amato Massimiliano (TLAB) wrote: Hello guys, I am trying to convert our system from Ant to Maven, I managed to succesfully migrate all the projects into Maven but right now i am facing the problem of the development process integration. I saw there is a Snapshot feature that upload the latest build to the repository, but I am not really sure how does it work? From my understanding if i am working on a project composed of several sub-project, like i do, i need to set in each project.xml file the version as x.y-dev and then install the articaft produced as install-snapshot or deploy-snapshot for the remote repo Now in each project that depends on that one, we need to update the version tag of the dependancy to SNAPSHOT and when we build, Maven automatically download the latest snapshot between the 2 that are in the local and remote repo When our development is completed we just need to change all the dependancy version number from snapshot to x.y and the main project.xml version from x.y-dev to x.y as well and there restart the cycle Is it correct or not? There is a better way to handle the development process? Thanks a ton for your help Massimiliano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jvz. Jason van Zyl [EMAIL PROTECTED] http://maven.apache.org happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: attainGoal
It's how you call another goal from another goal (or pre/postGoal). For example goal name=myPlugin:myGoal attainGoal name=java:compile/ /goal Here if you run maven myPlugin:myGoal, the java:compile goal will get executed. If you have (in your maven.xml) preGoal name=java:compile attainGoal name=xdoclet:webdoclet/ /preGoal The xdoclet:webdoclet goal will be executed before java:compile is run. Hope that helps Sri -Original Message- From: Raphael Philipe Mendes da Silva [mailto:[EMAIL PROTECTED] Sent: Thursday, April 15, 2004 8:56 AM To: Maven Users List (E-mail) Subject: attainGoal What do exactly the attainGoal tag?? I can't found some documentation about it. Someone can help me??? Raphael Philipe Mendes da Silva DSB - Diretoria de Soluções em Billing CPqD Telecom IT Solutions Tel.: +55 19 3705-6957 www.cpqd.com.br [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Maven and Development Process
Jason, One interesting side-effect of using entities is that if you're importing them from an external source (which, if you're not, what's the point?) then packaging/deploying a pom to the repo will result in an incomplete info set for others d/l'ing that project for a recursive build or recursive resolution... -john On Thu, 2004-04-15 at 16:12, Jason van Zyl wrote: On Thu, 2004-04-15 at 14:38, Mark Langley wrote: If you use XML entities to define your version numbers rather than hard coding them in the project.xml files, the process of switching between snapshot and release versions becomes much easier. See http://wiki.codehaus.org/maven/EnsureProjectConsistencyWithEntities for more details. Do a lot of people actually use this mechanism? Is it simply because maven1 doesn't support recursive inheritance? Maven2 support recursive inheritance well so would anyone still really need to use entities like this. Ultimately I suppose it doesn't matter how the POM comes together but I would like support to come from Maven itself and not the use of entities which I would consider a workaround. -Original Message- From: John Casey [mailto:[EMAIL PROTECTED] Sent: April 15, 2004 1:46 PM To: Maven Users List Subject: Re: Maven and Development Process Somewhat unfortunately (because it does amount to a lot of work), that is the current best practice, I believe. At any rate, this is exactly what we do. -john On Thu, 2004-04-15 at 12:12, Amato Massimiliano (TLAB) wrote: Hello guys, I am trying to convert our system from Ant to Maven, I managed to succesfully migrate all the projects into Maven but right now i am facing the problem of the development process integration. I saw there is a Snapshot feature that upload the latest build to the repository, but I am not really sure how does it work? From my understanding if i am working on a project composed of several sub-project, like i do, i need to set in each project.xml file the version as x.y-dev and then install the articaft produced as install-snapshot or deploy-snapshot for the remote repo Now in each project that depends on that one, we need to update the version tag of the dependancy to SNAPSHOT and when we build, Maven automatically download the latest snapshot between the 2 that are in the local and remote repo When our development is completed we just need to change all the dependancy version number from snapshot to x.y and the main project.xml version from x.y-dev to x.y as well and there restart the cycle Is it correct or not? There is a better way to handle the development process? Thanks a ton for your help Massimiliano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- John Casey [EMAIL PROTECTED] CommonJava Open Components Project http://www.commonjava.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Maven and Development Process
Speaking only for myself - I manage a corporate development environment with 14 developers working on about 30 modules in various stages of legacy maintenance, active development, RD experiments, etc. The set of developers responsible for each module is different, as is the set of dependencies that each project requires. And several modules will often be combined to produce one war artifact, which means that versions of any common dependencies had better match. It's much easier to define employee contact details in developers.ent, a master list of dependencies (internal and external) in dependencies.ent, and then add specific items by reference to each project (e.g.: developerdev-johndoe;/developer and dependencydep-log4j;/dependency). This allows me to maintain details of each item in exactly one place (the .ent file), and have them automatically updated in the 5, 10, or 15 projects that might happen to need them. This is particularly useful for dependencies - I can guarantee that any module using log4j links to version 1.2.8, then enforce that they migrate simultaneously to 1.2.9 with a one-line change. The maintenance time goes way down this way, and as a side benefit our project.xml files are shorter and much more comprehensible. I'm not sure why you would consider entities a workaround - they allow you to define a master list of resources, pick and choose which resources fall into each project, and keep everything synchronized. One could always implement the same capability within Maven, but that seems like unnecessary duplication of effort. The XML parser is giving you this functionality for free - might as well take advantage of it. Mark -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: April 15, 2004 4:13 PM To: Maven Users List Subject: RE: Maven and Development Process On Thu, 2004-04-15 at 14:38, Mark Langley wrote: If you use XML entities to define your version numbers rather than hard coding them in the project.xml files, the process of switching between snapshot and release versions becomes much easier. See http://wiki.codehaus.org/maven/EnsureProjectConsistencyWithEntities for more details. Do a lot of people actually use this mechanism? Is it simply because maven1 doesn't support recursive inheritance? Maven2 support recursive inheritance well so would anyone still really need to use entities like this. Ultimately I suppose it doesn't matter how the POM comes together but I would like support to come from Maven itself and not the use of entities which I would consider a workaround. -Original Message- From: John Casey [mailto:[EMAIL PROTECTED] Sent: April 15, 2004 1:46 PM To: Maven Users List Subject: Re: Maven and Development Process Somewhat unfortunately (because it does amount to a lot of work), that is the current best practice, I believe. At any rate, this is exactly what we do. -john On Thu, 2004-04-15 at 12:12, Amato Massimiliano (TLAB) wrote: Hello guys, I am trying to convert our system from Ant to Maven, I managed to succesfully migrate all the projects into Maven but right now i am facing the problem of the development process integration. I saw there is a Snapshot feature that upload the latest build to the repository, but I am not really sure how does it work? From my understanding if i am working on a project composed of several sub-project, like i do, i need to set in each project.xml file the version as x.y-dev and then install the articaft produced as install-snapshot or deploy-snapshot for the remote repo Now in each project that depends on that one, we need to update the version tag of the dependancy to SNAPSHOT and when we build, Maven automatically download the latest snapshot between the 2 that are in the local and remote repo When our development is completed we just need to change all the dependancy version number from snapshot to x.y and the main project.xml version from x.y-dev to x.y as well and there restart the cycle Is it correct or not? There is a better way to handle the development process? Thanks a ton for your help Massimiliano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jvz. Jason van Zyl [EMAIL PROTECTED] http://maven.apache.org happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Maven and Development Process
On Thu, 2004-04-15 at 17:02, Mark Langley wrote: This allows me to maintain details of each item in exactly one place (the .ent file), and have them automatically updated in the 5, 10, or 15 projects that might happen to need them. This is particularly useful for dependencies - I can guarantee that any module using log4j links to version 1.2.8, then enforce that they migrate simultaneously to 1.2.9 with a one-line change. I was asking because I believe why this is not possible in maven1 because recursive inheritence isn't support, it is in maven2. The maintenance time goes way down this way, and as a side benefit our project.xml files are shorter and much more comprehensible. Certainly, anything that makes the process more comprehensible is a good thing. I'm not sure why you would consider entities a workaround - they allow you to define a master list of resources, pick and choose which resources fall into each project, and keep everything synchronized. In maven2 I believe this can be done without the use of entities, but still it ultimately makes no difference to the XML processing of the POM as long as what maven gets is intact. One could always implement the same capability within Maven, but that seems like unnecessary duplication of effort. The XML parser is giving you this functionality for free - might as well take advantage of it. It's free in the XML parser, but with the advent of maven2 you'll see things like POMs being stored in DBs and prevayler (which I'm working on) and LDAP (which is something Alex is interested in) and hopefully a variety of other sources. For maven1 it is the only way to make a large set of POMs managable, but for maven2 I don't think it will be necessary but you certainly don't have to change the way you do things. Someone else answered me in IRC and they problem for them was that recursive inheritence doesn't work in maven1 so they needed to entities to make things sane. Mark -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: April 15, 2004 4:13 PM To: Maven Users List Subject: RE: Maven and Development Process On Thu, 2004-04-15 at 14:38, Mark Langley wrote: If you use XML entities to define your version numbers rather than hard coding them in the project.xml files, the process of switching between snapshot and release versions becomes much easier. See http://wiki.codehaus.org/maven/EnsureProjectConsistencyWithEntities for more details. Do a lot of people actually use this mechanism? Is it simply because maven1 doesn't support recursive inheritance? Maven2 support recursive inheritance well so would anyone still really need to use entities like this. Ultimately I suppose it doesn't matter how the POM comes together but I would like support to come from Maven itself and not the use of entities which I would consider a workaround. -Original Message- From: John Casey [mailto:[EMAIL PROTECTED] Sent: April 15, 2004 1:46 PM To: Maven Users List Subject: Re: Maven and Development Process Somewhat unfortunately (because it does amount to a lot of work), that is the current best practice, I believe. At any rate, this is exactly what we do. -john On Thu, 2004-04-15 at 12:12, Amato Massimiliano (TLAB) wrote: Hello guys, I am trying to convert our system from Ant to Maven, I managed to succesfully migrate all the projects into Maven but right now i am facing the problem of the development process integration. I saw there is a Snapshot feature that upload the latest build to the repository, but I am not really sure how does it work? From my understanding if i am working on a project composed of several sub-project, like i do, i need to set in each project.xml file the version as x.y-dev and then install the articaft produced as install-snapshot or deploy-snapshot for the remote repo Now in each project that depends on that one, we need to update the version tag of the dependancy to SNAPSHOT and when we build, Maven automatically download the latest snapshot between the 2 that are in the local and remote repo When our development is completed we just need to change all the dependancy version number from snapshot to x.y and the main project.xml version from x.y-dev to x.y as well and there restart the cycle Is it correct or not? There is a better way to handle the development process? Thanks a ton for your help Massimiliano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jvz. Jason van Zyl [EMAIL PROTECTED] http://maven.apache.org happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau
Re: Infamous Junit classloader bug
Yes, it is the nasty delegating classloader of Ant that is causing the problem... http://femur/roller/page/sradford/Weblog/20040325#classcastexception_and_junit Sean On Thu, 2004-04-15 at 15:52, Brice Copy wrote: The problem mentionned above is solved. I came across http://maven.apache.org/faq.html#unit-test-14 and added maven.junit.fork=yes to my project properties. Perhaps the FAQ could be more precise, and include a sample error message like : Class org/w3c/dom/Element violates loader constraints Cheers Brice - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dr. Sean Radford, MBBS, MSc [EMAIL PROTECTED] http://bladesys.demon.co.uk/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Maven and Development Process
-Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: 15 April 2004 22:13 To: Maven Users List Subject: RE: Maven and Development Process On Thu, 2004-04-15 at 14:38, Mark Langley wrote: If you use XML entities to define your version numbers rather than hard coding them in the project.xml files, the process of switching between snapshot and release versions becomes much easier. See http://wiki.codehaus.org/maven/EnsureProjectConsistencyWithEntities for more details. Do a lot of people actually use this mechanism? Is it simply because maven1 doesn't support recursive inheritance? Yes, mostly. Maven2 support recursive inheritance well so would anyone still really need to use entities like this. Ultimately I suppose it doesn't matter how the POM comes together but I would like support to come from Maven itself and not the use of entities which I would consider a workaround. I agree with this. However I'm not sure recursive inheritance is enough. If we wish to support all use case, we'll need to support dependencies reference as several projects may want to share some references while they are not sharing exactly the same set of references. Putting all references at the top level would mean that several subprojects which do not need all these references will still inherit from them. -Vincent -Original Message- From: John Casey [mailto:[EMAIL PROTECTED] Sent: April 15, 2004 1:46 PM To: Maven Users List Subject: Re: Maven and Development Process Somewhat unfortunately (because it does amount to a lot of work), that is the current best practice, I believe. At any rate, this is exactly what we do. -john On Thu, 2004-04-15 at 12:12, Amato Massimiliano (TLAB) wrote: Hello guys, I am trying to convert our system from Ant to Maven, I managed to succesfully migrate all the projects into Maven but right now i am facing the problem of the development process integration. I saw there is a Snapshot feature that upload the latest build to the repository, but I am not really sure how does it work? From my understanding if i am working on a project composed of several sub-project, like i do, i need to set in each project.xml file the version as x.y-dev and then install the articaft produced as install-snapshot or deploy-snapshot for the remote repo Now in each project that depends on that one, we need to update the version tag of the dependancy to SNAPSHOT and when we build, Maven automatically download the latest snapshot between the 2 that are in the local and remote repo When our development is completed we just need to change all the dependancy version number from snapshot to x.y and the main project.xml version from x.y-dev to x.y as well and there restart the cycle Is it correct or not? There is a better way to handle the development process? Thanks a ton for your help Massimiliano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jvz. Jason van Zyl [EMAIL PROTECTED] http://maven.apache.org happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Making A subproject Site
multiproject provides convenient default properties values. you should try to first set maven.multiproject.excludes and maven.multiproject.includes ; also be sure to exclude to top-level pom. once that done just run maven pultiproject:site from the top level directory (if you have parallel project structure you should run it from the master project directory). then you can try to twik the various properties to fit your needs. -- gd Raphael Philipe Mendes da Silva wrote: Thanks, but how it works? I have entered in the multiproject plugin site but i didn't find some docs... Someone can help?? -Original Message- From: Niclas Hedhman [mailto:[EMAIL PROTECTED] Sent: tera-feira, 13 de abril de 2004 12:05 To: Maven Users List Subject: Re: Making A subproject Site On Tuesday 13 April 2004 22:54, Raphael Philipe Mendes da Silva wrote: Hi, I'm new in Maven.. I need do a project site that have subprojects in it... how i can do it??? EIther use the reactor or what I like better the multiproject plugin. http://maven.apache.org/reference/plugins/multiproject/index.html Niclas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: multiproject:site issues
Please run with RC2 and add -e. Post the output to a JIRA issue. - Brett -Original Message- From: Charles N. Harvey III [mailto:[EMAIL PROTECTED] Sent: Friday, 16 April 2004 5:02 AM To: 'Maven Users List' Subject: multiproject:site issues Hello. I could swear there have been messages about this on the list but I'm just not sure of the fix for it. I am using rc1 and when I run maven site from the top level of my multiproject I get the following: -- xdoc:generate-from-pom: [echo] Generating xdocs from POM ... BUILD FAILED File.. file:/home/charvey/.maven/plugins/maven-xdoc-plugin-1.5-SNAPSH OT/ Element... velocity:merge Line.. 394 Column 9 null:-1:-1: null null Total time: 5 seconds Finished at: Thu Apr 15 15:02:02 EDT 2004 -- When I run maven multiproject:site I get this: -- multiproject:create-nav: [echo] Producing aggregate navigation... BUILD FAILED File.. file:/home/charvey/.maven/plugins/maven-multiproject-plugin-1.2-SNAPSHOT/ Element... velocity:merge Line.. 119 Column 11 null:-1:-1: null null Total time: 3 seconds Finished at: Thu Apr 15 15:07:53 EDT 2004 -- When I run maven site in a project that isn't multi it runs just fine. If it works in a regular project it makes me think that I'm doing something wrong, but I just don't know what. If anyone has any clues I would be greatful. Charlie P.S. - I tried the same thing with rc2 and got the same errors. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Maven and Development Process
On Thu, 2004-04-15 at 17:05, Vincent Massol wrote: Maven2 support recursive inheritance well so would anyone still really need to use entities like this. Ultimately I suppose it doesn't matter how the POM comes together but I would like support to come from Maven itself and not the use of entities which I would consider a workaround. I agree with this. However I'm not sure recursive inheritance is enough. If we wish to support all use case, we'll need to support dependencies reference as several projects may want to share some references while they are not sharing exactly the same set of references. Putting all references at the top level would mean that several subprojects which do not need all these references will still inherit from them. Do you use this sort of setup? I think that the dep section would be expanded along the tree of POMs where needed. But one thing I was think about the POM structure was the possibility of a meta flag to indicate whether an element was overriden or aggregated. Still not sure if this would be necessary for this type of scenerio, but there will be some surveys coming along with the maven2 alpha so we'll find out :-) -Vincent -Original Message- From: John Casey [mailto:[EMAIL PROTECTED] Sent: April 15, 2004 1:46 PM To: Maven Users List Subject: Re: Maven and Development Process Somewhat unfortunately (because it does amount to a lot of work), that is the current best practice, I believe. At any rate, this is exactly what we do. -john On Thu, 2004-04-15 at 12:12, Amato Massimiliano (TLAB) wrote: Hello guys, I am trying to convert our system from Ant to Maven, I managed to succesfully migrate all the projects into Maven but right now i am facing the problem of the development process integration. I saw there is a Snapshot feature that upload the latest build to the repository, but I am not really sure how does it work? From my understanding if i am working on a project composed of several sub-project, like i do, i need to set in each project.xml file the version as x.y-dev and then install the articaft produced as install-snapshot or deploy-snapshot for the remote repo Now in each project that depends on that one, we need to update the version tag of the dependancy to SNAPSHOT and when we build, Maven automatically download the latest snapshot between the 2 that are in the local and remote repo When our development is completed we just need to change all the dependancy version number from snapshot to x.y and the main project.xml version from x.y-dev to x.y as well and there restart the cycle Is it correct or not? There is a better way to handle the development process? Thanks a ton for your help Massimiliano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jvz. Jason van Zyl [EMAIL PROTECTED] http://maven.apache.org happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jvz. Jason van Zyl [EMAIL PROTECTED] http://maven.apache.org happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Maven and Development Process
-Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Thursday, April 15, 2004 9:08 PM To: Maven Users List Subject: RE: Maven and Development Process On Thu, 2004-04-15 at 17:05, Vincent Massol wrote: Maven2 support recursive inheritance well so would anyone still really need to use entities like this. Ultimately I suppose it doesn't matter how the POM comes together but I would like support to come from Maven itself and not the use of entities which I would consider a workaround. I agree with this. However I'm not sure recursive inheritance is enough. If we wish to support all use case, we'll need to support dependencies reference as several projects may want to share some references while they are not sharing exactly the same set of references. Putting all references at the top level would mean that several subprojects which do not need all these references will still inherit from them. Do you use this sort of setup? I think that the dep section would be expanded along the tree of POMs where needed. But one thing I was think about the POM structure was the possibility of a meta flag to indicate whether an element was overriden or aggregated. Still not sure if this would be necessary for this type of scenerio, but there will be some surveys coming along with the maven2 alpha so we'll find out :-) WDYT about flagging dependencies with free form attributes. Then having an optional inclusion filter in every POM. This filter selects the dependencies to include in the POM which is having its hierarchy of dependencies determined dynamically. A filter can work like so: ( (isRuntime=tree) (isOptional=true) ) If isRuntime and isOptional are dependency attributes then a 'defined' match can be determined. Otherwise a match is undefined when these attributes are not present and the net effect is the same as a failure to match. Maven's dependency analyzing code can apply this filter to the dependencies down the hierarchy until the super set of dependencies are exhausted. So the effective dependency hierarchy can be controlled using this filter and such free form attributes to express any user's specific need. WDYT? --Alex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Maven and Development Process
On Thu, 2004-04-15 at 21:28, Alex Karasulu wrote: Do you use this sort of setup? I think that the dep section would be expanded along the tree of POMs where needed. But one thing I was think about the POM structure was the possibility of a meta flag to indicate whether an element was overriden or aggregated. Still not sure if this would be necessary for this type of scenerio, but there will be some surveys coming along with the maven2 alpha so we'll find out :-) WDYT about flagging dependencies with free form attributes. Then having an optional inclusion filter in every POM. This filter selects the dependencies to include in the POM which is having its hierarchy of dependencies determined dynamically. A filter can work like so: ( (isRuntime=tree) (isOptional=true) ) If isRuntime and isOptional are dependency attributes then a 'defined' match can be determined. Otherwise a match is undefined when these attributes are not present and the net effect is the same as a failure to match. Maven's dependency analyzing code can apply this filter to the dependencies down the hierarchy until the super set of dependencies are exhausted. So the effective dependency hierarchy can be controlled using this filter and such free form attributes to express any user's specific need. WDYT? I'm not even sure we need the first form I mentioned, let alone something like this. I honestly don't like the idea of free form attributes and a filter. I really don't think something like this is required. But we'll find out soon enough! --Alex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jvz. Jason van Zyl [EMAIL PROTECTED] http://maven.apache.org happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Maven and Development Process
Jason van Zyl wrote: On Thu, 2004-04-15 at 14:38, Mark Langley wrote: If you use XML entities to define your version numbers rather than hard coding them in the project.xml files, the process of switching between snapshot and release versions becomes much easier. See http://wiki.codehaus.org/maven/EnsureProjectConsistencyWithEntities for more details. Do a lot of people actually use this mechanism? Is it simply because maven1 doesn't support recursive inheritance? Maven2 support recursive inheritance well so would anyone still really need to use entities like this. Ultimately I suppose it doesn't matter how the POM comes together but I would like support to come from Maven itself and not the use of entities which I would consider a workaround. Yes and no, but entities have their pros and cons. Inheritance is not anything and it depends on the element. E.g. in a multiproject you might have specific developers for the subprojects, but you would like to have them collected in the main project. Also I would not like to inherit always all dependencies from a dependent project, because some dependencies there might only be used to build the package or some are only used for test. E.g. commons-configuration has a dependency for dom4j although I can use the package (well, parts) without. Additionally I would not like to have the test dependencies of it inherited (simple-jndi, hsqldb, commons-db, dbunit, ...). While this component is normally an external artifact, I have similar situations in my projects. Using entities you can also create a company-wide repository. The locator might point to a webserver. Unfortunately such a entity repository makes your POMs quite unmoveable ... Regards, Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Maven and Development Process
Okie dokie. I just got the idea and thought I'd run it by ya. I guess it was a little out there. Alex -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Thursday, April 15, 2004 9:38 PM To: Maven Users List Subject: RE: Maven and Development Process I'm not even sure we need the first form I mentioned, let alone something like this. I honestly don't like the idea of free form attributes and a filter. I really don't think something like this is required. But we'll find out soon enough! L8r, Alex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
