Hey Jan Willem, On Fri, Jan 22, 2016 at 3:48 PM, Jan Willem Janssen <janwillem.jans...@luminis.eu> wrote: > Hi community, > > It has been very quiet the past couple of months on the development of ACE. I > am currently busy with picking up the last issues we need to resolve in order > to prepare a new release of ACE (which is long overdue already). >
Great, nice to see some action here :) > After the release, we’d like to start working on improving ACE again. We know > that ACE has several white spots that might impact its use for your use cases. > Therefore, I’d love to hear your feedback on ACE: issues, abeyance's and > hurdles you’ve come across and you like to see improved. Other ideas on what > can be improved are welcome as well :) > My three cents... :) 1) OSGi Repository support ACE is tightly coupled to it's internal and rather simplistic OBR implementation. AFAIK it has not been updated to the OSGi Repository specification, it uses a simple directory tree on disk and has to fully rebuild it's index on every change. Thus you can not extend metadata, there is no backup/restore provision and it doesn't scale well. So, instead of trying to fix all this, why not decouple it. Why not let ACE be configurable to talk to any number of organizational/upstream repositories that are already out there. For example, there have been a number of question about nexus, but it would also be nice to be able to link to Bnd Hub and not having to store and manage all those standard bundles separately. Obviously we could still keep an updated ACE OBR als a simple default. 2) Improved/pluggable storage. As mentioned before on our lists the current (zipped xml) storage model is awkward. Although fully versioned it lacks tooling to work with, has serious performance issues and has no backup/restore provision. Maybe improve on it and keep it as a default that does not depend on other infra, but again I think it would be beneficial to allow ACE to leverage existing managed infra where required. Note that this could be local database storage, but also distributed storage in which case servers/realys would not have to sync zipped zml over http at all! 3) Task oriented UI (on ReST) IMHO the webui is way passed it's expiration date. It's non-intuitive, it's unreliable, it's old technology, again doesn't scale and it just doesn't look sexy. I would suggest to extend/improve the ReST API and build a nice modern web interface against that. IMHO that ui should be way more task oriented, support users with searches (across repositories) , actively guide them with respect to configuration (required/supported tags etc) and resolver status etc. Probably it would have different (role based) perspectives. Finally, I think that in general we should focus more on easy-of-use-out-of-the-box. So.. documentation yes, but why don't we just have a number of common resource processors (zip/metatype/...) in there by default? grz Bram
