Comments (10)
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)
from batavia.
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.
from batavia.
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?
from batavia.
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 ?
from batavia.
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?
from batavia.
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.
from batavia.
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.
from batavia.
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 :
- short term - we adjust our API to be able to integrate via current Eclipse transformer CLI
- middle term - wait little bit and see what will be the outcome of ISSUE-28
- long term - participate on Eclipse project and adjust their API little bit to be better integrable with our API
from batavia.
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.
from batavia.
Initial Eclipse transformer integration is done. Thanks @scottmarlow for review, @jfdenise for valuable feedback.
from batavia.
Related Issues (20)
- Transform the legacy JAXB xml namespace to the EE 9 one in classes and schema documents
- Add new "direct" rule for JSF RESOURCE_IDENTIFIER
- JSF converter IDs not transformed (xHTML)
- JSF, AJAX-related request headers not transformed HOT 1
- Transforming the javax.annotation root package risk breaking non-Jakarta Annotations use of that package HOT 13
- Add the ability to exclude files to the SourceTransformerMojo
- Add option to allow over-write of target file
- Add direct constant string transformation properties needed for jastow JSP generation
- Support jakarta-direct.properties in Eclipse Transformer integration code
- Fix Jasper library transformation issues
- Batavia transformers must support reading of config files from file system (not just class path)
- No dependencies tranformer generates 'utility' classes in wrong packages
- No dependencies transformer must generate 'utility' classes only once per package
- No dependencies transformer counts java bytecode ops size improperly
- No dependencies transformer generates utility class methodref constant pool items with wrong 'zero' index
- JSP files are not transformed
- Transform SSLInformationAssociationHandler constants to jakarta namespace
- Support all javax.servlet properties HOT 3
- Make the API not filesystem dependent HOT 3
- Deal with jaxb context factory properties HOT 6
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from batavia.