Hi,
Jukka Zitting schrieb:
Hi,
On Thu, Jun 26, 2008 at 12:25 PM, Felix Meschberger <[EMAIL PROTECTED]> wrote:
I do not envision weekly releases of single components. But there may well
be one or two releases (or more) per month, yes. We also have this over at
Felix and it works quite well.
OK. I'm just wondering how it looks to a potential end user.
Looking at the Felix download and news pages, it's quite difficult to
determine whether an end user needs to care about all that. A release
is not just an artifact pushed to the Maven repository, but also
related stuff like release notes and relevant documentation updates.
Each release should come at least with enough information to tell a
user whether they should upgrade and what the effects will be if they
do.
Agreed. Release notes will certainly help. But these may be
semi-automated, I am sure.
Regarding end-user experience: Our current download pages has exactly
three downloadables: the standalone app, the web app and the source. We
might add individually released bundles in the future. But I don't
think, this is good. Read on ;-)
I would only consider merging if it would make sense on a code-wise basis.
Merging to "simplify" release management is IMHO wrong and bad.
How about merging to simplify end user experience?
We have this merging already and these are the apps we distribute today.
we might add other bundlings in the future in Deployment Packages.
Unless we can
somehow automate upgrades (wouldn't it be cool if bundles and all the
dependencies were automatically downloaded from the Maven
repository... :-), our users could well end up manually managing a
complex dependency tree. At least we should document the component
dependencies somewhere.
Oh yeah, this _is_ possible ! There is the so-called OSGi bundle
repositories -- OBR for short. The Sling applications come pre-installed
with support for these repositories by means of the Felix Web Console
and Felix bundlerepository bundles.
If you go to the bundles list of the web console you might notice the
generally grayed-out "Update" buttons. If you happen to have an
appropriate OBR registered (go to the OSGi Repository page) providing
updates for one or more bundles, you see the button activated. Simply
clicking on such a button will upgrade the given bundle -- and
automatically also upgrade any required dependencies.
For now we have the OBR for the first Sling release as a test bed at
[1]. This will be expanded and be coordinated with similar efforst in
the Apache Felix project with the ultimate goal of providing OBRs for
ease of use.
In the end, we should make everything a bundle. This enables all use cases,
import and embedding. Because, remember: A bundle basically is just a JAR
with special manifest headers.
The bigger difference is how they are presented to the user in a
running system. For example, on the web console, does it make sense
that for example commons-collections can be individually removed or
upgraded? How aware the end user should be of all the inter-component
dependencies? IMHO, the fewer dependencies the user needs to worry
about the better.
In the current web console you can see for each bundle, what imports are
active and what exports and which bundle is actually importing from the
bundle you are looking at.
So you can quickly decide which bundle will be touched when removing a
bundle. When upgrading a single bundle, the depending bundles will
generally quite happily work with the more recent version.
For example, say I have a component that uses some fancy new Map
implementation in a recent commons-collections release. When a user
deploys my component, it would be nice if she didn't need to also
worry about the commons-collections version. IMHO the same reasoning
applies also to things like commons/json.
Beware of mixing terms: What is a component here ? Is it a Declarative
Services Component ? In this case it is deployed as part of a bundle,
which might have an import to the commons-collections library. if you
deploy the bundle through OBR and the OBR has the newer library
available, it will automatically be deployed together with the new
component bundle.
If the updated commons-collections library is not available the new
bundle will not resolve -- or is not deployable through OBR due to
missing dependencies.
Hope this helps.
Regards
Felix
[1] http://people.apache.org/~fmeschbe/sling-repository.xml
