[GitHub] [maven-resolver] rjatkins commented on issue #29: [MRESOLVER-68] Add cache around TrackingFileManager.getLock(File)
rjatkins commented on issue #29: [MRESOLVER-68] Add cache around TrackingFileManager.getLock(File) URL: https://github.com/apache/maven-resolver/pull/29#issuecomment-477470717 In local testing on Windows 10 (using jprofiler), with a particularly pathological use of maven-enforcer-plugin in a project with 23 bannedDependencies rules, across more than 100 poms, with a tree depth of 4, build times to run `mvn validate` come down from around 10 minutes to around 5 mins, shaving more than 300 seconds off the time spent executing `java.io.File.getCanonicalPath`. This is when using maven-enforcer-plugin 3.0.0-M2, which happens to build a new dependency graph for each use of the bannedDependencies rule, so its performance is particularly bad for this project. I'm looking at also adding another higher level fix to that project that will speed things up considerably there too, although this performance fix in maven-resolver will still be valuable even after that's done. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (MNG-6605) Unable to suppress download messages in interactive mode
[
https://issues.apache.org/jira/browse/MNG-6605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16803502#comment-16803502
]
Raymond Augé commented on MNG-6605:
---
I've submitted a potential solution here
https://github.com/apache/maven/pull/239
> Unable to suppress download messages in interactive mode
>
>
> Key: MNG-6605
> URL: https://issues.apache.org/jira/browse/MNG-6605
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.6.0
>Reporter: Gunnar Wagenknecht
>Priority: Major
> Fix For: waiting-for-feedback
>
> Attachments: 2019-03-06_14-06-09.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When running Maven in batch mode (with option {{-B}}) it's possible to
> suppress download messages using
> "{{-Dorg.slf4j.simpleLogger.log.org.apache.maven.cli.transfer.Slf4jMavenTransferListener=warn}}"
> Example:
> {{mvn clean install -B
> -Dorg.slf4j.simpleLogger.log.org.apache.maven.cli.transfer.Slf4jMavenTransferListener=warn}}
> When leaving out the {{-B}} option this no longer works.
> *Example:*
> {noformat}
> export MAVEN_OPTS='-Xmx1g
> -Dorg.slf4j.simpleLogger.log.org.apache.maven.cli.transfer.Slf4jMavenTransferListener=warn
> -Dorg.slf4j.simpleLogger.showDateTime=true
> -Dorg.slf4j.simpleLogger.dateTimeFormat=HH:mm:ss'
> mvn clean install
> {noformat}
> Prints out time stamps as configured but does not suppress download progress
> messages.
> *Expected:*
> Suppressing "Downloaded" messages from the console output should be possible
> without requiring the "{{--batch-mode}}" command line argument.
> *Motivation:*
> Because Travis CI supports colorized output in build logs I'd like to avoid
> batch mode.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] [maven] rotty3000 opened a new pull request #239: MNG-6605 Unable to suppress download messages in interactive mode
rotty3000 opened a new pull request #239: MNG-6605 Unable to suppress download messages in interactive mode URL: https://github.com/apache/maven/pull/239 A solution for quieting the `Download[ed|ing] from ...` messages. This solution introduces the system property flag `-Dorg.apache.maven.cli.transfer.ConsoleMavenTransferListener.quiet` which can either be used on the cli or be set in the `MAVEN_OPTS` so that it affects system wide. Signed-off-by: Raymond Auge Following this checklist to help us incorporate your contribution quickly and easily: - [x] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MNG) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [x] Each commit in the pull request should have a meaningful subject line and body. - [x] Format the pull request title like `[MNG-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MNG-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [x] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [x] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [x] You have run the [Core IT][core-its] successfully. If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [x] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [x] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). [core-its]: https://maven.apache.org/core-its/core-it-suite/ This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (MDEP-644) Reintroduce the verbose option for dependency:tree
[ https://issues.apache.org/jira/browse/MDEP-644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16803496#comment-16803496 ] John Lin commented on MDEP-644: --- Hi Robert, Yes, I would like to implement it. Is there any relevant material you suggest to read? Thank you. > Reintroduce the verbose option for dependency:tree > -- > > Key: MDEP-644 > URL: https://issues.apache.org/jira/browse/MDEP-644 > Project: Maven Dependency Plugin > Issue Type: New Feature > Components: tree >Reporter: John Lin >Priority: Major > > The verbose option for dependency:tree is removed in maven-dependency-plugin > 3.0. This issue is to reintroduce the option. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [maven-resolver] rjatkins commented on issue #29: [MRESOLVER-68] Add cache around TrackingFileManager.getLock(File)
rjatkins commented on issue #29: [MRESOLVER-68] Add cache around TrackingFileManager.getLock(File) URL: https://github.com/apache/maven-resolver/pull/29#issuecomment-477388807 I've added some unit tests around the cache, and I'm refreshing the performance results with the new cache, with the (new) default maximum size of 1024 entries. Note that Guava's caches never get to that limit, but use some heuristics to remove LRU entries before the cache gets full - this is for cases when the cache is being populated in multiple threads, when the cache would otherwise spend a lot of time in each thread purging the oldest entries. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Created] (MSHARED-811) Improve handling of Metadata
Robert Scholte created MSHARED-811: -- Summary: Improve handling of Metadata Key: MSHARED-811 URL: https://issues.apache.org/jira/browse/MSHARED-811 Project: Maven Shared Components Issue Type: Improvement Components: maven-artifact-transfer Affects Versions: maven-artifact-transfer-0.11.0 Reporter: Robert Scholte Assignee: Robert Scholte Fix For: maven-artifact-transfer-0.12.0 Current implementation doesn't support install/deploy of custom metadata such as gpg signatures. The related code contains a comment statement which needs to be implemented. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MCOMPILER-377) Upgrade plexus-java to 1.0.3
[ https://issues.apache.org/jira/browse/MCOMPILER-377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise updated MCOMPILER-377: -- Fix Version/s: (was: 3.8.1) 3.8.2 > Upgrade plexus-java to 1.0.3 > > > Key: MCOMPILER-377 > URL: https://issues.apache.org/jira/browse/MCOMPILER-377 > Project: Maven Compiler Plugin > Issue Type: Dependency upgrade >Affects Versions: 3.8.1 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.8.2 > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MDEPLOY-252) Deploy current archive without creating new archive (jar, war, ear)
[ https://issues.apache.org/jira/browse/MDEPLOY-252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16803353#comment-16803353 ] Ivica Mikic commented on MDEPLOY-252: - I also tried i.e. to skip default-jar goal when running "mvn install" or "mvn deploy" with the profile using "none" for it, but got the error "No primary artifact to install, installing attached artifacts instead.", in which case my jar hasn't been installed/deployed to the Maven repository at all. > Deploy current archive without creating new archive (jar, war, ear) > --- > > Key: MDEPLOY-252 > URL: https://issues.apache.org/jira/browse/MDEPLOY-252 > Project: Maven Deploy Plugin > Issue Type: New Feature > Components: deploy:deploy >Affects Versions: 2.8.2 >Reporter: Ivica Mikic >Priority: Major > Labels: features, maven > Fix For: waiting-for-feedback > > > It would be great to be able to deploy current archive file (jar, war, ear) > without creating a new one, to preserve timestamp from previous package or > install run. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MDEPLOY-252) Deploy current archive without creating new archive (jar, war, ear)
[ https://issues.apache.org/jira/browse/MDEPLOY-252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16803264#comment-16803264 ] Ivica Mikic commented on MDEPLOY-252: - >From the Maven perspective, we normally build our Java code first with "mvn >clean package" many times during the active code change/development. This is >done either manually on the command line or within the IDE. But once testing >has passed and the code is considered reasonably stable, we want to proceed >with the "mvn install", then "mvn deploy", but keep the original archive files >in sync since there are no code changes. Isn't that reasonable? What would be >the alternative? I would still like to accomplish this somehow within the Maven life cycle, if possible. > Deploy current archive without creating new archive (jar, war, ear) > --- > > Key: MDEPLOY-252 > URL: https://issues.apache.org/jira/browse/MDEPLOY-252 > Project: Maven Deploy Plugin > Issue Type: New Feature > Components: deploy:deploy >Affects Versions: 2.8.2 >Reporter: Ivica Mikic >Priority: Major > Labels: features, maven > Fix For: waiting-for-feedback > > > It would be great to be able to deploy current archive file (jar, war, ear) > without creating a new one, to preserve timestamp from previous package or > install run. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MDEPLOY-252) Deploy current archive without creating new archive (jar, war, ear)
[ https://issues.apache.org/jira/browse/MDEPLOY-252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16803189#comment-16803189 ] Karl Heinz Marbaise commented on MDEPLOY-252: - First which plugin would you think needed to be written? Furthermore why are you doing manually releases? Or Do I misunderstand a thing here? > Deploy current archive without creating new archive (jar, war, ear) > --- > > Key: MDEPLOY-252 > URL: https://issues.apache.org/jira/browse/MDEPLOY-252 > Project: Maven Deploy Plugin > Issue Type: New Feature > Components: deploy:deploy >Affects Versions: 2.8.2 >Reporter: Ivica Mikic >Priority: Major > Labels: features, maven > Fix For: waiting-for-feedback > > > It would be great to be able to deploy current archive file (jar, war, ear) > without creating a new one, to preserve timestamp from previous package or > install run. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MDEPLOY-252) Deploy current archive without creating new archive (jar, war, ear)
[ https://issues.apache.org/jira/browse/MDEPLOY-252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16803113#comment-16803113 ] Ivica Mikic commented on MDEPLOY-252: - That's exactly what I had in mind: incremental build as part of the Maven life cycle. However, if that does not work by default, is there any other way to make it work (by using some argument values, different plugins, etc)? Would it make sense to write a new plugin to accomplish this? > Deploy current archive without creating new archive (jar, war, ear) > --- > > Key: MDEPLOY-252 > URL: https://issues.apache.org/jira/browse/MDEPLOY-252 > Project: Maven Deploy Plugin > Issue Type: New Feature > Components: deploy:deploy >Affects Versions: 2.8.2 >Reporter: Ivica Mikic >Priority: Major > Labels: features, maven > Fix For: waiting-for-feedback > > > It would be great to be able to deploy current archive file (jar, war, ear) > without creating a new one, to preserve timestamp from previous package or > install run. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MDEP-644) Reintroduce the verbose option for dependency:tree
[ https://issues.apache.org/jira/browse/MDEP-644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16803088#comment-16803088 ] Robert Scholte commented on MDEP-644: - Does this mean you're going to implement it? The verbose option had to be removed to make the code Maven3 compatible, the cause is quite deep in the codebase. > Reintroduce the verbose option for dependency:tree > -- > > Key: MDEP-644 > URL: https://issues.apache.org/jira/browse/MDEP-644 > Project: Maven Dependency Plugin > Issue Type: New Feature > Components: tree >Reporter: John Lin >Priority: Major > > The verbose option for dependency:tree is removed in maven-dependency-plugin > 3.0. This issue is to reintroduce the option. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6612) Ability to set repository of dependency
[
https://issues.apache.org/jira/browse/MNG-6612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16802922#comment-16802922
]
Max Lee commented on MNG-6612:
--
While this might work for some projects it doesn't work for tons of others
which can't be hosted there due to depending on other libraries or having
non-compatible licenses. (Besides all the obvious issues a centralised
service has)
I do lots of work in the Minecraft server modding and extending community
and projects are often impossible to be hosted on central, either due to
the base APIs not being (able to be) included or due to their interaction
with the proprietary base game code. Granted they don't seem to take the
"self-contained" rule too serious as far as I can tell, but it's
questionable if someone who only barely is able to use maven for their
small project would be able to go through the whole process of arguing
against one of the rules to get it included. In the end you are lucky if
the projects you want to depend on are even using maven. I would assume
that other modding communities would face similar issues, although I don't
know of any Java based ones that have comparable sizes.
Also part of me opening this issue was hoping for me having overlooked an
obvious configuration option, so I guess I got my answer and have to do the
work myself if I really want this.
> Ability to set repository of dependency
> ---
>
> Key: MNG-6612
> URL: https://issues.apache.org/jira/browse/MNG-6612
> Project: Maven
> Issue Type: New Feature
> Components: Dependencies
>Reporter: Max Lee
>Priority: Minor
> Labels: Repository, dependency
>
> In a setup where you specify multiple different repositories for your project
> it would be a useful to be able to specify which repository contains which
> dependency in the pom and not resolve such dependencies from the general
> repositories but only the ones defined for the dependency.
> E.g. in cases where you don't want other dependencies to get resolve in
> certain repositories because they contain broken versions or when you simply
> want to stop the potential privacy/security issues that leaking dependencies
> to another repository that doesn't even include the dependency could
> introduce. (Theoretically an ignored/skip-repositories setting could also
> solve this issue) Another application of this feature could be to define
> different update or checksum check setting for different artifacts that would
> use the same repository.
> This could theoretically be setup using the repository name:
>
> {code:java}
>
> id.group
> artifact-id
> version-string
>
> repository-id
>
>
> {code}
> or by allowing to directly set the repository-settings in the dependency and
> not on the outer scope (this would allow for a wider range of applications by
> allowing different repository settings per artifact but require a larger
> config for simply setting the repository of an artifact)
>
> {code:java}
>
> id.group
> artifact-id
> version-string
>
>
> repository-id
> https://repo.example.com/
>
>
>
> {code}
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (MNG-6618) Maven doesn't export org.slf4j.event.Level
[
https://issues.apache.org/jira/browse/MNG-6618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16802856#comment-16802856
]
Viacheslav Yakunin edited comment on MNG-6618 at 3/27/19 2:25 PM:
--
it may be the same as was for MNG-6360, export package org.slf4j.event.*
[https://github.com/apache/maven/pull/157/files]
But I am not able to assess the impact of the change (
was (Author: viacheslav.yakunin):
it may be the same as was for MNG-6360, export package org.slf4j.event.Level.
[https://github.com/apache/maven/pull/157/files]
But I am not able to assess the impact of the change (
> Maven doesn't export org.slf4j.event.Level
> --
>
> Key: MNG-6618
> URL: https://issues.apache.org/jira/browse/MNG-6618
> Project: Maven
> Issue Type: Task
>Affects Versions: 3.6.0
>Reporter: Viacheslav Yakunin
>Priority: Blocker
> Fix For: waiting-for-feedback
>
>
> Hi, this is the same issue as https://issues.apache.org/jira/browse/MNG-6360.
> Unfortunately I was not able to reopen it so I am creating new one.
> I was able to reproduce it when I tried to create maven plugin for running
> kafka broker during integration tests. Kafka refers to org.slf4j.event.Level
> and this causes following exception during plugin execution.
> {code}
> [ERROR] [KafkaServer id=1] Fatal error during KafkaServer shutdown.
> java.lang.NoClassDefFoundError: org/slf4j/event/Level
> at
> kafka.utils.CoreUtils$.swallow$default$3(CoreUtils.scala:84)
> at kafka.server.KafkaServer.shutdown(KafkaServer.scala:567)
> at
> net.sla.buildtools.kafka.maven.plugin.SingletonLauncher.stop(SingletonLauncher.java:73)
> at
> net.sla.buildtools.kafka.maven.plugin.StopKafkaBrokerMojo.execute(StopKafkaBrokerMojo.java:18)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> at
> org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
> at
> org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
> at
> org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:47)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> com.intellij.rt.execution.CommandLineWrapper.main(CommandLineWrapper.java:65)
> Caused by: java.lang.ClassNotFoundException: org.slf4j.event.Level
> at
> org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50)
> at
> org.codehaus.plexus.
[jira] [Commented] (MNG-6618) Maven doesn't export org.slf4j.event.Level
[
https://issues.apache.org/jira/browse/MNG-6618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16802856#comment-16802856
]
Viacheslav Yakunin commented on MNG-6618:
-
it may be the same as was for MNG-6360, export package org.slf4j.event.Level.
[https://github.com/apache/maven/pull/157/files]
But I am not able to assess the impact of the change (
> Maven doesn't export org.slf4j.event.Level
> --
>
> Key: MNG-6618
> URL: https://issues.apache.org/jira/browse/MNG-6618
> Project: Maven
> Issue Type: Task
>Affects Versions: 3.6.0
>Reporter: Viacheslav Yakunin
>Priority: Blocker
> Fix For: waiting-for-feedback
>
>
> Hi, this is the same issue as https://issues.apache.org/jira/browse/MNG-6360.
> Unfortunately I was not able to reopen it so I am creating new one.
> I was able to reproduce it when I tried to create maven plugin for running
> kafka broker during integration tests. Kafka refers to org.slf4j.event.Level
> and this causes following exception during plugin execution.
> {code}
> [ERROR] [KafkaServer id=1] Fatal error during KafkaServer shutdown.
> java.lang.NoClassDefFoundError: org/slf4j/event/Level
> at
> kafka.utils.CoreUtils$.swallow$default$3(CoreUtils.scala:84)
> at kafka.server.KafkaServer.shutdown(KafkaServer.scala:567)
> at
> net.sla.buildtools.kafka.maven.plugin.SingletonLauncher.stop(SingletonLauncher.java:73)
> at
> net.sla.buildtools.kafka.maven.plugin.StopKafkaBrokerMojo.execute(StopKafkaBrokerMojo.java:18)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> at
> org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
> at
> org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
> at
> org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:47)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> com.intellij.rt.execution.CommandLineWrapper.main(CommandLineWrapper.java:65)
> Caused by: java.lang.ClassNotFoundException: org.slf4j.event.Level
> at
> org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50)
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass(ClassRealm.java:271)
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:247)
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(Cla
[jira] [Updated] (MNG-6618) Maven doesn't export org.slf4j.event.Level
[
https://issues.apache.org/jira/browse/MNG-6618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-6618:
Fix Version/s: waiting-for-feedback
> Maven doesn't export org.slf4j.event.Level
> --
>
> Key: MNG-6618
> URL: https://issues.apache.org/jira/browse/MNG-6618
> Project: Maven
> Issue Type: Task
>Affects Versions: 3.6.0
>Reporter: Viacheslav Yakunin
>Priority: Blocker
> Fix For: waiting-for-feedback
>
>
> Hi, this is the same issue as https://issues.apache.org/jira/browse/MNG-6360.
> Unfortunately I was not able to reopen it so I am creating new one.
> I was able to reproduce it when I tried to create maven plugin for running
> kafka broker during integration tests. Kafka refers to org.slf4j.event.Level
> and this causes following exception during plugin execution.
> {code}
> [ERROR] [KafkaServer id=1] Fatal error during KafkaServer shutdown.
> java.lang.NoClassDefFoundError: org/slf4j/event/Level
> at
> kafka.utils.CoreUtils$.swallow$default$3(CoreUtils.scala:84)
> at kafka.server.KafkaServer.shutdown(KafkaServer.scala:567)
> at
> net.sla.buildtools.kafka.maven.plugin.SingletonLauncher.stop(SingletonLauncher.java:73)
> at
> net.sla.buildtools.kafka.maven.plugin.StopKafkaBrokerMojo.execute(StopKafkaBrokerMojo.java:18)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> at
> org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
> at
> org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
> at
> org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:47)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> com.intellij.rt.execution.CommandLineWrapper.main(CommandLineWrapper.java:65)
> Caused by: java.lang.ClassNotFoundException: org.slf4j.event.Level
> at
> org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50)
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass(ClassRealm.java:271)
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:247)
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:239)
> ... 32 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (MNG-6618) Maven doesn't export org.slf4j.event.Level
[
https://issues.apache.org/jira/browse/MNG-6618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16802804#comment-16802804
]
Michael Osipov edited comment on MNG-6618 at 3/27/19 1:51 PM:
--
What is your proposal to fix that?
was (Author: michael-o):
What is your propposal to fix that?
> Maven doesn't export org.slf4j.event.Level
> --
>
> Key: MNG-6618
> URL: https://issues.apache.org/jira/browse/MNG-6618
> Project: Maven
> Issue Type: Task
>Affects Versions: 3.6.0
>Reporter: Viacheslav Yakunin
>Priority: Blocker
>
> Hi, this is the same issue as https://issues.apache.org/jira/browse/MNG-6360.
> Unfortunately I was not able to reopen it so I am creating new one.
> I was able to reproduce it when I tried to create maven plugin for running
> kafka broker during integration tests. Kafka refers to org.slf4j.event.Level
> and this causes following exception during plugin execution.
> {code}
> [ERROR] [KafkaServer id=1] Fatal error during KafkaServer shutdown.
> java.lang.NoClassDefFoundError: org/slf4j/event/Level
> at
> kafka.utils.CoreUtils$.swallow$default$3(CoreUtils.scala:84)
> at kafka.server.KafkaServer.shutdown(KafkaServer.scala:567)
> at
> net.sla.buildtools.kafka.maven.plugin.SingletonLauncher.stop(SingletonLauncher.java:73)
> at
> net.sla.buildtools.kafka.maven.plugin.StopKafkaBrokerMojo.execute(StopKafkaBrokerMojo.java:18)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> at
> org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
> at
> org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
> at
> org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:47)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> com.intellij.rt.execution.CommandLineWrapper.main(CommandLineWrapper.java:65)
> Caused by: java.lang.ClassNotFoundException: org.slf4j.event.Level
> at
> org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50)
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass(ClassRealm.java:271)
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:247)
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:239)
> ... 32 more
> {code}
--
This message was sent by Atl
[jira] [Commented] (MNG-6618) Maven doesn't export org.slf4j.event.Level
[
https://issues.apache.org/jira/browse/MNG-6618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16802804#comment-16802804
]
Michael Osipov commented on MNG-6618:
-
What is your propposal to fix that?
> Maven doesn't export org.slf4j.event.Level
> --
>
> Key: MNG-6618
> URL: https://issues.apache.org/jira/browse/MNG-6618
> Project: Maven
> Issue Type: Task
>Affects Versions: 3.6.0
>Reporter: Viacheslav Yakunin
>Priority: Blocker
>
> Hi, this is the same issue as https://issues.apache.org/jira/browse/MNG-6360.
> Unfortunately I was not able to reopen it so I am creating new one.
> I was able to reproduce it when I tried to create maven plugin for running
> kafka broker during integration tests. Kafka refers to org.slf4j.event.Level
> and this causes following exception during plugin execution.
> {code}
> [ERROR] [KafkaServer id=1] Fatal error during KafkaServer shutdown.
> java.lang.NoClassDefFoundError: org/slf4j/event/Level
> at
> kafka.utils.CoreUtils$.swallow$default$3(CoreUtils.scala:84)
> at kafka.server.KafkaServer.shutdown(KafkaServer.scala:567)
> at
> net.sla.buildtools.kafka.maven.plugin.SingletonLauncher.stop(SingletonLauncher.java:73)
> at
> net.sla.buildtools.kafka.maven.plugin.StopKafkaBrokerMojo.execute(StopKafkaBrokerMojo.java:18)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> at
> org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
> at
> org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
> at
> org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:47)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> com.intellij.rt.execution.CommandLineWrapper.main(CommandLineWrapper.java:65)
> Caused by: java.lang.ClassNotFoundException: org.slf4j.event.Level
> at
> org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50)
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass(ClassRealm.java:271)
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:247)
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:239)
> ... 32 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6612) Ability to set repository of dependency
[
https://issues.apache.org/jira/browse/MNG-6612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16802801#comment-16802801
]
Michael Osipov commented on MNG-6612:
-
Are you aware that you can host your OSS stuff on Maven Central? If you host
there your project must be selfcontained within Central. I will leave this
open, but i am certain that this will remain open for the next couple of years
and then abandoned.
> Ability to set repository of dependency
> ---
>
> Key: MNG-6612
> URL: https://issues.apache.org/jira/browse/MNG-6612
> Project: Maven
> Issue Type: New Feature
> Components: Dependencies
>Reporter: Max Lee
>Priority: Minor
> Labels: Repository, dependency
>
> In a setup where you specify multiple different repositories for your project
> it would be a useful to be able to specify which repository contains which
> dependency in the pom and not resolve such dependencies from the general
> repositories but only the ones defined for the dependency.
> E.g. in cases where you don't want other dependencies to get resolve in
> certain repositories because they contain broken versions or when you simply
> want to stop the potential privacy/security issues that leaking dependencies
> to another repository that doesn't even include the dependency could
> introduce. (Theoretically an ignored/skip-repositories setting could also
> solve this issue) Another application of this feature could be to define
> different update or checksum check setting for different artifacts that would
> use the same repository.
> This could theoretically be setup using the repository name:
>
> {code:java}
>
> id.group
> artifact-id
> version-string
>
> repository-id
>
>
> {code}
> or by allowing to directly set the repository-settings in the dependency and
> not on the outer scope (this would allow for a wider range of applications by
> allowing different repository settings per artifact but require a larger
> config for simply setting the repository of an artifact)
>
> {code:java}
>
> id.group
> artifact-id
> version-string
>
>
> repository-id
> https://repo.example.com/
>
>
>
> {code}
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MSHARED-810) Support Java 12
[ https://issues.apache.org/jira/browse/MSHARED-810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rune Flobakk updated MSHARED-810: - External issue URL: https://github.com/apache/maven-dependency-analyzer/pull/6 > Support Java 12 > --- > > Key: MSHARED-810 > URL: https://issues.apache.org/jira/browse/MSHARED-810 > Project: Maven Shared Components > Issue Type: Bug > Components: maven-dependency-analyzer >Affects Versions: maven-dependency-analyzer-1.11.1 >Reporter: Rune Flobakk >Priority: Minor > Labels: Java12 > > ASM 7.1 supports Java 12 (and supposedly Java 13): > [https://asm.ow2.io/versions.html] > I have upgraded to v7.1 and tested it with maven-dependency-plugin:analyze on > a Java 12 project, and it works fine with only the dependency update. > [https://github.com/runeflobakk/maven-dependency-analyzer/commit/a8f026e296109badafdd57312b5032d4f5d33fcc] > I am happy to make a pull request for it! > (or if you prefer to just make the simple change yourself, that's would of > course also be great. Just wanted to let you know of the simple change to > make it compatible with Java 12) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [maven-dependency-analyzer] runeflobakk opened a new pull request #6: [MSHARED-819] - Support Java 12
runeflobakk opened a new pull request #6: [MSHARED-819] - Support Java 12 URL: https://github.com/apache/maven-dependency-analyzer/pull/6 Upgrade ASM from 7.0 to 7.1, in order to support Java 12 bytecode. Verified works with maven-dependency-plugin `analyze`-goal on own Java-12 project. JIRA issue: https://issues.apache.org/jira/browse/MSHARED-810 ### Contribution checklist: - [x] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MSHARED) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. Also be sure having selected the correct component. - [x] Each commit in the pull request should have a meaningful subject line and body. - [x] Format the pull request title like `[MSHARED-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MSHARED-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [x] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [x] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [x] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Created] (SUREFIRE-1656) Print Total Elapsed Time of Tests
David Mollitor created SUREFIRE-1656:
Summary: Print Total Elapsed Time of Tests
Key: SUREFIRE-1656
URL: https://issues.apache.org/jira/browse/SUREFIRE-1656
Project: Maven Surefire
Issue Type: Improvement
Components: Maven Surefire Plugin
Reporter: David Mollitor
{code:java}
[INFO] Running org.apache.avro.reflect.TestReflectData
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.022 s
- in org.apache.avro.reflect.TestReflectData
[INFO] Running org.apache.avro.TestDataFileCustomSync
[INFO] Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 s - in
org.apache.avro.TestDataFileCustomSync
[INFO]
[INFO] Results:
[INFO]
[WARNING] Tests run: 3163, Failures: 0, Errors: 0, Skipped: 1
[INFO]
[INFO]
{code}
There is a per-test-suite 'time elapsed' value. Please add a total 'time
elapsed' as part of the results output.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6612) Ability to set repository of dependency
[
https://issues.apache.org/jira/browse/MNG-6612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16802696#comment-16802696
]
Max Lee commented on MNG-6612:
--
While this might be a valid solution for big enterprises it isn't really viable
for small open source projects where the goal of using maven usually is to be
able to simply checkout the repository and build it without having to setup any
kind of additional software. (Something that maven was supposed to get rid of
in the first place)
Another suggested approach is for the repository offered by the developer of
the software to include all necessary dependencies that the project might have
(so you only need to add this one repository instead of the ones of your
libraries) which fails again when looked at with an "ease of use" approach in
two aspects: The developer of the software would need to manually update all
libraries in their repository and also be required to have the ability to
actually host such a repository (which many have not), lots don't even provide
repositories for their own projects and only provide it on some git repository
(mostly github, thank god for
[jitpack|[http://jitpack.io|http://jitpack.io/]]...). Of course you could
potentially host a maven repository on github (or the git repository hoster of
your choice) directly but this seems a bit odd and is also generally
discouraged by those service's TOS.
There is also another potential security concern with querying all listed
repositories instead of doing that per dependency: A malicious actor could
publish an artifact that you shade into your project to a repository that
didn't already contain it which you only used for a provided dependency (hence
require less trust) but which gets queried before the one were the artifact is
actually included. (I assume central checks each published artifacts but other
repository managers might not be) That way one could introduce code into built
artifacts (at least for new builds) without anyone noticing (unless they check
where a certain dependency was downloaded from I guess)
Of course you could kinda work around this attack vector by listing
repositories of shaded dependencies before the ones of provided dependencies
but I feel like this is kinda an un-intuitive approach. It also fails as soon
as one of the previous repositories is unreachable for whatever reason...
especially as DDOS-attacks to achieve other goals aren't too uncommon these
days. So I don't think such an issue should be ignored ‒ especially if a quite
small addition of "repository pinning" directly in the pom would already solve
lots of the mentioned issues.
> Ability to set repository of dependency
> ---
>
> Key: MNG-6612
> URL: https://issues.apache.org/jira/browse/MNG-6612
> Project: Maven
> Issue Type: New Feature
> Components: Dependencies
>Reporter: Max Lee
>Priority: Minor
> Labels: Repository, dependency
>
> In a setup where you specify multiple different repositories for your project
> it would be a useful to be able to specify which repository contains which
> dependency in the pom and not resolve such dependencies from the general
> repositories but only the ones defined for the dependency.
> E.g. in cases where you don't want other dependencies to get resolve in
> certain repositories because they contain broken versions or when you simply
> want to stop the potential privacy/security issues that leaking dependencies
> to another repository that doesn't even include the dependency could
> introduce. (Theoretically an ignored/skip-repositories setting could also
> solve this issue) Another application of this feature could be to define
> different update or checksum check setting for different artifacts that would
> use the same repository.
> This could theoretically be setup using the repository name:
>
> {code:java}
>
> id.group
> artifact-id
> version-string
>
> repository-id
>
>
> {code}
> or by allowing to directly set the repository-settings in the dependency and
> not on the outer scope (this would allow for a wider range of applications by
> allowing different repository settings per artifact but require a larger
> config for simply setting the repository of an artifact)
>
> {code:java}
>
> id.group
> artifact-id
> version-string
>
>
> repository-id
> https://repo.example.com/
>
>
>
> {code}
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MASSEMBLY-907) Dependencies are not included when run with mvn install
[ https://issues.apache.org/jira/browse/MASSEMBLY-907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lau Bakman updated MASSEMBLY-907: - Attachment: 311_package_verbose.log > Dependencies are not included when run with mvn install > --- > > Key: MASSEMBLY-907 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-907 > Project: Maven Assembly Plugin > Issue Type: Bug >Affects Versions: 3.1.1 >Reporter: Lau Bakman >Assignee: Karl Heinz Marbaise >Priority: Major > Attachments: 310_install.log, 310_install_verbose.log, > 311_install.log, 311_install_verbose.log, 311_package_verbose.log, > assembly_deps.zip > > > We have just updated to version 3.1.1 due to MASSEMBLY-873 and have stumbled > upon a problem. > Our project is structured similar to the attached project. When we build our > project using "mvn clean package" the project is assembled correctly > including dependencies. If we on the other hand build our project using "mvn > clean install", only the top level jar files are assembled and all > dependencies are missing. > This worked in version 3.1.0. > Is this by design? And if it is, is there a way to revert to the old behavior? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MASSEMBLY-907) Dependencies are not included when run with mvn install
[ https://issues.apache.org/jira/browse/MASSEMBLY-907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16802667#comment-16802667 ] Lau Bakman commented on MASSEMBLY-907: -- Added the log for "mvn package" with version 3.1.1. > Dependencies are not included when run with mvn install > --- > > Key: MASSEMBLY-907 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-907 > Project: Maven Assembly Plugin > Issue Type: Bug >Affects Versions: 3.1.1 >Reporter: Lau Bakman >Assignee: Karl Heinz Marbaise >Priority: Major > Attachments: 310_install.log, 310_install_verbose.log, > 311_install.log, 311_install_verbose.log, 311_package_verbose.log, > assembly_deps.zip > > > We have just updated to version 3.1.1 due to MASSEMBLY-873 and have stumbled > upon a problem. > Our project is structured similar to the attached project. When we build our > project using "mvn clean package" the project is assembled correctly > including dependencies. If we on the other hand build our project using "mvn > clean install", only the top level jar files are assembled and all > dependencies are missing. > This worked in version 3.1.0. > Is this by design? And if it is, is there a way to revert to the old behavior? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MNG-6619) Core extensions should not be in plexus.core classloader
Stefan Oehme created MNG-6619: - Summary: Core extensions should not be in plexus.core classloader Key: MNG-6619 URL: https://issues.apache.org/jira/browse/MNG-6619 Project: Maven Issue Type: Bug Components: core Reporter: Stefan Oehme The core extensions classloader is set up in [MavenCli|https://github.com/apache/maven/blob/b7249aff22b8993ddecfed26003c2e1bc04e708c/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java#L788]. However, [this line|https://github.com/apache/maven/blob/0be26449fb96774be126a6ad245d1a98dc71907c/apache-maven/src/bin/m2.conf#L7] also loads them into the plexus.core classloader, which is really just supposed to contain the Maven core jars. This can lead to problems when event spies are added to `lib/ext`. They are instantiated and get events when resolving other extensions during the `loadCoreExtensions` method, even though they have not yet been initialized. I assume that the line in m2.conf is just outdated and superseded by `loadCoreExtensions` and should thus be removed to avoid non-initialized event spies being called while loading extensions. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [maven-surefire] eolivelli commented on issue #224: Work-in-progress Test new travis script
eolivelli commented on issue #224: Work-in-progress Test new travis script URL: https://github.com/apache/maven-surefire/pull/224#issuecomment-477094426 @Tibor17 trying with parallel = 2. Travis does not give much guarantees in this free version This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (MASSEMBLY-907) Dependencies are not included when run with mvn install
[ https://issues.apache.org/jira/browse/MASSEMBLY-907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16802646#comment-16802646 ] Lau Bakman commented on MASSEMBLY-907: -- I have added the logging output for both executions. To my untrained eyes there seem to be a difference in line 1572: * 3.1.0: Dependencies (resolve): [compile] * 3.1.1: Dependencies (resolve): [test] > Dependencies are not included when run with mvn install > --- > > Key: MASSEMBLY-907 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-907 > Project: Maven Assembly Plugin > Issue Type: Bug >Affects Versions: 3.1.1 >Reporter: Lau Bakman >Assignee: Karl Heinz Marbaise >Priority: Major > Attachments: 310_install.log, 310_install_verbose.log, > 311_install.log, 311_install_verbose.log, assembly_deps.zip > > > We have just updated to version 3.1.1 due to MASSEMBLY-873 and have stumbled > upon a problem. > Our project is structured similar to the attached project. When we build our > project using "mvn clean package" the project is assembled correctly > including dependencies. If we on the other hand build our project using "mvn > clean install", only the top level jar files are assembled and all > dependencies are missing. > This worked in version 3.1.0. > Is this by design? And if it is, is there a way to revert to the old behavior? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MASSEMBLY-907) Dependencies are not included when run with mvn install
[ https://issues.apache.org/jira/browse/MASSEMBLY-907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lau Bakman updated MASSEMBLY-907: - Attachment: 311_install.log 310_install_verbose.log 310_install.log 311_install_verbose.log > Dependencies are not included when run with mvn install > --- > > Key: MASSEMBLY-907 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-907 > Project: Maven Assembly Plugin > Issue Type: Bug >Affects Versions: 3.1.1 >Reporter: Lau Bakman >Assignee: Karl Heinz Marbaise >Priority: Major > Attachments: 310_install.log, 310_install_verbose.log, > 311_install.log, 311_install_verbose.log, assembly_deps.zip > > > We have just updated to version 3.1.1 due to MASSEMBLY-873 and have stumbled > upon a problem. > Our project is structured similar to the attached project. When we build our > project using "mvn clean package" the project is assembled correctly > including dependencies. If we on the other hand build our project using "mvn > clean install", only the top level jar files are assembled and all > dependencies are missing. > This worked in version 3.1.0. > Is this by design? And if it is, is there a way to revert to the old behavior? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [maven-surefire] Tibor17 commented on issue #224: Work-in-progress Test new travis script
Tibor17 commented on issue #224: Work-in-progress Test new travis script URL: https://github.com/apache/maven-surefire/pull/224#issuecomment-477087409 @eolivelli It looks like the build expired after 17 minutes. The CPU is so slow? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (MNG-6618) Maven doesn't export org.slf4j.event.Level
[
https://issues.apache.org/jira/browse/MNG-6618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16802625#comment-16802625
]
Viacheslav Yakunin commented on MNG-6618:
-
Linking to original one
> Maven doesn't export org.slf4j.event.Level
> --
>
> Key: MNG-6618
> URL: https://issues.apache.org/jira/browse/MNG-6618
> Project: Maven
> Issue Type: Task
>Affects Versions: 3.6.0
>Reporter: Viacheslav Yakunin
>Priority: Blocker
>
> Hi, this is the same issue as https://issues.apache.org/jira/browse/MNG-6360.
> Unfortunately I was not able to reopen it so I am creating new one.
> I was able to reproduce it when I tried to create maven plugin for running
> kafka broker during integration tests. Kafka refers to org.slf4j.event.Level
> and this causes following exception during plugin execution.
> {code}
> [ERROR] [KafkaServer id=1] Fatal error during KafkaServer shutdown.
> java.lang.NoClassDefFoundError: org/slf4j/event/Level
> at
> kafka.utils.CoreUtils$.swallow$default$3(CoreUtils.scala:84)
> at kafka.server.KafkaServer.shutdown(KafkaServer.scala:567)
> at
> net.sla.buildtools.kafka.maven.plugin.SingletonLauncher.stop(SingletonLauncher.java:73)
> at
> net.sla.buildtools.kafka.maven.plugin.StopKafkaBrokerMojo.execute(StopKafkaBrokerMojo.java:18)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> at
> org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
> at
> org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
> at
> org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:47)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> com.intellij.rt.execution.CommandLineWrapper.main(CommandLineWrapper.java:65)
> Caused by: java.lang.ClassNotFoundException: org.slf4j.event.Level
> at
> org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50)
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass(ClassRealm.java:271)
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:247)
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:239)
> ... 32 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MNG-6618) Maven doesn't export org.slf4j.event.Level
Viacheslav Yakunin created MNG-6618:
---
Summary: Maven doesn't export org.slf4j.event.Level
Key: MNG-6618
URL: https://issues.apache.org/jira/browse/MNG-6618
Project: Maven
Issue Type: Task
Affects Versions: 3.6.0
Reporter: Viacheslav Yakunin
Hi, this is the same issue as https://issues.apache.org/jira/browse/MNG-6360.
Unfortunately I was not able to reopen it so I am creating new one.
I was able to reproduce it when I tried to create maven plugin for running
kafka broker during integration tests. Kafka refers to org.slf4j.event.Level
and this causes following exception during plugin execution.
{code}
[ERROR] [KafkaServer id=1] Fatal error during KafkaServer shutdown.
java.lang.NoClassDefFoundError: org/slf4j/event/Level
at kafka.utils.CoreUtils$.swallow$default$3(CoreUtils.scala:84)
at kafka.server.KafkaServer.shutdown(KafkaServer.scala:567)
at
net.sla.buildtools.kafka.maven.plugin.SingletonLauncher.stop(SingletonLauncher.java:73)
at
net.sla.buildtools.kafka.maven.plugin.StopKafkaBrokerMojo.execute(StopKafkaBrokerMojo.java:18)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
at
org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
at
org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
at org.codehaus.classworlds.Launcher.main(Launcher.java:47)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
com.intellij.rt.execution.CommandLineWrapper.main(CommandLineWrapper.java:65)
Caused by: java.lang.ClassNotFoundException: org.slf4j.event.Level
at
org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50)
at
org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass(ClassRealm.java:271)
at
org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:247)
at
org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:239)
... 32 more
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MASSEMBLY-907) Dependencies are not included when run with mvn install
[ https://issues.apache.org/jira/browse/MASSEMBLY-907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16802591#comment-16802591 ] Karl Heinz Marbaise commented on MASSEMBLY-907: --- Can you please add the logging output of the two executions you have mentioned... > Dependencies are not included when run with mvn install > --- > > Key: MASSEMBLY-907 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-907 > Project: Maven Assembly Plugin > Issue Type: Bug >Affects Versions: 3.1.1 >Reporter: Lau Bakman >Assignee: Karl Heinz Marbaise >Priority: Major > Attachments: assembly_deps.zip > > > We have just updated to version 3.1.1 due to MASSEMBLY-873 and have stumbled > upon a problem. > Our project is structured similar to the attached project. When we build our > project using "mvn clean package" the project is assembled correctly > including dependencies. If we on the other hand build our project using "mvn > clean install", only the top level jar files are assembled and all > dependencies are missing. > This worked in version 3.1.0. > Is this by design? And if it is, is there a way to revert to the old behavior? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Reopened] (MASSEMBLY-907) Dependencies are not included when run with mvn install
[ https://issues.apache.org/jira/browse/MASSEMBLY-907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise reopened MASSEMBLY-907: --- > Dependencies are not included when run with mvn install > --- > > Key: MASSEMBLY-907 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-907 > Project: Maven Assembly Plugin > Issue Type: Bug >Affects Versions: 3.1.1 >Reporter: Lau Bakman >Assignee: Karl Heinz Marbaise >Priority: Major > Attachments: assembly_deps.zip > > > We have just updated to version 3.1.1 due to MASSEMBLY-873 and have stumbled > upon a problem. > Our project is structured similar to the attached project. When we build our > project using "mvn clean package" the project is assembled correctly > including dependencies. If we on the other hand build our project using "mvn > clean install", only the top level jar files are assembled and all > dependencies are missing. > This worked in version 3.1.0. > Is this by design? And if it is, is there a way to revert to the old behavior? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MASSEMBLY-907) Dependencies are not included when run with mvn install
[ https://issues.apache.org/jira/browse/MASSEMBLY-907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16802508#comment-16802508 ] Lau Bakman commented on MASSEMBLY-907: -- I have tried with every version of maven-assembly-plugin from version 2.3. Only 3.1.1 fails to assemble the attached project correctly. > Dependencies are not included when run with mvn install > --- > > Key: MASSEMBLY-907 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-907 > Project: Maven Assembly Plugin > Issue Type: Bug >Affects Versions: 3.1.1 >Reporter: Lau Bakman >Assignee: Karl Heinz Marbaise >Priority: Major > Attachments: assembly_deps.zip > > > We have just updated to version 3.1.1 due to MASSEMBLY-873 and have stumbled > upon a problem. > Our project is structured similar to the attached project. When we build our > project using "mvn clean package" the project is assembled correctly > including dependencies. If we on the other hand build our project using "mvn > clean install", only the top level jar files are assembled and all > dependencies are missing. > This worked in version 3.1.0. > Is this by design? And if it is, is there a way to revert to the old behavior? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MASSEMBLY-907) Dependencies are not included when run with mvn install
[ https://issues.apache.org/jira/browse/MASSEMBLY-907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16802505#comment-16802505 ] Lau Bakman commented on MASSEMBLY-907: -- In the attached project: Change maven.assembly.plugin.version to 3.1.0 and execute "mvn install": spike.services.hello is assembled including dependencies in the lib folder. Change maven.assembly.plugin.version to 3.1.1 and execute "mvn install": spike.services.hello is assembled but without dependencies. > Dependencies are not included when run with mvn install > --- > > Key: MASSEMBLY-907 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-907 > Project: Maven Assembly Plugin > Issue Type: Bug >Affects Versions: 3.1.1 >Reporter: Lau Bakman >Assignee: Karl Heinz Marbaise >Priority: Major > Attachments: assembly_deps.zip > > > We have just updated to version 3.1.1 due to MASSEMBLY-873 and have stumbled > upon a problem. > Our project is structured similar to the attached project. When we build our > project using "mvn clean package" the project is assembled correctly > including dependencies. If we on the other hand build our project using "mvn > clean install", only the top level jar files are assembled and all > dependencies are missing. > This worked in version 3.1.0. > Is this by design? And if it is, is there a way to revert to the old behavior? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MASSEMBLY-907) Dependencies are not included when run with mvn install
[ https://issues.apache.org/jira/browse/MASSEMBLY-907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16802504#comment-16802504 ] Lau Bakman commented on MASSEMBLY-907: -- I still believe it is a bug and it is very much a problem for us. We cannot use 3.1.0 anymore due to MASSEMBLY-873 and we cannot upgrade to 3.1.1 because of a change in behavior. Prior to 3.1.1 our project setup which is demonstrated in the attached assembly_deps worked flawlessly, assembling all jars and their dependencies. With 3.1.1 this is no longer the case. Something has broken (for us) when the plugin is executed as part of "mvn install" My last comment yesterday concerned your question of why we use the "dir" format. We use the "dir" format to create a directory structure for building our installers. We cannot build the structure if the dependencies are not copied to the assembly output directory. The maven-resource-plugin is not relevant for this problem - it was part of my explanation for the "dir" format. > Dependencies are not included when run with mvn install > --- > > Key: MASSEMBLY-907 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-907 > Project: Maven Assembly Plugin > Issue Type: Bug >Affects Versions: 3.1.1 >Reporter: Lau Bakman >Assignee: Karl Heinz Marbaise >Priority: Major > Attachments: assembly_deps.zip > > > We have just updated to version 3.1.1 due to MASSEMBLY-873 and have stumbled > upon a problem. > Our project is structured similar to the attached project. When we build our > project using "mvn clean package" the project is assembled correctly > including dependencies. If we on the other hand build our project using "mvn > clean install", only the top level jar files are assembled and all > dependencies are missing. > This worked in version 3.1.0. > Is this by design? And if it is, is there a way to revert to the old behavior? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
