sisu-build-api

[laeubi]

m2e uses sisu-build-api to implement incremental builds, see https://www.eclipse.org/m2e/documentation/m2e-making-maven-plugins-compat.html

But looking at the repository, it is archive,d lat code changes where 12 years ago an it version still implies its some kind of experimental. Recently I found it might be good to enhance this API (e.g. for cases like eclipse-tycho/tycho#1278) but this would of course only work with active development.

So I really wonder if:

1. m2e should adopt this project so we can improve on this API (might need to publish it under a new GAV and have some wrapper for the old API).
2. we think this could be useful for maven in general and try to let maven adopt this API, but then we give good advice to the maven people why we thing this is general purpose enough.

[mickaelistria]

This is a general Maven issue IMO; m2e is just 1 possible case for integration of build increments and Maven builds. So the solution shouldn't be part of m2e ideally. Although the BuildContext is somehow deprecated, I wonder whether Maven community does provide a good alternative already. It's definitely worth discussing it with Maven experts on the dev mailing-list.

[HannesWell]

I agree that this is something that would be worth to discuss with the Maven devs.
IIRC for example the connector for the maven-dependency-plugin's copy goal would not be necessary if that Plugin would use the mentiond build-context (or a successor). Probably this applies for other maven-plugins top.

[laeubi]

@HannesWell do you like to bring this to the mailing list and/or Jira?

[HannesWell]

I'm interested to do that, yes.
But I probably don't have time for that immediatly after my vacation next week.
If one of you wants to do it earlier I'm fine with IT and will follow interestedly and would participate I
if it fits.

[HannesWell]

@HannesWell do you like to bring this to the mailing list and/or Jira?

Here we go:
https://www.mail-archive.com/[email protected]/msg127887.html

[HannesWell]

@HannesWell do you like to bring this to the mailing list and/or Jira?

Here we go: https://www.mail-archive.com/[email protected]/msg127887.html

Looks like their enthusiasm about adopting a 'BuildContext' like API by Maven is limited... Too bad.

[laeubi]

FYI @gnodet maybe also interesting for mvnd ...
@HannesWell any updates here?

[laeubi]

That would be true only for plugins that accept to not optimise their processing. If the plugin wants to do some stale files detection or any similar optimisation, it will have to work on two different code paths.

The only difference here is, that one adds an additional check for example:

if (isMyFileStale(input, output) {
  //do something
}

will become

if (buildContext.hasDelta(input) && isMyFileStale(input, output) {
  //do something
}

so no need for different code path...

In short, I think that there is a need for such an API, but it has to be defined in the maven project, has to actually provide some real value for non IDE builds,

That's why I though mvnd would be another consumer

and that can be integrated by other IDEs as well (not only Eclipse).

The current API can already be used by anyone (not only IDEs) and there are already some plugins out there using that.

There are been other attempts like takari incremental build.

The takiri one seem to adress a whole new framework but I might be wrong.

Anyway, this discussion should be brought to [email protected] imho.

I hope this will be done soon, but its always good to first collect some feedback from a smaller audience.

[gnodet]

That would be true only for plugins that accept to not optimise their processing. If the plugin wants to do some stale files detection or any similar optimisation, it will have to work on two different code paths.

The only difference here is, that one adds an additional check for example:

if (isMyFileStale(input, output) {
  //do something
}

will become

if (buildContext.hasDelta(input) && isMyFileStale(input, output) {
  //do something
}

so no need for different code path...

I think stale detection should be provided by the build context (or whatever the api is). Maybe I'm wrong, but the whole point of this API is to detect which files need to be processed, so this looks clearly redundant to me.

In short, I think that there is a need for such an API, but it has to be defined in the maven project, has to actually provide some real value for non IDE builds,

That's why I though mvnd would be another consumer

Yes, it may be. But if the state is stored, I'm not sure there's much benefit for mvnd to implement its own. Actually, if done properly, I'm not sure what Eclipse would actually gain. There's not much difference in flagging through a file watcher or checking the files directly and comparing with the output.

and that can be integrated by other IDEs as well (not only Eclipse).

The current API can already be used by anyone (not only IDEs) and there are already some plugins out there using that.

Sure, but it would be nice to make sure the API covers all the needs.

There are been other attempts like takari incremental build.

The takiri one seem to adress a whole new framework but I might be wrong.

Even for plugins, the API may miss a few things. The api needs to be able to store some configuration bits that will affect the processing, the api for deleted resources does not seem straightforward, and the one-to-one mapping between input and output might be too limitative.

Anyway, this discussion should be brought to [email protected] imho.

I hope this will be done soon, but its always good to first collect some feedback from a smaller audience.

[HannesWell]

@HannesWell any updates here?

Not yet unfortunately. If you want it to happen faster I wouldn't mind if you take care of it otherwise I can do that hopefully not too far in the future.

Besides the aspect of avoiding unnecessary file modifications the BuildContext also has the purpose to notify Eclipse (or the IDE in general, but I'm not aware how other IDEs handle that) about files/folders that have been modified and should therefore be refreshed. Otherwise the changes do not become visible to the Resources-Plugin of Eclipse and Eclipse can not show them to the user or consider them if necessary.

For example the only thing the connector for the maven-dependency-plugin does is to obtain the target directories of the copy/unpack goal and to tell Eclipse to refresh them:
https://github.com/ianbrandt/m2e-maven-dependency-plugin/blob/38c09f1ee625369f5ebc7a57f5b2a63e9034f9a4/core/src/com/ianbrandt/tools/m2e/mdp/core/MdpBuildParticipant.java#L71

If the maven-dependency-plugin would use BuildContext.newFileOutputStream() or something similar in a more general API then that whole connector would not be necessary.
The same applies for the maven-clean-plugin, for which no connector exists yet (as far as I know). But if there would be a method like BuildContext.delete() no connector would be necessary as well to make the IDE aware of additional directories that are cleaned by the clean goal.

[laeubi]

@HannesWell maybe we should propose the usage of the current BuildContext to these plugins with a lifecycle mapping xml? That should work as of today already...

[HannesWell]

@HannesWell maybe we should propose the usage of the current BuildContext to these plugins with a lifecycle mapping xml? That should work as of today already...

Yes that should work already. But my guess is that if we propose to use such abandoned prototype API the maintainers of those plugins will ask for something more robust which will lead to the general discussion, so I think we can just start that.
Nevertheless those two plug-ins are good examples.
It is probably faster if we simply add connectors for them to m2e. Maybe in a new plugin o.e.m2e.standard.connector or similar.

I started to prepare a little text for the Maven dev-mailing list that I hopefully complete in the next days and that I then plan to post on the Maven list. I will add a link here, but I have seen you are already on that list so will notice that any ways. :)

[laeubi]

The API is now revived in a new repository:

https://github.com/codehaus-plexus/plexus-build-api

given the reserved feedback from the maven-dev it seems most suitable to help with improving the API keeping it alive and healthy and hope for some glory future of maven 4 (or 5 ...), I opened some issues so everyone is invited to help:

https://github.com/codehaus-plexus/plexus-build-api/issues

[HannesWell]

Since the new plexus-build-api has new a new package name we can support both for some time to allow transition.

Too bad the new API was released already without your suggestions being considered. But from my quick overview I suspect that some of them are breaking changes so they cannot be applied for version 1.x.

This also makes me aware that it will be hard to support multiple major/incompatible versions of that API (if it evolves one day). Theoretically it would work if we have one impl bundle/project for each major version and detect which version a plugin uses, but that will be somewhat cumbersome, but theoretically doable.

[laeubi]

I'm not aware of any release, but we most likely will only support it up from version X where X is a version we are fine with and then only latest version that will hopefully be backward compatible for clients.

[HannesWell]

There was a release eight days ago:
https://github.com/codehaus-plexus/plexus-build-api/releases/tag/plexus-build-api-1.0.0

I'm not aware of any release, but we most likely will only support it up from version X where X is a version we are fine with and then only latest version that will hopefully be backward compatible for clients.

Yep, that's what I also had in mind.

[HannesWell]

For reference, supporting the new BuildContext-API is tracked in #944.