You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by John Casey <jd...@commonjava.org> on 2008/03/10 20:52:05 UTC
[proposal] Controlling extension-exported classes
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 project that uses an extension gets its own
ClassRealm that inherits from the core realm as well. The project
realm then imports all implementations of components declared in the
extension artifact. The interfaces for these components are assumed
to exist inside maven's core realm, to prevent adding new interfaces
to the runtime that plugins see.
Plugins each get their own ClassRealm, which is associated with a
particular project realm (or, if the project isn't using extensions,
the core realm) just before the plugin executes. This allows plugin
realms to be reusable across multiple projects (at least, that's the
theory), and reduces the memory problem incurred by each project
having their own copy of each plugin's realm.
The problem we've run into is that the dotnet code relies on maven-
toolchains, but uses sub-interfaces of the main toolchain interfaces
to do its work. This means it's not as simple as just casting the
dotnet-specific toolchain components to their implementation classes
and using that. Instead, the dotnet work relies on access to the sub-
interfaces, which are loaded twice: once in the extension realm
(isolated from the rest of the build, but accessible from the
extension's imported classes), and once again in the plugin (since it
can't see the sub-interface from the extension).
Simply adding all classes in an extension (and its dependencies) to
the core maven realm (or a project-specific realm) is not a great
option, since this can cause incompatibilities between the extension
and plugins. If the project uses and extension that depends on maven-
scm 1.0, and plugin Y needs maven-scm 1.1, you're out of luck. In the
current 2.1 implementation, the dependency on maven-scm from the
extension should be effectively hidden from the rest of maven, only
accessible from the extension component itself. Obviously this hiding
mechanism is a little too restrictive, since it also hides other
public non-core interfaces that need to be present to be used from
plugins.
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?
-john
---
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
RE: Development process (was: Controlling extension-exported classes)
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
I for one would like to see some design docs on the various changes so
we can grok them. I'm not sure rolling everything out is really what we
need at this point.
-----Original Message-----
From: John Casey [mailto:jdcasey@commonjava.org]
Sent: Tuesday, March 11, 2008 6:15 PM
To: Maven Developers List
Subject: Development process (was: Controlling extension-exported
classes)
That's completely true. I've implemented a new extension mechanism
with little or no documentation in the wiki or on the developers'
list. I was just about the only one committing on trunk at the time,
I was pretty careful to avoid bugs with this new implementation (and
made it number one priority to fix any issues that came up), and I
talked to almost anyone who would listen about this new extensions
mechanism (and the related work to allow multiple plugin versions in
the same build), including you on multiple occasions. All of my
commits have been done in public view, and there has been ample
opportunity to object to the direction I've been pursuing.
Over the past year, I've talked quite a bit about feature branches.
Some of this came as a result of some nasty surprises on trunk,
including some unilaterally deleted code to handle error messaging
that I wound up replacing with two new successive implementations
myself, because the original code was too complex (not my words). The
current implementation which I'm guessing is not overly complex - I
haven't floated a design doc on this either yet - is based on
AspectJ, which I know some people are uneasy about, but which is
still the best solution I've found (I had a functionality gap to
plug, remember). I talked about feature branches because that's a key
part of the process that we all agreed to early last year.
If any of the Maven committers is uncomfortable with the work I've
done on trunk, I'll pull it out onto a feature branch and we can vote
on it. I'd much prefer that there were some viable alternative to
fill the functionality vacuum, but we'll deal with this as it comes.
I still have a TODO to write up the design docs for the extension
mechanism, along with one for the error reporting, and Brett's
mentioned the importance of the branch-doc-vote-merge process in
helping those with limited time to keep up with the pace of
development. If we're all fine with slowing things down on trunk, I'm
fine with pulling these changes out, separating them into individual
design chunks, voting on them, and putting them back in. We can
simply roll back to 2.0.x functionality with trunk in the meantime.
I'm not going to try to be an exception to the rules here, if we can
all agree to follow them. I'm no more entitled than any of us to make
unilateral decisions about Maven code. I've been hypocritical in
these cases, and I'm perfectly willing to make it right.
Unfortunately, that's the best I can offer.
-john
On Mar 11, 2008, at 1:22 PM, Jason van Zyl wrote:
> Which you basically added without much discussion, no proposal and
> Milos' rightly nailed me the last time I tried that and that's
> perfectly valid. You're doing much the same thing and it's you
> yourself that asked that everything be done on a feature branch.
---
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Development process (was: Controlling extension-exported classes)
Posted by John Casey <jd...@commonjava.org>.
That's completely true. I've implemented a new extension mechanism
with little or no documentation in the wiki or on the developers'
list. I was just about the only one committing on trunk at the time,
I was pretty careful to avoid bugs with this new implementation (and
made it number one priority to fix any issues that came up), and I
talked to almost anyone who would listen about this new extensions
mechanism (and the related work to allow multiple plugin versions in
the same build), including you on multiple occasions. All of my
commits have been done in public view, and there has been ample
opportunity to object to the direction I've been pursuing.
Over the past year, I've talked quite a bit about feature branches.
Some of this came as a result of some nasty surprises on trunk,
including some unilaterally deleted code to handle error messaging
that I wound up replacing with two new successive implementations
myself, because the original code was too complex (not my words). The
current implementation which I'm guessing is not overly complex - I
haven't floated a design doc on this either yet - is based on
AspectJ, which I know some people are uneasy about, but which is
still the best solution I've found (I had a functionality gap to
plug, remember). I talked about feature branches because that's a key
part of the process that we all agreed to early last year.
If any of the Maven committers is uncomfortable with the work I've
done on trunk, I'll pull it out onto a feature branch and we can vote
on it. I'd much prefer that there were some viable alternative to
fill the functionality vacuum, but we'll deal with this as it comes.
I still have a TODO to write up the design docs for the extension
mechanism, along with one for the error reporting, and Brett's
mentioned the importance of the branch-doc-vote-merge process in
helping those with limited time to keep up with the pace of
development. If we're all fine with slowing things down on trunk, I'm
fine with pulling these changes out, separating them into individual
design chunks, voting on them, and putting them back in. We can
simply roll back to 2.0.x functionality with trunk in the meantime.
I'm not going to try to be an exception to the rules here, if we can
all agree to follow them. I'm no more entitled than any of us to make
unilateral decisions about Maven code. I've been hypocritical in
these cases, and I'm perfectly willing to make it right.
Unfortunately, that's the best I can offer.
-john
On Mar 11, 2008, at 1:22 PM, Jason van Zyl wrote:
> Which you basically added without much discussion, no proposal and
> Milos' rightly nailed me the last time I tried that and that's
> perfectly valid. You're doing much the same thing and it's you
> yourself that asked that everything be done on a feature branch.
---
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
Re: [proposal] Controlling extension-exported classes
Posted by Jason van Zyl <ja...@maven.org>.
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 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.
>
> The problem is that we may not always want to read the exports
> manifest for a particular artifact. Take the case when an artifact
> is sometimes a dependency that defers to another artifact (like a
> plugin or an extension) but at other times is used as a plugin or
> extension for a different application. In this case, what is a valid
> extension for one application and has the appropriate export
> manifest for that application would pollute the runtime of a
> different application. Maven may need to wrap a library that's meant
> as a generic plexus extension to support a Jetty-based appserver
> with something that would convert it to a Wagon implementation or
> something...in which case, exposing it as a generic embedded Jetty
> appserver inside of Maven's core could mess up plugins using the
> same library with a different version. In this case, the jetty
> component would be used internally by both the plugin and the maven
> extension component (the wagon impl), but the versions would
> conflict if they were shared...
>
Just reading this who do you think would say this is not complicated?
> Other uses of this component might be used to create a clustered
> plexus-driven appserver that uses the jetty component to send
> information across to other peers, for instance. In this case, the
> jetty component might need to run as a generic plexus extension.
>
> How could classworlds determine when the export manifest should or
> should not be used in this case?
>
ClassWorlds would not be determining anything, it's not going to
magically figure it out. But first ClassWorlds has no concept exports
and how are you going to control the Realms is my point. You
ultimately want to control the relationships between realms. Maven or
not how are you going to do that is my question. What put in a
classloader, how it relates to what's in a parent, or sibling, what
you mask is all generally the rules for doing this may be application
specific but this can be modeled in ClassWorlds.
>>
>>> 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?
>
>
> This isn't complicated at all; we have half of the solution in the
> DefaultMavenRealmManager already, to prevent all classes of an
> extension's dependency set from making their way into the core
> runtime.
Sorry, I simply don't buy that.
>
>
>>
>> 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.
>
> It's an oversimplification, when you take into account that
> classworlds is the basis for multiple applications, all of which
> share the same component framework. Artifacts are reused across the
> board, and may be used quite differently. See above for a
> hypothetical on that, or you could extrapolate a similar situation
> from the problems we've had using the scm wagon as an extension in
> maven, esp. when coupled with the release or scm plugins. You may
> discount the wagon scenario saying that the wagon should be a plugin-
> level dependency, but we don't have to narrow the example to wagon
> impls only.
>
>>
>>> 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?
>
> In the same way I'm handling controlled "export" of extension
> components now. Now, I read the component descriptors, grab the set
> of implementation classes from those, and import only those classes
> into the project realm for use in the rest of Maven. In this case,
> I'd simply be reading additional classes to be imported into this
> project realm from another manifest besides the one I'm currently
> using (the components.xml file). This is a dead simple solution, and
> it would be a very effective way for people to be explicit about
> which classes get added to maven's "core" runtime (the class realm
> used as a parent for all plugins building a particular project).
>
Which you basically added without much discussion, no proposal and
Milos' rightly nailed me the last time I tried that and that's
perfectly valid. You're doing much the same thing and it's you
yourself that asked that everything be done on a feature branch.
>>
>> 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.
>
> It's convenient to say that the scm wagon shouldn't ever be used as
> an extension, but that's sidestepping the real problem. What happens
> when we need to add the location of a particular SCM executable to
> the toolchains configuration?
>
> The dotnet toolchain extension is a great example of this sort of
> thing. I don't know what Shane was trying to add that the core
> toolchain interface couldn't support, but Milos has told me directly
> that the toolchain interfaces were designed to be extended by other
> interfaces (good component design for those intending to use the sub-
> interface methods)...these sub-interfaces aren't available under the
> current situation in 2.1, but they are in 2.0.x...as is everything
> else in the dependency chain for that extension, which creates
> problems with artifact versions, particularly when a plugin needs to
> use some of the classes that are in the dependency chain of one of
> these extensions. If the extension loads a helper component to do
> its job, and a plugin tries to load the same helper component but
> expects a different version (this could be as simple as a command-
> line generator that caches shell envars, btw), you're screwed.
>
> I've tried to informally introduce the concept of well-defined
> extension points in Maven by only allowing imports of implementation
> classes from extensions. This limits the use of these components to
> either the core interface it implements, or the extension-component
> class itself. However, as Shane's use case illustrates (backed up by
> Milos' intention that toolchain interfaces be extensible) this isn't
> enough. To fix the problem requires a VERY small change to maven.
>
> Generally, I don't have a problem with this sort of workflow for
> major design changes. But we're talking about a change to help
> transition from old functionality to new with LESS interruption to
> the user, and it will take fewer than 50 lines of code added to the
> DefaultMavenRealmManager to accomplish it.
I don't think this is a minor change, and it's not just 50 lines of
code. You already started doing a lot more work in the RealmManager
none of which is here:
http://docs.codehaus.org/display/MAVEN/Home
>
>
>>
>>> -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
>>>>>> brett@apache.org
>>>>>> http://blogs.exist.com/bporter/
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>
>>>>> ---
>>>>> 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: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>
>>> ---
>>> 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: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> ---
> 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
----------------------------------------------------------
Simplex sigillum veri. (Simplicity is the seal of truth.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [proposal] Controlling extension-exported classes
Posted by John Casey <jd...@commonjava.org>.
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.
The problem is that we may not always want to read the exports
manifest for a particular artifact. Take the case when an artifact is
sometimes a dependency that defers to another artifact (like a plugin
or an extension) but at other times is used as a plugin or extension
for a different application. In this case, what is a valid extension
for one application and has the appropriate export manifest for that
application would pollute the runtime of a different application.
Maven may need to wrap a library that's meant as a generic plexus
extension to support a Jetty-based appserver with something that
would convert it to a Wagon implementation or something...in which
case, exposing it as a generic embedded Jetty appserver inside of
Maven's core could mess up plugins using the same library with a
different version. In this case, the jetty component would be used
internally by both the plugin and the maven extension component (the
wagon impl), but the versions would conflict if they were shared...
Other uses of this component might be used to create a clustered
plexus-driven appserver that uses the jetty component to send
information across to other peers, for instance. In this case, the
jetty component might need to run as a generic plexus extension.
How could classworlds determine when the export manifest should or
should not be used in this case?
>
>> 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?
This isn't complicated at all; we have half of the solution in the
DefaultMavenRealmManager already, to prevent all classes of an
extension's dependency set from making their way into the core runtime.
>
> 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.
It's an oversimplification, when you take into account that
classworlds is the basis for multiple applications, all of which
share the same component framework. Artifacts are reused across the
board, and may be used quite differently. See above for a
hypothetical on that, or you could extrapolate a similar situation
from the problems we've had using the scm wagon as an extension in
maven, esp. when coupled with the release or scm plugins. You may
discount the wagon scenario saying that the wagon should be a plugin-
level dependency, but we don't have to narrow the example to wagon
impls only.
>
>> 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?
In the same way I'm handling controlled "export" of extension
components now. Now, I read the component descriptors, grab the set
of implementation classes from those, and import only those classes
into the project realm for use in the rest of Maven. In this case,
I'd simply be reading additional classes to be imported into this
project realm from another manifest besides the one I'm currently
using (the components.xml file). This is a dead simple solution, and
it would be a very effective way for people to be explicit about
which classes get added to maven's "core" runtime (the class realm
used as a parent for all plugins building a particular project).
>
> 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.
It's convenient to say that the scm wagon shouldn't ever be used as
an extension, but that's sidestepping the real problem. What happens
when we need to add the location of a particular SCM executable to
the toolchains configuration?
The dotnet toolchain extension is a great example of this sort of
thing. I don't know what Shane was trying to add that the core
toolchain interface couldn't support, but Milos has told me directly
that the toolchain interfaces were designed to be extended by other
interfaces (good component design for those intending to use the sub-
interface methods)...these sub-interfaces aren't available under the
current situation in 2.1, but they are in 2.0.x...as is everything
else in the dependency chain for that extension, which creates
problems with artifact versions, particularly when a plugin needs to
use some of the classes that are in the dependency chain of one of
these extensions. If the extension loads a helper component to do its
job, and a plugin tries to load the same helper component but expects
a different version (this could be as simple as a command-line
generator that caches shell envars, btw), you're screwed.
I've tried to informally introduce the concept of well-defined
extension points in Maven by only allowing imports of implementation
classes from extensions. This limits the use of these components to
either the core interface it implements, or the extension-component
class itself. However, as Shane's use case illustrates (backed up by
Milos' intention that toolchain interfaces be extensible) this isn't
enough. To fix the problem requires a VERY small change to maven.
Generally, I don't have a problem with this sort of workflow for
major design changes. But we're talking about a change to help
transition from old functionality to new with LESS interruption to
the user, and it will take fewer than 50 lines of code added to the
DefaultMavenRealmManager to accomplish it.
>
>> -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
>>>>> brett@apache.org
>>>>> http://blogs.exist.com/bporter/
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------
>>>>> ---
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>
>>>> ---
>>>> 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: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> ---
>> 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---
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
Re: [proposal] Controlling extension-exported classes
Posted by Jason van Zyl <ja...@maven.org>.
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
>>>>>> brett@apache.org
>>>>>> http://blogs.exist.com/bporter/
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>
>>>>> ---
>>>>> 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: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>
>>> ---
>>> 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: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> ---
> 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [proposal] Controlling extension-exported classes
Posted by John Casey <jd...@commonjava.org>.
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
>>>>> brett@apache.org
>>>>> http://blogs.exist.com/bporter/
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------
>>>>> ---
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>
>>>> ---
>>>> 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: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> ---
>> 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---
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
Re: [proposal] Controlling extension-exported classes
Posted by Jason van Zyl <ja...@maven.org>.
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
>>>> brett@apache.org
>>>> http://blogs.exist.com/bporter/
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>
>>> ---
>>> 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: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> ---
> 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [proposal] Controlling extension-exported classes
Posted by John Casey <jd...@commonjava.org>.
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).
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. 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.
-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
>>> brett@apache.org
>>> http://blogs.exist.com/bporter/
>>>
>>>
>>> --------------------------------------------------------------------
>>> -
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> ---
>> 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---
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
Re: [proposal] Controlling extension-exported classes
Posted by Jason van Zyl <ja...@maven.org>.
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 <ja...@maven.org>
>>> 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
>>>>>> brett@apache.org
>>>>>> http://blogs.exist.com/bporter/
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>
>>>>> ---
>>>>> 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: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> 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: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> ---
> 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [proposal] Controlling extension-exported classes
Posted by John Casey <jd...@commonjava.org>.
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 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.
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 <ja...@maven.org>
>> 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
>>>>> brett@apache.org
>>>>> http://blogs.exist.com/bporter/
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------
>>>>> ---
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>
>>>> ---
>>>> 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: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---
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
Re: [proposal] Controlling extension-exported classes
Posted by Jason van Zyl <ja...@maven.org>.
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 <ja...@maven.org>
> 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
>>>> brett@apache.org
>>>> http://blogs.exist.com/bporter/
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>
>>> ---
>>> 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: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [proposal] Controlling extension-exported classes
Posted by Milos Kleint <mk...@gmail.com>.
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 <ja...@maven.org> 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
> >> brett@apache.org
> >> http://blogs.exist.com/bporter/
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >
> > ---
> > 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [proposal] Controlling extension-exported classes
Posted by Jason van Zyl <ja...@maven.org>.
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
>> brett@apache.org
>> http://blogs.exist.com/bporter/
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> ---
> 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [proposal] Controlling extension-exported classes
Posted by John Casey <jd...@commonjava.org>.
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
> brett@apache.org
> http://blogs.exist.com/bporter/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---
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
Re: [proposal] Controlling extension-exported classes
Posted by Brett Porter <br...@apache.org>.
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
brett@apache.org
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org