Re: [epsilon-dev] Dependencies and some small fixes

[Maarten Bezemer <maarten.bezemer@xxxxxxxxx>]

Hello Dimitris,

On Saturday 25 January 2014 02:07:09 Dimitris Kolovos wrote:

> On 24 January 2014 22:07, Maarten Bezemer <maarten.bezemer@xxxxxxxxx> wrote:

> > First thing I tried to do, is to checkout the svn and import all plugins,
> > tests, examples into an Eclipse workspace. It was quite some work to get
> > all required plugins (I use Eclipse + jdk  from Ubuntu repositories, so
> > no convenient Eclipse Modeling install :) ).
> > 
> > Besides conflicts between projects required EMF Compare 1.x  and 2.x I got
> > all dependencies working. Should we put all required dependencies
> > somewhere online? So it becomes more convenient/easier to collect them
> > all?
> 
> Sure. Either an article under [1] or a Wiki page under [2] would be great!
> 
> [1] http://eclipse.org/epsilon/doc/articles
> [2] http://wiki.eclipse.org/Epsilon

I guess putting this information on the Epsilon wiki is the best course of 
action.
It is just some information, not a full article and it is easier to keep up to 
date in a wiki.

> > During this process I also modified some things due to Epsilon related 
errors:
> >  * a couple of missing methods
> >  * wrong generic type of a collection
> 
> I *think* I have the latest version of everything from the SVN in my
> setup but haven't noticed any such errors. Where do these appear in
> your setup?

Maybe my Eclipse is more strict when generating errors?
Although I used a clean workspace and did not configure these kind of things.

 * EdlModule is missing a setContext() method, which is required by 
IEolLibraryModule
 * ContactsModel is missing a findOne() method, required by ISearchableModel
 * ResourceCollectionGroup#iterator() returned the wrong generic type of 
Iterator<> (and does not use the correct type internally as well)

> >  * missing version requirements in plugin manifests
> 
> Are you referring to individual plugins or to all of Epsilon? So far,
> we've intentionally refrained from declaring version requirements
> except where absolutely necessary (e.g. in EMFCompare dependencies).
> For internal dependencies I can't see much value in doing so as it's
> unlikely that users will have different versions of, say, the engines
> and the development tools. For mature external dependencies (e.g.
> EMF/GMF), in all honesty, I wouldn't be sure where to set the bar
> (i.e. what really is the minimum version required).

Mostly EMF Compare dependencies: It took a while before I noticed that some 
plugins use version 1.1.1+ and other 2.0.0. I added the dependencies 
[1.1.1,2.0.0) for version 1.x to make this more clear.
Most confusing is, is that the org.eclipse.emf.compare.diff and 
org.eclipse.emf.compare.match disappeared in version 2.x


Furthermore, org.epsilon.examples.egl.gmf.papyrus uses the 
org.eclipse.papyrus.uml.diagram.activity of Papyrus that was introduced in 
version 0.9.0 (0.8.0 does not seem to work properly). Furthermore I needed to 
add the org.eclipse.papyrus.infra.gmfdiag.common. It is internally used by 
ActivityDiagramEditPart (papyrus class) but not reexported, resulting in this 
error:

"The type 
org.eclipse.papyrus.infra.gmfdiag.common.editpart.PapyrusDiagramEditPart 
cannot be resolved. It is indirectly referenced from required .class files"


I did not modify the internal dependencies, as I agree with you that users are 
not likely to have different versions running as they are bundled as a whole.


With respect to the mature external dependencies, normally I choose the 
version I used when starting the application. And apply that dependency 
everywhere. When I use a new feature or a relevant bug got solved, I update 
the dependency to force my users to upgrade (and prevent false bug reports, 
which were already solved externally).
But, for Epsilon I am happy to leave it at the current way. (Expect when 
something got added that is really required?)


Cheers,
  Maarten