Mailinglist Archive: opensuse-buildservice (375 mails)

< Previous Next >
Re: [opensuse-buildservice] Adding Build-service function to Eclipse! Any suggestions?
  • From: "Michael Hutchinson" <m.j.hutchinson@xxxxxxxxx>
  • Date: Thu, 24 Apr 2008 12:10:15 -0400
  • Message-id: <aec34c770804240910u419d63e5q6523fb86babf81dd@xxxxxxxxxxxxxx>
On Thu, Apr 24, 2008 at 4:32 AM, Peter Poeml <poeml@xxxxxxx> wrote:
...
It's not just about communication with the api -- it's also about
storing the sources locally, tracking modifications, merge handling,
cookie handling, and possibly other things.
I don't know how local sources are handled with eclipse, and how the
concept of a "working copy" looks there, but something like that
probably exists.

I'm not entirely sure that we'd need an osc-style working copy as such
-- in order to integrate fully with MD, I'd probably be expecting to
store the spec files and patches using the local VCS provider. At any
given point it would be possible to regenerate the corresponding
tarball from the VCS.

I would think twice, before I start to program a new client library, for
the following reasons:

- I wouldn't expect the osc library to become the source of a
performance problem when used from other languages.
Even calling 'osc' as external process should be okay, because osc
largely has network bound operation to do, which would take the same
time with a C library. Dealing with working copies is acceptable in
speed also, it seems, otherwise we might have looked for ways to make
osc faster already.

Well, I can't expect really osc to maintain a 100% stable "textual"
API, so parsing its output is bound to run into problems one day...

- It's really not rocket science, but even though a 20-line script is
sufficient to upload files (that's how osc started out after all), it
can take a bit of effort to implement all the other small things, and
get it right.

But I don't know which infrastructure Eclipse features. If it has local
source handling with merging and all (which I would expect), then all
that's needed is a library for the network communication, which is
indeed much more straightforward.

MonoDevelop will probably offer: generating/uploading tarballs and
editing spec files and project metadata, building locally, monitoring
build status. I don't think we'll want much more than that. We're not
aiming for a feature complete build service client, just a useful
level of integration to make it easy to deploy projects to packages
via the build service.

Some things could be done to make external use of osc (from other
languages) easier:
- osc could run as persistent process; it could batch-process commands,
saving on initialization time (it supports this already)
- since other languages wouldn't be able to use native Python objects,
we could add some kind of serialized output or XML output of the
things that osc produces

All of these would definitely help, yes, as long as we could rely on
it having a stable (or backwards-compatible) API.

Finally, IMO:
- it would be nice if we can share working copies between the different
clients (eclipse plugin, commandline client, ...)
- it would be nice if we have one *complete* and well-tested library,
instead of a handful of libraries each supporting a subset

We could think about a rewrite in C with bindings for different
languages. (No need from the viewpoint of the osc commandline, but in
for the above reasons)

I'm not sure that it's worth the effort of rewriting it in C, since a
stable osc text/xml API would work fine. I don't particularly fancy
writing it in C myself either.

FWIW, Mono can consume Java libraries, and can execute Python, so we
could write the library in Java... but let's not go there ;-)

Anyway, it would be nice to have forces joined and work together on one
library, wouldn't it?

Agreed, if it's viable.

--
Michael Hutchinson
http://mjhutchinson.com
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-buildservice+help@xxxxxxxxxxxx

< Previous Next >