[jira] Work started: (MRM-456) current configuration code is too likely to complain about multiple sources
[
http://jira.codehaus.org/browse/MRM-456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on MRM-456 started by Brett Porter.
current configuration code is too likely to complain about multiple sources
---
Key: MRM-456
URL: http://jira.codehaus.org/browse/MRM-456
Project: Archiva
Issue Type: Bug
Affects Versions: 1.0-beta-1
Reporter: Brett Porter
Assignee: Brett Porter
Fix For: 1.0-beta-2
those with alpha-1 are likely to have config in ~/.m2/archiva.xml.
But the default is to distribute and work with
${appserver.base}/conf/archiva.xml
This will complain whenever saving by default. I need to review the best
distribution situation.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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-456) current configuration code is too likely to complain about multiple sources
[
http://jira.codehaus.org/browse/MRM-456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter closed MRM-456.
Resolution: Fixed
current configuration code is too likely to complain about multiple sources
---
Key: MRM-456
URL: http://jira.codehaus.org/browse/MRM-456
Project: Archiva
Issue Type: Bug
Affects Versions: 1.0-beta-1
Reporter: Brett Porter
Assignee: Brett Porter
Fix For: 1.0-beta-2
those with alpha-1 are likely to have config in ~/.m2/archiva.xml.
But the default is to distribute and work with
${appserver.base}/conf/archiva.xml
This will complain whenever saving by default. I need to review the best
distribution situation.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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-316) RadCleanMojo does not clean .war files
RadCleanMojo does not clean .war files -- Key: MECLIPSE-316 URL: http://jira.codehaus.org/browse/MECLIPSE-316 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Components: RAD support Affects Versions: 2.4 Reporter: Siarhei Dudzin Fix For: 2.5 RadCleanMojo only cleans jars in deleteJarArtifactsInDirectory() while RadLibCopier also copies .war files in RadLibCopier.copyArtifact( IdeDependency[] deps, File destDir ). RadCleanMojo also needs to clean .war 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: (CONTINUUM-1379) Documentation Configuration Continuum ClearCase Maven 2
Documentation Configuration Continuum ClearCase Maven 2 --- Key: CONTINUUM-1379 URL: http://jira.codehaus.org/browse/CONTINUUM-1379 Project: Continuum Issue Type: New Feature Components: Documentation Environment: Windows XP, Maven 2.0.7, Continuum 1.1-beta-1 Reporter: Xavier Marc Attachments: Configuration Continuum Anglais.doc You can find in attachment the documentation about the configuration of the continuous integration server Continuum with ClearCase and Maven 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] Updated: (CONTINUUM-1379) Documentation Configuration Continuum ClearCase Maven 2
[ http://jira.codehaus.org/browse/CONTINUUM-1379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse updated CONTINUUM-1379: Fix Version/s: 1.1 Documentation Configuration Continuum ClearCase Maven 2 --- Key: CONTINUUM-1379 URL: http://jira.codehaus.org/browse/CONTINUUM-1379 Project: Continuum Issue Type: New Feature Components: Documentation Environment: Windows XP, Maven 2.0.7, Continuum 1.1-beta-1 Reporter: Xavier Marc Fix For: 1.1 Attachments: Configuration Continuum Anglais.doc You can find in attachment the documentation about the configuration of the continuous integration server Continuum with ClearCase and Maven 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] Commented: (CONTINUUM-1379) Documentation Configuration Continuum ClearCase Maven 2
[ http://jira.codehaus.org/browse/CONTINUUM-1379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_104393 ] Emmanuel Venisse commented on CONTINUUM-1379: - Thanks xavier. Your doc seems to be good. We don't use Word document for our documentation but we'll use the content (probably with some refactoring) when we'll refactor the site content Documentation Configuration Continuum ClearCase Maven 2 --- Key: CONTINUUM-1379 URL: http://jira.codehaus.org/browse/CONTINUUM-1379 Project: Continuum Issue Type: New Feature Components: Documentation Environment: Windows XP, Maven 2.0.7, Continuum 1.1-beta-1 Reporter: Xavier Marc Fix For: 1.1 Attachments: Configuration Continuum Anglais.doc You can find in attachment the documentation about the configuration of the continuous integration server Continuum with ClearCase and Maven 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] Closed: (DOXIA-133) default XML encoding (UTF-8) or XML encoding set in XML files is ignored: inputEncoding is used instead
[
http://jira.codehaus.org/browse/DOXIA-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vincent Siveton closed DOXIA-133.
-
Assignee: Vincent Siveton
Resolution: Fixed
Patch applied with modifications discussed there.
Thanks again Herve.
default XML encoding (UTF-8) or XML encoding set in XML files is ignored:
inputEncoding is used instead
---
Key: DOXIA-133
URL: http://jira.codehaus.org/browse/DOXIA-133
Project: Maven Doxia
Issue Type: Bug
Components: Core, Module - Docbook Simple, Module - Fml, Module -
Xdoc, Module - Xhtml, Site Renderer
Affects Versions: 1.0-alpha-8
Reporter: Herve Boutemy
Assignee: Vincent Siveton
Fix For: 1.0-alpha-9
Attachments: DOXIA-133_doxia-siterenderer.diff, DOXIA-133_doxia.diff,
DOXIA-133_doxia.diff, DOXIA-133_doxia.diff
Encoding can be specified per file, in the XML header: ?xml version=1.0
encoding=xxx?, or defaults to UTF-8
But DefaultSiteRenderer class always read files with inputEncoding: {{reader
= new InputStreamReader( new FileInputStream( fullPathDoc ),
context.getInputEncoding() );}}
When the source file is XML (xdoc, xhtml), should use XmlReader from
PLXUTILS-11 to detect the XML stream encoding instead.
Test case included in MSITE-239, site-plugin-test14
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DOXIA-103) Input encoding handling problem
[ http://jira.codehaus.org/browse/DOXIA-103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton closed DOXIA-103. - Assignee: Vincent Siveton Resolution: Fixed patch applied. Thanks. Input encoding handling problem --- Key: DOXIA-103 URL: http://jira.codehaus.org/browse/DOXIA-103 Project: Maven Doxia Issue Type: Bug Components: Site Renderer Environment: Linux, Java 5 Reporter: Sergey N. Zaitsev Assignee: Vincent Siveton Priority: Trivial Fix For: 1.0-alpha-9 Attachments: default-site-renderer.diff Site Renderer ignores inputEncoding parameter and uses ISO-8859-1 encoding when reading source 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: (DOXIA-147) Reviewed velocity warning
Reviewed velocity warning - Key: DOXIA-147 URL: http://jira.codehaus.org/browse/DOXIA-147 Project: Maven Doxia Issue Type: Improvement Affects Versions: 1.0-alpha-9 Reporter: Vincent Siveton Fix For: 1.0-alpha-9 The Velocity component configuration added with DOXIA-128 produces now lot of warnings, ie [WARNING] Velocimacro : VM addition rejected : displayTree : inline not allowed to replace existing VM [WARNING] Failed to add macro: #displayTree( display item ) : source = default-site.vm -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-314) PDE: Reactor dependencies left out of META/MANIFEST, causing PDE build failure
[ http://jira.codehaus.org/browse/MECLIPSE-314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Graham Leggett updated MECLIPSE-314: Attachment: pde-reactor-fix-2.patch A further problem was uncovered with PDE support and reactor projects. In addition to the MANIFEST.MF file, reactor project jars must also be written to the .project file, otherwise the artifacts of the reactor projects never make it into the final product, and the PDE build fails. This new patch addresses this issue. PDE: Reactor dependencies left out of META/MANIFEST, causing PDE build failure -- Key: MECLIPSE-314 URL: http://jira.codehaus.org/browse/MECLIPSE-314 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Components: PDE support Affects Versions: 2.4 Environment: java version 1.5.0_11 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_11-b03) Java HotSpot(TM) 64-Bit Server VM (build 1.5.0_11-b03, mixed mode) Reporter: Graham Leggett Attachments: pde-reactor-fix-2.patch, pde-reactor-fix.patch When the eclipse:eclipse goal synchronises MANIFEST.MF during PDE builds, all reactor projects are accidently left off the dependency list that gets written to Bundle-Classpath. This causes the PDE build to fail. The attached patch fixes this issue by inserting the missing reactor dependencies when writing the Bundle-Classpath. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRM-408) The mvn deploy:deploy-file command gives Parent doesn't exist in a fresh install
[ http://jira.codehaus.org/browse/MRM-408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_104428 ] Brett Porter commented on MRM-408: -- I will take a look at this The mvn deploy:deploy-file command gives Parent doesn't exist in a fresh install -- Key: MRM-408 URL: http://jira.codehaus.org/browse/MRM-408 Project: Archiva Issue Type: Bug Affects Versions: 1.0-alpha-1 Environment: Archiva 0.9-alpha-2 (bin) Reporter: Damon Rand Assignee: Brett Porter Fix For: 1.0-beta-2 I'm trying to follow the docs at this page. http://maven.apache.org/archiva/guides/getting-started/maven-configuration.html I'm setting security credentials and issuing this command with a pom.xml to include wagon-webdav mvn deploy:deploy-file -DgroupId=com.orbeon -DartifactId=blah -Dversion=3.5.1 -Dpackaging=jar -Dfile=lib/blah.jar -DrepositoryId=3rdp-releases -Durl=http://jerboa.intsec.amnesty.org:8081/archiva/repository/3rdp-releases/ I get this error message [INFO] Error deploying artifact: Failed to transfer file: http://jerboa.intsec.a mnesty.org:8081/archiva/repository/3rdp-releases//com/orbeon/blah/3.5.1/blah-3.5 .1.jar. Return code is: 409 An ethereal trace shows this request PUT /archiva/repository/3rdp-releases/com/orbeon/blah/3.5.1/blah-3.5.1.jar HTTP/1.1 And this response.. html headtitleError 409 Conflict/title/head body pbError 409 Conflict/b/p pResource in error: a href=http://jerboa.intsec.amnesty.org:8081/archiva/repository/com/orbeon/blah/3.5.1/blah-3.5.1.jar/com/orbeon/blah/3.5.1/blah-3.5.1.jar; http://jerboa.intsec.amnesty.org:8081/archiva/repository/com/orbeon/blah/3.5.1/blah-3.5.1.jar/com/orbeon/blah/3.5.1/blah-3.5.1.jar/a/p hr /pException details:/p preit.could.webdav.DAVException: Parent doesn't exist at it.could.webdav.DAVResource.write(DAVResource.java:465) at it.could.webdav.methods.PUT.process(PUT.java:59) at it.could.webdav.DAVProcessor.process(DAVProcessor.java:79) at org.codehaus.plexus.webdav.simple.SimpleDavServerComponent.process(SimpleDavServerComponent.java:142) at org.apache.maven.archiva.web.repository.ProxiedDavServer.process(ProxiedDavServer.java:156) at org.codehaus.plexus.webdav.servlet.multiplexed.MultiplexedWebDavServlet.service(MultiplexedWebDavServlet.java:111) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:830) at com.opensymphony.webwork.dispatcher.FilterDispatcher.doFilter(FilterDispatcher.java:189) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821) at com.opensymphony.module.sitemesh.filter.PageFilter.doFilter(PageFilter.java:39) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821) at com.opensymphony.webwork.dispatcher.ActionContextCleanUp.doFilter(ActionContextCleanUp.java:88) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:471) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:568) at org.mortbay.http.HttpContext.handle(HttpContext.java:1530) at org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:633) at org.mortbay.http.HttpContext.handle(HttpContext.java:1482) at org.mortbay.http.HttpServer.service(HttpServer.java:909) at org.mortbay.http.HttpConnection.service(HttpConnection.java:816) at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:982) at org.mortbay.http.HttpConnection.handle(HttpConnection.java:833) at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:244) at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357) at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534) /pre /body /html Note that request and response are very different.. /archiva/repository/3rdp-releases/com/orbeon/blah/3.5.1/blah-3.5.1.jar /archiva/repository/com/orbeon/blah/3.5.1/blah-3.5.1.jar/com/orbeon/blah/3.5.1/blah-3.5.1.jar Has anyone got this working? I can't imagine how it could work, at least in the release I have. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see:
[jira] Commented: (MRM-243) 507 Insufficient Storage when deploying artifact with webdav
[ http://jira.codehaus.org/browse/MRM-243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_104427 ] Brett Porter commented on MRM-243: -- I will take a look at this 507 Insufficient Storage when deploying artifact with webdav Key: MRM-243 URL: http://jira.codehaus.org/browse/MRM-243 Project: Archiva Issue Type: Bug Components: web application Environment: mvn 2.0.4, Windows Server 2003, Tomcat 5.5.17, Sun JDK 1.5.0_08, archiva HEAD Reporter: Magne Rasmussen Assignee: Brett Porter Fix For: 1.0-beta-2 Sometimes when deploying with dav I get a 507 Insufficient Storage error. The artifact (.../group/artifact/version/artifact-version.jar) gets deployed (with checksums). The metadata (.../group/artifact/version/maven-metatdata.xml) gets deployed (with checksums). It seems to happen when maven tries to upload the updated parent metadata (.../group/artifact/maven-metadata.xml). The checksums for this metadata deploys OK. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MRM-243) 507 Insufficient Storage when deploying artifact with webdav
[ http://jira.codehaus.org/browse/MRM-243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_104426 ] Brett Porter commented on MRM-243: -- confirmed. Shutting down Archiva and then starting it again let's you deploy once. The problem is only in writing the metadata. 507 Insufficient Storage when deploying artifact with webdav Key: MRM-243 URL: http://jira.codehaus.org/browse/MRM-243 Project: Archiva Issue Type: Bug Components: web application Environment: mvn 2.0.4, Windows Server 2003, Tomcat 5.5.17, Sun JDK 1.5.0_08, archiva HEAD Reporter: Magne Rasmussen Fix For: 1.0-beta-2 Sometimes when deploying with dav I get a 507 Insufficient Storage error. The artifact (.../group/artifact/version/artifact-version.jar) gets deployed (with checksums). The metadata (.../group/artifact/version/maven-metatdata.xml) gets deployed (with checksums). It seems to happen when maven tries to upload the updated parent metadata (.../group/artifact/maven-metadata.xml). The checksums for this metadata deploys OK. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-983) There should be real Group Actions that affect members of the group, and can affect subsets of group members based on selection.
[ http://jira.codehaus.org/browse/CONTINUUM-983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_104433 ] Emmanuel Venisse commented on CONTINUUM-983: Delete action is implemented There should be real Group Actions that affect members of the group, and can affect subsets of group members based on selection. -- Key: CONTINUUM-983 URL: http://jira.codehaus.org/browse/CONTINUUM-983 Project: Continuum Issue Type: Improvement Components: Web interface Affects Versions: 1.1-alpha-1 Reporter: Christian Gruber Fix For: 1.1-beta-2 There should be real Group Actions that affect members of the group, and can affect subsets of group members based on selection. In particular, there should be check-boxes before each member, which can allow such group actions to affect one or more members. Group actions I envision would include Build (with default build def) and Remove project from group. Any selected groups would be built or removed. The current Remove button would be moved elsewhere, as it is not about the contents of the group, but deletes the whole group. Possibly simply making an X remove button on the main list of groups, much the way individual projects have the same would 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: (MNG-3143) Allow handling custom typed artifacts
Allow handling custom typed artifacts - Key: MNG-3143 URL: http://jira.codehaus.org/browse/MNG-3143 Project: Maven 2 Issue Type: Improvement Components: Shared Affects Versions: Shared Components Reporter: Arnaud Bailly Priority: Minor Attachments: custom-type.patch In the Verifier class, checking artifacts' presence/absence in the repository does not handle custom types/extensions. The attached patch adds a TypeHandler class (a ligthweight ArtifactHandler) and a addHandler method for managing custom artifact types. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-2861) NullPointerException in DefaultArtifactCollector for relocated resolvedArtifacts with different version ranges and available versions.
[ http://jira.codehaus.org/browse/MNG-2861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_104453 ] Matthew Beermann commented on MNG-2861: --- Er, looks like I misnamed the patch. It should be MNG-2861-maven-artifact.patch, of course. NullPointerException in DefaultArtifactCollector for relocated resolvedArtifacts with different version ranges and available versions. -- Key: MNG-2861 URL: http://jira.codehaus.org/browse/MNG-2861 Project: Maven 2 Issue Type: Bug Components: Artifacts and Repositories Affects Versions: 2.0.5 Reporter: Micah Whitacre Fix For: Reviewed Pending Version Assignment Attachments: MNG-2861-maven-project.patch In a remoteRepository that I am populating I have a project. Previously I was deploying artifacts with an old groupId and then decided to switch to having a new more descriptive groupId. For the old groupId I have deployed versions 1.0 and 1.1. For the new groupId I have deployed 1.2 and 2.0. I deployed a relocation POM to the old groupId for the 1.2 version. I also updated the metadata.xml files to include 1.2 as an available version. This way projects using version ranges [1,2) will be able to pick up the newest version. So in the repository I now have: oldgroupId:project:1.0 oldgroupId:project:1.1 oldgroupId:project:1.2 - redirecting to newgroupId:project:1.2 newgroupId:project:1.2 newgroupId:project:2.0 The oldgroupId's metadata lists the available versions as [1.0,1.1,1.2]. The newgroupId's metadata lists the available versions has [1,2]. I have 3 additional projects A, B, C. A depends on B and C. B depends on oldgroupId:project:[1,2). Project B has also finished development and been released so we are avoiding rereleasing it for the groupId change. C depends on newgroupId:project:[2,3). When I try to build project A, Maven dies and gives me the following stack trace. [INFO] [ERROR] FATAL ERROR [INFO] [INFO] null [INFO] [DEBUG] Trace java.lang.NullPointerException at org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:168) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:305) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:305) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(DefaultArtifactCollector.java:70) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:284) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:272) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:243) at org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDependencies(DefaultPluginManager.java:1142) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:374) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:330) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:123) at org.apache.maven.cli.MavenCli.main(MavenCli.java:272) 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
[jira] Created: (MNG-3144) Snapshots not updated when using uniqueVersion false
Snapshots not updated when using uniqueVersion false Key: MNG-3144 URL: http://jira.codehaus.org/browse/MNG-3144 Project: Maven 2 Issue Type: Bug Components: Artifacts and Repositories Affects Versions: 2.0.7 Reporter: Nicky Sandhu Priority: Critical The particular scenario here is 1.) Deploy snapshot using uniqueVersion false in distribution management 2.) Verify repository has latest snapshot and metadata is updated in build number and timestamp 3. ) Goto a developer's machine (not the same as from which it was deployed) and do mvn -U or specify updates to be always in pom 4.) Local cache shows the maven metadata xml file is updated but the snapshot artifact (jar in this case) is not -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (CONTINUUM-983) There should be real Group Actions that affect members of the group, and can affect subsets of group members based on selection.
[ http://jira.codehaus.org/browse/CONTINUUM-983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed CONTINUUM-983. -- Assignee: Emmanuel Venisse Resolution: Fixed build action is implemented There should be real Group Actions that affect members of the group, and can affect subsets of group members based on selection. -- Key: CONTINUUM-983 URL: http://jira.codehaus.org/browse/CONTINUUM-983 Project: Continuum Issue Type: Improvement Components: Web interface Affects Versions: 1.1-alpha-1 Reporter: Christian Gruber Assignee: Emmanuel Venisse Fix For: 1.1-beta-2 There should be real Group Actions that affect members of the group, and can affect subsets of group members based on selection. In particular, there should be check-boxes before each member, which can allow such group actions to affect one or more members. Group actions I envision would include Build (with default build def) and Remove project from group. Any selected groups would be built or removed. The current Remove button would be moved elsewhere, as it is not about the contents of the group, but deletes the whole group. Possibly simply making an X remove button on the main list of groups, much the way individual projects have the same would 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] Closed: (CONTINUUM-982) Project Group Actions should be renamed Group Actions to avoid confusion.
[ http://jira.codehaus.org/browse/CONTINUUM-982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed CONTINUUM-982. -- Assignee: Emmanuel Venisse Resolution: Fixed Project Group Actions should be renamed Group Actions to avoid confusion. - Key: CONTINUUM-982 URL: http://jira.codehaus.org/browse/CONTINUUM-982 Project: Continuum Issue Type: Improvement Components: Web interface Affects Versions: 1.1-alpha-1 Reporter: Christian Gruber Assignee: Emmanuel Venisse Priority: Trivial Fix For: 1.1-beta-2 Summary says it all. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (CONTINUUM-981) Remove button on group actions is ambiguous and should be renamed Delete Group or Remove Group.
[ http://jira.codehaus.org/browse/CONTINUUM-981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed CONTINUUM-981. -- Assignee: Emmanuel Venisse Resolution: Fixed Remove button on group actions is ambiguous and should be renamed Delete Group or Remove Group. - Key: CONTINUUM-981 URL: http://jira.codehaus.org/browse/CONTINUUM-981 Project: Continuum Issue Type: Improvement Components: Web interface Affects Versions: 1.1-alpha-1 Reporter: Christian Gruber Assignee: Emmanuel Venisse Priority: Trivial Fix For: 1.1-beta-2 Remove button on group actions is ambiguous and should be renamed Delete Group or Remove Group. It currently reads as if it would remove some group members. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-1380) Move some duplicate data beans to api and create the appropriate services
[ http://jira.codehaus.org/browse/CONTINUUM-1380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated CONTINUUM-1380: Fix Version/s: Future Move some duplicate data beans to api and create the appropriate services - Key: CONTINUUM-1380 URL: http://jira.codehaus.org/browse/CONTINUUM-1380 Project: Continuum Issue Type: Improvement Components: Core system Affects Versions: 1.1-beta-1 Reporter: Olivier Lamy Fix For: Future Actually some data beans are duplicate in continuum-webapp and continuum-xmlrpc-api (ProjectGroupSummary, ProjectSummary ...). And some code is duplicate in this two modules. We can move all of this common part in api/core. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-1380) Move some duplicate data beans to api and create the appropriate services
Move some duplicate data beans to api and create the appropriate services - Key: CONTINUUM-1380 URL: http://jira.codehaus.org/browse/CONTINUUM-1380 Project: Continuum Issue Type: Improvement Components: Core system Affects Versions: 1.1-beta-1 Reporter: Olivier Lamy Fix For: Future Actually some data beans are duplicate in continuum-webapp and continuum-xmlrpc-api (ProjectGroupSummary, ProjectSummary ...). And some code is duplicate in this two modules. We can move all of this common part in api/core. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-1380) Move some duplicate data beans to api and create the appropriate services
[ http://jira.codehaus.org/browse/CONTINUUM-1380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_104465 ] Olivier Lamy commented on CONTINUUM-1380: - starting of this in CONTINUUM-1333. Adding a ProjectSummary bean and ProjectSummaryService. Move some duplicate data beans to api and create the appropriate services - Key: CONTINUUM-1380 URL: http://jira.codehaus.org/browse/CONTINUUM-1380 Project: Continuum Issue Type: Improvement Components: Core system Affects Versions: 1.1-beta-1 Reporter: Olivier Lamy Fix For: Future Actually some data beans are duplicate in continuum-webapp and continuum-xmlrpc-api (ProjectGroupSummary, ProjectSummary ...). And some code is duplicate in this two modules. We can move all of this common part in api/core. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-1333) show in project group summary per project also the status counters (as they are shown on the project groups pages)
[ http://jira.codehaus.org/browse/CONTINUUM-1333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated CONTINUUM-1333: Attachment: CONTINUUM-1333 patch attached. show in project group summary per project also the status counters (as they are shown on the project groups pages) --- Key: CONTINUUM-1333 URL: http://jira.codehaus.org/browse/CONTINUUM-1333 Project: Continuum Issue Type: Improvement Components: Web interface Affects Versions: 1.1-alpha-2 Reporter: tony nys Assignee: Olivier Lamy Priority: Minor Fix For: 1.1-beta-2 Attachments: CONTINUUM-1333 show in project group summary per project also the status counters (as they are shown on the project groups pages) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-971) Symbolic links are traversed on deletion
[ http://jira.codehaus.org/browse/CONTINUUM-971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated CONTINUUM-971: --- Attachment: CONTINUUM-971 patch attached. Symbolic links are traversed on deletion Key: CONTINUUM-971 URL: http://jira.codehaus.org/browse/CONTINUUM-971 Project: Continuum Issue Type: Bug Components: Environmental Affects Versions: 1.0.3 Environment: Reproduced on Redhat Enterprise 4 but applicable to all forms of UNIX Reporter: Uri Moszkowicz Assignee: Olivier Lamy Priority: Critical Fix For: 1.1-beta-2 Attachments: CONTINUUM-971 To reproduce: 1. Create a project that checks out files from some SCM 2. Create a build script that creates symbolic links outside of the checked out project sandbox. This is often done to bring outside libraries into the project. 3. Delete the created project from the Continuum website. Notice how all kinds of files disappear from your file system! From looking at the release logs it looks like someone added follow symbolic links as the default and mentioned that at some point in the future an option should be added to disable this behavior. Following symbolic links is very dangerous and if supported it should be disabled by default, not the reverse. A warning should be posted in a visible place for the existing versions until this can be fixed as it can result in significant data loss outside of the Continuum program. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MINVOKER-8) invoker unit tests fail
invoker unit tests fail --- Key: MINVOKER-8 URL: http://jira.codehaus.org/browse/MINVOKER-8 Project: Maven 2.x Invoker Plugin Issue Type: Bug Reporter: Brett Porter Assignee: John Casey I get the following failure on my Mac: testBuildShouldSucceed(org.apache.maven.shared.invoker.DefaultInvokerTest) Time elapsed: 1.058 sec FAILURE! junit.framework.AssertionFailedError: expected:0 but was:1 at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.failNotEquals(Assert.java:282) at junit.framework.Assert.assertEquals(Assert.java:64) at junit.framework.Assert.assertEquals(Assert.java:201) at junit.framework.Assert.assertEquals(Assert.java:207) at org.apache.maven.shared.invoker.DefaultInvokerTest.testBuildShouldSucceed(DefaultInvokerTest.java:44) at org.apache.maven.shared.invoker.DefaultInvokerTest.testBuildShouldSucceed(DefaultInvokerTest.java:44) The same issue is being seen in CI: http://maven.zones.apache.org/continuum/surefireReport.action?buildId=13387projectId=57#org.apache.maven.shared.invoker.DefaultInvokerTest this is building the shared 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] Created: (MRM-463) Metadata merging doesn't work.
Metadata merging doesn't work. -- Key: MRM-463 URL: http://jira.codehaus.org/browse/MRM-463 Project: Archiva Issue Type: Bug Components: remote proxy Affects Versions: 1.0-beta-2 Reporter: Joakim Erdfelt Priority: Blocker When dealing with metadata.xml files and proxying the merging of metadata is not performed correctly. Often ending up with a metadata.xml file with no versions specified. Tasks * Re-enabled metadata tests in the archiva-proxy module. * Fix the proxy code (and possibly the tests) to ensure metadata.xml files are merged correctly. * Create tests for 1 managed to multiple remote repos all with metadata.xml for the same groupId:artifactId * Create tests for versionless and versioned metadata.xml files. Note: Consider using the VersionComparator to obtain a unique list of sorted (by version) versions for the merged metadata.xml file. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRM-464) Metadata.xml files are not released from a filesystem lock in Win32
Metadata.xml files are not released from a filesystem lock in Win32 --- Key: MRM-464 URL: http://jira.codehaus.org/browse/MRM-464 Project: Archiva Issue Type: Bug Components: WebDAV interface Affects Versions: 1.0-beta-2 Reporter: Joakim Erdfelt Priority: Critical When using archiva on windows, and then performing a deploy, the metadata.xml files that are deployed get locked by archiva and then cannot be updated/redeployed by a subsequent deploy request. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MRM-466) NPE on DatabaseJob.execute()
[ http://jira.codehaus.org/browse/MRM-466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_104478 ] Brett Porter commented on MRM-466: -- this seems closely related to the same problem we saw occurring in Continuum not that long ago. We solved it buy adding a null guard around the operation, but we might want to consider an upgrade to the quartz component. NPE on DatabaseJob.execute() Key: MRM-466 URL: http://jira.codehaus.org/browse/MRM-466 Project: Archiva Issue Type: Bug Components: scheduling Affects Versions: 1.0-beta-2 Reporter: Joakim Erdfelt From archiva.log 30778389 [defaultScheduler_Worker-13] ERROR org.quartz.core.JobRunShell - Job database-group.database-job threw an unhandled Exception: java.lang.NullPointerException at org.apache.maven.archiva.scheduled.DatabaseTaskJob.execute(DatabaseTaskJob.java:57) at org.quartz.core.JobRunShell.run(JobRunShell.java:191) at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:516) 30778390 [defaultScheduler_Worker-13] ERROR org.quartz.core.ErrorLogger - Job (database-group.database-job threw an exception. org.quartz.SchedulerException: Job threw an unhandled exception. [See nested exception: java.lang.NullPointerException] at org.quartz.core.JobRunShell.run(JobRunShell.java:202) at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:516) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MRM-465) [Load Testing] When asking for pages that require the effective-pom in high load, app becomes unresponsive.
[ http://jira.codehaus.org/browse/MRM-465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_104476 ] Brett Porter commented on MRM-465: -- I would suggest by starting with locking and an in-memory cache. [Load Testing] When asking for pages that require the effective-pom in high load, app becomes unresponsive. --- Key: MRM-465 URL: http://jira.codehaus.org/browse/MRM-465 Project: Archiva Issue Type: Bug Components: browser Affects Versions: 1.0-beta-2 Reporter: Joakim Erdfelt Priority: Critical When having a process/tool (such as siege) hit the artifact browsing pages on archiva in rapid succession, the archiva application becomes unresponsive. Possible reason: when the first request hits to get the effective pom, the build of that effective pom starts, but before it has a chance to finish, another request arrives to do the same thing, and the process starts again, resources and such get eaten up fast in that scenario. Possible solution: * Lock the effective pom resolution on a per groupId:artifactId:version level. * Cache the effective pom on disk. ** (option 1) save the effective pom to disk in the groupId:artifactId:version location using the extension .effective.pom ** (option 2) save the effective pom to a long lived ehcache (backed on disk, in ehcache format) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-466) NPE on DatabaseJob.execute()
NPE on DatabaseJob.execute() Key: MRM-466 URL: http://jira.codehaus.org/browse/MRM-466 Project: Archiva Issue Type: Bug Components: scheduling Affects Versions: 1.0-beta-2 Reporter: Joakim Erdfelt From archiva.log 30778389 [defaultScheduler_Worker-13] ERROR org.quartz.core.JobRunShell - Job database-group.database-job threw an unhandled Exception: java.lang.NullPointerException at org.apache.maven.archiva.scheduled.DatabaseTaskJob.execute(DatabaseTaskJob.java:57) at org.quartz.core.JobRunShell.run(JobRunShell.java:191) at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:516) 30778390 [defaultScheduler_Worker-13] ERROR org.quartz.core.ErrorLogger - Job (database-group.database-job threw an exception. org.quartz.SchedulerException: Job threw an unhandled exception. [See nested exception: java.lang.NullPointerException] at org.quartz.core.JobRunShell.run(JobRunShell.java:202) at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:516) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-464) Metadata.xml files are not released from a filesystem lock in Win32
[ http://jira.codehaus.org/browse/MRM-464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MRM-464. Assignee: Brett Porter Resolution: Duplicate Metadata.xml files are not released from a filesystem lock in Win32 --- Key: MRM-464 URL: http://jira.codehaus.org/browse/MRM-464 Project: Archiva Issue Type: Bug Components: WebDAV interface Affects Versions: 1.0-beta-2 Reporter: Joakim Erdfelt Assignee: Brett Porter Priority: Critical When using archiva on windows, and then performing a deploy, the metadata.xml files that are deployed get locked by archiva and then cannot be updated/redeployed by a subsequent deploy request. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-465) [Load Testing] When asking for pages that require the effective-pom in high load, app becomes unresponsive.
[Load Testing] When asking for pages that require the effective-pom in high load, app becomes unresponsive. --- Key: MRM-465 URL: http://jira.codehaus.org/browse/MRM-465 Project: Archiva Issue Type: Bug Components: browser Affects Versions: 1.0-beta-2 Reporter: Joakim Erdfelt Priority: Critical When having a process/tool (such as siege) hit the artifact browsing pages on archiva in rapid succession, the archiva application becomes unresponsive. Possible reason: when the first request hits to get the effective pom, the build of that effective pom starts, but before it has a chance to finish, another request arrives to do the same thing, and the process starts again, resources and such get eaten up fast in that scenario. Possible solution: * Lock the effective pom resolution on a per groupId:artifactId:version level. * Cache the effective pom on disk. ** (option 1) save the effective pom to disk in the groupId:artifactId:version location using the extension .effective.pom ** (option 2) save the effective pom to a long lived ehcache (backed on disk, in ehcache format) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MRM-265) After removing a managed repository - Browse/Search still see it
[ http://jira.codehaus.org/browse/MRM-265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_104479 ] Joakim Erdfelt commented on MRM-265: MRM-37 - The Database Scan tasks should pick up the removed artifacts, and/or repository configuration and remove the entries from the database and lucene indexes. After removing a managed repository - Browse/Search still see it Key: MRM-265 URL: http://jira.codehaus.org/browse/MRM-265 Project: Archiva Issue Type: Bug Components: web application Affects Versions: 1.0-alpha-1 Reporter: Henri Yandell Fix For: 1.0-beta-2 I had a repository with lots of stuff in. I removed that (but didn't delete contents), then I added a tiny repository with a couple of jars in. When I goto browse and search, I still see the original, now removed, repository. Re-indexing didn't help [JIRA uses indexes for lists a lot, so I figured this might be the case here 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-467) 500 error when user requested the dependency tree for artifact
500 error when user requested the dependency tree for artifact -- Key: MRM-467 URL: http://jira.codehaus.org/browse/MRM-467 Project: Archiva Issue Type: Bug Affects Versions: 1.0-beta-1 Reporter: James William Dumay Attachments: archiva.log User requested dependency for an artifact and got a 500 error. archiva.log attached. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
