[GitHub] maven pull request: MNG-3092: Adds version range result filter beh...

Github user michael-o commented on the pull request: https://github.com/apache/maven/pull/70#issuecomment-151415114 @jvanzyl Are you saying that you dislike to change the default behavior, i.e., no merge? @barthel Did you run the ITs before and after your change? --- If your

Re: [VOTE] Release Apache Maven Shade Plugin version 2.4.2 (Take 2)

Hi, here is my +1 Kind regards Karl Heinz Marbaise On 10/24/15 12:48 PM, Karl Heinz Marbaise wrote: Hi, We solved 7 issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317921=12333008 There are still a couple of issues left in JIRA:

[GitHub] maven pull request: MNG-3092: Adds version range result filter beh...

Github user barthel commented on the pull request: https://github.com/apache/maven/pull/70#issuecomment-151395866 Can I do anything to support the merge? --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project

MNG-5899 Project models are no longer mutable in reactor

Context: MNG-5899 [1] which was originally reported as MSHADE-206 [2] I understand why the change[3] was made... but this change breaks about 80-90% of the use cases for the shade plugin... Is there any way we can consider a compromise? I think it should be permitted for a plugin to replace the

Re: [GitHub] maven pull request: MNG-3092: Adds version range result filter beh...

Changing the default behaviour of anything resolution related mid 3.x line is likely not a good idea. We definitely need to run the ITs with any changes like these to see what happens. Changing the way resolution works is definitely a 4.x thing. > On Oct 27, 2015, at 1:42 AM, michael-o

Re: MNG-5899 Project models are no longer mutable in reactor

The core model has to be mutable. I think there can be an ancillary model that carried other types of information like the dependency reduction. But mutation and re-consumption within the reactor I think is a bad idea and the complication enumerated below seems fairly extreme. Do you have a

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

+1 > On Oct 26, 2015, at 3:21 PM, Hervé BOUTEMY wrote: > > Hi, > > This is the first release of this new plugin. > 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 >

[GitHub] maven pull request: MNG-3092: Adds version range result filter beh...

Github user barthel commented on the pull request: https://github.com/apache/maven/pull/70#issuecomment-151463857 The default behavior is ``do nothing``. The ITs doesn't show any errors at this modifications. --- If your project is set up for it, you can reply to this email and have

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

+1 Arnaud On Mon, Oct 26, 2015 at 11:21 PM, Hervé BOUTEMY wrote: > Hi, > > This is the first release of this new plugin. > The JDeps Plugin uses the jdeps tool to analyze classes for internal API > calls. For more information about the standard jdeps tool, please refer

Java 7 and 8 features

I analized some releases and i noticed that not using java 7 features like multi catch and in java 8 do not use lambda expressions and others features, so i came by this email to know why the developers not using this features?

Re: MNG-5899 Project models are no longer mutable in reactor

I like the idea of a shaded-jar if we can make it work... though it does mean that anyone consuming poms outside of Maven will no longer be able to build the dependency graph without being aware of this special packaging... (plus there is also a set of use-cases from the flatten-maven-plugin and

Re: MNG-5899 Project models are no longer mutable in reactor

I think this only highlights the need to have immutable core model. The bundle plugin has no way to know how the shade plugin manipulates the pom and the generated bundle manifest will be based on original project model. (assuming I understand your suggested usecase) -- Regards, Igor On Tue,

Re: MNG-5899 Project models are no longer mutable in reactor

So I think we have then opportunity to model this correctly and we have something similar already in a WAR. We have a handler that clips all transitive dependencies. There would be a bit more work but if we make a separate packaging, build out the classpath correctly during the build we can

Re: MNG-5899 Project models are no longer mutable in reactor

On October 27, 2015 4:08:11 PM Jason van Zyl wrote: So I think we have then opportunity to model this correctly and we have something similar already in a WAR. We have a handler that clips all transitive dependencies. There would be a bit more work but if we make a separate

Re: Starting to cut Maven 3.3.7

Ok, no worries, as I said already, them version numbers are cheap (being and infinite supply of them and all that) On 27 October 2015 at 14:32, Jason van Zyl wrote: > Appears to be 3.3.7-SNAPHOT on master so I burned another one. > >> On Oct 27, 2015, at 7:28 AM, Stephen

Re: MNG-5899 Project models are no longer mutable in reactor

On Tue, Oct 27, 2015 at 10:40 AM, Igor Fedorenko wrote: > I think this only highlights the need to have immutable core model. The > bundle plugin has no way to know how the shade plugin manipulates the > pom and the generated bundle manifest will be based on original project

Re: MNG-5899 Project models are no longer mutable in reactor

If we went this route, it would be a new packaging type you opt into. It would purely be an additive change so wouldn’t affect any existing behaviour but only taking advantage of what we have for something like the WAR file. We may find this is insufficient but I don’t know without trying. >

Re: Java 7 and 8 features

We are just moved to java7 and start using new features I personally don't like the idea of moving all code to new java, I move the areas I currently work on On Tue, Oct 27, 2015 at 10:57 PM, Gary Gregory wrote: > Hi, > > What I see, is that most projects are struggling

Re: Java 7 and 8 features

Hi, What I see, is that most projects are struggling to move to Java 7, Java 8 seems out of range. There are a lot of opinions and both sides of each Java version for and against. At the end of the day, it's about user feedback and committer community involvement. The projects I help on also lack

Re: Java 7 and 8 features

Related to Java versions, Apache jclouds uses modernizer-maven-plugin to encourage use of modern Java APIs such as ArrayList, String.getBytes(Charset), etc.: https://github.com/andrewgaul/modernizer-maven-plugin On Tue, Oct 27, 2015 at 01:49:41PM -0200, Vinicius Corrêa de Almeida wrote: > I

Re: Java 7 and 8 features

Hi Vinicius, it is mostly to allow people which are bound (for any reason) to older JDK versions to use our software. There is a plenty number of projects which are not able to use newer JDK versions. I know that this is a controversial topic I think that the majority of us would like to

Re: [VOTE] Release Apache Maven Shade Plugin version 2.4.2 (Take 2)

Hi, i need one more binding VOTE... Kind regards Karl Heinz Marbaise On 10/24/15 12:48 PM, Karl Heinz Marbaise wrote: Hi, We solved 7 issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317921=12333008 There are still a couple of issues left in JIRA:

Re: [VOTE] Release Apache Maven Shade Plugin version 2.4.2 (Take 2)

+1 On Tue, Oct 27, 2015 at 4:20 PM, Karl Heinz Marbaise wrote: > Hi, > > i need one more binding VOTE... > > Kind regards > Karl Heinz Marbaise > > On 10/24/15 12:48 PM, Karl Heinz Marbaise wrote: >> >> Hi, >> >> We solved 7 issues: >> >>

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

+1 On 27 October 2015 at 09:21, Hervé BOUTEMY wrote: > Hi, > > This is the first release of this new plugin. > 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 >

Re: Starting to cut Maven 3.3.7

I thought the last failed spin was 3.3.5 so we should be spinning 3.3.6... but hey I don't mind, version numbers are cheap On 27 October 2015 at 14:09, Igor Fedorenko wrote: > This was announced 7 days ago on this list > >

Re: Starting to cut Maven 3.3.7

Appears to be 3.3.7-SNAPHOT on master so I burned another one. > On Oct 27, 2015, at 7:28 AM, Stephen Connolly > wrote: > > I thought the last failed spin was 3.3.5 so we should be spinning > 3.3.6... but hey I don't mind, version numbers are cheap > > On 27

[GitHub] maven pull request: MNG-3092: Adds version range result filter beh...

Github user jvanzyl commented on the pull request: https://github.com/apache/maven/pull/70#issuecomment-151499565 Then I don’t see an issue with merging it. > On Oct 27, 2015, at 4:38 AM, barthel wrote: > > The default behavior is do

Re: Starting to cut Maven 3.3.7

According to [1], we're still at 3.3.3, aren't we? 1: http://maven.apache.org/download.cgi On Tue, Oct 27, 2015 at 2:44 PM, Jason van Zyl wrote: > I’m going to start cutting the 3.3.7 now. > > Thanks, > > Jason > > -- >

Re: MNG-5899 Project models are no longer mutable in reactor

No, I meant immutable. > On Oct 27, 2015, at 6:58 AM, Igor Fedorenko wrote: > > Did you really mean "the core model has to be mutable"? The rest of your > message appears to suggest you do not want the model to be mutable, but > I am not sure. > > In any case, I think the

Re: MNG-5899 Project models are no longer mutable in reactor

On Tue, Oct 27, 2015 at 9:58 AM, Igor Fedorenko wrote: > Did you really mean "the core model has to be mutable"? The rest of your > message appears to suggest you do not want the model to be mutable, but > I am not sure. > > In any case, I think the core model must not be

Starting to cut Maven 3.3.7

I’m going to start cutting the 3.3.7 now. Thanks, Jason -- Jason van Zyl Founder, Takari and Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - Three people can

Re: Starting to cut Maven 3.3.7

> I’m going to start cutting the 3.3.7 now. Jason, could you announce this at least five days in advance? That would give at least some timeframe to merge PRs and handle issues. Michael - To unsubscribe, e-mail:

Re: MNG-5899 Project models are no longer mutable in reactor

Did you really mean "the core model has to be mutable"? The rest of your message appears to suggest you do not want the model to be mutable, but I am not sure. In any case, I think the core model must not be mutable. If the core model is mutable, this means pom.xml is not the ultimate source of

Re: Starting to cut Maven 3.3.7

This was announced 7 days ago on this list http://mail-archives.apache.org/mod_mbox/maven-dev/201510.mbox/%3CFFA7C22B-DD49-40C7-8D78-2C6D02B87D97%40takari.io%3E -- Regards, Igor On Tue, Oct 27, 2015, at 09:54 AM, Michael Osipov wrote: > > I’m going to start cutting the 3.3.7 now. > > Jason, >