On Wed, 2005-04-27 at 01:01 +0200, Vincent Massol wrote:
> Hi,
> 
> I am thinking about writing a m2 plugin for Cargo
> (http://cargo.codehaus.org). Here's what a typical configuration for such a
> plugin could be:
> 
>    <configuration>
>      <containers>
>        <container>
>          <key>resin3x</key>
>          <homeDir>c:/apps/resin-3.0.9</homeDir> | 
>          <zipUrlInstaller>
>            <url>http://www.caucho.com/download/resin-3.0.9.zip</url>
>            <installDir>${basedir}/target/install</installDir>
>          </zipUrlInstaller>
>          <output>${basedir}/target/resin-cargo.log</output>
>          <append>false</append>
>          <log>${basedir}/target/resin-log.log</log>
>          <configuration>
>            <hint>standalone</hint>
>            <dir>${basedir}/target/resin</dir>
>            <properties>
>              <property>
>                <name>cargo.servlet.port</name>
>                <value>8080</value>
>              </property>
>              <property>
>                <name>cargo.logging</name>
>                <value>high</value>
>              </property>
>            </properties>
>          </configuration>
>        </container>
>      </containers>
>    </configuration>
> 
> As you can see there are at least 2 properties (and possibly more) that
> depends on the machine the build is executing: <homeDir> and the port to use
> (8080 in the example).
> 
> What is the mechanism to let users define these properties so that they are
> not checked-in the SCM?

I need the exact same thing in the plexus plugin. I want to parameterize
the generation of the Continuum runtime. We were thinking about trying
to implement a profile mechanism so that you could specify a key for the
profile that you would like to use and that profile would be referenced
for values. Trying to provide all this information on the command line
wouldn't be acceptable. A profile could also be utilized for testing
purposes where you pull in a test profile.

> Is there a mechanism to extend the settings.xml file and have plugins
> automatically get properties from there (something like the direct
> equivalent of the <plugins><plugin><configuration> entries in the POM)?

We're not sure where we're going to put this. Maybe a standard place for
profiles?

o maybe in ~/.m2/profiles as if you had many profiles you probably want
to encapsulate each one and a profile would probably be a simple
properties file.

o maybe you might want to put profiles in CVS, say different testing
profiles? 

We need to figure out how to apply the profiles too. Maybe at the plugin
level? When I ran into this problem, Brett and I decided alpha-3 would
be a good time to try and take a stab at profile but we're all ears.
Profiles will come into play on many levels not just for plug-ins, but
for creating deployments or whatever.

> Thanks
> -Vincent
> 
> _________________________________________________________________
> Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en franais !
> Yahoo! Mail : http://fr.mail.yahoo.com
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
-- 
jvz.

Jason van Zyl
jason at maven.org
http://maven.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to