Remove strict requirement to bundle javax.inject #69

HannesWell · 2023-11-12T11:04:45Z

EMF-Parsly is one of few remaining projects that still pull the javax.inject bundles originating from Orbit into the Eclipse SimRel and it would therefore be good to get rid of that strict requirement.
Since the runtime Plugin is empty I assume it is just used to pull in some bundles into a (propably non-OSGi?) runtime.
If the required-bundle should be replaced by a Import-Package for javax.inject please let me know.

Context: eclipse-simrel/simrel.build#49

LorenzoBettini · 2023-11-12T12:29:53Z

@HannesWell thanks! I think that was inherited from xtext long time ago. Let's see whether the builds succeed.

LorenzoBettini · 2023-11-12T12:31:58Z

The builds fail because some of those classes (wrongly, I'd say) use javax.inject.Provider instead of the guice type.

HannesWell · 2023-11-12T12:51:32Z

Thanks @LorenzoBettini for the quick response.

The builds fail because some of those classes (wrongly, I'd say) use javax.inject.Provider instead of the guice type.

The class actually uses already the guice type, but com.google.inject.Provider extends javax.inject.Provider and therefore (at least the compiler) needs javax.inject too:

Error:  Failed to execute goal org.eclipse.tycho:tycho-compiler-plugin:2.7.5:compile (default-compile) on project org.eclipse.emf.parsley.runtime.common: Compilation failure: Compilation failure: 
Error:  /home/runner/work/emf-parsley/emf-parsley/plugins/org.eclipse.emf.parsley.runtime.common/src/org/eclipse/emf/parsley/runtime/service/ProviderModule.java:[31] 
Error:  	bind.toProvider((Provider<? extends Object>) instance);
Error:  	^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Error:  The type javax.inject.Provider cannot be resolved. It is indirectly referenced from required .class files

I added javax.inject as import so now hopefully the build passes.

LorenzoBettini · 2023-11-12T13:07:11Z

I was suggesting something else: instead of using Provider from javax.inject, use Provider from Google Guice

HannesWell · 2023-11-12T13:24:03Z

I was suggesting something else: instead of using Provider from javax.inject, use Provider from Google Guice

It already uses the provider from Guice. But com.google.inject.Provider extends javax.inject.Provider and therefore (at least the compiler) needs javax.inject too. (Sorry this statement was probably unclear due to quoting going wrong in my previous comment).

So there is nothing much that can be done in the code. :/

LorenzoBettini · 2023-11-12T13:27:34Z

The build still fails though.. I don't remember how xtext dealt with the same situation cc @cdietrich

HannesWell · 2023-11-12T13:30:39Z

The build still fails though.. I don't remember how xtext dealt with the same situation cc @cdietrich

Yes. But what was because org.eclipse.emf.parsley.common uses the Guice Provider too and now needs the import, since the reexport is removed from org.eclipse.emf.parsley.runtime.common.
But with the latest state the build succeeded locally on my computer.

cdietrich · 2023-11-12T13:42:01Z

which guice do you use in tp?

LorenzoBettini · 2023-11-12T13:45:42Z

@HannesWell the tests wrongly use javax.inject.Inject instead of guice inject

@cdietrich I'm still at 2022-12, I'll update deps next week

HannesWell · 2023-11-12T14:54:58Z

Ah, didn't noticed before that there are different build setups.

@HannesWell the tests wrongly use javax.inject.Inject instead of guice inject

I changed the tests to use com.google.inject.Inject and adjusted the Manifests of the E4 examples (I assume that you don't want to/can migrate them to jakarta yet).
The other build setup now succeeded locally too. Lets see if there are more to consider :)

LorenzoBettini · 2023-11-12T16:42:42Z

Thanks @HannesWell it works now.

I'd like to avoid having to specify javax.inject imports though: the clients projects would not work anymore now.

If I moved to Jakarta would that solve the problem?

Or, @cdietrich , moving to the new version of xtext/guice would solve the problem?

HannesWell · 2023-11-12T16:50:48Z

Thanks @HannesWell it works now.

Great!

I'd like to avoid having to specify javax.inject imports though: the clients projects would not work anymore now.

If I moved to Jakarta would that solve the problem?

That's right if they relied on the reexport of javax.inject and did not specify the import by themself, then yes they will not work anymore without changes. But since reexports can cause a lot of trouble (although they seem convenient in the first moment) it is generally not recommended to use them.
I think this is a similar discussion as in eclipse-xtext/xtext#2668.

But yes, if parsley would require the jakarta.inject.jakarta.inject-api instead, this would at least solve the SimRel third-party dependency problem. But they are probably not available in the TP emf-parsley currently uses.

cdietrich · 2023-11-12T16:50:52Z

Guide 7 has no dep or support for Javax.inject anymore

LorenzoBettini · 2023-11-13T12:19:09Z

@HannesWell thanks for the contribution! I'll merge it for now, and when I switch to new Xtext and Guice (#71 ) I'll remove all the import of javax.inject from MANIFESTs.

@cdietrich thanks for the confirmation about the new Guice.

LorenzoBettini · 2023-11-13T12:37:34Z

@HannesWell did you try to setup the development environment with Oomph?

I'm getting errors on the Xtend file EditingDomainTest.xtend: these two imports cannot be resolved:

import org.eclipse.emf.parsley.tests.util.GlobalAdapterFactoryEditingDomainModule
import org.eclipse.emf.parsley.tests.util.SingletonAdapterFactoryEditingDomainModule

I suspect that's something to do with javax.inject. The Oomph setup project builder also reports this in the "Error Log":

java.lang.IllegalStateException: Could not create binding for 'org.eclipse.emf.parsley.tests.util.SingletonAdapterFactoryEditingDomainModule' in context of project 'org.eclipse.emf.parsley.tests'.
	at org.eclipse.xtext.common.types.access.jdt.JdtBasedTypeFactory.createType(JdtBasedTypeFactory.java:338)
	at org.eclipse.xtext.common.types.access.jdt.JdtBasedTypeFactory.createType(JdtBasedTypeFactory.java:415)
	at org.eclipse.xtext.common.types.access.jdt.JdtBasedTypeFactory.createType(JdtBasedTypeFactory.java:1)
	at org.eclipse.xtext.common.types.access.jdt.JdtTypeMirror.initialize(JdtTypeMirror.java:68)
	at org.eclipse.xtext.common.types.access.TypeResource.doLoad(TypeResource.java:135)
	at org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(ResourceImpl.java:1563)
	at org.eclipse.xtext.common.types.access.TypeResource.load(TypeResource.java:121)
	at org.eclipse.xtext.common.types.access.jdt.JdtTypeProvider.createResourceAndFindType(JdtTypeProvider.java:290)
	at org.eclipse.xtext.common.types.access.jdt.JdtTypeProvider.findObjectTypeInJavaProject(JdtTypeProvider.java:273)
	at org.eclipse.xtext.common.types.access.jdt.JdtTypeProvider.doFindObjectType(JdtTypeProvider.java:216)
	at org.eclipse.xtext.common.types.access.jdt.JdtTypeProvider.findObjectType(JdtTypeProvider.java:196)
	at org.eclipse.xtext.common.types.access.jdt.JdtTypeProvider.doFindTypeByName(JdtTypeProvider.java:154)
	at org.eclipse.xtext.common.types.access.jdt.JdtTypeProvider.findTypeByName(JdtTypeProvider.java:163)
	at org.eclipse.xtext.common.types.xtext.AbstractTypeScope.getSingleElement(AbstractTypeScope.java:60)
	at org.eclipse.xtend.core.scoping.LocalResourceFilteringTypeScope.getSingleElement(LocalResourceFilteringTypeScope.java:42)
	at org.eclipse.xtend.core.scoping.RecordingTypeScope.getSingleElement(RecordingTypeScope.java:38)
	at org.eclipse.xtext.common.types.xtext.AbstractTypeScope.getSingleElement(AbstractTypeScope.java:55)
	at org.eclipse.xtext.scoping.impl.AbstractScope.getSingleElement(AbstractScope.java:109)
	at org.eclipse.xtext.linking.impl.DefaultLinkingService.getLinkedObjects(DefaultLinkingService.java:115)
	at org.eclipse.xtext.linking.lazy.LazyLinkingResource.getEObject(LazyLinkingResource.java:266)
	at org.eclipse.xtext.xbase.resource.BatchLinkableResource.getEObject(BatchLinkableResource.java:120)
	at org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getEObject(ResourceSetImpl.java:223)
	at org.eclipse.emf.ecore.util.EcoreUtil.resolve(EcoreUtil.java:209)
	at org.eclipse.emf.ecore.util.EcoreUtil.resolve(EcoreUtil.java:269)
	at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eResolveProxy(BasicEObjectImpl.java:1516)
	at org.eclipse.xtext.xtype.impl.XImportDeclarationImpl.getImportedType(XImportDeclarationImpl.java:262)
	at org.eclipse.xtend.core.scoping.XtendImportedNamespaceScopeProvider.getImportScope(XtendImportedNamespaceScopeProvider.java:285)
	at org.eclipse.xtend.core.scoping.XtendImportedNamespaceScopeProvider$1.get(XtendImportedNamespaceScopeProvider.java:132)
	at org.eclipse.xtend.core.scoping.XtendImportedNamespaceScopeProvider$1.get(XtendImportedNamespaceScopeProvider.java:1)
	at org.eclipse.xtext.util.OnChangeEvictingCache.get(OnChangeEvictingCache.java:79)
	at org.eclipse.xtend.core.scoping.XtendImportedNamespaceScopeProvider.getScope(XtendImportedNamespaceScopeProvider.java:120)
	at org.eclipse.xtext.xbase.scoping.batch.DelegatingScopes.getScope(DelegatingScopes.java:42)
	at org.eclipse.xtext.xbase.scoping.batch.TypeScopes.createTypeScope(TypeScopes.java:60)
	at org.eclipse.xtext.xbase.scoping.batch.XbaseBatchScopeProvider.getScope(XbaseBatchScopeProvider.java:113)
	at org.eclipse.xtext.xbase.annotations.typesystem.XbaseWithAnnotationsBatchScopeProvider.getScope(XbaseWithAnnotationsBatchScopeProvider.java:54)
	at org.eclipse.xtext.linking.impl.DefaultLinkingService.getScope(DefaultLinkingService.java:59)
	at org.eclipse.xtext.linking.impl.DefaultLinkingService.getLinkedObjects(DefaultLinkingService.java:108)
	at org.eclipse.xtext.linking.lazy.LazyLinkingResource.getEObject(LazyLinkingResource.java:266)
	at org.eclipse.xtext.xbase.resource.BatchLinkableResource.getEObject(BatchLinkableResource.java:120)
	at org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getEObject(ResourceSetImpl.java:223)
	at org.eclipse.emf.ecore.util.EcoreUtil.resolve(EcoreUtil.java:209)
	at org.eclipse.emf.ecore.util.EcoreUtil.resolve(EcoreUtil.java:269)
	at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eResolveProxy(BasicEObjectImpl.java:1516)
	at org.eclipse.xtext.common.types.impl.JvmTypeReferenceImplCustom.eResolveProxy(JvmTypeReferenceImplCustom.java:32)
	at org.eclipse.xtext.common.types.impl.JvmParameterizedTypeReferenceImpl.getType(JvmParameterizedTypeReferenceImpl.java:114)
	at org.eclipse.xtend.core.jvmmodel.XtendJvmModelInferrer.initialize(XtendJvmModelInferrer.java:389)
	at org.eclipse.xtend.core.jvmmodel.XtendJvmModelInferrer$5.run(XtendJvmModelInferrer.java:279)
	at org.eclipse.xtend.core.jvmmodel.XtendJvmModelInferrer$3.run(XtendJvmModelInferrer.java:219)
	at org.eclipse.xtext.xbase.resource.BatchLinkableResource.ensureJvmMembersInitialized(BatchLinkableResource.java:232)
	at org.eclipse.xtext.xbase.jvmmodel.JvmModelAssociator.getOrInstall(JvmModelAssociator.java:113)
	at org.eclipse.xtext.xbase.jvmmodel.JvmModelAssociator.getLogicalContainerMapping(JvmModelAssociator.java:128)
	at org.eclipse.xtext.xbase.jvmmodel.JvmModelAssociator.getAssociatedExpression(JvmModelAssociator.java:135)
	at org.eclipse.xtext.xbase.typesystem.internal.LogicalContainerAwareReentrantTypeResolver.recordExpressions(LogicalContainerAwareReentrantTypeResolver.java:420)
	at org.eclipse.xtext.xbase.typesystem.internal.LogicalContainerAwareReentrantTypeResolver.prepare(LogicalContainerAwareReentrantTypeResolver.java:414)
	at org.eclipse.xtext.xbase.typesystem.internal.LogicalContainerAwareReentrantTypeResolver.computeTypes(LogicalContainerAwareReentrantTypeResolver.java:702)
	at org.eclipse.xtend.core.typesystem.XtendReentrantTypeResolver.computeTypes(XtendReentrantTypeResolver.java:383)
	at org.eclipse.xtext.xbase.typesystem.internal.DefaultReentrantTypeResolver.resolve(DefaultReentrantTypeResolver.java:165)
	at org.eclipse.xtext.xbase.typesystem.internal.DefaultReentrantTypeResolver.reentrantResolve(DefaultReentrantTypeResolver.java:140)
	at org.eclipse.xtext.xbase.typesystem.internal.CompoundReentrantTypeResolver.reentrantResolve(CompoundReentrantTypeResolver.java:80)
	at org.eclipse.xtext.xbase.typesystem.internal.CachingBatchTypeResolver$LazyResolvedTypes.resolveTypes(CachingBatchTypeResolver.java:81)
	at org.eclipse.xtext.xbase.typesystem.internal.CachingBatchTypeResolver$2.process(CachingBatchTypeResolver.java:58)
	at org.eclipse.xtext.xbase.typesystem.internal.CachingBatchTypeResolver$2.process(CachingBatchTypeResolver.java:54)
	at org.eclipse.xtext.util.concurrent.IUnitOfWork$Void.exec(IUnitOfWork.java:38)
	at org.eclipse.xtext.util.OnChangeEvictingCache.execWithoutCacheClear(OnChangeEvictingCache.java:145)
	at org.eclipse.xtext.xbase.typesystem.internal.CachingBatchTypeResolver.doResolveTypes(CachingBatchTypeResolver.java:54)
	at org.eclipse.xtext.xbase.typesystem.internal.AbstractBatchTypeResolver.resolveTypes(AbstractBatchTypeResolver.java:70)
	at org.eclipse.xtext.xbase.resource.BatchLinkingService.resolveBatched(BatchLinkingService.java:72)
	at org.eclipse.xtext.xbase.resource.BatchLinkableResource.resolveLazyCrossReferences(BatchLinkableResource.java:166)
	at org.eclipse.xtext.EcoreUtil2.resolveLazyCrossReferences(EcoreUtil2.java:505)
	at org.eclipse.xtext.builder.clustering.ClusteringBuilderState.doUpdate(ClusteringBuilderState.java:232)
	at org.eclipse.xtext.builder.builderState.AbstractBuilderState.update(AbstractBuilderState.java:171)
	at org.eclipse.xtext.builder.impl.XtextBuilder.doBuild(XtextBuilder.java:521)
	at org.eclipse.xtext.builder.impl.XtextBuilder.addInfosFromTaskAndBuild(XtextBuilder.java:455)
	at org.eclipse.xtext.builder.impl.XtextBuilder.fullBuild(XtextBuilder.java:562)
	at org.eclipse.xtext.builder.impl.XtextBuilder.build(XtextBuilder.java:333)
...

HannesWell · 2023-11-13T17:21:31Z

@HannesWell thanks for the contribution! I'll merge it for now, and when I switch to new Xtext and Guice (#71 ) I'll remove all the import of javax.inject from MANIFESTs.

Great, thanks!

@HannesWell did you try to setup the development environment with Oomph?

Sorry I didn't. I had to adjust multiple projects and therefore only cloned the repos and modified them 'raw' and relied on the CI to check it.
If you havn't fixed it already I can look into it and try to fix it.

My first guess is that the guice annotations don't work here and therefore weren't applied before.

LorenzoBettini · 2023-11-13T17:26:09Z

@HannesWell I don't know if it's worthwhile to try to fix that. As I said, as part of #71 I'll upgrade to Guice 7 and I'll be able to remove javax.inject imported package completely. For the time being, though, I'd have to revert your commit. If you find an easy way to fix that as well I can hold the revert. However, as I said, please don't waste too much time if you can't fix it right away.

HannesWell · 2023-11-13T17:47:41Z

@HannesWell I don't know if it's worthwhile to try to fix that. As I said, as part of #71 I'll upgrade to Guice 7 and I'll be able to remove javax.inject imported package completely. For the time being, though, I'd have to revert your commit. If you find an easy way to fix that as well I can hold the revert. However, as I said, please don't waste too much time if you can't fix it right away.

OK, then please just revert the commit. I have to admit that I'm too busy and not eager to investigate it, if the plan is to revert it anyways the next week. 😅
Do you intend to contribute the result of the TP updates to the upcoming December SimRel?

LorenzoBettini · 2023-11-13T17:50:57Z

OK!
Yes, I have already created the release review for version 1.15 that I want to contribute to December simrel.
When I update to the new Guice I can release a milestone in the aggregator (maybe next week).
Thanks again!

HannesWell · 2023-11-13T18:38:24Z

When I update to the new Guice I can release a milestone in the aggregator (maybe next week).
Thanks again!

That would be great, thanks!
But if that doesn't work out I expect that emf-parsley won't be the last project pulling in the 'old' javax-bundles.
From all current requierers listed in eclipse-simrel/simrel.build#49 (comment) I have not yet get a response from XWT and looking at the repo's activities I'm not sure if the change will land and have an updated contribution in time.

LorenzoBettini · 2023-11-14T12:30:34Z

@HannesWell just one more question: what about javax.inject.Inject annotations used in e4 applications?
Will they have to be migrated to jakarta ones?
For e4 using Guice does not seem to work because of javax.inject.PostConstruct

HannesWell · 2023-11-14T16:27:19Z

what about javax.inject.Inject annotations used in e4 applications?\nWill they have to be migrated to jakarta ones?

The E4 injector supports both Jakarta and javax annotations, you can use either one (probably can even them mix or apply both):
https://eclipse.dev/eclipse/news/4.30/platform.php#support-jakarta-annotations

And it will support Javax for at least two more years:
eclipse-platform/eclipse.platform.releng.aggregator#1510

LorenzoBettini · 2023-11-16T18:13:29Z

@HannesWell, I've just contributed EMF Parsley 1.15.0 milestone to simrel: I removed all references to javax.inject.

HannesWell · 2023-11-17T20:12:09Z

@HannesWell, I've just contributed EMF Parsley 1.15.0 milestone to simrel: I removed all references to javax.inject.

Perfect. Thanks!
With on the latest simrel.build main I see emf-parsly is gone as strict requirer of javax.inject/annotation. 👍🏽

HannesWell mentioned this pull request Nov 12, 2023

Add javax annotations providing jakarta bundles eclipse-simrel/simrel.build#49

Merged

Remove strict requirement to bundle javax.inject

c1bb2bf

LorenzoBettini mentioned this pull request Nov 13, 2023

Get rid of javax.inject references #71

Closed

LorenzoBettini merged commit 03cb27d into eclipse-emf-parsley:master Nov 13, 2023
5 checks passed

HannesWell deleted the remove-javax.inject branch November 13, 2023 17:15

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Remove strict requirement to bundle javax.inject #69

Remove strict requirement to bundle javax.inject #69

HannesWell commented Nov 12, 2023

LorenzoBettini commented Nov 12, 2023

LorenzoBettini commented Nov 12, 2023

HannesWell commented Nov 12, 2023 •

edited

Loading

LorenzoBettini commented Nov 12, 2023

HannesWell commented Nov 12, 2023

LorenzoBettini commented Nov 12, 2023

HannesWell commented Nov 12, 2023

cdietrich commented Nov 12, 2023

LorenzoBettini commented Nov 12, 2023

HannesWell commented Nov 12, 2023

LorenzoBettini commented Nov 12, 2023

HannesWell commented Nov 12, 2023 •

edited

Loading

cdietrich commented Nov 12, 2023

LorenzoBettini commented Nov 13, 2023

LorenzoBettini commented Nov 13, 2023

HannesWell commented Nov 13, 2023

LorenzoBettini commented Nov 13, 2023

HannesWell commented Nov 13, 2023 •

edited

Loading

LorenzoBettini commented Nov 13, 2023

HannesWell commented Nov 13, 2023 •

edited

Loading

LorenzoBettini commented Nov 14, 2023

HannesWell commented Nov 14, 2023

LorenzoBettini commented Nov 16, 2023

HannesWell commented Nov 17, 2023

Remove strict requirement to bundle javax.inject #69

Remove strict requirement to bundle javax.inject #69

Conversation

HannesWell commented Nov 12, 2023

LorenzoBettini commented Nov 12, 2023

LorenzoBettini commented Nov 12, 2023

HannesWell commented Nov 12, 2023 • edited Loading

LorenzoBettini commented Nov 12, 2023

HannesWell commented Nov 12, 2023

LorenzoBettini commented Nov 12, 2023

HannesWell commented Nov 12, 2023

cdietrich commented Nov 12, 2023

LorenzoBettini commented Nov 12, 2023

HannesWell commented Nov 12, 2023

LorenzoBettini commented Nov 12, 2023

HannesWell commented Nov 12, 2023 • edited Loading

cdietrich commented Nov 12, 2023

LorenzoBettini commented Nov 13, 2023

LorenzoBettini commented Nov 13, 2023

HannesWell commented Nov 13, 2023

LorenzoBettini commented Nov 13, 2023

HannesWell commented Nov 13, 2023 • edited Loading

LorenzoBettini commented Nov 13, 2023

HannesWell commented Nov 13, 2023 • edited Loading

LorenzoBettini commented Nov 14, 2023

HannesWell commented Nov 14, 2023

LorenzoBettini commented Nov 16, 2023

HannesWell commented Nov 17, 2023

HannesWell commented Nov 12, 2023 •

edited

Loading

HannesWell commented Nov 12, 2023 •

edited

Loading

HannesWell commented Nov 13, 2023 •

edited

Loading

HannesWell commented Nov 13, 2023 •

edited

Loading