DefaultJavaToolChain? you mean the implementation?
Can you give me pointers to the Tycho sources that use this API?
(that's clearly not expected)
I'm in favor of introducing deprecated DefaultJavaToolChain
that extends the new implementation, which is easy to do: just need to
understand how it
Hi Hervé,
On 12/13/14 8:57 AM, Hervé BOUTEMY wrote:
done as told in the doc [1]
$ list_appgroups.pl hudson-jobadmin | grep marba
khmarbaise
This will give you more karma, but perhaps not everything you expected
This is more than i expected ;-)...Thanks...
Kind regards
Karl Heinz Marbaise
I can't reproduce the problem: see the logs in attachment
can you give me more details?
notice that from every changes we did on toolchains, the only expected visible
change was on MNG-5718: custom toolchains need to be enhanced.
MNG-5719 wasn't supposed to have any impact on Tycho or any
Hi,
We solved 21 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?version=20790styleName=HtmlprojectId=11126
This release is mostly focused on regressions and minor issues in the
2.5.X range.
There are still a couple of issues left in JIRA:
As somewhat of an assembly-plugin tradition, there is a small error in
the vote mail. We solved 9 issues. 21 issues was 2.5.2 :)
Kristian
2014-12-13 10:33 GMT+01:00 Kristian Rosenvold krosenv...@apache.org:
Hi,
We solved 21 issues:
Are you able to run mvn validate on the attached project with staged
maven 3.2.4 or current master? The log you attached is from maven 3.2.3.
I've attached log from current master.
--
Regards,
Igor
On 2014-12-13, 3:32, Hervé BOUTEMY wrote:
I can't reproduce the problem: see the logs in
uh, stupid me, I answered too early in the morning ;)
The problem is in pom.xml: the config is wrong
configuration
toolchains
vendorfake/vendor
/toolchains
/configuration
the result can be seen in the INFO message
[INFO] Type:vendor
With previous
Hi to all,
for you information about ApacheCON 2015...Travel Assistance Applications...
Forwarded Message
Subject:ApacheCon NA 2015 Travel Assistance Applications now open!
Date: Sat, 13 Dec 2014 13:59:15 +0100
From: jan i j...@apache.org
Reply-To: Maven
I just wanted to point out there was a change in behaviour between 3.2.3
and 3.2.4. If you this was expected/desired, I have no objections.
--
Regards,
Igor
On 2014-12-13, 8:33, Hervé BOUTEMY wrote:
uh, stupid me, I answered too early in the morning ;)
The problem is in pom.xml: the config is
I've reintroduced DefaultJavaToolChain as deprecated extension of
JavaToolchainImpl. All Tycho ITs pass now and I am not aware of any
other regressions in maven 3.2.4.
--
Regards,
Igor
On 2014-12-13, 3:13, Hervé BOUTEMY wrote:
DefaultJavaToolChain? you mean the implementation?
Can you give me
ok, I had a look at Tycho sources:
this is something introduced recently (10/10/2014): IIUC, Tycho 0.22.0 was
released since then
I'm surprised of tycho-core's ToolchainProvider: IIUC, that's a rewrite of a
part of maven-toochains-plugin, depending on ToolchainManagerPrivate which is
not part
MNG-5724 was pushed to 3.2.5 in Jira, but it was already modified in the code:
either the Jira issue is copmpletely fixed, or code reverted, but the issue
can't be postponed like this
Regards,
Hervé
Le vendredi 12 décembre 2014 16:54:39 Jason van Zyl a écrit :
Hi,
Time to release Maven
I've already reintroduced DefaultJavaToolChain and Tycho is happy now [1].
Tycho needs access to DefaultJavaToolChain#getJavaHome() which, to the
best of my knowledge, is not available from any other API, is not
available through ToolchainManager.
I don't believe Tycho references JavaToolChain
Hi,
tested with Maven 2.2.1, 3.0.5, 3.1.1, 3.2.1, 3.2.2, 3.2.3
and with the following combinations JDK-1.5-u22, JDK-1.6-u45,
JDK-1.7-u40, JDK-1.8-u25 whereas Maven 3.2.X has not been tested with
JDK 1.5...cause it needs at least Java 1.6.
mvn -Prun-its clean verify
no issues found so +1
The fixes have been made, I'll recut the release.
On Dec 13, 2014, at 9:44 AM, Igor Fedorenko i...@ifedorenko.com wrote:
I've already reintroduced DefaultJavaToolChain and Tycho is happy now [1].
Tycho needs access to DefaultJavaToolChain#getJavaHome() which, to the
best of my knowledge, is
we need to choose what we do with http://jira.codehaus.org/browse/MNG-5724
it is done, since we have Wagon 2.8, but it seems there is a debate if we
need to remove commons-io, commons-lang, and jsoup jars, and possibly wagon-
http-shared from maven distribution
I don't have precise opinion
I finally had a second deeper look at the issue, and chose to close it as fixed
in Maven 3.2.4: details in the comments
then there is no problem now to re-cut the release
thanks
Hervé
Le samedi 13 décembre 2014 21:14:08 Hervé BOUTEMY a écrit :
we need to choose what we do with
H, K
Regards,
Hervé
Le mardi 9 décembre 2014 10:52:14 Stephen Connolly a écrit :
This is a run-off vote to select the top two options for our new mascot's
name.
The entries with the highest number of votes will be selected for the final
round. If there is only one entry with the highest
Iirc we said not reusing version numbers after a .0 so this will be 3.2.5,
yes?
On Saturday, December 13, 2014, Jason van Zyl ja...@takari.io wrote:
The fixes have been made, I'll recut the release.
On Dec 13, 2014, at 9:44 AM, Igor Fedorenko i...@ifedorenko.com
javascript:; wrote:
I've
No, it will be 3.2.4.
On Dec 13, 2014, at 3:52 PM, Stephen Connolly stephen.alan.conno...@gmail.com
wrote:
Iirc we said not reusing version numbers after a .0 so this will be 3.2.5,
yes?
On Saturday, December 13, 2014, Jason van Zyl ja...@takari.io wrote:
The fixes have been made, I'll
Why? How will we tell the original broken binaries from the new ones?
On December 13, 2014 4:01:31 PM EST, Jason van Zyl ja...@takari.io wrote:
No, it will be 3.2.4.
On Dec 13, 2014, at 3:52 PM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
Iirc we said not reusing version numbers
We agreed that each new recut is a new point release.
Cheers,
Paul
On Sat, Dec 13, 2014 at 3:42 PM, Igor Fedorenko i...@ifedorenko.com wrote:
Why? How will we tell the original broken binaries from the new ones?
On December 13, 2014 4:01:31 PM EST, Jason van Zyl ja...@takari.io
wrote:
No,
Have the thread handy? I honestly forget having to agreed to that.
On Dec 13, 2014, at 5:05 PM, Paul Benedict pbened...@apache.org wrote:
We agreed that each new recut is a new point release.
Cheers,
Paul
On Sat, Dec 13, 2014 at 3:42 PM, Igor Fedorenko i...@ifedorenko.com wrote:
I don't because it's inconsistent for external users who will be confused about
where a release has gone. To date I have never skipped versions, for
consistency I don't want to start now. I consider the staged releases not
contributing to the public version pool.
For your case I think you're
When the 3.2.0 build had a regression, we jumped to 3.2.1:
http://mail-archives.apache.org/mod_mbox/maven-dev/201402.mbox/%3cdf2f7f9e-9334-43d9-aa01-03733604b...@takari.io%3E
Sorry I didn't provide this thread up front. It took a while to find it.
However, I am pretty sure we did this again with
Sure, I never wanted to do it which is why I forgot and will likely continue to
forget so I'll change the docs because I always have to look at them to figure
out how to publish the site. I still think it's a inconsistent practice for the
few it would inconvenience in a minor way.
On Dec 13,
Documentation updated.
On Dec 13, 2014, at 5:32 PM, Jason van Zyl ja...@takari.io wrote:
Sure, I never wanted to do it which is why I forgot and will likely continue
to forget so I'll change the docs because I always have to look at them to
figure out how to publish the site. I still think
I can see your point. However, I don't think it's all that unusual for
people to see skipped versions during upgrading anymore. For example, when
a security issue is found in a GA product, the affected version is
instantly pulled from distribution sites and a new version is published.
Whether a
Hi folks,
I have been working recently on Maven Project Info Reports Plugin and
fixed a bunch of issues. Those which are still open I requested
participants to respond whether the issues are still valid. If no one
responds, I will won't fix them.
Has anyone of you an open issue he would
Am 2014-12-13 um 23:46 schrieb Paul Benedict:
I can see your point. However, I don't think it's all that unusual for
people to see skipped versions during upgrading anymore. For example, when
a security issue is found in a GA product, the affected version is
instantly pulled from distribution
Not Maven central, distribution (download) sites like Apache's.
Cheers,
Paul
On Sat, Dec 13, 2014 at 4:50 PM, Michael Osipov micha...@apache.org wrote:
Am 2014-12-13 um 23:46 schrieb Paul Benedict:
I can see your point. However, I don't think it's all that unusual for
people to see skipped
Hi,
we are here in a complete different situation.
During the VOTE the artifacts are stored in a stage repository which can
simply being dropped (Which is the idea of those staged repository). The
only thing which is needed to be fixed is the SCM Tag (Git, SVN...).
This can be done
If
Am 2014-12-13 um 23:52 schrieb Paul Benedict:
Not Maven central, distribution (download) sites like Apache's.
I am aware of that but if something has gone GA, it is on Central.
Otherwise the term 'GA' wouldn't hold true.
Michael
Apache uses GA to mean a classification of a release; I don't mean it in
some sort of generalized sense. You can revoke the status of a release.
Whether you can erase it from everywhere it's been, that's another matter
(and not possible from Central, right).
Cheers,
Paul
On Sat, Dec 13, 2014 at
While I agree with your assessment Paul, the problem with upgrading
non-sequential release numbers that I encounter with some of my customers
(the larger organizations or ones with regulated products [think medical])
is it usually causes some confusion (we're on version n.2 and I see n.8
but
If people really don't want to end up skipping numbers, and also people
also don't want to recreate tags, there are solutions.
For example, Lucene recognizes that serious testing of snapshots just never
happens. So, the release manager starts by doing the full release process
for X.Y.Z-RC1. And
36 matches
Mail list logo
