[jira] Updated: (CONTINUUM-1098) Cannot upload a Maven 2 Project with modules
[ http://jira.codehaus.org/browse/CONTINUUM-1098?page=all ] Franz Allan Valencia See updated CONTINUUM-1098: Attachment: CONTINUUM-1098-continuum-webapp.patch CONTINUUM-1098-continuum-webapp.patch contains a workaround to this problem by allowing file:/ to the POM Url, as well as an improve error message when uploading an m2 project with modules. > Cannot upload a Maven 2 Project with modules > > > Key: CONTINUUM-1098 > URL: http://jira.codehaus.org/browse/CONTINUUM-1098 > Project: Continuum > Issue Type: Improvement > Components: Core system, Web interface, Web - UI >Affects Versions: 1.1 > Environment: -r490655 >Reporter: Franz Allan Valencia See > Attachments: CONTINUUM-1098-continuum-webapp.patch, error logs.txt, > error page.JPG > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MDEP-48) Sites and Repos out of sync
[ http://jira.codehaus.org/browse/MDEP-48?page=all ] Brian Fox closed MDEP-48. - Resolution: Fixed Fix Version/s: 2.0-alpha-1 Fixed by the impending release > Sites and Repos out of sync > --- > > Key: MDEP-48 > URL: http://jira.codehaus.org/browse/MDEP-48 > Project: Maven 2.x Dependency Plugin > Issue Type: Task >Affects Versions: 1.0 >Reporter: Barrett Nuzum > Assigned To: Brian Fox > Fix For: 2.0-alpha-1 > > > Central contains the dependency-maven-plugin under groupId org.codehaus.mojo > Trying to check out the svn repository instructs the user that the source > code is no longer at codehaus, but rather at apache.org > Going to the site at apache.org, there is no "Project Info". > http://maven.apache.org/plugins/maven-dependency-plugin/examples/copying-unpacking.html > In addition, the org.apache.maven.plugins version is not available at central > at all. > Please fully deprecate codehaus' site to point to apache.org, and deploy the > current stable release to central under the right group and artifact. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-234) Moving files between repos through webdav doesn't work
[ http://jira.codehaus.org/browse/MRM-234?page=comments#action_83967 ] Brett Porter commented on MRM-234: -- what's the downside of using slide? of them all, (2) seems like the "best" solution, assuming that is fairly straightfoward? > Moving files between repos through webdav doesn't work > -- > > Key: MRM-234 > URL: http://jira.codehaus.org/browse/MRM-234 > Project: Archiva > Issue Type: Bug > Components: repository interface >Affects Versions: 1.0 >Reporter: Carlos Sanchez > Fix For: 1.0 > > Attachments: client.log, server.log, webdav-0.5-dev.jar > > > The goal is to move files from one repo to another through the webdav > interface, using a webdav client, like Windows My Network Places or BitKinex > Two repos where created and accessed with username/password > http://localhost:8092/repository/repo1 > http://localhost:8092/repository/repo2 > Copying from one to another fails. > Copying from any other webdav server to them works > Copying from them to any other webdav server works > Copying from local to them and from them to local of course works > I tried with latest svn code from could.it which includes this MOVE > improvement http://issues.apache.org/jira/browse/HADOOP-505 that makes a real > move and not a copy+delete -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-2741) Meaningless error message: "Error transferring file"
[ http://jira.codehaus.org/browse/MNG-2741?page=all ] Brian Fox updated MNG-2741: --- Affects Version/s: 2.0.4 Component/s: Artifacts and Repositories Issue Type: Improvement (was: Bug) > Meaningless error message: "Error transferring file" > > > Key: MNG-2741 > URL: http://jira.codehaus.org/browse/MNG-2741 > Project: Maven 2 > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 2.0.4 >Reporter: Graham Leggett > Assigned To: Brian Fox > > When an attempt is made to resolve dependencies, the following error is > encountered: > [INFO] artifact org.apache.maven.plugins:maven-resources-plugin: checking for > updates from codehaus-mojo-snapshot-plugins > [WARNING] repository metadata for: 'artifact > org.apache.maven.plugins:maven-resources-plugin' could not be retrieved from > repository: codehaus-mojo-snapshot-plugins due to an error: Error > transferring file > [INFO] Repository 'codehaus-mojo-snapshot-plugins' will be blacklisted > Without further information, debugging this problem is impractical. > Information needed in the error message: > - Whether or not a proxy is being used, and if so, which one. (Symptoms in > this case indicate no proxy is being used, yet a proxy is configured - no way > to tell whether its a config problem or a proxy problem) > - Whether the server and/or proxy server gave an error code (4xx, 5xx), or > whether there was no response at 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] Moved: (MNG-2741) Meaningless error message: "Error transferring file"
[ http://jira.codehaus.org/browse/MNG-2741?page=all ] Brian Fox moved MDEP-53 to MNG-2741: Complexity: Intermediate Key: MNG-2741 (was: MDEP-53) Project: Maven 2 (was: Maven 2.x Dependency Plugin) > Meaningless error message: "Error transferring file" > > > Key: MNG-2741 > URL: http://jira.codehaus.org/browse/MNG-2741 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0.4 >Reporter: Graham Leggett > Assigned To: Brian Fox > > When an attempt is made to resolve dependencies, the following error is > encountered: > [INFO] artifact org.apache.maven.plugins:maven-resources-plugin: checking for > updates from codehaus-mojo-snapshot-plugins > [WARNING] repository metadata for: 'artifact > org.apache.maven.plugins:maven-resources-plugin' could not be retrieved from > repository: codehaus-mojo-snapshot-plugins due to an error: Error > transferring file > [INFO] Repository 'codehaus-mojo-snapshot-plugins' will be blacklisted > Without further information, debugging this problem is impractical. > Information needed in the error message: > - Whether or not a proxy is being used, and if so, which one. (Symptoms in > this case indicate no proxy is being used, yet a proxy is configured - no way > to tell whether its a config problem or a proxy problem) > - Whether the server and/or proxy server gave an error code (4xx, 5xx), or > whether there was no response at 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: (MINSTALL-32) classifier does not work on install:install-file, default artifact overwritten
[ http://jira.codehaus.org/browse/MINSTALL-32?page=all ] Wendy Smoak closed MINSTALL-32. --- Resolution: Fixed Fix Version/s: 2.2 Closing as a duplicate of MINSTALL-24, which is fixed in v2.2 (unreleased). > classifier does not work on install:install-file, default artifact overwritten > -- > > Key: MINSTALL-32 > URL: http://jira.codehaus.org/browse/MINSTALL-32 > Project: Maven 2.x Install Plugin > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Simon Gunzenreiner > Fix For: 2.2 > > > It would be very useful to be able to use the a -Dclassifer argument to the > install:install-file plugin. Although the documentation does not mention that > the use of "classifier" is supported, the InstallFileMojo let's assume so - > because it uses the "classifier". > Still though if install:insta--file is used in the following way: > mvn install:install-file -DgeneratePom=true -Dpackaging=jar > -DgroupId=myGroupId -Dversion=myVersino -DartifactId=myArtifactId > -Dclassifier=sources -Dfile=myArtifactId-myVersion-sources.jar > the default (jar) artifact is replaced with the sources artifact in the > repository. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CONTINUUM-1105) Duplicate email notifications with notifier in pom.xml
[ http://jira.codehaus.org/browse/CONTINUUM-1105?page=all ] Wendy Smoak updated CONTINUUM-1105: --- Description: When there is a notifier in the pom, and a group of projects (such as maven/plugins/trunk/pom.xml) is added under the groupId in the pom, every notification email is duplicated. In the UI for each project, the notifier correctly shows "From Project". It doesn't look like two notifiers have been added. 20070102 IRC conversation about adding maven/plugins/trunk/pom.xml under various groupIds: what could make continuum send duplicate emails? I've added and deleted all of maven/plugins/trunk/pom.xml a few times under different project groups. When I add it under the pom default org.apache.maven.plugins group, I get duplicate emails for every build. wsmoak, have you verified that there are not duplicate entries for emails in the build defs? I used to get duplicates when I belonged to an distribution-list and a direct email address. joakim: there is only the default build definition, and admin is the only member of the group wsmoak: I think we look at project group notifiers too when we look at project notifier, so we get the project group notifier twice when we send the mail it only happens when I add the projects under the pom default group id. If I delete and re-add it to some other group, I only get one email. yes, because, when you use the default project group, project notifiers are moved to the project group but I think they aren't removed in the project okay. and it's only happening with maven/plugins because struts, etc. doesn't have notifiers in the pom. >From the log file (email addresses changed...): INFO | jvm 1| 2007/01/02 20:16:39 | 2007-01-02 20:16:39,831 [pool-1-thread-1] INFO ShellCommandHelper:default - Executing: mvn --batch-mode --non-recursive clean install INFO | jvm 1| 2007/01/02 20:16:39 | 2007-01-02 20:16:39,831 [pool-1-thread-1] INFO ShellCommandHelper:default - Working directory: /opt/continuum-1.1-r490629-SNAPSHOT/apps/continuum/webapp/WEB-INF/working-directory/7 INFO | jvm 1| 2007/01/02 20:16:41 | 2007-01-02 20:16:41,660 [pool-1-thread-1] INFO ContinuumBuildExecutor:maven2 - Exit code: 1 INFO | jvm 1| 2007/01/02 20:16:41 | 2007-01-02 20:16:41,944 [pool-1-thread-1] INFO BuildController:default- Performing action deploy-artifact INFO | jvm 1| 2007/01/02 20:16:42 | 2007-01-02 20:16:42,072 [pool-1-thread-1] INFO Notifier:mail - Sending message: From '"[EMAIL PROTECTED]" <[EMAIL PROTECTED]>'. INFO | jvm 1| 2007/01/02 20:16:42 | 2007-01-02 20:16:42,072 [pool-1-thread-1] INFO Notifier:mail - Recipient: To '<[EMAIL PROTECTED]>'. INFO | jvm 1| 2007/01/02 20:16:42 | 2007-01-02 20:16:42,337 [pool-1-thread-1] INFO Notifier:mail - Sending message: From '"[EMAIL PROTECTED]" <[EMAIL PROTECTED]>'. INFO | jvm 1| 2007/01/02 20:16:42 | 2007-01-02 20:16:42,337 [pool-1-thread-1] INFO Notifier:mail - Recipient: To '<[EMAIL PROTECTED]>'. was: When there is a notifier in the pom, and a group of projects (such as maven/plugins/trunk/pom.xml) is added under the groupId in the pom, every notification email is duplicated. In the UI for each project, the notifier correctly shows "From Project". It doesn't look like two notifiers have been added. 20070102 IRC conversation about adding maven/plugins/trunk/pom.xml under various groupIds: what could make continuum send duplicate emails? I've added and deleted all of maven/plugins/trunk/pom.xml a few times under different project groups. When I add it under the pom default org.apache.maven.plugins group, I get duplicate emails for every build. wsmoak, have you verified that there are not duplicate entries for emails in the build defs? I used to get duplicates when I belonged to an distribution-list and a direct email address. joakim: there is only the default build definition, and admin is the only member of the group wsmoak: I think we look at project group notifiers too when we look at project notifier, so we get the project group notifier twice when we send the mail it only happens when I add the projects under the pom default group id. If I delete and re-add it to some other group, I only get one email. yes, because, when you use the default project group, project notifiers are moved to the project group but I think they aren't removed in the project okay. and it's only happening with maven/plugins because struts, etc. doesn't have notifiers in the pom. >From the log file (email addresses changed...): INFO | jvm 1| 2007/01/02 20:16:39 | 2007-01-02 20:16:39,831 [pool-1-thread-1] INFO ShellCommandHelper:default - Executing: mvn --batch-mode --non-recursive clean install INFO | jvm 1| 2007/01/02 20:16:39 | 2007-01-02 20:16:39,831 [pool-1-thread-1] INFO ShellCommandH
[jira] Reopened: (MRM-213) cannot undeploy archiva webapp
[ http://jira.codehaus.org/browse/MRM-213?page=all ] Dan Tran reopened MRM-213: -- I think we can fix this using this suggestion http://permalink.gmane.org/gmane.comp.jakarta.hivemind.user/2014 It is a big help for to solve jar lockup problem on windows > cannot undeploy archiva webapp > -- > > Key: MRM-213 > URL: http://jira.codehaus.org/browse/MRM-213 > Project: Archiva > Issue Type: Bug > Environment: I'm running Archiva webapp under tomcat 5.5 / windows > 2003 server >Reporter: nicolas de loof >Priority: Minor > > I'd like to undeploy without restarting Tomcat (as I don't have admin acces > to the server). When I undelploy archiva webapp using tomcat manager, the > webapp/archiva directory is not removed and WEB-INF/lib still contains: > jpox-1.1.1.jar > plexus-container-default-1.0-alpha-10.jar > plexus-security-authorization-rbac-store-jdo-1.0-alpha-6-20061013.204855-1.jar > plexus-security-keys-jdo-1.0-alpha-6-20061013.204855-1.jar > plexus-security-user-management-provider-jdo-1.0-alpha-6-20061013.204855-1.jar > webwork-2.2.4.jar > xwork-1.2.1.jar > I cannot remove those jars (files locked) > Maybe some background thread is not stopped at application undeploy ? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-1110) Need a way to force a build of a non-default build definition
Need a way to force a build of a non-default build definition - Key: CONTINUUM-1110 URL: http://jira.codehaus.org/browse/CONTINUUM-1110 Project: Continuum Issue Type: New Feature Components: Web - UI Affects Versions: 1.1 Reporter: Wendy Smoak The Project level "Build Now" and Project Group level "Build" buttons kick off a build of the default build definition. There appears to be no way to force a build of any non-default build definition. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MDEP-53) Meaningless error message: "Error transferring file"
[ http://jira.codehaus.org/browse/MDEP-53?page=comments#action_83949 ] Chris Love commented on MDEP-53: I believe that this is an error message that is created by maven and not by this plugin. I do not believe that this plugin can change this error message. I would encourage you too file this as a bug with the maven team, because this is a error message that is not very helpful. > Meaningless error message: "Error transferring file" > > > Key: MDEP-53 > URL: http://jira.codehaus.org/browse/MDEP-53 > Project: Maven 2.x Dependency Plugin > Issue Type: Bug >Reporter: Graham Leggett > Assigned To: Brian Fox > > When an attempt is made to resolve dependencies, the following error is > encountered: > [INFO] artifact org.apache.maven.plugins:maven-resources-plugin: checking for > updates from codehaus-mojo-snapshot-plugins > [WARNING] repository metadata for: 'artifact > org.apache.maven.plugins:maven-resources-plugin' could not be retrieved from > repository: codehaus-mojo-snapshot-plugins due to an error: Error > transferring file > [INFO] Repository 'codehaus-mojo-snapshot-plugins' will be blacklisted > Without further information, debugging this problem is impractical. > Information needed in the error message: > - Whether or not a proxy is being used, and if so, which one. (Symptoms in > this case indicate no proxy is being used, yet a proxy is configured - no way > to tell whether its a config problem or a proxy problem) > - Whether the server and/or proxy server gave an error code (4xx, 5xx), or > whether there was no response at 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] Updated: (MNG-1577) dependencyManagement does not work for transitive dependencies
[ http://jira.codehaus.org/browse/MNG-1577?page=all ] Patrick Schneider updated MNG-1577: --- Attachment: mng1577f.patch Here is an updated version of mng1577e.patch for the 2.0.x branch. It addresses not being able to bootstrap once the patch has been applied. (Some inheritance tests, added by the patch, were not finding their dependency jars.) > dependencyManagement does not work for transitive dependencies > -- > > Key: MNG-1577 > URL: http://jira.codehaus.org/browse/MNG-1577 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0 >Reporter: Joerg Schaible > Assigned To: John Casey > Fix For: 2.1 > > Attachments: mng1577.patch, mng1577a.patch, mng1577b.patch, > mng1577c.patch, mng1577d.patch, mng1577e-trunk.patch, mng1577e.patch, > mng1577f.patch, mng1577trunk.patch > > > The dependencyManagement does not work for transient dependencies. The > specified version is ignored. > Use case: > Main POM defines commons-digester-1.6 and commons-beanutils-1.7.0, A-SNAPSHOT > and B-SNAPSHOT > Project A is child of Main and depends directly on commons-beanutils (version > inherited from Main) > Project B is child of Main and depends directly on commons-digester (version > inherited from Main) > Project C is child of Main and depends directly on A & B (versions inherited > from Main) > A is compiled and tests are run using commons-beanutils-1.7.0 > B is compiled and tests are run using commons-digester-1.6 and > commons-beanutils-1.6, since digester is dependend on this > C is compiled and tests are run using commons-beanutils-1.7.0 > Integration tests of B did not verify, that B is behaving as expected in this > scenario. B might fail with 1.7.0 and it is not even recognized. > If I add beanutils also as direct dependency to B, it works fine, but then > are transitive dependency useless. It should be possible to define at least > in the dependencyManagement, that the versions of transient dependencies also > defined in the dependencyManagement have priority. > - Jörg -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MDEP-55) generate javadocs and jar src files with releae
generate javadocs and jar src files with releae --- Key: MDEP-55 URL: http://jira.codehaus.org/browse/MDEP-55 Project: Maven 2.x Dependency Plugin Issue Type: Improvement Affects Versions: 2.0 Reporter: Chris Love Assigned To: Brian Fox Priority: Minor Attachments: pompatch.patch see attached pom 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: (MECLIPSE-48) eclipse:eclipse goal should handle includes and excludes of the maven-compiler-plugin
[ http://jira.codehaus.org/browse/MECLIPSE-48?page=comments#action_83945 ] Richard van der Hoff commented on MECLIPSE-48: -- fabrizio, your changes seem to fix this problem nicely for resources, but there's still no means for excluding source files afaict. Are you certain this bug can be closed? > eclipse:eclipse goal should handle includes and excludes of the > maven-compiler-plugin > - > > Key: MECLIPSE-48 > URL: http://jira.codehaus.org/browse/MECLIPSE-48 > Project: Maven 2.x Eclipse Plugin > Issue Type: Improvement >Affects Versions: 2.0 >Reporter: Mark Donszelmann > Assigned To: fabrizio giustina > Fix For: 2.3 > > > The maven-compiler-plugin allows a configuration such as: > > maven-compiler-plugin > > > **/idl/*Factory.java > > > > the generated .classpath file currently does not mention the excluded part: > > > which should be: >path="src/main/java"/> >path="target/generated-sources/idl"/> -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MDEP-54) Exclude and Include specific dependencies based on Artifact id or group name
[ http://jira.codehaus.org/browse/MDEP-54?page=all ] Chris Love updated MDEP-54: --- Attachment: newFilters.patch Patch of implementation of this feature. Did not include regex matching because I based the filters off of the AbstractArtifactFeatureFilter > Exclude and Include specific dependencies based on Artifact id or group name > > > Key: MDEP-54 > URL: http://jira.codehaus.org/browse/MDEP-54 > Project: Maven 2.x Dependency Plugin > Issue Type: New Feature >Affects Versions: 2.0-alpha-1 >Reporter: Chris Love > Assigned To: Brian Fox > Attachments: newFilters.patch > > > new plugin parameters excludeArtifactId, includeArtifactId, excludeGroupId, > includeGroupId > comma seperated lists > first will implement exact matching > laterz will implement regex matching > I want too be able too include or exclude specific jars. Sometimes the > dependent poms do not setup the scope well. For example I do not want too > deploy maven jars! > I recommend adding two different filters to match these dependencies. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-234) Moving files between repos through webdav doesn't work
[ http://jira.codehaus.org/browse/MRM-234?page=comments#action_83940 ]
Joakim Erdfelt commented on MRM-234:
What's happening (Technical)
*Request*
{code}
MOVE /repository/corporate/cas HTTP/1.1
Content-Language: en-us
Accept-Language: en-us
Overwrite: F
Destination: http://192.168.1.104:9091/repository/snapshots/cas
Translate: f
User-Agent: Microsoft Data Access Internet Publishing Provider DAV
Host: 192.168.1.104:9091
Content-Length: 0
Connection: Keep-Alive
Cookie: JSESSIONID=1ia9oq074832f
Authorization: Basic YWRtaW46Ym9iMQ==
{code}
*Response*
{code}
HTTP/1.1 500 URI_scheme_is_not_file
Content-Type: text/html; charset=ISO-8859-1
Content-Length: 3887
Server: Archiva : CouldIT-WebDAV/0.4
DAV: 1
MS-Author-Via: DAV
Connection: keep-alive
HTTP ERROR: 500URI scheme is not "file"
RequestURI=/repository/corporate/casCaused
by:java.lang.IllegalArgumentException: URI scheme is not "file"
.at java.io.File.(File.java:324)
.at it.could.webdav.DAVRepository.getResource(DAVRepository.java:125)
.at it.could.webdav.methods.COPY.process(COPY.java:52)
.at it.could.webdav.methods.MOVE.process(MOVE.java:47)
.at it.could.webdav.DAVProcessor.process(DAVProcessor.java:79)
.at
org.apache.maven.archiva.web.servlet.repository.RepositoryAccess.servletRequest(RepositoryAccess.java:227)
.at
org.apache.maven.archiva.web.servlet.PlexusComponentServlet.service(PlexusComponentServlet.java:129)
.at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:445)
.at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1049)
.at
com.opensymphony.webwork.dispatcher.FilterDispatcher.doFilter(FilterDispatcher.java:189)
.at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1040)
.at
com.opensymphony.module.sitemesh.filter.PageFilter.parsePage(PageFilter.java:118)
{code}
The webdav servlet is being passed 2 pieces of information.
* Source File to Move From: /repository/corporate/cas
* Destination to Move To: http://192.168.1.104:9091/repository/snapshots/cas
The webdav servlet cannot handle moving a resource out to another URL.
It expects local to repository moves only.
That's why we get the URI scheme is not "file" error message.
Potential Solutions:
# Deny COPY and MOVE requests from working.
# Adjust the destination header if it is determined to belong to another
archiva repository before it.could.webdav handles the request.
# Create support for remove URL webdav move in it.could.webdav sourcebase using
slide-webdav-client libraries.
# Dump it.could.webdav in favor of slide-webdav-servlet
None of these solutions seem like a good idea to me.
Any opinions?
> Moving files between repos through webdav doesn't work
> --
>
> Key: MRM-234
> URL: http://jira.codehaus.org/browse/MRM-234
> Project: Archiva
> Issue Type: Bug
> Components: repository interface
>Affects Versions: 1.0
>Reporter: Carlos Sanchez
> Fix For: 1.0
>
> Attachments: client.log, server.log, webdav-0.5-dev.jar
>
>
> The goal is to move files from one repo to another through the webdav
> interface, using a webdav client, like Windows My Network Places or BitKinex
> Two repos where created and accessed with username/password
> http://localhost:8092/repository/repo1
> http://localhost:8092/repository/repo2
> Copying from one to another fails.
> Copying from any other webdav server to them works
> Copying from them to any other webdav server works
> Copying from local to them and from them to local of course works
> I tried with latest svn code from could.it which includes this MOVE
> improvement http://issues.apache.org/jira/browse/HADOOP-505 that makes a real
> move and not a copy+delete
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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-1109) Need a way to override all notifications
Need a way to override all notifications Key: CONTINUUM-1109 URL: http://jira.codehaus.org/browse/CONTINUUM-1109 Project: Continuum Issue Type: New Feature Components: Notifier - AOL, Notifier - IRC, Notifier - Jabber, Notifier - Mail, Notifier - MSN Affects Versions: 1.1 Reporter: Wendy Smoak It is currently possible to override the "To:" address for all email notifications by setting the element in application.xml. This also needs to be done for IRC notifications, etc. Case in point, if you add Cargo to Continuum, it floods the #cargo channel with notices because there is an IRC notifier configured in Cargo's pom. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MEAR-54) module exclusion example is wrong
[ http://jira.codehaus.org/browse/MEAR-54?page=all ] Stephane Nicoll closed MEAR-54. --- Resolution: Fixed Fixed. > module exclusion example is wrong > - > > Key: MEAR-54 > URL: http://jira.codehaus.org/browse/MEAR-54 > Project: Maven 2.x Ear Plugin > Issue Type: Task >Affects Versions: 2.3 >Reporter: Stephane Nicoll > Assigned To: Stephane Nicoll > Fix For: 2.3.1 > > > http://maven.apache.org/plugins/maven-ear-plugin/examples/excluding-a-module.html > specifies warModule instead of webModule. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Work started: (MEAR-54) module exclusion example is wrong
[ http://jira.codehaus.org/browse/MEAR-54?page=all ] Work on MEAR-54 started by Stephane Nicoll. > module exclusion example is wrong > - > > Key: MEAR-54 > URL: http://jira.codehaus.org/browse/MEAR-54 > Project: Maven 2.x Ear Plugin > Issue Type: Task >Affects Versions: 2.3 >Reporter: Stephane Nicoll > Assigned To: Stephane Nicoll > Fix For: 2.3.1 > > > http://maven.apache.org/plugins/maven-ear-plugin/examples/excluding-a-module.html > specifies warModule instead of webModule. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MEAR-53) ejb-client dependencies should not be treated as J2EE application client modules
[ http://jira.codehaus.org/browse/MEAR-53?page=all ] Stephane Nicoll closed MEAR-53. --- Resolution: Fixed This is fixed, a SNAPSHOT has been deployed on the apache repository http://people.apache.org/maven-snapshot-repository/org/apache/maven/plugins/maven-ear-plugin/2.3.1-SNAPSHOT/ Could you please test with this version. If you're happy with it, we'll make sure to release it ASAP. Thanks for the report. > ejb-client dependencies should not be treated as J2EE application client > modules > > > Key: MEAR-53 > URL: http://jira.codehaus.org/browse/MEAR-53 > Project: Maven 2.x Ear Plugin > Issue Type: Bug >Affects Versions: 2.3 > Environment: mvn 2.0.4 >Reporter: Marcel Schutte > Assigned To: Stephane Nicoll > Fix For: 2.3.1 > > > With the release of maven-ear-plugin 2.3, it has become default behavior to > include a tag in the generated application.xml for > dependencies of type ejb-client. > This is not the intended use of the tag and it also causes > errors in Websphere 5.1. is for application client modules > (j2ee modules with an application-client.xml deployment descriptor) and > certainly not for ejb-client jars (which are from a j2ee perspective regular > java jar files). > I understand from the discussion in MEAR-46 that JBoss users sometimes use > the tags as a means to document the jars that make up an ear. > This is al fine, but don't make this the default. > I suggest turning the behavior around and switching the default to no > inclusion in the generated application.xml -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-1105) Duplicate email notifications with notifier in pom.xml
[ http://jira.codehaus.org/browse/CONTINUUM-1105?page=all ] Wendy Smoak updated CONTINUUM-1105: --- Description: When there is a notifier in the pom, and a group of projects (such as maven/plugins/trunk/pom.xml) is added under the groupId in the pom, every notification email is duplicated. In the UI for each project, the notifier correctly shows "From Project". It doesn't look like two notifiers have been added. 20070102 IRC conversation about adding maven/plugins/trunk/pom.xml under various groupIds: what could make continuum send duplicate emails? I've added and deleted all of maven/plugins/trunk/pom.xml a few times under different project groups. When I add it under the pom default org.apache.maven.plugins group, I get duplicate emails for every build. wsmoak, have you verified that there are not duplicate entries for emails in the build defs? I used to get duplicates when I belonged to an distribution-list and a direct email address. joakim: there is only the default build definition, and admin is the only member of the group wsmoak: I think we look at project group notifiers too when we look at project notifier, so we get the project group notifier twice when we send the mail it only happens when I add the projects under the pom default group id. If I delete and re-add it to some other group, I only get one email. yes, because, when you use the default project group, project notifiers are moved to the project group but I think they aren't removed in the project okay. and it's only happening with maven/plugins because struts, etc. doesn't have notifiers in the pom. >From the log file (email addresses changed...): INFO | jvm 1| 2007/01/02 20:16:39 | 2007-01-02 20:16:39,831 [pool-1-thread-1] INFO ShellCommandHelper:default - Executing: mvn --batch-mode --non-recursive clean install INFO | jvm 1| 2007/01/02 20:16:39 | 2007-01-02 20:16:39,831 [pool-1-thread-1] INFO ShellCommandHelper:default - Working directory: /opt/continuum-1.1-r490629-SNAPSHOT/apps/continuum/webapp/WEB-INF/working-directory/7 INFO | jvm 1| 2007/01/02 20:16:41 | 2007-01-02 20:16:41,660 [pool-1-thread-1] INFO ContinuumBuildExecutor:maven2 - Exit code: 1 INFO | jvm 1| 2007/01/02 20:16:41 | 2007-01-02 20:16:41,944 [pool-1-thread-1] INFO BuildController:default- Performing action deploy-artifact INFO | jvm 1| 2007/01/02 20:16:42 | 2007-01-02 20:16:42,072 [pool-1-thread-1] INFO Notifier:mail - Sending message: From '"[EMAIL PROTECTED]" <[EMAIL PROTECTED]>'. INFO | jvm 1| 2007/01/02 20:16:42 | 2007-01-02 20:16:42,072 [pool-1-thread-1] INFO Notifier:mail - Recipient: To '<[EMAIL PROTECTED]>'. INFO | jvm 1| 2007/01/02 20:16:42 | 2007-01-02 20:16:42,337 [pool-1-thread-1] INFO Notifier:mail - Sending message: From '"[EMAIL PROTECTED]" <[EMAIL PROTECTED]>'. INFO | jvm 1| 2007/01/02 20:16:42 | 2007-01-02 20:16:42,337 [pool-1-thread-1] INFO Notifier:mail - Recipient: To '<[EMAIL PROTECTED]>'. Either * the 'add project' logic should remove the notifier from projects if it is added at the group level, or * Continuum should filter out duplicate recipients before sending. was: When there is a notifier in the pom, and a group of projects (such as maven/plugins/trunk/pom.xml) is added under the groupId in the pom, the notifier shows up at the project group level, and on each project. This causes every notification email to be duplicated. 20070102 IRC conversation about adding maven/plugins/trunk/pom.xml under various groupIds: what could make continuum send duplicate emails? I've added and deleted all of maven/plugins/trunk/pom.xml a few times under different project groups. When I add it under the pom default org.apache.maven.plugins group, I get duplicate emails for every build. wsmoak, have you verified that there are not duplicate entries for emails in the build defs? I used to get duplicates when I belonged to an distribution-list and a direct email address. joakim: there is only the default build definition, and admin is the only member of the group wsmoak: I think we look at project group notifiers too when we look at project notifier, so we get the project group notifier twice when we send the mail it only happens when I add the projects under the pom default group id. If I delete and re-add it to some other group, I only get one email. yes, because, when you use the default project group, project notifiers are moved to the project group but I think they aren't removed in the project okay. and it's only happening with maven/plugins because struts, etc. doesn't have notifiers in the pom. >From the log file (email addresses changed...): INFO | jvm 1| 2007/01/02 20:16:39 | 2007-01-02 20:16:39,831 [pool-1-thread-1] INFO ShellCommandHelper:default - Executing: mvn --b
[jira] Created: (CONTINUUM-1108) Change of Working Directory does not affect existing projects
Change of Working Directory does not affect existing projects - Key: CONTINUUM-1108 URL: http://jira.codehaus.org/browse/CONTINUUM-1108 Project: Continuum Issue Type: Bug Affects Versions: 1.1 Environment: 1.1-SNAPSHOT r490629 Reporter: Wendy Smoak In Configuration, changing the Working Directory does not affect projects already in Continuum. It does take effect for newly added projects. To reproduce: 1. ChooseConfiguration (under Administration, at left) 2. Edit, 3. Change the Working Directory 4. Save 5. Stop Continuum 6. Delete or move the old working copy directory 7. Start Continuum 8. Force a build of any project Now check the old and new working copy directories. Continuum checks out the project in the old directory, not the new one. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MDEP-54) Exclude and Include specific dependencies based on Artifact id or group name
Exclude and Include specific dependencies based on Artifact id or group name Key: MDEP-54 URL: http://jira.codehaus.org/browse/MDEP-54 Project: Maven 2.x Dependency Plugin Issue Type: New Feature Affects Versions: 2.0-alpha-1 Reporter: Chris Love Assigned To: Brian Fox new plugin parameters excludeArtifactId, includeArtifactId, excludeGroupId, includeGroupId comma seperated lists first will implement exact matching laterz will implement regex matching I want too be able too include or exclude specific jars. Sometimes the dependent poms do not setup the scope well. For example I do not want too deploy maven jars! I recommend adding two different filters to match these dependencies. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-1823) unable to synchronize
unable to synchronize - Key: MAVEN-1823 URL: http://jira.codehaus.org/browse/MAVEN-1823 Project: Maven 1.x Issue Type: Bug Components: plugin manager Affects Versions: 1.0.2 Environment: Windows XP, Eclipse SDK maven plugin Reporter: Meera Youn Priority: Minor Fix For: 1.0.2 I am getting this kind of error, when trying to synchronize from maven menu.. (right click on project>maven>synchronize) java.lang.VerifyError: class org.mevenide.ui.eclipse.sync.action.ToggleWritePropertiesAction overrides final method at java.lang.ClassLoader.defineClass0(Native Method) at java.lang.ClassLoader.defineClass(Unknown Source) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.defineClass(DefaultClassLoader.java:160) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.defineClass(ClasspathManager.java:498) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findClassImpl(ClasspathManager.java:468) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClassImpl(ClasspathManager.java:427) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:410) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:188) at org.eclipse.osgi.framework.internal.core.BundleLoader.findLocalClass(BundleLoader.java:339) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:391) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:352) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:83) at java.lang.ClassLoader.loadClass(Unknown Source) at java.lang.ClassLoader.loadClassInternal(Unknown Source) at org.mevenide.ui.eclipse.sync.view.SynchronizationView.createActions(SynchronizationView.java:352) at org.mevenide.ui.eclipse.sync.view.SynchronizationView.createPartControl(SynchronizationView.java:164) at org.eclipse.ui.internal.ViewReference.createPartHelper(ViewReference.java:332) at org.eclipse.ui.internal.ViewReference.createPart(ViewReference.java:197) at org.eclipse.ui.internal.WorkbenchPartReference.getPart(WorkbenchPartReference.java:566) at org.eclipse.ui.internal.Perspective.showView(Perspective.java:1675) at org.eclipse.ui.internal.WorkbenchPage.busyShowView(WorkbenchPage.java:987) at org.eclipse.ui.internal.WorkbenchPage.access$13(WorkbenchPage.java:968) at org.eclipse.ui.internal.WorkbenchPage$13.run(WorkbenchPage.java:3497) at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:67) at org.eclipse.ui.internal.WorkbenchPage.showView(WorkbenchPage.java:3494) at org.eclipse.ui.internal.WorkbenchPage.showView(WorkbenchPage.java:3470) at org.mevenide.ui.eclipse.actions.SynchronizeContainerAction.run(SynchronizeContainerAction.java:47) at org.eclipse.ui.internal.PluginAction.runWithEvent(PluginAction.java:254) at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:539) at org.eclipse.jface.action.ActionContributionItem.access$2(ActionContributionItem.java:488) at org.eclipse.jface.action.ActionContributionItem$5.handleEvent(ActionContributionItem.java:400) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:928) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3348) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2968) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:1914) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:1878) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:419) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) at org.eclipse.ui.internal.ide.IDEApplication.run(IDEApplication.java:95) at org.eclipse.core.internal.runtime.PlatformActivator$1.run(PlatformActivator.java:78) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:92) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:68) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:400) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:177) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang
[jira] Created: (MAVENUPLOAD-1301) JasperReports 1.3.0 upload
JasperReports 1.3.0 upload -- Key: MAVENUPLOAD-1301 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1301 Project: maven-upload-requests Issue Type: Task Reporter: Teodor Danciu http://jasperreports.sourceforge.net/maven/jasperreports-1.3.0-bundle.jar http://sourceforge.net/projects/jasperreports http://sourceforge.net/project/memberlist.php?group_id=36382 Open Source Reporting Engine -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-1300) JasperReports 1.2.8 upload
JasperReports 1.2.8 upload -- Key: MAVENUPLOAD-1300 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1300 Project: maven-upload-requests Issue Type: Task Reporter: Teodor Danciu http://jasperreports.sourceforge.net/maven/jasperreports-1.2.8-bundle.jar http://sourceforge.net/projects/jasperreports http://sourceforge.net/project/memberlist.php?group_id=36382 Open Source Reporting Engine -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-1908) snapshots not deployed using m2, or deployed with uniqueVersion = false are not updated if present locally
[ http://jira.codehaus.org/browse/MNG-1908?page=all ] Brett Porter closed MNG-1908. - Resolution: Fixed fixed, again :) > snapshots not deployed using m2, or deployed with uniqueVersion = false are > not updated if present locally > -- > > Key: MNG-1908 > URL: http://jira.codehaus.org/browse/MNG-1908 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0.1 >Reporter: Guillaume Nodet > Assigned To: Brett Porter >Priority: Blocker > Fix For: 2.0.5 > > Original Estimate: 30 minutes > Time Spent: 2 hours, 30 minutes > Remaining Estimate: 0 minutes > > It seems from the log info that m2 is trying to locate the artifact metadata > on the repository. > SInce this artifact has been generated from m1, there is no metadata. > So whatever repository settings are configured, m2 will never update snapsots. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-1107) Continuum build failes in continuum-core on a clean system
[ http://jira.codehaus.org/browse/CONTINUUM-1107?page=comments#action_83916 ] Roald Bankras commented on CONTINUUM-1107: -- Together with Jesse, I've found out that the test pom (in ...) has version 1.0.3 while the module poms refer to a parent with version 1.1-SNAPSHOT. Besides fixing the version number in these pom files, it's necessary to add an additional test to verify the version numbers of these poms. Hopefully I'll attach the patch before the end of this week > Continuum build failes in continuum-core on a clean system > -- > > Key: CONTINUUM-1107 > URL: http://jira.codehaus.org/browse/CONTINUUM-1107 > Project: Continuum > Issue Type: Bug > Components: Core system >Affects Versions: 1.1 >Reporter: Roald Bankras > Attachments: > org.apache.maven.continuum.project.builder.maven.MavenTwoContinuumProjectBuilderTest.txt > > > MavenTwoContinuumProjectBuilderTest failes twice: -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-2727) Fix Logging in threadsafe components
[ http://jira.codehaus.org/browse/MNG-2727?page=comments#action_83915 ] Jason van Zyl commented on MNG-2727: If it's relavent to the API of the application yes, if you want debug output or general tracing then this falls outside the monitor. Though this is a general problem that would be solved using a more direct use of log4j and it's NDC facilities. > Fix Logging in threadsafe components > > > Key: MNG-2727 > URL: http://jira.codehaus.org/browse/MNG-2727 > Project: Maven 2 > Issue Type: Task > Components: Embedding >Reporter: Jason van Zyl > Assigned To: Jason van Zyl > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-1107) Continuum build failes in continuum-core on a clean system
[ http://jira.codehaus.org/browse/CONTINUUM-1107?page=comments#action_83914 ] Jesse McConnell commented on CONTINUUM-1107: roald wants to get a patch on this with tests in the next week or so, just fyi.. > Continuum build failes in continuum-core on a clean system > -- > > Key: CONTINUUM-1107 > URL: http://jira.codehaus.org/browse/CONTINUUM-1107 > Project: Continuum > Issue Type: Bug > Components: Core system >Affects Versions: 1.1 >Reporter: Roald Bankras > Attachments: > org.apache.maven.continuum.project.builder.maven.MavenTwoContinuumProjectBuilderTest.txt > > > MavenTwoContinuumProjectBuilderTest failes twice: -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-1107) Continuum build failes in continuum-core on a clean system
Continuum build failes in continuum-core on a clean system -- Key: CONTINUUM-1107 URL: http://jira.codehaus.org/browse/CONTINUUM-1107 Project: Continuum Issue Type: Bug Components: Core system Affects Versions: 1.1 Reporter: Roald Bankras Attachments: org.apache.maven.continuum.project.builder.maven.MavenTwoContinuumProjectBuilderTest.txt MavenTwoContinuumProjectBuilderTest failes twice: -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-1106) Could not load class pssAutoLoginInterceptor Error due to missing plexus-ehcache class
[ http://jira.codehaus.org/browse/CONTINUUM-1106?page=comments#action_83911 ] Emmanuel Venisse commented on CONTINUUM-1106: - plexus-ehcache and ehcache jars are in my WEB-INF/lib > Could not load class pssAutoLoginInterceptor Error due to missing > plexus-ehcache class > -- > > Key: CONTINUUM-1106 > URL: http://jira.codehaus.org/browse/CONTINUUM-1106 > Project: Continuum > Issue Type: Bug > Components: Core system >Affects Versions: 1.1 >Reporter: Albert Strasheim > > I just deployed the WAR built from Continuum trunk to my brand new > installation of Apache Tomcat 5.5.20. > I ran into the following problems: > After configuring my app as shown here: > http://svn.apache.org/repos/asf/maven/continuum/trunk/continuum-webapp-test/src/test/tomcat5x/conf/Catalina/localhost/continuum.xml > Tomcat couldn't find Apache Derby. Copying the Derby JAR to common/lib solved > that problem. > Then Tomcat couldn't find a MessagingException from javax.mail. Copying > javax/mail/mail/1.4/mail-1.4.jar from my Maven repository to > webapps/continuum/WEB-INF/lib in my Tomcat directory solved that problem. > Now Tomcat can start Continuum but when I try to access the application, I > get the following error: > Caused by: java.lang.NoClassDefFoundError: > Lorg/codehaus/plexus/ehcache/EhcacheComponent > The JAR for this class (I'm guessing plexus-ehcache-something.jar) doesn't > seem to be in the WEB-INF/lib directory with the rest of the the Continuum > libraries > Complete log: > 1321 [http-8080-Processor23] INFO org.codehaus.plexus.PlexusContainer - > Loading on start [role]: [org.apache.maven.continuum.Continuum] > 1920 [http-8080-Processor23] INFO org.quartz.simpl.RAMJobStore - > RAMJobStore initialized. > 1920 [http-8080-Processor23] INFO org.quartz.impl.StdSchedulerFactory - > Quartz scheduler 'defaultScheduler' initialized from an externally provided > properties instance. > 1921 [http-8080-Processor23] INFO org.quartz.impl.StdSchedulerFactory - > Quartz scheduler version: 1.4.5 > 1921 [http-8080-Processor23] INFO org.quartz.core.QuartzScheduler - > Scheduler defaultScheduler_$_NON_CLUSTERED started. > 1969 [http-8080-Processor23] WARN > org.apache.maven.continuum.execution.ContinuumBuildExecutor:ant - Could not > find the executable 'ant' in the path '[]'. > 1975 [http-8080-Processor23] WARN > org.apache.maven.continuum.execution.ContinuumBuildExecutor:maven-1 - Could > not find the executable 'maven' in the path '[]'. > 2206 [http-8080-Processor23] DEBUG > org.apache.maven.settings.MavenSettingsBuilder - Building Maven global-level > settings from: '/opt/apache-tomcat-5.5.20/bin/null/conf/settings.xml' > 2206 [http-8080-Processor23] DEBUG > org.apache.maven.settings.MavenSettingsBuilder - Building Maven user-level > settings from: '/root/.m2/settings.xml' > 2298 [http-8080-Processor23] WARN > org.apache.maven.continuum.execution.ContinuumBuildExecutor:maven2 - Could > not find the executable 'mvn' in the path '[]'. > 2300 [http-8080-Processor23] INFO > org.apache.maven.continuum.execution.manager.BuildExecutorManager - Build > executors: > 2301 [http-8080-Processor23] INFO > org.apache.maven.continuum.execution.manager.BuildExecutorManager - maven-1 > 2301 [http-8080-Processor23] INFO > org.apache.maven.continuum.execution.manager.BuildExecutorManager - ant > 2301 [http-8080-Processor23] INFO > org.apache.maven.continuum.execution.manager.BuildExecutorManager - maven2 > 2301 [http-8080-Processor23] INFO > org.apache.maven.continuum.execution.manager.BuildExecutorManager - shell > 2803 [http-8080-Processor23] INFO org.apache.maven.continuum.Continuum - > Initializing Continuum. > 2803 [http-8080-Processor23] INFO org.apache.maven.continuum.Continuum - > Showing all projects: > 4175 [http-8080-Processor23] INFO org.apache.maven.continuum.Continuum - > Starting Continuum. > 4176 [http-8080-Processor23] INFO org.apache.maven.continuum.Continuum - > 4176 [http-8080-Processor23] INFO org.apache.maven.continuum.Continuum - > 4176 [http-8080-Processor23] INFO org.apache.maven.continuum.Continuum - < > Continuum 1.1-SNAPSHOT started! > > 4177 [http-8080-Processor23] INFO org.apache.maven.continuum.Continuum - > --- > 4177 [http-8080-Processor23] INFO org.apache.maven.continuum.Continuum - > \ ^__^ > 4177 [http-8080-Processor23] INFO org.apache.maven.continuum.Continuum - > \ (oo)\___ > 4177 [http-8080-Processor23] INFO org.apache.maven.continuum.Continuum - > (__)\ )\/\ > 4177 [http-8080-Processor23] INFO org.apache.maven.continuum.Continuum - > ||w | > 4177 [http-8080-Processor23] INFO org.apache.maven.continuum.Con
[jira] Commented: (CONTINUUM-1106) Could not load class pssAutoLoginInterceptor Error due to missing plexus-ehcache class
[ http://jira.codehaus.org/browse/CONTINUUM-1106?page=comments#action_83910 ] Albert Strasheim commented on CONTINUUM-1106: - After copying the JAR from http://snapshots.repository.codehaus.org/org/codehaus/plexus/plexus-ehcache/1.0-SNAPSHOT/ and the Ehcache jar from sourceforge to my WEB-INF/lib directory, I get to the admin account creation page. > Could not load class pssAutoLoginInterceptor Error due to missing > plexus-ehcache class > -- > > Key: CONTINUUM-1106 > URL: http://jira.codehaus.org/browse/CONTINUUM-1106 > Project: Continuum > Issue Type: Bug > Components: Core system >Affects Versions: 1.1 >Reporter: Albert Strasheim > > I just deployed the WAR built from Continuum trunk to my brand new > installation of Apache Tomcat 5.5.20. > I ran into the following problems: > After configuring my app as shown here: > http://svn.apache.org/repos/asf/maven/continuum/trunk/continuum-webapp-test/src/test/tomcat5x/conf/Catalina/localhost/continuum.xml > Tomcat couldn't find Apache Derby. Copying the Derby JAR to common/lib solved > that problem. > Then Tomcat couldn't find a MessagingException from javax.mail. Copying > javax/mail/mail/1.4/mail-1.4.jar from my Maven repository to > webapps/continuum/WEB-INF/lib in my Tomcat directory solved that problem. > Now Tomcat can start Continuum but when I try to access the application, I > get the following error: > Caused by: java.lang.NoClassDefFoundError: > Lorg/codehaus/plexus/ehcache/EhcacheComponent > The JAR for this class (I'm guessing plexus-ehcache-something.jar) doesn't > seem to be in the WEB-INF/lib directory with the rest of the the Continuum > libraries > Complete log: > 1321 [http-8080-Processor23] INFO org.codehaus.plexus.PlexusContainer - > Loading on start [role]: [org.apache.maven.continuum.Continuum] > 1920 [http-8080-Processor23] INFO org.quartz.simpl.RAMJobStore - > RAMJobStore initialized. > 1920 [http-8080-Processor23] INFO org.quartz.impl.StdSchedulerFactory - > Quartz scheduler 'defaultScheduler' initialized from an externally provided > properties instance. > 1921 [http-8080-Processor23] INFO org.quartz.impl.StdSchedulerFactory - > Quartz scheduler version: 1.4.5 > 1921 [http-8080-Processor23] INFO org.quartz.core.QuartzScheduler - > Scheduler defaultScheduler_$_NON_CLUSTERED started. > 1969 [http-8080-Processor23] WARN > org.apache.maven.continuum.execution.ContinuumBuildExecutor:ant - Could not > find the executable 'ant' in the path '[]'. > 1975 [http-8080-Processor23] WARN > org.apache.maven.continuum.execution.ContinuumBuildExecutor:maven-1 - Could > not find the executable 'maven' in the path '[]'. > 2206 [http-8080-Processor23] DEBUG > org.apache.maven.settings.MavenSettingsBuilder - Building Maven global-level > settings from: '/opt/apache-tomcat-5.5.20/bin/null/conf/settings.xml' > 2206 [http-8080-Processor23] DEBUG > org.apache.maven.settings.MavenSettingsBuilder - Building Maven user-level > settings from: '/root/.m2/settings.xml' > 2298 [http-8080-Processor23] WARN > org.apache.maven.continuum.execution.ContinuumBuildExecutor:maven2 - Could > not find the executable 'mvn' in the path '[]'. > 2300 [http-8080-Processor23] INFO > org.apache.maven.continuum.execution.manager.BuildExecutorManager - Build > executors: > 2301 [http-8080-Processor23] INFO > org.apache.maven.continuum.execution.manager.BuildExecutorManager - maven-1 > 2301 [http-8080-Processor23] INFO > org.apache.maven.continuum.execution.manager.BuildExecutorManager - ant > 2301 [http-8080-Processor23] INFO > org.apache.maven.continuum.execution.manager.BuildExecutorManager - maven2 > 2301 [http-8080-Processor23] INFO > org.apache.maven.continuum.execution.manager.BuildExecutorManager - shell > 2803 [http-8080-Processor23] INFO org.apache.maven.continuum.Continuum - > Initializing Continuum. > 2803 [http-8080-Processor23] INFO org.apache.maven.continuum.Continuum - > Showing all projects: > 4175 [http-8080-Processor23] INFO org.apache.maven.continuum.Continuum - > Starting Continuum. > 4176 [http-8080-Processor23] INFO org.apache.maven.continuum.Continuum - > 4176 [http-8080-Processor23] INFO org.apache.maven.continuum.Continuum - > 4176 [http-8080-Processor23] INFO org.apache.maven.continuum.Continuum - < > Continuum 1.1-SNAPSHOT started! > > 4177 [http-8080-Processor23] INFO org.apache.maven.continuum.Continuum - > --- > 4177 [http-8080-Processor23] INFO org.apache.maven.continuum.Continuum - > \ ^__^ > 4177 [http-8080-Processor23] INFO org.apache.maven.continuum.Continuum - > \ (oo)\___ > 4177 [http-8080-Processor23] INFO org.apache.maven.continuum.Continuum - > (__)\ )\
[jira] Created: (CONTINUUM-1106) Could not load class pssAutoLoginInterceptor Error due to missing plexus-ehcache class
Could not load class pssAutoLoginInterceptor Error due to missing plexus-ehcache class -- Key: CONTINUUM-1106 URL: http://jira.codehaus.org/browse/CONTINUUM-1106 Project: Continuum Issue Type: Bug Components: Core system Affects Versions: 1.1 Reporter: Albert Strasheim I just deployed the WAR built from Continuum trunk to my brand new installation of Apache Tomcat 5.5.20. I ran into the following problems: After configuring my app as shown here: http://svn.apache.org/repos/asf/maven/continuum/trunk/continuum-webapp-test/src/test/tomcat5x/conf/Catalina/localhost/continuum.xml Tomcat couldn't find Apache Derby. Copying the Derby JAR to common/lib solved that problem. Then Tomcat couldn't find a MessagingException from javax.mail. Copying javax/mail/mail/1.4/mail-1.4.jar from my Maven repository to webapps/continuum/WEB-INF/lib in my Tomcat directory solved that problem. Now Tomcat can start Continuum but when I try to access the application, I get the following error: Caused by: java.lang.NoClassDefFoundError: Lorg/codehaus/plexus/ehcache/EhcacheComponent The JAR for this class (I'm guessing plexus-ehcache-something.jar) doesn't seem to be in the WEB-INF/lib directory with the rest of the the Continuum libraries Complete log: 1321 [http-8080-Processor23] INFO org.codehaus.plexus.PlexusContainer - Loading on start [role]: [org.apache.maven.continuum.Continuum] 1920 [http-8080-Processor23] INFO org.quartz.simpl.RAMJobStore - RAMJobStore initialized. 1920 [http-8080-Processor23] INFO org.quartz.impl.StdSchedulerFactory - Quartz scheduler 'defaultScheduler' initialized from an externally provided properties instance. 1921 [http-8080-Processor23] INFO org.quartz.impl.StdSchedulerFactory - Quartz scheduler version: 1.4.5 1921 [http-8080-Processor23] INFO org.quartz.core.QuartzScheduler - Scheduler defaultScheduler_$_NON_CLUSTERED started. 1969 [http-8080-Processor23] WARN org.apache.maven.continuum.execution.ContinuumBuildExecutor:ant - Could not find the executable 'ant' in the path '[]'. 1975 [http-8080-Processor23] WARN org.apache.maven.continuum.execution.ContinuumBuildExecutor:maven-1 - Could not find the executable 'maven' in the path '[]'. 2206 [http-8080-Processor23] DEBUG org.apache.maven.settings.MavenSettingsBuilder - Building Maven global-level settings from: '/opt/apache-tomcat-5.5.20/bin/null/conf/settings.xml' 2206 [http-8080-Processor23] DEBUG org.apache.maven.settings.MavenSettingsBuilder - Building Maven user-level settings from: '/root/.m2/settings.xml' 2298 [http-8080-Processor23] WARN org.apache.maven.continuum.execution.ContinuumBuildExecutor:maven2 - Could not find the executable 'mvn' in the path '[]'. 2300 [http-8080-Processor23] INFO org.apache.maven.continuum.execution.manager.BuildExecutorManager - Build executors: 2301 [http-8080-Processor23] INFO org.apache.maven.continuum.execution.manager.BuildExecutorManager - maven-1 2301 [http-8080-Processor23] INFO org.apache.maven.continuum.execution.manager.BuildExecutorManager - ant 2301 [http-8080-Processor23] INFO org.apache.maven.continuum.execution.manager.BuildExecutorManager - maven2 2301 [http-8080-Processor23] INFO org.apache.maven.continuum.execution.manager.BuildExecutorManager - shell 2803 [http-8080-Processor23] INFO org.apache.maven.continuum.Continuum - Initializing Continuum. 2803 [http-8080-Processor23] INFO org.apache.maven.continuum.Continuum - Showing all projects: 4175 [http-8080-Processor23] INFO org.apache.maven.continuum.Continuum - Starting Continuum. 4176 [http-8080-Processor23] INFO org.apache.maven.continuum.Continuum - 4176 [http-8080-Processor23] INFO org.apache.maven.continuum.Continuum - 4176 [http-8080-Processor23] INFO org.apache.maven.continuum.Continuum - < Continuum 1.1-SNAPSHOT started! > 4177 [http-8080-Processor23] INFO org.apache.maven.continuum.Continuum - --- 4177 [http-8080-Processor23] INFO org.apache.maven.continuum.Continuum - \ ^__^ 4177 [http-8080-Processor23] INFO org.apache.maven.continuum.Continuum - \ (oo)\___ 4177 [http-8080-Processor23] INFO org.apache.maven.continuum.Continuum - (__)\ )\/\ 4177 [http-8080-Processor23] INFO org.apache.maven.continuum.Continuum - ||w | 4177 [http-8080-Processor23] INFO org.apache.maven.continuum.Continuum - || || 4177 [http-8080-Processor23] INFO org.apache.maven.continuum.Continuum - 4177 [http-8080-Processor23] INFO org.apache.maven.continuum.Continuum - 4177 [http-8080-Processor23] INFO org.apache.maven.continuum.initialization.ContinuumInitializer:default - Continuum initializer running ... 4269 [http-8080-Processor23] INFO org.apache.maven.continuum.build.
[jira] Created: (MEV-481) Wrong artifact name for groovy-sources in maven repo
Wrong artifact name for groovy-sources in maven repo Key: MEV-481 URL: http://jira.codehaus.org/browse/MEV-481 Project: Maven Evangelism Issue Type: Bug Reporter: nicolas de loof in http://repo1.maven.org/maven2/groovy/groovy/1.0-jsr-06/ the sources jar has a typo and is set to "grrovy" -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MDEP-53) Meaningless error message: "Error transferring file"
Meaningless error message: "Error transferring file" Key: MDEP-53 URL: http://jira.codehaus.org/browse/MDEP-53 Project: Maven 2.x Dependency Plugin Issue Type: Bug Reporter: Graham Leggett Assigned To: Brian Fox When an attempt is made to resolve dependencies, the following error is encountered: [INFO] artifact org.apache.maven.plugins:maven-resources-plugin: checking for updates from codehaus-mojo-snapshot-plugins [WARNING] repository metadata for: 'artifact org.apache.maven.plugins:maven-resources-plugin' could not be retrieved from repository: codehaus-mojo-snapshot-plugins due to an error: Error transferring file [INFO] Repository 'codehaus-mojo-snapshot-plugins' will be blacklisted Without further information, debugging this problem is impractical. Information needed in the error message: - Whether or not a proxy is being used, and if so, which one. (Symptoms in this case indicate no proxy is being used, yet a proxy is configured - no way to tell whether its a config problem or a proxy problem) - Whether the server and/or proxy server gave an error code (4xx, 5xx), or whether there was no response at 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] Commented: (MRM-243) 507 Insufficient Storage when deploying artifact with webdav
[ http://jira.codehaus.org/browse/MRM-243?page=comments#action_83898 ] Chris Wewerka commented on MRM-243: --- We have the same problem in the following environment: Client Side : mvn 2.0.4, slide 2.1, wagon-webdav-1.0-beta-2 Archiva Side: Java 1.5.0_10, Tomcat 5.5.20 > 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 > > > 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] Created: (MEV-480) geronimo-spec-* groupdid should be geronimo-spec in the db-ojb pom.xml and has wrong artifactId
geronimo-spec-* groupdid should be geronimo-spec in the db-ojb pom.xml and has wrong artifactId --- Key: MEV-480 URL: http://jira.codehaus.org/browse/MEV-480 Project: Maven Evangelism Issue Type: Bug Components: Dependencies Reporter: Mikko Wuokko In the pom file the geronimo-spec dependencies are defined like this: geronimo-spec-j2ee geronimo-spec-j2ee 1.4-rc4 geronimo-spec-jta geronimo-spec-jta 1.0.1B-rc4 geronimo-spec-servlet geronimo-spec-servlet 2.4-rc4 The groupId should be just geronimo-spec for all of them. AFAIK that is the groupId used in all the Maven2 repos I found. And also in the pom file the artifactId is ojb and it should be db-ojb instead. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MDEPLOY-45) Classifier not supported by deploy:deploy
[ http://jira.codehaus.org/browse/MDEPLOY-45?page=all ] Fabian Bauschulte updated MDEPLOY-45: - Attachment: MDEPLOY-45-maven-deploy-plugin.patch Fixed analog maven-install-plugin > Classifier not supported by deploy:deploy > - > > Key: MDEPLOY-45 > URL: http://jira.codehaus.org/browse/MDEPLOY-45 > Project: Maven 2.x Deploy Plugin > Issue Type: Bug >Affects Versions: 2.3 >Reporter: Fabian Bauschulte >Priority: Critical > Attachments: MDEPLOY-45-maven-deploy-plugin.patch > > > I am using classifieres in some projects (jar, war, ear) and installing the > artefacts works fine. I am getting an Exception during the deployment of the > artifacts. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-45) Classifier not supported by deploy:deploy
Classifier not supported by deploy:deploy - Key: MDEPLOY-45 URL: http://jira.codehaus.org/browse/MDEPLOY-45 Project: Maven 2.x Deploy Plugin Issue Type: Bug Affects Versions: 2.3 Reporter: Fabian Bauschulte Priority: Critical I am using classifieres in some projects (jar, war, ear) and installing the artefacts works fine. I am getting an Exception during the deployment of the artifacts. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Work started: (MNG-1908) snapshots not deployed using m2, or deployed with uniqueVersion = false are not updated if present locally
[ http://jira.codehaus.org/browse/MNG-1908?page=all ] Work on MNG-1908 started by Brett Porter. > snapshots not deployed using m2, or deployed with uniqueVersion = false are > not updated if present locally > -- > > Key: MNG-1908 > URL: http://jira.codehaus.org/browse/MNG-1908 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0.1 >Reporter: Guillaume Nodet > Assigned To: Brett Porter >Priority: Blocker > Fix For: 2.0.5 > > Original Estimate: 30 minutes > Time Spent: 2 hours, 30 minutes > Remaining Estimate: 0 minutes > > It seems from the log info that m2 is trying to locate the artifact metadata > on the repository. > SInce this artifact has been generated from m1, there is no metadata. > So whatever repository settings are configured, m2 will never update snapsots. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MEAR-54) module exclusion example is wrong
module exclusion example is wrong - Key: MEAR-54 URL: http://jira.codehaus.org/browse/MEAR-54 Project: Maven 2.x Ear Plugin Issue Type: Task Affects Versions: 2.3 Reporter: Stephane Nicoll Assigned To: Stephane Nicoll Fix For: 2.3.1 http://maven.apache.org/plugins/maven-ear-plugin/examples/excluding-a-module.html specifies warModule instead of webModule. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-1098) Cannot upload a Maven 2 Project with modules
[ http://jira.codehaus.org/browse/CONTINUUM-1098?page=comments#action_83895 ] Franz Allan Valencia See commented on CONTINUUM-1098: - Good day to you, Emmanuel, I see. So I guess this no-duplice-project rule applies not only to the uploading of m2 project (with submodules) but to other tasks as well ( such as manually adding a project that already exists, moving to a group where that project already exists, etc). Did I get that right? Also, will this rule will apply to m1, ant, and shell project as well? And what would be the definition of a project duplicate? For M2, would it be if two projects have the same artifact key and belong to the same project group? Or will we included packaging? ..And what about for the other project types? Maybe this deserves an issue of its own :-) If so, maybe this issue can progress on its own and we'll just add the no-duplicate-project mechanism later on when its finish. WDYT? Cheers, Franz > Cannot upload a Maven 2 Project with modules > > > Key: CONTINUUM-1098 > URL: http://jira.codehaus.org/browse/CONTINUUM-1098 > Project: Continuum > Issue Type: Improvement > Components: Core system, Web interface, Web - UI >Affects Versions: 1.1 > Environment: -r490655 >Reporter: Franz Allan Valencia See > Attachments: error logs.txt, error page.JPG > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-2727) Fix Logging in threadsafe components
[ http://jira.codehaus.org/browse/MNG-2727?page=comments#action_83894 ] Trygve Laugstol commented on MNG-2727: -- Shouldn't the component use a monitor instead of logging in the cases where the output is useful on a per-build basis? > Fix Logging in threadsafe components > > > Key: MNG-2727 > URL: http://jira.codehaus.org/browse/MNG-2727 > Project: Maven 2 > Issue Type: Task > Components: Embedding >Reporter: Jason van Zyl > Assigned To: Jason van Zyl > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (MNG-1908) snapshots not deployed using m2, or deployed with uniqueVersion = false are not updated if present locally
[ http://jira.codehaus.org/browse/MNG-1908?page=all ] Brett Porter reopened MNG-1908: --- the current fix has resulted in a regression in the release update functionality. Another IT is in order. > snapshots not deployed using m2, or deployed with uniqueVersion = false are > not updated if present locally > -- > > Key: MNG-1908 > URL: http://jira.codehaus.org/browse/MNG-1908 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0.1 >Reporter: Guillaume Nodet > Assigned To: Brett Porter >Priority: Blocker > Fix For: 2.0.5 > > Original Estimate: 30 minutes > Time Spent: 2 hours, 30 minutes > Remaining Estimate: 0 minutes > > It seems from the log info that m2 is trying to locate the artifact metadata > on the repository. > SInce this artifact has been generated from m1, there is no metadata. > So whatever repository settings are configured, m2 will never update snapsots. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-2601) mvn -U does NOT update/download the latest SNAPSHOT version
[ http://jira.codehaus.org/browse/MNG-2601?page=all ] Brett Porter closed MNG-2601. - Assignee: Brett Porter Resolution: Duplicate > mvn -U does NOT update/download the latest SNAPSHOT version > --- > > Key: MNG-2601 > URL: http://jira.codehaus.org/browse/MNG-2601 > Project: Maven 2 > Issue Type: Bug > Components: Command Line >Affects Versions: 2.0.4 >Reporter: Jimisola Laursen > Assigned To: Brett Porter >Priority: Critical > > I stumbled on this issue (again) with a new snapshot release of Apache's > XMLRPC library (3.1-SNAPSHOT). > For background information see here: > http://www.nabble.com/3.1-SNAPHOT-tf2411158.html > The bug is that mvn -U doesn't download the new 3.1-SNAPSHOT version when > there is one. I had (actually we as in our team) manually have to delete the > existing 3.1-SNAPSHOT in my local repository. > The xmlrpc library consists of three modules (common, server and client) this > problems applies to all three but I've make an example using the server > modules. > It can be found here: > http://people.apache.org/maven-snapshot-repository/org/apache/xmlrpc/xmlrpc-server/3.1-SNAPSHOT/ > The SNAPSHOTs generated does not use uniqueVersion (and filenames are hence > not created with a timestamp). Is that necessary for mvn -U to work? > If that is the case then > 1) this needs to be documented better. It is NOT how one expects it to work. > As a user I don't care how the SNAPSHOT was deployed - just that it is there. > 2) one should be able to force mvn to RE-download all SNAPSHOT (don't check > for update or anything just download). perhaps mvn -F (force redownload of > snapshots) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
