[jira] Created: (MRAR-15) Allow more customizations of resources to be included
Allow more customizations of resources to be included
-
Key: MRAR-15
URL: http://jira.codehaus.org/browse/MRAR-15
Project: Maven 2.x Rar Plugin
Issue Type: Improvement
Affects Versions: 2.2
Reporter: Jason Dillon
Should allow more customizations of resources to include... similar to
maven-war-plugin's {{}}.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly 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: (MRAR-3) Rar should be, or be able to be considered as, attached artifacts
[ http://jira.codehaus.org/browse/MRAR-3?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_88745 ] Jason Dillon commented on MRAR-3: - Is this issue still relevant? > Rar should be, or be able to be considered as, attached artifacts > - > > Key: MRAR-3 > URL: http://jira.codehaus.org/browse/MRAR-3 > Project: Maven 2.x Rar Plugin > Issue Type: Bug >Reporter: Guillaume Nodet >Priority: Critical > > ActiveMQ used to deploy both jar and rar. > And both are used. > I do not see any way to do so in m2. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MPIR-61) [PATCH] Updated CI Systems
[PATCH] Updated CI Systems -- Key: MPIR-61 URL: http://jira.codehaus.org/browse/MPIR-61 Project: Maven 2.x Project Info Reports Plugin Issue Type: Improvement Reporter: Mark Holster Priority: Minor Attachments: ci-systems.patch Added cruisecontrol, luntbuild, hudson & buildforge as recognized CI Systems. Removed bugzilla as it is a bug trackings system, not a ci system. If appreciated I could translate the english resource file to the dutch (nl) locale... just let me know. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MDEPLOY-48) deploy:deploy-file does not support deploying sources jars too
[ http://jira.codehaus.org/browse/MDEPLOY-48?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_88756 ] Harald Kuhr commented on MDEPLOY-48: It's possible to upload sources via the -Dclassifier=sources switch, the problem with this is it bumps the build-version of snapshots.. So I can't have sources and classes of the same version. A workaround is to manually rename the jar, sha and md5 to the latest version after update, but it is of course not a very elegant solution... Had a chat with Trygvis last night and he told it should be an easy thing to fix, so I'll expect it done by tomorrow. ;-) > deploy:deploy-file does not support deploying sources jars too > -- > > Key: MDEPLOY-48 > URL: http://jira.codehaus.org/browse/MDEPLOY-48 > Project: Maven 2.x Deploy Plugin > Issue Type: Improvement >Affects Versions: 2.3 >Reporter: Geoffrey De Smet > > deploy:deploy does, but deploy:deploy-file doesn't have a parameter to tell > him where the sources jar is: > mvn deploy:deploy-file -Dfile=$artifactFile -DpomFile=$pomFile -Durl=$toRepo -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-1833) Site plugin strips leading slash in urls
Site plugin strips leading slash in urls Key: MAVEN-1833 URL: http://jira.codehaus.org/browse/MAVEN-1833 Project: Maven 1.x Issue Type: Bug Affects Versions: 1.1-beta-2 Environment: Linux, Sun java 1.4 Reporter: Tim Pizey A link in navigation.xml with href='/index.html' does not create a link to server homepage but to current directory. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MSITE-214) Show repositories an artifact is deployed to as a report
Show repositories an artifact is deployed to as a report Key: MSITE-214 URL: http://jira.codehaus.org/browse/MSITE-214 Project: Maven 2.x Site Plugin Issue Type: Improvement Affects Versions: 2.0-beta-5 Environment: All Reporter: Tim Pizey Google can get one to the website for an artifact, but discovering which repository it is deployed to seems to rely upon asking on IRC, extracting the target repositories and creating a standard report would fix this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2362) Deployed POM is not valid XML
[ http://jira.codehaus.org/browse/MNG-2362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_88771 ] Jason van Zyl commented on MNG-2362: Could you please take the sample project and attach it to the release plugin. I would say the issue is fixed in the core as the POM is now left alone. So part one of the problem is resolved. > Deployed POM is not valid XML > - > > Key: MNG-2362 > URL: http://jira.codehaus.org/browse/MNG-2362 > Project: Maven 2 > Issue Type: Bug > Components: POM >Affects Versions: 2.0.4 >Reporter: Joerg Schaible > Assigned To: Jason van Zyl >Priority: Critical > Fix For: 2.0.6 > > Attachments: MNG-2362.zip > > > If the POM has utf-8 encoding and you make usage of entities to support > extended characters, these characters are no longer encoded as entities in > the repository (well, the effect is already visible in > target/effective-pom.xml). This is not a rule of general, POMs with packaging > "pom" are installed and deployed correclty. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-2362) Deployed POM is not valid XML
[ http://jira.codehaus.org/browse/MNG-2362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-2362. -- Resolution: Fixed The real issue is now in the modified POMs created by the release plugin. > Deployed POM is not valid XML > - > > Key: MNG-2362 > URL: http://jira.codehaus.org/browse/MNG-2362 > Project: Maven 2 > Issue Type: Bug > Components: POM >Affects Versions: 2.0.4 >Reporter: Joerg Schaible > Assigned To: Jason van Zyl >Priority: Critical > Fix For: 2.0.6 > > Attachments: MNG-2362.zip > > > If the POM has utf-8 encoding and you make usage of entities to support > extended characters, these characters are no longer encoded as entities in > the repository (well, the effect is already visible in > target/effective-pom.xml). This is not a rule of general, POMs with packaging > "pom" are installed and deployed correclty. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MRELEASE-201) Deployed POM is not valid XML
Deployed POM is not valid XML - Key: MRELEASE-201 URL: http://jira.codehaus.org/browse/MRELEASE-201 Project: Maven 2.x Release Plugin Issue Type: Bug Reporter: Joerg Schaible Attachments: MNG-2362.zip If the POM has utf-8 encoding and you make usage of entities to support extended characters, these characters are no longer encoded as entities in the repository (well, the effect is already visible in target/effective-pom.xml). This is not a rule of general, POMs with packaging "pom" are installed and deployed correctly. Multi module example. The attached archive contains a parent POM and a POM for a jar. Both UTF-8 encoded POMs contain a developer with a name using an entitiy. Releasing the POMs they are written with the expanded entitiy making the XML invalid. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-2252) Upgrade to plexus-utils 1.3
[ http://jira.codehaus.org/browse/MNG-2252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-2252. -- Resolution: Fixed Upgraded to 1.4. > Upgrade to plexus-utils 1.3 > --- > > Key: MNG-2252 > URL: http://jira.codehaus.org/browse/MNG-2252 > Project: Maven 2 > Issue Type: Improvement > Components: Dependencies >Affects Versions: 2.0.4, 2.0.5 >Reporter: Carlos Sanchez > Assigned To: Jason van Zyl > Fix For: 2.0.6 > > > When ready, upgrade to plexus-utils 1.3 > This issue is just a placeholder for other ones to depend on -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-2828) Upgrade the dependency on plexus-utils to a more recent version
[ http://jira.codehaus.org/browse/MNG-2828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-2828. -- Resolution: Fixed Upgraded to 1.4. > Upgrade the dependency on plexus-utils to a more recent version > --- > > Key: MNG-2828 > URL: http://jira.codehaus.org/browse/MNG-2828 > Project: Maven 2 > Issue Type: Improvement >Affects Versions: 2.0.5 >Reporter: Rémy Sanlaville > Assigned To: Jason van Zyl > Fix For: 2.0.6 > > > Maven 2.0.5 depends on plexus-utils:1.1 (cf. %M2_HOME%\core) while the last > version of plexus-utils is 1.4 (cf. > http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-utils/). > It would be nice to upgrade the dependency on plexus-utils to a more recent > version. > Rémy -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-2776) Upgrade the dependency on modello-maven-plugin to a more recent version
[ http://jira.codehaus.org/browse/MNG-2776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-2776. -- Resolution: Fixed POMs updated to configure the use of the modello plugin from the top-level POM. > Upgrade the dependency on modello-maven-plugin to a more recent version > --- > > Key: MNG-2776 > URL: http://jira.codehaus.org/browse/MNG-2776 > Project: Maven 2 > Issue Type: Task >Affects Versions: 2.0.4 >Reporter: Dennis Lundberg > Assigned To: Jason van Zyl > Fix For: 2.0.6 > > > Upgrade the dependency on modello-maven-plugin in maven-model to alpha-13 (or > alpha-14 if that is released). This would bring in a couple of nice features > for the generated documentation. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MCHANGELOG-56) Date format not understood by CVS
Date format not understood by CVS
-
Key: MCHANGELOG-56
URL: http://jira.codehaus.org/browse/MCHANGELOG-56
Project: Maven 2.x Changelog Plugin
Issue Type: Bug
Environment: CVS 1.12.13, Linux 2.6.18-4-xen-686 #1 SMP Thu Jan 25
02:34:40 UTC 2007 i686 GNU/Linux
Reporter: Stefan Seidel
In my pom.xml:
{code}
org.apache.maven.plugins
maven-changelog-plugin
2.0-SNAPSHOT
...
{code}
mvn site output:
{code}
[INFO] Scanning for projects...
[INFO]
[INFO] Building ReportingsPortlet
[INFO]task-segment: [site]
[INFO]
[INFO] Setting property: classpath.resource.loader.class =>
'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'.
[INFO] Setting property: velocimacro.messages.on => 'false'.
[INFO] Setting property: resource.loader => 'classpath'.
[INFO] Setting property: resource.manager.logwhenfound => 'false'.
[INFO] Setting property: classpath.resource.loader.class =>
'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'.
[INFO] Setting property: velocimacro.messages.on => 'false'.
[INFO] Setting property: resource.loader => 'classpath'.
[INFO] Setting property: resource.manager.logwhenfound => 'false'.
[INFO] [site:site]
[INFO] Skipped "About" report, file "index.html" already exists for the English
version.
[INFO] Generate "Change Log" report.
[INFO] Generating changed sets xml to:
/home/stefan/workspace/alles/xpm-portal/portlets/Reportings/target/changelog.xml
[INFO] Executing: cvs -z3 -f -d :pserver:[EMAIL PROTECTED]:/home/cvs -q log -d
2007-01-29T15:46:22+0100<2007-03-01T15:46:22+0100
[INFO] Working directory:
/home/stefan/workspace/alles/xpm-portal/portlets/Reportings/src/main/java
[ERROR] Provider message:
[ERROR] The cvs command failed.
[ERROR] Command output:
[ERROR] cvs [log aborted]: Can't parse date/time: `2007-01-29T15:46:22+0100'
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Error during page generation
Embedded error: Error rendering Maven report: An error is occurred during
changelog command :
Command failed.
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 7 seconds
[INFO] Finished at: Wed Feb 28 15:46:22 GMT+01:00 2007
[INFO] Final Memory: 20M/116M
[INFO]
{code}
It is understandable, because this CVS version just does not support this
strange date format.
Running
{code}
cvs -z3 -f -d :pserver:[EMAIL PROTECTED]:/home/cvs -q log -d "2007-01-29
15:46:22 +0100<2007-03-01 15:46:22 +0100"
{code}
on the command line instead does work.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CONTINUUM-972) Unable to delete projects
[ http://jira.codehaus.org/browse/CONTINUUM-972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_88786 ] Peter Kehren commented on CONTINUUM-972: I have a similar problem. I cannot delete projects, if they habe a lot of builds (more than 10.000 for example). The result is the same as already described above. > Unable to delete projects > - > > Key: CONTINUUM-972 > URL: http://jira.codehaus.org/browse/CONTINUUM-972 > Project: Continuum > Issue Type: Bug > Components: Core system >Affects Versions: 1.0.3 > Environment: Redhat Enterprise 3 >Reporter: Uri Moszkowicz > > I am unable to delete project sometimes. I've tried creating a simple project > and immediately deleting it. That seems to work. But when I create a real > project, let it run for a few days and then try to delete it I cannot. > To reproduce: > 1. Install continuum > 2. Create a project > 3. Let it run for at least one build (success or failure doesn't matter) > 4. Delete the project by clicking on "X" from main project page. A delete > confirmation page should then appear. > 5. Click on the "delete" button to confirm. The web browser then begins > loading but it never terminates. The logs show no exceptions. The delete just > hangs. > I've removed all the files from the build-output and working-directory and > tried deleting again. This makes no difference. If you interrupt the delete > and click on show projects the projects page ends up in an inconsistent state > (not as many columns, no buttons, an Apache copyright message). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CONTINUUM-663) Google Summer Of Code 2006 proposal for Continuum Eclipse Plugin
[ http://jira.codehaus.org/browse/CONTINUUM-663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse updated CONTINUUM-663: --- Comment: was deleted > Google Summer Of Code 2006 proposal for Continuum Eclipse Plugin > - > > Key: CONTINUUM-663 > URL: http://jira.codehaus.org/browse/CONTINUUM-663 > Project: Continuum > Issue Type: New Feature > Environment: Maven 2.0.x, Continuum 1.0.x, Eclipse 3.2 >Reporter: Rahul Thakur > Assigned To: Rahul Thakur > Attachments: cm-plugin.tar.gz, > Continuum-Eclipse-plugin-Google-SOC2006-proposal.txt, > Continuum-Eclipse-plugin-Google-SOC2006-proposal.txt > > Original Estimate: 8 weeks > Remaining Estimate: 8 weeks > > It is proposed for Google SOC 2006 to develop a Continuum Eclipse Plugin that > could be used by Eclipse users to manage project builds on a remote Continuum > server. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CONTINUUM-895) Add a delete confirmation screen for user
[ http://jira.codehaus.org/browse/CONTINUUM-895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse updated CONTINUUM-895: --- Comment: was deleted > Add a delete confirmation screen for user > - > > Key: CONTINUUM-895 > URL: http://jira.codehaus.org/browse/CONTINUUM-895 > Project: Continuum > Issue Type: New Feature > Components: Web interface >Reporter: Marvin King > Assigned To: Emmanuel Venisse > Fix For: 1.1 > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CONTINUUM-713) re-enabling xfire?
[ http://jira.codehaus.org/browse/CONTINUUM-713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse updated CONTINUUM-713: --- Comment: was deleted > re-enabling xfire? > -- > > Key: CONTINUUM-713 > URL: http://jira.codehaus.org/browse/CONTINUUM-713 > Project: Continuum > Issue Type: Wish >Affects Versions: 1.0.2, 1.0.3 >Reporter: Laszlo Hornyak Kocka > Fix For: 1.1 > > > As far as I remember XFire-based ws interface was disabled by default from > continuum in release 1.0.2, and I did not manange to re-enable it. > XFire 1.1 has motm support, so the build data can be streamed to clients e.g. > for IDE-plugins... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-143) SCP works for deploy goal, but not for site-deploy
[ http://jira.codehaus.org/browse/MSITE-143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_88791 ] David W commented on MSITE-143: --- I have same issue, to deploy site reports from windows to linux server. and it is a blocker for me. > SCP works for deploy goal, but not for site-deploy > -- > > Key: MSITE-143 > URL: http://jira.codehaus.org/browse/MSITE-143 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-5 >Reporter: Jacob Robertson > > The linux admins did everything necessary to get the deploy goal to work, and > now I have to go back to them and try and figure out why the "site-deploy" > goal says "Auth failed". Why does deploy work just fine with scp, but not > site-deploy? My environment is such that my deploy repository and my deploy > site directories are in the same parent directory, and have the exact same > permissions. But one goal fails to upload, and the other doesn't... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MECLIPSE-208) Implicit dependencies are not resolved when using make-artifacts with stripQualifier=false
[ http://jira.codehaus.org/browse/MECLIPSE-208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthew Beermann updated MECLIPSE-208: -- Attachment: MECLIPSE-208-maven-eclipse-plugin.patch I believe that this patch solves the issue. > Implicit dependencies are not resolved when using make-artifacts with > stripQualifier=false > -- > > Key: MECLIPSE-208 > URL: http://jira.codehaus.org/browse/MECLIPSE-208 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: PDE support >Affects Versions: 2.3 > Environment: Windows XP, Eclipse 3.3 M4 >Reporter: Chad Moats > Attachments: MECLIPSE-208-maven-eclipse-plugin.patch > > > When using qualifiers with the make-artifacts goal, implict dependencies > cannot be resolved because they fall outside the version range used. This > issue was found when trying to deploy Eclipse 3.3 M4 to my local repository > while retaining the qualifier. For example, the org.eclipse.core.runtime pom > that is gernerated states that it depends on org.eclipse.equinox.app using > the range of [1.0.0,2.0.0). The actual version number of the > org.eclipse.equinox.app is 1.0.0-v. Using a qualifier means that the > version actually falls before the 1.0.0-2.0.0 range. The following error is > logged: > Couldn't find a version in [1.0.0-v20061208] to match range [1.0.0,2.0.0) > org.eclipse.equinox:org.eclipse.equinox.app:jar:null -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-1190) Ability to edit nicely a build definition with scope group in a project
Ability to edit nicely a build definition with scope group in a project --- Key: CONTINUUM-1190 URL: http://jira.codehaus.org/browse/CONTINUUM-1190 Project: Continuum Issue Type: New Feature Components: Core - Profiles, Web interface Affects Versions: 1.1 Reporter: Stephane Nicoll When in a particular project, an administrator has the ability to edit a build definition from the GROUP but the current behavior is confusing since the changes is applicable to all projects in the group. Suggestion. When a build definition with scope GROUP is edited within a project, it is transformed automatically in a new build definition with scope PROJECT (with eventually a confirmation message). In general, editing stuff in a project page should only affect the project. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (CONTINUUM-1191) editProject: NoSuchMethodException:
editProject: NoSuchMethodException:
---
Key: CONTINUUM-1191
URL: http://jira.codehaus.org/browse/CONTINUUM-1191
Project: Continuum
Issue Type: Bug
Components: XMLRPC Interface
Affects Versions: 1.0.3
Reporter: Patrick Huber
I'm writing a small application that's intended to consolidate all build goals
and arguments for all our projects in continuum:
Client:
---
String address = "http://continuumhost:8000/continuum";;
ProjectsReader reader = new ProjectsReader(new URL(address));
for (Project project : reader.readProjects()) {
// reader.refreshProject(project);
List defs = project.getBuildDefinitions();
if (defs != null && defs.size() == 1) {
for (BuildDefinition def : defs) {
def.setGoals("clean deploy site:site site:deploy eclipse:eclipse
scm:checkin");
def.setArguments("--batch-mode --non-recursive
-Dincludes=\".project .classpath .settings\" -Dmessage=\"continuum checkin of
generated eclipse files\"");
}
}
else {
System.out.println("Project " + project.getId() + " " +
project.getName() + " has not exactly one build");
}
reader.editProject(project);
---
Exception:
---
Exception in thread "main" org.apache.xmlrpc.XmlRpcException:
java.lang.NoSuchMethodException:
org.apache.maven.continuum.xmlrpc.DefaultContinuumXmlRpc.updatenullProject(java.util.Hashtable)
at
org.apache.xmlrpc.XmlRpcClientResponseProcessor.decodeException(XmlRpcClientResponseProcessor.java:102)
at
org.apache.xmlrpc.XmlRpcClientResponseProcessor.decodeResponse(XmlRpcClientResponseProcessor.java:69)
at
org.apache.xmlrpc.XmlRpcClientWorker.execute(XmlRpcClientWorker.java:72)
at org.apache.xmlrpc.XmlRpcClient.execute(XmlRpcClient.java:193)
at org.apache.xmlrpc.XmlRpcClient.execute(XmlRpcClient.java:184)
at org.apache.xmlrpc.XmlRpcClient.execute(XmlRpcClient.java:177)
at
org.apache.maven.continuum.rpc.ProjectsReader.editProject(ProjectsReader.java:127)
at SampleClient.main(SampleClient.java:55)
---
It doesn't matter wether or not "reader.refreshProject(project);" is active. Am
I doing something wrong here or is this a bug? The documentation only shows how
to read a project...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (CONTINUUM-1192) Ability to disable a project group build definition per project
Ability to disable a project group build definition per project --- Key: CONTINUUM-1192 URL: http://jira.codehaus.org/browse/CONTINUUM-1192 Project: Continuum Issue Type: New Feature Components: Core - Profiles, Web interface Affects Versions: 1.1 Reporter: Stephane Nicoll Project group's build definitions are automatically inherited to any project created within the group which is fine. It would be even better if an administrator had the ability to disable such a build definition per project. For now, the only way is to override the default build definition which is confusing since the group's default build definition is not disabled. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MANTRUN-69) Embedded error: Could not create task or type of type: setproxy.
Embedded error: Could not create task or type of type: setproxy. Key: MANTRUN-69 URL: http://jira.codehaus.org/browse/MANTRUN-69 Project: Maven 2.x Antrun Plugin Issue Type: Bug Affects Versions: 1.1, 1.0 Environment: Windows XP Pro; Maven 2.0.4; JDK 1.5.0_10 Reporter: Thomas Kappen In order to access an external resource via a proxy within an ant build script, I need to configure a proxy. The antrun proxy does not recognise the Maven proxy settings in the settings.xml. Further, the ant task does not work: This configuration will cause an error: maven-antrun-plugin test run The error: INFO] ERROR] BUILD ERROR INFO] INFO] Error executing ant tasks I'm wondering about this error, because is an build-in ant task. This error occurs also, if the task is being used in the called ant build script. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-1193) Can't use continuum for M2 projects with externals
Can't use continuum for M2 projects with externals -- Key: CONTINUUM-1193 URL: http://jira.codehaus.org/browse/CONTINUUM-1193 Project: Continuum Issue Type: Bug Components: Core system Affects Versions: 1.1 Reporter: Nigel Magnay Priority: Blocker Using a recent HEAD checkout, if you try and add projects that use external modules in svn - for example http://svn.codehaus.org/cargo/trunks/pom.xml You get many add.project.missing.pom.errors This means I can't use continuum to build my project (which uses a similar build style) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-2330) Unable to execute eclipse:eclipse goal with embedded maven
[ http://jira.codehaus.org/browse/MNG-2330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-2330. -- Resolution: Fixed Appears to work fine now: http://svn.apache.org/repos/asf/maven/components/trunk/maven-embedder/src/test/java/org/apache/maven/embedder/MavenEmbedderUsingEclipsePluginTest.java > Unable to execute eclipse:eclipse goal with embedded maven > -- > > Key: MNG-2330 > URL: http://jira.codehaus.org/browse/MNG-2330 > Project: Maven 2 > Issue Type: Bug > Components: Embedding >Affects Versions: 2.0.4 > Environment: Windows >Reporter: Philip Dodds > Assigned To: Jason van Zyl > Fix For: 2.1.x > > Attachments: AdditionalInformation.txt > > > While trying to use an embedded maven within Eclipse to access the Archetype > logic I get a probem with resolution of the plugins. > I have attached in the text file the following: > A dump of the logging > The helper that is calling the embedded maven > The POM.xml that was generated in the first step (the archetype) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-2670) I'd like to get maven-embedder-2.0.4-dep.jar from central repository
[ http://jira.codehaus.org/browse/MNG-2670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-2670. -- Resolution: Fixed Won't be published, that embedder is highly defective. I will try to integrate the embedder work into 2.0.6 but this depends on getting the new version of the plexus container working in 2.0.6. > I'd like to get maven-embedder-2.0.4-dep.jar from central repository > - > > Key: MNG-2670 > URL: http://jira.codehaus.org/browse/MNG-2670 > Project: Maven 2 > Issue Type: Wish > Components: Embedding >Affects Versions: 2.0.4 >Reporter: YOKOTA Takehiko > Assigned To: Jason van Zyl >Priority: Minor > > I'd like to get maven-embedder-2.0.4-dep.jar from central repository. Could > anyone deploy the 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: (MNG-1117) MavenEmbedder.writeModel( w, model) should allow to preserve xml formatting
[ http://jira.codehaus.org/browse/MNG-1117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-1117. -- Resolution: Fixed The WriterUtils are now being used and this is the best we have right now for preserving the format. > MavenEmbedder.writeModel( w, model) should allow to preserve xml formatting > --- > > Key: MNG-1117 > URL: http://jira.codehaus.org/browse/MNG-1117 > Project: Maven 2 > Issue Type: Improvement > Components: Embedding >Reporter: Eugene Kuleshov > Assigned To: Jason van Zyl >Priority: Critical > Fix For: 2.1-alpha-1 > > > Currently MavenEmbedder.writeModel( w, model) method does not take into > account formatting of the existing pom.xml. This is critical limitation from > an end-user prospective. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-1072) Create an interface for user interaction for the embedder
[ http://jira.codehaus.org/browse/MNG-1072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-1072. -- Resolution: Fixed This is a bad idea I've decided. The client should be responsible for all interactivity and the embedder should simply get the session and request level configuration. > Create an interface for user interaction for the embedder > - > > Key: MNG-1072 > URL: http://jira.codehaus.org/browse/MNG-1072 > Project: Maven 2 > Issue Type: Task > Components: Embedding >Reporter: Jason van Zyl > Assigned To: Jason van Zyl > Fix For: 2.1.x > > > We need to provide an interface for user interaction that hides plexus and > allows users to anser simple questions like accepting new versions of plugins. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-1118) mavenEmbedder.readProjectWithDependencies improvements
[ http://jira.codehaus.org/browse/MNG-1118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_88823 ] Jason van Zyl commented on MNG-1118: Ok, this is not really a problem with this method but with artifact resolution. You two have worked around this by creating new implementations of the resolver. > mavenEmbedder.readProjectWithDependencies improvements > -- > > Key: MNG-1118 > URL: http://jira.codehaus.org/browse/MNG-1118 > Project: Maven 2 > Issue Type: Improvement > Components: Embedding, POM >Reporter: Eugene Kuleshov > Assigned To: Jason van Zyl > Fix For: 2.0.x > > > Currently mavenEmbedder.readProjectWithDependencies return instance of > MavenProject. So, collection of artifacts in this instance (including > transient dependencies) does not have information where those artifacts had > been declared. It would be useful for an IDE to be able to get this > information somehow (e.g. getArtifactMap(), which could return map of > artifacts to list of pom files). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-1118) mavenEmbedder.readProjectWithDependencies improvements
[ http://jira.codehaus.org/browse/MNG-1118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-1118. -- Resolution: Fixed I'll create new issues that deal specifically with the internals. The project return, or any other information you IDE integrators are now capturing and we have to return those strategies to the default artifact resolvers. It should not fail fast but collect all the information it can which is what you have done. > mavenEmbedder.readProjectWithDependencies improvements > -- > > Key: MNG-1118 > URL: http://jira.codehaus.org/browse/MNG-1118 > Project: Maven 2 > Issue Type: Improvement > Components: Embedding, POM >Reporter: Eugene Kuleshov > Assigned To: Jason van Zyl > Fix For: 2.0.x > > > Currently mavenEmbedder.readProjectWithDependencies return instance of > MavenProject. So, collection of artifacts in this instance (including > transient dependencies) does not have information where those artifacts had > been declared. It would be useful for an IDE to be able to get this > information somehow (e.g. getArtifactMap(), which could return map of > artifacts to list of pom files). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2515) The Embedder does not work when started from a groovy script that is started from maven 2
[ http://jira.codehaus.org/browse/MNG-2515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_88825 ] Jason van Zyl commented on MNG-2515: So do you want to fork here? I have to experiment but I might be able to make an isolated classloader which doesn't conflict but we could easily fork from the 2.0.4 process. > The Embedder does not work when started from a groovy script that is started > from maven 2 > - > > Key: MNG-2515 > URL: http://jira.codehaus.org/browse/MNG-2515 > Project: Maven 2 > Issue Type: Bug > Components: Embedding >Affects Versions: 2.1 > Environment: Windows XP, JDK 1.5, Maven 2.0.4 >Reporter: Christian Domsch > Attachments: embedder-it-test.zip > > > The deploymentserver:changestage plugin starts a groovy script that again > starts a maven 2.1-SNAPSHOT embedder. This fails due to classloading issues > because the classloader for the groovy script contains a thread context > classloader a s a parent. This parent classloader contains all classes from > the maven 2.0.4 process that started the plugin. The embedder now fails to > start because the parent classloader contains conflicting classes from 2.0.4 > while the embedder is 2.1-SNAPSHOT. > The test case in the zip contains the source for the deploymentserver-mojo > and the projects that this mojo should operate on. To start the test, install > the mojo, and start maven in the productA project with "mvn > deploymentserver:changestage". For this to work the settings.xml must contain > > > innowake.lifecycle.deployment.engine.plugin > > The zip also contains the groovy jars to be copied in the local repository. > Greetings, > Christian. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-1106) Stdout in MavenEmbedder.readProjectWithDependencies() method
[ http://jira.codehaus.org/browse/MNG-1106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-1106. -- Resolution: Fixed By creating an embedder logger you should be able to capture everything. > Stdout in MavenEmbedder.readProjectWithDependencies() method > > > Key: MNG-1106 > URL: http://jira.codehaus.org/browse/MNG-1106 > Project: Maven 2 > Issue Type: Bug > Components: Embedding >Affects Versions: 2.0 >Reporter: Eugene Kuleshov > Assigned To: Jason van Zyl > Fix For: 2.0.x > > > MavenEmbedder.readProjectWithDependencies() method is is dumping the > following to stdout. > [WARNING] Unable to get resource from repository snapshots > (http://snapshots.maven.codehaus.org/maven2) > This is happening when ArtifactResolutionException is thrown: > org.apache.maven.artifact.resolver.ArtifactResolutionException: Unable to > download the artifact from any repository > org.apache.maven:maven-artifact-manager:2.0-beta-4-SNAPSHOT:jar > from the specified remote repositories: > snapshots (http://snapshots.maven.codehaus.org/maven2), > central (http://repo1.maven.org/maven2) > Path to dependency: > 1) org.apache.maven:maven-plugin-tools-java:jar:2.0-beta-4-SNAPSHOT > 2) org.apache.maven:maven-plugin-tools-api:jar:2.0-beta-4-SNAPSHOT > 3) org.apache.maven:maven-project:jar:2.0-beta-4-SNAPSHOT > 4) org.apache.maven:maven-artifact-manager:jar:2.0-beta-4-SNAPSHOT -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2827) java.lang.StringIndexOutOfBoundsException if embedded into Eclipse plugin and required plugin parameter is missing
[ http://jira.codehaus.org/browse/MNG-2827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_88827 ] Jason van Zyl commented on MNG-2827: I'm testing this now. > java.lang.StringIndexOutOfBoundsException if embedded into Eclipse plugin and > required plugin parameter is missing > -- > > Key: MNG-2827 > URL: http://jira.codehaus.org/browse/MNG-2827 > Project: Maven 2 > Issue Type: Bug > Components: Embedding >Affects Versions: 2.1.x >Reporter: Stepan Roh > > Problem is in > org.apache.maven.usability.plugin.ExpressionDocumenter.initializeDocLoader() > which does some file-based magic tricks, but that does not work if Maven is > embedded into Eclipse plugin (where resources have "bundle" scheme and not > "file" and more importantly their path is different). > Test case: > - execute goal "jar:sign" on some basic pom.xml by using > MavenEmbedder.execute() > - proper behaviour is to throw MavenExecutionException where it says that > required parameter "alias" is missing > - but when executed from Eclipse (as part of some Eclipse plugin) it throws > (line numbers may vary): > Caused by: java.lang.StringIndexOutOfBoundsException: String index out of > range: -1 >at java.lang.String.substring(String.java:1444) >at > org.apache.maven.usability.plugin.ExpressionDocumenter.initializeDocLoader(ExpressionDocumenter.java:148) >at > org.apache.maven.usability.plugin.ExpressionDocumenter.load(ExpressionDocumenter.java:53) >at > org.apache.maven.plugin.PluginConfigurationException.addParameterUsageInfo(PluginConfigurationException.java:107) >at > org.apache.maven.plugin.PluginConfigurationException.buildConfigurationDiagnosticMessage(PluginConfigurationException.java:274) >at > org.apache.maven.usability.PluginConfigurationDiagnoser.diagnose(PluginConfigurationDiagnoser.java:49) >at > org.apache.maven.usability.diagnostics.ErrorDiagnostics.diagnose(ErrorDiagnostics.java:81) >at org.apache.maven.DefaultMaven.logDiagnostics(DefaultMaven.java:774) >at org.apache.maven.DefaultMaven.logError(DefaultMaven.java:728) >at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:188) >at org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:746) > The problematic line is: > myClasspathEntry = myClasspathEntry.substring( 0, > myClasspathEntry.length() - ( myResourcePath.length() + 2 ) ); > I replaced the initializeDocLoader()'s body with > return ExpressionDocumenter.class.getClassLoader(); > ... which works both inside and outside of Eclipse, but I tested it only on > embedder and do not know it's impact on CLI version. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-2827) java.lang.StringIndexOutOfBoundsException if embedded into Eclipse plugin and required plugin parameter is missing
[ http://jira.codehaus.org/browse/MNG-2827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-2827. -- Resolution: Fixed Patch applied and tested. Thanks. > java.lang.StringIndexOutOfBoundsException if embedded into Eclipse plugin and > required plugin parameter is missing > -- > > Key: MNG-2827 > URL: http://jira.codehaus.org/browse/MNG-2827 > Project: Maven 2 > Issue Type: Bug > Components: Embedding >Affects Versions: 2.1.x >Reporter: Stepan Roh > Assigned To: Jason van Zyl > > Problem is in > org.apache.maven.usability.plugin.ExpressionDocumenter.initializeDocLoader() > which does some file-based magic tricks, but that does not work if Maven is > embedded into Eclipse plugin (where resources have "bundle" scheme and not > "file" and more importantly their path is different). > Test case: > - execute goal "jar:sign" on some basic pom.xml by using > MavenEmbedder.execute() > - proper behaviour is to throw MavenExecutionException where it says that > required parameter "alias" is missing > - but when executed from Eclipse (as part of some Eclipse plugin) it throws > (line numbers may vary): > Caused by: java.lang.StringIndexOutOfBoundsException: String index out of > range: -1 >at java.lang.String.substring(String.java:1444) >at > org.apache.maven.usability.plugin.ExpressionDocumenter.initializeDocLoader(ExpressionDocumenter.java:148) >at > org.apache.maven.usability.plugin.ExpressionDocumenter.load(ExpressionDocumenter.java:53) >at > org.apache.maven.plugin.PluginConfigurationException.addParameterUsageInfo(PluginConfigurationException.java:107) >at > org.apache.maven.plugin.PluginConfigurationException.buildConfigurationDiagnosticMessage(PluginConfigurationException.java:274) >at > org.apache.maven.usability.PluginConfigurationDiagnoser.diagnose(PluginConfigurationDiagnoser.java:49) >at > org.apache.maven.usability.diagnostics.ErrorDiagnostics.diagnose(ErrorDiagnostics.java:81) >at org.apache.maven.DefaultMaven.logDiagnostics(DefaultMaven.java:774) >at org.apache.maven.DefaultMaven.logError(DefaultMaven.java:728) >at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:188) >at org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:746) > The problematic line is: > myClasspathEntry = myClasspathEntry.substring( 0, > myClasspathEntry.length() - ( myResourcePath.length() + 2 ) ); > I replaced the initializeDocLoader()'s body with > return ExpressionDocumenter.class.getClassLoader(); > ... which works both inside and outside of Eclipse, but I tested it only on > embedder and do not know it's impact on CLI version. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-1988) Provide support for repo manager indexer/search API
[ http://jira.codehaus.org/browse/MNG-1988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-1988. -- Resolution: Fixed Preliminary support added with Gatekeeper and is really part of IDE integratino which will happen over at Mevenide. > Provide support for repo manager indexer/search API > --- > > Key: MNG-1988 > URL: http://jira.codehaus.org/browse/MNG-1988 > Project: Maven 2 > Issue Type: New Feature > Components: Embedding >Affects Versions: 2.0.2 >Reporter: Eugene Kuleshov > Assigned To: Jason van Zyl > Fix For: 2.0.x > > > In IDE plugin we need to be able to search repository index, reindex local > repository and download/update indexes from the remote repositories. See > http://docs.codehaus.org/display/MAVEN/Repository+Manager > This is a common task, so embedder should provide this API, unless repository > manger will provide a embeddeble indexer/searcher component. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-2791) Error parsing Maven 1 POM file with an extend tag
[ http://jira.codehaus.org/browse/MNG-2791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_88830 ] Jason van Zyl commented on MNG-2791: How are you getting an m1 POM in the mix for an m2 project. You need to give me more information and the repo where this POM came from. > Error parsing Maven 1 POM file with an extend tag > - > > Key: MNG-2791 > URL: http://jira.codehaus.org/browse/MNG-2791 > Project: Maven 2 > Issue Type: Bug > Components: Embedding >Affects Versions: 2.1.x > Environment: Maven 2 Eclipse plugin 0.0.10 (latest from SVN) using > the following jars: > lucene-core-2.0.0.jar > maven-embedder-2.1.0.v20070110-2115-dep.jar > Eclipse 3.2 Session Data: > eclipse.buildId=M20060921-0945 > java.version=1.6.0 > java.vendor=Sun Microsystems Inc. > BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=es_ES > Command-line arguments: -os win32 -ws win32 -arch x86 -data c:\workspace > -clean >Reporter: Rodrigo Ruiz > > Trying to rebuild a project that depends on an artifact obtained from a > Maven1 repository, I get the following stacktrace: > org.eclipse.core.runtime.CoreException: Parsing error [whatever].pom; > org.codehaus.plexus.util.xml.pull.XmlPullParserException: Unrecognised tag: > 'extend' (position: START_TAG seen ...\n ... @4:11) > at > org.maven.ide.eclipse.embedder.MavenModelManager.readMavenModel(MavenModelManager.java:137) > at > org.maven.ide.eclipse.embedder.ClassPathResolver.getJavaDocUrl(ClassPathResolver.java:241) > at > org.maven.ide.eclipse.embedder.ClassPathResolver.resolveClasspathEntries(ClassPathResolver.java:154) > at > org.maven.ide.eclipse.builder.Maven2Builder.updateClasspath(Maven2Builder.java:95) > at > org.maven.ide.eclipse.builder.Maven2Builder.build(Maven2Builder.java:86) > at > org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:603) > at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) > at > org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:167) > at > org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:201) > at > org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:230) > at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) > at > org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:233) > at > org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:252) > at > org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:285) > at > org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:145) > at > org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:208) > at org.eclipse.core.internal.jobs.Worker.run(Worker.java:58) > org.eclipse.core.runtime.CoreException[4]: > org.codehaus.plexus.util.xml.pull.XmlPullParserException: Unrecognised tag: > 'extend' (position: START_TAG seen ...\n ... @4:11) > at > org.apache.maven.model.io.xpp3.MavenXpp3Reader.parseModel(MavenXpp3Reader.java:2405) > at > org.apache.maven.model.io.xpp3.MavenXpp3Reader.read(MavenXpp3Reader.java:4438) > at > org.apache.maven.model.io.xpp3.MavenXpp3Reader.read(MavenXpp3Reader.java:4449) > at > org.apache.maven.embedder.MavenEmbedder.readModel(MavenEmbedder.java:208) > at > org.maven.ide.eclipse.embedder.MavenModelManager.readMavenModel(MavenModelManager.java:133) > at > org.maven.ide.eclipse.embedder.ClassPathResolver.getJavaDocUrl(ClassPathResolver.java:241) > at > org.maven.ide.eclipse.embedder.ClassPathResolver.resolveClasspathEntries(ClassPathResolver.java:154) > at > org.maven.ide.eclipse.builder.Maven2Builder.updateClasspath(Maven2Builder.java:95) > at > org.maven.ide.eclipse.builder.Maven2Builder.build(Maven2Builder.java:86) > at > org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:603) > at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) > at > org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:167) > at > org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:201) > at > org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:230) > at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) > at > org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:233) > at > org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:252) > at > org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:285) > at > org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:145) > at
[jira] Closed: (MNG-2483) Review caching strategies throughout Maven for long-lived processes
[ http://jira.codehaus.org/browse/MNG-2483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-2483. -- Resolution: Fixed We have taken care of the case in maven-project. Each instance where we are doing this requires a new issue. > Review caching strategies throughout Maven for long-lived processes > --- > > Key: MNG-2483 > URL: http://jira.codehaus.org/browse/MNG-2483 > Project: Maven 2 > Issue Type: Improvement > Components: Ant tasks, Artifacts, Artifacts and Repositories, > Dependencies, Deployment, Embedding, General, Inheritance and Interpolation, > Logging, maven-archiver, Performance, Plugin API, Plugin Creation Tools, > Plugin Requests, Plugins and Lifecycle, Reactor and workspace, Repositories, > Settings, Sites & Reporting >Affects Versions: 2.0.4, 2.0.5 >Reporter: John Casey > Assigned To: Jason van Zyl >Priority: Critical > Fix For: 2.1.x > > > We need to revisit all instances where Maps, etc. are used to cache data > inside Maven (maven-artifact has some, as does maven-project, f.e.). Wherever > caching is used, we need to apply some sort of aging and/or size-limiting > implementation to keep Maven from chewing up massive amounts of memory in > long-lived processes, such as IDE extensions. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MJAR-7) jar plugin recreates jar files all the time
[
http://jira.codehaus.org/browse/MJAR-7?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_88834
]
Andy DePue commented on MJAR-7:
---
It looks like this fix is scheduled for 2.1, but I'm curious if the fix
addresses an issue I'm seeing? I'm currently using 2.0.5, and it looks like
Maven is actually doing an "up to date" check between the .jar and the sources,
but it always fails because pom.properties is a source file that gets included
in the .jar, and since Maven always regenerates pom.properties with each build,
it is always newer than the .jar. If I force maven NOT to include
pom.properties in the resulting .jar, then Maven will actually work correctly:
it won't rebuild the .jar until something changes. BTW, I'm turning off the
inclusion of pom.properties via this config:
{code:xml}
maven-jar-plugin
false
{code}
> jar plugin recreates jar files all the time
> ---
>
> Key: MJAR-7
> URL: http://jira.codehaus.org/browse/MJAR-7
> Project: Maven 2.x Jar Plugin
> Issue Type: Bug
>Reporter: Jochen Wiedmann
> Assigned To: Jason van Zyl
> Fix For: 2.1
>
> Attachments: maven-archiver-20060821-2.patch,
> maven-archiver-20060821.patch, maven-jar-plugin-20060821.patch,
> plexus-archiver-up2date.patch
>
>
> The jar plugin doesn't seem to check, whether rebuilding a jar file is
> actually required. For daily work, it would be faster to do what Ant's "jar"
> task does: Compare the timestamps of the input files with the timestamp of
> the target file.
> While this approach has the obvious advantage of being safe (and thus
> possibly well choosen as a default), it is not appropriate for large
> projects, where a single build requires a real lot of jar files being
> rebuilt, even if only a single source file has been changed. This applies, in
> particular, because comparable plugins like the war, ear, and assembly plugin
> are forced to behave in the same manner.
> Suggestion:
> - Introduce a new property, for example "maven.build.force". The main idea of
> the property would
> be, that other plugins (install, war, assembly, ...) would listen to the
> same property. While they
> would possible ignore it initially, one could add support later on.
> - The default property value would be true.
> - If the property value is set to false, then the jar plugin compares the
> timestamps of the input files with
> the timestamp of the output file. If the latter is newer than the input
> timestamps, then the jar file isn't
> being rebuilt.
> I am ready to provide a patch, if my suggestion should find interest.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly 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-2483) Review caching strategies throughout Maven for long-lived processes
[ http://jira.codehaus.org/browse/MNG-2483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_88836 ] Milos Kleint commented on MNG-2483: --- what about maven-artifact that john mentions? > Review caching strategies throughout Maven for long-lived processes > --- > > Key: MNG-2483 > URL: http://jira.codehaus.org/browse/MNG-2483 > Project: Maven 2 > Issue Type: Improvement > Components: Ant tasks, Artifacts, Artifacts and Repositories, > Dependencies, Deployment, Embedding, General, Inheritance and Interpolation, > Logging, maven-archiver, Performance, Plugin API, Plugin Creation Tools, > Plugin Requests, Plugins and Lifecycle, Reactor and workspace, Repositories, > Settings, Sites & Reporting >Affects Versions: 2.0.4, 2.0.5 >Reporter: John Casey > Assigned To: Jason van Zyl >Priority: Critical > Fix For: 2.1.x > > > We need to revisit all instances where Maps, etc. are used to cache data > inside Maven (maven-artifact has some, as does maven-project, f.e.). Wherever > caching is used, we need to apply some sort of aging and/or size-limiting > implementation to keep Maven from chewing up massive amounts of memory in > long-lived processes, such as IDE extensions. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-2835) The localRepository settings from the global settings file are ignored
[ http://jira.codehaus.org/browse/MNG-2835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-2835. -- Resolution: Fixed Fixed and tested: http://svn.apache.org/repos/asf/maven/components/trunk/maven-embedder/src/test/java/org/apache/maven/embedder/MavenEmbedderBehaviorTest.java > The localRepository settings from the global settings file are ignored > -- > > Key: MNG-2835 > URL: http://jira.codehaus.org/browse/MNG-2835 > Project: Maven 2 > Issue Type: Bug > Components: Embedding >Affects Versions: 2.1 >Reporter: Aaron Digulla > Assigned To: Jason van Zyl > > With the latest embedder (20070219), the localRepository is only taken into > account when it's specified in the user settings. When it is only in the > global settings file, it's ignored. > I think the problem is that not all settings are copied when > request = defaultsPopulator.populateDefaults( request ); > is called. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-2051) Failure to inject ScmManager component
[ http://jira.codehaus.org/browse/MNG-2051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-2051. -- Resolution: Fixed The SCM plugin appears to work just fine: http://svn.apache.org/repos/asf/maven/components/trunk/maven-embedder/src/test/java/org/apache/maven/embedder/EmbedderUsingScmPluginTest.java > Failure to inject ScmManager component > -- > > Key: MNG-2051 > URL: http://jira.codehaus.org/browse/MNG-2051 > Project: Maven 2 > Issue Type: Bug > Components: Embedding >Reporter: Michael Böckling > Assigned To: Jason van Zyl > Fix For: 2.1.x > > > When using the embedder, the component > "org.apache.maven.scm.manager.ScmManager" can not be injected (for what > reason ever). It works when using the commandline. > My field declaration: > /** >* Plexus injected component. >* >* @component >*/ > private ScmManager scmManager; > Stacktrace: > Exception in thread "main" > org.apache.maven.lifecycle.LifecycleExecutionException: Internal error in the > plugin manager executing goal > 'com.giniality:maven-scm-transfer-plugin:0.9-SNAPSHOT:transfer': Unable to > find the mojo 'com.giniality:maven-scm-transfer-plugin:0.9-SNAPSHOT:transfer' > in the plugin 'com.giniality:maven-scm-transfer-plugin' > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:535) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:485) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:455) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.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.embedder.MavenEmbedder.execute(MavenEmbedder.java:472) > at > org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:413) > at com.giniality.EmbeddedRunner.testProject(EmbeddedRunner.java:81) > at com.giniality.EmbeddedRunner.main(EmbeddedRunner.java:99) > Caused by: org.apache.maven.plugin.PluginManagerException: Unable to find the > mojo 'com.giniality:maven-scm-transfer-plugin:0.9-SNAPSHOT:transfer' in the > plugin 'com.giniality:maven-scm-transfer-plugin' > at > org.apache.maven.plugin.DefaultPluginManager.getConfiguredMojo(DefaultPluginManager.java:536) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:393) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:531) > ... 9 more > Caused by: > org.codehaus.plexus.component.repository.exception.ComponentLookupException: > Unable to lookup component > 'org.apache.maven.plugin.Mojocom.giniality:maven-scm-transfer-plugin:0.9-SNAPSHOT:transfer', > it could not be started > at > org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:339) > at > org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:440) > at > org.apache.maven.plugin.DefaultPluginManager.getConfiguredMojo(DefaultPluginManager.java:527) > ... 11 more > Caused by: > org.codehaus.plexus.component.repository.exception.ComponentLifecycleException: > Error starting component > at > org.codehaus.plexus.component.manager.AbstractComponentManager.startComponentLifecycle(AbstractComponentManager.java:109) > at > org.codehaus.plexus.component.manager.AbstractComponentManager.createComponentInstance(AbstractComponentManager.java:95) > at > org.codehaus.plexus.component.manager.PerLookupComponentManager.getComponent(PerLookupComponentManager.java:48) > at > org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:331) > ... 13 more > Caused by: > org.codehaus.plexus.personality.plexus.lifecycle.phase.PhaseExecutionException: > Error composing component > at > org.codehaus.plexus.personality.plexus.lifecycle.phase.CompositionPhase.execute(CompositionPhase.java:33) > at > org.codehaus.plexus.lifecycle.AbstractLifecycleHandler.start(AbstractLifecycleHandler.java:101) > at > org.codehaus.plexus.component.manager.AbstractComponentManager.startComponentLifecycle(AbstractComponentManager.java:105) > ... 16 more > Caused by: org.codehaus.plexus.component.composition.CompositionException: > Composition failed for the field scmManager in object of type > com.giniality.TransferMojo > at > org.codehaus.plexus.component.composition.FieldComponentCompos
[jira] Commented: (MNG-1118) mavenEmbedder.readProjectWithDependencies improvements
[ http://jira.codehaus.org/browse/MNG-1118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_88848 ] Dan Rollo commented on MNG-1118: Could you link the new Jira issue to this one so I can track it? > mavenEmbedder.readProjectWithDependencies improvements > -- > > Key: MNG-1118 > URL: http://jira.codehaus.org/browse/MNG-1118 > Project: Maven 2 > Issue Type: Improvement > Components: Embedding, POM >Reporter: Eugene Kuleshov > Assigned To: Jason van Zyl > Fix For: 2.0.x > > > Currently mavenEmbedder.readProjectWithDependencies return instance of > MavenProject. So, collection of artifacts in this instance (including > transient dependencies) does not have information where those artifacts had > been declared. It would be useful for an IDE to be able to get this > information somehow (e.g. getArtifactMap(), which could return map of > artifacts to list of pom files). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-2829) PlexusLoggerAdapter.error(String, Throwable) ignores Throwable
[ http://jira.codehaus.org/browse/MNG-2829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-2829. -- Resolution: Fixed Patch applied, thanks. > PlexusLoggerAdapter.error(String, Throwable) ignores Throwable > -- > > Key: MNG-2829 > URL: http://jira.codehaus.org/browse/MNG-2829 > Project: Maven 2 > Issue Type: Bug > Components: Embedding >Affects Versions: 2.1.x >Reporter: Stepan Roh > Assigned To: Jason van Zyl > Attachments: log_error_exception.patch > > > See attached 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-2483) Review caching strategies throughout Maven for long-lived processes
[ http://jira.codehaus.org/browse/MNG-2483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_88845 ] Jason van Zyl commented on MNG-2483: As I mentioned we should make issues for each system involved. I can do that. > Review caching strategies throughout Maven for long-lived processes > --- > > Key: MNG-2483 > URL: http://jira.codehaus.org/browse/MNG-2483 > Project: Maven 2 > Issue Type: Improvement > Components: Ant tasks, Artifacts, Artifacts and Repositories, > Dependencies, Deployment, Embedding, General, Inheritance and Interpolation, > Logging, maven-archiver, Performance, Plugin API, Plugin Creation Tools, > Plugin Requests, Plugins and Lifecycle, Reactor and workspace, Repositories, > Settings, Sites & Reporting >Affects Versions: 2.0.4, 2.0.5 >Reporter: John Casey > Assigned To: Jason van Zyl >Priority: Critical > Fix For: 2.1.x > > > We need to revisit all instances where Maps, etc. are used to cache data > inside Maven (maven-artifact has some, as does maven-project, f.e.). Wherever > caching is used, we need to apply some sort of aging and/or size-limiting > implementation to keep Maven from chewing up massive amounts of memory in > long-lived processes, such as IDE extensions. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-2723) Push all configuration models into the MavenExecutionRequest
[ http://jira.codehaus.org/browse/MNG-2723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-2723. -- Resolution: Fixed All this has been done between the configuration and execution request for the embedder. > Push all configuration models into the MavenExecutionRequest > > > Key: MNG-2723 > URL: http://jira.codehaus.org/browse/MNG-2723 > Project: Maven 2 > Issue Type: Task > Components: Embedding >Reporter: Jason van Zyl > Assigned To: Jason van Zyl > > Currently we have Settings, Session, RuntimeInfo and they all have pieces > that Maven requires to operate which is confusing. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-2051) Failure to inject ScmManager component
[ http://jira.codehaus.org/browse/MNG-2051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_88847 ] Jason van Zyl commented on MNG-2051: Can you give me a sample project that I can use to reproduce the problem? > Failure to inject ScmManager component > -- > > Key: MNG-2051 > URL: http://jira.codehaus.org/browse/MNG-2051 > Project: Maven 2 > Issue Type: Bug > Components: Embedding >Reporter: Michael Böckling > Fix For: 2.1.x > > > When using the embedder, the component > "org.apache.maven.scm.manager.ScmManager" can not be injected (for what > reason ever). It works when using the commandline. > My field declaration: > /** >* Plexus injected component. >* >* @component >*/ > private ScmManager scmManager; > Stacktrace: > Exception in thread "main" > org.apache.maven.lifecycle.LifecycleExecutionException: Internal error in the > plugin manager executing goal > 'com.giniality:maven-scm-transfer-plugin:0.9-SNAPSHOT:transfer': Unable to > find the mojo 'com.giniality:maven-scm-transfer-plugin:0.9-SNAPSHOT:transfer' > in the plugin 'com.giniality:maven-scm-transfer-plugin' > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:535) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:485) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:455) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.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.embedder.MavenEmbedder.execute(MavenEmbedder.java:472) > at > org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:413) > at com.giniality.EmbeddedRunner.testProject(EmbeddedRunner.java:81) > at com.giniality.EmbeddedRunner.main(EmbeddedRunner.java:99) > Caused by: org.apache.maven.plugin.PluginManagerException: Unable to find the > mojo 'com.giniality:maven-scm-transfer-plugin:0.9-SNAPSHOT:transfer' in the > plugin 'com.giniality:maven-scm-transfer-plugin' > at > org.apache.maven.plugin.DefaultPluginManager.getConfiguredMojo(DefaultPluginManager.java:536) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:393) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:531) > ... 9 more > Caused by: > org.codehaus.plexus.component.repository.exception.ComponentLookupException: > Unable to lookup component > 'org.apache.maven.plugin.Mojocom.giniality:maven-scm-transfer-plugin:0.9-SNAPSHOT:transfer', > it could not be started > at > org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:339) > at > org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:440) > at > org.apache.maven.plugin.DefaultPluginManager.getConfiguredMojo(DefaultPluginManager.java:527) > ... 11 more > Caused by: > org.codehaus.plexus.component.repository.exception.ComponentLifecycleException: > Error starting component > at > org.codehaus.plexus.component.manager.AbstractComponentManager.startComponentLifecycle(AbstractComponentManager.java:109) > at > org.codehaus.plexus.component.manager.AbstractComponentManager.createComponentInstance(AbstractComponentManager.java:95) > at > org.codehaus.plexus.component.manager.PerLookupComponentManager.getComponent(PerLookupComponentManager.java:48) > at > org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:331) > ... 13 more > Caused by: > org.codehaus.plexus.personality.plexus.lifecycle.phase.PhaseExecutionException: > Error composing component > at > org.codehaus.plexus.personality.plexus.lifecycle.phase.CompositionPhase.execute(CompositionPhase.java:33) > at > org.codehaus.plexus.lifecycle.AbstractLifecycleHandler.start(AbstractLifecycleHandler.java:101) > at > org.codehaus.plexus.component.manager.AbstractComponentManager.startComponentLifecycle(AbstractComponentManager.java:105) > ... 16 more > Caused by: org.codehaus.plexus.component.composition.CompositionException: > Composition failed for the field scmManager in object of type > com.giniality.TransferMojo > at > org.codehaus.plexus.component.composition.FieldComponentComposer.assignRequirementToField(FieldComponentComposer.java:144) > at > org.codehaus.plexus.component.composition.FieldComponentComposer.as
[jira] Closed: (MNG-2778) Allow access to the underlying plexus container from MavenEmbedder
[
http://jira.codehaus.org/browse/MNG-2778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl closed MNG-2778.
--
Resolution: Fixed
At the bottom of this examples class:
http://svn.apache.org/repos/asf/maven/components/trunk/maven-embedder/src/test/java/org/apache/maven/embedder/MavenEmbedderExampleTest.java
> Allow access to the underlying plexus container from MavenEmbedder
> --
>
> Key: MNG-2778
> URL: http://jira.codehaus.org/browse/MNG-2778
> Project: Maven 2
> Issue Type: Improvement
> Components: Embedding
>Affects Versions: 2.0.4
>Reporter: Kohsuke Kawaguchi
> Assigned To: Jason van Zyl
>
> When embedding Maven into applications, it's often convenient to be able to
> look up components inside Maven from the applications.
> This can be easily be done if MavenEmbedder lets me access PlexusContainer,
> like this:
> /**
> * Gets the [EMAIL PROTECTED] PlexusContainer} that hosts Maven.
> */
> public PlexusContainer getContainer() {
> return embedder.getContainer();
> }
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly 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-1398) Upload fastutil:fastutil:jar:5.0.7 to ibiblio
Upload fastutil:fastutil:jar:5.0.7 to ibiblio - Key: MAVENUPLOAD-1398 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1398 Project: maven-upload-requests Issue Type: Task Reporter: Matt Whitlock http://www.mattwhitlock.com/fastutil-5.0.7-bundle.jar http://fastutil.dsi.unimi.it/ fastutil extends the Java Collections Framework by providing type-specific maps, sets, lists and queues with a small memory footprint and fast access and insertion; it also includes a fast I/O API for binary and text files. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MEV-505) xml-resolver source jar is named wrong
xml-resolver source jar is named wrong -- Key: MEV-505 URL: http://jira.codehaus.org/browse/MEV-505 Project: Maven Evangelism Issue Type: Bug Reporter: Daniel Kulp The xml-resolver-1.2-source.jarshould be renamed to xml-resolver-1.2-sources.jar so eclipse:eclipse and idea can find it and download it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MWAR-92) Bad xml in sample documentation on website
[ http://jira.codehaus.org/browse/MWAR-92?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MWAR-92. --- Assignee: Dennis Lundberg Resolution: Fixed Fix Version/s: 2.1 Fixed in SVN. > Bad xml in sample documentation on website > -- > > Key: MWAR-92 > URL: http://jira.codehaus.org/browse/MWAR-92 > Project: Maven 2.x War Plugin > Issue Type: Bug >Reporter: Harold Shinsato > Assigned To: Dennis Lundberg >Priority: Minor > Fix For: 2.1 > > > The online documentation at > http://maven.apache.org/plugins/maven-war-plugin/examples/war-manifest-guide.html > contains a snippet of xml, the first example box has the following. > > value > > The final tag should have been to properly close it > and make it well formed xml, otherwise this snippet won't work. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MDEPLOY-51) Allow username and password to be specified on the command line
Allow username and password to be specified on the command line --- Key: MDEPLOY-51 URL: http://jira.codehaus.org/browse/MDEPLOY-51 Project: Maven 2.x Deploy Plugin Issue Type: Improvement Reporter: Paul Gier Allow the user to supply a user name password for a remote server when the deploy goal is called. Currently you have to add the repository username and password to the server.xml file. It would be helpful if the user could be prompted for a username and password on the command line. The password should be hidden when it is entered. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MAVEN-1833) Site plugin strips leading slash in urls
[ http://jira.codehaus.org/browse/MAVEN-1833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl closed MAVEN-1833. Assignee: Lukas Theussl Resolution: Won't Fix This is the intended behaviour: http://maven.apache.org/maven-1.x/using/site.html > Site plugin strips leading slash in urls > > > Key: MAVEN-1833 > URL: http://jira.codehaus.org/browse/MAVEN-1833 > Project: Maven 1.x > Issue Type: Bug >Affects Versions: 1.1-beta-2 > Environment: Linux, Sun java 1.4 >Reporter: Tim Pizey > Assigned To: Lukas Theussl > > A link in navigation.xml with href='/index.html' does not create a link to > server homepage but to current directory. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (WAGON-74) WebDav component references non-existant jetty pom and fails to install into maven when building.
WebDav component references non-existant jetty pom and fails to install into maven when building. - Key: WAGON-74 URL: http://jira.codehaus.org/browse/WAGON-74 Project: wagon Issue Type: Bug Components: wagon-webdav Affects Versions: 1.0-beta-2 Environment: Maven 2.0.5 Reporter: Derek Clarkson Priority: Blocker When attempt to deploy using the webdav to a local Archiva repository I get the message: Protocol [dav] is unsupported by the current configuration. Turning on debug I see at the top of the log: [DEBUG] Artifact not found - using stub model: Unable to download the artifact from any repository org.mortbay.jetty:jetty:pom:4.2.12 from the specified remote repositories: central (http://repo1.maven.org/maven2), aegeon-proxy (http://192.168.0.91:/proxy/aegeon) Looking inside the repo1.maven.org/maven2 repository I can see that the directory exists for jetty 4.2.12 but there is no pom in it. My build pom makes reference to the following extension: org.apache.maven.wagon wagon-webdav 1.0-beta-2 Please suggest a fix as this is blocking our development because we cannot deploy to our local Archiva server. ciao Derek -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MECLIPSE-234) [PATCH] EclipsePlugin.extractResourceDirs() reuses String method argument causing maven-eclipse.xml copy-resources problems
[PATCH] EclipsePlugin.extractResourceDirs() reuses String method argument
causing maven-eclipse.xml copy-resources problems
---
Key: MECLIPSE-234
URL: http://jira.codehaus.org/browse/MECLIPSE-234
Project: Maven 2.x Eclipse Plugin
Issue Type: Bug
Affects Versions: 2.3
Environment: Win2000
mvn 2.0.5
Reporter: Peter Lynch
Priority: Critical
Attachments: EclipsePlugin.patch
I have a pom which defines multiple resources. Each resource is in it's own
directory. Upon executing mvn eclipse:eclipse the maven-eclipse.xml that is
generated contains todir attribute values that concantenates pom.xml targetPath
values together in one long path. Further to this problem is the eclipse plugin
tries to mkdir this long path. On windows this can be extremely bad as in my
case it resulted in a path under target/classes that exceeded 256 chars long
and about 50 dir levels deep.(this became impossible to delete on Windows
without some magic renaming of each dir to '1' and using network shares...fun
stuff).
Anyways it boils down to some buggy reuse of method arguments in the
extractResourceDirs method. The output argument which is a string is reused in
such a way as to cause the concantenation. I simply defined a local String to
work around the problem.
Notice the patch also contains another fix in same method. One of the test
cases was passing an absolute path based output dir. Since there is no javadoc
I took a best guess to fix this bug. Maybe this was only a problem on windows.
See this part if you don't like it
{noformat}
// sometimes thisOutput is already an absolute path
File outputFile = new File( thisOutput );
if(!outputFile.isAbsolute()){
outputFile = new File( workspaceProjectBaseDir, thisOutput
);
}
{noformat}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly 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-292) [archiva-common] Fix BaseFileTest, so it will run on Windows
[ http://jira.codehaus.org/browse/MRM-292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed MRM-292. Assignee: Emmanuel Venisse Resolution: Fixed Fix Version/s: 1.0 already fixed but with an other patch > [archiva-common] Fix BaseFileTest, so it will run on Windows > > > Key: MRM-292 > URL: http://jira.codehaus.org/browse/MRM-292 > Project: Archiva > Issue Type: Bug >Affects Versions: 1.0 > Environment: Windows XP SP2, Sun JDK 5 Update 11, Maven 2.0.5 >Reporter: Nathan Beyer (Apache) > Assigned To: Emmanuel Venisse > Fix For: 1.0 > > Attachments: BaseFileTest.diff, BaseFileTest.diff > > > The test org.apache.maven.archiva.common.utils.BaseFileTest won't pass on > Windows platform, because it doesn't compensate for drive letters being > adding to the absolute paths. I've added some simple utility methods and > tweaked the expected values to compensate for this. I don't have a Linux box > to test on, so I haven't validated that they still work there, so the > committer should verify the tests on a Linux or Unix box. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
