24 Apr
2008
24 Apr
'08
07:31
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.> > - 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 my foo package bla