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
of what to add to a realm and what to export will vary with each
application but ultimately the information culminates in instructions
to ClassWorlds to do something with the classloader. You disagree with
this?
On 11-Mar-08, at 4:00 AM, Milos Kleint wrote:
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 about these constraints.
But of course classworlds need to have means of restricting access to
certain packages.. Not usre if the current importFrom() methods
fulfils the requirements.
Milos
On Tue, Mar 11, 2008 at 7:23 AM, Jason van Zyl <[EMAIL PROTECTED]>
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
downI'm not
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
A party which is not afraid of letting culture,
business, and welfare go to ruin completely can
be omnipotent for a while.
-- Jakob Burckhardt
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
