date:20170416

Github user Tibor17 commented on the issue:

https://github.com/apache/maven-surefire/pull/147
  
I hope we will release 2.20.1 soon, EO April - BO May.


---
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

[GitHub] maven-surefire issue #147: Reporters use buffers to reduce number of I/O ope...

Github user Tibor17 commented on the issue:

https://github.com/apache/maven-surefire/pull/147
  
@jerrinot 
Thx for contributing.


---
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

[GitHub] maven-surefire issue #147: Reporters use buffers to reduce number of I/O ope...

Github user jerrinot commented on the issue:

https://github.com/apache/maven-surefire/pull/147
  
@Tibor17: excellent, many thanks for a quick fix! Do you have an expected 
release date for 2.20.1 ?


---
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

[GitHub] maven-surefire pull request #147: Reporters use buffers to reduce number of ...

Github user jerrinot closed the pull request at:

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


---
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: New branch SUREFIRE-1361 to approve


Am 2017-04-16 um 17:57 schrieb Tibor Digana:

Hi,
I have copied [1] to branch SUREFIRE-1361 [2] and fixed checkstyle from the
contributor.
Can we proceed and push it to the master?

[1] https://github.com/apache/maven-surefire/pull/147
[2]
https://git-wip-us.apache.org/repos/asf?p=maven-surefire.git;a=commit;h=9c0025ed53d70c06279fef6c0fc30a54aeeab27b


Looks fine to me. Can we have some numbers what we really save here?


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

Re: New branch SUREFIRE-1361 to approve

If there are no objections I will push it to master.

On Sun, Apr 16, 2017 at 5:57 PM, Tibor Digana 
wrote:

> Hi,
> I have copied [1] to branch SUREFIRE-1361 [2] and fixed checkstyle from
> the contributor.
> Can we proceed and push it to the master?
>
> [1] https://github.com/apache/maven-surefire/pull/147
> [2] https://git-wip-us.apache.org/repos/asf?p=maven-surefire.
> git;a=commit;h=9c0025ed53d70c06279fef6c0fc30a54aeeab27b
>
>
> --
> Cheers
> Tibor
>



-- 
Cheers
Tibor

[GitHub] maven-surefire issue #147: Reporters use buffers to reduce number of I/O ope...

Github user Tibor17 commented on the issue:

https://github.com/apache/maven-surefire/pull/147
  
@jerrinot 
Pls close this PR. I created a branch 
https://git-wip-us.apache.org/repos/asf?p=maven-surefire.git;a=commit;h=9c0025ed53d70c06279fef6c0fc30a54aeeab27b


---
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

[GitHub] maven issue #112: Fix snapshot regular expression

2017-04-16 Thread khmarbaise

Github user khmarbaise commented on the issue:

https://github.com/apache/maven/pull/112
  
If you will take some time it's not a problem...the PR will be kept here 
for a long time until you will close it yourself ..so you can be patient and 
take the time you need...no hurry needed...Furthermore it would be great if you 
have identified an error of any kind of or just realised by reading the code 
the issue? The circumstances are important...


---
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: New branch SUREFIRE-1361 to approve

The build passed.

On Sun, Apr 16, 2017 at 5:57 PM, Tibor Digana-2 [via Maven] <
ml-node+s40175n5906549...@n5.nabble.com> wrote:

> Hi,
> I have copied [1] to branch SUREFIRE-1361 [2] and fixed checkstyle from
> the
> contributor.
> Can we proceed and push it to the master?
>
> [1] https://github.com/apache/maven-surefire/pull/147
> [2]
> https://git-wip-us.apache.org/repos/asf?p=maven-surefire.git;a=commit;h=
> 9c0025ed53d70c06279fef6c0fc30a54aeeab27b
>
>
> --
> Cheers
> Tibor
>
>
> --
> If you reply to this email, your message will be added to the discussion
> below:
> http://maven.40175.n5.nabble.com/New-branch-SUREFIRE-1361-
> to-approve-tp5906549.html
> To start a new topic under Maven Developers, email
> ml-node+s40175n142166...@n5.nabble.com
> To unsubscribe from Maven Developers, click here
> 
> .
> NAML
> 
>




--
View this message in context: 
http://maven.40175.n5.nabble.com/New-branch-SUREFIRE-1361-to-approve-tp5906549p5906554.html
Sent from the Maven Developers mailing list archive at Nabble.com.

New branch SUREFIRE-1361 to approve

Hi,
I have copied [1] to branch SUREFIRE-1361 [2] and fixed checkstyle from the
contributor.
Can we proceed and push it to the master?

[1] https://github.com/apache/maven-surefire/pull/147
[2]
https://git-wip-us.apache.org/repos/asf?p=maven-surefire.git;a=commit;h=9c0025ed53d70c06279fef6c0fc30a54aeeab27b


-- 
Cheers
Tibor

[GitHub] maven issue #112: Fix snapshot regular expression

2017-04-16 Thread kevin-canadian

Github user kevin-canadian commented on the issue:

https://github.com/apache/maven/pull/112
  
I actually just wanted to let you know about the bug, and since the fix was 
so simple I made a PR rather than creating an issue.

It will be a while before I have time look into the project's contribution 
guidelines or figure out how to add and run appropriate tests.

If someone would like to incorporate this fix in the meantime that would be 
great, otherwise I'll try to get around to it eventually!


---
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: rewrite StatelessXmlReporter fo JAXB


Am 2017-04-16 um 16:52 schrieb Tibor Digana:

That would still create a string in memory, won't it?

It would still leak in memory while getter is called.
Streaming to XML is better in this case.

Do we have any alternative?


I have to think about it and understand the whole system.
But why not use the regular XMLStreamWriter paired with this:
http://stackoverflow.com/a/2514/696632.

You'll be able to stream whatever you want.


On Sun, Apr 16, 2017 at 4:40 PM, Michael Osipov  wrote:


Am 2017-04-16 um 16:15 schrieb Tibor Digana:


Since we have XSD [1] we can generate classes and call setters in
particular places in StatelessXmlReporter.java.
Regarding memory consumption system-out may consume really a lot of
memory.
Therefore this is my proposal:

@XmlJavaTypeAdapter(CdataSystemAdapter.class)
public Utf8RecodingDeferredFileOutputStream getSystemOut()

class CdataSystemAdapter
WeakReference with   utf8RecodingDeferredFileOutputStream.writeTo(
stream )
return ""



That would still create a string in memory, won't it?

[1]

https://maven.apache.org/surefire/maven-surefire-plugin/xsd/
surefire-test-report.xsd



This needs a rewrite, too much duplication, no typing but xs:string only.

On Sun, Apr 16, 2017 at 2:43 PM, michaelo [via Maven] <

ml-node+s40175n5906482...@n5.nabble.com> wrote:

Am 2017-04-16 um 14:21 schrieb Tibor Digana:


Hi,


I want to first talk with you about XML marshaller StatelessXmlReporter


[1]


in Surefire which is built on the top of SharedUtils'


PrettyPrintXMLWriter.



I found out issues after a contributor opened this issue [2].

The problem is that we are using two streams, OutputStream and Writer,


to


create XML in file system for one reason. We write CDATA directly to the
stream apart of xml facility. We have bug with escaping illegal


characters.



Instead, my proposal is to create XSD and Jaxb stubs and marshal it to


XML


file and we do need to care about low level XML and escaping characters.
The code will be easier to understand. The elements system-out and
system-err can be large but we have the stream already in temp files
Utf8RecodingDeferredFileOutputStream which means that the Jaxb


mashaller


will not keep String in memory too long - only while Marshaller needs


the


string.

What is your opinion?



Looking at the current code -- a lot of boilerplate. I am quite
experienced with JAXB, XJC and the Maven JAXB2 Plugin [1].

Consider that JAXB always holds the model in memory. If you intend to
maintain streams within an XML you can resort fragments and other stuff
MOXy supports. But let me tell you that it won't be that easy as you
think if you want everything as streaming with little memory usage.

Michael

BTW: this should go to dev@

[1] https://github.com/highsource/maven-jaxb2-plugin

-
To unsubscribe, e-mail: [hidden email]

For additional commands, e-mail: [hidden email]




--
If you reply to this email, your message will be added to the discussion
below:
http://maven.40175.n5.nabble.com/Re-rewrite-StatelessXmlRepo
rter-fo-JAXB-
tp5906482.html
To start a new topic under Maven Developers, email
ml-node+s40175n142166...@n5.nabble.com
To unsubscribe from Maven Developers, click here

.
NAML







--
View this message in context: http://maven.40175.n5.nabble.c
om/Re-rewrite-StatelessXmlReporter-fo-JAXB-tp5906482p5906521.html
Sent from the Maven Developers mailing list archive at Nabble.com.




-
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: rewrite StatelessXmlReporter fo JAXB

>> That would still create a string in memory, won't it?
It would still leak in memory while getter is called.
Streaming to XML is better in this case.

Do we have any alternative?

On Sun, Apr 16, 2017 at 4:40 PM, Michael Osipov  wrote:

> Am 2017-04-16 um 16:15 schrieb Tibor Digana:
>
>> Since we have XSD [1] we can generate classes and call setters in
>> particular places in StatelessXmlReporter.java.
>> Regarding memory consumption system-out may consume really a lot of
>> memory.
>> Therefore this is my proposal:
>>
>> @XmlJavaTypeAdapter(CdataSystemAdapter.class)
>> public Utf8RecodingDeferredFileOutputStream getSystemOut()
>>
>> class CdataSystemAdapter
>> WeakReference with   utf8RecodingDeferredFileOutputStream.writeTo(
>> stream )
>> return ""
>>
>
> That would still create a string in memory, won't it?
>
> [1]
>> https://maven.apache.org/surefire/maven-surefire-plugin/xsd/
>> surefire-test-report.xsd
>>
>
> This needs a rewrite, too much duplication, no typing but xs:string only.
>
> On Sun, Apr 16, 2017 at 2:43 PM, michaelo [via Maven] <
>> ml-node+s40175n5906482...@n5.nabble.com> wrote:
>>
>> Am 2017-04-16 um 14:21 schrieb Tibor Digana:
>>>
>>> Hi,

 I want to first talk with you about XML marshaller StatelessXmlReporter

>>> [1]
>>>
 in Surefire which is built on the top of SharedUtils'

>>> PrettyPrintXMLWriter.
>>>

 I found out issues after a contributor opened this issue [2].

 The problem is that we are using two streams, OutputStream and Writer,

>>> to
>>>
 create XML in file system for one reason. We write CDATA directly to the
 stream apart of xml facility. We have bug with escaping illegal

>>> characters.
>>>

 Instead, my proposal is to create XSD and Jaxb stubs and marshal it to

>>> XML
>>>
 file and we do need to care about low level XML and escaping characters.
 The code will be easier to understand. The elements system-out and
 system-err can be large but we have the stream already in temp files
 Utf8RecodingDeferredFileOutputStream which means that the Jaxb

>>> mashaller
>>>
 will not keep String in memory too long - only while Marshaller needs

>>> the
>>>
 string.

 What is your opinion?

>>>
>>> Looking at the current code -- a lot of boilerplate. I am quite
>>> experienced with JAXB, XJC and the Maven JAXB2 Plugin [1].
>>>
>>> Consider that JAXB always holds the model in memory. If you intend to
>>> maintain streams within an XML you can resort fragments and other stuff
>>> MOXy supports. But let me tell you that it won't be that easy as you
>>> think if you want everything as streaming with little memory usage.
>>>
>>> Michael
>>>
>>> BTW: this should go to dev@
>>>
>>> [1] https://github.com/highsource/maven-jaxb2-plugin
>>>
>>> -
>>> To unsubscribe, e-mail: [hidden email]
>>> 
>>> For additional commands, e-mail: [hidden email]
>>> 
>>>
>>>
>>>
>>> --
>>> If you reply to this email, your message will be added to the discussion
>>> below:
>>> http://maven.40175.n5.nabble.com/Re-rewrite-StatelessXmlRepo
>>> rter-fo-JAXB-
>>> tp5906482.html
>>> To start a new topic under Maven Developers, email
>>> ml-node+s40175n142166...@n5.nabble.com
>>> To unsubscribe from Maven Developers, click here
>>> >> acro=unsubscribe_by_code=142166=dGlib3JkaWdhbmFAYX
>>> BhY2hlLm9yZ3wxNDIxNjZ8LTI4OTQ5MjEwMg==>
>>> .
>>> NAML
>>> >> acro=macro_viewer=instant_html%21nabble%3Aemail.naml
>>> =nabble.naml.namespaces.BasicNamespace-nabble.view.web.
>>> template.NabbleNamespace-nabble.view.web.template.NodeNamesp
>>> ace=notify_subscribers%21nabble%3Aemail.
>>> naml-instant_emails%21nabble%3Aemail.naml-send_instant_
>>> email%21nabble%3Aemail.naml>
>>>
>>>
>>
>>
>>
>> --
>> View this message in context: http://maven.40175.n5.nabble.c
>> om/Re-rewrite-StatelessXmlReporter-fo-JAXB-tp5906482p5906521.html
>> Sent from the Maven Developers mailing list archive at Nabble.com.
>>
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>


-- 
Cheers
Tibor

Re: rewrite StatelessXmlReporter fo JAXB


Am 2017-04-16 um 16:15 schrieb Tibor Digana:

Since we have XSD [1] we can generate classes and call setters in
particular places in StatelessXmlReporter.java.
Regarding memory consumption system-out may consume really a lot of memory.
Therefore this is my proposal:

@XmlJavaTypeAdapter(CdataSystemAdapter.class)
public Utf8RecodingDeferredFileOutputStream getSystemOut()

class CdataSystemAdapter
WeakReference with   utf8RecodingDeferredFileOutputStream.writeTo( stream )
return ""


That would still create a string in memory, won't it?


[1]
https://maven.apache.org/surefire/maven-surefire-plugin/xsd/surefire-test-report.xsd


This needs a rewrite, too much duplication, no typing but xs:string only.


On Sun, Apr 16, 2017 at 2:43 PM, michaelo [via Maven] <
ml-node+s40175n5906482...@n5.nabble.com> wrote:


Am 2017-04-16 um 14:21 schrieb Tibor Digana:


Hi,

I want to first talk with you about XML marshaller StatelessXmlReporter

[1]

in Surefire which is built on the top of SharedUtils'

PrettyPrintXMLWriter.


I found out issues after a contributor opened this issue [2].

The problem is that we are using two streams, OutputStream and Writer,

to

create XML in file system for one reason. We write CDATA directly to the
stream apart of xml facility. We have bug with escaping illegal

characters.


Instead, my proposal is to create XSD and Jaxb stubs and marshal it to

XML

file and we do need to care about low level XML and escaping characters.
The code will be easier to understand. The elements system-out and
system-err can be large but we have the stream already in temp files
Utf8RecodingDeferredFileOutputStream which means that the Jaxb

mashaller

will not keep String in memory too long - only while Marshaller needs

the

string.

What is your opinion?


Looking at the current code -- a lot of boilerplate. I am quite
experienced with JAXB, XJC and the Maven JAXB2 Plugin [1].

Consider that JAXB always holds the model in memory. If you intend to
maintain streams within an XML you can resort fragments and other stuff
MOXy supports. But let me tell you that it won't be that easy as you
think if you want everything as streaming with little memory usage.

Michael

BTW: this should go to dev@

[1] https://github.com/highsource/maven-jaxb2-plugin

-
To unsubscribe, e-mail: [hidden email]

For additional commands, e-mail: [hidden email]




--
If you reply to this email, your message will be added to the discussion
below:
http://maven.40175.n5.nabble.com/Re-rewrite-StatelessXmlReporter-fo-JAXB-
tp5906482.html
To start a new topic under Maven Developers, email
ml-node+s40175n142166...@n5.nabble.com
To unsubscribe from Maven Developers, click here

.
NAML







--
View this message in context: 
http://maven.40175.n5.nabble.com/Re-rewrite-StatelessXmlReporter-fo-JAXB-tp5906482p5906521.html
Sent from the Maven Developers mailing list archive at Nabble.com.




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

Re: rewrite StatelessXmlReporter fo JAXB

Since we have XSD [1] we can generate classes and call setters in
particular places in StatelessXmlReporter.java.
Regarding memory consumption system-out may consume really a lot of memory.
Therefore this is my proposal:

@XmlJavaTypeAdapter(CdataSystemAdapter.class)
public Utf8RecodingDeferredFileOutputStream getSystemOut()

class CdataSystemAdapter
WeakReference with   utf8RecodingDeferredFileOutputStream.writeTo( stream )
return ""

[1]
https://maven.apache.org/surefire/maven-surefire-plugin/xsd/surefire-test-report.xsd




On Sun, Apr 16, 2017 at 2:43 PM, michaelo [via Maven] <
ml-node+s40175n5906482...@n5.nabble.com> wrote:

> Am 2017-04-16 um 14:21 schrieb Tibor Digana:
>
> > Hi,
> >
> > I want to first talk with you about XML marshaller StatelessXmlReporter
> [1]
> > in Surefire which is built on the top of SharedUtils'
> PrettyPrintXMLWriter.
> >
> > I found out issues after a contributor opened this issue [2].
> >
> > The problem is that we are using two streams, OutputStream and Writer,
> to
> > create XML in file system for one reason. We write CDATA directly to the
> > stream apart of xml facility. We have bug with escaping illegal
> characters.
> >
> > Instead, my proposal is to create XSD and Jaxb stubs and marshal it to
> XML
> > file and we do need to care about low level XML and escaping characters.
> > The code will be easier to understand. The elements system-out and
> > system-err can be large but we have the stream already in temp files
> > Utf8RecodingDeferredFileOutputStream which means that the Jaxb
> mashaller
> > will not keep String in memory too long - only while Marshaller needs
> the
> > string.
> >
> > What is your opinion?
>
> Looking at the current code -- a lot of boilerplate. I am quite
> experienced with JAXB, XJC and the Maven JAXB2 Plugin [1].
>
> Consider that JAXB always holds the model in memory. If you intend to
> maintain streams within an XML you can resort fragments and other stuff
> MOXy supports. But let me tell you that it won't be that easy as you
> think if you want everything as streaming with little memory usage.
>
> Michael
>
> BTW: this should go to dev@
>
> [1] https://github.com/highsource/maven-jaxb2-plugin
>
> -
> To unsubscribe, e-mail: [hidden email]
> 
> For additional commands, e-mail: [hidden email]
> 
>
>
>
> --
> If you reply to this email, your message will be added to the discussion
> below:
> http://maven.40175.n5.nabble.com/Re-rewrite-StatelessXmlReporter-fo-JAXB-
> tp5906482.html
> To start a new topic under Maven Developers, email
> ml-node+s40175n142166...@n5.nabble.com
> To unsubscribe from Maven Developers, click here
> 
> .
> NAML
> 
>




--
View this message in context: 
http://maven.40175.n5.nabble.com/Re-rewrite-StatelessXmlReporter-fo-JAXB-tp5906482p5906521.html
Sent from the Maven Developers mailing list archive at Nabble.com.

Re: Publish Maven releases on SDKMAN!

2017-04-16 Thread Stephen Connolly

On Sun 16 Apr 2017 at 11:32, Marco Vermeulen  wrote:

> Hi Maven folks,
>
> I really haven't come here to start a flame war or to give justification
> about why/how I built SDKMAN. Even less, justifying why I gave it such a
> "silly" name. I have come here with friendly intent to help your community
> publish their own releases on SDKMAN. I've come back since I was urged to
> do so [1] recently on Twitter by the @ASFMavenProject account.


Twitter is not a good place for discussion.

We currently have 30 steps (some complex) to get a release out the door.

We want every committer capable of acting as release manager for core (I am
currently acting in that role because we had a failure to get releases out)

To adopt the push model would require:

1. Adding another step.
2. Either keeping shared credentials in a PMC only shared space (and
restrictions on release manager to PMC) or that the PMC has to step up and
take responsibility for *another* step
3. Even then, we have to remember to do it.

A pull model can be very simple: you can define the *exact* format of the
page on maven.apache.org. We use a template to populate the info. Every
time we release, the template will be regenerated as part of the site
release anyway (no extra manual step)

I want to remove steps from the release process, not add. Make it easy for
me to remove steps and you are my friend. Suggestions to add more do not
make me happy

Publishing
> is as simple as a small API call which can be handled by anyone wishing to
> take up this responsibility in your community.
>
> I won't be defending myself or arguing with anyone on this forum going
> forward. I'm simply asking you for help. Plain and simple. I won't be
> changing the way SDKMAN works, since it already works well and is very
> reliable. All our vendors love it, and are very happy to integrate with us.
> In the process we all win: vendors are given control of their own releases
> and get another channel to distribute their software free of charge, and
> users have a convenient easy-to-use way to install their favourite
> software. I get to stand in the middle and watch it all happen asking
> nothing in return. I like contributing my free time to make developers
> happy and easing their installation pains. This is what I do to make our
> open source world a better place.
>
> If anyone in the community wants to step up and help with this process,
> feel free to contact me and I would be more than happy to get you set up. I
> would issue some API credentials and this would empower you to do a simple
> REST call to make Maven available to all our users across all platforms.
> Feel free to send me a mail at ma...@sdkman.io
>
> Many thanks!
> Marco.
>
> [1] https://twitter.com/ASFMavenProject/status/851132246669103108
>
> On Sun, 16 Apr 2017 at 10:52 Aldrin Leal  wrote:
>
> > just fyi: github releases has an atom feed.
> >
> > https://github.com/apache/maven/releases.atom
> >
> > --
> > -- Aldrin Leal,  / http://about.me/aldrinleal
> >
> > On Sun, Apr 16, 2017 at 4:49 AM, Marco Vermeulen  >
> > wrote:
> >
> > > Hi Heinz,
> > >
> > > On Sun, 16 Apr 2017 at 08:41 Karl Heinz Marbaise 
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > > On 16/04/17 00:56, Marco Vermeulen wrote:
> > > > > Hi Maven folks,
> > > > >
> > > > > Some time ago I asked the Maven dev community whether they would be
> > > > willing
> > > > > to publish their releases on SDKMAN! [1] using our Vendor API [2].
> > > > > Unfortunately, my request was met with scepticism and ultimately
> > > resulted
> > > > > in no action taken.
> > > >
> > > > What happended out of the idea to scan automatically[1] for new
> > versions
> > > > and insert the data automatically via a crawler which can for example
> > > > scan maven central[2] where all releases of Maven will be distributed
> > > > (also there is a REST API on Maven Central)...or the distirbution
> > > pages...
> > > >
> > > >
> > > The idea to scan/crawl is not feasible for me as crawlers are brittle
> and
> > > time consuming to maintain. I provide SDKMAN in my spare time to help
> > > others, so don't want to spend my time maintaining something like this.
> > > Moreover, why write a piece of infrastructure when a simple API call
> from
> > > your side would do the trick? It would take almost no effort.
> > >
> > >
> > > >
> > > > [1]:
> https://www.mail-archive.com/dev@maven.apache.org/msg108018.html
> > > > [2]:
> > > >
> > > > http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.
> > > apache.maven%22%20AND%20a%3A%22apache-maven%22
> > > >
> > > >
> > > > >
> > > > > I would like to appeal to the Maven dev community again to take on
> > the
> > > > > responsibility of managing their own releases on our platform.
> > > >
> > > > Hm...maybe I misunderstand here a thing but which responsibily does
> the
> > > > Maven dev community has on your platform ?
> > > >
> >

Re: rewrite StatelessXmlReporter fo JAXB


Am 2017-04-16 um 14:21 schrieb Tibor Digana:

Hi,

I want to first talk with you about XML marshaller StatelessXmlReporter [1]
in Surefire which is built on the top of SharedUtils' PrettyPrintXMLWriter.

I found out issues after a contributor opened this issue [2].

The problem is that we are using two streams, OutputStream and Writer, to
create XML in file system for one reason. We write CDATA directly to the
stream apart of xml facility. We have bug with escaping illegal characters.

Instead, my proposal is to create XSD and Jaxb stubs and marshal it to XML
file and we do need to care about low level XML and escaping characters.
The code will be easier to understand. The elements system-out and
system-err can be large but we have the stream already in temp files
Utf8RecodingDeferredFileOutputStream which means that the Jaxb mashaller
will not keep String in memory too long - only while Marshaller needs the
string.

What is your opinion?


Looking at the current code -- a lot of boilerplate. I am quite 
experienced with JAXB, XJC and the Maven JAXB2 Plugin [1].


Consider that JAXB always holds the model in memory. If you intend to 
maintain streams within an XML you can resort fragments and other stuff 
MOXy supports. But let me tell you that it won't be that easy as you 
think if you want everything as streaming with little memory usage.


Michael

BTW: this should go to dev@

[1] https://github.com/highsource/maven-jaxb2-plugin

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

[GitHub] maven-surefire issue #147: Reporters use buffers to reduce number of I/O ope...

Github user Tibor17 commented on the issue:

https://github.com/apache/maven-surefire/pull/147
  
I am just discussing with ASF colleagues rewriting `StatelessXmlReporter` 
to JAXB.


---
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: Publish Maven releases on SDKMAN!

2017-04-16 Thread Marco Vermeulen

Hi Maven folks,

I really haven't come here to start a flame war or to give justification
about why/how I built SDKMAN. Even less, justifying why I gave it such a
"silly" name. I have come here with friendly intent to help your community
publish their own releases on SDKMAN. I've come back since I was urged to
do so [1] recently on Twitter by the @ASFMavenProject account. Publishing
is as simple as a small API call which can be handled by anyone wishing to
take up this responsibility in your community.

I won't be defending myself or arguing with anyone on this forum going
forward. I'm simply asking you for help. Plain and simple. I won't be
changing the way SDKMAN works, since it already works well and is very
reliable. All our vendors love it, and are very happy to integrate with us.
In the process we all win: vendors are given control of their own releases
and get another channel to distribute their software free of charge, and
users have a convenient easy-to-use way to install their favourite
software. I get to stand in the middle and watch it all happen asking
nothing in return. I like contributing my free time to make developers
happy and easing their installation pains. This is what I do to make our
open source world a better place.

If anyone in the community wants to step up and help with this process,
feel free to contact me and I would be more than happy to get you set up. I
would issue some API credentials and this would empower you to do a simple
REST call to make Maven available to all our users across all platforms.
Feel free to send me a mail at ma...@sdkman.io

Many thanks!
Marco.

[1] https://twitter.com/ASFMavenProject/status/851132246669103108

On Sun, 16 Apr 2017 at 10:52 Aldrin Leal  wrote:

> just fyi: github releases has an atom feed.
>
> https://github.com/apache/maven/releases.atom
>
> --
> -- Aldrin Leal,  / http://about.me/aldrinleal
>
> On Sun, Apr 16, 2017 at 4:49 AM, Marco Vermeulen 
> wrote:
>
> > Hi Heinz,
> >
> > On Sun, 16 Apr 2017 at 08:41 Karl Heinz Marbaise 
> > wrote:
> >
> > > Hi,
> > >
> > > On 16/04/17 00:56, Marco Vermeulen wrote:
> > > > Hi Maven folks,
> > > >
> > > > Some time ago I asked the Maven dev community whether they would be
> > > willing
> > > > to publish their releases on SDKMAN! [1] using our Vendor API [2].
> > > > Unfortunately, my request was met with scepticism and ultimately
> > resulted
> > > > in no action taken.
> > >
> > > What happended out of the idea to scan automatically[1] for new
> versions
> > > and insert the data automatically via a crawler which can for example
> > > scan maven central[2] where all releases of Maven will be distributed
> > > (also there is a REST API on Maven Central)...or the distirbution
> > pages...
> > >
> > >
> > The idea to scan/crawl is not feasible for me as crawlers are brittle and
> > time consuming to maintain. I provide SDKMAN in my spare time to help
> > others, so don't want to spend my time maintaining something like this.
> > Moreover, why write a piece of infrastructure when a simple API call from
> > your side would do the trick? It would take almost no effort.
> >
> >
> > >
> > > [1]: https://www.mail-archive.com/dev@maven.apache.org/msg108018.html
> > > [2]:
> > >
> > > http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.
> > apache.maven%22%20AND%20a%3A%22apache-maven%22
> > >
> > >
> > > >
> > > > I would like to appeal to the Maven dev community again to take on
> the
> > > > responsibility of managing their own releases on our platform.
> > >
> > > Hm...maybe I misunderstand here a thing but which responsibily does the
> > > Maven dev community has on your platform ?
> > >
> > >  From my personell point view: none
> > >
> >
> > The maven community has no responsibility, I am asking your community for
> > help. I'm asking you in a friendly manner to take on the responsibility
> of
> > publishing, you misunderstood my intent.
> >
> >
> > >
> > >  > The process
> > > > is very simple: It involves making a few REST calls to our API and
> > > > instantaneously releases become available for all the SDKMAN! users
> out
> > > > there.
> > >
> > > This is the point which is the problem...or the "scepticism" you
> > > mentioned...
> > >
> > > To be honest you seemed to be ignoring the suggestions for improvements
> > > on your platform which could make it easier to integrate parts on your
> > > platform...not only for us also for many other tools...which would
> > > improve the accepting for the support of your platform...
> > >
> >
> > All the others communities out there were more than happy to do the API
> > call. This community being the first out of all the others to show any
> > resistance. Empowering SDK vendors by exposing an API seems by far more
> > preferred among our vendors as it puts them in control of their own
> > releases. Releases become available fast and reliably, and they have full
> > control

Re: Publish Maven releases on SDKMAN!

2017-04-16 Thread Aldrin Leal

just fyi: github releases has an atom feed.

https://github.com/apache/maven/releases.atom

--
-- Aldrin Leal,  / http://about.me/aldrinleal

On Sun, Apr 16, 2017 at 4:49 AM, Marco Vermeulen 
wrote:

> Hi Heinz,
>
> On Sun, 16 Apr 2017 at 08:41 Karl Heinz Marbaise 
> wrote:
>
> > Hi,
> >
> > On 16/04/17 00:56, Marco Vermeulen wrote:
> > > Hi Maven folks,
> > >
> > > Some time ago I asked the Maven dev community whether they would be
> > willing
> > > to publish their releases on SDKMAN! [1] using our Vendor API [2].
> > > Unfortunately, my request was met with scepticism and ultimately
> resulted
> > > in no action taken.
> >
> > What happended out of the idea to scan automatically[1] for new versions
> > and insert the data automatically via a crawler which can for example
> > scan maven central[2] where all releases of Maven will be distributed
> > (also there is a REST API on Maven Central)...or the distirbution
> pages...
> >
> >
> The idea to scan/crawl is not feasible for me as crawlers are brittle and
> time consuming to maintain. I provide SDKMAN in my spare time to help
> others, so don't want to spend my time maintaining something like this.
> Moreover, why write a piece of infrastructure when a simple API call from
> your side would do the trick? It would take almost no effort.
>
>
> >
> > [1]: https://www.mail-archive.com/dev@maven.apache.org/msg108018.html
> > [2]:
> >
> > http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.
> apache.maven%22%20AND%20a%3A%22apache-maven%22
> >
> >
> > >
> > > I would like to appeal to the Maven dev community again to take on the
> > > responsibility of managing their own releases on our platform.
> >
> > Hm...maybe I misunderstand here a thing but which responsibily does the
> > Maven dev community has on your platform ?
> >
> >  From my personell point view: none
> >
>
> The maven community has no responsibility, I am asking your community for
> help. I'm asking you in a friendly manner to take on the responsibility of
> publishing, you misunderstood my intent.
>
>
> >
> >  > The process
> > > is very simple: It involves making a few REST calls to our API and
> > > instantaneously releases become available for all the SDKMAN! users out
> > > there.
> >
> > This is the point which is the problem...or the "scepticism" you
> > mentioned...
> >
> > To be honest you seemed to be ignoring the suggestions for improvements
> > on your platform which could make it easier to integrate parts on your
> > platform...not only for us also for many other tools...which would
> > improve the accepting for the support of your platform...
> >
>
> All the others communities out there were more than happy to do the API
> call. This community being the first out of all the others to show any
> resistance. Empowering SDK vendors by exposing an API seems by far more
> preferred among our vendors as it puts them in control of their own
> releases. Releases become available fast and reliably, and they have full
> control over this.
>
>
> >
> > In earlier days you have declined[1] to support maven at all now you
> > have changed your mind which of course is fine...
> >
>
> Yes, I changed my mind because I was urged [1] to do so on twitter by your
> very own twitter account.
>
> [1] https://twitter.com/ASFMavenProject/status/851132246669103108
>
>
>
> > [3]: https://issues.apache.org/jira/browse/MNG-5749
> >
> > >
> > > Many other teams are already doing this, including Gradle, Kotlin,
> > Groovy,
> > > Ceylon and Spring Boot to name a few. It would be great to have you
> guys
> > on
> > > board too.
> > >
> > > I currently perform these releases for Maven manually, which
> > unfortunately
> > > is not something I can sustain going forward.
> >
> > If the sdkman user community has already asked for support why don't you
> > solve the problem ?
> >
> >
> The problem has long been solved by us exposing an API. The problem here
> seems to be with an insular community who does not want to reach out to
> others to help. In this case, by making a simple API call at release time.
>
>
> > In three ways. Removing the manuall work for yourself, the acceptance of
> > your platform to support more tools and finally fulfill the need of your
> > user community...(Which I think is the most important part here).
> >
> > In particular if it could be done by using a curl call on maven central
> > or a little bit more if you like to scan the
> > http://maven.apache.org/docs/history.html page (jsoup is very easy) from
> > your site...
> >
> > In a nutshell I would say why not implementing a scan service yourself
> > which takes some time, but I got the impression that writing all these
> > mails/tickets etc. and discussions takes more time than implementing
> > such a service...
> >
>
> In a nutshell, from a software engineering perspective a push (API) is
> always preferred to a pull (crawler). I have enabled push on our platform
> and all

Re: Publish Maven releases on SDKMAN!

2017-04-16 Thread Marco Vermeulen

Hi Heinz,

On Sun, 16 Apr 2017 at 08:41 Karl Heinz Marbaise  wrote:

> Hi,
>
> On 16/04/17 00:56, Marco Vermeulen wrote:
> > Hi Maven folks,
> >
> > Some time ago I asked the Maven dev community whether they would be
> willing
> > to publish their releases on SDKMAN! [1] using our Vendor API [2].
> > Unfortunately, my request was met with scepticism and ultimately resulted
> > in no action taken.
>
> What happended out of the idea to scan automatically[1] for new versions
> and insert the data automatically via a crawler which can for example
> scan maven central[2] where all releases of Maven will be distributed
> (also there is a REST API on Maven Central)...or the distirbution pages...
>
>
The idea to scan/crawl is not feasible for me as crawlers are brittle and
time consuming to maintain. I provide SDKMAN in my spare time to help
others, so don't want to spend my time maintaining something like this.
Moreover, why write a piece of infrastructure when a simple API call from
your side would do the trick? It would take almost no effort.


>
> [1]: https://www.mail-archive.com/dev@maven.apache.org/msg108018.html
> [2]:
>
> http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.apache.maven%22%20AND%20a%3A%22apache-maven%22
>
>
> >
> > I would like to appeal to the Maven dev community again to take on the
> > responsibility of managing their own releases on our platform.
>
> Hm...maybe I misunderstand here a thing but which responsibily does the
> Maven dev community has on your platform ?
>
>  From my personell point view: none
>

The maven community has no responsibility, I am asking your community for
help. I'm asking you in a friendly manner to take on the responsibility of
publishing, you misunderstood my intent.


>
>  > The process
> > is very simple: It involves making a few REST calls to our API and
> > instantaneously releases become available for all the SDKMAN! users out
> > there.
>
> This is the point which is the problem...or the "scepticism" you
> mentioned...
>
> To be honest you seemed to be ignoring the suggestions for improvements
> on your platform which could make it easier to integrate parts on your
> platform...not only for us also for many other tools...which would
> improve the accepting for the support of your platform...
>

All the others communities out there were more than happy to do the API
call. This community being the first out of all the others to show any
resistance. Empowering SDK vendors by exposing an API seems by far more
preferred among our vendors as it puts them in control of their own
releases. Releases become available fast and reliably, and they have full
control over this.


>
> In earlier days you have declined[1] to support maven at all now you
> have changed your mind which of course is fine...
>

Yes, I changed my mind because I was urged [1] to do so on twitter by your
very own twitter account.

[1] https://twitter.com/ASFMavenProject/status/851132246669103108



> [3]: https://issues.apache.org/jira/browse/MNG-5749
>
> >
> > Many other teams are already doing this, including Gradle, Kotlin,
> Groovy,
> > Ceylon and Spring Boot to name a few. It would be great to have you guys
> on
> > board too.
> >
> > I currently perform these releases for Maven manually, which
> unfortunately
> > is not something I can sustain going forward.
>
> If the sdkman user community has already asked for support why don't you
> solve the problem ?
>
>
The problem has long been solved by us exposing an API. The problem here
seems to be with an insular community who does not want to reach out to
others to help. In this case, by making a simple API call at release time.


> In three ways. Removing the manuall work for yourself, the acceptance of
> your platform to support more tools and finally fulfill the need of your
> user community...(Which I think is the most important part here).
>
> In particular if it could be done by using a curl call on maven central
> or a little bit more if you like to scan the
> http://maven.apache.org/docs/history.html page (jsoup is very easy) from
> your site...
>
> In a nutshell I would say why not implementing a scan service yourself
> which takes some time, but I got the impression that writing all these
> mails/tickets etc. and discussions takes more time than implementing
> such a service...
>

In a nutshell, from a software engineering perspective a push (API) is
always preferred to a pull (crawler). I have enabled push on our platform
and all the other software providers have loved it. Subsequently none have
hesitated to adopted it. I won't be implementing an inferior pull model
anytime soon, especially as this problem has already been solved very
elegantly with an easy push.


>
> Kind regards
> Karl Heinz Marbaise
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Publish Maven releases on SDKMAN!

2017-04-16 Thread Aldrin Leal

Ironically, I've ported nvm (for node), but for Maven
, but ended up using sdkman later.

I wonder if it would be interesting to have a service to generate webhooks
and rss feeds for new versions/releases on github and apache overall.

--
-- Aldrin Leal,  / http://about.me/aldrinleal

On Sun, Apr 16, 2017 at 2:41 AM, Karl Heinz Marbaise 
wrote:

> Hi,
>
> On 16/04/17 00:56, Marco Vermeulen wrote:
>
>> Hi Maven folks,
>>
>> Some time ago I asked the Maven dev community whether they would be
>> willing
>> to publish their releases on SDKMAN! [1] using our Vendor API [2].
>> Unfortunately, my request was met with scepticism and ultimately resulted
>> in no action taken.
>>
>
> What happended out of the idea to scan automatically[1] for new versions
> and insert the data automatically via a crawler which can for example scan
> maven central[2] where all releases of Maven will be distributed (also
> there is a REST API on Maven Central)...or the distirbution pages...
>
>
> [1]: https://www.mail-archive.com/dev@maven.apache.org/msg108018.html
> [2]: http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.apach
> e.maven%22%20AND%20a%3A%22apache-maven%22
>
>
>
>> I would like to appeal to the Maven dev community again to take on the
>> responsibility of managing their own releases on our platform.
>>
>
> Hm...maybe I misunderstand here a thing but which responsibily does the
> Maven dev community has on your platform ?
>
> From my personell point view: none
>
> > The process
>
>> is very simple: It involves making a few REST calls to our API and
>> instantaneously releases become available for all the SDKMAN! users out
>> there.
>>
>
> This is the point which is the problem...or the "scepticism" you
> mentioned...
>
> To be honest you seemed to be ignoring the suggestions for improvements on
> your platform which could make it easier to integrate parts on your
> platform...not only for us also for many other tools...which would improve
> the accepting for the support of your platform...
>
> In earlier days you have declined[1] to support maven at all now you have
> changed your mind which of course is fine...
>
> [3]: https://issues.apache.org/jira/browse/MNG-5749
>
>
>> Many other teams are already doing this, including Gradle, Kotlin, Groovy,
>> Ceylon and Spring Boot to name a few. It would be great to have you guys
>> on
>> board too.
>>
>> I currently perform these releases for Maven manually, which unfortunately
>> is not something I can sustain going forward.
>>
>
> If the sdkman user community has already asked for support why don't you
> solve the problem ?
>
> In three ways. Removing the manuall work for yourself, the acceptance of
> your platform to support more tools and finally fulfill the need of your
> user community...(Which I think is the most important part here).
>
> In particular if it could be done by using a curl call on maven central or
> a little bit more if you like to scan the http://maven.apache.org/docs/h
> istory.html page (jsoup is very easy) from your site...
>
> In a nutshell I would say why not implementing a scan service yourself
> which takes some time, but I got the impression that writing all these
> mails/tickets etc. and discussions takes more time than implementing such a
> service...
>
>
> Kind regards
> Karl Heinz Marbaise
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Publish Maven releases on SDKMAN!

2017-04-16 Thread Karl Heinz Marbaise

Hi,

On 16/04/17 00:56, Marco Vermeulen wrote:

Hi Maven folks,

Some time ago I asked the Maven dev community whether they would be willing
to publish their releases on SDKMAN! [1] using our Vendor API [2].
Unfortunately, my request was met with scepticism and ultimately resulted
in no action taken.

What happended out of the idea to scan automatically[1] for new versions
and insert the data automatically via a crawler which can for example
scan maven central[2] where all releases of Maven will be distributed
(also there is a REST API on Maven Central)...or the distirbution pages...

[1]: https://www.mail-archive.com/dev@maven.apache.org/msg108018.html
[2]:
http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.apache.maven%22%20AND%20a%3A%22apache-maven%22

I would like to appeal to the Maven dev community again to take on the
responsibility of managing their own releases on our platform.

Hm...maybe I misunderstand here a thing but which responsibily does the
Maven dev community has on your platform ?

From my personell point view: none

> The process

is very simple: It involves making a few REST calls to our API and
instantaneously releases become available for all the SDKMAN! users out
there.

This is the point which is the problem...or the "scepticism" you
mentioned...

To be honest you seemed to be ignoring the suggestions for improvements
on your platform which could make it easier to integrate parts on your
platform...not only for us also for many other tools...which would
improve the accepting for the support of your platform...

In earlier days you have declined[1] to support maven at all now you
have changed your mind which of course is fine...

[3]: https://issues.apache.org/jira/browse/MNG-5749

Many other teams are already doing this, including Gradle, Kotlin, Groovy,
Ceylon and Spring Boot to name a few. It would be great to have you guys on
board too.

I currently perform these releases for Maven manually, which unfortunately
is not something I can sustain going forward.

If the sdkman user community has already asked for support why don't you
solve the problem ?

In three ways. Removing the manuall work for yourself, the acceptance of
your platform to support more tools and finally fulfill the need of your
user community...(Which I think is the most important part here).

In particular if it could be done by using a curl call on maven central
or a little bit more if you like to scan the
http://maven.apache.org/docs/history.html page (jsoup is very easy) from
your site...

In a nutshell I would say why not implementing a scan service yourself
which takes some time, but I got the impression that writing all these
mails/tickets etc. and discussions takes more time than implementing
such a service...

Kind regards
Karl Heinz Marbaise

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

[GitHub] maven-surefire pull request #147: Reporters use buffers to reduce number of ...

Github user jerrinot commented on a diff in the pull request:

https://github.com/apache/maven-surefire/pull/147#discussion_r111679651
  
--- Diff: 
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/report/StatelessXmlReporter.java
 ---
@@ -292,15 +293,15 @@ private FileOutputStream getOutputStream( 
WrappedReportEntry testSetReportEntry
 
 try
 {
-return new FileOutputStream( reportFile );
+return new BufferedOutputStream( new FileOutputStream( 
reportFile ), 16 * 1024 );
--- End diff --

Is this relevant for this changeset? I agree the reporter should use either 
directly the stream or the writer. However I see this as a separate problem. 

I can have a look at it as well, but it appears rather tricky and I would 
like to have it isolated from this very change. See this part: 
https://github.com/jerrinot/maven-surefire/blob/b66b524a42d6cbc2b23225d72b67671d25d3fc05/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/report/StatelessXmlReporter.java#L442-L442


---
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

[GitHub] maven-surefire issue #147: Reporters use buffers to reduce number of I/O ope...

Github user jerrinot commented on the issue:

https://github.com/apache/maven-surefire/pull/147
  
@Tibor17: thanks a lot for a quick review, I updated the PR.


---
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

[GitHub] maven-surefire pull request #147: Reporters use buffers to reduce number of ...