Various newbie observations

[Jeremias Maerki <de...@jeremias-maerki.ch>]

Hi Aces :-)

I'm looking into adopting parts of Apache ACE as the deployment tool for
an appliciation I'm writing. It's my second attempt with ACE now, after
my first that wasn't so successful. I'm starting to find my way around
the project by studying lots of source code and starting to add MetaType
information to make it easier to play with configuration settings.

Some background on what I'm trying to do if you're interested: I've
written a partial implementation of the OSGi Initial Provisioning server
[1]. Then I wrote a generic bootstrap agent that starts the actual
management agent (most probably a customized ACE if I can get it to do
what I need). I'm not using the launcher but a stripped down, minimal
Apache Karaf because it's easy to deploy that as a service and to
(low-level) configure. That looks like a promising approach to me so far.

So while digging around the project I noticed a few things:
- first of all, a nicely divided and designed set of bundles that
promises high flexibility and extensibility. Nice!
- the source code is an ugly mix of spaces and tabs for indentation.
Please talk among yourselves towards one or the other (I prefer spaces).
A very minimal Checkstyle configuration file might be helpful, too.
- A lot of svn:ignores are missing (see attached patch)
- as long as the documentation is a little spotty (which is ok at this
stage), please think about filling out the <description> tag in the POMs
for each bundle so it's easier to get at least an idea what some bundle
does. A little README would even be better. I think that would spare a
lot of would-be adopters a lot of time finding their way around the
project. I've had to regularly wander around the source code to figure
out what a bundle is supposed to do.

I'll send a patch for the MetaType stuff when I've done a few more of
those.

[1] http://markmail.org/thread/3xvjxh5f7sfystfr

Thanks,
Jeremias Maerki

Re: Various newbie observations

[Jean-Baptiste Onofré <jb...@nanthrax.net>]

I second Marcel,

all comments are welcome and interesting !!

Thanks
JB

On 09/30/2011 09:02 PM, Marcel Offermans wrote:
> Hello Jeremias,
>
> On Sep 30, 2011, at 10:29 AM, Jeremias Maerki wrote:
>
>> I'm looking into adopting parts of Apache ACE as the deployment tool for
>> an appliciation I'm writing. It's my second attempt with ACE now, after
>> my first that wasn't so successful. I'm starting to find my way around
>> the project by studying lots of source code and starting to add MetaType
>> information to make it easier to play with configuration settings.
>
> Cool, thanks!
>
>> Some background on what I'm trying to do if you're interested: I've
>> written a partial implementation of the OSGi Initial Provisioning server
>> [1]. Then I wrote a generic bootstrap agent that starts the actual
>> management agent (most probably a customized ACE if I can get it to do
>> what I need).
>
> Feel free to explain exactly what you need.
>
>> I'm not using the launcher but a stripped down, minimal
>> Apache Karaf because it's easy to deploy that as a service and to
>> (low-level) configure. That looks like a promising approach to me so far.
>
> The launchers we provide are examples, I'm sure as a community we can come up with many more!
>
>> So while digging around the project I noticed a few things:
>> - first of all, a nicely divided and designed set of bundles that
>> promises high flexibility and extensibility. Nice!
>
> Thanks!
>
>> - the source code is an ugly mix of spaces and tabs for indentation.
>> Please talk among yourselves towards one or the other (I prefer spaces).
>> A very minimal Checkstyle configuration file might be helpful, too.
>
> We have a style guide, but we lack a checkstyle and/or Eclipse formatters right now. Check out this page and let me know what you think:
> http://incubator.apache.org/ace/java-coding-style-guide.html
>
> I'll try to at least come up with a formatter for Eclipse (which is my weapon of choice).
>
>> - A lot of svn:ignores are missing (see attached patch)
>
> Thanks!
>
>> - as long as the documentation is a little spotty (which is ok at this
>> stage), please think about filling out the<description>  tag in the POMs
>> for each bundle so it's easier to get at least an idea what some bundle
>> does. A little README would even be better. I think that would spare a
>> lot of would-be adopters a lot of time finding their way around the
>> project. I've had to regularly wander around the source code to figure
>> out what a bundle is supposed to do.
>
> Excellent idea. I'll spend some time to do that. I can see how that helps.
>
>> I'll send a patch for the MetaType stuff when I've done a few more of
>> those.
>
> Great, I saw the patch, thanks a lot! Having the metatype stuff in place helps a lot, since there are more and more tools nowadays that can use this information.
>
> Greetings, Marcel
>
>

-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: Various newbie observations

[Jeremias Maerki <de...@jeremias-maerki.ch>]

Hi Marcel

On 05.10.2011 09:00:50 Marcel Offermans wrote:
<snip/>
> > I have to say that I don't like the Karaf features as they download many
> > artifacts from possibly different locations. Admins usually want to be
> > in control of what is installed on their systems. Therefore, the fewer
> > artifacts, the better. And I think that Karaf features have a similar
> > problem to the Maven approach of dependency resolution: it's much more
> > difficult to have the overview over all dependencies. Even though it's
> > more work, I like to have full control over which bundles are approved
> > to be used in a system. Downloading the whole internet during deployment
> > only to fail in the last 5% because some artifact is currently
> > unreachable... And if an environment doesn't have access to the internet,
> > you have to make your artifacts locally available anyway.
> 
> What we could do is provide an "import" mechanism that allows us to
> import karaf features into the ACE client, download all dependencies
> and stick them in the ACE OBR, creating a set of artifacts and an associated
> ACE feature for them.

That sounds useful.

> > The ACE GUI is very nice for some first experimentation and demo-ing but
> > IMO becomes more unattractive the further you go towards production
> > deployment.
> 
> Agreed, it needs work if you want to use it for that, adding things
> like proper RBAC, more filtering and sorting options to keep an overview even
> when you have long lists of artifacts, better overview of the history
> and better feedback from targets, etc..
> 
> > But still, I think other ACE components have a high chance
> > of being the right building blocks that I need for my
> > requirements/wishes. I simply have to learn a little more about ACE
> > (especially its client APIs) to find out where they fit in. The client
> > APIs are probably the key to the instant debugging-time deployment.
> 
> Yes, and we have basically two "flavors" of the client side API. One, I
> think you've already looked into by now, consists of a set of OSGi
> services. The other, more recently added, is a REST based client (which
> actually builds on the first).
> 
> Directly hooking up that client to your build process (script or IDE
> based) is indeed the quickest way to instantly deploy things. As a side
> note, if you want to, the client bundles can be run on a different
> machine than the ACE server itself. Right now they are deployed in the
> server because that's the most convenient for a web application but
> before we donated the codebase to Apache we used to have a Swing based
> client that contained those client bundles. That means you're in no way
> required to run the ACE server on your own machine (even though keeping
> everything on your local machine for development might be the easiest
> and quickest way of doing things).

Very good point! Hooking the REST service into the build process should
be more than enough (and much quicker to implement). Uploading a
configuration or another artifact should be easy, too. It's just that
the REST service is a little light on documentation. ;-) I guess I can
try to write that documentation by studying the code.

> > For the production deployment I'm probably looking more at a
> > descriptor-based approach for off-line deployment package assembly
> > (probably Ant-based). The longer I look at ACE, the more I think that
> > some components could really help me but I might not be using it quite
> > along the lines that you guys were initially designing it. But I could
> > be wrong.
> 
> The politically correct answer here probably is that we designed the
> system to be flexible. ;)

Which it really appears to be.

> We did envision different ways in which a deployment package could "end
> up" on a target. The default way is to have the target simply fetch it
> (with an HTTP call) but you can also point the target at a local folder
> and have it install deployment packages from there (creating something
> similar to file install, but with a granularity of a deployment package
> instead of individual bundles and configuration files).
> 
> There is a bit of an ongoing discussion on installing more than one
> deployment package (dp for now) onto a single target. I recently added
> some features for that. However, if you go that way, there are some
> restrictions. First of all, a single bundle can only belong to one dp at
> a time. Second of all, we can no longer validate on the server if what
> you send to a target will work, resolver wise (which we can, and are in
> the process of adding, for a single dp).

Interesting. When I have some experience with the development-time
deployments I guess I'll know if that would improve things.

> > I hope I was able to explain well enough what I'm trying to do.
> 
> I think so. :)
> 
> >>> I'm not using the launcher but a stripped down, minimal
> >>> Apache Karaf because it's easy to deploy that as a service and to
> >>> (low-level) configure. That looks like a promising approach to me so far.
> >> 
> >> The launchers we provide are examples, I'm sure as a community we can come up with many more!
> > 
> > I guess I can easily write a little essay about the Mini-Karaf approach
> > I'm currently following, when I've gathered some experience with it. I'm
> > also happy to make my Initial Provisioning and the generic mgmt agent
> > available under the ALv2 if anyone thinks that they are useful.
> 
> I think the initial provisioning solution would be a great match for
> the Felix project, because it implements an OSGi specification. For that
> same reason we donated the deployment admin implementation to Felix
> instead of maintaining it in ACE.

Yeah, but so far there was no overwhelming interest in it over @Felix.

> I would love to take a look at the mgmt agent you came up with once you feel it's working the way you want!

Well, it mostly works already. The only thing really missing is adding
the ability to install configurations to the bootstrap agent. Then I can
activate the property-based discovery service. At the moment I have to
quickly set the configuration via the WebConsole (installed test-wise
with the deployment ZIP) and half a second later, the distribution has
been installed by ACE.

The alternative would be to use a deployment package for the actual
management agent. AutoConf would then help with the discovery
configuration. With the Ant task to create DP's that I was surprised to
discover in ACE, that shouldn's be all that hard. But I'm not sure if it
supports AutoConf. Creating a simple ZIP (with no need for special
ordering and manifests like in DPs) is still easier for experiments.
Maybe I'll add support for both in the bootstrap agent.

Initial Provisioning:
http://jeremias-maerki.ch/download/osgi/ch.jm.osgi.provisioning-0.9.0.dev-sources.jar
Generic bootstrap agent:
http://jeremias-maerki.ch/download/osgi/ch.jm.osgi.management.agent.bootstrap-0.9.0.dev-sources.jar
ACE identification service that takes its ID from the
ProvisioningService's SPID:
http://jeremias-maerki.ch/download/osgi/ch.jm.osgi.management.ace.identification.ip-0.9.0.dev-sources.jar

(sorry, just source JARs at the moment. My build system currently doesn't
make it easy to put a single module in a self-contained package. I will
look into that when the whole thing is more mature so I dare to make a
release.)

<snip/>

> I'll keep up the good work. Documentation is definitely still lacking, so keep asking questions if something's not clear.

Thanks a lot for your help!

> >>> I'll send a patch for the MetaType stuff when I've done a few more of
> >>> those.
> >> 
> >> Great, I saw the patch, thanks a lot! Having the metatype stuff in
> >> place helps a lot, since there are more and more tools nowadays that can use
> >> this information.
> > 
> > Yep. I've been using Felix WebConsole which Metatype turns into a great
> > environment to configure an OSGi application while experimenting with it.
> 
> Exactly! Web console is a great showcase for now metatype works (and many other things ;)
> 
> We've been using the metatype based AutoConfig artifacts a lot to
> provision configuration to a system. In fact, for similar targets we
> even added a way to create a template that gets filled out with
> key/value pairs that can be added to for example individual targets.

Now that is VERY interesting! I know that's going to become an issue for
me.


Jeremias Maerki

Re: Various newbie observations

[Marcel Offermans <ma...@luminis.nl>]

Hello Jeremias,

On Oct 3, 2011, at 9:27 AM, Jeremias Maerki wrote:

> Hi Marcel
> 
> On 30.09.2011 21:02:54 Marcel Offermans wrote:
>> Hello Jeremias,
>> 
>> On Sep 30, 2011, at 10:29 AM, Jeremias Maerki wrote:
>> 
>>> I'm looking into adopting parts of Apache ACE as the deployment tool for
>>> an appliciation I'm writing. It's my second attempt with ACE now, after
>>> my first that wasn't so successful. I'm starting to find my way around
>>> the project by studying lots of source code and starting to add MetaType
>>> information to make it easier to play with configuration settings.
>> 
>> Cool, thanks!
>> 
>>> Some background on what I'm trying to do if you're interested: I've
>>> written a partial implementation of the OSGi Initial Provisioning server
>>> [1]. Then I wrote a generic bootstrap agent that starts the actual
>>> management agent (most probably a customized ACE if I can get it to do
>>> what I need).
>> 
>> Feel free to explain exactly what you need.
> 
> So far, I've been working with FileInstall to deploy modified bundles
> on-the-fly during development. That gives me very quick turn-arounds
> when debugging. Now, I'm at a point where I need to transform my
> single-instance system into a fully clustered one. During the
> development I'd like to keep the ability for a high
> debugging-productivity so I'd like to have a changed bundle distributed
> to all instances in the cluster immediately after it's built. My
> Ant-based build system currently copies every bundle directly into a
> FileInstall-observed directory.

Sound familiar. That's what I did a lot of the time as well. Nowadays, I tend to use BndTools a lot which builds and deploys my bundles on the fly as well, but only to one single, local target. The need to have a quick cycle here is something I think we all agree on.

> OTOH, approaching the point where my system needs to be packaged into an
> actual product, I need a versionable way of deploying the application.
> The application should be packaged into as few files as possible (think
> deployment packages, which I find a great concept). The configuration
> should be versionable, too, but probably deployed seperately to the
> actual bundles because they have different deployment schedules. I think
> the Features/Distribution grouping of ACE should accomodate this just
> fine.

Agreed, deployment packages are a very nice way of installing and updating, not only because they allow you to package everything in one file but also because of the transactional properties and their extendability through resource processors.

> I have to say that I don't like the Karaf features as they download many
> artifacts from possibly different locations. Admins usually want to be
> in control of what is installed on their systems. Therefore, the fewer
> artifacts, the better. And I think that Karaf features have a similar
> problem to the Maven approach of dependency resolution: it's much more
> difficult to have the overview over all dependencies. Even though it's
> more work, I like to have full control over which bundles are approved
> to be used in a system. Downloading the whole internet during deployment
> only to fail in the last 5% because some artifact is currently
> unreachable... And if an environment doesn't have access to the internet,
> you have to make your artifacts locally available anyway.

What we could do is provide an "import" mechanism that allows us to import karaf features into the ACE client, download all dependencies and stick them in the ACE OBR, creating a set of artifacts and an associated ACE feature for them.

> The ACE GUI is very nice for some first experimentation and demo-ing but
> IMO becomes more unattractive the further you go towards production
> deployment.

Agreed, it needs work if you want to use it for that, adding things like proper RBAC, more filtering and sorting options to keep an overview even when you have long lists of artifacts, better overview of the history and better feedback from targets, etc..

> But still, I think other ACE components have a high chance
> of being the right building blocks that I need for my
> requirements/wishes. I simply have to learn a little more about ACE
> (especially its client APIs) to find out where they fit in. The client
> APIs are probably the key to the instant debugging-time deployment.

Yes, and we have basically two "flavors" of the client side API. One, I think you've already looked into by now, consists of a set of OSGi services. The other, more recently added, is a REST based client (which actually builds on the first).

Directly hooking up that client to your build process (script or IDE based) is indeed the quickest way to instantly deploy things. As a side note, if you want to, the client bundles can be run on a different machine than the ACE server itself. Right now they are deployed in the server because that's the most convenient for a web application but before we donated the codebase to Apache we used to have a Swing based client that contained those client bundles. That means you're in no way required to run the ACE server on your own machine (even though keeping everything on your local machine for development might be the easiest and quickest way of doing things).

> For the production deployment I'm probably looking more at a
> descriptor-based approach for off-line deployment package assembly
> (probably Ant-based). The longer I look at ACE, the more I think that
> some components could really help me but I might not be using it quite
> along the lines that you guys were initially designing it. But I could
> be wrong.

The politically correct answer here probably is that we designed the system to be flexible. ;)

We did envision different ways in which a deployment package could "end up" on a target. The default way is to have the target simply fetch it (with an HTTP call) but you can also point the target at a local folder and have it install deployment packages from there (creating something similar to file install, but with a granularity of a deployment package instead of individual bundles and configuration files).

There is a bit of an ongoing discussion on installing more than one deployment package (dp for now) onto a single target. I recently added some features for that. However, if you go that way, there are some restrictions. First of all, a single bundle can only belong to one dp at a time. Second of all, we can no longer validate on the server if what you send to a target will work, resolver wise (which we can, and are in the process of adding, for a single dp).

> I hope I was able to explain well enough what I'm trying to do.

I think so. :)

>>> I'm not using the launcher but a stripped down, minimal
>>> Apache Karaf because it's easy to deploy that as a service and to
>>> (low-level) configure. That looks like a promising approach to me so far.
>> 
>> The launchers we provide are examples, I'm sure as a community we can come up with many more!
> 
> I guess I can easily write a little essay about the Mini-Karaf approach
> I'm currently following, when I've gathered some experience with it. I'm
> also happy to make my Initial Provisioning and the generic mgmt agent
> available under the ALv2 if anyone thinks that they are useful.

I think the initial provisioning solution would be a great match for the Felix project, because it implements an OSGi specification. For that same reason we donated the deployment admin implementation to Felix instead of maintaining it in ACE.

I would love to take a look at the mgmt agent you came up with once you feel it's working the way you want!

>>> So while digging around the project I noticed a few things:
>>> - first of all, a nicely divided and designed set of bundles that
>>> promises high flexibility and extensibility. Nice!
>> 
>> Thanks!
>> 
>>> - the source code is an ugly mix of spaces and tabs for indentation.
>>> Please talk among yourselves towards one or the other (I prefer spaces).
>>> A very minimal Checkstyle configuration file might be helpful, too.
>> 
>> We have a style guide, but we lack a checkstyle and/or Eclipse formatters right now. Check out this page and let me know what you think:
>> http://incubator.apache.org/ace/java-coding-style-guide.html
> 
> Took me a while to find the link to that page on the website. I'm not
> sure that placing/hiding that under "Building Apache ACE" is the best
> idea. Anyway, I'm happy to see that the ground rules are already
> established. Time to enforce them. :-)

:)

>> I'll try to at least come up with a formatter for Eclipse (which is my weapon of choice).
> 
> Mine, too. :-) Formatter settings, Checkstyle rules. Reduced to the
> minimum to enforce some ground rules but to still allow for some
> flexibility. We've made the mistake in Apache FOP to have too many rules
> which leaves much too many warnings to ever be cleaned up. Well, that
> project is 12 years old so is bound to have some "diversity" piled up.
> :-)
> 
> If you want I'll look into a Checkstyle file based on your style guide.

That would be great!

>>> - A lot of svn:ignores are missing (see attached patch)
>> 
>> Thanks!
>> 
>>> - as long as the documentation is a little spotty (which is ok at this
>>> stage), please think about filling out the <description> tag in the POMs
>>> for each bundle so it's easier to get at least an idea what some bundle
>>> does. A little README would even be better. I think that would spare a
>>> lot of would-be adopters a lot of time finding their way around the
>>> project. I've had to regularly wander around the source code to figure
>>> out what a bundle is supposed to do.
>> 
>> Excellent idea. I'll spend some time to do that. I can see how that helps.
> 
> Great! Thanks! The ones you put in so far are already VERY helpful! The
> client APIs are probably where I head next.

I'll keep up the good work. Documentation is definitely still lacking, so keep asking questions if something's not clear.

>>> I'll send a patch for the MetaType stuff when I've done a few more of
>>> those.
>> 
>> Great, I saw the patch, thanks a lot! Having the metatype stuff in
>> place helps a lot, since there are more and more tools nowadays that can use
>> this information.
> 
> Yep. I've been using Felix WebConsole which Metatype turns into a great
> environment to configure an OSGi application while experimenting with it.

Exactly! Web console is a great showcase for now metatype works (and many other things ;)

We've been using the metatype based AutoConfig artifacts a lot to provision configuration to a system. In fact, for similar targets we even added a way to create a template that gets filled out with key/value pairs that can be added to for example individual targets.

Greetings, Marcel

Re: Various newbie observations

[Jeremias Maerki <de...@jeremias-maerki.ch>]

Hi Marcel

On 30.09.2011 21:02:54 Marcel Offermans wrote:
> Hello Jeremias,
> 
> On Sep 30, 2011, at 10:29 AM, Jeremias Maerki wrote:
> 
> > I'm looking into adopting parts of Apache ACE as the deployment tool for
> > an appliciation I'm writing. It's my second attempt with ACE now, after
> > my first that wasn't so successful. I'm starting to find my way around
> > the project by studying lots of source code and starting to add MetaType
> > information to make it easier to play with configuration settings.
> 
> Cool, thanks!
> 
> > Some background on what I'm trying to do if you're interested: I've
> > written a partial implementation of the OSGi Initial Provisioning server
> > [1]. Then I wrote a generic bootstrap agent that starts the actual
> > management agent (most probably a customized ACE if I can get it to do
> > what I need).
> 
> Feel free to explain exactly what you need.

So far, I've been working with FileInstall to deploy modified bundles
on-the-fly during development. That gives me very quick turn-arounds
when debugging. Now, I'm at a point where I need to transform my
single-instance system into a fully clustered one. During the
development I'd like to keep the ability for a high
debugging-productivity so I'd like to have a changed bundle distributed
to all instances in the cluster immediately after it's built. My
Ant-based build system currently copies every bundle directly into a
FileInstall-observed directory.

OTOH, approaching the point where my system needs to be packaged into an
actual product, I need a versionable way of deploying the application.
The application should be packaged into as few files as possible (think
deployment packages, which I find a great concept). The configuration
should be versionable, too, but probably deployed seperately to the
actual bundles because they have different deployment schedules. I think
the Features/Distribution grouping of ACE should accomodate this just
fine.

I have to say that I don't like the Karaf features as they download many
artifacts from possibly different locations. Admins usually want to be
in control of what is installed on their systems. Therefore, the fewer
artifacts, the better. And I think that Karaf features have a similar
problem to the Maven approach of dependency resolution: it's much more
difficult to have the overview over all dependencies. Even though it's
more work, I like to have full control over which bundles are approved
to be used in a system. Downloading the whole internet during deployment
only to fail in the last 5% because some artifact is currently
unreachable... And if an environment doesn't have access to the internet,
you have to make your artifacts locally available anyway.

The ACE GUI is very nice for some first experimentation and demo-ing but
IMO becomes more unattractive the further you go towards production
deployment. But still, I think other ACE components have a high chance
of being the right building blocks that I need for my
requirements/wishes. I simply have to learn a little more about ACE
(especially its client APIs) to find out where they fit in. The client
APIs are probably the key to the instant debugging-time deployment. For
the production deployment I'm probably looking more at a
descriptor-based approach for off-line deployment package assembly
(probably Ant-based). The longer I look at ACE, the more I think that
some components could really help me but I might not be using it quite
along the lines that you guys were initially designing it. But I could
be wrong.

I hope I was able to explain well enough what I'm trying to do.

> > I'm not using the launcher but a stripped down, minimal
> > Apache Karaf because it's easy to deploy that as a service and to
> > (low-level) configure. That looks like a promising approach to me so far.
> 
> The launchers we provide are examples, I'm sure as a community we can come up with many more!

I guess I can easily write a little essay about the Mini-Karaf approach
I'm currently following, when I've gathered some experience with it. I'm
also happy to make my Initial Provisioning and the generic mgmt agent
available under the ALv2 if anyone thinks that they are useful.

> > So while digging around the project I noticed a few things:
> > - first of all, a nicely divided and designed set of bundles that
> > promises high flexibility and extensibility. Nice!
> 
> Thanks!
> 
> > - the source code is an ugly mix of spaces and tabs for indentation.
> > Please talk among yourselves towards one or the other (I prefer spaces).
> > A very minimal Checkstyle configuration file might be helpful, too.
> 
> We have a style guide, but we lack a checkstyle and/or Eclipse formatters right now. Check out this page and let me know what you think:
> http://incubator.apache.org/ace/java-coding-style-guide.html

Took me a while to find the link to that page on the website. I'm not
sure that placing/hiding that under "Building Apache ACE" is the best
idea. Anyway, I'm happy to see that the ground rules are already
established. Time to enforce them. :-)

> I'll try to at least come up with a formatter for Eclipse (which is my weapon of choice).

Mine, too. :-) Formatter settings, Checkstyle rules. Reduced to the
minimum to enforce some ground rules but to still allow for some
flexibility. We've made the mistake in Apache FOP to have too many rules
which leaves much too many warnings to ever be cleaned up. Well, that
project is 12 years old so is bound to have some "diversity" piled up.
:-)

If you want I'll look into a Checkstyle file based on your style guide.

> > - A lot of svn:ignores are missing (see attached patch)
> 
> Thanks!
> 
> > - as long as the documentation is a little spotty (which is ok at this
> > stage), please think about filling out the <description> tag in the POMs
> > for each bundle so it's easier to get at least an idea what some bundle
> > does. A little README would even be better. I think that would spare a
> > lot of would-be adopters a lot of time finding their way around the
> > project. I've had to regularly wander around the source code to figure
> > out what a bundle is supposed to do.
> 
> Excellent idea. I'll spend some time to do that. I can see how that helps.

Great! Thanks! The ones you put in so far are already VERY helpful! The
client APIs are probably where I head next.

> > I'll send a patch for the MetaType stuff when I've done a few more of
> > those.
> 
> Great, I saw the patch, thanks a lot! Having the metatype stuff in
> place helps a lot, since there are more and more tools nowadays that can use
> this information.

Yep. I've been using Felix WebConsole which Metatype turns into a great
environment to configure an OSGi application while experimenting with it.


Thanks,
Jeremias Maerki

Re: Various newbie observations

[Marcel Offermans <ma...@luminis.nl>]

Hello Jeremias,

On Sep 30, 2011, at 10:29 AM, Jeremias Maerki wrote:

> I'm looking into adopting parts of Apache ACE as the deployment tool for
> an appliciation I'm writing. It's my second attempt with ACE now, after
> my first that wasn't so successful. I'm starting to find my way around
> the project by studying lots of source code and starting to add MetaType
> information to make it easier to play with configuration settings.

Cool, thanks!

> Some background on what I'm trying to do if you're interested: I've
> written a partial implementation of the OSGi Initial Provisioning server
> [1]. Then I wrote a generic bootstrap agent that starts the actual
> management agent (most probably a customized ACE if I can get it to do
> what I need).

Feel free to explain exactly what you need.

> I'm not using the launcher but a stripped down, minimal
> Apache Karaf because it's easy to deploy that as a service and to
> (low-level) configure. That looks like a promising approach to me so far.

The launchers we provide are examples, I'm sure as a community we can come up with many more!

> So while digging around the project I noticed a few things:
> - first of all, a nicely divided and designed set of bundles that
> promises high flexibility and extensibility. Nice!

Thanks!

> - the source code is an ugly mix of spaces and tabs for indentation.
> Please talk among yourselves towards one or the other (I prefer spaces).
> A very minimal Checkstyle configuration file might be helpful, too.

We have a style guide, but we lack a checkstyle and/or Eclipse formatters right now. Check out this page and let me know what you think:
http://incubator.apache.org/ace/java-coding-style-guide.html

I'll try to at least come up with a formatter for Eclipse (which is my weapon of choice).

> - A lot of svn:ignores are missing (see attached patch)

Thanks!

> - as long as the documentation is a little spotty (which is ok at this
> stage), please think about filling out the <description> tag in the POMs
> for each bundle so it's easier to get at least an idea what some bundle
> does. A little README would even be better. I think that would spare a
> lot of would-be adopters a lot of time finding their way around the
> project. I've had to regularly wander around the source code to figure
> out what a bundle is supposed to do.

Excellent idea. I'll spend some time to do that. I can see how that helps.

> I'll send a patch for the MetaType stuff when I've done a few more of
> those.

Great, I saw the patch, thanks a lot! Having the metatype stuff in place helps a lot, since there are more and more tools nowadays that can use this information.

Greetings, Marcel