I believe we moved to https://github.com/codehaus-plexus/plexus-resources
And I just sended to you an invite to be part of the team.
Note @maven-dev team please ask if you need karma as well.
Cheers
Olivier
On 8 March 2015 at 12:05, Dennis Lundberg denn...@apache.org wrote:
Hi,
I've looked
Hi Emmanuel,
How can we help the Debian community? Is there some ML or pointer to the way
you're doing the re-packaging?
Notice that 3.1.1 is not a great choice: this was really an interim version
between 3.0.x and 3.2.x. IMHO, you'd better stay with 3.0.x or switch to
3.2.x. The only
Le vendredi 6 mars 2015 08:33:27 Anders Hammar a écrit :
What I'd like to stress here is that we're talking about Maven core, not
our plugins. We've had a separate discussion/thread for the plugins and for
those we've decided to go with a Java 6 requirement.
As plugins were mentioned in this
Hi Hervé ,
On 3/7/15 12:16 PM, Hervé BOUTEMY wrote:
like Benson, I wanted to understand why we didn't find the issue before the
release (I built the git HEAD without any issue)
I have added the appropriate log files for Maven 3.0.5, 3.1.1, 3.2.5
where i have always the same issue with Maven
it's good to undesrtand the details: yes, install vs verify...
Notice that it's a good thing (TM) to check releases during vote with verify
instead of install, so the local repository doesn't get polluted by local
build of a release that will later have an official build on central
should we
Le samedi 7 mars 2015 13:26:36 Hervé BOUTEMY a écrit :
Le samedi 7 mars 2015 13:06:26 Hervé BOUTEMY a écrit :
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
Hi Hervé,
what made me mad was that our buildservers haven't alarmed us on such
problem...
After diving a little bit into it i have found out the real difference
between my usage on our build servers / in the bug description and my usage:
The build servers use: mvn -Prun-its clean install
Hi,
when we start requiring Maven 3.0 for our plugins, IMO they should all
work *without* depending on Maven Compat.
I've tried to do this for the maven-invoker-plugin and hit the first issue.
They all have to do with artifacts: ArtifactInstaller, ArtifactRepository,
We changed version from 3.2.x to 3.3.x quite late in the release and
this was the reason I proposed change to java 7. It allows us continue
3.3.x improvement and use new language features.
Personally I believe changing compiler configuration to target java 7 is
very unlikely to introduce
ok, let's try: it's easy to revert :)
Regards,
Hervé
Le samedi 7 mars 2015 17:21:03 Karl Heinz Marbaise a écrit :
Hi Hervé,
On 3/7/15 4:32 PM, Hervé BOUTEMY wrote:
it's good to undesrtand the details: yes, install vs verify...
Notice that it's a good thing (TM) to check releases
ok, thank you for the precision: in this case, this is really a showstopper
the bug is more strange: it affects distribution but not git checkout :/
hopefully, newer m-invoker-p version seems ok with distribution
let's try...
Regards,
Hervé
Le samedi 7 mars 2015 13:53:09 Karl Heinz Marbaise
I don't want to change this so close to 3.3.0 release, but I plan to
rework build.xml to delegate actual build to existing maven
installation. Ant will only do extract-assembly. This way we will have
single maven build and Olivier will still be able use ant all to build
and install maven with one
Le samedi 7 mars 2015 08:45:37 Igor Fedorenko a écrit :
We changed version from 3.2.x to 3.3.x quite late in the release
yes, let's be fair :)
and
this was the reason I proposed change to java 7. It allows us continue
3.3.x improvement and use new language features.
Personally I believe
Hi Hervé,
On 3/7/15 4:32 PM, Hervé BOUTEMY wrote:
it's good to undesrtand the details: yes, install vs verify...
Notice that it's a good thing (TM) to check releases during vote with verify
instead of install, so the local repository doesn't get polluted by local
build of a release that will
great: can you give us a pointer?
if we upgrade to Java 7, having these improvements would be more interesting
than waiting the next patch release
the idea of Java 7 upgrade came quite late on the release schedule, and IMHO
these updates are worth one more release testing
Regards,
Hervé
Le
I deliberately kept the change in github to give the discussion a little
time. Personally I dont really mind waiting, but I really believe we're
wasting far too much energy on legacy java versions. It's not as if java6
users dont have a working version. And they can pay people to backport
stuff
Hi Kristian,
Please note that I am not opposed to using Java 7 in the core. What I am
objecting to is the planning, or rather the lack of it.
We currently have core ready to be released on Java 6. Then just before it
is about to be released someone says, hey lets switch Java version as
well.
Le samedi 7 mars 2015 13:06:26 Hervé BOUTEMY a écrit :
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:
and before 2.1.0 vs 2.2.0
and the only
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 was a dead branch
for start. 3.2.2 bugfixes could/should
like Benson, I wanted to understand why we didn't find the issue before the
release (I built the git HEAD without any issue)
looking at the build logs, it seems that it's only an issue when built with
Maven 2.2.1 (which I didn't test), and the bug seems more in m-invoker-p than
in archetype
+1
Le samedi 7 mars 2015 13:09:35 Kristian Rosenvold a écrit :
I deliberately kept the change in github to give the discussion a little
time. Personally I dont really mind waiting, but I really believe we're
wasting far too much energy on legacy java versions. It's not as if java6
users dont
Usually the opensource projects change the major version, to 4.0.0, if
breaking the commpatibility with previous release.
So why we don't do that?
Listing features of Java SE 7 that we may use:
try-catch-resources
Strings in switch Statements
Catching Multiple Exceptions
@SafeVarargs
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 build.
--
Regards,
Igor
On 2015-03-07 17:35, Tibor Digana wrote:
(Replying on this thread from my mail server does not work for me)
Usually the
Sorry, I am not following.
The current majority agreement is to change compiler target level
together with maven core minor version change from 3.2.x to 3.3.0. Then
we can gradually introduce java 7 features in future 3.3.x releases.
This way to avoid dead-end 3.3.0 release immediately followed
@Igor
How about Java SE 7 features?
If we change the compiler version, adapting compiler without introducing new
Java API features would not make any difference in 3.4.0.
Any thoughts?
--
View this message in context:
Hi,
we need one more binding VOTE ;-)
Kind regards
Karl Heinz
On 3/4/15 11:09 PM, Karl Heinz Marbaise wrote:
Hi,
We solved 15 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11137version=20457
There are still a couple of issues left in JIRA:
Hi,
we need one more binding VOTE...
Kind regards
Karl Heinz Marbaise
On 3/4/15 10:56 PM, Karl Heinz Marbaise wrote:
Hi,
We solved 3 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11714version=16117
There are still a couple of issues left in JIRA:
(Replying on this thread from my mail server does not work for me)
Usually the opensource projects change the major version, to 4.0.0, if
breaking the commpatibility with previous release.
So why we don't do that?
Listing features of Java SE 7 that we may use:
try-catch-resources
Strings in
Hi,
I've looked into MCHECKSTYLE-250 and MCHECKSTYLE-288 regarding an NPE.
It turned out to be in plexus-resources. So I have created a pull
request for it at
https://github.com/sonatype/plexus-resources/pull/1
I'd appreciate if someone with access to Sonatype's github area could
merge it and
29 matches
Mail list logo
