Hi there,
I think have the "extra" parent/pom.xml is a left-over. I think we could
move it to the "root pom" without any problems..
Bye,
Norman
Am 24.02.2011 12:42, schrieb Eric Charles:
About the parent poms:
1.- some projects use the root/pom.xml as parent (james server project
does that)
2. others create a root/parent/pom.xml specific project.
I was in favor of the first, now I use the second as default, maybe
tomorrow I will use the first again.
I looked at your patch which basically moves the definitions from
imap/parent/pom.xml to imap/pom.xml.
Before committing it, I would like to have a general discussion about
the strategy for all projects regarding the parent.
Maybe you could start a more generic thread about this.
Tks,
- Eric
On 24/02/2011 11:51, Felix Knecht wrote:
Hi Eric
The idea of parent is to have some basic/common definition in it, and
let the childs heritate from these (a bit like java classes).
This is the way maven works, and james simply uses this feature.
I agree.
For example, all imap modules have a parent which is located in
imap/parent.
This imap/parent has it-self a parent which is the james-project
(defined somewhere else in svn trunk - automatically fetched from the
repositories when you build james).
The <relativePath>./parent/pom.xml</relativePath> is simply there to
help for special case (system does not have access to the network
repositories, or you build partially the imap project,...).
But where's the benefit of having in fact almost 2 'parent' poms? If
you put the basic/common definitions from imap/parent/pom.xml
imap/pom.xml and reference the imap/pom.xml as parent in the
submodules you can get rid of the imap/parent, still have a parent
pom (imap/pom.xml) containing the definitions?
It's a bit complicated, but I think the way maven is implemented at
james is not a bad way. Of course, if you've got change proposal, we
are
always interested to talk about :)
See and talk about attachement :-)
For the site generation, simply invoke "mvn site" (or "mvn clean site")
in your imap root folder. The resulting site should be found under
target/site/
Do you receive an error invoking "mvn site" ?
I expressed not very clear, see other mail.
Kind regards
Felix
Tks,
- Eric
PS: The mailing list is moderated, this is why you didn't t see the
mail
directly.
On 24/02/2011 07:33, Felix Knecht wrote:
Sorry for reposting, but I thought it got lost somewhere on the way as
I haven't seen it after hours ...
On 02/24/2011 06:53 AM, Felix Knecht wrote:
Hi all
Trying to get the module sites generated I'm getting a little bit
confused about the usage of pom files.
I can't see the need of the module 'parent' containing only a pom.xml
with type <packaging>pom</packaging>. This parent/pom.xml does
various
definitions for reporting, building, dependencies.
Then we have the ./pom.xml, also as <packaging>pom</packaging>. This
pom.xml has a strange cycling dependency to it's parent pom - once as
<parent> and once as <module>. In fact you only get the up to date
parent because of the <relativePath> which can be indicated (and
BTW not
liked by maven 3.x). Without using the relativePath the parent
will be
always one step behind actual changes - actual parent pom will be as
module. Furthermore definitions in ./pom.xml mostly exists already in
the parent/pom.xml.
Last but not least the site generation seems to work (for me) only
when
deploying the site, otherwise I get strange results. I guess this is
because when deploying the generated site of the parent gets
overridden
with the site generated from ./pom.xml.
IMO it would make sense to merge these to poms (both of
<packaging>pom</packaging>) and have just one ./pom.xml and skip the
./parent completely.
Can please somebody throw some light on my confusion?
Thanks and kind regards
Felix
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
