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]
