[jira] (MNG-5346) update maven-plugin-plugin:descriptor default binding from generate-resources phase to process-classes
[
https://jira.codehaus.org/browse/MNG-5346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=347905#comment-347905
]
Jason van Zyl commented on MNG-5346:
Fixed on fc5cd371095913115f6cda6607630ba452a1b8bc
> update maven-plugin-plugin:descriptor default binding from generate-resources
> phase to process-classes
> --
>
> Key: MNG-5346
> URL: https://jira.codehaus.org/browse/MNG-5346
> Project: Maven 2 & 3
> Issue Type: Wish
>Affects Versions: 3.2.1
>Reporter: Herve Boutemy
>Assignee: Jason van Zyl
> Fix For: 3.2.2
>
> Attachments: plugin-annotation-sample.zip
>
>
> with Java annotations support added in Maven Plugin Tools 3.0, descriptor
> cannot be generated before compilation
> actually, to use annotations, users need to add extra configuration to avoid
> failure and to bind the goal to proper phase:
> {code:xml}
> true
>
>
>
> mojo-descriptor
>
> descriptor
>
> {code}
> changing the default lifecycle binding will enable removal of this extra
> configuration
> notice that removing the configuration from pom will require to check newer
> Maven version is used to build the plugin
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5346) update maven-plugin-plugin:descriptor default binding from generate-resources phase to process-classes
[
https://jira.codehaus.org/browse/MNG-5346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl closed MNG-5346.
--
Resolution: Fixed
> update maven-plugin-plugin:descriptor default binding from generate-resources
> phase to process-classes
> --
>
> Key: MNG-5346
> URL: https://jira.codehaus.org/browse/MNG-5346
> Project: Maven 2 & 3
> Issue Type: Wish
>Affects Versions: 3.2.1
>Reporter: Herve Boutemy
>Assignee: Jason van Zyl
> Fix For: 3.2.2
>
> Attachments: plugin-annotation-sample.zip
>
>
> with Java annotations support added in Maven Plugin Tools 3.0, descriptor
> cannot be generated before compilation
> actually, to use annotations, users need to add extra configuration to avoid
> failure and to bind the goal to proper phase:
> {code:xml}
> true
>
>
>
> mojo-descriptor
>
> descriptor
>
> {code}
> changing the default lifecycle binding will enable removal of this extra
> configuration
> notice that removing the configuration from pom will require to check newer
> Maven version is used to build the plugin
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-2199) Version ranges not supported for parent artifacts
[
https://jira.codehaus.org/browse/MNG-2199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=347912#comment-347912
]
Jason van Zyl commented on MNG-2199:
I was looking at this patch this week but there are no tests. If you create a
pull request on Github for the core, and a pull request for the integration
tests and everything passes I will process this patch. For reference you may
want to take a look at :
http://takari.io/2014/06/02/contributing-to-maven-core.html
> Version ranges not supported for parent artifacts
> -
>
> Key: MNG-2199
> URL: https://jira.codehaus.org/browse/MNG-2199
> Project: Maven 2 & 3
> Issue Type: Wish
> Components: Inheritance and Interpolation, POM, Reactor and workspace
>Affects Versions: 2.0.3
>Reporter: Christian Schulte
> Fix For: Issues to be reviewed for 4.x
>
> Attachments: MNG-2199-3.0.4.patch, MNG-2199-3.0.4.patch,
> MNG-2199-3.1.0-alpha-1.patch, MNG-2199.patch, MNG-2199.patch, MNG-2199.patch,
> MNG-2199.patch, MNG-2199.patch, MNG-2199.patch
>
>
> It would be great if Maven supports version ranges when specifying parent
> artifacts in a multi-module build. Currently this does not work.
>
> artifactId
> groupId
> [2.0, 2.0.1]
>
> [INFO] Scanning for projects...
> Downloading: http://repo1.maven.org/maven2/groupId/artifactId/[2.0,
> 2.0.1]/artifactId-[2.0, 2.0.1].pom
> Additionally it would be great if this
>
> artifactId
> groupId
> [2.0, ${pom.version}]
>
> [INFO] Scanning for projects...
> Downloading: http://repo1.maven.org/maven2/groupId/artifactId/[2.0,
> ${pom.version}]/artifactId-[2.0, ${pom.version}].pom
> would also work, if the version is specified in the same pom.xml which
> defines this parent definition.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5486) hiding transfer logs
[
https://jira.codehaus.org/browse/MNG-5486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=347914#comment-347914
]
Jason van Zyl commented on MNG-5486:
If you create a pull request this patch I will apply it.
> hiding transfer logs
>
>
> Key: MNG-5486
> URL: https://jira.codehaus.org/browse/MNG-5486
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: Command Line, Embedding, Logging, Performance
>Affects Versions: 3.0.5, 3.1.0
>Reporter: Jigar Joshi
>Priority: Minor
> Attachments: maven_qtl.patch, maven_qtl.patch, maven_qtl.patch
>
>
> Maven {{ConsoleMavenTransferListener}} adds too much verbose logs, Which is
> not required in all the cases and most of the time people uses it (
> {{ConsoleMavenTransferListener}} by default)
> It causes little overhead,
> For example: in CI build it adds those logs which is not required all the
> time, also (in my case) it triggers the build of a very large maven project
> tree at each 10 min adding lots of logs on disk
> Also there are other people who wants this feature as well
> http://maven.40175.n5.nabble.com/m2-Turning-off-download-log-messages-td46662.html
> http://stackoverflow.com/questions/3409918/maven-how-can-i-stop-the-deploy-plugin-from-logging-upload-progress
> I know there is a {{-q}} but which gets very quiet, so it would be nice if we
> are able to just quiet transfer logs
> I modified maven source to hide those log based on the parameter and using it
> successfully
> I have attached the patch here which was applied against 3.1-SNAPSHOT
> specifically at revision : 1495788
> https://svn.apache.org/repos/asf/maven/maven-3/trunk
> added new parameter
> {{-qtl}}
> to make quiet transfer log
> If I overlooked anything and did over engineering please let me know,
> Otherwise I would love to see this option in next release
> Thanks!
> Jigar
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5605) ssh-wagon hangs
[ https://jira.codehaus.org/browse/MNG-5605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-5605. -- Resolution: Cannot Reproduce > ssh-wagon hangs > --- > > Key: MNG-5605 > URL: https://jira.codehaus.org/browse/MNG-5605 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Deployment >Affects Versions: 3.2.1 >Reporter: Frank Cornelis >Priority: Blocker > > When releasing (using maven-release-plugin) via Maven 3.1.1 everything works > as expected. When doing the same via Maven 3.2.1, ssh-wagon all of the sudden > hangs on the second ssh upload. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MANTTASKS-203) java.lang.ClassCastException: org.codehaus.plexus.DefaultPlexusContainer cannot be cast to org.codehaus.plexus.PlexusContainer
[ https://jira.codehaus.org/browse/MANTTASKS-203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=347915#comment-347915 ] Jens Borgland commented on MANTTASKS-203: - Related to MANTTASKS-162? > java.lang.ClassCastException: org.codehaus.plexus.DefaultPlexusContainer > cannot be cast to org.codehaus.plexus.PlexusContainer > -- > > Key: MANTTASKS-203 > URL: https://jira.codehaus.org/browse/MANTTASKS-203 > Project: Maven Ant Tasks > Issue Type: Bug > Components: dependencies task >Affects Versions: 2.1.0, 2.1.1 > Environment: Apache Ant version 1.8.1 > Linux > java version "1.6.0_21" > Java(TM) SE Runtime Environment (build 1.6.0_21-b06) > Java HotSpot(TM) 64-Bit Server VM (build 17.0-b16, mixed mode) >Reporter: Thomas Scheffler >Priority: Critical > Attachments: build.xml > > > Running "ant test test2" for the submitted test results in a > ClassCastException: > java.lang.ClassCastException: org.codehaus.plexus.DefaultPlexusContainer > cannot be cast to org.codehaus.plexus.PlexusContainer > at > org.apache.maven.artifact.ant.AbstractArtifactTask.getContainer(AbstractArtifactTask.java:481) > at > org.apache.maven.artifact.ant.AbstractArtifactTask.lookup(AbstractArtifactTask.java:456) > at > org.apache.maven.artifact.ant.AbstractArtifactTask.initSettings(AbstractArtifactTask.java:289) > at > org.apache.maven.artifact.ant.AbstractArtifactTask.execute(AbstractArtifactTask.java:717) > at > org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291) > 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.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) > at org.apache.tools.ant.Task.perform(Task.java:348) > at org.apache.tools.ant.Target.execute(Target.java:390) > at org.apache.tools.ant.Target.performTasks(Target.java:411) > at > org.apache.tools.ant.Project.executeSortedTargets(Project.java:1397) > at org.apache.tools.ant.Project.executeTarget(Project.java:1366) > at > org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41) > at org.apache.tools.ant.Project.executeTargets(Project.java:1249) > at org.apache.tools.ant.Main.runBuild(Main.java:801) > at org.apache.tools.ant.Main.startAnt(Main.java:218) > at org.apache.tools.ant.launch.Launcher.run(Launcher.java:280) > at org.apache.tools.ant.launch.Launcher.main(Launcher.java:109) -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPMD-182) upgrade to last 5.1.0
[ https://jira.codehaus.org/browse/MPMD-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=347916#comment-347916 ] Zlika commented on MPMD-182: You have to set source/target to 1.8. I don't know how the plugin fails if used with java 8, but support for new java 8 constructs (lambdas, method references...) has only be added on PMD 5.1, and 5.1.1 fixes a problem with method references. > upgrade to last 5.1.0 > - > > Key: MPMD-182 > URL: https://jira.codehaus.org/browse/MPMD-182 > Project: Maven PMD Plugin > Issue Type: Improvement >Reporter: Olivier Lamy > Fix For: 3.2 > > -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5643) Profile properties in pom.xml don't override profile properties in settings.xml
[
https://jira.codehaus.org/browse/MNG-5643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=347925#comment-347925
]
Thomas Beauvais commented on MNG-5643:
--
Does that mean that each plugin is responsible for maintaining the behavior?
Or this version was point to a previous version of the Maven plugin libraries
which would effect more plugins. This isn't working in my Oracle WebLogic
plugin.
So, that is the order by design? That seems a little backwards to me but I
will take another look.
Thanks for the feedback.
> Profile properties in pom.xml don't override profile properties in
> settings.xml
> ---
>
> Key: MNG-5643
> URL: https://jira.codehaus.org/browse/MNG-5643
> Project: Maven 2 & 3
> Issue Type: Bug
>Affects Versions: 3.2.1
>Reporter: Thomas Beauvais
> Attachments: pom.xml, settings.xml
>
>
> Profile properties in pom.xml don't override profile properties in
> settings.xml.
> The goal is to provide team developers with a single settings.xml with useful
> profiles. Then, each project will override profile properties if necessary.
> In the following example we want to switch the $\{weblogic.host} property
> when enabled in the IDE or from the command line via: mvn -P stage
> What is curious is that overriding works when the profile being override
> exists in the same place as the profile that is doing the overriding. What
> this means is if all the profiles are in either the pom.xml OR settings.xml
> then everything works as expected.
> Normally, if the "stage" profile isn't actually present in the pom.xml I
> would get this:
> {noformat}[WARNING] The requested profile "stage" could not be activated
> because it does not exist.{noformat}
> But there is no warning about the profile "stage" because it does actually
> existing. The "stage" profile does exist in the pom.xml!
> Attached are sample pom.xml and settings.xml
> The command:
> {{mvn -P stage generate-resources}}
> The current output is:
> {noformat}
> [INFO] --- maven-antrun-plugin:1.3:run (default) @ simple-web ---
> [INFO] Executing tasks
> [echo] WebLogic: localhost
> [INFO] Executed tasks
> {noformat}
> The expected output is:
> {noformat}
> [INFO] --- maven-antrun-plugin:1.3:run (default) @ simple-web ---
> [INFO] Executing tasks
> [echo] WebLogic: 192.168.0.123
> [INFO] Executed tasks
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MSHARED-339) DependencyGraphBuilder does not provide verbose tree
Paul Gier created MSHARED-339: - Summary: DependencyGraphBuilder does not provide verbose tree Key: MSHARED-339 URL: https://jira.codehaus.org/browse/MSHARED-339 Project: Maven Shared Components Issue Type: Improvement Components: maven-dependency-tree Affects Versions: maven-dependency-tree-2.1 Reporter: Paul Gier The dependency graph builder provides a dependency tree which has already filtered out duplicate dependencies. In some cases such as testing dependency convergence or viewing the verbose dependency tree, it's useful to get information about the full tree including duplicates. The dependency graph builder should provide an option for including the unfiltered dependency tree. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MENFORCER-195) Dependency convergence does not support wildcard exclusions
[ https://jira.codehaus.org/browse/MENFORCER-195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=347929#comment-347929 ] Paul Gier commented on MENFORCER-195: - To give some more background on this, the dependency convergence rule used the shared maven dependency tree component. This component has a Maven 2 API/impl (DependencyTreeBuilder) and a second API (DependencyGraphBuilder) which works with Maven 2 and 3. The dependency convergence rule currently relies on the older Maven 2 API to provide a full dependency tree which it checks for transitive dependency conflicts. Unfortunately, the Maven 3 compatible API does not provide a full dependency tree so it's impossible to find dependency convergence conflicts. To resolve this issue the Maven 3 compatible API needs to provide an option for accessing the full dependency tree (MSHARED-339). > Dependency convergence does not support wildcard exclusions > --- > > Key: MENFORCER-195 > URL: https://jira.codehaus.org/browse/MENFORCER-195 > Project: Maven Enforcer Plugin > Issue Type: Bug > Components: Plugin >Affects Versions: 1.3.1 > Environment: Maven 3.2.1 >Reporter: Tomaz Cerar > > Maven 3.2 introduced wildcard exclusions for dependencies. > But if you use them dependencyConvergence wrongly complains about conflicting > transitive dependencies. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSKINS-93) Wrong file extension for 'apache-maven-project-2.png'
[
https://jira.codehaus.org/browse/MSKINS-93?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reassigned MSKINS-93:
Assignee: Michael Osipov
> Wrong file extension for 'apache-maven-project-2.png'
> -
>
> Key: MSKINS-93
> URL: https://jira.codehaus.org/browse/MSKINS-93
> Project: Maven Skins
> Issue Type: Bug
> Components: Fluido Skin
>Affects Versions: fluido-1.3.1
>Reporter: clement escoffier
>Assignee: Michael Osipov
>Priority: Minor
> Attachments: apache-maven-project-2.png
>
>
> The asset 'apache-maven-project-2.png' has the '.png' extension but actually
> it's a 'jpeg' file:
> {code}
> file apache-maven-project-2.png
> apache-maven-project-2.png: JPEG image data, JFIF standard 1.02
> {code}
> It's a minor issue, but it can become annoying if you want to optimize
> resource using optipng (or any other png optimizer).
> There are two easy way to fix this issue:
> * provide a png version of the image
> * rename the asset (but also update all the references to the asset)
> I've attached a png version of the asset.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MSKINS-93) Wrong file extension for 'apache-maven-project-2.png'
[
https://jira.codehaus.org/browse/MSKINS-93?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=347930#comment-347930
]
Michael Osipov commented on MSKINS-93:
--
Thanks for the report. This one is even incorrect on the front page. How did
you convert? The file is way bigger than the JPEG.
> Wrong file extension for 'apache-maven-project-2.png'
> -
>
> Key: MSKINS-93
> URL: https://jira.codehaus.org/browse/MSKINS-93
> Project: Maven Skins
> Issue Type: Bug
> Components: Fluido Skin
>Affects Versions: fluido-1.3.1
>Reporter: clement escoffier
>Priority: Minor
> Attachments: apache-maven-project-2.png
>
>
> The asset 'apache-maven-project-2.png' has the '.png' extension but actually
> it's a 'jpeg' file:
> {code}
> file apache-maven-project-2.png
> apache-maven-project-2.png: JPEG image data, JFIF standard 1.02
> {code}
> It's a minor issue, but it can become annoying if you want to optimize
> resource using optipng (or any other png optimizer).
> There are two easy way to fix this issue:
> * provide a png version of the image
> * rename the asset (but also update all the references to the asset)
> I've attached a png version of the asset.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MSKINS-93) Wrong file extension for 'apache-maven-project-2.png'
[
https://jira.codehaus.org/browse/MSKINS-93?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MSKINS-93:
-
Affects Version/s: stylus-1.5
> Wrong file extension for 'apache-maven-project-2.png'
> -
>
> Key: MSKINS-93
> URL: https://jira.codehaus.org/browse/MSKINS-93
> Project: Maven Skins
> Issue Type: Bug
> Components: Fluido Skin, Stylus Skin
>Affects Versions: stylus-1.5, fluido-1.3.1
>Reporter: clement escoffier
>Assignee: Michael Osipov
>Priority: Minor
> Attachments: apache-maven-project-2.png
>
>
> The asset 'apache-maven-project-2.png' has the '.png' extension but actually
> it's a 'jpeg' file:
> {code}
> file apache-maven-project-2.png
> apache-maven-project-2.png: JPEG image data, JFIF standard 1.02
> {code}
> It's a minor issue, but it can become annoying if you want to optimize
> resource using optipng (or any other png optimizer).
> There are two easy way to fix this issue:
> * provide a png version of the image
> * rename the asset (but also update all the references to the asset)
> I've attached a png version of the asset.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MSKINS-93) Wrong file extension for 'apache-maven-project-2.png'
[
https://jira.codehaus.org/browse/MSKINS-93?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MSKINS-93:
-
Component/s: Stylus Skin
> Wrong file extension for 'apache-maven-project-2.png'
> -
>
> Key: MSKINS-93
> URL: https://jira.codehaus.org/browse/MSKINS-93
> Project: Maven Skins
> Issue Type: Bug
> Components: Fluido Skin, Stylus Skin
>Affects Versions: stylus-1.5, fluido-1.3.1
>Reporter: clement escoffier
>Assignee: Michael Osipov
>Priority: Minor
> Attachments: apache-maven-project-2.png
>
>
> The asset 'apache-maven-project-2.png' has the '.png' extension but actually
> it's a 'jpeg' file:
> {code}
> file apache-maven-project-2.png
> apache-maven-project-2.png: JPEG image data, JFIF standard 1.02
> {code}
> It's a minor issue, but it can become annoying if you want to optimize
> resource using optipng (or any other png optimizer).
> There are two easy way to fix this issue:
> * provide a png version of the image
> * rename the asset (but also update all the references to the asset)
> I've attached a png version of the asset.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MSKINS-93) Wrong file extension for 'apache-maven-project-2.png'
[
https://jira.codehaus.org/browse/MSKINS-93?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MSKINS-93:
-
Fix Version/s: fluido-1.3.2
fluido-1.4.0
stylus-1.6
> Wrong file extension for 'apache-maven-project-2.png'
> -
>
> Key: MSKINS-93
> URL: https://jira.codehaus.org/browse/MSKINS-93
> Project: Maven Skins
> Issue Type: Bug
> Components: Fluido Skin, Stylus Skin
>Affects Versions: stylus-1.5, fluido-1.3.1
>Reporter: clement escoffier
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: stylus-1.6, fluido-1.4.0, fluido-1.3.2
>
> Attachments: apache-maven-project-2.png
>
>
> The asset 'apache-maven-project-2.png' has the '.png' extension but actually
> it's a 'jpeg' file:
> {code}
> file apache-maven-project-2.png
> apache-maven-project-2.png: JPEG image data, JFIF standard 1.02
> {code}
> It's a minor issue, but it can become annoying if you want to optimize
> resource using optipng (or any other png optimizer).
> There are two easy way to fix this issue:
> * provide a png version of the image
> * rename the asset (but also update all the references to the asset)
> I've attached a png version of the asset.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MSKINS-93) Wrong file extension for 'apache-maven-project-2.png'
[
https://jira.codehaus.org/browse/MSKINS-93?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MSKINS-93.
Resolution: Fixed
Fixed with r1602251 and r1602252.
> Wrong file extension for 'apache-maven-project-2.png'
> -
>
> Key: MSKINS-93
> URL: https://jira.codehaus.org/browse/MSKINS-93
> Project: Maven Skins
> Issue Type: Bug
> Components: Fluido Skin, Stylus Skin
>Affects Versions: stylus-1.5, fluido-1.3.1
>Reporter: clement escoffier
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: stylus-1.6, fluido-1.4.0, fluido-1.3.2
>
> Attachments: apache-maven-project-2.png
>
>
> The asset 'apache-maven-project-2.png' has the '.png' extension but actually
> it's a 'jpeg' file:
> {code}
> file apache-maven-project-2.png
> apache-maven-project-2.png: JPEG image data, JFIF standard 1.02
> {code}
> It's a minor issue, but it can become annoying if you want to optimize
> resource using optipng (or any other png optimizer).
> There are two easy way to fix this issue:
> * provide a png version of the image
> * rename the asset (but also update all the references to the asset)
> I've attached a png version of the asset.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MSKINS-93) Wrong file extension for 'apache-maven-project-2.png'
[
https://jira.codehaus.org/browse/MSKINS-93?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=347932#comment-347932
]
Michael Osipov edited comment on MSKINS-93 at 6/12/14 1:06 PM:
---
Fixed with r1602251 and r1602252. Conversion has been performed with
ImageMagick.
was (Author: michael-o):
Fixed with r1602251 and r1602252. Conversion has been perform with ImageMagick.
> Wrong file extension for 'apache-maven-project-2.png'
> -
>
> Key: MSKINS-93
> URL: https://jira.codehaus.org/browse/MSKINS-93
> Project: Maven Skins
> Issue Type: Bug
> Components: Fluido Skin, Stylus Skin
>Affects Versions: stylus-1.5, fluido-1.3.1
>Reporter: clement escoffier
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: stylus-1.6, fluido-1.4.0, fluido-1.3.2
>
> Attachments: apache-maven-project-2.png
>
>
> The asset 'apache-maven-project-2.png' has the '.png' extension but actually
> it's a 'jpeg' file:
> {code}
> file apache-maven-project-2.png
> apache-maven-project-2.png: JPEG image data, JFIF standard 1.02
> {code}
> It's a minor issue, but it can become annoying if you want to optimize
> resource using optipng (or any other png optimizer).
> There are two easy way to fix this issue:
> * provide a png version of the image
> * rename the asset (but also update all the references to the asset)
> I've attached a png version of the asset.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MSKINS-93) Wrong file extension for 'apache-maven-project-2.png'
[
https://jira.codehaus.org/browse/MSKINS-93?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=347932#comment-347932
]
Michael Osipov edited comment on MSKINS-93 at 6/12/14 1:06 PM:
---
Fixed with r1602251 and r1602252. Conversion has been perform with ImageMagick.
was (Author: michael-o):
Fixed with r1602251 and r1602252.
> Wrong file extension for 'apache-maven-project-2.png'
> -
>
> Key: MSKINS-93
> URL: https://jira.codehaus.org/browse/MSKINS-93
> Project: Maven Skins
> Issue Type: Bug
> Components: Fluido Skin, Stylus Skin
>Affects Versions: stylus-1.5, fluido-1.3.1
>Reporter: clement escoffier
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: stylus-1.6, fluido-1.4.0, fluido-1.3.2
>
> Attachments: apache-maven-project-2.png
>
>
> The asset 'apache-maven-project-2.png' has the '.png' extension but actually
> it's a 'jpeg' file:
> {code}
> file apache-maven-project-2.png
> apache-maven-project-2.png: JPEG image data, JFIF standard 1.02
> {code}
> It's a minor issue, but it can become annoying if you want to optimize
> resource using optipng (or any other png optimizer).
> There are two easy way to fix this issue:
> * provide a png version of the image
> * rename the asset (but also update all the references to the asset)
> I've attached a png version of the asset.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-1075) Addresses to documented mailing lists in Maven site dead
[
https://jira.codehaus.org/browse/SUREFIRE-1075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=347933#comment-347933
]
Michael Osipov edited comment on SUREFIRE-1075 at 6/12/14 1:25 PM:
---
Can you spawn another ticket at [https://issues.apache.org/jira/browse/INFRA]?
was (Author: michael-o):
Can you spawn another ticket at https://issues.apache.org/jira/browse/INFRA?
> Addresses to documented mailing lists in Maven site dead
>
>
> Key: SUREFIRE-1075
> URL: https://jira.codehaus.org/browse/SUREFIRE-1075
> Project: Maven Surefire
> Issue Type: Bug
> Components: documentation
>Reporter: Marcel Stör
>Priority: Critical
> Fix For: 2.18
>
>
> I tried to subscribe to mailing lists documented here
> http://maven.apache.org/surefire/maven-surefire-plugin/mail-lists.html
> What I got back was
> {noformat}
>- The following addresses had permanent fatal errors -
>
> (reason: 550 mail to surefire-users-subscr...@maven.apache.org not
> accepted here)
>- Transcript of session follows -
> ... while talking to mx1.us.apache.org.:
> >>> DATA
> <<< 550 mail to surefire-users-subscr...@maven.apache.org not accepted here
> 550 5.1.1 ... User unknown
> <<< 503 RCPT first
> {noformat}
> The archives linked there seem to contain only messages up to year 2010 or so.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-1075) Addresses to documented mailing lists in Maven site dead
[
https://jira.codehaus.org/browse/SUREFIRE-1075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=347933#comment-347933
]
Michael Osipov commented on SUREFIRE-1075:
--
Can you spawn another ticket at https://issues.apache.org/jira/browse/INFRA?
> Addresses to documented mailing lists in Maven site dead
>
>
> Key: SUREFIRE-1075
> URL: https://jira.codehaus.org/browse/SUREFIRE-1075
> Project: Maven Surefire
> Issue Type: Bug
> Components: documentation
>Reporter: Marcel Stör
>Priority: Critical
> Fix For: 2.18
>
>
> I tried to subscribe to mailing lists documented here
> http://maven.apache.org/surefire/maven-surefire-plugin/mail-lists.html
> What I got back was
> {noformat}
>- The following addresses had permanent fatal errors -
>
> (reason: 550 mail to surefire-users-subscr...@maven.apache.org not
> accepted here)
>- Transcript of session follows -
> ... while talking to mx1.us.apache.org.:
> >>> DATA
> <<< 550 mail to surefire-users-subscr...@maven.apache.org not accepted here
> 550 5.1.1 ... User unknown
> <<< 503 RCPT first
> {noformat}
> The archives linked there seem to contain only messages up to year 2010 or so.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-1069) Typo in alwaysGenerateSurefireReport doc: "Defaulyts"
[
https://jira.codehaus.org/browse/SUREFIRE-1069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reassigned SUREFIRE-1069:
Assignee: Michael Osipov
> Typo in alwaysGenerateSurefireReport doc: "Defaulyts"
> -
>
> Key: SUREFIRE-1069
> URL: https://jira.codehaus.org/browse/SUREFIRE-1069
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Report Plugin
>Affects Versions: 2.16
>Reporter: Joshua Hyde
>Assignee: Michael Osipov
>Priority: Trivial
> Fix For: 2.18
>
>
> The documentation for the {{alwaysGenerateSurefireReport}} parameter has a
> typo of "Defaults":
> {quote}If set to true the surefire report will be generated even when there
> are no surefire result files. Defaulyts to true to preserve legacy behaviour
> pre 2.10.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-1069) Typo in alwaysGenerateSurefireReport doc: "Defaulyts"
[
https://jira.codehaus.org/browse/SUREFIRE-1069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed SUREFIRE-1069.
Resolution: Fixed
Thanks, fixed:
https://git-wip-us.apache.org/repos/asf?p=maven-surefire.git;a=commit;h=57b410a38ed69d8e00ec93d1121842be3e81b42d
> Typo in alwaysGenerateSurefireReport doc: "Defaulyts"
> -
>
> Key: SUREFIRE-1069
> URL: https://jira.codehaus.org/browse/SUREFIRE-1069
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Report Plugin
>Affects Versions: 2.16
>Reporter: Joshua Hyde
>Assignee: Michael Osipov
>Priority: Trivial
> Fix For: 2.18
>
>
> The documentation for the {{alwaysGenerateSurefireReport}} parameter has a
> typo of "Defaults":
> {quote}If set to true the surefire report will be generated even when there
> are no surefire result files. Defaulyts to true to preserve legacy behaviour
> pre 2.10.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-1075) Addresses to documented mailing lists in Maven site dead
[
https://jira.codehaus.org/browse/SUREFIRE-1075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=347935#comment-347935
]
Marcel Stör commented on SUREFIRE-1075:
---
Yes, I'll do that. However, IMO it'd be more sensible if an admin simply moved
this issue to the new project...(don't have permission to do it myself)
> Addresses to documented mailing lists in Maven site dead
>
>
> Key: SUREFIRE-1075
> URL: https://jira.codehaus.org/browse/SUREFIRE-1075
> Project: Maven Surefire
> Issue Type: Bug
> Components: documentation
>Reporter: Marcel Stör
>Priority: Critical
> Fix For: 2.18
>
>
> I tried to subscribe to mailing lists documented here
> http://maven.apache.org/surefire/maven-surefire-plugin/mail-lists.html
> What I got back was
> {noformat}
>- The following addresses had permanent fatal errors -
>
> (reason: 550 mail to surefire-users-subscr...@maven.apache.org not
> accepted here)
>- Transcript of session follows -
> ... while talking to mx1.us.apache.org.:
> >>> DATA
> <<< 550 mail to surefire-users-subscr...@maven.apache.org not accepted here
> 550 5.1.1 ... User unknown
> <<< 503 RCPT first
> {noformat}
> The archives linked there seem to contain only messages up to year 2010 or so.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-1075) Addresses to documented mailing lists in Maven site dead
[
https://jira.codehaus.org/browse/SUREFIRE-1075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=347935#comment-347935
]
Marcel Stör edited comment on SUREFIRE-1075 at 6/12/14 2:34 PM:
Yes, I'll do that: https://issues.apache.org/jira/browse/INFRA-7901
was (Author: marcelstoer):
Yes, I'll do that. However, IMO it'd be more sensible if an admin simply moved
this issue to the new project...(don't have permission to do it myself)
> Addresses to documented mailing lists in Maven site dead
>
>
> Key: SUREFIRE-1075
> URL: https://jira.codehaus.org/browse/SUREFIRE-1075
> Project: Maven Surefire
> Issue Type: Bug
> Components: documentation
>Reporter: Marcel Stör
>Priority: Critical
> Fix For: 2.18
>
>
> I tried to subscribe to mailing lists documented here
> http://maven.apache.org/surefire/maven-surefire-plugin/mail-lists.html
> What I got back was
> {noformat}
>- The following addresses had permanent fatal errors -
>
> (reason: 550 mail to surefire-users-subscr...@maven.apache.org not
> accepted here)
>- Transcript of session follows -
> ... while talking to mx1.us.apache.org.:
> >>> DATA
> <<< 550 mail to surefire-users-subscr...@maven.apache.org not accepted here
> 550 5.1.1 ... User unknown
> <<< 503 RCPT first
> {noformat}
> The archives linked there seem to contain only messages up to year 2010 or so.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MASSEMBLY-334) Can not generate class-path from Manifest
[
https://jira.codehaus.org/browse/MASSEMBLY-334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=347937#comment-347937
]
Martin Schonaker commented on MASSEMBLY-334:
Doesn't work for me in version 2.2-beta5 in goal "attached".
I've found a workaround. It works using the deprecated goal assembly. However,
that goal doesn't attach the artifact, somehow. I've solved that part with
build-helper plugin.
> Can not generate class-path from Manifest
> -
>
> Key: MASSEMBLY-334
> URL: https://jira.codehaus.org/browse/MASSEMBLY-334
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: manifest
>Affects Versions: 2.2-beta-2
> Environment: Pc - Windows XP sp2
>Reporter: Damien
>
> I have a maven's projet multi-module.
> I have a problem when i launch mvn package assembly:assembly
> In the Manifest file, the class path does not generated.
> Pom project
> {code:xml}
>
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/maven-v4_0_0.xsd";>
> 4.0.0
> com.ipsis.pacha
> Pacha
> pom
> 1.0-SNAPSHOT
> PACHA
>
>
>
>
>
> maven-antrun-plugin
>
>
>
> print-maven-runtime-classpath
> compile
>
>
>name="runtime-classpath"
>
> refid="maven.runtime.classpath" />
>
> message="maven.runtime.classpath=${runtime-classpath}" />
>
>
>
> run
>
>
>
>
> print-maven-test-classpath
> test-compile
>
>
>name="test-classpath"
>
> refid="maven.test.classpath" />
>
> message="maven.test.classpath=${test-classpath}" />
>
>
>
> run
>
>
>
>
>
>
> maven-compiler-plugin
>
>
> 1.6
> 1.6
> 512m
> 1024m
> true
> true
> true
>
> ${JAVA_HOME}\bin\javac.exe
> 1.6
>
>
>
>
>
> true
> maven-deploy-plugin
>
>
> true
>
>
>
>
> org.apache.maven.plugins
> maven-release-plugin
>
> deploy
>
>
>
>
> maven-surefire-plugin
>
[jira] (SUREFIRE-1075) Addresses to documented mailing lists in Maven site dead
[
https://jira.codehaus.org/browse/SUREFIRE-1075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=347939#comment-347939
]
Michael Osipov commented on SUREFIRE-1075:
--
Looks good, as soon as INFRA has clarified this, I can update the POM
accordingly. Note: I cannot move this issue because INFRA is different JIRA
installation.
> Addresses to documented mailing lists in Maven site dead
>
>
> Key: SUREFIRE-1075
> URL: https://jira.codehaus.org/browse/SUREFIRE-1075
> Project: Maven Surefire
> Issue Type: Bug
> Components: documentation
>Reporter: Marcel Stör
>Priority: Critical
> Fix For: 2.18
>
>
> I tried to subscribe to mailing lists documented here
> http://maven.apache.org/surefire/maven-surefire-plugin/mail-lists.html
> What I got back was
> {noformat}
>- The following addresses had permanent fatal errors -
>
> (reason: 550 mail to surefire-users-subscr...@maven.apache.org not
> accepted here)
>- Transcript of session follows -
> ... while talking to mx1.us.apache.org.:
> >>> DATA
> <<< 550 mail to surefire-users-subscr...@maven.apache.org not accepted here
> 550 5.1.1 ... User unknown
> <<< 503 RCPT first
> {noformat}
> The archives linked there seem to contain only messages up to year 2010 or so.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5617) unreadable log in multi thread compilation
[ https://jira.codehaus.org/browse/MNG-5617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MNG-5617. --- Resolution: Duplicate Assignee: Robert Scholte > unreadable log in multi thread compilation > -- > > Key: MNG-5617 > URL: https://jira.codehaus.org/browse/MNG-5617 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Logging >Affects Versions: 3.1.1 > Environment: Unix, RedHat >Reporter: mohamed chenouili >Assignee: Robert Scholte >Priority: Critical > > when I try to compile multi-module project (-T 8), the log of each project is > not printed sequentially, all logs of the compilation is being printed as > soon as it is thrown by the compiler. > This makes logs unreadble. > Am I the only one in this case ? > I have seen that a solution was implemented but not used in Maven source > code (ThreadOutputMuxer.java). > Is there a solution for this issue ? > I should not be the only one. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-1075) Addresses to documented mailing lists in Maven site dead
[
https://jira.codehaus.org/browse/SUREFIRE-1075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=347939#comment-347939
]
Michael Osipov edited comment on SUREFIRE-1075 at 6/12/14 3:20 PM:
---
Looks good, according to INFRA those lists are dead, will wait for their
response, I can update the POM accordingly. Note: I cannot move this issue
because INFRA is different JIRA installation.
was (Author: michael-o):
Looks good, as soon as INFRA has clarified this, I can update the POM
accordingly. Note: I cannot move this issue because INFRA is different JIRA
installation.
> Addresses to documented mailing lists in Maven site dead
>
>
> Key: SUREFIRE-1075
> URL: https://jira.codehaus.org/browse/SUREFIRE-1075
> Project: Maven Surefire
> Issue Type: Bug
> Components: documentation
>Reporter: Marcel Stör
>Priority: Critical
> Fix For: 2.18
>
>
> I tried to subscribe to mailing lists documented here
> http://maven.apache.org/surefire/maven-surefire-plugin/mail-lists.html
> What I got back was
> {noformat}
>- The following addresses had permanent fatal errors -
>
> (reason: 550 mail to surefire-users-subscr...@maven.apache.org not
> accepted here)
>- Transcript of session follows -
> ... while talking to mx1.us.apache.org.:
> >>> DATA
> <<< 550 mail to surefire-users-subscr...@maven.apache.org not accepted here
> 550 5.1.1 ... User unknown
> <<< 503 RCPT first
> {noformat}
> The archives linked there seem to contain only messages up to year 2010 or so.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-1075) Addresses to documented mailing lists in Maven site dead
[
https://jira.codehaus.org/browse/SUREFIRE-1075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=347941#comment-347941
]
Marcel Stör commented on SUREFIRE-1075:
---
{quote}according to INFRA those lists are dead{quote}
Should this indeed prove to be correct the obvious follow-up question would be
"where to get support elsewhere?" (other than SO)
> Addresses to documented mailing lists in Maven site dead
>
>
> Key: SUREFIRE-1075
> URL: https://jira.codehaus.org/browse/SUREFIRE-1075
> Project: Maven Surefire
> Issue Type: Bug
> Components: documentation
>Reporter: Marcel Stör
>Priority: Critical
> Fix For: 2.18
>
>
> I tried to subscribe to mailing lists documented here
> http://maven.apache.org/surefire/maven-surefire-plugin/mail-lists.html
> What I got back was
> {noformat}
>- The following addresses had permanent fatal errors -
>
> (reason: 550 mail to surefire-users-subscr...@maven.apache.org not
> accepted here)
>- Transcript of session follows -
> ... while talking to mx1.us.apache.org.:
> >>> DATA
> <<< 550 mail to surefire-users-subscr...@maven.apache.org not accepted here
> 550 5.1.1 ... User unknown
> <<< 503 RCPT first
> {noformat}
> The archives linked there seem to contain only messages up to year 2010 or so.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-3283) Plugins that require dependency resolution in early phases cause dependency resolution issue
[ https://jira.codehaus.org/browse/MNG-3283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-3283: --- Assignee: Jason van Zyl > Plugins that require dependency resolution in early phases cause dependency > resolution issue > > > Key: MNG-3283 > URL: https://jira.codehaus.org/browse/MNG-3283 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies, Plugins and Lifecycle, Reactor and > workspace >Affects Versions: 2.0.7 >Reporter: Alfie Kirkpatrick >Assignee: Jason van Zyl > Fix For: Issues to be reviewed for 3.x > > Attachments: maven-dependency-bug.zip > > > What we're seeing is that some multi-project configurations succeed on > 'mvn package' but fail on 'mvn generate-sources'. They are failing when > one project in the reactor references another project in the reactor > which is not installed in the local repo. It seems that the referenced > project has not quite "made it" into the reactor this early in the phase > lifecycle. But it does work correctly if you target a later phase at the > outset which is really confusing. > The problem only occurs when a plugin binds itself to the > generate-sources phase and has @requiresDependencyResolution, presumably > because this is what triggers resolution of the referenced dependency > too early in the lifecycle, and hence the error. > We are seeing this problem when trying to run 'mvn eclipse:eclipse' > because this only executes the generate-sources phase by default and we > have other mojos which genuinely do generate source, such as java2wsdl. > A workaround we're using is to run 'mvn process-classes eclipse:eclipse'. > Attached is a really simple project that exhibits this problem. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-2876) versionrange doesn't handle singular version correctly
[ https://jira.codehaus.org/browse/MNG-2876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-2876. -- Resolution: Cannot Reproduce > versionrange doesn't handle singular version correctly > -- > > Key: MNG-2876 > URL: https://jira.codehaus.org/browse/MNG-2876 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0.2, 2.0.3, 2.0.4, 2.0.5, 2.0.6, 2.0.7, 2.0.8, 2.0.9, > 2.0.10, 2.1.0-M1, 3.0-alpha-1 >Reporter: brianfox brianfox >Assignee: brianfox brianfox > Fix For: Issues to be reviewed for 3.x > > > I'm still having trouble with this. I wrote a sample class to show my > problem. The issue is that all the contains calls are correct except that a > singular version ie "2.0.5" always returns true. Is this an artifact bug, or > am I doing something wrong? According to the javadoc for the method (shown in > my original post below) the singular version is allowed as a version range. > The tests and fix are here: > https://svn.apache.org/repos/asf/maven/plugins/branches/maven-artifact-version-range-fix > > I just need someone to take a look and I can apply. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-2876) versionrange doesn't handle singular version correctly
[ https://jira.codehaus.org/browse/MNG-2876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=347944#comment-347944 ] Jason van Zyl commented on MNG-2876: Branch doesn't exist anymore, nor most of the links. > versionrange doesn't handle singular version correctly > -- > > Key: MNG-2876 > URL: https://jira.codehaus.org/browse/MNG-2876 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0.2, 2.0.3, 2.0.4, 2.0.5, 2.0.6, 2.0.7, 2.0.8, 2.0.9, > 2.0.10, 2.1.0-M1, 3.0-alpha-1 >Reporter: brianfox brianfox >Assignee: brianfox brianfox > Fix For: Issues to be reviewed for 3.x > > > I'm still having trouble with this. I wrote a sample class to show my > problem. The issue is that all the contains calls are correct except that a > singular version ie "2.0.5" always returns true. Is this an artifact bug, or > am I doing something wrong? According to the javadoc for the method (shown in > my original post below) the singular version is allowed as a version range. > The tests and fix are here: > https://svn.apache.org/repos/asf/maven/plugins/branches/maven-artifact-version-range-fix > > I just need someone to take a look and I can apply. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-3376) plugin repositories are not checked when looking for snapshot plugin.
[ https://jira.codehaus.org/browse/MNG-3376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-3376. -- Resolution: Cannot Reproduce > plugin repositories are not checked when looking for snapshot plugin. > - > > Key: MNG-3376 > URL: https://jira.codehaus.org/browse/MNG-3376 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 3.0 >Reporter: Milos Kleint >Assignee: Milos Kleint > Fix For: Issues to be reviewed for 3.x > > Attachments: nbm-maven-plugin-repo.zip > > > Building current mevenide trunk with clean repository > (https://svn.codehaus.org/mevenide/trunk/mevenide2) > the root project defines section with nbm-maven-plugin in > 2.7-SNAPSHOT version. at the same time it defines pluginRepository pointing > to codehaus snapshots. The plugin is used by child projects. > with 2.0.7 it builds fine. > with current 2.1, the build fails because the 2.7-SNAPSHOT version is missing. > attached is the content of the nbm-maven-plugin folder in local repository. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-2834) "from the specified remote repositories" message incorrect
[ https://jira.codehaus.org/browse/MNG-2834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-2834. -- Resolution: Cannot Reproduce > "from the specified remote repositories" message incorrect > -- > > Key: MNG-2834 > URL: https://jira.codehaus.org/browse/MNG-2834 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0.5 >Reporter: Geoffrey De Smet >Assignee: John Casey >Priority: Trivial > Fix For: Issues to be reviewed for 3.x > > > I am getting this message on a not found dependency: > from the specified remote repositories: > ggg-dev (http://mvn.ggg.be/maven2/dev), > apache.snapshots (http://svn.apache.org/maven-snapshot-repository), > ggg-deploy (http://mvn.ggg.be/maven2/deploy), > snapshots (http://snapshots.maven.codehaus.org/maven2), > central (http://repo1.maven.org/maven2) > But that dependency (commons-collections:commons-collections:jar:2.0) is in > ibiblio. > However, we don't use ibiblio, because we configured our repositories like > this: > > > central > ggg deploy repository > http://mvn.ggg.be/maven2/deploy > > true > > > false > > > > ggg-dev > ggg dev repository > http://mvn.ggg.be/maven2/dev > > false > > > true > > > > > > ggg-deploy > ggg deploy repository > http://mvn.schaubroeck.be/maven2/deploy > > true > > > false > > > > ggg-dev > Schaubroeck dev repository > http://mvn.schaubroeck.be/maven2/dev > > false > > > true > > > > So the following lines of "from the specified remote repositories" are > incorrect: > apache.snapshots (http://svn.apache.org/maven-snapshot-repository), > snapshots (http://snapshots.maven.codehaus.org/maven2), > central (http://repo1.maven.org/maven2) > PS: especially those snapshots in there scared me... I deleted my entire > repo, verified that we do not include snapshot repo's and still they show up > in that list. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5620) LinkageError when CDI is in the classpath
[ https://jira.codehaus.org/browse/MNG-5620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=347945#comment-347945 ] Jason van Zyl commented on MNG-5620: @Stuart, do we need to expose any of CDI at all? Or even use the cdi-api dependency in Maven at all? I don't see us using it, does Sisu need for something related to Maven? > LinkageError when CDI is in the classpath > -- > > Key: MNG-5620 > URL: https://jira.codehaus.org/browse/MNG-5620 > Project: Maven 2 & 3 > Issue Type: Bug > Components: General >Affects Versions: 3.1.0-alpha-1, 3.1.0, 3.1.1, 3.2.1 >Reporter: Martin Grigorov > > We have troubles use 'mvn jetty:run' for > https://github.com/apache/wicket/tree/master/wicket-examples after upgrading > to Maven 3.1.0+. > It fails with: > 2014-04-17 16:22:57.160:WARN:oejuc.AbstractLifeCycle:FAILED > org.mortbay.jetty.plugin.JettyServer@44e5b006: java.lang.LinkageError: loader > constraint violation: when resolving overridden method > "org.jboss.weld.Weld.select(Ljavax/enterprise/util/TypeLiteral;[Ljava/lang/annotation/Annotation;)Ljavax/enterprise/inject/Instance;" > the class loader (instance of org/eclipse/jetty/webapp/WebAppClassLoader) of > the current class, org/jboss/weld/Weld, and its superclass loader (instance > of org/codehaus/plexus/classworlds/realm/ClassRealm), have different Class > objects for the type tion/Annotation;)Ljavax/enterprise/inject/Instance; used > in the signature > java.lang.LinkageError: loader constraint violation: when resolving > overridden method > "org.jboss.weld.Weld.select(Ljavax/enterprise/util/TypeLiteral;[Ljava/lang/annotation/Annotation;)Ljavax/enterprise/inject/Instance;" > the class loader (instance of org/eclipse/jetty/webapp/WebAppClassLoader) of > the current class, org/jboss/weld/Weld, and its superclass loader (instance > of org/codehaus/plexus/classworlds/realm/ClassRealm), have different Class > objects for the type tion/Annotation;)Ljavax/enterprise/inject/Instance; used > in the signature > at > org.jboss.weld.servlet.StaticWeldProvider$WeldSingleton.(StaticWeldProvider.java:29) > at > org.jboss.weld.servlet.StaticWeldProvider.getCDI(StaticWeldProvider.java:49) > at javax.enterprise.inject.spi.CDI.current(CDI.java:60) > at > org.jboss.weld.servlet.WeldInitialListener.contextInitialized(WeldInitialListener.java:85) > at > org.jboss.weld.servlet.api.helpers.ForwardingServletListener.contextInitialized(ForwardingServletListener.java:34) > at > org.jboss.weld.environment.servlet.Listener.contextInitialized(Listener.java:171) > at > org.eclipse.jetty.server.handler.ContextHandler.startContext(ContextHandler.java:733) > ... > The issue is not new. We just noticed that when using 3.0.5 it runs fine so > it should be some change in Maven itself. > I've found that another user had the same issue: > http://stackoverflow.com/a/18168215/497381 > How to reproduce: > 1) git clone https://github.com/apache/wicket.git > 2) mvn install (just to have all dependencies) > 3) cd wicket-examples > 4) mvn jetty:run (fails with 3.1.0+) -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5620) LinkageError when CDI is in the classpath
[ https://jira.codehaus.org/browse/MNG-5620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-5620: --- Assignee: Jason van Zyl > LinkageError when CDI is in the classpath > -- > > Key: MNG-5620 > URL: https://jira.codehaus.org/browse/MNG-5620 > Project: Maven 2 & 3 > Issue Type: Bug > Components: General >Affects Versions: 3.1.0-alpha-1, 3.1.0, 3.1.1, 3.2.1 >Reporter: Martin Grigorov >Assignee: Jason van Zyl > > We have troubles use 'mvn jetty:run' for > https://github.com/apache/wicket/tree/master/wicket-examples after upgrading > to Maven 3.1.0+. > It fails with: > 2014-04-17 16:22:57.160:WARN:oejuc.AbstractLifeCycle:FAILED > org.mortbay.jetty.plugin.JettyServer@44e5b006: java.lang.LinkageError: loader > constraint violation: when resolving overridden method > "org.jboss.weld.Weld.select(Ljavax/enterprise/util/TypeLiteral;[Ljava/lang/annotation/Annotation;)Ljavax/enterprise/inject/Instance;" > the class loader (instance of org/eclipse/jetty/webapp/WebAppClassLoader) of > the current class, org/jboss/weld/Weld, and its superclass loader (instance > of org/codehaus/plexus/classworlds/realm/ClassRealm), have different Class > objects for the type tion/Annotation;)Ljavax/enterprise/inject/Instance; used > in the signature > java.lang.LinkageError: loader constraint violation: when resolving > overridden method > "org.jboss.weld.Weld.select(Ljavax/enterprise/util/TypeLiteral;[Ljava/lang/annotation/Annotation;)Ljavax/enterprise/inject/Instance;" > the class loader (instance of org/eclipse/jetty/webapp/WebAppClassLoader) of > the current class, org/jboss/weld/Weld, and its superclass loader (instance > of org/codehaus/plexus/classworlds/realm/ClassRealm), have different Class > objects for the type tion/Annotation;)Ljavax/enterprise/inject/Instance; used > in the signature > at > org.jboss.weld.servlet.StaticWeldProvider$WeldSingleton.(StaticWeldProvider.java:29) > at > org.jboss.weld.servlet.StaticWeldProvider.getCDI(StaticWeldProvider.java:49) > at javax.enterprise.inject.spi.CDI.current(CDI.java:60) > at > org.jboss.weld.servlet.WeldInitialListener.contextInitialized(WeldInitialListener.java:85) > at > org.jboss.weld.servlet.api.helpers.ForwardingServletListener.contextInitialized(ForwardingServletListener.java:34) > at > org.jboss.weld.environment.servlet.Listener.contextInitialized(Listener.java:171) > at > org.eclipse.jetty.server.handler.ContextHandler.startContext(ContextHandler.java:733) > ... > The issue is not new. We just noticed that when using 3.0.5 it runs fine so > it should be some change in Maven itself. > I've found that another user had the same issue: > http://stackoverflow.com/a/18168215/497381 > How to reproduce: > 1) git clone https://github.com/apache/wicket.git > 2) mvn install (just to have all dependencies) > 3) cd wicket-examples > 4) mvn jetty:run (fails with 3.1.0+) -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-1075) Addresses to documented mailing lists in Maven site dead
[
https://jira.codehaus.org/browse/SUREFIRE-1075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=347953#comment-347953
]
Michael Osipov commented on SUREFIRE-1075:
--
Marcel,
you should subscribe to the Maven Users ML. I will target this issue an either
update the Surefire POM or delete all references to the mailing list.
> Addresses to documented mailing lists in Maven site dead
>
>
> Key: SUREFIRE-1075
> URL: https://jira.codehaus.org/browse/SUREFIRE-1075
> Project: Maven Surefire
> Issue Type: Bug
> Components: documentation
>Reporter: Marcel Stör
>Priority: Critical
> Fix For: 2.18
>
>
> I tried to subscribe to mailing lists documented here
> http://maven.apache.org/surefire/maven-surefire-plugin/mail-lists.html
> What I got back was
> {noformat}
>- The following addresses had permanent fatal errors -
>
> (reason: 550 mail to surefire-users-subscr...@maven.apache.org not
> accepted here)
>- Transcript of session follows -
> ... while talking to mx1.us.apache.org.:
> >>> DATA
> <<< 550 mail to surefire-users-subscr...@maven.apache.org not accepted here
> 550 5.1.1 ... User unknown
> <<< 503 RCPT first
> {noformat}
> The archives linked there seem to contain only messages up to year 2010 or so.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-1075) Addresses to documented mailing lists in Maven site dead
[
https://jira.codehaus.org/browse/SUREFIRE-1075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reassigned SUREFIRE-1075:
Assignee: Michael Osipov
> Addresses to documented mailing lists in Maven site dead
>
>
> Key: SUREFIRE-1075
> URL: https://jira.codehaus.org/browse/SUREFIRE-1075
> Project: Maven Surefire
> Issue Type: Bug
> Components: documentation
>Reporter: Marcel Stör
>Assignee: Michael Osipov
>Priority: Critical
> Fix For: 2.18
>
>
> I tried to subscribe to mailing lists documented here
> http://maven.apache.org/surefire/maven-surefire-plugin/mail-lists.html
> What I got back was
> {noformat}
>- The following addresses had permanent fatal errors -
>
> (reason: 550 mail to surefire-users-subscr...@maven.apache.org not
> accepted here)
>- Transcript of session follows -
> ... while talking to mx1.us.apache.org.:
> >>> DATA
> <<< 550 mail to surefire-users-subscr...@maven.apache.org not accepted here
> 550 5.1.1 ... User unknown
> <<< 503 RCPT first
> {noformat}
> The archives linked there seem to contain only messages up to year 2010 or so.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
