[news.eclipse.tools.emf] Re: Not a valid classifier on windows standalon

[Jack Glass <jack.glass@xxxxxxx>]

Hi ed,
> > I have a problem after upgrading from 2.3 to 2.4.1 in my standalone 
> > application.
> > I have an Object "Command" which is directly derived from EObject. 
> > Command is my root object from which all other objects from my 
> > application are derived. This class is abstract so its not listed in 
> > CommandFactoryImpl.
> >
> > One thing is that it works when I call it from Eclipse but not for in 
> > my standalone application on windows but on Linux.
> That's always a good indication that plugin.xml extension registrations 
> that are needed have been overlooked.

My standalone application is not using eclipse ide anymore (so no 
plugins anymore). Just SWT+EMF.

I use for EMF all listed jars
http://wiki.eclipse.org/EMF/EMF_2.3/Standalone_Zip_Removal
(Just the 2.4.1 version of it).

> > So it works in Eclipse (win+linux), and linux standalone but not 
> > windows  standalone. I check the classpaths, etc. everything is the same.
> >
> > I'm lost how can this be??
> Can you tell if a different resource factory is being used to create the 
> resource in each case?

I use this command to initialize my EMF package in the standalone case.
        CommandPackage navPackage = CommandPackage.eINSTANCE;
        // Demand load the resource for this file.
        resource = resourceSet.getResource(uri, true);

I works perfect under linux but not under window and also this worked in 
2.3 but not in 2.4.1.

> > The exception which I get:
> > java.lang.IllegalArgumentException: The class 'Command' is not a valid 
> > classifier
> >         at command.actions.impl.CommandFactoryImpl.create(Unknown Source)
> >         at 
> > org.eclipse.emf.ecore.xmi.impl.XMLHelperImpl.createObject(XMLHelperIm
> > pl.java:884)
> Normally it should never try to create an instance of an abstract type 
> because the serialization will contain either an xsi:type or a QName to 
> represent the concrete type that should be used.   I suspect that the 
> different options being used in each case are causing the problem....
> >         at 
In my file I have xsi:type statement but only with concret objects and 
never with "command".

Any ideas what I can do to get more information why it tries to load 
"Command"?

best regards,
jack