Re: last review of Reproducible Builds proposal

2019-10-11 Thread Enrico Olivelli
Il ven 11 ott 2019, 08:31 Christofer Dutz  ha
scritto:

> Just a small question. I have been following this thread with great
> interest.
>
> I think this is going to be a big thing when it makes the changes
> available to the main maven system.
>
> So as far as I understand the core part will be a fixed timestamp which
> will then be used throughout the build by multiple pluggins.
>
> So if I provide the same timestamp the result should be binary identical.
>
> Would it be possible to have this timestamp written/updated in the pom as
> part of the release:prepare step?
>

Yep, this was one of my questions at the beginning of this thread.
I see value in this proposal

Enrico




> Sort of setting it to some constant (ie REPODUCEABLE_BUILD_TIMESTAMP)
> simply takes the current time but if there is a concrete value, it uses
> that instead?
>
> Hope im not asking anything obvious. To me it looked as if the timestamp
> has to be manipulated manually.
>
> Chris
>
> Holen Sie sich Outlook für Android
> 
> From: Emmanuel Bourg 
> Sent: Thursday, October 10, 2019 11:50:34 PM
> To: dev@maven.apache.org 
> Subject: Re: last review of Reproducible Builds proposal
>
> Le 10/10/2019 à 19:28, Hervé BOUTEMY a écrit :
>
> > the only little mis-interpretation is that it is a pure build
> information,
> > then I don't see why this property would appear in a consumer POM
>
> Thank you for the clarification, that makes perfectly sense. And I now
> see the benefit of using a property that can be inherited. In a multi
> modules project it's only necessary to define the timestamp once in the
> root pom. Parent poms deployed to Maven Central will never include a
> timestamp and there is no risk of affecting other projects deriving from
> the pom.
>
> Emmanuel Bourg
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>


Re: Surefire 3.0.0-M4 release?

2019-10-09 Thread Enrico Olivelli
+1
Enrico

Il gio 10 ott 2019, 06:40 Romain Manni-Bucau  ha
scritto:

> Anything user facing preventing to let it be a final?
>
> Anyway +1 to let fixes get out.
>
> Le jeu. 10 oct. 2019 à 02:53, Olivier Lamy  a écrit :
>
> > Hi,
> > It's now almost 10 months since last and around 30 issues fixed.
> > Maybe time for a new release?
> > Moving issues still open to 3.0.0-M5?
> >
> > cheers
> > --
> > Olivier Lamy
> > http://twitter.com/olamy | http://linkedin.com/in/olamy
> >
>


Re: Consumer pom, use a System property or a pom property ?

2019-10-08 Thread Enrico Olivelli
Il lun 7 ott 2019, 20:59 Robert Scholte  ha scritto:

> bq. I would like to use this feature when Maven 3.7.0 is out
>
> There's this interesting idea from Stephen to activate it by default,
> disabling it explicitly by setting the property to false.
>

Using it by default is good.

After thinking more about this 'flag' I do think that a system property is
fine, it will help transitions to the new way, but we should print out a
warning that in the future there will be no way to disable it

Enrico




> I did a Twitter poll, and the result after 100 responses was close to 50/50
>
> The more I think about it, the more I start to like the idea.
> In the past we've always been very careful with activating features, but
> why in this case?
> The whole idea here is that it should not break current poms. However, it
> is possible to remove a couple of elements and these will be added during
> *build* as if they were always there. The installed/deployed pom in based
> on this, minus a view build-specific elements.
>
> Btw, I discovered that I should take care of the LexicalHandler too, so
> there will be more commits and tests.
>
> Robert
>
> ps. thanks for the compliments. I hope it'll move the project forward!
>
> On Mon, 07 Oct 2019 07:52:48 +0200, Enrico Olivelli 
>
> wrote:
>
> > Hello,
> > Robert sent out a (great) patch than enables experimental support for the
> > consumer pom.
> >
> > This new way of working is enabled by a system property
> > -Dmaven.experimental.
> >
> > I would like to use this feature when Maven 3.7.0 is out, but it won't be
> > possible to use such a feature with a system property, as such system
> > property is to be configured in every build machine in order to be sure
> > that the build is consistent across all of the environments.
> >
> > What about having a simply "property" (in ) in the
> project
> > ?
> > I will set in on the parent of my hierarchy.
> > I see we cannot a a new xml tag/xml attribute, as it will be a change in
> > the version of the pom.
> >
> > As an alternative we could have a flag in Maven, to be activated by an
> > 'extension'
> >
> >
> > Thoughts
> >
> > Enrico
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>


Consumer pom...a better name like 'public pom' ?

2019-10-07 Thread Enrico Olivelli
Hello,
Robert sent out a (great) patch to introduce support for the 'consumer' pom,
that is (if I understand correctly) a skinny pom that contains only useful
information for downstream 'consumers' of the pom (poms that depend on it).

This consumer pom feature is required in order to start thinking to new
feature of the pom, because it opens the way to publishing a pom with a
different 'version' of the original one.

I feel that this name is not very clear, at least it is not clear to me.

I propose these names:
- source pom -> the source file, the pom parsed by Maven from sources
- public pom -> the pom that is consumed by dependants, it is usually
deployed to remote repositories

In alternative to source/public I have imagined other couples:
- source/shared
- original/result
- source/result
- source/sharable
- source/visible
- source/effective
.

Thoughts ?

Enrico


Consumer pom, use a System property or a pom property ?

2019-10-06 Thread Enrico Olivelli
Hello,
Robert sent out a (great) patch than enables experimental support for the
consumer pom.

This new way of working is enabled by a system property
-Dmaven.experimental.

I would like to use this feature when Maven 3.7.0 is out, but it won't be
possible to use such a feature with a system property, as such system
property is to be configured in every build machine in order to be sure
that the build is consistent across all of the environments.

What about having a simply "property" (in ) in the project ?
I will set in on the parent of my hierarchy.
I see we cannot a a new xml tag/xml attribute, as it will be a change in
the version of the pom.

As an alternative we could have a flag in Maven, to be activated by an
'extension'


Thoughts

Enrico


Re: [DISCUSS] Maven 3.7.0

2019-10-01 Thread Enrico Olivelli
Robert,
Can you create a PR?

Enrico

Il mar 1 ott 2019, 07:19 Sylwester Lachiewicz  ha
scritto:

> +1 for Java 8 - let's kill 7 faster ;-))
>
> Sylwester
>
> wt., 1 paź 2019, 02:41 użytkownik Olivier Lamy  napisał:
>
> > +1 for Java 8
> > it's time now and we will probably having more contributions as
> young/cool
> > kids prefer using modern tools
> > Yup the world is not only made with Old Grumpy grand dad working only
> with
> > Java 5 :P )
> >
> > On Tue, 1 Oct 2019 at 04:14, Robert Scholte 
> wrote:
> >
> > > The versions upgrades of plugins are part of another topic, which are
> > > indeed 3.7.0 candidates.
> > >
> > > As said, the Java 8 update is not just about internal code improvements
> > > or
> > > changes. Maven will expose new APIs/SPIs that contain Java 8 Functions,
> > > so
> > > it must be seen as a requirement to implement the experimental
> > > buildconsumer feature.
> > >
> > > Robert
> > >
> > > On Sat, 28 Sep 2019 14:23:16 +0200, Tibor Digana <
> tibordig...@apache.org
> > >
> > >
> > > wrote:
> > >
> > > > Hello guys,
> > > >
> > > > For the user community these two issues are important:
> > > > https://issues.apache.org/jira/browse/MNG-6169
> > > > https://issues.apache.org/jira/browse/MNG-6548
> > > > The Tycho project is the user as well.
> > > > The J8 is internal code improvement/change => lower priority than the
> > > > user's priority => release order/priorities/dedicated time spent in
> > > > development.
> > > >
> > > > Have a nice day.
> > > >
> > > > Cheers
> > > > Tibor17
> > > >
> > > > On Sat, Sep 28, 2019 at 2:08 PM Gary Gregory  >
> > > > wrote:
> > > >
> > > >> I would say that fixing the Tycho issue comes first.
> > > >>
> > > >> Gary
> > > >>
> > > >> On Sat, Sep 28, 2019 at 8:04 AM Robert Scholte <
> rfscho...@apache.org>
> > > >> wrote:
> > > >>
> > > >> > Hi,
> > > >> >
> > > >> > TLDR; introduce maven.experimental.buildconsumer and push Java
> > > >> > requirement
> > > >> > to Java 8
> > > >> >
> > > >> > now that Maven 3.6.2 is out for a couple of weeks, it seems like
> we
> > > >> > didn't
> > > >> > face real regressions.
> > > >> > The only one might be tricky is the issue related to Tycho.
> > > >> >
> > > >> > However, I think we're ready to push Maven to the next level.
> > > >> >
> > > >> > For those actively reading this list, they should recognize the
> need
> > > >> for
> > > >> > splitting up the pom as it is on the local system versus the pom
> > being
> > > >> > uploaded. Once we truly control this mechanism we can think of
> > > >> > improvements on model 5.0.0 and new fileformats.
> > > >> >
> > > >> > I've created and implemented MNG-6656[1]. It also contains a zip
> > > with
> > > >> an
> > > >> > example (original, patched, README) to understand what's
> happening.
> > > >> >
> > > >> > In order to make this successful, we need IDEs and CI Servers to
> > > >> > understand and support these changes. The likely need to implement
> > > >> one of
> > > >> > the interfaces[2].
> > > >> > The new interface uses Java8 Functions (and especially
> > > >> SAXEventFactory is
> > > >> > way easier to read+maintain with Java 8). I've tried to keep Maven
> > > >> Java 7
> > > >> > compatible, but that was too hard to do.
> > > >> > So I'd like to use this opportunity to move Maven forward and
> start
> > > >> > requiring Java 8.
> > > >> >
> > > >> > There are some other improvements I'd like to add (those messages
> > will
> > > >> > follow), so this will imply that it will take some time before we
> > do a
> > > >> > new
> > > >> > release.
> > > >> >
> > > >> > WDTY,
> > > >> > Robert
> > > >> >
> > > >> > [1] https://issues.apache.org/jira/browse/MNG-6656
> > > >> > [2] https://github.com/apache/maven/compare/MNG-6656?expand=1
> > > >> >
> > > >> >
> > -
> > > >> > 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
> > >
> > >
> >
> > --
> > Olivier Lamy
> > http://twitter.com/olamy | http://linkedin.com/in/olamy
> >
>


Re: [DISCUSS] Maven 3.7.0

2019-09-30 Thread Enrico Olivelli
Tibor

Il lun 30 set 2019, 20:30 Tibor Digana  ha scritto:

> Robert, you'r really right, there is only 3.7.0-candidate
> <
> https://issues.apache.org/jira/issues/?jql=project+%3D+MNG+AND+fixVersion+%3D+3.7.0-candidate
> >
> version in Jira, see
>
> https://issues.apache.org/jira/projects/MNG?selectedItem=com.atlassian.jira.jira-projects-plugin:release-page
> So this means MNG-6169 is in this discussion as well as it is 3.7.0.
> As well as many other issues in the list including the MNG-6548 and
> MNG-6656 too.
>
> Internal code regarding J8 means that you have to rewrite the code to J8.
> It can be done automatically but that's another topic.
>

You know that compiling for j8 does not require to use lamdas or whatever,
don't have to change your code,but only set target=8

Enrico


As far as I know the Maven developers they do not always have private spare
> time to do this job and therefore it is better to write a list of
> priorities and find the human resources for these issue. I know how
> difficult it is. This is the main problem.
> I am not against J8. I only say that we have to deliver important things
> from the user perspective first and then those less important whishes which
> is called "priorities", nothing special.
>
> Cheers
> Tibor17
>
>
>
>
>
>
>
> On Mon, Sep 30, 2019 at 8:14 PM Robert Scholte 
> wrote:
>
> > The versions upgrades of plugins are part of another topic, which are
> > indeed 3.7.0 candidates.
> >
> > As said, the Java 8 update is not just about internal code improvements
> > or
> > changes. Maven will expose new APIs/SPIs that contain Java 8 Functions,
> > so
> > it must be seen as a requirement to implement the experimental
> > buildconsumer feature.
> >
> > Robert
> >
> > On Sat, 28 Sep 2019 14:23:16 +0200, Tibor Digana  >
> >
> > wrote:
> >
> > > Hello guys,
> > >
> > > For the user community these two issues are important:
> > > https://issues.apache.org/jira/browse/MNG-6169
> > > https://issues.apache.org/jira/browse/MNG-6548
> > > The Tycho project is the user as well.
> > > The J8 is internal code improvement/change => lower priority than the
> > > user's priority => release order/priorities/dedicated time spent in
> > > development.
> > >
> > > Have a nice day.
> > >
> > > Cheers
> > > Tibor17
> > >
> > > On Sat, Sep 28, 2019 at 2:08 PM Gary Gregory 
> > > wrote:
> > >
> > >> I would say that fixing the Tycho issue comes first.
> > >>
> > >> Gary
> > >>
> > >> On Sat, Sep 28, 2019 at 8:04 AM Robert Scholte 
> > >> wrote:
> > >>
> > >> > Hi,
> > >> >
> > >> > TLDR; introduce maven.experimental.buildconsumer and push Java
> > >> > requirement
> > >> > to Java 8
> > >> >
> > >> > now that Maven 3.6.2 is out for a couple of weeks, it seems like we
> > >> > didn't
> > >> > face real regressions.
> > >> > The only one might be tricky is the issue related to Tycho.
> > >> >
> > >> > However, I think we're ready to push Maven to the next level.
> > >> >
> > >> > For those actively reading this list, they should recognize the need
> > >> for
> > >> > splitting up the pom as it is on the local system versus the pom
> being
> > >> > uploaded. Once we truly control this mechanism we can think of
> > >> > improvements on model 5.0.0 and new fileformats.
> > >> >
> > >> > I've created and implemented MNG-6656[1]. It also contains a zip
> > with
> > >> an
> > >> > example (original, patched, README) to understand what's happening.
> > >> >
> > >> > In order to make this successful, we need IDEs and CI Servers to
> > >> > understand and support these changes. The likely need to implement
> > >> one of
> > >> > the interfaces[2].
> > >> > The new interface uses Java8 Functions (and especially
> > >> SAXEventFactory is
> > >> > way easier to read+maintain with Java 8). I've tried to keep Maven
> > >> Java 7
> > >> > compatible, but that was too hard to do.
> > >> > So I'd like to use this opportunity to move Maven forward and start
> > >> > requiring Java 8.
> > >> >
> > >> > There are some other improvements I'd like to add (those messages
> will
> > >> > follow), so this will imply that it will take some time before we
> do a
> > >> > new
> > >> > release.
> > >> >
> > >> > WDTY,
> > >> > Robert
> > >> >
> > >> > [1] https://issues.apache.org/jira/browse/MNG-6656
> > >> > [2] https://github.com/apache/maven/compare/MNG-6656?expand=1
> > >> >
> > >> >
> -
> > >> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > >> > For additional commands, e-mail: dev-h...@maven.apache.org
> > >> >
> > >> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>


Re: [DISCUSS] configuration for Reproducible Builds

2019-09-29 Thread Enrico Olivelli
Il dom 29 set 2019, 12:16 Robert Scholte  ha scritto:

> I would think that all project.* properties represent the pom.xml and are
> immutable. To be more precise: the same pom.xml should effectively stay
> the same with every build.
> Instead this seems more related the (maven)session, right?
>

If I understand correctly the value f this property is to be committed in
the source code.
Some thoughts:
- it should default to 'now' sampled at the beginning of the session
- it can be overridden with a value writen in the pom or on a source file
- it must be sampled and commited as final value during a 'release process'


Enrico



> Robert
>
> On Sun, 29 Sep 2019 11:19:45 +0200, Hervé BOUTEMY 
>
> wrote:
>
> > regarding the property name, I had an idea:
> >
> > why not do like we already did for  ${project.build.sourceEncoding},
> ie.
> > mimic
> > a future element in pom.xml, in build?
> >
> > could be project.build.timestamp?
> >
> > Le samedi 28 septembre 2019, 17:55:24 CEST Hervé BOUTEMY a écrit :
> >> Achieving Reproducible Builds require only one parameter: plugins that
> >> create zip or tar archives require a fixed timestamp for entries
> >>
> >> Putting that parameter as a pom property with a well known name and
> >> value
> >> format permits to share the configuration between every packaging
> >> plugin.
> >> This also has the advantage that child poms will inherit from parent
> >> value,
> >> and eventually override.
> >>
> >> The question is: *what property name and what value format should we
> >> keep?*
> >>
> >> For the PoC, I chose to extrapolate from a convention from Reproducible
> >> Builds project, which is very Linux-oriented: SOURCE_DATE_EPOCH
> >> environment
> >> variable, that I transformed into source-date-epoch property name,
> >> keeping
> >> the "date + %s" value
> >> https://reproducible-builds.org/docs/source-date-epoch/
> >>
> >>
> >> But I feel we can do a more user-readable solution by choosing another
> >> name
> >> and format, like "reproducible-build-timestamp" with an ISO-8601
> >> combined
> >> date and time representation
> >>
> >>
> >> WDYT? Any other idea?
> >>
> >> Regards,
> >>
> >> Hervé
> >>
> >>
> >>
> >> -
> >> 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
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>


Re: [DISCUSS] configuration for Reproducible Builds

2019-09-28 Thread Enrico Olivelli
Hervé
When will you set this value? During release:prepare and modify the pom?

Enrico

Il sab 28 set 2019, 17:55 Hervé BOUTEMY  ha scritto:

> Achieving Reproducible Builds require only one parameter: plugins that
> create
> zip or tar archives require a fixed timestamp for entries
>
> Putting that parameter as a pom property with a well known name and value
> format permits to share the configuration between every packaging plugin.
> This also has the advantage that child poms will inherit from parent
> value,
> and eventually override.
>
> The question is: *what property name and what value format should we keep?*
>
> For the PoC, I chose to extrapolate from a convention from Reproducible
> Builds
> project, which is very Linux-oriented: SOURCE_DATE_EPOCH environment
> variable,
> that I transformed into source-date-epoch property name, keeping the "date
> +
> %s" value
> https://reproducible-builds.org/docs/source-date-epoch/
>
>
> But I feel we can do a more user-readable solution by choosing another
> name
> and format, like "reproducible-build-timestamp" with an ISO-8601 combined
> date
> and time representation
>
>
> WDYT? Any other idea?
>
> Regards,
>
> Hervé
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>


Re: [DISCUSS] Maven 3.7.0

2019-09-28 Thread Enrico Olivelli
Robert,

Il sab 28 set 2019, 14:04 Robert Scholte  ha scritto:

> Hi,
>
> TLDR; introduce maven.experimental.buildconsumer and push Java
> requirement
> to Java 8
>
> now that Maven 3.6.2 is out for a couple of weeks, it seems like we
> didn't
> face real regressions.
> The only one might be tricky is the issue related to Tycho.
>
> However, I think we're ready to push Maven to the next level.
>
> For those actively reading this list, they should recognize the need for
> splitting up the pom as it is on the local system versus the pom being
> uploaded. Once we truly control this mechanism we can think of
> improvements on model 5.0.0 and new fileformats.
>
> I've created and implemented MNG-6656[1]. It also contains a zip with an
> example (original, patched, README) to understand what's happening.
>

This is really cool, I hope we get something like this very soon.

One overall comment from me is about using XML and particularly SAX.
We will have our Maven XML library but the core principle is that all of
the transformations are in a streaming fashion, there is no overall view of
the whole document, and you cannot go backward and you can't see the tags
after the current point.
SAX is more memory efficient but if this will be a base for the future we
should take into account future needs.

I will review carefully the patch when the approach is agreed by the
community. I have already taken a first look, if you create the pull
requests I can add comments

Enrico



> In order to make this successful, we need IDEs and CI Servers to
> understand and support these changes. The likely need to implement one of
> the interfaces[2].
> The new interface uses Java8 Functions (and especially SAXEventFactory is
> way easier to read+maintain with Java 8). I've tried to keep Maven Java 7
> compatible, but that was too hard to do.
> So I'd like to use this opportunity to move Maven forward and start
> requiring Java 8.
>
> There are some other improvements I'd like to add (those messages will
> follow), so this will imply that it will take some time before we do a
> new
> release.
>
> WDTY,
> Robert
>
> [1] https://issues.apache.org/jira/browse/MNG-6656
> [2] https://github.com/apache/maven/compare/MNG-6656?expand=1
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>


Re: [VOTE] Maven incremental build for BIG-sized projects with local and remote caching

2019-09-21 Thread Enrico Olivelli
Hi Maximilian,
is there anyway to see this work ? is it already open source? (I am sorry,
maybe I missed some email with links)

Enrico

Il giorno ven 20 set 2019 alle ore 19:30 Alexander Ashitkin <
ashitkin.a...@gmail.com> ha scritto:

> Hi Martijn
> thanks for positive feedback.
>
> Regarding IDE part, yes you're right on integration part, but still there
> important cases when cache helps:
> 1) you need to navigate less in project as top level targets fast enough
> to not drill down
> 2) if you need to build a part of project (say only rest of wicket) you
> need to provide up-to-date rest dependencies which are not active in the
> subproject - and caches restores missing pieces for you without rebuilding
> remaining part of the project
> 3) If you need to test project and invoke test - cache saves your time (as
> gradle does) on unchanged pieces
> 4) and because tests run faster you can try run slow tests which often too
> expensive in rapid development
>
> So maven integration in Intellij works nice. There is nothing super smart
> here, just sharing how i benefit from the cache in everyday ide work
>
> Thank you!
>
> On 2019/09/19 11:28:48, Martijn Dashorst 
> wrote:
> > On Thu, Sep 19, 2019 at 7:48 AM Alexander Ashitkin
> >  wrote:
> > > Configuration:
> > > * verify -T4 -P default,all-shapshots-repos
> > > * my project config (might be suboptimal for wicket)
> > > * scala tests disabled in 2 modules (caused bytecode version conflict
> on my machine)
> > >
> > > Results
> > > Clean state (cache disabled):   15:58 min
> > > Second run, target up to date (cache disabled):  10:20 min
> > > Fully cached (no changes):  17.507
> s
> > > wicketstuff-jwicket-tooltip-wtooltips changed:  34.936 s
> > > wicketstuff-rest-utils changed: 54.040
> s
> > >
> > > If you want to try other modules - please let me know.
> >
> > Nice results!
> >
> > > regarding ide - it's a usual maven installation, so any ide with maven
> integration should benefit from cache them maven action invoked
> >
> > My instinct says that an IDE as Eclipse won't benefit much from it, as
> > it has its own build lifecycle. Only when you invoke a commandline
> > Maven action (such as generate-sources) one might have a benefit.
> >
> > So in the day-to-day life the caching might not be as beneficial for
> > developers, but commandline builds happen often enough to make this
> > matter.
> >
> > Martijn
> >
> > -
> > 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: [VOTE] Maven incremental build for BIG-sized projects with local and remote caching

2019-09-14 Thread Enrico Olivelli
I feel that in general having an huge monolithic project is kind of a
project-smell.
Btw I have some big project with 100+ modules so I can see your pain.
In the daywork experience a single developer doesn't work on all of the
modules but usually you touch 1-2 modules and maybe some integration/system
test.
If you need to rebuild the full project for every change maybe there is
something wrong with the overall design.

I think you have you motivations for your layout, so let's talk about your
proposal.

If you have a way to split your project in subsystems you can use some
shared remote repository for deploying snapshots in order to share
intermediate results with other developers

If your goal is to be ready for releases I don't get your point. Usually
you work with snapshots and for a release you have to rebuild one time and
only once the full codebase in order to ensure that you a consistent build
of the project.
With all of this kind of temporary caches how do you ensure that the final
artifacts are the intended ones?


Beside note: this is not a real VOTE thread

Just my 2 cents

don't get me wrong, I admire your will to improve Maven ecosystem with this
cool feature! Thank you for contribution your work. We will try to get the
best

Enrico

Il sab 14 set 2019, 08:29 Laird Nelson  ha scritto:

> On Fri, Sep 13, 2019 at 11:01 PM Alexander Ashitkin <
> alexander.ashit...@db.com> wrote:
>
> > This feature is true incremental build – you don’t build modules which
> > were not changed at all and build only modified/changed ones.
> >
>
> Suppose module B depends on module A and I change A.  Does B get rebuilt in
> your system?
>
> Best,
> Laird
>


Re: Same snapshot deploy number for entire build - possible

2019-09-13 Thread Enrico Olivelli
Dan,
Are you running a single 'mvn deploy' or do you have multiple runs?
I have never seen weird behaviours in multi module projects

Cheers
Enrico

Il ven 13 set 2019, 08:19 Dan Tran  ha scritto:

> Hello, Maven dev
>
> any suggestion/thoughts on this issue are very much appreciated
>
> Regards
>
> -D
>
> On Wed, Sep 11, 2019 at 7:06 PM Dan Tran  wrote:
>
> > Hello Maven Users and Development Team
> >
> > Currently, artifact deployed as snapshot at Maven repository has the
> > following format
> >
> >  artifactId-version-timestamp-NN
> >
> > where NN auto-incremented at each maven module and the number varies
> >
> > Is there a way to use same snapshot NN for the entire multi-module maven
> > build?
> >
> > If I have to implement a solution, would it be as an extension or I have
> > to tinker with maven-deploy-plugin?
> >
> > Very appreciated any advice
> >
> > -D
> >
> >
> >
> >
> >
>


[ANNOUNCE] Apache Maven 3.6.2 released

2019-09-06 Thread Enrico Olivelli
The Apache Maven team is proud to announce Apache Maven version
3.6.2.

Maven is a software project management and comprehension tool. Based on the
concept of a project object model (POM), Maven can manage a project’s
build, reporting, and documentation from a central place.

Highlights:

- This release focuses mostly performance improvements, better memory
footprint, and less CPU usage.

- We are continuing to convert Maven Core to use JSR 330 annotations
instead of Plexus (still not finished, see MNG-5577).

- New support for ‘release’ qualifier (see MNG-6655).

- The toolchain.xml file supports environment variables (see MNG-6665).


For Apache Maven release details and downloads, visit:

https://maven.apache.org/download.cgi


Maven 3.6.2 Release Notes are at:

https://maven.apache.org/docs/3.6.2/release-notes.html


We would like to thank the contributors that made the release possible.

Regards,

The Apache Maven Team


Re: maven download broken on all mirrors

2019-09-03 Thread Enrico Olivelli
I am sorry
We are fixing it.
We had accidentally removed 3.6.1, before publishing 3.6.2.

Enrico


Il giorno mar 3 set 2019 alle ore 19:16 Tamás Cservenák 
ha scritto:

> FYI,
> And just to confirm, HU mirror lost 3.6.1 as well.
>
> T
>
> -- Forwarded message -
> From: 'Jörg Hohwiller' via mojohaus-dev 
> Date: Tue, Sep 3, 2019 at 7:13 PM
> Subject: maven download broken on all mirrors
> To: mojohaus-dev 
>
>
> Hi there,
>
> may be wrong here but I unsubsribed from maven-dev and subscribing just for
> this notice is too much burden.
> So in case anyone from maven core team is reading this:
>
> It is currently impossible to download the latest version of maven (3.6.1).
> It is gone from all the mirrors.
> Someting was really entierely messed up here:
> https://maven.apache.org/download.cgi
>
> I noticed this because it broke my travis-ci build so it is not just a
> local CDN or proxy issue, but seems to be globally effective.
> Hope this gets fixed asap as this is real pain if users already fail at
> downloading.
>
> Cheers
>   Jörg
>
> --
> You received this message because you are subscribed to the Google Groups
> "mojohaus-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mojohaus-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
>
> https://groups.google.com/d/msgid/mojohaus-dev/6b5ade3c-a607-4999-a0ae-af6332d0bacd%40googlegroups.com
> <
> https://groups.google.com/d/msgid/mojohaus-dev/6b5ade3c-a607-4999-a0ae-af6332d0bacd%40googlegroups.com?utm_medium=email_source=footer
> >
> .
>


Docker based dev environment

2019-09-03 Thread Enrico Olivelli
Hi folks,
I have backported a took from BookKeeper project, originally provided by
Sijie.

https://github.com/apache/zookeeper/pull/1075

It creates a docker image/container to run on a known version of the Os
(Linux), even on Mac.

Feel free to test it


Enrico


[RESULT] [VOTE] Release Apache Maven Version 3.6.2

2019-09-02 Thread Enrico Olivelli
Hi,

the vote passed with the following resuts:
+1 jes...@udby.com, Tibor Digana, Mickael Istria, Romain Manni-Bucau,
Francois Papon, Hervé Boutemy, Karl Heinz Marbaise, Olivier Lamy, Mirko
Friedenhagen, Tamas Cserveak, Gabriel Berlingueres, Grzegorz Grzybek,
Sylwester Lachiewicz, Robert Scholte, Michael Osipov, Arnaud Héritier

PMC Quorum: reached

I will promote the artifacts to the central repo and complete the procedure

Thank you to everyone !

Enrico

Il giorno lun 2 set 2019 alle ore 09:37 Arnaud Héritier 
ha scritto:

> +1 (I had only the time to test on few projects - no regression found)
>
>
> On Sun, Sep 1, 2019 at 2:16 PM Romain Manni-Bucau 
> wrote:
>
> > +1 (non binding)
> >
> > Le dim. 1 sept. 2019 à 12:50, Michael Osipov  a
> > écrit :
> >
> > > Am 2019-08-28 um 21:17 schrieb Enrico Olivelli:
> > > > Hi,
> > > >
> > > > We have solved 52 issues:
> > > >
> > >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12345234
> > > >
> > > > There are issues left in JIRA for Maven core:
> > > >
> > >
> >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC%2C%20updated%20DESC
> > > >
> > > > Staging repo:
> > > > https://repository.apache.org/content/repositories/maven-1529
> > > >
> > > > The distributable binaries and sources can be found here:
> > > >
> > >
> >
> https://repository.apache.org/content/repositories/maven-1529/org/apache/maven/apache-maven/3.6.2/
> > > >
> > > > Specifically the zip, tarball and source archives can be found here:
> > > >
> > > >
> > >
> >
> https://repository.apache.org/content/repositories/maven-1529/org/apache/maven/apache-maven/3.6.2/apache-maven-3.6.2-bin.zip
> > > >
> > >
> >
> https://repository.apache.org/content/repositories/maven-1529/org/apache/maven/apache-maven/3.6.2/apache-maven-3.6.2-bin.tar.gz
> > > >
> > > >
> > >
> >
> https://repository.apache.org/content/repositories/maven-1529/org/apache/maven/apache-maven/3.6.2/apache-maven-3.6.2-src.zip
> > > >
> > >
> >
> https://repository.apache.org/content/repositories/maven-1529/org/apache/maven/apache-maven/3.6.2/apache-maven-3.6.2-src.tar.gz
> > > >
> > > > The release artifacts are staged for distribution in:
> > > > https://dist.apache.org/repos/dist/dev/maven/maven-3/3.6.2
> > > >
> > > > Source release checksum(s):
> > > > apache-maven-3.6.2-src.tar.gz
> > > >
> > > > sha1: 373ffbe9fc88e5facbe10d7a6f6badd243545ade
> > > > sha512:
> > > >
> > >
> >
> 235198b48d29fe2f2394f2607a9a1637acfd0286beacb974c566f7f36ac6c469871a0db287539b2b62e6322d7423f586949e41cbbfea330fe03bf690688f6fd7
> > > >
> > > > apache-maven-3.6.2-src.zip:
> > > >
> > > > sha1: c6c5bd9828b3350905e97177978724eed0698de3
> > > > sha512:
> > > >
> > >
> >
> d7fdafbc16bd547bc3c2513255df375c2a616b04d414c2ffd7d9deb9931fab5db4c7ac912cc4bb0d96d0a083560b3cc1848ea9eecc3aeb4e4c5184329a7ead5b
> > > >
> > > > Git tag:
> > > >
> > >
> >
> https://gitbox.apache.org/repos/asf?p=maven.git;a=commit;h=40f52333136460af0dc0d7232c0dc0bcf0d9e117
> > > >
> > > > Staging site:
> > > > https://maven.apache.org/components/ref/3-LATEST/
> > > >
> > > > Vote open for 72 hours.
> > >
> > > +1
> > >
> > > Just noticed that almost 50% have been assigned to me ;-)
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > >
> > >
> >
>
>
> --
> -
> Arnaud Héritier
> http://aheritier.net
> Mail/GTalk: aheritier AT gmail DOT com
> Twitter/Skype : aheritier
>


Re: Draft of release notes for Maven 3.6.2

2019-09-02 Thread Enrico Olivelli
Thank you Gary.

I have updated the draft of release notes:
https://github.com/apache/maven-site/pull/99/files

I am closing the vote now and move forward with the release.
I will use that branch as base for the release notes, we can always
amend/fix/enhance them

Enrico

Il giorno lun 2 set 2019 alle ore 21:52 Gary Gregory 
ha scritto:

> FWIW, over in Apache Commons, I take the following approach when filling in
> the due-to attribute for an issue in changes.xml: I list the reporter first
> (the person who created the jira or wrote an email, then each person who
> participated in any way in chronological order, even if it is just making a
> good point in a Jira comment in order to guide the fix or feature. Nice and
> simple.
>
> Gary
>
> On Mon, Sep 2, 2019 at 1:59 PM Enrico Olivelli 
> wrote:
>
> > Any suggestion ?
> > I am leaning towards creating a single list of "Contributors" and a list
> of
> > "Reporters"
> >
> > I have  to close the VOTE, I will wait to reach consensus on this release
> > notes stuff before closing the vote.
> >
> > Enrico
> >
> > Il giorno sab 31 ago 2019 alle ore 17:18 Tibor Digana <
> > tibordig...@apache.org> ha scritto:
> >
> > > We have contributors listed directly in the POM
> > > https://github.com/apache/maven/blob/master/pom.xml#L120
> > > If we started with this great idea to list contributors in POM, we
> should
> > > continue with it and this is the same privilege for future contributurs
> > as
> > > well. They will be listed on the Maven sites which is a big Thx from us
> > > ASF/Maven for them.
> > > Enrico, you have hard time because you are doing it only by your hands.
> > Why
> > > not to ask the contributor to add himself to the POM while the
> > pull-request
> > > is open? This would simplify your work with the release and then the
> > > release notes is more simple to do.
> > >
> > > For instance in the JUnit4 group the author and contributor is writing
> > the
> > > release notes on Wiki. It is part of the normal work, otherwise it is
> > > incomplete.
> > > I was also asked by the comitter to describe the fix/feature on Wiki in
> > > JUnit4. But there must be writtent rules and culture in the team to
> > remind
> > > the contributor to write the release notes.
> > > You as committer cannot compete with a large number of contributors!
> > > The contributors must understand that the work is not only about Java
> > code,
> > > it is also documentation of whatever manner.
> > >
> > > Also we should ask a contributor whether he wants to be in the list,
> but
> > we
> > > cannot ignore the contributor in the list.
> > > And what is the next fact, the list of contributors exists for some
> time.
> > > We should continue in this tradition and we should pickup a new
> commiter
> > > from this list. It is simple because we can see that some contributors
> > are
> > > more active than the others and we can see it based on the the number
> of
> > > issues MNG-x. We will very hardly "decompile" the release notes and
> > > find such statistics. We can do it only in JIRA.
> > > But still "reporter" is important because without him the idea would
> not
> > > exist and this is important for users, I mean the idea, but contributor
> > > will be always in the development team or in the users which is the
> > matter
> > > of time when somebody writes the code. Contributors are important for
> > > development and us in ASF but the reporter is relevant for users
> because
> > he
> > > is the architect of "business idea" - of course it is not the same as
> in
> > > the enterprise. In the enterprise, the customer does not care who is
> > > contributor ala developer, he cares about the work done for him.
> > >
> > > On Sat, Aug 31, 2019 at 1:05 PM Enrico Olivelli 
> > > wrote:
> > >
> > > > In my opinion release notes should tell:
> > > > - new features/news and noteworthy
> > > > - user visible changes
> > > > - breaking changes
> > > >
> > > > I would add a list of contributors.
> > > > The list of 'reporters' is not useful.
> > > >
> > > > I see we are doing those lists in order to have a better engagement
> > with
> > > > the community, but I am not sure at 100% it is something that should
> > stay
> > > > forever on t

Re: Draft of release notes for Maven 3.6.2

2019-09-02 Thread Enrico Olivelli
Any suggestion ?
I am leaning towards creating a single list of "Contributors" and a list of
"Reporters"

I have  to close the VOTE, I will wait to reach consensus on this release
notes stuff before closing the vote.

Enrico

Il giorno sab 31 ago 2019 alle ore 17:18 Tibor Digana <
tibordig...@apache.org> ha scritto:

> We have contributors listed directly in the POM
> https://github.com/apache/maven/blob/master/pom.xml#L120
> If we started with this great idea to list contributors in POM, we should
> continue with it and this is the same privilege for future contributurs as
> well. They will be listed on the Maven sites which is a big Thx from us
> ASF/Maven for them.
> Enrico, you have hard time because you are doing it only by your hands. Why
> not to ask the contributor to add himself to the POM while the pull-request
> is open? This would simplify your work with the release and then the
> release notes is more simple to do.
>
> For instance in the JUnit4 group the author and contributor is writing the
> release notes on Wiki. It is part of the normal work, otherwise it is
> incomplete.
> I was also asked by the comitter to describe the fix/feature on Wiki in
> JUnit4. But there must be writtent rules and culture in the team to remind
> the contributor to write the release notes.
> You as committer cannot compete with a large number of contributors!
> The contributors must understand that the work is not only about Java code,
> it is also documentation of whatever manner.
>
> Also we should ask a contributor whether he wants to be in the list, but we
> cannot ignore the contributor in the list.
> And what is the next fact, the list of contributors exists for some time.
> We should continue in this tradition and we should pickup a new commiter
> from this list. It is simple because we can see that some contributors are
> more active than the others and we can see it based on the the number of
> issues MNG-x. We will very hardly "decompile" the release notes and
> find such statistics. We can do it only in JIRA.
> But still "reporter" is important because without him the idea would not
> exist and this is important for users, I mean the idea, but contributor
> will be always in the development team or in the users which is the matter
> of time when somebody writes the code. Contributors are important for
> development and us in ASF but the reporter is relevant for users because he
> is the architect of "business idea" - of course it is not the same as in
> the enterprise. In the enterprise, the customer does not care who is
> contributor ala developer, he cares about the work done for him.
>
> On Sat, Aug 31, 2019 at 1:05 PM Enrico Olivelli 
> wrote:
>
> > In my opinion release notes should tell:
> > - new features/news and noteworthy
> > - user visible changes
> > - breaking changes
> >
> > I would add a list of contributors.
> > The list of 'reporters' is not useful.
> >
> > I see we are doing those lists in order to have a better engagement with
> > the community, but I am not sure at 100% it is something that should stay
> > forever on the website, maybe it can be in the announcement email.
> >
> > I have used the release notes of 3.6.1 as template, to me it is not a
> > problem to shrink the list making some sort of select
> > 'distict(reportername)', distinct(contributor name).
> >
> > Enrico
> >
> > Il sab 31 ago 2019, 11:17 Tibor Digana  ha
> > scritto:
> >
> > > For me and many users the Release Note like this are very hard to read
> > and
> > > hard to find what is needed.
> > > Many times they go to google because it's easier to search than walking
> > > through all versions of release notes.
> > >
> > > We do not have a cumulative documentation with a list of features and
> we
> > > often point to release notes whenever any uaser is asking about feature
> > or
> > > for a problem that he has in his build.
> > >
> > > If it was only up to me, I would have the cumulative documentation(s)
> > which
> > > is in one folder, and another documents would be Jira Report generated
> by
> > > "reporting" and this would include the author in the table - easy and
> > > automated.
> > > IMO it should be just like in the plugins - every feature fully
> > documented
> > > in src/site/../*.apt and pushed with the code and tests to master in
> one
> > > commit.
> > >
> > > Then the Release Notes would be a matter of command line "mvn site
> ...".
> > >
> > > On Sat, Aug 31, 2

Re: Draft of release notes for Maven 3.6.2

2019-08-31 Thread Enrico Olivelli
In my opinion release notes should tell:
- new features/news and noteworthy
- user visible changes
- breaking changes

I would add a list of contributors.
The list of 'reporters' is not useful.

I see we are doing those lists in order to have a better engagement with
the community, but I am not sure at 100% it is something that should stay
forever on the website, maybe it can be in the announcement email.

I have used the release notes of 3.6.1 as template, to me it is not a
problem to shrink the list making some sort of select
'distict(reportername)', distinct(contributor name).

Enrico

Il sab 31 ago 2019, 11:17 Tibor Digana  ha scritto:

> For me and many users the Release Note like this are very hard to read and
> hard to find what is needed.
> Many times they go to google because it's easier to search than walking
> through all versions of release notes.
>
> We do not have a cumulative documentation with a list of features and we
> often point to release notes whenever any uaser is asking about feature or
> for a problem that he has in his build.
>
> If it was only up to me, I would have the cumulative documentation(s) which
> is in one folder, and another documents would be Jira Report generated by
> "reporting" and this would include the author in the table - easy and
> automated.
> IMO it should be just like in the plugins - every feature fully documented
> in src/site/../*.apt and pushed with the code and tests to master in one
> commit.
>
> Then the Release Notes would be a matter of command line "mvn site ...".
>
> On Sat, Aug 31, 2019 at 10:45 AM Robert Scholte 
> wrote:
>
> > The goal of release notes is that they are being read.
> > There should be a good balance of the amount of information, preventing
> > people to say TLDR;
> >
> > A long list of 'MNG- John Doe' doesn't provide me useful information.
> > The list of 'MNG- A good JIRA title' is useful and visiting the
> > related Jira page will provide you the extra information, including the
> > actual reporter and contributors.
> >
> > Summing up a list of names that helped on the release is a good way to
> > appreciate their help on this release.
> >
> > Robert
> >
> >
> > On Sat, 31 Aug 2019 08:33:15 +0200, Tibor Digana  >
> >
> > wrote:
> >
> > > We should use authors of the issue/PR/idea.
> > > After the release we can ask WHY (practical goals) he wanted the
> feature
> > > more than how. The question for "HOW" has to be placed very early
> during
> > > the review, but too late after the PR has been merged.
> > > I expect that the reviewer developer has checked all the code, so there
> > > would not be questions about *how* it is done. If the reviewer does not
> > > understand the code and he admits the change, then it is question for
> him
> > > whenever a new trouble happens.
> > > So this is my opinion - listing the author(s) of the idea in every
> > > issue/PR.
> > >
> > > On Fri, Aug 30, 2019 at 10:40 PM Robert Scholte 
> > > wrote:
> > >
> > >> Not sure if the reader of the release notes is helped with a long list
> > >> of
> > >> reporters and contributers per issue.
> > >> I would expect that only a list of (unique) names is good enough.
> > >>
> > >> If there is someone that deserves extra credits, I'd say it is Stefan
> > >> Oehme for diving into the code, looking for memory leaks AND providing
> > >> patches to solve it.
> > >>
> > >> thanks for pushing this release!
> > >> Robert
> > >>
> > >> On Fri, 30 Aug 2019 22:02:31 +0200, Enrico Olivelli
> > >> 
> > >>
> > >> wrote:
> > >>
> > >> > Hi all,
> > >> > I have sent a draft of the release notes for 3.6.2
> > >> >
> > >> > this is the PR
> > >> > https://github.com/apache/maven-site/pull/99/files
> > >> >
> > >> > Feel free to add comments or push fixes directly to the branch.
> > >> >
> > >> > It still lacks a bit of formatting, but the content is ready
> > >> >
> > >> > Cheers
> > >> > Enrico
> > >>
> > >> -
> > >> 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
> >
> >
>


Draft of release notes for Maven 3.6.2

2019-08-30 Thread Enrico Olivelli
Hi all,
I have sent a draft of the release notes for 3.6.2

this is the PR
https://github.com/apache/maven-site/pull/99/files

Feel free to add comments or push fixes directly to the branch.

It still lacks a bit of formatting, but the content is ready

Cheers
Enrico


Re: Found Issues - Release Apache Maven Version 3.6.2

2019-08-29 Thread Enrico Olivelli
Il gio 29 ago 2019, 12:46 Alexander Bubenchikov <
alexander.bubenchi...@jetbrains.com> ha scritto:

> Hi Enrico, my name is Alex, I've joined to Jetbrains this year and
> responsible for maven integration and Intellij idea.
>

Nice to meet you Alex
I am sorry I am not an expert of this part of Maven.
I will let the other developers answer to your question

Enrico

>
> he issue happen because we replace some components in maven
> (ModelInterpolator in this case) to our own implementation which have
> injected PathTranslator and UrlNormalizer
> I've workarounded the issue in our code, but I didn't dig well into this.
> Is there any new way to replace maven components?
>
> On Wed, Aug 28, 2019 at 11:57 PM Enrico Olivelli 
> wrote:
>
> > It may be due to any change regarding jsr 330 like
> > https://issues.apache.org/jira/plugins/servlet/mobile#issue/MNG-6686
> >
> >
> > I think it is an issue for Idea and not for us.
> > It would be good to have some developer from Jetbrains on this list
> >
> >
> > Enrico
> >
> > Il mer 28 ago 2019, 22:23 Tibor Digana  ha
> > scritto:
> >
> > > I do not have NPE in the log.
> > > Guice is certainly not CDI. Moving Guice to CDI must be painful.
> > > One reason why PathTranslator could not be found is that there are
> > several
> > > bean instances of the same interface.
> > > Second problem might go with the Guice/CDI.
> > > See this inheritance:
> > >
> > > @Named
> > > @Singleton
> > > public class DefaultPathTranslator
> > > implements PathTranslator
> > > {
> > >
> > > public interface PathTranslator
> > > {
> > >
> > >
> > >
> > > On Wed, Aug 28, 2019 at 10:04 PM Filipe Sousa 
> wrote:
> > >
> > >> Hi,
> > >>
> > >> Not sure if it’s the same bug I commented in
> > >>
> >
> https://issues.apache.org/jira/browse/MNG-6638?focusedCommentId=16852351=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16852351
> > >>
> > >> I reported to Jetbrains
> > https://youtrack.jetbrains.com/issue/IDEA-215315
> > >> <https://youtrack.jetbrains.com/issue/IDEA-215315> and is supposed to
> > be
> > >> fixed in 2019.3
> > >>
> > >> > On 28 Aug 2019, at 20:43, Tibor Digana 
> > wrote:
> > >> >
> > >> > I used Maven 3.6.2 in the IntelliJ IDEA 2019.2.1 and I found these
> > >> errors
> > >> > in the log file:
> > >> > ~/.IntelliJIdea2019.2/system/log/idea.log
> > >> >
> > >> > 2019-08-28 21:31:32,072 [255937677]  ERROR -
> > >> #org.jetbrains.idea.maven
> > >> > - com.google.inject.CreationException: Unable to create injector,
> see
> > >> the
> > >> > following errors:
> > >> >
> > >> > 1) No implementation for org.apache.maven.model.path.PathTranslator
> > was
> > >> > bound.
> > >> >  while locating org.apache.maven.model.path.PathTranslator
> > >> >for field at
> > >> >
> > >>
> >
> org.apache.maven.model.interpolation.AbstractStringBasedModelInterpolator.pathTranslator(Unknown
> > >> > Source)
> > >> >  at
> > >> >
> > >>
> >
> org.codehaus.plexus.DefaultPlexusContainer$1.configure(DefaultPlexusContainer.java:350)
> > >> >
> > >> > 2) No implementation for org.apache.maven.model.path.UrlNormalizer
> was
> > >> > bound.
> > >> >  while locating org.apache.maven.model.path.UrlNormalizer
> > >> >for field at
> > >> >
> > >>
> >
> org.apache.maven.model.interpolation.AbstractStringBasedModelInterpolator.urlNormalizer(Unknown
> > >> > Source)
> > >> >  at
> > >> >
> > >>
> >
> org.codehaus.plexus.DefaultPlexusContainer$1.configure(DefaultPlexusContainer.java:350)
> > >> >
> > >> > 2 errors
> > >> > java.lang.RuntimeException: com.google.inject.CreationException:
> > Unable
> > >> to
> > >> > create injector, see the following errors:
> > >> >
> > >> > 1) No implementation for org.apache.maven.model.path.PathTranslator
> > was
> > >> > bound.
> > >> >  while locating org.apache.maven.model.path.PathTranslator
> > >>

Re: Found Issues - Release Apache Maven Version 3.6.2

2019-08-28 Thread Enrico Olivelli
It may be due to any change regarding jsr 330 like
https://issues.apache.org/jira/plugins/servlet/mobile#issue/MNG-6686


I think it is an issue for Idea and not for us.
It would be good to have some developer from Jetbrains on this list


Enrico

Il mer 28 ago 2019, 22:23 Tibor Digana  ha scritto:

> I do not have NPE in the log.
> Guice is certainly not CDI. Moving Guice to CDI must be painful.
> One reason why PathTranslator could not be found is that there are several
> bean instances of the same interface.
> Second problem might go with the Guice/CDI.
> See this inheritance:
>
> @Named
> @Singleton
> public class DefaultPathTranslator
> implements PathTranslator
> {
>
> public interface PathTranslator
> {
>
>
>
> On Wed, Aug 28, 2019 at 10:04 PM Filipe Sousa  wrote:
>
>> Hi,
>>
>> Not sure if it’s the same bug I commented in
>> https://issues.apache.org/jira/browse/MNG-6638?focusedCommentId=16852351=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16852351
>>
>> I reported to Jetbrains https://youtrack.jetbrains.com/issue/IDEA-215315
>>  and is supposed to be
>> fixed in 2019.3
>>
>> > On 28 Aug 2019, at 20:43, Tibor Digana  wrote:
>> >
>> > I used Maven 3.6.2 in the IntelliJ IDEA 2019.2.1 and I found these
>> errors
>> > in the log file:
>> > ~/.IntelliJIdea2019.2/system/log/idea.log
>> >
>> > 2019-08-28 21:31:32,072 [255937677]  ERROR -
>> #org.jetbrains.idea.maven
>> > - com.google.inject.CreationException: Unable to create injector, see
>> the
>> > following errors:
>> >
>> > 1) No implementation for org.apache.maven.model.path.PathTranslator was
>> > bound.
>> >  while locating org.apache.maven.model.path.PathTranslator
>> >for field at
>> >
>> org.apache.maven.model.interpolation.AbstractStringBasedModelInterpolator.pathTranslator(Unknown
>> > Source)
>> >  at
>> >
>> org.codehaus.plexus.DefaultPlexusContainer$1.configure(DefaultPlexusContainer.java:350)
>> >
>> > 2) No implementation for org.apache.maven.model.path.UrlNormalizer was
>> > bound.
>> >  while locating org.apache.maven.model.path.UrlNormalizer
>> >for field at
>> >
>> org.apache.maven.model.interpolation.AbstractStringBasedModelInterpolator.urlNormalizer(Unknown
>> > Source)
>> >  at
>> >
>> org.codehaus.plexus.DefaultPlexusContainer$1.configure(DefaultPlexusContainer.java:350)
>> >
>> > 2 errors
>> > java.lang.RuntimeException: com.google.inject.CreationException: Unable
>> to
>> > create injector, see the following errors:
>> >
>> > 1) No implementation for org.apache.maven.model.path.PathTranslator was
>> > bound.
>> >  while locating org.apache.maven.model.path.PathTranslator
>> >for field at
>> >
>> org.apache.maven.model.interpolation.AbstractStringBasedModelInterpolator.pathTranslator(Unknown
>> > Source)
>> >  at
>> >
>> org.codehaus.plexus.DefaultPlexusContainer$1.configure(DefaultPlexusContainer.java:350)
>> >
>> > 2) No implementation for org.apache.maven.model.path.UrlNormalizer was
>> > bound.
>> >  while locating org.apache.maven.model.path.UrlNormalizer
>> >for field at
>> >
>> org.apache.maven.model.interpolation.AbstractStringBasedModelInterpolator.urlNormalizer(Unknown
>> > Source)
>> >  at
>> >
>> org.codehaus.plexus.DefaultPlexusContainer$1.configure(DefaultPlexusContainer.java:350)
>> >
>> > 2 errors
>> > at
>> >
>> com.google.inject.internal.Errors.throwCreationExceptionIfErrorsExist(Errors.java:543)
>> > at
>> >
>> com.google.inject.internal.InternalInjectorCreator.initializeStatically(InternalInjectorCreator.java:159)
>> > at
>> >
>> com.google.inject.internal.InternalInjectorCreator.build(InternalInjectorCreator.java:106)
>> > at com.google.inject.Guice.createInjector(Guice.java:87)
>> > at com.google.inject.Guice.createInjector(Guice.java:69)
>> > at com.google.inject.Guice.createInjector(Guice.java:59)
>> > at
>> >
>> org.codehaus.plexus.DefaultPlexusContainer.addComponent(DefaultPlexusContainer.java:344)
>> > at
>> >
>> org.codehaus.plexus.DefaultPlexusContainer.addComponent(DefaultPlexusContainer.java:332)
>> > at
>> >
>> org.jetbrains.idea.maven.server.Maven3XServerEmbedder.customizeComponents(Maven3XServerEmbedder.java:573)
>> > at
>> >
>> org.jetbrains.idea.maven.server.Maven3XServerEmbedder.customize(Maven3XServerEmbedder.java:542)
>> > at
>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
>> > Method)
>> > at
>> >
>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>> > at
>> >
>> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> > at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>> > at
>> >
>> java.rmi/sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:359)
>> > at java.rmi/sun.rmi.transport.Transport$1.run(Transport.java:200)
>> > at java.rmi/sun.rmi.transport.Transport$1.run(Transport.java:197)
>> > at 

[VOTE] Release Apache Maven Version 3.6.2

2019-08-28 Thread Enrico Olivelli
Hi,

We have solved 52 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12345234

There are issues left in JIRA for Maven core:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC%2C%20updated%20DESC

Staging repo:
https://repository.apache.org/content/repositories/maven-1529

The distributable binaries and sources can be found here:
https://repository.apache.org/content/repositories/maven-1529/org/apache/maven/apache-maven/3.6.2/

Specifically the zip, tarball and source archives can be found here:

https://repository.apache.org/content/repositories/maven-1529/org/apache/maven/apache-maven/3.6.2/apache-maven-3.6.2-bin.zip
https://repository.apache.org/content/repositories/maven-1529/org/apache/maven/apache-maven/3.6.2/apache-maven-3.6.2-bin.tar.gz

https://repository.apache.org/content/repositories/maven-1529/org/apache/maven/apache-maven/3.6.2/apache-maven-3.6.2-src.zip
https://repository.apache.org/content/repositories/maven-1529/org/apache/maven/apache-maven/3.6.2/apache-maven-3.6.2-src.tar.gz

The release artifacts are staged for distribution in:
https://dist.apache.org/repos/dist/dev/maven/maven-3/3.6.2

Source release checksum(s):
apache-maven-3.6.2-src.tar.gz

   sha1: 373ffbe9fc88e5facbe10d7a6f6badd243545ade
sha512:
235198b48d29fe2f2394f2607a9a1637acfd0286beacb974c566f7f36ac6c469871a0db287539b2b62e6322d7423f586949e41cbbfea330fe03bf690688f6fd7

apache-maven-3.6.2-src.zip:

   sha1: c6c5bd9828b3350905e97177978724eed0698de3
sha512:
d7fdafbc16bd547bc3c2513255df375c2a616b04d414c2ffd7d9deb9931fab5db4c7ac912cc4bb0d96d0a083560b3cc1848ea9eecc3aeb4e4c5184329a7ead5b

Git tag:
https://gitbox.apache.org/repos/asf?p=maven.git;a=commit;h=40f52333136460af0dc0d7232c0dc0bcf0d9e117

Staging site:
https://maven.apache.org/components/ref/3-LATEST/

Vote open for 72 hours.

[ ] +1
[ ] +0
[ ] -1

Kind regards
Enrico Olivelli


Re: Guidance for Maven Core release

2019-08-28 Thread Enrico Olivelli
Il mer 28 ago 2019, 20:55 Karl Heinz Marbaise  ha
scritto:

> Hi Enrico,
>
> On 28.08.19 19:52, Enrico Olivelli wrote:
> > Thank you Mirko
> > I have sent the official VOTE email.
>
> Unfortunately I don't see the VOTE mail ? Or did I miss something ?
>
Ops
Gmail to Apache SMTP proxy had a problem.
I will resend the email.

Thanks

Enrico



> Kind regards
> Karl Heinz Marbaise
>
> > I am now preparing the "release notes" with the summary for the website.
> > It will take time, in the meanwhile we can all the the staged artifacts
> >
> > Enrico
> >
> > Il giorno mer 28 ago 2019 alle ore 18:29 Mirko Friedenhagen <
> > mfriedenha...@gmx.de> ha scritto:
> >
> >> Hello Enrico,
> >>
> >> * just a short thumbs up, I had used 3.6.2-SNAPSHOT in about 10 projects
> >> calling `mvn verify` in parallel and had no issues.
> >> * Today these builds broke because now it is 3.6.3-SNAPSHOT.
> >> * I am just in the process of testing 3.6.2 with above mentioned
> projects.
> >> * I will report back as well once you started the vote.
> >>
> >> Regards
> >> Mirko
> >>
> >>> Am 28.08.2019 um 12:34 schrieb Enrico Olivelli :
> >>>
> >>> Il giorno mar 27 ago 2019 alle ore 19:21 Karl Heinz Marbaise <
> >>> khmarba...@gmx.de> ha scritto:
> >>>
> >>>> Hi Enrico,
> >>>>
> >>>> On 27.08.19 18:53, Enrico Olivelli wrote:
> >>>>> I have created the tag so the master is ready for new commits.
> >>>>> I am testing the staged artifacts, It will take time.
> >>>>
> >>>> Can you send the staged artifacts URL's so I can test too ?
> >>>>
> >>>
> >>> Sure
> >>> Here you are:
> >>> Dist area:
> >>> https://dist.apache.org/repos/dist/dev/maven/maven-3/3.6.2
> >>>
> >>> Apache Repository
> >>>
> >>
> https://repository.apache.org/content/repositories/maven-1529/org/apache/maven/apache-maven/3.6.2/
> >>>
> >>> Staged site:
> >>> https://maven.apache.org/components/ref/3-LATEST/
> >>>
> >>> I would like to publish Integration tests results Hervè is helping me
> >>>
> >>> Enrico
> >>>
> >>>
> >>>
> >>>>
> >>>> Kind regards
> >>>> Karl Heinz Marbaise
> >>>>
> >>>>> I will send the VOTE email as soon as I am ready.
> >>>>>
> >>>>> Enrico
> >>>>>
> >>>>> Il giorno dom 25 ago 2019 alle ore 20:27 Enrico Olivelli
> >>>>> mailto:eolive...@gmail.com>> ha scritto:
> >>>>>
> >>>>> Thank you guys for your support.
> >>>>> I apologize, something came up, I can't start the procedure until
> >>>>> (hopefully) Wednesday.
> >>>>>
> >>>>> I will start as soon as possible.
> >>>>> Please tag me if you are committing something to master branch
> >>>>>
> >>>>> Cheers
> >>>>> Enrico
> >>>>>
> >>>>> Il giorno dom 25 ago 2019 alle ore 12:53 Karl Heinz Marbaise
> >>>>> mailto:khmarba...@gmx.de>> ha scritto:
> >>>>>
> >>>>> Hi Enrico,
> >>>>>
> >>>>> On 24.08.19 23:55, Enrico Olivelli wrote:
> >>>>>> Hello,
> >>>>>> As I going to start the release procedure for Maven Core I
> >>>>> have a bunch of
> >>>>>> questions.
> >>>>>> I see  that the procedure is slightly different from the
> >>>>> procedure for
> >>>>>> plugins ([1]), but actually the main differences are about
> >>>>> the way we stage
> >>>>>> the release artifacts and the finalization phase, the core of
> >>>>> the processs
> >>>>>> will be release:prepare and release:perform as usual.
> >>>>>>
> >>>>>> So I will run "mvn:perform" and I will copy the artifacts to
> >>>>> [4], that is
> >>>>>> in a directory named 3.6.2 (I see that Karl used 3.6.0 last
> >>>>> time for 3.6.1,
> >

Re: Guidance for Maven Core release

2019-08-28 Thread Enrico Olivelli
Thank you Mirko
I have sent the official VOTE email.
I am now preparing the "release notes" with the summary for the website.
It will take time, in the meanwhile we can all the the staged artifacts

Enrico

Il giorno mer 28 ago 2019 alle ore 18:29 Mirko Friedenhagen <
mfriedenha...@gmx.de> ha scritto:

> Hello Enrico,
>
> * just a short thumbs up, I had used 3.6.2-SNAPSHOT in about 10 projects
> calling `mvn verify` in parallel and had no issues.
> * Today these builds broke because now it is 3.6.3-SNAPSHOT.
> * I am just in the process of testing 3.6.2 with above mentioned projects.
> * I will report back as well once you started the vote.
>
> Regards
> Mirko
>
> > Am 28.08.2019 um 12:34 schrieb Enrico Olivelli :
> >
> > Il giorno mar 27 ago 2019 alle ore 19:21 Karl Heinz Marbaise <
> > khmarba...@gmx.de> ha scritto:
> >
> >> Hi Enrico,
> >>
> >> On 27.08.19 18:53, Enrico Olivelli wrote:
> >>> I have created the tag so the master is ready for new commits.
> >>> I am testing the staged artifacts, It will take time.
> >>
> >> Can you send the staged artifacts URL's so I can test too ?
> >>
> >
> > Sure
> > Here you are:
> > Dist area:
> > https://dist.apache.org/repos/dist/dev/maven/maven-3/3.6.2
> >
> > Apache Repository
> >
> https://repository.apache.org/content/repositories/maven-1529/org/apache/maven/apache-maven/3.6.2/
> >
> > Staged site:
> > https://maven.apache.org/components/ref/3-LATEST/
> >
> > I would like to publish Integration tests results Hervè is helping me
> >
> > Enrico
> >
> >
> >
> >>
> >> Kind regards
> >> Karl Heinz Marbaise
> >>
> >>> I will send the VOTE email as soon as I am ready.
> >>>
> >>> Enrico
> >>>
> >>> Il giorno dom 25 ago 2019 alle ore 20:27 Enrico Olivelli
> >>> mailto:eolive...@gmail.com>> ha scritto:
> >>>
> >>>Thank you guys for your support.
> >>>I apologize, something came up, I can't start the procedure until
> >>>(hopefully) Wednesday.
> >>>
> >>>I will start as soon as possible.
> >>>Please tag me if you are committing something to master branch
> >>>
> >>>Cheers
> >>>Enrico
> >>>
> >>>Il giorno dom 25 ago 2019 alle ore 12:53 Karl Heinz Marbaise
> >>>mailto:khmarba...@gmx.de>> ha scritto:
> >>>
> >>>Hi Enrico,
> >>>
> >>>On 24.08.19 23:55, Enrico Olivelli wrote:
> >>>> Hello,
> >>>> As I going to start the release procedure for Maven Core I
> >>>have a bunch of
> >>>> questions.
> >>>> I see  that the procedure is slightly different from the
> >>>procedure for
> >>>> plugins ([1]), but actually the main differences are about
> >>>the way we stage
> >>>> the release artifacts and the finalization phase, the core of
> >>>the processs
> >>>> will be release:prepare and release:perform as usual.
> >>>>
> >>>> So I will run "mvn:perform" and I will copy the artifacts to
> >>>[4], that is
> >>>> in a directory named 3.6.2 (I see that Karl used 3.6.0 last
> >>>time for 3.6.1,
> >>>> maybe it was a typo).
> >>>> I will run manually the integration tests against the binary
> >>>artifacts
> >>>> generated and perform my self tests, if I have some problem
> >>>can I drop the
> >>>> get tag and the staged repository or should I ban "3.6.2" tag
> >>>forever and
> >>>> move immediately to 3.6.3 ?
> >>>>
> >>>> I see that Karl last time ([2]) sent a mail slightly
> >>>different from the
> >>>> template  [3] shall I use that email as template ?
> >>>>
> >>>> How does website staging works for Maven Core ? I see no
> >> specific
> >>>> instructions here in [6], I think the directory for Maven
> >>>Core staging is
> >>>> [7] (According to the
> >>>component-reference-documentation-helper tool).
> >>>> I have also found this script from Hervé, see [9], it runs
> >>>the same
> >>>> commands as in 

Re: Guidance for Maven Core release

2019-08-28 Thread Enrico Olivelli
Il giorno mar 27 ago 2019 alle ore 19:21 Karl Heinz Marbaise <
khmarba...@gmx.de> ha scritto:

> Hi Enrico,
>
> On 27.08.19 18:53, Enrico Olivelli wrote:
> > I have created the tag so the master is ready for new commits.
> > I am testing the staged artifacts, It will take time.
>
> Can you send the staged artifacts URL's so I can test too ?
>

Sure
Here you are:
Dist area:
https://dist.apache.org/repos/dist/dev/maven/maven-3/3.6.2

Apache Repository
https://repository.apache.org/content/repositories/maven-1529/org/apache/maven/apache-maven/3.6.2/

Staged site:
https://maven.apache.org/components/ref/3-LATEST/

I would like to publish Integration tests results Hervè is helping me

Enrico



>
> Kind regards
> Karl Heinz Marbaise
>
> > I will send the VOTE email as soon as I am ready.
> >
> > Enrico
> >
> > Il giorno dom 25 ago 2019 alle ore 20:27 Enrico Olivelli
> > mailto:eolive...@gmail.com>> ha scritto:
> >
> > Thank you guys for your support.
> > I apologize, something came up, I can't start the procedure until
> > (hopefully) Wednesday.
> >
> > I will start as soon as possible.
> > Please tag me if you are committing something to master branch
> >
> > Cheers
> > Enrico
> >
> > Il giorno dom 25 ago 2019 alle ore 12:53 Karl Heinz Marbaise
> > mailto:khmarba...@gmx.de>> ha scritto:
> >
> > Hi Enrico,
> >
> > On 24.08.19 23:55, Enrico Olivelli wrote:
> >  > Hello,
> >  > As I going to start the release procedure for Maven Core I
> > have a bunch of
> >  > questions.
> >  > I see  that the procedure is slightly different from the
> > procedure for
> >  > plugins ([1]), but actually the main differences are about
> > the way we stage
> >  > the release artifacts and the finalization phase, the core of
> > the processs
> >  > will be release:prepare and release:perform as usual.
> >  >
> >  > So I will run "mvn:perform" and I will copy the artifacts to
> > [4], that is
> >  > in a directory named 3.6.2 (I see that Karl used 3.6.0 last
> > time for 3.6.1,
> >  > maybe it was a typo).
> >  > I will run manually the integration tests against the binary
> > artifacts
> >  > generated and perform my self tests, if I have some problem
> > can I drop the
> >  > get tag and the staged repository or should I ban "3.6.2" tag
> > forever and
> >  > move immediately to 3.6.3 ?
> >  >
> >  > I see that Karl last time ([2]) sent a mail slightly
> > different from the
> >  > template  [3] shall I use that email as template ?
> >  >
> >  > How does website staging works for Maven Core ? I see no
> specific
> >  > instructions here in [6], I think the directory for Maven
> > Core staging is
> >  > [7] (According to the
> > component-reference-documentation-helper tool).
> >  > I have also found this script from Hervé, see [9], it runs
> > the same
> >  > commands as in the "common" procedure
> >  >
> >  > Release notes:
> >  > I can't find release notes for 3.6.0 and 3.6.1 on svn [8],
> > have the sources
> >  > been moved to another location ? on some git repo ?
> >  >
> >  > Should I prepare the release notes before then I cut the
> > release and send
> >  > the VOTE, or can I create them during the finalization of the
> > release ?
> >  > It will take time to write those notes, but I also think that
> > writing the
> >  > release notes helps a lot in understanding the effective
> > contents of the
> >  > release.
> >  >
> >  >
> >  > I have started a new build of master branch now, in order to
> > perform a
> >  > final check up, see[5].
> >  >
> >  > I am sorry if this list was so long but I feel it is a big
> > responsibility
> >  > to cut a release of Maven core and I want to be sure I am
> > understanding
> >  > clearly what I am doing.
> >

Re: Guidance for Maven Core release

2019-08-27 Thread Enrico Olivelli
I have created the tag so the master is ready for new commits.
I am testing the staged artifacts, It will take time.
I will send the VOTE email as soon as I am ready.

Enrico

Il giorno dom 25 ago 2019 alle ore 20:27 Enrico Olivelli <
eolive...@gmail.com> ha scritto:

> Thank you guys for your support.
> I apologize, something came up, I can't start the procedure until
> (hopefully) Wednesday.
>
> I will start as soon as possible.
> Please tag me if you are committing something to master branch
>
> Cheers
> Enrico
>
> Il giorno dom 25 ago 2019 alle ore 12:53 Karl Heinz Marbaise <
> khmarba...@gmx.de> ha scritto:
>
>> Hi Enrico,
>>
>> On 24.08.19 23:55, Enrico Olivelli wrote:
>> > Hello,
>> > As I going to start the release procedure for Maven Core I have a bunch
>> of
>> > questions.
>> > I see  that the procedure is slightly different from the procedure for
>> > plugins ([1]), but actually the main differences are about the way we
>> stage
>> > the release artifacts and the finalization phase, the core of the
>> processs
>> > will be release:prepare and release:perform as usual.
>> >
>> > So I will run "mvn:perform" and I will copy the artifacts to [4], that
>> is
>> > in a directory named 3.6.2 (I see that Karl used 3.6.0 last time for
>> 3.6.1,
>> > maybe it was a typo).
>> > I will run manually the integration tests against the binary artifacts
>> > generated and perform my self tests, if I have some problem can I drop
>> the
>> > get tag and the staged repository or should I ban "3.6.2" tag forever
>> and
>> > move immediately to 3.6.3 ?
>> >
>> > I see that Karl last time ([2]) sent a mail slightly different from the
>> > template  [3] shall I use that email as template ?
>> >
>> > How does website staging works for Maven Core ? I see no specific
>> > instructions here in [6], I think the directory for Maven Core staging
>> is
>> > [7] (According to the component-reference-documentation-helper tool).
>> > I have also found this script from Hervé, see [9], it runs the same
>> > commands as in the "common" procedure
>> >
>> > Release notes:
>> > I can't find release notes for 3.6.0 and 3.6.1 on svn [8], have the
>> sources
>> > been moved to another location ? on some git repo ?
>> >
>> > Should I prepare the release notes before then I cut the release and
>> send
>> > the VOTE, or can I create them during the finalization of the release ?
>> > It will take time to write those notes, but I also think that writing
>> the
>> > release notes helps a lot in understanding the effective contents of the
>> > release.
>> >
>> >
>> > I have started a new build of master branch now, in order to perform a
>> > final check up, see[5].
>> >
>> > I am sorry if this list was so long but I feel it is a big
>> responsibility
>> > to cut a release of Maven core and I want to be sure I am understanding
>> > clearly what I am doing.
>>
>> No need to apologize cause based on the list you are asking you show how
>> serious you are taking this ...
>>
>> No problem..
>>
>> As Hervé already stated go for it...
>>
>> Kind regards
>> Karl Heinz Marbaise
>>
>> >
>> > Please do not push changes to master branch and let me drive all of the
>> > commits until the release procedure is completed.
>> >
>> > Best regards
>> > Enrico Olivelli
>> >
>> >
>> > [1] https://maven.apache.org/developers/release/maven-core-release.html
>> > [2]
>> >
>> https://lists.apache.org/thread.html/249091304adb6366845ba115fb3d1d9d358682630ab4a51df0d4bf67@%3Cdev.maven.apache.org%3E
>> > [3]
>> >
>> https://maven.apache.org/developers/release/maven-project-release-procedure.html
>> > [4] https://dist.apache.org/repos/dist/dev/maven/maven-3/$VERSION. Then
>> > once the vote passed, svn move to
>> > https://dist.apache.org/repos/dist/release/maven/maven-3/3.6.2
>> > [5] https://builds.apache.org/job/maven-box/job/maven/job/master/279/
>> > [6]
>> >
>> https://maven.apache.org/developers/website/deploy-component-reference-documentation.html
>> > [7]
>> https://svn.apache.org/repos/asf/maven/website/components/ref/3-LATEST/
>> > [8]
>> https://svn.apache.org/repos/asf/maven/site/trunk/content/markdown/docs/
>> > [9] https://github.com/apache/maven/blob/master/deploySite.sh
>> > [10] https://maven.apache.org/docs/3.6.1/release-notes.html
>> >
>>
>


Re: Guidance for Maven Core release

2019-08-25 Thread Enrico Olivelli
Thank you guys for your support.
I apologize, something came up, I can't start the procedure until
(hopefully) Wednesday.

I will start as soon as possible.
Please tag me if you are committing something to master branch

Cheers
Enrico

Il giorno dom 25 ago 2019 alle ore 12:53 Karl Heinz Marbaise <
khmarba...@gmx.de> ha scritto:

> Hi Enrico,
>
> On 24.08.19 23:55, Enrico Olivelli wrote:
> > Hello,
> > As I going to start the release procedure for Maven Core I have a bunch
> of
> > questions.
> > I see  that the procedure is slightly different from the procedure for
> > plugins ([1]), but actually the main differences are about the way we
> stage
> > the release artifacts and the finalization phase, the core of the
> processs
> > will be release:prepare and release:perform as usual.
> >
> > So I will run "mvn:perform" and I will copy the artifacts to [4], that is
> > in a directory named 3.6.2 (I see that Karl used 3.6.0 last time for
> 3.6.1,
> > maybe it was a typo).
> > I will run manually the integration tests against the binary artifacts
> > generated and perform my self tests, if I have some problem can I drop
> the
> > get tag and the staged repository or should I ban "3.6.2" tag forever and
> > move immediately to 3.6.3 ?
> >
> > I see that Karl last time ([2]) sent a mail slightly different from the
> > template  [3] shall I use that email as template ?
> >
> > How does website staging works for Maven Core ? I see no specific
> > instructions here in [6], I think the directory for Maven Core staging is
> > [7] (According to the component-reference-documentation-helper tool).
> > I have also found this script from Hervé, see [9], it runs the same
> > commands as in the "common" procedure
> >
> > Release notes:
> > I can't find release notes for 3.6.0 and 3.6.1 on svn [8], have the
> sources
> > been moved to another location ? on some git repo ?
> >
> > Should I prepare the release notes before then I cut the release and send
> > the VOTE, or can I create them during the finalization of the release ?
> > It will take time to write those notes, but I also think that writing the
> > release notes helps a lot in understanding the effective contents of the
> > release.
> >
> >
> > I have started a new build of master branch now, in order to perform a
> > final check up, see[5].
> >
> > I am sorry if this list was so long but I feel it is a big responsibility
> > to cut a release of Maven core and I want to be sure I am understanding
> > clearly what I am doing.
>
> No need to apologize cause based on the list you are asking you show how
> serious you are taking this ...
>
> No problem..
>
> As Hervé already stated go for it...
>
> Kind regards
> Karl Heinz Marbaise
>
> >
> > Please do not push changes to master branch and let me drive all of the
> > commits until the release procedure is completed.
> >
> > Best regards
> > Enrico Olivelli
> >
> >
> > [1] https://maven.apache.org/developers/release/maven-core-release.html
> > [2]
> >
> https://lists.apache.org/thread.html/249091304adb6366845ba115fb3d1d9d358682630ab4a51df0d4bf67@%3Cdev.maven.apache.org%3E
> > [3]
> >
> https://maven.apache.org/developers/release/maven-project-release-procedure.html
> > [4] https://dist.apache.org/repos/dist/dev/maven/maven-3/$VERSION. Then
> > once the vote passed, svn move to
> > https://dist.apache.org/repos/dist/release/maven/maven-3/3.6.2
> > [5] https://builds.apache.org/job/maven-box/job/maven/job/master/279/
> > [6]
> >
> https://maven.apache.org/developers/website/deploy-component-reference-documentation.html
> > [7]
> https://svn.apache.org/repos/asf/maven/website/components/ref/3-LATEST/
> > [8]
> https://svn.apache.org/repos/asf/maven/site/trunk/content/markdown/docs/
> > [9] https://github.com/apache/maven/blob/master/deploySite.sh
> > [10] https://maven.apache.org/docs/3.6.1/release-notes.html
> >
>


Guidance for Maven Core release

2019-08-24 Thread Enrico Olivelli
Hello,
As I going to start the release procedure for Maven Core I have a bunch of
questions.
I see  that the procedure is slightly different from the procedure for
plugins ([1]), but actually the main differences are about the way we stage
the release artifacts and the finalization phase, the core of the processs
will be release:prepare and release:perform as usual.

So I will run "mvn:perform" and I will copy the artifacts to [4], that is
in a directory named 3.6.2 (I see that Karl used 3.6.0 last time for 3.6.1,
maybe it was a typo).
I will run manually the integration tests against the binary artifacts
generated and perform my self tests, if I have some problem can I drop the
get tag and the staged repository or should I ban "3.6.2" tag forever and
move immediately to 3.6.3 ?

I see that Karl last time ([2]) sent a mail slightly different from the
template  [3] shall I use that email as template ?

How does website staging works for Maven Core ? I see no specific
instructions here in [6], I think the directory for Maven Core staging is
[7] (According to the component-reference-documentation-helper tool).
I have also found this script from Hervé, see [9], it runs the same
commands as in the "common" procedure

Release notes:
I can't find release notes for 3.6.0 and 3.6.1 on svn [8], have the sources
been moved to another location ? on some git repo ?

Should I prepare the release notes before then I cut the release and send
the VOTE, or can I create them during the finalization of the release ?
It will take time to write those notes, but I also think that writing the
release notes helps a lot in understanding the effective contents of the
release.


I have started a new build of master branch now, in order to perform a
final check up, see[5].

I am sorry if this list was so long but I feel it is a big responsibility
to cut a release of Maven core and I want to be sure I am understanding
clearly what I am doing.

Please do not push changes to master branch and let me drive all of the
commits until the release procedure is completed.

Best regards
Enrico Olivelli


[1] https://maven.apache.org/developers/release/maven-core-release.html
[2]
https://lists.apache.org/thread.html/249091304adb6366845ba115fb3d1d9d358682630ab4a51df0d4bf67@%3Cdev.maven.apache.org%3E
[3]
https://maven.apache.org/developers/release/maven-project-release-procedure.html
[4] https://dist.apache.org/repos/dist/dev/maven/maven-3/$VERSION. Then
once the vote passed, svn move to
https://dist.apache.org/repos/dist/release/maven/maven-3/3.6.2
[5] https://builds.apache.org/job/maven-box/job/maven/job/master/279/
[6]
https://maven.apache.org/developers/website/deploy-component-reference-documentation.html
[7] https://svn.apache.org/repos/asf/maven/website/components/ref/3-LATEST/
[8] https://svn.apache.org/repos/asf/maven/site/trunk/content/markdown/docs/
[9] https://github.com/apache/maven/blob/master/deploySite.sh
[10] https://maven.apache.org/docs/3.6.1/release-notes.html


Re: Releasing Maven 3.6.2

2019-08-24 Thread Enrico Olivelli
Il sab 24 ago 2019, 12:16 Tibor Digana  ha scritto:

> Enrico, I know that Michael mentioned some test failure but I could not
> find it in MNG-6695 because the executions 1 and 2 were deleted by 3.
> So only Michael has the resources which belong to that error.
> Michael have you investigated the error, what is it, what cause?
>


Michael merged now MNG-6695.
I will start a couple of build from master on Jenkins in order to see if we
are stable.

I will start a new thread asking for suggestions about the release process


Enrico


T
>
> On Sat, Aug 24, 2019 at 12:08 PM Enrico Olivelli 
> wrote:
>
> > Il ven 23 ago 2019, 11:55 Enrico Olivelli  ha
> > scritto:
> >
> > >
> > > I see this test failing on current master, locally on my machine
> (MacOS),
> > > this is a show stopper...
> > > I will investigate as soon as possible, but today I can't
> > >
> >
> > The test doesn't fail on my fedora box, only on Mac, consistently.
> > We are not using Mac as reference platform (only linux and Windows)
> >
> > So maybe this is not a real problem.
> > Unfortunately thus week I won't have access to any Mac box so I won't be
> > able to reproduce the problem.
> >
> > I feel we can go to the release as soon as we commit the last enhancement
> >
> > Enrico
> >
> >
> >
> > > [ERROR] Tests run: 821, Failures: 1, Errors: 0, Skipped: 0, Time
> elapsed:
> > > 1,366.325 s <<< FAILURE! - in org.apache.maven.it.IntegrationTestSuite
> > >
> > > [ERROR]
> > > testitMNG6386UnicodeChars(org.apache.maven.it
> > .MavenITmng6386BaseUriPropertyTest)
> > > Time elapsed: 1.252 s  <<< FAILURE!
> > >
> > > junit.framework.AssertionFailedError
> > >
> > > at
> > > org.apache.maven.it
> >
> .MavenITmng6386BaseUriPropertyTest.testitMNG6386UnicodeChars(MavenITmng6386BaseUriPropertyTest.java:90)
> > >
> > >
> > >
> > > Enrico
> > >
> > > Il giorno ven 23 ago 2019 alle ore 09:49 Tibor Digana <
> > > tibordig...@apache.org> ha scritto:
> > >
> > >> Yeah Enrico, go for it. ;-)
> > >> Good luck!
> > >>
> > >> T
> > >>
> > >> On Fri, Aug 23, 2019 at 7:18 AM Enrico Olivelli 
> > >> wrote:
> > >>
> > >> > Il gio 22 ago 2019, 23:42 Hervé BOUTEMY  ha
> > >> > scritto:
> > >> >
> > >> > > We have 49 issues closed and nothing remaining open [1]
> > >> > >
> > >> > > Any objection to launch the release now?
> > >> > >
> > >> > > Any volunteer?
> > >> > >
> > >> >
> > >> > I would like to try. I can do it in the weekend.
> > >> > I have only released plugins, maybe I would need some guidance
> > >> >
> > >> > Okay?
> > >> >
> > >> > Enrico
> > >> >
> > >> >
> > >> >
> > >> > > Regards,
> > >> > >
> > >> > > Hervé
> > >> > >
> > >> > > [1] https://issues.apache.org/jira/projects/MNG/versions/12345234
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > -
> > >> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > >> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > >> > >
> > >> > >
> > >> >
> > >>
> > >
> >
>


Re: Releasing Maven 3.6.2

2019-08-24 Thread Enrico Olivelli
Il ven 23 ago 2019, 11:55 Enrico Olivelli  ha scritto:

>
> I see this test failing on current master, locally on my machine (MacOS),
> this is a show stopper...
> I will investigate as soon as possible, but today I can't
>

The test doesn't fail on my fedora box, only on Mac, consistently.
We are not using Mac as reference platform (only linux and Windows)

So maybe this is not a real problem.
Unfortunately thus week I won't have access to any Mac box so I won't be
able to reproduce the problem.

I feel we can go to the release as soon as we commit the last enhancement

Enrico



> [ERROR] Tests run: 821, Failures: 1, Errors: 0, Skipped: 0, Time elapsed:
> 1,366.325 s <<< FAILURE! - in org.apache.maven.it.IntegrationTestSuite
>
> [ERROR]
> testitMNG6386UnicodeChars(org.apache.maven.it.MavenITmng6386BaseUriPropertyTest)
> Time elapsed: 1.252 s  <<< FAILURE!
>
> junit.framework.AssertionFailedError
>
> at
> org.apache.maven.it.MavenITmng6386BaseUriPropertyTest.testitMNG6386UnicodeChars(MavenITmng6386BaseUriPropertyTest.java:90)
>
>
>
> Enrico
>
> Il giorno ven 23 ago 2019 alle ore 09:49 Tibor Digana <
> tibordig...@apache.org> ha scritto:
>
>> Yeah Enrico, go for it. ;-)
>> Good luck!
>>
>> T
>>
>> On Fri, Aug 23, 2019 at 7:18 AM Enrico Olivelli 
>> wrote:
>>
>> > Il gio 22 ago 2019, 23:42 Hervé BOUTEMY  ha
>> > scritto:
>> >
>> > > We have 49 issues closed and nothing remaining open [1]
>> > >
>> > > Any objection to launch the release now?
>> > >
>> > > Any volunteer?
>> > >
>> >
>> > I would like to try. I can do it in the weekend.
>> > I have only released plugins, maybe I would need some guidance
>> >
>> > Okay?
>> >
>> > Enrico
>> >
>> >
>> >
>> > > Regards,
>> > >
>> > > Hervé
>> > >
>> > > [1] https://issues.apache.org/jira/projects/MNG/versions/12345234
>> > >
>> > >
>> > >
>> > > -
>> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> > > For additional commands, e-mail: dev-h...@maven.apache.org
>> > >
>> > >
>> >
>>
>


Re: [VOTE] Retire Maven OSGi

2019-08-23 Thread Enrico Olivelli
+1
Thank you Dirk for checking

Enrico

Il giorno ven 23 ago 2019 alle ore 20:48 Arnaud Héritier <
aherit...@gmail.com> ha scritto:

> +1
>
> Le ven. 23 août 2019 à 15:17, Robert Scholte  a
> écrit :
>
> > Hi,
> >
> > The Apache Maven project consist of about 90 (sub)projects. Due to the
> > small number of volunteers and the huge amount of code to maintain we're
> > missing enough space to make real progress on all these projects,
> > including our ambitious ideas for the next major version(s) of Maven
> > itself.
> > To be able to gain more focus we need to criticize the current
> > subprojects
> > and decide if it is worth maintaining.
> >
> > https://maven.apache.org/shared/maven-osgi/ describes the main purpose
> > in
> > one line: Library for Maven-OSGi integration.
> > There have been only 2 releases: 0.1.0 in July 2007 and 0.2.0 in December
> > 2007 and just one open issue by Stuart McCulloch regarding an unclosed
> jar.
> > It is unclear to me if this library is still used. The library is based
> > on
> > just 3 files: interface, default implementation and dedicated exception.
> > Either the library is complete or never used anymore. In both cases I see
> > no real reason to maintain it.
> >
> > I therefore propose that we retire the maven-osgi library.
> >
> > I don't think it makes sense to do a final release. Instead we should
> > update the documentation and freeze the codebase.
> >
> > The process for retiring a plugin is described here:
> > https://maven.apache.org/developers/retirement-plan-plugins.html
> > [https://maven.apache.org/developers/retirement-plan-plugins.html]
> >
> > The vote is open for 72 hours.
> > [ ] +1 Yes, it's about time
> > [ ] -1 No, because...
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> > --
> -
> Arnaud Héritier
> http://aheritier.net
> Mail/GTalk: aheritier AT gmail DOT com
> Twitter/Skype : aheritier
>


Re: Releasing Maven 3.6.2

2019-08-23 Thread Enrico Olivelli
Il giorno ven 23 ago 2019 alle ore 22:55 Michael Osipov 
ha scritto:

> Am 2019-08-22 um 23:42 schrieb Hervé BOUTEMY:
> > We have 49 issues closed and nothing remaining open [1]
> >
> > Any objection to launch the release now?
>
> I have now scheduled MNG-6695 for inclusion. It has been worked on for
> quite a while.
>
> Is there are no objections, build passes, I will merge this weekend.
>

+1 please go
I am testing current master and I am checking the maven core release
procedure in the meantime


Enrico




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


Re: Releasing Maven 3.6.2

2019-08-23 Thread Enrico Olivelli
I see this test failing on current master, locally on my machine (MacOS),
this is a show stopper...
I will investigate as soon as possible, but today I can't

[ERROR] Tests run: 821, Failures: 1, Errors: 0, Skipped: 0, Time elapsed:
1,366.325 s <<< FAILURE! - in org.apache.maven.it.IntegrationTestSuite

[ERROR]
testitMNG6386UnicodeChars(org.apache.maven.it.MavenITmng6386BaseUriPropertyTest)
Time elapsed: 1.252 s  <<< FAILURE!

junit.framework.AssertionFailedError

at
org.apache.maven.it.MavenITmng6386BaseUriPropertyTest.testitMNG6386UnicodeChars(MavenITmng6386BaseUriPropertyTest.java:90)



Enrico

Il giorno ven 23 ago 2019 alle ore 09:49 Tibor Digana <
tibordig...@apache.org> ha scritto:

> Yeah Enrico, go for it. ;-)
> Good luck!
>
> T
>
> On Fri, Aug 23, 2019 at 7:18 AM Enrico Olivelli 
> wrote:
>
> > Il gio 22 ago 2019, 23:42 Hervé BOUTEMY  ha
> > scritto:
> >
> > > We have 49 issues closed and nothing remaining open [1]
> > >
> > > Any objection to launch the release now?
> > >
> > > Any volunteer?
> > >
> >
> > I would like to try. I can do it in the weekend.
> > I have only released plugins, maybe I would need some guidance
> >
> > Okay?
> >
> > Enrico
> >
> >
> >
> > > Regards,
> > >
> > > Hervé
> > >
> > > [1] https://issues.apache.org/jira/projects/MNG/versions/12345234
> > >
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > >
> > >
> >
>


Re: Releasing Maven 3.6.2

2019-08-22 Thread Enrico Olivelli
Il gio 22 ago 2019, 23:42 Hervé BOUTEMY  ha scritto:

> We have 49 issues closed and nothing remaining open [1]
>
> Any objection to launch the release now?
>
> Any volunteer?
>

I would like to try. I can do it in the weekend.
I have only released plugins, maybe I would need some guidance

Okay?

Enrico



> Regards,
>
> Hervé
>
> [1] https://issues.apache.org/jira/projects/MNG/versions/12345234
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>


Re: Asking for release: Eclipse 2019-06 incompatible with Tycho because of Maven 3.6.1 bug

2019-08-21 Thread Enrico Olivelli
Il mer 21 ago 2019, 10:37 Tibor Digana  ha scritto:

> > Is it a regression compared to last release
>
> This was also my question but anyway the bug looks scarying and it is an
> indicator of hanging Maven
> So we should ask the authour of the PR:
> https://github.com/apache/maven-resolver/pull/39
>
> Cheers
> Tibor17
>
> On Wed, Aug 21, 2019 at 12:39 AM Mickael Istria 
> wrote:
>
> > On Tue, Aug 20, 2019 at 9:01 PM Tibor Digana 
> > wrote:
> >
> > > Want to announce you about a new issue in the Resolver.
> > > @Herve @Sylwester I found you in the history. Can you comment author's
> > > changes?
> >
> >
> > Is it a regression compared to last release? If not, I don't think it
> > should be made a blocker for upcoming release.
>

I agree.
If do not have other blocker we should cut a release as soon as possible

Enrico

>
>


Re: MASSEMBLY-918 proposal

2019-08-19 Thread Enrico Olivelli
I was thinking more about 1) but I am not a 'tar' master.
Maybe you can write a simple jshell script that uses the java libs and
tweaks the tarbar

Enrico

Il dom 18 ago 2019, 22:10  ha scritto:

> 4. Squash Docker image layers? This approach requires additional tool (
> https://github.com/jwilder/docker-squash requires sudo) and understanding
> of what layers to squash and what layers to keep as is (for optimization of
> Docker image delivery - some base layers are taken from image vendor and
> are not changed, so I need to keep them to avoid re-delivering of the whole
> Docker image). I'm not sure about impact of squashing of Docker layers on
> Docker build cache and on the whole time required for building (if TAR
> checksum didn't change then rebuilding of Docker image is faster due to
> Docker build cache).
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>


Re: MASSEMBLY-918 proposal

2019-08-18 Thread Enrico Olivelli
Can't you run some post package script with the maven exec plugin?


Enrico

Il ven 16 ago 2019, 19:55  ha scritto:

> Hi Enrico,
>
> Yes, I need just root:root for the task I described, but it doesn't look
> like correct (generic) solution to add just flag for the "root ownership",
> because its implementation looks as hard (easy for smbd) as adding
> possibility to specify both user and group.
>
> Marat.
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>


Re: Review - Maven Core - Resolver 1.4.1

2019-08-18 Thread Enrico Olivelli
+1

Enrico

Il dom 18 ago 2019, 17:25 Tibor Digana  ha scritto:

> Hi,
>
> There's a new branch MNG-6738 with new Resolver 1.4.1.
> If you have no objections, I will push it to master.
>
> https://gitbox.apache.org/repos/asf?p=maven.git;a=commit;h=88b632cf3d727c7d003a8a36f1b39bffb2f790f3
>
> The build is running
> https://builds.apache.org/job/maven-box/job/maven/job/MNG-6738/
>
> Cheers
> Tibor
>


Re: plugins share common repository on one Jenkins node

2019-08-18 Thread Enrico Olivelli
Il ven 16 ago 2019, 20:37 Tibor Digana  ha scritto:

> The builds on a Jenkins node should be isolated. The paths of local
> repository should be distinct. Therefore we used the trick with
> EXECUTOR_NUMBER:
>
>
> https://gitbox.apache.org/repos/asf?p=maven-jenkins-lib.git;a=blob;f=vars/asfMavenTlpPlgnBuild.groovy;h=e4576ac12e9dec73aee0540fa9aab37fd507d614;hb=HEAD#l150
>
> This is the path and wrong because it is not distinct!
> Local Repo (linux-jdk11-m3.6.x_build): ../.maven_repositories/null
>
> The problem is that the code is not serialized on the particular Jenkins
> node and executor.
> Thus we observed errors in Archetype builds when running integration tests
> via maven-invoker-plugin:
>
> [INFO] Building: build-and-run-its\pom.xml
> [INFO] run post-build script verify.groovy
> WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by
> org.codehaus.groovy.reflection.CachedClass
>
> (file:/F:/short/.maven_repositories/null/org/codehaus/groovy/groovy-all/2.4.8/groovy-all-2.4.8.jar)
> to method java.lang.Object.finalize()
>
> So I moved the code into the targeting execution block:
>
>
> https://gitbox.apache.org/repos/asf?p=maven-jenkins-lib.git;a=commitdiff;h=aee445426dac012af4326c0b80c93422200c2a56
>
> and the logs look promissing now:
>
> Local Repo (windows-jdk11-m3.6.x_build): ../.maven_repositories/0
> Local Repo (windows-jdk12-m3.6.x_build): ../.maven_repositories/1
> Local Repo (windows-jdk13-m3.6.x_build): ../.maven_repositories/2
>

Good catch!

Thank you Tibor

Enrico



> --
> Cheers
> Tibor
>


Re: MASSEMBLY-918 proposal

2019-08-16 Thread Enrico Olivelli
Marat,
Sorry for late reply.

Il lun 29 lug 2019, 19:00  ha scritto:

> Hi community.
>
> I use Maven with Maven Resources plugin and Dockerfile Maven plugin
> (https://github.com/spotify/dockerfile-maven) for building my Docker
> images
> and this approach works fine (much better than shell scripts) except one
> issue - refer to "The backlash of chmod/chown/mv in your Dockerfile"
> article
> (
> https://medium.com/@lmakarov/the-backlash-of-chmod-chown-mv-in-your-dockerf
> ile-f12fe08c0b55
> ).
> I was able to solve this issue in terms of location and
> file / directory permissions with Maven Assembly plugin and TAR format but
> ownership of files and directories is still an issue - refer to
> https://issues.apache.org/jira/browse/MASSEMBLY-918 for details.
>


So you need to create tar files with root:root as owner of files?

Enrico

>
> This issue with ownership is important for the business project I work in
> because this issue becomes security issue (well, it's **minor** security
> issue to be honest, but I'd prefer to not prove that for software security
> team but just fix the issue) when Red Hat OpenShift and RHEL 7 are used,
> i.e. the same issue may be important for other business projects
> ("corporates") utilizing the same (popular) stack.
>
> I implemented PoC which demonstrates that MASSEMBLY-918 can be easily
> solved
> (refer to issue description). It's still PoC because it doesn't follow all
> the rules required for official pull requests and contains no unit tests
> for
> the new feature I implemented.
>
> I'd like to understand:
>
> 1. If MASSEMBLY-918 is actual for other developers? Does anybody else use
> Maven for building of Docker images and have the same limits because of
> RHEL
> and OpenShift?
> 2. Does it make sense to invest into official pull requests for further
> promotion of changes (these changes may be helpful not only for building of
> Docker images)?
>
> Thank you.
>
> Regards,
> Marat Abrarov.
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>


Re: [maven-core] Feedback wanted: MNG-6732 DefaultArtifactDescriptorReader.loadPom to check IGNORE_MISSING policy upon ArtifactTransferException

2019-08-15 Thread Enrico Olivelli
Tomo,
I left a comment on github

Cheers
Enrico

Il gio 15 ago 2019, 18:05 Tomo Suzuki  ha
scritto:

> Hi Maven developers,
>
> I appreciate if somebody can give feedback on my raised issue and pull
> request.
>
> [MNG-6732] - DefaultArtifactDescriptorReader.loadPom to check
> IGNORE_MISSING policy upon ArtifactTransferException
> https://issues.apache.org/jira/browse/MNG-6732
> https://github.com/apache/maven/pull/277
>
> --
> Regards,
> Tomo
>


Re: Setup a CI job for a PR

2019-08-09 Thread Enrico Olivelli
Romain

Il ven 9 ago 2019, 19:47 Romain Manni-Bucau  ha
scritto:

> Hi everyone,
>
> I'd like to make https://github.com/apache/maven-shade-plugin/pull/24
> passing
> on our CI to ensure it is the issue we see on master, however I don't
> manage to create a job, I pushed a branch with the jira name on asf repo
> but nothing pops up on jenkins.
>


I see that you already pushed a branch to the shared repo

https://github.com/apache/maven-shade-plugin/tree/MSHADE-322

But jenkins is not starting


Enrico


> What do I miss?
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>


Re: Asking for release: Eclipse 2019-06 incompatible with Tycho because of Maven 3.6.1 bug

2019-08-01 Thread Enrico Olivelli
Il gio 1 ago 2019, 20:58 Michael Osipov  ha scritto:

> Am 2019-08-01 um 20:53 schrieb Mickael Istria:
> > Hey all,
> >
> > Any news here?
> >
>
>
> I think we basically need to fix MNG-6713 and MNG-6716 and then need to
> stand up as RM.
>

There is a big work going on.
Once we have a stable master branch I can try to perform the release
procedure


Enrico


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


Fwd: JDK installations on Jenkins nodes

2019-07-29 Thread Enrico Olivelli
FYI from bui...@apache.org

-- Forwarded message -
Da: Chris Thistlethwaite 
Date: lun 29 lug 2019 alle ore 16:21
Subject: JDK installations on Jenkins nodes
To: 


Greetings!

I'm going to be trimming the available JDK versions on the Jenkins
nodes, both Linux and Windows, to better line up with what Infra is
going to support. The "latest" symlink will stick around and will point
to the latest build of whatever is currently the latest build of JDK.
We're trying to cut down on the amount of different JDK builds of the
same release, for example JDK 1.8_92, 121, 144, 152, when all we really
want is build 152. We will also not be adding any older, unsupported
builds of JDK unless there is a critical security update. So JDK1.7.0_79
will be latest7 for the foreseeable future.

Please review
https://cwiki.apache.org/confluence/display/INFRA/JDK+Installation+Matrix
for the changes, they are highlighted in yellow. Nothing should change
for you if you're using one of the "latest" symlinks, this really only
changes builds targeted at a specific JDK.

Thank you,
Chris T.
#asfinfra


Re: Archiving ITs result in Plugin builds

2019-07-28 Thread Enrico Olivelli
Tibor,
Thanks for the heads up

Enrico

Il dom 28 lug 2019, 02:26 Tibor Digana  ha scritto:

> Hi devs,
>
> Now we can archive any directories in plugin builds.
> This feature was enabled in Jenkins library maven-jenkins-lib.
>
> For instance, this is the Jenkinsfile script from apache/maven-archetype.
> Here you can see how to archive the build result of all ITs from failed
> builds for further analysis:
>
> asfMavenTlpPlgnBuild(tmpWs: true, archives: ['archetype-plugin-its' :
> 'maven-archetype-plugin/target/it/projects'])
>
>
>
> Cheers
> Tibor17
>


Re: Second MNG-6713

2019-07-27 Thread Enrico Olivelli
Il sab 27 lug 2019, 12:52 Robert Scholte  ha scritto:

> On Sat, 27 Jul 2019 11:52:21 +0200, Enrico Olivelli 
>
> wrote:
>
> > Il gio 25 lug 2019, 09:33 Alexius Diakogiannis <
> > alexius.diakogian...@gmail.com> ha scritto:
> >
> >> Hi,
> >>
> >> In my honest opinion it does, in case you want to switch from artifacts
> >> that belong to a migrated groupid.
> >>
> >
> > It may have sense, but it is very corner case.
> > I have never seen such cases.
> >
> > It would be interesting to have some 'exclude * except ...'
> >
> > Like
> > 
> > io.netty
> > * but keep netty-all
> > 
>
> I don't think we should do something like this. In Maven we have includes
> to define a set of dependencies and excludes to remove some specific
> dependencies. Adding another layer would overcomplicate things.
>


Robert,
You are right and your example is what people usually do. And I agree is it
better.
I was just thinking out loud.
Thanks for your reply.

Enrico



> Instead, people could do:
> 
>   GROUPID
>   ARTIFACT
>   
>
>io.netty
>*
>
>   
> 
> 
>   io.netty
>   netty-all
> 
>
> >
> > Netty is famous for shipping a uber netty-all and a ten of netty-codec,
> > netty-common...artifacts and it is always a mess to keep clean the
> > dependency tree in case of multiple consumers of such library in
> > different
> > flavours (uber vs split)
> >
> > Sorry for beeing slightly off topic
> >
> > I will review the patch
> >
> > Enrico
> >
> >
> >
> >> Thanks,
> >> Alexius
> >>
> >>
> >> On Thu, 25 Jul 2019 at 10:29, Robert Scholte <
> >> robert.scho...@sourcegrounds.nl> wrote:
> >>
> >> > At JCrete I've been working with Ray Tsang on some issues with
> >> enforcer
> >> > rules that didn't respect the exclusions of dependencies.
> >> > After digging a log we discovered that the real issue is the
> >> > ExclusionFilter, which isn't aware of wildcard exclusions.
> >> > So the fix was quite easy[1]
> >> > The funny thing is that the original IncludesArtifactFilter (3.6.0 and
> >> > before) had a todo comment regarding wildcards[2]
> >> > With MNG-6713[3] several enforcer rules are fixed automatically,
> >> without
> >> > any codechange!
> >> >
> >> > As long as master is still unstable, it is hard to confirm this change
> >> > doesn't cause any regression.
> >> >
> >> > One thing worth mentioning (as the wildcards are never explicitly
> >> > specified):
> >> > Does it make sense to have a wildcard from groupId and an explicit
> >> value
> >> > for artifactId?
> >> > Current proposal allows it.
> >> >
> >> > thanks,
> >> > Robert
> >> >
> >> > [1] https://github.com/apache/maven/pull/269
> >> > [2]
> >> >
> >> >
> >>
> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/artifact/resolver/filter/
> >> > IncludesArtifactFilter.java#L52
> >> > <
> >>
> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/artifact/resolver/filter/IncludesArtifactFilter.java#L52
> >> >
> >> > [3] https://issues.apache.org/jira/browse/MNG-6713
> >> >
> >> > -
> >> > 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: Second MNG-6713

2019-07-27 Thread Enrico Olivelli
Il gio 25 lug 2019, 09:33 Alexius Diakogiannis <
alexius.diakogian...@gmail.com> ha scritto:

> Hi,
>
> In my honest opinion it does, in case you want to switch from artifacts
> that belong to a migrated groupid.
>

It may have sense, but it is very corner case.
I have never seen such cases.

It would be interesting to have some 'exclude * except ...'

Like

io.netty
* but keep netty-all


Netty is famous for shipping a uber netty-all and a ten of netty-codec,
netty-common...artifacts and it is always a mess to keep clean the
dependency tree in case of multiple consumers of such library in different
flavours (uber vs split)

Sorry for beeing slightly off topic

I will review the patch

Enrico



> Thanks,
> Alexius
>
>
> On Thu, 25 Jul 2019 at 10:29, Robert Scholte <
> robert.scho...@sourcegrounds.nl> wrote:
>
> > At JCrete I've been working with Ray Tsang on some issues with enforcer
> > rules that didn't respect the exclusions of dependencies.
> > After digging a log we discovered that the real issue is the
> > ExclusionFilter, which isn't aware of wildcard exclusions.
> > So the fix was quite easy[1]
> > The funny thing is that the original IncludesArtifactFilter (3.6.0 and
> > before) had a todo comment regarding wildcards[2]
> > With MNG-6713[3] several enforcer rules are fixed automatically, without
> > any codechange!
> >
> > As long as master is still unstable, it is hard to confirm this change
> > doesn't cause any regression.
> >
> > One thing worth mentioning (as the wildcards are never explicitly
> > specified):
> > Does it make sense to have a wildcard from groupId and an explicit value
> > for artifactId?
> > Current proposal allows it.
> >
> > thanks,
> > Robert
> >
> > [1] https://github.com/apache/maven/pull/269
> > [2]
> >
> >
> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/artifact/resolver/filter/
> > IncludesArtifactFilter.java#L52
> > <
> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/artifact/resolver/filter/IncludesArtifactFilter.java#L52
> >
> > [3] https://issues.apache.org/jira/browse/MNG-6713
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>


Re: Problems with checkstyle tests on Windows (Was [VOTE] Release Apache Maven Checkstyle Plugin version 3.1.0)

2019-07-24 Thread Enrico Olivelli
Il mer 24 lug 2019, 10:02 Tibor Digana  ha scritto:

> Hi Enrico,
>
> Do we have a statement from vendors of PMD and/or Checkstyle libraries that
> their rules would turn to platform independence?
> I know there was a pull request on GitHub and a promis with the release (I
> guess PMD).
> Once we would have these libraries with modified default values in favor of
> platform non-sensitive EOL rules, we would not have to apapt our
> integration tests to platform.
>


I think that Checkstyle has been released and we should upgrade it.
Enrico


> Cheers
> Tibor
>
>
> On Tue, May 14, 2019 at 2:11 PM Enrico Olivelli 
> wrote:
>
> > I will get a windows box and try to reproduce.
> > It is weird that on ASF Jenkins the build is passing even on windows
> >
> > Enrico
> >
> > -- Forwarded message -
> > Da: Enrico Olivelli 
> > Date: mar 14 mag 2019, 13:58
> > Subject: Re: [VOTE] Release Apache Maven Checkstyle Plugin version 3.1.0
> > To: Maven Developers List 
> >
> >
> > Eric and Tibor,
> > Thank you so much for your effort in testing Maven Checkstyle Plugin.
> >
> > This is the "official" VOTE thread, here we have to decide if the staged
> > artifacts are good to be released or not.
> >
> > Feel free to cast a -1 if you think that the staged artifacts are not
> > "stable" or there is any showstopper problem for the release.
> >
> > Let's move this discussion to a separate thread, something like
> "Validation
> > failures in Windows over current checkstyle plugin master branch")
> >
> > Enrico
> >
> >
> >
> >
> > Il giorno mar 14 mag 2019 alle ore 13:51 Eric Lilja <
> mindcoo...@gmail.com>
> > ha scritto:
> >
> > > Tried overriding line.separator when running using
> -Dline.separator="\n",
> > > but then the builds fails (early) in maven-plugin-plugin:
> > > [ERROR] Failed to execute goal
> > > org.apache.maven.plugins:maven-plugin-plugin:3.5:descriptor
> > > (default-descriptor) on project maven-checkstyle-plugin: Execution
> > > default-descriptor of goal
> > > org.apache.maven.plugins:maven-plugin-plugin:3.5:descriptor failed:
> > > Requested line separator is invalid. -> [Help 1]
> > > [ERROR]
> > > [ERROR] To see the full stack trace of the errors, re-run Maven with
> the
> > -e
> > > switch.
> > > [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> > > [ERROR]
> > > [ERROR] For more information about the errors and possible solutions,
> > > please read the following articles:
> > > [ERROR] [Help 1]
> > >
> >
> http://cwiki.apache.org/confluence/display/MAVEN/PluginExecutionException
> > >
> > > Tried upgrading maven-plugin-plugin to 3.6.0 (lots of stuff
> > > upgradeable...), but same error
> > >
> > > I also happened to notice this (probably unrelated, but wanted to bring
> > it
> > > to attention anyway so it can be fixed) warning:
> > > [INFO] java-annotations mojo extractor found 4 mojo descriptors.
> > > [WARNING]
> > >
> > > Unexpected situation: destinationDirectory not defined in
> > > maven-plugin-help.properties during help mojo source generation but
> > > expected during XML descriptor generation.
> > > [WARNING] Please check helpmojo goal version used in previous build
> > phase.
> > > [WARNING] If you just upgraded to plugin-tools >= 3.2 you must run a
> > clean
> > > build at least once.
> > > [WARNING] Trying default location: target\generated-sources\plugin
> > >
> > > - Eric L
> > >
> > > On Tue, May 14, 2019 at 11:04 AM Eric Lilja 
> > wrote:
> > >
> > > > I tried bumping checkstyle to 8.20, plus a few of the plexus
> > > dependencies,
> > > > but that just brought an additional failure... (to
> > > > MCHECKSTYLE-70-multi-sourcefolder\pom.xml)  :-)
> > > >
> > > > I suppose the problem might be that the files has linux-style line
> > breaks
> > > > (this is desired for me, I don't want to convert to windows-style
> line
> > > > breaks locally), but the test think I should have windows-style line
> > > > separators. It seems these files are generated by the tests because I
> > > tried
> > > > changing them to Windows style line breaks for re-running just to see
> > if
> > > > that would work, but those changes were overwritten)

Re: Maven Build Fix and Reverting MRESOLVER-7

2019-07-17 Thread Enrico Olivelli
+1

Enrico

Il mer 17 lug 2019, 19:49 Tibor Digana  ha scritto:

> For these purpose of build stability, see Jira issue
> https://issues.apache.org/jira/browse/MNG-6712
> "Revert maven-resolver:1.4.0 to 1.3.3"
>
>
>
> On Tue, Jul 16, 2019 at 12:48 PM Tibor Digana 
> wrote:
>
> > Hello devs,
> >
> > You may have noticed that Maven build fails over one month.
> > We cann't cut a new release version of Maven.
> > Additionally, another Maven builds still fail too.
> >
> > Not speaking too long, I want to inform you that I want to revert the
> > commit of MRESOLVER-7 in Maven Core and make the build passing. I will
> try
> > to do so in an outstanding branch and confirm successful build.
> >
> > The reasoning about this activity is explained in
> >
> >
> https://issues.apache.org/jira/browse/MRESOLVER-7?focusedCommentId=16885618=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16885618
> >
> > Have a nice day!
> > Tibor17
> >
> >
>


Re: Problems with checkstyle tests on Windows (Was [VOTE] Release Apache Maven Checkstyle Plugin version 3.1.0)

2019-07-17 Thread Enrico Olivelli
Il mer 17 lug 2019, 13:28 Eric Lilja  ha scritto:

> I believe, if we instead upgrade to Checkstyle 8.21 or later, we don't need
> to do any of those alternative approaches.
>
> https://github.com/checkstyle/checkstyle/issues/4073


Eric
I think it is the best idea
Do you have cycles to give it a try?

Enrico



>
> - Eric L
>
>
> On Wed, Jul 17, 2019 at 1:20 PM Vladimir Sitnikov <
> sitnikov.vladi...@gmail.com> wrote:
>
> > Robert>A clone from Git succeeds, but the sources.zip fails.
> > Robert>The files in the zip are generated on a unix system, so all EOLs
> in
> > text files are LF
> > Robert>...
> > Robert>The fix: add a setup.groovy to the IT and rewrite the java files
> > with OS specific EOLs
> >
> > Alternative approaches:
> > A) Provide both Linux (LF) and Windows (CRLF) source distributions (e.g.
> > *.zip and *.tgz).
> > B) Specify "lineSeparator" explicitly. Then you could have both CRLF and
> LF
> > files at the same time and verify if those work
> > C) Generate file at the build stage. If you generate it into target/
> > directory, then you could generate the file with appropriate for the
> > platform enconding
> > D) Ensure the file is always in LF or CRLF by adding a relevant
> > .gitattributes entry
> >
> > Vladimir
> >
>


Re: ITs in maven-release

2019-07-14 Thread Enrico Olivelli
Il dom 14 lug 2019, 11:52 Clemens Quoss  ha scritto:

> Hello everyone,
>
> I have provided a PR for MRELEASE-229 [1] and added some JUnit tests
> recently.
>
> Now I was wondering if i should provide an IT, too, and had a look into it:
>
> Running
>
> mvn verify -Prun-its
>
> with Maven 3.6.1 and JDK 7 Update 80 fails:
>
> ...
>
> [INFO] Building: projects\perform\MRELEASE-459\pom.xml
> [INFO] run post-build script verify.groovy
> [INFO]   The post-build script did not succeed. assert matcher.find()
> |   |
> |   false
> java.util.regex.Matcher[pattern=\Q[DEBUG] Additional arguments:
> \E(?:-Dhttps.protocols=TLSv1.2 )?-P(.+)\Q-DperformRelease=true -f
> pom.xml\E region=0,154745 lastmatch=]
> [INFO]   projects\perform\MRELEASE-459\pom.xml 
> FAILED (10.4 s)
>
> ...
>
> IMHO it has something to do with TLSv1.2 not being backported to JDK 7
> Update 80.  But i may be wrong.
>
> With JDK 8 Update 212 the tests run successfully.
>
> My question is:  Should the IT still run with JDK 7?


Yes

Enrico


I thought so since
> maven-release can still be build with it.  If some versions of JDKs are
> not capable of being used for IT, shouldn't the IT run fail fast (by
> enforcing the eligible versions)?
>
> That was one question I have now redarding the ITs of maven-release.  I
> post my other questions in separate mails.
>
> Regards,
>
> Clemens
>
> [1] https://github.com/apache/maven-release/pull/29
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>


Re: Re: Asking for release: Eclipse 2019-06 incompatible with Tycho because of Maven 3.6.1 bug

2019-07-09 Thread Enrico Olivelli
In the mean time I am running the integration tests of maven core on my
linux box and I have a bunch of failures, I am investigating.

Enrico

Il giorno mar 9 lug 2019 alle ore 14:25 Michael Osipov <1983-01...@gmx.net>
ha scritto:

> Already merged a week ago. Someone has to push a release.
>
> > Gesendet: Dienstag, 09. Juli 2019 um 11:44 Uhr
> > Von: "Enrico Olivelli" 
> > An: "Maven Developers List" 
> > Cc: "Gabriel Belingueres" , "Mickael Istria" <
> mist...@redhat.com>
> > Betreff: Re: Asking for release: Eclipse 2019-06 incompatible with Tycho
> because of Maven 3.6.1 bug
> >
> > Michael,
> > did you have time to take a look to Plexus stuff ?
> >
> > I am back from vacation, I am ready to start the procedure
> >
> > Enrico
> >
> > Il giorno lun 1 lug 2019 alle ore 21:41 Michael Osipov <
> micha...@apache.org>
> > ha scritto:
> >
> > > Am 2019-06-30 um 00:26 schrieb Gabriel Belingueres:
> > > > Before the release of 3.6.2 please consider to cut a release of
> > > > plexus-utils, which has PRs for two important issues:
> > > >
> > > > DirectoryScanner traverses directories despite limited inclusions
> > > > <https://github.com/codehaus-plexus/plexus-utils/issues/63>
> > > > XML processing instructions with embedded '>' fail to parse
> > > > <https://github.com/codehaus-plexus/plexus-utils/issues/65>
> > >
> > > I will look at both.
> > >
> > > There are some open, and heavily discussed PRs for perfomance
> > > improvement on Maven. They will likely land in 3.6.2 as well.
> > >
> >
> >
> >
> >
> >
> > >
> > > -
> > > 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: Asking for release: Eclipse 2019-06 incompatible with Tycho because of Maven 3.6.1 bug

2019-07-09 Thread Enrico Olivelli
Michael,
did you have time to take a look to Plexus stuff ?

I am back from vacation, I am ready to start the procedure

Enrico

Il giorno lun 1 lug 2019 alle ore 21:41 Michael Osipov 
ha scritto:

> Am 2019-06-30 um 00:26 schrieb Gabriel Belingueres:
> > Before the release of 3.6.2 please consider to cut a release of
> > plexus-utils, which has PRs for two important issues:
> >
> > DirectoryScanner traverses directories despite limited inclusions
> > 
> > XML processing instructions with embedded '>' fail to parse
> > 
>
> I will look at both.
>
> There are some open, and heavily discussed PRs for perfomance
> improvement on Maven. They will likely land in 3.6.2 as well.
>





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


Re: Asking for release: Eclipse 2019-06 incompatible with Tycho because of Maven 3.6.1 bug

2019-06-26 Thread Enrico Olivelli
Il mer 26 giu 2019, 22:39 Michael Osipov  ha scritto:

> Am 2019-06-26 um 16:51 schrieb Mickael Istria:
> > Hi all,
> >
> > Eclipse m2e did include a newer release of Maven in order to greatly
> > improve its performances. This release was 3.6.1 (3.6.0 had a bug making
> > some of its APIs unusable by m2e internals).
> > However, Maven 3.6.1 also breaks compatibility with Eclipse Tycho. It was
> > the topic of a Jira, that was fixed.
> > The only way to get it all working would be to adopt a newer version of
> > Maven in next release of m2e (in September).
> >
> > Is there a date already set for 3.6.2 release?
> > Could it be pretty soon as this issue is basically hurting all Eclipse
> > plugin developers (which we assume 99% use the Eclipse IDE and Eclipse
> > Tycho) ?
>
> I don't see anything blocking this. We just need someone to be the
> release manager for 3.6.2. Any volunteers?
>

I will be happy to try, but I will be on vacation next week
I have already managed releases for plugins I guess the procedure is
somehow more complex.

If I understand correctly there is a bit of hurry, If any other volunteer
steps in I can do the next time.


Enrico


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


[ANN] Apache Maven JDeps Plugin 3.1.2 Released

2019-06-20 Thread Enrico Olivelli
The Apache Maven team is pleased to announce the release of the Apache
Maven JDeps Plugin, version 3.1.2

The JDeps Plugin uses the jdeps tool to analyze classes for internal API
calls. For more information about the standard jdeps tool,
please refer to
https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool

https://maven.apache.org/plugins/maven-jdeps-plugin/

You should specify the version in your project's plugin configuration:


  org.apache.maven.plugins
  maven-jdeps-plugin
  3.1.2


You can download the appropriate sources etc. from the download page:

https://maven.apache.org/plugins/maven-jdeps-plugin/download.cgi

Release Notes - Maven JDeps Plugin - Version 3.1.2

** Improvement
* [MJDEPS-23] - The parameter multiRelease should have a user property
so that you can set it from the command line

** Dependency upgrade
* [MJDEPS-17] - Upgrade maven-plugins parent to version 33

Enjoy,

-The Apache Maven team


[RESULT] [VOTE] Release Apache Maven JDeps Plugin version 3.1.2

2019-06-18 Thread Enrico Olivelli
- Hi,
-
- The vote has passed with the following result:
-
- +1 : Tibor Digana, Robert Scholte, Sylwester Lachiewicz, Hervé Boutemy
-
- PMC quorum:reached
-
- I will promote the artifacts to the central repo.
-
- As usual I will need help from any PMC in order to move the
artifacts to the ASF
- dist area
-

Enrico

Il giorno mar 18 giu 2019 alle ore 21:32 Robert Scholte <
rfscho...@apache.org> ha scritto:

> +1
>
>
> On 12-6-2019 17:29:22, Enrico Olivelli  wrote:
> Hi,
>
> We solved 2 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12342845=Text=12319223
>
> There are still a couple of issues left in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MJDEPS%20AND%20status%20%3D%20open
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1512
>
> https://repository.apache.org/content/repositories/maven-1512/org/apache/maven/plugins/maven-jdeps-plugin/3.1.2/maven-jdeps-plugin-3.1.2-source-release.zip
>
> Source release checksum(s):
> maven-jdeps-plugin-3.1.2-source-release.zip sha512:
>
> e268500d5f9e6f03f5ea8ffd218de414af401cb336e1445eddfffba0867bf0741514ff5fa12e8193306888a5d605aacd8aa3637a3c3bbfaaee6437817ac5ebe1
>
> Staging site:
> https://maven.apache.org/plugins-archives/maven-jdeps-plugin-LATEST/
>
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for at least 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
>
> Enrico
>


Re: [VOTE] Release Apache Maven JDeps Plugin version 3.1.2

2019-06-18 Thread Enrico Olivelli
One more PMC vote please


Enrico

Il dom 16 giu 2019, 18:42 Tibor Digana  ha scritto:

> +1, sha512 ok, and build passed successfully on jdk 1.8 and 12
>
> On Wed, Jun 12, 2019 at 5:29 PM Enrico Olivelli 
> wrote:
>
> > Hi,
> >
> > We solved 2 issues:
> >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12342845=Text=12319223
> >
> > There are still a couple of issues left in JIRA:
> >
> >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MJDEPS%20AND%20status%20%3D%20open
> >
> > Staging repo:
> > https://repository.apache.org/content/repositories/maven-1512
> >
> >
> https://repository.apache.org/content/repositories/maven-1512/org/apache/maven/plugins/maven-jdeps-plugin/3.1.2/maven-jdeps-plugin-3.1.2-source-release.zip
> >
> > Source release checksum(s):
> > maven-jdeps-plugin-3.1.2-source-release.zip sha512:
> >
> >
> e268500d5f9e6f03f5ea8ffd218de414af401cb336e1445eddfffba0867bf0741514ff5fa12e8193306888a5d605aacd8aa3637a3c3bbfaaee6437817ac5ebe1
> >
> > Staging site:
> > https://maven.apache.org/plugins-archives/maven-jdeps-plugin-LATEST/
> >
> > Guide to testing staged releases:
> > https://maven.apache.org/guides/development/guide-testing-releases.html
> >
> > Vote open for at least 72 hours.
> >
> > [ ] +1
> > [ ] +0
> > [ ] -1
> >
> >
> > Enrico
> >
>


Re: [VOTE] Release Apache Maven Archiver version 3.1.1

2019-06-17 Thread Enrico Olivelli
+1 built and run its on jdk12 on linux
checksum is good

Thank you Tibor
Enrico

Il giorno dom 16 giu 2019 alle ore 18:08 Sylwester Lachiewicz <
slachiew...@gmail.com> ha scritto:

> +1
> Tested on JDK 12.
>
> czw., 13 cze 2019 o 17:18 Tibor Digana 
> napisał(a):
>
> > Hi,
> >
> > We solved 1 issue:
> >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317122=12345450
> >
> > There are still a couple of issues left in JIRA:
> >
> >
> https://issues.apache.org/jira/i#issues/?jql=project+%3D+ARCHETYPE+AND+status+%3D+Open+ORDER+BY+priority+DESC
> >
> > Staging repo:
> > https://repository.apache.org/content/repositories/maven-1513/
> >
> >
> https://repository.apache.org/service/local/repositories/maven-1513/content/org/apache/maven/archetype/maven-archetype/3.1.1/maven-archetype-3.1.1-source-release.zip
> >
> > Source release checksum(s):
> > maven-archetype-3.1.1-source-release.zip sha512:
> >
> >
> 4c41063cbc57c22f9b3ac615686a3fcc7f0bfb2e1967406ab1389712f6012e9d27dafa9553a8bf9af1d495f0a04ca91975599e9518d7a5ae05f6f570834473dc
> >
> > Staging site:
> > https://maven.apache.org/archetype-archives/archetype-LATEST/
> >
> > Guide to testing staged releases:
> > http://maven.apache.org/guides/development/guide-testing-releases.html
> >
> > Vote open for 72 hours.
> >
> > [ ] +1
> > [ ] +0
> > [ ] -1
> >
> > Cheers
> > Tibor17
> >
>


Re: [VOTE] Release Apache Maven JDeps Plugin version 3.1.2

2019-06-16 Thread Enrico Olivelli
Please anybody take a chance to check and validate


Enrico

Il mer 12 giu 2019, 17:28 Enrico Olivelli  ha scritto:

> Hi,
>
> We solved 2 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12342845=Text=12319223
>
> There are still a couple of issues left in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MJDEPS%20AND%20status%20%3D%20open
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1512
>
> https://repository.apache.org/content/repositories/maven-1512/org/apache/maven/plugins/maven-jdeps-plugin/3.1.2/maven-jdeps-plugin-3.1.2-source-release.zip
>
> Source release checksum(s):
> maven-jdeps-plugin-3.1.2-source-release.zip sha512:
> e268500d5f9e6f03f5ea8ffd218de414af401cb336e1445eddfffba0867bf0741514ff5fa12e8193306888a5d605aacd8aa3637a3c3bbfaaee6437817ac5ebe1
>
> Staging site:
> https://maven.apache.org/plugins-archives/maven-jdeps-plugin-LATEST/
>
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for at least 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
>
> Enrico
>


[VOTE] Release Apache Maven JDeps Plugin version 3.1.2

2019-06-12 Thread Enrico Olivelli
Hi,

We solved 2 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12342845=Text=12319223

There are still a couple of issues left in JIRA:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20MJDEPS%20AND%20status%20%3D%20open

Staging repo:
https://repository.apache.org/content/repositories/maven-1512
https://repository.apache.org/content/repositories/maven-1512/org/apache/maven/plugins/maven-jdeps-plugin/3.1.2/maven-jdeps-plugin-3.1.2-source-release.zip

Source release checksum(s):
maven-jdeps-plugin-3.1.2-source-release.zip sha512:
e268500d5f9e6f03f5ea8ffd218de414af401cb336e1445eddfffba0867bf0741514ff5fa12e8193306888a5d605aacd8aa3637a3c3bbfaaee6437817ac5ebe1

Staging site:
https://maven.apache.org/plugins-archives/maven-jdeps-plugin-LATEST/

Guide to testing staged releases:
https://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for at least 72 hours.

[ ] +1
[ ] +0
[ ] -1


Enrico


Re: Cutting Releases of JDeps and Scripting Plugins

2019-06-10 Thread Enrico Olivelli
I see no one objects.
I will cut a release for jdeps as soon as possible.

for the 'scripting' plugin maybe I will need more help than usual as it is
the first release of ever.

Thanks
Enrico


Il giorno mar 28 mag 2019 alle ore 14:11 Enrico Olivelli <
eolive...@gmail.com> ha scritto:

> Hi,
> I would like to cut a release of JDeps plugin soon.
> I have committed a fix for an annoying problem with MultiRelease Jars (1)
>
> It is time to cut a first release of Maven Scripting Plugin.
>
> Thoughts ?
>
> Enrico
>
>
> [1] https://issues.apache.org/jira/browse/MJDEPS-23
>
>


Re: hocon and json formats for the Project Object Model

2019-06-10 Thread Enrico Olivelli
Hi, Hunter,
I have received your email a bit corrupted.
Did you put some ASCII art ?
Did you add attachments ?

I find your idea interesting. thank you

Enrico

Il giorno lun 10 giu 2019 alle ore 11:33 Hunter C Payne
 ha scritto:

> Hello all,   I've used Maven for probably 15 years now.  I think its great
> and want to thank you all for all your hard work.
>I've written a quick Scala library that converts pom.xml files to/from
> pom.json and pom.conf (Hocon) files.  This allows for a much less verbose
> way to specify pom files.  The code I've written should also be suitable to
> integrate into Maven proper (if you so choose) as it can construct the
> Maven bean classes that represent a POM in the Maven source base.
>
> Here is a link to that library which I call Unbound.  Hope everyone likes
> this little project and thinks it helps promote Maven.  Its not quite
> complete yet as a bit more testing and debugging is necessary before it can
> be used but I still wanted to broadcast the idea to see how everyone felt
> about it.
>
> hunterpayne/maven-unbound
>
> |
> |
> |
> |  |  |
>
>  |
>
>  |
> |
> |  |
> hunterpayne/maven-unbound
>
> Hocon and Json to Apache pom.xml. Contribute to hunterpayne/maven-unbound
> development by creating an account on ...
>  |
>
>  |
>
>  |
>
>
> thank you for your time,
> Hunter
>


Re: [VOTE] Retire Maven Downloader

2019-06-07 Thread Enrico Olivelli
+1
Enrico

Il ven 7 giu 2019, 15:37 James Gough  ha scritto:

> +1
>
> > On 7 Jun 2019, at 14:34, Tibor Digana  wrote:
> >
> > +1
> >
> > On Fri, Jun 7, 2019 at 3:32 PM Robert Scholte 
> wrote:
> >
> >> Hi,
> >>
> >> The Apache Maven project consist of about 90 (sub)projects. Due to the
> >> small number of volunteers and the huge amount of code to maintain we're
> >> missing enough space to make real progress on all these projects,
> including
> >> our ambitious ideas for the next major version(s) of Maven itself.
> >> To be able to gain more focus we need to criticize the current
> subprojects
> >> and decide if it is worth maintaining.
> >>
> >> https://maven.apache.org/shared/maven-downloader/ [
> >> https://maven.apache.org/shared/maven-downloader/] describes the main
> >> purpose in one line: Provide a super simple interface for downloading a
> >> single artifact. Well, right now the preferred library to do so is
> either
> >> maven-resolver or maven-artifact-transfer.
> >> There have been only 2 releases, the last one was in December 2006.
> >>
> >> I therefore propose that we retire the maven-downloader.
> >>
> >> I don't think it makes sense to do a final release. Instead we should
> >> update the documentation and freeze the codebase.
> >>
> >> The process for retiring a plugin is described here:
> >> https://maven.apache.org/developers/retirement-plan-plugins.html [
> >> https://maven.apache.org/developers/retirement-plan-plugins.html]
> >>
> >> The vote is open for 72 hours.
> >> [ ] +1 Yes, it's about time
> >> [ ] -1 No, because...
> >>
> >>
> >>
> >>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>


Re: proposal for maven-archetype to switch to dom4j 2.1.1 (and Java 8)

2019-06-04 Thread Enrico Olivelli
Yep
I going to merge the upgrade patch as soon as I am back from vacation

https://github.com/apache/maven-archetype/pull/28

Enrico

Il mar 4 giu 2019, 11:49 Tibor Digana  ha scritto:

> Sylwester, removing dom4j and substituting by Java XML API would be the
> best choice.
> Pls then inform the guys in
> https://github.com/apache/maven-archetype/pull/28 because I think they are
> handling it in parallel with you.
> Cheers
> Tibor
>
> On Tue, Jun 4, 2019 at 8:46 AM Sylwester Lachiewicz  >
> wrote:
>
> > Hi,
> > if dom4j is problematic I can try to remove that old dependency. We use
> it
> > internally in 2 placea (in fact almost only one simple method) - to
> manage
> >  element in pom.xml
> >
> > Sylwester
> >
> > W dniu wt., 4.06.2019 o 09:36 Homer, Tony 
> > napisał(a):
> >
> > > >>But there is one thing I do not understand why such upgrade is so
> > > important for the users even if overriding the dependency in user's POM
> > is
> > > so simple.
> > > >>Do you inherit from this project and you need dom4j as transitive
> > > dependency?
> > >
> > > I suppose you did not ask me, but I thought I'd share the background on
> > > why I proposed this change.
> > > My team maintains an eclipse product which depends on m2e which in turn
> > > depends on maven-archetype to provide dom4j.
> > > I originally proposed that m2e update to dom4j 2.1.1 [1], but because
> m2e
> > > gets dom4j from maven-archetype, Mickael asked me to instead request
> that
> > > maven-archetype update to 2.1.1.
> > > As for why I need this update, our company policy does not allow us to
> > > release software containing CVEs with CVSS v2 > 4.0.  I believe that
> the
> > > thinking is that even if the CVE is not actionable in the specific case
> > (as
> > > you suggested is the case here), some customers will refuse to use the
> > > software because retaining the CVE version shows poor security hygiene.
> > In
> > > any case, I have no control over this policy.
> > > I have been working around this issue by forking m2e and updating it to
> > > use dom4j 2.1.1 myself, but I'd like to stop doing this and use the
> > > upstream version instead.
> > > In order to achieve this, I logged the issue with m2e-core and opened a
> > PR
> > > (as mentioned above), then logged an issue with maven-archetype and
> > opened
> > > a PR (which is essentially what we are discussing here).
> > >
> > > Tony
> > >
> > > [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=547337
> > >
> > > On 6/3/19 , 2:45 PM, "Tibor Digana"  wrote:
> > >
> > >  @Mickael Istria
> > > @Eric Lilja 
> > > @Elliotte Rusty Harold
> > >
> > > We are the maintainers.
> > >
> > > But there is one thing I do not understand why such upgrade is so
> > > important
> > > for the users even if overriding the dependency in user's POM is so
> > > simple.
> > > Do you inherit from this project and you need dom4j as transitive
> > > dependency?
> > >
> > > Having a look in the CVE-2018-1000632 (
> > > https://www.cvedetails.com/cve/CVE-2018-1000632/), the root of
> > > security fix
> > > in DOM4J 2.1.1 is called "XML Injection on element and attribute".
> > The
> > > issue talks about names of element where you pass character like
> "<".
> > > Do we
> > > use such element name in this project? No! Because it is hard coded
> > > string
> > > in our code:
> > >
> > > .addElement( "modules" )
> > > .addElement( "module" )
> > >
> > > The classes of DOM4J is used in method stack and not exposed
> outside.
> > > The security fix simply throws an exception in case of using "<" in
> > > qname.
> > >
> > > The question is why the pressure is made high in maven-archetype,
> > even
> > > if
> > > we see that the base of the security fix cannot improve our life.
> > >
> > > Resources:
> > > https://www.cvedetails.com/cve/CVE-2018-1000632/
> > > https://ihacktoprotect.com/post/dom4j-xml-injection/
> > > https://github.com/dom4j/dom4j/issues/48
> > >
> > > Cheers
> > > Tibor
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > On Mon, Jun 3, 2019 at 7:47 PM Eric Lilja 
> > > wrote:
> > >
> > > > +1, people on old versions of Java can remain on the old version
> of
> > > the
> > > > plugin. No one who is in a project where an old version of Java
> is
> > > still in
> > > > use (< 8) expect to have everything else in their eco-system
> (3PPs,
> > > maven
> > > > plugins etc) at bleeding edge versions. I guess many such
> projects
> > > are many
> > > > versions behind on even supported releases...particularly
> regarding
> > > Maven
> > > > plugins.
> > > >
> > > > - Eric L
> > > >
> > > > On Mon, Jun 3, 2019 at 7:23 PM Mickael Istria <
> mist...@redhat.com>
> > > wrote:
> > > >
> > > > > People who don't want to update are the ones who have to pay
> the
> > > effort,
> > > > > not the project that tries to ship a security fix.
> > > > > 

Re: proposal for maven-archetype to switch to dom4j 2.1.1 (and Java 8)

2019-06-03 Thread Enrico Olivelli
Elliotte,

Il giorno lun 3 giu 2019 alle ore 15:59 Elliotte Rusty Harold <
elh...@ibiblio.org> ha scritto:

> Perhaps ask the dom4j developers first to see if a 2.0.3 release can
> be scheduled.
>
> And if that doesn't work, how much effort is it to switch off of dom4j
> completely?
>
> maven-archetype strikes me as too important to drop Java 7
> compatibility this soon.
>

Are you -1 with this change ?
If an user wan't to use java 7 he can use current version of the plugin.

Enrico





>
>
> On Fri, May 31, 2019 at 3:02 PM Homer, Tony  wrote:
> >
> > Currently maven-archetype depends on dom4j 1.6.1 which is vulnerable to
> CVE-2018-1000632 [1].
> > I filed ARCHETYPE-567 [2] to track this.
> > In order to mitigate this vulnerability, an update to dom4j 2.1.1 is
> needed.
> > dom4j 2.1.x requires Java 8+ [3].
> > dom4j 2.0.x would retain compatibility with Java 7 (Java 5+) but the
> latest release (2.0.2) is vulnerable to CVE-2018-1000632.
> > The current dev version (2.0.3) seems to contain a fix for
> CVE-2018-1000632 but has been pending release for ~1 year.
> >
> > I opened PR #28 [4] to make these changes.
> > What else I should do to advance this proposal?
> >
> > Thanks!
> > Tony Homer
> >
> > [1] https://nvd.nist.gov/vuln/detail/CVE-2018-1000632
> > [2] https://issues.apache.org/jira/browse/ARCHETYPE-567
> > [3] https://dom4j.github.io
> > [4] https://github.com/apache/maven-archetype/pull/28
> >
>
>
> --
> Elliotte Rusty Harold
> elh...@ibiblio.org
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>


Re: proposal for maven-archetype to switch to dom4j 2.1.1 (and Java 8)

2019-06-02 Thread Enrico Olivelli
We are working hard to get this done.

I will commit as soon as CI is green (blue...)

Enrico

Il sab 1 giu 2019, 10:02 Enrico Olivelli  ha scritto:

> If there is any complaint I will commit the change.
> We are already moving to java8 other plugins that are not part of the core
> lifecycle (Maven 3 supports java7)
>
>
> Enrico
>
> Il ven 31 mag 2019, 21:43 Enrico Olivelli  ha
> scritto:
>
>> +1
>> Enrico
>>
>> Il ven 31 mag 2019, 21:02 Homer, Tony  ha scritto:
>>
>>> Currently maven-archetype depends on dom4j 1.6.1 which is vulnerable to
>>> CVE-2018-1000632 [1].
>>> I filed ARCHETYPE-567 [2] to track this.
>>> In order to mitigate this vulnerability, an update to dom4j 2.1.1 is
>>> needed.
>>> dom4j 2.1.x requires Java 8+ [3].
>>> dom4j 2.0.x would retain compatibility with Java 7 (Java 5+) but the
>>> latest release (2.0.2) is vulnerable to CVE-2018-1000632.
>>> The current dev version (2.0.3) seems to contain a fix for
>>> CVE-2018-1000632 but has been pending release for ~1 year.
>>>
>>> I opened PR #28 [4] to make these changes.
>>> What else I should do to advance this proposal?
>>>
>>> Thanks!
>>> Tony Homer
>>>
>>> [1] https://nvd.nist.gov/vuln/detail/CVE-2018-1000632
>>> [2] https://issues.apache.org/jira/browse/ARCHETYPE-567
>>> [3] https://dom4j.github.io
>>> [4] https://github.com/apache/maven-archetype/pull/28
>>>
>>>


Re: Help with failing tests on CI

2019-06-02 Thread Enrico Olivelli
Tibor,

Il dom 2 giu 2019, 15:32 Tibor Digana  ha scritto:

> Enrico, I sent you a message regarding this question on GitHub, pls see it
> here
> https://github.com/apache/maven-archetype/pull/28#issuecomment-498030811


Thank you so much


Enrico




>
> On Sun, Jun 2, 2019 at 12:44 PM Enrico Olivelli 
> wrote:
>
> > Hi,
> > I am not able to understand why integration tests of Maven Archetype
> plugin
> > are randomly failing here:
> >
> >
> >
> https://builds.apache.org/job/maven-box/job/maven-archetype/job/ARCHETYPE-567/
> >
> > I ca't reproduce the failures.
> > Is there any way to see the logs of the integration tests ? like having a
> > ZIP of all the build.log of the integration tests ?
> >
> > Thanks in advance
> >
> > Enrico
> >
>


Help with failing tests on CI

2019-06-02 Thread Enrico Olivelli
Hi,
I am not able to understand why integration tests of Maven Archetype plugin
are randomly failing here:

https://builds.apache.org/job/maven-box/job/maven-archetype/job/ARCHETYPE-567/

I ca't reproduce the failures.
Is there any way to see the logs of the integration tests ? like having a
ZIP of all the build.log of the integration tests ?

Thanks in advance

Enrico


Re: Drop tests for java 9 and 10?

2019-06-02 Thread Enrico Olivelli
It seems to me that they are already skipped

https://gitbox.apache.org/repos/asf?p=maven-jenkins-lib.git;a=blob_plain;f=vars/asfMavenTlpPlgnBuild.groovy;hb=HEAD

But in some cases, like in the checkstyle plugin, we have a custom liat
jdks on the Jenkins file.
I am going to do the same for the maven archetype plugin

We should make it simpler to configure.
Like adding a new optional configuration entry 'minJdk' to be set inside
the Jenkinsfile.

This way we don't have to hard code the list.

I guess we will be seeing soon more and more plugins that need jdk8 as
minimum but we are keeping jdk7 as base


Enrico

Il dom 2 giu 2019, 11:47 Tibor Digana  ha scritto:

> +1 for deleting 9 1nd 10.
> yes, there's a statement by Robert "all non-EOL versions and the first EA".
> Now that includes 7 and 8 .
>
> On Sun, Jun 2, 2019 at 10:42 AM Enrico Olivelli 
> wrote:
>
> > Hi,
> > To me it is not clear if we should keep tests against java 9 and java 10.
> >
> > I think it is mostly a waste of resources and time.
> >
> > Do we have a clear and documented statement about which versions are
> > supported and tested ?
> >
> >
> > Thoughts?
> > Enrico
> >
>


Drop tests for java 9 and 10?

2019-06-02 Thread Enrico Olivelli
Hi,
To me it is not clear if we should keep tests against java 9 and java 10.

I think it is mostly a waste of resources and time.

Do we have a clear and documented statement about which versions are
supported and tested ?


Thoughts?
Enrico


Re: proposal for maven-archetype to switch to dom4j 2.1.1 (and Java 8)

2019-06-01 Thread Enrico Olivelli
If there is any complaint I will commit the change.
We are already moving to java8 other plugins that are not part of the core
lifecycle (Maven 3 supports java7)


Enrico

Il ven 31 mag 2019, 21:43 Enrico Olivelli  ha scritto:

> +1
> Enrico
>
> Il ven 31 mag 2019, 21:02 Homer, Tony  ha scritto:
>
>> Currently maven-archetype depends on dom4j 1.6.1 which is vulnerable to
>> CVE-2018-1000632 [1].
>> I filed ARCHETYPE-567 [2] to track this.
>> In order to mitigate this vulnerability, an update to dom4j 2.1.1 is
>> needed.
>> dom4j 2.1.x requires Java 8+ [3].
>> dom4j 2.0.x would retain compatibility with Java 7 (Java 5+) but the
>> latest release (2.0.2) is vulnerable to CVE-2018-1000632.
>> The current dev version (2.0.3) seems to contain a fix for
>> CVE-2018-1000632 but has been pending release for ~1 year.
>>
>> I opened PR #28 [4] to make these changes.
>> What else I should do to advance this proposal?
>>
>> Thanks!
>> Tony Homer
>>
>> [1] https://nvd.nist.gov/vuln/detail/CVE-2018-1000632
>> [2] https://issues.apache.org/jira/browse/ARCHETYPE-567
>> [3] https://dom4j.github.io
>> [4] https://github.com/apache/maven-archetype/pull/28
>>
>>


Re: proposal for maven-archetype to switch to dom4j 2.1.1 (and Java 8)

2019-05-31 Thread Enrico Olivelli
+1
Enrico

Il ven 31 mag 2019, 21:02 Homer, Tony  ha scritto:

> Currently maven-archetype depends on dom4j 1.6.1 which is vulnerable to
> CVE-2018-1000632 [1].
> I filed ARCHETYPE-567 [2] to track this.
> In order to mitigate this vulnerability, an update to dom4j 2.1.1 is
> needed.
> dom4j 2.1.x requires Java 8+ [3].
> dom4j 2.0.x would retain compatibility with Java 7 (Java 5+) but the
> latest release (2.0.2) is vulnerable to CVE-2018-1000632.
> The current dev version (2.0.3) seems to contain a fix for
> CVE-2018-1000632 but has been pending release for ~1 year.
>
> I opened PR #28 [4] to make these changes.
> What else I should do to advance this proposal?
>
> Thanks!
> Tony Homer
>
> [1] https://nvd.nist.gov/vuln/detail/CVE-2018-1000632
> [2] https://issues.apache.org/jira/browse/ARCHETYPE-567
> [3] https://dom4j.github.io
> [4] https://github.com/apache/maven-archetype/pull/28
>
>


Adding contributors to pom.xml

2019-05-28 Thread Enrico Olivelli
Hi,
Is there any rule to add a reference to a contributor in the contributors
section of the pom.xml of a plugin.

For instance today I have merged a PR from a new time contributor to the
maven jdeps plugin.
Should I add his email/reference to the pom of that plugin?

I remember that the first time I contributed to the war plugin the
committer added me to the list of contributors to the project.
It was very exciting as a first time contribution for me.


Enrico


Re: [VOTE] Retire Maven Ant Plugin

2019-05-28 Thread Enrico Olivelli
+1 ( non binding )

Enrico

Il mar 28 mag 2019, 21:43 Tibor Digana  ha scritto:

> +1
>
> On Tue, May 28, 2019 at 8:55 PM Robert Scholte 
> wrote:
>
> > Hi,
> >
> > The Apache Maven project consist of about 100 (sub)projects. Due to the
> > small number of volunteers and the huge amount of code to maintain we're
> > missing enough space to make real progress on all these projects,
> including
> > our ambitious ideas for the next major version(s) of Maven itself.
> > To be able to gain more focus we need to criticize the current
> subprojects
> > and decide if it is worth maintaining.
> >
> > The goal of the Apache Maven Ant Plugin it to generate Ant build files
> > based on a pom.xml and was released for the last time in December 2014.
> Due
> > to the different ways that Ant and Maven work I don't think it makes
> > sense anymore to maintain a plugin to transform Maven files to Ant.
> > See https://maven.apache.org/plugins/maven-ant-plugin/ [
> > https://maven.apache.org/plugins/maven-ant-plugin/]
> >
> > To be clear, this is NOT the plugin you can use to run Ant within Maven;
> > that's the maven-antrun-plugin.
> >
> > I therefore propose that we retire the maven-ant-plugin.
> >
> > I don't think it makes sense to do a final release. Instead we should
> > update the documentation and freeze the codebase.
> >
> > The process for retiring a plugin is described here:
> > https://maven.apache.org/developers/retirement-plan-plugins.html
> >
> > The vote is open for 72 hours.
> > [ ] +1 Yes, it's about time
> > [ ] -1 No, because...
>


Cutting Releases of JDeps and Scripting Plugins

2019-05-28 Thread Enrico Olivelli
Hi,
I would like to cut a release of JDeps plugin soon.
I have committed a fix for an annoying problem with MultiRelease Jars (1)

It is time to cut a first release of Maven Scripting Plugin.

Thoughts ?

Enrico


[1] https://issues.apache.org/jira/browse/MJDEPS-23


[ANN] Apache Maven Checkstyle Plugin 3.1.0 Released

2019-05-28 Thread Enrico Olivelli
The Apache Maven team is pleased to announce the release of the Apache
Maven Checkstyle Plugin, version 3.1.0

The Checkstyle Plugin generates a report regarding the code style used by
the developers. For more information about Checkstyle, see
http://checkstyle.sourceforge.net/.

This version of the plugin uses Checkstyle 8 by default, requires
Java 8 and it does not support Checkstyle 6 anymore.

https://maven.apache.org/plugins/maven-checkstyle-plugin/

You should specify the version in your project's plugin configuration:


  org.apache.maven.plugins
  maven-checkstyle-plugin
  3.1.0


You can download the appropriate sources etc. from the download page:

https://maven.apache.org/plugins/maven-checkstyle-plugin/download.cgi

Release Notes - Maven Checkstyle Plugin - Version 3.1.0

** Bug
* [MCHECKSTYLE-323] - usage of checkstyle 7.0 (jdk8 is required)
* [MCHECKSTYLE-344] - StringIndexOutOfBoundsException in RuleUtil
* [MCHECKSTYLE-347] - StringIndexOutOfBoundsException when
checkstyle.violation.ignore set to empty value
* [MCHECKSTYLE-365] - Site Report, Rules: Violation count incorrect for
duplicate rules when one uses default severity

** Improvement
* [MCHECKSTYLE-326] - Running mvn install works first time second it
does not
* [MCHECKSTYLE-350] - Lock version of animal-sniffer-maven-plugin
* [MCHECKSTYLE-353] - Don't resolve any dependencies
* [MCHECKSTYLE-374] - Replace deprecated methods in Checkstyle
* [MCHECKSTYLE-375] - Upgrade all test XML doctypes

** Dependency upgrade
* [MCHECKSTYLE-349] - Upgrade to parent pom 31
* [MCHECKSTYLE-359] - Upgrade maven-plugins parent to version 32
* [MCHECKSTYLE-360] - Upgrade maven-site-plugin to 3.7.1 for
integration tests
* [MCHECKSTYLE-366] - Upgrade checkstyle to a more recent version

Enjoy,

-The Apache Maven team


Re: Problems with checkstyle tests on Windows (Was [VOTE] Release Apache Maven Checkstyle Plugin version 3.1.0)

2019-05-27 Thread Enrico Olivelli
Il lun 27 mag 2019, 22:27 Eric Lilja  ha scritto:

> I mean that we don't need to convert any line breaks in any files in
> maven-checkstyle-plugin for the ITs to work, if we use checkstyle 8.21.
> However, we could extend the tests for "file-ends-with-newline" to
> explicitly cover all valid combinations of
> system-line-break/file-line-break. Like if my system line break is
> windows-style and the file ends with unix-style line break, the test should
> pass, and vice versa. This to let the tests actually showcase (and test,
> obviously) how the feature actually works from 8.21 onwards (look at the
> bugifx I linked previously:
> https://github.com/checkstyle/checkstyle/issues/4073)
>

This is the work, gently carried on by 2 guys from Checkstyle community.

https://github.com/apache/maven-checkstyle-plugin/pull/16

The idea is to convert a bunch of files to linux EOL. IIUC git is able to
convert EOL automatically on windows, so having a clear convention for all
of the files helps keeping an uniform way of dealing with this problem.

The integration test about MCHECKSTYLE-54 has been changed in a way that
now it is testing only the issue and not other stuff (like incidentally was
checking for EOLs due to the usage of the default checkstyle rules)

Thank you for continuing this discussion for the health of the project

Enrico




> - Eric L
>
> On Mon, May 27, 2019 at 10:17 PM Eric Lilja  wrote:
>
> > Hi Enrico! Just out of curiosity, what do you mean by " We are also
> fixing
> > EOL in the checkstyle plugin code base"? No change in the plugin is
> > required with regards to EOLs to make tests pass, simply bump to version
> > 8.21 of checkstyle itself (but there were two other errors, seemingly not
> > related to EOL characters). Cheers!
> >
> > - Eric L
> >
> > On Mon, May 27, 2019 at 8:37 PM Enrico Olivelli 
> > wrote:
> >
> >> Eric
> >> Thank you
> >>
> >> We are also fixing EOL in the checkstyle plugin code base
> >>
> >> Enrico
> >>
> >>
> >>
> >> Il lun 27 mag 2019, 11:34 Eric Lilja  ha scritto:
> >>
> >> > Just to inform you that this problem has been resolved in version 8.21
> >> of
> >> > checkstyle, which was just released, and I've confirmed the fix works
> by
> >> > running the ITs on the checkstyle-plugin (checked out master on
> Cygwin).
> >> > There are two other failures, though (was one failure with 8.20 if I
> >> recall
> >> > correctly, apart from the EOL issue still present in that version).
> >> >
> >> > https://github.com/checkstyle/checkstyle/issues/4073
> >> >
> >> > - Eric L
> >> >
> >> > On Thu, May 16, 2019 at 1:33 AM Tibor Digana 
> >> > wrote:
> >> >
> >> > > Enrico, I checked the Checkstyle rules again (default value =
> system)
> >> and
> >> > > Robert is right, please adjust the IT sources on the fly.
> >> > > Not sure why INFRA or Jenkins sets the Windows EOL to LF.
> >> > > Therefore we could not find this issue in version 3.0.0 (Jan 04)
> >> because
> >> > > the IT was created on Jan 17 and we run it on local Windows the
> first
> >> > time.
> >> > >
> >> > > The library is fine. I used several old versions of the plugin
> having
> >> > > identical results.
> >> > > Few links:
> >> > >
> >> > >
> http://checkstyle.sourceforge.net/config_misc.html#NewlineAtEndOfFile
> >> > > 
> >> > > http://checkstyle.sourceforge.net/google_style.html
> >> > >
> >> > >
> >> >
> >>
> https://github.com/checkstyle/checkstyle/blob/master/src/main/resources/sun_checks.xml
> >> > >
> >> > >
> >> >
> >>
> https://github.com/checkstyle/checkstyle/blob/master/src/main/resources/google_checks.xml
> >> > >
> >> > > I expected platform independence because my company used
> >> sun_checks.xml
> >> > on
> >> > > Windows with Unix EOL in Git/IDE without this problem.
> >> > > The company improved sun_checks.xml long time ago, so I realized
> that
> >> > later
> >> > > that it is slightly different XML and different experience. Sorry.
> >> > > Cheers
> >> > > Tibor17
> >> > >
> >> > >
> >> > > On Tue, May 14, 2019 at 2:11 PM Enrico Olivelli <
> eolive...@gmail.com

Re: Problems with checkstyle tests on Windows (Was [VOTE] Release Apache Maven Checkstyle Plugin version 3.1.0)

2019-05-27 Thread Enrico Olivelli
Eric
Thank you

We are also fixing EOL in the checkstyle plugin code base

Enrico



Il lun 27 mag 2019, 11:34 Eric Lilja  ha scritto:

> Just to inform you that this problem has been resolved in version 8.21 of
> checkstyle, which was just released, and I've confirmed the fix works by
> running the ITs on the checkstyle-plugin (checked out master on Cygwin).
> There are two other failures, though (was one failure with 8.20 if I recall
> correctly, apart from the EOL issue still present in that version).
>
> https://github.com/checkstyle/checkstyle/issues/4073
>
> - Eric L
>
> On Thu, May 16, 2019 at 1:33 AM Tibor Digana 
> wrote:
>
> > Enrico, I checked the Checkstyle rules again (default value = system) and
> > Robert is right, please adjust the IT sources on the fly.
> > Not sure why INFRA or Jenkins sets the Windows EOL to LF.
> > Therefore we could not find this issue in version 3.0.0 (Jan 04) because
> > the IT was created on Jan 17 and we run it on local Windows the first
> time.
> >
> > The library is fine. I used several old versions of the plugin having
> > identical results.
> > Few links:
> >
> > http://checkstyle.sourceforge.net/config_misc.html#NewlineAtEndOfFile
> > 
> > http://checkstyle.sourceforge.net/google_style.html
> >
> >
> https://github.com/checkstyle/checkstyle/blob/master/src/main/resources/sun_checks.xml
> >
> >
> https://github.com/checkstyle/checkstyle/blob/master/src/main/resources/google_checks.xml
> >
> > I expected platform independence because my company used sun_checks.xml
> on
> > Windows with Unix EOL in Git/IDE without this problem.
> > The company improved sun_checks.xml long time ago, so I realized that
> later
> > that it is slightly different XML and different experience. Sorry.
> > Cheers
> > Tibor17
> >
> >
> > On Tue, May 14, 2019 at 2:11 PM Enrico Olivelli 
> > wrote:
> >
> > > I will get a windows box and try to reproduce.
> > > It is weird that on ASF Jenkins the build is passing even on windows
> > >
> > > Enrico
> > >
> > > -- Forwarded message -
> > > Da: Enrico Olivelli 
> > > Date: mar 14 mag 2019, 13:58
> > > Subject: Re: [VOTE] Release Apache Maven Checkstyle Plugin version
> 3.1.0
> > > To: Maven Developers List 
> > >
> > >
> > > Eric and Tibor,
> > > Thank you so much for your effort in testing Maven Checkstyle Plugin.
> > >
> > > This is the "official" VOTE thread, here we have to decide if the
> staged
> > > artifacts are good to be released or not.
> > >
> > > Feel free to cast a -1 if you think that the staged artifacts are not
> > > "stable" or there is any showstopper problem for the release.
> > >
> > > Let's move this discussion to a separate thread, something like
> > "Validation
> > > failures in Windows over current checkstyle plugin master branch")
> > >
> > > Enrico
> > >
> > >
> > >
> > >
> > > Il giorno mar 14 mag 2019 alle ore 13:51 Eric Lilja <
> > mindcoo...@gmail.com>
> > > ha scritto:
> > >
> > > > Tried overriding line.separator when running using
> > -Dline.separator="\n",
> > > > but then the builds fails (early) in maven-plugin-plugin:
> > > > [ERROR] Failed to execute goal
> > > > org.apache.maven.plugins:maven-plugin-plugin:3.5:descriptor
> > > > (default-descriptor) on project maven-checkstyle-plugin: Execution
> > > > default-descriptor of goal
> > > > org.apache.maven.plugins:maven-plugin-plugin:3.5:descriptor failed:
> > > > Requested line separator is invalid. -> [Help 1]
> > > > [ERROR]
> > > > [ERROR] To see the full stack trace of the errors, re-run Maven with
> > the
> > > -e
> > > > switch.
> > > > [ERROR] Re-run Maven using the -X switch to enable full debug
> logging.
> > > > [ERROR]
> > > > [ERROR] For more information about the errors and possible solutions,
> > > > please read the following articles:
> > > > [ERROR] [Help 1]
> > > >
> > >
> >
> http://cwiki.apache.org/confluence/display/MAVEN/PluginExecutionException
> > > >
> > > > Tried upgrading maven-plugin-plugin to 3.6.0 (lots of stuff
> > > > upgradeable...), but same error
> > > >
> > > > I also happened to notice this (probably unrelated, but wanted to
>

New checkstyle website isn't published

2019-05-25 Thread Enrico Olivelli
Hi,
I did not sent the ANNOUNCE email about checkstyle plugin because the
website is not updated.

On svn the website looks good, see [1], it is at version 3.1.0 (look on the
top right of the page)
But the web site [2] is not updated

The download page is out of sync [3]

What's wrong ?

Thanks
Enrico

[1]
https://svn.apache.org/repos/asf/maven/website/components/plugins/maven-checkstyle-plugin/index.html
[2] https://maven.apache.org/plugins/maven-checkstyle-plugin/
[3] https://maven.apache.org/plugins/maven-checkstyle-plugin/download.cgi


[RESULT] [VOTE] Release Apache Maven Checkstyle Plugin version 3.1.0

2019-05-20 Thread Enrico Olivelli
- Hi,
-
- The vote has passed with the following result:
-
- +1 :  Tibor Digana, Sylwester Lachiewicz, Hervé Boutemy, Karl Heinz Marbaise
-
- PMC quorum: reached
-
- I will promote the artifacts to the central repo.


Enrico

Il giorno dom 19 mag 2019 alle ore 11:44 Sylwester Lachiewicz <
slachiew...@gmail.com> ha scritto:

> +1
> Sylwester
>
> W dniu niedz., 19.05.2019 o 11:09 Hervé BOUTEMY 
> napisał(a):
>
> > +1
> >
> > Regards,
> >
> > Hervé
> >
> > Le lundi 13 mai 2019, 11:52:30 CEST Enrico Olivelli a écrit :
> > > Hi,
> > >
> > > We solved 13 issues:
> > >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12342397
> > > eName=Text=12317223
> > >
> > > Please note that this version now only supports CheckStyle 8+ and Java
> 8
> > > (as required by latest Checkstyle)
> > >
> > > There are still a couple of issues left in JIRA:
> > >
> >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20XX%20AND%
> > > 20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC
> > >
> > > Staging repo:
> > > https://repository.apache.org/content/repositories/maven-1503/
> > >
> >
> https://repository.apache.org/content/repositories/maven-1503/org/apache/mav
> > >
> >
> en/plugins/maven-checkstyle-plugin/3.1.0/maven-checkstyle-plugin-3.1.0-sourc
> > > e-release.zip
> > >
> > > Source release checksum(s):
> > > maven-checkstyle-plugin-3.1.0-source-release.zip sha512:
> > >
> >
> eca46edb4d2f6cf2e250169ce5d5e510781b4bba116cc7b5655797cdb109ccdb0da883a17613
> > > 47c6e2c77fe58395aff17e45c46d85a8a823340ae2b11c92852e
> > >
> > > Staging site:
> > >
> >
> https://maven.apache.org/plugins-archives/maven-checkstyle-plugin-LATEST/
> > >
> > > Guide to testing staged releases:
> > >
> https://maven.apache.org/guides/development/guide-testing-releases.html
> > >
> > > Vote open for at least 72 hours.
> > >
> > > [ ] +1
> > > [ ] +0
> > > [ ] -1
> > >
> > >
> > > Enrico Olivelli
> >
> >
> >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>


Re: Maven-enforcer-plugin dependency convergence verbose logs

2019-05-18 Thread Enrico Olivelli
Hi Jon,
I think that if this idea can help you it is worth to work on it.
Can you create a JIRA with your case ?
It would be great if you can also try to send a pull request with a
proposal,
We will be happy to see your code and eventually merge it.

Cheers
Enrico

Il sab 18 mag 2019, 06:48 Jon Harper  ha scritto:

> Hi list,
> using maven-enforcer-plugin dependency converge rule, the logs of the
> trees of the conflicting dependencies represent 7000 lines out of the
> 12000 lines of logs of my build.
>
> Would it be possible to allow configuring the verbosity of the plugin
> ? Either with an explicit configuration flag, or by using more fine
> grained loggers so that the user can configure them using slf4j ?
>
> A simple change would be to change the log of the trees to the INFO so
> that users can configure
> org.slf4j.simpleLogger.log.org.apache.maven.plugins.enforcer to WARN
> (either on the command line, or in .mvn/jvm.config or in
> $MAVEN_HOME/conf/logging/simplelogger.properties  )
>
> For example on this example log, removing the trees would still leave
> useful logs but remove a lot of noise.
>
> >> [WARNING]
> >> Dependency convergence error for
> org.openrdf.sesame:sesame-rio-api:2.7.12 paths to dependency are:
> >> +-com.blazegraph:bigdata-core:2.1.4
> >>   +-org.openrdf.sesame:sesame-runtime:2.7.12
> >> +-org.openrdf.sesame:sesame-repository-api:2.7.12
> >>   +-org.openrdf.sesame:sesame-rio-api:2.7.12
> >> and
> >> +-com.powsybl:powsybl-distribution-core:3.0.0-SNAPSHOT
> >>   +-com.powsybl:powsybl-triple-store-impl-blazegraph:3.0.0-SNAPSHOT
> >> [..snip 200 lines of trees..]
> >>
> >> [WARNING] Rule 0:
> org.apache.maven.plugins.enforcer.DependencyConvergence failed with message:
> >> Failed while enforcing releasability. See above detailed error message.
>
> What do you think ?
>
> Cheers,
> Jon
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>


Re: Open pull requests

2019-05-15 Thread Enrico Olivelli
Thank you Joseph,
If you have time you can help us review the pending pulls and see if they
are still useful and/or suggest changes before merge.
Every eye on patches is very valuable and it helps commiters of the project
in their work.

Enrico

Il mer 15 mag 2019, 19:08 Robert Scholte  ha scritto:

> Hi Joseph,
>
> great to hear you want to contribute, we appreciate that a lot!
> But you mind have noticed there are a huge amount of open issues and pull
> request and we simple can not catch up due to the limited amount of time
> and volunteers.
>
> Regarding the open PRs, I expect that most were created in a period where
> Maven itself was still on subversion, but the Apache Software Foundation
> provided read-only copies at Github.
> The integration between both systems was bad, we didn't get notifications
> and trying to patch it back to subversion was a nightmare.
> Things are better nowadays, but we still suffer from that period.
>
> My main activity is currently reading and writing daily e-mails and trying
> to get and keep everything stable.So development is not even in the top 3
> activities.
> Going through older PRs is something that should be done, but I'm afraid
> it is not getting the highest priority.
>
> Don't let this be a message to stop contributing, just be aware that it
> requires some patience.
>
> thanks,
> Robert
>
>
> On 14-5-2019 06:21:17, Joseph Walton  wrote:
> - To
> unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional
> commands, e-mail: dev-h...@maven.apache.org
> As an interested contributor, I've opened a couple of pull requests, and
> it's not always clear what the next step is for a non-project-member to get
> things merged.
>
> To see how other PRs (https://github.com/apache/maven/pulls [
> https://github.com/apache/maven/pulls] -- currently, '32 open') are being
> handled, I thought it might make sense to chart them; chart attached.
>
> Notable:
> * a significant number were opened more than a year ago (as far back as
> 2014), haven't been merged and now have conflicts. Could they be closed?
>
> * some more recent ones are mergeable, and approved. Can these be merged?
> * for the other PRs in between -- do they need work, or would closing them
> send a clearer message?
>
> Thanks.
>


Re: Problems with checkstyle tests on Windows (Was [VOTE] Release Apache Maven Checkstyle Plugin version 3.1.0)

2019-05-15 Thread Enrico Olivelli
Il mer 15 mag 2019, 17:44 Tibor Digana  ha scritto:

> @Enrico did you announce the Checkstyle team about our issue [1]?
> What is going on with that?
> [1]: https://issues.apache.org/jira/browse/MCHECKSTYLE-376
> Thx
> Tibor17
>


Not yet sorry. I have been busy today. Will do this evening


Enrico



>
> On Tue, May 14, 2019 at 2:11 PM Enrico Olivelli 
> wrote:
>
> > I will get a windows box and try to reproduce.
> > It is weird that on ASF Jenkins the build is passing even on windows
> >
> > Enrico
> >
> > -- Forwarded message -
> > Da: Enrico Olivelli 
> > Date: mar 14 mag 2019, 13:58
> > Subject: Re: [VOTE] Release Apache Maven Checkstyle Plugin version 3.1.0
> > To: Maven Developers List 
> >
> >
> > Eric and Tibor,
> > Thank you so much for your effort in testing Maven Checkstyle Plugin.
> >
> > This is the "official" VOTE thread, here we have to decide if the staged
> > artifacts are good to be released or not.
> >
> > Feel free to cast a -1 if you think that the staged artifacts are not
> > "stable" or there is any showstopper problem for the release.
> >
> > Let's move this discussion to a separate thread, something like
> "Validation
> > failures in Windows over current checkstyle plugin master branch")
> >
> > Enrico
> >
> >
> >
> >
> > Il giorno mar 14 mag 2019 alle ore 13:51 Eric Lilja <
> mindcoo...@gmail.com>
> > ha scritto:
> >
> > > Tried overriding line.separator when running using
> -Dline.separator="\n",
> > > but then the builds fails (early) in maven-plugin-plugin:
> > > [ERROR] Failed to execute goal
> > > org.apache.maven.plugins:maven-plugin-plugin:3.5:descriptor
> > > (default-descriptor) on project maven-checkstyle-plugin: Execution
> > > default-descriptor of goal
> > > org.apache.maven.plugins:maven-plugin-plugin:3.5:descriptor failed:
> > > Requested line separator is invalid. -> [Help 1]
> > > [ERROR]
> > > [ERROR] To see the full stack trace of the errors, re-run Maven with
> the
> > -e
> > > switch.
> > > [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> > > [ERROR]
> > > [ERROR] For more information about the errors and possible solutions,
> > > please read the following articles:
> > > [ERROR] [Help 1]
> > >
> >
> http://cwiki.apache.org/confluence/display/MAVEN/PluginExecutionException
> > >
> > > Tried upgrading maven-plugin-plugin to 3.6.0 (lots of stuff
> > > upgradeable...), but same error
> > >
> > > I also happened to notice this (probably unrelated, but wanted to bring
> > it
> > > to attention anyway so it can be fixed) warning:
> > > [INFO] java-annotations mojo extractor found 4 mojo descriptors.
> > > [WARNING]
> > >
> > > Unexpected situation: destinationDirectory not defined in
> > > maven-plugin-help.properties during help mojo source generation but
> > > expected during XML descriptor generation.
> > > [WARNING] Please check helpmojo goal version used in previous build
> > phase.
> > > [WARNING] If you just upgraded to plugin-tools >= 3.2 you must run a
> > clean
> > > build at least once.
> > > [WARNING] Trying default location: target\generated-sources\plugin
> > >
> > > - Eric L
> > >
> > > On Tue, May 14, 2019 at 11:04 AM Eric Lilja 
> > wrote:
> > >
> > > > I tried bumping checkstyle to 8.20, plus a few of the plexus
> > > dependencies,
> > > > but that just brought an additional failure... (to
> > > > MCHECKSTYLE-70-multi-sourcefolder\pom.xml)  :-)
> > > >
> > > > I suppose the problem might be that the files has linux-style line
> > breaks
> > > > (this is desired for me, I don't want to convert to windows-style
> line
> > > > breaks locally), but the test think I should have windows-style line
> > > > separators. It seems these files are generated by the tests because I
> > > tried
> > > > changing them to Windows style line breaks for re-running just to see
> > if
> > > > that would work, but those changes were overwritten)
> > > >
> > > > - Eric L
> > > >
> > > > On Tue, May 14, 2019 at 10:38 AM Eric Lilja 
> > > wrote:
> > > >
> > > >> I also see a failure for MCHECKSTYLE-54 on Windows. (Sorry, I didn't
> &g

Re: Maven-enforcer-plugin's use of aether-util in transitive dependency

2019-05-15 Thread Enrico Olivelli
Thanks Tomo for the heads up.
I will move the patch forward.


Enrico

Il giorno mar 14 mag 2019 alle ore 22:08 Tomo Suzuki
 ha scritto:

> Hi Enrico,
>
> The PR https://github.com/apache/maven-enforcer/pull/52  has been approved
> (Thanks!) but not merged yet.
> Is this something you can take care of, or should I take any action?
>
> Regards,
> Tomo
>
> *From: *Tomo Suzuki 
> *Date: *Mon, Mar 18, 2019 at 12:15 AM
> *To: *Maven Developers List
>
> Enrico,
> >
> > Created the PR. https://github.com/apache/maven-enforcer/pull/52
> >
> > Regards,
> > Tomo
> >
> >
> > On Sun, Mar 17, 2019 at 5:17 PM Enrico Olivelli 
> > wrote:
> >
> >> Awesome
> >> Let's see the PR
> >>
> >> Thanks
> >> Enrico
> >>
> >> Il mer 13 mar 2019, 22:19 Tomo Suzuki  ha
> >> scritto:
> >>
> >> > Hi Maven developers,
> >> > (following "Contributing" section of maven-enforcer-plugin
> >> > <https://github.com/apache/maven-enforcer#contributing>)
> >> >
> >> > I'm thinking to raise a PR to fix an issue below, so that
> >> > maven-enforcer-plugin can work with maven-resolver-util without
> explicit
> >> > "exclusion" element. Let me know what you think!
> >> >
> >> > While writing a custom enforcer rule, I encountered NoSuchMethodError
> >> > org.eclipse.aether.util.ConfigUtils.getFloat. I believe it is caused
> by
> >> > transitive dependency in org.eclipse.aether:aether-util. The class is
> >> also
> >> > in org.apache.maven.resolver:maven-resolver-util:1.3.1. A workaround
> >> with
> >> > exclusion element
> >> > <
> >> >
> >>
> https://github.com/GoogleCloudPlatform/cloud-opensource-java/blob/master/enforcer-rules/pom.xml#L64
> >> > >
> >> > just worked fine for me but I'd like to contribute to fix the root
> >> cause if
> >> > possible.
> >> >
> >> > --
> >> > Regards,
> >> > Tomo
> >> >
> >>
> >
> >
> > --
> > Regards,
> > Tomo
> >
>
>
> --
> Regards,
> Tomo
>


Re: Problems with checkstyle tests on Windows (Was [VOTE] Release Apache Maven Checkstyle Plugin version 3.1.0)

2019-05-14 Thread Enrico Olivelli
Thanks
I am able to reproduce the issue on a Windows box.
Still I can't understand why we aren't seeing problems on CI.

Eric,
do you have cycles to create a JIRA and send a Pull request ?
We can fix it in master.
As Tibor said, I think this is not a blocker for the 3.1.0 release.

Otherwise I will fix it when I have time, but not today


Thank you very much for reporting
Enrico



Il giorno mar 14 mag 2019 alle ore 16:24 Enrico Olivelli <
eolive...@gmail.com> ha scritto:

>
>
> Il giorno mar 14 mag 2019 alle ore 14:34 Tibor Digana <
> tibordig...@apache.org> ha scritto:
>
>> Two files in one IT are problematic but I don't think it is a problem for
>> your release.
>> The  CPD should be fixed and a method should be reused but again it is not
>> a reason to interrupt the vote.
>>
>> One more question. Why did you "git push" the history from Maven Release
>> plugin?
>> This should be done after the vote because yet you do not know the vote
>> result.
>>
>
> Please explain better.
> I apologize if I did a mistake, but I can't understand your concern.
>
> I have used these commands:
> mvn release:clean
> mvn release:prepare
> mvn release:perform
> "Closed" the  staged repository
>
> current master is 3.1.1-SNAPSHOT
> https://github.com/apache/maven-checkstyle-plugin
>
> tag is at: 3.1.0
>
> https://github.com/apache/maven-checkstyle-plugin/tree/maven-checkstyle-plugin-3.1.0
>
>
>
>
>
> Enrico
>
>
>
>>
>> Cheers
>> Tibor
>>
>> On Tue, May 14, 2019 at 2:11 PM Enrico Olivelli 
>> wrote:
>>
>> > I will get a windows box and try to reproduce.
>> > It is weird that on ASF Jenkins the build is passing even on windows
>> >
>> > Enrico
>> >
>> > -- Forwarded message -
>> > Da: Enrico Olivelli 
>> > Date: mar 14 mag 2019, 13:58
>> > Subject: Re: [VOTE] Release Apache Maven Checkstyle Plugin version 3.1.0
>> > To: Maven Developers List 
>> >
>> >
>> > Eric and Tibor,
>> > Thank you so much for your effort in testing Maven Checkstyle Plugin.
>> >
>> > This is the "official" VOTE thread, here we have to decide if the staged
>> > artifacts are good to be released or not.
>> >
>> > Feel free to cast a -1 if you think that the staged artifacts are not
>> > "stable" or there is any showstopper problem for the release.
>> >
>> > Let's move this discussion to a separate thread, something like
>> "Validation
>> > failures in Windows over current checkstyle plugin master branch")
>> >
>> > Enrico
>> >
>> >
>> >
>> >
>> > Il giorno mar 14 mag 2019 alle ore 13:51 Eric Lilja <
>> mindcoo...@gmail.com>
>> > ha scritto:
>> >
>> > > Tried overriding line.separator when running using
>> -Dline.separator="\n",
>> > > but then the builds fails (early) in maven-plugin-plugin:
>> > > [ERROR] Failed to execute goal
>> > > org.apache.maven.plugins:maven-plugin-plugin:3.5:descriptor
>> > > (default-descriptor) on project maven-checkstyle-plugin: Execution
>> > > default-descriptor of goal
>> > > org.apache.maven.plugins:maven-plugin-plugin:3.5:descriptor failed:
>> > > Requested line separator is invalid. -> [Help 1]
>> > > [ERROR]
>> > > [ERROR] To see the full stack trace of the errors, re-run Maven with
>> the
>> > -e
>> > > switch.
>> > > [ERROR] Re-run Maven using the -X switch to enable full debug logging.
>> > > [ERROR]
>> > > [ERROR] For more information about the errors and possible solutions,
>> > > please read the following articles:
>> > > [ERROR] [Help 1]
>> > >
>> >
>> http://cwiki.apache.org/confluence/display/MAVEN/PluginExecutionException
>> > >
>> > > Tried upgrading maven-plugin-plugin to 3.6.0 (lots of stuff
>> > > upgradeable...), but same error
>> > >
>> > > I also happened to notice this (probably unrelated, but wanted to
>> bring
>> > it
>> > > to attention anyway so it can be fixed) warning:
>> > > [INFO] java-annotations mojo extractor found 4 mojo descriptors.
>> > > [WARNING]
>> > >
>> > > Unexpected situation: destinationDirectory not defined in
>> > > maven-plugin-help.properties during help mojo source generation but
>> > > expected

Re: Problems with checkstyle tests on Windows (Was [VOTE] Release Apache Maven Checkstyle Plugin version 3.1.0)

2019-05-14 Thread Enrico Olivelli
Il giorno mar 14 mag 2019 alle ore 14:34 Tibor Digana <
tibordig...@apache.org> ha scritto:

> Two files in one IT are problematic but I don't think it is a problem for
> your release.
> The  CPD should be fixed and a method should be reused but again it is not
> a reason to interrupt the vote.
>
> One more question. Why did you "git push" the history from Maven Release
> plugin?
> This should be done after the vote because yet you do not know the vote
> result.
>

Please explain better.
I apologize if I did a mistake, but I can't understand your concern.

I have used these commands:
mvn release:clean
mvn release:prepare
mvn release:perform
"Closed" the  staged repository

current master is 3.1.1-SNAPSHOT
https://github.com/apache/maven-checkstyle-plugin

tag is at: 3.1.0
https://github.com/apache/maven-checkstyle-plugin/tree/maven-checkstyle-plugin-3.1.0





Enrico



>
> Cheers
> Tibor
>
> On Tue, May 14, 2019 at 2:11 PM Enrico Olivelli 
> wrote:
>
> > I will get a windows box and try to reproduce.
> > It is weird that on ASF Jenkins the build is passing even on windows
> >
> > Enrico
> >
> > -- Forwarded message -
> > Da: Enrico Olivelli 
> > Date: mar 14 mag 2019, 13:58
> > Subject: Re: [VOTE] Release Apache Maven Checkstyle Plugin version 3.1.0
> > To: Maven Developers List 
> >
> >
> > Eric and Tibor,
> > Thank you so much for your effort in testing Maven Checkstyle Plugin.
> >
> > This is the "official" VOTE thread, here we have to decide if the staged
> > artifacts are good to be released or not.
> >
> > Feel free to cast a -1 if you think that the staged artifacts are not
> > "stable" or there is any showstopper problem for the release.
> >
> > Let's move this discussion to a separate thread, something like
> "Validation
> > failures in Windows over current checkstyle plugin master branch")
> >
> > Enrico
> >
> >
> >
> >
> > Il giorno mar 14 mag 2019 alle ore 13:51 Eric Lilja <
> mindcoo...@gmail.com>
> > ha scritto:
> >
> > > Tried overriding line.separator when running using
> -Dline.separator="\n",
> > > but then the builds fails (early) in maven-plugin-plugin:
> > > [ERROR] Failed to execute goal
> > > org.apache.maven.plugins:maven-plugin-plugin:3.5:descriptor
> > > (default-descriptor) on project maven-checkstyle-plugin: Execution
> > > default-descriptor of goal
> > > org.apache.maven.plugins:maven-plugin-plugin:3.5:descriptor failed:
> > > Requested line separator is invalid. -> [Help 1]
> > > [ERROR]
> > > [ERROR] To see the full stack trace of the errors, re-run Maven with
> the
> > -e
> > > switch.
> > > [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> > > [ERROR]
> > > [ERROR] For more information about the errors and possible solutions,
> > > please read the following articles:
> > > [ERROR] [Help 1]
> > >
> >
> http://cwiki.apache.org/confluence/display/MAVEN/PluginExecutionException
> > >
> > > Tried upgrading maven-plugin-plugin to 3.6.0 (lots of stuff
> > > upgradeable...), but same error
> > >
> > > I also happened to notice this (probably unrelated, but wanted to bring
> > it
> > > to attention anyway so it can be fixed) warning:
> > > [INFO] java-annotations mojo extractor found 4 mojo descriptors.
> > > [WARNING]
> > >
> > > Unexpected situation: destinationDirectory not defined in
> > > maven-plugin-help.properties during help mojo source generation but
> > > expected during XML descriptor generation.
> > > [WARNING] Please check helpmojo goal version used in previous build
> > phase.
> > > [WARNING] If you just upgraded to plugin-tools >= 3.2 you must run a
> > clean
> > > build at least once.
> > > [WARNING] Trying default location: target\generated-sources\plugin
> > >
> > > - Eric L
> > >
> > > On Tue, May 14, 2019 at 11:04 AM Eric Lilja 
> > wrote:
> > >
> > > > I tried bumping checkstyle to 8.20, plus a few of the plexus
> > > dependencies,
> > > > but that just brought an additional failure... (to
> > > > MCHECKSTYLE-70-multi-sourcefolder\pom.xml)  :-)
> > > >
> > > > I suppose the problem might be that the files has linux-style line
> > breaks
> > > > (this is desired for me, I don't want to convert to windows-style
> line
> > >

Problems with checkstyle tests on Windows (Was [VOTE] Release Apache Maven Checkstyle Plugin version 3.1.0)

2019-05-14 Thread Enrico Olivelli
I will get a windows box and try to reproduce.
It is weird that on ASF Jenkins the build is passing even on windows

Enrico

-- Forwarded message -
Da: Enrico Olivelli 
Date: mar 14 mag 2019, 13:58
Subject: Re: [VOTE] Release Apache Maven Checkstyle Plugin version 3.1.0
To: Maven Developers List 


Eric and Tibor,
Thank you so much for your effort in testing Maven Checkstyle Plugin.

This is the "official" VOTE thread, here we have to decide if the staged
artifacts are good to be released or not.

Feel free to cast a -1 if you think that the staged artifacts are not
"stable" or there is any showstopper problem for the release.

Let's move this discussion to a separate thread, something like "Validation
failures in Windows over current checkstyle plugin master branch")

Enrico




Il giorno mar 14 mag 2019 alle ore 13:51 Eric Lilja 
ha scritto:

> Tried overriding line.separator when running using -Dline.separator="\n",
> but then the builds fails (early) in maven-plugin-plugin:
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-plugin-plugin:3.5:descriptor
> (default-descriptor) on project maven-checkstyle-plugin: Execution
> default-descriptor of goal
> org.apache.maven.plugins:maven-plugin-plugin:3.5:descriptor failed:
> Requested line separator is invalid. -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions,
> please read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/PluginExecutionException
>
> Tried upgrading maven-plugin-plugin to 3.6.0 (lots of stuff
> upgradeable...), but same error
>
> I also happened to notice this (probably unrelated, but wanted to bring it
> to attention anyway so it can be fixed) warning:
> [INFO] java-annotations mojo extractor found 4 mojo descriptors.
> [WARNING]
>
> Unexpected situation: destinationDirectory not defined in
> maven-plugin-help.properties during help mojo source generation but
> expected during XML descriptor generation.
> [WARNING] Please check helpmojo goal version used in previous build phase.
> [WARNING] If you just upgraded to plugin-tools >= 3.2 you must run a clean
> build at least once.
> [WARNING] Trying default location: target\generated-sources\plugin
>
> - Eric L
>
> On Tue, May 14, 2019 at 11:04 AM Eric Lilja  wrote:
>
> > I tried bumping checkstyle to 8.20, plus a few of the plexus
> dependencies,
> > but that just brought an additional failure... (to
> > MCHECKSTYLE-70-multi-sourcefolder\pom.xml)  :-)
> >
> > I suppose the problem might be that the files has linux-style line breaks
> > (this is desired for me, I don't want to convert to windows-style line
> > breaks locally), but the test think I should have windows-style line
> > separators. It seems these files are generated by the tests because I
> tried
> > changing them to Windows style line breaks for re-running just to see if
> > that would work, but those changes were overwritten)
> >
> > - Eric L
> >
> > On Tue, May 14, 2019 at 10:38 AM Eric Lilja 
> wrote:
> >
> >> I also see a failure for MCHECKSTYLE-54 on Windows. (Sorry, I didn't try
> >> the source zip, just cloned master)
> >>
> >> I tested on one of our corporate laptops:
> >> Windows 10
> >> Cygwin 64-bit (I use it to clone the repo and use Maven)
> >> Maven 3.6.0
> >> Java 8 update 202
> >>
> >> The build log says:
> >> [INFO] There are 2 errors reported by Checkstyle 8.19 with
> sun_checks.xml
> >> ruleset.
> >> [ERROR]
> >>
> src\main\java\org\apache\maven\plugins\checkstyle\mcheckstyle54\Mcheckstyle54.java:[1]
> >> (misc) NewlineAtEndOfFile: File does not end with a newline.
> >> [ERROR]
> >>
> src\main\java\org\apache\maven\plugins\checkstyle\mcheckstyle54\package-info.java:[1]
> >> (misc) NewlineAtEndOfFile: File does not end with a newline.
> >>
> >> These two files end with unix-style line breaks (as expected with my
> >> setup).
> >>
> >> - Eric L
> >>
> >>
> >> On Tue, May 14, 2019 at 8:10 AM Enrico Olivelli 
> >> wrote:
> >>
> >>> Il lun 13 mag 2019, 23:48 Tibor Digana  ha
> >>> scritto:
> >>>
> >>> > Robert, I did *not* use the source zip.
> >>> >
> >>>
> >>> IMHO we should vote on the staged zip
> >>>
> >>>

Re: [VOTE] Release Apache Maven Checkstyle Plugin version 3.1.0

2019-05-14 Thread Enrico Olivelli
Eric and Tibor,
Thank you so much for your effort in testing Maven Checkstyle Plugin.

This is the "official" VOTE thread, here we have to decide if the staged
artifacts are good to be released or not.

Feel free to cast a -1 if you think that the staged artifacts are not
"stable" or there is any showstopper problem for the release.

Let's move this discussion to a separate thread, something like "Validation
failures in Windows over current checkstyle plugin master branch")

Enrico




Il giorno mar 14 mag 2019 alle ore 13:51 Eric Lilja 
ha scritto:

> Tried overriding line.separator when running using -Dline.separator="\n",
> but then the builds fails (early) in maven-plugin-plugin:
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-plugin-plugin:3.5:descriptor
> (default-descriptor) on project maven-checkstyle-plugin: Execution
> default-descriptor of goal
> org.apache.maven.plugins:maven-plugin-plugin:3.5:descriptor failed:
> Requested line separator is invalid. -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions,
> please read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/PluginExecutionException
>
> Tried upgrading maven-plugin-plugin to 3.6.0 (lots of stuff
> upgradeable...), but same error
>
> I also happened to notice this (probably unrelated, but wanted to bring it
> to attention anyway so it can be fixed) warning:
> [INFO] java-annotations mojo extractor found 4 mojo descriptors.
> [WARNING]
>
> Unexpected situation: destinationDirectory not defined in
> maven-plugin-help.properties during help mojo source generation but
> expected during XML descriptor generation.
> [WARNING] Please check helpmojo goal version used in previous build phase.
> [WARNING] If you just upgraded to plugin-tools >= 3.2 you must run a clean
> build at least once.
> [WARNING] Trying default location: target\generated-sources\plugin
>
> - Eric L
>
> On Tue, May 14, 2019 at 11:04 AM Eric Lilja  wrote:
>
> > I tried bumping checkstyle to 8.20, plus a few of the plexus
> dependencies,
> > but that just brought an additional failure... (to
> > MCHECKSTYLE-70-multi-sourcefolder\pom.xml)  :-)
> >
> > I suppose the problem might be that the files has linux-style line breaks
> > (this is desired for me, I don't want to convert to windows-style line
> > breaks locally), but the test think I should have windows-style line
> > separators. It seems these files are generated by the tests because I
> tried
> > changing them to Windows style line breaks for re-running just to see if
> > that would work, but those changes were overwritten)
> >
> > - Eric L
> >
> > On Tue, May 14, 2019 at 10:38 AM Eric Lilja 
> wrote:
> >
> >> I also see a failure for MCHECKSTYLE-54 on Windows. (Sorry, I didn't try
> >> the source zip, just cloned master)
> >>
> >> I tested on one of our corporate laptops:
> >> Windows 10
> >> Cygwin 64-bit (I use it to clone the repo and use Maven)
> >> Maven 3.6.0
> >> Java 8 update 202
> >>
> >> The build log says:
> >> [INFO] There are 2 errors reported by Checkstyle 8.19 with
> sun_checks.xml
> >> ruleset.
> >> [ERROR]
> >>
> src\main\java\org\apache\maven\plugins\checkstyle\mcheckstyle54\Mcheckstyle54.java:[1]
> >> (misc) NewlineAtEndOfFile: File does not end with a newline.
> >> [ERROR]
> >>
> src\main\java\org\apache\maven\plugins\checkstyle\mcheckstyle54\package-info.java:[1]
> >> (misc) NewlineAtEndOfFile: File does not end with a newline.
> >>
> >> These two files end with unix-style line breaks (as expected with my
> >> setup).
> >>
> >> - Eric L
> >>
> >>
> >> On Tue, May 14, 2019 at 8:10 AM Enrico Olivelli 
> >> wrote:
> >>
> >>> Il lun 13 mag 2019, 23:48 Tibor Digana  ha
> >>> scritto:
> >>>
> >>> > Robert, I did *not* use the source zip.
> >>> >
> >>>
> >>> IMHO we should vote on the staged zip
> >>>
> >>>
> >>> > git clone
> https://gitbox.apache.org/repos/asf/maven-checkstyle-plugin
> >>> > Oracle jdk 1.8.0u212, Maven 3.3.9, Windows 10
> >>> >
> >>>
> >>> This is what CI does and tests are passing.
> >>>
> >>&

Re: [VOTE] Release Apache Maven Checkstyle Plugin version 3.1.0

2019-05-14 Thread Enrico Olivelli
Il lun 13 mag 2019, 23:48 Tibor Digana  ha scritto:

> Robert, I did *not* use the source zip.
>

IMHO we should vote on the staged zip


> git clone https://gitbox.apache.org/repos/asf/maven-checkstyle-plugin
> Oracle jdk 1.8.0u212, Maven 3.3.9, Windows 10
>

This is what CI does and tests are passing.

Do you have some global git configuration?

Enrico

>
> I see there is a new line, but the checkstyle does not care if you put one
> or two lines.
> No idea why.
>
> Even if you go to the target and run it from the folder
> c:\vcs\github\maven-checkstyle-plugin\target\it\MCHECKSTYLE-54\
> it's the same as if you run the project root - mvn verify -P
> run-its,quality-checks
>
>
> *mvn -nsu checkstyle:check*
>
> [INFO] --- maven-checkstyle-plugin:3.1.1-SNAPSHOT:check (default-cli) @
> mcheckstyle-54 ---
> [INFO] There are 2 errors reported by Checkstyle 8.19 with sun_checks.xml
> ruleset.
> [ERROR]
>
> src\main\java\org\apache\maven\plugins\checkstyle\mcheckstyle54\Mcheckstyle54.java:[1]
> (misc) NewlineAtEndOfFile: File does not end with a newline.
> [ERROR]
>
> src\main\java\org\apache\maven\plugins\checkstyle\mcheckstyle54\package-info.java:[1]
> (misc) NewlineAtEndOfFile: File does not end with a newline.
> [INFO]
> 
> [INFO] BUILD FAILURE
> [INFO]
> 
> [INFO] Total time: 3.450 s
> [INFO] Finished at: 2019-05-13T23:42:55+02:00
> [INFO] Final Memory: 12M/193M
> [INFO]
> 
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-checkstyle-plugin:3.1.1-SNAPSHOT:check
> (default-cli) on project mcheckstyle-54: You have 2 Checkstyle violations.
> -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions,
> please read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
>
>
> On Mon, May 13, 2019 at 10:29 PM Robert Scholte 
> wrote:
>
> > This can happen when source-release.zip was created on a different OS
> > compared to the verifying OS.
> >
> > With Git it will switch to the line endings of the operating system, but
> > with a zip that's not possible.
> >
> > I'd say not blocking, but the IT needs to be fixed to handle these
> > situations.
> >
> > Robert
> >
> >
> > On Mon, 13 May 2019 21:55:27 +0200, Enrico Olivelli  >
> >
> > wrote:
> >
> > > Tibor
> > > It is strage all its are passing on CI.
> > > Are you sure you have correcly unpacked the package?
> > >
> > >
> > > Il lun 13 mag 2019, 21:23 Tibor Digana  ha
> > > scritto:
> > >
> > >> checked the sha512 of src zip, ok
> > >> checked the build, failed (mvn verify -P run-its,quality-checks)
> > >>
> > >
> > > What is 'quality-checks' profile? I have never heard about it
> > >
> > > Enrico
> > >
> > >
> > >> [INFO] Building: MCHECKSTYLE-54\pom.xml
> > >> [INFO]   MCHECKSTYLE-54\pom.xml ...
> > >> FAILED
> > >> (5.3 s)
> > >>
> > >> *Mcheckstyle54.java:[1] (misc) NewlineAtEndOfFile: File does not end
> > >> with a
> > >> newline.*
> > >>
> > >> but I checkted this file and it ends with a new line. Is it bug in the
> > >> Checkstyle dependency?
> > >>
> > >> [INFO] BUILD FAILURE
> > >> [ERROR] Failed to execute goal
> > >> org.apache.maven.plugins:maven-pmd-plugin:3.8:cpd-check (cpd-check) on
> > >> project maven-checkstyle-plugin: You have 1 CPD duplication.
> > >>
> > >> There are exactly the same methods. That's why CPD fails, see
> > >> CheckstyleViolationCheckMojo L813
> > >> AbstractCheckstyleReportL581
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> On Mon, May 13, 2019 at 11:52 AM Enrico Olivelli  >
> > >> wrote:
> > >>
> > >> > Hi,
> > >> >
> > >> > We solved 13 issues:
> > >> >
> > >> 

Re: [VOTE] Release Apache Maven Checkstyle Plugin version 3.1.0

2019-05-13 Thread Enrico Olivelli
Tibor
It is strage all its are passing on CI.
Are you sure you have correcly unpacked the package?


Il lun 13 mag 2019, 21:23 Tibor Digana  ha scritto:

> checked the sha512 of src zip, ok
> checked the build, failed (mvn verify -P run-its,quality-checks)
>

What is 'quality-checks' profile? I have never heard about it

Enrico


> [INFO] Building: MCHECKSTYLE-54\pom.xml
> [INFO]   MCHECKSTYLE-54\pom.xml ... FAILED
> (5.3 s)
>
> *Mcheckstyle54.java:[1] (misc) NewlineAtEndOfFile: File does not end with a
> newline.*
>
> but I checkted this file and it ends with a new line. Is it bug in the
> Checkstyle dependency?
>
> [INFO] BUILD FAILURE
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-pmd-plugin:3.8:cpd-check (cpd-check) on
> project maven-checkstyle-plugin: You have 1 CPD duplication.
>
> There are exactly the same methods. That's why CPD fails, see
> CheckstyleViolationCheckMojo L813
> AbstractCheckstyleReport    L581
>
>
>
>
>
>
>
>
>
> On Mon, May 13, 2019 at 11:52 AM Enrico Olivelli 
> wrote:
>
> > Hi,
> >
> > We solved 13 issues:
> >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12342397=Text=12317223
> >
> > Please note that this version now only supports CheckStyle 8+ and Java 8
> > (as required by latest Checkstyle)
> >
> > There are still a couple of issues left in JIRA:
> >
> >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20XX%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC
> >
> > Staging repo:
> > https://repository.apache.org/content/repositories/maven-1503/
> >
> >
> https://repository.apache.org/content/repositories/maven-1503/org/apache/maven/plugins/maven-checkstyle-plugin/3.1.0/maven-checkstyle-plugin-3.1.0-source-release.zip
> >
> > Source release checksum(s):
> > maven-checkstyle-plugin-3.1.0-source-release.zip sha512:
> >
> >
> eca46edb4d2f6cf2e250169ce5d5e510781b4bba116cc7b5655797cdb109ccdb0da883a1761347c6e2c77fe58395aff17e45c46d85a8a823340ae2b11c92852e
> >
> > Staging site:
> >
> https://maven.apache.org/plugins-archives/maven-checkstyle-plugin-LATEST/
> >
> > Guide to testing staged releases:
> > https://maven.apache.org/guides/development/guide-testing-releases.html
> >
> > Vote open for at least 72 hours.
> >
> > [ ] +1
> > [ ] +0
> > [ ] -1
> >
> >
> > Enrico Olivelli
> >
>


[VOTE] Release Apache Maven Checkstyle Plugin version 3.1.0

2019-05-13 Thread Enrico Olivelli
Hi,

We solved 13 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12342397=Text=12317223

Please note that this version now only supports CheckStyle 8+ and Java 8
(as required by latest Checkstyle)

There are still a couple of issues left in JIRA:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20XX%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC

Staging repo:
https://repository.apache.org/content/repositories/maven-1503/
https://repository.apache.org/content/repositories/maven-1503/org/apache/maven/plugins/maven-checkstyle-plugin/3.1.0/maven-checkstyle-plugin-3.1.0-source-release.zip

Source release checksum(s):
maven-checkstyle-plugin-3.1.0-source-release.zip sha512:
eca46edb4d2f6cf2e250169ce5d5e510781b4bba116cc7b5655797cdb109ccdb0da883a1761347c6e2c77fe58395aff17e45c46d85a8a823340ae2b11c92852e

Staging site:
https://maven.apache.org/plugins-archives/maven-checkstyle-plugin-LATEST/

Guide to testing staged releases:
https://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for at least 72 hours.

[ ] +1
[ ] +0
[ ] -1


Enrico Olivelli


Re: Latest snapshot build (archive, not Maven artifact)

2019-05-12 Thread Enrico Olivelli
Il dom 12 mag 2019, 23:01 Olivier Lamy  ha scritto:

> +1
> definitely agree on that let's make it simple
> simple deploy of one build with java8 and voila.
> it's snapshot and NOT a release... so we do not have to jump on every bugs
> immediately.
>

Yes

+1

Enrico

It will be already a great forward to have quick feedback from maven
> consumers
>
>
>
>
> On Mon, 13 May 2019 at 02:43, Mickael Istria  wrote:
>
> > IMO, if some patch managed to get to master, it's worth being released,
> > even if IT test fail.
> > So I would make the first step being a `mvn deploy` of what[s in master,
> > before running other tests.
> > I think this would be much simpler, allow community to test some "master"
> > snapshot even if it's bugged (so community can help in resolving), and
> > would cover all use-cases I have about snapshot. And -to put it another
> > way- making complex effort to run IT tests on all OS before publishing a
> > snapshot is over-engineering.
> >
>
>
> --
> Olivier Lamy
> http://twitter.com/olamy | http://linkedin.com/in/olamy
>


Re: Tagging Maven Checkstyle plugin

2019-05-10 Thread Enrico Olivelli
Il giorno ven 10 mag 2019 alle ore 14:53 Eric Lilja 
ha scritto:

> Great news! Which version of Checkstyle will be default, 8.20? Hoping for
> 8.20!
>

Actually we have 8.19
https://github.com/apache/maven-checkstyle-plugin/blob/6abad1cb750244899c6e3b45a7a8bb49fba954db/pom.xml#L71

Feel free to send a PR

Enrico


>
> - Eric L
>
> On Fri, May 10, 2019 at 2:42 PM Tibor Digana 
> wrote:
>
> > Thx for your effort.
> > Good job with everything you have done in Maven.
> >
> > On Fri, May 10, 2019 at 2:23 PM Enrico Olivelli 
> > wrote:
> >
> > > Hi all,
> > > I am going to cut a release of Maven Checkstyle Plugin during this
> > weekend.
> > >
> > > There are major changes, I will release 3.1.0 version:
> > > - drop support for Java 7 (Checkstyle 8 needs java 8)
> > > - drop support for Checkstyle  < 8.x (We have migrated to the new
> > > Checkstyle API)
> > > - do not resolve anymore project depedencies (This seems deprecated
> from
> > > Checkstyle perspective)
> > >
> > > Most of these works have been done with guys from Checkstyle project
> and
> > > this is great because our plugin is mostly a wrapper around Checkstyle
> > and
> > > it is good that we work together.
> > >
> > > Unfortunately Checkstyle 8 has major breking changes and checkstyle
> > > configuration files taht worked on CS 6 do not work any more (I had to
> > > change a bunch of ITs) but this is expected
> > > and this is very appreciated from CS community because now they are
> free
> > to
> > > move forward
> > > with the project.
> > >
> > > Enrico
> > >
> >
>


Tagging Maven Checkstyle plugin

2019-05-10 Thread Enrico Olivelli
Hi all,
I am going to cut a release of Maven Checkstyle Plugin during this weekend.

There are major changes, I will release 3.1.0 version:
- drop support for Java 7 (Checkstyle 8 needs java 8)
- drop support for Checkstyle  < 8.x (We have migrated to the new
Checkstyle API)
- do not resolve anymore project depedencies (This seems deprecated from
Checkstyle perspective)

Most of these works have been done with guys from Checkstyle project and
this is great because our plugin is mostly a wrapper around Checkstyle and
it is good that we work together.

Unfortunately Checkstyle 8 has major breking changes and checkstyle
configuration files taht worked on CS 6 do not work any more (I had to
change a bunch of ITs) but this is expected
and this is very appreciated from CS community because now they are free to
move forward
with the project.

Enrico


Re: New release of ant-maven-plugin

2019-05-06 Thread Enrico Olivelli
Il lun 6 mag 2019, 14:47 Tibor Digana  ha scritto:

> I also would prefer using Java 8 in plugins but we have made an agreement
> to use Java 7 and migrate plugins to API 3.0.
> This means the ant-maven-plugin should be released with version 3.0.0.
>
> Enrico, do we loose some rules of Checkstyle if using the old version of
> the plugin at Java 7 here in Maven?
>

Sorry, I don't know

But checkstyle 8 needs java8
Enrico


> Cheers
> Tibor
>
> On Sat, May 4, 2019 at 9:01 PM Eric Lilja  wrote:
>
> > I would not mind at all seeing latest 1.10.x of Ant being used instead (I
> > believe 1.10.6 is being voted on at the moment), and the plugin requiring
> > Java 8. I am also happy to hear that the checkstyle plugin didn't get
> stuck
> > on some older, Java 7-compatible release of Checkstyle, but is able to
> > follow the latest versions! I think that's good!
> >
> > - Eric L
> >
> > On Sat, May 4, 2019 at 8:57 PM Enrico Olivelli 
> > wrote:
> >
> > > Il sab 4 mag 2019, 19:46 Eric Lilja  ha scritto:
> > >
> > > > That's great news, Sylwester! Since it will be version 3.0 (as you
> > say),
> > > > I'm assuming the plugin will be changed to require Maven 3.x and
> Java 7
> > > > (and update to latest Maven parents), as that is a target for
> official
> > > > Maven plugins versioned 3 and higher? And why can't we use ant
> version
> > > > 1.10.x, does it require Java 8?
> > > >
> > >
> > > FYI we are doing the same for checkstyle plugin. Checkstyle now
> requires
> > > java8 and so the new version of the plugin will adapt to its core
> > > dependency
> > >
> > >
> > > Enrico
> > >
> > >
> > >
> > > > Looking forward to the release!
> > > >
> > > > - Eric L
> > > >
> > > > On Fri, May 3, 2019 at 9:48 PM Sylwester Lachiewicz <
> > > slachiew...@gmail.com
> > > > >
> > > > wrote:
> > > >
> > > > > I have also updated Ant to 1.9.14 and I think we can already
> prepare
> > a
> > > > vote
> > > > > for the 3.0 release.
> > > > > Sylwester
> > > > >
> > > > > niedz., 14 kwi 2019 o 22:35 Sebastian Laskawiec <
> slask...@redhat.com
> > >
> > > > > napisał(a):
> > > > >
> > > > > > Hey Robert,
> > > > > >
> > > > > > Thank you for the heads up!
> > > > > >
> > > > > > I'm talking about this one:
> > > > > > org.apache.maven.plugins
> > > > > > maven-antrun-plugin
> > > > > > 1.8
> > > > > >
> > > > > > The one, that can run Ant scripts within a Maven project.
> > > > > >
> > > > > > Thanks,
> > > > > > Sebastian
> > > > > >
> > > > > > On Sat, Apr 13, 2019 at 11:50 AM Robert Scholte <
> > > rfscho...@apache.org>
> > > > > > wrote:
> > > > > >
> > > > > > > Hi Sebastian,
> > > > > > >
> > > > > > > be careful with your naming, because my first response would
> have
> > > > been
> > > > > > > 'no'.
> > > > > > >
> > > > > > > You're talking about ant-maven-plugin, whereas we maintain 2
> > > related
> > > > > > > plugins: maven-ant-plugin and maven-antrun-plugin.
> > > > > > >
> > > > > > > The first one can generate Ant scripts based on a Maven
> project.
> > > This
> > > > > > > project hasn't been touched for quite some time and it probably
> > > > doesn't
> > > > > > > make sense to maintain this plugin any longer.
> > > > > > >
> > > > > > > The latter on the other hand does make sense, however in
> general
> > it
> > > > is
> > > > > a
> > > > > > > sign that you're doing a task that should be transformed to a
> > > > dedicated
> > > > > > > Maven plugin.
> > > > > > >
> > > > > > > So all we need is somebody to step up as the release manager.
> > > > > > > Might be a good project for a Maven committer who has never
> done
> > a
> > > > > > > release
> > > > > > > before.
> > > > > > >
> > > > > > > Robert
> > > > > > >
> > > > > > > On Thu, 11 Apr 2019 09:28:02 +0200, Sebastian Laskawiec
> > > > > > >  wrote:
> > > > > > >
> > > > > > > > Hey,
> > > > > > > >
> > > > > > > > My name is Sebastian Łaskawiec and I'm a part of Keycloak
> > > > Engineering
> > > > > > > > Team
> > > > > > > > [1].
> > > > > > > >
> > > > > > > > Recently I hit a problem with resolving user properties that
> > > seems
> > > > to
> > > > > > be
> > > > > > > > fixed in Maven. I would love to give it a go but it seems we
> > > didn't
> > > > > > have
> > > > > > > > any release for a very long time [2]. Could you please tell
> me,
> > > do
> > > > > you
> > > > > > > > plan
> > > > > > > > to release a new version any time soon?
> > > > > > > >
> > > > > > > > On a side note, I already reached Hervé Boutemy, who asked me
> > to
> > > > > write
> > > > > > to
> > > > > > > > this email list and ask for release. Thank you for the hint,
> > > Hervé!
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > > Sebastian Łaskawiec
> > > > > > > > Senior Software Engineer @ Red Hat
> > > > > > > > Keycloak Engineering Team
> > > > > > > >
> > > > > > > > [1] https://www.keycloak.org/
> > > > > > > > [2] https://github.com/apache/maven-antrun-plugin/releases
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>


[ANN] Apache Maven Surefire Plugin 2.22.2 Released

2019-05-05 Thread Enrico Olivelli
The Apache Maven team is pleased to announce the release of the Apache
Maven Surefire Plugin, version 2.22.2.

The release contains 1 bug fix about JUnit 5 Compatibility

Again we received contributions from the community in form of bug reports
and bug fixes.
Thank you and keep them coming!

http://maven.apache.org/plugins/maven-surefire-plugin/

You should specify the version in your project's plugin configuration:


  org.apache.maven.plugins
  maven-surefire-plugin
  2.22.2


or for failsafe:


  org.apache.maven.plugins
  maven-failsafe-plugin
  2.22.2


or for surefire-report:


  org.apache.maven.plugins
  maven-surefire-report-plugin
  2.22.2



You can download the appropriate sources etc. from the download page:
https://maven.apache.org/surefire/download.cgi


Release Notes - Maven Surefire - Version 2.22.2

** Bug
* [SUREFIRE-1614] - JUnit Runner that writes to System.out corrupts
Surefire's STDOUT when using JUnit's Vintage Engine


Enjoy,

-The Apache Maven team


Re: New release of ant-maven-plugin

2019-05-04 Thread Enrico Olivelli
Il sab 4 mag 2019, 19:46 Eric Lilja  ha scritto:

> That's great news, Sylwester! Since it will be version 3.0 (as you say),
> I'm assuming the plugin will be changed to require Maven 3.x and Java 7
> (and update to latest Maven parents), as that is a target for official
> Maven plugins versioned 3 and higher? And why can't we use ant version
> 1.10.x, does it require Java 8?
>

FYI we are doing the same for checkstyle plugin. Checkstyle now requires
java8 and so the new version of the plugin will adapt to its core dependency


Enrico



> Looking forward to the release!
>
> - Eric L
>
> On Fri, May 3, 2019 at 9:48 PM Sylwester Lachiewicz  >
> wrote:
>
> > I have also updated Ant to 1.9.14 and I think we can already prepare a
> vote
> > for the 3.0 release.
> > Sylwester
> >
> > niedz., 14 kwi 2019 o 22:35 Sebastian Laskawiec 
> > napisał(a):
> >
> > > Hey Robert,
> > >
> > > Thank you for the heads up!
> > >
> > > I'm talking about this one:
> > > org.apache.maven.plugins
> > > maven-antrun-plugin
> > > 1.8
> > >
> > > The one, that can run Ant scripts within a Maven project.
> > >
> > > Thanks,
> > > Sebastian
> > >
> > > On Sat, Apr 13, 2019 at 11:50 AM Robert Scholte 
> > > wrote:
> > >
> > > > Hi Sebastian,
> > > >
> > > > be careful with your naming, because my first response would have
> been
> > > > 'no'.
> > > >
> > > > You're talking about ant-maven-plugin, whereas we maintain 2 related
> > > > plugins: maven-ant-plugin and maven-antrun-plugin.
> > > >
> > > > The first one can generate Ant scripts based on a Maven project. This
> > > > project hasn't been touched for quite some time and it probably
> doesn't
> > > > make sense to maintain this plugin any longer.
> > > >
> > > > The latter on the other hand does make sense, however in general it
> is
> > a
> > > > sign that you're doing a task that should be transformed to a
> dedicated
> > > > Maven plugin.
> > > >
> > > > So all we need is somebody to step up as the release manager.
> > > > Might be a good project for a Maven committer who has never done a
> > > > release
> > > > before.
> > > >
> > > > Robert
> > > >
> > > > On Thu, 11 Apr 2019 09:28:02 +0200, Sebastian Laskawiec
> > > >  wrote:
> > > >
> > > > > Hey,
> > > > >
> > > > > My name is Sebastian Łaskawiec and I'm a part of Keycloak
> Engineering
> > > > > Team
> > > > > [1].
> > > > >
> > > > > Recently I hit a problem with resolving user properties that seems
> to
> > > be
> > > > > fixed in Maven. I would love to give it a go but it seems we didn't
> > > have
> > > > > any release for a very long time [2]. Could you please tell me, do
> > you
> > > > > plan
> > > > > to release a new version any time soon?
> > > > >
> > > > > On a side note, I already reached Hervé Boutemy, who asked me to
> > write
> > > to
> > > > > this email list and ask for release. Thank you for the hint, Hervé!
> > > > >
> > > > > Thanks,
> > > > > Sebastian Łaskawiec
> > > > > Senior Software Engineer @ Red Hat
> > > > > Keycloak Engineering Team
> > > > >
> > > > > [1] https://www.keycloak.org/
> > > > > [2] https://github.com/apache/maven-antrun-plugin/releases
> > > >
> > >
> >
>


[RESULT] [VOTE] Release Apache Maven Surefire Plugin version 2.22.2

2019-05-02 Thread Enrico Olivelli
- Hi,
-
- The vote has passed with the following result:
-
- +1 : Tibor Digana, Stephane Nicoll, Romain Manni-Bucau,
- Francois Papon, Benedikt Ritter, Olivier Lamy
-
- PMC quorum: reached
-
- I will promote the artifacts to the central repo.

Enrico


  1   2   3   4   >