commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <craig...@apache.org>
Subject Re: Maven "Craig" feature added :-)
Date Thu, 11 Jul 2002 21:51:57 GMT


On 11 Jul 2002, Jason van Zyl wrote:

> Date: 11 Jul 2002 17:46:07 -0400
> From: Jason van Zyl <jason@zenplex.com>
> Reply-To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
> To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
> Subject: Re: Maven "Craig" feature added :-)
>
> On Thu, 2002-07-11 at 17:36, Craig R. McClanahan wrote:
> >
> >
> > Wow, I feel so important!  A feature named after *me*  :-)
>
> That's what it will officially be referred to from now on ;-)
>
> > >
> > > jvanzyl     2002/07/11 11:53:09
> > >
> > >   Modified:    src/bin  driver.jelly
> > >   Log:
> > >   o This change adds support for the 'Craig' feature :-)
> > >
> > >     If you have:
> > >
> > >     maven.jar.override = on
> > >
> > >     set then you can specify properties like the following:
> > >
> > >     maven.jar.commons-beanutils = /path/to/commons-beanutils.jar
> > >     maven.jar.commons-digester = /path/to/commons-digester.jar
> > >
> > >     And they will override the dependency specified in the POM.
> > >
> > >     This is preliminary but is working and shouldn't affect anyone
> > >     because the maven.jar.override needs to be present and on and
> > >     you need the special properties as well.
> > >
> >
> > In principle it sounds like this would do the trick.
> >
> > These would go in your project.properties file, right?  Since that file is
> > checked in to CVS (at least on the Mavenized projects I've seen), I
> > presume there is some mechanism for local overrides (like what most Ant
> > build scripts do with build.properties files)?
>
> For testing I defined them in my ~/build.properties file. In maven at
> the moment that last definition of a property wins (the reverse of ant)
> so you could override at the project level if you wanted. But I don't
> think that would happen much as the project.xml defines the version to
> use at the project level. But you could override it if you wanted.
>

Ah ... I didn't realize you were doing the automatic reading of
build.properties already.  (And "${user.home}/build.properties" as well, I
hope.)  That should cover the use cases I was worried about.

> > I also kinda like Costin's suggestion about using property names more
> > familiar to folks who have built build.xml scripts (and associated
> > properties files) in the past.
>
> All I need is the unique project id, in our example commons-beanutils,
> so using the method currently used is perfectly acceptable.
>
> > You'd certainly want to have a separate
> > "override.properties" file (or something) for these, to avoid potential
> > name clashes.
>
> Not sure I follow ... you mean if maven.override.jars = on then consult
> the special override.properties file? Would it have to be in a separate
> file?
>
> At any rate, it's wide open and can be changed to accommodate users.
>

Does this, in principle, let you override *any* project property, or just
JAR file locations?  Flexibility sounds intriguing, but might also be a
little dangerous.

Craig


--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message