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
pom properties after the fact [was: do something...]
Sorry about the chattiness today. I think I've finally nailed down my
actual question.
In the previous thread I commented on how I can change properties
after the fact that build on each other. For instance:
qb.name=Tommy Maddox
best.qb.ever=${qb.name}
qb.name=Ben Roethlisberger
now best.qb.ever is "Ben Roethlisberger"
however, I don't see this behavior for project.xml(pom) properties:
project.properties
--
best.qb.ever=Tommy Maddox
project.xml
-
${best.qb.ever}
maven.xml
pom.build.sourceDirectory: ${pom.build.sourceDirectory}
This outputs as:
...Tommy Maddox
Is there any way to get the above behavior to occur in the example
below? If not, I'll need to make the changes suggested in the
previous thread and I'll stop polluting this list ;-)
Thanks,
Ben
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
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
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
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
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/pr
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
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]
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: javac ... -source 1.3
I ran: $ maven -X plugin:install 1> plugin_install.txt 2>&1 and put it here: http://www.benanderson.us/bd/plugin_install.txt On Tue, 16 Nov 2004 06:41:38 +1100, Brett Porter <[EMAIL PROTECTED]> wrote: > Fixing the first will fix the second. Can you run the first with a -X option? > > On Mon, 15 Nov 2004 14:37:43 -0500, Ben Anderson > > > <[EMAIL PROTECTED]> wrote: > > There could be something screwy w/ my installation, b/c I installed > > 1.0.1, then uninstalled it, then re-installed 1.0. But anyways, heres > > what happened. > > > > w/ no dependencies specified. > > > > $ maven plugin:install > > __ __ > > | \/ |__ _Apache__ ___ > > | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ > > |_| |_\__,_|\_/\___|_||_| v. 1.0 > > > > java.lang.NoClassDefFoundError: org/jaxen/JaxenException > > at java.lang.Class.forName0(Native Method) > > at java.lang.Class.forName(Class.java:141) > > at > > org.apache.commons.jelly.tags.xml.XMLTagLibrary.class$(XMLTagLibrary.java:39) > > at > > org.apache.commons.jelly.tags.xml.XMLTagLibrary.(XMLTagLibrary.java:44) > > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > > Method) > > at > > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) > > at > > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) > > at java.lang.reflect.Constructor.newInstance(Constructor.java:274) > > at java.lang.Class.newInstance0(Class.java:308) > > at java.lang.Class.newInstance(Class.java:261) > > at > > org.apache.commons.jelly.JellyContext.getTagLibrary(JellyContext.java:454) > > at > > org.apache.maven.jelly.MavenJellyContext.getTagLibrary(MavenJellyContext.java:171) > > at > > org.apache.commons.jelly.JellyContext.getTagLibrary(JellyContext.java:437) > > at > > org.apache.maven.jelly.MavenJellyContext.getTagLibrary(MavenJellyContext.java:171) > > at > > org.apache.commons.jelly.parser.XMLParser.createTag(XMLParser.java:979) > > at > > org.apache.commons.jelly.parser.XMLParser.startElement(XMLParser.java:593) > > at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown > > Source) > > at > > org.apache.xerces.parsers.AbstractXMLDocumentParser.emptyElement(Unknown > > Source) > > at > > org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown > > Source) > > ... > > > > w/ jaxen: > > > > jaxen > > jaxen > > jaxen-1.0-FCS-full.jar > > > > > > $ maven plugin:install > > __ __ > > | \/ |__ _Apache__ ___ > > | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ > > |_| |_\__,_|\_/\___|_||_| v. 1.0 > > > > java.lang.NoClassDefFoundError: org/saxpath/SAXPathException > > at java.lang.ClassLoader.defineClass0(Native Method) > > at java.lang.ClassLoader.defineClass(ClassLoader.java:537) > > at > > java.security.SecureClassLoader.defineClass(SecureClassLoader.java:123) > > at java.net.URLClassLoader.defineClass(URLClassLoader.java:251) > > at java.net.URLClassLoader.access$100(URLClassLoader.java:55) > > at java.net.URLClassLoader$1.run(URLClassLoader.java:194) > > at java.security.AccessController.doPrivileged(Native Method) > > at java.net.URLClassLoader.findClass(URLClassLoader.java:187) > > at java.lang.ClassLoader.loadClass(ClassLoader.java:289) > > at java.lang.ClassLoader.loadClass(ClassLoader.java:235) > > at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302) > > at java.lang.Class.forName0(Native Method) > > at java.lang.Class.forName(Class.java:141) > > at > > org.apache.commons.jelly.tags.xml.XMLTagLibrary.class$(XMLTagLibrary.java:39) > > at > > org.apache.commons.jelly.tags.xml.XMLTagLibrary.(XMLTagLibrary.java:44) > > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > > Method) > > at > > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) > > at > > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) > > at java.lang.reflect.Constructor.newInstance(Constructor.java:274) > > at java
Re: javac ... -source 1.3
There could be something screwy w/ my installation, b/c I installed 1.0.1, then uninstalled it, then re-installed 1.0. But anyways, heres what happened. w/ no dependencies specified. $ maven plugin:install __ __ | \/ |__ _Apache__ ___ | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.0 java.lang.NoClassDefFoundError: org/jaxen/JaxenException at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:141) at org.apache.commons.jelly.tags.xml.XMLTagLibrary.class$(XMLTagLibrary.java:39) at org.apache.commons.jelly.tags.xml.XMLTagLibrary.(XMLTagLibrary.java:44) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:274) at java.lang.Class.newInstance0(Class.java:308) at java.lang.Class.newInstance(Class.java:261) at org.apache.commons.jelly.JellyContext.getTagLibrary(JellyContext.java:454) at org.apache.maven.jelly.MavenJellyContext.getTagLibrary(MavenJellyContext.java:171) at org.apache.commons.jelly.JellyContext.getTagLibrary(JellyContext.java:437) at org.apache.maven.jelly.MavenJellyContext.getTagLibrary(MavenJellyContext.java:171) at org.apache.commons.jelly.parser.XMLParser.createTag(XMLParser.java:979) at org.apache.commons.jelly.parser.XMLParser.startElement(XMLParser.java:593) at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source) at org.apache.xerces.parsers.AbstractXMLDocumentParser.emptyElement(Unknown Source) at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source) ... w/ jaxen: jaxen jaxen jaxen-1.0-FCS-full.jar $ maven plugin:install __ __ | \/ |__ _Apache__ ___ | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.0 java.lang.NoClassDefFoundError: org/saxpath/SAXPathException at java.lang.ClassLoader.defineClass0(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:537) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:123) at java.net.URLClassLoader.defineClass(URLClassLoader.java:251) at java.net.URLClassLoader.access$100(URLClassLoader.java:55) at java.net.URLClassLoader$1.run(URLClassLoader.java:194) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:187) at java.lang.ClassLoader.loadClass(ClassLoader.java:289) at java.lang.ClassLoader.loadClass(ClassLoader.java:235) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:141) at org.apache.commons.jelly.tags.xml.XMLTagLibrary.class$(XMLTagLibrary.java:39) at org.apache.commons.jelly.tags.xml.XMLTagLibrary.(XMLTagLibrary.java:44) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:274) at java.lang.Class.newInstance0(Class.java:308) w/ jaxen/dom4j: jaxen jaxen jaxen-1.0-FCS-full.jar dom4j dom4j 1.4 $ maven plugin:install __ __ | \/ |__ _Apache__ ___ | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.0 BUILD SUCCESSFUL Total time: 5 seconds Finished at: Mon Nov 15 14:25:12 EST 2004 On Tue, 16 Nov 2004 06:18:16 +1100, Brett Porter <[EMAIL PROTECTED]> wrote: > Ben, > > These dependencies don't sound right, what error were you getting beforehand? > > - Brett > > On Mon, 15 Nov 2004 10:08:28 -0500, Ben Anderson > > > <[EMAIL PROTECTED]> wrote: > > whoops, sent that to brett instead of the list... sorry. I also > > forgot to mention, that before I did the plugin:install under > > maven-plugins/java, I had to add jaxen and dom4j as dependencies. > > > > On Mon, 15 Nov 2004 10:01:00 -0500, Ben Anderson > > > > > > <[EMAIL PROTECTED]> wrote: > > > ah - plugin.properties - that makes sense. Well, I'm learning about > > > plugins... I checked out maven-plugins from cvs and did a > > > plugin:install. That didn't work, but when I deleted the old
Re: javac ... -source 1.3
whoops, sent that to brett instead of the list... sorry. I also
forgot to mention, that before I did the plugin:install under
maven-plugins/java, I had to add jaxen and dom4j as dependencies.
On Mon, 15 Nov 2004 10:01:00 -0500, Ben Anderson
<[EMAIL PROTECTED]> wrote:
> ah - plugin.properties - that makes sense. Well, I'm learning about
> plugins... I checked out maven-plugins from cvs and did a
> plugin:install. That didn't work, but when I deleted the old jar from
> ${MAVEN_HOME}/plugins and copied in the new one, then it worked fine.
> Thanks,
> Ben
>
>
>
>
> On Sat, 13 Nov 2004 08:22:24 +1100, Brett Porter <[EMAIL PROTECTED]> wrote:
> > You'll find it defined in plugin.properties which would also have worked.
> >
> > When the next java plugin is released, this has been fixed so you can
> > upgrade without fear of overwriting your change.
> >
> > (IF you'd like to check it out from CVS and run maven plugin:install
> > to verify - feel free)
> >
> > Cheers,
> > Brett
> >
> > On Fri, 12 Nov 2004 12:16:47 -0500, Ben Anderson
> >
> >
> > <[EMAIL PROTECTED]> wrote:
> > > I got it working again. I edited the plugin.jelly and commented out
> > > the following lines:
> > >
> > >
> > > I understand this is needed if you wish to change the -source, but I
> > > don't. I'm not setting maven.compile.source anywhere, so I would
> > > expect is to be null, but for some reason it always got set to 1.3...
> > > who knows? Also, I first worked on $HOME/.maven/plugins or
> > > $HOME/.maven/cache, but these did nothing. What worked was when I
> > > edited the plugin.jelly in $MAVEN_HOME/plugins/maven-javajar
> > > What's the necessity for these various version?
> > >
> > > Bottom line - I got my problem fixed and I'm happy.
> > >
> > > Thanks,
> > > Ben
> > >
> > > On Fri, 12 Nov 2004 07:40:39 -0500, Ben Anderson
> > >
> > >
> > > <[EMAIL PROTECTED]> wrote:
> > > > Thanks for the tip Brett, but it still adds -source as an argument:
> > > > $maven -X java:compile
> > > > ...
> > > > '-sourcepath'
> > > > 'D:\VSS3\MedAmerica_Working\src\java'
> > > > '-target'
> > > > '1.1'
> > > > '-g'
> > > > '-source'
> > > > ''
> > > > ...
> > > >
> > > > looks like I've got the maven-java-plugin1.4
> > > >
> > > > $ maven --info | grep java
> > > > Which.version=Which.java:($Revision: 1.2 $) WhichJar.java:($Revision:
> > > > 1.2 $)
> > > > java.version=1.4.2_04
> > > > java.ext.dirs=c:\j2sdk1.4.2_04\jre\lib\ext
> > > > java.class.path=c:\Program Files\Apache Software Foundation\Maven
> > > > 1.0/lib/forehead-1.0-beta-5.jar
> > > > java.vendor=Sun Microsystems Inc.
> > > > java.runtime.name=Java(TM) 2 Runtime Environment, Standard Edition
> > > > maven-java-plugin-1.4
> > > > maven-javacc-plugin-1.1
> > > > maven-javadoc-plugin-1.6.1
> > > >
> > > > Thanks,
> > > > Ben
> > > >
> > > >
> > > >
> > > >
> > > > On Fri, 12 Nov 2004 09:26:58 +1100, Brett Porter <[EMAIL PROTECTED]>
> > > > wrote:
> > > > > Sorry, my mistake. I was referring to a change made after the last
> > > > > release, which was included with Maven 1.0.1.
> > > > >
> > > > > You will need to set:
> > > > > maven.compile.source=
> > > > >
> > > > > This should be added as an FAQ.
> > > > >
> > > > > Cheers,
> > > > > Brett
> > > > >
> > > > > On Fri, 12 Nov 2004 09:24:37 +1100, Brett Porter <[EMAIL PROTECTED]>
> > > > > wrote:
> > > > > > That's stange, because the plugin no longer has .source or .target
> > > > > > set
> > > > > > by default.
> > > > > >
> > > > > > Can you please run maven --info to find the java plugin version you
> > > > > > are using (there should only be one hopefully!), and check your
> > > > > > ~/build.properties and any other properties files in the project for
> > > > > > specification of maven.comp
Re: javac ... -source 1.3
I got it working again. I edited the plugin.jelly and commented out the following lines: I understand this is needed if you wish to change the -source, but I don't. I'm not setting maven.compile.source anywhere, so I would expect is to be null, but for some reason it always got set to 1.3... who knows? Also, I first worked on $HOME/.maven/plugins or $HOME/.maven/cache, but these did nothing. What worked was when I edited the plugin.jelly in $MAVEN_HOME/plugins/maven-javajar What's the necessity for these various version? Bottom line - I got my problem fixed and I'm happy. Thanks, Ben On Fri, 12 Nov 2004 07:40:39 -0500, Ben Anderson <[EMAIL PROTECTED]> wrote: > Thanks for the tip Brett, but it still adds -source as an argument: > $maven -X java:compile > ... > '-sourcepath' > 'D:\VSS3\MedAmerica_Working\src\java' > '-target' > '1.1' > '-g' > '-source' > '' > ... > > looks like I've got the maven-java-plugin1.4 > > $ maven --info | grep java > Which.version=Which.java:($Revision: 1.2 $) WhichJar.java:($Revision: 1.2 $) > java.version=1.4.2_04 > java.ext.dirs=c:\j2sdk1.4.2_04\jre\lib\ext > java.class.path=c:\Program Files\Apache Software Foundation\Maven > 1.0/lib/forehead-1.0-beta-5.jar > java.vendor=Sun Microsystems Inc. > java.runtime.name=Java(TM) 2 Runtime Environment, Standard Edition > maven-java-plugin-1.4 > maven-javacc-plugin-1.1 > maven-javadoc-plugin-1.6.1 > > Thanks, > Ben > > > > > On Fri, 12 Nov 2004 09:26:58 +1100, Brett Porter <[EMAIL PROTECTED]> wrote: > > Sorry, my mistake. I was referring to a change made after the last > > release, which was included with Maven 1.0.1. > > > > You will need to set: > > maven.compile.source= > > > > This should be added as an FAQ. > > > > Cheers, > > Brett > > > > On Fri, 12 Nov 2004 09:24:37 +1100, Brett Porter <[EMAIL PROTECTED]> wrote: > > > That's stange, because the plugin no longer has .source or .target set > > > by default. > > > > > > Can you please run maven --info to find the java plugin version you > > > are using (there should only be one hopefully!), and check your > > > ~/build.properties and any other properties files in the project for > > > specification of maven.compile.source > > > > > > Thanks, > > > Brett > > > > > > > > > > > > > > > > > > > On Thu, 11 Nov 2004 21:49:19 +0100, Arnaud HERITIER <[EMAIL PROTECTED]> > > > wrote: > > > > You must look at the plugin java : > > > > http://maven.apache.org/reference/plugins/java/ > > > > > > > > Arnaud > > > > > > > > > -Message d'origine- > > > > > De : Ben Anderson [mailto:[EMAIL PROTECTED] > > > > > Envoyé : jeudi 11 novembre 2004 21:13 > > > > > À : Maven Users List > > > > > Objet : javac ... -source 1.3 > > > > > > > > > > > > > > > > > > Hi, > > > > > I upgraded to maven1.0.1, but now my build is broken. The problem is > > > > > we're using the javac bundled with websphere3.5.7. This javac does > > > > > not have a -source option which maven is adding. I tried uninstalling > > > > > 1.0.1 and reinstalling 1.0, but this didn't help. I also grepped > > > > > through the plugins directories to find where ant:javac is defined, > > > > > but I don't see it. Does anyone know how to either stop the javac > > > > > command from using the -source option, or restore my existing 1.0 > > > > > installation more completely? > > > > > 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: escapeText
thanks, Brett - that worked! I thought it wasn't at first because I was echoing to the screen using , but as it turns out this tag escapes xml as well. But the escapeText and encode tags are working in j:set. On Fri, 12 Nov 2004 09:45:31 +1100, Brett Porter <[EMAIL PROTECTED]> wrote: > We have upgraded Jelly on CVS HEAD and it seems to be working, so you > should be able to drop this all into Maven's lib directly. > > - Brett > > On Thu, 11 Nov 2004 09:26:03 -0500, Ben Anderson > > > <[EMAIL PROTECTED]> wrote: > > Is there anyway I can "insert" the latest version of jelly into maven > > manually? Isn't this the type of dependency version lagging maven set > > out to resolve? I'm really not trying to be an antagonist at all, I > > would just like to use all of Jelly's features. > > Thanks, > > Ben > > > > On Wed, 10 Nov 2004 15:50:11 -0500, Ben Anderson > > > > > > <[EMAIL PROTECTED]> wrote: > > > Hi, > > > How do I set a variable with xml in it and then spit it back out? > > > > > > > > > > > > > > > > > > This escapes the xml, which I dont' want: > > > <category name... > > > > > > Looking at jelly's documentation, I should be able to do this: > > > > > > > > > but I get this output: > > > This tag does not understand the 'escapeText' attribute > > > > > > This seems like a case where maven isn't using the latest jelly again? > > > Does anyone know if there are any workarounds I can use for the > > > current version of maven. > > > > > > 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: javac ... -source 1.3
Thanks for the tip Brett, but it still adds -source as an argument: $maven -X java:compile ... '-sourcepath' 'D:\VSS3\MedAmerica_Working\src\java' '-target' '1.1' '-g' '-source' '' ... looks like I've got the maven-java-plugin1.4 $ maven --info | grep java Which.version=Which.java:($Revision: 1.2 $) WhichJar.java:($Revision: 1.2 $) java.version=1.4.2_04 java.ext.dirs=c:\j2sdk1.4.2_04\jre\lib\ext java.class.path=c:\Program Files\Apache Software Foundation\Maven 1.0/lib/forehead-1.0-beta-5.jar java.vendor=Sun Microsystems Inc. java.runtime.name=Java(TM) 2 Runtime Environment, Standard Edition maven-java-plugin-1.4 maven-javacc-plugin-1.1 maven-javadoc-plugin-1.6.1 Thanks, Ben On Fri, 12 Nov 2004 09:26:58 +1100, Brett Porter <[EMAIL PROTECTED]> wrote: > Sorry, my mistake. I was referring to a change made after the last > release, which was included with Maven 1.0.1. > > You will need to set: > maven.compile.source= > > This should be added as an FAQ. > > Cheers, > Brett > > On Fri, 12 Nov 2004 09:24:37 +1100, Brett Porter <[EMAIL PROTECTED]> wrote: > > That's stange, because the plugin no longer has .source or .target set > > by default. > > > > Can you please run maven --info to find the java plugin version you > > are using (there should only be one hopefully!), and check your > > ~/build.properties and any other properties files in the project for > > specification of maven.compile.source > > > > Thanks, > > Brett > > > > > > > > > > > > On Thu, 11 Nov 2004 21:49:19 +0100, Arnaud HERITIER <[EMAIL PROTECTED]> > > wrote: > > > You must look at the plugin java : > > > http://maven.apache.org/reference/plugins/java/ > > > > > > Arnaud > > > > > > > -Message d'origine- > > > > De : Ben Anderson [mailto:[EMAIL PROTECTED] > > > > Envoyé : jeudi 11 novembre 2004 21:13 > > > > À : Maven Users List > > > > Objet : javac ... -source 1.3 > > > > > > > > > > > > > > Hi, > > > > I upgraded to maven1.0.1, but now my build is broken. The problem is > > > > we're using the javac bundled with websphere3.5.7. This javac does > > > > not have a -source option which maven is adding. I tried uninstalling > > > > 1.0.1 and reinstalling 1.0, but this didn't help. I also grepped > > > > through the plugins directories to find where ant:javac is defined, > > > > but I don't see it. Does anyone know how to either stop the javac > > > > command from using the -source option, or restore my existing 1.0 > > > > installation more completely? > > > > 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]
javac ... -source 1.3
Hi, I upgraded to maven1.0.1, but now my build is broken. The problem is we're using the javac bundled with websphere3.5.7. This javac does not have a -source option which maven is adding. I tried uninstalling 1.0.1 and reinstalling 1.0, but this didn't help. I also grepped through the plugins directories to find where ant:javac is defined, but I don't see it. Does anyone know how to either stop the javac command from using the -source option, or restore my existing 1.0 installation more completely? Thanks, Ben - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: escapeText
Is there anyway I can "insert" the latest version of jelly into maven manually? Isn't this the type of dependency version lagging maven set out to resolve? I'm really not trying to be an antagonist at all, I would just like to use all of Jelly's features. Thanks, Ben On Wed, 10 Nov 2004 15:50:11 -0500, Ben Anderson <[EMAIL PROTECTED]> wrote: > Hi, > How do I set a variable with xml in it and then spit it back out? > > > > > > This escapes the xml, which I dont' want: > <category name... > > Looking at jelly's documentation, I should be able to do this: > > > but I get this output: > This tag does not understand the 'escapeText' attribute > > This seems like a case where maven isn't using the latest jelly again? > Does anyone know if there are any workarounds I can use for the > current version of maven. > > Thanks, > Ben > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
escapeText
Hi, How do I set a variable with xml in it and then spit it back out? This escapes the xml, which I dont' want: <category name... Looking at jelly's documentation, I should be able to do this: but I get this output: This tag does not understand the 'escapeText' attribute This seems like a case where maven isn't using the latest jelly again? Does anyone know if there are any workarounds I can use for the current version of maven. Thanks, Ben - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
root ${basedir}
Is there a property for specifying the ${basedir} of the highest level
of my pom inheritnace tree?
Thanks,
Ben
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven test:test
That did it - I didn't have defined - I was
just going off of this:
http://maven.apache.org/reference/user-guide.html#POM_Inheritance
Once again I will say that it'd be pretty much impossible to use maven
w/out being on this list or else delving into the code for every
little thing as the documentation is so poor. But I'm not complaining
because this list has been very good to me :-)
Thanks,
Ben
On Wed, 3 Nov 2004 05:30:09 -0700, Charles Daniels <[EMAIL PROTECTED]> wrote:
> Try adding these within :
>
> ${maven.src.dir}
> ${maven.src.dir}
>
> Notice that /com is not specified.
>
>
>
> > -Original Message-
> > From: Ben Anderson [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, November 03, 2004 5:24 AM
> > To: [EMAIL PROTECTED]
> > Subject: maven test:test
> >
> > Hi,
> > I have this in my project.xml
> >
> > ${maven.src.dir}/com
> >
> >
> > ${maven.src.dir}
> >
> > *.xml
> > *.dtd
> >
> >
> >
> >
> >
> > ${maven.src.dir}/**/*Test*.java
> >
> >
> > ${maven.src.dir}/**/TestAll.java
> > ${maven.src.dir}/**/*Abstract*.java
> >
> >
> >
> >
> > my maven.src.dir I define elsewhere, but that's beside the point. I
> > have a Test file right along side the rest of my src code. When I do
> > java:compile, it gets compiled. But when I do test:test I get "no
> > tests to run". I tried taking out the ${maven.src.dir} inside the
> > tags, but that didn't help. Any ideas what I'm doing
> > wrong?
> > 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]
maven test:test
Hi,
I have this in my project.xml
${maven.src.dir}/com
${maven.src.dir}
*.xml
*.dtd
${maven.src.dir}/**/*Test*.java
${maven.src.dir}/**/TestAll.java
${maven.src.dir}/**/*Abstract*.java
my maven.src.dir I define elsewhere, but that's beside the point. I
have a Test file right along side the rest of my src code. When I do
java:compile, it gets compiled. But when I do test:test I get "no
tests to run". I tried taking out the ${maven.src.dir} inside the
tags, but that didn't help. Any ideas what I'm doing
wrong?
Thanks,
Ben
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
${maven.goal} ??
Is there a property for the goal the user entered? I want to make a pregoal on, say, java:compile that echos what the user entered as their goal. This would produce: $maven jar:jar ... your desired goal: jar:jar $maven java:compile ... your desired goal: java:compile Thanks, Ben - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
users@maven.apache.org
Anyone know what I'm doing wrong here:
${envs.add('.qa')}
${envs.add('.Nqa')}
${envs.add('.prod')}
...
I assumed running this would output nothing, but on the contrary, it does:
$ maven -Denv=qa prop
__ __
| \/ |__ _Apache__ ___
| |\/| / _` \ V / -_) ' \ ~ intelligent projects ~
|_| |_\__,_|\_/\___|_||_| v. 1.0
build:start:
prop:
true
true
true
BUILD SUCCESSFUL
Total time: 2 seconds
Finished at: Mon Nov 01 14:57:29 EST 2004
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: dynamic property access
Thanks Alex - that works! However, I've realized I don't really need to do
this. If anyone cares, here's my resolution that lets me add tokens to
property files dynamically w/out requiring a change in my maven.xml. Nothing
special here - I just think it's pretty neat.
.${env}
${prop.key.substring(0, prop.key.indexOf(envDir))}
environment.properties
--
server.name.qa=myQABox
server.name.prod=myProdBox
server.port=80
Some properties file to be filtered
---
[EMAIL PROTECTED]@
[EMAIL PROTECTED]
now I can run:
maven -Denv=qa|prod someGoal
-Ben
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: dynamic property access
yes, that's a solution for the example I gave, but not what I'm looking for.
Let me give the real example:
config.properties
-
servername.qa=qaServer
servername.prod=prodServer
maven.xml
-
actually, this is probably a bit much. Is there a way to solve the original
example w/out modifying the tags?
Thanks,
Ben
Quoting Eric Giguere <[EMAIL PROTECTED]>:
> Hello Ben
> Yep, try this:
>
>
>
>
> ${colorKey}
>
>
>
> Hope it helps
> Eric.
>
> Ben Anderson wrote:
>
> >Hi,
> >I want to dynamically set which property I access. Is this possible?
> >Obviously the below code won't work, but you get the idea. I thought
> >maybe that the tag might help, but it doesn't seem to do
> >anything.
> >
> >
> >
> >
> >${${colorKey}}
> >
> >
> >Any ideas?
> >
> >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]
dynamic property access
Hi,
I want to dynamically set which property I access. Is this possible?
Obviously the below code won't work, but you get the idea. I thought
maybe that the tag might help, but it doesn't seem to do
anything.
${${colorKey}}
Any ideas?
Thanks,
Ben
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Build setup for multiple "small projects" that are related
> Thanks for the quick reply.
To jog your memory - I was in one of your D.O. Tech classes a couple years back
when I was with Paychex. Just paying my respects to the teacher ;-) You also
introduced me to gvim, for which I am ever grateful.
> 1. Each "sub project" has its own artifacts (jar files). Would i just
> put them down in the lower project.xml files?
not too sure what you're asking here... Are you asking where the jar will be
placed after it is built? If so, you can specify that in the maven.build.dir
property. However, you probably want to leave this as the default
(${basedir}/target). Should you need to use this jar as a dependency in
another project, you'll want to do jar:install. The subproject's project.xml
will be where you specify information specific to that jar, such as the make up
of the jar, the name of the jar, etc.
> 2. When I want to build, for example, the web-services piece, where
> would I do the maven command, and what goal would that be?
from the web-services directory (where your subproject's project.xml is)
maven jar:jar
maven is all about plugins. On maven's home page, click on references->plugins.
> 3. It seems like if I don't use the built in structure, the built in
> goals don't work very well as they "assume" one source directory.
bingo. Maven can be rather intrusive as far as directory structures, jar
contents, etc. This is one of the reasons so many ant supporters are unwilling
to adopt maven. However, like anything else, in order to enforce reuse,
standards must be made and enforced.
Something else it seems you've been hinting at is the reactor. Using it, you
can recursively call subproject goals from a higher directory. You would
create a custom goal which you write in jelly and various tag libraries. The
reactor is invoked from the jelly:maven taglib. You can find this by clicking
"references->maven jelly tags" from maven's home page.
-Ben
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Build setup for multiple "small projects" that are related
Irv,
It doesn't sound like your directory structures need to change. I would suggest
keeping the same one you have, then you can use maven's inheritance:
src
project.xml
common
project.xml
java
xml
conf
web-services
project.xml
java
xml
conf
xml-util
project.xml
java
xml
conf
In your top level project.xml you can define your common structure:
...
java
xml
*.xml
conf
*.properties
...
then in your subdirectories
../project.xml
...
> Also, in the web-services and xml-util projects, would I then list the
> common project as a dependency?
If you're creating a war or ear, or some other aggregate artifact, then you will
need to specify the artifacts you want to include. For instance:
dotech
common
1.0
true
If, however, you are building a component jar, then you only need to specify the
dependency if it needs to be in your classpath during compile time. So, it
seems like you will in your case. Note: Make sure that you "install" the
dependency in your local repo ("maven jar:install") before you try to access
it.
> So, I'd have build/web-services where the common source would be built
> with the web-services src. (With nested tags under javac)
I think the thing you want to focus on is what artifacts you wish to create.
Maven has had some controversy about whether to allow multiple source
directories in the same project. The general understanding is that you should
not do this, but you can if you want:
http://maven.apache.org/faq.html#multiple-source-directories
In most cases in makes more sense to keep the jars separate. So, your
web-services and xml-util jars would not contain the class files that are in
the common jar.
HTH,
Ben
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[RES} Re: running the project out of maven.xml
what do you know - that worked! Thanks Craig!
Craig S. Cottingham wrote:
On Oct 20, 2004, at 13:24, Ben Anderson wrote:
I'd like to take advantage of the classpath which maven uses to run
my project. I've tried to solutions:
[ ... ]
2.
classpath="${basedir}/target/classes"
classpathref="maven.dependency.classpath"/>
This makes a little more sense, but for some reason I'm getting this
output:
[java] [ERROR] java.lang.NoClassDefFoundError: org/w3c/dom/Document
Oh so close. Try adding 'fork="true"' to the ant:java tag.
It's possible to make a goal that's pretty flexible. For instance,
here's what I use:
This requires defining "classname" on the command line, like:
maven -Dclassname=net.cottingham.Test run
--
Craig S. Cottingham
[EMAIL PROTECTED]
OpenPGP key available from:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x7977F79C
-
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]
running the project out of maven.xml
Hi,
I'd like to take advantage of the classpath which maven uses to run my
project. I've tried to solutions:
1.
${us.benanderson.rpc.Assignment3.main(null)}
This gives no output (good or bad)
2.
This makes a little more sense, but for some reason I'm getting this output:
[java] [ERROR] java.lang.NoClassDefFoundError: org/w3c/dom/Document
This is baffling me because I have this dependency specified:
xml-apis
xmlParserAPIs
2.0.2
I'm looking at this jar and it definitely contains
org.w3c.dom.Document. I know it's using maven.dependency.classpath,
because it'll give me different errors depending on what dependencies I
specifiy.
I'll list all my files, if someone ambitous wants to glance over them.
Thanks,
Ben
project.xml
---
3
ass3
ass3
ass3
1.0
jaxrpc
jaxrpc
jaxrpc.jar
axis
axis
1.1
dom4j
dom4j
1.4
xerces
xerces
2.4.0
xerces
xercesImpl
2.6.2
jaxp
jaxp
1.2
sax
sax
2.0.1
xml-apis
xml-apis
2.0.2
xml-apis
xmlParserAPIs
2.0.2
commons-logging
commons-logging
1.0
commons-discovery
commons-discovery
0.2
xalan
xalan
2.5.1
src
maven.xml
---
${us.benanderson.rpc.Assignment3.main2()}
project.properties
--
maven.repo.remote=http://www.ibiblio.com/maven,
http://www.bluesunrise.com/maven, http://mevenide.codehaus.org/repository
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
users@maven.apache.org
Hi, I'm trying to use the
reactor default goals?
Hi, In my subprojects I've set the default goal in both project.xml and maven.xml but this doesn't call any goals. The reactor works, but the subprojects don't "do" anything. Any ideas? Thanks, Ben Anderson - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
maven.xml inheritance
Hi, I'm trying to use inheritance with my project. The problem is that I only want the project.xml to be inherited, but the behaviors in maven.xml are also being inherited. Is there a way to turn this off? I'm honestly not seeing all the benefits of using inheritance. Is it all that it's cracked up to be? Thanks, Ben - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
maven -u [undocumented goals]
Hi all, Hopefully this is an easy question - I just can't find the answer anywhere. When I do: maven -u I get: Undocumented goals : [list of all my goals] This leads me to believe that there's a way to document my custom goals. Is this true? I need other developers to be able to understand how the goals should be used. Or should I just create another custom goal that spits out this info? Thanks, Ben - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
maven -u [undocumented goals]
Hi all, Hopefully this is an easy question - I just can't find the answer anywhere. When I do: maven -u I get: Undocumented goals : [list of all my goals] This leads me to believe that there's a way to document my custom goals. Is this true? I need other developers to be able to understand how the goals should be used. Or should I just create another custom goal that spits out this info? Thanks, Ben - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
ant:xmlvalidate
anyone know how to use this optional ant task in maven? Is there some standard way to enable ant optionals? From what I've seen, you just need to add the optional jar, but I don't think this tag needs any additional jars. Thanks, Ben - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven and FTP Ant task: what's up??
see this thread: http://marc.theaimsgroup.com/?l=turbine-maven-user&m=109570387625634&w=2 Note: you will have to manually download NetComponents.jar - which is hard to find. I can't remember where I got it from. Don't ask me why you need this jar as opposed to the current version of that project (commons-net). I had this problem a few weeks ago... and got pretty frustrated when I couldn't find the answer and almost abandoned maven. While this does seem to be a problem, it is solvable and maven is worth it ;-) -Ben Quoting [EMAIL PROTECTED]: > > > > > Hi all, > > I try to use the FTP Ant task in my maven.xml, but I can't make it work. > I've searched the mail archive, and I figured out that lots of people had > troubles with this task in Maven 1.0, but none found a solution regarding > this problem (at least, none gave a solution on the mailing list - a guy > just gave a hack and I couldn't even make it work). > > So if someone has a solution that works, that would be really kind of him > to send it to the list :o) > Otherwise, shouldn't this problem be addressed quickly? (it seems that the > FTP task used to work in Maven previous builds) > > Regards, > Fabrice. > > > - > 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: property from .properties vs
I'm thinking this is the desired behavior. First of all, I think it's wrong to
use the dot notation for the "var" attribute of will create a variable of that same type
(ConstantExpression). While ${my.property} creates a new
variable of type String. So, my conclusion is that (correct me if I'm wrong)
in order to use a property variable in an expression like
you must first create a variable of
type String:
${my.property}
-Ben
Quoting Ben Anderson <[EMAIL PROTECTED]>:
> Hi,
> I've noticed that there is a distinct difference with properties declared in
> a
> .properties file vs. properties set using the
> desired behavior or a bug. For instance:
>
> build.properties
>
> my.property=myValue
>
> maven.xml
> -
> ${my.property}
>
> true
>
>
> outputs:
> [echo] myValue
>
> notice that "[echo] true" is not output.
>
> now if I do this:
> maven.xml
> -
>
> ${my.property}
>
> true
>
>
> outputs:
> [echo] myValue
> [echo] true
>
> Why this difference? Am I doing something wrong? Any thoughts?
> 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]
property from .properties vs
Hi,
I've noticed that there is a distinct difference with properties declared in a
.properties file vs. properties set using ${my.property}
true
outputs:
[echo] myValue
notice that "[echo] true" is not output.
now if I do this:
maven.xml
-
${my.property}
true
outputs:
[echo] myValue
[echo] true
Why this difference? Am I doing something wrong? Any thoughts?
Thanks,
Ben
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: How do I test a schema
Thanks for the update C. I guess I'll go with that solution as well.
Quoting "Helck, Christopher" <[EMAIL PROTECTED]>:
> I decided to go with a Junit solution. I first tried XMLUnit (which I've
> used in the past to diff xml's -- worked like a charm), but gave up
> because it doesn't seem to support schemas and I was getting weird
> errors. Since I'm using Java 1.5 I used the javax.xml packages.
>
> I would prefer a maven based solution, but this does the trick for now.
> Here's sample code.
>
> %<--
>
> package com.foobar;
>
> import java.io.File;
>
> import javax.xml.XMLConstants;
> import javax.xml.transform.Source;
> import javax.xml.transform.stream.StreamSource;
> import javax.xml.validation.Schema;
> import javax.xml.validation.SchemaFactory;
> import javax.xml.validation.Validator;
>
> import junit.framework.Assert;
> import junit.framework.Test;
> import junit.framework.TestCase;
> import junit.framework.TestSuite;
>
> public class SchemaTest extends AbstractTestCase {
>
> public SchemaTest(String name) throws Exception {
> super(name);
> }
>
> public void testErrors() throws Exception {
> validate("xdocs/Foo.xsd", "/conf/ComplexTest.xml");
> }
>
> public void testSimple() throws Exception {
> validate("xdocs/Foo.xsd", "/conf/Simple.xml");
> }
>
> private void validate(String schemaFileName, String xmlFileName)
> throws Exception {
> Source xmlSource = new
> StreamSource(this.getClass().getResourceAsStream(xmlFileName));
>
> SchemaFactory factory =
> SchemaFactory.newInstance(XMLConstants.W3C_XML_SCHEMA_NS_URI);
> Schema schema = factory.newSchema(new
> File(getTestFile(schemaFileName)));
> Validator validator = schema.newValidator();
> validator.validate(xmlSource);
> }
>
> public static Test suite() {
> return new TestSuite(SchemaTest.class);
> }
>
> }
>
> %<-
>
> Regards,
> C. Helck
>
> -Original Message-
> From: Ben Anderson [mailto:[EMAIL PROTECTED]
> Sent: Thursday, September 23, 2004 7:29 AM
> To: Maven Users List
> Subject: Re: How do I test a schema
>
>
> That's funny - I was trying to do this yesterday, but gave up. You'll
> need the validate plugin jar here:
> http://jakarta.apache.org/commons/jelly/libs/validate/index.html
> I'm not sure where you're supposed to stick these jars. I put it in
> $MAVEN_HOME/lib and that worked, but it's probably supposed to go
> somewhere else. There's also some documentation there, but no examples.
> Here's what I had thus far:
>
>
>
>
>
> of course this doesn't work. Maybe together we can figure it out. -Ben
>
> Quoting "Helck, Christopher" <[EMAIL PROTECTED]>:
>
> > I'd like to automate testing a XML schema under maven, but I don't
> > have a clue how to begin :-). I have a schema and some example XML
> > files. I'd like to validate the files against the schema. Any help is
> > appreciated.
> >
> > Thanks,
> > C. Helck
> >
> >
> >
> >
> > The information contained in this e-mail is confidential. This e-mail
> > is intended only for the stated addressee. If you are not an
> > addressee, you must not disclose, copy, circulate or in any other way
> > use or rely on the information contained in this e-mail. if you have
> > received this e-mail in error, please inform us immediately and delete
>
> > it and all copies from your system.
> >
> > EBS Dealing Resources International Limited. Registered address:
> > 55-56 Lincoln's Inn Fields, London WC2A 3LJ, United Kingdom.
> > Registered number 2633663.
> >
> > EBS Dealing Resources, Inc, registered in Delaware. Address: 535
> > Madison Avenue, 24th Floor, New York, NY 10022, USA, and One upper
> > Pond road, Building F - Floor 3, Parsippany, NJ 07054, USA.
> >
> > EBS Dealing Resources Japan Limited, a Japanese Corporation. Address:
> > Asteer Kayabacho Bldg, 6th Floor, 1-6-1, Shinkawa, Chuo-Ku, Tokyo
> > 104-0033, Japan.
> >
> >
>
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
> The information contained in this e-mail is confidential. This e-mail is
> intended only for the stated addresse
Re: How do I test a schema
That's funny - I was trying to do this yesterday, but gave up. You'll need the validate plugin jar here: http://jakarta.apache.org/commons/jelly/libs/validate/index.html I'm not sure where you're supposed to stick these jars. I put it in $MAVEN_HOME/lib and that worked, but it's probably supposed to go somewhere else. There's also some documentation there, but no examples. Here's what I had thus far: of course this doesn't work. Maybe together we can figure it out. -Ben Quoting "Helck, Christopher" <[EMAIL PROTECTED]>: > I'd like to automate testing a XML schema under maven, but I don't have > a clue how to begin :-). I have a schema and some example XML files. I'd > like to validate the files against the schema. Any help is appreciated. > > Thanks, > C. Helck > > > > > The information contained in this e-mail is confidential. This e-mail is > intended only for the stated addressee. If you are not an addressee, you > must not disclose, copy, circulate or in any other way use or rely on the > information contained in this e-mail. if you have received this e-mail in > error, please inform us immediately and delete it and all copies from your > system. > > EBS Dealing Resources International Limited. Registered address: 55-56 > Lincoln's Inn Fields, London WC2A 3LJ, United Kingdom. Registered number > 2633663. > > EBS Dealing Resources, Inc, registered in Delaware. Address: 535 Madison > Avenue, 24th Floor, New York, NY 10022, USA, and One upper Pond road, > Building F - Floor 3, Parsippany, NJ 07054, USA. > > EBS Dealing Resources Japan Limited, a Japanese Corporation. Address: Asteer > Kayabacho Bldg, 6th Floor, 1-6-1, Shinkawa, Chuo-Ku, Tokyo 104-0033, Japan. > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: custom goal (ant)
I don't see maven on marc.theaimsgroup.com or mail-archive.com. I've already searched here: http://nagoya.apache.org/eyebrowse/SearchList?listId=&listName=users%40maven.apache.org&searchText=ftp&defaultField=body&Search=Search prior to posting my question. I've also googled and done extensive other searching. I've seen the question posted a few times, but never answered. I'm guessing it's probably not that difficult to do - I'm just having a hard time with maven's documentation. Thanks anyways. Quoting dan tran <[EMAIL PROTECTED]>: > Search this list for "ftp" i am sure you will find the solution. > > -D > > > On Mon, 20 Sep 2004 08:24:46 -0700, Ben Anderson > <[EMAIL PROTECTED]> wrote: > > Hi, > > I want to create a goal which deploys to our qa box. I figured I'd use > custom > > goals with ant's ftp option. However, it doesn't seem to do anything. > I've > > tried the exact same thing in ant and it works fine. Here's my maven.xml: > > > > > default="jar:jar" > > xmlns:j="jelly:core" > > xmlns:u="jelly:util" > > xmlns:ant="jelly:ant"> > > > > > > > userid="qa_user" > > password="qa_password"> > > > > > > > > > > > > > > Any ideas what's wrong? > > 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]
custom goal (ant)
Hi, I want to create a goal which deploys to our qa box. I figured I'd use custom goals with ant's ftp option. However, it doesn't seem to do anything. I've tried the exact same thing in ant and it works fine. Here's my maven.xml: Any ideas what's wrong? Thanks, Ben - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: suppress warning output
Let me add onto the second part of this message... I need to compile using WebSphere 3.5.7's sdk which is a variant of sdk 1.2 (I know the response - "WHY?"). I set JAVA_HOME to point to directory containing bin/javac, but I'm getting this output: $ maven __ __ | \/ |__ _Apache__ ___ | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.0 java.lang.NoSuchMethodError: java.util.Collections: method singletonList(Ljava/lang/Object;)Ljava/util/List; not found at org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:607) at org.apache.maven.MavenSession.attainGoals(MavenSession.java:266) at org.apache.maven.cli.App.doMain(App.java:486) at org.apache.maven.cli.App.main(App.java:1215) at java.lang.reflect.Method.invoke(Native Method) at com.werken.forehead.Forehead.run(Forehead.java:551) at com.werken.forehead.Forehead.main(Forehead.java:581) Am I out of luck? Does Maven not run under sdk 1.2? I checked the apis' and sure enough there is no such method in java.util.List. I tried setting these properties (I found that you could do this to support 1.5, so I'm not sure if this actually does anything): maven.compile.source=1.2 maven.compile.target=1.2 Thanks, Ben Quoting Ben Anderson <[EMAIL PROTECTED]>: > Hi, > Is there a way to suppress warning messages when compiling? I don't see any > options listed in the properties. While I'm asking questions again - does > maven use the javac that my $PATH is pointing to, or some other one? > 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]
suppress warning output
Hi, Is there a way to suppress warning messages when compiling? I don't see any options listed in the properties. While I'm asking questions again - does maven use the javac that my $PATH is pointing to, or some other one? Thanks, Ben - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: stupid newbie
That article set me pretty straight. Maven's site might want to do a better job
at pointing people to the articles, since they are much more valuable than
Maven's own documentation. Anyways, I'm still left with a couple of questions:
I went here to find various dependencies:
http://www.ibiblio.org/maven/
I was able to use this approach:
itext
itext
0.99
to satisfy some, but unfortunately our app is dependent on quite a few
proprietary jars. I'm still unsure of how to set my classpath...
something like this?
${websphere.compileTimeClasses}/ejs.jar
would this work if websphere.compileTimeClasses was set? If so, how do I set
it? Like this?
If so, where do I put it?
I'd prefer not to have to copy all the jars into my local repository.
Thanks,
Ben
Quoting Martijn Dashorst <[EMAIL PROTECTED]>:
> Ben,
>
> The two files have different purposes: project.xml describes what your
> project is about, maven.xml describes how to do stuff which isn't done
> by maven plugins.
>
> Are your sources located relatively to the project.xml file in a
> subdirectory called 'MedAmerica_Working'? i.e.
>
> + projectroot/
> + project.xml
> + MedAmerica_Working/
> + com/
> + medamerica/
> + HelloWorld.java
> ?
>
> In your situation you need the following project.xml:
>
> 3
> ltc
> medamerica
> medamerica
> 1
>
> 2004
>
>
>
>
>
>
>
>
>
> servletapi
> servletapi
> 2.2
>
>
>
> MedAmerica_Working
>
>
>
> a 'maven jar' will create a jar file for your project. If you need a war
> file, then you'll need more configuration.
>
> Why don't you try the 'maven genapp' to look at a standard way of
> setting up your project? (See the plugin documentation for more
> information on the different types of projects the genapp can generate
> for you, http://maven.apache.org/reference/plugins/genapp/templates.html).
>
> Don't give up on maven too soon. It isn't that hard.
>
> Have you read the excellent article:
> http://www.theserverside.com/articles/article.tss?l=MavenMagic
> ?
>
> Martijn
>
> Ben Anderson wrote:
>
> >Thanks for the responses. ok, I updated to 1.0. I also, changed the name
> from
> >maven.xml to project.xml and this seems to have worked, which is it supposed
> to
> >be? Now I'm faced with classpath issues. I tried using this approach, but
> it
> >doesn't seem to work.
> >
> >
> > > default="jar:jar"
> > xmlns:j="jelly:core"
> > xmlns:u="jelly:util">
> >
> >
> > 3
> > medamerica
> > ltc
> > medamerica
> > 1
> >
> >
> >
> >
> >
> >MedAmerica_Working
> >
> >
> >${jarDir1}/servlet.jar
> >
> >
> >
> >
> >
> >
> >
>
>
> -
> 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: stupid newbie
Thanks for the responses. ok, I updated to 1.0. I also, changed the name from
maven.xml to project.xml and this seems to have worked, which is it supposed to
be? Now I'm faced with classpath issues. I tried using this approach, but it
doesn't seem to work.
3
medamerica
ltc
medamerica
1
MedAmerica_Working
${jarDir1}/servlet.jar
Quoting Emmanuel Venisse <[EMAIL PROTECTED]>:
> What is your directory structure?
>
> You know that you can upgrade your Maven to 1.0. 1.0RC3 is an very old
> version.
>
> Emmanuel
>
> ----- Original Message -
> From: "Ben Anderson" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Friday, September 17, 2004 2:24 PM
> Subject: stupid newbie
>
>
> > After perusing through maven's website for the thousandth time I've
> decided now
> > is the time for me to switch from ant. Unfortunately, I've been unable to
> > crawl so far, let alone walk. I don't know if I'm not understanding the
> > documentation or if it's just lacking. I also have searched through the
> > mail-archive (although my preferred marc.theaimsgroup.com does not have
> this
> > list?)
> >
> > My initial build should be simple. I just want to compile and jar up some
> > source files - that should be simple, right?
> >
> > Here's my pom:
> >
> >
> > 3
> > medamerica
> > ltc
> > medamerica
> > 1
> >
> >
> > MedAmerica_Working
> >
> >
> >
> >
> > so, then I run:
> >
> > $ maven jar:jar
> > __ __
> > | \/ |__ _Apache__ ___
> > | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~
> > |_| |_\__,_|\_/\___|_||_| v. 1.0-rc3
> >
> >
> 3medamericaltc factId>medamerica1 ceDirectory>MedAmerica_Workingbuild:start:
> >
> > java:prepare-filesystem:
> >
> > java:compile:
> > [echo] Compiling to d:\vss\src/target/classes
> > [echo] No java source files to compile.
> > resources or todir was null
> >
> > java:jar-resources:
> >
> > test:prepare-filesystem:
> >
> > test:test-resources:
> >
> > test:compile:
> > [echo] No test source files to compile.
> >
> > test:test:
> > [echo] No tests to run.
> >
> > BUILD FAILED
> > File.. D:\Documents and
> > Settings\banderso\.maven\plugins\maven-jar-plugin-1.5\plugin.jelly
> > Element... ant:fail
> > Line.. 42
> > Column 19
> > You must define currentVersion in your POM.
> > Total time: 3 seconds
> > Finished at: Fri Sep 17 08:19:21 EDT 2004
> >
> > I'm running this from cygwin, so I can cut and paste, but I get the same
> output
> > from regular DOS prompt. Sorry, for the simplicity of this question. If
> you
> > can at least point me in the right direction to learning...
> > TIA,
> > Ben Anderson
> >
> >
> > -
> > 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]
stupid newbie
After perusing through maven's website for the thousandth time I've decided now is the time for me to switch from ant. Unfortunately, I've been unable to crawl so far, let alone walk. I don't know if I'm not understanding the documentation or if it's just lacking. I also have searched through the mail-archive (although my preferred marc.theaimsgroup.com does not have this list?) My initial build should be simple. I just want to compile and jar up some source files - that should be simple, right? Here's my pom: 3 medamerica ltc medamerica 1 MedAmerica_Working so, then I run: $ maven jar:jar __ __ | \/ |__ _Apache__ ___ | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.0-rc3 3medamericaltcmedamerica1MedAmerica_Workingbuild:start: java:prepare-filesystem: java:compile: [echo] Compiling to d:\vss\src/target/classes [echo] No java source files to compile. resources or todir was null java:jar-resources: test:prepare-filesystem: test:test-resources: test:compile: [echo] No test source files to compile. test:test: [echo] No tests to run. BUILD FAILED File.. D:\Documents and Settings\banderso\.maven\plugins\maven-jar-plugin-1.5\plugin.jelly Element... ant:fail Line.. 42 Column 19 You must define currentVersion in your POM. Total time: 3 seconds Finished at: Fri Sep 17 08:19:21 EDT 2004 I'm running this from cygwin, so I can cut and paste, but I get the same output from regular DOS prompt. Sorry, for the simplicity of this question. If you can at least point me in the right direction to learning... TIA, Ben Anderson - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
