[eclipse-dev] Eclipse SDK @ Maven Central - please help improve & spread

[Stephan Herrmann <stephan.herrmann@xxxxxxxxx>]

Hi,

You may have seen [1] that starting with Neon.2 all artifacts of Eclipse SDK
are available from Maven Central. I believe this is an important step to
acknowledge those adopters that cannot consume our artifacts via p2.

As Neon.3 GA is approaching, I'm preparing the next upload (before all this
will be handed over to Sravan to - hopefully - become just one small routine
step in all future releases).

Today I'm asking for some help to make this a full success:

== Iron out last glitches & quirks ==

=== source bundles ===
First, for several bundles we don't ship suitable source bundles.
I already filed a couple of bugs [2][3]. While it's too late for Neon,
I think it would be great if the Oxygen release would produce proper
source bundles for everything we ship. Note, that Maven Central actually
*requires* source bundles, so currently we have to create them on the fly
when publishing to Maven - which adds undesirable complexity to the build
and is quite fragile actually. See also this list: [4]

=== proper maven metadata for OSGi fragments ===
For the most part, metadata found in our p2 repos are perfectly suited
for generating fully sufficient pom files (using CBI aggregator).
For fragments, however, we have some inherent difficulties, because p2
makes heavy use of platform filters, for which no direct equivalent
seems to exists in Maven.

I have learned that some adopters consume things like SWT by directly
depending on one of the platform specific fragments, but I think this
is against the spirit of Eclipse/SWT. So I have made an attempt at
supporting platform independent consumption of our artifacts to the
degree possible [5][6]. The approach may be a bit unconventional, so I'd
like to ask if anybody is aware of an approach that achieves the same
decoupling (no unwanted platform dependence in poms) while better
integrating with Maven. To be specific and using the example of SWT:
I believe it should be possible to develop a library that depends on
SWT while leaving the choice of platform to the user of that library.
Apparently this is a tough challenge in Maven land.
Please comment in https://bugs.eclipse.org/510186.

=== have we captured "everything"? ===
Scripts are pulling artifacts from the aggregated SDK update site.
We may be producing some artifacts which are not intended for
installation in Eclipse but still worth publishing to Maven Central.
One such example is the jdt batch compiler ("ecj"), which wasn't
published to Maven as of Neon.2 but will be included for Neon.3.

Are there any other artifacts that should be included, but aren't yet?

== Spread the word ==

You may help the adopters of your respective artifacts by spreading the
word and also soliciting feedback regarding consumeability. I believe
you know best, who are those adopters and on what channels they are
listening. Several project web sites should probably list the coordinates
where artifacts can be found in Maven. BTW, the group IDs are:
- org.eclipse.platform
- org.eclipse.pde
- org.eclipse.jdt
where platform comprises everything produced by the Eclipse Project
except for PDE and JDT.

In particular, whatever strategy we'll finally use for fragments, we'll
need to inform our adopters about the intended usage.

thanks,
Stephan

[1] https://objectteams.wordpress.com/2017/01/09/eclipse-neon-2-is-on-maven-central/
[2] https://bugs.eclipse.org/510973
[3] https://bugs.eclipse.org/510976
[4] https://hudson.eclipse.org/releng/view/Publish%20to%20Maven%20Central/job/CBIaggregator/ws/sourceBundles.txt
[5] https://bugs.eclipse.org/510186#c8
[6] https://bugs.eclipse.org/510186#c12