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

[Dimitris Kolovos <dimitris.kolovos@xxxxxxxxxx>]

Hi Maarten,

>> 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.

+1

>
>> > 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

You're right. This is in EDL under /examples which I don't have in my
local workspace.

>  * ResourceCollectionGroup#iterator() returned the wrong generic type of
> Iterator<> (and does not use the correct type internally as well)
>

I don't get any errors there but please feel free to commit any
changes you need to make to get rid of the errors.

>> >  * 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"
>

+1

>
> 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?)
>

This makes sense.

Cheers,
Dimitris

>
> Cheers,
>   Maarten
> _______________________________________________
> epsilon-dev mailing list
> epsilon-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/epsilon-dev



-- 
Dr Dimitris Kolovos
Lecturer in Enterprise Systems
Department of Computer Science
University of York
http://www.cs.york.ac.uk/~dkolovos

EMAIL DISCLAIMER http://www.york.ac.uk/docs/disclaimer/email.htm