You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Brett Porter <br...@apache.org> on 2005/07/22 12:30:09 UTC
build extensions vs plugins
Hi,
Ref: MNG-598, MNG-226
We have "build extensions" - ie providers for wagon, scm that are not
really plugins but additional providers for a particular plexus role.
Currently, these need to be dropped into M2_HOME/lib along with their
dependencies which is not ideal. (SCM ones can be a dependency on the
SCM/release plugin, but there is no scope to later add a new one). In
the future, repository metadata might help us locate plexus components
with a particular role and role hint, but this will hold us over until then.
While we should still make the "standard" ones available out of the box,
it needs to be easy to add more via the project in a reproducible way,
so I propose:
<build>
<extensions>
<extension>
<groupId>org.apache.maven.wagon</groupId>
<artifactId>wagon-ftp</artifactId>
<version>1.0-alpha-4</version>
</extension>
</extensions>
</build>
This is here instead of in dependencies for clarity and so that you can
use them both as an extension and as a dependency without having to
worry about matching versions or scope.
Extensions are:
- inherited from the parent
- have NO configuration
- the version can be omitted (use RELEASE) or use ranges like a plugin
and will be populated by the release plugin
At execution, it needs to be available to the core code (eg
DefaultWagonManager), and also particular plugins (eg maven-scm-plugin).
For now, I just intend to push the extensions into the core classloader.
I think we might eventually need to construct a per-project execution
realm as a basis for plugin realms and recreate those plugin realms for
each project (currently it is only ever created for one plugin - so
mutliple versions of a plugin might have problems).
This would be very inconvenient for adding plugins that provide type and
packaging handlers, but we don't want to have to resolve and search all
the plugins to find a missing dependency type. For this, we can add
<extensions>true|false</extensions> to the <plugin/> element, eg:
<plugin>
<groupId>org.codehaus.plexus</groupId>
<artifactId>plexus-maven-plugin</artifactId>
<extensions>true</extensions>
<configuration>
...
</configuration>
</plugin>
This will indicate to the plugin manager to pre-load those plugins, and
to search it for any plexus components. When the lifecycle executor is
looking for a packaging handler, it will have to search those plugin
containers also.
How does this sound?
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: build extensions vs plugins
Posted by John Casey <jd...@commonjava.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
+1, esp. the last bit about the new plugin element.
Brett Porter wrote:
| Hi,
|
| Ref: MNG-598, MNG-226
|
| We have "build extensions" - ie providers for wagon, scm that are not
| really plugins but additional providers for a particular plexus role.
| Currently, these need to be dropped into M2_HOME/lib along with their
| dependencies which is not ideal. (SCM ones can be a dependency on the
| SCM/release plugin, but there is no scope to later add a new one). In
| the future, repository metadata might help us locate plexus components
| with a particular role and role hint, but this will hold us over until
then.
|
| While we should still make the "standard" ones available out of the box,
| it needs to be easy to add more via the project in a reproducible way,
| so I propose:
|
| <build>
| <extensions>
| <extension>
| <groupId>org.apache.maven.wagon</groupId>
| <artifactId>wagon-ftp</artifactId>
| <version>1.0-alpha-4</version>
| </extension>
| </extensions>
| </build>
|
| This is here instead of in dependencies for clarity and so that you can
| use them both as an extension and as a dependency without having to
| worry about matching versions or scope.
| Extensions are:
| - inherited from the parent
| - have NO configuration
| - the version can be omitted (use RELEASE) or use ranges like a plugin
| and will be populated by the release plugin
|
| At execution, it needs to be available to the core code (eg
| DefaultWagonManager), and also particular plugins (eg maven-scm-plugin).
| For now, I just intend to push the extensions into the core classloader.
| I think we might eventually need to construct a per-project execution
| realm as a basis for plugin realms and recreate those plugin realms for
| each project (currently it is only ever created for one plugin - so
| mutliple versions of a plugin might have problems).
|
| This would be very inconvenient for adding plugins that provide type and
| packaging handlers, but we don't want to have to resolve and search all
| the plugins to find a missing dependency type. For this, we can add
| <extensions>true|false</extensions> to the <plugin/> element, eg:
|
| <plugin>
| <groupId>org.codehaus.plexus</groupId>
| <artifactId>plexus-maven-plugin</artifactId>
| <extensions>true</extensions>
| <configuration>
| ...
| </configuration>
| </plugin>
|
| This will indicate to the plugin manager to pre-load those plugins, and
| to search it for any plexus components. When the lifecycle executor is
| looking for a packaging handler, it will have to search those plugin
| containers also.
|
| How does this sound?
|
| - Brett
|
| ---------------------------------------------------------------------
| To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
| For additional commands, e-mail: dev-help@maven.apache.org
|
|
|
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFC4R+GK3h2CZwO/4URAmscAJ0dwTgdEuG990qV9ff1fMfrnNe/9ACgmb38
rM0R/zztaiZHegZeiTMrb2M=
=vUKH
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: build extensions vs plugins
Posted by Emmanuel Venisse <em...@venisse.net>.
this sound is ok for me.
Emmanuel
Brett Porter wrote:
> Hi,
>
> Ref: MNG-598, MNG-226
>
> We have "build extensions" - ie providers for wagon, scm that are not
> really plugins but additional providers for a particular plexus role.
> Currently, these need to be dropped into M2_HOME/lib along with their
> dependencies which is not ideal. (SCM ones can be a dependency on the
> SCM/release plugin, but there is no scope to later add a new one). In
> the future, repository metadata might help us locate plexus components
> with a particular role and role hint, but this will hold us over until then.
>
> While we should still make the "standard" ones available out of the box,
> it needs to be easy to add more via the project in a reproducible way,
> so I propose:
>
> <build>
> <extensions>
> <extension>
> <groupId>org.apache.maven.wagon</groupId>
> <artifactId>wagon-ftp</artifactId>
> <version>1.0-alpha-4</version>
> </extension>
> </extensions>
> </build>
>
> This is here instead of in dependencies for clarity and so that you can
> use them both as an extension and as a dependency without having to
> worry about matching versions or scope.
> Extensions are:
> - inherited from the parent
> - have NO configuration
> - the version can be omitted (use RELEASE) or use ranges like a plugin
> and will be populated by the release plugin
>
> At execution, it needs to be available to the core code (eg
> DefaultWagonManager), and also particular plugins (eg maven-scm-plugin).
> For now, I just intend to push the extensions into the core classloader.
> I think we might eventually need to construct a per-project execution
> realm as a basis for plugin realms and recreate those plugin realms for
> each project (currently it is only ever created for one plugin - so
> mutliple versions of a plugin might have problems).
>
> This would be very inconvenient for adding plugins that provide type and
> packaging handlers, but we don't want to have to resolve and search all
> the plugins to find a missing dependency type. For this, we can add
> <extensions>true|false</extensions> to the <plugin/> element, eg:
>
> <plugin>
> <groupId>org.codehaus.plexus</groupId>
> <artifactId>plexus-maven-plugin</artifactId>
> <extensions>true</extensions>
> <configuration>
> ...
> </configuration>
> </plugin>
>
> This will indicate to the plugin manager to pre-load those plugins, and
> to search it for any plexus components. When the lifecycle executor is
> looking for a packaging handler, it will have to search those plugin
> containers also.
>
> How does this sound?
>
> - Brett
>
> ---------------------------------------------------------------------
> 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: build extensions vs plugins
Posted by Jason van Zyl <ja...@maven.org>.
On Fri, 2005-07-22 at 20:30 +1000, Brett Porter wrote:
> Hi,
> How does this sound?
+1
> - Brett
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
jvz.
Jason van Zyl
jason at maven.org
http://maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: build extensions vs plugins
Posted by Trygve Laugstøl <tr...@codehaus.org>.
On Fri, Jul 22, 2005 at 08:30:09PM +1000, Brett Porter wrote:
> Hi,
>
> Ref: MNG-598, MNG-226
>
> How does this sound?
+1
--
Trygve