Hi,
I tried improvements on http://maven.staging.apache.org/maven-2.x-eol.html
And here are some small updates proposed to the announcement: the newest idea
is that plugins already at 3.x will switch to Maven 3 prerequisite for
plugin's version 3.5 (see compiler which should go from 3.2 to 3.5
notice that this would be a de-facto Maven versionning pattern:
2.0 (Java 1.4)/2.1(Java 1.4+changes)/2.2(Java 5)
3.0 (Java 5)/3.1(Java 5+changes)/3.2(Java 6)
then 3.2(Java 6)/3.3(Java 6+changes)/3.4(Java 7), if we announce the pattern
and do the 3.4 release something like one month later (after c
issues for 3.2.6 have already been pushed forward to 3.3.0 *before* the
Java7 decision. And that's fine by me.
As Dennis already suggested: after 3.3.0 push JDK requirement to 1.7 and
call this Maven 3.4.0
A JDK requirement has too much impact for a 3.3.1, but IMHO it's not worth
a 4.0.0
Also
@Robert
source=target=1.7 after M3.3.0? You mean 3.3.1?
A bit strange to make it in an incremental version since a user would not
imaging a fix version to break the system requirements in his CI regarding
JDK installation.
Currently the release notes for 3.2.6 is empty.
So if there's really nothi
So let's say that Dennis and I have our concerns.
The discussion about versions seems more about marketing versions.
If the current added features are minor incremental worthy AND Java
Runtime change to version 7 is also minor incremental worthy, then so be
it.
I wouldn't call 3.3.0 a dead en
On 2015-03-08 9:35, Tibor Digana wrote:
@Igor
Would you introduce trully incremental compiler with JDT?
I guess the surefire would need the interface from core or compiler to be
notified about modified tests in order to execute only those.
Incremental test execution requires full impact analys
I have a biased data point to throw into the mix:
The Jenkins project would really like to ditch support for running on Java
6. When Maven releases a version that requires Java 7, and Olivier updates
the "evil" plugin to use the new Maven dependencies, then Jenkins can force
through dropping sup
On Sat, Mar 7, 2015 at 10:04 AM, Robert Scholte wrote:
> Mercury? I guess some of it is now part of Aether,
Mercury predates Aether. It was an attempt to update the artifact apis
that was abandoned. (Unless the name is being reused as something new)
--
Le dimanche 8 mars 2015 16:17:39 Dennis Lundberg a écrit :
> On Sat, Mar 7, 2015 at 1:06 PM, Hervé BOUTEMY wrote:
> >> There is nothing stoping you from releasing 3.3.0 on Java 6 now, and
> >> 3.4.0
> >> on Java 7 in a few weeks.
> >
> > what I don't like with this plan is that it is exactly what
The breaking thing is the new prerequisite of Java 7 which would
exclude some of our users.
On Sun, Mar 8, 2015 at 12:05 AM, Igor Fedorenko wrote:
> How is this a breaking change? All plugins that worked with 3.2.5 are
> expected to work as is. All projects that built with 3.2.5 are expected
> to
Hi Igor,
In my opinion the switch to Java 7 as a prerequisite is a non-risky
thing to do, even though I still argue that we should wait till the
next release to do it.
Making use of the new Java 7 features in the code is the risky bit.
That in my book warrants a minor release bump rather that a p
On Sat, Mar 7, 2015 at 1:06 PM, Hervé BOUTEMY wrote:
>> There is nothing stoping you from releasing 3.3.0 on Java 6 now, and 3.4.0
>> on Java 7 in a few weeks.
> what I don't like with this plan is that it is exactly what happened with
> 3.1.1 then 3.2.1: we never did any bugfix for 3.1.1, 3.1.1 w
As you said, the SPI did not work well in multimodule project.
You tested SPI in Maven, so you know better than me :)
With JSR-269 with can use javax.inject:javax-inject annotations and we the
user can use non-default constructor. Imaging this in user, our processor is
sensitive only in SurefireCo
Let me re-phrase that; what are the benefits/downsides of using annotation
processors instead of SPI/plexus ?
Kristian
2015-03-08 15:43 GMT+01:00 Kristian Rosenvold
:
> i think an API makes total sense for surefire. I'm not sure about the
> merits of annotation processors vs SPI or regular ple
i think an API makes total sense for surefire. I'm not sure about the
merits of annotation processors vs SPI or regular plexus components ?
Kristian
2015-03-08 15:32 GMT+01:00 Tibor Digana :
> Kristian, you probably mean our utilies which switch implementations by
> java
> version.
> Yes, Java
Kristian, you probably mean our utilies which switch implementations by java
version.
Yes, Java 8 is the lastest and greatest to have; But in my own company does
not have the confidence to use java 8 even after my trainings incorporating
Java 8 features into the projects.
BTW, I would like to test
Just for the record; we already use most of the "important" java7 stuff
through reflection if it is available (and we have been doing this for
several years). So the "language" features are really the only thing we're
missing.
The improved generics are /great/, try with resources are ok and multic
Java SE 7 Features and Enhancements
http://www.oracle.com/technetwork/java/javase/jdk7-relnotes-418459.html
--
View this message in context:
http://maven.40175.n5.nabble.com/move-maven-core-to-java-7-tp5827988p5828456.html
Sent from the Maven Developers mailing list archive at Nabble.com.
+ 1, Java SE 7
Looking for changes in our plugins as well.
For instance Java 7 introduced a new utility class java.util.Objects.
I found this very useful :
java.util.Objects.requireNonNull() in offensive programming in constructors
java.util.Objects.equals()
java.util.Objects.hashCode()
java.io.
Hi Karl Heinz,
of course I (just) created http://jira.codehaus.org/browse/MINVOKER-183
:)
Regards,
Hervé
Le dimanche 8 mars 2015 13:04:15 Karl Heinz Marbaise a écrit :
> Hi Hervé,
>
> have you created an JIRA issue m-invoker-p for it? Would be great that
> this kind of inforation will not disa
Hi Hervé,
have you created an JIRA issue m-invoker-p for it? Would be great that
this kind of inforation will not disappear...
Kind regards
Karl Heinz Marbaise
On 3/8/15 10:52 AM, Hervé BOUTEMY wrote:
+1
notice I got a strange result when I tried to build from distribution: 6 ITs
were failin
if such little API fixes the issue for most use cases, that would be great
because another more extreme solution would be to use Eclipse Aether, then
have Maven 3.2 as prerequisite: if we can avoid it, that would be great
Regards,
Hervé
Le dimanche 8 mars 2015 11:42:01 Robert Scholte a écrit :
Seems like we need the same kind of solution as done with the Dependency
Tree.
I've introduced a new shared component: maven-artifact-transfer
At least the following plugins are nominated to use this:
maven-install-plugin
maven-deploy-plugin
maven-invoker-plugin
thanks,
Robert
Op Sat, 07 Mar
+1
notice I got a strange result when I tried to build from distribution: 6 ITs
were failing. After some research, I found that building from a path name
containing accents ("Téléchargements" in my case) cause ITs to fail
Once I moved everything to ~/tmp, the problem disappeared...
I suppose t
+1
Regards,
Hervé
Le mercredi 4 mars 2015 22:56:03 Karl Heinz Marbaise a écrit :
> Hi,
>
> We solved 3 issues:
> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11714&version=161
> 17
>
> There are still a couple of issues left in JIRA:
> http://jira.codehaus.org/issues/?jql=project
25 matches
Mail list logo
