[jira] Commented: (WAGON-323) CLONE -keyboard-interactive method is used even when password is supplied
[ http://jira.codehaus.org/browse/WAGON-323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=262639#action_262639 ] Bernd Vogt commented on WAGON-323: -- Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200) Java version: 1.6.0_21 OS name: windows 7 version: 6.1 arch: amd64 Family: windows CLONE -keyboard-interactive method is used even when password is supplied - Key: WAGON-323 URL: http://jira.codehaus.org/browse/WAGON-323 Project: Maven Wagon Issue Type: Bug Components: wagon-ssh Affects Versions: 1.0-beta-4 Environment: Maven version: 2.0.10-RC8 Java version: 1.5.0_13 Default locale: en_US, platform encoding: ISO8859-1 OS name: sunos version: 5.10 arch: sparc family: unix Reporter: Bernd Vogt Assignee: Brett Porter Fix For: 1.0-beta-5 Starting from 2.0.10-RC8 deploy (with ssh and password) started to fail - I'm getting: [DEBUG] Connecting to repository: 'repo.sandsli.dnb.no' with url: 'scp://repo.sandsli.dnb.no/dnb/data/proximity/inhouse.snapshot/storage'. Keyboard interactive required, supplied password is ignored event though the pw is in settings.xml: With help from Brett this was added: build extensions extension groupIdorg.apache.maven.wagon/groupId artifactIdwagon-ssh/artifactId version1.0-beta-2/version /extension /extensions which resolved the case. Fragment from settings.xml: servers server usernameMyUser/username passwordMySecret/password filePermissions777/filePermissions directoryPermissions777/directoryPermissions idrepo.sandsli.dnb.no/id /server Fragment from pom.xml: distributionManagement repository idrepo.sandsli.dnb.no/id nameDnBNOR Felles Repository/name urlscp://repo.sandsli.dnb.no/dnb/data/proximity/inhouse/storage/url /repository snapshotRepository idrepo.sandsli.dnb.no/id nameDnBNOR Felles Snapshot Repository/name urlscp://repo.sandsli.dnb.no/dnb/data/proximity/inhouse.snapshot/storage/url /snapshotRepository site idrepo.sandsli.dnb.no/id urlscp://repo.sandsli.dnb.no/dnb/prosess/prosjektdok/no.dnbnor.websphere-1.3-SNAPSHOT/websphere-testenvironment/url /site /distributionManagement -- 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: (MPIR-223) Dependency report introduces corruption in classpaths for other plugins
Dependency report introduces corruption in classpaths for other plugins --- Key: MPIR-223 URL: http://jira.codehaus.org/browse/MPIR-223 Project: Maven 2.x Project Info Reports Plugin Issue Type: Bug Components: dependencies Affects Versions: 2.3.1, 2.3 Reporter: Carlos Sanchez Attachments: maven-project-info-report-defect-2.3.1.zip MPIR-144 shows up again per Neil Hartner comments. Creating this new issue This issue has reappeared in 2.3.1. I'm attaching an updated version of the zipped maven project that reproduces this issue. You can change which version of MPIR plugin to use with -Dmpir-version. For example: mvn clean install site:site -Dmpir-version=2.3.1 2.1, 2.3 and 2.3.1 will fail 2.1.1 and 2.2 will succeed -- 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: (MPIR-144) Dependency report introduces corruption in classpaths for other plugins
[ http://jira.codehaus.org/browse/MPIR-144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=262640#action_262640 ] Carlos Sanchez commented on MPIR-144: - Opened a new issue per Neil's comments MPIR-223. Please check MPIR-146 too which this issue duplicates Dependency report introduces corruption in classpaths for other plugins --- Key: MPIR-144 URL: http://jira.codehaus.org/browse/MPIR-144 Project: Maven 2.x Project Info Reports Plugin Issue Type: Bug Components: dependencies Affects Versions: 2.1 Environment: Maven version: 2.0.8 Java version: 1.5.0_11 OS name: linux version: 2.6.9-42.elsmp arch: i386 Family: unix (RHEL 4) Reporter: Robert Golkosky Priority: Critical Attachments: failure-run.log, maven-project-info-report-defect-2.3.1.zip, maven-project-info-report-defect.tar.gz, MPIR-144-example2.zip, successful-run.log When enabling the dependency report of the project info reports plugin and generating the site for a multi-module project, it appears that the classpaths being constructed for the compile and surefire plugins are being altered. This only occurs when the dependency report is enabled, i.e. the build succeeds and the site can be generated without the dependency report enabled. I've attached a simple maven project which demonstrates the failure. You can observe the successful build by running mvn clean install site:site, and the failure scenario by enabling the profile projectReports: mvn clean install site:site -P projectReports. You can also find debug logs attached for both a successful build and a failed build. The build failure is caused by improperly adding the test jar artifact for project-a to the testCompile classpath of project-c. In the successful build scenario, project-c will receive the primary project-a jar artifact transitively through interface-b. Even more interesting is the fact that if project-c includes a direct dependency on project-a, the test jar artifact will still be added to the classpath. One final note about the sample project, removing the dependency from project-c to project-b has no impact on the build failure, but removing project-b from the reactor (i.e. comment out the project-b module from the main pom.xml) will cause the failure to go away. This problem does not occur with version 2.0.1 of the project info reports plugin. I also tried Maven 2.1-M1 to see if the problem might be resolved there, but the classpath corruption still occurs. The root cause of this problem may actually lie in a shared component like maven-dependency-tree, but I found it originally through the use of the project info reports plugin so I figured this would be a good place to start tracking it down. -- 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-597) Workspace dependencies not resolved for SNAPSHOT dependencies (artifact has a different version from that in dependency management)
[
http://jira.codehaus.org/browse/MECLIPSE-597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=262648#action_262648
]
Yves Langisch commented on MECLIPSE-597:
We are regularly stumbling over this issue which leads to time costly manually
work. Is there any reason why the provided patch is not applied yet? I could
provide a new patch against the trunk if necessary.
Thanks
Yves
Workspace dependencies not resolved for SNAPSHOT dependencies (artifact has a
different version from that in dependency management)
---
Key: MECLIPSE-597
URL: http://jira.codehaus.org/browse/MECLIPSE-597
Project: Maven 2.x Eclipse Plugin
Issue Type: Bug
Components: Core : Dependencies resolution and build path
(.classpath)
Affects Versions: 2.7
Environment: Nexus 1.3.6, Eclipse 3.4, Windows XP
Reporter: Michal Galet
Priority: Critical
Attachments: maven-eclipse-plugin-2.7.patch
When generating eclipse project with mvn eclipse:eclipse
-Declipse.workspace=d:/eclipse-ws the SNAPSHOT dependencies are not resolved
from workspace correctly. See console output below. This is probably caused
by the way how Nexus handles the SNAPSHOTs. The artifact is resolved by
ArtifactResolver and the version is changed from 1.1.0-SNAPSHOT to
1.1.0-20090819.145009-4.
The comparison should be performed against {{artifact.getBaseVersion()}}
instead of {{artifact.getVersion()}}. A simple fix is attached as a patch.
Console output:
[INFO] Artifact com.test:sample:jar:4.0.0.B02-SNAPSHOT already available a
s a workspace project, but with different version. Expected:
4.0.0.B02-20090819.145009-4, found
: 4.0.0.B02-SNAPSHOT
--
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: (MECLIPSE-597) Workspace dependencies not resolved for SNAPSHOT dependencies (artifact has a different version from that in dependency management)
[
http://jira.codehaus.org/browse/MECLIPSE-597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=262648#action_262648
]
Yves Langisch edited comment on MECLIPSE-597 at 4/6/11 3:55 AM:
We are regularly stumbling over this issue which leads to time costly manual
work. Is there any reason why the provided patch is not applied yet? I could
provide a new patch against the trunk if necessary.
Thanks
Yves
was (Author: ylangisc):
We are regularly stumbling over this issue which leads to time costly
manually work. Is there any reason why the provided patch is not applied yet? I
could provide a new patch against the trunk if necessary.
Thanks
Yves
Workspace dependencies not resolved for SNAPSHOT dependencies (artifact has a
different version from that in dependency management)
---
Key: MECLIPSE-597
URL: http://jira.codehaus.org/browse/MECLIPSE-597
Project: Maven 2.x Eclipse Plugin
Issue Type: Bug
Components: Core : Dependencies resolution and build path
(.classpath)
Affects Versions: 2.7
Environment: Nexus 1.3.6, Eclipse 3.4, Windows XP
Reporter: Michal Galet
Priority: Critical
Attachments: maven-eclipse-plugin-2.7.patch
When generating eclipse project with mvn eclipse:eclipse
-Declipse.workspace=d:/eclipse-ws the SNAPSHOT dependencies are not resolved
from workspace correctly. See console output below. This is probably caused
by the way how Nexus handles the SNAPSHOTs. The artifact is resolved by
ArtifactResolver and the version is changed from 1.1.0-SNAPSHOT to
1.1.0-20090819.145009-4.
The comparison should be performed against {{artifact.getBaseVersion()}}
instead of {{artifact.getVersion()}}. A simple fix is attached as a patch.
Console output:
[INFO] Artifact com.test:sample:jar:4.0.0.B02-SNAPSHOT already available a
s a workspace project, but with different version. Expected:
4.0.0.B02-20090819.145009-4, found
: 4.0.0.B02-SNAPSHOT
--
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: (SUREFIRE-723) All tests are executed when -Dtest= option is specified
All tests are executed when -Dtest= option is specified --- Key: SUREFIRE-723 URL: http://jira.codehaus.org/browse/SUREFIRE-723 Project: Maven Surefire Issue Type: Bug Components: Maven Surefire Plugin Affects Versions: 2.8 Environment: Kubuntu 10.10 Maven 2.2.1 Reporter: Sami Nieminen Before version 2.8 it was possible to generate the test jar packages without actually running the unit tests by specifying the option -Dtest= (mvn install -Dtest=). This has changed with 2.8 since now this option doesn't seem to have any effect, i.e. all the tests are executed. -- 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: (MCOMPILER-152) Mention tycho-compiler-jdt on the Non-javac compilerIds documentation page
Mention tycho-compiler-jdt on the Non-javac compilerIds documentation page Key: MCOMPILER-152 URL: http://jira.codehaus.org/browse/MCOMPILER-152 Project: Maven 2.x Compiler Plugin Issue Type: Improvement Affects Versions: 2.3.2 Reporter: Olivier Michallat Priority: Minor Attachments: MCOMPILER-mention_tycho_binding.patch The Tycho project provides an alternate implementation of the Eclipse compiler binding. It uses a more recent version of the JDT, and handles compilerArguments correctly. I believe using this artifact would solve MCOMPILER-123, and possibly other Eclipse-related issues. For what it's worth, I'm attaching a patch that adds a mention to the artifact in the generated site. -- 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-597) Workspace dependencies not resolved for SNAPSHOT dependencies (artifact has a different version from that in dependency management)
[
http://jira.codehaus.org/browse/MECLIPSE-597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=262657#action_262657
]
Thomas Maurer commented on MECLIPSE-597:
The environment is irrelevant, because it occurs also with a Archiva 1.2.1
repository. The problem arise only during a workspace dependency resolution on
a single project (child pom, respectively) and not during a reactor dependency
resolution on a parent pom. As Michal already described, the reason is that the
ArtifactResolver changes the artifact version in its resolve() method (line 594
in class org.apache.maven.plugin.ide.AbstractIdeSupportMojo). Using
artifact.getBaseVersion() in the subsequent code would solve the problem.
Workspace dependencies not resolved for SNAPSHOT dependencies (artifact has a
different version from that in dependency management)
---
Key: MECLIPSE-597
URL: http://jira.codehaus.org/browse/MECLIPSE-597
Project: Maven 2.x Eclipse Plugin
Issue Type: Bug
Components: Core : Dependencies resolution and build path
(.classpath)
Affects Versions: 2.7
Environment: Nexus 1.3.6, Eclipse 3.4, Windows XP
Reporter: Michal Galet
Priority: Critical
Attachments: maven-eclipse-plugin-2.7.patch
When generating eclipse project with mvn eclipse:eclipse
-Declipse.workspace=d:/eclipse-ws the SNAPSHOT dependencies are not resolved
from workspace correctly. See console output below. This is probably caused
by the way how Nexus handles the SNAPSHOTs. The artifact is resolved by
ArtifactResolver and the version is changed from 1.1.0-SNAPSHOT to
1.1.0-20090819.145009-4.
The comparison should be performed against {{artifact.getBaseVersion()}}
instead of {{artifact.getVersion()}}. A simple fix is attached as a patch.
Console output:
[INFO] Artifact com.test:sample:jar:4.0.0.B02-SNAPSHOT already available a
s a workspace project, but with different version. Expected:
4.0.0.B02-20090819.145009-4, found
: 4.0.0.B02-SNAPSHOT
--
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: (MINDEXER-26) NPE from IndexWriter.isLocked in DefaultIndexingContext.prepareCleanIndex
[
http://jira.codehaus.org/browse/MINDEXER-26?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=262660#action_262660
]
Tamás Cservenák commented on MINDEXER-26:
-
As I see from NetBeans issue, this NPE happened _within_ DefaultIndexingContext
constructor, so I would rule out that same context's -- that is just being
constructed -- close() method was called. This code is called from constructor,
and having indexDirectory {{null}} means something really bad.
{{close()}} method contains null check to make possible calling it multiple
times without any problem (closing already closed context does nothing, is
harmless).
According stack trace and Affects version, the DefaultIndexingContext with File
parameter is called (this rules out calling another constructor with {{null}}
Directory as parameter). But here, that would mean {{FSDirectory.open()}}
returns {{null}}, which again seems unlikely after inspecting the code.
...unless {{warmUp( NexusIndexSearcher searcher )}} failed with IOException. It
seems we eat some information here...
NPE from IndexWriter.isLocked in DefaultIndexingContext.prepareCleanIndex
-
Key: MINDEXER-26
URL: http://jira.codehaus.org/browse/MINDEXER-26
Project: Maven Indexer
Issue Type: Bug
Affects Versions: 4.0.0
Environment: VM: Java HotSpot(TM) 64-Bit Server VM, 19.0-b09,
Java(TM) SE Runtime
Environment, 1.6.0_23-b05
OS: Windows 7
Reporter: Jesse Glick
http://netbeans.org/bugzilla/show_bug.cgi?id=197346 reported by a NetBeans
user in a build embedding Maven Indexer 4.0.0.
{noformat}
if ( IndexWriter.isLocked( indexDirectory ) )
{
IndexWriter.unlock( indexDirectory );
}
{noformat}
Looks like {[indexDirectory}} is null, perhaps due to {{close}} having been
called, and this code does not check for that (other code in the same class
does). Can probably be guarded with a simple null check?
--
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: (MINDEXER-26) NPE from IndexWriter.isLocked in DefaultIndexingContext.prepareCleanIndex
[
http://jira.codehaus.org/browse/MINDEXER-26?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=262664#action_262664
]
Tamás Cservenák commented on MINDEXER-26:
-
Just to clean up my previous hazy comment that contained a revelation. So yes,
it seems that {{warmUp()}}, when throws IOEx actually closes the context, but
then later a prepare clean index is tried, and NPEs. And all this might
happen from constructor too.
NPE from IndexWriter.isLocked in DefaultIndexingContext.prepareCleanIndex
-
Key: MINDEXER-26
URL: http://jira.codehaus.org/browse/MINDEXER-26
Project: Maven Indexer
Issue Type: Bug
Affects Versions: 4.0.0
Environment: VM: Java HotSpot(TM) 64-Bit Server VM, 19.0-b09,
Java(TM) SE Runtime
Environment, 1.6.0_23-b05
OS: Windows 7
Reporter: Jesse Glick
http://netbeans.org/bugzilla/show_bug.cgi?id=197346 reported by a NetBeans
user in a build embedding Maven Indexer 4.0.0.
{noformat}
if ( IndexWriter.isLocked( indexDirectory ) )
{
IndexWriter.unlock( indexDirectory );
}
{noformat}
Looks like {[indexDirectory}} is null, perhaps due to {{close}} having been
called, and this code does not check for that (other code in the same class
does). Can probably be guarded with a simple null check?
--
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: (MSITE-472) Navigation links from maven-project-info-reports disappear when using maven-site-plugin 3.0-beta-1-SNAPSHOT and POM references parent POM
[ http://jira.codehaus.org/browse/MSITE-472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl closed MSITE-472. --- Resolution: Fixed Fix Version/s: 3.0-beta-4 Assignee: Lukas Theussl This seems fixed (tested with m3.0.3, site-plugin-3.0-beta-3, pir-2.3.1). Navigation links from maven-project-info-reports disappear when using maven-site-plugin 3.0-beta-1-SNAPSHOT and POM references parent POM - Key: MSITE-472 URL: http://jira.codehaus.org/browse/MSITE-472 Project: Maven 2.x and 3.x Site Plugin Issue Type: Bug Components: Maven 3, multi module Affects Versions: 3.0-beta-1 Environment: Maven 3.0-alpha-7, JDK 6 Reporter: Michael Pilquist Assignee: Lukas Theussl Fix For: 3.0-beta-4 Attachments: site-parent-issue.zip If a project has a parent POM, no navigation links are generated in the submodule's site. The parent site has navigation however. This behavior occurs both when parent is in the reactor and when it is not. Attached is a very simple multimodule build consisting of a single parent POM and a JAR module. After running mvn clean install site, observe that target/site/index.html has the proper navigation but parent-usage-test/target/site/index.html has an empty navigation panel. This may be a bug in project-info-reports but since it works correctly when there's no parent POM, I thought this was the correct project. -- 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: (MSITE-519) overwrite inherited menu item or add addition item to inherited menu
[ http://jira.codehaus.org/browse/MSITE-519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl closed MSITE-519. --- Resolution: Duplicate Assignee: Lukas Theussl overwrite inherited menu item or add addition item to inherited menu Key: MSITE-519 URL: http://jira.codehaus.org/browse/MSITE-519 Project: Maven 2.x and 3.x Site Plugin Issue Type: Bug Components: inheritance Affects Versions: 3.0-beta-3 Environment: maven 3.0 Reporter: Thomas Wabner Assignee: Lukas Theussl I have a parent project with a site descriptor where I have defined a menu like this: ... menu name=Overview inherit=top item name=Introduction href=/index.html / /menu ... Now I have a child project which should overwrite OR add addition item(s) to the inherited site descriptor like this: ... menu name=Overview item name=Introduction href=/index.html / item name=Deployment instruction href=/deploy.html / /menu ... The current behavior is that the Overview menu is rendered twice in the resulting site. But I expect that the additional menu item will be mixed into the Overview menu. -- 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: (SCM-615) RemoveMojo to allow removing resources from version control
RemoveMojo to allow removing resources from version control --- Key: SCM-615 URL: http://jira.codehaus.org/browse/SCM-615 Project: Maven SCM Issue Type: Improvement Components: maven-plugin Affects Versions: 1.5 Reporter: Paul Mackinlay Attachments: remove_mojo_patch.txt A patch file is included. Running the junit test shows that although the remove command fails, it is not propagated to the mojo class. It is suggested that PerforceRemoveCommand.executeRemoveCommand() is changed to rethrow CommandLineException as a ScmException. -- 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: (MJARSIGNER-14) Keystore password should be entered in an interactive way
Keystore password should be entered in an interactive way
-
Key: MJARSIGNER-14
URL: http://jira.codehaus.org/browse/MJARSIGNER-14
Project: Maven 2.x Jar Signer Plugin
Issue Type: Improvement
Affects Versions: 1.2
Reporter: Eric TOURNIER
Priority: Minor
For security reasons, it could be useful not to configure keystore password in
the {{pom.xml}} file. Then, when these informations are missing, the plugin
should ask the user to enter this password in an interactive way.
--
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: (MJARSIGNER-14) Keystore password should be entered in an interactive way
[
http://jira.codehaus.org/browse/MJARSIGNER-14?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric TOURNIER updated MJARSIGNER-14:
Attachment: MJARSIGNER-14-maven-jarsigner-plugin.patch
This patch asks the user for a keystore password if it not configured in pom.xml
The case of a missing key password is not included in this patch
Keystore password should be entered in an interactive way
-
Key: MJARSIGNER-14
URL: http://jira.codehaus.org/browse/MJARSIGNER-14
Project: Maven 2.x Jar Signer Plugin
Issue Type: Improvement
Affects Versions: 1.2
Reporter: Eric TOURNIER
Priority: Minor
Attachments: MJARSIGNER-14-maven-jarsigner-plugin.patch
For security reasons, it could be useful not to configure keystore password
in the {{pom.xml}} file. Then, when these informations are missing, the
plugin should ask the user to enter this password in an interactive way.
--
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-4715) version expression constant
[
http://jira.codehaus.org/browse/MNG-4715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=262679#action_262679
]
Axel Fontaine commented on MNG-4715:
I also believe expressions should be allowed.
This enables you to decouple updating your version number from checking in to
version control, which is one of the big problems with the traditional Maven
release process.
This way, the only change actually commited for a new release is the code. No
need to additionally modify the POM.
I've described this in detail here:
http://www.axelfontaine.com/2011/01/maven-releases-on-steroids-adios.html
version expression constant
---
Key: MNG-4715
URL: http://jira.codehaus.org/browse/MNG-4715
Project: Maven 2 3
Issue Type: Improvement
Components: Dependencies, POM
Affects Versions: 3.0-alpha-6, 3.0-alpha-7, 3.0-beta-1
Environment: eclipse linux xp
Reporter: Faruk
Priority: Critical
Fix For: Issues to be reviewed for 3.x
Attachments: untitled.JPG
early versions, we define modules versions with expressions, and set them to
the parent pom,
simply;
properties
ibb-core-cache.version1.0.1/ibb-core-cache.version
ibb-core-util.version1.0.1/ibb-core-util.version
/properties
and then, we give this property to modules pom as expression ,
nameik-plug/name
packagingjar/packaging
version${ibb-core-util.versionn}/version
but know , it gives an error you know like this,
[WARNING] Some problems were encountered while building the effective model
for ibb-parent:ibb-modules-parent:pom:1.0.0
[WARNING] 'version' contains an expression but should be a constant. @
ibb-parent:ibb-modules-parent:${ibb-core-jars.version},
C:\dev\ibb\workspace\core\ibb-modules-parent\pom.xml
but I think that, this enhancement is causes wrong result,
think that , if we have i project already developing about 3 years, this
project has a lot of modules, and this modules have sub modules , and this
sub modules already bound to some other modules not define in your pom, but
your updates must be affect them, at this situation, developer want to write
the existing version numbers with properties to parent pom, and want to
manage them like this. at the attach file below , the close projects are
belongs to open projects, but they are the different team developing this. I
cant force the other developers to cache their versions, I must use this
versions as initial step
--
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: (SCM-615) RemoveMojo to allow removing resources from version control
[ http://jira.codehaus.org/browse/SCM-615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated SCM-615: - Fix Version/s: 1.6 Assignee: Olivier Lamy RemoveMojo to allow removing resources from version control --- Key: SCM-615 URL: http://jira.codehaus.org/browse/SCM-615 Project: Maven SCM Issue Type: Improvement Components: maven-plugin Affects Versions: 1.5 Reporter: Paul Mackinlay Assignee: Olivier Lamy Fix For: 1.6 Attachments: remove_mojo_patch.txt A patch file is included. Running the junit test shows that although the remove command fails, it is not propagated to the mojo class. It is suggested that PerforceRemoveCommand.executeRemoveCommand() is changed to rethrow CommandLineException as a ScmException. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-5059) --also-make-phase
--also-make-phase
-
Key: MNG-5059
URL: http://jira.codehaus.org/browse/MNG-5059
Project: Maven 2 3
Issue Type: Improvement
Components: Command Line
Affects Versions: 3.0.3
Reporter: Jesse Glick
Background:
http://mail-archives.apache.org/mod_mbox/maven-dev/201104.mbox/%3Cincnbn$4kl$1...@dough.gmane.org%3E
{{--also-make}} (with {{--projects}}) is useful, but suffers from the problem
that dependent projects are always built to the same goal/phase as the selected
project(s). That is fine for e.g. {{compile}} or {{install}}, but not for e.g.
{{test}} where you would only want to build {{compile}} (or {{test-compile}})
for dependencies, not actually test them.
Suggest a variant form of this parameter (say {{--also-make-phase}} / {{-amp}})
which would accept a goal or phase to run on dependencies in place of the
regular arguments. For example, to run a unit test after making sure all its
dependencies have been (re-)compiled:
{noformat}
mvn -amp test-compile -pl testedmod test -Dtest=OneTest
{noformat}
or to run an (unpacked) web application after (re-)compiling libraries it uses:
{noformat}
mvn -amp compile -pl webapp jetty:run
{noformat}
You might want to pass a goal rather than a phase, so the name could be
misleading, but I think that would be a rarer use case. Ditto passing multiple
goals/phases for the upstream projects.
--
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: (ARCHETYPE-369) scripting support
scripting support - Key: ARCHETYPE-369 URL: http://jira.codehaus.org/browse/ARCHETYPE-369 Project: Maven Archetype Issue Type: New Feature Components: Generator Affects Versions: 2.0 Reporter: Lucien Weller I tried to implement a scripting support for maven-archetype. See git pull request (https://github.com/apache/maven-archetype/pull/1) for further details. -- 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-672) branching a sub module during a build
branching a sub module during a build
-
Key: MRELEASE-672
URL: http://jira.codehaus.org/browse/MRELEASE-672
Project: Maven 2.x Release Plugin
Issue Type: Bug
Affects Versions: 2.1
Environment: maven-release-plugin 2.1 with SVN
Reporter: Lucien Weller
We have to requirement to create a reparate branch of a part of your source
tree (concretely a sub module) somtime when building the entire tree. We
automated this with a profile in pom.xml of that sub-module where we configured
branch goal as part of packag phase with something like this:
profile
idmakeBranch/id
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-release-plugin/artifactId
executions
execution
idmake-branch/id
phasepackage/phase
goals
goalbranch/goal
/goals
configuration
branchNamere${project.version}-branch/branchName
developmentVersion${project.version}/developmentVersion
updateBranchVersionstrue/updateBranchVersions
releaseVersion${project.version}-00-SNAPSHOT/releaseVersion
/configuration
/execution
/executions
/plugin
/plugins
/build
/profile
Unfortunately we faced two problems:
* Scm URL was not correctly handled for sub-module, acording path of module.
This issue was already solved for Tagging in release preparation (see
MRELEASE-261). We ported the fix for branching.
* With actual implementation all projects of a rector build are considered by
branch goal. We solved this issue by filtering projects according their
relative path.
--
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-672) branching a sub module during a build
[
http://jira.codehaus.org/browse/MRELEASE-672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=262703#action_262703
]
Lucien Weller commented on MRELEASE-672:
pull request with fix provided on github (see
https://github.com/apache/maven-release/pull/1)
branching a sub module during a build
-
Key: MRELEASE-672
URL: http://jira.codehaus.org/browse/MRELEASE-672
Project: Maven 2.x Release Plugin
Issue Type: Bug
Affects Versions: 2.1
Environment: maven-release-plugin 2.1 with SVN
Reporter: Lucien Weller
We have to requirement to create a reparate branch of a part of your source
tree (concretely a sub module) somtime when building the entire tree. We
automated this with a profile in pom.xml of that sub-module where we
configured branch goal as part of packag phase with something like this:
profile
idmakeBranch/id
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-release-plugin/artifactId
executions
execution
idmake-branch/id
phasepackage/phase
goals
goalbranch/goal
/goals
configuration
branchNamere${project.version}-branch/branchName
developmentVersion${project.version}/developmentVersion
updateBranchVersionstrue/updateBranchVersions
releaseVersion${project.version}-00-SNAPSHOT/releaseVersion
/configuration
/execution
/executions
/plugin
/plugins
/build
/profile
Unfortunately we faced two problems:
* Scm URL was not correctly handled for sub-module, acording path of module.
This issue was already solved for Tagging in release preparation (see
MRELEASE-261). We ported the fix for branching.
* With actual implementation all projects of a rector build are considered by
branch goal. We solved this issue by filtering projects according their
relative path.
--
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: (SUREFIRE-723) All tests are executed when -Dtest= option is specified
[ http://jira.codehaus.org/browse/SUREFIRE-723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=262710#action_262710 ] Olivier Lamy commented on SUREFIRE-723: --- You can use -DskipTests [http://maven.apache.org/plugins/maven-surefire-plugin/test-mojo.html#skipTests] All tests are executed when -Dtest= option is specified --- Key: SUREFIRE-723 URL: http://jira.codehaus.org/browse/SUREFIRE-723 Project: Maven Surefire Issue Type: Bug Components: Maven Surefire Plugin Affects Versions: 2.8 Environment: Kubuntu 10.10 Maven 2.2.1 Reporter: Sami Nieminen Before version 2.8 it was possible to generate the test jar packages without actually running the unit tests by specifying the option -Dtest= (mvn install -Dtest=). This has changed with 2.8 since now this option doesn't seem to have any effect, i.e. all the tests are executed. -- 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: (SCM-616) Add the blame command to providers matrix
Add the blame command to providers matrix - Key: SCM-616 URL: http://jira.codehaus.org/browse/SCM-616 Project: Maven SCM Issue Type: Task Components: documentation Reporter: Simon Brandhof Priority: Minor Attachments: blame_site.diff The blame command is not listed in http://maven.apache.org/scm/matrix.html I checked the presence of GitCommand implementation to know if the command is functional. -- 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: (SCM-616) Add the blame command to providers matrix
[ http://jira.codehaus.org/browse/SCM-616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated SCM-616: - Fix Version/s: 1.6 Assignee: Olivier Lamy Add the blame command to providers matrix - Key: SCM-616 URL: http://jira.codehaus.org/browse/SCM-616 Project: Maven SCM Issue Type: Task Components: documentation Reporter: Simon Brandhof Assignee: Olivier Lamy Priority: Minor Fix For: 1.6 Attachments: blame_site.diff The blame command is not listed in http://maven.apache.org/scm/matrix.html I checked the presence of GitCommand implementation to know if the command is functional. -- 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
Re: jira-report - login to JIRA issue
I had the same problem, add a trailing slash (http://jira.company.com/?pid=12345). The code that parses the configuration needs it. -- View this message in context: http://maven.40175.n5.nabble.com/jira-report-login-to-JIRA-issue-tp3695580p4287113.html Sent from the Maven - Issues mailing list archive at Nabble.com.
[jira] Created: (SCM-617) Update documentation Provider Configuration Subversion
Update documentation Provider Configuration Subversion
--
Key: SCM-617
URL: http://jira.codehaus.org/browse/SCM-617
Project: Maven SCM
Issue Type: Task
Components: documentation, maven-scm-provider-svn
Affects Versions: 1.5
Reporter: Robert Scholte
Priority: Minor
SCM\-1.5 has a new {{svn-settings}} -parameter: {{useAuthCache}}, which is not
yet documented, see [http://maven.apache.org/scm/subversion.html]
--
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: (MCHANGELOG-120) Add inputEncoding parameter
Add inputEncoding parameter --- Key: MCHANGELOG-120 URL: http://jira.codehaus.org/browse/MCHANGELOG-120 Project: Maven 2.x Changelog Plugin Issue Type: Improvement Affects Versions: 2.2 Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 20:31:09+0300) Java version: 1.6.0_23, vendor: Sun Microsystems Inc. Default locale: ru_RU, platform encoding: Cp1251 OS name: windows 7, version: 6.1, arch: x86, family: windows svn, version 1.6.16 (r1073529) Reporter: Sergey Zakusov The plugin generates changelog reports incorrectly when there is used Cirillic in commit log messages. So it is required to specify character encoding (CP866/CP1251) to parse changelog response truly. -- 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: (SCM-616) Add the blame command to providers matrix
[ http://jira.codehaus.org/browse/SCM-616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgeny Mandrikov closed SCM-616. Resolution: Fixed fixed [rev 1089635|http://svn.apache.org/viewvc?view=revisionrevision=1089635] Thanks ! Add the blame command to providers matrix - Key: SCM-616 URL: http://jira.codehaus.org/browse/SCM-616 Project: Maven SCM Issue Type: Task Components: documentation Reporter: Simon Brandhof Assignee: Evgeny Mandrikov Priority: Minor Fix For: 1.6 Attachments: blame_site.diff The blame command is not listed in http://maven.apache.org/scm/matrix.html I checked the presence of GitCommand implementation to know if the command is functional. -- 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: (SCM-617) Update documentation Provider Configuration Subversion
[
http://jira.codehaus.org/browse/SCM-617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy updated SCM-617:
-
Fix Version/s: 1.6
Update documentation Provider Configuration Subversion
--
Key: SCM-617
URL: http://jira.codehaus.org/browse/SCM-617
Project: Maven SCM
Issue Type: Task
Components: documentation, maven-scm-provider-svn
Affects Versions: 1.5
Reporter: Robert Scholte
Priority: Minor
Fix For: 1.6
SCM\-1.5 has a new {{svn-settings}} -parameter: {{useAuthCache}}, which is
not yet documented, see [http://maven.apache.org/scm/subversion.html]
--
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: (MSITE-578) Incorrect and confusing site:stage goal documentation
Incorrect and confusing site:stage goal documentation
-
Key: MSITE-578
URL: http://jira.codehaus.org/browse/MSITE-578
Project: Maven 2.x and 3.x Site Plugin
Issue Type: Bug
Components: site:stage(-deploy)
Affects Versions: 2.2
Reporter: SebbASF
The site:stage goal contains the following doc:
generatedSiteDirectory:
Directory containing generated documentation.
* Type: java.io.File
* Required: Yes
* Expression: ${project.build.directory}/generated-site
The expression looks wrong.
The explanation is also a bit ambiguous - is the directory used to find already
generated documentation, or is it used as the output directory from site:stage?
In which case, how does it differ from outputDirectory ?
The page also contains:
outputDirectory:
Directory containing the generated project sites and report distributions.
* Type: java.io.File
* Required: Yes
* Expression: ${siteOutputDirectory}
* Default: ${project.reporting.outputDirectory}
Again, it's not obvious if this is an output or input directory.
Also, why is the parameter marked as Required when there is a default?
--
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: (MSITE-578) Incorrect and confusing documentation of site directories
[
http://jira.codehaus.org/browse/MSITE-578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukas Theussl updated MSITE-578:
Affects Version/s: 3.0-beta-3
Fix Version/s: 3.0-beta-4
2.3
Assignee: Lukas Theussl
Summary: Incorrect and confusing documentation of site
directories (was: Incorrect and confusing site:stage goal documentation)
As of version 2.3 (3.0-beta-4) the site:stage goal does not use these
parameters anymore, see MSITE-533. The above comments still apply to the
site:site goal, so I changed the title.
Incorrect and confusing documentation of site directories
-
Key: MSITE-578
URL: http://jira.codehaus.org/browse/MSITE-578
Project: Maven 2.x and 3.x Site Plugin
Issue Type: Bug
Components: site:stage(-deploy)
Affects Versions: 2.2, 3.0-beta-3
Reporter: SebbASF
Assignee: Lukas Theussl
Fix For: 2.3, 3.0-beta-4
The site:stage goal contains the following doc:
generatedSiteDirectory:
Directory containing generated documentation.
* Type: java.io.File
* Required: Yes
* Expression: ${project.build.directory}/generated-site
The expression looks wrong.
The explanation is also a bit ambiguous - is the directory used to find
already generated documentation, or is it used as the output directory from
site:stage? In which case, how does it differ from outputDirectory ?
The page also contains:
outputDirectory:
Directory containing the generated project sites and report distributions.
* Type: java.io.File
* Required: Yes
* Expression: ${siteOutputDirectory}
* Default: ${project.reporting.outputDirectory}
Again, it's not obvious if this is an output or input directory.
Also, why is the parameter marked as Required when there is a default?
--
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
