-
Notifications
You must be signed in to change notification settings - Fork 320
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
jdt.compiler.(apt|tool) gone #2134
Comments
cc @LorenzoBettini this breaks the changes with eclipse/xtext-maven#146 |
Signed-off-by: Christian Dietrich <[email protected]>
the new bundle also seems not to be a fragment anymore |
only explicit usage in maven/gradle (here we still use old version) and wizard, |
IIRC, It was announced in the cross project dev mailing list as the result of refactoring of ecj. Probably for backward compatibility we could add jdt.feature to the tp? Or maybe those fragments are not needed anymore also for order tp now that we have pinned versions? |
so to be on the safe side we need to add a dependency to |
|
@LorenzoBettini could you try that with your usecase for eclipse/xtext-maven#146 |
Have you actually read the notes?
|
…(tool|apt) Signed-off-by: Christian Dietrich <[email protected]>
i was confused by the second "problem" that point do "ant" like environments |
Signed-off-by: Christian Dietrich <[email protected]>
Do you have non OSGI based use case where Xtext used in a plain Java application (means, no dependencies resolving via manifests through OSGI container)? In that case you need to add batch compiler bundle to the classpath. |
only if users do not use maven or gradle or tycho to provide the classpath |
@iloveeclipse @merks can you tell / do you know if there are is a maven snapshot repo available for jdt and platform meanwhile? |
We do use xtext from OSGI context, and that's is a different problem (too much of context) :) |
This job should be doing that https://ci.eclipse.org/releng/view/Publish%20to%20Maven/ With results published here: https://repo.eclipse.org/content/repositories/eclipse-snapshots/ This JDT stuff indeed looks very new: https://repo.eclipse.org/content/repositories/eclipse-snapshots/org/eclipse/jdt/ |
Note, it still has ecj and doesn't have compiler batch. Also note, ecj is the compiler batch bundle. |
What is there is as expected and is correct... There is this mapping rule: That produces the expected ecj artifact name: That artifact has the expected symbolic name: And eventually, when release, it will end up here as before: https://repo1.maven.org/maven2/org/eclipse/jdt/ecj/ So what we see in this snapshot repository is what we will see after it's published to Maven central... |
=> we should do a branch where we update to latest platform
to the dev bom.
|
Signed-off-by: Christian Dietrich <[email protected]>
Signed-off-by: Christian Dietrich <[email protected]>
Signed-off-by: Christian Dietrich <[email protected]>
Signed-off-by: Christian Dietrich <[email protected]>
Signed-off-by: Christian Dietrich <[email protected]>
Signed-off-by: Christian Dietrich <[email protected]>
Signed-off-by: Christian Dietrich <[email protected]>
[eclipse-xtext/xtext#2134] remove dependency to obsolte jdt.compiler.(tool|apt)
[eclipse-xtext/xtext#2134] replace compiler.tool+apt with batch
testing blocked by eclipse-platform/eclipse.platform.releng.aggregator#811 |
have to wait for testing until the deploy issue consuming from gradle is resolved or 4.27 is released |
Signed-off-by: Christian Dietrich <[email protected]>
Signed-off-by: Christian Dietrich <[email protected]>
Signed-off-by: Christian Dietrich <[email protected]>
Signed-off-by: Christian Dietrich <[email protected]>
Signed-off-by: Christian Dietrich <[email protected]>
Signed-off-by: Christian Dietrich <[email protected]>
Signed-off-by: Christian Dietrich <[email protected]>
Signed-off-by: Christian Dietrich <[email protected]>
jdt.compiler.(apt|tool) gone seems to be removed from jdt
@iloveeclipse @szarnekow do you know if this is intentional?
what is the replacement?
eclipse-jdt/eclipse.jdt.core@457e222
of course it will be painful to make this work with backwards compatibility
The text was updated successfully, but these errors were encountered: