[jira] (MNG-5540) Simplyfied form of overridden scope on transitive dependencies
[
https://jira.codehaus.org/browse/MNG-5540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana closed MNG-5540.
-
Resolution: Not A Bug
> Simplyfied form of overridden scope on transitive dependencies
> --
>
> Key: MNG-5540
> URL: https://jira.codehaus.org/browse/MNG-5540
> Project: Maven 2 & 3
> Issue Type: New Feature
> Components: Dependencies
>Affects Versions: 3.1.1
>Reporter: Tibor Digana
>Priority: Critical
>
> I am thinking of a new feature since Maven's exclusion are two steps process
> in practice.
> In order to change the scope from compile to provided on transitive
> dependency you exclude dependency via
> {code:xml}
>
>
> ...
>
>
>... transitive dependency ...
>
>
>
>
> {code}
> Then put such transitive {{}} with {{scope=provided}} which was
> excluded above.
> {code:xml}
>
>
> ...
> provided
>
>
> {code}
> This is waste because you have to touch the exc.dependency twice and the POM
> xml is getting huge.
> Maybe another syntax would simplify:
> {code:xml}
>
>
> ...
>
>
> ... transitive dependency ...
> provided
>
>
>
>
> {code}
> Validation should fail if no such transitive dependency in includes section
> is specified for the wrapping dependency.
> If the transitive dependency is specified in other sections or inherited, the
> scopes should be merged.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5536) Wrong runtime classpath if inheriting dependencies specified by profile from parent
[ https://jira.codehaus.org/browse/MNG-5536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana closed MNG-5536. - Resolution: Not A Bug > Wrong runtime classpath if inheriting dependencies specified by profile from > parent > --- > > Key: MNG-5536 > URL: https://jira.codehaus.org/browse/MNG-5536 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Profiles >Affects Versions: 3.1.1 > Environment: Win >Reporter: Tibor Digana >Priority: Critical > Attachments: with profiles and with parents.zip > > > The module DAO-BOM(pom) defines dependency within a profile. > Other module webapp(war) which indirectly inherits from DAO-BOM does not see > such dependency hibernate-core-4.2.6.Final.jar and dependency which was not > excluded hibernate-commons-annotations-4.0.2.Final.jar > Since the failure results in dependency and war plugin, it looks like the bug > is in Maven core and related to profiles. > I found this issue when I examied the workaround for > https://jira.codehaus.org/browse/MNG-2205 > The problem is that the build result is different in Maven 2.2.1 and Maven > 3.1.1 in webapp module. > The Maven 2.2.1 works as expected. > There are two issues with Maven 3.1.1 : > + Maven 3 ignored two Hibernate runtime artifacts which I expect in WAR file; > + classpath produced by maven-dependency-plugin:build-classpath does not have > those two runtime artifacts if includeScope=runtime. See the webapp POM. > The Zip file contains the project and four text files. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SCM-740) Maven Release Plugin releases SNAPSHOT instead of STABLE version
[ https://jira.codehaus.org/browse/SCM-740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=345070#comment-345070 ] Cédric Jonas commented on SCM-740: -- @Mark: is there anything new about a new release containing this fix? Thanks. > Maven Release Plugin releases SNAPSHOT instead of STABLE version > > > Key: SCM-740 > URL: https://jira.codehaus.org/browse/SCM-740 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-git > Environment: Everywhere with maven-scm-provider-gitexe of version 1.9 > (and maybe older) >Reporter: Jan Novotný >Assignee: Mark Struberg > Fix For: 1.10 > > Attachments: Wrong_base_directory_used1.patch > > > If you have following project structure: > - superproject [Git repository root] > - projectA [release target] > - projectB [release target] > in other words you release subproject of a larger Git repository separately, > you probably run at the same issue as we did. No recipe from above mentioned > sources solves your problems and during release:prepare phase still no commit > of stable pom.xml occurs. There is another bug in GitStatusConsumer class > that checks output of the git status --porcelain command and verifies > existency of the mentioned files on local filesystem. Regretfully it uses > working directory instead of git repository root as the base folder and thus > it constructs invalid path to the file where project folder directory is > duplicated. > Problem is better described here: > http://blog.novoj.net/2014/01/24/maven-release-plugin-releases-snapshot-instead-of-stable-version -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5620) LinkageError when CDI is in the classpath
Martin Grigorov created MNG-5620: Summary: 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.2.1, 3.1.1, 3.1.0, 3.1.0-alpha-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] (MPLUGIN-264) Allow other packaging types
[ https://jira.codehaus.org/browse/MPLUGIN-264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Fedorenko closed MPLUGIN-264. -- Resolution: Fixed http://svn.apache.org/viewvc?view=revision&revision=1588273 > Allow other packaging types > --- > > Key: MPLUGIN-264 > URL: https://jira.codehaus.org/browse/MPLUGIN-264 > Project: Maven Plugin Tools > Issue Type: Improvement > Components: Plugin Plugin >Reporter: Igor Fedorenko >Assignee: Igor Fedorenko > Fix For: 3.3 > > > Currently, maven-plugin-plugin silently ignores projects that packaging > different from "maven-plugin". Although this is a reasonable default, it is > sometimes useful to generate plugin descriptor for "jar" projects or projects > that use domain-specific packaging types. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MRELEASE-875) release:prepare does not commit pom.xml if not in the git root
[ https://jira.codehaus.org/browse/MRELEASE-875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=345083#comment-345083 ] Robert Scholte commented on MRELEASE-875: - The root cause should be searched in the SCM project. SCM-740 also describes a problem with Git 1.9, but it exposes another problem, but it could be very well related. > release:prepare does not commit pom.xml if not in the git root > -- > > Key: MRELEASE-875 > URL: https://jira.codehaus.org/browse/MRELEASE-875 > Project: Maven Release Plugin > Issue Type: Bug > Components: prepare >Affects Versions: 2.5 > Environment: git 1.9.0 >Reporter: john ten Den > > When the project pom.xml is not in the Git project root (f.e. in the "src" > directory) the pom.xml not committed and pushed (before tagging) > Commit of the pom.xml during release:prepare works fine if it is in the / > (root) of the git repository > Using the pom.xml in a subdirectory worked well with version 2.4.2 using git > 1.7. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
