[jira] (SCM-689) Mercurial provider writes the cleartext password in log entries
[ https://jira.codehaus.org/browse/SCM-689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed SCM-689. Resolution: Fixed Fix Version/s: 1.8 applied. Thanks! > Mercurial provider writes the cleartext password in log entries > --- > > Key: SCM-689 > URL: https://jira.codehaus.org/browse/SCM-689 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-mercurial (hg) >Affects Versions: 1.7 >Reporter: Olivier Lamy >Assignee: Olivier Lamy > Fix For: 1.8 > > -- 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] (SCM-689) Mercurial provider writes the cleartext password in log entries
[ https://jira.codehaus.org/browse/SCM-689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=307316#comment-307316 ] Olivier Lamy commented on SCM-689: -- pull request: https://github.com/apache/maven-scm/pull/2 > Mercurial provider writes the cleartext password in log entries > --- > > Key: SCM-689 > URL: https://jira.codehaus.org/browse/SCM-689 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-mercurial (hg) >Affects Versions: 1.7 >Reporter: Olivier Lamy >Assignee: Olivier Lamy > -- 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] (SCM-689) Mercurial provider writes the cleartext password in log entries
[ https://jira.codehaus.org/browse/SCM-689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy reassigned SCM-689: Assignee: Olivier Lamy > Mercurial provider writes the cleartext password in log entries > --- > > Key: SCM-689 > URL: https://jira.codehaus.org/browse/SCM-689 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-mercurial (hg) >Affects Versions: 1.7 >Reporter: Olivier Lamy >Assignee: Olivier Lamy > -- 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] (SCM-689) Mercurial provider writes the cleartext password in log entries
Olivier Lamy created SCM-689: Summary: Mercurial provider writes the cleartext password in log entries Key: SCM-689 URL: https://jira.codehaus.org/browse/SCM-689 Project: Maven SCM Issue Type: Bug Components: maven-scm-provider-mercurial (hg) Affects Versions: 1.7 Reporter: Olivier Lamy -- 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] (MSHARED-235) Invalid artifact type with maven 3
[ https://jira.codehaus.org/browse/MSHARED-235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MSHARED-235. Resolution: Fixed Fix Version/s: maven-dependency-tree-2.1 patch applied. Thanks! > Invalid artifact type with maven 3 > -- > > Key: MSHARED-235 > URL: https://jira.codehaus.org/browse/MSHARED-235 > Project: Maven Shared Components > Issue Type: Bug > Components: maven-dependency-tree >Affects Versions: maven-dependency-tree-2.0 >Reporter: Tuomas Kiviaho >Assignee: Olivier Lamy >Priority: Blocker > Fix For: maven-dependency-tree-2.1 > > Attachments: Maven3DependencyGraphBuilder.patch > > > Maven3DependencyGraphBuilder seems to anticipate that type is always the same > as Aether artifact extension. This is not true for instance with > maven-bundle-plugin that uses 'jar' as extension but type as 'bundle'. > Included a small one-liner patch that fixes the problem. -- 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] (MSHARED-235) Invalid artifact type with maven 3
[ https://jira.codehaus.org/browse/MSHARED-235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy reassigned MSHARED-235: Assignee: Olivier Lamy > Invalid artifact type with maven 3 > -- > > Key: MSHARED-235 > URL: https://jira.codehaus.org/browse/MSHARED-235 > Project: Maven Shared Components > Issue Type: Bug > Components: maven-dependency-tree >Affects Versions: maven-dependency-tree-2.0 >Reporter: Tuomas Kiviaho >Assignee: Olivier Lamy >Priority: Blocker > Attachments: Maven3DependencyGraphBuilder.patch > > > Maven3DependencyGraphBuilder seems to anticipate that type is always the same > as Aether artifact extension. This is not true for instance with > maven-bundle-plugin that uses 'jar' as extension but type as 'bundle'. > Included a small one-liner patch that fixes the problem. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-269) Check that 'new development version' is a SNAPSHOT version
[ https://jira.codehaus.org/browse/MRELEASE-269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MRELEASE-269. --- Resolution: Fixed Fixed as part of MRELEASE-511 Unit test added in [r1378347|http://svn.apache.org/viewvc?rev=1378347&view=rev] > Check that 'new development version' is a SNAPSHOT version > --- > > Key: MRELEASE-269 > URL: https://jira.codehaus.org/browse/MRELEASE-269 > Project: Maven 2.x Release Plugin > Issue Type: Wish > Components: prepare >Affects Versions: 2.0-beta-6 >Reporter: Michael Meyer >Assignee: Robert Scholte > Labels: contributers-welcome > Fix For: Backlog > > > While executing 'mvn release:prepare' one gets asked for the new development > version like this: > What is the new development version for "foo"? (com.bar:foo) 1.12-SNAPSHOT: > Say I want the new development version to be 2.0-SNAPSHOT (and not like > suggested 1.12-SNAPSHOT) but by accident I only enter 2.0. This will work > just fine until I want to execute 'mvn release:prepare' again at some later > point. Then I will get the error message that the current version is not a > SNAPSHOT version. > It would be really nice if release:prepare could check if I have entered a > valid SNAPSHOT version. If not release:prepare should fail or even nicer ask > me to enter a proper SNAPSHOT version. -- 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] (MENFORCER-138) Rule to ban all transitive dependencies
[ https://jira.codehaus.org/browse/MENFORCER-138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier updated MENFORCER-138: Description: In some projects it's necessary (or at least desirable) to have all dependencies explicitly specified in pom. We have a build requirement to use a strictly controlled maven repository which includes only artifacts which are necessary and have been reviewed/approved. In order to meet this requirement, each new dependency in the build much be reviewed before each release. This can be done by periodically reviewing the dependency tree and cleaning up any unnecessary dependencies, but it would be more efficient if the developer adding the dependency was immediately notified that new (possibly unnecessary) dependencies were added to the build and not explicitly defined. The developer can immediately choose whether to exclude the transitive dependency (if it's not really needed), or declare the dependency and control the version using dependency management. Doing this checking up front when the build is modified is more efficient than periodically reviewing the dependency tree after several upgrades may have taken place. It In order to facilitate this use case, an enforcer rule could check that all dependencies are explicitly defined unless they are specifically marked to be ignored. This would ban all transitive dependencies so that the user could either add the transitive dependency directly to the pom (if it's actually needed), or exclude the dependency using exclusions in the dependency management, or marked to be ignored using something like an parameter similar to other standard enforcer rules. was: In some projects it's necessary (or at least desirable) to have all dependencies specified in pom. It would be nice to have an enforcer rule that would ban all transitive dependencies so that the user could either add the transitive dependency directly to the pom (if it's actually needed), or exclude the dependency. The rule should also have an option to ignore certain transitive dependencies, possibly using a similar syntax to other rules. Assignee: Paul Gier > Rule to ban all transitive dependencies > --- > > Key: MENFORCER-138 > URL: https://jira.codehaus.org/browse/MENFORCER-138 > Project: Maven 2.x Enforcer Plugin > Issue Type: New Feature > Components: Standard Rules >Reporter: Paul Gier >Assignee: Paul Gier > > In some projects it's necessary (or at least desirable) to have all > dependencies explicitly specified in pom. We have a build requirement to use > a strictly controlled maven repository which includes only artifacts which > are necessary and have been reviewed/approved. In order to meet this > requirement, each new dependency in the build much be reviewed before each > release. This can be done by periodically reviewing the dependency tree and > cleaning up any unnecessary dependencies, but it would be more efficient if > the developer adding the dependency was immediately notified that new > (possibly unnecessary) dependencies were added to the build and not > explicitly defined. The developer can immediately choose whether to exclude > the transitive dependency (if it's not really needed), or declare the > dependency and control the version using dependency management. Doing this > checking up front when the build is modified is more efficient than > periodically reviewing the dependency tree after several upgrades may have > taken place. > It In order to facilitate this use case, an enforcer rule could check that > all dependencies are explicitly defined unless they are specifically marked > to be ignored. This would ban all transitive dependencies so that the user > could either add the transitive dependency directly to the pom (if it's > actually needed), or exclude the dependency using exclusions in the > dependency management, or marked to be ignored using something like an > parameter similar to other standard enforcer rules. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5337) Maven activation profile feature cannot differ jdk version with build number
[ https://jira.codehaus.org/browse/MNG-5337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=307301#comment-307301 ] Vladimir Kravets commented on MNG-5337: --- Exactly, attached patch resolves this issue. > Maven activation profile feature cannot differ jdk version with build number > > > Key: MNG-5337 > URL: https://jira.codehaus.org/browse/MNG-5337 > Project: Maven 2 & 3 > Issue Type: Bug >Affects Versions: 3.0.5, 3.1 >Reporter: Vladimir Kravets >Priority: Minor > Attachments: fix_jdk_build_version_activator.diff > > > Since Oracle can apply some major changes between builds we need to have > ability to detect build number from profile -> activation -> jdk tag > By now using only first three components of jdk version. I propose to use > first 4 components of the version to be able to process it further. > E.g. from ~1.6.0-30 classpath separator is ";" instead of ":". In 1.7.x also > using ";". -- 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] (SCM-688) workingDirectory is not honored when tagging
William Newman created SCM-688:
--
Summary: workingDirectory is not honored when tagging
Key: SCM-688
URL: https://jira.codehaus.org/browse/SCM-688
Project: Maven SCM
Issue Type: Bug
Components: maven-scm-api, maven-scm-client, maven-scm-provider-svn
Affects Versions: 1.7
Reporter: William Newman
When using 'tag' I cannot set the 'workingDirectory' property in either the pom
or command line.
I.E.
if my pom is not the directory I want to tag I cannot set the working directory
to something else.
{noformat}
mvn scm:tag -DworkingDirectory=/tmp/somewhere
{noformat}
I believe that this should change directories to /tmp/somewhere and then
perform the 'svn copy' command.
--
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-908) Surefire fails with StackOverflowError when toolchains are present
Sergei Ivanov created SUREFIRE-908:
--
Summary: Surefire fails with StackOverflowError when toolchains
are present
Key: SUREFIRE-908
URL: https://jira.codehaus.org/browse/SUREFIRE-908
Project: Maven Surefire
Issue Type: Bug
Components: Maven Surefire Plugin
Affects Versions: 2.12.3
Reporter: Sergei Ivanov
Priority: Blocker
All our builds failed after an upgrade from 2.12.2 to 2.12.3 with the following
stack trace. Looking at the trunk version of {{AbstractSurefireMojo.java}},
there's indeed an infinite recursion between the two methods. The recursion
only happens when a toolchain is defined in the project.
{noformat}
[INFO] --- maven-surefire-plugin:2.12.3:test (default-test) @ config-server ---
[INFO] Toolchain in surefire-plugin: JDK[/opt/app//tools/jdk/64/jdk1.6.0_15]
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchStandard(Launcher.java:329)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:239)
at org.jvnet.hudson.maven3.agent.Maven3Main.launch(Maven3Main.java:158)
at hudson.maven.Maven3Builder.call(Maven3Builder.java:98)
at hudson.maven.Maven3Builder.call(Maven3Builder.java:64)
at hudson.remoting.UserRequest.perform(UserRequest.java:118)
at hudson.remoting.UserRequest.perform(UserRequest.java:48)
at hudson.remoting.Request$2.run(Request.java:287)
at
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.lang.StackOverflowError
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.getEffectiveForkMode(AbstractSurefireMojo.java:890)
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.isForkModeNever(AbstractSurefireMojo.java:880)
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.getEffectiveForkMode(AbstractSurefireMojo.java:892)
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.isForkModeNever(AbstractSurefireMojo.java:880)
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.getEffectiveForkMode(AbstractSurefireMojo.java:892)
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.isForkModeNever(AbstractSurefireMojo.java:880)
...
{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] (SCM-687) Fix TFS Support
Jonatan Urfalino created SCM-687:
Summary: Fix TFS Support
Key: SCM-687
URL: https://jira.codehaus.org/browse/SCM-687
Project: Maven SCM
Issue Type: Bug
Components: maven-scm-provider-tfs
Affects Versions: 1.7
Environment: TFS 2008 (Team Explorer 2008 + TFPowerTools 2008)
Sonar 3.1.1
Sonar Runner 1.4
sonar-scm-activity-plugin-1.5.jar
maven-scm-api-1.7.jar
Reporter: Jonatan Urfalino
When running SCM Activity Plugin for TFS you get hundreeds of
"java.text.ParseException: Unparseable date" exceptions, because the 'tfpt
annotate /nopromts' command does not return neither the date nor the author of
each line, only the changeset number.
(Thus the second string that the plugin tries to find is not a date, but the
file code itself)
Also see
[SONARPLUGINS-373|http://jira.codehaus.org/browse/SONARPLUGINS-373?focusedCommentId=307289#comment-307289]
Error:
{code}
09:36:29.218 ERROR .s.ScmActivitySensor - Failure during SCM blame retrieval
java.lang.NullPointerException: null
at java.util.Calendar.setTime(Calendar.java:1106) ~[na:1.7.0_03]
at java.text.SimpleDateFormat.format(SimpleDateFormat.java:955)
~[na:1.7.0_03]
at java.text.SimpleDateFormat.format(SimpleDateFormat.java:948)
~[na:1.7.0_03]
at
org.sonar.api.utils.DateUtils$ThreadSafeDateFormat.format(DateUtils.java:149)
~[sonar-plugin-api-3.1.1.jar:na]
at java.text.DateFormat.format(DateFormat.java:336) ~[na:1.7.0_03]
at org.sonar.api.utils.DateUtils.formatDateTime(DateUtils.java:55)
~[sonar-plugin-api-3.1.1.jar:na]
at org.sonar.plugins.scmactivity.Blame.save(Blame.java:61) ~[na:na]
at
org.sonar.plugins.scmactivity.BlameVersionSelector.fileChanged(BlameVersionSelector.java:73)
~[na:na]
at
org.sonar.plugins.scmactivity.BlameVersionSelector.detect(BlameVersionSelector.java:57)
~[na:na]
at
org.sonar.plugins.scmactivity.ScmActivitySensor$1.call(ScmActivitySensor.java:110)
~[na:na]
at
org.sonar.plugins.scmactivity.ScmActivitySensor$1.call(ScmActivitySensor.java:108)
~[na:na]
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
~[na:1.7.0_03]
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
~[na:1.7.0_03]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
~[na:1.7.0_03]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
~[na:1.7.0_03]
at java.lang.Thread.run(Thread.java:722) ~[na:1.7.0_03]
09:36:31.464 WARN .p.s.SonarScmManager - skip ParseException: Unparseable
date: "System.Configuration;" during parsing date System.Configuration; with
pattern MM/dd/ with Locale en
java.text.ParseException: Unparseable date: "System.Configuration;"
at java.text.DateFormat.parse(DateFormat.java:357) ~[na:1.7.0_03]
at
org.apache.maven.scm.util.AbstractConsumer.parseDate(AbstractConsumer.java:112)
[maven-scm-api-1.7.jar:1.7]
at
org.apache.maven.scm.util.AbstractConsumer.parseDate(AbstractConsumer.java:68)
[maven-scm-api-1.7.jar:1.7]
at
org.apache.maven.scm.provider.tfs.command.blame.TfsBlameConsumer.consumeLine(TfsBlameConsumer.java:66)
[maven-scm-provider-tfs-1.7.jar:1.7]
at
org.codehaus.plexus.util.cli.StreamPumper.consumeLine(StreamPumper.java:197)
[plexus-utils-2.0.5.jar:na]
at org.codehaus.plexus.util.cli.StreamPumper.run(StreamPumper.java:137)
[plexus-utils-2.0.5.jar:na]
09:36:31.464 WARN .p.s.SonarScmManager - skip ParseException: Unparseable
date: "System.Web;" during parsing date System.Web; with pattern MM/dd/
with Locale en
java.text.ParseException: Unparseable date: "System.Web;"
at java.text.DateFormat.parse(DateFormat.java:357) ~[na:1.7.0_03]
at
org.apache.maven.scm.util.AbstractConsumer.parseDate(AbstractConsumer.java:112)
[maven-scm-api-1.7.jar:1.7]
at
org.apache.maven.scm.util.AbstractConsumer.parseDate(AbstractConsumer.java:68)
[maven-scm-api-1.7.jar:1.7]
at
org.apache.maven.scm.provider.tfs.command.blame.TfsBlameConsumer.consumeLine(TfsBlameConsumer.java:66)
[maven-scm-provider-tfs-1.7.jar:1.7]
at
org.codehaus.plexus.util.cli.StreamPumper.consumeLine(StreamPumper.java:197)
[plexus-utils-2.0.5.jar:na]
at org.codehaus.plexus.util.cli.StreamPumper.run(StreamPumper.java:137)
[plexus-utils-2.0.5.jar:na]
{code}
--
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] (MSHADE-120) createSourceJar does not include sources from current module
[
https://jira.codehaus.org/browse/MSHADE-120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=307291#comment-307291
]
Saurabh Ajmera commented on MSHADE-120:
---
Hi Vivek,
Are you trying to reproduce the issue using the attached project or are you
trying to use the solution proposed by Trask?
> createSourceJar does not include sources from current module
>
>
> Key: MSHADE-120
> URL: https://jira.codehaus.org/browse/MSHADE-120
> Project: Maven 2.x Shade Plugin
> Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Saurabh Ajmera
> Attachments: maven-shade-problem.zip
>
>
> In such case the best approach is to create an issue with a sample project
> to reproduce the trouble .
> And the best of the best attaching a patch which fix the issue :-)
> --
> Olivier
> Le 25 mai 2012 17:40, "Saurabh Ajmera" a écrit :
> Hi,
> Is there anyone using the shade plugin? are you facing this issue?
> On May 22, 2012, at 11:06 AM, Saurabh Ajmera wrote:
> Hi,
> I am using the maven shade plugin to produce a jar which includes
> contents of one dependency artifact plus the contents of my current maven
> module, such that the contents of my maven module override the files with
> the same name in the dependency jar.
> The shade plugin generates the jar file correctly as needed. However,
> the source files from the current maven modules does not get included in
> the generated source jar. Am I doing something wrong?
> Following is the extract from my pom.xml
>
>
> org.apache.maven.plugins
> maven-shade-plugin
> ${maven.shade.plugin.version}
>
> true
>
>
>
> org.kuali.rice:rice-impl
>
>
>
>
>
>
> package
>
> shade
>
>
>
>
>
> Thank you,
> Saurabh Ajmera.
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
--
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] (MSHADE-120) createSourceJar does not include sources from current module
[
https://jira.codehaus.org/browse/MSHADE-120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=307290#comment-307290
]
Vivek Kumar commented on MSHADE-120:
Hi Saurabh
I tried you project attached in issue, but it doesn't seems to be working for
me.
Can you update working example of your project.
> createSourceJar does not include sources from current module
>
>
> Key: MSHADE-120
> URL: https://jira.codehaus.org/browse/MSHADE-120
> Project: Maven 2.x Shade Plugin
> Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Saurabh Ajmera
> Attachments: maven-shade-problem.zip
>
>
> In such case the best approach is to create an issue with a sample project
> to reproduce the trouble .
> And the best of the best attaching a patch which fix the issue :-)
> --
> Olivier
> Le 25 mai 2012 17:40, "Saurabh Ajmera" a écrit :
> Hi,
> Is there anyone using the shade plugin? are you facing this issue?
> On May 22, 2012, at 11:06 AM, Saurabh Ajmera wrote:
> Hi,
> I am using the maven shade plugin to produce a jar which includes
> contents of one dependency artifact plus the contents of my current maven
> module, such that the contents of my maven module override the files with
> the same name in the dependency jar.
> The shade plugin generates the jar file correctly as needed. However,
> the source files from the current maven modules does not get included in
> the generated source jar. Am I doing something wrong?
> Following is the extract from my pom.xml
>
>
> org.apache.maven.plugins
> maven-shade-plugin
> ${maven.shade.plugin.version}
>
> true
>
>
>
> org.kuali.rice:rice-impl
>
>
>
>
>
>
> package
>
> shade
>
>
>
>
>
> Thank you,
> Saurabh Ajmera.
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5337) Maven activation profile feature cannot differ jdk version with build number
[ https://jira.codehaus.org/browse/MNG-5337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=307282#comment-307282 ] Paul Benedict commented on MNG-5337: Makes sense to me. The code is already correctly parsing the the build number (after the dash) but it's being ignored because the proceeding code stops at the third component. > Maven activation profile feature cannot differ jdk version with build number > > > Key: MNG-5337 > URL: https://jira.codehaus.org/browse/MNG-5337 > Project: Maven 2 & 3 > Issue Type: Bug >Affects Versions: 3.0.5, 3.1 >Reporter: Vladimir Kravets >Priority: Minor > Attachments: fix_jdk_build_version_activator.diff > > > Since Oracle can apply some major changes between builds we need to have > ability to detect build number from profile -> activation -> jdk tag > By now using only first three components of jdk version. I propose to use > first 4 components of the version to be able to process it further. > E.g. from ~1.6.0-30 classpath separator is ";" instead of ":". In 1.7.x also > using ";". -- 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-tabpanel&focusedCommentId=307269#comment-307269 ] Alex Halovanic commented on MEAR-146: - Works like a charm, thanks! > 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 >Assignee: Stéphane Nicoll >Priority: Minor > Fix For: 2.8 > > Attachments: ear-general-librarydirectory.patch, > 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
[jira] (ARCHETYPE-419) archetype:create-from-project create a pom.xml with package=maven-archetype but archetype:generate requires a package=jar
Emeka Mosanya created ARCHETYPE-419: --- Summary: archetype:create-from-project create a pom.xml with package=maven-archetype but archetype:generate requires a package=jar Key: ARCHETYPE-419 URL: https://jira.codehaus.org/browse/ARCHETYPE-419 Project: Maven Archetype Issue Type: Bug Components: Creator, Generator Affects Versions: 2.2 Reporter: Emeka Mosanya Priority: Minor FilesetArchetypeCreator.createArchetypeProjectPom hardcodes the project packaging to "maven-archetype" which is fine. Unfortunately, the DefaultDownloader which downloads the archetype during the create-from-project goal is searching for an archetype with a "jar" packaging. Therefore, you cannot directly generate a new project using archetype:generate from a freshly created archetype since generate will not find it. The integration test works fine since it uses the artifact just built under target and which is a jar package but if you add the install property to the create-from-project goals, the package will be installed in the local repository with a package maven-archetype like this: Installing /Users/ft/falcon/ftcloud-git/services/smokeapp/smokeappService/target/generated-sources/archetype/target/smokeapp-service-archetype-0.15.0-SNAPSHOT.jar to /Users/ft/.m2/repository/com/ft/smokeapp-service-archetype/0.15.0-SNAPSHOT/smokeapp-service-archetype-0.15.0-SNAPSHOT.maven-archetype I think that the downloader should search for a 'maven-archetype' package and not a jar package or we should make the parameter configurable. My rational is the following: I would like to avoid copying the created archetype in my source directory but instead keep it as a result of the build process and directly install/deploy it. This is to avoid code duplication and ensure that the archetype is always in sync with the originating project. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHARED-237) upgrade ApacheLicense 1.1 to 2.0 for some leftovers
[
https://jira.codehaus.org/browse/MSHARED-237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Struberg closed MSHARED-237.
-
Resolution: Fixed
Checked the prevenience and updated the license headers. All the files were
forks of Ant files which got upgraded to ALv2 in ant a long time ago
> upgrade ApacheLicense 1.1 to 2.0 for some leftovers
>
>
> Key: MSHARED-237
> URL: https://jira.codehaus.org/browse/MSHARED-237
> Project: Maven Shared Components
> Issue Type: Task
>Reporter: Mark Struberg
>Assignee: Mark Struberg
>
> A few of our sources in our SVN repo which are explicitely noted as
> {quote}
> * Copyright (c) 2000-2003 The Apache Software Foundation. All rights
> * reserved.
> {quote}
> do still have the old 1.1 license header. Those classes are all forked out of
> ant which moved to ALv2.0 a long time ago. I'll update these headers
> accordingly.
--
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] (MSHARED-237) upgrade ApacheLicense 1.1 to 2.0 for some leftovers
[
https://jira.codehaus.org/browse/MSHARED-237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Struberg reassigned MSHARED-237:
-
Assignee: Mark Struberg
> upgrade ApacheLicense 1.1 to 2.0 for some leftovers
>
>
> Key: MSHARED-237
> URL: https://jira.codehaus.org/browse/MSHARED-237
> Project: Maven Shared Components
> Issue Type: Task
>Reporter: Mark Struberg
>Assignee: Mark Struberg
>
> A few of our sources in our SVN repo which are explicitely noted as
> {quote}
> * Copyright (c) 2000-2003 The Apache Software Foundation. All rights
> * reserved.
> {quote}
> do still have the old 1.1 license header. Those classes are all forked out of
> ant which moved to ALv2.0 a long time ago. I'll update these headers
> accordingly.
--
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] (MSHARED-237) upgrade ApacheLicense 1.1 to 2.0 for some leftovers
Mark Struberg created MSHARED-237:
-
Summary: upgrade ApacheLicense 1.1 to 2.0 for some leftovers
Key: MSHARED-237
URL: https://jira.codehaus.org/browse/MSHARED-237
Project: Maven Shared Components
Issue Type: Task
Reporter: Mark Struberg
A few of our sources in our SVN repo which are explicitely noted as
{quote}
* Copyright (c) 2000-2003 The Apache Software Foundation. All rights
* reserved.
{quote}
do still have the old 1.1 license header. Those classes are all forked out of
ant which moved to ALv2.0 a long time ago. I'll update these headers
accordingly.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5337) Maven activation profile feature cannot differ jdk version with build number
Vladimir Kravets created MNG-5337: - Summary: Maven activation profile feature cannot differ jdk version with build number Key: MNG-5337 URL: https://jira.codehaus.org/browse/MNG-5337 Project: Maven 2 & 3 Issue Type: Bug Affects Versions: 3.0.5, 3.1 Reporter: Vladimir Kravets Priority: Minor Attachments: fix_jdk_build_version_activator.diff Since Oracle can apply some major changes between builds we need to have ability to detect build number from profile -> activation -> jdk tag By now using only first three components of jdk version. I propose to use first 4 components of the version to be able to process it further. E.g. from ~1.6.0-30 classpath separator is ";" instead of ":". In 1.7.x also using ";". -- 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] (MSHARED-236) Refactor utility classes of shared components into an own utility package
[ https://jira.codehaus.org/browse/MSHARED-236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg reassigned MSHARED-236: - Assignee: Mark Struberg > Refactor utility classes of shared components into an own utility package > - > > Key: MSHARED-236 > URL: https://jira.codehaus.org/browse/MSHARED-236 > Project: Maven Shared Components > Issue Type: Bug >Reporter: Mark Struberg >Assignee: Mark Struberg > > DirectoryScanner in maven-verifier is one example. > We should introcude a new shared-utils module which doesn't contain any > external dependencies if possible. -- 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] (MSHARED-236) Refactor utility classes of shared components into an own utility package
Mark Struberg created MSHARED-236: - Summary: Refactor utility classes of shared components into an own utility package Key: MSHARED-236 URL: https://jira.codehaus.org/browse/MSHARED-236 Project: Maven Shared Components Issue Type: Bug Reporter: Mark Struberg DirectoryScanner in maven-verifier is one example. We should introcude a new shared-utils module which doesn't contain any external dependencies if possible. -- 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] (DOXIA-477) Table justification changes forcing unnecessary work on plain tables
Dave Syer created DOXIA-477: --- Summary: Table justification changes forcing unnecessary work on plain tables Key: DOXIA-477 URL: https://jira.codehaus.org/browse/DOXIA-477 Project: Maven Doxia Issue Type: Bug Components: Module - Apt Affects Versions: 1.1.1 Reporter: Dave Syer Since 1.1.1 (I think, DOXIA-38), the AptParser *requires* every row in a table to specify justification for all cells. This is onerous and for large tables makes them impossible to maintain. The old behaviour was to ignore *--- lines between rows, which I would like to re-instate if there is no change in justification. Note that there is a related ArrayIndexOutOfBounds if you don't specify *precisely* the right number of columns in every row. This is really quite annoying for large tables. I think the reference for that is DOXIA-453. -- 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
