[MNG-5227] The 'optional' flag of a dependency should be manageable.

[jira-importer]

Christian Schulte opened MNG-5227 and commented

<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>groupId</groupId>
      <artifactId>artifactId</artifactId>
      <version>version</version>
      <optional>false</optional> <!-- Ignored by Maven 2 & 3 in dependency management. -->
    </dependency>
  </dependencies>
</dependencyManagement>

---

Affects: 3.0.3

Attachments:

• MNG-5227.patch (1.67 kB)
• MNG-5227.patch (2.06 kB)

Issue Links:

• MRESOLVER-9 DefaultDependencyCollector does not correctly handle dependency management
  ("is blocked by")

• MNG-5632 Optional tag in dependencyManagement not inherited - disallow and/or document
  ("is duplicated by")

• HIVE-27338 JDBC drivers are transitively inherited although declared optional
  ("causes")

• MNG-5600 Dependency management import should support exclusions.

• MNG-2984 Allow more control around the configuration and use of optional dependencies

• MNG-6139 Addition of command line option 'legacy-dependency-management'.
  ("is required by")

• MNG-4600 [regression] Optional flag from dependency management applied to dependencies
  ("supercedes")

• MNG-1977 Global dependency exclusions
  ("supercedes")

• MNG-5959 Can maven provide a features that exclude dependency gloablly
  ("supercedes")

• MNG-5935 Optional true getting lost in managed dependencies when transitive
  ("is depended upon by")

Remote Links:

• Page
  

6 votes, 14 watchers

[jira-importer]

Christian Schulte commented

This has been solved in Aether but not in Maven.

[jira-importer]

Christian Schulte commented

Fixed in Aether with d35844ccf9900c8d141cf796b67677a27830bec6.

[jira-importer]

Christian Schulte commented

This issue is blocked by Aether Bug 486740.

[jira-importer]

Jason van Zyl commented

I applied your patch locally, but I can't push because Eclipse's webhook's have detected you don't have an Eclipse CLA on file. So, I started the termination process with Eclipse, and I am working with Joel from Sonatype so I can push the code to Github in the interim and cut a release to Maven Central to unblock this. Bear with me.

[jira-importer]

Christian Schulte commented

Let me know if I there is anything I can do to help. Does it mean you are planning to change the Aether package names? We had 'org.sonatype.aether' and 'org.eclipse.aether' maybe it's time someone registers a 'aether.codes', 'aether.software' or whatever domain name and we use that for the package name once and for all? Maybe even rename the whole thing?

[jira-importer]

Jason van Zyl commented

No, I definitely do not want to rename the packages. It caused so much disruption that I really don't think it's worth it. Once it's entirely internalized it won't really matter so I don't see much point in causing a lot of grief. I'm working with the Eclipse Foundation on the termination of Aether and I don't think anyone is going to mind if we leave the package names as they are. I really don't see it as value-adding work to flip a bunch of package names and make adapters for everything. Should have a release out in a day or two.

[jira-importer]

Christian Schulte commented

I would not mind signing a CLA with Eclipse if that helps. No experience with any processes there, though.

[jira-importer]

Jason van Zyl commented

It's a little more complicated at Eclipse because your employer has to sign the corporate CLA. This usually takes a while, and honestly we're transitioning this back to Apache so I'll have something for you in Maven Central in a day or two.

[jira-importer]

Jason van Zyl commented

Christian Schulte There's no real need for a CLA at Eclipse because you have one at Apache. But I would ask that add a test for https://github.com/jvanzyl/aether-core/commit/da9708bf7321e25c2a74dddb893539f735135a6d. Also the ITs appear to be broken, do they depend on this change?

I will fill out the termination review paperwork today, ask Eclipse legal to verify my license change, and ask if we can continue to use their package names at Apache to prevent any unnecessary pain for users. I'll try to get this into Apache as fast as possible.

[jira-importer]

Jason van Zyl commented

Do you have corresponding changes in Maven core as the use of Aether with your patch causes a failure in Maven core for me?

[jira-importer]

Christian Schulte commented

The ITs have been committed already. They will start working with the updated Aether automatically.

[jira-importer]

Christian Schulte commented

If you are referring to 'maven-compat/src/test/java/org/apache/maven/project/inheritance/t06/ProjectInheritanceTest.java' then this test case needs updating. It's testing the existence of a transitive test dependency which should not be there. The scope in dependency management needs updating from 'test' to something available transitively to make it test what was intended. I've written test cases for 'maven-core' as well.

[jira-importer]

Jason van Zyl commented

But it is there, and you can't just arbitrarily change the behaviour. How do you know this won't affect anyone? You make a change in Aether with no tests, commit changes to ITs that fail without those changes in Aether, Maven core fails with the changes in Aether and then you assert the test needs to change? C'mon Christian, you can't do that.

[jira-importer]

Christian Schulte commented

Test case update.

[jira-importer]

Christian Schulte commented

That test case is testing the correct version is inherited and is not about anything scope. The author did not notice he is running into a Maven core issue. Please see the patch and tell me the test case is testing correct behaviour when not applied.