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]
