Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 340408

Summary:	Automated StandaloneSetup
Product:	[Modeling] TMF	Reporter:	Ed Willink <ed>
Component:	Xtext	Assignee:	Project Inbox <tmf.xtext-inbox>
Status:	CLOSED WONTFIX	QA Contact:
Severity:	enhancement
Priority:	P3	CC:	sven.efftinge
Version:	2.0.0
Target Milestone:	---
Hardware:	PC
OS:	Windows Vista
Whiteboard:

Description Ed Willink

2011-03-18 06:32:36 EDT

Xtext provides smarter Ecore Resources that need smarter setup. This works fine through automated invocation by Eclipse plugins, but requires manual invocation standalone.

The manual invocation is a source of user errors and difficulties, particularly when the 'initialization' is auto-generated by an Xtext unaware tool such as Acceleo.

Traditionally Ecore Resources are initialized by XXXPackage.eINSTANCE invoking XXXPackageImpl.init(). (This is what Acceleo assumes for an Xtext resource.)

Is it possible for the initialisation order to be reversed?

Rather than StandaloneSetup invoking init(), autogenerate an init() that invokes StandaloneSetup. Xtext resource configuration could then comply with the traditional 'API'.

Comment 1 Sven Efftinge

2011-03-26 15:03:51 EDT

I understood that you want to move the injector creation to be called from within XXXPackageImpl.init(), right?
Sorry, although I see how this would fix the problem, users wouldn't be able to control the initialization of injectors anymore. Also I don't think that initialization of EPackages are related to initialization of the ResourceFactory registry.

Comment 2 Ed Willink

2011-03-26 15:27:27 EDT

(In reply to comment #1)
> I understood that you want to move the injector creation to be called from
> within XXXPackageImpl.init(), right?

Yes, but only when necessary.

> Sorry, although I see how this would fix the problem, users wouldn't be able to
> control the initialization of injectors anymore.

The invocation of standaloneSetup should be guarded against double invocation so, I see three use cases.

a) Plugin usage

Plugin registrations happen as now, extra standaloneSetup invocation in init is ignored.

b) Default Standalone usage

init invokes standaloneSetup.

c) Controlled Standalone usage

User invokes standloneSetup explicitly, subsequent invocation from init() is ignored.

This should allow explicit control for users who want it, and correct behaviour for users who do nothing.

> Also I don't think that
> initialization of EPackages are related to initialization of the
> ResourceFactory registry.

These two activities are nominally independent, but often are related since populating a ResourceFactory registry requires an eINSTANCE parameter and it is the access of the eINSTANCE that performs the package initialization.

Comment 3 Sven Efftinge

2011-03-26 16:21:00 EDT

(In reply to comment #2)
> > Sorry, although I see how this would fix the problem, users wouldn't be able to
> > control the initialization of injectors anymore.
> 
> The invocation of standaloneSetup should be guarded against double invocation
> so, I see three use cases.

Generally it is perfectly ok, to create multiple injectors from one module.

> 
> a) Plugin usage
> 
> Plugin registrations happen as now, extra standaloneSetup invocation in init is
> ignored.
> 
> b) Default Standalone usage
> 
> init invokes standaloneSetup.

I think Acceleo shouldn't assume that every resource in the world is an XMI resource :-)
So they should provide some means to register the EMF singletons prior to execution.

> These two activities are nominally independent, but often are related since
> populating a ResourceFactory registry requires an eINSTANCE parameter and it is
> the access of the eINSTANCE that performs the package initialization.

No, they are only related if you have derived only one EPackage from one grammar. If there are more than one or you just imported one things are different.