Re: dependency management across projects
> > > The release of the BOM would be that release of "a single coherent unit" > > then. It would specify the (marketing) version of the "platform" P. > > For example, P v1.0.0 will include v1.2.3 of SP1 (sub-product 1), v1.4.3 > of > > SP2, etc. > > Isn't it what I just write in my original post? (without mentioning the > BOM) > I believe so, yes. The key thing in my "solution" is the BOM. And the BOM will keep the appropriate version of the the sub-products together. > The very point I am trying to make here is > "how do you manage that manual BOM on a daily basis". Each sub-project has > its own release cycle and we cannot force the versions it has to use for a > specific branch. For instance, the product might state that the dependency > D should be 2.2.0 (because that's the latest or the one that people > generally use) but for backward compatibility reason SP2 has to use 1.8.0. > There is no automatic solution for this that I know of. I suppose that tolls could be created, but keep in mind that in the end, "for backward compatibility reason SP2 has to use 1.8.0" is normally a human decision. /Anders > > Creating manually the first BOM for P v1.0.0 isn't a problem: i've created > a set of tools that I am happy to share once they are fully ready. But > maintaining that BOM in the long run is more of a challenge (because we > can't force the sub-projects to use those versions so we have to monitor > what happens in each sub-project to take the appropriate version at the > product level). > > Thanks again for the feedback! > > S. > > > > > > /Anders > > > > > > > > > > > > > > > > > > > > > > There is also the possibility of creating a "grouping pom", which > lists > > > all > > > > artifacts as dependencies. You would then declare a dependency to > that > > > > grouping pom and get all deps magically sucked in. However, this is > not > > > > really the "Maven way" in my opinion as you wouldn't specify your > > direct > > > > deps bu sort of relly on transitive deps. There are some fans of this > > > > approach though here on this list. > > > > > > > > > > > > > 2. Build configs that *force* each sub-project to run with the list > > of > > > > > dependencies for the project (to ensure all tests pass, etc). This > is > > > to > > > > be > > > > > used alongside the regular build job for validation purpose > > > > > > > > > > > > > Maybe some enforcer rule? > > > > > > > > > > Like I said, this is to be used alongside the regular build job. So my > > SP4 > > > 1.2.0-SNAPSHOT is building with a set of dependencies on its own and I > > want > > > to validate that with the dependencies of the target release for P, it > is > > > also working just fine. It may just be the same ideally or slightly > > > different (or not slightly at all which requires an explicit > validation). > > > > > > So I need to be able to swap those versions for validation purposes and > > run > > > the build with that. > > > > > > S. > > > > > > > > > > > > > > > > > /Anders > > > > > > > > > > > > > > > > > > I started to look at this and my first trial was to generate a > report > > > > with > > > > > all the dependencies of each project and build a consolidated > report > > > > that I > > > > > can match against the candidates. This would help manage the first > > goal > > > > as > > > > > if a dependency gets added, removed or updated, the global > > > > > dependencyManagement has to be impacted manually (do we upgrade or > > not, > > > > > etc). > > > > > > > > > > For the second part, it's not easy to force a dependency change in > > > Maven, > > > > > especially if the version has been specified at the project level. > > > > > > > > > > Thanks for reading that far. If you have any idea or know any > > > > organisation > > > > > that tried to implement that, I'd be interested > > > > > > > > > > Thanks! > > > > > S. > > > > > > > > > > > > > > >
Maven process stuck on MacOS with Java8
On Fri, Jan 31, 2014 at 8:45 PM, Mark Derricutt > wrote: > That's the terminal, not the shell ( bash, zsh, fish, csh etc. ). > Yes, right. I am just using the default (bash). I also invoked the same command from the plain Terminal application and I have the same issue. Martijn, I've just tried with 127, same issue. The problem is that I can't generate a thread dump jstack 47707 47707: Unable to open socket file: target process not responding or HotSpot VM not loaded The -F option can be used when the target process is not responding Using -F does not really help either. S. > I was also using iTerm when I had my issue, and now I think about it - > since the last beta update/release I've not seen the issue again, but I > also changed laptops so can't recall if its only on the new install I've > not had the issue. > > I suspect they're not the same issue tho... maybe. > > > On 1 Feb 2014, at 0:05, Stephane Nicoll wrote: > > Mark, >> >> I am using iTerm2 (1.0.0.20130622) >> >> S. >> >> >> On Fri, Jan 31, 2014 at 11:56 AM, Mark Derricutt >> > >> wrote: >> >> You're not by any chance using "fish" as your shell are you? >>> >>> For awhile some strange bug in fish ( at least on my old machine, along >>> with a combination of prompt settings ) would "hang" on the termination >>> of >>> processes, more often than not maven but also others. Something about it >>> being stuck reading a char from stdin or something - only it wasn't time >>> related, sometimes resizes/splitting the terminal would kick it back into >>> gear. >>> >>> >>> On 31 Jan 2014, at 23:12, Stephane Nicoll wrote: >>> >>> I am definitely impatient because looking at that closer, the shell is >>> not >>> stuck but it takes several seconds to give back hand. Sometimes it's ok, sometimes is 5 sec or so. >>> - >>> 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 > > -- Sent from my phone
Re: dependency management across projects
On Fri, Jan 31, 2014 at 1:16 PM, Anders Hammar wrote: > The release of the BOM would be that release of "a single coherent unit" > then. It would specify the (marketing) version of the "platform" P. > For example, P v1.0.0 will include v1.2.3 of SP1 (sub-product 1), v1.4.3 of > SP2, etc. > Isn't it what I just write in my original post? (without mentioning the BOM) > > Creating the BOM would be a manual work I think, as you want to make sure > that exactly the correct versions are included (might not be the latest > releases). > Yes, this is already what I do. The very point I am trying to make here is "how do you manage that manual BOM on a daily basis". Each sub-project has its own release cycle and we cannot force the versions it has to use for a specific branch. For instance, the product might state that the dependency D should be 2.2.0 (because that's the latest or the one that people generally use) but for backward compatibility reason SP2 has to use 1.8.0. Creating manually the first BOM for P v1.0.0 isn't a problem: i've created a set of tools that I am happy to share once they are fully ready. But maintaining that BOM in the long run is more of a challenge (because we can't force the sub-projects to use those versions so we have to monitor what happens in each sub-project to take the appropriate version at the product level). Thanks again for the feedback! S. > > /Anders > > > > > > > > > > > > > > > There is also the possibility of creating a "grouping pom", which lists > > all > > > artifacts as dependencies. You would then declare a dependency to that > > > grouping pom and get all deps magically sucked in. However, this is not > > > really the "Maven way" in my opinion as you wouldn't specify your > direct > > > deps bu sort of relly on transitive deps. There are some fans of this > > > approach though here on this list. > > > > > > > > > > 2. Build configs that *force* each sub-project to run with the list > of > > > > dependencies for the project (to ensure all tests pass, etc). This is > > to > > > be > > > > used alongside the regular build job for validation purpose > > > > > > > > > > Maybe some enforcer rule? > > > > > > > Like I said, this is to be used alongside the regular build job. So my > SP4 > > 1.2.0-SNAPSHOT is building with a set of dependencies on its own and I > want > > to validate that with the dependencies of the target release for P, it is > > also working just fine. It may just be the same ideally or slightly > > different (or not slightly at all which requires an explicit validation). > > > > So I need to be able to swap those versions for validation purposes and > run > > the build with that. > > > > S. > > > > > > > > > > > > /Anders > > > > > > > > > > > > > > I started to look at this and my first trial was to generate a report > > > with > > > > all the dependencies of each project and build a consolidated report > > > that I > > > > can match against the candidates. This would help manage the first > goal > > > as > > > > if a dependency gets added, removed or updated, the global > > > > dependencyManagement has to be impacted manually (do we upgrade or > not, > > > > etc). > > > > > > > > For the second part, it's not easy to force a dependency change in > > Maven, > > > > especially if the version has been specified at the project level. > > > > > > > > Thanks for reading that far. If you have any idea or know any > > > organisation > > > > that tried to implement that, I'd be interested > > > > > > > > Thanks! > > > > S. > > > > > > > > > >
