I think this can still be a problem. Say you have 1.0-SNAPSHOT of your product using version 1 of your corp pom. (I always suggest org poms always be releases for the same reason I'm about to explain) Then you go and change the trunk of your product code to use version 2 of the corp pom. I'm a developer happily working on the side in my private branch (or un-updated WC...). All of a sudden my build fails... (because the enforcer rule or because the snapshot of the corp pom was updated with conflicting info). If you have snapshots of your corp pom, things will change suddenly for people sitting off to the side working on their own stuff...the same will happen if you are enforcing that they always use the latest corp pom.
-----Original Message----- From: Nick Stolwijk [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 19, 2007 6:02 PM To: Maven Users List Subject: Re: How to deploy corporate-pom? I was not talking about revisions (SVN) but about versions (maven repository). I hadn't thought about branches/trunk with each their own releases. So maybe it should just be an option to only have the latest minor version. ie. if there is an update from 0.9.1 to 0.9.2 you should take it. It there is an update from 0.9.1 to 1.0.0, you are only warned about it. Maybe get a requirements list before start coding. LatestCompanyPom enforcer rule: Basic functionality: - Should fail if the current project is a SNAPSHOT and there is a newer version of the top most (the corporate pom) artifact. (Don't fail on released versions) - Very optional (I can't find a good use case):Option to fail on released versions also. - Option to not fail on major changes. (so update from 0.9.1 -> 0.9.2 fail, from 0.9.0 to 1.0.0 don't fail) Any other use cases/ideas? With regards, Nick Stolwijk Brian E. Fox wrote: > This is an interesting idea, but what if you change the rev on the trunk > but someone has a developer branch? Now their branch will start failing > the rule cause it's not the latest top level parent. > > -----Original Message----- > From: Nick Stolwijk [mailto:[EMAIL PROTECTED] > Sent: Wednesday, December 19, 2007 5:21 PM > To: Maven Users List > Subject: Re: How to deploy corporate-pom? > > I was also thinking, that you could write a custom rule for the enforcer > > plugin, which checks that the topmost parent is the latest in the > available repositories. Maybe I will write it tomorrow, if you are > interested. > > Hth, > > Nick Stolwijk > > [EMAIL PROTECTED] wrote: > >> Couldn't you put the version of the parent (corporate-pom) to LATEST >> > instead of a version number. AFAIK, when you do a release it is changed > into the current latest version. So tags won't change when you update > your corporate pom. > >> Hth, >> >> Nick Stolwijk >> >> -----Original Message----- >> From: Boeckli, Dominique [mailto:[EMAIL PROTECTED] >> Sent: Wed 12/19/2007 5:04 PM >> To: Maven Users List >> Subject: RE: How to deploy corporate-pom? >> >> the problem is that things get forgotten: >> >> Assuming i start working on Project Y and i forget to check if there's >> > a > >> new company pom. After a few >> changes in my code in this project, it is builded on wrong >> > dependencies > >> succesfully and deployed on the >> test server. Deployment failes and i spent a lot of time debugging it, >> searching the problem in my >> own code. Half of the other developers doing the same error, loosing a >> lot of time. >> >> The script you mentioned is a solution for this problem. Does anybody >> have such a script? >> >> P.S. removing stuff from their local repo was not really another >> problem, it is only a other way to handle >> the same problem. In this way i don't use any snapshot version, i work >> and edit directly on released >> versions (eg 1.0). When i think the company pom is ok, i deploy it and >> advice my collegues to delete this >> versions from their local repo. In this way, they are forced to get >> > the > >> new parent from the intranet >> repo. The point is, that the version allway remains the same for the >> company pom. This way is ugly but >> it causes not more work and problems than the official way. I am not >> happy with it, neither, and this is the reason >> why i ask here around what other people are doing. >> >> brgds >> >> Dominique >> >> -----Original Message----- >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] >> Sent: Wednesday, December 19, 2007 04:16 PM >> To: Maven Users List; Maven Users List >> Subject: RE: How to deploy corporate-pom? >> >> I thought the problem was with developers having to remove stuff from >> their local repository. Now you present another problem. >> >> In my vision, they should certainly not change automatically. At least >> not the tags, then you can have two builds of the same tag with >> different parent information, based on when it's build. >> >> So should they change all, then you could write a script which >> > replaced > >> it in the trunks and branches. Or should they only change, when the >> projects get alive again. I guess you can compare it to mavens own >> "corporate pom". There are a few versions of that, and plugins, >> > modules > >> and projects only update, when they think it is necessary and when it >> > is > >> completely tested. The parent of project is also a dependency, which >> after changing, should be tested whether it broke anything or not. >> >> So let me rephrase it, why would you want to change projects nobody is >> working on? Maybe it is easier to have it as one of the steps when >> reviving a project. Check whether the parent should be updated and >> > test > >> it if has to. >> >> Hth, >> >> Nick Stolwijk >> >> >> -----Original Message----- >> From: Boeckli, Dominique [mailto:[EMAIL PROTECTED] >> Sent: Wed 12/19/2007 4:05 PM >> To: Maven Users List >> Subject: RE: How to deploy corporate-pom? >> >> yes, i understand, but "good-way"-example is based on 2 projects. >> >> But, my example is the following: >> >> Project A same. >> Project B same. >> ........................no comes the difference................ >> >> 200 more projects, currently nobody working on it, some were not >> > changed > >> since >> 2 years or more, has as parent corporate-pom:0.1.0 as well. >> >> In this case the "good way" is a pain as well. Who goes to change all >> those projects to the new corporate-pom:0.1.1 ? >> >> -----Original Message----- >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] >> Sent: Wednesday, December 19, 2007 03:46 PM >> To: Maven Users List >> Subject: RE: How to deploy corporate-pom? >> >> I didn't meant on developer basis, but on project basis. >> >> Example: >> corporate-pom is at version 0.1.0 >> Project A has as parent corporate-pom:0.1.0 Project B has as parent >> corporate-pom:0.1.0 >> >> Project A wants a version changed, dependency added, whatever. >> >> corporate-pom changes to version 0.1.1-SNAPSHOT Project A changes its >> parent pom to 0.1.1-SNAPSHOT Developers at project A automatically get >> the new corporate-pom when they update and build project A. >> Developer also get automatically once a day any new SNAPSHOTS of the >> corporate-pom. >> >> Changes to corporate-pom are tested and found ok. >> Corporate-pom is released to version 0.1.1. >> Project A changes the version to 0.1.1. >> Developers get new 0.1.0 corporate pom when updating and building. >> >> Now you can go to the team leader, responsible person, etc of project >> > b, > >> and also let them update the version in their pom. >> Developers at project B also automatically get the new corporate pom. >> >> No manually removing corporate poms from local repositories or >> inconsistent builds. >> >> I guess this is the "Good Way". :) >> >> Hth, >> >> Nick Stolwijk >> >> >> -----Original Message----- >> From: Boeckli, Dominique [mailto:[EMAIL PROTECTED] >> Sent: Wed 12/19/2007 3:36 PM >> To: Maven Users List >> Subject: RE: How to deploy corporate-pom? >> >> In fact, both ways are not perfect! >> Assuming: i change the company pom in your way and advice the >> > developers > >> about this change. As you know most of the email are deleted without >> being read, i am sure that nobody remembers that there's a new version >> of the company Pom. So, the effect is the same like in my way: after i >> changed the company pom i have to advice the developers that they >> > delete > >> the local company pom in the local repository. >> This gets forgotten as well and the people are picking up the old >> company Pom. >> >> Both ways are bad! And there's no good way?! >> >> Does anybody have an idea? >> >> >> >> -----Original Message----- >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] >> Sent: Thursday, December 13, 2007 01:34 PM >> To: Maven Users List; Maven Users List >> Subject: RE: How to deploy corporate-pom? >> >> This is not good. The other developers won't get the change. And if >> other projects (and especially their tags) rely on this and you change >> it, you got not reproducible builds. Also not good. Just update the >> other versions when needed. It's the most clean thing to do. >> >> With regards, >> >> Nick Stolwijk >> >> >> -----Original Message----- >> From: Boeckli, Dominique [mailto:[EMAIL PROTECTED] >> Sent: Thu 12/13/2007 1:27 PM >> To: Maven Users List >> Subject: RE: How to deploy corporate-pom? >> >> I just do it this way for the company pom (-DperformRelease=true) >> because it would be pain if the version number for the company pom has >> been increased and all other projects defining this one as parent has >> > to > >> be edited. >> >> When i edit and doing "mvn clean deploy -DperformRelease=true -U -X" >> > for > >> the company pom i can see that the local repository has got the >> > change. > >> This is good so far. But what is about the other developers still >> > having > >> the old company pom in their local repository (using the same version >> number)? >> >> brgds >> >> Dominique Boeckli >> >> -----Original Message----- >> From: Siegmann Daniel, NY [mailto:[EMAIL PROTECTED] >> Sent: Friday, November 09, 2007 10:30 PM >> To: Maven Users List >> Subject: RE: How to deploy corporate-pom? >> >> <<How do I package the corporate pom? Do I just upload it to archiva >> > in > >> a directory called corporate-pom with just the pom.xml file in >> > there?>> > >> No. This is a Maven project like any other. Just have the following in >> your POM: >> >> <project> >> <packaging>pom</packaging> >> ... >> </project> >> >> Then use the Maven deploy plugin ("mvn deploy"). >> >> Note that you should follow standard release procedure. i.e. if you >> > are > >> not releasing a snapshot you should set "-DperformRelease=true" and >> > you > >> should have this tagged in your version control system (or just use >> > the > >> release plugin). >> >> -- >> Daniel Siegmann >> FJA-US, Inc. >> 512 Seventh Ave., New York, NY 10018 >> (212) 840-2618 ext. 139 >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
