Sorry Arron, I have missed that section of your mail. Yes you do need
commit access across all project. I think it is reasonable that if you
don't have commit access to all the projects then you need to manually
coordinate the change with everyone. It is a pain so commit access can
solve the problem very easily. If it is a politically sensitive thing to
gain this access you could try to configure your source control to only
give you access to pom.xml.
Also, looking at your poms, I think you have a very non conventional
setup. You have alot of dependencies setup in the parent pom with provided
scope - those dependencies also seems to be artifacts of your child
projects. To be honest, I'm really confused about the structure of your
poms. Have you converted this Maven project structure from Ant? How have
you managed to perform a release of your software without a the use of
release plugin? I can't imagine how your build will work as it is like
chicken and egg problem - i.e., you need all the artifacts of the 50+
modules before you even get to build all of them.
The release tag helps you to increment -SNAPSHOT version to non snapshot.
It then tag the code and pull the code out for a clean build which it's
artifacts then gets deployed to the repository. The pom version and parent
pom version is then incremented back to the next -SNAPSHOT ready for
development again. Basically it automates the manual work of tagging,
incrementing version numbers, commiting to source control and releasing
your software version.
${project.version} just refers to the version of the pom - this is a
built-in facility of Maven to reference various element value with the
pom.
Cheers,
rOnn c.
"Aaron Zeckoski" <[EMAIL PROTECTED]>
11/15/2007 08:27 PM
Please respond to
"Maven Users List" <users@maven.apache.org>
To
[EMAIL PROTECTED]
cc
"Maven Users List" <users@maven.apache.org>
Subject
Re: How to control versioning across multiple POMs?
> Do you use release plugin?
>
> The release plugin should increment the version of the parent pom and
the
> pom itself for you.
If you mean this one:
http://maven.apache.org/plugins/maven-release-plugin/index.html
No. I had a hard time understanding what it actually does from the
docs and it seems like I would need commit access to all the
sub-projects (which I do not have).
> If you have dependencies to sibling pom in your dependencies
declaration,
> I'd use <version>${project.version}</version> to get around the problem
that
> the release tag won't increment the version back to snapshot.
What do you mean? Where would I specify this property? In the master
POM? Is this a special property in maven2?
> I have a series of 3 POMs and I need to be able to control versioning
> across them. They are arranged like so:
>
> master POM (parent of) base POM (parent of) project POM
>
> There is one master and one base POM but there are many many project
> POMs, roughly 50+ currently with new ones being added
>
> The master POM has a version (as it seems all children must specify
> the version of the parent correctly in the parent tag). The base POM
> has no version as it inherits from the master. The problem here is
> that we want to upgrade the overall version... except that every
> project POM specifies the version of either the master or base POM (in
> the parent tag). It means we have to somehow coordinate among 50+
> projects (which are controlled by various people/groups) and tell them
> to all change the version of the parent.
>
> This is not ideal at all and I suspect we are just doing something
> dumb or completely wrong. So, how can we control the overall version
> for all the projects without having to change all of the POMs?
>
> You can view the source here if you like:
> master: https://source.sakaiproject.org/svn/master/trunk/pom.xml
> base: https://source.sakaiproject.org/contrib/caret/kernel/pom.xml
> sample project:
> https://source.sakaiproject.org/contrib/caret/kernel/alias/pom.xml
>
> -AZ
>
>
> --
> Aaron Zeckoski ([EMAIL PROTECTED])
> Senior Research Engineer - CARET - Cambridge University
> [http://bugs.sakaiproject.org/confluence/display/~aaronz/]
> Sakai Fellow - [http://aaronz-sakai.blogspot.com/]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
>
> ##########################################################
> DISCLAIMER:
> This email and any attachment may contain confidential information.
> If you are not the intended recipient you are not authorized to copy
> or disclose all or any part of it without the prior written consent
> of Toyota.
>
> Opinions expressed in this email and any attachments are those of the
> sender and not necessarily the opinions of Toyota.
> Please scan this email and any attachment(s) for viruses.
> Toyota does not accept any responsibility for problems caused by
> viruses, whether it is Toyota's fault or not.
> ##########################################################
--
Aaron Zeckoski ([EMAIL PROTECTED])
Senior Research Engineer - CARET - Cambridge University
[http://bugs.sakaiproject.org/confluence/display/~aaronz/]
Sakai Fellow - [http://aaronz-sakai.blogspot.com/]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
######################################################################
DISCLAIMER:
This email and any attachment may contain confidential information.
If you are not the intended recipient you are not authorized to copy
or disclose all or any part of it without the prior written consent
of Toyota.
Opinions expressed in this email and any attachments are those of the
sender and not necessarily the opinions of Toyota.
Please scan this email and any attachment(s) for viruses.
Toyota does not accept any responsibility for problems caused by
viruses, whether it is Toyota's fault or not.
######################################################################
