i'm not convinced it can be solved on the classworlds level alone. The import of single packages needs to be done for a whole tree of jars that the extension depends on. And it needs to be defined in one place and that is the extension jar. The classworlds-internal solution doesn't have any idea about these constraints. But of course classworlds need to have means of restricting access to certain packages.. Not usre if the current importFrom() methods fulfils the requirements.
Milos On Tue, Mar 11, 2008 at 7:23 AM, Jason van Zyl <[EMAIL PROTECTED]> wrote: > I would highly recommend not doing this in Maven first and actually > prototyping something with Plexus and ClassWorlds and it is something > general and simple to start. > > This is not a Maven specific thing. After sifting through the plugin > code to try and see how to generalize the mechanism it is painfully > obviously that what's buried in Maven is really general. I would try > it with some simple examples in ClassWorlds as not to get bogged downI'm not > in Maven specifics at first even though that it the ultimate target. I > would also recommend enlisting the opinion of Dain if he's not on this > list because he's done a lot of this classloader work and has lots of > good ideas and has attempt to make OSGi like classloaders for just the > purpose you're talking about. > > Any file that is read to limit/restrict the classloader/realm should > be in classworlds. > > > > On 10-Mar-08, at 1:27 PM, John Casey wrote: > > > I'm not entirely sure how to generalize it into plexus just yet, > > since I'm jumping through some pretty complex ClassRealm-management > > hoops in Maven right now. I'm not sure how I'd even start telling > > Plexus to do that atm. The place in the current trunk implementation > > to add this stuff is in Maven. > > > > -john > > > > On Mar 10, 2008, at 4:02 PM, Brett Porter wrote: > > > >> > >> On 11/03/2008, at 6:52 AM, John Casey wrote: > >> > >>> I'd propose to resolve this using a mechanism borrowed from OSGi: > >>> we should create some sort of manifest of classes to be exported > >>> from the extension for use by the rest of Maven. This file could > >>> be optional, and the existing behavior would result. But if the > >>> file were present, it would name all the classes (and class > >>> patterns?) in the extension artifact (and possibly its > >>> dependencies) to "export" into the main maven ClassRealm(s) for > >>> use by plugins. This is a relatively small change to Maven's > >>> extension mechanism for 2.1, and would restore many of the best > >>> features of the old extension functionality without incurring the > >>> blind incompatibilities of the old system. > >>> > >>> Anyone have any thoughts on this? > >> > >> It was really off the top of my head, but it sounds like the right > >> approach. So you're saying this would be a maven specific feature, > >> not a general plexus one? > >> > >> - Brett > >> > >> -- > >> Brett Porter > >> [EMAIL PROTECTED] > >> http://blogs.exist.com/bporter/ > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > > > > --- > > John Casey > > Committer and PMC Member, Apache Maven > > mail: jdcasey at commonjava dot org > > blog: http://www.ejlife.net/blogs/john > > rss: http://feeds.feedburner.com/ejlife/john > > > > > > Thanks, > > Jason > > ---------------------------------------------------------- > Jason van Zyl > Founder, Apache Maven > jason at sonatype dot com > ---------------------------------------------------------- > > happiness is like a butterfly: the more you chase it, the more it will > elude you, but if you turn your attention to other things, it will come > and sit softly on your shoulder ... > > -- Thoreau > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
