On 24-Mar-09, at 8:08 AM, John Casey wrote:
There's a similar thing happening in the assembly plugin, for
component descriptor handlers (the things that merge various
descriptors when there is a collision, rather than simply replacing
one with another). It might work out alright to simply load a
collection of these, then pick the correct one...
One thing about it though: we're going to need to release an
intermediate version (2.2.x?) that contains a plexus version which
can inject collections properly, if we're going to migrate the
plugins over in anticipation of 3.0. Since the version of plexus
used in 2.1.0 doesn't handle collections properly (still using
alpha-9), we can't really migrate away before 3.0 otherwise, which
means 3.0 will still have to support lookup(..) in some form.
The session lookup can stay in 2.x.x forever really. I don't want to
do any work in the 2.x.x line to support the new container I just want
people to know it's deprecated. When they switch to 3.0 it's not going
to be there.
-john
Brian E. Fox wrote:
The enforcer uses this to hand components over to the rules via a get
Component method (it implements the expressionevaluator interface). I
would probably need to convert all the rules over to actual plexus
components to use injection.
-----Original Message-----
From: Jason van Zyl [mailto:[email protected]] Sent: Monday,
March 23, 2009 7:51 PM
To: Maven Developers List
Subject: deprecating MavenSession.lookup( role|class ) and prefer
injection in plugins
Hi,
I would like to remove the MavenSession.lookup( class|role )
methods in Maven 3.x so I would like to start deprecating them and
prefer injecting anything required using a javadoc annotation
(current plugin api) and an annotation (the new plugin api).
General access to the container is not required more with the new
annotation-based Plexus containers and it's really a bad practice
not to have injected all the things you need.
Plexus used in Maven 3.x injects collections properly and as new
components enter the system they find their way into the correct
collections. So, for example, if a new lifecycle mapping is
discovered in the system it will just automatically show up it
the Map<String,Lifecycle> inside the LifecycleExecutor. This was
the primary reason why we exposed the container and it's not
required anymore.
So if we deprecate starting now, folks will know long before Maven
3.x comes out.
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
----------------------------------------------------------
Our achievements speak for themselves. What we have to keep track
of are our failures, discouragements and doubts. We tend to forget
the past difficulties, the many false starts, and the painful
groping. We see our past achievements as the end result of a
clean forward thrust, and our present difficulties as
signs of decline and decay.
-- Eric Hoffer, Reflections on the Human Condition
---------------------------------------------------------------------
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]
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
----------------------------------------------------------
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: [email protected]
For additional commands, e-mail: [email protected]
