OK, I'm not really sure how to take that. :( But people in the ABM community have found these APIs to be quite straightforward. It may be a methodological thing, I dunno but it might make sense to back up a bit and figure out what it is that the framework is doing before trying to work around it.
Yes, there are ***completely obvious*** refactorings to make, if we wanted to build a new version of Ascape, but you're still missing the point. ***Ascape is Legacy***.You need to remember also -- this is a point I keep trying to make -- Escape is simply an exemplar for the AMP platform. Precisely because I didn't want to -- and couldn't for IP reasons -- simply migrate Ascape to AMP, there is an abstraction layer there. So there is a lot of extra complexity that wouldn't otherwise need to be there. That's why we have all of those wrappers and everything. It is simply a way to make models written against the Ascape API work inside of the Eclipse AMP system, and since the APIs are similar it actually makes things more confusing.
On Jul 5, 2011, at 7:43 AM, Urs Frei wrote: Yes indeed. That seems a little complicated.
Right now, we're spending hours and
hours trying to understand the implementations of Ascape and Escape...
To make things as easy as possible,
better understandable, better testable and easier extendable, there are
quite a few code snipped we'd like to refactor. Obviously, they include
Ascape. We really need an easy and light development process.
Just as Martin Fowler would quote...
Any fool can write code that a computer
can understand. Good programmers write code that humans can understand.
:-)
Von:
Miles Parker <milesparker@xxxxxxxxx>
An:
AMP developer mailing
list <amp-dev@xxxxxxxxxxx>
Datum:
04.07.2011 19:46
Betreff:
Re: [amp-dev]
Antwort: Ascape core
Gesendet von:
amp-dev-bounces@xxxxxxxxxxx
It's complicated, as usual. But yes, you have to actually
build the dependencies. For the orbit stuff we now get that from Orbit
P2, so we can get rid of o.apache.a, o.apache.c.c, o.jdom and o.junit.
We maintain o.e.e.java, which is a different story, we have a bug fix out
to fix that one to use the Eclipse EMF repos instead. In any case, the
bottom-line is that we cannot deliver anything that wasn't actually physically
built at Eclipse. So no jars, sorry, but we can and do use Eclipse hosted
plugins where available. :)
On Jul 3, 2011, at 11:57 PM, Urs Frei wrote:
Okay. We'll try and reverse those changes.
We'll probably have to make a patch for Ascape.
If we're not supposed to change Ascape sources, why are they put into the
git repository as sources? Why not use a JAR file. That way it would be
clear that nothing can be changed without explanation.
Talking about dependecies...
org.apache.ant
org.apache.commons.collections
org.apache.commons.lang
org.eclipse.emf.java
org.jdom
org.junit
are all included as sources as well. I don't think we're supposed to make
changes in those projects. Why are they in the git repository? Couldn't
we get rid of them?
Von: Miles
Parker <milesparker@xxxxxxxxx>
An: AMP
developer mailing list <amp-dev@xxxxxxxxxxx>
Datum: 01.07.2011
20:18
Betreff: [amp-dev]
Ascape core
Gesendet von: amp-dev-bounces@xxxxxxxxxxx
Hi guys,
I noticed some changes to Ascape core in bug 350813.
If I neglected to make this clear, for IP
reasons *we cannot make changes to org.ascape.* We area llowed to
include them only as dependencies. If we make changes to ascape proper,
we need to apply them to the sourceforge code base (I'm happy to make you
committers on that as well) and then put them through a CQ to get them
back into AMP. I know, a complete PITA, but that might make it a little
clearer why I've avoided some obvious design improvements. Let's figure
out a set of changes and bundle them up. It's not like it's an incredibly
difficult process, but it does take at least a few days and often a week
or two to get them approved. For now, please back those changes out --
it's important that they don't end up in a released build.
thanks,
Miles
_______________________________________________
amp-dev mailing list
amp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/amp-dev
________________________________________________________________
Urs Frei, Ingenieur FH
Wissenschaftlicher Mitarbeiter
Fon +41 71 226 12 22
Fax +41 71 226 12 13
Web http://www.fhsg.ch
FHS St.Gallen, Hochschule für Angewandte Wissenschaften
IMS-FHS | Poststrasse 28 | Postfach 1664 | 9001 St.Gallen | Switzerland
FHO Fachhochschule Ostschweiz_______________________________________________
amp-dev mailing list
amp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/amp-dev
_______________________________________________
amp-dev mailing list
amp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/amp-dev
________________________________________________________________
Urs Frei, Ingenieur FH
Wissenschaftlicher Mitarbeiter
Fon +41 71 226 12 22
Fax +41 71 226 12 13
Web http://www.fhsg.ch
FHS St.Gallen, Hochschule für Angewandte Wissenschaften
IMS-FHS | Poststrasse 28 | Postfach 1664 | 9001 St.Gallen | Switzerland
FHO Fachhochschule Ostschweiz_______________________________________________ amp-dev mailing list amp-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/amp-dev
|