[jira] Commented: (MNG-2532) System properties cannot be set from Profiles or Settings.xml
[ https://jira.codehaus.org/browse/MNG-2532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=275654#comment-275654 ] David Artiga commented on MNG-2532: --- +1. Please re-open. System properties cannot be set from Profiles or Settings.xml - Key: MNG-2532 URL: https://jira.codehaus.org/browse/MNG-2532 Project: Maven 2 3 Issue Type: Bug Components: Profiles, Settings Affects Versions: 2.0.4 Environment: Windows XP Reporter: Peter Pilgrim Assignee: Brett Porter Hi All With the maven-antrun-plugin in Maven 2.0.4 is it possibly to define a system property. Instead of me doing this all the time. mvn install -Duser.install.root=C:\Program Files\IBM\WebSphere\AppServer For more info on the context see my blog http://www.jroller.com/page/peter_pilgrim?entry=how_to_configure_xemacs_http Specifically the system properties is not set up following to either a profiles.xml or settings.xml file by Maven 2 Possibly the system property I need is not also transfered to the Ant task using the maven-antrun-plugin. /* profiles.xml */ profiles profile iduser-install-root/id activation property name!user.install.root/name /property /activation properties user.install.rootC:\\Program Files\\IBM\\WebSphere\\AppServer/user.install.root /properties /profile /profiles Running mvn help:active-profiles, however, does show that the profile has been read. C:\WORKSP~2\M2SPRI~1\ejbmvn help:active-profiles [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'help'. [INFO] - --- [INFO] Building Maven 2.0 Spring EJB Research Project (EJB Module) [INFO]task-segment: [help:active-profiles] (aggregator-style) [INFO] - --- [INFO] [help:active-profiles] [INFO] Active Profiles for Project 'com.ubs.firc.ptsp.research.ejb:M2SpringEJBExample-e jb:ejb:1.0-SNAPSHOT': The following profiles are active: - user-install-root (source: profiles.xml) [INFO] [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 1 second [INFO] Finished at: Tue Aug 29 10:46:31 BST 2006 [INFO] Final Memory: 2M/5M [INFO] C:\WORKSP~2\M2SPRI~1\ejb Thanks Peter Pilgrim -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSANDBOX-51) Rewrite Plexus Utils classes at the ASF from scratch
[ https://jira.codehaus.org/browse/MSANDBOX-51?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=275655#comment-275655 ] Mark Struberg commented on MSANDBOX-51: --- Yes, there are classes which are currently in Ant and in commons and mostly maintained by the same committers. What I wanted to make clear is that quite a lot of the plexus-utils project is just a copy (+singular modifications) of ASF internal projects. So there is not much IP issue with those classes. Rewrite Plexus Utils classes at the ASF from scratch Key: MSANDBOX-51 URL: https://jira.codehaus.org/browse/MSANDBOX-51 Project: Maven 2.x Sandbox Issue Type: New Feature Reporter: Mark Struberg plexus-utils are 85% written by ASF committers, but we still don't have a IP cleared history. For cleaning this up we aim to rewrite those classes from scratch in ASF maven sandbox. The strategy is the following: 1. create unit tests for the existing plexus classes 2. create a new implementation from scratch 3. the new implementation must be a binary API compatible drop-in replacement -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-5154) repo1.maven.org should support HTTPS and HTTP requests should be redirected to HTTPS
[ https://jira.codehaus.org/browse/MNG-5154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann closed MNG-5154. -- Resolution: Not A Bug Please fill this request at https://issues.sonatype.org/browse/MVNCENTRAL. repo1.maven.org should support HTTPS and HTTP requests should be redirected to HTTPS Key: MNG-5154 URL: https://jira.codehaus.org/browse/MNG-5154 Project: Maven 2 3 Issue Type: Bug Reporter: Eric Rannaud As Java runs the Internet (sic), and that Maven is awesome (sic again -- these are real quotes, google them), man-in-the-middle attacks that inject bad code in downloaded JARs that are then happily and blindly executed on the machines of the developers that build the software that run the aforementioned Internet without any authentication whatsoever is not a very good idea. Once upon a time, when Maven was invented, back in 1985, there was an understandable certain naivete when it came to such things as security. The world was a happy place where no one tried to own developers machines, because nobody understood, yet, that developers machines are the best way to distribute malware all over the fricking place. But this is 2011, a year that saw shinny new social networks redirect all HTTP requests to HTTPS from day one, so I'm sure that now is a good time to reconsider. Thanks. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MJAR-139) New option to avoid empty jar creation
[
https://jira.codehaus.org/browse/MJAR-139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Rekveld updated MJAR-139:
--
Attachment: MJAR-139.patch
I took a look at the code and found a simple way to get this fixed.
In the {{AbstractJarMojo}} class, I added a parameter called {{skipIfEmpty}}
with a default value of false, this so not the change the behavior if the
parameter is not set.
If this flag is set to {{true}} and the {{getClassesDirectory()}} method
returns a directory that doesn't exist, then the archive creation will be
skipped.
But if it is set to {{false}} (or default) then the archive will be created
even if it is empty.
(i) This also applies to the jar goal.
Please take a look at the attached patch, no tests included.
I have deployed this patch in the 2.3.1-marvelution-1 version of the plugin
that is available here:
http://repository.marvelution.com/content/repositories/releases/
Cheers,
Mark
New option to avoid empty jar creation
--
Key: MJAR-139
URL: https://jira.codehaus.org/browse/MJAR-139
Project: Maven 2.x JAR Plugin
Issue Type: Improvement
Affects Versions: 2.3.1
Reporter: Roman Ivanov
Attachments: MJAR-139.patch
Usage of test-jar is beneficial for all project, as all of them have tests.
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-jar-plugin/artifactId
version2.3.1/version
executions
execution
goals
goaltest-jar/goal
/goals
/execution
/executions
/plugin
Pom artifacts and some jar artifacts does not have test and will never have
them.
In logs we have: [WARNING] JAR will be empty - no content was marked for
inclusion!
and empty and useless artifacts are created, deployed , ...
It will be convenient to have an plugin option to define whether skip empty
jar creation and warning or generate jar with warning in log. Does it make
sense ?
By default option will be FALSE, to comply with previous behavior.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-519) Timestamps on messages
[ https://jira.codehaus.org/browse/MNG-519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=275668#comment-275668 ] Scott MacDonald commented on MNG-519: - I'm not sure what is more amazing...That maven does not support timestamped logs, or that I have been a maven user for so many years and only just noticed. Timestamps on messages -- Key: MNG-519 URL: https://jira.codehaus.org/browse/MNG-519 Project: Maven 2 3 Issue Type: New Feature Components: Logging, Plugins and Lifecycle Reporter: Jeff Jensen Priority: Minor Fix For: 3.x / Backlog With current and/or moving forward with M2, I would like an option for timestamped messages. We have a somewhat long nightly process. I regularly wish for timestamps on the log messages from the Maven build. The two primary reasons for this are duration calculation - how long did something take, and an occasional correlation with an outside event. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MINDEXER-36) Add some OSGI metadata in the index to be able to search on
Add some OSGI metadata in the index to be able to search on --- Key: MINDEXER-36 URL: https://jira.codehaus.org/browse/MINDEXER-36 Project: Maven Indexer Issue Type: New Feature Reporter: Olivier Lamy Index at least : * Bundle-SymbolicName * Bundle-Version * Export-Package Others OSGI metadata ? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MJARSIGNER-17) The plugin should pass proxy information to the jarsigner command.
The plugin should pass proxy information to the jarsigner command. -- Key: MJARSIGNER-17 URL: https://jira.codehaus.org/browse/MJARSIGNER-17 Project: Maven 2.x Jar Signer Plugin Issue Type: Improvement Affects Versions: 1.2 Reporter: Christian Schulte Since 'jarsigner' may need to access network resources, the plugin should pass proxy information to the command. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-604) Properties from settings.xml are not recognized in site distribution management
[
https://jira.codehaus.org/browse/MSITE-604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=275674#comment-275674
]
Dennis Lundberg commented on MSITE-604:
---
Can you please attach an example of your settings.xml
Properties from settings.xml are not recognized in site distribution
management
Key: MSITE-604
URL: https://jira.codehaus.org/browse/MSITE-604
Project: Maven 2.x and 3.x Site Plugin
Issue Type: Bug
Components: site:deploy
Affects Versions: 3.0
Environment: Apache Maven 2.2.1 and 3.0.3
Reporter: Marcin Kuthan
My distribution management section looks like:
{code}
distributionManagement
site
id${acme-corporate-pom.siteRepositoryId}/id
url${acme-corporate-pom.siteRepositoryUrl}/url
/site
/distributionManagement
{code}
Where the default property values are defined in the pom:
{code}
properties
acme-corporate-pom.siteRepositoryIdacme-site/acme-corporate-pom.siteRepositoryId
acme-corporate-pom.siteRepositoryUrlscp://sites.intranet.acme.com/var/www/acme-corporate-pom.siteRepositoryUrl
/properties
{code}
I'm able redefine properties from command line, the provided repository is
used instead default one:
{code}
mvn site:site site:deploy
-Dacme-corporate-pom.siteRepositoryUrl=scp://somehost/var/www/sites
-Dacme-corporate-pom.siteRepositoryId=somehost
{code}
But when I redefine properties in the profile in {{settings.xml}}, they are
ignored. The profile is activated in {{activeProfiles}} element.
It looks, than only m-site-p ignores properties defined in the
{{settings.xml}} file. m-deploy-p recognizes properties as I expected
(distribution management section for articats deployment is configured in
similar way to site deployment).
--
Marcin Kuthan
Maven For Enterprise - http://code.google.com/p/m4enterprise/
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MJARSIGNER-17) The plugin should pass proxy information to the jarsigner command.
[ https://jira.codehaus.org/browse/MJARSIGNER-17?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte updated MJARSIGNER-17: Attachment: MJARSIGNER-17.patch Patch to support passing proxy information. The plugin should pass proxy information to the jarsigner command. -- Key: MJARSIGNER-17 URL: https://jira.codehaus.org/browse/MJARSIGNER-17 Project: Maven 2.x Jar Signer Plugin Issue Type: Improvement Affects Versions: 1.2 Reporter: Christian Schulte Attachments: MJARSIGNER-17.patch Since 'jarsigner' may need to access network resources, the plugin should pass proxy information to the command. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MJARSIGNER-15) ${jarsigner.arguments} expression does not work.
[
https://jira.codehaus.org/browse/MJARSIGNER-15?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schulte closed MJARSIGNER-15.
---
Resolution: Won't Fix
Fix Version/s: 1.0
Supported since Maven 3.0.3 - MNG-5011.
${jarsigner.arguments} expression does not work.
Key: MJARSIGNER-15
URL: https://jira.codehaus.org/browse/MJARSIGNER-15
Project: Maven 2.x Jar Signer Plugin
Issue Type: Bug
Affects Versions: 1.2
Reporter: Christian Schulte
Fix For: 1.0
Attachments: MJARSIGNER-15.patch
Trying to set additional arguments using -Djarsigner.arguments fails with:
[INFO] Failed to configure plugin parameters for:
org.apache.maven.plugins:maven-jarsigner-plugin:1.2
on the command line, specify: '-Djarsigner.arguments=VALUE'
Cause: Cannot assign configuration entry 'arguments' to 'class
[Ljava.lang.String;' from '${jarsigner.arguments}', which is of type class
java.lang.String
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-655) Maven Release Plugin Fails to perform the Release when using TFS scm
[ https://jira.codehaus.org/browse/MRELEASE-655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=275689#comment-275689 ] Dmitry Malenok commented on MRELEASE-655: - Workaroud: use Cross-platform command-line client for Team Foundation Server (from Microsoft Visual Studio Team Explorer Everywhere 2010) instead of native TFS command line utilites. Details: http://social.msdn.microsoft.com/Forums/en-AU/tee/thread/8ea3796d-acdd-4ec8-9c44-d9599512b0bb Maven Release Plugin Fails to perform the Release when using TFS scm Key: MRELEASE-655 URL: https://jira.codehaus.org/browse/MRELEASE-655 Project: Maven 2.x Release Plugin Issue Type: Bug Components: perform Affects Versions: 2.1 Environment: Windows 7 64 bit, Maven 3.0.1, Java 1.6_23, TFS 2010 Reporter: Nikhil Jain Priority: Blocker Labels: scrub-review-started Attachments: keymanager-release.log, Release_Command.txt We are able to prepare a build successfully using Prepare release but while performing release the release plugin is not able to perform release using TFS 2010. It errors due to incorrect sequence of SCM commands for TFS. The output of perform release is attached. For performing release we are issuing a command while specifies to use edit mode, Provides anew TFS workspace to map and a working directory to checkout code to perform a release. We are using the release plugin with TFS as suggested on Teamprise site http://kb.teamprise.com/article/view/95 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-552) Add useEditMode option to release:update-versions
[ https://jira.codehaus.org/browse/MRELEASE-552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=275697#comment-275697 ] Dmitry Malenok commented on MRELEASE-552: - This issue is a bug, but not an improvement. It is near to impossible to reset the readonly flag manually for the huge multi-modules project :( Add useEditMode option to release:update-versions - Key: MRELEASE-552 URL: https://jira.codehaus.org/browse/MRELEASE-552 Project: Maven 2.x Release Plugin Issue Type: Improvement Affects Versions: 2.0 Reporter: Russ Kociuba Priority: Minor Attachments: MRELEASE-552.patch My SCM (TFS) needs to checkout files in order to be able to edit them. Thus the current version of the update-versions goal fails because the files are read-only. The ability to set the useEditMode option to true would fix this. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (ARCHETYPE-378) Remove the parameter goalPrefix (and corresponding code) from the archetype:add-archetype-metadata mojo
[
https://jira.codehaus.org/browse/ARCHETYPE-378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy updated ARCHETYPE-378:
---
Fix Version/s: 2.1
Assignee: Olivier Lamy
Remove the parameter goalPrefix (and corresponding code) from the
archetype:add-archetype-metadata mojo
---
Key: ARCHETYPE-378
URL: https://jira.codehaus.org/browse/ARCHETYPE-378
Project: Maven Archetype
Issue Type: Task
Components: Plugin
Affects Versions: 2.0
Reporter: Benjamin Bentmann
Assignee: Olivier Lamy
Priority: Trivial
Fix For: 2.1
As questioned in [Archtypes and plugin
prefix|http://www.mail-archive.com/dev@maven.apache.org/msg89617.html], it
appears the parameter {{goalName}} of the {{add-archetype-metadata}} mojo
exists merely due to copypaste but has no real use in the context of
archetypes. As such the parameter and its backing code should be removed to
reduce confusion for end users and to keep the group-level metadata free from
bogus plugin prefix mappings for archetypes.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2163) Allow plugin dependencies to be excluded
[ https://jira.codehaus.org/browse/MNG-2163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=275710#comment-275710 ] LexeY commented on MNG-2163: I have jetty plugin and need to exclude jaas-1.0.jar from its dependencies. Need something like this: plugin groupIdorg.mortbay.jetty/groupId artifactIdmaven-jetty-plugin/artifactId version6.1.10/version exclusions exclusion artifactIdjaas/artifactId groupIdjaas/groupId /exclusion /exclusions /plugin I use IBM java, and java have this jar too, and i need use this jar only from JDK, not from jetty plugin. Now i have conflict. Allow plugin dependencies to be excluded Key: MNG-2163 URL: https://jira.codehaus.org/browse/MNG-2163 Project: Maven 2 3 Issue Type: New Feature Components: Dependencies Affects Versions: 2.0.2 Environment: Windows XP, Cygwin Reporter: Mark Hobson Fix For: Issues to be reviewed for 3.x Need to add an exclusions block in the POM for plugins. The use-case is excluding slf4j-simple from the jetty6 plugin in order to use an alternative slf4j implementation. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MJARSIGNER-15) ${jarsigner.arguments} expression does not work.
[
https://jira.codehaus.org/browse/MJARSIGNER-15?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg updated MJARSIGNER-15:
--
Fix Version/s: (was: 1.0)
${jarsigner.arguments} expression does not work.
Key: MJARSIGNER-15
URL: https://jira.codehaus.org/browse/MJARSIGNER-15
Project: Maven 2.x Jar Signer Plugin
Issue Type: Bug
Affects Versions: 1.2
Reporter: Christian Schulte
Attachments: MJARSIGNER-15.patch
Trying to set additional arguments using -Djarsigner.arguments fails with:
[INFO] Failed to configure plugin parameters for:
org.apache.maven.plugins:maven-jarsigner-plugin:1.2
on the command line, specify: '-Djarsigner.arguments=VALUE'
Cause: Cannot assign configuration entry 'arguments' to 'class
[Ljava.lang.String;' from '${jarsigner.arguments}', which is of type class
java.lang.String
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
