Re: A thought on local-SNAPSHOTs
The real issue I see is people not defining their snapshot policy (and I mean that in a wider sense) Personally speaking I favour *never* deploying snapshots. Only using them for local speed up where a large reactor required to wire everything up using either the `package` or `verify` phase (with or without tests skipped) would just take too long. So for me, with my pattern of creating local aggregator projects and not really installing let alone deploying snapshots, there is no problem... When working on projects however that use a CI system to deploy snapshots after every build... Well I tend to curse them (or turn off snapshot update checking)... Worse is where this was done because building a specific artifact requires a toolchain I do not have access to on my machine... So I am forced to turn on snapshot checking for every build while working on that module. What you usually find is people have not realised the cause and effect. I favour the CI server deploying snapshots with every build *but* into a repo only for use by the CI server. I favour never deploying smapshots to developer repositories... Any time you think you need to... Well you probably just need to cut a release... Can't cut a release because tests are failing? Wtf are you giving me that broken shit for... Timestamped snapshots are just a crutch... My €0.02 On Sunday, 15 June 2014, Mark Derricutt m...@talios.com wrote: Hey all, A recent discussion on one of the github PR's led to a discussion on SNAPSHOT resolution, which is a long standing issue in maven range support with several long standing open tickets lingering. A thought I just had, which relates to some things I've been playing with in my C.I. builds, could quite simply resolve this. Maybe I know a few people who say they just don't allow/use SNAPSHOTs but whenever you do an `mvm install` you end up with a -SNAPSHOT in your ~/.m2/repository - and that then affects resolution. My thought was why is the local _repository_ treated differently to normal repositories - in that it's as tho `snapshotsenabledtrue/enabled/snapshots` is defined for them - and maybe it is? Why not simply _disable_ that. But further than that, what if maven tracked TWO local repositories: ~/.m2/repository ~/.m2/snapshots Much like `distributionManagement ` has two a `repository` and `snapshotRepository` section, what if we have an `installationManagement` section ( probably limited only to `settings.xml` for install wide settings? ) that did the same, but for the local repository? -SNAPSHOTs installed via `mvn install` or downloaded via dependencies would go in here. This way - there's a clear separation of snapshots and releases, if you don't want snapshot resolution - disable that local repository Thoughts? Mark -- Sent from my phone
Re: A thought on local-SNAPSHOTs
Op Sun, 15 Jun 2014 11:07:33 +0200 schreef Stephen Connolly stephen.alan.conno...@gmail.com: The real issue I see is people not defining their snapshot policy (and I mean that in a wider sense) Personally speaking I favour *never* deploying snapshots. Only using them for local speed up where a large reactor required to wire everything up using either the `package` or `verify` phase (with or without tests skipped) would just take too long. exactly my thoughts as well. I see a lot of users still doing 'install' for the wrong reasons: - coworkers said so / internet said so. So for me, with my pattern of creating local aggregator projects and not really installing let alone deploying snapshots, there is no problem... When working on projects however that use a CI system to deploy snapshots after every build... Well I tend to curse them (or turn off snapshot update checking)... Worse is where this was done because building a specific artifact requires a toolchain I do not have access to on my machine... So I am forced to turn on snapshot checking for every build while working on that module. What you usually find is people have not realised the cause and effect. I favour the CI server deploying snapshots with every build *but* into a repo only for use by the CI server. I favour never deploying smapshots to developer repositories... Any time you think you need to... Well you probably just need to cut a release... Can't cut a release because tests are failing? Wtf are you giving me that broken shit for... Timestamped snapshots are just a crutch... My €0.02 I like to improve the lifecycle even a bit. If you do a deploy, the install should be skipped. This way all co-workers will pull the same instance. If the deploy fails, your local repo is still clean. My current thought is to introduce the ability to split the lifecycle. : : verify /\ installdeploy This would improve the reliability of Maven, make it a bit faster and in the end both 'mvn install' and 'mvn deploy' will keep the same behavior. thanks, Robert On Sunday, 15 June 2014, Mark Derricutt m...@talios.com wrote: Hey all, A recent discussion on one of the github PR's led to a discussion on SNAPSHOT resolution, which is a long standing issue in maven range support with several long standing open tickets lingering. A thought I just had, which relates to some things I've been playing with in my C.I. builds, could quite simply resolve this. Maybe I know a few people who say they just don't allow/use SNAPSHOTs but whenever you do an `mvm install` you end up with a -SNAPSHOT in your ~/.m2/repository - and that then affects resolution. My thought was why is the local _repository_ treated differently to normal repositories - in that it's as tho `snapshotsenabledtrue/enabled/snapshots` is defined for them - and maybe it is? Why not simply _disable_ that. But further than that, what if maven tracked TWO local repositories: ~/.m2/repository ~/.m2/snapshots Much like `distributionManagement ` has two a `repository` and `snapshotRepository` section, what if we have an `installationManagement` section ( probably limited only to `settings.xml` for install wide settings? ) that did the same, but for the local repository? -SNAPSHOTs installed via `mvn install` or downloaded via dependencies would go in here. This way - there's a clear separation of snapshots and releases, if you don't want snapshot resolution - disable that local repository Thoughts? Mark - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
RE: A thought on local-SNAPSHOTs
To: dev@maven.apache.org Subject: Re: A thought on local-SNAPSHOTs Date: Sun, 15 Jun 2014 13:08:17 +0200 From: rfscho...@apache.org Op Sun, 15 Jun 2014 11:07:33 +0200 schreef Stephen Connolly stephen.alan.conno...@gmail.com: The real issue I see is people not defining their snapshot policy (and I mean that in a wider sense) Personally speaking I favour *never* deploying snapshots. Only using them for local speed up where a large reactor required to wire everything up using either the `package` or `verify` phase (with or without tests skipped) would just take too long. exactly my thoughts as well. I see a lot of users still doing 'install' for the wrong reasons: - coworkers said so / internet said so. So for me, with my pattern of creating local aggregator projects and not really installing let alone deploying snapshots, there is no problem... When working on projects however that use a CI system to deploy snapshots after every build... Well I tend to curse them (or turn off snapshot update checking)... Worse is where this was done because building a specific artifact requires a toolchain I do not have access to on my machine... So I am forced to turn on snapshot checking for every build while working on that module. What you usually find is people have not realised the cause and effect. I favour the CI server deploying snapshots with every build *but* into a repo only for use by the CI server. I favour never deploying smapshots to developer repositories... Any time you think you need to... Well you probably just need to cut a release... Can't cut a release because tests are failing? Wtf are you giving me that broken shit for... Timestamped snapshots are just a crutch... My €0.02 I like to improve the lifecycle even a bit. If you do a deploy, the install should be skipped. This way all co-workers will pull the same instance. If the deploy fails, your local repo is still clean. My current thought is to introduce the ability to split the lifecycle. : : verify /\ installdeploy This would improve the reliability of Maven, make it a bit faster and in the end both 'mvn install' and 'mvn deploy' will keep the same behavior. thanks, Robert On Sunday, 15 June 2014, Mark Derricutt m...@talios.com wrote: Hey all, A recent discussion on one of the github PR's led to a discussion on SNAPSHOT resolution, which is a long standing issue in maven range support with several long standing open tickets lingering. A thought I just had, which relates to some things I've been playing with in my C.I. builds, could quite simply resolve this. Maybe I know a few people who say they just don't allow/use SNAPSHOTs but whenever you do an `mvm install` you end up with a -SNAPSHOT in your ~/.m2/repository - and that then affects resolution. My thought was why is the local _repository_ treated differently to normal repositories - in that it's as tho `snapshotsenabledtrue/enabled/snapshots` is defined for them - and maybe it is? Why not simply _disable_ that. But further than that, what if maven tracked TWO local repositories: ~/.m2/repository ~/.m2/snapshots Much like `distributionManagement ` has two a `repository` and `snapshotRepository` section, what if we have an `installationManagement` section ( probably limited only to `settings.xml` for install wide settings? ) that did the same, but for the local repository? -SNAPSHOTs installed via `mvn install` or downloaded via dependencies would go in here. This way - there's a clear separation of snapshots and releases, if you don't want snapshot resolution - disable that local repository Thoughts? Mark MGSNAPSHOTs are Murphy on your back Not only maven but eclipse distros going into local p2 repo MGSpent most of the weekend trying to get eclipse buildnumber to sub in reasonable version on SNAPS MG24 hours later i called nojoy and mv SNAPs and success deployed eclipse distros into local p2 repo MGI agree with Stephen ..if a SNAP is'nt validated for public use dont put in any repo MGBTW: nexus repositories have 3 categories of distros SNAPs, STAGED and RELEASEs MGHappy Fathers Day - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[GitHub] maven pull request: [MNG-2199] Version ranges not supported for pa...
Github user jvanzyl commented on the pull request: https://github.com/apache/maven/pull/21#issuecomment-46114965 No, we do not use install on this particular project where we are developing the concept of a generation. We either have a project in source form locally, or we get it remotely. Everything works in the reactor because we have changed the way resolution works in the reactor. Many of the issues where you can't run eclipse:eclipse in the reactor prior to the package phase, or not being able to resolve test-jars we have fixed in our particular implementation. We are only part way through this project so I'm not sure what will remain when we are finally done, but we are doing a form of continuous delivery. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [GitHub] maven pull request: [MNG-2199] Version ranges not supported for pa...
On Jun 14, 2014, at 3:09 PM, Hervé BOUTEMY herve.bout...@free.fr wrote: Le samedi 14 juin 2014 13:33:37 Jason van Zyl a écrit : yes, but how is the constraint expressed and coded? Trying to encode these in such a way where you effectively have a property graph is hard. Aether has some preliminary support for this but not really. In practice to date it's really constrain the version or constrain what you are resolving against. Either explicit with your version as a concrete version if you want to resolve against the wild. Or you use ranges and the constraint is encoded as the list of repositories you are going to resolve against. for the moment, yes, the constraint has to be encoded as the list of repositories you resolve against: if we make this practice clear, things will get much clearer until we find another strategy (I don't have one for the moment) Given that we have a de facto formalism through our code, specifically in Aether, that I would gravitate toward using a formalized resolution model like what OSGi. I'm certainly not a huge proponent of OSGi, but they have a completely formalized and specified resolution algorithm. I really didn't find any formalisation of resolution algorithm, either in Aether of OSGi: once a list of version have been found that match the constraint, I still don't see/know what is the chosen one Can you point me to the right direction, please? You need to download the spec: http://www.osgi.org/Specifications/HomePage There is a section on versions. At any rate you have the two mode of ensuring reproducibility which is to use concrete versions against an arbitrary set of repositories, or range versions against a constrained set of a repositories. we don't have the same definition of reproducibility but yes, with range version, you can get more control using constrained set of repositories: but more control, to differentiate pre-release and release artifacts for example, is not yet reproducibility To me there is not real distinction between pre-release and release. As I move more toward continuous delivery I see it as a stream of releases all with standard versions. Right now I partition by putting them in separate repositories, maybe at some point in the future the partitioning can be logical. This would be a property graph type resolution where there is a property associated with a particular deployment that says what type it is so the system can decide whether it should participate in resolution. But that presupposes property graph based resolution and that we can actually define what these types are. That's not going to happen for a while so the most practical option for the time being is separating these types into different repositories. Nightly, integration, milestone, or whatever you happen to call them. In both cases you'll have reproducibility problems if your repositories are not managed correctly. But I think trying to come up with a property graph based resolution mechanism to deal with context is not going to happen any time soon and most likely never so I don't really think pursuing that is an option. property graph resolution mechanism is probably too much but a parametrized resolution algorithm (filtering + final selection of one version from the remaining candidates), at global build level, should be feasible - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - To do two things at once is to do neither. -- Publilius Syrus, Roman slave, first century B.C.
[VOTE] Release Apache Maven EAR Plugin version 2.9.1
Hi, We solved 2 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11132version=18776 There are still 27 issues left in JIRA: http://jira.codehaus.org/issues/?jql=project%20%3D%20MEAR%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC Staging repo: https://repository.apache.org/content/repositories/maven-1024 http://repository.apache.org/content/repositories/maven-1024/org/apache/maven/plugins/maven-ear-plugin/2.9.1/maven-ear-plugin-2.9.1-source-release.zip Source release checksum(s): maven-ear-plugin-2.9.1-source-release.zip sha1: b1f8e9e492c0199636da22c741736a38307a8f57 Staging site: http://maven.apache.org/plugins-archives/maven-ear-plugin-LATEST/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Kind regards Karl-Heinz Marbaise - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [GitHub] maven pull request: [MNG-2199] Version ranges not supported for pa...
Le dimanche 15 juin 2014 09:19:26 Jason van Zyl a écrit : On Jun 14, 2014, at 3:09 PM, Hervé BOUTEMY herve.bout...@free.fr wrote: Le samedi 14 juin 2014 13:33:37 Jason van Zyl a écrit : yes, but how is the constraint expressed and coded? Trying to encode these in such a way where you effectively have a property graph is hard. Aether has some preliminary support for this but not really. In practice to date it's really constrain the version or constrain what you are resolving against. Either explicit with your version as a concrete version if you want to resolve against the wild. Or you use ranges and the constraint is encoded as the list of repositories you are going to resolve against. for the moment, yes, the constraint has to be encoded as the list of repositories you resolve against: if we make this practice clear, things will get much clearer until we find another strategy (I don't have one for the moment) Given that we have a de facto formalism through our code, specifically in Aether, that I would gravitate toward using a formalized resolution model like what OSGi. I'm certainly not a huge proponent of OSGi, but they have a completely formalized and specified resolution algorithm. I really didn't find any formalisation of resolution algorithm, either in Aether of OSGi: once a list of version have been found that match the constraint, I still don't see/know what is the chosen one Can you point me to the right direction, please? You need to download the spec: http://www.osgi.org/Specifications/HomePage There is a section on versions. ok, I found the answer: 3.8 Resolving Process ... An exporter with a higher version is preferred over an exporter with a lower version then maximum version (compatible with version range) is used: we should be able to say simply that and IIUC: - nobody finds that any other choice is better in any case - nobody finds that it looks like LATEST, which was removed because it was told not reproducible Now I understand how using version ranges is not really compatible with using SNAPSHOTs: SNAPSHOT is the way to handle limited change when not using ranges But if you choose to use ranges, you have this de-facto LATEST handling that makes SNAPSHOTs more a problem than anything For the moment, I continue to like SNAPSHOTs + preferred versions :) But I start to see all the implications of using ranges: this is a whole other organization Regards, Hervé - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [GitHub] maven pull request: [MNG-2199] Version ranges not supported for pa...
On Jun 15, 2014, at 11:01 AM, Hervé BOUTEMY herve.bout...@free.fr wrote: Le dimanche 15 juin 2014 09:19:26 Jason van Zyl a écrit : On Jun 14, 2014, at 3:09 PM, Hervé BOUTEMY herve.bout...@free.fr wrote: Le samedi 14 juin 2014 13:33:37 Jason van Zyl a écrit : yes, but how is the constraint expressed and coded? Trying to encode these in such a way where you effectively have a property graph is hard. Aether has some preliminary support for this but not really. In practice to date it's really constrain the version or constrain what you are resolving against. Either explicit with your version as a concrete version if you want to resolve against the wild. Or you use ranges and the constraint is encoded as the list of repositories you are going to resolve against. for the moment, yes, the constraint has to be encoded as the list of repositories you resolve against: if we make this practice clear, things will get much clearer until we find another strategy (I don't have one for the moment) Given that we have a de facto formalism through our code, specifically in Aether, that I would gravitate toward using a formalized resolution model like what OSGi. I'm certainly not a huge proponent of OSGi, but they have a completely formalized and specified resolution algorithm. I really didn't find any formalisation of resolution algorithm, either in Aether of OSGi: once a list of version have been found that match the constraint, I still don't see/know what is the chosen one Can you point me to the right direction, please? You need to download the spec: http://www.osgi.org/Specifications/HomePage There is a section on versions. ok, I found the answer: 3.8 Resolving Process ... An exporter with a higher version is preferred over an exporter with a lower version then maximum version (compatible with version range) is used: we should be able to say simply that and IIUC: - nobody finds that any other choice is better in any case - nobody finds that it looks like LATEST, which was removed because it was told not reproducible There was a proposal for pre-releases (like SNAPSHOTs but was rejected). Honestly I don't think they are needed. At Eclipse we do just fine without them. There are a steam of releases and we pick one that works. More akin to continuous delivery. To further complicate matters you can have an explicit target platform which essentially enumerates your entire runtime and that's what you can resolve against. So you can have ranges in your dependency specification but your target platform is going to have specific versions available for use and it is a logical constraint. This is a little like having a dependencyManagement section if it enumerated the transitive hull and locked down the versions but in Maven's case (without some enforcement) if a dependency was not listed but requested Maven would carry on, where if a bundle was requested and not available in the target platform the resolver would blow up. Unless you're using Tycho without a target platform and then it works more like Maven. It's rather complicated in Tycho as we've tried to make Maven and OSGi cooperate which is like mixing oil and water as Igor would say. Now I understand how using version ranges is not really compatible with using SNAPSHOTs: SNAPSHOT is the way to handle limited change when not using ranges But if you choose to use ranges, you have this de-facto LATEST handling that makes SNAPSHOTs more a problem than anything It's just how we use SNAPSHOT. In a Tycho build we use -SNAPSHOT in the Maven POMs and .qualifier in the bundle manifests, but all the bundles and metadata get expanded for deployment. So if you look at the m2e-egit extra manfiest: https://github.com/tesla/m2eclipse-egit/blob/master/org.sonatype.m2e.egit/META-INF/MANIFEST.MF#L5 You will see .qualifier in the version and this gets expanded to a build qualifier which generally contains the UTC date stamp. Now if you look in a deployed version at: http://repository.takari.io:8081/nexus/content/sites/m2e.extras/m2eclipse-egit/0.14.0/N/0.14.0.201405280011/ And you open the artifacts.jar and look at artifact.xml you will see that there is no trace of the .qualifier. So the resolver is not dealing with the literal .qualifier it's just dealing with numerics. Really I think this is where we will get insofar deploying artifacts and metadata with expanded qualifiers. I think our discussion on Wednesday will include having build-time vs consumption-time POMs. The consumption-time POM can have most of the build information stripped out and we can likely have it be fully expanded. I'll post something on Monday so people can prepare for Wednesday. For the moment, I continue to like SNAPSHOTs + preferred versions :) It works in many cases and for 10 years ago it was better than anything else. The fatal flaw with snapshots (which would not be hard to fix) is that each build
Re: A thought on local-SNAPSHOTs
So if I have two modules that are interdependent on in-progress changes, how does one build/test the dependant one. Note - reactor builds and multi-modules builds are out of the question - the above modules are in separate git repositories and there's no way to create a fake reactor setup - i.e. a separate pom.xml just listing module/ elements ( maven complains when that pom is not the parent ). On 15 Jun 2014, at 23:08, Robert Scholte wrote: exactly my thoughts as well. I see a lot of users still doing 'install' for the wrong reasons: - coworkers said so / internet said so. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: A thought on local-SNAPSHOTs
On 15 Jun 2014, at 21:07, Stephen Connolly wrote: I favour never deploying smapshots to developer repositories... Any time Agree fully on not deploying snapshots - but I'm talking about locally INSTALLED snapshots. broken shit for... Timestamped snapshots are just a crutch... Agreed totally - and we never use them either. But that's 100% irrelevant to this topic ( at least directly ). - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: A thought on local-SNAPSHOTs
On Jun 15, 2014, at 5:45 PM, Mark Derricutt m...@talios.com wrote: So if I have two modules that are interdependent on in-progress changes, how does one build/test the dependant one. This setup is just normal and works in m2e with Eclipse's workspace resolution. I can have an arbitrary graph of projects where the projects can be in source form or binary dependencies: everything is resolved from within Eclipse and I don't need the command line at all. I have worked like this for years and Igor has made many improvements over time to make it easier. Note - reactor builds and multi-modules builds are out of the question - the above modules are in separate git repositories and there's no way to create a fake reactor setup - i.e. a separate pom.xml just listing module/ elements ( maven complains when that pom is not the parent ). That said I am working with a customer where this type of workspace resolution we have in Eclipse we want on the command line. Ideally I want the behaviour we have in Eclipse to be available on the command line and in CI systems. The graph of projects you have in your IDE is probably not too dissimilar from a graph of projects you have in a CI system and you should be able to build them all in the same workspace. I basically always work in Eclipse for this reason and I never install anything until I want to try it all on the command line. Ultimately I hope not to have to install anything ever and maybe install can just go away at some point. On 15 Jun 2014, at 23:08, Robert Scholte wrote: exactly my thoughts as well. I see a lot of users still doing 'install' for the wrong reasons: - coworkers said so / internet said so. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - To think is easy. To act is hard. But the hardest thing in the world is to act in accordance with your thinking. -- Johann von Goethe
[GitHub] maven-enforcer pull request: [MENFORCER-193]: Add new rule: Banned...
Github user wangyf2010 closed the pull request at: https://github.com/apache/maven-enforcer/pull/13 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: A thought on local-SNAPSHOTs
On Sunday, 15 June 2014, Mark Derricutt m...@talios.com wrote: So if I have two modules that are interdependent on in-progress changes, how does one build/test the dependant one. Note - reactor builds and multi-modules builds are out of the question - the above modules are in separate git repositories and there's no way to create a fake reactor setup - i.e. a separate pom.xml just listing module/ elements ( maven complains when that pom is not the parent ). Even if the local aggregator does something like module../foo/module ? On 15 Jun 2014, at 23:08, Robert Scholte wrote: exactly my thoughts as well. I see a lot of users still doing 'install' for the wrong reasons: - coworkers said so / internet said so. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Sent from my phone
Re: A thought on local-SNAPSHOTs
On 16 June 2014 14:12, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On Sunday, 15 June 2014, Mark Derricutt m...@talios.com wrote: So if I have two modules that are interdependent on in-progress changes, how does one build/test the dependant one. Note - reactor builds and multi-modules builds are out of the question - the above modules are in separate git repositories and there's no way to create a fake reactor setup - i.e. a separate pom.xml just listing module/ elements ( maven complains when that pom is not the parent ). Even if the local aggregator does something like module../foo/module A link to a blog post or more detail might be useful for those still learning. I'm pretty sure I know this to look like ROOT/ - aggregator - pom.xml (reference modules ../projectA and ../projectB) - projectA - projectB But its not something I do, and I'm hoping I got it right from Maven experience :) This is where the vaoporware Magic Checkout plugin that Kristian has mentioned would be useful. This plugin would automatically change a released dependency to its snapshot version, check it out, and update/create the aggregator project to reference the checked out version.
