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
[EMAIL PROTECTED]
http://blogs.exist.com/bporter/
------------------------------------------------------------------
---
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---
John Casey
Committer and PMC Member, Apache Maven
mail: jdcasey at commonjava dot org
blog: http://www.ejlife.net/blogs/john
rss: http://feeds.feedburner.com/ejlife/john
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
happiness is like a butterfly: the more you chase it, the more it
will
elude you, but if you turn your attention to other things, it
will come
and sit softly on your shoulder ...
-- Thoreau
--------------------------------------------------------------------
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---
John Casey
Committer and PMC Member, Apache Maven
mail: jdcasey at commonjava dot org
blog: http://www.ejlife.net/blogs/john
rss: http://feeds.feedburner.com/ejlife/john
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
Our achievements speak for themselves. What we have to keep track
of are our failures, discouragements and doubts. We tend to forget
the past difficulties, the many false starts, and the painful
groping. We see our past achievements as the end result of a
clean forward thrust, and our present difficulties as
signs of decline and decay.
-- Eric Hoffer, Reflections on the Human Condition
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---
John Casey
Committer and PMC Member, Apache Maven
mail: jdcasey at commonjava dot org
blog: http://www.ejlife.net/blogs/john
rss: http://feeds.feedburner.com/ejlife/john
