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!
+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 ke
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 xirc
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 failur
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 J
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
__
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...@ma
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
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 do
+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, alt
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, 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 taki
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-Surefi
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
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/m
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 th
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 o
+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 establishe
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
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+
+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
R
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
SS
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
> plu
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 app
>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.
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/
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
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 usin
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/maste
29 matches
Mail list logo
