You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Jörg Schaible <Jo...@Elsag-Solutions.com> on 2008/04/29 15:40:01 UTC
Plugin development & plexus-utils version
Hi folks,
developing a new plugin I made usage of plexus-utils 1.5.1. Unfortunately this fails when I try to run the plugin in a real project, because some classes seem outdated (missing method in FileUtils):
========= %< ============
[FATAL ERROR] com.elsagsolutions.buildsystem.maven2.plugin.templates.ActionMojo#execute() caused a linkage error (java.lang.NoSuchMethodError) and may be out-of-date. Check the realms:
[FATAL ERROR] Plugin realm = app0.child-container[com.elsagsolutions.buildsystem.maven2.plugin:es-template-maven2-plugin]
urls[0] = file:/d:/repository/m2/com/elsagsolutions/buildsystem/maven2/plugin/es-template-maven2-plugin/1.0-SNAPSHOT/es-template-maven2-plugin-1.0-SNAPSHOT.jar
urls[1] = file:/d:/repository/m2/org/codehaus/plexus/plexus-utils/1.1/plexus-utils-1.1.jar
[FATAL ERROR] Container realm = plexus.core
urls[0] = file:/c:/Programme/Apache Software Foundation/Maven 2.0.9/lib/maven-2.0.9-uber.jar
[INFO] ------------------------------------------------------------------------
[ERROR] FATAL ERROR
[INFO] ------------------------------------------------------------------------
[INFO] org.codehaus.plexus.util.FileUtils.copyDirectoryStructureIfModified(Ljava/io/File;Ljava/io/File;)V
========= %< ============
Do I interpret this right, that I am stuck with plexus-utils 1.1 despite the deps declared for my plugin?
- Jörg
BTW: http://maven.apache.org/guides/mini/guide-maven-classloading.html is outdated. There is no core directory anymore and lib contains the uber jar.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Plugin development & plexus-utils version
Posted by Benjamin Bentmann <be...@udo.edu>.
Jörg Schaible wrote:
> Maybe a new scope
+1 on that instead of some time-consuming ASM post analysis and POM
rewriting.
Benjamin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Plugin development & plexus-utils version
Posted by Jörg Schaible <jo...@gmx.de>.
On Mittwoch, 30. April 2008, William Ferguson wrote:
> As Benjamin points out at the end of that Jira, the current behaviour is
there to deal with use of libraries containing classes that extend classes in
other libraries.
>
> Seems to me that we need a way to differentiate in our projects which
dependencies need to get *exported* as compile dependencies and which can get
exported as runtime depedencies.
>
> Projects that don't use implementation inheritance will be able to trim down
their exported compile time dependencies to nil.
>
> Implementation inheritance of any class relegates that class's library to
being exported as a compile time dep, otherwise the library is exported as a
runtime dep.
Maybe a new scope: private or hidden
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Plugin development & plexus-utils version
Posted by Tom Huybrechts <to...@gmail.com>.
That's way too much magic. I'd rather have an explicit
<exported>true\false</exported> flag.
dependency:analyze could check this if desired.
On Wed, Apr 30, 2008 at 4:31 AM, Brian E. Fox <br...@reply.infinity.nu> wrote:
> It seems like we would need an ASM based post processor to analyze it before generating the pom that gets deployed.
>
>
> -----Original Message-----
> From: William Ferguson [mailto:William.Ferguson@yarris.com]
> Sent: Tuesday, April 29, 2008 7:01 PM
> To: Maven Developers List; joerg.schaible@gmx.de
> Subject: Re: Plugin development & plexus-utils version
>
> As Benjamin points out at the end of that Jira, the current behaviour is there to deal with use of libraries containing classes that extend classes in other libraries.
>
> Seems to me that we need a way to differentiate in our projects which dependencies need to get *exported* as compile dependencies and which can get exported as runtime depedencies.
>
> Projects that don't use implementation inheritance will be able to trim down their exported compile time dependencies to nil.
>
> Implementation inheritance of any class relegates that class's library to being exported as a compile time dep, otherwise the library is exported as a runtime dep.
>
> William
>
>
> > -----Original Message-----
> > From: news [mailto:news@ger.gmane.org] On Behalf Of Jörg Schaible
> > Sent: Wednesday, 30 April 2008 7:20 AM
> > To: dev@maven.apache.org
> > Subject: Re: Plugin development &
> > plexus-utils version - Sender is forged (SPF Fail)
> >
> > Well, I requested long ago a setting for maven to inherit all
> > deps as runtime by default ... :-)
> >
> > http://jira.codehaus.org/browse/MNG-2589
> >
> > - Jörg
>
> ---------------------------------------------------------------------
> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: Plugin development & plexus-utils version
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
It seems like we would need an ASM based post processor to analyze it before generating the pom that gets deployed.
-----Original Message-----
From: William Ferguson [mailto:William.Ferguson@yarris.com]
Sent: Tuesday, April 29, 2008 7:01 PM
To: Maven Developers List; joerg.schaible@gmx.de
Subject: Re: Plugin development & plexus-utils version
As Benjamin points out at the end of that Jira, the current behaviour is there to deal with use of libraries containing classes that extend classes in other libraries.
Seems to me that we need a way to differentiate in our projects which dependencies need to get *exported* as compile dependencies and which can get exported as runtime depedencies.
Projects that don't use implementation inheritance will be able to trim down their exported compile time dependencies to nil.
Implementation inheritance of any class relegates that class's library to being exported as a compile time dep, otherwise the library is exported as a runtime dep.
William
> -----Original Message-----
> From: news [mailto:news@ger.gmane.org] On Behalf Of Jörg Schaible
> Sent: Wednesday, 30 April 2008 7:20 AM
> To: dev@maven.apache.org
> Subject: Re: Plugin development &
> plexus-utils version - Sender is forged (SPF Fail)
>
> Well, I requested long ago a setting for maven to inherit all
> deps as runtime by default ... :-)
>
> http://jira.codehaus.org/browse/MNG-2589
>
> - Jörg
---------------------------------------------------------------------
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: Plugin development & plexus-utils version
Posted by William Ferguson <Wi...@yarris.com>.
As Benjamin points out at the end of that Jira, the current behaviour is there to deal with use of libraries containing classes that extend classes in other libraries.
Seems to me that we need a way to differentiate in our projects which dependencies need to get *exported* as compile dependencies and which can get exported as runtime depedencies.
Projects that don't use implementation inheritance will be able to trim down their exported compile time dependencies to nil.
Implementation inheritance of any class relegates that class's library to being exported as a compile time dep, otherwise the library is exported as a runtime dep.
William
> -----Original Message-----
> From: news [mailto:news@ger.gmane.org] On Behalf Of Jörg Schaible
> Sent: Wednesday, 30 April 2008 7:20 AM
> To: dev@maven.apache.org
> Subject: Re: Plugin development &
> plexus-utils version - Sender is forged (SPF Fail)
>
> Well, I requested long ago a setting for maven to inherit all
> deps as runtime by default ... :-)
>
> http://jira.codehaus.org/browse/MNG-2589
>
> - Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Plugin development & plexus-utils version
Posted by Jörg Schaible <jo...@gmx.de>.
Benjamin Bentmann wrote:
>> Solved, the dependency was inherited transitively by
>> maven-artifact-2.0.9.
>
> You should never rely on transitive dependencies if you directly use its
> classes/methods in your code but always declare them directly. The goal
> dependency:analyze
> can help you a big deal in ensuring all your dependencies are properly
> declared.
Well, I requested long ago a setting for maven to inherit all deps as
runtime by default ... :-)
http://jira.codehaus.org/browse/MNG-2589
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Plugin development & plexus-utils version
Posted by Benjamin Bentmann <be...@udo.edu>.
> Solved, the dependency was inherited transitively by maven-artifact-2.0.9.
You should never rely on transitive dependencies if you directly use its
classes/methods in your code but always declare them directly. The goal
dependency:analyze
can help you a big deal in ensuring all your dependencies are properly
declared.
Benjamin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: Plugin development & plexus-utils version
Posted by Jörg Schaible <Jo...@Elsag-Solutions.com>.
Jörg Schaible wrote:
> Hi folks,
>
> developing a new plugin I made usage of plexus-utils 1.5.1.
> Unfortunately this fails when I try to run the plugin in a
> real project, because some classes seem outdated (missing method in
> FileUtils):
>
> ========= %< ============
> [FATAL ERROR]
> com.elsagsolutions.buildsystem.maven2.plugin.templates.ActionM
> ojo#execute() caused a linkage error
> (java.lang.NoSuchMethodError) and may be out-of-date. Check the
> realms: [FATAL ERROR] Plugin realm =
> app0.child-container[com.elsagsolutions.buildsystem.maven2.plu
> gin:es-template-maven2-plugin]
> urls[0] =
> file:/d:/repository/m2/com/elsagsolutions/buildsystem/maven2/p
> lugin/es-template-maven2-plugin/1.0-SNAPSHOT/es-template-maven
> 2-plugin-1.0-SNAPSHOT.jar urls[1] =
> file:/d:/repository/m2/org/codehaus/plexus/plexus-utils/1.1/pl
> exus-utils-1.1.jar [FATAL ERROR] Container realm = plexus.core
> urls[0] = file:/c:/Programme/Apache Software Foundation/Maven
> 2.0.9/lib/maven-2.0.9-uber.jar
> [INFO]
> --------------------------------------------------------------
> ----------
> [ERROR] FATAL ERROR
> [INFO]
> --------------------------------------------------------------
> ----------
> [INFO]
> org.codehaus.plexus.util.FileUtils.copyDirectoryStructureIfMod
> ified(Ljava/io/File;Ljava/io/File;)V
> ========= %< ============
>
> Do I interpret this right, that I am stuck with plexus-utils
> 1.1 despite the deps declared for my plugin?
Solved, the dependency was inherited transitively by maven-artifact-2.0.9. As soon as I declared plexus-utils-1.5.1 as direct dependency the newer classes have been found and the plugin worked as expected.
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org