On 6/13/06, Stefan Hübner <[EMAIL PROTECTED]> wrote:
Hi Kenney,
2006/6/13, Kenney Westerhof <[EMAIL PROTECTED]>:
> On Mon, 12 Jun 2006, Stephen Duncan wrote:
>
>
Another advantage, more of convenience, of differ between parent and
aggregating pom: you can have the parent pom at the same level as
Hi Stephen,
2006/6/13, Stephen Duncan <[EMAIL PROTECTED]>:
I personally do more as you do.
I have team-wide "super-POMs" I have a primary one that has basic
url, issue management, etc. type settings. Then I have a "core" POM
with common dependencyManagment section to encourage use of the same
Hi Kenney,
2006/6/13, Kenney Westerhof <[EMAIL PROTECTED]>:
On Mon, 12 Jun 2006, Stephen Duncan wrote:
Hi,
I'd thought I'd throw in a pair of $0.01..
Using the aggregating POM as the parent pom implies that the projects
are structured in a directory structure matching the child->parent
relati
On Mon, 12 Jun 2006, Stephen Duncan wrote:
Hi,
I'd thought I'd throw in a pair of $0.01..
Using the aggregating POM as the parent pom implies that the projects
are structured in a directory structure matching the child->parent
relationship. That means that the child->parent relationship is the
i
I personally do more as you do.
I have team-wide "super-POMs" I have a primary one that has basic
url, issue management, etc. type settings. Then I have a "core" POM
with common dependencyManagment section to encourage use of the same
versions of Jar's to prevent incompatibilities, as well as c
Hi all,
this is kind of a best-practise-question about your habbits of using
the concepts of multi-project-super-pom.
First of all, are there distinctive terms commonly agreed upon for
each of those concepts?
Second, those two ways of using POMs appear to me to be orthogonal to
each other, real
