Additionally Igor, who's working on m2eclipse, has also done a bunch
of classloading magic with Plexus and OSGi stuff specifically so when
you write something up I'll make sure he and Dain comment. Dain and
Igor both have classloaders that have modeled this to some extent.
On 11-Mar-08, at 10:31 AM, John Casey wrote:
I'll prepare a formal proposal on the wiki, and produce a proof-of-
concept on a branch to aid this discussion. I'll need to get Dain
and anyone else with OSGi or related experience to look this over,
though, since I'd be willing to bet that applications need to have
the ability to manage this import/export (or, bridging) behavior,
not the classloader itself. This may happen through the specific
bundle manifests and the fact that these bundles are only used in
similar systems, but I'm willing to bet that such bundle exports
have to be managed at the application level, not at the individual
library level.
-john
On Mar 11, 2008, at 11:26 AM, Jason van Zyl wrote:
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]
---
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
----------------------------------------------------------
We know what we are, but know not what we may be.
-- Shakespeare
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
