[jira] [Commented] (MSHARED-1327) Change output directory default in AbstractMavenReport
[
https://issues.apache.org/jira/browse/MSHARED-1327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17784700#comment-17784700
]
ASF GitHub Bot commented on MSHARED-1327:
-
michael-o commented on PR #26:
URL:
https://github.com/apache/maven-reporting-impl/pull/26#issuecomment-1805231560
I still stand with `reports`.
> Change output directory default in AbstractMavenReport
> --
>
> Key: MSHARED-1327
> URL: https://issues.apache.org/jira/browse/MSHARED-1327
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-reporting-impl
>Affects Versions: maven-reporting-impl-4.0.0-M11
>Reporter: Alexander Kriegisch
>Assignee: Michael Osipov
>Priority: Major
> Fix For: maven-reporting-impl-4.0.0-M12
>
>
> The output directory should default to {{${project.build.directory}}} instead
> of {{${project.reporting.outputDirectory}}}. Quoting my reasoning from
> https://github.com/apache/maven-jxr/commit/ae81a34ac616bf7e4ea4fa9d4eb09f0979eaccb1#commitcomment-130639906:
> {quote}
> (...) because the latter is simply wrong IMO. For stand-alone mojo execution,
> a plugin should not mess with Maven Site's default directory. Imagine a
> situation in which each module should get its own, self-consistent report
> when called stand-alone, but the site should contain an aggregate with a
> different structure or maybe no report from that plugin at all. The default
> would then pollute the site directory. This is why on the ML I asked you
> ([~michaelo]), if overriding a {{@Parameter}} annotation on a base class
> field by another {{@Parameter}} annotation on a setter in a subclass it is
> the right or canonical way to implement such a default override.
> BTW, like I also said before, Maven Javadoc Plugin, even though it does not
> use the abstract base class, implements the default correctly: build dir for
> stand-alone, report dir in site generation context.
> {quote}
> The javadoc is, BTW, still correct and does not need to be changed: In a site
> generation context, the reporting base directory will be set here
> automatically without any further changes due to:
> {code:java}
> @Override
> public void setReportOutputDirectory(File reportOutputDirectory) {
> this.reportOutputDirectory = reportOutputDirectory;
> this.outputDirectory = reportOutputDirectory;
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MSHARED-1327] Change output directory default [maven-reporting-impl]
michael-o commented on PR #26: URL: https://github.com/apache/maven-reporting-impl/pull/26#issuecomment-1805231560 I still stand with `reports`. -- 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: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MSHARED-1327) Change output directory default in AbstractMavenReport
[
https://issues.apache.org/jira/browse/MSHARED-1327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17784651#comment-17784651
]
ASF GitHub Bot commented on MSHARED-1327:
-
kriegaex commented on PR #26:
URL:
https://github.com/apache/maven-reporting-impl/pull/26#issuecomment-1804970463
> Even if a plugin uses a subdir in the shared one, there are still assets
from the skin which need to be present to properly render the report in the
browser.
Then, I think I am with you concerning the idea to have a dedicated common
base directory for reports, because now you just gave me a good reason for it:
common assets from the skin. I had not thought about that before.
Of course, the current default `${project.reporting.outputDirectory}` serves
this purpose, but as we discussed, calling a stand-alone goal could yield a
different kind of report (per module, not aggregated) than building a site. Now
that we established that `${project.build.directory}` might be inadequate,
something like `${project.build.directory}/reports` might actually be the
better solution.
> Change output directory default in AbstractMavenReport
> --
>
> Key: MSHARED-1327
> URL: https://issues.apache.org/jira/browse/MSHARED-1327
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-reporting-impl
>Affects Versions: maven-reporting-impl-4.0.0-M11
>Reporter: Alexander Kriegisch
>Assignee: Michael Osipov
>Priority: Major
> Fix For: maven-reporting-impl-4.0.0-M12
>
>
> The output directory should default to {{${project.build.directory}}} instead
> of {{${project.reporting.outputDirectory}}}. Quoting my reasoning from
> https://github.com/apache/maven-jxr/commit/ae81a34ac616bf7e4ea4fa9d4eb09f0979eaccb1#commitcomment-130639906:
> {quote}
> (...) because the latter is simply wrong IMO. For stand-alone mojo execution,
> a plugin should not mess with Maven Site's default directory. Imagine a
> situation in which each module should get its own, self-consistent report
> when called stand-alone, but the site should contain an aggregate with a
> different structure or maybe no report from that plugin at all. The default
> would then pollute the site directory. This is why on the ML I asked you
> ([~michaelo]), if overriding a {{@Parameter}} annotation on a base class
> field by another {{@Parameter}} annotation on a setter in a subclass it is
> the right or canonical way to implement such a default override.
> BTW, like I also said before, Maven Javadoc Plugin, even though it does not
> use the abstract base class, implements the default correctly: build dir for
> stand-alone, report dir in site generation context.
> {quote}
> The javadoc is, BTW, still correct and does not need to be changed: In a site
> generation context, the reporting base directory will be set here
> automatically without any further changes due to:
> {code:java}
> @Override
> public void setReportOutputDirectory(File reportOutputDirectory) {
> this.reportOutputDirectory = reportOutputDirectory;
> this.outputDirectory = reportOutputDirectory;
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MSHARED-1327] Change output directory default [maven-reporting-impl]
kriegaex commented on PR #26:
URL:
https://github.com/apache/maven-reporting-impl/pull/26#issuecomment-1804970463
> Even if a plugin uses a subdir in the shared one, there are still assets
from the skin which need to be present to properly render the report in the
browser.
Then, I think I am with you concerning the idea to have a dedicated common
base directory for reports, because now you just gave me a good reason for it:
common assets from the skin. I had not thought about that before.
Of course, the current default `${project.reporting.outputDirectory}` serves
this purpose, but as we discussed, calling a stand-alone goal could yield a
different kind of report (per module, not aggregated) than building a site. Now
that we established that `${project.build.directory}` might be inadequate,
something like `${project.build.directory}/reports` might actually be the
better solution.
--
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: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MDEP-896) Removing unused code
[ https://issues.apache.org/jira/browse/MDEP-896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17784649#comment-17784649 ] Karl Heinz Marbaise commented on MDEP-896: -- Done in [8b150c49a6221751c3bc992dbff67e06ce37bfa9|https://gitbox.apache.org/repos/asf?p=maven-dependency-plugin.git;a=commitdiff;h=8b150c49a6221751c3bc992dbff67e06ce37bfa9] > Removing unused code > > > Key: MDEP-896 > URL: https://issues.apache.org/jira/browse/MDEP-896 > Project: Maven Dependency Plugin > Issue Type: Improvement >Affects Versions: 3.6.1 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.6.2 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MDEP-896) Removing unused code
[ https://issues.apache.org/jira/browse/MDEP-896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise closed MDEP-896. Resolution: Done > Removing unused code > > > Key: MDEP-896 > URL: https://issues.apache.org/jira/browse/MDEP-896 > Project: Maven Dependency Plugin > Issue Type: Improvement >Affects Versions: 3.6.1 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.6.2 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MDEP-896) Removing unused code
Karl Heinz Marbaise created MDEP-896: Summary: Removing unused code Key: MDEP-896 URL: https://issues.apache.org/jira/browse/MDEP-896 Project: Maven Dependency Plugin Issue Type: Improvement Affects Versions: 3.6.1 Reporter: Karl Heinz Marbaise Assignee: Karl Heinz Marbaise Fix For: 3.6.2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MSHARED-1333) Upgrade maven-shared-components to version 40
[ https://issues.apache.org/jira/browse/MSHARED-1333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17784646#comment-17784646 ] Karl Heinz Marbaise commented on MSHARED-1333: -- Done in [b2923d2f0dd6241ceae7244086c4d5e4df7ed326|https://gitbox.apache.org/repos/asf?p=maven-dependency-tree.git;a=commitdiff;h=b2923d2f0dd6241ceae7244086c4d5e4df7ed326] > Upgrade maven-shared-components to version 40 > - > > Key: MSHARED-1333 > URL: https://issues.apache.org/jira/browse/MSHARED-1333 > Project: Maven Shared Components > Issue Type: Improvement > Components: maven-dependency-tree >Affects Versions: maven-dependency-tree-3.2.1 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: maven-dependency-tree-3.2.2 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MSHARED-1333) Upgrade maven-shared-components to version 40
[ https://issues.apache.org/jira/browse/MSHARED-1333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise closed MSHARED-1333. Resolution: Done > Upgrade maven-shared-components to version 40 > - > > Key: MSHARED-1333 > URL: https://issues.apache.org/jira/browse/MSHARED-1333 > Project: Maven Shared Components > Issue Type: Improvement > Components: maven-dependency-tree >Affects Versions: maven-dependency-tree-3.2.1 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: maven-dependency-tree-3.2.2 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] Bump org.junit.jupiter:junit-jupiter-api from 5.10.0 to 5.10.1 [maven-dependency-analyzer]
dependabot[bot] closed pull request #99: Bump org.junit.jupiter:junit-jupiter-api from 5.10.0 to 5.10.1 URL: https://github.com/apache/maven-dependency-analyzer/pull/99 -- 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: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Bump org.junit.jupiter:junit-jupiter-api from 5.10.0 to 5.10.1 [maven-dependency-analyzer]
dependabot[bot] commented on PR #99: URL: https://github.com/apache/maven-dependency-analyzer/pull/99#issuecomment-1804938814 Looks like org.junit.jupiter:junit-jupiter-api is up-to-date now, so this is no longer needed. -- 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: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MSHARED-1332) Usage of bom instead of single dependencies
[ https://issues.apache.org/jira/browse/MSHARED-1332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17784645#comment-17784645 ] Karl Heinz Marbaise commented on MSHARED-1332: -- Done in [0ae9f893d29d7dea031c718fc7e1cb465fc4d6ff|https://gitbox.apache.org/repos/asf?p=maven-dependency-analyzer.git;a=commitdiff;h=0ae9f893d29d7dea031c718fc7e1cb465fc4d6ff] > Usage of bom instead of single dependencies > --- > > Key: MSHARED-1332 > URL: https://issues.apache.org/jira/browse/MSHARED-1332 > Project: Maven Shared Components > Issue Type: Improvement > Components: maven-dependency-analyzer >Affects Versions: maven-dependency-analyzer-1.13.2 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: maven-dependency-analyzer-1.13.3 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MSHARED-1332) Usage of bom instead of single dependencies
[ https://issues.apache.org/jira/browse/MSHARED-1332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise closed MSHARED-1332. Resolution: Done > Usage of bom instead of single dependencies > --- > > Key: MSHARED-1332 > URL: https://issues.apache.org/jira/browse/MSHARED-1332 > Project: Maven Shared Components > Issue Type: Improvement > Components: maven-dependency-analyzer >Affects Versions: maven-dependency-analyzer-1.13.2 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: maven-dependency-analyzer-1.13.3 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MSHARED-1333) Upgrade maven-shared-components to version 40
Karl Heinz Marbaise created MSHARED-1333: Summary: Upgrade maven-shared-components to version 40 Key: MSHARED-1333 URL: https://issues.apache.org/jira/browse/MSHARED-1333 Project: Maven Shared Components Issue Type: Improvement Components: maven-dependency-tree Affects Versions: maven-dependency-tree-3.2.1 Reporter: Karl Heinz Marbaise Assignee: Karl Heinz Marbaise Fix For: maven-dependency-tree-3.2.2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MSHARED-1332) Usage of bom instead of single dependencies
Karl Heinz Marbaise created MSHARED-1332: Summary: Usage of bom instead of single dependencies Key: MSHARED-1332 URL: https://issues.apache.org/jira/browse/MSHARED-1332 Project: Maven Shared Components Issue Type: Improvement Components: maven-dependency-analyzer Affects Versions: maven-dependency-analyzer-1.13.2 Reporter: Karl Heinz Marbaise Assignee: Karl Heinz Marbaise Fix For: maven-dependency-analyzer-1.13.3 -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [EXPERIMENT] Jetty transport [maven-resolver]
cstamas closed pull request #225: [EXPERIMENT] Jetty transport URL: https://github.com/apache/maven-resolver/pull/225 -- 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: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Bump hazelcast from 5.1.4 to 5.3.0 in /maven-resolver-named-locks-hazelcast [maven-resolver]
dependabot[bot] closed pull request #287: Bump hazelcast from 5.1.4 to 5.3.0 in /maven-resolver-named-locks-hazelcast URL: https://github.com/apache/maven-resolver/pull/287 -- 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: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Bump hazelcast from 5.1.4 to 5.3.0 in /maven-resolver-named-locks-hazelcast [maven-resolver]
dependabot[bot] commented on PR #287: URL: https://github.com/apache/maven-resolver/pull/287#issuecomment-1804891476 Looks like com.hazelcast:hazelcast is up-to-date now, so this is no longer needed. -- 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: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Bump hazelcast from 5.1.4 to 5.3.0 in /maven-resolver-named-locks-hazelcast [maven-resolver]
cstamas commented on PR #287: URL: https://github.com/apache/maven-resolver/pull/287#issuecomment-1804891140 @dependabot rebase -- 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: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Improve transfer listener speed [maven]
cstamas commented on PR #1302: URL: https://github.com/apache/maven/pull/1302#issuecomment-1804884501 +1 but no change detected... built master with master vs this PR, pretty much same result (build time) -- 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: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[PR] Improve transfer listener speed [maven]
gnodet opened a new pull request, #1302: URL: https://github.com/apache/maven/pull/1302 - Try to improve concurrency - Delegate display to a single thread - Disable test which is broken with new logic -- 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: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MRESOLVER-302) Introduce onSession close
[ https://issues.apache.org/jira/browse/MRESOLVER-302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17784627#comment-17784627 ] ASF GitHub Bot commented on MRESOLVER-302: -- cstamas merged PR #360: URL: https://github.com/apache/maven-resolver/pull/360 > Introduce onSession close > - > > Key: MRESOLVER-302 > URL: https://issues.apache.org/jira/browse/MRESOLVER-302 > Project: Maven Resolver > Issue Type: Improvement > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 2.0.0 > > > The on session close callback, revisited. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MRESOLVER-302] Addendum [maven-resolver]
cstamas merged PR #360: URL: https://github.com/apache/maven-resolver/pull/360 -- 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: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7899) Various memory usage improvements
[
https://issues.apache.org/jira/browse/MNG-7899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17784626#comment-17784626
]
ASF GitHub Bot commented on MNG-7899:
-
gnodet merged PR #1296:
URL: https://github.com/apache/maven/pull/1296
> Various memory usage improvements
> -
>
> Key: MNG-7899
> URL: https://issues.apache.org/jira/browse/MNG-7899
> Project: Maven
> Issue Type: Improvement
> Components: Design, Patterns & Best Practices, Embedding,
> General, Logging
>Affects Versions: 4.0.0-alpha-2
>Reporter: sebastien
>Priority: Major
>
> Some optimisations can be applied to the code to reduce the use of temporary
> objects.
> Typical improvements identified are:
> * reduce scope of temporary objects creation to avoid creating when not
> needed. Example :
> {code:java}
> public String toString() {
> StringBuilder sb = new StringBuilder(512);
> if (isEmpty()) {
> return "empty";
> }
> for (MetadataGraphVertex v : vertices) {
> .{code}
> can be replaced by
> {code:java}
> public String toString() {
> if (isEmpty()) {
> return "empty";
> }
> StringBuilder sb = new StringBuilder(512);
> for (MetadataGraphVertex v : vertices) {
> .{code}
> * Reuse StringBuilder objects in loops by setting its length to zero
> * Use the StringBuilder.append() with index to avoid String.substring().
> Example:
>
> {code:java}
> int idx = resourceName.lastIndexOf('/');
> buffer.append(idx < 0 ? resourceName : resourceName.substring(idx + 1));
> {code}
> can be replaced by
>
> {code:java}
> int idx = resourceName.lastIndexOf('/');
> if (idx < 0) {
> buffer.append(resourceName);
> } else {
> buffer.append(resourceName, idx + 1, resourceName.length());
> } {code}
>
>
> * Replace dynamic string creation static constants when possible
> * Avoid creating temporary strings with + operator when the final
> destination can be used instead, like PrintStream.print() method
> * Avoir using StringBuilder.append() method and util method MessageUtils.a()
> when the final destination can be used instead, like PrintStream.print()
> method
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MNG-7899] Various memory usage improvements 4-1 [maven]
gnodet merged PR #1296: URL: https://github.com/apache/maven/pull/1296 -- 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: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MSHARED-1331) Upgrade maven-shared-parent to version 40
[ https://issues.apache.org/jira/browse/MSHARED-1331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17784622#comment-17784622 ] Karl Heinz Marbaise commented on MSHARED-1331: -- Done in [07a2d3939ac17dc8e308bf50d682d40aeafe3e98|https://gitbox.apache.org/repos/asf?p=maven-dependency-analyzer.git;a=commitdiff;h=07a2d3939ac17dc8e308bf50d682d40aeafe3e98] > Upgrade maven-shared-parent to version 40 > - > > Key: MSHARED-1331 > URL: https://issues.apache.org/jira/browse/MSHARED-1331 > Project: Maven Shared Components > Issue Type: Improvement > Components: maven-dependency-analyzer >Affects Versions: maven-dependency-analyzer-1.13.2 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: maven-dependency-analyzer-1.13.3 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MSHARED-1331) Upgrade maven-shared-parent to version 40
[ https://issues.apache.org/jira/browse/MSHARED-1331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise closed MSHARED-1331. Resolution: Done > Upgrade maven-shared-parent to version 40 > - > > Key: MSHARED-1331 > URL: https://issues.apache.org/jira/browse/MSHARED-1331 > Project: Maven Shared Components > Issue Type: Improvement > Components: maven-dependency-analyzer >Affects Versions: maven-dependency-analyzer-1.13.2 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: maven-dependency-analyzer-1.13.3 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MSHARED-1331) Upgrade maven-shared-parent to version 40
[ https://issues.apache.org/jira/browse/MSHARED-1331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise reassigned MSHARED-1331: Assignee: Karl Heinz Marbaise > Upgrade maven-shared-parent to version 40 > - > > Key: MSHARED-1331 > URL: https://issues.apache.org/jira/browse/MSHARED-1331 > Project: Maven Shared Components > Issue Type: Improvement > Components: maven-dependency-analyzer >Affects Versions: maven-dependency-analyzer-1.13.2 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: maven-dependency-analyzer-1.13.3 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MSHARED-1331) Upgrade maven-shared-parent to version 40
Karl Heinz Marbaise created MSHARED-1331: Summary: Upgrade maven-shared-parent to version 40 Key: MSHARED-1331 URL: https://issues.apache.org/jira/browse/MSHARED-1331 Project: Maven Shared Components Issue Type: Improvement Components: maven-dependency-analyzer Affects Versions: maven-dependency-analyzer-1.13.2 Reporter: Karl Heinz Marbaise Fix For: maven-dependency-analyzer-1.13.3 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-302) Introduce onSession close
[
https://issues.apache.org/jira/browse/MRESOLVER-302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17784612#comment-17784612
]
ASF GitHub Bot commented on MRESOLVER-302:
--
gnodet commented on code in PR #360:
URL: https://github.com/apache/maven-resolver/pull/360#discussion_r1388076564
##
maven-resolver-api/src/main/java/org/eclipse/aether/RepositorySystemSession.java:
##
@@ -88,12 +88,18 @@ interface CloseableRepositorySystemSession extends
RepositorySystemSession, Clos
}
/**
- * Builder for building {@link CloseableRepositorySystemSession}
instances. Builder instances can be created with
+ * Builder for building {@link CloseableSession} instances. Builder
instances can be created with
* {@link RepositorySystem#createSessionBuilder()} method.
+ *
+ * Note: while this interface extend {@link RepositorySystemSession}, it
should NOT be used as such, it is just
+ * a helper ability, to make possible uses like {@link
#withLocalRepository(File)} method is, where
+ * "chicken or egg" situation would appear (you need session for
not-yet-built session). This class is NOT
+ * immutable nor thread safe. It is highly recommended that upon
configuring builder is done, invoke
+ * {@link #build()} method and use resulting immutable session
throughout your code.
*
* @since TBD
*/
-interface SessionBuilder {
+interface SessionBuilder extends RepositorySystemSession {
Review Comment:
I think this part can be moved to the DefaultSessionBuilder.
##
maven-resolver-api/src/main/java/org/eclipse/aether/RepositorySystemSession.java:
##
@@ -386,12 +393,48 @@ interface SessionBuilder {
SessionBuilder setCache(RepositoryCache cache);
/**
- * Shortcut method to set up local repository manager.
+ * Shortcut method to set up local repository manager directly onto
builder. There must be at least one non-null
+ * {@link File} passed in this method. In case multiple files, session
builder will use chained local repository
+ * manager.
+ *
+ * @param basedir The local repository base directories.
+ * @return This session for chaining, never {@code null}.
+ * @see #newLocalRepositoryManager(LocalRepository...)
+ */
+SessionBuilder withLocalRepositoryBasedir(File... basedir);
Review Comment:
rename to `setLocalRepositoryBasedirs(File... basedirs)`
##
maven-resolver-api/src/main/java/org/eclipse/aether/RepositorySystemSession.java:
##
@@ -386,12 +393,48 @@ interface SessionBuilder {
SessionBuilder setCache(RepositoryCache cache);
/**
- * Shortcut method to set up local repository manager.
+ * Shortcut method to set up local repository manager directly onto
builder. There must be at least one non-null
+ * {@link File} passed in this method. In case multiple files, session
builder will use chained local repository
+ * manager.
+ *
+ * @param basedir The local repository base directories.
+ * @return This session for chaining, never {@code null}.
+ * @see #newLocalRepositoryManager(LocalRepository...)
+ */
+SessionBuilder withLocalRepositoryBasedir(File... basedir);
+
+/**
+ * Shortcut method to set up local repository manager directly onto
builder. There must be at least one non-null
+ * {@link File} present in passed in list. In case multiple files,
session builder will use chained local
+ * repository manager.
*
- * @param basedir The local repository base directory, may be {@code
null} if none.
+ * @param basedir The local repository base directories.
* @return This session for chaining, never {@code null}.
+ * @see #newLocalRepositoryManager(LocalRepository...)
*/
-SessionBuilder withLocalRepository(File basedir);
+SessionBuilder withLocalRepositoryBasedir(List basedir);
+
+/**
+ * Shortcut method to set up local repository manager directly onto
builder. There must be at least one non-null
+ * {@link LocalRepository} passed in this method. In case multiple
local repositories, session builder will
+ * use chained local repository manager.
+ *
+ * @param localRepository The local repositories.
+ * @return This session for chaining, never {@code null}.
+ * @see #newLocalRepositoryManager(LocalRepository...)
+ */
+SessionBuilder withLocalRepository(LocalRepository... localRepository);
+
+/**
+ * Shortcut method to set up local repository manager directly onto
builder. There must be at least one non-null
+ * {@link LocalRepository} present in passed in list. In case multiple
local repositories, se
Re: [PR] [MRESOLVER-302] Addendum [maven-resolver]
gnodet commented on code in PR #360:
URL: https://github.com/apache/maven-resolver/pull/360#discussion_r1388076564
##
maven-resolver-api/src/main/java/org/eclipse/aether/RepositorySystemSession.java:
##
@@ -88,12 +88,18 @@ interface CloseableRepositorySystemSession extends
RepositorySystemSession, Clos
}
/**
- * Builder for building {@link CloseableRepositorySystemSession}
instances. Builder instances can be created with
+ * Builder for building {@link CloseableSession} instances. Builder
instances can be created with
* {@link RepositorySystem#createSessionBuilder()} method.
+ *
+ * Note: while this interface extend {@link RepositorySystemSession}, it
should NOT be used as such, it is just
+ * a helper ability, to make possible uses like {@link
#withLocalRepository(File)} method is, where
+ * "chicken or egg" situation would appear (you need session for
not-yet-built session). This class is NOT
+ * immutable nor thread safe. It is highly recommended that upon
configuring builder is done, invoke
+ * {@link #build()} method and use resulting immutable session
throughout your code.
*
* @since TBD
*/
-interface SessionBuilder {
+interface SessionBuilder extends RepositorySystemSession {
Review Comment:
I think this part can be moved to the DefaultSessionBuilder.
##
maven-resolver-api/src/main/java/org/eclipse/aether/RepositorySystemSession.java:
##
@@ -386,12 +393,48 @@ interface SessionBuilder {
SessionBuilder setCache(RepositoryCache cache);
/**
- * Shortcut method to set up local repository manager.
+ * Shortcut method to set up local repository manager directly onto
builder. There must be at least one non-null
+ * {@link File} passed in this method. In case multiple files, session
builder will use chained local repository
+ * manager.
+ *
+ * @param basedir The local repository base directories.
+ * @return This session for chaining, never {@code null}.
+ * @see #newLocalRepositoryManager(LocalRepository...)
+ */
+SessionBuilder withLocalRepositoryBasedir(File... basedir);
Review Comment:
rename to `setLocalRepositoryBasedirs(File... basedirs)`
##
maven-resolver-api/src/main/java/org/eclipse/aether/RepositorySystemSession.java:
##
@@ -386,12 +393,48 @@ interface SessionBuilder {
SessionBuilder setCache(RepositoryCache cache);
/**
- * Shortcut method to set up local repository manager.
+ * Shortcut method to set up local repository manager directly onto
builder. There must be at least one non-null
+ * {@link File} passed in this method. In case multiple files, session
builder will use chained local repository
+ * manager.
+ *
+ * @param basedir The local repository base directories.
+ * @return This session for chaining, never {@code null}.
+ * @see #newLocalRepositoryManager(LocalRepository...)
+ */
+SessionBuilder withLocalRepositoryBasedir(File... basedir);
+
+/**
+ * Shortcut method to set up local repository manager directly onto
builder. There must be at least one non-null
+ * {@link File} present in passed in list. In case multiple files,
session builder will use chained local
+ * repository manager.
*
- * @param basedir The local repository base directory, may be {@code
null} if none.
+ * @param basedir The local repository base directories.
* @return This session for chaining, never {@code null}.
+ * @see #newLocalRepositoryManager(LocalRepository...)
*/
-SessionBuilder withLocalRepository(File basedir);
+SessionBuilder withLocalRepositoryBasedir(List basedir);
+
+/**
+ * Shortcut method to set up local repository manager directly onto
builder. There must be at least one non-null
+ * {@link LocalRepository} passed in this method. In case multiple
local repositories, session builder will
+ * use chained local repository manager.
+ *
+ * @param localRepository The local repositories.
+ * @return This session for chaining, never {@code null}.
+ * @see #newLocalRepositoryManager(LocalRepository...)
+ */
+SessionBuilder withLocalRepository(LocalRepository... localRepository);
+
+/**
+ * Shortcut method to set up local repository manager directly onto
builder. There must be at least one non-null
+ * {@link LocalRepository} present in passed in list. In case multiple
local repositories, session builder will
+ * use chained local repository manager.
+ *
+ * @param basedir The local repository base directories.
+ * @return This session for chaining, never {@code null}.
+ * @see #newLocalRepositoryManager(LocalR
Re: [PR] [MNG-7648] Fix locationTracking in DefaultModelBuildingRequest copy constructor. [maven]
hazendaz commented on PR #940: URL: https://github.com/apache/maven/pull/940#issuecomment-1804183734 Sorry never got around to opening a ticket on this but tried out alpha 8, it works perfect now. Confirmed with java 11, 17, and 21. No issues. So whatever was wrong was magically fixed ;) -- 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: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7648) Generated model reader is not setting location information
[
https://issues.apache.org/jira/browse/MNG-7648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17784545#comment-17784545
]
ASF GitHub Bot commented on MNG-7648:
-
hazendaz commented on PR #940:
URL: https://github.com/apache/maven/pull/940#issuecomment-1804183734
Sorry never got around to opening a ticket on this but tried out alpha 8, it
works perfect now. Confirmed with java 11, 17, and 21. No issues. So
whatever was wrong was magically fixed ;)
> Generated model reader is not setting location information
> --
>
> Key: MNG-7648
> URL: https://issues.apache.org/jira/browse/MNG-7648
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.8.7, 4.0.0-alpha-3
>Reporter: Pavel Horal
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.8.8, 3.9.0, 4.0.0-alpha-4, 4.0.0
>
>
> -Generated model reader is not setting {{location}} property -
> [https://github.com/apache/maven/blob/e73a0b00fde80c400a6d854ec0c2ba7436325eed/maven-toolchain-model/src/main/mdo/reader.vm#L683]
> .-
> Project model does not have location property in plugin execution (potential
> issue when merging model parent configuration?). This causes issues for
> example in Maven Enforcer Plugin which uses this information (see
> [MENFORCER-447|https://issues.apache.org/jira/browse/MENFORCER-447?focusedCommentId=17651671&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17651671]).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MSHADE-406) relocated multi-release classes aren't moved to a new directory
[
https://issues.apache.org/jira/browse/MSHADE-406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17784516#comment-17784516
]
ASF GitHub Bot commented on MSHADE-406:
---
nielsbasjes commented on PR #202:
URL:
https://github.com/apache/maven-shade-plugin/pull/202#issuecomment-1804054638
Next hurdle: Almost all of the code assumes the name of the class file is
the same as the package+class name.
> relocated multi-release classes aren't moved to a new directory
> ---
>
> Key: MSHADE-406
> URL: https://issues.apache.org/jira/browse/MSHADE-406
> Project: Maven Shade Plugin
> Issue Type: Bug
>Reporter: Brian Gruber
>Priority: Major
>
> In a project in which a dependency has a multi-release jar, classes that
> match a relocation pattern and are in the {{META-INF/versions}} directories
> are not moved to the new directory structure. They are, however, rewritten so
> that the class file itself specifies the new package name.
> Sample project:
> [https://gist.github.com/bgruber/5fb045759505da5150d3e93ec5c6010e]
> The generated jar file still contains classes like this:
> {code:java}
> $ jar tf target/relocation-test-SNAPSHOT-1.0.jar | grep versions | head
> META-INF/versions/
> META-INF/versions/9/
> META-INF/versions/9/org/
> META-INF/versions/9/org/bouncycastle/
> META-INF/versions/9/org/bouncycastle/crypto/
> META-INF/versions/9/org/bouncycastle/crypto/AsymmetricCipherKeyPair.class
> META-INF/versions/9/org/bouncycastle/crypto/Digest.class
> META-INF/versions/9/org/bouncycastle/crypto/CryptoServicesRegistrar$Property.class
> META-INF/versions/9/org/bouncycastle/crypto/CryptoServicesRegistrar.class
> META-INF/versions/9/org/bouncycastle/crypto/KeyGenerationParameters.class{code}
> I expect these class files to be under
> {{META-INF/versions/9/com/dd/org/bouncycastle}}. Extracting one of them from
> the jar and examining it, the class file does appear to have been modified to
> have the new package name:
> {code:java}
> $ jar xf target/relocation-test-SNAPSHOT-1.0.jar
> META-INF/versions/9/org/bouncycastle/crypto/Digest.class
> $ javap META-INF/versions/9/org/bouncycastle/crypto/Digest.class
> Compiled from "Digest.java"
> public interface com.dd.org.bouncycastle.crypto.Digest {
> public abstract java.lang.String getAlgorithmName();
> public abstract int getDigestSize();
> public abstract void update(byte);
> public abstract void update(byte[], int, int);
> public abstract int doFinal(byte[], int);
> public abstract void reset();
> }{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MSHADE-406] Support multi release jars [maven-shade-plugin]
nielsbasjes commented on PR #202: URL: https://github.com/apache/maven-shade-plugin/pull/202#issuecomment-1804054638 Next hurdle: Almost all of the code assumes the name of the class file is the same as the package+class name. -- 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: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7899) Various memory usage improvements
[
https://issues.apache.org/jira/browse/MNG-7899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17784494#comment-17784494
]
ASF GitHub Bot commented on MNG-7899:
-
sebastien-doyon commented on PR #1296:
URL: https://github.com/apache/maven/pull/1296#issuecomment-1803979760
@gnodet I just fixed a format problem that made the build fail.
> Various memory usage improvements
> -
>
> Key: MNG-7899
> URL: https://issues.apache.org/jira/browse/MNG-7899
> Project: Maven
> Issue Type: Improvement
> Components: Design, Patterns & Best Practices, Embedding,
> General, Logging
>Affects Versions: 4.0.0-alpha-2
>Reporter: sebastien
>Priority: Major
>
> Some optimisations can be applied to the code to reduce the use of temporary
> objects.
> Typical improvements identified are:
> * reduce scope of temporary objects creation to avoid creating when not
> needed. Example :
> {code:java}
> public String toString() {
> StringBuilder sb = new StringBuilder(512);
> if (isEmpty()) {
> return "empty";
> }
> for (MetadataGraphVertex v : vertices) {
> .{code}
> can be replaced by
> {code:java}
> public String toString() {
> if (isEmpty()) {
> return "empty";
> }
> StringBuilder sb = new StringBuilder(512);
> for (MetadataGraphVertex v : vertices) {
> .{code}
> * Reuse StringBuilder objects in loops by setting its length to zero
> * Use the StringBuilder.append() with index to avoid String.substring().
> Example:
>
> {code:java}
> int idx = resourceName.lastIndexOf('/');
> buffer.append(idx < 0 ? resourceName : resourceName.substring(idx + 1));
> {code}
> can be replaced by
>
> {code:java}
> int idx = resourceName.lastIndexOf('/');
> if (idx < 0) {
> buffer.append(resourceName);
> } else {
> buffer.append(resourceName, idx + 1, resourceName.length());
> } {code}
>
>
> * Replace dynamic string creation static constants when possible
> * Avoid creating temporary strings with + operator when the final
> destination can be used instead, like PrintStream.print() method
> * Avoir using StringBuilder.append() method and util method MessageUtils.a()
> when the final destination can be used instead, like PrintStream.print()
> method
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MNG-7899] Various memory usage improvements 4-1 [maven]
sebastien-doyon commented on PR #1296: URL: https://github.com/apache/maven/pull/1296#issuecomment-1803979760 @gnodet I just fixed a format problem that made the build fail. -- 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: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7899) Various memory usage improvements
[
https://issues.apache.org/jira/browse/MNG-7899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17784481#comment-17784481
]
ASF GitHub Bot commented on MNG-7899:
-
sebastien-doyon commented on PR #1296:
URL: https://github.com/apache/maven/pull/1296#issuecomment-1803945482
@gnodet your changes are cleaner. I agree with your contribution, thanks!
> Various memory usage improvements
> -
>
> Key: MNG-7899
> URL: https://issues.apache.org/jira/browse/MNG-7899
> Project: Maven
> Issue Type: Improvement
> Components: Design, Patterns & Best Practices, Embedding,
> General, Logging
>Affects Versions: 4.0.0-alpha-2
>Reporter: sebastien
>Priority: Major
>
> Some optimisations can be applied to the code to reduce the use of temporary
> objects.
> Typical improvements identified are:
> * reduce scope of temporary objects creation to avoid creating when not
> needed. Example :
> {code:java}
> public String toString() {
> StringBuilder sb = new StringBuilder(512);
> if (isEmpty()) {
> return "empty";
> }
> for (MetadataGraphVertex v : vertices) {
> .{code}
> can be replaced by
> {code:java}
> public String toString() {
> if (isEmpty()) {
> return "empty";
> }
> StringBuilder sb = new StringBuilder(512);
> for (MetadataGraphVertex v : vertices) {
> .{code}
> * Reuse StringBuilder objects in loops by setting its length to zero
> * Use the StringBuilder.append() with index to avoid String.substring().
> Example:
>
> {code:java}
> int idx = resourceName.lastIndexOf('/');
> buffer.append(idx < 0 ? resourceName : resourceName.substring(idx + 1));
> {code}
> can be replaced by
>
> {code:java}
> int idx = resourceName.lastIndexOf('/');
> if (idx < 0) {
> buffer.append(resourceName);
> } else {
> buffer.append(resourceName, idx + 1, resourceName.length());
> } {code}
>
>
> * Replace dynamic string creation static constants when possible
> * Avoid creating temporary strings with + operator when the final
> destination can be used instead, like PrintStream.print() method
> * Avoir using StringBuilder.append() method and util method MessageUtils.a()
> when the final destination can be used instead, like PrintStream.print()
> method
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MNG-7899] Various memory usage improvements 4-1 [maven]
sebastien-doyon commented on PR #1296: URL: https://github.com/apache/maven/pull/1296#issuecomment-1803945482 @gnodet your changes are cleaner. I agree with your contribution, thanks! -- 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: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MSHADE-406) relocated multi-release classes aren't moved to a new directory
[
https://issues.apache.org/jira/browse/MSHADE-406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17784476#comment-17784476
]
ASF GitHub Bot commented on MSHADE-406:
---
nielsbasjes commented on PR #202:
URL:
https://github.com/apache/maven-shade-plugin/pull/202#issuecomment-1803939052
Current status: A basic shade and a shade+minimize seem to work.
Relocated does not yet work.
> relocated multi-release classes aren't moved to a new directory
> ---
>
> Key: MSHADE-406
> URL: https://issues.apache.org/jira/browse/MSHADE-406
> Project: Maven Shade Plugin
> Issue Type: Bug
>Reporter: Brian Gruber
>Priority: Major
>
> In a project in which a dependency has a multi-release jar, classes that
> match a relocation pattern and are in the {{META-INF/versions}} directories
> are not moved to the new directory structure. They are, however, rewritten so
> that the class file itself specifies the new package name.
> Sample project:
> [https://gist.github.com/bgruber/5fb045759505da5150d3e93ec5c6010e]
> The generated jar file still contains classes like this:
> {code:java}
> $ jar tf target/relocation-test-SNAPSHOT-1.0.jar | grep versions | head
> META-INF/versions/
> META-INF/versions/9/
> META-INF/versions/9/org/
> META-INF/versions/9/org/bouncycastle/
> META-INF/versions/9/org/bouncycastle/crypto/
> META-INF/versions/9/org/bouncycastle/crypto/AsymmetricCipherKeyPair.class
> META-INF/versions/9/org/bouncycastle/crypto/Digest.class
> META-INF/versions/9/org/bouncycastle/crypto/CryptoServicesRegistrar$Property.class
> META-INF/versions/9/org/bouncycastle/crypto/CryptoServicesRegistrar.class
> META-INF/versions/9/org/bouncycastle/crypto/KeyGenerationParameters.class{code}
> I expect these class files to be under
> {{META-INF/versions/9/com/dd/org/bouncycastle}}. Extracting one of them from
> the jar and examining it, the class file does appear to have been modified to
> have the new package name:
> {code:java}
> $ jar xf target/relocation-test-SNAPSHOT-1.0.jar
> META-INF/versions/9/org/bouncycastle/crypto/Digest.class
> $ javap META-INF/versions/9/org/bouncycastle/crypto/Digest.class
> Compiled from "Digest.java"
> public interface com.dd.org.bouncycastle.crypto.Digest {
> public abstract java.lang.String getAlgorithmName();
> public abstract int getDigestSize();
> public abstract void update(byte);
> public abstract void update(byte[], int, int);
> public abstract int doFinal(byte[], int);
> public abstract void reset();
> }{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MSHADE-406] Support multi release jars [maven-shade-plugin]
nielsbasjes commented on PR #202: URL: https://github.com/apache/maven-shade-plugin/pull/202#issuecomment-1803939052 Current status: A basic shade and a shade+minimize seem to work. Relocated does not yet work. -- 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: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MRESOLVER-302) Introduce onSession close
[ https://issues.apache.org/jira/browse/MRESOLVER-302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17784472#comment-17784472 ] ASF GitHub Bot commented on MRESOLVER-302: -- cstamas opened a new pull request, #360: URL: https://github.com/apache/maven-resolver/pull/360 Changes: * rename closeable session to lessen repetition in source * make builder implement session interface but explain what is the intent here --- https://issues.apache.org/jira/browse/MRESOLVER-302 > Introduce onSession close > - > > Key: MRESOLVER-302 > URL: https://issues.apache.org/jira/browse/MRESOLVER-302 > Project: Maven Resolver > Issue Type: Improvement > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 2.0.0 > > > The on session close callback, revisited. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[PR] [MRESOLVER-302] Addendum [maven-resolver]
cstamas opened a new pull request, #360: URL: https://github.com/apache/maven-resolver/pull/360 Changes: * rename closeable session to lessen repetition in source * make builder implement session interface but explain what is the intent here --- https://issues.apache.org/jira/browse/MRESOLVER-302 -- 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: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7653) Integrate resolver onSessionClose
[ https://issues.apache.org/jira/browse/MNG-7653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17784467#comment-17784467 ] ASF GitHub Bot commented on MNG-7653: - cstamas opened a new pull request, #1301: URL: https://github.com/apache/maven/pull/1301 WIP --- https://issues.apache.org/jira/browse/MNG-7653 > Integrate resolver onSessionClose > - > > Key: MNG-7653 > URL: https://issues.apache.org/jira/browse/MNG-7653 > Project: Maven > Issue Type: Task > Components: Core >Reporter: Tamas Cservenak >Priority: Major > Fix For: 4.0.x-candidate, 4.0.0 > > > Make Maven Core register each session and notify resolver about session ends, > as needed by MRESOLVER-302 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7662) Proxy session scoped components so that they can be injected into singletons beans
[
https://issues.apache.org/jira/browse/MNG-7662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17784457#comment-17784457
]
ASF GitHub Bot commented on MNG-7662:
-
gnodet merged PR #950:
URL: https://github.com/apache/maven/pull/950
> Proxy session scoped components so that they can be injected into singletons
> beans
> --
>
> Key: MNG-7662
> URL: https://issues.apache.org/jira/browse/MNG-7662
> Project: Maven
> Issue Type: Bug
>Reporter: Christoph Läubrich
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: 4.0.0-alpha-9
>
>
> The {{SessionScope}} will now create proxies to wrap beans when there's a
> need to inject a bean while the session scope is not yet available. Such
> proxies require the use of a {{Typed}} annotation, either the
> {{org.eclipse.sisu.Typed}} or {{javax.enterprise.inject.Typed}} annotation,
> to be put on the bean that requires to be wrapped by a proxy.
> {code:java}
> @Named
> static class MySingletonBean {
> @Inject
> BeanItf myBean;
> }
> interface BeanItf {
> Session getSession();
> }
> @SessionScoped
> @Typed
> static class MySessionScopedBean implements BeanItf {
> @Inject
> Session session;
> public Session getSession() {
> return session;
> }
> }
> {code}
> ===
> Original problem:
> Currently DefaultMaven gets the Graphbuilder injected as a strict requirement
> at a very early stage. This leads to the problem, that a GraphBuilder
> implementation can not use any SessionScoped Components (because the session
> scope is not setup yet).
> The error then is
> {code:java}
> 1) Error in custom provider, com.google.inject.OutOfScopeException: Cannot
> access Key[type=org.apache.maven.execution.MavenSession, annotation=[none]]
> outside of a scoping block
> at
> org.apache.maven.session.scope.internal.SessionScopeModule.configure(SessionScopeModule.java:64)
> (via modules: org.eclipse.sisu.wire.WireModule ->
> org.apache.maven.session.scope.internal.SessionScopeModule)
> while locating org.apache.maven.execution.MavenSession
> for the 1st parameter of
> org.eclipse.tycho.helper.PluginRealmHelper.(Unknown Source)
> at ClassRealm[coreExtension>org.eclipse.tycho:tycho-build:${tycho-version},
> parent: ClassRealm[plexus.core, parent: null]] (via modules:
> org.eclipse.sisu.wire.WireModule ->
> org.eclipse.sisu.plexus.PlexusBindingModule)
> while locating org.eclipse.tycho.helper.PluginRealmHelper
> at ClassRealm[coreExtension>org.eclipse.tycho:tycho-build:${tycho-version},
> parent: ClassRealm[plexus.core, parent: null]] (via modules:
> org.eclipse.sisu.wire.WireModule ->
> org.eclipse.sisu.plexus.PlexusBindingModule)
> while locating org.eclipse.tycho.p2maven.InstallableUnitGenerator
> at ClassRealm[coreExtension>org.eclipse.tycho:tycho-build:${tycho-version},
> parent: ClassRealm[plexus.core, parent: null]] (via modules:
> org.eclipse.sisu.wire.WireModule ->
> org.eclipse.sisu.plexus.PlexusBindingModule)
> while locating org.eclipse.tycho.p2maven.MavenProjectDependencyProcessor
> while locating org.eclipse.tycho.build.TychoGraphBuilder
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MNG-7662) Proxy session scoped components so that they can be injected into singletons beans
[
https://issues.apache.org/jira/browse/MNG-7662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet closed MNG-7662.
Resolution: Fixed
> Proxy session scoped components so that they can be injected into singletons
> beans
> --
>
> Key: MNG-7662
> URL: https://issues.apache.org/jira/browse/MNG-7662
> Project: Maven
> Issue Type: Bug
>Reporter: Christoph Läubrich
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: 4.0.0-alpha-9
>
>
> The {{SessionScope}} will now create proxies to wrap beans when there's a
> need to inject a bean while the session scope is not yet available. Such
> proxies require the use of a {{Typed}} annotation, either the
> {{org.eclipse.sisu.Typed}} or {{javax.enterprise.inject.Typed}} annotation,
> to be put on the bean that requires to be wrapped by a proxy.
> {code:java}
> @Named
> static class MySingletonBean {
> @Inject
> BeanItf myBean;
> }
> interface BeanItf {
> Session getSession();
> }
> @SessionScoped
> @Typed
> static class MySessionScopedBean implements BeanItf {
> @Inject
> Session session;
> public Session getSession() {
> return session;
> }
> }
> {code}
> ===
> Original problem:
> Currently DefaultMaven gets the Graphbuilder injected as a strict requirement
> at a very early stage. This leads to the problem, that a GraphBuilder
> implementation can not use any SessionScoped Components (because the session
> scope is not setup yet).
> The error then is
> {code:java}
> 1) Error in custom provider, com.google.inject.OutOfScopeException: Cannot
> access Key[type=org.apache.maven.execution.MavenSession, annotation=[none]]
> outside of a scoping block
> at
> org.apache.maven.session.scope.internal.SessionScopeModule.configure(SessionScopeModule.java:64)
> (via modules: org.eclipse.sisu.wire.WireModule ->
> org.apache.maven.session.scope.internal.SessionScopeModule)
> while locating org.apache.maven.execution.MavenSession
> for the 1st parameter of
> org.eclipse.tycho.helper.PluginRealmHelper.(Unknown Source)
> at ClassRealm[coreExtension>org.eclipse.tycho:tycho-build:${tycho-version},
> parent: ClassRealm[plexus.core, parent: null]] (via modules:
> org.eclipse.sisu.wire.WireModule ->
> org.eclipse.sisu.plexus.PlexusBindingModule)
> while locating org.eclipse.tycho.helper.PluginRealmHelper
> at ClassRealm[coreExtension>org.eclipse.tycho:tycho-build:${tycho-version},
> parent: ClassRealm[plexus.core, parent: null]] (via modules:
> org.eclipse.sisu.wire.WireModule ->
> org.eclipse.sisu.plexus.PlexusBindingModule)
> while locating org.eclipse.tycho.p2maven.InstallableUnitGenerator
> at ClassRealm[coreExtension>org.eclipse.tycho:tycho-build:${tycho-version},
> parent: ClassRealm[plexus.core, parent: null]] (via modules:
> org.eclipse.sisu.wire.WireModule ->
> org.eclipse.sisu.plexus.PlexusBindingModule)
> while locating org.eclipse.tycho.p2maven.MavenProjectDependencyProcessor
> while locating org.eclipse.tycho.build.TychoGraphBuilder
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MNG-7662] Use proxies for session scoped beans [maven]
gnodet merged PR #950: URL: https://github.com/apache/maven/pull/950 -- 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: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7924) Better control over and better integration with Resolver
[ https://issues.apache.org/jira/browse/MNG-7924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17784449#comment-17784449 ] ASF GitHub Bot commented on MNG-7924: - rmannibucau commented on PR #1299: URL: https://github.com/apache/maven/pull/1299#issuecomment-1803806891 @cstamas one reason I really dislike type vs flags is type is not composable without coding (our limitation of being descriptive in our descriptor/pom - which is a good thing by itself but implies that limitation) whereas it has to be at some point in your examples. Once again, technically we agreed a long time ago but still, users don't understand that, you seems to think they have to and I'd like to avoid them to understand all that. Ultimately it can be a semantic issue (type is not a "common" _type_) but it is a hurting thing in user land and I don't see with your PR which enables to not keep this ambiguity, why we would have to keep using it. Ultimately your PR even enable to define custom "types" in the pom (predefined flags) so user can use it in build pom and then it is published properly with type=extension and flattened flags if desired. > Better control over and better integration with Resolver > > > Key: MNG-7924 > URL: https://issues.apache.org/jira/browse/MNG-7924 > Project: Maven > Issue Type: Task > Components: Artifacts and Repositories >Reporter: Tamas Cservenak >Priority: Major > Fix For: 4.0.0-alpha-9 > > > Integrate better and obtain better control over Resolver. These changes did > stem from "[JPMS module > experiment|https://cwiki.apache.org/confluence/display/MAVEN/Experiment+-+Explicit+JPMS+support]"; > and are considered improvement but *does not implement any functionality* > related to JPMS module support. > Changes: > * Maven4 should stop "disconnected coexistence" of two type systems > (ArtifactHandlers and Resolver ArtifactTypeRegistry), it should unify them. > * Maven4 Core should provide generic and extensible means to introduce new > artifact types (fully in extension, and extension should get extended data > via "roundtrip" in core/resolver) -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MNG-7924] Better control over and better integration with Resolver [maven]
rmannibucau commented on PR #1299: URL: https://github.com/apache/maven/pull/1299#issuecomment-1803806891 @cstamas one reason I really dislike type vs flags is type is not composable without coding (our limitation of being descriptive in our descriptor/pom - which is a good thing by itself but implies that limitation) whereas it has to be at some point in your examples. Once again, technically we agreed a long time ago but still, users don't understand that, you seems to think they have to and I'd like to avoid them to understand all that. Ultimately it can be a semantic issue (type is not a "common" _type_) but it is a hurting thing in user land and I don't see with your PR which enables to not keep this ambiguity, why we would have to keep using it. Ultimately your PR even enable to define custom "types" in the pom (predefined flags) so user can use it in build pom and then it is published properly with type=extension and flattened flags if desired. -- 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: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] [MNG-7662] Use proxies for session scoped beans [maven]
cstamas commented on PR #950: URL: https://github.com/apache/maven/pull/950#issuecomment-1803792327 Ah, true, yes, proxies are ONLY about interfaces kk -- 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: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7662) Proxy session scoped components so that they can be injected into singletons beans
[
https://issues.apache.org/jira/browse/MNG-7662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17784442#comment-17784442
]
ASF GitHub Bot commented on MNG-7662:
-
cstamas commented on PR #950:
URL: https://github.com/apache/maven/pull/950#issuecomment-1803792327
Ah, true, yes, proxies are ONLY about interfaces kk
> Proxy session scoped components so that they can be injected into singletons
> beans
> --
>
> Key: MNG-7662
> URL: https://issues.apache.org/jira/browse/MNG-7662
> Project: Maven
> Issue Type: Bug
>Reporter: Christoph Läubrich
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: 4.0.0-alpha-9
>
>
> The {{SessionScope}} will now create proxies to wrap beans when there's a
> need to inject a bean while the session scope is not yet available. Such
> proxies require the use of a {{Typed}} annotation, either the
> {{org.eclipse.sisu.Typed}} or {{javax.enterprise.inject.Typed}} annotation,
> to be put on the bean that requires to be wrapped by a proxy.
> {code:java}
> @Named
> static class MySingletonBean {
> @Inject
> BeanItf myBean;
> }
> interface BeanItf {
> Session getSession();
> }
> @SessionScoped
> @Typed
> static class MySessionScopedBean implements BeanItf {
> @Inject
> Session session;
> public Session getSession() {
> return session;
> }
> }
> {code}
> ===
> Original problem:
> Currently DefaultMaven gets the Graphbuilder injected as a strict requirement
> at a very early stage. This leads to the problem, that a GraphBuilder
> implementation can not use any SessionScoped Components (because the session
> scope is not setup yet).
> The error then is
> {code:java}
> 1) Error in custom provider, com.google.inject.OutOfScopeException: Cannot
> access Key[type=org.apache.maven.execution.MavenSession, annotation=[none]]
> outside of a scoping block
> at
> org.apache.maven.session.scope.internal.SessionScopeModule.configure(SessionScopeModule.java:64)
> (via modules: org.eclipse.sisu.wire.WireModule ->
> org.apache.maven.session.scope.internal.SessionScopeModule)
> while locating org.apache.maven.execution.MavenSession
> for the 1st parameter of
> org.eclipse.tycho.helper.PluginRealmHelper.(Unknown Source)
> at ClassRealm[coreExtension>org.eclipse.tycho:tycho-build:${tycho-version},
> parent: ClassRealm[plexus.core, parent: null]] (via modules:
> org.eclipse.sisu.wire.WireModule ->
> org.eclipse.sisu.plexus.PlexusBindingModule)
> while locating org.eclipse.tycho.helper.PluginRealmHelper
> at ClassRealm[coreExtension>org.eclipse.tycho:tycho-build:${tycho-version},
> parent: ClassRealm[plexus.core, parent: null]] (via modules:
> org.eclipse.sisu.wire.WireModule ->
> org.eclipse.sisu.plexus.PlexusBindingModule)
> while locating org.eclipse.tycho.p2maven.InstallableUnitGenerator
> at ClassRealm[coreExtension>org.eclipse.tycho:tycho-build:${tycho-version},
> parent: ClassRealm[plexus.core, parent: null]] (via modules:
> org.eclipse.sisu.wire.WireModule ->
> org.eclipse.sisu.plexus.PlexusBindingModule)
> while locating org.eclipse.tycho.p2maven.MavenProjectDependencyProcessor
> while locating org.eclipse.tycho.build.TychoGraphBuilder
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7662) Proxy session scoped components so that they can be injected into singletons beans
[
https://issues.apache.org/jira/browse/MNG-7662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17784440#comment-17784440
]
ASF GitHub Bot commented on MNG-7662:
-
gnodet commented on PR #950:
URL: https://github.com/apache/maven/pull/950#issuecomment-1803785911
> Why is `@Typed` required? It has a serious side effect in Sisu regarding
how bean is bound...
Oh, yes. That's actually the semantics that we need. The goal is to make
sure the proxied bean is exposed only with interfaces. So we need `@Typed` in
order to make sure it will be injected properly.
I experimented with adding an interface list to `@SessionScoped`, but then,
if the injection point was using the actual implementation class instead of an
interface, the injection would fail without a proper explanation (just that
setting the field did not work, but not with a ClassCastException or anything
that could give a hint).
> Proxy session scoped components so that they can be injected into singletons
> beans
> --
>
> Key: MNG-7662
> URL: https://issues.apache.org/jira/browse/MNG-7662
> Project: Maven
> Issue Type: Bug
>Reporter: Christoph Läubrich
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: 4.0.0-alpha-9
>
>
> The {{SessionScope}} will now create proxies to wrap beans when there's a
> need to inject a bean while the session scope is not yet available. Such
> proxies require the use of a {{Typed}} annotation, either the
> {{org.eclipse.sisu.Typed}} or {{javax.enterprise.inject.Typed}} annotation,
> to be put on the bean that requires to be wrapped by a proxy.
> {code:java}
> @Named
> static class MySingletonBean {
> @Inject
> BeanItf myBean;
> }
> interface BeanItf {
> Session getSession();
> }
> @SessionScoped
> @Typed
> static class MySessionScopedBean implements BeanItf {
> @Inject
> Session session;
> public Session getSession() {
> return session;
> }
> }
> {code}
> ===
> Original problem:
> Currently DefaultMaven gets the Graphbuilder injected as a strict requirement
> at a very early stage. This leads to the problem, that a GraphBuilder
> implementation can not use any SessionScoped Components (because the session
> scope is not setup yet).
> The error then is
> {code:java}
> 1) Error in custom provider, com.google.inject.OutOfScopeException: Cannot
> access Key[type=org.apache.maven.execution.MavenSession, annotation=[none]]
> outside of a scoping block
> at
> org.apache.maven.session.scope.internal.SessionScopeModule.configure(SessionScopeModule.java:64)
> (via modules: org.eclipse.sisu.wire.WireModule ->
> org.apache.maven.session.scope.internal.SessionScopeModule)
> while locating org.apache.maven.execution.MavenSession
> for the 1st parameter of
> org.eclipse.tycho.helper.PluginRealmHelper.(Unknown Source)
> at ClassRealm[coreExtension>org.eclipse.tycho:tycho-build:${tycho-version},
> parent: ClassRealm[plexus.core, parent: null]] (via modules:
> org.eclipse.sisu.wire.WireModule ->
> org.eclipse.sisu.plexus.PlexusBindingModule)
> while locating org.eclipse.tycho.helper.PluginRealmHelper
> at ClassRealm[coreExtension>org.eclipse.tycho:tycho-build:${tycho-version},
> parent: ClassRealm[plexus.core, parent: null]] (via modules:
> org.eclipse.sisu.wire.WireModule ->
> org.eclipse.sisu.plexus.PlexusBindingModule)
> while locating org.eclipse.tycho.p2maven.InstallableUnitGenerator
> at ClassRealm[coreExtension>org.eclipse.tycho:tycho-build:${tycho-version},
> parent: ClassRealm[plexus.core, parent: null]] (via modules:
> org.eclipse.sisu.wire.WireModule ->
> org.eclipse.sisu.plexus.PlexusBindingModule)
> while locating org.eclipse.tycho.p2maven.MavenProjectDependencyProcessor
> while locating org.eclipse.tycho.build.TychoGraphBuilder
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MNG-7662] Use proxies for session scoped beans [maven]
gnodet commented on PR #950: URL: https://github.com/apache/maven/pull/950#issuecomment-1803785911 > Why is `@Typed` required? It has a serious side effect in Sisu regarding how bean is bound... Oh, yes. That's actually the semantics that we need. The goal is to make sure the proxied bean is exposed only with interfaces. So we need `@Typed` in order to make sure it will be injected properly. I experimented with adding an interface list to `@SessionScoped`, but then, if the injection point was using the actual implementation class instead of an interface, the injection would fail without a proper explanation (just that setting the field did not work, but not with a ClassCastException or anything that could give a hint). -- 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: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (MNG-7662) Proxy session scoped components so that they can be injected into singletons beans
[
https://issues.apache.org/jira/browse/MNG-7662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet updated MNG-7662:
-
Description:
The {{SessionScope}} will now create proxies to wrap beans when there's a need
to inject a bean while the session scope is not yet available. Such proxies
require the use of a {{Typed}} annotation, either the
{{org.eclipse.sisu.Typed}} or {{javax.enterprise.inject.Typed}} annotation, to
be put on the bean that requires to be wrapped by a proxy.
{code:java}
@Named
static class MySingletonBean {
@Inject
BeanItf myBean;
}
interface BeanItf {
Session getSession();
}
@SessionScoped
@Typed
static class MySessionScopedBean implements BeanItf {
@Inject
Session session;
public Session getSession() {
return session;
}
}
{code}
===
Original problem:
Currently DefaultMaven gets the Graphbuilder injected as a strict requirement
at a very early stage. This leads to the problem, that a GraphBuilder
implementation can not use any SessionScoped Components (because the session
scope is not setup yet).
The error then is
{code:java}
1) Error in custom provider, com.google.inject.OutOfScopeException: Cannot
access Key[type=org.apache.maven.execution.MavenSession, annotation=[none]]
outside of a scoping block
at
org.apache.maven.session.scope.internal.SessionScopeModule.configure(SessionScopeModule.java:64)
(via modules: org.eclipse.sisu.wire.WireModule ->
org.apache.maven.session.scope.internal.SessionScopeModule)
while locating org.apache.maven.execution.MavenSession
for the 1st parameter of
org.eclipse.tycho.helper.PluginRealmHelper.(Unknown Source)
at ClassRealm[coreExtension>org.eclipse.tycho:tycho-build:${tycho-version},
parent: ClassRealm[plexus.core, parent: null]] (via modules:
org.eclipse.sisu.wire.WireModule -> org.eclipse.sisu.plexus.PlexusBindingModule)
while locating org.eclipse.tycho.helper.PluginRealmHelper
at ClassRealm[coreExtension>org.eclipse.tycho:tycho-build:${tycho-version},
parent: ClassRealm[plexus.core, parent: null]] (via modules:
org.eclipse.sisu.wire.WireModule -> org.eclipse.sisu.plexus.PlexusBindingModule)
while locating org.eclipse.tycho.p2maven.InstallableUnitGenerator
at ClassRealm[coreExtension>org.eclipse.tycho:tycho-build:${tycho-version},
parent: ClassRealm[plexus.core, parent: null]] (via modules:
org.eclipse.sisu.wire.WireModule -> org.eclipse.sisu.plexus.PlexusBindingModule)
while locating org.eclipse.tycho.p2maven.MavenProjectDependencyProcessor
while locating org.eclipse.tycho.build.TychoGraphBuilder
{code}
was:
The {{SessionScope}} will now create proxies to wrap beans when there's a need
to inject a bean while the session scope is not yet available. Such proxies
require the use of a {{Typed}} annotation, either the
{{org.eclipse.sisu.Typed}} or {{javax.enterprise.inject.Typed}} annotation, to
be put on the bean that requires to be wrapped by a proxy.
{code:java}
@Named
static class MySingletonBean {
@Inject
BeanItf myBean;
}
interface BeanItf {
Session getSession();
}
@SessionScoped
@Typed
static class MySessionScopedBean implements BeanItf {
@Inject
Session session;
public Session getSession() {
return session;
}
}
{code}
===
Currently DefaultMaven gets the Graphbuilder injected as a strict requirement
at a very early stage. This leads to the problem, that a GraphBuilder
implementation can not use any SessionScoped Components (because the session
scope is not setup yet).
The error then is
{code:java}
1) Error in custom provider, com.google.inject.OutOfScopeException: Cannot
access Key[type=org.apache.maven.execution.MavenSession, annotation=[none]]
outside of a scoping block
at
org.apache.maven.session.scope.internal.SessionScopeModule.configure(SessionScopeModule.java:64)
(via modules: org.eclipse.sisu.wire.WireModule ->
org.apache.maven.session.scope.internal.SessionScopeModule)
while locating org.apache.maven.execution.MavenSession
for the 1st parameter of
org.eclipse.tycho.helper.PluginRealmHelper.(Unknown Source)
at ClassRealm[coreExtension>org.eclipse.tycho:tycho-build:${tycho-version},
parent: ClassRealm[plexus.core, parent: null]] (via modules:
org.eclipse.sisu.wire.WireModule -> org.eclipse.sisu.plexus.PlexusBindingModule)
while locating org.eclipse.tycho.helper.PluginRealmHelper
at ClassRealm[coreExtension>org.eclipse.tycho:tycho-build:${tycho-version},
parent: ClassRealm[plexus.core, parent: null]] (via modules:
org.eclipse.sisu.wire.WireModule -> org.eclipse.sisu.plexus.PlexusBindingModule)
while locating org.eclipse.tycho.p2maven.InstallableUnitGenerator
at ClassRealm[coreExtension>org.eclipse.tycho:tycho-build:${tycho-version},
parent: ClassRealm[plexus.core,
[jira] [Commented] (MNG-7775) toString method in VersionRange is undocumented and surprising
[ https://issues.apache.org/jira/browse/MNG-7775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17784438#comment-17784438 ] Elliotte Rusty Harold commented on MNG-7775: Optimization doesn't help. Performance is not the issue. The output probably needs to change. > toString method in VersionRange is undocumented and surprising > -- > > Key: MNG-7775 > URL: https://issues.apache.org/jira/browse/MNG-7775 > Project: Maven > Issue Type: Bug >Reporter: Elliotte Rusty Harold >Priority: Minor > > It sometimes returns a single version rather than the full range, though the > only way to see this is by reading the code. I've seen this create confusing > end user messages in enforcer rules. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7662) Proxy session scoped components so that they can be injected into singletons beans
[
https://issues.apache.org/jira/browse/MNG-7662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17784437#comment-17784437
]
ASF GitHub Bot commented on MNG-7662:
-
cstamas commented on PR #950:
URL: https://github.com/apache/maven/pull/950#issuecomment-1803778150
Why is `@Typed` required? It has a serious side effect in Sisu regarding how
bean is bound...
> Proxy session scoped components so that they can be injected into singletons
> beans
> --
>
> Key: MNG-7662
> URL: https://issues.apache.org/jira/browse/MNG-7662
> Project: Maven
> Issue Type: Bug
>Reporter: Christoph Läubrich
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: 4.0.0-alpha-9
>
>
> The {{SessionScope}} will now create proxies to wrap beans when there's a
> need to inject a bean while the session scope is not yet available. Such
> proxies require the use of a {{Typed}} annotation, either the
> {{org.eclipse.sisu.Typed}} or {{javax.enterprise.inject.Typed}} annotation,
> to be put on the bean that requires to be wrapped by a proxy.
> {code:java}
> @Named
> static class MySingletonBean {
> @Inject
> BeanItf myBean;
> }
> interface BeanItf {
> Session getSession();
> }
> @SessionScoped
> @Typed
> static class MySessionScopedBean implements BeanItf {
> @Inject
> Session session;
> public Session getSession() {
> return session;
> }
> }
> {code}
> ===
> Currently DefaultMaven gets the Graphbuilder injected as a strict requirement
> at a very early stage. This leads to the problem, that a GraphBuilder
> implementation can not use any SessionScoped Components (because the session
> scope is not setup yet).
> The error then is
> {code:java}
> 1) Error in custom provider, com.google.inject.OutOfScopeException: Cannot
> access Key[type=org.apache.maven.execution.MavenSession, annotation=[none]]
> outside of a scoping block
> at
> org.apache.maven.session.scope.internal.SessionScopeModule.configure(SessionScopeModule.java:64)
> (via modules: org.eclipse.sisu.wire.WireModule ->
> org.apache.maven.session.scope.internal.SessionScopeModule)
> while locating org.apache.maven.execution.MavenSession
> for the 1st parameter of
> org.eclipse.tycho.helper.PluginRealmHelper.(Unknown Source)
> at ClassRealm[coreExtension>org.eclipse.tycho:tycho-build:${tycho-version},
> parent: ClassRealm[plexus.core, parent: null]] (via modules:
> org.eclipse.sisu.wire.WireModule ->
> org.eclipse.sisu.plexus.PlexusBindingModule)
> while locating org.eclipse.tycho.helper.PluginRealmHelper
> at ClassRealm[coreExtension>org.eclipse.tycho:tycho-build:${tycho-version},
> parent: ClassRealm[plexus.core, parent: null]] (via modules:
> org.eclipse.sisu.wire.WireModule ->
> org.eclipse.sisu.plexus.PlexusBindingModule)
> while locating org.eclipse.tycho.p2maven.InstallableUnitGenerator
> at ClassRealm[coreExtension>org.eclipse.tycho:tycho-build:${tycho-version},
> parent: ClassRealm[plexus.core, parent: null]] (via modules:
> org.eclipse.sisu.wire.WireModule ->
> org.eclipse.sisu.plexus.PlexusBindingModule)
> while locating org.eclipse.tycho.p2maven.MavenProjectDependencyProcessor
> while locating org.eclipse.tycho.build.TychoGraphBuilder
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MNG-7662] Use proxies for session scoped beans [maven]
cstamas commented on PR #950: URL: https://github.com/apache/maven/pull/950#issuecomment-1803778150 Why is `@Typed` required? It has a serious side effect in Sisu regarding how bean is bound... -- 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: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[PR] Clean up dependencies versions [maven]
gnodet opened a new pull request, #1300: URL: https://github.com/apache/maven/pull/1300 Following this checklist to help us incorporate your contribution quickly and easily: - [ ] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MNG) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [ ] Each commit in the pull request should have a meaningful subject line and body. - [ ] Format the pull request title like `[MNG-XXX] SUMMARY`, where you replace `MNG-XXX` and `SUMMARY` with the appropriate JIRA issue. - [ ] Also format the first line of the commit message like `[MNG-XXX] SUMMARY`. Best practice is to use the JIRA issue title in both the pull request title and in the first line of the commit message. - [ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [ ] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [ ] You have run the [Core IT][core-its] successfully. If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [ ] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [ ] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). [core-its]: https://maven.apache.org/core-its/core-it-suite/ -- 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: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Assigned] (MNG-7662) Proxy session scoped components so that they can be injected into singletons beans
[
https://issues.apache.org/jira/browse/MNG-7662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet reassigned MNG-7662:
Assignee: Guillaume Nodet
> Proxy session scoped components so that they can be injected into singletons
> beans
> --
>
> Key: MNG-7662
> URL: https://issues.apache.org/jira/browse/MNG-7662
> Project: Maven
> Issue Type: Bug
>Reporter: Christoph Läubrich
>Assignee: Guillaume Nodet
>Priority: Major
>
> The {{SessionScope}} will now create proxies to wrap beans when there's a
> need to inject a bean while the session scope is not yet available. Such
> proxies require the use of a {{Typed}} annotation, either the
> {{org.eclipse.sisu.Typed}} or {{javax.enterprise.inject.Typed}} annotation,
> to be put on the bean that requires to be wrapped by a proxy.
> {code:java}
> @Named
> static class MySingletonBean {
> @Inject
> BeanItf myBean;
> }
> interface BeanItf {
> Session getSession();
> }
> @SessionScoped
> @Typed
> static class MySessionScopedBean implements BeanItf {
> @Inject
> Session session;
> public Session getSession() {
> return session;
> }
> }
> {code}
> ===
> Currently DefaultMaven gets the Graphbuilder injected as a strict requirement
> at a very early stage. This leads to the problem, that a GraphBuilder
> implementation can not use any SessionScoped Components (because the session
> scope is not setup yet).
> The error then is
> {code:java}
> 1) Error in custom provider, com.google.inject.OutOfScopeException: Cannot
> access Key[type=org.apache.maven.execution.MavenSession, annotation=[none]]
> outside of a scoping block
> at
> org.apache.maven.session.scope.internal.SessionScopeModule.configure(SessionScopeModule.java:64)
> (via modules: org.eclipse.sisu.wire.WireModule ->
> org.apache.maven.session.scope.internal.SessionScopeModule)
> while locating org.apache.maven.execution.MavenSession
> for the 1st parameter of
> org.eclipse.tycho.helper.PluginRealmHelper.(Unknown Source)
> at ClassRealm[coreExtension>org.eclipse.tycho:tycho-build:${tycho-version},
> parent: ClassRealm[plexus.core, parent: null]] (via modules:
> org.eclipse.sisu.wire.WireModule ->
> org.eclipse.sisu.plexus.PlexusBindingModule)
> while locating org.eclipse.tycho.helper.PluginRealmHelper
> at ClassRealm[coreExtension>org.eclipse.tycho:tycho-build:${tycho-version},
> parent: ClassRealm[plexus.core, parent: null]] (via modules:
> org.eclipse.sisu.wire.WireModule ->
> org.eclipse.sisu.plexus.PlexusBindingModule)
> while locating org.eclipse.tycho.p2maven.InstallableUnitGenerator
> at ClassRealm[coreExtension>org.eclipse.tycho:tycho-build:${tycho-version},
> parent: ClassRealm[plexus.core, parent: null]] (via modules:
> org.eclipse.sisu.wire.WireModule ->
> org.eclipse.sisu.plexus.PlexusBindingModule)
> while locating org.eclipse.tycho.p2maven.MavenProjectDependencyProcessor
> while locating org.eclipse.tycho.build.TychoGraphBuilder
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-7662) Proxy session scoped components so that they can be injected into singletons beans
[
https://issues.apache.org/jira/browse/MNG-7662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet updated MNG-7662:
-
Fix Version/s: 4.0.0-alpha-9
> Proxy session scoped components so that they can be injected into singletons
> beans
> --
>
> Key: MNG-7662
> URL: https://issues.apache.org/jira/browse/MNG-7662
> Project: Maven
> Issue Type: Bug
>Reporter: Christoph Läubrich
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: 4.0.0-alpha-9
>
>
> The {{SessionScope}} will now create proxies to wrap beans when there's a
> need to inject a bean while the session scope is not yet available. Such
> proxies require the use of a {{Typed}} annotation, either the
> {{org.eclipse.sisu.Typed}} or {{javax.enterprise.inject.Typed}} annotation,
> to be put on the bean that requires to be wrapped by a proxy.
> {code:java}
> @Named
> static class MySingletonBean {
> @Inject
> BeanItf myBean;
> }
> interface BeanItf {
> Session getSession();
> }
> @SessionScoped
> @Typed
> static class MySessionScopedBean implements BeanItf {
> @Inject
> Session session;
> public Session getSession() {
> return session;
> }
> }
> {code}
> ===
> Currently DefaultMaven gets the Graphbuilder injected as a strict requirement
> at a very early stage. This leads to the problem, that a GraphBuilder
> implementation can not use any SessionScoped Components (because the session
> scope is not setup yet).
> The error then is
> {code:java}
> 1) Error in custom provider, com.google.inject.OutOfScopeException: Cannot
> access Key[type=org.apache.maven.execution.MavenSession, annotation=[none]]
> outside of a scoping block
> at
> org.apache.maven.session.scope.internal.SessionScopeModule.configure(SessionScopeModule.java:64)
> (via modules: org.eclipse.sisu.wire.WireModule ->
> org.apache.maven.session.scope.internal.SessionScopeModule)
> while locating org.apache.maven.execution.MavenSession
> for the 1st parameter of
> org.eclipse.tycho.helper.PluginRealmHelper.(Unknown Source)
> at ClassRealm[coreExtension>org.eclipse.tycho:tycho-build:${tycho-version},
> parent: ClassRealm[plexus.core, parent: null]] (via modules:
> org.eclipse.sisu.wire.WireModule ->
> org.eclipse.sisu.plexus.PlexusBindingModule)
> while locating org.eclipse.tycho.helper.PluginRealmHelper
> at ClassRealm[coreExtension>org.eclipse.tycho:tycho-build:${tycho-version},
> parent: ClassRealm[plexus.core, parent: null]] (via modules:
> org.eclipse.sisu.wire.WireModule ->
> org.eclipse.sisu.plexus.PlexusBindingModule)
> while locating org.eclipse.tycho.p2maven.InstallableUnitGenerator
> at ClassRealm[coreExtension>org.eclipse.tycho:tycho-build:${tycho-version},
> parent: ClassRealm[plexus.core, parent: null]] (via modules:
> org.eclipse.sisu.wire.WireModule ->
> org.eclipse.sisu.plexus.PlexusBindingModule)
> while locating org.eclipse.tycho.p2maven.MavenProjectDependencyProcessor
> while locating org.eclipse.tycho.build.TychoGraphBuilder
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7924) Better control over and better integration with Resolver
[ https://issues.apache.org/jira/browse/MNG-7924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17784435#comment-17784435 ] ASF GitHub Bot commented on MNG-7924: - cstamas commented on PR #1299: URL: https://github.com/apache/maven/pull/1299#issuecomment-1803773056 And a counter example: consider maven-resolver artifacts (!): * uses plain packaging "jar", but * the produced JARs have Sisu index (Sisu DI, JSR330) * the produced JARs have OSGi header (OSGi) * the produced JARs have "Automatic-Module-Name" header (JPMS) It is up to "consumer" how he consumes these things, which (orthogonal) way he makes use of resolver: * on classpath as plain JAR (using RepositorySystemSupplier) * on classpath with Sisu DI (as in Maven) * in OSGi container as bundles * in JPMS app (unsure is it possible, but "metadata" is there) So type is about "consuming", and consumed thing does NOT need to be rebuilt, to consume it as this or that. > Better control over and better integration with Resolver > > > Key: MNG-7924 > URL: https://issues.apache.org/jira/browse/MNG-7924 > Project: Maven > Issue Type: Task > Components: Artifacts and Repositories >Reporter: Tamas Cservenak >Priority: Major > Fix For: 4.0.0-alpha-9 > > > Integrate better and obtain better control over Resolver. These changes did > stem from "[JPMS module > experiment|https://cwiki.apache.org/confluence/display/MAVEN/Experiment+-+Explicit+JPMS+support]"; > and are considered improvement but *does not implement any functionality* > related to JPMS module support. > Changes: > * Maven4 should stop "disconnected coexistence" of two type systems > (ArtifactHandlers and Resolver ArtifactTypeRegistry), it should unify them. > * Maven4 Core should provide generic and extensible means to introduce new > artifact types (fully in extension, and extension should get extended data > via "roundtrip" in core/resolver) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-7662) Proxy session scoped components so that they can be injected into singletons beans
[
https://issues.apache.org/jira/browse/MNG-7662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet updated MNG-7662:
-
Description:
The {{SessionScope}} will now create proxies to wrap beans when there's a need
to inject a bean while the session scope is not yet available. Such proxies
require the use of a {{Typed}} annotation, either the
{{org.eclipse.sisu.Typed}} or {{javax.enterprise.inject.Typed}} annotation, to
be put on the bean that requires to be wrapped by a proxy.
{code:java}
@Named
static class MySingletonBean {
@Inject
BeanItf myBean;
}
interface BeanItf {
Session getSession();
}
@SessionScoped
@Typed
static class MySessionScopedBean implements BeanItf {
@Inject
Session session;
public Session getSession() {
return session;
}
}
{code}
===
Currently DefaultMaven gets the Graphbuilder injected as a strict requirement
at a very early stage. This leads to the problem, that a GraphBuilder
implementation can not use any SessionScoped Components (because the session
scope is not setup yet).
The error then is
{code:java}
1) Error in custom provider, com.google.inject.OutOfScopeException: Cannot
access Key[type=org.apache.maven.execution.MavenSession, annotation=[none]]
outside of a scoping block
at
org.apache.maven.session.scope.internal.SessionScopeModule.configure(SessionScopeModule.java:64)
(via modules: org.eclipse.sisu.wire.WireModule ->
org.apache.maven.session.scope.internal.SessionScopeModule)
while locating org.apache.maven.execution.MavenSession
for the 1st parameter of
org.eclipse.tycho.helper.PluginRealmHelper.(Unknown Source)
at ClassRealm[coreExtension>org.eclipse.tycho:tycho-build:${tycho-version},
parent: ClassRealm[plexus.core, parent: null]] (via modules:
org.eclipse.sisu.wire.WireModule -> org.eclipse.sisu.plexus.PlexusBindingModule)
while locating org.eclipse.tycho.helper.PluginRealmHelper
at ClassRealm[coreExtension>org.eclipse.tycho:tycho-build:${tycho-version},
parent: ClassRealm[plexus.core, parent: null]] (via modules:
org.eclipse.sisu.wire.WireModule -> org.eclipse.sisu.plexus.PlexusBindingModule)
while locating org.eclipse.tycho.p2maven.InstallableUnitGenerator
at ClassRealm[coreExtension>org.eclipse.tycho:tycho-build:${tycho-version},
parent: ClassRealm[plexus.core, parent: null]] (via modules:
org.eclipse.sisu.wire.WireModule -> org.eclipse.sisu.plexus.PlexusBindingModule)
while locating org.eclipse.tycho.p2maven.MavenProjectDependencyProcessor
while locating org.eclipse.tycho.build.TychoGraphBuilder
{code}
was:
The {{SessionScope}} will now create proxies to wrap beans when there's a need
to inject a bean while the session scope is not yet available. Such proxies
require the use of a {{Typed}} annotation, either the
{{org.eclipse.sisu.Typed}} or {{javax.enterprise.inject.Typed}} annotation, to
be put on the bean that requires to be wrapped by a proxy.
{code}
@Named
static class MySingletonBean {
@Inject
BeanItf myBean;
}
interface BeanItf {
Session getSession();
}
@SessionScoped
@Typed(BeanItf.class)
static class MySessionScopedBean implements BeanItf {
@Inject
Session session;
public Session getSession() {
return session;
}
}
{code}
===
Currently DefaultMaven gets the Graphbuilder injected as a strict requirement
at a very early stage. This leads to the problem, that a GraphBuilder
implementation can not use any SessionScoped Components (because the session
scope is not setup yet).
The error then is
{code:java}
1) Error in custom provider, com.google.inject.OutOfScopeException: Cannot
access Key[type=org.apache.maven.execution.MavenSession, annotation=[none]]
outside of a scoping block
at
org.apache.maven.session.scope.internal.SessionScopeModule.configure(SessionScopeModule.java:64)
(via modules: org.eclipse.sisu.wire.WireModule ->
org.apache.maven.session.scope.internal.SessionScopeModule)
while locating org.apache.maven.execution.MavenSession
for the 1st parameter of
org.eclipse.tycho.helper.PluginRealmHelper.(Unknown Source)
at ClassRealm[coreExtension>org.eclipse.tycho:tycho-build:${tycho-version},
parent: ClassRealm[plexus.core, parent: null]] (via modules:
org.eclipse.sisu.wire.WireModule -> org.eclipse.sisu.plexus.PlexusBindingModule)
while locating org.eclipse.tycho.helper.PluginRealmHelper
at ClassRealm[coreExtension>org.eclipse.tycho:tycho-build:${tycho-version},
parent: ClassRealm[plexus.core, parent: null]] (via modules:
org.eclipse.sisu.wire.WireModule -> org.eclipse.sisu.plexus.PlexusBindingModule)
while locating org.eclipse.tycho.p2maven.InstallableUnitGenerator
at ClassRealm[coreExtension>org.eclipse.tycho:tycho-build:${tycho-version},
parent: ClassRealm[plexus.core, par
Re: [PR] [MNG-7924] Better control over and better integration with Resolver [maven]
cstamas commented on PR #1299: URL: https://github.com/apache/maven/pull/1299#issuecomment-1803773056 And a counter example: consider maven-resolver artifacts (!): * uses plain packaging "jar", but * the produced JARs have Sisu index (Sisu DI, JSR330) * the produced JARs have OSGi header (OSGi) * the produced JARs have "Automatic-Module-Name" header (JPMS) It is up to "consumer" how he consumes these things, which (orthogonal) way he makes use of resolver: * on classpath as plain JAR (using RepositorySystemSupplier) * on classpath with Sisu DI (as in Maven) * in OSGi container as bundles * in JPMS app (unsure is it possible, but "metadata" is there) So type is about "consuming", and consumed thing does NOT need to be rebuilt, to consume it as this or that. -- 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: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (MNG-7662) Proxy session scoped components so that they can be injected into singletons beans
[
https://issues.apache.org/jira/browse/MNG-7662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet updated MNG-7662:
-
Description:
The {{SessionScope}} will now create proxies to wrap beans when there's a need
to inject a bean while the session scope is not yet available. Such proxies
require the use of a {{Typed}} annotation, either the
{{org.eclipse.sisu.Typed}} or {{javax.enterprise.inject.Typed}} annotation, to
be put on the bean that requires to be wrapped by a proxy.
{code}
@Named
static class MySingletonBean {
@Inject
BeanItf myBean;
}
interface BeanItf {
Session getSession();
}
@SessionScoped
@Typed(BeanItf.class)
static class MySessionScopedBean implements BeanItf {
@Inject
Session session;
public Session getSession() {
return session;
}
}
{code}
===
Currently DefaultMaven gets the Graphbuilder injected as a strict requirement
at a very early stage. This leads to the problem, that a GraphBuilder
implementation can not use any SessionScoped Components (because the session
scope is not setup yet).
The error then is
{code:java}
1) Error in custom provider, com.google.inject.OutOfScopeException: Cannot
access Key[type=org.apache.maven.execution.MavenSession, annotation=[none]]
outside of a scoping block
at
org.apache.maven.session.scope.internal.SessionScopeModule.configure(SessionScopeModule.java:64)
(via modules: org.eclipse.sisu.wire.WireModule ->
org.apache.maven.session.scope.internal.SessionScopeModule)
while locating org.apache.maven.execution.MavenSession
for the 1st parameter of
org.eclipse.tycho.helper.PluginRealmHelper.(Unknown Source)
at ClassRealm[coreExtension>org.eclipse.tycho:tycho-build:${tycho-version},
parent: ClassRealm[plexus.core, parent: null]] (via modules:
org.eclipse.sisu.wire.WireModule -> org.eclipse.sisu.plexus.PlexusBindingModule)
while locating org.eclipse.tycho.helper.PluginRealmHelper
at ClassRealm[coreExtension>org.eclipse.tycho:tycho-build:${tycho-version},
parent: ClassRealm[plexus.core, parent: null]] (via modules:
org.eclipse.sisu.wire.WireModule -> org.eclipse.sisu.plexus.PlexusBindingModule)
while locating org.eclipse.tycho.p2maven.InstallableUnitGenerator
at ClassRealm[coreExtension>org.eclipse.tycho:tycho-build:${tycho-version},
parent: ClassRealm[plexus.core, parent: null]] (via modules:
org.eclipse.sisu.wire.WireModule -> org.eclipse.sisu.plexus.PlexusBindingModule)
while locating org.eclipse.tycho.p2maven.MavenProjectDependencyProcessor
while locating org.eclipse.tycho.build.TychoGraphBuilder
{code}
was:
The {{SessionScope}} will now create proxies to wrap beans when there's a need
to inject a bean while the session scope is not yet available.
===
Currently DefaultMaven gets the Graphbuilder injected as a strict requirement
at a very early stage. This leads to the problem, that a GraphBuilder
implementation can not use any SessionScoped Components (because the session
scope is not setup yet).
The error then is
{code:java}
1) Error in custom provider, com.google.inject.OutOfScopeException: Cannot
access Key[type=org.apache.maven.execution.MavenSession, annotation=[none]]
outside of a scoping block
at
org.apache.maven.session.scope.internal.SessionScopeModule.configure(SessionScopeModule.java:64)
(via modules: org.eclipse.sisu.wire.WireModule ->
org.apache.maven.session.scope.internal.SessionScopeModule)
while locating org.apache.maven.execution.MavenSession
for the 1st parameter of
org.eclipse.tycho.helper.PluginRealmHelper.(Unknown Source)
at ClassRealm[coreExtension>org.eclipse.tycho:tycho-build:${tycho-version},
parent: ClassRealm[plexus.core, parent: null]] (via modules:
org.eclipse.sisu.wire.WireModule -> org.eclipse.sisu.plexus.PlexusBindingModule)
while locating org.eclipse.tycho.helper.PluginRealmHelper
at ClassRealm[coreExtension>org.eclipse.tycho:tycho-build:${tycho-version},
parent: ClassRealm[plexus.core, parent: null]] (via modules:
org.eclipse.sisu.wire.WireModule -> org.eclipse.sisu.plexus.PlexusBindingModule)
while locating org.eclipse.tycho.p2maven.InstallableUnitGenerator
at ClassRealm[coreExtension>org.eclipse.tycho:tycho-build:${tycho-version},
parent: ClassRealm[plexus.core, parent: null]] (via modules:
org.eclipse.sisu.wire.WireModule -> org.eclipse.sisu.plexus.PlexusBindingModule)
while locating org.eclipse.tycho.p2maven.MavenProjectDependencyProcessor
while locating org.eclipse.tycho.build.TychoGraphBuilder
{code}
> Proxy session scoped components so that they can be injected into singletons
> beans
> --
>
> Key: MNG-7662
> URL: https://issues.apache.org/jira/browse/MNG-7662
> Project: Maven
> Issue Type: Bug
>
[jira] [Updated] (MNG-7662) Proxy session scoped components so that they can be injected into singletons beans
[
https://issues.apache.org/jira/browse/MNG-7662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet updated MNG-7662:
-
Description:
The {{SessionScope}} will now create proxies to wrap beans when there's a need
to inject a bean while the session scope is not yet available.
===
Currently DefaultMaven gets the Graphbuilder injected as a strict requirement
at a very early stage. This leads to the problem, that a GraphBuilder
implementation can not use any SessionScoped Components (because the session
scope is not setup yet).
The error then is
{code:java}
1) Error in custom provider, com.google.inject.OutOfScopeException: Cannot
access Key[type=org.apache.maven.execution.MavenSession, annotation=[none]]
outside of a scoping block
at
org.apache.maven.session.scope.internal.SessionScopeModule.configure(SessionScopeModule.java:64)
(via modules: org.eclipse.sisu.wire.WireModule ->
org.apache.maven.session.scope.internal.SessionScopeModule)
while locating org.apache.maven.execution.MavenSession
for the 1st parameter of
org.eclipse.tycho.helper.PluginRealmHelper.(Unknown Source)
at ClassRealm[coreExtension>org.eclipse.tycho:tycho-build:${tycho-version},
parent: ClassRealm[plexus.core, parent: null]] (via modules:
org.eclipse.sisu.wire.WireModule -> org.eclipse.sisu.plexus.PlexusBindingModule)
while locating org.eclipse.tycho.helper.PluginRealmHelper
at ClassRealm[coreExtension>org.eclipse.tycho:tycho-build:${tycho-version},
parent: ClassRealm[plexus.core, parent: null]] (via modules:
org.eclipse.sisu.wire.WireModule -> org.eclipse.sisu.plexus.PlexusBindingModule)
while locating org.eclipse.tycho.p2maven.InstallableUnitGenerator
at ClassRealm[coreExtension>org.eclipse.tycho:tycho-build:${tycho-version},
parent: ClassRealm[plexus.core, parent: null]] (via modules:
org.eclipse.sisu.wire.WireModule -> org.eclipse.sisu.plexus.PlexusBindingModule)
while locating org.eclipse.tycho.p2maven.MavenProjectDependencyProcessor
while locating org.eclipse.tycho.build.TychoGraphBuilder
{code}
was:
Currently DefaultMaven gets the Graphbuilder injected as a strict requirement
at a very early stage. This leads to the problem, that a GraphBuilder
implementation can not use any SessionScoped Components (because the session
scope is not setup yet).
The error then is
{code:java}
1) Error in custom provider, com.google.inject.OutOfScopeException: Cannot
access Key[type=org.apache.maven.execution.MavenSession, annotation=[none]]
outside of a scoping block
at
org.apache.maven.session.scope.internal.SessionScopeModule.configure(SessionScopeModule.java:64)
(via modules: org.eclipse.sisu.wire.WireModule ->
org.apache.maven.session.scope.internal.SessionScopeModule)
while locating org.apache.maven.execution.MavenSession
for the 1st parameter of
org.eclipse.tycho.helper.PluginRealmHelper.(Unknown Source)
at ClassRealm[coreExtension>org.eclipse.tycho:tycho-build:${tycho-version},
parent: ClassRealm[plexus.core, parent: null]] (via modules:
org.eclipse.sisu.wire.WireModule -> org.eclipse.sisu.plexus.PlexusBindingModule)
while locating org.eclipse.tycho.helper.PluginRealmHelper
at ClassRealm[coreExtension>org.eclipse.tycho:tycho-build:${tycho-version},
parent: ClassRealm[plexus.core, parent: null]] (via modules:
org.eclipse.sisu.wire.WireModule -> org.eclipse.sisu.plexus.PlexusBindingModule)
while locating org.eclipse.tycho.p2maven.InstallableUnitGenerator
at ClassRealm[coreExtension>org.eclipse.tycho:tycho-build:${tycho-version},
parent: ClassRealm[plexus.core, parent: null]] (via modules:
org.eclipse.sisu.wire.WireModule -> org.eclipse.sisu.plexus.PlexusBindingModule)
while locating org.eclipse.tycho.p2maven.MavenProjectDependencyProcessor
while locating org.eclipse.tycho.build.TychoGraphBuilder
{code}
> Proxy session scoped components so that they can be injected into singletons
> beans
> --
>
> Key: MNG-7662
> URL: https://issues.apache.org/jira/browse/MNG-7662
> Project: Maven
> Issue Type: Bug
>Reporter: Christoph Läubrich
>Priority: Major
>
> The {{SessionScope}} will now create proxies to wrap beans when there's a
> need to inject a bean while the session scope is not yet available.
> ===
> Currently DefaultMaven gets the Graphbuilder injected as a strict requirement
> at a very early stage. This leads to the problem, that a GraphBuilder
> implementation can not use any SessionScoped Components (because the session
> scope is not setup yet).
> The error then is
> {code:java}
> 1) Error in custom provider, com.google.inject.OutOfScopeException: Cannot
> access Key[type=org.apache.maven.execution.MavenSession, annotation=[none]]
> outside of a scoping block
> at
> org.apache.maven.session.scope.internal.
[jira] [Updated] (MNG-7662) Proxy session scoped components so that they can be injected into singletons beans
[
https://issues.apache.org/jira/browse/MNG-7662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet updated MNG-7662:
-
Summary: Proxy session scoped components so that they can be injected into
singletons beans (was: Allow Graphbuilder to use session scoped components)
> Proxy session scoped components so that they can be injected into singletons
> beans
> --
>
> Key: MNG-7662
> URL: https://issues.apache.org/jira/browse/MNG-7662
> Project: Maven
> Issue Type: Bug
>Reporter: Christoph Läubrich
>Priority: Major
>
> Currently DefaultMaven gets the Graphbuilder injected as a strict requirement
> at a very early stage. This leads to the problem, that a GraphBuilder
> implementation can not use any SessionScoped Components (because the session
> scope is not setup yet).
> The error then is
> {code:java}
> 1) Error in custom provider, com.google.inject.OutOfScopeException: Cannot
> access Key[type=org.apache.maven.execution.MavenSession, annotation=[none]]
> outside of a scoping block
> at
> org.apache.maven.session.scope.internal.SessionScopeModule.configure(SessionScopeModule.java:64)
> (via modules: org.eclipse.sisu.wire.WireModule ->
> org.apache.maven.session.scope.internal.SessionScopeModule)
> while locating org.apache.maven.execution.MavenSession
> for the 1st parameter of
> org.eclipse.tycho.helper.PluginRealmHelper.(Unknown Source)
> at ClassRealm[coreExtension>org.eclipse.tycho:tycho-build:${tycho-version},
> parent: ClassRealm[plexus.core, parent: null]] (via modules:
> org.eclipse.sisu.wire.WireModule ->
> org.eclipse.sisu.plexus.PlexusBindingModule)
> while locating org.eclipse.tycho.helper.PluginRealmHelper
> at ClassRealm[coreExtension>org.eclipse.tycho:tycho-build:${tycho-version},
> parent: ClassRealm[plexus.core, parent: null]] (via modules:
> org.eclipse.sisu.wire.WireModule ->
> org.eclipse.sisu.plexus.PlexusBindingModule)
> while locating org.eclipse.tycho.p2maven.InstallableUnitGenerator
> at ClassRealm[coreExtension>org.eclipse.tycho:tycho-build:${tycho-version},
> parent: ClassRealm[plexus.core, parent: null]] (via modules:
> org.eclipse.sisu.wire.WireModule ->
> org.eclipse.sisu.plexus.PlexusBindingModule)
> while locating org.eclipse.tycho.p2maven.MavenProjectDependencyProcessor
> while locating org.eclipse.tycho.build.TychoGraphBuilder
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7924) Better control over and better integration with Resolver
[ https://issues.apache.org/jira/browse/MNG-7924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17784421#comment-17784421 ] ASF GitHub Bot commented on MNG-7924: - cstamas commented on PR #1299: URL: https://github.com/apache/maven/pull/1299#issuecomment-1803725216 Just a thought experiment (that takari somewhat tried to deliver): Look at the `takari-maven-component` packaging. It's goal is: producing jar artifact meant to be used within Maven. This is so expressive... what are you building? "maven-component"s or "jar with sisu index to be used in Maven". Basically, we could distinguish even "jar with sisu index", and if user depends on that, it could (by some plugin, surefire extension example) trigger Sisu container creation that uses INDEX to pick up components from classpath, and so on and so on... These little information crumbs can serve the purpose to make things even more smarter (without being "smart smart", but simply to behave according things our user describes to us). Also, they express intent very very clearly. > Better control over and better integration with Resolver > > > Key: MNG-7924 > URL: https://issues.apache.org/jira/browse/MNG-7924 > Project: Maven > Issue Type: Task > Components: Artifacts and Repositories >Reporter: Tamas Cservenak >Priority: Major > Fix For: 4.0.0-alpha-9 > > > Integrate better and obtain better control over Resolver. These changes did > stem from "[JPMS module > experiment|https://cwiki.apache.org/confluence/display/MAVEN/Experiment+-+Explicit+JPMS+support]"; > and are considered improvement but *does not implement any functionality* > related to JPMS module support. > Changes: > * Maven4 should stop "disconnected coexistence" of two type systems > (ArtifactHandlers and Resolver ArtifactTypeRegistry), it should unify them. > * Maven4 Core should provide generic and extensible means to introduce new > artifact types (fully in extension, and extension should get extended data > via "roundtrip" in core/resolver) -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MNG-7924] Better control over and better integration with Resolver [maven]
cstamas commented on PR #1299: URL: https://github.com/apache/maven/pull/1299#issuecomment-1803725216 Just a thought experiment (that takari somewhat tried to deliver): Look at the `takari-maven-component` packaging. It's goal is: producing jar artifact meant to be used within Maven. This is so expressive... what are you building? "maven-component"s or "jar with sisu index to be used in Maven". Basically, we could distinguish even "jar with sisu index", and if user depends on that, it could (by some plugin, surefire extension example) trigger Sisu container creation that uses INDEX to pick up components from classpath, and so on and so on... These little information crumbs can serve the purpose to make things even more smarter (without being "smart smart", but simply to behave according things our user describes to us). Also, they express intent very very clearly. -- 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: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7924) Better control over and better integration with Resolver
[ https://issues.apache.org/jira/browse/MNG-7924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17784415#comment-17784415 ] ASF GitHub Bot commented on MNG-7924: - cstamas commented on PR #1299: URL: https://github.com/apache/maven/pull/1299#issuecomment-1803707342 Along those lines, yes: Packaging provides flexibility for producers, to build new (or "old", like packaging "jar" vs "takari-jar") things. Type provides flexibility for consumers, for example if producer builds a "bundle" (w/ required extension to make sure he is producing valid OSGi bundle), a consumer still may choose to consume it as "jar", or "bundle" (if he is also in OSGi realm), etc... > Better control over and better integration with Resolver > > > Key: MNG-7924 > URL: https://issues.apache.org/jira/browse/MNG-7924 > Project: Maven > Issue Type: Task > Components: Artifacts and Repositories >Reporter: Tamas Cservenak >Priority: Major > Fix For: 4.0.0-alpha-9 > > > Integrate better and obtain better control over Resolver. These changes did > stem from "[JPMS module > experiment|https://cwiki.apache.org/confluence/display/MAVEN/Experiment+-+Explicit+JPMS+support]"; > and are considered improvement but *does not implement any functionality* > related to JPMS module support. > Changes: > * Maven4 should stop "disconnected coexistence" of two type systems > (ArtifactHandlers and Resolver ArtifactTypeRegistry), it should unify them. > * Maven4 Core should provide generic and extensible means to introduce new > artifact types (fully in extension, and extension should get extended data > via "roundtrip" in core/resolver) -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MNG-7924] Better control over and better integration with Resolver [maven]
cstamas commented on PR #1299: URL: https://github.com/apache/maven/pull/1299#issuecomment-1803707342 Along those lines, yes: Packaging provides flexibility for producers, to build new (or "old", like packaging "jar" vs "takari-jar") things. Type provides flexibility for consumers, for example if producer builds a "bundle" (w/ required extension to make sure he is producing valid OSGi bundle), a consumer still may choose to consume it as "jar", or "bundle" (if he is also in OSGi realm), etc... -- 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: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7924) Better control over and better integration with Resolver
[
https://issues.apache.org/jira/browse/MNG-7924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17784412#comment-17784412
]
ASF GitHub Bot commented on MNG-7924:
-
rmannibucau commented on PR #1299:
URL: https://github.com/apache/maven/pull/1299#issuecomment-1803703826
@cstamas I guess current state is clear but since it is not fully embraced
by the community and your PR enables to align both worlds I really think we
shouldnt miss this opportunity.
If even sonatype gets it wrong it is likely not very welcomed by the
community IMHO.
Side note: never said you were wrong or it was not working, just that there
is so much misunderstanding that making it more obvious would be welcomed.
In terms of impl it is mainly your PR + pom adjustments and be it but it
makes the user facing interactions (our "ui") way more obvious I think:
* You can to change how an artifact is consumed -> change the related flag.
* You want to resolve a particular extension -> change the extension
vs
* You want the `.jar` to ignore transitive deps? Change its `type` ("Wait, I
need to rebuild the dependency?")
> Better control over and better integration with Resolver
>
>
> Key: MNG-7924
> URL: https://issues.apache.org/jira/browse/MNG-7924
> Project: Maven
> Issue Type: Task
> Components: Artifacts and Repositories
>Reporter: Tamas Cservenak
>Priority: Major
> Fix For: 4.0.0-alpha-9
>
>
> Integrate better and obtain better control over Resolver. These changes did
> stem from "[JPMS module
> experiment|https://cwiki.apache.org/confluence/display/MAVEN/Experiment+-+Explicit+JPMS+support]";
> and are considered improvement but *does not implement any functionality*
> related to JPMS module support.
> Changes:
> * Maven4 should stop "disconnected coexistence" of two type systems
> (ArtifactHandlers and Resolver ArtifactTypeRegistry), it should unify them.
> * Maven4 Core should provide generic and extensible means to introduce new
> artifact types (fully in extension, and extension should get extended data
> via "roundtrip" in core/resolver)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MNG-7924] Better control over and better integration with Resolver [maven]
rmannibucau commented on PR #1299:
URL: https://github.com/apache/maven/pull/1299#issuecomment-1803703826
@cstamas I guess current state is clear but since it is not fully embraced
by the community and your PR enables to align both worlds I really think we
shouldnt miss this opportunity.
If even sonatype gets it wrong it is likely not very welcomed by the
community IMHO.
Side note: never said you were wrong or it was not working, just that there
is so much misunderstanding that making it more obvious would be welcomed.
In terms of impl it is mainly your PR + pom adjustments and be it but it
makes the user facing interactions (our "ui") way more obvious I think:
* You can to change how an artifact is consumed -> change the related flag.
* You want to resolve a particular extension -> change the extension
vs
* You want the `.jar` to ignore transitive deps? Change its `type` ("Wait, I
need to rebuild the dependency?")
--
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: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MNG-7924) Better control over and better integration with Resolver
[ https://issues.apache.org/jira/browse/MNG-7924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17784405#comment-17784405 ] ASF GitHub Bot commented on MNG-7924: - cstamas commented on PR #1299: URL: https://github.com/apache/maven/pull/1299#issuecomment-1803688709 Another important thing people forget is that `type != packaging`, and due this bias/assumption they come up with wrong conclusions... Type is NOT packaging, but they CAN be equal. Think about "producer" (project producing artifact) and "consumer" (project that consumes produced artifact). And let's stick with "jar artifact" for simplicity. Producer can produce jar in several ways: * packaging=jar the most ordinary way * packaging=takari-jar very common * packaging=my-supercool-jar (ie. I come up with some my own flavour of packaging for JARs) * etc As you see, technically "endless" options for producing JARs (technically, while in reality few people will care to introduce new packaging, but is not uncommon). Consumer can consume these jars above in several ways: * dependency type=jar the most ordinary way * dependency type=takari-jar very uncommon, but here you must have takari-lifecycle extension present. In fact, this is semantically wrong, and shows my pet-peeve, even sonatype does it wrong * dependency type=my-supercool-jar ditto, you need extension So as you see, not that packaging != type but they are actually `n:m` or unsure, how to express it... Sonatype does it wrong: https://search.maven.org/artifact/io.takari.maven.plugins/takari-lifecycle-plugin/2.1.1/takari-maven-plugin They recommend to "consume" this plugin as: ``` io.takari.maven.plugins takari-lifecycle-plugin 2.1.1 takari-maven-plugin ``` Which is wrong, as to make Maven understand `takari-maven-plugin` you need takari-lifecycle-plugin :smile: Simply put, Sonatype search suffers from [this issue](https://issues.apache.org/jira/browse/MNG-7373?focusedCommentId=17769743&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17769743) > Better control over and better integration with Resolver > > > Key: MNG-7924 > URL: https://issues.apache.org/jira/browse/MNG-7924 > Project: Maven > Issue Type: Task > Components: Artifacts and Repositories >Reporter: Tamas Cservenak >Priority: Major > Fix For: 4.0.0-alpha-9 > > > Integrate better and obtain better control over Resolver. These changes did > stem from "[JPMS module > experiment|https://cwiki.apache.org/confluence/display/MAVEN/Experiment+-+Explicit+JPMS+support]"; > and are considered improvement but *does not implement any functionality* > related to JPMS module support. > Changes: > * Maven4 should stop "disconnected coexistence" of two type systems > (ArtifactHandlers and Resolver ArtifactTypeRegistry), it should unify them. > * Maven4 Core should provide generic and extensible means to introduce new > artifact types (fully in extension, and extension should get extended data > via "roundtrip" in core/resolver) -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MNG-7924] Better control over and better integration with Resolver [maven]
cstamas commented on PR #1299: URL: https://github.com/apache/maven/pull/1299#issuecomment-1803688709 Another important thing people forget is that `type != packaging`, and due this bias/assumption they come up with wrong conclusions... Type is NOT packaging, but they CAN be equal. Think about "producer" (project producing artifact) and "consumer" (project that consumes produced artifact). And let's stick with "jar artifact" for simplicity. Producer can produce jar in several ways: * packaging=jar the most ordinary way * packaging=takari-jar very common * packaging=my-supercool-jar (ie. I come up with some my own flavour of packaging for JARs) * etc As you see, technically "endless" options for producing JARs (technically, while in reality few people will care to introduce new packaging, but is not uncommon). Consumer can consume these jars above in several ways: * dependency type=jar the most ordinary way * dependency type=takari-jar very uncommon, but here you must have takari-lifecycle extension present. In fact, this is semantically wrong, and shows my pet-peeve, even sonatype does it wrong * dependency type=my-supercool-jar ditto, you need extension So as you see, not that packaging != type but they are actually `n:m` or unsure, how to express it... Sonatype does it wrong: https://search.maven.org/artifact/io.takari.maven.plugins/takari-lifecycle-plugin/2.1.1/takari-maven-plugin They recommend to "consume" this plugin as: ``` io.takari.maven.plugins takari-lifecycle-plugin 2.1.1 takari-maven-plugin ``` Which is wrong, as to make Maven understand `takari-maven-plugin` you need takari-lifecycle-plugin :smile: Simply put, Sonatype search suffers from [this issue](https://issues.apache.org/jira/browse/MNG-7373?focusedCommentId=17769743&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17769743) -- 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: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7924) Better control over and better integration with Resolver
[ https://issues.apache.org/jira/browse/MNG-7924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17784402#comment-17784402 ] ASF GitHub Bot commented on MNG-7924: - rmannibucau commented on PR #1299: URL: https://github.com/apache/maven/pull/1299#issuecomment-1803682292 I fully understand that and this is exactly why I'd like we stop doing that. > We could add "flags" to dependencies, but that would make Maven very very "low level", and would trigger a huge cognitive load on end users IMHO. Rather move "baby steps" with improvements, and we will see where it gets us. IMHO it is where we are today, almost no user or plugin writer fully understand the implications of a type and it is often misused. The design of this PR opens the flags which are exactly the proper design and solution to handle the "context" you need and avoid to workaround the lack of flags with an existing marker, aka type today. See it as it is, would you use `org.superbiz-classpath` in `groupid` to say that `org.superbiz` is in the classpath? Probably not but it is what we do in `type` cause of the lack of alternative. With your PR we can assume it and move it to flags and I think it is what would serve the best users and us. The only challenge will be to solve this in pom v4.0.0 (mvn 3) but ultimately since it is build flags it would just be a matter of sticking to type=extension rule so I think we would be good and help our community rather than promoting more a workaround. > Better control over and better integration with Resolver > > > Key: MNG-7924 > URL: https://issues.apache.org/jira/browse/MNG-7924 > Project: Maven > Issue Type: Task > Components: Artifacts and Repositories >Reporter: Tamas Cservenak >Priority: Major > Fix For: 4.0.0-alpha-9 > > > Integrate better and obtain better control over Resolver. These changes did > stem from "[JPMS module > experiment|https://cwiki.apache.org/confluence/display/MAVEN/Experiment+-+Explicit+JPMS+support]"; > and are considered improvement but *does not implement any functionality* > related to JPMS module support. > Changes: > * Maven4 should stop "disconnected coexistence" of two type systems > (ArtifactHandlers and Resolver ArtifactTypeRegistry), it should unify them. > * Maven4 Core should provide generic and extensible means to introduce new > artifact types (fully in extension, and extension should get extended data > via "roundtrip" in core/resolver) -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MNG-7924] Better control over and better integration with Resolver [maven]
rmannibucau commented on PR #1299: URL: https://github.com/apache/maven/pull/1299#issuecomment-1803682292 I fully understand that and this is exactly why I'd like we stop doing that. > We could add "flags" to dependencies, but that would make Maven very very "low level", and would trigger a huge cognitive load on end users IMHO. Rather move "baby steps" with improvements, and we will see where it gets us. IMHO it is where we are today, almost no user or plugin writer fully understand the implications of a type and it is often misused. The design of this PR opens the flags which are exactly the proper design and solution to handle the "context" you need and avoid to workaround the lack of flags with an existing marker, aka type today. See it as it is, would you use `org.superbiz-classpath` in `groupid` to say that `org.superbiz` is in the classpath? Probably not but it is what we do in `type` cause of the lack of alternative. With your PR we can assume it and move it to flags and I think it is what would serve the best users and us. The only challenge will be to solve this in pom v4.0.0 (mvn 3) but ultimately since it is build flags it would just be a matter of sticking to type=extension rule so I think we would be good and help our community rather than promoting more a workaround. -- 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: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7924) Better control over and better integration with Resolver
[ https://issues.apache.org/jira/browse/MNG-7924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17784389#comment-17784389 ] ASF GitHub Bot commented on MNG-7924: - cstamas commented on PR #1299: URL: https://github.com/apache/maven/pull/1299#issuecomment-1803653059 Type is part of Maven DNA, and let me try to explain why: When you are on "resolver level" (so no Maven in vicinity, like MIMA or Resolver "demos" runs), you are dealing with "artifacts", that are really just "named files" or "files with coordinates", and coordinates are needed to lay these files out in some "space" (layout). There is NO whatsoever assumption about "what those files are". At this level resolver merely cares about getting you these files and publishing these files for you. When you hop abstraction level higher, at Maven level, you do not deal (never!) with "artifacts" anymore, but you attribute the usage (or role) to artifact, so in Maven you deal with: * artifact that is the project * artifact that is the parent POM * artifact that is maven-plugin * artifact that is a dependency * etc (so, "artifact" is superset of ALL things Maven uses, but in Maven universe you KNOW and TELL (implicitly or explicitly) what you want that artifact for). And while you have "implied types" (parent POM, maven-plugin, extension, etc are "implied types"), for dependencies you need something "extra" to express "what it is" (or "what I want with it"), and the type serves that purpose. We could add "flags" to dependencies, but that would make Maven very very "low level", and would trigger a huge cognitive load on end users IMHO. Rather move "baby steps" with improvements, and we will see where it gets us. > Better control over and better integration with Resolver > > > Key: MNG-7924 > URL: https://issues.apache.org/jira/browse/MNG-7924 > Project: Maven > Issue Type: Task > Components: Artifacts and Repositories >Reporter: Tamas Cservenak >Priority: Major > Fix For: 4.0.0-alpha-9 > > > Integrate better and obtain better control over Resolver. These changes did > stem from "[JPMS module > experiment|https://cwiki.apache.org/confluence/display/MAVEN/Experiment+-+Explicit+JPMS+support]"; > and are considered improvement but *does not implement any functionality* > related to JPMS module support. > Changes: > * Maven4 should stop "disconnected coexistence" of two type systems > (ArtifactHandlers and Resolver ArtifactTypeRegistry), it should unify them. > * Maven4 Core should provide generic and extensible means to introduce new > artifact types (fully in extension, and extension should get extended data > via "roundtrip" in core/resolver) -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MNG-7924] Better control over and better integration with Resolver [maven]
cstamas commented on PR #1299: URL: https://github.com/apache/maven/pull/1299#issuecomment-1803653059 Type is part of Maven DNA, and let me try to explain why: When you are on "resolver level" (so no Maven in vicinity, like MIMA or Resolver "demos" runs), you are dealing with "artifacts", that are really just "named files" or "files with coordinates", and coordinates are needed to lay these files out in some "space" (layout). There is NO whatsoever assumption about "what those files are". At this level resolver merely cares about getting you these files and publishing these files for you. When you hop abstraction level higher, at Maven level, you do not deal (never!) with "artifacts" anymore, but you attribute the usage (or role) to artifact, so in Maven you deal with: * artifact that is the project * artifact that is the parent POM * artifact that is maven-plugin * artifact that is a dependency * etc (so, "artifact" is superset of ALL things Maven uses, but in Maven universe you KNOW and TELL (implicitly or explicitly) what you want that artifact for). And while you have "implied types" (parent POM, maven-plugin, extension, etc are "implied types"), for dependencies you need something "extra" to express "what it is" (or "what I want with it"), and the type serves that purpose. We could add "flags" to dependencies, but that would make Maven very very "low level", and would trigger a huge cognitive load on end users IMHO. Rather move "baby steps" with improvements, and we will see where it gets us. -- 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: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7924) Better control over and better integration with Resolver
[ https://issues.apache.org/jira/browse/MNG-7924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17784384#comment-17784384 ] ASF GitHub Bot commented on MNG-7924: - rmannibucau commented on PR #1299: URL: https://github.com/apache/maven/pull/1299#issuecomment-1803635618 > um, is like that even today Exactly, and I hope the refactoring enables to stop doing that, it is very misleading for end users and technically no more needed with your PR. > Better control over and better integration with Resolver > > > Key: MNG-7924 > URL: https://issues.apache.org/jira/browse/MNG-7924 > Project: Maven > Issue Type: Task > Components: Artifacts and Repositories >Reporter: Tamas Cservenak >Priority: Major > Fix For: 4.0.0-alpha-9 > > > Integrate better and obtain better control over Resolver. These changes did > stem from "[JPMS module > experiment|https://cwiki.apache.org/confluence/display/MAVEN/Experiment+-+Explicit+JPMS+support]"; > and are considered improvement but *does not implement any functionality* > related to JPMS module support. > Changes: > * Maven4 should stop "disconnected coexistence" of two type systems > (ArtifactHandlers and Resolver ArtifactTypeRegistry), it should unify them. > * Maven4 Core should provide generic and extensible means to introduce new > artifact types (fully in extension, and extension should get extended data > via "roundtrip" in core/resolver) -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MNG-7924] Better control over and better integration with Resolver [maven]
rmannibucau commented on PR #1299: URL: https://github.com/apache/maven/pull/1299#issuecomment-1803635618 > um, is like that even today Exactly, and I hope the refactoring enables to stop doing that, it is very misleading for end users and technically no more needed with your PR. -- 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: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7924) Better control over and better integration with Resolver
[ https://issues.apache.org/jira/browse/MNG-7924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17784381#comment-17784381 ] ASF GitHub Bot commented on MNG-7924: - cstamas commented on PR #1299: URL: https://github.com/apache/maven/pull/1299#issuecomment-1803632036 > Is it planned to make the properties injected from the pom "mvn 4 version" and therefore makes the type dictionnary useless? If so +1 (means the toggles will be exposed to users and type can stick to extension and management in the build handled by end user, best of all worlds), else I'm mixed since it does not change much things if it stays internal only. A bit fuzzy thought but let me try: * "Is it planned to make the properties injected from the pom "mvn 4 version" NO * "therefore makes the type dictionnary useless?" NO * "means the toggles will be exposed to users" YES * "type can stick to extension and management in the build handled by end user" um, is like that even today * "if it stays internal only" um, Type is part of public Maven API, so it cannot be internal only per definitionem > Better control over and better integration with Resolver > > > Key: MNG-7924 > URL: https://issues.apache.org/jira/browse/MNG-7924 > Project: Maven > Issue Type: Task > Components: Artifacts and Repositories >Reporter: Tamas Cservenak >Priority: Major > Fix For: 4.0.0-alpha-9 > > > Integrate better and obtain better control over Resolver. These changes did > stem from "[JPMS module > experiment|https://cwiki.apache.org/confluence/display/MAVEN/Experiment+-+Explicit+JPMS+support]"; > and are considered improvement but *does not implement any functionality* > related to JPMS module support. > Changes: > * Maven4 should stop "disconnected coexistence" of two type systems > (ArtifactHandlers and Resolver ArtifactTypeRegistry), it should unify them. > * Maven4 Core should provide generic and extensible means to introduce new > artifact types (fully in extension, and extension should get extended data > via "roundtrip" in core/resolver) -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MNG-7924] Better control over and better integration with Resolver [maven]
cstamas commented on PR #1299: URL: https://github.com/apache/maven/pull/1299#issuecomment-1803632036 > Is it planned to make the properties injected from the pom "mvn 4 version" and therefore makes the type dictionnary useless? If so +1 (means the toggles will be exposed to users and type can stick to extension and management in the build handled by end user, best of all worlds), else I'm mixed since it does not change much things if it stays internal only. A bit fuzzy thought but let me try: * "Is it planned to make the properties injected from the pom "mvn 4 version" NO * "therefore makes the type dictionnary useless?" NO * "means the toggles will be exposed to users" YES * "type can stick to extension and management in the build handled by end user" um, is like that even today * "if it stays internal only" um, Type is part of public Maven API, so it cannot be internal only per definitionem -- 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: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7662) Allow Graphbuilder to use session scoped components
[
https://issues.apache.org/jira/browse/MNG-7662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17784380#comment-17784380
]
ASF GitHub Bot commented on MNG-7662:
-
rmannibucau commented on code in PR #950:
URL: https://github.com/apache/maven/pull/950#discussion_r1387851206
##
maven-core/pom.xml:
##
@@ -144,6 +144,12 @@ under the License.
org.slf4j
slf4j-api
+
Review Comment:
yes the JVM embed a relocated asm version which always works with their
version, this is why I want to be able to guarantee your extension developped
with jvm N+3 when maven was released with last jvm N works.
your change is very appreciated and ok for me, thanks!
> Allow Graphbuilder to use session scoped components
> ---
>
> Key: MNG-7662
> URL: https://issues.apache.org/jira/browse/MNG-7662
> Project: Maven
> Issue Type: Bug
>Reporter: Christoph Läubrich
>Priority: Major
>
> Currently DefaultMaven gets the Graphbuilder injected as a strict requirement
> at a very early stage. This leads to the problem, that a GraphBuilder
> implementation can not use any SessionScoped Components (because the session
> scope is not setup yet).
> The error then is
> {code:java}
> 1) Error in custom provider, com.google.inject.OutOfScopeException: Cannot
> access Key[type=org.apache.maven.execution.MavenSession, annotation=[none]]
> outside of a scoping block
> at
> org.apache.maven.session.scope.internal.SessionScopeModule.configure(SessionScopeModule.java:64)
> (via modules: org.eclipse.sisu.wire.WireModule ->
> org.apache.maven.session.scope.internal.SessionScopeModule)
> while locating org.apache.maven.execution.MavenSession
> for the 1st parameter of
> org.eclipse.tycho.helper.PluginRealmHelper.(Unknown Source)
> at ClassRealm[coreExtension>org.eclipse.tycho:tycho-build:${tycho-version},
> parent: ClassRealm[plexus.core, parent: null]] (via modules:
> org.eclipse.sisu.wire.WireModule ->
> org.eclipse.sisu.plexus.PlexusBindingModule)
> while locating org.eclipse.tycho.helper.PluginRealmHelper
> at ClassRealm[coreExtension>org.eclipse.tycho:tycho-build:${tycho-version},
> parent: ClassRealm[plexus.core, parent: null]] (via modules:
> org.eclipse.sisu.wire.WireModule ->
> org.eclipse.sisu.plexus.PlexusBindingModule)
> while locating org.eclipse.tycho.p2maven.InstallableUnitGenerator
> at ClassRealm[coreExtension>org.eclipse.tycho:tycho-build:${tycho-version},
> parent: ClassRealm[plexus.core, parent: null]] (via modules:
> org.eclipse.sisu.wire.WireModule ->
> org.eclipse.sisu.plexus.PlexusBindingModule)
> while locating org.eclipse.tycho.p2maven.MavenProjectDependencyProcessor
> while locating org.eclipse.tycho.build.TychoGraphBuilder
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MNG-7662] Use proxies for session scoped beans [maven]
rmannibucau commented on code in PR #950: URL: https://github.com/apache/maven/pull/950#discussion_r1387851206 ## maven-core/pom.xml: ## @@ -144,6 +144,12 @@ under the License. org.slf4j slf4j-api + Review Comment: yes the JVM embed a relocated asm version which always works with their version, this is why I want to be able to guarantee your extension developped with jvm N+3 when maven was released with last jvm N works. your change is very appreciated and ok for me, thanks! -- 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: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7924) Better control over and better integration with Resolver
[
https://issues.apache.org/jira/browse/MNG-7924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17784379#comment-17784379
]
ASF GitHub Bot commented on MNG-7924:
-
cstamas commented on code in PR #1299:
URL: https://github.com/apache/maven/pull/1299#discussion_r1387849231
##
maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/MavenRepositorySystemUtils.java:
##
@@ -59,8 +62,37 @@ private MavenRepositorySystemUtils() {
* the session with authentication, mirror, proxy and other information
required for your environment.
*
* @return The new repository system session, never {@code null}.
+ * @deprecated This method is deprecated.
*/
+@Deprecated
public static DefaultRepositorySystemSession newSession() {
+DefaultArtifactTypeRegistry stereotypes = new
DefaultArtifactTypeRegistry();
+stereotypes.add(new DefaultArtifactType("pom"));
Review Comment:
Deprecation is probably wrong is "deprecated" from Maven POV as it wants
to inject own TypeRegistry, but again, code integrating Maven Resolver (like
MIMA) does not have new Maven API on classpath, and it will want to stick to
"pure" resolver classes...
> Better control over and better integration with Resolver
>
>
> Key: MNG-7924
> URL: https://issues.apache.org/jira/browse/MNG-7924
> Project: Maven
> Issue Type: Task
> Components: Artifacts and Repositories
>Reporter: Tamas Cservenak
>Priority: Major
> Fix For: 4.0.0-alpha-9
>
>
> Integrate better and obtain better control over Resolver. These changes did
> stem from "[JPMS module
> experiment|https://cwiki.apache.org/confluence/display/MAVEN/Experiment+-+Explicit+JPMS+support]";
> and are considered improvement but *does not implement any functionality*
> related to JPMS module support.
> Changes:
> * Maven4 should stop "disconnected coexistence" of two type systems
> (ArtifactHandlers and Resolver ArtifactTypeRegistry), it should unify them.
> * Maven4 Core should provide generic and extensible means to introduce new
> artifact types (fully in extension, and extension should get extended data
> via "roundtrip" in core/resolver)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MNG-7924] Better control over and better integration with Resolver [maven]
cstamas commented on code in PR #1299:
URL: https://github.com/apache/maven/pull/1299#discussion_r1387849231
##
maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/MavenRepositorySystemUtils.java:
##
@@ -59,8 +62,37 @@ private MavenRepositorySystemUtils() {
* the session with authentication, mirror, proxy and other information
required for your environment.
*
* @return The new repository system session, never {@code null}.
+ * @deprecated This method is deprecated.
*/
+@Deprecated
public static DefaultRepositorySystemSession newSession() {
+DefaultArtifactTypeRegistry stereotypes = new
DefaultArtifactTypeRegistry();
+stereotypes.add(new DefaultArtifactType("pom"));
Review Comment:
Deprecation is probably wrong is "deprecated" from Maven POV as it wants
to inject own TypeRegistry, but again, code integrating Maven Resolver (like
MIMA) does not have new Maven API on classpath, and it will want to stick to
"pure" resolver classes...
--
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: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MNG-7924) Better control over and better integration with Resolver
[
https://issues.apache.org/jira/browse/MNG-7924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17784378#comment-17784378
]
ASF GitHub Bot commented on MNG-7924:
-
cstamas commented on code in PR #1299:
URL: https://github.com/apache/maven/pull/1299#discussion_r1387786371
##
maven-core/src/main/java/org/apache/maven/artifact/handler/manager/LegacyArtifactHandlerManager.java:
##
@@ -0,0 +1,72 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.maven.artifact.handler.manager;
+
+import javax.inject.Inject;
+import javax.inject.Named;
+import javax.inject.Singleton;
+
+import java.util.Map;
+import java.util.Set;
+import java.util.concurrent.ConcurrentHashMap;
+
+import org.apache.maven.artifact.handler.ArtifactHandler;
+import org.apache.maven.artifact.handler.DefaultArtifactHandler;
+
+/**
+ */
+@Named
+@Singleton
+public class LegacyArtifactHandlerManager implements ArtifactHandlerManager {
Review Comment:
This is a simple trick:
* legacyAHM is what "default" was so far (it have legacy AHs injected), is
new, but nobody uses it as it is new thing (just new code "knows" about it)
* defaultAHM changed to delegate calls to typeRegistry
* typeRegistry uses as a fallback legacyAHM
This completes the circle:
* legacy code will refer to defaultAHM that goes to typeRegistry that will
refer legacyAHM (as fallback)
* new code will refer to typeRegistry that will refer legacyAHM (as fallback)
This way new code and legacy code both "see" the same things: whether it is
new AH (legacy) or Type (new) being added by extension for example
> Better control over and better integration with Resolver
>
>
> Key: MNG-7924
> URL: https://issues.apache.org/jira/browse/MNG-7924
> Project: Maven
> Issue Type: Task
> Components: Artifacts and Repositories
>Reporter: Tamas Cservenak
>Priority: Major
> Fix For: 4.0.0-alpha-9
>
>
> Integrate better and obtain better control over Resolver. These changes did
> stem from "[JPMS module
> experiment|https://cwiki.apache.org/confluence/display/MAVEN/Experiment+-+Explicit+JPMS+support]";
> and are considered improvement but *does not implement any functionality*
> related to JPMS module support.
> Changes:
> * Maven4 should stop "disconnected coexistence" of two type systems
> (ArtifactHandlers and Resolver ArtifactTypeRegistry), it should unify them.
> * Maven4 Core should provide generic and extensible means to introduce new
> artifact types (fully in extension, and extension should get extended data
> via "roundtrip" in core/resolver)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MNG-7924] Better control over and better integration with Resolver [maven]
cstamas commented on code in PR #1299:
URL: https://github.com/apache/maven/pull/1299#discussion_r1387786371
##
maven-core/src/main/java/org/apache/maven/artifact/handler/manager/LegacyArtifactHandlerManager.java:
##
@@ -0,0 +1,72 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.maven.artifact.handler.manager;
+
+import javax.inject.Inject;
+import javax.inject.Named;
+import javax.inject.Singleton;
+
+import java.util.Map;
+import java.util.Set;
+import java.util.concurrent.ConcurrentHashMap;
+
+import org.apache.maven.artifact.handler.ArtifactHandler;
+import org.apache.maven.artifact.handler.DefaultArtifactHandler;
+
+/**
+ */
+@Named
+@Singleton
+public class LegacyArtifactHandlerManager implements ArtifactHandlerManager {
Review Comment:
This is a simple trick:
* legacyAHM is what "default" was so far (it have legacy AHs injected), is
new, but nobody uses it as it is new thing (just new code "knows" about it)
* defaultAHM changed to delegate calls to typeRegistry
* typeRegistry uses as a fallback legacyAHM
This completes the circle:
* legacy code will refer to defaultAHM that goes to typeRegistry that will
refer legacyAHM (as fallback)
* new code will refer to typeRegistry that will refer legacyAHM (as fallback)
This way new code and legacy code both "see" the same things: whether it is
new AH (legacy) or Type (new) being added by extension for example
--
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: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MNG-7924) Better control over and better integration with Resolver
[
https://issues.apache.org/jira/browse/MNG-7924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17784377#comment-17784377
]
ASF GitHub Bot commented on MNG-7924:
-
cstamas commented on code in PR #1299:
URL: https://github.com/apache/maven/pull/1299#discussion_r1387841807
##
api/maven-api-core/src/main/java/org/apache/maven/api/Type.java:
##
@@ -51,14 +51,21 @@ public interface Type {
* Returns the dependency type id.
* The id uniquely identifies this dependency type.
*
- * @return the id of this type
+ * @return the id of this type, never {@code null}.
*/
String getId();
+/**
+ * Returns the dependency type language.
+ *
+ * @return the language of this type, never {@code null}.
+ */
+String getLanguage();
Review Comment:
Removed language, keep type simplest as possible.
> Better control over and better integration with Resolver
>
>
> Key: MNG-7924
> URL: https://issues.apache.org/jira/browse/MNG-7924
> Project: Maven
> Issue Type: Task
> Components: Artifacts and Repositories
>Reporter: Tamas Cservenak
>Priority: Major
> Fix For: 4.0.0-alpha-9
>
>
> Integrate better and obtain better control over Resolver. These changes did
> stem from "[JPMS module
> experiment|https://cwiki.apache.org/confluence/display/MAVEN/Experiment+-+Explicit+JPMS+support]";
> and are considered improvement but *does not implement any functionality*
> related to JPMS module support.
> Changes:
> * Maven4 should stop "disconnected coexistence" of two type systems
> (ArtifactHandlers and Resolver ArtifactTypeRegistry), it should unify them.
> * Maven4 Core should provide generic and extensible means to introduce new
> artifact types (fully in extension, and extension should get extended data
> via "roundtrip" in core/resolver)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7662) Allow Graphbuilder to use session scoped components
[
https://issues.apache.org/jira/browse/MNG-7662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17784376#comment-17784376
]
ASF GitHub Bot commented on MNG-7662:
-
gnodet commented on code in PR #950:
URL: https://github.com/apache/maven/pull/950#discussion_r1387840616
##
maven-core/pom.xml:
##
@@ -144,6 +144,12 @@ under the License.
org.slf4j
slf4j-api
+
Review Comment:
> Yes exactly, I think it is a case which becomes not rare to ignore.
My point is that I mitigated the problem by externalising ASM. Whenever a
new ASM release comes, we can easily bump it and release maven. But not sure
it actually works, see the last point below.
> About the interface thing it is mainly a matter of registering the scoped
bean with an interface instead of its class so means
`@SessionScoped(targetInterface = MyApi.class) class MyApiImpl implements Api
{}` or something like that - once again we can relax it for internal usage but
not for external ones - and `T` becomes `MyApi` instead of taking the actual
instance. Could it be a compromise to try to not shout in users foot?
I've reworked the PR in this way. The injection is limited to beans which
have a `Typed` annotation (sisu or inject) and the proxies now use JDK proxies.
Related to sisu, I investigated a bit, and ASM is not used to actually
discover classes, that's correctly done with the generated META-INF files, but
it's used to discover the injection points without having to load the classes,
see [sisu
SpaceScanner](https://github.com/eclipse/sisu.inject/blob/master/org.eclipse.sisu.inject/src/main/java/org/eclipse/sisu/space/SpaceScanner.java).
Unfortunately, the sisu code does need [some small
migration](https://github.com/eclipse/sisu.inject/commit/a9752361662edac045f16129a49e1a8b625aa604)
when upgrading to a new ASM version to support reading new code...
Another point I just found is that the `java.lang.reflect.Proxy`... [is
using
ASM](https://github.com/openjdk/jdk/blob/dd9eab15c832c20e65681c21c5f91df11f4cddf9/src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java#L56)
to create the proxies ! So not sure we can really do much here... However, I
assume the JDK uses an ASM version which support the JDK itself somehow.
> Allow Graphbuilder to use session scoped components
> ---
>
> Key: MNG-7662
> URL: https://issues.apache.org/jira/browse/MNG-7662
> Project: Maven
> Issue Type: Bug
>Reporter: Christoph Läubrich
>Priority: Major
>
> Currently DefaultMaven gets the Graphbuilder injected as a strict requirement
> at a very early stage. This leads to the problem, that a GraphBuilder
> implementation can not use any SessionScoped Components (because the session
> scope is not setup yet).
> The error then is
> {code:java}
> 1) Error in custom provider, com.google.inject.OutOfScopeException: Cannot
> access Key[type=org.apache.maven.execution.MavenSession, annotation=[none]]
> outside of a scoping block
> at
> org.apache.maven.session.scope.internal.SessionScopeModule.configure(SessionScopeModule.java:64)
> (via modules: org.eclipse.sisu.wire.WireModule ->
> org.apache.maven.session.scope.internal.SessionScopeModule)
> while locating org.apache.maven.execution.MavenSession
> for the 1st parameter of
> org.eclipse.tycho.helper.PluginRealmHelper.(Unknown Source)
> at ClassRealm[coreExtension>org.eclipse.tycho:tycho-build:${tycho-version},
> parent: ClassRealm[plexus.core, parent: null]] (via modules:
> org.eclipse.sisu.wire.WireModule ->
> org.eclipse.sisu.plexus.PlexusBindingModule)
> while locating org.eclipse.tycho.helper.PluginRealmHelper
> at ClassRealm[coreExtension>org.eclipse.tycho:tycho-build:${tycho-version},
> parent: ClassRealm[plexus.core, parent: null]] (via modules:
> org.eclipse.sisu.wire.WireModule ->
> org.eclipse.sisu.plexus.PlexusBindingModule)
> while locating org.eclipse.tycho.p2maven.InstallableUnitGenerator
> at ClassRealm[coreExtension>org.eclipse.tycho:tycho-build:${tycho-version},
> parent: ClassRealm[plexus.core, parent: null]] (via modules:
> org.eclipse.sisu.wire.WireModule ->
> org.eclipse.sisu.plexus.PlexusBindingModule)
> while locating org.eclipse.tycho.p2maven.MavenProjectDependencyProcessor
> while locating org.eclipse.tycho.build.TychoGraphBuilder
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MNG-7924] Better control over and better integration with Resolver [maven]
cstamas commented on code in PR #1299:
URL: https://github.com/apache/maven/pull/1299#discussion_r1387841807
##
api/maven-api-core/src/main/java/org/apache/maven/api/Type.java:
##
@@ -51,14 +51,21 @@ public interface Type {
* Returns the dependency type id.
* The id uniquely identifies this dependency type.
*
- * @return the id of this type
+ * @return the id of this type, never {@code null}.
*/
String getId();
+/**
+ * Returns the dependency type language.
+ *
+ * @return the language of this type, never {@code null}.
+ */
+String getLanguage();
Review Comment:
Removed language, keep type simplest as possible.
--
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: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Re: [PR] [MNG-7662] Use proxies for session scoped beans [maven]
gnodet commented on code in PR #950:
URL: https://github.com/apache/maven/pull/950#discussion_r1387840616
##
maven-core/pom.xml:
##
@@ -144,6 +144,12 @@ under the License.
org.slf4j
slf4j-api
+
Review Comment:
> Yes exactly, I think it is a case which becomes not rare to ignore.
My point is that I mitigated the problem by externalising ASM. Whenever a
new ASM release comes, we can easily bump it and release maven. But not sure
it actually works, see the last point below.
> About the interface thing it is mainly a matter of registering the scoped
bean with an interface instead of its class so means
`@SessionScoped(targetInterface = MyApi.class) class MyApiImpl implements Api
{}` or something like that - once again we can relax it for internal usage but
not for external ones - and `T` becomes `MyApi` instead of taking the actual
instance. Could it be a compromise to try to not shout in users foot?
I've reworked the PR in this way. The injection is limited to beans which
have a `Typed` annotation (sisu or inject) and the proxies now use JDK proxies.
Related to sisu, I investigated a bit, and ASM is not used to actually
discover classes, that's correctly done with the generated META-INF files, but
it's used to discover the injection points without having to load the classes,
see [sisu
SpaceScanner](https://github.com/eclipse/sisu.inject/blob/master/org.eclipse.sisu.inject/src/main/java/org/eclipse/sisu/space/SpaceScanner.java).
Unfortunately, the sisu code does need [some small
migration](https://github.com/eclipse/sisu.inject/commit/a9752361662edac045f16129a49e1a8b625aa604)
when upgrading to a new ASM version to support reading new code...
Another point I just found is that the `java.lang.reflect.Proxy`... [is
using
ASM](https://github.com/openjdk/jdk/blob/dd9eab15c832c20e65681c21c5f91df11f4cddf9/src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java#L56)
to create the proxies ! So not sure we can really do much here... However, I
assume the JDK uses an ASM version which support the JDK itself somehow.
--
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: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MNG-7924) Better control over and better integration with Resolver
[
https://issues.apache.org/jira/browse/MNG-7924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17784367#comment-17784367
]
ASF GitHub Bot commented on MNG-7924:
-
cstamas commented on code in PR #1299:
URL: https://github.com/apache/maven/pull/1299#discussion_r1387827010
##
api/maven-api-core/src/main/java/org/apache/maven/api/Type.java:
##
@@ -51,14 +51,21 @@ public interface Type {
* Returns the dependency type id.
* The id uniquely identifies this dependency type.
*
- * @return the id of this type
+ * @return the id of this type, never {@code null}.
*/
String getId();
+/**
+ * Returns the dependency type language.
Review Comment:
https://github.com/apache/maven-resolver/blob/master/maven-resolver-api/src/main/java/org/eclipse/aether/artifact/ArtifactProperties.java#L35-L38
Will try to remove this (but Resolver ArtifactProperties could be still used
to set/get this property)
> Better control over and better integration with Resolver
>
>
> Key: MNG-7924
> URL: https://issues.apache.org/jira/browse/MNG-7924
> Project: Maven
> Issue Type: Task
> Components: Artifacts and Repositories
>Reporter: Tamas Cservenak
>Priority: Major
> Fix For: 4.0.0-alpha-9
>
>
> Integrate better and obtain better control over Resolver. These changes did
> stem from "[JPMS module
> experiment|https://cwiki.apache.org/confluence/display/MAVEN/Experiment+-+Explicit+JPMS+support]";
> and are considered improvement but *does not implement any functionality*
> related to JPMS module support.
> Changes:
> * Maven4 should stop "disconnected coexistence" of two type systems
> (ArtifactHandlers and Resolver ArtifactTypeRegistry), it should unify them.
> * Maven4 Core should provide generic and extensible means to introduce new
> artifact types (fully in extension, and extension should get extended data
> via "roundtrip" in core/resolver)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MNG-7924] Better control over and better integration with Resolver [maven]
cstamas commented on code in PR #1299:
URL: https://github.com/apache/maven/pull/1299#discussion_r1387827010
##
api/maven-api-core/src/main/java/org/apache/maven/api/Type.java:
##
@@ -51,14 +51,21 @@ public interface Type {
* Returns the dependency type id.
* The id uniquely identifies this dependency type.
*
- * @return the id of this type
+ * @return the id of this type, never {@code null}.
*/
String getId();
+/**
+ * Returns the dependency type language.
Review Comment:
https://github.com/apache/maven-resolver/blob/master/maven-resolver-api/src/main/java/org/eclipse/aether/artifact/ArtifactProperties.java#L35-L38
Will try to remove this (but Resolver ArtifactProperties could be still used
to set/get this property)
--
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: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MNG-7924) Better control over and better integration with Resolver
[
https://issues.apache.org/jira/browse/MNG-7924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17784364#comment-17784364
]
ASF GitHub Bot commented on MNG-7924:
-
cstamas commented on code in PR #1299:
URL: https://github.com/apache/maven/pull/1299#discussion_r1387816705
##
api/maven-api-core/src/main/java/org/apache/maven/api/Type.java:
##
@@ -51,14 +51,21 @@ public interface Type {
* Returns the dependency type id.
* The id uniquely identifies this dependency type.
*
- * @return the id of this type
+ * @return the id of this type, never {@code null}.
*/
String getId();
+/**
+ * Returns the dependency type language.
Review Comment:
I think it is more like "universe", as for example the "war" case: means
WebArchive in J2EE that is "Java universe". Unsure what the intent of this AH
property was originally. Also, POMs are language="none" (so basically "any", as
POM can be used even to produce native code as well, or think polyglot, so is
not "language bound").
> Better control over and better integration with Resolver
>
>
> Key: MNG-7924
> URL: https://issues.apache.org/jira/browse/MNG-7924
> Project: Maven
> Issue Type: Task
> Components: Artifacts and Repositories
>Reporter: Tamas Cservenak
>Priority: Major
> Fix For: 4.0.0-alpha-9
>
>
> Integrate better and obtain better control over Resolver. These changes did
> stem from "[JPMS module
> experiment|https://cwiki.apache.org/confluence/display/MAVEN/Experiment+-+Explicit+JPMS+support]";
> and are considered improvement but *does not implement any functionality*
> related to JPMS module support.
> Changes:
> * Maven4 should stop "disconnected coexistence" of two type systems
> (ArtifactHandlers and Resolver ArtifactTypeRegistry), it should unify them.
> * Maven4 Core should provide generic and extensible means to introduce new
> artifact types (fully in extension, and extension should get extended data
> via "roundtrip" in core/resolver)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MNG-7924] Better control over and better integration with Resolver [maven]
cstamas commented on code in PR #1299:
URL: https://github.com/apache/maven/pull/1299#discussion_r1387816705
##
api/maven-api-core/src/main/java/org/apache/maven/api/Type.java:
##
@@ -51,14 +51,21 @@ public interface Type {
* Returns the dependency type id.
* The id uniquely identifies this dependency type.
*
- * @return the id of this type
+ * @return the id of this type, never {@code null}.
*/
String getId();
+/**
+ * Returns the dependency type language.
Review Comment:
I think it is more like "universe", as for example the "war" case: means
WebArchive in J2EE that is "Java universe". Unsure what the intent of this AH
property was originally. Also, POMs are language="none" (so basically "any", as
POM can be used even to produce native code as well, or think polyglot, so is
not "language bound").
--
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: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MNG-7924) Better control over and better integration with Resolver
[
https://issues.apache.org/jira/browse/MNG-7924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17784362#comment-17784362
]
ASF GitHub Bot commented on MNG-7924:
-
cstamas commented on code in PR #1299:
URL: https://github.com/apache/maven/pull/1299#discussion_r1387813713
##
api/maven-api-core/src/main/java/org/apache/maven/api/Type.java:
##
@@ -51,14 +51,21 @@ public interface Type {
* Returns the dependency type id.
* The id uniquely identifies this dependency type.
*
- * @return the id of this type
+ * @return the id of this type, never {@code null}.
*/
String getId();
+/**
+ * Returns the dependency type language.
+ *
+ * @return the language of this type, never {@code null}.
+ */
+String getLanguage();
Review Comment:
I may remove this, as it is used ONLY in conversion of Type to AH, but am
unsure is it used anywhere at all...
We can always return it using DependencyProperties where Map
can not only hold "flags" (string values of "true" and "false") but something
else as well
> Better control over and better integration with Resolver
>
>
> Key: MNG-7924
> URL: https://issues.apache.org/jira/browse/MNG-7924
> Project: Maven
> Issue Type: Task
> Components: Artifacts and Repositories
>Reporter: Tamas Cservenak
>Priority: Major
> Fix For: 4.0.0-alpha-9
>
>
> Integrate better and obtain better control over Resolver. These changes did
> stem from "[JPMS module
> experiment|https://cwiki.apache.org/confluence/display/MAVEN/Experiment+-+Explicit+JPMS+support]";
> and are considered improvement but *does not implement any functionality*
> related to JPMS module support.
> Changes:
> * Maven4 should stop "disconnected coexistence" of two type systems
> (ArtifactHandlers and Resolver ArtifactTypeRegistry), it should unify them.
> * Maven4 Core should provide generic and extensible means to introduce new
> artifact types (fully in extension, and extension should get extended data
> via "roundtrip" in core/resolver)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MNG-7924] Better control over and better integration with Resolver [maven]
cstamas commented on code in PR #1299:
URL: https://github.com/apache/maven/pull/1299#discussion_r1387813713
##
api/maven-api-core/src/main/java/org/apache/maven/api/Type.java:
##
@@ -51,14 +51,21 @@ public interface Type {
* Returns the dependency type id.
* The id uniquely identifies this dependency type.
*
- * @return the id of this type
+ * @return the id of this type, never {@code null}.
*/
String getId();
+/**
+ * Returns the dependency type language.
+ *
+ * @return the language of this type, never {@code null}.
+ */
+String getLanguage();
Review Comment:
I may remove this, as it is used ONLY in conversion of Type to AH, but am
unsure is it used anywhere at all...
We can always return it using DependencyProperties where Map
can not only hold "flags" (string values of "true" and "false") but something
else as well
--
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: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MNG-7924) Better control over and better integration with Resolver
[
https://issues.apache.org/jira/browse/MNG-7924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17784359#comment-17784359
]
ASF GitHub Bot commented on MNG-7924:
-
cstamas commented on code in PR #1299:
URL: https://github.com/apache/maven/pull/1299#discussion_r1387809160
##
api/maven-api-core/src/main/java/org/apache/maven/api/Type.java:
##
@@ -51,14 +51,21 @@ public interface Type {
* Returns the dependency type id.
* The id uniquely identifies this dependency type.
*
- * @return the id of this type
+ * @return the id of this type, never {@code null}.
*/
String getId();
+/**
+ * Returns the dependency type language.
+ *
+ * @return the language of this type, never {@code null}.
+ */
+String getLanguage();
+
/**
* Get the file extension of artifacts of this type.
*
- * @return the file extension
+ * @return the file extension, never {@code null}.
Review Comment:
nope, they are never null for types. In maven, when ext=null, then it
implies ext=typeId
> Better control over and better integration with Resolver
>
>
> Key: MNG-7924
> URL: https://issues.apache.org/jira/browse/MNG-7924
> Project: Maven
> Issue Type: Task
> Components: Artifacts and Repositories
>Reporter: Tamas Cservenak
>Priority: Major
> Fix For: 4.0.0-alpha-9
>
>
> Integrate better and obtain better control over Resolver. These changes did
> stem from "[JPMS module
> experiment|https://cwiki.apache.org/confluence/display/MAVEN/Experiment+-+Explicit+JPMS+support]";
> and are considered improvement but *does not implement any functionality*
> related to JPMS module support.
> Changes:
> * Maven4 should stop "disconnected coexistence" of two type systems
> (ArtifactHandlers and Resolver ArtifactTypeRegistry), it should unify them.
> * Maven4 Core should provide generic and extensible means to introduce new
> artifact types (fully in extension, and extension should get extended data
> via "roundtrip" in core/resolver)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MNG-7924] Better control over and better integration with Resolver [maven]
cstamas commented on code in PR #1299:
URL: https://github.com/apache/maven/pull/1299#discussion_r1387809160
##
api/maven-api-core/src/main/java/org/apache/maven/api/Type.java:
##
@@ -51,14 +51,21 @@ public interface Type {
* Returns the dependency type id.
* The id uniquely identifies this dependency type.
*
- * @return the id of this type
+ * @return the id of this type, never {@code null}.
*/
String getId();
+/**
+ * Returns the dependency type language.
+ *
+ * @return the language of this type, never {@code null}.
+ */
+String getLanguage();
+
/**
* Get the file extension of artifacts of this type.
*
- * @return the file extension
+ * @return the file extension, never {@code null}.
Review Comment:
nope, they are never null for types. In maven, when ext=null, then it
implies ext=typeId
--
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: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
