How big is the code? I got the impression that is is not going to be that
big (perhaps 20k or less)?
I agree with Pascal that it would be nice to separate this into another
bundle, but I would like to avoid splitting it into a whole bunch of very
small bundles. Would it be possible to move
Hi Thomas,
Thomas Watson wrote:
How big is the code? I got the impression that is is not going to be
that big (perhaps 20k or less)?
The current class files are ~15k compressed jar (good guess Tom).
Scott
___
equinox-dev mailing list
Comments inline.
Tom
Scott Lewis wrote:
H Tom,
Thanks for the responses. Follow up inline below.
Scott
stuff deleted
For now you can just throw a ServiceException of UNKNOWN or if you
want you could just use your own value for the type until we sort this
out.
Ok, is this
I think the jobs-specific code should go in the jobs bundle. It may not
end up taking the exact form of the prototype, but having a job-based
executor in the jobs bundle makes sense to me (it may just be added to
IJobManager rather than a separate class, but that's an implementation
detail).
comments in-line.
Tom
Scott Lewis wrote:
Hi all,
Although provisional API (for 1.5 years) seems a bit conservative...and
it will cause ECF/other potential clients of the API difficulties over
this time (i.e. we would like to have our ECF 3.0/Galileo release of
remote services use this
Hello Eclipse Runtime experts,
In order to provide preprocessor support for low-end Java devices/
phones, EclipseME/MTJ has hooked into JDT by using a Classloader hook
for a few releases. This has worked fine until recent Galileo
builds. One of our users let us know that our runtime hooks
Hi Thomas and all,
I've attached a zip with new plugin org.eclipse.equinox.future with
package naming as discussed, and patches for jobs and tests plugins to
the original bug:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=253777
Just to avoid further potential for multi-bug confusion.
