ArrayIndexOutOfBoundsException
I am trying to troubleshoot a Hudson build that seems to be directly related to Maven itself, or at least something in a POM file. All of our other builds are fine. I have attempted to chase the bug through the source code via the stack traces, and about the best I could figure out was that _maybe_ there was a problem with a duplicate plugin. I removed the only plugin that was duplicated from the parent (compiler plugin), but had no luck. Installed maven version is 3.0.4. Any help is appreciated. [ERROR] Internal error: java.lang.ArrayIndexOutOfBoundsException: 8194 - [Help 1]org.apache.maven.InternalErrorException: Internal error: java.lang.ArrayIndexOutOfBoundsException: 8194 at org.apache.maven.lifecycle.internal.BuilderCommon.handleBuildError(BuilderCommon.java:128) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:95) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) 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.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) Caused by: java.lang.ArrayIndexOutOfBoundsException: 8194 at org.codehaus.plexus.util.xml.pull.MXParser.parsePI(MXParser.java:2470) at org.codehaus.plexus.util.xml.pull.MXParser.nextImpl(MXParser.java:1257) at org.codehaus.plexus.util.xml.pull.MXParser.next(MXParser.java:1105) at org.codehaus.plexus.util.xml.Xpp3DomBuilder.build(Xpp3DomBuilder.java:179) at org.codehaus.plexus.util.xml.Xpp3DomBuilder.build(Xpp3DomBuilder.java:86) at org.apache.maven.model.io.xpp3.MavenXpp3Reader.parsePluginExecution(MavenXpp3Reader.java:3137) at org.apache.maven.model.io.xpp3.MavenXpp3Reader.parsePlugin(MavenXpp3Reader.java:2918) at org.apache.maven.model.io.xpp3.MavenXpp3Reader.parsePluginManagement(MavenXpp3Reader.java:3186) at org.apache.maven.model.io.xpp3.MavenXpp3Reader.parseBuild(MavenXpp3Reader.java:1157) at org.apache.maven.model.io.xpp3.MavenXpp3Reader.parseModel(MavenXpp3Reader.java:2456) at org.apache.maven.model.io.xpp3.MavenXpp3Reader.read(MavenXpp3Reader.java:4088) at org.apache.maven.model.io.xpp3.MavenXpp3Reader.read(MavenXpp3Reader.java:4021) at org.apache.maven.model.io.DefaultModelReader.read(DefaultModelReader.java:122) at org.apache.maven.model.io.DefaultModelReader.read(DefaultModelReader.java:91) at org.apache.maven.model.building.DefaultModelProcessor.read(DefaultModelProcessor.java:77) at org.apache.maven.model.building.DefaultModelBuilder.readModel(DefaultModelBuilder.java:456)
Re: Maven Profile for distincts web.xml
On Mon, May 27, 2013 at 02:20:15PM -0300, Alberto Ivo wrote: The differences between the web.xml is context-param param-namejavax.faces.PROJECT_STAGE/param-name param-value*Development | Production*/param-value /context-param Shouldn't that sort of information be supplied by the container rather than baked into the app? -- Mark H. Wood, Lead System Programmer mw...@iupui.edu Machines should not be friendly. Machines should be obedient. signature.asc Description: Digital signature
Re: Maven Profile for distincts web.xml
On Tue, May 28, 2013 at 10:37 AM, Mark H. Wood mw...@iupui.edu wrote: On Mon, May 27, 2013 at 02:20:15PM -0300, Alberto Ivo wrote: The differences between the web.xml is context-param param-namejavax.faces.PROJECT_STAGE/param-name param-value*Development | Production*/param-value /context-param Shouldn't that sort of information be supplied by the container rather than baked into the app? That's a good idea.. I will search how to do it! -- Mark H. Wood, Lead System Programmer mw...@iupui.edu Machines should not be friendly. Machines should be obedient.
Re: Maven Profile for distincts web.xml
On 28 May 2013 14:37, Mark H. Wood mw...@iupui.edu wrote: On Mon, May 27, 2013 at 02:20:15PM -0300, Alberto Ivo wrote: The differences between the web.xml is context-param param-namejavax.faces.PROJECT_STAGE/param-name param-value*Development | Production*/param-value /context-param Shouldn't that sort of information be supplied by the container rather than baked into the app? One would think so, but sadly that is not the way the spec was written. According to http://css.dzone.com/news/jsf-20-new-feature-preview-ser You can use a JNDI variable to override: java:comp/env/jsf/ProjectStage So if that works for the JSF impl you are using you should be able to configure the container so that all deployed apps see the java:comp/env/jsf/ProjectStage value you want them to see... thereby removing the problem entirely. Older JSF 2 implementations may have issues though... but should be fine on all JSF 2.1+ etc -- Mark H. Wood, Lead System Programmer mw...@iupui.edu Machines should not be friendly. Machines should be obedient.
Re: Maven Profile for distincts web.xml
On 28/05/2013 9:46 AM, Alberto Ivo wrote: On Tue, May 28, 2013 at 10:37 AM, Mark H. Wood mw...@iupui.edu wrote: On Mon, May 27, 2013 at 02:20:15PM -0300, Alberto Ivo wrote: The differences between the web.xml is context-param param-namejavax.faces.PROJECT_STAGE/param-name param-value*Development | Production*/param-value /context-param Shouldn't that sort of information be supplied by the container rather than baked into the app? That's a good idea.. I will search how to do it! 2 short blogs on ways to do it. Separating Environment from Maven Artifacts http://blog.artifact-software.com/tech/?p=150 Separating Deployment from Development with JNDI http://blog.artifact-software.com/tech/?p=58 Ron -- Mark H. Wood, Lead System Programmer mw...@iupui.edu Machines should not be friendly. Machines should be obedient. -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102
Re: Maven Profile for distincts web.xml
On Tue, May 28, 2013 at 02:49:26PM +0100, Stephen Connolly wrote: On 28 May 2013 14:37, Mark H. Wood mw...@iupui.edu wrote: On Mon, May 27, 2013 at 02:20:15PM -0300, Alberto Ivo wrote: The differences between the web.xml is context-param param-namejavax.faces.PROJECT_STAGE/param-name param-value*Development | Production*/param-value /context-param Shouldn't that sort of information be supplied by the container rather than baked into the app? One would think so, but sadly that is not the way the spec was written. According to http://css.dzone.com/news/jsf-20-new-feature-preview-ser You can use a JNDI variable to override: java:comp/env/jsf/ProjectStage So if that works for the JSF impl you are using you should be able to configure the container so that all deployed apps see the java:comp/env/jsf/ProjectStage value you want them to see... thereby removing the problem entirely. Older JSF 2 implementations may have issues though... but should be fine on all JSF 2.1+ etc I suppose it depends on your container. In Tomcat I'd write an external context descriptor something like: Context ... Parameter name='javax.faces.PROJECT_STAGE' value='Development' override='false'/ /Context and omit the context-param from web.xml, letting the value default to Production. I think I recall being able to do something similar in Jetty. -- Mark H. Wood, Lead System Programmer mw...@iupui.edu Machines should not be friendly. Machines should be obedient. signature.asc Description: Digital signature
Re: Maven Profile for distincts web.xml
jetty's is more fun... though you can hack it with one of the override methods On 28 May 2013 15:05, Mark H. Wood mw...@iupui.edu wrote: On Tue, May 28, 2013 at 02:49:26PM +0100, Stephen Connolly wrote: On 28 May 2013 14:37, Mark H. Wood mw...@iupui.edu wrote: On Mon, May 27, 2013 at 02:20:15PM -0300, Alberto Ivo wrote: The differences between the web.xml is context-param param-namejavax.faces.PROJECT_STAGE/param-name param-value*Development | Production*/param-value /context-param Shouldn't that sort of information be supplied by the container rather than baked into the app? One would think so, but sadly that is not the way the spec was written. According to http://css.dzone.com/news/jsf-20-new-feature-preview-ser You can use a JNDI variable to override: java:comp/env/jsf/ProjectStage So if that works for the JSF impl you are using you should be able to configure the container so that all deployed apps see the java:comp/env/jsf/ProjectStage value you want them to see... thereby removing the problem entirely. Older JSF 2 implementations may have issues though... but should be fine on all JSF 2.1+ etc I suppose it depends on your container. In Tomcat I'd write an external context descriptor something like: Context ... Parameter name='javax.faces.PROJECT_STAGE' value='Development' override='false'/ /Context and omit the context-param from web.xml, letting the value default to Production. I think I recall being able to do something similar in Jetty. -- Mark H. Wood, Lead System Programmer mw...@iupui.edu Machines should not be friendly. Machines should be obedient.
Re: maven3 - getting error on mvn dependency:tree command
mvn -version Apache Maven 3.0 (r1004208; 2010-10-04 07:50:56-0400) Java version: 1.6.0_16 -- View this message in context: http://maven.40175.n5.nabble.com/maven3-getting-error-on-mvn-dependency-tree-command-tp5756424p5757150.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven3 - getting error on mvn dependency:tree command
Can you please try with maven 3.0.5 ? Thanks 2013/5/28 coolguy sanke...@gmail.com mvn -version Apache Maven 3.0 (r1004208; 2010-10-04 07:50:56-0400) Java version: 1.6.0_16 -- View this message in context: http://maven.40175.n5.nabble.com/maven3-getting-error-on-mvn-dependency-tree-command-tp5756424p5757150.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Baptiste Batmat MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor !
Re: Maven Profile for distincts web.xml
Any idea on JBoss 7 AS? Ivo On Tue, May 28, 2013 at 11:14 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: jetty's is more fun... though you can hack it with one of the override methods On 28 May 2013 15:05, Mark H. Wood mw...@iupui.edu wrote: On Tue, May 28, 2013 at 02:49:26PM +0100, Stephen Connolly wrote: On 28 May 2013 14:37, Mark H. Wood mw...@iupui.edu wrote: On Mon, May 27, 2013 at 02:20:15PM -0300, Alberto Ivo wrote: The differences between the web.xml is context-param param-namejavax.faces.PROJECT_STAGE/param-name param-value*Development | Production*/param-value /context-param Shouldn't that sort of information be supplied by the container rather than baked into the app? One would think so, but sadly that is not the way the spec was written. According to http://css.dzone.com/news/jsf-20-new-feature-preview-ser You can use a JNDI variable to override: java:comp/env/jsf/ProjectStage So if that works for the JSF impl you are using you should be able to configure the container so that all deployed apps see the java:comp/env/jsf/ProjectStage value you want them to see... thereby removing the problem entirely. Older JSF 2 implementations may have issues though... but should be fine on all JSF 2.1+ etc I suppose it depends on your container. In Tomcat I'd write an external context descriptor something like: Context ... Parameter name='javax.faces.PROJECT_STAGE' value='Development' override='false'/ /Context and omit the context-param from web.xml, letting the value default to Production. I think I recall being able to do something similar in Jetty. -- Mark H. Wood, Lead System Programmer mw...@iupui.edu Machines should not be friendly. Machines should be obedient.
Re: Maven Profile for distincts web.xml
http://bit.ly/18wuJIj On 28 May 2013 15:33, Alberto Ivo alberto...@gmail.com wrote: Any idea on JBoss 7 AS? Ivo On Tue, May 28, 2013 at 11:14 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: jetty's is more fun... though you can hack it with one of the override methods On 28 May 2013 15:05, Mark H. Wood mw...@iupui.edu wrote: On Tue, May 28, 2013 at 02:49:26PM +0100, Stephen Connolly wrote: On 28 May 2013 14:37, Mark H. Wood mw...@iupui.edu wrote: On Mon, May 27, 2013 at 02:20:15PM -0300, Alberto Ivo wrote: The differences between the web.xml is context-param param-namejavax.faces.PROJECT_STAGE/param-name param-value*Development | Production*/param-value /context-param Shouldn't that sort of information be supplied by the container rather than baked into the app? One would think so, but sadly that is not the way the spec was written. According to http://css.dzone.com/news/jsf-20-new-feature-preview-ser You can use a JNDI variable to override: java:comp/env/jsf/ProjectStage So if that works for the JSF impl you are using you should be able to configure the container so that all deployed apps see the java:comp/env/jsf/ProjectStage value you want them to see... thereby removing the problem entirely. Older JSF 2 implementations may have issues though... but should be fine on all JSF 2.1+ etc I suppose it depends on your container. In Tomcat I'd write an external context descriptor something like: Context ... Parameter name='javax.faces.PROJECT_STAGE' value='Development' override='false'/ /Context and omit the context-param from web.xml, letting the value default to Production. I think I recall being able to do something similar in Jetty. -- Mark H. Wood, Lead System Programmer mw...@iupui.edu Machines should not be friendly. Machines should be obedient.
Re: Maven Profile for distincts web.xml
Sorry wrong link... you want http://bit.ly/18wuQUc On 28 May 2013 15:41, Stephen Connolly stephen.alan.conno...@gmail.comwrote: http://bit.ly/18wuJIj On 28 May 2013 15:33, Alberto Ivo alberto...@gmail.com wrote: Any idea on JBoss 7 AS? Ivo On Tue, May 28, 2013 at 11:14 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: jetty's is more fun... though you can hack it with one of the override methods On 28 May 2013 15:05, Mark H. Wood mw...@iupui.edu wrote: On Tue, May 28, 2013 at 02:49:26PM +0100, Stephen Connolly wrote: On 28 May 2013 14:37, Mark H. Wood mw...@iupui.edu wrote: On Mon, May 27, 2013 at 02:20:15PM -0300, Alberto Ivo wrote: The differences between the web.xml is context-param param-namejavax.faces.PROJECT_STAGE/param-name param-value*Development | Production*/param-value /context-param Shouldn't that sort of information be supplied by the container rather than baked into the app? One would think so, but sadly that is not the way the spec was written. According to http://css.dzone.com/news/jsf-20-new-feature-preview-ser You can use a JNDI variable to override: java:comp/env/jsf/ProjectStage So if that works for the JSF impl you are using you should be able to configure the container so that all deployed apps see the java:comp/env/jsf/ProjectStage value you want them to see... thereby removing the problem entirely. Older JSF 2 implementations may have issues though... but should be fine on all JSF 2.1+ etc I suppose it depends on your container. In Tomcat I'd write an external context descriptor something like: Context ... Parameter name='javax.faces.PROJECT_STAGE' value='Development' override='false'/ /Context and omit the context-param from web.xml, letting the value default to Production. I think I recall being able to do something similar in Jetty. -- Mark H. Wood, Lead System Programmer mw...@iupui.edu Machines should not be friendly. Machines should be obedient.
RE: maven 3 doesn't use reactor to find parent - revert to maven 2 behaviour
Is this what you are seeing? Sort of. But it seems you have assigned relativePath to a non- empty value, something I think is incorrect in this kind of setup. I believe my setup was described in enough detail in my previous post. I used no relativePath elements. The non-resolvable parent POM error, I believe is due to the reactor attempts to determine the processing order. I see no reason why Maven cannot locate all aggregated modules first using the reactor, and resolve parent+dependencies in the next phase. Then this is a non-issue. I believe this is how Maven 2 works. Your case (3) is not following any accepted pattern that Maven supports. It seems this was an accepted pattern in Maven 2 but not in Maven 3. Or are you saying this was not an accepted pattern in Maven 2 either, and worked by fluke? As you suggested previously I will bring this subject to the dev list, see post parent pom lookup in reactor. Best regards Mike Russell Gold wrote: OK, I think I have managed to duplicate the behavior. Is this what you are seeing? [ERROR] [ERROR] The project com.packtpub.maven:obfuscate:1.0 (/Users/russgold/projects/maven-course/sample4/obfuscator/pom. xml) has 1 error [ERROR] Non-resolvable parent POM: Could not find artifact com.packtpub.maven:parent4:pom:1.0 in central (http://repo.maven.apache.org/maven2) and 'parent.relativePath' points at wrong local POM @ line 5, column 13 - [Help 2] The non-resolvable parent POM error, I believe is due to the reactor attempts to determine the processing order. It reads each pom to see what its dependencies are - but part of those dependencies could themselves be defined in the parent, so it needs to be able to resolve the parent as part of this process. If you use the conventional pattern in which a parent aggregates its children, then the reactor already knows the parent. If you don't, unless the parent is already in the repository, it has no way of knowing what the parent is in order to determine the proper build order. It may be that in Maven 2, this determination was not done, and the module order specified by the aggregator was followed blindly. Your case (3) is not following any accepted pattern that Maven supports. It is often said, if you fight with Maven, you will lose. On May 27, 2013, at 12:01 PM, Russell Gold r...@gold-family.us wrote: I'm having trouble understanding your use case still, I think - and you are disregarding the general pattern that child poms are found nested under their parent; however, from your description, I don't see why this wouldn't work. Can you make a small sample project that displays the problematic behavior and post it somewhere? On May 24, 2013, at 10:07 AM, Mike Wilson mike...@hotmail.com wrote: There are many variations, but here is a simplification of our own scenario: 1) Consider a number of standalone modules with their own release cycles in their own VCS repos: parent/ [vcs0] pom.xml (1.0.0) module1/ [vcs1] pom.xml (1.1.0, parent=parent-1.0.0) module2/ [vcs2] ... 2) Team 1 is updating module1 in feature branch f1: module1/ [vcs1] pom.xml (1.2.0-f1-SNAPSHOT, parent=parent-1.0.0) They want to refer to the pre-built released parent from repo. 3) Team 2 is updating module1 and the parent in feature branch f2. They have aggregated all modules they are working on in a feature workspace pom for easy building: feature2workspace/ [aggregation root] pom.xml (modules=parent,module1) parent/ [vcs0] pom.xml (1.1.0-f2-SNAPSHOT) module1/ [vcs1] pom.xml (1.2.0-f2-SNAPSHOT, parent=parent-1.1.0-f2-SNAPSHOT) They want to refer to the local checkout of parent. As you can see, module1 can not make any assumption about what filesystem directory the parent module resides in, so no relativePath element can be added. In Maven 2 there is success when building the feature workspace from root, but Maven 3 fails. To get it working in Maven 3 we either have to maintain relativePath elements that are different for every feature-branch (and deal with them when merging back into main = error-prone), or manually have to deal with build order within the feature workspace. In reality our case is made up of hundreds of standalone modules and parent/sub-repos used for the aggregation level, representing a feature or team branch where the root pom.xml is thus shared between team members through the parent repo. Best regards Mike Russell Gold wrote: Only the developers could say for sure, but I would guess that it was done as part of code cleanup - that it's not so much that they wanted to remove the feature as it was that cleaning up the code might have made it hard to support the feature - and there was no particular reason to keep it. But that's just a guess. I am not on the development team and
How to generate source as webpage
Which plugin I have to use if I want generate webpage which shows source of java file... See at http://dddsample.sourceforge.net/xref/se/citerus/dddsample/domain/model/handling/HandlingEvent.html there is a behaviour which I need. Thx -- View this message in context: http://maven.40175.n5.nabble.com/How-to-generate-source-as-webpage-tp5757138.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven3 - getting error on mvn dependency:tree command
Thank you, Baptiste MATHUS-2 ! It works fine with maven 3.0.5 -- View this message in context: http://maven.40175.n5.nabble.com/maven3-getting-error-on-mvn-dependency-tree-command-tp5756424p5757160.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: How to generate source as webpage
http://maven.apache.org/plugins/maven-jxr-plugin/ Which plugin I have to use if I want generate webpage which shows source of java file... See at http://dddsample.sourceforge.net/xref/se/citerus/dddsample/domain/model/handling/HandlingEvent.html there is a behaviour which I need. Thx -- View this message in context: http://maven.40175.n5.nabble.com/How-to-generate-source-as-webpage-tp5757138.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: How to generate source as webpage
Which plugin I have to use if I want generate webpage which shows source of java file... Go to the Maven home page: http://maven.apache.org/ On the left, click on Maven Plugins under Documentation. Scroll down to Reporting Plugins and read the descriptions to find the one you want. Hint: it is called JXR. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: ArrayIndexOutOfBoundsException
It would appear you have a broken XML processing instruction somewhere, the kind that looks like this; ?xml version=1.0 encoding=UTF-8 ? Kristian 2013/5/28 Jason Ferguson fergusonja...@gmail.com: I am trying to troubleshoot a Hudson build that seems to be directly related to Maven itself, or at least something in a POM file. All of our other builds are fine. I have attempted to chase the bug through the source code via the stack traces, and about the best I could figure out was that _maybe_ there was a problem with a duplicate plugin. I removed the only plugin that was duplicated from the parent (compiler plugin), but had no luck. Installed maven version is 3.0.4. Any help is appreciated. [ERROR] Internal error: java.lang.ArrayIndexOutOfBoundsException: 8194 - [Help 1]org.apache.maven.InternalErrorException: Internal error: java.lang.ArrayIndexOutOfBoundsException: 8194 at org.apache.maven.lifecycle.internal.BuilderCommon.handleBuildError(BuilderCommon.java:128) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:95) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) 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.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) Caused by: java.lang.ArrayIndexOutOfBoundsException: 8194 at org.codehaus.plexus.util.xml.pull.MXParser.parsePI(MXParser.java:2470) at org.codehaus.plexus.util.xml.pull.MXParser.nextImpl(MXParser.java:1257) at org.codehaus.plexus.util.xml.pull.MXParser.next(MXParser.java:1105) at org.codehaus.plexus.util.xml.Xpp3DomBuilder.build(Xpp3DomBuilder.java:179) at org.codehaus.plexus.util.xml.Xpp3DomBuilder.build(Xpp3DomBuilder.java:86) at org.apache.maven.model.io.xpp3.MavenXpp3Reader.parsePluginExecution(MavenXpp3Reader.java:3137) at org.apache.maven.model.io.xpp3.MavenXpp3Reader.parsePlugin(MavenXpp3Reader.java:2918) at org.apache.maven.model.io.xpp3.MavenXpp3Reader.parsePluginManagement(MavenXpp3Reader.java:3186) at org.apache.maven.model.io.xpp3.MavenXpp3Reader.parseBuild(MavenXpp3Reader.java:1157) at org.apache.maven.model.io.xpp3.MavenXpp3Reader.parseModel(MavenXpp3Reader.java:2456) at org.apache.maven.model.io.xpp3.MavenXpp3Reader.read(MavenXpp3Reader.java:4088) at org.apache.maven.model.io.xpp3.MavenXpp3Reader.read(MavenXpp3Reader.java:4021) at org.apache.maven.model.io.DefaultModelReader.read(DefaultModelReader.java:122) at org.apache.maven.model.io.DefaultModelReader.read(DefaultModelReader.java:91) at org.apache.maven.model.building.DefaultModelProcessor.read(DefaultModelProcessor.java:77) at org.apache.maven.model.building.DefaultModelBuilder.readModel(DefaultModelBuilder.java:456) - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
re: Assembly and moving dependencies (JNLP style project)
I am converting a JNLP style project (we are actually using a modified Getdown, but the basic concepts are the same) - so the project is a kind of hybrid, under normal circumstances it would be built as a jar, however, since it installs from a server it is currently being built as a war. The issue is that, as a war it requires none of the project dependencies (well, actually there is one) to actually run *on the server* -- but the dependencies must be there for access upon the installers request. The one issue is that the dependencies cannot (and really should not) be in the WEB-INF/lib folder (typically they reside at the root so they can be retrieved via http://myserver/myproject/some.jar). My first question is if anyone else is doing builds for these types of projects what approach do you use? I have not found a plugin for Getdown projects that does proper assembly. The JNLP plugin *might* produce some of this, but it is not an exact fit for my non-JNLP web installer Barring any answers to that, how can I move - or gain access to a list of - the project dependencies? I have been looking at the assembly plugin, but that seems to only allow you to include add'l files (or exclude some). Were I to exclude my dependencies: excludecommons-lang:commons-lang/exclude I would have to (1) hard code each dependency to exclude and (2) hard code, in some way, to move specific dependencies into the root of the war. I would like to be able to do this in a more flexible manner so that I don't have to change multiple files when I add or remove a dependency to my project. Perhaps I could use a some wildcarding in there, but for #2 I don't want all dependencies to be moved and I don't want those, that are moved, all moved to the same location. The additional piece of this is that the installer requires a XML file which lists all of the artifacts that the client needs to run. In the same way I need to move those dependencies around, if I could create a section of that XML file from a build-time list of dependencies that would also make this process much cleaner as well; all of my dependency related items would come from the POM. I know this is kind of a lot, but hopefully someone out there has had to deal with this before and can provide some much needed insight for making a nice clean build for this type of project. Thanks scott
Re: Assembly and moving dependencies (JNLP style project)
I think the simplest thing to do is to write a plugin This gives you a multitude of advantages. You get to create the xml file yourself. You get to package everything out the way you want. Then create a ZIP of the whole lot and attach that to the reactor. The ZIP is what your build produces... If you then need to wrap that in a WAR flle, you just add it as a dependency (typezip/type) to your WAR project and it will get expanded and overlayed into the WAR file. So the plugin will have the following: 1. A custom lifecycle 2. A goal that creates the XML file from the project dependencies 3. A goal that copies the dependencies into the required location 4. A goal that zips up the dependencies and the XML file and attaches that ZIP to the reactor And if you do all that, anyone needing a getdown project will just have to do packaginggetdown/packaging And presto they are done... nice simple pom file The work involved in the plugin is not too bad... the goals can mostly be copypaste developed from existing plugins, and the custom lifecycle is the final polish (just a file in the plugin's resources) HTH -Stephen On 28 May 2013 19:45, Scott Klein scott.kl...@goldenhour.com wrote: I am converting a JNLP style project (we are actually using a modified Getdown, but the basic concepts are the same) - so the project is a kind of hybrid, under normal circumstances it would be built as a jar, however, since it installs from a server it is currently being built as a war. The issue is that, as a war it requires none of the project dependencies (well, actually there is one) to actually run *on the server* -- but the dependencies must be there for access upon the installers request. The one issue is that the dependencies cannot (and really should not) be in the WEB-INF/lib folder (typically they reside at the root so they can be retrieved via http://myserver/myproject/some.jar). My first question is if anyone else is doing builds for these types of projects what approach do you use? I have not found a plugin for Getdown projects that does proper assembly. The JNLP plugin *might* produce some of this, but it is not an exact fit for my non-JNLP web installer Barring any answers to that, how can I move - or gain access to a list of - the project dependencies? I have been looking at the assembly plugin, but that seems to only allow you to include add'l files (or exclude some). Were I to exclude my dependencies: excludecommons-lang:commons-lang/exclude I would have to (1) hard code each dependency to exclude and (2) hard code, in some way, to move specific dependencies into the root of the war. I would like to be able to do this in a more flexible manner so that I don't have to change multiple files when I add or remove a dependency to my project. Perhaps I could use a some wildcarding in there, but for #2 I don't want all dependencies to be moved and I don't want those, that are moved, all moved to the same location. The additional piece of this is that the installer requires a XML file which lists all of the artifacts that the client needs to run. In the same way I need to move those dependencies around, if I could create a section of that XML file from a build-time list of dependencies that would also make this process much cleaner as well; all of my dependency related items would come from the POM. I know this is kind of a lot, but hopefully someone out there has had to deal with this before and can provide some much needed insight for making a nice clean build for this type of project. Thanks scott
Re: maven 3 doesn't use reactor to find parent - revert to maven 2 behaviour
2013/5/28 Mike Wilson mike...@hotmail.com Is this what you are seeing? Sort of. But it seems you have assigned relativePath to a non- empty value, something I think is incorrect in this kind of setup. I believe my setup was described in enough detail in my previous post. I used no relativePath elements. The non-resolvable parent POM error, I believe is due to the reactor attempts to determine the processing order. I see no reason why Maven cannot locate all aggregated modules first using the reactor, and resolve parent+dependencies in the next phase. Then this is a non-issue. I believe this is how Maven 2 works. Your case (3) is not following any accepted pattern that Maven supports. It seems this was an accepted pattern in Maven 2 but not in Maven 3. Or are you saying this was not an accepted pattern in Maven 2 either, and worked by fluke? Didn't dig on that very subject, but IIRC, kind of. Parent pom could sometime be downloaded although it *was* part of the reactor. Being more explicit and less permissive is one of the features of m3 (as is the build reproducibility for maven in general). Cheers
Re: maven 3 doesn't use reactor to find parent - revert to maven 2 behaviour
On 28 May 2013 20:22, Baptiste MATHUS bmat...@batmat.net wrote: 2013/5/28 Mike Wilson mike...@hotmail.com Is this what you are seeing? Sort of. But it seems you have assigned relativePath to a non- empty value, something I think is incorrect in this kind of setup. I believe my setup was described in enough detail in my previous post. I used no relativePath elements. The non-resolvable parent POM error, I believe is due to the reactor attempts to determine the processing order. I see no reason why Maven cannot locate all aggregated modules first using the reactor, and resolve parent+dependencies in the next phase. Then this is a non-issue. I believe this is how Maven 2 works. Your case (3) is not following any accepted pattern that Maven supports. It seems this was an accepted pattern in Maven 2 but not in Maven 3. Or are you saying this was not an accepted pattern in Maven 2 either, and worked by fluke? Didn't dig on that very subject, but IIRC, kind of. Parent pom could sometime be downloaded although it *was* part of the reactor. Being more explicit and less permissive is one of the features of m3 (as is the build reproducibility for maven in general). IIRC another issue was that if the parent from the reactor has a different version from the parent specified in the pom, Maven 2.x just uses the one from the reactor while with this fix Maven 3.x will correctly attempt to download and use the specified version from the remote reposotory / local cache I have not tested if this change allows Maven 3 to have two different versions of the same GA within the one reactor... but irrespective of that issue it does allow the parent version to be disconnected from the version picked up by child poms
pre-site binding examples?
Hi, I'm looking for an example of a plugin that runs in the pre-site phase. I used to generate web pages dynamically from data stored in xml, using java classes to format various xml files, and I'm looking for a way to do that in maven. I presume that I want something analogous to the way code generation works - a code generator can add source paths that the javac plugin will see. Is there something equivalent for the site plugin? Thanks Russ - Come read my webnovel, Take a Lemon http://www.takealemon.com, and listen to the Misfile radio play http://www.gold-family.us/audio/misfile.html!
