Skip to content
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

Merged
merged 6 commits into from Nov 22, 2022
Merged

Conversation

kwin
Copy link
Member

@kwin kwin commented Oct 28, 2022

Use BuildContext to notify about newly generated files/folders

Following this checklist to help us incorporate your
contribution quickly and easily:

  • Make sure there is a JIRA issue 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 [MDEP-XXX] - Fixes bug in ApproximateQuantiles,
    where you replace MDEP-XXX with the appropriate JIRA issue. Best practice
    is to use the JIRA issue title in 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 integration tests successfully (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.

Use BuildContext to notify about newly generated files/folders
Copy link
Member

@slawekjaranowski slawekjaranowski left a 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 Show resolved Hide resolved
pom.xml Outdated
Comment on lines 251 to 256
<dependency>
<groupId>org.sonatype.plexus</groupId>
<artifactId>plexus-build-api</artifactId>
<version>0.0.7</version>
<scope>compile</scope>
</dependency>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

unmaintained dependency ...

Copy link
Member Author

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).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

specific language governing permissions and limitations
under the License.
-->
<lifecycleMappingMetadata>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Specific only for Eclipse ...

Copy link
Member Author

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.

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.

Copy link
Member

@olamy olamy Nov 2, 2022

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.

Copy link
Member Author

@kwin kwin Nov 2, 2022

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.

Copy link
Member

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....

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.

Copy link
Member

@cstamas cstamas Nov 2, 2022

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)

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. :)

Copy link
Member Author

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.

@kwin kwin requested a review from olamy October 28, 2022 13:29
@michael-o michael-o removed their request for review October 28, 2022 19:25
@@ -59,6 +60,21 @@
@Component
private ArchiverManager archiverManager;


/**
* For m2e incremental build support

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.

Copy link
Member Author

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)?

Copy link
Member Author

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)

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done in c34c3c7.

@mickaelistria
Copy link

@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.

@HannesWell
Copy link

@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
@kwin kwin changed the title [MDEP-674] Add m2e lifecycle metadata [MDEP-674] Add IDE build support Nov 9, 2022
Copy link

@HannesWell HannesWell left a 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!

Copy link
Member

@slawekjaranowski slawekjaranowski left a 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
@kwin kwin merged commit 50a4b70 into master Nov 22, 2022
@kwin kwin deleted the feature/incremental-build-support branch November 22, 2022 10:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
6 participants