m2e (or its default catalouge) ships an outdated version of org.sonatype.tycho.m2e interferring with felix-bundle-plugin

[laeubi]

I have org.sonatype.tycho.m2e_0.8.1.201704211436 in my eclipse (seems to be either installed automatic or included in eclipse).

This does not contain the following change tesla/m2eclipse-tycho@22db079 and thus interferes currently with the maven-bundle plugin from felix.

[mickaelistria]

Default catalog is in https://github.com/takari/m2e-discovery-catalog . Good luck with it!
If you have the energy to migrate it back to https://github.com/eclipse-m2e/m2e-discovery-catalog , it would be awesome. I tried and go discourage by the complexity of a build (for something that's just supposed to be a list of metadata)...

[laeubi]

@fbricon seems to recently worked on this, maybe he can give some insights? I think m2e should be in charge of the default catalogue.

go discourage by the complexity of a build (for something that's just supposed to be a list of metadata)..

Do you remember any key points that maxes this complex? E.g is the build using old maven/tycho/whatever versions and never versions fail? I will try to take a look later on also...

[laeubi]

@mickaelistria I'm a bit confused, what is the origin of the connectorUrl? How are items deployed there?

e.g. if I take a look here I have no idea where/when a release is made, obviously the 0.7.0 is not recent (as we have 0.8 in eclipse) but even this seems not be the latest version as it does not contain the fix for felix bundle plugin... so maybe the first step would be to make anew release of m2eclipse-tycho and let the discovery catalouge use this, but I don't understand how this is supposed to work...?

[laeubi]

Another question, is https://github.com/takari/m2eclipse-discovery recent? It seems to reference "supported" m2e versions but they are a bit outdated and the discovery-catalogue seems to hard code 1.4 m2e version.

So is m2e in charge of the cataloge? Does we reuse some kind of eclipse functionality? Can we change connector handling in m2e (e.g. use another format / approach to discover connectors?).

From what I have been aware of (as a user) I only remember this dialog asking me if I like to install a connector, but in the catalouge there seems to be doing much more (categories, icons, additional plugins) ...

[fbricon]

The complexity of the m2eclipse-catalog stems from at least 2 facts:

• it depends on a maven plugin (https://github.com/takari/m2eclipse-discovery) that's no longer maintained, which contains hard coded versions of m2e version. It should probably be contributed and maintained as a m2e subproject (with all the paperwork involved).
• the build actually performs validity checks of each listed connector, i.e. checks that each plugin's update site is available and contains the proper metadata. So it's supposed to give you a "safe" list of metadata (at least from the moment the catalog was built)

So, in the past m2eclipse-discovery builds were built on Sonatype, then Takari's Build infra, which was able to publish the catalogs directly to the most reliable place there is, aka https://repo1.maven.org/maven2/.m2e/discovery-catalog/. That build infra is gone, it's not possible to publish there anymore. I don't expect Sonatype to give us the ability to keep pushing bits to Mavent Central anymore. Nowadays, the catalog is published to Github Pages via a Github Workflow: https://github.com/takari/m2e-discovery-catalog/blob/master/.github/workflows/.deploy.yml. It's super simple,(doesn't deal with catalog versioning)but then Github outages are more frequent then Maven Central (can anyone remember a Maven Central outage?).

I think today the main issue is the catalog needs to be built targeting old m2e versions as in https://github.com/takari/m2e-discovery-catalog/blob/master/org.eclipse.m2e.discovery.oss/src/main/resources-filtered/connectors.xml#L75. Updating those versions requires owning m2eclipse-discovery, but even having to maintain a list of up to date m2e version there doesn't scale. While being inconvenient, the catalog publishing still works anyway, in a very hacky way.

Now, if you want to update m2eclipse-tycho in the catalog, open a PR on https://github.com/takari/m2e-discovery-catalog/blob/master/org.eclipse.m2e.discovery.oss/src/main/resources-filtered/connectors.xml#L60, update it to m2eclipse-tycho/0.9.0/N/0.9.0.201811261502/ and once merged, the catalog will be updated in https://github.com/takari/m2e-discovery-catalog/tree/gh-pages/catalogs

[laeubi]

update it to m2eclipse-tycho/0.9.0/N/0.9.0.201811261502/

Thanks for the guidance and insights I'll do that right now, just for curiosity how do you know that specific version string exits?

• it depends on a maven plugin (https://github.com/takari/m2eclipse-discovery) that's no longer maintained, which contains hard coded versions of m2e version.

It seems you and @ifedorenko are the only contributors, would you mind to release this to EPL2.0? Shouldn't then be to much hassle to integrate it (I'm a bit uncertain if it should be part of m2e or better tycho-extras?)

I don't expect Sonatype to give us the ability to keep pushing bits to Mavent Central anymore.

Why not? Could it be deployed as a regular artifact?

but even having to maintain a list of up to date m2e version there doesn't scale.

But what are these then for anyways?

[fbricon]

update it to m2eclipse-tycho/0.9.0/N/0.9.0.201811261502/

Thanks for the guidance and insights I'll do that right now, just for curiosity how do you know that specific version string exits?

Same as for the catalog, takari m2e connectors were deployed to Maven Central, in https://repo1.maven.org/maven2/.m2e/connectors/m2eclipse-tycho/

• it depends on a maven plugin (https://github.com/takari/m2eclipse-discovery) that's no longer maintained, which contains hard coded versions of m2e version.

It seems you and @ifedorenko are the only contributors, would you mind to release this to EPL2.0? Shouldn't then be to much hassle to integrate it (I'm a bit uncertain if it should be part of m2e or better tycho-extras?)

It's unclear what the current license is. A single file (https://github.com/takari/m2eclipse-discovery/blob/42b369d18955a71e8cfa459cf784a63cab6f9d42/org.sonatype.m2e.discovery.publisher.maven-plugin/src/main/java/org/sonatype/m2e/discovery/publisher/M2eDiscoveryMetadataGeneratorMojo.java) mentions ASL2. Dunno what the rest of the project is supposed to be. That's a question for @jvanzyl.

I don't expect Sonatype to give us the ability to keep pushing bits to Mavent Central anymore.

Why not?

Because it was happening when @jvanzyl was working for Sonatype. It's no longer the case. I don't know of any other case where 3rd parties could deploy non-maven artifacts to Maven Central nilly-willy.

Could it be deployed as a regular artifact?

Probably yes

but even having to maintain a list of up to date m2e version there doesn't scale.

But what are these then for anyways?

It lets you declare which connectors are compatible with which m2e versions. If a connector depends on a new m2e API, then it shouldn't be listed in the UI, when running on an older m2e version.

[laeubi]

It lets you declare which connectors are compatible with which m2e versions. If a connector depends on a new m2e API, then it shouldn't be listed in the UI, when running on an older m2e version.

But if we only support m2e 1.4 and can't upgrade it seems a bit useless...

I don't know of any other case where 3rd parties could deploy non-maven artifacts to Maven Central nilly-willy.

At least is is common to deploy even zip files to maven central as regular artifacts so what makes the connector part special here? Given that we now have mvn: protocoll support in the IDE these could then even be reverenced as mvn:org.eclipse.m2e:catlouge:1.0 or something It seems obvious to have m2e consume whats ever possible from maven itself, so I wonder: do we need these update-sites? Can't the ctalouge simply reference (a list of) maven coordinates where the connectors are present?

[fbricon]

It lets you declare which connectors are compatible with which m2e versions. If a connector depends on a new m2e API, then it shouldn't be listed in the UI, when running on an older m2e version.

But if we only support m2e 1.4 and can't upgrade it seems a bit useless...

Until this is fixed, yes, totally.

I don't know of any other case where 3rd parties could deploy non-maven artifacts to Maven Central nilly-willy.

At least is is common to deploy even zip files to maven central as regular artifacts so what makes the connector part special here? Given that we now have mvn: protocoll support in the IDE these could then even be reverenced as mvn:org.eclipse.m2e:catlouge:1.0 or something It seems obvious to have m2e consume whats ever possible from maven itself, so I wonder: do we need these update-sites? Can't the ctalouge simply reference (a list of) maven coordinates where the connectors are present?

The catalog discovery part on the m2e side depends on a combination of Mylyn/p2 API. If they support the fancy new maven coordinates from the recent TP improvements, then have at it.

[laeubi]

I have created takari/m2e-discovery-catalog#70 now.

[HannesWell]

I have org.sonatype.tycho.m2e_0.8.1.201704211436 in my eclipse (seems to be either installed automatic or included in eclipse).

For your info, this is likely installed by M2E's Oomph setup. See the P2 Director task named m2e - connectors in the m2e.setup.