Custom Setup Task in OOMPH and namespace conflict

OOMPH is a solution that helps to install official and custom Eclipse distributions.

Those who use it for their own distro can extend its behaviour thanks to setup tasks. A setup task is made up of both an EMF model (that extends the setup.ecore/#SetupTask element from OOMPH) and Java code. This code is partially generated by EMF. People only have to complete the perform method to make it do something at runtime. Obviously, OOMPH provides a wizard to help in the creation of such a thing.

However, I recently had to maintain an existing set of setup tasks. And when I opened the genmodel file for my tasks, I had a weird error message in the genmodel editor.

EMF error due to conflicting namespaces

The exact error message indicates…


Problems encountered in the model
- The package 'http://www.eclipse.org/oomph/setup/1.0#/' has the same namespace URI 'http://www.eclipse.org/oomph/setup/1.0' as package 'platform:/resource/org.eclipse.oomph.setup/model/Setup.ecore#/'
- The package 'http://www.eclipse.org/oomph/setup/1.0#/' has the same namespace URI 'http://www.eclipse.org/oomph/setup/1.0' as package 'platform:/resource/org.eclipse.oomph.base/model/Base.ecore#/'

That’s a weird message.
Even worse, it does not appear if you create a new setup task project. I compared everything: the models, the project settings… everything.

Anyway… One important thing is that this message is not blocking. The EMF editor is made up of two tabs. When such an error is found, this editor shows the problems tab. But the generator tab is still available and you can perform generations anyway. So, you can ignore the message. Or, you can rid of it by following the explanations below. Notice this just a workaround.

Taking a detailed look at the error message, it indicates that two EMF projects from OOMPH export the same package. In fact, both packages export different classes but within the same namespace. And they reference each other (Setup extends classes from Base). Anyway, EMF does not know which package pick up as both could match.

The workaround for this is to update the ecore model.
Indeed, the generated ecore contains…

<eClassifiers
   xsi:type="ecore:EClass"
   name="YourTaskName"
   eSuperTypes="http://www.eclipse.org/oomph/setup/1.0#//SetupTask">

The super type is resolved by namespace.
If you reference it by the location of the ecore model, that will solve the problem.

<eClassifiers 
   xsi:type="ecore:EClass"
   name="YourTaskName"
   eSuperTypes="platform:/resource/org.eclipse.oomph.setup/model/Setup.ecore#//SetupTask">

The Setup classes extends the Base ones.
So, you can directly reference the Setup.ecore file. You can also update your genmodel file with the URL of the existing generators.

usedGenPackages="platform:/resource/org.eclipse.oomph.base/model/Base.genmodel#//base platform:/resource/org.eclipse.oomph.setup/model/Setup.genmodel#//setup"

… instead of…

usedGenPackages="../../org.eclipse.oomph.base/model/Base.genmodel#//base ../../org.eclipse.oomph.setup/model/Setup.genmodel#//setup"

Eventually, you will opt for a solution that prevents the genmodel from rewriting the ecore file. Just remove the publicationLocation attribute from your genmodel. Otherwise, every time you generate code from your genmodel file, it will rewrite the super types in your ecore file. Definitely not what you want.

PS: I have still not understood why the error sometimes appears.
In my case, the ecore file defined several setup tasks in the same file. My other example did not. Maybe that’s the reason.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s