alexroldugin / spray Goto Github PK

The SWTBot tests as black box tests should ensure, that the generated example 
diagram code provides the expected behavior. This should make the developers 
confident, that changes to the DSL and the associated generator, that break the 
expected behavior, are discovered soon.

Beside the SWTBot tests there can be implemented simple unit tests for single 
features, too. This would require a lot of mocking interacting classes, but 
with those tests, causes of misbehavior can be spotted more easily. Here also 
the dark feature processing is needed: 
http://help.eclipse.org/indigo/topic/org.eclipse.graphiti.doc/resources/docu/gfw
/dark-feature-processing.htm

How to run SWTBot headless in Maven is described here: 
http://wiki.eclipse.org/SWTBot/Maven

Take the example tests contained in Graphiti source code as reference:

PSF for CVS or better http://git.eclipse.org/c/gmp/org.eclipse.gmp.graphiti.git/
<?xml version="1.0" encoding="UTF-8"?>
 <psf version="2.0">
 <provider id="org.eclipse.team.cvs.core.cvsnature">
 <project reference="1.0,:pserver:dev.eclipse.org:/cvsroot/modeling,org.eclipse.gmp/org.eclipse.gmp.graphiti/tests/org.eclipse.graphiti.bot.tests,org.eclipse.graphiti.bot.tests"/>
 <project reference="1.0,:pserver:dev.eclipse.org:/cvsroot/modeling,org.eclipse.gmp/org.eclipse.gmp.graphiti/tests/org.eclipse.graphiti.tests,org.eclipse.graphiti.tests"/>
 <project reference="1.0,:pserver:dev.eclipse.org:/cvsroot/modeling,org.eclipse.gmp/org.eclipse.gmp.graphiti/features/org.eclipse.graphiti.tests-feature,org.eclipse.graphiti.tests-feature"/>
 <project reference="1.0,:pserver:dev.eclipse.org:/cvsroot/modeling,org.eclipse.gmp/org.eclipse.gmp.graphiti/tests/org.eclipse.graphiti.testtool.ecore,org.eclipse.graphiti.testtool.ecore"/>
 <project reference="1.0,:pserver:dev.eclipse.org:/cvsroot/modeling,org.eclipse.gmp/org.eclipse.gmp.graphiti/tests/org.eclipse.graphiti.testtool.sketch,org.eclipse.graphiti.testtool.sketch"/>
 <project reference="1.0,:pserver:dev.eclipse.org:/cvsroot/modeling,org.eclipse.gmp/org.eclipse.gmp.graphiti/tests/org.eclipse.graphiti.ui.tests,org.eclipse.graphiti.ui.tests"/>
 </provider>
 </psf> 

Several templates use 'instanceof' in the filter() function:
{{{
filter(c | c instanceof EClass)
}}}
The problem with this pattern is that the resulting list is not typed to the 
desired type.

If using filter with the `typeof` operator, the resulting iterable will be 
typed with the filtered type.

The templates must use this pattern:
{{{
filter(typeof(EClass))
}}}

example: mod4jDiagramTypeProvider as well as mod4jDiagramTypeProviderBase are 
placed inside src-gen, but mod4jDiagramTypeProvider should reside in src, so 
changes would not get thrown away after regeneration

The Xspray generator should therefore define different outlets.

Beside the project wizard in issue 
http://code.google.com/a/eclipselabs.org/p/spray/issues/detail?id=21 there 
should be also a diagram wizard that allows to choose, if the domain model 
should be contained in the diagram file or should be separated stored in an 
extra file. Furthermore the wizard should enable to choose an existing domain 
model file to create a diagram file fore. 
Further improvements would be to support choosing different diagram types 
operating as different views on the same domain model, but maybe this should be 
tracked in an extra issue report.

What steps will reproduce the problem?
1. Create spray project with wizard and use default settings
2. Use attached spray-file to generate code
3. Look at MyDiagramFeatureProviderBase::getCreateConnectionFeatures. In my 
case it looks like this:
public ICreateConnectionFeature[] getCreateConnectionFeatures() {
  return new ICreateConnectionFeature[] { ,,
  };
}

If we add one more shape description (e.g. for BusinessDomainModel's EClass) we 
will see not two commas, but three. If one more - four commas, and so on.

What version of the product are you using? On what operating system?
Eclipse Modeling Tools

Version: Indigo Release
Build id: 20110615-0604

Windows XP SP3

Spray will need Xbase expressions for different aspects. The grammar must be 
derived from Xbase then.

Since Xbase API is currently fluent, the exact version to use should be pinned 
in the manifests. Currently this is 2.0.1.

It should be possible to define a figure that contains an image. In the 
implementation the image would be a child of the figure, e.g. a rectangle. The 
image itself has optional a width and height as well as a position inside the 
shape.

Additional Ideas

Colors should not only be restricted to IColorConstant instances, it should 
also be allowed to define a color with RGB values.

   line (width=2  color=RGB(128,128,128));

Sebastian Zarnekow has written an article to include a Color Picker dialog to 
choose the RGB color.

http://zarnekow.blogspot.com/2011/06/customizing-content-assist-with-xtext.html

Creation of Spray projects should be as easy as possible. A project wizard 
should be added to create a project with the structure as in 
org.xspray.example.one.

Currently the content of the src-gen and xtend-gen folder is checked in. It is 
generally a bad practice to check in generated code. However, checking in 
xtend-gen is currently mandatory due to limitations on compiling Xtend sources 
in a headless build. But the contents of src-gen can be derived.

To do:
- Configure the Fornax Workflow plugin to execute the GenerateXspray.mwe2 
workflow
- Configure the maven-clean-plugin
- Remove contents of src-gen from the repository
- Add .gitignore in src-gen

Originally there were used absolute paths. This has been slightly improved by 
using relative paths now.  But this mechanism will not work, when the 
referenced file is contained within a jar file.

examples/org.xspray.examples.one/model/mod4j-busmod.properties contains 
property projectPath. This is used as destination folder for the generated 
files.

examples/org.xspray.examples.one/model/mod4j-busmod.xspray uses the path to 
import the BusinessDomainDsl.ecore.

org.xspray.xtext.generator.Main from project plugins/org.xspray.xtext is 
launched with the path to the .xspray file as input parameter.

Using "platform:/resource/ does not work, the so addressed files cannot be 
found this way. This might be due the fact that the projects are imported as 
reference in my Eclipse workspace from my local git repository. 

The relative path solution assumes currently that org.xspray.xtext is current 
working directory from that the domain meta model resp. the target generation 
project can be reached that way:
../../examples/org.mod4j.dsl.businessdomain.mm/model/BusinessDomainDsl.ecore
../../examples/org.xspray.examples.one

Tycho 0.13.0 was released. 
Release notes see: http://wiki.eclipse.org/Tycho/Release_Notes/0.13

Upgraded POM.

There is a path hard coded in JavaGenFile.java. All hardcoded paths should be 
removed. (Issue sent by email by Jorg Reichert)

The built eclipse repository does only contain the plugins from the Spray 
project. When using the update site users might need to add too much update 
sites to get the dependent features from (SWTBot, xtext-utils,...).

The tycho-p2-repository-plugin plugin can be configured to include the 
dependent plugins by setting the includeAllDependencies property:

{{{
<plugin>
  <groupId>org.eclipse.tycho</groupId>
  <artifactId>tycho-p2-repository-plugin</artifactId>
  <configuration>
    <includeAllDependencies>true</includeAllDependencies>
    <repositoryName>spray-${project.version}</repositoryName>
  </configuration>
</plugin>
}}}

When having o.e.s.examples.one in the workspace, the workflow 
SprayGenerator.mwe2 is marked with error
   Couldn't resolve reference to Module 'org.eclipselabs.spray.xtext.generator.SprayGenerator'.

The "missing" workflow is located in plugin 
org.eclipselabs.spray.generator.graphiti, and its package is exported. The 
plugin is also listed as required bundle.

Missing Dependency? Xtext-Bug?

The class names should have different casing, see Example One
1) class names begin with small letter 'mod4j', but class names should start 
with capital letter
     mod4jAddAssociationFeatureBase 
  => Mod4jAddAssociationFeatureBase

2) Names of references must start with capital letter
     mod4jCreateBusinessClassbusinessRulesBusinessRuleFeature
  => Mod4jCreateBusinessClassBusinessRulesBusinessRuleFeature

The plugins have currently version 1.0.0 (without qualifier).

Since this is early state development the versions of the plugins should be set 
to 0.1.0.qualifier resp. 0.1.0-SNAPSHOT in the pom.xml files.

We need to provide our documentation in a format that is consumable in the 
following formats:
- HTML
- Eclipse Help
- PDF
The documentation should be easily to write. The production of the different 
formats must be integrated into the build, maybe only if a specific profile is 
activated.

The documentation project has to be created at location /docs in the repository 
as an Eclipse project.

Specify the required plugins to install to the IDE to develop the documentation.

Possible candidates for documentation format:
- Mylyn WikiText
- eWiki - http://nirmalsasidharan.wordpress.com/category/mylyn/
- Xdoc - 
http://zarnekow.blogspot.com/2011/06/xdoc-documentation-language-for-eclipse.htm
l
- ... (add others)

The generated Palette contains an entry "XXX", see screenshot.

This is hard coded in ToolBehaviourProvider.xtend

In several places of the Xtend templates the 'new' operator is used to 
instantiate template classes and other helpers.

This is not the recommended way, it is better to inject these objects. This 
way, these classes can use Extensions, otherwise the classes are not managed 
with Guice.

Example:
`XsprayGenerator.xtend`:
{{{
var Plugin plugin = new Plugin()
}}}

Change to
{{{
class XprayGenerator ... {
   @Inject Plugin plugin
}
}}}

The editor fails with an exception, that the EClass cannot be resolved.

Date: Sun, 25 Sep 2011 13:44:07 +0200
From: Soeren Dierkes    <[email protected]>
To: [email protected]
Subject: [graphiti-dev] First Editor
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed

Hey everyone,

I know its not the common way to ask via dev-mailinglist, but no one 
answered me in my thread, so I decide to ask you.
I think the answer should be pretty easy, but I dont get it for my own.

Its my  first try to develop a plugin, and I start with your tutorial 
and just copy paste the first classes to test it and
reconfigure it to understand the API.
I am able to create a new editor, but if I try to open it there is no 
EClass object and I got the exception:

Contributor mytutorial.PropertyContributor cannot be created.

Later in your tutorial it is described how I add this to the plugin.xml 
and I think I did it like I should.
But now I got nothing, no exception, no EClass, no warning.

Ive tried everything I know, but it doesnt work.
Last step, ask some developer.

I hope you can help me 

Soeren

Currently the metaclass name is just an named reference, no real cross 
reference.

Rule "MetaClass" must be changed from:
{{{
MetaClass :
    'class'  name=ID  ('alias' alias=ID)? ('icon' icon=STRING)?
}}}
to:
{{{
MetaClass :
    'class'  name=[ecore::EClass|QualifiedName]  ('alias' alias=ID)? ('icon' icon=STRING)?
}}}

What steps will reproduce the problem?
1. Download Eclipse Indigo MDT.
2. Add http://spray.eclipselabs.org.codespot.com/git.distribution/releases as 
an update site.
3. Select all.
4. Press next and then finish.

What is the expected output? 
A successful install.

What do you see instead?
Cannot complete the install because one or more required items could not be 
found.
  Software being installed: Spray SDK Feature 0.1.0 (org.xspray.feature.sdk.feature.group 0.1.0)
  Missing requirement: org.xspray.xtext.tests 0.1.0 (org.xspray.xtext.tests 0.1.0) requires 'bundle org.eclipselabs.xtext.utils.unittesting 0.9.0' but it could not be found
  Cannot satisfy dependency:
    From: Spray SDK Feature 0.1.0 (org.xspray.feature.sdk.feature.group 0.1.0)
    To: org.xspray.xtext.tests [0.1.0]

What version of the product are you using? On what operating system?
Was using a freshly unpacked eclipse-modeling-indigo-linux-gtk-x86_64.tar.gz

Please provide any additional information below.

Installation works fine with 
https://spray.ci.cloudbees.com/job/spray-ci-build/lastSuccessfulBuild/artifact/r
eleng/repository/target/repository/

Examples would also be appreciated.

The resulting Jars are unsigned. We have to sign them in the build.

Tycho resolves its dependencies from the P2 repositories configured by the 
<repository> entries in the parent pom.

The spray.target target definition file defines the target platform as well. 
The build should use this definition, this reduces the risk of using different 
targets in development and build.

What steps will reproduce the problem?
1. Install Spray from CI build.
2. Create a new project using the wizard.
3. Change the contents of the .spray file to the following:
diagram   mydiagram2

// Add import statements here, e.g.
 import BusinessDomainDsl.*

   class BusinessClass:
     container  ( fill=dark_green ) 
     [
//       text ( )  { "<<"+eClass.name+">> " + name};
     ]
4. Save the file.

What is the expected output? What do you see instead?
A clean compile. Instead one gets:
Description Resource    Path    Location    Type
IColorConstant cannot be resolved to a 
variable    Mydiagram2AddBusinessClassFeatureBase.java  /org.eclipselabs.spray.examp
les.mydiagram2/src-gen/org/eclipselabs/spray/examples/mydiagram2/features   line 
65  Java Problem

If you add this line:
       text ( )  { "<<"+eClass.name+">> " + name};
You will get:
Description Resource    Path    Location    Type
Couldn't resolve reference to JvmIdentifiableElement 
'+'.    mydiagram2.spray    /org.eclipselabs.spray.examples.mydiagram2/model    line: 18 
/org.eclipselabs.spray.examples.mydiagram2/model/mydiagram2.spray   Xtext Check 
(fast)

What version of the product are you using? On what operating system?
Spray CI 0.3.0, Eclipse Indigo MDT SR1 20110916-0149.

Please provide any additional information below.
It would be good with a getting started tutorial.
I suppose things like this should work with proper setup, so I guess I could be 
doing something wrong..?

What steps will reproduce the problem?
1. Install everything from 
https://spray.ci.cloudbees.com/job/spray-ci-build/lastSuccessfulBuild/artifact/r
eleng/repository/target/repository/(Date done: Fri Sep  9 17:16:08 CEST 2011)
into a fresh Eclipse Indigo MDT tool
2. "Import" -> "Plug-ins and Fragments" -> 
Import from "The active target platform"
Plug-ins and Fragments to Import "Select from all.."
Import As "Projects with source folders"
3. Choose "org.xspray.examples.one"

What is the expected output? What do you see instead?
Build errors:
Description Resource    Path    Location    Type
Package 'org.xspray.examples.mod4j.diagram' does not exist in this 
plug-in MANIFEST.MF /org.xspray.examples.one/META-INF   line 6  Plug-in Problem
Package 'org.xspray.examples.mod4j.features' does not exist in this 
plug-in MANIFEST.MF /org.xspray.examples.one/META-INF   line 6  Plug-in Problem
and associated errors due to this in mod4j-busmod.xspray.

Also there is no syntax highlighting or anything like that in
/org.xspray.examples.one/src/org/xspray/examples/one/XsprayGenerator.mwe2
Adding a dependency to the appropriate tooling would be nice.

What version of the product are you using? On what operating system?
Just eclipse-modeling-indigo-linux-gtk-x86_64.tar.gz

Please provide any additional information below.
Installing the Xtext SDK from 
http://download.eclipse.org/modeling/tmf/xtext/updates/composite/releases/ 
fixed the syntax highlighting/editor support for the .mwe2 file.

In 
/Users/ci_server/git/spray/examples/one/org.eclipselabs.spray.examples.one/model
/mod4j-busmod.properties the project path must be non relative when used in 
Eclipse (to enable the build) and relative when used in the Jenkins build (to 
find the sources). 

see commit 9be63b2bcca29da2012cffe8cd8bf3ad037162c0, that reverted the change 
of commit 4fa13907c5c964932b9beb7410f085a706cb9cbd

Spray uses an enum to define colors. The generator maps that to 
IColorConstants. The Spray DSL should directly refer to a JvmType and filter 
them by type IColorConstant.

{{{
... 
lineColor = Color
...

enum Color :
    BLACK = 'black' 
}}}

Change to:
{{{
Color : type = JvmTypeReference
}}}

Later this should be extended to compute the color by an Xbase expression.

The projects have been developed with prefix "org.xspray", since we have a 
nameclash with another project named "Spray" 
(https://github.com/spray/spray/wiki). We agreed with the other Spray project 
that we can also leave the name "Spray". Further, Eclipselabs encourages to 
choose the prefix "org.eclipselabs" 
(http://www.eclipse.org/org/foundation/eclipselabs/guidelines.php).

Thus the projects should be renamed to `org.eclipselabs.spray.xxxxx`, same for 
base packages.

The string entered for "icon" is free hand. It is not checked that the icon 
does exist, nor you can see it in action without starting the runtime.

If activating the content assist in the icon STRING it should propose the paths 
of known icons: at least those residing in the project, then maybe also from 
dependent plugins. If possible, show the icon also in the hover information.

Add feature projects:
- org.xspray.feature
- org.xspray.feature.source

The Spray language plugin should not have a dependency on Graphiti related 
plugins (o.e.s.generator.graphiti, o.e.s.runtime.graphiti), the dependency must 
be vice versa.

The reason why o.e.s.xtext depends on o.e.s.generator.graphiti is that 
SprayGenerator.xtend invokes the Graphiti generator. The classes from package 
o.e.s.xtext.generator must be moved to o.e.s.graphiti.generator.

To trigger the build in the UI as before, a BuilderParticipant must be 
registered outside of the language plugins. Since this is UI related, a new 
plugin o.e.s.generator.graphiti.ui must be introduced.

As a result, o.e.s.xtext must not have a dependency to any *.graphiti.* plugin 
and the code generator in the UI must still be triggered on model save.

The metamodel classes in org.xspray.mm can be generated any time from the 
genmodel, and this can be automated in the build.

TODO:
- check metamodel classes for manual code. There is a derived attribute "path" 
for migration purposes of the templates that was introduced in issue#6
- Put the code into extension classes
- add MWE workflow to the project
- execute workflow in the build
- remove classes from src

In Add/CreateSomethingFeature we have ability to override canAdd/canCreate 
method, so it means that we can change target container from Diagram to other 
shape. But all spray containers doesn't pay attention to this fact and use 
Diagram as parent shape for all spray containers (e.g. in 
SprayRectangleContainer):

public ContainerShape createContainer(IAddContext context,
                                      Object addedModelElement) {
  targetDiagram = (Diagram) context.getTargetContainer();
  ....
}

Is it possible to use ContainerShape as target containers instead of Diagram? 
Or it's the best (the fastest) way to instantiate my own 
SprayRectangleContainer-like container in Add/CreateSomethingFeature's 
constructor?

All relevant information like plugin/feature name, provider, license etc. 
should be externalized into
- plugin.properties
- feature.properties

For features, add license file, about file, logo and include them to 
bin.includes in the build.properties.

For plugins, set 
  Bundle-Localization: plugin
in the MANIFEST.MF

The language already depends heavily on looking up the GenModel for referred 
EClasses. From the GenModel the associated file extension can be derived, thus 
the "extension" keyword is not required.

Xtext 2.1.0 is about to be released. For Spray it is especially important that 
the Outlet paths are configurable. Also the Xtend Organize Imports function and 
builder syntax are useful.

In most sense it will be a drop-in replacement. Only 
ToolBehaviourProvider.xtend needs a bit refactoring.

The target definition must be adjusted.

Add Maven POMs to each project and provide a master POM.

The master POM should be in the /releng folder.

When the generator properties file is changed the Spray generator should also 
be triggered. Currently this happens only when changing the .xspray file.

The org.xspray.examples.one project contains an MWE2 workflow. When installing 
the Spray SDK feature the MWE2 editor is not available.

The target platform must be extended by MWE2 and also the Spray SDK feature.

What steps will reproduce the problem?
1. Clean CI install of Spray.
2. Create a new Spray project with the wizard.
3. Edit the .spray file with the following contents:
diagram   mydiagram1

 import BusinessDomainDsl.*
   class BusinessClass:
     container  ( fill=dark_green ) 
     [
       text ( )  { "<<"+eClass.name+">> " + name};
     ]


What is the expected output? What do you see instead?
No build errors.
Description Resource    Path    Location    Type
Couldn't resolve reference to JvmIdentifiableElement 
'+'.    mydiagram1.spray    /org.eclipselabs.spray.examples.mydiagram1/model    line: 25 
/org.eclipselabs.spray.examples.mydiagram1/model/mydiagram1.spray   Xtext Check 
(fast)
Couldn't resolve reference to JvmIdentifiableElement 
'+'.    mydiagram1.spray    /org.eclipselabs.spray.examples.mydiagram1/model    line: 25 
/org.eclipselabs.spray.examples.mydiagram1/model/mydiagram1.spray   Xtext Check 
(fast)
Couldn't resolve reference to JvmIdentifiableElement 
'+'.    mydiagram1.spray    /org.eclipselabs.spray.examples.mydiagram1/model    line: 25 
/org.eclipselabs.spray.examples.mydiagram1/model/mydiagram1.spray   Xtext Check 
(fast)


What version of the product are you using? On what operating system?
Spray SDK Feature   0.3.0.201110101215
Errors in both eclipse-SDK-3.7-Xtext-2.0.1-linux-gtk.tar.gz and 
eclipse-modeling-indigo-SR1-linux-gtk.tar.gz.

Please provide any additional information below.

Spray requires that it can look up the Genmodel for a given EClass. Responsible 
for this is the GenModelHelper. This looks up the map
   EcorePlugin.getEPackageNsURIToGenModelLocationMap()

This map will be filled automatically with genmodels registered by extension 
point. It does not work with Genmodels that are only in the workspace.

For the runtime part, the given GenModelHelper should be sufficient. Additional 
genmodels must be registered manually, like it is done in the unit tests.

In the UI, a specialized GenModelHelper could add look up from the workspace. 
To do: Write this specialized GenModelHelper in plugin 
org.eclipselabs.spray.xtext.ui and bind it to the SprayUiModule.

Templates contain sometimes a huge amount of logic to create the right imports. 
For example, FeatureProvider.xtend uses 50 lines of code just for computed 
imports.

{{{
...
    import «feature_package()».«diagram.name»Layout«cls.visibleName()»Feature; // 4
        «IF cls.representedBy instanceof Container»
            «var container = cls.representedBy as Container »
        «FOR MetaReference reference : container.parts.filter(typeof(MetaReference))  »
          «var references = cls.type.EAllReferences » 
          «val referenceName = reference.getName»
          «var target = references.findFirst(e|e.name == referenceName ) » 
          «IF ! target.EReferenceType.abstract»
    import «feature_package()».«cls.diagram.name»Create«cls.getName»«reference.getName»«target.EReferenceType.name»Feature;
  ...
}}}


Therefore there is the ImportUtil class, which uses an ImportManager to collect 
the qualified names of used classes, and prints out the simple name.

To use it, the body of a template must be evaluated first before printing out 
the imports. As a reference look at AddConnectionFeature.xtend, the mainFile() 
method initializes ImportUtil and delegates to mainFileBody to evaluate the 
file content and their imports.

I run into that problem under MacOS as well as under Windows XP. I use Maven 
3.0.3. With mvn clean install in the releng folder I finally end up with the 
output below (what is strange as the build in Cloudbees' Jenkins obvious works):

-------------------------------------------------------
 T E S T S
-------------------------------------------------------
Running org.xspray.xtext.tests.Mod4jTest
11.09.2011 15:44:49 org.eclipse.emf.mwe.utils.StandaloneSetup setPlatformUri
INFO: Registering platform uri 'C:\git\spray\tests'
log4j:WARN No appenders could be found for logger (org.eclipselabs.xtext.utils.u
nittesting.XtextTest).
log4j:WARN Please initialize the log4j system properly.
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.282 sec <<< FA
ILURE!
test_mod4j_busmod(org.xspray.xtext.tests.Mod4jTest)  Time elapsed: 1 sec  <<< ER
ROR!
org.eclipse.xtext.resource.ClasspathUriResolutionException: java.lang.IllegalSta
teException: Couldn't find resource on classpath. URI was 'classpath:///mod4j/Bu
sinessDomainDsl.ecore'
        at org.eclipse.xtext.resource.ClassloaderClasspathUriResolver.resolve(Cl
assloaderClasspathUriResolver.java:48)
        at org.eclipse.xtext.resource.XtextResourceSet.resolveClasspathURI(Xtext
ResourceSet.java:35)
        at org.eclipse.xtext.resource.XtextResourceSet.access$0(XtextResourceSet
.java:34)
        at org.eclipse.xtext.resource.XtextResourceSet$1.normalize(XtextResource
Set.java:53)
        at org.eclipse.emf.ecore.resource.impl.ExtensibleURIConverterImpl.create
InputStream(ExtensibleURIConverterImpl.java:349)
        at org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(ResourceImpl.ja
va:1262)
        at org.eclipselabs.xtext.utils.unittesting.XtextTest.loadModel(XtextTest
.java:406)
        at org.eclipselabs.xtext.utils.unittesting.XtextTest.testFile(XtextTest.
java:175)
        at org.xspray.xtext.tests.Mod4jTest.test_mod4j_busmod(Mod4jTest.java:26)

        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(Framework
Method.java:44)
        at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCal
lable.java:15)
        at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMe
thod.java:41)
        at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMet
hod.java:20)
        at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.
java:28)
        at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.ja
va:31)
        at org.eclipse.xtext.junit4.XtextRunner$1.evaluate(XtextRunner.java:55)
        at org.junit.runners.BlockJUnit4ClassRunner.runNotIgnored(BlockJUnit4Cla
ssRunner.java:79)
        at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRun
ner.java:71)
        at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRun
ner.java:49)
        at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
        at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
        at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
        at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
        at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
        at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.
java:28)
        at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
        at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.
java:62)
        at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTes
tSet(AbstractDirectoryTestSuite.java:140)
        at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(Ab
stractDirectoryTestSuite.java:127)
        at org.apache.maven.surefire.Surefire.run(Surefire.java:177)
        at org.eclipse.tycho.surefire.osgibooter.OsgiSurefireBooter.run(OsgiSure
fireBooter.java:72)
        at org.eclipse.tycho.surefire.osgibooter.HeadlessTestApplication.run(Hea
dlessTestApplication.java:21)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.eclipse.equinox.internal.app.EclipseAppContainer.callMethodWithEx
ception(EclipseAppContainer.java:587)
        at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandl
e.java:198)
        at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runAppli
cation(EclipseAppLauncher.java:110)
        at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(Ec
lipseAppLauncher.java:79)
        at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.ja
va:344)
        at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.ja
va:179)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:622)
        at org.eclipse.equinox.launcher.Main.basicRun(Main.java:577)
        at org.eclipse.equinox.launcher.Main.run(Main.java:1410)
        at org.eclipse.equinox.launcher.Main.main(Main.java:1386)
Caused by: java.lang.IllegalStateException: Couldn't find resource on classpath.
 URI was 'classpath:///mod4j/BusinessDomainDsl.ecore'
        at org.eclipse.xtext.resource.ClassloaderClasspathUriResolver.findResour
ceOnClasspath(ClassloaderClasspathUriResolver.java:60)
        at org.eclipse.xtext.resource.ClassloaderClasspathUriResolver.resolve(Cl
assloaderClasspathUriResolver.java:45)
        ... 53 more


Results :

Tests in error:
  test_mod4j_busmod(org.xspray.xtext.tests.Mod4jTest)

Tests run: 1, Failures: 0, Errors: 1, Skipped: 0

[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO]
[INFO] Eclipselabs Spray ................................. SUCCESS [0.422s]
[INFO] org.xspray.mm ..................................... SUCCESS [42.281s]
[INFO] org.xspray.generator.graphiti ..................... SUCCESS [1.515s]
[INFO] org.xspray.runtime ................................ SUCCESS [0.922s]
[INFO] org.xspray.xtext .................................. SUCCESS [15.485s]
[INFO] org.xspray.xtext.ui ............................... SUCCESS [3.593s]
[INFO] org.mod4j.dsl.businessdomain.mm ................... SUCCESS [1.032s]
[INFO] org.xspray.examples.one ........................... SUCCESS [1.343s]
[INFO] org.xspray.xtext.tests ............................ FAILURE [1:11.547s]
[INFO] org.xspray.examples.one.tests ..................... SKIPPED
[INFO] org.xspray.feature ................................ SKIPPED
[INFO] org.xspray.feature.source ......................... SKIPPED
[INFO] org.xspray.feature.sdk ............................ SKIPPED
[INFO] org.xspray.releng.repository ...................... SKIPPED
[INFO] ------------------------------------------------------------------------

The file headers of generated files contain a timestamp
  Generated on Mon Aug 29 17:53:16 CEST 2011 by XSpray

This timestamp makes it harder to compare changes in generated files, since the 
timestamp will always change and thus all files will be shown as changed when 
comparing two generator results.

This feature should be configurable, and turned off for reference examples. The 
proper place to configure it is the Spray generator properties file.

The o.e.s.xtext.ui plugin has dependencies to the Spray Graphiti plugins. This 
dependency must be removed.

It has to be investigated if the extension point 
org.eclipse.xtext.ui.shared.overridingGuiceModule can be used to achieve this.

The JDT Formatter should be integrated to post process the generated Java files.

Error in org.eclipselabs.spray.xtext/Spray.xtext with message:
The referenced package 'http://www.eclipse.org/xtext/common/JavaVMTypes' was 
imported from a different location. Here: 
'platform:/plugin/org.eclipse.xtext.common.types/model/JavaVMTypes.ecore

What steps will reproduce the problem?
1. Make dir C:/spray_sources/
2. cd to C:/spray_sources/
3. Make repository clone with command:
     git clone https://code.google.com/a/eclipselabs.org/p/spray/
   (so after cloning I got only one "spray" directory inside C:/spray_sources/)
4. Open workspace with set path to C:/spray_sources/
5. Import project from spray/releng
6. Set "Spray Target Platform" in Window > Preferences > Plugin-Development > 
Target Platform
7. Import all projects from spray/plugins/
8. After projects auto-building and refreshing I got several errors in 
Spray.xtext - main of which described above

What is the expected output? What do you see instead?
I expect to see no errors after projects' building

What version of the product are you using? On what operating system?
I use eclipse with info:
"Eclipse Modeling Tools

Version: Indigo Release
Build id: 20110615-0604"

Please provide any additional information below.
If I build with:
mvn clean install -Pskip-ui-tests

all works perfectly