Switch to codehaus plexus-build-api 1.2.0

[gnodet]

No description provided.

[kwin]

This breaks Eclipse support. Please wait until Eclipse supports it.

[gnodet]

This breaks Eclipse support. Please wait until Eclipse supports it.

I'd really like to have codehaus-plexus/plexus-build-api#64 somehow. That's actually the reason why I'd like a release of modello and upgrade maven to it.

@laeubi what's the ETA to bring in the update ?

[laeubi]

There is currently no ETA for this, but as this is actually a fallback component you can for mvnd (I assume its most important there?!?) simply provide a MvndBuildContext (it just needs a higher @Priority) that do whatever is good there (even watch the filesystem for changes and provide appropriate delta notifications for mojos).

I think one can even write a core extension for standard maven...

[gnodet]

There is currently no ETA for this, but as this is actually a fallback component you can for mvnd (I assume its most important there?!?) simply provide a MvndBuildContext (it just needs a higher @Priority) that do whatever is good there (even watch the filesystem for changes and provide appropriate delta notifications for mojos).

I think one can even write a core extension for standard maven...

It's not specifically for mvnd. Stock maven would really benefit from the cached stream too and Maven does not provide this api.

Not having the cache stream means that files written using the build-api will get rewritten at every run. This includes modello generated files, but also manifest computed using bnd. That cascades down in a reactor and all jars are regenerated. So it's a tradeoff between faster builds in the whole maven ecosystem vs faster builds in eclipse. Given I don't use eclipse, you know whereto I'm leaning .... ;-)

[laeubi]

Its the choice of the plugin of course, but then using the buildapi is useless as a whole and expect that users complaining will be redirected to the plugin itself and not get any support from m2e-project then.

BuildAPi is the most important part for seaming-less integration in (Eclipse) IDE as otherwise a full build is required (instead of incremental ones), I usually work in the IDE and don't care about a few second or even minutes on the CI but others might have different experience.

Stock maven would really benefit from the cached stream too and Maven does not provide this api.

This does not prevent you from writing a dedicated plugin and add it to the extensions.xml ...

[gnodet]

Its the choice of the plugin of course, but then using the buildapi is useless as a whole and expect that users complaining will be redirected to the plugin itself and not get any support from m2e-project then.

BuildAPi is the most important part for seaming-less integration in (Eclipse) IDE as otherwise a full build is required (instead of incremental ones), I usually work in the IDE and don't care about a few second or even minutes on the CI but others might have different experience.

Stock maven would really benefit from the cached stream too and Maven does not provide this api.

This does not prevent you from writing a dedicated plugin and add it to the extensions.xml ...

I'm willing to help upgrading m2e to it. @kwin also proposed is help in eclipse-m2e/m2e-core#944 (comment) I think. If you do not want our help and you're not planning to work on this issue, then we should drop the new artifact completely, there's no point in having it. Also, the caching output stream could easily be added to the old one.

If none of the above proposal has your agreement, then, yes, I'll try to work around this issue, but using an extensions.xml is not really an option, as my goal is not to fix a given build, but rather optimize plugins more generally. That would mean pushing the plexus-build-api out and use a caching writer directly.

That's related to discussions we had with @cstamas too, where this api benefits m2e only and not the whole maven ecosystem. Fwiw, I've started working on a replacement api based on takari codebase at apache/maven#1118.

[laeubi]

I'm willing to help upgrading m2e to it.

This is not a simple upgrade, as both versions need to be supported.

If you do not want our help and you're not planning to work on this issue,

I don't say I'm not working on it, there is just no ETA when work will be finished.

then we should drop the new artifact completely, there's no point in having it

The point of having it was a organizational decision, not a technical one nor does anyone asked if there is enough dev-power or the impact on this change. So from m2e POW this was the same "useless" change as the javax > jakarta change, and I already mentioned in the PR that just changing the new (unused) artifact won't help much.

where this api benefits m2e only and not the whole maven ecosystem

This is not only m2e, whoever likes can adapt this API (including maven) but well its always only theoretical discussions and ends for nothing as it fastly change into a "we don't want to support IDEs because then we need to support the whole world and you can always use extensions for this and beside thsi we don't care at all about your requirements", still there are many happy users using this API even though it is "only m2e".

I've started working on a replacement api based on takari codebase at apache/maven#1118.

Fine, but unless it is supported in m2e (actually takairi was supposed to be supported in m2e one time already), this won't help anything more and soon we need to support 3 competing APIs.... Also note that for what a plugin requires (need to know what files are changed since last time) the takari API adds a lot of complexity for little gain (beside that's the best and perfect API of course). Also incremental is only one part of plexus build api, there is a lot more requirements (e.g. markers, forking of process and so on).