Re: I think we are ready for 3.5.0-alpha-1

2017-02-17 Thread Tibor Digana 
-1: fix pending bugs, otherwise users will report more bugs
For instance Robert said the above fix was a workaround.

On Fri, Feb 17, 2017 at 7:18 PM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> Would it help yet to cut an alpha and start tracking bugs?
>
> I am starting to be concerned that the collective of volunteers are on a
> death march with no end in site... so I am seeking ways to identify an end
> where we can cut 3.5.0 and start on 3.5.1
>
> I don't want to be here in 2-3 weeks and still not even a 3.5.0-alpha-1
> that users could start testing
>
> On Fri 17 Feb 2017 at 18:10, Michael Osipov  wrote:
>
> > Am 2017-02-17 um 18:03 schrieb Arnaud Héritier:
> > > Is there someone who tried to deploy a "large" artifact ?
> > >
> > > I have a bug in 3.5 and not in 3.3.9 but for now no time to dig
> > >
> > > The project : https://github.com/jenkinsci/maven-plugin
> > > Downloading:
> > >
> > https://repo.jenkins-ci.org/snapshots/org/jenkins-ci/main/
> maven-plugin/2.16-SNAPSHOT/maven-metadata.xml
> > > Downloaded:
> > >
> > https://repo.jenkins-ci.org/snapshots/org/jenkins-ci/main/
> maven-plugin/2.16-SNAPSHOT/maven-metadata.xml
> > > (929 B at 1.5 kB/s)
> > > Uploading:
> > >
> > https://repo.jenkins-ci.org/snapshots/org/jenkins-ci/main/
> maven-plugin/2.16-SNAPSHOT/maven-plugin-2.16-20170217.170023-3.hpi
> > > [INFO] I/O exception (java.net.SocketException) caught when processing
> > > request to {s}->https://repo.jenkins-ci.org:443: Broken pipe (Write
> > failed)
> > > [INFO] Retrying request to {s}->https://repo.jenkins-ci.org:443
> > > [INFO] I/O exception (java.net.SocketException) caught when processing
> > > request to {s}->https://repo.jenkins-ci.org:443: Broken pipe (Write
> > failed)
> > > [INFO] Retrying request to {s}->https://repo.jenkins-ci.org:443
> > > [INFO] I/O exception (java.net.SocketException) caught when processing
> > > request to {s}->https://repo.jenkins-ci.org:443: Broken pipe (Write
> > failed)
> > > [INFO] Retrying request to {s}->https://repo.jenkins-ci.org:443
> >
> > In Wagon 2.12 Apache HttpComponents have been upgraded:
> > > diff --git a/wagon-providers/pom.xml b/wagon-providers/pom.xml
> > > index 1995fb7..e29dd55 100644
> > > --- a/wagon-providers/pom.xml
> > > +++ b/wagon-providers/pom.xml
> > > @@ -23,7 +23,7 @@ under the License.
> > >
> > >  org.apache.maven.wagon
> > >  wagon
> > > -2.10
> > > +2.12
> > >  ../pom.xml
> > >
> > >
> > > @@ -50,12 +50,12 @@ under the License.
> > >
> > >  org.apache.httpcomponents
> > >  httpclient
> > > -4.3.5
> > > +4.5.2
> > >
> > >
> > >  org.apache.httpcomponents
> > >  httpcore
> > > -4.3.2
> > > +4.4.4
> > >
> > >
> > >  org.apache.sshd
> >
> > Additionally, the log dependencies where incorrectly configured which
> > has been corrected in another ticket.
> >
> > Finally, we have a HugeFileDownloadTest which downloads a 4 GiB large
> > file, we can easily add a HugeFileUploadTest.
> >
> > Looking at the log messages issued by the HttpComponents, you have a
> > network issue. Somewhere between you and the Artifactory instance the
> > connection has been terminated (broken pipe).
> >
> > Can you repeat this issue realiably?
> >
> > Michael
> >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> > --
> Sent from my phone
>



-- 
Cheers
Tibor

Re: I think we are ready for 3.5.0-alpha-1

2017-02-17 Thread Hervé BOUTEMY 
one question I have on this is: how do we want to track issues in Jira?
Do we let 3.5.0 open (with its 65 issues) or do we release it renamed as 
3.5.0-alpha-1?
Do we create a 3.5.0-alpha-1 version just to mark bugs found in 3.5.0-alpha-1 
as "affects version"?

Regards,

Hervé

Le samedi 18 février 2017, 08:06:03 CET Hervé BOUTEMY a écrit :
> if we go with the "alpha-1" road, let's use the benefit: it may have some
> little issues
> 
> then +1 to cut alpha-1 now
> 
> Regards,
> 
> Hervé
> 
> Le vendredi 17 février 2017, 18:57:18 CET Arnaud Héritier a écrit :
> > +1 for to have the cat out of the box !!!
> > 
> > Le ven. 17 févr. 2017 à 19:19, Stephen Connolly <
> > 
> > stephen.alan.conno...@gmail.com> a écrit :
> > > Would it help yet to cut an alpha and start tracking bugs?
> > > 
> > > I am starting to be concerned that the collective of volunteers are on a
> > > death march with no end in site... so I am seeking ways to identify an
> > > end
> > > where we can cut 3.5.0 and start on 3.5.1
> > > 
> > > I don't want to be here in 2-3 weeks and still not even a 3.5.0-alpha-1
> > > that users could start testing
> > > 
> > > On Fri 17 Feb 2017 at 18:10, Michael Osipov  wrote:
> > > > Am 2017-02-17 um 18:03 schrieb Arnaud Héritier:
> > > > > Is there someone who tried to deploy a "large" artifact ?
> > > > > 
> > > > > I have a bug in 3.5 and not in 3.3.9 but for now no time to dig
> > > > > 
> > > > > The project : https://github.com/jenkinsci/maven-plugin
> > > 
> > > > > Downloading:
> > > https://repo.jenkins-ci.org/snapshots/org/jenkins-ci/main/maven-plugin/2
> > > .1
> > > 6-SNAPSHOT/maven-metadata.xml>
> > > 
> > > > > Downloaded:
> > > https://repo.jenkins-ci.org/snapshots/org/jenkins-ci/main/maven-plugin/2
> > > .1
> > > 6-SNAPSHOT/maven-metadata.xml>
> > > 
> > > > > (929 B at 1.5 kB/s)
> > > 
> > > > > Uploading:
> > > https://repo.jenkins-ci.org/snapshots/org/jenkins-ci/main/maven-plugin/2
> > > .1
> > > 6-SNAPSHOT/maven-plugin-2.16-20170217.170023-3.hpi>
> > > 
> > > > > [INFO] I/O exception (java.net.SocketException) caught when
> > > > > processing
> > > > > request to {s}->https://repo.jenkins-ci.org:443: Broken pipe (Write
> > > > 
> > > > failed)
> > > > 
> > > > > [INFO] Retrying request to {s}->https://repo.jenkins-ci.org:443
> > > > > [INFO] I/O exception (java.net.SocketException) caught when
> > > > > processing
> > > > > request to {s}->https://repo.jenkins-ci.org:443: Broken pipe (Write
> > > > 
> > > > failed)
> > > > 
> > > > > [INFO] Retrying request to {s}->https://repo.jenkins-ci.org:443
> > > > > [INFO] I/O exception (java.net.SocketException) caught when
> > > > > processing
> > > > > request to {s}->https://repo.jenkins-ci.org:443: Broken pipe (Write
> > > > 
> > > > failed)
> > > > 
> > > > > [INFO] Retrying request to {s}->https://repo.jenkins-ci.org:443
> > > > 
> > > > In Wagon 2.12 Apache HttpComponents have been upgraded:
> > > > > diff --git a/wagon-providers/pom.xml b/wagon-providers/pom.xml
> > > > > index 1995fb7..e29dd55 100644
> > > > > --- a/wagon-providers/pom.xml
> > > > > +++ b/wagon-providers/pom.xml
> > > > > @@ -23,7 +23,7 @@ under the License.
> > > > > 
> > > > >
> > > > >
> > > > >  org.apache.maven.wagon
> > > > >  wagon
> > > > > 
> > > > > -2.10
> > > > > +2.12
> > > > > 
> > > > >  ../pom.xml
> > > > >
> > > > >
> > > > > 
> > > > > @@ -50,12 +50,12 @@ under the License.
> > > > > 
> > > > >
> > > > >
> > > > >  org.apache.httpcomponents
> > > > >  httpclient
> > > > > 
> > > > > -4.3.5
> > > > > +4.5.2
> > > > > 
> > > > >
> > > > >
> > > > >
> > > > >  org.apache.httpcomponents
> > > > >  httpcore
> > > > > 
> > > > > -4.3.2
> > > > > +4.4.4
> > > > > 
> > > > >
> > > > >
> > > > >
> > > > >  org.apache.sshd
> > > > 
> > > > Additionally, the log dependencies where incorrectly configured which
> > > > has been corrected in another ticket.
> > > > 
> > > > Finally, we have a HugeFileDownloadTest which downloads a 4 GiB large
> > > > file, we can easily add a HugeFileUploadTest.
> > > > 
> > > > Looking at the log messages issued by the HttpComponents, you have a
> > > > network issue. Somewhere between you and the Artifactory instance the
> > > > connection has been terminated (broken pipe).
> > > > 
> > > > Can you repeat this issue realiably?
> > > > 
> > > > Michael
> > > > 
> > > > 
> > > > 
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > > For additional commands, e-mail: dev-h...@maven.apache.org
> > > > 
> > > > --
> > > 
> > > Sent from my phone
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org

Re: I think we are ready for 3.5.0-alpha-1

2017-02-17 Thread Hervé BOUTEMY 
if we go with the "alpha-1" road, let's use the benefit: it may have some 
little issues

then +1 to cut alpha-1 now

Regards,

Hervé

Le vendredi 17 février 2017, 18:57:18 CET Arnaud Héritier a écrit :
> +1 for to have the cat out of the box !!!
> 
> Le ven. 17 févr. 2017 à 19:19, Stephen Connolly <
> 
> stephen.alan.conno...@gmail.com> a écrit :
> > Would it help yet to cut an alpha and start tracking bugs?
> > 
> > I am starting to be concerned that the collective of volunteers are on a
> > death march with no end in site... so I am seeking ways to identify an end
> > where we can cut 3.5.0 and start on 3.5.1
> > 
> > I don't want to be here in 2-3 weeks and still not even a 3.5.0-alpha-1
> > that users could start testing
> > 
> > On Fri 17 Feb 2017 at 18:10, Michael Osipov  wrote:
> > > Am 2017-02-17 um 18:03 schrieb Arnaud Héritier:
> > > > Is there someone who tried to deploy a "large" artifact ?
> > > > 
> > > > I have a bug in 3.5 and not in 3.3.9 but for now no time to dig
> > > > 
> > > > The project : https://github.com/jenkinsci/maven-plugin
> > 
> > > > Downloading:
> > https://repo.jenkins-ci.org/snapshots/org/jenkins-ci/main/maven-plugin/2.1
> > 6-SNAPSHOT/maven-metadata.xml> 
> > > > Downloaded:
> > https://repo.jenkins-ci.org/snapshots/org/jenkins-ci/main/maven-plugin/2.1
> > 6-SNAPSHOT/maven-metadata.xml> 
> > > > (929 B at 1.5 kB/s)
> > 
> > > > Uploading:
> > https://repo.jenkins-ci.org/snapshots/org/jenkins-ci/main/maven-plugin/2.1
> > 6-SNAPSHOT/maven-plugin-2.16-20170217.170023-3.hpi> 
> > > > [INFO] I/O exception (java.net.SocketException) caught when processing
> > > > request to {s}->https://repo.jenkins-ci.org:443: Broken pipe (Write
> > > 
> > > failed)
> > > 
> > > > [INFO] Retrying request to {s}->https://repo.jenkins-ci.org:443
> > > > [INFO] I/O exception (java.net.SocketException) caught when processing
> > > > request to {s}->https://repo.jenkins-ci.org:443: Broken pipe (Write
> > > 
> > > failed)
> > > 
> > > > [INFO] Retrying request to {s}->https://repo.jenkins-ci.org:443
> > > > [INFO] I/O exception (java.net.SocketException) caught when processing
> > > > request to {s}->https://repo.jenkins-ci.org:443: Broken pipe (Write
> > > 
> > > failed)
> > > 
> > > > [INFO] Retrying request to {s}->https://repo.jenkins-ci.org:443
> > > 
> > > In Wagon 2.12 Apache HttpComponents have been upgraded:
> > > > diff --git a/wagon-providers/pom.xml b/wagon-providers/pom.xml
> > > > index 1995fb7..e29dd55 100644
> > > > --- a/wagon-providers/pom.xml
> > > > +++ b/wagon-providers/pom.xml
> > > > @@ -23,7 +23,7 @@ under the License.
> > > > 
> > > >
> > > >
> > > >  org.apache.maven.wagon
> > > >  wagon
> > > > 
> > > > -2.10
> > > > +2.12
> > > > 
> > > >  ../pom.xml
> > > >
> > > >
> > > > 
> > > > @@ -50,12 +50,12 @@ under the License.
> > > > 
> > > >
> > > >
> > > >  org.apache.httpcomponents
> > > >  httpclient
> > > > 
> > > > -4.3.5
> > > > +4.5.2
> > > > 
> > > >
> > > >
> > > >
> > > >  org.apache.httpcomponents
> > > >  httpcore
> > > > 
> > > > -4.3.2
> > > > +4.4.4
> > > > 
> > > >
> > > >
> > > >
> > > >  org.apache.sshd
> > > 
> > > Additionally, the log dependencies where incorrectly configured which
> > > has been corrected in another ticket.
> > > 
> > > Finally, we have a HugeFileDownloadTest which downloads a 4 GiB large
> > > file, we can easily add a HugeFileUploadTest.
> > > 
> > > Looking at the log messages issued by the HttpComponents, you have a
> > > network issue. Somewhere between you and the Artifactory instance the
> > > connection has been terminated (broken pipe).
> > > 
> > > Can you repeat this issue realiably?
> > > 
> > > Michael
> > > 
> > > 
> > > 
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > > 
> > > --
> > 
> > Sent from my phone



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

Re: Fwd: How to name modules, automatic and otherwise

2017-02-17 Thread Hervé BOUTEMY 
there is some level of misunderstanding

my proposal is not to force any default value: just check (for people 
publishing to Central) that chosen value starts with groupId


then, in some Maven plugin, we can independently propose magic help to propose 
auto-calculated default values to people using Maven, that will be injected in 
Module-Name: since this Maven plugin will respect the previous Central 
convention (value starts with groupId), this will be ok.

I'm not sure that proposing automagic values for target module names (ie not 
automodule names derived from file name) is safe: when a developper wants to 
really take Java 9 module names in consideration (either by migrating to a 
real module, either by defining a Module-Name property in his manifest), he 
really has to know that he's committed to this name. If the white magic 
algorithm to propose a name does not find a name that has human sense (for 
whatever reason), that will be problematic.

Notice that the fact that you seem to propose an algorigthm where the 
generated name has a colon in it surprised me: are colons accepted in a Jigsaw 
module name?


Notice 2:
I like the proposal of Module-Name MANIFEST.MF property to let a developper 
influence the name of his automodule, without migrating to Jigsaw yet: very 
nice idea

Regards,

Hervé

Le vendredi 17 février 2017, 09:01:46 CET Brian Fox a écrit :
> Hervé: I feel like I don't completely understand the proposal, but I feel
> like we can achieve your intent using the Module-Name simply by defaulting
> it to g:a and building up a good base of new stuff going into Central such
> that when people start using jigsaw, there is a good pattern in place and
> we've hopefully avoided conflicts.
> 
> Am I mis-understanding your proposal?
> 
> On Thu, Feb 16, 2017 at 8:51 PM, Hervé BOUTEMY 
> 
> wrote:
> > tuesday, I was at a Jigsaw presentation from Remi Forax in France, where
> > the
> > fact that nothing was taken into consideration looked something that was
> > happenning (and the recent publication shows that it has happened now)
> > 
> > Then Remi and I discussed and looked for ideas on what lighter proposal to
> > do
> > for the namespace concern when sharing modules publicly
> > 
> > And I proposed a simplified idea that looked promising when we challenged
> > 
> > it:
> > for modules that are to be shared on Maven Central,
> > handwritten full module name should *start with groupId*
> > 
> > applied to the example for Hibernate, this would just say: Hibernate
> > project
> > owns "org.hibernate" module namespace on [Maven] Central since they own
> > org.hibernate groupId
> > 
> > Notice: automodules won't give same module names. Automodules are just
> > transient automagic values for temporary local work, not for public shared
> > work
> > 
> > Notice 2: whatever does not go to [Maven] Central has just other
> > conventions.
> > Knowing the impact of existing [Maven] Central content, people doing their
> > local convention will probably "naturally" think at:
> > - immediate compatibility, to be able to consume public artifacts
> > - future compatibility, to be able to later publish a private artifact
> > that
> > may be later shared as public artifact
> > 
> > 
> > I started to share this idea (which is not far from initial proposal: just
> > not
> > about automodule names and not using artifactId)  yesterday with Robert:
> > the
> > discussion just started, nobody had time yet to write the proposal down
> > and
> > share it with a wider audience
> > 
> > 
> > WDYT?
> > 
> > Regards,
> > 
> > Hervé
> > 
> > Le jeudi 16 février 2017, 19:56:41 CET Manfred Moser a écrit :
> > > And it looks like they are saying .. just add the groupId (or similar
> > > namespace) to the modulename. A bit like some artifact repeat the
> > > groupId
> > > in the artifactId to be specific... seems like a wasted opportunity to
> > > define a good usage pattern. The idea of actually supporting same module
> > > names for different forks or the same thing is touted as an advantage.
> > > Anybody that ever had to debug something like this will know its not an
> > > advantage at all .. just simply path to troubleshooting nightmares.
> > > 
> > > I expected as much but I am still disappointed and see lots of trouble
> > 
> > with
> > 
> > > this in the future. Maybe it would be good if all Apache project and
> > 
> > others
> > 
> > > that are going to publish modules start with using the full namespace in
> > > the module name. Problem is of course that the examples I saw so far all
> > 
> > do
> > 
> > > NOT do that so we will end up with a mess anyway..
> > > 
> > > Manfred
> > > 
> > > Brian Fox wrote on 2017-02-16 10:42:
> > > > On Thu, Feb 16, 2017 at 1:38 PM, Igor Fedorenko 
> > 
> > wrote:
> > > >> Can't we just block auto-named modules from the build? We control
> > > >> dependencies and should be able to look inside and barf if we don't
> > 
> > like
> > 
> >

Re: I think we are ready for 3.5.0-alpha-1

2017-02-17 Thread Christian Schulte 
Am 02/17/17 um 19:18 schrieb Stephen Connolly:
> Would it help yet to cut an alpha and start tracking bugs?
> 
> I am starting to be concerned that the collective of volunteers are on a
> death march with no end in site... so I am seeking ways to identify an end
> where we can cut 3.5.0 and start on 3.5.1
> 
> I don't want to be here in 2-3 weeks and still not even a 3.5.0-alpha-1
> that users could start testing

Maybe we should start concentrating on the issues we already know of,
fix those, and then start cutting releases. If you take a look at the
following build jobs, there are issues we would need to fix before
releasing anything to the users. There may still be issues with the
setup of those jobs. Currently the results are not build job related, IMHO.



Regards,
-- 
Christian


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

Recent issues found in Surefire master/Maven Clean Plugin 3.0.0 with Maven master

2017-02-17 Thread Michael Osipov 

Hi folks,

Christian Schulte asked me a couple of days ago wether I am able to 
build Surefire master with Maven master. It was constantly failing for 
him on his OpenBSD machines. Since I have several real servers with 
FreeBSD 10.3-STABLE at hand I did run all Surefire ITs and I was able to 
reproduce it. Our entire test infrastructure wasn't unfortunately!


@Tibor: correct me if something is wrong or missing!

After several days of heavy testing, thread dumps and log file analysis 
with Tibor Digana and various Maven combinations (3.3.9, master, 
MNG-6169, MNG-6169 + MCLEAN 3.0.0) we figured out that there are several 
serious bugs in Surefire master, Maven Shared Utils 0.9/3.1.0 and likely 
Maven Clean Plugin 3.0.0.


Since crucial parts of Surefire rely on native code in the JVM (forks, 
streams), our code was not robust enough.


As of today we have found:

* Missing flushes in streams caused forked VM to be apparently 
non-responsive
* TestNG tests mostly failed due to duplicate contradicting properties 
passed to forked VMs

* Uninitialized/too early attributes made daemon threads to kill forked VMs
* Code or dependency change from MCLEAN 2.6.1 to 3.0.0 cause repeated 
failures of a handful ITs

@Karl Heinz: were you able to figure out something here?

Issues in JIRA are pending...

Everyone's invited to take a look at the log output as well as the 
target directory of surefire-integration-tests and contribute:
http://home.apache.org/~michaelo/maven/surefire/. The filenames should 
be pretty much self-explanatory.


My big question is: how can we improve our test infrastructure? Can we 
raise with INFRA to get at least one FreeBSD and Solaris node for 
Jenkins? I consider coverage on Windows and Ubuntu way to small, we do 
not even have a CentOS node. Surefire ITs and Maven ITs are paramount 
for us, we should treat them as such!


Michael

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

Re: Fwd: How to name modules, automatic and otherwise

2017-02-17 Thread Bernd 
>
> The idea is to not default to group:artifact but to check if the artifact
> starts with a suffix of the group-ID and then skip this. So g=org.hibernate
> a=hibernate-core would become org.hibernate.core and not
> org.hibernate.hibernate.core. This is a neat trick I wished in the past in
> some repository listings as well. However there is room for conflicts:
> org.hibernate:hibernate-util and org.hibernate:util would fold to the same
> module :-( (However it is most likely better to default to the shorter
> version and ask people to specify a longer version in case of conflicts)?


2017-02-17 15:01 GMT+01:00 Brian Fox :

> Hervé: I feel like I don't completely understand the proposal, but I feel
> like we can achieve your intent using the Module-Name simply by defaulting
> it to g:a and building up a good base of new stuff going into Central such
> that when people start using jigsaw, there is a good pattern in place and
> we've hopefully avoided conflicts.
>
> Am I mis-understanding your proposal?
>
> On Thu, Feb 16, 2017 at 8:51 PM, Hervé BOUTEMY 
> wrote:
>
> > tuesday, I was at a Jigsaw presentation from Remi Forax in France, where
> > the
> > fact that nothing was taken into consideration looked something that was
> > happenning (and the recent publication shows that it has happened now)
> >
> > Then Remi and I discussed and looked for ideas on what lighter proposal
> to
> > do
> > for the namespace concern when sharing modules publicly
> >
> > And I proposed a simplified idea that looked promising when we challenged
> > it:
> > for modules that are to be shared on Maven Central,
> > handwritten full module name should *start with groupId*
> >
> >
> > applied to the example for Hibernate, this would just say: Hibernate
> > project
> > owns "org.hibernate" module namespace on [Maven] Central since they own
> > org.hibernate groupId
> >
> > Notice: automodules won't give same module names. Automodules are just
> > transient automagic values for temporary local work, not for public
> shared
> > work
> >
> > Notice 2: whatever does not go to [Maven] Central has just other
> > conventions.
> > Knowing the impact of existing [Maven] Central content, people doing
> their
> > local convention will probably "naturally" think at:
> > - immediate compatibility, to be able to consume public artifacts
> > - future compatibility, to be able to later publish a private artifact
> that
> > may be later shared as public artifact
> >
> >
> > I started to share this idea (which is not far from initial proposal:
> just
> > not
> > about automodule names and not using artifactId)  yesterday with Robert:
> > the
> > discussion just started, nobody had time yet to write the proposal down
> and
> > share it with a wider audience
> >
> >
> > WDYT?
> >
> > Regards,
> >
> > Hervé
> >
> > Le jeudi 16 février 2017, 19:56:41 CET Manfred Moser a écrit :
> > > And it looks like they are saying .. just add the groupId (or similar
> > > namespace) to the modulename. A bit like some artifact repeat the
> groupId
> > > in the artifactId to be specific... seems like a wasted opportunity to
> > > define a good usage pattern. The idea of actually supporting same
> module
> > > names for different forks or the same thing is touted as an advantage.
> > > Anybody that ever had to debug something like this will know its not an
> > > advantage at all .. just simply path to troubleshooting nightmares.
> > >
> > > I expected as much but I am still disappointed and see lots of trouble
> > with
> > > this in the future. Maybe it would be good if all Apache project and
> > others
> > > that are going to publish modules start with using the full namespace
> in
> > > the module name. Problem is of course that the examples I saw so far
> all
> > do
> > > NOT do that so we will end up with a mess anyway..
> > >
> > > Manfred
> > >
> > > Brian Fox wrote on 2017-02-16 10:42:
> > > > On Thu, Feb 16, 2017 at 1:38 PM, Igor Fedorenko  >
> > wrote:
> > > >> Can't we just block auto-named modules from the build? We control
> > > >> dependencies and should be able to look inside and barf if we don't
> > like
> > > >> anything, no?
> > > >
> > > > Yes but this only applies to things that are modularized. The bigger
> > issue
> > > > is all the existing stuff that would be used as automodules...first
> > they
> > > > are already out there and second, there's nothing to see and block.
> > > >
> > > >> I realize this does not set good defaults for non-maven projects, so
> > > >> there will be some friction there, but hopefully maven userbase is
> big
> > > >> enough to create sufficient pressure for non-maven projects to
> provide
> > > >> explicit module names.
> > > >
> > > > That's exactly my point in originally suggesting to leverage the g:a
> by
> > > > default, but we can do exactly the same thing by injecting the
> > Module-Name
> > > > asap to build up the right practices before

Re: I think we are ready for 3.5.0-alpha-1

2017-02-17 Thread Arnaud Héritier 
+1 for to have the cat out of the box !!!

Le ven. 17 févr. 2017 à 19:19, Stephen Connolly <
stephen.alan.conno...@gmail.com> a écrit :

> Would it help yet to cut an alpha and start tracking bugs?
>
> I am starting to be concerned that the collective of volunteers are on a
> death march with no end in site... so I am seeking ways to identify an end
> where we can cut 3.5.0 and start on 3.5.1
>
> I don't want to be here in 2-3 weeks and still not even a 3.5.0-alpha-1
> that users could start testing
>
> On Fri 17 Feb 2017 at 18:10, Michael Osipov  wrote:
>
> > Am 2017-02-17 um 18:03 schrieb Arnaud Héritier:
> > > Is there someone who tried to deploy a "large" artifact ?
> > >
> > > I have a bug in 3.5 and not in 3.3.9 but for now no time to dig
> > >
> > > The project : https://github.com/jenkinsci/maven-plugin
> > > Downloading:
> > >
> >
> https://repo.jenkins-ci.org/snapshots/org/jenkins-ci/main/maven-plugin/2.16-SNAPSHOT/maven-metadata.xml
> > > Downloaded:
> > >
> >
> https://repo.jenkins-ci.org/snapshots/org/jenkins-ci/main/maven-plugin/2.16-SNAPSHOT/maven-metadata.xml
> > > (929 B at 1.5 kB/s)
> > > Uploading:
> > >
> >
> https://repo.jenkins-ci.org/snapshots/org/jenkins-ci/main/maven-plugin/2.16-SNAPSHOT/maven-plugin-2.16-20170217.170023-3.hpi
> > > [INFO] I/O exception (java.net.SocketException) caught when processing
> > > request to {s}->https://repo.jenkins-ci.org:443: Broken pipe (Write
> > failed)
> > > [INFO] Retrying request to {s}->https://repo.jenkins-ci.org:443
> > > [INFO] I/O exception (java.net.SocketException) caught when processing
> > > request to {s}->https://repo.jenkins-ci.org:443: Broken pipe (Write
> > failed)
> > > [INFO] Retrying request to {s}->https://repo.jenkins-ci.org:443
> > > [INFO] I/O exception (java.net.SocketException) caught when processing
> > > request to {s}->https://repo.jenkins-ci.org:443: Broken pipe (Write
> > failed)
> > > [INFO] Retrying request to {s}->https://repo.jenkins-ci.org:443
> >
> > In Wagon 2.12 Apache HttpComponents have been upgraded:
> > > diff --git a/wagon-providers/pom.xml b/wagon-providers/pom.xml
> > > index 1995fb7..e29dd55 100644
> > > --- a/wagon-providers/pom.xml
> > > +++ b/wagon-providers/pom.xml
> > > @@ -23,7 +23,7 @@ under the License.
> > >
> > >  org.apache.maven.wagon
> > >  wagon
> > > -2.10
> > > +2.12
> > >  ../pom.xml
> > >
> > >
> > > @@ -50,12 +50,12 @@ under the License.
> > >
> > >  org.apache.httpcomponents
> > >  httpclient
> > > -4.3.5
> > > +4.5.2
> > >
> > >
> > >  org.apache.httpcomponents
> > >  httpcore
> > > -4.3.2
> > > +4.4.4
> > >
> > >
> > >  org.apache.sshd
> >
> > Additionally, the log dependencies where incorrectly configured which
> > has been corrected in another ticket.
> >
> > Finally, we have a HugeFileDownloadTest which downloads a 4 GiB large
> > file, we can easily add a HugeFileUploadTest.
> >
> > Looking at the log messages issued by the HttpComponents, you have a
> > network issue. Somewhere between you and the Artifactory instance the
> > connection has been terminated (broken pipe).
> >
> > Can you repeat this issue realiably?
> >
> > Michael
> >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> > --
> Sent from my phone
>
-- 
-
Arnaud Héritier
http://aheritier.net
Mail/GTalk: aheritier AT gmail DOT com
Twitter/Skype : aheritier

Re: I think we are ready for 3.5.0-alpha-1

2017-02-17 Thread Stephen Connolly 
Would it help yet to cut an alpha and start tracking bugs?

I am starting to be concerned that the collective of volunteers are on a
death march with no end in site... so I am seeking ways to identify an end
where we can cut 3.5.0 and start on 3.5.1

I don't want to be here in 2-3 weeks and still not even a 3.5.0-alpha-1
that users could start testing

On Fri 17 Feb 2017 at 18:10, Michael Osipov  wrote:

> Am 2017-02-17 um 18:03 schrieb Arnaud Héritier:
> > Is there someone who tried to deploy a "large" artifact ?
> >
> > I have a bug in 3.5 and not in 3.3.9 but for now no time to dig
> >
> > The project : https://github.com/jenkinsci/maven-plugin
> > Downloading:
> >
> https://repo.jenkins-ci.org/snapshots/org/jenkins-ci/main/maven-plugin/2.16-SNAPSHOT/maven-metadata.xml
> > Downloaded:
> >
> https://repo.jenkins-ci.org/snapshots/org/jenkins-ci/main/maven-plugin/2.16-SNAPSHOT/maven-metadata.xml
> > (929 B at 1.5 kB/s)
> > Uploading:
> >
> https://repo.jenkins-ci.org/snapshots/org/jenkins-ci/main/maven-plugin/2.16-SNAPSHOT/maven-plugin-2.16-20170217.170023-3.hpi
> > [INFO] I/O exception (java.net.SocketException) caught when processing
> > request to {s}->https://repo.jenkins-ci.org:443: Broken pipe (Write
> failed)
> > [INFO] Retrying request to {s}->https://repo.jenkins-ci.org:443
> > [INFO] I/O exception (java.net.SocketException) caught when processing
> > request to {s}->https://repo.jenkins-ci.org:443: Broken pipe (Write
> failed)
> > [INFO] Retrying request to {s}->https://repo.jenkins-ci.org:443
> > [INFO] I/O exception (java.net.SocketException) caught when processing
> > request to {s}->https://repo.jenkins-ci.org:443: Broken pipe (Write
> failed)
> > [INFO] Retrying request to {s}->https://repo.jenkins-ci.org:443
>
> In Wagon 2.12 Apache HttpComponents have been upgraded:
> > diff --git a/wagon-providers/pom.xml b/wagon-providers/pom.xml
> > index 1995fb7..e29dd55 100644
> > --- a/wagon-providers/pom.xml
> > +++ b/wagon-providers/pom.xml
> > @@ -23,7 +23,7 @@ under the License.
> >
> >  org.apache.maven.wagon
> >  wagon
> > -2.10
> > +2.12
> >  ../pom.xml
> >
> >
> > @@ -50,12 +50,12 @@ under the License.
> >
> >  org.apache.httpcomponents
> >  httpclient
> > -4.3.5
> > +4.5.2
> >
> >
> >  org.apache.httpcomponents
> >  httpcore
> > -4.3.2
> > +4.4.4
> >
> >
> >  org.apache.sshd
>
> Additionally, the log dependencies where incorrectly configured which
> has been corrected in another ticket.
>
> Finally, we have a HugeFileDownloadTest which downloads a 4 GiB large
> file, we can easily add a HugeFileUploadTest.
>
> Looking at the log messages issued by the HttpComponents, you have a
> network issue. Somewhere between you and the Artifactory instance the
> connection has been terminated (broken pipe).
>
> Can you repeat this issue realiably?
>
> Michael
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
> --
Sent from my phone

Re: I think we are ready for 3.5.0-alpha-1

2017-02-17 Thread Michael Osipov 

Am 2017-02-17 um 18:03 schrieb Arnaud Héritier:

Is there someone who tried to deploy a "large" artifact ?

I have a bug in 3.5 and not in 3.3.9 but for now no time to dig

The project : https://github.com/jenkinsci/maven-plugin
Downloading:
https://repo.jenkins-ci.org/snapshots/org/jenkins-ci/main/maven-plugin/2.16-SNAPSHOT/maven-metadata.xml
Downloaded:
https://repo.jenkins-ci.org/snapshots/org/jenkins-ci/main/maven-plugin/2.16-SNAPSHOT/maven-metadata.xml
(929 B at 1.5 kB/s)
Uploading:
https://repo.jenkins-ci.org/snapshots/org/jenkins-ci/main/maven-plugin/2.16-SNAPSHOT/maven-plugin-2.16-20170217.170023-3.hpi
[INFO] I/O exception (java.net.SocketException) caught when processing
request to {s}->https://repo.jenkins-ci.org:443: Broken pipe (Write failed)
[INFO] Retrying request to {s}->https://repo.jenkins-ci.org:443
[INFO] I/O exception (java.net.SocketException) caught when processing
request to {s}->https://repo.jenkins-ci.org:443: Broken pipe (Write failed)
[INFO] Retrying request to {s}->https://repo.jenkins-ci.org:443
[INFO] I/O exception (java.net.SocketException) caught when processing
request to {s}->https://repo.jenkins-ci.org:443: Broken pipe (Write failed)
[INFO] Retrying request to {s}->https://repo.jenkins-ci.org:443


In Wagon 2.12 Apache HttpComponents have been upgraded:

diff --git a/wagon-providers/pom.xml b/wagon-providers/pom.xml
index 1995fb7..e29dd55 100644
--- a/wagon-providers/pom.xml
+++ b/wagon-providers/pom.xml
@@ -23,7 +23,7 @@ under the License.
   
 org.apache.maven.wagon
 wagon
-2.10
+2.12
 ../pom.xml
   

@@ -50,12 +50,12 @@ under the License.
   
 org.apache.httpcomponents
 httpclient
-4.3.5
+4.5.2
   
   
 org.apache.httpcomponents
 httpcore
-4.3.2
+4.4.4
   
   
 org.apache.sshd


Additionally, the log dependencies where incorrectly configured which 
has been corrected in another ticket.


Finally, we have a HugeFileDownloadTest which downloads a 4 GiB large 
file, we can easily add a HugeFileUploadTest.


Looking at the log messages issued by the HttpComponents, you have a 
network issue. Somewhere between you and the Artifactory instance the 
connection has been terminated (broken pipe).


Can you repeat this issue realiably?

Michael



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

[GitHub] maven-surefire issue #142: SUREFIRE-1330: Import provider code donated by JU...

2017-02-17 Thread Tibor17 
Github user Tibor17 commented on the issue:

https://github.com/apache/maven-surefire/pull/142
  
@sbrannen 
It looks like we will rename 2.19.2 to 2.20.0, but this is not official yet.


---
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: I think we are ready for 3.5.0-alpha-1

2017-02-17 Thread Robert Scholte 
I would expect this to be a wagon issue. Could you try to replace only  
these jars? i.e. wagon-*-2.12 back to wagon-*-2.10 as in 3.3.9


Robert

On Fri, 17 Feb 2017 18:03:04 +0100, Arnaud Héritier   
wrote:



Is there someone who tried to deploy a "large" artifact ?

I have a bug in 3.5 and not in 3.3.9 but for now no time to dig

The project : https://github.com/jenkinsci/maven-plugin

Here are the logs with 3.3.9

Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
2015-11-10T17:41:47+01:00)
Maven home: /Users/arnaud/Applications/apache-maven-3.3.9
Java version: 1.8.0_112, vendor: Oracle Corporation
Java home:
/Library/Java/JavaVirtualMachines/jdk1.8.0_112.jdk/Contents/Home/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "10.12.3", arch: "x86_64", family: "mac"
...
[INFO] --- maven-deploy-plugin:2.8.2:deploy (default-deploy) @  
maven-plugin

---
Downloading:
https://repo.jenkins-ci.org/snapshots/org/jenkins-ci/main/maven-plugin/2.16-SNAPSHOT/maven-metadata.xml
Downloaded:
https://repo.jenkins-ci.org/snapshots/org/jenkins-ci/main/maven-plugin/2.16-SNAPSHOT/maven-metadata.xml
(585 B at 0.7 KB/sec)
Uploading:
https://repo.jenkins-ci.org/snapshots/org/jenkins-ci/main/maven-plugin/2.16-SNAPSHOT/maven-plugin-2.16-20170217.165537-2.hpi
Uploaded:
https://repo.jenkins-ci.org/snapshots/org/jenkins-ci/main/maven-plugin/2.16-SNAPSHOT/maven-plugin-2.16-20170217.165537-2.hpi
(8716 KB at 98.1 KB/sec)
Uploading:
https://repo.jenkins-ci.org/snapshots/org/jenkins-ci/main/maven-plugin/2.16-SNAPSHOT/maven-plugin-2.16-20170217.165537-2.pom
Uploaded:
https://repo.jenkins-ci.org/snapshots/org/jenkins-ci/main/maven-plugin/2.16-SNAPSHOT/maven-plugin-2.16-20170217.165537-2.pom
(20 KB at 21.0 KB/sec)
Downloading:
https://repo.jenkins-ci.org/snapshots/org/jenkins-ci/main/maven-plugin/maven-metadata.xml
Downloaded:
https://repo.jenkins-ci.org/snapshots/org/jenkins-ci/main/maven-plugin/maven-metadata.xml
(684 B at 2.1 KB/sec)
Uploading:
https://repo.jenkins-ci.org/snapshots/org/jenkins-ci/main/maven-plugin/2.16-SNAPSHOT/maven-metadata.xml
Uploaded:
https://repo.jenkins-ci.org/snapshots/org/jenkins-ci/main/maven-plugin/2.16-SNAPSHOT/maven-metadata.xml
(778 B at 1.3 KB/sec)
Uploading:
https://repo.jenkins-ci.org/snapshots/org/jenkins-ci/main/maven-plugin/maven-metadata.xml
Uploaded:
https://repo.jenkins-ci.org/snapshots/org/jenkins-ci/main/maven-plugin/maven-metadata.xml
(649 B at 0.6 KB/sec)
Uploading:
https://repo.jenkins-ci.org/snapshots/org/jenkins-ci/main/maven-plugin/2.16-SNAPSHOT/maven-plugin-2.16-20170217.165537-2.jar
Uploaded:
https://repo.jenkins-ci.org/snapshots/org/jenkins-ci/main/maven-plugin/2.16-SNAPSHOT/maven-plugin-2.16-20170217.165537-2.jar
(693 KB at 71.2 KB/sec)
Uploading:
https://repo.jenkins-ci.org/snapshots/org/jenkins-ci/main/maven-plugin/2.16-SNAPSHOT/maven-metadata.xml
Uploaded:
https://repo.jenkins-ci.org/snapshots/org/jenkins-ci/main/maven-plugin/2.16-SNAPSHOT/maven-metadata.xml
(950 B at 1.2 KB/sec)
[INFO]

[INFO] BUILD SUCCESS
[INFO]

[INFO] Total time: 01:58 min
[INFO] Finished at: 2017-02-17T17:57:19+01:00
[INFO] Final Memory: 53M/497M
[INFO]


Here are the logs with 3.5

Apache Maven 3.5.0-SNAPSHOT (0284dda81beb43b54116326f9a6efd439d40c922;
2017-02-12T22:49:52+01:00)
Maven home: /Users/arnaud/Applications/apache-maven-3.5.0-SNAPSHOT
Java version: 1.8.0_112, vendor: Oracle Corporation
Java home:
/Library/Java/JavaVirtualMachines/jdk1.8.0_112.jdk/Contents/Home/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "10.12.3", arch: "x86_64", family:  
"mac"

...
[INFO] --- maven-deploy-plugin:2.8.2:deploy (default-deploy) @  
maven-plugin

---
Downloading:
https://repo.jenkins-ci.org/snapshots/org/jenkins-ci/main/maven-plugin/2.16-SNAPSHOT/maven-metadata.xml
Downloaded:
https://repo.jenkins-ci.org/snapshots/org/jenkins-ci/main/maven-plugin/2.16-SNAPSHOT/maven-metadata.xml
(929 B at 1.5 kB/s)
Uploading:
https://repo.jenkins-ci.org/snapshots/org/jenkins-ci/main/maven-plugin/2.16-SNAPSHOT/maven-plugin-2.16-20170217.170023-3.hpi
[INFO] I/O exception (java.net.SocketException) caught when processing
request to {s}->https://repo.jenkins-ci.org:443: Broken pipe (Write  
failed)

[INFO] Retrying request to {s}->https://repo.jenkins-ci.org:443
[INFO] I/O exception (java.net.SocketException) caught when processing
request to {s}->https://repo.jenkins-ci.org:443: Broken pipe (Write  
failed)

[INFO] Retrying request to {s}->https://repo.jenkins-ci.org:443
[INFO] I/O exception (java.net.SocketException) caught when processing
request to {s}->https://repo.jenkins-ci.org:443: Broken pipe (Write  
failed)

[INFO] Retrying request to {s}->https://repo.jenkins-ci.org:443
Uploading:

Re: I think we are ready for 3.5.0-alpha-1

2017-02-17 Thread Tibor Digana 
It happens with ArrayList filled up with objects in writer Thread.
Reader will see:
size=5, and Object array has all elements null.
In such cases I use ConcurrentLinkedQueue, thread-safe impl without using
locks - just write once and reads multiple times - or use Guava.
Does this happen with this?
final List newItemsThatCanBeBuilt = analyzer.markAsFinished(
projectBuild.getProject() );
Map.get(null) will crash of course when key is element of
newItemsThatCanBeBuil.



On Fri, Feb 17, 2017 at 5:25 PM, Robert Scholte-6 [via Maven] <
ml-node+s40175n5898885...@n5.nabble.com> wrote:

> Hi Karl Heinz,
>
> looking at the commit[1] I see that the projectBuildList.contains will
> prevent the NPE, but it looks weird to me that the projectBuildList does
> not contain a mavenProject which was marked as finished so can be built.
> Why is it null?
> If there's no clear reason yet, there should be at least an else-statement
>
> logging this.
> Looks to me more like a NPE prevention instead of fixing the root cause.
>
> -1 for me.
>
> thanks,
> Robert
>
> [1]
> https://git1-us-west.apache.org/repos/asf?p=maven.git;a=commitdiff;h=
> 238f789ad07a18c0dff7f884c9a5d3b47258fc47
>
>
> On Fri, 17 Feb 2017 16:56:23 +0100, Karl Heinz Marbaise
> <[hidden email] >
> wrote:
>
> > Hi,
> >
> > I have identified a bug[1] in Maven Core based on an issue related to
> > versions-maven-plugin:
> >
> > I have made already a fix for it and all tests are running[2].
> >
> > Any objection to merge that issue into master ?
> >
> > Kind regards
> > Karl Heinz Marbaise
> >
> > [1]: https://issues.apache.org/jira/browse/MNG-6170
> > [2]:
> > https://builds.apache.org/view/M-R/view/Maven/job/maven-
> 3.x-jenkinsfile/job/MNG-6170/
> >
> >
> > On 08/02/17 21:01, Stephen Connolly wrote:
> >> I think all the important stuff is merged. I'll take a final review
> >> through
> >> and then cut alpha-1
> >>
> >> We can still add stuff if necessary for an alpha-2 but I'd much prefer
>
> >> to
> >> focus that on shaking out bugs.
> >>
> >> Ideally we do at most 3 alpha's before soft-code-freeze and a beta (at
> >> which point it should only be serious bug fixes)
> >>
> >> Then we give the beta some soak and cut the release
> >>
> >> I toyed with spinning RCs but I'm thinking alpha and beta are better
> >> terms
> >>
> >> Thoughts?
> >>
> >
> >
> > -
> > To unsubscribe, e-mail: [hidden email]
> 
> > For additional commands, e-mail: [hidden email]
> 
>
> -
> 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/I-think-we-are-ready-for-3-5-0-alpha-1-
> tp5897626p5898885.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/I-think-we-are-ready-for-3-5-0-alpha-1-tp5897626p5898899.html
Sent from the Maven Developers mailing list archive at Nabble.com.

Re: I think we are ready for 3.5.0-alpha-1

2017-02-17 Thread Arnaud Héritier 
Is there someone who tried to deploy a "large" artifact ?

I have a bug in 3.5 and not in 3.3.9 but for now no time to dig

The project : https://github.com/jenkinsci/maven-plugin

Here are the logs with 3.3.9

Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
2015-11-10T17:41:47+01:00)
Maven home: /Users/arnaud/Applications/apache-maven-3.3.9
Java version: 1.8.0_112, vendor: Oracle Corporation
Java home:
/Library/Java/JavaVirtualMachines/jdk1.8.0_112.jdk/Contents/Home/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "10.12.3", arch: "x86_64", family: "mac"
...
[INFO] --- maven-deploy-plugin:2.8.2:deploy (default-deploy) @ maven-plugin
---
Downloading:
https://repo.jenkins-ci.org/snapshots/org/jenkins-ci/main/maven-plugin/2.16-SNAPSHOT/maven-metadata.xml
Downloaded:
https://repo.jenkins-ci.org/snapshots/org/jenkins-ci/main/maven-plugin/2.16-SNAPSHOT/maven-metadata.xml
(585 B at 0.7 KB/sec)
Uploading:
https://repo.jenkins-ci.org/snapshots/org/jenkins-ci/main/maven-plugin/2.16-SNAPSHOT/maven-plugin-2.16-20170217.165537-2.hpi
Uploaded:
https://repo.jenkins-ci.org/snapshots/org/jenkins-ci/main/maven-plugin/2.16-SNAPSHOT/maven-plugin-2.16-20170217.165537-2.hpi
(8716 KB at 98.1 KB/sec)
Uploading:
https://repo.jenkins-ci.org/snapshots/org/jenkins-ci/main/maven-plugin/2.16-SNAPSHOT/maven-plugin-2.16-20170217.165537-2.pom
Uploaded:
https://repo.jenkins-ci.org/snapshots/org/jenkins-ci/main/maven-plugin/2.16-SNAPSHOT/maven-plugin-2.16-20170217.165537-2.pom
(20 KB at 21.0 KB/sec)
Downloading:
https://repo.jenkins-ci.org/snapshots/org/jenkins-ci/main/maven-plugin/maven-metadata.xml
Downloaded:
https://repo.jenkins-ci.org/snapshots/org/jenkins-ci/main/maven-plugin/maven-metadata.xml
(684 B at 2.1 KB/sec)
Uploading:
https://repo.jenkins-ci.org/snapshots/org/jenkins-ci/main/maven-plugin/2.16-SNAPSHOT/maven-metadata.xml
Uploaded:
https://repo.jenkins-ci.org/snapshots/org/jenkins-ci/main/maven-plugin/2.16-SNAPSHOT/maven-metadata.xml
(778 B at 1.3 KB/sec)
Uploading:
https://repo.jenkins-ci.org/snapshots/org/jenkins-ci/main/maven-plugin/maven-metadata.xml
Uploaded:
https://repo.jenkins-ci.org/snapshots/org/jenkins-ci/main/maven-plugin/maven-metadata.xml
(649 B at 0.6 KB/sec)
Uploading:
https://repo.jenkins-ci.org/snapshots/org/jenkins-ci/main/maven-plugin/2.16-SNAPSHOT/maven-plugin-2.16-20170217.165537-2.jar
Uploaded:
https://repo.jenkins-ci.org/snapshots/org/jenkins-ci/main/maven-plugin/2.16-SNAPSHOT/maven-plugin-2.16-20170217.165537-2.jar
(693 KB at 71.2 KB/sec)
Uploading:
https://repo.jenkins-ci.org/snapshots/org/jenkins-ci/main/maven-plugin/2.16-SNAPSHOT/maven-metadata.xml
Uploaded:
https://repo.jenkins-ci.org/snapshots/org/jenkins-ci/main/maven-plugin/2.16-SNAPSHOT/maven-metadata.xml
(950 B at 1.2 KB/sec)
[INFO]

[INFO] BUILD SUCCESS
[INFO]

[INFO] Total time: 01:58 min
[INFO] Finished at: 2017-02-17T17:57:19+01:00
[INFO] Final Memory: 53M/497M
[INFO]


Here are the logs with 3.5

Apache Maven 3.5.0-SNAPSHOT (0284dda81beb43b54116326f9a6efd439d40c922;
2017-02-12T22:49:52+01:00)
Maven home: /Users/arnaud/Applications/apache-maven-3.5.0-SNAPSHOT
Java version: 1.8.0_112, vendor: Oracle Corporation
Java home:
/Library/Java/JavaVirtualMachines/jdk1.8.0_112.jdk/Contents/Home/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "10.12.3", arch: "x86_64", family: "mac"
...
[INFO] --- maven-deploy-plugin:2.8.2:deploy (default-deploy) @ maven-plugin
---
Downloading:
https://repo.jenkins-ci.org/snapshots/org/jenkins-ci/main/maven-plugin/2.16-SNAPSHOT/maven-metadata.xml
Downloaded:
https://repo.jenkins-ci.org/snapshots/org/jenkins-ci/main/maven-plugin/2.16-SNAPSHOT/maven-metadata.xml
(929 B at 1.5 kB/s)
Uploading:
https://repo.jenkins-ci.org/snapshots/org/jenkins-ci/main/maven-plugin/2.16-SNAPSHOT/maven-plugin-2.16-20170217.170023-3.hpi
[INFO] I/O exception (java.net.SocketException) caught when processing
request to {s}->https://repo.jenkins-ci.org:443: Broken pipe (Write failed)
[INFO] Retrying request to {s}->https://repo.jenkins-ci.org:443
[INFO] I/O exception (java.net.SocketException) caught when processing
request to {s}->https://repo.jenkins-ci.org:443: Broken pipe (Write failed)
[INFO] Retrying request to {s}->https://repo.jenkins-ci.org:443
[INFO] I/O exception (java.net.SocketException) caught when processing
request to {s}->https://repo.jenkins-ci.org:443: Broken pipe (Write failed)
[INFO] Retrying request to {s}->https://repo.jenkins-ci.org:443
Uploading:
https://repo.jenkins-ci.org/snapshots/org/jenkins-ci/main/maven-plugin/2.16-SNAPSHOT/maven-plugin-2.16-20170217.170023-3.pom
Uploaded:
https://repo.jenkins-ci.org/snapshots/org/jenkins-ci/main/maven-plugin/2.16-SNAPSHOT/maven-plugin-2.16-20170217.170023-3.pom
(20 kB at 12 kB/s)

Re: I think we are ready for 3.5.0-alpha-1

2017-02-17 Thread Tibor Digana 
Hi all,

At which line is NPE?
[1] looks like multithreading.
Is NPE cause due to Java Memory Model?
One thread is writer, seconds is reader, and object is not thread-safe
(immutable, synchronized either volatile).
[1]
https://git1-us-west.apache.org/repos/asf?p=maven.git;a=commitdiff;h=238f789ad07a18c0dff7f884c9a5d3b47258fc47



On Fri, Feb 17, 2017 at 5:24 PM, Robert Scholte 
wrote:

> Hi Karl Heinz,
>
> looking at the commit[1] I see that the projectBuildList.contains will
> prevent the NPE, but it looks weird to me that the projectBuildList does
> not contain a mavenProject which was marked as finished so can be built.
> Why is it null?
> If there's no clear reason yet, there should be at least an else-statement
> logging this.
> Looks to me more like a NPE prevention instead of fixing the root cause.
>
> -1 for me.
>
> thanks,
> Robert
>
> [1] https://git1-us-west.apache.org/repos/asf?p=maven.git;a=comm
> itdiff;h=238f789ad07a18c0dff7f884c9a5d3b47258fc47
>
>
>
> On Fri, 17 Feb 2017 16:56:23 +0100, Karl Heinz Marbaise 
> wrote:
>
> Hi,
>>
>> I have identified a bug[1] in Maven Core based on an issue related to
>> versions-maven-plugin:
>>
>> I have made already a fix for it and all tests are running[2].
>>
>> Any objection to merge that issue into master ?
>>
>> Kind regards
>> Karl Heinz Marbaise
>>
>> [1]: https://issues.apache.org/jira/browse/MNG-6170
>> [2]: https://builds.apache.org/view/M-R/view/Maven/job/maven-3.x-
>> jenkinsfile/job/MNG-6170/
>>
>>
>> On 08/02/17 21:01, Stephen Connolly wrote:
>>
>>> I think all the important stuff is merged. I'll take a final review
>>> through
>>> and then cut alpha-1
>>>
>>> We can still add stuff if necessary for an alpha-2 but I'd much prefer to
>>> focus that on shaking out bugs.
>>>
>>> Ideally we do at most 3 alpha's before soft-code-freeze and a beta (at
>>> which point it should only be serious bug fixes)
>>>
>>> Then we give the beta some soak and cut the release
>>>
>>> I toyed with spinning RCs but I'm thinking alpha and beta are better
>>> terms
>>>
>>> Thoughts?
>>>
>>>
>>
>> -
>> 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
>
>


-- 
Cheers
Tibor

Re: Fwd: How to name modules, automatic and otherwise

2017-02-17 Thread Manfred Moser 
Thats how I understand it as well and I like it. 

Brian Fox wrote on 2017-02-17 06:01:

> Hervé: I feel like I don't completely understand the proposal, but I feel
> like we can achieve your intent using the Module-Name simply by defaulting
> it to g:a and building up a good base of new stuff going into Central such
> that when people start using jigsaw, there is a good pattern in place and
> we've hopefully avoided conflicts.
> 
> Am I mis-understanding your proposal?
> 
> On Thu, Feb 16, 2017 at 8:51 PM, Hervé BOUTEMY 
> wrote:
> 
>> tuesday, I was at a Jigsaw presentation from Remi Forax in France, where
>> the
>> fact that nothing was taken into consideration looked something that was
>> happenning (and the recent publication shows that it has happened now)
>>
>> Then Remi and I discussed and looked for ideas on what lighter proposal to
>> do
>> for the namespace concern when sharing modules publicly
>>
>> And I proposed a simplified idea that looked promising when we challenged
>> it:
>> for modules that are to be shared on Maven Central,
>> handwritten full module name should *start with groupId*
>>
>>
>> applied to the example for Hibernate, this would just say: Hibernate
>> project
>> owns "org.hibernate" module namespace on [Maven] Central since they own
>> org.hibernate groupId
>>
>> Notice: automodules won't give same module names. Automodules are just
>> transient automagic values for temporary local work, not for public shared
>> work
>>
>> Notice 2: whatever does not go to [Maven] Central has just other
>> conventions.
>> Knowing the impact of existing [Maven] Central content, people doing their
>> local convention will probably "naturally" think at:
>> - immediate compatibility, to be able to consume public artifacts
>> - future compatibility, to be able to later publish a private artifact that
>> may be later shared as public artifact
>>
>>
>> I started to share this idea (which is not far from initial proposal: just
>> not
>> about automodule names and not using artifactId)  yesterday with Robert:
>> the
>> discussion just started, nobody had time yet to write the proposal down and
>> share it with a wider audience
>>
>>
>> WDYT?
>>
>> Regards,
>>
>> Hervé
>>
>> Le jeudi 16 février 2017, 19:56:41 CET Manfred Moser a écrit :
>> > And it looks like they are saying .. just add the groupId (or similar
>> > namespace) to the modulename. A bit like some artifact repeat the groupId
>> > in the artifactId to be specific... seems like a wasted opportunity to
>> > define a good usage pattern. The idea of actually supporting same module
>> > names for different forks or the same thing is touted as an advantage.
>> > Anybody that ever had to debug something like this will know its not an
>> > advantage at all .. just simply path to troubleshooting nightmares.
>> >
>> > I expected as much but I am still disappointed and see lots of trouble
>> with
>> > this in the future. Maybe it would be good if all Apache project and
>> others
>> > that are going to publish modules start with using the full namespace in
>> > the module name. Problem is of course that the examples I saw so far all
>> do
>> > NOT do that so we will end up with a mess anyway..
>> >
>> > Manfred
>> >
>> > Brian Fox wrote on 2017-02-16 10:42:
>> > > On Thu, Feb 16, 2017 at 1:38 PM, Igor Fedorenko 
>> wrote:
>> > >> Can't we just block auto-named modules from the build? We control
>> > >> dependencies and should be able to look inside and barf if we don't
>> like
>> > >> anything, no?
>> > >
>> > > Yes but this only applies to things that are modularized. The bigger
>> issue
>> > > is all the existing stuff that would be used as automodules...first
>> they
>> > > are already out there and second, there's nothing to see and block.
>> > >
>> > >> I realize this does not set good defaults for non-maven projects, so
>> > >> there will be some friction there, but hopefully maven userbase is big
>> > >> enough to create sufficient pressure for non-maven projects to provide
>> > >> explicit module names.
>> > >
>> > > That's exactly my point in originally suggesting to leverage the g:a by
>> > > default, but we can do exactly the same thing by injecting the
>> Module-Name
>> > > asap to build up the right practices before jigsaw takes off.
>> > >
>> > >> --
>> > >> Regards,
>> > >> Igor
>> > >>
>> > >> On Thu, Feb 16, 2017, at 01:11 PM, Brian Fox wrote:
>> > >> > I generally agree the concerns were mostly ignored. Specifically the
>> > >> > dangers in not carefully approaching and setting best practices in
>> the
>> > >> > names, thereby willfully ignoring what happened with NPM.
>> > >> >
>> > >> > The inclusion of the Module-Name metadata is frankly, more than I
>> > >> > expected
>> > >> > we would get. I think this does give us something to work with,
>> first
>> > >> > by
>> > >> > making that defaulted by the Maven plugins and later by enforcing in
>> > >> > the
>> > >> > repo as

Re: I think we are ready for 3.5.0-alpha-1

2017-02-17 Thread Robert Scholte 

Hi Karl Heinz,

looking at the commit[1] I see that the projectBuildList.contains will  
prevent the NPE, but it looks weird to me that the projectBuildList does  
not contain a mavenProject which was marked as finished so can be built.  
Why is it null?
If there's no clear reason yet, there should be at least an else-statement  
logging this.

Looks to me more like a NPE prevention instead of fixing the root cause.

-1 for me.

thanks,
Robert

[1]  
https://git1-us-west.apache.org/repos/asf?p=maven.git;a=commitdiff;h=238f789ad07a18c0dff7f884c9a5d3b47258fc47



On Fri, 17 Feb 2017 16:56:23 +0100, Karl Heinz Marbaise  
 wrote:



Hi,

I have identified a bug[1] in Maven Core based on an issue related to  
versions-maven-plugin:


I have made already a fix for it and all tests are running[2].

Any objection to merge that issue into master ?

Kind regards
Karl Heinz Marbaise

[1]: https://issues.apache.org/jira/browse/MNG-6170
[2]:  
https://builds.apache.org/view/M-R/view/Maven/job/maven-3.x-jenkinsfile/job/MNG-6170/



On 08/02/17 21:01, Stephen Connolly wrote:
I think all the important stuff is merged. I'll take a final review  
through

and then cut alpha-1

We can still add stuff if necessary for an alpha-2 but I'd much prefer  
to

focus that on shaking out bugs.

Ideally we do at most 3 alpha's before soft-code-freeze and a beta (at
which point it should only be serious bug fixes)

Then we give the beta some soak and cut the release

I toyed with spinning RCs but I'm thinking alpha and beta are better  
terms


Thoughts?




-
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

How are artifacts resolved from the reactor via LegacyRepositorySystem?

2017-02-17 Thread org . apache . maven . user 
Hello.

I'm currently trying to debug
https://issues.apache.org/jira/browse/MASSEMBLY-848 and am reaching
this line:

https://github.com/apache/maven-plugins/blob/trunk/maven-assembly-plugin/src/main/java/org/apache/maven/plugins/assembly/artifact/DefaultDependencyResolver.java#L232

I'm debugging based on the contents of an integration test, the
original source files of which came from this example project:

  https://github.com/io7m/independent-versioning-20170207

When line 232 is reached in the debugger, the dependencyArtifacts
parameter contains the two artifacts
com.io7m.experimental:mod-a:jar:1.1.0:compile and
com.io7m.experimental:mod-b:jar:1.2.0:compile and both of those claim
to already have been resolved (isResolved() == true), which makes sense
as they're reactor projects. Both are present in the given
configSource.reactorProjects list. However, the code doesn't appear to
make any use of this list or the fact that the artifacts are already
resolved. It simply passes the list of artifacts to the resolver which
then fails with an OverConstrainedVersionException because the reactor
project artifacts aren't in any of the remote or local repositories.

This seems to be the root cause of MASSEMBLY-848, but I can't work out
whether this is expected behaviour, misuse of an API, an oversight, or
possibly all or none of the above!

Can anyone shed any light on this?

M


pgpO43nka9r6m.pgp
Description: OpenPGP digital signature

Re: I think we are ready for 3.5.0-alpha-1

2017-02-17 Thread Karl Heinz Marbaise 

Hi,

I have identified a bug[1] in Maven Core based on an issue related to 
versions-maven-plugin:


I have made already a fix for it and all tests are running[2].

Any objection to merge that issue into master ?

Kind regards
Karl Heinz Marbaise

[1]: https://issues.apache.org/jira/browse/MNG-6170
[2]: 
https://builds.apache.org/view/M-R/view/Maven/job/maven-3.x-jenkinsfile/job/MNG-6170/



On 08/02/17 21:01, Stephen Connolly wrote:

I think all the important stuff is merged. I'll take a final review through
and then cut alpha-1

We can still add stuff if necessary for an alpha-2 but I'd much prefer to
focus that on shaking out bugs.

Ideally we do at most 3 alpha's before soft-code-freeze and a beta (at
which point it should only be serious bug fixes)

Then we give the beta some soak and cut the release

I toyed with spinning RCs but I'm thinking alpha and beta are better terms

Thoughts?




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

Re: Fwd: How to name modules, automatic and otherwise

2017-02-17 Thread Brian Fox 
Hervé: I feel like I don't completely understand the proposal, but I feel
like we can achieve your intent using the Module-Name simply by defaulting
it to g:a and building up a good base of new stuff going into Central such
that when people start using jigsaw, there is a good pattern in place and
we've hopefully avoided conflicts.

Am I mis-understanding your proposal?

On Thu, Feb 16, 2017 at 8:51 PM, Hervé BOUTEMY 
wrote:

> tuesday, I was at a Jigsaw presentation from Remi Forax in France, where
> the
> fact that nothing was taken into consideration looked something that was
> happenning (and the recent publication shows that it has happened now)
>
> Then Remi and I discussed and looked for ideas on what lighter proposal to
> do
> for the namespace concern when sharing modules publicly
>
> And I proposed a simplified idea that looked promising when we challenged
> it:
> for modules that are to be shared on Maven Central,
> handwritten full module name should *start with groupId*
>
>
> applied to the example for Hibernate, this would just say: Hibernate
> project
> owns "org.hibernate" module namespace on [Maven] Central since they own
> org.hibernate groupId
>
> Notice: automodules won't give same module names. Automodules are just
> transient automagic values for temporary local work, not for public shared
> work
>
> Notice 2: whatever does not go to [Maven] Central has just other
> conventions.
> Knowing the impact of existing [Maven] Central content, people doing their
> local convention will probably "naturally" think at:
> - immediate compatibility, to be able to consume public artifacts
> - future compatibility, to be able to later publish a private artifact that
> may be later shared as public artifact
>
>
> I started to share this idea (which is not far from initial proposal: just
> not
> about automodule names and not using artifactId)  yesterday with Robert:
> the
> discussion just started, nobody had time yet to write the proposal down and
> share it with a wider audience
>
>
> WDYT?
>
> Regards,
>
> Hervé
>
> Le jeudi 16 février 2017, 19:56:41 CET Manfred Moser a écrit :
> > And it looks like they are saying .. just add the groupId (or similar
> > namespace) to the modulename. A bit like some artifact repeat the groupId
> > in the artifactId to be specific... seems like a wasted opportunity to
> > define a good usage pattern. The idea of actually supporting same module
> > names for different forks or the same thing is touted as an advantage.
> > Anybody that ever had to debug something like this will know its not an
> > advantage at all .. just simply path to troubleshooting nightmares.
> >
> > I expected as much but I am still disappointed and see lots of trouble
> with
> > this in the future. Maybe it would be good if all Apache project and
> others
> > that are going to publish modules start with using the full namespace in
> > the module name. Problem is of course that the examples I saw so far all
> do
> > NOT do that so we will end up with a mess anyway..
> >
> > Manfred
> >
> > Brian Fox wrote on 2017-02-16 10:42:
> > > On Thu, Feb 16, 2017 at 1:38 PM, Igor Fedorenko 
> wrote:
> > >> Can't we just block auto-named modules from the build? We control
> > >> dependencies and should be able to look inside and barf if we don't
> like
> > >> anything, no?
> > >
> > > Yes but this only applies to things that are modularized. The bigger
> issue
> > > is all the existing stuff that would be used as automodules...first
> they
> > > are already out there and second, there's nothing to see and block.
> > >
> > >> I realize this does not set good defaults for non-maven projects, so
> > >> there will be some friction there, but hopefully maven userbase is big
> > >> enough to create sufficient pressure for non-maven projects to provide
> > >> explicit module names.
> > >
> > > That's exactly my point in originally suggesting to leverage the g:a by
> > > default, but we can do exactly the same thing by injecting the
> Module-Name
> > > asap to build up the right practices before jigsaw takes off.
> > >
> > >> --
> > >> Regards,
> > >> Igor
> > >>
> > >> On Thu, Feb 16, 2017, at 01:11 PM, Brian Fox wrote:
> > >> > I generally agree the concerns were mostly ignored. Specifically the
> > >> > dangers in not carefully approaching and setting best practices in
> the
> > >> > names, thereby willfully ignoring what happened with NPM.
> > >> >
> > >> > The inclusion of the Module-Name metadata is frankly, more than I
> > >> > expected
> > >> > we would get. I think this does give us something to work with,
> first
> > >> > by
> > >> > making that defaulted by the Maven plugins and later by enforcing in
> > >> > the
> > >> > repo as appropriate. Using this correctly could help solve some of
> my
> > >> > initial concerns that we weren't appropriately leveraging the
> > >> > default-effect.
> > >> >
> > >> > PS: those of you who aren't sure what this was

[GitHub] maven-surefire issue #142: SUREFIRE-1330: Import provider code donated by JU...

2017-02-17 Thread sbrannen 
Github user sbrannen commented on the issue:

https://github.com/apache/maven-surefire/pull/142
  
Very happy to hear that the Surefire team has taken over the provider for 
the JUnit Platform!!! 

Thanks! 😄 


---
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 #142: SUREFIRE-1330: Import provider code donated by JU...

2017-02-17 Thread sbrannen 
Github user sbrannen commented on the issue:

https://github.com/apache/maven-surefire/pull/142
  
@marcphilipp, 2.19.2 will support "*Tests" by default as well: 

https://twitter.com/sam_brannen/status/766979129954570240


---
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 #142: SUREFIRE-1330: Import provider code donate...

2017-02-17 Thread sbrannen 
Github user sbrannen commented on a diff in the pull request:

https://github.com/apache/maven-surefire/pull/142#discussion_r101716366
  
--- Diff: surefire-providers/pom.xml ---
@@ -41,6 +41,7 @@
 surefire-junit3
 surefire-junit4
 surefire-junit47
+surefire-junit5
--- End diff --

Agreed. Please do not refer to the _JUnit Platform_ as "JUnit 5".

The JUnit Platform is approaching version 1.0 GA, not 5.0.


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