[jira] [Commented] (MJAR-198) jar:jar without classifier replaces default jar
[
https://issues.apache.org/jira/browse/MJAR-198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14633112#comment-14633112
]
Elias Elmqvist Wulcan commented on MJAR-198:
That is very nice but the artifact is still attached and installed which is
opposite of what the documentation says.
{quote}
classifier
String
Classifier to add to the artifact generated. If given, the artifact will be
attached. _If this is not given,it will merely be written to the output
directory according to the finalName._
{quote}
A project using jar packaging and also building some intermediary jar files,
will have its default jar overwritten by one of the intermediary jar files on
install. If the intermediary jars are strange in some way, for example with
special class path prefixes or special excludes, this behavior will cause
depending projects to fail.
> jar:jar without classifier replaces default jar
> ---
>
> Key: MJAR-198
> URL: https://issues.apache.org/jira/browse/MJAR-198
> Project: Maven JAR Plugin
> Issue Type: Bug
>Affects Versions: 2.3.1, 2.3.2, 2.4, 2.5, 2.6
> Environment: Windows 8.1 Pro
> JDK 1.8 45
> Maven 3.2.5
>Reporter: Elias Elmqvist Wulcan
>Priority: Minor
> Labels: newbie
> Attachments: 0.tar, mvn.install.debug.txt
>
>
> If I add an execution of jar:jar in a project of packaging jar and do not
> configure a classifier for the additional jar, the additional jar will be
> installed instead of the default jar.
> Omitting a classifier in the configuration for the goal jar:jar is documented
> to have the effect that the jar will not be attached and this is the behavior
> that I want. Instead, the jar is attached and replaces the default jar.
> AbstractJarMojo.java:254 checks nullness of classifier to decide whether to
> attach or not. JarMojo.java:51 declares a default value the empty string for
> classifier. Maybe the combination of these lines cause the bug.
> http://svn.apache.org/viewvc/maven/plugins/tags/maven-jar-plugin-2.6/src/main/java/org/apache/maven/plugin/jar/AbstractJarMojo.java?revision=1664111&view=markup
> http://svn.apache.org/viewvc/maven/plugins/tags/maven-jar-plugin-2.6/src/main/java/org/apache/maven/plugin/jar/JarMojo.java?revision=1664111&view=markup
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MWAR-351) Optional dependency not being included in the WEB-INF/lib folder
[ https://issues.apache.org/jira/browse/MWAR-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14633629#comment-14633629 ] Michael Osipov commented on MWAR-351: - Probably the documentation is not clear on this. Why do you want to use optional deps with WAR files at all? > Optional dependency not being included in the WEB-INF/lib folder > > > Key: MWAR-351 > URL: https://issues.apache.org/jira/browse/MWAR-351 > Project: Maven WAR Plugin > Issue Type: Bug >Affects Versions: 2.2 >Reporter: Hockchai Lim >Priority: Minor > > I've a maven web module that has several dependencies that are declared with > true in pom.xml. For example: > > log4j > log4j > true > > When performing packaging of this project, Maven WAR Plugin is not including > those optional dependencies to the WEB-INF/lib folder, which I think is > incorrect. According to > https://maven.apache.org/guides/introduction/introduction-to-optional-and-excludes-dependencies.html, > optional dependency should work like transitive dependency for this web > module. Optional dependency should only be ignored on projects/modules that > reference this web modle. > Below is the relevant sections from > https://maven.apache.org/guides/introduction/introduction-to-optional-and-excludes-dependencies.html > link: > How do optional dependencies work? > Project-A -> Project-B > The diagram above says that Project-A depends on Project-B. When A declares B > as an optional dependency in its POM, this relationship remains unchanged. > Its just like a normal build where Project-B will be added in its classpath. > Project-X -> Project-A > But when another project(Project-X) declares Project-A as a dependency in its > POM, the optional dependency takes effect. You'll notice that Project-B is > not included in the classpath of Project-X; you will need to declare it > directly in your POM in order for B to be included in X's classpath. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MWAR-351) Optional dependency not being included in the WEB-INF/lib folder
[ https://issues.apache.org/jira/browse/MWAR-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14633694#comment-14633694 ] Hockchai Lim commented on MWAR-351: --- This WAR module is really a EJB module. I followed Tomee's suggestion on packaging a EJB in WAR file (http://tomee.apache.org/deploying-in-tomee.html). So, this WAR module is really a EJB server app. All the dependencies declared in this module are for this module only. For all its ejb client modules, I would do below to include the ejb client jar: MyEJBGroupID MyEJBArtifactId 1.0 ejb-client ejb client module does not need server's transitive dependencies, and hence the optional attribute are added to them. The purpose of optional dependency is to allow the author to declare dependency for a project/module that is strictly for that project/module only. The WAR plugin not including optional dependency in WEB-INF/lib for that project/module seems to be breaking the purpose of this attribute. > Optional dependency not being included in the WEB-INF/lib folder > > > Key: MWAR-351 > URL: https://issues.apache.org/jira/browse/MWAR-351 > Project: Maven WAR Plugin > Issue Type: Bug >Affects Versions: 2.2 >Reporter: Hockchai Lim >Priority: Minor > > I've a maven web module that has several dependencies that are declared with > true in pom.xml. For example: > > log4j > log4j > true > > When performing packaging of this project, Maven WAR Plugin is not including > those optional dependencies to the WEB-INF/lib folder, which I think is > incorrect. According to > https://maven.apache.org/guides/introduction/introduction-to-optional-and-excludes-dependencies.html, > optional dependency should work like transitive dependency for this web > module. Optional dependency should only be ignored on projects/modules that > reference this web modle. > Below is the relevant sections from > https://maven.apache.org/guides/introduction/introduction-to-optional-and-excludes-dependencies.html > link: > How do optional dependencies work? > Project-A -> Project-B > The diagram above says that Project-A depends on Project-B. When A declares B > as an optional dependency in its POM, this relationship remains unchanged. > Its just like a normal build where Project-B will be added in its classpath. > Project-X -> Project-A > But when another project(Project-X) declares Project-A as a dependency in its > POM, the optional dependency takes effect. You'll notice that Project-B is > not included in the classpath of Project-X; you will need to declare it > directly in your POM in order for B to be included in X's classpath. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (MCHECKSTYLE-303) Integration Tests MCHECKSTYLE-295 failed for Maven 2.2.1
[
https://issues.apache.org/jira/browse/MCHECKSTYLE-303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg closed MCHECKSTYLE-303.
---
Resolution: Duplicate
> Integration Tests MCHECKSTYLE-295 failed for Maven 2.2.1
>
>
> Key: MCHECKSTYLE-303
> URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-303
> Project: Maven Checkstyle Plugin
> Issue Type: Bug
>Affects Versions: 2.16
>Reporter: Karl Heinz Marbaise
> Attachments: build.log, mvn.log
>
>
> The integration test MCHECKSTYLE-295 failed for Maven 2.2.1 with Java 1.7
> {code}
> ~/Downloads/maven-checkstyle-plugin-2.16$ mvn --version
> Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200)
> Java version: 1.7.0_21
> Java home: /Library/Java/JavaVirtualMachines/jdk1.7.0_21.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x" version: "10.8.5" arch: "x86_64" Family: "mac"
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5805) Custom packaging types: configuring DefaultLifecycleMapping mojo executions
[
https://issues.apache.org/jira/browse/MNG-5805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14633919#comment-14633919
]
Hudson commented on MNG-5805:
-
SUCCESS: Integrated in maven-3.x #1093 (See
[https://builds.apache.org/job/maven-3.x/1093/])
MNG-5805: Restore binary compatibility (jason: rev
3677220f6e499e97f2b47b0593bc394b689d14d6)
*
maven-core/src/main/java/org/apache/maven/lifecycle/mapping/LifecyclePhase.java
* maven-core/src/main/java/org/apache/maven/lifecycle/mapping/Lifecycle.java
* maven-core/src/main/java/org/apache/maven/lifecycle/Lifecycle.java
*
maven-core/src/main/java/org/apache/maven/lifecycle/mapping/DefaultLifecycleMapping.java
*
maven-core/src/main/java/org/apache/maven/lifecycle/internal/DefaultLifecyclePluginAnalyzer.java
*
maven-core/src/main/java/org/apache/maven/lifecycle/mapping/LifecycleMapping.java
> Custom packaging types: configuring DefaultLifecycleMapping mojo executions
> ---
>
> Key: MNG-5805
> URL: https://issues.apache.org/jira/browse/MNG-5805
> Project: Maven
> Issue Type: Improvement
> Components: Plugins and Lifecycle
>Reporter: Anton Tanasenko
>Assignee: Jason van Zyl
>Priority: Minor
> Fix For: 3.3.4
>
>
> Currently, DefaultLifecycleMapping does not support mapping phases to goals
> with a custom configuration (see
> maven-core/src/main/resources/META-INF/plexus/default-bindings.xml). It is
> impossible to bind, say, an assembly plugin to 'package' phase within a
> custom packaging type, since assembly plugin requires a meaningful
> configuration to be set.
> At my job, we have a number of poms, each serving a purpose of defining a
> lifecycle for a particular type of project (there's one for jar, a couple for
> wars and several more for other types of deployable artifacts).
> Now that I somewhat understand maven's lifecycle, It seems natural to convert
> such poms to custom packaging types, leaving only a single parent with global
> config and pluginManagement. But it is currently impossible, since we are
> using mostly standard plugins (only occasional dedicated ones) to configure
> projects' lifecycles.
> I did some digging around and put together a relatively straightforward
> change to maven-core:
> https://github.com/apache/maven/compare/master...atanasenko:mng-5805-lifecycle-mojo-config?w=1
> It both introduces support for specifying configuration and dependencies for
> mojo executions:
> {code:xml}
>
>
>
> org.apache.maven.plugins:maven-install-plugin:2.4:install
> ...
> ...
>
>
> ...
>
>
>
> {code}
> as well as retains support for existing mapping syntax:
> {code:xml}
> org.apache.maven.plugins:maven-install-plugin:2.4:install,
> ...
> {code}
> I will put together some its (as well as make sure that existing are running
> ok) and create a pull request for both. Also, there are a couple of changes
> that break API in org/apache/maven/lifecycle/Lifecycle.java and
> org/apache/maven/lifecycle/mapping/Lifecycle.java. How critical is it to
> mantain compatibility in those two?
> ITS:
> https://github.com/apache/maven-integration-testing/compare/master...atanasenko:mng-5805-lifecycle-mojo-config?w=1
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5841) Install plugin should generate md5 in same format as md5sum
[ https://issues.apache.org/jira/browse/MNG-5841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14634021#comment-14634021 ] Julian Hyde commented on MNG-5841: -- For Apache projects, note that these are the pertinent guidelines: http://www.apache.org/dev/release-distribution#sigs-and-sums > Install plugin should generate md5 in same format as md5sum > --- > > Key: MNG-5841 > URL: https://issues.apache.org/jira/browse/MNG-5841 > Project: Maven > Issue Type: Bug >Reporter: Julian Hyde > > maven-install-plugin generates md5 and sha1 files that contain just a > checksum (and no newline), whereas md5sum generates a file with a checksum > and the file name. > It would be good to support that format. > See discussion in CALCITE-747. I would rather use maven than resorting to > shell scripts as the Phoenix project has (see a later comment in that thread). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MNG-5841) Install plugin should generate md5 in same format as md5sum
[ https://issues.apache.org/jira/browse/MNG-5841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Hyde updated MNG-5841: - Summary: Install plugin should generate md5 in same format as md5sum (was: Install plugin should generate md5 in same format as ) > Install plugin should generate md5 in same format as md5sum > --- > > Key: MNG-5841 > URL: https://issues.apache.org/jira/browse/MNG-5841 > Project: Maven > Issue Type: Bug >Reporter: Julian Hyde > > maven-install-plugin generates md5 and sha1 files that contain just a > checksum (and no newline), whereas md5sum generates a file with a checksum > and the file name. > It would be good to support that format. > See discussion in CALCITE-747. I would rather use maven than resorting to > shell scripts as the Phoenix project has (see a later comment in that thread). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNGSITE-251) Update link to SortPom reference
[ https://issues.apache.org/jira/browse/MNGSITE-251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14634226#comment-14634226 ] Manfred Moser commented on MNGSITE-251: --- This should probably link to the tidy maven plugin http://www.mojohaus.org/tidy-maven-plugin/pom-mojo.html > Update link to SortPom reference > > > Key: MNGSITE-251 > URL: https://issues.apache.org/jira/browse/MNGSITE-251 > Project: Maven Project Web Site > Issue Type: Documentation >Reporter: Björn Ekryd >Priority: Minor > Labels: documentation, easyfix > > On the page https://maven.apache.org/developers/conventions/code.html, you > have a link to the SortPom plugin. > Since Google Code is shutting down, the plugin has moved location to GitHub. > Please change the plugin link reference to https://github.com/Ekryd/sortpom -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MCHECKSTYLE-290) add a history table to show which version of Chesktyle is used by default in which version of m-checkstyle-p
[ https://issues.apache.org/jira/browse/MCHECKSTYLE-290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14634311#comment-14634311 ] Roman Ivanov commented on MCHECKSTYLE-290: -- > but I don't know how to track evolution in Chesktyle documentation new check is rare event for Checkstyle for now. Usually we extend Check with new options to let it be more customizable to user expectations. In release notes we try to split such updates to separate group to ease user detection of that. But it might be reasonable to keep track in what version Check is introduced and in what version option is introduced. We show only latest documentation , and plugin is always behind by version of used checkstyle. > add a history table to show which version of Chesktyle is used by default in > which version of m-checkstyle-p > > > Key: MCHECKSTYLE-290 > URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-290 > Project: Maven Checkstyle Plugin > Issue Type: Improvement >Affects Versions: 2.15 >Reporter: Hervé Boutemy >Assignee: Hervé Boutemy > Fix For: 2.16 > > > this will ease people having problems probably related to Checkstyle > evolution, but which are hard to track at the moment > see > http://mail-archives.apache.org/mod_mbox/maven-users/201504.mbox/%3C0A05D02C-865F-452F-8EA3-CEE499010396%40talios.com%3E > notice with that documentation, it will be easier to go from m-checkstyle-p > version to Checkstyle version, but I don't know how to track evolution in > Chesktyle documentation... -- This message was sent by Atlassian JIRA (v6.3.4#6332)
