do something before *.properties files load
Hi, I'd like to set a property based on some other command line property. For instance if: maven -Denv=qa java:compile I'd like this: build.properties --- some.arbitrary.property=qaValue but if maven -Denv=prod java:compile I'd like this: build.properties --- some.arbitrary.property=prodValue I've come up with 2 theoretical solutions, but I don't know if either are valid. 1) Can I embed jelly in my build.properties files? 2) Is there a goal that occurs before maven loads the properties file. So I could write a ... ... some.arbitrary.property=qaValue ... some.arbitrary.property=prodValue Thanks, Ben - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: do something before *.properties files load
> 1) Can I embed jelly in my build.properties files?
The answer to the question you were trying to ask is yes, but to this
specific one, no. Jelly is the XML scripting, JEXL is the expression
language used in Jelly. You can use an expression in build.properties,
but not embed Jelly - just in case you wanted to start doing
conditionals :)
eg,
somedir=${basedir}/src
otherdir=${maven.build.dir}/other
> 2) Is there a goal that occurs before maven loads the properties
> file. So I could write a
> ...
> ...
> some.arbitrary.property=qaValue
> ...
> some.arbitrary.property=prodValue
No, but the first is nicer and works.
- Brett
>
> Thanks,
> Ben
>
> -
> 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]
Re: do something before *.properties files load
Thanks Brett. I ran some tests specifying expressions in the
project.properties file. It's pretty neat how the properties retain a
reference of some kind instead of resolving at the initial assignment.
For instance:
qb.name=Tommy Maddox
best.qb.ever=${qb.name}
qb.name=Ben Roethlisberger
now best.qb.ever is "Ben Roethlisberger". I see this works now - is
this indended (I'm assuming is must be)? Am I safe in relying on
maven to stay this way?
One more general question. The reason I'm asking is because I'd like
to do the following. Maybe this is way off base and there's a better
way:
command
--
maven -Denv=qa jar:jar
maven.xml
...
project.properties
-
maven.src.dir=${basepath}/src/java
project.xml
-
...
this is bogus and will never be used
Does this make sense? I think this is the best way to be able to flip
things like maven.src.dir by specifying an environment on the command
line.
One more.. I can't find the property that equates to this tag
. I checked here:
http://maven.apache.org/reference/plugins/test/properties.html
and here:
http://maven.apache.org/reference/user-guide.html#Behavioural_Properties
am I just blind or is it not listed?
Thanks,
Ben
On Fri, 19 Nov 2004 09:01:48 +1100, Brett Porter <[EMAIL PROTECTED]> wrote:
> > 1) Can I embed jelly in my build.properties files?
>
> The answer to the question you were trying to ask is yes, but to this
> specific one, no. Jelly is the XML scripting, JEXL is the expression
> language used in Jelly. You can use an expression in build.properties,
> but not embed Jelly - just in case you wanted to start doing
> conditionals :)
>
> eg,
> somedir=${basedir}/src
> otherdir=${maven.build.dir}/other
>
> > 2) Is there a goal that occurs before maven loads the properties
> > file. So I could write a
> > ...
> > ...
> > some.arbitrary.property=qaValue
> > ...
> > some.arbitrary.property=prodValue
>
> No, but the first is nicer and works.
>
> - Brett
>
> >
> > Thanks,
> > Ben
> >
> > -
> > 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]
Re: do something before *.properties files load
Hi Ben,
Yes, you can expect that behaviour to remain the same.
maven.src.dir is not what you think it is. You would need to modify
pom.build.sourceDirectory, but this is not recommended.
Why are you changing sources in different environments? Perhaps you
want s?
- Brett
On Fri, 19 Nov 2004 08:15:27 -0500, Ben Anderson
<[EMAIL PROTECTED]> wrote:
> Thanks Brett. I ran some tests specifying expressions in the
> project.properties file. It's pretty neat how the properties retain a
> reference of some kind instead of resolving at the initial assignment.
> For instance:
>
> qb.name=Tommy Maddox
> best.qb.ever=${qb.name}
> qb.name=Ben Roethlisberger
>
> now best.qb.ever is "Ben Roethlisberger". I see this works now - is
> this indended (I'm assuming is must be)? Am I safe in relying on
> maven to stay this way?
>
> One more general question. The reason I'm asking is because I'd like
> to do the following. Maybe this is way off base and there's a better
> way:
>
> command
> --
> maven -Denv=qa jar:jar
>
> maven.xml
>
>
>
>
>
> ...
>
> project.properties
> -
> maven.src.dir=${basepath}/src/java
>
> project.xml
> -
> ...
>
>
> this is bogus and will never be used
>
>
> Does this make sense? I think this is the best way to be able to flip
> things like maven.src.dir by specifying an environment on the command
> line.
>
> One more.. I can't find the property that equates to this tag
> . I checked here:
> http://maven.apache.org/reference/plugins/test/properties.html
> and here:
> http://maven.apache.org/reference/user-guide.html#Behavioural_Properties
> am I just blind or is it not listed?
>
> Thanks,
> Ben
>
>
>
>
> On Fri, 19 Nov 2004 09:01:48 +1100, Brett Porter <[EMAIL PROTECTED]> wrote:
> > > 1) Can I embed jelly in my build.properties files?
> >
> > The answer to the question you were trying to ask is yes, but to this
> > specific one, no. Jelly is the XML scripting, JEXL is the expression
> > language used in Jelly. You can use an expression in build.properties,
> > but not embed Jelly - just in case you wanted to start doing
> > conditionals :)
> >
> > eg,
> > somedir=${basedir}/src
> > otherdir=${maven.build.dir}/other
> >
> > > 2) Is there a goal that occurs before maven loads the properties
> > > file. So I could write a
> > > ...
> > > ...
> > > some.arbitrary.property=qaValue
> > > ...
> > > some.arbitrary.property=prodValue
> >
> > No, but the first is nicer and works.
> >
> > - Brett
> >
> > >
> > > Thanks,
> > > Ben
> > >
> > > -
> > > 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]
Re: do something before *.properties files load
I want to be able to build the source using either my local working
directory which I have modified, or vss's shadow directory which
contains only checked in files. Same goes for unit tests.
On Sat, 20 Nov 2004 00:26:28 +1100, Brett Porter <[EMAIL PROTECTED]> wrote:
> Hi Ben,
>
> Yes, you can expect that behaviour to remain the same.
>
> maven.src.dir is not what you think it is. You would need to modify
> pom.build.sourceDirectory, but this is not recommended.
>
> Why are you changing sources in different environments? Perhaps you
> want s?
>
> - Brett
>
>
>
>
> On Fri, 19 Nov 2004 08:15:27 -0500, Ben Anderson
> <[EMAIL PROTECTED]> wrote:
> > Thanks Brett. I ran some tests specifying expressions in the
> > project.properties file. It's pretty neat how the properties retain a
> > reference of some kind instead of resolving at the initial assignment.
> > For instance:
> >
> > qb.name=Tommy Maddox
> > best.qb.ever=${qb.name}
> > qb.name=Ben Roethlisberger
> >
> > now best.qb.ever is "Ben Roethlisberger". I see this works now - is
> > this indended (I'm assuming is must be)? Am I safe in relying on
> > maven to stay this way?
> >
> > One more general question. The reason I'm asking is because I'd like
> > to do the following. Maybe this is way off base and there's a better
> > way:
> >
> > command
> > --
> > maven -Denv=qa jar:jar
> >
> > maven.xml
> >
> >
> >
> >
> >
> > ...
> >
> > project.properties
> > -
> > maven.src.dir=${basepath}/src/java
> >
> > project.xml
> > -
> > ...
> >
> >
> > this is bogus and will never be used
> >
> >
> > Does this make sense? I think this is the best way to be able to flip
> > things like maven.src.dir by specifying an environment on the command
> > line.
> >
> > One more.. I can't find the property that equates to this tag
> > . I checked here:
> > http://maven.apache.org/reference/plugins/test/properties.html
> > and here:
> > http://maven.apache.org/reference/user-guide.html#Behavioural_Properties
> > am I just blind or is it not listed?
> >
> > Thanks,
> > Ben
> >
> >
> >
> >
> > On Fri, 19 Nov 2004 09:01:48 +1100, Brett Porter <[EMAIL PROTECTED]> wrote:
> > > > 1) Can I embed jelly in my build.properties files?
> > >
> > > The answer to the question you were trying to ask is yes, but to this
> > > specific one, no. Jelly is the XML scripting, JEXL is the expression
> > > language used in Jelly. You can use an expression in build.properties,
> > > but not embed Jelly - just in case you wanted to start doing
> > > conditionals :)
> > >
> > > eg,
> > > somedir=${basedir}/src
> > > otherdir=${maven.build.dir}/other
> > >
> > > > 2) Is there a goal that occurs before maven loads the properties
> > > > file. So I could write a
> > > > ...
> > > > ...
> > > > some.arbitrary.property=qaValue
> > > > ...
> > > > some.arbitrary.property=prodValue
> > >
> > > No, but the first is nicer and works.
> > >
> > > - Brett
> > >
> > > >
> > > > Thanks,
> > > > Ben
> > > >
> > > > -
> > > > 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]
Re: do something before *.properties files load
Can I suggest that you just use project.xml from your local copy or
the VSS shadow directory respectively? Does this pose some particular
limitation?
I do something similar in some cases - having a clean CVS checkout and
an in progress checkout.
- Brett
On Fri, 19 Nov 2004 08:37:55 -0500, Ben Anderson
<[EMAIL PROTECTED]> wrote:
> I want to be able to build the source using either my local working
> directory which I have modified, or vss's shadow directory which
> contains only checked in files. Same goes for unit tests.
>
>
>
>
> On Sat, 20 Nov 2004 00:26:28 +1100, Brett Porter <[EMAIL PROTECTED]> wrote:
> > Hi Ben,
> >
> > Yes, you can expect that behaviour to remain the same.
> >
> > maven.src.dir is not what you think it is. You would need to modify
> > pom.build.sourceDirectory, but this is not recommended.
> >
> > Why are you changing sources in different environments? Perhaps you
> > want s?
> >
> > - Brett
> >
> >
> >
> >
> > On Fri, 19 Nov 2004 08:15:27 -0500, Ben Anderson
> > <[EMAIL PROTECTED]> wrote:
> > > Thanks Brett. I ran some tests specifying expressions in the
> > > project.properties file. It's pretty neat how the properties retain a
> > > reference of some kind instead of resolving at the initial assignment.
> > > For instance:
> > >
> > > qb.name=Tommy Maddox
> > > best.qb.ever=${qb.name}
> > > qb.name=Ben Roethlisberger
> > >
> > > now best.qb.ever is "Ben Roethlisberger". I see this works now - is
> > > this indended (I'm assuming is must be)? Am I safe in relying on
> > > maven to stay this way?
> > >
> > > One more general question. The reason I'm asking is because I'd like
> > > to do the following. Maybe this is way off base and there's a better
> > > way:
> > >
> > > command
> > > --
> > > maven -Denv=qa jar:jar
> > >
> > > maven.xml
> > >
> > >
> > >
> > >
> > >
> > > ...
> > >
> > > project.properties
> > > -
> > > maven.src.dir=${basepath}/src/java
> > >
> > > project.xml
> > > -
> > > ...
> > >
> > >
> > > this is bogus and will never be used
> > >
> > >
> > > Does this make sense? I think this is the best way to be able to flip
> > > things like maven.src.dir by specifying an environment on the command
> > > line.
> > >
> > > One more.. I can't find the property that equates to this tag
> > > . I checked here:
> > > http://maven.apache.org/reference/plugins/test/properties.html
> > > and here:
> > > http://maven.apache.org/reference/user-guide.html#Behavioural_Properties
> > > am I just blind or is it not listed?
> > >
> > > Thanks,
> > > Ben
> > >
> > >
> > >
> > >
> > > On Fri, 19 Nov 2004 09:01:48 +1100, Brett Porter <[EMAIL PROTECTED]>
> > > wrote:
> > > > > 1) Can I embed jelly in my build.properties files?
> > > >
> > > > The answer to the question you were trying to ask is yes, but to this
> > > > specific one, no. Jelly is the XML scripting, JEXL is the expression
> > > > language used in Jelly. You can use an expression in build.properties,
> > > > but not embed Jelly - just in case you wanted to start doing
> > > > conditionals :)
> > > >
> > > > eg,
> > > > somedir=${basedir}/src
> > > > otherdir=${maven.build.dir}/other
> > > >
> > > > > 2) Is there a goal that occurs before maven loads the properties
> > > > > file. So I could write a
> > > > > ...
> > > > > ...
> > > > > some.arbitrary.property=qaValue
> > > > > ...
> > > > > some.arbitrary.property=prodValue
> > > >
> > > > No, but the first is nicer and works.
> > > >
> > > > - Brett
> > > >
> > > > >
> > > > > Thanks,
> > > > > Ben
> > > > >
> > > > > -
> > > > > 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]
Re: do something before *.properties files load
Yeah, you're probably right. We should just use maven's inheritance
to sort this stuff out. But this is still throwing me a little. I
want to be able to create artifacts for various environments w/out
changing any files, whether it's renaming or whatever. Does this mean
I would have to create a subdirectory for each different environment?
It would be nice if maven allowed inheritance (which is one of the
many things that makes maven cool) using some other techniqure than
the file structure. For instance, I've already created 2 sub
directories (war and ear) for the same project. To create the ear, I
first cd to the war directory and do a war:install. Then I have to cd
to the ear directory and create my ear. The only reason the ear
directory exists is so that I can specify a dependency on my war
artifact (creating a new project.xml which inherits from the upper
project.xml). I know I can use the reactor here, which would
eliminate some of the "cd"'ing. Back from my tangent... so, in order
to do different environmetns, I'd specify separate sub directories for
each and override accordingly? Does that make more sense? It's a
little different than what I think you suggested, but like I said, I
don't want to have to change files (project.xml, build.properties,
etc.) for each different environment.
Thanks,
Ben
On Sat, 20 Nov 2004 00:43:31 +1100, Brett Porter <[EMAIL PROTECTED]> wrote:
> Can I suggest that you just use project.xml from your local copy or
> the VSS shadow directory respectively? Does this pose some particular
> limitation?
>
> I do something similar in some cases - having a clean CVS checkout and
> an in progress checkout.
>
> - Brett
>
> On Fri, 19 Nov 2004 08:37:55 -0500, Ben Anderson
>
>
> <[EMAIL PROTECTED]> wrote:
> > I want to be able to build the source using either my local working
> > directory which I have modified, or vss's shadow directory which
> > contains only checked in files. Same goes for unit tests.
> >
> >
> >
> >
> > On Sat, 20 Nov 2004 00:26:28 +1100, Brett Porter <[EMAIL PROTECTED]> wrote:
> > > Hi Ben,
> > >
> > > Yes, you can expect that behaviour to remain the same.
> > >
> > > maven.src.dir is not what you think it is. You would need to modify
> > > pom.build.sourceDirectory, but this is not recommended.
> > >
> > > Why are you changing sources in different environments? Perhaps you
> > > want s?
> > >
> > > - Brett
> > >
> > >
> > >
> > >
> > > On Fri, 19 Nov 2004 08:15:27 -0500, Ben Anderson
> > > <[EMAIL PROTECTED]> wrote:
> > > > Thanks Brett. I ran some tests specifying expressions in the
> > > > project.properties file. It's pretty neat how the properties retain a
> > > > reference of some kind instead of resolving at the initial assignment.
> > > > For instance:
> > > >
> > > > qb.name=Tommy Maddox
> > > > best.qb.ever=${qb.name}
> > > > qb.name=Ben Roethlisberger
> > > >
> > > > now best.qb.ever is "Ben Roethlisberger". I see this works now - is
> > > > this indended (I'm assuming is must be)? Am I safe in relying on
> > > > maven to stay this way?
> > > >
> > > > One more general question. The reason I'm asking is because I'd like
> > > > to do the following. Maybe this is way off base and there's a better
> > > > way:
> > > >
> > > > command
> > > > --
> > > > maven -Denv=qa jar:jar
> > > >
> > > > maven.xml
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > ...
> > > >
> > > > project.properties
> > > > -
> > > > maven.src.dir=${basepath}/src/java
> > > >
> > > > project.xml
> > > > -
> > > > ...
> > > >
> > > >
> > > > this is bogus and will never be used
> > > >
> > > >
> > > > Does this make sense? I think this is the best way to be able to flip
> > > > things like maven.src.dir by specifying an environment on the command
> > > > line.
> > > >
> > > > One more.. I can't find the property that equates to this tag
> > > > . I checked here:
> > > > http://maven.apache.org/reference/plugins/test/properties.html
> > > > and here:
> > > > http://maven.apache.org/reference/user-guide.html#Behavioural_Properties
> > > > am I just blind or is it not listed?
> > > >
> > > > Thanks,
> > > > Ben
> > > >
> > > >
> > > >
> > > >
> > > > On Fri, 19 Nov 2004 09:01:48 +1100, Brett Porter <[EMAIL PROTECTED]>
> > > > wrote:
> > > > > > 1) Can I embed jelly in my build.properties files?
> > > > >
> > > > > The answer to the question you were trying to ask is yes, but to this
> > > > > specific one, no. Jelly is the XML scripting, JEXL is the expression
> > > > > language used in Jelly. You can use an expression in build.properties,
> > > > > but not embed Jelly - just in case you wanted to start doing
> > > > > conditionals :)
> > > > >
> > > > > eg,
> > > > > somedir=${basedir}/src
> > > > > otherdir=${maven.build.dir}/other
> > > > >
> > > > > > 2) Is there a goal that occurs before maven loads the properties
> > > > > > file.
RE: do something before *.properties files load
I think that environment specifical things can be set in the
build.properties file.
I am using one build.properties file for each environment. For instance,
for Windows I have one build.properties in my home, for unix a slightly
different one in my unix home. For nightly build we have a
different unix user, which has a special build.properties file in home.
If I work with several environment on the same machine, I simply switch
the build.properties file in my home.
I hope this helps.
Greetings
Pierre
-Original Message-
From: Ben Anderson [mailto:[EMAIL PROTECTED]
Sent: Freitag, 19. November 2004 15:52
To: Maven Users List
Subject: Re: do something before *.properties files load
Yeah, you're probably right. We should just use maven's inheritance
to sort this stuff out. But this is still throwing me a little. I
want to be able to create artifacts for various environments w/out
changing any files, whether it's renaming or whatever. Does this mean
I would have to create a subdirectory for each different environment?
It would be nice if maven allowed inheritance (which is one of the
many things that makes maven cool) using some other techniqure than
the file structure. For instance, I've already created 2 sub
directories (war and ear) for the same project. To create the ear, I
first cd to the war directory and do a war:install. Then I have to cd
to the ear directory and create my ear. The only reason the ear
directory exists is so that I can specify a dependency on my war
artifact (creating a new project.xml which inherits from the upper
project.xml). I know I can use the reactor here, which would
eliminate some of the "cd"'ing. Back from my tangent... so, in order
to do different environmetns, I'd specify separate sub directories for
each and override accordingly? Does that make more sense? It's a
little different than what I think you suggested, but like I said, I
don't want to have to change files (project.xml, build.properties,
etc.) for each different environment.
Thanks,
Ben
On Sat, 20 Nov 2004 00:43:31 +1100, Brett Porter
<[EMAIL PROTECTED]> wrote:
> Can I suggest that you just use project.xml from your local copy or
> the VSS shadow directory respectively? Does this pose some particular
> limitation?
>
> I do something similar in some cases - having a clean CVS checkout and
> an in progress checkout.
>
> - Brett
>
> On Fri, 19 Nov 2004 08:37:55 -0500, Ben Anderson
>
>
> <[EMAIL PROTECTED]> wrote:
> > I want to be able to build the source using either my local working
> > directory which I have modified, or vss's shadow directory which
> > contains only checked in files. Same goes for unit tests.
> >
> >
> >
> >
> > On Sat, 20 Nov 2004 00:26:28 +1100, Brett Porter
<[EMAIL PROTECTED]> wrote:
> > > Hi Ben,
> > >
> > > Yes, you can expect that behaviour to remain the same.
> > >
> > > maven.src.dir is not what you think it is. You would need to
modify
> > > pom.build.sourceDirectory, but this is not recommended.
> > >
> > > Why are you changing sources in different environments? Perhaps
you
> > > want s?
> > >
> > > - Brett
> > >
> > >
> > >
> > >
> > > On Fri, 19 Nov 2004 08:15:27 -0500, Ben Anderson
> > > <[EMAIL PROTECTED]> wrote:
> > > > Thanks Brett. I ran some tests specifying expressions in the
> > > > project.properties file. It's pretty neat how the properties
retain a
> > > > reference of some kind instead of resolving at the initial
assignment.
> > > > For instance:
> > > >
> > > > qb.name=Tommy Maddox
> > > > best.qb.ever=${qb.name}
> > > > qb.name=Ben Roethlisberger
> > > >
> > > > now best.qb.ever is "Ben Roethlisberger". I see this works now
- is
> > > > this indended (I'm assuming is must be)? Am I safe in relying
on
> > > > maven to stay this way?
> > > >
> > > > One more general question. The reason I'm asking is because I'd
like
> > > > to do the following. Maybe this is way off base and there's a
better
> > > > way:
> > > >
> > > > command
> > > > --
> > > > maven -Denv=qa jar:jar
> > > >
> > > > maven.xml
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > ...
> > > >
> > > > project.properties
> > > > -
>
Re: do something before *.properties files load
yes, I understand that. But what if I don't want to swap
build.properties files for each environment? I want to the same user,
w/out making them manually change build.properties, to be able to
build for various environments from the same machine.
On Fri, 19 Nov 2004 16:11:13 +0100, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
> I think that environment specifical things can be set in the
> build.properties file.
> I am using one build.properties file for each environment. For instance,
> for Windows I have one build.properties in my home, for unix a slightly
> different one in my unix home. For nightly build we have a
> different unix user, which has a special build.properties file in home.
> If I work with several environment on the same machine, I simply switch
> the build.properties file in my home.
> I hope this helps.
>
> Greetings
> Pierre
>
>
>
> -Original Message-
> From: Ben Anderson [mailto:[EMAIL PROTECTED]
> Sent: Freitag, 19. November 2004 15:52
> To: Maven Users List
> Subject: Re: do something before *.properties files load
>
> Yeah, you're probably right. We should just use maven's inheritance
> to sort this stuff out. But this is still throwing me a little. I
> want to be able to create artifacts for various environments w/out
> changing any files, whether it's renaming or whatever. Does this mean
> I would have to create a subdirectory for each different environment?
> It would be nice if maven allowed inheritance (which is one of the
> many things that makes maven cool) using some other techniqure than
> the file structure. For instance, I've already created 2 sub
> directories (war and ear) for the same project. To create the ear, I
> first cd to the war directory and do a war:install. Then I have to cd
> to the ear directory and create my ear. The only reason the ear
> directory exists is so that I can specify a dependency on my war
> artifact (creating a new project.xml which inherits from the upper
> project.xml). I know I can use the reactor here, which would
> eliminate some of the "cd"'ing. Back from my tangent... so, in order
> to do different environmetns, I'd specify separate sub directories for
> each and override accordingly? Does that make more sense? It's a
> little different than what I think you suggested, but like I said, I
> don't want to have to change files (project.xml, build.properties,
> etc.) for each different environment.
> Thanks,
> Ben
>
> On Sat, 20 Nov 2004 00:43:31 +1100, Brett Porter
> <[EMAIL PROTECTED]> wrote:
> > Can I suggest that you just use project.xml from your local copy or
> > the VSS shadow directory respectively? Does this pose some particular
> > limitation?
> >
> > I do something similar in some cases - having a clean CVS checkout and
> > an in progress checkout.
> >
> > - Brett
> >
> > On Fri, 19 Nov 2004 08:37:55 -0500, Ben Anderson
> >
> >
> > <[EMAIL PROTECTED]> wrote:
> > > I want to be able to build the source using either my local working
> > > directory which I have modified, or vss's shadow directory which
> > > contains only checked in files. Same goes for unit tests.
> > >
> > >
> > >
> > >
> > > On Sat, 20 Nov 2004 00:26:28 +1100, Brett Porter
> <[EMAIL PROTECTED]> wrote:
> > > > Hi Ben,
> > > >
> > > > Yes, you can expect that behaviour to remain the same.
> > > >
> > > > maven.src.dir is not what you think it is. You would need to
> modify
> > > > pom.build.sourceDirectory, but this is not recommended.
> > > >
> > > > Why are you changing sources in different environments? Perhaps
> you
> > > > want s?
> > > >
> > > > - Brett
> > > >
> > > >
> > > >
> > > >
> > > > On Fri, 19 Nov 2004 08:15:27 -0500, Ben Anderson
> > > > <[EMAIL PROTECTED]> wrote:
> > > > > Thanks Brett. I ran some tests specifying expressions in the
> > > > > project.properties file. It's pretty neat how the properties
> retain a
> > > > > reference of some kind instead of resolving at the initial
> assignment.
> > > > > For instance:
> > > > >
> > > > > qb.name=Tommy Maddox
> > > > > best.qb.ever=${qb.name}
> > > > > qb.name=Ben Roethlisberger
> > > > >
> > > > > now best.qb.ever is "Ben Roethlisberger". I see this works now
> - is
> > > > > this indended (I
RE: do something before *.properties files load
I am coming to a similar problem as you, Ben. I can see two possible solutions,
I've yet to decide which fits our setup the best.
The first solution is to use Ant's property replacement task. For example,
let's
say your environment specific properties are in your web.xml file. You'd create
a generic web_template.xml file with all the environment specific information
written in the form of: ${env.specific.property}. Then, you'll create a
.properties file for each of your environments, (dev.properties) which will
contain your environment specific properties for development. Then create a
preGoal for war:war (maybe something else), and use the ant properties
replacement task ( I believe) to get those values into the newly
generated web.xml. Then use this new web.xml will be used in the newly
generated
war file. You'll have to create some switch that can be used on the command
line, or maybe even some project level goals in your maven.xml files that will
generate what you need (think of something like "build-dev" to create in your
top
most maven.xml file).
Another solution would be to create a separate web.xml for each environment,
web_dev.xml for example. Then in your preGoal for war:war, you could switch on
a
property specified on the command line, and copy the selected xml file to
web.xml. Then the newly generated war file will contain the right web.xml.
Personally, I like the first solution a bit better. In a way, it makes you
declare what the environment specific properties are, and you must provide a
value for them to work. It also allows you to replace properties into different
types of files, like source code.
I've used this approach for some of my Xdoclet code. I'll set some Xdoclet
values to be like "${env.property}", let Xdoclet generate other files, then run
my properties file through, replacing what needs to be replaced. It seems to
work pretty well, I find that many of my properties are really quite common, and
as a result, I only have to change the property in one place to affect a change
in my whole build.
Obviously, it makes yet another step to get from code to build, and maybe it's a
bit difficult to explain to another developer. But you document your build
process perfectly anyway, right? ;)
Hope that helps.
Troy
-Original Message-
From: Ben Anderson [mailto:[EMAIL PROTECTED]
Sent: Friday, November 19, 2004 10:44 AM
To: Maven Users List
Subject: Re: do something before *.properties files load
yes, I understand that. But what if I don't want to swap build.properties files
for each environment? I want to the same user, w/out making them manually
change
build.properties, to be able to build for various environments from the same
machine.
On Fri, 19 Nov 2004 16:11:13 +0100, [EMAIL PROTECTED] <[EMAIL PROTECTED]>
wrote:
> I think that environment specifical things can be set in the
> build.properties file. I am using one build.properties file for each
> environment. For instance, for Windows I have one build.properties in
> my home, for unix a slightly different one in my unix home. For
> nightly build we have a different unix user, which has a special
> build.properties file in home. If I work with several environment on
> the same machine, I simply switch the build.properties file in my
> home. I hope this helps.
>
> Greetings
> Pierre
>
>
>
> -Original Message-
> From: Ben Anderson [mailto:[EMAIL PROTECTED]
> Sent: Freitag, 19. November 2004 15:52
> To: Maven Users List
> Subject: Re: do something before *.properties files load
>
> Yeah, you're probably right. We should just use maven's inheritance
> to sort this stuff out. But this is still throwing me a little. I
> want to be able to create artifacts for various environments w/out
> changing any files, whether it's renaming or whatever. Does this mean
> I would have to create a subdirectory for each different environment?
> It would be nice if maven allowed inheritance (which is one of the
> many things that makes maven cool) using some other techniqure than
> the file structure. For instance, I've already created 2 sub
> directories (war and ear) for the same project. To create the ear, I
> first cd to the war directory and do a war:install. Then I have to cd
> to the ear directory and create my ear. The only reason the ear
> directory exists is so that I can specify a dependency on my war
> artifact (creating a new project.xml which inherits from the upper
> project.xml). I know I can use the reactor here, which would
> eliminate some of the "cd"'ing. Back from my tangent... so, in order
> to do different environmetns, I'd specify separate sub directories for
> each and override accordingly? Does that make more sense? It&#x
RE: do something before *.properties files load
The first solution can also be done with the following ant snippet:
(I found it in my build.xml script.)
T
-Original Message-
From: Poppe, Troy [mailto:[EMAIL PROTECTED]
Sent: Friday, November 19, 2004 11:03 AM
To: 'Maven Users List'; 'Ben Anderson'
Subject: RE: do something before *.properties files load
I am coming to a similar problem as you, Ben. I can see two possible solutions,
I've yet to decide which fits our setup the best.
The first solution is to use Ant's property replacement task. For example,
let's
say your environment specific properties are in your web.xml file. You'd create
a generic web_template.xml file with all the environment specific information
written in the form of: ${env.specific.property}. Then, you'll create a
.properties file for each of your environments, (dev.properties) which will
contain your environment specific properties for development. Then create a
preGoal for war:war (maybe something else), and use the ant properties
replacement task ( I believe) to get those values into the newly
generated web.xml. Then use this new web.xml will be used in the newly
generated
war file. You'll have to create some switch that can be used on the command
line, or maybe even some project level goals in your maven.xml files that will
generate what you need (think of something like "build-dev" to create in your
top
most maven.xml file).
Another solution would be to create a separate web.xml for each environment,
web_dev.xml for example. Then in your preGoal for war:war, you could switch on
a
property specified on the command line, and copy the selected xml file to
web.xml. Then the newly generated war file will contain the right web.xml.
Personally, I like the first solution a bit better. In a way, it makes you
declare what the environment specific properties are, and you must provide a
value for them to work. It also allows you to replace properties into different
types of files, like source code.
I've used this approach for some of my Xdoclet code. I'll set some Xdoclet
values to be like "${env.property}", let Xdoclet generate other files, then run
my properties file through, replacing what needs to be replaced. It seems to
work pretty well, I find that many of my properties are really quite common, and
as a result, I only have to change the property in one place to affect a change
in my whole build.
Obviously, it makes yet another step to get from code to build, and maybe it's a
bit difficult to explain to another developer. But you document your build
process perfectly anyway, right? ;)
Hope that helps.
Troy
-Original Message-
From: Ben Anderson [mailto:[EMAIL PROTECTED]
Sent: Friday, November 19, 2004 10:44 AM
To: Maven Users List
Subject: Re: do something before *.properties files load
yes, I understand that. But what if I don't want to swap build.properties files
for each environment? I want to the same user, w/out making them manually
change
build.properties, to be able to build for various environments from the same
machine.
On Fri, 19 Nov 2004 16:11:13 +0100, [EMAIL PROTECTED] <[EMAIL PROTECTED]>
wrote:
> I think that environment specifical things can be set in the
> build.properties file. I am using one build.properties file for each
> environment. For instance, for Windows I have one build.properties in
> my home, for unix a slightly different one in my unix home. For
> nightly build we have a different unix user, which has a special
> build.properties file in home. If I work with several environment on
> the same machine, I simply switch the build.properties file in my
> home. I hope this helps.
>
> Greetings
> Pierre
>
>
>
> -Original Message-----
> From: Ben Anderson [mailto:[EMAIL PROTECTED]
> Sent: Freitag, 19. November 2004 15:52
> To: Maven Users List
> Subject: Re: do something before *.properties files load
>
> Yeah, you're probably right. We should just use maven's inheritance
> to sort this stuff out. But this is still throwing me a little. I
> want to be able to create artifacts for various environments w/out
> changing any files, whether it's renaming or whatever. Does this mean
> I would have to create a subdirectory for each different environment?
> It would be nice if maven allowed inheritance (which is one of the
> many things that makes maven cool) using some other techniqure than
> the file structure. For instance, I've already created 2 sub
> directories (war and ear) for the same project. To create the ear, I
> first cd to the war directory and do a war:install. Then I have to cd
> to the ear directory and create my ear. The only reason the ear
> directory exists is so that I can specify a dependency on my war
>
Re: do something before *.properties files load
Neither of those will work, because I want to dynamically change these:
${basepath}/src/java
${basepath}/src/test
...
The properties file that specifices ${basepath} must be set before the
maven.xml is parsed.
On Fri, 19 Nov 2004 11:02:55 -0500, Poppe, Troy <[EMAIL PROTECTED]> wrote:
>
> I am coming to a similar problem as you, Ben. I can see two possible
> solutions,
> I've yet to decide which fits our setup the best.
>
> The first solution is to use Ant's property replacement task. For example,
> let's
> say your environment specific properties are in your web.xml file. You'd
> create
> a generic web_template.xml file with all the environment specific information
> written in the form of: ${env.specific.property}. Then, you'll create a
> .properties file for each of your environments, (dev.properties) which will
> contain your environment specific properties for development. Then create a
> preGoal for war:war (maybe something else), and use the ant properties
> replacement task ( I believe) to get those values into the newly
> generated web.xml. Then use this new web.xml will be used in the newly
> generated
> war file. You'll have to create some switch that can be used on the command
> line, or maybe even some project level goals in your maven.xml files that will
> generate what you need (think of something like "build-dev" to create in your
> top
> most maven.xml file).
>
> Another solution would be to create a separate web.xml for each environment,
> web_dev.xml for example. Then in your preGoal for war:war, you could switch
> on a
> property specified on the command line, and copy the selected xml file to
> web.xml. Then the newly generated war file will contain the right web.xml.
>
> Personally, I like the first solution a bit better. In a way, it makes you
> declare what the environment specific properties are, and you must provide a
> value for them to work. It also allows you to replace properties into
> different
> types of files, like source code.
>
> I've used this approach for some of my Xdoclet code. I'll set some Xdoclet
> values to be like "${env.property}", let Xdoclet generate other files, then
> run
> my properties file through, replacing what needs to be replaced. It seems to
> work pretty well, I find that many of my properties are really quite common,
> and
> as a result, I only have to change the property in one place to affect a
> change
> in my whole build.
>
> Obviously, it makes yet another step to get from code to build, and maybe
> it's a
> bit difficult to explain to another developer. But you document your build
> process perfectly anyway, right? ;)
>
> Hope that helps.
>
> Troy
>
>
>
>
> -Original Message-
> From: Ben Anderson [mailto:[EMAIL PROTECTED]
> Sent: Friday, November 19, 2004 10:44 AM
> To: Maven Users List
> Subject: Re: do something before *.properties files load
>
> yes, I understand that. But what if I don't want to swap build.properties
> files
> for each environment? I want to the same user, w/out making them manually
> change
> build.properties, to be able to build for various environments from the same
> machine.
>
> On Fri, 19 Nov 2004 16:11:13 +0100, [EMAIL PROTECTED] <[EMAIL PROTECTED]>
> wrote:
> > I think that environment specifical things can be set in the
> > build.properties file. I am using one build.properties file for each
> > environment. For instance, for Windows I have one build.properties in
> > my home, for unix a slightly different one in my unix home. For
> > nightly build we have a different unix user, which has a special
> > build.properties file in home. If I work with several environment on
> > the same machine, I simply switch the build.properties file in my
> > home. I hope this helps.
> >
> > Greetings
> > Pierre
> >
> >
> >
> > -Original Message-
> > From: Ben Anderson [mailto:[EMAIL PROTECTED]
> > Sent: Freitag, 19. November 2004 15:52
> > To: Maven Users List
> > Subject: Re: do something before *.properties files load
> >
> > Yeah, you're probably right. We should just use maven's inheritance
> > to sort this stuff out. But this is still throwing me a little. I
> > want to be able to create artifacts for various environments w/out
> > changing any files, whether it's renaming or whatever. Does this mean
> > I would have to create a subdirectory for each different environment?
> > It would be nice if maven allowed inheritance (which is one of the
> > many things that makes maven cool) us
RE: do something before *.properties files load
So you deploy different code to different environments?
T
-Original Message-
From: Ben Anderson [mailto:[EMAIL PROTECTED]
Sent: Friday, November 19, 2004 11:29 AM
To: Maven Users List
Subject: Re: do something before *.properties files load
Neither of those will work, because I want to dynamically change these:
${basepath}/src/java
${basepath}/src/test
...
The properties file that specifices ${basepath} must be set before the maven.xml
is parsed.
On Fri, 19 Nov 2004 11:02:55 -0500, Poppe, Troy <[EMAIL PROTECTED]> wrote:
>
> I am coming to a similar problem as you, Ben. I can see two possible
> solutions, I've yet to decide which fits our setup the best.
>
> The first solution is to use Ant's property replacement task. For
> example, let's say your environment specific properties are in your
> web.xml file. You'd create a generic web_template.xml file with all
> the environment specific information written in the form of:
> ${env.specific.property}. Then, you'll create a .properties file for
> each of your environments, (dev.properties) which will contain your
> environment specific properties for development. Then create a
> preGoal for war:war (maybe something else), and use the ant properties
> replacement task ( I believe) to get those values into the
> newly generated web.xml. Then use this new web.xml will be used in
> the newly generated war file. You'll have to create some switch that
> can be used on the command line, or maybe even some project level
> goals in your maven.xml files that will generate what you need (think
> of something like "build-dev" to create in your top most maven.xml
> file).
>
> Another solution would be to create a separate web.xml for each
> environment, web_dev.xml for example. Then in your preGoal for
> war:war, you could switch on a property specified on the command line,
> and copy the selected xml file to web.xml. Then the newly generated
> war file will contain the right web.xml.
>
> Personally, I like the first solution a bit better. In a way, it
> makes you declare what the environment specific properties are, and
> you must provide a value for them to work. It also allows you to
> replace properties into different types of files, like source code.
>
> I've used this approach for some of my Xdoclet code. I'll set some
> Xdoclet values to be like "${env.property}", let Xdoclet generate
> other files, then run my properties file through, replacing what needs
> to be replaced. It seems to work pretty well, I find that many of my
> properties are really quite common, and as a result, I only have to
> change the property in one place to affect a change in my whole build.
>
> Obviously, it makes yet another step to get from code to build, and
> maybe it's a bit difficult to explain to another developer. But you
> document your build process perfectly anyway, right? ;)
>
> Hope that helps.
>
> Troy
>
>
>
>
> -Original Message-
> From: Ben Anderson [mailto:[EMAIL PROTECTED]
> Sent: Friday, November 19, 2004 10:44 AM
> To: Maven Users List
> Subject: Re: do something before *.properties files load
>
> yes, I understand that. But what if I don't want to swap
> build.properties files for each environment? I want to the same user,
> w/out making them manually change build.properties, to be able to
> build for various environments from the same machine.
>
> On Fri, 19 Nov 2004 16:11:13 +0100, [EMAIL PROTECTED]
> <[EMAIL PROTECTED]>
> wrote:
> > I think that environment specifical things can be set in the
> > build.properties file. I am using one build.properties file for each
> > environment. For instance, for Windows I have one build.properties
> > in my home, for unix a slightly different one in my unix home. For
> > nightly build we have a different unix user, which has a special
> > build.properties file in home. If I work with several environment on
> > the same machine, I simply switch the build.properties file in my
> > home. I hope this helps.
> >
> > Greetings
> > Pierre
> >
> >
> >
> > -Original Message-
> > From: Ben Anderson [mailto:[EMAIL PROTECTED]
> > Sent: Freitag, 19. November 2004 15:52
> > To: Maven Users List
> > Subject: Re: do something before *.properties files load
> >
> > Yeah, you're probably right. We should just use maven's inheritance
> > to sort this stuff out. But this is still throwing me a little. I
> > want to be able to create artifacts for various environments w/out
> > changing any files, whether it's rena
Fwd: do something before *.properties files load
-- Forwarded message --
From: Ben Anderson <[EMAIL PROTECTED]>
Date: Fri, 19 Nov 2004 11:43:26 -0500
Subject: Re: do something before *.properties files load
To: "Poppe, Troy" <[EMAIL PROTECTED]>
Yes, same code essentially, except that one directory is a users
working directory and one is from the SCM repository.
On Fri, 19 Nov 2004 11:30:37 -0500, Poppe, Troy <[EMAIL PROTECTED]> wrote:
>
> So you deploy different code to different environments?
>
> T
>
>
>
> -Original Message-
> From: Ben Anderson [mailto:[EMAIL PROTECTED]
> Sent: Friday, November 19, 2004 11:29 AM
> To: Maven Users List
> Subject: Re: do something before *.properties files load
>
> Neither of those will work, because I want to dynamically change these:
>
> ${basepath}/src/java
> ${basepath}/src/test
> ...
> The properties file that specifices ${basepath} must be set before the
> maven.xml
> is parsed.
>
> On Fri, 19 Nov 2004 11:02:55 -0500, Poppe, Troy <[EMAIL PROTECTED]> wrote:
> >
> > I am coming to a similar problem as you, Ben. I can see two possible
> > solutions, I've yet to decide which fits our setup the best.
> >
> > The first solution is to use Ant's property replacement task. For
> > example, let's say your environment specific properties are in your
> > web.xml file. You'd create a generic web_template.xml file with all
> > the environment specific information written in the form of:
> > ${env.specific.property}. Then, you'll create a .properties file for
> > each of your environments, (dev.properties) which will contain your
> > environment specific properties for development. Then create a
> > preGoal for war:war (maybe something else), and use the ant properties
> > replacement task ( I believe) to get those values into the
> > newly generated web.xml. Then use this new web.xml will be used in
> > the newly generated war file. You'll have to create some switch that
> > can be used on the command line, or maybe even some project level
> > goals in your maven.xml files that will generate what you need (think
> > of something like "build-dev" to create in your top most maven.xml
> > file).
> >
> > Another solution would be to create a separate web.xml for each
> > environment, web_dev.xml for example. Then in your preGoal for
> > war:war, you could switch on a property specified on the command line,
> > and copy the selected xml file to web.xml. Then the newly generated
> > war file will contain the right web.xml.
> >
> > Personally, I like the first solution a bit better. In a way, it
> > makes you declare what the environment specific properties are, and
> > you must provide a value for them to work. It also allows you to
> > replace properties into different types of files, like source code.
> >
> > I've used this approach for some of my Xdoclet code. I'll set some
> > Xdoclet values to be like "${env.property}", let Xdoclet generate
> > other files, then run my properties file through, replacing what needs
> > to be replaced. It seems to work pretty well, I find that many of my
> > properties are really quite common, and as a result, I only have to
> > change the property in one place to affect a change in my whole build.
> >
> > Obviously, it makes yet another step to get from code to build, and
> > maybe it's a bit difficult to explain to another developer. But you
> > document your build process perfectly anyway, right? ;)
> >
> > Hope that helps.
> >
> > Troy
> >
> >
> >
> >
> > -Original Message-
> > From: Ben Anderson [mailto:[EMAIL PROTECTED]
> > Sent: Friday, November 19, 2004 10:44 AM
> > To: Maven Users List
> > Subject: Re: do something before *.properties files load
> >
> > yes, I understand that. But what if I don't want to swap
> > build.properties files for each environment? I want to the same user,
> > w/out making them manually change build.properties, to be able to
> > build for various environments from the same machine.
> >
> > On Fri, 19 Nov 2004 16:11:13 +0100, [EMAIL PROTECTED]
> > <[EMAIL PROTECTED]>
> > wrote:
> > > I think that environment specifical things can be set in the
> > > build.properties file. I am using one build.properties file for each
> > > environment. For instance, for Windows I have one build.properties
> > > in my home, for unix a slightly different one in my unix home. For
> > > nightly build we have a different unix use
RE: do something before *.properties files load
Would it be possible to use something like this in the POM:
./opt/${myenvironmenttype}/project.xml
So depending on the property you specify you can inherit from
./opt/dev/project.xml or ./opt/prod/project.xml, and their respective
*.properties. The dev and prod folder only contains maven files. The opt
folder should prevent the multiproject plug-in to go through these
folders.
Just an idea, let me know if this make sense.
> -Original Message-
> From: Ben Anderson [mailto:[EMAIL PROTECTED]
> Sent: Friday, November 19, 2004 11:44 AM
> To: Maven Users List
> Subject: Fwd: do something before *.properties files load
>
> -- Forwarded message --
> From: Ben Anderson <[EMAIL PROTECTED]>
> Date: Fri, 19 Nov 2004 11:43:26 -0500
> Subject: Re: do something before *.properties files load
> To: "Poppe, Troy" <[EMAIL PROTECTED]>
>
>
> Yes, same code essentially, except that one directory is a users
> working directory and one is from the SCM repository.
>
>
>
>
> On Fri, 19 Nov 2004 11:30:37 -0500, Poppe, Troy
<[EMAIL PROTECTED]>
> wrote:
> >
> > So you deploy different code to different environments?
> >
> > T
> >
> >
> >
> > -Original Message-----
> > From: Ben Anderson [mailto:[EMAIL PROTECTED]
> > Sent: Friday, November 19, 2004 11:29 AM
> > To: Maven Users List
> > Subject: Re: do something before *.properties files load
> >
> > Neither of those will work, because I want to dynamically change
these:
> >
> > ${basepath}/src/java
> >
${basepath}/src/test
> > ...
> > The properties file that specifices ${basepath} must be set before
the
> maven.xml
> > is parsed.
> >
> > On Fri, 19 Nov 2004 11:02:55 -0500, Poppe, Troy
<[EMAIL PROTECTED]>
> wrote:
> > >
> > > I am coming to a similar problem as you, Ben. I can see two
possible
> > > solutions, I've yet to decide which fits our setup the best.
> > >
> > > The first solution is to use Ant's property replacement task. For
> > > example, let's say your environment specific properties are in
your
> > > web.xml file. You'd create a generic web_template.xml file with
all
> > > the environment specific information written in the form of:
> > > ${env.specific.property}. Then, you'll create a .properties file
for
> > > each of your environments, (dev.properties) which will contain
your
> > > environment specific properties for development. Then create a
> > > preGoal for war:war (maybe something else), and use the ant
properties
> > > replacement task ( I believe) to get those values into
the
> > > newly generated web.xml. Then use this new web.xml will be used
in
> > > the newly generated war file. You'll have to create some switch
that
> > > can be used on the command line, or maybe even some project level
> > > goals in your maven.xml files that will generate what you need
(think
> > > of something like "build-dev" to create in your top most maven.xml
> > > file).
> > >
> > > Another solution would be to create a separate web.xml for each
> > > environment, web_dev.xml for example. Then in your preGoal for
> > > war:war, you could switch on a property specified on the command
line,
> > > and copy the selected xml file to web.xml. Then the newly
generated
> > > war file will contain the right web.xml.
> > >
> > > Personally, I like the first solution a bit better. In a way, it
> > > makes you declare what the environment specific properties are,
and
> > > you must provide a value for them to work. It also allows you to
> > > replace properties into different types of files, like source
code.
> > >
> > > I've used this approach for some of my Xdoclet code. I'll set
some
> > > Xdoclet values to be like "${env.property}", let Xdoclet generate
> > > other files, then run my properties file through, replacing what
needs
> > > to be replaced. It seems to work pretty well, I find that many of
my
> > > properties are really quite common, and as a result, I only have
to
> > > change the property in one place to affect a change in my whole
build.
> > >
> > > Obviously, it makes yet another step to get from code to build,
and
> > > maybe it's a bit difficult to explain to another developer. But
you
> > > document your build process perfectly anyway, right? ;)
> > >
> > > Hope that helps.
> > >
> > > Troy
> > >
> > >
RE: do something before *.properties files load
I think that we might have missed the primary issue here There are
two properties with the same name in the properties file. In regards to
the statement "Yes, you can expect that behavior to remain the same", I
suspect that this was in terms of one property being able to have an
expression of another property. I personally doubt that it was in
regard to the load behavior of the property file, in terms of whether
"qb.name" gets assigned the value of "Tommy Maddox" or of "Ben
Roethlisberger". In any case, "best.qb.ever" will be assigned the final
value of "qb.name".
-Original Message-
From: Brett Porter [mailto:[EMAIL PROTECTED]
Sent: Friday, November 19, 2004 8:26 AM
To: Maven Users List; Ben Anderson
Subject: Re: do something before *.properties files load
Hi Ben,
Yes, you can expect that behaviour to remain the same.
maven.src.dir is not what you think it is. You would need to modify
pom.build.sourceDirectory, but this is not recommended.
Why are you changing sources in different environments? Perhaps you want
s?
- Brett
On Fri, 19 Nov 2004 08:15:27 -0500, Ben Anderson
<[EMAIL PROTECTED]> wrote:
> Thanks Brett. I ran some tests specifying expressions in the
> project.properties file. It's pretty neat how the properties retain a
> reference of some kind instead of resolving at the initial assignment.
> For instance:
>
> qb.name=Tommy Maddox
> best.qb.ever=${qb.name}
> qb.name=Ben Roethlisberger
>
> now best.qb.ever is "Ben Roethlisberger". I see this works now - is
> this indended (I'm assuming is must be)? Am I safe in relying on
> maven to stay this way?
>
> One more general question. The reason I'm asking is because I'd like
> to do the following. Maybe this is way off base and there's a better
> way:
>
> command
> --
> maven -Denv=qa jar:jar
>
> maven.xml
>
>
>
>
>
> ...
>
> project.properties
> -
> maven.src.dir=${basepath}/src/java
>
> project.xml
> -
> ...
>
>
> this is bogus and will never be used
>
>
> Does this make sense? I think this is the best way to be able to flip
> things like maven.src.dir by specifying an environment on the command
> line.
>
> One more.. I can't find the property that equates to this tag
> . I checked here:
> http://maven.apache.org/reference/plugins/test/properties.html
> and here:
> http://maven.apache.org/reference/user-guide.html#Behavioural_Properti
> es
> am I just blind or is it not listed?
>
> Thanks,
> Ben
>
>
>
>
> On Fri, 19 Nov 2004 09:01:48 +1100, Brett Porter
> <[EMAIL PROTECTED]> wrote:
> > > 1) Can I embed jelly in my build.properties files?
> >
> > The answer to the question you were trying to ask is yes, but to
> > this specific one, no. Jelly is the XML scripting, JEXL is the
> > expression language used in Jelly. You can use an expression in
> > build.properties, but not embed Jelly - just in case you wanted to
> > start doing conditionals :)
> >
> > eg,
> > somedir=${basedir}/src
> > otherdir=${maven.build.dir}/other
> >
> > > 2) Is there a goal that occurs before maven loads the properties
> > > file. So I could write a ...
> > > ...
> > > some.arbitrary.property=qaValue
> > > ...
> > > some.arbitrary.property=prodValue
> >
> > No, but the first is nicer and works.
> >
> > - Brett
> >
> > >
> > > Thanks,
> > > Ben
> > >
> > > --
> > > ---
> > > 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]
This message and any attachments contain information, which may be confidential
or privileged. If you are not the intended recipient, please refrain from any
disclosure, copying, distribution or use of this information. Please be aware
that such actions are prohibited. If you have received this transmission in
error, kindly notify us by calling 1-800-262-4723 or e-mail to [EMAIL
PROTECTED] We appreciate your cooperation.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: do something before *.properties files load
that's a pretty slick solution. I'm going to use that.
On Fri, 19 Nov 2004 12:06:02 -0500, Jean-Marc Lavoie
<[EMAIL PROTECTED]> wrote:
> Would it be possible to use something like this in the POM:
>
> ./opt/${myenvironmenttype}/project.xml
>
> So depending on the property you specify you can inherit from
> ./opt/dev/project.xml or ./opt/prod/project.xml, and their respective
> *.properties. The dev and prod folder only contains maven files. The opt
> folder should prevent the multiproject plug-in to go through these
> folders.
>
> Just an idea, let me know if this make sense.
>
>
>
>
> > -Original Message-
> > From: Ben Anderson [mailto:[EMAIL PROTECTED]
> > Sent: Friday, November 19, 2004 11:44 AM
> > To: Maven Users List
> > Subject: Fwd: do something before *.properties files load
> >
> > -- Forwarded message --
> > From: Ben Anderson <[EMAIL PROTECTED]>
> > Date: Fri, 19 Nov 2004 11:43:26 -0500
> > Subject: Re: do something before *.properties files load
> > To: "Poppe, Troy" <[EMAIL PROTECTED]>
> >
> >
> > Yes, same code essentially, except that one directory is a users
> > working directory and one is from the SCM repository.
> >
> >
> >
> >
> > On Fri, 19 Nov 2004 11:30:37 -0500, Poppe, Troy
> <[EMAIL PROTECTED]>
> > wrote:
> > >
> > > So you deploy different code to different environments?
> > >
> > > T
> > >
> > >
> > >
> > > -Original Message-
> > > From: Ben Anderson [mailto:[EMAIL PROTECTED]
> > > Sent: Friday, November 19, 2004 11:29 AM
> > > To: Maven Users List
> > > Subject: Re: do something before *.properties files load
> > >
> > > Neither of those will work, because I want to dynamically change
> these:
> > >
> > > ${basepath}/src/java
> > >
> ${basepath}/src/test
> > > ...
> > > The properties file that specifices ${basepath} must be set before
> the
> > maven.xml
> > > is parsed.
> > >
> > > On Fri, 19 Nov 2004 11:02:55 -0500, Poppe, Troy
> <[EMAIL PROTECTED]>
> > wrote:
> > > >
> > > > I am coming to a similar problem as you, Ben. I can see two
> possible
> > > > solutions, I've yet to decide which fits our setup the best.
> > > >
> > > > The first solution is to use Ant's property replacement task. For
> > > > example, let's say your environment specific properties are in
> your
> > > > web.xml file. You'd create a generic web_template.xml file with
> all
> > > > the environment specific information written in the form of:
> > > > ${env.specific.property}. Then, you'll create a .properties file
> for
> > > > each of your environments, (dev.properties) which will contain
> your
> > > > environment specific properties for development. Then create a
> > > > preGoal for war:war (maybe something else), and use the ant
> properties
> > > > replacement task ( I believe) to get those values into
> the
> > > > newly generated web.xml. Then use this new web.xml will be used
> in
> > > > the newly generated war file. You'll have to create some switch
> that
> > > > can be used on the command line, or maybe even some project level
> > > > goals in your maven.xml files that will generate what you need
> (think
> > > > of something like "build-dev" to create in your top most maven.xml
> > > > file).
> > > >
> > > > Another solution would be to create a separate web.xml for each
> > > > environment, web_dev.xml for example. Then in your preGoal for
> > > > war:war, you could switch on a property specified on the command
> line,
> > > > and copy the selected xml file to web.xml. Then the newly
> generated
> > > > war file will contain the right web.xml.
> > > >
> > > > Personally, I like the first solution a bit better. In a way, it
> > > > makes you declare what the environment specific properties are,
> and
> > > > you must provide a value for them to work. It also allows you to
> > > > replace properties into different types of files, like source
> code.
> > > >
> > > > I've used this approach for some of my Xdoclet code. I'll set
> some
> > > > Xdoclet values to be like "${env.property}", let Xdoclet g
