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

Integrate eclipse transformer with Batavia #45

Closed
ropalka opened this issue May 29, 2020 · 10 comments
Closed

Integrate eclipse transformer with Batavia #45

ropalka opened this issue May 29, 2020 · 10 comments

Comments

@ropalka
Copy link
Collaborator

ropalka commented May 29, 2020

https://github.com/eclipse/transformer

@ropalka
Copy link
Collaborator Author

ropalka commented Jun 3, 2020

It is not possible to integrate Eclipse transformer with Batavia project at the moment because both projects use different abstractions. Batavia's main abstraction is Resource - which is any entry inside jar file or any file on file system. The Eclipse transformer's abstraction is CLI and passing it configuration args. (FYI @jfdenise @scottmarlow)

@jfdenise
Copy link
Contributor

jfdenise commented Jun 3, 2020

Raw thinking, could we have an integration at a higher level to handle jar transformation only? Mainly at the Tools API level? Batavia would abstract the transformer in use. Galleon would still be able to select the transformer tools backend.

@ropalka
Copy link
Collaborator Author

ropalka commented Jun 3, 2020

What we could do is to modify Batavia project to be configurable similar way like Eclipse transformer is, that is we should introduce Option abstraction, TransformerBuilder.addOption(name, value) methods, maybe Changes abstraction including Transformer.getChanges() method?

@ropalka
Copy link
Collaborator Author

ropalka commented Jun 3, 2020

Our new abstractions would become Option and Change etc instead of Transformer.Resource
and we would move bunch of code from Tools API to Transformer API, WDYT @scottmarlow ?

@scottmarlow
Copy link
Collaborator

Our new abstractions would become Option and Change etc instead of Transformer.Resource
and we would move bunch of code from Tools API to Transformer API,
Do you mean to move bunch of code from Batavia Tools API to Eclipse Transformer API? I assume you mean Batavia Transformer API, as I don't see an API in Eclipse Transformer. I think that this idea is good, unless we can think of a way to change Eclipse Transformer to be easier to integrate with.

issues/28 is for moving the cli into its own project, to better support maven/gradle drivers. Should we stick to passing parameters the Eclipse Transformer CLI style interface way or do we want a better integration point than org.eclipse.transformer.Transformer#runWith?

@scottmarlow
Copy link
Collaborator

Raw thinking, could we have an integration at a higher level to handle jar transformation only? Mainly at the Tools API level? Batavia would abstract the transformer in use. Galleon would still be able to select the transformer tools backend.

If the question is could we remove ToolUtils#transformClassFile, I think we could, if that helps our integration with Eclipse Transformer.

@ropalka
Copy link
Collaborator Author

ropalka commented Jun 3, 2020

Our new abstractions would become Option and Change etc instead of Transformer.Resource
and we would move bunch of code from Tools API to Transformer API,
Do you mean to move bunch of code from Batavia Tools API to Eclipse Transformer API? I assume you mean Batavia Transformer API, as I don't see an API in Eclipse Transformer. I think that this idea is good, unless we can think of a way to change Eclipse Transformer to be easier to integrate with.

issues/28 is for moving the cli into its own project, to better support maven/gradle drivers. Should we stick to passing parameters the Eclipse Transformer CLI style interface way or do we want a better integration point than org.eclipse.transformer.Transformer#runWith?

It looks like Eclipse transformer is little bit behind us WRT proper separation of tools vs. transformer code. Anyway they are going to move the proper way.

@ropalka
Copy link
Collaborator Author

ropalka commented Jun 3, 2020

Raw thinking, could we have an integration at a higher level to handle jar transformation only? Mainly at the Tools API level? Batavia would abstract the transformer in use. Galleon would still be able to select the transformer tools backend.

If the question is could we remove ToolUtils#transformClassFile, I think we could, if that helps our integration with Eclipse Transformer.

Yes, that was the question @scottmarlow . It seems we have three options on table ATM :

  1. short term - we adjust our API to be able to integrate via current Eclipse transformer CLI
  2. middle term - wait little bit and see what will be the outcome of ISSUE-28
  3. long term - participate on Eclipse project and adjust their API little bit to be better integrable with our API

@jfdenise
Copy link
Contributor

jfdenise commented Jun 4, 2020

With respect to integration in galleon I would vote for 2) and 3). Currently as soon as we have an eclipse transformer release that integrates the fix we need, I could release a galleon-plugins that calls into eclipse transformer directly. Then switching to use Batavia when ready would be an easy task.

@ropalka
Copy link
Collaborator Author

ropalka commented Aug 6, 2020

Initial Eclipse transformer integration is done. Thanks @scottmarlow for review, @jfdenise for valuable feedback.

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

3 participants