[Discuss] Handling of initial bundles

[Christian Schneider <ch...@die-schneider.net>]

Hi all,

on startup we currently use the following procedure.

We read property karaf.auto.start from the file config.properties.
This can be either a list of bundles separated by spaces or 
"startup.properties" or "all".
If it is all we replace karaf.auto.start with the list of all bundles in 
the system dir. I think this option does not really make much sense.
If it is startup.properties then we replace karaf.auto.start with the 
list of bundles specified in the file startup.properties.
Additionally we either support mvn urls or paths which are converted to 
mvn urls.

This all is quite a lot of variability of which we use none.

I propose to replace this in two steps:

1. Remove the karaf.auto.start property and always load the bundles from 
startup.properties. Also only support mvn urls.
This makes the code in main cleaner and makes it easier for our users to 
understand how to change the startup bundles.

2. Remove the startup.properties and instead use a feature name to 
determine the list of bundles to load
The second step makes this even simpler and additionally we can remove 
the generation of the startup.properties in the karaf maven plugin.

So what do you think?

Christian

-- 
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
Talend Application Integration Division http://www.talend.com

Re: [Discuss] Handling of initial bundles

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

Thanks. I'll try to allocate some time to look at the latest
improvements. And Cellar is on my experiments list anyway. I've lost my
patience with Maven a long time ago, so to preserve my mental health,
Maven is no option for my project.


Jeremias Maerki


On 07.05.2012 17:51:20 Christian Schneider wrote:
> Thanks for the insight into your system. It is always intersting how 
> other working solutions look like. It is a good inspiration to think in 
> some different directions.
> 
> I think most of the requirements you have should work with maven, karaf 
> features and cellar for clusters.
> 
> For me maven has the main benefit that there is a repository where all 
> development results end up. This is the ideal
> base to deploy from. Of course you have basically the same but you had 
> to put a lot of effort into it till it worked.
> 
> If you want to revisit how karaf works right now you can try the 
> examples from my tutorials. They show how to build with maven
> and how to deploy using features. From my own experience this works 
> really well. For development you can use the dev:watch *
> command in maven to watch for changes in your local repo. These get then 
> automatically redeployed.
> 
> Btw. I recently removed the OSGi API from the karaf jar. So it might fit 
> your needs better already. It would be great if you could review the 
> current version in trunk.
> If you have some proposals how to make it fit your needs without too 
> many changes I would really be interested to hear them.
> 
> Christian
> 
> Am 07.05.2012 16:27, schrieb Jeremias Maerki:
> > (comments inline below...)
> >
> > Jeremias Maerki
> >
> >
> > On 07.05.2012 11:38:43 Christian Schneider wrote:
> >> I really like your setup it looks quite lean. It is very different from
> >> how karaf works though.
> >> So I am not sure how easy it would be to karaf open enough to also
> >> support that style. Having boot time plugins could be interesting.
> >> We already have the karaf activator that could be used for this. Perhaps
> >> that could be a basis for achieving such an open setup.
> >>
> >> I have some questions about your setup:
> >>
> >> - We use maven as a repository of binary artifacts (bundles, simple
> >> jars). What do you use for this purpose?
> > Basically bundles in a shallow directory structure.
> >
> > I used to experiment with Apache ACE. Quite nice for production
> > environments but during development it wasn't easy enough to achieve
> > quick turn-arounds when re-deploying bundles in my development instance
> > (or instances when I work on cluster functionality). So I ended up
> > implementing a rather simple system: a servlet that observes a local
> > directory. Each subdirectory represents a "profile" with n bundles.
> > Special zero-length "import-profile.*" files let me include other
> > profiles. Via distributed events (event admin over Hazelcast) I can make
> > all instances sync with that repository. So, whenever I build a bundle
> > it gets copied to one of the profile directories and is distributed to
> > every node in the cluster within a couple of seconds. So, more or less
> > ACE-very-light without manual steps. Basically, the client part of this
> > is my management agent that I deploy via initial provisioning.
> >
> > I can also leverage FileInstall's ArtifactListeners to deploy configs,
> > for example.
> >
> > One reason for this rather simplistic approach was that I want to have
> > close control over the set of bundles that I want to deploy on the
> > system. Essentially, I try to avoid the topic of transitive dependencies
> > like this which is one thing I dislike about Maven (there's good and bad
> > in everything). Since I'm building a document production system that
> > might one day become open source with an Apache-compatible license
> > policy, I want full control over what goes into the system.
> >
> > I guess in the long-term I might also want to go towards OBR. It should
> > be easy to enhance the servlet so it produces OBR metadata from the
> > bundles in its repository.
> >
> >> - While I see that your setup should work nicely it sure was a lot of
> >> effort to create. Why did you choose to do so instead of simply using
> >> plain karaf?
> > Yes, it was quite a bit. But I had invested quite a lot of time already
> > to try to make Ace do what I was looking for, but my requirements just
> > didn't fit. I think Ace is great from the integration step on up to
> > production, but I wanted something that gives me full control and that
> > would work efficiently from my development environment up to production.
> > Well, that's the deployment part...
> >
> > ...and for the container part: I guess it was several little things that
> > let me do that:
> > - I wasn't happy with the Maven directory outline in "system" and with
> > startup.properties.
> > - Another thing I didn't like was the embedding of the OSGi API in
> > karaf.jar. That disallows running on the latest Felix.
> > - I don't need the failover setup. I rather solve that with a cluster or
> > hot stand-by.
> > - The distinction between karaf.base and karaf.home is not clear enough
> > to me.
> > - I wanted to split karaf.data into a data (/var/local) and a log
> > (/var/log) location. That would have been relatively easy to propose to
> > Karaf, I know. After all, I was the one to suggest the karaf.data
> > property. But that point was mostly an after-thought after already
> > having started with my container.
> > That's what I remember just now. I'm pretty sure I've had another point.
> >
> >
> >> - What are the main features of karaf that make you use it compared to
> >> plain felix? The maven support can not be it :-)
> > - standardized properties for file locations (home, data, etc.)
> > - the approach with properties files and property substitution
> > - the shell and many commands (although I still write my own commands
> > with plain RFC 132)
> > - SSH console
> > - Blueprint deployer
> >
> > I guess features are nice for experiments and demos, but I remember
> > having troubles in the past so I didn't use them. I've never revisited
> > that decision through new tests. I've not always been able to follow
> > every development in Karaf. I noticed Cellar quite (too) late, for
> > example. I had already implemented similar things.
> >
> > Generally, I still run into strange effects every now and then. Some
> > third-party that was not really written for OSGi not behaving ideally,
> > producing class loader issues or whatever. Keeping tight control over
> > deployment allows me to counteract this to a degree. I sometimes wonder
> > if I'm the only one running into so many little problems with various
> > bundles. I love OSGi but sometimes I find it difficult to create a
> > complex system where all components play nice from startup to shutdown.
> > I often find myself up- or downgrading a particular bundle (and its
> > dependencies) to work around a problem.
> >
> >> Genrally I am not a big fan of completely open systems as they fragment
> >> the user deployments. If you mainly make your platform open then every
> >> user will use it differently.
> > I understand that completely. It also makes it more complex for newbies.
> > I do think it's good that Karaf recommends a widely accepted best
> > practice with the default installation. The "newbie kickstart" (unpack,
> > drop a bundle in "deploy" and go) is one of the great things about Karaf.
> > It's much easier to get OSGi newbies started on Karaf than with plain
> > framework. But maybe it can get a bit more open for the advanced user.
> >
> >> That is not so good in relation to forming a community. So I am more a
> >> fan of choosing a good path and using it (a bit like gnome vs kde or mac
> >> vs linux). Of course in some areas modularity is really good but you
> >> have to be careful.
> > Agreed. But one size doesn't fit all. I like Ace but it's not for me. I
> > "spent/wasted" a lot of time building basic components of my own. I'm
> > pathologic in that area. I even wrote my Bnd alternative for Ant. How
> > crazy is that? ;-) But it turned out that it was really easier (and
> > faster) sometimes to build something that was tailored to my
> > expectations that to beat something else into submission. Surely not in
> > every case.
> >
> >> Christian
> >>
> >> Am 07.05.2012 10:17, schrieb Jeremias Maerki:
> >>> (hooking into a random point in this thread, mostly agreeing with
> >>> Guillaume and David)
> >>>
> >>> I'd like to offer my view on the topic. I've recently started moving
> >>> away from the Karaf bootstrapper (still using many Karaf bundles,
> >>> though). I ended up writing my own bootstrapper because I thought the
> >>> current one does too much and imposes certain decisions.
> >>>
> >>> Here's where I am now:
> >>> - "lib" directory for the bootstrapper (18KB) + framework(s) and service
> >>> adapters (Commons Deamon, Wrapper etc., in the future to be implemented
> >>> as plug-ins using META-INF/services like with the framework).
> >>> - "lib/endorsed" directory: not nice but unfortunately I can't seem to
> >>> do without, yet.
> >>> - "bundles" directory for startup bundles. Can optionally have
> >>> subdirectories with the start-level as name, ex. "bundles/10" for
> >>> start-level 10. (No startup.properties) (Even this could be a "bootstrap"
> >>> plug-in so others can implement their own choice of initial bundle
> >>> provisioning.)
> >>> - "etc" directory: minimally only contains a system.properties,
> >>> framework.properties and jre.properties.
> >>>
> >>> In the production deployment, the installation really just contains a
> >>> minimal set of 3 bundles (compendium, my initial provisioning
> >>> implementation bundle and config admin). Initial provisioning fetches
> >>> the management agent from a central place and invokes that to actually
> >>> deploy the application.
> >>>
> >>> That allows me to put minimal configuration on each server and reduce
> >>> the frequency in which the bootstrapper has to be upgraded. All the rest
> >>> is fetched from a central deployment server.
> >>>
> >>> In my development environment, fileinstall and many other bundles are
> >>> put in the "bundles" directory so I get a "Karaf-like" setup, skipping
> >>> the actual deployment server (actually the local instance serves as that).
> >>>
> >>> I don't work with Maven, so I don't personally like that dependency,
> >>> even it's just the directory layout in the "system" directory. The
> >>> startup.properties doesn't even need to be kept in sync with that
> >>> directory.
> >>>
> >>> Since I'm seeing multiple desires in this thread, why not make the
> >>> container/bootstrapper much more modular and give the power to the users
> >>> to choose their favorite setup? Karaf already offers a ton of very
> >>> useful bundles that can but don't need to be used. You could extend that
> >>> approach to the bootstrapper.
> >>>
> >>> Just my 0.05 CHF.
> >>>
> >>> HTH
> >>> Jeremias Maerki
> >>>
> >>
> >> -- 
> >> Christian Schneider
> >> http://www.liquid-reality.de
> >>
> >> Open Source Architect
> >> Talend Application Integration Division http://www.talend.com
> 
> 
> -- 
> 
> Christian Schneider
> http://www.liquid-reality.de
> 
> Open Source Architect
> Talend Application Integration Division http://www.talend.com

Re: [Discuss] Handling of initial bundles

[Christian Schneider <ch...@die-schneider.net>]

Thanks for the insight into your system. It is always intersting how 
other working solutions look like. It is a good inspiration to think in 
some different directions.

I think most of the requirements you have should work with maven, karaf 
features and cellar for clusters.

For me maven has the main benefit that there is a repository where all 
development results end up. This is the ideal
base to deploy from. Of course you have basically the same but you had 
to put a lot of effort into it till it worked.

If you want to revisit how karaf works right now you can try the 
examples from my tutorials. They show how to build with maven
and how to deploy using features. From my own experience this works 
really well. For development you can use the dev:watch *
command in maven to watch for changes in your local repo. These get then 
automatically redeployed.

Btw. I recently removed the OSGi API from the karaf jar. So it might fit 
your needs better already. It would be great if you could review the 
current version in trunk.
If you have some proposals how to make it fit your needs without too 
many changes I would really be interested to hear them.

Christian

Am 07.05.2012 16:27, schrieb Jeremias Maerki:
> (comments inline below...)
>
> Jeremias Maerki
>
>
> On 07.05.2012 11:38:43 Christian Schneider wrote:
>> I really like your setup it looks quite lean. It is very different from
>> how karaf works though.
>> So I am not sure how easy it would be to karaf open enough to also
>> support that style. Having boot time plugins could be interesting.
>> We already have the karaf activator that could be used for this. Perhaps
>> that could be a basis for achieving such an open setup.
>>
>> I have some questions about your setup:
>>
>> - We use maven as a repository of binary artifacts (bundles, simple
>> jars). What do you use for this purpose?
> Basically bundles in a shallow directory structure.
>
> I used to experiment with Apache ACE. Quite nice for production
> environments but during development it wasn't easy enough to achieve
> quick turn-arounds when re-deploying bundles in my development instance
> (or instances when I work on cluster functionality). So I ended up
> implementing a rather simple system: a servlet that observes a local
> directory. Each subdirectory represents a "profile" with n bundles.
> Special zero-length "import-profile.*" files let me include other
> profiles. Via distributed events (event admin over Hazelcast) I can make
> all instances sync with that repository. So, whenever I build a bundle
> it gets copied to one of the profile directories and is distributed to
> every node in the cluster within a couple of seconds. So, more or less
> ACE-very-light without manual steps. Basically, the client part of this
> is my management agent that I deploy via initial provisioning.
>
> I can also leverage FileInstall's ArtifactListeners to deploy configs,
> for example.
>
> One reason for this rather simplistic approach was that I want to have
> close control over the set of bundles that I want to deploy on the
> system. Essentially, I try to avoid the topic of transitive dependencies
> like this which is one thing I dislike about Maven (there's good and bad
> in everything). Since I'm building a document production system that
> might one day become open source with an Apache-compatible license
> policy, I want full control over what goes into the system.
>
> I guess in the long-term I might also want to go towards OBR. It should
> be easy to enhance the servlet so it produces OBR metadata from the
> bundles in its repository.
>
>> - While I see that your setup should work nicely it sure was a lot of
>> effort to create. Why did you choose to do so instead of simply using
>> plain karaf?
> Yes, it was quite a bit. But I had invested quite a lot of time already
> to try to make Ace do what I was looking for, but my requirements just
> didn't fit. I think Ace is great from the integration step on up to
> production, but I wanted something that gives me full control and that
> would work efficiently from my development environment up to production.
> Well, that's the deployment part...
>
> ...and for the container part: I guess it was several little things that
> let me do that:
> - I wasn't happy with the Maven directory outline in "system" and with
> startup.properties.
> - Another thing I didn't like was the embedding of the OSGi API in
> karaf.jar. That disallows running on the latest Felix.
> - I don't need the failover setup. I rather solve that with a cluster or
> hot stand-by.
> - The distinction between karaf.base and karaf.home is not clear enough
> to me.
> - I wanted to split karaf.data into a data (/var/local) and a log
> (/var/log) location. That would have been relatively easy to propose to
> Karaf, I know. After all, I was the one to suggest the karaf.data
> property. But that point was mostly an after-thought after already
> having started with my container.
> That's what I remember just now. I'm pretty sure I've had another point.
>
>
>> - What are the main features of karaf that make you use it compared to
>> plain felix? The maven support can not be it :-)
> - standardized properties for file locations (home, data, etc.)
> - the approach with properties files and property substitution
> - the shell and many commands (although I still write my own commands
> with plain RFC 132)
> - SSH console
> - Blueprint deployer
>
> I guess features are nice for experiments and demos, but I remember
> having troubles in the past so I didn't use them. I've never revisited
> that decision through new tests. I've not always been able to follow
> every development in Karaf. I noticed Cellar quite (too) late, for
> example. I had already implemented similar things.
>
> Generally, I still run into strange effects every now and then. Some
> third-party that was not really written for OSGi not behaving ideally,
> producing class loader issues or whatever. Keeping tight control over
> deployment allows me to counteract this to a degree. I sometimes wonder
> if I'm the only one running into so many little problems with various
> bundles. I love OSGi but sometimes I find it difficult to create a
> complex system where all components play nice from startup to shutdown.
> I often find myself up- or downgrading a particular bundle (and its
> dependencies) to work around a problem.
>
>> Genrally I am not a big fan of completely open systems as they fragment
>> the user deployments. If you mainly make your platform open then every
>> user will use it differently.
> I understand that completely. It also makes it more complex for newbies.
> I do think it's good that Karaf recommends a widely accepted best
> practice with the default installation. The "newbie kickstart" (unpack,
> drop a bundle in "deploy" and go) is one of the great things about Karaf.
> It's much easier to get OSGi newbies started on Karaf than with plain
> framework. But maybe it can get a bit more open for the advanced user.
>
>> That is not so good in relation to forming a community. So I am more a
>> fan of choosing a good path and using it (a bit like gnome vs kde or mac
>> vs linux). Of course in some areas modularity is really good but you
>> have to be careful.
> Agreed. But one size doesn't fit all. I like Ace but it's not for me. I
> "spent/wasted" a lot of time building basic components of my own. I'm
> pathologic in that area. I even wrote my Bnd alternative for Ant. How
> crazy is that? ;-) But it turned out that it was really easier (and
> faster) sometimes to build something that was tailored to my
> expectations that to beat something else into submission. Surely not in
> every case.
>
>> Christian
>>
>> Am 07.05.2012 10:17, schrieb Jeremias Maerki:
>>> (hooking into a random point in this thread, mostly agreeing with
>>> Guillaume and David)
>>>
>>> I'd like to offer my view on the topic. I've recently started moving
>>> away from the Karaf bootstrapper (still using many Karaf bundles,
>>> though). I ended up writing my own bootstrapper because I thought the
>>> current one does too much and imposes certain decisions.
>>>
>>> Here's where I am now:
>>> - "lib" directory for the bootstrapper (18KB) + framework(s) and service
>>> adapters (Commons Deamon, Wrapper etc., in the future to be implemented
>>> as plug-ins using META-INF/services like with the framework).
>>> - "lib/endorsed" directory: not nice but unfortunately I can't seem to
>>> do without, yet.
>>> - "bundles" directory for startup bundles. Can optionally have
>>> subdirectories with the start-level as name, ex. "bundles/10" for
>>> start-level 10. (No startup.properties) (Even this could be a "bootstrap"
>>> plug-in so others can implement their own choice of initial bundle
>>> provisioning.)
>>> - "etc" directory: minimally only contains a system.properties,
>>> framework.properties and jre.properties.
>>>
>>> In the production deployment, the installation really just contains a
>>> minimal set of 3 bundles (compendium, my initial provisioning
>>> implementation bundle and config admin). Initial provisioning fetches
>>> the management agent from a central place and invokes that to actually
>>> deploy the application.
>>>
>>> That allows me to put minimal configuration on each server and reduce
>>> the frequency in which the bootstrapper has to be upgraded. All the rest
>>> is fetched from a central deployment server.
>>>
>>> In my development environment, fileinstall and many other bundles are
>>> put in the "bundles" directory so I get a "Karaf-like" setup, skipping
>>> the actual deployment server (actually the local instance serves as that).
>>>
>>> I don't work with Maven, so I don't personally like that dependency,
>>> even it's just the directory layout in the "system" directory. The
>>> startup.properties doesn't even need to be kept in sync with that
>>> directory.
>>>
>>> Since I'm seeing multiple desires in this thread, why not make the
>>> container/bootstrapper much more modular and give the power to the users
>>> to choose their favorite setup? Karaf already offers a ton of very
>>> useful bundles that can but don't need to be used. You could extend that
>>> approach to the bootstrapper.
>>>
>>> Just my 0.05 CHF.
>>>
>>> HTH
>>> Jeremias Maerki
>>>
>>
>> -- 
>> Christian Schneider
>> http://www.liquid-reality.de
>>
>> Open Source Architect
>> Talend Application Integration Division http://www.talend.com


-- 

Christian Schneider
http://www.liquid-reality.de

Open Source Architect
Talend Application Integration Division http://www.talend.com

Re: [Discuss] Handling of initial bundles

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

(comments inline below...)

Jeremias Maerki


On 07.05.2012 11:38:43 Christian Schneider wrote:
> I really like your setup it looks quite lean. It is very different from 
> how karaf works though.
> So I am not sure how easy it would be to karaf open enough to also 
> support that style. Having boot time plugins could be interesting.
> We already have the karaf activator that could be used for this. Perhaps 
> that could be a basis for achieving such an open setup.
> 
> I have some questions about your setup:
> 
> - We use maven as a repository of binary artifacts (bundles, simple 
> jars). What do you use for this purpose?

Basically bundles in a shallow directory structure.

I used to experiment with Apache ACE. Quite nice for production
environments but during development it wasn't easy enough to achieve
quick turn-arounds when re-deploying bundles in my development instance
(or instances when I work on cluster functionality). So I ended up
implementing a rather simple system: a servlet that observes a local
directory. Each subdirectory represents a "profile" with n bundles.
Special zero-length "import-profile.*" files let me include other
profiles. Via distributed events (event admin over Hazelcast) I can make
all instances sync with that repository. So, whenever I build a bundle
it gets copied to one of the profile directories and is distributed to
every node in the cluster within a couple of seconds. So, more or less
ACE-very-light without manual steps. Basically, the client part of this
is my management agent that I deploy via initial provisioning.

I can also leverage FileInstall's ArtifactListeners to deploy configs,
for example.

One reason for this rather simplistic approach was that I want to have
close control over the set of bundles that I want to deploy on the
system. Essentially, I try to avoid the topic of transitive dependencies
like this which is one thing I dislike about Maven (there's good and bad
in everything). Since I'm building a document production system that
might one day become open source with an Apache-compatible license
policy, I want full control over what goes into the system.

I guess in the long-term I might also want to go towards OBR. It should
be easy to enhance the servlet so it produces OBR metadata from the
bundles in its repository.

> - While I see that your setup should work nicely it sure was a lot of 
> effort to create. Why did you choose to do so instead of simply using 
> plain karaf?

Yes, it was quite a bit. But I had invested quite a lot of time already
to try to make Ace do what I was looking for, but my requirements just
didn't fit. I think Ace is great from the integration step on up to
production, but I wanted something that gives me full control and that
would work efficiently from my development environment up to production.
Well, that's the deployment part...

...and for the container part: I guess it was several little things that
let me do that:
- I wasn't happy with the Maven directory outline in "system" and with
startup.properties.
- Another thing I didn't like was the embedding of the OSGi API in
karaf.jar. That disallows running on the latest Felix.
- I don't need the failover setup. I rather solve that with a cluster or
hot stand-by.
- The distinction between karaf.base and karaf.home is not clear enough
to me.
- I wanted to split karaf.data into a data (/var/local) and a log
(/var/log) location. That would have been relatively easy to propose to
Karaf, I know. After all, I was the one to suggest the karaf.data
property. But that point was mostly an after-thought after already
having started with my container.
That's what I remember just now. I'm pretty sure I've had another point.


> - What are the main features of karaf that make you use it compared to 
> plain felix? The maven support can not be it :-)

- standardized properties for file locations (home, data, etc.)
- the approach with properties files and property substitution
- the shell and many commands (although I still write my own commands
with plain RFC 132)
- SSH console
- Blueprint deployer

I guess features are nice for experiments and demos, but I remember
having troubles in the past so I didn't use them. I've never revisited
that decision through new tests. I've not always been able to follow
every development in Karaf. I noticed Cellar quite (too) late, for
example. I had already implemented similar things.

Generally, I still run into strange effects every now and then. Some
third-party that was not really written for OSGi not behaving ideally,
producing class loader issues or whatever. Keeping tight control over
deployment allows me to counteract this to a degree. I sometimes wonder
if I'm the only one running into so many little problems with various
bundles. I love OSGi but sometimes I find it difficult to create a
complex system where all components play nice from startup to shutdown.
I often find myself up- or downgrading a particular bundle (and its
dependencies) to work around a problem.

> Genrally I am not a big fan of completely open systems as they fragment 
> the user deployments. If you mainly make your platform open then every 
> user will use it differently.

I understand that completely. It also makes it more complex for newbies.
I do think it's good that Karaf recommends a widely accepted best
practice with the default installation. The "newbie kickstart" (unpack,
drop a bundle in "deploy" and go) is one of the great things about Karaf.
It's much easier to get OSGi newbies started on Karaf than with plain
framework. But maybe it can get a bit more open for the advanced user.

> That is not so good in relation to forming a community. So I am more a 
> fan of choosing a good path and using it (a bit like gnome vs kde or mac 
> vs linux). Of course in some areas modularity is really good but you 
> have to be careful.

Agreed. But one size doesn't fit all. I like Ace but it's not for me. I
"spent/wasted" a lot of time building basic components of my own. I'm
pathologic in that area. I even wrote my Bnd alternative for Ant. How
crazy is that? ;-) But it turned out that it was really easier (and
faster) sometimes to build something that was tailored to my
expectations that to beat something else into submission. Surely not in
every case.

> Christian
> 
> Am 07.05.2012 10:17, schrieb Jeremias Maerki:
> > (hooking into a random point in this thread, mostly agreeing with
> > Guillaume and David)
> >
> > I'd like to offer my view on the topic. I've recently started moving
> > away from the Karaf bootstrapper (still using many Karaf bundles,
> > though). I ended up writing my own bootstrapper because I thought the
> > current one does too much and imposes certain decisions.
> >
> > Here's where I am now:
> > - "lib" directory for the bootstrapper (18KB) + framework(s) and service
> > adapters (Commons Deamon, Wrapper etc., in the future to be implemented
> > as plug-ins using META-INF/services like with the framework).
> > - "lib/endorsed" directory: not nice but unfortunately I can't seem to
> > do without, yet.
> > - "bundles" directory for startup bundles. Can optionally have
> > subdirectories with the start-level as name, ex. "bundles/10" for
> > start-level 10. (No startup.properties) (Even this could be a "bootstrap"
> > plug-in so others can implement their own choice of initial bundle
> > provisioning.)
> > - "etc" directory: minimally only contains a system.properties,
> > framework.properties and jre.properties.
> >
> > In the production deployment, the installation really just contains a
> > minimal set of 3 bundles (compendium, my initial provisioning
> > implementation bundle and config admin). Initial provisioning fetches
> > the management agent from a central place and invokes that to actually
> > deploy the application.
> >
> > That allows me to put minimal configuration on each server and reduce
> > the frequency in which the bootstrapper has to be upgraded. All the rest
> > is fetched from a central deployment server.
> >
> > In my development environment, fileinstall and many other bundles are
> > put in the "bundles" directory so I get a "Karaf-like" setup, skipping
> > the actual deployment server (actually the local instance serves as that).
> >
> > I don't work with Maven, so I don't personally like that dependency,
> > even it's just the directory layout in the "system" directory. The
> > startup.properties doesn't even need to be kept in sync with that
> > directory.
> >
> > Since I'm seeing multiple desires in this thread, why not make the
> > container/bootstrapper much more modular and give the power to the users
> > to choose their favorite setup? Karaf already offers a ton of very
> > useful bundles that can but don't need to be used. You could extend that
> > approach to the bootstrapper.
> >
> > Just my 0.05 CHF.
> >
> > HTH
> > Jeremias Maerki
> >
> 
> 
> -- 
> Christian Schneider
> http://www.liquid-reality.de
> 
> Open Source Architect
> Talend Application Integration Division http://www.talend.com

Re: [Discuss] Handling of initial bundles

[Christian Schneider <ch...@die-schneider.net>]

I really like your setup it looks quite lean. It is very different from 
how karaf works though.
So I am not sure how easy it would be to karaf open enough to also 
support that style. Having boot time plugins could be interesting.
We already have the karaf activator that could be used for this. Perhaps 
that could be a basis for achieving such an open setup.

I have some questions about your setup:

- We use maven as a repository of binary artifacts (bundles, simple 
jars). What do you use for this purpose?
- While I see that your setup should work nicely it sure was a lot of 
effort to create. Why did you choose to do so instead of simply using 
plain karaf?
- What are the main features of karaf that make you use it compared to 
plain felix? The maven support can not be it :-)

Genrally I am not a big fan of completely open systems as they fragment 
the user deployments. If you mainly make your platform open then every 
user will use it differently.
That is not so good in relation to forming a community. So I am more a 
fan of choosing a good path and using it (a bit like gnome vs kde or mac 
vs linux). Of course in some areas modularity is really good but you 
have to be careful.

Christian

Am 07.05.2012 10:17, schrieb Jeremias Maerki:
> (hooking into a random point in this thread, mostly agreeing with
> Guillaume and David)
>
> I'd like to offer my view on the topic. I've recently started moving
> away from the Karaf bootstrapper (still using many Karaf bundles,
> though). I ended up writing my own bootstrapper because I thought the
> current one does too much and imposes certain decisions.
>
> Here's where I am now:
> - "lib" directory for the bootstrapper (18KB) + framework(s) and service
> adapters (Commons Deamon, Wrapper etc., in the future to be implemented
> as plug-ins using META-INF/services like with the framework).
> - "lib/endorsed" directory: not nice but unfortunately I can't seem to
> do without, yet.
> - "bundles" directory for startup bundles. Can optionally have
> subdirectories with the start-level as name, ex. "bundles/10" for
> start-level 10. (No startup.properties) (Even this could be a "bootstrap"
> plug-in so others can implement their own choice of initial bundle
> provisioning.)
> - "etc" directory: minimally only contains a system.properties,
> framework.properties and jre.properties.
>
> In the production deployment, the installation really just contains a
> minimal set of 3 bundles (compendium, my initial provisioning
> implementation bundle and config admin). Initial provisioning fetches
> the management agent from a central place and invokes that to actually
> deploy the application.
>
> That allows me to put minimal configuration on each server and reduce
> the frequency in which the bootstrapper has to be upgraded. All the rest
> is fetched from a central deployment server.
>
> In my development environment, fileinstall and many other bundles are
> put in the "bundles" directory so I get a "Karaf-like" setup, skipping
> the actual deployment server (actually the local instance serves as that).
>
> I don't work with Maven, so I don't personally like that dependency,
> even it's just the directory layout in the "system" directory. The
> startup.properties doesn't even need to be kept in sync with that
> directory.
>
> Since I'm seeing multiple desires in this thread, why not make the
> container/bootstrapper much more modular and give the power to the users
> to choose their favorite setup? Karaf already offers a ton of very
> useful bundles that can but don't need to be used. You could extend that
> approach to the bootstrapper.
>
> Just my 0.05 CHF.
>
> HTH
> Jeremias Maerki
>


-- 
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
Talend Application Integration Division http://www.talend.com

Re: [Discuss] Handling of initial bundles

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

(hooking into a random point in this thread, mostly agreeing with
Guillaume and David)

I'd like to offer my view on the topic. I've recently started moving
away from the Karaf bootstrapper (still using many Karaf bundles,
though). I ended up writing my own bootstrapper because I thought the
current one does too much and imposes certain decisions.

Here's where I am now:
- "lib" directory for the bootstrapper (18KB) + framework(s) and service
adapters (Commons Deamon, Wrapper etc., in the future to be implemented
as plug-ins using META-INF/services like with the framework).
- "lib/endorsed" directory: not nice but unfortunately I can't seem to
do without, yet.
- "bundles" directory for startup bundles. Can optionally have
subdirectories with the start-level as name, ex. "bundles/10" for
start-level 10. (No startup.properties) (Even this could be a "bootstrap"
plug-in so others can implement their own choice of initial bundle
provisioning.)
- "etc" directory: minimally only contains a system.properties,
framework.properties and jre.properties.

In the production deployment, the installation really just contains a
minimal set of 3 bundles (compendium, my initial provisioning
implementation bundle and config admin). Initial provisioning fetches
the management agent from a central place and invokes that to actually
deploy the application.

That allows me to put minimal configuration on each server and reduce
the frequency in which the bootstrapper has to be upgraded. All the rest
is fetched from a central deployment server.

In my development environment, fileinstall and many other bundles are
put in the "bundles" directory so I get a "Karaf-like" setup, skipping
the actual deployment server (actually the local instance serves as that).

I don't work with Maven, so I don't personally like that dependency,
even it's just the directory layout in the "system" directory. The
startup.properties doesn't even need to be kept in sync with that
directory.

Since I'm seeing multiple desires in this thread, why not make the
container/bootstrapper much more modular and give the power to the users
to choose their favorite setup? Karaf already offers a ton of very
useful bundles that can but don't need to be used. You could extend that
approach to the bootstrapper.

Just my 0.05 CHF.

HTH
Jeremias Maerki

Re: [Discuss] Handling of initial bundles

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

As I said in my previous e-mail, all depends of the proposed 
implementation. Maybe we can keep something clean and simple, also 
atomic, in Main.

But I'm agree with you about the fact that Main should be autonomous and 
simple.

Regards
JB

On 05/06/2012 07:12 PM, Achim Nierbeck wrote:
> Even though you and Christian are certainly right that maven and OSGi
> work quite well if the versions are kept right, but this
> isn't the focus here. So coming back to the initial question I agree
> with Guillaume, to better keep the main class
> lean and simple therefore I give a -1 on this.
> I don't want to see any dependencies to a features service what so ever
> in main.
>
> Thanx, Achim
>
> Am 05.05.2012 11:33, schrieb Jean-Baptiste Onofré:
>> Agree with Christian.
>>
>> Leveraging Pax URL in Karaf is a key feature (even if sometime we fake
>> the Pax URL usage, like in startup.properties URLs).
>>
>> Regards
>> JB
>>
>> On 05/05/2012 08:52 AM, Christian Schneider wrote:
>>> Well in this case you should use felix it uses a flat list of bundles
>>> :-)
>>>
>>> I think the maven centric aproach is the biggest benefit in karaf. Of
>>> course obr can help to make this even better but out there you almost
>>> find no obr repos.
>>> The big benefit with maven is that you have almost any lib available.
>>> You only need to know the artifact coordinates. For example it is great
>>> that you can install cxf or camle by just
>>> issuing two commands. How should that work without features that load
>>> artifacts from maven? As soon as all bundles are available in obr repos
>>> we can switch to this aproach but
>>> I think that is not the near future.
>>>
>>> I think the aproach of installing features and bundles from a company
>>> maven repo should be our recommended way of installing applications. I
>>> recommend to companies to split
>>> their development and deployment process at the maven repo. Developers
>>> build the sources and deploy the binaries to the company maven repo.
>>> Admins install from there. I think
>>> that is the cleanest technical aproach to devops we currently have.
>>> Of course this should include the use of the obr. As obr and maven often
>>> are incorporated in the same repository (like nexus or archiva) this
>>> should be achievable.
>>>
>>> Kar files are a dead end for me. They have their purpose when companies
>>> do not have a repository but they are completely anti modular. If you
>>> deploy two applications using kar files you have a lot of duplication
>>> and most of the advantages of osgi are gone.
>>>
>>> About the flar system repo. Why should that be a good idea? The good
>>> thing about the system repo as a maven repo is that it mimics the
>>> central repo. So users can be sure that our system repo is just a cache.
>>> All the artifacts in there are the same as in central. So the user knows
>>> that each of these jars is the "official" version. This is very helpful
>>> for example for doing licensing audits.
>>>
>>> Btw. I think maven and osgi are very compatible on the lowest level.
>>> Maven can supply single artifacts very well. It is only the dependency
>>> resolution that is not compatible but obr can help out with that.
>>>
>>> Christian
>>>
>>> Am 05.05.2012 04:04, schrieb David Jencks:
>>>> I think we should make karaf much less maven centric including:
>>>>
>>>> -- system repo is flat, not maven structured, with file names enforced
>>>> as bundle-symbolic-name_bundle-version.jar. startup.properties can
>>>> then just have jar-name=start-level.
>>>>
>>>> -- kar files use similar flat internal repo
>>>>
>>>> -- non-kar features deprecated
>>>>
>>>> -- heavily encourage use of obr.
>>>>
>>>> maven and osgi are really not very compatible and trying to pretend
>>>> they are IMO leads to too many problems and suppresses the usefulness
>>>> of osgi.
>>>>
>>>> thanks
>>>> david jencks
>>>>
>>>> On May 4, 2012, at 12:46 PM, Guillaume Nodet wrote:
>>>>
>>>>> Please, keep the main file lean and simple, no dependencies on url
>>>>> handlers
>>>>> or features or OBR or anything.
>>>>> The less interactions we have with the framework, the less fixes
>>>>> we'll to
>>>>> do there and the more stable it will be.
>>>>> The idea is to bootstrap the osgi framework, all the real provisioning
>>>>> should be done in the osgi framework itself using the feature
>>>>> service or
>>>>> obr or anything else that is required.
>>>>>
>>>>> On Fri, May 4, 2012 at 8:35 PM, Jean-Baptiste
>>>>> Onofré<jb...@nanthrax.net>wrote:
>>>>>
>>>>>> It makes sense, and I don't want to use the OfflineFeatureService
>>>>>> (not
>>>>>> require) but we will certainly have to decide to some "restriction"
>>>>>> (for
>>>>>> instance, what do we do if a feature is define in a feature ;)).
>>>>>>
>>>>>> Regards
>>>>>> JB
>>>>>>
>>>>>>
>>>>>> On 05/04/2012 08:18 PM, Christian Schneider wrote:
>>>>>>
>>>>>>> Hi JB,
>>>>>>>
>>>>>>> yes we do not use the real maven resolution. I thought about
>>>>>>> changing it
>>>>>>> but it would have too many dependencies.
>>>>>>>
>>>>>>> I did not mean to really use features. Rather to read the feature
>>>>>>> file
>>>>>>> instead of the startup.properties but still process and resolve
>>>>>>> in the
>>>>>>> same way as before. So this should not add
>>>>>>> much complexity. We could use the OfflineFeatureService but I dont
>>>>>>> think
>>>>>>> it is really necessary.
>>>>>>>
>>>>>>> Christian
>>>>>>>
>>>>>>> Am 04.05.2012 19:24, schrieb Jean-Baptiste Onofré:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> As reminder, in startup properties we don't really use mvn URL. I
>>>>>>>> mean
>>>>>>>> we construct a file URL from the mvn one, we don't really use Pax
>>>>>>>> URL.
>>>>>>>>
>>>>>>>> Anyway, it sounds good to me. I don't think users use anything else
>>>>>>>> than the startup.properties.
>>>>>>>>
>>>>>>>> Regarding a feature instead of startup.properties, it means that we
>>>>>>>> have to load at least feature core. I'm not sure that it's a good
>>>>>>>> idea
>>>>>>>> because feature is already OSGi oriented, whereas in the main
>>>>>>>> area we
>>>>>>>> start the framework (so we are not in the "OSGi area"). It's
>>>>>>>> possible
>>>>>>>> but it means that even if we provide a features XML, it's not
>>>>>>>> really
>>>>>>>> the feature service that will be use but a FeatureStartup process
>>>>>>>> (like OfflineFeatureService that we use in the Karaf maven plugin).
>>>>>>>>
>>>>>>>> So it means that we will have a dual bootstrap process which use
>>>>>>>> feature:
>>>>>>>> - the "startup" feature (which doesn't really use the feature
>>>>>>>> service)
>>>>>>>> - the "boot" feature (which uses the feature service)
>>>>>>>>
>>>>>>>> As the startup.properties is generated from a feature currently, it
>>>>>>>> makes sense to directly use the feature.
>>>>>>>>
>>>>>>>> All depends the way that it will be implemented, but basically +1
>>>>>>>>
>>>>>>>> Regards
>>>>>>>> JB
>>>>>>>>
>>>>>>>> On 05/04/2012 07:03 PM, Christian Schneider wrote:
>>>>>>>>
>>>>>>>>> Hi all,
>>>>>>>>>
>>>>>>>>> on startup we currently use the following procedure.
>>>>>>>>>
>>>>>>>>> We read property karaf.auto.start from the file config.properties.
>>>>>>>>> This can be either a list of bundles separated by spaces or
>>>>>>>>> "startup.properties" or "all".
>>>>>>>>> If it is all we replace karaf.auto.start with the list of all
>>>>>>>>> bundles in
>>>>>>>>> the system dir. I think this option does not really make much
>>>>>>>>> sense.
>>>>>>>>> If it is startup.properties then we replace karaf.auto.start with
>>>>>>>>> the
>>>>>>>>> list of bundles specified in the file startup.properties.
>>>>>>>>> Additionally we either support mvn urls or paths which are
>>>>>>>>> converted to
>>>>>>>>> mvn urls.
>>>>>>>>>
>>>>>>>>> This all is quite a lot of variability of which we use none.
>>>>>>>>>
>>>>>>>>> I propose to replace this in two steps:
>>>>>>>>>
>>>>>>>>> 1. Remove the karaf.auto.start property and always load the
>>>>>>>>> bundles from
>>>>>>>>> startup.properties. Also only support mvn urls.
>>>>>>>>> This makes the code in main cleaner and makes it easier for our
>>>>>>>>> users to
>>>>>>>>> understand how to change the startup bundles.
>>>>>>>>>
>>>>>>>>> 2. Remove the startup.properties and instead use a feature name to
>>>>>>>>> determine the list of bundles to load
>>>>>>>>> The second step makes this even simpler and additionally we can
>>>>>>>>> remove
>>>>>>>>> the generation of the startup.properties in the karaf maven
>>>>>>>>> plugin.
>>>>>>>>>
>>>>>>>>> So what do you think?
>>>>>>>>>
>>>>>>>>> Christian
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>> --
>>>>>> Jean-Baptiste Onofré
>>>>>> jbonofre@apache.org
>>>>>> http://blog.nanthrax.net
>>>>>> Talend - http://www.talend.com
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> ------------------------
>>>>> Guillaume Nodet
>>>>> ------------------------
>>>>> Blog: http://gnodet.blogspot.com/
>>>>> ------------------------
>>>>> FuseSource, Integration everywhere
>>>>> http://fusesource.com
>>>
>>>
>>
>
>

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

Re: [Discuss] Handling of initial bundles

[Christian Schneider <ch...@die-schneider.net>]

I thought the startup.poperties is mainly the bootstrap bundles that are 
not expected to be changed for custom distros.

Do you think it is really necessary to change the startup.properties for 
custom distros? There is still the featuresBoot in features.cfg where 
you can specify other features to load. I think the startup.properties 
should be as small as possbile as for example you only have the fake 
maven lookups at this point not the full features of pax url.

As mentioned in my other mail you can already use flat file names in 
startup.properties. So the maven like structure of the system repo is 
not mandatory.

Christian

Am 07.05.2012 03:26, schrieb David Jencks:
> I hope I don't understand your proposal....  if I do I'm -1 on it.
>
> Right now you can aggregate any number of features from any number of feature repositories into the startup properties.  I've found this useful building custom assemblies.
>
> To get the equivalent using a features in one or more features repositories you are either going to have to create a new feature somewhere or provide a way to load a lot of features from a lot of repositories.
>
> Also, you will be using features in two different ways: as the startup bundles and as regular features.
>
> I think this is too complicated and confusing.
>
> If you really want to pursue this further I'd also suggest considering something more like the subsystems spec idea of a feature.
>
> And as I mentioned before I think we should remove the fake mvn urls from startup.properties and make the system repo flat..... which should simplify the startup code quite a bit.
>
>
> thanks
> david jencks
>
> On May 6, 2012, at 1:28 PM, Christian Schneider wrote:
>

-- 

Christian Schneider
http://www.liquid-reality.de

Open Source Architect
Talend Application Integration Division http://www.talend.com

Re: [Discuss] Handling of initial bundles

[David Jencks <da...@yahoo.com>]

I hope I don't understand your proposal....  if I do I'm -1 on it.

Right now you can aggregate any number of features from any number of feature repositories into the startup properties.  I've found this useful building custom assemblies.

To get the equivalent using a features in one or more features repositories you are either going to have to create a new feature somewhere or provide a way to load a lot of features from a lot of repositories.

Also, you will be using features in two different ways: as the startup bundles and as regular features.

I think this is too complicated and confusing.

If you really want to pursue this further I'd also suggest considering something more like the subsystems spec idea of a feature.

And as I mentioned before I think we should remove the fake mvn urls from startup.properties and make the system repo flat..... which should simplify the startup code quite a bit.


thanks
david jencks

On May 6, 2012, at 1:28 PM, Christian Schneider wrote:

> I did not have the intention to make this more complicated. I just removed the other options.
> So what exactly do you -1?
> 
> I already committed the first step of the implementation and of course did not introduce any new dependencies.
> For the next step I plan to simply read the feature file instead of the properties file. I don´t think that I need the feature service for that.
> 
> Of course that means that the framework feature would only allow the list of bundles and the startlevel for each bundle. So basically the same
> that is supported in the startup.properties. Is that ok?
> 
> Christian
> 
> Am 06.05.2012 19:12, schrieb Achim Nierbeck:
>> Even though you and Christian are certainly right that maven and OSGi work quite well if the versions are kept right, but this
>> isn't the focus here. So coming back to the initial question I agree with Guillaume, to better keep the main class
>> lean and simple therefore I give a -1 on this.
>> I don't want to see any dependencies to a features service what so ever in main.
>> 
>> Thanx, Achim
>> 
>> Am 05.05.2012 11:33, schrieb Jean-Baptiste Onofré:
>>> Agree with Christian.
>>> 
>>> Leveraging Pax URL in Karaf is a key feature (even if sometime we fake the Pax URL usage, like in startup.properties URLs).
>>> 
>>> Regards
>>> JB
>>> 
>>> On 05/05/2012 08:52 AM, Christian Schneider wrote:
>>>> Well in this case you should use felix it uses a flat list of bundles :-)
>>>> 
>>>> I think the maven centric aproach is the biggest benefit in karaf. Of
>>>> course obr can help to make this even better but out there you almost
>>>> find no obr repos.
>>>> The big benefit with maven is that you have almost any lib available.
>>>> You only need to know the artifact coordinates. For example it is great
>>>> that you can install cxf or camle by just
>>>> issuing two commands. How should that work without features that load
>>>> artifacts from maven? As soon as all bundles are available in obr repos
>>>> we can switch to this aproach but
>>>> I think that is not the near future.
>>>> 
>>>> I think the aproach of installing features and bundles from a company
>>>> maven repo should be our recommended way of installing applications. I
>>>> recommend to companies to split
>>>> their development and deployment process at the maven repo. Developers
>>>> build the sources and deploy the binaries to the company maven repo.
>>>> Admins install from there. I think
>>>> that is the cleanest technical aproach to devops we currently have.
>>>> Of course this should include the use of the obr. As obr and maven often
>>>> are incorporated in the same repository (like nexus or archiva) this
>>>> should be achievable.
>>>> 
>>>> Kar files are a dead end for me. They have their purpose when companies
>>>> do not have a repository but they are completely anti modular. If you
>>>> deploy two applications using kar files you have a lot of duplication
>>>> and most of the advantages of osgi are gone.
>>>> 
>>>> About the flar system repo. Why should that be a good idea? The good
>>>> thing about the system repo as a maven repo is that it mimics the
>>>> central repo. So users can be sure that our system repo is just a cache.
>>>> All the artifacts in there are the same as in central. So the user knows
>>>> that each of these jars is the "official" version. This is very helpful
>>>> for example for doing licensing audits.
>>>> 
>>>> Btw. I think maven and osgi are very compatible on the lowest level.
>>>> Maven can supply single artifacts very well. It is only the dependency
>>>> resolution that is not compatible but obr can help out with that.
>>>> 
>>>> Christian
>>>> 
>>>> Am 05.05.2012 04:04, schrieb David Jencks:
>>>>> I think we should make karaf much less maven centric including:
>>>>> 
>>>>> -- system repo is flat, not maven structured, with file names enforced
>>>>> as bundle-symbolic-name_bundle-version.jar. startup.properties can
>>>>> then just have jar-name=start-level.
>>>>> 
>>>>> -- kar files use similar flat internal repo
>>>>> 
>>>>> -- non-kar features deprecated
>>>>> 
>>>>> -- heavily encourage use of obr.
>>>>> 
>>>>> maven and osgi are really not very compatible and trying to pretend
>>>>> they are IMO leads to too many problems and suppresses the usefulness
>>>>> of osgi.
>>>>> 
>>>>> thanks
>>>>> david jencks
>>>>> 
>>>>> On May 4, 2012, at 12:46 PM, Guillaume Nodet wrote:
>>>>> 
>>>>>> Please, keep the main file lean and simple, no dependencies on url
>>>>>> handlers
>>>>>> or features or OBR or anything.
>>>>>> The less interactions we have with the framework, the less fixes
>>>>>> we'll to
>>>>>> do there and the more stable it will be.
>>>>>> The idea is to bootstrap the osgi framework, all the real provisioning
>>>>>> should be done in the osgi framework itself using the feature service or
>>>>>> obr or anything else that is required.
>>>>>> 
>>>>>> On Fri, May 4, 2012 at 8:35 PM, Jean-Baptiste
>>>>>> Onofré<jb...@nanthrax.net>wrote:
>>>>>> 
>>>>>>> It makes sense, and I don't want to use the OfflineFeatureService (not
>>>>>>> require) but we will certainly have to decide to some "restriction"
>>>>>>> (for
>>>>>>> instance, what do we do if a feature is define in a feature ;)).
>>>>>>> 
>>>>>>> Regards
>>>>>>> JB
>>>>>>> 
>>>>>>> 
>>>>>>> On 05/04/2012 08:18 PM, Christian Schneider wrote:
>>>>>>> 
>>>>>>>> Hi JB,
>>>>>>>> 
>>>>>>>> yes we do not use the real maven resolution. I thought about
>>>>>>>> changing it
>>>>>>>> but it would have too many dependencies.
>>>>>>>> 
>>>>>>>> I did not mean to really use features. Rather to read the feature file
>>>>>>>> instead of the startup.properties but still process and resolve in the
>>>>>>>> same way as before. So this should not add
>>>>>>>> much complexity. We could use the OfflineFeatureService but I dont
>>>>>>>> think
>>>>>>>> it is really necessary.
>>>>>>>> 
>>>>>>>> Christian
>>>>>>>> 
>>>>>>>> Am 04.05.2012 19:24, schrieb Jean-Baptiste Onofré:
>>>>>>>> 
>>>>>>>>> Hi,
>>>>>>>>> 
>>>>>>>>> As reminder, in startup properties we don't really use mvn URL. I
>>>>>>>>> mean
>>>>>>>>> we construct a file URL from the mvn one, we don't really use Pax
>>>>>>>>> URL.
>>>>>>>>> 
>>>>>>>>> Anyway, it sounds good to me. I don't think users use anything else
>>>>>>>>> than the startup.properties.
>>>>>>>>> 
>>>>>>>>> Regarding a feature instead of startup.properties, it means that we
>>>>>>>>> have to load at least feature core. I'm not sure that it's a good
>>>>>>>>> idea
>>>>>>>>> because feature is already OSGi oriented, whereas in the main area we
>>>>>>>>> start the framework (so we are not in the "OSGi area"). It's possible
>>>>>>>>> but it means that even if we provide a features XML, it's not really
>>>>>>>>> the feature service that will be use but a FeatureStartup process
>>>>>>>>> (like OfflineFeatureService that we use in the Karaf maven plugin).
>>>>>>>>> 
>>>>>>>>> So it means that we will have a dual bootstrap process which use
>>>>>>>>> feature:
>>>>>>>>> - the "startup" feature (which doesn't really use the feature
>>>>>>>>> service)
>>>>>>>>> - the "boot" feature (which uses the feature service)
>>>>>>>>> 
>>>>>>>>> As the startup.properties is generated from a feature currently, it
>>>>>>>>> makes sense to directly use the feature.
>>>>>>>>> 
>>>>>>>>> All depends the way that it will be implemented, but basically +1
>>>>>>>>> 
>>>>>>>>> Regards
>>>>>>>>> JB
>>>>>>>>> 
>>>>>>>>> On 05/04/2012 07:03 PM, Christian Schneider wrote:
>>>>>>>>> 
>>>>>>>>>> Hi all,
>>>>>>>>>> 
>>>>>>>>>> on startup we currently use the following procedure.
>>>>>>>>>> 
>>>>>>>>>> We read property karaf.auto.start from the file config.properties.
>>>>>>>>>> This can be either a list of bundles separated by spaces or
>>>>>>>>>> "startup.properties" or "all".
>>>>>>>>>> If it is all we replace karaf.auto.start with the list of all
>>>>>>>>>> bundles in
>>>>>>>>>> the system dir. I think this option does not really make much sense.
>>>>>>>>>> If it is startup.properties then we replace karaf.auto.start with
>>>>>>>>>> the
>>>>>>>>>> list of bundles specified in the file startup.properties.
>>>>>>>>>> Additionally we either support mvn urls or paths which are
>>>>>>>>>> converted to
>>>>>>>>>> mvn urls.
>>>>>>>>>> 
>>>>>>>>>> This all is quite a lot of variability of which we use none.
>>>>>>>>>> 
>>>>>>>>>> I propose to replace this in two steps:
>>>>>>>>>> 
>>>>>>>>>> 1. Remove the karaf.auto.start property and always load the
>>>>>>>>>> bundles from
>>>>>>>>>> startup.properties. Also only support mvn urls.
>>>>>>>>>> This makes the code in main cleaner and makes it easier for our
>>>>>>>>>> users to
>>>>>>>>>> understand how to change the startup bundles.
>>>>>>>>>> 
>>>>>>>>>> 2. Remove the startup.properties and instead use a feature name to
>>>>>>>>>> determine the list of bundles to load
>>>>>>>>>> The second step makes this even simpler and additionally we can
>>>>>>>>>> remove
>>>>>>>>>> the generation of the startup.properties in the karaf maven plugin.
>>>>>>>>>> 
>>>>>>>>>> So what do you think?
>>>>>>>>>> 
>>>>>>>>>> Christian
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>> 
>>>>>>> -- 
>>>>>>> Jean-Baptiste Onofré
>>>>>>> jbonofre@apache.org
>>>>>>> http://blog.nanthrax.net
>>>>>>> Talend - http://www.talend.com
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> -- 
>>>>>> ------------------------
>>>>>> Guillaume Nodet
>>>>>> ------------------------
>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>> ------------------------
>>>>>> FuseSource, Integration everywhere
>>>>>> http://fusesource.com
>>>> 
>>>> 
>>> 
>> 
>> 
> 
> 
> -- 
> 
> Christian Schneider
> http://www.liquid-reality.de
> 
> Open Source Architect
> Talend Application Integration Division http://www.talend.com
> 

Re: [Discuss] Handling of initial bundles

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

Hi Christian,

For this kind of changes, especially when you start a discussion thread, 
it makes sense to wait the "result" of the discussion and submit a patch 
in Jira for review before committing.

Regards
JB

On 05/06/2012 10:28 PM, Christian Schneider wrote:
> I did not have the intention to make this more complicated. I just
> removed the other options.
> So what exactly do you -1?
>
> I already committed the first step of the implementation and of course
> did not introduce any new dependencies.
> For the next step I plan to simply read the feature file instead of the
> properties file. I don´t think that I need the feature service for that.
>
> Of course that means that the framework feature would only allow the
> list of bundles and the startlevel for each bundle. So basically the same
> that is supported in the startup.properties. Is that ok?
>
> Christian
>
> Am 06.05.2012 19:12, schrieb Achim Nierbeck:
>> Even though you and Christian are certainly right that maven and OSGi
>> work quite well if the versions are kept right, but this
>> isn't the focus here. So coming back to the initial question I agree
>> with Guillaume, to better keep the main class
>> lean and simple therefore I give a -1 on this.
>> I don't want to see any dependencies to a features service what so
>> ever in main.
>>
>> Thanx, Achim
>>
>> Am 05.05.2012 11:33, schrieb Jean-Baptiste Onofré:
>>> Agree with Christian.
>>>
>>> Leveraging Pax URL in Karaf is a key feature (even if sometime we
>>> fake the Pax URL usage, like in startup.properties URLs).
>>>
>>> Regards
>>> JB
>>>
>>> On 05/05/2012 08:52 AM, Christian Schneider wrote:
>>>> Well in this case you should use felix it uses a flat list of
>>>> bundles :-)
>>>>
>>>> I think the maven centric aproach is the biggest benefit in karaf. Of
>>>> course obr can help to make this even better but out there you almost
>>>> find no obr repos.
>>>> The big benefit with maven is that you have almost any lib available.
>>>> You only need to know the artifact coordinates. For example it is great
>>>> that you can install cxf or camle by just
>>>> issuing two commands. How should that work without features that load
>>>> artifacts from maven? As soon as all bundles are available in obr repos
>>>> we can switch to this aproach but
>>>> I think that is not the near future.
>>>>
>>>> I think the aproach of installing features and bundles from a company
>>>> maven repo should be our recommended way of installing applications. I
>>>> recommend to companies to split
>>>> their development and deployment process at the maven repo. Developers
>>>> build the sources and deploy the binaries to the company maven repo.
>>>> Admins install from there. I think
>>>> that is the cleanest technical aproach to devops we currently have.
>>>> Of course this should include the use of the obr. As obr and maven
>>>> often
>>>> are incorporated in the same repository (like nexus or archiva) this
>>>> should be achievable.
>>>>
>>>> Kar files are a dead end for me. They have their purpose when companies
>>>> do not have a repository but they are completely anti modular. If you
>>>> deploy two applications using kar files you have a lot of duplication
>>>> and most of the advantages of osgi are gone.
>>>>
>>>> About the flar system repo. Why should that be a good idea? The good
>>>> thing about the system repo as a maven repo is that it mimics the
>>>> central repo. So users can be sure that our system repo is just a
>>>> cache.
>>>> All the artifacts in there are the same as in central. So the user
>>>> knows
>>>> that each of these jars is the "official" version. This is very helpful
>>>> for example for doing licensing audits.
>>>>
>>>> Btw. I think maven and osgi are very compatible on the lowest level.
>>>> Maven can supply single artifacts very well. It is only the dependency
>>>> resolution that is not compatible but obr can help out with that.
>>>>
>>>> Christian
>>>>
>>>> Am 05.05.2012 04:04, schrieb David Jencks:
>>>>> I think we should make karaf much less maven centric including:
>>>>>
>>>>> -- system repo is flat, not maven structured, with file names enforced
>>>>> as bundle-symbolic-name_bundle-version.jar. startup.properties can
>>>>> then just have jar-name=start-level.
>>>>>
>>>>> -- kar files use similar flat internal repo
>>>>>
>>>>> -- non-kar features deprecated
>>>>>
>>>>> -- heavily encourage use of obr.
>>>>>
>>>>> maven and osgi are really not very compatible and trying to pretend
>>>>> they are IMO leads to too many problems and suppresses the usefulness
>>>>> of osgi.
>>>>>
>>>>> thanks
>>>>> david jencks
>>>>>
>>>>> On May 4, 2012, at 12:46 PM, Guillaume Nodet wrote:
>>>>>
>>>>>> Please, keep the main file lean and simple, no dependencies on url
>>>>>> handlers
>>>>>> or features or OBR or anything.
>>>>>> The less interactions we have with the framework, the less fixes
>>>>>> we'll to
>>>>>> do there and the more stable it will be.
>>>>>> The idea is to bootstrap the osgi framework, all the real
>>>>>> provisioning
>>>>>> should be done in the osgi framework itself using the feature
>>>>>> service or
>>>>>> obr or anything else that is required.
>>>>>>
>>>>>> On Fri, May 4, 2012 at 8:35 PM, Jean-Baptiste
>>>>>> Onofré<jb...@nanthrax.net>wrote:
>>>>>>
>>>>>>> It makes sense, and I don't want to use the OfflineFeatureService
>>>>>>> (not
>>>>>>> require) but we will certainly have to decide to some "restriction"
>>>>>>> (for
>>>>>>> instance, what do we do if a feature is define in a feature ;)).
>>>>>>>
>>>>>>> Regards
>>>>>>> JB
>>>>>>>
>>>>>>>
>>>>>>> On 05/04/2012 08:18 PM, Christian Schneider wrote:
>>>>>>>
>>>>>>>> Hi JB,
>>>>>>>>
>>>>>>>> yes we do not use the real maven resolution. I thought about
>>>>>>>> changing it
>>>>>>>> but it would have too many dependencies.
>>>>>>>>
>>>>>>>> I did not mean to really use features. Rather to read the
>>>>>>>> feature file
>>>>>>>> instead of the startup.properties but still process and resolve
>>>>>>>> in the
>>>>>>>> same way as before. So this should not add
>>>>>>>> much complexity. We could use the OfflineFeatureService but I dont
>>>>>>>> think
>>>>>>>> it is really necessary.
>>>>>>>>
>>>>>>>> Christian
>>>>>>>>
>>>>>>>> Am 04.05.2012 19:24, schrieb Jean-Baptiste Onofré:
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> As reminder, in startup properties we don't really use mvn URL. I
>>>>>>>>> mean
>>>>>>>>> we construct a file URL from the mvn one, we don't really use Pax
>>>>>>>>> URL.
>>>>>>>>>
>>>>>>>>> Anyway, it sounds good to me. I don't think users use anything
>>>>>>>>> else
>>>>>>>>> than the startup.properties.
>>>>>>>>>
>>>>>>>>> Regarding a feature instead of startup.properties, it means
>>>>>>>>> that we
>>>>>>>>> have to load at least feature core. I'm not sure that it's a good
>>>>>>>>> idea
>>>>>>>>> because feature is already OSGi oriented, whereas in the main
>>>>>>>>> area we
>>>>>>>>> start the framework (so we are not in the "OSGi area"). It's
>>>>>>>>> possible
>>>>>>>>> but it means that even if we provide a features XML, it's not
>>>>>>>>> really
>>>>>>>>> the feature service that will be use but a FeatureStartup process
>>>>>>>>> (like OfflineFeatureService that we use in the Karaf maven
>>>>>>>>> plugin).
>>>>>>>>>
>>>>>>>>> So it means that we will have a dual bootstrap process which use
>>>>>>>>> feature:
>>>>>>>>> - the "startup" feature (which doesn't really use the feature
>>>>>>>>> service)
>>>>>>>>> - the "boot" feature (which uses the feature service)
>>>>>>>>>
>>>>>>>>> As the startup.properties is generated from a feature
>>>>>>>>> currently, it
>>>>>>>>> makes sense to directly use the feature.
>>>>>>>>>
>>>>>>>>> All depends the way that it will be implemented, but basically +1
>>>>>>>>>
>>>>>>>>> Regards
>>>>>>>>> JB
>>>>>>>>>
>>>>>>>>> On 05/04/2012 07:03 PM, Christian Schneider wrote:
>>>>>>>>>
>>>>>>>>>> Hi all,
>>>>>>>>>>
>>>>>>>>>> on startup we currently use the following procedure.
>>>>>>>>>>
>>>>>>>>>> We read property karaf.auto.start from the file
>>>>>>>>>> config.properties.
>>>>>>>>>> This can be either a list of bundles separated by spaces or
>>>>>>>>>> "startup.properties" or "all".
>>>>>>>>>> If it is all we replace karaf.auto.start with the list of all
>>>>>>>>>> bundles in
>>>>>>>>>> the system dir. I think this option does not really make much
>>>>>>>>>> sense.
>>>>>>>>>> If it is startup.properties then we replace karaf.auto.start with
>>>>>>>>>> the
>>>>>>>>>> list of bundles specified in the file startup.properties.
>>>>>>>>>> Additionally we either support mvn urls or paths which are
>>>>>>>>>> converted to
>>>>>>>>>> mvn urls.
>>>>>>>>>>
>>>>>>>>>> This all is quite a lot of variability of which we use none.
>>>>>>>>>>
>>>>>>>>>> I propose to replace this in two steps:
>>>>>>>>>>
>>>>>>>>>> 1. Remove the karaf.auto.start property and always load the
>>>>>>>>>> bundles from
>>>>>>>>>> startup.properties. Also only support mvn urls.
>>>>>>>>>> This makes the code in main cleaner and makes it easier for our
>>>>>>>>>> users to
>>>>>>>>>> understand how to change the startup bundles.
>>>>>>>>>>
>>>>>>>>>> 2. Remove the startup.properties and instead use a feature
>>>>>>>>>> name to
>>>>>>>>>> determine the list of bundles to load
>>>>>>>>>> The second step makes this even simpler and additionally we can
>>>>>>>>>> remove
>>>>>>>>>> the generation of the startup.properties in the karaf maven
>>>>>>>>>> plugin.
>>>>>>>>>>
>>>>>>>>>> So what do you think?
>>>>>>>>>>
>>>>>>>>>> Christian
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>> --
>>>>>>> Jean-Baptiste Onofré
>>>>>>> jbonofre@apache.org
>>>>>>> http://blog.nanthrax.net
>>>>>>> Talend - http://www.talend.com
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> ------------------------
>>>>>> Guillaume Nodet
>>>>>> ------------------------
>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>> ------------------------
>>>>>> FuseSource, Integration everywhere
>>>>>> http://fusesource.com
>>>>
>>>>
>>>
>>
>>
>
>

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

Re: [Discuss] Handling of initial bundles

["Jamie G." <ja...@gmail.com>]

+1 Achim. If one feels that they should start a discussion on the ML
over a proposed change, than its best to wait for the outcome of the
discussion before checking it in. If the code needs to be available
for ML review than please create a JIRA, and upload a patch or make a
git copy available.

Cheers,
Jamie

On Sun, May 6, 2012 at 8:16 PM, Achim Nierbeck <bc...@googlemail.com> wrote:
> To my concern the way main and the loading of karaf worked was "Good Enough
> for Now".
> I didn't see any issues to change the way it was working. So yes if
> something is good and properly
> working, don't Touch it. You might break it.
>
> Regarding committing your changes, I do find it disturbing, that you start a
> discussion without
> waiting for a result.
>
> regards, Achim
>
>
> Am 06.05.2012 22:28, schrieb Christian Schneider:
>
>> I did not have the intention to make this more complicated. I just removed
>> the other options.
>> So what exactly do you -1?
>>
>> I already committed the first step of the implementation and of course did
>> not introduce any new dependencies.
>> For the next step I plan to simply read the feature file instead of the
>> properties file. I don´t think that I need the feature service for that.
>>
>> Of course that means that the framework feature would only allow the list
>> of bundles and the startlevel for each bundle. So basically the same
>> that is supported in the startup.properties. Is that ok?
>>
>> Christian
>>
>> Am 06.05.2012 19:12, schrieb Achim Nierbeck:
>>>
>>> Even though you and Christian are certainly right that maven and OSGi
>>> work quite well if the versions are kept right, but this
>>> isn't the focus here. So coming back to the initial question I agree with
>>> Guillaume, to better keep the main class
>>> lean and simple therefore I give a -1 on this.
>>> I don't want to see any dependencies to a features service what so ever
>>> in main.
>>>
>>> Thanx, Achim
>>>
>>> Am 05.05.2012 11:33, schrieb Jean-Baptiste Onofré:
>>>>
>>>> Agree with Christian.
>>>>
>>>> Leveraging Pax URL in Karaf is a key feature (even if sometime we fake
>>>> the Pax URL usage, like in startup.properties URLs).
>>>>
>>>> Regards
>>>> JB
>>>>
>>>> On 05/05/2012 08:52 AM, Christian Schneider wrote:
>>>>>
>>>>> Well in this case you should use felix it uses a flat list of bundles
>>>>> :-)
>>>>>
>>>>> I think the maven centric aproach is the biggest benefit in karaf. Of
>>>>> course obr can help to make this even better but out there you almost
>>>>> find no obr repos.
>>>>> The big benefit with maven is that you have almost any lib available.
>>>>> You only need to know the artifact coordinates. For example it is great
>>>>> that you can install cxf or camle by just
>>>>> issuing two commands. How should that work without features that load
>>>>> artifacts from maven? As soon as all bundles are available in obr repos
>>>>> we can switch to this aproach but
>>>>> I think that is not the near future.
>>>>>
>>>>> I think the aproach of installing features and bundles from a company
>>>>> maven repo should be our recommended way of installing applications. I
>>>>> recommend to companies to split
>>>>> their development and deployment process at the maven repo. Developers
>>>>> build the sources and deploy the binaries to the company maven repo.
>>>>> Admins install from there. I think
>>>>> that is the cleanest technical aproach to devops we currently have.
>>>>> Of course this should include the use of the obr. As obr and maven
>>>>> often
>>>>> are incorporated in the same repository (like nexus or archiva) this
>>>>> should be achievable.
>>>>>
>>>>> Kar files are a dead end for me. They have their purpose when companies
>>>>> do not have a repository but they are completely anti modular. If you
>>>>> deploy two applications using kar files you have a lot of duplication
>>>>> and most of the advantages of osgi are gone.
>>>>>
>>>>> About the flar system repo. Why should that be a good idea? The good
>>>>> thing about the system repo as a maven repo is that it mimics the
>>>>> central repo. So users can be sure that our system repo is just a
>>>>> cache.
>>>>> All the artifacts in there are the same as in central. So the user
>>>>> knows
>>>>> that each of these jars is the "official" version. This is very helpful
>>>>> for example for doing licensing audits.
>>>>>
>>>>> Btw. I think maven and osgi are very compatible on the lowest level.
>>>>> Maven can supply single artifacts very well. It is only the dependency
>>>>> resolution that is not compatible but obr can help out with that.
>>>>>
>>>>> Christian
>>>>>
>>>>> Am 05.05.2012 04:04, schrieb David Jencks:
>>>>>>
>>>>>> I think we should make karaf much less maven centric including:
>>>>>>
>>>>>> -- system repo is flat, not maven structured, with file names enforced
>>>>>> as bundle-symbolic-name_bundle-version.jar. startup.properties can
>>>>>> then just have jar-name=start-level.
>>>>>>
>>>>>> -- kar files use similar flat internal repo
>>>>>>
>>>>>> -- non-kar features deprecated
>>>>>>
>>>>>> -- heavily encourage use of obr.
>>>>>>
>>>>>> maven and osgi are really not very compatible and trying to pretend
>>>>>> they are IMO leads to too many problems and suppresses the usefulness
>>>>>> of osgi.
>>>>>>
>>>>>> thanks
>>>>>> david jencks
>>>>>>
>>>>>> On May 4, 2012, at 12:46 PM, Guillaume Nodet wrote:
>>>>>>
>>>>>>> Please, keep the main file lean and simple, no dependencies on url
>>>>>>> handlers
>>>>>>> or features or OBR or anything.
>>>>>>> The less interactions we have with the framework, the less fixes
>>>>>>> we'll to
>>>>>>> do there and the more stable it will be.
>>>>>>> The idea is to bootstrap the osgi framework, all the real
>>>>>>> provisioning
>>>>>>> should be done in the osgi framework itself using the feature service
>>>>>>> or
>>>>>>> obr or anything else that is required.
>>>>>>>
>>>>>>> On Fri, May 4, 2012 at 8:35 PM, Jean-Baptiste
>>>>>>> Onofré<jb...@nanthrax.net>wrote:
>>>>>>>
>>>>>>>> It makes sense, and I don't want to use the OfflineFeatureService
>>>>>>>> (not
>>>>>>>> require) but we will certainly have to decide to some "restriction"
>>>>>>>> (for
>>>>>>>> instance, what do we do if a feature is define in a feature ;)).
>>>>>>>>
>>>>>>>> Regards
>>>>>>>> JB
>>>>>>>>
>>>>>>>>
>>>>>>>> On 05/04/2012 08:18 PM, Christian Schneider wrote:
>>>>>>>>
>>>>>>>>> Hi JB,
>>>>>>>>>
>>>>>>>>> yes we do not use the real maven resolution. I thought about
>>>>>>>>> changing it
>>>>>>>>> but it would have too many dependencies.
>>>>>>>>>
>>>>>>>>> I did not mean to really use features. Rather to read the feature
>>>>>>>>> file
>>>>>>>>> instead of the startup.properties but still process and resolve in
>>>>>>>>> the
>>>>>>>>> same way as before. So this should not add
>>>>>>>>> much complexity. We could use the OfflineFeatureService but I dont
>>>>>>>>> think
>>>>>>>>> it is really necessary.
>>>>>>>>>
>>>>>>>>> Christian
>>>>>>>>>
>>>>>>>>> Am 04.05.2012 19:24, schrieb Jean-Baptiste Onofré:
>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> As reminder, in startup properties we don't really use mvn URL. I
>>>>>>>>>> mean
>>>>>>>>>> we construct a file URL from the mvn one, we don't really use Pax
>>>>>>>>>> URL.
>>>>>>>>>>
>>>>>>>>>> Anyway, it sounds good to me. I don't think users use anything
>>>>>>>>>> else
>>>>>>>>>> than the startup.properties.
>>>>>>>>>>
>>>>>>>>>> Regarding a feature instead of startup.properties, it means that
>>>>>>>>>> we
>>>>>>>>>> have to load at least feature core. I'm not sure that it's a good
>>>>>>>>>> idea
>>>>>>>>>> because feature is already OSGi oriented, whereas in the main area
>>>>>>>>>> we
>>>>>>>>>> start the framework (so we are not in the "OSGi area"). It's
>>>>>>>>>> possible
>>>>>>>>>> but it means that even if we provide a features XML, it's not
>>>>>>>>>> really
>>>>>>>>>> the feature service that will be use but a FeatureStartup process
>>>>>>>>>> (like OfflineFeatureService that we use in the Karaf maven
>>>>>>>>>> plugin).
>>>>>>>>>>
>>>>>>>>>> So it means that we will have a dual bootstrap process which use
>>>>>>>>>> feature:
>>>>>>>>>> - the "startup" feature (which doesn't really use the feature
>>>>>>>>>> service)
>>>>>>>>>> - the "boot" feature (which uses the feature service)
>>>>>>>>>>
>>>>>>>>>> As the startup.properties is generated from a feature currently,
>>>>>>>>>> it
>>>>>>>>>> makes sense to directly use the feature.
>>>>>>>>>>
>>>>>>>>>> All depends the way that it will be implemented, but basically +1
>>>>>>>>>>
>>>>>>>>>> Regards
>>>>>>>>>> JB
>>>>>>>>>>
>>>>>>>>>> On 05/04/2012 07:03 PM, Christian Schneider wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi all,
>>>>>>>>>>>
>>>>>>>>>>> on startup we currently use the following procedure.
>>>>>>>>>>>
>>>>>>>>>>> We read property karaf.auto.start from the file
>>>>>>>>>>> config.properties.
>>>>>>>>>>> This can be either a list of bundles separated by spaces or
>>>>>>>>>>> "startup.properties" or "all".
>>>>>>>>>>> If it is all we replace karaf.auto.start with the list of all
>>>>>>>>>>> bundles in
>>>>>>>>>>> the system dir. I think this option does not really make much
>>>>>>>>>>> sense.
>>>>>>>>>>> If it is startup.properties then we replace karaf.auto.start with
>>>>>>>>>>> the
>>>>>>>>>>> list of bundles specified in the file startup.properties.
>>>>>>>>>>> Additionally we either support mvn urls or paths which are
>>>>>>>>>>> converted to
>>>>>>>>>>> mvn urls.
>>>>>>>>>>>
>>>>>>>>>>> This all is quite a lot of variability of which we use none.
>>>>>>>>>>>
>>>>>>>>>>> I propose to replace this in two steps:
>>>>>>>>>>>
>>>>>>>>>>> 1. Remove the karaf.auto.start property and always load the
>>>>>>>>>>> bundles from
>>>>>>>>>>> startup.properties. Also only support mvn urls.
>>>>>>>>>>> This makes the code in main cleaner and makes it easier for our
>>>>>>>>>>> users to
>>>>>>>>>>> understand how to change the startup bundles.
>>>>>>>>>>>
>>>>>>>>>>> 2. Remove the startup.properties and instead use a feature name
>>>>>>>>>>> to
>>>>>>>>>>> determine the list of bundles to load
>>>>>>>>>>> The second step makes this even simpler and additionally we can
>>>>>>>>>>> remove
>>>>>>>>>>> the generation of the startup.properties in the karaf maven
>>>>>>>>>>> plugin.
>>>>>>>>>>>
>>>>>>>>>>> So what do you think?
>>>>>>>>>>>
>>>>>>>>>>> Christian
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>> --
>>>>>>>> Jean-Baptiste Onofré
>>>>>>>> jbonofre@apache.org
>>>>>>>> http://blog.nanthrax.net
>>>>>>>> Talend - http://www.talend.com
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> ------------------------
>>>>>>> Guillaume Nodet
>>>>>>> ------------------------
>>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>>> ------------------------
>>>>>>> FuseSource, Integration everywhere
>>>>>>> http://fusesource.com
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>>
>
>
> --
> - Apache Karaf<http://karaf.apache.org/>  Committer&  PMC
> - OPS4J Pax Web<http://wiki.ops4j.org/display/paxweb/Pax+Web/>    Committer&
>  Project Lead
> - Blog<http://notizblog.nierbeck.de/>
>

Re: [Discuss] Handling of initial bundles

[Achim Nierbeck <bc...@googlemail.com>]

Just one reminder here,
starting a discussion on a Friday night and expecting all people to 
react till Sunday evening.
Nope this is a no-go.

I still have to say I don't think I like the idea of a "Artificial" 
features resolver, I actually liked the
way the startup.properties worked.

David might be right to remove those "fake-maven" notation, though I 
have to say
since most all other bundles are somehow "maven" managed I'm fine with 
the way it worked, but
it should also work with plain path.

Regarding your split up of main into a bunch modules, I don't see the 
benefit there, it was quite
good the way it was, and I fully agree with Guillaume here.

but this is just my 2 cents .....




Am 07.05.2012 08:18, schrieb Christian Schneider:
> I waited for almost 2 days. Your mail came just shortly after my 
> commit. So I thought the dicussion was settled.
> You are right though that I could have waited a little longer. I only 
> committed the first part though and I think that I incorporated all 
> feedback into the change.
>
> So let me summarize the feedback and how I included it:
>
> - There was only positive feedback about having only the 
> startup.properties and not the properties in the config.properties to 
> control the startup bundles. So I think  we agreed on this.
> - David gave the feedback that he would like the startup.properties to 
> be a flat list of bundles. While I don´t agree that this is a good 
> idea this is absolutely possible. I used mvn urls in
> startup.properties and for the framework but you can use relative 
> paths. So if you have the startup bundles directly below system you 
> can just refer to them by file name in  the startup.properties.
> I also used an interface ArtifactResolver that allows to easily 
> replace this behaviour.
> - Guillaume and you gave the feedback to not introduce new 
> dependencies and I did not
>
> So functionally I mainly simplified and restructured the Main code. It 
> went down from about 950 lines of code to about 400. I think the code 
> is much more readable and maintainable now.
>
> There is one nice new feature that is possible now. You can specify 
> the path to your local maven repo in bundle.locations. In this case 
> karaf can startup completely without a system directory and directly 
> uses the
> local repo. I think this is really nice for developing. As you do not 
> have to do the assembly step when changing the source of modules in 
> startup.properties.
>
> So again sorry for committing too early but I worked really hard on 
> this the weekend. In the end I had a really nice solution that at this 
> point I think fitted into all the feedback.
>
> Christian
>
> Am 07.05.2012 00:46, schrieb Achim Nierbeck:
>> To my concern the way main and the loading of karaf worked was "Good 
>> Enough for Now".
>> I didn't see any issues to change the way it was working. So yes if 
>> something is good and properly
>> working, don't Touch it. You might break it.
>>
>> Regarding committing your changes, I do find it disturbing, that you 
>> start a discussion without
>> waiting for a result.
>>
>> regards, Achim
>>
>>
>> Am 06.05.2012 22:28, schrieb Christian Schneider:
>>> I did not have the intention to make this more complicated. I just 
>>> removed the other options.
>>> So what exactly do you -1?
>>>
>>> I already committed the first step of the implementation and of 
>>> course did not introduce any new dependencies.
>>> For the next step I plan to simply read the feature file instead of 
>>> the properties file. I don´t think that I need the feature service 
>>> for that.
>>>
>>> Of course that means that the framework feature would only allow the 
>>> list of bundles and the startlevel for each bundle. So basically the 
>>> same
>>> that is supported in the startup.properties. Is that ok?
>>>
>>> Christian
>>>
>>> Am 06.05.2012 19:12, schrieb Achim Nierbeck:
>>>> Even though you and Christian are certainly right that maven and 
>>>> OSGi work quite well if the versions are kept right, but this
>>>> isn't the focus here. So coming back to the initial question I 
>>>> agree with Guillaume, to better keep the main class
>>>> lean and simple therefore I give a -1 on this.
>>>> I don't want to see any dependencies to a features service what so 
>>>> ever in main.
>>>>
>>>> Thanx, Achim
>>>>
>>>> Am 05.05.2012 11:33, schrieb Jean-Baptiste Onofré:
>>>>> Agree with Christian.
>>>>>
>>>>> Leveraging Pax URL in Karaf is a key feature (even if sometime we 
>>>>> fake the Pax URL usage, like in startup.properties URLs).
>>>>>
>>>>> Regards
>>>>> JB
>>>>>
>>>>> On 05/05/2012 08:52 AM, Christian Schneider wrote:
>>>>>> Well in this case you should use felix it uses a flat list of 
>>>>>> bundles :-)
>>>>>>
>>>>>> I think the maven centric aproach is the biggest benefit in 
>>>>>> karaf. Of
>>>>>> course obr can help to make this even better but out there you 
>>>>>> almost
>>>>>> find no obr repos.
>>>>>> The big benefit with maven is that you have almost any lib 
>>>>>> available.
>>>>>> You only need to know the artifact coordinates. For example it is 
>>>>>> great
>>>>>> that you can install cxf or camle by just
>>>>>> issuing two commands. How should that work without features that 
>>>>>> load
>>>>>> artifacts from maven? As soon as all bundles are available in obr 
>>>>>> repos
>>>>>> we can switch to this aproach but
>>>>>> I think that is not the near future.
>>>>>>
>>>>>> I think the aproach of installing features and bundles from a 
>>>>>> company
>>>>>> maven repo should be our recommended way of installing 
>>>>>> applications. I
>>>>>> recommend to companies to split
>>>>>> their development and deployment process at the maven repo. 
>>>>>> Developers
>>>>>> build the sources and deploy the binaries to the company maven repo.
>>>>>> Admins install from there. I think
>>>>>> that is the cleanest technical aproach to devops we currently have.
>>>>>> Of course this should include the use of the obr. As obr and 
>>>>>> maven often
>>>>>> are incorporated in the same repository (like nexus or archiva) this
>>>>>> should be achievable.
>>>>>>
>>>>>> Kar files are a dead end for me. They have their purpose when 
>>>>>> companies
>>>>>> do not have a repository but they are completely anti modular. If 
>>>>>> you
>>>>>> deploy two applications using kar files you have a lot of 
>>>>>> duplication
>>>>>> and most of the advantages of osgi are gone.
>>>>>>
>>>>>> About the flar system repo. Why should that be a good idea? The good
>>>>>> thing about the system repo as a maven repo is that it mimics the
>>>>>> central repo. So users can be sure that our system repo is just a 
>>>>>> cache.
>>>>>> All the artifacts in there are the same as in central. So the 
>>>>>> user knows
>>>>>> that each of these jars is the "official" version. This is very 
>>>>>> helpful
>>>>>> for example for doing licensing audits.
>>>>>>
>>>>>> Btw. I think maven and osgi are very compatible on the lowest level.
>>>>>> Maven can supply single artifacts very well. It is only the 
>>>>>> dependency
>>>>>> resolution that is not compatible but obr can help out with that.
>>>>>>
>>>>>> Christian
>>>>>>
>>>>>> Am 05.05.2012 04:04, schrieb David Jencks:
>>>>>>> I think we should make karaf much less maven centric including:
>>>>>>>
>>>>>>> -- system repo is flat, not maven structured, with file names 
>>>>>>> enforced
>>>>>>> as bundle-symbolic-name_bundle-version.jar. startup.properties can
>>>>>>> then just have jar-name=start-level.
>>>>>>>
>>>>>>> -- kar files use similar flat internal repo
>>>>>>>
>>>>>>> -- non-kar features deprecated
>>>>>>>
>>>>>>> -- heavily encourage use of obr.
>>>>>>>
>>>>>>> maven and osgi are really not very compatible and trying to pretend
>>>>>>> they are IMO leads to too many problems and suppresses the 
>>>>>>> usefulness
>>>>>>> of osgi.
>>>>>>>
>>>>>>> thanks
>>>>>>> david jencks
>>>>>>>
>>>>>>> On May 4, 2012, at 12:46 PM, Guillaume Nodet wrote:
>>>>>>>
>>>>>>>> Please, keep the main file lean and simple, no dependencies on url
>>>>>>>> handlers
>>>>>>>> or features or OBR or anything.
>>>>>>>> The less interactions we have with the framework, the less fixes
>>>>>>>> we'll to
>>>>>>>> do there and the more stable it will be.
>>>>>>>> The idea is to bootstrap the osgi framework, all the real 
>>>>>>>> provisioning
>>>>>>>> should be done in the osgi framework itself using the feature 
>>>>>>>> service or
>>>>>>>> obr or anything else that is required.
>>>>>>>>
>>>>>>>> On Fri, May 4, 2012 at 8:35 PM, Jean-Baptiste
>>>>>>>> Onofré<jb...@nanthrax.net>wrote:
>>>>>>>>
>>>>>>>>> It makes sense, and I don't want to use the 
>>>>>>>>> OfflineFeatureService (not
>>>>>>>>> require) but we will certainly have to decide to some 
>>>>>>>>> "restriction"
>>>>>>>>> (for
>>>>>>>>> instance, what do we do if a feature is define in a feature ;)).
>>>>>>>>>
>>>>>>>>> Regards
>>>>>>>>> JB
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 05/04/2012 08:18 PM, Christian Schneider wrote:
>>>>>>>>>
>>>>>>>>>> Hi JB,
>>>>>>>>>>
>>>>>>>>>> yes we do not use the real maven resolution. I thought about
>>>>>>>>>> changing it
>>>>>>>>>> but it would have too many dependencies.
>>>>>>>>>>
>>>>>>>>>> I did not mean to really use features. Rather to read the 
>>>>>>>>>> feature file
>>>>>>>>>> instead of the startup.properties but still process and 
>>>>>>>>>> resolve in the
>>>>>>>>>> same way as before. So this should not add
>>>>>>>>>> much complexity. We could use the OfflineFeatureService but I 
>>>>>>>>>> dont
>>>>>>>>>> think
>>>>>>>>>> it is really necessary.
>>>>>>>>>>
>>>>>>>>>> Christian
>>>>>>>>>>
>>>>>>>>>> Am 04.05.2012 19:24, schrieb Jean-Baptiste Onofré:
>>>>>>>>>>
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> As reminder, in startup properties we don't really use mvn 
>>>>>>>>>>> URL. I
>>>>>>>>>>> mean
>>>>>>>>>>> we construct a file URL from the mvn one, we don't really 
>>>>>>>>>>> use Pax
>>>>>>>>>>> URL.
>>>>>>>>>>>
>>>>>>>>>>> Anyway, it sounds good to me. I don't think users use 
>>>>>>>>>>> anything else
>>>>>>>>>>> than the startup.properties.
>>>>>>>>>>>
>>>>>>>>>>> Regarding a feature instead of startup.properties, it means 
>>>>>>>>>>> that we
>>>>>>>>>>> have to load at least feature core. I'm not sure that it's a 
>>>>>>>>>>> good
>>>>>>>>>>> idea
>>>>>>>>>>> because feature is already OSGi oriented, whereas in the 
>>>>>>>>>>> main area we
>>>>>>>>>>> start the framework (so we are not in the "OSGi area"). It's 
>>>>>>>>>>> possible
>>>>>>>>>>> but it means that even if we provide a features XML, it's 
>>>>>>>>>>> not really
>>>>>>>>>>> the feature service that will be use but a FeatureStartup 
>>>>>>>>>>> process
>>>>>>>>>>> (like OfflineFeatureService that we use in the Karaf maven 
>>>>>>>>>>> plugin).
>>>>>>>>>>>
>>>>>>>>>>> So it means that we will have a dual bootstrap process which 
>>>>>>>>>>> use
>>>>>>>>>>> feature:
>>>>>>>>>>> - the "startup" feature (which doesn't really use the feature
>>>>>>>>>>> service)
>>>>>>>>>>> - the "boot" feature (which uses the feature service)
>>>>>>>>>>>
>>>>>>>>>>> As the startup.properties is generated from a feature 
>>>>>>>>>>> currently, it
>>>>>>>>>>> makes sense to directly use the feature.
>>>>>>>>>>>
>>>>>>>>>>> All depends the way that it will be implemented, but 
>>>>>>>>>>> basically +1
>>>>>>>>>>>
>>>>>>>>>>> Regards
>>>>>>>>>>> JB
>>>>>>>>>>>
>>>>>>>>>>> On 05/04/2012 07:03 PM, Christian Schneider wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>
>>>>>>>>>>>> on startup we currently use the following procedure.
>>>>>>>>>>>>
>>>>>>>>>>>> We read property karaf.auto.start from the file 
>>>>>>>>>>>> config.properties.
>>>>>>>>>>>> This can be either a list of bundles separated by spaces or
>>>>>>>>>>>> "startup.properties" or "all".
>>>>>>>>>>>> If it is all we replace karaf.auto.start with the list of all
>>>>>>>>>>>> bundles in
>>>>>>>>>>>> the system dir. I think this option does not really make 
>>>>>>>>>>>> much sense.
>>>>>>>>>>>> If it is startup.properties then we replace 
>>>>>>>>>>>> karaf.auto.start with
>>>>>>>>>>>> the
>>>>>>>>>>>> list of bundles specified in the file startup.properties.
>>>>>>>>>>>> Additionally we either support mvn urls or paths which are
>>>>>>>>>>>> converted to
>>>>>>>>>>>> mvn urls.
>>>>>>>>>>>>
>>>>>>>>>>>> This all is quite a lot of variability of which we use none.
>>>>>>>>>>>>
>>>>>>>>>>>> I propose to replace this in two steps:
>>>>>>>>>>>>
>>>>>>>>>>>> 1. Remove the karaf.auto.start property and always load the
>>>>>>>>>>>> bundles from
>>>>>>>>>>>> startup.properties. Also only support mvn urls.
>>>>>>>>>>>> This makes the code in main cleaner and makes it easier for 
>>>>>>>>>>>> our
>>>>>>>>>>>> users to
>>>>>>>>>>>> understand how to change the startup bundles.
>>>>>>>>>>>>
>>>>>>>>>>>> 2. Remove the startup.properties and instead use a feature 
>>>>>>>>>>>> name to
>>>>>>>>>>>> determine the list of bundles to load
>>>>>>>>>>>> The second step makes this even simpler and additionally we 
>>>>>>>>>>>> can
>>>>>>>>>>>> remove
>>>>>>>>>>>> the generation of the startup.properties in the karaf maven 
>>>>>>>>>>>> plugin.
>>>>>>>>>>>>
>>>>>>>>>>>> So what do you think?
>>>>>>>>>>>>
>>>>>>>>>>>> Christian
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> -- 
>>>>>>>>> Jean-Baptiste Onofré
>>>>>>>>> jbonofre@apache.org
>>>>>>>>> http://blog.nanthrax.net
>>>>>>>>> Talend - http://www.talend.com
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> -- 
>>>>>>>> ------------------------
>>>>>>>> Guillaume Nodet
>>>>>>>> ------------------------
>>>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>>>> ------------------------
>>>>>>>> FuseSource, Integration everywhere
>>>>>>>> http://fusesource.com
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>


-- 
- Apache Karaf<http://karaf.apache.org/>  Committer&  PMC
- OPS4J Pax Web<http://wiki.ops4j.org/display/paxweb/Pax+Web/>    Committer&  Project Lead
- Blog<http://notizblog.nierbeck.de/>

Re: [Discuss] Handling of initial bundles

[Christian Schneider <ch...@die-schneider.net>]

I know. I was just refering to that I could do it in one of those two 
ways but without using the actual code from the feature service to keep 
dependencies low.

Christian

Am 07.05.2012 09:37, schrieb Jean-Baptiste Onofré:
> Hi Christian,
>
> FYI, on trunk, feature descriptor is already read by JAXB (take a look 
> in the karaf-maven-plugin, you will see the JAXB marshaling).
>
> Regards
> JB 

Re: [Discuss] Handling of initial bundles

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

Hi Christian,

FYI, on trunk, feature descriptor is already read by JAXB (take a look 
in the karaf-maven-plugin, you will see the JAXB marshaling).

Regards
JB

On 05/07/2012 09:35 AM, Christian Schneider wrote:
> You are right of course that splitting the code into more files does not
> necessarily make it more readable.
>
> So what I did was to mainly the code more readable. I think in the
> current state also someone who sees the code
> for the first time should be able to understand it pretty fast. So for
> example the main and launch methods explain the big picture without
> going into the details.
>
> http://svn.apache.org/repos/asf/karaf/trunk/main/src/main/java/org/apache/karaf/main/Main.java
>
>
> About the dependencies. I fully agree that we should keep the main code
> simple and that we should not introduce more dependencies.
> After all it should just be the bootstrap and hand over to the real OSGi
> code as soon as possible.
>
> So what I thought about using a feature is the following:
>
> We currently have startup.properties with:
> mvn\:org.ops4j.base/ops4j-base-lang/1.3.0 = 5
> mvn\:org.apache.servicemix.bundles/org.apache.servicemix.bundles.junit/3.8.2_4
> = 5
> ...
>
> We generate this from a pom.xml and a feature.xml that are located in
> framework.
>
> So we already a an equivalent feature:
>
> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
> <features
> xmlns="http://karaf.apache.org/xmlns/features/v1.0.0"name="framework-3.0.0-SNAPSHOT">
>
> <feature name="framework"version="3.0.0-SNAPSHOT"description="Karaf core
> feature">
> <bundle
> start-level="5"start="true">mvn:org.ops4j.base/ops4j-base-lang/1.3.0</bundle>
>
> <bundle
> start-level="5"start="true">mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.junit/3.8.2_4</bundle>
>
> ...
> </feature>
> </features>
>
> What I planned is to read the feature using jaxb or even plain dom and
> xpath in the simplest way possible to read the framework feature and
> extract the
> same informations we have in startup.properties. We could have a
> property in the config.properties that specifies the mvn url of the
> framework feature file and the
> feature name.
>
> This should be just some few lines of code. Additionally we can keep the
> startup.properties loading code and use it if there is a
> startup.properties file. I would prefer to
> completely remove the startup.properties but if David needs it we can
> keep it.
>
> The advantage of removing startup.properties would be that we can also
> remove the functionality of the startup.properties generation which is
> quite complicated as it needs to
> use the feature service code outside of OSGi.
>
> Christian
>
> Am 07.05.2012 09:00, schrieb Guillaume Nodet:
>> Christian, I don't care about the fact that the main class is 3000
>> lines or
>> split into 30 files of 100 lines each.
>> What I care about is that the main jar is so simple so we don't ever have
>> to touch it.
>> The main reason is that while you can update all the bundles in the osgi
>> framework, if you have to change the main jar, you need a manual
>> intervention.
>> So the less code we have in main the better. This implies that we don't
>> handle features or OBR there and this also implies that we should not try
>> to do a real maven resolution here too (but that's not the case right now
>> afaik).
>>
>> As for simplifying the startup.properties and config.properties handling,
>> that sounds like a good idea. The original code comes from Felix directly
>> and only had minor modifications to do what we want, but some features
>> are
>> clearly not used.
>>
>>
>

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

Re: [Discuss] Handling of initial bundles

[Christian Schneider <ch...@die-schneider.net>]

You are right of course that splitting the code into more files does not 
necessarily make it more readable.

So what I did was to mainly the code more readable. I think in the 
current state also someone who sees the code
for the first time should be able to understand it pretty fast. So for 
example the main and launch methods explain the big picture without
going into the details.

http://svn.apache.org/repos/asf/karaf/trunk/main/src/main/java/org/apache/karaf/main/Main.java

About the dependencies. I fully agree that we should keep the main code 
simple and that we should not introduce more dependencies.
After all it should just be the bootstrap and hand over to the real OSGi 
code as soon as possible.

So what I thought about using a feature is the following:

We currently have startup.properties with:
mvn\:org.ops4j.base/ops4j-base-lang/1.3.0 = 5
mvn\:org.apache.servicemix.bundles/org.apache.servicemix.bundles.junit/3.8.2_4 
= 5
...

We generate this from a pom.xml and a feature.xml that are located in 
framework.

So we already a an equivalent feature:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<features  xmlns="http://karaf.apache.org/xmlns/features/v1.0.0"name="framework-3.0.0-SNAPSHOT">
     <feature  name="framework"version="3.0.0-SNAPSHOT"description="Karaf core feature">
         <bundle  start-level="5"start="true">mvn:org.ops4j.base/ops4j-base-lang/1.3.0</bundle>
         <bundle  start-level="5"start="true">mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.junit/3.8.2_4</bundle>
...
     </feature>
</features>

What I planned is to read the feature using jaxb or even plain dom and xpath in the simplest way possible to read the framework feature and extract the
same informations we have in startup.properties. We could have a property in the config.properties that specifies the mvn url of the framework feature file and the
feature name.

This should be just some few lines of code. Additionally we can keep the startup.properties loading code and use it if there is a startup.properties file.  I would prefer to
completely remove the startup.properties but if David needs it we can keep it.

The advantage of removing startup.properties would be that we can also remove the functionality of the startup.properties generation which is quite complicated as it needs to
use the feature service code outside of OSGi.

Christian

Am 07.05.2012 09:00, schrieb Guillaume Nodet:
> Christian, I don't care about the fact that the main class is 3000 lines or
> split into 30 files of 100 lines each.
> What I care about is that the main jar is so simple so we don't ever have
> to touch it.
> The main reason is that while you can update all the bundles in the osgi
> framework, if you have to change the main jar, you need a manual
> intervention.
> So the less code we have in main the better.  This implies that we don't
> handle features or OBR there and this also implies that we should not try
> to do a real maven resolution here too (but that's not the case right now
> afaik).
>
> As for simplifying the startup.properties and config.properties handling,
> that sounds like a good idea.  The original code comes from Felix directly
> and only had minor modifications to do what we want, but some features are
> clearly not used.
>
>

-- 

Christian Schneider
http://www.liquid-reality.de

Open Source Architect
Talend Application Integration Division http://www.talend.com

Re: [Discuss] Handling of initial bundles

[Guillaume Nodet <gn...@gmail.com>]

Christian, I don't care about the fact that the main class is 3000 lines or
split into 30 files of 100 lines each.
What I care about is that the main jar is so simple so we don't ever have
to touch it.
The main reason is that while you can update all the bundles in the osgi
framework, if you have to change the main jar, you need a manual
intervention.
So the less code we have in main the better.  This implies that we don't
handle features or OBR there and this also implies that we should not try
to do a real maven resolution here too (but that's not the case right now
afaik).

As for simplifying the startup.properties and config.properties handling,
that sounds like a good idea.  The original code comes from Felix directly
and only had minor modifications to do what we want, but some features are
clearly not used.

On Mon, May 7, 2012 at 8:18 AM, Christian Schneider <chris@die-schneider.net
> wrote:

> I waited for almost 2 days. Your mail came just shortly after my commit.
> So I thought the dicussion was settled.
> You are right though that I could have waited a little longer. I only
> committed the first part though and I think that I incorporated all
> feedback into the change.
>
> So let me summarize the feedback and how I included it:
>
> - There was only positive feedback about having only the
> startup.properties and not the properties in the config.properties to
> control the startup bundles. So I think  we agreed on this.
> - David gave the feedback that he would like the startup.properties to be
> a flat list of bundles. While I don´t agree that this is a good idea this
> is absolutely possible. I used mvn urls in
> startup.properties and for the framework but you can use relative paths.
> So if you have the startup bundles directly below system you can just refer
> to them by file name in  the startup.properties.
> I also used an interface ArtifactResolver that allows to easily replace
> this behaviour.
> - Guillaume and you gave the feedback to not introduce new dependencies
> and I did not
>
> So functionally I mainly simplified and restructured the Main code. It
> went down from about 950 lines of code to about 400. I think the code is
> much more readable and maintainable now.
>
> There is one nice new feature that is possible now. You can specify the
> path to your local maven repo in bundle.locations. In this case karaf can
> startup completely without a system directory and directly uses the
> local repo. I think this is really nice for developing. As you do not have
> to do the assembly step when changing the source of modules in
> startup.properties.
>
> So again sorry for committing too early but I worked really hard on this
> the weekend. In the end I had a really nice solution that at this point I
> think fitted into all the feedback.
>
> Christian
>
> Am 07.05.2012 00:46, schrieb Achim Nierbeck:
>
>  To my concern the way main and the loading of karaf worked was "Good
>> Enough for Now".
>> I didn't see any issues to change the way it was working. So yes if
>> something is good and properly
>> working, don't Touch it. You might break it.
>>
>> Regarding committing your changes, I do find it disturbing, that you
>> start a discussion without
>> waiting for a result.
>>
>> regards, Achim
>>
>>
>> Am 06.05.2012 22:28, schrieb Christian Schneider:
>>
>>> I did not have the intention to make this more complicated. I just
>>> removed the other options.
>>> So what exactly do you -1?
>>>
>>> I already committed the first step of the implementation and of course
>>> did not introduce any new dependencies.
>>> For the next step I plan to simply read the feature file instead of the
>>> properties file. I don´t think that I need the feature service for that.
>>>
>>> Of course that means that the framework feature would only allow the
>>> list of bundles and the startlevel for each bundle. So basically the same
>>> that is supported in the startup.properties. Is that ok?
>>>
>>> Christian
>>>
>>> Am 06.05.2012 19:12, schrieb Achim Nierbeck:
>>>
>>>> Even though you and Christian are certainly right that maven and OSGi
>>>> work quite well if the versions are kept right, but this
>>>> isn't the focus here. So coming back to the initial question I agree
>>>> with Guillaume, to better keep the main class
>>>> lean and simple therefore I give a -1 on this.
>>>> I don't want to see any dependencies to a features service what so ever
>>>> in main.
>>>>
>>>> Thanx, Achim
>>>>
>>>> Am 05.05.2012 11:33, schrieb Jean-Baptiste Onofré:
>>>>
>>>>> Agree with Christian.
>>>>>
>>>>> Leveraging Pax URL in Karaf is a key feature (even if sometime we fake
>>>>> the Pax URL usage, like in startup.properties URLs).
>>>>>
>>>>> Regards
>>>>> JB
>>>>>
>>>>> On 05/05/2012 08:52 AM, Christian Schneider wrote:
>>>>>
>>>>>> Well in this case you should use felix it uses a flat list of bundles
>>>>>> :-)
>>>>>>
>>>>>> I think the maven centric aproach is the biggest benefit in karaf. Of
>>>>>> course obr can help to make this even better but out there you almost
>>>>>> find no obr repos.
>>>>>> The big benefit with maven is that you have almost any lib available.
>>>>>> You only need to know the artifact coordinates. For example it is
>>>>>> great
>>>>>> that you can install cxf or camle by just
>>>>>> issuing two commands. How should that work without features that load
>>>>>> artifacts from maven? As soon as all bundles are available in obr
>>>>>> repos
>>>>>> we can switch to this aproach but
>>>>>> I think that is not the near future.
>>>>>>
>>>>>> I think the aproach of installing features and bundles from a company
>>>>>> maven repo should be our recommended way of installing applications. I
>>>>>> recommend to companies to split
>>>>>> their development and deployment process at the maven repo. Developers
>>>>>> build the sources and deploy the binaries to the company maven repo.
>>>>>> Admins install from there. I think
>>>>>> that is the cleanest technical aproach to devops we currently have.
>>>>>> Of course this should include the use of the obr. As obr and maven
>>>>>> often
>>>>>> are incorporated in the same repository (like nexus or archiva) this
>>>>>> should be achievable.
>>>>>>
>>>>>> Kar files are a dead end for me. They have their purpose when
>>>>>> companies
>>>>>> do not have a repository but they are completely anti modular. If you
>>>>>> deploy two applications using kar files you have a lot of duplication
>>>>>> and most of the advantages of osgi are gone.
>>>>>>
>>>>>> About the flar system repo. Why should that be a good idea? The good
>>>>>> thing about the system repo as a maven repo is that it mimics the
>>>>>> central repo. So users can be sure that our system repo is just a
>>>>>> cache.
>>>>>> All the artifacts in there are the same as in central. So the user
>>>>>> knows
>>>>>> that each of these jars is the "official" version. This is very
>>>>>> helpful
>>>>>> for example for doing licensing audits.
>>>>>>
>>>>>> Btw. I think maven and osgi are very compatible on the lowest level.
>>>>>> Maven can supply single artifacts very well. It is only the dependency
>>>>>> resolution that is not compatible but obr can help out with that.
>>>>>>
>>>>>> Christian
>>>>>>
>>>>>> Am 05.05.2012 04:04, schrieb David Jencks:
>>>>>>
>>>>>>> I think we should make karaf much less maven centric including:
>>>>>>>
>>>>>>> -- system repo is flat, not maven structured, with file names
>>>>>>> enforced
>>>>>>> as bundle-symbolic-name_bundle-**version.jar. startup.properties can
>>>>>>> then just have jar-name=start-level.
>>>>>>>
>>>>>>> -- kar files use similar flat internal repo
>>>>>>>
>>>>>>> -- non-kar features deprecated
>>>>>>>
>>>>>>> -- heavily encourage use of obr.
>>>>>>>
>>>>>>> maven and osgi are really not very compatible and trying to pretend
>>>>>>> they are IMO leads to too many problems and suppresses the usefulness
>>>>>>> of osgi.
>>>>>>>
>>>>>>> thanks
>>>>>>> david jencks
>>>>>>>
>>>>>>> On May 4, 2012, at 12:46 PM, Guillaume Nodet wrote:
>>>>>>>
>>>>>>>  Please, keep the main file lean and simple, no dependencies on url
>>>>>>>> handlers
>>>>>>>> or features or OBR or anything.
>>>>>>>> The less interactions we have with the framework, the less fixes
>>>>>>>> we'll to
>>>>>>>> do there and the more stable it will be.
>>>>>>>> The idea is to bootstrap the osgi framework, all the real
>>>>>>>> provisioning
>>>>>>>> should be done in the osgi framework itself using the feature
>>>>>>>> service or
>>>>>>>> obr or anything else that is required.
>>>>>>>>
>>>>>>>> On Fri, May 4, 2012 at 8:35 PM, Jean-Baptiste
>>>>>>>> Onofré<jb...@nanthrax.net>wrote:
>>>>>>>>
>>>>>>>>  It makes sense, and I don't want to use the OfflineFeatureService
>>>>>>>>> (not
>>>>>>>>> require) but we will certainly have to decide to some "restriction"
>>>>>>>>> (for
>>>>>>>>> instance, what do we do if a feature is define in a feature ;)).
>>>>>>>>>
>>>>>>>>> Regards
>>>>>>>>> JB
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 05/04/2012 08:18 PM, Christian Schneider wrote:
>>>>>>>>>
>>>>>>>>>  Hi JB,
>>>>>>>>>>
>>>>>>>>>> yes we do not use the real maven resolution. I thought about
>>>>>>>>>> changing it
>>>>>>>>>> but it would have too many dependencies.
>>>>>>>>>>
>>>>>>>>>> I did not mean to really use features. Rather to read the feature
>>>>>>>>>> file
>>>>>>>>>> instead of the startup.properties but still process and resolve
>>>>>>>>>> in the
>>>>>>>>>> same way as before. So this should not add
>>>>>>>>>> much complexity. We could use the OfflineFeatureService but I dont
>>>>>>>>>> think
>>>>>>>>>> it is really necessary.
>>>>>>>>>>
>>>>>>>>>> Christian
>>>>>>>>>>
>>>>>>>>>> Am 04.05.2012 19:24, schrieb Jean-Baptiste Onofré:
>>>>>>>>>>
>>>>>>>>>>  Hi,
>>>>>>>>>>>
>>>>>>>>>>> As reminder, in startup properties we don't really use mvn URL. I
>>>>>>>>>>> mean
>>>>>>>>>>> we construct a file URL from the mvn one, we don't really use Pax
>>>>>>>>>>> URL.
>>>>>>>>>>>
>>>>>>>>>>> Anyway, it sounds good to me. I don't think users use anything
>>>>>>>>>>> else
>>>>>>>>>>> than the startup.properties.
>>>>>>>>>>>
>>>>>>>>>>> Regarding a feature instead of startup.properties, it means that
>>>>>>>>>>> we
>>>>>>>>>>> have to load at least feature core. I'm not sure that it's a good
>>>>>>>>>>> idea
>>>>>>>>>>> because feature is already OSGi oriented, whereas in the main
>>>>>>>>>>> area we
>>>>>>>>>>> start the framework (so we are not in the "OSGi area"). It's
>>>>>>>>>>> possible
>>>>>>>>>>> but it means that even if we provide a features XML, it's not
>>>>>>>>>>> really
>>>>>>>>>>> the feature service that will be use but a FeatureStartup process
>>>>>>>>>>> (like OfflineFeatureService that we use in the Karaf maven
>>>>>>>>>>> plugin).
>>>>>>>>>>>
>>>>>>>>>>> So it means that we will have a dual bootstrap process which use
>>>>>>>>>>> feature:
>>>>>>>>>>> - the "startup" feature (which doesn't really use the feature
>>>>>>>>>>> service)
>>>>>>>>>>> - the "boot" feature (which uses the feature service)
>>>>>>>>>>>
>>>>>>>>>>> As the startup.properties is generated from a feature currently,
>>>>>>>>>>> it
>>>>>>>>>>> makes sense to directly use the feature.
>>>>>>>>>>>
>>>>>>>>>>> All depends the way that it will be implemented, but basically +1
>>>>>>>>>>>
>>>>>>>>>>> Regards
>>>>>>>>>>> JB
>>>>>>>>>>>
>>>>>>>>>>> On 05/04/2012 07:03 PM, Christian Schneider wrote:
>>>>>>>>>>>
>>>>>>>>>>>  Hi all,
>>>>>>>>>>>>
>>>>>>>>>>>> on startup we currently use the following procedure.
>>>>>>>>>>>>
>>>>>>>>>>>> We read property karaf.auto.start from the file
>>>>>>>>>>>> config.properties.
>>>>>>>>>>>> This can be either a list of bundles separated by spaces or
>>>>>>>>>>>> "startup.properties" or "all".
>>>>>>>>>>>> If it is all we replace karaf.auto.start with the list of all
>>>>>>>>>>>> bundles in
>>>>>>>>>>>> the system dir. I think this option does not really make much
>>>>>>>>>>>> sense.
>>>>>>>>>>>> If it is startup.properties then we replace karaf.auto.start
>>>>>>>>>>>> with
>>>>>>>>>>>> the
>>>>>>>>>>>> list of bundles specified in the file startup.properties.
>>>>>>>>>>>> Additionally we either support mvn urls or paths which are
>>>>>>>>>>>> converted to
>>>>>>>>>>>> mvn urls.
>>>>>>>>>>>>
>>>>>>>>>>>> This all is quite a lot of variability of which we use none.
>>>>>>>>>>>>
>>>>>>>>>>>> I propose to replace this in two steps:
>>>>>>>>>>>>
>>>>>>>>>>>> 1. Remove the karaf.auto.start property and always load the
>>>>>>>>>>>> bundles from
>>>>>>>>>>>> startup.properties. Also only support mvn urls.
>>>>>>>>>>>> This makes the code in main cleaner and makes it easier for our
>>>>>>>>>>>> users to
>>>>>>>>>>>> understand how to change the startup bundles.
>>>>>>>>>>>>
>>>>>>>>>>>> 2. Remove the startup.properties and instead use a feature name
>>>>>>>>>>>> to
>>>>>>>>>>>> determine the list of bundles to load
>>>>>>>>>>>> The second step makes this even simpler and additionally we can
>>>>>>>>>>>> remove
>>>>>>>>>>>> the generation of the startup.properties in the karaf maven
>>>>>>>>>>>> plugin.
>>>>>>>>>>>>
>>>>>>>>>>>> So what do you think?
>>>>>>>>>>>>
>>>>>>>>>>>> Christian
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>  --
>>>>>>>>> Jean-Baptiste Onofré
>>>>>>>>> jbonofre@apache.org
>>>>>>>>> http://blog.nanthrax.net
>>>>>>>>> Talend - http://www.talend.com
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> ------------------------
>>>>>>>> Guillaume Nodet
>>>>>>>> ------------------------
>>>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>>>> ------------------------
>>>>>>>> FuseSource, Integration everywhere
>>>>>>>> http://fusesource.com
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
> --
>
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> Talend Application Integration Division http://www.talend.com
>
>


-- 
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
FuseSource, Integration everywhere
http://fusesource.com

Re: [Discuss] Handling of initial bundles

[Christian Schneider <ch...@die-schneider.net>]

I waited for almost 2 days. Your mail came just shortly after my commit. 
So I thought the dicussion was settled.
You are right though that I could have waited a little longer. I only 
committed the first part though and I think that I incorporated all 
feedback into the change.

So let me summarize the feedback and how I included it:

- There was only positive feedback about having only the 
startup.properties and not the properties in the config.properties to 
control the startup bundles. So I think  we agreed on this.
- David gave the feedback that he would like the startup.properties to 
be a flat list of bundles. While I don´t agree that this is a good idea 
this is absolutely possible. I used mvn urls in
startup.properties and for the framework but you can use relative paths. 
So if you have the startup bundles directly below system you can just 
refer to them by file name in  the startup.properties.
I also used an interface ArtifactResolver that allows to easily replace 
this behaviour.
- Guillaume and you gave the feedback to not introduce new dependencies 
and I did not

So functionally I mainly simplified and restructured the Main code. It 
went down from about 950 lines of code to about 400. I think the code is 
much more readable and maintainable now.

There is one nice new feature that is possible now. You can specify the 
path to your local maven repo in bundle.locations. In this case karaf 
can startup completely without a system directory and directly uses the
local repo. I think this is really nice for developing. As you do not 
have to do the assembly step when changing the source of modules in 
startup.properties.

So again sorry for committing too early but I worked really hard on this 
the weekend. In the end I had a really nice solution that at this point 
I think fitted into all the feedback.

Christian

Am 07.05.2012 00:46, schrieb Achim Nierbeck:
> To my concern the way main and the loading of karaf worked was "Good 
> Enough for Now".
> I didn't see any issues to change the way it was working. So yes if 
> something is good and properly
> working, don't Touch it. You might break it.
>
> Regarding committing your changes, I do find it disturbing, that you 
> start a discussion without
> waiting for a result.
>
> regards, Achim
>
>
> Am 06.05.2012 22:28, schrieb Christian Schneider:
>> I did not have the intention to make this more complicated. I just 
>> removed the other options.
>> So what exactly do you -1?
>>
>> I already committed the first step of the implementation and of 
>> course did not introduce any new dependencies.
>> For the next step I plan to simply read the feature file instead of 
>> the properties file. I don´t think that I need the feature service 
>> for that.
>>
>> Of course that means that the framework feature would only allow the 
>> list of bundles and the startlevel for each bundle. So basically the 
>> same
>> that is supported in the startup.properties. Is that ok?
>>
>> Christian
>>
>> Am 06.05.2012 19:12, schrieb Achim Nierbeck:
>>> Even though you and Christian are certainly right that maven and 
>>> OSGi work quite well if the versions are kept right, but this
>>> isn't the focus here. So coming back to the initial question I agree 
>>> with Guillaume, to better keep the main class
>>> lean and simple therefore I give a -1 on this.
>>> I don't want to see any dependencies to a features service what so 
>>> ever in main.
>>>
>>> Thanx, Achim
>>>
>>> Am 05.05.2012 11:33, schrieb Jean-Baptiste Onofré:
>>>> Agree with Christian.
>>>>
>>>> Leveraging Pax URL in Karaf is a key feature (even if sometime we 
>>>> fake the Pax URL usage, like in startup.properties URLs).
>>>>
>>>> Regards
>>>> JB
>>>>
>>>> On 05/05/2012 08:52 AM, Christian Schneider wrote:
>>>>> Well in this case you should use felix it uses a flat list of 
>>>>> bundles :-)
>>>>>
>>>>> I think the maven centric aproach is the biggest benefit in karaf. Of
>>>>> course obr can help to make this even better but out there you almost
>>>>> find no obr repos.
>>>>> The big benefit with maven is that you have almost any lib available.
>>>>> You only need to know the artifact coordinates. For example it is 
>>>>> great
>>>>> that you can install cxf or camle by just
>>>>> issuing two commands. How should that work without features that load
>>>>> artifacts from maven? As soon as all bundles are available in obr 
>>>>> repos
>>>>> we can switch to this aproach but
>>>>> I think that is not the near future.
>>>>>
>>>>> I think the aproach of installing features and bundles from a company
>>>>> maven repo should be our recommended way of installing 
>>>>> applications. I
>>>>> recommend to companies to split
>>>>> their development and deployment process at the maven repo. 
>>>>> Developers
>>>>> build the sources and deploy the binaries to the company maven repo.
>>>>> Admins install from there. I think
>>>>> that is the cleanest technical aproach to devops we currently have.
>>>>> Of course this should include the use of the obr. As obr and maven 
>>>>> often
>>>>> are incorporated in the same repository (like nexus or archiva) this
>>>>> should be achievable.
>>>>>
>>>>> Kar files are a dead end for me. They have their purpose when 
>>>>> companies
>>>>> do not have a repository but they are completely anti modular. If you
>>>>> deploy two applications using kar files you have a lot of duplication
>>>>> and most of the advantages of osgi are gone.
>>>>>
>>>>> About the flar system repo. Why should that be a good idea? The good
>>>>> thing about the system repo as a maven repo is that it mimics the
>>>>> central repo. So users can be sure that our system repo is just a 
>>>>> cache.
>>>>> All the artifacts in there are the same as in central. So the user 
>>>>> knows
>>>>> that each of these jars is the "official" version. This is very 
>>>>> helpful
>>>>> for example for doing licensing audits.
>>>>>
>>>>> Btw. I think maven and osgi are very compatible on the lowest level.
>>>>> Maven can supply single artifacts very well. It is only the 
>>>>> dependency
>>>>> resolution that is not compatible but obr can help out with that.
>>>>>
>>>>> Christian
>>>>>
>>>>> Am 05.05.2012 04:04, schrieb David Jencks:
>>>>>> I think we should make karaf much less maven centric including:
>>>>>>
>>>>>> -- system repo is flat, not maven structured, with file names 
>>>>>> enforced
>>>>>> as bundle-symbolic-name_bundle-version.jar. startup.properties can
>>>>>> then just have jar-name=start-level.
>>>>>>
>>>>>> -- kar files use similar flat internal repo
>>>>>>
>>>>>> -- non-kar features deprecated
>>>>>>
>>>>>> -- heavily encourage use of obr.
>>>>>>
>>>>>> maven and osgi are really not very compatible and trying to pretend
>>>>>> they are IMO leads to too many problems and suppresses the 
>>>>>> usefulness
>>>>>> of osgi.
>>>>>>
>>>>>> thanks
>>>>>> david jencks
>>>>>>
>>>>>> On May 4, 2012, at 12:46 PM, Guillaume Nodet wrote:
>>>>>>
>>>>>>> Please, keep the main file lean and simple, no dependencies on url
>>>>>>> handlers
>>>>>>> or features or OBR or anything.
>>>>>>> The less interactions we have with the framework, the less fixes
>>>>>>> we'll to
>>>>>>> do there and the more stable it will be.
>>>>>>> The idea is to bootstrap the osgi framework, all the real 
>>>>>>> provisioning
>>>>>>> should be done in the osgi framework itself using the feature 
>>>>>>> service or
>>>>>>> obr or anything else that is required.
>>>>>>>
>>>>>>> On Fri, May 4, 2012 at 8:35 PM, Jean-Baptiste
>>>>>>> Onofré<jb...@nanthrax.net>wrote:
>>>>>>>
>>>>>>>> It makes sense, and I don't want to use the 
>>>>>>>> OfflineFeatureService (not
>>>>>>>> require) but we will certainly have to decide to some 
>>>>>>>> "restriction"
>>>>>>>> (for
>>>>>>>> instance, what do we do if a feature is define in a feature ;)).
>>>>>>>>
>>>>>>>> Regards
>>>>>>>> JB
>>>>>>>>
>>>>>>>>
>>>>>>>> On 05/04/2012 08:18 PM, Christian Schneider wrote:
>>>>>>>>
>>>>>>>>> Hi JB,
>>>>>>>>>
>>>>>>>>> yes we do not use the real maven resolution. I thought about
>>>>>>>>> changing it
>>>>>>>>> but it would have too many dependencies.
>>>>>>>>>
>>>>>>>>> I did not mean to really use features. Rather to read the 
>>>>>>>>> feature file
>>>>>>>>> instead of the startup.properties but still process and 
>>>>>>>>> resolve in the
>>>>>>>>> same way as before. So this should not add
>>>>>>>>> much complexity. We could use the OfflineFeatureService but I 
>>>>>>>>> dont
>>>>>>>>> think
>>>>>>>>> it is really necessary.
>>>>>>>>>
>>>>>>>>> Christian
>>>>>>>>>
>>>>>>>>> Am 04.05.2012 19:24, schrieb Jean-Baptiste Onofré:
>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> As reminder, in startup properties we don't really use mvn 
>>>>>>>>>> URL. I
>>>>>>>>>> mean
>>>>>>>>>> we construct a file URL from the mvn one, we don't really use 
>>>>>>>>>> Pax
>>>>>>>>>> URL.
>>>>>>>>>>
>>>>>>>>>> Anyway, it sounds good to me. I don't think users use 
>>>>>>>>>> anything else
>>>>>>>>>> than the startup.properties.
>>>>>>>>>>
>>>>>>>>>> Regarding a feature instead of startup.properties, it means 
>>>>>>>>>> that we
>>>>>>>>>> have to load at least feature core. I'm not sure that it's a 
>>>>>>>>>> good
>>>>>>>>>> idea
>>>>>>>>>> because feature is already OSGi oriented, whereas in the main 
>>>>>>>>>> area we
>>>>>>>>>> start the framework (so we are not in the "OSGi area"). It's 
>>>>>>>>>> possible
>>>>>>>>>> but it means that even if we provide a features XML, it's not 
>>>>>>>>>> really
>>>>>>>>>> the feature service that will be use but a FeatureStartup 
>>>>>>>>>> process
>>>>>>>>>> (like OfflineFeatureService that we use in the Karaf maven 
>>>>>>>>>> plugin).
>>>>>>>>>>
>>>>>>>>>> So it means that we will have a dual bootstrap process which use
>>>>>>>>>> feature:
>>>>>>>>>> - the "startup" feature (which doesn't really use the feature
>>>>>>>>>> service)
>>>>>>>>>> - the "boot" feature (which uses the feature service)
>>>>>>>>>>
>>>>>>>>>> As the startup.properties is generated from a feature 
>>>>>>>>>> currently, it
>>>>>>>>>> makes sense to directly use the feature.
>>>>>>>>>>
>>>>>>>>>> All depends the way that it will be implemented, but 
>>>>>>>>>> basically +1
>>>>>>>>>>
>>>>>>>>>> Regards
>>>>>>>>>> JB
>>>>>>>>>>
>>>>>>>>>> On 05/04/2012 07:03 PM, Christian Schneider wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi all,
>>>>>>>>>>>
>>>>>>>>>>> on startup we currently use the following procedure.
>>>>>>>>>>>
>>>>>>>>>>> We read property karaf.auto.start from the file 
>>>>>>>>>>> config.properties.
>>>>>>>>>>> This can be either a list of bundles separated by spaces or
>>>>>>>>>>> "startup.properties" or "all".
>>>>>>>>>>> If it is all we replace karaf.auto.start with the list of all
>>>>>>>>>>> bundles in
>>>>>>>>>>> the system dir. I think this option does not really make 
>>>>>>>>>>> much sense.
>>>>>>>>>>> If it is startup.properties then we replace karaf.auto.start 
>>>>>>>>>>> with
>>>>>>>>>>> the
>>>>>>>>>>> list of bundles specified in the file startup.properties.
>>>>>>>>>>> Additionally we either support mvn urls or paths which are
>>>>>>>>>>> converted to
>>>>>>>>>>> mvn urls.
>>>>>>>>>>>
>>>>>>>>>>> This all is quite a lot of variability of which we use none.
>>>>>>>>>>>
>>>>>>>>>>> I propose to replace this in two steps:
>>>>>>>>>>>
>>>>>>>>>>> 1. Remove the karaf.auto.start property and always load the
>>>>>>>>>>> bundles from
>>>>>>>>>>> startup.properties. Also only support mvn urls.
>>>>>>>>>>> This makes the code in main cleaner and makes it easier for our
>>>>>>>>>>> users to
>>>>>>>>>>> understand how to change the startup bundles.
>>>>>>>>>>>
>>>>>>>>>>> 2. Remove the startup.properties and instead use a feature 
>>>>>>>>>>> name to
>>>>>>>>>>> determine the list of bundles to load
>>>>>>>>>>> The second step makes this even simpler and additionally we can
>>>>>>>>>>> remove
>>>>>>>>>>> the generation of the startup.properties in the karaf maven 
>>>>>>>>>>> plugin.
>>>>>>>>>>>
>>>>>>>>>>> So what do you think?
>>>>>>>>>>>
>>>>>>>>>>> Christian
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>> -- 
>>>>>>>> Jean-Baptiste Onofré
>>>>>>>> jbonofre@apache.org
>>>>>>>> http://blog.nanthrax.net
>>>>>>>> Talend - http://www.talend.com
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> -- 
>>>>>>> ------------------------
>>>>>>> Guillaume Nodet
>>>>>>> ------------------------
>>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>>> ------------------------
>>>>>>> FuseSource, Integration everywhere
>>>>>>> http://fusesource.com
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>>
>
>


-- 

Christian Schneider
http://www.liquid-reality.de

Open Source Architect
Talend Application Integration Division http://www.talend.com

Re: [Discuss] Handling of initial bundles

[Achim Nierbeck <bc...@googlemail.com>]

To my concern the way main and the loading of karaf worked was "Good 
Enough for Now".
I didn't see any issues to change the way it was working. So yes if 
something is good and properly
working, don't Touch it. You might break it.

Regarding committing your changes, I do find it disturbing, that you 
start a discussion without
waiting for a result.

regards, Achim


Am 06.05.2012 22:28, schrieb Christian Schneider:
> I did not have the intention to make this more complicated. I just 
> removed the other options.
> So what exactly do you -1?
>
> I already committed the first step of the implementation and of course 
> did not introduce any new dependencies.
> For the next step I plan to simply read the feature file instead of 
> the properties file. I don´t think that I need the feature service for 
> that.
>
> Of course that means that the framework feature would only allow the 
> list of bundles and the startlevel for each bundle. So basically the same
> that is supported in the startup.properties. Is that ok?
>
> Christian
>
> Am 06.05.2012 19:12, schrieb Achim Nierbeck:
>> Even though you and Christian are certainly right that maven and OSGi 
>> work quite well if the versions are kept right, but this
>> isn't the focus here. So coming back to the initial question I agree 
>> with Guillaume, to better keep the main class
>> lean and simple therefore I give a -1 on this.
>> I don't want to see any dependencies to a features service what so 
>> ever in main.
>>
>> Thanx, Achim
>>
>> Am 05.05.2012 11:33, schrieb Jean-Baptiste Onofré:
>>> Agree with Christian.
>>>
>>> Leveraging Pax URL in Karaf is a key feature (even if sometime we 
>>> fake the Pax URL usage, like in startup.properties URLs).
>>>
>>> Regards
>>> JB
>>>
>>> On 05/05/2012 08:52 AM, Christian Schneider wrote:
>>>> Well in this case you should use felix it uses a flat list of 
>>>> bundles :-)
>>>>
>>>> I think the maven centric aproach is the biggest benefit in karaf. Of
>>>> course obr can help to make this even better but out there you almost
>>>> find no obr repos.
>>>> The big benefit with maven is that you have almost any lib available.
>>>> You only need to know the artifact coordinates. For example it is 
>>>> great
>>>> that you can install cxf or camle by just
>>>> issuing two commands. How should that work without features that load
>>>> artifacts from maven? As soon as all bundles are available in obr 
>>>> repos
>>>> we can switch to this aproach but
>>>> I think that is not the near future.
>>>>
>>>> I think the aproach of installing features and bundles from a company
>>>> maven repo should be our recommended way of installing applications. I
>>>> recommend to companies to split
>>>> their development and deployment process at the maven repo. Developers
>>>> build the sources and deploy the binaries to the company maven repo.
>>>> Admins install from there. I think
>>>> that is the cleanest technical aproach to devops we currently have.
>>>> Of course this should include the use of the obr. As obr and maven 
>>>> often
>>>> are incorporated in the same repository (like nexus or archiva) this
>>>> should be achievable.
>>>>
>>>> Kar files are a dead end for me. They have their purpose when 
>>>> companies
>>>> do not have a repository but they are completely anti modular. If you
>>>> deploy two applications using kar files you have a lot of duplication
>>>> and most of the advantages of osgi are gone.
>>>>
>>>> About the flar system repo. Why should that be a good idea? The good
>>>> thing about the system repo as a maven repo is that it mimics the
>>>> central repo. So users can be sure that our system repo is just a 
>>>> cache.
>>>> All the artifacts in there are the same as in central. So the user 
>>>> knows
>>>> that each of these jars is the "official" version. This is very 
>>>> helpful
>>>> for example for doing licensing audits.
>>>>
>>>> Btw. I think maven and osgi are very compatible on the lowest level.
>>>> Maven can supply single artifacts very well. It is only the dependency
>>>> resolution that is not compatible but obr can help out with that.
>>>>
>>>> Christian
>>>>
>>>> Am 05.05.2012 04:04, schrieb David Jencks:
>>>>> I think we should make karaf much less maven centric including:
>>>>>
>>>>> -- system repo is flat, not maven structured, with file names 
>>>>> enforced
>>>>> as bundle-symbolic-name_bundle-version.jar. startup.properties can
>>>>> then just have jar-name=start-level.
>>>>>
>>>>> -- kar files use similar flat internal repo
>>>>>
>>>>> -- non-kar features deprecated
>>>>>
>>>>> -- heavily encourage use of obr.
>>>>>
>>>>> maven and osgi are really not very compatible and trying to pretend
>>>>> they are IMO leads to too many problems and suppresses the usefulness
>>>>> of osgi.
>>>>>
>>>>> thanks
>>>>> david jencks
>>>>>
>>>>> On May 4, 2012, at 12:46 PM, Guillaume Nodet wrote:
>>>>>
>>>>>> Please, keep the main file lean and simple, no dependencies on url
>>>>>> handlers
>>>>>> or features or OBR or anything.
>>>>>> The less interactions we have with the framework, the less fixes
>>>>>> we'll to
>>>>>> do there and the more stable it will be.
>>>>>> The idea is to bootstrap the osgi framework, all the real 
>>>>>> provisioning
>>>>>> should be done in the osgi framework itself using the feature 
>>>>>> service or
>>>>>> obr or anything else that is required.
>>>>>>
>>>>>> On Fri, May 4, 2012 at 8:35 PM, Jean-Baptiste
>>>>>> Onofré<jb...@nanthrax.net>wrote:
>>>>>>
>>>>>>> It makes sense, and I don't want to use the 
>>>>>>> OfflineFeatureService (not
>>>>>>> require) but we will certainly have to decide to some "restriction"
>>>>>>> (for
>>>>>>> instance, what do we do if a feature is define in a feature ;)).
>>>>>>>
>>>>>>> Regards
>>>>>>> JB
>>>>>>>
>>>>>>>
>>>>>>> On 05/04/2012 08:18 PM, Christian Schneider wrote:
>>>>>>>
>>>>>>>> Hi JB,
>>>>>>>>
>>>>>>>> yes we do not use the real maven resolution. I thought about
>>>>>>>> changing it
>>>>>>>> but it would have too many dependencies.
>>>>>>>>
>>>>>>>> I did not mean to really use features. Rather to read the 
>>>>>>>> feature file
>>>>>>>> instead of the startup.properties but still process and resolve 
>>>>>>>> in the
>>>>>>>> same way as before. So this should not add
>>>>>>>> much complexity. We could use the OfflineFeatureService but I dont
>>>>>>>> think
>>>>>>>> it is really necessary.
>>>>>>>>
>>>>>>>> Christian
>>>>>>>>
>>>>>>>> Am 04.05.2012 19:24, schrieb Jean-Baptiste Onofré:
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> As reminder, in startup properties we don't really use mvn URL. I
>>>>>>>>> mean
>>>>>>>>> we construct a file URL from the mvn one, we don't really use Pax
>>>>>>>>> URL.
>>>>>>>>>
>>>>>>>>> Anyway, it sounds good to me. I don't think users use anything 
>>>>>>>>> else
>>>>>>>>> than the startup.properties.
>>>>>>>>>
>>>>>>>>> Regarding a feature instead of startup.properties, it means 
>>>>>>>>> that we
>>>>>>>>> have to load at least feature core. I'm not sure that it's a good
>>>>>>>>> idea
>>>>>>>>> because feature is already OSGi oriented, whereas in the main 
>>>>>>>>> area we
>>>>>>>>> start the framework (so we are not in the "OSGi area"). It's 
>>>>>>>>> possible
>>>>>>>>> but it means that even if we provide a features XML, it's not 
>>>>>>>>> really
>>>>>>>>> the feature service that will be use but a FeatureStartup process
>>>>>>>>> (like OfflineFeatureService that we use in the Karaf maven 
>>>>>>>>> plugin).
>>>>>>>>>
>>>>>>>>> So it means that we will have a dual bootstrap process which use
>>>>>>>>> feature:
>>>>>>>>> - the "startup" feature (which doesn't really use the feature
>>>>>>>>> service)
>>>>>>>>> - the "boot" feature (which uses the feature service)
>>>>>>>>>
>>>>>>>>> As the startup.properties is generated from a feature 
>>>>>>>>> currently, it
>>>>>>>>> makes sense to directly use the feature.
>>>>>>>>>
>>>>>>>>> All depends the way that it will be implemented, but basically +1
>>>>>>>>>
>>>>>>>>> Regards
>>>>>>>>> JB
>>>>>>>>>
>>>>>>>>> On 05/04/2012 07:03 PM, Christian Schneider wrote:
>>>>>>>>>
>>>>>>>>>> Hi all,
>>>>>>>>>>
>>>>>>>>>> on startup we currently use the following procedure.
>>>>>>>>>>
>>>>>>>>>> We read property karaf.auto.start from the file 
>>>>>>>>>> config.properties.
>>>>>>>>>> This can be either a list of bundles separated by spaces or
>>>>>>>>>> "startup.properties" or "all".
>>>>>>>>>> If it is all we replace karaf.auto.start with the list of all
>>>>>>>>>> bundles in
>>>>>>>>>> the system dir. I think this option does not really make much 
>>>>>>>>>> sense.
>>>>>>>>>> If it is startup.properties then we replace karaf.auto.start 
>>>>>>>>>> with
>>>>>>>>>> the
>>>>>>>>>> list of bundles specified in the file startup.properties.
>>>>>>>>>> Additionally we either support mvn urls or paths which are
>>>>>>>>>> converted to
>>>>>>>>>> mvn urls.
>>>>>>>>>>
>>>>>>>>>> This all is quite a lot of variability of which we use none.
>>>>>>>>>>
>>>>>>>>>> I propose to replace this in two steps:
>>>>>>>>>>
>>>>>>>>>> 1. Remove the karaf.auto.start property and always load the
>>>>>>>>>> bundles from
>>>>>>>>>> startup.properties. Also only support mvn urls.
>>>>>>>>>> This makes the code in main cleaner and makes it easier for our
>>>>>>>>>> users to
>>>>>>>>>> understand how to change the startup bundles.
>>>>>>>>>>
>>>>>>>>>> 2. Remove the startup.properties and instead use a feature 
>>>>>>>>>> name to
>>>>>>>>>> determine the list of bundles to load
>>>>>>>>>> The second step makes this even simpler and additionally we can
>>>>>>>>>> remove
>>>>>>>>>> the generation of the startup.properties in the karaf maven 
>>>>>>>>>> plugin.
>>>>>>>>>>
>>>>>>>>>> So what do you think?
>>>>>>>>>>
>>>>>>>>>> Christian
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>> -- 
>>>>>>> Jean-Baptiste Onofré
>>>>>>> jbonofre@apache.org
>>>>>>> http://blog.nanthrax.net
>>>>>>> Talend - http://www.talend.com
>>>>>>>
>>>>>>
>>>>>>
>>>>>> -- 
>>>>>> ------------------------
>>>>>> Guillaume Nodet
>>>>>> ------------------------
>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>> ------------------------
>>>>>> FuseSource, Integration everywhere
>>>>>> http://fusesource.com
>>>>
>>>>
>>>
>>
>>
>
>


-- 
- Apache Karaf<http://karaf.apache.org/>  Committer&  PMC
- OPS4J Pax Web<http://wiki.ops4j.org/display/paxweb/Pax+Web/>    Committer&  Project Lead
- Blog<http://notizblog.nierbeck.de/>

Re: [Discuss] Handling of initial bundles

[Christian Schneider <ch...@die-schneider.net>]

I did not have the intention to make this more complicated. I just 
removed the other options.
So what exactly do you -1?

I already committed the first step of the implementation and of course 
did not introduce any new dependencies.
For the next step I plan to simply read the feature file instead of the 
properties file. I don´t think that I need the feature service for that.

Of course that means that the framework feature would only allow the 
list of bundles and the startlevel for each bundle. So basically the same
that is supported in the startup.properties. Is that ok?

Christian

Am 06.05.2012 19:12, schrieb Achim Nierbeck:
> Even though you and Christian are certainly right that maven and OSGi 
> work quite well if the versions are kept right, but this
> isn't the focus here. So coming back to the initial question I agree 
> with Guillaume, to better keep the main class
> lean and simple therefore I give a -1 on this.
> I don't want to see any dependencies to a features service what so 
> ever in main.
>
> Thanx, Achim
>
> Am 05.05.2012 11:33, schrieb Jean-Baptiste Onofré:
>> Agree with Christian.
>>
>> Leveraging Pax URL in Karaf is a key feature (even if sometime we 
>> fake the Pax URL usage, like in startup.properties URLs).
>>
>> Regards
>> JB
>>
>> On 05/05/2012 08:52 AM, Christian Schneider wrote:
>>> Well in this case you should use felix it uses a flat list of 
>>> bundles :-)
>>>
>>> I think the maven centric aproach is the biggest benefit in karaf. Of
>>> course obr can help to make this even better but out there you almost
>>> find no obr repos.
>>> The big benefit with maven is that you have almost any lib available.
>>> You only need to know the artifact coordinates. For example it is great
>>> that you can install cxf or camle by just
>>> issuing two commands. How should that work without features that load
>>> artifacts from maven? As soon as all bundles are available in obr repos
>>> we can switch to this aproach but
>>> I think that is not the near future.
>>>
>>> I think the aproach of installing features and bundles from a company
>>> maven repo should be our recommended way of installing applications. I
>>> recommend to companies to split
>>> their development and deployment process at the maven repo. Developers
>>> build the sources and deploy the binaries to the company maven repo.
>>> Admins install from there. I think
>>> that is the cleanest technical aproach to devops we currently have.
>>> Of course this should include the use of the obr. As obr and maven 
>>> often
>>> are incorporated in the same repository (like nexus or archiva) this
>>> should be achievable.
>>>
>>> Kar files are a dead end for me. They have their purpose when companies
>>> do not have a repository but they are completely anti modular. If you
>>> deploy two applications using kar files you have a lot of duplication
>>> and most of the advantages of osgi are gone.
>>>
>>> About the flar system repo. Why should that be a good idea? The good
>>> thing about the system repo as a maven repo is that it mimics the
>>> central repo. So users can be sure that our system repo is just a 
>>> cache.
>>> All the artifacts in there are the same as in central. So the user 
>>> knows
>>> that each of these jars is the "official" version. This is very helpful
>>> for example for doing licensing audits.
>>>
>>> Btw. I think maven and osgi are very compatible on the lowest level.
>>> Maven can supply single artifacts very well. It is only the dependency
>>> resolution that is not compatible but obr can help out with that.
>>>
>>> Christian
>>>
>>> Am 05.05.2012 04:04, schrieb David Jencks:
>>>> I think we should make karaf much less maven centric including:
>>>>
>>>> -- system repo is flat, not maven structured, with file names enforced
>>>> as bundle-symbolic-name_bundle-version.jar. startup.properties can
>>>> then just have jar-name=start-level.
>>>>
>>>> -- kar files use similar flat internal repo
>>>>
>>>> -- non-kar features deprecated
>>>>
>>>> -- heavily encourage use of obr.
>>>>
>>>> maven and osgi are really not very compatible and trying to pretend
>>>> they are IMO leads to too many problems and suppresses the usefulness
>>>> of osgi.
>>>>
>>>> thanks
>>>> david jencks
>>>>
>>>> On May 4, 2012, at 12:46 PM, Guillaume Nodet wrote:
>>>>
>>>>> Please, keep the main file lean and simple, no dependencies on url
>>>>> handlers
>>>>> or features or OBR or anything.
>>>>> The less interactions we have with the framework, the less fixes
>>>>> we'll to
>>>>> do there and the more stable it will be.
>>>>> The idea is to bootstrap the osgi framework, all the real 
>>>>> provisioning
>>>>> should be done in the osgi framework itself using the feature 
>>>>> service or
>>>>> obr or anything else that is required.
>>>>>
>>>>> On Fri, May 4, 2012 at 8:35 PM, Jean-Baptiste
>>>>> Onofré<jb...@nanthrax.net>wrote:
>>>>>
>>>>>> It makes sense, and I don't want to use the OfflineFeatureService 
>>>>>> (not
>>>>>> require) but we will certainly have to decide to some "restriction"
>>>>>> (for
>>>>>> instance, what do we do if a feature is define in a feature ;)).
>>>>>>
>>>>>> Regards
>>>>>> JB
>>>>>>
>>>>>>
>>>>>> On 05/04/2012 08:18 PM, Christian Schneider wrote:
>>>>>>
>>>>>>> Hi JB,
>>>>>>>
>>>>>>> yes we do not use the real maven resolution. I thought about
>>>>>>> changing it
>>>>>>> but it would have too many dependencies.
>>>>>>>
>>>>>>> I did not mean to really use features. Rather to read the 
>>>>>>> feature file
>>>>>>> instead of the startup.properties but still process and resolve 
>>>>>>> in the
>>>>>>> same way as before. So this should not add
>>>>>>> much complexity. We could use the OfflineFeatureService but I dont
>>>>>>> think
>>>>>>> it is really necessary.
>>>>>>>
>>>>>>> Christian
>>>>>>>
>>>>>>> Am 04.05.2012 19:24, schrieb Jean-Baptiste Onofré:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> As reminder, in startup properties we don't really use mvn URL. I
>>>>>>>> mean
>>>>>>>> we construct a file URL from the mvn one, we don't really use Pax
>>>>>>>> URL.
>>>>>>>>
>>>>>>>> Anyway, it sounds good to me. I don't think users use anything 
>>>>>>>> else
>>>>>>>> than the startup.properties.
>>>>>>>>
>>>>>>>> Regarding a feature instead of startup.properties, it means 
>>>>>>>> that we
>>>>>>>> have to load at least feature core. I'm not sure that it's a good
>>>>>>>> idea
>>>>>>>> because feature is already OSGi oriented, whereas in the main 
>>>>>>>> area we
>>>>>>>> start the framework (so we are not in the "OSGi area"). It's 
>>>>>>>> possible
>>>>>>>> but it means that even if we provide a features XML, it's not 
>>>>>>>> really
>>>>>>>> the feature service that will be use but a FeatureStartup process
>>>>>>>> (like OfflineFeatureService that we use in the Karaf maven 
>>>>>>>> plugin).
>>>>>>>>
>>>>>>>> So it means that we will have a dual bootstrap process which use
>>>>>>>> feature:
>>>>>>>> - the "startup" feature (which doesn't really use the feature
>>>>>>>> service)
>>>>>>>> - the "boot" feature (which uses the feature service)
>>>>>>>>
>>>>>>>> As the startup.properties is generated from a feature 
>>>>>>>> currently, it
>>>>>>>> makes sense to directly use the feature.
>>>>>>>>
>>>>>>>> All depends the way that it will be implemented, but basically +1
>>>>>>>>
>>>>>>>> Regards
>>>>>>>> JB
>>>>>>>>
>>>>>>>> On 05/04/2012 07:03 PM, Christian Schneider wrote:
>>>>>>>>
>>>>>>>>> Hi all,
>>>>>>>>>
>>>>>>>>> on startup we currently use the following procedure.
>>>>>>>>>
>>>>>>>>> We read property karaf.auto.start from the file 
>>>>>>>>> config.properties.
>>>>>>>>> This can be either a list of bundles separated by spaces or
>>>>>>>>> "startup.properties" or "all".
>>>>>>>>> If it is all we replace karaf.auto.start with the list of all
>>>>>>>>> bundles in
>>>>>>>>> the system dir. I think this option does not really make much 
>>>>>>>>> sense.
>>>>>>>>> If it is startup.properties then we replace karaf.auto.start with
>>>>>>>>> the
>>>>>>>>> list of bundles specified in the file startup.properties.
>>>>>>>>> Additionally we either support mvn urls or paths which are
>>>>>>>>> converted to
>>>>>>>>> mvn urls.
>>>>>>>>>
>>>>>>>>> This all is quite a lot of variability of which we use none.
>>>>>>>>>
>>>>>>>>> I propose to replace this in two steps:
>>>>>>>>>
>>>>>>>>> 1. Remove the karaf.auto.start property and always load the
>>>>>>>>> bundles from
>>>>>>>>> startup.properties. Also only support mvn urls.
>>>>>>>>> This makes the code in main cleaner and makes it easier for our
>>>>>>>>> users to
>>>>>>>>> understand how to change the startup bundles.
>>>>>>>>>
>>>>>>>>> 2. Remove the startup.properties and instead use a feature 
>>>>>>>>> name to
>>>>>>>>> determine the list of bundles to load
>>>>>>>>> The second step makes this even simpler and additionally we can
>>>>>>>>> remove
>>>>>>>>> the generation of the startup.properties in the karaf maven 
>>>>>>>>> plugin.
>>>>>>>>>
>>>>>>>>> So what do you think?
>>>>>>>>>
>>>>>>>>> Christian
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>> -- 
>>>>>> Jean-Baptiste Onofré
>>>>>> jbonofre@apache.org
>>>>>> http://blog.nanthrax.net
>>>>>> Talend - http://www.talend.com
>>>>>>
>>>>>
>>>>>
>>>>> -- 
>>>>> ------------------------
>>>>> Guillaume Nodet
>>>>> ------------------------
>>>>> Blog: http://gnodet.blogspot.com/
>>>>> ------------------------
>>>>> FuseSource, Integration everywhere
>>>>> http://fusesource.com
>>>
>>>
>>
>
>


-- 

Christian Schneider
http://www.liquid-reality.de

Open Source Architect
Talend Application Integration Division http://www.talend.com

Re: [Discuss] Handling of initial bundles

[Achim Nierbeck <bc...@googlemail.com>]

Even though you and Christian are certainly right that maven and OSGi 
work quite well if the versions are kept right, but this
isn't the focus here. So coming back to the initial question I agree 
with Guillaume, to better keep the main class
lean and simple therefore I give a -1 on this.
I don't want to see any dependencies to a features service what so ever 
in main.

Thanx, Achim

Am 05.05.2012 11:33, schrieb Jean-Baptiste Onofré:
> Agree with Christian.
>
> Leveraging Pax URL in Karaf is a key feature (even if sometime we fake 
> the Pax URL usage, like in startup.properties URLs).
>
> Regards
> JB
>
> On 05/05/2012 08:52 AM, Christian Schneider wrote:
>> Well in this case you should use felix it uses a flat list of bundles 
>> :-)
>>
>> I think the maven centric aproach is the biggest benefit in karaf. Of
>> course obr can help to make this even better but out there you almost
>> find no obr repos.
>> The big benefit with maven is that you have almost any lib available.
>> You only need to know the artifact coordinates. For example it is great
>> that you can install cxf or camle by just
>> issuing two commands. How should that work without features that load
>> artifacts from maven? As soon as all bundles are available in obr repos
>> we can switch to this aproach but
>> I think that is not the near future.
>>
>> I think the aproach of installing features and bundles from a company
>> maven repo should be our recommended way of installing applications. I
>> recommend to companies to split
>> their development and deployment process at the maven repo. Developers
>> build the sources and deploy the binaries to the company maven repo.
>> Admins install from there. I think
>> that is the cleanest technical aproach to devops we currently have.
>> Of course this should include the use of the obr. As obr and maven often
>> are incorporated in the same repository (like nexus or archiva) this
>> should be achievable.
>>
>> Kar files are a dead end for me. They have their purpose when companies
>> do not have a repository but they are completely anti modular. If you
>> deploy two applications using kar files you have a lot of duplication
>> and most of the advantages of osgi are gone.
>>
>> About the flar system repo. Why should that be a good idea? The good
>> thing about the system repo as a maven repo is that it mimics the
>> central repo. So users can be sure that our system repo is just a cache.
>> All the artifacts in there are the same as in central. So the user knows
>> that each of these jars is the "official" version. This is very helpful
>> for example for doing licensing audits.
>>
>> Btw. I think maven and osgi are very compatible on the lowest level.
>> Maven can supply single artifacts very well. It is only the dependency
>> resolution that is not compatible but obr can help out with that.
>>
>> Christian
>>
>> Am 05.05.2012 04:04, schrieb David Jencks:
>>> I think we should make karaf much less maven centric including:
>>>
>>> -- system repo is flat, not maven structured, with file names enforced
>>> as bundle-symbolic-name_bundle-version.jar. startup.properties can
>>> then just have jar-name=start-level.
>>>
>>> -- kar files use similar flat internal repo
>>>
>>> -- non-kar features deprecated
>>>
>>> -- heavily encourage use of obr.
>>>
>>> maven and osgi are really not very compatible and trying to pretend
>>> they are IMO leads to too many problems and suppresses the usefulness
>>> of osgi.
>>>
>>> thanks
>>> david jencks
>>>
>>> On May 4, 2012, at 12:46 PM, Guillaume Nodet wrote:
>>>
>>>> Please, keep the main file lean and simple, no dependencies on url
>>>> handlers
>>>> or features or OBR or anything.
>>>> The less interactions we have with the framework, the less fixes
>>>> we'll to
>>>> do there and the more stable it will be.
>>>> The idea is to bootstrap the osgi framework, all the real provisioning
>>>> should be done in the osgi framework itself using the feature 
>>>> service or
>>>> obr or anything else that is required.
>>>>
>>>> On Fri, May 4, 2012 at 8:35 PM, Jean-Baptiste
>>>> Onofré<jb...@nanthrax.net>wrote:
>>>>
>>>>> It makes sense, and I don't want to use the OfflineFeatureService 
>>>>> (not
>>>>> require) but we will certainly have to decide to some "restriction"
>>>>> (for
>>>>> instance, what do we do if a feature is define in a feature ;)).
>>>>>
>>>>> Regards
>>>>> JB
>>>>>
>>>>>
>>>>> On 05/04/2012 08:18 PM, Christian Schneider wrote:
>>>>>
>>>>>> Hi JB,
>>>>>>
>>>>>> yes we do not use the real maven resolution. I thought about
>>>>>> changing it
>>>>>> but it would have too many dependencies.
>>>>>>
>>>>>> I did not mean to really use features. Rather to read the feature 
>>>>>> file
>>>>>> instead of the startup.properties but still process and resolve 
>>>>>> in the
>>>>>> same way as before. So this should not add
>>>>>> much complexity. We could use the OfflineFeatureService but I dont
>>>>>> think
>>>>>> it is really necessary.
>>>>>>
>>>>>> Christian
>>>>>>
>>>>>> Am 04.05.2012 19:24, schrieb Jean-Baptiste Onofré:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> As reminder, in startup properties we don't really use mvn URL. I
>>>>>>> mean
>>>>>>> we construct a file URL from the mvn one, we don't really use Pax
>>>>>>> URL.
>>>>>>>
>>>>>>> Anyway, it sounds good to me. I don't think users use anything else
>>>>>>> than the startup.properties.
>>>>>>>
>>>>>>> Regarding a feature instead of startup.properties, it means that we
>>>>>>> have to load at least feature core. I'm not sure that it's a good
>>>>>>> idea
>>>>>>> because feature is already OSGi oriented, whereas in the main 
>>>>>>> area we
>>>>>>> start the framework (so we are not in the "OSGi area"). It's 
>>>>>>> possible
>>>>>>> but it means that even if we provide a features XML, it's not 
>>>>>>> really
>>>>>>> the feature service that will be use but a FeatureStartup process
>>>>>>> (like OfflineFeatureService that we use in the Karaf maven plugin).
>>>>>>>
>>>>>>> So it means that we will have a dual bootstrap process which use
>>>>>>> feature:
>>>>>>> - the "startup" feature (which doesn't really use the feature
>>>>>>> service)
>>>>>>> - the "boot" feature (which uses the feature service)
>>>>>>>
>>>>>>> As the startup.properties is generated from a feature currently, it
>>>>>>> makes sense to directly use the feature.
>>>>>>>
>>>>>>> All depends the way that it will be implemented, but basically +1
>>>>>>>
>>>>>>> Regards
>>>>>>> JB
>>>>>>>
>>>>>>> On 05/04/2012 07:03 PM, Christian Schneider wrote:
>>>>>>>
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> on startup we currently use the following procedure.
>>>>>>>>
>>>>>>>> We read property karaf.auto.start from the file config.properties.
>>>>>>>> This can be either a list of bundles separated by spaces or
>>>>>>>> "startup.properties" or "all".
>>>>>>>> If it is all we replace karaf.auto.start with the list of all
>>>>>>>> bundles in
>>>>>>>> the system dir. I think this option does not really make much 
>>>>>>>> sense.
>>>>>>>> If it is startup.properties then we replace karaf.auto.start with
>>>>>>>> the
>>>>>>>> list of bundles specified in the file startup.properties.
>>>>>>>> Additionally we either support mvn urls or paths which are
>>>>>>>> converted to
>>>>>>>> mvn urls.
>>>>>>>>
>>>>>>>> This all is quite a lot of variability of which we use none.
>>>>>>>>
>>>>>>>> I propose to replace this in two steps:
>>>>>>>>
>>>>>>>> 1. Remove the karaf.auto.start property and always load the
>>>>>>>> bundles from
>>>>>>>> startup.properties. Also only support mvn urls.
>>>>>>>> This makes the code in main cleaner and makes it easier for our
>>>>>>>> users to
>>>>>>>> understand how to change the startup bundles.
>>>>>>>>
>>>>>>>> 2. Remove the startup.properties and instead use a feature name to
>>>>>>>> determine the list of bundles to load
>>>>>>>> The second step makes this even simpler and additionally we can
>>>>>>>> remove
>>>>>>>> the generation of the startup.properties in the karaf maven 
>>>>>>>> plugin.
>>>>>>>>
>>>>>>>> So what do you think?
>>>>>>>>
>>>>>>>> Christian
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>> -- 
>>>>> Jean-Baptiste Onofré
>>>>> jbonofre@apache.org
>>>>> http://blog.nanthrax.net
>>>>> Talend - http://www.talend.com
>>>>>
>>>>
>>>>
>>>> -- 
>>>> ------------------------
>>>> Guillaume Nodet
>>>> ------------------------
>>>> Blog: http://gnodet.blogspot.com/
>>>> ------------------------
>>>> FuseSource, Integration everywhere
>>>> http://fusesource.com
>>
>>
>


-- 
- Apache Karaf<http://karaf.apache.org/>  Committer&  PMC
- OPS4J Pax Web<http://wiki.ops4j.org/display/paxweb/Pax+Web/>    Committer&  Project Lead
- Blog<http://notizblog.nierbeck.de/>

Re: [Discuss] Handling of initial bundles

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

Agree with Christian.

Leveraging Pax URL in Karaf is a key feature (even if sometime we fake 
the Pax URL usage, like in startup.properties URLs).

Regards
JB

On 05/05/2012 08:52 AM, Christian Schneider wrote:
> Well in this case you should use felix it uses a flat list of bundles :-)
>
> I think the maven centric aproach is the biggest benefit in karaf. Of
> course obr can help to make this even better but out there you almost
> find no obr repos.
> The big benefit with maven is that you have almost any lib available.
> You only need to know the artifact coordinates. For example it is great
> that you can install cxf or camle by just
> issuing two commands. How should that work without features that load
> artifacts from maven? As soon as all bundles are available in obr repos
> we can switch to this aproach but
> I think that is not the near future.
>
> I think the aproach of installing features and bundles from a company
> maven repo should be our recommended way of installing applications. I
> recommend to companies to split
> their development and deployment process at the maven repo. Developers
> build the sources and deploy the binaries to the company maven repo.
> Admins install from there. I think
> that is the cleanest technical aproach to devops we currently have.
> Of course this should include the use of the obr. As obr and maven often
> are incorporated in the same repository (like nexus or archiva) this
> should be achievable.
>
> Kar files are a dead end for me. They have their purpose when companies
> do not have a repository but they are completely anti modular. If you
> deploy two applications using kar files you have a lot of duplication
> and most of the advantages of osgi are gone.
>
> About the flar system repo. Why should that be a good idea? The good
> thing about the system repo as a maven repo is that it mimics the
> central repo. So users can be sure that our system repo is just a cache.
> All the artifacts in there are the same as in central. So the user knows
> that each of these jars is the "official" version. This is very helpful
> for example for doing licensing audits.
>
> Btw. I think maven and osgi are very compatible on the lowest level.
> Maven can supply single artifacts very well. It is only the dependency
> resolution that is not compatible but obr can help out with that.
>
> Christian
>
> Am 05.05.2012 04:04, schrieb David Jencks:
>> I think we should make karaf much less maven centric including:
>>
>> -- system repo is flat, not maven structured, with file names enforced
>> as bundle-symbolic-name_bundle-version.jar. startup.properties can
>> then just have jar-name=start-level.
>>
>> -- kar files use similar flat internal repo
>>
>> -- non-kar features deprecated
>>
>> -- heavily encourage use of obr.
>>
>> maven and osgi are really not very compatible and trying to pretend
>> they are IMO leads to too many problems and suppresses the usefulness
>> of osgi.
>>
>> thanks
>> david jencks
>>
>> On May 4, 2012, at 12:46 PM, Guillaume Nodet wrote:
>>
>>> Please, keep the main file lean and simple, no dependencies on url
>>> handlers
>>> or features or OBR or anything.
>>> The less interactions we have with the framework, the less fixes
>>> we'll to
>>> do there and the more stable it will be.
>>> The idea is to bootstrap the osgi framework, all the real provisioning
>>> should be done in the osgi framework itself using the feature service or
>>> obr or anything else that is required.
>>>
>>> On Fri, May 4, 2012 at 8:35 PM, Jean-Baptiste
>>> Onofré<jb...@nanthrax.net>wrote:
>>>
>>>> It makes sense, and I don't want to use the OfflineFeatureService (not
>>>> require) but we will certainly have to decide to some "restriction"
>>>> (for
>>>> instance, what do we do if a feature is define in a feature ;)).
>>>>
>>>> Regards
>>>> JB
>>>>
>>>>
>>>> On 05/04/2012 08:18 PM, Christian Schneider wrote:
>>>>
>>>>> Hi JB,
>>>>>
>>>>> yes we do not use the real maven resolution. I thought about
>>>>> changing it
>>>>> but it would have too many dependencies.
>>>>>
>>>>> I did not mean to really use features. Rather to read the feature file
>>>>> instead of the startup.properties but still process and resolve in the
>>>>> same way as before. So this should not add
>>>>> much complexity. We could use the OfflineFeatureService but I dont
>>>>> think
>>>>> it is really necessary.
>>>>>
>>>>> Christian
>>>>>
>>>>> Am 04.05.2012 19:24, schrieb Jean-Baptiste Onofré:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> As reminder, in startup properties we don't really use mvn URL. I
>>>>>> mean
>>>>>> we construct a file URL from the mvn one, we don't really use Pax
>>>>>> URL.
>>>>>>
>>>>>> Anyway, it sounds good to me. I don't think users use anything else
>>>>>> than the startup.properties.
>>>>>>
>>>>>> Regarding a feature instead of startup.properties, it means that we
>>>>>> have to load at least feature core. I'm not sure that it's a good
>>>>>> idea
>>>>>> because feature is already OSGi oriented, whereas in the main area we
>>>>>> start the framework (so we are not in the "OSGi area"). It's possible
>>>>>> but it means that even if we provide a features XML, it's not really
>>>>>> the feature service that will be use but a FeatureStartup process
>>>>>> (like OfflineFeatureService that we use in the Karaf maven plugin).
>>>>>>
>>>>>> So it means that we will have a dual bootstrap process which use
>>>>>> feature:
>>>>>> - the "startup" feature (which doesn't really use the feature
>>>>>> service)
>>>>>> - the "boot" feature (which uses the feature service)
>>>>>>
>>>>>> As the startup.properties is generated from a feature currently, it
>>>>>> makes sense to directly use the feature.
>>>>>>
>>>>>> All depends the way that it will be implemented, but basically +1
>>>>>>
>>>>>> Regards
>>>>>> JB
>>>>>>
>>>>>> On 05/04/2012 07:03 PM, Christian Schneider wrote:
>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> on startup we currently use the following procedure.
>>>>>>>
>>>>>>> We read property karaf.auto.start from the file config.properties.
>>>>>>> This can be either a list of bundles separated by spaces or
>>>>>>> "startup.properties" or "all".
>>>>>>> If it is all we replace karaf.auto.start with the list of all
>>>>>>> bundles in
>>>>>>> the system dir. I think this option does not really make much sense.
>>>>>>> If it is startup.properties then we replace karaf.auto.start with
>>>>>>> the
>>>>>>> list of bundles specified in the file startup.properties.
>>>>>>> Additionally we either support mvn urls or paths which are
>>>>>>> converted to
>>>>>>> mvn urls.
>>>>>>>
>>>>>>> This all is quite a lot of variability of which we use none.
>>>>>>>
>>>>>>> I propose to replace this in two steps:
>>>>>>>
>>>>>>> 1. Remove the karaf.auto.start property and always load the
>>>>>>> bundles from
>>>>>>> startup.properties. Also only support mvn urls.
>>>>>>> This makes the code in main cleaner and makes it easier for our
>>>>>>> users to
>>>>>>> understand how to change the startup bundles.
>>>>>>>
>>>>>>> 2. Remove the startup.properties and instead use a feature name to
>>>>>>> determine the list of bundles to load
>>>>>>> The second step makes this even simpler and additionally we can
>>>>>>> remove
>>>>>>> the generation of the startup.properties in the karaf maven plugin.
>>>>>>>
>>>>>>> So what do you think?
>>>>>>>
>>>>>>> Christian
>>>>>>>
>>>>>>>
>>>>>
>>>> --
>>>> Jean-Baptiste Onofré
>>>> jbonofre@apache.org
>>>> http://blog.nanthrax.net
>>>> Talend - http://www.talend.com
>>>>
>>>
>>>
>>> --
>>> ------------------------
>>> Guillaume Nodet
>>> ------------------------
>>> Blog: http://gnodet.blogspot.com/
>>> ------------------------
>>> FuseSource, Integration everywhere
>>> http://fusesource.com
>
>

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

Re: [Discuss] Handling of initial bundles

[Christian Schneider <ch...@die-schneider.net>]

Well in this case you should use felix it uses a flat list of bundles :-)

I think the maven centric aproach is the biggest benefit in karaf. Of 
course obr can help to make this even better but out there you almost 
find no obr repos.
The big benefit with maven is that you have almost any lib available. 
You only need to know the artifact coordinates. For example it is great 
that you can install cxf or camle by just
issuing two commands. How should that work without features that load 
artifacts from maven?  As soon as all bundles are available in obr repos 
we can switch to this aproach but
I think that is not the near future.

I think the aproach of installing features and bundles from a company 
maven repo should be our recommended way of installing applications. I 
recommend to companies to split
their development and deployment process at the maven repo. Developers 
build the sources and deploy the binaries to the company maven repo. 
Admins install from there. I think
that is the cleanest technical aproach to devops we currently have.
Of course this should include the use of the obr. As obr and maven often 
are incorporated in the same repository (like nexus or archiva) this 
should be achievable.

Kar files are a dead end for me. They have their purpose when companies 
do not have a repository but they are completely anti modular. If you 
deploy two applications using kar files you have a lot of duplication
and most of the advantages of osgi are gone.

About the flar system repo. Why should that be a good idea? The good 
thing about the system repo as a maven repo is that it mimics the 
central repo. So users can be sure that our system repo is just a cache.
All the artifacts in there are the same as in central. So the user knows 
that each of these jars is the "official" version. This is very helpful 
for example for doing licensing audits.

Btw. I think maven and osgi are very compatible on the lowest level. 
Maven can supply single artifacts very well. It is only the dependency 
resolution that is not compatible but obr can help out with that.

Christian

Am 05.05.2012 04:04, schrieb David Jencks:
> I think we should make karaf much less maven centric including:
>
> -- system repo is flat, not maven structured, with file names enforced as bundle-symbolic-name_bundle-version.jar.  startup.properties can then just have jar-name=start-level.
>
> -- kar files use similar flat internal repo
>
> -- non-kar features deprecated
>
> -- heavily encourage use of obr.
>
> maven and osgi are really not very compatible and trying to pretend they are IMO leads to too many problems and suppresses the usefulness of osgi.
>
> thanks
> david jencks
>
> On May 4, 2012, at 12:46 PM, Guillaume Nodet wrote:
>
>> Please, keep the main file lean and simple, no dependencies on url handlers
>> or features or OBR or anything.
>> The less interactions we have with the framework, the less fixes we'll to
>> do there and the more stable it will be.
>> The idea is to bootstrap the osgi framework, all the real provisioning
>> should be done in the osgi framework itself using the feature service or
>> obr or anything else that is required.
>>
>> On Fri, May 4, 2012 at 8:35 PM, Jean-Baptiste Onofré<jb...@nanthrax.net>wrote:
>>
>>> It makes sense, and I don't want to use the OfflineFeatureService (not
>>> require) but we will certainly have to decide to some "restriction" (for
>>> instance, what do we do if a feature is define in a feature ;)).
>>>
>>> Regards
>>> JB
>>>
>>>
>>> On 05/04/2012 08:18 PM, Christian Schneider wrote:
>>>
>>>> Hi JB,
>>>>
>>>> yes we do not use the real maven resolution. I thought about changing it
>>>> but it would have too many dependencies.
>>>>
>>>> I did not mean to really use features. Rather to read the feature file
>>>> instead of the startup.properties but still process and resolve in the
>>>> same way as before. So this should not add
>>>> much complexity. We could use the OfflineFeatureService but I dont think
>>>> it is really necessary.
>>>>
>>>> Christian
>>>>
>>>> Am 04.05.2012 19:24, schrieb Jean-Baptiste Onofré:
>>>>
>>>>> Hi,
>>>>>
>>>>> As reminder, in startup properties we don't really use mvn URL. I mean
>>>>> we construct a file URL from the mvn one, we don't really use Pax URL.
>>>>>
>>>>> Anyway, it sounds good to me. I don't think users use anything else
>>>>> than the startup.properties.
>>>>>
>>>>> Regarding a feature instead of startup.properties, it means that we
>>>>> have to load at least feature core. I'm not sure that it's a good idea
>>>>> because feature is already OSGi oriented, whereas in the main area we
>>>>> start the framework (so we are not in the "OSGi area"). It's possible
>>>>> but it means that even if we provide a features XML, it's not really
>>>>> the feature service that will be use but a FeatureStartup process
>>>>> (like OfflineFeatureService that we use in the Karaf maven plugin).
>>>>>
>>>>> So it means that we will have a dual bootstrap process which use feature:
>>>>> - the "startup" feature (which doesn't really use the feature service)
>>>>> - the "boot" feature (which uses the feature service)
>>>>>
>>>>> As the startup.properties is generated from a feature currently, it
>>>>> makes sense to directly use the feature.
>>>>>
>>>>> All depends the way that it will be implemented, but basically +1
>>>>>
>>>>> Regards
>>>>> JB
>>>>>
>>>>> On 05/04/2012 07:03 PM, Christian Schneider wrote:
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> on startup we currently use the following procedure.
>>>>>>
>>>>>> We read property karaf.auto.start from the file config.properties.
>>>>>> This can be either a list of bundles separated by spaces or
>>>>>> "startup.properties" or "all".
>>>>>> If it is all we replace karaf.auto.start with the list of all bundles in
>>>>>> the system dir. I think this option does not really make much sense.
>>>>>> If it is startup.properties then we replace karaf.auto.start with the
>>>>>> list of bundles specified in the file startup.properties.
>>>>>> Additionally we either support mvn urls or paths which are converted to
>>>>>> mvn urls.
>>>>>>
>>>>>> This all is quite a lot of variability of which we use none.
>>>>>>
>>>>>> I propose to replace this in two steps:
>>>>>>
>>>>>> 1. Remove the karaf.auto.start property and always load the bundles from
>>>>>> startup.properties. Also only support mvn urls.
>>>>>> This makes the code in main cleaner and makes it easier for our users to
>>>>>> understand how to change the startup bundles.
>>>>>>
>>>>>> 2. Remove the startup.properties and instead use a feature name to
>>>>>> determine the list of bundles to load
>>>>>> The second step makes this even simpler and additionally we can remove
>>>>>> the generation of the startup.properties in the karaf maven plugin.
>>>>>>
>>>>>> So what do you think?
>>>>>>
>>>>>> Christian
>>>>>>
>>>>>>
>>>>
>>> --
>>> Jean-Baptiste Onofré
>>> jbonofre@apache.org
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>>>
>>
>>
>> -- 
>> ------------------------
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> FuseSource, Integration everywhere
>> http://fusesource.com


-- 

Christian Schneider
http://www.liquid-reality.de

Open Source Architect
Talend Application Integration Division http://www.talend.com

Re: [Discuss] Handling of initial bundles

[David Jencks <da...@yahoo.com>]

I think we should make karaf much less maven centric including:

-- system repo is flat, not maven structured, with file names enforced as bundle-symbolic-name_bundle-version.jar.  startup.properties can then just have jar-name=start-level.

-- kar files use similar flat internal repo

-- non-kar features deprecated

-- heavily encourage use of obr.

maven and osgi are really not very compatible and trying to pretend they are IMO leads to too many problems and suppresses the usefulness of osgi.

thanks
david jencks

On May 4, 2012, at 12:46 PM, Guillaume Nodet wrote:

> Please, keep the main file lean and simple, no dependencies on url handlers
> or features or OBR or anything.
> The less interactions we have with the framework, the less fixes we'll to
> do there and the more stable it will be.
> The idea is to bootstrap the osgi framework, all the real provisioning
> should be done in the osgi framework itself using the feature service or
> obr or anything else that is required.
> 
> On Fri, May 4, 2012 at 8:35 PM, Jean-Baptiste Onofré <jb...@nanthrax.net>wrote:
> 
>> It makes sense, and I don't want to use the OfflineFeatureService (not
>> require) but we will certainly have to decide to some "restriction" (for
>> instance, what do we do if a feature is define in a feature ;)).
>> 
>> Regards
>> JB
>> 
>> 
>> On 05/04/2012 08:18 PM, Christian Schneider wrote:
>> 
>>> Hi JB,
>>> 
>>> yes we do not use the real maven resolution. I thought about changing it
>>> but it would have too many dependencies.
>>> 
>>> I did not mean to really use features. Rather to read the feature file
>>> instead of the startup.properties but still process and resolve in the
>>> same way as before. So this should not add
>>> much complexity. We could use the OfflineFeatureService but I dont think
>>> it is really necessary.
>>> 
>>> Christian
>>> 
>>> Am 04.05.2012 19:24, schrieb Jean-Baptiste Onofré:
>>> 
>>>> Hi,
>>>> 
>>>> As reminder, in startup properties we don't really use mvn URL. I mean
>>>> we construct a file URL from the mvn one, we don't really use Pax URL.
>>>> 
>>>> Anyway, it sounds good to me. I don't think users use anything else
>>>> than the startup.properties.
>>>> 
>>>> Regarding a feature instead of startup.properties, it means that we
>>>> have to load at least feature core. I'm not sure that it's a good idea
>>>> because feature is already OSGi oriented, whereas in the main area we
>>>> start the framework (so we are not in the "OSGi area"). It's possible
>>>> but it means that even if we provide a features XML, it's not really
>>>> the feature service that will be use but a FeatureStartup process
>>>> (like OfflineFeatureService that we use in the Karaf maven plugin).
>>>> 
>>>> So it means that we will have a dual bootstrap process which use feature:
>>>> - the "startup" feature (which doesn't really use the feature service)
>>>> - the "boot" feature (which uses the feature service)
>>>> 
>>>> As the startup.properties is generated from a feature currently, it
>>>> makes sense to directly use the feature.
>>>> 
>>>> All depends the way that it will be implemented, but basically +1
>>>> 
>>>> Regards
>>>> JB
>>>> 
>>>> On 05/04/2012 07:03 PM, Christian Schneider wrote:
>>>> 
>>>>> Hi all,
>>>>> 
>>>>> on startup we currently use the following procedure.
>>>>> 
>>>>> We read property karaf.auto.start from the file config.properties.
>>>>> This can be either a list of bundles separated by spaces or
>>>>> "startup.properties" or "all".
>>>>> If it is all we replace karaf.auto.start with the list of all bundles in
>>>>> the system dir. I think this option does not really make much sense.
>>>>> If it is startup.properties then we replace karaf.auto.start with the
>>>>> list of bundles specified in the file startup.properties.
>>>>> Additionally we either support mvn urls or paths which are converted to
>>>>> mvn urls.
>>>>> 
>>>>> This all is quite a lot of variability of which we use none.
>>>>> 
>>>>> I propose to replace this in two steps:
>>>>> 
>>>>> 1. Remove the karaf.auto.start property and always load the bundles from
>>>>> startup.properties. Also only support mvn urls.
>>>>> This makes the code in main cleaner and makes it easier for our users to
>>>>> understand how to change the startup bundles.
>>>>> 
>>>>> 2. Remove the startup.properties and instead use a feature name to
>>>>> determine the list of bundles to load
>>>>> The second step makes this even simpler and additionally we can remove
>>>>> the generation of the startup.properties in the karaf maven plugin.
>>>>> 
>>>>> So what do you think?
>>>>> 
>>>>> Christian
>>>>> 
>>>>> 
>>>> 
>>> 
>>> 
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>> 
> 
> 
> 
> -- 
> ------------------------
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> FuseSource, Integration everywhere
> http://fusesource.com

Re: [Discuss] Handling of initial bundles

[Guillaume Nodet <gn...@gmail.com>]

Please, keep the main file lean and simple, no dependencies on url handlers
or features or OBR or anything.
The less interactions we have with the framework, the less fixes we'll to
do there and the more stable it will be.
The idea is to bootstrap the osgi framework, all the real provisioning
should be done in the osgi framework itself using the feature service or
obr or anything else that is required.

On Fri, May 4, 2012 at 8:35 PM, Jean-Baptiste Onofré <jb...@nanthrax.net>wrote:

> It makes sense, and I don't want to use the OfflineFeatureService (not
> require) but we will certainly have to decide to some "restriction" (for
> instance, what do we do if a feature is define in a feature ;)).
>
> Regards
> JB
>
>
> On 05/04/2012 08:18 PM, Christian Schneider wrote:
>
>> Hi JB,
>>
>> yes we do not use the real maven resolution. I thought about changing it
>> but it would have too many dependencies.
>>
>> I did not mean to really use features. Rather to read the feature file
>> instead of the startup.properties but still process and resolve in the
>> same way as before. So this should not add
>> much complexity. We could use the OfflineFeatureService but I dont think
>> it is really necessary.
>>
>> Christian
>>
>> Am 04.05.2012 19:24, schrieb Jean-Baptiste Onofré:
>>
>>> Hi,
>>>
>>> As reminder, in startup properties we don't really use mvn URL. I mean
>>> we construct a file URL from the mvn one, we don't really use Pax URL.
>>>
>>> Anyway, it sounds good to me. I don't think users use anything else
>>> than the startup.properties.
>>>
>>> Regarding a feature instead of startup.properties, it means that we
>>> have to load at least feature core. I'm not sure that it's a good idea
>>> because feature is already OSGi oriented, whereas in the main area we
>>> start the framework (so we are not in the "OSGi area"). It's possible
>>> but it means that even if we provide a features XML, it's not really
>>> the feature service that will be use but a FeatureStartup process
>>> (like OfflineFeatureService that we use in the Karaf maven plugin).
>>>
>>> So it means that we will have a dual bootstrap process which use feature:
>>> - the "startup" feature (which doesn't really use the feature service)
>>> - the "boot" feature (which uses the feature service)
>>>
>>> As the startup.properties is generated from a feature currently, it
>>> makes sense to directly use the feature.
>>>
>>> All depends the way that it will be implemented, but basically +1
>>>
>>> Regards
>>> JB
>>>
>>> On 05/04/2012 07:03 PM, Christian Schneider wrote:
>>>
>>>> Hi all,
>>>>
>>>> on startup we currently use the following procedure.
>>>>
>>>> We read property karaf.auto.start from the file config.properties.
>>>> This can be either a list of bundles separated by spaces or
>>>> "startup.properties" or "all".
>>>> If it is all we replace karaf.auto.start with the list of all bundles in
>>>> the system dir. I think this option does not really make much sense.
>>>> If it is startup.properties then we replace karaf.auto.start with the
>>>> list of bundles specified in the file startup.properties.
>>>> Additionally we either support mvn urls or paths which are converted to
>>>> mvn urls.
>>>>
>>>> This all is quite a lot of variability of which we use none.
>>>>
>>>> I propose to replace this in two steps:
>>>>
>>>> 1. Remove the karaf.auto.start property and always load the bundles from
>>>> startup.properties. Also only support mvn urls.
>>>> This makes the code in main cleaner and makes it easier for our users to
>>>> understand how to change the startup bundles.
>>>>
>>>> 2. Remove the startup.properties and instead use a feature name to
>>>> determine the list of bundles to load
>>>> The second step makes this even simpler and additionally we can remove
>>>> the generation of the startup.properties in the karaf maven plugin.
>>>>
>>>> So what do you think?
>>>>
>>>> Christian
>>>>
>>>>
>>>
>>
>>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>



-- 
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
FuseSource, Integration everywhere
http://fusesource.com

Re: [Discuss] Handling of initial bundles

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

It makes sense, and I don't want to use the OfflineFeatureService (not 
require) but we will certainly have to decide to some "restriction" (for 
instance, what do we do if a feature is define in a feature ;)).

Regards
JB

On 05/04/2012 08:18 PM, Christian Schneider wrote:
> Hi JB,
>
> yes we do not use the real maven resolution. I thought about changing it
> but it would have too many dependencies.
>
> I did not mean to really use features. Rather to read the feature file
> instead of the startup.properties but still process and resolve in the
> same way as before. So this should not add
> much complexity. We could use the OfflineFeatureService but I dont think
> it is really necessary.
>
> Christian
>
> Am 04.05.2012 19:24, schrieb Jean-Baptiste Onofré:
>> Hi,
>>
>> As reminder, in startup properties we don't really use mvn URL. I mean
>> we construct a file URL from the mvn one, we don't really use Pax URL.
>>
>> Anyway, it sounds good to me. I don't think users use anything else
>> than the startup.properties.
>>
>> Regarding a feature instead of startup.properties, it means that we
>> have to load at least feature core. I'm not sure that it's a good idea
>> because feature is already OSGi oriented, whereas in the main area we
>> start the framework (so we are not in the "OSGi area"). It's possible
>> but it means that even if we provide a features XML, it's not really
>> the feature service that will be use but a FeatureStartup process
>> (like OfflineFeatureService that we use in the Karaf maven plugin).
>>
>> So it means that we will have a dual bootstrap process which use feature:
>> - the "startup" feature (which doesn't really use the feature service)
>> - the "boot" feature (which uses the feature service)
>>
>> As the startup.properties is generated from a feature currently, it
>> makes sense to directly use the feature.
>>
>> All depends the way that it will be implemented, but basically +1
>>
>> Regards
>> JB
>>
>> On 05/04/2012 07:03 PM, Christian Schneider wrote:
>>> Hi all,
>>>
>>> on startup we currently use the following procedure.
>>>
>>> We read property karaf.auto.start from the file config.properties.
>>> This can be either a list of bundles separated by spaces or
>>> "startup.properties" or "all".
>>> If it is all we replace karaf.auto.start with the list of all bundles in
>>> the system dir. I think this option does not really make much sense.
>>> If it is startup.properties then we replace karaf.auto.start with the
>>> list of bundles specified in the file startup.properties.
>>> Additionally we either support mvn urls or paths which are converted to
>>> mvn urls.
>>>
>>> This all is quite a lot of variability of which we use none.
>>>
>>> I propose to replace this in two steps:
>>>
>>> 1. Remove the karaf.auto.start property and always load the bundles from
>>> startup.properties. Also only support mvn urls.
>>> This makes the code in main cleaner and makes it easier for our users to
>>> understand how to change the startup bundles.
>>>
>>> 2. Remove the startup.properties and instead use a feature name to
>>> determine the list of bundles to load
>>> The second step makes this even simpler and additionally we can remove
>>> the generation of the startup.properties in the karaf maven plugin.
>>>
>>> So what do you think?
>>>
>>> Christian
>>>
>>
>
>

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

Re: [Discuss] Handling of initial bundles

[Christian Schneider <ch...@die-schneider.net>]

Hi JB,

yes we do not use the real maven resolution. I thought about changing it 
but it would have too many dependencies.

I did not mean to really use features. Rather to read the feature file 
instead of the startup.properties but still process and resolve in the 
same way as before. So this should not add
much complexity. We could use the OfflineFeatureService but I dont think 
it is really necessary.

Christian

Am 04.05.2012 19:24, schrieb Jean-Baptiste Onofré:
> Hi,
>
> As reminder, in startup properties we don't really use mvn URL. I mean 
> we construct a file URL from the mvn one, we don't really use Pax URL.
>
> Anyway, it sounds good to me. I don't think users use anything else 
> than the startup.properties.
>
> Regarding a feature instead of startup.properties, it means that we 
> have to load at least feature core. I'm not sure that it's a good idea 
> because feature is already OSGi oriented, whereas in the main area we 
> start the framework (so we are not in the "OSGi area"). It's possible 
> but it means that even if we provide a features XML, it's not really 
> the feature service that will be use but a FeatureStartup process 
> (like OfflineFeatureService that we use in the Karaf maven plugin).
>
> So it means that we will have a dual bootstrap process which use feature:
> - the "startup" feature (which doesn't really use the feature service)
> - the "boot" feature (which uses the feature service)
>
> As the startup.properties is generated from a feature currently, it 
> makes sense to directly use the feature.
>
> All depends the way that it will be implemented, but basically +1
>
> Regards
> JB
>
> On 05/04/2012 07:03 PM, Christian Schneider wrote:
>> Hi all,
>>
>> on startup we currently use the following procedure.
>>
>> We read property karaf.auto.start from the file config.properties.
>> This can be either a list of bundles separated by spaces or
>> "startup.properties" or "all".
>> If it is all we replace karaf.auto.start with the list of all bundles in
>> the system dir. I think this option does not really make much sense.
>> If it is startup.properties then we replace karaf.auto.start with the
>> list of bundles specified in the file startup.properties.
>> Additionally we either support mvn urls or paths which are converted to
>> mvn urls.
>>
>> This all is quite a lot of variability of which we use none.
>>
>> I propose to replace this in two steps:
>>
>> 1. Remove the karaf.auto.start property and always load the bundles from
>> startup.properties. Also only support mvn urls.
>> This makes the code in main cleaner and makes it easier for our users to
>> understand how to change the startup bundles.
>>
>> 2. Remove the startup.properties and instead use a feature name to
>> determine the list of bundles to load
>> The second step makes this even simpler and additionally we can remove
>> the generation of the startup.properties in the karaf maven plugin.
>>
>> So what do you think?
>>
>> Christian
>>
>


-- 

Christian Schneider
http://www.liquid-reality.de

Open Source Architect
Talend Application Integration Division http://www.talend.com

Re: [Discuss] Handling of initial bundles

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

Hi,

As reminder, in startup properties we don't really use mvn URL. I mean 
we construct a file URL from the mvn one, we don't really use Pax URL.

Anyway, it sounds good to me. I don't think users use anything else than 
the startup.properties.

Regarding a feature instead of startup.properties, it means that we have 
to load at least feature core. I'm not sure that it's a good idea 
because feature is already OSGi oriented, whereas in the main area we 
start the framework (so we are not in the "OSGi area"). It's possible 
but it means that even if we provide a features XML, it's not really the 
feature service that will be use but a FeatureStartup process (like 
OfflineFeatureService that we use in the Karaf maven plugin).

So it means that we will have a dual bootstrap process which use feature:
- the "startup" feature (which doesn't really use the feature service)
- the "boot" feature (which uses the feature service)

As the startup.properties is generated from a feature currently, it 
makes sense to directly use the feature.

All depends the way that it will be implemented, but basically +1

Regards
JB

On 05/04/2012 07:03 PM, Christian Schneider wrote:
> Hi all,
>
> on startup we currently use the following procedure.
>
> We read property karaf.auto.start from the file config.properties.
> This can be either a list of bundles separated by spaces or
> "startup.properties" or "all".
> If it is all we replace karaf.auto.start with the list of all bundles in
> the system dir. I think this option does not really make much sense.
> If it is startup.properties then we replace karaf.auto.start with the
> list of bundles specified in the file startup.properties.
> Additionally we either support mvn urls or paths which are converted to
> mvn urls.
>
> This all is quite a lot of variability of which we use none.
>
> I propose to replace this in two steps:
>
> 1. Remove the karaf.auto.start property and always load the bundles from
> startup.properties. Also only support mvn urls.
> This makes the code in main cleaner and makes it easier for our users to
> understand how to change the startup bundles.
>
> 2. Remove the startup.properties and instead use a feature name to
> determine the list of bundles to load
> The second step makes this even simpler and additionally we can remove
> the generation of the startup.properties in the karaf maven plugin.
>
> So what do you think?
>
> Christian
>

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

Re: [Discuss] Handling of initial bundles

[Christian Schneider <ch...@die-schneider.net>]

I simply tried to avoid that dependency. Do you propose to use the 
feature service from the main module? We could do this but I am not sure
it would be such a good idea.

My intention in using the framework feature is simply to avoid having 
the startup.properties to avoid having this information duplicated 
between the features and the startup.properties.

Christian

Am 08.05.2012 09:46, schrieb Guillaume Nodet:
> The problem for me is not too many dependencies, it is really too much
> code.  The more code there is in main, the more bug fixes there will be,
> which means that people won't be able to update at runtime.
> What I really don't like in bringing features is that those have changed in
> the past and may certainly also change in the future, which mean the main
> jar will not be as stable is it should be.
> I really prefer to keep it at a minimum and rely on the feature service to
> deploy all the features.  Why is that a problem ?
>

-- 
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
Talend Application Integration Division http://www.talend.com

Re: [Discuss] Handling of initial bundles

[Guillaume Nodet <gn...@gmail.com>]

The problem for me is not too many dependencies, it is really too much
code.  The more code there is in main, the more bug fixes there will be,
which means that people won't be able to update at runtime.
What I really don't like in bringing features is that those have changed in
the past and may certainly also change in the future, which mean the main
jar will not be as stable is it should be.
I really prefer to keep it at a minimum and rely on the feature service to
deploy all the features.  Why is that a problem ?

On Tue, May 8, 2012 at 9:01 AM, Christian Schneider <chris@die-schneider.net
> wrote:

> I would like to summarize the discussion about my proposed second step to
> replace the startup.properties by a feature loading. Again sorry that I
> committed the first part too early.
> I think though that our discussion mainly was about the second part and I
> did not even start to implement that.
>
> Here the requirements people wrote during the discussion:
> - We should not introduce additional dependencies into the main module
> - Some people like the startup.properties. So we should keep this feature
> - In addition to the maven urls we should also support loading bundles
> from a flat directory structure
> - We should allow several features from several feature files to be used
> at startup
>
> So this is what I propose to fullfill the above requirements:
> - If a startup.properties file exists then the bundles in there will be
> loaded and started (works already)
> - We introduce two new optional properties for config.properties:
> startup.feature.url and startup.feature.name (default:framework)
> - If the startup.feature.url property is present then we resolve the
> startup.feature.url using the ArtifactResolver and read the named feature.
> We then install all bundles in the
> feature with their corresponding startlevels
> - We allow to use file names in the startup.properties that are searched
> in system and bundle.locations. This allows the flat structure. (Works
> already)
> - We read the feature file using jaxb but not with the feaure service.
> Instead we simply use annotated pojos
> - We switch the build process of our framework feature to not generate the
> startup.properties anymore and instead use the new properties to reference
> the existing
> feature
> - I propose to not implement the possibility to use more than one feature
> in the startup as this feature is only used to bootstrap the distro. I dont
> think custom distros need to change that behaviour
>
> Pro:
> - Makes our build simpler
> - Makes our itests simpler as we do not need to sync the
> startup.properties anymore by hand
> - People who already know the feature concept do not have to learn the new
> concept of the startup.properties
>
> Con:
> - We have an additional description of a feature file in main. I think
> this is not so bad as we keep it to the minimum. We should also detect
> discrepancies very fast as the
> itests will fail
>
> Christian
>
> Am 04.05.2012 19:03, schrieb Christian Schneider:
>
>  Hi all,
>>
>> on startup we currently use the following procedure.
>>
>> We read property karaf.auto.start from the file config.properties.
>> This can be either a list of bundles separated by spaces or
>> "startup.properties" or "all".
>> If it is all we replace karaf.auto.start with the list of all bundles in
>> the system dir. I think this option does not really make much sense.
>> If it is startup.properties then we replace karaf.auto.start with the
>> list of bundles specified in the file startup.properties.
>> Additionally we either support mvn urls or paths which are converted to
>> mvn urls.
>>
>> This all is quite a lot of variability of which we use none.
>>
>> I propose to replace this in two steps:
>>
>> 1. Remove the karaf.auto.start property and always load the bundles from
>> startup.properties. Also only support mvn urls.
>> This makes the code in main cleaner and makes it easier for our users to
>> understand how to change the startup bundles.
>>
>> 2. Remove the startup.properties and instead use a feature name to
>> determine the list of bundles to load
>> The second step makes this even simpler and additionally we can remove
>> the generation of the startup.properties in the karaf maven plugin.
>>
>> So what do you think?
>>
>> Christian
>>
>>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> Talend Application Integration Division http://www.talend.com
>
>


-- 
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
FuseSource, Integration everywhere
http://fusesource.com

Re: [Discuss] Handling of initial bundles

[Christian Schneider <ch...@die-schneider.net>]

The changes about feature loading are not yet in the trunk but I 
attached them as a patch to:
https://issues.apache.org/jira/browse/KARAF-1296

So you can already try it. Guillaume is currently reviewing the changes 
so I wait a bit more what his result is.

The patch also contains a test where I have a config.properties with one 
additional line:

--
karaf.startup.feature.uri=mvn:org.apache.karaf.features/framework/1.0.0/xml/features
karaf.startup.feature.name=framework
--

The second line is optional and defaults to framework. So that is what 
you would have to put into the config to make startup without 
startup.properties work.
The code also reads both startup.properties and the feature so you could 
even mix both but I would not recommend it.

Christian

Am 23.05.2012 17:44, schrieb Andrei Pozolotin:
>      Christian:
>
>      I am curious
>
>      1) are your changes are in current karaf 3 snapshot?
>
>      2) do you have example/test project that shows how to build
>      karaf distro w/o startup.properties, with minimal feature=framework
>      only?
>
>      3) or is the idea discarded?
>
>      Thank you,
>
>      Andrei
>
>
>
>

-- 
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
Talend Application Integration Division http://www.talend.com

Re: [Discuss] Handling of initial bundles

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

OK, I missed your revert, sorry for that (my mbox has been tragically 
grown up during vacation ;)).

As Andreas said, maybe a change around that has no value (even if you 
think it does in your perspective), so nothing has to be handled.

That's the point that I want to clarify first: does it make sense to 
change something around startup/bootstrap.

Regards
JB

On 06/02/2012 11:51 AM, Christian Schneider wrote:
> Hi JB,
>
> my mail is only to find out how I should handle this. I reverted my
> change about one hour after Guillaumes -1.
> Btw. I did not see any other -1 about my commit.
>
> Christian
>
>
> Am 02.06.2012 11:42, schrieb Jean-Baptiste Onofré:
>> Hi Christian,
>>
>> Before arguing on each point, David, Guillaume, and Andreas sent a -1.
>> So please, revert your changes, we will discuss how we should move.
>>
>> Thanks
>> Regards
>> JB
>>
>> On 06/02/2012 11:17 AM, Christian Schneider wrote:
>>> After my rather emotional driven first answer I would like to elaborate
>>> a bit more.
>>>
>>> I have put a lot of effort into my implementation of feature reading in
>>> the main. I made sure the code does not introduce any new dependencies
>>> which was one of the issues. I added a test which shows the code works
>>> and also works together with the startup.properties handling. The code
>>> was only about 20 lines so it did not make the Main class really more
>>> complex.
>>>
>>> Guillaume correctly listed some unaddressed concerns. So lets look into
>>> the remaining issues inline:
>>>
>>> Am 25.05.2012 17:55, schrieb Christian Schneider:
>>>> Thanks for the explanations.
>>>>
>>>> I don´t think I can address these concerns while keeping the original
>>>> idea of using features like the startup.properties. So I closed the
>>>> issue as wont fix.
>>>>
>>>> Christian
>>>>
>>>> Am 25.05.2012 17:34, schrieb Guillaume Nodet:
>>>>> David said he didn't want xml processing in the bootstrap. This
>>>>> clearly has not been addressed.
>>> As features are expressed in xml I can not really address this without
>>> completely skipping the feature reading. This was the main reason why I
>>> closed the issue. I hoped my simple implementation convinced David that
>>> xml handling is not so bad after all. As he did not express any concerns
>>> about my patch I thought this is resolved.
>>>>> Andreas said there's no value in your change because the file is now
>>>>> fully generated. This hasn't been addressed.
>>> The value is in not having to generate the startup.properties. This
>>> would make the karaf maven plugin simpler as the code could be removed
>>> there. This is of course just my personal opinion. So I am not sure how
>>> to resolve that concern.
>>>>> I said only supporting a subset of features schema is a problem. This
>>>>> hasn't been addressed.
>>> I answered in the issue that the subset of a feature that is handled is
>>> quite equivalent in what we can do in the startup.properties file. As
>>> the framwork feature is the core of karaf I think we can
>>> live with not having the ability to reference other features or define
>>> configs. These additional features would make the feature handling too
>>> complex for the Main class. So I think we can argue that it is necessary
>>> and not a big problem to only support a subset.
>>>>>
>>>>>
>>>>> I may have missed something. But when people disagree, letting time
>>>>> pass does not usually change things.
>>>>> AFAIK, those concerns has been raised on the patch you uploaded, so
>>>>> there's something wrong here.
>>> There was only one comment on the patch from Guillaume. It was the last
>>> one in the list about not handling all possibilities of a feature. As I
>>> thought this was not a severe issue and adddtionall features could be
>>> added later if necessary I committed the patch. No one else commented or
>>> reviewed the patch. So I thought this was a kind of silent approval. So
>>> I really had a good feeling about the commit and was very disappointed
>>> about Guillaumes -1 as I thought I really did everything as well as I
>>> could by supplying a patch and waiting more than 4 days.
>>>
>>> @Guillaume so what is your proposal. How should I have handled this
>>> issue? Should I have given the jira issue more time so more people could
>>> review the patch? Should I ask for positive approval which is rather
>>> uncommon at apache?
>>>
>>> Christian
>>>
>>>
>>
>
>

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

Re: [Discuss] Handling of initial bundles

[Christian Schneider <ch...@die-schneider.net>]

Hi JB,

my mail is only to find out how I should handle this. I reverted my 
change about one hour after Guillaumes -1.
Btw. I did not see any other -1 about my commit.

Christian


Am 02.06.2012 11:42, schrieb Jean-Baptiste Onofré:
> Hi Christian,
>
> Before arguing on each point, David, Guillaume, and Andreas sent a -1. 
> So please, revert your changes, we will discuss how we should move.
>
> Thanks
> Regards
> JB
>
> On 06/02/2012 11:17 AM, Christian Schneider wrote:
>> After my rather emotional driven first answer I would like to elaborate
>> a bit more.
>>
>> I have put a lot of effort into my implementation of feature reading in
>> the main. I made sure the code does not introduce any new dependencies
>> which was one of the issues. I added a test which shows the code works
>> and also works together with the startup.properties handling. The code
>> was only about 20 lines so it did not make the Main class really more
>> complex.
>>
>> Guillaume correctly listed some unaddressed concerns. So lets look into
>> the remaining issues inline:
>>
>> Am 25.05.2012 17:55, schrieb Christian Schneider:
>>> Thanks for the explanations.
>>>
>>> I don´t think I can address these concerns while keeping the original
>>> idea of using features like the startup.properties. So I closed the
>>> issue as wont fix.
>>>
>>> Christian
>>>
>>> Am 25.05.2012 17:34, schrieb Guillaume Nodet:
>>>> David said he didn't want xml processing in the bootstrap. This
>>>> clearly has not been addressed.
>> As features are expressed in xml I can not really address this without
>> completely skipping the feature reading. This was the main reason why I
>> closed the issue. I hoped my simple implementation convinced David that
>> xml handling is not so bad after all. As he did not express any concerns
>> about my patch I thought this is resolved.
>>>> Andreas said there's no value in your change because the file is now
>>>> fully generated. This hasn't been addressed.
>> The value is in not having to generate the startup.properties. This
>> would make the karaf maven plugin simpler as the code could be removed
>> there. This is of course just my personal opinion. So I am not sure how
>> to resolve that concern.
>>>> I said only supporting a subset of features schema is a problem. This
>>>> hasn't been addressed.
>> I answered in the issue that the subset of a feature that is handled is
>> quite equivalent in what we can do in the startup.properties file. As
>> the framwork feature is the core of karaf I think we can
>> live with not having the ability to reference other features or define
>> configs. These additional features would make the feature handling too
>> complex for the Main class. So I think we can argue that it is necessary
>> and not a big problem to only support a subset.
>>>>
>>>>
>>>> I may have missed something. But when people disagree, letting time
>>>> pass does not usually change things.
>>>> AFAIK, those concerns has been raised on the patch you uploaded, so
>>>> there's something wrong here.
>> There was only one comment on the patch from Guillaume. It was the last
>> one in the list about not handling all possibilities of a feature. As I
>> thought this was not a severe issue and adddtionall features could be
>> added later if necessary I committed the patch. No one else commented or
>> reviewed the patch. So I thought this was a kind of silent approval. So
>> I really had a good feeling about the commit and was very disappointed
>> about Guillaumes -1 as I thought I really did everything as well as I
>> could by supplying a patch and waiting more than 4 days.
>>
>> @Guillaume so what is your proposal. How should I have handled this
>> issue? Should I have given the jira issue more time so more people could
>> review the patch? Should I ask for positive approval which is rather
>> uncommon at apache?
>>
>> Christian
>>
>>
>


-- 

Christian Schneider
http://www.liquid-reality.de

Open Source Architect
Talend Application Integration Division http://www.talend.com

Re: [Discuss] Handling of initial bundles

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

Hi Christian,

Before arguing on each point, David, Guillaume, and Andreas sent a -1. 
So please, revert your changes, we will discuss how we should move.

Thanks
Regards
JB

On 06/02/2012 11:17 AM, Christian Schneider wrote:
> After my rather emotional driven first answer I would like to elaborate
> a bit more.
>
> I have put a lot of effort into my implementation of feature reading in
> the main. I made sure the code does not introduce any new dependencies
> which was one of the issues. I added a test which shows the code works
> and also works together with the startup.properties handling. The code
> was only about 20 lines so it did not make the Main class really more
> complex.
>
> Guillaume correctly listed some unaddressed concerns. So lets look into
> the remaining issues inline:
>
> Am 25.05.2012 17:55, schrieb Christian Schneider:
>> Thanks for the explanations.
>>
>> I don´t think I can address these concerns while keeping the original
>> idea of using features like the startup.properties. So I closed the
>> issue as wont fix.
>>
>> Christian
>>
>> Am 25.05.2012 17:34, schrieb Guillaume Nodet:
>>> David said he didn't want xml processing in the bootstrap. This
>>> clearly has not been addressed.
> As features are expressed in xml I can not really address this without
> completely skipping the feature reading. This was the main reason why I
> closed the issue. I hoped my simple implementation convinced David that
> xml handling is not so bad after all. As he did not express any concerns
> about my patch I thought this is resolved.
>>> Andreas said there's no value in your change because the file is now
>>> fully generated. This hasn't been addressed.
> The value is in not having to generate the startup.properties. This
> would make the karaf maven plugin simpler as the code could be removed
> there. This is of course just my personal opinion. So I am not sure how
> to resolve that concern.
>>> I said only supporting a subset of features schema is a problem. This
>>> hasn't been addressed.
> I answered in the issue that the subset of a feature that is handled is
> quite equivalent in what we can do in the startup.properties file. As
> the framwork feature is the core of karaf I think we can
> live with not having the ability to reference other features or define
> configs. These additional features would make the feature handling too
> complex for the Main class. So I think we can argue that it is necessary
> and not a big problem to only support a subset.
>>>
>>>
>>> I may have missed something. But when people disagree, letting time
>>> pass does not usually change things.
>>> AFAIK, those concerns has been raised on the patch you uploaded, so
>>> there's something wrong here.
> There was only one comment on the patch from Guillaume. It was the last
> one in the list about not handling all possibilities of a feature. As I
> thought this was not a severe issue and adddtionall features could be
> added later if necessary I committed the patch. No one else commented or
> reviewed the patch. So I thought this was a kind of silent approval. So
> I really had a good feeling about the commit and was very disappointed
> about Guillaumes -1 as I thought I really did everything as well as I
> could by supplying a patch and waiting more than 4 days.
>
> @Guillaume so what is your proposal. How should I have handled this
> issue? Should I have given the jira issue more time so more people could
> review the patch? Should I ask for positive approval which is rather
> uncommon at apache?
>
> Christian
>
>

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

Re: [Discuss] Handling of initial bundles

[Christian Schneider <ch...@die-schneider.net>]

I added an issue for creating a customized standalone karaf from a 
standard karaf distro: https://issues.apache.org/jira/browse/KARAF-1519

It would be great if you could review and add your requirements.

Christian

Am 03.06.2012 17:28, schrieb Dan Tran:
> On Sun, Jun 3, 2012 at 5:19 AM, Christian Schneider
> <ch...@die-schneider.net>  wrote:
>> One nice  thing about the feature files we currently use is that they are
>> globally adressable using a maven coordinate. So by support reading features
>> we could create a very small distro that can read all it needs from maven
>> repos. If maven access is not allowed/possible in an environment we can
>> nicely use our system dir to make karaf fully self contained.
>>
>> So feature reading would allow us to have a fixed small binary distro that
>> can easily be customized by users. They can already change the feature set
>> they want and with startup feature loading they could also customize the
>> startup feature without build their own distro. We could extend that to some
>> commands that allow reading features into the system dir. So the user could
>> download a small karaf binary, execute some commands at a place with maven
>> repo access and as a result get a customized distro he can then use in a
>> closed company environment. This would be much simpler then building your
>> own distro with maven like you have to do it now.
>  From the perspective of karaf's feature, this is a big plus for us
> since we deliver karaf to our client
> in a isolated environment.
>
>> Honestly the above thing would also work nicely without loading startup
>> bundles from a feature file. I doubt anyway that people really need to
>> change the framework bundles.
>>
>> Supporting the subsystem spec sounds great to me. So that may be a good
>> reason to delay supporting feature reading and then only support it for the
>> subsystem spec features. Any way the startup feature loading from xml is not
>> that big of an issue for me. I thought it is a nice feature but it is not
>> really crucial.
>>
>> Now to the last part about maven support in karaf. I think at the moment
>> maven support is a key feature in karaf that makes it much easier to use
>> than other frameworks. It allows to install big frameworks like camel and
>> cxf with just some simple commands. Whenever I show this to people who do
>> not know karaf they are really impressed by it. So while I am sure that
>> maven is not ideal for OSGi bundles it is the best we currently have.
>>
>> I fully support replacing maven with something better like obr but only when
>> it is ready. So the key to that would be that all relevant bundles are
>> available in OBRs. We then also would need a url for adressing bundles from
>> OBRs (not sure if we have such a thing already). So replacing maven sounds
>> like a good goal for the future but not near term. Perhaps in the end maven
>> and OBR grow together anyway and the big maven repos simply additionally
>> support OBR. So you would address the entry points into the OBR as maven
>> coordinates and resolve dependencies using the OBR features.
>>
>> Christian
>>
>> P.S. Thanks for your nice words about my contributions to karaf. I really
>> like Karaf and see a great future for it. So I guess I just have to learn to
>> step on less toes on the way :-)
>>
>> Am 02.06.2012 19:26, schrieb David Jencks:
>>
>>> Hi Christian,
>>>
>>> I'm not a big fan of xml when dealing with not-very-complicated data.  The
>>> data in startup.properties is just about the right complexity for a
>>> properties file.  A feature repo is too much: it can contain more than one
>>> feature, and the name of the startup feature has to be hard coded.
>>>
>>> Furthermore, now that the subsystem spec is fairly final I think we should
>>> look towards using spec features as much as possible and start thinking of
>>> karaf features as possibly obsolete.  Pushing the karaf feature xml format
>>> into the framework startup is exactly opposite of this goal.
>>>
>>> I looked back and reviewed your patch.  Mostly I'm impressed with how much
>>> you've contributed in the last few months :-)  I wish I had as much time to
>>> spend on karaf....  Your patch is indeed pretty simple and small but my
>>> objections are really to the idea of using xml during startup rather than
>>> the implementation.  I might have missed it but didn't think you addressed
>>> the question of why xml was better than a properties file.
>>>
>>> My views might not be shared by many others, for instance I really think
>>> we should try hard to make karaf runtime independent of maven including the
>>> mvn url handler, and I'm not sure anyone else agrees with me.
>>>
>>> thanks
>>> david jencks
>>>
>>>
>>> On Jun 2, 2012, at 2:17 AM, Christian Schneider wrote:
>>>
>> --
>>
>> Christian Schneider
>> http://www.liquid-reality.de
>>
>> Open Source Architect
>> Talend Application Integration Division http://www.talend.com
>>


-- 
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
Talend Application Integration Division http://www.talend.com

Re: [Discuss] Handling of initial bundles

[Dan Tran <da...@gmail.com>]

On Sun, Jun 3, 2012 at 5:19 AM, Christian Schneider
<ch...@die-schneider.net> wrote:
> One nice  thing about the feature files we currently use is that they are
> globally adressable using a maven coordinate. So by support reading features
> we could create a very small distro that can read all it needs from maven
> repos. If maven access is not allowed/possible in an environment we can
> nicely use our system dir to make karaf fully self contained.
>
> So feature reading would allow us to have a fixed small binary distro that
> can easily be customized by users. They can already change the feature set
> they want and with startup feature loading they could also customize the
> startup feature without build their own distro. We could extend that to some
> commands that allow reading features into the system dir. So the user could
> download a small karaf binary, execute some commands at a place with maven
> repo access and as a result get a customized distro he can then use in a
> closed company environment. This would be much simpler then building your
> own distro with maven like you have to do it now.

>From the perspective of karaf's feature, this is a big plus for us
since we deliver karaf to our client
in a isolated environment.

>
> Honestly the above thing would also work nicely without loading startup
> bundles from a feature file. I doubt anyway that people really need to
> change the framework bundles.
>
> Supporting the subsystem spec sounds great to me. So that may be a good
> reason to delay supporting feature reading and then only support it for the
> subsystem spec features. Any way the startup feature loading from xml is not
> that big of an issue for me. I thought it is a nice feature but it is not
> really crucial.
>
> Now to the last part about maven support in karaf. I think at the moment
> maven support is a key feature in karaf that makes it much easier to use
> than other frameworks. It allows to install big frameworks like camel and
> cxf with just some simple commands. Whenever I show this to people who do
> not know karaf they are really impressed by it. So while I am sure that
> maven is not ideal for OSGi bundles it is the best we currently have.
>
> I fully support replacing maven with something better like obr but only when
> it is ready. So the key to that would be that all relevant bundles are
> available in OBRs. We then also would need a url for adressing bundles from
> OBRs (not sure if we have such a thing already). So replacing maven sounds
> like a good goal for the future but not near term. Perhaps in the end maven
> and OBR grow together anyway and the big maven repos simply additionally
> support OBR. So you would address the entry points into the OBR as maven
> coordinates and resolve dependencies using the OBR features.
>
> Christian
>
> P.S. Thanks for your nice words about my contributions to karaf. I really
> like Karaf and see a great future for it. So I guess I just have to learn to
> step on less toes on the way :-)
>
> Am 02.06.2012 19:26, schrieb David Jencks:
>
>> Hi Christian,
>>
>> I'm not a big fan of xml when dealing with not-very-complicated data.  The
>> data in startup.properties is just about the right complexity for a
>> properties file.  A feature repo is too much: it can contain more than one
>> feature, and the name of the startup feature has to be hard coded.
>>
>> Furthermore, now that the subsystem spec is fairly final I think we should
>> look towards using spec features as much as possible and start thinking of
>> karaf features as possibly obsolete.  Pushing the karaf feature xml format
>> into the framework startup is exactly opposite of this goal.
>>
>> I looked back and reviewed your patch.  Mostly I'm impressed with how much
>> you've contributed in the last few months :-)  I wish I had as much time to
>> spend on karaf....  Your patch is indeed pretty simple and small but my
>> objections are really to the idea of using xml during startup rather than
>> the implementation.  I might have missed it but didn't think you addressed
>> the question of why xml was better than a properties file.
>>
>> My views might not be shared by many others, for instance I really think
>> we should try hard to make karaf runtime independent of maven including the
>> mvn url handler, and I'm not sure anyone else agrees with me.
>>
>> thanks
>> david jencks
>>
>>
>> On Jun 2, 2012, at 2:17 AM, Christian Schneider wrote:
>>
>
> --
>
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> Talend Application Integration Division http://www.talend.com
>

Re: [Discuss] Handling of initial bundles

[Christian Schneider <ch...@die-schneider.net>]

One nice  thing about the feature files we currently use is that they 
are globally adressable using a maven coordinate. So by support reading 
features we could create a very small distro that can read all it needs 
from maven repos. If maven access is not allowed/possible in an 
environment we can nicely use our system dir to make karaf fully self 
contained.

So feature reading would allow us to have a fixed small binary distro 
that can easily be customized by users. They can already change the 
feature set they want and with startup feature loading they could also 
customize the startup feature without build their own distro. We could 
extend that to some commands that allow reading features into the system 
dir. So the user could download a small karaf binary, execute some 
commands at a place with maven repo access and as a result get a 
customized distro he can then use in a closed company environment. This 
would be much simpler then building your own distro with maven like you 
have to do it now.

Honestly the above thing would also work nicely without loading startup 
bundles from a feature file. I doubt anyway that people really need to 
change the framework bundles.

Supporting the subsystem spec sounds great to me. So that may be a good 
reason to delay supporting feature reading and then only support it for 
the subsystem spec features. Any way the startup feature loading from 
xml is not that big of an issue for me. I thought it is a nice feature 
but it is not really crucial.

Now to the last part about maven support in karaf. I think at the moment 
maven support is a key feature in karaf that makes it much easier to use 
than other frameworks. It allows to install big frameworks like camel 
and cxf with just some simple commands. Whenever I show this to people 
who do not know karaf they are really impressed by it. So while I am 
sure that maven is not ideal for OSGi bundles it is the best we 
currently have.

I fully support replacing maven with something better like obr but only 
when it is ready. So the key to that would be that all relevant bundles 
are available in OBRs. We then also would need a url for adressing 
bundles from OBRs (not sure if we have such a thing already). So 
replacing maven sounds like a good goal for the future but not near 
term. Perhaps in the end maven and OBR grow together anyway and the big 
maven repos simply additionally support OBR. So you would address the 
entry points into the OBR as maven coordinates and resolve dependencies 
using the OBR features.

Christian

P.S. Thanks for your nice words about my contributions to karaf. I 
really like Karaf and see a great future for it. So I guess I just have 
to learn to step on less toes on the way :-)

Am 02.06.2012 19:26, schrieb David Jencks:
> Hi Christian,
>
> I'm not a big fan of xml when dealing with not-very-complicated data.  The data in startup.properties is just about the right complexity for a properties file.  A feature repo is too much: it can contain more than one feature, and the name of the startup feature has to be hard coded.
>
> Furthermore, now that the subsystem spec is fairly final I think we should look towards using spec features as much as possible and start thinking of karaf features as possibly obsolete.  Pushing the karaf feature xml format into the framework startup is exactly opposite of this goal.
>
> I looked back and reviewed your patch.  Mostly I'm impressed with how much you've contributed in the last few months :-)  I wish I had as much time to spend on karaf....  Your patch is indeed pretty simple and small but my objections are really to the idea of using xml during startup rather than the implementation.  I might have missed it but didn't think you addressed the question of why xml was better than a properties file.
>
> My views might not be shared by many others, for instance I really think we should try hard to make karaf runtime independent of maven including the mvn url handler, and I'm not sure anyone else agrees with me.
>
> thanks
> david jencks
>
>
> On Jun 2, 2012, at 2:17 AM, Christian Schneider wrote:
>

-- 

Christian Schneider
http://www.liquid-reality.de

Open Source Architect
Talend Application Integration Division http://www.talend.com

Re: [Discuss] Handling of initial bundles

[David Jencks <da...@yahoo.com>]

Hi Christian,

I'm not a big fan of xml when dealing with not-very-complicated data.  The data in startup.properties is just about the right complexity for a properties file.  A feature repo is too much: it can contain more than one feature, and the name of the startup feature has to be hard coded.  

Furthermore, now that the subsystem spec is fairly final I think we should look towards using spec features as much as possible and start thinking of karaf features as possibly obsolete.  Pushing the karaf feature xml format into the framework startup is exactly opposite of this goal.

I looked back and reviewed your patch.  Mostly I'm impressed with how much you've contributed in the last few months :-)  I wish I had as much time to spend on karaf....  Your patch is indeed pretty simple and small but my objections are really to the idea of using xml during startup rather than the implementation.  I might have missed it but didn't think you addressed the question of why xml was better than a properties file.

My views might not be shared by many others, for instance I really think we should try hard to make karaf runtime independent of maven including the mvn url handler, and I'm not sure anyone else agrees with me.

thanks
david jencks


On Jun 2, 2012, at 2:17 AM, Christian Schneider wrote:

> After my rather emotional driven first answer I would like to elaborate a bit more.
> 
> I have put a lot of effort into my implementation of feature reading in the main. I made sure the code does not introduce any new dependencies which was one of the issues. I added a test which shows the code works and also works together with the startup.properties handling. The code was only about 20 lines so it did not make the Main class really more complex.
> 
> Guillaume correctly listed some unaddressed concerns. So lets look into the remaining issues inline:
> 
> Am 25.05.2012 17:55, schrieb Christian Schneider:
>> Thanks for the explanations.
>> 
>> I don´t think I can address these concerns while keeping the original idea of using features like the startup.properties. So I closed the issue as wont fix.
>> 
>> Christian
>> 
>> Am 25.05.2012 17:34, schrieb Guillaume Nodet:
>>> David said he didn't want xml processing in the bootstrap.  This
>>> clearly has not been addressed.
> As features are expressed in xml I can not really address this without completely skipping the feature reading. This was the main reason why I closed the issue. I hoped my simple implementation convinced David that xml handling is not so bad after all. As he did not express any concerns about my patch I thought this is resolved.
>>> Andreas said there's no value in your change because the file is now
>>> fully generated.  This hasn't been addressed.
> The value is in not having to generate the startup.properties. This would make the karaf maven plugin simpler as the code could be removed there. This is of course just my personal opinion. So I am not sure how to resolve that concern.
>>> I said only supporting a subset of features schema is a problem.  This
>>> hasn't been addressed.
> I answered in the issue that the subset of a feature that is handled is quite equivalent in what we can do in the startup.properties file. As the framwork feature is the core of karaf I think we can
> live with not having the ability to reference other features or define configs. These additional features would make the feature handling too complex for the Main class. So I think we can argue that it is necessary and not a big problem to only support a subset.
>>> 
>>> 
>>> I may have missed something.  But when people disagree, letting time
>>> pass does not usually change things.
>>> AFAIK, those concerns has been raised on the patch you uploaded, so
>>> there's something wrong here.
> There was only one comment on the patch from Guillaume. It was the last one in the list about not handling all possibilities of a feature.  As I thought this was not a severe issue and adddtionall features could be added later if necessary I committed the patch. No one else commented or reviewed the patch. So I thought this was a kind of silent approval. So I really had a good feeling about the commit and was very disappointed about Guillaumes -1 as I thought I really did everything as well as I could by supplying a patch and waiting more than 4 days.
> 
> @Guillaume so what is your proposal. How should I have handled this issue? Should I have given the jira issue more time so more people could review the patch? Should I ask for positive approval which is rather uncommon at apache?
> 
> Christian
> 
> 
> -- 
> 
> Christian Schneider
> http://www.liquid-reality.de
> 
> Open Source Architect
> Talend Application Integration Division http://www.talend.com
> 

Re: [Discuss] Handling of initial bundles

[Christian Schneider <ch...@die-schneider.net>]

After my rather emotional driven first answer I would like to elaborate 
a bit more.

I have put a lot of effort into my implementation of feature reading in 
the main. I made sure the code does not introduce any new dependencies 
which was one of the issues. I added a test which shows the code works 
and also works together with the startup.properties handling. The code 
was only about 20 lines so it did not make the Main class really more 
complex.

Guillaume correctly listed some unaddressed concerns. So lets look into 
the remaining issues inline:

Am 25.05.2012 17:55, schrieb Christian Schneider:
> Thanks for the explanations.
>
> I don´t think I can address these concerns while keeping the original 
> idea of using features like the startup.properties. So I closed the 
> issue as wont fix.
>
> Christian
>
> Am 25.05.2012 17:34, schrieb Guillaume Nodet:
>> David said he didn't want xml processing in the bootstrap.  This
>> clearly has not been addressed.
As features are expressed in xml I can not really address this without 
completely skipping the feature reading. This was the main reason why I 
closed the issue. I hoped my simple implementation convinced David that 
xml handling is not so bad after all. As he did not express any concerns 
about my patch I thought this is resolved.
>>  Andreas said there's no value in your change because the file is now
>> fully generated.  This hasn't been addressed.
The value is in not having to generate the startup.properties. This 
would make the karaf maven plugin simpler as the code could be removed 
there. This is of course just my personal opinion. So I am not sure how 
to resolve that concern.
>> I said only supporting a subset of features schema is a problem.  This
>> hasn't been addressed.
I answered in the issue that the subset of a feature that is handled is 
quite equivalent in what we can do in the startup.properties file. As 
the framwork feature is the core of karaf I think we can
live with not having the ability to reference other features or define 
configs. These additional features would make the feature handling too 
complex for the Main class. So I think we can argue that it is necessary 
and not a big problem to only support a subset.
>>
>>
>> I may have missed something.  But when people disagree, letting time
>> pass does not usually change things.
>> AFAIK, those concerns has been raised on the patch you uploaded, so
>> there's something wrong here.
There was only one comment on the patch from Guillaume. It was the last 
one in the list about not handling all possibilities of a feature.  As I 
thought this was not a severe issue and adddtionall features could be 
added later if necessary I committed the patch. No one else commented or 
reviewed the patch. So I thought this was a kind of silent approval. So 
I really had a good feeling about the commit and was very disappointed 
about Guillaumes -1 as I thought I really did everything as well as I 
could by supplying a patch and waiting more than 4 days.

@Guillaume so what is your proposal. How should I have handled this 
issue? Should I have given the jira issue more time so more people could 
review the patch? Should I ask for positive approval which is rather 
uncommon at apache?

Christian


-- 

Christian Schneider
http://www.liquid-reality.de

Open Source Architect
Talend Application Integration Division http://www.talend.com

Re: [Discuss] Handling of initial bundles

[Christian Schneider <ch...@die-schneider.net>]

Thanks for the explanations.

I don´t think I can address these concerns while keeping the original 
idea of using features like the startup.properties. So I closed the 
issue as wont fix.

Christian

Am 25.05.2012 17:34, schrieb Guillaume Nodet:
> David said he didn't want xml processing in the bootstrap.  This
> clearly has not been addressed.
> Andreas said there's no value in your change because the file is now
> fully generated.  This hasn't been addressed.
> I said only supporting a subset of features schema is a problem.  This
> hasn't been addressed.
>
> I may have missed something.  But when people disagree, letting time
> pass does not usually change things.
> AFAIK, those concerns has been raised on the patch you uploaded, so
> there's something wrong here.
>
> On Fri, May 25, 2012 at 5:30 PM, Christian Schneider
> <ch...@die-schneider.net>  wrote:
>> I thought we had settled all these concerns.
>> So what are the concerns regarding the commit that make you -1 it?
>>
>> During the discussion there were some concerns but I think my implementation
>> should have addressed all concerns. I created an issue and put up a patch.
>> This was available for 4 days now. Besides you no one else took the time to
>> review the patch.
>>
>> So from your review you wrote you were concernd that the implementation does
>> not implement all features of the feature file and people might want more.
>> Does this really warrant a -1 ?
>>
>> Christian
>>
>> Am 25.05.2012 17:08, schrieb Guillaume Nodet:
>>
>>> Can you please revert.  I think 3 people expressed concerns with the
>>> patch, so i'm officially -1 it until this concerns have been fully
>>> addressed and we've reached a consensus.
>>>
>>> On Fri, May 25, 2012 at 4:41 PM, Christian Schneider
>>> <ch...@die-schneider.net>    wrote:
>>>> I have now committed the patch. So you should be able to test from trunk
>>>> now.
>>>>
>>>>
>>>> Christian
>>>>
>>>> Am 23.05.2012 17:44, schrieb Andrei Pozolotin:
>>>>>      Christian:
>>>>>
>>>>>
>>>>>      I am curious
>>>>>
>>>>>      1) are your changes are in current karaf 3 snapshot?
>>>>>
>>>>>      2) do you have example/test project that shows how to build
>>>>>      karaf distro w/o startup.properties, with minimal feature=framework
>>>>>      only?
>>>>>
>>>>>      3) or is the idea discarded?
>>>>>
>>>>>      Thank you,
>>>>>
>>>>>      Andrei
>>>>>
>>>> --
>>>> Christian Schneider
>>>> http://www.liquid-reality.de
>>>>
>>>> Open Source Architect
>>>> Talend Application Integration Division http://www.talend.com
>>>>
>>>
>>
>> --
>> Christian Schneider
>> http://www.liquid-reality.de
>>
>> Open Source Architect
>> Talend Application Integration Division http://www.talend.com
>>
>
>


-- 
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
Talend Application Integration Division http://www.talend.com

Re: [Discuss] Handling of initial bundles

[Guillaume Nodet <gn...@gmail.com>]

David said he didn't want xml processing in the bootstrap.  This
clearly has not been addressed.
Andreas said there's no value in your change because the file is now
fully generated.  This hasn't been addressed.
I said only supporting a subset of features schema is a problem.  This
hasn't been addressed.

I may have missed something.  But when people disagree, letting time
pass does not usually change things.
AFAIK, those concerns has been raised on the patch you uploaded, so
there's something wrong here.

On Fri, May 25, 2012 at 5:30 PM, Christian Schneider
<ch...@die-schneider.net> wrote:
> I thought we had settled all these concerns.
> So what are the concerns regarding the commit that make you -1 it?
>
> During the discussion there were some concerns but I think my implementation
> should have addressed all concerns. I created an issue and put up a patch.
> This was available for 4 days now. Besides you no one else took the time to
> review the patch.
>
> So from your review you wrote you were concernd that the implementation does
> not implement all features of the feature file and people might want more.
> Does this really warrant a -1 ?
>
> Christian
>
> Am 25.05.2012 17:08, schrieb Guillaume Nodet:
>
>> Can you please revert.  I think 3 people expressed concerns with the
>> patch, so i'm officially -1 it until this concerns have been fully
>> addressed and we've reached a consensus.
>>
>> On Fri, May 25, 2012 at 4:41 PM, Christian Schneider
>> <ch...@die-schneider.net>  wrote:
>>>
>>> I have now committed the patch. So you should be able to test from trunk
>>> now.
>>>
>>>
>>> Christian
>>>
>>> Am 23.05.2012 17:44, schrieb Andrei Pozolotin:
>>>>
>>>>     Christian:
>>>>
>>>>
>>>>     I am curious
>>>>
>>>>     1) are your changes are in current karaf 3 snapshot?
>>>>
>>>>     2) do you have example/test project that shows how to build
>>>>     karaf distro w/o startup.properties, with minimal feature=framework
>>>>     only?
>>>>
>>>>     3) or is the idea discarded?
>>>>
>>>>     Thank you,
>>>>
>>>>     Andrei
>>>>
>>> --
>>> Christian Schneider
>>> http://www.liquid-reality.de
>>>
>>> Open Source Architect
>>> Talend Application Integration Division http://www.talend.com
>>>
>>
>>
>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> Talend Application Integration Division http://www.talend.com
>



-- 
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
FuseSource, Integration everywhere
http://fusesource.com

Re: [Discuss] Handling of initial bundles

[Christian Schneider <ch...@die-schneider.net>]

I thought we had settled all these concerns.
So what are the concerns regarding the commit that make you -1 it?

During the discussion there were some concerns but I think my 
implementation should have addressed all concerns. I created an issue 
and put up a patch. This was available for 4 days now. Besides you no 
one else took the time to review the patch.

So from your review you wrote you were concernd that the implementation 
does not implement all features of the feature file and people might 
want more. Does this really warrant a -1 ?

Christian

Am 25.05.2012 17:08, schrieb Guillaume Nodet:
> Can you please revert.  I think 3 people expressed concerns with the
> patch, so i'm officially -1 it until this concerns have been fully
> addressed and we've reached a consensus.
>
> On Fri, May 25, 2012 at 4:41 PM, Christian Schneider
> <ch...@die-schneider.net>  wrote:
>> I have now committed the patch. So you should be able to test from trunk
>> now.
>>
>>
>> Christian
>>
>> Am 23.05.2012 17:44, schrieb Andrei Pozolotin:
>>>      Christian:
>>>
>>>
>>>      I am curious
>>>
>>>      1) are your changes are in current karaf 3 snapshot?
>>>
>>>      2) do you have example/test project that shows how to build
>>>      karaf distro w/o startup.properties, with minimal feature=framework
>>>      only?
>>>
>>>      3) or is the idea discarded?
>>>
>>>      Thank you,
>>>
>>>      Andrei
>>>
>> --
>> Christian Schneider
>> http://www.liquid-reality.de
>>
>> Open Source Architect
>> Talend Application Integration Division http://www.talend.com
>>
>
>


-- 
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
Talend Application Integration Division http://www.talend.com

Re: [Discuss] Handling of initial bundles

[Guillaume Nodet <gn...@gmail.com>]

Can you please revert.  I think 3 people expressed concerns with the
patch, so i'm officially -1 it until this concerns have been fully
addressed and we've reached a consensus.

On Fri, May 25, 2012 at 4:41 PM, Christian Schneider
<ch...@die-schneider.net> wrote:
> I have now committed the patch. So you should be able to test from trunk
> now.
>
>
> Christian
>
> Am 23.05.2012 17:44, schrieb Andrei Pozolotin:
>>
>>     Christian:
>>
>>
>>     I am curious
>>
>>     1) are your changes are in current karaf 3 snapshot?
>>
>>     2) do you have example/test project that shows how to build
>>     karaf distro w/o startup.properties, with minimal feature=framework
>>     only?
>>
>>     3) or is the idea discarded?
>>
>>     Thank you,
>>
>>     Andrei
>>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> Talend Application Integration Division http://www.talend.com
>



-- 
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
FuseSource, Integration everywhere
http://fusesource.com

Re: [Discuss] Handling of initial bundles

[Christian Schneider <ch...@die-schneider.net>]

I have now committed the patch. So you should be able to test from trunk 
now.

Christian

Am 23.05.2012 17:44, schrieb Andrei Pozolotin:
>      Christian:
>
>      I am curious
>
>      1) are your changes are in current karaf 3 snapshot?
>
>      2) do you have example/test project that shows how to build
>      karaf distro w/o startup.properties, with minimal feature=framework
>      only?
>
>      3) or is the idea discarded?
>
>      Thank you,
>
>      Andrei
>

-- 
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
Talend Application Integration Division http://www.talend.com

Re: [Discuss] Handling of initial bundles

[Andrei Pozolotin <an...@gmail.com>]

    Christian:

    I am curious

    1) are your changes are in current karaf 3 snapshot?

    2) do you have example/test project that shows how to build
    karaf distro w/o startup.properties, with minimal feature=framework
    only?

    3) or is the idea discarded?

    Thank you,

    Andrei



-------- Original Message  --------
Subject: Re: [Discuss] Handling of initial bundles
From: Christian Schneider <ch...@die-schneider.net>
To: dev@karaf.apache.org
Date: Tue 08 May 2012 11:26:49 AM CDT
>
>
> Am 08.05.2012 17:49, schrieb David Jencks:
>> I really don't understand what problem you are trying to solve.  Most
>> people won't use a custom assembly or if they do will use the same
>> startup.properties as our assemblies.  Anyone who needs to construct
>> a custom set of startup bundles isn't going to be worried by the
>> startup.properties format, that is a tiny detail compared with
>> figuring out what you need to get a working server from startup bundles.
> The advantage is that we do not need the extra step to create the
> startup.properties. The advantage is small though. So if there is a
> majority for not implementing the feature
> reading I will not do it.
>>
>> I agree with Guillaume that keeping the startup code simple is a very
>> high priority.  To me, adding anything that involves xml to the
>> startup code is a really bad idea and would require very clear and
>> overwhelming advantages to be considered.
>>
>> I've never suggested reading more than one feature during startup.  I
>> think the current approach of generating startup.properties from
>> features specified in the assembly's pom is just fine.
> That is what I meant. That you wrote we need to be able to combine
> several features into startup.properties. If we would do this with
> pure features it would mean that we need to be able to use more than
> one feature.
>
> Christian
>>
>> thanks
>> david jencks
>>
>> On May 8, 2012, at 12:01 AM, Christian Schneider wrote:
>>
>>> I would like to summarize the discussion about my proposed second
>>> step to replace the startup.properties by a feature loading. Again
>>> sorry that I committed the first part too early.
>>> I think though that our discussion mainly was about the second part
>>> and I did not even start to implement that.
>>>
>>> Here the requirements people wrote during the discussion:
>>> - We should not introduce additional dependencies into the main module
>>> - Some people like the startup.properties. So we should keep this
>>> feature
>>> - In addition to the maven urls we should also support loading
>>> bundles from a flat directory structure
>>> - We should allow several features from several feature files to be
>>> used at startup
>>>
>>> So this is what I propose to fullfill the above requirements:
>>> - If a startup.properties file exists then the bundles in there will
>>> be loaded and started (works already)
>>> - We introduce two new optional properties for config.properties:
>>> startup.feature.url and startup.feature.name (default:framework)
>>> - If the startup.feature.url property is present then we resolve the
>>> startup.feature.url using the ArtifactResolver and read the named
>>> feature. We then install all bundles in the
>>> feature with their corresponding startlevels
>>> - We allow to use file names in the startup.properties that are
>>> searched in system and bundle.locations. This allows the flat
>>> structure. (Works already)
>>> - We read the feature file using jaxb but not with the feaure
>>> service. Instead we simply use annotated pojos
>>> - We switch the build process of our framework feature to not
>>> generate the startup.properties anymore and instead use the new
>>> properties to reference the existing
>>> feature
>>> - I propose to not implement the possibility to use more than one
>>> feature in the startup as this feature is only used to bootstrap the
>>> distro. I dont think custom distros need to change that behaviour
>>>
>>> Pro:
>>> - Makes our build simpler
>>> - Makes our itests simpler as we do not need to sync the
>>> startup.properties anymore by hand
>>> - People who already know the feature concept do not have to learn
>>> the new concept of the startup.properties
>>>
>>> Con:
>>> - We have an additional description of a feature file in main. I
>>> think this is not so bad as we keep it to the minimum. We should
>>> also detect discrepancies very fast as the
>>> itests will fail
>>>
>>> Christian
>>>
>>> Am 04.05.2012 19:03, schrieb Christian Schneider:
>>>> Hi all,
>>>>
>>>> on startup we currently use the following procedure.
>>>>
>>>> We read property karaf.auto.start from the file config.properties.
>>>> This can be either a list of bundles separated by spaces or
>>>> "startup.properties" or "all".
>>>> If it is all we replace karaf.auto.start with the list of all
>>>> bundles in the system dir. I think this option does not really make
>>>> much sense.
>>>> If it is startup.properties then we replace karaf.auto.start with
>>>> the list of bundles specified in the file startup.properties.
>>>> Additionally we either support mvn urls or paths which are
>>>> converted to mvn urls.
>>>>
>>>> This all is quite a lot of variability of which we use none.
>>>>
>>>> I propose to replace this in two steps:
>>>>
>>>> 1. Remove the karaf.auto.start property and always load the bundles
>>>> from startup.properties. Also only support mvn urls.
>>>> This makes the code in main cleaner and makes it easier for our
>>>> users to understand how to change the startup bundles.
>>>>
>>>> 2. Remove the startup.properties and instead use a feature name to
>>>> determine the list of bundles to load
>>>> The second step makes this even simpler and additionally we can
>>>> remove the generation of the startup.properties in the karaf maven
>>>> plugin.
>>>>
>>>> So what do you think?
>>>>
>>>> Christian
>>>>
>>>
>>> -- 
>>> Christian Schneider
>>> http://www.liquid-reality.de
>>>
>>> Open Source Architect
>>> Talend Application Integration Division http://www.talend.com
>>>
>
>

Re: [Discuss] Handling of initial bundles

[Christian Schneider <ch...@die-schneider.net>]

Am 08.05.2012 17:49, schrieb David Jencks:
> I really don't understand what problem you are trying to solve.  Most people won't use a custom assembly or if they do will use the same startup.properties as our assemblies.  Anyone who needs to construct a custom set of startup bundles isn't going to be worried by the startup.properties format, that is a tiny detail compared with figuring out what you need to get a working server from startup bundles.
The advantage is that we do not need the extra step to create the 
startup.properties. The advantage is small though. So if there is a 
majority for not implementing the feature
reading I will not do it.
>
> I agree with Guillaume that keeping the startup code simple is a very high priority.  To me, adding anything that involves xml to the startup code is a really bad idea and would require very clear and overwhelming advantages to be considered.
>
> I've never suggested reading more than one feature during startup.  I think the current approach of generating startup.properties from features specified in the assembly's pom is just fine.
That is what I meant. That you wrote we need to be able to combine 
several features into startup.properties. If we would do this with pure 
features it would mean that we need to be able to use more than one feature.

Christian
>
> thanks
> david jencks
>
> On May 8, 2012, at 12:01 AM, Christian Schneider wrote:
>
>> I would like to summarize the discussion about my proposed second step to replace the startup.properties by a feature loading. Again sorry that I committed the first part too early.
>> I think though that our discussion mainly was about the second part and I did not even start to implement that.
>>
>> Here the requirements people wrote during the discussion:
>> - We should not introduce additional dependencies into the main module
>> - Some people like the startup.properties. So we should keep this feature
>> - In addition to the maven urls we should also support loading bundles from a flat directory structure
>> - We should allow several features from several feature files to be used at startup
>>
>> So this is what I propose to fullfill the above requirements:
>> - If a startup.properties file exists then the bundles in there will be loaded and started (works already)
>> - We introduce two new optional properties for config.properties: startup.feature.url and startup.feature.name (default:framework)
>> - If the startup.feature.url property is present then we resolve the startup.feature.url using the ArtifactResolver and read the named feature. We then install all bundles in the
>> feature with their corresponding startlevels
>> - We allow to use file names in the startup.properties that are searched in system and bundle.locations. This allows the flat structure. (Works already)
>> - We read the feature file using jaxb but not with the feaure service. Instead we simply use annotated pojos
>> - We switch the build process of our framework feature to not generate the startup.properties anymore and instead use the new properties to reference the existing
>> feature
>> - I propose to not implement the possibility to use more than one feature in the startup as this feature is only used to bootstrap the distro. I dont think custom distros need to change that behaviour
>>
>> Pro:
>> - Makes our build simpler
>> - Makes our itests simpler as we do not need to sync the startup.properties anymore by hand
>> - People who already know the feature concept do not have to learn the new concept of the startup.properties
>>
>> Con:
>> - We have an additional description of a feature file in main. I think this is not so bad as we keep it to the minimum. We should also detect discrepancies very fast as the
>> itests will fail
>>
>> Christian
>>
>> Am 04.05.2012 19:03, schrieb Christian Schneider:
>>> Hi all,
>>>
>>> on startup we currently use the following procedure.
>>>
>>> We read property karaf.auto.start from the file config.properties.
>>> This can be either a list of bundles separated by spaces or "startup.properties" or "all".
>>> If it is all we replace karaf.auto.start with the list of all bundles in the system dir. I think this option does not really make much sense.
>>> If it is startup.properties then we replace karaf.auto.start with the list of bundles specified in the file startup.properties.
>>> Additionally we either support mvn urls or paths which are converted to mvn urls.
>>>
>>> This all is quite a lot of variability of which we use none.
>>>
>>> I propose to replace this in two steps:
>>>
>>> 1. Remove the karaf.auto.start property and always load the bundles from startup.properties. Also only support mvn urls.
>>> This makes the code in main cleaner and makes it easier for our users to understand how to change the startup bundles.
>>>
>>> 2. Remove the startup.properties and instead use a feature name to determine the list of bundles to load
>>> The second step makes this even simpler and additionally we can remove the generation of the startup.properties in the karaf maven plugin.
>>>
>>> So what do you think?
>>>
>>> Christian
>>>
>>
>> -- 
>> Christian Schneider
>> http://www.liquid-reality.de
>>
>> Open Source Architect
>> Talend Application Integration Division http://www.talend.com
>>


-- 
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
Talend Application Integration Division http://www.talend.com

Re: [Discuss] Handling of initial bundles

[David Jencks <da...@yahoo.com>]

I really don't understand what problem you are trying to solve.  Most people won't use a custom assembly or if they do will use the same startup.properties as our assemblies.  Anyone who needs to construct a custom set of startup bundles isn't going to be worried by the startup.properties format, that is a tiny detail compared with figuring out what you need to get a working server from startup bundles.

I agree with Guillaume that keeping the startup code simple is a very high priority.  To me, adding anything that involves xml to the startup code is a really bad idea and would require very clear and overwhelming advantages to be considered.

I've never suggested reading more than one feature during startup.  I think the current approach of generating startup.properties from features specified in the assembly's pom is just fine.

thanks
david jencks

On May 8, 2012, at 12:01 AM, Christian Schneider wrote:

> I would like to summarize the discussion about my proposed second step to replace the startup.properties by a feature loading. Again sorry that I committed the first part too early.
> I think though that our discussion mainly was about the second part and I did not even start to implement that.
> 
> Here the requirements people wrote during the discussion:
> - We should not introduce additional dependencies into the main module
> - Some people like the startup.properties. So we should keep this feature
> - In addition to the maven urls we should also support loading bundles from a flat directory structure
> - We should allow several features from several feature files to be used at startup
> 
> So this is what I propose to fullfill the above requirements:
> - If a startup.properties file exists then the bundles in there will be loaded and started (works already)
> - We introduce two new optional properties for config.properties: startup.feature.url and startup.feature.name (default:framework)
> - If the startup.feature.url property is present then we resolve the startup.feature.url using the ArtifactResolver and read the named feature. We then install all bundles in the
> feature with their corresponding startlevels
> - We allow to use file names in the startup.properties that are searched in system and bundle.locations. This allows the flat structure. (Works already)
> - We read the feature file using jaxb but not with the feaure service. Instead we simply use annotated pojos
> - We switch the build process of our framework feature to not generate the startup.properties anymore and instead use the new properties to reference the existing
> feature
> - I propose to not implement the possibility to use more than one feature in the startup as this feature is only used to bootstrap the distro. I dont think custom distros need to change that behaviour
> 
> Pro:
> - Makes our build simpler
> - Makes our itests simpler as we do not need to sync the startup.properties anymore by hand
> - People who already know the feature concept do not have to learn the new concept of the startup.properties
> 
> Con:
> - We have an additional description of a feature file in main. I think this is not so bad as we keep it to the minimum. We should also detect discrepancies very fast as the
> itests will fail
> 
> Christian
> 
> Am 04.05.2012 19:03, schrieb Christian Schneider:
>> Hi all,
>> 
>> on startup we currently use the following procedure.
>> 
>> We read property karaf.auto.start from the file config.properties.
>> This can be either a list of bundles separated by spaces or "startup.properties" or "all".
>> If it is all we replace karaf.auto.start with the list of all bundles in the system dir. I think this option does not really make much sense.
>> If it is startup.properties then we replace karaf.auto.start with the list of bundles specified in the file startup.properties.
>> Additionally we either support mvn urls or paths which are converted to mvn urls.
>> 
>> This all is quite a lot of variability of which we use none.
>> 
>> I propose to replace this in two steps:
>> 
>> 1. Remove the karaf.auto.start property and always load the bundles from startup.properties. Also only support mvn urls.
>> This makes the code in main cleaner and makes it easier for our users to understand how to change the startup bundles.
>> 
>> 2. Remove the startup.properties and instead use a feature name to determine the list of bundles to load
>> The second step makes this even simpler and additionally we can remove the generation of the startup.properties in the karaf maven plugin.
>> 
>> So what do you think?
>> 
>> Christian
>> 
> 
> 
> -- 
> Christian Schneider
> http://www.liquid-reality.de
> 
> Open Source Architect
> Talend Application Integration Division http://www.talend.com
> 

Re: [Discuss] Handling of initial bundles

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

There are some startup.properties "static" for tests (for instance in 
the instance tests).

But it should not be the case ;)

Regards
JB

On 05/08/2012 11:21 AM, Andreas Pieber wrote:
> uuhhhh, no :-)
>
> The startup.properties is completely created from the framework
> features.xml :-) The only startup.properties you find in an empty
> trunk are:
>
> pieber@prime karaf]$ find -name startup.properties
> ./main/src/test/resources/test-karaf-home/etc/startup.properties
> ./itests/tests/src/test/resources/org/apache/karaf/testing/startup.properties
> ./instance/core/src/test/resources/etc/startup.properties
>
> @./main/src/test/resources/test-karaf-home/etc/startup.properties
>
> for unittests
>
> @./itests/tests/src/test/resources/org/apache/karaf/testing/startup.properties
>
> no idea why this one is here. I'll remove it; it does nothing in the
> karaf testframework we're using for our itests.
>
> @./instance/core/src/test/resources/etc/startup.properties
>
> for unittests
>
> So there is no need for manually editing any startup.property files
> (and even less for the itests).
>
> Kind regards,
> Andreas
>
> On Tue, May 8, 2012 at 10:29 AM, Christian Schneider
> <ch...@die-schneider.net>  wrote:
>> Honestly I am not sure. I just see that we have a startup.properties in the
>> resources dir and learned that we have to keep it in sync with the
>> startup.properties from the
>> framework feature.
>>
>> So perhaps this is not necessary anymore? Can we delete this file then?
>>
>> Christian
>>
>> Am 08.05.2012 10:19, schrieb Andreas Pieber:
>>
>>> Hey,
>>>
>>> On Tue, May 8, 2012 at 9:01 AM, Christian Schneider
>>> <ch...@die-schneider.net>    wrote:
>>>>
>>>> </SKIP>
>>>> - Makes our itests simpler as we do not need to sync the
>>>> startup.properties
>>>> anymore by hand
>>>
>>> Please explain that point in more detail. TBH I don't really get it
>>> how this will speed up the itests. Our itests (at least on the trunk)
>>> are based on the labs-paxexam-karaf bundles (well, the version moved
>>> to trunk) which is based on the assembly, not on anything build on the
>>> fly? *confused*.
>>>
>>> Kind regards,
>>> Andreas
>>>
>>
>> --
>> Christian Schneider
>> http://www.liquid-reality.de
>>
>> Open Source Architect
>> Talend Application Integration Division http://www.talend.com
>>

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

Re: [Discuss] Handling of initial bundles

[Andreas Pieber <an...@gmail.com>]

uuhhhh, no :-)

The startup.properties is completely created from the framework
features.xml :-) The only startup.properties you find in an empty
trunk are:

pieber@prime karaf]$ find -name startup.properties
./main/src/test/resources/test-karaf-home/etc/startup.properties
./itests/tests/src/test/resources/org/apache/karaf/testing/startup.properties
./instance/core/src/test/resources/etc/startup.properties

@./main/src/test/resources/test-karaf-home/etc/startup.properties

for unittests

@./itests/tests/src/test/resources/org/apache/karaf/testing/startup.properties

no idea why this one is here. I'll remove it; it does nothing in the
karaf testframework we're using for our itests.

@./instance/core/src/test/resources/etc/startup.properties

for unittests

So there is no need for manually editing any startup.property files
(and even less for the itests).

Kind regards,
Andreas

On Tue, May 8, 2012 at 10:29 AM, Christian Schneider
<ch...@die-schneider.net> wrote:
> Honestly I am not sure. I just see that we have a startup.properties in the
> resources dir and learned that we have to keep it in sync with the
> startup.properties from the
> framework feature.
>
> So perhaps this is not necessary anymore? Can we delete this file then?
>
> Christian
>
> Am 08.05.2012 10:19, schrieb Andreas Pieber:
>
>> Hey,
>>
>> On Tue, May 8, 2012 at 9:01 AM, Christian Schneider
>> <ch...@die-schneider.net>  wrote:
>>>
>>> </SKIP>
>>> - Makes our itests simpler as we do not need to sync the
>>> startup.properties
>>> anymore by hand
>>
>> Please explain that point in more detail. TBH I don't really get it
>> how this will speed up the itests. Our itests (at least on the trunk)
>> are based on the labs-paxexam-karaf bundles (well, the version moved
>> to trunk) which is based on the assembly, not on anything build on the
>> fly? *confused*.
>>
>> Kind regards,
>> Andreas
>>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> Talend Application Integration Division http://www.talend.com
>

Re: [Discuss] Handling of initial bundles

[Christian Schneider <ch...@die-schneider.net>]

Honestly I am not sure. I just see that we have a startup.properties in 
the resources dir and learned that we have to keep it in sync with the 
startup.properties from the
framework feature.

So perhaps this is not necessary anymore? Can we delete this file then?

Christian

Am 08.05.2012 10:19, schrieb Andreas Pieber:
> Hey,
>
> On Tue, May 8, 2012 at 9:01 AM, Christian Schneider
> <ch...@die-schneider.net>  wrote:
>> </SKIP>
>> - Makes our itests simpler as we do not need to sync the startup.properties
>> anymore by hand
> Please explain that point in more detail. TBH I don't really get it
> how this will speed up the itests. Our itests (at least on the trunk)
> are based on the labs-paxexam-karaf bundles (well, the version moved
> to trunk) which is based on the assembly, not on anything build on the
> fly? *confused*.
>
> Kind regards,
> Andreas
>

-- 
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
Talend Application Integration Division http://www.talend.com

Re: [Discuss] Handling of initial bundles

[Andreas Pieber <an...@gmail.com>]

Hey,

On Tue, May 8, 2012 at 9:01 AM, Christian Schneider
<ch...@die-schneider.net> wrote:
> </SKIP>
> - Makes our itests simpler as we do not need to sync the startup.properties
> anymore by hand

Please explain that point in more detail. TBH I don't really get it
how this will speed up the itests. Our itests (at least on the trunk)
are based on the labs-paxexam-karaf bundles (well, the version moved
to trunk) which is based on the assembly, not on anything build on the
fly? *confused*.

Kind regards,
Andreas

> - People who already know the feature concept do not have to learn the new
> concept of the startup.properties
>
> Con:
> - We have an additional description of a feature file in main. I think this
> is not so bad as we keep it to the minimum. We should also detect
> discrepancies very fast as the
> itests will fail
>
> Christian
>
> Am 04.05.2012 19:03, schrieb Christian Schneider:
>
>> Hi all,
>>
>> on startup we currently use the following procedure.
>>
>> We read property karaf.auto.start from the file config.properties.
>> This can be either a list of bundles separated by spaces or
>> "startup.properties" or "all".
>> If it is all we replace karaf.auto.start with the list of all bundles in
>> the system dir. I think this option does not really make much sense.
>> If it is startup.properties then we replace karaf.auto.start with the list
>> of bundles specified in the file startup.properties.
>> Additionally we either support mvn urls or paths which are converted to
>> mvn urls.
>>
>> This all is quite a lot of variability of which we use none.
>>
>> I propose to replace this in two steps:
>>
>> 1. Remove the karaf.auto.start property and always load the bundles from
>> startup.properties. Also only support mvn urls.
>> This makes the code in main cleaner and makes it easier for our users to
>> understand how to change the startup bundles.
>>
>> 2. Remove the startup.properties and instead use a feature name to
>> determine the list of bundles to load
>> The second step makes this even simpler and additionally we can remove the
>> generation of the startup.properties in the karaf maven plugin.
>>
>> So what do you think?
>>
>> Christian
>>
>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> Talend Application Integration Division http://www.talend.com
>

Re: [Discuss] Handling of initial bundles

[Christian Schneider <ch...@die-schneider.net>]

I would like to summarize the discussion about my proposed second step 
to replace the startup.properties by a feature loading. Again sorry that 
I committed the first part too early.
I think though that our discussion mainly was about the second part and 
I did not even start to implement that.

Here the requirements people wrote during the discussion:
- We should not introduce additional dependencies into the main module
- Some people like the startup.properties. So we should keep this feature
- In addition to the maven urls we should also support loading bundles 
from a flat directory structure
- We should allow several features from several feature files to be used 
at startup

So this is what I propose to fullfill the above requirements:
- If a startup.properties file exists then the bundles in there will be 
loaded and started (works already)
- We introduce two new optional properties for config.properties: 
startup.feature.url and startup.feature.name (default:framework)
- If the startup.feature.url property is present then we resolve the 
startup.feature.url using the ArtifactResolver and read the named 
feature. We then install all bundles in the
feature with their corresponding startlevels
- We allow to use file names in the startup.properties that are searched 
in system and bundle.locations. This allows the flat structure. (Works 
already)
- We read the feature file using jaxb but not with the feaure service. 
Instead we simply use annotated pojos
- We switch the build process of our framework feature to not generate 
the startup.properties anymore and instead use the new properties to 
reference the existing
feature
- I propose to not implement the possibility to use more than one 
feature in the startup as this feature is only used to bootstrap the 
distro. I dont think custom distros need to change that behaviour

Pro:
- Makes our build simpler
- Makes our itests simpler as we do not need to sync the 
startup.properties anymore by hand
- People who already know the feature concept do not have to learn the 
new concept of the startup.properties

Con:
- We have an additional description of a feature file in main. I think 
this is not so bad as we keep it to the minimum. We should also detect 
discrepancies very fast as the
itests will fail

Christian

Am 04.05.2012 19:03, schrieb Christian Schneider:
> Hi all,
>
> on startup we currently use the following procedure.
>
> We read property karaf.auto.start from the file config.properties.
> This can be either a list of bundles separated by spaces or 
> "startup.properties" or "all".
> If it is all we replace karaf.auto.start with the list of all bundles 
> in the system dir. I think this option does not really make much sense.
> If it is startup.properties then we replace karaf.auto.start with the 
> list of bundles specified in the file startup.properties.
> Additionally we either support mvn urls or paths which are converted 
> to mvn urls.
>
> This all is quite a lot of variability of which we use none.
>
> I propose to replace this in two steps:
>
> 1. Remove the karaf.auto.start property and always load the bundles 
> from startup.properties. Also only support mvn urls.
> This makes the code in main cleaner and makes it easier for our users 
> to understand how to change the startup bundles.
>
> 2. Remove the startup.properties and instead use a feature name to 
> determine the list of bundles to load
> The second step makes this even simpler and additionally we can remove 
> the generation of the startup.properties in the karaf maven plugin.
>
> So what do you think?
>
> Christian
>


-- 
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
Talend Application Integration Division http://www.talend.com