Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

Am 08/12/16 um 15:58 schrieb Samuel Langlois: > Thanks for your answer Robert. > It is a bit more complicated than just being unable to override a property. > It's more that you can't change a dependencyManagement defined above by > overriding a property. > Anyway, I think it deserves an issue to

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

Could you please test properties can correctly be overridden again in the latest 3.4.0-SNAPSHOT available from . It should have been fixed by this commit

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

The code in question is in class 'DefaultModelBuilder'. Everything is done by those two methods: public ModelBuildingResult build( ModelBuildingRequest request ) public ModelBuildingResult build( ModelBuildingRequest request, ModelBuildingResult result ) Called in that order.

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

Am 08/13/16 um 00:28 schrieb Christian Schulte: > reviewing things. So current state of this is: "That's the behaviour > requested and tested during commiting to MNG-5971. Cannot override > properties? Really requested behaviour? Maybe incorrect. Need to look at > it again. There was a reason it

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

Am 08/12/16 um 20:11 schrieb Curtis Rueden: > Hi Christian, > > Thank you very much for looking at my example, and your speedy reply. > >> Can you please add your objections to MNG-5971 in JIRA. > > Done. I also added the same comments to MNG-6079, which I believe is a > legitimate regression

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

Hi Christian, Thank you very much for looking at my example, and your speedy reply. > Can you please add your objections to MNG-5971 in JIRA. Done. I also added the same comments to MNG-6079, which I believe is a legitimate regression caused by the fixing of MNG-5971. > > 2) I do not know how

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

Am 12.08.2016 um 19:16 schrieb Curtis Rueden: Hi all, Concerned by this thread, I did some tests. And I have to say, the new Maven 3.4.0 dependency resolution rules seem like a step backwards. == REAL-WORLD EXAMPLE == Consider the following project:

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

Can you please add your objections to MNG-5971 in JIRA. Maybe by copy and pasting your email. Reverting to the old behaviour is problematic and most of the users having taken part in that discussion will disagree with you, I think. The issue has been filed due to real-world problems. There are

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

Hi all, Concerned by this thread, I did some tests. And I have to say, the new Maven 3.4.0 dependency resolution rules seem like a step backwards. == REAL-WORLD EXAMPLE == Consider the following project: https://github.com/fiji/fiji/blob/ced9faee1c4fba9997a3d614759fb6e78e359d4f/pom.xml Amongst

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

Am 08/12/16 um 14:41 schrieb Samuel Langlois: > Hello > > I noticed a change of behaviour in Maven 3.4, which made one of our builds > fail. > It may be a bit of a corner case, so I'll let someone else decide whether > it's a regression or a bug fix... You can read all about it here:

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

Thanks for your answer Robert. It is a bit more complicated than just being unable to override a property. It's more that you can't change a dependencyManagement defined above by overriding a property. Anyway, I think it deserves an issue to be looked at properly, so I created

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

This should be treated as a bug. Many builds, including ours, relies on being able to override properties defined in the parent hierarchy in a module POM. This change you are describing would break a lot of builds... > On Aug 12, 2016, at 8:41 AM, Samuel Langlois

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

Hello I noticed a change of behaviour in Maven 3.4, which made one of our builds fail. It may be a bit of a corner case, so I'll let someone else decide whether it's a regression or a bug fix... We have a submodule where the "parent" pom contains a dependency with scope=import, but with the

Re: Read git email in pom.xml

Thanks @lando. Really appreciate you help!. On Fri, Aug 12, 2016 at 7:29 AM, lando wrote: > Nvm looks like you got the info already. > > On Fri, Aug 12, 2016 at 7:27 AM, lando wrote: > > > It would be using environment variables I believe. I've put some

Re: Read git email in pom.xml

Nvm looks like you got the info already. On Fri, Aug 12, 2016 at 7:27 AM, lando wrote: > It would be using environment variables I believe. I've put some time > into maven, I'll see what I can work out. > > > On Fri, Aug 12, 2016 at 2:57 AM, swapnil barwat

Re: Read git email in pom.xml

It would be using environment variables I believe. I've put some time into maven, I'll see what I can work out. On Fri, Aug 12, 2016 at 2:57 AM, swapnil barwat wrote: > I have a requirement where i need to send license volition mail to the > owner (whoever is

Read git email in pom.xml

I have a requirement where i need to send license volition mail to the owner (whoever is committed the code). I am using artifactory maven plugin which has license configuration. This allows you to config violation recipients" in pom.xml where you can mention the email address to whom you want to

Re: Artifactory pro abstract credentials in settings.xml

Thanks guys for the reply. I was able to solve using environment variable. I set two environment variable and use it in pom.xml. Artifactory maven plugin by default doesn't support read credentials from settings.xml. I appreciate the help! On Tue, Aug 9, 2016 at 2:36 PM, Martin Gainty