update

[Jason van Zyl <jv...@maven.org>]

Howdy,

I am going to try and check in the changes I have today but I might not
get there so I figured I would just drop a line about what's going on.
Currently in the code I have I have managed to get the following
working:

o Tranparent plugin downloading: so when you request the execution of a
goal the plugin is checked for, if it is not present it is downloaded
along with all plugins it may depend on as well as all the required
dependencies.

o Plugins working from the local repository: there are no plugins
deployed with m2 at all now. All plugins are treated equally and they
are used from the local repository. The above mentioned process pulls
all plugins into the local repository and uses them from there.

o Plugin isolation: when a plugin is added to the system all the
dependencies of the plugin are used to populate a ClassWorlds ClassRealm
which is stored for use at a time when a goal from the plugin needs to
be executed. This is essentially a feature of plexus which is being
utilized in m2.

I've have tried a few little experiments but I can start with the m2
distribution and have no plugins in my local repository and everything
seems to be working well. This now means that all the mojos we have will
be automatically and transparently available.

I will doing some cleanup and doco and making sure all the integration
tests work and I hope to get this in today or tomorrow sometime.


-- 
jvz.

Jason van Zyl
jason@maven.org
http://maven.apache.org

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 

Re: update

[Brett Porter <br...@apache.org>]

Quoting Jason van Zyl <jv...@maven.org>:

> On Tue, 2004-08-03 at 18:16, Brett Porter wrote:
> > Sounds very cool.
> > 
> > Will there still be a way to distribute standard ones? 
> 
> I don't really see why we need to. I want to fully decouple the
> lifecycle of the plugins from the core and this is now entirely
> possible.
> 
> > Perhaps the installer can unpack a local 
> > repository?
> 
> The first time someone goes to use it everything will come down that's
> required.

I'd like there to be a way to do it offline, somehow. I'll probably add it myself like I did with 
m1 (but much less ad hoc and crappy :)

> > How does version resolution work? How about updating when a new release
> comes out?
> 
> The rough sketch:
> 
> There will be a <plugins/> element in the POM to control the versions
> and configurations for plugins.
> 
> o if no where in the model hierarchy a version for a particular plugin
> is not specified the latest version of the plugin will be used (we'll
> have a little text file akin to the snapshot-version file). Somehow,
> once maven selects this latest version some POM will be updated to
> reflect the use of.
> 
> o to use a new version of a plugin all you would have to do is update
> your POM, or we could have something to help users update the POM. Could
> do a little search for available versions, let them pick, and update the
> POM. From that point forward the version specified in the POM will be
> used.

What about non-project affiliated plugins, like idea? Does this go in a "user POM"? That 
sounds like the best choice.

For the snapshotted plugins, will they be checked every time, or just when you run a 
command? I'd say the second, perhaps with a flag in the POM to make some be done every 
time.

Does this mean there are no more plugin dependencies? You just use the plugin element?

Cheers
Brett

Re: update

[Jason van Zyl <jv...@maven.org>]

On Tue, 2004-08-03 at 18:16, Brett Porter wrote:
> Sounds very cool.
> 
> Will there still be a way to distribute standard ones? 

I don't really see why we need to. I want to fully decouple the
lifecycle of the plugins from the core and this is now entirely
possible.

> Perhaps the installer can unpack a local 
> repository?

The first time someone goes to use it everything will come down that's
required.

> How does version resolution work? How about updating when a new release comes out?

The rough sketch:

There will be a <plugins/> element in the POM to control the versions
and configurations for plugins.

o if no where in the model hierarchy a version for a particular plugin
is not specified the latest version of the plugin will be used (we'll
have a little text file akin to the snapshot-version file). Somehow,
once maven selects this latest version some POM will be updated to
reflect the use of.

o to use a new version of a plugin all you would have to do is update
your POM, or we could have something to help users update the POM. Could
do a little search for available versions, let them pick, and update the
POM. From that point forward the version specified in the POM will be
used.

Currently the ClassRealms that are created are keyed by the plexus
componentKey so with a slight modification I'll take into consideration
the version of a component, in our case a plugins, so that multiple
versions of the same plugins can execute without consequence.


-- 
jvz.

Jason van Zyl
jason@maven.org
http://maven.apache.org

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 

Re: update

[Brett Porter <br...@apache.org>]

Sounds very cool.

Will there still be a way to distribute standard ones? Perhaps the installer can unpack a local 
repository?

How does version resolution work? How about updating when a new release comes out?

Cheers,
Brett

Quoting Jason van Zyl <jv...@maven.org>:

> Howdy,
> 
> I am going to try and check in the changes I have today but I might not
> get there so I figured I would just drop a line about what's going on.
> Currently in the code I have I have managed to get the following
> working:
> 
> o Tranparent plugin downloading: so when you request the execution of a
> goal the plugin is checked for, if it is not present it is downloaded
> along with all plugins it may depend on as well as all the required
> dependencies.
> 
> o Plugins working from the local repository: there are no plugins
> deployed with m2 at all now. All plugins are treated equally and they
> are used from the local repository. The above mentioned process pulls
> all plugins into the local repository and uses them from there.
> 
> o Plugin isolation: when a plugin is added to the system all the
> dependencies of the plugin are used to populate a ClassWorlds ClassRealm
> which is stored for use at a time when a goal from the plugin needs to
> be executed. This is essentially a feature of plexus which is being
> utilized in m2.
> 
> I've have tried a few little experiments but I can start with the m2
> distribution and have no plugins in my local repository and everything
> seems to be working well. This now means that all the mojos we have will
> be automatically and transparently available.
> 
> I will doing some cleanup and doco and making sure all the integration
> tests work and I hope to get this in today or tomorrow sometime.
> 
> 
> -- 
> jvz.
> 
> Jason van Zyl
> jason@maven.org
> http://maven.apache.org
> 
> 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 
> 

Re: update

[Emmanuel Venisse <em...@venisse.net>]

I'm impatient to see it.

Emmanuel

----- Original Message ----- 
From: "Jason van Zyl" <jv...@maven.org>
To: "Maven 2 Developers List" <m2...@maven.apache.org>
Sent: Tuesday, August 03, 2004 6:29 PM
Subject: update


> Howdy,
> 
> I am going to try and check in the changes I have today but I might not
> get there so I figured I would just drop a line about what's going on.
> Currently in the code I have I have managed to get the following
> working:
> 
> o Tranparent plugin downloading: so when you request the execution of a
> goal the plugin is checked for, if it is not present it is downloaded
> along with all plugins it may depend on as well as all the required
> dependencies.
> 
> o Plugins working from the local repository: there are no plugins
> deployed with m2 at all now. All plugins are treated equally and they
> are used from the local repository. The above mentioned process pulls
> all plugins into the local repository and uses them from there.
> 
> o Plugin isolation: when a plugin is added to the system all the
> dependencies of the plugin are used to populate a ClassWorlds ClassRealm
> which is stored for use at a time when a goal from the plugin needs to
> be executed. This is essentially a feature of plexus which is being
> utilized in m2.
> 
> I've have tried a few little experiments but I can start with the m2
> distribution and have no plugins in my local repository and everything
> seems to be working well. This now means that all the mojos we have will
> be automatically and transparently available.
> 
> I will doing some cleanup and doco and making sure all the integration
> tests work and I hope to get this in today or tomorrow sometime.
> 
> 
> -- 
> jvz.
> 
> Jason van Zyl
> jason@maven.org
> http://maven.apache.org
> 
> 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 
> 
> 

Re: update

[Jason van Zyl <jv...@maven.org>]

On Tue, 2004-08-03 at 12:38, John Casey wrote:
> > o Plugin isolation: when a plugin is added to the system all the
> > dependencies of the plugin are used to populate a ClassWorlds ClassRealm
> > which is stored for use at a time when a goal from the plugin needs to
> > be executed. This is essentially a feature of plexus which is being
> > utilized in m2.
> 
> will each plugin have access to it's classloader/classworld/realm? This
> would be nice to allow resource loading relative to that
> realm/whatever...otherwise, it would be nice if we could use something
> like:

The ClassRealm is created, the plugin and all its dependencies are
placed in the Realm and the plugin is then instantiated with that
ClassRealm. So, yes the plugin will have access to any resources in the
ClassRealm which includes stuff packaged in the plugin itself.

The xdoc plugin has mojos that access all the resources required for
xdoc generation using getResource/getResourceAsStream. The plugins
aren't unpacked so this type of use is a must.

> // the name of this plugin class, in resource format
> String myClassName = myPluginClass.class.getName().replace('.', '/') +
> ".class";
> 
> // retrieve the resource for this plugin class
> URL url = getClass().getClassLoader().getResource(myClassName);
> 
> // get the full URL of the plugin class
> String resourcesBase = url.toExternalForm();
> 
> // now trim to get the jar from which this plugin was loaded.
> resourcesBase = resourcesBase.substring(0, resourcesBase.indexOf("!"));
> 
> URL myResource = new URL(resourcesBase + myResourceName);
> myResource.openStream();
> ...
> 
> Thoughts?
> 
> -john

-- 
jvz.

Jason van Zyl
jason@maven.org
http://maven.apache.org

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 

Re: update

[John Casey <jd...@commonjava.org>]

> o Plugin isolation: when a plugin is added to the system all the
> dependencies of the plugin are used to populate a ClassWorlds ClassRealm
> which is stored for use at a time when a goal from the plugin needs to
> be executed. This is essentially a feature of plexus which is being
> utilized in m2.

will each plugin have access to it's classloader/classworld/realm? This
would be nice to allow resource loading relative to that
realm/whatever...otherwise, it would be nice if we could use something
like:

// the name of this plugin class, in resource format
String myClassName = myPluginClass.class.getName().replace('.', '/') +
".class";

// retrieve the resource for this plugin class
URL url = getClass().getClassLoader().getResource(myClassName);

// get the full URL of the plugin class
String resourcesBase = url.toExternalForm();

// now trim to get the jar from which this plugin was loaded.
resourcesBase = resourcesBase.substring(0, resourcesBase.indexOf("!"));

URL myResource = new URL(resourcesBase + myResourceName);
myResource.openStream();
...

Thoughts?

-john