Two pieces of info: there is already an optional tag in the parent
that allows you to specify where the parent is - <relativePath>:
http://maven.apache.org/ref/2.0.3-SNAPSHOT/maven-model/maven.html#class_parent
Also, rather than running with -N, you should look at the <inherited> option:
http://maven.apache.org/ref/current/maven-model/maven.html#class_plugin
- Stephen
On 7/13/06, Joerg Hohwiller <[EMAIL PROTECTED]> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Edwin,
Edwin Punzalan wrote:
>
> The TREE layout is recommended... the plugins are laid-out flat bec they
> are all plugins which means they all have a single parent. No use for a
> sub-parent for now... but there have been talks of categorizing the
> plugins which maybe a good cause for sub-parents with their own children.
Thanks for this information. Maybe there should be a mini-guide about
multi-project layout...
But strange - maybe I did something wrong or started on a too early version of
maven2 (plugins), but the source-repository report did not work right with TREE
layout that time.
Anyways the user should be quite free to layout his project.
I could also think about a third example:
trunk/
trunk/foo-project/project/pom.xml
trunk/foo-project/children/foo-project-util/project/pom.xml
trunk/foo-project/children/foo-project-service/project/pom.xml
trunk/foo-project/children/foo-project-service/children/foo-project-service-core/project/pom.xml
trunk/foo-project/children/foo-project-service/children/foo-project-service-main/project/pom.xml
Now I think if maven could have an optional tag in the <parent> that overrides
the path to the parent project. The default would be "../" for TREE layout.
For the flat layout you can use "../${parent.artifactId}". In the crazy example
above, it would be "../../../project".
This would be the inverse of the <modules> path.
You might say that there is no need for this. But then you never had a parent
pom with an ant-script or complex build rules inside and you got totally
crazy from the extra "mvn -N install" call in the parent project (that why I
discovered -N).
So if maven has a way to find the parent pom.xml locally and it is there and has
the specified version it could be read insted of taking it from the repository.
Anyways for the problems that some of the plugins have with the
different layouts: I think that all information is already there in a reactor
build and the <modules> directives give all information needed for
source-repository report, maven-release-plugin, etc.
Thinks that are not working properly are just "bugs".
Regards
Jörg
p.s. sorry for top-posting ;)
>
>
> Joerg Hohwiller wrote:
>
> Hi there,
>
> I have a complex maven project that goes down to 3 levels of POM
> inheritance (=
> it has sub-sub-projects).
>
> I am not really sure about what the suggested layout is:
>
> TREE:
>
> trunk/
> trunk/foo-project/pom.xml
> trunk/foo-project/foo-project-util/pom.xml
> trunk/foo-project/foo-project-service/pom.xml
> trunk/foo-project/foo-project-service/foo-project-service-core/pom.xml
> trunk/foo-project/foo-project-service/foo-project-service-main/pom.xml
>
> or
>
> FLAT:
>
> trunk/
> trunk/foo-project/pom.xml
> trunk/foo-project-util/pom.xml
> trunk/foo-project-service/pom.xml
> trunk/foo-project-service-core/pom.xml
> trunk/foo-project-service-main/pom.xml
>
>
> As it seems by most plugins the "FLAT" layout is required for them to
> work.
> On the other hand some parts of maven seem to expect the "TREE" layout
> (e.g.
> parent POMs are sometimes looked up at "../pom.xml").
>
> I personally prefer the "TREE" variant. Especially if someone only
> wants to
> checkout and work on a sub-project this makes it way easier!
> But because I got into heavy trouble with maven I changed to the
> "FLAT" variant
> (what caused a lot of stupid work).
>
> I could not find any offical documentation about this toppic.
>
> My personal oppinion is that maven should support both ways (without
> heavy
> customization).
>
> The problem is that there are lots of plugins heavily involved in this
> issue
> (maven-release-plugin, all the reports such as the source repository,
> etc) and
> the maven-core itself.
>
> So what do you think about this one?
>
> Take c
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
