Re: [poll] Requiring users to specify plugin versions in Maven 2.1 or later
I should start by saying that I haven't followed the entire thread on this subject, so if something I say here has been beat to death elsewhere just write me off as a lurker and go on... I have started specifying versions for all lifecycle plugins in my "company POM" with the hopes that would be enough to lock all plugin versions. If you can make it so that I can specify something like "org.apache.maven.pom:lifecycle:2.0.7" or "com.mycompany:plugin-versions:1.1.6" (with all the proper XML around it, of course) as a dependency/mix-in/etc which would lock down all of the plugin versions, I am all in favor of (A). Part of the difficulty in this is getting all of the plugins to lock down their dependencies so that using version x.y.z of a plugin will always and forever more use the same specific version of each dependency. If something as simple as described above is not feasible, then I think we must go the route of (B) to avoid major user (and especially new user) headaches just trying to get a simple project started. Another possibility, although probably a major PITA, would be to allow but warn if versions are not specified if the project version is a snapshot. This would allow a user to start version x.y.z-SNAPSHOT of a project, comment out the version numbers for the plugins, and get the current versions downloaded and identified. When the user is ready to lock down the plugin versions, they just fill in the version numbers from the messages produced during the build. The biggest problem with this is identifying which plugins should produce a warning. One last idea: Since this is likely to involve a increment in the model version (I think I saw "4.1.0"), how about adding a required model element with a syntax like "parent" which specifies the version list? If it can be inherited, it makes it easy to specify the value for entire project trees. By making it required (or producing a warning if not specified), you encourage users to make the specification. If each Maven release provides an example with the latest release versions of each plugin at the time the Maven release is created, then there would be very little editing required by the user to make a custom version to update certain plugins; the new user can get everything specified automatically with a very short POM so the amount of typing required just to get a project off the ground would be minimal. - Original Message - From: "Brett Porter" <[EMAIL PROTECTED]> To: "Maven Developers List" Sent: Saturday, September 01, 2007 10:48 PM Subject: [poll] Requiring users to specify plugin versions in Maven 2.1 or later I'd like to hear from as many people as possible their opinion this topic (even if you just want to say '0' so we know where you stand). [ ] (A) All plugin versions must be specified by the project or its parent hierarchy somewhere, at the cost of some verbosity (though we should look at ways to make this easier/smaller/etc per the current discussion) [ ] (B) Retain the current behaviour, but make using the enforcer a best practice to do the above, or some other control mechanism such as having the repository manager handle the available plugins [ ] (C) No opinion [ ] (D) Undecided [ ] (E) Other (please specify) Thanks, Brett -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Lifecycle issues with Cobertura plugin and custom plugin
I thought you were using Maven 2. The Maven 2 plugin v2.1 uses Cobertura 1.8 which exhibits this problem. By downgrading the plugin to v2.0, you use v1.7 of Cobertura which does not have this problem. - Original Message - From: "Ralph Goers" <[EMAIL PROTECTED]> To: "Maven Developers List" Sent: Wednesday, February 07, 2007 9:14 AM Subject: Re: Lifecycle issues with Cobertura plugin and custom plugin What is this well known problem. I tried upgrading the plugin for maven 1.0.2 from version 1.1.1 of cobertura to 1.3 and have the same problem - all the reports show 0 coverage. Ralph Bob Allison wrote: Sounds like the well-known Cobertura 2.1 problem. Try explicitly specifying version 2.0 of the plugin and see if that fixes it. - Original Message - From: "drekka" <[EMAIL PROTECTED]> To: Sent: Wednesday, February 07, 2007 1:13 AM Subject: Lifecycle issues with Cobertura plugin and custom plugin Hi guys, I've been trying to nut this out for a couple of days now and need your help. A few weeks ago I wrote a Junit4 plugin which works perfectly in the test phase. It doesn't fork or anything fancy, just gets on with the job. It's header contains the following annotations: * @requiresDependencyResolution test * @goal runJunit4Tests * @phase test However when I added the Cobertrua plugin to the mix, the cobertura report keeps reporting 0% coverage. The logs indicate that my plugin is working and using the generated-classes/cobertura/ directory. It also indicates that the classes are being instrumented correctly. yet looking at the .ser file cobertura uses it would appear that either the instrumented classes are not logging correctly or not being used as nothing is appended to the file. This lead me to conclude that there is something wrong with the way I've setup the plugin within maven. From reading the source of the cobertura plugin it appears that the plugin forks a new process to run the test phase again. At this point I'm not sure what happens as the maven doco is really hard to follow and leave me with more questions than answers. The logs indicate that the test are run twice. Once before instrumenting and once after. I've looked for any direct connection between the surefire and cobertura plugins but cannot see anything. Any ideas guys ? ciao Derek -- View this message in context: http://www.nabble.com/Lifecycle-issues-with-Cobertura-plugin-and-custom-plugin-tf3185205s177.html#a8840433 Sent from the Maven Developers mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Lifecycle issues with Cobertura plugin and custom plugin
Sounds like the well-known Cobertura 2.1 problem. Try explicitly specifying version 2.0 of the plugin and see if that fixes it. - Original Message - From: "drekka" <[EMAIL PROTECTED]> To: Sent: Wednesday, February 07, 2007 1:13 AM Subject: Lifecycle issues with Cobertura plugin and custom plugin Hi guys, I've been trying to nut this out for a couple of days now and need your help. A few weeks ago I wrote a Junit4 plugin which works perfectly in the test phase. It doesn't fork or anything fancy, just gets on with the job. It's header contains the following annotations: * @requiresDependencyResolution test * @goal runJunit4Tests * @phase test However when I added the Cobertrua plugin to the mix, the cobertura report keeps reporting 0% coverage. The logs indicate that my plugin is working and using the generated-classes/cobertura/ directory. It also indicates that the classes are being instrumented correctly. yet looking at the .ser file cobertura uses it would appear that either the instrumented classes are not logging correctly or not being used as nothing is appended to the file. This lead me to conclude that there is something wrong with the way I've setup the plugin within maven. From reading the source of the cobertura plugin it appears that the plugin forks a new process to run the test phase again. At this point I'm not sure what happens as the maven doco is really hard to follow and leave me with more questions than answers. The logs indicate that the test are run twice. Once before instrumenting and once after. I've looked for any direct connection between the surefire and cobertura plugins but cannot see anything. Any ideas guys ? ciao Derek -- View this message in context: http://www.nabble.com/Lifecycle-issues-with-Cobertura-plugin-and-custom-plugin-tf3185205s177.html#a8840433 Sent from the Maven Developers mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using maven to build RPMs and problems with the RPM database
The RPM plugin I wrote in Codehaus uses a subdirectory of
"${basedir}/target" as the place where everything to be packaged is
assembled. This should mean that the _BUILD_ of an RPM can run in parallel
with another _BUILD_.
It is always going to be bad form to try to do multiple _INSTALL_ actions in
parallel. Usually, the RPM command line tool will detect that the database
is locked (since step one in doing an install is to lock the database so you
can update it); I can easily see some race conditions where this might not
always work.
HTH
- Original Message -
From: "John Casey" <[EMAIL PROTECTED]>
To: "Maven Developers List"
Sent: Wednesday, January 31, 2007 2:37 PM
Subject: Re: Using maven to build RPMs and problems with the RPM database
Concurrency is an issue any way you slice it, and it's not just limited to
RPMs. RPMs represent a set of files installed on the system, so you have
to
somehow verify that you're not installing the same RPM _or_file_list_ on
one
system at the same time. Granted, this isn't as severe a limitation as the
concurrent modification problem in the rpm database, but it's still an
important factor.
So, if a dev team is sharing a machine and needs to do concurrent
build/installs - or, in CI situations where a similar thing is happening -
it might be essential to setup some sort of chroot setup with a separate
rpm
database for each, so the filesystem paths don't overwrite. This is a BIG
thing to tackle in any sort of universal way, and I'm not even going to
pretend to understand all that would be involved...only that it's much
more
than just dealing with the RPM database.
It's not arbitrary classpaths out here, and we're not in Kansas anymore.
:-)
-john
On 1/31/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:
Hi,
I'm just throwing out a question because I have experience a problem
with concurrency in the RPM database. Over in the CBUILDs stuff where
we are using Maven to build RPMs whenever I do two simultaneous
builds where the result is installing an RPM I seem to corrupt the
database rendering RPM useless without rebuilding the RPM database.
I've read in some places that you cannot run RPM commands in parallel
because of concurrency issues. I'm locked to RHEL 3. If there was a
locking mechanism I suppose that would be someone better but means
all my builds are going to block on the lock. But if there are
concurrency issues that means trying to build RPMs during a
development is impractical. Anyone have a definitive answer on this
or a pointer to some documentation? I'm going to try and contact Erik
Troan for a definitive answer but if anyone knows please pipe up! :-)
Jason.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Request for Summary element in POM
The reason I mentioned it is that the plugin WRITES the spec file it uses. You might want to see how I mapped POM elements into the spec file. There is likely to be a difference in how we are doing things, in which case it would be good to use a uniform mapping of elements. - Original Message - From: "Ole Ersoy" <[EMAIL PROTECTED]> To: "Maven Developers List" Sent: Monday, December 25, 2006 9:25 PM Subject: Re: Request for Summary element in POM Hey Bob, Thanks for the tip. I'll probably have a look later for comparison of my approach vs. that mojo's approach. Perhaps an even better mojo could be made from the combination of the two approaches :-) I'm using Eclipse's EMF project that allows me to easily map various POM elements to their corresponding spec values using fragment path annotations on the SpecDescriptor ecore model I created. I wanted to see whether would lean to a cleaner overall and more manageable design. Anyways, Regardless of which mojo is used to generate the spec, a Summary element on the POM would still be very useful. I could just put it on the SpecDescriptor model, but then the JPackage project, and any other project, that wants to generate RPMs using Maven would need to provide this value outside of Maven. This means that someone other than the original project creator is providing the summary or description on the spec file, which equals less collaboration / consensus between the original project creator and the spec writer. Cheers, - Ole --- Bob Allison <[EMAIL PROTECTED]> wrote: You might take a look at the RPM plugin in the Mojo sandbox... - Original Message - From: "Ole Ersoy" <[EMAIL PROTECTED]> To: "Maven Developers List" Sent: Sunday, December 24, 2006 4:38 PM Subject: Request for Summary element in POM > Hi, > > I'm in the process of releasing an RPM Spec generator > for the JPackage project, and noticed that there is a > description element in the pom, but no summary > element. > > If a summary element were added it would make JPackage > spec generation more efficient, assuming various > projects would put both elements to use. > > Can we add a summary element to the pom? > > I think this would be a convienent element to have > in the sense that description could now be more of a > detailed description and the summary...well a summary > :-) > > I could put a JIRA in for this and update the xml > schema if this sounds reasonable. > > Thanks, > - Ole > > > > __ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Request for Summary element in POM
You might take a look at the RPM plugin in the Mojo sandbox... - Original Message - From: "Ole Ersoy" <[EMAIL PROTECTED]> To: "Maven Developers List" Sent: Sunday, December 24, 2006 4:38 PM Subject: Request for Summary element in POM Hi, I'm in the process of releasing an RPM Spec generator for the JPackage project, and noticed that there is a description element in the pom, but no summary element. If a summary element were added it would make JPackage spec generation more efficient, assuming various projects would put both elements to use. Can we add a summary element to the pom? I think this would be a convienent element to have in the sense that description could now be more of a detailed description and the summary...well a summary :-) I could put a JIRA in for this and update the xml schema if this sounds reasonable. Thanks, - Ole __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven and Fedora
I have only been half following this thread so please excuse me if what I say is OT or repeats what someone else said. As the author of the RPM plugin, I think I can safely say that we could easily build RPMs of each Maven release (containing the same content as the tarball) that installs by default into a place like "/usr/maven/2.0.4" but can be relocated at the whim of the experienced admin. As long as each release installs into a directory specific to the release (no overlap on files) the user can install as many releases as they want and put the release they want to use on the path. This would make installation easier for those who don't like to use tar/unzip, don't want to think about where things should be installed, or who are doing a gazillion machines (like I used to do) and need a way to mass-install. If we want to get real fancy, we could even set up a means where each Maven RPM updates some symlink in /usr/bin to point to itself; that gets us automatic upgrades when a new RPM is installed. I will be the first to admit that this does not precisely fit into the Linux standard filesystem. So what? There are a lot of packages, some very big, that don't choose to install into Linux differently than they install into Solaris or HP-UX. All of the Maven documentation is based around the entire tarball being unpacked into a single directory and used from there, and we can easily make an RPM that does exactly that for those who prefer. - Original Message - From: "Jason van Zyl" <[EMAIL PROTECTED]> To: "Maven Developers List" Sent: Saturday, December 09, 2006 12:16 PM Subject: Re: Maven and Fedora On 9 Dec 06, at 11:06 AM 9 Dec 06, David Whitehurst wrote: I'm an AppFuse person that listens here and I agree wholeheartedly with Jason. All of the linux variations have a graphical file explorer and some unzip facility. You just do the following: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-2039) Fails to install netbeans-freeform plugin
[ http://jira.codehaus.org/browse/MNG-2039?page=comments#action_57866 ] Bob Allison commented on MNG-2039: -- The NetBeans-Freeform plugin is currently in the Mojo sandbox. I believe you need to build it from source. > Fails to install netbeans-freeform plugin > - > > Key: MNG-2039 > URL: http://jira.codehaus.org/browse/MNG-2039 > Project: Maven 2 > Type: Bug > Versions: documentation > Environment: Maven 2.0.2, Mac OS X 10.4.2, Java 1.5.0_05 NetBeans 5.0RC2 > Reporter: Travis Risner > Assignee: Brett Porter > Attachments: maven2bug txt > > > At > http://maven.apache.org/guides/mini/guide-ide-netbeans/guide-ide-netbeans.html, > the second step says to run "mvn > netbeans-freeform:generate-netbeans-project", but instead of a successful > download and build, I get the error message and stack trace shown in the > attachment.. > If I picked the wrong category to file this bug, please put it where it > belongs. > If you need more information, let me know. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MCOMPILER-13) New Mojos for compiler and jar plugins to allow alternate jars
[ http://jira.codehaus.org/browse/MCOMPILER-13?page=comments#action_55628 ] Bob Allison commented on MCOMPILER-13: -- I should probably add that the mock object sources are in a different source tree than the implementation sources, as opposed to merely needing to filter which classes go in which jar. > New Mojos for compiler and jar plugins to allow alternate jars > -- > > Key: MCOMPILER-13 > URL: http://jira.codehaus.org/browse/MCOMPILER-13 > Project: Maven 2.x Compiler Plugin > Type: Bug > Environment: Linux using JDK 1.5.0_01 > Reporter: Bob Allison > Attachments: AltCompilerMojo.java, AltJarMojo.java, pom.xml > > > Add mojos so that mock objects and other affiliated source roots can be > compiled and packaged in the same project -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MCOMPILER-13) New Mojos for compiler and jar plugins to allow alternate jars
[ http://jira.codehaus.org/browse/MCOMPILER-13?page=comments#action_55627 ] Bob Allison commented on MCOMPILER-13: -- If we use a profile to change the sourceDirectory, how do I do the following in a single build (since this has to run from the reactor): -- Build the implementation jar (no classifier) -- Build the mock-object jar (classifier = "mock") -- Install both jars in the repository for the next module to use OK, the third is easy if the mock-object jar is added to the artifact list. The main reason for the new Mojos (or altering the existing ones) si so that I can have multiple executions of the compiler and jar Mojos during the same run. If there is a means to do this without altering the existing compiler plugin, I'm all for it (just let me know how to do it). > New Mojos for compiler and jar plugins to allow alternate jars > -- > > Key: MCOMPILER-13 > URL: http://jira.codehaus.org/browse/MCOMPILER-13 > Project: Maven 2.x Compiler Plugin > Type: Bug > Environment: Linux using JDK 1.5.0_01 > Reporter: Bob Allison > Attachments: AltCompilerMojo.java, AltJarMojo.java, pom.xml > > > Add mojos so that mock objects and other affiliated source roots can be > compiled and packaged in the same project -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1732) Improve methods to define the scope and packaging of dependencies
Improve methods to define the scope and packaging of dependencies - Key: MNG-1732 URL: http://jira.codehaus.org/browse/MNG-1732 Project: Maven 2 Type: Improvement Versions: 2.0 Reporter: Bob Allison I have been thinking about the way the dependency scope is being used, and I think there may be a need to expand the scope definitions so that more flexibility is available for defining what dependencies get packaged into artifacts and what dependencies are used in the various classpaths. My thought is to create a new tag on the dependency XML tree called "usage"; it would look something like this: junit junit 3.8.1 true true false false /usr/local/lib I see two classes of items within the tag: -- classpath items (compile, test, execute above) which split out the current meaning of the scope value and would have the value of "true" or "false" to identify if the dependency should appear on the classpath; the default value for these would be "true" -- packaging items (jar, rpm above) which control the packaging of the dependency into the specified type of artifact and would have the value "false" to omit the dependency, "true" to package the dependency in a package-specific default location (e.g., wars would default to "WEB-INF/lib"), or a path to package the dependency in a specific place in the artifact; the default value for these would be "false" My expectation is that both and would be accepted and that would be configured as a Map. If possible, it would be easier for mojos to use this arrangement if specifying would cause a pre-configured map to be placed in the usage variable so that mojos only have to look at the usage map and not interpolate the scope value as well. I think this may also help with people who have a hard time remembering that a scope of "compile" means that the dependency is also available at runtime and which scopes make the dependency get packaged into the artifact. It would also address some of the "how do I keep my war dependencies from appearing in my ear file" type of questions. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1558) Manifest generation problems caused by valid POM information
Manifest generation problems caused by valid POM information Key: MNG-1558 URL: http://jira.codehaus.org/browse/MNG-1558 Project: Maven 2 Type: Bug Components: maven-jar-plugin Versions: 2.0 Reporter: Bob Allison It looks like we have some problems with the contents of manifests in jar files. According to Sun's documentation (http://java.sun.com/j2se/1.5.0/docs/guide/jar/jar.html), there are three basic formatting rules which are not always being enforced: 1) All text must be UTF-8 2) Lines are limited to 72 characters; longer lines must be continued 3) Sections are divided by blank lines Where are these rules being violated? The first rule can be violated by any POM which is in a character set other than UTF-8. The last two rules can be violated by any POM value which spans multiple lines. Both of these are potential problems since a number of POM values go directly into the manifest without sufficient checking. Example: The plugin I have been working on suddenly stopped working. It stopped when I added a two-line description to the POM. I have been able to determine that converting the second line of the description into a proper manifest continuation line fixed the problem. As it turns out, the class loader was ignoring the jar; this created an error where the name of the Mojo class was found but the class could not be loaded. Workarounds for the present: -- Any POM fields which end up in a jar manifest needs to be limited to UTF-8 characters. -- Multi-line values should be constructed so that all lines start with a space character (not strictly required for the first line but it doesn't hurt). -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-1445) NPE thrown when parsing bad plugin jar
[ http://jira.codehaus.org/browse/MNG-1445?page=all ] Bob Allison updated MNG-1445: - Attachment: MNG-1445-testcase.zip The attached test case contains two projects: -- testplugin creates a simple plugin -- test references the plugin To replicate the problem: -- Run "mvn install" on testplugin -- Unpack the installed jar, remove META-INF/maven/plugin.xml, and repack the jar -- Run "mvn compile" on test > NPE thrown when parsing bad plugin jar > -- > > Key: MNG-1445 > URL: http://jira.codehaus.org/browse/MNG-1445 > Project: Maven 2 > Type: Bug > Versions: 2.0 > Environment: Java 1.5.0 on Linux > Reporter: Bob Allison > Attachments: MNG-1445-testcase.zip > > > Due to a configuration error, I had referenced a jar that was not a plugin in > the list of plugins. This caused the following NPE: > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] null > [INFO] > > [INFO] Trace > java.lang.NullPointerException > at > org.apache.maven.plugin.DefaultPluginManager.addPlugin(DefaultPluginManager.java:292) > at > org.apache.maven.plugin.DefaultPluginManager.verifyVersionedPlugin(DefaultPluginManager.java:198) > at > org.apache.maven.plugin.DefaultPluginManager.verifyPlugin(DefaultPluginManager.java:163) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(DefaultLifecycleExecutor.java:1095) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.bindPluginToLifecycle(DefaultLifecycleExecutor.java:1060) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.constructLifecycleMappings(DefaultLifecycleExecutor.java:869) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:447) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:301) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:268) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:137) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:316) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:113) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:249) > 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1445) NPE thrown when parsing bad plugin jar
NPE thrown when parsing bad plugin jar -- Key: MNG-1445 URL: http://jira.codehaus.org/browse/MNG-1445 Project: Maven 2 Type: Bug Versions: 2.0 Environment: Java 1.5.0 on Linux Reporter: Bob Allison Due to a configuration error, I had referenced a jar that was not a plugin in the list of plugins. This caused the following NPE: [INFO] [ERROR] FATAL ERROR [INFO] [INFO] null [INFO] [INFO] Trace java.lang.NullPointerException at org.apache.maven.plugin.DefaultPluginManager.addPlugin(DefaultPluginManager.java:292) at org.apache.maven.plugin.DefaultPluginManager.verifyVersionedPlugin(DefaultPluginManager.java:198) at org.apache.maven.plugin.DefaultPluginManager.verifyPlugin(DefaultPluginManager.java:163) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(DefaultLifecycleExecutor.java:1095) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.bindPluginToLifecycle(DefaultLifecycleExecutor.java:1060) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.constructLifecycleMappings(DefaultLifecycleExecutor.java:869) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:447) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:301) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:268) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:137) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:316) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:113) at org.apache.maven.cli.MavenCli.main(MavenCli.java:249) 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1174) New Mojos for compiler and jar plugins to allow alternate jars
[ http://jira.codehaus.org/browse/MNG-1174?page=comments#action_48421 ] Bob Allison commented on MNG-1174: -- Holding off is not a problem. I had started to try to build this as a separate plugin that leveraged off of the compiler plugin code. Although I could build the plugin with the compiler plugin as a compile dependency, when I tried to use the plugin it failed miserably because the parameters defined in AbstractCompilerMojo were not included in the plugin descriptor (and editing the file didn't help since the descriptor was rewritten the next time I tried to package the plugin even though nothing else had changed). I'm sure this needs some close review since I just did a simple copy with a couple hacks. There are probably a few things I copied that make it work wrong in some (or most) circumstances. I'm especially unsure about the reference to "Artifact" in the compiler mojo and if I should have taken that out. One thing that might eliminate the need for these mojos is if the "compileSourceRoots" and "outputDirectory" parameters were made editable. I very much understand why they are read only, since you want the default behavior driven from the POM correctly. Perhaps it might be possible to have these appear twice: one copy is defined editable with no defaults but not marked required, the other copy (with "Pom" on the end) defined as they are now. The plugin could then use the POM-based variables if the user did not specify the editable parameters and fail if the user only specifies one of the editable parameters. (Just a thought...) > New Mojos for compiler and jar plugins to allow alternate jars > -- > > Key: MNG-1174 > URL: http://jira.codehaus.org/browse/MNG-1174 > Project: Maven 2 > Type: Improvement > Versions: 2.0-beta-3 > Environment: Linux using JDK 1.5.0_01 > Reporter: Bob Allison > Fix For: 2.0-beta-4 > Attachments: AltCompilerMojo.java, AltJarMojo.java, pom.xml > > > Add mojos so that mock objects and other affiliated source roots can be > compiled and packaged in the same project -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-1174) New Mojos for compiler and jar plugins to allow alternate jars
[ http://jira.codehaus.org/browse/MNG-1174?page=all ] Bob Allison updated MNG-1174: - Attachment: pom.xml The build section from a POM which shows how to use the new mojos > New Mojos for compiler and jar plugins to allow alternate jars > -- > > Key: MNG-1174 > URL: http://jira.codehaus.org/browse/MNG-1174 > Project: Maven 2 > Type: Improvement > Versions: 2.0-beta-3 > Environment: Linux using JDK 1.5.0_01 > Reporter: Bob Allison > Fix For: 2.0-beta-4 > Attachments: AltCompilerMojo.java, AltJarMojo.java, pom.xml > > > Add mojos so that mock objects and other affiliated source roots can be > compiled and packaged in the same project -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-1174) New Mojos for compiler and jar plugins to allow alternate jars
[ http://jira.codehaus.org/browse/MNG-1174?page=all ] Bob Allison updated MNG-1174: - Attachment: AltJarMojo.java AltJarMojo is identical to JarMojo except: -- Goal changed to "altjar" -- Parameter "outputDirectory" renamed to "sourceDirectory" , made editable, and given no default > New Mojos for compiler and jar plugins to allow alternate jars > -- > > Key: MNG-1174 > URL: http://jira.codehaus.org/browse/MNG-1174 > Project: Maven 2 > Type: Improvement > Versions: 2.0-beta-3 > Environment: Linux using JDK 1.5.0_01 > Reporter: Bob Allison > Fix For: 2.0-beta-4 > Attachments: AltCompilerMojo.java, AltJarMojo.java > > > Add mojos so that mock objects and other affiliated source roots can be > compiled and packaged in the same project -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-1174) New Mojos for compiler and jar plugins to allow alternate jars
[ http://jira.codehaus.org/browse/MNG-1174?page=all ] Bob Allison updated MNG-1174: - Attachment: AltCompilerMojo.java The AltCompilerMojo is identical to CompilerMojo except: -- Goal changed to "altcompile" -- A parameter "suffix" added to allow an easy definition of the file endings to compile -- Parameter "compileSourceRoots" renamed to "sources" and made editable -- Parameter "outputDirectory" made editable > New Mojos for compiler and jar plugins to allow alternate jars > -- > > Key: MNG-1174 > URL: http://jira.codehaus.org/browse/MNG-1174 > Project: Maven 2 > Type: Improvement > Versions: 2.0-beta-3 > Environment: Linux using JDK 1.5.0_01 > Reporter: Bob Allison > Fix For: 2.0-beta-4 > Attachments: AltCompilerMojo.java > > > Add mojos so that mock objects and other affiliated source roots can be > compiled and packaged in the same project -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1174) New Mojos for compiler and jar plugins to allow alternate jars
New Mojos for compiler and jar plugins to allow alternate jars -- Key: MNG-1174 URL: http://jira.codehaus.org/browse/MNG-1174 Project: Maven 2 Type: Improvement Versions: 2.0-beta-3 Environment: Linux using JDK 1.5.0_01 Reporter: Bob Allison Fix For: 2.0-beta-4 Add mojos so that mock objects and other affiliated source roots can be compiled and packaged in the same project -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1041) Classifier-specific dependencies colliding with generic dependencies
[ http://jira.codehaus.org/browse/MNG-1041?page=comments#action_47677 ] Bob Allison commented on MNG-1041: -- I don't think I can use this for my mocks, and here's why: I have proj-a and proj-b, both of which have unit tests in src/test. Proj-b uses the jar produced by proj-a. For unit tests of proj-b I need the mock objects of proj-a but I don't want to inherit the unit tests of proj-a (no need to run them as part of proj-b since they test proj-a). I also do not want the mock objects for proj-a to pollute the classpath during the unit tests of proj-a, since I have some factory classes which exist in the mock objects to allow the proj-b unit tests to create the mock object of the proj-a class and load it into the replacement factory during its tests. To accomplish what I need, I need to have a src/mock directory that is built and deployed as a jar separate from the test classes. I don't know if that can be done by making a "mock-jar" goal for the jar plugin or if something else needs to be done. > Classifier-specific dependencies colliding with generic dependencies > > > Key: MNG-1041 > URL: http://jira.codehaus.org/browse/MNG-1041 > Project: Maven 2 > Type: Bug > Versions: 2.0-beta-1 > Environment: Win XP SP2, Java 1.4.2 > Reporter: John Fallows > Assignee: Brett Porter > Fix For: 2.0-beta-3 > > > It seems like there is a collision between dependencies from the same > project but with different classifiers, causing only the main > dependency artifact to be present on the compilation classpath. > project/ > api-module/ > impl-module/ > The api-module generates 2 artifacts, one with classifier "mock". > The impl-module depends on both of these artifiacts, one with "mock" > classifier at "test" scope and the other with no classifier at the > default "compile" scope. > During compilation of the impl-module tests, classes from the > api-module "mock" artifact are not found on the classpath. > It seems as though the "mock" artifact and the regular artifact are > colliding, causing the "mock" artifact to be removed from the test > compilation classpath. > Both the "mock" and regular artifacts from the api-module have type > "jar". Even when the "mock" type is changed to "zip", the same > problem occurs. > Perhaps dependency classifiers are ignored while constructing the > compilation classpath? > Brett Porter wrote: > I think its because the project you are depending on is in the > reactor, and its probably a bug. > Basically, its trying to use the built version of that project, but > projects are only identified by group:artifactId -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1045) resolve ordering of parent build in reactor
[ http://jira.codehaus.org/browse/MNG-1045?page=comments#action_47477 ] Bob Allison commented on MNG-1045: -- Not being up-to-speed on all the details of the DAG process, this may not be possible, but... How about this approach: Do not automatically add the parent-child edge. After the entire graph is built, locate any projects which are isolated (no edges reach them) and place them at the end of the build. The hard part I see in this is being able to locate the isolated projects (maybe add an int field to count the number of edges that reach a particular project). Using this approach, no edges are added which can cause unexpected cycles. If non-aggregating parents need to come first, then isolated projects can be added to the start and end as appropriate. > resolve ordering of parent build in reactor > --- > > Key: MNG-1045 > URL: http://jira.codehaus.org/browse/MNG-1045 > Project: Maven 2 > Type: Bug > Components: maven-project > Reporter: Brett Porter > Assignee: Brett Porter > Fix For: 2.0-beta-3 > > > previously, parent always built first. This caused issues with cycles when > the parent depended on the child (Which may also be the case with modules and > an aggregating root if that occurs). > Now, with the parent last, the "clean:clean" command is causing issues > (previously it0065 - until dependency on parent's target directory was > removed). A child is using/writing to the parent's target directory, and then > clean comes and wipes it out. > - is this acceptable? > - what alternatives are there? > Currently proposed solution: > - parent is not factored into dependency graph to avoid cycles > - parent is forced to come before children if not aggregating > - parent is forced to come last if aggregating (currently aggregating doesn't > run children anyway, relying on earlier output) -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (CONTINUUM-321) Maven 2 properties are ignored
Maven 2 properties are ignored
--
Key: CONTINUUM-321
URL: http://jira.codehaus.org/browse/CONTINUUM-321
Project: Continuum
Type: Bug
Versions: 1.0-alpha-4
Environment: Running release 1.0-alpha-4 on Linux, using Maven 2.0-beta-1
release
Reporter: Bob Allison
My Maven 2 project tree consists of a parent directory with a pom.xml and a set
of child projects in subdirectories of the parent directory. In the parent
project, I am using a pair of properties to define the build version as follows:
3.0
-SNAPSHOT
...
${revision}${snapshot}
...
I have tried placing the properties in the parent project and in the child
project, but I get the same results.
When I run the build with m2 from the command line, everything builds,
installs, and deploys correctly. When the child project is built with
Continuum, the output from Maven looks like:
jvm 1| 2005-09-26 13:08:13,244 [Thread-0] WARN MavenProjectBuilder
-
jvm 1| * Using defaults for missing POM
qaccess:3rd-party:pom:${revision}${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: (MNG-690) Make text in appear the same size as the rest of the text
[ http://jira.codehaus.org/browse/MNG-690?page=all ]
Bob Allison updated MNG-690:
Attachment: MNG-690.diff
Based the previous file starting at the wrong directory. This one should be
correct.
> Make text in appear the same size as the rest of the text
> ---
>
> Key: MNG-690
> URL: http://jira.codehaus.org/browse/MNG-690
> Project: Maven 2
> Type: Improvement
> Components: maven-site-plugin
> Versions: 2.0-alpha-3
> Reporter: Bob Allison
> Priority: Minor
> Fix For: 2.0-beta-2
> Attachments: MNG-690.diff, MNG-690.diff
>
>
> As currently defined, text in a paragraph that is enclosed in
> ... will appear much smaller. This has been true since v1.0.2
> or earlier.
> Adding the following four lines to "maven-theme.css" will fix the problem (I
> would suggest adding them right after the first four lines which set similar
> information for most other text):
> code{
> font-family: Courier, monospace;
> font-size: 13px;
> }
--
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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-794) Deploy fails with NPE
[ http://jira.codehaus.org/browse/MNG-794?page=comments#action_46981 ] Bob Allison commented on MNG-794: - Retried this with beta-1 and it appears to be working now. Probably fixed while fixing other deployment issues. > Deploy fails with NPE > - > > Key: MNG-794 > URL: http://jira.codehaus.org/browse/MNG-794 > Project: Maven 2 > Type: Bug > Components: maven-artifact > Versions: 2.0-beta-1 > Environment: SVN revision 240249 on Linux > Reporter: Bob Allison > Fix For: 2.0-beta-2 > > > Trying to deploy a project (I have tried POM and jar packaging projects) > results in: > Uploading: > scp://repository.host/home/qadev-home/m2/snapshot/qaccess/data/3.0-SNAPSHOT/data-3.0-20050826.144537-1.jar > java.lang.NullPointerException > at com.jcraft.jsch.ChannelSession.run()V(Unknown Source) > at java.lang.Thread.run()V(Unknown Source) > at java.lang.Thread.startThreadFromVM(Ljava.lang.Thread;)V(Unknown > Source) -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-690) Make text in appear the same size as the rest of the text
[ http://jira.codehaus.org/browse/MNG-690?page=all ]
Bob Allison updated MNG-690:
Attachment: MNG-690.diff
This patch updates the current maven-theme.css to correct this problem.
> Make text in appear the same size as the rest of the text
> ---
>
> Key: MNG-690
> URL: http://jira.codehaus.org/browse/MNG-690
> Project: Maven 2
> Type: Improvement
> Components: maven-site-plugin
> Versions: 2.0-alpha-3
> Reporter: Bob Allison
> Priority: Minor
> Fix For: 2.0-beta-2
> Attachments: MNG-690.diff
>
>
> As currently defined, text in a paragraph that is enclosed in
> ... will appear much smaller. This has been true since v1.0.2
> or earlier.
> Adding the following four lines to "maven-theme.css" will fix the problem (I
> would suggest adding them right after the first four lines which set similar
> information for most other text):
> code{
> font-family: Courier, monospace;
> font-size: 13px;
> }
--
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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-971) Allow goals such as "clean:clean" to be specified as "clean"
Allow goals such as "clean:clean" to be specified as "clean" Key: MNG-971 URL: http://jira.codehaus.org/browse/MNG-971 Project: Maven 2 Type: Improvement Versions: 2.0-beta-1 Reporter: Bob Allison Priority: Minor It would be real nice if specifying a goal without a colon in it (e.g., "clean" or "site") would check to see if there is a plugin by that name with a goal by the same name. I think this would ease the transition for some people and greatly help people like me who can't type worth a darn. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-875) Duplicate repository IDs prevent mirroring Maven2 development repositories
[ http://jira.codehaus.org/browse/MNG-875?page=comments#action_46512 ] Bob Allison commented on MNG-875: - Took out all of my mirrors from settings.xml; the same it tests still fail. Must be related to the release process. > Duplicate repository IDs prevent mirroring Maven2 development repositories > -- > > Key: MNG-875 > URL: http://jira.codehaus.org/browse/MNG-875 > Project: Maven 2 > Type: Improvement > Versions: 2.0-beta-1 > Reporter: Bob Allison > Assignee: Brett Porter > Priority: Minor > Attachments: fix-repos-id.patch > > > Within the Maven 2 codebase, two different development repositories are given > the "snapshots" ID. Because the repositories are at different web addresses, > it is impossible to specify a mirror which satisfies both repositories. The > attached patch adjusts the codebase to consistently use the following names: > -- "snapshots" refers to the Maven Central Development Repository at > http://snapshots.maven.codehaus.org/maven2 > -- "plugin-snapshots" refers to the Maven Central Plugins Development > Repository at http://snapshots.maven.codehaus.org/maven2/plugins > After making these changes (and adding a mirror for "central") I am able to > build the entire Maven 2 bootstrap and pass all integration tests while > minimizing the number of times the build is skipping the mirror and going > directly to ibiblio. The three downloads that go directly to ibiblio are > modello dependencies which reference a repository with the ID of > "central-plugins"; my attempts to mirror this repository appear to be ignored. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-875) Duplicate repository IDs prevent mirroring Maven2 development repositories
[ http://jira.codehaus.org/browse/MNG-875?page=comments#action_46495 ] Bob Allison commented on MNG-875: - OK. I backed out the changes of this patch and tried to build m2 with "snapshots" mirrored from "http://snapshots.maven.codehaus.org/maven2"; and "central" mirrored from "http://www.ibiblio.org/maven2";. The following it tests fail because they cannot locate something in the repository: it0065, it0064, it0063, it0049, it0046, it0045, it0044, it0040, it0027, it0026, it0025, it0023, it0022, it0020, it0015, it0013, it0012, it0011, it0010, it0009, it0008. > Duplicate repository IDs prevent mirroring Maven2 development repositories > -- > > Key: MNG-875 > URL: http://jira.codehaus.org/browse/MNG-875 > Project: Maven 2 > Type: Improvement > Versions: 2.0-beta-1 > Reporter: Bob Allison > Assignee: Brett Porter > Priority: Minor > Attachments: fix-repos-id.patch > > > Within the Maven 2 codebase, two different development repositories are given > the "snapshots" ID. Because the repositories are at different web addresses, > it is impossible to specify a mirror which satisfies both repositories. The > attached patch adjusts the codebase to consistently use the following names: > -- "snapshots" refers to the Maven Central Development Repository at > http://snapshots.maven.codehaus.org/maven2 > -- "plugin-snapshots" refers to the Maven Central Plugins Development > Repository at http://snapshots.maven.codehaus.org/maven2/plugins > After making these changes (and adding a mirror for "central") I am able to > build the entire Maven 2 bootstrap and pass all integration tests while > minimizing the number of times the build is skipping the mirror and going > directly to ibiblio. The three downloads that go directly to ibiblio are > modello dependencies which reference a repository with the ID of > "central-plugins"; my attempts to mirror this repository appear to be ignored. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MPJCOVERAGE-33) XmlPullParserException
[ http://jira.codehaus.org/browse/MPJCOVERAGE-33?page=comments#action_46493 ] Bob Allison commented on MPJCOVERAGE-33: So searching the source for "metod" won't find the typo? > XmlPullParserException > -- > > Key: MPJCOVERAGE-33 > URL: http://jira.codehaus.org/browse/MPJCOVERAGE-33 > Project: maven-jcoverage-plugin > Type: Bug > Versions: 1.0.9 > Environment: JDK 1.4, Maven1.02 > Reporter: kylin > Attachments: coverage.xml > > > org.xmlpull.v1.XmlPullParserException: end tag name 'metods' must match start > tag name 'methods' (position: TEXT seen ...\r\n... > @230:14) > at org.xmlpull.mxp1.MXParser.parseEndTag(MXParser.java:1704) > at org.xmlpull.mxp1.MXParser.nextImpl(MXParser.java:1175) > at org.xmlpull.mxp1.MXParser.next(MXParser.java:1137) > at org.xmlpull.mxp1.MXParser.nextTag(MXParser.java:1122) > at > org.apache.maven.jcoveragereport.CoverageUnmarshaller.parse(CoverageUnmarshaller.java:86) -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MPJCOVERAGE-33) XmlPullParserException
[ http://jira.codehaus.org/browse/MPJCOVERAGE-33?page=comments#action_46490 ] Bob Allison commented on MPJCOVERAGE-33: To me, this looks like a typo in the XML. In the stanza for class "com.ai.utils.rule.RuleBean" the tag is closed with just like the error message indicates. > XmlPullParserException > -- > > Key: MPJCOVERAGE-33 > URL: http://jira.codehaus.org/browse/MPJCOVERAGE-33 > Project: maven-jcoverage-plugin > Type: Bug > Versions: 1.0.9 > Environment: JDK 1.4, Maven1.02 > Reporter: kylin > Attachments: coverage.xml > > > org.xmlpull.v1.XmlPullParserException: end tag name 'metods' must match start > tag name 'methods' (position: TEXT seen ...\r\n... > @230:14) > at org.xmlpull.mxp1.MXParser.parseEndTag(MXParser.java:1704) > at org.xmlpull.mxp1.MXParser.nextImpl(MXParser.java:1175) > at org.xmlpull.mxp1.MXParser.next(MXParser.java:1137) > at org.xmlpull.mxp1.MXParser.nextTag(MXParser.java:1122) > at > org.apache.maven.jcoveragereport.CoverageUnmarshaller.parse(CoverageUnmarshaller.java:86) -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-875) Duplicate repository IDs prevent mirroring Maven2 development repositories
[ http://jira.codehaus.org/browse/MNG-875?page=comments#action_46487 ] Bob Allison commented on MNG-875: - Does that mean that the m2 POMs no longer reference snapshots... and snapshots as diffrent URLs? That is what the patch fixes. > Duplicate repository IDs prevent mirroring Maven2 development repositories > -- > > Key: MNG-875 > URL: http://jira.codehaus.org/browse/MNG-875 > Project: Maven 2 > Type: Improvement > Versions: 2.0-beta-1 > Reporter: Bob Allison > Assignee: Brett Porter > Priority: Minor > Attachments: fix-repos-id.patch > > > Within the Maven 2 codebase, two different development repositories are given > the "snapshots" ID. Because the repositories are at different web addresses, > it is impossible to specify a mirror which satisfies both repositories. The > attached patch adjusts the codebase to consistently use the following names: > -- "snapshots" refers to the Maven Central Development Repository at > http://snapshots.maven.codehaus.org/maven2 > -- "plugin-snapshots" refers to the Maven Central Plugins Development > Repository at http://snapshots.maven.codehaus.org/maven2/plugins > After making these changes (and adding a mirror for "central") I am able to > build the entire Maven 2 bootstrap and pass all integration tests while > minimizing the number of times the build is skipping the mirror and going > directly to ibiblio. The three downloads that go directly to ibiblio are > modello dependencies which reference a repository with the ID of > "central-plugins"; my attempts to mirror this repository appear to be ignored. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-891) Javadoc fails to include libraries
Javadoc fails to include libraries -- Key: MNG-891 URL: http://jira.codehaus.org/browse/MNG-891 Project: Maven 2 Type: Bug Versions: 2.0-beta-1 Environment: SVN revision 280814 on Linux using JRockit 1.4.2 Reporter: Bob Allison Priority: Critical Attachments: javadoc-failure.zip I am writing a simple extension to log4j that consists of a new class which extends Level to add more values. I have zipped up the project (the pom and a single source file) and attached them. The project compiles fine. When I try to generate the JavaDoc for the project, JavaDoc fails to include the log4j library in the classpath which causes it to fail. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-875) Duplicate repository IDs prevent mirroring Maven2 development repositories
Duplicate repository IDs prevent mirroring Maven2 development repositories -- Key: MNG-875 URL: http://jira.codehaus.org/browse/MNG-875 Project: Maven 2 Type: Improvement Versions: 2.0-beta-1 Reporter: Bob Allison Priority: Minor Attachments: fix-repos-id.patch Within the Maven 2 codebase, two different development repositories are given the "snapshots" ID. Because the repositories are at different web addresses, it is impossible to specify a mirror which satisfies both repositories. The attached patch adjusts the codebase to consistently use the following names: -- "snapshots" refers to the Maven Central Development Repository at http://snapshots.maven.codehaus.org/maven2 -- "plugin-snapshots" refers to the Maven Central Plugins Development Repository at http://snapshots.maven.codehaus.org/maven2/plugins After making these changes (and adding a mirror for "central") I am able to build the entire Maven 2 bootstrap and pass all integration tests while minimizing the number of times the build is skipping the mirror and going directly to ibiblio. The three downloads that go directly to ibiblio are modello dependencies which reference a repository with the ID of "central-plugins"; my attempts to mirror this repository appear to be ignored. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-839) Checkstyle plugin fails with default parameters
Checkstyle plugin fails with default parameters --- Key: MNG-839 URL: http://jira.codehaus.org/browse/MNG-839 Project: Maven 2 Type: Bug Components: maven-checkstyle-plugin Versions: 2.0-beta-1 Environment: SVN revision 279038 on Linux Reporter: Bob Allison Attachments: CheckstyleReport.diff After updating from revision 278582, the checkstyle plugin fails with the following: Caused by: org.apache.maven.reporting.MavenReportException: Invalid configuration file format: sun at org.apache.maven.plugin.checkstyle.CheckstyleReport.getConfigFile()Ljava.lang.String;(CheckstyleReport.java:430) at org.apache.maven.plugin.checkstyle.CheckstyleReport.executeReport(Ljava.util.Locale;)V(CheckstyleReport.java:239) at org.apache.maven.reporting.AbstractMavenReport.generate(Lorg.codehaus.doxia.sink.Sink;Ljava.util.Locale;)V(AbstractMavenReport.java:117) at org.apache.maven.doxia.DoxiaMojo.generateReportsPages(Ljava.util.List;Ljava.util.Locale;Ljava.io.File;)V(DoxiaMojo.java:744) at org.apache.maven.doxia.DoxiaMojo.execute()V(DoxiaMojo.java:325) The attached patch corrects an error in CheckstyleReport which is checking for a null string rather than for "sun" -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-139) server definitions should be reusable
[ http://jira.codehaus.org/browse/MNG-139?page=comments#action_45474 ] Bob Allison commented on MNG-139: - One place where problems can occur is using a mirror for codehaus while building m2. In the m2 top-level plugin, there is a repository named "snapshots" which points to "http://snapshots.maven.codehaus.org/maven2/"; and a pluginRepository named "snapshots" which points to "http://snapshots.maven.codehaus.org/maven2/plugins";. Creating a mirror of "snapshots" causes problems during the integration tests. The name used for the pluginRepository needs to be changed so it does not match the regular repository (that change allows the integration tests to succeed whether the pluginRepository is mirrored or not). > server definitions should be reusable > - > > Key: MNG-139 > URL: http://jira.codehaus.org/browse/MNG-139 > Project: Maven 2 > Type: Task > Components: design > Reporter: Brett Porter > Assignee: Brett Porter > Priority: Critical > Fix For: 2.0-beta-1 > > Original Estimate: 4 hours > Remaining: 4 hours > > currently if multiple projects use the same server for deployment, we are > relying on inheritence to share the definition, or it must be copied. This > applies similarly to the SCM connection and the dist/site management settings. > It would be a good idea to be able to declare these elements in a deployed > artifact. > It may still be reasonable to do this through inheritence, but there is a > chance we'll hit the need for multiple inheritence (because multiple projects > inherit things from different sources), so we should enumerate the use cases > and verify it. > eg. >A B > / \ / \ > C D E > Where A and B declare two different things that D uses both of, but which C > and E desire only to inherit one of. > This essentially using composition for some elements instead of inheritence. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-794) Deploy fails with NPE
Deploy fails with NPE - Key: MNG-794 URL: http://jira.codehaus.org/browse/MNG-794 Project: Maven 2 Type: Bug Versions: 2.0-beta-1 Environment: SVN revision 240249 on Linux Reporter: Bob Allison Trying to deploy a project (I have tried POM and jar packaging projects) results in: Uploading: scp://repository.host/home/qadev-home/m2/snapshot/qaccess/data/3.0-SNAPSHOT/data-3.0-20050826.144537-1.jar java.lang.NullPointerException at com.jcraft.jsch.ChannelSession.run()V(Unknown Source) at java.lang.Thread.run()V(Unknown Source) at java.lang.Thread.startThreadFromVM(Ljava.lang.Thread;)V(Unknown Source) -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-779) JavadocReport throws NPE
JavadocReport throws NPE Key: MNG-779 URL: http://jira.codehaus.org/browse/MNG-779 Project: Maven 2 Type: Bug Versions: 2.0-beta-1 Environment: SVN revision 239419 on Linux Reporter: Bob Allison Running site:site on a project that was working yesterday (revision 235747), received teh following exception: [INFO] Generate "JavaDocs" report. [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Diagnosis: Error during report generation [INFO] [ERROR] Cause: org.apache.maven.plugin.MojoExecutionException: Error during report generation at org.apache.maven.doxia.DoxiaMojo.execute(DoxiaMojo.java:492) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:364) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:478) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:459) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:441) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:131) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:186) at org.apache.maven.cli.MavenCli.main(MavenCli.java:316) 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) Caused by: org.apache.maven.reporting.MavenReportException: An error has occurred in javadoc report generation. at org.apache.maven.plugin.javadoc.JavadocReport.executeReport(JavadocReport.java:852) at org.apache.maven.plugin.javadoc.JavadocReport.generate(JavadocReport.java:613) at org.apache.maven.doxia.DoxiaMojo.execute(DoxiaMojo.java:298) ... 16 more Caused by: java.lang.NullPointerException at org.apache.maven.plugin.javadoc.JavadocReport.executeReport(JavadocReport.java:795) ... 18 more The code in JavadocReport is: if ( this.doctitle.equals( DEFAULT_DOCTITLE ) ) I am assuming that doctitle is not being initialized properly. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-754) Exception thrown building site
[ http://jira.codehaus.org/browse/MNG-754?page=comments#action_44953 ] Bob Allison commented on MNG-754: - I ended up having to rebuild my repository (both my local repository and the one I deploy to). Now, I cannot duplicate the problem. My guess is that I had something messed up in one of the repositories and whatever caused that problem has been fixed in SVN already. > Exception thrown building site > -- > > Key: MNG-754 > URL: http://jira.codehaus.org/browse/MNG-754 > Project: Maven 2 > Type: Bug > Versions: 2.0-beta-1 > Environment: SVN revision 233464 on Linux > Reporter: Bob Allison > Fix For: 2.0-beta-1 > Attachments: ActiveProjectArtifact.diff > > > Starting a new project which depends on another project in my tree. I > created the bare bones project directory and added an index.xml in the > src/site/xdoc directory. > When trying to build the site from the top level project, I got the following > exception in the new project: > [INFO] [site:site] > [INFO] Generate "JavaDocs" report. > [INFO] Generate "Issue Tracking" report. > [INFO] Generate "Dependencies" report. > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Diagnosis: Error during site generation > [INFO] > > [ERROR] Cause: > org.apache.maven.plugin.MojoExecutionException: Error during site generation > at org.apache.maven.doxia.DoxiaMojo.execute(DoxiaMojo.java:500) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:364) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:470) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:451) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:433) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:266) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:125) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:186) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:316) > 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) > Caused by: java.lang.IllegalArgumentException: Can't find a valid Maven > project in the repository for the artifact [EMAIL PROTECTED] > at > org.apache.maven.report.projectinfo.DependenciesReport$DependenciesRenderer.renderBody(DependenciesReport.java:236) > at > org.apache.maven.reporting.AbstractMavenReportRenderer.render(AbstractMavenReportRenderer.java:65) > at > org.apache.maven.report.projectinfo.DependenciesReport.executeReport(DependenciesReport.java:147) > at > org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:117) > at org.apache.maven.doxia.DoxiaMojo.execute(DoxiaMojo.java:298) > ... 16 more > I think the exception needs to have the actual artifact information. Perhaps > the ActiveProjectArtifact class needs a toString method to fix this. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-755) Running "m2 -fae" does not use POM or reactor
[ http://jira.codehaus.org/browse/MNG-755?page=comments#action_44949 ] Bob Allison commented on MNG-755: - I wasn't sure if this was one bug or two. I did not know if the NPE was a result of using the "Default Maven Project" or something different. Using --fail-at-end instead of -fae causes the build to use the POM in the directory rather than a default POM. I also do not get the NPE. I guess this can be closed since the whole thing was caused by using the documented but disfunctional command line options. > Running "m2 -fae" does not use POM or reactor > - > > Key: MNG-755 > URL: http://jira.codehaus.org/browse/MNG-755 > Project: Maven 2 > Type: Bug > Versions: 2.0-beta-1 > Environment: SVN revision 233464 on Linux > Reporter: Bob Allison > Fix For: 2.0-beta-1 > > > I ran "m2 -fae clean:clean package site:site" on my top level package to > clean up all targets, rebuild the artifacts, and generate a site for every > project (I used -fae since I have a problem building the site in one > sub-project). The banner displayed when it started processing was: > [INFO] > > [INFO] Building Maven Default Project > [INFO]task-segment: [clean:clean, package, site:site] > [INFO] > > even though I have a different name in the POM. > A little later, the build fails with: > [INFO] [jar:jar] > [WARNING] JAR will be empty - no content was marked for inclusion! > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Diagnosis: Error assembling JAR > [INFO] > > [ERROR] Cause: > org.apache.maven.plugin.MojoExecutionException: Error assembling JAR > at org.apache.maven.plugin.jar.JarMojo.execute(JarMojo.java:107) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:364) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:470) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:443) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:429) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:266) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:125) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:186) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:316) > 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) > Caused by: java.lang.NullPointerException > at > org.apache.maven.archiver.MavenArchiver.createArchive(MavenArchiver.java:238) > at org.apache.maven.plugin.jar.JarMojo.execute(JarMojo.java:100) > ... 16 more > which is caused by not having any sources in the project (since it is a POM > project). The build also did not run any of the modules. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-755) Running "m2 -fae" does not use POM or reactor
[ http://jira.codehaus.org/browse/MNG-755?page=comments#action_44747 ] Bob Allison commented on MNG-755: - It looks like "m2 -fn" exhibits the same behavior. > Running "m2 -fae" does not use POM or reactor > - > > Key: MNG-755 > URL: http://jira.codehaus.org/browse/MNG-755 > Project: Maven 2 > Type: Bug > Versions: 2.0-beta-1 > Environment: SVN revision 233464 on Linux > Reporter: Bob Allison > > > I ran "m2 -fae clean:clean package site:site" on my top level package to > clean up all targets, rebuild the artifacts, and generate a site for every > project (I used -fae since I have a problem building the site in one > sub-project). The banner displayed when it started processing was: > [INFO] > > [INFO] Building Maven Default Project > [INFO]task-segment: [clean:clean, package, site:site] > [INFO] > > even though I have a different name in the POM. > A little later, the build fails with: > [INFO] [jar:jar] > [WARNING] JAR will be empty - no content was marked for inclusion! > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Diagnosis: Error assembling JAR > [INFO] > > [ERROR] Cause: > org.apache.maven.plugin.MojoExecutionException: Error assembling JAR > at org.apache.maven.plugin.jar.JarMojo.execute(JarMojo.java:107) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:364) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:470) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:443) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:429) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:266) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:125) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:186) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:316) > 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) > Caused by: java.lang.NullPointerException > at > org.apache.maven.archiver.MavenArchiver.createArchive(MavenArchiver.java:238) > at org.apache.maven.plugin.jar.JarMojo.execute(JarMojo.java:100) > ... 16 more > which is caused by not having any sources in the project (since it is a POM > project). The build also did not run any of the modules. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-755) Running "m2 -fae" does not use POM or reactor
Running "m2 -fae" does not use POM or reactor - Key: MNG-755 URL: http://jira.codehaus.org/browse/MNG-755 Project: Maven 2 Type: Bug Versions: 2.0-beta-1 Environment: SVN revision 233464 on Linux Reporter: Bob Allison I ran "m2 -fae clean:clean package site:site" on my top level package to clean up all targets, rebuild the artifacts, and generate a site for every project (I used -fae since I have a problem building the site in one sub-project). The banner displayed when it started processing was: [INFO] [INFO] Building Maven Default Project [INFO]task-segment: [clean:clean, package, site:site] [INFO] even though I have a different name in the POM. A little later, the build fails with: [INFO] [jar:jar] [WARNING] JAR will be empty - no content was marked for inclusion! [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Diagnosis: Error assembling JAR [INFO] [ERROR] Cause: org.apache.maven.plugin.MojoExecutionException: Error assembling JAR at org.apache.maven.plugin.jar.JarMojo.execute(JarMojo.java:107) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:364) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:470) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:443) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:429) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:266) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:125) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:186) at org.apache.maven.cli.MavenCli.main(MavenCli.java:316) 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) Caused by: java.lang.NullPointerException at org.apache.maven.archiver.MavenArchiver.createArchive(MavenArchiver.java:238) at org.apache.maven.plugin.jar.JarMojo.execute(JarMojo.java:100) ... 16 more which is caused by not having any sources in the project (since it is a POM project). The build also did not run any of the modules. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-754) Exception thrown building site
[ http://jira.codehaus.org/browse/MNG-754?page=comments#action_44743 ] Bob Allison commented on MNG-754: - I have to take back something I said. It turns out that the problem does not go away with a POM for the app server's library jar. At least, after clearing my local repository, the problem occurs even with the POM downloaded properly. > Exception thrown building site > -- > > Key: MNG-754 > URL: http://jira.codehaus.org/browse/MNG-754 > Project: Maven 2 > Type: Bug > Versions: 2.0-beta-1 > Environment: SVN revision 233464 on Linux > Reporter: Bob Allison > Fix For: 2.0-beta-1 > Attachments: ActiveProjectArtifact.diff > > > Starting a new project which depends on another project in my tree. I > created the bare bones project directory and added an index.xml in the > src/site/xdoc directory. > When trying to build the site from the top level project, I got the following > exception in the new project: > [INFO] [site:site] > [INFO] Generate "JavaDocs" report. > [INFO] Generate "Issue Tracking" report. > [INFO] Generate "Dependencies" report. > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Diagnosis: Error during site generation > [INFO] > > [ERROR] Cause: > org.apache.maven.plugin.MojoExecutionException: Error during site generation > at org.apache.maven.doxia.DoxiaMojo.execute(DoxiaMojo.java:500) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:364) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:470) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:451) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:433) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:266) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:125) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:186) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:316) > 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) > Caused by: java.lang.IllegalArgumentException: Can't find a valid Maven > project in the repository for the artifact [EMAIL PROTECTED] > at > org.apache.maven.report.projectinfo.DependenciesReport$DependenciesRenderer.renderBody(DependenciesReport.java:236) > at > org.apache.maven.reporting.AbstractMavenReportRenderer.render(AbstractMavenReportRenderer.java:65) > at > org.apache.maven.report.projectinfo.DependenciesReport.executeReport(DependenciesReport.java:147) > at > org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:117) > at org.apache.maven.doxia.DoxiaMojo.execute(DoxiaMojo.java:298) > ... 16 more > I think the exception needs to have the actual artifact information. Perhaps > the ActiveProjectArtifact class needs a toString method to fix this. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-754) Exception thrown building site
[ http://jira.codehaus.org/browse/MNG-754?page=comments#action_44741 ] Bob Allison commented on MNG-754: - Looking at the artifact that it is complaining about, it is one that depends on a jar which I copied from my app server's library and placed in the repository so I could use it as a dependency. It appears to be caused by the fact that I did not create a POM for the app server's library jar. When I built the POM, the problem goes away. I should also mention that the problem only seems to appear when running in reactor mode. If I go directly to the project having problems, the site builds fine. > Exception thrown building site > -- > > Key: MNG-754 > URL: http://jira.codehaus.org/browse/MNG-754 > Project: Maven 2 > Type: Bug > Versions: 2.0-beta-1 > Environment: SVN revision 233464 on Linux > Reporter: Bob Allison > Fix For: 2.0-beta-1 > Attachments: ActiveProjectArtifact.diff > > > Starting a new project which depends on another project in my tree. I > created the bare bones project directory and added an index.xml in the > src/site/xdoc directory. > When trying to build the site from the top level project, I got the following > exception in the new project: > [INFO] [site:site] > [INFO] Generate "JavaDocs" report. > [INFO] Generate "Issue Tracking" report. > [INFO] Generate "Dependencies" report. > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Diagnosis: Error during site generation > [INFO] > > [ERROR] Cause: > org.apache.maven.plugin.MojoExecutionException: Error during site generation > at org.apache.maven.doxia.DoxiaMojo.execute(DoxiaMojo.java:500) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:364) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:470) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:451) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:433) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:266) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:125) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:186) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:316) > 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) > Caused by: java.lang.IllegalArgumentException: Can't find a valid Maven > project in the repository for the artifact [EMAIL PROTECTED] > at > org.apache.maven.report.projectinfo.DependenciesReport$DependenciesRenderer.renderBody(DependenciesReport.java:236) > at > org.apache.maven.reporting.AbstractMavenReportRenderer.render(AbstractMavenReportRenderer.java:65) > at > org.apache.maven.report.projectinfo.DependenciesReport.executeReport(DependenciesReport.java:147) > at > org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:117) > at org.apache.maven.doxia.DoxiaMojo.execute(DoxiaMojo.java:298) > ... 16 more > I think the exception needs to have the actual artifact information. Perhaps > the ActiveProjectArtifact class needs a toString method to fix this. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-754) Exception thrown building site
[ http://jira.codehaus.org/browse/MNG-754?page=all ] Bob Allison updated MNG-754: Attachment: ActiveProjectArtifact.diff With this patch, the exception reads: Caused by: java.lang.IllegalArgumentException: Can't find a valid Maven project in the repository for the artifact [qaccess:logging:3.0-20050819.123446-3]. > Exception thrown building site > -- > > Key: MNG-754 > URL: http://jira.codehaus.org/browse/MNG-754 > Project: Maven 2 > Type: Bug > Versions: 2.0-beta-1 > Environment: SVN revision 233464 on Linux > Reporter: Bob Allison > Fix For: 2.0-beta-1 > Attachments: ActiveProjectArtifact.diff > > > Starting a new project which depends on another project in my tree. I > created the bare bones project directory and added an index.xml in the > src/site/xdoc directory. > When trying to build the site from the top level project, I got the following > exception in the new project: > [INFO] [site:site] > [INFO] Generate "JavaDocs" report. > [INFO] Generate "Issue Tracking" report. > [INFO] Generate "Dependencies" report. > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Diagnosis: Error during site generation > [INFO] > > [ERROR] Cause: > org.apache.maven.plugin.MojoExecutionException: Error during site generation > at org.apache.maven.doxia.DoxiaMojo.execute(DoxiaMojo.java:500) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:364) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:470) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:451) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:433) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:266) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:125) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:186) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:316) > 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) > Caused by: java.lang.IllegalArgumentException: Can't find a valid Maven > project in the repository for the artifact [EMAIL PROTECTED] > at > org.apache.maven.report.projectinfo.DependenciesReport$DependenciesRenderer.renderBody(DependenciesReport.java:236) > at > org.apache.maven.reporting.AbstractMavenReportRenderer.render(AbstractMavenReportRenderer.java:65) > at > org.apache.maven.report.projectinfo.DependenciesReport.executeReport(DependenciesReport.java:147) > at > org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:117) > at org.apache.maven.doxia.DoxiaMojo.execute(DoxiaMojo.java:298) > ... 16 more > I think the exception needs to have the actual artifact information. Perhaps > the ActiveProjectArtifact class needs a toString method to fix this. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-754) Exception thrown building site
Exception thrown building site -- Key: MNG-754 URL: http://jira.codehaus.org/browse/MNG-754 Project: Maven 2 Type: Bug Versions: 2.0-beta-1 Environment: SVN revision 233464 on Linux Reporter: Bob Allison Starting a new project which depends on another project in my tree. I created the bare bones project directory and added an index.xml in the src/site/xdoc directory. When trying to build the site from the top level project, I got the following exception in the new project: [INFO] [site:site] [INFO] Generate "JavaDocs" report. [INFO] Generate "Issue Tracking" report. [INFO] Generate "Dependencies" report. [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Diagnosis: Error during site generation [INFO] [ERROR] Cause: org.apache.maven.plugin.MojoExecutionException: Error during site generation at org.apache.maven.doxia.DoxiaMojo.execute(DoxiaMojo.java:500) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:364) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:470) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:451) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:433) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:266) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:125) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:186) at org.apache.maven.cli.MavenCli.main(MavenCli.java:316) 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) Caused by: java.lang.IllegalArgumentException: Can't find a valid Maven project in the repository for the artifact [EMAIL PROTECTED] at org.apache.maven.report.projectinfo.DependenciesReport$DependenciesRenderer.renderBody(DependenciesReport.java:236) at org.apache.maven.reporting.AbstractMavenReportRenderer.render(AbstractMavenReportRenderer.java:65) at org.apache.maven.report.projectinfo.DependenciesReport.executeReport(DependenciesReport.java:147) at org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:117) at org.apache.maven.doxia.DoxiaMojo.execute(DoxiaMojo.java:298) ... 16 more I think the exception needs to have the actual artifact information. Perhaps the ActiveProjectArtifact class needs a toString method to fix this. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-753) Check for artifacts in POM-defined repositories before checking the central repository
Check for artifacts in POM-defined repositories before checking the central repository -- Key: MNG-753 URL: http://jira.codehaus.org/browse/MNG-753 Project: Maven 2 Type: Improvement Versions: 2.0-beta-1 Reporter: Bob Allison Priority: Minor In our Maven 1.0.2 build environment, we went to the trouble of building a replica of the ibiblio repository on a local machine because we would have builds hang for minutes if ibiblio decided to hiccup while the build was trying to update the snapshots of our current projects. It would be nice if Maven 2 would look for dependencies in the local repositories (those defined in the project and parent POMs) before looking in the central repository. This would allow locally-produced artifacts to be found faster (especially if the internet connection is dial-up) and would probably also reduce the load on the ibiblio servers. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-747) Javadoc classpath does not match compiler classpath
[ http://jira.codehaus.org/browse/MNG-747?page=comments#action_44679 ] Bob Allison commented on MNG-747: - Updated my SVN tree and tried things again. Works fine. > Javadoc classpath does not match compiler classpath > --- > > Key: MNG-747 > URL: http://jira.codehaus.org/browse/MNG-747 > Project: Maven 2 > Type: Bug > Versions: 2.0-beta-1 > Environment: SVN revision 233262 (17-Aug 1530 ET) > Reporter: Bob Allison > > > Project A depends on library X with scope "provided". > Project B depends on project A with scope "provided" but also uses library X. > When compiling project B, there is no need to declare the dependency on > library X. Trying to build the JavaDoc for project B fails because library X > is not 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-747) Javadoc classpath does not match compiler classpath
Javadoc classpath does not match compiler classpath --- Key: MNG-747 URL: http://jira.codehaus.org/browse/MNG-747 Project: Maven 2 Type: Bug Versions: 2.0-beta-1 Environment: SVN revision 233262 (17-Aug 1530 ET) Reporter: Bob Allison Project A depends on library X with scope "provided". Project B depends on project A with scope "provided" but also uses library X. When compiling project B, there is no need to declare the dependency on library X. Trying to build the JavaDoc for project B fails because library X is not 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-745) Deploying source jar to repository receives wrong name
[ http://jira.codehaus.org/browse/MNG-745?page=comments#action_44640 ] Bob Allison commented on MNG-745: - I'm not worried about the build ID being part of the artifact, I was looking at the file xx-SNAPSHOT.version.txt that is placed in the repository in the same directory as the jar file. I updated my SVN tree at 1530 ET today (revision 233262). The source jar is no longer created or deployed (which doesn't bother me, I was going to ask how to suppress it anyway), and the dependent project builds correctly. > Deploying source jar to repository receives wrong name > -- > > Key: MNG-745 > URL: http://jira.codehaus.org/browse/MNG-745 > Project: Maven 2 > Type: Bug > Components: maven-artifact > Versions: 2.0-beta-1 > Environment: Working from SVN revision 233074 > Project defined with jar > Reporter: Bob Allison > Assignee: John Casey > > > When the source jar is deployed to the repository (both as a release and as a > snapshot), the jar file is named wrong. The jar that is built is named > log4j-3.0-SNAPSHOT-sources.jar (as expected) but when it is deployed to the > repository it is named log4j-3.0-SNAPSHOT-artifactClassifier.artifactType -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-745) Deploying source jar to repository receives wrong name
[ http://jira.codehaus.org/browse/MNG-745?page=comments#action_44598 ] Bob Allison commented on MNG-745: - Correction on the above: In the repository, the file is log4j-3.0-20050816.233900-8-artifactClassifier.artifactType I am also noticing that the source jar has a different sequence number (the -8 in the above name) than the binary jar generated at the same time (its name is log4j-3.0-20050816.233900-7.jar). Because the source jar's sequence number appears in the log4j-3.0-SNAPSHOT.version.txt file in the repository, the project that depends on this jar is unable to download the POM or jar for the current snapshot. > Deploying source jar to repository receives wrong name > -- > > Key: MNG-745 > URL: http://jira.codehaus.org/browse/MNG-745 > Project: Maven 2 > Type: Bug > Components: maven-artifact > Versions: 2.0-beta-1 > Environment: Working from SVN revision 233074 > Project defined with jar > Reporter: Bob Allison > > > When the source jar is deployed to the repository (both as a release and as a > snapshot), the jar file is named wrong. The jar that is built is named > log4j-3.0-SNAPSHOT-sources.jar (as expected) but when it is deployed to the > repository it is named log4j-3.0-SNAPSHOT-artifactClassifier.artifactType -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-745) Deploying source jar to repository receives wrong name
Deploying source jar to repository receives wrong name -- Key: MNG-745 URL: http://jira.codehaus.org/browse/MNG-745 Project: Maven 2 Type: Bug Components: maven-artifact Versions: 2.0-beta-1 Environment: Working from SVN revision 233074 Project defined with jar Reporter: Bob Allison When the source jar is deployed to the repository (both as a release and as a snapshot), the jar file is named wrong. The jar that is built is named log4j-3.0-SNAPSHOT-sources.jar (as expected) but when it is deployed to the repository it is named log4j-3.0-SNAPSHOT-artifactClassifier.artifactType -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-734) java.lang.InstantiationException while deploying snapshot
[ http://jira.codehaus.org/browse/MNG-734?page=comments#action_44595 ] Bob Allison commented on MNG-734: - Well, that description does explain why when I simplified my POM for testing I started geting the exception for both snapshots and releases. Adding the snapshot repository reference fixed the problem. For the record, the working minimal test POM is: 4.0.0 qaccess log4j jar 3.0-SNAPSHOT Q.Access log4j Interface log4j log4j 1.2.8 jar provided qadev Q.Access Release Repository scp://cvs.host.machine/path/to/m2/release qadev Q.Access Development Repository scp://cvs.host.machine/path/to/m2/snapshot > java.lang.InstantiationException while deploying snapshot > - > > Key: MNG-734 > URL: http://jira.codehaus.org/browse/MNG-734 > Project: Maven 2 > Type: Bug > Components: maven-plugins > Versions: 2.0-beta-1 > Reporter: Bob Allison > Assignee: John Casey > Fix For: 2.0-beta-1 > > > Setting up a project to deploy a snapshot. From comments of others, I have a > bad POM in one of my dependencies (haven't tracked that down yet). > When I set the project's version to "3.0", the jar is deployed properly. > When I set the project's version to "3.0-SNAPSHOT", I get the following stack > dump: > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Diagnosis: Error configuring plugin for execution of 'deploy:deploy'. > [INFO] > > [ERROR] Cause: > org.apache.maven.plugin.MojoExecutionException: Error configuring plugin for > execution of 'deploy:deploy'. > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:342) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:472) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:445) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:431) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:268) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:127) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:186) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:292) > 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) > Caused by: org.apache.maven.plugin.PluginConfigurationException: Unable to > parse the created DOM for plugin configuration > at > org.apache.maven.plugin.DefaultPluginManager.populatePluginFields(DefaultPluginManager.java:1022) > at > org.apache.maven.plugin.DefaultPluginManager.getConfiguredMojo(DefaultPluginManager.java:522) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:337) > ... 15 more > Caused by: > org.codehaus.plexus.component.configurator.ComponentConfigurationException: > Class 'org.apache.maven.artifact.repository.ArtifactRepository' cannot be > instantiated > at > org.codehaus.plexus.component.configurator.converters.AbstractConfigurationConverter.instantiateObject(AbstractConfigurationConverter.java:120) > at > org.codehaus.plexus.component.configurator.converters.composite.ObjectWithFieldsConverter.fromConfiguration(ObjectWithFieldsConverter.java:83) > at > org.codehaus.plexus.component.configurator.converters.composite.ObjectWithFieldsConverter.processConfiguration(ObjectWithFieldsConverter.java:118) > at > org.codehaus.plexus.component.configurator.BasicComponentConfigurator.con
[jira] Commented: (MNG-734) java.lang.InstantiationException while deploying snapshot
[ http://jira.codehaus.org/browse/MNG-734?page=comments#action_44572 ] Bob Allison commented on MNG-734: - I renamed "deploymentRepository" to "ploymentRepository" so that it comes after "localRepository" during processing. This allows me to look at the method calls for both configuration elements. The method calls look identical, yet "localRepository" gets configured correctly and "ploymentRepository" causes an exception. > java.lang.InstantiationException while deploying snapshot > - > > Key: MNG-734 > URL: http://jira.codehaus.org/browse/MNG-734 > Project: Maven 2 > Type: Bug > Components: maven-plugins > Versions: 2.0-beta-1 > Reporter: Bob Allison > Fix For: 2.0-beta-1 > > > Setting up a project to deploy a snapshot. From comments of others, I have a > bad POM in one of my dependencies (haven't tracked that down yet). > When I set the project's version to "3.0", the jar is deployed properly. > When I set the project's version to "3.0-SNAPSHOT", I get the following stack > dump: > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Diagnosis: Error configuring plugin for execution of 'deploy:deploy'. > [INFO] > > [ERROR] Cause: > org.apache.maven.plugin.MojoExecutionException: Error configuring plugin for > execution of 'deploy:deploy'. > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:342) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:472) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:445) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:431) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:268) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:127) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:186) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:292) > 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) > Caused by: org.apache.maven.plugin.PluginConfigurationException: Unable to > parse the created DOM for plugin configuration > at > org.apache.maven.plugin.DefaultPluginManager.populatePluginFields(DefaultPluginManager.java:1022) > at > org.apache.maven.plugin.DefaultPluginManager.getConfiguredMojo(DefaultPluginManager.java:522) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:337) > ... 15 more > Caused by: > org.codehaus.plexus.component.configurator.ComponentConfigurationException: > Class 'org.apache.maven.artifact.repository.ArtifactRepository' cannot be > instantiated > at > org.codehaus.plexus.component.configurator.converters.AbstractConfigurationConverter.instantiateObject(AbstractConfigurationConverter.java:120) > at > org.codehaus.plexus.component.configurator.converters.composite.ObjectWithFieldsConverter.fromConfiguration(ObjectWithFieldsConverter.java:83) > at > org.codehaus.plexus.component.configurator.converters.composite.ObjectWithFieldsConverter.processConfiguration(ObjectWithFieldsConverter.java:118) > at > org.codehaus.plexus.component.configurator.BasicComponentConfigurator.configureComponent(BasicComponentConfigurator.java:55) > at > org.apache.maven.plugin.DefaultPluginManager.populatePluginFields(DefaultPluginManager.java:1017) > ... 17 more > Caused by: java.lang.InstantiationException: > org.apache.maven.artifact.repository.Artifact
[jira] Commented: (MNG-734) java.lang.InstantiationException while deploying snapshot
[ http://jira.codehaus.org/browse/MNG-734?page=comments#action_44562 ]
Bob Allison commented on MNG-734:
-
After putting a few System.out.println in the plexus code, I have traced the
cause of the exception back a little.
When the deploy plugin is loaded, it is configured with a call to
BasicComponentConfigurator.configureComponent method. The configuration that
is passed to this method is:
${project.artifact}
${project.attachedArtifacts}
${project.build.directory}
${project.distributionManagementArtifactRepository}
${project.build.finalName}
${localRepository}
${project.packaging}
${project.file.parentFile}
${updateReleaseInfo}
BasicComponentConfigurator.configureComponent calls
ObjectWithFieldsConverter.processConfiguration to convert each configuration
element into a Java object. When this method gets to the fourth element
(deploymentRepository) it calls ObjectWithFieldsConverter.fromConfiguration to
create an object. The problem here is that the implementation class specified
in the configuration is an interface and can't be instantiated.
> java.lang.InstantiationException while deploying snapshot
> -
>
> Key: MNG-734
> URL: http://jira.codehaus.org/browse/MNG-734
> Project: Maven 2
> Type: Bug
> Components: maven-plugins
> Versions: 2.0-beta-1
> Reporter: Bob Allison
> Fix For: 2.0-beta-1
>
>
> Setting up a project to deploy a snapshot. From comments of others, I have a
> bad POM in one of my dependencies (haven't tracked that down yet).
> When I set the project's version to "3.0", the jar is deployed properly.
> When I set the project's version to "3.0-SNAPSHOT", I get the following stack
> dump:
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Diagnosis: Error configuring plugin for execution of 'deploy:deploy'.
> [INFO]
>
> [ERROR] Cause:
> org.apache.maven.plugin.MojoExecutionException: Error configuring plugin for
> execution of 'deploy:deploy'.
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:342)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:472)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:445)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:431)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:268)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:127)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:186)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:292)
> 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)
> Caused by: org.apache.maven.plugin.PluginConfigurationException: Unable to
> parse the created DOM for plugin configuration
> at
> org.apache.maven.plugin.DefaultPluginManager.populatePluginFields(DefaultPluginManager.java:1022)
> at
> org.apache.maven.plugin.DefaultPluginManager.getConfiguredMojo(DefaultPluginManager.java:522)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:337)
> ... 15 more
> Caused by:
> org.codehaus.plexus.component.configurator.ComponentConfigurationException:
> Class 'org.apache.maven.artifact.repository.ArtifactRepository' cannot be
> instantiated
> at
> org.codehaus.plexus.component.configurator.converters.AbstractConfigurationConverter.instantiateObject(AbstractConfigurationConverter.java:120)
> at
> org.codehaus.plexus.component.confi
[jira] Commented: (MNG-734) java.lang.InstantiationException while deploying snapshot
[ http://jira.codehaus.org/browse/MNG-734?page=comments#action_44416 ] Bob Allison commented on MNG-734: - I have simplified my POM to the following: 4.0.0 qaccess log4j jar 3.0-SNAPSHOT Q.Access log4j Interface log4j log4j 1.2.8 jar provided I am still getting the exception while deploying the snapshot. > java.lang.InstantiationException while deploying snapshot > - > > Key: MNG-734 > URL: http://jira.codehaus.org/browse/MNG-734 > Project: Maven 2 > Type: Bug > Components: maven-plugins > Versions: 2.0-beta-1 > Reporter: Bob Allison > > > Setting up a project to deploy a snapshot. From comments of others, I have a > bad POM in one of my dependencies (haven't tracked that down yet). > When I set the project's version to "3.0", the jar is deployed properly. > When I set the project's version to "3.0-SNAPSHOT", I get the following stack > dump: > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Diagnosis: Error configuring plugin for execution of 'deploy:deploy'. > [INFO] > > [ERROR] Cause: > org.apache.maven.plugin.MojoExecutionException: Error configuring plugin for > execution of 'deploy:deploy'. > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:342) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:472) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:445) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:431) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:268) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:127) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:186) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:292) > 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) > Caused by: org.apache.maven.plugin.PluginConfigurationException: Unable to > parse the created DOM for plugin configuration > at > org.apache.maven.plugin.DefaultPluginManager.populatePluginFields(DefaultPluginManager.java:1022) > at > org.apache.maven.plugin.DefaultPluginManager.getConfiguredMojo(DefaultPluginManager.java:522) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:337) > ... 15 more > Caused by: > org.codehaus.plexus.component.configurator.ComponentConfigurationException: > Class 'org.apache.maven.artifact.repository.ArtifactRepository' cannot be > instantiated > at > org.codehaus.plexus.component.configurator.converters.AbstractConfigurationConverter.instantiateObject(AbstractConfigurationConverter.java:120) > at > org.codehaus.plexus.component.configurator.converters.composite.ObjectWithFieldsConverter.fromConfiguration(ObjectWithFieldsConverter.java:83) > at > org.codehaus.plexus.component.configurator.converters.composite.ObjectWithFieldsConverter.processConfiguration(ObjectWithFieldsConverter.java:118) > at > org.codehaus.plexus.component.configurator.BasicComponentConfigurator.configureComponent(BasicComponentConfigurator.java:55) > at > org.apache.maven.plugin.DefaultPluginManager.populatePluginFields(DefaultPluginManager.java:1017) > ... 17 more > Caused by: java.lang.InstantiationException: > org.apache.maven.artifact.repository.ArtifactRepository > at java.lang.Class.newInstance0(Class.java:335) > at java.lang.Class.newInstance(Class.java:303)
[jira] Commented: (MNG-734) java.lang.InstantiationException while deploying snapshot
[ http://jira.codehaus.org/browse/MNG-734?page=comments#action_44415 ] Bob Allison commented on MNG-734: - Exception is thrown because org.apache.maven.artifact.repository.ArtifactRepository is an interface. To try to see what is happening, I added a System.out.println at the beginning of AbstractConfigurationConverter.instantiateObject (the method throwing the exception) to see every time an object is being created this way. When deploying a release, no objects are created using this method while configuring the deploy plugin. When deploying a snapshot, an attempt is made to instantiate this interface. > java.lang.InstantiationException while deploying snapshot > - > > Key: MNG-734 > URL: http://jira.codehaus.org/browse/MNG-734 > Project: Maven 2 > Type: Bug > Components: maven-plugins > Versions: 2.0-beta-1 > Reporter: Bob Allison > > > Setting up a project to deploy a snapshot. From comments of others, I have a > bad POM in one of my dependencies (haven't tracked that down yet). > When I set the project's version to "3.0", the jar is deployed properly. > When I set the project's version to "3.0-SNAPSHOT", I get the following stack > dump: > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Diagnosis: Error configuring plugin for execution of 'deploy:deploy'. > [INFO] > > [ERROR] Cause: > org.apache.maven.plugin.MojoExecutionException: Error configuring plugin for > execution of 'deploy:deploy'. > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:342) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:472) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:445) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:431) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:268) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:127) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:186) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:292) > 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) > Caused by: org.apache.maven.plugin.PluginConfigurationException: Unable to > parse the created DOM for plugin configuration > at > org.apache.maven.plugin.DefaultPluginManager.populatePluginFields(DefaultPluginManager.java:1022) > at > org.apache.maven.plugin.DefaultPluginManager.getConfiguredMojo(DefaultPluginManager.java:522) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:337) > ... 15 more > Caused by: > org.codehaus.plexus.component.configurator.ComponentConfigurationException: > Class 'org.apache.maven.artifact.repository.ArtifactRepository' cannot be > instantiated > at > org.codehaus.plexus.component.configurator.converters.AbstractConfigurationConverter.instantiateObject(AbstractConfigurationConverter.java:120) > at > org.codehaus.plexus.component.configurator.converters.composite.ObjectWithFieldsConverter.fromConfiguration(ObjectWithFieldsConverter.java:83) > at > org.codehaus.plexus.component.configurator.converters.composite.ObjectWithFieldsConverter.processConfiguration(ObjectWithFieldsConverter.java:118) > at > org.codehaus.plexus.component.configurator.BasicComponentConfigurator.configureComponent(BasicComponentConfigurator.java:55) > at > org.apache.maven.plugin.DefaultPluginManager.populatePluginF
[jira] Created: (MNG-734) java.lang.InstantiationException while deploying snapshot
java.lang.InstantiationException while deploying snapshot - Key: MNG-734 URL: http://jira.codehaus.org/browse/MNG-734 Project: Maven 2 Type: Bug Components: maven-plugins Versions: 2.0-beta-1 Reporter: Bob Allison Setting up a project to deploy a snapshot. From comments of others, I have a bad POM in one of my dependencies (haven't tracked that down yet). When I set the project's version to "3.0", the jar is deployed properly. When I set the project's version to "3.0-SNAPSHOT", I get the following stack dump: [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Diagnosis: Error configuring plugin for execution of 'deploy:deploy'. [INFO] [ERROR] Cause: org.apache.maven.plugin.MojoExecutionException: Error configuring plugin for execution of 'deploy:deploy'. at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:342) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:472) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:445) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:431) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:268) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:127) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:186) at org.apache.maven.cli.MavenCli.main(MavenCli.java:292) 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) Caused by: org.apache.maven.plugin.PluginConfigurationException: Unable to parse the created DOM for plugin configuration at org.apache.maven.plugin.DefaultPluginManager.populatePluginFields(DefaultPluginManager.java:1022) at org.apache.maven.plugin.DefaultPluginManager.getConfiguredMojo(DefaultPluginManager.java:522) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:337) ... 15 more Caused by: org.codehaus.plexus.component.configurator.ComponentConfigurationException: Class 'org.apache.maven.artifact.repository.ArtifactRepository' cannot be instantiated at org.codehaus.plexus.component.configurator.converters.AbstractConfigurationConverter.instantiateObject(AbstractConfigurationConverter.java:120) at org.codehaus.plexus.component.configurator.converters.composite.ObjectWithFieldsConverter.fromConfiguration(ObjectWithFieldsConverter.java:83) at org.codehaus.plexus.component.configurator.converters.composite.ObjectWithFieldsConverter.processConfiguration(ObjectWithFieldsConverter.java:118) at org.codehaus.plexus.component.configurator.BasicComponentConfigurator.configureComponent(BasicComponentConfigurator.java:55) at org.apache.maven.plugin.DefaultPluginManager.populatePluginFields(DefaultPluginManager.java:1017) ... 17 more Caused by: java.lang.InstantiationException: org.apache.maven.artifact.repository.ArtifactRepository at java.lang.Class.newInstance0(Class.java:335) at java.lang.Class.newInstance(Class.java:303) at org.codehaus.plexus.component.configurator.converters.AbstractConfigurationConverter.instantiateObject(AbstractConfigurationConverter.java:110) ... 21 more -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-696) Web site cannot be generated with duplicate file names in different directories
Web site cannot be generated with duplicate file names in different directories --- Key: MNG-696 URL: http://jira.codehaus.org/browse/MNG-696 Project: Maven 2 Type: Bug Components: maven-plugins Versions: 2.0-beta-1 Reporter: Bob Allison Priority: Minor I have a tool I am using to generate UML diagrams for the project I am working on. This tool is capable of generating a web site with all of the diagrams and text, organized in a set of directories based on the way the model is organized. In the top directory that the tool generates is a file "index.html" which provides the starting point to browse the diagrams. I am trying to incorporate this documentation into the Maven-generated site. To do this, I am copying the entire tree into my project tree at src/site/resources/uml and put a link in the site.xml to point to "./uml". When I try to build the site, the site plugin complains that src/site/resource/uml/index.html is a duplicate of src/site/xdoc/index/xml. If I rename the index.html in the uml tree, the site builds fine and the uml tree appears in target/site/uml. Why does the plugin complain that the file is a duplicate since it will not be placed in the same directory? -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-695) Exceptions thrown building project information report "Source Repository"
[ http://jira.codehaus.org/browse/MNG-695?page=comments#action_43857 ]
Bob Allison commented on MNG-695:
-
I made the following changes to ScmReport.java to eliminate the problem:
In method renderDeveloperAccessSection, added the following at the top of the
method:
if ( devRepository == null )
{
return;
}
In method getScmRepository, added the following after the check for scmUrl ==
null:
if ( scmUrl.equals("") )
{
return null;
}
I don't know if these changes are the best, but they do seem to work for me.
> Exceptions thrown building project information report "Source Repository"
> -
>
> Key: MNG-695
> URL: http://jira.codehaus.org/browse/MNG-695
> Project: Maven 2
> Type: Bug
> Components: maven-plugins
> Versions: 2.0-beta-1
> Reporter: Bob Allison
>
>
> (This was working yesterday. This morning I updated my SVN tree to 227227
> and this started happening.)
> I am not currently using SCM features of Maven, so I do not have a developer
> connection defined. In v1.0.2, I have always had an empty tag in the
> project.xml.
> If the v2 POM has "", I get the following exception:
> [INFO]
>
> [INFO] Diagnosis: Error during site generation
> [INFO]
>
> [ERROR] Cause:
> org.apache.maven.plugin.MojoExecutionException: Error during site generation
> at org.apache.maven.doxia.DoxiaMojo.execute(DoxiaMojo.java:491)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:361)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:378)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:359)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:341)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:229)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:123)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:209)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:267)
> 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)
> Caused by: java.lang.StringIndexOutOfBoundsException: String index out of
> range: -4
> at java.lang.String.substring(String.java:1768)
> at java.lang.String.substring(String.java:1735)
> at
> org.apache.maven.scm.manager.plexus.DefaultScmManager.findDelimiter(DefaultScmManager.java:218)
> at
> org.apache.maven.scm.manager.plexus.DefaultScmManager.makeScmRepository(DefaultScmManager.java:118)
> at
> org.apache.maven.report.projectinfo.ScmReport$ScmRenderer.getScmRepository(ScmReport.java:632)
> at
> org.apache.maven.report.projectinfo.ScmReport$ScmRenderer.renderBody(ScmReport.java:200)
> at
> org.apache.maven.reporting.AbstractMavenReportRenderer.render(AbstractMavenReportRenderer.java:65)
> at
> org.apache.maven.report.projectinfo.ScmReport.executeReport(ScmReport.java:135)
> at
> org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:117)
> at org.apache.maven.doxia.DoxiaMojo.execute(DoxiaMojo.java:290)
> ... 16 more
> If a comment out the stanza, I get the following exception:
> [INFO]
>
> [INFO] Diagnosis: Error during site generation
> [INFO]
>
> [ERROR] Cause:
> org.apache.maven.plugin.MojoExecutionException: Error during site generation
> at org.apache.maven.doxia.DoxiaMojo.execute(DoxiaMojo.java:491)
> at
> org.apache.m
[jira] Created: (MNG-695) Exceptions thrown building project information report "Source Repository"
Exceptions thrown building project information report "Source Repository" - Key: MNG-695 URL: http://jira.codehaus.org/browse/MNG-695 Project: Maven 2 Type: Bug Components: maven-plugins Versions: 2.0-beta-1 Reporter: Bob Allison (This was working yesterday. This morning I updated my SVN tree to 227227 and this started happening.) I am not currently using SCM features of Maven, so I do not have a developer connection defined. In v1.0.2, I have always had an empty tag in the project.xml. If the v2 POM has "", I get the following exception: [INFO] [INFO] Diagnosis: Error during site generation [INFO] [ERROR] Cause: org.apache.maven.plugin.MojoExecutionException: Error during site generation at org.apache.maven.doxia.DoxiaMojo.execute(DoxiaMojo.java:491) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:361) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:378) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:359) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:341) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:229) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:123) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:209) at org.apache.maven.cli.MavenCli.main(MavenCli.java:267) 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) Caused by: java.lang.StringIndexOutOfBoundsException: String index out of range: -4 at java.lang.String.substring(String.java:1768) at java.lang.String.substring(String.java:1735) at org.apache.maven.scm.manager.plexus.DefaultScmManager.findDelimiter(DefaultScmManager.java:218) at org.apache.maven.scm.manager.plexus.DefaultScmManager.makeScmRepository(DefaultScmManager.java:118) at org.apache.maven.report.projectinfo.ScmReport$ScmRenderer.getScmRepository(ScmReport.java:632) at org.apache.maven.report.projectinfo.ScmReport$ScmRenderer.renderBody(ScmReport.java:200) at org.apache.maven.reporting.AbstractMavenReportRenderer.render(AbstractMavenReportRenderer.java:65) at org.apache.maven.report.projectinfo.ScmReport.executeReport(ScmReport.java:135) at org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:117) at org.apache.maven.doxia.DoxiaMojo.execute(DoxiaMojo.java:290) ... 16 more If a comment out the stanza, I get the following exception: [INFO] [INFO] Diagnosis: Error during site generation [INFO] [ERROR] Cause: org.apache.maven.plugin.MojoExecutionException: Error during site generation at org.apache.maven.doxia.DoxiaMojo.execute(DoxiaMojo.java:491) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:361) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:378) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:359) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:341) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:229) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:123) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:209) at org.apache.maven.cli.MavenCli.main(MavenCli.java:267) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMetho
[jira] Created: (MNG-693) Reporting stanza is not inherited from parent
Reporting stanza is not inherited from parent - Key: MNG-693 URL: http://jira.codehaus.org/browse/MNG-693 Project: Maven 2 Type: Bug Versions: 2.0-beta-1 Reporter: Bob Allison Priority: Minor I have a multi-level project using Maven 1.0.2 that I am working on converting to Maven 2. In the 1.0.2 environment, I have the top level project define a number of defaults for all of the projects; this allows the project.xml and maven.xml files for lower-level projects to be small (or in the case of the maven.xml file, unneeded). While working towards building up the inheritance in the new model, it appears that the information in the stanza of the top level project is not getting inherited by the lower-level projects. To get any reports to be generated, I need to copy the stanza from the parent into each lower-level project. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-690) Make text in appear the same size as the rest of the text
Make text in appear the same size as the rest of the text
---
Key: MNG-690
URL: http://jira.codehaus.org/browse/MNG-690
Project: Maven 2
Type: Improvement
Components: maven-plugins
Versions: 2.0-alpha-3
Reporter: Bob Allison
Priority: Minor
As currently defined, text in a paragraph that is enclosed in ...
will appear much smaller. This has been true since v1.0.2 or earlier.
Adding the following four lines to "maven-theme.css" will fix the problem (I
would suggest adding them right after the first four lines which set similar
information for most other text):
code{
font-family: Courier, monospace;
font-size: 13px;
}
--
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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
