[jira] (MDEP-368) Configure plexus-archiver to use java.io.File methods to set permissions when available.
[
https://jira.codehaus.org/browse/MDEP-368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=306966#comment-306966
]
Olivier Lamy commented on MDEP-368:
---
@Tim Use this repository:
https://repository.apache.org/content/groups/snapshots/
Configure plexus-archiver to use java.io.File methods to set permissions when
available.
Key: MDEP-368
URL: https://jira.codehaus.org/browse/MDEP-368
Project: Maven 2.x Dependency Plugin
Issue Type: Improvement
Components: unpack, unpack-dependencies
Affects Versions: 2.5
Reporter: Tim Moore
Assignee: Olivier Lamy
Fix For: 2.5.1
Attachments: useJvmChmod.patch
We updated from maven-dependency-plugin 2.4 to 2.5 in our build, and found
that it slowed down significantly. Our build process involves unpacking
several large zip files, and profiling the build showed us that the extra
time was spent in Plexus Archiver's {{ArchiveEntryUtils.chmod}}, where it was
executing a {{chmod}} process for each file in the archive.
We tracked this change to an update of the Plexus Archiver dependency from
2.0 to 2.1.1 in version 2.5 of the Maven Dependency Plugin:
http://svn.apache.org/viewvc?view=revisionrevision=1292983
Plexus Archiver can be configured to use the {{setReadable}}, {{setWritable}}
and {{setExecutable}} methods on {{java.io.File}} instead of executing
{{chmod}}. These methods are new in Java 6, but Plexus Archiver invokes them
using reflection when they are available, falling back on executing {{chmod}}
when they are not, so it remains backwards compatible with Java 5.
This configuration is disabled by default, but can be configured via Plexus.
The attached patch to Maven Dependency Plugin sets the archiver components to
use the JVM implementation when available.
The patch doesn't include tests, since the behavior is dependent on the Java
version used, but when applied all of the existing tests pass in Java 6.
Credit for the investigation and the patch is due to Vincent Choy
(vc...@atlassian.com). He asked me to file this issue on his behalf.
--
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] (MPIR-251) Artifact ###### has no file error regression.
[
https://jira.codehaus.org/browse/MPIR-251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Myron updated MPIR-251:
---
Attachment: pom.xml
I reduced my POM to the minimum... and it only happens when i include my
uploaded oracle ojdbc driver and use PIR v2.4+
(Has been uploaded to our local Nexus 1.8.x months ago and has only the
generated POM)
Removing that doesn't display the errors...
Artifact ## has no file error regression.
-
Key: MPIR-251
URL: https://jira.codehaus.org/browse/MPIR-251
Project: Maven 2.x Project Info Reports Plugin
Issue Type: Bug
Components: dependencies
Affects Versions: 2.5
Reporter: Ian Brandt
Priority: Minor
Attachments: pom.xml
It appears that MPIR-158 has regressed. I'm seeing the same exact issue in
2.5 with Maven 3.0.4:
{noformat}
[INFO] Generating Dependencies report---
maven-project-info-reports-plugin:2.5
[ERROR] Artifact: com.sun:tools:jar:1.5.0 has no file.
[ERROR] Artifact: com.thoughtworks.xstream:xstream:jar:1.3 has no file.
[ERROR] Artifact: commons-beanutils:commons-beanutils:jar:1.8.0 has no file.
[ERROR] Artifact: commons-cli:commons-cli:jar:1.1 has no file.
[ERROR] Artifact: commons-codec:commons-codec:jar:1.3 has no file.
[ERROR] Artifact: commons-collections:commons-collections:jar:3.2.1 has no
file.
[ERROR] Artifact: commons-digester:commons-digester:jar:2.0 has no file.
[ERROR] Artifact: commons-fileupload:commons-fileupload:jar:1.2.2 has no file.
...{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MDEP-368) Configure plexus-archiver to use java.io.File methods to set permissions when available.
[
https://jira.codehaus.org/browse/MDEP-368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=306969#comment-306969
]
Tim Moore commented on MDEP-368:
OK with 2.5.1-SNAPSHOT (built locally) and useJvmChmodtrue/useJvmChmod in
the plugin configuration, my project's build went down from ~7 minutes to
2m26s. (y)
That's about the same as with version 2.4 (actually a little better!) Thanks
again!
Configure plexus-archiver to use java.io.File methods to set permissions when
available.
Key: MDEP-368
URL: https://jira.codehaus.org/browse/MDEP-368
Project: Maven 2.x Dependency Plugin
Issue Type: Improvement
Components: unpack, unpack-dependencies
Affects Versions: 2.5
Reporter: Tim Moore
Assignee: Olivier Lamy
Fix For: 2.5.1
Attachments: useJvmChmod.patch
We updated from maven-dependency-plugin 2.4 to 2.5 in our build, and found
that it slowed down significantly. Our build process involves unpacking
several large zip files, and profiling the build showed us that the extra
time was spent in Plexus Archiver's {{ArchiveEntryUtils.chmod}}, where it was
executing a {{chmod}} process for each file in the archive.
We tracked this change to an update of the Plexus Archiver dependency from
2.0 to 2.1.1 in version 2.5 of the Maven Dependency Plugin:
http://svn.apache.org/viewvc?view=revisionrevision=1292983
Plexus Archiver can be configured to use the {{setReadable}}, {{setWritable}}
and {{setExecutable}} methods on {{java.io.File}} instead of executing
{{chmod}}. These methods are new in Java 6, but Plexus Archiver invokes them
using reflection when they are available, falling back on executing {{chmod}}
when they are not, so it remains backwards compatible with Java 5.
This configuration is disabled by default, but can be configured via Plexus.
The attached patch to Maven Dependency Plugin sets the archiver components to
use the JVM implementation when available.
The patch doesn't include tests, since the behavior is dependent on the Java
version used, but when applied all of the existing tests pass in Java 6.
Credit for the investigation and the patch is due to Vincent Choy
(vc...@atlassian.com). He asked me to file this issue on his behalf.
--
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-867) Add a way to declare all project properties as environmentVariables
[ https://jira.codehaus.org/browse/SUREFIRE-867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold updated SUREFIRE-867: Labels: proposed-wontfix (was: ) Add a way to declare all project properties as environmentVariables --- Key: SUREFIRE-867 URL: https://jira.codehaus.org/browse/SUREFIRE-867 Project: Maven Surefire Issue Type: Improvement Components: Maven Surefire Plugin Reporter: Pierre Le Roux Labels: proposed-wontfix It could be great to have a new option such as *allPropertiesAsEnvironmentVariables* (by default : false) that would retrieve all context properties (project, parent project and activated profile properties) and add it as environment variables. -- 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-867) Add a way to declare all project properties as environmentVariables
[ https://jira.codehaus.org/browse/SUREFIRE-867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=307013#comment-307013 ] Kristian Rosenvold commented on SUREFIRE-867: - The disadvantage of this strategy is that it creates a wholesale import of unspecified environment variables to your project, which can effectively reduce build reproducibility. With the current system, the pom acts as an interface specification between your build and the external environment, which means its possible to understand which parameters will/can influence the build. I will be proposing this as a wontfix. Add a way to declare all project properties as environmentVariables --- Key: SUREFIRE-867 URL: https://jira.codehaus.org/browse/SUREFIRE-867 Project: Maven Surefire Issue Type: Improvement Components: Maven Surefire Plugin Reporter: Pierre Le Roux Labels: proposed-wontfix It could be great to have a new option such as *allPropertiesAsEnvironmentVariables* (by default : false) that would retrieve all context properties (project, parent project and activated profile properties) and add it as environment variables. -- 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-867) Add a way to declare all project properties as environmentVariables
[ https://jira.codehaus.org/browse/SUREFIRE-867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=307014#comment-307014 ] Pierre Le Roux commented on SUREFIRE-867: - I understand. That's why i also purposed to manage this with property patterns. Add a way to declare all project properties as environmentVariables --- Key: SUREFIRE-867 URL: https://jira.codehaus.org/browse/SUREFIRE-867 Project: Maven Surefire Issue Type: Improvement Components: Maven Surefire Plugin Reporter: Pierre Le Roux Labels: proposed-wontfix It could be great to have a new option such as *allPropertiesAsEnvironmentVariables* (by default : false) that would retrieve all context properties (project, parent project and activated profile properties) and add it as environment variables. -- 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] (MSKINS-63) Improve the sidebar layout
[ https://jira.codehaus.org/browse/MSKINS-63?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated MSKINS-63: - Attachment: MSKINS-63-2.patch This fixes active + expanded menuitem Improve the sidebar layout -- Key: MSKINS-63 URL: https://jira.codehaus.org/browse/MSKINS-63 Project: Maven Skins Issue Type: Improvement Components: Fluido Skin Affects Versions: fluido-1.3.0 Reporter: Simone Tripodi Attachments: MSKINS-63-2.patch, MSKINS-63.patch, Screen Shot 2012-08-22 at 2.49.25 PM.png, Screen Shot 2012-08-23 at 2.38.06 PM.png, Screen Shot 2012-08-23 at 2.40.06 PM.png, Screen Shot 2012-08-23 at 2.40.17 PM.png After upgrading Bootstrap to v2.1.0, sidebar back to look bad again, see the attached screenshot :S It could be improved starting, for example, from the Bootstrap [Sample|http://twitter.github.com/bootstrap/examples/fluid.html] (which is called _fluid_!!! :D) -- 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] (MSKINS-63) Improve the sidebar layout
[ https://jira.codehaus.org/browse/MSKINS-63?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MSKINS-63. -- Resolution: Fixed Fix Version/s: fluido-1.3.0 Assignee: Olivier Lamy patch from robert applied with modifications. Improve the sidebar layout -- Key: MSKINS-63 URL: https://jira.codehaus.org/browse/MSKINS-63 Project: Maven Skins Issue Type: Improvement Components: Fluido Skin Affects Versions: fluido-1.3.0 Reporter: Simone Tripodi Assignee: Olivier Lamy Fix For: fluido-1.3.0 Attachments: MSKINS-63-2.patch, MSKINS-63.patch, Screen Shot 2012-08-22 at 2.49.25 PM.png, Screen Shot 2012-08-23 at 2.38.06 PM.png, Screen Shot 2012-08-23 at 2.40.06 PM.png, Screen Shot 2012-08-23 at 2.40.17 PM.png After upgrading Bootstrap to v2.1.0, sidebar back to look bad again, see the attached screenshot :S It could be improved starting, for example, from the Bootstrap [Sample|http://twitter.github.com/bootstrap/examples/fluid.html] (which is called _fluid_!!! :D) -- 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] (MSITE-443) add a reportingManagement section
[
https://jira.codehaus.org/browse/MSITE-443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=307042#comment-307042
]
Diwaker Gupta commented on MSITE-443:
-
This *major* bug has been open for 7 years now. There seems be enough community
support for this feature. The Maven developers should either mark this as won't
fix or fix it for real, rather than let it linger in limbo forever.
add a reportingManagement section
-
Key: MSITE-443
URL: https://jira.codehaus.org/browse/MSITE-443
Project: Maven 2.x and 3.x Site Plugin
Issue Type: Bug
Environment: maven-site-plugin 2.0-beta-3-SNAPSHOT
Reporter: Indrajit Raychaudhuri
Consider the following POM:
{code:xml}
!-- ... ... --
!-- ... ... --
build
pluginManagement
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-javadoc-plugin/artifactId
configuration
authorfalse/author
/configuration
/plugin
/pluginManagement
/build
!-- ... ... --
!-- ... ... --
reporting
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-javadoc-plugin/artifactId
/plugin
/plugins
/reporting
!-- ... ... --
{code}
{{mvn site:site}} doesn't honor the javadoc configuration specified in the
{{pluginManagement/}} section.
However, {{mvn javadoc:javadoc}} honors them.
This is true not just for javadoc but other plugins like checkstyle as well.
I guess, the {{reporting/}} section doesn't use the {{pluginManagement/}}
section at all.
--
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-907) IllegalArgumentException from ThreadPoolExecutor.init in surefire.booterclient.ForkStarter.runSuitesForkPerTestSet
[
https://jira.codehaus.org/browse/SUREFIRE-907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=307046#comment-307046
]
Kristian Rosenvold edited comment on SUREFIRE-907 at 8/24/12 1:44 PM:
--
Fixed with IT in r1377032. Thanks for the report!
was (Author: krosenvold):
Fixed with IT in r1375109. Thanks for the report!
IllegalArgumentException from ThreadPoolExecutor.init in
surefire.booterclient.ForkStarter.runSuitesForkPerTestSet
Key: SUREFIRE-907
URL: https://jira.codehaus.org/browse/SUREFIRE-907
Project: Maven Surefire
Issue Type: Bug
Components: process forking
Affects Versions: 2.12.2
Environment: JDK 7u6, Ubuntu
Reporter: Jesse Glick
Assignee: Kristian Rosenvold
Priority: Minor
Fix For: 2.13.0
In some Maven project, e.g. {{maven-core}}, run:
{code:none}
$ mvn -DforkMode=perthread -e test
java.lang.IllegalArgumentException
at
java.util.concurrent.ThreadPoolExecutor.init(ThreadPoolExecutor.java:1275)
at
java.util.concurrent.ThreadPoolExecutor.init(ThreadPoolExecutor.java:1163)
at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.runSuitesForkPerTestSet(ForkStarter.java:142)
at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:122)
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:199)
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAllProviders(AbstractSurefireMojo.java:176)
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:135)
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:98)
{code}
Fix seems to be to specify {{-DthreadCount=something}}, but the mojo should
say so politely.
--
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-907) IllegalArgumentException from ThreadPoolExecutor.init in surefire.booterclient.ForkStarter.runSuitesForkPerTestSet
[
https://jira.codehaus.org/browse/SUREFIRE-907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Rosenvold closed SUREFIRE-907.
---
Resolution: Fixed
Fix Version/s: 2.13.0
Assignee: Kristian Rosenvold
Fixed with IT in r1375109. Thanks for the report!
IllegalArgumentException from ThreadPoolExecutor.init in
surefire.booterclient.ForkStarter.runSuitesForkPerTestSet
Key: SUREFIRE-907
URL: https://jira.codehaus.org/browse/SUREFIRE-907
Project: Maven Surefire
Issue Type: Bug
Components: process forking
Affects Versions: 2.12.2
Environment: JDK 7u6, Ubuntu
Reporter: Jesse Glick
Assignee: Kristian Rosenvold
Priority: Minor
Fix For: 2.13.0
In some Maven project, e.g. {{maven-core}}, run:
{code:none}
$ mvn -DforkMode=perthread -e test
java.lang.IllegalArgumentException
at
java.util.concurrent.ThreadPoolExecutor.init(ThreadPoolExecutor.java:1275)
at
java.util.concurrent.ThreadPoolExecutor.init(ThreadPoolExecutor.java:1163)
at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.runSuitesForkPerTestSet(ForkStarter.java:142)
at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:122)
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:199)
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAllProviders(AbstractSurefireMojo.java:176)
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:135)
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:98)
{code}
Fix seems to be to specify {{-DthreadCount=something}}, but the mojo should
say so politely.
--
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] (MSKINS-63) Improve the sidebar layout
[ https://jira.codehaus.org/browse/MSKINS-63?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy reopened MSKINS-63: Improve the sidebar layout -- Key: MSKINS-63 URL: https://jira.codehaus.org/browse/MSKINS-63 Project: Maven Skins Issue Type: Improvement Components: Fluido Skin Affects Versions: fluido-1.3.0 Reporter: Simone Tripodi Assignee: Olivier Lamy Fix For: fluido-1.3.0 Attachments: MSKINS-63-2.patch, MSKINS-63-icon-chevron.patch, MSKINS-63.patch, Screen Shot 2012-08-22 at 2.49.25 PM.png, Screen Shot 2012-08-23 at 2.38.06 PM.png, Screen Shot 2012-08-23 at 2.40.06 PM.png, Screen Shot 2012-08-23 at 2.40.17 PM.png After upgrading Bootstrap to v2.1.0, sidebar back to look bad again, see the attached screenshot :S It could be improved starting, for example, from the Bootstrap [Sample|http://twitter.github.com/bootstrap/examples/fluid.html] (which is called _fluid_!!! :D) -- 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] (MSKINS-63) Improve the sidebar layout
[ https://jira.codehaus.org/browse/MSKINS-63?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated MSKINS-63: --- Attachment: MSKINS-63-icon-chevron.patch patch to use icon-chevron Improve the sidebar layout -- Key: MSKINS-63 URL: https://jira.codehaus.org/browse/MSKINS-63 Project: Maven Skins Issue Type: Improvement Components: Fluido Skin Affects Versions: fluido-1.3.0 Reporter: Simone Tripodi Assignee: Olivier Lamy Fix For: fluido-1.3.0 Attachments: MSKINS-63-2.patch, MSKINS-63-icon-chevron.patch, MSKINS-63.patch, Screen Shot 2012-08-22 at 2.49.25 PM.png, Screen Shot 2012-08-23 at 2.38.06 PM.png, Screen Shot 2012-08-23 at 2.40.06 PM.png, Screen Shot 2012-08-23 at 2.40.17 PM.png After upgrading Bootstrap to v2.1.0, sidebar back to look bad again, see the attached screenshot :S It could be improved starting, for example, from the Bootstrap [Sample|http://twitter.github.com/bootstrap/examples/fluid.html] (which is called _fluid_!!! :D) -- 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] (MSKINS-63) Improve the sidebar layout
[ https://jira.codehaus.org/browse/MSKINS-63?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=307049#comment-307049 ] Olivier Lamy edited comment on MSKINS-63 at 8/24/12 3:27 PM: - patch to use icon-chevron live sample here: http://people.apache.org/~olamy/maven/skins/ was (Author: olamy): patch to use icon-chevron Improve the sidebar layout -- Key: MSKINS-63 URL: https://jira.codehaus.org/browse/MSKINS-63 Project: Maven Skins Issue Type: Improvement Components: Fluido Skin Affects Versions: fluido-1.3.0 Reporter: Simone Tripodi Assignee: Olivier Lamy Fix For: fluido-1.3.0 Attachments: MSKINS-63-2.patch, MSKINS-63-icon-chevron.patch, MSKINS-63.patch, Screen Shot 2012-08-22 at 2.49.25 PM.png, Screen Shot 2012-08-23 at 2.38.06 PM.png, Screen Shot 2012-08-23 at 2.40.06 PM.png, Screen Shot 2012-08-23 at 2.40.17 PM.png After upgrading Bootstrap to v2.1.0, sidebar back to look bad again, see the attached screenshot :S It could be improved starting, for example, from the Bootstrap [Sample|http://twitter.github.com/bootstrap/examples/fluid.html] (which is called _fluid_!!! :D) -- 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] (MGPG-9) gpg plugin hangs when it should prompt for the secret key passphrase hangs
[ https://jira.codehaus.org/browse/MGPG-9?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=307051#comment-307051 ] Javier A. Ortiz Bultron commented on MGPG-9: I still can't make it to work. I tried both work arounds and still have the same outcome. Any ideas? gpg plugin hangs when it should prompt for the secret key passphrase hangs -- Key: MGPG-9 URL: https://jira.codehaus.org/browse/MGPG-9 Project: Maven 2.x and 3.x GPG Plugin Issue Type: Bug Environment: Maven 2.0.6, JDK 1.5.0_11, Linux 2.6.x Reporter: Alex Karasulu Assignee: Benjamin Bentmann When used in conjunction with the release plugin the release:perform command hangs when it should prompt for the secret key passphrase. Interestingly enough when I put the passphrase into the settings.xml file the plugin does not hang. I suspect the prompt is failing to show up. -- 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] (MGPG-9) gpg plugin hangs when it should prompt for the secret key passphrase hangs
[ https://jira.codehaus.org/browse/MGPG-9?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=307051#comment-307051 ] Javier A. Ortiz Bultron edited comment on MGPG-9 at 8/24/12 3:55 PM: - I still can't make it to work. I tried both work arounds and still have the same outcome. Any ideas? When I try it on the command prompt like this: Z:\NetBeans\output-handlermvn -Dgpg.passphrase=pass -Prelease-sign-artifacts -Darguments=-Dgpg.passphrase=pass release:clean release:prepare release:perform It still prompts for the password. was (Author: javydreamercsw): I still can't make it to work. I tried both work arounds and still have the same outcome. Any ideas? gpg plugin hangs when it should prompt for the secret key passphrase hangs -- Key: MGPG-9 URL: https://jira.codehaus.org/browse/MGPG-9 Project: Maven 2.x and 3.x GPG Plugin Issue Type: Bug Environment: Maven 2.0.6, JDK 1.5.0_11, Linux 2.6.x Reporter: Alex Karasulu Assignee: Benjamin Bentmann When used in conjunction with the release plugin the release:perform command hangs when it should prompt for the secret key passphrase. Interestingly enough when I put the passphrase into the settings.xml file the plugin does not hang. I suspect the prompt is failing to show up. -- 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] (MEAR-141) No way to configure generate env-entry elements in generated application.xml
[
https://jira.codehaus.org/browse/MEAR-141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stéphane Nicoll closed MEAR-141.
Resolution: Fixed
Time. And now it's done. I also changed the tests so that they use envEntries
to make sure ITs will pass on Maven2
No way to configure generate env-entry elements in generated application.xml
Key: MEAR-141
URL: https://jira.codehaus.org/browse/MEAR-141
Project: Maven 2.x Ear Plugin
Issue Type: Improvement
Affects Versions: 2.6
Reporter: Laird Nelson
Assignee: Stéphane Nicoll
Fix For: 2.8
The maven-ear-plugin offers the {{security}} element for declaring
security-role-names in a generated application.xml. It does not offer such a
facility for generating {{env-entry}} elements. It should.
--
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] (MEAR-146) Expose parameter to not write library-directory element in application.xml
[ https://jira.codehaus.org/browse/MEAR-146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=307058#comment-307058 ] Stéphane Nicoll commented on MEAR-146: -- I see. Well. Let's do both then. Expose parameter to not write library-directory element in application.xml -- Key: MEAR-146 URL: https://jira.codehaus.org/browse/MEAR-146 Project: Maven 2.x Ear Plugin Issue Type: Improvement Affects Versions: 2.7 Environment: Oracle WebLogic Reporter: Alex Halovanic Priority: Minor Fix For: 2.8 Attachments: ear-remove-librarydirectory-IT.patch, ear-remove-librarydirectory-IT.patch, ear-remove-librarydirectory.patch, ear-remove-librarydirectory.patch The current handling of defaultLibBundleDir leads to some issues on Oracle Weblogic 10+. The Ear plugin currently sets library-directory to the value of defaultLibBundleDir in the application.xml for EARs v5+. Some of Oracle's classloading features break (specifically Generic File Loading) when this element is set. defaultLibBundleDir has to be set to APP-INF/lib since this is the magic library folder for WebLogic. The patch adds a parameter to prevent setting library-directory for cases like this. -- 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
