Issue #74: Add display-extension-updates#908
Conversation
eca6dbc to
55bdfa1
Compare
55bdfa1 to
4119ff6
Compare
slawekjaranowski
left a comment
There was a problem hiding this comment.
Extension can also by defined in .mvn/extensions.xml
https://maven.apache.org/configure.html#mvn-extensions-xml-file
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.
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.
internal implementation ... can be changed - it is risik to use it
c1580f4 to
5a37c0d
Compare
| <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.
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.
I don't see a check for dummy-impl so why this file exists?
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. |
slawekjaranowski
left a comment
There was a problem hiding this comment.
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
| <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.
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.
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. |
slawekjaranowski
left a comment
There was a problem hiding this comment.
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.
We should not generate xsd for this model - it is internally used for reading extensions.xml
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