Ok not to deploy Eclipse features to Maven for the time being (because of a bug)?

[Richard Eckart de Castilho <re...@apache.org>]

Hi all,

there is a problem in the interplay between building Eclipse Feature modules
using Tycho and the maven-checksum-plugin. 

Tycho attaches e.g. a file called `p2content.xml` to the build, and the
maven-checksum-plugin generates a checksum file then which contains this
filename, but the file ends up in the Maven repository as e.g. 
`org.apache.uima.ruta.feature-3.2.0-p2metadata.xml`.

  https://github.com/nicoulaj/checksum-maven-plugin/issues/137

It checksum file still contains a valid checksum and the checksum checking rules
configured on the ASF Maven Repository even accept it. But during release
valiation, it is annoying because the checksum file cannot be checked using
`sha512 -c <file>.sha512`. So I think it would be better not to deploy such
a file to the Maven repo.

The maven-checksum-plugin is by default running in the `verify` phase of the
build which comes directly before the `install` phase. So we cannot insert
e.g. an antrun task there which would fix the checksum files unless we'd
reconfigure the maven-checksum-plugin to run in an earlier phase. Also
needing an antrun task to fix this is kind of annoying. 

This problem happens in particular with Eclipse Feature modules. I believe
that it should be ok to not deploy Eclipse Feature modules to Maven repositories
for the moment.

Of course if we want to work with "true" Maven P2 update sites which bundle
nothing and just contain pointers to other Maven artifacts, we would probably
have to deploy the features as well. But maybe the checksum-maven-plugin
issue 137 might be fixed by then? The only project currently experimenting
with a Maven P2 update site is the UIMA Java SDK - so thinking about this
would only become relevant with its 3.4.0 release - and even then we could
still postpone the experiment to a later release.

So my suggestion for the moment would be to 

* disable deployment of Eclipse features (and Eclipse update sites) to Maven repositories
* wait for checksum-maven-plugin issues #137 to get resolved (maybe help out there)

Does that sound reasonable? Anybody having a better idea?


Alternatives that I currently see are:
* live with the wrong filename in the sha512 file
* try if running maven-checksum-plugin in the `integration-test` phase is sufficent and
  then add an antrun script which tries fixing the names in the sha512 file


Cheers,

-- Richard

Re: Ok not to deploy Eclipse features to Maven for the time being (because of a bug)?

[Peter Klügl <pe...@averbis.com>]

Hi,


I think it's totally fine not to deploy the feature artifact to maven 
central if it is not required by the update site.


The source it the official released artifact, the jars on maven central 
are the commonly used ones, the plugin and feature bundles are just 
additional tooling. I think there no need to deploy any of them to maven 
central with the current update site setting.


Best


Peter



Am 20.05.2022 um 22:10 schrieb Richard Eckart de Castilho:
> Hi all,
>
> there is a problem in the interplay between building Eclipse Feature 
> modules
> using Tycho and the maven-checksum-plugin.
>
> Tycho attaches e.g. a file called `p2content.xml` to the build, and the
> maven-checksum-plugin generates a checksum file then which contains this
> filename, but the file ends up in the Maven repository as e.g.
> `org.apache.uima.ruta.feature-3.2.0-p2metadata.xml`.
>
> https://github.com/nicoulaj/checksum-maven-plugin/issues/137
>
> It checksum file still contains a valid checksum and the checksum 
> checking rules
> configured on the ASF Maven Repository even accept it. But during release
> valiation, it is annoying because the checksum file cannot be checked 
> using
> `sha512 -c <file>.sha512`. So I think it would be better not to deploy 
> such
> a file to the Maven repo.
>
> The maven-checksum-plugin is by default running in the `verify` phase 
> of the
> build which comes directly before the `install` phase. So we cannot insert
> e.g. an antrun task there which would fix the checksum files unless we'd
> reconfigure the maven-checksum-plugin to run in an earlier phase. Also
> needing an antrun task to fix this is kind of annoying.
>
> This problem happens in particular with Eclipse Feature modules. I believe
> that it should be ok to not deploy Eclipse Feature modules to Maven 
> repositories
> for the moment.
>
> Of course if we want to work with "true" Maven P2 update sites which 
> bundle
> nothing and just contain pointers to other Maven artifacts, we would 
> probably
> have to deploy the features as well. But maybe the checksum-maven-plugin
> issue 137 might be fixed by then? The only project currently experimenting
> with a Maven P2 update site is the UIMA Java SDK - so thinking about this
> would only become relevant with its 3.4.0 release - and even then we could
> still postpone the experiment to a later release.
>
> So my suggestion for the moment would be to
>
> * disable deployment of Eclipse features (and Eclipse update sites) to 
> Maven repositories
> * wait for checksum-maven-plugin issues #137 to get resolved (maybe 
> help out there)
>
> Does that sound reasonable? Anybody having a better idea?
>
>
> Alternatives that I currently see are:
> * live with the wrong filename in the sha512 file
> * try if running maven-checksum-plugin in the `integration-test` phase 
> is sufficent and
> then add an antrun script which tries fixing the names in the sha512 file
>
>
> Cheers,
>
> -- Richard

-- 
Dr. Peter Klügl
R&D Text Mining/Machine Learning

Averbis GmbH
Salzstr. 15
79098 Freiburg
Germany

Fon: +49 761 708 394 0
Fax: +49 761 708 394 10
Email: peter.kluegl@averbis.com
Web: https://averbis.com

Headquarters: Freiburg im Breisgau
Register Court: Amtsgericht Freiburg im Breisgau, HRB 701080
Managing Directors: Dr. med. Philipp Daumke, Dr. Kornél Markó