Re: Now seriously: how can I manage dependencies of own projects with maven
On Wed, Oct 20, 2010 at 8:12 AM, Michael McCallum mich...@redengine.co.nz wrote: You could try something like... mvn -s special-settings-file.xml verify install haha. Hudson has a horrible bug involving -s that the maintainers keep claiming to fix and failing to fix. Perhaps some day. set that up for the jobs in hudson that should share snapshots... and for the others mvn verify So you end up with two sets of jobs * those the build the head of an artifact against the heads of the others * those that build the head of an artifact against the latest releases of the others (assuming you use ranges of course) cheers Michael On Wednesday 20 October 2010 00:25:33 Benson Margulies wrote: If you are using 'downstream', how do you avoid the need to publish to at least a common local repo? I've been facing the following variation on this: I do not want to publish snapshots to nexus, since they mess up people who download stale ones into their development process. I do want to split a hudson build into multiple jobs with dependencies. Short of an extra repo in nexus that is used only for intra-hudson snapshots, I haven't thought of anything. Have you? - 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: Now seriously: how can I manage dependencies of own projects with maven
On 18 October 2010 23:15, Zac Thompson z...@zac.ca wrote: On Fri, Oct 15, 2010 at 6:34 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: I just set up a big fat aggrigator for each of the test everything together projects that I want to run CI over. I use svn:externals to check everything out and then two maven builders, first to update the aggregator and all child modules to link them together and the second to run verify. That way I never pollute the local repo... and these types of build run less frequently (hourly), so the slower build is less of an issue. Thanks for this bit, Stephen; I've been considering doing exactly this for a little while, so it's good to know you've already proven it can work well in practice. I think nightly is good enough in my case. I haven't tried using externals with Hudson yet, so I'm curious: does your hourly build always run whether there have been changes or not, or are you getting Hudson to check for updates first? I set it as downstream of each module's job so that if the svn:externals build correctly, then we trigger a build of the latest integration uber-build - 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: Now seriously: how can I manage dependencies of own projects with maven
If you are using 'downstream', how do you avoid the need to publish to at least a common local repo? I've been facing the following variation on this: I do not want to publish snapshots to nexus, since they mess up people who download stale ones into their development process. I do want to split a hudson build into multiple jobs with dependencies. Short of an extra repo in nexus that is used only for intra-hudson snapshots, I haven't thought of anything. Have you? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Now seriously: how can I manage dependencies of own projects with maven
because downstream is the trigger, the build checks everything out and uses an uber-aggregator build so that all the artifacts will be in the reactor which is how mvn verify can work (no need for clean because I do a clean checkout for every build) On 19 October 2010 12:25, Benson Margulies bimargul...@gmail.com wrote: If you are using 'downstream', how do you avoid the need to publish to at least a common local repo? I've been facing the following variation on this: I do not want to publish snapshots to nexus, since they mess up people who download stale ones into their development process. I do want to split a hudson build into multiple jobs with dependencies. Short of an extra repo in nexus that is used only for intra-hudson snapshots, I haven't thought of anything. Have you? - 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: Now seriously: how can I manage dependencies of own projects with maven
On Tue, Oct 19, 2010 at 7:28 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: because downstream is the trigger, the build checks everything out and uses an uber-aggregator build so that all the artifacts will be in the reactor which is how mvn verify can work (no need for clean because I do a clean checkout for every build) I'm confused between the implications of 'uberaggregated' and 'downstream'. You've combined all the pieces into one giant build that is downstream of something else, right? OK, I see. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Now seriously: how can I manage dependencies of own projects with maven
On 19 October 2010 12:42, Benson Margulies bimargul...@gmail.com wrote: On Tue, Oct 19, 2010 at 7:28 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: because downstream is the trigger, the build checks everything out and uses an uber-aggregator build so that all the artifacts will be in the reactor which is how mvn verify can work (no need for clean because I do a clean checkout for every build) I'm confused between the implications of 'uberaggregated' and 'downstream'. You've combined all the pieces into one giant build that is downstream of something else, right? OK, I see. it's downstream of the trunks of each of it's components... the trunk projects build svn as is and are triggered by svn trigger this is the latest of everything project and that builds only if the constituent trunk projects are building, and wht it is building is not the code in svn but the code in svn after re-linking to the reactor hmmm I think I might have a new feature for versions-m-p (versions:use-reactor) -Stephen - 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: Now seriously: how can I manage dependencies of own projects with maven
Attached is a sample of how I configure the builders (using update-properties as my inter-module deps are via properties for this uber-integration-project) the principle remains the same On 19 October 2010 12:50, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On 19 October 2010 12:42, Benson Margulies bimargul...@gmail.com wrote: On Tue, Oct 19, 2010 at 7:28 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: because downstream is the trigger, the build checks everything out and uses an uber-aggregator build so that all the artifacts will be in the reactor which is how mvn verify can work (no need for clean because I do a clean checkout for every build) I'm confused between the implications of 'uberaggregated' and 'downstream'. You've combined all the pieces into one giant build that is downstream of something else, right? OK, I see. it's downstream of the trunks of each of it's components... the trunk projects build svn as is and are triggered by svn trigger this is the latest of everything project and that builds only if the constituent trunk projects are building, and wht it is building is not the code in svn but the code in svn after re-linking to the reactor hmmm I think I might have a new feature for versions-m-p (versions:use-reactor) -Stephen - 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: Now seriously: how can I manage dependencies of own projects with maven
Attached is a sample of how I configure the builders (using update-properties as my inter-module deps are via properties for this uber-integration-project) the principle remains the same Either you failed to attach anything, or it got stripped. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Now seriously: how can I manage dependencies of own projects with maven
stripped On 19 October 2010 16:50, Wayne Fay wayne...@gmail.com wrote: Attached is a sample of how I configure the builders (using update-properties as my inter-module deps are via properties for this uber-integration-project) the principle remains the same Either you failed to attach anything, or it got stripped. Wayne - 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: Now seriously: how can I manage dependencies of own projects with maven
On Fri, Oct 15, 2010 at 6:34 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: I just set up a big fat aggrigator for each of the test everything together projects that I want to run CI over. I use svn:externals to check everything out and then two maven builders, first to update the aggregator and all child modules to link them together and the second to run verify. That way I never pollute the local repo... and these types of build run less frequently (hourly), so the slower build is less of an issue. Thanks for this bit, Stephen; I've been considering doing exactly this for a little while, so it's good to know you've already proven it can work well in practice. I think nightly is good enough in my case. I haven't tried using externals with Hudson yet, so I'm curious: does your hourly build always run whether there have been changes or not, or are you getting Hudson to check for updates first? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Now seriously: how can I manage dependencies of own projects with maven
Hello, following situation: I have like 20 projects which are libs of different level. They are all built as jars. They are partially dependent on each other (not circularly). For example project A provides very basic utils. Project B is more specialized and depends on A. Project C depends on A, project D on A and C. I have two requirements: First: I want them to depend on a released version of each other, not necessary last release, but preferred. This work if I declare the dependency as RELEASE or a version number like 1.0.2 Second: I want to be able to build automatically each night to check whether the last svn committed changes of the projects break the dependent projects. This works if I declare dependencies as SNAPSHOT, like 1.0.2-SNAPSHOT. The problem with SNAPSHOT is that If I release 1.0.1 of project B it upgrades the dependency of A from 1.0.1-SNAPSHOT to 1.0.2 SNAPSHOT (if I previously released an 1.0.1 of project A). As a result I am not able to release 1.0.2 of project B until I have released 1.0.2 of A, even I had no changes in A. Therefore the question, how can I teach maven that project depend on RELEASEd versions of each other for release process and dependency management on the one side, and on svn snapshots for CI purposes on the other? The only thing I can come up with right now is to have two different poms for each project, with different dependencies. But this sounds like a mess to maintain :-(. I have done this before with ant+ivy by simple declaring a file based 'local repository'. This local repository existed only in the context of a job. I than had a hudson job that checked out all 20 projects and published them one after each other into the local repository. If some versions would not compile, the job would fail and send an alert. This hasn't affected already released versions. Is something similar possible with maven? regards Leon - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Now seriously: how can I manage dependencies of own projects with maven
On 15 October 2010 07:28, Leon Rosenberg rosenberg.l...@gmail.com wrote: Hello, following situation: I have like 20 projects which are libs of different level. They are all built as jars. They are partially dependent on each other (not circularly). For example project A provides very basic utils. Project B is more specialized and depends on A. Project C depends on A, project D on A and C. I have two requirements: First: I want them to depend on a released version of each other, not necessary last release, but preferred. This work if I declare the dependency as RELEASE STOP right there! NEVER EVER USE versionRELEASE/version the tag is depricated and relies on correct metadata to work and it does not work the way you think it works. The metadata for RELEASE is the last (in time) version that was not a -SNAPSHOT and that was deployed. so if you deploy in order 1.0, 2.0, 1.0.1, 2.1, 1.0.2 then RELEASE will be equivalent to 1.0.2 and not 2.1 or a version number like 1.0.2 That is the correct way to work Second: I want to be able to build automatically each night to check whether the last svn committed changes of the projects break the dependent projects. This works if I declare dependencies as SNAPSHOT, like 1.0.2-SNAPSHOT. The problem with SNAPSHOT is that If I release 1.0.1 of project B it upgrades the dependency of A from 1.0.1-SNAPSHOT to 1.0.2 SNAPSHOT (if I previously released an 1.0.1 of project A). Sounds like a bug in either your project structure, or the maven release plugin. can you post the poms of A and B and a diagram of their layout in SVN, e.g. / + A + trunk + tags + branches + B + trunk + tags + branches As a result I am not able to release 1.0.2 of project B until I have released 1.0.2 of A, even I had no changes in A. Therefore the question, how can I teach maven that project depend on RELEASEd versions of each other for release process and dependency management on the one side, and on svn snapshots for CI purposes on the other? another trick is to have your CI build run one of the versions-maven-plugin goals before running the build. but you will actually want two CI builds, one which builds SVN exactly as it is, the other which uses v-m-p to update to the bleeding edge and build things... one of the goals like http://mojo.codehaus.org/versions-maven-plugin/use-latest-versions-mojo.html should help The only thing I can come up with right now is to have two different poms for each project, with different dependencies. But this sounds like a mess to maintain :-(. if you use v-m-p it should not be I have done this before with ant+ivy by simple declaring a file based 'local repository'. This local repository existed only in the context of a job. I than had a hudson job that checked out all 20 projects and published them one after each other into the local repository. If some versions would not compile, the job would fail and send an alert. This hasn't affected already released versions. Is something similar possible with maven? regards Leon - 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: Now seriously: how can I manage dependencies of own projects with maven
On Fri, Oct 15, 2010 at 10:31 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On 15 October 2010 07:28, Leon Rosenberg rosenberg.l...@gmail.com wrote: Hello, following situation: I have like 20 projects which are libs of different level. They are all built as jars. They are partially dependent on each other (not circularly). For example project A provides very basic utils. Project B is more specialized and depends on A. Project C depends on A, project D on A and C. I have two requirements: First: I want them to depend on a released version of each other, not necessary last release, but preferred. This work if I declare the dependency as RELEASE STOP right there! NEVER EVER USE versionRELEASE/version the tag is depricated and relies on correct metadata to work and it does not work the way you think it works. The metadata for RELEASE is the last (in time) version that was not a -SNAPSHOT and that was deployed. so if you deploy in order 1.0, 2.0, 1.0.1, 2.1, 1.0.2 then RELEASE will be equivalent to 1.0.2 and not 2.1 Good to know, thanx! or a version number like 1.0.2 That is the correct way to work Second: I want to be able to build automatically each night to check whether the last svn committed changes of the projects break the dependent projects. This works if I declare dependencies as SNAPSHOT, like 1.0.2-SNAPSHOT. The problem with SNAPSHOT is that If I release 1.0.1 of project B it upgrades the dependency of A from 1.0.1-SNAPSHOT to 1.0.2 SNAPSHOT (if I previously released an 1.0.1 of project A). Sounds like a bug in either your project structure, or the maven release plugin. can you post the poms of A and B and a diagram of their layout in SVN, e.g. / + A + trunk + tags + branches + B + trunk + tags + branches As a result I am not able to release 1.0.2 of project B until I have released 1.0.2 of A, even I had no changes in A. Therefore the question, how can I teach maven that project depend on RELEASEd versions of each other for release process and dependency management on the one side, and on svn snapshots for CI purposes on the other? another trick is to have your CI build run one of the versions-maven-plugin goals before running the build. but you will actually want two CI builds, one which builds SVN exactly as it is, the other which uses v-m-p to update to the bleeding edge and build things... one of the goals like http://mojo.codehaus.org/versions-maven-plugin/use-latest-versions-mojo.html should help Ok, from what I understood I should use versions:use-latest-snapshots from the vmp to replace all 1.0.something to 1.0.somethingelsesnapshot, build with it and tell whether its still working. If I execute mvn install on each commit I should be able to detect errors early. Is this correct? Do you know by chance whether hudson will be able to recognize that builds as dependency builds and trigger the build of dependent projects automatically? thanx regards Leon The only thing I can come up with right now is to have two different poms for each project, with different dependencies. But this sounds like a mess to maintain :-(. if you use v-m-p it should not be I have done this before with ant+ivy by simple declaring a file based 'local repository'. This local repository existed only in the context of a job. I than had a hudson job that checked out all 20 projects and published them one after each other into the local repository. If some versions would not compile, the job would fail and send an alert. This hasn't affected already released versions. Is something similar possible with maven? regards Leon - 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: Now seriously: how can I manage dependencies of own projects with maven
On 15 October 2010 12:57, Leon Rosenberg rosenberg.l...@gmail.com wrote: On Fri, Oct 15, 2010 at 10:31 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On 15 October 2010 07:28, Leon Rosenberg rosenberg.l...@gmail.com wrote: Hello, following situation: I have like 20 projects which are libs of different level. They are all built as jars. They are partially dependent on each other (not circularly). For example project A provides very basic utils. Project B is more specialized and depends on A. Project C depends on A, project D on A and C. I have two requirements: First: I want them to depend on a released version of each other, not necessary last release, but preferred. This work if I declare the dependency as RELEASE STOP right there! NEVER EVER USE versionRELEASE/version the tag is depricated and relies on correct metadata to work and it does not work the way you think it works. The metadata for RELEASE is the last (in time) version that was not a -SNAPSHOT and that was deployed. so if you deploy in order 1.0, 2.0, 1.0.1, 2.1, 1.0.2 then RELEASE will be equivalent to 1.0.2 and not 2.1 Good to know, thanx! or a version number like 1.0.2 That is the correct way to work Second: I want to be able to build automatically each night to check whether the last svn committed changes of the projects break the dependent projects. This works if I declare dependencies as SNAPSHOT, like 1.0.2-SNAPSHOT. The problem with SNAPSHOT is that If I release 1.0.1 of project B it upgrades the dependency of A from 1.0.1-SNAPSHOT to 1.0.2 SNAPSHOT (if I previously released an 1.0.1 of project A). Sounds like a bug in either your project structure, or the maven release plugin. can you post the poms of A and B and a diagram of their layout in SVN, e.g. / + A + trunk + tags + branches + B + trunk + tags + branches As a result I am not able to release 1.0.2 of project B until I have released 1.0.2 of A, even I had no changes in A. Therefore the question, how can I teach maven that project depend on RELEASEd versions of each other for release process and dependency management on the one side, and on svn snapshots for CI purposes on the other? another trick is to have your CI build run one of the versions-maven-plugin goals before running the build. but you will actually want two CI builds, one which builds SVN exactly as it is, the other which uses v-m-p to update to the bleeding edge and build things... one of the goals like http://mojo.codehaus.org/versions-maven-plugin/use-latest-versions-mojo.html should help Ok, from what I understood I should use versions:use-latest-snapshots from the vmp to replace all 1.0.something to 1.0.somethingelsesnapshot, build with it and tell whether its still working. If I execute mvn install on each commit I should be able to detect errors early. Is this correct? Do you know by chance whether hudson will be able to recognize that builds as dependency builds and trigger the build of dependent projects automatically? thanx regards Leon The only thing I can come up with right now is to have two different poms for each project, with different dependencies. But this sounds like a mess to maintain :-(. if you use v-m-p it should not be I have done this before with ant+ivy by simple declaring a file based 'local repository'. This local repository existed only in the context of a job. I than had a hudson job that checked out all 20 projects and published them one after each other into the local repository. If some versions would not compile, the job would fail and send an alert. This hasn't affected already released versions. Is something similar possible with maven? I use freestyle projects and if you are using v-m-p you will need to use them too. I just set up a big fat aggrigator for each of the test everything together projects that I want to run CI over. I use svn:externals to check everything out and then two maven builders, first to update the aggregator and all child modules to link them together and the second to run verify. That way I never pollute the local repo... and these types of build run less frequently (hourly), so the slower build is less of an issue. -Stephen regards Leon - 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
