Using ant filtercopies to set context-roots in xml files and hyperlinks and
all that.
everybody works out of their own sandbox with their own context-root.
I've made it possible so they can work that way, and then I have goals that
allow them
to store their work on the university JBoss server ... blah blah, it never
ends.
I've been doing lots preGoal things like that, setting maven.war.src for
example and then doing an attainGoal name="war"
the sub-project can be executed within its own directory, or it might be
executed from the parent reactor. All Rules Descend from the parent works
really well, and I like that last-set business. But to protect the overall
project I'm having to divide it into cvs modules so that this person or that
person only works in a sub-project, creating a certain EAR or WAR or
whatever.
It would be great if I could be "SURE" that the sub-project gets the same
environment from loading the parent properties manually as they do from
inheriting them from the reactor. If I set a ${sandbox} kind of thing
correctly in sub-project build.properties, I can have the sub-project
project.properties fall into a nice hierarchical cascade scheme. but i
must be sure build gets loaded first in sub to create that hierarchy in
project.
I'm trying to avoid unnecessary complexity and chaos. Working last-set from
parent, first-set in sub-project ... you ever get that feeling ...?
----- Original Message -----
From: "Brett Porter" <[EMAIL PROTECTED]>
To: "'Maven Users List'" <[EMAIL PROTECTED]>
Sent: Wednesday, September 17, 2003 3:18 PM
Subject: RE: maven vs ant property settings
> I'm confused about which properties you are trying to set though. Sounds
> more like you need to provide them with templates for their properties in
> this case.
>
> I've seen some developers wildcarding some things pretty badly too :)
> Originally I had our projects loading a set of custom properties and
> per-user properties on every invocation (as well as converting them to
> filters). IT worked, but it was unnecessarily complex and I've since
ripped
> it out.
>
> If you are needing to set properties to affect the plugin, you probably
have
> to load your property file in a preGoal on the one you are thinking of,
and
> then actually push the properties into the plugin context using
> ${pom.getPluginContext('maven-war-plugin').setVariable('maven.war.src',
> 'web')} at the moment.
>
> - Brett
>
> > -----Original Message-----
> > From: khote [mailto:[EMAIL PROTECTED]
> > Sent: Thursday, 18 September 2003 8:09 AM
> > To: Maven Users List
> > Subject: Re: maven vs ant property settings
> >
> >
> > I have a single JBoss server at the university. Some of my
> > project team works via ssh on that server, some of them work
> > on their home system with their own JBoss server, some have
> > only localhost and some have a domain name ... I'm probably
> > going to end up with several other combinations.
> >
> > I'm trying to run this out of cvs as well. I need to give
> > each member a build.properties in each project and
> > sub-project, that doesn't make it to the cvs repository of
> > course ... it can get to be a huge mess. And I'm dealing
> > with students, they often have a unique way of *ing
> > everything up with breathtaking stupidty
> >
> > If I had more certain control over the way properties are set
> > I would be happier.
> >
> > ----- Original Message -----
> > From: "Brett Porter" <[EMAIL PROTECTED]>
> > To: "'Maven Users List'" <[EMAIL PROTECTED]>
> > Sent: Wednesday, September 17, 2003 2:59 PM
> > Subject: RE: maven vs ant property settings
> >
> >
> > > Where were you trying to use the properties? This will only work for
> > inside
> > > the maven.xml file you have defined, not outside of it.
> > >
> > > Loading parent project.properties files is on the TODO list - check
> > > JIRA. Unfortunately, for now you'll just have to work
> > around it. I've
> > > never
> > found
> > > this to be an issue, although it would be nicer to be able
> > to use an
> > > extended project.properties to do some extra things.
> > >
> > > - Brett
> > >
> > > > -----Original Message-----
> > > > From: Dominik Dahlem [mailto:[EMAIL PROTECTED]
> > > > Sent: Thursday, 18 September 2003 12:55 AM
> > > > Cc: Maven Users List
> > > > Subject: Re: maven vs ant property settings
> > > >
> > > >
> > > > I don't have a solution to your problem. But I had
> > similar problems.
> > > > I played a bit with property settings recently. All my
> > duplications
> > > > in my projects are in properties files. I couldn't find a way to
> > > > load properties from a master project.properties file. I tried to
> > > > load the properties in maven.xml:
> > > >
> > > > <project default="site"
> > > > xmlns:ant="jelly:ant">
> > > > <ant:property
> > file="${basedir}/../../master/project.properties"/>
> > > > </project>
> > > >
> > > > However, this project didn't recognize the properties
> > from my master
> > > > file. I'd be happy, if someone has a solution for that.
> > > >
> > > >
> > > > Dominik
> > > >
> > > >
> > > > On Wed, 2003-09-17 at 15:15, khote wrote:
> > > > > I understant an important difference in the way maven and
> > > > ant handle
> > > > > property settings is first-set vs last-set. when I'm in a child
> > > > > project that wants to inherit from the parent in this
> > > > > manner:
> > > > >
> > > > > <property file="../project.properties"/>
> > > > > <property file="../build.properties"/>
> > > > >
> > > > > It's not always convenient to use the parent reactor to
> > execute in
> > > > > child projects, so I can't always count on those settings
> > > > > existing, particularly directory settings in the
> > build.properties
> > > > > for local system information.
> > > > >
> > > > > Which way is it being done, maven or ant? If ant, is there
> > > > a way to
> > > > > get it done last-set?
> > > > >
> > > > > -----------------------------------------------------------
> > > > > "Trying is the first step towards failure." -- Homer Simpson
> > > > >
> > > > > kevinHagel
> > > > > http://hagelnx.com
> > > > >
> > > > >
> > > > >
> > > >
> > --------------------------------------------------------------------
> > > > -
> > > > > 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]
