Re: Lets talk about our changes openly. maven-surefire git commit: [SUREFIRE-1324] Surefire incorrectly suppresses exceptions when closing resources.

[Tibor Digana]

I have created a pull request
https://github.com/apache/maven-surefire/pull/139
The build passed successfully.
Christian, Benedikt please have a look and I will amend the HEAD revision
in origin/master.
Thx.

On Fri, Jan 6, 2017 at 4:43 PM, Tibor Digana  wrote:

> Christian thx for the logs.
> Can you please send me *log.txt* from these folders?
> surefire-integration-tests/target/Surefire34SecurityManagerIT_
> testSecurityManager
> surefire-integration-tests/target/Surefire1295AttributeJvmCrashe
> sToTestsIT_crashInFork
> surefire-integration-tests/target/Surefire1295AttributeJvmCrashe
> sToTestsIT_crashInReusableFork
> surefire-integration-tests/target/Surefire1295AttributeJvmCrashe
> sToTestsIT_crashInSingleUseFork
>
> Cheers
> Tibor
>
> On Fri, Jan 6, 2017 at 3:11 AM, Tibor Digana 
> wrote:
>
>> Hello guys,
>>
>> Sorry for late reply.
>> I do not want to remove your work from the commit - it's not fair to
>> anyone and therefore I would like to open PR at GitHub and I would like to
>> amend the commit with my proposal and *you guys feel free to comment on
>> the PR - everybody is welcome*.
>> I understand that this takes your and my spare time but that's the only
>> way we can friendly continue.
>> In my experiences the professionals must communicate in code review and
>> however they have good technical understanding always they may have
>> different decisions and consensus is the only way we will coexist.
>>
>> :) I will send you link in GitHub in a day.
>>
>> I see we will make good job together!
>>
>>
>>
>>
>>
>> On Mon, Jan 2, 2017 at 3:42 PM, Tibor Digana 
>> wrote:
>>
>>> I also have such feeling that Maven became a playground.
>>> Last week I saw it in reality and after Robert told me we made
>>> playground in our sources I could not believe this could happen in such
>>> professional project like Maven.
>>>
>>> I would appreciate it if the change [1] 
>>> e5a6b9c8d4f514100a01dea2acf1fb059e294968
>>> was reverted in Surefire and a new pull request was open at GitHub making
>>> the code review.
>>> I use to do this with myself with big changes and I am waiting for
>>> anyone in the PR. We are doing the same with one excellent guy from another
>>> ASF project who is supporting us with JUnit 5 addons and this works pretty
>>> well.
>>>
>>> The situation in Surefire is quite ambitious to release Versions 2.19.2
>>> and 3.0.0-RC1 in parallel with 2.19.3 JDK9 support and JUnit 5 support now
>>> in January.
>>>
>>> The problem is that these Surefire three plugins are so easy to crash
>>> with whatever changes and therefore I implemented dumping internal errors
>>> to dump files which will help us investigate two Jira issues - critical and
>>> blocker. And there are much more thinks to talk about the features...
>>>
>>> I would really appreciate if we could behave like ordinal users in our
>>> project and provide a pull request in GitHub and call for code review.
>>> This does not mean only Surefire.
>>>
>>> So now please revert last change [1] and let's start from the ground.
>>> We should again learn from the beginning and start communicating in the
>>> community; otherwise this is the end of the project.
>>>
>>> [1] https://git1-us-west.apache.org/repos/asf?p=maven-surefire.g
>>> it=commit=e5a6b9c8d4f514100a01dea2acf1fb059e294968
>>>
>>> We can talk about more visions, or I can open Wiki for such talks which
>>> I think we will appreciate because everybody can add her/his visions.
>>>
>>> WDYT?
>>>
>>> Cheers
>>> Tibor
>>>
>>
>>
>

[GitHub] maven-surefire pull request #139: [SUREFIRE-1324] Surefire incorrectly suppr...

[Tibor17]

GitHub user Tibor17 opened a pull request:

https://github.com/apache/maven-surefire/pull/139

[SUREFIRE-1324] Surefire incorrectly suppresses exceptions when closing 
resources.



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/Tibor17/maven-surefire SUREFIRE-1324

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/maven-surefire/pull/139.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #139


commit 2cf58708f6798f04d0314dce5df4c0ed5c2a09d3
Author: Tibor17 
Date:   2017-01-07T02:55:07Z

[SUREFIRE-1324] Surefire incorrectly suppresses exceptions when closing 
resources.




---
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 is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03

[Tibor Digana]

Hi Stephen. In the Roadmap you have mentioned that all the discussion of
particular Jira issue is discussed in ML.
I cannot imaging how the code would be discussed here. Why not in pull
request at github?
In the repository with ASF rights INFRA can create labels like you have
proposed  "?" or "+1" or milestone "3.5" etc.
https://help.github.com/articles/creating-and-editing-labels-for-issues-and-pull-requests/


On Tue, Jan 3, 2017 at 6:52 PM, Manfred Moser 
wrote:

> I am +100 on that. Thanks for taking the initiative to get things back on
> track.
>
> Manfred
>
> Stephen Connolly wrote on 2017-01-03 09:40:
>
> > I believe we have consensus, here is the final call for anyone objecting
> to
> > the plan to have their opinions considered.
> >
> > Here is the draft of the proposal for the vote:
> >
> > NOTE: THIS IS *NOT* THE VOTE
> >
> > -BEGIN DRAFT-
> > Hi,
> >
> > We have collectively managed to mess up our ability to follow the
> original
> > release plan for 3.4.0 which was originally supposed to consist of an
> > effective no-op change of Eclipse's Aether for the code after migration
> to
> > Apache's Maven Resolver plus some other orthogonal changes around logging
> > colourization and launcher script bug fixes.
> >
> > Given that some developer private builds of the current master branch
> have
> > been shared with as 3.4.0-SNAPSHOT. More critically, JIRA issues have
> been
> > closed with a fixed version of 3.4.0.
> >
> > For us to release a 3.4.0 with those fixes reverted, could cause
> confusion
> > with our user community.
> >
> > Additionally the informal practice of keeping existing integration tests
> as
> > RTC has not been followed, leading to some people to question whether the
> > integration tests remain valid.
> >
> > For all the above reasons it is proposed to do *all* the following as an
> > whole:
> >
> > 1. In git://git.apache.org/maven.git we will rename the current master
> > branch to `pre-reset-master` and recreate `master` as (TODO HASH
> > corresponding to a commit that does a version bump to 3.5.0-SNAPSHOT on
> top
> > of 737de43e392fc15a0ce366db98d70aa18b3f6c03 - by having a commit that is
> > not on the current master branch it will prevent accidental fast-forward
> > commits)
> >
> > 2. In git://git.apache.org/maven-integration-testing.git we will rename
> the
> > current master branch to `pre-reset-master` and recreate `master` as
> (TODO
> > HASH corresponding to a commit on top of 94bd771c88cc96014ca0ddaa07ac6f
> > 778b3c7501)
> >
> > 3. In git://git.apache.org/maven-resolver.git we will rename the current
> > master branch to `pre-reset-master` and recreate `master`
> > as b74f7a1e8837875b4780199f644119f55d22465d (i.e. the 1.0.x branch)
> >
> > We will then proceed to have (ideally) the original committers
> cherry-pick
> > (and tidy up an squash... if the original committers are not able to
> assist
> > then squashing may not be practicable) those changes that have been
> agreed
> > for 3.5.0 as summarized on the
> > https://cwiki.apache.org/confluence/display/MAVEN/Roadmap+2017 wiki page
> > (authorative source of the decisions summarized in the wiki page is the
> > mail thread:
> > https://mail-archives.apache.org/mod_mbox/maven-dev/201612.mbox/%3CCA%
> 2BnPnMxERdjJq5ChMNP-HN_AvZOs8sm7Ud5aVcEza0BPnm5ZOw%40mail.gmail.com%3E
> > ).
> >
> > As this involves a --force push on the `master` branch, we want to get
> the
> > approval of the committers before continuing.
> >
> > The vote will be open for at least 72 hours.
> >
> > The vote will be decided by a simple majority of valid votes cast. There
> is
> > no veto.
> >
> > The vote is open to all committers.
> >
> > In addition, for the vote to be valid, there must be at least 3x+1 votes
> > from PMC members
> >
> > TODO: insert voting options template
> >
> > -Stephen
> > -END DRAFT-
> >
> > I'm going to start the vote in a clean thread some time tomorrow. Any
> > suggested changes will need to be provided before say 12:00 UTC,
> >
> > If you do not agree that we have consensus (i.e. you are likely to vote
> -1)
> > please stand up and let us know your concerns so that we may adapt the
> plan
> > to include your concerns. There is no harm in not liking the current
> plan,
> > we would rather delay and alter our plan to address your concerns and
> have
> > the vote thread as a formality rather than the vote thread becoming a
> > source of conflict and disharmony in our community.
> >
> > Before I call the vote I will push the forking changes to maven and
> > maven-integration-testing onto a separate branch so that the vote thread
> > can include those hashes. I am delaying doing that until tomorrow in case
> > there is a change in plan on which hash to base off.
> >
> > Fun times!
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org

Re: Lets talk about our changes openly. maven-surefire git commit: [SUREFIRE-1324] Surefire incorrectly suppresses exceptions when closing resources.

[Tibor Digana]

Christian thx for the logs.
Can you please send me *log.txt* from these folders?
surefire-integration-tests/target/Surefire34SecurityManagerIT_testSecurityManager
surefire-integration-tests/target/Surefire1295AttributeJvmCrashesToTestsIT_crashInFork
surefire-integration-tests/target/Surefire1295AttributeJvmCrashesToTestsIT_crashInReusableFork
surefire-integration-tests/target/Surefire1295AttributeJvmCrashesToTestsIT_crashInSingleUseFork

Cheers
Tibor

On Fri, Jan 6, 2017 at 3:11 AM, Tibor Digana  wrote:

> Hello guys,
>
> Sorry for late reply.
> I do not want to remove your work from the commit - it's not fair to
> anyone and therefore I would like to open PR at GitHub and I would like to
> amend the commit with my proposal and *you guys feel free to comment on
> the PR - everybody is welcome*.
> I understand that this takes your and my spare time but that's the only
> way we can friendly continue.
> In my experiences the professionals must communicate in code review and
> however they have good technical understanding always they may have
> different decisions and consensus is the only way we will coexist.
>
> :) I will send you link in GitHub in a day.
>
> I see we will make good job together!
>
>
>
>
>
> On Mon, Jan 2, 2017 at 3:42 PM, Tibor Digana 
> wrote:
>
>> I also have such feeling that Maven became a playground.
>> Last week I saw it in reality and after Robert told me we made playground
>> in our sources I could not believe this could happen in such professional
>> project like Maven.
>>
>> I would appreciate it if the change [1] 
>> e5a6b9c8d4f514100a01dea2acf1fb059e294968
>> was reverted in Surefire and a new pull request was open at GitHub making
>> the code review.
>> I use to do this with myself with big changes and I am waiting for anyone
>> in the PR. We are doing the same with one excellent guy from another ASF
>> project who is supporting us with JUnit 5 addons and this works pretty well.
>>
>> The situation in Surefire is quite ambitious to release Versions 2.19.2
>> and 3.0.0-RC1 in parallel with 2.19.3 JDK9 support and JUnit 5 support now
>> in January.
>>
>> The problem is that these Surefire three plugins are so easy to crash
>> with whatever changes and therefore I implemented dumping internal errors
>> to dump files which will help us investigate two Jira issues - critical and
>> blocker. And there are much more thinks to talk about the features...
>>
>> I would really appreciate if we could behave like ordinal users in our
>> project and provide a pull request in GitHub and call for code review.
>> This does not mean only Surefire.
>>
>> So now please revert last change [1] and let's start from the ground.
>> We should again learn from the beginning and start communicating in the
>> community; otherwise this is the end of the project.
>>
>> [1] https://git1-us-west.apache.org/repos/asf?p=maven-surefire.
>> git=commit=e5a6b9c8d4f514100a01dea2acf1fb059e294968
>>
>> We can talk about more visions, or I can open Wiki for such talks which I
>> think we will appreciate because everybody can add her/his visions.
>>
>> WDYT?
>>
>> Cheers
>> Tibor
>>
>
>

Re: FOSDEM 2017

[Hervé BOUTEMY]

yes, I wanted to come but had a conflict of agenda :(

this is sad since it's a great opportunity to discuss with a lot of people

I hope those who'll attend will have as much fun as we had last years

Regards,

Hervé

Le jeudi 5 janvier 2017, 19:03:12 CET Arnaud Héritier a écrit :
> Still negotiating at home but I'm trying to be here
> AFAIK Hervé won't be able to come
> 
> On Thu, Jan 5, 2017 at 2:20 PM, Robert Scholte  wrote:
> > Hi,
> > 
> > Just like the last couple of years FOSDEM has been a great opportunity to
> > meet several Maven developers.
> > Some of the new features and improvements started here when the Maven
> > committers shared their ideas.
> > 
> > FOSDEM 2017 will take place at ULB Campus Solbosch on Saturday 4 and
> > Sunday 5 February 2017.
> > I plan to go this year and I'm wondering who considers to come as well.
> > 
> > thanks,
> > Robert
> > 
> > [1] https://fosdem.org/2017/
> > 
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [DISCUSS] Big Scrub for proposed 3.5.0 (if we reset master)

[Hervé BOUTEMY]

Le jeudi 5 janvier 2017, 22:40:10 CET Robert Scholte a écrit :
> Hervé Boutemy:
> It seems that all issues have to do with expanding URLs and connections.
yes, calculating effective values for each pom

> Right now there's business logic in the ModelBuilder to calculate such
> values. We already had some discussions about this :) My question is: is
> this really necessary for the effective pom or are the related plugins
> (m-site-p, m-release-p, etc) capable to calculate it?
a lot of things can be done independently by plugins: that's a fact. When you 
look at it, report plugins configuration and execution is now in maven-report-
exec, which does a lot of things similar to what Maven core does to run Mojos.
It makes things really complex for plugins, to redo something that was until 
now done centrally by Maven core.
Then honestly, is it necessary? it's a question of choice.

> For the SCM
> connections it is quite clear for that the SCM provider should
> (re)-calculate the connection, and don't use the SVN concept as done right
> now (in fact, you can find scm-specific hacks in the code)
no, it's not that clear: yes, we can make something very open (more open than 
url(child) = url(parent) + / + artifactId), then complex, then require to 
delegate, then don't have the effective value in effective pom and force 
plugins to calculate effective value when they need it.
or we can consider that the little improvement I did on the algorithm (be able 
to use a path instead of artifactId, or not add anything) is sufficient, since 
adding a path is really something you expect from url semantics

I'm convinced of the second solution, and we both know didn't convince you yet 
:)

> I really hope it is not necessary to introduce these special properties.
they are the minimum to have something a little bit configurable but yet 
standardized

> I
> have more hope in the distribution-pom or leave the responsibility to the
> plugins using these values. For that reason no 3.5.0 for me.
I don't like to postpone such work done for one year, but since 3.5.0 is on 
convergence and mutual understanding, it's clear I'll need to accept to 
postpone...
I'll prepare a branch and we'll have a discussion, probably after 3.5.0

Regards,

Hervé

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org