On 11-Mar-08, at 8:09 AM, John Casey wrote:
I can see solving this in a generalized extension mechanism for
Plexus - which is different from a plugin situation, since plugins
are assumed to be leaf nodes of the classloader hierarchy, and are
therefore simpler to manage - but not for ClassWorlds. Milos is
completely correct on this one; the extension artifact needs to
manage how much of its dependency artifacts get exposed to the main
runtime, particularly since something like commons-collections would
never be able to make that sort of decision (or, substitute maven-
scm for commons-collections, if you like).
How is this not then a ClassWorlds problem. Ultimately you are going
to decided what gets loaded in a Realm, and what you expose yes? There
is also no way to currently export anything in a Realm.
If we have code for this sort of thing in Plexus, then that's fine,
but I'd prefer to get a preliminary implementation out for the
community to start using more quickly, so we can learn from it.
I honestly think this will end up far more complicated because you'll
have started in the middle. What exactly do you need?
I would say in summary it's a way to take a source of dependency
information and determine what portion of the information is used to
populate a new realm based on what exists in parent realms. Is this
not the case.
Then, we can refactor that stop-gap solution (which will be about
the same thing as we're going to be putting in Plexus, it's just
implemented one layer higher) to the more general one once it's
ready. In the meantime, we're going to be suffering a little more
than we need to if we're unnecessarily restrictive (without a path
for fixing that) with extension loading. We've already run into a
completely valid use case for this in one place; let's not put off
any solution until we have the perfect one.
I don't want a perfect one, I just don't want something unnecessarily
complicated. For example how are you going to even tackle exports when
this mechanism isn't supported in ClassWorlds?
Also, put the proposal in the wiki and then I believe your suggestion
of working on a branch and then getting people to review is a good
one. In your first email you say generally to avoid the problems in
2.0.x but you don't say what those are and I think that should be
outlined and coalesced with discussions we've had about extensions
before where we talked about extensions that were components, or
really plugin dependencies in the case of wagons for deployment or SCM
providers while in your email you're still talking about them as
extensions when wagons/scm providers might possibly be subsumed by
having a solution for including those as plugin dependencies.
-john
On Mar 11, 2008, at 2:23 AM, Jason van Zyl wrote:
I would highly recommend not doing this in Maven first and actually
prototyping something with Plexus and ClassWorlds and it is
something general and simple to start.
This is not a Maven specific thing. After sifting through the
plugin code to try and see how to generalize the mechanism it is
painfully obviously that what's buried in Maven is really general.
I would try it with some simple examples in ClassWorlds as not to
get bogged down in Maven specifics at first even though that it the
ultimate target. I would also recommend enlisting the opinion of
Dain if he's not on this list because he's done a lot of this
classloader work and has lots of good ideas and has attempt to make
OSGi like classloaders for just the purpose you're talking about.
Any file that is read to limit/restrict the classloader/realm
should be in classworlds.
On 10-Mar-08, at 1:27 PM, John Casey wrote:
I'm not entirely sure how to generalize it into plexus just yet,
since I'm jumping through some pretty complex ClassRealm-
management hoops in Maven right now. I'm not sure how I'd even
start telling Plexus to do that atm. The place in the current
trunk implementation to add this stuff is in Maven.
-john
On Mar 10, 2008, at 4:02 PM, Brett Porter wrote:
On 11/03/2008, at 6:52 AM, John Casey wrote:
I'd propose to resolve this using a mechanism borrowed from
OSGi: we should create some sort of manifest of classes to be
exported from the extension for use by the rest of Maven. This
file could be optional, and the existing behavior would result.
But if the file were present, it would name all the classes (and
class patterns?) in the extension artifact (and possibly its
dependencies) to "export" into the main maven ClassRealm(s) for
use by plugins. This is a relatively small change to Maven's
extension mechanism for 2.1, and would restore many of the best
features of the old extension functionality without incurring
the blind incompatibilities of the old system.
Anyone have any thoughts on this?
It was really off the top of my head, but it sounds like the
right approach. So you're saying this would be a maven specific
feature, not a general plexus one?
- Brett
--
Brett Porter
[EMAIL PROTECTED]
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---
John Casey
Committer and PMC Member, Apache Maven
mail: jdcasey at commonjava dot org
blog: http://www.ejlife.net/blogs/john
rss: http://feeds.feedburner.com/ejlife/john
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
happiness is like a butterfly: the more you chase it, the more it
will
elude you, but if you turn your attention to other things, it will
come
and sit softly on your shoulder ...
-- Thoreau
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---
John Casey
Committer and PMC Member, Apache Maven
mail: jdcasey at commonjava dot org
blog: http://www.ejlife.net/blogs/john
rss: http://feeds.feedburner.com/ejlife/john
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
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]
