maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Hohwiller <>
Subject Re: Progress on support for large projects
Date Wed, 13 May 2009 19:03:01 GMT
Hash: SHA1

Hi David,

> [cut.]
> Sorry I wasn't more specific last night at 2:00 am :-).  I need more scm
> context to understand.  I'm assuming something like svn with
> +tags
>   +root-1.0 (1.0)
>     +A(1.0)
>     \B(1.0)
>   +root-1.1 (1.1)
>     +A(1.0)
>     \B(1.1)
>   \root-1.2 (1.1)
>     +A(1.0)
>     \B(1.2)
> \trunk
>   \root(1.2-SNAPSHOT)
>     +A(???? 1.0? 1.0-SNAPSHOT?? 1.1-SNAPSHOT???)
>     \B(1.3-SNAPSHOT)
> I have several assumptions about releasing stuff...
> - development will continue after the release
> - therefore the version in "trunk" must be incremented so it's clear
> that snapshots are later than the release
> - tags should not contain anything with a snapshot version
> - releasing will create a tag of what's been released
> - tagging for release creates a copy of an entire svn subtree, not a
> copy with stuff removed.
> I see several problems with the svn tree I sketched above:
> - there are 3 or 4 copies of A claiming to be version 1.0
> - there is no plausible version for trunk/root/A
> - in tags, the version of root doesn't match the end of the directory
> name. (there are 2 version 1.1 roots)
> I must not be understanding something basic about what you are
> proposing.... I'm probably beating a long-dead horse but could you
> please be even more specific about what scm operations you want to have
> as part of a release and what the scm repo looks like afterwards?

Like Ralph, I have no problem with my scm (which is indeed svn).
I also want to maintain versions of modules and have the problems
that when I change a version I typically have to change this
in all other POMs pointing to the module that changed version.
Besiders there can be excuses where a dependency version remains
unchanged, so no automatism that release-plugin could guess.
And I want to keep modules unchanged in the tree. In my case they would
NOT have to be rebuild but that does NOT matter to me.
Maintaining these redundant versions is hell if you do it by hand.
I have some hacky tools but it could be so easy if you could just
omit the version in the dependencies of my local pom.xml's.

To answer the SCM-structure question:
There maybe some good conventions but SVN gives you a lot of flexibility
in whatever you do. I personally always have a flat list of all my modules
in tags and then have the according module copied (tagged) there named by
its version. I never think that release-plugin has to deal with all
possible ways that users can do their release-management. It has to go
some way and there will always be people that want it different so I
think the release-plugin is NOT the magic answer to all of our problems.

> thanks
> david jencks

Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla -


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message