cvs commit: jakarta-turbine-maven/src/plugins-build/xdoclet/src/plugin-resources - New directory

[jv...@apache.org]

jvanzyl     2003/01/23 09:07:47

  jakarta-turbine-maven/src/plugins-build/xdoclet/src/plugin-resources - New directory

Project inheritance/extension, being allowed to set $basedir would be helpful

[Colin Sampaleanu <co...@exis.com>]

Generally, subprojects which inherit from a parent project do not work 
with the same directories and artifacts that the parent project does.

There is however a case where this would be very useful, and for this to 
be easy to do, the subproject needs to think it has a different $basedir 
than the one the project.xml file is in (although the maven.xml and 
project.properties alongside it should still be read).

Consider the 'ear' plugin. It can currently only build an ear file with 
artifacts which are already in the remote or local repository (as a 
result of an 'install'). However, it would be much more useful if you 
could have a project which compiled code, built jars and wars, and then 
built the ear. One way to handle this would be to have a project build 
up all the artifacts and install them, then call (via the reactor) a 
subproject to create the ear file. The important thing is that if the 
subproject thought it's basedir was the basedir of the parent project, 
then it could reuse all the src artifacts relative to the parent. 
Otherwise, any reference to a file (via a property) needs to be 
overriden in the child project (consider for example the property which 
points to the standard location for the application.xml file, for which 
there is a default value in the plugin, or the manifest, etc. Without 
being able to override the basedir, these artifacts have to be found 
either by overriding all the default properties, or else by actually 
placing them in the subproject.

Thoughts?

Colin

Re: Serious issues with overriding remote and local repo w/reactor vs standalone

[Colin Sampaleanu <co...@exis.com>]

There seems to be a partial solution to this. Each project must override 
the repos individually (e.g. not rely on inheritance), and must specify 
relative paths off $basedir, not '.'. So in the parent project you can have

# override remote repo since we want to also point to a cvs based remote 
repo
# to get some jars not found at ibiblio
maven.repo.remote=http://www.ibiblio.com/maven/,http://some.where/else/,file:${basedir}/../../shared/repository
# overrid local repo since we want to allow this set of related source 
projects
# to be built from multiple locations without conflicting
maven.repo.local=${basedir}/../mavenrepo

and if the child project is two levels deeper, then it would use

# override remote repo since we want to also point to a cvs based remote 
repo
# to get some jars not found at ibiblio
maven.repo.remote=http://www.ibiblio.com/maven/,http://some.where/else/,file:${basedir}/../../../../shared/repository
# overrid local repo since we want to allow this set of related source 
projects
# to be built from multiple locations without conflicting
maven.repo.local=${basedir}/../../../mavenrepo

Now, when the child is built in it's own directory standalone, it is ok. 
When it is built through the parent via the reactor, the  repo overrides 
from the child are still used, with $basedir relative to the child not 
the parent, and it still works. If the child has no repo overrides, then 
it will fail as maven will try to use the default maven values for this, 
not the values from the parent or any other project.

Hope this helps anybody trying to do something similar. As per my 
previous post, I still think the whole issue of inheriting properties 
with paths in them is pretty thorny...

Regards,

Colin


Colin Sampaleanu wrote:

> Maven and the reactor get pretty confused with regards to overrrides 
> of the local and remote repo. In a top level project, I am overriding 
> the remote and local repos as follows:
>
> # override remote repo since we want to also point to a cvs based 
> remote repo
> # to get some jars not found at ibiblio
> maven.repo.remote=http://www.ibiblio.com/maven/,http://some.where/else/,file:../../shared/repository
> # overrid local repo since we want to allow this set of related source 
> projects
> # to be built from multiple locations without conflicting
> maven.repo.local=../mavenrepo
>
> This works great when building just this project, and allows jars to 
> come down from ibiblio as well as a local cvs based remote repository, 
> and get placed into a local repo specific to this instance of the 
> source code, instead of the general maven local repository.
>
> However, when a project in a subdirectory which extends from this one 
> comes into the picture, things get pretty bad:
>
> In the subproject, first of all the local and remote repo overrides do 
> not seem to get inherited at all from the parent project. So if there 
> are dependencies in the subproject, no jars can be found from the 
> right place and put in the right place. If I also place overrides for 
> the repo locations in the subproject's project.properties file, the 
> values there are interpreted differently depending on whether the 
> subproject is build from the reactor or standalone. If the subproject 
> is build from the reactor, then any relative paths must be relative to 
> the parent project dir. If the subproject is built standalone, then 
> any relative paths must be relative to the subproject dir. Using 
> absolute paths seems to work, but is not an optimal situation since 
> this must work in a relative fashion depending on where the source is 
> pulled out, and there may be multiple instances of the source. The 
> other questions is why inheritance of repo overrides doesn't work, 
> although even if it did there would be a question of what dir any 
> relative paths would be relative to.
>
> So at this point, as far as I can tell, there is no way to have a 
> reactor based build with multiple projects and repo overrides, unless 
> all paths are kept absolute.
>
> There is also a general question of how to inherit properties which 
> contain relative paths, and be able to use them constructively. When 
> setting a property to a relative path in a parent project, there needs 
> to be a mechanism to say that that property is relative to whatever 
> project it is used in, and that's what $basedir is. But there is also 
> a need to be able to set a relative path in the parent project dir 
> that even when inherited will stay relative to the parent project dir.
>
> Regards,
>
> Colin

Serious issues with overriding remote and local repo w/reactor vs standalone

[Colin Sampaleanu <co...@exis.com>]

Maven and the reactor get pretty confused with regards to overrrides of 
the local and remote repo. In a top level project, I am overriding the 
remote and local repos as follows:

# override remote repo since we want to also point to a cvs based remote 
repo
# to get some jars not found at ibiblio
maven.repo.remote=http://www.ibiblio.com/maven/,http://some.where/else/,file:../../shared/repository
# overrid local repo since we want to allow this set of related source 
projects
# to be built from multiple locations without conflicting
maven.repo.local=../mavenrepo

This works great when building just this project, and allows jars to 
come down from ibiblio as well as a local cvs based remote repository, 
and get placed into a local repo specific to this instance of the source 
code, instead of the general maven local repository.

However, when a project in a subdirectory which extends from this one 
comes into the picture, things get pretty bad:

In the subproject, first of all the local and remote repo overrides do 
not seem to get inherited at all from the parent project. So if there 
are dependencies in the subproject, no jars can be found from the right 
place and put in the right place. If I also place overrides for the repo 
locations in the subproject's project.properties file, the values there 
are interpreted differently depending on whether the subproject is build 
from the reactor or standalone. If the subproject is build from the 
reactor, then any relative paths must be relative to the parent project 
dir. If the subproject is built standalone, then any relative paths must 
be relative to the subproject dir. Using absolute paths seems to work, 
but is not an optimal situation since this must work in a relative 
fashion depending on where the source is pulled out, and there may be 
multiple instances of the source. The other questions is why inheritance 
of repo overrides doesn't work, although even if it did there would be a 
question of what dir any relative paths would be relative to.

So at this point, as far as I can tell, there is no way to have a 
reactor based build with multiple projects and repo overrides, unless 
all paths are kept absolute.

There is also a general question of how to inherit properties which 
contain relative paths, and be able to use them constructively. When 
setting a property to a relative path in a parent project, there needs 
to be a mechanism to say that that property is relative to whatever 
project it is used in, and that's what $basedir is. But there is also a 
need to be able to set a relative path in the parent project dir that 
even when inherited will stay relative to the parent project dir.

Regards,

Colin