For all of those who asked to access to replies (I didn't see they were
protected) I'll find a solution to share these results when the survey will
be really started/published.
On Tue, Jul 16, 2013 at 8:19 AM, Arnaud Héritier wrote:
> Good point. I updated the survey to tell it is the Oracle JDK
I'm not in favor to recreate a maven-3.1 tag to avoid confusions and we
need to keep the maven-3.1.0 which was used in the release
But I agree to improve our release/RCs/Staging process as far as it remains
as automated as possible.
It is already complexe to release stuffs on Apache side and I don'
Good point. I updated the survey to tell it is the Oracle JDK EOL
Survey :
https://docs.google.com/forms/d/1Jqxq2KgSricwS7YV7pmWvHA8m7_TE7c8JhusugPmGW4/viewform
Replies :
https://docs.google.com/forms/d/1Jqxq2KgSricwS7YV7pmWvHA8m7_TE7c8JhusugPmGW4/viewanalytics
On Tue, Jul 16, 2013 at 8:06 AM, Ch
Michael's point about omiting the trailing .0 is valid, and introducing it
now does not follow the established convention.
Is it going to be cleaned up?
-Chris
On Tue, Jul 16, 2013 at 6:42 AM, Arnaud Héritier wrote:
> lol
>
>
> On Mon, Jul 15, 2013 at 10:40 PM, Hervé BOUTEMY >wrote:
>
> > uh, a
As long as surefire can fork down to 1.5 and as long as tool chains can
compile with 1.5, the only issue I can see is if the development
environments where these older JVMs are running do not have newer JDKs
available also.
This is the same issue we face in the Jenkins project, were we are
(consid
+1 to ensure that we have a good solution (toolchains) to continue to keep
a compatibility with old Java builds.
Like always, upgrading the prerequisite of the core is less annoying than
the one in plugins.
Users can always keep an old core (and many of them will do it as far as
new core versions a
On Tue, Jul 16, 2013 at 10:07 AM, Arnaud Héritier wrote:
> Hi,
>
> Java 6 EOL was in feb and Maven and its plugins are always compatible
>
Oracle Java 6 was EOL'd.
IBM Java 6 was, and is not due to be for a few more years. They even
*extended* 1.5's life for a year. Sept this year, I think.
-
Given that Oracle have stated they will be more aggressive in forcing
people to upgrade, eg -target (and I think -source too) will not got all
the way down to 1.2 any more from JDK8 IIRC, we will need to sort out a few
things:
- is toolchains the way to go?
- have we good test coverage with toolc
I would prefer going from JDK5 to 7 immediately as well, old JDK means
usage of old tools.
Regards Mirko
--
Sent from my mobile
On Jul 16, 2013 7:07 AM, "Stephen Connolly"
wrote:
> So what I am hearing is that until we bump core to require JDK6 (or 7) then
> logback is the only runner from a te
On Jul 16, 2013 2:08 AM, "Arnaud Héritier" wrote:
>
> Hi,
>
> Java 6 EOL was in feb and Maven and its plugins are always compatible
> with Java 5 (And probably various plugins with Java 4).
> Couldn't it be interesting to see which JDKs our users are using to see
> how we can schedule the end
So what I am hearing is that until we bump core to require JDK6 (or 7) then
logback is the only runner from a technical point of view (never mind that
log4j2 is still not GA)
OTOH I would be interested in bumping JDK all the way to 7 if we were happy
that toolchains is good enough and we had tests
Hello,
I have a mojo with the following :
@Parameter( readonly = true, defaultValue = "${repositorySystemSession}" )
private RepositorySystemSession repoSession;
public void execute() throws MojoExecutionException {
...
DefaultDependencyResolutionRequest dependencyResolutionReque
On Mon, Jul 15, 2013 at 8:07 PM, Arnaud Héritier wrote:
> Hi,
>
> Java 6 EOL was in feb and Maven and its plugins are always compatible
> with Java 5 (And probably various plugins with Java 4).
> Couldn't it be interesting to see which JDKs our users are using to see
> how we can schedule the
Hi,
Java 6 EOL was in feb and Maven and its plugins are always compatible
with Java 5 (And probably various plugins with Java 4).
Couldn't it be interesting to see which JDKs our users are using to see
how we can schedule the end of support of Java 5 (and more). Perhaps a
removal of Java 5 sup
Commit
Then
Review
On 16 July 2013 00:15, Barrie Treloar wrote:
> On 16 July 2013 08:39, Stephen Connolly
> wrote:
>> Remember folks, we are CTR not RTC so we shouldn't be holding up getting
>> stuff done
>
> I think I should be able to grok that, but google isn't helping me.
> Are you making u
Hi
FYI I rebased both branches on current master :
*
https://git-wip-us.apache.org/repos/asf?p=maven.git;a=shortlog;h=refs/heads/slf4j-log4j2
*
https://git-wip-us.apache.org/repos/asf?p=maven.git;a=shortlog;h=refs/heads/slf4j-logback
With all work done by Herve both branches have only one intere
On 16 July 2013 08:39, Stephen Connolly wrote:
> Remember folks, we are CTR not RTC so we shouldn't be holding up getting
> stuff done
I think I should be able to grok that, but google isn't helping me.
Are you making up your own acronyms :)
--
Remember folks, we are CTR not RTC so we shouldn't be holding up getting
stuff done
On Monday, 15 July 2013, Arnaud Héritier wrote:
> I think we won't debate a lot :-)
> Pushed
>
>
> On Mon, Jul 15, 2013 at 10:02 PM, Hervé BOUTEMY
>
> >wrote:
>
> > +1
> >
> > Regards,
> >
> > Hervé
> >
> > Le l
These are not my commits in facts. I'm updating (rebasing) two working
branches and our Git@ASF is notifying us about all changes from ... (I have
a doubt from where how it seems to be far)
On Tue, Jul 16, 2013 at 12:34 AM, sebb wrote:
> On 15 July 2013 23:26, wrote:
> > Add ASL license heade
On 15 July 2013 23:26, wrote:
> Code cleanup - Maven requires Java 5+ : Replace for and while loops by for
> each
>
>
> Project: http://git-wip-us.apache.org/repos/asf/maven/repo
> Commit: http://git-wip-us.apache.org/repos/asf/maven/commit/d92746dc
> Tree: http://git-wip-us.apache.org/repos/asf
On 15 July 2013 23:26, wrote:
> Code cleanup - Maven requires Java 5+ : Remove unnecessary boxing
Not sure that's a good idea.
I've found quite a few bugs related to boxing in other projects.
For example, auto-unboxing a field that can sometimes be null may
cause an unexpected NPE; it's not al
On 15 July 2013 23:26, wrote:
> fix typo and use names from their respective POMs
>
>
> Project: http://git-wip-us.apache.org/repos/asf/maven/repo
> Commit: http://git-wip-us.apache.org/repos/asf/maven/commit/2fea34f7
> Tree: http://git-wip-us.apache.org/repos/asf/maven/tree/2fea34f7
> Diff: http
On 15 July 2013 23:26, wrote:
> Replace package.html with package-info.java
Warning: this will cause unnecessary compilations unless/until
https://jira.codehaus.org/browse/MCOMPILER-205 is fixed.
-
To unsubscribe, e-mail: dev-u
On 15 July 2013 23:26, wrote:
> Add ASL license header
>
Trivial nit: it's the AL header, i.e. Apache License header.
It's not a Software license per se.
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additiona
I think we won't debate a lot :-)
Pushed
On Mon, Jul 15, 2013 at 10:02 PM, Hervé BOUTEMY wrote:
> +1
>
> Regards,
>
> Hervé
>
> Le lundi 15 juillet 2013 21:02:37 Arnaud Héritier a écrit :
> > Hi all,
> >
> > Now that 3.1 is out we'll have to think to the future.
> > I saw on twitter that Jas
lol
On Mon, Jul 15, 2013 at 10:40 PM, Hervé BOUTEMY wrote:
> uh, another bot?
>
> Le lundi 15 juillet 2013 22:28:26 Fred Cooke a écrit :
> > What was the hash for future reference? This is why sebb is sooo right.
> If
> > you have a unique coordinate, you're good for life, no matter what gets
>
uh, another bot?
Le lundi 15 juillet 2013 22:28:26 Fred Cooke a écrit :
> What was the hash for future reference? This is why sebb is sooo right. If
> you have a unique coordinate, you're good for life, no matter what gets
> done to the SCM. (more or less)
>
> On Mon, Jul 15, 2013 at 9:53 PM, Arn
maven 3.1 : a47ef06832bff888928c66c525e18439b7a3c0f3 (June 23rd)
maven 3.1.0 : 893ca28a1da9d5f51ac03827af98bb730128f9f2 (June 28th)
On Mon, Jul 15, 2013 at 10:28 PM, Fred Cooke wrote:
> What was the hash for future reference? This is why sebb is sooo right. If
> you have a unique coordinate, yo
GitHub user mfriedenhagen opened a pull request:
https://github.com/apache/maven-enforcer/pull/5
MENFORCER-160 Add levels ERROR and WARN to enforcer rules
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/mfriedenhagen/maven-enforc
What was the hash for future reference? This is why sebb is sooo right. If
you have a unique coordinate, you're good for life, no matter what gets
done to the SCM. (more or less)
On Mon, Jul 15, 2013 at 9:53 PM, Arnaud Héritier wrote:
> done
>
>
> On Mon, Jul 15, 2013 at 9:36 PM, Jason van Zyl w
+1
Regards,
Hervé
Le lundi 15 juillet 2013 21:02:37 Arnaud Héritier a écrit :
> Hi all,
>
> Now that 3.1 is out we'll have to think to the future.
> I saw on twitter that Jason has already many ideas to share.
> For now the version in master is 3.1-SNAPSHOT.
> Do we bump it to 3.2-SNAPS
done
On Mon, Jul 15, 2013 at 9:36 PM, Jason van Zyl wrote:
> Sure, drop the older one.
>
> On Jul 15, 2013, at 2:57 PM, Arnaud Héritier wrote:
>
> > Hi Jason,
> >
> > It seems we have 2 tags in Git for maven 3.1 : maven-3.1 and maven-3.1.0
> > I think that the the right one to keep is the se
Github user imod closed the pull request at:
https://github.com/apache/maven-scm/pull/5
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Agreed, but as discussed the nicer appaoach would be to use tags in the
form 3.1.0-0...N and then point the final tag at the hash pointed to by the
successful spin's tag, if you insist on this whole respinning thing.
On Mon, Jul 15, 2013 at 9:36 PM, Jason van Zyl wrote:
> Sure, drop the older on
Sure, drop the older one.
On Jul 15, 2013, at 2:57 PM, Arnaud Héritier wrote:
> Hi Jason,
>
> It seems we have 2 tags in Git for maven 3.1 : maven-3.1 and maven-3.1.0
> I think that the the right one to keep is the second one (893ca28 - 28th
> June) ?
> I suppose we need to drop the old mave
On Mon, Jul 15, 2013 at 9:04 PM, Fred Cooke wrote:
> 10/10 to Jason for not reusing the existing tag name! <3
>
I didn't say I was against to use different tags for each release attempt
:-)
But what do we do with old tags ?
>From my point of view we have to remove them to avoid confusions
especi
Am 2013-07-15 20:57, schrieb Arnaud Héritier:
Hi Jason,
It seems we have 2 tags in Git for maven 3.1 : maven-3.1 and maven-3.1.0
I think that the the right one to keep is the second one (893ca28 - 28th
June) ?
I suppose we need to drop the old maven-3.1 tag ?
Cheers,
Isn't the conven
10/10 to Jason for not reusing the existing tag name! <3
On Mon, Jul 15, 2013 at 8:57 PM, Arnaud Héritier wrote:
> Hi Jason,
>
> It seems we have 2 tags in Git for maven 3.1 : maven-3.1 and maven-3.1.0
> I think that the the right one to keep is the second one (893ca28 - 28th
> June) ?
> I
Hi all,
Now that 3.1 is out we'll have to think to the future.
I saw on twitter that Jason has already many ideas to share.
For now the version in master is 3.1-SNAPSHOT.
Do we bump it to 3.2-SNAPSHOT ?
(We can always create a 3.1.x branch later from the tag if we need some
bugfix releas
Hi Jason,
It seems we have 2 tags in Git for maven 3.1 : maven-3.1 and maven-3.1.0
I think that the the right one to keep is the second one (893ca28 - 28th
June) ?
I suppose we need to drop the old maven-3.1 tag ?
Cheers,
-
Arnaud Héritier
http://aheritier.net
Mail/GTalk: aheritier AT
40 matches
Mail list logo
