You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by John Casey <jd...@commonjava.org> on 2003/01/21 17:38:15 UTC
loading an arbitrary properties file
Is there a way to include an arbitrary properties file from the
maven.xml? I have a project directory with many sub-project builds,
each with its own project.xml. From the maven.xml, I'm using reactor to
build these in one fell swoop. I'd like things like the jar deployment
site/directory to be specified at the main project level, instead of
duplicating the project.properties for each sub-project (something like
2 dozen of these). Since the only project-specific properties file
loaded is in ${basedir}, this doesn't appear to work...or does it? Is
there a maven tag to load ${basedir}../../project.properties into the
jelly context?
John
Re: loading an arbitrary properties file
Posted by John Casey <jd...@commonjava.org>.
My suspicion is that this is only a problem for me because I'm trying to
have the sub-project inherit maven.username, for which a default invalid
value is set when a context is created. This means that when the
context is created within MavenUtils, as the inheritance is temporarily
turned off, that default value is overriding the value in the parent
project, and by the time interitance is turned back on, it's too late.
Just a gut feeling. I'm still investigating to find out if I'm wrong.
John
On Tue, 2003-01-21 at 13:12, Jason van Zyl wrote:
> On Tue, 2003-01-21 at 11:38, John Casey wrote:
> > Is there a way to include an arbitrary properties file from the
> > maven.xml?
>
> Why do you need that?
>
> > I have a project directory with many sub-project builds,
> > each with its own project.xml. From the maven.xml, I'm using reactor to
> > build these in one fell swoop. I'd like things like the jar deployment
> > site/directory to be specified at the main project level, instead of
> > duplicating the project.properties for each sub-project (something like
> > 2 dozen of these). Since the only project-specific properties file
> > loaded is in ${basedir}, this doesn't appear to work...or does it? Is
> > there a maven tag to load ${basedir}../../project.properties into the
> > jelly context?
>
> According the the reactor build in the touchstone properties are being
> passed around projects fine. If you want to verify look at:
>
> http://cvs.apache.org/viewcvs.cgi/jakarta-turbine-maven/src/test/touchstone-build/src/reactor-build/standard/
>
> In this functional test there is inheritance going on so Maven inherits
> properties from the parent.
>
> The reactor has a shared jelly script for project that run in the
> reactor that don't inherit. Would you like a shared properties file as
> well? Maven will not take anything from the top-level project in a
> reactor by default unless the project actually inherits from that
> project.
>
> > John
> >
> >
> >
> >
> >
> > --
> > To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> > For additional commands, e-mail: <ma...@jakarta.apache.org>
> --
> jvz.
>
> Jason van Zyl
> jason@zenplex.com
> http://tambora.zenplex.org
>
> In short, man creates for himself a new religion of a rational
> and technical order to justify his work and to be justified in it.
>
> -- Jacques Ellul, The Technological Society
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
Re: loading an arbitrary properties file
Posted by Jason van Zyl <ja...@zenplex.com>.
On Tue, 2003-01-21 at 15:29, John Casey wrote:
> After looking at the maven.xml that you point out, the only thing I can
> imagine is that the goal "display" is loaded with the master-project
> properties, or that it may actually execute in a different jelly
> context...I'm not sure. However, I've re-run my tests to duplicate your
> test in this example (in the touchstone), except that I created a
> maven.xml WITHIN THE SUB-PROJECT DIRECTORY to do nothing but display a
> property set within the master-project, and no dice.
I just added what you described and I am seeing the property being
correctly set and displayed.
> John
>
> On Tue, 2003-01-21 at 13:12, Jason van Zyl wrote:
> > On Tue, 2003-01-21 at 11:38, John Casey wrote:
> > > Is there a way to include an arbitrary properties file from the
> > > maven.xml?
> >
> > Why do you need that?
> >
> > > I have a project directory with many sub-project builds,
> > > each with its own project.xml. From the maven.xml, I'm using reactor to
> > > build these in one fell swoop. I'd like things like the jar deployment
> > > site/directory to be specified at the main project level, instead of
> > > duplicating the project.properties for each sub-project (something like
> > > 2 dozen of these). Since the only project-specific properties file
> > > loaded is in ${basedir}, this doesn't appear to work...or does it? Is
> > > there a maven tag to load ${basedir}../../project.properties into the
> > > jelly context?
> >
> > According the the reactor build in the touchstone properties are being
> > passed around projects fine. If you want to verify look at:
> >
> > http://cvs.apache.org/viewcvs.cgi/jakarta-turbine-maven/src/test/touchstone-build/src/reactor-build/standard/
> >
> > In this functional test there is inheritance going on so Maven inherits
> > properties from the parent.
> >
> > The reactor has a shared jelly script for project that run in the
> > reactor that don't inherit. Would you like a shared properties file as
> > well? Maven will not take anything from the top-level project in a
> > reactor by default unless the project actually inherits from that
> > project.
> >
> > > John
> > >
> > >
> > >
> > >
> > >
> > > --
> > > To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> > > For additional commands, e-mail: <ma...@jakarta.apache.org>
> > --
> > jvz.
> >
> > Jason van Zyl
> > jason@zenplex.com
> > http://tambora.zenplex.org
> >
> > In short, man creates for himself a new religion of a rational
> > and technical order to justify his work and to be justified in it.
> >
> > -- Jacques Ellul, The Technological Society
> >
> >
> > --
> > To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> > For additional commands, e-mail: <ma...@jakarta.apache.org>
> >
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
jvz.
Jason van Zyl
jason@zenplex.com
http://tambora.zenplex.org
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
Re: loading an arbitrary properties file
Posted by John Casey <jd...@commonjava.org>.
After looking at the maven.xml that you point out, the only thing I can
imagine is that the goal "display" is loaded with the master-project
properties, or that it may actually execute in a different jelly
context...I'm not sure. However, I've re-run my tests to duplicate your
test in this example (in the touchstone), except that I created a
maven.xml WITHIN THE SUB-PROJECT DIRECTORY to do nothing but display a
property set within the master-project, and no dice.
John
On Tue, 2003-01-21 at 13:12, Jason van Zyl wrote:
> On Tue, 2003-01-21 at 11:38, John Casey wrote:
> > Is there a way to include an arbitrary properties file from the
> > maven.xml?
>
> Why do you need that?
>
> > I have a project directory with many sub-project builds,
> > each with its own project.xml. From the maven.xml, I'm using reactor to
> > build these in one fell swoop. I'd like things like the jar deployment
> > site/directory to be specified at the main project level, instead of
> > duplicating the project.properties for each sub-project (something like
> > 2 dozen of these). Since the only project-specific properties file
> > loaded is in ${basedir}, this doesn't appear to work...or does it? Is
> > there a maven tag to load ${basedir}../../project.properties into the
> > jelly context?
>
> According the the reactor build in the touchstone properties are being
> passed around projects fine. If you want to verify look at:
>
> http://cvs.apache.org/viewcvs.cgi/jakarta-turbine-maven/src/test/touchstone-build/src/reactor-build/standard/
>
> In this functional test there is inheritance going on so Maven inherits
> properties from the parent.
>
> The reactor has a shared jelly script for project that run in the
> reactor that don't inherit. Would you like a shared properties file as
> well? Maven will not take anything from the top-level project in a
> reactor by default unless the project actually inherits from that
> project.
>
> > John
> >
> >
> >
> >
> >
> > --
> > To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> > For additional commands, e-mail: <ma...@jakarta.apache.org>
> --
> jvz.
>
> Jason van Zyl
> jason@zenplex.com
> http://tambora.zenplex.org
>
> In short, man creates for himself a new religion of a rational
> and technical order to justify his work and to be justified in it.
>
> -- Jacques Ellul, The Technological Society
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
Re: loading an arbitrary properties file
Posted by John Casey <jd...@commonjava.org>.
Sorry for the email onslaught...there seems to be something wrong with
our email server here, and everything is sort of delayed. Anyway, all I
did was to take the display goal out of the main project's maven.xml and
put it into a new maven.xml in the sub-project's basedir. Then, I set
the maven.username in the master project's project.properties, and setup
the display goal to echo it to screen. I'm sorry but I'm not really
sure how to send this as a patch...
the dir structure would look like this:
<touchstone-dir-you-sent-me>\
maven.xml .......................remove the display goal from here.
project.properties...............set the maven.username here.
a\
maven.xml......................new file, put the display goal here,
and have it look for
${maven.username} instead of
${property.to.share}
That should break it. It's because maven.username is a special case, in
that the default USERNAME_NOT_SET is populated from driver.properties,
which is loaded over the top of the parent's context when the new child
context is created. I've just about got a patch that will fix this
problem by creating a marker.properties file which will hold these types
of default marker values, and load them with inheritance on...so they
won't squash a setting from the parent's context with a marker.
John
On Tue, 2003-01-21 at 16:40, Jason van Zyl wrote:
> On Tue, 2003-01-21 at 17:35, Jason van Zyl wrote:
>
> >
> > I am not seeing what your are seeing. The first step is to send me the
> > patch that breaks the touchstone, then I will look at your patch.
>
> Or simply a goal I can just to see what you are seeing. There is also
> the issue of values being set in the driver that can probably go
> somewhere else now. Actually looking at them now I see that most of the
> properties can go to their respective plugin. At any rate I'll wait for
> the patch that shows me the failure then I'll take a patch and then I'll
> clean out the driver.properties.
>
> >
> >
> > jvz.
> >
> > Jason van Zyl
> > jason@zenplex.com
> > http://tambora.zenplex.org
> >
> > In short, man creates for himself a new religion of a rational
> > and technical order to justify his work and to be justified in it.
> >
> > -- Jacques Ellul, The Technological Society
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
Re: loading an arbitrary properties file
Posted by John Casey <jd...@commonjava.org>.
I have built and verified that the following diff and new properties
file solve the problem. Essentially, I split the markers into a
separate properties file and then loaded it under inheritance mode after
everything else, when there is a parent context...the new properties
file goes in src/conf, and the diff does the rest...
Hope it helps,
John
On Tue, 2003-01-21 at 16:40, Jason van Zyl wrote:
> On Tue, 2003-01-21 at 17:35, Jason van Zyl wrote:
>
> >
> > I am not seeing what your are seeing. The first step is to send me the
> > patch that breaks the touchstone, then I will look at your patch.
>
> Or simply a goal I can just to see what you are seeing. There is also
> the issue of values being set in the driver that can probably go
> somewhere else now. Actually looking at them now I see that most of the
> properties can go to their respective plugin. At any rate I'll wait for
> the patch that shows me the failure then I'll take a patch and then I'll
> clean out the driver.properties.
>
> >
> >
> > jvz.
> >
> > Jason van Zyl
> > jason@zenplex.com
> > http://tambora.zenplex.org
> >
> > In short, man creates for himself a new religion of a rational
> > and technical order to justify his work and to be justified in it.
> >
> > -- Jacques Ellul, The Technological Society
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
Re: loading an arbitrary properties file
Posted by Jason van Zyl <ja...@zenplex.com>.
On Tue, 2003-01-21 at 17:35, Jason van Zyl wrote:
>
> I am not seeing what your are seeing. The first step is to send me the
> patch that breaks the touchstone, then I will look at your patch.
Or simply a goal I can just to see what you are seeing. There is also
the issue of values being set in the driver that can probably go
somewhere else now. Actually looking at them now I see that most of the
properties can go to their respective plugin. At any rate I'll wait for
the patch that shows me the failure then I'll take a patch and then I'll
clean out the driver.properties.
>
>
> jvz.
>
> Jason van Zyl
> jason@zenplex.com
> http://tambora.zenplex.org
>
> In short, man creates for himself a new religion of a rational
> and technical order to justify his work and to be justified in it.
>
> -- Jacques Ellul, The Technological Society
Re: loading an arbitrary properties file
Posted by Jason van Zyl <ja...@zenplex.com>.
On Tue, 2003-01-21 at 16:40, John Casey wrote:
> Here's the problem, and a diff containing the fix:
>
> The Problem:
>
> The driver.properties file has a set of defaults which may not be
> appropriate, as the are just markers denoting an invalid setting. This
> erases any properties of the same name in the parent context, since
> inheritance is turned off while the properties set (system, user,
> project, project build, and driver) are loaded, which means those
> default marker values in the driver.properties file get precedence over
> the parent project.properties file, which I think is unintended.
>
> The Solution (maybe, I dunno about design decisions...):
>
> If the new sub-project context is created using the parent context, and
> then the driver.properties are loaded BEFORE turning off the interitance
> attribute, then the rest of the properties are loaded as usual,
> everything should progress as normal with the exception that those
> invalid default markers are replaced by values from the parent context.
> I realize that some of the values in the driver.properties file may need
> to be there to override some things from the base project (such as
> ${basedir}, I guess), so the "right" solution may actually be to create
> a markers.properties file for the invalid marker values, and load that
> like the driver.properties file in my attached diff...However, it looks
> as though this diff will work for now...
I am not seeing what your are seeing. The first step is to send me the
patch that breaks the touchstone, then I will look at your patch.
>
>
> *******************************************
> I haven't been able to build this copy, since for some reason the maven
> build seems broken in the Deploy plugin's build process...it can't find
> org.apache.maven.project.Project (fun, fun)...but I think the concept is
> solid, and that's really what I wanted to get across.
> *******************************************
>
> Hope it helps,
> John
>
>
>
> On Tue, 2003-01-21 at 13:12, Jason van Zyl wrote:
> > On Tue, 2003-01-21 at 11:38, John Casey wrote:
> > > Is there a way to include an arbitrary properties file from the
> > > maven.xml?
> >
> > Why do you need that?
> >
> > > I have a project directory with many sub-project builds,
> > > each with its own project.xml. From the maven.xml, I'm using reactor to
> > > build these in one fell swoop. I'd like things like the jar deployment
> > > site/directory to be specified at the main project level, instead of
> > > duplicating the project.properties for each sub-project (something like
> > > 2 dozen of these). Since the only project-specific properties file
> > > loaded is in ${basedir}, this doesn't appear to work...or does it? Is
> > > there a maven tag to load ${basedir}../../project.properties into the
> > > jelly context?
> >
> > According the the reactor build in the touchstone properties are being
> > passed around projects fine. If you want to verify look at:
> >
> > http://cvs.apache.org/viewcvs.cgi/jakarta-turbine-maven/src/test/touchstone-build/src/reactor-build/standard/
> >
> > In this functional test there is inheritance going on so Maven inherits
> > properties from the parent.
> >
> > The reactor has a shared jelly script for project that run in the
> > reactor that don't inherit. Would you like a shared properties file as
> > well? Maven will not take anything from the top-level project in a
> > reactor by default unless the project actually inherits from that
> > project.
> >
> > > John
> > >
> > >
> > >
> > >
> > >
> > > --
> > > To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> > > For additional commands, e-mail: <ma...@jakarta.apache.org>
> > --
> > jvz.
> >
> > Jason van Zyl
> > jason@zenplex.com
> > http://tambora.zenplex.org
> >
> > In short, man creates for himself a new religion of a rational
> > and technical order to justify his work and to be justified in it.
> >
> > -- Jacques Ellul, The Technological Society
> >
> >
> > --
> > To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> > For additional commands, e-mail: <ma...@jakarta.apache.org>
> >
>
>
> ______________________________________________________________________
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
jvz.
Jason van Zyl
jason@zenplex.com
http://tambora.zenplex.org
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
Re: loading an arbitrary properties file
Posted by John Casey <jd...@commonjava.org>.
Here's the problem, and a diff containing the fix:
The Problem:
The driver.properties file has a set of defaults which may not be
appropriate, as the are just markers denoting an invalid setting. This
erases any properties of the same name in the parent context, since
inheritance is turned off while the properties set (system, user,
project, project build, and driver) are loaded, which means those
default marker values in the driver.properties file get precedence over
the parent project.properties file, which I think is unintended.
The Solution (maybe, I dunno about design decisions...):
If the new sub-project context is created using the parent context, and
then the driver.properties are loaded BEFORE turning off the interitance
attribute, then the rest of the properties are loaded as usual,
everything should progress as normal with the exception that those
invalid default markers are replaced by values from the parent context.
I realize that some of the values in the driver.properties file may need
to be there to override some things from the base project (such as
${basedir}, I guess), so the "right" solution may actually be to create
a markers.properties file for the invalid marker values, and load that
like the driver.properties file in my attached diff...However, it looks
as though this diff will work for now...
*******************************************
I haven't been able to build this copy, since for some reason the maven
build seems broken in the Deploy plugin's build process...it can't find
org.apache.maven.project.Project (fun, fun)...but I think the concept is
solid, and that's really what I wanted to get across.
*******************************************
Hope it helps,
John
On Tue, 2003-01-21 at 13:12, Jason van Zyl wrote:
> On Tue, 2003-01-21 at 11:38, John Casey wrote:
> > Is there a way to include an arbitrary properties file from the
> > maven.xml?
>
> Why do you need that?
>
> > I have a project directory with many sub-project builds,
> > each with its own project.xml. From the maven.xml, I'm using reactor to
> > build these in one fell swoop. I'd like things like the jar deployment
> > site/directory to be specified at the main project level, instead of
> > duplicating the project.properties for each sub-project (something like
> > 2 dozen of these). Since the only project-specific properties file
> > loaded is in ${basedir}, this doesn't appear to work...or does it? Is
> > there a maven tag to load ${basedir}../../project.properties into the
> > jelly context?
>
> According the the reactor build in the touchstone properties are being
> passed around projects fine. If you want to verify look at:
>
> http://cvs.apache.org/viewcvs.cgi/jakarta-turbine-maven/src/test/touchstone-build/src/reactor-build/standard/
>
> In this functional test there is inheritance going on so Maven inherits
> properties from the parent.
>
> The reactor has a shared jelly script for project that run in the
> reactor that don't inherit. Would you like a shared properties file as
> well? Maven will not take anything from the top-level project in a
> reactor by default unless the project actually inherits from that
> project.
>
> > John
> >
> >
> >
> >
> >
> > --
> > To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> > For additional commands, e-mail: <ma...@jakarta.apache.org>
> --
> jvz.
>
> Jason van Zyl
> jason@zenplex.com
> http://tambora.zenplex.org
>
> In short, man creates for himself a new religion of a rational
> and technical order to justify his work and to be justified in it.
>
> -- Jacques Ellul, The Technological Society
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
Re: loading an arbitrary properties file
Posted by Jason van Zyl <ja...@zenplex.com>.
On Tue, 2003-01-21 at 11:38, John Casey wrote:
> Is there a way to include an arbitrary properties file from the
> maven.xml?
Why do you need that?
> I have a project directory with many sub-project builds,
> each with its own project.xml. From the maven.xml, I'm using reactor to
> build these in one fell swoop. I'd like things like the jar deployment
> site/directory to be specified at the main project level, instead of
> duplicating the project.properties for each sub-project (something like
> 2 dozen of these). Since the only project-specific properties file
> loaded is in ${basedir}, this doesn't appear to work...or does it? Is
> there a maven tag to load ${basedir}../../project.properties into the
> jelly context?
According the the reactor build in the touchstone properties are being
passed around projects fine. If you want to verify look at:
http://cvs.apache.org/viewcvs.cgi/jakarta-turbine-maven/src/test/touchstone-build/src/reactor-build/standard/
In this functional test there is inheritance going on so Maven inherits
properties from the parent.
The reactor has a shared jelly script for project that run in the
reactor that don't inherit. Would you like a shared properties file as
well? Maven will not take anything from the top-level project in a
reactor by default unless the project actually inherits from that
project.
> John
>
>
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
jvz.
Jason van Zyl
jason@zenplex.com
http://tambora.zenplex.org
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society