Re: mvn eclipse:eclipse - creating psf file
On Thu, Apr 23, 2009 at 12:56 PM, Vladimir Blagojevic wrote: > It allows one to group related projects in eclipse. So, theoretically, after > creating all projects from pom files in eclipse:eclipse can create psf file. > Users would them import all these projects in workspace by selecting > Import->Team Project Set and selecting the psf file. > > Should be very cool. I was surprised that this is not implemented already :( Yes it would. I could find no JIRAs raised for this request. This would resolve one of my problems with Import existing projects as there are proof of concept projects in our code base which eclipse picks up and I have to remember not to select them. If I had one file to import that selected the correct projects that would be better. I'll see if I have time to look at it. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Linking source & javadoc plugin to install phase - limitation?
Short answer: because maven does not guarantee the execution order within a phase. Long answer: maven-install-plugin:install installs all the artifacts that are attached to the current module in the current build reactor into the local repository. maven-javadoc-plugin:jar creates a jar of the module javadocs and attaches it to the current module. the same applies to test-jar... when install:install runs *before* javadoc:jar, the javadoc jar is not attached, and so cannot be installed. the solution is to bind the javadoc executions to a phase *before* install in order to guarantee that the artifacts are available. FYI, the preferred phase to bind artifact creation to is the "package" phase. There is nothing stopping you from binding to a different phase, but you will find that "things just work" if you bind "packaging up my artifacts" to the package phase -Stephen 2009/4/23 nodje : > > hmmm, maybe I should reformulate in something simpler. > Hope someone that understand source and javadoc plugins is gonna pity > me:wistle: > > Basically, I expect from both source and javadoc plugin, to create the > source and javadoc jars. > Then, when invoking install or deploy, I expect all artifacts, including > -sources.jar and -javadoc.jar, to de installed locally, then deployed when > deploy is invoked. > > This totally works when including the plugins in the regular > > It does as well if I include plugins in some > , when the plugin is active. > > But it does not if I modify the standard way of execution with: > > install > > jar > test-jar > > > In this case, the source and javadoc artifacts are created, but they won't > be installed in the local repo nor will they be deployed. > > Why is that? > > -nodje > > > nodje wrote: >> >> Hi, >> >> I'm trying to limit the creation of Sources and Javadoc jars to goals only >> after install. >> >> Currently, these two are triggered with profiles (the one for PROD >> deployment) and it works well. >> >> I'd like to have those also created for internal deployment when we don't >> use the PROD profile. >> >> Having the two plugins linked to the install phase for that purpose seemed >> good to me: >> >> >> maven-source-plugin >> 2.0.4 >> >> >> install >> >> jar >> test-jar >> >> >> >> >> >> maven-javadoc-plugin >> 2.5 >> >> true >> >> >> >> attach-javadocs >> deploy >> >> jar >> >> >> >> >> >> and it works to some extends. The articfacts are created (-sources-jar, >> -javadoc.jar) as expected when invoking the install goal. >> But they aren't copied to the local repository anymore. (though the >> sources artifacts are when invoking the deploy goal with this config.) >> >> NB: when invoking 'deploy' goal: if Javadoc plugin is linked to deploy >> phase, javadoc artifact doesn't get copied nor uploaded to local and >> remote repos. If linked to the install phase like for the Source plugin, >> javadoc artifact do get copied and then uploaded. >> >> Why is that? >> >> I have a hard time understanding why they get copied when the plugin >> section doesn't contain any phase attribute, or when the >> plugin belongs to a Profile and NOT when the install is >> included in the plugin. >> >> -nodje >> > > -- > View this message in context: > http://n2.nabble.com/Linking-source---javadoc-plugin-to-install-phase---limitation--tp2626903p2681088.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 > > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Linking source & javadoc plugin to install phase - limitation?
hmmm, maybe I should reformulate in something simpler. Hope someone that understand source and javadoc plugins is gonna pity me:wistle: Basically, I expect from both source and javadoc plugin, to create the source and javadoc jars. Then, when invoking install or deploy, I expect all artifacts, including -sources.jar and -javadoc.jar, to de installed locally, then deployed when deploy is invoked. This totally works when including the plugins in the regular It does as well if I include plugins in some , when the plugin is active. But it does not if I modify the standard way of execution with: install jar test-jar In this case, the source and javadoc artifacts are created, but they won't be installed in the local repo nor will they be deployed. Why is that? -nodje nodje wrote: > > Hi, > > I'm trying to limit the creation of Sources and Javadoc jars to goals only > after install. > > Currently, these two are triggered with profiles (the one for PROD > deployment) and it works well. > > I'd like to have those also created for internal deployment when we don't > use the PROD profile. > > Having the two plugins linked to the install phase for that purpose seemed > good to me: > > > maven-source-plugin > 2.0.4 > > > install > > jar > test-jar > > > > > > maven-javadoc-plugin > 2.5 > > true > > > > attach-javadocs > deploy > > jar > > > > > > and it works to some extends. The articfacts are created (-sources-jar, > -javadoc.jar) as expected when invoking the install goal. > But they aren't copied to the local repository anymore. (though the > sources artifacts are when invoking the deploy goal with this config.) > > NB: when invoking 'deploy' goal: if Javadoc plugin is linked to deploy > phase, javadoc artifact doesn't get copied nor uploaded to local and > remote repos. If linked to the install phase like for the Source plugin, > javadoc artifact do get copied and then uploaded. > > Why is that? > > I have a hard time understanding why they get copied when the plugin > section doesn't contain any phase attribute, or when the > plugin belongs to a Profile and NOT when the install is > included in the plugin. > > -nodje > -- View this message in context: http://n2.nabble.com/Linking-source---javadoc-plugin-to-install-phase---limitation--tp2626903p2681088.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: mvn eclipse:eclipse - creating psf file
It allows one to group related projects in eclipse. So, theoretically, after creating all projects from pom files in eclipse:eclipse can create psf file. Users would them import all these projects in workspace by selecting Import->Team Project Set and selecting the psf file. Should be very cool. I was surprised that this is not implemented already :( On 4/22/09 9:50 AM, Vladimir Blagojevic wrote: Hi, Is there a way to create team project set (*.psf) file from pom when executing mvn eclipse:eclipse? Thanks, Vladimir - 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: mvn eclipse:eclipse - creating psf file
On Wed, Apr 22, 2009 at 11:20 PM, Vladimir Blagojevic wrote: > Hi, > > Is there a way to create team project set (*.psf) file from pom when > executing mvn eclipse:eclipse? What are these files used for? I've never heard of them. I think the short answer is that it doesn't at the moment, but it would be possible to extend the plugin. Feel free to patch it and raise a JIRA. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] findbugs-maven-plugin v 2.0.1 release
The Maven Findbugs team would like to announce the release of the Maven Findbugs Plugin version 2.0.1 This plugin allows the developer to run Findbugs analysis against a Maven project and produce site output in HTML to match other site reports. There are options to produce other XML outputs which are used by other plugins. Issues fixed in this release: - Updated to Findbugs 1.3.8 More information can be found at the plugin site: http://mojo.codehaus.org/findbugs-maven-plugin/ Issues Can be registered in JIRA at: http://jira.codehaus.org/browse/MFINDBUGS More information on FindBugs http://findbugs.sourceforge.net/index.html You can test the Maven Findbugs Plugin in your own project by adding the following dependency: org.codehaus.mojo findbugs-maven-plugin 2.0.1 *NOTE* Version 2.0 and greater of the Maven Findbugs plugin will require Maven to be run with a minimum of Java 5. This is consistent with Findbugs requirement for their versions of 1.3.X and greater. -- Regards, Garvin LeClaire garvin.lecla...@gmail.com
Re: Sharing properties between modules
hmmm I suspect that what you'd need is profiles you could activate a profilein the child if the file is present On 22/04/2009, Anastasios Angelidis wrote: > I guess if that's what you call them lol > > So yes if the .properties file is in the parent then use that one. If > it's in the child module use the child one. > > > Stephen Connolly wrote: >> A >> >> you want to use the value from the parent if the parent is in the current >> reactor but if the parent is not in the current reactor, you want to use >> the >> value from the child? >> >> Is that what you are trying to do? >> >> -Stephen >> >> 2009/4/22 Anastasios Angelidis >> >> >>> Sometime we build the entire project sometimes just individual modules. >>> >>> Each module has it's own filters right now. >>> >>> Basically if the parent filter exists then use that one. If only building >>> an individual module then use it's filter. >>> >>> >>> >>> >>> Grant Rettke wrote: >>> >>> And each individual module should have filtering on right? > If you want to share them, what would you be filtering out? - 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 > > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Sharing properties between modules
I guess if that's what you call them lol So yes if the .properties file is in the parent then use that one. If it's in the child module use the child one. Stephen Connolly wrote: A you want to use the value from the parent if the parent is in the current reactor but if the parent is not in the current reactor, you want to use the value from the child? Is that what you are trying to do? -Stephen 2009/4/22 Anastasios Angelidis Sometime we build the entire project sometimes just individual modules. Each module has it's own filters right now. Basically if the parent filter exists then use that one. If only building an individual module then use it's filter. Grant Rettke wrote: And each individual module should have filtering on right? If you want to share them, what would you be filtering out? - 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: maven antrun plugin
bind the execution to the pre-site phase Sent from my [rhymes with myPod] ;-) On 22 Apr 2009, at 22:40, huser wrote: Hi , I added maven ant run plugin to my project POM.xml. Then I ran mvn clean install antrun:run. I do not see the javadoc target getting generated. The plugin is not working as expected. Any ideas ? My project has various modules inside it. Following change was made in project\pom.xml maven-antrun-plugin run -- View this message in context: http://www.nabble.com/maven-antrun-plugin-tp23176592p23176592.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 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
maven antrun plugin
Hi , I added maven ant run plugin to my project POM.xml. Then I ran mvn clean install antrun:run. I do not see the javadoc target getting generated. The plugin is not working as expected. Any ideas ? My project has various modules inside it. Following change was made in project\pom.xml maven-antrun-plugin run -- View this message in context: http://www.nabble.com/maven-antrun-plugin-tp23176592p23176592.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
[ANN] Maven Source Plugin 2.1 Released
The Maven team is pleased to announce the release of the Maven Source Plugin, version 2.1 This plugin is used to create jar of the project source files. http://maven.apache.org/plugins/maven-source-plugin/ You should specify the version in your project's plugin configuration: org.apache.maven.plugins maven-source-plugin 2.1 Release Notes - Maven 2.x Source Plugin - Version 2.1 ** Bug * [MSOURCES-28] - No test for up todate/no ablity to exclude pom.properties from resulting jar * [MSOURCES-31] - forking lifecycle of source:jar goal results in release-plugin error * [MSOURCES-36] - Source jar manifest should contain Specification and Implementation details * [MSOURCES-37] - CLONE -maven-source-plugin causes generate-sources phase to execute twice * [MSOURCES-40] - Add throws MojoExecutionException on getSources() mehtod ** Improvement * [MSOURCES-13] - No-Forking mojos for use within a POM instead of CLI * [MSOURCES-34] - Allow the artifact type to be changed * [MSOURCES-39] - Add an includePom option to the sources:jar goal ** New Feature * [MSOURCES-41] - Generate source jars supporting Eclipse Source Bundle format. ** Wish * [MSOURCES-33] - provideconfiguration * [MSOURCES-42] - Please add support for MavenArchiveConfiguration Enjoy, -The Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: How to conditionally classes from the generated JAR?
On Wed, Apr 22, 2009 at 2:21 PM, Stephen Connolly wrote: > put the exclusion in a profile Thanks. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: How to conditionally classes from the generated JAR?
put the exclusion in a profile Sent from my [rhymes with myPod] ;-) On 22 Apr 2009, at 20:17, Grant Rettke wrote: Hi, By default, we need to exclude some classes from inclusion in the JAR file. It looks like in jar:jar I can use the excludes property to specify this. The thing is that, sometimes we do want to include these classes. I am wondering what is the best way to allow for condition inclusion of these classes within the JAR? Traditional thought says that defining a value at the command line makes sense, but I am not sure of how to make the exclusion conditional based on that property. Best wishes, Grant - 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
How to conditionally classes from the generated JAR?
Hi, By default, we need to exclude some classes from inclusion in the JAR file. It looks like in jar:jar I can use the excludes property to specify this. The thing is that, sometimes we do want to include these classes. I am wondering what is the best way to allow for condition inclusion of these classes within the JAR? Traditional thought says that defining a value at the command line makes sense, but I am not sure of how to make the exclusion conditional based on that property. Best wishes, Grant - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Converting to Maven 1.x
You should explain to your manager the costs incurred for using Maven 1.x will be higher because it's harder for our community to support Maven 1.x at this point. There might be a few committers left here who maintain Maven 1.x projects but I would imagine the interest is pretty low here in Maven 1.x. So the burden of fixes to Maven itself when you have problems will probably be yours. Yours is the first request I've heard to convert from Maven 2.x to 1.x. As such I don't even know if there are any tools around. There might be but I don't recall there being any. Probably easy enough to take on the existing tools and go the other way. On 22-Apr-09, at 10:21 AM, Michael K. Craghead wrote: I know this seems like a strange request, but what is the best way to convert a Maven 2 project to Maven 1? Our development team was going to start to move to Maven 2, but the plans have changed. Unfortunately, I've already built all of my code using Maven 2. I need to know how to convert my various projects to Maven 1. That includes changing the directory structure to leave out the "main" directory folder between the "src" and "java" folders, as well as any other directory differences that I might not be thinking of at the moment. Thanks. Michael K. Craghead Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl -- 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: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: A style question about testing
Hi David and Stephen, Thank you for the feedback! Modules should have their tests with them, that is the ideal lifecycle and nothing would add value in the path that I was wondering. I believe that my train of though largely reflected a lack of internalization of the "Maven way" of doing things. Best wishes, Grant - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Converting to Maven 1.x
Besides starting from scratch? No. Maven 1.x is dead for all intents and purposes. Michael K. Craghead wrote: It hasn't gone that far...So should I to assume from the responses that there is no good or easy way to convert to Maven 1? Michael K. Craghead From: David Hoffer To: Maven Users List Sent: Wednesday, April 22, 2009 1:40:42 PM Subject: Re: Converting to Maven 1.x And has the manger mandated all code shall be written in C? Strange indeed. -Dave On Wed, Apr 22, 2009 at 11:37 AM, Stephen Connolly < stephen.alan.conno...@gmail.com> wrote: Bash the manager over the head until he changes his mind ;-) -Stephen 2009/4/22 Michael K. Craghead I know this seems like a strange request, but what is the best way to convert a Maven 2 project to Maven 1? Our development team was going to start to move to Maven 2, but the plans have changed. Unfortunately, I've already built all of my code using Maven 2. I need to know how to convert my various projects to Maven 1. That includes changing the directory structure to leave out the "main" directory folder between the "src" and "java" folders, as well as any other directory differences that I might not be thinking of at the moment. Thanks. Michael K. Craghead
Re: Converting to Maven 1.x
why not just use an ant script to call m2 that way your build is ok, and m1 can be used to build everything (every problem can be solved by adding a layer of indirection) Sent from my [rhymes with myPod] ;-) On 22 Apr 2009, at 18:49, David Hoffer wrote: Never used m1, no idea. -Dave On Wed, Apr 22, 2009 at 11:48 AM, Michael K. Craghead wrote: It hasn't gone that far...So should I to assume from the responses that there is no good or easy way to convert to Maven 1? Michael K. Craghead From: David Hoffer To: Maven Users List Sent: Wednesday, April 22, 2009 1:40:42 PM Subject: Re: Converting to Maven 1.x And has the manger mandated all code shall be written in C? Strange indeed. -Dave On Wed, Apr 22, 2009 at 11:37 AM, Stephen Connolly < stephen.alan.conno...@gmail.com> wrote: Bash the manager over the head until he changes his mind ;-) -Stephen 2009/4/22 Michael K. Craghead I know this seems like a strange request, but what is the best way to convert a Maven 2 project to Maven 1? Our development team was going to start to move to Maven 2, but the plans have changed. Unfortunately, I've already built all of my code using Maven 2. I need to know how to convert my various projects to Maven 1. That includes changing the directory structure to leave out the "main" directory folder between the "src" and "java" folders, as well as any other directory differences that I might not be thinking of at the moment. Thanks. Michael K. Craghead - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Converting to Maven 1.x
Never used m1, no idea. -Dave On Wed, Apr 22, 2009 at 11:48 AM, Michael K. Craghead wrote: > It hasn't gone that far...So should I to assume from the responses that > there is no good or easy way to convert to Maven 1? > Michael K. Craghead > > > > > > From: David Hoffer > To: Maven Users List > Sent: Wednesday, April 22, 2009 1:40:42 PM > Subject: Re: Converting to Maven 1.x > > And has the manger mandated all code shall be written in C? Strange > indeed. > > -Dave > > On Wed, Apr 22, 2009 at 11:37 AM, Stephen Connolly < > stephen.alan.conno...@gmail.com> wrote: > > > Bash the manager over the head until he changes his mind > > > > ;-) > > > > -Stephen > > > > 2009/4/22 Michael K. Craghead > > > > > I know this seems like a strange request, but what is the best way to > > > convert a Maven 2 project to Maven 1? Our development team was going to > > > start to move to Maven 2, but the plans have changed. Unfortunately, > I've > > > already built all of my code using Maven 2. I need to know how to > convert > > my > > > various projects to Maven 1. That includes changing the directory > > structure > > > to leave out the "main" directory folder between the "src" and "java" > > > folders, as well as any other directory differences that I might not be > > > thinking of at the moment. Thanks. > > > Michael K. Craghead > > >
Re: Converting to Maven 1.x
It hasn't gone that far...So should I to assume from the responses that there is no good or easy way to convert to Maven 1? Michael K. Craghead From: David Hoffer To: Maven Users List Sent: Wednesday, April 22, 2009 1:40:42 PM Subject: Re: Converting to Maven 1.x And has the manger mandated all code shall be written in C? Strange indeed. -Dave On Wed, Apr 22, 2009 at 11:37 AM, Stephen Connolly < stephen.alan.conno...@gmail.com> wrote: > Bash the manager over the head until he changes his mind > > ;-) > > -Stephen > > 2009/4/22 Michael K. Craghead > > > I know this seems like a strange request, but what is the best way to > > convert a Maven 2 project to Maven 1? Our development team was going to > > start to move to Maven 2, but the plans have changed. Unfortunately, I've > > already built all of my code using Maven 2. I need to know how to convert > my > > various projects to Maven 1. That includes changing the directory > structure > > to leave out the "main" directory folder between the "src" and "java" > > folders, as well as any other directory differences that I might not be > > thinking of at the moment. Thanks. > > Michael K. Craghead >
Re: Converting to Maven 1.x
I'm sure, but stillI don't have a choice. Michael K. Craghead From: nicolas de loof To: Maven Users List Sent: Wednesday, April 22, 2009 1:40:02 PM Subject: Re: Converting to Maven 1.x Do you know you will be the latest one on this list to use maven 1 :p 2009/4/22 Stephen Connolly > Bash the manager over the head until he changes his mind > > ;-) > > -Stephen > > 2009/4/22 Michael K. Craghead > > > I know this seems like a strange request, but what is the best way to > > convert a Maven 2 project to Maven 1? Our development team was going to > > start to move to Maven 2, but the plans have changed. Unfortunately, I've > > already built all of my code using Maven 2. I need to know how to convert > my > > various projects to Maven 1. That includes changing the directory > structure > > to leave out the "main" directory folder between the "src" and "java" > > folders, as well as any other directory differences that I might not be > > thinking of at the moment. Thanks. > > Michael K. Craghead >
Re: Converting to Maven 1.x
Unfortunately that won't work this time. Our effort is just a very small part of a much larger project. I was looking forward to using 2 and had gotten use to m2eclipse. Michael K. Craghead From: Stephen Connolly To: Maven Users List Sent: Wednesday, April 22, 2009 1:37:33 PM Subject: Re: Converting to Maven 1.x Bash the manager over the head until he changes his mind ;-) -Stephen 2009/4/22 Michael K. Craghead > I know this seems like a strange request, but what is the best way to > convert a Maven 2 project to Maven 1? Our development team was going to > start to move to Maven 2, but the plans have changed. Unfortunately, I've > already built all of my code using Maven 2. I need to know how to convert my > various projects to Maven 1. That includes changing the directory structure > to leave out the "main" directory folder between the "src" and "java" > folders, as well as any other directory differences that I might not be > thinking of at the moment. Thanks. > Michael K. Craghead
Re: Converting to Maven 1.x
And has the manger mandated all code shall be written in C? Strange indeed. -Dave On Wed, Apr 22, 2009 at 11:37 AM, Stephen Connolly < stephen.alan.conno...@gmail.com> wrote: > Bash the manager over the head until he changes his mind > > ;-) > > -Stephen > > 2009/4/22 Michael K. Craghead > > > I know this seems like a strange request, but what is the best way to > > convert a Maven 2 project to Maven 1? Our development team was going to > > start to move to Maven 2, but the plans have changed. Unfortunately, I've > > already built all of my code using Maven 2. I need to know how to convert > my > > various projects to Maven 1. That includes changing the directory > structure > > to leave out the "main" directory folder between the "src" and "java" > > folders, as well as any other directory differences that I might not be > > thinking of at the moment. Thanks. > > Michael K. Craghead >
Re: Converting to Maven 1.x
Do you know you will be the latest one on this list to use maven 1 :p 2009/4/22 Stephen Connolly > Bash the manager over the head until he changes his mind > > ;-) > > -Stephen > > 2009/4/22 Michael K. Craghead > > > I know this seems like a strange request, but what is the best way to > > convert a Maven 2 project to Maven 1? Our development team was going to > > start to move to Maven 2, but the plans have changed. Unfortunately, I've > > already built all of my code using Maven 2. I need to know how to convert > my > > various projects to Maven 1. That includes changing the directory > structure > > to leave out the "main" directory folder between the "src" and "java" > > folders, as well as any other directory differences that I might not be > > thinking of at the moment. Thanks. > > Michael K. Craghead >
Re: RELEASE and branches
Yes, just updating the pom to remove the manual parts is a great step forward. -Dave On Wed, Apr 22, 2009 at 11:35 AM, Stephen Connolly < stephen.alan.conno...@gmail.com> wrote: > 2009/4/22 David Hoffer > > > Sorry, I might not be clear on the big problem you are trying to solve. > > The > > release plugin works for us. Its used for each dependency you need to > > release. We try to limit snapshot usage overall, that's just for things > a > > project is actively changing, else use a released version. > > > > The 'biggest' problem, I have had, is not being able to use version > > ranges...means I have to modify the dependency version in the consuming > > projects, but never more than one per per dependency so its manageable. > > Now > > I see there is the versions-maven-plugin so potentially this will allow > > version ranges which will eliminate this manual process. > > > > -Dave > > > > > FYI, the versions-maven-plugin *modifies* your pom.xml... so you will still > have to commit the changed poms to SCM... but you don't have to change them > by hand any more... the process should go something like this > > mvn versions:update-properties > mvn clean verify > if that worked > mvn versions:commit > svn ci -m "updated the versions" > else > mvn versions:revert > fi > > Note: versions-maven-plugin (from 1.0-alpha-3) uses a "poor man's" scm to > allow you to roll back the changes it made quickly > > -Stephen >
Re: Converting to Maven 1.x
Bash the manager over the head until he changes his mind ;-) -Stephen 2009/4/22 Michael K. Craghead > I know this seems like a strange request, but what is the best way to > convert a Maven 2 project to Maven 1? Our development team was going to > start to move to Maven 2, but the plans have changed. Unfortunately, I've > already built all of my code using Maven 2. I need to know how to convert my > various projects to Maven 1. That includes changing the directory structure > to leave out the "main" directory folder between the "src" and "java" > folders, as well as any other directory differences that I might not be > thinking of at the moment. Thanks. > Michael K. Craghead
Re: RELEASE and branches
2009/4/22 David Hoffer > Sorry, I might not be clear on the big problem you are trying to solve. > The > release plugin works for us. Its used for each dependency you need to > release. We try to limit snapshot usage overall, that's just for things a > project is actively changing, else use a released version. > > The 'biggest' problem, I have had, is not being able to use version > ranges...means I have to modify the dependency version in the consuming > projects, but never more than one per per dependency so its manageable. > Now > I see there is the versions-maven-plugin so potentially this will allow > version ranges which will eliminate this manual process. > > -Dave > > FYI, the versions-maven-plugin *modifies* your pom.xml... so you will still have to commit the changed poms to SCM... but you don't have to change them by hand any more... the process should go something like this mvn versions:update-properties mvn clean verify if that worked mvn versions:commit svn ci -m "updated the versions" else mvn versions:revert fi Note: versions-maven-plugin (from 1.0-alpha-3) uses a "poor man's" scm to allow you to roll back the changes it made quickly -Stephen
Re: RELEASE and branches
It depends... if your build is reliable and never fails... if all your components always have the same version number... if all your modules are in the same tree... then yes the the release plugin will sort it out for you. however, if you have a long flakey build (we have one that is about 4 hours and fails during release if you look at it sideways) what we do with that build is release the reliable bits first, and then the unreliable modules separately... this can (and does) result in different build numbers for each module, but that's ok. -Stephen 2009/4/22 Michael Hüttermann > starting at lowest dependencies and work the way ... having a pretty big > build system this sounds like a nightmare. Just only using the maven > release plugin on the top level isn't enough right ?! > > Michael > >
Re: RELEASE and branches
Sorry, I might not be clear on the big problem you are trying to solve. The release plugin works for us. Its used for each dependency you need to release. We try to limit snapshot usage overall, that's just for things a project is actively changing, else use a released version. The 'biggest' problem, I have had, is not being able to use version ranges...means I have to modify the dependency version in the consuming projects, but never more than one per per dependency so its manageable. Now I see there is the versions-maven-plugin so potentially this will allow version ranges which will eliminate this manual process. -Dave On Wed, Apr 22, 2009 at 11:17 AM, Michael Hüttermann < mich...@huettermann.net> wrote: > starting at lowest dependencies and work the way ... having a pretty big > build system this sounds like a nightmare. Just only using the maven > release plugin on the top level isn't enough right ?! > > Michael > > > > > We use snapshot for all versions while developing then when release time > > comes we release (maven release plugin) each project, starting at the > > lowest > > dependency and work our way up to the top. The release plugin will > > automatically update each project to the next snapshot version, as well > as > > SCM tagging, etc. > > > > > > On Wed, Apr 22, 2009 at 10:37 AM, Michael Hüttermann < > > mich...@huettermann.net> wrote: > > > >> ok, I see, thanks! There is another concept using a generic version: > >> snapshots. What do you do with your SNAPSHOTs while branching then? Do > >> you > >> go through all your POMs and dependencies replacing the snapshot token > >> with the real snapshot version including timestamp? You can say "ok, I > >> will never use RELEASE" but you want to use the snapshot mechanism in > >> the > >> daily work for sure I guess. What's your strategy here while branching ? > >> > >> Thanks for your time !!! > >> > >> Michael > >> > >> > >> > >> > 2009/4/22 Michael Hüttermann > >> > > >> >> Hello experts, > >> >> > >> >> how do you set up the process if you use RELEASE for a dependency in > >> a > >> >> POM, and work with VCS branches ? > >> > > >> > > >> > you stop using RELEASE for a dependency. > >> > > >> > RELEASE corresponds to the last released version... so if you release, > >> in > >> > order > >> > > >> > 1.0.0 > >> > 1.0.1 > >> > 1.1.0 > >> > 1.1.1 > >> > 2.0.0 > >> > 1.0.2 > >> > > >> > Then RELEASE will correspond to 1.0.2 as that was the last version > >> > released. > >> > > >> > The solution is to use version ranges, i.e. work on the 1.0.x branch > >> would > >> > depend on [1.0.0,1.1.0-!) that is any version greater than or equal to > >> > 1.0.0 > >> > and less than 1.1.0-! (which thanks to the joys of ascii sorting means > >> > that > >> > you will exclude any 1.1.0 version including 1.1.0-SNAPSHOT which is > >> less > >> > than 1.1.0) > >> > > >> > Of course version ranges only work if you follow maven's rules for > >> version > >> > numbering... if you cannot follow maven's (some would say slightly > >> > strange) > >> > version numbering scheme you will need to do some manual work... to > >> help > >> > automate the manual work, you'll probably end up using > >> > versions-maven-plugin > >> > and specifying the version using a property. > >> > > >> > > >> >> What is your best practice? Probably a > >> >> branch will have to adress another, older version of an artifact, > >> >> actually > >> >> it has to adress a stable, tagged version. What happens if on HEAD > >> you > >> >> use > >> >> new versions of dependencies (so a new version for RELEASE), ... do > >> you > >> >> adjust all of your branches to remove the RELEASE token and enter a > >> >> dedicated version? Isn't that a nightmare ? > >> > > >> > > >> > I think you will realise from my earlier comment that there is *no way > >> in > >> > hell* that you would use RELEASE. > >> > > >> > FYI, the LATEST and RELEASE versions were initially more for use in > >> > specifying plugin versions... but they are so problematic that > >> everyone > >> > pretty much avoids them > >> > > >> > -Stephen > >> > > >> >> > >> >> > >> >> Thanks !! > >> >> > >> >> > >> >> Michael > >> >> > >> >> - > >> >> 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: RELEASE and branches
I guess we need to separate 3rd party dependencies and internal dependencies. In general you do not want to depend on a -SNAPSHOT version of a third party dependency... for example in between releases, there is no way I'd switch from log4j-1.2.15 to log4j-1.2.16-SNAPSHOT ___unless___ there was a bug in 1.2.15 that was affecting my code, in which case I might switch to the -SNAPSHOT until either log4j releases, or I need to release at which point I would also do a release of log4j-1.2.16-mycompany-01 However, if these are internal dependencies, chances are that you actually do want the -SNAPSHOT dependency... so if i'm working on foobar-optional 2.3-SNAPSHOT I will depend on foobar-core 2.3-SNAPSHOT also... now there's this quirky feature that I'm adding to foobar-optional, and the guys working on foobar-core are great at breaking their build... so what I do in that case is I lock my -SNAPSHOT dependency on foobar-core to 2.3-20090422.181944-5 because that one is working, then I add my feature and when I'm finished I restore back to a regular -SNAPSHOT and start worrying about integrating with the changes that they made to foobar-core -Stephen 2009/4/22 Michael Hüttermann > hmm how does that help between releases? You need to adress stable, > labeled versions of artifacts .. so in my feeling you aren't allowed to > use any snapshot version at all .. ? > > Michael > > > > I think (actually I hope) he's talking about between releases. > > > > trunk might be moving rapidly, so you fork a branch to work on a > > feature... > > you don't want the changes to the artifacts from trunk screwing with your > > build until you are ready to merge the branch back to trunk... > > > > If he's got some other plan then I'd advise him against using timestamp > > snapshots for such a crazy plan (which I'm sure he will share in an > effort > > to prove that it's not crazy) > > > > -Stephen > >
Converting to Maven 1.x
I know this seems like a strange request, but what is the best way to convert a Maven 2 project to Maven 1? Our development team was going to start to move to Maven 2, but the plans have changed. Unfortunately, I've already built all of my code using Maven 2. I need to know how to convert my various projects to Maven 1. That includes changing the directory structure to leave out the "main" directory folder between the "src" and "java" folders, as well as any other directory differences that I might not be thinking of at the moment. Thanks. Michael K. Craghead
Re: RELEASE and branches
starting at lowest dependencies and work the way ... having a pretty big build system this sounds like a nightmare. Just only using the maven release plugin on the top level isn't enough right ?! Michael > We use snapshot for all versions while developing then when release time > comes we release (maven release plugin) each project, starting at the > lowest > dependency and work our way up to the top. The release plugin will > automatically update each project to the next snapshot version, as well as > SCM tagging, etc. > > > On Wed, Apr 22, 2009 at 10:37 AM, Michael Hüttermann < > mich...@huettermann.net> wrote: > >> ok, I see, thanks! There is another concept using a generic version: >> snapshots. What do you do with your SNAPSHOTs while branching then? Do >> you >> go through all your POMs and dependencies replacing the snapshot token >> with the real snapshot version including timestamp? You can say "ok, I >> will never use RELEASE" but you want to use the snapshot mechanism in >> the >> daily work for sure I guess. What's your strategy here while branching ? >> >> Thanks for your time !!! >> >> Michael >> >> >> >> > 2009/4/22 Michael Hüttermann >> > >> >> Hello experts, >> >> >> >> how do you set up the process if you use RELEASE for a dependency in >> a >> >> POM, and work with VCS branches ? >> > >> > >> > you stop using RELEASE for a dependency. >> > >> > RELEASE corresponds to the last released version... so if you release, >> in >> > order >> > >> > 1.0.0 >> > 1.0.1 >> > 1.1.0 >> > 1.1.1 >> > 2.0.0 >> > 1.0.2 >> > >> > Then RELEASE will correspond to 1.0.2 as that was the last version >> > released. >> > >> > The solution is to use version ranges, i.e. work on the 1.0.x branch >> would >> > depend on [1.0.0,1.1.0-!) that is any version greater than or equal to >> > 1.0.0 >> > and less than 1.1.0-! (which thanks to the joys of ascii sorting means >> > that >> > you will exclude any 1.1.0 version including 1.1.0-SNAPSHOT which is >> less >> > than 1.1.0) >> > >> > Of course version ranges only work if you follow maven's rules for >> version >> > numbering... if you cannot follow maven's (some would say slightly >> > strange) >> > version numbering scheme you will need to do some manual work... to >> help >> > automate the manual work, you'll probably end up using >> > versions-maven-plugin >> > and specifying the version using a property. >> > >> > >> >> What is your best practice? Probably a >> >> branch will have to adress another, older version of an artifact, >> >> actually >> >> it has to adress a stable, tagged version. What happens if on HEAD >> you >> >> use >> >> new versions of dependencies (so a new version for RELEASE), ... do >> you >> >> adjust all of your branches to remove the RELEASE token and enter a >> >> dedicated version? Isn't that a nightmare ? >> > >> > >> > I think you will realise from my earlier comment that there is *no way >> in >> > hell* that you would use RELEASE. >> > >> > FYI, the LATEST and RELEASE versions were initially more for use in >> > specifying plugin versions... but they are so problematic that >> everyone >> > pretty much avoids them >> > >> > -Stephen >> > >> >> >> >> >> >> Thanks !! >> >> >> >> >> >> Michael >> >> >> >> - >> >> 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: RELEASE and branches
hmm how does that help between releases? You need to adress stable, labeled versions of artifacts .. so in my feeling you aren't allowed to use any snapshot version at all .. ? Michael > I think (actually I hope) he's talking about between releases. > > trunk might be moving rapidly, so you fork a branch to work on a > feature... > you don't want the changes to the artifacts from trunk screwing with your > build until you are ready to merge the branch back to trunk... > > If he's got some other plan then I'd advise him against using timestamp > snapshots for such a crazy plan (which I'm sure he will share in an effort > to prove that it's not crazy) > > -Stephen > > 2009/4/22 David Hoffer > >> We use snapshot for all versions while developing then when release time >> comes we release (maven release plugin) each project, starting at the >> lowest >> dependency and work our way up to the top. The release plugin will >> automatically update each project to the next snapshot version, as well >> as >> SCM tagging, etc. >> >> >> On Wed, Apr 22, 2009 at 10:37 AM, Michael Hüttermann < >> mich...@huettermann.net> wrote: >> >> > ok, I see, thanks! There is another concept using a generic version: >> > snapshots. What do you do with your SNAPSHOTs while branching then? Do >> you >> > go through all your POMs and dependencies replacing the snapshot token >> > with the real snapshot version including timestamp? You can say "ok, I >> > will never use RELEASE" but you want to use the snapshot mechanism in >> the >> > daily work for sure I guess. What's your strategy here while branching >> ? >> > >> > Thanks for your time !!! >> > >> > Michael >> > >> > >> > >> > > 2009/4/22 Michael Hüttermann >> > > >> > >> Hello experts, >> > >> >> > >> how do you set up the process if you use RELEASE for a dependency >> in a >> > >> POM, and work with VCS branches ? >> > > >> > > >> > > you stop using RELEASE for a dependency. >> > > >> > > RELEASE corresponds to the last released version... so if you >> release, >> in >> > > order >> > > >> > > 1.0.0 >> > > 1.0.1 >> > > 1.1.0 >> > > 1.1.1 >> > > 2.0.0 >> > > 1.0.2 >> > > >> > > Then RELEASE will correspond to 1.0.2 as that was the last version >> > > released. >> > > >> > > The solution is to use version ranges, i.e. work on the 1.0.x branch >> > would >> > > depend on [1.0.0,1.1.0-!) that is any version greater than or equal >> to >> > > 1.0.0 >> > > and less than 1.1.0-! (which thanks to the joys of ascii sorting >> means >> > > that >> > > you will exclude any 1.1.0 version including 1.1.0-SNAPSHOT which is >> less >> > > than 1.1.0) >> > > >> > > Of course version ranges only work if you follow maven's rules for >> > version >> > > numbering... if you cannot follow maven's (some would say slightly >> > > strange) >> > > version numbering scheme you will need to do some manual work... to >> help >> > > automate the manual work, you'll probably end up using >> > > versions-maven-plugin >> > > and specifying the version using a property. >> > > >> > > >> > >> What is your best practice? Probably a >> > >> branch will have to adress another, older version of an artifact, >> > >> actually >> > >> it has to adress a stable, tagged version. What happens if on HEAD >> you >> > >> use >> > >> new versions of dependencies (so a new version for RELEASE), ... do >> you >> > >> adjust all of your branches to remove the RELEASE token and enter a >> > >> dedicated version? Isn't that a nightmare ? >> > > >> > > >> > > I think you will realise from my earlier comment that there is *no >> way >> in >> > > hell* that you would use RELEASE. >> > > >> > > FYI, the LATEST and RELEASE versions were initially more for use in >> > > specifying plugin versions... but they are so problematic that >> everyone >> > > pretty much avoids them >> > > >> > > -Stephen >> > > >> > >> >> > >> >> > >> Thanks !! >> > >> >> > >> >> > >> Michael >> > >> >> > >> - >> > >> 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: RELEASE and branches
2009/4/22 David Hoffer > Ahhh, > > A plugin to fix version range problems, I'll have to ckeck this out. > > -Dave > > On Wed, Apr 22, 2009 at 10:41 AM, Stephen Connolly < > stephen.alan.conno...@gmail.com> wrote: > > 2009/4/22 David Hoffer > > > On Wed, Apr 22, 2009 at 10:05 AM, Stephen Connolly < > > > stephen.alan.conno...@gmail.com> wrote: > > > > Of course version ranges only work if you follow maven's rules for > > > version > > > > numbering... if you cannot follow maven's (some would say slightly > > > strange) > > > > version numbering scheme you will need to do some manual work... to > > help > > > > automate the manual work, you'll probably end up using > > > > versions-maven-plugin > > > > and specifying the version using a property. > Of course this was what I said in my first response ;-) -Stephen
Re: RELEASE and branches
Ahhh,
A plugin to fix version range problems, I'll have to ckeck this out.
-Dave
On Wed, Apr 22, 2009 at 10:41 AM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:
> Which is where using properties and the versions-maven-plugin comes to the
> rescue
>
>
> ...
>
> ...
>
>com.foobar
>foobar-core
>${foobar-version}
>
>
>com.foobar
>foobar-optional
>${foobar-version}
>
> ...
>
> ...
>
> 1.2
>
> ...
>
>
>
> org.codehaus.mojo
> versions-maven-plugin
> 1.0-alpha-3-SNAPSHOT
>
>
>
>foobar-version
>[1.2,2.0-!)
>
>
>
>
>
>
> ...
>
>
> running
>
> mvn versions:update-properties
>
> will look for newer versions of both linked artifacts that are within the
> specified range and update the property if required.
>
> mvn versions:update-properties -DallowSnapshots=true
>
> is the only way to get -SNAPSHOT versions...
>
> Note: if your reactor contained a -SNAPSHOT version of both of the foobar
> dependencies, then update-properties will detect this and assume that you
> probably want to use the version from the reactor and not the previous
> release... but there's a flag to turn that behaviour off.
>
> -Stephen
>
> 2009/4/22 David Hoffer
>
> > Unfortunately version ranges have so many bugs i don't find them useful
> > either. The problem with version ranges is that they will, in most
> cases,
> > include snapshots although that's both not intended and violates the
> > version
> > range spec.
> >
> > -Dave
> >
> > On Wed, Apr 22, 2009 at 10:05 AM, Stephen Connolly <
> > stephen.alan.conno...@gmail.com> wrote:
> >
> > > 2009/4/22 Michael Hüttermann
> > >
> > > > Hello experts,
> > > >
> > > > how do you set up the process if you use RELEASE for a dependency in
> a
> > > > POM, and work with VCS branches ?
> > >
> > >
> > > you stop using RELEASE for a dependency.
> > >
> > > RELEASE corresponds to the last released version... so if you release,
> in
> > > order
> > >
> > > 1.0.0
> > > 1.0.1
> > > 1.1.0
> > > 1.1.1
> > > 2.0.0
> > > 1.0.2
> > >
> > > Then RELEASE will correspond to 1.0.2 as that was the last version
> > > released.
> > >
> > > The solution is to use version ranges, i.e. work on the 1.0.x branch
> > would
> > > depend on [1.0.0,1.1.0-!) that is any version greater than or equal to
> > > 1.0.0
> > > and less than 1.1.0-! (which thanks to the joys of ascii sorting means
> > that
> > > you will exclude any 1.1.0 version including 1.1.0-SNAPSHOT which is
> less
> > > than 1.1.0)
> > >
> > > Of course version ranges only work if you follow maven's rules for
> > version
> > > numbering... if you cannot follow maven's (some would say slightly
> > strange)
> > > version numbering scheme you will need to do some manual work... to
> help
> > > automate the manual work, you'll probably end up using
> > > versions-maven-plugin
> > > and specifying the version using a property.
> > >
> > >
> > > > What is your best practice? Probably a
> > > > branch will have to adress another, older version of an artifact,
> > > actually
> > > > it has to adress a stable, tagged version. What happens if on HEAD
> you
> > > use
> > > > new versions of dependencies (so a new version for RELEASE), ... do
> you
> > > > adjust all of your branches to remove the RELEASE token and enter a
> > > > dedicated version? Isn't that a nightmare ?
> > >
> > >
> > > I think you will realise from my earlier comment that there is *no way
> in
> > > hell* that you would use RELEASE.
> > >
> > > FYI, the LATEST and RELEASE versions were initially more for use in
> > > specifying plugin versions... but they are so problematic that everyone
> > > pretty much avoids them
> > >
> > > -Stephen
> > >
> > > >
> > > >
> > > > Thanks !!
> > > >
> > > >
> > > > Michael
> > > >
> > > > -
> > > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > > > For additional commands, e-mail: users-h...@maven.apache.org
> > > >
> > > >
> > >
> >
>
Re: RELEASE and branches
I think (actually I hope) he's talking about between releases. trunk might be moving rapidly, so you fork a branch to work on a feature... you don't want the changes to the artifacts from trunk screwing with your build until you are ready to merge the branch back to trunk... If he's got some other plan then I'd advise him against using timestamp snapshots for such a crazy plan (which I'm sure he will share in an effort to prove that it's not crazy) -Stephen 2009/4/22 David Hoffer > We use snapshot for all versions while developing then when release time > comes we release (maven release plugin) each project, starting at the > lowest > dependency and work our way up to the top. The release plugin will > automatically update each project to the next snapshot version, as well as > SCM tagging, etc. > > > On Wed, Apr 22, 2009 at 10:37 AM, Michael Hüttermann < > mich...@huettermann.net> wrote: > > > ok, I see, thanks! There is another concept using a generic version: > > snapshots. What do you do with your SNAPSHOTs while branching then? Do > you > > go through all your POMs and dependencies replacing the snapshot token > > with the real snapshot version including timestamp? You can say "ok, I > > will never use RELEASE" but you want to use the snapshot mechanism in the > > daily work for sure I guess. What's your strategy here while branching ? > > > > Thanks for your time !!! > > > > Michael > > > > > > > > > 2009/4/22 Michael Hüttermann > > > > > >> Hello experts, > > >> > > >> how do you set up the process if you use RELEASE for a dependency in a > > >> POM, and work with VCS branches ? > > > > > > > > > you stop using RELEASE for a dependency. > > > > > > RELEASE corresponds to the last released version... so if you release, > in > > > order > > > > > > 1.0.0 > > > 1.0.1 > > > 1.1.0 > > > 1.1.1 > > > 2.0.0 > > > 1.0.2 > > > > > > Then RELEASE will correspond to 1.0.2 as that was the last version > > > released. > > > > > > The solution is to use version ranges, i.e. work on the 1.0.x branch > > would > > > depend on [1.0.0,1.1.0-!) that is any version greater than or equal to > > > 1.0.0 > > > and less than 1.1.0-! (which thanks to the joys of ascii sorting means > > > that > > > you will exclude any 1.1.0 version including 1.1.0-SNAPSHOT which is > less > > > than 1.1.0) > > > > > > Of course version ranges only work if you follow maven's rules for > > version > > > numbering... if you cannot follow maven's (some would say slightly > > > strange) > > > version numbering scheme you will need to do some manual work... to > help > > > automate the manual work, you'll probably end up using > > > versions-maven-plugin > > > and specifying the version using a property. > > > > > > > > >> What is your best practice? Probably a > > >> branch will have to adress another, older version of an artifact, > > >> actually > > >> it has to adress a stable, tagged version. What happens if on HEAD you > > >> use > > >> new versions of dependencies (so a new version for RELEASE), ... do > you > > >> adjust all of your branches to remove the RELEASE token and enter a > > >> dedicated version? Isn't that a nightmare ? > > > > > > > > > I think you will realise from my earlier comment that there is *no way > in > > > hell* that you would use RELEASE. > > > > > > FYI, the LATEST and RELEASE versions were initially more for use in > > > specifying plugin versions... but they are so problematic that everyone > > > pretty much avoids them > > > > > > -Stephen > > > > > >> > > >> > > >> Thanks !! > > >> > > >> > > >> Michael > > >> > > >> - > > >> 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: RELEASE and branches
I should point out that I never use timestamp snapshots... but then we build everything locally, and our CI server does not deploy snapshots... we had too many issues with both random snapshot updates, and non-full builds 2009/4/22 Stephen Connolly > versions:lock-snapshots > > and then > > versions:unlock-snapshots > > to turn them back to normal before reintegrating your branch > > > 2009/4/22 Michael Hüttermann > >> ok, I see, thanks! There is another concept using a generic version: >> snapshots. What do you do with your SNAPSHOTs while branching then? Do you >> go through all your POMs and dependencies replacing the snapshot token >> with the real snapshot version including timestamp? You can say "ok, I >> will never use RELEASE" but you want to use the snapshot mechanism in the >> daily work for sure I guess. What's your strategy here while branching ? >> >> Thanks for your time !!! >> >> Michael >> >> >> >> > 2009/4/22 Michael Hüttermann >> > >> >> Hello experts, >> >> >> >> how do you set up the process if you use RELEASE for a dependency in a >> >> POM, and work with VCS branches ? >> > >> > >> > you stop using RELEASE for a dependency. >> > >> > RELEASE corresponds to the last released version... so if you release, >> in >> > order >> > >> > 1.0.0 >> > 1.0.1 >> > 1.1.0 >> > 1.1.1 >> > 2.0.0 >> > 1.0.2 >> > >> > Then RELEASE will correspond to 1.0.2 as that was the last version >> > released. >> > >> > The solution is to use version ranges, i.e. work on the 1.0.x branch >> would >> > depend on [1.0.0,1.1.0-!) that is any version greater than or equal to >> > 1.0.0 >> > and less than 1.1.0-! (which thanks to the joys of ascii sorting means >> > that >> > you will exclude any 1.1.0 version including 1.1.0-SNAPSHOT which is >> less >> > than 1.1.0) >> > >> > Of course version ranges only work if you follow maven's rules for >> version >> > numbering... if you cannot follow maven's (some would say slightly >> > strange) >> > version numbering scheme you will need to do some manual work... to help >> > automate the manual work, you'll probably end up using >> > versions-maven-plugin >> > and specifying the version using a property. >> > >> > >> >> What is your best practice? Probably a >> >> branch will have to adress another, older version of an artifact, >> >> actually >> >> it has to adress a stable, tagged version. What happens if on HEAD you >> >> use >> >> new versions of dependencies (so a new version for RELEASE), ... do you >> >> adjust all of your branches to remove the RELEASE token and enter a >> >> dedicated version? Isn't that a nightmare ? >> > >> > >> > I think you will realise from my earlier comment that there is *no way >> in >> > hell* that you would use RELEASE. >> > >> > FYI, the LATEST and RELEASE versions were initially more for use in >> > specifying plugin versions... but they are so problematic that everyone >> > pretty much avoids them >> > >> > -Stephen >> > >> >> >> >> >> >> Thanks !! >> >> >> >> >> >> Michael >> >> >> >> - >> >> 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: RELEASE and branches
We use snapshot for all versions while developing then when release time comes we release (maven release plugin) each project, starting at the lowest dependency and work our way up to the top. The release plugin will automatically update each project to the next snapshot version, as well as SCM tagging, etc. On Wed, Apr 22, 2009 at 10:37 AM, Michael Hüttermann < mich...@huettermann.net> wrote: > ok, I see, thanks! There is another concept using a generic version: > snapshots. What do you do with your SNAPSHOTs while branching then? Do you > go through all your POMs and dependencies replacing the snapshot token > with the real snapshot version including timestamp? You can say "ok, I > will never use RELEASE" but you want to use the snapshot mechanism in the > daily work for sure I guess. What's your strategy here while branching ? > > Thanks for your time !!! > > Michael > > > > > 2009/4/22 Michael Hüttermann > > > >> Hello experts, > >> > >> how do you set up the process if you use RELEASE for a dependency in a > >> POM, and work with VCS branches ? > > > > > > you stop using RELEASE for a dependency. > > > > RELEASE corresponds to the last released version... so if you release, in > > order > > > > 1.0.0 > > 1.0.1 > > 1.1.0 > > 1.1.1 > > 2.0.0 > > 1.0.2 > > > > Then RELEASE will correspond to 1.0.2 as that was the last version > > released. > > > > The solution is to use version ranges, i.e. work on the 1.0.x branch > would > > depend on [1.0.0,1.1.0-!) that is any version greater than or equal to > > 1.0.0 > > and less than 1.1.0-! (which thanks to the joys of ascii sorting means > > that > > you will exclude any 1.1.0 version including 1.1.0-SNAPSHOT which is less > > than 1.1.0) > > > > Of course version ranges only work if you follow maven's rules for > version > > numbering... if you cannot follow maven's (some would say slightly > > strange) > > version numbering scheme you will need to do some manual work... to help > > automate the manual work, you'll probably end up using > > versions-maven-plugin > > and specifying the version using a property. > > > > > >> What is your best practice? Probably a > >> branch will have to adress another, older version of an artifact, > >> actually > >> it has to adress a stable, tagged version. What happens if on HEAD you > >> use > >> new versions of dependencies (so a new version for RELEASE), ... do you > >> adjust all of your branches to remove the RELEASE token and enter a > >> dedicated version? Isn't that a nightmare ? > > > > > > I think you will realise from my earlier comment that there is *no way in > > hell* that you would use RELEASE. > > > > FYI, the LATEST and RELEASE versions were initially more for use in > > specifying plugin versions... but they are so problematic that everyone > > pretty much avoids them > > > > -Stephen > > > >> > >> > >> Thanks !! > >> > >> > >> Michael > >> > >> - > >> 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: RELEASE and branches
versions:lock-snapshots and then versions:unlock-snapshots to turn them back to normal before reintegrating your branch 2009/4/22 Michael Hüttermann > ok, I see, thanks! There is another concept using a generic version: > snapshots. What do you do with your SNAPSHOTs while branching then? Do you > go through all your POMs and dependencies replacing the snapshot token > with the real snapshot version including timestamp? You can say "ok, I > will never use RELEASE" but you want to use the snapshot mechanism in the > daily work for sure I guess. What's your strategy here while branching ? > > Thanks for your time !!! > > Michael > > > > > 2009/4/22 Michael Hüttermann > > > >> Hello experts, > >> > >> how do you set up the process if you use RELEASE for a dependency in a > >> POM, and work with VCS branches ? > > > > > > you stop using RELEASE for a dependency. > > > > RELEASE corresponds to the last released version... so if you release, in > > order > > > > 1.0.0 > > 1.0.1 > > 1.1.0 > > 1.1.1 > > 2.0.0 > > 1.0.2 > > > > Then RELEASE will correspond to 1.0.2 as that was the last version > > released. > > > > The solution is to use version ranges, i.e. work on the 1.0.x branch > would > > depend on [1.0.0,1.1.0-!) that is any version greater than or equal to > > 1.0.0 > > and less than 1.1.0-! (which thanks to the joys of ascii sorting means > > that > > you will exclude any 1.1.0 version including 1.1.0-SNAPSHOT which is less > > than 1.1.0) > > > > Of course version ranges only work if you follow maven's rules for > version > > numbering... if you cannot follow maven's (some would say slightly > > strange) > > version numbering scheme you will need to do some manual work... to help > > automate the manual work, you'll probably end up using > > versions-maven-plugin > > and specifying the version using a property. > > > > > >> What is your best practice? Probably a > >> branch will have to adress another, older version of an artifact, > >> actually > >> it has to adress a stable, tagged version. What happens if on HEAD you > >> use > >> new versions of dependencies (so a new version for RELEASE), ... do you > >> adjust all of your branches to remove the RELEASE token and enter a > >> dedicated version? Isn't that a nightmare ? > > > > > > I think you will realise from my earlier comment that there is *no way in > > hell* that you would use RELEASE. > > > > FYI, the LATEST and RELEASE versions were initially more for use in > > specifying plugin versions... but they are so problematic that everyone > > pretty much avoids them > > > > -Stephen > > > >> > >> > >> Thanks !! > >> > >> > >> Michael > >> > >> - > >> 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: RELEASE and branches
Which is where using properties and the versions-maven-plugin comes to the
rescue
...
...
com.foobar
foobar-core
${foobar-version}
com.foobar
foobar-optional
${foobar-version}
...
...
1.2
...
org.codehaus.mojo
versions-maven-plugin
1.0-alpha-3-SNAPSHOT
foobar-version
[1.2,2.0-!)
...
running
mvn versions:update-properties
will look for newer versions of both linked artifacts that are within the
specified range and update the property if required.
mvn versions:update-properties -DallowSnapshots=true
is the only way to get -SNAPSHOT versions...
Note: if your reactor contained a -SNAPSHOT version of both of the foobar
dependencies, then update-properties will detect this and assume that you
probably want to use the version from the reactor and not the previous
release... but there's a flag to turn that behaviour off.
-Stephen
2009/4/22 David Hoffer
> Unfortunately version ranges have so many bugs i don't find them useful
> either. The problem with version ranges is that they will, in most cases,
> include snapshots although that's both not intended and violates the
> version
> range spec.
>
> -Dave
>
> On Wed, Apr 22, 2009 at 10:05 AM, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
> > 2009/4/22 Michael Hüttermann
> >
> > > Hello experts,
> > >
> > > how do you set up the process if you use RELEASE for a dependency in a
> > > POM, and work with VCS branches ?
> >
> >
> > you stop using RELEASE for a dependency.
> >
> > RELEASE corresponds to the last released version... so if you release, in
> > order
> >
> > 1.0.0
> > 1.0.1
> > 1.1.0
> > 1.1.1
> > 2.0.0
> > 1.0.2
> >
> > Then RELEASE will correspond to 1.0.2 as that was the last version
> > released.
> >
> > The solution is to use version ranges, i.e. work on the 1.0.x branch
> would
> > depend on [1.0.0,1.1.0-!) that is any version greater than or equal to
> > 1.0.0
> > and less than 1.1.0-! (which thanks to the joys of ascii sorting means
> that
> > you will exclude any 1.1.0 version including 1.1.0-SNAPSHOT which is less
> > than 1.1.0)
> >
> > Of course version ranges only work if you follow maven's rules for
> version
> > numbering... if you cannot follow maven's (some would say slightly
> strange)
> > version numbering scheme you will need to do some manual work... to help
> > automate the manual work, you'll probably end up using
> > versions-maven-plugin
> > and specifying the version using a property.
> >
> >
> > > What is your best practice? Probably a
> > > branch will have to adress another, older version of an artifact,
> > actually
> > > it has to adress a stable, tagged version. What happens if on HEAD you
> > use
> > > new versions of dependencies (so a new version for RELEASE), ... do you
> > > adjust all of your branches to remove the RELEASE token and enter a
> > > dedicated version? Isn't that a nightmare ?
> >
> >
> > I think you will realise from my earlier comment that there is *no way in
> > hell* that you would use RELEASE.
> >
> > FYI, the LATEST and RELEASE versions were initially more for use in
> > specifying plugin versions... but they are so problematic that everyone
> > pretty much avoids them
> >
> > -Stephen
> >
> > >
> > >
> > > Thanks !!
> > >
> > >
> > > Michael
> > >
> > > -
> > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: users-h...@maven.apache.org
> > >
> > >
> >
>
Re: RELEASE and branches
ok, I see, thanks! There is another concept using a generic version: snapshots. What do you do with your SNAPSHOTs while branching then? Do you go through all your POMs and dependencies replacing the snapshot token with the real snapshot version including timestamp? You can say "ok, I will never use RELEASE" but you want to use the snapshot mechanism in the daily work for sure I guess. What's your strategy here while branching ? Thanks for your time !!! Michael > 2009/4/22 Michael Hüttermann > >> Hello experts, >> >> how do you set up the process if you use RELEASE for a dependency in a >> POM, and work with VCS branches ? > > > you stop using RELEASE for a dependency. > > RELEASE corresponds to the last released version... so if you release, in > order > > 1.0.0 > 1.0.1 > 1.1.0 > 1.1.1 > 2.0.0 > 1.0.2 > > Then RELEASE will correspond to 1.0.2 as that was the last version > released. > > The solution is to use version ranges, i.e. work on the 1.0.x branch would > depend on [1.0.0,1.1.0-!) that is any version greater than or equal to > 1.0.0 > and less than 1.1.0-! (which thanks to the joys of ascii sorting means > that > you will exclude any 1.1.0 version including 1.1.0-SNAPSHOT which is less > than 1.1.0) > > Of course version ranges only work if you follow maven's rules for version > numbering... if you cannot follow maven's (some would say slightly > strange) > version numbering scheme you will need to do some manual work... to help > automate the manual work, you'll probably end up using > versions-maven-plugin > and specifying the version using a property. > > >> What is your best practice? Probably a >> branch will have to adress another, older version of an artifact, >> actually >> it has to adress a stable, tagged version. What happens if on HEAD you >> use >> new versions of dependencies (so a new version for RELEASE), ... do you >> adjust all of your branches to remove the RELEASE token and enter a >> dedicated version? Isn't that a nightmare ? > > > I think you will realise from my earlier comment that there is *no way in > hell* that you would use RELEASE. > > FYI, the LATEST and RELEASE versions were initially more for use in > specifying plugin versions... but they are so problematic that everyone > pretty much avoids them > > -Stephen > >> >> >> Thanks !! >> >> >> Michael >> >> - >> 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
[ANN] Sonar maven plugin 1.0-beta-1 released
The Mojo team is pleased to announce the first beta-release of Sonar maven plugin. This plugin allows to analyse sources and extract measures to Sonar, an open-source platform to manage code quality. See http://mojo.codehaus.org/sonar-maven-plugin for details. Have fun
Re: Sharing properties between modules
A you want to use the value from the parent if the parent is in the current reactor but if the parent is not in the current reactor, you want to use the value from the child? Is that what you are trying to do? -Stephen 2009/4/22 Anastasios Angelidis > Sometime we build the entire project sometimes just individual modules. > > Each module has it's own filters right now. > > Basically if the parent filter exists then use that one. If only building > an individual module then use it's filter. > > > > > Grant Rettke wrote: > >> And each individual module should have filtering on right? >>> >>> >> >> If you want to share them, what would you be filtering out? >> >> - >> 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: A style question about testing
If anything I see problems in untangling the rats nest of dependencies between code and tests if you don't just pull each one out one by one. Since the tests will initially have the entire dependency tree available, you could have a situation that tests fail to compile as you move the main code into the sub-modules... requiring adding the module that the main code was moved to as a dependency... which could result in a circular dependency hell -Stephen 2009/4/22 David Hoffer > I read it fast so maybe I missed something but I don't think I would create > modules with only tests in the hopes you will move the source there > someday. Generally speaking the maven way would be to refactor out the > source and the tests into modules and then add the new dependencies as you > go. I don't see value in moving tests first/only. > > -Dave > > On Mon, Apr 20, 2009 at 2:44 PM, Grant Rettke wrote: > > > Hi folks, > > > > I've got a question for you about managing unit testing. > > > > The situation that we are in is that right now, we have a single > > module 'Products' that has a lot of classes in it. We know that > > eventually we will refactor it into multiple modules (one for each > > Product), but at this moment we have no clue when. However, we do know > > that we have this goal in mind and that we would adhere to the > > standard main/test structure in those separated modules > > > > That said, there is a desire to get this stuff in place. The sooner I > > have a plan there the sooner I feel like it might happen. Here is how > > I am thinking I would do it: > > > > For each product that we break out, create a module, and basically > > don't have any source in it yet, just the tests, and add a test-time > > dependency for the classes being tested (back to the mega module > > basically). > > > > This way all of the individual product moules would be in place, their > > tests would be set up, developed and running, and it would allow for > > developers to migrate over the product functionality source code when > > they are ready. > > > > Is this a good approach? > > > > It makes sense, but I want to do idiomatic Maven, and I am just getting > > started. > > > > I will give this a try tomorrow. > > > > Best wishes, > > > > Grant > > > > - > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > For additional commands, e-mail: users-h...@maven.apache.org > > > > >
Re: RELEASE and branches
Unfortunately version ranges have so many bugs i don't find them useful either. The problem with version ranges is that they will, in most cases, include snapshots although that's both not intended and violates the version range spec. -Dave On Wed, Apr 22, 2009 at 10:05 AM, Stephen Connolly < stephen.alan.conno...@gmail.com> wrote: > 2009/4/22 Michael Hüttermann > > > Hello experts, > > > > how do you set up the process if you use RELEASE for a dependency in a > > POM, and work with VCS branches ? > > > you stop using RELEASE for a dependency. > > RELEASE corresponds to the last released version... so if you release, in > order > > 1.0.0 > 1.0.1 > 1.1.0 > 1.1.1 > 2.0.0 > 1.0.2 > > Then RELEASE will correspond to 1.0.2 as that was the last version > released. > > The solution is to use version ranges, i.e. work on the 1.0.x branch would > depend on [1.0.0,1.1.0-!) that is any version greater than or equal to > 1.0.0 > and less than 1.1.0-! (which thanks to the joys of ascii sorting means that > you will exclude any 1.1.0 version including 1.1.0-SNAPSHOT which is less > than 1.1.0) > > Of course version ranges only work if you follow maven's rules for version > numbering... if you cannot follow maven's (some would say slightly strange) > version numbering scheme you will need to do some manual work... to help > automate the manual work, you'll probably end up using > versions-maven-plugin > and specifying the version using a property. > > > > What is your best practice? Probably a > > branch will have to adress another, older version of an artifact, > actually > > it has to adress a stable, tagged version. What happens if on HEAD you > use > > new versions of dependencies (so a new version for RELEASE), ... do you > > adjust all of your branches to remove the RELEASE token and enter a > > dedicated version? Isn't that a nightmare ? > > > I think you will realise from my earlier comment that there is *no way in > hell* that you would use RELEASE. > > FYI, the LATEST and RELEASE versions were initially more for use in > specifying plugin versions... but they are so problematic that everyone > pretty much avoids them > > -Stephen > > > > > > > Thanks !! > > > > > > Michael > > > > - > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > For additional commands, e-mail: users-h...@maven.apache.org > > > > >
Re: A style question about testing
If anything I see problems in untangling the rats nest of dependencies between code and tests if you don't just pull each one out one by one. Since the tests will initially have the entire dependency tree available, you could have a situation that tests fail to compile as you move the main code into the sub-modules... requiring adding the module that the main code was moved to as a dependency... which could result in a circular dependency hell -Stephen 2009/4/22 David Hoffer > I read it fast so maybe I missed something but I don't think I would create > modules with only tests in the hopes you will move the source there > someday. Generally speaking the maven way would be to refactor out the > source and the tests into modules and then add the new dependencies as you > go. I don't see value in moving tests first/only. > > -Dave > > On Mon, Apr 20, 2009 at 2:44 PM, Grant Rettke wrote: > > > Hi folks, > > > > I've got a question for you about managing unit testing. > > > > The situation that we are in is that right now, we have a single > > module 'Products' that has a lot of classes in it. We know that > > eventually we will refactor it into multiple modules (one for each > > Product), but at this moment we have no clue when. However, we do know > > that we have this goal in mind and that we would adhere to the > > standard main/test structure in those separated modules > > > > That said, there is a desire to get this stuff in place. The sooner I > > have a plan there the sooner I feel like it might happen. Here is how > > I am thinking I would do it: > > > > For each product that we break out, create a module, and basically > > don't have any source in it yet, just the tests, and add a test-time > > dependency for the classes being tested (back to the mega module > > basically). > > > > This way all of the individual product moules would be in place, their > > tests would be set up, developed and running, and it would allow for > > developers to migrate over the product functionality source code when > > they are ready. > > > > Is this a good approach? > > > > It makes sense, but I want to do idiomatic Maven, and I am just getting > > started. > > > > I will give this a try tomorrow. > > > > Best wishes, > > > > Grant > > > > - > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > For additional commands, e-mail: users-h...@maven.apache.org > > > > >
Re: RELEASE and branches
2009/4/22 Michael Hüttermann > Hello experts, > > how do you set up the process if you use RELEASE for a dependency in a > POM, and work with VCS branches ? you stop using RELEASE for a dependency. RELEASE corresponds to the last released version... so if you release, in order 1.0.0 1.0.1 1.1.0 1.1.1 2.0.0 1.0.2 Then RELEASE will correspond to 1.0.2 as that was the last version released. The solution is to use version ranges, i.e. work on the 1.0.x branch would depend on [1.0.0,1.1.0-!) that is any version greater than or equal to 1.0.0 and less than 1.1.0-! (which thanks to the joys of ascii sorting means that you will exclude any 1.1.0 version including 1.1.0-SNAPSHOT which is less than 1.1.0) Of course version ranges only work if you follow maven's rules for version numbering... if you cannot follow maven's (some would say slightly strange) version numbering scheme you will need to do some manual work... to help automate the manual work, you'll probably end up using versions-maven-plugin and specifying the version using a property. > What is your best practice? Probably a > branch will have to adress another, older version of an artifact, actually > it has to adress a stable, tagged version. What happens if on HEAD you use > new versions of dependencies (so a new version for RELEASE), ... do you > adjust all of your branches to remove the RELEASE token and enter a > dedicated version? Isn't that a nightmare ? I think you will realise from my earlier comment that there is *no way in hell* that you would use RELEASE. FYI, the LATEST and RELEASE versions were initially more for use in specifying plugin versions... but they are so problematic that everyone pretty much avoids them -Stephen > > > Thanks !! > > > Michael > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: Sharing properties between modules
Sometime we build the entire project sometimes just individual modules. Each module has it's own filters right now. Basically if the parent filter exists then use that one. If only building an individual module then use it's filter. Grant Rettke wrote: And each individual module should have filtering on right? If you want to share them, what would you be filtering out? - 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: Sharing properties between modules
> And each individual module should have filtering on right? If you want to share them, what would you be filtering out? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Sharing properties between modules
And each individual module should have filtering on right? David Hoffer wrote: You can set any number of properties in the parent, that all the modules inherit. value value On Wed, Apr 22, 2009 at 9:20 AM, Anastasios Angelidis wrote: Is there any good samples out there showing how to share properties between multiple modules? I.e: Parent POM Module1 Module2 Basically both module share common database connection properties so instead of filtering in both, I would like to filter on the parent and propagate to the children. But also would like to be able to to do so on per module basis. So I should be able to build the entire project or the individual modules. Thanks - 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: Sharing properties between modules
You can set any number of properties in the parent, that all the modules inherit. value value On Wed, Apr 22, 2009 at 9:20 AM, Anastasios Angelidis wrote: > Is there any good samples out there showing how to share properties between > multiple modules? > > I.e: > > Parent POM > Module1 > Module2 > > Basically both module share common database connection properties so > instead of filtering in both, I would like to filter on the parent and > propagate to the children. But also would like to be able to to do so on per > module basis. > > So I should be able to build the entire project or the individual modules. > > Thanks > > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: A style question about testing
I read it fast so maybe I missed something but I don't think I would create modules with only tests in the hopes you will move the source there someday. Generally speaking the maven way would be to refactor out the source and the tests into modules and then add the new dependencies as you go. I don't see value in moving tests first/only. -Dave On Mon, Apr 20, 2009 at 2:44 PM, Grant Rettke wrote: > Hi folks, > > I've got a question for you about managing unit testing. > > The situation that we are in is that right now, we have a single > module 'Products' that has a lot of classes in it. We know that > eventually we will refactor it into multiple modules (one for each > Product), but at this moment we have no clue when. However, we do know > that we have this goal in mind and that we would adhere to the > standard main/test structure in those separated modules > > That said, there is a desire to get this stuff in place. The sooner I > have a plan there the sooner I feel like it might happen. Here is how > I am thinking I would do it: > > For each product that we break out, create a module, and basically > don't have any source in it yet, just the tests, and add a test-time > dependency for the classes being tested (back to the mega module > basically). > > This way all of the individual product moules would be in place, their > tests would be set up, developed and running, and it would allow for > developers to migrate over the product functionality source code when > they are ready. > > Is this a good approach? > > It makes sense, but I want to do idiomatic Maven, and I am just getting > started. > > I will give this a try tomorrow. > > Best wishes, > > Grant > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Sharing properties between modules
Is there any good samples out there showing how to share properties between multiple modules? I.e: Parent POM Module1 Module2 Basically both module share common database connection properties so instead of filtering in both, I would like to filter on the parent and propagate to the children. But also would like to be able to to do so on per module basis. So I should be able to build the entire project or the individual modules. Thanks - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: How to bundle the dependant jars with in the lib folder of war module?
Try these two links - http://maven.apache.org/plugins/maven-war-plugin/examples/skinny-wars.html http://docs.codehaus.org/display/MAVENUSER/Solving+the+Skinny+Wars+problem -Kyle On Tue, Apr 21, 2009 at 11:39 PM, RaviPotnuru wrote: > > I have an EAR project for which the poms were already written, now i want > jars to be bundled with war modules lib folder and those shouldn't be part > of the EAR module, can some one please help me in this regard. Briefly I > want all my dependancies should be bundled with in the war and they > shouldn,t be at ear level. Your help in this regard is greatly > appreciated... thank you. > -- > View this message in context: > http://www.nabble.com/How-to-bundle-the-dependant-jars-with-in-the-lib-folder-of-war-module--tp23169133p23169133.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 > > -- -Act as if it were impossible to fail
maven-antrun-plugin 1.2 upgrade to 1.3
Hi I have pom which calls ant build file, ant build file has some echo statements After upgrading from 1.2 to 1.3 ant output to console is not visible anymore and also end message from maven about successful build are also gone. on command line looks like script is simply terminated. At the beginning i see ant echo output in console, but then there is triggered some log4j output also written to console and after that ant and maven output to console is doesn't show up. It works correct if i set version 1.2 - after printing log4j statements i see ant echo and maven build successful messages. has anyone have observed similar issue, may be its a bug? thanks juris - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven, jsp files in dependency
> I'm using maven2 for dependency management. I have one project that contains > some java files and some jsp files and another project, a web project, that Assuming both projects are using War packaging, you would simply use War Overlays: http://maven.apache.org/plugins/maven-war-plugin/examples/war-overlay.html Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
mvn eclipse:eclipse - creating psf file
Hi, Is there a way to create team project set (*.psf) file from pom when executing mvn eclipse:eclipse? Thanks, Vladimir - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RELEASE and branches
Hello experts, how do you set up the process if you use RELEASE for a dependency in a POM, and work with VCS branches ? What is your best practice? Probably a branch will have to adress another, older version of an artifact, actually it has to adress a stable, tagged version. What happens if on HEAD you use new versions of dependencies (so a new version for RELEASE), ... do you adjust all of your branches to remove the RELEASE token and enter a dedicated version? Isn't that a nightmare ? Thanks !! Michael - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: scm:add question
Hi! The short answer is: why not simply call git-add [files], git-commit, git-push ? If you use SVN you also wouldn't use mvn scm:add, isn't? The long answer is: I honestly have no clue why this happens :) I get the fileSet.getFileList() in the executeAddCommand and simply add all the files in it to the git-add command line. (we could add a '--' for safety reasons btw) So I' need a bit more debug output via mvn -X. A JIRA would also be nice :) And this should btw go to the scm list to not scare users with internal stuff ;) LieGrue, strub --- Ryan Connolly schrieb am Mi, 22.4.2009: > Von: Ryan Connolly > Betreff: Re: scm:add question > An: "Maven Users List" > Datum: Mittwoch, 22. April 2009, 15:12 > How about using */** for > includes? Also, maybe run using -e to see > the stack trace if available? That may help you debug > this issue as > well. > > On Wed, Apr 22, 2009 at 9:00 AM, Sean Davis > wrote: > > On Wed, Apr 22, 2009 at 8:40 AM, Ryan Connolly > wrote: > > > >> It looks as though you are trying to add > everything in the src dir but > >> the plugin is complaining that it does not know > what it is you want to > >> add... I would try passing the optional includes > property to the > >> plugin configuration to see if that changes > things. > > > > > > Thanks, Ryan, for the suggestion. > > > > mvn scm:add -Dmaven.scm.basedir=./src > -Dmaven.scm.src.includes=* > > > > produces the same result. > > > > Sean > > > > > >> > >> On Wed, Apr 22, 2009 at 8:27 AM, Sean Davis > wrote: > >> > I am pretty new to maven and I am trying to > use the maven scm plugin to > >> add > >> > files and then commit to a bare git > repository (located on the file > >> system). > >> > > >> > In my pom, I have: > >> > > >> > > >> > > scm:git:file://localhost/tmp/stuff.git > >> > > >> > > >> > scm:git:file://localhost/tmp/stuff.git > >> > > >> > > >> > Then, I am executing from the command line > and in the base directory of > >> the > >> > project (directory contains pom.xml): > >> > > >> > sdavis$ mvn scm:add > -Dmaven.scm.basedir=./src > >> > [INFO] Scanning for projects... > >> > [INFO] Searching repository for plugin with > prefix: 'scm'. > >> > [INFO] > >> > > > >> > [INFO] Building SeqWrench > >> > [INFO] task-segment: [scm:add] > (aggregator-style) > >> > [INFO] > >> > > > >> > [INFO] [scm:add] > >> > [INFO] > >> > > > >> > [ERROR] BUILD ERROR > >> > [INFO] > >> > > > >> > [INFO] Cannot run add command : > >> > > >> > Embedded error: Exception while executing SCM > command. > >> > You must provide at least one file/directory > to add > >> > > >> > Any suggestions on what I am missing? > >> > > >> > Thanks, > >> > Sean > >> > > >> > >> > >> > >> -- > >> �...@n > >> > >> > - > >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > >> For additional commands, e-mail: users-h...@maven.apache.org > >> > >> > > > > > > -- > �...@n > > - > 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: scm:add question
How about using */** for includes? Also, maybe run using -e to see the stack trace if available? That may help you debug this issue as well. On Wed, Apr 22, 2009 at 9:00 AM, Sean Davis wrote: > On Wed, Apr 22, 2009 at 8:40 AM, Ryan Connolly wrote: > >> It looks as though you are trying to add everything in the src dir but >> the plugin is complaining that it does not know what it is you want to >> add... I would try passing the optional includes property to the >> plugin configuration to see if that changes things. > > > Thanks, Ryan, for the suggestion. > > mvn scm:add -Dmaven.scm.basedir=./src -Dmaven.scm.src.includes=* > > produces the same result. > > Sean > > >> >> On Wed, Apr 22, 2009 at 8:27 AM, Sean Davis wrote: >> > I am pretty new to maven and I am trying to use the maven scm plugin to >> add >> > files and then commit to a bare git repository (located on the file >> system). >> > >> > In my pom, I have: >> > >> > >> > scm:git:file://localhost/tmp/stuff.git >> > >> > >> scm:git:file://localhost/tmp/stuff.git >> > >> > >> > Then, I am executing from the command line and in the base directory of >> the >> > project (directory contains pom.xml): >> > >> > sdavis$ mvn scm:add -Dmaven.scm.basedir=./src >> > [INFO] Scanning for projects... >> > [INFO] Searching repository for plugin with prefix: 'scm'. >> > [INFO] >> > >> > [INFO] Building SeqWrench >> > [INFO] task-segment: [scm:add] (aggregator-style) >> > [INFO] >> > >> > [INFO] [scm:add] >> > [INFO] >> > >> > [ERROR] BUILD ERROR >> > [INFO] >> > >> > [INFO] Cannot run add command : >> > >> > Embedded error: Exception while executing SCM command. >> > You must provide at least one file/directory to add >> > >> > Any suggestions on what I am missing? >> > >> > Thanks, >> > Sean >> > >> >> >> >> -- >> �...@n >> >> - >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> For additional commands, e-mail: users-h...@maven.apache.org >> >> > -- �...@n - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Configure JCoverage maven plugin
I would personally use Cobertura plugin as according to the JCoverage plugin site, it is deprecated and no longer maintained. http://maven.apache.org/maven-1.x/plugins/jcoverage/index.html On Wed, Apr 22, 2009 at 8:46 AM, Chirag Trivedi wrote: > > Hi, > > I have maven project in which I build my java source files and execute JUnit > test cases on it. Now, I want to find out the code coverage and have > installed JCoverage maven plugin. > > What steps I have to follow to configure the JCoverage maven plugin > > Thanks & Regards, > Chirag Trivedi > > > Now surf faster and smarter ! Check out the new Firefox 3 - Yahoo! > Edition http://downloads.yahoo.com/in/firefox/ > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > -- �...@n - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: scm:add question
On Wed, Apr 22, 2009 at 8:40 AM, Ryan Connolly wrote: > It looks as though you are trying to add everything in the src dir but > the plugin is complaining that it does not know what it is you want to > add... I would try passing the optional includes property to the > plugin configuration to see if that changes things. Thanks, Ryan, for the suggestion. mvn scm:add -Dmaven.scm.basedir=./src -Dmaven.scm.src.includes=* produces the same result. Sean > > On Wed, Apr 22, 2009 at 8:27 AM, Sean Davis wrote: > > I am pretty new to maven and I am trying to use the maven scm plugin to > add > > files and then commit to a bare git repository (located on the file > system). > > > > In my pom, I have: > > > > > >scm:git:file://localhost/tmp/stuff.git > > > > > scm:git:file://localhost/tmp/stuff.git > > > > > > Then, I am executing from the command line and in the base directory of > the > > project (directory contains pom.xml): > > > > sdavis$ mvn scm:add -Dmaven.scm.basedir=./src > > [INFO] Scanning for projects... > > [INFO] Searching repository for plugin with prefix: 'scm'. > > [INFO] > > > > [INFO] Building SeqWrench > > [INFO]task-segment: [scm:add] (aggregator-style) > > [INFO] > > > > [INFO] [scm:add] > > [INFO] > > > > [ERROR] BUILD ERROR > > [INFO] > > > > [INFO] Cannot run add command : > > > > Embedded error: Exception while executing SCM command. > > You must provide at least one file/directory to add > > > > Any suggestions on what I am missing? > > > > Thanks, > > Sean > > > > > > -- > �...@n > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Configure JCoverage maven plugin
Hi, I have maven project in which I build my java source files and execute JUnit test cases on it. Now, I want to find out the code coverage and have installed JCoverage maven plugin. What steps I have to follow to configure the JCoverage maven plugin Thanks & Regards, Chirag Trivedi Now surf faster and smarter ! Check out the new Firefox 3 - Yahoo! Edition http://downloads.yahoo.com/in/firefox/ - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
maven, jsp files in dependency
Hi I'm using maven2 for dependency management. I have one project that contains some java files and some jsp files and another project, a web project, that depends on the first project. How do I access the jsp files from the web project? I can see that the jsp files are added to 1-0-SNAPSHOT-sources.jar and not 1-0-SNAPSHOT.jar ( which is added as a dependency in the web projects pom.xml) ... Any suggestions would be appreciated.. -- View this message in context: http://www.nabble.com/maven%2C-jsp-files-in-dependency-tp23175420p23175420.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: scm:add question
It looks as though you are trying to add everything in the src dir but the plugin is complaining that it does not know what it is you want to add... I would try passing the optional includes property to the plugin configuration to see if that changes things. On Wed, Apr 22, 2009 at 8:27 AM, Sean Davis wrote: > I am pretty new to maven and I am trying to use the maven scm plugin to add > files and then commit to a bare git repository (located on the file system). > > In my pom, I have: > > > scm:git:file://localhost/tmp/stuff.git > > scm:git:file://localhost/tmp/stuff.git > > > Then, I am executing from the command line and in the base directory of the > project (directory contains pom.xml): > > sdavis$ mvn scm:add -Dmaven.scm.basedir=./src > [INFO] Scanning for projects... > [INFO] Searching repository for plugin with prefix: 'scm'. > [INFO] > > [INFO] Building SeqWrench > [INFO] task-segment: [scm:add] (aggregator-style) > [INFO] > > [INFO] [scm:add] > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Cannot run add command : > > Embedded error: Exception while executing SCM command. > You must provide at least one file/directory to add > > Any suggestions on what I am missing? > > Thanks, > Sean > -- �...@n - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Maven site links
Hi: I have another query regarding maven site generation, in particular how does one create links that open in a new window? I'm seeing the icon for indicating that a link opens in a new window in skin resources and would like my javadocs, test coverage reports and others to open in a new window. How is this acheived? Must one modify the velocity template to acheive this or is there a way to do this in site.xml or perhaps another way I am unaware of? Any info on this subject would be very helpful. Thanks in advance. -Ryan - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
scm:add question
I am pretty new to maven and I am trying to use the maven scm plugin to add files and then commit to a bare git repository (located on the file system). In my pom, I have: scm:git:file://localhost/tmp/stuff.git scm:git:file://localhost/tmp/stuff.git Then, I am executing from the command line and in the base directory of the project (directory contains pom.xml): sdavis$ mvn scm:add -Dmaven.scm.basedir=./src [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'scm'. [INFO] [INFO] Building SeqWrench [INFO]task-segment: [scm:add] (aggregator-style) [INFO] [INFO] [scm:add] [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Cannot run add command : Embedded error: Exception while executing SCM command. You must provide at least one file/directory to add Any suggestions on what I am missing? Thanks, Sean
Adding org.apache.log4j.logger to a Java project
Good Morning, I want to add org.apache.log4j.logger to a Java Netbeans Project, using the codehaus plugin. In the line: private static final Logger LOG = Logger.getLogger(DivisionUtil.class); I use the right button, and select the option: "Search Dependency at Maven Repository for Loggers", and it appears a lot of actions, not the one I am looking for. I have two answers: 1) Where is the file where specifies where is maven looking for? 2) How can I solve this problem? Thanks in advance, Jaime. -- View this message in context: http://www.nabble.com/Adding-org.apache.log4j.logger-to-a-Java-project-tp23173514p23173514.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: going mad :-) testing archetype
Hi, The filtering of the files in the archetype plugin is done using Velocity. This means that ech filtered file is a Velocity template. # is a comment char in velocity. If your file has no filtering to be done on it (don't use properties asked by the plugin), consider putting it in a non-filtered fileset in your archetype-metadata. Another option could be to create your archetype from a sample project, see what is automatically done then hack the created archetype where the automatic creation don't fit your needs. Regards, Raphaël 2009/4/22 Lachlan Deck > On 22/04/2009, at 7:15 PM, Nick Stolwijk wrote: > > Could you try it with the debug option (-X). Maybe that shows what jar >> file gets extracted. >> > > I just identified the problem. In a properties file I had the following in > the archetype: > > ## > # Some section heading > ## > some.java.property = foo > > And in the generated project the '##' were getting > stripped. > > Not sure why. Is this documented somewhere? > (These were the only lines I'd added. By adding a bogus java property I see > that the file is certainly being used.) > > > with regards, > -- > > Lachlan Deck > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: going mad :-) testing archetype
On 22/04/2009, at 7:15 PM, Nick Stolwijk wrote: Could you try it with the debug option (-X). Maybe that shows what jar file gets extracted. I just identified the problem. In a properties file I had the following in the archetype: ## # Some section heading ## some.java.property = foo And in the generated project the '##' were getting stripped. Not sure why. Is this documented somewhere? (These were the only lines I'd added. By adding a bogus java property I see that the file is certainly being used.) with regards, -- Lachlan Deck - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: going mad :-) testing archetype
Could you try it with the debug option (-X). Maybe that shows what jar file gets extracted. Hth, Nick Stolwijk ~Java Developer~ Iprofs BV. Claus Sluterweg 125 2012 WS Haarlem www.iprofs.nl On Wed, Apr 22, 2009 at 10:45 AM, Lachlan Deck wrote: > On 22/04/2009, at 6:27 PM, Nick Stolwijk wrote: > >> Are there any other version of your archetype in >> ~/.m2/repository/my/groupId/my-archetype? > > No. I deleted the dir prior to installing. > >> With regards, >> >> Nick Stolwijk >> ~Java Developer~ >> >> Iprofs BV. >> Claus Sluterweg 125 >> 2012 WS Haarlem >> www.iprofs.nl >> >> >> >> On Wed, Apr 22, 2009 at 10:25 AM, Lachlan Deck >> wrote: >>> >>> ~/.m2/repository/my/groupId/my-archetype >> >> - >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> For additional commands, e-mail: users-h...@maven.apache.org >> > > with regards, > -- > > Lachlan Deck > > > > > - > 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
pom does not get installed, if classifier used
Hi All, when I do a 'mvn install' and the maven jar/ejb plugin is configured to use a classifier e.g. ... maven-jar-plugin dev ... only the .jar file gets installed in the local repository. If I don't use a classifier the pom gets installed alongside the .jar file. and maven-metadata-local.xml file is created in the directory above. Is not installing the pom if a classifier is used the intended behaviour? I'm using Maven 2.0.10 and tested this only for jar and ejb types. Thanks, Niklas. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: going mad :-) testing archetype
On 22/04/2009, at 6:27 PM, Nick Stolwijk wrote: Are there any other version of your archetype in ~/.m2/repository/my/groupId/my-archetype? No. I deleted the dir prior to installing. With regards, Nick Stolwijk ~Java Developer~ Iprofs BV. Claus Sluterweg 125 2012 WS Haarlem www.iprofs.nl On Wed, Apr 22, 2009 at 10:25 AM, Lachlan Deck wrote: ~/.m2/repository/my/groupId/my-archetype - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org with regards, -- Lachlan Deck - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: going mad :-) testing archetype
On 22/04/2009, at 6:35 PM, William Ghelfi wrote: On Wed, Apr 22, 2009 at 10:25 AM, Lachlan Deck wrote: $ cd ~/ $ mkdir test && cd test $ mvn -o archetype:generate -DarchetypeCatalog=local <...> Choose archetype: 1: local -> my-archetype (Yada yada) <...> Choose a number: (1/2/3/4): 1 Define value for groupId: : my.grouping Define value for artifactId: : myapp Define value for version: 1.0-SNAPSHOT: : Define value for package: my.grouping: : Confirm properties configuration: <...> Y: : [INFO] [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 37 seconds [INFO] Finished at: Wed Apr 22 17:57:04 EST 2009 [INFO] Final Memory: 8M/15M [INFO] $ $ less myapp/src/main/resources/Properties --> still doesn't contain the text I've added :-/ Sorry for the question... Not at all... Did you remember to create a new app using the new archetype, and then checked the new app? That's what the output above shows. i.e., me creating a new app after having installed the archetype. Quite strange. with regards, -- Lachlan Deck - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: going mad :-) testing archetype
On Wed, Apr 22, 2009 at 10:25 AM, Lachlan Deck wrote: > $ cd ~/ > $ mkdir test && cd test > $ mvn -o archetype:generate -DarchetypeCatalog=local > <...> > Choose archetype: > 1: local -> my-archetype (Yada yada) > <...> > Choose a number: (1/2/3/4): 1 > Define value for groupId: : my.grouping > Define value for artifactId: : myapp > Define value for version: 1.0-SNAPSHOT: : > Define value for package: my.grouping: : > Confirm properties configuration: > <...> > Y: : > [INFO] > > [INFO] BUILD SUCCESSFUL > [INFO] > > [INFO] Total time: 37 seconds > [INFO] Finished at: Wed Apr 22 17:57:04 EST 2009 > [INFO] Final Memory: 8M/15M > [INFO] > > $ > $ less myapp/src/main/resources/Properties --> still doesn't contain the > text I've added :-/ > Sorry for the question... Did you remember to create a new app using the new archetype, and then checked the new app? William - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: going mad :-) testing archetype
Are there any other version of your archetype in ~/.m2/repository/my/groupId/my-archetype? With regards, Nick Stolwijk ~Java Developer~ Iprofs BV. Claus Sluterweg 125 2012 WS Haarlem www.iprofs.nl On Wed, Apr 22, 2009 at 10:25 AM, Lachlan Deck wrote: > ~/.m2/repository/my/groupId/my-archetype - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
going mad :-) testing archetype
just need a sanity check here :-) I'm trying to test some updates to an archetype. So I've edited a particular file, for example, such as the following: $ emacs my-archetype/src/main/resources/archetype-resources/src/main/ resources/Properties I've cleaned my local repo of the artifacts in the same groupId and then re-installed it: $ mvn -o clean install But then when I generate a project from the archetype the adjustments I've made don't appear. $ cd ~/ $ mkdir test && cd test $ mvn -o archetype:generate -DarchetypeCatalog=local <...> Choose archetype: 1: local -> my-archetype (Yada yada) <...> Choose a number: (1/2/3/4): 1 Define value for groupId: : my.grouping Define value for artifactId: : myapp Define value for version: 1.0-SNAPSHOT: : Define value for package: my.grouping: : Confirm properties configuration: <...> Y: : [INFO] [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 37 seconds [INFO] Finished at: Wed Apr 22 17:57:04 EST 2009 [INFO] Final Memory: 8M/15M [INFO] $ $ less myapp/src/main/resources/Properties --> still doesn't contain the text I've added :-/ So digging deeper: $ cp ~/.m2/repository/my/groupId/my-archetype/2.0.18-SNAPSHOT/my- archetype-2.0.18-SNAPSHOT.jar . $ mv my-archetype-2.0.18-SNAPSHOT.jar my-archetype-2.0.18-SNAPSHOT.zip $ unzip my-archetype-2.0.18-SNAPSHOT.zip $ less archetype-resources/src/main/resources/Properties --> looks good! There's gotta be something obvious I'm missing ... any clues? Is there some cache I've overlooked? :-) Thanks. Is maven caching the old versions (that I've deleted) somewhere else? How do I ensure that I'm testing what I've installed? Thanks. with regards, -- Lachlan Deck - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
