[jira] (MCHANGELOG-128) Remove the unused commentFormat paramater from changelog mojo
Martín D'Aloia created MCHANGELOG-128: - Summary: Remove the unused commentFormat paramater from changelog mojo Key: MCHANGELOG-128 URL: https://jira.codehaus.org/browse/MCHANGELOG-128 Project: Maven 2.x Changelog Plugin Issue Type: Improvement Affects Versions: 2.2, 2.3 Reporter: Martín D'Aloia Priority: Trivial Attachments: remove-commentFormat-parameter.patch The parameter commentFormat on the changelog mojo is unused and the javadoc says that it is used by ClearcaseChangeLogGenerator which not exists on the project. -- 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] (MCHANGELOG-127) Add possibilty to specify an alternate SCM connection url
Martín D'Aloia created MCHANGELOG-127: - Summary: Add possibilty to specify an alternate SCM connection url Key: MCHANGELOG-127 URL: https://jira.codehaus.org/browse/MCHANGELOG-127 Project: Maven 2.x Changelog Plugin Issue Type: New Feature Affects Versions: 2.2, 2.3 Reporter: Martín D'Aloia Attachments: custom-scm-connection-url.patch Add possibilty to specify an alternate connection url other than the defined in the SCM section, similar to the SCM mojo of the maven-project-info-reports-plugin (see [here|http://maven.apache.org/plugins/maven-project-info-reports-plugin/scm-mojo.html#anonymousConnection]) and the ChangeLog mojo of the maven-scm-plugin (see [here|http://maven.apache.org/scm/maven-scm-plugin/changelog-mojo.html#connectionUrl]) This makes possible to generate, for example, a general site module (on a multi-module project) with general information. This is the same intention of the General SCM Project Information Report (see [here|http://maven.apache.org/plugins/maven-project-info-reports-plugin/examples/scm-report.html]) The patch provided contains one possible solution and the modification of the testcases affected by this change. By default the 2 new parameters gets the value specified on *project.scm.connection* and *project.scm.developerConnection* -- 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] (MRELEASE-757) cannot perform a release with another pom then pom.xml
Emmanuel Potvin created MRELEASE-757:
Summary: cannot perform a release with another pom then pom.xml
Key: MRELEASE-757
URL: https://jira.codehaus.org/browse/MRELEASE-757
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: perform
Reporter: Emmanuel Potvin
If for an obscure but uncontrolable reason I hava a pom named anything else
then pom.xml, like pom2.xml, the following command don't work :
mvn -f pom2.xml release:prepare release:perform
the prepare phase works well. But the perform have this error : the deploy
command launched on the checked out code (in the target folder) run with
pom.xml... I fixed it with the following code change :
RunPerformGoalsPhase.java, line 71 :
// ensure we don't use the release pom for the perform goals
if ( !StringUtils.isEmpty( additionalArguments ) )
{
additionalArguments = additionalArguments + " -f pom.xml";
}
else
{
additionalArguments = "-f pom.xml";
}
with :
// ensure we don't use the release pom for the perform goals
if ( !StringUtils.isEmpty( additionalArguments ) )
{
additionalArguments = additionalArguments + " -f " + pomFileName;
}
else
{
additionalArguments = "-f " + pomFileName;
}
--
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] (ARCHETYPE-411) goals parameter don't use -s and -gs parameter
Lefebvre JF created ARCHETYPE-411: - Summary: goals parameter don't use -s and -gs parameter Key: ARCHETYPE-411 URL: https://jira.codehaus.org/browse/ARCHETYPE-411 Project: Maven Archetype Issue Type: Bug Affects Versions: 2.2 Reporter: Lefebvre JF Priority: Blocker When using archétype:generate -s mySettings.xml -Dparamxxx= -Dgoals=AGOAL AGOAL is invoqued but without mySettings informations -- 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] (SUREFIRE-865) surefire 2.12 with parallel=methods does not execute junit 4.7+ tests in parallel
Neil Hartner created SUREFIRE-865: - Summary: surefire 2.12 with parallel=methods does not execute junit 4.7+ tests in parallel Key: SUREFIRE-865 URL: https://jira.codehaus.org/browse/SUREFIRE-865 Project: Maven Surefire Issue Type: Bug Components: Junit 4.7+ (parallel) support Environment: Maven 2.2.1 and 3.0.4, JDK6, JUnit 4.10 Reporter: Neil Hartner Attachments: surefire-parallel-junit.zip parallel=methods with junit does not appear to parallelize junit test execution in surefire 2.12 or 2.13-SNAPSHOT. parallel=classes works with 2.12, but parallel=methods only works for me in earlier versions of surefire like 2.10 and 2.11. I saw an earlier bug related to TestSuite classes but my tests are not using @Test. I have attached a very simple maven project that demonstrates this issue. It has 2 test classes with 2 tests each where each test calls Thread.sleep() for 4-8 seconds. Here are a few build commands to reproduce the bug: First run: mvn test -Dsurefire-version=2.11 -Dparallel=methods Notice that in 2.11 the tests execute in two threads and in parallel. Total execution time on my box was 15s. Then run: mvn test -Dsurefire-version=2.12 -Dparallel=methods Notice that in 2.12 the tests execute in the same main thread. Total execution time on my box was 26s. Finally run: mvn test -Dsurefire-version=2.12 -Dparallel=classes Notice that parallel=classes does correctly execute tests in two threads and in parallel. Total execution time on my box was 17s. --- Here is output from my machine when running these commands... Run: mvn test -Dsurefire-version=2.11 -Dparallel=methods OUTPUT: Concurrency config is parallel='methods', perCoreThreadCount=true, threadCount=2, useUnlimitedThreads=false Running com.overstock.BarTest Fri May 11 11:26:34 MDT 2012: BarTest calling sleep(5) in thread pool-1-thread-2 Fri May 11 11:26:34 MDT 2012: BarTest calling sleep(4) in thread pool-1-thread-1 Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 9.033 sec Running com.overstock.FooTest Fri May 11 11:26:39 MDT 2012: FooTest calling sleep(7) in thread pool-1-thread-3 Fri May 11 11:26:39 MDT 2012: FooTest calling sleep(8) in thread pool-1-thread-4 Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 15.008 sec Results : Tests run: 4, Failures: 0, Errors: 0, Skipped: 0 [INFO] [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 15 seconds Run: mvn test -Dsurefire-version=2.12 -Dparallel=methods OUTPUT: Concurrency config is parallel='methods', perCoreThreadCount=true, threadCount=2, useUnlimitedThreads=false Running com.overstock.BarTest Fri May 11 11:25:53 MDT 2012: BarTest calling sleep(4) in thread main Fri May 11 11:25:58 MDT 2012: BarTest calling sleep(5) in thread main Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 9.017 sec Running com.overstock.FooTest Fri May 11 11:26:03 MDT 2012: FooTest calling sleep(7) in thread main Fri May 11 11:26:10 MDT 2012: FooTest calling sleep(8) in thread main Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 15.003 sec Results : Tests run: 4, Failures: 0, Errors: 0, Skipped: 0 [INFO] [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 26 seconds Run: mvn test -Dsurefire-version=2.12 -Dparallel=classes OUTPUT: Concurrency config is parallel='classes', perCoreThreadCount=true, threadCount=2, useUnlimitedThreads=false Running com.overstock.BarTest Fri May 11 11:27:38 MDT 2012: BarTest calling sleep(4) in thread pool-1-thread-1 Fri May 11 11:27:42 MDT 2012: BarTest calling sleep(5) in thread pool-1-thread-1 Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 9.016 sec Running com.overstock.FooTest Fri May 11 11:27:38 MDT 2012: FooTest calling sleep(7) in thread pool-1-thread-2 Fri May 11 11:27:45 MDT 2012: FooTest calling sleep(8) in thread pool-1-thread-2 Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 15.016 sec Results : Tests run: 4, Failures: 0, Errors: 0, Skipped: 0 [INFO] [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 17 seconds -- 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] (MCHECKSTYLE-176) Support for @javax.annotation.Generated
Peter Ford created MCHECKSTYLE-176:
--
Summary: Support for @javax.annotation.Generated
Key: MCHECKSTYLE-176
URL: https://jira.codehaus.org/browse/MCHECKSTYLE-176
Project: Maven 2.x Checkstyle Plugin
Issue Type: New Feature
Reporter: Peter Ford
Priority: Minor
Would you be willing to consider whether any support can be added for excluding
code that is annotated with {{javax.annotation.Generated}}?
For example, if a {{.java}} file contains a public class that is annotated
{{@Generated}}, perhaps the whole file would be excluded from checks - if a
suitable parameter was set in the POM.
Thanks!
--
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] (MRELEASE-674) release plugin converts explicit version to snapshot
[
https://jira.codehaus.org/browse/MRELEASE-674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MRELEASE-674:
Description:
I would like to use {{release:update-versions}} to explicitly update the
versions of my multiproject. Unfortunetly the release plugin converts the given
developmentVersion to a SNAPSHOT version. It happens in
{{MapVersionPhase.getNextVersion()}}.
I would expect the plugin to leave the given developmentVersion property as it
is, because the prompt version will not be converted. Here is my command line:
{{mvn release:update-versions -DautoVersionSubmodules=true
-DdevelopmentVersion=2.0.1 -DpushChanges=false}}
I made a patch and attached it to the issue.
was:
I would like to use release:update-versions to explicitly update the versions
of my multiproject. Unfortunetly the release plugin converts the given
developmentVersion to a SNAPSHOT version. It happens in
MapVersionPhase.getNextVersion().
I would expect the plugin to leave the given developmentVersion property as it
is, because the prompt version will not be converted. Here is my command line:
mvn release:update-versions -DautoVersionSubmodules=true
-DdevelopmentVersion=2.0.1 -DpushChanges=false
I made a patch and attached it to the issue.
Fix Version/s: 2.4
Assignee: Robert Scholte
The number of open issues is huge, it'll take some time to clean it up. I'll
mark this for the 2.4 release.
You could help if you could provide an integration-test
> release plugin converts explicit version to snapshot
> -
>
> Key: MRELEASE-674
> URL: https://jira.codehaus.org/browse/MRELEASE-674
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: update-versions
>Affects Versions: 2.1
> Environment: Apache Maven 3.0.2 (r1056850; 2011-01-09 01:58:10+0100)
> Java version: 1.6.0_23, vendor: Sun Microsystems Inc.
> Java home: i:\tools\jdk\1.6.0_23\jre
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows xp", version: "5.1", arch: "x86", family: "windows"
>Reporter: Bernd Mau
>Assignee: Robert Scholte
> Fix For: 2.4
>
> Attachments: MapVersionPhase.patch
>
>
> I would like to use {{release:update-versions}} to explicitly update the
> versions of my multiproject. Unfortunetly the release plugin converts the
> given developmentVersion to a SNAPSHOT version. It happens in
> {{MapVersionPhase.getNextVersion()}}.
> I would expect the plugin to leave the given developmentVersion property as
> it is, because the prompt version will not be converted. Here is my command
> line:
> {{mvn release:update-versions -DautoVersionSubmodules=true
> -DdevelopmentVersion=2.0.1 -DpushChanges=false}}
> I made a patch and attached it to the issue.
--
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] (MRELEASE-674) release plugin converts explicit version to snapshot
[ https://jira.codehaus.org/browse/MRELEASE-674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=298493#comment-298493 ] Jim McCaskey commented on MRELEASE-674: --- I've noticed the release plugin has been released a few times with out this even though a patch is available. I was curious if there was any reason why. > release plugin converts explicit version to snapshot > - > > Key: MRELEASE-674 > URL: https://jira.codehaus.org/browse/MRELEASE-674 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: update-versions >Affects Versions: 2.1 > Environment: Apache Maven 3.0.2 (r1056850; 2011-01-09 01:58:10+0100) > Java version: 1.6.0_23, vendor: Sun Microsystems Inc. > Java home: i:\tools\jdk\1.6.0_23\jre > Default locale: de_DE, platform encoding: Cp1252 > OS name: "windows xp", version: "5.1", arch: "x86", family: "windows" >Reporter: Bernd Mau > Attachments: MapVersionPhase.patch > > > I would like to use release:update-versions to explicitly update the versions > of my multiproject. Unfortunetly the release plugin converts the given > developmentVersion to a SNAPSHOT version. It happens in > MapVersionPhase.getNextVersion(). > I would expect the plugin to leave the given developmentVersion property as > it is, because the prompt version will not be converted. Here is my command > line: > mvn release:update-versions -DautoVersionSubmodules=true > -DdevelopmentVersion=2.0.1 -DpushChanges=false > I made a patch and attached it to the issue. -- 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] (MASSEMBLY-607) Wildcard in dependencySet/includes doesn't match artifact with empty classifier
Alexander Kormushin created MASSEMBLY-607:
-
Summary: Wildcard in dependencySet/includes doesn't match artifact
with empty classifier
Key: MASSEMBLY-607
URL: https://jira.codehaus.org/browse/MASSEMBLY-607
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.3
Environment: Windows 7/Maven 3.0.03
Reporter: Alexander Kormushin
Following dependency set will match only my jar artifacts with any non-empty
classifier:
{code}
com.mycompany.*:*:jar:*:*
{code}
But it seems wildcard should include empty ones.
Here is the related code fragment:
{code:title=.m2\repository\org\apache\maven\shared\maven-common-artifact-filters\1.4\maven-common-artifact-filters-1.4.jar!\org\apache\maven\shared\artifact\filter\PatternIncludesArtifactFilter.class}
172private boolean matchAgainst( final String value, final List patterns,
final boolean regionMatch )
181// fail immediately if pattern tokens outnumber tokens to match
182boolean matched = ( patternTokens.length <= tokens.length );
{code}
I have following values achieving 182 line:
pattern=[com.mycompany.*, *, jar, *, *]
tokens=[com.mycompany, myproject, jar, 1.0.0-SNAPSHOT]
--
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] (MRELEASE-426) There is no way to specify a branch/tag/revision when performing a release
[ https://jira.codehaus.org/browse/MRELEASE-426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=298481#comment-298481 ] Jörgen Persson edited comment on MRELEASE-426 at 5/11/12 6:55 AM: -- Ok. From my point of view, it's not CVS we're using in my company, but SVN. I would like to have the possibility to specify -DscmVersion= when making a release and it is due to the following. We have official releases and we have alpha or beta releases. When making an alpha or beta release, we are not allowed to make any release branches as this should not be maintained in a traditional way with bug fix releases and so as we do in official releases. Sometimes when there is a need for such a alpha or beta release, and due to a time consuming release procedure (an rough estimate is half a day, due to a lot of test cases, packaging, assemblying, ...), what I would like, is for my colleagues, to grab a snapshot version from our Jenkins server and do QA / test on it. If the QA / tests were successful there are normally a lot of commits made on our trunk in the mean time. This is why I would like to release and tag trunk as how it looked at and not HEAD. was (Author: jpe2012): Ok. From my point of view, it's not CVS we're using in my company, but SVN. I would like to have the possibility to specify -DscmVersion= when making a release and it is due to the following. We have official releases and we have alpha or beta releases. When making an alpha or beta release, we are not allowed to make any release branches as this should not be maintained in a traditional way with bug fix releases and so as we do in official releases. Sometimes when there is a need for such a alpha or beta release, and due to a time consuming release procedure (an rough estimate is half a day, due to a lot of test cases, packaging, assemblying, ...), what I would like, is for my colleagues, to grab a snapshot version from our Jenkins server and do QA / test on it. If the QA / tests were successful there are normally a lot of commits made on our trunk. This is why I would like to release and tag trunk as how it looked at and not HEAD. > There is no way to specify a branch/tag/revision when performing a release > -- > > Key: MRELEASE-426 > URL: https://jira.codehaus.org/browse/MRELEASE-426 > Project: Maven 2.x Release Plugin > Issue Type: Improvement > Components: perform >Affects Versions: 2.0-beta-8 > Environment: Maven2, CVSNT >Reporter: Eric > > When using the release-plugin with CVS, there does not seem to be any way to > specify a version & versionType to base the release on. > The scm plugin allows to specify scmVersion, scmVersionType to pass this > information to the plugin, but when calling the release:perform goal, there > is no way to send this information to the scm plugin to checkout the files > from the appropriate branch/tag. > Accordingly, it seems that with CVS, the only way to build a release is from > the latest sources in the HEAD; not extremely practical. -- 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] (MRELEASE-426) There is no way to specify a branch/tag/revision when performing a release
[ https://jira.codehaus.org/browse/MRELEASE-426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=298481#comment-298481 ] Jörgen Persson commented on MRELEASE-426: - Ok. From my point of view, it's not CVS we're using in my company, but SVN. I would like to have the possibility to specify -DscmVersion= when making a release and it is due to the following. We have official releases and we have alpha or beta releases. When making an alpha or beta release, we are not allowed to make any release branches as this should not be maintained in a traditional way with bug fix releases and so as we do in official releases. Sometimes when there is a need for such a alpha or beta release, and due to a time consuming release procedure (an rough estimate is half a day, due to a lot of test cases, packaging, assemblying, ...), what I would like, is for my colleagues, to grab a snapshot version from our Jenkins server and do QA / test on it. If the QA / tests were successful there are normally a lot of commits made on our trunk. This is why I would like to release and tag trunk as how it looked at and not HEAD. > There is no way to specify a branch/tag/revision when performing a release > -- > > Key: MRELEASE-426 > URL: https://jira.codehaus.org/browse/MRELEASE-426 > Project: Maven 2.x Release Plugin > Issue Type: Improvement > Components: perform >Affects Versions: 2.0-beta-8 > Environment: Maven2, CVSNT >Reporter: Eric > > When using the release-plugin with CVS, there does not seem to be any way to > specify a version & versionType to base the release on. > The scm plugin allows to specify scmVersion, scmVersionType to pass this > information to the plugin, but when calling the release:perform goal, there > is no way to send this information to the scm plugin to checkout the files > from the appropriate branch/tag. > Accordingly, it seems that with CVS, the only way to build a release is from > the latest sources in the HEAD; not extremely practical. -- 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] (MNG-5284) Maven keeps connecting to http://repo1.maven.org even with mirrors
Rafael Pato created MNG-5284:
Summary: Maven keeps connecting to http://repo1.maven.org even
with mirrors
Key: MNG-5284
URL: https://jira.codehaus.org/browse/MNG-5284
Project: Maven 2 & 3
Issue Type: Bug
Components: Dependencies
Affects Versions: 3.0.4
Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 08:44:56+)
Maven home: C:\Program Files\apache-maven-3.0.4
Java version: 1.6.0_22, vendor: Sun Microsystems Inc.
Java home: C:\Progra~1\Java\jdk1.6.0_22\jre
Default locale: pt_PT, platform encoding: Cp1252
OS name: "windows server 2008 r2", version: "6.1", arch: "amd64", family:
"windows"
Reporter: Rafael Pato
Priority: Critical
Attachments: settings.xml
I created a mirror in setting.xml , for every connection , to connect to my
local repo in Artifactory . It works! But when the generate action starts Maven
connects to http://repo1.maven.org:
{code}
[DEBUG] Using mirror ibiblio.org
(http://localhost:8081/artifactory/remote-widesys-libs) for central
(http://localhost:8081/artifactory/remote-widesys-libs).
[DEBUG] Using mirror remote-widesys-libs
(http://localhost:8081/artifactory/remote-widesys-libs) for snapshots
(http://localhost:8081/artifactory/remote-widesys-libs).
[DEBUG] Extension realms for project org.apache.maven:standalone-pom:pom:1:
(none)
[DEBUG] Looking up lifecyle mappings for packaging pom from
ClassRealm[plexus.core, parent: null]
[DEBUG] Resolving plugin prefix archetype from [org.apache.maven.plugins,
org.codehaus.mojo]
[DEBUG] Using mirror remote-widesys-libs
(http://localhost:8081/artifactory/remote-widesys-libs) for apache.snapshots
(http://repository.apache.org/snapshots).
[DEBUG] Using mirror remote-widesys-libs
(http://localhost:8081/artifactory/remote-widesys-libs) for apache.snapshots
(http://repository.apache.org/snapshots).
[DEBUG] Using mirror remote-widesys-libs
(http://localhost:8081/artifactory/remote-widesys-libs) for apache.snapshots
(http://repository.apache.org/snapshots).
[DEBUG] Using mirror remote-widesys-libs
(http://localhost:8081/artifactory/remote-widesys-libs) for apache.snapshots
(http://repository.apache.org/snapshots).
[DEBUG] Using mirror remote-widesys-libs
(http://localhost:8081/artifactory/remote-widesys-libs) for apache.snapshots
(http://people.apache.org/repo/m2-snapshot-repository).
[DEBUG] Using mirror remote-widesys-libs
(http://localhost:8081/artifactory/remote-widesys-libs) for codehaus.org
(http://snapshots.repository.codehaus.org).
[DEBUG] Using mirror remote-widesys-libs
(http://localhost:8081/artifactory/remote-widesys-libs) for apache.snapshots
(http://repository.apache.org/snapshots).
[DEBUG] Using mirror remote-widesys-libs
(http://localhost:8081/artifactory/remote-widesys-libs) for apache.snapshots
(http://people.apache.org/repo/m2-snapshot-repository).
[DEBUG] Using mirror remote-widesys-libs
(http://localhost:8081/artifactory/remote-widesys-libs) for apache.snapshots
(http://repository.apache.org/snapshots).
[INFO] Generating project in Batch mode
[DEBUG] Searching for remote catalog:
http://repo1.maven.org/maven2/archetype-catalog.xml
[DEBUG] Searching for remote catalog: http://repo1.maven.org/maven2
{code}
And btw, I'm using mirrors and I've overwrited the central repo with my local
repo.
I've searched the whole Internet for ways to disable connections to
http://repo1.maven.org but this keeps happening...
You can consult my settings.xml in the attachments
--
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] (MRELEASE-426) There is no way to specify a branch/tag/revision when performing a release
[ https://jira.codehaus.org/browse/MRELEASE-426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=298480#comment-298480 ] Mark Struberg commented on MRELEASE-426: Well, I only used CVS from mid 90s to early 2004 or so, but I think there was a way to checkout a branch. It was not very handy but still it used to work. Can you please shed more light on why it is not possible to just create a branch in CVS. I bet it would be easier to switch to SVN or GIT nowadays. Given that CVS has horrible security leaks and is practically unmaintained since 5 years, isn't? > There is no way to specify a branch/tag/revision when performing a release > -- > > Key: MRELEASE-426 > URL: https://jira.codehaus.org/browse/MRELEASE-426 > Project: Maven 2.x Release Plugin > Issue Type: Improvement > Components: perform >Affects Versions: 2.0-beta-8 > Environment: Maven2, CVSNT >Reporter: Eric > > When using the release-plugin with CVS, there does not seem to be any way to > specify a version & versionType to base the release on. > The scm plugin allows to specify scmVersion, scmVersionType to pass this > information to the plugin, but when calling the release:perform goal, there > is no way to send this information to the scm plugin to checkout the files > from the appropriate branch/tag. > Accordingly, it seems that with CVS, the only way to build a release is from > the latest sources in the HEAD; not extremely practical. -- 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] (MRELEASE-426) There is no way to specify a branch/tag/revision when performing a release
[ https://jira.codehaus.org/browse/MRELEASE-426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=298469#comment-298469 ] Jörgen Persson commented on MRELEASE-426: - It's an old post / issue, but I agree with the issue creator. It would be very very convenient to be able to make a release from an earlier revision than HEAD > There is no way to specify a branch/tag/revision when performing a release > -- > > Key: MRELEASE-426 > URL: https://jira.codehaus.org/browse/MRELEASE-426 > Project: Maven 2.x Release Plugin > Issue Type: Improvement > Components: perform >Affects Versions: 2.0-beta-8 > Environment: Maven2, CVSNT >Reporter: Eric > > When using the release-plugin with CVS, there does not seem to be any way to > specify a version & versionType to base the release on. > The scm plugin allows to specify scmVersion, scmVersionType to pass this > information to the plugin, but when calling the release:perform goal, there > is no way to send this information to the scm plugin to checkout the files > from the appropriate branch/tag. > Accordingly, it seems that with CVS, the only way to build a release is from > the latest sources in the HEAD; not extremely practical. -- 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
