date:20211220

Re: Fw: Request for Enhancement: Dependency Overrides

2021-12-20 Thread Romain Manni-Bucau

Hi Enno,

Reusing import in another block with another semantic has too much
drawbacks for me:

1. it makes the meaning different depending where it is used
2. you need to create a kind of bom for overrides which is not really the
intent/will on user side (you literally want an exclude/include mecanism)

I still have issues with transitivity with this feature, both cases are
valid (using it or not) but if we enable it then we break easily projects
with > 1 import level so guess we don't have the choice to not use it which
means a consumed project with imports must rewrite the pom to promote
imports as excludes - exactly as you do to day without tat feature - to
keep modelVersion=4.0.0 and the artifact consumable so not sure the gain is
that huge since at the end and as mentionned you *already* have that
feature: create a packaging=pom module and use it instead of the direct
artifact you want to use if you care about repeating some dependency.

I perfectly understand the quickfix spirit in case of a CVE but at the end
we are already tooled for that (dependency plugin, oss index etc) so as a
developer you don't gain much and technically once you have
excluded/included the dep you want in a consumable pom you are iso having
imports in the parent so it is a one time work if properly setup so I kind
of still think we don't need to make the dev life more complex but maybe
document it and worse case enhance dependency plugin to do that for you:
mvn dependency:replace -Ddependency.replace.from=javax.foo -
Ddependency.replace.to=jakarta.foo. In other words this can be thought more
in terms of process than model feature which simplifies a lot the learning
curve, usage, integration and way of doing for end users.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le lun. 20 déc. 2021 à 21:26, Enno Thieleke  a
écrit :

> Hello again,
>
> judging by the increased traffic in this mailing list some of you seem to
> be on vacation. That's nice. I was hoping that this might be a good time to
> ask for your opinion again about what I wrote a couple of weeks ago?
>
> Kind regards
> Enno
>
> 
> From: Enno Thieleke 
> Sent: Friday, December 3, 2021 10:54 AM
> To: Maven Developers List 
> Subject: Re: Request for Enhancement: Dependency Overrides
>
> Hi,
>
> concerning the request to change the override XML element to a
> fully-fledged dependency, thus removing the need for accompanying managed
> dependencies...
>
> tl;dr
> I would add a version attribute, nothing more, to the override XML
> element. The rest would remain unchanged.
>
> Full version:
>
> If I turned the override XML element into a fully-fledged dependency,
> should we support properties such as `scope` and `optional`? In my opinion
> we shouldn't, because that's still subject to original dependency
> definitions, not overrides. If people want to change the scope or add
> exclusions, they should stick to dependency management. That's what it's
> there for.
> I think it's enough to just add a version child-element to the current
> override XML element. That would remove the need for accompanying managed
> dependencies for just versions and in many simple cases that'd suffice,
> wouldn't you agree? I think we should draw the line here between changing
> artifact coordinates, a special kind of dependency management, and managing
> other dependency properties -> separation of concerns.
> Suppose I added a version child-element, I'd still have concerns about
> moving dependencyOverrides up one level so that it would be a sibling of
> dependencyManagement. Imagine I moved dependencyOverrides up one level. How
> would we import them properly? Currently importing a POM imports both:
> managed dependencies as well as overrides and I think that wouldn't be the
> right approach anymore. Would special import XML elements do the trick?
> Such as this:
>
> 
>   
> 
>   ...
>   import 
> 
>   
> 
> 
>   
>  
>   
>   
>   
> 
>   
>   ...
> 
>
> To be honest: I think that'd suck. Another way would be to introduce a new
> special purpose scope, but I think the existing special purpose scope
> "import" is perfect: it's meant to import dependency management information
> from different POMs and since overrides affect dependencies in the sense
> that they manage dependency coordinates, we're still talking about
> dependency management.
>
> Please let me know what you think.
>
> Kind regards
> Enno
>
> 
> From: Romain Manni-Bucau 
> Sent: Monday, November 22, 2021 2:33 PM
> To: Maven Developers List 
> Subject: Re: Request for Enhancement: Dependency Overrides
>
> Le lun. 22 nov. 2021 à 14:15, Enno Th

Re: Using of Travis

2021-12-20 Thread Xeno Amess

travis is too slow comparing to github actions.
so as github actions be free...
+1 for move to actions.

XenoAmess

From: Gary Gregory 
Sent: Tuesday, December 21, 2021 12:23:46 AM
To: Maven Developers List 
Subject: Re: Using of Travis

FWIW, I plan on doing the same for most Apache Commons components.

Gary

On Mon, Dec 20, 2021, 11:22 Elliotte Rusty Harold 
wrote:

> +1 to drop Travis, for multiple reasons
>
> On Fri, Dec 17, 2021 at 7:52 AM Slawomir Jaranowski
>  wrote:
> >
> > Hi,
> >
> > As the primary CI environment we use Jenkins.
> > Now also using GH Actions  ...
> > I think that those both are enough.
> >
> > Some projects contain scripts for Travis, like surefire.
> >
> > Do we want to still use Travis?
> >
> > --
> > Sławomir Jaranowski
>
>
>
> --
> 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
>
>

Fw: Request for Enhancement: Dependency Overrides

2021-12-20 Thread Enno Thieleke

Hello again,

judging by the increased traffic in this mailing list some of you seem to be on 
vacation. That's nice. I was hoping that this might be a good time to ask for 
your opinion again about what I wrote a couple of weeks ago?

Kind regards
Enno


From: Enno Thieleke 
Sent: Friday, December 3, 2021 10:54 AM
To: Maven Developers List 
Subject: Re: Request for Enhancement: Dependency Overrides

Hi,

concerning the request to change the override XML element to a fully-fledged 
dependency, thus removing the need for accompanying managed dependencies...

tl;dr
I would add a version attribute, nothing more, to the override XML element. The 
rest would remain unchanged.

Full version:

If I turned the override XML element into a fully-fledged dependency, should we 
support properties such as `scope` and `optional`? In my opinion we shouldn't, 
because that's still subject to original dependency definitions, not overrides. 
If people want to change the scope or add exclusions, they should stick to 
dependency management. That's what it's there for.
I think it's enough to just add a version child-element to the current override 
XML element. That would remove the need for accompanying managed dependencies 
for just versions and in many simple cases that'd suffice, wouldn't you agree? 
I think we should draw the line here between changing artifact coordinates, a 
special kind of dependency management, and managing other dependency properties 
-> separation of concerns.
Suppose I added a version child-element, I'd still have concerns about moving 
dependencyOverrides up one level so that it would be a sibling of 
dependencyManagement. Imagine I moved dependencyOverrides up one level. How 
would we import them properly? Currently importing a POM imports both: managed 
dependencies as well as overrides and I think that wouldn't be the right 
approach anymore. Would special import XML elements do the trick? Such as this:


  

  ...
  import 

  


  
 
  
  
  

  
  ...


To be honest: I think that'd suck. Another way would be to introduce a new 
special purpose scope, but I think the existing special purpose scope "import" 
is perfect: it's meant to import dependency management information from 
different POMs and since overrides affect dependencies in the sense that they 
manage dependency coordinates, we're still talking about dependency management.

Please let me know what you think.

Kind regards
Enno


From: Romain Manni-Bucau 
Sent: Monday, November 22, 2021 2:33 PM
To: Maven Developers List 
Subject: Re: Request for Enhancement: Dependency Overrides

Le lun. 22 nov. 2021 à 14:15, Enno Thieleke  a
écrit :

> Hello,
>
> @Delany, regarding 1 and 2: If I added all the other elements of the
> dependency tag, I would have to apply dependency management anyway if
> present (and I played around with it for a bit), but I see your point.
> Maybe using the dependency tag (I'd still name it override though) is "good
> enough" for small projects/POMs. I will throw a bit of time at it and check
> for "bad" implications.
>
> Making the override tag optional to have some sort of global exclusion
> mechanism is out of scope. Let me explain: When dependency management comes
> into play (in maven-resolver), it is not designed/intended to suddenly have
> no dependency at hand to work with. The dependency node in the graph
> already exists and the only thing that's left to do is filling it with the
> right information. I would have to rewrite/change that code as well. I.e.
> the code would have to check for a dependencyOverride with a matching
> original with no override. To be honest, I personally find that to be
> confusing. An exclusion should be explicit, because it carries a lot of
> weight in my opinion. The absence of an XML element should not make for an
> exclusion. Global excludes should exist though, just in a different way.
>
> @Romain, I disagree that not defining the version in an override could be
> a source of big issues, because it would have to be defined in dependency
> management anyway, so it's basically there. Changing the major version is
> possible, even today, simply by using dependency management. It is the
> responsibility of the developer to provide a proper override (which is why
> I suggested a different name, dropinReplacement, to make the intent
> clearer). Still, as stated earlier, I will see what I can do. No promises
> though. :)
>

I never said I like that but it is what it is so "it would have to be
defined in dependency management" is an assumption you cannot do and is
erroneous and I don't see us saying you can't use this override feature
and/or we break your project if you do so I guess we don't have much choice
than baking it completely and not half.

Keep in mind dependencyManagement does not behave as dependency override
but that it solves similar issues (controlling your dependency

[GitHub] [maven-site] slawekjaranowski merged pull request #268: IntelliJ IDEA - code style for Groovy

2021-12-20 Thread GitBox



slawekjaranowski merged pull request #268:
URL: https://github.com/apache/maven-site/pull/268


   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[GitHub] [maven-mvnd] yliu224 commented on issue #514: Unsupported address error when running linux machine

2021-12-20 Thread GitBox



yliu224 commented on issue #514:
URL: https://github.com/apache/maven-mvnd/issues/514#issuecomment-998230925


   Yes, it's the same 
   
   ```
   ❯ mvnd -Djava.net.preferIPv4Stack=false -Djava.net.preferIPv6Addresses=true 
-v
   mvnd native client 0.7.1-linux-amd64 
(97c587c11383a67b5bd0ff8388bd94c694b91c1e)
   Terminal: org.jline.terminal.impl.PosixSysTerminal with pty 
org.jline.terminal.impl.jansi.linux.LinuxNativePty
   Exception in thread "main" java.lang.IllegalArgumentException: Unsupported 
address: inet:/[0:0:0:0:0:0:0:1]:38953
at 
org.mvndaemon.mvnd.common.SocketFamily.fromString(SocketFamily.java:95)
at 
org.mvndaemon.mvnd.client.DaemonConnector.connect(DaemonConnector.java:482)
at 
org.mvndaemon.mvnd.client.DaemonConnector.connectToDaemon(DaemonConnector.java:452)
at 
org.mvndaemon.mvnd.client.DaemonConnector.connectToDaemonWithId(DaemonConnector.java:438)
at 
org.mvndaemon.mvnd.client.DaemonConnector.startDaemon(DaemonConnector.java:288)
at 
org.mvndaemon.mvnd.client.DaemonConnector.connect(DaemonConnector.java:122)
at 
org.mvndaemon.mvnd.client.DefaultClient.execute(DefaultClient.java:272)
at org.mvndaemon.mvnd.client.DefaultClient.main(DefaultClient.java:118)
   ❯ echo $JAVA_TOOL_OPTIONS
   -Xmx8192m -Djava.net.preferIPv6Addresses=true
   ```


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

Re: [VOTE] Release Maven Wagon version 3.5.0

2021-12-20 Thread Arnaud Héritier

+1

Le lun. 20 déc. 2021 à 17:48, Olivier Lamy  a écrit :

> +1
>
> On Sun, 19 Dec 2021 at 19:46, Michael Osipov  wrote:
>
> > Hi,
> >
> > We solved 5 issues:
> >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318122&version=12351097
> >
> > There are still a couple of issues left in JIRA:
> >
> >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20WAGON%20AND%20resolution%20%3D%20Unresolved
> >
> > Staging repo:
> > https://repository.apache.org/content/repositories/maven-1680/
> >
> >
> https://repository.apache.org/content/repositories/maven-1680/org/apache/maven/wagon/wagon/3.5.0/wagon-3.5.0-source-release.zip
> >
> > Source release checksum(s):
> > wagon-3.5.0-source-release.zip
> > sha512:
> >
> >
> c24c05c37b621c6ce160ef30675ca94c683b8581a2252a6b383d852d779816cbd80688f2e14d8eb1722e56984f97b301379762a9ebba77e9366ece03bef69d52
> >
> > Staging site:
> > https://maven.apache.org/wagon-archives/wagon-LATEST/
> >
> > Guide to testing staged releases:
> > https://maven.apache.org/guides/development/guide-testing-releases.html
> >
> > Vote open for 72 hours.
> >
> > [ ] +1
> > [ ] +0
> > [ ] -1
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>
-- 
Arnaud Héritier
Twitter/GitHub/... : aheritier

Re: [VOTE] Release Maven Wagon version 3.5.0

2021-12-20 Thread Olivier Lamy

+1

On Sun, 19 Dec 2021 at 19:46, Michael Osipov  wrote:

> Hi,
>
> We solved 5 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318122&version=12351097
>
> There are still a couple of issues left in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20WAGON%20AND%20resolution%20%3D%20Unresolved
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1680/
>
> https://repository.apache.org/content/repositories/maven-1680/org/apache/maven/wagon/wagon/3.5.0/wagon-3.5.0-source-release.zip
>
> Source release checksum(s):
> wagon-3.5.0-source-release.zip
> sha512:
>
> c24c05c37b621c6ce160ef30675ca94c683b8581a2252a6b383d852d779816cbd80688f2e14d8eb1722e56984f97b301379762a9ebba77e9366ece03bef69d52
>
> Staging site:
> https://maven.apache.org/wagon-archives/wagon-LATEST/
>
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Using of Travis

2021-12-20 Thread Gary Gregory

FWIW, I plan on doing the same for most Apache Commons components.

Gary

On Mon, Dec 20, 2021, 11:22 Elliotte Rusty Harold 
wrote:

> +1 to drop Travis, for multiple reasons
>
> On Fri, Dec 17, 2021 at 7:52 AM Slawomir Jaranowski
>  wrote:
> >
> > Hi,
> >
> > As the primary CI environment we use Jenkins.
> > Now also using GH Actions  ...
> > I think that those both are enough.
> >
> > Some projects contain scripts for Travis, like surefire.
> >
> > Do we want to still use Travis?
> >
> > --
> > Sławomir Jaranowski
>
>
>
> --
> 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: Using of Travis

2021-12-20 Thread Elliotte Rusty Harold

+1 to drop Travis, for multiple reasons

On Fri, Dec 17, 2021 at 7:52 AM Slawomir Jaranowski
 wrote:
>
> Hi,
>
> As the primary CI environment we use Jenkins.
> Now also using GH Actions  ...
> I think that those both are enough.
>
> Some projects contain scripts for Travis, like surefire.
>
> Do we want to still use Travis?
>
> --
> Sławomir Jaranowski



-- 
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: [VOTE] Release Maven Wagon version 3.5.0

2021-12-20 Thread Jason van Zyl

+1

> On Dec 19, 2021, at 1:46 PM, Michael Osipov  wrote:
> 
> Hi,
> 
> We solved 5 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318122&version=12351097
> 
> There are still a couple of issues left in JIRA:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20WAGON%20AND%20resolution%20%3D%20Unresolved
> 
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1680/
> https://repository.apache.org/content/repositories/maven-1680/org/apache/maven/wagon/wagon/3.5.0/wagon-3.5.0-source-release.zip
> 
> Source release checksum(s):
> wagon-3.5.0-source-release.zip
> sha512: 
> c24c05c37b621c6ce160ef30675ca94c683b8581a2252a6b383d852d779816cbd80688f2e14d8eb1722e56984f97b301379762a9ebba77e9366ece03bef69d52
> 
> Staging site:
> https://maven.apache.org/wagon-archives/wagon-LATEST/
> 
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
> 
> Vote open for 72 hours.
> 
> [ ] +1
> [ ] +0
> [ ] -1
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 

Thanks,

Jason




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

Re: [VOTE] Release Maven Resolver version 1.7.3

2021-12-20 Thread Jason van Zyl

+1

> On Dec 19, 2021, at 2:31 PM, Michael Osipov  wrote:
> 
> Hi,
> 
> We solved 6 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12320628&version=12350595
> 
> There are still a couple of issues left in JIRA:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20resolution%20%3D%20Unresolved%20AND%20component%20%3D%20Resolver
> 
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1681/
> https://repository.apache.org/content/repositories/maven-1681/org/apache/maven/resolver/maven-resolver/1.7.3/maven-resolver-1.7.3-source-release.zip
> 
> Source release checksum(s):
> maven-resolver-1.7.3-source-release.zip
> fb41a2cff0bf83f0e2e9a53f97fb4c8803c492b1d07ae5493e70101214b49db2b829850868adea06dc75436e6f0a023db31fef90dd1de8e9433210a87684db9b
> 
> Staging site:
> https://maven.apache.org/resolver-archives/resolver-LATEST/
> 
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
> 
> Vote open for 72 hours.
> 
> [ ] +1
> [ ] +0
> [ ] -1
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 

Thanks,

Jason




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

[GitHub] [maven-mvnd] mschorsch commented on issue #490: Daemon forgets about maven settings on reuse

2021-12-20 Thread GitBox



mschorsch commented on issue #490:
URL: https://github.com/apache/maven-mvnd/issues/490#issuecomment-997896424


   The issue seems to happen only in multi module projects.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

Re: Fw: Request for Enhancement: Dependency Overrides

Re: Using of Travis

Fw: Request for Enhancement: Dependency Overrides

[GitHub] [maven-site] slawekjaranowski merged pull request #268: IntelliJ IDEA - code style for Groovy

[GitHub] [maven-mvnd] yliu224 commented on issue #514: Unsupported address error when running linux machine

Re: [VOTE] Release Maven Wagon version 3.5.0

Re: [VOTE] Release Maven Wagon version 3.5.0

Re: Using of Travis

Re: Using of Travis

Re: [VOTE] Release Maven Wagon version 3.5.0

Re: [VOTE] Release Maven Resolver version 1.7.3

[GitHub] [maven-mvnd] mschorsch commented on issue #490: Daemon forgets about maven settings on reuse

12 matches

Site Navigation

Mail list logo

Footer information