Re: problem to git reset hash at git-wip-us.apache.org/repos/asf
When you do the git reset --hard command you basically move your local "master" branch back somewhere else in history. If you make a commit at the point, you will not be able to push to apache, since it refuses to rollback history. To get out of this situation you need to do git merge origin/master before pushing (assuming git-wip-us.apache.org is origin) Kristian 2014-12-24 1:49 GMT+01:00 : > I need a help with reseting the master > git-wip-us.apache.org/repos/asf/surefire. > I did like this: > git reset --hard f7558cb8ff087d5aaf114ec291babac31896bef3 > git commit > git push -u https://git-wip-us.apache.org/repos/asf/maven-surefire.git > master > GitHub is telling me: > remote: Rewinding refs/heads/master is forbidden. > Is there another way to reset the HEAD to another hash? > > - > 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
Re: problem to git reset hash at git-wip-us.apache.org/repos/asf
I see you have pushed some "interesting" committs to surefire master @ apache. These are a permanent part of history, and cannot be undone. You also pushed a few "interesting" branches, which I took the liberty of deleting, sicne they were pointing to existing history. In general, I find that using "gitk --all" is a very good tool to try to understand what's going on when I'm confused. K 2014-12-24 11:41 GMT+01:00 Kristian Rosenvold : > When you do the git reset --hard command you basically move your local > "master" branch back somewhere else in history. If you make a commit > at the point, you will not be able to push to apache, since it refuses > to rollback history. > > To get out of this situation you need to do git merge origin/master > before pushing (assuming git-wip-us.apache.org is origin) > > Kristian > > > 2014-12-24 1:49 GMT+01:00 : >> I need a help with reseting the master >> git-wip-us.apache.org/repos/asf/surefire. >> I did like this: >> git reset --hard f7558cb8ff087d5aaf114ec291babac31896bef3 >> git commit >> git push -u https://git-wip-us.apache.org/repos/asf/maven-surefire.git >> master >> GitHub is telling me: >> remote: Rewinding refs/heads/master is forbidden. >> Is there another way to reset the HEAD to another hash? >> >> - >> 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
Re: Contributing to Maven
I was looking at bug list and found this - MavenMNG-5721 Which is a possible null pointer exception in org.apache.maven.repository. MetadataResolutionResult It is a fairly easy fix where you have to assign the output of initList function to a private variable …. I want to fix it. Can some one tell me how do I submit a patch ? the maven site has details on submitting patch with SVN but I guess the project has moved on to GIT. On Dec 23, 2014, at 1:48 PM, Karl Heinz Marbaise wrote: > Hi, > > On 12/23/14 2:45 AM, Raghavendra Vaidya wrote: >> I have downloaded, built and setup maven code on intellij I am able to >> debug the maven build on the IDE. >> >> I want to start contributing to the project by fixing bugs. > > http://maven.apache.org/guides/development/guide-helping.html > > Furthermore there is a JIRA for Maven itself: > > http://jira.codehaus.org/browse/MNG > > and for every plugin there are also JIRA areas available see: > > http://maven.apache.org/plugins/ > > See the links on the right side SVN/Git and JIRA ... > > You can start working on one of the issues and see if you can handle it > If you have any questions don't hesitate to ask here on the dev list... > > >> >> Could some one point me to resources / documentation on the Maven code >> design - how the java components are put together . >> > > Kind regards > Karl Heinz Marbaise > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org >
"prepare for the Anschluss"
the line from Sound of Music that seems applicable for this situtation
when I run the dx Utility from maven-android-plugin as:
java -Xmx5120M -jar $ANDROID_HOME/lib/dx.jar --dex
--output=$ANDROID_HOME/target/classes.dex
${user.home}/.m2/repository/org/apache/maven/maven-plugin-descriptor/2.0.5/maven-plugin-descriptor-2.0.5.jar
${user.home}/.m2/repository/com/android/tools/lint/lint-api/22.4.2/lint-api-22.4.2.jar
...space delimited list of 1000 assorted jars to be converted to DEX
fubars with the following friendly message:
UNEXPECTED TOP-LEVEL EXCEPTION:
java.lang.IllegalArgumentException: already added:
Lorg/objectweb/asm/tree/AbstractInsnNode;
at com.android.dx.dex.file.ClassDefsSection.add(ClassDefsSection.java:122)
at com.android.dx.dex.file.DexFile.add(DexFile.java:161)
at com.android.dx.command.dexer.Main.processClass(Main.java:685)
at com.android.dx.command.dexer.Main.processFileBytes(Main.java:634)
at com.android.dx.command.dexer.Main.access$600(Main.java:78)
at com.android.dx.command.dexer.Main$1.processFileBytes(Main.java:572)
at
com.android.dx.cf.direct.ClassPathOpener.processArchive(ClassPathOpener.java:284)
at
com.android.dx.cf.direct.ClassPathOpener.processOne(ClassPathOpener.java:166)
at
com.android.dx.cf.direct.ClassPathOpener.process(ClassPathOpener.java:144)
at com.android.dx.command.dexer.Main.processOne(Main.java:596)
at com.android.dx.command.dexer.Main.processAllFiles(Main.java:498)
at com.android.dx.command.dexer.Main.runMonoDex(Main.java:264)
at com.android.dx.command.dexer.Main.run(Main.java:230)
at com.android.dx.command.dexer.Main.main(Main.java:199)
at com.android.dx.command.Main.main(Main.java:103)
1149 errors; aborting
warning: Ignoring InnerClasses attribute for an anonymous inner class
(org.apache.commons.jxpath.JXPathBasicBeanInfo$1) that doesn't come with an
associated EnclosingMethod attribute. This class was probably produced by a
compiler that did not target the modern .class file format. The recommended
solution is to recompile the class from source, using an up-to-date compiler
and without specifying any "-target" type options. The consequence of ignoring
this warning is that reflective operations on this class will incorrectly
indicate that it is *not* an inner class.
Apparently Androids com.android.dx.cf.direct.ClassPathOpener is expecting a
specific format of Class for reflection magic so apparently I would need to
recompile ALL of the maven jars in my local repo to at least 1.7.0_45 before
attempting ..i have 1000 at last count and this effort would be too time
consuming so I am seeking advice on how to mitigate
Google has decided to shy away from Androids Dalvik VM to create Googles own VM
for Android Lollipop called ART here are some conversion pointers..The long
winded explanation for this paradigm shift involves lawsuits in US Courts
Moving from DALVIK to ART
Enabling ART in Android Build
Device Runtime(s)
Two runtimes are now available, the existing Dalvik runtime (libdvm.so) and the
ART runtime (libart.so).
A device can be built using either or both runtimes. (You can dual boot from
Developer options if both runtimes are installed.)
See runtime_common.mk. That is included from
build/target/product/runtime_libdvm.mk or
build/target/product/runtime_libdvm.mk or both.
To maintain backward compatibility, ART uses the same input bytecode as Dalvik,
supplied through standard .dex files as part of APK files,
DEX to ART ELF Conversion:
Once an application is compiled by using ART's on-device dex2oat utility, it is
run solely from the compiled ELF executable
the Dalvik .odex files are replaced with Executable and Linkable Format (ELF)
executables output from dex2oat
These helpful hints should be sanitised and posted somewhere but I dont know
where this should go?
Looks like we have some interesting work to look forward to 2015
Happy Channukah/Merry Christmas
Martin
__
[DISCUSS] Move everything to 1.6, take 2 (was: Re: I can't make a release ...)
>Oops. Snappy contains 1.6 java bytecode, which breaks the build on maven >plugins. We need to upgrade to 1.6; I'm taking this to the mailing list :) Last time discussed this we established a consensus to establish 3.0.5 (maybe 3.0.6) as a minimum baseline for the 3.x range of plugins. This 3.0.X has a 1.5 java requirement. The problem is that *everyone* is moving to 1.6 and it's getting increasingly hard to maintain a 1.5 code base. As an example, I have been moving code to apache commons, but we're basically unable to use this effort because commons is now 1.6. alternately I need to backport the code in a "source-level-shading", but these things are getting silly. I propose the following: Make the 3.x line of plugins java 1.6+ only. Release all shared utilities in 1.6 versions in the 3.x version range. 3.0.X maven versions stay "forever" on the 2.x line of plugins and jdk 1.5. The most recent core version moves defaults to the 3.x range of plugins. The parent poms migrate to 3.x range some time in the near future. Keeping 3.0.x fixes to a minuimum (and "critical" stuff) only, will ensure that we can still stay 1.5 compatible here. Kristian 2014-12-24 13:52 GMT+01:00 Benson Margulies : > I don't have access to push a plexus-archiver release, could you > please do the honors. > > Also, looks like my splitting job left some work behind in terms of > the parent pom. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Contributing to Maven
Hi, best is to create a patch which is attached to the jira issue... And yes maven itself is in Git...and take a look if after you change all tests are correctly working... So somplest is to create a fork of the apache repository create a local branch according to the issue and create an appropriate pull request...give hint in the jira issue... Thanks. Kind regards karl Heinz Marbaise On 12/24/14 2:02 PM, Raghavendra Vaidya wrote: I was looking at bug list and found this - MavenMNG-5721 Which is a possible null pointer exception in org.apache.maven.repository. MetadataResolutionResult It is a fairly easy fix where you have to assign the output of initList function to a private variable …. I want to fix it. Can some one tell me how do I submit a patch ? the maven site has details on submitting patch with SVN but I guess the project has moved on to GIT. On Dec 23, 2014, at 1:48 PM, Karl Heinz Marbaise wrote: Hi, On 12/23/14 2:45 AM, Raghavendra Vaidya wrote: I have downloaded, built and setup maven code on intellij I am able to debug the maven build on the IDE. I want to start contributing to the project by fixing bugs. http://maven.apache.org/guides/development/guide-helping.html Furthermore there is a JIRA for Maven itself: http://jira.codehaus.org/browse/MNG and for every plugin there are also JIRA areas available see: http://maven.apache.org/plugins/ See the links on the right side SVN/Git and JIRA ... You can start working on one of the issues and see if you can handle it If you have any questions don't hesitate to ask here on the dev list... Could some one point me to resources / documentation on the Maven code design - how the java components are put together . - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] Move everything to 1.6, take 2 (was: Re: I can't make a release ...)
We already discussed this so many times But seriously with 2015 coming really soon I believe it's time. Finally so many years after java 1.5 EOL! :-) -- Olivier On 25 Dec 2014 00:20, "Kristian Rosenvold" wrote: > >Oops. Snappy contains 1.6 java bytecode, which breaks the build on maven > plugins. We need to upgrade to 1.6; I'm taking this to the mailing list :) > > Last time discussed this we established a consensus to establish 3.0.5 > (maybe 3.0.6) as a minimum baseline for the 3.x range of plugins. > > This 3.0.X has a 1.5 java requirement. The problem is that *everyone* > is moving to 1.6 and it's getting increasingly hard to maintain a 1.5 > code base. As an example, I have been moving code to apache commons, > but we're basically unable to use this effort because commons is now > 1.6. alternately I need to backport the code in a > "source-level-shading", but these things are getting silly. > > I propose the following: > > Make the 3.x line of plugins java 1.6+ only. > Release all shared utilities in 1.6 versions in the 3.x version range. > 3.0.X maven versions stay "forever" on the 2.x line of plugins and jdk 1.5. > The most recent core version moves defaults to the 3.x range of plugins. > The parent poms migrate to 3.x range some time in the near future. > > Keeping 3.0.x fixes to a minuimum (and "critical" stuff) only, will > ensure that we can still stay 1.5 compatible here. > > > Kristian > > 2014-12-24 13:52 GMT+01:00 Benson Margulies : > > I don't have access to push a plexus-archiver release, could you > > please do the honors. > > > > Also, looks like my splitting job left some work behind in terms of > > the parent pom. > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: problem to git reset hash at git-wip-us.apache.org/repos/asf
Yes I supposed last few commits won't be able undo other way. Next time this will not happen, we will make "safe" commitments first. What branches were introduced? The apache branch had master and surefire-954-test only. The whole problem was with maven-release-plugin:2.2.1 and some other with SSLv3 and not-generated MD5 in Nexus repository. We were unable to deploy release versions. Thus the team decided to use the latest maven-parent and apache POM which means that now we use maven-release-plugin:2.5.1 working with git client 1.9.5. Since we have quite urgent fixes in surefire I will call a vote. The people reported next two major issues only, so we have 98 major, and after surefire 2.19 the number of issues should decrease again. Then we will have let's say more stable code and API to prepare for surefire 3.0. Since the rest of the issues are a lot of features, after fixing them in 2.19, we will get better imagination of what API the people would like to customize in 3.0 instead of plugin's pom configuration. - BR, tibor17 -- View this message in context: http://maven.40175.n5.nabble.com/problem-to-git-reset-hash-at-git-wip-us-apache-org-repos-asf-tp5820756p5820822.html Sent from the Maven Developers mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] Move everything to 1.6, take 2 (was: Re: I can't make a release ...)
+1 if someone really wants to stay with JDK 5, just don't update plugins to latest and greatest and IMHO, if we need to maintain Maven 3.0.x in parallel from 3.2.x, that's not because of the JDK prerequisite: that's because there are problems to upgrade some plugins because of Aether change Regards, Hervé Le mercredi 24 décembre 2014 14:20:06 Kristian Rosenvold a écrit : > >Oops. Snappy contains 1.6 java bytecode, which breaks the build on maven > >plugins. We need to upgrade to 1.6; I'm taking this to the mailing list :) > Last time discussed this we established a consensus to establish 3.0.5 > (maybe 3.0.6) as a minimum baseline for the 3.x range of plugins. > > This 3.0.X has a 1.5 java requirement. The problem is that *everyone* > is moving to 1.6 and it's getting increasingly hard to maintain a 1.5 > code base. As an example, I have been moving code to apache commons, > but we're basically unable to use this effort because commons is now > 1.6. alternately I need to backport the code in a > "source-level-shading", but these things are getting silly. > > I propose the following: > > Make the 3.x line of plugins java 1.6+ only. > Release all shared utilities in 1.6 versions in the 3.x version range. > 3.0.X maven versions stay "forever" on the 2.x line of plugins and jdk 1.5. > The most recent core version moves defaults to the 3.x range of plugins. > The parent poms migrate to 3.x range some time in the near future. > > Keeping 3.0.x fixes to a minuimum (and "critical" stuff) only, will > ensure that we can still stay 1.5 compatible here. > > > Kristian > > 2014-12-24 13:52 GMT+01:00 Benson Margulies : > > I don't have access to push a plexus-archiver release, could you > > please do the honors. > > > > Also, looks like my splitting job left some work behind in terms of > > the parent pom. > > - > 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
[VOTE] Release Apache Maven Surefire Plugin version 2.18.1
Hi, We solved 13 issues: https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10541&version=20814 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&mode=hide&jqlQuery=project+%3D+SUREFIRE+AND+resolution+%3D+Unresolved+ORDER+BY+updated+DESC Staging repo: https://repository.apache.org/content/repositories/maven-1110 https://repository.apache.org/service/local/repositories/maven-1110/content/org/apache/maven/surefire/surefire/2.18.1/surefire-2.18.1-source-release.zip Source release checksum(s): surefire-2.18.1-source-release.zip sha1: 59a04c54118e796ca3729b0376a71891d299ed9b Staging site: http://maven.apache.org/surefire-archives/surefire-LATEST/maven-surefire-plugin/index.html http://maven.apache.org/surefire-archives/surefire-LATEST/maven-failsafe-plugin/index.html http://maven.apache.org/surefire-archives/surefire-LATEST/maven-surefire-report-plugin/index.html Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Plexus Archiver -- snappy?
Le mardi 23 décembre 2014 19:10:48 Benson Margulies a écrit : > I made the changes here for snappy. There are two outstanding pull > requests that seem to predate some pretty significant work. Shall I > selfishly make a release without them? Give their authors some time to > update? > > Is there a better mailing list for this item? now that even the code is outside Codehaus, plexus-dev ML is full dead... perhaps time to move code to ASF? looking at plexus-archiver history, it seems to have been taken from Ant: https://github.com/sonatype/plexus-archiver/commits/master?page=14 Regards, Hervé - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] Move everything to 1.6, take 2 (was: Re: I can't make a release ...)
+1 (Hoping we can get up to 1.7 soon too) On Wednesday, 24 December 2014, Kristian Rosenvold wrote: > >Oops. Snappy contains 1.6 java bytecode, which breaks the build on maven > plugins. We need to upgrade to 1.6; I'm taking this to the mailing list :) > > Last time discussed this we established a consensus to establish 3.0.5 > (maybe 3.0.6) as a minimum baseline for the 3.x range of plugins. > > This 3.0.X has a 1.5 java requirement. The problem is that *everyone* > is moving to 1.6 and it's getting increasingly hard to maintain a 1.5 > code base. As an example, I have been moving code to apache commons, > but we're basically unable to use this effort because commons is now > 1.6. alternately I need to backport the code in a > "source-level-shading", but these things are getting silly. > > I propose the following: > > Make the 3.x line of plugins java 1.6+ only. > Release all shared utilities in 1.6 versions in the 3.x version range. > 3.0.X maven versions stay "forever" on the 2.x line of plugins and jdk 1.5. > The most recent core version moves defaults to the 3.x range of plugins. > The parent poms migrate to 3.x range some time in the near future. > > Keeping 3.0.x fixes to a minuimum (and "critical" stuff) only, will > ensure that we can still stay 1.5 compatible here. > > > Kristian > > 2014-12-24 13:52 GMT+01:00 Benson Margulies >: > > I don't have access to push a plexus-archiver release, could you > > please do the honors. > > > > Also, looks like my splitting job left some work behind in terms of > > the parent pom. > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > -- Sent from my phone
Re: [VOTE] Release Apache Maven Surefire Plugin version 2.18.1
Hi, first just a question: Why are the CI builds https://builds.apache.org/view/All/job/maven-surefire-mvn-2.2.1/ and those for windows: https://builds.apache.org/view/All/job/maven-surefire-windows/ are failing ? Is there a good reason to ignore those results ? Or are those failures based on known issues? Kind regards Karl Heinz Marbaise On 12/24/14 5:03 PM, tibo...@lycos.com wrote: Hi, We solved 13 issues: https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10541&version=20814 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&mode=hide&jqlQuery=project+%3D+SUREFIRE+AND+resolution+%3D+Unresolved+ORDER+BY+updated+DESC Staging repo: https://repository.apache.org/content/repositories/maven-1110 https://repository.apache.org/service/local/repositories/maven-1110/content/org/apache/maven/surefire/surefire/2.18.1/surefire-2.18.1-source-release.zip Source release checksum(s): surefire-2.18.1-source-release.zip sha1: 59a04c54118e796ca3729b0376a71891d299ed9b Staging site: http://maven.apache.org/surefire-archives/surefire-LATEST/maven-surefire-plugin/index.html http://maven.apache.org/surefire-archives/surefire-LATEST/maven-failsafe-plugin/index.html http://maven.apache.org/surefire-archives/surefire-LATEST/maven-surefire-report-plugin/index.html Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Maven Surefire Plugin version 2.18.1
Good question, this was our problem whole year. I was asking Kristian about the same, and AFAIK this was related to the machine itself. One can see OutOfMemoryError: PermGen space As this wasn't my priviledge to fix the system setup, i was not able to make more here. - BR, tibor17 -- View this message in context: http://maven.40175.n5.nabble.com/VOTE-Release-Apache-Maven-Surefire-Plugin-version-2-18-1-tp5820843p5820864.html Sent from the Maven Developers mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Maven Surefire Plugin version 2.18.1
Hi, so I have taken a look into the setup for Maven 2.2.1 where the memory settings look like this (which looks very similar to the README.txt)... -Xmx2g -Xms256m -XX:MaxPermSize=512m Apart from that those build don't fail based on out of memory... https://builds.apache.org/view/All/job/maven-surefire-mvn-2.2.1/ws/maven-failsafe-plugin/target/it/jetty-war-test-failing/build.log/*view*/ The following looks different: import: Entry[import from realm ClassRealm[maven.api, parent: null]] - at org.apache.maven.plugin.internal.DefaultMavenPluginManager.getConfiguredMojo(DefaultMavenPluginManager.java:485) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:92) ... 20 more Caused by: java.lang.UnsupportedClassVersionError: org/eclipse/jetty/maven/plugin/JettyStopMojo : Unsupported major.minor version 51.0 at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631) at java.lang.ClassLoader.defineClass(ClassLoader.java:615) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141) at java.net.URLClassLoader.defineClass(URLClassLoader.java:283) at java.net.URLClassLoader.access$000(URLClassLoader.java:58) at java.net.URLClassLoader$1.run(URLClassLoader.java:197) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:190) at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClassFromSelf(ClassRealm.java:386) at org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:42) at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:244) at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:230) at org.sonatype.guice.bean.reflect.URLClassSpace.loadClass(URLClassSpace.java:101) at org.sonatype.guice.bean.reflect.NamedClass.load(NamedClass.java:45) at org.sonatype.guice.bean.reflect.AbstractDeferredClass.get(AbstractDeferredClass.java:45) at com.google.inject.internal.ProviderInternalFactory.provision(ProviderInternalFactory.java:84) at com.google.inject.internal.InternalFactoryToInitializableAdapter.provision(InternalFactoryToInitializableAdapter.java:52) at com.google.inject.internal.ProviderInternalFactory$1.call(ProviderInternalFactory.java:70) at com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:100) at org.sonatype.guice.plexus.lifecycles.PlexusLifecycleManager.onProvision(PlexusLifecycleManager.java:138) at com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:108) at com.google.inject.internal.ProvisionListenerStackCallback.provision(ProvisionListenerStackCallback.java:55) at com.google.inject.internal.ProviderInternalFactory.circularGet(ProviderInternalFactory.java:68) at com.google.inject.internal.InternalFactoryToInitializableAdapter.get(InternalFactoryToInitializableAdapter.java:45) at com.google.inject.internal.InjectorImpl$3$1.call(InjectorImpl.java:965) at com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1011) at com.google.inject.internal.InjectorImpl$3.get(InjectorImpl.java:961) at com.google.inject.Scopes$1$1.get(Scopes.java:59) at org.sonatype.guice.bean.locators.LazyBeanEntry.getValue(LazyBeanEntry.java:83) at org.sonatype.guice.plexus.locators.LazyPlexusBean.getValue(LazyPlexusBean.java:49) at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:253) at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:245) at org.apache.maven.plugin.internal.DefaultMavenPluginManager.getConfiguredMojo(DefaultMavenPluginManager.java:455) ... 21 more [ERROR] [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/PluginContainerException Running post-build script: /home/jenkins/jenkins-slave/workspace/maven-surefire-mvn-2.2.1/maven-failsafe-plugin/target/it/jetty-war-test-failing/verify.bsh Could not find failsafe summary: /home/jenkins/jenkins-slave/workspace/maven-surefire-mvn-2.2.1/maven-failsafe-plugin/target/it/jetty-war-test-failing/target/failsafe-reports/failsafe-summary.xml Finished post-build script: /home/jenkins/jenkins-slave/workspace/maven-surefire-mvn-2.2.1/maven-failsafe-plugin/target/it/jetty-war-test-failing/verify.bsh The other IT's fails for the same reason: https://builds.apache.org/view/All/job/maven-surefire-mvn-2.2.1/ws/maven-failsafe-plugin/target/it/jetty-war-test-passing/build.log/*view*/ Caused by:
Re: [VOTE] Release Apache Maven Surefire Plugin version 2.18.1
The tests in failsafe-plugin wasn't touched in 2.18 and 2.18.1. The IT "jetty-war-test-failing" you have picked up was improved 5 months ago which survived previous release too. https://github.com/apache/maven-surefire/commits/master/maven-failsafe-plugin/src/it/jetty-war-test-failing/pom.xml The last one seems to be misleading, but it is legal, since it is supposed to "interrupt" the JUnit test execution - we are searching expected message "finished abruptly after timeout of 2.5 seconds" in log. Entire code is compiled by javac 1.5. Already reported JIRA @ 2.19 https://jira.codehaus.org/browse/SUREFIRE-1128 - BR, tibor17 -- View this message in context: http://maven.40175.n5.nabble.com/VOTE-Release-Apache-Maven-Surefire-Plugin-version-2-18-1-tp5820843p5820873.html Sent from the Maven Developers mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Maven Surefire Plugin version 2.18.1
Upon the users pressure and frequent bug SUREFIRE-1121, the Surefire 2.18.1 release fixed the blocker SUREFIRE-1121, and other important major fixes SUREFIRE-1114, SUREFIRE-1112. - BR, tibor17 -- View this message in context: http://maven.40175.n5.nabble.com/VOTE-Release-Apache-Maven-Surefire-Plugin-version-2-18-1-tp5820843p5820878.html Sent from the Maven Developers mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] Move everything to 1.6, take 2 (was: Re: I can't make a release ...)
+1, would also make testing with JDK9 easier, although I've already found a good solution for that. Robert Op Wed, 24 Dec 2014 14:20:06 +0100 schreef Kristian Rosenvold : Oops. Snappy contains 1.6 java bytecode, which breaks the build on maven plugins. We need to upgrade to 1.6; I'm taking this to the mailing list :) Last time discussed this we established a consensus to establish 3.0.5 (maybe 3.0.6) as a minimum baseline for the 3.x range of plugins. This 3.0.X has a 1.5 java requirement. The problem is that *everyone* is moving to 1.6 and it's getting increasingly hard to maintain a 1.5 code base. As an example, I have been moving code to apache commons, but we're basically unable to use this effort because commons is now 1.6. alternately I need to backport the code in a "source-level-shading", but these things are getting silly. I propose the following: Make the 3.x line of plugins java 1.6+ only. Release all shared utilities in 1.6 versions in the 3.x version range. 3.0.X maven versions stay "forever" on the 2.x line of plugins and jdk 1.5. The most recent core version moves defaults to the 3.x range of plugins. The parent poms migrate to 3.x range some time in the near future. Keeping 3.0.x fixes to a minuimum (and "critical" stuff) only, will ensure that we can still stay 1.5 compatible here. Kristian 2014-12-24 13:52 GMT+01:00 Benson Margulies : I don't have access to push a plexus-archiver release, could you please do the honors. Also, looks like my splitting job left some work behind in terms of the parent pom. - 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
Re: [DISCUSS] Move everything to 1.6, take 2 (was: Re: I can't make a release ...)
First: +1 for 1.6 minimum. Second: I feel we need to take a more strategic look at java in general and plugin mechanics & dependencies in particular. 1.6 is deprecated since a few years - and while its bytecode runs fine on a JDK 8 runtime, any implicit dependencies and internal reflection magic relies on the horrible fact that the classpath is global and anything is accessible. This is not the case (or should not be the case) when running on a Java 9 runtime. As I'm sure you are aware, attempting to run maven and its plugins in an OSGi environment is a rather complex, and currently rather futile, exercise due to the modularized nature of the classloader as well as the runtime in general. While there are certainly differences between OSGi and Java 9 as far as the runtime and classloading mechanics go, the similarities in modularization are decently clear. So ... how do we ensure that our plugins can work in a JDK 9 runtime environment (in addition to JDK 6 - 8 RTs)? Do we create a shared utility to generate correct module-info.java files? What are your thoughts on the upcoming - substantially bigger - change when we need to be compliant with the module mechanics of Java 9? 2014-12-24 14:20 GMT+01:00 Kristian Rosenvold : > >Oops. Snappy contains 1.6 java bytecode, which breaks the build on maven > plugins. We need to upgrade to 1.6; I'm taking this to the mailing list :) > > Last time discussed this we established a consensus to establish 3.0.5 > (maybe 3.0.6) as a minimum baseline for the 3.x range of plugins. > > This 3.0.X has a 1.5 java requirement. The problem is that *everyone* > is moving to 1.6 and it's getting increasingly hard to maintain a 1.5 > code base. As an example, I have been moving code to apache commons, > but we're basically unable to use this effort because commons is now > 1.6. alternately I need to backport the code in a > "source-level-shading", but these things are getting silly. > > I propose the following: > > Make the 3.x line of plugins java 1.6+ only. > Release all shared utilities in 1.6 versions in the 3.x version range. > 3.0.X maven versions stay "forever" on the 2.x line of plugins and jdk 1.5. > The most recent core version moves defaults to the 3.x range of plugins. > The parent poms migrate to 3.x range some time in the near future. > > Keeping 3.0.x fixes to a minuimum (and "critical" stuff) only, will > ensure that we can still stay 1.5 compatible here. > > > Kristian > > 2014-12-24 13:52 GMT+01:00 Benson Margulies : > > I don't have access to push a plexus-archiver release, could you > > please do the honors. > > > > Also, looks like my splitting job left some work behind in terms of > > the parent pom. > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > -- -- +==+ | Bästa hälsningar, | [sw. "Best regards"] | | Lennart Jörelid | EAI Architect & Integrator | | jGuru Europe AB | Mölnlycke - Kista | | Email: l...@jguru.se | URL: www.jguru.se | Phone | (skype):jgurueurope | (intl): +46 708 507 603 | (domestic): 0708 - 507 603 +==+
Re: [DISCUSS] Move everything to 1.6, take 2 (was: Re: I can't make a release ...)
+1. jdk 1.6 is EOL-ed for some time (Feb 2013) already and even 1.7 will be EOL-ed in April 2015.. I would suggest moving straight to 1.7 but I guess that's been already discussed. Milos On Thu, Dec 25, 2014 at 7:54 AM, Robert Scholte wrote: > +1, would also make testing with JDK9 easier, although I've already found > a good solution for that. > > Robert > > Op Wed, 24 Dec 2014 14:20:06 +0100 schreef Kristian Rosenvold < > krosenv...@apache.org>: > > > Oops. Snappy contains 1.6 java bytecode, which breaks the build on maven >>> plugins. We need to upgrade to 1.6; I'm taking this to the mailing list :) >>> >> >> Last time discussed this we established a consensus to establish 3.0.5 >> (maybe 3.0.6) as a minimum baseline for the 3.x range of plugins. >> >> This 3.0.X has a 1.5 java requirement. The problem is that *everyone* >> is moving to 1.6 and it's getting increasingly hard to maintain a 1.5 >> code base. As an example, I have been moving code to apache commons, >> but we're basically unable to use this effort because commons is now >> 1.6. alternately I need to backport the code in a >> "source-level-shading", but these things are getting silly. >> >> I propose the following: >> >> Make the 3.x line of plugins java 1.6+ only. >> Release all shared utilities in 1.6 versions in the 3.x version range. >> 3.0.X maven versions stay "forever" on the 2.x line of plugins and jdk >> 1.5. >> The most recent core version moves defaults to the 3.x range of plugins. >> The parent poms migrate to 3.x range some time in the near future. >> >> Keeping 3.0.x fixes to a minuimum (and "critical" stuff) only, will >> ensure that we can still stay 1.5 compatible here. >> >> >> Kristian >> >> 2014-12-24 13:52 GMT+01:00 Benson Margulies : >> >>> I don't have access to push a plexus-archiver release, could you >>> please do the honors. >>> >>> Also, looks like my splitting job left some work behind in terms of >>> the parent pom. >>> >> >> - >> 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 > >
Re: [DISCUSS] Move everything to 1.6, take 2 (was: Re: I can't make a release ...)
Here's what I don't understand. I can see why people need to keep building apps that run on antediluvian version. I can't see why it's such a problem for a tool, such as Maven, to require 1.7. Who are we accomodating by the current policy, or even the 1.6 plan? Meanwhile, it seems to me that we don't need a complex system of releases. There will be no new 3.0.x releases except for some sort of exceptional event. If we simply open up everything except the 3.0.x branch of the core to 1.6 or 1.7, then the worst that happens is, in the event of a security issue out in a component or a plugin, someone has to make a branch from the last 1.5-compatible release to make the fix. On Wed, Dec 24, 2014 at 5:02 PM, Milos Kleint wrote: > +1. > > jdk 1.6 is EOL-ed for some time (Feb 2013) already and even 1.7 will be > EOL-ed in April 2015.. > > I would suggest moving straight to 1.7 but I guess that's been already > discussed. > > Milos > > On Thu, Dec 25, 2014 at 7:54 AM, Robert Scholte > wrote: > >> +1, would also make testing with JDK9 easier, although I've already found >> a good solution for that. >> >> Robert >> >> Op Wed, 24 Dec 2014 14:20:06 +0100 schreef Kristian Rosenvold < >> krosenv...@apache.org>: >> >> >> Oops. Snappy contains 1.6 java bytecode, which breaks the build on maven plugins. We need to upgrade to 1.6; I'm taking this to the mailing list :) >>> >>> Last time discussed this we established a consensus to establish 3.0.5 >>> (maybe 3.0.6) as a minimum baseline for the 3.x range of plugins. >>> >>> This 3.0.X has a 1.5 java requirement. The problem is that *everyone* >>> is moving to 1.6 and it's getting increasingly hard to maintain a 1.5 >>> code base. As an example, I have been moving code to apache commons, >>> but we're basically unable to use this effort because commons is now >>> 1.6. alternately I need to backport the code in a >>> "source-level-shading", but these things are getting silly. >>> >>> I propose the following: >>> >>> Make the 3.x line of plugins java 1.6+ only. >>> Release all shared utilities in 1.6 versions in the 3.x version range. >>> 3.0.X maven versions stay "forever" on the 2.x line of plugins and jdk >>> 1.5. >>> The most recent core version moves defaults to the 3.x range of plugins. >>> The parent poms migrate to 3.x range some time in the near future. >>> >>> Keeping 3.0.x fixes to a minuimum (and "critical" stuff) only, will >>> ensure that we can still stay 1.5 compatible here. >>> >>> >>> Kristian >>> >>> 2014-12-24 13:52 GMT+01:00 Benson Margulies : >>> I don't have access to push a plexus-archiver release, could you please do the honors. Also, looks like my splitting job left some work behind in terms of the parent pom. >>> >>> - >>> 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 >> >> - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] Move everything to 1.6, take 2 (was: Re: I can't make a release ...)
I assume that anyone wishing for 1.7 will also accept 1.6. I would really just like to establish a consensus that we're leaving 1.5 in favour of 1.6. We have a certain tradition for being "last" to leave jdk versions and I don't really mind this. It *does* become a problem when it makes practical development of maven and their core plugins a problem, which is where we're at. So my key argument is really about making the pain smaller, not about using a cool jdk version (which is 1.8 anyway, 1.7 is boring). apache-commons just opened up for all apache committers so we can basically move lots of our code to "better" homes if we care to. Kristian 2014-12-24 23:08 GMT+01:00 Benson Margulies : > Here's what I don't understand. I can see why people need to keep > building apps that run on antediluvian version. I can't see why it's > such a problem for a tool, such as Maven, to require 1.7. Who are we > accomodating by the current policy, or even the 1.6 plan? > > Meanwhile, it seems to me that we don't need a complex system of > releases. There will be no new 3.0.x releases except for some sort of > exceptional event. If we simply open up everything except the 3.0.x > branch of the core to 1.6 or 1.7, then the worst that happens is, in > the event of a security issue out in a component or a plugin, someone > has to make a branch from the last 1.5-compatible release to make the > fix. > > > On Wed, Dec 24, 2014 at 5:02 PM, Milos Kleint wrote: >> +1. >> >> jdk 1.6 is EOL-ed for some time (Feb 2013) already and even 1.7 will be >> EOL-ed in April 2015.. >> >> I would suggest moving straight to 1.7 but I guess that's been already >> discussed. >> >> Milos >> >> On Thu, Dec 25, 2014 at 7:54 AM, Robert Scholte >> wrote: >> >>> +1, would also make testing with JDK9 easier, although I've already found >>> a good solution for that. >>> >>> Robert >>> >>> Op Wed, 24 Dec 2014 14:20:06 +0100 schreef Kristian Rosenvold < >>> krosenv...@apache.org>: >>> >>> >>> Oops. Snappy contains 1.6 java bytecode, which breaks the build on maven > plugins. We need to upgrade to 1.6; I'm taking this to the mailing list :) > Last time discussed this we established a consensus to establish 3.0.5 (maybe 3.0.6) as a minimum baseline for the 3.x range of plugins. This 3.0.X has a 1.5 java requirement. The problem is that *everyone* is moving to 1.6 and it's getting increasingly hard to maintain a 1.5 code base. As an example, I have been moving code to apache commons, but we're basically unable to use this effort because commons is now 1.6. alternately I need to backport the code in a "source-level-shading", but these things are getting silly. I propose the following: Make the 3.x line of plugins java 1.6+ only. Release all shared utilities in 1.6 versions in the 3.x version range. 3.0.X maven versions stay "forever" on the 2.x line of plugins and jdk 1.5. The most recent core version moves defaults to the 3.x range of plugins. The parent poms migrate to 3.x range some time in the near future. Keeping 3.0.x fixes to a minuimum (and "critical" stuff) only, will ensure that we can still stay 1.5 compatible here. Kristian 2014-12-24 13:52 GMT+01:00 Benson Margulies : > I don't have access to push a plexus-archiver release, could you > please do the honors. > > Also, looks like my splitting job left some work behind in terms of > the parent pom. > - 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 >>> >>> > > - > 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
Need Jira account
Can some one tell me how do I get a Jira account for creating and submitting patches ? the website says contact your Jira administrators …. I am not sure who is the Jira administrator. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
RE: Need Jira account
what is "the failure" you are experiencing? which maven plugin are you submitting a patch for? what is the maven version, OS and JDK your patch is targetting? Martin __ > From: raghavendra.vai...@gmail.com > Subject: Need Jira account > Date: Thu, 25 Dec 2014 08:10:05 +0530 > To: dev@maven.apache.org > > Can some one tell me how do I get a Jira account for creating and submitting > patches ? the website says contact your Jira administrators …. I am not sure > who is the Jira administrator. > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org >
Re: Need Jira account
Where did you see that? For codehaus, you interact with xircles (that's where most of the Maven jira project are). On Wed, Dec 24, 2014 at 9:40 PM, Raghavendra Vaidya wrote: > Can some one tell me how do I get a Jira account for creating and submitting > patches ? the website says contact your Jira administrators …. I am not sure > who is the Jira administrator. > - > 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
Re: Need Jira account
I am just about getting started to contribute to maven … bear with my stupid questions : I am trying to submit a patch for this bug : MavenMNG-5721 looks like I need a Jira account to do the same … hence the request. On Dec 25, 2014, at 8:16 AM, Martin Gainty wrote: > > what is "the failure" you are experiencing? > which maven plugin are you submitting a patch for? > what is the maven version, OS and JDK your patch is targetting? > > Martin > __ > > > >> From: raghavendra.vai...@gmail.com >> Subject: Need Jira account >> Date: Thu, 25 Dec 2014 08:10:05 +0530 >> To: dev@maven.apache.org >> >> Can some one tell me how do I get a Jira account for creating and submitting >> patches ? the website says contact your Jira administrators …. I am not sure >> who is the Jira administrator. >> - >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> >
Re: Need Jira account
I saw the bug description @ this URL : http://jira.codehaus.org/browse/MNG-4687?jql=project%20%3D%20MNG%20AND%20status%20%3D%20Open%20ORDER%20BY%20priority%20ASC%2C%20key%20ASC On Dec 25, 2014, at 8:38 AM, Benson Margulies wrote: > Where did you see that? For codehaus, you interact with xircles > (that's where most of the Maven jira project are). > > On Wed, Dec 24, 2014 at 9:40 PM, Raghavendra Vaidya > wrote: >> Can some one tell me how do I get a Jira account for creating and submitting >> patches ? the website says contact your Jira administrators …. I am not sure >> who is the Jira administrator. >> - >> 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 >
Re: [DISCUSS] Move everything to 1.6, take 2 (was: Re: I can't make a release ...)
+1 Gary Original message From: Benson Margulies Date:12/24/2014 17:08 (GMT-05:00) To: Maven Developers List Cc: Subject: Re: [DISCUSS] Move everything to 1.6, take 2 (was: Re: I can't make a release ...) Here's what I don't understand. I can see why people need to keep building apps that run on antediluvian version. I can't see why it's such a problem for a tool, such as Maven, to require 1.7. Who are we accomodating by the current policy, or even the 1.6 plan? Meanwhile, it seems to me that we don't need a complex system of releases. There will be no new 3.0.x releases except for some sort of exceptional event. If we simply open up everything except the 3.0.x branch of the core to 1.6 or 1.7, then the worst that happens is, in the event of a security issue out in a component or a plugin, someone has to make a branch from the last 1.5-compatible release to make the fix. On Wed, Dec 24, 2014 at 5:02 PM, Milos Kleint wrote: > +1. > > jdk 1.6 is EOL-ed for some time (Feb 2013) already and even 1.7 will be > EOL-ed in April 2015.. > > I would suggest moving straight to 1.7 but I guess that's been already > discussed. > > Milos > > On Thu, Dec 25, 2014 at 7:54 AM, Robert Scholte > wrote: > >> +1, would also make testing with JDK9 easier, although I've already found >> a good solution for that. >> >> Robert >> >> Op Wed, 24 Dec 2014 14:20:06 +0100 schreef Kristian Rosenvold < >> krosenv...@apache.org>: >> >> >> Oops. Snappy contains 1.6 java bytecode, which breaks the build on maven plugins. We need to upgrade to 1.6; I'm taking this to the mailing list :) >>> >>> Last time discussed this we established a consensus to establish 3.0.5 >>> (maybe 3.0.6) as a minimum baseline for the 3.x range of plugins. >>> >>> This 3.0.X has a 1.5 java requirement. The problem is that *everyone* >>> is moving to 1.6 and it's getting increasingly hard to maintain a 1.5 >>> code base. As an example, I have been moving code to apache commons, >>> but we're basically unable to use this effort because commons is now >>> 1.6. alternately I need to backport the code in a >>> "source-level-shading", but these things are getting silly. >>> >>> I propose the following: >>> >>> Make the 3.x line of plugins java 1.6+ only. >>> Release all shared utilities in 1.6 versions in the 3.x version range. >>> 3.0.X maven versions stay "forever" on the 2.x line of plugins and jdk >>> 1.5. >>> The most recent core version moves defaults to the 3.x range of plugins. >>> The parent poms migrate to 3.x range some time in the near future. >>> >>> Keeping 3.0.x fixes to a minuimum (and "critical" stuff) only, will >>> ensure that we can still stay 1.5 compatible here. >>> >>> >>> Kristian >>> >>> 2014-12-24 13:52 GMT+01:00 Benson Margulies : >>> I don't have access to push a plexus-archiver release, could you please do the honors. Also, looks like my splitting job left some work behind in terms of the parent pom. >>> >>> - >>> 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 >> >> - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Need Jira account
It's not obvious but you click in the top left on the xircles icon and sign up there. If you want your first patch should be to make sure the documentation is up to date for someone new to the project!
