-
Notifications
You must be signed in to change notification settings - Fork 267
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Issue #74: Add display-extension-updates #908
Issue #74: Add display-extension-updates #908
Conversation
eca6dbc
to
55bdfa1
Compare
55bdfa1
to
4119ff6
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Extension can also by defined in .mvn/extensions.xml
https://maven.apache.org/configure.html#mvn-extensions-xml-file
versions-common/src/main/java/org/codehaus/mojo/versions/utils/ExtensionBuilder.java
Outdated
Show resolved
Hide resolved
852bdda
to
36a8593
Compare
@slawekjaranowski added support for core extensions declared in |
b8dd20f
to
76e0619
Compare
* @since 2.15.0 | ||
*/ | ||
public static Stream<Extension> getCoreExtensions(MavenSession session) throws IOException, XmlPullParserException { | ||
Path extensionsFile = session.getCurrentProject().getBasedir().toPath().resolve(".mvn/extensions.xml"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What with multimdule projects?
getBasedir
- returns path to current module - imho it is not Maven project root - should be checked by IT
import java.nio.file.Path; | ||
import java.util.stream.Stream; | ||
|
||
import org.apache.maven.cli.internal.extension.model.io.xpp3.CoreExtensionsXpp3Reader; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
internal implementation ... can be changed - it is risik to use it
versions-maven-plugin/src/main/java/org/codehaus/mojo/versions/DisplayExtensionUpdatesMojo.java
Outdated
Show resolved
Hide resolved
versions-maven-plugin/src/main/java/org/codehaus/mojo/versions/DisplayExtensionUpdatesMojo.java
Outdated
Show resolved
Hide resolved
c1580f4
to
5a37c0d
Compare
versions-model-core-extensions/src/main/mdo/core-extensions.mdo
Outdated
Show resolved
Hide resolved
<extensions xmlns="http://maven.apache.org/EXTENSIONS/1.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" | ||
xsi:schemaLocation="http://maven.apache.org/EXTENSIONS/1.0.0 http://maven.apache.org/xsd/core-extensions-1.0.0.xsd"> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Core extensions can be defined only in project root - in child module it will be skipped as I know.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see a check for dummy-impl
so why this file exists?
versions-maven-plugin/src/main/java/org/codehaus/mojo/versions/DisplayExtensionUpdatesMojo.java
Outdated
Show resolved
Hide resolved
5a37c0d
to
f0b85a5
Compare
b3375b4
to
a686ce2
Compare
@ajarmoniuk please rebase this PR ... now I see in diff changes from master ... |
51c498a
to
cf5aaaf
Compare
Rebased. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, I see
you create new module versions-model-core-extensions
with contain a copy file core-extensions.mdo from Maven core.
I think that better will be use org.apache.maven.cli.internal.extension.model.io.xpp3.CoreExtensionsXpp3Reader
even it is internal
pom.xml
Outdated
@@ -126,6 +127,7 @@ | |||
<maven.compiler.source>${mojo.java.target}</maven.compiler.source> | |||
<junitBomVersion>5.9.1</junitBomVersion> | |||
<mavenVersion>3.2.5</mavenVersion> | |||
<mavenEmbedderVersion>3.3.9</mavenEmbedderVersion> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is from Maven Core should have the same version as used Maven api and so on
<extensions xmlns="http://maven.apache.org/EXTENSIONS/1.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" | ||
xsi:schemaLocation="http://maven.apache.org/EXTENSIONS/1.0.0 http://maven.apache.org/xsd/core-extensions-1.0.0.xsd"> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see a check for dummy-impl
so why this file exists?
Are you sure? I asked you before when you requested me to change that:
So, what should it be? I'll wait. |
to test if the .mvn/extensions is not processed in the child. |
cf5aaaf
to
e9eed03
Compare
@slawekjaranowski and if you need time to decide, feel free to remove this from the upcoming release. It's not so easy. Maven Embedder 3.2.5 does not have the Core Extensions parser. Only 3.3.9 and later has it. So we cannot use the one from the same version as Maven. https://maven.apache.org/ref/3.2.5/maven-embedder/xref/index.html |
e9eed03
to
da43c20
Compare
Ok, I must review of it more carefully ... so I will do it again in next week Maybe some one else want to look also - @slachiewicz ? |
@slawekjaranowski @slachiewicz It's not the only case like this in this plugin. Please have a look at e.g. parsing raw pom. Currently it's an ad-hoc parser created from scratch in the plugin, but it actually depends on a document defined and owned by the Maven project. So it's a very similar case. |
@slawekjaranowski I propose that we keep a version of this PR with the file from the Apache Maven project with its own ASF license and its own Modello version. Until there comes an API from Maven, which we can request or implement. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that we not need new module only for a few classes, we not need xsd for it, it is only for internal purpose.
I would like to put core-extensions.mdo into versions-common where is only used.
<execution> | ||
<id>generate-site-doc</id> | ||
<goals> | ||
<goal>xdoc</goal> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should not generate xsd for this model - it is internally used for reading extensions.xml
versions-model-core-extensions/src/main/mdo/core-extensions.mdo
Outdated
Show resolved
Hide resolved
versions-model-core-extensions/src/main/mdo/core-extensions.mdo
Outdated
Show resolved
Hide resolved
Applied. |
950810f
to
ef5f771
Compare
Oh yes, I remember it now. The reason why I created that module was that I couldn't go around javadoc generation errors -- classes were generated. I think that there is no easy way of hinting javadoc to use the autogenerated classes. Exit code: 1 Refer to the generated Javadoc files in '/Users/ajarmoniuk/IdeaProjects/versions-maven-plugin-2/versions-common/target/site/apidocs' dir. |
ef5f771
to
1e4bd55
Compare
Deleting the contents of '/home/runner/work/versions/versions' @slawekjaranowski @slachiewicz could you please restart? |
@slawekjaranowski is there anything else to be done about this PR? |
1306c33
to
65125cc
Compare
65125cc
to
d5baff3
Compare
d5baff3
to
6d554df
Compare
Hi, Wait for build and we can go. |
First stage of extensions support.
Not supporting core extensions. Only build extensions are supported.
@slawekjaranowski please review