The generation gap classes are placed in src-gen, should be placed in src about spray HOT 18 CLOSED

Generation of the 'empty' files (like mod4jDiagramTypeProvider ) in the src-gen 
folder is done on purpose. These need to be be generated in the src-gen folder. 
Only when a user wants to change a file, he should move it to the src folder. 
Advantages of this scheme are:
- regeneration as much as possible. Sometimes the 'empty'  files change because 
of changes in the generator, , or sometimes they might need to contain some 
code.
-  better overview for the user.,  He will only see files in the src folder 
that he has actually changed.  Given the huge amount of files that may be 
generated it is not workable to generate them all in the src folder.  It will 
be impossible for the user to find his manual changes.

I'll handle this one.

Maybe we should consider the pattern used in Sculptor: 
http://fornax.itemis.de/confluence/display/fornax/3.+Advanced+Tutorial+(CSC)#3.A
dvancedTutorial(CSC)-GapClass

i.e. introduce a keyword gap - only for elements in the DSL containing "gap" a 
gap class is generated: so if the user want to adapt a default behaviour he 
just annotate the element in the DSL with "gap"

We could go the Fornax way,  but I see no big advantage.  I have good 
experiences with the way it is done now.  I propose to leave it as is, I think 
there are more pressing issues to deal with.

So, if I want to change mod4jDiagramTypeProvider.java file, I have to move it 
from src-gen to src directory and then make changes? But if it's so, after 
code-regeneration mod4jDiagramTypeProvider.java appears in src-gen again and 
I'll get 'The type mod4jDiagramTypeProvider is already defined'. So, now it's 
bug - am I right?

No, it works slightly more intelligent. If the file is moved to src the 
generator will recognize that it has been moved and will not generate the file 
again.  

[deleted comment]

Yes, you're right! I found this place in 
org.eclipselabs.spray.generator.graphiti.templates.SprayGenerator.xtend
But. I cannot understand why, but if I create new spray(0.2.0)-project (using 
wizard, with default settings) - source code generates perfectly in "src-gen"!

Then I create org.eclipselabs.spray.examples.mydiagram.diagram package in "src" 
and copy here some file (e.g. MyDiagramDiagramTypeProvider) from "src-gen" 
(from the same package) to "src" and try to clean and rebuild workspace, then I 
got two MyDiagramDiagramTypeProvider.java files (in "src" and "src-gen") and 
"The type MyDiagramDiagramTypeProvider is already defined"-error for those that 
lays in "src".

Jos, maybe You know (or someone else) quick way to fix this error or maybe I do 
something wrong?

*In FileGenerator.xtend, not in SprayGenerator.xtend

If I ran eclipse with enabled -consoleLog then I got this log:
PROPERTIES 
[platform:/resource/org.eclipselabs.spray.examples.MyDiagram/model/MyDiagram.pro
perties]
EclipseResourceFileSystemAccess: WARNING: dos not work yet
generating 
org/eclipselabs/spray/examples/mydiagram/diagram/MyDiagramDiagramTypeProvider.ja
va
....

PS: I use Windows XP

Make sure that the file you are copying is meant to be used for manual 
extensions /overriding.  The base class never is and will always be generated.  
You can see this in the generated comment at the start of the file. Can you 
check this?

Yes. I saw all this comments about extension point, so it was my first step for 
working with spray - copy this file (without suffix Base) to "src".

I went through project's source codes and found that in my case for some reason 
for source code generation used not JavaIoFileSystemAccess', but 
EclipseResourceFileSystemAccess' object. So that's why we see warning: 
*EclipseResourceFileSystemAccess: WARNING: dos not work yet*
(you can see it in SprayGraphityGenerator.xtend::doGenerate)
And I think because of this generator looks for file not in workspace 
directory, but in eclipse start directory (e.g. C:\Program Files\eclipse\).

So in my case for generation uses JavaGenFile's object with uninitialized Gen 
and Man output pathes (the same doGenerate method), at least we should add:

if(  javaFsa != null ){
  java = new JavaGenFile(javaFsa)
  java.setGenOutputPath(genOutputPath)
  java.setManOutputPath(manOutputPath)
} else  {
  java = new JavaGenFile(eclipseFsa)
  // add two following lines
  java.setGenOutputPath(genOutputPath)
  java.setManOutputPath(manOutputPath)
}

After adding this lines generator again will looks for file in eclipse's start 
directory. But if we set eclipse start directory to workspace directory it 
works pretty well. Ofcourse it isn't right solution, but as quick fix can be 
used.

Maybe you know what should I do to make generator use JavaIoFileSystemAccess' 
object instead of EclipseResourceFileSystemAccess'?

Right,  when I committed the first code,  this was only working while running 
the generator from the Main program, not inside Eclipse.  I'll take a look how 
to fix this for buildinh inside Eclipse

Can you, at least, add those two lines of initializing gen and man pathes as I 
mention above to repository -  it helps me to omit adding this modifications by 
myself and rebuilding spray any time I sync with your's repository.
Can you do this for me?

with commit 8a4ab0272644c2655cda8678df90141126706e50 the output paths are added 
as requested in #c14

As discussed yesterday it is very likely that in the future there will be a 
configuration file in the project that registers all classes for that a gap 
class should be generated. To ease that configuration there will be UI 
enhancements that support creating new gap classes from existing generated 
classes.

I'll handle this one.  The path should only be used when not inside Eclipse.  
Within Eclipse we should use the project to find the location for the different 
folders.

Changed code generation in Eclipse to use the project location instead of the 
projectPath from the properties file.  Now the generator works standalone and 
as an eclipse builder.
Also repaired the fact that extension point files that were moved to 'src'  
were still generated.