[jira] Created: (MAVENUPLOAD-820) JFreeChart 1.0.1
JFreeChart 1.0.1 Key: MAVENUPLOAD-820 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-820 Project: maven-upload-requests Type: Task Reporter: Takayoshi Kimura Attachments: jfreechart-1.0.1-bundle.jar http://www.jfree.org/jfreechart/ -- 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-2196) Fails when parent module is not located a level above
[ http://jira.codehaus.org/browse/MNG-2196?page=comments#action_62721 ]
Vincent Massol commented on MNG-2196:
-
FYI, it now works on cargo. I'll make the change to the pom for the
rleativePath thanks.
> Fails when parent module is not located a level above
> -
>
> Key: MNG-2196
> URL: http://jira.codehaus.org/browse/MNG-2196
> Project: Maven 2
> Type: Bug
> Components: Dependencies
> Versions: 2.0.4
> Reporter: Vincent Massol
> Assignee: John Casey
> Priority: Blocker
> Fix For: 2.0.4
>
>
> Cargo is now failing to build with v2.0.4-SNAPSHOT as shown below. I believe
> the problem is because we have the following structure
> {noformat}
> trunk/
> |_ samples/
> |_ testdata/
> {noformat}
> where {{testdata}}'s POM refers to the POM in {{trunk}}.
> Error log:
> {noformat}
> C:\dev\cargo\trunk>mvn clean install
> [INFO] Scanning for projects...
> [INFO]
>
> [ERROR] FATAL ERROR
> [INFO]
>
> [INFO] Failed to resolve artifact.
> GroupId: org.codehaus.cargo
> ArtifactId: cargo
> Version: 0.9-SNAPSHOT
> Reason: Unable to download the artifact from any repository
> org.codehaus.cargo:cargo:pom:0.9-SNAPSHOT
> from the specified remote repositories:
> central (http://repo1.maven.org/maven2)
> [INFO]
>
> [INFO] Trace
> org.apache.maven.reactor.MavenExecutionException: Cannot find parent:
> org.codehaus.cargo:cargo for p
> roject: org.codehaus.cargo:cargo-samples-testdata:pom:null
> at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:365)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:278)
> 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:324)
> 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.project.ProjectBuildingException: Cannot find
> parent: org.codehaus.cargo
> :cargo for project: org.codehaus.cargo:cargo-samples-testdata:pom:null
> at
> org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(DefaultMavenProjectBu
> ilder.java:1132)
> at
> org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuil
> der.java:672)
> at
> org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMa
> venProjectBuilder.java:414)
> at
> org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java
> :190)
> at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:515)
> at
> org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:447)
> at
> org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:491)
> at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:351)
> ... 11 more
> Caused by: org.apache.maven.project.ProjectBuildingException: POM
> 'org.codehaus.cargo:cargo' not fou
> nd in repository: Unable to download the artifact from any repository
> org.codehaus.cargo:cargo:pom:0.9-SNAPSHOT
> from the specified remote repositories:
> central (http://repo1.maven.org/maven2)
> at
> org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepository(DefaultMavenP
> rojectBuilder.java:511)
> at
> org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(DefaultMavenProjectBu
> ilder.java:1128)
> ... 18 more
> Caused by: org.apache.maven.artifact.resolver.ArtifactNotFoundException:
> Unable to download the arti
> fact from any repository
> org.codehaus.cargo:cargo:pom:0.9-SNAPSHOT
> from the specified remote repositories:
> central (http://repo1.maven.org/maven2)
> at
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolve
> r.java:136)
> at
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolve
> r.java:63)
> at
> org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepository(DefaultMavenP
> rojectBuilder.java:465)
> ... 19 more
> Caused by: org
[jira] Created: (MAVENUPLOAD-821) JCommon 1.0.2
JCommon 1.0.2 - Key: MAVENUPLOAD-821 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-821 Project: maven-upload-requests Type: Task Reporter: Takayoshi Kimura Attachments: jcommon-1.0.2-bundle.jar http://www.jfree.org/jcommon/ -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-822) Weblets 0.4
Weblets 0.4 --- Key: MAVENUPLOAD-822 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-822 Project: maven-upload-requests Type: Task Reporter: John R Fallows https://weblets.dev.java.net/files/documents/4141/32209/weblets-0.4-bundle.jar https://weblets.dev.java.net/files/documents/4141/32210/weblets-api-0.4-bundle.jar https://weblets.dev.java.net/files/documents/4141/32211/weblets-impl-0.4-bundle.jar Please note: we do not use a public URL for the Apache 2.0 License because this causes network connectivity requirements during site generation, as the license is downloaded. Many thanks in advance. -- 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: (MSUREFIRE-87) Improve error stack trace when the error comes from the user's test code
Improve error stack trace when the error comes from the user's test code
Key: MSUREFIRE-87
URL: http://jira.codehaus.org/browse/MSUREFIRE-87
Project: Maven 2.x Surefire Plugin
Type: Improvement
Versions: 2.1.3
Reporter: Vincent Massol
For example here's what's printed when my test code reports an error:
{noformat}
java.lang.reflect.InvocationTargetException
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:324)
at
org.apache.maven.surefire.SurefireBooter.main(SurefireBooter.java:785)
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:274)
at
org.apache.maven.surefire.SurefireUtils.instantiateBattery(SurefireUtils.java:54)
at
org.apache.maven.surefire.Surefire.instantiateBatteries(Surefire.java:262)
at org.apache.maven.surefire.Surefire.run(Surefire.java:93)
at org.apache.maven.surefire.Surefire.run(Surefire.java:87)
at org.apache.maven.surefire.Surefire.run(Surefire.java:63)
... 5 more
Caused by: java.lang.reflect.InvocationTargetException
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:324)
at
org.apache.maven.surefire.battery.JUnitBattery.processTestClass(JUnitBattery.java:130)
at
org.apache.maven.surefire.battery.JUnitBattery.(JUnitBattery.java:69)
... 14 more
Caused by: java.lang.RuntimeException: System property "cargo.containers" must
be defined.
at
org.codehaus.cargo.sample.java.AbstractCargoTestCase.addContainerToTest(AbstractCargoTestCase.java:157)
{noformat}
This is really not nice and hard to read as the real cause it buried down the
stack trace. I would like surefire code to directly make the user's error be at
the top of the thrown stack trace, i.e. surefire should not catch user
exceptions. This is what I would expect to see:
{noformat}
java.lang.RuntimeException: System property "cargo.containers" must be defined.
at
org.codehaus.cargo.sample.java.AbstractCargoTestCase.addContainerToTest(AbstractCargoTestCase.java:157)
{noformat}
Thanks
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Created: (MCLOVER-32) Add support for aggregating functional tests results
Add support for aggregating functional tests results Key: MCLOVER-32 URL: http://jira.codehaus.org/browse/MCLOVER-32 Project: Maven 2.x Clover Plugin Type: Task Versions: 2.0 Reporter: Vincent Massol Assigned to: Vincent Massol In order to aggregate functional tests we need to do the following: * Modify clover:instrument so that the forked lifecycle extends till the install phase * Create an internal clover mojo bound to the install phase that will created a clovered version of the project's artifact as an attached artifact (classifier = "clover"). * Handle the different type of packaging. For example for a WAR packaging, add the clover jar to the attached clovered WAR, etc. * Modify the clover:instrumentInternal so that for any dependency artifact, it looks for the clovered version in the repo and adds it instead of the non-clovered version. Quite some work... The Clover plugin is bound to become the most complex m2 plugin ever written! :-) -- 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-645) xmlrpc: Class Not Found org.apache.maven.continuum.model.project.Project
[ http://jira.codehaus.org/browse/CONTINUUM-645?page=all ] Emmanuel Venisse closed CONTINUUM-645: -- Assign To: Emmanuel Venisse Resolution: Duplicate Duplicated with CONTINUUM-642 > xmlrpc: Class Not Found org.apache.maven.continuum.model.project.Project > > > Key: CONTINUUM-645 > URL: http://jira.codehaus.org/browse/CONTINUUM-645 > Project: Continuum > Type: Bug > Components: XMLRPC Interface > Versions: 1.0.3 > Environment: Windows XP, Continuum 1.0.3-SNAPSHOT > $> svn info > Path: . > URL: http://svn.apache.org/repos/asf/maven/continuum/branches/continuum-1.0.x > Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68 > Revision: 390550 > Node Kind: directory > Schedule: normal > Last Changed Author: evenisse > Last Changed Rev: 389840 > Last Changed Date: 2006-03-29 12:23:34 -0500 (Wed, 29 Mar 2006) > Properties Last Updated: 2006-03-31 19:35:18 -0500 (Fri, 31 Mar 2006) > Reporter: David H. DeWolf > Assignee: Emmanuel Venisse > > > org.jpox.exceptions.ClassNotResolvedException: Class > org.apache.maven.continuum.model.project.Project was not found in the > CLASSPATH. Please check your specification and your CLASSPATH. > at > org.jpox.JDOClassLoaderResolver.classForName(JDOClassLoaderResolver.java:169) > at > org.jpox.JDOClassLoaderResolver.classForName(JDOClassLoaderResolver.java:317) > at > org.jpox.store.rdbms.extent.ClassTableExtent$1.getType(ClassTableExtent.java:210) > at > org.jpox.store.query.UnionIteratorStatement.(UnionIteratorStatement.java:186) > at > org.jpox.store.query.UnionIteratorStatement.(UnionIteratorStatement.java:160) > at > org.jpox.store.rdbms.extent.ClassTableExtent.newQueryStatement(ClassTableExtent.java:198) > at > org.jpox.store.query.JDOQLQuery$Compiler.executionCompile(JDOQLQuery.java:806) > at org.jpox.store.query.JDOQLQuery.performExecute(JDOQLQuery.java:447) > at org.jpox.store.query.Query.executeWithMap(Query.java:1113) > at org.jpox.store.query.Query.executeWithArray(Query.java:1086) > at org.jpox.store.query.Query.execute(Query.java:1009) > at > org.codehaus.plexus.jdo.PlexusJdoUtils.getAllObjectsDetached(PlexusJdoUtils.java:233) > at > org.apache.maven.continuum.store.JdoContinuumStore.getAllObjectsDetached(JdoContinuumStore.java:980) > at > org.apache.maven.continuum.store.JdoContinuumStore.getAllProjectsWithAllDetails(JdoContinuumStore.java:942) > at > org.apache.maven.continuum.DefaultContinuum.getAllProjectsWithAllDetails(DefaultContinuum.java:2152) > at > org.apache.maven.continuum.xmlrpc.DefaultContinuumXmlRpc.getProjects(DefaultContinuumXmlRpc.java:96) > 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.apache.xmlrpc.Invoker.execute(Unknown Source) > at org.apache.xmlrpc.XmlRpcWorker.invokeHandler(Unknown Source) > at org.apache.xmlrpc.XmlRpcWorker.execute(Unknown Source) > at org.apache.xmlrpc.XmlRpcServer.execute(Unknown Source) > at org.apache.xmlrpc.XmlRpcServer.execute(Unknown Source) > at org.apache.xmlrpc.WebServer$Connection.run(Unknown Source) > at org.apache.xmlrpc.WebServer$Runner.run(Unknown Source) > at java.lang.Thread.run(Thread.java:595) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-823) Prototype Taglib 1.1
Prototype Taglib 1.1 Key: MAVENUPLOAD-823 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-823 Project: maven-upload-requests Type: Task Reporter: Tim O'Brien Version 1.1. of the prototype jsp taglib -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-824) Reference Taglib 1.0
Reference Taglib 1.0 Key: MAVENUPLOAD-824 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-824 Project: maven-upload-requests Type: Task Reporter: Tim O'Brien Version 1.0 of the Reference Taglib -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-825) Generic DAO 1.0http://jira.codehaus.org/secure/CreateIssue.jspa
Generic DAO 1.0http://jira.codehaus.org/secure/CreateIssue.jspa --- Key: MAVENUPLOAD-825 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-825 Project: maven-upload-requests Type: Task Reporter: Tim O'Brien Generic DAO 1.0 release -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MECLIPSE-94) Allow eclipse:eclipse to work on pom (and other) projects
Allow eclipse:eclipse to work on pom (and other) projects - Key: MECLIPSE-94 URL: http://jira.codehaus.org/browse/MECLIPSE-94 Project: Maven 2.x Eclipse Plugin Type: Improvement Versions: 2.1 Reporter: Felipe Leme Assigned to: Vincent Massol I'm creating a Java EE project based on the m2book (which I was reviewing; it's not available yet...) and one of the projects is a pom-packaging project used for integration tests. According to Vincent, currently this project must be a pom (in fact, I tried to set it as jar, but then the test phase would be run anyway, which would cause the tests to fail), as it doesn't produces a jar. But as it has java files (on the src/main/it/java directory), I tried to call eclipse:eclipse but it fails, saying that "Not running eclipse plugin goal for pom project". For these scenarios, I think a propery would be enough. At first I thought something about a 'force' or 'forceGeneration' property, would enough, which the code change being from: if ( "pom".equals( packaging ) && eclipseProjectDir == null ) to: if ( "pom".equals( packaging ) && eclipseProjectDir == null && !forceGeneration ) Then I realized there is other place where the pom nature is checked: if ( "pom".equals( packaging ) && eclipseProjectDir == null && !forceGeneration ) So, I think a better name for the property would be 'javaProject' and the change would be: final boolean isJavaProjectProperty = // read property; defaults to false... if ( "pom".equals( packaging ) && eclipseProjectDir == null && !isJavaProjectProperty ) isJavaProject = isJavaProjectProperty || !"ear".equals( packaging ) && !"pom".equals( packaging ); If nobody objects and someone is willing to apply the changes, I can provide such patch (with the proper test cases). -- Felipe PS: I'm assigning it to Vincent for now, as he 'dreamed' that such features already existed :-) -- 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: (MECLIPSE-94) Allow eclipse:eclipse to work on pom (and other) projects
[ http://jira.codehaus.org/browse/MECLIPSE-94?page=comments#action_62734 ] Felipe Leme commented on MECLIPSE-94: - Sure, no problem, makes more sense. I just wanted to be sure you were notified about it (well, I could have sent you a message, sorry :-) > Allow eclipse:eclipse to work on pom (and other) projects > - > > Key: MECLIPSE-94 > URL: http://jira.codehaus.org/browse/MECLIPSE-94 > Project: Maven 2.x Eclipse Plugin > Type: Improvement > Versions: 2.1 > Reporter: Felipe Leme > > > I'm creating a Java EE project based on the m2book (which I was reviewing; > it's not available yet...) and one of the projects is a pom-packaging project > used for integration tests. According to Vincent, currently this project must > be a pom (in fact, I tried to set it as jar, but then the test phase would be > run anyway, which would cause the tests to fail), as it doesn't produces a > jar. But as it has java files (on the src/main/it/java directory), I tried to > call eclipse:eclipse but it fails, saying that "Not running eclipse plugin > goal for pom project". > For these scenarios, I think a propery would be enough. At first I thought > something about a 'force' or 'forceGeneration' property, would enough, which > the code change being from: > if ( "pom".equals( packaging ) && eclipseProjectDir == null ) > to: > if ( "pom".equals( packaging ) && eclipseProjectDir == null && > !forceGeneration ) > Then I realized there is other place where the pom nature is checked: > if ( "pom".equals( packaging ) && eclipseProjectDir == null && > !forceGeneration ) > So, I think a better name for the property would be 'javaProject' and the > change would be: > final boolean isJavaProjectProperty = // read property; defaults to false... > if ( "pom".equals( packaging ) && eclipseProjectDir == null && > !isJavaProjectProperty ) > isJavaProject = isJavaProjectProperty || !"ear".equals( packaging ) && > !"pom".equals( packaging ); > If nobody objects and someone is willing to apply the changes, I can provide > such patch (with the proper test cases). > -- Felipe > PS: I'm assigning it to Vincent for now, as he 'dreamed' that such features > already existed :-) -- 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: (ARCHETYPE-10) j2ee archetype has invalid dependencies
[ http://jira.codehaus.org/browse/ARCHETYPE-10?page=comments#action_62735 ] Jesse McConnell commented on ARCHETYPE-10: -- well, nothing in there strictly needs to require webservices I don't think I'll take a look, I probably built the sample around the idea of webservices as well > j2ee archetype has invalid dependencies > --- > > Key: ARCHETYPE-10 > URL: http://jira.codehaus.org/browse/ARCHETYPE-10 > Project: Maven Archetype > Type: Bug > Components: Archetypes > Environment: j2sdk1.4.2_08, maven 2.0, winxp > Reporter: Brian Bonner > Assignee: Jesse McConnell > > > I'm trying to install the maven-j2ee-archetype and run it to test a mod to > the eclipse plugin that I made. > Unfortunately, it's not letting me install the archetype. > I unpacked: maven-archetype-j2ee.jar > I cd'd to the directory and ran: mvn install. > C:\test\maven-archetype-j2ee>mvn install > [INFO] Scanning for projects... > Downloading: > http://cvs.apache.org/repository//org/apache/maven/archetypes/maven > -archetypes/1.0-alpha-4-SNAPSHOT/maven-archetypes-1.0-alpha-4-SNAPSHOT.pom > [WARNING] Unable to get resource from repository snapshot-repo > (http://cvs.apach > e.org/repository/) > [INFO] > - > --- > [ERROR] FATAL ERROR > [INFO] > - > --- > [INFO] Failed to resolve artifact. > GroupId: org.apache.maven.archetypes > ArtifactId: maven-archetypes > Version: 1.0-alpha-4-SNAPSHOT > Reason: Unable to download the artifact from any repository > org.apache.maven.archetypes:maven-archetypes:1.0-alpha-4-SNAPSHOT:pom > from the specified remote repositories: > central (http://repo1.maven.org/maven2), > snapshot-repo (http://cvs.apache.org/repository/) > [INFO] > - > --- > [INFO] Trace > org.apache.maven.reactor.MavenExecutionException: POM > 'org.apache.maven.archetyp > es:maven-archetypes' not found in repository: Unable to download the artifact > fr > om any repository > org.apache.maven.archetypes:maven-archetypes:1.0-alpha-4-SNAPSHOT:pom > from the specified remote repositories: > central (http://repo1.maven.org/maven2), > snapshot-repo (http://cvs.apache.org/repository/) > at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:359) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:276) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:113) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:249) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. > java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces > sorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:324) > 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.project.ProjectBuildingException: POM > 'org.apache.ma > ven.archetypes:maven-archetypes' not found in repository: Unable to download > the > artifact from any repository > org.apache.maven.archetypes:maven-archetypes:1.0-alpha-4-SNAPSHOT:pom > from the specified remote repositories: > central (http://repo1.maven.org/maven2), > snapshot-repo (http://cvs.apache.org/repository/) > at > org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepo > sitory(DefaultMavenProjectBuilder.java:423) > at > org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(D > efaultMavenProjectBuilder.java:955) > at > org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMave > nProjectBuilder.java:586) > at > org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFi > le(DefaultMavenProjectBuilder.java:298) > at > org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMave > nProjectBuilder.java:276) > at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:509) > at > org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:441) > at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:345) > ... 11 more > Caused by: org.apache.maven.artifact.resolver.ArtifactNotFoundException: > Unable > to download the artifact from any repository > org.apache.maven.archetypes:maven-archetypes:1.0-alpha-4-SNAPSHOT:pom > from the specified remote repositories: > central (http://repo1.maven.org/maven2), > snapshot-repo (http:
[jira] Updated: (ARCHETYPE-10) j2ee archetype has invalid dependencies
[ http://jira.codehaus.org/browse/ARCHETYPE-10?page=all ] Jesse McConnell updated ARCHETYPE-10: - Attachment: marchetype-10.patch > j2ee archetype has invalid dependencies > --- > > Key: ARCHETYPE-10 > URL: http://jira.codehaus.org/browse/ARCHETYPE-10 > Project: Maven Archetype > Type: Bug > Components: Archetypes > Environment: j2sdk1.4.2_08, maven 2.0, winxp > Reporter: Brian Bonner > Assignee: Jesse McConnell > Attachments: marchetype-10.patch > > > I'm trying to install the maven-j2ee-archetype and run it to test a mod to > the eclipse plugin that I made. > Unfortunately, it's not letting me install the archetype. > I unpacked: maven-archetype-j2ee.jar > I cd'd to the directory and ran: mvn install. > C:\test\maven-archetype-j2ee>mvn install > [INFO] Scanning for projects... > Downloading: > http://cvs.apache.org/repository//org/apache/maven/archetypes/maven > -archetypes/1.0-alpha-4-SNAPSHOT/maven-archetypes-1.0-alpha-4-SNAPSHOT.pom > [WARNING] Unable to get resource from repository snapshot-repo > (http://cvs.apach > e.org/repository/) > [INFO] > - > --- > [ERROR] FATAL ERROR > [INFO] > - > --- > [INFO] Failed to resolve artifact. > GroupId: org.apache.maven.archetypes > ArtifactId: maven-archetypes > Version: 1.0-alpha-4-SNAPSHOT > Reason: Unable to download the artifact from any repository > org.apache.maven.archetypes:maven-archetypes:1.0-alpha-4-SNAPSHOT:pom > from the specified remote repositories: > central (http://repo1.maven.org/maven2), > snapshot-repo (http://cvs.apache.org/repository/) > [INFO] > - > --- > [INFO] Trace > org.apache.maven.reactor.MavenExecutionException: POM > 'org.apache.maven.archetyp > es:maven-archetypes' not found in repository: Unable to download the artifact > fr > om any repository > org.apache.maven.archetypes:maven-archetypes:1.0-alpha-4-SNAPSHOT:pom > from the specified remote repositories: > central (http://repo1.maven.org/maven2), > snapshot-repo (http://cvs.apache.org/repository/) > at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:359) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:276) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:113) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:249) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. > java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces > sorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:324) > 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.project.ProjectBuildingException: POM > 'org.apache.ma > ven.archetypes:maven-archetypes' not found in repository: Unable to download > the > artifact from any repository > org.apache.maven.archetypes:maven-archetypes:1.0-alpha-4-SNAPSHOT:pom > from the specified remote repositories: > central (http://repo1.maven.org/maven2), > snapshot-repo (http://cvs.apache.org/repository/) > at > org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepo > sitory(DefaultMavenProjectBuilder.java:423) > at > org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(D > efaultMavenProjectBuilder.java:955) > at > org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMave > nProjectBuilder.java:586) > at > org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFi > le(DefaultMavenProjectBuilder.java:298) > at > org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMave > nProjectBuilder.java:276) > at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:509) > at > org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:441) > at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:345) > ... 11 more > Caused by: org.apache.maven.artifact.resolver.ArtifactNotFoundException: > Unable > to download the artifact from any repository > org.apache.maven.archetypes:maven-archetypes:1.0-alpha-4-SNAPSHOT:pom > from the specified remote repositories: > central (http://repo1.maven.org/maven2), > snapshot-repo (http://cvs.apache.org/repository/) > at > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(De > f
[jira] Moved: (SCM-180) Does not deploy to existing folder
[ http://jira.codehaus.org/browse/SCM-180?page=all ] Jesse McConnell moved MSITE-107 to SCM-180: --- Complexity: Intermediate Key: SCM-180 (was: MSITE-107) Project: Maven SCM (was: Maven 2.x Site Plugin) > Does not deploy to existing folder > -- > > Key: SCM-180 > URL: http://jira.codehaus.org/browse/SCM-180 > Project: Maven SCM > Type: Bug > Environment: Windows XP, Windows 2003 server, Maven 2.0.2 > Reporter: Andreas Guther > Attachments: site.error.txt > > > I have mapped a drive to our site deployment server on a windows 2003 server. > The deploy works fine if the target folder does not exist. If the project > was previously deployed the deploy target will fail with the error as > included below. I would expect that the deploy overwrites the content in an > existing folder. > C:\workspace\dev.ztel.mt.trunk>mvn site:deploy -e > + Error stacktraces are turned on. > [INFO] Scanning for projects... > [INFO] Searching repository for plugin with prefix: 'site'. > [INFO] > > [INFO] Building zTelligence > [INFO]task-segment: [site:deploy] > [INFO] > > [INFO] [site:deploy] > file://W:/projects/ztel-trunk - Session: Opened > file://W:/projects/ztel-trunk - Session: Disconnecting > file://W:/projects/ztel-trunk - Session: Disconnected > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Error uploading site > Embedded error: Could not make directory 'W:\projects\ztel-trunk\.'. > [INFO] > > [INFO] Trace > org.apache.maven.lifecycle.LifecycleExecutionException: Error uploading site > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:556) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:485) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:455) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.jav > a:303) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:270) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:139) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:249) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > Caused by: org.apache.maven.plugin.MojoExecutionException: Error uploading > site > at > org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:162) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:415) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:531) > ... 16 more > Caused by: org.apache.maven.wagon.TransferFailedException: Could not make > directory 'W:\projects\ztel-trunk\.'. > at > org.apache.maven.wagon.providers.file.FileWagon.putDirectory(FileWagon.java:113) > at > org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:154) > ... 18 more > [INFO] > > [INFO] Total time: 1 second > [INFO] Finished at: Sat Mar 25 09:22:14 PST 2006 > [INFO] Final Memory: 4M/508M > [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] Moved: (WAGON-40) Does not deploy to existing folder
[ http://jira.codehaus.org/browse/WAGON-40?page=all ] Jesse McConnell moved SCM-180 to WAGON-40: -- Complexity: (was: Intermediate) Workflow: jira (was: Maven New) Key: WAGON-40 (was: SCM-180) Project: wagon (was: Maven SCM) > Does not deploy to existing folder > -- > > Key: WAGON-40 > URL: http://jira.codehaus.org/browse/WAGON-40 > Project: wagon > Type: Bug > Environment: Windows XP, Windows 2003 server, Maven 2.0.2 > Reporter: Andreas Guther > Attachments: site.error.txt > > > I have mapped a drive to our site deployment server on a windows 2003 server. > The deploy works fine if the target folder does not exist. If the project > was previously deployed the deploy target will fail with the error as > included below. I would expect that the deploy overwrites the content in an > existing folder. > C:\workspace\dev.ztel.mt.trunk>mvn site:deploy -e > + Error stacktraces are turned on. > [INFO] Scanning for projects... > [INFO] Searching repository for plugin with prefix: 'site'. > [INFO] > > [INFO] Building zTelligence > [INFO]task-segment: [site:deploy] > [INFO] > > [INFO] [site:deploy] > file://W:/projects/ztel-trunk - Session: Opened > file://W:/projects/ztel-trunk - Session: Disconnecting > file://W:/projects/ztel-trunk - Session: Disconnected > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Error uploading site > Embedded error: Could not make directory 'W:\projects\ztel-trunk\.'. > [INFO] > > [INFO] Trace > org.apache.maven.lifecycle.LifecycleExecutionException: Error uploading site > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:556) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:485) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:455) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.jav > a:303) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:270) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:139) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:249) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > Caused by: org.apache.maven.plugin.MojoExecutionException: Error uploading > site > at > org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:162) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:415) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:531) > ... 16 more > Caused by: org.apache.maven.wagon.TransferFailedException: Could not make > directory 'W:\projects\ztel-trunk\.'. > at > org.apache.maven.wagon.providers.file.FileWagon.putDirectory(FileWagon.java:113) > at > org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:154) > ... 18 more > [INFO] > > [INFO] Total time: 1 second > [INFO] Finished at: Sat Mar 25 09:22:14 PST 2006 > [INFO] Final Memory: 4M/508M > [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] Commented: (WAGON-40) Does not deploy to existing folder
[ http://jira.codehaus.org/browse/WAGON-40?page=comments#action_62739 ] Jesse McConnell commented on WAGON-40: -- Caused by: org.apache.maven.wagon.TransferFailedException: Could not make directory 'W:\projects\ztel-trunk\.'. at org.apache.maven.wagon.providers.file.FileWagon.putDirectory(FileWagon.java:113) this looks like more of a wagon issue so moving it over to there > Does not deploy to existing folder > -- > > Key: WAGON-40 > URL: http://jira.codehaus.org/browse/WAGON-40 > Project: wagon > Type: Bug > Environment: Windows XP, Windows 2003 server, Maven 2.0.2 > Reporter: Andreas Guther > Attachments: site.error.txt > > > I have mapped a drive to our site deployment server on a windows 2003 server. > The deploy works fine if the target folder does not exist. If the project > was previously deployed the deploy target will fail with the error as > included below. I would expect that the deploy overwrites the content in an > existing folder. > C:\workspace\dev.ztel.mt.trunk>mvn site:deploy -e > + Error stacktraces are turned on. > [INFO] Scanning for projects... > [INFO] Searching repository for plugin with prefix: 'site'. > [INFO] > > [INFO] Building zTelligence > [INFO]task-segment: [site:deploy] > [INFO] > > [INFO] [site:deploy] > file://W:/projects/ztel-trunk - Session: Opened > file://W:/projects/ztel-trunk - Session: Disconnecting > file://W:/projects/ztel-trunk - Session: Disconnected > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Error uploading site > Embedded error: Could not make directory 'W:\projects\ztel-trunk\.'. > [INFO] > > [INFO] Trace > org.apache.maven.lifecycle.LifecycleExecutionException: Error uploading site > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:556) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:485) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:455) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.jav > a:303) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:270) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:139) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:249) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > Caused by: org.apache.maven.plugin.MojoExecutionException: Error uploading > site > at > org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:162) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:415) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:531) > ... 16 more > Caused by: org.apache.maven.wagon.TransferFailedException: Could not make > directory 'W:\projects\ztel-trunk\.'. > at > org.apache.maven.wagon.providers.file.FileWagon.putDirectory(FileWagon.java:113) > at > org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:154) > ... 18 more > [INFO] > > [INFO] Total time: 1 second > [INFO] Finished at: Sat Mar 25 09:22:14 PST 2006 > [INFO] Final Memory: 4M/508M > [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
[jira] Updated: (MSITE-101) schedule and release doxia 1.0
[ http://jira.codehaus.org/browse/MSITE-101?page=all ] Jesse McConnell updated MSITE-101: -- Component: doxia integration > schedule and release doxia 1.0 > -- > > Key: MSITE-101 > URL: http://jira.codehaus.org/browse/MSITE-101 > Project: Maven 2.x Site Plugin > Type: Task > Components: doxia integration > Reporter: Brett Porter > Fix For: 2.0 > > > resolve any outstanding issues -- 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: (MSITE-109) Site plugin should convert .fml files when working from xdocDirectory
[ http://jira.codehaus.org/browse/MSITE-109?page=all ]
Jesse McConnell updated MSITE-109:
--
Component: doxia integration
> Site plugin should convert .fml files when working from xdocDirectory
> -
>
> Key: MSITE-109
> URL: http://jira.codehaus.org/browse/MSITE-109
> Project: Maven 2.x Site Plugin
> Type: Improvement
> Components: doxia integration
> Versions: 2.0
> Reporter: Wendy Smoak
> Fix For: 2.0
>
>
> In m1, by default the .fml files are found anywhere under ${basedir}/xdocs.
> http://maven.apache.org/maven-1.x/plugins/faq/properties.html
> If the m2 site plugin is working from ${basedir}/xdocs, (or a configured
> 'xdocDirectory'), it should convert any .fml files it finds there.
> http://www.nabble.com/-m2-latest-site-plugin-with-m1-format-project%2C-and-skins--t1379592.html#a3708717
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Created: (MECLIPSE-95) Var classpath entries need to be marked exported by default
Var classpath entries need to be marked exported by default --- Key: MECLIPSE-95 URL: http://jira.codehaus.org/browse/MECLIPSE-95 Project: Maven 2.x Eclipse Plugin Type: Bug Versions: 2.1 Reporter: Sachin Patel Fix For: 2.2 Generated .classpath entries of kind "var" need to be marked exported by default so that referenced projects have visibility to them. Or provide an option to specifiy that that entries should be exported. Example: should me made... -- 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: (MSITE-98) Allow files to be excluded from site generation
[ http://jira.codehaus.org/browse/MSITE-98?page=all ] Jesse McConnell updated MSITE-98: - Component: doxia integration > Allow files to be excluded from site generation > --- > > Key: MSITE-98 > URL: http://jira.codehaus.org/browse/MSITE-98 > Project: Maven 2.x Site Plugin > Type: New Feature > Components: doxia integration > Reporter: Dennis Lundberg > Fix For: 2.0 > Attachments: MSITE-98.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: (MSITE-64) move all relevant site rendering code into doxia, so that reports can also generate proper decoration and skinning
[ http://jira.codehaus.org/browse/MSITE-64?page=all ] Jesse McConnell updated MSITE-64: - Component: doxia integration > move all relevant site rendering code into doxia, so that reports can also > generate proper decoration and skinning > -- > > Key: MSITE-64 > URL: http://jira.codehaus.org/browse/MSITE-64 > Project: Maven 2.x Site Plugin > Type: Improvement > Components: doxia integration > Reporter: Brett Porter > Fix For: 2.0 > > > currently, standalone reports always get the default -- 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: (MSITE-40) don't generate doc file if it is unchanged
[ http://jira.codehaus.org/browse/MSITE-40?page=all ] Jesse McConnell updated MSITE-40: - Component: doxia integration > don't generate doc file if it is unchanged > -- > > Key: MSITE-40 > URL: http://jira.codehaus.org/browse/MSITE-40 > Project: Maven 2.x Site Plugin > Type: Bug > Components: doxia integration > Reporter: Brett Porter > Assignee: Jesse McConnell > Fix For: 2.0 > Attachments: doxia-regen.patch, msite-40-doxia.patch, > msite-40-site-plugin.patch, site-regen.patch > > > this would help make rsync more effecient not to mention faster site gen -- 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: (MIDEA-44) Optional toggle switch to revert MIDEA-35
[ http://jira.codehaus.org/browse/MIDEA-44?page=comments#action_62744 ] Johann Reyes commented on MIDEA-44: --- This again is causing problem for web module settings. This I believe is true for idea 5.x although I'm did my testing in idea 5.1 The default behavior in Idea is that they don't use short names no more to reference module libraries, and when the library name is include to build a web module in idea, at first looks pfine, is going to include all your jars in the web module, but restart the IDE and you'll see you lost your packaging settings, this being when you shutdown idea, it tried to remove the name attribute from the .iml file , and it doing so, you lose your packaging settings. This sadly is a big pain since one has to setup the dependecies then eveytime the IDE is restarted. > Optional toggle switch to revert MIDEA-35 > - > > Key: MIDEA-44 > URL: http://jira.codehaus.org/browse/MIDEA-44 > Project: Maven 2.x Idea Plugin > Type: Improvement > Reporter: Patrick Lightbody > Assignee: Brett Porter > Fix For: 2.0 > Attachments: useShortDependencyNames.patch > > > I never had any problems with the short names that were removed when MIDEA-35 > was fixed, but I believe the reporter that it can cause problems. However, I > think that it is a useful enough feature that users should be able to turn it > on if they want to. So here is a patch that does that. -- 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: (MSITE-19) Various encoding problems with InputStream and XML
[ http://jira.codehaus.org/browse/MSITE-19?page=comments#action_62745 ] Jesse McConnell commented on MSITE-19: -- should be use make another mojo that can be bound to process-resources and implements the native2ascii behavior we are looking for here? I see that some people have already gotten this functionality working by using the ant native2ascii task... if this is the case then we can probably make a mojo for this pretty quickly, and just make an issue over there for creating it, link it to this issue and then close this issue out if that is all that is remaining. > Various encoding problems with InputStream and XML > -- > > Key: MSITE-19 > URL: http://jira.codehaus.org/browse/MSITE-19 > Project: Maven 2.x Site Plugin > Type: Bug > Reporter: Naoki Nose > Fix For: 2.0 > Attachments: plexus-i18n.diff, plexus-site-renderer.diff, plexus-utils.diff, > plexus-utils_2.diff, project-info-report_ja.properties, > project-info-report_zh_CN.properties, project-info-report_zh_CN.properties, > site-plugin_ja.properties, site-plugin_zh_CN.properties > > > There is various encoding problems with InputStream and XML in different > components. > - Property resource file is encoded with UTF-8 , but Java reads bundle with > UTF-8. > - In different components Reader is constructed with default system encoding. > - MXParser ignores encoding attribute in xml declaration. -- 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: (MIDEA-44) Optional toggle switch to revert MIDEA-35
[ http://jira.codehaus.org/browse/MIDEA-44?page=comments#action_62746 ] Patrick Lightbody commented on MIDEA-44: I'm personally OK with it being defaulted to false, like I had in my patch. I'll defer to Brett on what he'd like to do. We do need a way to keep this behavior though: Bret and I find it _extremely_ valuable and haven't had problems with it (I'm also running 5.1). > Optional toggle switch to revert MIDEA-35 > - > > Key: MIDEA-44 > URL: http://jira.codehaus.org/browse/MIDEA-44 > Project: Maven 2.x Idea Plugin > Type: Improvement > Reporter: Patrick Lightbody > Assignee: Brett Porter > Fix For: 2.0 > Attachments: useShortDependencyNames.patch > > > I never had any problems with the short names that were removed when MIDEA-35 > was fixed, but I believe the reporter that it can cause problems. However, I > think that it is a useful enough feature that users should be able to turn it > on if they want to. So here is a patch that does that. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MECLIPSE-96) Missing support for range of dependency versions
Missing support for range of dependency versions Key: MECLIPSE-96 URL: http://jira.codehaus.org/browse/MECLIPSE-96 Project: Maven 2.x Eclipse Plugin Type: Bug Versions: 2.2, 2.0, 2.1 Environment: Sun Java 1.5_06 / Maven 2.0.3 Reporter: Petter L. H. Eide Given a project with a dependency as the following: my.group my-artifact-id [3.1.0,) and goal 'mvn eclipse:eclipse', the plugin does not interprets the range and tries to download: Downloading: http://repo1.maven.org/maven2/my/group/my-artifact-id/[3.1.0,)/my-artifact-id-[3.1.0,).jar [WARNING] Unable to get resource from repository central (http://repo1.maven.org/maven2) Likevise, the following is written to 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] Commented: (MIDEA-44) Optional toggle switch to revert MIDEA-35
[ http://jira.codehaus.org/browse/MIDEA-44?page=comments#action_62749 ] Johann Reyes commented on MIDEA-44: --- I don't have a problem also being defaulted to true, just pointing out the problem with this, and making a reference that the default way that idea creates their iml files, they no longer support the name attribute?? (why I'm not sure) > Optional toggle switch to revert MIDEA-35 > - > > Key: MIDEA-44 > URL: http://jira.codehaus.org/browse/MIDEA-44 > Project: Maven 2.x Idea Plugin > Type: Improvement > Reporter: Patrick Lightbody > Assignee: Brett Porter > Fix For: 2.0 > Attachments: useShortDependencyNames.patch > > > I never had any problems with the short names that were removed when MIDEA-35 > was fixed, but I believe the reporter that it can cause problems. However, I > think that it is a useful enough feature that users should be able to turn it > on if they want to. So here is a patch that does that. -- 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-2201) Interpolation problem when using surefire
Interpolation problem when using surefire
-
Key: MNG-2201
URL: http://jira.codehaus.org/browse/MNG-2201
Project: Maven 2
Type: Bug
Components: Inheritence and Interpolation
Versions: 2.0.4
Reporter: Vincent Massol
I've just tried the cargo build with the latest trunk versions of
2.0.4-SNAPSHOT and surefire plugin, and it seems there's some interpolation
issue (I don't know if the problem is with the surefire plugin or with maven
core).
Here's what I have:
maven-surefire-plugin
pertest
[...]
cargo.target.dir
${project.build.directory}
[...]
It seems the ${project.build.directory} property is no longer getting resolved
as I got a directory named ${project.build.directory} created.
It used to work fine before.
--
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-2201) Interpolation problem when using surefire
[ http://jira.codehaus.org/browse/MNG-2201?page=all ]
Vincent Massol updated MNG-2201:
Priority: Blocker (was: Major)
Description:
I've just tried the cargo build with the latest trunk versions of
2.0.4-SNAPSHOT and surefire plugin, and it seems there's some interpolation
issue (I don't know if the problem is with the surefire plugin or with maven
core).
Here's what I have:
{code:xml}
maven-surefire-plugin
pertest
[...]
cargo.target.dir
${project.build.directory}
[...]
{code}
It seems the ${project.build.directory} property is no longer getting resolved
as I got a directory named ${project.build.directory} created.
It used to work fine before.
was:
I've just tried the cargo build with the latest trunk versions of
2.0.4-SNAPSHOT and surefire plugin, and it seems there's some interpolation
issue (I don't know if the problem is with the surefire plugin or with maven
core).
Here's what I have:
maven-surefire-plugin
pertest
[...]
cargo.target.dir
${project.build.directory}
[...]
It seems the ${project.build.directory} property is no longer getting resolved
as I got a directory named ${project.build.directory} created.
It used to work fine before.
> Interpolation problem when using surefire
> -
>
> Key: MNG-2201
> URL: http://jira.codehaus.org/browse/MNG-2201
> Project: Maven 2
> Type: Bug
> Components: Inheritence and Interpolation
> Versions: 2.0.4
> Reporter: Vincent Massol
> Priority: Blocker
>
>
> I've just tried the cargo build with the latest trunk versions of
> 2.0.4-SNAPSHOT and surefire plugin, and it seems there's some interpolation
> issue (I don't know if the problem is with the surefire plugin or with maven
> core).
> Here's what I have:
> {code:xml}
>
>
>
>
> maven-surefire-plugin
>
> pertest
>
> [...]
>
> cargo.target.dir
> ${project.build.directory}
>
> [...]
> {code}
> It seems the ${project.build.directory} property is no longer getting
> resolved as I got a directory named ${project.build.directory} created.
> It used to work fine before.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-6) Multiproject Release: No check in
[ http://jira.codehaus.org/browse/MRELEASE-6?page=comments#action_62756 ] Fabian Bauschulte commented on MRELEASE-6: -- I am using CVS and eclipse (workspace). All my projects are CVS modules: parent and moduleA, modulesB, moduleC: \parent \moduleA \moduleB \moduleC Every project has the section "xxx" set to the correct cvs location. Refactoring of the package structure is not possible in my case (legacy system). I don´t see a way to use the multiproject release - any solution would be highly appreciated. At the moment I am forced to release all modules "my hand": \parent\mvn -N release:prepare release:perform \moduleA\mvn release:prepare release:perform \moduleB\mvn release:prepare release:perform \moduleC\mvn release:prepare release:perform Is there any chance to get this bug fixed in the next time?? > Multiproject Release: No check in > - > > Key: MRELEASE-6 > URL: http://jira.codehaus.org/browse/MRELEASE-6 > Project: Maven 2.x Release Plugin > Type: Bug > Environment: Windows XP, Eclipse Workspace > Reporter: Bernd Mau > Priority: Critical > > > I tried to release a multiproject with 5 modules (on a Branch). Well, > the POMs of all modules are changed and there are some dependencies > which have been updated correctly. But only the master has been checked > in correctly. > I'm changed the recommended layout, to fit in an eclipse workspace. I > have one master at the same level as the other modules. > The module section of the master pom.xml: > > ../hhla.library.pom > ../hhla.library.site > ../hhla.lang > ../hhla.common.log4jx > -- 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-2202) Improve pom to handle daylight saving changes
Improve pom to handle daylight saving changes - Key: MNG-2202 URL: http://jira.codehaus.org/browse/MNG-2202 Project: Maven 2 Type: Improvement Reporter: Andreas Guther Priority: Minor It would be great if the timezone element in Maven 2 could be extendend in a way that makes it able to determine the offset own its own as well as to be able to make adjustments to daylight savings. The following suggestion from the Maven Users mailing list seems to be an interesting approach. Note: In addition to the posting from Ian Stewart I would like to add that I believe that the offset element is not needed in case the timezone has a name and the dayligh savings element. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 04, 2006 6:36 AM To: Maven Users List Subject: Re: TimeZone Element in pom.xml Note that the observation of Summertime/Daylight Savings Time does not change the timezone where a developer resides. Instead of changing everybody's timezone twice a year, I would recommend making the timezone element its own complex type, more inline with the java.util.TimeZone class: Eastern -5 true It's better to be hated for who you are than loved for who you are not Ian D. Stewart Appl Dev Analyst-Advisory, DCS Automation JPMorganChase Global Technology Infrastructure Phone: (614) 244-2564 Pager: (888) 260-0078 "Andreas Guther" <[EMAIL PROTECTED]To: "Maven Users List" ttools.com> cc: Subject: TimeZone Element in pom.xml 04/04/2006 12:43 AM Please respond to "Maven Users List" Hi, Is there a way in Maven to adjust the TimeZone element in the pom.xml to daylight savings time? We have an international team and I like the fact that we can see on the maven generated web site's team list what time it is for a specific developer. What I am missing is the automatic adjustment for example for my time zone which is in winter times -8 and in summer times -7. I just made a global search and replace in my pom.xml but actually it would be more convenient maven could do that for me. Is there anything that helps me solving the problem or is this worth an enhancement request? Andreas -- 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: (MECLIPSE-96) Missing support for range of dependency versions
[ http://jira.codehaus.org/browse/MECLIPSE-96?page=all ] fabrizio giustina closed MECLIPSE-96: - Assign To: fabrizio giustina Resolution: Fixed Fix Version: 2.2 fixed in svn for 2.2 > Missing support for range of dependency versions > > > Key: MECLIPSE-96 > URL: http://jira.codehaus.org/browse/MECLIPSE-96 > Project: Maven 2.x Eclipse Plugin > Type: Bug > Versions: 2.2, 2.0, 2.1 > Environment: Sun Java 1.5_06 / Maven 2.0.3 > Reporter: Petter L. H. Eide > Assignee: fabrizio giustina > Fix For: 2.2 > > > Given a project with a dependency as the following: > > my.group > my-artifact-id > [3.1.0,) > > and goal 'mvn eclipse:eclipse', the plugin does not interprets the range and > tries to download: > Downloading: > http://repo1.maven.org/maven2/my/group/my-artifact-id/[3.1.0,)/my-artifact-id-[3.1.0,).jar > [WARNING] Unable to get resource from repository central > (http://repo1.maven.org/maven2) > Likevise, the following is written to classpath: > path="M2_REPO/my/group/my-artifact-id/[3.1.0,)/my-artifact-id-[3.1.0,).jar"/> -- 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: (MSITE-109) Site plugin should convert .fml files when working from xdocDirectory
[ http://jira.codehaus.org/browse/MSITE-109?page=all ]
Jesse McConnell updated MSITE-109:
--
Attachment: msite-109.patch
> Site plugin should convert .fml files when working from xdocDirectory
> -
>
> Key: MSITE-109
> URL: http://jira.codehaus.org/browse/MSITE-109
> Project: Maven 2.x Site Plugin
> Type: Improvement
> Components: doxia integration
> Versions: 2.0
> Reporter: Wendy Smoak
> Fix For: 2.0
> Attachments: msite-109.patch
>
>
> In m1, by default the .fml files are found anywhere under ${basedir}/xdocs.
> http://maven.apache.org/maven-1.x/plugins/faq/properties.html
> If the m2 site plugin is working from ${basedir}/xdocs, (or a configured
> 'xdocDirectory'), it should convert any .fml files it finds there.
> http://www.nabble.com/-m2-latest-site-plugin-with-m1-format-project%2C-and-skins--t1379592.html#a3708717
--
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: (MSITE-109) Site plugin should convert .fml files when working from xdocDirectory
[ http://jira.codehaus.org/browse/MSITE-109?page=comments#action_62762 ]
Emmanuel Venisse commented on MSITE-109:
I don't agree with this patch. fml files must be in fml directory and not in
xdoc directory
> Site plugin should convert .fml files when working from xdocDirectory
> -
>
> Key: MSITE-109
> URL: http://jira.codehaus.org/browse/MSITE-109
> Project: Maven 2.x Site Plugin
> Type: Improvement
> Components: doxia integration
> Versions: 2.0
> Reporter: Wendy Smoak
> Assignee: Brett Porter
> Fix For: 2.0
> Attachments: msite-109.patch
>
>
> In m1, by default the .fml files are found anywhere under ${basedir}/xdocs.
> http://maven.apache.org/maven-1.x/plugins/faq/properties.html
> If the m2 site plugin is working from ${basedir}/xdocs, (or a configured
> 'xdocDirectory'), it should convert any .fml files it finds there.
> http://www.nabble.com/-m2-latest-site-plugin-with-m1-format-project%2C-and-skins--t1379592.html#a3708717
--
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: (MPSITE-50) a way to ignore report failures
[ http://jira.codehaus.org/browse/MPSITE-50?page=all ] Shinobu Kawai Yoshida updated MPSITE-50: Attachment: MPSITE-50.patch > a way to ignore report failures > --- > > Key: MPSITE-50 > URL: http://jira.codehaus.org/browse/MPSITE-50 > Project: maven-site-plugin > Type: Wish > Components: plugin > Versions: 1.6.1 > Reporter: Shinobu Kawai Yoshida > Assignee: Lukas Theussl > Priority: Minor > Attachments: MPSITE-50.patch, MPSITE-50.patch > > > It would be great if there was a way to ignore report failures. Something > like a proprety called "maven.site.reports.failonerror". -- 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: (MSITE-98) Allow files to be excluded from site generation
[ http://jira.codehaus.org/browse/MSITE-98?page=comments#action_62766 ] Jesse McConnell commented on MSITE-98: -- I looked through this issue and the corresponding doxia issue and poked around on it and have it so we don't need to change any interfaces, plus we have a more general way of excluding sources based on the parserId maven-site-plugin 2.0-SNAPSHOT **/*oo.xml this will filter out any files that end in oo.xml from any of the xdoc modules, for example foo.xml is not processed using this example. I'll post the patch here and comment and close the other doxia issue, we want to try and avoid interface changes like this when the functionality fits pretty well in the SiteRenderingContext my 2 cents > Allow files to be excluded from site generation > --- > > Key: MSITE-98 > URL: http://jira.codehaus.org/browse/MSITE-98 > Project: Maven 2.x Site Plugin > Type: New Feature > Components: doxia integration > Reporter: Dennis Lundberg > Fix For: 2.0 > Attachments: MSITE-98.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] Commented: (MPSITE-50) a way to ignore report failures
[ http://jira.codehaus.org/browse/MPSITE-50?page=comments#action_62767 ] Lukas Theussl commented on MPSITE-50: - Can you provide a patch for the docs as well? What will happen if you set eg maven.checkstyle.fail.on.violation=true but maven.site.reports.failonerror=false? > a way to ignore report failures > --- > > Key: MPSITE-50 > URL: http://jira.codehaus.org/browse/MPSITE-50 > Project: maven-site-plugin > Type: Wish > Components: plugin > Versions: 1.6.1 > Reporter: Shinobu Kawai Yoshida > Assignee: Lukas Theussl > Priority: Minor > Attachments: MPSITE-50.patch, MPSITE-50.patch > > > It would be great if there was a way to ignore report failures. Something > like a proprety called "maven.site.reports.failonerror". -- 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: (MSITE-98) Allow files to be excluded from site generation
[ http://jira.codehaus.org/browse/MSITE-98?page=all ] Jesse McConnell updated MSITE-98: - Attachment: site-msite-98.patch doxia-msite-98.patch > Allow files to be excluded from site generation > --- > > Key: MSITE-98 > URL: http://jira.codehaus.org/browse/MSITE-98 > Project: Maven 2.x Site Plugin > Type: New Feature > Components: doxia integration > Reporter: Dennis Lundberg > Fix For: 2.0 > Attachments: MSITE-98.patch, doxia-msite-98.patch, site-msite-98.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] Closed: (DOXIA-54) Allow for the per module Renderer to exclude files from the rendering
[ http://jira.codehaus.org/browse/DOXIA-54?page=all ] Jesse McConnell closed DOXIA-54: Assign To: Jesse McConnell Resolution: Fixed closing this issue since I think we might have a less obtrusive fix on the parent issue thanks though, helped clue into the problem area > Allow for the per module Renderer to exclude files from the rendering > - > > Key: DOXIA-54 > URL: http://jira.codehaus.org/browse/DOXIA-54 > Project: doxia > Type: New Feature > Components: Site Renderer > Reporter: Dennis Lundberg > Assignee: Jesse McConnell > Attachments: DOXIA-54.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] Created: (SCM-181) Handle renumbered changelists
Handle renumbered changelists - Key: SCM-181 URL: http://jira.codehaus.org/browse/SCM-181 Project: Maven SCM Type: Bug Components: maven-scm-provider-perforce Reporter: Mike Perham Perforce can renumber a changelist if someone else sneaks in a changelist. http://www.perforce.com/perforce/doc.051/manuals/p4guide/07_changelists.html I just got this while testing the release plugin: [INFO] Transforming wif to snapshot [INFO] Checking in development POMs Provider message: Unable to submit Command output: Change 94821 renamed change 94823 and submitted. [INFO] -- [ERROR] BUILD ERROR [INFO] -- [INFO] An error is occurred in the checkin process. Embedded error: Error! Everything is ok (i.e. it was checked in successfully) but maven-scm thinks there was an error. -- 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: (MSITE-91) "src/site/site.xml" hardcoded in AbstractSiteMojo.java
[ http://jira.codehaus.org/browse/MSITE-91?page=all ]
Johann Reyes updated MSITE-91:
--
Attachment: MSITE-91.patch
> "src/site/site.xml" hardcoded in AbstractSiteMojo.java
> --
>
> Key: MSITE-91
> URL: http://jira.codehaus.org/browse/MSITE-91
> Project: Maven 2.x Site Plugin
> Type: Bug
> Versions: 2.0-beta-4
> Reporter: Fabrice BELLINGARD
> Fix For: 2.0
> Attachments: MSITE-91.patch
>
>
> There's a todo in the code, so this issue is more a reminder than an unknown
> bug.
> In AbstractSiteMojo.java, there's:
> protected File getSiteDescriptorFile( File basedir, Locale locale )
> {
> // TODO: get proper siteDirectory from site configuration of the
> project this relates to
> File siteDescriptor = new File( basedir, "src/site/site_" +
> locale.getLanguage() + ".xml" );
> if ( !siteDescriptor.exists() )
> {
> siteDescriptor = new File( basedir, "src/site/site.xml" );
> }
> return siteDescriptor;
> }
--
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: (SCM-181) Handle renumbered changelists
[ http://jira.codehaus.org/browse/SCM-181?page=all ] Mike Perham closed SCM-181: --- Assign To: Mike Perham Resolution: Fixed Fix Version: 1.0 Updated checkin consumer and added test case. > Handle renumbered changelists > - > > Key: SCM-181 > URL: http://jira.codehaus.org/browse/SCM-181 > Project: Maven SCM > Type: Bug > Components: maven-scm-provider-perforce > Reporter: Mike Perham > Assignee: Mike Perham > Fix For: 1.0 > > > Perforce can renumber a changelist if someone else sneaks in a changelist. > http://www.perforce.com/perforce/doc.051/manuals/p4guide/07_changelists.html > I just got this while testing the release plugin: > [INFO] Transforming wif to snapshot > [INFO] Checking in development POMs > Provider message: > Unable to submit > Command output: > Change 94821 renamed change 94823 and submitted. > [INFO] -- > [ERROR] BUILD ERROR > [INFO] -- > [INFO] An error is occurred in the checkin process. > Embedded error: Error! > Everything is ok (i.e. it was checked in successfully) but maven-scm thinks > there was an error. -- 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: (MSITE-109) Site plugin should convert .fml files when working from xdocDirectory
[ http://jira.codehaus.org/browse/MSITE-109?page=comments#action_62773 ]
Wendy Smoak commented on MSITE-109:
---
Then how about adding a element to go with the ?
The problem is that with a Maven-1 formatted project, which is what
is intended to help with, by default, the .fml files are in the
xdoc directory.
> Site plugin should convert .fml files when working from xdocDirectory
> -
>
> Key: MSITE-109
> URL: http://jira.codehaus.org/browse/MSITE-109
> Project: Maven 2.x Site Plugin
> Type: Improvement
> Components: doxia integration
> Versions: 2.0
> Reporter: Wendy Smoak
> Assignee: Brett Porter
> Fix For: 2.0
> Attachments: msite-109.patch
>
>
> In m1, by default the .fml files are found anywhere under ${basedir}/xdocs.
> http://maven.apache.org/maven-1.x/plugins/faq/properties.html
> If the m2 site plugin is working from ${basedir}/xdocs, (or a configured
> 'xdocDirectory'), it should convert any .fml files it finds there.
> http://www.nabble.com/-m2-latest-site-plugin-with-m1-format-project%2C-and-skins--t1379592.html#a3708717
--
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: (MCOMPILER-30) Compiler fork executable fails when the path has spaces
[ http://jira.codehaus.org/browse/MCOMPILER-30?page=all ]
Carlos Sanchez updated MCOMPILER-30:
Fix Version: 2.1
Merged to branch 2.0.x
> Compiler fork executable fails when the path has spaces
> ---
>
> Key: MCOMPILER-30
> URL: http://jira.codehaus.org/browse/MCOMPILER-30
> Project: Maven 2.x Compiler Plugin
> Type: Bug
> Versions: 2.0.1
> Reporter: Carlos Sanchez
> Assignee: Carlos Sanchez
> Fix For: 2.1, 2.0.2
>
>
> JAVA_1_3_HOME=C:\Program Files\Java\jdk1.3.1_18
>
> maven-compiler-plugin
>
> true
> 1.3
> ${JAVA_1_3_HOME}/bin/javac
>
>
> Fails with
> Failure executing javac, but could not parse the error:
> 'C:\Program' is not recognized as an internal or external command,
> operable program or batch file.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Created: (MEAR-25) EAR plugin fails when project contains a dependency of type pom
EAR plugin fails when project contains a dependency of type pom --- Key: MEAR-25 URL: http://jira.codehaus.org/browse/MEAR-25 Project: Maven 2.x Ear Plugin Type: Bug Versions: 2.0 Reporter: Evan Deaubl I have a project that constructs an EAR as an artifact, and it references a dependency of type pom, which is simply a project that lists dependencies provided by the platform we are deploying on (jboss). When I attempt to build the EAR, I receive the following error: [ERROR] FATAL ERROR [INFO] [INFO] Could not handle artifact type[pom] [INFO] [INFO] Trace java.lang.IllegalStateException: Could not handle artifact type[pom] at org.apache.maven.plugin.ear.EarModuleFactory.newEarModule(EarModuleFactory.java:75) at org.apache.maven.plugin.ear.AbstractEarMojo.execute(AbstractEarMojo.java:119) at org.apache.maven.plugin.ear.GenerateApplicationXmlMojo.execute(GenerateApplicationXmlMojo.java:96) ...trimmed output here... To my way of thinking, pom dependencies are Maven-internal, and should be ignored by the EAR plugin. -- 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: (MIDEA-37) Add functionality to create EAR modules.
[ http://jira.codehaus.org/browse/MIDEA-37?page=comments#action_62776 ] Johann Reyes commented on MIDEA-37: --- I believe this functionality has already been added to module as I see support for EAR packaging in the source code. > Add functionality to create EAR modules. > > > Key: MIDEA-37 > URL: http://jira.codehaus.org/browse/MIDEA-37 > Project: Maven 2.x Idea Plugin > Type: Improvement > Reporter: Aleksandr Tarutin > > > Add functionality to create EAR modules as per TODO added in IdeaModuleMojo. -- 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: (MSITE-98) Allow files to be excluded from site generation
[ http://jira.codehaus.org/browse/MSITE-98?page=comments#action_62779 ] Dennis Lundberg commented on MSITE-98: -- Jesse, I think that your solution is more elegant. Never mess with an interface unless it's necessary. I have been meaning to get back to this issue after Brett's refactoring, but haven't found the time. I'll give your patch a spin and see it works for my use case. > Allow files to be excluded from site generation > --- > > Key: MSITE-98 > URL: http://jira.codehaus.org/browse/MSITE-98 > Project: Maven 2.x Site Plugin > Type: New Feature > Components: doxia integration > Reporter: Dennis Lundberg > Assignee: Brett Porter > Fix For: 2.0 > Attachments: MSITE-98.patch, doxia-msite-98.patch, site-msite-98.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] Created: (CONTINUUM-648) IOException when user try to add a project with an url that contiains "*" like "http://svn.codehaus.org/*checkout*/trunk/pom.xml?root=plexus"
IOException when user try to add a project with an url that contiains "*" like "http://svn.codehaus.org/*checkout*/trunk/pom.xml?root=plexus"; - Key: CONTINUUM-648 URL: http://jira.codehaus.org/browse/CONTINUUM-648 Project: Continuum Type: Bug Versions: 1.0.3 Reporter: Emmanuel Venisse Assigned to: Emmanuel Venisse Fix For: 1.0.3 -- 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-648) IOException when user try to add a project with an url that contiains "*" like "http://svn.codehaus.org/*checkout*/trunk/pom.xml?root=plexus"
[ http://jira.codehaus.org/browse/CONTINUUM-648?page=all ] Emmanuel Venisse closed CONTINUUM-648: -- Resolution: Fixed > IOException when user try to add a project with an url that contiains "*" > like "http://svn.codehaus.org/*checkout*/trunk/pom.xml?root=plexus"; > - > > Key: CONTINUUM-648 > URL: http://jira.codehaus.org/browse/CONTINUUM-648 > Project: Continuum > Type: Bug > Versions: 1.0.3 > Reporter: Emmanuel Venisse > Assignee: Emmanuel Venisse > Fix For: 1.0.3 > > -- 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: (ARCHETYPE-33) Better Archetype template processing support
[ http://jira.codehaus.org/browse/ARCHETYPE-33?page=comments#action_62782 ] Jason van Zyl commented on ARCHETYPE-33: Can you explain what it is exactly you changed. You either have to comment or provide a patch so I can see the differences. > Better Archetype template processing support > > > Key: ARCHETYPE-33 > URL: http://jira.codehaus.org/browse/ARCHETYPE-33 > Project: Maven Archetype > Type: Improvement > Reporter: Aaron Anderson > Assignee: Jason van Zyl > Priority: Trivial > Attachments: new-archetype.zip > > > I really love the maven 2 archetype concept and have developed an enhanced > version that utilizes the velocity templating engine to a greater degree. > While the code is fully functionality it needs to be cleaned up and the > documentation enhanced. Please feel to incorporate any part of this back into > maven 2 if any of it is appealing. If desired I could also enhance the code > to make it a better contribution as well. > To test out the archetype functionallity, run mvn install in both archetype > (new plugin) and jbi-component (sample archetype) > to execute the new archetype, run > C:\temp\maventest> mvn > com.javaforge.bobber:bobber-archetype:1.0-SNAPSHOT:create > -DarchetypeGroupId=com.javaforge.bobber > -DarchetypeArtifactId=maven-archetype-jbi-component > -DarchetypeVersion=1.0-SNAPSHOT -DgroupId=com.newarchetype -DartifactId=test > in the same way the default archeype functionality works. -- 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: (ARCHETYPE-2) complete templates
[ http://jira.codehaus.org/browse/ARCHETYPE-2?page=all ] Jason van Zyl closed ARCHETYPE-2: - Resolution: Won't Fix Most of them exist and separate issues can be created for desired archetypes. > complete templates > -- > > Key: ARCHETYPE-2 > URL: http://jira.codehaus.org/browse/ARCHETYPE-2 > Project: Maven Archetype > Type: Improvement > Reporter: Brett Porter > > > finish the existing templates, and ensure there are templates for: > - maven plugin > - multiproject > - ear > - ejb > - rar > - site (or is this added to the others?) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVENUPLOAD-825) Generic DAO 1.0http://jira.codehaus.org/secure/CreateIssue.jspa
[ http://jira.codehaus.org/browse/MAVENUPLOAD-825?page=all ] Carlos Sanchez closed MAVENUPLOAD-825: -- Assign To: Carlos Sanchez Resolution: Fixed > Generic DAO 1.0http://jira.codehaus.org/secure/CreateIssue.jspa > --- > > Key: MAVENUPLOAD-825 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-825 > Project: maven-upload-requests > Type: Task > Reporter: Tim O'Brien > Assignee: Carlos Sanchez > > > Generic DAO 1.0 release -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVENUPLOAD-823) Prototype Taglib 1.1
[ http://jira.codehaus.org/browse/MAVENUPLOAD-823?page=all ] Carlos Sanchez closed MAVENUPLOAD-823: -- Resolution: Fixed > Prototype Taglib 1.1 > > > Key: MAVENUPLOAD-823 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-823 > Project: maven-upload-requests > Type: Task > Reporter: Tim O'Brien > > > Version 1.1. of the prototype jsp taglib -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVENUPLOAD-824) Reference Taglib 1.0
[ http://jira.codehaus.org/browse/MAVENUPLOAD-824?page=all ] Carlos Sanchez closed MAVENUPLOAD-824: -- Assign To: Carlos Sanchez Resolution: Fixed > Reference Taglib 1.0 > > > Key: MAVENUPLOAD-824 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-824 > Project: maven-upload-requests > Type: Task > Reporter: Tim O'Brien > Assignee: Carlos Sanchez > > > Version 1.0 of the Reference Taglib -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVENUPLOAD-812) iCal4j 0.9.19 - Maven bundle
[ http://jira.codehaus.org/browse/MAVENUPLOAD-812?page=all ] Carlos Sanchez closed MAVENUPLOAD-812: -- Assign To: Carlos Sanchez Resolution: Fixed > iCal4j 0.9.19 - Maven bundle > > > Key: MAVENUPLOAD-812 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-812 > Project: maven-upload-requests > Type: Task > Reporter: Ben Fortuna > Assignee: Carlos Sanchez > > > http://ical4j.sourceforge.net/maven/ical4j-0.9.19-bundle.jar > http://ical4j.sourceforge.net > http://sourceforge.net/users/fortuna > A Java library for reading and writing iCalendar (*.ics) files. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVENUPLOAD-795) daisy html cleaner library
[ http://jira.codehaus.org/browse/MAVENUPLOAD-795?page=all ] Carlos Sanchez closed MAVENUPLOAD-795: -- Assign To: Carlos Sanchez Resolution: Fixed > daisy html cleaner library > -- > > Key: MAVENUPLOAD-795 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-795 > Project: maven-upload-requests > Type: Task > Reporter: Jorg Heymans > Assignee: Carlos Sanchez > > > please add to ibiblio/maven2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-813) CAS Extend Client
[ http://jira.codehaus.org/browse/MAVENUPLOAD-813?page=comments#action_62785 ] Carlos Sanchez commented on MAVENUPLOAD-813: sources have to be inside the bundle, you can check the instructions > CAS Extend Client > - > > Key: MAVENUPLOAD-813 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-813 > Project: maven-upload-requests > Type: Task > Reporter: Tim O'Brien > > > I've also assembled the sources here: > http://brahe.discursive.com/cas-extend-client-java-2.1.1-sources.jar > This is an extension of the CAS client that adds some features aimed at > development with the canonical cas client. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVENUPLOAD-821) JCommon 1.0.2
[ http://jira.codehaus.org/browse/MAVENUPLOAD-821?page=all ] Carlos Sanchez closed MAVENUPLOAD-821: -- Assign To: Carlos Sanchez Resolution: Fixed > JCommon 1.0.2 > - > > Key: MAVENUPLOAD-821 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-821 > Project: maven-upload-requests > Type: Task > Reporter: Takayoshi Kimura > Assignee: Carlos Sanchez > Attachments: jcommon-1.0.2-bundle.jar > > > http://www.jfree.org/jcommon/ -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVENUPLOAD-820) JFreeChart 1.0.1
[ http://jira.codehaus.org/browse/MAVENUPLOAD-820?page=all ] Carlos Sanchez closed MAVENUPLOAD-820: -- Assign To: Carlos Sanchez Resolution: Fixed > JFreeChart 1.0.1 > > > Key: MAVENUPLOAD-820 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-820 > Project: maven-upload-requests > Type: Task > Reporter: Takayoshi Kimura > Assignee: Carlos Sanchez > Attachments: jfreechart-1.0.1-bundle.jar > > > http://www.jfree.org/jfreechart/ -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVENUPLOAD-822) Weblets 0.4
[ http://jira.codehaus.org/browse/MAVENUPLOAD-822?page=all ] Carlos Sanchez closed MAVENUPLOAD-822: -- Assign To: Carlos Sanchez Resolution: Fixed > Weblets 0.4 > --- > > Key: MAVENUPLOAD-822 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-822 > Project: maven-upload-requests > Type: Task > Reporter: John R Fallows > Assignee: Carlos Sanchez > > > https://weblets.dev.java.net/files/documents/4141/32209/weblets-0.4-bundle.jar > https://weblets.dev.java.net/files/documents/4141/32210/weblets-api-0.4-bundle.jar > https://weblets.dev.java.net/files/documents/4141/32211/weblets-impl-0.4-bundle.jar > Please note: we do not use a public URL for the Apache 2.0 License because > this causes network connectivity requirements during site generation, as the > license is downloaded. > Many thanks in advance. -- 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-2201) Interpolation problem when using surefire
[ http://jira.codehaus.org/browse/MNG-2201?page=all ]
John Casey updated MNG-2201:
Priority: Critical (was: Blocker)
Assign To: John Casey
Version: 2.0
2.0.1
2.0.2
2.0.3
Fix Version: 2.0.5
Complexity: Expert (was: Intermediate)
Remaining Estimate: 4 hours
Original Estimate: 4 hours
test is it0104.
> Interpolation problem when using surefire
> -
>
> Key: MNG-2201
> URL: http://jira.codehaus.org/browse/MNG-2201
> Project: Maven 2
> Type: Bug
> Components: Inheritence and Interpolation
> Versions: 2.0, 2.0.1, 2.0.2, 2.0.3, 2.0.4
> Reporter: Vincent Massol
> Assignee: John Casey
> Priority: Critical
> Fix For: 2.0.5
>
> Original Estimate: 4 hours
> Remaining: 4 hours
>
> I've just tried the cargo build with the latest trunk versions of
> 2.0.4-SNAPSHOT and surefire plugin, and it seems there's some interpolation
> issue (I don't know if the problem is with the surefire plugin or with maven
> core).
> Here's what I have:
> {code:xml}
>
>
>
>
> maven-surefire-plugin
>
> pertest
>
> [...]
>
> cargo.target.dir
> ${project.build.directory}
>
> [...]
> {code}
> It seems the ${project.build.directory} property is no longer getting
> resolved as I got a directory named ${project.build.directory} created.
> It used to work fine before.
--
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: (MECLIPSE-90) Provide a way to not generate .classpath and only a .project file
[ http://jira.codehaus.org/browse/MECLIPSE-90?page=all ] fabrizio giustina closed MECLIPSE-90: - Assign To: fabrizio giustina Resolution: Fixed Fix Version: 2.2 version 2.2 will generate a classpath file only for java-capable projects (checking artifactHandler.getLanguage() ). If you pom specify a custom packaging a classpath file (and related natures/builders in .project) will not be added > Provide a way to not generate .classpath and only a .project file > - > > Key: MECLIPSE-90 > URL: http://jira.codehaus.org/browse/MECLIPSE-90 > Project: Maven 2.x Eclipse Plugin > Type: Bug > Versions: 2.1 > Reporter: Sachin Patel > Assignee: fabrizio giustina > Fix For: 2.2 > > > When running eclipse:eclipse against a set of "eclipse-feature" projects, > these modules do not contain any source thus a .classpath should not be > generated for them. Need a way to generate only the .project file in order > to better support "eclipse-plugin-development" with maven. -- 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-2201) Interpolation problem when using surefire
[ http://jira.codehaus.org/browse/MNG-2201?page=all ]
John Casey closed MNG-2201:
---
Resolution: Fixed
fixing for 2.0.5, since this requires a new release of plexus-container-default.
The problem is in the handling of parameters of type java.util.Properties. The
PropertiesConverter (used in plexus to coerce DOMs into Properties instances)
doesn't use the expression evaluator on the values. I've fixed this in SVN, but
the newest version of p-c-d could introduce significant risks into the 2.0.4
release of Maven, which is meant to be as quick as possible, to correct two
glaring regressions.
> Interpolation problem when using surefire
> -
>
> Key: MNG-2201
> URL: http://jira.codehaus.org/browse/MNG-2201
> Project: Maven 2
> Type: Bug
> Components: Inheritence and Interpolation
> Versions: 2.0, 2.0.1, 2.0.2, 2.0.3, 2.0.4
> Reporter: Vincent Massol
> Assignee: John Casey
> Priority: Critical
> Fix For: 2.0.5
>
> Original Estimate: 4 hours
> Remaining: 4 hours
>
> I've just tried the cargo build with the latest trunk versions of
> 2.0.4-SNAPSHOT and surefire plugin, and it seems there's some interpolation
> issue (I don't know if the problem is with the surefire plugin or with maven
> core).
> Here's what I have:
> {code:xml}
>
>
>
>
> maven-surefire-plugin
>
> pertest
>
> [...]
>
> cargo.target.dir
> ${project.build.directory}
>
> [...]
> {code}
> It seems the ${project.build.directory} property is no longer getting
> resolved as I got a directory named ${project.build.directory} created.
> It used to work fine before.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-814) Saxon 8.7
[ http://jira.codehaus.org/browse/MAVENUPLOAD-814?page=comments#action_62792 ] Carlos Sanchez commented on MAVENUPLOAD-814: Next time please create only one issue and paste all the urls in the description There are no dependencies, with jaranalyzer i see that the submodules depend on saxon http://jroller.com/page/carlossg?entry=analyzing_jar_dependencies You should create relocation poms for the artifacts already under saxon group, something like: 4.0.0 saxon saxon 8.7 net.sf.saxon > Saxon 8.7 > - > > Key: MAVENUPLOAD-814 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-814 > Project: maven-upload-requests > Type: Task > Reporter: Tim O'Brien > > > This is Saxon 8.7. If you click on the contributor link below you will see a > mail thread from the saxon help list where Michael Kay give explicit > permission to upload these artifacts to the Maven 2 repository. -- 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-814) Saxon 8.7
[ http://jira.codehaus.org/browse/MAVENUPLOAD-814?page=all ] Carlos Sanchez updated MAVENUPLOAD-814: --- Attachment: dep.png > Saxon 8.7 > - > > Key: MAVENUPLOAD-814 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-814 > Project: maven-upload-requests > Type: Task > Reporter: Tim O'Brien > Attachments: dep.png > > > This is Saxon 8.7. If you click on the contributor link below you will see a > mail thread from the saxon help list where Michael Kay give explicit > permission to upload these artifacts to the Maven 2 repository. -- 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: (MECLIPSE-64) Allow Natures and Builders to be Added instead of Replaced
[ http://jira.codehaus.org/browse/MECLIPSE-64?page=all ] fabrizio giustina closed MECLIPSE-64: - Assign To: fabrizio giustina Resolution: Fixed Fix Version: 2.2 new properties additionalProjectNatures and additionalBuildcommands added for 2.2 > Allow Natures and Builders to be Added instead of Replaced > -- > > Key: MECLIPSE-64 > URL: http://jira.codehaus.org/browse/MECLIPSE-64 > Project: Maven 2.x Eclipse Plugin > Type: Improvement > Reporter: Stephen Duncan Jr > Assignee: fabrizio giustina > Fix For: 2.2 > > > Currently when you specify natures and builders, they replace the default > ones, instead of adding on to them. I would like to add a nature and a > builder to the plugin. My use case is being able to add > org.springframework.ide.eclipse.core.springnature > and > org.springframework.ide.eclipse.core.springbuilder > to a project. I would like to do this with a profile so that these can be > added onto a project if you have Spring IDE installed. This could be a > applied to a jar or a war project, so I won't know ahead of time what the > other natuers or buildcommands should be. -- 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: (MECLIPSE-93) Incorrect src entry being added in .classpath for referenced projects
[ http://jira.codehaus.org/browse/MECLIPSE-93?page=all ] fabrizio giustina closed MECLIPSE-93: - Assign To: fabrizio giustina Resolution: Won't Fix Fix Version: (was: 2.2) 2.1 Referenced projects NEED to added to .classpath as source paths for eclipse. You can verify this by adding a project reference in the "Build path" dialog. > Incorrect src entry being added in .classpath for referenced projects > - > > Key: MECLIPSE-93 > URL: http://jira.codehaus.org/browse/MECLIPSE-93 > Project: Maven 2.x Eclipse Plugin > Type: Bug > Versions: 2.1 > Reporter: Sachin Patel > Assignee: fabrizio giustina > Fix For: 2.1 > > > The generated .classpath contains src entries for each project referenced in > the .project. This is incorrect, these entries should be removed. For > example.. > Consider Project A and Project B. If A depends on B, A's .project file > contains a reference to Project B which is correct, but its classpath > contains a src entry to the root of B, which should not be there. > There seem to be additional src entries as well, which seems to mess things > up (at least for eclipse-plugin development) which I'll dig into and open > jiras on 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: (MECLIPSE-19) Create Settings Based on Package Type
[ http://jira.codehaus.org/browse/MECLIPSE-19?page=all ] fabrizio giustina closed MECLIPSE-19: - Assign To: fabrizio giustina Resolution: Duplicate same as MECLIPSE-94 I'm going to mark this as duplicate and leave MECLIPSE-94 open since MECLIPSE-94 contains a more detailed description > Create Settings Based on Package Type > - > > Key: MECLIPSE-19 > URL: http://jira.codehaus.org/browse/MECLIPSE-19 > Project: Maven 2.x Eclipse Plugin > Type: Bug > Versions: 2.0 > Reporter: Stephen Duncan Jr > Assignee: fabrizio giustina > > > If pom is specified, the Eclipse project should be a > simple project with no builders or natures. If it's > jar then none of the WTP natures or builders should be > added. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-64) move all relevant site rendering code into doxia, so that reports can also generate proper decoration and skinning
[ http://jira.codehaus.org/browse/MSITE-64?page=comments#action_62798 ] Jesse McConnell commented on MSITE-64: -- I have a couple ideas of what this could mean but could you elaborate on what you are looking for brett? this is the last site issue for 2.0 that I think is doxia related so would like to get this wrapped up so maybe we can schedule a doxia release...I should go through doxia and look for blockers as well..I'll do that next... > move all relevant site rendering code into doxia, so that reports can also > generate proper decoration and skinning > -- > > Key: MSITE-64 > URL: http://jira.codehaus.org/browse/MSITE-64 > Project: Maven 2.x Site Plugin > Type: Improvement > Components: doxia integration > Reporter: Brett Porter > Fix For: 2.0 > > > currently, standalone reports always get the default -- 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: (MECLIPSE-93) Incorrect src entry being added in .classpath for referenced projects
[ http://jira.codehaus.org/browse/MECLIPSE-93?page=comments#action_62800 ] Sachin Patel commented on MECLIPSE-93: -- Sorry, yes you are correct. > Incorrect src entry being added in .classpath for referenced projects > - > > Key: MECLIPSE-93 > URL: http://jira.codehaus.org/browse/MECLIPSE-93 > Project: Maven 2.x Eclipse Plugin > Type: Bug > Versions: 2.1 > Reporter: Sachin Patel > Assignee: fabrizio giustina > Fix For: 2.1 > > > The generated .classpath contains src entries for each project referenced in > the .project. This is incorrect, these entries should be removed. For > example.. > Consider Project A and Project B. If A depends on B, A's .project file > contains a reference to Project B which is correct, but its classpath > contains a src entry to the root of B, which should not be there. > There seem to be additional src entries as well, which seems to mess things > up (at least for eclipse-plugin development) which I'll dig into and open > jiras on 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: (MNG-2188) Report mojos should check canGenerateReport() when called directly
[ http://jira.codehaus.org/browse/MNG-2188?page=all ]
Walco van Loon updated MNG-2188:
Attachment: AbstractMavenReport-canGenerateReport-check.patch
> Report mojos should check canGenerateReport() when called directly
> --
>
> Key: MNG-2188
> URL: http://jira.codehaus.org/browse/MNG-2188
> Project: Maven 2
> Type: Improvement
> Components: Sites & Reporting
> Versions: 2.0.3
> Reporter: Vincent Massol
> Attachments: AbstractMavenReport-canGenerateReport-check.patch
>
>
> There's a canGenerateReport() method in a ReportMojo. This method is called
> by the site phase to decide if the mojo should be called or not. This is
> cool. However the user can call directly the report mojo and in that case the
> canGenerateReport() method is not called automatically. Thus the solution for
> a plugin developer is to write:
> {code}
> public void executeReport()
> {
> if (canGenerateReport() )
> {
> [...]
> }
> }
> {code}
> Which means that the canGenerateReport method is going to be called twice
> when mvn site is executed.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (MECLIPSE-94) Allow eclipse:eclipse to work on pom (and other) projects
[ http://jira.codehaus.org/browse/MECLIPSE-94?page=comments#action_62802 ] Stephen Duncan Jr commented on MECLIPSE-94: --- As http://jira.codehaus.org/browse/MECLIPSE-19 was marked as a duplicate of this, I'll flesh out some details here. 1) My request about JAR projects is apparently incorrect, and the addition of the wtpversion attribute solves the real issue which was a desire not to have WTP builders for jar projects 2) For POM projects, there are two current behaviors. a) When simply running eclipse:eclipse for a POM project, the project is skipped. I think this is incorrect behavior, and should instead create a .project file for an Eclipse "Simple Project" with no builders, etc. This is somewhat in contrast to the request here, as it sounds like Felipe wants to generate a Java Project. That could still be effectively done with specifying builders or something, but it may be that a more convenient mechanism is needed. b) when running eclipse:eclipse -Declipse.workspace=/path/to/workspace, a project for the POM packaged artifact IS created, and it IS a java project. Again, in that case, I would like it to be changed to be a Simple Project (no builders or natures). That was what my original request was about. Feel free to separate this back out into separate requests or re-open MECLIPSE-19 if this clarification indicates that they are not really duplicates... > Allow eclipse:eclipse to work on pom (and other) projects > - > > Key: MECLIPSE-94 > URL: http://jira.codehaus.org/browse/MECLIPSE-94 > Project: Maven 2.x Eclipse Plugin > Type: Improvement > Versions: 2.1 > Reporter: Felipe Leme > > > I'm creating a Java EE project based on the m2book (which I was reviewing; > it's not available yet...) and one of the projects is a pom-packaging project > used for integration tests. According to Vincent, currently this project must > be a pom (in fact, I tried to set it as jar, but then the test phase would be > run anyway, which would cause the tests to fail), as it doesn't produces a > jar. But as it has java files (on the src/main/it/java directory), I tried to > call eclipse:eclipse but it fails, saying that "Not running eclipse plugin > goal for pom project". > For these scenarios, I think a propery would be enough. At first I thought > something about a 'force' or 'forceGeneration' property, would enough, which > the code change being from: > if ( "pom".equals( packaging ) && eclipseProjectDir == null ) > to: > if ( "pom".equals( packaging ) && eclipseProjectDir == null && > !forceGeneration ) > Then I realized there is other place where the pom nature is checked: > if ( "pom".equals( packaging ) && eclipseProjectDir == null && > !forceGeneration ) > So, I think a better name for the property would be 'javaProject' and the > change would be: > final boolean isJavaProjectProperty = // read property; defaults to false... > if ( "pom".equals( packaging ) && eclipseProjectDir == null && > !isJavaProjectProperty ) > isJavaProject = isJavaProjectProperty || !"ear".equals( packaging ) && > !"pom".equals( packaging ); > If nobody objects and someone is willing to apply the changes, I can provide > such patch (with the proper test cases). > -- Felipe > PS: I'm assigning it to Vincent for now, as he 'dreamed' that such features > already existed :-) -- 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: (MECLIPSE-93) Incorrect src entry being added in .classpath for referenced projects
[ http://jira.codehaus.org/browse/MECLIPSE-93?page=all ] Sachin Patel reopened MECLIPSE-93: -- Actually, sorry will need to reopen this. While the statement is true for Java Projects, for plugin development it is not. Plugin bundles reference other plugins and their references to each other are configured via the requiredPlugins classpath container. By including src entries to the referenced "plugins" this results in an error. I'm beginning to think it would be useful to provide a flag in the configuration to better handle the "plugin-development" case. > Incorrect src entry being added in .classpath for referenced projects > - > > Key: MECLIPSE-93 > URL: http://jira.codehaus.org/browse/MECLIPSE-93 > Project: Maven 2.x Eclipse Plugin > Type: Bug > Versions: 2.1 > Reporter: Sachin Patel > Assignee: fabrizio giustina > Fix For: 2.1 > > > The generated .classpath contains src entries for each project referenced in > the .project. This is incorrect, these entries should be removed. For > example.. > Consider Project A and Project B. If A depends on B, A's .project file > contains a reference to Project B which is correct, but its classpath > contains a src entry to the root of B, which should not be there. > There seem to be additional src entries as well, which seems to mess things > up (at least for eclipse-plugin development) which I'll dig into and open > jiras on 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] Commented: (MECLIPSE-93) Incorrect src entry being added in .classpath for referenced projects
[ http://jira.codehaus.org/browse/MECLIPSE-93?page=comments#action_62804 ] Sachin Patel commented on MECLIPSE-93: -- Along with not adding src entries for referenced "plugin-projects" project references should be removed as well in the .project file. > Incorrect src entry being added in .classpath for referenced projects > - > > Key: MECLIPSE-93 > URL: http://jira.codehaus.org/browse/MECLIPSE-93 > Project: Maven 2.x Eclipse Plugin > Type: Bug > Versions: 2.1 > Reporter: Sachin Patel > Assignee: fabrizio giustina > Fix For: 2.1 > > > The generated .classpath contains src entries for each project referenced in > the .project. This is incorrect, these entries should be removed. For > example.. > Consider Project A and Project B. If A depends on B, A's .project file > contains a reference to Project B which is correct, but its classpath > contains a src entry to the root of B, which should not be there. > There seem to be additional src entries as well, which seems to mess things > up (at least for eclipse-plugin development) which I'll dig into and open > jiras on 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] Commented: (MECLIPSE-94) Allow eclipse:eclipse to work on pom (and other) projects
[ http://jira.codehaus.org/browse/MECLIPSE-94?page=comments#action_62807 ] Felipe Leme commented on MECLIPSE-94: - Hi Stephen, Independently of being duplicated issues, I think your reasoning makes more sense, i.e, always generate a simple eclipse project for a pom-packaging M2 project - and if it's necessary to set it as java, use the natures property (although it might be necessary to change the isJavaProject assignment to reflect that nature - I don't have the code available right now to answer for sure). Regarding the -Declipse.workspace property, I guess that explain the eclipseProjectDir == null comparisson; anyway, I still think that's not enough, as it would require each developer to set a property in order to setup the project... -- Felipe > Allow eclipse:eclipse to work on pom (and other) projects > - > > Key: MECLIPSE-94 > URL: http://jira.codehaus.org/browse/MECLIPSE-94 > Project: Maven 2.x Eclipse Plugin > Type: Improvement > Versions: 2.1 > Reporter: Felipe Leme > > > I'm creating a Java EE project based on the m2book (which I was reviewing; > it's not available yet...) and one of the projects is a pom-packaging project > used for integration tests. According to Vincent, currently this project must > be a pom (in fact, I tried to set it as jar, but then the test phase would be > run anyway, which would cause the tests to fail), as it doesn't produces a > jar. But as it has java files (on the src/main/it/java directory), I tried to > call eclipse:eclipse but it fails, saying that "Not running eclipse plugin > goal for pom project". > For these scenarios, I think a propery would be enough. At first I thought > something about a 'force' or 'forceGeneration' property, would enough, which > the code change being from: > if ( "pom".equals( packaging ) && eclipseProjectDir == null ) > to: > if ( "pom".equals( packaging ) && eclipseProjectDir == null && > !forceGeneration ) > Then I realized there is other place where the pom nature is checked: > if ( "pom".equals( packaging ) && eclipseProjectDir == null && > !forceGeneration ) > So, I think a better name for the property would be 'javaProject' and the > change would be: > final boolean isJavaProjectProperty = // read property; defaults to false... > if ( "pom".equals( packaging ) && eclipseProjectDir == null && > !isJavaProjectProperty ) > isJavaProject = isJavaProjectProperty || !"ear".equals( packaging ) && > !"pom".equals( packaging ); > If nobody objects and someone is willing to apply the changes, I can provide > such patch (with the proper test cases). > -- Felipe > PS: I'm assigning it to Vincent for now, as he 'dreamed' that such features > already existed :-) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-822) Weblets 0.4
[ http://jira.codehaus.org/browse/MAVENUPLOAD-822?page=comments#action_62808 ] John R Fallows commented on MAVENUPLOAD-822: Have all three bundles been uploaded to ibiblio? http://www.ibiblio.org/maven2/net/java/dev/weblets/ Currently, the weblets 0.4 pom from the first bundle is visible, but neither api nor impl bundles (incl. sources) are visible. > Weblets 0.4 > --- > > Key: MAVENUPLOAD-822 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-822 > Project: maven-upload-requests > Type: Task > Reporter: John R Fallows > Assignee: Carlos Sanchez > > > https://weblets.dev.java.net/files/documents/4141/32209/weblets-0.4-bundle.jar > https://weblets.dev.java.net/files/documents/4141/32210/weblets-api-0.4-bundle.jar > https://weblets.dev.java.net/files/documents/4141/32211/weblets-impl-0.4-bundle.jar > Please note: we do not use a public URL for the Apache 2.0 License because > this causes network connectivity requirements during site generation, as the > license is downloaded. > Many thanks in advance. -- 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: (MSITE-64) move all relevant site rendering code into doxia, so that reports can also generate proper decoration and skinning
[ http://jira.codehaus.org/browse/MSITE-64?page=comments#action_62809 ] Brett Porter commented on MSITE-64: --- I think this is basically done, and now just requires wiring in the code to AbstractMavenReport, so could be moved to MNG > move all relevant site rendering code into doxia, so that reports can also > generate proper decoration and skinning > -- > > Key: MSITE-64 > URL: http://jira.codehaus.org/browse/MSITE-64 > Project: Maven 2.x Site Plugin > Type: Improvement > Components: doxia integration > Reporter: Brett Porter > Assignee: Brett Porter > Fix For: 2.0 > > > currently, standalone reports always get the default -- 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: (MSITE-64) move all relevant site rendering code into doxia, so that reports can also generate proper decoration and skinning
[ http://jira.codehaus.org/browse/MSITE-64?page=comments#action_62810 ] Brett Porter commented on MSITE-64: --- ... but I think I left it here to actually prove that first > move all relevant site rendering code into doxia, so that reports can also > generate proper decoration and skinning > -- > > Key: MSITE-64 > URL: http://jira.codehaus.org/browse/MSITE-64 > Project: Maven 2.x Site Plugin > Type: Improvement > Components: doxia integration > Reporter: Brett Porter > Assignee: Brett Porter > Fix For: 2.0 > > > currently, standalone reports always get the default -- 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: (MIDEA-44) Optional toggle switch to revert MIDEA-35
[ http://jira.codehaus.org/browse/MIDEA-44?page=comments#action_62811 ] Brett Porter commented on MIDEA-44: --- defaulted it to false. Maybe you could file this as an issue at IntelliJ? > Optional toggle switch to revert MIDEA-35 > - > > Key: MIDEA-44 > URL: http://jira.codehaus.org/browse/MIDEA-44 > Project: Maven 2.x Idea Plugin > Type: Improvement > Reporter: Patrick Lightbody > Assignee: Brett Porter > Fix For: 2.0 > Attachments: useShortDependencyNames.patch > > > I never had any problems with the short names that were removed when MIDEA-35 > was fixed, but I believe the reporter that it can cause problems. However, I > think that it is a useful enough feature that users should be able to turn it > on if they want to. So here is a patch that does that. -- 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: (MSITE-109) Site plugin should convert .fml files when working from xdocDirectory
[ http://jira.codehaus.org/browse/MSITE-109?page=comments#action_62812 ]
Brett Porter commented on MSITE-109:
I don't think separate configuration is needed, but this should not be in doxia
(as this would pick up fml files from src/site/xdoc). I think it is a simple
fix in the site plugin to reprocess the module
> Site plugin should convert .fml files when working from xdocDirectory
> -
>
> Key: MSITE-109
> URL: http://jira.codehaus.org/browse/MSITE-109
> Project: Maven 2.x Site Plugin
> Type: Improvement
> Components: doxia integration
> Versions: 2.0
> Reporter: Wendy Smoak
> Assignee: Brett Porter
> Fix For: 2.0
> Attachments: msite-109.patch
>
>
> In m1, by default the .fml files are found anywhere under ${basedir}/xdocs.
> http://maven.apache.org/maven-1.x/plugins/faq/properties.html
> If the m2 site plugin is working from ${basedir}/xdocs, (or a configured
> 'xdocDirectory'), it should convert any .fml files it finds there.
> http://www.nabble.com/-m2-latest-site-plugin-with-m1-format-project%2C-and-skins--t1379592.html#a3708717
--
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: (MSITE-109) Site plugin should convert .fml files when working from xdocDirectory
[ http://jira.codehaus.org/browse/MSITE-109?page=all ]
Brett Porter closed MSITE-109:
--
Resolution: Fixed
> Site plugin should convert .fml files when working from xdocDirectory
> -
>
> Key: MSITE-109
> URL: http://jira.codehaus.org/browse/MSITE-109
> Project: Maven 2.x Site Plugin
> Type: Improvement
> Components: doxia integration
> Versions: 2.0
> Reporter: Wendy Smoak
> Assignee: Brett Porter
> Fix For: 2.0
> Attachments: msite-109.patch
>
>
> In m1, by default the .fml files are found anywhere under ${basedir}/xdocs.
> http://maven.apache.org/maven-1.x/plugins/faq/properties.html
> If the m2 site plugin is working from ${basedir}/xdocs, (or a configured
> 'xdocDirectory'), it should convert any .fml files it finds there.
> http://www.nabble.com/-m2-latest-site-plugin-with-m1-format-project%2C-and-skins--t1379592.html#a3708717
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-686) Please, upload JXTA 2.3.6 to the ibiblio repository.
[ http://jira.codehaus.org/browse/MAVENUPLOAD-686?page=comments#action_62814 ] Peter K Chan commented on MAVENUPLOAD-686: -- There is a small issue with the pom.xml dependency list. The jaxen dependency should be 1.0-FCS, not 1.0-FCS-full (perhaps that was an older reference to a version that is no longer available?). > Please, upload JXTA 2.3.6 to the ibiblio repository. > > > Key: MAVENUPLOAD-686 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-686 > Project: maven-upload-requests > Type: Task > Reporter: Loic Lefevre > Assignee: Carlos Sanchez > > > http://lolosav.free.fr/dev/jxta-2.3.6-bundle.jar > JXTA peers create a virtual network where any peer can interact with other > peers and resources directly even when some of the peers and resources are > behind firewalls and NATs or are on different network transports. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-686) Please, upload JXTA 2.3.6 to the ibiblio repository.
[ http://jira.codehaus.org/browse/MAVENUPLOAD-686?page=comments#action_62815 ] Carlos Sanchez commented on MAVENUPLOAD-686: Peter, if you have any problem please use http://jira.codehaus.org/browse/MEV > Please, upload JXTA 2.3.6 to the ibiblio repository. > > > Key: MAVENUPLOAD-686 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-686 > Project: maven-upload-requests > Type: Task > Reporter: Loic Lefevre > Assignee: Carlos Sanchez > > > http://lolosav.free.fr/dev/jxta-2.3.6-bundle.jar > JXTA peers create a virtual network where any peer can interact with other > peers and resources directly even when some of the peers and resources are > behind firewalls and NATs or are on different network transports. -- 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: (MIDEA-44) Optional toggle switch to revert MIDEA-35
[ http://jira.codehaus.org/browse/MIDEA-44?page=comments#action_62816 ] Johann Reyes commented on MIDEA-44: --- This is a bug with idea for the 5.x series. It's fixed in the new version of idea not yet released as per http://www.jetbrains.net/jira/browse/IDEADEV-4966. And this is a bug specific with module named libraries. To quote reply: BTW, this bug occurs only with a named module-level libraries. As a workaround you can use project-level libraries or unnamed module libraries instead. > Optional toggle switch to revert MIDEA-35 > - > > Key: MIDEA-44 > URL: http://jira.codehaus.org/browse/MIDEA-44 > Project: Maven 2.x Idea Plugin > Type: Improvement > Reporter: Patrick Lightbody > Assignee: Brett Porter > Fix For: 2.0 > Attachments: useShortDependencyNames.patch > > > I never had any problems with the short names that were removed when MIDEA-35 > was fixed, but I believe the reporter that it can cause problems. However, I > think that it is a useful enough feature that users should be able to turn it > on if they want to. So here is a patch that does that. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-814) Saxon 8.7
[ http://jira.codehaus.org/browse/MAVENUPLOAD-814?page=comments#action_62821 ] Tim O'Brien commented on MAVENUPLOAD-814: - Carlos, sorry for not populating dependencies. I've populated dependencies (everything depends on saxon, saxon-jdom depends on jdom-1.0 and saxon-xom depends on xom-1.1. Here are the addresses of the regenerated bundles: http://brahe.discursive.com/saxon-8.7-bundle.jar http://brahe.discursive.com/saxon-dom-8.7-bundle.jar http://brahe.discursive.com/saxon-jdom-8.7-bundle.jar http://brahe.discursive.com/saxon-sql-8.7-bundle.jar http://brahe.discursive.com/saxon-xom-8.7-bundle.jar http://brahe.discursive.com/saxon-xpath-8.7-bundle.jar And, finally, I created a bundle that contains a relocation record for the old groupId http://brahe.discursive.com/relocate-saxon-8.7-bundle.jar > Saxon 8.7 > - > > Key: MAVENUPLOAD-814 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-814 > Project: maven-upload-requests > Type: Task > Reporter: Tim O'Brien > Attachments: dep.png > > > This is Saxon 8.7. If you click on the contributor link below you will see a > mail thread from the saxon help list where Michael Kay give explicit > permission to upload these artifacts to the Maven 2 repository. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVENUPLOAD-817) Saxon SQL Exensions 8.7
[ http://jira.codehaus.org/browse/MAVENUPLOAD-817?page=all ] Tim O'Brien closed MAVENUPLOAD-817: --- Resolution: Fixed Closing this issue, MAVENUPLOAD-814 takes the place of this issue. > Saxon SQL Exensions 8.7 > --- > > Key: MAVENUPLOAD-817 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-817 > Project: maven-upload-requests > Type: Task > Reporter: Tim O'Brien > > > Click on contributor link for message from Michael Kay authorizing adding > Saxon to Maven 2 repository. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVENUPLOAD-815) Saxon DOM 8.7
[ http://jira.codehaus.org/browse/MAVENUPLOAD-815?page=all ] Tim O'Brien closed MAVENUPLOAD-815: --- Resolution: Fixed Closing this issue, MAVENUPLOAD-814 takes the place of this issue. > Saxon DOM 8.7 > - > > Key: MAVENUPLOAD-815 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-815 > Project: maven-upload-requests > Type: Task > Reporter: Tim O'Brien > > > This is the DOM library for Saxon 8.7. Click on the contributor link to see > a message from Michael Kay providing explicit permission to add this to the > repo. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVENUPLOAD-816) Saxon JDOM 8.7
[ http://jira.codehaus.org/browse/MAVENUPLOAD-816?page=all ] Tim O'Brien closed MAVENUPLOAD-816: --- Resolution: Fixed Closing this issue, MAVENUPLOAD-814 takes the place of this issue. > Saxon JDOM 8.7 > -- > > Key: MAVENUPLOAD-816 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-816 > Project: maven-upload-requests > Type: Task > Reporter: Tim O'Brien > > > Saxon JDOM Library. Click on contributor link for message from Michael Kay > authorizing upload -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVENUPLOAD-819) Saxon XPath 8.7
[ http://jira.codehaus.org/browse/MAVENUPLOAD-819?page=all ] Tim O'Brien closed MAVENUPLOAD-819: --- Resolution: Fixed Closing this issue, MAVENUPLOAD-814 takes the place of this issue. > Saxon XPath 8.7 > --- > > Key: MAVENUPLOAD-819 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-819 > Project: maven-upload-requests > Type: Task > Reporter: Tim O'Brien > > > Click on contributor link for message from Michael Kay granting permission to > add library to repo. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVENUPLOAD-818) Saxon XOM 8.7
[ http://jira.codehaus.org/browse/MAVENUPLOAD-818?page=all ] Tim O'Brien closed MAVENUPLOAD-818: --- Resolution: Fixed Closing this issue, MAVENUPLOAD-814 takes the place of this issue. > Saxon XOM 8.7 > - > > Key: MAVENUPLOAD-818 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-818 > Project: maven-upload-requests > Type: Task > Reporter: Tim O'Brien > > > Click on contributor link for message from Michael Kay granting authority to > add these releases to the Maven repository -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVENUPLOAD-814) Saxon 8.7
[ http://jira.codehaus.org/browse/MAVENUPLOAD-814?page=all ] Carlos Sanchez closed MAVENUPLOAD-814: -- Assign To: Carlos Sanchez Resolution: Fixed Thanks, done > Saxon 8.7 > - > > Key: MAVENUPLOAD-814 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-814 > Project: maven-upload-requests > Type: Task > Reporter: Tim O'Brien > Assignee: Carlos Sanchez > Attachments: dep.png > > > This is Saxon 8.7. If you click on the contributor link below you will see a > mail thread from the saxon help list where Michael Kay give explicit > permission to upload these artifacts to the Maven 2 repository. -- 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: (MIDEA-48) Using "src/main/dir, src/main/dir2" will only exclude "src/main/dir"
Using "src/main/dir, src/main/dir2" will only exclude "src/main/dir" Key: MIDEA-48 URL: http://jira.codehaus.org/browse/MIDEA-48 Project: Maven 2.x Idea Plugin Type: Bug Reporter: Edwin Punzalan This is caused by the startWith logic since src/main/dir2 starts with src/main/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] Updated: (MIDEA-48) Using "src/main/dir, src/main/dir2" as "exclude" parameter will only exclude "src/main/dir"
[ http://jira.codehaus.org/browse/MIDEA-48?page=all ] Edwin Punzalan updated MIDEA-48: Assign To: Edwin Punzalan Summary: Using "src/main/dir, src/main/dir2" as "exclude" parameter will only exclude "src/main/dir" (was: Using "src/main/dir, src/main/dir2" will only exclude "src/main/dir") > Using "src/main/dir, src/main/dir2" as "exclude" parameter will only exclude > "src/main/dir" > --- > > Key: MIDEA-48 > URL: http://jira.codehaus.org/browse/MIDEA-48 > Project: Maven 2.x Idea Plugin > Type: Bug > Reporter: Edwin Punzalan > Assignee: Edwin Punzalan > > > This is caused by the startWith logic since src/main/dir2 starts with > src/main/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] Closed: (MIDEA-48) Using "src/main/dir, src/main/dir2" as "exclude" parameter will only exclude "src/main/dir"
[ http://jira.codehaus.org/browse/MIDEA-48?page=all ] Edwin Punzalan closed MIDEA-48: --- Resolution: Fixed > Using "src/main/dir, src/main/dir2" as "exclude" parameter will only exclude > "src/main/dir" > --- > > Key: MIDEA-48 > URL: http://jira.codehaus.org/browse/MIDEA-48 > Project: Maven 2.x Idea Plugin > Type: Bug > Reporter: Edwin Punzalan > Assignee: Edwin Punzalan > > > This is caused by the startWith logic since src/main/dir2 starts with > src/main/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
