On Sun, Nov 2, 2014 at 10:41 AM, Hervé BOUTEMY wrote:
> Le dimanche 2 novembre 2014 09:51:14 Dennis Lundberg a écrit :
>> Looking into this I'm a bit puzzled. Version 1.1-SNAPSHOT of
>> maven-toolchains-plugin bind by default to the validate phase, but it
>> doesn't run unless I specify an executi
On Sat, Nov 1, 2014 at 10:41 AM, Dennis Lundberg wrote:
> Hi,
>
> I'm just starting to look at toolchains, with the goal of using Java 5 for
> jobs in latest Jenkins LTS version.
I have this working now.
> Here are a few reflections from what I've read so far.
>
> Great to have a toolchains refe
Le dimanche 2 novembre 2014 09:51:14 Dennis Lundberg a écrit :
> Looking into this I'm a bit puzzled. Version 1.1-SNAPSHOT of
> maven-toolchains-plugin bind by default to the validate phase, but it
> doesn't run unless I specify an execution for it. If I have it
> specified in build/plugins with co
Op Sat, 01 Nov 2014 14:56:56 +0100 schreef Hervé BOUTEMY
:
Le samedi 1 novembre 2014 23:45:32 Mark Derricutt a écrit :
On 1 Nov 2014, at 22:41, Dennis Lundberg wrote:
> so that we can update it quickly when new plugins support it. The
others
> should just link to that page. The current inf
Le samedi 1 novembre 2014 10:41:40 Dennis Lundberg a écrit :
> The xsd used needs to be added
> to the main Maven site in the xsd directory.
+1 didn't see it wasn't there
I just did it: http://maven.apache.org/xsd/
>
> There are currently 3 wiki pages used or referenced. One Codehaus page [1]
> t
Le samedi 1 novembre 2014 23:45:32 Mark Derricutt a écrit :
> On 1 Nov 2014, at 22:41, Dennis Lundberg wrote:
> > so that we can update it quickly when new plugins support it. The others
> > should just link to that page. The current info on supporting
+1
this could be the mini guide, transforming
On 1 Nov 2014, at 22:41, Dennis Lundberg wrote:
> so that we can update it quickly when new plugins support it. The others
> should just link to that page. The current info on supporting
For reference - my clojure-maven-plugin has supported it for ages now, and I
think I rolled that over onto m
Hi,
I'm just starting to look at toolchains, with the goal of using Java 5 for
jobs in latest Jenkins LTS version.
Here are a few reflections from what I've read so far.
Great to have a toolchains reference. It is in core site where it belongs.
It needs to be expanded with more explanations thou
I started improving documentation on toochains:
- in core [1]
- in m-toolchains-p [2]
feedback appreciated
next step is documenting how to create a custom toolchain: any pointer to some
working extra-toolchain (or even archetype, let's dream)?
Regards,
Hervé
[1] http://maven.apache.org/ref/3-
-1 on changing the JDK for M3.0.x
+1 for removal of the M3.1.x download from the mainpage
Op Thu, 30 Oct 2014 20:23:28 +0100 schreef Stephen Connolly
:
I am also -1 on changing the JDK for an existing line.
I seem to remember communicating that we would have at least a minor
version bump i
I am also -1 on changing the JDK for an existing line.
I seem to remember communicating that we would have at least a minor
version bump if we were upping the JVM requirement when communicating the
JVM version bump for 3.2.x
On Thursday, October 30, 2014, Dennis Lundberg wrote:
> I am -1 on c
I am -1 on changing JDK level in a patch version, either in core or another
one of our products. That is bad form, since the release is not backwards
compatible.
--
Dennis Lundberg
Den 29 okt 2014 08:04 skrev "Kristian Rosenvold" <
kristian.rosenv...@gmail.com>:
> Personally I think we could cons
+1 to switching to JDK 6 and for dropping the 3.1.x line.
Regards
Mirko
--
Sent from my mobile
On Oct 29, 2014 8:04 AM, "Kristian Rosenvold"
wrote:
> Personally I think we could consider releasing 3.0.6 with jdk6
> requirement and leave jdk5 altogether. And that's for plugins too :)
>
> Kristia
+1 to JDK 5 for Maven 3.0.6: will avoid confusion
for the "supported" vs "partially supported":
AFAIK, the only fully supported version has always been the latest, and only
the latest: we can once again explain it
then is 3.1.1"supported with security issues"? Do you plan to release 3.1.2
with
Le jeudi 30 octobre 2014 10:08:19 Mark Derricutt a écrit :
> On 29 Oct 2014, at 19:33, Baptiste Mathus wrote:
> > Didn't double checked, but IIRC 3.1.1 still uses JDK5. 3.2.x uses JDK 6.
> > That may be a change you want to have in mind, though I personally don't
> > care about JDK 5.
>
> Another
On 29 Oct 2014, at 19:33, Baptiste Mathus wrote:
> Didn't double checked, but IIRC 3.1.1 still uses JDK5. 3.2.x uses JDK 6.
> That may be a change you want to have in mind, though I personally don't
> care about JDK 5.
Another +1 for promoting the use of toolchains.
--
Mark Derricutt
http://www
Am 2014-10-29 um 03:24 schrieb Hervé BOUTEMY:
we currently propose 3 versions: 3.0.5, 3.1.1 and 3.2.3
which suppose we may release 3.0.6, 3.1.2 and 3.2.4 in the future
I see why we would release 3.0.6: Aether change force some users to stay to
3.0.x, and I started to define some backports I'd li
Hi,
On 10/29/14 7:33 AM, Baptiste Mathus wrote:
no outstanding change in 3.2.x that blocks 3.1.x users from upgrading to
3.2.x, isn't it?
Didn't double checked, but IIRC 3.1.1 still uses JDK5. 3.2.x uses JDK 6.
That may be a change you want to have in mind, though I personally don't
care about
+1
On Wednesday, October 29, 2014, Hervé BOUTEMY wrote:
> we currently propose 3 versions: 3.0.5, 3.1.1 and 3.2.3
> which suppose we may release 3.0.6, 3.1.2 and 3.2.4 in the future
>
> I see why we would release 3.0.6: Aether change force some users to stay to
> 3.0.x, and I started to define s
+1
--
Olivier
On 29 Oct 2014 18:04, "Kristian Rosenvold"
wrote:
> Personally I think we could consider releasing 3.0.6 with jdk6
> requirement and leave jdk5 altogether. And that's for plugins too :)
>
> Kristian
>
>
> 2014-10-29 7:33 GMT+01:00 Baptiste Mathus :
> >> no outstanding change in 3.2
Personally I think we could consider releasing 3.0.6 with jdk6
requirement and leave jdk5 altogether. And that's for plugins too :)
Kristian
2014-10-29 7:33 GMT+01:00 Baptiste Mathus :
>> no outstanding change in 3.2.x that blocks 3.1.x users from upgrading to
> 3.2.x, isn't it?
>
> Didn't doubl
> no outstanding change in 3.2.x that blocks 3.1.x users from upgrading to
3.2.x, isn't it?
Didn't double checked, but IIRC 3.1.1 still uses JDK5. 3.2.x uses JDK 6.
That may be a change you want to have in mind, though I personally don't
care about JDK 5.
+1 indeed.
Cheers
Le mer. 29 oct. 2014
+1
29. Okt. 2014 03:24 skrev "Hervé BOUTEMY" følgende:
> we currently propose 3 versions: 3.0.5, 3.1.1 and 3.2.3
> which suppose we may release 3.0.6, 3.1.2 and 3.2.4 in the future
>
> I see why we would release 3.0.6: Aether change force some users to stay to
> 3.0.x, and I started to define som
+1 (non-binding)
Gary
On Tue, Oct 28, 2014 at 10:24 PM, Hervé BOUTEMY
wrote:
> we currently propose 3 versions: 3.0.5, 3.1.1 and 3.2.3
> which suppose we may release 3.0.6, 3.1.2 and 3.2.4 in the future
>
> I see why we would release 3.0.6: Aether change force some users to stay to
> 3.0.x, and
+1
On Wed, Oct 29, 2014 at 10:22 AM, Manfred Moser
wrote:
> +1 to that. Good idea imho..
>
> manfred
>
> Hervé BOUTEMY wrote on 28.10.2014 19:24:
>
> > we currently propose 3 versions: 3.0.5, 3.1.1 and 3.2.3
> > which suppose we may release 3.0.6, 3.1.2 and 3.2.4 in the future
> >
> > I see why
+1 to that. Good idea imho..
manfred
Hervé BOUTEMY wrote on 28.10.2014 19:24:
> we currently propose 3 versions: 3.0.5, 3.1.1 and 3.2.3
> which suppose we may release 3.0.6, 3.1.2 and 3.2.4 in the future
>
> I see why we would release 3.0.6: Aether change force some users to stay to
> 3.0.x,
we currently propose 3 versions: 3.0.5, 3.1.1 and 3.2.3
which suppose we may release 3.0.6, 3.1.2 and 3.2.4 in the future
I see why we would release 3.0.6: Aether change force some users to stay to
3.0.x, and I started to define some backports I'd like to put in it [1]
But I don't see why we wou
27 matches
Mail list logo
