+1
On 14 October 2015 at 07:08, Karl Heinz Marbaise wrote:
> Hi,
>
> I need two more binding VOTEs...
>
> Kind regards
> Karl Heinz Marbaise
> On 10/13/15 7:26 PM, Karl Heinz Marbaise wrote:
>
>> Hi,
>>
>> here is my +1.
>>
>>
>> Kind regards
>> Karl Heinz Marbaise
>> On 10/11/15 10:17 PM, Karl
here's mine
+1 non-binding
On Sun, Oct 11, 2015 at 10:17 PM, Karl Heinz Marbaise
wrote:
> Hi,
>
> Note: This is a Maven 3.0 / JDK 6 release
>
> We solved 5 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922&version=12333677
>
> There are several issue open:
>
>
+1.
On Tue, Oct 13, 2015 at 4:08 PM, Karl Heinz Marbaise wrote:
> Hi,
>
> I need two more binding VOTEs...
>
> Kind regards
> Karl Heinz Marbaise
> On 10/13/15 7:26 PM, Karl Heinz Marbaise wrote:
>>
>> Hi,
>>
>> here is my +1.
>>
>>
>> Kind regards
>> Karl Heinz Marbaise
>> On 10/11/15 10:17 PM,
+1
> On Oct 11, 2015, at 4:17 PM, Karl Heinz Marbaise wrote:
>
> Hi,
>
> Note: This is a Maven 3.0 / JDK 6 release
>
> We solved 5 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922&version=12333677
>
> There are several issue open:
> https://issues.apache.org
Hi,
I have created a maven-3.2.6 branch for the back port...and added those
issues to the Roadmap for 3.2.6 in JIRA as well...
The question is:
Is there something which should be part of this bug fix release as
well...backport some other issues which are ready ?
Kind regards
Karl Heinz Ma
Hi,
I need two more binding VOTEs...
Kind regards
Karl Heinz Marbaise
On 10/13/15 7:26 PM, Karl Heinz Marbaise wrote:
Hi,
here is my +1.
Kind regards
Karl Heinz Marbaise
On 10/11/15 10:17 PM, Karl Heinz Marbaise wrote:
Hi,
Note: This is a Maven 3.0 / JDK 6 release
We solved 5 issues:
http
Consider me prodded.
> On Oct 13, 2015, at 3:35 PM, Stephen Connolly
> wrote:
>
> Yes I was going to try and prod JvZ again...
>
> On 12 October 2015 at 23:47, Mark Derricutt
> wrote:
>> After seeing Karl's post about a back ported 3.2.6 release, I was reminded
>> about the about the aborte
Yes I was going to try and prod JvZ again...
On 12 October 2015 at 23:47, Mark Derricutt wrote:
> After seeing Karl's post about a back ported 3.2.6 release, I was reminded
> about the about the aborted 3.3.6 release?
>
> http://maven-dev.markmail.org/search/?q=Vote+3.3.6#query:Vote%203.3.6+page
After seeing Karl's post about a back ported 3.2.6 release, I was reminded
about the about the aborted 3.3.6 release?
http://maven-dev.markmail.org/search/?q=Vote+3.3.6#query:Vote%203.3.6+page:1+mid:oklhst7l23lylkiu+state:results
Mark
--
Mark Derricutt
http://www.theoryinpractice.net
http://ww
Hi,
I haven't been itched by such kind of problem, but i'm thinking about a
way to make the current implementation better...
Furthermore can we catch such an edge case? I don't know any realiable
solution to catch this...
root
+-- .mvn
+-- parent/aggregator
+-- m1
+-- m2
so this kind c
Hi,
here is my +1.
Kind regards
Karl Heinz Marbaise
On 10/11/15 10:17 PM, Karl Heinz Marbaise wrote:
Hi,
Note: This is a Maven 3.0 / JDK 6 release
We solved 5 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922&version=12333677
There are several issue open:
ht
> On Oct 13, 2015, at 10:45 AM, Benson Margulies wrote:
>
>>
>> I am just accustomed to seeing the whole graph in M2Eclipse and excluding,
>> refactoring and locking things down while I’m running tests. I get
>> everything working and then don’t think about much until a required
>> dependenc
On Tue, Oct 13, 2015 at 10:29 AM, Jason van Zyl wrote:
>
>> The second is the ease of messing up.
>>
>> The maven-release project is set up as a ticking bomb under this
>> regime. The project uses dependencyManagement to lock to a version; so
>> if any dependency requires a newer version, the resu
> The second is the ease of messing up.
>
> The maven-release project is set up as a ticking bomb under this
> regime. The project uses dependencyManagement to lock to a version; so
> if any dependency requires a newer version, the result is the
> explosion we have experienced. To me, this seems
Github user Tibor17 commented on the pull request:
https://github.com/apache/maven-surefire/pull/105#issuecomment-147730852
@juherr Thx I will include it.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project do
On 13 October 2015 at 15:14, Benson Margulies wrote:
> I am perfectly willing to stand corrected; I started this email thread
> to get some insight. I may have misheard Stephen over the noise of the
> other runners.
No that was collecting my son from school... even more noizy... ;-)
I didn't wan
Github user juherr commented on the pull request:
https://github.com/apache/maven-surefire/pull/105#issuecomment-147729243
087c7c3c4b54000fae6ea722a0119ab76f05b5c1 is missing, but not a problem for
me :)
---
If your project is set up for it, you can reply to this email and have your
Github user juherr closed the pull request at:
https://github.com/apache/maven-surefire/pull/105
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature
OK, I retract my doc comment in part:
"In addition, the version and scope of artifacts which are
incorporated from transitive dependencies may also be controlled by
specifying them in a dependency management section." is hinting at
reality, but I think it could be made much stronger; the differenc
I am perfectly willing to stand corrected; I started this email thread
to get some insight. I may have misheard Stephen over the noise of the
other runners.
However, I will say that I don't like two aspects of this, and I
wonder if they could be improved.
The first is documentation.
https://mave
> On Oct 13, 2015, at 8:44 AM, Benson Margulies wrote:
>
> I got a lecture on this from Stephen Connolly, who took some time out
> from Marathon training to educate me. We're all wrong.
>
> The only way to 'lock down' a version is to use a range: [foo). All
> other versions are 'recommended’.
I think you meant [foo], i.e. both square brackets, for version range
that means "version foo and nothing else".
--
Regards,
Igor
On Tue, Oct 13, 2015, at 08:44 AM, Benson Margulies wrote:
> I got a lecture on this from Stephen Connolly, who took some time out
> from Marathon training to educate
I got a lecture on this from Stephen Connolly, who took some time out
from Marathon training to educate me. We're all wrong.
The only way to 'lock down' a version is to use a range: [foo). All
other versions are 'recommended'.
If there are no ranges, then the resolution algorithm decides what
ver
The Apache Maven team is pleased to announce the release of the Apache
Maven Plugins parent POM, version 28.
This POM is the common parent of all of the plugins maintained by the
Apache Maven PMC, and, as such, is of limited use to developers
outside of the Maven project. See the svn history of
ht
GitHub user sfussenegger opened a pull request:
https://github.com/apache/maven-enforcer/pull/16
MENFORCER-241 allow ignoring minor and patch level mismatches
this patch allows `dependencyConvergence` to only consider major and minor
version changes by introducing a new `degree` par
This vote passes:
+1 binding: me, Kristian Rosenvold, Hervé, Karl Hans, Olivier.
+1 other: Michael Osipov, Tibor Digana
I will proceed with the process.
On Sun, Oct 11, 2015 at 8:34 PM, Olivier Lamy wrote:
> +1
>
> On 12 October 2015 at 05:20, Karl Heinz Marbaise wrote:
>
>> Hi,
>>
>> +1 ...
I am now -1 on commit
1677765 chrisgwarp 1.9.5-SNAPSHOT
from maven-release. Back in May, this made source changes to require
an unreleased, incompatible, SCM version. Now I can't release release
to fix a critical problem. Further, since it involves this level of
API dependency, I think it req
I would go even further here.
The Eclipse <-> Maven integration is still (2015!) hugely messy, often
requiring special hacks within Mojos to work [at all].
M2E - which seems like the preferred choice in the Eclipse community -
depends on largely undocumented hacks to
work with Mojos updating fi
28 matches
Mail list logo
