[jira] Closed: (MRELEASE-211) set version in batch mode
[
http://jira.codehaus.org/browse/MRELEASE-211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Gier closed MRELEASE-211.
--
Resolution: Won't Fix
The javadoc generation is done because of the release profile in the super pom.
As William suggested, you can turn off this release profile either in your pom
or from the command line
{{-DuseReleaseProfile=false}}
I think the plan is to change the super pom in the future so javadocs aren't
automatically generated, but it might not be until maven 2.1.
> set version in batch mode
> -
>
> Key: MRELEASE-211
> URL: http://jira.codehaus.org/browse/MRELEASE-211
> Project: Maven 2.x Release Plugin
> Issue Type: New Feature
>Affects Versions: 2.0-beta-5
> Environment: win XP pro SP2, maven 2.0.5, maven release plugin
> 2.0-beta-5
>Reporter: Andrew Chikvaidze
>
> I think a lot of developer teams often don't need generate javadoc for their
> project every time when running release:perform.
> I think it's very useful to add an option to disable javadoc creation.
> When I tried to pass to maven "-DperformRelease=false" this haven't effect.
> Later I saw in function
> private void perform( ReleaseDescriptor releaseDescriptor, Settings
> settings, List reactorProjects,
> File checkoutDirectory, String goals, boolean
> useReleaseProfile,
> ReleaseManagerListener listener, ReleaseResult
> result )
> the code:
> if ( useReleaseProfile )
> {
> if ( !StringUtils.isEmpty( additionalArguments ) )
> {
> /*
> evil hack (we don't need javadoc)
> additionalArguments = additionalArguments + "
> -DperformRelease=true";
> */
> additionalArguments = additionalArguments + "
> -DperformRelease=false";
> }
> else
> {
> /*
> evil hack (we don't need javadoc)
> additionalArguments = "-DperformRelease=true";
> */
> additionalArguments = "-DperformRelease=false";
> }
> }
> so, unfortunately now I cannot set -DperformRelease=false..
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MECLIPSE-497) Null ptr exception displayed when settings.xml file is selected. exception trace below.
Null ptr exception displayed when settings.xml file is selected. exception trace below. Key: MECLIPSE-497 URL: http://jira.codehaus.org/browse/MECLIPSE-497 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Components: Core : Dependencies resolution and build path Environment: Eclipse 3.3 Reporter: Suresh - select the attached settings.xml file in Windows->preferences->Maven->installatons window - index update begins. After a few minutes, a 1-line exception is displayed: An internal error occurred during: "Updating indexes". java.lang.NullPointerException Error View window displays the following: java.lang.NullPointerException at org.sonatype.nexus.index.context.DefaultIndexingContext.deleteIndexFiles(DefaultIndexingContext.java:262) at org.sonatype.nexus.index.context.DefaultIndexingContext.replace(DefaultIndexingContext.java:418) at org.sonatype.nexus.index.updater.DefaultIndexUpdater$1.invoke(DefaultIndexUpdater.java:95) at org.sonatype.nexus.index.updater.DefaultIndexUpdater.run(DefaultIndexUpdater.java:169) at org.sonatype.nexus.index.updater.DefaultIndexUpdater.fetchAndUpdateIndex(DefaultIndexUpdater.java:63) at org.maven.ide.eclipse.internal.index.NexusIndexManager.fetchAndUpdateIndex(NexusIndexManager.java:489) at org.maven.ide.eclipse.index.IndexManager$UpdateCommand.run(IndexManager.java:415) at org.maven.ide.eclipse.index.IndexManager$IndexUpdaterJob.run(IndexManager.java:532) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55) -- 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-3553) cannot resolve dependency with scope import
[
http://jira.codehaus.org/browse/MNG-3553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=151839#action_151839
]
Alexandre Navarro commented on MNG-3553:
I confirmed what Thomas Diesler said "In a more general way, it seem that
project A cannot have a dependency on B if B defines a dependency with scope
import that is deployed on a non-central snapshot repository."
I have the same problem in my enterprise.
> cannot resolve dependency with scope import
> ---
>
> Key: MNG-3553
> URL: http://jira.codehaus.org/browse/MNG-3553
> Project: Maven 2
> Issue Type: Bug
>Affects Versions: 2.0.9
>Reporter: Thomas Diesler
> Fix For: 2.0.11
>
>
> This pom when added as a dependency of another project does not see
> repository http://snapshots.jboss.org/maven2
>
>
>
>
> org.jboss.jbossas
> jboss-as-component-matrix
> ${jboss.version}
> pom
> import
>
>
>
> with effective settings
> [EMAIL PROTECTED] trunk]$ mvn help:effective-settings
> [INFO] Scanning for projects...
> [INFO] Reactor build order:
> [INFO] JBoss Web Services - Stack CXF
> [INFO] JBoss Web Services - Stack CXF Management
> [INFO] JBoss Web Services - Stack CXF Runtime Server
> [INFO] JBoss Web Services - Stack CXF Runtime Client
> [INFO] Searching repository for plugin with prefix: 'help'.
> [INFO]
>
> [INFO] Building JBoss Web Services - Stack CXF
> [INFO]task-segment: [help:effective-settings] (aggregator-style)
> [INFO]
>
> [INFO] [help:effective-settings]
> [INFO]
> Effective settings:
>
> /home/tdiesler/.m2/repository
>
>
>
>
> !jboss.repository.off
>
>
>
>
>
> snapshots.jboss.org
> http://snapshots.jboss.org/maven2
>
>
>
> false
>
> repository.jboss.org
> http://repository.jboss.org/maven2
>
>
> jboss.repository
>
>
>
> user-profile
>
>
> org.jboss.maven.plugins
>
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MEAR-87) Allow exclusion of artifacts when building the ear file.
[ http://jira.codehaus.org/browse/MEAR-87?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=151830#action_151830 ] Maarten Billemont commented on MEAR-87: --- The current method of excluding dependencies is OK for excluding two or three. It is UNMANAGABLE for excluding large groups of dependencies. Moreover, excluding transitive dependencies this way is utterly rediculous, especially when you have lots of them. You end up with a POM file that repeats x% of all the dependencies in your project, creating massive dublicate code which is hell to maintain. For example, we want to exclude all non-in-house artifacts from the EAR generated; so that the EAR file we distribute contains only our own artifacts. The other dependencies, we put in the default/lib directory of our JBoss AS; they do not belong in the EAR file - where they only serve to bloat; especially when we're trying to build or deploy 4 EAR files, each with all of those dependencies in them. > Allow exclusion of artifacts when building the ear file. > > > Key: MEAR-87 > URL: http://jira.codehaus.org/browse/MEAR-87 > Project: Maven 2.x Ear Plugin > Issue Type: New Feature >Affects Versions: 2.3.1 >Reporter: Dieter Houthooft >Priority: Minor > Fix For: 2.4 > > Attachments: maven-ear-plugin-excludes-fixed.patch, > maven-ear-plugin-excludes.patch > > > What is included in the .ear file is determined by the module list and the > dependency list and its transitive dependencies. We are often confronted with > changing demands about what to include in our ear files. It is quite hard to > change our dependency management (scopes) every time without side-effects on > other distributable artifacts. So I created an exclude configuration option > which allows to exclude artifacts from the ear file based on regular > expressions (java.util.regex) matching artifactIds and groupIds. > Use it like this: > > > > be.nondistributable.* > > > -- 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] Issue Comment Edited: (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=151824#action_151824 ] luc.willems edited comment on MRELEASE-326 at 10/24/08 9:05 AM: doesn't work for me :-( dependency errors are thrown before any clean/install goal has been run. using maven 2.0.9 and maven-release-plugin version 2.0-beta-7 was (Author: luc.willems): doesn't work for me :-( dependency errors are thrown before any clean/install goal has been run. > 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] 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=151824#action_151824 ] Luc Willems commented on MRELEASE-326: -- doesn't work for me :-( dependency errors are thrown before any clean/install goal has been run. > 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] Commented: (MRELEASE-293) Value of ${project.version} is captured before version resolution
[
http://jira.codehaus.org/browse/MRELEASE-293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=151823#action_151823
]
Luc Willems commented on MRELEASE-293:
--
same problem here.
useing ${version} resolves into "snapshot" versions in the final TAG
name.
maybe we should change tag info "prefix-tag" and append runtime version during
release proces.
> Value of ${project.version} is captured before version resolution
> -
>
> Key: MRELEASE-293
> URL: http://jira.codehaus.org/browse/MRELEASE-293
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: scm
>Affects Versions: 2.0-beta-6
> Environment: OS X 10.4.9, Java 5, Maven 2.0.6
>Reporter: Jarrod Carlson
>
> Our organization uses tags in which are the product version and only the
> product version:
> /tags
> /2.0.1
> /2.0.2
>
> /2.1.12
> The default value of is "${project.artifactId}-${project.version}" as
> specified in MRELEASE-53.
> However, when I specify the value of as follows:
> ${project.version}--or-- ${version}
> release:prepare resolves this to "artifact-x.y.z-SNAPSHOT".
> In other words, when a is specified, it is taken before the release
> process finalizes the release number.
> While I can specify the release on the command line, I need to be able to
> batch mode this process.
> ${project.version} should resolve to: "2.0.2" (or x.y.z).
--
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] Issue Comment Edited: (MNG-2142) Forcing execution of the post-integration-test phase
[ http://jira.codehaus.org/browse/MNG-2142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=151815#action_151815 ] ffbeltran edited comment on MNG-2142 at 10/24/08 7:52 AM: --- It's possible to configure the Surefire plugin to continue a build even if it encounters a failure. For example, i have: org.apache.maven.plugins maven-surefire-plugin true surefire-ut test test false **/*ITest.java surefire-it integration-test test false **/*ITest.java true My Unit Tests ends with Test.java and my Integration Tests ends with ITest.java. With , when Maven encounters a error in a Integration Test it continue the execution, stopping the server. Hope it helps was (Author: ffbeltran): It's possible to configure the Surefire plugin to continue a build even if it encounters a failure. For example, i have: org.apache.maven.plugins maven-surefire-plugin true surefire-ut test test false **/*ITest.java surefire-it integration-test test false **/*ITest.java true My Unit Tests ends with Test.java and my Integration Tests ends with ITest.java. When Maven encounters a error in a Integration Test it continue the execution, stopping the server. Hope it helps > Forcing execution of the post-integration-test phase > > > Key: MNG-2142 > URL: http://jira.codehaus.org/browse/MNG-2142 > Project: Maven 2 > Issue Type: Improvement > Components: Integration Tests >Affects Versions: 2.0.3 >Reporter: Vincent Massol > Fix For: 3.0 > > > The post-integration-test phase needs to always be called even in case of > tests failures in the integration-test phase. > For example when using Cargo the container may be left running if the > post-integration-test phase is not called... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2142) Forcing execution of the post-integration-test phase
[ http://jira.codehaus.org/browse/MNG-2142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=151815#action_151815 ] Federico Fernández commented on MNG-2142: - It's possible to configure the Surefire plugin to continue a build even if it encounters a failure. For example, i have: org.apache.maven.plugins maven-surefire-plugin true surefire-ut test test false **/*ITest.java surefire-it integration-test test false **/*ITest.java true My Unit Tests ends with Test.java and my Integration Tests ends with ITest.java. When Maven encounters a error in a Integration Test it continue the execution, stopping the server. Hope it helps > Forcing execution of the post-integration-test phase > > > Key: MNG-2142 > URL: http://jira.codehaus.org/browse/MNG-2142 > Project: Maven 2 > Issue Type: Improvement > Components: Integration Tests >Affects Versions: 2.0.3 >Reporter: Vincent Massol > Fix For: 3.0 > > > The post-integration-test phase needs to always be called even in case of > tests failures in the integration-test phase. > For example when using Cargo the container may be left running if the > post-integration-test phase is not called... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MECLIPSE-451) EJB projects are not correctly referenced in .component
[
http://jira.codehaus.org/browse/MECLIPSE-451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=151805#action_151805
]
Steffen Grunwald commented on MECLIPSE-451:
---
I supplied a patch in MECLIPSE-455 that writes the archivename with the jar
extension.
Please test and comment on it.
> EJB projects are not correctly referenced in .component
>
>
> Key: MECLIPSE-451
> URL: http://jira.codehaus.org/browse/MECLIPSE-451
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Bug
> Environment: Eclipse 3.3, Wtp 2.0, Jboss 4.2, Linux
>Reporter: Gabriele Contini
>Priority: Critical
>
> There is a problem generating wtp 2.0 configuration for multi-module j2ee
> applications using ejb 3.0.
> Here is my project structure.
> {noformat}
> myapp
>|--ear
>| |-- .settings
>| ||--- org.eclipse.wst.common.component
>| |
>| |-- pom.xml
>|--ejb
>| |-- pom.xml
>|
>|
> {noformat}
> here is a snippet from: myapp/ejb/pom.xml
> {code:xml}
>
> myapp-ejb
> ejb
> ...
> {code}
> here is a snippet from: myapp/ear/pom.xml
> {code:xml}
>
> ${pom.groupId}
> myapp-ejb
> ${pom.version}
> ejb
>
> {code}
> and here is a snippet from the generated org.eclipse.wst.common.component
> file in the ear project.
> {code:xml}
> handle="module:/resource/myapp-ejb/myapp-ejb">
> EjbModule_9473961
> uses
>
> {code}
> Thus inside the ear generated by eclipse i can find an artifact: myapp-ejb.ejb
> Whereas the generated application.xml the module is referenced with .jar
> extension:
> {code:xml}
>
> ---
>
> myapp-ejb.jar
>
> {code}
> I tried to override the application.xml with a custom one, but it seems that
> jboss doesn't like at all the extension ".ejb" for ejb 3.0 jars.
> To make it work i modified by hand the generated
> org.eclipse.wst.common.component file in the ear project like this:
> {code:xml}
> handle="module:/resource/unirepo-core/unirepo-core">
> EjbModule_12684337
> uses
>
> {code}
> At the moment this file must be modified by hand every time i generate the
> eclipse configuration.
--
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-1969) Mojo not getting configuration from pom in integration-test phase
[
http://jira.codehaus.org/browse/MNG-1969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann updated MNG-1969:
---
Description:
I have a plugin that defines a new packaging type. This is basically the same
as the jar packaging type, except it does nothing in the test phase, has a
special packaging phase (where some manifest entries are added) and an
integration-test phase that runs an integration test.
I am able to modify parameters in the "packaging" phase with no problem.
However, in the integration-test phase, for some reason, my parameters are not
getting set from the pom.xml. Here is the XML snippet from my pom.xml:
{code:xml}
com.bea.core.maven2.plugins
maven-osgi-bundler-plugin
1.0.0-SNAPSHOT
true
main
package
osgi-bundle
com.bea.jetty.JettyActivator
Jetty HTTP
OSGi HTTP service using Jetty
com.bea.core.jetty
org.osgi.framework
org.osgi.service.log
com.bea.core.dioce
com.bea.core.netio
com.bea.core.wm
javax.servlet;version=2.5
javax.servlet.http;version=2.5
org.osgi.service.http;version=1.2
.
lib/http-service.jar
lib/servlet.jar
test
package
test-osgi-bundle
com.bea.jetty.test.TestActivator
Jetty HTTP Tests
OSGi HTTP service using Jetty Testing
Bundle
com.bea.core.jetty.tests
org.osgi.framework
javax.servlet
javax.servlet.http
org.osgi.service.http
integration-test
integration-test
run-osgi-test
true
{code}
With no problem at all the various variables I set in the "packaging" phase are
being set. There are two mojo's there, with the goals osgi-bundle and
test-osgi-bundle. Both of those things seem to be getting their configuration
parameters just fine from the pom.xml.
However, my run-osgi-test goal that happens from the integration-test phase is
NOT getting the configuration parameter.
Here is the output from "mvn -X integration-test" (well, some of it)...
{noformat}
[DEBUG] Configuring mojo
'com.bea.core.maven2.plugins:maven-osgi-bundler-plugin:
1.0.0-SNAPSHOT:run-osgi-test' -->
[DEBUG] (f) buildDirectory = C:\weblogic\dev\core\modules\jetty\target
[DEBUG] (f) integrationDirectoryName = integration-test
[DEBUG] (f) loadFileName = loader.xml
[DEBUG] (f) project = [EMAIL PROTECTED]
[DEBUG] (f) skip = false
[DEBUG] (f) testTimeout = 30
{noformat}
Etc. At this point, shouldn't "skip" be "true" since I set it to "true" in the
pom.xml?
Here is the java:
{code:java}
/**
* Should these tests be skipped?
* @parameter expression="false"
*/
private boolean skip;
{code}
I have tried several things:
1) Making it a "String" rather than a Boolean
2) Moving it to the same package as the other mojo's that *are* getting their
variables configured properly
3) Having multiple "plugin" definitions in the pom file
Here is something else I just found out:
If instead I change the last "execution" for the plugin to be for phase
"package", then my variables get set properly. So, if my pom.xml instead has
this:
{code:xml}
integration-test
package
run-osgi-test
true
{code}
The problem with this is that my run-osgi-test then properly picks up the
variables in the "packaging" phase but then goes ahead and runs with the
variables not set in the "integration-test" phase.
was:
I have a plugin that defines a new packaging type. This is basically the same
as the jar packaging type, except it does nothing in the test phase, has a
special packaging phase (where some manifest entries are
added) and an integration-test phase that runs an integration test.
I am able to modify parameters in the "packaging" phase with no problem.
However, in the integration-test phase, for some reason, my parameters are not
getting set from the pom.xml. Here is the XML snippet from my
pom.xml:
com.bea.core.maven2.plugins
maven-osgi-bundler-plugin
1.0.0-SNAPSHOT
true
main
package
osgi-bundle
com.bea.jetty.JettyActivator
Jetty HTTP
OSGi HTTP service using
Jetty
com.bea.core.jetty
org.osgi.framework
org.osgi.service.log
com.bea.core.dioce
com.bea.core.netio
com.bea.core.wm
javax.servlet;version=2.5
javax.servlet.http;version=2.5
org.osgi.service.http;version=1.2
.
[jira] Closed: (MSHARED-76) Verifier executeGoal method is OS-dependent in case of failure
[ http://jira.codehaus.org/browse/MSHARED-76?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann closed MSHARED-76. Assignee: Benjamin Bentmann (was: Jason van Zyl) Resolution: Duplicate Fixed as per MSHARED-73. > Verifier executeGoal method is OS-dependent in case of failure > -- > > Key: MSHARED-76 > URL: http://jira.codehaus.org/browse/MSHARED-76 > Project: Maven Shared Components > Issue Type: Bug > Components: maven-verifier >Affects Versions: maven-verifier 1.0 >Reporter: Stephane Nicoll >Assignee: Benjamin Bentmann > Fix For: maven-verifier 1.2 > > > On windows Verifier.executeGoal() runs ok even if the underneath execution > fails (this is good since there is a special method to make sure that > everything went ok). > On linux/macOSx, a VerificationException is thrown (Exit code was non-zero) > This OS-dependent behavior is an issue when one wants to test that a given > project is actually expected to fail (see project-026 in the EAR plugin for > instance). -- 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: (MSHARED-76) Verifier executeGoal method is OS-dependent in case of failure
[ http://jira.codehaus.org/browse/MSHARED-76?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann moved MNG-2718 to MSHARED-76: --- Affects Version/s: (was: 2.0.4) maven-verifier 1.0 Fix Version/s: (was: Reviewed Pending Version Assignment) maven-verifier 1.2 Component/s: (was: Integration Tests) maven-verifier Key: MSHARED-76 (was: MNG-2718) Project: Maven Shared Components (was: Maven 2) > Verifier executeGoal method is OS-dependent in case of failure > -- > > Key: MSHARED-76 > URL: http://jira.codehaus.org/browse/MSHARED-76 > Project: Maven Shared Components > Issue Type: Bug > Components: maven-verifier >Affects Versions: maven-verifier 1.0 >Reporter: Stephane Nicoll >Assignee: Jason van Zyl > Fix For: maven-verifier 1.2 > > > On windows Verifier.executeGoal() runs ok even if the underneath execution > fails (this is good since there is a special method to make sure that > everything went ok). > On linux/macOSx, a VerificationException is thrown (Exit code was non-zero) > This OS-dependent behavior is an issue when one wants to test that a given > project is actually expected to fail (see project-026 in the EAR plugin for > instance). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVENUPLOAD-2226) Upload of ANTLR v3.1
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Heritier closed MAVENUPLOAD-2226. Resolution: Duplicate > Upload of ANTLR v3.1 > > > Key: MAVENUPLOAD-2226 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2226 > Project: Maven Upload Requests > Issue Type: Wish >Reporter: Thomas VIAL > > http://sd-6069.dedibox.fr/vhcs2/antlr-3.1-bundle.jar > http://antlr.org > Hi, > I'm not a developer for ANTLR but I'd be glad to have it in the central repo. > The URL I provide is from a personal server that has nothing to do with > ANTLR; hope it's not a problem. > The antlr-3.1.jar inside the bundle is the complete binary distribution, > downloaded directly from http://antlr.org/download.html and bundled without > modifications. > And here is a link to the antlr-interest ML archives with the initial wish: > http://www.antlr.org:8080/pipermail/antlr-interest/2008-September/030636.html > Thanks! > Thomas -- 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-382) Specifying workingDirectory as system property on CL is not picked up by release:perform
[ http://jira.codehaus.org/browse/MRELEASE-382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=151789#action_151789 ] Benjamin Bentmann commented on MRELEASE-382: If just everything would be as easy to fix as this one ;-) > Specifying workingDirectory as system property on CL is not picked up by > release:perform > > > Key: MRELEASE-382 > URL: http://jira.codehaus.org/browse/MRELEASE-382 > Project: Maven 2.x Release Plugin > Issue Type: Improvement > Components: scm >Affects Versions: 2.0-beta-7 > Environment: Win XP SP2, SUN JDK 1.5.0_16-b02, mvn 2.1.0-M1 >Reporter: Anders Hammar >Assignee: Benjamin Bentmann > Fix For: 2.0-beta-8 > > > Running the release:perform mojo from command line in an empty directory (no > pom) with the -DworkingDirectory flag, the specified workingDirectory is not > picked up. This results in the workingDirectory being used something like > 'CUR_DIR/null/target/checkout'. > The command being issued: > mvn release:perform -DconnectionUrl="scm:clearcase:VIEW_NAME:load /VOB/PATH" > -Dtag=TAG_NAME -DworkingDirectory=c:\mvn-test\checkout -- 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
