Hi,
>> You don't. You need to group your projects by release cycles - only
>> projects that share a common release cycle should be placed under the
>> same parent (at least that's what I always do).
>>
>>
>>> - The scm-element is ignored in the submodule. In either variant testA
>>> is not tagged in subversion, in variant B) the externals point to
>>> trunk/testA (absolute path) or to tags/testA (relative path, not existent).
>>>
>>>
>>>
>> Since those projects should share the same release cycle , tagging
>> individual sub-projects separately makes no sense (they all share the
>> same version number anyway)
>>
>
> Afaik, that's not correct (rather bold for a newbie, isn't he ;-)
> The sub-projects only share the same version number if you set
> autoVersionSubmodules=true.
My statement was made under the assumption the release plugin is unable
to correctly increment version numbers of sub-projects that use
a version number other than that of the parent. At least last year I was
unable to get such a setup to work *unless* I used the parent project's
version number
in all sub-projects as well. Quite some time has passed and if I
remember correctly, I used property expressions to propagate version
numbers, so maybe my problem was caused by those
and not related to the actual numbers being different.
Personally, I've never used "module sets" to create a release from. I
think the "Maven Way" is to create a meta-project ("applicationserver" ,
"webserver" etc.) and make this meta-project depend on the actual
artifacts. Then you use the assembly-plugin ( or dependency plugin) to
actually gather the different artifacts and combine them into a single
archive/directory/whatever.
But I'm not claiming to be a Maven expert - maybe it's me that got it
wrong ;)
Regards,
Tobias
> Btw, keeping things modular means that
> modules may be used in several projects.
>
> It's important for our business to keep the different module-sets
> versioned, so if one module is tagged/versioned the whole set is tagged.
>
> It doesn't make sense to me to tag every module when changing only one
> because it implies that every module has been changed.
>
> Sorry for the project/module naming mess.
>
> Regards,
> Florian
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>
>
