[jira] (MDEP-360) Allow using folder as dependency:get destination parameter
[ https://jira.codehaus.org/browse/MDEP-360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kalle Korhonen updated MDEP-360: Attachment: MDEP-360.patch A patch with a test, although I couldn't run it successfully as I was hitting MDEP-353 > Allow using folder as dependency:get destination parameter > -- > > Key: MDEP-360 > URL: https://jira.codehaus.org/browse/MDEP-360 > Project: Maven 2.x Dependency Plugin > Issue Type: Improvement > Components: get >Affects Versions: 2.4 >Reporter: Kalle Korhonen > Attachments: MDEP-360.patch > > > Currently the plugin rejects destination that is referring to a folder but > there's no reason to require a file only. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MDEP-360) Allow using folder as dependency:get destination parameter
Kalle Korhonen created MDEP-360: --- Summary: Allow using folder as dependency:get destination parameter Key: MDEP-360 URL: https://jira.codehaus.org/browse/MDEP-360 Project: Maven 2.x Dependency Plugin Issue Type: Improvement Components: get Affects Versions: 2.4 Reporter: Kalle Korhonen Currently the plugin rejects destination that is referring to a folder but there's no reason to require a file only. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MEV-649) log4j 1.2.15 points to nonfuctional maven-repository.dev.java.net packages breaking whole build
[ http://jira.codehaus.org/browse/MEV-649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=209847#action_209847 ] Kalle Korhonen commented on MEV-649: I had filed https://issues.apache.org/bugzilla/show_bug.cgi?id=48216 to mark the optional log4j dependencies as optional (but status is still NEW) > log4j 1.2.15 points to nonfuctional maven-repository.dev.java.net packages > breaking whole build > --- > > Key: MEV-649 > URL: http://jira.codehaus.org/browse/MEV-649 > Project: Maven Evangelism > Issue Type: Bug >Reporter: Jan Uhlir >Assignee: Carlos Sanchez > > Log4j 2.1.15 dependency from central repository has dependencies linked to > https://maven-repository.dev.java.net/nonav/repository - jmxri, jmxtools and > java mail (and others?). These denpendencies are broken or the whole external > repository is unaccesible by now. > Is it even permitted to have "external" dependency for a package in central > repository? > I found it hard to find how to disable a repository (block a repository) so I > am using this opportunity for a micro how to for unlucky ones like me. > Troubled dependency definition: > > log4j > log4j > 1.2.15 > > Error log (shortened) -- > [INFO] Scanning for projects... > ... > [INFO] Copying 1 resource > Downloading: > https://maven-repository.dev.java.net/nonav/repository/com.sun.jmx/jars/jmxri-1.2.1.jar > Downloading: > https://maven-repository.dev.java.net/nonav/repository/com.sun.jdmk/jars/jmxtools-1.2.1.jar > 353/353b > 353b downloaded (jmxri-1.2.1.jar) > 357/357b > 357b downloaded (jmxtools-1.2.1.jar) > [WARNING] *** CHECKSUM FAILED - Checksum failed on download: local = > 'a55ce8e95c9bb027e78557acc9e2b973fe3c611e'; remote = ' Downloading: > https://maven-repository.dev.java.net/nonav/repository/com.sun.jmx/jars/jmxri-1.2.1.jar > 353/353b > 353b downloaded (jmxri-1.2.1.jar) > [WARNING] [WARNING] *** CHECKSUM FAILED - Checksum failed on download: local > = 'a55ce8e95c9bb027e78557acc9e2b973fe3c611e'; remote = ' *** CHECKSUM FAILED - Checksum failed on download: local = > '9e1dae7682d2b60d5b17b7d47e20d99d70ba65cf'; remote = ' Downloading: > https://maven-repository.dev.java.net/nonav/repository/com.sun.jdmk/jars/jmxtools-1.2.1.jar > 357/357b > 357b downloaded (jmxtools-1.2.1.jar) > [WARNING] *** CHECKSUM FAILED - Checksum failed on download: local = > '9e1dae7682d2b60d5b17b7d47e20d99d70ba65cf'; remote = ' ... > [INFO] Compilation failure > ... > error: error reading > /opt/javalibs/com/sun/jdmk/jmxtools/1.2.1/jmxtools-1.2.1.jar; error in > opening zip file > error: error reading /opt/javalibs/com/sun/jmx/jmxri/1.2.1/jmxri-1.2.1.jar; > error in opening zip file > Solution (1) - Disable repository (settings.xml). > Note, it is much more tricky that it seems to be! It gave me hard time before > I found out. Documentation should be improved here. > 1) Tricky, you have to do it for releases and snapshots. There is no > repository wide disabling option. > 2) You have to provide not just same (failing) repository URL but more > importantly the same repository ID as it is in ill referencig POM (log4j > 2.1.15 in our case) > 3) Blacklisting repository is something completely different then disabling. > Not usable in this case (?). It is not ad hoc settable by user anyway > OK, here is the code: > > default > ... > > > java.net > > > https://maven-repository.dev.java.net/nonav/repository > > false > > > false > > > > > Solution (2) - exclude the "external" sub-dependencies of log4j 2.1.15, like > jmxri, jmxtools and java mail. And perhaps others. It takes more time to > figure out what else "external". > Solution (3) - the best one. Use version log4j 2.1.14 instead. It seems to be > 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: (ARCHETYPE-242) The "remote" archchetype-catalog doesn't really exist.
[ http://jira.codehaus.org/browse/ARCHETYPE-242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=205962#action_205962 ] Kalle Korhonen commented on ARCHETYPE-242: -- Brilliant Raphaël, thanks for the tip! > The "remote" archchetype-catalog doesn't really exist. > -- > > Key: ARCHETYPE-242 > URL: http://jira.codehaus.org/browse/ARCHETYPE-242 > Project: Maven Archetype > Issue Type: Bug >Reporter: Jörg Henne >Priority: Minor > > This page > http://maven.apache.org/plugins/maven-archetype-plugin/specification/archetype-catalog.html > states that the default "remote" catalog is located at > http://repo1.maven.org/maven2/archetype-catalog.xml. However, there is no > such file on repo1.maven.org and thus the remote catalog is useless. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (ARCHETYPE-242) The "remote" archchetype-catalog doesn't really exist.
[ http://jira.codehaus.org/browse/ARCHETYPE-242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=204898#action_204898 ] Kalle Korhonen commented on ARCHETYPE-242: -- Agree with Stevo, it's still pretty badly broken. MRM doesn't help much if you want to make your archetype available publicly to other users like many open source projects do. There was a discussion about this on Maven users list (http://markmail.org/message/remgjzpl2kdrd7ph?q=+Error+reading+archetype+catalog+http://repo1.maven.org/maven2&page=1&refer=2cb3yjsdlzym52vb) almost a year ago noting that repo1/repo2 should either just run archetype:crawl periodically or Sonatype's Nexus should push the catalog to repo1 but I don't know if either effort has gone anywhere. Considering archetype:create is already deprecated I think this is more than a minor issue. Right now, is there any better workaround than lobby archetype maintainers to include your archetype in the new version of archetype plugin? > The "remote" archchetype-catalog doesn't really exist. > -- > > Key: ARCHETYPE-242 > URL: http://jira.codehaus.org/browse/ARCHETYPE-242 > Project: Maven Archetype > Issue Type: Bug >Reporter: Jörg Henne >Priority: Minor > > This page > http://maven.apache.org/plugins/maven-archetype-plugin/specification/archetype-catalog.html > states that the default "remote" catalog is located at > http://repo1.maven.org/maven2/archetype-catalog.xml. However, there is no > such file on repo1.maven.org and thus the remote catalog is useless. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (SCM-406) scm tag does not work with Subversion 1.5.1
[
http://jira.codehaus.org/browse/SCM-406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=155565#action_155565
]
Kalle Korhonen commented on SCM-406:
Agree, still a problem in svn 1.5.4, sorry for the noise. Only one of our
project succeeded a release without issues because of a funny side effect of
using the buildnumber plugin - it does svn update as part of the build (if
configured so); which as other have pointed out, you can do manually as well to
continue release:prepare after it fails the first time.
> scm tag does not work with Subversion 1.5.1
> ---
>
> Key: SCM-406
> URL: http://jira.codehaus.org/browse/SCM-406
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-svn
>Affects Versions: 1.0
>Reporter: James William Dumay
> Fix For: 1.1.1
>
>
> scm:checkin does not work with Subversion 1.5.1
> On release:perform (which I assume calls scm:checkin) the following error
> occurs:
> {code}
> svn: File
> '/svn/private/atlassian/confluence/tags/confluence-project-2.10-m1/conf-acceptance-test/pom.xml'
> already exists
> {code}
> Using subversion 1.4.x is a good enough workaround.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (SCM-406) scm tag does not work with Subversion 1.5.1
[
http://jira.codehaus.org/browse/SCM-406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=155004#action_155004
]
Kalle Korhonen commented on SCM-406:
Try together with release plugin 2.0-beta-8 - though I'm now seeing some
oddities, need to verify it's not a user error when I release our project the
next time (in a week)
> scm tag does not work with Subversion 1.5.1
> ---
>
> Key: SCM-406
> URL: http://jira.codehaus.org/browse/SCM-406
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-svn
>Affects Versions: 1.0
>Reporter: James William Dumay
> Fix For: 1.1.1
>
>
> scm:checkin does not work with Subversion 1.5.1
> On release:perform (which I assume calls scm:checkin) the following error
> occurs:
> {code}
> svn: File
> '/svn/private/atlassian/confluence/tags/confluence-project-2.10-m1/conf-acceptance-test/pom.xml'
> already exists
> {code}
> Using subversion 1.4.x is a good enough workaround.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (SCM-406) scm tag does not work with Subversion 1.5.1
[
http://jira.codehaus.org/browse/SCM-406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=153836#action_153836
]
Kalle Korhonen commented on SCM-406:
Upgrading to svn 1.5.4 fixes the issue
> scm tag does not work with Subversion 1.5.1
> ---
>
> Key: SCM-406
> URL: http://jira.codehaus.org/browse/SCM-406
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-svn
>Affects Versions: 1.0
>Reporter: James William Dumay
> Fix For: 1.1.1
>
>
> scm:checkin does not work with Subversion 1.5.1
> On release:perform (which I assume calls scm:checkin) the following error
> occurs:
> {code}
> svn: File
> '/svn/private/atlassian/confluence/tags/confluence-project-2.10-m1/conf-acceptance-test/pom.xml'
> already exists
> {code}
> Using subversion 1.4.x is a good enough workaround.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-326) Doens't resolve multiproject dependencies properly
[ http://jira.codehaus.org/browse/MRELEASE-326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=139211#action_139211 ] Kalle Korhonen commented on MRELEASE-326: - This is the documented behavior of the release plugin right? By default, release:prepare doesn't run install goal. If you need it, you can configure it to run "clean install" as instructed at http://maven.apache.org/plugins/maven-release-plugin/examples/run-goals-before-commit.html > Doens't resolve multiproject dependencies properly > --- > > Key: MRELEASE-326 > URL: http://jira.codehaus.org/browse/MRELEASE-326 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-7 > Environment: Windows, JDK 1.6, Maven 2.08 >Reporter: Kuno Baeriswyl > Attachments: Stacktrace_release-plugin.txt > > > I'd try to make a release:prepare from a multiproject: > A (Multiproject POM) > B (Core Interfaces) > C (Component) > D (Core Impl) > E (Standalone Client) > F (EJB) > G (Client) > A is the parent project and contains the other project from B to G. Following > dependencies are defined : G -> F -> D -> B -> A > However, when it comes to build the Artifact G, the release plugin aborts, > because of missing Artifact F. But it's part of the Multiproject and was just > build before. The release plugin checks the remote repository for an existing > version. Which is non-sense, since I'm actually try to buld it right now... > Since the release plugin has already changed the pom from Snapshot to stable > version labels. I can now do "mvn install" and the missing Artefact will be > installed. And the second run of mvn release:prepare will succeed! Though, I > don't like this workaround and hope this can be fixed. > Thanks > Kuno -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRELEASE-333) allowTimestampedSnapshots is not applied to report plugins
allowTimestampedSnapshots is not applied to report plugins -- Key: MRELEASE-333 URL: http://jira.codehaus.org/browse/MRELEASE-333 Project: Maven 2.x Release Plugin Issue Type: Bug Affects Versions: 2.0-beta-7 Environment: Any Reporter: Kalle Korhonen Related to already resolved MRELEASE-124. allowTimestampedSnapshots make it possible to force a release with uniquely versioned snapshots as dependencies, but the parameter has no effect on report snapshots dependencies. Looking at the code in the patch it seems the parameter is only applied to straight-up project dependencies. If you are forced to use reports that are only available as snapshots (currently e.g. the dashboard plugin), you are out of luck unless you deploy custom versions of the plugin in your internal repository or disable the reports for the release. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MDEPLOY-44) Add uniqueVersion parameter to deploy goal as deploy-file goal
[ http://jira.codehaus.org/browse/MDEPLOY-44?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_114948 ] Kalle Korhonen commented on MDEPLOY-44: --- As a workaround, you can set uniqueVersion to false in distributionManagement section of your pom, e.g: my-repo My Internal Repository scp://my-repo.com/repo false But, it'd be very useful if you could override uniqueVersion setting from the command line. > Add uniqueVersion parameter to deploy goal as deploy-file goal > -- > > Key: MDEPLOY-44 > URL: http://jira.codehaus.org/browse/MDEPLOY-44 > Project: Maven 2.x Deploy Plugin > Issue Type: Improvement >Affects Versions: 2.2.1 > Environment: Maven 2.0.4 >Reporter: David Vicente > > We developp a big application which we deploy in our local repository with > deploy goal. > But deploy goal use a timestamp to name the archive file and we have many > problems of disk space that obliges us to clean manually our local repository. > it's possible to add the uniqueVersion parameter to deploy goal as done with > deploy-file goal which would remove us the obligation to purge ? > thanks -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-125) add mojo for creating a source bundle
[ http://jira.codehaus.org/browse/MASSEMBLY-125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106605 ] Kalle Korhonen commented on MASSEMBLY-125: -- Agree, assembly should have a support for classifiers. My use case is creating a user-downloadable distro that should contain *-sources.jars and javadoc.jars. Currently using dependencies:copy-dependencies to fetch all dependencies (it doesn't have an includes/excludes), then using fileSets in an assembly to package a few of them selectively into the distro. Would be much cleaner if I could use classifiers with a dependencySet. > add mojo for creating a source bundle > - > > Key: MASSEMBLY-125 > URL: http://jira.codehaus.org/browse/MASSEMBLY-125 > Project: Maven 2.x Assembly Plugin > Issue Type: New Feature >Reporter: Ovidio Mallo > Fix For: 2.2-beta-2 > > > I think it would be nice to have some mojo "source:jar-with-dependencies" or > something similar which not only includes the artifact's sources into the JAR > but also those of its transitive dependencies. This would e.g. allow to > create a source bundle for an assembly created with Maven. > As a concrete example, the "Maven 2.x Plugin for Eclipse" project, which is > no Maven but a simple PDE project, uses the MavenEmbedder assembly. There, it > would be very handy to also have such a source bundle to attach to the > assembly JAR file inside Eclipse for developing and especially for debugging. > Would there maybe be any interest (beside my single use case :-)) in such a > feature? If so, I would eventually give it a try myself if I find the time... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MANTTASKS-13) Ant Tasks use of is inconsistent
[ http://jira.codehaus.org/browse/MANTTASKS-13?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105176 ] Kalle Korhonen commented on MANTTASKS-13: - ... and using Maven Tasks for Ant 2.0.7 > Ant Tasks use of is inconsistent > - > > Key: MANTTASKS-13 > URL: http://jira.codehaus.org/browse/MANTTASKS-13 > Project: Maven 2.x Ant Tasks > Issue Type: Bug > Environment: cygwin/win32 >Reporter: jonathan anderson >Priority: Minor > > In the ant build file, authentication works fine if you do: > >version="1.0-SNAPSHOT"/> >url="https://blah.blah.edu:8081/maven2";> > > > > But, if you do >url="https://blah.blah.edu:8081/maven2";> > > > >version="1.0-SNAPSHOT"/> > > > It fails mysteriously. The remoteRepository is found, but the http client > does not respond to the authentication challenge. The only error which > presents is a vague "Error transferring file" message -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MANTTASKS-13) Ant Tasks use of is inconsistent
[ http://jira.codehaus.org/browse/MANTTASKS-13?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105175 ] Kalle Korhonen commented on MANTTASKS-13: - Yes, I can confirm the same on Linux platform. In the latter example, you can of course add as nested in but then referencing to a repository definition is kind of pointless. A referenced nested authentication tag is always ignored. > Ant Tasks use of is inconsistent > - > > Key: MANTTASKS-13 > URL: http://jira.codehaus.org/browse/MANTTASKS-13 > Project: Maven 2.x Ant Tasks > Issue Type: Bug > Environment: cygwin/win32 >Reporter: jonathan anderson >Priority: Minor > > In the ant build file, authentication works fine if you do: > >version="1.0-SNAPSHOT"/> >url="https://blah.blah.edu:8081/maven2";> > > > > But, if you do >url="https://blah.blah.edu:8081/maven2";> > > > >version="1.0-SNAPSHOT"/> > > > It fails mysteriously. The remoteRepository is found, but the http client > does not respond to the authentication challenge. The only error which > presents is a vague "Error transferring file" message -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MASSEMBLY-136) outputDirectory to support absolute paths
outputDirectory to support absolute paths - Key: MASSEMBLY-136 URL: http://jira.codehaus.org/browse/MASSEMBLY-136 Project: Maven 2.x Assembly Plugin Issue Type: Improvement Affects Versions: 2.0.1 Environment: Linux Reporter: Kalle Korhonen Priority: Minor Can you please make the assembly parameter "outputDirectory" support absolute paths, just like "directory" in fileSets. Currently all paths are relative to the root directory of the assembly, whether or not you specify the path separator in the beginning or not. I see no reason why it should only support relative paths. I'm using assembly:directory to deploy some resources for my unit/integration tests that are normally available on a production environment. I realize I'm using the plugin "the wrong way", but the directory goal and format isn't suitable for deploying to the repository anyways. Also, either I don't know how to use appendAssemblyId correctly or it doesn't work for directory 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: (MPWAR-41) Ability to merge other war files as dependencies
[ http://jira.codehaus.org/browse/MPWAR-41?page=comments#action_67531 ] Kalle Korhonen commented on MPWAR-41: - Yeap, I'd also need this solved in a generic way. I'd simply want to include a zip dependency into a war. Currently it seems only jar dependencies are packaged into the war. > Ability to merge other war files as dependencies > > > Key: MPWAR-41 > URL: http://jira.codehaus.org/browse/MPWAR-41 > Project: maven-war-plugin > Type: New Feature > Versions: 1.6 > Reporter: Grégory Joseph (old account) > Attachments: maven-war-includewar.patch > > > In a project I'm working on, we need to be able to separate parts of our web > applications, to be able to build different versions, with or without certain > features. > Since some of these "parts" use jsp's, have specific dependencies, etc... we > can't just build them as jars. > I've made the attached patch in order to be able to specify a dependency of > type war and have it included in my "master" war. > Note that for this to work, the dependent war should not have a web.xml, for > instance. As it is, it simply unwar's the dependency in the main build > directory. It might be desired to actually run this *before* copying the > resources from the master project, so that at least they don't get > overwritten by the dependencies'. > Currently, the META-INF content and the web.xml are excluded from the unwar > task, maybe more excludes should be added? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SCM-153) Continuum fails while trying to build from clearcase
[ http://jira.codehaus.org/browse/SCM-153?page=comments#action_66341 ] Kalle Korhonen commented on SCM-153: Don't know what the root cause of the problem is but, sometimes the actual build directory isn't created while the view storage directory is. To work around the problem, you can remove the created view storage dir with "cleartool rmview" (check the id of the Continuum build to know which one to remove) and then try again. Once Continuum is happy with the directories and doesn't try re-creating snapshot, but uses update only, the problem is gone. > Continuum fails while trying to build from clearcase > > > Key: SCM-153 > URL: http://jira.codehaus.org/browse/SCM-153 > Project: Maven SCM > Type: Bug > Components: maven-scm-provider-clearcase > Versions: 1.0-beta-3 > Environment: Clearcase UCM / Windows XP / Snapshot view > Reporter: David Dandeneau > > > When trying to perform a build from continuum I receive the following error: > Provider message: The cleartool command failed. > Command output: > --- > cleartool: Error: A registry entry already exists for > "dandendj-LNGDAYD-4130684-maven-7". > --- > This happens on the second time through. On the first time through I receive: > org.apache.maven.continuum.execution.ContinuumBuildExecutorException: Could > not find Maven project descriptor. > at > org.apache.maven.continuum.execution.maven.m2.MavenTwoBuildExecutor.updateProjectFromCheckOut(MavenTwoBuildExecutor.java:111) > at > org.apache.maven.continuum.core.action.UpdateProjectFromWorkingDirectoryContinuumAction.execute(UpdateProjectFromWorkingDirectoryContinuumAction.java:62) > at > org.apache.maven.continuum.buildcontroller.DefaultBuildController.build(DefaultBuildController.java:169) > at > org.apache.maven.continuum.buildcontroller.BuildProjectTaskExecutor.executeTask(BuildProjectTaskExecutor.java:53) > at > org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable.run(ThreadedTaskQueueExecutor.java:103) > at java.lang.Thread.run(Thread.java:595) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SCM-153) Continuum fails while trying to build from clearcase
[ http://jira.codehaus.org/browse/SCM-153?page=comments#action_66338 ] Kalle Korhonen commented on SCM-153: This still happens in 1.0.3. My Clearcase master build works, but sub-module builds and builds from different branches fail with the same exception. I'm building on Linux w/ standard Clearcase 6.x. > Continuum fails while trying to build from clearcase > > > Key: SCM-153 > URL: http://jira.codehaus.org/browse/SCM-153 > Project: Maven SCM > Type: Bug > Components: maven-scm-provider-clearcase > Versions: 1.0-beta-3 > Environment: Clearcase UCM / Windows XP / Snapshot view > Reporter: David Dandeneau > > > When trying to perform a build from continuum I receive the following error: > Provider message: The cleartool command failed. > Command output: > --- > cleartool: Error: A registry entry already exists for > "dandendj-LNGDAYD-4130684-maven-7". > --- > This happens on the second time through. On the first time through I receive: > org.apache.maven.continuum.execution.ContinuumBuildExecutorException: Could > not find Maven project descriptor. > at > org.apache.maven.continuum.execution.maven.m2.MavenTwoBuildExecutor.updateProjectFromCheckOut(MavenTwoBuildExecutor.java:111) > at > org.apache.maven.continuum.core.action.UpdateProjectFromWorkingDirectoryContinuumAction.execute(UpdateProjectFromWorkingDirectoryContinuumAction.java:62) > at > org.apache.maven.continuum.buildcontroller.DefaultBuildController.build(DefaultBuildController.java:169) > at > org.apache.maven.continuum.buildcontroller.BuildProjectTaskExecutor.executeTask(BuildProjectTaskExecutor.java:53) > at > org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable.run(ThreadedTaskQueueExecutor.java:103) > at java.lang.Thread.run(Thread.java:595) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
