You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ace.apache.org by Jan Willem Janssen <ja...@luminis.eu> on 2016/01/22 15:48:43 UTC
[feedback] hurdles when working with ACE
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).
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 :)
Thanks in advance,
(cross posting to the dev@ list as well).
--
Met vriendelijke groeten | Kind regards
Jan Willem Janssen | Software Architect
+31 631 765 814
My world is something with Amdatu and Apache
Luminis Technologies
Churchillplein 1
7314 BZ Apeldoorn
+31 88 586 46 00
https://www.luminis.eu
KvK (CoC) 09 16 28 93
BTW (VAT) NL8170.94.441.B.01
Re: [feedback] hurdles when working with ACE
Posted by Jan Willem Janssen <ja...@luminis.eu>.
Hi Daan,
> On 25 Jan 2016, at 16:04, Daan Veldhof <da...@gmail.com> wrote:
>
> - The first challenge i've encountered was that I couldn't upload .zip
> files. I know there is a way to create your own resource processor, but it
> was easier for me to convert the .zip to .jar.
>
> - The second challenge was to create targets for celix. We've got celix
> working for Android devices, but they need different bundles because most
> Android devices contain an ARM processor. The solution for us was to create
> multiple targets with their cpu architecture in their id (i.e.
> celix_armeabi-v7a or celix_armeabi). I would like to see something were you
> could specify the id and in the tags you would specify the cpu
> architecture. So if you have a normal linux machine it would register
> itself to ace with {id:celix, cpu_arch: linux-x86} and a android device
> would register with {id:celix, cpu_arch:armeabi-v7a}
>
> - The third challenge was to use the REST api. There was some documentation
> but it wasn't enough. I looked like someone started with it, but didn't
> finish it. Eventually through the mailing-list I got it up and running.
>
> - The last thing i've encountered was that the automation bundle wasn't
> working properly. If a new target was added it wouldn't be registered and
> approved. You had to log in and retrieve and store a workspace before it
> would be registered and approved.
Thanks for your feedback. It aligns quite well with the thoughts and ideas we
already have on improving ACE.
I’m currently processing all the replies I’ve had so far, and I’ll include
yours as well.
Thanks again,
--
Met vriendelijke groeten | Kind regards
Jan Willem Janssen | Software Architect
+31 631 765 814
My world is something with Amdatu and Apache
Luminis Technologies
Churchillplein 1
7314 BZ Apeldoorn
+31 88 586 46 00
https://www.luminis.eu
KvK (CoC) 09 16 28 93
BTW (VAT) NL8170.94.441.B.01
Re: [feedback] hurdles when working with ACE
Posted by Bryan Hunt <bh...@mac.com>.
I have only scanned these emails, and seen some key words such as pluggable storage, REST, modern UI, etc. I’ve been working on just that. If there is any interest, have a look at: https://github.com/BryanHunt/web-in-a-box
Bryan
> On Jan 27, 2016, at 10:57 AM, Jan Willem Janssen <ja...@luminis.eu> wrote:
>
> Hi Pepijn,
>
> Thanks for your elaborate feedback! See my remarks/questions inline.
>
>> On 25 Jan 2016, at 21:32, Pepijn Noltes <pe...@gmail.com> wrote:
>> […]
>> My issues/improvements:
>>
>> - Simpler setup out of the box.
>>
>> The server-allinone contains a lot of feature I personally do not
>> use/need. This makes jumping into Apache ACE difficult.
>> For example - also mentioned by Daan - the need to approve targets is
>> not needed our current use case, but we have to work around this.
>> An other item is the four levels (artifacts, features, distributions
>> targets) as I understand this is adaptable, but out of the box there
>> are four.
>
> I think we should rethink how ACE by default is going to handle new
> targets. With your and Daan’s feedback I do see a real need for that.
>
>> - Support docker
>> Make it possible to "deploy" docker images using Apache ACE. Docker is
>> becoming more popular by the day and in my opinion rightly so.
>> Provisioning docker images in a more controlled manner is IMO still
>> missing.
>>
>> Although using Apache ACE to runtime deploy sets of bundles can be
>> very flexible and powerful in my experience sometimes a pre-created
>> OSGi docker image is preferable.
>> This minimizes the "entropy" of the system by introducing composed
>> OSGi bundles used in a (more) deterministic manner. Although
>> theoretically continuously deploying/undeploying bundles on a OSGi
>> container should work, in practice this can lead to issues (note that
>> should be considered bugs, but still). Also pre-created docker images
>> can be tested as-is and therefore be qualified as whole.
>>
>> A combination would be interesting, so default bundles and the
>> possibility to use Apache ACE to update default bundles / sprinkle on
>> additional bundles.
>>
>> Provide A minimal OSGi client containing the ACE agent and make this
>> images easy extendable by adding additional bundles / configuration
>> files. (See INAETICS (github) for a minimal OSGi client example).
>
> I see two ways ACE could support Docker: either by provisioning pre-built
> Docker images (tarballs) or by provisioning the Dockerfile only and let
> the agent on the target build the Docker image for you. Not sure yet
> which one is “better”. At the moment, I’m prototyping and playing a bit
> with a custom agent that could handle this, just to see how this might
> work.
>
>> Focus on making development of cluster / distributed systems more easy
>> without restarting the cluster. So updated bundles / docker images and
>> restarting ACE client should be possible and easy.
>
> Do you mean that ACE is acting as a cluster manager, or just provides
> the ability to provision multiple targets in a “transactional” manner
> (all or nothing approach)?
>
>> – Use the capability-requirement model resolving
>>
>> I would prefer using the capability requirement model to match what to
>> deploy instead of coupling artifact2feature, etc. Although this could
>> maybe be to complex, I think it's worth thinking about.
>>
>> Especially combining this with docker images (e.g. using docker labels
>> to add Provide-Capability / Require-Capability ) could be a
>> interesting feature. This could help in solving a problem where OSGi
>> is very good at, running mircroservices with multiple versions of
>> services. But in this case mircoservices means REST services provided
>> by docker containers.
>
> Interesting point. Need to ponder about this a little longer on how
> this would work out.
>
>> – Runtime configuration
>> When using Apache ACE I often ran in the desire the edit/update the
>> configuration file used. A more “inline” support to updating (e.g.
>> enable debug printing) small configuration files would be nice.
>
> Do you mean the configuration of ACE itself, or the configuration
> that is provisioned to the targets?
>
>> - Monitor targets
>> Maybe out of scope for Apache ACE, but also something I noticed would
>> be very welcome when using Apache ACE, is a more elaborate monitoring
>> of the targets. Maybe even something like a heartbeat to ensure the
>> target is alive.
>
> The fact that a target periodically sends feedback would actually
> provide this information already. But I think you mean that the UI
> should actively report when it hasn’t seen/heard from a target in
> a while?
>
>> - No gosh
>> I understand that gosh is very powerful, but I see it as yet another
>> scripting language I prefer not to learn. I would prefer a more
>> feature rich / responsive HTML UI and better supported REST api.
>
> Fair point: gosh isn’t the most intuitive way of talking to ACE. We
> need to come up with another way of doing that from a end-users
> perspective (RESTish responsive UI) and from an automation point of
> view (for automated deployments, CIs, etc).
>
> --
> Met vriendelijke groeten | Kind regards
>
> Jan Willem Janssen | Software Architect
> +31 631 765 814
>
>
> My world is something with Amdatu and Apache
>
> Luminis Technologies
> Churchillplein 1
> 7314 BZ Apeldoorn
> +31 88 586 46 00
>
> https://www.luminis.eu
>
> KvK (CoC) 09 16 28 93
> BTW (VAT) NL8170.94.441.B.01
>
Re: [feedback] hurdles when working with ACE
Posted by Jan Willem Janssen <ja...@luminis.eu>.
Hi Pepijn,
Thanks for your elaborate feedback! See my remarks/questions inline.
> On 25 Jan 2016, at 21:32, Pepijn Noltes <pe...@gmail.com> wrote:
> […]
> My issues/improvements:
>
> - Simpler setup out of the box.
>
> The server-allinone contains a lot of feature I personally do not
> use/need. This makes jumping into Apache ACE difficult.
> For example - also mentioned by Daan - the need to approve targets is
> not needed our current use case, but we have to work around this.
> An other item is the four levels (artifacts, features, distributions
> targets) as I understand this is adaptable, but out of the box there
> are four.
I think we should rethink how ACE by default is going to handle new
targets. With your and Daan’s feedback I do see a real need for that.
> - Support docker
> Make it possible to "deploy" docker images using Apache ACE. Docker is
> becoming more popular by the day and in my opinion rightly so.
> Provisioning docker images in a more controlled manner is IMO still
> missing.
>
> Although using Apache ACE to runtime deploy sets of bundles can be
> very flexible and powerful in my experience sometimes a pre-created
> OSGi docker image is preferable.
> This minimizes the "entropy" of the system by introducing composed
> OSGi bundles used in a (more) deterministic manner. Although
> theoretically continuously deploying/undeploying bundles on a OSGi
> container should work, in practice this can lead to issues (note that
> should be considered bugs, but still). Also pre-created docker images
> can be tested as-is and therefore be qualified as whole.
>
> A combination would be interesting, so default bundles and the
> possibility to use Apache ACE to update default bundles / sprinkle on
> additional bundles.
>
> Provide A minimal OSGi client containing the ACE agent and make this
> images easy extendable by adding additional bundles / configuration
> files. (See INAETICS (github) for a minimal OSGi client example).
I see two ways ACE could support Docker: either by provisioning pre-built
Docker images (tarballs) or by provisioning the Dockerfile only and let
the agent on the target build the Docker image for you. Not sure yet
which one is “better”. At the moment, I’m prototyping and playing a bit
with a custom agent that could handle this, just to see how this might
work.
> Focus on making development of cluster / distributed systems more easy
> without restarting the cluster. So updated bundles / docker images and
> restarting ACE client should be possible and easy.
Do you mean that ACE is acting as a cluster manager, or just provides
the ability to provision multiple targets in a “transactional” manner
(all or nothing approach)?
> – Use the capability-requirement model resolving
>
> I would prefer using the capability requirement model to match what to
> deploy instead of coupling artifact2feature, etc. Although this could
> maybe be to complex, I think it's worth thinking about.
>
> Especially combining this with docker images (e.g. using docker labels
> to add Provide-Capability / Require-Capability ) could be a
> interesting feature. This could help in solving a problem where OSGi
> is very good at, running mircroservices with multiple versions of
> services. But in this case mircoservices means REST services provided
> by docker containers.
Interesting point. Need to ponder about this a little longer on how
this would work out.
> – Runtime configuration
> When using Apache ACE I often ran in the desire the edit/update the
> configuration file used. A more “inline” support to updating (e.g.
> enable debug printing) small configuration files would be nice.
Do you mean the configuration of ACE itself, or the configuration
that is provisioned to the targets?
> - Monitor targets
> Maybe out of scope for Apache ACE, but also something I noticed would
> be very welcome when using Apache ACE, is a more elaborate monitoring
> of the targets. Maybe even something like a heartbeat to ensure the
> target is alive.
The fact that a target periodically sends feedback would actually
provide this information already. But I think you mean that the UI
should actively report when it hasn’t seen/heard from a target in
a while?
> - No gosh
> I understand that gosh is very powerful, but I see it as yet another
> scripting language I prefer not to learn. I would prefer a more
> feature rich / responsive HTML UI and better supported REST api.
Fair point: gosh isn’t the most intuitive way of talking to ACE. We
need to come up with another way of doing that from a end-users
perspective (RESTish responsive UI) and from an automation point of
view (for automated deployments, CIs, etc).
--
Met vriendelijke groeten | Kind regards
Jan Willem Janssen | Software Architect
+31 631 765 814
My world is something with Amdatu and Apache
Luminis Technologies
Churchillplein 1
7314 BZ Apeldoorn
+31 88 586 46 00
https://www.luminis.eu
KvK (CoC) 09 16 28 93
BTW (VAT) NL8170.94.441.B.01
Re: [feedback] hurdles when working with ACE
Posted by Pepijn Noltes <pe...@gmail.com>.
Hi All,
First of all I agree with Daan issue. I have also several
improvement/issues myself.
A bit of background. My use case for Apache ACE is a distributed
polyglot (Apache Felix / Apache Celix) system where the goal is
dynamic (runtime) reconfiguration of the software.
One of the project we used Apache ACE in is INAETICS
(http://www.inaetics.org/). I worked in this project – among others –
together with Jan Willlem.
My issues/improvements:
- Simpler setup out of the box.
The server-allinone contains a lot of feature I personally do not
use/need. This makes jumping into Apache ACE difficult.
For example - also mentioned by Daan - the need to approve targets is
not needed our current use case, but we have to work around this.
An other item is the four levels (artifacts, features, distributions
targets) as I understand this is adaptable, but out of the box there
are four.
Maybe different server configuration for different use case can be created.
- Support docker
Make it possible to "deploy" docker images using Apache ACE. Docker is
becoming more popular by the day and in my opinion rightly so.
Provisioning docker images in a more controlled manner is IMO still
missing.
Although using Apache ACE to runtime deploy sets of bundles can be
very flexible and powerful in my experience sometimes a pre-created
OSGi docker image is preferable.
This minimizes the "entropy" of the system by introducing composed
OSGi bundles used in a (more) deterministic manner. Although
theoretically continuously deploying/undeploying bundles on a OSGi
container should work, in practice this can lead to issues (note that
should be considered bugs, but still). Also pre-created docker images
can be tested as-is and therefore be qualified as whole.
A combination would be interesting, so default bundles and the
possibility to use Apache ACE to update default bundles / sprinkle on
additional bundles.
Provide A minimal OSGi client containing the ACE agent and make this
images easy extendable by adding additional bundles / configuration
files. (See INAETICS (github) for a minimal OSGi client example).
Focus on making development of cluster / distributed systems more easy
without restarting the cluster. So updated bundles / docker images and
restarting ACE client should be possible and easy.
– Use the capability-requirement model resolving
I would prefer using the capability requirement model to match what to
deploy instead of coupling artifact2feature, etc. Although this could
maybe be to complex, I think it's worth thinking about.
Especially combining this with docker images (e.g. using docker labels
to add Provide-Capability / Require-Capability ) could be a
interesting feature. This could help in solving a problem where OSGi
is very good at, running mircroservices with multiple versions of
services. But in this case mircoservices means REST services provided
by docker containers.
– Runtime configuration
When using Apache ACE I often ran in the desire the edit/update the
configuration file used. A more “inline” support to updating (e.g.
enable debug printing) small configuration files would be nice.
- Monitor targets
Maybe out of scope for Apache ACE, but also something I noticed would
be very welcome when using Apache ACE, is a more elaborate monitoring
of the targets. Maybe even something like a heartbeat to ensure the
target is alive.
- No gosh
I understand that gosh is very powerful, but I see it as yet another
scripting language I prefer not to learn. I would prefer a more
feature rich / responsive HTML UI and better supported REST api.
Well these are just my 2 cents.
Greetings,
Pepijn
On Mon, Jan 25, 2016 at 4:04 PM, Daan Veldhof <da...@gmail.com> wrote:
> Hi Jan,
>
> I haven't worked with Ace for that long, but I hope I can add some
> feedback, especially from the Celix side.
>
> - The first challenge i've encountered was that I couldn't upload .zip
> files. I know there is a way to create your own resource processor, but it
> was easier for me to convert the .zip to .jar.
>
> - The second challenge was to create targets for celix. We've got celix
> working for Android devices, but they need different bundles because most
> Android devices contain an ARM processor. The solution for us was to create
> multiple targets with their cpu architecture in their id (i.e.
> celix_armeabi-v7a or celix_armeabi). I would like to see something were you
> could specify the id and in the tags you would specify the cpu
> architecture. So if you have a normal linux machine it would register
> itself to ace with {id:celix, cpu_arch: linux-x86} and a android device
> would register with {id:celix, cpu_arch:armeabi-v7a}
>
> - The third challenge was to use the REST api. There was some documentation
> but it wasn't enough. I looked like someone started with it, but didn't
> finish it. Eventually through the mailing-list I got it up and running.
>
> - The last thing i've encountered was that the automation bundle wasn't
> working properly. If a new target was added it wouldn't be registered and
> approved. You had to log in and retrieve and store a workspace before it
> would be registered and approved.
>
> Regards,
> Daan Veldhof
>
>
>
>
>
> 2016-01-22 15:48 GMT+01:00 Jan Willem Janssen <ja...@luminis.eu>
> :
>
>> 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).
>>
>> 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 :)
>>
>> Thanks in advance,
>>
>> (cross posting to the dev@ list as well).
>>
>> --
>> Met vriendelijke groeten | Kind regards
>>
>> Jan Willem Janssen | Software Architect
>> +31 631 765 814
>>
>>
>> My world is something with Amdatu and Apache
>>
>> Luminis Technologies
>> Churchillplein 1
>> 7314 BZ Apeldoorn
>> +31 88 586 46 00
>>
>> https://www.luminis.eu
>>
>> KvK (CoC) 09 16 28 93
>> BTW (VAT) NL8170.94.441.B.01
>>
>>
Re: [feedback] hurdles when working with ACE
Posted by Daan Veldhof <da...@gmail.com>.
Hi Jan,
I haven't worked with Ace for that long, but I hope I can add some
feedback, especially from the Celix side.
- The first challenge i've encountered was that I couldn't upload .zip
files. I know there is a way to create your own resource processor, but it
was easier for me to convert the .zip to .jar.
- The second challenge was to create targets for celix. We've got celix
working for Android devices, but they need different bundles because most
Android devices contain an ARM processor. The solution for us was to create
multiple targets with their cpu architecture in their id (i.e.
celix_armeabi-v7a or celix_armeabi). I would like to see something were you
could specify the id and in the tags you would specify the cpu
architecture. So if you have a normal linux machine it would register
itself to ace with {id:celix, cpu_arch: linux-x86} and a android device
would register with {id:celix, cpu_arch:armeabi-v7a}
- The third challenge was to use the REST api. There was some documentation
but it wasn't enough. I looked like someone started with it, but didn't
finish it. Eventually through the mailing-list I got it up and running.
- The last thing i've encountered was that the automation bundle wasn't
working properly. If a new target was added it wouldn't be registered and
approved. You had to log in and retrieve and store a workspace before it
would be registered and approved.
Regards,
Daan Veldhof
2016-01-22 15:48 GMT+01:00 Jan Willem Janssen <ja...@luminis.eu>
:
> 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).
>
> 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 :)
>
> Thanks in advance,
>
> (cross posting to the dev@ list as well).
>
> --
> Met vriendelijke groeten | Kind regards
>
> Jan Willem Janssen | Software Architect
> +31 631 765 814
>
>
> My world is something with Amdatu and Apache
>
> Luminis Technologies
> Churchillplein 1
> 7314 BZ Apeldoorn
> +31 88 586 46 00
>
> https://www.luminis.eu
>
> KvK (CoC) 09 16 28 93
> BTW (VAT) NL8170.94.441.B.01
>
>
Re: [feedback] hurdles when working with ACE
Posted by Jan Willem Janssen <ja...@luminis.eu>.
Hi Frank,
Thanks for your feedback!
> On 22 Jan 2016, at 15:55, Frank Langel <fr...@frankjlangel.com> wrote:
>
> Thanks a lot. I see a lot of value in a solution such as Ace,
> But it needs to be maintained and there needs to be sufficient demand.
>
> Here a few issues we faced and that created the following requirement
> - Integration with persistence backend —> GIT/SQL db, so all ACE artifcats/settings/data is properly stored
Could you elaborate a bit more on this? Do you mean that everything should be stored in a persistent backend, or that it is easier to use alternative backends for different parts (e.g. Artifactory instead of the default OBR, Derby for the metadata of ACE, etc.)?
> - better documentation
Yes, this is something we definitely should improve on.
> - integration with BndTools
> - best practices for entire SDLC
Good points.
--
Met vriendelijke groeten | Kind regards
Jan Willem Janssen | Software Architect
+31 631 765 814
My world is something with Amdatu and Apache
Luminis Technologies
Churchillplein 1
7314 BZ Apeldoorn
+31 88 586 46 00
https://www.luminis.eu
KvK (CoC) 09 16 28 93
BTW (VAT) NL8170.94.441.B.01
Re: [feedback] hurdles when working with ACE
Posted by Frank Langel <fr...@frankjlangel.com>.
Hi Jan,
Thanks a lot. I see a lot of value in a solution such as Ace,
But it needs to be maintained and there needs to be sufficient demand.
Here a few issues we faced and that created the following requirement
- Integration with persistence backend —> GIT/SQL db, so all ACE artifcats/settings/data is properly stored
- better documentation
- integration with BndTools
- best practices for entire SDLC
Best
Frank
On 1/22/16, 3:48 PM, "Jan Willem Janssen" <ja...@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).
>
>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 :)
>
>Thanks in advance,
>
>(cross posting to the dev@ list as well).
>
>--
>Met vriendelijke groeten | Kind regards
>
>Jan Willem Janssen | Software Architect
>+31 631 765 814
>
>
>My world is something with Amdatu and Apache
>
>Luminis Technologies
>Churchillplein 1
>7314 BZ Apeldoorn
>+31 88 586 46 00
>
>https://www.luminis.eu
>
>KvK (CoC) 09 16 28 93
>BTW (VAT) NL8170.94.441.B.01
>
Re: [feedback] hurdles when working with ACE
Posted by Bram de Kruijff <bd...@gmail.com>.
On Wed, Jan 27, 2016 at 5:46 PM, Jan Willem Janssen
<ja...@luminis.eu> wrote:
> Hi Bram,
>
>> On 26 Jan 2016, at 10:03, Bram de Kruijff <bd...@gmail.com> wrote:
>>
>>
>> 1) OSGi Repository support
>> […]
>
> Completely agree on this.
>
>>
>> 2) Improved/pluggable storage.
>> […]
>
> Completely agree on this.
>
>>
>> 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.
>
> I agree that the current UI is a bit outdated and I like the idea of a
> task oriented UI. It might nicely align with our ideas of redesigning
> the client (read: the four column-based model).
>
>> 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?
>
> Fair point; aside the usual suspects of metatype configuration and binary
> blobs (ZIP files), what other artifacts do you see?
>
Good question :) I guess I should break down my thoughts...
1) It should all work out of the box. Not having to add the rps by
hand/script and having no reasonable way to determine whether that has
been done. I would hope that the aforementioned repository support
would allow us to simply query for bundles with the proper capability
without user interaction.
2) Another concrete resource type that comes to mind is configuration
properties files. Nobody likes meta-type I think that in most cases it
just makes adoption more complex.
3) Other concrete resource types would probably be rather
solution/framework specific, but what they typically have in common is
the need to transfer resources to the target. At present this requires
implementation of a custom recognizer, helper, processor... could we
provide a generic "resource artifact type" to simply that?
grz
Bram
> --
> Met vriendelijke groeten | Kind regards
>
> Jan Willem Janssen | Software Architect
> +31 631 765 814
>
>
> My world is something with Amdatu and Apache
>
> Luminis Technologies
> Churchillplein 1
> 7314 BZ Apeldoorn
> +31 88 586 46 00
>
> https://www.luminis.eu
>
> KvK (CoC) 09 16 28 93
> BTW (VAT) NL8170.94.441.B.01
>
Re: [feedback] hurdles when working with ACE
Posted by Bram de Kruijff <bd...@gmail.com>.
On Wed, Jan 27, 2016 at 5:46 PM, Jan Willem Janssen
<ja...@luminis.eu> wrote:
> Hi Bram,
>
>> On 26 Jan 2016, at 10:03, Bram de Kruijff <bd...@gmail.com> wrote:
>>
>>
>> 1) OSGi Repository support
>> […]
>
> Completely agree on this.
>
>>
>> 2) Improved/pluggable storage.
>> […]
>
> Completely agree on this.
>
>>
>> 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.
>
> I agree that the current UI is a bit outdated and I like the idea of a
> task oriented UI. It might nicely align with our ideas of redesigning
> the client (read: the four column-based model).
>
>> 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?
>
> Fair point; aside the usual suspects of metatype configuration and binary
> blobs (ZIP files), what other artifacts do you see?
>
Good question :) I guess I should break down my thoughts...
1) It should all work out of the box. Not having to add the rps by
hand/script and having no reasonable way to determine whether that has
been done. I would hope that the aforementioned repository support
would allow us to simply query for bundles with the proper capability
without user interaction.
2) Another concrete resource type that comes to mind is configuration
properties files. Nobody likes meta-type I think that in most cases it
just makes adoption more complex.
3) Other concrete resource types would probably be rather
solution/framework specific, but what they typically have in common is
the need to transfer resources to the target. At present this requires
implementation of a custom recognizer, helper, processor... could we
provide a generic "resource artifact type" to simply that?
grz
Bram
> --
> Met vriendelijke groeten | Kind regards
>
> Jan Willem Janssen | Software Architect
> +31 631 765 814
>
>
> My world is something with Amdatu and Apache
>
> Luminis Technologies
> Churchillplein 1
> 7314 BZ Apeldoorn
> +31 88 586 46 00
>
> https://www.luminis.eu
>
> KvK (CoC) 09 16 28 93
> BTW (VAT) NL8170.94.441.B.01
>
Re: [feedback] hurdles when working with ACE
Posted by Jan Willem Janssen <ja...@luminis.eu>.
Hi Bram,
> On 26 Jan 2016, at 10:03, Bram de Kruijff <bd...@gmail.com> wrote:
>
>
> 1) OSGi Repository support
> […]
Completely agree on this.
>
> 2) Improved/pluggable storage.
> […]
Completely agree on this.
>
> 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.
I agree that the current UI is a bit outdated and I like the idea of a
task oriented UI. It might nicely align with our ideas of redesigning
the client (read: the four column-based model).
> 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?
Fair point; aside the usual suspects of metatype configuration and binary
blobs (ZIP files), what other artifacts do you see?
--
Met vriendelijke groeten | Kind regards
Jan Willem Janssen | Software Architect
+31 631 765 814
My world is something with Amdatu and Apache
Luminis Technologies
Churchillplein 1
7314 BZ Apeldoorn
+31 88 586 46 00
https://www.luminis.eu
KvK (CoC) 09 16 28 93
BTW (VAT) NL8170.94.441.B.01
Re: [feedback] hurdles when working with ACE
Posted by Bram de Kruijff <bd...@gmail.com>.
Hey Jan Willem,
On Fri, Jan 22, 2016 at 3:48 PM, Jan Willem Janssen
<ja...@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
Re: [feedback] hurdles when working with ACE
Posted by Bram de Kruijff <bd...@gmail.com>.
Hey Jan Willem,
On Fri, Jan 22, 2016 at 3:48 PM, Jan Willem Janssen
<ja...@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