[GitHub] maven-integration-testing pull request: [MNG-5958] restore binary ...

Github user michael-o commented on the pull request: https://github.com/apache/maven-integration-testing/pull/13#issuecomment-170228875 The Its do not work if you are behind a repo manager and in an locked down environment, regardless of the tips on the site. --- If your project is

Re: Log4j Warning

Branch updated with changes to make it work. And here is an example extension to make logback "take over": https://github.com/cstamas/maven-logback-logging To use it 1. build the slf4j-gossip branch 2. build the maven-logback-logging extension 3. in desired project just add .mvn/extensions.xml

Re: [VOTE] Release Apache Maven Shade Plugin version 2.4.3

+1 Regards, Hervé Le mercredi 6 janvier 2016 22:05:36 Tibor Digana a écrit : > Hi, > > We solved 4 issues: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317921 > rsion=12333879 > > There are still a couple of issues left in JIRA: >

Re: [Jigsaw] Fwd: Specifying module paths

Hi Paul, thanks for your response. I'm not sure if I follow you with the forking problem. I guess you're talking about the fork option of surefire. Maybe one of the active surefire committers can explain how classpaths are handled right now and if this has a conflict with this proposal.

[GitHub] maven-integration-testing pull request: [MNG-5958] restore binary ...

Github user jvanzyl commented on the pull request: https://github.com/apache/maven-integration-testing/pull/13#issuecomment-170241627 Once all the files are in the bootstrap that you might need I've never had an issue. I'll double check on Monday, but last week I ran the ITs on a

Re: Strange problem with custom ArtifactHandler

Hi, RepositoryUtils is a utility class, whereas an ArtifactHandler is a Component (i.e. injectable), so these 2 don't mix that well together. IMHO the Artifact is way too big and too complex. It is a mixture of a pojo with component(s), and that's probably also the reason why there was an

Re: Log4j Warning

The gossip JAR looks small. I’d be fine using that as it satisfies the need for colours and is nominally bigger than slf4j-simple which will make almost everyone happy. This alleviates the colour debate. You want to try it? For more complicated use cases someone we’ll need an extension and

Re: migrating Surefire to 3.0-RC1

Hi Tibor, Regarding the artifactResolver.resolveTransitively, this has been replaced with dependencyResolver. The reason is that an artifact is basically a coordinate with a file, it is not aware of dependencies. I've traced one down for you:

Re: Log4j Warning

I assume gossip does the magic for substitue or delegating loggers? If that’s working to run gossip during startup and then cleanly flipping over to logback with all the proper rebinding then great. The ITs work with gossip? > On Jan 9, 2016, at 9:28 AM, Tamás Cservenák

[GitHub] maven-surefire pull request: SUREFIRE-1216: TEST-*.xml files gener...

Github user Tibor17 commented on the pull request: https://github.com/apache/maven-surefire/pull/110#issuecomment-170281465 @mfriedenhagen Can you answer my question to the exec time we spoke abot in https://issues.apache.org/jira/browse/SUREFIRE-964 ? It is related to this

Re: [Jigsaw] Fwd: Specifying module paths

This is a very good proposal. My only suggestion is to extend javax.tools CompilationTask API to take modulepath map as in-memory parameter. Not a big deal, but it'll be silly to write properties file to disk for it to be immediately read by the code executed in the same jvm. -- Regards, Igor

[GitHub] maven-surefire pull request: SUREFIRE-1216: TEST-*.xml files gener...

Github user mfriedenhagen commented on the pull request: https://github.com/apache/maven-surefire/pull/110#issuecomment-170283705 * @Tibor17, I think I was confused by test files in the Jenkins' XUnit plugin (see

[GitHub] maven-surefire pull request: SUREFIRE-1216: TEST-*.xml files gener...

Github user Tibor17 commented on the pull request: https://github.com/apache/maven-surefire/pull/110#issuecomment-170285026 Feel free to push it to master. I will then update a branch 3.0-rc1. You can then close it in jira. If you have time we would need to alter

[GitHub] maven-surefire pull request: SUREFIRE-1216: TEST-*.xml files gener...

GitHub user mfriedenhagen opened a pull request: https://github.com/apache/maven-surefire/pull/110 SUREFIRE-1216: TEST-*.xml files generated by Surefire are invalid. You can merge this pull request into a Git repository by running: $ git pull

[GitHub] maven-surefire pull request: SUREFIRE-1216: TEST-*.xml files gener...

Github user Tibor17 commented on the pull request: https://github.com/apache/maven-surefire/pull/110#issuecomment-170281272 LGTM --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature

Re: [VOTE] Release Apache Maven Shade Plugin version 2.4.3

+1 non-binding, tested with a small project using Maven 3.3.9 and JDK 1.7.0_80. Regards Mirko -- http://illegalstateexception.blogspot.com/ https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen) https://bitbucket.org/mfriedenhagen/ On Sat, Jan 9, 2016 at 4:33 PM, Hervé BOUTEMY

[GitHub] maven-plugins pull request: Update Deprecated usage of shaHex to s...

GitHub user nhojpatrick opened a pull request: https://github.com/apache/maven-plugins/pull/78 Update Deprecated usage of shaHex to sha1Hex See https://commons.apache.org/proper/commons-codec/apidocs/org/apache/commons/codec/digest/DigestUtils.html#shaHex%28byte[]%29 You can merge

Re: [DISCUSS] MDEPLOY-205: MavenProject with only attachments must have packaging "pom"

what about packaging=bundle? it has jar extension -D On Sat, Jan 9, 2016 at 9:04 AM, Robert Scholte wrote: > Hi, > > I've created MDEPLOY-205: MavenProject with only attachments must have > packaging "pom"[1] > > If I apply such a change, tests written for MDEPLOY-45 and

[DISCUSS] MDEPLOY-205: MavenProject with only attachments must have packaging "pom"

Hi, I've created MDEPLOY-205: MavenProject with only attachments must have packaging "pom"[1] If I apply such a change, tests written for MDEPLOY-45 and MDEPLOY-78 fail. [ERROR] The following builds failed: [ERROR] * mdeploy-45-test\pom.xml [ERROR] * no-main-artifact-1\pom.xml [ERROR] *

[GitHub] maven-integration-testing pull request: [MNG-5958] restore binary ...

Github user michael-o commented on the pull request: https://github.com/apache/maven-integration-testing/pull/13#issuecomment-170257051 That is strange, I ran the ITs from my Windows and FreeBSD machine at work. Both failed with `maven.it.central` pointing to our Nexus instance. On

Re: [Jigsaw] Fwd: Specifying module paths

a. Regarding execution of forked JVM in Surefire it has nothing to do with javac, nothing but java. Regarding building forked jar, then yes this may have an impact because we create jar file which contains manifetst having Class-Path. b. Is the classpath in manifest going to be deprecated or

Re: [Jigsaw] Fwd: Specifying module paths

According to the JDK ticket, Alan says: "anything that implements "module path" would need to support this." I assumed this also means java.exe. The ticket also states they want to get away from "long command lines". Based on these remarks, it should be affecting forking too. On Jan 9, 2016 10:57

Re: [Jigsaw] Fwd: Specifying module paths

So if I do not implement module-info.java in surefire booter, everything would be same as in the old JVM? What if a user has module-info.class in one of his jar files which appears in Class-Path of surefire's MANIFEST.MF? Anyway we should include Oracle guys into our discussion. What influence

Re: [Jigsaw] Fwd: Specifying module paths

module-info on classpath is ignored. That's also the reason why I can run surefire with my module-info enriched project. If you add a jar without module-info to the module-path, it is considered an automodule, i.e exports all packages and requires all available modules. This kind of

Re: [DISCUSS] MDEPLOY-205: MavenProject with only attachments must have packaging "pom"

that's all handled by the ArtifactHandler, which knows how to translate the packaging and type to a specific file extension. So let me rephrase: in my opinion a non-pom MavenProject MUST have a main artifact. Regarding the integration tests, to me they abuse the lifecycle for a specific

[GitHub] maven-surefire pull request: Update README.TXT

GitHub user Tibor17 opened a pull request: https://github.com/apache/maven-surefire/pull/111 Update README.TXT You can merge this pull request into a Git repository by running: $ git pull https://github.com/Tibor17/maven-surefire patch-1 Alternatively you can review and

[GitHub] maven-surefire pull request: Update README.TXT

Github user asfgit closed the pull request at: https://github.com/apache/maven-surefire/pull/111 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the

Re: [DISCUSS] MDEPLOY-205: MavenProject with only attachments must have packaging "pom"

+1 to introduce this policy which surely reduce the confusion of packaging type during deploy:deploy-file -D On Sat, Jan 9, 2016 at 10:34 AM, Robert Scholte wrote: > that's all handled by the ArtifactHandler, which knows how to translate > the packaging and type to a