this would be perfect, because now i did how it was recommended, but:
1. modified the parent trunk to snapshot.
2. did a release of the company pom. Released highest version is now 1.1
3. modified the first child in the chain:
<parent>
<groupId>eds</groupId>
<artifactId>eds</artifactId>
<version>LATEST</version> <--- changed, LASTEST is
1.1 (currently highest version number of parent)
</parent>
<modelVersion>4.0.0</modelVersion>
<groupId>eds.tweb</groupId>
<artifactId>tweb</artifactId>
<packaging>pom</packaging>
<version>1.1-SNAPSHOT</version>
<name>tweb</name>
4. install/deploy or release-prepare are all failing with following
error:
[ERROR] FATAL ERROR
[INFO]
------------------------------------------------------------------------
[INFO] Error building POM (may not be this project's POM).
Project ID: eds.tweb:tweb:pom:1.1-SNAPSHOT
Reason: Cannot find parent: eds:eds for project:
eds.tweb:tweb:pom:1.1-SNAPSHOT for project
eds.tweb:tweb:pom:1.1-SNAPSHOT
In this case i would expect that it would take version 1.1 of the parent
pom.
brgds
Dominique
-----Original Message-----
From: Nick Stolwijk [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 19, 2007 11: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]
