You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@karaf.apache.org by mikevan <mv...@comcast.net> on 2011/05/03 20:46:46 UTC
[DISCUSS] Karaf-Max assembly
For folks developing applications to deploy into Karaf on closed networks, it
is not always feasable to be able to download all the optional packages for
which we have optional console commands. I'm thinking web:, http:, obr:,
and the like.
I propse we create a new assembly for karaf that will include all of the
optional bundles in the system directory for use in closed-networks. After
talking about this topic on IRC it seems that many of us developing on
closed networks have created work-arounds for this. Because there are so
many work-arounds, perhaps its time to have a single Karaf-Max deployment
that contains all of the optional bundles for karaf.
If it helps, I can write it... :-)
-----
Mike Van (aka karafman)
Karaf Team (Contributor)
--
View this message in context: http://karaf.922171.n3.nabble.com/DISCUSS-Karaf-Max-assembly-tp2895460p2895460.html
Sent from the Karaf - Dev mailing list archive at Nabble.com.
Re: [DISCUSS] Karaf-Max assembly
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Mike,
It could be interested. AFAIR, David worked on the new MOJO and the full
distribution provide quite the same thing.
We can guarantee a "standard" Karaf full distribution but not a custom
Karaf distribution.
Anyway, as I said in previous threads, as soon as Karaf 2.2.1 is out, we
will focus on trunk to deeper test the assemblies and new MOJOs.
I'm agree to include this kind of distribution (even if it could be a
large one :)).
Regards
JB
On 05/03/2011 08:46 PM, mikevan wrote:
> For folks developing applications to deploy into Karaf on closed networks, it
> is not always feasable to be able to download all the optional packages for
> which we have optional console commands. I'm thinking web:, http:, obr:,
> and the like.
>
> I propse we create a new assembly for karaf that will include all of the
> optional bundles in the system directory for use in closed-networks. After
> talking about this topic on IRC it seems that many of us developing on
> closed networks have created work-arounds for this. Because there are so
> many work-arounds, perhaps its time to have a single Karaf-Max deployment
> that contains all of the optional bundles for karaf.
>
> If it helps, I can write it... :-)
>
> -----
> Mike Van (aka karafman)
> Karaf Team (Contributor)
> --
> View this message in context: http://karaf.922171.n3.nabble.com/DISCUSS-Karaf-Max-assembly-tp2895460p2895460.html
> Sent from the Karaf - Dev mailing list archive at Nabble.com.
Re: [DISCUSS] Karaf-Max assembly
Posted by mikevan <mv...@comcast.net>.
David Jencks wrote:
>
> Hi Mike,
>
> karaf-full is supposed to be identical to the non-minimal karaf assembly
> from the old style assembly.
>
> I have no objection to your proposal and I think it would be pretty
> trivial to make such an assembly using the karaf-assembly packaging.
>
> I'm curious about the environment you are in that would make it easier to
> import an assembly containing 150 bundles 50 of which you don't use than
> the 100 you do use.
>
> thanks
> david jencks
>
> On May 3, 2011, at 12:22 PM, mikevan wrote:
>
>>
>> mikevan wrote:
>>>
>>> For folks developing applications to deploy into Karaf on closed
>>> networks,
>>> it is not always feasable to be able to download all the optional
>>> packages
>>> for which we have optional console commands. I'm thinking web:, http:,
>>> obr:, and the like.
>>>
>>> I propse we create a new assembly for karaf that will include all of the
>>> optional bundles in the system directory for use in closed-networks.
>>> After talking about this topic on IRC it seems that many of us
>>> developing
>>> on closed networks have created work-arounds for this. Because there
>>> are
>>> so many work-arounds, perhaps its time to have a single Karaf-Max
>>> deployment that contains all of the optional bundles for karaf.
>>>
>>> If it helps, I can write it... :-)
>>>
>>
>> After further research, we currently have a karaf-full kar and assembly.
>> However, it doesn't look like karaf-full contains all of the optional
>> dependent bundles. What was supposed to go into karaf-full? Does that
>> suffice the use-case expressed above? If not, would it be appropriate to
>> have a new assembly addressing the karaf-max usecase?
>>
>> David J, What are you thoughts on this?
>>
>>
>> -----
>> Mike Van (aka karafman)
>> Karaf Team (Contributor)
>> --
>> View this message in context:
>> http://karaf.922171.n3.nabble.com/DISCUSS-Karaf-Max-assembly-tp2895460p2895601.html
>> Sent from the Karaf - Dev mailing list archive at Nabble.com.
>
If we talk in terms of the use-case presented, this would be an assembly for
users who are developing on a closed-network. A closed-network in this case
would be a network with no external connectivity to the internet. In the
IRC room, several folks came up with specific types of clients they'd worked
with that had a closed-network as defined above. Examples presented there
included corporate clients like banks, although many customers with strong
security would fall within that category.
As users become more karaf-savvy, it is certainly forseeable that they would
begin leveraging more of the optional packages that karaf-max would contain.
For example, when I first started using Karaf, I had no idea what obr was,
but now I use that set of functionality quite a bit, and have provided
patches to increase the functionality of obr. Another example would be the
pax-web packages which make it easier to deploy servlets into Karaf. A user
using JMS would not necessarily care about that, however with many
web-services moving to REST, having access to the optional http: and war:
features would make lives easier.
To extend the use-case to make it more understandable, I would assume
karaf-max would be a development-only environment. After a user has
developed an application using karaf-max, they would likely create a kar out
of the files they have deployed as bundles. Or, in my case, generate a
local maven repository containing those specific bundles and an
applicatiom-specific features.xml file. In that case, the actual deployment
would be done using karaf-minimal, and the kar or local maven repository.
I hope this makes sense.
-----
Mike Van (aka karafman)
Karaf Team (Contributor)
--
View this message in context: http://karaf.922171.n3.nabble.com/DISCUSS-Karaf-Max-assembly-tp2895460p2895743.html
Sent from the Karaf - Dev mailing list archive at Nabble.com.
Re: [DISCUSS] Karaf-Max assembly
Posted by David Jencks <da...@yahoo.com>.
Hi Mike,
karaf-full is supposed to be identical to the non-minimal karaf assembly from the old style assembly.
I have no objection to your proposal and I think it would be pretty trivial to make such an assembly using the karaf-assembly packaging.
I'm curious about the environment you are in that would make it easier to import an assembly containing 150 bundles 50 of which you don't use than the 100 you do use.
thanks
david jencks
On May 3, 2011, at 12:22 PM, mikevan wrote:
>
> mikevan wrote:
>>
>> For folks developing applications to deploy into Karaf on closed networks,
>> it is not always feasable to be able to download all the optional packages
>> for which we have optional console commands. I'm thinking web:, http:,
>> obr:, and the like.
>>
>> I propse we create a new assembly for karaf that will include all of the
>> optional bundles in the system directory for use in closed-networks.
>> After talking about this topic on IRC it seems that many of us developing
>> on closed networks have created work-arounds for this. Because there are
>> so many work-arounds, perhaps its time to have a single Karaf-Max
>> deployment that contains all of the optional bundles for karaf.
>>
>> If it helps, I can write it... :-)
>>
>
> After further research, we currently have a karaf-full kar and assembly.
> However, it doesn't look like karaf-full contains all of the optional
> dependent bundles. What was supposed to go into karaf-full? Does that
> suffice the use-case expressed above? If not, would it be appropriate to
> have a new assembly addressing the karaf-max usecase?
>
> David J, What are you thoughts on this?
>
>
> -----
> Mike Van (aka karafman)
> Karaf Team (Contributor)
> --
> View this message in context: http://karaf.922171.n3.nabble.com/DISCUSS-Karaf-Max-assembly-tp2895460p2895601.html
> Sent from the Karaf - Dev mailing list archive at Nabble.com.
Re: [DISCUSS] Karaf-Max assembly
Posted by mikevan <mv...@comcast.net>.
mikevan wrote:
>
> For folks developing applications to deploy into Karaf on closed networks,
> it is not always feasable to be able to download all the optional packages
> for which we have optional console commands. I'm thinking web:, http:,
> obr:, and the like.
>
> I propse we create a new assembly for karaf that will include all of the
> optional bundles in the system directory for use in closed-networks.
> After talking about this topic on IRC it seems that many of us developing
> on closed networks have created work-arounds for this. Because there are
> so many work-arounds, perhaps its time to have a single Karaf-Max
> deployment that contains all of the optional bundles for karaf.
>
> If it helps, I can write it... :-)
>
After further research, we currently have a karaf-full kar and assembly.
However, it doesn't look like karaf-full contains all of the optional
dependent bundles. What was supposed to go into karaf-full? Does that
suffice the use-case expressed above? If not, would it be appropriate to
have a new assembly addressing the karaf-max usecase?
David J, What are you thoughts on this?
-----
Mike Van (aka karafman)
Karaf Team (Contributor)
--
View this message in context: http://karaf.922171.n3.nabble.com/DISCUSS-Karaf-Max-assembly-tp2895460p2895601.html
Sent from the Karaf - Dev mailing list archive at Nabble.com.
Re: [DISCUSS] Karaf-Max assembly
Posted by Christian Schneider <ch...@die-schneider.net>.
I understand that. What I meant is that you setup your distro in a place
with internet connection and then bring the distribution zip into the
closed environment.
Christian
Am 03.05.2011 22:56, schrieb Achim Nierbeck:
> Hi Christian,
>
> well the scenario Mike is talking of you are not able to download your
> dependencies at all.
> There are certain environments where you merely don't get the desired
> downloads,
> especially with maven.
>
> so yes I can understand and support the idea of building an additional
> distro including all
> optional features.
>
> regards, Achim
>
>> Hi Mike,
>>
>> while this is sure possible it would be quite big. Especially if you
>> also would include other projects like camel or activemq.
>>
>> Instead I propose to add some commands to karaf to download
>> dependencies to the sytem dir. So the user could load karaf. Add the
>> feature url he needs and with some simple commands download them to
>> the system dir. Then he can zip the distro again and use it in the
>> closed environment.
>>
>> I think that would be much more flexible.
>>
>> Christian
>>
>>
>> Am 03.05.2011 20:46, schrieb mikevan:
>>> For folks developing applications to deploy into Karaf on closed
>>> networks, it
>>> is not always feasable to be able to download all the optional
>>> packages for
>>> which we have optional console commands. I'm thinking web:, http:,
>>> obr:,
>>> and the like.
>>>
>>> I propse we create a new assembly for karaf that will include all of the
>>> optional bundles in the system directory for use in closed-networks.
>>> After
>>> talking about this topic on IRC it seems that many of us developing on
>>> closed networks have created work-arounds for this. Because there
>>> are so
>>> many work-arounds, perhaps its time to have a single Karaf-Max
>>> deployment
>>> that contains all of the optional bundles for karaf.
>>>
>>> If it helps, I can write it... :-)
>>>
>>> -----
>>> Mike Van (aka karafman)
>>> Karaf Team (Contributor)
>>> --
>>> View this message in context:
>>> http://karaf.922171.n3.nabble.com/DISCUSS-Karaf-Max-assembly-tp2895460p2895460.html
>>> Sent from the Karaf - Dev mailing list archive at Nabble.com.
>>>
>
--
----
http://www.liquid-reality.de
Re: [DISCUSS] Karaf-Max assembly
Posted by Achim Nierbeck <bc...@googlemail.com>.
Hi Christian,
well the scenario Mike is talking of you are not able to download your
dependencies at all.
There are certain environments where you merely don't get the desired
downloads,
especially with maven.
so yes I can understand and support the idea of building an additional
distro including all
optional features.
regards, Achim
> Hi Mike,
>
> while this is sure possible it would be quite big. Especially if you
> also would include other projects like camel or activemq.
>
> Instead I propose to add some commands to karaf to download
> dependencies to the sytem dir. So the user could load karaf. Add the
> feature url he needs and with some simple commands download them to
> the system dir. Then he can zip the distro again and use it in the
> closed environment.
>
> I think that would be much more flexible.
>
> Christian
>
>
> Am 03.05.2011 20:46, schrieb mikevan:
>> For folks developing applications to deploy into Karaf on closed
>> networks, it
>> is not always feasable to be able to download all the optional
>> packages for
>> which we have optional console commands. I'm thinking web:, http:,
>> obr:,
>> and the like.
>>
>> I propse we create a new assembly for karaf that will include all of the
>> optional bundles in the system directory for use in closed-networks.
>> After
>> talking about this topic on IRC it seems that many of us developing on
>> closed networks have created work-arounds for this. Because there
>> are so
>> many work-arounds, perhaps its time to have a single Karaf-Max
>> deployment
>> that contains all of the optional bundles for karaf.
>>
>> If it helps, I can write it... :-)
>>
>> -----
>> Mike Van (aka karafman)
>> Karaf Team (Contributor)
>> --
>> View this message in context:
>> http://karaf.922171.n3.nabble.com/DISCUSS-Karaf-Max-assembly-tp2895460p2895460.html
>> Sent from the Karaf - Dev mailing list archive at Nabble.com.
>>
>
Re: [DISCUSS] Karaf-Max assembly
Posted by "Jamie G." <ja...@gmail.com>.
That sounds cool, I like it :)
On Wed, May 4, 2011 at 1:08 PM, Andreas Pieber <an...@gmail.com> wrote:
> TBH I see this a little bit different. Basically I think we should
> offer only two distributions. One "online" and one "offline". The
> online distribution contains only the absolute bare and minimum system
> (similar to the min distribution now) and would be the "new"
> apache-karaf distribution. This one is the default distribution
> starting up with the bare minimum and the user can install anything he
> wants using features:install getting them online. The offline should
> contain all artifacts (even if it becomes quite big).
>
> IMHO the feature system is sufficient enough (and easy enough to
> understand and use) that this should work.
>
> BUT what I do think could be useful is to add "ueber-features". E.g.
> features:install karaf-clusteredserver, karaf-webserver,
> karaf-obrserver should represent our distribution. I think if we add
> this information in the default startup header
>
> {code}
> KARAF
>
> press tab for ...
>
> To transform karaf into a specific distribution use
>
> * features:install karaf-clusterservice (for a clustered version...
> * ...
> {code}
>
> That way we can be quite minimal and focus on the real code providing
> all distributions only "virtually"... WDYT?
>
> Kind regards,
> Andreas
> On Wed, May 4, 2011 at 5:26 PM, Jamie G. <ja...@gmail.com> wrote:
>> Actually further on to the side discussion of specialized distros,
>> this is something that should be covered in the Karaf user manual.
>> Perhaps a section on how to customize our minimal and/or full distros
>> into a web, OBR, or cluster distro? This would provide our users with
>> plenty of examples of how to go about using our tooling and keep out
>> release foot print more manageable.
>>
>> Cheers,
>> J
>>
>> On Wed, May 4, 2011 at 12:14 PM, Jamie G. <ja...@gmail.com> wrote:
>>> I have to say from my perspective offering specialized distributions
>>> doesn't make sense. It should be that users can customize distros
>>> easily via the tooling provided by Karaf. At release time we'll end up
>>> with dozens of release kits for testing and validation (src-zip,
>>> scr-tar,gz, zip, and tar.gz times N distributions).
>>>
>>> Cheers,
>>> Jamie
>>>
>>> On Wed, May 4, 2011 at 11:36 AM, Guillaume Nodet <gn...@gmail.com> wrote:
>>>> Well, the problem is that if we want to offer more using optional
>>>> features, we'll end up with a big bunch of bundles anyway.
>>>> I'm not completely convinced. As discussed in the other thread, I
>>>> wonder if having dedicated distributions for web, obr server,
>>>> clustering would make more sense.
>>>>
>>>> On Wed, May 4, 2011 at 15:52, mikevan <mv...@comcast.net> wrote:
>>>>>
>>>>> Christian Schneider wrote:
>>>>>>
>>>>>> Hi Mike,
>>>>>>
>>>>>> while this is sure possible it would be quite big. Especially if you
>>>>>> also would include other projects like camel or activemq.
>>>>>>
>>>>>> Instead I propose to add some commands to karaf to download dependencies
>>>>>> to the sytem dir. So the user could load karaf. Add the feature url he
>>>>>> needs and with some simple commands download them to the system dir.
>>>>>> Then he can zip the distro again and use it in the closed environment.
>>>>>>
>>>>>> I think that would be much more flexible.
>>>>>>
>>>>>> Christian
>>>>>>
>>>>>>
>>>>>> Am 03.05.2011 20:46, schrieb mikevan:
>>>>>>> For folks developing applications to deploy into Karaf on closed
>>>>>>> networks, it
>>>>>>> is not always feasable to be able to download all the optional packages
>>>>>>> for
>>>>>>> which we have optional console commands. I'm thinking web:, http:, obr:,
>>>>>>> and the like.
>>>>>>>
>>>>>>> I propse we create a new assembly for karaf that will include all of the
>>>>>>> optional bundles in the system directory for use in closed-networks.
>>>>>>> After
>>>>>>> talking about this topic on IRC it seems that many of us developing on
>>>>>>> closed networks have created work-arounds for this. Because there are so
>>>>>>> many work-arounds, perhaps its time to have a single Karaf-Max deployment
>>>>>>> that contains all of the optional bundles for karaf.
>>>>>>>
>>>>>>> If it helps, I can write it... :-)
>>>>>>>
>>>>>>> -----
>>>>>>> Mike Van (aka karafman)
>>>>>>> Karaf Team (Contributor)
>>>>>>> --
>>>>>>> View this message in context:
>>>>>>> http://karaf.922171.n3.nabble.com/DISCUSS-Karaf-Max-assembly-tp2895460p2895460.html
>>>>>>> Sent from the Karaf - Dev mailing list archive at Nabble.com.
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> ----
>>>>>> http://www.liquid-reality.de
>>>>>>
>>>>>
>>>>> Another way to think of what would be included in karaf-max is that anything
>>>>> referenced in the karaf features.xml file (think mandatory features and
>>>>> optional features) would be included in the karaf-max release. With this in
>>>>> mind, Apache projects that can be used in Karaf, but aren't referenced in
>>>>> the karaf features.xml documents would not be included. So, ActiveMQ would
>>>>> not be part of the distibution, Camel would not be part of the distribution.
>>>>> However, Aries (included in the enterprise features.xml document) would be,
>>>>> as would the shell libraries for web and obr.
>>>>>
>>>>> Pls let me know if this clarifies things for you.
>>>>>
>>>>> -----
>>>>> Mike Van (aka karafman)
>>>>> Karaf Team (Contributor)
>>>>> --
>>>>> View this message in context: http://karaf.922171.n3.nabble.com/DISCUSS-Karaf-Max-assembly-tp2895460p2898918.html
>>>>> Sent from the Karaf - Dev mailing list archive at Nabble.com.
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Cheers,
>>>> Guillaume Nodet
>>>> ------------------------
>>>> Blog: http://gnodet.blogspot.com/
>>>> ------------------------
>>>> Open Source SOA
>>>> http://fusesource.com
>>>>
>>>> Connect at CamelOne May 24-26
>>>> The Open Source Integration Conference
>>>> http://camelone.com/
>>>>
>>>
>>
>
Re: [DISCUSS] Karaf-Max assembly
Posted by Andreas Pieber <an...@gmail.com>.
TBH I see this a little bit different. Basically I think we should
offer only two distributions. One "online" and one "offline". The
online distribution contains only the absolute bare and minimum system
(similar to the min distribution now) and would be the "new"
apache-karaf distribution. This one is the default distribution
starting up with the bare minimum and the user can install anything he
wants using features:install getting them online. The offline should
contain all artifacts (even if it becomes quite big).
IMHO the feature system is sufficient enough (and easy enough to
understand and use) that this should work.
BUT what I do think could be useful is to add "ueber-features". E.g.
features:install karaf-clusteredserver, karaf-webserver,
karaf-obrserver should represent our distribution. I think if we add
this information in the default startup header
{code}
KARAF
press tab for ...
To transform karaf into a specific distribution use
* features:install karaf-clusterservice (for a clustered version...
* ...
{code}
That way we can be quite minimal and focus on the real code providing
all distributions only "virtually"... WDYT?
Kind regards,
Andreas
On Wed, May 4, 2011 at 5:26 PM, Jamie G. <ja...@gmail.com> wrote:
> Actually further on to the side discussion of specialized distros,
> this is something that should be covered in the Karaf user manual.
> Perhaps a section on how to customize our minimal and/or full distros
> into a web, OBR, or cluster distro? This would provide our users with
> plenty of examples of how to go about using our tooling and keep out
> release foot print more manageable.
>
> Cheers,
> J
>
> On Wed, May 4, 2011 at 12:14 PM, Jamie G. <ja...@gmail.com> wrote:
>> I have to say from my perspective offering specialized distributions
>> doesn't make sense. It should be that users can customize distros
>> easily via the tooling provided by Karaf. At release time we'll end up
>> with dozens of release kits for testing and validation (src-zip,
>> scr-tar,gz, zip, and tar.gz times N distributions).
>>
>> Cheers,
>> Jamie
>>
>> On Wed, May 4, 2011 at 11:36 AM, Guillaume Nodet <gn...@gmail.com> wrote:
>>> Well, the problem is that if we want to offer more using optional
>>> features, we'll end up with a big bunch of bundles anyway.
>>> I'm not completely convinced. As discussed in the other thread, I
>>> wonder if having dedicated distributions for web, obr server,
>>> clustering would make more sense.
>>>
>>> On Wed, May 4, 2011 at 15:52, mikevan <mv...@comcast.net> wrote:
>>>>
>>>> Christian Schneider wrote:
>>>>>
>>>>> Hi Mike,
>>>>>
>>>>> while this is sure possible it would be quite big. Especially if you
>>>>> also would include other projects like camel or activemq.
>>>>>
>>>>> Instead I propose to add some commands to karaf to download dependencies
>>>>> to the sytem dir. So the user could load karaf. Add the feature url he
>>>>> needs and with some simple commands download them to the system dir.
>>>>> Then he can zip the distro again and use it in the closed environment.
>>>>>
>>>>> I think that would be much more flexible.
>>>>>
>>>>> Christian
>>>>>
>>>>>
>>>>> Am 03.05.2011 20:46, schrieb mikevan:
>>>>>> For folks developing applications to deploy into Karaf on closed
>>>>>> networks, it
>>>>>> is not always feasable to be able to download all the optional packages
>>>>>> for
>>>>>> which we have optional console commands. I'm thinking web:, http:, obr:,
>>>>>> and the like.
>>>>>>
>>>>>> I propse we create a new assembly for karaf that will include all of the
>>>>>> optional bundles in the system directory for use in closed-networks.
>>>>>> After
>>>>>> talking about this topic on IRC it seems that many of us developing on
>>>>>> closed networks have created work-arounds for this. Because there are so
>>>>>> many work-arounds, perhaps its time to have a single Karaf-Max deployment
>>>>>> that contains all of the optional bundles for karaf.
>>>>>>
>>>>>> If it helps, I can write it... :-)
>>>>>>
>>>>>> -----
>>>>>> Mike Van (aka karafman)
>>>>>> Karaf Team (Contributor)
>>>>>> --
>>>>>> View this message in context:
>>>>>> http://karaf.922171.n3.nabble.com/DISCUSS-Karaf-Max-assembly-tp2895460p2895460.html
>>>>>> Sent from the Karaf - Dev mailing list archive at Nabble.com.
>>>>>>
>>>>>
>>>>> --
>>>>> ----
>>>>> http://www.liquid-reality.de
>>>>>
>>>>
>>>> Another way to think of what would be included in karaf-max is that anything
>>>> referenced in the karaf features.xml file (think mandatory features and
>>>> optional features) would be included in the karaf-max release. With this in
>>>> mind, Apache projects that can be used in Karaf, but aren't referenced in
>>>> the karaf features.xml documents would not be included. So, ActiveMQ would
>>>> not be part of the distibution, Camel would not be part of the distribution.
>>>> However, Aries (included in the enterprise features.xml document) would be,
>>>> as would the shell libraries for web and obr.
>>>>
>>>> Pls let me know if this clarifies things for you.
>>>>
>>>> -----
>>>> Mike Van (aka karafman)
>>>> Karaf Team (Contributor)
>>>> --
>>>> View this message in context: http://karaf.922171.n3.nabble.com/DISCUSS-Karaf-Max-assembly-tp2895460p2898918.html
>>>> Sent from the Karaf - Dev mailing list archive at Nabble.com.
>>>>
>>>
>>>
>>>
>>> --
>>> Cheers,
>>> Guillaume Nodet
>>> ------------------------
>>> Blog: http://gnodet.blogspot.com/
>>> ------------------------
>>> Open Source SOA
>>> http://fusesource.com
>>>
>>> Connect at CamelOne May 24-26
>>> The Open Source Integration Conference
>>> http://camelone.com/
>>>
>>
>
Re: [DISCUSS] Karaf-Max assembly
Posted by "Jamie G." <ja...@gmail.com>.
Actually further on to the side discussion of specialized distros,
this is something that should be covered in the Karaf user manual.
Perhaps a section on how to customize our minimal and/or full distros
into a web, OBR, or cluster distro? This would provide our users with
plenty of examples of how to go about using our tooling and keep out
release foot print more manageable.
Cheers,
J
On Wed, May 4, 2011 at 12:14 PM, Jamie G. <ja...@gmail.com> wrote:
> I have to say from my perspective offering specialized distributions
> doesn't make sense. It should be that users can customize distros
> easily via the tooling provided by Karaf. At release time we'll end up
> with dozens of release kits for testing and validation (src-zip,
> scr-tar,gz, zip, and tar.gz times N distributions).
>
> Cheers,
> Jamie
>
> On Wed, May 4, 2011 at 11:36 AM, Guillaume Nodet <gn...@gmail.com> wrote:
>> Well, the problem is that if we want to offer more using optional
>> features, we'll end up with a big bunch of bundles anyway.
>> I'm not completely convinced. As discussed in the other thread, I
>> wonder if having dedicated distributions for web, obr server,
>> clustering would make more sense.
>>
>> On Wed, May 4, 2011 at 15:52, mikevan <mv...@comcast.net> wrote:
>>>
>>> Christian Schneider wrote:
>>>>
>>>> Hi Mike,
>>>>
>>>> while this is sure possible it would be quite big. Especially if you
>>>> also would include other projects like camel or activemq.
>>>>
>>>> Instead I propose to add some commands to karaf to download dependencies
>>>> to the sytem dir. So the user could load karaf. Add the feature url he
>>>> needs and with some simple commands download them to the system dir.
>>>> Then he can zip the distro again and use it in the closed environment.
>>>>
>>>> I think that would be much more flexible.
>>>>
>>>> Christian
>>>>
>>>>
>>>> Am 03.05.2011 20:46, schrieb mikevan:
>>>>> For folks developing applications to deploy into Karaf on closed
>>>>> networks, it
>>>>> is not always feasable to be able to download all the optional packages
>>>>> for
>>>>> which we have optional console commands. I'm thinking web:, http:, obr:,
>>>>> and the like.
>>>>>
>>>>> I propse we create a new assembly for karaf that will include all of the
>>>>> optional bundles in the system directory for use in closed-networks.
>>>>> After
>>>>> talking about this topic on IRC it seems that many of us developing on
>>>>> closed networks have created work-arounds for this. Because there are so
>>>>> many work-arounds, perhaps its time to have a single Karaf-Max deployment
>>>>> that contains all of the optional bundles for karaf.
>>>>>
>>>>> If it helps, I can write it... :-)
>>>>>
>>>>> -----
>>>>> Mike Van (aka karafman)
>>>>> Karaf Team (Contributor)
>>>>> --
>>>>> View this message in context:
>>>>> http://karaf.922171.n3.nabble.com/DISCUSS-Karaf-Max-assembly-tp2895460p2895460.html
>>>>> Sent from the Karaf - Dev mailing list archive at Nabble.com.
>>>>>
>>>>
>>>> --
>>>> ----
>>>> http://www.liquid-reality.de
>>>>
>>>
>>> Another way to think of what would be included in karaf-max is that anything
>>> referenced in the karaf features.xml file (think mandatory features and
>>> optional features) would be included in the karaf-max release. With this in
>>> mind, Apache projects that can be used in Karaf, but aren't referenced in
>>> the karaf features.xml documents would not be included. So, ActiveMQ would
>>> not be part of the distibution, Camel would not be part of the distribution.
>>> However, Aries (included in the enterprise features.xml document) would be,
>>> as would the shell libraries for web and obr.
>>>
>>> Pls let me know if this clarifies things for you.
>>>
>>> -----
>>> Mike Van (aka karafman)
>>> Karaf Team (Contributor)
>>> --
>>> View this message in context: http://karaf.922171.n3.nabble.com/DISCUSS-Karaf-Max-assembly-tp2895460p2898918.html
>>> Sent from the Karaf - Dev mailing list archive at Nabble.com.
>>>
>>
>>
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>>
>> Connect at CamelOne May 24-26
>> The Open Source Integration Conference
>> http://camelone.com/
>>
>
Re: [DISCUSS] Karaf-Max assembly
Posted by "Jamie G." <ja...@gmail.com>.
I have to say from my perspective offering specialized distributions
doesn't make sense. It should be that users can customize distros
easily via the tooling provided by Karaf. At release time we'll end up
with dozens of release kits for testing and validation (src-zip,
scr-tar,gz, zip, and tar.gz times N distributions).
Cheers,
Jamie
On Wed, May 4, 2011 at 11:36 AM, Guillaume Nodet <gn...@gmail.com> wrote:
> Well, the problem is that if we want to offer more using optional
> features, we'll end up with a big bunch of bundles anyway.
> I'm not completely convinced. As discussed in the other thread, I
> wonder if having dedicated distributions for web, obr server,
> clustering would make more sense.
>
> On Wed, May 4, 2011 at 15:52, mikevan <mv...@comcast.net> wrote:
>>
>> Christian Schneider wrote:
>>>
>>> Hi Mike,
>>>
>>> while this is sure possible it would be quite big. Especially if you
>>> also would include other projects like camel or activemq.
>>>
>>> Instead I propose to add some commands to karaf to download dependencies
>>> to the sytem dir. So the user could load karaf. Add the feature url he
>>> needs and with some simple commands download them to the system dir.
>>> Then he can zip the distro again and use it in the closed environment.
>>>
>>> I think that would be much more flexible.
>>>
>>> Christian
>>>
>>>
>>> Am 03.05.2011 20:46, schrieb mikevan:
>>>> For folks developing applications to deploy into Karaf on closed
>>>> networks, it
>>>> is not always feasable to be able to download all the optional packages
>>>> for
>>>> which we have optional console commands. I'm thinking web:, http:, obr:,
>>>> and the like.
>>>>
>>>> I propse we create a new assembly for karaf that will include all of the
>>>> optional bundles in the system directory for use in closed-networks.
>>>> After
>>>> talking about this topic on IRC it seems that many of us developing on
>>>> closed networks have created work-arounds for this. Because there are so
>>>> many work-arounds, perhaps its time to have a single Karaf-Max deployment
>>>> that contains all of the optional bundles for karaf.
>>>>
>>>> If it helps, I can write it... :-)
>>>>
>>>> -----
>>>> Mike Van (aka karafman)
>>>> Karaf Team (Contributor)
>>>> --
>>>> View this message in context:
>>>> http://karaf.922171.n3.nabble.com/DISCUSS-Karaf-Max-assembly-tp2895460p2895460.html
>>>> Sent from the Karaf - Dev mailing list archive at Nabble.com.
>>>>
>>>
>>> --
>>> ----
>>> http://www.liquid-reality.de
>>>
>>
>> Another way to think of what would be included in karaf-max is that anything
>> referenced in the karaf features.xml file (think mandatory features and
>> optional features) would be included in the karaf-max release. With this in
>> mind, Apache projects that can be used in Karaf, but aren't referenced in
>> the karaf features.xml documents would not be included. So, ActiveMQ would
>> not be part of the distibution, Camel would not be part of the distribution.
>> However, Aries (included in the enterprise features.xml document) would be,
>> as would the shell libraries for web and obr.
>>
>> Pls let me know if this clarifies things for you.
>>
>> -----
>> Mike Van (aka karafman)
>> Karaf Team (Contributor)
>> --
>> View this message in context: http://karaf.922171.n3.nabble.com/DISCUSS-Karaf-Max-assembly-tp2895460p2898918.html
>> Sent from the Karaf - Dev mailing list archive at Nabble.com.
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
> Connect at CamelOne May 24-26
> The Open Source Integration Conference
> http://camelone.com/
>
Re: [DISCUSS] Karaf-Max assembly
Posted by Guillaume Nodet <gn...@gmail.com>.
Well, the problem is that if we want to offer more using optional
features, we'll end up with a big bunch of bundles anyway.
I'm not completely convinced. As discussed in the other thread, I
wonder if having dedicated distributions for web, obr server,
clustering would make more sense.
On Wed, May 4, 2011 at 15:52, mikevan <mv...@comcast.net> wrote:
>
> Christian Schneider wrote:
>>
>> Hi Mike,
>>
>> while this is sure possible it would be quite big. Especially if you
>> also would include other projects like camel or activemq.
>>
>> Instead I propose to add some commands to karaf to download dependencies
>> to the sytem dir. So the user could load karaf. Add the feature url he
>> needs and with some simple commands download them to the system dir.
>> Then he can zip the distro again and use it in the closed environment.
>>
>> I think that would be much more flexible.
>>
>> Christian
>>
>>
>> Am 03.05.2011 20:46, schrieb mikevan:
>>> For folks developing applications to deploy into Karaf on closed
>>> networks, it
>>> is not always feasable to be able to download all the optional packages
>>> for
>>> which we have optional console commands. I'm thinking web:, http:, obr:,
>>> and the like.
>>>
>>> I propse we create a new assembly for karaf that will include all of the
>>> optional bundles in the system directory for use in closed-networks.
>>> After
>>> talking about this topic on IRC it seems that many of us developing on
>>> closed networks have created work-arounds for this. Because there are so
>>> many work-arounds, perhaps its time to have a single Karaf-Max deployment
>>> that contains all of the optional bundles for karaf.
>>>
>>> If it helps, I can write it... :-)
>>>
>>> -----
>>> Mike Van (aka karafman)
>>> Karaf Team (Contributor)
>>> --
>>> View this message in context:
>>> http://karaf.922171.n3.nabble.com/DISCUSS-Karaf-Max-assembly-tp2895460p2895460.html
>>> Sent from the Karaf - Dev mailing list archive at Nabble.com.
>>>
>>
>> --
>> ----
>> http://www.liquid-reality.de
>>
>
> Another way to think of what would be included in karaf-max is that anything
> referenced in the karaf features.xml file (think mandatory features and
> optional features) would be included in the karaf-max release. With this in
> mind, Apache projects that can be used in Karaf, but aren't referenced in
> the karaf features.xml documents would not be included. So, ActiveMQ would
> not be part of the distibution, Camel would not be part of the distribution.
> However, Aries (included in the enterprise features.xml document) would be,
> as would the shell libraries for web and obr.
>
> Pls let me know if this clarifies things for you.
>
> -----
> Mike Van (aka karafman)
> Karaf Team (Contributor)
> --
> View this message in context: http://karaf.922171.n3.nabble.com/DISCUSS-Karaf-Max-assembly-tp2895460p2898918.html
> Sent from the Karaf - Dev mailing list archive at Nabble.com.
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Connect at CamelOne May 24-26
The Open Source Integration Conference
http://camelone.com/
Re: [DISCUSS] Karaf-Max assembly
Posted by mikevan <mv...@comcast.net>.
Christian Schneider wrote:
>
> Hi Mike,
>
> while this is sure possible it would be quite big. Especially if you
> also would include other projects like camel or activemq.
>
> Instead I propose to add some commands to karaf to download dependencies
> to the sytem dir. So the user could load karaf. Add the feature url he
> needs and with some simple commands download them to the system dir.
> Then he can zip the distro again and use it in the closed environment.
>
> I think that would be much more flexible.
>
> Christian
>
>
> Am 03.05.2011 20:46, schrieb mikevan:
>> For folks developing applications to deploy into Karaf on closed
>> networks, it
>> is not always feasable to be able to download all the optional packages
>> for
>> which we have optional console commands. I'm thinking web:, http:, obr:,
>> and the like.
>>
>> I propse we create a new assembly for karaf that will include all of the
>> optional bundles in the system directory for use in closed-networks.
>> After
>> talking about this topic on IRC it seems that many of us developing on
>> closed networks have created work-arounds for this. Because there are so
>> many work-arounds, perhaps its time to have a single Karaf-Max deployment
>> that contains all of the optional bundles for karaf.
>>
>> If it helps, I can write it... :-)
>>
>> -----
>> Mike Van (aka karafman)
>> Karaf Team (Contributor)
>> --
>> View this message in context:
>> http://karaf.922171.n3.nabble.com/DISCUSS-Karaf-Max-assembly-tp2895460p2895460.html
>> Sent from the Karaf - Dev mailing list archive at Nabble.com.
>>
>
> --
> ----
> http://www.liquid-reality.de
>
Another way to think of what would be included in karaf-max is that anything
referenced in the karaf features.xml file (think mandatory features and
optional features) would be included in the karaf-max release. With this in
mind, Apache projects that can be used in Karaf, but aren't referenced in
the karaf features.xml documents would not be included. So, ActiveMQ would
not be part of the distibution, Camel would not be part of the distribution.
However, Aries (included in the enterprise features.xml document) would be,
as would the shell libraries for web and obr.
Pls let me know if this clarifies things for you.
-----
Mike Van (aka karafman)
Karaf Team (Contributor)
--
View this message in context: http://karaf.922171.n3.nabble.com/DISCUSS-Karaf-Max-assembly-tp2895460p2898918.html
Sent from the Karaf - Dev mailing list archive at Nabble.com.
Re: [DISCUSS] Karaf-Max assembly
Posted by Christian Schneider <ch...@die-schneider.net>.
Exactly this approval process is what I wanted to support with my
proposal. You create your own distro in an easy way and have exactly
what you need. This will make approval easier.
We could of course also create a max assembly and combine it with a
custom distro functionality. So people could downlaod the max assembly
into their closed environment. Then use some commands to create their
own stripped down distro. Which they can then feed into approval.
Christian
Am 04.05.2011 00:25, schrieb David Jencks:
> Hi Christian,
>
> You can do this right now in trunk with a karaf-assembly project.
>
> I don't see how it really helps in a closed environment, nor do I understand how the proposed karaf-max will help. In my experience when you have a closed environment there's an approval process to get stuff into it. Despite Mike's first answer to me, I still don't understand how packaging 150 bundles into an assembly when you only need 100 will make that approval process easier. I'd also expect a closed environment to need to make most of the imported artifacts available to the build system which AFAICT neither Mike nor your proposal address.
>
> And, I still don't have any problem with adding such a mega-assembly. I don't think it will help anyone in a closed environment but it does seem like it might make all the possibilities easier to discover and play with.
>
> thanks
> david jencks
>
> On May 3, 2011, at 1:45 PM, Christian Schneider wrote:
>
>> Hi Mike,
>>
>> while this is sure possible it would be quite big. Especially if you also would include other projects like camel or activemq.
>>
>> Instead I propose to add some commands to karaf to download dependencies to the sytem dir. So the user could load karaf. Add the feature url he needs and with some simple commands download them to the system dir. Then he can zip the distro again and use it in the closed environment.
>>
>> I think that would be much more flexible.
>>
>> Christian
>>
>>
>> Am 03.05.2011 20:46, schrieb mikevan:
>>> For folks developing applications to deploy into Karaf on closed networks, it
>>> is not always feasable to be able to download all the optional packages for
>>> which we have optional console commands. I'm thinking web:, http:, obr:,
>>> and the like.
>>>
>>> I propse we create a new assembly for karaf that will include all of the
>>> optional bundles in the system directory for use in closed-networks. After
>>> talking about this topic on IRC it seems that many of us developing on
>>> closed networks have created work-arounds for this. Because there are so
>>> many work-arounds, perhaps its time to have a single Karaf-Max deployment
>>> that contains all of the optional bundles for karaf.
>>>
>>> If it helps, I can write it... :-)
>>>
>>> -----
>>> Mike Van (aka karafman)
>>> Karaf Team (Contributor)
>>> --
>>> View this message in context: http://karaf.922171.n3.nabble.com/DISCUSS-Karaf-Max-assembly-tp2895460p2895460.html
>>> Sent from the Karaf - Dev mailing list archive at Nabble.com.
>>>
>> --
>> ----
>> http://www.liquid-reality.de
>>
>
--
----
http://www.liquid-reality.de
Re: [DISCUSS] Karaf-Max assembly
Posted by David Jencks <da...@yahoo.com>.
Hi Christian,
You can do this right now in trunk with a karaf-assembly project.
I don't see how it really helps in a closed environment, nor do I understand how the proposed karaf-max will help. In my experience when you have a closed environment there's an approval process to get stuff into it. Despite Mike's first answer to me, I still don't understand how packaging 150 bundles into an assembly when you only need 100 will make that approval process easier. I'd also expect a closed environment to need to make most of the imported artifacts available to the build system which AFAICT neither Mike nor your proposal address.
And, I still don't have any problem with adding such a mega-assembly. I don't think it will help anyone in a closed environment but it does seem like it might make all the possibilities easier to discover and play with.
thanks
david jencks
On May 3, 2011, at 1:45 PM, Christian Schneider wrote:
> Hi Mike,
>
> while this is sure possible it would be quite big. Especially if you also would include other projects like camel or activemq.
>
> Instead I propose to add some commands to karaf to download dependencies to the sytem dir. So the user could load karaf. Add the feature url he needs and with some simple commands download them to the system dir. Then he can zip the distro again and use it in the closed environment.
>
> I think that would be much more flexible.
>
> Christian
>
>
> Am 03.05.2011 20:46, schrieb mikevan:
>> For folks developing applications to deploy into Karaf on closed networks, it
>> is not always feasable to be able to download all the optional packages for
>> which we have optional console commands. I'm thinking web:, http:, obr:,
>> and the like.
>>
>> I propse we create a new assembly for karaf that will include all of the
>> optional bundles in the system directory for use in closed-networks. After
>> talking about this topic on IRC it seems that many of us developing on
>> closed networks have created work-arounds for this. Because there are so
>> many work-arounds, perhaps its time to have a single Karaf-Max deployment
>> that contains all of the optional bundles for karaf.
>>
>> If it helps, I can write it... :-)
>>
>> -----
>> Mike Van (aka karafman)
>> Karaf Team (Contributor)
>> --
>> View this message in context: http://karaf.922171.n3.nabble.com/DISCUSS-Karaf-Max-assembly-tp2895460p2895460.html
>> Sent from the Karaf - Dev mailing list archive at Nabble.com.
>>
>
> --
> ----
> http://www.liquid-reality.de
>
Re: [DISCUSS] Karaf-Max assembly
Posted by Christian Schneider <ch...@die-schneider.net>.
Hi Mike,
while this is sure possible it would be quite big. Especially if you
also would include other projects like camel or activemq.
Instead I propose to add some commands to karaf to download dependencies
to the sytem dir. So the user could load karaf. Add the feature url he
needs and with some simple commands download them to the system dir.
Then he can zip the distro again and use it in the closed environment.
I think that would be much more flexible.
Christian
Am 03.05.2011 20:46, schrieb mikevan:
> For folks developing applications to deploy into Karaf on closed networks, it
> is not always feasable to be able to download all the optional packages for
> which we have optional console commands. I'm thinking web:, http:, obr:,
> and the like.
>
> I propse we create a new assembly for karaf that will include all of the
> optional bundles in the system directory for use in closed-networks. After
> talking about this topic on IRC it seems that many of us developing on
> closed networks have created work-arounds for this. Because there are so
> many work-arounds, perhaps its time to have a single Karaf-Max deployment
> that contains all of the optional bundles for karaf.
>
> If it helps, I can write it... :-)
>
> -----
> Mike Van (aka karafman)
> Karaf Team (Contributor)
> --
> View this message in context: http://karaf.922171.n3.nabble.com/DISCUSS-Karaf-Max-assembly-tp2895460p2895460.html
> Sent from the Karaf - Dev mailing list archive at Nabble.com.
>
--
----
http://www.liquid-reality.de