Mailinglist Archive: opensuse-buildservice (375 mails)

< Previous Next >
Re: [opensuse-buildservice] Adding Build-service function to Eclipse! Any suggestions?
  • From: Carsten Hoeger <choeger@xxxxxxxxxxxxxxxx>
  • Date: Thu, 24 Apr 2008 09:31:26 +0200
  • Message-id: <20080424073126.GC4191@xxxxxxxxxxxxxxxx>
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.

<package name="foo" project="bar">
<title>my foo package</title>
<description>bla</description>
<person userid="me" role="maintainer"/>
</package>


- 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
< Previous Next >