Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Publish a jar artifact to maven central/bintray/jfrog #18

Open
JLLeitschuh opened this issue Sep 10, 2018 · 4 comments
Open

Publish a jar artifact to maven central/bintray/jfrog #18

JLLeitschuh opened this issue Sep 10, 2018 · 4 comments

Comments

@JLLeitschuh
Copy link

It looks like @oehme has already done this for Gradle's profiler: https://mvnrepository.com/artifact/com.github.oehme/jfr-flame-graph

It would be nice if there were an official release.

@oehme
Copy link
Contributor

oehme commented Sep 11, 2018

What I did there was a total hack, repackaging parts of the Oracle JDK. I actually plan to remove that again to avoid any raised eyebrows due to licensing.

What we could publish is a version without the Oracle JDK stuff and find it through a custom classloader at runtime. That would require a slight rewrite of the code. On the plus side it would allow us to finally support different JDK versions.

@JLLeitschuh
Copy link
Author

Doesn't this require the JFR data which can only be generated with the Oracle JDK anyways?

My eventual goal is to create a Gradle plugin that generates flame graphs from your Gradle tests.
I'm trying to find a library that does most of the leg work for me so all I have to do is wrap it as a Gradle plugin.

@oehme
Copy link
Contributor

oehme commented Sep 11, 2018

Doesn't this require the JFR data which can only be generated with the Oracle JDK anyways?

That's not the point - We can't go repackaging Oracle-licensed code and pushing it to some repository.

JFR is part of OpenJDK since Java 11. But still, repackaging that is not desirable as we'd be binding us to a specific version of the inlined code.

The API has changed in Java 9 and changed again in Java 11. That's why a runtime lookup and some dynamic trickery will be necessary to make it work on as many systems as possible.

In short: Create a JfrReader abstraction which knows how to deal with different JFR APIs and gives back a stream of events which we can then transform into flamegraph data.

@JLLeitschuh
Copy link
Author

Okay. This sounds like a plan.

I'm happy to help out where needed. I've never worked with JFR or it's API. Please try keep me in the loop on this one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants