[jira] Commented: (CONTINUUM-455) Parameters in SCM Urls
[ http://jira.codehaus.org/browse/CONTINUUM-455?page=comments#action_60842
]
Martin Ahrer commented on CONTINUUM-455:
As I have voted for this I also wanted to add some motivation for it. I have a
fairly large number of maven projects being built by various individuals (in
future also continuum for nightly builds). Therefore I'm using ${user.home} in
my SCM URL.
Thanks
Martin
> Parameters in SCM Urls
> --
>
> Key: CONTINUUM-455
> URL: http://jira.codehaus.org/browse/CONTINUUM-455
> Project: Continuum
> Type: New Feature
> Components: Web interface
> Versions: 1.1, 1.0-alpha-1, 1.0-alpha-2, 1.0-alpha-3, 1.0-alpha-4,
> 1.0-beta-1, 1.0, 1.0.1
> Environment: Linux
> Reporter: Rafael Silva
>
>
> I'd like to use parameters in scm urls.
> like:
> scm:cvs:ext:[EMAIL PROTECTED]:/home/company/cvs:project
> Thanks in advance,
> Rafael Silva
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly 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-601) Add a servlet for downloading files project as text (without html decoration)
[ http://jira.codehaus.org/browse/CONTINUUM-601?page=all ] Emmanuel Venisse closed CONTINUUM-601: -- Resolution: Fixed Done. > Add a servlet for downloading files project as text (without html decoration) > - > > Key: CONTINUUM-601 > URL: http://jira.codehaus.org/browse/CONTINUUM-601 > Project: Continuum > Type: New Feature > Components: Web interface > 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: (MWAR-24) [PATCH] Add ability to specify context.xml file in plugin configuration
[ http://jira.codehaus.org/browse/MWAR-24?page=comments#action_60845 ] John Tolentino commented on MWAR-24: Verified and tested this code. Please apply patch. > [PATCH] Add ability to specify context.xml file in plugin configuration > --- > > Key: MWAR-24 > URL: http://jira.codehaus.org/browse/MWAR-24 > Project: Maven 2.x War Plugin > Type: New Feature > Versions: 2.0 > Reporter: Kris Nuttycombe > Fix For: 2.0 > Attachments: contextXml.patch > > > The context.xml file for a web application may require configuration specific > to the deployment environment of the webapp, and consequently should be able > to be treated like the web.xml file in allowing the location of the > context.xml file to be used in the webapp to be specified by a plugin > configuration parameter. This patch basically duplicates the replacement > functionality provided for the web.xml file for META-INF/context.xml. > This patch also provides a minor bugfix to ensure that values of the webXml > and contextXml parameters do not accept whitespace as valid values. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MAVEN-1751) "A cycle was detected" where no cycle can be found
"A cycle was detected" where no cycle can be found -- Key: MAVEN-1751 URL: http://jira.codehaus.org/browse/MAVEN-1751 Project: Maven Type: Bug Versions: 1.1-beta-2 Environment: SUSE Linux 10.0 (kernel 2.6.13-15-smp), J2SDK 1.4.2_10 Reporter: Anders Heintz Attachments: proj1_dependencies.xml, proj2_dependencies.xml, proj3_dependencies.xml I have a quite large multiproject project which I fail to build using Maven 1.1beta2 (Maven 1.0.2 works fine). I "divided and conquered" a bit and excluded all but the most basic project, then added one at a time. When I included my third project, the build fails with the message "A cycle was detected". The dependencies for these tree projects (except external dependencies) are: Project 1 depends on Project 2 and Project 3. Project 2 depends on Project 3. Project 3 is a base "project" which contains common services and are used by all other projects. I'll attach the dependencies part of the three subprojects. When I run the same goal (any multiproject goal, for example 'maven -Dgoal=clean multiproject:goal') using Maven 1.0.2 it works fine: Starting the reactor... Our processing order: webSelect Project 3 webSelect Project 2 webSelect Project 1 When I tried commenting out all dependencies apart from the project mentioned above, it still fails, it even fails when I remove Project 1's dependency to Project 3. What is even more confusing is when I replace Project 1 with another subproject which have the same dependencies it works fine (which however, is a ejb project instead of being a jar project which Project 1 is). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRM-102) ProxyManager enhancements
ProxyManager enhancements - Key: MRM-102 URL: http://jira.codehaus.org/browse/MRM-102 Project: Maven Repository Manager Type: Improvement Components: remote proxy Reporter: Edwin Punzalan As brett pointed out, the DefaultProxyManager needs some refactoring especially on these points: - remove cache period - get() ignores the return of getRemoteFile() - make the proxy check for the checksum and metadata files first, before parsing the path for an artifact - getArtifactFile should use artifact.setFile() and not return the file anymore. - temp should be setup to deleteOnExit() - rename copyTempToTarget to moveTempToTarget - rename prepare/release checksums to prepare/release ChecksumListeners - use FileUtils.read when applicable -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MEV-339) Missing POMs for Spring 2.0-m2
[ http://jira.codehaus.org/browse/MEV-339?page=comments#action_60848 ] Ruben Inoto commented on MEV-339: - Thanks Julien. I wonder why nobody is paying attention to you, and if anyone out there at Spring realizes of the importance of having the POMs in the repository. This is certainly hindering a lot of people (me included) from trying to use the latest versions of the framework.. > Missing POMs for Spring 2.0-m2 > -- > > Key: MEV-339 > URL: http://jira.codehaus.org/browse/MEV-339 > Project: Maven Evangelism > Type: Bug > Components: Missing POM > Reporter: Julien Dubois > Attachments: spring-2.0-m2.zip > > > The pom.xml files are missing for all the 2.0-m2 release of the Spring > Framework. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MRM-102) ProxyManager enhancements
[ http://jira.codehaus.org/browse/MRM-102?page=all ] Edwin Punzalan updated MRM-102: --- Assign To: Edwin Punzalan Remaining Estimate: 1 hour Original Estimate: 1 hour > ProxyManager enhancements > - > > Key: MRM-102 > URL: http://jira.codehaus.org/browse/MRM-102 > Project: Maven Repository Manager > Type: Improvement > Components: remote proxy > Reporter: Edwin Punzalan > Assignee: Edwin Punzalan > > Original Estimate: 1 hour > Remaining: 1 hour > > As brett pointed out, the DefaultProxyManager needs some refactoring > especially on these points: > - remove cache period > - get() ignores the return of getRemoteFile() > - make the proxy check for the checksum and metadata files first, before > parsing the path for an artifact > - getArtifactFile should use artifact.setFile() and not return the file > anymore. > - temp should be setup to deleteOnExit() > - rename copyTempToTarget to moveTempToTarget > - rename prepare/release checksums to prepare/release ChecksumListeners > - use FileUtils.read when applicable -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MEV-358) Missing POMs for Spring 2.0-m3
Missing POMs for Spring 2.0-m3 -- Key: MEV-358 URL: http://jira.codehaus.org/browse/MEV-358 Project: Maven Evangelism Type: Bug Components: Missing POM Reporter: Julien Dubois The pom.xml files are missing for all the 2.0-m3 release of the Spring Framework. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MJAR-35) Abstraction for JarSignMojo so that webstart plugin can allow the user to choose how their jars are signed
[ http://jira.codehaus.org/browse/MJAR-35?page=all ] Lukas Theussl moved MPJAR-54 to MJAR-35: Workflow: Maven New (was: jira) Key: MJAR-35 (was: MPJAR-54) Project: Maven 2.x Jar Plugin (was: maven-jar-plugin) > Abstraction for JarSignMojo so that webstart plugin can allow the user to > choose how their jars are signed > -- > > Key: MJAR-35 > URL: http://jira.codehaus.org/browse/MJAR-35 > Project: Maven 2.x Jar Plugin > Type: New Feature > Reporter: David Boden > Attachments: JarSignerMojo.java > > > The webstart Maven 2 plugin signs jar files as part of its operation. At the > moment, it relies upon JarSignMojo to do this. > While this is going to be correct 90% of the time, sometimes users (like > myself!) need to ask the webstart plugin to sign jars in a different way. > Specifically, my company keeps its private key separate and provides an HTTP > Post interface to allow me to submit jars for signing. I've got a Mojo to do > this. > What I need is for the webstart plugin to use an abstraction defined in an > interface called JarSignerMojo (attached to this issue) rather than > JarSignMojo. That way, I can plug my own Mojo in to be used instead of > JarSignMojo. Jerome Lacoste is doing the webstart plugin development and is > happy to accommodate this change if we can get the interface added to the jar > plugin project. > The only change to the existing code is that JarSignMojo's class declaration > needs to be changed to: > public class JarSignMojo extends AbstractMojo implements JarSignerMojo -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-455) Parameters in SCM Urls
[ http://jira.codehaus.org/browse/CONTINUUM-455?page=all ] Emmanuel Venisse closed CONTINUUM-455: -- Assign To: Emmanuel Venisse Resolution: Fixed Fix Version: 1.0.3 Fixed. > Parameters in SCM Urls > -- > > Key: CONTINUUM-455 > URL: http://jira.codehaus.org/browse/CONTINUUM-455 > Project: Continuum > Type: New Feature > Components: Web interface > Versions: 1.1, 1.0-alpha-1, 1.0-alpha-2, 1.0-alpha-3, 1.0-alpha-4, > 1.0-beta-1, 1.0, 1.0.1 > Environment: Linux > Reporter: Rafael Silva > Assignee: Emmanuel Venisse > Fix For: 1.0.3 > > > I'd like to use parameters in scm urls. > like: > scm:cvs:ext:[EMAIL PROTECTED]:/home/company/cvs:project > Thanks in advance, > Rafael Silva -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MWAR-24) [PATCH] Add ability to specify context.xml file in plugin configuration
[ http://jira.codehaus.org/browse/MWAR-24?page=all ] Edwin Punzalan closed MWAR-24: -- Resolution: Fixed Patch applied. With minor revision to use StringUtils.isNotEmpty when applicable. Thanks. > [PATCH] Add ability to specify context.xml file in plugin configuration > --- > > Key: MWAR-24 > URL: http://jira.codehaus.org/browse/MWAR-24 > Project: Maven 2.x War Plugin > Type: New Feature > Versions: 2.0 > Reporter: Kris Nuttycombe > Assignee: John Tolentino > Fix For: 2.0 > Attachments: contextXml.patch > > Time Spent: 2 hours, 30 minutes >Remaining: 0 minutes > > The context.xml file for a web application may require configuration specific > to the deployment environment of the webapp, and consequently should be able > to be treated like the web.xml file in allowing the location of the > context.xml file to be used in the webapp to be specified by a plugin > configuration parameter. This patch basically duplicates the replacement > functionality provided for the web.xml file for META-INF/context.xml. > This patch also provides a minor bugfix to ensure that values of the webXml > and contextXml parameters do not accept whitespace as valid values. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MWAR-24) [PATCH] Add ability to specify context.xml file in plugin configuration
[ http://jira.codehaus.org/browse/MWAR-24?page=comments#action_60852 ] Vincent Massol commented on MWAR-24: Does the context.xml file applies to all webapp? AFAIK this file is Tomcat-specific. If that were the case I don't think we should include this patch (or not as it is). Indeed why would Tomcat get a special attention. What about all the other container's config files (jboss-web.xml, weblogic.xml, geronimo-*.xml, etc)? It doesn't look right. That's of course unless I'm wrong and there's a context.xml that has sprung up in some latest servlet spec that I'm not aware of :-) Thanks -Vincent > [PATCH] Add ability to specify context.xml file in plugin configuration > --- > > Key: MWAR-24 > URL: http://jira.codehaus.org/browse/MWAR-24 > Project: Maven 2.x War Plugin > Type: New Feature > Versions: 2.0 > Reporter: Kris Nuttycombe > Assignee: John Tolentino > Fix For: 2.0 > Attachments: contextXml.patch > > Time Spent: 2 hours, 30 minutes >Remaining: 0 minutes > > The context.xml file for a web application may require configuration specific > to the deployment environment of the webapp, and consequently should be able > to be treated like the web.xml file in allowing the location of the > context.xml file to be used in the webapp to be specified by a plugin > configuration parameter. This patch basically duplicates the replacement > functionality provided for the web.xml file for META-INF/context.xml. > This patch also provides a minor bugfix to ensure that values of the webXml > and contextXml parameters do not accept whitespace as valid values. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MAVEN-1751) "A cycle was detected" where no cycle can be found
[ http://jira.codehaus.org/browse/MAVEN-1751?page=comments#action_60853 ] Arnaud Heritier commented on MAVEN-1751: It's certainly related to MAVEN-1750. We have several problems with multiprojects : MAVEN-1741, MAVEN-1710, MAVEN-1691, ... It's on the top of my todo list > "A cycle was detected" where no cycle can be found > -- > > Key: MAVEN-1751 > URL: http://jira.codehaus.org/browse/MAVEN-1751 > Project: Maven > Type: Bug > Versions: 1.1-beta-2 > Environment: SUSE Linux 10.0 (kernel 2.6.13-15-smp), J2SDK 1.4.2_10 > Reporter: Anders Heintz > Attachments: proj1_dependencies.xml, proj2_dependencies.xml, > proj3_dependencies.xml > > > I have a quite large multiproject project which I fail to build using Maven > 1.1beta2 (Maven 1.0.2 works fine). I "divided and conquered" a bit and > excluded all but the most basic project, then added one at a time. When I > included my third project, the build fails with the message "A cycle was > detected". The dependencies for these tree projects (except external > dependencies) are: > Project 1 depends on Project 2 and Project 3. Project 2 depends on Project 3. > Project 3 is a base "project" which contains common services and are used by > all other projects. > I'll attach the dependencies part of the three subprojects. > When I run the same goal (any multiproject goal, for example 'maven > -Dgoal=clean multiproject:goal') using Maven 1.0.2 it works fine: > Starting the reactor... > Our processing order: > webSelect Project 3 > webSelect Project 2 > webSelect Project 1 > When I tried commenting out all dependencies apart from the project mentioned > above, it still fails, it even fails when I remove Project 1's dependency to > Project 3. > What is even more confusing is when I replace Project 1 with another > subproject which have the same dependencies it works fine (which however, is > a ejb project instead of being a jar project which Project 1 is). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MRM-102) ProxyManager enhancements
[ http://jira.codehaus.org/browse/MRM-102?page=all ] Edwin Punzalan closed MRM-102: -- Resolution: Fixed > ProxyManager enhancements > - > > Key: MRM-102 > URL: http://jira.codehaus.org/browse/MRM-102 > Project: Maven Repository Manager > Type: Improvement > Components: remote proxy > Reporter: Edwin Punzalan > Assignee: Edwin Punzalan > > Original Estimate: 1 hour >Time Spent: 30 minutes > Remaining: 0 minutes > > As brett pointed out, the DefaultProxyManager needs some refactoring > especially on these points: > - remove cache period > - get() ignores the return of getRemoteFile() > - make the proxy check for the checksum and metadata files first, before > parsing the path for an artifact > - getArtifactFile should use artifact.setFile() and not return the file > anymore. > - temp should be setup to deleteOnExit() > - rename copyTempToTarget to moveTempToTarget > - rename prepare/release checksums to prepare/release ChecksumListeners > - use FileUtils.read when applicable -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MAVEN-1751) "A cycle was detected" where no cycle can be found
[ http://jira.codehaus.org/browse/MAVEN-1751?page=comments#action_60858 ] Anders Heintz commented on MAVEN-1751: -- Thanks for your information, let me know if I can be of any help with testing etc. > "A cycle was detected" where no cycle can be found > -- > > Key: MAVEN-1751 > URL: http://jira.codehaus.org/browse/MAVEN-1751 > Project: Maven > Type: Bug > Versions: 1.1-beta-2 > Environment: SUSE Linux 10.0 (kernel 2.6.13-15-smp), J2SDK 1.4.2_10 > Reporter: Anders Heintz > Attachments: proj1_dependencies.xml, proj2_dependencies.xml, > proj3_dependencies.xml > > > I have a quite large multiproject project which I fail to build using Maven > 1.1beta2 (Maven 1.0.2 works fine). I "divided and conquered" a bit and > excluded all but the most basic project, then added one at a time. When I > included my third project, the build fails with the message "A cycle was > detected". The dependencies for these tree projects (except external > dependencies) are: > Project 1 depends on Project 2 and Project 3. Project 2 depends on Project 3. > Project 3 is a base "project" which contains common services and are used by > all other projects. > I'll attach the dependencies part of the three subprojects. > When I run the same goal (any multiproject goal, for example 'maven > -Dgoal=clean multiproject:goal') using Maven 1.0.2 it works fine: > Starting the reactor... > Our processing order: > webSelect Project 3 > webSelect Project 2 > webSelect Project 1 > When I tried commenting out all dependencies apart from the project mentioned > above, it still fails, it even fails when I remove Project 1's dependency to > Project 3. > What is even more confusing is when I replace Project 1 with another > subproject which have the same dependencies it works fine (which however, is > a ejb project instead of being a jar project which Project 1 is). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVEN-1751) "A cycle was detected" where no cycle can be found
[ http://jira.codehaus.org/browse/MAVEN-1751?page=comments#action_60862 ] Arnaud Heritier commented on MAVEN-1751: Thanks, I'll deploy a snapshot to allow you to test it ASAP. > "A cycle was detected" where no cycle can be found > -- > > Key: MAVEN-1751 > URL: http://jira.codehaus.org/browse/MAVEN-1751 > Project: Maven > Type: Bug > Versions: 1.1-beta-2 > Environment: SUSE Linux 10.0 (kernel 2.6.13-15-smp), J2SDK 1.4.2_10 > Reporter: Anders Heintz > Attachments: proj1_dependencies.xml, proj2_dependencies.xml, > proj3_dependencies.xml > > > I have a quite large multiproject project which I fail to build using Maven > 1.1beta2 (Maven 1.0.2 works fine). I "divided and conquered" a bit and > excluded all but the most basic project, then added one at a time. When I > included my third project, the build fails with the message "A cycle was > detected". The dependencies for these tree projects (except external > dependencies) are: > Project 1 depends on Project 2 and Project 3. Project 2 depends on Project 3. > Project 3 is a base "project" which contains common services and are used by > all other projects. > I'll attach the dependencies part of the three subprojects. > When I run the same goal (any multiproject goal, for example 'maven > -Dgoal=clean multiproject:goal') using Maven 1.0.2 it works fine: > Starting the reactor... > Our processing order: > webSelect Project 3 > webSelect Project 2 > webSelect Project 1 > When I tried commenting out all dependencies apart from the project mentioned > above, it still fails, it even fails when I remove Project 1's dependency to > Project 3. > What is even more confusing is when I replace Project 1 with another > subproject which have the same dependencies it works fine (which however, is > a ejb project instead of being a jar project which Project 1 is). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-1978) "Provided" scope transitive dependencies required + exclude dependencies for runtime scope only
[ http://jira.codehaus.org/browse/MNG-1978?page=comments#action_60863 ] David Boden commented on MNG-1978: -- > If it can't be assumed to be provided transitively, then shouldn't it be > treated as if it's compile scope for the transitive case? Completely agree with this statement. >why is this listed under the documentation-faqs component? isn't this a >question about scope-handling, something that should be assigned to something >like the core module (if that still exists)? In my original comment I stated *if* there was a good explaination then please assign this to the documentation subproject. There *isn't* a good explaination. We need a code change. "provided" dependencies should be transitive. Please move this into the relevant development subproject. Many thanks. > "Provided" scope transitive dependencies required + exclude dependencies for > runtime scope only > --- > > Key: MNG-1978 > URL: http://jira.codehaus.org/browse/MNG-1978 > Project: Maven 2 > Type: New Feature > Components: Documentation: Faqs > Versions: 2.0.2 > Reporter: David Boden > Fix For: documentation > > > Why are provided scope dependencies not transitive? > I have several examples in my project where I need to declare a dependency as > on the compilation classpath but not on the runtime classpath and I need it > to be transitive. I don't want the dependency to be packaged up in my > deployment artifact but my entire multi-project hierarchy relies on the > dependency. > At the moment, I have to workaround the problem, mostly by declaring > duplicate provided scope dependencies in multiple projects. > If there's a well-known answer to this query then apologies, could it be > placed in the "Introduction to Dependency Mechanism" documentation. > I would also be able to model my dependency structure more accurately if I > could a dependency from the runtime classpath only and keep it in > the compile classpath. > E.g. > > > SalesStation > cds_ss_shared > SNAPSHOT > > > SalesStation > ss_base_shared > > runtime > > > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-770) jalopy-console-0.1-1.5rc2
[ http://jira.codehaus.org/browse/MAVENUPLOAD-770?page=comments#action_60866 ] Joachim Bader commented on MAVENUPLOAD-770: --- thanks, it's fixed, now. > jalopy-console-0.1-1.5rc2 > - > > Key: MAVENUPLOAD-770 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-770 > Project: maven-upload-requests > Type: Task > Reporter: Joachim Bader > > > http://jalopy.sourceforge.net/jalopy-console/index.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MASSEMBLY-68) Need method to exclude all child dependencies when creating a jar
[ http://jira.codehaus.org/browse/MASSEMBLY-68?page=all ] Allan Ramirez closed MASSEMBLY-68: -- Resolution: Fixed -added new parameter called projectModulesOnly where it assembles all the project modules without their dependencies. To use command mvn assembly:assembly -DprojectModulesOnly=true > Need method to exclude all child dependencies when creating a jar > - > > Key: MASSEMBLY-68 > URL: http://jira.codehaus.org/browse/MASSEMBLY-68 > Project: Maven 2.x Assembly Plugin > Type: Improvement > Reporter: Dan Diephouse > Assignee: Allan Ramirez > Fix For: 2.1 > > Original Estimate: 12 hours > Remaining: 12 hours > > With xfire, we have 10 different modules. We want to create an "xfire-all" > jar that has all the xfire modules bundled. We can do this with the assembly > plugin right now by creating a pom with all our modules in it. However, when > it includes all the child dependencies. To exclude child dependencies you > have to listen them individually. XFire probably has around 50+ dependencies > spread out over the build. Maintaining this exclude list would be too much > work, so we'd like a way to simply say - build a jar composed of these 10 > jars, but none of their deps. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MJAVADOC-3) plugin should honor proxy settings
[ http://jira.codehaus.org/browse/MJAVADOC-3?page=all ] Maria Odea Ching updated MJAVADOC-3: Due Date: 13/Mar/06 Remaining Estimate: 3 hours, 30 minutes Original Estimate: 3 hours, 30 minutes > plugin should honor proxy settings > -- > > Key: MJAVADOC-3 > URL: http://jira.codehaus.org/browse/MJAVADOC-3 > Project: Maven 2.x Javadoc Plugin > Type: Bug > Environment: tested on Linux/Windows > Reporter: Dirk Olmes > Assignee: Maria Odea Ching > Priority: Minor > Fix For: 2.0-beta-4 > > Original Estimate: 3 hours, 30 minutes > Remaining: 3 hours, 30 minutes > > The maven2 plugin should honor the proxy settings. When specifying the > option, the forked javadoc process always tries to fetch the package-list > directly. This fails on corporate networks, where all web access has to go > through a proxy. > I've tried to specify a proxy by using the option but this > does not work because all parameters for the javadoc process are written to > an options file, which is passed to the forked javadoc process. By the time > the javadoc process gets to see the arguments, it is already running so all > VM parameters (-J-Dhttp.proxyHost...) cause errors. > The most seamless integration would be to pass whatever proxy is configured > to the forked javadoc process. Configuration options for specifying the proxy > for the javadoc-plugin would be acceptable, too. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MJAVADOC-3) plugin should honor proxy settings
[ http://jira.codehaus.org/browse/MJAVADOC-3?page=all ] Maria Odea Ching updated MJAVADOC-3: Attachment: MJAVADOC-3-maven-javadoc-plugin.patch > plugin should honor proxy settings > -- > > Key: MJAVADOC-3 > URL: http://jira.codehaus.org/browse/MJAVADOC-3 > Project: Maven 2.x Javadoc Plugin > Type: Bug > Environment: tested on Linux/Windows > Reporter: Dirk Olmes > Assignee: Maria Odea Ching > Priority: Minor > Fix For: 2.0-beta-4 > Attachments: MJAVADOC-3-maven-javadoc-plugin.patch > > Original Estimate: 3 hours, 30 minutes > Remaining: 3 hours, 30 minutes > > The maven2 plugin should honor the proxy settings. When specifying the > option, the forked javadoc process always tries to fetch the package-list > directly. This fails on corporate networks, where all web access has to go > through a proxy. > I've tried to specify a proxy by using the option but this > does not work because all parameters for the javadoc process are written to > an options file, which is passed to the forked javadoc process. By the time > the javadoc process gets to see the arguments, it is already running so all > VM parameters (-J-Dhttp.proxyHost...) cause errors. > The most seamless integration would be to pass whatever proxy is configured > to the forked javadoc process. Configuration options for specifying the proxy > for the javadoc-plugin would be acceptable, too. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-2124) Incorrect resolution of parent POM properties
[ http://jira.codehaus.org/browse/MNG-2124?page=comments#action_60880 ]
Kjetil Ødegaard commented on MNG-2124:
--
Great! Looks like this fixed my problem.
> Incorrect resolution of parent POM properties
> -
>
> Key: MNG-2124
> URL: http://jira.codehaus.org/browse/MNG-2124
> Project: Maven 2
> Type: Bug
> Components: Inheritence and Interpolation
> Versions: 2.0.2
> Environment: Windows XP, JDK 1.4.2_11
> Reporter: Kjetil Ødegaard
> Assignee: John Casey
> Priority: Blocker
> Fix For: 2.0.3
> Attachments: maven-bug.zip
>
>
> Unzip maven-bug to current dir and cd to maven-bug/artifact.
> Now, Maven 2.0.1 handles things correctly (irrelevant output removed):
> {code}[echo] Parent: parentartifact, project: artifact{code}
> But Maven 2.0.2 has a bug:
> {code}[echo] Parent: artifact, project: artifact{code}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly 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-1) cannot create project based on archetype that is not in cetral repository
[ http://jira.codehaus.org/browse/ARCHETYPE-1?page=comments#action_60881 ] Rob Dickens commented on ARCHETYPE-1: - When I said it builds, I meant 'mvn install's (to your local repository). However, doing a 'mvn deploy' to your internal repository appears to require various changes (which I haven't been able to fathom). Also, repeating the 'mvn install' appears to require that you manually delete various target directories. > cannot create project based on archetype that is not in cetral repository > - > > Key: ARCHETYPE-1 > URL: http://jira.codehaus.org/browse/ARCHETYPE-1 > Project: Maven Archetype > Type: Bug > Reporter: Milos Kleint > Assignee: Jason van Zyl > Priority: Critical > Fix For: 0.7 > Attachments: settings.xml > > > it's not possible to create an archetype based on a template from non-default > repository. the archetype's artifact never gets downloaded. > I tried to create a project based on archetype from > mevenide.codehaus.org/m2-repository (the repository is listed in the > settings.xml file - the file is attached) > the command line looks like this: > m2 archetype:create -DgroupId=com.mycompany -DartifactId=myapp > -DarchetypeGroupId=org.codehaus.mevenide.plugins > -DarchetypeArtifactId=maven-archetype-nbm -DarchetypeVersion=1.0 > The artifact is there: > http://mevenide.codehaus.org/m2-repository/org/codehaus/mevenide/plugins/maven-archetype-nbm/ > but the repository never gets contacted. > here is the output of the command: > > THE m2 COMMMAND IS DEPRECATED - PLEASE RUN mvn INSTEAD > [INFO] Scanning for projects... > [INFO] Searching repository for plugin with prefix: 'archetype'. > [INFO] > > [INFO] Building Maven Default Project > [INFO]task-segment: [archetype:create] (aggregator-style) > [INFO] > > [INFO] Setting property: classpath.resource.loader.class => > 'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'. > [INFO] Setting property: resource.loader => 'classpath'. > [INFO] ** > [INFO] Starting Jakarta Velocity v1.4 > [INFO] RuntimeInstance initializing. > [INFO] Default Properties File: > org/apache/velocity/runtime/defaults/velocity.properties > [INFO] Default ResourceManager initializing. (class > org.apache.velocity.runtime.resource.ResourceManagerImpl) > [INFO] Resource Loader Instantiated: > org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader > [INFO] ClasspathResourceLoader : initialization starting. > [INFO] ClasspathResourceLoader : initialization complete. > [INFO] ResourceCache : initialized. (class > org.apache.velocity.runtime.resource.ResourceCacheImpl) > [INFO] Default ResourceManager initialization complete. > [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Literal > [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Macro > [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Parse > [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Include > [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Foreach > [INFO] Created: 20 parsers. > [INFO] Velocimacro : initialization starting. > [INFO] Velocimacro : adding VMs from VM library template : > VM_global_library.vm > [ERROR] ResourceManager : unable to find resource 'VM_global_library.vm' in > anyresource loader. > [INFO] Velocimacro : error using VM library template VM_global_library.vm : > org.apache.velocity.exception.ResourceNotFoundException: Unable to find > resource 'VM_global_library.vm' > [INFO] Velocimacro : VM library template macro registration complete. > [INFO] Velocimacro : allowInline = true : VMs can be defined inline in > templates > [INFO] Velocimacro : allowInlineToOverride = false : VMs defined inline may > NOTreplace previous VM definitions > [INFO] Velocimacro : allowInlineLocal = false : VMs defined inline will be > global in scope if allowed. > [INFO] Velocimacro : messages on : VM system will output logging messages > [INFO] Velocimacro : autoload off : VM system will not automatically reload > global library macros > [INFO] Velocimacro : initialization complete. > [INFO] Velocity successfully started. > [INFO] [archetype:create] > [INFO] Defaulting package to group ID: com.mycompany > Downloading: > http://repo1.maven.org/maven2/org/codehaus/mevenide/plugins/maven-archetype-nbm/1.0/maven-archetype-nbm-1.0.jar > [WARNING] Unable to get resource from repository central > (http://repo1.maven.org/maven2) > [INFO] > > [ERROR] BUILD ERROR > [INF
[jira] Created: (MSITE-102) SCM files in src/site directory cause 'mvn site' to fail - need to exclude files
SCM files in src/site directory cause 'mvn site' to fail - need to exclude files Key: MSITE-102 URL: http://jira.codehaus.org/browse/MSITE-102 Project: Maven 2.x Site Plugin Type: Bug Versions: 2.0-beta-4 Environment: Windows XP Professional, Sun JDK 1.5.0_06, Maven 2.0.2 Reporter: Graham Triggs Our SCM solution (Surround SCM) places .MySCMServerInfo files in each directory. For a site archetype (and possibly others), issuing a 'mvn site' after checking the project into SCM causes the error below to be generated. Need a way of excluding .MySCMServerInfo files from the site generator (or possibly ideally, restricting the document transformer to recognised file extensions). [INFO] Scanning for projects... [INFO] Reactor build order: [INFO] BMc Java Development [INFO] Maven Webapp Archetype [INFO] [INFO] Building BMc Java Development [INFO]task-segment: [site] [INFO] [INFO] Setting property: classpath.resource.loader.class => 'org.codehaus.plexus.velocity.ContextCla ssLoaderResourceLoader'. [INFO] Setting property: velocimacro.messages.on => 'false'. [INFO] Setting property: resource.loader => 'classpath'. [INFO] Setting property: resource.manager.logwhenfound => 'false'. [INFO] ** [INFO] Starting Jakarta Velocity v1.4 [INFO] RuntimeInstance initializing. [INFO] Default Properties File: org\apache\velocity\runtime\defaults\velocity.properties [INFO] Default ResourceManager initializing. (class org.apache.velocity.runtime.resource.ResourceMan agerImpl) [INFO] Resource Loader Instantiated: org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader [INFO] ClasspathResourceLoader : initialization starting. [INFO] ClasspathResourceLoader : initialization complete. [INFO] ResourceCache : initialized. (class org.apache.velocity.runtime.resource.ResourceCacheImpl) [INFO] Default ResourceManager initialization complete. [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Literal [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Macro [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Parse [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Include [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Foreach [INFO] Created: 20 parsers. [INFO] Velocimacro : initialization starting. [INFO] Velocimacro : adding VMs from VM library template : VM_global_library.vm [ERROR] ResourceManager : unable to find resource 'VM_global_library.vm' in any resource loader. [INFO] Velocimacro : error using VM library template VM_global_library.vm : org.apache.velocity.exc eption.ResourceNotFoundException: Unable to find resource 'VM_global_library.vm' [INFO] Velocimacro : VM library template macro registration complete. [INFO] Velocimacro : allowInline = true : VMs can be defined inline in templates [INFO] Velocimacro : allowInlineToOverride = false : VMs defined inline may NOT replace previous VM definitions [INFO] Velocimacro : allowInlineLocal = false : VMs defined inline will be global in scope if allow ed. [INFO] Velocimacro : initialization complete. [INFO] Velocity successfully started. [INFO] [site:site] [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Some files are duplicates in the site directory or in the generated-site directory. Review the following files for the "English" version: apt\.MySCMServerInfo fml\.MySCMServerInfo fr\.MySCMServerInfo xdoc\.MySCMServerInfo [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 6 seconds [INFO] Finished at: Mon Mar 13 14:09:08 GMT 2006 [INFO] Final Memory: 5M/10M [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: (MJAVADOC-3) plugin should honor proxy settings
[ http://jira.codehaus.org/browse/MJAVADOC-3?page=comments#action_60889 ] Vincent Siveton commented on MJAVADOC-3: I think a better approach could be to use user system settings defined by maven-settings. WDYT? > plugin should honor proxy settings > -- > > Key: MJAVADOC-3 > URL: http://jira.codehaus.org/browse/MJAVADOC-3 > Project: Maven 2.x Javadoc Plugin > Type: Bug > Environment: tested on Linux/Windows > Reporter: Dirk Olmes > Assignee: Maria Odea Ching > Priority: Minor > Fix For: 2.0-beta-4 > Attachments: MJAVADOC-3-maven-javadoc-plugin.patch > > Original Estimate: 3 hours, 30 minutes >Time Spent: 3 hours, 30 minutes > Remaining: 0 minutes > > The maven2 plugin should honor the proxy settings. When specifying the > option, the forked javadoc process always tries to fetch the package-list > directly. This fails on corporate networks, where all web access has to go > through a proxy. > I've tried to specify a proxy by using the option but this > does not work because all parameters for the javadoc process are written to > an options file, which is passed to the forked javadoc process. By the time > the javadoc process gets to see the arguments, it is already running so all > VM parameters (-J-Dhttp.proxyHost...) cause errors. > The most seamless integration would be to pass whatever proxy is configured > to the forked javadoc process. Configuration options for specifying the proxy > for the javadoc-plugin would be acceptable, too. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-102) SCM files in src/site directory cause 'mvn site' to fail - need to exclude files
[ http://jira.codehaus.org/browse/MSITE-102?page=all ] Emmanuel Venisse closed MSITE-102: -- Assign To: Emmanuel Venisse Resolution: Fixed Fix Version: 2.0 Fixed. > SCM files in src/site directory cause 'mvn site' to fail - need to exclude > files > > > Key: MSITE-102 > URL: http://jira.codehaus.org/browse/MSITE-102 > Project: Maven 2.x Site Plugin > Type: Bug > Versions: 2.0-beta-4 > Environment: Windows XP Professional, Sun JDK 1.5.0_06, Maven 2.0.2 > Reporter: Graham Triggs > Assignee: Emmanuel Venisse > Fix For: 2.0 > > > Our SCM solution (Surround SCM) places .MySCMServerInfo files in each > directory. For a site archetype (and possibly others), issuing a 'mvn site' > after checking the project into SCM causes the error below to be generated. > Need a way of excluding .MySCMServerInfo files from the site generator (or > possibly ideally, restricting the document transformer to recognised file > extensions). > [INFO] Scanning for projects... > [INFO] Reactor build order: > [INFO] BMc Java Development > [INFO] Maven Webapp Archetype > [INFO] > > [INFO] Building BMc Java Development > [INFO]task-segment: [site] > [INFO] > > [INFO] Setting property: classpath.resource.loader.class => > 'org.codehaus.plexus.velocity.ContextCla > ssLoaderResourceLoader'. > [INFO] Setting property: velocimacro.messages.on => 'false'. > [INFO] Setting property: resource.loader => 'classpath'. > [INFO] Setting property: resource.manager.logwhenfound => 'false'. > [INFO] ** > [INFO] Starting Jakarta Velocity v1.4 > [INFO] RuntimeInstance initializing. > [INFO] Default Properties File: > org\apache\velocity\runtime\defaults\velocity.properties > [INFO] Default ResourceManager initializing. (class > org.apache.velocity.runtime.resource.ResourceMan > agerImpl) > [INFO] Resource Loader Instantiated: > org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader > [INFO] ClasspathResourceLoader : initialization starting. > [INFO] ClasspathResourceLoader : initialization complete. > [INFO] ResourceCache : initialized. (class > org.apache.velocity.runtime.resource.ResourceCacheImpl) > [INFO] Default ResourceManager initialization complete. > [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Literal > [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Macro > [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Parse > [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Include > [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Foreach > [INFO] Created: 20 parsers. > [INFO] Velocimacro : initialization starting. > [INFO] Velocimacro : adding VMs from VM library template : > VM_global_library.vm > [ERROR] ResourceManager : unable to find resource 'VM_global_library.vm' in > any resource loader. > [INFO] Velocimacro : error using VM library template VM_global_library.vm : > org.apache.velocity.exc > eption.ResourceNotFoundException: Unable to find resource > 'VM_global_library.vm' > [INFO] Velocimacro : VM library template macro registration complete. > [INFO] Velocimacro : allowInline = true : VMs can be defined inline in > templates > [INFO] Velocimacro : allowInlineToOverride = false : VMs defined inline may > NOT replace previous VM > definitions > [INFO] Velocimacro : allowInlineLocal = false : VMs defined inline will be > global in scope if allow > ed. > [INFO] Velocimacro : initialization complete. > [INFO] Velocity successfully started. > [INFO] [site:site] > [INFO] > > [ERROR] BUILD FAILURE > [INFO] > > [INFO] Some files are duplicates in the site directory or in the > generated-site directory. > Review the following files for the "English" version: > apt\.MySCMServerInfo > fml\.MySCMServerInfo > fr\.MySCMServerInfo > xdoc\.MySCMServerInfo > [INFO] > > [INFO] For more information, run Maven with the -e switch > [INFO] > > [INFO] Total time: 6 seconds > [INFO] Finished at: Mon Mar 13 14:09:08 GMT 2006 > [INFO] Final Memory: 5M/10M > [INFO] > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.
[jira] Reopened: (MSITE-102) SCM files in src/site directory cause 'mvn site' to fail - need to exclude files
[ http://jira.codehaus.org/browse/MSITE-102?page=all ] Graham Triggs reopened MSITE-102: - If this is fixed, then can someone point me in the direction of how to actually make it work please!!! I've been struggling with this for three days, searched through the issues, and Googled as much as possible, and tried every solution (and variation of solution) that I can come across, and I am STILL having this problem. And yes, I am using the latest version of Maven (2.0.2) > SCM files in src/site directory cause 'mvn site' to fail - need to exclude > files > > > Key: MSITE-102 > URL: http://jira.codehaus.org/browse/MSITE-102 > Project: Maven 2.x Site Plugin > Type: Bug > Versions: 2.0-beta-4 > Environment: Windows XP Professional, Sun JDK 1.5.0_06, Maven 2.0.2 > Reporter: Graham Triggs > Assignee: Emmanuel Venisse > Fix For: 2.0 > > > Our SCM solution (Surround SCM) places .MySCMServerInfo files in each > directory. For a site archetype (and possibly others), issuing a 'mvn site' > after checking the project into SCM causes the error below to be generated. > Need a way of excluding .MySCMServerInfo files from the site generator (or > possibly ideally, restricting the document transformer to recognised file > extensions). > [INFO] Scanning for projects... > [INFO] Reactor build order: > [INFO] BMc Java Development > [INFO] Maven Webapp Archetype > [INFO] > > [INFO] Building BMc Java Development > [INFO]task-segment: [site] > [INFO] > > [INFO] Setting property: classpath.resource.loader.class => > 'org.codehaus.plexus.velocity.ContextCla > ssLoaderResourceLoader'. > [INFO] Setting property: velocimacro.messages.on => 'false'. > [INFO] Setting property: resource.loader => 'classpath'. > [INFO] Setting property: resource.manager.logwhenfound => 'false'. > [INFO] ** > [INFO] Starting Jakarta Velocity v1.4 > [INFO] RuntimeInstance initializing. > [INFO] Default Properties File: > org\apache\velocity\runtime\defaults\velocity.properties > [INFO] Default ResourceManager initializing. (class > org.apache.velocity.runtime.resource.ResourceMan > agerImpl) > [INFO] Resource Loader Instantiated: > org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader > [INFO] ClasspathResourceLoader : initialization starting. > [INFO] ClasspathResourceLoader : initialization complete. > [INFO] ResourceCache : initialized. (class > org.apache.velocity.runtime.resource.ResourceCacheImpl) > [INFO] Default ResourceManager initialization complete. > [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Literal > [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Macro > [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Parse > [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Include > [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Foreach > [INFO] Created: 20 parsers. > [INFO] Velocimacro : initialization starting. > [INFO] Velocimacro : adding VMs from VM library template : > VM_global_library.vm > [ERROR] ResourceManager : unable to find resource 'VM_global_library.vm' in > any resource loader. > [INFO] Velocimacro : error using VM library template VM_global_library.vm : > org.apache.velocity.exc > eption.ResourceNotFoundException: Unable to find resource > 'VM_global_library.vm' > [INFO] Velocimacro : VM library template macro registration complete. > [INFO] Velocimacro : allowInline = true : VMs can be defined inline in > templates > [INFO] Velocimacro : allowInlineToOverride = false : VMs defined inline may > NOT replace previous VM > definitions > [INFO] Velocimacro : allowInlineLocal = false : VMs defined inline will be > global in scope if allow > ed. > [INFO] Velocimacro : initialization complete. > [INFO] Velocity successfully started. > [INFO] [site:site] > [INFO] > > [ERROR] BUILD FAILURE > [INFO] > > [INFO] Some files are duplicates in the site directory or in the > generated-site directory. > Review the following files for the "English" version: > apt\.MySCMServerInfo > fml\.MySCMServerInfo > fr\.MySCMServerInfo > xdoc\.MySCMServerInfo > [INFO] > > [INFO] For more information, run Maven with the -e switch > [INFO] > > [INFO] Total time: 6 seconds > [INFO] Finished at: M
[jira] Created: (MSITE-103) finish refactoring of category summary pages and index page report
finish refactoring of category summary pages and index page report -- Key: MSITE-103 URL: http://jira.codehaus.org/browse/MSITE-103 Project: Maven 2.x Site Plugin Type: Task Reporter: Brett Porter Assigned to: Brett Porter Priority: Blocker Fix For: 2.0 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MSITE-80) refactor site mojo into reusable components
[ http://jira.codehaus.org/browse/MSITE-80?page=all ] Brett Porter closed MSITE-80: - Resolution: Fixed > refactor site mojo into reusable components > --- > > Key: MSITE-80 > URL: http://jira.codehaus.org/browse/MSITE-80 > Project: Maven 2.x Site Plugin > Type: Task > Reporter: Brett Porter > Assignee: Brett Porter > Fix For: 2.0 > > Original Estimate: 3 hours >Time Spent: 12 hours > Remaining: 0 minutes > > the code in the site mojo has taken on a lot of the work that belongs in the > reporting-impl and doxia-site-renderer. This prevents other things from > reusing it. Needs a slim down. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-102) SCM files in src/site directory cause 'mvn site' to fail - need to exclude files
[ http://jira.codehaus.org/browse/MSITE-102?page=comments#action_60897 ] Emmanuel Venisse commented on MSITE-102: You must update your plexus-utils lib in $MAVEN_HOME/lib by this one : http://snapshots.maven.codehaus.org/maven2/org/codehaus/plexus/plexus-utils/1.2-SNAPSHOT/plexus-utils-1.2-20060313.144211-6.jar > SCM files in src/site directory cause 'mvn site' to fail - need to exclude > files > > > Key: MSITE-102 > URL: http://jira.codehaus.org/browse/MSITE-102 > Project: Maven 2.x Site Plugin > Type: Bug > Versions: 2.0-beta-4 > Environment: Windows XP Professional, Sun JDK 1.5.0_06, Maven 2.0.2 > Reporter: Graham Triggs > Assignee: Emmanuel Venisse > Fix For: 2.0 > > > Our SCM solution (Surround SCM) places .MySCMServerInfo files in each > directory. For a site archetype (and possibly others), issuing a 'mvn site' > after checking the project into SCM causes the error below to be generated. > Need a way of excluding .MySCMServerInfo files from the site generator (or > possibly ideally, restricting the document transformer to recognised file > extensions). > [INFO] Scanning for projects... > [INFO] Reactor build order: > [INFO] BMc Java Development > [INFO] Maven Webapp Archetype > [INFO] > > [INFO] Building BMc Java Development > [INFO]task-segment: [site] > [INFO] > > [INFO] Setting property: classpath.resource.loader.class => > 'org.codehaus.plexus.velocity.ContextCla > ssLoaderResourceLoader'. > [INFO] Setting property: velocimacro.messages.on => 'false'. > [INFO] Setting property: resource.loader => 'classpath'. > [INFO] Setting property: resource.manager.logwhenfound => 'false'. > [INFO] ** > [INFO] Starting Jakarta Velocity v1.4 > [INFO] RuntimeInstance initializing. > [INFO] Default Properties File: > org\apache\velocity\runtime\defaults\velocity.properties > [INFO] Default ResourceManager initializing. (class > org.apache.velocity.runtime.resource.ResourceMan > agerImpl) > [INFO] Resource Loader Instantiated: > org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader > [INFO] ClasspathResourceLoader : initialization starting. > [INFO] ClasspathResourceLoader : initialization complete. > [INFO] ResourceCache : initialized. (class > org.apache.velocity.runtime.resource.ResourceCacheImpl) > [INFO] Default ResourceManager initialization complete. > [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Literal > [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Macro > [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Parse > [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Include > [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Foreach > [INFO] Created: 20 parsers. > [INFO] Velocimacro : initialization starting. > [INFO] Velocimacro : adding VMs from VM library template : > VM_global_library.vm > [ERROR] ResourceManager : unable to find resource 'VM_global_library.vm' in > any resource loader. > [INFO] Velocimacro : error using VM library template VM_global_library.vm : > org.apache.velocity.exc > eption.ResourceNotFoundException: Unable to find resource > 'VM_global_library.vm' > [INFO] Velocimacro : VM library template macro registration complete. > [INFO] Velocimacro : allowInline = true : VMs can be defined inline in > templates > [INFO] Velocimacro : allowInlineToOverride = false : VMs defined inline may > NOT replace previous VM > definitions > [INFO] Velocimacro : allowInlineLocal = false : VMs defined inline will be > global in scope if allow > ed. > [INFO] Velocimacro : initialization complete. > [INFO] Velocity successfully started. > [INFO] [site:site] > [INFO] > > [ERROR] BUILD FAILURE > [INFO] > > [INFO] Some files are duplicates in the site directory or in the > generated-site directory. > Review the following files for the "English" version: > apt\.MySCMServerInfo > fml\.MySCMServerInfo > fr\.MySCMServerInfo > xdoc\.MySCMServerInfo > [INFO] > > [INFO] For more information, run Maven with the -e switch > [INFO] > > [INFO] Total time: 6 seconds > [INFO] Finished at: Mon Mar 13 14:09:08 GMT 2006 > [INFO] Final Memory: 5M/10M > [INFO] > -- This mes
[jira] Commented: (MSITE-102) SCM files in src/site directory cause 'mvn site' to fail - need to exclude files
[ http://jira.codehaus.org/browse/MSITE-102?page=comments#action_60898 ] Graham Triggs commented on MSITE-102: - I didn't have a plexus-utils in my $MAVEN_HOME/lib (or rather, $MAVEN_HOME2/lib). If I add the linked jar, I get the following message: [INFO] Scanning for projects... [INFO] [INFO] Building Maven Webapp Archetype [INFO]task-segment: [site] [INFO] [INFO] [ERROR] FATAL ERROR [INFO] [INFO] loader constraints violated when linking org/codehaus/plexus/util/xml/Xpp3Dom class [INFO] [INFO] Trace java.lang.LinkageError: loader constraints violated when linking org/codehaus/plexus/util/xml/Xpp3Do m class at org.apache.maven.plugin.descriptor.PluginDescriptorBuilder.buildConfiguration(PluginDescr iptorBuilder.java:302) at org.apache.maven.plugin.descriptor.PluginDescriptorBuilder.build(PluginDescriptorBuilder. java:31) at org.apache.maven.plugin.MavenPluginDiscoverer.createComponentDescriptors(MavenPluginDisco verer.java:49) at org.codehaus.plexus.component.discovery.AbstractComponentDiscoverer.findComponents(Abstra ctComponentDiscoverer.java:78) at org.codehaus.plexus.DefaultPlexusContainer.discoverComponents(DefaultPlexusContainer.java :717) at org.codehaus.plexus.DefaultPlexusContainer.start(DefaultPlexusContainer.java:779) at org.codehaus.plexus.DefaultPlexusContainer.createChildContainer(DefaultPlexusContainer.ja va:270) at org.apache.maven.plugin.DefaultPluginManager.addPlugin(DefaultPluginManager.java:280) at org.apache.maven.plugin.DefaultPluginManager.verifyVersionedPlugin(DefaultPluginManager.j ava:200) at org.apache.maven.plugin.DefaultPluginManager.verifyPlugin(DefaultPluginManager.java:165) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(DefaultLifecycleExecutor .java:1218) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.getMojoDescriptor(DefaultLifecycleExe cutor.java:1483) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.bindLifecycleForPackaging(DefaultLife cycleExecutor.java:979) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.constructLifecycleMappings(DefaultLif ecycleExecutor.java:943) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor. java:450) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultL ifecycleExecutor.java:303) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleE xecutor.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) [INFO] [INFO] Total time: < 1 second [INFO] Finished at: Mon Mar 13 15:25:15 GMT 2006 [INFO] Final Memory: 1M/2M [INFO] > SCM files in src/site directory cause 'mvn site' to fail - need to exclude > files > > > Key: MSITE-102 > URL: http://jira.codehaus.org/browse/MSITE-102 > Project: Maven 2.x Site Plugin > Type: Bug > Versions: 2.0-beta-4 > Environment: Windows XP Professional, Sun JDK 1.5.0_06, Maven 2.0.2 > Reporter: Graham Triggs > Assignee: Emmanuel Venisse > Fix For: 2.0 > > > Our SCM solution (Surround SCM) places .MySCMServerInfo files in each > directory. For a site archetype (and possibly others), issuing a 'mvn site' > after checking the project into SCM causes the error below to be generated. > Need a way of excluding .MySCMServerInfo
[jira] Closed: (MSITE-102) SCM files in src/site directory cause 'mvn site' to fail - need to exclude files
[ http://jira.codehaus.org/browse/MSITE-102?page=all ] Emmanuel Venisse closed MSITE-102: -- Resolution: Fixed I fixed it in site plugin so if it is released before maven use plexus-utils-1.2, it will work without update of plexus-utils lib plexus-utils is in $M2_HOME/core > SCM files in src/site directory cause 'mvn site' to fail - need to exclude > files > > > Key: MSITE-102 > URL: http://jira.codehaus.org/browse/MSITE-102 > Project: Maven 2.x Site Plugin > Type: Bug > Versions: 2.0-beta-4 > Environment: Windows XP Professional, Sun JDK 1.5.0_06, Maven 2.0.2 > Reporter: Graham Triggs > Assignee: Emmanuel Venisse > Fix For: 2.0 > > > Our SCM solution (Surround SCM) places .MySCMServerInfo files in each > directory. For a site archetype (and possibly others), issuing a 'mvn site' > after checking the project into SCM causes the error below to be generated. > Need a way of excluding .MySCMServerInfo files from the site generator (or > possibly ideally, restricting the document transformer to recognised file > extensions). > [INFO] Scanning for projects... > [INFO] Reactor build order: > [INFO] BMc Java Development > [INFO] Maven Webapp Archetype > [INFO] > > [INFO] Building BMc Java Development > [INFO]task-segment: [site] > [INFO] > > [INFO] Setting property: classpath.resource.loader.class => > 'org.codehaus.plexus.velocity.ContextCla > ssLoaderResourceLoader'. > [INFO] Setting property: velocimacro.messages.on => 'false'. > [INFO] Setting property: resource.loader => 'classpath'. > [INFO] Setting property: resource.manager.logwhenfound => 'false'. > [INFO] ** > [INFO] Starting Jakarta Velocity v1.4 > [INFO] RuntimeInstance initializing. > [INFO] Default Properties File: > org\apache\velocity\runtime\defaults\velocity.properties > [INFO] Default ResourceManager initializing. (class > org.apache.velocity.runtime.resource.ResourceMan > agerImpl) > [INFO] Resource Loader Instantiated: > org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader > [INFO] ClasspathResourceLoader : initialization starting. > [INFO] ClasspathResourceLoader : initialization complete. > [INFO] ResourceCache : initialized. (class > org.apache.velocity.runtime.resource.ResourceCacheImpl) > [INFO] Default ResourceManager initialization complete. > [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Literal > [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Macro > [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Parse > [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Include > [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Foreach > [INFO] Created: 20 parsers. > [INFO] Velocimacro : initialization starting. > [INFO] Velocimacro : adding VMs from VM library template : > VM_global_library.vm > [ERROR] ResourceManager : unable to find resource 'VM_global_library.vm' in > any resource loader. > [INFO] Velocimacro : error using VM library template VM_global_library.vm : > org.apache.velocity.exc > eption.ResourceNotFoundException: Unable to find resource > 'VM_global_library.vm' > [INFO] Velocimacro : VM library template macro registration complete. > [INFO] Velocimacro : allowInline = true : VMs can be defined inline in > templates > [INFO] Velocimacro : allowInlineToOverride = false : VMs defined inline may > NOT replace previous VM > definitions > [INFO] Velocimacro : allowInlineLocal = false : VMs defined inline will be > global in scope if allow > ed. > [INFO] Velocimacro : initialization complete. > [INFO] Velocity successfully started. > [INFO] [site:site] > [INFO] > > [ERROR] BUILD FAILURE > [INFO] > > [INFO] Some files are duplicates in the site directory or in the > generated-site directory. > Review the following files for the "English" version: > apt\.MySCMServerInfo > fml\.MySCMServerInfo > fr\.MySCMServerInfo > xdoc\.MySCMServerInfo > [INFO] > > [INFO] For more information, run Maven with the -e switch > [INFO] > > [INFO] Total time: 6 seconds > [INFO] Finished at: Mon Mar 13 14:09:08 GMT 2006 > [INFO] Final Memory: 5M/10M > [INFO] > -- This message is automatically generated by JI
[jira] Created: (MSITE-104) There is no way to specify the input encoding of site documents
There is no way to specify the input encoding of site documents Key: MSITE-104 URL: http://jira.codehaus.org/browse/MSITE-104 Project: Maven 2.x Site Plugin Type: Bug Reporter: Naoki Nose In Japan,it's necessary to specify the input encoding of site document different from the system default, because there is two commonly used encodings in Japanese environment(Shift_JIS and EUC-JP). But current maven-site-plugin doesn't provide the way to specify the input encoding of site documents explicitly. We need to specify it in POM. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (CONTINUUM-540) Incorrect FAQ answer for "How does Continuum detect a successful build?"
[ http://jira.codehaus.org/browse/CONTINUUM-540?page=all ] Emmanuel Venisse closed CONTINUUM-540: -- Assign To: Emmanuel Venisse Resolution: Fixed Fix Version: 1.0.3 Fixed. > Incorrect FAQ answer for "How does Continuum detect a successful build?" > - > > Key: CONTINUUM-540 > URL: http://jira.codehaus.org/browse/CONTINUUM-540 > Project: Continuum > Type: Bug > Components: Documentation > Versions: 1.0.2 > Environment: Windows XP SP2, Ant Build, JRE 5, Ant 1.6.5 > Reporter: Olli > Assignee: Emmanuel Venisse > Fix For: 1.0.3 > > > The answer to the FAQ "How does Continuum detect a successful build?" is > out-of-date and incorrect (at least for Windows XP SP2). > It states to addthe following to the end of your maven or ant .bat file: > if "%MAVEN_TERMINATE_CMD%" == "on" exit %ERROR_CODE% > but this must be: > if "%MAVEN_TERMINATE_CMD%" == "on" exit %ERRORLEVEL% > The env var %ERROR_CODE% is undefined (at least for Windows XP SP2). > Starting with Continuum 1.0.2 the MAVEN_TERMINATE_CMD var is set by Continuum > in the DefaultShellComanderHelper class so the second half of the FAQ answer > is not needed if you need a version >= 1.0.2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-625) Value of "Group" column depends on how you added the project
Value of "Group" column depends on how you added the project Key: CONTINUUM-625 URL: http://jira.codehaus.org/browse/CONTINUUM-625 Project: Continuum Type: Bug Components: Web interface Versions: 1.0.2 Reporter: Matthew Beermann Priority: Minor Fix For: 1.1-alpha-1 The text that appears in the "Group" column of the project listing seems, counterintuitively, to depend on how exactly you added the project. * If I add Maven 2 projects en masse through a master POM that has , the name of that master POM is used. This may be related to an (incorrect) assumption that if A has B as a , then B has A as a , which is not true for me. * If I add the projects one-by-one, the results appear to be somewhat random. Looking over the list in my Continuum instance, I see projects that have their own name as their Group, and some that are displaying the name of sibling projects. I'm not quite sure what /should/ be displayed, but whatever it is, it ought to be consistent... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-777) Wrong groupId for artifact "slf4j-log4j13"
Wrong groupId for artifact "slf4j-log4j13" -- Key: MAVENUPLOAD-777 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-777 Project: maven-upload-requests Type: Bug Reporter: Ceki Gulcu Attachments: slf4j-log4j13-1.0-bundle.jar I mistakenly had the wrong element in the POM file for "slf4j-log4j13". As a consequence, the ibiblio repository has a dictory called "org.slf4j13". See [1]. The attached jar file corrects this mistake.I suggest that the directory related to "org.slf4j13" be removed immediately. [1] http://www.ibiblio.org/maven/org.slf4j13/ -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-777) Wrong groupId for artifact "slf4j-log4j13"
[ http://jira.codehaus.org/browse/MAVENUPLOAD-777?page=comments#action_60907 ] Ceki Gulcu commented on MAVENUPLOAD-777: The URL: http://jira.codehaus.org/secure/attachment/19587/slf4j-log4j13-1.0-bundle.jar > Wrong groupId for artifact "slf4j-log4j13" > -- > > Key: MAVENUPLOAD-777 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-777 > Project: maven-upload-requests > Type: Bug > Reporter: Ceki Gulcu > Attachments: slf4j-log4j13-1.0-bundle.jar > > > I mistakenly had the wrong element in the POM file for > "slf4j-log4j13". As a consequence, the ibiblio repository has a dictory > called > "org.slf4j13". See [1]. > The attached jar file corrects this mistake.I suggest that the directory > related to "org.slf4j13" be removed immediately. > [1] http://www.ibiblio.org/maven/org.slf4j13/ -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MAVEN-1751) "A cycle was detected" where no cycle can be found
[ http://jira.codehaus.org/browse/MAVEN-1751?page=comments#action_60908 ] David Jencks commented on MAVEN-1751: - I don't know if it is related to this exact problem, but I have noticed that if I accidentally have 2 subprojects with the same name, maven claims there is a cycle. Changing the name of one project allows the build to proceed. > "A cycle was detected" where no cycle can be found > -- > > Key: MAVEN-1751 > URL: http://jira.codehaus.org/browse/MAVEN-1751 > Project: Maven > Type: Bug > Versions: 1.1-beta-2 > Environment: SUSE Linux 10.0 (kernel 2.6.13-15-smp), J2SDK 1.4.2_10 > Reporter: Anders Heintz > Attachments: proj1_dependencies.xml, proj2_dependencies.xml, > proj3_dependencies.xml > > > I have a quite large multiproject project which I fail to build using Maven > 1.1beta2 (Maven 1.0.2 works fine). I "divided and conquered" a bit and > excluded all but the most basic project, then added one at a time. When I > included my third project, the build fails with the message "A cycle was > detected". The dependencies for these tree projects (except external > dependencies) are: > Project 1 depends on Project 2 and Project 3. Project 2 depends on Project 3. > Project 3 is a base "project" which contains common services and are used by > all other projects. > I'll attach the dependencies part of the three subprojects. > When I run the same goal (any multiproject goal, for example 'maven > -Dgoal=clean multiproject:goal') using Maven 1.0.2 it works fine: > Starting the reactor... > Our processing order: > webSelect Project 3 > webSelect Project 2 > webSelect Project 1 > When I tried commenting out all dependencies apart from the project mentioned > above, it still fails, it even fails when I remove Project 1's dependency to > Project 3. > What is even more confusing is when I replace Project 1 with another > subproject which have the same dependencies it works fine (which however, is > a ejb project instead of being a jar project which Project 1 is). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (CONTINUUM-461) ${pom.artifactId} in the Scm Url is not translated when adding a new project via the web interface
[ http://jira.codehaus.org/browse/CONTINUUM-461?page=all ]
Emmanuel Venisse closed CONTINUUM-461:
--
Assign To: Emmanuel Venisse
Resolution: Fixed
Fix Version: 1.0.3
Fixed.
> ${pom.artifactId} in the Scm Url is not translated when adding a new project
> via the web interface
> --
>
> Key: CONTINUUM-461
> URL: http://jira.codehaus.org/browse/CONTINUUM-461
> Project: Continuum
> Type: Bug
> Components: Web interface
> Versions: 1.0.1
> Reporter: Paul Spencer
> Assignee: Emmanuel Venisse
> Priority: Minor
> Fix For: 1.0.3
>
>
> ${pom.artifactId} in the Scm Url is not translated when adding a new project
> via the web interface.
> My maven 1 project containse the following repository entry:
>
> scm:cvs:pserver:[EMAIL
> PROTECTED]:/source:${pom.artifactId}
>
> I have not tried to add a m2 project that uses ${pom.artifactId} in the scm
> definition.
> The workaround is to edit the Scm Url using the web application.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-778) Please update 2.3.5 version of Freemarker library
Please update 2.3.5 version of Freemarker library - Key: MAVENUPLOAD-778 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-778 Project: maven-upload-requests Type: Improvement Reporter: Francesco Tinti -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-2145) Plugins' dependencies are not always checked
[ http://jira.codehaus.org/browse/MNG-2145?page=all ] Yann Le Du updated MNG-2145: Attachment: test-suite.zip > Plugins' dependencies are not always checked > > > Key: MNG-2145 > URL: http://jira.codehaus.org/browse/MNG-2145 > Project: Maven 2 > Type: Bug > Components: Dependencies > Versions: 2.0.2 > Reporter: Daiyam > Priority: Blocker > Attachments: pom-echo.xml, pom-merge.xml, pom-profile.xml, pom.xml, > test-suite.zip > > > I want to run two ant task, one on the phase 'generate-sources' which > contains a dependency and another on the phase 'package'. > When I want to compile with the project like that, maven don't check the > dependency. > But when I comment the plugin on the phase 'package', maven check it. > PS: In the pom.xml in attachement, maven must check the library > junit:junit:jar:30.80.10 (which don't exsist) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-2145) Plugins' dependencies are not always checked
[ http://jira.codehaus.org/browse/MNG-2145?page=comments#action_60912 ] Yann Le Du commented on MNG-2145: - OK, I've made a small test suite, and here is a clumsy guess about the process. Let's assume that main is assimilated to a (in first position). # (!) In an , if no is defined, then default is added # (!) If an is defined in several activated with the same , the in the last overwrites the in the first # (/) If several with different are defined in several activated for the same , they are merged in the first # (x) If several are defined in several activated for the same , they are NOT merged in the first # (!) If several are defined in the same with the same , I don't know what happens :p # (/) If no is defined in main for a given , the one in the first is copied into main I think that : * because of points 1. and 2. , should be mandatoty * point 4. should be corrected * situation in point 5. should not be allowed > Plugins' dependencies are not always checked > > > Key: MNG-2145 > URL: http://jira.codehaus.org/browse/MNG-2145 > Project: Maven 2 > Type: Bug > Components: Dependencies > Versions: 2.0.2 > Reporter: Daiyam > Priority: Blocker > Attachments: pom-echo.xml, pom-merge.xml, pom-profile.xml, pom.xml, > test-suite.zip > > > I want to run two ant task, one on the phase 'generate-sources' which > contains a dependency and another on the phase 'package'. > When I want to compile with the project like that, maven don't check the > dependency. > But when I comment the plugin on the phase 'package', maven check it. > PS: In the pom.xml in attachement, maven must check the library > junit:junit:jar:30.80.10 (which don't exsist) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-779) Upload request for NLOG4J 1.2.24
Upload request for NLOG4J 1.2.24 Key: MAVENUPLOAD-779 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-779 Project: maven-upload-requests Type: Task Reporter: Ceki Gulcu Attachments: nlog4j-1.2.24-bundle.jar Upload request for NLOG4J 1.2.24 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MWAR-26) Do not overwrite target unless source is modified
[ http://jira.codehaus.org/browse/MWAR-26?page=comments#action_60915 ] Andres March commented on MWAR-26: -- This will be a significant patch, since FileUtils currently does all the copying. I will have a go at it and see if I can put something together. Is there any common apache or codehaus libraries that have this type of "copy only if modified" feature? > Do not overwrite target unless source is modified > - > > Key: MWAR-26 > URL: http://jira.codehaus.org/browse/MWAR-26 > Project: Maven 2.x War Plugin > Type: Bug > Reporter: Andres March > Fix For: 2.0 > > > I thought MWAR-8 had fixed my issue but it seems to still exist. Correct me > if I'm wrong but doing incremental builds with this war plugin is not > possible. All the web app sources get overwritten regardless if they have > been modified or not. Incremental build were possible in Maven 1 because it > was ANT based. This version uses plexus FileUtils which overwrites without > regard to if the target file exists or older than the source. Besides the > time issue, overwriting the web.xml each time makes my context reload since > the context runs on tomcat from the target location. I think this is a > reasonable configuration but if there is a better way, let me know. Building > inplace wars is not an option as it dirties the source. > If we are in agreement, I may be able to provide a 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: (MNG-32) Plugin test harness
[ http://jira.codehaus.org/browse/MNG-32?page=comments#action_60913 ] Jesse McConnell commented on MNG-32: I was able to get the maven-site-plugin instantiated by adding the plugin harness test dependency and update the maven -site-plugin pom reference to maven-artifact. IMO that is going to be the biggest limiting factor to this approach, reconsiling the version of dependencies. I have added a mess of dependencies to the plugin-testing-harness pom but they are not used if the project in question has a different version of the dependency, like with the site plugin. At this point I think we are left with individual details for the framework on a per plugin basis. I implemented most of the maven project stub this morning so it is mostly useful, missing some things but for basic usage should be in decent shape. > Plugin test harness > --- > > Key: MNG-32 > URL: http://jira.codehaus.org/browse/MNG-32 > Project: Maven 2 > Type: Task > Components: Sandbox, Plugin API, Design, Patterns & Best Practices > Reporter: Jason van Zyl > Assignee: Jesse McConnell > Priority: Blocker > Attachments: maven-compiler-plugin.jar, maven-jar-plugin.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] Closed: (CONTINUUM-506) Fix typos and formatting in site docs and add faq entry about changing ports
[ http://jira.codehaus.org/browse/CONTINUUM-506?page=all ] Emmanuel Venisse closed CONTINUUM-506: -- Resolution: Fixed Fix Version: 1.0.3 Applied. Thanks. > Fix typos and formatting in site docs and add faq entry about changing ports > > > Key: CONTINUUM-506 > URL: http://jira.codehaus.org/browse/CONTINUUM-506 > Project: Continuum > Type: Improvement > Components: Documentation > Reporter: Dennis Lundberg > Assignee: Emmanuel Venisse > Priority: Minor > Fix For: 1.0.3 > Attachments: faq-problem.jpg, site-improvements.patch > > > Updated the site documents by fixing typos and adding some formatting where I > thought it was appropiate. > Also added an FAQ entry: "How can I run Continuum on a different port?" > Note: I had some trouble generating the site using the released version of > Maven 2. When issuing the command > mvn -U site > some pages looked weird, even in sections that I had not touched. The pages > are the ones using the fml format, i.e. about.fml and faq.fml. The problem > appears when using the "source" element more than once within the same > "answer" element. This might be a bug in the site plugin for Maven 2. Please > advise me if I should open an issue for this for maven-site-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: (MNG-2146) [maven-embedder-refactor] DefaultPluginRegistryBuilder gives NPE when maven.home system property is not available.
[ http://jira.codehaus.org/browse/MNG-2146?page=comments#action_60918 ] John Casey commented on MNG-2146: - This is fixed on the trunk and the maven-2.0.x branch, but needs to be propagated to the embedder-refactor branch. > [maven-embedder-refactor] DefaultPluginRegistryBuilder gives NPE when > maven.home system property is not available. > -- > > Key: MNG-2146 > URL: http://jira.codehaus.org/browse/MNG-2146 > Project: Maven 2 > Type: Bug > Components: Embedding > Versions: 2.1 > Environment: jason's maven-embedder-refactor branch > Reporter: Milos Kleint > Attachments: DefaultPluginRegistryBuilder.patch > > > patch attached, the problem is the initialization of default global plugin > registry which claim to be maven CLI independent but initializes only when > invoked by the CLI. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MANTRUN-37) Antrun breaks on multi-module builds
[ http://jira.codehaus.org/browse/MANTRUN-37?page=comments#action_60920 ]
Maciej Szefler commented on MANTRUN-37:
---
Also, blowing away the plugins directory does not solve the problem.
> Antrun breaks on multi-module builds
>
>
> Key: MANTRUN-37
> URL: http://jira.codehaus.org/browse/MANTRUN-37
> Project: Maven 2.x Antrun Plugin
> Type: Bug
> Versions: 1.1
> Environment: Maven 2.0.1
> Reporter: Mike Perham
> Assignee: Carlos Sanchez
> Priority: Critical
>
>
> I just updated to antrun v1.1 (which needs to be marked as released in jira
> BTW) and find that my multimodule build is now breaking. Running the build
> in the child module itself works fine but if I build the parent, it fails
> when it gets to the child with the antrun task. Here's part of the debug
> output. Note it says 1.1 in the dependency tree but 1.0 further down.
> {noformat}
> [DEBUG] org.apache.maven.plugins:maven-antrun-plugin:maven-plugin:1.1
> (selected for runtime)
> [DEBUG] org.apache.maven:maven-project:jar:2.0.1 (selected for runtime)
> [DEBUG] org.apache.maven:maven-model:jar:2.0.1 (selected for runtime)
> [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.5 (selected for
> runtime)
> [DEBUG] classworlds:classworlds:jar:1.1-alpha-2 (selected for runtime)
> [DEBUG] org.apache.maven:maven-profile:jar:2.0.1 (selected for runtime)
> [DEBUG] org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9
> (selected for runtime)
> [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4 (removed - nearer
> found: 1.0.5)
> [DEBUG] junit:junit:jar:3.8.1 (selected for runtime)
> [DEBUG] org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9
> (selected for runtime)
> [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4 (removed - nearer
> found: 1.0.5)
> [DEBUG] classworlds:classworlds:jar:1.1-alpha-2 (selected for runtime)
> [DEBUG] junit:junit:jar:3.8.1 (selected for runtime)
> [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.5 (selected for runtime)
> [DEBUG] org.apache.maven:maven-artifact-manager:jar:2.0.1 (selected for
> runtime)
> [DEBUG] org.apache.maven:maven-repository-metadata:jar:2.0.1 (selected
> for runtime)
> [DEBUG] org.apache.maven.wagon:wagon-provider-api:jar:1.0-alpha-5
> (selected for runtime)
> [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4 (removed - nearer
> found: 1.0.5)
> [DEBUG] org.apache.maven:maven-artifact:jar:2.0.1 (selected for runtime)
> [DEBUG] org.apache.maven:maven-artifact:jar:2.0.1 (selected for runtime)
> [DEBUG] org.apache.maven:maven-plugin-api:jar:2.0.1 (selected for runtime)
> [DEBUG] ant:ant:jar:1.6.5 (selected for runtime)
> [DEBUG] ant:ant-launcher:jar:1.6.5 (selected for runtime)
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Internal error in the plugin manager executing goal
> 'org.apache.maven.plugins:maven-antrun-plugin:1.0:run': Unable to find the
> mojo 'org.apache.maven.plugins:maven-antrun-plugin:1.0:run' in the plugin
> 'org.apache.maven.plugins:maven-antrun-plugin'
> Component descriptor cannot be found in the component repository:
> org.apache.maven.plugin.Mojoorg.apache.maven.plugins:maven-antrun-plugin:1.0:run.
> [INFO]
>
> [DEBUG] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: Internal error in the
> plugin manager executing goal
> 'org.apache.maven.plugins:maven-antrun-plugin:1.0:run': Unable to find the
> mojo 'org.apache.maven.plugins:maven-antrun-plugin:1.0:run' in the plugin
> 'org.apache.maven.plugins:maven-antrun-plugin'
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:472)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:451)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java: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(Nativ
[jira] Commented: (MANTRUN-37) Antrun breaks on multi-module builds
[ http://jira.codehaus.org/browse/MANTRUN-37?page=comments#action_60919 ]
Maciej Szefler commented on MANTRUN-37:
---
I have the same problem with 2.0.1 and 2.0.2. If no version is specified for
the plugin the problem occurs, if version 1.1 is specified, the problem occurs.
If version 1.0 is specified the problem does not occur.
> Antrun breaks on multi-module builds
>
>
> Key: MANTRUN-37
> URL: http://jira.codehaus.org/browse/MANTRUN-37
> Project: Maven 2.x Antrun Plugin
> Type: Bug
> Versions: 1.1
> Environment: Maven 2.0.1
> Reporter: Mike Perham
> Assignee: Carlos Sanchez
> Priority: Critical
>
>
> I just updated to antrun v1.1 (which needs to be marked as released in jira
> BTW) and find that my multimodule build is now breaking. Running the build
> in the child module itself works fine but if I build the parent, it fails
> when it gets to the child with the antrun task. Here's part of the debug
> output. Note it says 1.1 in the dependency tree but 1.0 further down.
> {noformat}
> [DEBUG] org.apache.maven.plugins:maven-antrun-plugin:maven-plugin:1.1
> (selected for runtime)
> [DEBUG] org.apache.maven:maven-project:jar:2.0.1 (selected for runtime)
> [DEBUG] org.apache.maven:maven-model:jar:2.0.1 (selected for runtime)
> [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.5 (selected for
> runtime)
> [DEBUG] classworlds:classworlds:jar:1.1-alpha-2 (selected for runtime)
> [DEBUG] org.apache.maven:maven-profile:jar:2.0.1 (selected for runtime)
> [DEBUG] org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9
> (selected for runtime)
> [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4 (removed - nearer
> found: 1.0.5)
> [DEBUG] junit:junit:jar:3.8.1 (selected for runtime)
> [DEBUG] org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9
> (selected for runtime)
> [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4 (removed - nearer
> found: 1.0.5)
> [DEBUG] classworlds:classworlds:jar:1.1-alpha-2 (selected for runtime)
> [DEBUG] junit:junit:jar:3.8.1 (selected for runtime)
> [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.5 (selected for runtime)
> [DEBUG] org.apache.maven:maven-artifact-manager:jar:2.0.1 (selected for
> runtime)
> [DEBUG] org.apache.maven:maven-repository-metadata:jar:2.0.1 (selected
> for runtime)
> [DEBUG] org.apache.maven.wagon:wagon-provider-api:jar:1.0-alpha-5
> (selected for runtime)
> [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4 (removed - nearer
> found: 1.0.5)
> [DEBUG] org.apache.maven:maven-artifact:jar:2.0.1 (selected for runtime)
> [DEBUG] org.apache.maven:maven-artifact:jar:2.0.1 (selected for runtime)
> [DEBUG] org.apache.maven:maven-plugin-api:jar:2.0.1 (selected for runtime)
> [DEBUG] ant:ant:jar:1.6.5 (selected for runtime)
> [DEBUG] ant:ant-launcher:jar:1.6.5 (selected for runtime)
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Internal error in the plugin manager executing goal
> 'org.apache.maven.plugins:maven-antrun-plugin:1.0:run': Unable to find the
> mojo 'org.apache.maven.plugins:maven-antrun-plugin:1.0:run' in the plugin
> 'org.apache.maven.plugins:maven-antrun-plugin'
> Component descriptor cannot be found in the component repository:
> org.apache.maven.plugin.Mojoorg.apache.maven.plugins:maven-antrun-plugin:1.0:run.
> [INFO]
>
> [DEBUG] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: Internal error in the
> plugin manager executing goal
> 'org.apache.maven.plugins:maven-antrun-plugin:1.0:run': Unable to find the
> mojo 'org.apache.maven.plugins:maven-antrun-plugin:1.0:run' in the plugin
> 'org.apache.maven.plugins:maven-antrun-plugin'
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:472)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:451)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java: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(Mave
[jira] Commented: (CONTINUUM-589) Configure JPOX to use a database pool
[ http://jira.codehaus.org/browse/CONTINUUM-589?page=comments#action_60924 ] Erik Bengtson commented on CONTINUUM-589: - More resources http://www.jpox.org/docs/1_1/rdbms_connection_pooling.html > Configure JPOX to use a database pool > - > > Key: CONTINUUM-589 > URL: http://jira.codehaus.org/browse/CONTINUUM-589 > Project: Continuum > Type: Improvement > Components: Core system > Reporter: Emmanuel Venisse > > > http://www.jpox.org/docs/faq.html#datasource_pools -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-780) Please upload the following QALab bundles - they are updated versions of the various QALab parts.
Please upload the following QALab bundles - they are updated versions of the various QALab parts. - Key: MAVENUPLOAD-780 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-780 Project: maven-upload-requests Type: Task Reporter: Dave Sag Attachments: maven-qalab-plugin-0.8.0-bundle.jar, maven-qalab-plugin-2.1-bundle.jar, qalab-0.8.0-bundle.jar qalab-0.8.0 the latest release of QALab - the software quality data aggregation and reporting utility. maven-qalab-plugin-0.8.0 - a maven 1 plugin that uses qalab 0.8 maven-qalab-plugin-2.1 a maven 2 plugin that uses qalab 0.8 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MANTRUN-37) Antrun breaks on multi-module builds
[ http://jira.codehaus.org/browse/MANTRUN-37?page=comments#action_60943 ]
Carlos Sanchez commented on MANTRUN-37:
---
Maciej, the issue was closed as not reproducible. If you have a sample please
post it.
> Antrun breaks on multi-module builds
>
>
> Key: MANTRUN-37
> URL: http://jira.codehaus.org/browse/MANTRUN-37
> Project: Maven 2.x Antrun Plugin
> Type: Bug
> Versions: 1.1
> Environment: Maven 2.0.1
> Reporter: Mike Perham
> Assignee: Carlos Sanchez
> Priority: Critical
>
>
> I just updated to antrun v1.1 (which needs to be marked as released in jira
> BTW) and find that my multimodule build is now breaking. Running the build
> in the child module itself works fine but if I build the parent, it fails
> when it gets to the child with the antrun task. Here's part of the debug
> output. Note it says 1.1 in the dependency tree but 1.0 further down.
> {noformat}
> [DEBUG] org.apache.maven.plugins:maven-antrun-plugin:maven-plugin:1.1
> (selected for runtime)
> [DEBUG] org.apache.maven:maven-project:jar:2.0.1 (selected for runtime)
> [DEBUG] org.apache.maven:maven-model:jar:2.0.1 (selected for runtime)
> [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.5 (selected for
> runtime)
> [DEBUG] classworlds:classworlds:jar:1.1-alpha-2 (selected for runtime)
> [DEBUG] org.apache.maven:maven-profile:jar:2.0.1 (selected for runtime)
> [DEBUG] org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9
> (selected for runtime)
> [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4 (removed - nearer
> found: 1.0.5)
> [DEBUG] junit:junit:jar:3.8.1 (selected for runtime)
> [DEBUG] org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9
> (selected for runtime)
> [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4 (removed - nearer
> found: 1.0.5)
> [DEBUG] classworlds:classworlds:jar:1.1-alpha-2 (selected for runtime)
> [DEBUG] junit:junit:jar:3.8.1 (selected for runtime)
> [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.5 (selected for runtime)
> [DEBUG] org.apache.maven:maven-artifact-manager:jar:2.0.1 (selected for
> runtime)
> [DEBUG] org.apache.maven:maven-repository-metadata:jar:2.0.1 (selected
> for runtime)
> [DEBUG] org.apache.maven.wagon:wagon-provider-api:jar:1.0-alpha-5
> (selected for runtime)
> [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4 (removed - nearer
> found: 1.0.5)
> [DEBUG] org.apache.maven:maven-artifact:jar:2.0.1 (selected for runtime)
> [DEBUG] org.apache.maven:maven-artifact:jar:2.0.1 (selected for runtime)
> [DEBUG] org.apache.maven:maven-plugin-api:jar:2.0.1 (selected for runtime)
> [DEBUG] ant:ant:jar:1.6.5 (selected for runtime)
> [DEBUG] ant:ant-launcher:jar:1.6.5 (selected for runtime)
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Internal error in the plugin manager executing goal
> 'org.apache.maven.plugins:maven-antrun-plugin:1.0:run': Unable to find the
> mojo 'org.apache.maven.plugins:maven-antrun-plugin:1.0:run' in the plugin
> 'org.apache.maven.plugins:maven-antrun-plugin'
> Component descriptor cannot be found in the component repository:
> org.apache.maven.plugin.Mojoorg.apache.maven.plugins:maven-antrun-plugin:1.0:run.
> [INFO]
>
> [DEBUG] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: Internal error in the
> plugin manager executing goal
> 'org.apache.maven.plugins:maven-antrun-plugin:1.0:run': Unable to find the
> mojo 'org.apache.maven.plugins:maven-antrun-plugin:1.0:run' in the plugin
> 'org.apache.maven.plugins:maven-antrun-plugin'
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:472)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:451)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java: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.NativeMethodAccess
[jira] Commented: (MJAVADOC-3) plugin should honor proxy settings
[ http://jira.codehaus.org/browse/MJAVADOC-3?page=comments#action_60944 ] Maria Odea Ching commented on MJAVADOC-3: - We can set the default values of the parameters to the proxy config in the settings.xml file. In that way, the proxy can be configured either through the pom or through maven-settings. > plugin should honor proxy settings > -- > > Key: MJAVADOC-3 > URL: http://jira.codehaus.org/browse/MJAVADOC-3 > Project: Maven 2.x Javadoc Plugin > Type: Bug > Environment: tested on Linux/Windows > Reporter: Dirk Olmes > Assignee: Maria Odea Ching > Priority: Minor > Fix For: 2.0-beta-4 > Attachments: MJAVADOC-3-maven-javadoc-plugin.patch > > Original Estimate: 3 hours, 30 minutes >Time Spent: 3 hours, 30 minutes > Remaining: 0 minutes > > The maven2 plugin should honor the proxy settings. When specifying the > option, the forked javadoc process always tries to fetch the package-list > directly. This fails on corporate networks, where all web access has to go > through a proxy. > I've tried to specify a proxy by using the option but this > does not work because all parameters for the javadoc process are written to > an options file, which is passed to the forked javadoc process. By the time > the javadoc process gets to see the arguments, it is already running so all > VM parameters (-J-Dhttp.proxyHost...) cause errors. > The most seamless integration would be to pass whatever proxy is configured > to the forked javadoc process. Configuration options for specifying the proxy > for the javadoc-plugin would be acceptable, too. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-770) jalopy-console-0.1-1.5rc2
[ http://jira.codehaus.org/browse/MAVENUPLOAD-770?page=comments#action_60945 ] Carlos Sanchez commented on MAVENUPLOAD-770: pomVersion has to be 3 > jalopy-console-0.1-1.5rc2 > - > > Key: MAVENUPLOAD-770 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-770 > Project: maven-upload-requests > Type: Task > Reporter: Joachim Bader > > > http://jalopy.sourceforge.net/jalopy-console/index.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-778) Please update 2.3.5 version of Freemarker library
[ http://jira.codehaus.org/browse/MAVENUPLOAD-778?page=comments#action_60946 ] Carlos Sanchez commented on MAVENUPLOAD-778: Please read http://maven.apache.org/guides/mini/guide-ibiblio-upload.html > Please update 2.3.5 version of Freemarker library > - > > Key: MAVENUPLOAD-778 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-778 > Project: maven-upload-requests > Type: Improvement > Reporter: Francesco Tinti > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-777) Wrong groupId for artifact "slf4j-log4j13"
[ http://jira.codehaus.org/browse/MAVENUPLOAD-777?page=all ] Carlos Sanchez closed MAVENUPLOAD-777: -- Assign To: Carlos Sanchez Resolution: Fixed > Wrong groupId for artifact "slf4j-log4j13" > -- > > Key: MAVENUPLOAD-777 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-777 > Project: maven-upload-requests > Type: Bug > Reporter: Ceki Gulcu > Assignee: Carlos Sanchez > Attachments: slf4j-log4j13-1.0-bundle.jar > > > I mistakenly had the wrong element in the POM file for > "slf4j-log4j13". As a consequence, the ibiblio repository has a dictory > called > "org.slf4j13". See [1]. > The attached jar file corrects this mistake.I suggest that the directory > related to "org.slf4j13" be removed immediately. > [1] http://www.ibiblio.org/maven/org.slf4j13/ -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-779) Upload request for NLOG4J 1.2.24
[ http://jira.codehaus.org/browse/MAVENUPLOAD-779?page=all ] Carlos Sanchez closed MAVENUPLOAD-779: -- Assign To: Carlos Sanchez Resolution: Fixed > Upload request for NLOG4J 1.2.24 > > > Key: MAVENUPLOAD-779 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-779 > Project: maven-upload-requests > Type: Task > Reporter: Ceki Gulcu > Assignee: Carlos Sanchez > Attachments: nlog4j-1.2.24-bundle.jar > > > Upload request for NLOG4J 1.2.24 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-780) Please upload the following QALab bundles - they are updated versions of the various QALab parts.
[ http://jira.codehaus.org/browse/MAVENUPLOAD-780?page=all ] Carlos Sanchez closed MAVENUPLOAD-780: -- Assign To: Carlos Sanchez Resolution: Fixed > Please upload the following QALab bundles - they are updated versions of the > various QALab parts. > - > > Key: MAVENUPLOAD-780 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-780 > Project: maven-upload-requests > Type: Task > Reporter: Dave Sag > Assignee: Carlos Sanchez > Attachments: maven-qalab-plugin-0.8.0-bundle.jar, > maven-qalab-plugin-2.1-bundle.jar, qalab-0.8.0-bundle.jar > > > qalab-0.8.0 the latest release of QALab - the software quality data > aggregation and reporting utility. > maven-qalab-plugin-0.8.0 - a maven 1 plugin that uses qalab 0.8 > maven-qalab-plugin-2.1 a maven 2 plugin that uses qalab 0.8 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-779) Upload request for NLOG4J 1.2.24
[ http://jira.codehaus.org/browse/MAVENUPLOAD-779?page=comments#action_60948 ] Carlos Sanchez commented on MAVENUPLOAD-779: I fixed some problems in the pom, please take note In maven 1 has to be inside provided > Upload request for NLOG4J 1.2.24 > > > Key: MAVENUPLOAD-779 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-779 > Project: maven-upload-requests > Type: Task > Reporter: Ceki Gulcu > Assignee: Carlos Sanchez > Attachments: nlog4j-1.2.24-bundle.jar > > > Upload request for NLOG4J 1.2.24 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MRM-103) Make the artifact discoverers use the artifact utils
Make the artifact discoverers use the artifact utils Key: MRM-103 URL: http://jira.codehaus.org/browse/MRM-103 Project: Maven Repository Manager Type: Improvement Components: discovery Reporter: Edwin Punzalan The parsing of an artifact path (both for m1 and m2) have been extracted into the MRM-utils module and the discovery should use this instead. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRM-103) Make the artifact discoverers use the artifact utils
[ http://jira.codehaus.org/browse/MRM-103?page=all ] Edwin Punzalan updated MRM-103: --- Assign To: Edwin Punzalan Remaining Estimate: 1 hour Original Estimate: 1 hour > Make the artifact discoverers use the artifact utils > > > Key: MRM-103 > URL: http://jira.codehaus.org/browse/MRM-103 > Project: Maven Repository Manager > Type: Improvement > Components: discovery > Reporter: Edwin Punzalan > Assignee: Edwin Punzalan > > Original Estimate: 1 hour > Remaining: 1 hour > > The parsing of an artifact path (both for m1 and m2) have been extracted into > the MRM-utils module and the discovery should use this instead. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MRM-101) ProxyManagerFactory is not needed
[ http://jira.codehaus.org/browse/MRM-101?page=all ] Edwin Punzalan closed MRM-101: -- Resolution: Fixed > ProxyManagerFactory is not needed > - > > Key: MRM-101 > URL: http://jira.codehaus.org/browse/MRM-101 > Project: Maven Repository Manager > Type: Improvement > Components: remote proxy > Reporter: Edwin Punzalan > Assignee: Edwin Punzalan > > Original Estimate: 3 hours > Remaining: 3 hours > > "It shouldn't be modifying the configuration from a parameter when the > configuration is also a parameter - just set it in the original > configuration. The caller can lookup the proxy manager directly and configure > it." - brett -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MRM-103) Make the artifact discoverers use the artifact utils
[ http://jira.codehaus.org/browse/MRM-103?page=all ] Edwin Punzalan closed MRM-103: -- Resolution: Fixed > Make the artifact discoverers use the artifact utils > > > Key: MRM-103 > URL: http://jira.codehaus.org/browse/MRM-103 > Project: Maven Repository Manager > Type: Improvement > Components: discovery > Reporter: Edwin Punzalan > Assignee: Edwin Punzalan > > Original Estimate: 1 hour >Time Spent: 1 hour > Remaining: 0 minutes > > The parsing of an artifact path (both for m1 and m2) have been extracted into > the MRM-utils module and the discovery should use this instead. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MJAVADOC-3) plugin should honor proxy settings
[ http://jira.codehaus.org/browse/MJAVADOC-3?page=all ] Maria Odea Ching updated MJAVADOC-3: Attachment: MJAVADOC-3-maven-javadoc-plugin.patch > plugin should honor proxy settings > -- > > Key: MJAVADOC-3 > URL: http://jira.codehaus.org/browse/MJAVADOC-3 > Project: Maven 2.x Javadoc Plugin > Type: Bug > Environment: tested on Linux/Windows > Reporter: Dirk Olmes > Assignee: Maria Odea Ching > Priority: Minor > Fix For: 2.0-beta-4 > Attachments: MJAVADOC-3-maven-javadoc-plugin.patch, > MJAVADOC-3-maven-javadoc-plugin.patch > > Original Estimate: 3 hours, 30 minutes >Time Spent: 3 hours, 30 minutes > Remaining: 0 minutes > > The maven2 plugin should honor the proxy settings. When specifying the > option, the forked javadoc process always tries to fetch the package-list > directly. This fails on corporate networks, where all web access has to go > through a proxy. > I've tried to specify a proxy by using the option but this > does not work because all parameters for the javadoc process are written to > an options file, which is passed to the forked javadoc process. By the time > the javadoc process gets to see the arguments, it is already running so all > VM parameters (-J-Dhttp.proxyHost...) cause errors. > The most seamless integration would be to pass whatever proxy is configured > to the forked javadoc process. Configuration options for specifying the proxy > for the javadoc-plugin would be acceptable, too. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MRM-104) ProxyConfiguration enhancements
ProxyConfiguration enhancements --- Key: MRM-104 URL: http://jira.codehaus.org/browse/MRM-104 Project: Maven Repository Manager Type: Improvement Components: remote proxy Reporter: Edwin Punzalan According to brett, these are the need improvements: - make repoCache a member of the ProxyManager, which will remove ArtifactRepositoryFactory - browsable should be a configuration of the webapp - remove field storage for the layout and use plexus to lookup valid values - loadMavenProxyConfiguration should be in a separate reader class -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-6) improve documentation
[ http://jira.codehaus.org/browse/MCOMPILER-6?page=all ] Carlos Sanchez updated MCOMPILER-6: --- Fix Version: 2.0.1 > improve documentation > - > > Key: MCOMPILER-6 > URL: http://jira.codehaus.org/browse/MCOMPILER-6 > Project: Maven 2.x Compiler Plugin > Type: Bug > Reporter: Brett Porter > Fix For: 2.0.1 > > > some aspects are unclear: > - compilerVersion is only used when forking > - fork should indicate that it uses the built in version when false, not an > executable. > Also: > - don't set parameters that only apply to forking when fork is false to make > the code more readable > - specifiy which are specific to javac, or java in general (perhaps we should > be able to assign a @category to a plugin parameter) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MCOMPILER-5) OOM in reactor build and javac
[ http://jira.codehaus.org/browse/MCOMPILER-5?page=comments#action_60956 ] Carlos Sanchez commented on MCOMPILER-5: Please run maven with -X to get more relevant output fork should work, if not please open a jira issue > OOM in reactor build and javac > -- > > Key: MCOMPILER-5 > URL: http://jira.codehaus.org/browse/MCOMPILER-5 > Project: Maven 2.x Compiler Plugin > Type: Bug > Environment: Windows JDK 1.4.2 > Reporter: Mike Perham > > > We are seeing a OOM error when running a medium-sized reactor build (approx > 15 projects). After about 10 modules, the javac plugin fails with an OOM in > a module that actually has just a single java file. Forking the VM actually > leads to an immediate error in the first module so I assume forking does not > work currently. > Setting the max heap memory by using set MAVEN_OPTS=-Xmx512m has no visible > effect. > The system is out of resources. > Consult the following stack trace for details. > java.lang.OutOfMemoryError > [INFO] -- > [INFO] For more information, run Maven with the -e switch > [INFO] -- > [INFO] Total time: 4 minutes 16 seconds > [INFO] Finished at: Thu Nov 10 14:00:27 CST 2005 > [INFO] Final Memory: 63M/140M > [INFO] -- > I realize there is not a lot of info here. Please let me know how I can > supply more specific information for you. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-63) replace interpolated values with decoration model directives
[ http://jira.codehaus.org/browse/MSITE-63?page=all ]
Brett Porter closed MSITE-63:
-
Resolution: Fixed
> replace interpolated values with decoration model directives
>
>
> Key: MSITE-63
> URL: http://jira.codehaus.org/browse/MSITE-63
> Project: Maven 2.x Site Plugin
> Type: Improvement
> Reporter: Brett Porter
> Fix For: 2.0
>
>
> this will help differentiate between what is declarative (eg, the positional
> ), vs what should be populated (${modules})
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (MIDEA-32) Changed Xpp3Dom in favor of dom4j
[ http://jira.codehaus.org/browse/MIDEA-32?page=comments#action_60958 ] Edwin Punzalan commented on MIDEA-32: - Johann, I don't think its the path. Cause its still not working with this same message in tortoise: -- The patch seems outdated! The file line and the patch line } do not match! -- > Changed Xpp3Dom in favor of dom4j > - > > Key: MIDEA-32 > URL: http://jira.codehaus.org/browse/MIDEA-32 > Project: Maven 2.x Idea Plugin > Type: Improvement > Reporter: Johann Reyes > Assignee: Edwin Punzalan > Fix For: 2.0 > Attachments: MIDEA-32.patch, MIDEA-32.patch > > > As per @todo changed from Xpp3Dom to dom4j so it can cope properly with > entities. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MRM-104) ProxyConfiguration enhancements
[ http://jira.codehaus.org/browse/MRM-104?page=all ] Edwin Punzalan updated MRM-104: --- Assign To: Edwin Punzalan Remaining Estimate: 3 hours Original Estimate: 3 hours > ProxyConfiguration enhancements > --- > > Key: MRM-104 > URL: http://jira.codehaus.org/browse/MRM-104 > Project: Maven Repository Manager > Type: Improvement > Components: remote proxy > Reporter: Edwin Punzalan > Assignee: Edwin Punzalan > > Original Estimate: 3 hours > Remaining: 3 hours > > According to brett, these are the need improvements: > - make repoCache a member of the ProxyManager, which will remove > ArtifactRepositoryFactory > - browsable should be a configuration of the webapp > - remove field storage for the layout and use plexus to lookup valid values > - loadMavenProxyConfiguration should be in a separate reader class -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MJAVADOC-3) plugin should honor proxy settings
[ http://jira.codehaus.org/browse/MJAVADOC-3?page=all ] Allan Ramirez closed MJAVADOC-3: Resolution: Fixed Applied patch. > plugin should honor proxy settings > -- > > Key: MJAVADOC-3 > URL: http://jira.codehaus.org/browse/MJAVADOC-3 > Project: Maven 2.x Javadoc Plugin > Type: Bug > Environment: tested on Linux/Windows > Reporter: Dirk Olmes > Assignee: Maria Odea Ching > Priority: Minor > Fix For: 2.0-beta-4 > Attachments: MJAVADOC-3-maven-javadoc-plugin.patch, > MJAVADOC-3-maven-javadoc-plugin.patch > > Original Estimate: 3 hours, 30 minutes >Time Spent: 4 hours > Remaining: 0 minutes > > The maven2 plugin should honor the proxy settings. When specifying the > option, the forked javadoc process always tries to fetch the package-list > directly. This fails on corporate networks, where all web access has to go > through a proxy. > I've tried to specify a proxy by using the option but this > does not work because all parameters for the javadoc process are written to > an options file, which is passed to the forked javadoc process. By the time > the javadoc process gets to see the arguments, it is already running so all > VM parameters (-J-Dhttp.proxyHost...) cause errors. > The most seamless integration would be to pass whatever proxy is configured > to the forked javadoc process. Configuration options for specifying the proxy > for the javadoc-plugin would be acceptable, too. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-770) jalopy-console-0.1-1.5rc2
[ http://jira.codehaus.org/browse/MAVENUPLOAD-770?page=comments#action_60961 ] Joachim Bader commented on MAVENUPLOAD-770: --- pomVersion has changed into 3 > jalopy-console-0.1-1.5rc2 > - > > Key: MAVENUPLOAD-770 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-770 > Project: maven-upload-requests > Type: Task > Reporter: Joachim Bader > > > http://jalopy.sourceforge.net/jalopy-console/index.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MJAVADOC-28) [EMAIL PROTECTED] foo} doesn't work when "foo" is a package name
[ http://jira.codehaus.org/browse/MJAVADOC-28?page=comments#action_60962 ] Maria Odea Ching commented on MJAVADOC-28: -- Cannot reproduce error. When javadoc was executed, there were no warnings for the [EMAIL PROTECTED] tags in the javadoc comments of the test project. The links were also present in the generated javadocs. > [EMAIL PROTECTED] foo} doesn't work when "foo" is a package name > - > > Key: MJAVADOC-28 > URL: http://jira.codehaus.org/browse/MJAVADOC-28 > Project: Maven 2.x Javadoc Plugin > Type: Bug > Environment: Windows XP > Reporter: Martin Desruisseaux > Assignee: Maria Odea Ching > Priority: Minor > Fix For: 2.0-beta-4 > > > See or link tags of the kind [EMAIL PROTECTED] org.mypackage} doesn't work > with maven-javadoc-plugin (we get a "Tag @link: reference not found: > org.mypackage" warning), while it work when using the javadoc tool from the > command line or from an Ant script. I suspect that this is related to the way > maven-javadoc-plugin work, which provides a list of source files as a @files > argument. > A possible workaround is to provide a way to use the maven-javadoc-plugin > through the javadoc's -subpackages option, instead of letting > maven-javadoc-plugin creates a @files. It would gives more control to the > user, would allows the current parameter to work (this > parameter is currently useless since it is ignored when the files to process > are provided in @files), and would solve the problem reported in this JIRA > issue. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-781) please replace maven-qalab-plugin 2.1 with this one - the last one was missing something vital
please replace maven-qalab-plugin 2.1 with this one - the last one was missing something vital -- Key: MAVENUPLOAD-781 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-781 Project: maven-upload-requests Type: Bug Reporter: Dave Sag Attachments: maven-qalab-plugin-2.1-bundle.jar Last night I inadvertantly made a bundle of the wrong version of my maven2 qalab plugin. (see MAVENUPLOAD-780) the attached file is the correct bundle. many apologies. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MRM-104) ProxyConfiguration enhancements
[ http://jira.codehaus.org/browse/MRM-104?page=all ] Edwin Punzalan closed MRM-104: -- Resolution: Fixed > ProxyConfiguration enhancements > --- > > Key: MRM-104 > URL: http://jira.codehaus.org/browse/MRM-104 > Project: Maven Repository Manager > Type: Improvement > Components: remote proxy > Reporter: Edwin Punzalan > Assignee: Edwin Punzalan > > Original Estimate: 3 hours > Remaining: 3 hours > > According to brett, these are the need improvements: > - make repoCache a member of the ProxyManager, which will remove > ArtifactRepositoryFactory > - browsable should be a configuration of the webapp > - remove field storage for the layout and use plexus to lookup valid values > - loadMavenProxyConfiguration should be in a separate reader class -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
