[GitHub] maven-surefire pull request: Remove JUnit4Provider.java.orig.
Github user asfgit closed the pull request at: https://github.com/apache/maven-surefire/pull/39 --- 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 feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Maven EAR Plugin version 2.9.1
+1 On 17 June 2014 05:33, Robert Scholte wrote: > +1 > > * maven-ear-plugin-2.9.1-source-release.zip results in BUILD SUCCESS > * [INFO] Rat check: Summary of files. Unapproved: 0 unknown: 0 generated: 0 > approved: 330 licence. > * SHA1 correct > * Site is ok > > Robert > > Op Sun, 15 Jun 2014 16:23:51 +0200 schreef Karl Heinz Marbaise > : > >> Hi, >> >> We solved 2 issues: >> >> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11132&version=18776 >> >> There are still 27 issues left in JIRA: >> >> http://jira.codehaus.org/issues/?jql=project%20%3D%20MEAR%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC >> >> Staging repo: >> https://repository.apache.org/content/repositories/maven-1024 >> >> >> http://repository.apache.org/content/repositories/maven-1024/org/apache/maven/plugins/maven-ear-plugin/2.9.1/maven-ear-plugin-2.9.1-source-release.zip >> >> Source release checksum(s): >> maven-ear-plugin-2.9.1-source-release.zip sha1: >> b1f8e9e492c0199636da22c741736a38307a8f57 >> >> Staging site: >> http://maven.apache.org/plugins-archives/maven-ear-plugin-LATEST/ >> >> Guide to testing staged releases: >> http://maven.apache.org/guides/development/guide-testing-releases.html >> >> Vote open for 72 hours. >> >> [ ] +1 >> [ ] +0 >> [ ] -1 >> >> Kind regards >> Karl-Heinz Marbaise >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > -- Olivier Lamy Ecetera: http://ecetera.com.au http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[GitHub] maven pull request: - logging configuration now no longer overwrit...
Github user jvanzyl commented on the pull request: https://github.com/apache/maven/pull/22#issuecomment-46256490 I will push this in right after I cut the 3.2.2. --- 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 feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Releasing 3.2.2
Ok, fixed a few more things over the weekend and I think all is good. If no other problems surface I'll stage it tomorrow morning (EDT). On Jun 14, 2014, at 2:53 PM, Hervé BOUTEMY wrote: > Le samedi 14 juin 2014 13:51:21 Jason van Zyl a écrit : >> So my current plan is to roll in Christian's change, and then I'm going to >> roll the 3.2.2. > +1 > >> >> If anyone wants to work on anything else speak up. I'm in no rush but I have >> time this weekend so I'll roll the 3.2.2 if no one else is going to work on >> anything. > not me: I already did what I wanted in 3.2.2 :) > >> >> My next project is to write a validator that compares what Aether resolves, >> what it looks like after the project filter is applied, and what that looks >> like in the WAR, Assembly, and Dependency plugin. There are a whole raft of >> issues where there are claimed scope transition issues but it's not easy >> for a user to see what's actually resolved vs what a plugin might do if it >> employes its own resolution or artifact filtering. I've already found one >> case where the WAR plugin isn't doing the right thing so I'm just going to >> make a tool to split out everything along the way so I can see what system >> is at fault and then try to fix the problems, or assign them to the >> respective plugin. > +1 > I tried to write UT for maven-aether-provider, to check exactly the same > thing: but the task was hard and I never finished > > you expect to run the validator against what content? > > Regards, > > Hervé > >> On Jun 12, 2014, at 8:05 AM, Jason van Zyl wrote: >>> Git and Github especially get credit. If there is a PR for core with tests >>> and a corresponding PR for the integration tests and it all applies and >>> passes as per [1] then it makes reviewing so, so much easier. >>> >>> The next set of validation I'd like to do is make sure that all of m2e >>> work with any of these changes. If this works then incorporating changes >>> becomes radically easier. Working on these PRs has been very pleasant. >>> Maybe not for the contributors whose PRs I erased by mistake. Konstantin >>> was particularly patient. >>> >>> [1]: http://takari.io/2014/06/02/contributing-to-maven-core.html >>> >>> On Jun 12, 2014, at 5:15 AM, Michael-O <1983-01...@gmx.net> wrote: > I'm going to look at a couple more issues, but I'm done processing all > the pull requests and I will look at cutting a release over the > weekend. > > Thanks to all of those who contributed pull requests for core! The > highest level of participation I've seen in a long time.>> I think this credit goes to Github. It eases the participation of non-committers tremendously. Though, we need to improve the PR process on mirrored repos. Mike - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org >>> >>> Thanks, >>> >>> Jason >>> >>> -- >>> Jason van Zyl >>> Founder, Apache Maven >>> http://twitter.com/jvanzyl >>> http://twitter.com/takari_io >>> - >>> >>> A man enjoys his work when he understands the whole and when he >>> is responsible for the quality of the whole >>> >>> -- Christopher Alexander, A Pattern Language >> >> Thanks, >> >> Jason >> >> -- >> Jason van Zyl >> Founder, Apache Maven >> http://twitter.com/jvanzyl >> http://twitter.com/takari_io >> - >> >> People develop abstractions by generalizing from concrete examples. >> Every attempt to determine the correct abstraction on paper without >> actually developing a running system is doomed to failure. No one >> is that smart. A framework is a resuable design, so you develop it by >> looking at the things it is supposed to be a design of. The more examples >> you look at, the more general your framework will be. >> >> -- Ralph Johnson & Don Roberts, Patterns for Evolving Frameworks > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io -
[GitHub] maven-surefire pull request: Remove JUnit4Provider.java.orig.
GitHub user Stephan202 opened a pull request: https://github.com/apache/maven-surefire/pull/39 Remove JUnit4Provider.java.orig. The file `surefire-providers/surefire-junit4/src/main/java/org/apache/maven/surefire/junit4/JUnit4Provider.java.orig` was accidentally committed in 3274bd308adc85ef16d463cb7aa8af290465bc67. A benign mistake. You can merge this pull request into a Git repository by running: $ git pull https://github.com/Stephan202/maven-surefire remove-patch-artifact Alternatively you can review and apply these changes as the patch at: https://github.com/apache/maven-surefire/pull/39.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #39 commit 0bac911a303d9a3c7a43f2dee7c7bf8cd1f306bb Author: Stephan Schroevers Date: 2014-06-16T19:37:04Z Remove JUnit4Provider.java.orig. --- 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 feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Maven EAR Plugin version 2.9.1
+1 * maven-ear-plugin-2.9.1-source-release.zip results in BUILD SUCCESS * [INFO] Rat check: Summary of files. Unapproved: 0 unknown: 0 generated: 0 approved: 330 licence. * SHA1 correct * Site is ok Robert Op Sun, 15 Jun 2014 16:23:51 +0200 schreef Karl Heinz Marbaise : Hi, We solved 2 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11132&version=18776 There are still 27 issues left in JIRA: http://jira.codehaus.org/issues/?jql=project%20%3D%20MEAR%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC Staging repo: https://repository.apache.org/content/repositories/maven-1024 http://repository.apache.org/content/repositories/maven-1024/org/apache/maven/plugins/maven-ear-plugin/2.9.1/maven-ear-plugin-2.9.1-source-release.zip Source release checksum(s): maven-ear-plugin-2.9.1-source-release.zip sha1: b1f8e9e492c0199636da22c741736a38307a8f57 Staging site: http://maven.apache.org/plugins-archives/maven-ear-plugin-LATEST/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Kind regards Karl-Heinz Marbaise - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[GitHub] maven pull request: - logging configuration now no longer overwrit...
Github user jvanzyl commented on the pull request: https://github.com/apache/maven/pull/22#issuecomment-46200202 You may want to try running the script described in here just to make sure the Maven ITs are not affected by the change. We have several ITs that specifically look at log output. Thanks for the pull request! If I can integrate it into the 3.2.2 release I will, but I'm about to cut it. --- 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 feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[GitHub] maven pull request: - logging configuration now no longer overwrit...
GitHub user a-horst opened a pull request: https://github.com/apache/maven/pull/22 - logging configuration now no longer overwrites the default log level - logging configuration now no longer overwrites the default log level as specified in conf/logging/simplelogger.properties (see [MNG-2570] (http://jira.codehaus.org/browse/MNG-2570) (related)); the default log level was always set to "info" unless either option "debug" or "quiet" were used; this made it effectively impossible to change the default log level to something other than "debug", "error" or "info" You can merge this pull request into a Git repository by running: $ git pull https://github.com/a-horst/maven master Alternatively you can review and apply these changes as the patch at: https://github.com/apache/maven/pull/22.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #22 commit b5cc5a948f90ef8dc8f202d7180354f2df96d155 Author: a-horst Date: 2014-06-16T15:00:12Z - logging configuration now no longer overwrites the default log level as specified in conf/logging/simplelogger.properties (see MNG-2570) --- 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 feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Use of code using aether in a plugin
On Jun 16, 2014, at 8:22 AM, Nigel Magnay wrote: > Ah, I'm using 0.9.0.M3, should I downgrade it ? Ideally I'd like to be able > to support all versions of maven (this is actually being upgraded as things >> maven 3.0.x aren't working) > Then don't use Aether. Look at the technique used in the maven-dependency-tree if you want something that works in multiple versions of Maven. What happened with Aether is unfortunate but it's definitely a mess. > It seems a bit messy that if I'm using aether in a module, and I want to > use that module directly in a maven plugin, but I can see how the 'most > normal' usecase would want it that way. I wonder if there's some > classloader or uberjar/shading alternative. Aside from a few outliers you should be fine with the version that Maven uses, if you want to use Aether directly. > > > On Mon, Jun 16, 2014 at 1:09 PM, Jason van Zyl wrote: > >> You are using Aether 1.0, stick with 0.9.0.M2. Maven itself hasn't >> upgraded to 1.0. The version used in the core is exported for use in >> plugins. >> >> On Jun 16, 2014, at 6:06 AM, Nigel Magnay wrote: >> >>> Hi >>> >>> I have some pre-existing code that uses org.eclipse.aether, that works >> fine. >>> >>> However, when I reference it and invoke it from a maven-plugin, I get >>> >>> A required class was missing while executing : >>> org.eclipse.aether.spi.connector.transport.TransporterFactory >>> >>> Looking at the urls spat out, it seems aether-spi is not of the >> classpath. >>> It's in the plugin manifest though. >>> >>> I assume it's being masked out somehow, as it's used in maven as well. I >>> don't want to use Maven's RepositorySystem. >>> >>> What's one supposed to do in this circumstance? shade? >> >> Thanks, >> >> Jason >> >> -- >> Jason van Zyl >> Founder, Apache Maven >> http://twitter.com/jvanzyl >> http://twitter.com/takari_io >> - >> >> We know what we are, but know not what we may be. >> >> -- Shakespeare >> >> >> >> >> >> >> >> >> >> Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - People develop abstractions by generalizing from concrete examples. Every attempt to determine the correct abstraction on paper without actually developing a running system is doomed to failure. No one is that smart. A framework is a resuable design, so you develop it by looking at the things it is supposed to be a design of. The more examples you look at, the more general your framework will be. -- Ralph Johnson & Don Roberts, Patterns for Evolving Frameworks
Re: Use of code using aether in a plugin
Ah, I'm using 0.9.0.M3, should I downgrade it ? Ideally I'd like to be able to support all versions of maven (this is actually being upgraded as things > maven 3.0.x aren't working) It seems a bit messy that if I'm using aether in a module, and I want to use that module directly in a maven plugin, but I can see how the 'most normal' usecase would want it that way. I wonder if there's some classloader or uberjar/shading alternative. On Mon, Jun 16, 2014 at 1:09 PM, Jason van Zyl wrote: > You are using Aether 1.0, stick with 0.9.0.M2. Maven itself hasn't > upgraded to 1.0. The version used in the core is exported for use in > plugins. > > On Jun 16, 2014, at 6:06 AM, Nigel Magnay wrote: > > > Hi > > > > I have some pre-existing code that uses org.eclipse.aether, that works > fine. > > > > However, when I reference it and invoke it from a maven-plugin, I get > > > > A required class was missing while executing : > > org.eclipse.aether.spi.connector.transport.TransporterFactory > > > > Looking at the urls spat out, it seems aether-spi is not of the > classpath. > > It's in the plugin manifest though. > > > > I assume it's being masked out somehow, as it's used in maven as well. I > > don't want to use Maven's RepositorySystem. > > > > What's one supposed to do in this circumstance? shade? > > Thanks, > > Jason > > -- > Jason van Zyl > Founder, Apache Maven > http://twitter.com/jvanzyl > http://twitter.com/takari_io > - > > We know what we are, but know not what we may be. > > -- Shakespeare > > > > > > > > > >
Re: Use of code using aether in a plugin
You are using Aether 1.0, stick with 0.9.0.M2. Maven itself hasn't upgraded to 1.0. The version used in the core is exported for use in plugins. On Jun 16, 2014, at 6:06 AM, Nigel Magnay wrote: > Hi > > I have some pre-existing code that uses org.eclipse.aether, that works fine. > > However, when I reference it and invoke it from a maven-plugin, I get > > A required class was missing while executing : > org.eclipse.aether.spi.connector.transport.TransporterFactory > > Looking at the urls spat out, it seems aether-spi is not of the classpath. > It's in the plugin manifest though. > > I assume it's being masked out somehow, as it's used in maven as well. I > don't want to use Maven's RepositorySystem. > > What's one supposed to do in this circumstance? shade? Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - We know what we are, but know not what we may be. -- Shakespeare
Use of code using aether in a plugin
Hi I have some pre-existing code that uses org.eclipse.aether, that works fine. However, when I reference it and invoke it from a maven-plugin, I get A required class was missing while executing : org.eclipse.aether.spi.connector.transport.TransporterFactory Looking at the urls spat out, it seems aether-spi is not of the classpath. It's in the plugin manifest though. I assume it's being masked out somehow, as it's used in maven as well. I don't want to use Maven's RepositorySystem. What's one supposed to do in this circumstance? shade?
Re: A thought on local-SNAPSHOTs
That's it... and also note that while Maven complains if the pom at the specified is not the parent, it will build correctly ... just resolving the parent from the local repository and not from the disk. On 16 June 2014 06:05, Barrie Treloar wrote: > On 16 June 2014 14:12, Stephen Connolly > wrote: > > > On Sunday, 15 June 2014, Mark Derricutt wrote: > > > > > So if I have two modules that are interdependent on in-progress > changes, > > > how does one build/test the dependant one. > > > > > > Note - reactor builds and multi-modules builds are out of the question > - > > > the above modules are in separate git repositories and there's no way > to > > > create a "fake reactor" setup - i.e. a separate pom.xml just listing > > > elements ( maven complains when that pom is not the parent ). > > > > > > Even if the local aggregator does something like > > > > ../foo > > > A link to a blog post or more detail might be useful for those still > learning. > > I'm pretty sure I know this to look like > ROOT/ > - aggregator > - pom.xml (reference modules ../projectA and ../projectB) > - projectA > - projectB > > But its not something I do, and I'm hoping I got it right from Maven > experience :) > > This is where the vaoporware "Magic Checkout" plugin that Kristian has > mentioned would be useful. > This plugin would automatically change a released dependency to its > snapshot version, check it out, and update/create the aggregator project to > reference the checked out version. >
