[jira] [Closed] (MJAR-234) Class-Path: attribute in manifest shouldn't have broken names
[ https://issues.apache.org/jira/browse/MJAR-234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise closed MJAR-234. Resolution: Cannot Reproduce No problem. If you can't reproduce it's hard to find the problem. But if you find it some day..please open an issue thanks for trying to make Maven better and no need to excuse... > Class-Path: attribute in manifest shouldn't have broken names > - > > Key: MJAR-234 > URL: https://issues.apache.org/jira/browse/MJAR-234 > Project: Maven JAR Plugin > Issue Type: Bug > Environment: 10:20:02 $ mvn --version > Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; > 2015-11-10T16:41:47+00:00) > Maven home: /Applications/local/dev/maven > Java version: 1.8.0_121, vendor: Oracle Corporation > Java home: > /Library/Java/JavaVirtualMachines/jdk1.8.0_121.jdk/Contents/Home/jre > Default locale: en_GB, platform encoding: UTF-8 > OS name: "mac os x", version: "10.12.3", arch: "x86_64", family: "mac" > 10:21:57 $ > I've tried the 3.0.2 version of the jar plug-in >Reporter: Marco Brandizi > Labels: manifest > > I'd like to reopen https://issues.apache.org/jira/browse/MJAR-121: in > MANIFEST.MF, when you spawn a list like this for Class-Path: > Class-Path: commons-lang-2.4.jar plexus-utils-1.1.jar workflow-base-1. > 0.4-SNAPSHOT.jar commons-cli-1.2.jar > (there is a space before 0.4, JIRA is not rendering it here) > Java doesn't see the classes in workflow-base-1.0.4-SNAPSHOT.jar, which has a > break in between. If I change it manually, to list one jar per line (with two > spaces at the begin of the line), it works as expected. Also note I do put a > blank line at the end in both cases. > Generating that list the way you do might be compatible with the jar > specifications, but Java 8 apparently isn't compatible with them and hence > the end result is a failing JAR. > The first fix coming in my mind is to list one jar per line, as I did. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MNG-6186) switch to improved HawtJNI
[
https://issues.apache.org/jira/browse/MNG-6186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly updated MNG-6186:
--
Fix Version/s: (was: 3.5.0-candidate)
3.5.1-candidate
> switch to improved HawtJNI
> --
>
> Key: MNG-6186
> URL: https://issues.apache.org/jira/browse/MNG-6186
> Project: Maven
> Issue Type: Sub-task
> Components: Bootstrap & Build, Command Line
>Affects Versions: 3.5.0-beta-1
>Reporter: Hervé Boutemy
> Fix For: 3.5.1-candidate
>
>
> calculating the directory where jansi native lib is available required a hack
> = copy/paste HawtJNI code
> https://git1-us-west.apache.org/repos/asf?p=maven.git;a=blobdiff;f=maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java;h=350fa61c5da633a04fa17c1ed7530096c4ad60ad;hp=b3367c177c91fae32831207ab4a568121da621f0;hb=181b0215aa1199e152db9d2c08b1a01436547805;hpb=809ba34055c70eab31876aad03c577e925fa2e6e
> This should become a HawtJNI feature (ie. {{library.jansi.path}} should point
> to {{lib/jansi-native}} and HawtJNI should find the right directory the same
> way it does it in classpath), then we'll be able to integrate it instead of
> hacking
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MNG-6167) Clean up dependency mess (reported by dependency:analyze)
[
https://issues.apache.org/jira/browse/MNG-6167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly updated MNG-6167:
--
Fix Version/s: (was: 3.5.0-candidate)
3.5.1-candidate
> Clean up dependency mess (reported by dependency:analyze)
> -
>
> Key: MNG-6167
> URL: https://issues.apache.org/jira/browse/MNG-6167
> Project: Maven
> Issue Type: Task
>Affects Versions: 3.3.9
>Reporter: Michael Osipov
>Assignee: Michael Osipov
> Fix For: 3.5.1-candidate
>
> Attachments: dep-analayze.log
>
>
> {{mvn dependency:analyze}} reports that a lot of transitive dependencies are
> used directly, but never declared in the POMs.
> Parts have been done in
> [934e030f049d955c330c4b61abb66a543f9ca990|https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=934e030f049d955c330c4b61abb66a543f9ca990].
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MNG-6188) Console color not properly reset when interrupting build process
[ https://issues.apache.org/jira/browse/MNG-6188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MNG-6188: -- Fix Version/s: (was: 3.5.0-candidate) 3.5.1-candidate > Console color not properly reset when interrupting build process > > > Key: MNG-6188 > URL: https://issues.apache.org/jira/browse/MNG-6188 > Project: Maven > Issue Type: Bug > Components: Logging >Affects Versions: 3.5.0-alpha-1 >Reporter: Robert Scholte > Fix For: 3.5.1-candidate > > Attachments: jansi-bug.PNG > > > When interrupting the build process for some reason, it could happen that > console has still a color assigned. > For a possible result, see the attachment (most of mint should have been > white) -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MNG-6169) Lifecycle/binding plugin version updates
[ https://issues.apache.org/jira/browse/MNG-6169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MNG-6169: -- Fix Version/s: (was: 3.5.0-candidate) 3.5.1-candidate > Lifecycle/binding plugin version updates > > > Key: MNG-6169 > URL: https://issues.apache.org/jira/browse/MNG-6169 > Project: Maven > Issue Type: Improvement >Affects Versions: 3.3.9 >Reporter: Christian Schulte >Assignee: Michael Osipov >Priority: Minor > Fix For: 3.5.1-candidate > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MNG-6185) Replace doclettag explanation with annotations in AbstractMojo javadoc
[
https://issues.apache.org/jira/browse/MNG-6185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly updated MNG-6185:
--
Fix Version/s: (was: 3.5.0-candidate)
3.5.0
> Replace doclettag explanation with annotations in AbstractMojo javadoc
> --
>
> Key: MNG-6185
> URL: https://issues.apache.org/jira/browse/MNG-6185
> Project: Maven
> Issue Type: Improvement
>Reporter: Robert Scholte
>Priority: Minor
> Fix For: 3.5.0
>
>
> The javadoc of {{org.apache.maven.plugin.AbstractMojo}} still describes the
> usage of doclettags, which should be upgraded/rewritten to annotations.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MNG-5359) Declared execution in PluginMgmt gets bound to lifecycle (regression)
[ https://issues.apache.org/jira/browse/MNG-5359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MNG-5359: -- Fix Version/s: (was: 3.5.0-candidate) 3.5.1-candidate > Declared execution in PluginMgmt gets bound to lifecycle (regression) > - > > Key: MNG-5359 > URL: https://issues.apache.org/jira/browse/MNG-5359 > Project: Maven > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 3.0.1, 3.0.2, 3.0.3, 3.0.4 > Environment: Mac OS 10.7.5, Apple JDK 1.6.0_35 > (Same behavior seen on Windows XP with Sun JDK 1.6.0 as well) >Reporter: Anders Hammar >Assignee: Christian Schulte > Fix For: 3.5.1-candidate > > Attachments: binding-test.zip, MNG-5359-IT.patch > > > If a plugin execution binding is declared in pluginManagement it gets bound > to the build lifecycle in Maven 3.0.x, but not with Maven 2.2.1. > My understanding is that the behavior in Maven 3.0 is wrong; an execution > binding needs to be declared in build/plugins/plugin to be bound. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Reopened] (MNG-5359) Declared execution in PluginMgmt gets bound to lifecycle (regression)
[ https://issues.apache.org/jira/browse/MNG-5359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly reopened MNG-5359: --- > Declared execution in PluginMgmt gets bound to lifecycle (regression) > - > > Key: MNG-5359 > URL: https://issues.apache.org/jira/browse/MNG-5359 > Project: Maven > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 3.0.1, 3.0.2, 3.0.3, 3.0.4 > Environment: Mac OS 10.7.5, Apple JDK 1.6.0_35 > (Same behavior seen on Windows XP with Sun JDK 1.6.0 as well) >Reporter: Anders Hammar >Assignee: Christian Schulte > Fix For: 3.5.1-candidate > > Attachments: binding-test.zip, MNG-5359-IT.patch > > > If a plugin execution binding is declared in pluginManagement it gets bound > to the build lifecycle in Maven 3.0.x, but not with Maven 2.2.1. > My understanding is that the behavior in Maven 3.0 is wrong; an execution > binding needs to be declared in build/plugins/plugin to be bound. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MNG-6114) Elements from the global settings should be ordered before elements from the user settings.
[ https://issues.apache.org/jira/browse/MNG-6114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MNG-6114: -- Fix Version/s: (was: 3.5.0-candidate) 3.5.1-candidate > Elements from the global settings should be ordered before elements from the > user settings. > --- > > Key: MNG-6114 > URL: https://issues.apache.org/jira/browse/MNG-6114 > Project: Maven > Issue Type: Bug >Reporter: Christian Schulte >Assignee: Christian Schulte > Fix For: 3.5.1-candidate > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Reopened] (MNG-6114) Elements from the global settings should be ordered before elements from the user settings.
[ https://issues.apache.org/jira/browse/MNG-6114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly reopened MNG-6114: --- > Elements from the global settings should be ordered before elements from the > user settings. > --- > > Key: MNG-6114 > URL: https://issues.apache.org/jira/browse/MNG-6114 > Project: Maven > Issue Type: Bug >Reporter: Christian Schulte >Assignee: Christian Schulte > Fix For: 3.5.1-candidate > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MNG-6172) Precedence of command-line system property options has changed
[
https://issues.apache.org/jira/browse/MNG-6172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly updated MNG-6172:
--
Affects Version/s: (was: 3.5.0-candidate)
> Precedence of command-line system property options has changed
> --
>
> Key: MNG-6172
> URL: https://issues.apache.org/jira/browse/MNG-6172
> Project: Maven
> Issue Type: Bug
> Components: Command Line
>Reporter: Stuart McCulloch
>Assignee: Stephen Connolly
>Priority: Blocker
> Fix For: 3.5.0-alpha-1, 3.5.0
>
>
> The current state of master (what will eventually become 3.5.0) has reversed
> the precedence of command-line system property options compared to previous
> releases of Maven.
> For example, running this command with a basic project:
> {code}
> mvn -Dmaven.repo.local=/tmp/aaa -Dmaven.repo.local=/tmp/zzz validate
> {code}
> using current master will cause {{/tmp/aaa}} to be created (first-one-wins),
> whereas for all previous releases of Maven {{/tmp/zzz}} would have been
> created (last-one-wins)
> This has the potential to break CI builds which relied on the previous
> last-one-wins behaviour.
> This was introduced by the fix for MNG-6078
> https://github.com/apache/maven/commit/ca4303031357a7decaee8de770b71fb2c2fedd28
> - by reversing the whole array the precedence between options on the same
> command line has been reversed, not just the relationship between
> .mvn/maven.config options and command line options.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MNG-6069) Migrate to non deprecated parts of Commons CLI
[
https://issues.apache.org/jira/browse/MNG-6069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly updated MNG-6069:
--
Fix Version/s: (was: 3.5.0)
3.5.1-candidate
> Migrate to non deprecated parts of Commons CLI
> --
>
> Key: MNG-6069
> URL: https://issues.apache.org/jira/browse/MNG-6069
> Project: Maven
> Issue Type: Improvement
> Components: Embedding
>Affects Versions: 3.3.9
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.5.1-candidate
>
>
> At the moment all parts of {{OptionBuilder...}} are marked deprecated in
> {{CLIManager}}. They should be migrated to:
> {code:java}
> Option.builder( HELP ).longOpt( "help" ).desc( "Display help information"
> ).build()
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MNG-6069) Migrate to non deprecated parts of Commons CLI
[
https://issues.apache.org/jira/browse/MNG-6069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly updated MNG-6069:
--
Affects Version/s: 3.5.0
3.5.0-alpha-1
3.5.0-beta-1
> Migrate to non deprecated parts of Commons CLI
> --
>
> Key: MNG-6069
> URL: https://issues.apache.org/jira/browse/MNG-6069
> Project: Maven
> Issue Type: Improvement
> Components: Embedding
>Affects Versions: 3.3.9, 3.5.0-alpha-1, 3.5.0-beta-1, 3.5.0
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.5.1-candidate
>
>
> At the moment all parts of {{OptionBuilder...}} are marked deprecated in
> {{CLIManager}}. They should be migrated to:
> {code:java}
> Option.builder( HELP ).longOpt( "help" ).desc( "Display help information"
> ).build()
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (MNG-6195) Use consistent quoting forms in mvn launcher script
Stephen Connolly created MNG-6195:
-
Summary: Use consistent quoting forms in mvn launcher script
Key: MNG-6195
URL: https://issues.apache.org/jira/browse/MNG-6195
Project: Maven
Issue Type: Bug
Components: core
Affects Versions: 3.5.0-beta-1, 3.5.0-alpha-1
Reporter: Stephen Connolly
Fix For: 3.5.0
We have different forms of quoting in the shell script. We should pick a
consistent policy and follow that.
Specific areas of concern around backticks and {{$(...)}}
Solaris 10 is known to have a true BourneShell which does not understand
{{$(...)}} but the backtick style is very hard to quote effectively
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MNG-6191) mvn -f complains about illegal readlink option under macOS
[
https://issues.apache.org/jira/browse/MNG-6191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hervé Boutemy updated MNG-6191:
---
Priority: Major (was: Minor)
> mvn -f complains about illegal readlink option under macOS
> --
>
> Key: MNG-6191
> URL: https://issues.apache.org/jira/browse/MNG-6191
> Project: Maven
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 3.5.0-alpha-1
> Environment: Java version: 1.8.0_111, vendor: Oracle Corporation
> Java home:
> /Library/Java/JavaVirtualMachines/jdk1.8.0_111.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.10.5", arch: "x86_64", family: "mac"
>Reporter: Andreas Sewe
> Fix For: 3.5.0
>
>
> This is a *regression* from Maven 3.3.9. With 3.5.0-alpha-1, using {{mvn -f}}
> under OS X causes the following error to be printed out (similar to
> MNG-5688), before the command proceeds (AFAICT) without error:
> {noformat}
> > mvn clean package -f releng/repository/pom.xml
> readlink: illegal option -- f
> usage: readlink [-n] [file ...]
> usage: dirname path
> [INFO] Scanning for projects...
> {noformat}
> FWIW, I don’t get this error on a normal {{mvn clean package}} without the
> {{-f}} parameter.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MNG-6191) mvn -f complains about illegal readlink option under macOS
[
https://issues.apache.org/jira/browse/MNG-6191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hervé Boutemy updated MNG-6191:
---
Fix Version/s: 3.5.0
> mvn -f complains about illegal readlink option under macOS
> --
>
> Key: MNG-6191
> URL: https://issues.apache.org/jira/browse/MNG-6191
> Project: Maven
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 3.5.0-alpha-1
> Environment: Java version: 1.8.0_111, vendor: Oracle Corporation
> Java home:
> /Library/Java/JavaVirtualMachines/jdk1.8.0_111.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.10.5", arch: "x86_64", family: "mac"
>Reporter: Andreas Sewe
> Fix For: 3.5.0
>
>
> This is a *regression* from Maven 3.3.9. With 3.5.0-alpha-1, using {{mvn -f}}
> under OS X causes the following error to be printed out (similar to
> MNG-5688), before the command proceeds (AFAICT) without error:
> {noformat}
> > mvn clean package -f releng/repository/pom.xml
> readlink: illegal option -- f
> usage: readlink [-n] [file ...]
> usage: dirname path
> [INFO] Scanning for projects...
> {noformat}
> FWIW, I don’t get this error on a normal {{mvn clean package}} without the
> {{-f}} parameter.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MNG-6191) mvn -f complains about illegal readlink option under macOS
[
https://issues.apache.org/jira/browse/MNG-6191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hervé Boutemy updated MNG-6191:
---
Affects Version/s: 3.5.0-beta-1
> mvn -f complains about illegal readlink option under macOS
> --
>
> Key: MNG-6191
> URL: https://issues.apache.org/jira/browse/MNG-6191
> Project: Maven
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 3.5.0-alpha-1, 3.5.0-beta-1
> Environment: Java version: 1.8.0_111, vendor: Oracle Corporation
> Java home:
> /Library/Java/JavaVirtualMachines/jdk1.8.0_111.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.10.5", arch: "x86_64", family: "mac"
>Reporter: Andreas Sewe
> Fix For: 3.5.0
>
>
> This is a *regression* from Maven 3.3.9. With 3.5.0-alpha-1, using {{mvn -f}}
> under OS X causes the following error to be printed out (similar to
> MNG-5688), before the command proceeds (AFAICT) without error:
> {noformat}
> > mvn clean package -f releng/repository/pom.xml
> readlink: illegal option -- f
> usage: readlink [-n] [file ...]
> usage: dirname path
> [INFO] Scanning for projects...
> {noformat}
> FWIW, I don’t get this error on a normal {{mvn clean package}} without the
> {{-f}} parameter.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MNG-6168) Fix unclosed streams
[ https://issues.apache.org/jira/browse/MNG-6168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hervé Boutemy updated MNG-6168: --- Affects Version/s: 3.5.0-beta-1 > Fix unclosed streams > > > Key: MNG-6168 > URL: https://issues.apache.org/jira/browse/MNG-6168 > Project: Maven > Issue Type: Bug >Affects Versions: 3.3.9, 3.5.0-beta-1 >Reporter: Michael Osipov >Assignee: Christian Schulte > Fix For: 3.5.0 > > > Based on > [0535716fd602eb056ed791b89d7f9a3fb882499c|https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=0535716fd602eb056ed791b89d7f9a3fb882499c]. > several streams remain unclosed or contain some boilterplate code. Let's > clean that up. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (MNG-6196) Update dependences
Sylwester Lachiewicz created MNG-6196: - Summary: Update dependences Key: MNG-6196 URL: https://issues.apache.org/jira/browse/MNG-6196 Project: Maven Issue Type: Improvement Components: Dependencies Affects Versions: 3.5.0-beta-1 Reporter: Sylwester Lachiewicz Priority: Minor Update dependences for maven build Mocito 1.10 -> 2.7.19 Slf4j 1.7.22 -> 1.7.25 (SLF4J-394) logback-classic 1.2.2 With slf4j update we can simplify maven-slf4j-provider implementation -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (DOXIA-554) Parsing time for Markdown documents can take very long and hang site generation
[
https://issues.apache.org/jira/browse/DOXIA-554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hervé Boutemy updated DOXIA-554:
Fix Version/s: 1.8
> Parsing time for Markdown documents can take very long and hang site
> generation
> ---
>
> Key: DOXIA-554
> URL: https://issues.apache.org/jira/browse/DOXIA-554
> Project: Maven Doxia
> Issue Type: Bug
> Components: Module - Markdown
>Affects Versions: 1.7
>Reporter: Michael Benz
> Fix For: 1.8
>
> Attachments: maven-pom-sample-pegdown-performance.zip
>
>
> The parsing time for Markdown documents can take very long and hang site
> generation when e.g. long tables are being generated.
> The author of pegdown has marked the pegdown project deprecated since
> 2016-12-14 [pegdown.org|https://github.com/sirthias/pegdown/] and advises to
> switch to [flexmark-java|https://github.com/vsch/flexmark-java].
> {quote}
> The project is essentially unmaintained with tickets piling up and crucial
> bugs not being fixed.
> pegdown's parsing performance isn't great. In some cases of pathological
> input runtime can even become exponential, which means that the parser either
> appears to "hang" completely or abort processing after a time-out.
> {quote}
> Since the parsing timeout was increased in DOXIA-498 it is now possible to
> "hang" the site creation with a longer table like the one in this example.
> In case this sample is rendered using version 3.3 of the maven site
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (DOXIA-553) Replace pegdown due to deprecation and end of life notice
[
https://issues.apache.org/jira/browse/DOXIA-553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hervé Boutemy closed DOXIA-553.
---
Resolution: Duplicate
Fix Version/s: DOXIA-554
> Replace pegdown due to deprecation and end of life notice
> -
>
> Key: DOXIA-553
> URL: https://issues.apache.org/jira/browse/DOXIA-553
> Project: Maven Doxia
> Issue Type: Improvement
> Components: Module - Markdown
> Environment: maven plugin.
>Reporter: Marc Campbell
> Fix For: DOXIA-554
>
>
> On 2016.12.14, [{{sirthias/pegdown}}|https://github.com/sirthias/pegdown/]
> posted a deprecation notice that "pegdown has reached its end of life."
> The pegdown notice also gives reasons to consider
> [{{@vsch's}}|https://github.com/vsch]
> [{{flexmark-java}}|https://github.com/vsch/flexmark-java] as a replacement.
> See:
> https://github.com/sirthias/pegdown
> https://github.com/vsch/flexmark-java
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (DOXIA-553) Replace pegdown due to deprecation and end of life notice
[
https://issues.apache.org/jira/browse/DOXIA-553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hervé Boutemy updated DOXIA-553:
Fix Version/s: (was: DOXIA-554)
1.8
> Replace pegdown due to deprecation and end of life notice
> -
>
> Key: DOXIA-553
> URL: https://issues.apache.org/jira/browse/DOXIA-553
> Project: Maven Doxia
> Issue Type: Improvement
> Components: Module - Markdown
> Environment: maven plugin.
>Reporter: Marc Campbell
> Fix For: 1.8
>
>
> On 2016.12.14, [{{sirthias/pegdown}}|https://github.com/sirthias/pegdown/]
> posted a deprecation notice that "pegdown has reached its end of life."
> The pegdown notice also gives reasons to consider
> [{{@vsch's}}|https://github.com/vsch]
> [{{flexmark-java}}|https://github.com/vsch/flexmark-java] as a replacement.
> See:
> https://github.com/sirthias/pegdown
> https://github.com/vsch/flexmark-java
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (DOXIA-551) tWiki anchor link generates page link
[
https://issues.apache.org/jira/browse/DOXIA-551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15853162#comment-15853162
]
Hervé Boutemy edited comment on DOXIA-551 at 3/25/17 5:00 PM:
--
Wikiwords and anchors should be treated differently according to the
documentation: (http://twiki.org/cgi-bin/view/TWiki04x01/TextFormattingRules)
I don't know the codebase, but if resolveLink() is used for both, then a
condition would be necessary:
{code:java}if (wikiWord.startsWith("#")) {
return wikiWord;
}
else
{
return "./" + wikiWord + ".html";
}{code}
was (Author: gviczai):
Wikiwords and anchors should be treated differently according to the
documentation: (http://twiki.org/cgi-bin/view/TWiki04x01/TextFormattingRules)
I don't know the codebase, but if resolveLink() is used for both, then a
condition would be necessary:
if (wikiWord.startsWith("#")) {
return wikiWord;
}
else
{
return "./" + wikiWord + ".html";
}
> tWiki anchor link generates page link
> -
>
> Key: DOXIA-551
> URL: https://issues.apache.org/jira/browse/DOXIA-551
> Project: Maven Doxia
> Issue Type: Bug
> Components: Maven plugin, Module - Twiki
>Affects Versions: 1.7
> Environment: Linux
>Reporter: Viczai Gábor
>Priority: Minor
> Labels: anchor, link, link-local, twiki
>
> When generating site doc with maven plugin, html files generated from *.twiki
> files contains wrong links for anchor links.
> In twiki file if I specify [[#MyAnchor][a link]] it generates href="./#MyAnchor.html">a link
> It seems like, no matter what, a ".html" is always inserted at the end of the
> link. (Possibly the link is not recognised as an anchor?!)
> (However, the anchor creation itself is ok. If a line starting with
> "#MyAnchor" in the twiki file is present, the html output will contain the name="MyAnchor">... at the correct place.)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MNG-6196) Update dependences
[ https://issues.apache.org/jira/browse/MNG-6196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15941794#comment-15941794 ] ASF GitHub Bot commented on MNG-6196: - Github user khmarbaise commented on the issue: https://github.com/apache/maven/pull/109 Please mention the JIRA issue in your commit message like this: ``` [MNG-6196] ... ``` otherwise it's hard to follow changes in history...also updating the JIRA issue title would be a good idea if you have a good idea what is more descriptive...;-) > Update dependences > -- > > Key: MNG-6196 > URL: https://issues.apache.org/jira/browse/MNG-6196 > Project: Maven > Issue Type: Improvement > Components: Dependencies >Affects Versions: 3.5.0-beta-1 >Reporter: Sylwester Lachiewicz >Priority: Minor > > Update dependences for maven build > Mocito 1.10 -> 2.7.19 > Slf4j 1.7.22 -> 1.7.25 (SLF4J-394) > logback-classic 1.2.2 > With slf4j update we can simplify maven-slf4j-provider implementation -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (DOXIA-538) Tag used for monospaced is not a valid html5 tag
[
https://issues.apache.org/jira/browse/DOXIA-538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15941796#comment-15941796
]
Hervé Boutemy commented on DOXIA-538:
-
notice {{}} can't replace {{}} since it's a block, then adds newline
the question is: do modern browsers not support good'ole HTML 4?
> Tag used for monospaced is not a valid html5 tag
> --
>
> Key: DOXIA-538
> URL: https://issues.apache.org/jira/browse/DOXIA-538
> Project: Maven Doxia
> Issue Type: Bug
> Components: Core, Module - Xdoc, Module - Xhtml
>Affects Versions: 1.6
>Reporter: Ievgen Degtiarenko
> Attachments: monospaced_for_doxia.patch
>
>
> https://maven.apache.org/doxia/references/apt-format.html
> <<>> is converted into Monospaced that is not valid tag
> in html5
> Attached patch replaces tag with that is the most common tag that
> is displayed as monospaced text in modern browsers.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (DOXIA-497) APTSink: links and paragraphs inside tables
[ https://issues.apache.org/jira/browse/DOXIA-497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15941798#comment-15941798 ] Hervé Boutemy commented on DOXIA-497: - what makes you wait for 2.0? this does look like a simple bugfix, isn't it? or did I miss something important? > APTSink: links and paragraphs inside tables > --- > > Key: DOXIA-497 > URL: https://issues.apache.org/jira/browse/DOXIA-497 > Project: Maven Doxia > Issue Type: Bug > Components: Module - Apt >Affects Versions: 1.4, 1.5 >Reporter: Martin Kurz > Attachments: table-generation.patch > > > When generating table markup with APTSink, link content is written to buffer > while structure markup is directly written, so the generated markup is > invalid. When writing paragraphs inside table cells, the generated markup is > also invalid. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (DOXIA-497) APTSink: links and paragraphs inside tables
[ https://issues.apache.org/jira/browse/DOXIA-497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15941798#comment-15941798 ] Hervé Boutemy edited comment on DOXIA-497 at 3/25/17 5:10 PM: -- [~michael-o] what makes you wait for 2.0? this does look like a simple bugfix, isn't it? or did I miss something important? was (Author: hboutemy): what makes you wait for 2.0? this does look like a simple bugfix, isn't it? or did I miss something important? > APTSink: links and paragraphs inside tables > --- > > Key: DOXIA-497 > URL: https://issues.apache.org/jira/browse/DOXIA-497 > Project: Maven Doxia > Issue Type: Bug > Components: Module - Apt >Affects Versions: 1.4, 1.5 >Reporter: Martin Kurz > Attachments: table-generation.patch > > > When generating table markup with APTSink, link content is written to buffer > while structure markup is directly written, so the generated markup is > invalid. When writing paragraphs inside table cells, the generated markup is > also invalid. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (DOXIA-536) AptParser does not force linebreak in Sink after a comment is written
[
https://issues.apache.org/jira/browse/DOXIA-536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hervé Boutemy closed DOXIA-536.
---
Resolution: Won't Fix
> AptParser does not force linebreak in Sink after a comment is written
> -
>
> Key: DOXIA-536
> URL: https://issues.apache.org/jira/browse/DOXIA-536
> Project: Maven Doxia
> Issue Type: Bug
> Components: Module - Apt
>Affects Versions: 1.6
>Reporter: Michael Osipov
>Priority: Minor
>
> Consider this comment block:
> {noformat}
> ~~ Copyright 2012 Michael Osipov
> ~~
> ~~ Licensed under the Apache License, Version 2.0 (the "License");
> ~~ you may not use this file except in compliance with the License.
> ~~ You may obtain a copy of the License at
> ~~
> ~~ http://www.apache.org/licenses/LICENSE-2.0
> ~~
> ~~ Unless required by applicable law or agreed to in writing, software
> ~~ distributed under the License is distributed on an "AS IS" BASIS,
> ~~ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> ~~ See the License for the specific language governing permissions and
> ~~ limitations under the License.
> {noformat}
> Apt's comment syntax goes to the end of the line which would mean that if the
> {{AptParser}} hits a comment it has to create a line break with the target
> {{Sink}} too. Unfortunately, the result in, e.g., HTML is:
> {noformat}
>
> {noformat}
> This is ugly doesn't make the comment readible at all. Investigate how we can
> send a {{line.separator}}, i.e., pretty-print the output.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (MSITE-791) upgrade Doxia to 1.8 to benefit from new Markdown parser (require Java 7)
Hervé Boutemy created MSITE-791: --- Summary: upgrade Doxia to 1.8 to benefit from new Markdown parser (require Java 7) Key: MSITE-791 URL: https://issues.apache.org/jira/browse/MSITE-791 Project: Maven Site Plugin Issue Type: Improvement Affects Versions: 3.6 Reporter: Hervé Boutemy Fix For: 3.7 see DOXIA-554 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MNG-6112) Central repository in the 4.0.0 super POM should declare update policy 'never'.
[ https://issues.apache.org/jira/browse/MNG-6112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15941885#comment-15941885 ] Hudson commented on MNG-6112: - SUCCESS: Integrated in Jenkins build maven-3.x #1582 (See [https://builds.apache.org/job/maven-3.x/1582/]) [MNG-6112] Central repository in the 4.0.0 super POM should declare (schulte: [http://git-wip-us.apache.org/repos/asf/?p=maven.git&a=commit&h=8400984ac5201ae6bf06bfa88ade8a8468c76634]) * (edit) maven-core/src/main/java/org/apache/maven/bridge/MavenRepositorySystem.java * (edit) maven-model-builder/src/main/resources/org/apache/maven/model/pom-4.0.0.xml > Central repository in the 4.0.0 super POM should declare update policy > 'never'. > --- > > Key: MNG-6112 > URL: https://issues.apache.org/jira/browse/MNG-6112 > Project: Maven > Issue Type: Bug >Affects Versions: 3.5.0-beta-1 >Reporter: Christian Schulte >Assignee: Christian Schulte > Fix For: 3.5.0 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (DOXIA-554) Parsing time for Markdown documents can take very long and hang site generation
[
https://issues.apache.org/jira/browse/DOXIA-554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15941969#comment-15941969
]
Hudson commented on DOXIA-554:
--
SUCCESS: Integrated in Jenkins build doxia-all #329 (See
[https://builds.apache.org/job/doxia-all/329/])
[DOXIA-554] migrated Markdown parser from pegdown to flaxmark-java
Submitted by: Vladimir Schneider (hboutemy:
[http://svn.apache.org/viewvc/?view=rev&rev=1788689])
* (edit) ./doxia/doxia-modules/doxia-module-markdown/pom.xml
* (add)
./doxia/doxia-modules/doxia-module-markdown/src/main/java/org/apache/maven/doxia/module/markdown/FlexmarkDoxiaExtension.java
* (add)
./doxia/doxia-modules/doxia-module-markdown/src/main/java/org/apache/maven/doxia/module/markdown/FlexmarkDoxiaNodeRenderer.java
* (edit)
./doxia/doxia-modules/doxia-module-markdown/src/main/java/org/apache/maven/doxia/module/markdown/MarkdownParser.java
* (delete)
./doxia/doxia-modules/doxia-module-markdown/src/main/java/org/apache/maven/doxia/module/markdown/MarkdownToDoxiaHtmlSerializer.java
* (edit) ./doxia/doxia-modules/doxia-module-markdown/src/site/apt/index.apt
* (edit)
./doxia/doxia-modules/doxia-module-markdown/src/test/java/org/apache/maven/doxia/module/markdown/MarkdownParserTest.java
* (edit)
./doxia/doxia-modules/doxia-module-markdown/src/test/resources/html-content.md
* (edit) ./doxia/doxia-modules/doxia-module-markdown/src/test/resources/test.md
* (edit) ./doxia/pom.xml
> Parsing time for Markdown documents can take very long and hang site
> generation
> ---
>
> Key: DOXIA-554
> URL: https://issues.apache.org/jira/browse/DOXIA-554
> Project: Maven Doxia
> Issue Type: Bug
> Components: Module - Markdown
>Affects Versions: 1.7
>Reporter: Michael Benz
> Fix For: 1.8
>
> Attachments: maven-pom-sample-pegdown-performance.zip
>
>
> The parsing time for Markdown documents can take very long and hang site
> generation when e.g. long tables are being generated.
> The author of pegdown has marked the pegdown project deprecated since
> 2016-12-14 [pegdown.org|https://github.com/sirthias/pegdown/] and advises to
> switch to [flexmark-java|https://github.com/vsch/flexmark-java].
> {quote}
> The project is essentially unmaintained with tickets piling up and crucial
> bugs not being fixed.
> pegdown's parsing performance isn't great. In some cases of pathological
> input runtime can even become exponential, which means that the parser either
> appears to "hang" completely or abort processing after a time-out.
> {quote}
> Since the parsing timeout was increased in DOXIA-498 it is now possible to
> "hang" the site creation with a longer table like the one in this example.
> In case this sample is rendered using version 3.3 of the maven site
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MNG-6196) Updated Mockito, slf4j and logback dependences to latest versions
[ https://issues.apache.org/jira/browse/MNG-6196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz updated MNG-6196: -- Summary: Updated Mockito, slf4j and logback dependences to latest versions (was: Update dependences) > Updated Mockito, slf4j and logback dependences to latest versions > - > > Key: MNG-6196 > URL: https://issues.apache.org/jira/browse/MNG-6196 > Project: Maven > Issue Type: Improvement > Components: Dependencies >Affects Versions: 3.5.0-beta-1 >Reporter: Sylwester Lachiewicz >Priority: Minor > > Update dependences for maven build > Mocito 1.10 -> 2.7.19 > Slf4j 1.7.22 -> 1.7.25 (SLF4J-394) > logback-classic 1.2.2 > With slf4j update we can simplify maven-slf4j-provider implementation -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (DOXIA-554) Parsing time for Markdown documents can take very long and hang site generation
[
https://issues.apache.org/jira/browse/DOXIA-554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hervé Boutemy closed DOXIA-554.
---
Resolution: Fixed
Assignee: Hervé Boutemy
PR merged, with little updates: now, I'll do MSITE-791 to integrate the result
in m-site-p 3.7
thank you for your great work
> Parsing time for Markdown documents can take very long and hang site
> generation
> ---
>
> Key: DOXIA-554
> URL: https://issues.apache.org/jira/browse/DOXIA-554
> Project: Maven Doxia
> Issue Type: Bug
> Components: Module - Markdown
>Affects Versions: 1.7
>Reporter: Michael Benz
>Assignee: Hervé Boutemy
> Fix For: 1.8
>
> Attachments: maven-pom-sample-pegdown-performance.zip
>
>
> The parsing time for Markdown documents can take very long and hang site
> generation when e.g. long tables are being generated.
> The author of pegdown has marked the pegdown project deprecated since
> 2016-12-14 [pegdown.org|https://github.com/sirthias/pegdown/] and advises to
> switch to [flexmark-java|https://github.com/vsch/flexmark-java].
> {quote}
> The project is essentially unmaintained with tickets piling up and crucial
> bugs not being fixed.
> pegdown's parsing performance isn't great. In some cases of pathological
> input runtime can even become exponential, which means that the parser either
> appears to "hang" completely or abort processing after a time-out.
> {quote}
> Since the parsing timeout was increased in DOXIA-498 it is now possible to
> "hang" the site creation with a longer table like the one in this example.
> In case this sample is rendered using version 3.3 of the maven site
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (DOXIA-554) Parsing time for Markdown documents can take very long and hang site generation
[
https://issues.apache.org/jira/browse/DOXIA-554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15941977#comment-15941977
]
Vladimir Schneider commented on DOXIA-554:
--
Hervé, My pleasure and thank you for guiding this newbie through doxia
intricacies.
Let me know if any issues come up that need addressing.
> Parsing time for Markdown documents can take very long and hang site
> generation
> ---
>
> Key: DOXIA-554
> URL: https://issues.apache.org/jira/browse/DOXIA-554
> Project: Maven Doxia
> Issue Type: Bug
> Components: Module - Markdown
>Affects Versions: 1.7
>Reporter: Michael Benz
>Assignee: Hervé Boutemy
> Fix For: 1.8
>
> Attachments: maven-pom-sample-pegdown-performance.zip
>
>
> The parsing time for Markdown documents can take very long and hang site
> generation when e.g. long tables are being generated.
> The author of pegdown has marked the pegdown project deprecated since
> 2016-12-14 [pegdown.org|https://github.com/sirthias/pegdown/] and advises to
> switch to [flexmark-java|https://github.com/vsch/flexmark-java].
> {quote}
> The project is essentially unmaintained with tickets piling up and crucial
> bugs not being fixed.
> pegdown's parsing performance isn't great. In some cases of pathological
> input runtime can even become exponential, which means that the parser either
> appears to "hang" completely or abort processing after a time-out.
> {quote}
> Since the parsing timeout was increased in DOXIA-498 it is now possible to
> "hang" the site creation with a longer table like the one in this example.
> In case this sample is rendered using version 3.3 of the maven site
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (MNG-2893) Update the DefaultPluginManager to not use a project depMan for controlling it's transitive dependencies
[ https://issues.apache.org/jira/browse/MNG-2893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte reassigned MNG-2893: -- Assignee: Christian Schulte (was: Jason van Zyl) > Update the DefaultPluginManager to not use a project depMan for controlling > it's transitive dependencies > > > Key: MNG-2893 > URL: https://issues.apache.org/jira/browse/MNG-2893 > Project: Maven > Issue Type: Task > Components: Plugins and Lifecycle >Affects Versions: 2.0.5 >Reporter: Jason van Zyl >Assignee: Christian Schulte > Fix For: 3.2.x > > > An adjustment to MNG-1577. The classpath for plugins should not be affected > by a projects depMan. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MNG-2893) Update the DefaultPluginManager to not use a project depMan for controlling it's transitive dependencies
[ https://issues.apache.org/jira/browse/MNG-2893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte updated MNG-2893: --- Fix Version/s: 3.5.1-candidate > Update the DefaultPluginManager to not use a project depMan for controlling > it's transitive dependencies > > > Key: MNG-2893 > URL: https://issues.apache.org/jira/browse/MNG-2893 > Project: Maven > Issue Type: Task > Components: Plugins and Lifecycle >Affects Versions: 2.0.5 >Reporter: Jason van Zyl >Assignee: Christian Schulte > Fix For: 3.2.x, 3.5.1-candidate > > > An adjustment to MNG-1577. The classpath for plugins should not be affected > by a projects depMan. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MNG-5984) Maven core extension resolution ignores repositories from activeByDefault profiles in settings.xml
[
https://issues.apache.org/jira/browse/MNG-5984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schulte updated MNG-5984:
---
Fix Version/s: (was: needing-scrub-3.4.0-fallout)
3.5.1-candidate
> Maven core extension resolution ignores repositories from activeByDefault
> profiles in settings.xml
> --
>
> Key: MNG-5984
> URL: https://issues.apache.org/jira/browse/MNG-5984
> Project: Maven
> Issue Type: Bug
> Components: Profiles, Settings
>Affects Versions: 3.3.9
>Reporter: Gabriël Konat
>Assignee: Christian Schulte
>Priority: Minor
> Fix For: 3.5.1-candidate
>
>
> When building a project with a core extension in {{.mvn/extensions.xml}},
> where the core extension is not installed locally but needs to be retrieved
> from a remote repository, profiles from {{settings.xml}} with repositories
> which are {{true}}, are ignored, failing
> the resolution of the core extension.
> If the profile is activated from within an {{activeProfiles}} section, they
> are not ignored and resolution succeeds.
> Concrete example:
> {code:xml|title=.mvn/extensions.xml}
>
>
>
> org.metaborg
> spoofax-maven-plugin-pomless
> 2.0.0-SNAPSHOT
>
>
> {code}
> {code:xml|title=~/.m2/settings.xml}
>
>xmlns="http://maven.apache.org/SETTINGS/1.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
> http://maven.apache.org/xsd/settings-1.0.0.xsd";
> >
>
>
> add-metaborg-snapshot-repos
>
> true
>
>
>
> metaborg-snapshot-repo
>
> http://artifacts.metaborg.org/content/repositories/snapshots/
>
> false
>
>
> true
>
>
>
>
>
> metaborg-snapshot-repo
>
> http://artifacts.metaborg.org/content/repositories/snapshots/
>
> false
>
>
> true
>
>
>
>
>
>
> {code}
> Results in failed resolution:
> {code:title=mvn -Dmaven.repo.local=.cleanmvnrepo clean verify}
> [WARNING] The POM for
> org.metaborg:spoofax-maven-plugin-pomless:jar:2.0.0-SNAPSHOT is missing, no
> dependency information available
> [WARNING] Failed to read extensions descriptor
> /Users/gohla/spoofax/master/repo/spoofax-releng/sdf/org.metaborg.meta.lang.sdf/.mvn/extensions.xml:
> Plugin org.metaborg:spoofax-maven-plugin-pomless:2.0.0-SNAPSHOT or one of
> its dependencies could not be resolved: Could not find artifact
> org.metaborg:spoofax-maven-plugin-pomless:jar:2.0.0-SNAPSHOT
> {code}
> Whereas with the following settings file it succeeds to resolve the core
> extension:
> {code:xml|title=~/.m2/settings.xml}
>
>xmlns="http://maven.apache.org/SETTINGS/1.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
> http://maven.apache.org/xsd/settings-1.0.0.xsd";
> >
>
>
> add-metaborg-snapshot-repos
>
>
> metaborg-snapshot-repo
>
> http://artifacts.metaborg.org/content/repositories/snapshots/
>
> false
>
>
> true
>
>
>
>
>
> metaborg-snapshot-repo
>
> http://artifacts.metaborg.org/content/repositories/snapshots/
>
> false
>
>
> true
>
>
>
>
>
>
> add-metaborg-snapshot-repos
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MSITE-791) upgrade Doxia to 1.8 to benefit from new Markdown parser (require Java 7)
[ https://issues.apache.org/jira/browse/MSITE-791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15941981#comment-15941981 ] Hudson commented on MSITE-791: -- FAILURE: Integrated in Jenkins build maven-plugins #8900 (See [https://builds.apache.org/job/maven-plugins/8900/]) [MSITE-791] integrated DOxia 1.8 to benefit from new Markdown parser based on flexmark-java (requires Java 7) (hboutemy: [http://svn.apache.org/viewvc/?view=rev&rev=1788691]) * (edit) maven-site-plugin/pom.xml * (edit) maven-site-plugin/src/it/MSITE-159/pom.xml * (edit) maven-site-plugin/src/it/MSITE-265/pom.xml * (edit) maven-site-plugin/src/it/MSITE-458/pom.xml * (edit) maven-site-plugin/src/it/MSITE-497/pom.xml * (edit) maven-site-plugin/src/it/MSITE-566/pom.xml * (edit) maven-site-plugin/src/it/MSITE-582/pom.xml * (edit) maven-site-plugin/src/it/MSITE-609/pom.xml * (edit) maven-site-plugin/src/it/MSITE-658/pom.xml * (edit) maven-site-plugin/src/it/MSITE-723/pom.xml * (edit) maven-site-plugin/src/it/doxia-formats/pom.xml * (edit) maven-site-plugin/src/it/inheritance-interpolation/pom.xml * (edit) maven-site-plugin/src/it/inheritance-interpolation/repo-parent/pom.xml * (edit) maven-site-plugin/src/it/inheritedMenus/parentAsRef/pom.xml * (edit) maven-site-plugin/src/it/inheritedMenus/parentNotAsRef/pom.xml * (edit) maven-site-plugin/src/it/inheritedMenus/pom.xml * (edit) maven-site-plugin/src/it/it-plugin-test/pom.xml * (edit) maven-site-plugin/src/it/resources/pom.xml * (edit) maven-site-plugin/src/it/site-deploy/pom.xml * (edit) maven-site-plugin/src/it/site-inheritance/aggregator/pom.xml * (edit) maven-site-plugin/src/it/site-inheritance/module/pom.xml * (edit) maven-site-plugin/src/it/site-inheritance/parent/pom.xml * (edit) maven-site-plugin/src/it/site-inheritance/pom.xml * (edit) maven-site-plugin/src/it/site-jar/pom.xml * (edit) maven-site-plugin/src/it/site-sd-lang/pom.xml * (edit) maven-site-plugin/src/it/site-sd/pom.xml * (edit) maven-site-plugin/src/it/template-skin/pom.xml * (edit) maven-site-plugin/src/it/validate/pom.xml > upgrade Doxia to 1.8 to benefit from new Markdown parser (require Java 7) > - > > Key: MSITE-791 > URL: https://issues.apache.org/jira/browse/MSITE-791 > Project: Maven Site Plugin > Issue Type: Improvement >Affects Versions: 3.6 >Reporter: Hervé Boutemy > Fix For: 3.7 > > > see DOXIA-554 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MNG-6164) Collections inconsistently immutable.
[
https://issues.apache.org/jira/browse/MNG-6164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schulte updated MNG-6164:
---
Fix Version/s: 3.5.1-candidate
> Collections inconsistently immutable.
> -
>
> Key: MNG-6164
> URL: https://issues.apache.org/jira/browse/MNG-6164
> Project: Maven
> Issue Type: Bug
>Reporter: Christian Schulte
>Assignee: Christian Schulte
>Priority: Critical
> Fix For: 3.5.1-candidate
>
>
> There are plenty of places where empty collections are returned from public
> API methods like:
> {code}
> public List getExceptions()
> {
> return exceptions == null ? Collections. emptyList() :
> exceptions;
> }
> {code}
> The issue with this is that the empty list is immutable but the collection
> returned for the nun-null case is not immutable. All those methods should
> return an immutable collection consistently.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MNG-4347) import-scoped dependencies of direct dependencies are not resolved using profile modifications from settings.xml
[ https://issues.apache.org/jira/browse/MNG-4347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte updated MNG-4347: --- Fix Version/s: 3.5.1-candidate > import-scoped dependencies of direct dependencies are not resolved using > profile modifications from settings.xml > > > Key: MNG-4347 > URL: https://issues.apache.org/jira/browse/MNG-4347 > Project: Maven > Issue Type: Bug > Components: Artifacts and Repositories, Dependencies, General, > Profiles, Settings >Affects Versions: 2.2.1 >Reporter: John Casey >Assignee: John Casey >Priority: Critical > Fix For: 2.2.2, 3.5.1-candidate > > > Given: > * project A lists project B as a dependency > * project B lists project C as an import-scoped entry in dependencyManagement > * project B's dependency version for project C is a SNAPSHOT > * the user's settings.xml file modifies the definition of the central > repository to enable searching for SNAPSHOT artifacts. > When project A's dependency POMs are retrieved as part of collecting the > transitive dependency closure for A, B's project instance is built. During > this process, the POM for project C should be retrieved from central > (according to the modifications in settings.xml). However, the profile > information from the settings.xml is never applied to project B's POM, and > never modifies the central repository definition found there. Since the > default definition for the repository 'central' from the super POM has > snapshots disabled, project C's POM cannot be found, and the build fails. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MNG-5639) Support resolution of Import Scope POMs from Repo that contains a ${parameter}
[
https://issues.apache.org/jira/browse/MNG-5639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schulte updated MNG-5639:
---
Fix Version/s: 3.5.1-candidate
> Support resolution of Import Scope POMs from Repo that contains a ${parameter}
> --
>
> Key: MNG-5639
> URL: https://issues.apache.org/jira/browse/MNG-5639
> Project: Maven
> Issue Type: Improvement
> Components: Dependencies
>Affects Versions: 3.2.1
>Reporter: Mark Ingram
>Assignee: Jason van Zyl
>Priority: Minor
> Fix For: 3.2.2, 3.5.1-candidate
>
> Attachments: pom.xml
>
>
> Running mvn help:effective-pom on the attached POM:
> {noformat}[ERROR] The project
> com.ming:maven-failing-import-pom-example:1.0.0-SNAPSHOT
> (C:\wip\scratch-dev\maven-import-dependency-management\pom.xml) has 1 error
> [ERROR] Non-resolvable import POM: Could not transfer artifact
> org.springframework:spring-framework-bom:pom:4.0.0.R2 from/to
> spring-milestones (${spring.url}): No connector available to access
> repository spring-milestones (${spring.url}) of type default using the
> available factories WagonRepositoryConnectorFactory @ line 20, column 25 ->
> Help 2]{noformat}
> mvn help:effective-pom -Prepo-will-succeed works as expected.
> Note that prior to attempting the failing resolution, the full project POM
> model has successfully been resolved. So the correct value for the property
> is known and could in theory be substituted into the repository URL before
> the failing import pom resolve attempt.
> Will create a Github pull request with one possible solution to this - it
> includes a JUnit test case.
> Note: agreed this is a contrived example. To try and give an idea of the
> actual use case - several development streams are setup with individual
> sandboxed Nexus repository holding specific version of several shared
> components. The repository configuration uses the pattern
> $\{nexus.baseurl}/content/groups/$\{stream.name} with the properties set in
> settings.xml file.
> One workaround would be to create profiles for every work stream that
> explicitly list the full repository URL, even then the above feature would be
> nice to allow the $\{nexus.baseurl} to avoid repeating that part.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (MNG-6185) Replace doclettag explanation with annotations in AbstractMojo javadoc
[
https://issues.apache.org/jira/browse/MNG-6185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte reassigned MNG-6185:
---
Assignee: Robert Scholte
> Replace doclettag explanation with annotations in AbstractMojo javadoc
> --
>
> Key: MNG-6185
> URL: https://issues.apache.org/jira/browse/MNG-6185
> Project: Maven
> Issue Type: Improvement
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Minor
> Fix For: 3.5.0
>
>
> The javadoc of {{org.apache.maven.plugin.AbstractMojo}} still describes the
> usage of doclettags, which should be upgraded/rewritten to annotations.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (DOXIA-554) Parsing time for Markdown documents can take very long and hang site generation
[
https://issues.apache.org/jira/browse/DOXIA-554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15941999#comment-15941999
]
Hervé Boutemy commented on DOXIA-554:
-
Jira is the issues repository: you'll need to find an issue that you find
interest in
> Parsing time for Markdown documents can take very long and hang site
> generation
> ---
>
> Key: DOXIA-554
> URL: https://issues.apache.org/jira/browse/DOXIA-554
> Project: Maven Doxia
> Issue Type: Bug
> Components: Module - Markdown
>Affects Versions: 1.7
>Reporter: Michael Benz
>Assignee: Hervé Boutemy
> Fix For: 1.8
>
> Attachments: maven-pom-sample-pegdown-performance.zip
>
>
> The parsing time for Markdown documents can take very long and hang site
> generation when e.g. long tables are being generated.
> The author of pegdown has marked the pegdown project deprecated since
> 2016-12-14 [pegdown.org|https://github.com/sirthias/pegdown/] and advises to
> switch to [flexmark-java|https://github.com/vsch/flexmark-java].
> {quote}
> The project is essentially unmaintained with tickets piling up and crucial
> bugs not being fixed.
> pegdown's parsing performance isn't great. In some cases of pathological
> input runtime can even become exponential, which means that the parser either
> appears to "hang" completely or abort processing after a time-out.
> {quote}
> Since the parsing timeout was increased in DOXIA-498 it is now possible to
> "hang" the site creation with a longer table like the one in this example.
> In case this sample is rendered using version 3.3 of the maven site
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (MSITE-791) upgrade Doxia to 1.8 to benefit from new Markdown parser (require Java 7)
[ https://issues.apache.org/jira/browse/MSITE-791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hervé Boutemy resolved MSITE-791. - Resolution: Fixed Assignee: Hervé Boutemy > upgrade Doxia to 1.8 to benefit from new Markdown parser (require Java 7) > - > > Key: MSITE-791 > URL: https://issues.apache.org/jira/browse/MSITE-791 > Project: Maven Site Plugin > Issue Type: Improvement >Affects Versions: 3.6 >Reporter: Hervé Boutemy >Assignee: Hervé Boutemy > Fix For: 3.7 > > > see DOXIA-554 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (MDOAP-48) Upgrade of plexus-interpolation to 1.24.
[ https://issues.apache.org/jira/browse/MDOAP-48?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte reassigned MDOAP-48: -- Assignee: (was: Christian Schulte) > Upgrade of plexus-interpolation to 1.24. > > > Key: MDOAP-48 > URL: https://issues.apache.org/jira/browse/MDOAP-48 > Project: Maven DOAP Plugin > Issue Type: Task >Reporter: Christian Schulte >Priority: Trivial > Fix For: 3.0.0 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (MARCHETYPES-48) Upgrade archetyp-packaging extension to 3.4.
[ https://issues.apache.org/jira/browse/MARCHETYPES-48?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte reassigned MARCHETYPES-48: Assignee: (was: Christian Schulte) > Upgrade archetyp-packaging extension to 3.4. > > > Key: MARCHETYPES-48 > URL: https://issues.apache.org/jira/browse/MARCHETYPES-48 > Project: Maven Archetype Bundles > Issue Type: Task >Reporter: Christian Schulte >Priority: Trivial > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (MJAVADOC-462) Upgrade of doxia to 1.7 and doxia-sitetools to 1.7.1.
[ https://issues.apache.org/jira/browse/MJAVADOC-462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte reassigned MJAVADOC-462: -- Assignee: (was: Christian Schulte) > Upgrade of doxia to 1.7 and doxia-sitetools to 1.7.1. > - > > Key: MJAVADOC-462 > URL: https://issues.apache.org/jira/browse/MJAVADOC-462 > Project: Maven Javadoc Plugin > Issue Type: Task >Reporter: Christian Schulte >Priority: Trivial > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (MNG-2478) add "resources-filtered" filtered resource directories to super POM
[
https://issues.apache.org/jira/browse/MNG-2478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schulte reassigned MNG-2478:
--
Assignee: (was: Christian Schulte)
> add "resources-filtered" filtered resource directories to super POM
> ---
>
> Key: MNG-2478
> URL: https://issues.apache.org/jira/browse/MNG-2478
> Project: Maven
> Issue Type: New Feature
> Components: POM
>Affects Versions: 2.0.4
> Environment: any
>Reporter: Jörg Hohwiller
> Fix For: needing-scrub-3.4.0-fallout
>
>
> The super POM contains default folders for resources that are NOT filtered
> (src/main/resources and src/test/resources). If one (additionally) needs a
> filtered resources folder, it needs to override the default and therefore has
> to add all default folders if he does NOT want to "loose" the defaults.
> To make this easier my suggestion is to add filtered resource folders to the
> super POM. This should also fit to the philosophy of maven that aims to have
> defaults and only declare as little custom configuration as needed.
> My personal favorite for the foldernames would be "templates" but to make
> things more obvious to the user maybe "resources-filtered" would be better.
> Actually I do not care to much about the name...
> So the resources in the super POM should look like this:
> {code:xml}
>
> src/main/resources
>
>
>
> src/main/resources-filtered
> true
>
>
>
>
>
> src/test/resources
>
>
>
> src/test/resources-filtered
> true
>
>
> {code}
> Update: The folder name has been changed to "resources-filtered".
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (MNG-2893) Update the DefaultPluginManager to not use a project depMan for controlling it's transitive dependencies
[ https://issues.apache.org/jira/browse/MNG-2893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte reassigned MNG-2893: -- Assignee: (was: Christian Schulte) > Update the DefaultPluginManager to not use a project depMan for controlling > it's transitive dependencies > > > Key: MNG-2893 > URL: https://issues.apache.org/jira/browse/MNG-2893 > Project: Maven > Issue Type: Task > Components: Plugins and Lifecycle >Affects Versions: 2.0.5 >Reporter: Jason van Zyl > Fix For: 3.2.x, 3.5.1-candidate > > > An adjustment to MNG-1577. The classpath for plugins should not be affected > by a projects depMan. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (MNG-5222) Maven 3 no longer logs warnings about deprecated plugin parameters.
[ https://issues.apache.org/jira/browse/MNG-5222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte reassigned MNG-5222: -- Assignee: (was: Christian Schulte) > Maven 3 no longer logs warnings about deprecated plugin parameters. > --- > > Key: MNG-5222 > URL: https://issues.apache.org/jira/browse/MNG-5222 > Project: Maven > Issue Type: Wish > Components: Plugins and Lifecycle >Affects Versions: 3.0.3 >Reporter: Christian Schulte >Priority: Minor > > Providing a value for a deprecated plugin parameter, Maven 2.2.1 used to log > a warning. Currently Maven 3 does not. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (DOXIA-544) Set document tag on chapter header for FO format
[ https://issues.apache.org/jira/browse/DOXIA-544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15942003#comment-15942003 ] Hudson commented on DOXIA-544: -- SUCCESS: Integrated in Jenkins build doxia-all #330 (See [https://builds.apache.org/job/doxia-all/330/]) [DOXIA-544] set document tag on chapter header Submitted by: Blair Cooper (hboutemy: [http://svn.apache.org/viewvc/?view=rev&rev=1788693]) * (edit) ./doxia/doxia-modules/doxia-module-fo/src/main/java/org/apache/maven/doxia/module/fo/FoAggregateSink.java > Set document tag on chapter header for FO format > > > Key: DOXIA-544 > URL: https://issues.apache.org/jira/browse/DOXIA-544 > Project: Maven Doxia > Issue Type: Improvement > Components: Module - FO >Affects Versions: 1.7 >Reporter: Blair Cooper > Attachments: DoxiaFoPatch.txt > > > Currently the "id" tag is set on the block tag when starting the body. As a > result, if you're viewing the toc or bookmarks and you click on a chapter > title the document scrolls to the top of the body with the chapter title > scrolled off the top of the screen. > By setting the "id" on the block that starts the chapter heading the page > will scroll to a point where the chapter title is also visible. This provides > a better visual clue to the reader that they arrived at the desired location. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (MNG-5197) locally declared test dependency's first-generation transitive dependency version incorrectly overrides (n > 1)th-generation compile-scoped dependency version
[ https://issues.apache.org/jira/browse/MNG-5197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte reassigned MNG-5197: -- Assignee: (was: Christian Schulte) > locally declared test dependency's first-generation transitive dependency > version incorrectly overrides (n > 1)th-generation compile-scoped dependency > version > -- > > Key: MNG-5197 > URL: https://issues.apache.org/jira/browse/MNG-5197 > Project: Maven > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.2.1, 3.0.3 > Environment: OSX, Windows 7 >Reporter: Matt Benson > Fix For: needing-scrub-3.4.0-fallout > > Attachments: test-versions.tar.gz > > > This bug seems to relate to MNG-4457, MNG-4156, and potentially others, but I > have opened a new issue since nothing I found while searching could be > described in precisely the same way. > The test project I am attaching defines three modules: > thing1 > thing2 > thing3 > thing1 depends on hamcrest-core 1.2 > thing2 depends on thing1 and junit 4.10 > thing3 depends on thing2 and junit 4.10 > If you install these, you can then view the dependency trees for thing2 and > thing3 and see that thing1 correctly resolves v1.2 for hamcrest-core. > thing3, however, apparently overrides the version back to 1.1, apparently > accessed transitively via junit. > Thanks to Mark Struberg for his help in isolating this behavior! -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (DOXIA-504) Update to latest Plexus Container
[ https://issues.apache.org/jira/browse/DOXIA-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15942004#comment-15942004 ] Hudson commented on DOXIA-504: -- SUCCESS: Integrated in Jenkins build doxia-all #330 (See [https://builds.apache.org/job/doxia-all/330/]) [DOXIA-504] upgraded Plexus container to latest Submitted by: Mikolaj Izdebski (hboutemy: [http://svn.apache.org/viewvc/?view=rev&rev=1788692]) * (edit) ./doxia/doxia-core/src/test/java/org/apache/maven/doxia/module/AbstractIdentityTest.java * (edit) ./doxia/doxia-core/src/test/java/org/apache/maven/doxia/sink/impl/AbstractSinkTest.java * (edit) ./doxia/doxia-core/src/test/java/org/apache/maven/doxia/xsd/AbstractXmlValidator.java * (edit) ./doxia/pom.xml > Update to latest Plexus Container > - > > Key: DOXIA-504 > URL: https://issues.apache.org/jira/browse/DOXIA-504 > Project: Maven Doxia > Issue Type: Improvement > Components: Core >Reporter: Mikolaj Izdebski > Attachments: doxia-plexus-container.patch > > > Doxia is currently using old alpha version of Plexus. Please update to > latest stable Plexus Container. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (MNG-5708) Maven dependency resolution inconsistent with multiple excludes
[ https://issues.apache.org/jira/browse/MNG-5708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte reassigned MNG-5708: -- Assignee: (was: Christian Schulte) > Maven dependency resolution inconsistent with multiple excludes > --- > > Key: MNG-5708 > URL: https://issues.apache.org/jira/browse/MNG-5708 > Project: Maven > Issue Type: Bug > Components: Dependencies >Affects Versions: 3.2.3 > Environment: Apache Maven 3.2.3 > (33f8c3e1027c3ddde99d3cdebad2656a31e8fdf4; 2014-08-11T13:58:10-07:00) > Maven home: /home/henning/.apache-maven > Java version: 1.7.0_67, vendor: Oracle Corporation > Java home: /usr/lib/jvm/java-1.7.0-sun-1.7.0.67/jre > Default locale: en_US, platform encoding: UTF-8 > OS name: "linux", version: "3.16.6-200.fc20.x86_64", arch: "amd64", family: > "unix" >Reporter: Henning Schmiedehausen > Fix For: needing-scrub-3.4.0-fallout > > Attachments: dependency-bug-2.tar.gz, dependency-bug-3.tar.gz, > dependency-bug.tar.gz > > > This is how to reproduce the problem: > download and unpack the attached tarball. It contains three projects: > proj1 depends on log4j and commons-lang3 > proj2 is a multi module project which uses proj1. But it uses slf4j, so for > proj1 it has an exclusion in the dependency management section which excludes > log4j > module1 depends on proj1 and log4j-over-slf4j > module2 depends on proj1 > proj3 is a project that depends on module1. > enter each project one-by-one and do "mvn clean install". This works fine. So > dependency exclusion etc. works. > Now, remove the comments from the exclude block in proj2/module2/pom.xml > run "mvn clean install" in proj2. Everything still builds fine in proj2. > Same goes for "mvn clean install -pl :module2" (only build module2) and "mvn > clean install -rf :module2" (resume from module2) > now go to proj3. The build fails because there are duplicates on the > classpath. Looking at the dependency tree: > [INFO] group:proj3:jar:1-SNAPSHOT > [INFO] \- group:module1:jar:1-SNAPSHOT:compile > [INFO]+- group:proj1:jar:1-SNAPSHOT:compile > [INFO]| \- log4j:log4j:jar:1.2.7:compile > [INFO]\- org.slf4j:log4j-over-slf4j:jar:1.7.7:compile > [INFO] \- org.slf4j:slf4j-api:jar:1.7.7:compile > log4j (which was excluded in the dependencyManagement section) has reappeared! > This only happens if there are excludes in the depMgt section of a parent pom > *and* excludes in the dependency itself in a child project *and* the > dependency is referred from outside the multi module project. For an in-tree > project (such as module2), everything is fine. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (MNG-5359) Declared execution in PluginMgmt gets bound to lifecycle (regression)
[ https://issues.apache.org/jira/browse/MNG-5359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte reassigned MNG-5359: -- Assignee: (was: Christian Schulte) > Declared execution in PluginMgmt gets bound to lifecycle (regression) > - > > Key: MNG-5359 > URL: https://issues.apache.org/jira/browse/MNG-5359 > Project: Maven > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 3.0.1, 3.0.2, 3.0.3, 3.0.4 > Environment: Mac OS 10.7.5, Apple JDK 1.6.0_35 > (Same behavior seen on Windows XP with Sun JDK 1.6.0 as well) >Reporter: Anders Hammar > Fix For: 3.5.1-candidate > > Attachments: binding-test.zip, MNG-5359-IT.patch > > > If a plugin execution binding is declared in pluginManagement it gets bound > to the build lifecycle in Maven 3.0.x, but not with Maven 2.2.1. > My understanding is that the behavior in Maven 3.0 is wrong; an execution > binding needs to be declared in build/plugins/plugin to be bound. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (MNG-5939) Problem doing release when sources are generate as well
[ https://issues.apache.org/jira/browse/MNG-5939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte reassigned MNG-5939: -- Assignee: (was: Christian Schulte) > Problem doing release when sources are generate as well > --- > > Key: MNG-5939 > URL: https://issues.apache.org/jira/browse/MNG-5939 > Project: Maven > Issue Type: Bug >Affects Versions: 3.2.3 > Environment: Ubuntu 12.04.5 LTS > Apache Maven 3.2.1 (ea8b2b07643dbb1b84b6d16e1f08391b666bc1e9; > 2014-02-14T18:37:52+01:00) > Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; > 2015-11-10T17:41:47+01:00) > Java version: 1.7.0_76, vendor: Oracle Corporation >Reporter: chibbe > Fix For: needing-scrub-3.4.0-fallout > > Attachments: > 0001-MNG-5939-Addresses-duplicate-attached-artifact-probl.patch, foo.bar.zip > > > If I specified that sources should be generated with jar-no-fork goal > https://maven.apache.org/plugins/maven-source-plugin/jar-no-fork-mojo.html . > When doing a release with maven-release-plugin it will build the source again > when useReleaseProfile is true (use the release profile that adds sources and > javadocs to the released artifact > http://maven.apache.org/maven-release/maven-release-plugin/perform-mojo.html#useReleaseProfile). > The outcome is that it will run with both jar and jar-no-fork and generate > and deploy 2 -sources.jar artifacts, with same version. That makes the > release build fails. > > The same behavior could be reproduced when running both jar and jar-no-fork > goal between maven 3.2.1. and maven 3.3.9. > > Please find the logs for maven 3.2.1 and 3.3.9 in the foo.bar.zip > With maven 3.3.9 it uploads it 2 times : > Uploaded: > http://127.0.0.1:8081/nexus/content/repositories/releases/foo/bar/0.0.1/bar-0.0.1-sources.jar > (722 B at 15.3 KB/sec) > Uploading: > http://127.0.0.1:8081/nexus/content/repositories/releases/foo/bar/0.0.1/bar-0.0.1-sources.jar > 722/722 B -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (MNG-5940) Change the maven-source-plugin jar goal into jar-no-fork in Maven Super POM
[
https://issues.apache.org/jira/browse/MNG-5940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schulte reassigned MNG-5940:
--
Assignee: (was: Christian Schulte)
> Change the maven-source-plugin jar goal into jar-no-fork in Maven Super POM
> ---
>
> Key: MNG-5940
> URL: https://issues.apache.org/jira/browse/MNG-5940
> Project: Maven
> Issue Type: Improvement
> Components: core
>Reporter: Karl Heinz Marbaise
>Priority: Minor
> Fix For: needing-scrub-3.4.0-fallout
>
>
> At the moment the {{maven-source-plugin:jar}} goal is defined in the Maven
> super pom:
> {code:xml}
>
> true
> maven-source-plugin
>
>
> attach-sources
>
> jar
>
>
>
>
> {code}
> where the goal of {{maven-source-plugin}} should be changed from {{jar}} into
> {{jar-no-fork}}, cause most of the time you need to override this behaviour.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (MNG-5863) default pom's release-profile should invoke source plugin with goal "jar-no-fork" instead of "jar"
[ https://issues.apache.org/jira/browse/MNG-5863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte reassigned MNG-5863: -- Assignee: (was: Christian Schulte) > default pom's release-profile should invoke source plugin with goal > "jar-no-fork" instead of "jar" > -- > > Key: MNG-5863 > URL: https://issues.apache.org/jira/browse/MNG-5863 > Project: Maven > Issue Type: Bug > Components: POM >Affects Versions: 3.3.3 >Reporter: Petr Kozelka > Fix For: needing-scrub-3.4.0-fallout > > Original Estimate: 0.25h > Remaining Estimate: 0.25h > > in maven-model-builder, the file pom-4.0.0.xml defines "release-profile" > which binds some executions to the lifecycle. > One of them is source:jar - which forks the build. That can be a problem in > some configurations, and the forking is probably not necessary. > One situation where the forked build hurts is this: > - I have checkstyle:check attached to phase "validate" > - some of my modules generate code, obviously not compliant to the checkstyle > The problem is that, inside forked build, the checkstyle:check is called > again, but now it checks also the generated code (because target/ is no > longer empty). And of course fails. > Even worse: during normal development iterations, everything is fine. But > when I have to issue a release (usually under some pressure), I hit this > problem. > Fortunately, there _is_ a workaround: override the execution "attach-sources" > and assign it to a non-existing phase, and define execution with different id > for that. > But it is too ugly and I believe that the simple fix would solve it - for the > meantime before the whole profile is removed. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (MNG-6049) Add behavior to filter resolved version ranges of an artifact
[
https://issues.apache.org/jira/browse/MNG-6049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schulte reassigned MNG-6049:
--
Assignee: (was: Christian Schulte)
> Add behavior to filter resolved version ranges of an artifact
> -
>
> Key: MNG-6049
> URL: https://issues.apache.org/jira/browse/MNG-6049
> Project: Maven
> Issue Type: Improvement
> Components: core, Dependencies
>Reporter: Uwe Barthel
>Priority: Critical
> Fix For: 3.6.0-candidate
>
>
> The discussion on issue MNG-3092 shows the seriously needs of different kinds
> of version range resolving in Maven.
> This solution provides a hook for Maven extensions/plugins to change the list
> of resolved version range results as required.
> The {{DefaultVersionRangeResolver}} will be extended with a filter for
> version range results. A new interface {{VersionRangeResultFilter}} is added
> and a non-filtering {{DefaultVersionRangeResultFilter}}.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (MNG-5981) Plexus lifecycle could be activated too late during overlapping parallel requests
[
https://issues.apache.org/jira/browse/MNG-5981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schulte reassigned MNG-5981:
--
Assignee: (was: Christian Schulte)
> Plexus lifecycle could be activated too late during overlapping parallel
> requests
> -
>
> Key: MNG-5981
> URL: https://issues.apache.org/jira/browse/MNG-5981
> Project: Maven
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 3.3.1, 3.3.3, 3.3.9
>Reporter: Stuart McCulloch
> Fix For: needing-scrub-3.4.0-fallout
>
>
> A user reported seeing NPEs when running a particular project in parallel:
> http://www.mail-archive.com/users%40felix.apache.org/msg17072.html
> This was tracked down to the way we defer lifecycle activation for components
> (potentially) involved in dependency injection cycles (A->B->A). This bug is
> only triggered by specific lookup sequences when running parallel builds.
> The key fix was to move when we start cycle detection to the first scoped
> component in the lookup: https://bugs.eclipse.org/bugs/show_bug.cgi?id=487090
> (since a cycle can only ever involve scoped components - unscoped/per-lookup
> components can never repeat)
> The accuracy was also improved by using {{Scopes.isCircularProxy}} to spot
> when we inject a circular dependency proxy (which is when when we need to
> defer activation until the end of the cycle to allow that proxy to be
> populated). Previously the code was overly pessimistic when considering what
> might end up as a cycle.
> Sisu 0.3.3 contains both these fixes:
> https://wiki.eclipse.org/Sisu/Changelog#Release_0.3.3
> Previous releases can be patched by replacing the old org.eclipse.sisu.inject
> and org.eclipse.sisu.plexus jars with the ones from the 0.3.3 release.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (MNG-5992) Git passwords are exposed as the Super POM still uses Maven Release Plugin 2.3.2
[ https://issues.apache.org/jira/browse/MNG-5992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte reassigned MNG-5992: -- Assignee: (was: Christian Schulte) > Git passwords are exposed as the Super POM still uses Maven Release Plugin > 2.3.2 > > > Key: MNG-5992 > URL: https://issues.apache.org/jira/browse/MNG-5992 > Project: Maven > Issue Type: Improvement > Components: Bootstrap & Build, Plugins and Lifecycle, POM >Affects Versions: 3.3.3, 3.3.9 > Environment: All >Reporter: Ryan J. McDonough >Priority: Critical > Labels: security > Fix For: needing-scrub-3.4.0-fallout > > > The super POM defines version 2.3.2 of the Maven Release plugin. When using > HTTP/HTTPS Git SCM URIs, Maven will printout the password in the logs. Thus, > any CI system such as Jenkins, TravisCI, etc. will have the passwords exposed > in the logs and in the console output. In the case of TravisCI, this will be > publicly visible. > The [Maven Release Plugin fixed this issue in > MRELEASE-846|https://issues.apache.org/jira/browse/MRELEASE-846], but Maven > core is still pointing at an exposed version of the Maven Release plugin. I > have a test case that demonstrates the issue here: > https://github.com/damnhandy/maven-publish-issue > If you run the same build and explicitly define 2.5.3, the password is no > longer displayed. This should be the default. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (MNG-6054) Remove super POM plugin management section
[ https://issues.apache.org/jira/browse/MNG-6054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte reassigned MNG-6054: -- Assignee: (was: Christian Schulte) > Remove super POM plugin management section > -- > > Key: MNG-6054 > URL: https://issues.apache.org/jira/browse/MNG-6054 > Project: Maven > Issue Type: Task >Affects Versions: 3.3.9 >Reporter: Christian Schulte >Priority: Trivial > Fix For: needing-scrub-3.4.0-fallout > > > The super POM contains various plugins in the plugin management not part of > any default lifecycle. These should be removed from the super POM. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (MNG-6058) Test dependencies should override application dependencies only during testing.
[
https://issues.apache.org/jira/browse/MNG-6058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schulte reassigned MNG-6058:
--
Assignee: (was: Christian Schulte)
> Test dependencies should override application dependencies only during
> testing.
> ---
>
> Key: MNG-6058
> URL: https://issues.apache.org/jira/browse/MNG-6058
> Project: Maven
> Issue Type: Bug
>Reporter: Christian Schulte
> Attachments: MNG-6058.zip
>
>
> The following graph
> {code}
> POM
> |->a 2.0 compile
> |-->b 2.0 compile
> |->b 1.0 test
> {code}
> will be mediated to
> {code}
> POM
> |->a 2.0 compile
> |->b 1.0 test
> {code}
> The test dependency on b will make the transitive application dependency on b
> disappear. Maven should understand that the application dependency on b in
> version 2.0 is part of the application classpath and that the test
> dependency on b in version 1.0 is part of the test classpath only (overriding
> the application classpath). If someone adds a dependency on a project like
> that, the test dependency will disappear because the test scope is not
> transitive so that a "consuming" project gets a different application
> classpath than the project itself.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (MNG-6073) Addition of a core extension point to the model builder supporting model finalization.
[ https://issues.apache.org/jira/browse/MNG-6073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte closed MNG-6073. -- Resolution: Won't Fix Fix Version/s: (was: 3.6.0-candidate) > Addition of a core extension point to the model builder supporting model > finalization. > -- > > Key: MNG-6073 > URL: https://issues.apache.org/jira/browse/MNG-6073 > Project: Maven > Issue Type: New Feature >Reporter: Christian Schulte >Assignee: Christian Schulte >Priority: Trivial > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (MNG-6055) Move the release profile out of Maven's core so it can be more easily changed.
[ https://issues.apache.org/jira/browse/MNG-6055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte reassigned MNG-6055: -- Assignee: (was: Christian Schulte) > Move the release profile out of Maven's core so it can be more easily changed. > -- > > Key: MNG-6055 > URL: https://issues.apache.org/jira/browse/MNG-6055 > Project: Maven > Issue Type: Improvement >Reporter: Christian Schulte > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (MNG-6073) Addition of a core extension point to the model builder supporting model finalization.
[ https://issues.apache.org/jira/browse/MNG-6073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte reassigned MNG-6073: -- Assignee: (was: Christian Schulte) > Addition of a core extension point to the model builder supporting model > finalization. > -- > > Key: MNG-6073 > URL: https://issues.apache.org/jira/browse/MNG-6073 > Project: Maven > Issue Type: New Feature >Reporter: Christian Schulte >Priority: Trivial > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (MNG-6075) Increase the model validation level to the next minor level version.
[ https://issues.apache.org/jira/browse/MNG-6075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte closed MNG-6075. -- Resolution: Won't Fix Assignee: (was: Christian Schulte) Fix Version/s: (was: 3.6.0-candidate) > Increase the model validation level to the next minor level version. > > > Key: MNG-6075 > URL: https://issues.apache.org/jira/browse/MNG-6075 > Project: Maven > Issue Type: Task >Reporter: Christian Schulte >Priority: Critical > > Maven 3 has warned about various model related issues clearly stating that > not reacting to those warnings may break with a future Maven version. > Starting with Maven 3.4, the model validation level has been increased to the > next minor version so that such warnings will become errors as of 3.4. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (MNG-6079) 3.4 regression: cannot override version of a dependencyManagement in a submodule any more
[
https://issues.apache.org/jira/browse/MNG-6079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schulte reassigned MNG-6079:
--
Assignee: (was: Christian Schulte)
> 3.4 regression: cannot override version of a dependencyManagement in a
> submodule any more
> -
>
> Key: MNG-6079
> URL: https://issues.apache.org/jira/browse/MNG-6079
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: needing-scrub-3.4.0-fallout
>Reporter: Samuel Langlois
> Attachments: parent-pom.xml, pom.xml
>
>
> When you import a {{}} section from another pom, you
> can use a property for the version:
> {code}
>
>
>
> org.apache.maven.surefire
> surefire
> ${surefire.version}
> pom
> import
>
>
>
> {code}
> In Maven 3.3 and before, that version could be overridden in submodules, by
> overriding the property.
> In Maven 3.4, this doesn't work any more: redefining the property doesn't
> change the dependencies which are defined.
> I attach a simple example that uses surefire dependencies.
> {{mvn dependency:list}} will yield different results:
> * surefire-api:jar:2.12 with Maven 3.3, because this is the overridden
> version in the pom
> * surefire-api:jar:2.10 with Maven 3.4 (as of snapshot 2016-08-06), which is
> the version defined in the parent pom
> It is admittedly a corner case, or potentially a bug fix. In Maven 3.4, the
> behaviour of is now more consistent with the one of
> , where you can't redefine a dependency version simply by
> overriding a property.
> It is however a change in behaviour -- which broke my build.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (MNG-6079) 3.4 regression: cannot override version of a dependencyManagement in a submodule any more
[
https://issues.apache.org/jira/browse/MNG-6079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schulte closed MNG-6079.
--
Resolution: Not A Problem
Fix Version/s: (was: 3.6.0-candidate)
> 3.4 regression: cannot override version of a dependencyManagement in a
> submodule any more
> -
>
> Key: MNG-6079
> URL: https://issues.apache.org/jira/browse/MNG-6079
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: needing-scrub-3.4.0-fallout
>Reporter: Samuel Langlois
> Attachments: parent-pom.xml, pom.xml
>
>
> When you import a {{}} section from another pom, you
> can use a property for the version:
> {code}
>
>
>
> org.apache.maven.surefire
> surefire
> ${surefire.version}
> pom
> import
>
>
>
> {code}
> In Maven 3.3 and before, that version could be overridden in submodules, by
> overriding the property.
> In Maven 3.4, this doesn't work any more: redefining the property doesn't
> change the dependencies which are defined.
> I attach a simple example that uses surefire dependencies.
> {{mvn dependency:list}} will yield different results:
> * surefire-api:jar:2.12 with Maven 3.3, because this is the overridden
> version in the pom
> * surefire-api:jar:2.10 with Maven 3.4 (as of snapshot 2016-08-06), which is
> the version defined in the parent pom
> It is admittedly a corner case, or potentially a bug fix. In Maven 3.4, the
> behaviour of is now more consistent with the one of
> , where you can't redefine a dependency version simply by
> overriding a property.
> It is however a change in behaviour -- which broke my build.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (MNG-6114) Elements from the global settings should be ordered before elements from the user settings.
[ https://issues.apache.org/jira/browse/MNG-6114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte reassigned MNG-6114: -- Assignee: (was: Christian Schulte) > Elements from the global settings should be ordered before elements from the > user settings. > --- > > Key: MNG-6114 > URL: https://issues.apache.org/jira/browse/MNG-6114 > Project: Maven > Issue Type: Bug >Reporter: Christian Schulte > Fix For: 3.5.1-candidate > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (MNG-6127) Fix plugin execution configuration interference
[ https://issues.apache.org/jira/browse/MNG-6127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte reassigned MNG-6127: -- Assignee: (was: Christian Schulte) > Fix plugin execution configuration interference > --- > > Key: MNG-6127 > URL: https://issues.apache.org/jira/browse/MNG-6127 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 3.3.9 >Reporter: Mario Krizmanic > Fix For: needing-scrub-3.4.0-fallout > > > The plugin execution configuration may interfere across maven modules > included in a build in case a plugin extension provides a default > configuration. > Because the custom plugin configuration defined in the maven modules is > merged to the plugin execution configuration and the merged configuration is > re-used during building the other included maven modules, so the other maven > modules may be build using the invalid configuration. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (MPOM-140) Upgrade maven-assembly-plugin to 3.0.0.
[ https://issues.apache.org/jira/browse/MPOM-140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte closed MPOM-140. -- Resolution: Duplicate Assignee: (was: Christian Schulte) > Upgrade maven-assembly-plugin to 3.0.0. > --- > > Key: MPOM-140 > URL: https://issues.apache.org/jira/browse/MPOM-140 > Project: Maven POMs > Issue Type: Task >Reporter: Christian Schulte >Priority: Trivial > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (MNG-6184) Maven dependency StackOverflowException
[ https://issues.apache.org/jira/browse/MNG-6184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte reassigned MNG-6184: -- Assignee: (was: Christian Schulte) > Maven dependency StackOverflowException > --- > > Key: MNG-6184 > URL: https://issues.apache.org/jira/browse/MNG-6184 > Project: Maven > Issue Type: Bug >Affects Versions: 3.5.0-alpha-1 >Reporter: Jon Harper > > See the last comments in MNG-5592 asking to reopen the issue. See the > attached file MNG-5592_testcase.zip -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (MNG-6141) Dependency management overrides are not transitive and should be considered an anti-pattern.
[ https://issues.apache.org/jira/browse/MNG-6141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte reassigned MNG-6141: -- Assignee: (was: Christian Schulte) > Dependency management overrides are not transitive and should be considered > an anti-pattern. > > > Key: MNG-6141 > URL: https://issues.apache.org/jira/browse/MNG-6141 > Project: Maven > Issue Type: Bug >Reporter: Christian Schulte >Priority: Critical > Attachments: MNG-6141.zip > > > Overriding the dependency management in a module, the overridden value will > not be preserved transitively. It makes no sense to be able to override the > dependency management in a module if that is only effective in that module > and nowhere else. Overriding the dependency management should be considered > an anti-pattern. Maven should provide a warning when it is used. During the > development of Maven 3.4, there have been quite a few discussions on dev@ > about build issues which were all caused by overriding the dependency > management without noticing this is not supported transitively. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (MPOM-143) Upgrade maven-dependency-plugin to 3.0.0.
[ https://issues.apache.org/jira/browse/MPOM-143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte closed MPOM-143. -- Resolution: Won't Fix Assignee: (was: Christian Schulte) Fix Version/s: (was: ASF-19) > Upgrade maven-dependency-plugin to 3.0.0. > - > > Key: MPOM-143 > URL: https://issues.apache.org/jira/browse/MPOM-143 > Project: Maven POMs > Issue Type: Task >Reporter: Christian Schulte >Priority: Trivial > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (MSHARED-599) Escaping the escape string produces incorrect output.
[ https://issues.apache.org/jira/browse/MSHARED-599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte reassigned MSHARED-599: - Assignee: (was: Christian Schulte) > Escaping the escape string produces incorrect output. > - > > Key: MSHARED-599 > URL: https://issues.apache.org/jira/browse/MSHARED-599 > Project: Maven Shared Components > Issue Type: Bug > Components: maven-filtering >Affects Versions: maven-filtering-3.1.1 >Reporter: Christian Schulte > Fix For: maven-filtering-3.1.2 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (MPOM-145) Upgrade maven-plugin-plugin to 3.5.
[ https://issues.apache.org/jira/browse/MPOM-145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte closed MPOM-145. -- Resolution: Won't Fix Assignee: (was: Christian Schulte) Fix Version/s: (was: ASF-19) > Upgrade maven-plugin-plugin to 3.5. > --- > > Key: MPOM-145 > URL: https://issues.apache.org/jira/browse/MPOM-145 > Project: Maven POMs > Issue Type: Task >Reporter: Christian Schulte >Priority: Trivial > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (MSHARED-603) Upgrade maven-shared-resources to 2.
[ https://issues.apache.org/jira/browse/MSHARED-603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte reassigned MSHARED-603: - Assignee: (was: Christian Schulte) > Upgrade maven-shared-resources to 2. > > > Key: MSHARED-603 > URL: https://issues.apache.org/jira/browse/MSHARED-603 > Project: Maven Shared Components > Issue Type: Task >Reporter: Christian Schulte >Priority: Trivial > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (MSHARED-626) Upgrade of 'maven-shared-utils' to 3.2.0.
[ https://issues.apache.org/jira/browse/MSHARED-626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte reassigned MSHARED-626: - Assignee: (was: Christian Schulte) > Upgrade of 'maven-shared-utils' to 3.2.0. > - > > Key: MSHARED-626 > URL: https://issues.apache.org/jira/browse/MSHARED-626 > Project: Maven Shared Components > Issue Type: Task > Components: maven-jarsigner >Reporter: Christian Schulte >Priority: Trivial > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (MSHARED-625) Refactored to use 'maven-shared-utils' instead of 'plexus-utils'.
[ https://issues.apache.org/jira/browse/MSHARED-625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte reassigned MSHARED-625: - Assignee: (was: Christian Schulte) > Refactored to use 'maven-shared-utils' instead of 'plexus-utils'. > -- > > Key: MSHARED-625 > URL: https://issues.apache.org/jira/browse/MSHARED-625 > Project: Maven Shared Components > Issue Type: Task > Components: maven-invoker >Reporter: Christian Schulte >Priority: Trivial > Fix For: maven-jarsigner-3.0.0 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (MSHARED-624) Upgrade of maven-shared-utils to 3.2.0.
[ https://issues.apache.org/jira/browse/MSHARED-624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte reassigned MSHARED-624: - Assignee: (was: Christian Schulte) > Upgrade of maven-shared-utils to 3.2.0. > --- > > Key: MSHARED-624 > URL: https://issues.apache.org/jira/browse/MSHARED-624 > Project: Maven Shared Components > Issue Type: Task > Components: maven-verifier >Reporter: Christian Schulte >Priority: Trivial > Fix For: maven-verifier-1.7 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MNG-2893) Update the DefaultPluginManager to not use a project depMan for controlling it's transitive dependencies
[ https://issues.apache.org/jira/browse/MNG-2893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15942012#comment-15942012 ] Christian Schulte commented on MNG-2893: Issue is fixed in the master branch of [my private maven repository on github|https://github.com/ChristianSchulte/maven/tree/master]. When interested, you can cherry pick the commit to your own repository and create a pull request for the apache master branch with just this commit yourself from there. > Update the DefaultPluginManager to not use a project depMan for controlling > it's transitive dependencies > > > Key: MNG-2893 > URL: https://issues.apache.org/jira/browse/MNG-2893 > Project: Maven > Issue Type: Task > Components: Plugins and Lifecycle >Affects Versions: 2.0.5 >Reporter: Jason van Zyl > Fix For: 3.2.x, 3.5.1-candidate > > > An adjustment to MNG-1577. The classpath for plugins should not be affected > by a projects depMan. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MNG-5359) Declared execution in PluginMgmt gets bound to lifecycle (regression)
[ https://issues.apache.org/jira/browse/MNG-5359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15942016#comment-15942016 ] Christian Schulte commented on MNG-5359: Issue is fixed in the master branch of [my private maven repository on github|https://github.com/ChristianSchulte/maven/tree/master]. When interested, you can cherry pick the commit to your own repository and create a pull request for the apache master branch with just this commit yourself from there. > Declared execution in PluginMgmt gets bound to lifecycle (regression) > - > > Key: MNG-5359 > URL: https://issues.apache.org/jira/browse/MNG-5359 > Project: Maven > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 3.0.1, 3.0.2, 3.0.3, 3.0.4 > Environment: Mac OS 10.7.5, Apple JDK 1.6.0_35 > (Same behavior seen on Windows XP with Sun JDK 1.6.0 as well) >Reporter: Anders Hammar > Fix For: 3.5.1-candidate > > Attachments: binding-test.zip, MNG-5359-IT.patch > > > If a plugin execution binding is declared in pluginManagement it gets bound > to the build lifecycle in Maven 3.0.x, but not with Maven 2.2.1. > My understanding is that the behavior in Maven 3.0 is wrong; an execution > binding needs to be declared in build/plugins/plugin to be bound. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MNG-5984) Maven core extension resolution ignores repositories from activeByDefault profiles in settings.xml
[
https://issues.apache.org/jira/browse/MNG-5984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15942018#comment-15942018
]
Christian Schulte commented on MNG-5984:
Issue is fixed in the master branch of [my private maven repository on
github|https://github.com/ChristianSchulte/maven/tree/master]. When interested,
you can cherry pick the commit to your own repository and create a pull request
for the apache master branch with just this commit yourself from there.
> Maven core extension resolution ignores repositories from activeByDefault
> profiles in settings.xml
> --
>
> Key: MNG-5984
> URL: https://issues.apache.org/jira/browse/MNG-5984
> Project: Maven
> Issue Type: Bug
> Components: Profiles, Settings
>Affects Versions: 3.3.9
>Reporter: Gabriël Konat
>Priority: Minor
> Fix For: 3.5.1-candidate
>
>
> When building a project with a core extension in {{.mvn/extensions.xml}},
> where the core extension is not installed locally but needs to be retrieved
> from a remote repository, profiles from {{settings.xml}} with repositories
> which are {{true}}, are ignored, failing
> the resolution of the core extension.
> If the profile is activated from within an {{activeProfiles}} section, they
> are not ignored and resolution succeeds.
> Concrete example:
> {code:xml|title=.mvn/extensions.xml}
>
>
>
> org.metaborg
> spoofax-maven-plugin-pomless
> 2.0.0-SNAPSHOT
>
>
> {code}
> {code:xml|title=~/.m2/settings.xml}
>
>xmlns="http://maven.apache.org/SETTINGS/1.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
> http://maven.apache.org/xsd/settings-1.0.0.xsd";
> >
>
>
> add-metaborg-snapshot-repos
>
> true
>
>
>
> metaborg-snapshot-repo
>
> http://artifacts.metaborg.org/content/repositories/snapshots/
>
> false
>
>
> true
>
>
>
>
>
> metaborg-snapshot-repo
>
> http://artifacts.metaborg.org/content/repositories/snapshots/
>
> false
>
>
> true
>
>
>
>
>
>
> {code}
> Results in failed resolution:
> {code:title=mvn -Dmaven.repo.local=.cleanmvnrepo clean verify}
> [WARNING] The POM for
> org.metaborg:spoofax-maven-plugin-pomless:jar:2.0.0-SNAPSHOT is missing, no
> dependency information available
> [WARNING] Failed to read extensions descriptor
> /Users/gohla/spoofax/master/repo/spoofax-releng/sdf/org.metaborg.meta.lang.sdf/.mvn/extensions.xml:
> Plugin org.metaborg:spoofax-maven-plugin-pomless:2.0.0-SNAPSHOT or one of
> its dependencies could not be resolved: Could not find artifact
> org.metaborg:spoofax-maven-plugin-pomless:jar:2.0.0-SNAPSHOT
> {code}
> Whereas with the following settings file it succeeds to resolve the core
> extension:
> {code:xml|title=~/.m2/settings.xml}
>
>xmlns="http://maven.apache.org/SETTINGS/1.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
> http://maven.apache.org/xsd/settings-1.0.0.xsd";
> >
>
>
> add-metaborg-snapshot-repos
>
>
> metaborg-snapshot-repo
>
> http://artifacts.metaborg.org/content/repositories/snapshots/
>
> false
>
>
> true
>
>
>
>
>
> metaborg-snapshot-repo
>
> http://artifacts.metaborg.org/content/repositories/snapshots/
>
> false
>
>
> true
>
>
>
>
>
>
> add-metaborg-snapshot-repos
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (MNG-5984) Maven core extension resolution ignores repositories from activeByDefault profiles in settings.xml
[
https://issues.apache.org/jira/browse/MNG-5984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schulte reassigned MNG-5984:
--
Assignee: (was: Christian Schulte)
> Maven core extension resolution ignores repositories from activeByDefault
> profiles in settings.xml
> --
>
> Key: MNG-5984
> URL: https://issues.apache.org/jira/browse/MNG-5984
> Project: Maven
> Issue Type: Bug
> Components: Profiles, Settings
>Affects Versions: 3.3.9
>Reporter: Gabriël Konat
>Priority: Minor
> Fix For: 3.5.1-candidate
>
>
> When building a project with a core extension in {{.mvn/extensions.xml}},
> where the core extension is not installed locally but needs to be retrieved
> from a remote repository, profiles from {{settings.xml}} with repositories
> which are {{true}}, are ignored, failing
> the resolution of the core extension.
> If the profile is activated from within an {{activeProfiles}} section, they
> are not ignored and resolution succeeds.
> Concrete example:
> {code:xml|title=.mvn/extensions.xml}
>
>
>
> org.metaborg
> spoofax-maven-plugin-pomless
> 2.0.0-SNAPSHOT
>
>
> {code}
> {code:xml|title=~/.m2/settings.xml}
>
>xmlns="http://maven.apache.org/SETTINGS/1.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
> http://maven.apache.org/xsd/settings-1.0.0.xsd";
> >
>
>
> add-metaborg-snapshot-repos
>
> true
>
>
>
> metaborg-snapshot-repo
>
> http://artifacts.metaborg.org/content/repositories/snapshots/
>
> false
>
>
> true
>
>
>
>
>
> metaborg-snapshot-repo
>
> http://artifacts.metaborg.org/content/repositories/snapshots/
>
> false
>
>
> true
>
>
>
>
>
>
> {code}
> Results in failed resolution:
> {code:title=mvn -Dmaven.repo.local=.cleanmvnrepo clean verify}
> [WARNING] The POM for
> org.metaborg:spoofax-maven-plugin-pomless:jar:2.0.0-SNAPSHOT is missing, no
> dependency information available
> [WARNING] Failed to read extensions descriptor
> /Users/gohla/spoofax/master/repo/spoofax-releng/sdf/org.metaborg.meta.lang.sdf/.mvn/extensions.xml:
> Plugin org.metaborg:spoofax-maven-plugin-pomless:2.0.0-SNAPSHOT or one of
> its dependencies could not be resolved: Could not find artifact
> org.metaborg:spoofax-maven-plugin-pomless:jar:2.0.0-SNAPSHOT
> {code}
> Whereas with the following settings file it succeeds to resolve the core
> extension:
> {code:xml|title=~/.m2/settings.xml}
>
>xmlns="http://maven.apache.org/SETTINGS/1.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
> http://maven.apache.org/xsd/settings-1.0.0.xsd";
> >
>
>
> add-metaborg-snapshot-repos
>
>
> metaborg-snapshot-repo
>
> http://artifacts.metaborg.org/content/repositories/snapshots/
>
> false
>
>
> true
>
>
>
>
>
> metaborg-snapshot-repo
>
> http://artifacts.metaborg.org/content/repositories/snapshots/
>
> false
>
>
> true
>
>
>
>
>
>
> add-metaborg-snapshot-repos
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (MNG-6164) Collections inconsistently immutable.
[
https://issues.apache.org/jira/browse/MNG-6164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schulte reassigned MNG-6164:
--
Assignee: (was: Christian Schulte)
> Collections inconsistently immutable.
> -
>
> Key: MNG-6164
> URL: https://issues.apache.org/jira/browse/MNG-6164
> Project: Maven
> Issue Type: Bug
>Reporter: Christian Schulte
>Priority: Critical
> Fix For: 3.5.1-candidate
>
>
> There are plenty of places where empty collections are returned from public
> API methods like:
> {code}
> public List getExceptions()
> {
> return exceptions == null ? Collections. emptyList() :
> exceptions;
> }
> {code}
> The issue with this is that the empty list is immutable but the collection
> returned for the nun-null case is not immutable. All those methods should
> return an immutable collection consistently.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MNG-6164) Collections inconsistently immutable.
[
https://issues.apache.org/jira/browse/MNG-6164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15942021#comment-15942021
]
Christian Schulte commented on MNG-6164:
Issue is fixed in the master branch of [my private maven repository on
github|https://github.com/ChristianSchulte/maven/tree/master]. When interested,
you can cherry pick the commit to your own repository and create a pull request
for the apache master branch with just this commit yourself from there.
> Collections inconsistently immutable.
> -
>
> Key: MNG-6164
> URL: https://issues.apache.org/jira/browse/MNG-6164
> Project: Maven
> Issue Type: Bug
>Reporter: Christian Schulte
>Priority: Critical
> Fix For: 3.5.1-candidate
>
>
> There are plenty of places where empty collections are returned from public
> API methods like:
> {code}
> public List getExceptions()
> {
> return exceptions == null ? Collections. emptyList() :
> exceptions;
> }
> {code}
> The issue with this is that the empty list is immutable but the collection
> returned for the nun-null case is not immutable. All those methods should
> return an immutable collection consistently.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MNG-6114) Elements from the global settings should be ordered before elements from the user settings.
[ https://issues.apache.org/jira/browse/MNG-6114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15942019#comment-15942019 ] Christian Schulte commented on MNG-6114: Issue is fixed in the master branch of [my private maven repository on github|https://github.com/ChristianSchulte/maven/tree/master]. When interested, you can cherry pick the commit to your own repository and create a pull request for the apache master branch with just this commit yourself from there. > Elements from the global settings should be ordered before elements from the > user settings. > --- > > Key: MNG-6114 > URL: https://issues.apache.org/jira/browse/MNG-6114 > Project: Maven > Issue Type: Bug >Reporter: Christian Schulte > Fix For: 3.5.1-candidate > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (MNG-5600) Dependency management import should support exclusions.
[
https://issues.apache.org/jira/browse/MNG-5600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schulte reassigned MNG-5600:
--
Assignee: (was: Christian Schulte)
> Dependency management import should support exclusions.
> ---
>
> Key: MNG-5600
> URL: https://issues.apache.org/jira/browse/MNG-5600
> Project: Maven
> Issue Type: Improvement
> Components: Dependencies
>Reporter: Radai Rosenblatt
> Fix For: 3.5.1-candidate
>
>
> suppose i have a multi-module project that uses spring, and so have this in
> dependency-managements in a parent pom:
> {code:xml}
>
> org.springframework
> spring-framework-bom
> ${org.springframework.version}
> pom
> import
>
> {code}
> spring artifacts (or at least a lot of them) have a dependency on
> commons-logging. right now, if i want to exclude commons-logging i have to
> add an exclusion to every spring dependency in every module of my project,
> which is actually more XML overall than giving up on using the bom dependency
> altogether and listing all spring dependencies with excludes once in the
> parent dependency management.
> I'd like to be able to do this:
> {code:xml}
>
> org.springframework
> spring-framework-bom
> ${org.springframework.version}
> pom
> import
>
>
> commons-logging
> commons-logging
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (MNG-5527) Dependency management import should support relocations.
[
https://issues.apache.org/jira/browse/MNG-5527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schulte reassigned MNG-5527:
--
Assignee: (was: Christian Schulte)
> Dependency management import should support relocations.
>
>
> Key: MNG-5527
> URL: https://issues.apache.org/jira/browse/MNG-5527
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
> Environment: maven-3.1.0
> Fedora 18 x86_64
>Reporter: Matous Jobanek
> Fix For: 3.5.1-candidate
>
>
> Consider the following scenario:
> {code:xml}
>
> 4.0.0
> old.groupId.bom
> my-artifactId-bom
> 1.0
> pom
>
>
> new.groupId.bom
> my-artifactId-bom
> 2.0
>
>
>
> {code}
> {code:xml}
>
> 4.0.0
> my.project.groupId
> my-project
> 1.0
> war
>
>
>
> old.groupId.bom
> my-artifactId-bom
> 1.0
> pom
> import
>
>
>
> ...
>
> {code}
> The expected result according to [1]:
> During building the "my-project" it should print the WARNING with the
> information about the relocation and it should be automatically redirected
> from old.groupId.bom:my-artifactId-bom:1.0 to
> new.groupId.bom:my-artifactId-bom:2.0 and use dependencies from the new pom.
> Actual results:
> There is no WARNING and no redirection to the new pom and maven is trying to
> obtain dependencies from the old pom (old.groupId.bom:my-artifactId-bom:1.0).
>
> Nevertheless, when the pom is declared as a "normal dependency" (not in the
> "dependencyManagement" part) it works without any problem - it prints the
> WARNING and redirects to the new pom, but this is not the case we are using.
> [1] http://maven.apache.org/guides/mini/guide-relocation.html
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MNG-5527) Dependency management import should support relocations.
[
https://issues.apache.org/jira/browse/MNG-5527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15942024#comment-15942024
]
Christian Schulte commented on MNG-5527:
Issue is fixed in the master branch of [my private maven repository on
github|https://github.com/ChristianSchulte/maven/tree/master]. When interested,
you can cherry pick the commit to your own repository and create a pull request
for the apache master branch with just this commit yourself from there.
> Dependency management import should support relocations.
>
>
> Key: MNG-5527
> URL: https://issues.apache.org/jira/browse/MNG-5527
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
> Environment: maven-3.1.0
> Fedora 18 x86_64
>Reporter: Matous Jobanek
> Fix For: 3.5.1-candidate
>
>
> Consider the following scenario:
> {code:xml}
>
> 4.0.0
> old.groupId.bom
> my-artifactId-bom
> 1.0
> pom
>
>
> new.groupId.bom
> my-artifactId-bom
> 2.0
>
>
>
> {code}
> {code:xml}
>
> 4.0.0
> my.project.groupId
> my-project
> 1.0
> war
>
>
>
> old.groupId.bom
> my-artifactId-bom
> 1.0
> pom
> import
>
>
>
> ...
>
> {code}
> The expected result according to [1]:
> During building the "my-project" it should print the WARNING with the
> information about the relocation and it should be automatically redirected
> from old.groupId.bom:my-artifactId-bom:1.0 to
> new.groupId.bom:my-artifactId-bom:2.0 and use dependencies from the new pom.
> Actual results:
> There is no WARNING and no redirection to the new pom and maven is trying to
> obtain dependencies from the old pom (old.groupId.bom:my-artifactId-bom:1.0).
>
> Nevertheless, when the pom is declared as a "normal dependency" (not in the
> "dependencyManagement" part) it works without any problem - it prints the
> WARNING and redirects to the new pom, but this is not the case we are using.
> [1] http://maven.apache.org/guides/mini/guide-relocation.html
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MNG-5600) Dependency management import should support exclusions.
[
https://issues.apache.org/jira/browse/MNG-5600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15942025#comment-15942025
]
Christian Schulte commented on MNG-5600:
Issue is fixed in the master branch of [my private maven repository on
github|https://github.com/ChristianSchulte/maven/tree/master]. When interested,
you can cherry pick the commit to your own repository and create a pull request
for the apache master branch with just this commit yourself from there.
> Dependency management import should support exclusions.
> ---
>
> Key: MNG-5600
> URL: https://issues.apache.org/jira/browse/MNG-5600
> Project: Maven
> Issue Type: Improvement
> Components: Dependencies
>Reporter: Radai Rosenblatt
> Fix For: 3.5.1-candidate
>
>
> suppose i have a multi-module project that uses spring, and so have this in
> dependency-managements in a parent pom:
> {code:xml}
>
> org.springframework
> spring-framework-bom
> ${org.springframework.version}
> pom
> import
>
> {code}
> spring artifacts (or at least a lot of them) have a dependency on
> commons-logging. right now, if i want to exclude commons-logging i have to
> add an exclusion to every spring dependency in every module of my project,
> which is actually more XML overall than giving up on using the bom dependency
> altogether and listing all spring dependencies with excludes once in the
> parent dependency management.
> I'd like to be able to do this:
> {code:xml}
>
> org.springframework
> spring-framework-bom
> ${org.springframework.version}
> pom
> import
>
>
> commons-logging
> commons-logging
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MNG-5971) Imported dependencies should be available to inheritance processing
[
https://issues.apache.org/jira/browse/MNG-5971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15942026#comment-15942026
]
Christian Schulte commented on MNG-5971:
Issue is fixed in the master branch of [my private maven repository on
github|https://github.com/ChristianSchulte/maven/tree/master]. When interested,
you can cherry pick the commit to your own repository and create a pull request
for the apache master branch with just this commit yourself from there.
> Imported dependencies should be available to inheritance processing
> ---
>
> Key: MNG-5971
> URL: https://issues.apache.org/jira/browse/MNG-5971
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.3.3
>Reporter: Stephane Nicoll
>Priority: Trivial
> Fix For: 3.6.0-candidate
>
> Attachments: bom-cloud.zip
>
>
> When a project extends from a parent with a {{dependencyManagement}} section,
> it is not always possible to properly override (and align) the version to use
> for a group of dependencies.
> We typically use Bill Of Materials to gather a group of modules and make sure
> their versions are consistent.
> The following project demonstrates the issue:
> https://github.com/snicoll-scratches/maven-dependency-management
> The first commit is a working use case where the parent uses a bom with
> version A and we use the same bom with version B in the child. Version B is
> used as expected.
> The second commit demonstrates the faulty scenario. Rather than using a bom
> in the parent, we use a direct dependency (provided by that bom). We still
> use the bom with a different version. In that case all the dependencies but
> the one provided by the parent are overridden (leading to mixed versions for
> the dependencies provided by the BOM).
> It looks like the distance is still used to compute the version while the
> graph of dependencies should be flatten at each step for a proper override.
> Thoughts? Thanks!
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (MNG-5227) The 'optional' flag of a dependency should be manageable.
[
https://issues.apache.org/jira/browse/MNG-5227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schulte reassigned MNG-5227:
--
Assignee: (was: Christian Schulte)
> The 'optional' flag of a dependency should be manageable.
> -
>
> Key: MNG-5227
> URL: https://issues.apache.org/jira/browse/MNG-5227
> Project: Maven
> Issue Type: New Feature
> Components: Artifacts and Repositories
>Affects Versions: 3.0.3
>Reporter: Christian Schulte
>Priority: Minor
> Fix For: 3.6.0-candidate
>
> Attachments: MNG-5227.patch, MNG-5227.patch
>
>
> {code}
>
>
>
> groupId
> artifactId
> version
> false
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (MNG-5971) Imported dependencies should be available to inheritance processing
[
https://issues.apache.org/jira/browse/MNG-5971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schulte reassigned MNG-5971:
--
Assignee: (was: Christian Schulte)
> Imported dependencies should be available to inheritance processing
> ---
>
> Key: MNG-5971
> URL: https://issues.apache.org/jira/browse/MNG-5971
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.3.3
>Reporter: Stephane Nicoll
>Priority: Trivial
> Fix For: 3.6.0-candidate
>
> Attachments: bom-cloud.zip
>
>
> When a project extends from a parent with a {{dependencyManagement}} section,
> it is not always possible to properly override (and align) the version to use
> for a group of dependencies.
> We typically use Bill Of Materials to gather a group of modules and make sure
> their versions are consistent.
> The following project demonstrates the issue:
> https://github.com/snicoll-scratches/maven-dependency-management
> The first commit is a working use case where the parent uses a bom with
> version A and we use the same bom with version B in the child. Version B is
> used as expected.
> The second commit demonstrates the faulty scenario. Rather than using a bom
> in the parent, we use a direct dependency (provided by that bom). We still
> use the bom with a different version. In that case all the dependencies but
> the one provided by the parent are overridden (leading to mixed versions for
> the dependencies provided by the BOM).
> It looks like the distance is still used to compute the version while the
> graph of dependencies should be flatten at each step for a proper override.
> Thoughts? Thanks!
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (MNG-5935) Optional true getting lost in managed dependencies when transitive
[ https://issues.apache.org/jira/browse/MNG-5935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte reassigned MNG-5935: -- Assignee: (was: Christian Schulte) > Optional true getting lost in managed dependencies when transitive > -- > > Key: MNG-5935 > URL: https://issues.apache.org/jira/browse/MNG-5935 > Project: Maven > Issue Type: Bug > Components: Dependencies >Affects Versions: 3.3.9 > Environment: Apache Maven 3.3.9 > (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T17:41:47+01:00) > Maven home: C:\Temp\apache-maven-3.3.9 > Java version: 1.8.0_66, vendor: Oracle Corporation > Java home: C:\Prog\Java\v8_66\jre > Default locale: nl_NL, platform encoding: Cp1252 > OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos" >Reporter: Marcel Schutte > Fix For: 3.6.0-candidate > > Attachments: buildoutput.txt, Parent.zip > > > Run 'mvn package' on the project in the attached Parent.zip. Note that the > dependency Jar2 gets packaged in WEB-INF/lib and the other dependencies (Jar, > Jar1 and Jar3) do not. > I think the inclusion of Jar2 is incorrect, because project 'Web' declares > its dependency on 'Jar' to be optional and Jar2 being a transitive dependency > of Jar should inherit this. > If you look at the other Jarx dependencies, they have different combinations > of ways to become optional and have their versions managed. Only the case > when optionality is inherited and the dependency management for the version > is in another pom, yields incorrect results. > Please note that I believe the maven-war-plugin is not the cause of this > behavior. I have built and used a modified version of maven-war-plugin which > as the first thing in its WarMojo.execute() lists the result of > getProject().getArtifacts() including the value of each Artifact's > isOptional() method. Already at this point only Jar2 has optional false. > I am using maven-war-plugin in this bug report for the following reasons: > * maven-war-plugin uses the optional flag of dependencies in deciding whether > to package it or not, making this behavior visible > * I don't know of another way to visualize the value of the optional flag in > core maven (running with -X outputs the dependency tree in a section with > header 'Dependency collection stats', but this only shows the scope value) > * maven-dependency-plugin:resolve also only shows scope and not optionality > * obviously, maven-war-plugin is exactly what I intend to use and where I > found the bug -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MNG-5935) Optional true getting lost in managed dependencies when transitive
[ https://issues.apache.org/jira/browse/MNG-5935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15942028#comment-15942028 ] Christian Schulte commented on MNG-5935: Issue is fixed in the master branch of [my private maven repository on github|https://github.com/ChristianSchulte/maven/tree/master]. When interested, you can cherry pick the commit to your own repository and create a pull request for the apache master branch with just this commit yourself from there. > Optional true getting lost in managed dependencies when transitive > -- > > Key: MNG-5935 > URL: https://issues.apache.org/jira/browse/MNG-5935 > Project: Maven > Issue Type: Bug > Components: Dependencies >Affects Versions: 3.3.9 > Environment: Apache Maven 3.3.9 > (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T17:41:47+01:00) > Maven home: C:\Temp\apache-maven-3.3.9 > Java version: 1.8.0_66, vendor: Oracle Corporation > Java home: C:\Prog\Java\v8_66\jre > Default locale: nl_NL, platform encoding: Cp1252 > OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos" >Reporter: Marcel Schutte > Fix For: 3.6.0-candidate > > Attachments: buildoutput.txt, Parent.zip > > > Run 'mvn package' on the project in the attached Parent.zip. Note that the > dependency Jar2 gets packaged in WEB-INF/lib and the other dependencies (Jar, > Jar1 and Jar3) do not. > I think the inclusion of Jar2 is incorrect, because project 'Web' declares > its dependency on 'Jar' to be optional and Jar2 being a transitive dependency > of Jar should inherit this. > If you look at the other Jarx dependencies, they have different combinations > of ways to become optional and have their versions managed. Only the case > when optionality is inherited and the dependency management for the version > is in another pom, yields incorrect results. > Please note that I believe the maven-war-plugin is not the cause of this > behavior. I have built and used a modified version of maven-war-plugin which > as the first thing in its WarMojo.execute() lists the result of > getProject().getArtifacts() including the value of each Artifact's > isOptional() method. Already at this point only Jar2 has optional false. > I am using maven-war-plugin in this bug report for the following reasons: > * maven-war-plugin uses the optional flag of dependencies in deciding whether > to package it or not, making this behavior visible > * I don't know of another way to visualize the value of the optional flag in > core maven (running with -X outputs the dependency tree in a section with > header 'Dependency collection stats', but this only shows the scope value) > * maven-dependency-plugin:resolve also only shows scope and not optionality > * obviously, maven-war-plugin is exactly what I intend to use and where I > found the bug -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MNG-5227) The 'optional' flag of a dependency should be manageable.
[
https://issues.apache.org/jira/browse/MNG-5227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15942027#comment-15942027
]
Christian Schulte commented on MNG-5227:
Issue is fixed in the master branch of [my private maven repository on
github|https://github.com/ChristianSchulte/maven/tree/master]. When interested,
you can cherry pick the commit to your own repository and create a pull request
for the apache master branch with just this commit yourself from there.
> The 'optional' flag of a dependency should be manageable.
> -
>
> Key: MNG-5227
> URL: https://issues.apache.org/jira/browse/MNG-5227
> Project: Maven
> Issue Type: New Feature
> Components: Artifacts and Repositories
>Affects Versions: 3.0.3
>Reporter: Christian Schulte
>Priority: Minor
> Fix For: 3.6.0-candidate
>
> Attachments: MNG-5227.patch, MNG-5227.patch
>
>
> {code}
>
>
>
> groupId
> artifactId
> version
> false
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (MNG-6135) Maven plugins and core extensions are not dependencies, they should be resolved the same way as projects.
[
https://issues.apache.org/jira/browse/MNG-6135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schulte reassigned MNG-6135:
--
Assignee: (was: Christian Schulte)
> Maven plugins and core extensions are not dependencies, they should be
> resolved the same way as projects.
> -
>
> Key: MNG-6135
> URL: https://issues.apache.org/jira/browse/MNG-6135
> Project: Maven
> Issue Type: Bug
>Reporter: Christian Schulte
>Priority: Critical
> Fix For: 3.6.0-candidate
>
>
> Due to a bug in the Maven resolver, plugin and core extensions were resolved
> incorrectly: the direct {{test}} and {{provided}} dependencies were ignored.
> Ironically, this fix breaks some plugins because direct {{test}} dependencies
> now take precedence over transitive {{compile}} one: see MNG-5739
> (we know only one case where {{provided}} case has an impact: MPLUGIN-296,
> and in this only case, the new behaviour is more consistent than the previous)
>
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MNG-5761) Dependency management is not transitive.
[ https://issues.apache.org/jira/browse/MNG-5761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15942029#comment-15942029 ] Christian Schulte commented on MNG-5761: Issue is fixed in the master branch of [my private maven repository on github|https://github.com/ChristianSchulte/maven/tree/master]. When interested, you can cherry pick the commit to your own repository and create a pull request for the apache master branch with just this commit yourself from there. > Dependency management is not transitive. > > > Key: MNG-5761 > URL: https://issues.apache.org/jira/browse/MNG-5761 > Project: Maven > Issue Type: Bug > Components: Dependencies >Affects Versions: 3.2.5 >Reporter: Jeff Schnitzer >Priority: Critical > Fix For: 3.6.0-candidate > > Attachments: MNG-5761.zip > > > A detailed description of the issue is here: > http://stackoverflow.com/questions/28312975/maven-dependencymanagement-version-ignored-in-transitive-dependencies > The short of it is that maven appears to be using the wrong > version in a transitive dependency. There are two > relevant sections in the build, one pulled in by guice > and one pulled in by gwizard-parent. These are the dependency paths from the > top: > gwizard-example -> gwizard-config -> gwizard-parent > gwizard-example -> gwizard-config -> guice -> guice-parent > gwizard-parent's dependencyManagement specifies guava 18 > guice-parent's dependencyManagement specifies guava 16 > Guava 16 is winning. This seems highly undesirable, and in fact it breaks our > build. I would expect that in a version # fight, "closest to the top" should > win. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
