Re: [tools-pmc] Object Teams proposal

[Stephan Herrmann <stephan@xxxxxxxxxxxxxxx>]

Hi David,

Thanks for your questions. Those sure are interesting points you make.

> This appears to be a moderately mature code base that is already open
> sourced. I'd like to see a short paragraph describing the motivation for
> moving to Eclipse. I can imagine several, and just think it should be
> spelled out.

You're right, the code has reached some maturity, which BTW is one of the
reasons for applying under Tools, not Technology. So, while consolidating,
extending and otherwise improving will never end, let me be very frank
to say that our main goal currently is to build a greater community than
what we have now. We are convinced that becoming an Eclipse project
would help us in at least two ways: better visibility and improved confidence
(in IP-cleanness, long-term availability and maintenance of the tooling).

> Who are the expected adopters of this technology and project? Or, perhaps
> a
> better way of asking my question, what "value add" would an adopter
> provide?
> What APIs are there for them to build on? It appears more as something to
> "just use", without API. I was wondering if my quick read was correct or
> if
> there's API that I'm just not reading about. Perhaps related, is this
> more a "runtime" technology, rather then tool?

It has both parts:
(1) OT/J provides a compiler and a runtime for applications running on
    a bare JVM and OT/Equinox provides the runtime to do the same in Equinox.
    OT/Equinox can definitely be used by any plug-in developer.
    What OT/Equinox developers are consuming is 1 or 2 extension points
    plus the extended syntax of OT/J. I would consider those developers as
    adopters, no?
(2) the OTDT is a full IDE, seamlessly extending the JDT. So, the OTDT is
    roughly as extensible as the JDT and provides an extended version of
    the JDT's API. Adopters are welcome to consume these API and create
    more plug-ins on top of the OTDT, just as they would with the JDT.
    Additionally, we hope to foster interaction with projects like MyLyn
    (e.g., I spoke to Mik and he seemed very open on this) for creating
    all kinds of connectors.

For the "value add", adopters (1) would continue adding value to their
respective projects, just at a higher pace and maintainability (our claim).
Adopters (2) would enrich the OTDT with new features, or cross-fertilize
the OTDT with any other project.

For some of our plug-ins we have merely started sorting out what should
be API and what remains internal, so that's definitely a future task.

> You say, "All software of the Object Teams software has been developed
> using
> the following infrastructure: ... A specific test suite for compiler and
> runtime based on the JACKS framework". From a quick glance, JACKS appears
> to
> be GPL, and its web page states that even the test cases that use it are
> GPL.
> I believe GPL is incompatible with EPL, so that can't come over to
> Eclipse.
> (Right?)

You're very quick at this, I only noticed this conflict after submitting
our proposal. I see several options:
 - Since JACKS was developed by the IBM jikes team, perhaps we could negotiate
   EPL compatible licencing (cf. the JDT/Core uses the jikes parser generator).
 - I believe as the copyright holder of the test cases we could still create
   standalone test cases (not using JACKS) and provide them under the EPL, no?
   The connection to JACKS is very loose, so this is doable (with some effort).
 - Only in the worst case we would maintain these tests outside Eclipse and
   only publish the test results on the Eclipse servers.
 
> Minor question, simply out of curiosity, what's the difference between
> "...
> load-time byte-code weaving ... [and] ... run-time weaving"?

That's a good one ;-)
Basically, it's the question how many chances you get: with load-time weaving
you MUST intercept the class bytes BEFORE the class is defined in the JVM.
With run-time weaving you can do it any time while the system is running.
While run-time weaving definitely opens great new flexibility, it also avoids
intricate difficulties regarding the load order of classes.

> A good job is done explaining how this technology is related to AspectJ
> and
> Equinox Aspects. Since it is closely related to these technologies
> (especially Equinox Aspects) it might be better to have under the same PMC
> as
> one of those.

We seem to agree here: both AspectJ projects are already under Tools ;-)

As for Equinox Aspects I'm in contact with Martin Lippert and I don't think
we need organizational help for co-operation, once the technical issues have
been sorted out.

As for the OT/Equinox part going under Runtime could be appropriate as well,
but OT/Equinox is actually the smaller part of our project in comparison to
the OTDT. I don't think RT would be enthusiastic about hosting a fullfledged
IDE, would they?  (hi Jeff ;-)

Theoretically the easiest thing would be to split, like OT/Equinox under
RT and the OTDT under Tools, but I don't (yet) see the human resources to run
this as two separate projects. That's why I'd like to go with the larger
part of the project: the IDE.

> The idea being, that the common PMC could better encourage
> collaboration among the "competing" sub-projects. In general, I think its
> fine to have projects doing similar things, as long as they do not divide
> the
> community. At least deserves some thought and discussion from other PMC
> members.

sure.


Should I add any of these explainations to the proposal, or is it just
relevant for this discussion?

thanks,
Stephan