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
On 11-Mar-08, at 9:55 AM, John Casey wrote:
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 b
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 th
On 11-Mar-08, at 8:39 AM, John Casey wrote:
On Mar 11, 2008, at 10:37 AM, Jason van Zyl wrote:
The experiment that this mechanism works must be done at the
Classworlds level first.
Can you please provide some reasoning why this is an absolute,
rather than just making an assertion?
Wh
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
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 ClassW
On Mar 11, 2008, at 10:37 AM, Jason van Zyl wrote:
The experiment that this mechanism works must be done at the
Classworlds level first.
Can you please provide some reasoning why this is an absolute, rather
than just making an assertion?
That we have enough information to mimic what nee
The experiment that this mechanism works must be done at the
Classworlds level first.
That we have enough information to mimic what need there alone, I
certainly agree with you but that can be closely modeled before we
start tearing about the internals of Maven. The source of information
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 on
i'm not convinced it can be solved on the classworlds level alone. The
import of single packages needs to be done for a whole tree of jars
that the extension depends on. And it needs to be defined in one place
and that is the extension jar. The classworlds-internal solution
doesn't have any idea ab
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
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
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 resu
Hi all,
In order to prevent the issues we've had in 2.0.x, I've refactored
the extension mechanism in 2.1 to be much more careful about
separating extensions from the core of maven. All extensions are
loaded into their own ClassRealm that inherits from the maven core
ClassRealm, and each
14 matches
Mail list logo
