[jira] Updated: (MNG-1682) Plugins do not honor the correct extension when run as a part of a multiproject build
[ http://jira.codehaus.org/browse/MNG-1682?page=all ] Jochen Wiedmann updated MNG-1682: - Attachment: ReactorProblem.tar.gz > Plugins do not honor the correct extension when run as a part of a > multiproject build > - > > Key: MNG-1682 > URL: http://jira.codehaus.org/browse/MNG-1682 > Project: Maven 2 > Type: Bug > Components: Plugins and Lifecycle > Versions: 2.0 > Environment: Windows NT; JDK 1.5 > Reporter: Nigel Magnay > Fix For: 2.0.4 > Attachments: ReactorProblem.tar.gz > > > I have a plugin with a component.xml described here. > I think the component.xml is correct - it certainly looks the > same as the plexus examples. > My project that uses this plugin works entirely correctly, *unless* it > is a part of a multiproject build, in which case it uses the wrong > extension. I don't know why this would be the case unless I've missed > something? > In same directory: > W:\kms\dev\apps\kms>mvn install > [INFO] Scanning for projects... > [INFO] > > [INFO] Building KMS Application Code > [INFO]task-segment: [install] > [INFO] > > [INFO] [cargo2:uberwar] > [INFO] [install:install] > [INFO] Installing W:\1244 - Knowledge Management System > (KMS)\dev\apps\kms\target\kms-2.0-SNAPSHOT.war to C:\Documents and > Settings\nig > el.magnay\.m2\repository\com\cswgroup\kms\kms\2.0-SNAPSHOT\kms-2.0-SNAPSHOT.war > [INFO] > > [INFO] BUILD SUCCESSFUL > [INFO] > > [INFO] Total time: 1 minute 9 seconds > [INFO] Finished at: Thu Nov 24 11:46:53 GMT 2005 > [INFO] Final Memory: 3M/6M > [INFO] > > As a part of a multiproject: > > [INFO] > > [INFO] Building KMS Application Code > [INFO]task-segment: [install] > [INFO] > > [INFO] [cargo2:uberwar] > [INFO] [install:install] > [INFO] Installing W:\1244 - Knowledge Management System > (KMS)\dev\apps\kms\target\kms-2.0-SNAPSHOT.war to C:\Documents and > Settings\nig > el.magnay\.m2\repository\com\cswgroup\kms\kms\2.0-SNAPSHOT\kms-2.0-SNAPSHOT.uberwar > > Config of plugin: > > > > org.apache.maven.lifecycle.mapping.LifecycleMapping > uberwar > > org.apache.maven.lifecycle.mapping.DefaultLifecycleMapping > > > >org.codehaus.cargo.maven2:cargo-maven2-plugin:uberwar > > > org.apache.maven.plugins:maven-install-plugin:install > > org.apache.maven.plugins:maven-deploy-plugin:deploy > > > > > org.apache.maven.artifact.handler.ArtifactHandler > uberwar > > org.apache.maven.artifact.handler.DefaultArtifactHandler > >uberwar > war >uberwar > > > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MWAR-21) Need a way to include limited set of webapp's dependencies
[ http://jira.codehaus.org/browse/MWAR-21?page=comments#action_61851 ] John Tolentino commented on MWAR-21: DIRK OLMES: Usecase: Pack a war that includes only a limited set of the webapp's dependencies. Solution: Profiles Usecase: To run from the development machines, need ejb*-client, only. And for deployment on the production server, those dependencies have to be omitted. Solution: Still profiles. Create a "test" profile where the dependencies used only for the development machines (ejb*-client) are declared. Concern: Don't want to duplicate all the dependencies of our-ejb-facade in the webapp's pom. Answer: There will be no duplicates here because, like what Trygve said, you only need to declare the uncommon artifacts (in this case your ejb*-client dependencies). Related URL: - http://maven.apache.org/guides/introduction/introduction-to-profiles.html DAVID BODEN: Usecase: Packaging three .war files in a .ear. They share most of their dependencies. Same as "Developer packages multiple war files in an ear and wants to consolidate the dependencies onto the ear classpath." EAR-PROJECT (parent) * WAR1 (child-module) * WAR2 (child-module) * WAR3 (child-module) Need to include the dependencies as .jar files in the .ear and have them loaded in my container by the EJB ClassLoader. But don't want the .jar files packed into both of the .war files. Solution: PARENT-POM * EAR-PROJECT * PARENT-POM2 ** WAR1 ** WAR2 ** WAR3 Declare common dependencies in WAR1, WAR2 and WAR3 in PARENT-POM2 with provided scope. Also declare these dependencies (without the provided scope) in the EAR project. Add WAR1, WAR2 and WAR3 to EAR-PROJECT's dependencies as well. Verified this setup works in a similar project. WAR1, WAR2 and WAR3 builds but their common dependencies are not included in the wars. EAR-PROJECT includes all the WARs and their dependencies in its packaging. EUGENE KULESHOV: Need: Dependency scope that is required for compilation but not in the runtime. Same As "Way to exclude certain dependencies from being packaged into war. Eg. servlet-api-2.4.jar is required for most of the sevlet or web framework but it should not be packaged into war because api is provided by container." Answer: Provided scope, As was mentioned by Grzegorz Slowikowski. Also verified this and war builds but does not add jars with provided scope. Related URLs: - http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html - http://maven.apache.org/ref/2.0.3-SNAPSHOT/maven-model/maven.html > Need a way to include limited set of webapp's dependencies > -- > > Key: MWAR-21 > URL: http://jira.codehaus.org/browse/MWAR-21 > Project: Maven 2.x War Plugin > Type: Improvement > Environment: M2.0.1 > Reporter: Dirk Olmes > Assignee: John Tolentino > Priority: Blocker > Fix For: 2.0 > Attachments: AbstractWarMojo.diff > > > I need a way to pack a war that includes only a limited set of the webapp's > dependencies. We're deploying in mainly two different environments: for > testing, the webapp runs standalone and thus needs to include all its > dependencies in the war. For production we deploy the webapp into a JBoss > server that has all the dependencies already installed. > I've modified AbstractWarMojo in the following way: 1) allow to specify > dependencyIncludes an dependencyExcludes (as lists) 2) upon building the war, > each dependency is checked against the excludes and the includes and will be > added to the war accordingly. > While this patch may not be the best way to to it, it clearly shows my > requirements. -- 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: (MWAR-21) Need a way to include limited set of webapp's dependencies
[ http://jira.codehaus.org/browse/MWAR-21?page=all ] John Tolentino closed MWAR-21: -- Resolution: Fixed > Need a way to include limited set of webapp's dependencies > -- > > Key: MWAR-21 > URL: http://jira.codehaus.org/browse/MWAR-21 > Project: Maven 2.x War Plugin > Type: Improvement > Environment: M2.0.1 > Reporter: Dirk Olmes > Assignee: John Tolentino > Priority: Blocker > Fix For: 2.0 > Attachments: AbstractWarMojo.diff > > Time Spent: 6 hours >Remaining: 0 minutes > > I need a way to pack a war that includes only a limited set of the webapp's > dependencies. We're deploying in mainly two different environments: for > testing, the webapp runs standalone and thus needs to include all its > dependencies in the war. For production we deploy the webapp into a JBoss > server that has all the dependencies already installed. > I've modified AbstractWarMojo in the following way: 1) allow to specify > dependencyIncludes an dependencyExcludes (as lists) 2) upon building the war, > each dependency is checked against the excludes and the includes and will be > added to the war accordingly. > While this patch may not be the best way to to it, it clearly shows my > requirements. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNGECLIPSE-59) Allow artifact resolution from workspace projects
[ http://jira.codehaus.org/browse/MNGECLIPSE-59?page=all ] Mark J. Sinke updated MNGECLIPSE-59: Attachment: ArtifactResolver-try3.patch > Allow artifact resolution from workspace projects > - > > Key: MNGECLIPSE-59 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-59 > Project: Maven 2.x Extension for Eclipse > Type: New Feature > Components: Dependency Resolver > Versions: 0.0.4 > Reporter: Leonardo Quijano Vincenzi > Assignee: Eugene Kuleshov > Fix For: 1.0.0 > Attachments: ArtifactResolver-try3.patch, > EclipseArtifactResolver-corrected.patch, EclipseArtifactResolver.patch, > maven-embedder-2.1-SNAPSHOT-dep.jar > > > Provide artifact resolution from workspace projects, which override the same > artifact from the local or remote repositories. This would allow to work with > dependant Eclipse projects without specifying the Eclipse dependency manually. > The workspace artifact resolution would have to be specified manually, since > several Maven-Enabled projects in the same workspace could have the same > artifact and version Id. Or at least automatic resolution with an optional > override would be nice. > More comments here: > http://jira.codehaus.org/browse/MNGECLIPSE-58 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-2176) Properties interpolation in settings.xml
Properties interpolation in settings.xml
Key: MNG-2176
URL: http://jira.codehaus.org/browse/MNG-2176
Project: Maven 2
Type: Bug
Components: Inheritence and Interpolation
Versions: 2.0.2
Reporter: nicolas de loof
Priority: Minor
I've set my settings.xml to set repository in M2_HOME :
${maven.home}/repository
The property ${maven.home} is not interpollated and my repository is created on
root filesystem.
--
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: (MEV-364) Fix dependencies of common-lang 1.0 (add test scope for junit)
[ http://jira.codehaus.org/browse/MEV-364?page=comments#action_61863 ] Guillaume Boissier commented on MEV-364: in fact I'm using commons-cli and the only released version is commons-cli 1.0 that depends on commons-logging 1.0 and commons-lang 1.0 I'm not sure if it realy needs all those. but if this is the case commons-lang 1.0 pom fix is required :o) (next version are allready fixed) > Fix dependencies of common-lang 1.0 (add test scope for junit) > -- > > Key: MEV-364 > URL: http://jira.codehaus.org/browse/MEV-364 > Project: Maven Evangelism > Type: Bug > Components: Invalid POM, Dependencies > Reporter: Guillaume Boissier > > > consider changing > > > junit > junit > 3.7 > > > to > > > junit > junit > 3.7 > test > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-2177) moved mojo plugins are missing web pages at http://maven.apache.org/plugins
moved mojo plugins are missing web pages at http://maven.apache.org/plugins --- Key: MNG-2177 URL: http://jira.codehaus.org/browse/MNG-2177 Project: Maven 2 Type: Bug Components: Documentation: General Reporter: John Allen From: http://maven.apache.org/plugins Changelog plugin link (http://mojo.codehaus.org/changelog-maven-plugin) Redirects to http://maven.apache.org/plugins/maven-changelog-plugin Which displays the maven 404 page Same applies to the other moved codehaus mojo plugin links -- 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: (MPEAR-17) plugin could generate more elements in application.xml
[ http://jira.codehaus.org/browse/MPEAR-17?page=all ]
Arnaud Heritier closed MPEAR-17:
Resolution: Fixed
Applied. Thx.
> plugin could generate more elements in application.xml
> --
>
> Key: MPEAR-17
> URL: http://jira.codehaus.org/browse/MPEAR-17
> Project: maven-ear-plugin
> Type: Improvement
> Environment: maven-ear-plugin-1.5, maven-1.0-rc3, windows XP SP1
> Reporter: Charles Crouch
> Assignee: Arnaud Heritier
> Priority: Minor
> Fix For: 1.9
> Attachments: MPEAR-17.patch, plugin.jelly, plugin.jelly.patch
>
>
> The EAR plugin can generate an application.xml containing display-name and
> module elements but it lacks several others, i.e.
> 1) application/description
> 2) application/security-role/role-name
> The changes described below are quite small and enable the creation of the
> above elements by specifying more properties, e.g.
> 1) maven.ear.appxml.description=Product ${pom.groupId}, version
> ${pom.currentVersion}
> 2) maven.ear.appxml.securityRoles=UserRole, AdminRole
> The changes to the plugin.jelly, positioned correctly, would be:
> 1) value="${maven.ear.appxml.description}"/>
>
> name="description">${maven.ear.appxml.description}
>
>
> 2)value="${maven.ear.appxml.securityRoles}"/>
>
>trim="true">${maven.ear.appxml.securityRoles}
>
>
>name="role-name">${role.trim()}
>
>
>
--
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: (MSUREFIRE-72) [surefire-testng] SurefireReportMojo.executeReport() throws a java.lang.NumberFormatException
[ http://jira.codehaus.org/browse/MSUREFIRE-72?page=comments#action_61867 ] Vincent Siveton commented on MSUREFIRE-72: -- It is in surefire-testng branch. Thanks > [surefire-testng] SurefireReportMojo.executeReport() throws a > java.lang.NumberFormatException > - > > Key: MSUREFIRE-72 > URL: http://jira.codehaus.org/browse/MSUREFIRE-72 > Project: Maven 2.x Surefire Plugin > Type: Bug > Reporter: Vincent Siveton > Priority: Blocker > Fix For: 2.2 > Attachments: surefire-api_diff > > > NumberFormat.getInstance() uses the current default locale in the jvm. > The patch specifies the English Locale. > Here is the full stacktrace: > [INFO] Generate "Maven Surefire Report" report. > java.lang.NumberFormatException: For input string: "0,031" > at > sun.misc.FloatingDecimal.readJavaFormatString(FloatingDecimal.java:1224) > at java.lang.Float.parseFloat(Float.java:394) > at > org.codehaus.mojo.surefire.ReportTestSuite.startElement(ReportTestSuite.java:78) > at > com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.startElement(AbstractSAXParser.java:533) > at > com.sun.org.apache.xerces.internal.impl.dtd.XMLDTDValidator.startElement(XMLDTDValidator.java:798) > at > com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanStartElement(XMLDocumentFragmentScannerImpl.java:878) > at > com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$ContentDispatcher.scanRootElementHook(XMLDocumentScannerImpl.java:1157) > at > com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(XMLDocumentFragmentScannerImpl.java:1794) > at > com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:368) > at > com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:834) > at > com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:764) > at > com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:148) > at > com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1242) > at javax.xml.parsers.SAXParser.parse(SAXParser.java:375) > at javax.xml.parsers.SAXParser.parse(SAXParser.java:311) > at > org.codehaus.mojo.surefire.ReportTestSuite.(ReportTestSuite.java:59) > at > org.codehaus.mojo.surefire.SurefireReportParser.parseXMLReportFiles(SurefireReportParser.java:42) > at > org.codehaus.mojo.surefire.SurefireReportGenerator.doGenerateReport(SurefireReportGenerator.java:44) > at > org.codehaus.mojo.surefire.SurefireReportMojo.executeReport(SurefireReportMojo.java:77) > at > org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:117) > at > org.apache.maven.plugins.site.SiteMojo.generateReportsPages(SiteMojo.java:1055) > at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:397) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.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)java.lang.NullPointerException >
[jira] Created: (MCHANGELOG-11) ViewCVS links are incorrect.
ViewCVS links are incorrect.
-
Key: MCHANGELOG-11
URL: http://jira.codehaus.org/browse/MCHANGELOG-11
Project: Maven 2.x Changelog Plugin
Type: Bug
Versions: 2.0
Reporter: Martin Johannesen
My ViewCVS links are incorrect . Example of link:
SCM Url not inherited and ending with /:
Incorrect: http://./viewcvs/viewcvs.cgi/common/om.xml
Correct: http://./viewcvs/viewcvs.cgi/common/pom.xml
SCM Url inherited and ending with /:
Incorrect: http://./viewcvs/viewcvs.cgi/common/oioom.xml
Correct: http://./viewcvs/viewcvs.cgi/common/oio/pom.xml
The problem is in org.apache.maven.changelog.ChangeLogReport:
{{
private String getAbsolutePath( final String base, final String target )
{
return absPath + target.substring( 1 );
}
}}
It always cuts of the first character of the target, maybe because it assumes
that the first character is a /.
The next problem is that when using an inherited scm url, it doesnt get a "/"
appended to the absPath, so a solution to this problem could be:
{{
private String getAbsolutePath( final String base, final String target )
{
if(!absPath.endsWith("/")) absPath+="/";
String newTarget=target;
if(newTarget.startsWith("/")) newTarget=newTarget.substring(1);
return absPath + newTarget;
}
}}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2173) support in plugins
[ http://jira.codehaus.org/browse/MNG-2173?page=comments#action_61868 ] John Allen commented on MNG-2173: - Note that a work around for this issue is to configure the reporting plugins and their dependencies as part of your build in the section of your POM, as they are reporting plugins they wont bind to a lifecycle phase (well PMD and checkstyle dont) and will thus be dormant in a normal build. However due to the way maven does things (a nice way of saying a bug depending upon perspective) when you run site:site the plugins referenced by will use their configured dependencies and will thus find resources in the custom jars youve specified. Note, if youre activating the reporting plugins via a in a child POMs you need to (pre)configure those reporting plugins in the section of your parent POM rather than the section due to another bug that prevents specified depenedencies from being picked up in child POMs when activated from . Extract from my parent POM:- maven-pmd-plugin pmd com.fujitsu.abs.build-resources 1.1-SNAPSHOT pmd-fujitsu.xml xml true utf-8 100 org.apache.maven.plugins maven-checkstyle-plugin com.fujitsu.abs.build-resources checkstyle 1.1-SNAPSHOT xml xref checkstyle-fujitsu.xml Usage in my child POM:- maven-checkstyle-plugin xml xref checkstyle-fujitsu.xml maven-pmd-plugin pmd-fujitsu.xml xml true utf-8 100 [SNIP] enableGovernanceChecks abs.enableGovernanceChecks true maven-checkstyle-plugin checkstyle com.fujitsu.abs.build-resources 1.1-SNAPSHOT standards-conformance
[jira] Closed: (CONTINUUM-441) ConcurrentModificationException when doing build (maven1, multiproject:install)
[ http://jira.codehaus.org/browse/CONTINUUM-441?page=all ] Emmanuel Venisse closed CONTINUUM-441: -- Assign To: Emmanuel Venisse Resolution: Fixed Fix Version: 1.0.2 already fixed. > ConcurrentModificationException when doing build (maven1, > multiproject:install) > --- > > Key: CONTINUUM-441 > URL: http://jira.codehaus.org/browse/CONTINUUM-441 > Project: Continuum > Type: Bug > Components: Core system > Versions: 1.0 > Reporter: Chris lutje Spelberg > Assignee: Emmanuel Venisse > Fix For: 1.0.2 > > > I get this exception when trying to build. > java.util.ConcurrentModificationException > at > java.util.AbstractList$Itr.checkForComodification(AbstractList.java:448) > at java.util.AbstractList$Itr.next(AbstractList.java:419) > at > org.apache.maven.continuum.execution.maven.m1.DefaultMavenOneMetadataHelper.mapMetadata(DefaultMavenOneMetadataHelper.java:309) > at > org.apache.maven.continuum.execution.maven.m1.MavenOneBuildExecutor.updateProjectFromCheckOut(MavenOneBuildExecutor.java:84) > at > org.apache.maven.continuum.core.action.UpdateProjectFromWorkingDirectoryContinuumAction.execute(UpdateProjectFromWorkingDirectoryContinuumAction.java:59) > at > org.apache.maven.continuum.buildcontroller.DefaultBuildController.build(DefaultBuildController.java:168) > at > org.apache.maven.continuum.buildcontroller.BuildProjectTaskExecutor.executeTask(BuildProjectTaskExecutor.java:53) > at > org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable.run(ThreadedTaskQueueExecutor.java:103) > at java.lang.Thread.run(Thread.java:534) > My project.xml: > > > 3 > Project name > mygroupid > myartifactid > SNAPSHOT > > Organization > http://www/ > > 2005 > my.package > My Short Description > > > scm:cvs:pserver:[EMAIL PROTECTED]:/cvs/project:myartifact > > scm:cvs:pserver:[EMAIL > PROTECTED]:/cvs/project:myartifact > > > > > http://jira.codehaus.org/secure/BrowseProject.jspa?id=12345 > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-2176) Properties interpolation in settings.xml
[ http://jira.codehaus.org/browse/MNG-2176?page=all ]
Brett Porter closed MNG-2176:
-
Assign To: Brett Porter
Resolution: Duplicate
> Properties interpolation in settings.xml
>
>
> Key: MNG-2176
> URL: http://jira.codehaus.org/browse/MNG-2176
> Project: Maven 2
> Type: Bug
> Components: Inheritence and Interpolation
> Versions: 2.0.2
> Reporter: nicolas de loof
> Assignee: Brett Porter
> Priority: Minor
>
>
> I've set my settings.xml to set repository in M2_HOME :
> ${maven.home}/repository
>
> The property ${maven.home} is not interpollated and my repository is created
> on root filesystem.
--
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-8) conversion of the existing unit tests to use the AbstractMojoTestCase from the plugin testing harness
[ http://jira.codehaus.org/browse/MCLEAN-8?page=comments#action_61871 ] Brett Porter commented on MCLEAN-8: --- can you please fix this so that it works in hte reactor first. Easy way to check, from parent directory: mvn -f maven-clean-plugin/pom.xml clean test > conversion of the existing unit tests to use the AbstractMojoTestCase from > the plugin testing harness > - > > Key: MCLEAN-8 > URL: http://jira.codehaus.org/browse/MCLEAN-8 > Project: Maven 2.x Clean Plugin > Type: Improvement > Reporter: Jesse McConnell > Attachments: maven-clean-harness.patch > > > This is the patch for that I am hoping are best practices in using the plugin > testing harness as mentioned in MNG-32 -- 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-7) empty removes the directory of the fileset
[ http://jira.codehaus.org/browse/MCLEAN-7?page=comments#action_61873 ]
Brett Porter commented on MCLEAN-7:
---
I think we should scratch this issue. To me ==
== null, that is, exclude nothing.
The bug should be filed against plexus-utils / file management API (if
appropriate). Perhaps we should rebase DirectoryScanner against the latest from
Ant to see if such bugs have been fixed. Anyway, not a big issue.
> empty removes the directory of the fileset
> --
>
> Key: MCLEAN-7
> URL: http://jira.codehaus.org/browse/MCLEAN-7
> Project: Maven 2.x Clean Plugin
> Type: Bug
> Reporter: Jesse McConnell
>
>
> I was shifting the unit tests over to use the plugin harness and noticed a
> test case failing.
> if you look at the test case for the fileset test case, the second fileset
> test has an addFileset(dir, "**", "");
> this unit test works fine, but when you try and actually do this behavior
> using the plugin configuration it brings up an error
>
>
> ${basedir}/target/test-classes/fileset-clean-test/buildOutputDirectory
>
> **
>
>
> that would be the plugin configuration of the same deal.
> ( results in a stack trace)
> In this case the directory is getting deleted when configured. You can
> exhibit the same behavior with the existing test case if you try and pass
> null into the addFileset signature...
> this would be the failing test case using the existing plugin, note the null
> in the second addFileset()
> --
> public void testFilesets()
> throws Exception
> {
> String base = TARGET_TEST_DIR + "/target";
> CleanMojo mojo = new CleanMojo();
> mojo.addFileset( createFileset( base, "**/file.txt", "**/subdir/**" )
> );
> String outputDirectory = TARGET_TEST_DIR + "/buildOutputDirectory";
> mojo.addFileset( createFileset( outputDirectory, "**", null ) );
> mojo.execute();
> // fileset 1
> assertTrue( checkExists( base ) );
> assertTrue( checkExists( base + "/classes" ) );
> assertFalse( checkExists( base + "/classes/file.txt" ) );
> /* TODO: looks like a bug in the file-management library
> assertTrue( FileUtils.fileExists( base + "/subdir/file.txt" ) );
> */
> // fileset 2
> assertTrue( checkExists( outputDirectory ) );
> assertFalse( checkExists( outputDirectory + "/file.txt" ) );
> System.exit(-1);
> }
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (MSOURCES-2) Maven Sources Plugin should be able to distribute test sources as well as main sources
[ http://jira.codehaus.org/browse/MSOURCES-2?page=all ] Brett Porter updated MSOURCES-2: Fix Version: 2.0.1 > Maven Sources Plugin should be able to distribute test sources as well as > main sources > -- > > Key: MSOURCES-2 > URL: http://jira.codehaus.org/browse/MSOURCES-2 > Project: Maven 2.x Sources Plugin > Type: Improvement > Environment: all > Reporter: Dan Fabulich > Fix For: 2.0.1 > > > The Maven Sources Plugin doesn't appear to have a way to distribute the test > sources along with the actual product sources. Since automated tests can > serve as good examples/working documentation, it would be nice to be able to > distribute these in my build. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MANTRUN-48) mvan.plugin.classpath does not include configured dependencies
mvan.plugin.classpath does not include configured dependencies -- Key: MANTRUN-48 URL: http://jira.codehaus.org/browse/MANTRUN-48 Project: Maven 2.x Antrun Plugin Type: Improvement Reporter: Stephen Duncan Jr If I declare additional dependencies in inside plugin configuration in the POM, I can't find any way to access these with the existing classpath elements. They should be added to maven.plugin.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
[jira] Created: (CONTINUUM-637) If two build definitions with same schedule, only first is executed
If two build definitions with same schedule, only first is executed --- Key: CONTINUUM-637 URL: http://jira.codehaus.org/browse/CONTINUUM-637 Project: Continuum Type: Bug Components: Core system Versions: 1.0.3 Environment: continuum-20060324.02 Reporter: Yann Le Du Fix For: 1.0.3 A project has two build definitions with the same schedule : Definition 1 : clean site-deploy - DEFAULT_SCHEDULE Definition 2 : clean install - DEFAULT_SCHEDULE (default build definition) Only Definition 1 is executed. According to Emmanuel Venisse, Definition 2 is launched but without changes, so it doesn't run the build. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-2178) incorrect M2_HOME guess in mvn.bat
incorrect M2_HOME guess in mvn.bat -- Key: MNG-2178 URL: http://jira.codehaus.org/browse/MNG-2178 Project: Maven 2 Type: Bug Components: Bootstrap & Build Versions: 2.0.2 Environment: WXP Reporter: Jörg Henne mvn.bat contains the following lines: :chkMHome if not "%M2_HOME%"=="" goto valMHome if "%OS%"=="Windows_NT" SET M2_HOME=%~dps0\.. if not "%M2_HOME%"=="" goto valMHome Guessing M2_HOME=%~dps0\.. leads to complaints later on, since the script expects m2.bat in bin/...: if exist "%M2_HOME%\bin\m2.bat" goto init Hence, the line should read: if "%OS%"=="Windows_NT" SET M2_HOME=%~dps0\..\.. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (CONTINUUM-638) Module isn't executed if parent has no definition for this schedule
Module isn't executed if parent has no definition for this schedule --- Key: CONTINUUM-638 URL: http://jira.codehaus.org/browse/CONTINUUM-638 Project: Continuum Type: Bug Components: Core system Versions: 1.0.3 Environment: continuum-20060324.02 Reporter: Yann Le Du Fix For: 1.0.3 Project P is parent of project M. P has 1 build definition : clean install - YET_ANOTHER_SCHEDULE M has 2 build definitions : clean install - DEFAULT_SCHEDULE (default build definition) clean install - YET_ANOTHER_SCHEDULE M won't be executed for DEFAULT_SCHEDULE It seems that M requires P to be executed first - which won't happen for this schedule. -- 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: (CONTINUUM-637) If two build definitions with same schedule, only first is executed
[ http://jira.codehaus.org/browse/CONTINUUM-637?page=comments#action_61880 ] Emmanuel Venisse commented on CONTINUUM-637: it's fixed locally but require more tests > If two build definitions with same schedule, only first is executed > --- > > Key: CONTINUUM-637 > URL: http://jira.codehaus.org/browse/CONTINUUM-637 > Project: Continuum > Type: Bug > Components: Core system > Versions: 1.0.3 > Environment: continuum-20060324.02 > Reporter: Yann Le Du > Fix For: 1.0.3 > > > A project has two build definitions with the same schedule : > Definition 1 : clean site-deploy - DEFAULT_SCHEDULE > Definition 2 : clean install - DEFAULT_SCHEDULE (default build definition) > Only Definition 1 is executed. > According to Emmanuel Venisse, Definition 2 is launched but without changes, > so it doesn't run the build. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNGECLIPSE-93) Choosing goal from Goals... dialog in Run Configuration appends to existing goal creating invalid goal
Choosing goal from Goals... dialog in Run Configuration appends to existing goal creating invalid goal -- Key: MNGECLIPSE-93 URL: http://jira.codehaus.org/browse/MNGECLIPSE-93 Project: Maven 2.x Extension for Eclipse Type: Bug Components: Maven Launcher Versions: 0.0.5 Environment: Mac OS/X 10.4.4 Reporter: Bill Siggelkow Assigned to: Eugene Kuleshov Priority: Minor This behavior occurs when you select Run > External Tools ... and pick a m2 run configuration. If I select a goal from the Goals... dialog and there is already a goal (e.g. compile) listed in the text field, the new selected goal is appended to the text (creating a goal of, for example, compilepackage) of the current goal. It seems like it should replace the text instead. -- 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: (MASSEMBLY-66) Ability to index into a nominated dependency JAR to identify files to include in the assembly (Im thinking .so/.dll etc)
[ http://jira.codehaus.org/browse/MASSEMBLY-66?page=comments#action_61891 ] ruel loehr commented on MASSEMBLY-66: - Essentially, you need to have zipfileset support. This could be very useful . On the maven site, this wouldn't be so tough too add, but plexus utils would need to be modified to have a zipfilescanner. > Ability to index into a nominated dependency JAR to identify files to include > in the assembly (Im thinking .so/.dll etc) > > > Key: MASSEMBLY-66 > URL: http://jira.codehaus.org/browse/MASSEMBLY-66 > Project: Maven 2.x Assembly Plugin > Type: Improvement > Environment: Linux, x86_64, x86, win32 > Reporter: Andy Brook > Priority: Critical > > > Im trying to bundle a SWT application, I'm almost there, the only thing > missing is the ability to include .so files in the assembly that are > currently stored inside a dependancy. As far as I can tell there is no neat > way to pull a few files out of a given dependency... > My example is the SWT libraries, the GTK linux specific JAR in the eclipse > bundle also contain the native libraries. Ive renamed this to fit into a > maven2 repository, but really dont want to have to copy the files manually. > Ideally, I would like to be able to specify the dependency in mind and extend > the fileSet element to allow the context of the include to work only within > that dependency. > If there is something Im missing and this can be done with existing plugins > Id like to hear about it! > eg: > ::POM:: > > > org.eclipse.swt > gtk-linux-x86 > 3.1.1 > runtime > > ::assembly-descriptor.xml:: > > > org.eclipse.swt:gtk-linux-x86:3.1.1 > /lib > > *.so > > -- 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: (MPTEST-10) Add timeouts to the test plugin
[ http://jira.codehaus.org/browse/MPTEST-10?page=all ]
Lukas Theussl closed MPTEST-10:
---
Resolution: Fixed
> Add timeouts to the test plugin
> ---
>
> Key: MPTEST-10
> URL: http://jira.codehaus.org/browse/MPTEST-10
> Project: maven-test-plugin
> Type: Improvement
> Reporter: Julian Payne
> Fix For: 1.8
>
>
> I need to be able to set a timeout in the unit tests because we have
> graphical tests that block from time to time.
> Here is what I would like to be added in the plugin.jelly as part of the
> junit element:
>failureProperty="maven.test.failure"
> fork="${maven.junit.fork}"
> dir="${maven.junit.dir}">
>
>
>
>
>
--
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: (MCLOVER-21) License discovery is broken
[ http://jira.codehaus.org/browse/MCLOVER-21?page=comments#action_61893 ] Vincent Massol commented on MCLOVER-21: --- Hi Matthew, The cenqua documentation refers to Clover. Here you're talking about the Clover plugin for maven2 which is a different beast. It has its own license discovery mechanism. The current way to pass a license is to use the LicenseFile element as you mentioned. I'm curious to understand why you think this it not good. BTW the clover jar is located in the local maven repository and AFAIK there's no license artifact type. I agree that we could possibly have that implemented and put it in the repository. Feel free to provide a patch for this. However I'd like to close this issue as license discovery is not "broken"! :-) > License discovery is broken > --- > > Key: MCLOVER-21 > URL: http://jira.codehaus.org/browse/MCLOVER-21 > Project: Maven 2.x Clover Plugin > Type: Bug > Versions: 2.0 > Reporter: Matthew Beermann > Priority: Critical > Fix For: 2.1 > > > Even when a valid, unexpired "clover.license" is located alongside the clover > jar, it does not appear to be located and used as Cenqua's documentation says > it should. In the example below, the directory contains a "clover.license" > that is known to work properly with the Clover plugin in Maven 1. > Yes, there is a configuration parameter that can work around > this, but that doesn't address the underlying problem (and furthermore the > fix isn't particularly portable). > [INFO] [clover:instrument] > Clover Version 1.3.11, built on November 02 2005 > loaded from: C:\maven\local_repository\clover\clover\1.3.11\clover-1.3.11.jar > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] This license has now expired. > [INFO] > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (CONTINUUM-639) Rebuild not triggered when svn repository change consists of a single file deletion
Rebuild not triggered when svn repository change consists of a single file deletion --- Key: CONTINUUM-639 URL: http://jira.codehaus.org/browse/CONTINUUM-639 Project: Continuum Type: Bug Components: Core system Versions: 1.0.2 Environment: Continuum 1.3-SNAPSHOT (RC 1) Java 5.0 Update 6 Windows XP SP2 Subversion 1.3.0 Reporter: Mark Reynolds Here is a continuum log snippet after I deleted a single file from my subversion repository. INFO | jvm 1| 2006/03/24 12:02:31 | 2006-03-24 12:02:31,342 [defaultScheduler_Worker-12] INFO SchedulesActivator - > Executing build job (DEFAULT_SCHEDULE)... INFO | jvm 1| 2006/03/24 12:02:31 | 2006-03-24 12:02:31,342 [defaultScheduler_Worker-12] INFO ContinuumStore:jdo - nb result : 3 INFO | jvm 1| 2006/03/24 12:02:31 | 2006-03-24 12:02:31,514 [Thread-1] INFO ContinuumScm - Updating project: id: '3', name 'Apreso Content Manager Web App'. INFO | jvm 1| 2006/03/24 12:02:31 | 2006-03-24 12:02:31,545 [Thread-1] INFO ScmManager - Executing: svn --non-interactive update INFO | jvm 1| 2006/03/24 12:02:31 | 2006-03-24 12:02:31,545 [Thread-1] INFO ScmManager - Working directory: C:\continuum\working-directory\3 INFO | jvm 1| 2006/03/24 12:02:31 | 2006-03-24 12:02:31,749 [defaultScheduler_Worker-12] INFO Continuum - Enqueuing 'Apreso Content Manager Web App' (Build definition id=3). INFO | jvm 1| 2006/03/24 12:02:31 | 2006-03-24 12:02:31,827 [defaultScheduler_Worker-3] INFO SchedulesActivator - > Executing build job (DEFAULT_SCHEDULE)... INFO | jvm 1| 2006/03/24 12:02:31 | 2006-03-24 12:02:31,827 [defaultScheduler_Worker-3] INFO ContinuumStore:jdo - nb result : 3 INFO | jvm 1| 2006/03/24 12:02:32 | 2006-03-24 12:02:32,108 [Thread-51624] DEBUG ScmManager - At revision 3114. INFO | jvm 1| 2006/03/24 12:02:32 | 2006-03-24 12:02:32,186 [Thread-1] INFO BuildController- The project was not built because all changes are unknown. INFO | jvm 1| 2006/03/24 12:02:32 | 2006-03-24 12:02:32,483 [Thread-1] INFO ContinuumScm - Updating project: id: '1', name 'Apreso Content Manager'. INFO | jvm 1| 2006/03/24 12:02:32 | 2006-03-24 12:02:32,515 [Thread-1] INFO ScmManager - Executing: svn --non-interactive update INFO | jvm 1| 2006/03/24 12:02:32 | 2006-03-24 12:02:32,515 [Thread-1] INFO ScmManager - Working directory: C:\continuum\working-directory\1 INFO | jvm 1| 2006/03/24 12:02:33 | 2006-03-24 12:02:33,109 [Thread-51626] DEBUG ScmManager - D acm-lib\src\test\java\com\anystream\acm\service\TestLocationService.java INFO | jvm 1| 2006/03/24 12:02:33 | 2006-03-24 12:02:33,109 [Thread-51626] DEBUG ScmManager - Skipping non-file: acm-lib\src\test\java\com\anystream\acm\service\TestLocationService.java INFO | jvm 1| 2006/03/24 12:02:33 | 2006-03-24 12:02:33,109 [Thread-51626] DEBUG ScmManager - Updated to revision 3114. INFO | jvm 1| 2006/03/24 12:02:33 | 2006-03-24 12:02:33,187 [Thread-1] INFO BuildController- The project was not built because all changes are unknown. INFO | jvm 1| 2006/03/24 12:02:33 | 2006-03-24 12:02:33,484 [Thread-1] INFO ContinuumScm - Updating project: id: '2', name 'Apreso Content Manager Library'. INFO | jvm 1| 2006/03/24 12:02:33 | 2006-03-24 12:02:33,500 [Thread-1] INFO ScmManager - Executing: svn --non-interactive update INFO | jvm 1| 2006/03/24 12:02:33 | 2006-03-24 12:02:33,500 [Thread-1] INFO ScmManager - Working directory: C:\continuum\working-directory\2 INFO | jvm 1| 2006/03/24 12:02:34 | 2006-03-24 12:02:34,109 [Thread-51628] DEBUG ScmManager - D src\test\java\com\anystream\acm\service\TestLocationService.java INFO | jvm 1| 2006/03/24 12:02:34 | 2006-03-24 12:02:34,109 [Thread-51628] DEBUG ScmManager - Skipping non-file: src\test\java\com\anystream\acm\service\TestLocationService.java INFO | jvm 1| 2006/03/24 12:02:34 | 2006-03-24 12:02:34,109 [Thread-51628] DEBUG ScmManager - Updated to revision 3114. INFO | jvm 1| 2006/03/24 12:02:34 | 2006-03-24 12:02:34,187 [Thread-1] INFO BuildController- The project was not built because all changes are unknown. INFO | jvm 1| 2006/03/24 12:02:34 | 2006-03-24 12:02:34,516 [Thread-1] INFO ContinuumScm - Updating project: id: '3', name 'Apreso Content Manager Web App'. INFO | jvm 1| 2006/03/24 12:02:34 |
[jira] Closed: (CONTINUUM-637) If two build definitions with same schedule, only first is executed
[ http://jira.codehaus.org/browse/CONTINUUM-637?page=all ] Emmanuel Venisse closed CONTINUUM-637: -- Assign To: Emmanuel Venisse Resolution: Fixed Fixed. > If two build definitions with same schedule, only first is executed > --- > > Key: CONTINUUM-637 > URL: http://jira.codehaus.org/browse/CONTINUUM-637 > Project: Continuum > Type: Bug > Components: Core system > Versions: 1.0.3 > Environment: continuum-20060324.02 > Reporter: Yann Le Du > Assignee: Emmanuel Venisse > Fix For: 1.0.3 > > > A project has two build definitions with the same schedule : > Definition 1 : clean site-deploy - DEFAULT_SCHEDULE > Definition 2 : clean install - DEFAULT_SCHEDULE (default build definition) > Only Definition 1 is executed. > According to Emmanuel Venisse, Definition 2 is launched but without changes, > so it doesn't run the build. -- 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: (CONTINUUM-636) Multiple build definitions pr project makes no sense
[ http://jira.codehaus.org/browse/CONTINUUM-636?page=all ] Emmanuel Venisse closed CONTINUUM-636: -- Assign To: Emmanuel Venisse Resolution: Fixed Fix Version: 1.0.3 You can now assign several build definition to a project and scm activity will be found from last execution of current build definition and not an other. > Multiple build definitions pr project makes no sense > > > Key: CONTINUUM-636 > URL: http://jira.codehaus.org/browse/CONTINUUM-636 > Project: Continuum > Type: Improvement > Reporter: Jarl Petter Kvalsvik > Assignee: Emmanuel Venisse > Fix For: 1.0.3 > > > In my Continuum setup I want to run contiluous builds during daytime and once > every night I want to also create extensive reports. > It is a problem that if I create several build definitions these share SCM > state and thus will prevent each other from running. > In my scenario the daytime build will run fine, but since there is no SCM > activity between the last daytime build and the nightly build, the nightly > build will be skipped (becaus no SCM changes are detected). > I would have preferred that unique "project numbers" are assigned to a build > definition to prevent sharing of SCM state. -- 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: (CONTINUUM-639) Rebuild not triggered when svn repository change consists of a single file deletion
[ http://jira.codehaus.org/browse/CONTINUUM-639?page=comments#action_61897 ] Mark Reynolds commented on CONTINUUM-639: - Oops, that is Continuum 1.0.3-SNAPSHOT (RC 1) > Rebuild not triggered when svn repository change consists of a single file > deletion > --- > > Key: CONTINUUM-639 > URL: http://jira.codehaus.org/browse/CONTINUUM-639 > Project: Continuum > Type: Bug > Components: Core system > Versions: 1.0.2 > Environment: Continuum 1.3-SNAPSHOT (RC 1) > Java 5.0 Update 6 > Windows XP SP2 > Subversion 1.3.0 > Reporter: Mark Reynolds > > > Here is a continuum log snippet after I deleted a single file from my > subversion repository. > INFO | jvm 1| 2006/03/24 12:02:31 | 2006-03-24 12:02:31,342 > [defaultScheduler_Worker-12] INFO SchedulesActivator - > > Executing build job (DEFAULT_SCHEDULE)... > INFO | jvm 1| 2006/03/24 12:02:31 | 2006-03-24 12:02:31,342 > [defaultScheduler_Worker-12] INFO ContinuumStore:jdo - nb result > : 3 > INFO | jvm 1| 2006/03/24 12:02:31 | 2006-03-24 12:02:31,514 [Thread-1] > INFO ContinuumScm - Updating project: id: '3', name > 'Apreso Content Manager Web App'. > INFO | jvm 1| 2006/03/24 12:02:31 | 2006-03-24 12:02:31,545 [Thread-1] > INFO ScmManager - Executing: svn --non-interactive update > INFO | jvm 1| 2006/03/24 12:02:31 | 2006-03-24 12:02:31,545 [Thread-1] > INFO ScmManager - Working directory: > C:\continuum\working-directory\3 > INFO | jvm 1| 2006/03/24 12:02:31 | 2006-03-24 12:02:31,749 > [defaultScheduler_Worker-12] INFO Continuum - Enqueuing > 'Apreso Content Manager Web App' (Build definition id=3). > INFO | jvm 1| 2006/03/24 12:02:31 | 2006-03-24 12:02:31,827 > [defaultScheduler_Worker-3] INFO SchedulesActivator - > > Executing build job (DEFAULT_SCHEDULE)... > INFO | jvm 1| 2006/03/24 12:02:31 | 2006-03-24 12:02:31,827 > [defaultScheduler_Worker-3] INFO ContinuumStore:jdo - nb result > : 3 > INFO | jvm 1| 2006/03/24 12:02:32 | 2006-03-24 12:02:32,108 > [Thread-51624] DEBUG ScmManager - At revision 3114. > INFO | jvm 1| 2006/03/24 12:02:32 | 2006-03-24 12:02:32,186 [Thread-1] > INFO BuildController- The project was not built because all > changes are unknown. > INFO | jvm 1| 2006/03/24 12:02:32 | 2006-03-24 12:02:32,483 [Thread-1] > INFO ContinuumScm - Updating project: id: '1', name > 'Apreso Content Manager'. > INFO | jvm 1| 2006/03/24 12:02:32 | 2006-03-24 12:02:32,515 [Thread-1] > INFO ScmManager - Executing: svn --non-interactive update > INFO | jvm 1| 2006/03/24 12:02:32 | 2006-03-24 12:02:32,515 [Thread-1] > INFO ScmManager - Working directory: > C:\continuum\working-directory\1 > INFO | jvm 1| 2006/03/24 12:02:33 | 2006-03-24 12:02:33,109 > [Thread-51626] DEBUG ScmManager - D > acm-lib\src\test\java\com\anystream\acm\service\TestLocationService.java > INFO | jvm 1| 2006/03/24 12:02:33 | 2006-03-24 12:02:33,109 > [Thread-51626] DEBUG ScmManager - Skipping non-file: > acm-lib\src\test\java\com\anystream\acm\service\TestLocationService.java > INFO | jvm 1| 2006/03/24 12:02:33 | 2006-03-24 12:02:33,109 > [Thread-51626] DEBUG ScmManager - Updated to revision > 3114. > INFO | jvm 1| 2006/03/24 12:02:33 | 2006-03-24 12:02:33,187 [Thread-1] > INFO BuildController- The project was not built because all > changes are unknown. > INFO | jvm 1| 2006/03/24 12:02:33 | 2006-03-24 12:02:33,484 [Thread-1] > INFO ContinuumScm - Updating project: id: '2', name > 'Apreso Content Manager Library'. > INFO | jvm 1| 2006/03/24 12:02:33 | 2006-03-24 12:02:33,500 [Thread-1] > INFO ScmManager - Executing: svn --non-interactive update > INFO | jvm 1| 2006/03/24 12:02:33 | 2006-03-24 12:02:33,500 [Thread-1] > INFO ScmManager - Working directory: > C:\continuum\working-directory\2 > INFO | jvm 1| 2006/03/24 12:02:34 | 2006-03-24 12:02:34,109 > [Thread-51628] DEBUG ScmManager - D > src\test\java\com\anystream\acm\service\TestLocationService.java > INFO | jvm 1| 2006/03/24 12:02:34 | 2006-03-24 12:02:34,109 > [Thread-51628] DEBUG ScmManager - Skipping non-file: > src\test\java\com\anystream\acm\service\TestLocationService.java > INFO | jvm 1| 2006/03/24 12:02:34 | 2006-03-24 12:02:34,109 > [Thread-51628] DEBUG ScmManager - Updated to revision > 3114. > INFO | jvm 1| 20
[jira] Closed: (MPTEST-36) Display a banner when all tests do not pass
[ http://jira.codehaus.org/browse/MPTEST-36?page=all ] Lukas Theussl closed MPTEST-36: --- Resolution: Fixed > Display a banner when all tests do not pass > --- > > Key: MPTEST-36 > URL: http://jira.codehaus.org/browse/MPTEST-36 > Project: maven-test-plugin > Type: Improvement > Reporter: Michael Mattox > Assignee: Lukas Theussl > Priority: Trivial > Fix For: 1.8 > > > We spend a lot of time looking at the test results trying to see if there are > any failures. If maven would print a banner saying something like "TEST > FAILURES EXIST" that would greatly help us to see if all tests passed or not. -- 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: (MASSEMBLY-45) Support for mappers in assembly desriptors
[ http://jira.codehaus.org/browse/MASSEMBLY-45?page=comments#action_61902 ] Prasad Kashyap commented on MASSEMBLY-45: - Geronimo is currently evaluating the usage of this plugin for assembling it's binary distribution. This is one of the much required features. > Support for mappers in assembly desriptors > -- > > Key: MASSEMBLY-45 > URL: http://jira.codehaus.org/browse/MASSEMBLY-45 > Project: Maven 2.x Assembly Plugin > Type: Bug > Reporter: Anuerin Diaz > > > I would like to forward a wish to have the assembly plugin support the notion > of file mappers similar to the ones in Ant[1]. To illustrate, assuming a > multi-module project with the following layout: > Root >|-Module1 >|-Module2 >|-Container >| |-Module3 >| |-Module4 >|-Module5 >|- pom.xml > and an assembly desriptor entry for the contained modules like this > > > Container > > > **/target/*.jar > > > > The assembly plugin will be able to get all jar files produced by Module3 and > Module4 but the "Container//target" structure will still be > included. One workaround is to enumerate each artifact but > problematic if the number of contained sub-modules is numerous. Support for > filemappers which look like this: > > > Container > > > **/target/*.jar > > > > > will cause all contained jar files to be copied without their original > structure. This feature would be useful for globbing artifact names as well > as for physically organizing project structures according to type. > [1] http://ant.apache.org/manual/CoreTypes/mapper.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-41) Enable wilcards in dependency set includes/excludes
[ http://jira.codehaus.org/browse/MASSEMBLY-41?page=comments#action_61903 ] Prasad Kashyap commented on MASSEMBLY-41: - This is another good requirement that will help Geronimo use the maven-assembly-plugin. > Enable wilcards in dependency set includes/excludes > --- > > Key: MASSEMBLY-41 > URL: http://jira.codehaus.org/browse/MASSEMBLY-41 > Project: Maven 2.x Assembly Plugin > Type: Bug > Reporter: Filip Vuksanovic > > > Wildcards can't be used in dependency set includes/excludes inside assembly > descriptor. > >my-assembly > > jar > >false > > >/ >true >runtime > > groupId:artifactId > > > > > It should at least support something like groupId:*. -- 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: (MNGECLIPSE-93) Choosing goal from Goals... dialog in Run Configuration appends to existing goal creating invalid goal
[ http://jira.codehaus.org/browse/MNGECLIPSE-93?page=comments#action_61904 ] Bill Siggelkow commented on MNGECLIPSE-93: -- Well, since I can manually enter goals in the free text area separated by a space, and maven will process them appropriately; then it seems that an easy solution to this, albeit minor problem, would be to ensure that a space (or other appropriate delimiter) is inserted before/after the goal as needed. That way, I could pick 'compile' and then pick 'package' ... similar to the way that you can select multiple targets in the Ant view. > Choosing goal from Goals... dialog in Run Configuration appends to existing > goal creating invalid goal > -- > > Key: MNGECLIPSE-93 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-93 > Project: Maven 2.x Extension for Eclipse > Type: Bug > Components: Maven Launcher > Versions: 0.0.5 > Environment: Mac OS/X 10.4.4 > Reporter: Bill Siggelkow > Assignee: Dmitri Maximovich > Priority: Minor > > > This behavior occurs when you select Run > External Tools ... and pick a m2 > run configuration. If I select a goal from the Goals... dialog and there is > already a goal (e.g. compile) listed in the text field, the new selected goal > is appended to the text (creating a goal of, for example, compilepackage) of > the current goal. It seems like it should replace the text instead. -- 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: (MJAR-5) no Implementation-Vendor-Id in META-INF/MANIFEST.MF
[ http://jira.codehaus.org/browse/MJAR-5?page=comments#action_61905 ] Stephane Nicoll commented on MJAR-5: What about a configuration property of the JavaMojo with the groupId as default? > no Implementation-Vendor-Id in META-INF/MANIFEST.MF > --- > > Key: MJAR-5 > URL: http://jira.codehaus.org/browse/MJAR-5 > Project: Maven 2.x Jar Plugin > Type: Bug > Environment: Linux 2.6.12-9-386 Kubuntu java version "1.4.2-02" > Reporter: Pascal Grange > Priority: Blocker > > > mvn package does not generate an entry "Implementation-Vendor-Id". This is a > blocker when we use the extension mechanisme with tomcat. -- 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: (MCLOVER-21) License discovery is broken
[ http://jira.codehaus.org/browse/MCLOVER-21?page=comments#action_61907 ] Matthew Beermann commented on MCLOVER-21: - In Maven 1, to install a license file, it was sufficient to drop it into the local repository next to clover.jar. This does not work in Maven 2. It was very convenient, and I'd like it back. Can you morph this issue into an enhancement request along those lines (or file a new one), and I'll have a look at the source code? > License discovery is broken > --- > > Key: MCLOVER-21 > URL: http://jira.codehaus.org/browse/MCLOVER-21 > Project: Maven 2.x Clover Plugin > Type: Bug > Versions: 2.0 > Reporter: Matthew Beermann > Priority: Critical > Fix For: 2.1 > > > Even when a valid, unexpired "clover.license" is located alongside the clover > jar, it does not appear to be located and used as Cenqua's documentation says > it should. In the example below, the directory contains a "clover.license" > that is known to work properly with the Clover plugin in Maven 1. > Yes, there is a configuration parameter that can work around > this, but that doesn't address the underlying problem (and furthermore the > fix isn't particularly portable). > [INFO] [clover:instrument] > Clover Version 1.3.11, built on November 02 2005 > loaded from: C:\maven\local_repository\clover\clover\1.3.11\clover-1.3.11.jar > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] This license has now expired. > [INFO] > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MJXR-8) add option to disable test Xref
[ http://jira.codehaus.org/browse/MJXR-8?page=all ] Jesse McConnell updated MJXR-8: --- Attachment: mjxr-8.patch > add option to disable test Xref > --- > > Key: MJXR-8 > URL: http://jira.codehaus.org/browse/MJXR-8 > Project: Maven 2.x JXR Plugin > Type: New Feature > Reporter: Brett Porter > Fix For: 2.0 > Attachments: mjxr-8.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
[jira] Updated: (MECLIPSE-78) create eclipse projects which are m2eclipse ready
[ http://jira.codehaus.org/browse/MECLIPSE-78?page=all ] Joshua Nichols updated MECLIPSE-78: --- Attachment: m2eclipse.patch > create eclipse projects which are m2eclipse ready > - > > Key: MECLIPSE-78 > URL: http://jira.codehaus.org/browse/MECLIPSE-78 > Project: Maven 2.x Eclipse Plugin > Type: New Feature > Environment: Fedora Core 3, Sun JDK 1.5.0.06, Eclipse 3.1.1, Maven 2.0.2 > Reporter: Joshua Nichols > Attachments: m2eclipse.patch, m2eclipse.patch > > > WIth the recent development of the m2eclipse plugin, I believe it is useful > to create eclipse projects via mvn eclipse:eclipse that use m2eclipse from > the start. One of the advantages of using m2eclipse is that you don't have to > rerun eclipse:eclipse when you update any dependencies. > A few things are necessary to accomplish this, in terms of changes to > .classpath and .project. > .project needs a new nature and builder added. For the builder: > > org.maven.ide.eclipse.maven2Builder > > > For the nature: > org.maven.ide.eclipse.maven2Nature > In the .classpath, we need to add: >path="org.maven.ide.eclipse.MAVEN2_CLASSPATH_CONTAINER"/> > In .classpath, you also don't want entries path="M2_REPO/blah/blah/x.y.z/blah-x.y.z.jar"/>, because they would conflict > with m2eclipse setting up 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
[jira] Updated: (MCLEAN-8) conversion of the existing unit tests to use the AbstractMojoTestCase from the plugin testing harness
[ http://jira.codehaus.org/browse/MCLEAN-8?page=all ] Jesse McConnell updated MCLEAN-8: - Attachment: maven-clean-harness-2.patch > conversion of the existing unit tests to use the AbstractMojoTestCase from > the plugin testing harness > - > > Key: MCLEAN-8 > URL: http://jira.codehaus.org/browse/MCLEAN-8 > Project: Maven 2.x Clean Plugin > Type: Improvement > Reporter: Jesse McConnell > Attachments: maven-clean-harness-2.patch, maven-clean-harness.patch > > > This is the patch for that I am hoping are best practices in using the plugin > testing harness as mentioned in MNG-32 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-967) maven.mdo, settings.mdo, and generated-sources
[ http://jira.codehaus.org/browse/MNG-967?page=all ] Brett Porter updated MNG-967: - Reporter: Jesse McConnell (was: Jesse McConnell) > maven.mdo, settings.mdo, and generated-sources > -- > > Key: MNG-967 > URL: http://jira.codehaus.org/browse/MNG-967 > Project: Maven 2 > Type: Bug > Components: POM > Reporter: Jesse McConnell > Priority: Trivial > Fix For: 2.0.4 > > > a nice trivial issue... > maven-components/maven-settings/settings.mdo > maven-components/maven-model/maven.mdo > those ought to be in src/main/modello > and they ought to be generating their source to > target/generated-sources/modello > they are currently generating to > target/generated-sources -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-756) error updating poms that should exist in the project hierarchy
[ http://jira.codehaus.org/browse/MNG-756?page=all ] Brett Porter updated MNG-756: - Reporter: Jesse McConnell (was: Jesse McConnell) > error updating poms that should exist in the project hierarchy > -- > > Key: MNG-756 > URL: http://jira.codehaus.org/browse/MNG-756 > Project: Maven 2 > Type: Bug > Components: Inheritence and Interpolation > Reporter: Jesse McConnell > > > I noticed this the other day and brett mentioned he saw it from time to time > as well. > basically, I start a process in a subproject first thing in the morning and I > start getting exceptions in trying to find POM files from repositories when > it is not a pom that _will_ be anywhere other then in the existing project > hierarchy. > my setup that is triggering this is: > root/pom > root/cli/pom > root/core/pom > subpoms both have the root pom as the parent. > I'll note that I did include the exception from not being able to find the > maven-execute-plugin from anywhere since that isn't in either of the places > and I generally ignore it, but it I figured I would add it to this in case it > was related in anyway. halfway through you'll see the reference to the > gallup:g:1.0 artifact which is the interesting one. How can a child _not_ > know that the parent isn't going to be on a webserver but locally? I would > think this kinda stuff will generate a substantial amount of bad traffic to > the main repos. > This is what my logs show: (-X didn't yield anything different) > ideation]g-maven/g-cli>m2 -Dexecute.class="com.gallup.net.URLTester" > -Dexecute.args="https://svn.gallup.com/svn/g-maven/trunk/pom.xml"; > execute:resources > [INFO] Retrieving plugins.xml (plugin mappings) for group: > 'org.apache.maven.plugins' > [INFO] Retrieving plugins.xml (plugin mappings) for group: > 'org.apache.maven.plugins' > [INFO] Refreshing plugin mapping metadata; looking for plugin with prefix: > 'execute'. > [INFO] Refreshing plugin-mapping metadata... > [INFO] maven-execute-plugin: updating metadata due to status of 'deployed' > Downloading: > http://maven.gallup.com/plugins-repository/org/apache/maven/plugins/maven-execute-plugin/0.1/maven-execute-plugin-0.1.pom > [WARNING] Unable to get resource from repository > http://maven.gallup.com/plugins-repository > Downloading: > http://repo1.maven.org/maven2/plugins/org/apache/maven/plugins/maven-execute-plugin/0.1/maven-execute-plugin-0.1.pom > [WARNING] Unable to get resource from repository > http://repo1.maven.org/maven2/plugins > [WARNING] Error updating POM - using existing version > org.apache.maven.artifact.resolver.ArtifactResolutionException: Unable to > download the artifact from any repository > org.apache.maven.plugins:maven-execute-plugin:0.1:pom > from the specified remote repositories: > http://maven.gallup.com/plugins-repository, > http://repo1.maven.org/maven2/plugins > at > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:132) > at > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveAlways(DefaultArtifactResolver.java:69) > at > org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepository(DefaultMavenProjectBuilder.java:348) > at > org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:303) > at > org.apache.maven.plugin.DefaultPluginManager.checkRequiredMavenVersion(DefaultPluginManager.java:252) > at > org.apache.maven.plugin.DefaultPluginManager.verifyPlugin(DefaultPluginManager.java:198) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.getMojoDescriptor(DefaultLifecycleExecutor.java:986) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.segmentTaskListByAggregationNeeds(DefaultLifecycleExecutor.java:366) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:108) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:186) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:316) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > Caused by: org.apache.maven.wagon.ResourceDoesNotExistException: Unable to > download the artifact from any repository >
[jira] Updated: (MNG-772) maven-eclipse-plugin NPE during writing setting file.
[ http://jira.codehaus.org/browse/MNG-772?page=all ] Brett Porter updated MNG-772: - Reporter: Jesse McConnell (was: Jesse McConnell) > maven-eclipse-plugin NPE during writing setting file. > - > > Key: MNG-772 > URL: http://jira.codehaus.org/browse/MNG-772 > Project: Maven 2 > Type: Bug > Reporter: Jesse McConnell > Assignee: Kenney Westerhof > Fix For: 2.0-beta-1 > Attachments: eclipse-plugin.patch > > > the maven eclipse plugin was certain that if the maven-compiler-plugin was > mentioned in the artifacts list that it would have source and target values > defined. > > maven-compiler-plugin > >iso-8859-1 > > > I don't and the eclipse plugin was blowing up with a NPE for this. > I patched it to check for the child Xpp3Dom objects to actually exist before > trying to get their values, which was the cause of the NPE. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-681) Plugin Utility Class
[ http://jira.codehaus.org/browse/MNG-681?page=all ] Brett Porter updated MNG-681: - Reporter: Jesse McConnell (was: Jesse McConnell) > Plugin Utility Class > > > Key: MNG-681 > URL: http://jira.codehaus.org/browse/MNG-681 > Project: Maven 2 > Type: New Feature > Components: Plugin API > Versions: 2.0-alpha-3 > Reporter: Jesse McConnell > Priority: Minor > > > Tryg mentioned that we might want to make a plugins utility class for some of > the issues I ran into implementing a mess of a plugin. > the plugin was pinned into the process-classes phase and generated a source > file which needed to be compiled > 1) I needed to have the classes that were compiled in the compile phase in my > classpath for the plugin. my way around this was to make a URLClassLoader > pointed at the compiled classes. The classes I was processing all used one > of two interfaces and it would have been nice to have those interfaces > available to cast the new instances of the classes and call a method > directly. reflection served the purpose though > 2) I needed to compile the freshly generated source file, so I ripped a mess > of code from the maven compiler plugin to achieve this > two examples of things that would be nice to have a cleaner method of > achieving the same results..if you think it is a good idea I can generalize > what I did into a couple of api's I think. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-603) sablecc plugin
[ http://jira.codehaus.org/browse/MNG-603?page=all ] Brett Porter updated MNG-603: - Reporter: Jesse McConnell (was: Jesse McConnell) > sablecc plugin > -- > > Key: MNG-603 > URL: http://jira.codehaus.org/browse/MNG-603 > Project: Maven 2 > Type: Improvement > Reporter: Jesse McConnell > Attachments: maven-sablecc-plugin.tar, maven-sablecc-plugin.v2.tar, > maven-sablecc-plugin.v3.tar > > > added a sablecc plugin which can be used like this: > > maven-sablecc-plugin > 1.0-SNAPSHOT > >expressions.grammar, aicc.grammar > > > > generate-sources > > generate > > > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-602) tweak MojoExecutionException to use Throwable as opposed to Exception
[ http://jira.codehaus.org/browse/MNG-602?page=all ] Brett Porter updated MNG-602: - Reporter: Jesse McConnell (was: Jesse McConnell) > tweak MojoExecutionException to use Throwable as opposed to Exception > - > > Key: MNG-602 > URL: http://jira.codehaus.org/browse/MNG-602 > Project: Maven 2 > Type: Bug > Reporter: Jesse McConnell > Fix For: 2.0-beta-1 > Attachments: throwable.patch > > > some unfortunate things like sablecc toss Throwable so we need a clean way to > catching those and returning the MojoExecutionException in plugins -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-849) plugins that add source roots ignored under certain circumstances
[ http://jira.codehaus.org/browse/MNG-849?page=all ] Brett Porter updated MNG-849: - Reporter: Jesse McConnell (was: Jesse McConnell) > plugins that add source roots ignored under certain circumstances > - > > Key: MNG-849 > URL: http://jira.codehaus.org/browse/MNG-849 > Project: Maven 2 > Type: Bug > Reporter: Jesse McConnell > Assignee: Brett Porter > > > kenney and I talked about this on irc for a while...here is a rundown.. > Use Case 1: > when working on my file activator for profiles I use the idea of checking for > a file that is missing and if it is missing then activate the profile, which > contains a plugin that generates the source file I want to > compile...originally I was pointing at the generated java file > so for the initial execution the profile is activated and the compile source > root is added to the mix of things to compile > however, after that should the build have failed and that file not have been > compiled it will not be compiled from that point forward since that the file > the profile was checking for did exist, just not the compiled class file > version of it. > so I switched it over to activate if the classfile didn't exist. > well at that point I was just running > m2 compiler:compile which ends up > bypassing the profile activation and not adding the compile source > rootand since the original source files require that generated class to > compile against the build is broken until there is a clean:clean and that > profile is activated again. > Use Case 2: > this cropped up right after the discussion on the profile activation...dozer > was using >m2 javadoc:javadoc to generate javadocs for a mess of generated > classes but they were not getting picked up...since that generated source > root was not readily apparent to the javadoc plugin when it was executed > directly outside of the context of the normal lifecycle where such things > ought to be set in the normal course of events. > Breakdown: > the thought here is that when a plugin is executed outside of the normal > lifecycle it doesn't have the full context of the lifecycle in terms of > compile source roots > now it could be that this isn't something that m2 should deal with, instead > leaving the onus onto the plugin writers to provide configuration options to > the plugins to support the users mentioning what source roots to use here and > there...and at least in the example of the profile there are lots of > different ways I could have done it...I chose that route to give profiles a > bit of a workout. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-821) file existence profile activation patch
[ http://jira.codehaus.org/browse/MNG-821?page=all ] Brett Porter updated MNG-821: - Reporter: Jesse McConnell (was: Jesse McConnell) > file existence profile activation patch > --- > > Key: MNG-821 > URL: http://jira.codehaus.org/browse/MNG-821 > Project: Maven 2 > Type: New Feature > Components: Inheritence and Interpolation, POM > Versions: 2.0-beta-1 > Reporter: Jesse McConnell > Assignee: Brett Porter > Fix For: 2.0-beta-1 > Attachments: file-existence-profile-activation.patch, > file-profile-activation.patch > > > > classnames > > > > target/generated-sources/classname-generator/com/stuff/util/GClassnameProvider.java > > > > also is a valid tag inside that as well. > The problem with this patch atm is that it ceases to work outside of the > context of the subproject it exists in.. > this is because in the FileExistenceProfileActivator we have no mechanism of > getting the absolute path for that file string. > I looked into BuildBase object that you can get from the Profile passed in > but it is empty (null) and the string doesn't resolve expressions either... > so...if I can get pointed in the right direction for adding that expression > resolution in there I'll put that in...talked to kenney about this a bit on > irc this morning as well and he seemed to think that was probably the way to > go. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CONTINUUM-258) https:// doesn't seem to be a supported mechanism for referencing a pom
[ http://jira.codehaus.org/browse/CONTINUUM-258?page=all ] Brett Porter updated CONTINUUM-258: --- Reporter: Jesse McConnell (was: Jesse McConnell) > https:// doesn't seem to be a supported mechanism for referencing a pom > --- > > Key: CONTINUUM-258 > URL: http://jira.codehaus.org/browse/CONTINUUM-258 > Project: Continuum > Type: Bug > Components: Web interface > Reporter: Jesse McConnell > Fix For: 1.0-alpha-4 > Attachments: MungedHttpsURL.java, secure-url-continuum-api.patch, > secure-url-continuum-core.patch, secure-url-continuum-pre.patch, > secure-url-plexus.patch, secure-url-validation.patch > > > I have a svn repository setup with https:// certificate and AD LDAP password > authentication... > would be real nice to be able to point to a pom with > https://svn.company.com/svn/g-maven-plugins/trunk/pom.xml > and have it picked up. > right now it just grumbles about > Enter the URL to the Maven 2 POM[ The URL you provided doesn't exist ] > (in red even :) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MAVENUPLOAD-720) JavaCC 4.0
[ http://jira.codehaus.org/browse/MAVENUPLOAD-720?page=all ] Brett Porter updated MAVENUPLOAD-720: - Reporter: Jesse McConnell (was: Jesse McConnell) > JavaCC 4.0 > -- > > Key: MAVENUPLOAD-720 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-720 > Project: maven-upload-requests > Type: Task > Reporter: Jesse McConnell > Assignee: Carlos Sanchez > > > http://www.perendengue.com/stuff/javacc-4.0-bundle.jar > https://javacc.dev.java.net > javacc 4.0 release needed for updated javacc-maven-plugin to support java 5 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-595) patch for adding -encoding X to the javac
[ http://jira.codehaus.org/browse/MNG-595?page=all ] Brett Porter updated MNG-595: - Reporter: Jesse McConnell (was: Jesse McConnell) > patch for adding -encoding X to the javac > - > > Key: MNG-595 > URL: http://jira.codehaus.org/browse/MNG-595 > Project: Maven 2 > Type: Improvement > Reporter: Jesse McConnell > Assignee: Brett Porter > Fix For: 2.0-beta-1 > Attachments: patch > > > for maven-compiler-plugin > supports this now: > > > > maven-compiler-plugin > >utf8 > > > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-725) pom dependencies not added to compile Classpath
[ http://jira.codehaus.org/browse/MNG-725?page=all ] Brett Porter updated MNG-725: - Reporter: Jesse McConnell (was: Jesse McConnell) > pom dependencies not added to compile Classpath > --- > > Key: MNG-725 > URL: http://jira.codehaus.org/browse/MNG-725 > Project: Maven 2 > Type: Bug > Components: Artifacts and Repositories > Reporter: Jesse McConnell > Assignee: Brett Porter > > > I am trying to use a meta dependency pom file to lump several dependencies > together into one unit. > on the webserver I have > >4.0.0 >meta-dependency >oracle >pom >1.0 >oracle meta dependencies list > > > oracle > oracle > 9201 > provided > > > oracle > oracle_nls_charset > 9201.12 > provided > > > > in the local pom I have: > > meta-dependency > oracle > 1.0 > pom > > Note: I had to specify pom here otherwise it defaulted to trying to > find a .jar file for it even though the pom was specified in > the remote pom...this seemed redundent and unnecessary. In this case the > DEBUG showed it as oracle:jar:1.0 even though the remote pom was clearly in > my local repo and was the one from the server, not a default one like kenney > had mentioned might be the case on irc. > [DEBUG] xml-apis:xml-apis:jar:2.0.2 (selected for provided) > [DEBUG] meta-dependency:oracle:pom:1.0 (selected for compile) > [DEBUG] jclass:pagelayout:jar:5.0 (selected for provided) > that is the debug output from the compiler, I would expect to see the > dependencies in the remote pom listed just below the pom declaration. > I initially tried this with the subproject pom, and that was the same deal. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-1390) @requiresDependencyResolution in process-classes post compile
[ http://jira.codehaus.org/browse/MNG-1390?page=all ]
Brett Porter updated MNG-1390:
--
Reporter: Jesse McConnell (was: Jesse McConnell)
> @requiresDependencyResolution in process-classes post compile
> -
>
> Key: MNG-1390
> URL: http://jira.codehaus.org/browse/MNG-1390
> Project: Maven 2
> Type: Bug
> Components: Inheritence and Interpolation
> Versions: 2.0
> Reporter: Jesse McConnell
> Fix For: 2.0.4
>
> Original Estimate: 3 hours
> Remaining: 3 hours
>
> I was looking back into some plugins I had written a while back and ran
> across an oddity.
> it appears that when using a plugin in the process-classes phase, after the
> compiler plugin has done its thing, the @requiresDependencyResolution javadoc
> flag will toggle the presense of dependencies that are scoped to provided in
> the dependencies section when calling project.getCompileClasspathElements();
> (a difference of 80 vs 24 when not using the flag and then using it)
> ---
> this are two snippits of code from the plugin
> /**
> * A plugin for generating * java file containing all the classes in a src
> tree.
> *
> * @goal generate
> * @requiresDependencyResolution
> * @description Functions Generator plugin
> * @author jesse <[EMAIL PROTECTED]>
> */
>
>
>
> List classpathFiles = project.getCompileClasspathElements();
>
> URL[] urls = new URL[classpathFiles.size() + 1];
>
> getLog().debug("" + classpathFiles.size());
>
> for (int i = 0; i < classpathFiles.size(); ++i) {
> getLog().debug((String)classpathFiles.get(i));
> urls[i] = new File((String)classpathFiles.get(i)).toURL();
> }
>
> urls[classpathFiles.size()] = new File( buildDirectory + "/classes"
> ).toURL();
>
> URLClassLoader ucl = new URLClassLoader(urls,
> Thread.currentThread().getContextClassLoader());
> being used with the following plugin declaration:
>
> gallup.maven
> services-provider-maven-plugin
> 1.0.1
>
>
> com/g/util/ServiceProvider.java
>
>
>
> process-classes
>
> generate
>
>
>
>
>
> analyzing the debug output when I run the plugin without the
> @requiresDependencyResolution I get 80 dependencies and it builds out the
> classloader correctly..
> but if I add the @requiresDependencyResolution statement I go down to 24
> dependencies being put into the classloader...and the discrepency corresponds
> to the presense of the provided statement.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (MNG-741) new method: addResource( String directory, String includes, String excludes ) on MavenProject
[ http://jira.codehaus.org/browse/MNG-741?page=all ] Brett Porter updated MNG-741: - Reporter: Jesse McConnell (was: Jesse McConnell) > new method: addResource( String directory, String includes, String excludes ) > on MavenProject > - > > Key: MNG-741 > URL: http://jira.codehaus.org/browse/MNG-741 > Project: Maven 2 > Type: Improvement > Reporter: Jesse McConnell > Attachments: add_resource_maven_project.patch > > > in the sablecc plugin I have a case of *.dat files getting created that need > to get jared up with the actual project so I needed to add them as a resource > to the project...since the plugin developers should have to have a minimal > exposure to internals of maven I added this method to MavenProject as a > convience method...also means I have one less dependency that the plugin > itself needs to reference...whichever one model is a part of. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SUREFIRE-19) default excludes prevents inner class test cases
[ http://jira.codehaus.org/browse/SUREFIRE-19?page=all ] Brett Porter updated SUREFIRE-19: - Reporter: Jesse McConnell (was: Jesse McConnell) > default excludes prevents inner class test cases > > > Key: SUREFIRE-19 > URL: http://jira.codehaus.org/browse/SUREFIRE-19 > Project: surefire > Type: Bug > Versions: 1.4 > Reporter: Jesse McConnell > Assignee: Carlos Sanchez > Fix For: 1.5.2 > Attachments: maven-surefire-plugin.patch, surefire.patch > > > some people use inner classes for junit tests since they have access to > private variables in the unit tests. > for my particular case we have all unit tests called Foo$TEST > in the DirectoryBattery there was a default excludes that was _always_ > getting added to exclude inner classes...so the patch attached moves this > default exclusion to the listing of default excluders in the > maven-surefire-plugin and removed the forced exclusion. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (ARCHETYPE-8) example maven project architecture (jars, wars, ejbs, and an ear)
[ http://jira.codehaus.org/browse/ARCHETYPE-8?page=all ] Brett Porter updated ARCHETYPE-8: - Reporter: Jesse McConnell (was: Jesse McConnell) > example maven project architecture (jars, wars, ejbs, and an ear) > - > > Key: ARCHETYPE-8 > URL: http://jira.codehaus.org/browse/ARCHETYPE-8 > Project: Maven Archetype > Type: Improvement > Reporter: Jesse McConnell > Priority: Minor > Fix For: 2.0.1 > Attachments: maven-archetype-j2ee.jar, sample-m2-project.jar > > > someone on the mailing lists asked me for a working sample layout for a > project containing muliple source directories, nesting subprojects, servlets > in war files, ejbs, and ultimately into a ear file. > this is a small sample project, no source but it builds out all the > artifacts. also includes an example of dependencyManagement of versions at > the root pom file. > post comments and I'll make the changes if you want. anyway, on irc I said I > would make it and post it in an issue for review so here it is. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-727) missing dependency version error is vague
[ http://jira.codehaus.org/browse/MNG-727?page=all ] Brett Porter updated MNG-727: - Reporter: Jesse McConnell (was: Jesse McConnell) > missing dependency version error is vague > - > > Key: MNG-727 > URL: http://jira.codehaus.org/browse/MNG-727 > Project: Maven 2 > Type: Improvement > Reporter: Jesse McConnell > > > [INFO] Reason: Failed to validate POM for > '/home/jesse/src/g-maven/g-app/pom.xml'. > Reason(s): > [0] 'dependencies.dependency.version' is missing. > [1] 'dependencies.dependency.version' is missing. > [2] 'dependencies.dependency.version' is missing. > [3] 'dependencies.dependency.version' is missing. > [4] 'dependencies.dependency.version' is missing. > [5] 'dependencies.dependency.version' is missing. > [INFO] > > [INFO] Total time: < 1 second > [INFO] Finished at: Fri Aug 12 15:38:30 CDT 2005 > [INFO] Final Memory: 2M/41M > [INFO] > It would be really nice if this message told you the actual dependency that > was missing. -- 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: (MPASPECTJ-6) autoweave test code before running tests
[ http://jira.codehaus.org/browse/MPASPECTJ-6?page=comments#action_61921 ] Joshua White commented on MPASPECTJ-6: -- As of version 3.2, it seems that this fix has reversed itself. No matter where I put my aspect as a pregoal, it always seems to use the value of "maven.compile.src.set" for the value of "maven.test.compile.src.set". I am assuming that this is because it doesn't have access to the test plugin as referenced above. > autoweave test code before running tests > > > Key: MPASPECTJ-6 > URL: http://jira.codehaus.org/browse/MPASPECTJ-6 > Project: maven-aspectj-plugin > Type: Improvement > Environment: maven-1.0-rc1, WinXP, J2SE 1.4.2 > Reporter: John Fallows > Fix For: 3.1 > Attachments: aspectj-test.txt > > > I have recently started to use virtual mock objects > (http://www.virtualmock.org) that make heavy use of AspectJ in the test cases > of a maven project. > I noticed that the latest AspectJ plugin has support for autoweaving the > project sources, but not the test sources. > Once you have resolved how to weave the compiled classes instead of just the > JAR, how difficult would it be to autoweave the test classes 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
[jira] Reopened: (MPASPECTJ-6) autoweave test code before running tests
[ http://jira.codehaus.org/browse/MPASPECTJ-6?page=all ] Lukas Theussl reopened MPASPECTJ-6: --- > autoweave test code before running tests > > > Key: MPASPECTJ-6 > URL: http://jira.codehaus.org/browse/MPASPECTJ-6 > Project: maven-aspectj-plugin > Type: Improvement > Environment: maven-1.0-rc1, WinXP, J2SE 1.4.2 > Reporter: John Fallows > Fix For: 3.1 > Attachments: aspectj-test.txt > > > I have recently started to use virtual mock objects > (http://www.virtualmock.org) that make heavy use of AspectJ in the test cases > of a maven project. > I noticed that the latest AspectJ plugin has support for autoweaving the > project sources, but not the test sources. > Once you have resolved how to weave the compiled classes instead of just the > JAR, how difficult would it be to autoweave the test classes 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
[jira] Updated: (MPASPECTJ-6) autoweave test code before running tests
[ http://jira.codehaus.org/browse/MPASPECTJ-6?page=all ] Lukas Theussl updated MPASPECTJ-6: -- Fix Version: (was: 3.1) 4.0 > autoweave test code before running tests > > > Key: MPASPECTJ-6 > URL: http://jira.codehaus.org/browse/MPASPECTJ-6 > Project: maven-aspectj-plugin > Type: Improvement > Environment: maven-1.0-rc1, WinXP, J2SE 1.4.2 > Reporter: John Fallows > Fix For: 4.0 > Attachments: aspectj-test.txt > > > I have recently started to use virtual mock objects > (http://www.virtualmock.org) that make heavy use of AspectJ in the test cases > of a maven project. > I noticed that the latest AspectJ plugin has support for autoweaving the > project sources, but not the test sources. > Once you have resolved how to weave the compiled classes instead of just the > JAR, how difficult would it be to autoweave the test classes 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
[jira] Closed: (MPTEST-47) It should be possible to add additional elements to the test classpath
[ http://jira.codehaus.org/browse/MPTEST-47?page=all ]
Lukas Theussl closed MPTEST-47:
---
Assign To: Lukas Theussl
Resolution: Fixed
> It should be possible to add additional elements to the test classpath
> --
>
> Key: MPTEST-47
> URL: http://jira.codehaus.org/browse/MPTEST-47
> Project: maven-test-plugin
> Type: Improvement
> Environment: Java(TM) 2 Runtime Environment, Standard Edition (build
> 1.4.2_07-b05)
> Java HotSpot(TM) Client VM (build 1.4.2_07-b05, mixed mode)
> Reporter: Henning Schmiedehausen
> Assignee: Lukas Theussl
> Fix For: 1.8
> Attachments: maven-test.patch
>
> Original Estimate: 10 minutes
> Remaining: 10 minutes
>
> (this is basically a rehash of MPTEST-16)
> For porting unit tests from ant to maven, it was necessary to add certain
> pre-produced jars to the test classpath. This is not possible with the 1.6.2
> plugin. My solution was (as the solution of some other users), to add a
> property which can
> be assigned and is then added to the classpath. This allows me to do e.g.
> maven.test.classpath=
> ${basedir}/test/cpload/test1.jar;${basedir}/test/cpload/test2.jar
> where test1.jar and test2.jar are jars that must not be present in the build
> phase but need to present in the test phase.
> There have different solution been discussed. However:
> - adding something to the "resources" part of the POM makes it impossible to
> automatically download such a jar
> through maven.
> - adding a property to the dependencies makes it impossible to ship such a
> test jar with the distribution and reference
> it locally.
> and still we currently have no solution at all. I'd therefore propose the
> attached patch which allows all three test goals in maven-test-plugin
> (test:single, test:test and test:match) to evaluate a property variable
> called maven.test.classpath. This
> variable (if nonempty) is transferred to a element
> and can therefore contain multiple elements (separated by e.g. ";").
> The attached patch is IMHO the easiest fix for this problem with seems to
> affect a lot of maven users.
--
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
