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?
What you are trying to accomplish is classloader isolation with the
limitation of artifacts place in a classloader and/or limiting their
view with a piece of information. How is this not very classloader
specific. My assertion is that this is entirely a classloader problem
regardless of where the information is coming from. In this case it's
Maven. We'll start with that.
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?
First: This is not tearing about the internals of Maven. It is a
single class that needs to be changed, and the change is very small.
You can look at the way these things are handled today, in the
DefaultMavenRealmManager inside maven-project. This is the place
where such changes could very easily be tested without an impact to
the rest of the Maven, Plexus, or ClassWorlds codebase.
Second: I agree that the extension artifact should be able to be put
in charge of the export information. The problem comes when this
extension artifact makes its way into both the extension and the
plugin realms, where the same control file can be read from
classworlds, and severely screw things up. It's true that plugin
realms are managed differently than extension realms, but I'm not
confident that this difference could prevent such a mess.
I just don't see a reason to risk completely destabilizing Maven's
trunk by changing a whole chain of dependencies, when we could try
out such a small change right in maven itself for the first alpha.
That's what we all say, which resulted in me backing out, or keeping
out my changes big and small. It was your suggestion to make all
changes on branches and then merge them in, not me.
It's just an alpha, after all, nothing so permanent, and it
certainly wouldn't preclude burying the same functionality deeper
within the dependency chain once we've vetted the theory on working
code and determined that we can push that code down below both the
plugin and extension layers safely. We don't need to push out the
alpha release of Maven 2.1 any further for this, but I think we
could get a show of hands together relatively quickly to show that
this is important to include in some form.
I don't think that ClassWorlds is the wrong place for this to end
up; I just want to take a little longer path to put it there, so we
can develop the code through a couple more iterations first.
Classworlds is behind a lot more than Maven, and I don't want to
jeopardize other release paths there, either.
-john
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]
---
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]
