|
»
»
»
Plugin development & plexus-utils version
|
View:
New views
9 Messages
—
Rating Filter:
Alert me
|
 |
Plugin development & plexus-utils version
by Jörg Schaible
::
Rate this Message:
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@... For additional commands, e-mail: dev-help@... |
|
|
RE: Plugin development & plexus-utils version
by Jörg Schaible
::
Rate this Message:
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@... For additional commands, e-mail: dev-help@... |
|
|
Re: Plugin development & plexus-utils version
by Benjamin Bentmann
::
Rate this Message:
> 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@... For additional commands, e-mail: dev-help@... |
|
|
Re: Plugin development & plexus-utils version
by Jörg Schaible-2
::
Rate this Message:
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@... For additional commands, e-mail: dev-help@... |
|
|
Re: Plugin development & plexus-utils version
by William Ferguson
::
Rate this Message:
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@...] On Behalf Of Jörg Schaible > Sent: Wednesday, 30 April 2008 7:20 AM > To: dev@... > 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@... For additional commands, e-mail: dev-help@... |
|
|
RE: Plugin development & plexus-utils version
by Brian E Fox
::
Rate this Message:
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@...] Sent: Tuesday, April 29, 2008 7:01 PM To: Maven Developers List; joerg.schaible@... 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@...] On Behalf Of Jörg Schaible > Sent: Wednesday, 30 April 2008 7:20 AM > To: dev@... > 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@... For additional commands, e-mail: dev-help@... --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: Plugin development & plexus-utils version
by Jörg Schaible-2
::
Rate this Message:
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@... For additional commands, e-mail: dev-help@... |
|
|
Re: Plugin development & plexus-utils version
by TomHuybrechts
::
Rate this Message:
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 <brianf@...> 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@...] > Sent: Tuesday, April 29, 2008 7:01 PM > To: Maven Developers List; joerg.schaible@... > 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@...] On Behalf Of Jörg Schaible > > Sent: Wednesday, 30 April 2008 7:20 AM > > To: dev@... > > 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@... > For additional commands, e-mail: dev-help@... > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@... > For additional commands, e-mail: dev-help@... > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: Plugin development & plexus-utils version
by Benjamin Bentmann
::
Rate this Message:
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@... For additional commands, e-mail: dev-help@... |
| Free Forum Powered by Nabble | Forum Help |