[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [epsilon-dev] Dependencies and some small fixes
|
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