You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Jason van Zyl <jv...@maven.org> on 2003/10/07 22:08:46 UTC
Moving Plugins
Howdy,
Just another push. If you have plugins that are non-core and you want me
to move them over let me know. I think I'm looking at Vincent and
Emmanuel as the next candidates :-)
--
jvz.
Jason van Zyl
jason@zenplex.com
http://tambora.zenplex.org
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Moving Plugins
Posted by Ryan Hoegg <rh...@isisnetworks.net>.
Peter Donald wrote:
>On Thu, 9 Oct 2003 12:17 am, Florin Vancea wrote:
>
>
>>If I may say something before it's too late: Maybe there is a need for a LATEST on each (or on several) branch (es).
>>
>>Something like
>>
>><dependency>
>> <groupId>log4j</groupId>
>> <artifactId>log4j</artifactId>
>> <version>LATEST</version>
>></dependency>
>>
>>should get the latest-and-gratest, but something like
>>
>><dependency>
>> <groupId>log4j</groupId>
>> <artifactId>log4j</artifactId>
>> <version>1.LATEST</version>
>></dependency>
>>
>>should use the latest version available that still has the version with prefix "1."
>>
>>Just a thought...
>>
>>
>
>I think it is a good throught but ... I think that it may be a beta idea to formalize a version-ing standard before you do this. For example one project may assume that anything compiled against 1.1 will work in 1.2 (ie minor versions represent forward compatible changes). Another project may assume that micro versions represent forward compatability (ie 1.1.2 is compatible with 1.1.1 or 1.1).
>
>That would make dependencys very close to JDK "optional packages"/"extensions" ala (except for no separation between implementation and specification).
>
>http://spice.sourceforge.net/extension/
>http://java.sun.com/j2se/1.3/docs/guide/extensions/versioning.html
>
>Alternatively you could specify version resolution scheme in the dependency declaration via something like
>
><dependency>
> <groupId>log4j</groupId>
> <artifactId>log4j</artifactId>
> <version>1.1</version>
> <version-resolution-policy>extension</version-resolution-policy>
></dependency>
>
>
There is an opportunity here to provide an extensible version resolution
system. If we somehow hand the entire <dependency/> element to the
fetch component (and anything else that needs to know about the
dependency) we can allow the version specification to be interpreted in
more than one way. This would allow us to try alternatives for version
resolution like 1.LATEST or like Peter's idea, as well as other
alternatives such as regular expressions or version ranges and
minimum/maximum versions. I am willing to do the work for this, but am
a bit skittish as I know there is a large body of code out there
somewhere from maven-new. Also, I have brought this up a couple times
on IRC and have been told that several people are already looking at this.
--
Ryan Hoegg
ISIS Networks
http://www.isisnetworks.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Moving Plugins
Posted by Peter Donald <pe...@realityforge.org>.
On Thu, 9 Oct 2003 12:17 am, Florin Vancea wrote:
> If I may say something before it's too late: Maybe there is a need for a
> LATEST on each (or on several) branch (es).
>
> Something like
>
> <dependency>
> <groupId>log4j</groupId>
> <artifactId>log4j</artifactId>
> <version>LATEST</version>
> </dependency>
>
> should get the latest-and-gratest, but something like
>
> <dependency>
> <groupId>log4j</groupId>
> <artifactId>log4j</artifactId>
> <version>1.LATEST</version>
> </dependency>
>
> should use the latest version available that still has the version with
> prefix "1."
>
> Just a thought...
I think it is a good throught but ... I think that it may be a beta idea to
formalize a version-ing standard before you do this. For example one project
may assume that anything compiled against 1.1 will work in 1.2 (ie minor
versions represent forward compatible changes). Another project may assume
that micro versions represent forward compatability (ie 1.1.2 is compatible
with 1.1.1 or 1.1).
That would make dependencys very close to JDK "optional packages"/"extensions"
ala (except for no separation between implementation and specification).
http://spice.sourceforge.net/extension/
http://java.sun.com/j2se/1.3/docs/guide/extensions/versioning.html
Alternatively you could specify version resolution scheme in the dependency
declaration via something like
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<version>1.1</version>
<version-resolution-policy>extension</version-resolution-policy>
</dependency>
--
Cheers,
Peter Donald
*---------------------------------------------*
| "The only way to discover the limits of the |
| possible is to go beyond them into the |
| impossible." -Arthur C. Clarke |
*---------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Moving Plugins
Posted by Florin Vancea <fv...@maxiq.ro>.
----- Original Message -----
From: "Jason van Zyl" <jv...@maven.org>
To: "Maven Developers List" <de...@maven.apache.org>
Sent: Wednesday, October 08, 2003 8:30 AM
Subject: RE: Moving Plugins
> > - also, now that plugins are externalized it will be more difficult to
> > converge in term of jar versions between them. You may end up having to
> > download 10 versions of log4j, etc. I believe we now need more urgently
> > something like the discussed LATEST (which would point to the latest
> > released jar):
> >
> > <dependency>
> > <groupId>log4j</groupId>
> > <artifactId>log4j</artifactId>
> > <version>LATEST</version>
> > </dependency>
> >
> > That would probably require the addition of some metadata file in the
> > remote repo (releases.xml for ex), listing all releases. The default
> > mode should not connect to internet every time maven builds but rather
> > only connects on demand.
>
> We can probably borrow the SNAPSHOT logic and modify it for use with
> LATEST.
>
If I may say something before it's too late: Maybe there is a need for a
LATEST on each (or on several) branch (es).
Something like
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<version>LATEST</version>
</dependency>
should get the latest-and-gratest, but something like
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<version>1.LATEST</version>
</dependency>
should use the latest version available that still has the version with
prefix "1."
Just a thought...
Florin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: Moving Plugins
Posted by Jason van Zyl <jv...@maven.org>.
On Wed, 2003-10-08 at 01:39, Vincent Massol wrote:
> Hi Jason,
>
> I'm fine with moving the following: Cactus, checkstyle, jboss, pmd,
> statcvs and actually all the other remaining plugins... I still don't
> understand why we need to keep any plugin at all in maven core. They can
> be downloaded for bootstrapping (in the same way as all the other jars
> are).
Ultimately total separation is the goal. I'm totally for complete
separation of the:
- core
- plugins
- installation builder
- functional testing
It's always been difficult for people to comprehend maven when they
start trying to help develop. Even our own developers aren't sure where
things are and don't do things correctly ... so I think we think along
the same lines in that a SOC is necessary. The plugins will be paired
down to the point where the can't be any more and that will reveal more
work I'm sure to allow the complete separation.
> However, I still have some questions :-)
>
> - are the latest released versions of maven-plugins plugins going to be
> packaged in the next release rc2?
It is a trivial task to package together whatever we deign to be the
release. This is not difficult but I'm sure there are plugins that we
don't need to include. For example the Plexus plugin certainly doesn't
need to be included. Again, anything can be included but I think we
should try to avoid the humungo install.
> - if not, are they going to be bundled for easy installing or would
> users need to install them one by one (which would be a pain)?
Again, it's a decision to be made what's installed. If someone feels
strongly about including a plugin then we can include it. For example I
don't consider anything EJB related to be default material but you might
think differently. If you want them in there I'm not averse to that at
all.
> - now that the plugins are decorelated from Maven core, the plugins need
> to state with what version of Maven they have been tested and are
> compatible with. How do we do this? Do we need a new pom tag?
Not sure yet. If we decide from 1.0 on that a plugin must work then we
definitely need a mechanism to easily test a plugin across versions or
mark a plugin as working with a specific version.
> - also, now that plugins are externalized it will be more difficult to
> converge in term of jar versions between them. You may end up having to
> download 10 versions of log4j, etc. I believe we now need more urgently
> something like the discussed LATEST (which would point to the latest
> released jar):
>
> <dependency>
> <groupId>log4j</groupId>
> <artifactId>log4j</artifactId>
> <version>LATEST</version>
> </dependency>
>
> That would probably require the addition of some metadata file in the
> remote repo (releases.xml for ex), listing all releases. The default
> mode should not connect to internet every time maven builds but rather
> only connects on demand.
We can probably borrow the SNAPSHOT logic and modify it for use with
LATEST.
> Thanks!
> -Vincent
>
> > -----Original Message-----
> > From: Jason van Zyl [mailto:jvanzyl@maven.org]
> > Sent: 07 October 2003 22:09
> > To: Maven Developers List
> > Subject: Moving Plugins
> >
> > Howdy,
> >
> > Just another push. If you have plugins that are non-core and you want
> me
> > to move them over let me know. I think I'm looking at Vincent and
> > Emmanuel as the next candidates :-)
> >
> > --
> > jvz.
> >
> > Jason van Zyl
> > jason@zenplex.com
> > http://tambora.zenplex.org
> >
> > In short, man creates for himself a new religion of a rational
> > and technical order to justify his work and to be justified in it.
> >
> > -- Jacques Ellul, The Technological Society
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
--
jvz.
Jason van Zyl
jason@zenplex.com
http://tambora.zenplex.org
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: Moving Plugins
Posted by Jason van Zyl <jv...@maven.org>.
On Wed, 2003-10-08 at 06:58, Vincent Massol wrote:
> Do you want me to move the one I listed in my previous mail or do you
> want to do it?
Sure, I can move them over when I do Pete's.
> Thanks
> -Vincent
>
> > -----Original Message-----
> > From: Jason van Zyl [mailto:jvanzyl@maven.org]
> > Sent: 08 October 2003 07:41
> > To: Maven Developers List
> > Subject: RE: Moving Plugins
> >
> > On Wed, 2003-10-08 at 02:53, Vincent Massol wrote:
> >
> > > Agreed. In my opinion we should do both. We already started the
> plugin
> > > move; we should finish it and not let it lie in mid-air.
> >
> > Many have been moved and I've offered help to anyone who has plugins
> and
> > wants them moved. I have moved my own and anyone who has contacted. I
> > didn't want to move plugins that didn't belong to me as a matter of
> > courtesy and just in case there is something that would be hampered in
> > the move as I'm not familiar with.
> >
> > I'll be moving kaz's plugins and what remain of emmanuel's as most of
> > them were moved already without asking.
> >
> > --
> > jvz.
> >
> > Jason van Zyl
> > jason@zenplex.com
> > http://tambora.zenplex.org
> >
> > In short, man creates for himself a new religion of a rational
> > and technical order to justify his work and to be justified in it.
> >
> > -- Jacques Ellul, The Technological Society
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
--
jvz.
Jason van Zyl
jason@zenplex.com
http://tambora.zenplex.org
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: Moving Plugins
Posted by Vincent Massol <vm...@pivolis.com>.
Do you want me to move the one I listed in my previous mail or do you
want to do it?
Thanks
-Vincent
> -----Original Message-----
> From: Jason van Zyl [mailto:jvanzyl@maven.org]
> Sent: 08 October 2003 07:41
> To: Maven Developers List
> Subject: RE: Moving Plugins
>
> On Wed, 2003-10-08 at 02:53, Vincent Massol wrote:
>
> > Agreed. In my opinion we should do both. We already started the
plugin
> > move; we should finish it and not let it lie in mid-air.
>
> Many have been moved and I've offered help to anyone who has plugins
and
> wants them moved. I have moved my own and anyone who has contacted. I
> didn't want to move plugins that didn't belong to me as a matter of
> courtesy and just in case there is something that would be hampered in
> the move as I'm not familiar with.
>
> I'll be moving kaz's plugins and what remain of emmanuel's as most of
> them were moved already without asking.
>
> --
> jvz.
>
> Jason van Zyl
> jason@zenplex.com
> http://tambora.zenplex.org
>
> In short, man creates for himself a new religion of a rational
> and technical order to justify his work and to be justified in it.
>
> -- Jacques Ellul, The Technological Society
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: Moving Plugins
Posted by Jason van Zyl <jv...@maven.org>.
On Wed, 2003-10-08 at 02:53, Vincent Massol wrote:
> Agreed. In my opinion we should do both. We already started the plugin
> move; we should finish it and not let it lie in mid-air.
Many have been moved and I've offered help to anyone who has plugins and
wants them moved. I have moved my own and anyone who has contacted. I
didn't want to move plugins that didn't belong to me as a matter of
courtesy and just in case there is something that would be hampered in
the move as I'm not familiar with.
I'll be moving kaz's plugins and what remain of emmanuel's as most of
them were moved already without asking.
--
jvz.
Jason van Zyl
jason@zenplex.com
http://tambora.zenplex.org
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: Moving Plugins
Posted by Vincent Massol <vm...@pivolis.com>.
> -----Original Message-----
> From: dion@multitask.com.au [mailto:dion@multitask.com.au]
> Sent: 08 October 2003 09:10
> To: Maven Developers List
> Subject: RE: Moving Plugins
[snip]
> > In addition, adding this declaration will download the maven jar
which
> > is unnecessary for most plugins.
>
> It should be pre-populated in the repo as part of the install, as
should
> all of maven and the shipped plugin dependencies.
What I meant was that if I have Maven b10 installed and I download, say
the new cactus plugin that has a dependency on maven rc1, the maven rc1
jar will get downloaded...
-Vincent
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: Moving Plugins
Posted by di...@multitask.com.au.
"Vincent Massol" <vm...@pivolis.com> wrote on 08/10/2003 04:53:36 PM:
[snip]
> Agreed. In my opinion we should do both. We already started the plugin
> move; we should finish it and not let it lie in mid-air. I shall be able
> to help more in about 1-2 week's time now that my JUnit book is going to
> press... (yeah :-). It's sooooo good when it's finished).
I've started it some. We just need a plan I think :-)
[snip]
> > They should declare it, if needed, using a dependency. Some of them
> > already do.
>
> Yeah I thought about this, but... How is that going to work? 99.99% of
> the plugin do not depend on the maven jar... Let's take an example;
> let's imagine I want to say that the maven-cactus-plugin plugin only
> works with Maven RC1 or later. How do I say that? How is it checked by
> the Maven core so that Maven will say "Sorry, you need Maven xx or
> greater for this plugin to work"?
Yep, this and the JDK are a good example for this sort of behaviour. It's
a runtime requirement rather than a dependency per-se.
Not sure of the best way to solve this issue yet.
> In addition, adding this declaration will download the maven jar which
> is unnecessary for most plugins.
It should be pre-populated in the repo as part of the install, as should
all of maven and the shipped plugin dependencies.
--
dIon Gillard, Multitask Consulting
Blog: http://blogs.codehaus.org/people/dion/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: Moving Plugins
Posted by Vincent Massol <vm...@pivolis.com>.
> -----Original Message-----
> From: dion@multitask.com.au [mailto:dion@multitask.com.au]
> Sent: 08 October 2003 08:03
> To: Maven Developers List
> Subject: RE: Moving Plugins
>
> "Vincent Massol" <vm...@pivolis.com> wrote on 08/10/2003 03:39:23
PM:
>
> > Hi Jason,
> >
> > I'm fine with moving the following: Cactus, checkstyle, jboss, pmd,
> > statcvs and actually all the other remaining plugins... I still
don't
> > understand why we need to keep any plugin at all in maven core. They
can
> > be downloaded for bootstrapping (in the same way as all the other
jars
> > are).
>
> I'd rather we got the moved plugins integrated into the
> distribution/install process so that it's easier to do rc-2, and got
the
> web site back to it's original functionality. This moving stuff and
losing
> functionality/documentation shits me.
Agreed. In my opinion we should do both. We already started the plugin
move; we should finish it and not let it lie in mid-air. I shall be able
to help more in about 1-2 week's time now that my JUnit book is going to
press... (yeah :-). It's sooooo good when it's finished).
[snip]
> > - now that the plugins are decorelated from Maven core, the plugins
need
> > to state with what version of Maven they have been tested and are
> > compatible with. How do we do this? Do we need a new pom tag?
>
> They should declare it, if needed, using a dependency. Some of them
> already do.
Yeah I thought about this, but... How is that going to work? 99.99% of
the plugin do not depend on the maven jar... Let's take an example;
let's imagine I want to say that the maven-cactus-plugin plugin only
works with Maven RC1 or later. How do I say that? How is it checked by
the Maven core so that Maven will say "Sorry, you need Maven xx or
greater for this plugin to work"?
In addition, adding this declaration will download the maven jar which
is unnecessary for most plugins.
>
> > - also, now that plugins are externalized it will be more difficult
to
> > converge in term of jar versions between them. You may end up having
to
>
> I don't see why. We have a dependency convergence report for the core
set
> (currently http://maven.apache.org/dependency-convergence-report.html
),
> and if we could get our act together on setting up a site for the
split
> plugins, we'd have the same report. It's not that difficult.
>
> > download 10 versions of log4j, etc. I believe we now need more
urgently
> > something like the discussed LATEST (which would point to the latest
> > released jar):
> >
> > <dependency>
> > <groupId>log4j</groupId>
> > <artifactId>log4j</artifactId>
> > <version>LATEST</version>
> > </dependency>
> >
> > That would probably require the addition of some metadata file in
the
> > remote repo (releases.xml for ex), listing all releases. The default
> > mode should not connect to internet every time maven builds but
rather
> > only connects on demand.
>
> Good idea, and I think we'll need it eventually, but IMHO there are
more
> important issues to solve, such as getting a distribution of maven
> together that includes all the needed jars and plugins.
Agreed. In any case I should help if I want to get things done... ;-)
Thanks dIon
-Vincent
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: Moving Plugins
Posted by di...@multitask.com.au.
"Vincent Massol" <vm...@pivolis.com> wrote on 08/10/2003 03:39:23 PM:
> Hi Jason,
>
> I'm fine with moving the following: Cactus, checkstyle, jboss, pmd,
> statcvs and actually all the other remaining plugins... I still don't
> understand why we need to keep any plugin at all in maven core. They can
> be downloaded for bootstrapping (in the same way as all the other jars
> are).
I'd rather we got the moved plugins integrated into the
distribution/install process so that it's easier to do rc-2, and got the
web site back to it's original functionality. This moving stuff and losing
functionality/documentation shits me.
> However, I still have some questions :-)
>
> - are the latest released versions of maven-plugins plugins going to be
> packaged in the next release rc2?
Yes.
> - if not, are they going to be bundled for easy installing or would
> users need to install them one by one (which would be a pain)?
No.
> - now that the plugins are decorelated from Maven core, the plugins need
> to state with what version of Maven they have been tested and are
> compatible with. How do we do this? Do we need a new pom tag?
They should declare it, if needed, using a dependency. Some of them
already do.
> - also, now that plugins are externalized it will be more difficult to
> converge in term of jar versions between them. You may end up having to
I don't see why. We have a dependency convergence report for the core set
(currently http://maven.apache.org/dependency-convergence-report.html ),
and if we could get our act together on setting up a site for the split
plugins, we'd have the same report. It's not that difficult.
> download 10 versions of log4j, etc. I believe we now need more urgently
> something like the discussed LATEST (which would point to the latest
> released jar):
>
> <dependency>
> <groupId>log4j</groupId>
> <artifactId>log4j</artifactId>
> <version>LATEST</version>
> </dependency>
>
> That would probably require the addition of some metadata file in the
> remote repo (releases.xml for ex), listing all releases. The default
> mode should not connect to internet every time maven builds but rather
> only connects on demand.
Good idea, and I think we'll need it eventually, but IMHO there are more
important issues to solve, such as getting a distribution of maven
together that includes all the needed jars and plugins.
--
dIon Gillard, Multitask Consulting
Blog: http://blogs.codehaus.org/people/dion/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: Moving Plugins
Posted by Vincent Massol <vm...@pivolis.com>.
Hi Jason,
I'm fine with moving the following: Cactus, checkstyle, jboss, pmd,
statcvs and actually all the other remaining plugins... I still don't
understand why we need to keep any plugin at all in maven core. They can
be downloaded for bootstrapping (in the same way as all the other jars
are).
However, I still have some questions :-)
- are the latest released versions of maven-plugins plugins going to be
packaged in the next release rc2?
- if not, are they going to be bundled for easy installing or would
users need to install them one by one (which would be a pain)?
- now that the plugins are decorelated from Maven core, the plugins need
to state with what version of Maven they have been tested and are
compatible with. How do we do this? Do we need a new pom tag?
- also, now that plugins are externalized it will be more difficult to
converge in term of jar versions between them. You may end up having to
download 10 versions of log4j, etc. I believe we now need more urgently
something like the discussed LATEST (which would point to the latest
released jar):
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<version>LATEST</version>
</dependency>
That would probably require the addition of some metadata file in the
remote repo (releases.xml for ex), listing all releases. The default
mode should not connect to internet every time maven builds but rather
only connects on demand.
Thanks!
-Vincent
> -----Original Message-----
> From: Jason van Zyl [mailto:jvanzyl@maven.org]
> Sent: 07 October 2003 22:09
> To: Maven Developers List
> Subject: Moving Plugins
>
> Howdy,
>
> Just another push. If you have plugins that are non-core and you want
me
> to move them over let me know. I think I'm looking at Vincent and
> Emmanuel as the next candidates :-)
>
> --
> jvz.
>
> Jason van Zyl
> jason@zenplex.com
> http://tambora.zenplex.org
>
> In short, man creates for himself a new religion of a rational
> and technical order to justify his work and to be justified in it.
>
> -- Jacques Ellul, The Technological Society
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org