[continuum build - SUCCESS - update] Tue Dec 20 11:00:00 GMT 2005
Distribution: http://maven.zones.apache.org/~continuum/builds/continuum-20051220.11.tar.gz Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20051220.11.txt
[jira] Created: (CONTINUUM-522) IRC support needed for IRC servers not supporting /privmsg
IRC support needed for IRC servers not supporting /privmsg -- Key: CONTINUUM-522 URL: http://jira.codehaus.org/browse/CONTINUUM-522 Project: Continuum Type: Improvement Components: IRC Notifier Versions: 1.0.2 Environment: Linux Reporter: Daniel Kulp The IRC server we use in house does not support /privmsg for any non-operator user. The IS folks are refusing to add any other operators for use by the continuum builds. It would be nice if we could configure the IRC notifier to do a normal: /join #channel and then a normal text message is sent. -- 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
[continuum build - SUCCESS - update] Tue Dec 20 22:30:00 GMT 2005
Distribution: http://maven.zones.apache.org/~continuum/builds/continuum-20051220.223000.tar.gz Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20051220.223000.txt
[continuum build - FAILED - update] Wed Dec 21 00:30:00 GMT 2005
Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20051221.003001.txt
[continuum build - FAILED - update] Wed Dec 21 01:00:00 GMT 2005
Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20051221.01.txt
[continuum build - FAILED - checkout] Wed Dec 21 01:30:00 GMT 2005
Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20051221.013000.txt
[continuum build - FAILED - update] Wed Dec 21 02:00:00 GMT 2005
Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20051221.02.txt
[continuum build - FAILED - update] Wed Dec 21 03:00:00 GMT 2005
Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20051221.03.txt
[continuum build - SUCCESS - update] Wed Dec 21 03:30:00 GMT 2005
Distribution: http://maven.zones.apache.org/~continuum/builds/continuum-20051221.033000.tar.gz Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20051221.033000.txt
[jira] Commented: (MSITE-11) PluginManagement config is not used by plugins enabled in the site generation phase
[ http://jira.codehaus.org/browse/MSITE-11?page=comments#action_53795 ]
Indrajit Raychaudhuri commented on MSITE-11:
Wonderful!
So the reportingManagement/ idea in [#action_53690] _actually_ makes sense to
me now and appears clean enough too.
This also appears to be a candidate for docu. somewhere (maybe in maven-model)
specifying the distinction between buildpluginManagement//build and
reportingManagement/ and what should go where (as part of best-practice).
PluginManagement config is not used by plugins enabled in the site generation
phase
---
Key: MSITE-11
URL: http://jira.codehaus.org/browse/MSITE-11
Project: Maven 2.x Site Plugin
Type: Bug
Environment: maven-site-plugin 2.0-beta-3-SNAPSHOT
Reporter: Indrajit Raychaudhuri
Consider the following POM:
{code:xml}
!-- ... ... --
!-- ... ... --
build
pluginManagement
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-javadoc-plugin/artifactId
configuration
authorfalse/author
/configuration
/plugin
/pluginManagement
/build
!-- ... ... --
!-- ... ... --
reporting
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-javadoc-plugin/artifactId
/plugin
/plugins
/reporting
!-- ... ... --
{code}
{{mvn site:site}} doesn't honor the javadoc configuration specified in the
{{pluginManagement/}} section.
However, {{mvn javadoc:javadoc}} honors them.
This is true not just for javadoc but other plugins like checkstyle as well.
I guess, the {{reporting/}} section doesn't use the {{pluginManagement/}}
section at all.
--
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]
Re: Moved: (MRELEASE-7) Release versioning does not work with dependencyManagement
[ http://jira.codehaus.org/browse/MRELEASE-7?page=all ] Jason van Zyl moved MNG-1728 to MRELEASE-7: --- Version: (was: 2.0.1) Component: (was: maven-release-plugin) Workflow: jira (was: Maven) Key: MRELEASE-7 (was: MNG-1728) Project: Maven 2.x Release Plugin (was: Maven 2) Release versioning does not work with dependencyManagement -- Key: MRELEASE-7 URL: http://jira.codehaus.org/browse/MRELEASE-7 Project: Maven 2.x Release Plugin Type: Bug Reporter: mike perham Assignee: Brett Porter Attachments: scm-test.zip We use a top-level dependencyManagement block in our root POM to hold all versions. Children reference group/artifact but do not specify the version in their own POMs. When I prepare a top-level release of the parent and children, the child POMs have the versions added and the parent POM still contains the old version. Attached is a very simple project set. Update the SCM connection, do a release:prepare and examine the parent and scmwar\'s POM. -- 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Moved: (MRELEASE-36) Release plugin fails to update SNAPSHOTS in the dependencyManagement section
[ http://jira.codehaus.org/browse/MRELEASE-36?page=all ] Jason van Zyl moved MNG-1374 to MRELEASE-36: Version: (was: 2.0) Fix Version: (was: 2.0.1) Component: (was: maven-release-plugin) Workflow: jira (was: Maven) Key: MRELEASE-36 (was: MNG-1374) Project: Maven 2.x Release Plugin (was: Maven 2) Release plugin fails to update SNAPSHOTS in the dependencyManagement section Key: MRELEASE-36 URL: http://jira.codehaus.org/browse/MRELEASE-36 Project: Maven 2.x Release Plugin Type: Bug Environment: Maven 2.0 (release-plugin version: 2.0-beta3) Reporter: Шrjan Austvold Assignee: John Casey Attachments: prep.txt In a multi project the parent-pom can specify \standard\ versions for dependencies within the project group. I have found it convenient to also list group-members with versions in this section so that all child artifact within the group simply specifies inter-group artifact dependencies without versions. The release plugin fails to alter SNAPSHOT dependencies within the dependencyMangement section. The tagged version of child poms gets instead the correct version explicitly stated in their dependency section. It seems a bit strange that dependencies on artifacts within a group must have dependencies on other artifacts within the group listed with version numbers. -- 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MPA-35) add Lukas Theussl to the PMC
add Lukas Theussl to the PMC Key: MPA-35 URL: http://jira.codehaus.org/browse/MPA-35 Project: Maven Project Administration Type: Task Reporter: Brett Porter Assigned to: Jason van Zyl Jason to add Lukas to the PMC roster in committee-info.txt 72 hours after the creation of this issue. -- 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]
Improve methods to define the scope and packaging of dependencies (MNG-1732)
I'm back from vacation now, so if this won't start another holy war (like XML format) I have two questions on this issue: 1) Why is this a bad idea? 2) Assuming that this idea won't be done, any suggestions on how to configure the mapping of dependencies to RPM installation locations? A good deal of the reason for the suggestion was to allow dependencies to be easily mapped to the location where the RPM package should install them. If the project has dependencies which need to be packaged, I need to know where to put them. With things the way they are right now, I need to specify the group/artifact/version/type as a dependency then repeat the information in the RPM plugin configuration so that I can link that dependency with a location in the package. I also see a lot of confusion on the user list on how to get a dependency [not] packaged in a war/ear/ejb (especially when people make the same mistake I made and assume that compile scope means compile-time, not everywhere) since you have to play games with the scope and exclusions to get things packaged correctly (based on what I see on the user list). -Original Message- From: Brett Porter (JIRA) [mailto:[EMAIL PROTECTED] Sent: Sunday, December 11, 2005 02:51 To: dev@maven.apache.org Subject: [jira] Closed: (MNG-1732) Improve methods to define the scope andpackaging of dependencies [ http://jira.codehaus.org/browse/MNG-1732?page=all ] Brett Porter closed MNG-1732: - Assign To: Brett Porter Resolution: Won't Fix we can answer questions about why this is a bad idea on the dev list 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 Assignee: Brett Porter 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: dependency groupIdjunit/groupId artifactIdjunit/artifactId version3.8.1/version !--scopetest/scope-- usage compiletrue/compile testtrue/test executefalse/execute jarfalse/jar rpm/usr/local/lib/rpm /usage /dependency I see two classes of items within the usage 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 scope and usage would be accepted and that usage would be configured as a Map. If possible, it would be easier for mojos to use this arrangement if specifying scope would cause a pre-configured usage 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MRM-41) discover standalone POMs
[ http://jira.codehaus.org/browse/MRM-41?page=all ] John Tolentino updated MRM-41: -- Attachment: repository-manager.diff discover standalone POMs Key: MRM-41 URL: http://jira.codehaus.org/browse/MRM-41 Project: Maven Repository Manager Type: Task Components: discovery Reporter: Brett Porter Assignee: John Tolentino Fix For: 1.0-alpha-1 Attachments: repository-manager.diff where the pom is the artifact -- 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: (MRM-41) discover standalone POMs
[ http://jira.codehaus.org/browse/MRM-41?page=all ] John Tolentino updated MRM-41: -- Attachment: (was: repository-manager.diff) discover standalone POMs Key: MRM-41 URL: http://jira.codehaus.org/browse/MRM-41 Project: Maven Repository Manager Type: Task Components: discovery Reporter: Brett Porter Assignee: John Tolentino Fix For: 1.0-alpha-1 Attachments: repository-manager.diff where the pom is the artifact -- 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] Reopened: (MPASPECTJ-21) Support AspectJ 5
[ http://jira.codehaus.org/browse/MPASPECTJ-21?page=all ] Carlos Sanchez reopened MPASPECTJ-21: - Assign To: (was: Carlos Sanchez) Updated to 1.5RC1, waiting for final Support AspectJ 5 - Key: MPASPECTJ-21 URL: http://jira.codehaus.org/browse/MPASPECTJ-21 Project: maven-aspectj-plugin Type: Improvement Reporter: Carlos Sanchez Fix For: 4.0 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1880) Add new pre and post phases to the integration-test phase
Add new pre and post phases to the integration-test phase - Key: MNG-1880 URL: http://jira.codehaus.org/browse/MNG-1880 Project: Maven 2 Type: Wish Components: Plugins and Lifecycle Versions: 2.0.1 Reporter: Vincent Massol Here's an example: Imagine I want to use the cargo plugin for starting/stopping my container. I need to attach the cargo:start goal to a phase and I need to do the same for the cargo:stop goal. I can't do that today. Of course, I could modify the cargo plugin and offer some cargo:test goal that would do it all. But that violates the concept of phases and reduces the options for the users (note: I may still offer a cargo:test goal but I'd like to user to be able to map cargo goals to phases himself too). This is just an example. By definition IT require a running environment so there'll always be a need to set up and tear down stuff. -- 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] Closed: (MAVENUPLOAD-643) Upload ExtremeComponents 1.0.1-M3
[ http://jira.codehaus.org/browse/MAVENUPLOAD-643?page=all ] Carlos Sanchez closed MAVENUPLOAD-643: -- Assign To: Carlos Sanchez Resolution: Fixed Upload ExtremeComponents 1.0.1-M3 - Key: MAVENUPLOAD-643 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-643 Project: maven-upload-requests Type: Task Reporter: Emmanuel Venisse Assignee: Carlos Sanchez eXtremeComponents is a jsp dynamically generated table. -- 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]
RE: JIRA Project for Maven 2.x Plug-ins
Hi Jason, Great! Shouldn't we remove the JIRA components for the plugins in the Maven 2 JIRA project? Thanks -Vincent -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: mardi 20 décembre 2005 03:33 To: Maven Users List Subject: JIRA Project for Maven 2.x Plug-ins Hi, We are trying to streamline our processes and so each Maven 2.x Plug-in now has its own JIRA project. This will allow us to have clear roadmaps for each plug-in, and make it easier for users to influence our work/release ordering. We will now be able to use the voting mechanism more effectively so we can more easily see what users want us to do. So, please start using the pertinent JIRA project when raising issues for a particular plug-in. I will migrate the existing issues over. For reference these are the JIRA projects that have been created: Maven 2.x Antlr Plugin: http://jira.codehaus.org/browse/MANTLR Maven 2.x Ant Plugin: http://jira.codehaus.org/browse/MANT Maven 2.x Antrun Plugin: http://jira.codehaus.org/browse/MANTRUN Maven 2.x Assembly Plugin: http://jira.codehaus.org/browse/MASSEMBLY Maven 2.x Checkstyle Plugin: http://jira.codehaus.org/browse/MCHECKSTYLE Maven 2.x Clean Plugin: http://jira.codehaus.org/browse/MCLEAN Maven 2.x Clover Plugin: http://jira.codehaus.org/browse/MCLOVER Maven 2.x Compiler Plugin: http://jira.codehaus.org/browse/MCOMPILER Maven 2.x Deploy Plugin: http://jira.codehaus.org/browse/MDEPLOY Maven 2.x Ear Plugin: http://jira.codehaus.org/browse/MEAR Maven 2.x Eclipse Plugin: http://jira.codehaus.org/browse/MECLIPSE Maven 2.x Ejb Plugin: http://jira.codehaus.org/browse/MEJB Maven 2.x Idea Plugin: http://jira.codehaus.org/browse/MIDEA Maven 2.x Install Plugin: http://jira.codehaus.org/browse/MINSTALL Maven 2.x Jar Plugin: http://jira.codehaus.org/browse/MJAR Maven 2.x Javadoc Plugin: http://jira.codehaus.org/browse/MJAVADOC Maven 2.x Plugin Plugin: http://jira.codehaus.org/browse/MPLUGIN Maven 2.x Pmd Plugin: http://jira.codehaus.org/browse/MPMD Maven 2.x Project Help Plugin: http://jira.codehaus.org/browse/MPH Maven 2.x Project Info Reports Plugin: http://jira.codehaus.org/browse/MPIR Maven 2.x Rar Plugin: http://jira.codehaus.org/browse/MRAR Maven 2.x Release Plugin: http://jira.codehaus.org/browse/MRELEASE Maven 2.x Resources Plugin: http://jira.codehaus.org/browse/MRESOURCES Maven 2.x Site Plugin: http://jira.codehaus.org/browse/MSITE Maven 2.x Sources Plugin: http://jira.codehaus.org/browse/MSOURCES Maven 2.x Surefire Plugin: http://jira.codehaus.org/browse/MSUREFIRE Maven 2.x Verifier Plugin: http://jira.codehaus.org/browse/MVERIFIER Maven 2.x War Plugin: http://jira.codehaus.org/browse/MWAR If there are any problems please let us know. Hope this makes tracking plug-ins easier for all of us. As an aside, if anyone is interested in JIRA automation there are several Java and Ruby-based tools here that I used to automate the creation of the projects above. http://svn.apache.org/viewcvs.cgi/maven/sandbox/issue/ I will also be using these tools to make some reports which will allow us to see at a glance what users want in terms of features, fixes and releases. -- jvz. Jason van Zyl jason at maven.org http://maven.apache.org believe nothing, no matter where you read it, or who has said it, not even if i have said it, unless it agrees with your own reason and your own common sense. -- Buddha - 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]
[m2] custom plugin called multiple time with different configuration: problem
I have a site report/plugin that holds the common settings (actually all settings), it has the goal report I have for each specific report a subclass of that one that overrides a run() function (the only diffirence) if I use the this in the pom.xml, it uses the specific inputfile but if I do not add idX/id where X is a unique number, it uses the settings of the first time it was called with that number how can I make that it's not necessary to add idunique number/id? are there alternatives to calling one report.java with different settings? do I need those subclasses LinguineMapsPlugin extends AbstractMavenReport @goal report DtdReport extends LinguineMapsPlugin @goal dtdreport WsdlReport extends LinguineMapsPlugin @goal wsdlreport ... reporting plugins plugin groupIdorg.codehaus.mojo/groupId artifactIdmaven-linguine-maps-plugin/artifactId version1.0.0-alpha-1/version reportSets reportSet reports reportwsdlreport/report /reports id0/id configuration inputfiles inputfile src/test/resources/wsdl/reportservice.wsdl /inputfile /inputfiles outputfiletest_wsdl.png/outputfile /configuration /reportSet reportSet reports reportdtdreport/report /reports id1/id configuration inputfiles inputfile src/test/resources/dtd/hibernate-mapping-3.0.dtd /inputfile /inputfiles outputfiletest_dtd.png/outputfile /configuration /reportSet /reportSets configuration exefile C:/Program Files/ATT/Graphviz/bin/dot.exe /exefile /configuration /plugin /plugins /reporting -- met vriendelijke groeten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Site aggregation (Relocating discussion from confluence to dev)
Re discussion regarding site aggregation See: http://docs.codehaus.org/display/MAVEN/Sites+and+Inheritence for previous notes. Hi Brett, Re your last comments: 'The copy is done from the top level so it can run as an aggregator and the subprojects can be viewed as a single site and deployed as one. However, I see that if any of the subprojects have a different URL this won't work, so it may need to be reconsidered.' Although I see the need for a parent project site generation to access and parse its child projects files to build various composite and aggregate reports (such as javadoc or the various code analysis tools) I do not see why this would require copies of the child project's site files themselves. In fact thinking about it I would expect the composite report generation to use the 'raw' data files and not the HTML report prepared versions of those files (i.e. process the surefire XML output or the checkstyle XML output). In terms of deployment I do not think we should be breaking the project independence by trying to deploy child sites via the parent site for the various reasons I have already described: namely that a child's site deployment details are not related to the deployment details of its parent, and therefore all child and parent HTML HREF linking must be via project.URLs and not filesystem relative locations. I am not sure of the real meaning of an @aggregator Mojo (despite hunting for details on maven.apache.org) so maybe I'm missing some magic here but the way I see it is that all a child's generated artefacts, including its site files, are independent of its parent's generated assets in terms of their addressing and deployment semantics. The child relationship is only one of build order and POM inheritance, not artefact dependency. I will raise a JIRA regarding the fact that project.getParent() returns an un-interpolated project. Cheers, John - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MEV-140) Tapestry POM missing dependencies for javassist (2.6), ognl (2.6.3), commons-fileupload (1.0)
[ http://jira.codehaus.org/browse/MEV-140?page=all ] Carlos Sanchez closed MEV-140: -- Assign To: Carlos Sanchez (was: Edwin Punzalan) Resolution: Fixed Used attached pom Tapestry POM missing dependencies for javassist (2.6), ognl (2.6.3), commons-fileupload (1.0) - Key: MEV-140 URL: http://jira.codehaus.org/browse/MEV-140 Project: Maven Evangelism Type: Bug Components: Missing POM Reporter: Matt Raible Assignee: Carlos Sanchez Attachments: tapestry-3.0.3.pom You might include tapestry-contrib since most everyone uses it when using Tapestry. -- 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]
Re: JIRA Project for Maven 2.x Plug-ins
Vincent Massol wrote: Hi Jason, Great! Shouldn't we remove the JIRA components for the plugins in the Maven 2 JIRA project? I think so. Deng and Allan were helping me transfer over the issues to the new project and that's complete so we go ahead and remove the components. Thanks -Vincent -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: mardi 20 décembre 2005 03:33 To: Maven Users List Subject: JIRA Project for Maven 2.x Plug-ins Hi, We are trying to streamline our processes and so each Maven 2.x Plug-in now has its own JIRA project. This will allow us to have clear roadmaps for each plug-in, and make it easier for users to influence our work/release ordering. We will now be able to use the voting mechanism more effectively so we can more easily see what users want us to do. So, please start using the pertinent JIRA project when raising issues for a particular plug-in. I will migrate the existing issues over. For reference these are the JIRA projects that have been created: Maven 2.x Antlr Plugin: http://jira.codehaus.org/browse/MANTLR Maven 2.x Ant Plugin: http://jira.codehaus.org/browse/MANT Maven 2.x Antrun Plugin: http://jira.codehaus.org/browse/MANTRUN Maven 2.x Assembly Plugin: http://jira.codehaus.org/browse/MASSEMBLY Maven 2.x Checkstyle Plugin: http://jira.codehaus.org/browse/MCHECKSTYLE Maven 2.x Clean Plugin: http://jira.codehaus.org/browse/MCLEAN Maven 2.x Clover Plugin: http://jira.codehaus.org/browse/MCLOVER Maven 2.x Compiler Plugin: http://jira.codehaus.org/browse/MCOMPILER Maven 2.x Deploy Plugin: http://jira.codehaus.org/browse/MDEPLOY Maven 2.x Ear Plugin: http://jira.codehaus.org/browse/MEAR Maven 2.x Eclipse Plugin: http://jira.codehaus.org/browse/MECLIPSE Maven 2.x Ejb Plugin: http://jira.codehaus.org/browse/MEJB Maven 2.x Idea Plugin: http://jira.codehaus.org/browse/MIDEA Maven 2.x Install Plugin: http://jira.codehaus.org/browse/MINSTALL Maven 2.x Jar Plugin: http://jira.codehaus.org/browse/MJAR Maven 2.x Javadoc Plugin: http://jira.codehaus.org/browse/MJAVADOC Maven 2.x Plugin Plugin: http://jira.codehaus.org/browse/MPLUGIN Maven 2.x Pmd Plugin: http://jira.codehaus.org/browse/MPMD Maven 2.x Project Help Plugin: http://jira.codehaus.org/browse/MPH Maven 2.x Project Info Reports Plugin: http://jira.codehaus.org/browse/MPIR Maven 2.x Rar Plugin: http://jira.codehaus.org/browse/MRAR Maven 2.x Release Plugin: http://jira.codehaus.org/browse/MRELEASE Maven 2.x Resources Plugin: http://jira.codehaus.org/browse/MRESOURCES Maven 2.x Site Plugin: http://jira.codehaus.org/browse/MSITE Maven 2.x Sources Plugin: http://jira.codehaus.org/browse/MSOURCES Maven 2.x Surefire Plugin: http://jira.codehaus.org/browse/MSUREFIRE Maven 2.x Verifier Plugin: http://jira.codehaus.org/browse/MVERIFIER Maven 2.x War Plugin: http://jira.codehaus.org/browse/MWAR If there are any problems please let us know. Hope this makes tracking plug-ins easier for all of us. As an aside, if anyone is interested in JIRA automation there are several Java and Ruby-based tools here that I used to automate the creation of the projects above. http://svn.apache.org/viewcvs.cgi/maven/sandbox/issue/ I will also be using these tools to make some reports which will allow us to see at a glance what users want in terms of features, fixes and releases. -- jvz. Jason van Zyl jason at maven.org http://maven.apache.org believe nothing, no matter where you read it, or who has said it, not even if i have said it, unless it agrees with your own reason and your own common sense. -- Buddha - 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] -- jvz. Jason van Zyl jason at maven.org http://maven.apache.org Three people can keep a secret provided two of them are dead. -- Unknown - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MPXDOC-186) Mailing list links break if the address starts with http
Mailing list links break if the address starts with http Key: MPXDOC-186 URL: http://jira.codehaus.org/browse/MPXDOC-186 Project: maven-xdoc-plugin Type: Bug Versions: 1.9.2 Reporter: Ortwin Glück Our mailing lists have email addresses that start with http: e.g. [EMAIL PROTECTED] Our POM: http://svn.apache.org/repos/asf/jakarta/commons/proper/httpclient/trunk/project.xml The generated HTML: http://jakarta.apache.org/commons/httpclient/mail-lists.html As you can see the mailing list links are missing the mailto: prefix. The problem is on line 24 in the file plugin-resources/templates/mail-lists.xml: #if ($link.trim().startsWith(http)) which should be #if ($link.trim().startsWith(http://;)) or equivalent. -- 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] Moved: (MSOURCES-1) No resources directory is present in the generated jar
[ http://jira.codehaus.org/browse/MSOURCES-1?page=all ] Vincent Massol moved MNG-1748 to MSOURCES-1: Component: (was: maven-sources-plugin) Workflow: jira (was: Maven) Key: MSOURCES-1 (was: MNG-1748) Project: Maven 2.x Sources Plugin (was: Maven 2) No resources directory is present in the generated jar -- Key: MSOURCES-1 URL: http://jira.codehaus.org/browse/MSOURCES-1 Project: Maven 2.x Sources Plugin Type: Bug Reporter: Vincent Siveton Assignee: Vincent Siveton maven-source-plugin doesn't add resources directories -- 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] Moved: (MRESOURCES-2) No such file or directory when resource targetdirectory contains ../ and target/classes does not exist.
[ http://jira.codehaus.org/browse/MRESOURCES-2?page=all ]
Vincent Massol moved MNG-1345 to MRESOURCES-2:
--
Version: (was: 2.0)
Fix Version: (was: 2.0.1)
Component: (was: maven-resources-plugin)
Workflow: jira (was: Maven)
Key: MRESOURCES-2 (was: MNG-1345)
Project: Maven 2.x Resources Plugin (was: Maven 2)
No such file or directory when resource targetdirectory contains ../ and
target/classes does not exist.
---
Key: MRESOURCES-2
URL: http://jira.codehaus.org/browse/MRESOURCES-2
Project: Maven 2.x Resources Plugin
Type: Bug
Environment: Linux fails, Windows is fine.
Reporter: Mark Donszelmann
Assignee: John Casey
Priority: Minor
Attachments: MNG-1345-maven-resources-plugin.patch
Original Estimate: 10 minutes
Time Spent: 10 minutes
Remaining: 0 minutes
No such file or directory when resource targetdirectory contains ../ and
target/classes does not exist.
example:
resource
targetPath../generated-sources/filter/targetPath
filteringtrue/filtering
directory${basedir}/src/main/java/directory
includes
include**/*/include
/includes
/resource
since the targetdirectory is relative to target/classes (or whatever the
setting is to put the class files)
the plugin fails with a
No such file or directory:
target/classes/../generated-sources/filter/.
if target/classes does not exist.
On Windows it works fine, on Unix it fails.
Workaround: copy some resources to target/classes first, so that
target/classes exists.
--
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] Moved: (MRESOURCES-5) Proposal for improved resource filtering
[ http://jira.codehaus.org/browse/MRESOURCES-5?page=all ] Vincent Massol moved MNG-788 to MRESOURCES-5: - Version: (was: 2.0-beta-1) Fix Version: (was: 2.0-beta-2) Component: (was: maven-resources-plugin) (was: POM) Workflow: jira (was: Maven) Key: MRESOURCES-5 (was: MNG-788) Project: Maven 2.x Resources Plugin (was: Maven 2) Proposal for improved resource filtering Key: MRESOURCES-5 URL: http://jira.codehaus.org/browse/MRESOURCES-5 Project: Maven 2.x Resources Plugin Type: Improvement Reporter: Carsten Ziegeler Assignee: Brett Porter Original Estimate: 1 hour Time Spent: 2 hours Remaining: 0 minutes The current resource filtering has to be configured at the resource plugin configuration. This issue is about making resource filtering more user-friendly. There are the following requirements: 1) being able to split resources up into two groups: the filtered-on-copy group and the 'just-copy' group. 2) being able to specify multiple properties files / having a default file so users can override. Much like project.properties/build.properties in maven1. 3) being able to specify different filter properties using profiles The last item 3) is already working, so this is about 1) and 2). What about adding the following XML to the resource section of the POM: filtering filterIncludes/ filterExcludes/ /filtering And this configuration to the resource plugin configuration filterPropertyFiles filterPropertyFilesrc/build.properties.sample/filterPropertyFile filterPropertyFile failOnError=falsesrc/build.properties/filterPropertyFile /filterProptertyFiles /configuration From the following list a) and b) address item 1) while c) addresses item 2): a) As soon as a filtering section is available on a resource, it is filtered. b) Usually you have in a single resource directory resources that you want to filter and resources that shouldn't be filtered like images etc. One solution to address this is to specify two resource sets in the POM with different include and exlucde filters and turn on/off filtering accordingly. I think a more elegant way is to say, this is my resource set and filter only these files in this resource set. That's why I added the filterIncludes and filterExcludes section. We can also define default filterExcludes like images etc. On the one hand this is imho a more natural way of defining filtering and on the other hand, this should increase performance. The resource tree has only to be scanned once. With two resources, the tree is scanned twice. Especially if you have big resource trees (e.g. for webapps) this should increase performance noticeably. c) You can specify several property files at the resource plugin. This files are read in the order of appearance and if a token is defined twice, the last definition read wins. In addition you can set the failOnError flag on a property file, so if this file is missing no error occurs. I could imagine these optional additions: 4) Defining the tokens in the pom so the plugin could check which ones are missing and you have an overview of all the configuration settings used in all the resource files (the latter being more important). So, we could add this XML to the filtering section in the POM: filterTokens tokentokenname/token tokenanothertokenname/token /filtertokens If the section is missing all tokens are replaced by default. 5) Define properties directly without a property file. We could add this to the resource plugin configuration: filterProperties filterProperty nameaToken/name valuesomeValue/value /filterProperty ... /filterProperties -- 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] Moved: (MRESOURCES-6) When filtering, properties defined in projectproperties should be allowed as well.
[ http://jira.codehaus.org/browse/MRESOURCES-6?page=all ] Vincent Massol moved MNG-1194 to MRESOURCES-6: -- Fix Version: (was: 2.0.1) Component: (was: maven-resources-plugin) Workflow: jira (was: Maven) Key: MRESOURCES-6 (was: MNG-1194) Project: Maven 2.x Resources Plugin (was: Maven 2) When filtering, properties defined in projectproperties should be allowed as well. -- Key: MRESOURCES-6 URL: http://jira.codehaus.org/browse/MRESOURCES-6 Project: Maven 2.x Resources Plugin Type: Improvement Reporter: David Jackman It would be nice to be able to reference custom properties defined in the properties section of pom.xml in resources for filtering. -- 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] Moved: (MRAR-1) maven-rar-plugin can not install the generated rar file to the local repository
[ http://jira.codehaus.org/browse/MRAR-1?page=all ] Jason van Zyl moved MNG-1681 to MRAR-1: --- Fix Version: (was: 2.0.1) Component: (was: maven-rar-plugin) Workflow: jira (was: Maven) Key: MRAR-1 (was: MNG-1681) Project: Maven 2.x Rar Plugin (was: Maven 2) maven-rar-plugin can not install the generated rar file to the local repository --- Key: MRAR-1 URL: http://jira.codehaus.org/browse/MRAR-1 Project: Maven 2.x Rar Plugin Type: Bug Environment: Win XP SP2, JDK 5, M2 2.0.1-SNAPSHOT Reporter: Henry S. Isidro Assignee: Edwin Punzalan Attachments: maven-rar-plugin.diff The build stops and generates an Access Denied error because it cannot install the correct file to the local repository. Looking at the console output, these lines are present: [INFO] [install:install] [INFO] Installing C:\myrar-project\target\classes to C:\Documents and Settings\user1\.m2\repository\myrar-project\myrar-project\1.0-SNAPSHOT\myrar-project-1.0-SNAPSHOT.rar So it seems that the plugin is trying to copy the target\classes to the local repository and renaming it as the rar file. I've attached a DIFF file with some changes that I think will make the plugin work. -- 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: (MDEPLOY-13) Error while deploying when using scpexe protocol with non-default scp/ssh executables
[ http://jira.codehaus.org/browse/MDEPLOY-13?page=comments#action_53814 ] mike perham commented on MDEPLOY-13: Brett, can you give more specifics about the code that needs to be fixed? We are seeing this problem also when trying to use scpexe and I would like to fix it but I don't know where the relevant buggy code is. Error while deploying when using scpexe protocol with non-default scp/ssh executables - Key: MDEPLOY-13 URL: http://jira.codehaus.org/browse/MDEPLOY-13 Project: Maven 2.x Deploy Plugin Type: Bug Reporter: Vincent Massol First I have not been able to use the scp protocol as there's a bug with jsch. This is a known bug as I was told on IRC. Thus I have tried to use the scpexe protocol: distributionManagement repository idcargo/id nameCargo's private repository/name !-- Note: We're using scpexe protocol instead of scp because jsch has an issue (already reported) that makes it fail. Once it works switch back to scp protocol. -- urlscpexe://beaver.codehaus.org/home/projects/cargo/dist2/url /repository /distributionManagement In my settings.xml I have: servers server idcargo/id usernamevmassol/username privateKey.../privateKey filePermissions664/filePermissions directoryPermissions775/directoryPermissions configuration sshExecutabletortoiseplink/sshExecutable scpExecutablepscp/scpExecutable /configuration /server /servers However when I do a deploy I get the following: C:\dev\cargo\trunkmvn -X -N deploy [...] [INFO] [deploy:deploy] [INFO] Retrieving previous build number from cargo Executing command: scp -i C:\DOCUME~1\VINCEN~1\MYDOCU~1\.ssh\vmassol.ssh2.private.putty -o BatchMode yes [EMAIL PROTECTED] .org:/home/projects/cargo/dist2/org/codehaus/cargo/cargo/0.7-SNAPSHOT/maven-metadata.xml maven-metadata-cargo.xml.tmp [WARNING] repository metadata for: 'snapshot org.codehaus.cargo:cargo:0.7-SNAPSHOT' could not be retrieved from repository: cargo due to an error: Exit code: 1 - 'scp' is not recognized as an internal or external command, operable program or batch file. [INFO] Repository 'cargo' will be blacklisted [DEBUG] Exception org.apache.maven.wagon.TransferFailedException: Exit code: 1 - 'scp' is not recognized as an internal or external command, operable program or batch file. at org.apache.maven.wagon.providers.sshext.ScpExternalWagon.executeScpCommand(ScpExternalWagon.java:294) at org.apache.maven.wagon.providers.sshext.ScpExternalWagon.get(ScpExternalWagon.java:375) at org.apache.maven.artifact.manager.DefaultWagonManager.getRemoteFile(DefaultWagonManager.java:367) at org.apache.maven.artifact.manager.DefaultWagonManager.getArtifactMetadata(DefaultWagonManager.java:295) at org.apache.maven.artifact.repository.metadata.DefaultRepositoryMetadataManager.resolveAlways(DefaultRepositoryMetadataM anager.java:356) at org.apache.maven.artifact.repository.metadata.DefaultRepositoryMetadataManager.resolveAlways(DefaultRepositoryMetadataM anager.java:310) at org.apache.maven.artifact.transform.SnapshotTransformation.resolveLatestSnapshotBuildNumber(SnapshotTransformation.java :158) at org.apache.maven.artifact.transform.SnapshotTransformation.transformForDeployment(SnapshotTransformation.java:97) at org.apache.maven.artifact.transform.DefaultArtifactTransformationManager.transformForDeployment(DefaultArtifactTransfor mationManager.java:61) at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:68) at org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:137) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:519) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:469) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:448) 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:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at
[jira] Assigned: (SCM-114) Clientspec naming
[ http://jira.codehaus.org/browse/SCM-114?page=all ]
mike perham reassigned SCM-114:
---
Assign To: mike perham
Clientspec naming
-
Key: SCM-114
URL: http://jira.codehaus.org/browse/SCM-114
Project: Maven SCM
Type: Improvement
Components: maven-scm-provider-perforce
Versions: 1.0-beta-3
Reporter: mike perham
Assignee: mike perham
Fix For: 1.0-beta-3
Several people have expressed more than a passing interest in how the
Perforce clientspec is named by Maven SCM. The name needs to be
autogenerated and unique for each Continuum project build. Currently I am
thinking something like:
${project}-${user}-${hostname}-mavenscm
Emmannuel, does the SCM subsystem have access to the name of the project
being built? If not, I can just use the name of the last directory in the
SCM URL for the name of the project: //depot/projects/foobar would mean that
${project} = foobar.
And just head off the inevitable question: you cannot set P4CLIENT for this
because Continuum may build several different projects and they each need a
unique clientspec.
--
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] Assigned: (SCM-119) Perforce provider should only append /... to view if necessary
[ http://jira.codehaus.org/browse/SCM-119?page=all ] mike perham reassigned SCM-119: --- Assign To: mike perham Perforce provider should only append /... to view if necessary Key: SCM-119 URL: http://jira.codehaus.org/browse/SCM-119 Project: Maven SCM Type: Bug Components: maven-scm-provider-perforce Reporter: Neil Padgen Assignee: mike perham Attachments: patch When creating a clientspec, maven-scm-provider-perforce currently appends /... to the SCM URL regardless of what is already there. But other plugins (such as the changelog-report-plugin, file-activity-report-plugin and developer-activity-report-plugin) require the SCM URL to end in /... to be able to produce output. Fix: when creating the clientspec, only append /... if it is not already there. (I'm not sure if p4 filelog is invoked by this component or those other report plugins.) *Untested* patch attached. -- 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] Assigned: (SCM-113) Support persistent and transient clientspecs
[ http://jira.codehaus.org/browse/SCM-113?page=all ] mike perham reassigned SCM-113: --- Assign To: mike perham Support persistent and transient clientspecs Key: SCM-113 URL: http://jira.codehaus.org/browse/SCM-113 Project: Maven SCM Type: New Feature Components: maven-scm-provider-perforce Versions: 1.0-beta-3 Reporter: mike perham Assignee: mike perham Fix For: 1.0-beta-3 Continuum needs a persistent clientspec because it needs to update a project's source code and build it once an hour. On larger projects a complete resync might take 10-20 minutes so it is necessary to keep a clientspec around for that Continuum project build so syncs only take a few seconds. However, the Maven Release plugin may need to be used by tens or even hundreds of developers to release any number of small modules. Currently this would mean lots of clientspecs being created for the release checkout which are reused very infrequently. Here I would prefer to create the clientspec, do the checkout, build and then delete the clientspec. This is what I term a transient clientspec. The Perforce plugin would need to default to one mode and support some sort of hint which tells it which mode to operate in. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MEV-267) org.springframework is missing *.pom files in ibiblio
[ http://jira.codehaus.org/browse/MEV-267?page=all ] Carlos Sanchez closed MEV-267: -- Assign To: Carlos Sanchez Resolution: Fixed Uploaded to org.springframework org.springframework is missing *.pom files in ibiblio - Key: MEV-267 URL: http://jira.codehaus.org/browse/MEV-267 Project: Maven Evangelism Type: Bug Components: Invalid POM Reporter: Matt Raible Assignee: Carlos Sanchez I like to follow best practices, and it appears that you (the Maven Team) would prefer we use org.springframework for Spring's groupId, rather than springframework. If I change my pom.xml setting to use org.springframework for the groupId (for spring and spring-mock (v 1.2.6)), I get the following warning: [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. Downloading: http://repo1.maven.org/maven2/org/springframework/spring-mock/1.2.6 /spring-mock-1.2.6.pom [WARNING] Unable to get resource from repository central (http://repo1.maven.org /maven2) Downloading: http://repo1.maven.org/maven2/org/springframework/spring/1.2.6/spri ng-1.2.6.pom [WARNING] Unable to get resource from repository central (http://repo1.maven.org /maven2) If I change my groupId to be springframework, I don't get any warnings. It seems like org.springframework is not as up-to-date as springframework, especially since its directories are missing *.pom files. -- 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: (MAVEN-1345) Upgrade to dom4j 1.4
[ http://jira.codehaus.org/browse/MAVEN-1345?page=comments#action_53816 ] Elliotte Rusty Harold commented on MAVEN-1345: -- Please do not use dom4j 1.4 or earlier. It has some license issues that weren't corrected until about 1.6. I have to check on the exact version, but I'm pretty sure 1.4 is too early to contain the fix. OK. I checked. 1.5.2 is the first version that's kosher. You really shouldn't use anything earlier. Upgrade to dom4j 1.4 Key: MAVEN-1345 URL: http://jira.codehaus.org/browse/MAVEN-1345 Project: Maven Type: Bug Components: core Versions: 1.0-rc3 Reporter: Paul Libbrecht Assignee: Brett Porter Priority: Critical Fix For: 1.1-beta-1 Currently, Maven relies on dom4j beta 8. This is bad in many respects, the worst being that the XML output, for example provided by Jelly XML plugin, has wrong xmlns attributes. At least the 1.5 betas of dom4j all fix this, they also fix the html output which was, otherwise, inserting random (kind-of) spaces in the text. -- 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]
Problems with JIRA Plug-in Projects
Hi, There are a few issues with the movement of the issues. So I'll list them and then we need to decide what to do: 1) I selected the retain option which I assumed would create the versions in new projects, but the affects/fix version information appears to have been lost. 2) I thought I selected the option I thought would map Bug/Improvement/etc into their equivalents in the new projects but it appears that all the types went in as Bugs. These are the bigs ones. So versions need to be recreated and the workflow needs to be set as Vincent made a special workflow for us. These I can automate. I think if we identify the leads then each of the plugin projects can be cleaned up quickly and if users take a peek at issues they raised it probably won't take long. But we can always restore a backup too. I would prefer not to do that. I think we can clean up the issues in the plug-in projects relatively quickly. Any thoughts? -- jvz. Jason van Zyl jason at maven.org http://maven.apache.org In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MCLOVER-3) classpath error
[ http://jira.codehaus.org/browse/MCLOVER-3?page=all ] Vincent Massol updated MCLOVER-3: - Version: 2.0-alpha-1 Fix Version: 2.0 set again versions after the jira move from Maven 2 to Maven 2.x Clover Plugin classpath error --- Key: MCLOVER-3 URL: http://jira.codehaus.org/browse/MCLOVER-3 Project: Maven 2.x Clover Plugin Type: Bug Versions: 2.0-alpha-1 Environment: Windows XP, JDK 5.0 update 6, Maven 2.0, maven-clover-plugin-2.0-alpha-1 Reporter: YueNi Fix For: 2.0 I used maven clover plugin to generate test report but got FileNotFoundException. I employ spring in my project, so I use ClassPathXmlApplicationContext in my JUnit test case to get the application context. When the clover:report goal is executed, I got the error message Caused by: java.io.FileNotFoundException: class path resource [net/sf/psm4j/applicationContext.xml] cannot be opened because it does not exist(Actually, the file exists in the right path) . When I executed the mvn test goal, the unit test can be run without exception. In the same time, I can also run the test case in Eclipse without exception(The Eclipse .classpath file is generated by maven eclipse:eclipse goal). Therefore, I think there's something wrong in the maven clover plugin dealing with the classpath. -- 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: (MCLOVER-4) clover:check fails, even though coverage is 100%
[ http://jira.codehaus.org/browse/MCLOVER-4?page=all ] Vincent Massol updated MCLOVER-4: - Version: 2.0-alpha-1 Fix Version: 2.0 set again versions after the jira move from Maven 2 to Maven 2.x Clover Plugin clover:check fails, even though coverage is 100% Key: MCLOVER-4 URL: http://jira.codehaus.org/browse/MCLOVER-4 Project: Maven 2.x Clover Plugin Type: Bug Versions: 2.0-alpha-1 Reporter: Brett Porter Assignee: Vincent Massol Fix For: 2.0 this is occurring on maven-clover-plugin-samples-simple -- 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] Reopened: (MCLOVER-4) clover:check fails, even though coverage is 100%
[ http://jira.codehaus.org/browse/MCLOVER-4?page=all ] Vincent Massol reopened MCLOVER-4: -- Reopening to set again versions after the jira move from Maven 2 to Maven 2.x Clover Plugin clover:check fails, even though coverage is 100% Key: MCLOVER-4 URL: http://jira.codehaus.org/browse/MCLOVER-4 Project: Maven 2.x Clover Plugin Type: Bug Versions: 2.0-alpha-1 Reporter: Brett Porter Assignee: Vincent Massol Fix For: 2.0 this is occurring on maven-clover-plugin-samples-simple -- 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] Closed: (MCLOVER-4) clover:check fails, even though coverage is 100%
[ http://jira.codehaus.org/browse/MCLOVER-4?page=all ] Vincent Massol closed MCLOVER-4: Resolution: Fixed Fixed again versions after the jira move from Maven 2 to Maven 2.x Clover Plugin clover:check fails, even though coverage is 100% Key: MCLOVER-4 URL: http://jira.codehaus.org/browse/MCLOVER-4 Project: Maven 2.x Clover Plugin Type: Bug Versions: 2.0-alpha-1 Reporter: Brett Porter Assignee: Vincent Massol Fix For: 2.0 this is occurring on maven-clover-plugin-samples-simple -- 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: (MCLOVER-1) clover has to be declared as project dependency to run clover:report
[ http://jira.codehaus.org/browse/MCLOVER-1?page=all ] Vincent Massol updated MCLOVER-1: - Version: 2.0-alpha-1 Fix Version: 2.0 set again versions after the jira move from Maven 2 to Maven 2.x Clover Plugin clover has to be declared as project dependency to run clover:report Key: MCLOVER-1 URL: http://jira.codehaus.org/browse/MCLOVER-1 Project: Maven 2.x Clover Plugin Type: Bug Versions: 2.0-alpha-1 Reporter: Daniel Schömer Assignee: Brett Porter Fix For: 2.0 Original Estimate: 1 hour Time Spent: 30 minutes Remaining: 0 minutes If I try to run m2 clover:report on one of my projects, the goal fails because the compiler can't find the com_cenqua_clover package. If I declare clover as compile-time dependency, the goal creates a clover report as expected. I think the clover:report goal should implicit include clover to the classpath. # m2 clover:report [INFO] Searching repository for plugin with prefix: 'clover'. [INFO] [INFO] Building clOptions [INFO]task-segment: [clover:report] [INFO] [INFO] [clover:instrument] [INFO] [resources:resources] [INFO] [compiler:compile] Compiling 6 source files to /home/daniel/workspace/option/target/clover/classes [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Reason: Compilation failure [INFO] [INFO] /home/daniel/workspace/option/target/clover/src/schoemer/cli/Command.java:[24,117] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/cli/Option.java:[74,115] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/util/LispToStringStyle.java:[14,104] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/util/ReflectionToStringBuilder2.java:[20,125] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/cli/Parser.java:[14,95] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/util/Utils.java:[18,76] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/cli/Command.java:[24,181] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/cli/Command.java:[24,533] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/cli/Command.java:[24,599] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/cli/Option.java:[74,179] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/cli/Option.java:[74,531] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/cli/Option.java:[74,597] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/util/LispToStringStyle.java:[14,168] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/util/LispToStringStyle.java:[14,520] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/util/LispToStringStyle.java:[14,586] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/util/ReflectionToStringBuilder2.java:[20,189] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/util/ReflectionToStringBuilder2.java:[20,541] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/util/ReflectionToStringBuilder2.java:[20,607] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/cli/Parser.java:[14,159] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/cli/Parser.java:[14,511] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/cli/Parser.java:[14,577] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/util/Utils.java:[18,140] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/util/Utils.java:[18,492] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/util/Utils.java:[18,558]
[jira] Reopened: (MCLOVER-1) clover has to be declared as project dependency to run clover:report
[ http://jira.codehaus.org/browse/MCLOVER-1?page=all ] Vincent Massol reopened MCLOVER-1: -- Reopen to set again versions after the jira move from Maven 2 to Maven 2.x Clover Plugin clover has to be declared as project dependency to run clover:report Key: MCLOVER-1 URL: http://jira.codehaus.org/browse/MCLOVER-1 Project: Maven 2.x Clover Plugin Type: Bug Versions: 2.0-alpha-1 Reporter: Daniel Schömer Assignee: Brett Porter Fix For: 2.0 Original Estimate: 1 hour Time Spent: 30 minutes Remaining: 0 minutes If I try to run m2 clover:report on one of my projects, the goal fails because the compiler can't find the com_cenqua_clover package. If I declare clover as compile-time dependency, the goal creates a clover report as expected. I think the clover:report goal should implicit include clover to the classpath. # m2 clover:report [INFO] Searching repository for plugin with prefix: 'clover'. [INFO] [INFO] Building clOptions [INFO]task-segment: [clover:report] [INFO] [INFO] [clover:instrument] [INFO] [resources:resources] [INFO] [compiler:compile] Compiling 6 source files to /home/daniel/workspace/option/target/clover/classes [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Reason: Compilation failure [INFO] [INFO] /home/daniel/workspace/option/target/clover/src/schoemer/cli/Command.java:[24,117] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/cli/Option.java:[74,115] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/util/LispToStringStyle.java:[14,104] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/util/ReflectionToStringBuilder2.java:[20,125] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/cli/Parser.java:[14,95] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/util/Utils.java:[18,76] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/cli/Command.java:[24,181] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/cli/Command.java:[24,533] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/cli/Command.java:[24,599] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/cli/Option.java:[74,179] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/cli/Option.java:[74,531] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/cli/Option.java:[74,597] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/util/LispToStringStyle.java:[14,168] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/util/LispToStringStyle.java:[14,520] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/util/LispToStringStyle.java:[14,586] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/util/ReflectionToStringBuilder2.java:[20,189] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/util/ReflectionToStringBuilder2.java:[20,541] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/util/ReflectionToStringBuilder2.java:[20,607] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/cli/Parser.java:[14,159] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/cli/Parser.java:[14,511] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/cli/Parser.java:[14,577] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/util/Utils.java:[18,140] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/util/Utils.java:[18,492] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/util/Utils.java:[18,558] package com_cenqua_clover does
[jira] Closed: (MCLOVER-1) clover has to be declared as project dependency to run clover:report
[ http://jira.codehaus.org/browse/MCLOVER-1?page=all ] Vincent Massol closed MCLOVER-1: Resolution: Fixed Fixed again versions after the jira move from Maven 2 to Maven 2.x Clover Plugin clover has to be declared as project dependency to run clover:report Key: MCLOVER-1 URL: http://jira.codehaus.org/browse/MCLOVER-1 Project: Maven 2.x Clover Plugin Type: Bug Versions: 2.0-alpha-1 Reporter: Daniel Schömer Assignee: Brett Porter Fix For: 2.0 Original Estimate: 1 hour Time Spent: 30 minutes Remaining: 0 minutes If I try to run m2 clover:report on one of my projects, the goal fails because the compiler can't find the com_cenqua_clover package. If I declare clover as compile-time dependency, the goal creates a clover report as expected. I think the clover:report goal should implicit include clover to the classpath. # m2 clover:report [INFO] Searching repository for plugin with prefix: 'clover'. [INFO] [INFO] Building clOptions [INFO]task-segment: [clover:report] [INFO] [INFO] [clover:instrument] [INFO] [resources:resources] [INFO] [compiler:compile] Compiling 6 source files to /home/daniel/workspace/option/target/clover/classes [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Reason: Compilation failure [INFO] [INFO] /home/daniel/workspace/option/target/clover/src/schoemer/cli/Command.java:[24,117] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/cli/Option.java:[74,115] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/util/LispToStringStyle.java:[14,104] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/util/ReflectionToStringBuilder2.java:[20,125] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/cli/Parser.java:[14,95] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/util/Utils.java:[18,76] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/cli/Command.java:[24,181] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/cli/Command.java:[24,533] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/cli/Command.java:[24,599] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/cli/Option.java:[74,179] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/cli/Option.java:[74,531] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/cli/Option.java:[74,597] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/util/LispToStringStyle.java:[14,168] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/util/LispToStringStyle.java:[14,520] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/util/LispToStringStyle.java:[14,586] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/util/ReflectionToStringBuilder2.java:[20,189] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/util/ReflectionToStringBuilder2.java:[20,541] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/util/ReflectionToStringBuilder2.java:[20,607] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/cli/Parser.java:[14,159] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/cli/Parser.java:[14,511] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/cli/Parser.java:[14,577] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/util/Utils.java:[18,140] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/util/Utils.java:[18,492] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/util/Utils.java:[18,558] package
[jira] Created: (MNGECLIPSE-15) Output folders are not set correctly by 'Update Sources' action
Output folders are not set correctly by 'Update Sources' action --- Key: MNGECLIPSE-15 URL: http://jira.codehaus.org/browse/MNGECLIPSE-15 Project: Maven 2.x Plug-in for Eclipse Type: Bug Reporter: YOKOTA Takehiko Assigned to: Eugene Kuleshov Although source folders on build path are updated correctly by 'Update Sources' action, output folders are not updated at all. For example, it is expected that output folder for 'src/test/java' and 'src/test/resources' is set to 'target/test-classes', but not set. -- 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] Reopened: (MCLOVER-6) change outputDirectory in reports to default to ${project.reporting.outputDirectory}
[ http://jira.codehaus.org/browse/MCLOVER-6?page=all ]
Vincent Massol reopened MCLOVER-6:
--
Reopen to set again versions after the jira move from Maven 2 to Maven 2.x
Clover Plugin
change outputDirectory in reports to default to
${project.reporting.outputDirectory}
Key: MCLOVER-6
URL: http://jira.codehaus.org/browse/MCLOVER-6
Project: Maven 2.x Clover Plugin
Type: Bug
Reporter: Brett Porter
Assignee: Johnny R. Ruiz III
Attachments: MNG-1034-maven-plugins.patch, MNG-1034-maven-pmd-plugin.patch
must be done after beta-3 release
--
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: (MCLOVER-6) change outputDirectory in reports to default to ${project.reporting.outputDirectory}
[ http://jira.codehaus.org/browse/MCLOVER-6?page=all ]
Vincent Massol updated MCLOVER-6:
-
Version: 2.0-alpha-1
Fix Version: 2.0
type: Improvement (was: Bug)
set again versions after the jira move from Maven 2 to Maven 2.x Clover
Plugin
change outputDirectory in reports to default to
${project.reporting.outputDirectory}
Key: MCLOVER-6
URL: http://jira.codehaus.org/browse/MCLOVER-6
Project: Maven 2.x Clover Plugin
Type: Improvement
Versions: 2.0-alpha-1
Reporter: Brett Porter
Assignee: Johnny R. Ruiz III
Fix For: 2.0
Attachments: MNG-1034-maven-plugins.patch, MNG-1034-maven-pmd-plugin.patch
must be done after beta-3 release
--
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] Closed: (MCLOVER-6) change outputDirectory in reports to default to ${project.reporting.outputDirectory}
[ http://jira.codehaus.org/browse/MCLOVER-6?page=all ]
Vincent Massol closed MCLOVER-6:
Resolution: Fixed
Fixed again versions after the jira move from Maven 2 to Maven 2.x Clover
Plugin
change outputDirectory in reports to default to
${project.reporting.outputDirectory}
Key: MCLOVER-6
URL: http://jira.codehaus.org/browse/MCLOVER-6
Project: Maven 2.x Clover Plugin
Type: Improvement
Versions: 2.0-alpha-1
Reporter: Brett Porter
Assignee: Johnny R. Ruiz III
Fix For: 2.0
Attachments: MNG-1034-maven-plugins.patch, MNG-1034-maven-pmd-plugin.patch
must be done after beta-3 release
--
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]
RE: Problems with JIRA Plug-in Projects
-Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: mardi 20 décembre 2005 16:37 To: Maven Developers List Subject: Problems with JIRA Plug-in Projects Hi, There are a few issues with the movement of the issues. So I'll list them and then we need to decide what to do: 1) I selected the retain option which I assumed would create the versions in new projects, but the affects/fix version information appears to have been lost. 2) I thought I selected the option I thought would map Bug/Improvement/etc into their equivalents in the new projects but it appears that all the types went in as Bugs. These are the bigs ones. So versions need to be recreated and the workflow needs to be set as Vincent made a special workflow for us. These I can automate. I think if we identify the leads then each of the plugin projects can be cleaned up quickly and if users take a peek at issues they raised it probably won't take long. But we can always restore a backup too. I would prefer not to do that. I think we can clean up the issues in the plug-in projects relatively quickly. I'm working on restoring the clover plugin as I write. I think we can fix things by hands rather than do a dangerous restore (we won't know how many new issues were added after the last backup point). Thanks -Vincent In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society - 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]
[jira] Commented: (MNGECLIPSE-15) Output folders are not set correctly by 'Update Sources' action
[ http://jira.codehaus.org/browse/MNGECLIPSE-15?page=comments#action_53828 ] Eugene Kuleshov commented on MNGECLIPSE-15: --- Actually it is trickier then it seems. You can't really use the same output folders between Eclipse compiler and any external tools, including Maven build. So, it is generally a bad idea to use the same output folders. See discussion about this at https://bugs.eclipse.org/bugs/show_bug.cgi?id=99497 Output folders are not set correctly by 'Update Sources' action --- Key: MNGECLIPSE-15 URL: http://jira.codehaus.org/browse/MNGECLIPSE-15 Project: Maven 2.x Plug-in for Eclipse Type: Bug Reporter: YOKOTA Takehiko Assignee: Eugene Kuleshov Although source folders on build path are updated correctly by 'Update Sources' action, output folders are not updated at all. For example, it is expected that output folder for 'src/test/java' and 'src/test/resources' is set to 'target/test-classes', but not set. -- 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: (MCLOVER-2) clover breaks when encountering assert statements.
[ http://jira.codehaus.org/browse/MCLOVER-2?page=all ] Vincent Massol updated MCLOVER-2: - Version: 2.0-alpha-1 Fix Version: 2.0 set again versions after the jira move from Maven 2 to Maven 2.x Clover Plugin clover breaks when encountering assert statements. -- Key: MCLOVER-2 URL: http://jira.codehaus.org/browse/MCLOVER-2 Project: Maven 2.x Clover Plugin Type: Bug Versions: 2.0-alpha-1 Environment: any Reporter: Dave Sag Assignee: Vincent Massol Fix For: 2.0 Attachments: example_pom_from_davesag.xml, maven-clover-plugin-samples-20051024.zip, maven-clover-plugin-samples_breaks_DS.zip the clover plugin is breaking on the line assert result != null : the result should not be null; saying [INFO] Reason: Clover has failed to instrument the source files i can only assume that this is because clover does not understand the assert, or is assuming java 1.3? eitherway it's no use to me until this is fixed. -- 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] Reopened: (MCLOVER-2) clover breaks when encountering assert statements.
[ http://jira.codehaus.org/browse/MCLOVER-2?page=all ] Vincent Massol reopened MCLOVER-2: -- Reopen to set again versions after the jira move from Maven 2 to Maven 2.x Clover Plugin clover breaks when encountering assert statements. -- Key: MCLOVER-2 URL: http://jira.codehaus.org/browse/MCLOVER-2 Project: Maven 2.x Clover Plugin Type: Bug Versions: 2.0-alpha-1 Environment: any Reporter: Dave Sag Assignee: Vincent Massol Fix For: 2.0 Attachments: example_pom_from_davesag.xml, maven-clover-plugin-samples-20051024.zip, maven-clover-plugin-samples_breaks_DS.zip the clover plugin is breaking on the line assert result != null : the result should not be null; saying [INFO] Reason: Clover has failed to instrument the source files i can only assume that this is because clover does not understand the assert, or is assuming java 1.3? eitherway it's no use to me until this is fixed. -- 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] Closed: (MCLOVER-2) clover breaks when encountering assert statements.
[ http://jira.codehaus.org/browse/MCLOVER-2?page=all ] Vincent Massol closed MCLOVER-2: Resolution: Fixed Fixed again versions after the jira move from Maven 2 to Maven 2.x Clover Plugin clover breaks when encountering assert statements. -- Key: MCLOVER-2 URL: http://jira.codehaus.org/browse/MCLOVER-2 Project: Maven 2.x Clover Plugin Type: Bug Versions: 2.0-alpha-1 Environment: any Reporter: Dave Sag Assignee: Vincent Massol Fix For: 2.0 Attachments: example_pom_from_davesag.xml, maven-clover-plugin-samples-20051024.zip, maven-clover-plugin-samples_breaks_DS.zip the clover plugin is breaking on the line assert result != null : the result should not be null; saying [INFO] Reason: Clover has failed to instrument the source files i can only assume that this is because clover does not understand the assert, or is assuming java 1.3? eitherway it's no use to me until this is fixed. -- 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: (MCLOVER-7) mvn clover:report generates errors in tests that execute properly in mvn test
[ http://jira.codehaus.org/browse/MCLOVER-7?page=all ]
Vincent Massol updated MCLOVER-7:
-
Version: 2.0-alpha-1
Fix Version: 2.0
set again versions after the jira move from Maven 2 to Maven 2.x Clover
Plugin
mvn clover:report generates errors in tests that execute properly in mvn
test
-
Key: MCLOVER-7
URL: http://jira.codehaus.org/browse/MCLOVER-7
Project: Maven 2.x Clover Plugin
Type: Bug
Versions: 2.0-alpha-1
Reporter: Chris Gray
Fix For: 2.0
Some of our java code opens data files, which have been stored in the
${PROJECT_ROOT} directory. When we execute mvn test, the code compiles
fine, and all unit tests pass. However, when we add the clover plugin to the
pom.xml file, all tests fail during the clover run. As far as I can tell, it
looks like clover when executes the tests, they look for the data files in
the ${PROJECT_ROOT}/target/clover directory instead of the ${PROJECT_ROOT}
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] Updated: (MCLOVER-5) Clover fails on multi-module builds
[ http://jira.codehaus.org/browse/MCLOVER-5?page=all ] Vincent Massol updated MCLOVER-5: - Version: 2.0-alpha-1 Fix Version: 2.0 set again versions after the jira move from Maven 2 to Maven 2.x Clover Plugin Clover fails on multi-module builds --- Key: MCLOVER-5 URL: http://jira.codehaus.org/browse/MCLOVER-5 Project: Maven 2.x Clover Plugin Type: Bug Versions: 2.0-alpha-1 Reporter: mike perham Fix For: 2.0 I added clover to my reports plugins in my top-level POM and then ran mvn site:site at the top. As expected, it recurses into the child modules and the first module's build works but the second fails with the following error: [INFO] Error configuring: org.apache.maven.plugins:maven-clover-plugin. Reason: ERROR: Cannot override read-only parameter: project in goal: clover:instrument -- 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: (MCLOVER-12) clover should generate a placeholder if project do not have test cases
[ http://jira.codehaus.org/browse/MCLOVER-12?page=all ] Vincent Massol updated MCLOVER-12: -- Version: 2.0-alpha-1 Fix Version: 2.0 set again versions after the jira move from Maven 2 to Maven 2.x Clover Plugin clover should generate a placeholder if project do not have test cases -- Key: MCLOVER-12 URL: http://jira.codehaus.org/browse/MCLOVER-12 Project: Maven 2.x Clover Plugin Type: Bug Versions: 2.0-alpha-1 Environment: Maven 2.0, maven.clover-plugin 2.0-alpha-1 Reporter: Anuerin Diaz Fix For: 2.0 For project that have no test cases (like parent projects of packaging type pom), the generated site contains a Clover link under the Project Reports menu but since coverage testing results was not generated for this project then the link points to a non-existent page. In cases like this, it would be nice to have a placeholder page (one saying the tests were not applicable), or the actual clover link removed so that the users will not click onto a missing link. -- 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] Reopened: (MCLOVER-8) Clover default target percentage too high - should be 0%
[ http://jira.codehaus.org/browse/MCLOVER-8?page=all ] Vincent Massol reopened MCLOVER-8: -- Reopen to set again versions after the jira move from Maven 2 to Maven 2.x Clover Plugin Clover default target percentage too high - should be 0% Key: MCLOVER-8 URL: http://jira.codehaus.org/browse/MCLOVER-8 Project: Maven 2.x Clover Plugin Type: Bug Versions: 2.0-alpha-1 Reporter: Mark Kuzmycz Assignee: Vincent Massol Priority: Trivial Fix For: 2.0 The target percentage attribute is a good idea. However, it should be treated as optional as most projects will want to build irrespective of the target. This is especially true when you run the site goal. In which case you want the execution to complete (irrespective of clover restrictions) so that you can communicate the results to the developers. Can we please have the default value set to 0% -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MCLOVER-8) Clover default target percentage too high - should be 0%
[ http://jira.codehaus.org/browse/MCLOVER-8?page=all ] Vincent Massol updated MCLOVER-8: - Version: 2.0-alpha-1 Fix Version: 2.0 set again versions after the jira move from Maven 2 to Maven 2.x Clover Plugin Clover default target percentage too high - should be 0% Key: MCLOVER-8 URL: http://jira.codehaus.org/browse/MCLOVER-8 Project: Maven 2.x Clover Plugin Type: Bug Versions: 2.0-alpha-1 Reporter: Mark Kuzmycz Assignee: Vincent Massol Priority: Trivial Fix For: 2.0 The target percentage attribute is a good idea. However, it should be treated as optional as most projects will want to build irrespective of the target. This is especially true when you run the site goal. In which case you want the execution to complete (irrespective of clover restrictions) so that you can communicate the results to the developers. Can we please have the default value set to 0% -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MCLOVER-8) Clover default target percentage too high - should be 0%
[ http://jira.codehaus.org/browse/MCLOVER-8?page=all ] Vincent Massol closed MCLOVER-8: Resolution: Won't Fix Fixed again versions after the jira move from Maven 2 to Maven 2.x Clover Plugin Clover default target percentage too high - should be 0% Key: MCLOVER-8 URL: http://jira.codehaus.org/browse/MCLOVER-8 Project: Maven 2.x Clover Plugin Type: Bug Versions: 2.0-alpha-1 Reporter: Mark Kuzmycz Assignee: Vincent Massol Priority: Trivial Fix For: 2.0 The target percentage attribute is a good idea. However, it should be treated as optional as most projects will want to build irrespective of the target. This is especially true when you run the site goal. In which case you want the execution to complete (irrespective of clover restrictions) so that you can communicate the results to the developers. Can we please have the default value set to 0% -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (MCLOVER-9) Locale problem in Clover plugin
[ http://jira.codehaus.org/browse/MCLOVER-9?page=all ] Vincent Massol reopened MCLOVER-9: -- Reopen to set again versions after the jira move from Maven 2 to Maven 2.x Clover Plugin Locale problem in Clover plugin --- Key: MCLOVER-9 URL: http://jira.codehaus.org/browse/MCLOVER-9 Project: Maven 2.x Clover Plugin Type: Bug Reporter: Wim Deblauwe Assignee: Vincent Siveton I get the following error with the clover plugin [INFO] [ERROR] FATAL ERROR [INFO] [INFO] Can't find bundle for base name clover-report, locale nl_NL [INFO] [INFO] Trace java.util.MissingResourceException: Can't find bundle for base name clover-report, locale nl_NL at java.util.ResourceBundle.throwMissingResourceException(ResourceBundle.java:837) at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:806) at java.util.ResourceBundle.getBundle(ResourceBundle.java:700) at org.apache.maven.plugin.clover.CloverReportMojo.getBundle(CloverReportMojo.java:104) at org.apache.maven.plugin.clover.CloverReportMojo.getName(CloverReportMojo.java:136) at org.apache.maven.plugins.site.ReportComparator.compare(ReportComparator.java:40) at java.util.Arrays.mergeSort(Arrays.java:1284) at java.util.Arrays.sort(Arrays.java:1223) at java.util.Collections.sort(Collections.java:159) at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:240) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:399) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:519) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:469) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:448) 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) regards, Wim -- 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: (MCLOVER-13) Check artifact language
[ http://jira.codehaus.org/browse/MCLOVER-13?page=all ]
Vincent Massol updated MCLOVER-13:
--
Version: 2.0-alpha-1
Fix Version: 2.0
type: Improvement (was: Bug)
Check artifact language
---
Key: MCLOVER-13
URL: http://jira.codehaus.org/browse/MCLOVER-13
Project: Maven 2.x Clover Plugin
Type: Improvement
Versions: 2.0-alpha-1
Reporter: Mario Van Steenberghe
Priority: Minor
Fix For: 2.0
Would it be possible to add an artifact language verification before
executing your mojos ? This was done in the javadoc plug-in and seems to work
great.
In a multi-project build, this allows you to specify the reports for all
sub-projects at parent level. The generation of the clover report will be
excluded, since it is not defined as a 'java' artifact.
---
public void executeReport( Locale locale ) throws MavenReportException {
ArtifactHandler artifactHandler =
project.getArtifact().getArtifactHandler();
if ( !java.equals( artifactHandler.getLanguage() ) ) {
getLog().info( Not executing Clover as the project is not a Java
classpath-capable package );
return;
}
}
-
This could be included in both CloverReportMojo and CloverInstrumentMojo.
Regards,
Mario.
--
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] Closed: (MCLOVER-9) Locale problem in Clover plugin
[ http://jira.codehaus.org/browse/MCLOVER-9?page=all ] Vincent Massol closed MCLOVER-9: Assign To: Vincent Massol (was: Vincent Siveton) Resolution: Won't Fix This was not a clover plugin issue. It was a Maven 2.0 report issue fixed by Vincent Siveton. Locale problem in Clover plugin --- Key: MCLOVER-9 URL: http://jira.codehaus.org/browse/MCLOVER-9 Project: Maven 2.x Clover Plugin Type: Bug Versions: 2.0-alpha-1 Reporter: Wim Deblauwe Assignee: Vincent Massol Fix For: 2.0 I get the following error with the clover plugin [INFO] [ERROR] FATAL ERROR [INFO] [INFO] Can't find bundle for base name clover-report, locale nl_NL [INFO] [INFO] Trace java.util.MissingResourceException: Can't find bundle for base name clover-report, locale nl_NL at java.util.ResourceBundle.throwMissingResourceException(ResourceBundle.java:837) at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:806) at java.util.ResourceBundle.getBundle(ResourceBundle.java:700) at org.apache.maven.plugin.clover.CloverReportMojo.getBundle(CloverReportMojo.java:104) at org.apache.maven.plugin.clover.CloverReportMojo.getName(CloverReportMojo.java:136) at org.apache.maven.plugins.site.ReportComparator.compare(ReportComparator.java:40) at java.util.Arrays.mergeSort(Arrays.java:1284) at java.util.Arrays.sort(Arrays.java:1223) at java.util.Collections.sort(Collections.java:159) at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:240) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:399) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:519) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:469) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:448) 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) regards, Wim -- 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] Reopened: (MCLOVER-11) Add support for passing flush policy/flush interval to Clover
[ http://jira.codehaus.org/browse/MCLOVER-11?page=all ] Vincent Massol reopened MCLOVER-11: --- Reopen to set again versions after the jira move from Maven 2 to Maven 2.x Clover Plugin Add support for passing flush policy/flush interval to Clover - Key: MCLOVER-11 URL: http://jira.codehaus.org/browse/MCLOVER-11 Project: Maven 2.x Clover Plugin Type: Bug Reporter: Vincent Massol Assignee: Vincent Massol See http://cenqua.com/clover/doc/adv/flushpolicies.html. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MCLOVER-9) Locale problem in Clover plugin
[ http://jira.codehaus.org/browse/MCLOVER-9?page=all ] Vincent Massol updated MCLOVER-9: - Version: 2.0-alpha-1 Fix Version: 2.0 set again versions after the jira move from Maven 2 to Maven 2.x Clover Plugin Locale problem in Clover plugin --- Key: MCLOVER-9 URL: http://jira.codehaus.org/browse/MCLOVER-9 Project: Maven 2.x Clover Plugin Type: Bug Versions: 2.0-alpha-1 Reporter: Wim Deblauwe Assignee: Vincent Siveton Fix For: 2.0 I get the following error with the clover plugin [INFO] [ERROR] FATAL ERROR [INFO] [INFO] Can't find bundle for base name clover-report, locale nl_NL [INFO] [INFO] Trace java.util.MissingResourceException: Can't find bundle for base name clover-report, locale nl_NL at java.util.ResourceBundle.throwMissingResourceException(ResourceBundle.java:837) at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:806) at java.util.ResourceBundle.getBundle(ResourceBundle.java:700) at org.apache.maven.plugin.clover.CloverReportMojo.getBundle(CloverReportMojo.java:104) at org.apache.maven.plugin.clover.CloverReportMojo.getName(CloverReportMojo.java:136) at org.apache.maven.plugins.site.ReportComparator.compare(ReportComparator.java:40) at java.util.Arrays.mergeSort(Arrays.java:1284) at java.util.Arrays.sort(Arrays.java:1223) at java.util.Collections.sort(Collections.java:159) at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:240) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:399) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:519) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:469) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:448) 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) regards, Wim -- 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: (MCLOVER-11) Add support for passing flush policy/flush interval to Clover
[ http://jira.codehaus.org/browse/MCLOVER-11?page=all ] Vincent Massol updated MCLOVER-11: -- Version: 2.0-alpha-1 Fix Version: 2.0 type: New Feature (was: Bug) set again versions after the jira move from Maven 2 to Maven 2.x Clover Plugin Add support for passing flush policy/flush interval to Clover - Key: MCLOVER-11 URL: http://jira.codehaus.org/browse/MCLOVER-11 Project: Maven 2.x Clover Plugin Type: New Feature Versions: 2.0-alpha-1 Reporter: Vincent Massol Assignee: Vincent Massol Fix For: 2.0 See http://cenqua.com/clover/doc/adv/flushpolicies.html. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MCLOVER-11) Add support for passing flush policy/flush interval to Clover
[ http://jira.codehaus.org/browse/MCLOVER-11?page=all ] Vincent Massol closed MCLOVER-11: - Resolution: Fixed Fixed again versions after the jira move from Maven 2 to Maven 2.x Clover Plugin Add support for passing flush policy/flush interval to Clover - Key: MCLOVER-11 URL: http://jira.codehaus.org/browse/MCLOVER-11 Project: Maven 2.x Clover Plugin Type: New Feature Versions: 2.0-alpha-1 Reporter: Vincent Massol Assignee: Vincent Massol Fix For: 2.0 See http://cenqua.com/clover/doc/adv/flushpolicies.html. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MCLOVER-10) Upgrade to Clover 1.3.10_01
[ http://jira.codehaus.org/browse/MCLOVER-10?page=all ] Vincent Massol updated MCLOVER-10: -- Version: 2.0-alpha-1 Fix Version: 2.0 type: Improvement (was: Bug) set again versions after the jira move from Maven 2 to Maven 2.x Clover Plugin Upgrade to Clover 1.3.10_01 --- Key: MCLOVER-10 URL: http://jira.codehaus.org/browse/MCLOVER-10 Project: Maven 2.x Clover Plugin Type: Improvement Versions: 2.0-alpha-1 Reporter: Vincent Massol Assignee: Vincent Massol Fix For: 2.0 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MCLOVER-10) Upgrade to Clover 1.3.10_01
[ http://jira.codehaus.org/browse/MCLOVER-10?page=all ] Vincent Massol closed MCLOVER-10: - Resolution: Fixed Fixed again versions after the jira move from Maven 2 to Maven 2.x Clover Plugin Upgrade to Clover 1.3.10_01 --- Key: MCLOVER-10 URL: http://jira.codehaus.org/browse/MCLOVER-10 Project: Maven 2.x Clover Plugin Type: Improvement Versions: 2.0-alpha-1 Reporter: Vincent Massol Assignee: Vincent Massol Fix For: 2.0 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (MCLOVER-10) Upgrade to Clover 1.3.10_01
[ http://jira.codehaus.org/browse/MCLOVER-10?page=all ] Vincent Massol reopened MCLOVER-10: --- Reopen to set again versions after the jira move from Maven 2 to Maven 2.x Clover Plugin Upgrade to Clover 1.3.10_01 --- Key: MCLOVER-10 URL: http://jira.codehaus.org/browse/MCLOVER-10 Project: Maven 2.x Clover Plugin Type: Bug Versions: 2.0-alpha-1 Reporter: Vincent Massol Assignee: Vincent Massol Fix For: 2.0 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MCLEAN-2) Delete additional directories and files including testOutputDirectory, outputDirectory, and directory
[ http://jira.codehaus.org/browse/MCLEAN-2?page=all ] ruel loehr updated MCLEAN-2: Attachment: MCLEAN-2.txt Delete additional directories and files including testOutputDirectory, outputDirectory, and directory - Key: MCLEAN-2 URL: http://jira.codehaus.org/browse/MCLEAN-2 Project: Maven 2.x Clean Plugin Type: Bug Reporter: Ash Lux Priority: Minor Attachments: MCLEAN-2.txt, MNG-1801-maven-clean-lugin.patch -- 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: (MCLEAN-2) Delete additional directories and files including testOutputDirectory, outputDirectory, and directory
[ http://jira.codehaus.org/browse/MCLEAN-2?page=comments#action_53847 ] ruel loehr commented on MCLEAN-2: - I ran into the same situation and have attached a patch MCLEAN-2.txt as well. Delete additional directories and files including testOutputDirectory, outputDirectory, and directory - Key: MCLEAN-2 URL: http://jira.codehaus.org/browse/MCLEAN-2 Project: Maven 2.x Clean Plugin Type: Bug Reporter: Ash Lux Priority: Minor Attachments: MCLEAN-2.txt, MNG-1801-maven-clean-lugin.patch -- 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: (MCLEAN-2) Delete additional directories and files including testOutputDirectory, outputDirectory, and directory
[ http://jira.codehaus.org/browse/MCLEAN-2?page=comments#action_53849 ] Dan Tran commented on MCLEAN-2: --- rather than removing directories, It is best to remove using FileSet(s) where we can exclude/includes files within a directory. Delete additional directories and files including testOutputDirectory, outputDirectory, and directory - Key: MCLEAN-2 URL: http://jira.codehaus.org/browse/MCLEAN-2 Project: Maven 2.x Clean Plugin Type: Bug Reporter: Ash Lux Priority: Minor Attachments: MCLEAN-2.txt, MNG-1801-maven-clean-lugin.patch -- 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: (MJAVADOC-30) javadoc plugin does not work on war projects
[ http://jira.codehaus.org/browse/MJAVADOC-30?page=comments#action_53850 ] Matt Hicks commented on MJAVADOC-30: I downloaded Maven 2.0.1 and new repository plugins and I still see this behavior. Are there additional steps required or can we re-open this issue? javadoc plugin does not work on war projects - Key: MJAVADOC-30 URL: http://jira.codehaus.org/browse/MJAVADOC-30 Project: Maven 2.x Javadoc Plugin Type: Bug Environment: Linux/sun jdk 1.4.1_04 Reporter: Joe Shomphe Assignee: Brett Porter when mvn javadoc:javadoc is run, the following error occurs: [INFO] Not executing Javadoc as the project is not a Java classpath-capable package this only happens when my pom,xml has packagingwar/packaging declared When this is set to jar, javadoc works fine. The war project has java sources in it! -- 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: (MCLEAN-2) Delete additional directories and files including testOutputDirectory, outputDirectory, and directory
[ http://jira.codehaus.org/browse/MCLEAN-2?page=comments#action_53851 ] ruel loehr commented on MCLEAN-2: - Is there an example in any existing plugins where filesets are used? Delete additional directories and files including testOutputDirectory, outputDirectory, and directory - Key: MCLEAN-2 URL: http://jira.codehaus.org/browse/MCLEAN-2 Project: Maven 2.x Clean Plugin Type: Bug Reporter: Ash Lux Priority: Minor Attachments: MCLEAN-2.txt, MNG-1801-maven-clean-lugin.patch -- 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: (CONTINUUM-354) Need a way to poll for new projects
[ http://jira.codehaus.org/browse/CONTINUUM-354?page=comments#action_53852 ] Matthew Beermann commented on CONTINUUM-354: No, CONTINUUM-330 didn't solve this. Here's why: 1. Add a new module/ to the parent project and check in. 2. Rebuild the parent project. 3. I would expect the new module to be added to the Continuum project list, if it doesn't exist already. However, no such thing occurs. It seems that Continuum will check/add modules when the parent project is first added, but not when the parent project changes. It should, IMO. Need a way to poll for new projects --- Key: CONTINUUM-354 URL: http://jira.codehaus.org/browse/CONTINUUM-354 Project: Continuum Type: Improvement Versions: 1.0-beta-1 Reporter: Matthew Beermann Fix For: 1.1 The feature where Continuum can populate its build list from a URL is wonderful; it'd be even more wonderful if it could remember that URL and poll it periodically. We have a master build list of all projects that we'll use to initially populate the build database; but ideally we could simply add a new project to that in CVS and have Continuum just pick it up. This is a feature that we've (somewhat painfully) managed to implement in CruiseControl, and it's a must-have if we're going to switch over... this might or might not depend on CONTINUUM-330. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MCLEAN-2) Delete additional directories and files including testOutputDirectory, outputDirectory, and directory
[ http://jira.codehaus.org/browse/MCLEAN-2?page=comments#action_53853 ] Dan Tran commented on MCLEAN-2: --- mavne-assembly-plugin uses its own generated FileSet maven-scm-plugin ( in maven-scm ) uses it s own ScmFileSet Delete additional directories and files including testOutputDirectory, outputDirectory, and directory - Key: MCLEAN-2 URL: http://jira.codehaus.org/browse/MCLEAN-2 Project: Maven 2.x Clean Plugin Type: Bug Reporter: Ash Lux Priority: Minor Attachments: MCLEAN-2.txt, MNG-1801-maven-clean-lugin.patch -- 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] Closed: (MNG-1690) [maven-ejb3-plugin] NPE in EJB3Mojo.java
[ http://jira.codehaus.org/browse/MNG-1690?page=all ] Stephane Nicoll closed MNG-1690: Resolution: Fixed Applied to ejb3 and par plugins ; Thanks. [maven-ejb3-plugin] NPE in EJB3Mojo.java Key: MNG-1690 URL: http://jira.codehaus.org/browse/MNG-1690 Project: Maven 2 Type: Bug Components: Sandbox Reporter: Tim Kettler Assignee: Stephane Nicoll Attachments: maven-ejb3-plugin.patch running mvn package fails with: [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error assembling EJB3 [INFO] [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Error assembling EJB3 at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:544) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:469) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:448) 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:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) 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) Caused by: org.apache.maven.plugin.MojoExecutionException: Error assembling EJB3 at org.apache.maven.plugin.ejb3.Ejb3Mojo.execute(Ejb3Mojo.java:146) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:519) ... 16 more Caused by: java.lang.NullPointerException at org.apache.maven.plugin.ejb3.Ejb3Mojo.execute(Ejb3Mojo.java:136) ... 18 more A look at the source shows that the archiver is never initialized. The attached patch initializes the archiver with a JarArchiver. -- 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] Closed: (MNG-1691) [maven-par-plugin] NPE in ParMojo.java
[ http://jira.codehaus.org/browse/MNG-1691?page=all ] Stephane Nicoll closed MNG-1691: Resolution: Duplicate See MNG-1690. [maven-par-plugin] NPE in ParMojo.java -- Key: MNG-1691 URL: http://jira.codehaus.org/browse/MNG-1691 Project: Maven 2 Type: Bug Components: Sandbox Reporter: Tim Kettler Assignee: Stephane Nicoll Attachments: maven-par-plugin.patch Same problem as described in MNG-1690. -- 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] Reopened: (MEAR-15) Support of sar files
[ http://jira.codehaus.org/browse/MEAR-15?page=all ] Stephane Nicoll reopened MEAR-15: - Building the roadmap for 2.1 Support of sar files Key: MEAR-15 URL: http://jira.codehaus.org/browse/MEAR-15 Project: Maven 2.x Ear Plugin Type: Bug Environment: Maven 2.0.1, maven-ear-plugin 2.0, Windows XP. Reporter: Jay Stramel Assignee: Stephane Nicoll Fix For: 2.1 Building an ear file will fail if the ear file requires a SAR file as one of it's components. -- 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] Closed: (MEAR-15) Support of sar files
[ http://jira.codehaus.org/browse/MEAR-15?page=all ] Stephane Nicoll closed MEAR-15: --- Resolution: Fixed Fix Version: 2.1 Support of sar files Key: MEAR-15 URL: http://jira.codehaus.org/browse/MEAR-15 Project: Maven 2.x Ear Plugin Type: Bug Environment: Maven 2.0.1, maven-ear-plugin 2.0, Windows XP. Reporter: Jay Stramel Assignee: Stephane Nicoll Fix For: 2.1 Building an ear file will fail if the ear file requires a SAR file as one of it's components. -- 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] Reopened: (MEAR-12) Make maven-ear-plugin feature complete against m1 version
[ http://jira.codehaus.org/browse/MEAR-12?page=all ] Stephane Nicoll reopened MEAR-12: - Make maven-ear-plugin feature complete against m1 version - Key: MEAR-12 URL: http://jira.codehaus.org/browse/MEAR-12 Project: Maven 2.x Ear Plugin Type: Bug Reporter: Edwin Punzalan Assignee: Edwin Punzalan Fix For: 2.0 Attachments: MNG-822-maven-ear-plugin.patch Original Estimate: 8 hours Time Spent: 2 hours Remaining: 0 minutes -- 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] Closed: (MEAR-12) Make maven-ear-plugin feature complete against m1 version
[ http://jira.codehaus.org/browse/MEAR-12?page=all ] Stephane Nicoll closed MEAR-12: --- Resolution: Fixed Fix Version: 2.0 Make maven-ear-plugin feature complete against m1 version - Key: MEAR-12 URL: http://jira.codehaus.org/browse/MEAR-12 Project: Maven 2.x Ear Plugin Type: Bug Reporter: Edwin Punzalan Assignee: Edwin Punzalan Fix For: 2.0 Attachments: MNG-822-maven-ear-plugin.patch Original Estimate: 8 hours Time Spent: 2 hours Remaining: 0 minutes -- 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] Closed: (MPXDOC-186) Mailing list links break if the address starts with http
[ http://jira.codehaus.org/browse/MPXDOC-186?page=all ] Lukas Theussl closed MPXDOC-186: Resolution: Fixed Fix Version: 1.10 Mailing list links break if the address starts with http Key: MPXDOC-186 URL: http://jira.codehaus.org/browse/MPXDOC-186 Project: maven-xdoc-plugin Type: Bug Versions: 1.9.2 Reporter: Ortwin Glück Fix For: 1.10 Our mailing lists have email addresses that start with http: e.g. [EMAIL PROTECTED] Our POM: http://svn.apache.org/repos/asf/jakarta/commons/proper/httpclient/trunk/project.xml The generated HTML: http://jakarta.apache.org/commons/httpclient/mail-lists.html As you can see the mailing list links are missing the mailto: prefix. The problem is on line 24 in the file plugin-resources/templates/mail-lists.xml: #if ($link.trim().startsWith(http)) which should be #if ($link.trim().startsWith(http://;)) or equivalent. -- 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] Closed: (MEAR-4) Some src/main/resources contents are not included in the package
[ http://jira.codehaus.org/browse/MEAR-4?page=all ] Stephane Nicoll closed MEAR-4: -- Resolution: Fixed Fix Version: 2.0 Some src/main/resources contents are not included in the package Key: MEAR-4 URL: http://jira.codehaus.org/browse/MEAR-4 Project: Maven 2.x Ear Plugin Type: Bug Environment: Maven 2, Java 1.4.2_08 Reporter: John Tolentino Assignee: Brett Porter Fix For: 2.0 Some src/main/resources files and folders were excluded in the package (e.g. other META-INF xmls). Even defining the resource directory in the pom does not work. Use the standard resources goals instead of copyDirectoryStructure(). -- 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] Reopened: (MEAR-4) Some src/main/resources contents are not included in the package
[ http://jira.codehaus.org/browse/MEAR-4?page=all ] Stephane Nicoll reopened MEAR-4: Some src/main/resources contents are not included in the package Key: MEAR-4 URL: http://jira.codehaus.org/browse/MEAR-4 Project: Maven 2.x Ear Plugin Type: Bug Environment: Maven 2, Java 1.4.2_08 Reporter: John Tolentino Assignee: Brett Porter Fix For: 2.0 Some src/main/resources files and folders were excluded in the package (e.g. other META-INF xmls). Even defining the resource directory in the pom does not work. Use the standard resources goals instead of copyDirectoryStructure(). -- 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] Reopened: (MEAR-9) Add support for packaging .par and .ejb3 files in an .ear file
[ http://jira.codehaus.org/browse/MEAR-9?page=all ]
Stephane Nicoll reopened MEAR-9:
Add support for packaging .par and .ejb3 files in an .ear file
--
Key: MEAR-9
URL: http://jira.codehaus.org/browse/MEAR-9
Project: Maven 2.x Ear Plugin
Type: Bug
Reporter: Adrian
Assignee: Stephane Nicoll
Priority: Minor
Fix For: 2.1
Attachments: MNG-1264.diff
The ear plugin does not support packaging of .ejb3 and .par files into an
.ear file.
To fix this a few lines of code need to be added to the
org.apache.maven.plugin.ear.EarModuleFactory class in the newEarModule method.
else if ( ejb3.equals( artifact.getType() ) )
{
return new EjbModule( artifact );
}
else if ( par.equals( artifact.getType() ) )
{
return new EjbModule( artifact );
}
This will allow an application.xml file to be created with .ejb3 and .par
files, for example
application ...
module
ejbentities.par/ejb
/module
module
ejbbusiness.ejb3/ejb
/module
/application
--
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] Closed: (MEAR-9) Add support for packaging .par and .ejb3 files in an .ear file
[ http://jira.codehaus.org/browse/MEAR-9?page=all ]
Stephane Nicoll closed MEAR-9:
--
Resolution: Fixed
Fix Version: 2.1
Add support for packaging .par and .ejb3 files in an .ear file
--
Key: MEAR-9
URL: http://jira.codehaus.org/browse/MEAR-9
Project: Maven 2.x Ear Plugin
Type: Bug
Reporter: Adrian
Assignee: Stephane Nicoll
Priority: Minor
Fix For: 2.1
Attachments: MNG-1264.diff
The ear plugin does not support packaging of .ejb3 and .par files into an
.ear file.
To fix this a few lines of code need to be added to the
org.apache.maven.plugin.ear.EarModuleFactory class in the newEarModule method.
else if ( ejb3.equals( artifact.getType() ) )
{
return new EjbModule( artifact );
}
else if ( par.equals( artifact.getType() ) )
{
return new EjbModule( artifact );
}
This will allow an application.xml file to be created with .ejb3 and .par
files, for example
application ...
module
ejbentities.par/ejb
/module
module
ejbbusiness.ejb3/ejb
/module
/application
--
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] Closed: (MEAR-6) Packaging plugins like war, ear does not check artifacts if they are tagged as optional
[ http://jira.codehaus.org/browse/MEAR-6?page=all ] Stephane Nicoll closed MEAR-6: -- Resolution: Fixed Fix Version: 2.1 Packaging plugins like war, ear does not check artifacts if they are tagged as optional --- Key: MEAR-6 URL: http://jira.codehaus.org/browse/MEAR-6 Project: Maven 2.x Ear Plugin Type: Bug Reporter: Edwin Punzalan Assignee: Edwin Punzalan Fix For: 2.1 Attachments: MNG-1280-maven-ear-plugin.patch, MNG-1280-maven-rar-plugin.patch, MNG-1280-maven-war-plugin.patch This fixes war, ear, and rar. Are there other artifacts that should also check for the optional tag? -- 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] Reopened: (MEAR-5) application.xml generated incorrectly
[ http://jira.codehaus.org/browse/MEAR-5?page=all ] Stephane Nicoll reopened MEAR-5: application.xml generated incorrectly - Key: MEAR-5 URL: http://jira.codehaus.org/browse/MEAR-5 Project: Maven 2.x Ear Plugin Type: Bug Reporter: Tomislav Stojcevich Assignee: Stephane Nicoll Priority: Minor Fix For: 2.1 Attachments: MNG-1402-maven-ear-plugin.patch, MNG-1402-maven-ear-pluginB.patch When generating an application.xml the description is written out before the display-name. According to the DTD, display-name needs to be first. See: http://java.sun.com/dtd/application_1_3.dtd A work around is to not use a description element in the pom. -- 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] Reopened: (MEAR-6) Packaging plugins like war, ear does not check artifacts if they are tagged as optional
[ http://jira.codehaus.org/browse/MEAR-6?page=all ] Stephane Nicoll reopened MEAR-6: Packaging plugins like war, ear does not check artifacts if they are tagged as optional --- Key: MEAR-6 URL: http://jira.codehaus.org/browse/MEAR-6 Project: Maven 2.x Ear Plugin Type: Bug Reporter: Edwin Punzalan Assignee: Edwin Punzalan Fix For: 2.1 Attachments: MNG-1280-maven-ear-plugin.patch, MNG-1280-maven-rar-plugin.patch, MNG-1280-maven-war-plugin.patch This fixes war, ear, and rar. Are there other artifacts that should also check for the optional tag? -- 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] Closed: (MEAR-5) application.xml generated incorrectly
[ http://jira.codehaus.org/browse/MEAR-5?page=all ] Stephane Nicoll closed MEAR-5: -- Resolution: Fixed Fix Version: 2.1 application.xml generated incorrectly - Key: MEAR-5 URL: http://jira.codehaus.org/browse/MEAR-5 Project: Maven 2.x Ear Plugin Type: Bug Reporter: Tomislav Stojcevich Assignee: Stephane Nicoll Priority: Minor Fix For: 2.1 Attachments: MNG-1402-maven-ear-plugin.patch, MNG-1402-maven-ear-pluginB.patch When generating an application.xml the description is written out before the display-name. According to the DTD, display-name needs to be first. See: http://java.sun.com/dtd/application_1_3.dtd A work around is to not use a description element in the pom. -- 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] Closed: (MEAR-13) excluding resources in ear archive
[ http://jira.codehaus.org/browse/MEAR-13?page=all ] Stephane Nicoll closed MEAR-13: --- Resolution: Fixed Fix Version: 2.1 excluding resources in ear archive -- Key: MEAR-13 URL: http://jira.codehaus.org/browse/MEAR-13 Project: Maven 2.x Ear Plugin Type: Bug Reporter: Michal Stochmialek Assignee: Stephane Nicoll Fix For: 2.1 I'm using resourceDir for including additional resources in ear archive. Since the project is stored in CVS, directories within resourcesDir contain 'CVS' directories. I would like to exclude those directories from ear archive. I believe that the same issue is with earSourceDirectory. -- 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] Reopened: (MEAR-2) EAR plugin ignores application XML setting
[ http://jira.codehaus.org/browse/MEAR-2?page=all ]
Stephane Nicoll reopened MEAR-2:
EAR plugin ignores application XML setting
--
Key: MEAR-2
URL: http://jira.codehaus.org/browse/MEAR-2
Project: Maven 2.x Ear Plugin
Type: Bug
Reporter: mike perham
Assignee: Stephane Nicoll
In EarMojo.java:
/**
* The location of the application.xml file to be used within the ear
file.
*
* @parameter
expression=${basedir}/src/main/application/META-INF/application.xml
*/
private File applicationXmlFile;
I set this and Maven still generates an application.xml file anyways.
Checking the code, this variable is never actually referenced anywhere so it
appears impossible to use the EAR plugin with a pre-written application.xml.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (MEAR-13) excluding resources in ear archive
[ http://jira.codehaus.org/browse/MEAR-13?page=all ] Stephane Nicoll reopened MEAR-13: - excluding resources in ear archive -- Key: MEAR-13 URL: http://jira.codehaus.org/browse/MEAR-13 Project: Maven 2.x Ear Plugin Type: Bug Reporter: Michal Stochmialek Assignee: Stephane Nicoll Fix For: 2.1 I'm using resourceDir for including additional resources in ear archive. Since the project is stored in CVS, directories within resourcesDir contain 'CVS' directories. I would like to exclude those directories from ear archive. I believe that the same issue is with earSourceDirectory. -- 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: (MPJAVADOC-68) Combined use of online and offline links
[ http://jira.codehaus.org/browse/MPJAVADOC-68?page=comments#action_53857 ] Lukas Theussl commented on MPJAVADOC-68: The source repository is here: http://svn.apache.org/viewcvs.cgi/maven/maven-1/plugins/trunk/javadoc/ please check the main maven site for instructions on how to create a patch: http://maven.apache.org/maven-1.x/contributing/patches.html Anyway, I'll have a look at your patch ASAP, thanks! Combined use of online and offline links Key: MPJAVADOC-68 URL: http://jira.codehaus.org/browse/MPJAVADOC-68 Project: maven-javadoc-plugin Type: Improvement Versions: 1.7 Reporter: Wouter Hermeling Priority: Minor Attachments: plugin.jelly, plugin.jelly.patch i want to be able to use both offline and online links. For offline links i mean 'online links in offline mode'. The reason is trivial: 1. I have links to online available apidocs like the javaapi, j2ee api, jasperrepots api, etc 2. I also have links to apidocs which are not availble yet. These apidocs become availble when the whole maven site is being published to a secure site. For situation 1, i'd like to use online links For situation 2, i'd like to use online links in offline mode. I've read the plugin jelly. It seems there's a build in feature to use offline links even in online mode, but that does not seem to work. According to the javadoc api itself, it supports both online and offline links simultaneously. It does not even have a online/offline mode. This is what the maven-javadoc-plugin should support as well. -- 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] Closed: (MEAR-10) need to set default bundleDir for all ear modules
[ http://jira.codehaus.org/browse/MEAR-10?page=all ] Stephane Nicoll closed MEAR-10: --- Resolution: Fixed Fix Version: 2.1 need to set default bundleDir for all ear modules - Key: MEAR-10 URL: http://jira.codehaus.org/browse/MEAR-10 Project: Maven 2.x Ear Plugin Type: Bug Reporter: Michal Stochmialek Assignee: Stephane Nicoll Fix For: 2.1 I need an improvement of bundleDir feature. I would like to specify common bundleDir for all modules in ear. For example: plugin artifactIdmaven-ear-plugin/artifactId configuration resourcesDirsrc/resources/resourcesDir defaultBundleDirAPP-INF/lib/defaultBundleDir modules javaModule ... /javaModule ejbModule ... /ejbModule /modules /configuration /plugin I have ear with single ejb and a bunch of jar archives. I would like them all placed in APP-INF/lib directory. Using bundleDir tag I must duplicate whole dependency list (and also transitive dependencies) in ear-plugin configuration and change bundle dir of each archive. It's very frustrating. -- 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] Closed: (MEAR-2) EAR plugin ignores application XML setting
[ http://jira.codehaus.org/browse/MEAR-2?page=all ]
Stephane Nicoll closed MEAR-2:
--
Resolution: Fixed
Fix Version: 2.1
EAR plugin ignores application XML setting
--
Key: MEAR-2
URL: http://jira.codehaus.org/browse/MEAR-2
Project: Maven 2.x Ear Plugin
Type: Bug
Reporter: mike perham
Assignee: Stephane Nicoll
Fix For: 2.1
In EarMojo.java:
/**
* The location of the application.xml file to be used within the ear
file.
*
* @parameter
expression=${basedir}/src/main/application/META-INF/application.xml
*/
private File applicationXmlFile;
I set this and Maven still generates an application.xml file anyways.
Checking the code, this variable is never actually referenced anywhere so it
appears impossible to use the EAR plugin with a pre-written application.xml.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (MEAR-10) need to set default bundleDir for all ear modules
[ http://jira.codehaus.org/browse/MEAR-10?page=all ] Stephane Nicoll reopened MEAR-10: - need to set default bundleDir for all ear modules - Key: MEAR-10 URL: http://jira.codehaus.org/browse/MEAR-10 Project: Maven 2.x Ear Plugin Type: Bug Reporter: Michal Stochmialek Assignee: Stephane Nicoll Fix For: 2.1 I need an improvement of bundleDir feature. I would like to specify common bundleDir for all modules in ear. For example: plugin artifactIdmaven-ear-plugin/artifactId configuration resourcesDirsrc/resources/resourcesDir defaultBundleDirAPP-INF/lib/defaultBundleDir modules javaModule ... /javaModule ejbModule ... /ejbModule /modules /configuration /plugin I have ear with single ejb and a bunch of jar archives. I would like them all placed in APP-INF/lib directory. Using bundleDir tag I must duplicate whole dependency list (and also transitive dependencies) in ear-plugin configuration and change bundle dir of each archive. It's very frustrating. -- 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: (MEAR-8) Add security role definitions to maven-ear-plugin
[ http://jira.codehaus.org/browse/MEAR-8?page=all ]
Stephane Nicoll updated MEAR-8:
---
Fix Version: 2.2
type: Improvement (was: Bug)
Add security role definitions to maven-ear-plugin
-
Key: MEAR-8
URL: http://jira.codehaus.org/browse/MEAR-8
Project: Maven 2.x Ear Plugin
Type: Improvement
Reporter: Martijn de Bruijn
Assignee: Stephane Nicoll
Priority: Minor
Fix For: 2.2
The maven-ear-plugin is not capable of defining security-roles. This should
be added.
An example of the pom.xml:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-ear-plugin/artifactId
configuration
resourcesDir${basedir}/META-INF/resourcesDir
security
security-role id=SecurityRole_1131964323008
description/description
role-namemanager/role-name
/security-role
security-role id=SecurityRole_1131964323018
description/description
role-nameteller/role-name
/security-role
/security
/configuration
/plugin
It should be possible to add the id field to the security-role element to be
able to link the roles to other generated artifacts.
--
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] Reopened: (MEAR-1) Plugin configuration doesn't support .ejb3 and .par EJB modules
[ http://jira.codehaus.org/browse/MEAR-1?page=all ] Stephane Nicoll reopened MEAR-1: Plugin configuration doesn't support .ejb3 and .par EJB modules --- Key: MEAR-1 URL: http://jira.codehaus.org/browse/MEAR-1 Project: Maven 2.x Ear Plugin Type: Bug Reporter: Tim Kettler Assignee: Stephane Nicoll Priority: Minor Fix For: 2.1 Attachments: MNG-1723.patch, test-prj.zip When specifying a module configuration for an EJB-Module which is of the type .ejb3 or .par maven fails with ther following error: [EMAIL PROTECTED]:~/Develop/test-prj$ mvn -e package + Error stacktraces are turned on. [INFO] Scanning for projects... [INFO] Reactor build order: [INFO] Unnamed - test:test-project:pom:1.0-SNAPSHOT [INFO] Unnamed - test:test-ejb:ejb3:1.0-SNAPSHOT [INFO] Unnamed - test:test-ear:ear:1.0-SNAPSHOT [INFO] [INFO] Building Unnamed - test:test-project:pom:1.0-SNAPSHOT [INFO]task-segment: [package] [INFO] [INFO] No goals needed for project - skipping [INFO] [INFO] Building Unnamed - test:test-ejb:ejb3:1.0-SNAPSHOT [INFO]task-segment: [package] [INFO] [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:compile] Compiling 1 source file to /home/tik/Develop/test-prj/test-ejb/target/classes [INFO] [resources:testResources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:testCompile] [INFO] No sources to compile [INFO] [surefire:test] [INFO] No tests to run. [INFO] [ejb3:ejb3] [INFO] Building jar: /home/tik/Develop/test-prj/test-ejb/target/test-ejb-1.0-SNAPSHOT.ejb3 [INFO] [INFO] Building Unnamed - test:test-ear:ear:1.0-SNAPSHOT [INFO]task-segment: [package] [INFO] [INFO] [ear:generate-application-xml] [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Artifact[test:test-ejb:ejb] is not a dependency of the project. [INFO] [INFO] Trace org.apache.maven.BuildFailureException: Artifact[test:test-ejb:ejb] is not a dependency of the project. at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:540) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:469) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:448) 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:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) 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) Caused by: org.apache.maven.plugin.MojoFailureException: Artifact[test:test-ejb:ejb] is not a dependency of the project. at org.apache.maven.plugin.ear.AbstractEarModule.resolveArtifact(AbstractEarModule.java:98) at org.apache.maven.plugin.ear.AbstractEarMojo.execute(AbstractEarMojo.java:98) at org.apache.maven.plugin.ear.GenerateApplicationXmlMojo.execute(GenerateApplicationXmlMojo.java:96) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) at
