[jira] Reopened: (MNG-3014) java.lang.NoClassDefFoundError: com/bea/wlw/filesystem/IFileFilter getting this error while running "APPC"
[ http://jira.codehaus.org/browse/MNG-3014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Debabrat reopened MNG-3014: --- hi Brett Porter I posted this issue because i am getting error while running weblogic:appc using weblogic-maven-plugin. How can you say this is not regarding maven. While running weblogic:appc using maven i am getting the error the weblogic:appc working fine with ANT Deb > java.lang.NoClassDefFoundError: com/bea/wlw/filesystem/IFileFilter getting > this error while running "APPC" > --- > > Key: MNG-3014 > URL: http://jira.codehaus.org/browse/MNG-3014 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.0.4 > Environment: window xp,maven 2.0.4 >Reporter: Debabrat > > Hello -- > I'm building my application using weblogic9.2 and am up to the part where > weblogic.appc ant task kicks in. I get the following error message: > [ > <[ComplianceChecker] Check > ing servlet-mapping for servlet name : "ImageViewer".> > [jspc] -webapp specified, searching . for JSPs > java.lang.NoClassDefFoundError: com/bea/wlw/filesystem/IFileFilter > at weblogic.servlet.jsp.jspc20.runBodyInternal(jspc20.java:420) > at weblogic.servlet.jsp.jspc20.runJspc(jspc20.java:195) > at weblogic.servlet.jsp.JspcInvoker.compile(JspcInvoker.java:239) > at > weblogic.application.compiler.AppcUtils.compileWAR(AppcUtils.java:353) > at > weblogic.application.compiler.WARCompiler.compile(WARCompiler.java:78) > at > weblogic.application.compiler.flow.AppCompilerFlow.compileInput(AppCompi > lerFlow.java:118) > at > weblogic.application.compiler.flow.AppCompilerFlow.compile(AppCompilerFl > ow.java:43) > at > weblogic.application.compiler.FlowDriver$FlowStateChange.next(FlowDriver > .java:69) > at > weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriv > er.java:26) > at > weblogic.application.compiler.FlowDriver.nextState(FlowDriver.java:36) > at weblogic.application.compiler.FlowDriver.run(FlowDriver.java:26) > at weblogic.application.compiler.Appc.runBody(Appc.java:163) > at weblogic.utils.compiler.Tool.run(Tool.java:158) > at weblogic.utils.compiler.Tool.run(Tool.java:115) > at weblogic.application.compiler.Appc.main(Appc.java:174) > at weblogic.appc.main(appc.java:14) > at org.codehaus.mojo.weblogic.AppcMojo.execute(AppcMojo.java:129) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginMa > nager.java:412) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Default > LifecycleExecutor.java:534) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifec > ycle(DefaultLifecycleExecutor.java:475) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultL > ifecycleExecutor.java:454) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandle > Failures(DefaultLifecycleExecutor.java:306) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments( > DefaultLifecycleExecutor.java:273) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifec > ycleExecutor.java:140) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav > a:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor > Impl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > [ERROR] Exception encountered during APPC processing > java.lang.NoClassDefFoundError: com/bea/wlw/filesystem/IFileFilter > at weblogic.servlet.jsp.jspc20.runBodyInternal(jspc20.java:420) > at weblogic.servlet.jsp.jspc20.runJspc(jspc20.java:195) > at weblogic.servlet.jsp.JspcInvoker.compile(JspcInvoker.java:239) > at > weblogic.application.compiler.AppcUtils.compileWAR(AppcUtils.java:353) > at > weblogic.application.compiler.WARCompiler.compile(WARCompiler.java:78) > at > weblogic.application.compiler.flow.AppCompilerFlow.compileInput(AppCompi > lerFlow.ja
[jira] Issue Comment Edited: (MRM-426) Search does not work for snapshots because of different version values in index and database when the snapshot version is unique
[ http://jira.codehaus.org/browse/MRM-426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100591 ] Maria Odea Ching edited comment on MRM-426 at 6/27/07 12:57 AM: After further investigation, I found out that the problem was due to the following: 1. When the artifact was indexed (in IndexContentConsumer), the artifact version is being converted to **-SNAPSHOT whenever a unique snapshot version is encountered.. from the example above, 1.1.2-20070427.065136-1, 1.1.2-20070506.163513-2 and 1.1.2-20070506.163513-3 thus becomes 1.1.2-SNAPSHOT when added in the index. This is for the 'version' field in the index. But in the 'filename' field of the index, the unique version is retained as is. Therefore when you search 'castor-anttasks-1.1.2-20070427.065136-1.pom', you'll get 1 hit result like this: Hits: 1 of 1 castor-anttasks org / codehaus / castor / castor-anttasks | Version(s): 1.1.2-SNAPSHOT 2. When the artifact was added in the database (in ArtifactUpdateDatabaseConsumer), the unique version was retained as is. And since the version of the artifact in the results page is 1.1.2-SNAPSHOT, when you click it to browse that artifact.. it couldn't be found on the database because the version of the artifact that was added was still 1.1.2-20070427.065136-1 and what's being queried is 1.1.2-SNAPSHOT. I've thought of two ways to approach this.. 1. do not convert unique snapshots to **-SNAPSHOT and retain all versions as is 2. convert all unique versions (in the database and in the index -- filename field) to **-SNAPSHOT. What do you guys think? was: After further investigation, I found out that the problem was due to the following: 1. When the artifact was indexed (in IndexContentConsumer), the artifact version is being converted to **-SNAPSHOT whenever a unique snapshot version is encountered.. from the example above, 1.1.2-20070427.065136-1, 1.1.2-20070506.163513-2 and 1.1.2-20070506.163513-3 thus becomes 1.1.2-SNAPSHOT when added in the index. This is for the 'version' field in the index. But in the 'filename' field of the index, the unique version is retained as is. Therefore when you search 'castor-anttasks-1.1.2-20070427.065136-1.pom', you'll get 1 hit result like this: Hits: 1 of 1 castor-anttasks org / codehaus / castor / castor-anttasks | Version(s): 1.1.2-SNAPSHOT 2. When the artifact was added in the database (in ArtifactUpdateDatabaseConsumer), the unique version was retained as is. And since the version of the artifact in the results page is 1.1.2-SNAPSHOT, when you click it to browse that artifact.. it couldn't be found on the database because the version of the artifact that was added was still 1.1.2-20070427.065136-1 and what's being queried is 1.1.2-SNAPSHOT. I've thought of two ways to approach this.. 1. do not convert unique snapshots to **-SNAPSHOT and retain all versions as is 2. convert all unique versions (in the database and in the index -- filename field) to **-SNAPSHOT. Personally, I'd go for #1 because the index and the database would match the actual contents of the repository. What do you guys think? > Search does not work for snapshots because of different version values in > index and database when the snapshot version is unique > > > Key: MRM-426 > URL: http://jira.codehaus.org/browse/MRM-426 > Project: Archiva > Issue Type: Bug >Affects Versions: 1.0-alpha-2 >Reporter: Maria Odea Ching > > When an artifact with unique snapshots is searched from Archiva, the search > result would contain different hits for that artifact which has the same > version but when you click the version to browse the artifact.. an > ObjectNotFound error is returned. Below is an example of this behavior. > The artifact to be searched is castor-anttasks. Let's say it has 3 SNAPSHOT > versions 1.1.2-20070427.065136-1, 1.1.2-20070506.163513-2 and > 1.1.2-20070506.163513-3 in the repository, and the path to this artifact is > [REPO]/org/codehaus/castor/castor-anttasks/1.1.2-SNAPSHOT. > The search results would then look like this: > Hits: 3 of 3 > castor-anttasks > org / codehaus / castor / castor-anttasks | Version(s): 1.1.2-SNAPSHOT > castor-anttasks > org / codehaus / castor / castor-anttasks | Version(s): 1.1.2-SNAPSHOT > castor-anttasks > org / codehaus / castor / castor-anttasks | Version(s): 1.1.2-SNAPSHOT > When you click either of the versions to browse the artifact, what you would > get is this error: > 'Unable to find project model for > [org.codehaus.castor:castor-anttasks:1.1.2-SNAPSHOT]' -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secu
[jira] Reopened: (MNG-2188) Report mojos should check canGenerateReport() when called directly
[
http://jira.codehaus.org/browse/MNG-2188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter reopened MNG-2188:
---
Assignee: Vincent Massol
> Report mojos should check canGenerateReport() when called directly
> --
>
> Key: MNG-2188
> URL: http://jira.codehaus.org/browse/MNG-2188
> Project: Maven 2
> Issue Type: Improvement
> Components: Sites & Reporting
>Affects Versions: 2.0.3
>Reporter: Vincent Massol
>Assignee: Vincent Massol
> Fix For: 2.0.x
>
> Attachments: AbstractMavenReport-canGenerateReport-check.patch
>
>
> There's a canGenerateReport() method in a ReportMojo. This method is called
> by the site phase to decide if the mojo should be called or not. This is
> cool. However the user can call directly the report mojo and in that case the
> canGenerateReport() method is not called automatically. Thus the solution for
> a plugin developer is to write:
> {code}
> public void executeReport()
> {
> if (canGenerateReport() )
> {
> [...]
> }
> }
> {code}
> Which means that the canGenerateReport method is going to be called twice
> when mvn site is executed.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (MNG-728) Consider using java.net.useSystemProxies
[ http://jira.codehaus.org/browse/MNG-728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter reopened MNG-728: -- > Consider using java.net.useSystemProxies > > > Key: MNG-728 > URL: http://jira.codehaus.org/browse/MNG-728 > Project: Maven 2 > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 2.0-alpha-3 >Reporter: Kohsuke Kawaguchi >Priority: Minor > Fix For: 2.1.x > > Attachments: maven-proxy-1.patch, maven-proxy-2.patch, > maven-proxy-3.patch > > > Consider using the java.net.useSystemProxies property so that Maven can work > with a proxy without requring any user intervention. > See http://weblogs.java.net/blog/kohsuke/archive/2005/08/we_deserve_a_be.html > for more information. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-1830) add a 'compiled on ' label when maven 2 is invoked with --version option
[ http://jira.codehaus.org/browse/MNG-1830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-1830: -- Patch Submitted: (was: [Yes]) patches are not applicable for this > add a 'compiled on ' label when maven 2 is invoked with --version > option > > > Key: MNG-1830 > URL: http://jira.codehaus.org/browse/MNG-1830 > Project: Maven 2 > Issue Type: Improvement >Reporter: Rahul Thakur >Priority: Minor > Fix For: 2.0.x > > Attachments: bootstrap_builtOn.patch, maven-archiver_builtOn.patch > > > It might be a good idea to append > 'compiled on ' > when maven2 is invoked with '--version' swtich/option, just like Ant does. > Can be helpful when compiling m2 locally 'n' times and need to ensure the m2 > installation was infact updated or when was it last updated. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (MNG-1830) add a 'compiled on ' label when maven 2 is invoked with --version option
[ http://jira.codehaus.org/browse/MNG-1830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter reopened MNG-1830: --- regardless, built on would be a useful addition to the --version output > add a 'compiled on ' label when maven 2 is invoked with --version > option > > > Key: MNG-1830 > URL: http://jira.codehaus.org/browse/MNG-1830 > Project: Maven 2 > Issue Type: Improvement >Reporter: Rahul Thakur >Priority: Minor > Fix For: 2.0.x > > Attachments: bootstrap_builtOn.patch, maven-archiver_builtOn.patch > > > It might be a good idea to append > 'compiled on ' > when maven2 is invoked with '--version' swtich/option, just like Ant does. > Can be helpful when compiling m2 locally 'n' times and need to ensure the m2 > installation was infact updated or when was it last updated. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (MNG-50) Coding standard descriptor
[ http://jira.codehaus.org/browse/MNG-50?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter reopened MNG-50: - > Coding standard descriptor > -- > > Key: MNG-50 > URL: http://jira.codehaus.org/browse/MNG-50 > Project: Maven 2 > Issue Type: New Feature >Reporter: Jason van Zyl >Priority: Minor > Fix For: 2.2.x > > > Add a field to the POM that describes the coding standard used by a project. > This value could then be used to create a link to a standard set of documents > describing the chose coding standard: sun, turbine, gnu or what have you. > This could possibly be combined with some other properties that might > generally control source formatting and verification type plugins like > checkstyle. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-50) Coding standard descriptor
[ http://jira.codehaus.org/browse/MNG-50?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-50: Fix Version/s: (was: 2.1.x) 2.2.x Patch Submitted: (was: [Yes]) > Coding standard descriptor > -- > > Key: MNG-50 > URL: http://jira.codehaus.org/browse/MNG-50 > Project: Maven 2 > Issue Type: New Feature >Reporter: Jason van Zyl >Priority: Minor > Fix For: 2.2.x > > > Add a field to the POM that describes the coding standard used by a project. > This value could then be used to create a link to a standard set of documents > describing the chose coding standard: sun, turbine, gnu or what have you. > This could possibly be combined with some other properties that might > generally control source formatting and verification type plugins like > checkstyle. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3071) Add a command line option to dump the contents of all the classloaders used during an invocation of Maven
[ http://jira.codehaus.org/browse/MNG-3071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100650 ] Brett Porter commented on MNG-3071: --- yep, there's a separate jira somewhere for adding domains to the -X output, so maybe this is time to roll that in rather than introducing another command line option > Add a command line option to dump the contents of all the classloaders used > during an invocation of Maven > - > > Key: MNG-3071 > URL: http://jira.codehaus.org/browse/MNG-3071 > Project: Maven 2 > Issue Type: New Feature >Affects Versions: 2.0.7 >Reporter: Jason van Zyl > Fix For: 2.0.8 > > > It is very annoying to track down what versions of what are being used, so > add a mode to the command line to dump the contents of the class realms being > used. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3071) Add a command line option to dump the contents of all the classloaders used during an invocation of Maven
[ http://jira.codehaus.org/browse/MNG-3071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100649 ] Jason van Zyl commented on MNG-3071: So the user doesn't have to sift through 15 pages of output. We could use the same pattern that the java command line does where there are -Xfoo options. I'm just thinking of Jochen's particular use case and all he really wants is the classloader contents. Domain specific debugging to make diagnosis easier. > Add a command line option to dump the contents of all the classloaders used > during an invocation of Maven > - > > Key: MNG-3071 > URL: http://jira.codehaus.org/browse/MNG-3071 > Project: Maven 2 > Issue Type: New Feature >Affects Versions: 2.0.7 >Reporter: Jason van Zyl > Fix For: 2.0.8 > > > It is very annoying to track down what versions of what are being used, so > add a mode to the command line to dump the contents of the class realms being > used. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3071) Add a command line option to dump the contents of all the classloaders used during an invocation of Maven
[ http://jira.codehaus.org/browse/MNG-3071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100648 ] Brett Porter commented on MNG-3071: --- why not just add this to the -X output? > Add a command line option to dump the contents of all the classloaders used > during an invocation of Maven > - > > Key: MNG-3071 > URL: http://jira.codehaus.org/browse/MNG-3071 > Project: Maven 2 > Issue Type: New Feature >Affects Versions: 2.0.7 >Reporter: Jason van Zyl > Fix For: 2.0.8 > > > It is very annoying to track down what versions of what are being used, so > add a mode to the command line to dump the contents of the class realms being > used. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (WAGON-82) wagon-webdav does not set http-proxy correctly
[ http://jira.codehaus.org/browse/WAGON-82?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100647 ] Brett Porter commented on WAGON-82: --- Arnaud - if this is working, please go ahead and apply it. > wagon-webdav does not set http-proxy correctly > -- > > Key: WAGON-82 > URL: http://jira.codehaus.org/browse/WAGON-82 > Project: wagon > Issue Type: Bug > Components: wagon-webdav >Affects Versions: 1.0-beta-2 > Environment: any system >Reporter: Marc Wilhelm >Priority: Blocker > Attachments: WAGON-82-maven-artifact-manager.patch, > WAGON-82-tested-maven-artifact-manager.patch, WAGON-82-tested-wagon.patch, > WAGON-82-wagon.patch, wagon-webdav.patch > > > Webdav connections through a http-proxy are currently not possible. > The webdav provider opens first a connection to the target system and checks > after this, if a proxy should be used. > To fix this in the method > "org.apache.maven.wagon.providers.webdav.WebdavWagon#openConnection()" the > call "webdavResource = new CorrectedWebdavResource( httpURL );" must be > changed into "webdavResource = new CorrectedWebdavResource( );" and after > configuring the http-proxy the method call > "webdavResource.setHttpURL(httpURL);" must be added. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MWAR-109) Problem using webResources in configuration
Problem using webResources in configuration --- Key: MWAR-109 URL: http://jira.codehaus.org/browse/MWAR-109 Project: Maven 2.x War Plugin Issue Type: Bug Affects Versions: 2.0.2, 2.0.3 Reporter: David Castro I have been trying to get web resources into a resources directory where I can have them copied over during packaging and filtered as necessary. With 2.0 the targetPath doesn't work. And with 2.0.2 and 2.0.3-SNAPSHOT I can't seem to configure without it blowing up at all. They both die at the IOUtil.copy call in AbstractWarMojo org.apache.maven.plugin.war.AbstractWarMojo.copyFilteredFile(AbstractWarMojo.java:921) --- org.apache.maven.plugins maven-war-plugin 2.0.2 WEB-INF/spring true src/main/resources/WEB-INF/spring *.xml *.properties --- [INFO] Copy webapp webResources to /home/arimus/workspace-ym/ym/ym-proj/ym-web/target/myapp [INFO] [ERROR] FATAL ERROR [INFO] [INFO] org.apache.maven.project.MavenProject cannot be cast to java.lang.String [INFO] [INFO] Trace java.lang.ClassCastException: org.apache.maven.project.MavenProject cannot be cast to java.lang.String at org.codehaus.plexus.util.InterpolationFilterReader.read(InterpolationFilterReader.java:269) at org.codehaus.plexus.util.InterpolationFilterReader.read(InterpolationFilterReader.java:201) at org.codehaus.plexus.util.InterpolationFilterReader.read(InterpolationFilterReader.java:162) at java.io.Reader.read(Reader.java:123) at org.codehaus.plexus.util.IOUtil.copy(IOUtil.java:212) at org.codehaus.plexus.util.IOUtil.copy(IOUtil.java:200) at org.apache.maven.plugin.war.AbstractWarMojo.copyFilteredFile(AbstractWarMojo.java:921) at org.apache.maven.plugin.war.AbstractWarMojo.copyResources(AbstractWarMojo.java:415) at org.apache.maven.plugin.war.AbstractWarMojo.buildWebapp(AbstractWarMojo.java:518) at org.apache.maven.plugin.war.AbstractWarMojo.buildExplodedWebapp(AbstractWarMojo.java:347) at org.apache.maven.plugin.war.WarMojo.performPackaging(WarMojo.java:164) at org.apache.maven.plugin.war.WarMojo.execute(WarMojo.java:130) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) at org.apache.maven.cli.MavenCli.main(MavenCli.java:272) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SCM-322) SCM plug-in should tell at what revision the source is when it finishes
[
http://jira.codehaus.org/browse/SCM-322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Mayorga Adame updated SCM-322:
---
Description:
As of now the output is like this:
{noformat}
...
[INFO] [scm:update]
[INFO] Executing: svn --non-interactive update
[INFO] Working directory: C:\archiva
[INFO] Storing revision in 'scm.revision' project property.
[INFO]
[INFO] BUILD SUCCESSFUL
[INFO]
...
{noformat}
It would be nice to have something like this:
{noformat}
...
[INFO] [scm:update]
[INFO] Executing: svn --non-interactive update
[INFO] Working directory: C:\archiva
[INFO] Project at revision XXX.
[INFO] Storing revision in 'scm.revision' project property.
[INFO]
[INFO] BUILD SUCCESSFUL
[INFO]
...
{noformat}
was:
It would be nice to have this feature.
As of now the output is like this:
{noformat}
...
[INFO] [scm:update]
[INFO] Executing: svn --non-interactive update
[INFO] Working directory: C:\archiva
[INFO] Storing revision in 'scm.revision' project property.
[INFO]
[INFO] BUILD SUCCESSFUL
[INFO]
...
{noformat}
> SCM plug-in should tell at what revision the source is when it finishes
> ---
>
> Key: SCM-322
> URL: http://jira.codehaus.org/browse/SCM-322
> Project: Maven SCM
> Issue Type: Improvement
> Components: maven-plugin
>Affects Versions: 1.0
>Reporter: Alex Mayorga Adame
>Priority: Trivial
>
> As of now the output is like this:
> {noformat}
> ...
> [INFO] [scm:update]
> [INFO] Executing: svn --non-interactive update
> [INFO] Working directory: C:\archiva
> [INFO] Storing revision in 'scm.revision' project property.
> [INFO]
>
> [INFO] BUILD SUCCESSFUL
> [INFO]
>
> ...
> {noformat}
> It would be nice to have something like this:
> {noformat}
> ...
> [INFO] [scm:update]
> [INFO] Executing: svn --non-interactive update
> [INFO] Working directory: C:\archiva
> [INFO] Project at revision XXX.
> [INFO] Storing revision in 'scm.revision' project property.
> [INFO]
>
> [INFO] BUILD SUCCESSFUL
> [INFO]
>
> ...
> {noformat}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SCM-322) SCM plug-in should tell at what revision the source is when it finishes
SCM plug-in should tell at what revision the source is when it finishes
---
Key: SCM-322
URL: http://jira.codehaus.org/browse/SCM-322
Project: Maven SCM
Issue Type: Improvement
Components: maven-plugin
Affects Versions: 1.0
Reporter: Alex Mayorga Adame
Priority: Trivial
It would be nice to have this feature.
As of now the output is like this:
{noformat}
...
[INFO] [scm:update]
[INFO] Executing: svn --non-interactive update
[INFO] Working directory: C:\archiva
[INFO] Storing revision in 'scm.revision' project property.
[INFO]
[INFO] BUILD SUCCESSFUL
[INFO]
...
{noformat}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVENUPLOAD-1613) Test ticket
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Contegix Support closed MAVENUPLOAD-1613. - Resolution: Fixed test ticket. Please disregard > Test ticket > --- > > Key: MAVENUPLOAD-1613 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1613 > Project: maven-upload-requests > Issue Type: Test >Reporter: Contegix Support > > test -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-1613) Test ticket
Test ticket --- Key: MAVENUPLOAD-1613 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1613 Project: maven-upload-requests Issue Type: Test Reporter: Contegix Support test -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MEV-533) JUnit maven-metadata.xml doesn't include 4.3 versions
[ http://jira.codehaus.org/browse/MEV-533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MEV-533. -- Assignee: Carlos Sanchez Resolution: Fixed > JUnit maven-metadata.xml doesn't include 4.3 versions > - > > Key: MEV-533 > URL: http://jira.codehaus.org/browse/MEV-533 > Project: Maven Evangelism > Issue Type: Bug > Components: Invalid Metadata >Reporter: Stephen Pack >Assignee: Carlos Sanchez > > The maven-metadata.xml [1] doesn't include the 4.3 and 4.3.1 versions that > are out there. Can this please be updated? Thanks. > [1] http://repo1.maven.org/maven2/junit/junit/maven-metadata.xml -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MEV-529) Please fix aspectj mavane-metadata.xml
[ http://jira.codehaus.org/browse/MEV-529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MEV-529. -- Assignee: Carlos Sanchez Resolution: Fixed > Please fix aspectj mavane-metadata.xml > -- > > Key: MEV-529 > URL: http://jira.codehaus.org/browse/MEV-529 > Project: Maven Evangelism > Issue Type: Task > Components: Invalid Metadata >Reporter: Richard A. Gill >Assignee: Carlos Sanchez > > Please update the metadata to reflect the latest (newer) version > 1.5.0 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVENUPLOAD-1609) Synchronize opensymphony:xwork:jar:2.0.3 to central repo
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1609. --- Assignee: Carlos Sanchez Resolution: Fixed > Synchronize opensymphony:xwork:jar:2.0.3 to central repo > > > Key: MAVENUPLOAD-1609 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1609 > Project: maven-upload-requests > Issue Type: Bug >Reporter: Olivier Lamy >Assignee: Carlos Sanchez > > Hi, > The artifact opensymphony:xwork:jar:2.0.3 is in the opensymphony repository > http://maven2.opensymphony.com/opensymphony/xwork/2.0.3/ . > Is it possible to have in http://repo1.maven.org/maven2/opensymphony/xwork/ ? > Thanks. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVENUPLOAD-1611) jframework.org upload script
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1611. --- Assignee: Carlos Sanchez Resolution: Fixed > jframework.org upload script > > > Key: MAVENUPLOAD-1611 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1611 > Project: maven-upload-requests > Issue Type: Task >Reporter: Misha Gridnev >Assignee: Carlos Sanchez > Attachments: org.jframework.sh > > > Please add org.jframework.sh to upload scripts. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-1609) Synchronize opensymphony:xwork:jar:2.0.3 to central repo
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100632 ] Carlos Sanchez commented on MAVENUPLOAD-1609: - artifactId for jempbox doesn't match jar name (uppercase/lowercase) it should be like the jar name JempBox > Synchronize opensymphony:xwork:jar:2.0.3 to central repo > > > Key: MAVENUPLOAD-1609 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1609 > Project: maven-upload-requests > Issue Type: Bug >Reporter: Olivier Lamy > > Hi, > The artifact opensymphony:xwork:jar:2.0.3 is in the opensymphony repository > http://maven2.opensymphony.com/opensymphony/xwork/2.0.3/ . > Is it possible to have in http://repo1.maven.org/maven2/opensymphony/xwork/ ? > Thanks. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVENUPLOAD-1612) Upload request for jython 2.2-rc1
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1612. --- Assignee: Carlos Sanchez Resolution: Fixed > Upload request for jython 2.2-rc1 > - > > Key: MAVENUPLOAD-1612 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1612 > Project: maven-upload-requests > Issue Type: Task >Reporter: Charlie Groves >Assignee: Carlos Sanchez > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVENUPLOAD-1610) New version of XINS for Maven2 repository
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1610. --- Assignee: Carlos Sanchez Resolution: Fixed > New version of XINS for Maven2 repository > - > > Key: MAVENUPLOAD-1610 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1610 > Project: maven-upload-requests > Issue Type: Task >Reporter: Anthony Goubard >Assignee: Carlos Sanchez > > Hi, > Here are new JAR file that I'd like to have uploaded in Maven: > http://xins.sourceforge.net/maven/xins-server-2.0.jar > http://xins.sourceforge.net/maven/xins-common-2.0.jar > http://xins.sourceforge.net/maven/xins-client-2.0.jar > http://xins.sourceforge.net/maven/logdoc-2.0.jar > Kind regards, > Anthony -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVENUPLOAD-1601) Cooee 1.0 Upload
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1601. --- Assignee: Carlos Sanchez Resolution: Incomplete > Cooee 1.0 Upload > > > Key: MAVENUPLOAD-1601 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1601 > Project: maven-upload-requests > Issue Type: Task >Reporter: Daniel Murley >Assignee: Carlos Sanchez > > http://www.karora.org/maven-repository/bundles/cooee-1.0-bundle.jar > http://www.karora.org > http://www.karora.org/projects/cooee/team-list.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVEN-1852) Parse Fatal Error at line 491 column 42: The entity name must immediately follow the '&' in the entity reference.
[ http://jira.codehaus.org/browse/MAVEN-1852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl closed MAVEN-1852. Assignee: Lukas Theussl Resolution: Won't Fix This is not a bug, check the entity at line 491 column 42. If in doubt, consult the user list (and include the file that contains your entities!). > Parse Fatal Error at line 491 column 42: The entity name must immediately > follow the '&' in the entity reference. > - > > Key: MAVEN-1852 > URL: http://jira.codehaus.org/browse/MAVEN-1852 > Project: Maven 1 > Issue Type: Bug > Environment: WinXP Home Edition, Version 2002 Service Pack 2 > Dell Dimension DIM2400 > Intel Pentium(R) 4 CPU 2.80GHz > 2.79 GHz, 1.25 GB RAM >Reporter: Dennis Gagomiros >Assignee: Lukas Theussl >Priority: Critical > > running maven -e and maven --info yielded the same results: > __ __ > | \/ |__ _Apache__ ___ > | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ > |_| |_\__,_|\_/\___|_||_| v. 1.0.2 > Plugin cache will be regenerated > Parse Fatal Error at line 491 column 42: The entity name must immediately > follow the '&' in the entity reference. > org.xml.sax.SAXParseException: The entity name must immediately follow the > '&' in the entity reference. > at > org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown > Source) > at org.apache.xerces.util.ErrorHandlerWrapper.fatalError(Unknown Source) > at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source) > at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source) > at org.apache.xerces.impl.XMLScanner.reportFatalError(Unknown Source) > at > org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanEntityReference(Unknown > Source) > at > org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown > Source) > at > org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown > Source) > at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) > at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source) > at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) > at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) > at org.apache.commons.digester.Digester.parse(Digester.java:1581) > at org.apache.maven.MavenUtils.getInterpolatedPOM(MavenUtils.java:386) > at org.apache.maven.MavenUtils.getJellyProject(MavenUtils.java:360) > at org.apache.maven.MavenUtils.getProject(MavenUtils.java:144) > at > org.apache.maven.plugin.JellyScriptHousing.getProject(JellyScriptHousing.java:105) > at > org.apache.maven.plugin.PluginManager.createPluginHousing(PluginManager.java:339) > at > org.apache.maven.plugin.PluginManager.loadUncachedPlugins(PluginManager.java:235) > at > org.apache.maven.plugin.PluginManager.initialize(PluginManager.java:304) > at > org.apache.maven.MavenSession.initializePluginManager(MavenSession.java:204) > at org.apache.maven.MavenSession.initialize(MavenSession.java:171) > at org.apache.maven.cli.App.doMain(App.java:475) > at org.apache.maven.cli.App.main(App.java:1239) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at com.werken.forehead.Forehead.run(Forehead.java:551) > at com.werken.forehead.Forehead.main(Forehead.java:581) > You have encountered an unknown error running Maven. Please help us to > correct > this problem by following these simple steps: > - read the Maven FAQ at http://maven.apache.org/faq.html > - run the same command again with the '-e' parameter, eg maven -e jar > - search the maven-user archives for the error at > http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED] > - post the output of maven -e to JIRA at > http://jira.codehaus.org/BrowseProject.jspa?id=10030 (you must sign up first) > - run 'maven --info' and post the output as the environment to the bug above > Total time: 1 seconds > Finished at: Tue Jun 26 13:39:48 EDT 2007 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVEN-1852) Parse Fatal Error at line 491 column 42: The entity name must immediately follow the '&' in the entity reference.
Parse Fatal Error at line 491 column 42: The entity name must immediately follow the '&' in the entity reference. - Key: MAVEN-1852 URL: http://jira.codehaus.org/browse/MAVEN-1852 Project: Maven 1 Issue Type: Bug Environment: WinXP Home Edition, Version 2002 Service Pack 2 Dell Dimension DIM2400 Intel Pentium(R) 4 CPU 2.80GHz 2.79 GHz, 1.25 GB RAM Reporter: Dennis Gagomiros Priority: Critical running maven -e and maven --info yielded the same results: __ __ | \/ |__ _Apache__ ___ | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.0.2 Plugin cache will be regenerated Parse Fatal Error at line 491 column 42: The entity name must immediately follow the '&' in the entity reference. org.xml.sax.SAXParseException: The entity name must immediately follow the '&' in the entity reference. at org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown Source) at org.apache.xerces.util.ErrorHandlerWrapper.fatalError(Unknown Source) at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source) at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source) at org.apache.xerces.impl.XMLScanner.reportFatalError(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanEntityReference(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at org.apache.commons.digester.Digester.parse(Digester.java:1581) at org.apache.maven.MavenUtils.getInterpolatedPOM(MavenUtils.java:386) at org.apache.maven.MavenUtils.getJellyProject(MavenUtils.java:360) at org.apache.maven.MavenUtils.getProject(MavenUtils.java:144) at org.apache.maven.plugin.JellyScriptHousing.getProject(JellyScriptHousing.java:105) at org.apache.maven.plugin.PluginManager.createPluginHousing(PluginManager.java:339) at org.apache.maven.plugin.PluginManager.loadUncachedPlugins(PluginManager.java:235) at org.apache.maven.plugin.PluginManager.initialize(PluginManager.java:304) at org.apache.maven.MavenSession.initializePluginManager(MavenSession.java:204) at org.apache.maven.MavenSession.initialize(MavenSession.java:171) at org.apache.maven.cli.App.doMain(App.java:475) at org.apache.maven.cli.App.main(App.java:1239) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at com.werken.forehead.Forehead.run(Forehead.java:551) at com.werken.forehead.Forehead.main(Forehead.java:581) You have encountered an unknown error running Maven. Please help us to correct this problem by following these simple steps: - read the Maven FAQ at http://maven.apache.org/faq.html - run the same command again with the '-e' parameter, eg maven -e jar - search the maven-user archives for the error at http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED] - post the output of maven -e to JIRA at http://jira.codehaus.org/BrowseProject.jspa?id=10030 (you must sign up first) - run 'maven --info' and post the output as the environment to the bug above Total time: 1 seconds Finished at: Tue Jun 26 13:39:48 EDT 2007 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-3072) Dependency with lower version number is chosen
[ http://jira.codehaus.org/browse/MNG-3072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MNG-3072. --- Assignee: Carlos Sanchez Resolution: Won't Fix For what you say it works correctly, Maven uses the "nearest dependency" resolution, not the "latest version" see http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html > Dependency with lower version number is chosen > -- > > Key: MNG-3072 > URL: http://jira.codehaus.org/browse/MNG-3072 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.6 >Reporter: Achim Abeling >Assignee: Carlos Sanchez > Attachments: surefire-bug.tar.gz > > > My test application tries to create a spring > org.springframework.context.ApplicationContext. > This fails because of a > java.lang.NoClassDefFoundError: > org/springframework/beans/factory/support/ConfigurableBeanFactoryUtils > This class is included in org.springframework:spring-context:1.2.8 but not in > version 2.0.6 which I am using. > Version 1.2.8 is a dependency for e.g org.apache.axis2:axis2-kernel. > Maven chooses version 1.2.8. Running with option -X one can see the line > [DEBUG] org.springframework:spring-context:jar:2.0.6:compile (removed - > nearer found: 1.2.8) > Surprisingly if the cglib dependency in my test project is commented version > 2.0.6 is chosen. > (The test project is called surefire-bug because I first thought it had to do > with the surefire-plugin and was too lazy to rename everything.) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3072) Dependency with lower version number is chosen
[ http://jira.codehaus.org/browse/MNG-3072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100621 ] Mark Hobson commented on MNG-3072: -- I haven't looked at your project's dependencies, but sounds like a result of nearest-wins conflict resolution - see MNG-612. > Dependency with lower version number is chosen > -- > > Key: MNG-3072 > URL: http://jira.codehaus.org/browse/MNG-3072 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.6 >Reporter: Achim Abeling > Attachments: surefire-bug.tar.gz > > > My test application tries to create a spring > org.springframework.context.ApplicationContext. > This fails because of a > java.lang.NoClassDefFoundError: > org/springframework/beans/factory/support/ConfigurableBeanFactoryUtils > This class is included in org.springframework:spring-context:1.2.8 but not in > version 2.0.6 which I am using. > Version 1.2.8 is a dependency for e.g org.apache.axis2:axis2-kernel. > Maven chooses version 1.2.8. Running with option -X one can see the line > [DEBUG] org.springframework:spring-context:jar:2.0.6:compile (removed - > nearer found: 1.2.8) > Surprisingly if the cglib dependency in my test project is commented version > 2.0.6 is chosen. > (The test project is called surefire-bug because I first thought it had to do > with the surefire-plugin and was too lazy to rename everything.) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MWAR-9) WAR plugin should support minimal WARs for inclusion within an EAR
[ http://jira.codehaus.org/browse/MWAR-9?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100602 ] Jason Melnick commented on MWAR-9: -- After more testing the posted patch doesn't work as intended as it removes the transitive dependencies of non-optional deps. Am working on the correct fix now and will repost. > WAR plugin should support minimal WARs for inclusion within an EAR > -- > > Key: MWAR-9 > URL: http://jira.codehaus.org/browse/MWAR-9 > Project: Maven 2.x War Plugin > Issue Type: Improvement >Reporter: Mike Perham >Assignee: Stephane Nicoll > Attachments: AbstractWarMojo.patch > > > I noticed that when I build a WAR, I get a gigantic WEB-INF/lib with all my > deps. This is fine for a default but maven should also support "skeleton" > WARs which will be packaged within an EAR. We have EARs which package 3-4 > WARs each and to have the deps duplicated within each WAR means we cannot > have shared data (since the classes are loaded within each WAR's classloader, > rather than by the parent EAR's classloader). It also means 80MB EARs! :-) > It seems like two things need to happen: > 1) Add a "skeleton" flag which prevents copying any dependencies to > WEB-INF/lib. > 2) Instead generate a META-INF/MANIFEST.MF which has a Class-Path entry which > lists the relative locations of the dependencies within the parent EAR. > Fabrice has basically the same idea written down here. Starting with "- for > a War..." : > http://marc.theaimsgroup.com/?l=turbine-maven-user&m=112737860024530&w=2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3072) Dependency with lower version number is chosen
[ http://jira.codehaus.org/browse/MNG-3072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100600 ] Achim Abeling commented on MNG-3072: It works if the dependency org.springframework:spring-context is explicitly defined. > Dependency with lower version number is chosen > -- > > Key: MNG-3072 > URL: http://jira.codehaus.org/browse/MNG-3072 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.6 >Reporter: Achim Abeling > Attachments: surefire-bug.tar.gz > > > My test application tries to create a spring > org.springframework.context.ApplicationContext. > This fails because of a > java.lang.NoClassDefFoundError: > org/springframework/beans/factory/support/ConfigurableBeanFactoryUtils > This class is included in org.springframework:spring-context:1.2.8 but not in > version 2.0.6 which I am using. > Version 1.2.8 is a dependency for e.g org.apache.axis2:axis2-kernel. > Maven chooses version 1.2.8. Running with option -X one can see the line > [DEBUG] org.springframework:spring-context:jar:2.0.6:compile (removed - > nearer found: 1.2.8) > Surprisingly if the cglib dependency in my test project is commented version > 2.0.6 is chosen. > (The test project is called surefire-bug because I first thought it had to do > with the surefire-plugin and was too lazy to rename everything.) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-3072) Dependency with lower version number is chosen
Dependency with lower version number is chosen -- Key: MNG-3072 URL: http://jira.codehaus.org/browse/MNG-3072 Project: Maven 2 Issue Type: Bug Components: Dependencies Affects Versions: 2.0.6 Reporter: Achim Abeling Attachments: surefire-bug.tar.gz My test application tries to create a spring org.springframework.context.ApplicationContext. This fails because of a java.lang.NoClassDefFoundError: org/springframework/beans/factory/support/ConfigurableBeanFactoryUtils This class is included in org.springframework:spring-context:1.2.8 but not in version 2.0.6 which I am using. Version 1.2.8 is a dependency for e.g org.apache.axis2:axis2-kernel. Maven chooses version 1.2.8. Running with option -X one can see the line [DEBUG] org.springframework:spring-context:jar:2.0.6:compile (removed - nearer found: 1.2.8) Surprisingly if the cglib dependency in my test project is commented version 2.0.6 is chosen. (The test project is called surefire-bug because I first thought it had to do with the surefire-plugin and was too lazy to rename everything.) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2771) Provide a means of loading custom substitute components instead of default Maven components
[ http://jira.codehaus.org/browse/MNG-2771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100592 ] Mark Hobson commented on MNG-2771: -- I can't seem to get the extensions mechanism working when overriding descriptors in 2.0.x nor 2.1. Looking at both sources, DefaultExtensionManager.addExtension calls DefaultPlexusContainer.addJarResource in which discoverComponents never overrides a descriptor if it already exists. This seems to go against Kenney's comment above - am I missing something? > Provide a means of loading custom substitute components instead of default > Maven components > --- > > Key: MNG-2771 > URL: http://jira.codehaus.org/browse/MNG-2771 > Project: Maven 2 > Issue Type: New Feature > Components: General >Affects Versions: 2.0.4 >Reporter: John Casey >Assignee: Kenney Westerhof > Fix For: 2.1-alpha-1 > > > At times, it is necessary to use different mechanisms for resolving > artifacts, building projects, etc. Since Maven is built on component-oriented > technology, it should be possible to substitute the component implementation > used for these tasks. Yet this is currently impossible. > We need a mechanism for specifying, resolving, loading, and using custom > components during the build process. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Work started: (MRM-425) Search and Browse do not work for snapshots
[ http://jira.codehaus.org/browse/MRM-425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on MRM-425 started by Maria Odea Ching. > Search and Browse do not work for snapshots > --- > > Key: MRM-425 > URL: http://jira.codehaus.org/browse/MRM-425 > Project: Archiva > Issue Type: Bug > Components: web application >Affects Versions: 1.0-alpha-2 >Reporter: John Didion >Assignee: Maria Odea Ching > > When I to browse or search an artifact with snapshots, I usually get an error > when I try to go to the artifact info page. Looking at the logs, Archiva is > complaining that the version (x.y.z-SNAPSHOT) does not match the pom file's > version (x.y.z-timestamp-buildno). > Ideally, sequence for browse would be group->artifact->base version->snapshot > version. In other words, I would first browse to the base version, under > which would be listed all the snapshot versions. The pom snippet on the base > version page would have x.y.z-SNAPSHOT and the pom snippet > on the snapshot version page would have > x.y.z-timestamp-buildno. I think this would be a lot more > clear than how it currently works - mixing base versions and snapshot > versions on the same page. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRM-426) Search does not work for snapshots because of different version values in index and database when the snapshot version is unique
[ http://jira.codehaus.org/browse/MRM-426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100591 ] Maria Odea Ching commented on MRM-426: -- After further investigation, I found out that the problem was due to the following: 1. When the artifact was indexed (in IndexContentConsumer), the artifact version is being converted to **-SNAPSHOT whenever a unique snapshot version is encountered.. from the example above, 1.1.2-20070427.065136-1, 1.1.2-20070506.163513-2 and 1.1.2-20070506.163513-3 thus becomes 1.1.2-SNAPSHOT when added in the index. This is for the 'version' field in the index. But in the 'filename' field of the index, the unique version is retained as is. Therefore when you search 'castor-anttasks-1.1.2-20070427.065136-1.pom', you'll get 1 hit result like this: Hits: 1 of 1 castor-anttasks org / codehaus / castor / castor-anttasks | Version(s): 1.1.2-SNAPSHOT 2. When the artifact was added in the database (in ArtifactUpdateDatabaseConsumer), the unique version was retained as is. And since the version of the artifact in the results page is 1.1.2-SNAPSHOT, when you click it to browse that artifact.. it couldn't be found on the database because the version of the artifact that was added was still 1.1.2-20070427.065136-1 and what's being queried is 1.1.2-SNAPSHOT. I've thought of two ways to approach this.. 1. do not convert unique snapshots to **-SNAPSHOT and retain all versions as is 2. convert all unique versions (in the database and in the index -- filename field) to **-SNAPSHOT. Personally, I'd go for #1 because the index and the database would match the actual contents of the repository. What do you guys think? > Search does not work for snapshots because of different version values in > index and database when the snapshot version is unique > > > Key: MRM-426 > URL: http://jira.codehaus.org/browse/MRM-426 > Project: Archiva > Issue Type: Bug >Affects Versions: 1.0-alpha-2 >Reporter: Maria Odea Ching > > When an artifact with unique snapshots is searched from Archiva, the search > result would contain different hits for that artifact which has the same > version but when you click the version to browse the artifact.. an > ObjectNotFound error is returned. Below is an example of this behavior. > The artifact to be searched is castor-anttasks. Let's say it has 3 SNAPSHOT > versions 1.1.2-20070427.065136-1, 1.1.2-20070506.163513-2 and > 1.1.2-20070506.163513-3 in the repository, and the path to this artifact is > [REPO]/org/codehaus/castor/castor-anttasks/1.1.2-SNAPSHOT. > The search results would then look like this: > Hits: 3 of 3 > castor-anttasks > org / codehaus / castor / castor-anttasks | Version(s): 1.1.2-SNAPSHOT > castor-anttasks > org / codehaus / castor / castor-anttasks | Version(s): 1.1.2-SNAPSHOT > castor-anttasks > org / codehaus / castor / castor-anttasks | Version(s): 1.1.2-SNAPSHOT > When you click either of the versions to browse the artifact, what you would > get is this error: > 'Unable to find project model for > [org.codehaus.castor:castor-anttasks:1.1.2-SNAPSHOT]' -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRM-426) Search does not work for snapshots because of different version values in index and database when the snapshot version is unique
Search does not work for snapshots because of different version values in index and database when the snapshot version is unique Key: MRM-426 URL: http://jira.codehaus.org/browse/MRM-426 Project: Archiva Issue Type: Bug Affects Versions: 1.0-alpha-2 Reporter: Maria Odea Ching When an artifact with unique snapshots is searched from Archiva, the search result would contain different hits for that artifact which has the same version but when you click the version to browse the artifact.. an ObjectNotFound error is returned. Below is an example of this behavior. The artifact to be searched is castor-anttasks. Let's say it has 3 SNAPSHOT versions 1.1.2-20070427.065136-1, 1.1.2-20070506.163513-2 and 1.1.2-20070506.163513-3 in the repository, and the path to this artifact is [REPO]/org/codehaus/castor/castor-anttasks/1.1.2-SNAPSHOT. The search results would then look like this: Hits: 3 of 3 castor-anttasks org / codehaus / castor / castor-anttasks | Version(s): 1.1.2-SNAPSHOT castor-anttasks org / codehaus / castor / castor-anttasks | Version(s): 1.1.2-SNAPSHOT castor-anttasks org / codehaus / castor / castor-anttasks | Version(s): 1.1.2-SNAPSHOT When you click either of the versions to browse the artifact, what you would get is this error: 'Unable to find project model for [org.codehaus.castor:castor-anttasks:1.1.2-SNAPSHOT]' -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRM-425) Search and Browse do not work for snapshots
[ http://jira.codehaus.org/browse/MRM-425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maria Odea Ching updated MRM-425: - Comment: was deleted > Search and Browse do not work for snapshots > --- > > Key: MRM-425 > URL: http://jira.codehaus.org/browse/MRM-425 > Project: Archiva > Issue Type: Bug > Components: web application >Affects Versions: 1.0-alpha-2 >Reporter: John Didion > > When I to browse or search an artifact with snapshots, I usually get an error > when I try to go to the artifact info page. Looking at the logs, Archiva is > complaining that the version (x.y.z-SNAPSHOT) does not match the pom file's > version (x.y.z-timestamp-buildno). > Ideally, sequence for browse would be group->artifact->base version->snapshot > version. In other words, I would first browse to the base version, under > which would be listed all the snapshot versions. The pom snippet on the base > version page would have x.y.z-SNAPSHOT and the pom snippet > on the snapshot version page would have > x.y.z-timestamp-buildno. I think this would be a lot more > clear than how it currently works - mixing base versions and snapshot > versions on the same page. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRM-425) Search and Browse do not work for snapshots
[ http://jira.codehaus.org/browse/MRM-425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100590 ] Maria Odea Ching commented on MRM-425: -- This was the behavior I encountered for Search: When an artifact with unique snapshots is searched from Archiva, the search result would contain different hits for that artifact which has the same version but when you click the version to browse the artifact..an 'Unable to find...' error is returned. Below is an example: The artifact to be searched is castor-anttasks. Let's say it has three SNAPSHOT versions 1.1.2-20070427.065136-1, 1.1.2-20070506.163513-2 and 1.1.2-20070506.163513-3 in the repository, and the path to this artifact is [REPO]/org/codehaus/castor/castor-anttasks/1.1.2-SNAPSHOT. The search results would then look like this: Hits: 3 of 3 castor-anttasks org / codehaus / castor / castor-anttasks | Version(s): 1.1.2-SNAPSHOT castor-anttasks org / codehaus / castor / castor-anttasks | Version(s): 1.1.2-SNAPSHOT castor-anttasks org / codehaus / castor / castor-anttasks | Version(s): 1.1.2-SNAPSHOT When you click either of the versions to browse the artifact, what you would get is this error: 'Unable to find project model for [org.codehaus.castor:castor-anttasks:1.1.2-SNAPSHOT]' > Search and Browse do not work for snapshots > --- > > Key: MRM-425 > URL: http://jira.codehaus.org/browse/MRM-425 > Project: Archiva > Issue Type: Bug > Components: web application >Affects Versions: 1.0-alpha-2 >Reporter: John Didion > > When I to browse or search an artifact with snapshots, I usually get an error > when I try to go to the artifact info page. Looking at the logs, Archiva is > complaining that the version (x.y.z-SNAPSHOT) does not match the pom file's > version (x.y.z-timestamp-buildno). > Ideally, sequence for browse would be group->artifact->base version->snapshot > version. In other words, I would first browse to the base version, under > which would be listed all the snapshot versions. The pom snippet on the base > version page would have x.y.z-SNAPSHOT and the pom snippet > on the snapshot version page would have > x.y.z-timestamp-buildno. I think this would be a lot more > clear than how it currently works - mixing base versions and snapshot > versions on the same page. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MECLIPSE-286) Ability to skip generated-resources/rad6 folder creation while executing eclipse:rad
Ability to skip generated-resources/rad6 folder creation while executing eclipse:rad Key: MECLIPSE-286 URL: http://jira.codehaus.org/browse/MECLIPSE-286 Project: Maven 2.x Eclipse Plugin Issue Type: Improvement Affects Versions: 2.3 Environment: maven 2.0.5 windows xp Reporter: Christian Blavier Attachments: maven-eclipse-plugin-rad.patch Hello, eclipse:rad goal always generate a target/generated-resources/rad6 folder for jar components and add it into eclipse classpath. The problem is that after any mvn clean, the folder is deleted and eclipse complains about a missing classpath entry. That's why, I would like to be able to skip this folder creation (which is useless for my purpose) or at least change the destination directory (not in target) I attached a patch that do followings : - added a generatedResourceDirname parameter - added a default value for this parameter : DEFAULT_GENERATED_RESOURCE_DIRNAME - added a NONE value for this parameter : NO_GENERATED_RESOURCE_DIRNAME - added a test that skip folder generation (and classpath modification) when generatedResourceDirname == NO_GENERATED_RESOURCE_DIR That's all ! :) Thanks -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-257) Unable to do a release with release plug-in
[ http://jira.codehaus.org/browse/MRELEASE-257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100587 ] Pascal ST LAURENT commented on MRELEASE-257: It appears to be the same as [MRELEASE-236] issue. I try the new release 2.0.7 and it is not fixed. > Unable to do a release with release plug-in > --- > > Key: MRELEASE-257 > URL: http://jira.codehaus.org/browse/MRELEASE-257 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-4 > Environment: Windows XP SP2, Maven 2.0.7, JDK 1.5.0_10 >Reporter: Pascal ST LAURENT > > When I try to do a release, I call the following statement : mvn > release:prepare. I received this exception, maybe caused by path too long in > the project... > [ERROR] FATAL ERROR > [INFO] > > [INFO] 60 > [INFO] > > [INFO] Trace > java.lang.ArrayIndexOutOfBoundsException: 60 > at > org.apache.maven.shared.release.phase.RewritePomsForReleasePhase.translateUrlPath(RewritePomsForReleasePhase.java:249) > at > org.apache.maven.shared.release.phase.RewritePomsForReleasePhase.translateScm(RewritePomsForReleasePhase.java:124) > at > org.apache.maven.shared.release.phase.RewritePomsForReleasePhase.transformScm(RewritePomsForReleasePhase.java:61) > at > org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.transformDocument(AbstractRewritePomsPhase.java:271) > at > org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.transformProject(AbstractRewritePomsPhase.java:180) > at > org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.transform(AbstractRewritePomsPhase.java:116) > at > org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.execute(AbstractRewritePomsPhase.java:99) > at > org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:194) > at > org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:131) > at > org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:94) > at > org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:127) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:224) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:280) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRELEASE-257) Unable to do a release with release plug-in
Unable to do a release with release plug-in --- Key: MRELEASE-257 URL: http://jira.codehaus.org/browse/MRELEASE-257 Project: Maven 2.x Release Plugin Issue Type: Bug Affects Versions: 2.0-beta-4 Environment: Windows XP SP2, Maven 2.0.7, JDK 1.5.0_10 Reporter: Pascal ST LAURENT When I try to do a release, I call the following statement : mvn release:prepare. I received this exception, maybe caused by path too long in the project... [ERROR] FATAL ERROR [INFO] [INFO] 60 [INFO] [INFO] Trace java.lang.ArrayIndexOutOfBoundsException: 60 at org.apache.maven.shared.release.phase.RewritePomsForReleasePhase.translateUrlPath(RewritePomsForReleasePhase.java:249) at org.apache.maven.shared.release.phase.RewritePomsForReleasePhase.translateScm(RewritePomsForReleasePhase.java:124) at org.apache.maven.shared.release.phase.RewritePomsForReleasePhase.transformScm(RewritePomsForReleasePhase.java:61) at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.transformDocument(AbstractRewritePomsPhase.java:271) at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.transformProject(AbstractRewritePomsPhase.java:180) at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.transform(AbstractRewritePomsPhase.java:116) at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.execute(AbstractRewritePomsPhase.java:99) at org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:194) at org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:131) at org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:94) at org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:127) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:224) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) at org.apache.maven.cli.MavenCli.main(MavenCli.java:280) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MEAR-70) loader-repository node for jboss configuration
loader-repository node for jboss configuration
--
Key: MEAR-70
URL: http://jira.codehaus.org/browse/MEAR-70
Project: Maven 2.x Ear Plugin
Issue Type: Bug
Affects Versions: 2.3.1
Reporter: Mark Kettner
I added the patch MEAR-50.patch to the 2.3 version of the maven-ear-plugin.
However, after the patch I still couldn't generate a correct jboss-app.xml file
when the pom.xml contained the following definition:
org.apache.maven.plugins
maven-ear-plugin
2.3.1
4
nl.ictu.spg.bsn:loader=afslagbsn
java2ParentDelegation=false
This is because in the file AbstractEarMojo the
final String loaderRepository = jboss.getChild(
JbossConfiguration.LOADER_REPOSITORY ).getValue();
is null when a subtag is added to the loaderRepository tag.
This can be solved by changing the definition in the pom.xml file to the
following:
org.apache.maven.plugins
maven-ear-plugin
2.3.1
4
and change the "write" method in the JbossAppXmlWriter class to the following:
// classloader repository
if ( jbossConfiguration.getLoaderRepository() != null )
{
writer.startElement( JbossConfiguration.LOADER_REPOSITORY );
writer.writeMarkup( jbossConfiguration.getLoaderRepository() );
writer.endElement();
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2900) Extensions that have no declared dependency on plexus-utils yet need it at runtime will fail.
[ http://jira.codehaus.org/browse/MNG-2900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100584 ] Jason van Zyl commented on MNG-2900: In this particular case we are dealing with the webdav extension and this is what we use for Plexus and we deploy all the time. And my test server that has WebDAV enables works without error. Now if you have other extensions that are not WebDAV but something else then we need the specific setup. You can't just say categorically that it doesn't work when this stack track deals specifically with the WebDAV extension. If you are using WebDAV then we need to see the POM for anything else that may be causing you problems. > Extensions that have no declared dependency on plexus-utils yet need it at > runtime will fail. > - > > Key: MNG-2900 > URL: http://jira.codehaus.org/browse/MNG-2900 > Project: Maven 2 > Issue Type: Bug >Reporter: Jason van Zyl >Assignee: Jason van Zyl > Fix For: 2.0.6 > > > This is happening with the WebDAV Wagon: > java.lang.NoClassDefFoundError: org/codehaus/plexus/util/StringUtils > at > org.apache.maven.wagon.providers.webdav.WebDavWagon.put(WebDavWagon.java:192) > at > org.apache.maven.artifact.manager.DefaultWagonManager.putRemoteFile(DefaultWagonManager.java:237) > at > org.apache.maven.artifact.manager.DefaultWagonManager.putArtifact(DefaultWagonManager.java:153) > at > org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:80) > at > org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:162) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:272) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
