ace-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremias Maerki <...@jeremias-maerki.ch>
Subject Re: Various newbie observations
Date Mon, 03 Oct 2011 07:27:26 GMT
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


Mime
View raw message