[opensuse-buildservice] Adding Build-service function to Eclipse! Any suggestions?

newer
[opensuse-buildservice] failed to...

older
[opensuse-buildservice] How to set...

long hong

22 Apr 2008 22 Apr '08

12:40

Hello, everyone! This summer I shall attend the Google Summer of Code, adding build service functions to eclipse. The bellow is my project: http://code.google.com/soc/2008/suse/appinfo.html?csaid=DFC9A170A95499CD Now I just want to gather users' expectations to this project. What would you like to see when using Build-Service in Eclipse? Thanks a lot! --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

Show replies by date

Carsten Hoeger

22 Apr 22 Apr

15:15

New subject: [opensuse-buildservice] Adding Build-service function to Eclipse! Any suggestions?

On Tue, Apr 22, long hong wrote:

...

Hello, everyone! This summer I shall attend the Google Summer of Code, adding build service functions to eclipse. The bellow is my project: http://code.google.com/soc/2008/suse/appinfo.html?csaid=DFC9A170A95499CD

Nice to hear! :-)

...

Now I just want to gather users' expectations to this project. What would you like to see when using Build-Service in Eclipse? Thanks a lot!

Here some use cases that come to my mind: - Add/Change packages - Edit/Create package Templates - Add/Change projects - Edit/Create project Templates - Add a "New Buildservice Package/Projekt" Workflow - Edit specfiles and debian/* files using eclipse and upload them to the buildservice automatically - could be achieved in using/integrating existing technology, e.g. https://admin.fedoraproject.org/pkgdb/packages/name/eclipse-rpm-editor - monitor build status - download (and maybe even deploy package(s)) More advanced: - Add a new view similar to the CVS Browser to be able to browse projects/packages on the buildservice and download them with rightclick [...] Btw.: on http://code.google.com/soc/2008/suse/appinfo.html?csaid=DFC9A170A95499CD you wrote, that the eclipse integration would depend on osc. I do not think, that this would be a good approach. An eclipse plugin should work out-of-the-box without installing additional software, IMHO. For internal purposes I started writing a java client for the buildservice to be able to upload, download and query the buildservice from within ant-tasks, that are integrated into CruiseControl¹. Maybe we could combine our work and create a java client library for the buildservice. ¹ http://cruisecontrol.sourceforge.net/ -- With best regards, Carsten Hoeger

long hong

15:42

2008/4/22 Carsten Hoeger :

...

On Tue, Apr 22, long hong wrote:

...
Hello, everyone! This summer I shall attend the Google Summer of Code, adding build service functions to eclipse. The bellow is my project: http://code.google.com/soc/2008/suse/appinfo.html?csaid=DFC9A170A95499CD

Nice to hear! :-)

...
Now I just want to gather users' expectations to this project. What would you like to see when using Build-Service in Eclipse? Thanks a lot!

Here some use cases that come to my mind:

- Add/Change packages - Edit/Create package Templates - Add/Change projects - Edit/Create project Templates - Add a "New Buildservice Package/Projekt" Workflow - Edit specfiles and debian/* files using eclipse and upload them to the buildservice automatically - could be achieved in using/integrating existing technology, e.g. https://admin.fedoraproject.org/pkgdb/packages/name/eclipse-rpm-editor - monitor build status - download (and maybe even deploy package(s))

More advanced:

- Add a new view similar to the CVS Browser to be able to browse projects/packages on the buildservice and download them with rightclick

[...] I think SVN like is better :)

Btw.: on http://code.google.com/soc/2008/suse/appinfo.html?csaid=DFC9A170A95499CD you wrote, that the eclipse integration would depend on osc. I do not think, that this would be a good approach. An eclipse plugin should work out-of-the-box without installing additional software, IMHO. OK, I see. Maybe I should add functions similar to OSC but not use OSC directly. I think first I should try to use Build-Service API. Anyway I've never used RENT before althouth I know what it is.

For internal purposes I started writing a java client for the buildservice to be able to upload, download and query the buildservice from within ant-tasks, that are integrated into CruiseControl¹.

Maybe we could combine our work and create a java client library for the buildservice. Interesting! Is it hard to do so?

¹ http://cruisecontrol.sourceforge.net/

-- With best regards,

Carsten Hoeger

--------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

Carsten Hoeger

15:58

New subject: [opensuse-buildservice] Adding Build-service function to Eclipse! Any suggestions?

On Tue, Apr 22, long hong wrote:

...

...
More advanced:

- Add a new view similar to the CVS Browser to be able to browse projects/packages on the buildservice and download them with rightclick

[...] I think SVN like is better :)

SVN has advantages over cvs, yes. I never used the svn browser of eclipse, but the functionality should be the same.

...

...
Btw.: on http://code.google.com/soc/2008/suse/appinfo.html?csaid=DFC9A170A95499CD you wrote, that the eclipse integration would depend on osc. I do not think, that this would be a good approach. An eclipse plugin should work out-of-the-box without installing additional software, IMHO. OK, I see. Maybe I should add functions similar to OSC but not use OSC directly. I think first I should try to use Build-Service API. Anyway I've never used RENT before althouth I know what it is.

With RENT you mean REST, don't you?

...

...
For internal purposes I started writing a java client for the buildservice to be able to upload, download and query the buildservice from within ant-tasks, that are integrated into CruiseControl¹.

Maybe we could combine our work and create a java client library for the buildservice. Interesting! Is it hard to do so?

Not really once you found out what java projects to use to parse xml (I'm currently using XPath), do html connects, etc. Ant integration in writing custom ant tasks is quite easy once you have a bs java client... :-) -- With best regards, Carsten Hoeger

long hong

16:05

2008/4/22 Carsten Hoeger :

...

On Tue, Apr 22, long hong wrote:

...
...
More advanced:

- Add a new view similar to the CVS Browser to be able to browse projects/packages on the buildservice and download them with rightclick

[...] I think SVN like is better :)

SVN has advantages over cvs, yes. I never used the svn browser of eclipse, but the functionality should be the same.

...
...
Btw.: on http://code.google.com/soc/2008/suse/appinfo.html?csaid=DFC9A170A95499CD you wrote, that the eclipse integration would depend on osc. I do not think, that this would be a good approach. An eclipse plugin should work out-of-the-box without installing additional software, IMHO. OK, I see. Maybe I should add functions similar to OSC but not use OSC directly. I think first I should try to use Build-Service API. Anyway I've never used RENT before althouth I know what it is.

With RENT you mean REST, don't you? Yes, REST :P

...
...
For internal purposes I started writing a java client for the buildservice to be able to upload, download and query the buildservice from within ant-tasks, that are integrated into CruiseControl¹.

Maybe we could combine our work and create a java client library for the buildservice. Interesting! Is it hard to do so?

Not really once you found out what java projects to use to parse xml (I'm currently using XPath), do html connects, etc.

Ant integration in writing custom ant tasks is quite easy once you have a bs java client... :-) I just know that there is a QT-client for BS. This summer two or more Java client will appear :D

--

With best regards,

Carsten Hoeger

Pavol Rusnak

16:09

long hong wrote:

...

I just know that there is a QT-client for BS.

It only displays project status. Nothing else could be done with this tool. -- Best Regards / S pozdravom, Pavol RUSNAK SUSE LINUX, s.r.o Package Maintainer Lihovarska 1060/12 PGP 0xA6917144 19000 Praha 9, CR prusnak[at]suse.cz http://www.suse.cz --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

long hong

23 Apr 23 Apr

09:30

2008/4/23 Pavol Rusnak :

...

long hong wrote:

...
I just know that there is a QT-client for BS.

It only displays project status. Nothing else could be done with this tool. So it just use GET to read project status? Can it be that easy?

-- Best Regards / S pozdravom,

Pavol RUSNAK SUSE LINUX, s.r.o Package Maintainer Lihovarska 1060/12 PGP 0xA6917144 19000 Praha 9, CR prusnak[at]suse.cz http://www.suse.cz --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

Carsten Hoeger

16:41

New subject: [opensuse-buildservice] Adding Build-service function to Eclipse! Any suggestions?

On Wed, Apr 23, long hong wrote:

...

...
...
I just know that there is a QT-client for BS.

It only displays project status. Nothing else could be done with this tool. So it just use GET to read project status? Can it be that easy?

Yes. -- With best regards, Carsten Hoeger

Michael Hutchinson

19:09

Sorry for replying without context; I only joined the mailing list after the first few messages in this thread... I'm particularly interested in the planning of this project and the GNOME build service client, as I'm planning to implement similar functionality in MonoDevelop, the Mono (C# etc) IDE. Hence if we could share ideas, plans, designs and other information, that would be great. It's a shame all three of us are using different runtimes, as this means we can't share code directly :-/ -- Michael Hutchinson http://mjhutchinson.com --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

long hong

19:51

Do you want to use OSC? If we all use osc, then we all use the same runtime :) Certainly using API is more straightforward. But I don't think the two ways make too much difference. 2008/4/24 Michael Hutchinson :

...

Sorry for replying without context; I only joined the mailing list after the first few messages in this thread...

I'm particularly interested in the planning of this project and the GNOME build service client, as I'm planning to implement similar functionality in MonoDevelop, the Mono (C# etc) IDE. Hence if we could share ideas, plans, designs and other information, that would be great. It's a shame all three of us are using different runtimes, as this means we can't share code directly :-/

-- Michael Hutchinson http://mjhutchinson.com

Michael Hutchinson

20:10

On Wed, Apr 23, 2008 at 3:51 PM, long hong wrote:

...

Do you want to use OSC? If we all use osc, then we all use the same runtime :) Certainly using API is more straightforward. But I don't think the two ways make too much difference.

I'd been considering using osc, but since the build service API looks relatively straightforward, it's probably easier to do it directly from C#. The thing that IMO might be a bit more challenging is performing local builds... -- Michael Hutchinson http://mjhutchinson.com --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

Marcus Hüwe

21:15

New subject: [opensuse-buildservice] Adding Build-service function to Eclipse! Any suggestions?

On 2008-04-23 16:10:26 -0400, Michael Hutchinson wrote:

...

On Wed, Apr 23, 2008 at 3:51 PM, long hong wrote:

...
Do you want to use OSC? If we all use osc, then we all use the same runtime :) Certainly using API is more straightforward. But I don't think the two ways make too much difference.

I'd been considering using osc, but since the build service API looks relatively straightforward, it's probably easier to do it directly from C#. The thing that IMO might be a bit more challenging is performing local builds...

Well perfoming local builds shouldn't be too hard. Basically it consists of 3 things: - getting the prjconf (can be retrieved via the api) - getting the buildconfig (can be retrieved via the api too) - calling the /usr/bin/build script with some parameters etc. (btw. that's how osc does it, too) So independent from your preferred language you will probably just need to do these steps. Marcus --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

Peter Poeml

24 Apr 24 Apr

08:34

On Wed, Apr 23, 2008 at 11:15:55PM +0200, Marcus Hüwe wrote:

...

On 2008-04-23 16:10:26 -0400, Michael Hutchinson wrote:

...
I'd been considering using osc, but since the build service API looks relatively straightforward, it's probably easier to do it directly from C#. The thing that IMO might be a bit more challenging is performing local builds...

Well perfoming local builds shouldn't be too hard. Basically it consists of 3 things: - getting the prjconf (can be retrieved via the api) - getting the buildconfig (can be retrieved via the api too) - calling the /usr/bin/build script with some parameters etc.

- downloading of needed packages from the api and caching them

...

(btw. that's how osc does it, too)

So independent from your preferred language you will probably just need to do these steps.

Or, if the working copies are "osc compatible", just call osc for this part of the job. Nobody is going to rewrite "build" in Java of C#, either, or is anyone? :-) Peter -- "WARNING: This bug is visible to non-employees. Please be respectful!" SUSE LINUX Products GmbH Research & Development

Peter Poeml

08:32

On Wed, Apr 23, 2008 at 04:10:26PM -0400, Michael Hutchinson wrote:

...

On Wed, Apr 23, 2008 at 3:51 PM, long hong wrote:

...
Do you want to use OSC? If we all use osc, then we all use the same runtime :) Certainly using API is more straightforward. But I don't think the two ways make too much difference.

I'd been considering using osc, but since the build service API looks relatively straightforward, it's probably easier to do it directly from C#. The thing that IMO might be a bit more challenging is performing local builds...

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 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. - 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. 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 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) Anyway, it would be nice to have forces joined and work together on one library, wouldn't it? Peter -- "WARNING: This bug is visible to non-employees. Please be respectful!" SUSE LINUX Products GmbH Research & Development

Michael Hutchinson

16:10

On Thu, Apr 24, 2008 at 4:32 AM, Peter Poeml 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@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

Rodrigo Moya

28 Apr 28 Apr

14:41

New subject: [opensuse-buildservice] Adding Build-service function to Eclipse! Any suggestions?

On Thu, 2008-04-24 at 03:51 +0800, long hong wrote:

...

Do you want to use OSC? If we all use osc, then we all use the same runtime :) Certainly using API is more straightforward. But I don't think the two ways make too much difference.

using OSC for complex command's output might be quite tricky -- Rodrigo Moya --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

Rodrigo Moya

14:40

New subject: [opensuse-buildservice] Adding Build-service function to Eclipse! Any suggestions?

On Wed, 2008-04-23 at 15:09 -0400, Michael Hutchinson wrote:

...

Sorry for replying without context; I only joined the mailing list after the first few messages in this thread...

I'm particularly interested in the planning of this project and the GNOME build service client, as I'm planning to implement similar functionality in MonoDevelop, the Mono (C# etc) IDE. Hence if we could share ideas, plans, designs and other information, that would be great. It's a shame all three of us are using different runtimes, as this means we can't share code directly :-/

yes, I think we should consider sharing the client implementation as much as possible, so I see 2 solutions: * write a C library and create bindings from it * write a D-Bus daemon that can be contacted via any D-Bus bindings for the GNOME client we were planning to use the OSC API, since we'll be using pygtk, but since the Java and Mono clients are not able to use it and so need to write their own client lib, I think we could use some of the SoC student's time to work on this shared layer, couldn't we? -- Rodrigo Moya --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

Adrian Schröter

14:48

On Monday 28 April 2008 16:40:57 wrote Rodrigo Moya:

...

On Wed, 2008-04-23 at 15:09 -0400, Michael Hutchinson wrote:

...
Sorry for replying without context; I only joined the mailing list after the first few messages in this thread...

I'm particularly interested in the planning of this project and the GNOME build service client, as I'm planning to implement similar functionality in MonoDevelop, the Mono (C# etc) IDE. Hence if we could share ideas, plans, designs and other information, that would be great. It's a shame all three of us are using different runtimes, as this means we can't share code directly :-/

yes, I think we should consider sharing the client implementation as much as possible, so I see 2 solutions:

* write a C library and create bindings from it * write a D-Bus daemon that can be contacted via any D-Bus bindings

for the GNOME client we were planning to use the OSC API, since we'll be using pygtk, but since the Java and Mono clients are not able to use it and so need to write their own client lib, I think we could use some of the SoC student's time to work on this shared layer, couldn't we?

Reading this, I wonder why we need a standard library for the api at all. Not that I am against it, but which functionality should go into it. I think most should be implemented on the api.o.o side. Pure http connect should be available in every development enviroment these days. Can you give some examples what kind of functionality makes sense to have in a common application library ? bye adrian -- Adrian Schroeter SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) email: adrian@suse.de --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

Marcus Hüwe

15:11

New subject: [opensuse-buildservice] Adding Build-service function to Eclipse! Any suggestions?

On 2008-04-28 16:48:31 +0200, Adrian Schröter wrote:

...

On Monday 28 April 2008 16:40:57 wrote Rodrigo Moya:

...
On Wed, 2008-04-23 at 15:09 -0400, Michael Hutchinson wrote:

...
Sorry for replying without context; I only joined the mailing list after the first few messages in this thread...

I'm particularly interested in the planning of this project and the GNOME build service client, as I'm planning to implement similar functionality in MonoDevelop, the Mono (C# etc) IDE. Hence if we could share ideas, plans, designs and other information, that would be great. It's a shame all three of us are using different runtimes, as this means we can't share code directly :-/

yes, I think we should consider sharing the client implementation as much as possible, so I see 2 solutions:

* write a C library and create bindings from it * write a D-Bus daemon that can be contacted via any D-Bus bindings

for the GNOME client we were planning to use the OSC API, since we'll be using pygtk, but since the Java and Mono clients are not able to use it and so need to write their own client lib, I think we could use some of the SoC student's time to work on this shared layer, couldn't we?

Reading this, I wonder why we need a standard library for the api at all.

Not that I am against it, but which functionality should go into it. I think most should be implemented on the api.o.o side.

Pure http connect should be available in every development enviroment these days.

Can you give some examples what kind of functionality makes sense to have in a common application library ?

A common library would make sense for things like working with project dirs and package dirs etc. This should be done in a "unique" way e.g. it wouldn't make sense if each client has its own subdir (osc -> .osc, client1 -> .client1...). But I get the impression that only the gnome obs client would need this functionality and the others "merely" do http requests. Marcus --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

Mario

15:12

...

A common library would make sense for things like working with project dirs and package dirs etc. This should be done in a "unique" way e.g. it wouldn't make sense if each client has its own subdir (osc -> .osc, client1 -> .client1...). Actually, such a library will be written as part of my SoC so somebody could easily write QT frontend on top of it. But current discussions is more that one of osc re-implementation in several languages, and possible ways to avoid that.

KR, M. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

Adrian Schröter

29 Apr 29 Apr

00:19

On Monday 28 April 2008 17:11:42 wrote Marcus Hüwe:

...

On 2008-04-28 16:48:31 +0200, Adrian Schröter wrote:

...
On Monday 28 April 2008 16:40:57 wrote Rodrigo Moya:

...
On Wed, 2008-04-23 at 15:09 -0400, Michael Hutchinson wrote:

...
Sorry for replying without context; I only joined the mailing list after the first few messages in this thread...

I'm particularly interested in the planning of this project and the GNOME build service client, as I'm planning to implement similar functionality in MonoDevelop, the Mono (C# etc) IDE. Hence if we could share ideas, plans, designs and other information, that would be great. It's a shame all three of us are using different runtimes, as this means we can't share code directly :-/

yes, I think we should consider sharing the client implementation as much as possible, so I see 2 solutions:

* write a C library and create bindings from it * write a D-Bus daemon that can be contacted via any D-Bus bindings

for the GNOME client we were planning to use the OSC API, since we'll be using pygtk, but since the Java and Mono clients are not able to use it and so need to write their own client lib, I think we could use some of the SoC student's time to work on this shared layer, couldn't we?

Reading this, I wonder why we need a standard library for the api at all.

Not that I am against it, but which functionality should go into it. I think most should be implemented on the api.o.o side.

Pure http connect should be available in every development enviroment these days.

Can you give some examples what kind of functionality makes sense to have in a common application library ?

A common library would make sense for things like working with project dirs and package dirs etc. This should be done in a "unique" way e.g. it wouldn't make sense if each client has its own subdir (osc -> .osc, client1 -> .client1...).

indeed, that makes much sense. bye adrian -- Adrian Schroeter SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) email: adrian@suse.de --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

Cornelius Schumacher

08:23

On Monday 28 April 2008, Marcus Hüwe wrote:

...

A common library would make sense for things like working with project dirs and package dirs etc. This should be done in a "unique" way e.g. it wouldn't make sense if each client has its own subdir (osc -> .osc, client1 -> .client1...).

Would that need a library? Wouldn't it be sufficient to establish a documented standardized convention how to store data locally? -- Cornelius Schumacher --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

Marcus Hüwe

10:49

New subject: [opensuse-buildservice] Adding Build-service function to Eclipse! Any suggestions?

On 2008-04-29 10:23:43 +0200, Cornelius Schumacher wrote:

...

On Monday 28 April 2008, Marcus Hüwe wrote:

...
A common library would make sense for things like working with project dirs and package dirs etc. This should be done in a "unique" way e.g. it wouldn't make sense if each client has its own subdir (osc -> .osc, client1 -> .client1...).

Would that need a library? Wouldn't it be sufficient to establish a documented standardized convention how to store data locally?

Hmm if I think about it again I would say no:) - if there's standardized way how to store the data everything is fine. The only drawback is that each client has to implement it from scratch - nevertheless this shouldn't be too hard because it's just about parsing and interpreting xml files... Marcus --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

Dirk Stoecker

11:21

On Tue, 29 Apr 2008, Marcus Hüwe wrote:

...

...
...
A common library would make sense for things like working with project dirs and package dirs etc. This should be done in a "unique" way e.g. it wouldn't make sense if each client has its own subdir (osc -> .osc, client1 -> .client1...).

Would that need a library? Wouldn't it be sufficient to establish a documented standardized convention how to store data locally?

Hmm if I think about it again I would say no:) - if there's standardized way how to store the data everything is fine. The only drawback is that each client has to implement it from scratch - nevertheless this shouldn't be too hard because it's just about parsing and interpreting xml files...

Actually it is very straighforward. Don't see any reason for support library functions here: _apiurl https://api.opensuse.org _osclib_version 0.99 _package alpine _project home:dstoecker The following two are from server (at least _meta is, I'm sure). _files: <directory name="alpine" rev="34" vrev="1" srcmd5="3d3c9aa4d3e8977f875752064d197838"> <entry name="all-1.10_20080316.patch.gz" md5="feea012e1438dba9092ca49ae22a17c7" size="168769" mtime="1205825205" /> <entry name="alpine-1.10.tar.bz2" md5="c507684620766ed091186785a0dccbca" size="4861929" mtime="1205825256" /> <entry name="alpine.spec" md5="c83d88a072b15fa631ce5872a1fcd6a6" size="3100" mtime="1205825258" /> </directory> _meta: <package project="home:dstoecker" name="alpine"> <title>University of Washington Pine mail user agent</title> <description>Alpine -- an Alternatively Licensed Program for Internet News & Email -- is a tool for reading, sending, and managing electronic messages. Alpine is the successor to Pine and was developed by Computing & Communications at the University of Washington. Though originally designed for inexperienced email users, Alpine supports many advanced features, and an ever-growing number of configuration and personal-preference options. </description> <person role="maintainer" userid="dstoecker"/> <build> <disable repository='SLES_9'/> </build> <url>ftp://ftp.cac.washington.edu/alpine/</url> </package> Ciao -- http://www.dstoecker.eu/ (PGP key available)

Rodrigo Moya

28 Apr 28 Apr

15:34

New subject: [opensuse-buildservice] Adding Build-service function to Eclipse! Any suggestions?

On Mon, 2008-04-28 at 16:48 +0200, Adrian Schröter wrote:

...

On Monday 28 April 2008 16:40:57 wrote Rodrigo Moya:

...
On Wed, 2008-04-23 at 15:09 -0400, Michael Hutchinson wrote:

...
Sorry for replying without context; I only joined the mailing list after the first few messages in this thread...

I'm particularly interested in the planning of this project and the GNOME build service client, as I'm planning to implement similar functionality in MonoDevelop, the Mono (C# etc) IDE. Hence if we could share ideas, plans, designs and other information, that would be great. It's a shame all three of us are using different runtimes, as this means we can't share code directly :-/

yes, I think we should consider sharing the client implementation as much as possible, so I see 2 solutions:

* write a C library and create bindings from it * write a D-Bus daemon that can be contacted via any D-Bus bindings

for the GNOME client we were planning to use the OSC API, since we'll be using pygtk, but since the Java and Mono clients are not able to use it and so need to write their own client lib, I think we could use some of the SoC student's time to work on this shared layer, couldn't we?

Reading this, I wonder why we need a standard library for the api at all.

Not that I am against it, but which functionality should go into it. I think most should be implemented on the api.o.o side.

Pure http connect should be available in every development enviroment these days.

yes, but if every app needs to use the HTTP API, there will be for sure need for some extra code than the one to send and receive results, which I'll mention below...

...

Can you give some examples what kind of functionality makes sense to have in a common application library ?

authentication, error handling, basic results processing, asynchronous calls... that is, do we want every app to deal with 1st time authentication, for instance, or API changes in the server ? -- Rodrigo Moya --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

Adrian Schröter

20:43

On Monday 28 April 2008 17:34:12 wrote Rodrigo Moya:

...

On Mon, 2008-04-28 at 16:48 +0200, Adrian Schröter wrote:

...
On Monday 28 April 2008 16:40:57 wrote Rodrigo Moya:

...
On Wed, 2008-04-23 at 15:09 -0400, Michael Hutchinson wrote:

...
Sorry for replying without context; I only joined the mailing list after the first few messages in this thread...

I'm particularly interested in the planning of this project and the GNOME build service client, as I'm planning to implement similar functionality in MonoDevelop, the Mono (C# etc) IDE. Hence if we could share ideas, plans, designs and other information, that would be great. It's a shame all three of us are using different runtimes, as this means we can't share code directly :-/

yes, I think we should consider sharing the client implementation as much as possible, so I see 2 solutions:

* write a C library and create bindings from it * write a D-Bus daemon that can be contacted via any D-Bus bindings

for the GNOME client we were planning to use the OSC API, since we'll be using pygtk, but since the Java and Mono clients are not able to use it and so need to write their own client lib, I think we could use some of the SoC student's time to work on this shared layer, couldn't we?

Reading this, I wonder why we need a standard library for the api at all.

Not that I am against it, but which functionality should go into it. I think most should be implemented on the api.o.o side.

Pure http connect should be available in every development enviroment these days.

yes, but if every app needs to use the HTTP API, there will be for sure need for some extra code than the one to send and receive results, which I'll mention below...

...
Can you give some examples what kind of functionality makes sense to have in a common application library ?

authentication, error handling, basic results processing, asynchronous calls... that is, do we want every app to deal with 1st time authentication, for instance, or API changes in the server ?

k, but when you write a generic C library for this than you need to wrap this one again into Python, Ruby, Qt, ... specific interfaces via another lib or code stub. Don't you think this native code could directly use the http api ? I personally think it is easier to handle this in native code. It is at least easier for me to write a Qt lib directly using the http api than to wrap around a C lib without any signal handling. While a http request is a one liner in Qt and signal and error handling is more or less for free. I see a point with the authentification handling though ... We do our best to keep the API stable. But you would anyway need to adapt the library and the native language code stub anyway if we don't ... -- Adrian Schroeter SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) email: adrian@suse.de --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

Benji Weber

14:57

On 28/04/2008, Rodrigo Moya wrote:

...

yes, I think we should consider sharing the client implementation as much as possible, so I see 2 solutions:

* write a C library and create bindings from it * write a D-Bus daemon that can be contacted via any D-Bus bindings

for the GNOME client we were planning to use the OSC API, since we'll be using pygtk, but since the Java and Mono clients are not able to use it and so need to write their own client lib, I think we could use some of the SoC student's time to work on this shared layer, couldn't we?

This seems a little unnecessary. Consuming webservice API from java/.net is already particularly easy. Consuming a c library with bindings or a DBUS api is considerably more complicated (at least in java). Not to mention the potential problems with breaking compatibility with the library consumers with future changes. API.opensuse.org already defines a programming language independent API, why do you need another? -- Benjamin Weber --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

Carsten Hoeger

15:00

New subject: [opensuse-buildservice] Adding Build-service function to Eclipse! Any suggestions?

On Mon, Apr 28, Benji Weber wrote:

...

...
yes, I think we should consider sharing the client implementation as much as possible, so I see 2 solutions:

* write a C library and create bindings from it * write a D-Bus daemon that can be contacted via any D-Bus bindings

for the GNOME client we were planning to use the OSC API, since we'll be using pygtk, but since the Java and Mono clients are not able to use it and so need to write their own client lib, I think we could use some of the SoC student's time to work on this shared layer, couldn't we?

This seems a little unnecessary. Consuming webservice API from java/.net is already particularly easy. Consuming a c library with bindings or a DBUS api is considerably more complicated (at least in java). Not to mention the potential problems with breaking compatibility with the library consumers with future changes. API.opensuse.org already defines a programming language independent API, why do you need another?

Exactly. And in addition I won't even start to think about the native-code-into-eclipse-integration-nightmare. -- With best regards, Carsten Hoeger

Michal Marek

16:20

Benji Weber napsal(a):

...

On 28/04/2008, Rodrigo Moya wrote:

...
yes, I think we should consider sharing the client implementation as much as possible, so I see 2 solutions:

* write a C library and create bindings from it * write a D-Bus daemon that can be contacted via any D-Bus bindings

for the GNOME client we were planning to use the OSC API, since we'll be using pygtk, but since the Java and Mono clients are not able to use it and so need to write their own client lib, I think we could use some of the SoC student's time to work on this shared layer, couldn't we?

This seems a little unnecessary. Consuming webservice API from java/.net is already particularly easy. Consuming a c library with bindings or a DBUS api is considerably more complicated (at least in java). Not to mention the potential problems with breaking compatibility with the library consumers with future changes. API.opensuse.org already defines a programming language independent API, why do you need another?

Agreed. Sure, some features are more complicated than just parsing XML received via HTTP (local build), but in these cases we can as well use the osc program externally. I think we should rather make sure that osc (the program) is scripting-friendly. Then there's also the problem of coordination, that the SoC student(s) working on the common library will block others' work on the actual client programs. I think the students will have enough fun meeting the SoC deadlines themselves ;-). Michal --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

Klaas Freitag

23 Apr 23 Apr

08:50

Hi,

> > http://code.google.com/soc/2008/suse/appinfo.html?csaid=DFC9A170A95499CD
>
> Nice to hear! :-)
Yes, that's great :)

> > Now I just want to gather users' expectations to this project. What
> > would you like to see when using Build-Service in Eclipse? Thanks a
> > lot!
>
> Here some use cases that come to my mind:
>
> - Add/Change packages
I think Changing packages is a key thing. That means knowing the important
file formats like tarballs, specs, dsc's etc. and offering editors for them,
maybe on the fly checks on syntax etc. where applicable.
- Create package source links 

>   - Edit/Create package Templates
Do you think about kind of "personal" Package Templates? Or general BS
templates? If the latter, I don't think they should be really editable
in Eclipse but somehow downloadable and available in the Eclipseclient
on new package creation. However we do not have too much about templates 
yet, so this is not high priority.

> - Add/Change projects
Again here Editing as a key thing, similar to what I wrote about packages
above. Additionally the client could assist for example on creating a 
metapackage as describecd for example on 
http://en.opensuse.org/Meta_Packages/ISV and other project specific things.

- Create submit requests

>   - Edit/Create project Templates
> - Add a "New Buildservice Package/Projekt" Workflow
Again, these two seem to depend on templates.

> - Edit specfiles and debian/* files using eclipse and upload them to the
>   buildservice automatically
Directly after editing or on a "Sync with BS" command?

>   - could be achieved in using/integrating existing technology, e.g.
>     https://admin.fedoraproject.org/pkgdb/packages/name/eclipse-rpm-editor
> - monitor build status
Yes, important and can be quite eye-candy and thus a real benefit :)

> - download (and maybe even deploy package(s))
Deploying is IMO a very interesting thing, we do not have that in other
clients IMO. Can you elaborate a bit what is important there from a 
ISV s POV?

> More advanced:
>
> - Add a new view similar to the CVS Browser to be able to browse
>   projects/packages on the buildservice and download them with rightclick
Also Browsing by tags would be nice.

> Btw.: on
> http://code.google.com/soc/2008/suse/appinfo.html?csaid=DFC9A170A95499CD
> you wrote, that the eclipse integration would depend on osc. I do not
> think, that this would be a good approach. An eclipse plugin should work
> out-of-the-box without installing additional software, IMHO.
Agreed. OTOH osc evolves to be a cool python lib that eases client development
a lot. But probably in the Eclipse case native Java is probably better. I hope
there are enough usefull java tools to make that easy.
>
> For internal purposes I started writing a java client for the buildservice
> to be able to upload, download and query the buildservice from within
> ant-tasks, that are integrated into CruiseControl¹.
>
> Maybe we could combine our work and create a java client library for the
> buildservice.
Cool :)

Klaas


-- 
Klaas Freitag                              Architect OPS/IPD
                        SUSE LINUX Products GmbH - Nuernberg
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org
For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

Carsten Hoeger

24 Apr 24 Apr

07:31

New subject: [opensuse-buildservice] Adding Build-service function to Eclipse! Any suggestions?

On Wed, Apr 23, Klaas Freitag wrote:

> > > http://code.google.com/soc/2008/suse/appinfo.html?csaid=DFC9A170A95499CD
> >
> > Nice to hear! :-)
> Yes, that's great :)
> 
> > > Now I just want to gather users' expectations to this project. What
> > > would you like to see when using Build-Service in Eclipse? Thanks a
> > > lot!
> >
> > Here some use cases that come to my mind:
> >
> > - Add/Change packages
> I think Changing packages is a key thing. That means knowing the important
> file formats like tarballs, specs, dsc's etc. and offering editors for them,
> maybe on the fly checks on syntax etc. where applicable.
> - Create package source links 

Exactly
 
> >   - Edit/Create package Templates
> Do you think about kind of "personal" Package Templates? Or general BS
> templates? If the latter, I don't think they should be really editable
> in Eclipse but somehow downloadable and available in the Eclipseclient
> on new package creation. However we do not have too much about templates 
> yet, so this is not high priority.

I had these .xml files in mind, which represent a package.


  my foo package
  bla
  


 
> > - Add/Change projects
> Again here Editing as a key thing, similar to what I wrote about packages
> above. Additionally the client could assist for example on creating a 
> metapackage as describecd for example on 
> http://en.opensuse.org/Meta_Packages/ISV and other project specific things.
> 
> - Create submit requests
> 
> >   - Edit/Create project Templates
> > - Add a "New Buildservice Package/Projekt" Workflow
> Again, these two seem to depend on templates.
> 
> > - Edit specfiles and debian/* files using eclipse and upload them to the
> >   buildservice automatically
> Directly after editing or on a "Sync with BS" command?
 
sync would IMHO fit better in the eclipse approach (see synchronize with team
on svn/cvs checkouts).

> >   - could be achieved in using/integrating existing technology, e.g.
> >     https://admin.fedoraproject.org/pkgdb/packages/name/eclipse-rpm-editor
> > - monitor build status
> Yes, important and can be quite eye-candy and thus a real benefit :)
> 
> > - download (and maybe even deploy package(s))
> Deploying is IMO a very interesting thing, we do not have that in other
> clients IMO. Can you elaborate a bit what is important there from a 
> ISV s POV?

As an ISV or as a sofware developer in general you need to test, develop and
test again. Part of a test is to install and test the software like the end
user is going to do it.

Of course that can be archieved in starting a package installer such as yast,
apt, yum, ..., but that would mean that it is required configure the obs repo
of the project as an installation source. It would be more easy if the
developer could just click und download and install. Of course that will only
work if there are no unsatisfied dependencies anymore.

I could imagine the functionalities:

- Install single package from project X
- Install all packages belonging to project X

And of course a method that uses the os buildin installer to install a package
is also nice to have.

I do not consider this deploy feature to be a must have, however.

> > More advanced:
> >
> > - Add a new view similar to the CVS Browser to be able to browse
> >   projects/packages on the buildservice and download them with rightclick
> Also Browsing by tags would be nice.
> 
> > Btw.: on
> > http://code.google.com/soc/2008/suse/appinfo.html?csaid=DFC9A170A95499CD
> > you wrote, that the eclipse integration would depend on osc. I do not
> > think, that this would be a good approach. An eclipse plugin should work
> > out-of-the-box without installing additional software, IMHO.
> Agreed. OTOH osc evolves to be a cool python lib that eases client development
> a lot. But probably in the Eclipse case native Java is probably better.

Creating a library as a sub-project has the additional advantage, that it can
be used by other Java based project in addition.

> I hope
> there are enough usefull java tools to make that easy.

Well, to parse XML in Java you have the choice between a gazillion different
choices. A http client is available from the jakarta commons project and even
part of the JDK.

> > For internal purposes I started writing a java client for the buildservice
> > to be able to upload, download and query the buildservice from within
> > ant-tasks, that are integrated into CruiseControl¹.
> >
> > Maybe we could combine our work and create a java client library for the
> > buildservice.
> Cool :)

-- 
With best regards,

Carsten Hoeger

Michal Marek

28 Apr 28 Apr

12:08

Klaas Freitag wrote:
> Hi,
> 
>>> http://code.google.com/soc/2008/suse/appinfo.html?csaid=DFC9A170A95499CD
>> Nice to hear! :-)
> Yes, that's great :)
> 
>>> Now I just want to gather users' expectations to this project. What
>>> would you like to see when using Build-Service in Eclipse? Thanks a
>>> lot!
>> Here some use cases that come to my mind:
>>
>> - Add/Change packages
> I think Changing packages is a key thing. That means knowing the important
> file formats like tarballs, specs, dsc's etc. and offering editors for them,
> maybe on the fly checks on syntax etc. where applicable.
> - Create package source links 

What is a "package source link" and why should I need it? :)

I mean, source links are of course a cool feature of the buildservice,
but I don't think it's a must have for the eclipse plugin, not for the
first version at least. I think that a plugin that let's you upload a
source tarball of your project to the bs, edit a spec / dsc file,
monitor build status and download the resulting packages would already
be a good outcome of the SoC project. More advanced features can be
added later :)

Michal
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org
For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

5834

Age (days ago)

5841

Last active (days ago)

List overview

Download

31 comments

14 participants

participants (14)

Adrian Schröter
Benji Weber
Carsten Hoeger
Cornelius Schumacher
Dirk Stoecker
Klaas Freitag
long hong
Marcus Hüwe
Mario
Michael Hutchinson
Michal Marek
Pavol Rusnak
Peter Poeml
Rodrigo Moya