-
Notifications
You must be signed in to change notification settings - Fork 179
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
[MDEP-674] Add IDE build support #257
Conversation
Use BuildContext to notify about newly generated files/folders
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'm not feel good with such implementation ... yes I know there are no other proposition.
pom.xml
Outdated
<dependency> | ||
<groupId>org.sonatype.plexus</groupId> | ||
<artifactId>plexus-build-api</artifactId> | ||
<version>0.0.7</version> | ||
<scope>compile</scope> | ||
</dependency> |
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.
unmaintained dependency ...
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.
Not really, it saw a new release at https://github.com/codehaus-plexus/plexus-build-api. The new GAV and packages are just not compatible with m2e yet (eclipse-m2e/m2e-core#944).
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.
Compare also with the discussion at https://lists.apache.org/thread/h2gy5l7j5bv7ycbpwdjby66v8gwhzck2.
specific language governing permissions and limitations | ||
under the License. | ||
--> | ||
<lifecycleMappingMetadata> |
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.
Specific only for Eclipse ...
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.
could be used by any IDE supporting incremental builds, but currently m2e is the only consumer, right.
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.
Eclipse and its derivative, such as Java edition in VSCode.
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.
is there option to not store such specific IDE file here?
I don't like much this... I would be -1.
we already have a sort of specific API and now specific files.
Imagine if every IDE ask for storing their specific files?
sounds a bad design to me.
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.
Fact is: There is no other metadata defined for any other IDE. Every IDE could reuse this metadata. We already have m2e metadata in other Maven plugins e.g. in https://github.com/apache/maven-resources-plugin/blob/master/src/main/resources/META-INF/m2e/lifecycle-mapping-metadata.xml or in https://github.com/apache/maven-enforcer/tree/master/maven-enforcer-plugin/src/main/resources/META-INF/m2e.
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.
which should have never been accepted....
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.
Imagine if every IDE ask for storing their specific files? sounds a bad design to me.
Indeed that would be bad and was the reason why I/we the M2E team reached out to the Maven devs on their mailing list (the link @kwin posted above) to establish a unified API defined/maintained by Maven that all IDEs could use. Eventually this probably would have lead to a similar Maven-defined/maintained lifecycle-mapping metadata format (which actually also could be generated from annotations see e.g. eclipse-m2e/m2e-core#830).
But there was only negative feedback from all Maven devs about that suggestion, so each IDE has to continue to handle it their one way.
Anyway, as @mickaelistria said below we can maintain that metadata in a Eclipse M2E plug-in.
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.
Indeed that would be bad and was the reason why I/we the M2E team reached out to the Maven devs on their mailing list (the link @kwin posted above) to establish a unified API defined/maintained by Maven that all IDEs could use. [...] But there was only negative feedback from all Maven devs about that suggestion, so each IDE has to continue to handle it their one way.
A very very strange conclusion drawn from a ML thread having this post: https://lists.apache.org/thread/044tno4lvdjvm4yv7orsqpmn3x4175c4
(edit: typo)
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.
That's right Guillaume Nodet was not averse to the suggestion, but from the other not so positive comments I had the impression that this was not the general conclusion. However, if that was a misinterpretation from my side and the suggestion will be considered in the future, I'm glad. :)
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.
As there was no consensus to add m2e specific metadata I removed it now in c34c3c7.
@@ -59,6 +60,21 @@ | |||
@Component | |||
private ArchiverManager archiverManager; | |||
|
|||
|
|||
/** | |||
* For m2e incremental build support |
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.
Since the BuildContext
API is not Eclipse M2E specific (even though M2E is the only user I'm aware of) I suggest to make this comment more generic.
The same applies for the comment of the skipDuringIncrementalBuild
.
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 mostly to not confuse it with http://takari.io/2014/03/25/incremental-build.html. Any suggestion for the naming as just incremental build support
may be a bit too generic (as there are other incremental build APIs)?
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.
Maybe IDE build support
as this is also not only about incremental support but also about other features from the Build Support API (like notification about updates files or context-specific error messages)
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.
Sounds good.
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.
Done in c34c3c7.
@kwin @HannesWell what about adding the lifecycle mappings in https://github.com/eclipse-m2e/m2e-core/blob/master/org.eclipse.m2e.core/lifecycle-mapping-metadata.xml and not include it in the PR if this is an issue for Maven project? After all, @olamy is right and we have a way to put those mappings file somewhere else, only the BuildContext API has to be part of the plugin as far as I know. |
Yes we can do that. Actually it would be natural to have all metadata in the plugin to minimize the synchronization effort, but this does only make sense if that is in a general 'Maven' format and not a IDE specific one (as said above #257 (comment)) |
remove m2e specific lifecycle mapping metadata
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.
Looks good to me. Thank you!
src/main/java/org/apache/maven/plugins/dependency/AbstractDependencyMojo.java
Outdated
Show resolved
Hide resolved
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'm not a fan such case ... but ok looks good enough
fix since version
Use BuildContext to notify about newly generated files/folders
Following this checklist to help us incorporate your
contribution quickly and easily:
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.
[MDEP-XXX] - Fixes bug in ApproximateQuantiles
,where you replace
MDEP-XXX
with the appropriate JIRA issue. Best practiceis to use the JIRA issue title in the pull request title and in the first line of the
commit message.
mvn clean verify
to make sure basic checks pass. A more thorough check willbe performed on your pull request automatically.
mvn -Prun-its clean verify
).If your pull request is about ~20 lines of code you don't need to sign an
Individual Contributor License Agreement 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
you have to acknowledge this by using the following check-box.
I hereby declare this contribution to be licensed under the Apache License Version 2.0, January 2004
In any other case, please file an Apache Individual Contributor License Agreement.