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
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
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
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
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
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
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 krosenv...@apache.org wrote:
Oops. Snappy contains 1.6 java bytecode, which breaks the
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
+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
Hi,
We solved 13 issues:
https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10541version=20814
There are still a couple of issues left in JIRA:
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
+1
(Hoping we can get up to 1.7 soon too)
On Wednesday, 24 December 2014, Kristian Rosenvold krosenv...@apache.org
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
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
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
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...
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
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:
+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
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
+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 rfscho...@apache.org
wrote:
+1, would also make testing
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
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
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:
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
__
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
raghavendra.vai...@gmail.com wrote:
Can some one tell me how do I get a Jira account for creating and submitting
patches ? the
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 mgai...@hotmail.com wrote:
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 bimargul...@gmail.com wrote:
Where did you see that? For codehaus,
+1
Gary
div Original message /divdivFrom: Benson Margulies
bimargul...@gmail.com /divdivDate:12/24/2014 17:08 (GMT-05:00)
/divdivTo: Maven Developers List dev@maven.apache.org /divdivCc:
/divdivSubject: Re: [DISCUSS] Move everything to 1.6, take 2 (was: Re: I
can't make a
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!
29 matches
Mail list logo
