Input needed (Tycho & OSGi vs Maven)!

[Mario Torre]

I like #4 too, seems very clean.

Cheers,
Mario

—
Mario Torre
Associate Manager, Software Engineering
Red Hat GmbH
9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898
________________________________
From: jmc-dev <jmc-dev-bounces at openjdk.java.net> on behalf of Marcus Hirt <marcus.hirt at oracle.com>
Sent: Monday, August 13, 2018 3:37:02 PM
To: jmc-dev at openjdk.java.net
Subject: Re: Input needed (Tycho & OSGi vs Maven)!

Hi all,

I am leaning towards FQN (alternative 4), unless there is a way to:

1. Build core with the Maven groupID and artifactID from alternative 1.
2. Get the Tycho and the p2-maven-plugin to play well with a Bundle-SymbolicName that
   is built up from both the groupID _and_ artifactID.

Kind regards,
Marcus

From: Isuru Perera <chrishantha at gmail.com>
Date: Monday, 13 August 2018 at 13:28
To: <marcus.hirt at oracle.com>
Cc: <jmc-dev at openjdk.java.net>
Subject: Re: Input needed (Tycho & OSGi vs Maven)!

Hi,

I think that the option #4 is good. It'll look artificial to non-OSGi programs, but that's just the name. It's better to have FQN for OSGi programs. As a developer, I know that these artifacts are mainly used by the JMC tool, based on an OSGi framework. I do not mind the artifact id in non-OSGi programs as long as I can get the dependencies from the Maven Central and use JMC core libraries to consume JFR APIs.

Currently, I'm getting the artifacts from local JDK path (https://github.com/chrishantha/jfr-flame-graph/blob/d563550dcb2b3d87ee78524ff01d712102f8c6d0/gradle/missioncontrol.gradle) and I could avoid this workaround if the JMC core libraries are available in Maven Central.

Thank you.

On Mon, Aug 13, 2018 at 3:46 PM Marcus Hirt <mailto:marcus.hirt at oracle.com> wrote:
Hi all,

We have an issue that requires your input. We want to make the JMC core
libraries available at maven central. For that to work, we must make the core
artifacts independently buildable (i.e. not use Tycho to build them as part
of everything else). This will mean that the core libraries will be consumed
as part of the other third-party dependencies.

Now, since these third-party dependencies are exposed to OSGi by artifact name
only (not by group id and artifact id), we have the following alternatives:

1. Use group id: org.openjdk.jmc, artifact id: common.
   This is probably the nicest way to consume this from non-OSGi programs.
   However, from the OSGi side, this will be consumed as just common.

2. Use group id: org.openjdk, artifact id: jmc.common.
   This provides a bit of a qualifier (jmc) for OSGi programs. Uses a very wide
   group.

3. Use group id: org.openjdk.jmc, artifact id: jmc.common.
   Also provides a bit of a qualifier (jmc) for OSGi programs. Uses a less wide
   group. Will look artificial to non-OSGi programs.

4. Use group id: org.openjdk.jmc, artifact id: org.openjdk.jmc.common.
   Provides an FQN for OSGi-programs. Will look artificial to non-OSGi programs.

What do you guys think?

Kind regards,
Marcus



--
Isuru Perera
http://about.me/chrishantha