Re: Best practices for seperate releases of parent and modules
On Jan 21, 2008 10:42 AM, [EMAIL PROTECTED] wrote: Is it advisable to move the commons-parent to another subdirectory or is this layout the preferred way? I was experiencing with the former, but gave it up. The reason is that far too many plugins are not suitable to use it. Examples include: - The SCM URL must be configured in every subproject. Otherwise the SCM links on the generated site will be broken. - The distribution URL's must be configured in every subproject. Otherwise deployment will use the wrong target URL. And so on. Jochen -- Look, that's why there's rules, understand? So that you think before you break 'em. -- (Terry Pratchett, Thief of Time) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Best practices for seperate releases of parent and modules
At our company we are busy with a commons project, which has a few submodules. Our current layout is: commons-parent/ commons-module-1/ pom.xml src/ commons-module-2/ commons-module-3/ pom.xml Now we want to do seperate releases of the commons-parent and the modules, just like the Maven plugins. Is it advisable to move the commons-parent to another subdirectory or is this layout the preferred way? I mean the following layout: commons/ commons-parent/ pom.xml commons-module-1/ pom.xml src/ commons-module-2/ commons-module-3/ With regards, Nick Stolwijk
RE: Best practices for seperate releases of parent and modules
But when you release the parent, do you also release all the submodules or do you run mvn with non-recursive? With regards, Nick Stolwijk -Original Message- From: Jochen Wiedmann [mailto:[EMAIL PROTECTED] Sent: Mon 1/21/2008 10:52 AM To: Maven Users List Subject: Re: Best practices for seperate releases of parent and modules On Jan 21, 2008 10:42 AM, [EMAIL PROTECTED] wrote: Is it advisable to move the commons-parent to another subdirectory or is this layout the preferred way? I was experiencing with the former, but gave it up. The reason is that far too many plugins are not suitable to use it. Examples include: - The SCM URL must be configured in every subproject. Otherwise the SCM links on the generated site will be broken. - The distribution URL's must be configured in every subproject. Otherwise deployment will use the wrong target URL. And so on. Jochen -- Look, that's why there's rules, understand? So that you think before you break 'em. -- (Terry Pratchett, Thief of Time) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Best practices for seperate releases of parent and modules
On Jan 21, 2008 11:00 AM, [EMAIL PROTECTED] wrote: But when you release the parent, do you also release all the submodules or do you run mvn with non-recursive? If the parent hasn't changed (in other words, if it hasn't a SNAPSHOT version), then I am happy to release the submodules only. To be honest, that if requires a certain degree of cautiousness. My recommended approach to resolve that is to provide read-only access to the parent for most developers except a few selected. Jochen -- Look, that's why there's rules, understand? So that you think before you break 'em. -- (Terry Pratchett, Thief of Time) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Best practices for seperate releases of parent and modules
But normally the trunk should always contain a SNAPSHOT version, but only the submodules don't have it as parent as long as they don't need to rely on the changes in the parent. But if you use the release plugin to release the parent, will the tag contain only the parent or all the submodules as well? If I look at the maven plugins [1] tags the release contains all the modules (with SNAPSHOT-versions), but the tags directory also contains a tag for each release of the modules (without SNAPSHOT-versions). So it seems they run mvn non recursively, but it is still tagging the whole tree. Seems a little strange to me. With regards, Nick Stolwijk -Original Message- From: Jochen Wiedmann [mailto:[EMAIL PROTECTED] Sent: Mon 1/21/2008 11:39 AM To: Maven Users List Subject: Re: Best practices for seperate releases of parent and modules On Jan 21, 2008 11:00 AM, [EMAIL PROTECTED] wrote: But when you release the parent, do you also release all the submodules or do you run mvn with non-recursive? If the parent hasn't changed (in other words, if it hasn't a SNAPSHOT version), then I am happy to release the submodules only. To be honest, that if requires a certain degree of cautiousness. My recommended approach to resolve that is to provide read-only access to the parent for most developers except a few selected. Jochen -- Look, that's why there's rules, understand? So that you think before you break 'em. -- (Terry Pratchett, Thief of Time) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Best practices for seperate releases of parent and modules
In my opinion, trunk is the development version aka SNAPSHOT. Only the tags should contain the released version number. Each module should provide the parent version it needs and can only be released if that is a non-SNAPSHOT version. With regards, Nick Stolwijk -Original Message- From: Jochen Wiedmann [mailto:[EMAIL PROTECTED] Sent: Mon 1/21/2008 11:58 AM To: Maven Users List Subject: Re: Best practices for seperate releases of parent and modules On Jan 21, 2008 11:48 AM, [EMAIL PROTECTED] wrote: But normally the trunk should always contain a SNAPSHOT version, but only the submodules don't have it as parent as long as they don't need to rely on the changes in the parent. I do not know, why it should. We do not do it that way. But if you use the release plugin to release the parent, will the tag contain only the parent or all the submodules as well? That depends on the level on which we cut the release. Jochen -- Look, that's why there's rules, understand? So that you think before you break 'em. -- (Terry Pratchett, Thief of Time) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Best practices for seperate releases of parent and modules
annoying indeed but you only have to set the scm urls once in the each artifact and with an archetype well only once. i think its dumb to have the parent of several modules the same... if you think OO then the parent of any artifact should define common behaviour for articfacts of that type... so you should have a jar parent, webapp parent etc etc... and usually an aggregation of modules crosses concerns e.g. server, client, common code, persistence, api it seems really obvious to me, maybe i'm missing something On Mon, 21 Jan 2008 22:52:09 Jochen Wiedmann wrote: On Jan 21, 2008 10:42 AM, [EMAIL PROTECTED] wrote: Is it advisable to move the commons-parent to another subdirectory or is this layout the preferred way? I was experiencing with the former, but gave it up. The reason is that far too many plugins are not suitable to use it. Examples include: - The SCM URL must be configured in every subproject. Otherwise the SCM links on the generated site will be broken. - The distribution URL's must be configured in every subproject. Otherwise deployment will use the wrong target URL. And so on. Jochen -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
