Features and OBR

classic Classic list List threaded Threaded
69 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Features and OBR

Guillaume Nodet
I've just added support for pluggable resolvers for features.
I've also created an OBR based resolver that is installed with the obr feature.

Now you can do the following:

  <feature name="xx" version="yy" resolver="obr">
      <bundle>bundle:(&(symbolicname=org.apache.camel.camel-blueprint)(version>=2.4.0)(version<2.4.1))</bundle>
  </feature>

If OBR has been configured with the needed repositories, it will
install camel-blueprint bundle with all the required dependencies.
The benefit is that you don't have to specify all the dependencies,
but only the key bundles.  The added benefit is that the deployment
will leverage what is already installed and you don't have to maintain
an homogeneous set of repositories (for example, you should not have
to specify which version of spring you want to use and obr will reuse
the one installed if possible, or choose which one to install based on
the constraints expressed by the bundles).

I haven't updated the feature descriptor yet, mostly because we don't
have a obr repository which contain all the bundles we need.
I have one locally that contain all the bundles present on maven
central, but it's a bit too big to be used in this context, so not
sure how to handle that yet.

Anyway, just wanted to give a heads up on that.

--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Reply | Threaded
Open this post in threaded view
|

Re: Features and OBR

David Jencks

On Jul 2, 2010, at 8:03 AM, Guillaume Nodet wrote:

> I've just added support for pluggable resolvers for features.
> I've also created an OBR based resolver that is installed with the obr feature.
>
> Now you can do the following:
>
>  <feature name="xx" version="yy" resolver="obr">
>      <bundle>bundle:(&(symbolicname=org.apache.camel.camel-blueprint)(version>=2.4.0)(version<2.4.1))</bundle>
>  </feature>
>
> If OBR has been configured with the needed repositories, it will
> install camel-blueprint bundle with all the required dependencies.
> The benefit is that you don't have to specify all the dependencies,
> but only the key bundles.  The added benefit is that the deployment
> will leverage what is already installed and you don't have to maintain
> an homogeneous set of repositories (for example, you should not have
> to specify which version of spring you want to use and obr will reuse
> the one installed if possible, or choose which one to install based on
> the constraints expressed by the bundles).
>
> I haven't updated the feature descriptor yet, mostly because we don't
> have a obr repository which contain all the bundles we need.
> I have one locally that contain all the bundles present on maven
> central, but it's a bit too big to be used in this context, so not
> sure how to handle that yet.
>
> Anyway, just wanted to give a heads up on that.


One of the points of friction I see between maven and osgi is that in maven you explicitly  specify which artifacts supply your needed dependencies whereas in osgi they magically appear from something like OBR.  I've always wondered where the OBR-like info is supposed to come from.  On the other hand, if you are using maven to build, you have a reasonable set of candidate artifacts in the maven dependencies (assuming they are all bundles).

Something I started experimenting with in geronimo is to, for each feature, construct an OBR xml file out of the maven dependencies.  Just before you try to install the feature, you add the obr fragment to the OBR instance you are using for resolving the feature.  This pretty much assures that something that will enable the bundles in the features to resolve will be available.  

Writing the code for this was easy, but we weren't relying enough on OBR at the time to find out how well it works in practice.  I have been wondering if anyone else would think this is a reasonable approach to investigate.

thanks
david jencks
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com

Reply | Threaded
Open this post in threaded view
|

Re: Features and OBR

Guillaume Nodet
That could be a good way.  I haven't experimented that really, but I
think it would at least give the freedom to the resolver to reuse
locally installed bundles, so that's obviously a really good start.

As for OBR itself, I've added to the maven bundle plugin a goal that
can be used to build an obr repository out of a maven repository in a
directory.  This goal can also generated maven urls instead of the
file:// urls that it would give.  Thus giving an additional
indirection in the url instead of pointing directly to the http
location.

I think from a production pov, what would be needed is some kind of
maven repository (nexus or archiva) coupled with an OBR repository.
This way, the deployer would be responsibe for adding authorized
artifacts in the repository and that would automatically update an obr
repository descriptor with the added artifacts.
The problem is that this way of seeing the problem does not work well
in a non controlled environment such as most users do when they allow
access to maven central ... So in that case, your approach of using
the maven dependencies could be a good solution.

On Fri, Jul 2, 2010 at 18:34, David Jencks <[hidden email]> wrote:

>
> On Jul 2, 2010, at 8:03 AM, Guillaume Nodet wrote:
>
>> I've just added support for pluggable resolvers for features.
>> I've also created an OBR based resolver that is installed with the obr feature.
>>
>> Now you can do the following:
>>
>>  <feature name="xx" version="yy" resolver="obr">
>>      <bundle>bundle:(&(symbolicname=org.apache.camel.camel-blueprint)(version>=2.4.0)(version<2.4.1))</bundle>
>>  </feature>
>>
>> If OBR has been configured with the needed repositories, it will
>> install camel-blueprint bundle with all the required dependencies.
>> The benefit is that you don't have to specify all the dependencies,
>> but only the key bundles.  The added benefit is that the deployment
>> will leverage what is already installed and you don't have to maintain
>> an homogeneous set of repositories (for example, you should not have
>> to specify which version of spring you want to use and obr will reuse
>> the one installed if possible, or choose which one to install based on
>> the constraints expressed by the bundles).
>>
>> I haven't updated the feature descriptor yet, mostly because we don't
>> have a obr repository which contain all the bundles we need.
>> I have one locally that contain all the bundles present on maven
>> central, but it's a bit too big to be used in this context, so not
>> sure how to handle that yet.
>>
>> Anyway, just wanted to give a heads up on that.
>
>
> One of the points of friction I see between maven and osgi is that in maven you explicitly  specify which artifacts supply your needed dependencies whereas in osgi they magically appear from something like OBR.  I've always wondered where the OBR-like info is supposed to come from.  On the other hand, if you are using maven to build, you have a reasonable set of candidate artifacts in the maven dependencies (assuming they are all bundles).
>
> Something I started experimenting with in geronimo is to, for each feature, construct an OBR xml file out of the maven dependencies.  Just before you try to install the feature, you add the obr fragment to the OBR instance you are using for resolving the feature.  This pretty much assures that something that will enable the bundles in the features to resolve will be available.
>
> Writing the code for this was easy, but we weren't relying enough on OBR at the time to find out how well it works in practice.  I have been wondering if anyone else would think this is a reasonable approach to investigate.
>
> thanks
> david jencks
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>
>



--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Reply | Threaded
Open this post in threaded view
|

Re: Features and OBR

Guillaume Nodet
I think I have a solution to partially solve the problem.  Of the main
interest in OBR imho is that it knows what is installed in the framework
already, so it can be used to avoid duplicating libraries in different
versions that are not needed (if you need spring-core 3.0.3 but spring-core
3.0.4 is installed, there's no need to install both usually).
The problem is that the use of OBR usually require OBR repositories.   I
think I can get rid of that by creating a dummy OBR repository from the
features descriptors and flagging some bundles in the features descriptor as
optional (or dependencies).

For example, in the current descriptor repoitory we have:


    <feature name="jasypt-encryption" version="2.1.99-SNAPSHOT">

 <bundle>mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.commons-codec/1.3_3</bundle>

 <bundle>mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.commons-lang/2.4_4</bundle>

 <bundle>mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.jasypt/1.6_1</bundle>

 <bundle>mvn:org.apache.karaf.jaas/org.apache.karaf.jaas.jasypt/2.1.99-SNAPSHOT</bundle>
    </feature>

But really, the key bundle here is
the mvn:org.apache.karaf.jaas/org.apache.karaf.jaas.jasypt/2.1.99-SNAPSHOT
one, whereas the three others are just dependency whith versions that could
be changed (provided they are still in the required range).  This would mean
that if commons-lang-2.5 has already been installed through another feature,
there's no need to install another version of it.

In addition, I think supporting dependency on feature ranges would be really
important as it would help greatly when depending on spring 2.x or 3.x for
example.

On Mon, Jul 5, 2010 at 09:29, Guillaume Nodet <[hidden email]> wrote:

> That could be a good way.  I haven't experimented that really, but I
> think it would at least give the freedom to the resolver to reuse
> locally installed bundles, so that's obviously a really good start.
>
> As for OBR itself, I've added to the maven bundle plugin a goal that
> can be used to build an obr repository out of a maven repository in a
> directory.  This goal can also generated maven urls instead of the
> file:// urls that it would give.  Thus giving an additional
> indirection in the url instead of pointing directly to the http
> location.
>
> I think from a production pov, what would be needed is some kind of
> maven repository (nexus or archiva) coupled with an OBR repository.
> This way, the deployer would be responsibe for adding authorized
> artifacts in the repository and that would automatically update an obr
> repository descriptor with the added artifacts.
> The problem is that this way of seeing the problem does not work well
> in a non controlled environment such as most users do when they allow
> access to maven central ... So in that case, your approach of using
> the maven dependencies could be a good solution.
>
> On Fri, Jul 2, 2010 at 18:34, David Jencks <[hidden email]> wrote:
> >
> > On Jul 2, 2010, at 8:03 AM, Guillaume Nodet wrote:
> >
> >> I've just added support for pluggable resolvers for features.
> >> I've also created an OBR based resolver that is installed with the obr
> feature.
> >>
> >> Now you can do the following:
> >>
> >>  <feature name="xx" version="yy" resolver="obr">
> >>
>  <bundle>bundle:(&(symbolicname=org.apache.camel.camel-blueprint)(version>=2.4.0)(version<2.4.1))</bundle>
> >>  </feature>
> >>
> >> If OBR has been configured with the needed repositories, it will
> >> install camel-blueprint bundle with all the required dependencies.
> >> The benefit is that you don't have to specify all the dependencies,
> >> but only the key bundles.  The added benefit is that the deployment
> >> will leverage what is already installed and you don't have to maintain
> >> an homogeneous set of repositories (for example, you should not have
> >> to specify which version of spring you want to use and obr will reuse
> >> the one installed if possible, or choose which one to install based on
> >> the constraints expressed by the bundles).
> >>
> >> I haven't updated the feature descriptor yet, mostly because we don't
> >> have a obr repository which contain all the bundles we need.
> >> I have one locally that contain all the bundles present on maven
> >> central, but it's a bit too big to be used in this context, so not
> >> sure how to handle that yet.
> >>
> >> Anyway, just wanted to give a heads up on that.
> >
> >
> > One of the points of friction I see between maven and osgi is that in
> maven you explicitly  specify which artifacts supply your needed
> dependencies whereas in osgi they magically appear from something like OBR.
>  I've always wondered where the OBR-like info is supposed to come from.  On
> the other hand, if you are using maven to build, you have a reasonable set
> of candidate artifacts in the maven dependencies (assuming they are all
> bundles).
> >
> > Something I started experimenting with in geronimo is to, for each
> feature, construct an OBR xml file out of the maven dependencies.  Just
> before you try to install the feature, you add the obr fragment to the OBR
> instance you are using for resolving the feature.  This pretty much assures
> that something that will enable the bundles in the features to resolve will
> be available.
> >
> > Writing the code for this was easy, but we weren't relying enough on OBR
> at the time to find out how well it works in practice.  I have been
> wondering if anyone else would think this is a reasonable approach to
> investigate.
> >
> > thanks
> > david jencks
> >>
> >> --
> >> Cheers,
> >> Guillaume Nodet
> >> ------------------------
> >> Blog: http://gnodet.blogspot.com/
> >> ------------------------
> >> Open Source SOA
> >> http://fusesource.com
> >
> >
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>



--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Reply | Threaded
Open this post in threaded view
|

Re: Features and OBR

jbonofre
Hi Guillaume

+1 to support dependency on features range.
Anyway, the dependency resolution is already performed by the bundle (if
it uses Import-Package statement with a version range, for instance, in
your exemple org.apache.commons.lang;version="[2.4,2.5)").

I guess that we need to "construct" the URL compatible with PAX URL
before delegating to PAX. The bundle will be added in the OBR
repositories (locally to Karaf) with a "dependency" flag.

The question is how to upgrade the descriptor repository to work like this.

I propose:
1/ the bundle version could be optional as:
<bundle>mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.commons-lang</bundle>
In that case, Karaf will looking for the OBR to get an existing
commons-lang bundle. It fails if the bundle is not present in the OBR
2/ define a bundle version range as
<bundle>mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.commons-lang/[2.4,2.5)</bundle>
In that case, Karaf will looking for the OBR to get the first bundle
matching the version range.
3/ define the bundle version is still supported (to be backward compatible).

What do you think ?

Regards
JB

On 10/20/2010 01:02 AM, Guillaume Nodet wrote:

> I think I have a solution to partially solve the problem.  Of the main
> interest in OBR imho is that it knows what is installed in the framework
> already, so it can be used to avoid duplicating libraries in different
> versions that are not needed (if you need spring-core 3.0.3 but spring-core
> 3.0.4 is installed, there's no need to install both usually).
> The problem is that the use of OBR usually require OBR repositories.   I
> think I can get rid of that by creating a dummy OBR repository from the
> features descriptors and flagging some bundles in the features descriptor as
> optional (or dependencies).
>
> For example, in the current descriptor repoitory we have:
>
>
>      <feature name="jasypt-encryption" version="2.1.99-SNAPSHOT">
>
>   <bundle>mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.commons-codec/1.3_3</bundle>
>
>   <bundle>mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.commons-lang/2.4_4</bundle>
>
>   <bundle>mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.jasypt/1.6_1</bundle>
>
>   <bundle>mvn:org.apache.karaf.jaas/org.apache.karaf.jaas.jasypt/2.1.99-SNAPSHOT</bundle>
>      </feature>
>
> But really, the key bundle here is
> the mvn:org.apache.karaf.jaas/org.apache.karaf.jaas.jasypt/2.1.99-SNAPSHOT
> one, whereas the three others are just dependency whith versions that could
> be changed (provided they are still in the required range).  This would mean
> that if commons-lang-2.5 has already been installed through another feature,
> there's no need to install another version of it.
>
> In addition, I think supporting dependency on feature ranges would be really
> important as it would help greatly when depending on spring 2.x or 3.x for
> example.
>
> On Mon, Jul 5, 2010 at 09:29, Guillaume Nodet<[hidden email]>  wrote:
>
>> That could be a good way.  I haven't experimented that really, but I
>> think it would at least give the freedom to the resolver to reuse
>> locally installed bundles, so that's obviously a really good start.
>>
>> As for OBR itself, I've added to the maven bundle plugin a goal that
>> can be used to build an obr repository out of a maven repository in a
>> directory.  This goal can also generated maven urls instead of the
>> file:// urls that it would give.  Thus giving an additional
>> indirection in the url instead of pointing directly to the http
>> location.
>>
>> I think from a production pov, what would be needed is some kind of
>> maven repository (nexus or archiva) coupled with an OBR repository.
>> This way, the deployer would be responsibe for adding authorized
>> artifacts in the repository and that would automatically update an obr
>> repository descriptor with the added artifacts.
>> The problem is that this way of seeing the problem does not work well
>> in a non controlled environment such as most users do when they allow
>> access to maven central ... So in that case, your approach of using
>> the maven dependencies could be a good solution.
>>
>> On Fri, Jul 2, 2010 at 18:34, David Jencks<[hidden email]>  wrote:
>>>
>>> On Jul 2, 2010, at 8:03 AM, Guillaume Nodet wrote:
>>>
>>>> I've just added support for pluggable resolvers for features.
>>>> I've also created an OBR based resolver that is installed with the obr
>> feature.
>>>>
>>>> Now you can do the following:
>>>>
>>>>   <feature name="xx" version="yy" resolver="obr">
>>>>
>>   <bundle>bundle:(&(symbolicname=org.apache.camel.camel-blueprint)(version>=2.4.0)(version<2.4.1))</bundle>
>>>>   </feature>
>>>>
>>>> If OBR has been configured with the needed repositories, it will
>>>> install camel-blueprint bundle with all the required dependencies.
>>>> The benefit is that you don't have to specify all the dependencies,
>>>> but only the key bundles.  The added benefit is that the deployment
>>>> will leverage what is already installed and you don't have to maintain
>>>> an homogeneous set of repositories (for example, you should not have
>>>> to specify which version of spring you want to use and obr will reuse
>>>> the one installed if possible, or choose which one to install based on
>>>> the constraints expressed by the bundles).
>>>>
>>>> I haven't updated the feature descriptor yet, mostly because we don't
>>>> have a obr repository which contain all the bundles we need.
>>>> I have one locally that contain all the bundles present on maven
>>>> central, but it's a bit too big to be used in this context, so not
>>>> sure how to handle that yet.
>>>>
>>>> Anyway, just wanted to give a heads up on that.
>>>
>>>
>>> One of the points of friction I see between maven and osgi is that in
>> maven you explicitly  specify which artifacts supply your needed
>> dependencies whereas in osgi they magically appear from something like OBR.
>>   I've always wondered where the OBR-like info is supposed to come from.  On
>> the other hand, if you are using maven to build, you have a reasonable set
>> of candidate artifacts in the maven dependencies (assuming they are all
>> bundles).
>>>
>>> Something I started experimenting with in geronimo is to, for each
>> feature, construct an OBR xml file out of the maven dependencies.  Just
>> before you try to install the feature, you add the obr fragment to the OBR
>> instance you are using for resolving the feature.  This pretty much assures
>> that something that will enable the bundles in the features to resolve will
>> be available.
>>>
>>> Writing the code for this was easy, but we weren't relying enough on OBR
>> at the time to find out how well it works in practice.  I have been
>> wondering if anyone else would think this is a reasonable approach to
>> investigate.
>>>
>>> thanks
>>> david jencks
>>>>
>>>> --
>>>> Cheers,
>>>> Guillaume Nodet
>>>> ------------------------
>>>> Blog: http://gnodet.blogspot.com/
>>>> ------------------------
>>>> Open Source SOA
>>>> http://fusesource.com
>>>
>>>
>>
>>
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>>
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Features and OBR

iocanel
It sounds good.


On Wed, Oct 20, 2010 at 10:18 AM, Jean-Baptiste Onofré <[hidden email]>wrote:

> Hi Guillaume
>
> +1 to support dependency on features range.
> Anyway, the dependency resolution is already performed by the bundle (if it
> uses Import-Package statement with a version range, for instance, in your
> exemple org.apache.commons.lang;version="[2.4,2.5)").
>
> I guess that we need to "construct" the URL compatible with PAX URL before
> delegating to PAX. The bundle will be added in the OBR repositories (locally
> to Karaf) with a "dependency" flag.
>
> The question is how to upgrade the descriptor repository to work like this.
>
> I propose:
> 1/ the bundle version could be optional as:
>
> <bundle>mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.commons-lang</bundle>
> In that case, Karaf will looking for the OBR to get an existing
> commons-lang bundle. It fails if the bundle is not present in the OBR
> 2/ define a bundle version range as
>
> <bundle>mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.commons-lang/[2.4,2.5)</bundle>
> In that case, Karaf will looking for the OBR to get the first bundle
> matching the version range.
> 3/ define the bundle version is still supported (to be backward
> compatible).
>
> What do you think ?
>
> Regards
> JB
>
>
> On 10/20/2010 01:02 AM, Guillaume Nodet wrote:
>
>> I think I have a solution to partially solve the problem.  Of the main
>> interest in OBR imho is that it knows what is installed in the framework
>> already, so it can be used to avoid duplicating libraries in different
>> versions that are not needed (if you need spring-core 3.0.3 but
>> spring-core
>> 3.0.4 is installed, there's no need to install both usually).
>> The problem is that the use of OBR usually require OBR repositories.   I
>> think I can get rid of that by creating a dummy OBR repository from the
>> features descriptors and flagging some bundles in the features descriptor
>> as
>> optional (or dependencies).
>>
>> For example, in the current descriptor repoitory we have:
>>
>>
>>     <feature name="jasypt-encryption" version="2.1.99-SNAPSHOT">
>>
>>
>>  <bundle>mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.commons-codec/1.3_3</bundle>
>>
>>
>>  <bundle>mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.commons-lang/2.4_4</bundle>
>>
>>
>>  <bundle>mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.jasypt/1.6_1</bundle>
>>
>>
>>  <bundle>mvn:org.apache.karaf.jaas/org.apache.karaf.jaas.jasypt/2.1.99-SNAPSHOT</bundle>
>>     </feature>
>>
>> But really, the key bundle here is
>> the mvn:org.apache.karaf.jaas/org.apache.karaf.jaas.jasypt/2.1.99-SNAPSHOT
>> one, whereas the three others are just dependency whith versions that
>> could
>> be changed (provided they are still in the required range).  This would
>> mean
>> that if commons-lang-2.5 has already been installed through another
>> feature,
>> there's no need to install another version of it.
>>
>> In addition, I think supporting dependency on feature ranges would be
>> really
>> important as it would help greatly when depending on spring 2.x or 3.x for
>> example.
>>
>> On Mon, Jul 5, 2010 at 09:29, Guillaume Nodet<[hidden email]>  wrote:
>>
>>  That could be a good way.  I haven't experimented that really, but I
>>> think it would at least give the freedom to the resolver to reuse
>>> locally installed bundles, so that's obviously a really good start.
>>>
>>> As for OBR itself, I've added to the maven bundle plugin a goal that
>>> can be used to build an obr repository out of a maven repository in a
>>> directory.  This goal can also generated maven urls instead of the
>>> file:// urls that it would give.  Thus giving an additional
>>> indirection in the url instead of pointing directly to the http
>>> location.
>>>
>>> I think from a production pov, what would be needed is some kind of
>>> maven repository (nexus or archiva) coupled with an OBR repository.
>>> This way, the deployer would be responsibe for adding authorized
>>> artifacts in the repository and that would automatically update an obr
>>> repository descriptor with the added artifacts.
>>> The problem is that this way of seeing the problem does not work well
>>> in a non controlled environment such as most users do when they allow
>>> access to maven central ... So in that case, your approach of using
>>> the maven dependencies could be a good solution.
>>>
>>> On Fri, Jul 2, 2010 at 18:34, David Jencks<[hidden email]>
>>>  wrote:
>>>
>>>>
>>>> On Jul 2, 2010, at 8:03 AM, Guillaume Nodet wrote:
>>>>
>>>>  I've just added support for pluggable resolvers for features.
>>>>> I've also created an OBR based resolver that is installed with the obr
>>>>>
>>>> feature.
>>>
>>>>
>>>>> Now you can do the following:
>>>>>
>>>>>  <feature name="xx" version="yy" resolver="obr">
>>>>>
>>>>>  <bundle>bundle:(&(symbolicname=org.apache.camel.camel-blueprint)(version>=2.4.0)(version<2.4.1))</bundle>
>>>
>>>>  </feature>
>>>>>
>>>>> If OBR has been configured with the needed repositories, it will
>>>>> install camel-blueprint bundle with all the required dependencies.
>>>>> The benefit is that you don't have to specify all the dependencies,
>>>>> but only the key bundles.  The added benefit is that the deployment
>>>>> will leverage what is already installed and you don't have to maintain
>>>>> an homogeneous set of repositories (for example, you should not have
>>>>> to specify which version of spring you want to use and obr will reuse
>>>>> the one installed if possible, or choose which one to install based on
>>>>> the constraints expressed by the bundles).
>>>>>
>>>>> I haven't updated the feature descriptor yet, mostly because we don't
>>>>> have a obr repository which contain all the bundles we need.
>>>>> I have one locally that contain all the bundles present on maven
>>>>> central, but it's a bit too big to be used in this context, so not
>>>>> sure how to handle that yet.
>>>>>
>>>>> Anyway, just wanted to give a heads up on that.
>>>>>
>>>>
>>>>
>>>> One of the points of friction I see between maven and osgi is that in
>>>>
>>> maven you explicitly  specify which artifacts supply your needed
>>> dependencies whereas in osgi they magically appear from something like
>>> OBR.
>>>  I've always wondered where the OBR-like info is supposed to come from.
>>>  On
>>> the other hand, if you are using maven to build, you have a reasonable
>>> set
>>> of candidate artifacts in the maven dependencies (assuming they are all
>>> bundles).
>>>
>>>>
>>>> Something I started experimenting with in geronimo is to, for each
>>>>
>>> feature, construct an OBR xml file out of the maven dependencies.  Just
>>> before you try to install the feature, you add the obr fragment to the
>>> OBR
>>> instance you are using for resolving the feature.  This pretty much
>>> assures
>>> that something that will enable the bundles in the features to resolve
>>> will
>>> be available.
>>>
>>>>
>>>> Writing the code for this was easy, but we weren't relying enough on OBR
>>>>
>>> at the time to find out how well it works in practice.  I have been
>>> wondering if anyone else would think this is a reasonable approach to
>>> investigate.
>>>
>>>>
>>>> thanks
>>>> david jencks
>>>>
>>>>>
>>>>> --
>>>>> Cheers,
>>>>> Guillaume Nodet
>>>>> ------------------------
>>>>> Blog: http://gnodet.blogspot.com/
>>>>> ------------------------
>>>>> Open Source SOA
>>>>> http://fusesource.com
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Cheers,
>>> Guillaume Nodet
>>> ------------------------
>>> Blog: http://gnodet.blogspot.com/
>>> ------------------------
>>> Open Source SOA
>>> http://fusesource.com
>>>
>>>
>>
>>
>>


--
*Ioannis Canellos*
http://iocanel.blogspot.com

Integration Engineer @ Upstream S.A. <http://www.upstreamsystems.com>
Ioannis Canellos
http://iocanel.blogspot.com
Reply | Threaded
Open this post in threaded view
|

Re: Features and OBR

Guillaume Nodet
I was mostly thinking about versioning at the feature dependency level.
The mvn url already supports range, so i don't think we need to do anything
here.
Afaik, you can already write:

mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.commons-codec/[1.3_3,2)

I'll post a bit more later today or tomorrow.

On Wed, Oct 20, 2010 at 09:32, Ioannis Canellos <[hidden email]> wrote:

> It sounds good.
>
>
> On Wed, Oct 20, 2010 at 10:18 AM, Jean-Baptiste Onofré <[hidden email]
> >wrote:
>
> > Hi Guillaume
> >
> > +1 to support dependency on features range.
> > Anyway, the dependency resolution is already performed by the bundle (if
> it
> > uses Import-Package statement with a version range, for instance, in your
> > exemple org.apache.commons.lang;version="[2.4,2.5)").
> >
> > I guess that we need to "construct" the URL compatible with PAX URL
> before
> > delegating to PAX. The bundle will be added in the OBR repositories
> (locally
> > to Karaf) with a "dependency" flag.
> >
> > The question is how to upgrade the descriptor repository to work like
> this.
> >
> > I propose:
> > 1/ the bundle version could be optional as:
> >
> >
> <bundle>mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.commons-lang</bundle>
> > In that case, Karaf will looking for the OBR to get an existing
> > commons-lang bundle. It fails if the bundle is not present in the OBR
> > 2/ define a bundle version range as
> >
> >
> <bundle>mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.commons-lang/[2.4,2.5)</bundle>
> > In that case, Karaf will looking for the OBR to get the first bundle
> > matching the version range.
> > 3/ define the bundle version is still supported (to be backward
> > compatible).
> >
> > What do you think ?
> >
> > Regards
> > JB
> >
> >
> > On 10/20/2010 01:02 AM, Guillaume Nodet wrote:
> >
> >> I think I have a solution to partially solve the problem.  Of the main
> >> interest in OBR imho is that it knows what is installed in the framework
> >> already, so it can be used to avoid duplicating libraries in different
> >> versions that are not needed (if you need spring-core 3.0.3 but
> >> spring-core
> >> 3.0.4 is installed, there's no need to install both usually).
> >> The problem is that the use of OBR usually require OBR repositories.   I
> >> think I can get rid of that by creating a dummy OBR repository from the
> >> features descriptors and flagging some bundles in the features
> descriptor
> >> as
> >> optional (or dependencies).
> >>
> >> For example, in the current descriptor repoitory we have:
> >>
> >>
> >>     <feature name="jasypt-encryption" version="2.1.99-SNAPSHOT">
> >>
> >>
> >>
>  <bundle>mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.commons-codec/1.3_3</bundle>
> >>
> >>
> >>
>  <bundle>mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.commons-lang/2.4_4</bundle>
> >>
> >>
> >>
>  <bundle>mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.jasypt/1.6_1</bundle>
> >>
> >>
> >>
>  <bundle>mvn:org.apache.karaf.jaas/org.apache.karaf.jaas.jasypt/2.1.99-SNAPSHOT</bundle>
> >>     </feature>
> >>
> >> But really, the key bundle here is
> >> the
> mvn:org.apache.karaf.jaas/org.apache.karaf.jaas.jasypt/2.1.99-SNAPSHOT
> >> one, whereas the three others are just dependency whith versions that
> >> could
> >> be changed (provided they are still in the required range).  This would
> >> mean
> >> that if commons-lang-2.5 has already been installed through another
> >> feature,
> >> there's no need to install another version of it.
> >>
> >> In addition, I think supporting dependency on feature ranges would be
> >> really
> >> important as it would help greatly when depending on spring 2.x or 3.x
> for
> >> example.
> >>
> >> On Mon, Jul 5, 2010 at 09:29, Guillaume Nodet<[hidden email]>  wrote:
> >>
> >>  That could be a good way.  I haven't experimented that really, but I
> >>> think it would at least give the freedom to the resolver to reuse
> >>> locally installed bundles, so that's obviously a really good start.
> >>>
> >>> As for OBR itself, I've added to the maven bundle plugin a goal that
> >>> can be used to build an obr repository out of a maven repository in a
> >>> directory.  This goal can also generated maven urls instead of the
> >>> file:// urls that it would give.  Thus giving an additional
> >>> indirection in the url instead of pointing directly to the http
> >>> location.
> >>>
> >>> I think from a production pov, what would be needed is some kind of
> >>> maven repository (nexus or archiva) coupled with an OBR repository.
> >>> This way, the deployer would be responsibe for adding authorized
> >>> artifacts in the repository and that would automatically update an obr
> >>> repository descriptor with the added artifacts.
> >>> The problem is that this way of seeing the problem does not work well
> >>> in a non controlled environment such as most users do when they allow
> >>> access to maven central ... So in that case, your approach of using
> >>> the maven dependencies could be a good solution.
> >>>
> >>> On Fri, Jul 2, 2010 at 18:34, David Jencks<[hidden email]>
> >>>  wrote:
> >>>
> >>>>
> >>>> On Jul 2, 2010, at 8:03 AM, Guillaume Nodet wrote:
> >>>>
> >>>>  I've just added support for pluggable resolvers for features.
> >>>>> I've also created an OBR based resolver that is installed with the
> obr
> >>>>>
> >>>> feature.
> >>>
> >>>>
> >>>>> Now you can do the following:
> >>>>>
> >>>>>  <feature name="xx" version="yy" resolver="obr">
> >>>>>
> >>>>>
>  <bundle>bundle:(&(symbolicname=org.apache.camel.camel-blueprint)(version>=2.4.0)(version<2.4.1))</bundle>
> >>>
> >>>>  </feature>
> >>>>>
> >>>>> If OBR has been configured with the needed repositories, it will
> >>>>> install camel-blueprint bundle with all the required dependencies.
> >>>>> The benefit is that you don't have to specify all the dependencies,
> >>>>> but only the key bundles.  The added benefit is that the deployment
> >>>>> will leverage what is already installed and you don't have to
> maintain
> >>>>> an homogeneous set of repositories (for example, you should not have
> >>>>> to specify which version of spring you want to use and obr will reuse
> >>>>> the one installed if possible, or choose which one to install based
> on
> >>>>> the constraints expressed by the bundles).
> >>>>>
> >>>>> I haven't updated the feature descriptor yet, mostly because we don't
> >>>>> have a obr repository which contain all the bundles we need.
> >>>>> I have one locally that contain all the bundles present on maven
> >>>>> central, but it's a bit too big to be used in this context, so not
> >>>>> sure how to handle that yet.
> >>>>>
> >>>>> Anyway, just wanted to give a heads up on that.
> >>>>>
> >>>>
> >>>>
> >>>> One of the points of friction I see between maven and osgi is that in
> >>>>
> >>> maven you explicitly  specify which artifacts supply your needed
> >>> dependencies whereas in osgi they magically appear from something like
> >>> OBR.
> >>>  I've always wondered where the OBR-like info is supposed to come from.
> >>>  On
> >>> the other hand, if you are using maven to build, you have a reasonable
> >>> set
> >>> of candidate artifacts in the maven dependencies (assuming they are all
> >>> bundles).
> >>>
> >>>>
> >>>> Something I started experimenting with in geronimo is to, for each
> >>>>
> >>> feature, construct an OBR xml file out of the maven dependencies.  Just
> >>> before you try to install the feature, you add the obr fragment to the
> >>> OBR
> >>> instance you are using for resolving the feature.  This pretty much
> >>> assures
> >>> that something that will enable the bundles in the features to resolve
> >>> will
> >>> be available.
> >>>
> >>>>
> >>>> Writing the code for this was easy, but we weren't relying enough on
> OBR
> >>>>
> >>> at the time to find out how well it works in practice.  I have been
> >>> wondering if anyone else would think this is a reasonable approach to
> >>> investigate.
> >>>
> >>>>
> >>>> thanks
> >>>> david jencks
> >>>>
> >>>>>
> >>>>> --
> >>>>> Cheers,
> >>>>> Guillaume Nodet
> >>>>> ------------------------
> >>>>> Blog: http://gnodet.blogspot.com/
> >>>>> ------------------------
> >>>>> Open Source SOA
> >>>>> http://fusesource.com
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>> --
> >>> Cheers,
> >>> Guillaume Nodet
> >>> ------------------------
> >>> Blog: http://gnodet.blogspot.com/
> >>> ------------------------
> >>> Open Source SOA
> >>> http://fusesource.com
> >>>
> >>>
> >>
> >>
> >>
>
>
> --
> *Ioannis Canellos*
> http://iocanel.blogspot.com
>
> Integration Engineer @ Upstream S.A. <http://www.upstreamsystems.com>
>



--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Reply | Threaded
Open this post in threaded view
|

Re: Features and OBR

jbonofre
Ahh interesting, I'm gonna make a try.

On 10/20/2010 12:17 PM, Guillaume Nodet wrote:

> I was mostly thinking about versioning at the feature dependency level.
> The mvn url already supports range, so i don't think we need to do anything
> here.
> Afaik, you can already write:
>
> mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.commons-codec/[1.3_3,2)
>
> I'll post a bit more later today or tomorrow.
>
> On Wed, Oct 20, 2010 at 09:32, Ioannis Canellos<[hidden email]>  wrote:
>
>> It sounds good.
>>
>>
>> On Wed, Oct 20, 2010 at 10:18 AM, Jean-Baptiste Onofré<[hidden email]
>>> wrote:
>>
>>> Hi Guillaume
>>>
>>> +1 to support dependency on features range.
>>> Anyway, the dependency resolution is already performed by the bundle (if
>> it
>>> uses Import-Package statement with a version range, for instance, in your
>>> exemple org.apache.commons.lang;version="[2.4,2.5)").
>>>
>>> I guess that we need to "construct" the URL compatible with PAX URL
>> before
>>> delegating to PAX. The bundle will be added in the OBR repositories
>> (locally
>>> to Karaf) with a "dependency" flag.
>>>
>>> The question is how to upgrade the descriptor repository to work like
>> this.
>>>
>>> I propose:
>>> 1/ the bundle version could be optional as:
>>>
>>>
>> <bundle>mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.commons-lang</bundle>
>>> In that case, Karaf will looking for the OBR to get an existing
>>> commons-lang bundle. It fails if the bundle is not present in the OBR
>>> 2/ define a bundle version range as
>>>
>>>
>> <bundle>mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.commons-lang/[2.4,2.5)</bundle>
>>> In that case, Karaf will looking for the OBR to get the first bundle
>>> matching the version range.
>>> 3/ define the bundle version is still supported (to be backward
>>> compatible).
>>>
>>> What do you think ?
>>>
>>> Regards
>>> JB
>>>
>>>
>>> On 10/20/2010 01:02 AM, Guillaume Nodet wrote:
>>>
>>>> I think I have a solution to partially solve the problem.  Of the main
>>>> interest in OBR imho is that it knows what is installed in the framework
>>>> already, so it can be used to avoid duplicating libraries in different
>>>> versions that are not needed (if you need spring-core 3.0.3 but
>>>> spring-core
>>>> 3.0.4 is installed, there's no need to install both usually).
>>>> The problem is that the use of OBR usually require OBR repositories.   I
>>>> think I can get rid of that by creating a dummy OBR repository from the
>>>> features descriptors and flagging some bundles in the features
>> descriptor
>>>> as
>>>> optional (or dependencies).
>>>>
>>>> For example, in the current descriptor repoitory we have:
>>>>
>>>>
>>>>      <feature name="jasypt-encryption" version="2.1.99-SNAPSHOT">
>>>>
>>>>
>>>>
>>   <bundle>mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.commons-codec/1.3_3</bundle>
>>>>
>>>>
>>>>
>>   <bundle>mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.commons-lang/2.4_4</bundle>
>>>>
>>>>
>>>>
>>   <bundle>mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.jasypt/1.6_1</bundle>
>>>>
>>>>
>>>>
>>   <bundle>mvn:org.apache.karaf.jaas/org.apache.karaf.jaas.jasypt/2.1.99-SNAPSHOT</bundle>
>>>>      </feature>
>>>>
>>>> But really, the key bundle here is
>>>> the
>> mvn:org.apache.karaf.jaas/org.apache.karaf.jaas.jasypt/2.1.99-SNAPSHOT
>>>> one, whereas the three others are just dependency whith versions that
>>>> could
>>>> be changed (provided they are still in the required range).  This would
>>>> mean
>>>> that if commons-lang-2.5 has already been installed through another
>>>> feature,
>>>> there's no need to install another version of it.
>>>>
>>>> In addition, I think supporting dependency on feature ranges would be
>>>> really
>>>> important as it would help greatly when depending on spring 2.x or 3.x
>> for
>>>> example.
>>>>
>>>> On Mon, Jul 5, 2010 at 09:29, Guillaume Nodet<[hidden email]>   wrote:
>>>>
>>>>   That could be a good way.  I haven't experimented that really, but I
>>>>> think it would at least give the freedom to the resolver to reuse
>>>>> locally installed bundles, so that's obviously a really good start.
>>>>>
>>>>> As for OBR itself, I've added to the maven bundle plugin a goal that
>>>>> can be used to build an obr repository out of a maven repository in a
>>>>> directory.  This goal can also generated maven urls instead of the
>>>>> file:// urls that it would give.  Thus giving an additional
>>>>> indirection in the url instead of pointing directly to the http
>>>>> location.
>>>>>
>>>>> I think from a production pov, what would be needed is some kind of
>>>>> maven repository (nexus or archiva) coupled with an OBR repository.
>>>>> This way, the deployer would be responsibe for adding authorized
>>>>> artifacts in the repository and that would automatically update an obr
>>>>> repository descriptor with the added artifacts.
>>>>> The problem is that this way of seeing the problem does not work well
>>>>> in a non controlled environment such as most users do when they allow
>>>>> access to maven central ... So in that case, your approach of using
>>>>> the maven dependencies could be a good solution.
>>>>>
>>>>> On Fri, Jul 2, 2010 at 18:34, David Jencks<[hidden email]>
>>>>>   wrote:
>>>>>
>>>>>>
>>>>>> On Jul 2, 2010, at 8:03 AM, Guillaume Nodet wrote:
>>>>>>
>>>>>>   I've just added support for pluggable resolvers for features.
>>>>>>> I've also created an OBR based resolver that is installed with the
>> obr
>>>>>>>
>>>>>> feature.
>>>>>
>>>>>>
>>>>>>> Now you can do the following:
>>>>>>>
>>>>>>>   <feature name="xx" version="yy" resolver="obr">
>>>>>>>
>>>>>>>
>>   <bundle>bundle:(&(symbolicname=org.apache.camel.camel-blueprint)(version>=2.4.0)(version<2.4.1))</bundle>
>>>>>
>>>>>>   </feature>
>>>>>>>
>>>>>>> If OBR has been configured with the needed repositories, it will
>>>>>>> install camel-blueprint bundle with all the required dependencies.
>>>>>>> The benefit is that you don't have to specify all the dependencies,
>>>>>>> but only the key bundles.  The added benefit is that the deployment
>>>>>>> will leverage what is already installed and you don't have to
>> maintain
>>>>>>> an homogeneous set of repositories (for example, you should not have
>>>>>>> to specify which version of spring you want to use and obr will reuse
>>>>>>> the one installed if possible, or choose which one to install based
>> on
>>>>>>> the constraints expressed by the bundles).
>>>>>>>
>>>>>>> I haven't updated the feature descriptor yet, mostly because we don't
>>>>>>> have a obr repository which contain all the bundles we need.
>>>>>>> I have one locally that contain all the bundles present on maven
>>>>>>> central, but it's a bit too big to be used in this context, so not
>>>>>>> sure how to handle that yet.
>>>>>>>
>>>>>>> Anyway, just wanted to give a heads up on that.
>>>>>>>
>>>>>>
>>>>>>
>>>>>> One of the points of friction I see between maven and osgi is that in
>>>>>>
>>>>> maven you explicitly  specify which artifacts supply your needed
>>>>> dependencies whereas in osgi they magically appear from something like
>>>>> OBR.
>>>>>   I've always wondered where the OBR-like info is supposed to come from.
>>>>>   On
>>>>> the other hand, if you are using maven to build, you have a reasonable
>>>>> set
>>>>> of candidate artifacts in the maven dependencies (assuming they are all
>>>>> bundles).
>>>>>
>>>>>>
>>>>>> Something I started experimenting with in geronimo is to, for each
>>>>>>
>>>>> feature, construct an OBR xml file out of the maven dependencies.  Just
>>>>> before you try to install the feature, you add the obr fragment to the
>>>>> OBR
>>>>> instance you are using for resolving the feature.  This pretty much
>>>>> assures
>>>>> that something that will enable the bundles in the features to resolve
>>>>> will
>>>>> be available.
>>>>>
>>>>>>
>>>>>> Writing the code for this was easy, but we weren't relying enough on
>> OBR
>>>>>>
>>>>> at the time to find out how well it works in practice.  I have been
>>>>> wondering if anyone else would think this is a reasonable approach to
>>>>> investigate.
>>>>>
>>>>>>
>>>>>> thanks
>>>>>> david jencks
>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Cheers,
>>>>>>> Guillaume Nodet
>>>>>>> ------------------------
>>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>>> ------------------------
>>>>>>> Open Source SOA
>>>>>>> http://fusesource.com
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Cheers,
>>>>> Guillaume Nodet
>>>>> ------------------------
>>>>> Blog: http://gnodet.blogspot.com/
>>>>> ------------------------
>>>>> Open Source SOA
>>>>> http://fusesource.com
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>
>>
>> --
>> *Ioannis Canellos*
>> http://iocanel.blogspot.com
>>
>> Integration Engineer @ Upstream S.A.<http://www.upstreamsystems.com>
>>
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Features and OBR

Guillaume Nodet
In reply to this post by Guillaume Nodet
Ok, so i've raise KARAF-251 and KARAF-252 and committed some patches, but
i'd like to discuss those before closing the jiras.

So, KARAF-251 is about using range on features.
I've modified the parser and installation service to allow using ranges when
specifying a dependency on a feature.
I've also modified the karaf feature descriptor to leverage that by adding a
spring2 feature:

    <feature name="spring" version="2.5.6.SEC01">
        <bundle
dependency='true'>mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.aopalliance/1.0_4</bundle>
        <bundle>mvn:org.springframework/spring-core/2.5.6.SEC01</bundle>
        <bundle>mvn:org.springframework/spring-beans/2.5.6.SEC01</bundle>
        <bundle>mvn:org.springframework/spring-aop/2.5.6.SEC01</bundle>
        <bundle>mvn:org.springframework/spring-context/2.5.6.SEC01</bundle>

 <bundle>mvn:org.springframework/spring-context-support/2.5.6.SEC01</bundle>
    </feature>
    <feature name="spring" version="3.0.3.RELEASE">
        <bundle
dependency='true'>mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.aopalliance/1.0_4</bundle>
        <bundle>mvn:org.springframework/spring-core/3.0.3.RELEASE</bundle>
        <bundle>mvn:org.springframework/spring-asm/3.0.3.RELEASE</bundle>

 <bundle>mvn:org.springframework/spring-expression/3.0.3.RELEASE</bundle>
        <bundle>mvn:org.springframework/spring-beans/3.0.3.RELEASE</bundle>
        <bundle>mvn:org.springframework/spring-aop/3.0.3.RELEASE</bundle>

 <bundle>mvn:org.springframework/spring-context/3.0.3.RELEASE</bundle>

 <bundle>mvn:org.springframework/spring-context-support/3.0.3.RELEASE</bundle>
    </feature>
    <feature name="spring-dm" version="1.2.0">
        <feature version="[2.5.6,4)">spring</feature>

 <bundle>mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.cglib/2.1_3_6</bundle>
        <bundle>mvn:org.springframework.osgi/spring-osgi-io/1.2.0</bundle>
        <bundle>mvn:org.springframework.osgi/spring-osgi-core/1.2.0</bundle>

 <bundle>mvn:org.springframework.osgi/spring-osgi-extender/1.2.0</bundle>

 <bundle>mvn:org.springframework.osgi/spring-osgi-annotation/1.2.0</bundle>

 <bundle>mvn:org.apache.karaf.deployer/org.apache.karaf.deployer.spring/2.1.99-SNAPSHOT</bundle>
    </feature>

When installing a feature, the dependant features are installed as
following:
  * if no version is indicated, it means [0, +oo)
  * if a version is indicated, the range is closed [x, x]
  * if a feature matching the range is already installed, use that one
  * else find the highest version matching the range

So if you 'features:install spring-dm' it will install spring 3.0.3 by
default.  If you want to install the 2.5 version, you need to
'features:install spring 2.5.6' and then 'features:install spring-dm'.

The second improvement, KARAF-252 is about leveraging OBR to avoid
installing duplicate dependencies while not forcing the user into using and
maintaining OBR repositories.  It can now be done by flagging dependencies
with a dependency='true' flag and resolver="(obr)".   Note the parentheses
that mean the obr resolver is optional (so it will default to the previous
behavior if obr isn't installed and in that case will install all the listed
bundles).   If obr resolver is present, the feature will be transitively
resolved by creating an obr repository containing all the listed bundles and
resolving only the bundles marked as not 'dependency'.  So in the example
above, the aopalliance bundle is marked as a dependency, so that if another
aopalliance bundle satisfying the constraint (imported packages, etc...) is
already installed, it won't be installed.

Thoughts?


On Wed, Oct 20, 2010 at 12:17, Guillaume Nodet <[hidden email]> wrote:

> I was mostly thinking about versioning at the feature dependency level.
> The mvn url already supports range, so i don't think we need to do anything
> here.
> Afaik, you can already write:
>
> mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.commons-codec/[1.3_3,2)
>
> I'll post a bit more later today or tomorrow.
>
> On Wed, Oct 20, 2010 at 09:32, Ioannis Canellos <[hidden email]> wrote:
>
>> It sounds good.
>>
>>
>> On Wed, Oct 20, 2010 at 10:18 AM, Jean-Baptiste Onofré <[hidden email]
>> >wrote:
>>
>> > Hi Guillaume
>> >
>> > +1 to support dependency on features range.
>> > Anyway, the dependency resolution is already performed by the bundle (if
>> it
>> > uses Import-Package statement with a version range, for instance, in
>> your
>> > exemple org.apache.commons.lang;version="[2.4,2.5)").
>> >
>> > I guess that we need to "construct" the URL compatible with PAX URL
>> before
>> > delegating to PAX. The bundle will be added in the OBR repositories
>> (locally
>> > to Karaf) with a "dependency" flag.
>> >
>> > The question is how to upgrade the descriptor repository to work like
>> this.
>> >
>> > I propose:
>> > 1/ the bundle version could be optional as:
>> >
>> >
>> <bundle>mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.commons-lang</bundle>
>> > In that case, Karaf will looking for the OBR to get an existing
>> > commons-lang bundle. It fails if the bundle is not present in the OBR
>> > 2/ define a bundle version range as
>> >
>> >
>> <bundle>mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.commons-lang/[2.4,2.5)</bundle>
>> > In that case, Karaf will looking for the OBR to get the first bundle
>> > matching the version range.
>> > 3/ define the bundle version is still supported (to be backward
>> > compatible).
>> >
>> > What do you think ?
>> >
>> > Regards
>> > JB
>> >
>> >
>> > On 10/20/2010 01:02 AM, Guillaume Nodet wrote:
>> >
>> >> I think I have a solution to partially solve the problem.  Of the main
>> >> interest in OBR imho is that it knows what is installed in the
>> framework
>> >> already, so it can be used to avoid duplicating libraries in different
>> >> versions that are not needed (if you need spring-core 3.0.3 but
>> >> spring-core
>> >> 3.0.4 is installed, there's no need to install both usually).
>> >> The problem is that the use of OBR usually require OBR repositories.
>> I
>> >> think I can get rid of that by creating a dummy OBR repository from the
>> >> features descriptors and flagging some bundles in the features
>> descriptor
>> >> as
>> >> optional (or dependencies).
>> >>
>> >> For example, in the current descriptor repoitory we have:
>> >>
>> >>
>> >>     <feature name="jasypt-encryption" version="2.1.99-SNAPSHOT">
>> >>
>> >>
>> >>
>>  <bundle>mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.commons-codec/1.3_3</bundle>
>> >>
>> >>
>> >>
>>  <bundle>mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.commons-lang/2.4_4</bundle>
>> >>
>> >>
>> >>
>>  <bundle>mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.jasypt/1.6_1</bundle>
>> >>
>> >>
>> >>
>>  <bundle>mvn:org.apache.karaf.jaas/org.apache.karaf.jaas.jasypt/2.1.99-SNAPSHOT</bundle>
>> >>     </feature>
>> >>
>> >> But really, the key bundle here is
>> >> the
>> mvn:org.apache.karaf.jaas/org.apache.karaf.jaas.jasypt/2.1.99-SNAPSHOT
>> >> one, whereas the three others are just dependency whith versions that
>> >> could
>> >> be changed (provided they are still in the required range).  This would
>> >> mean
>> >> that if commons-lang-2.5 has already been installed through another
>> >> feature,
>> >> there's no need to install another version of it.
>> >>
>> >> In addition, I think supporting dependency on feature ranges would be
>> >> really
>> >> important as it would help greatly when depending on spring 2.x or 3.x
>> for
>> >> example.
>> >>
>> >> On Mon, Jul 5, 2010 at 09:29, Guillaume Nodet<[hidden email]>
>>  wrote:
>> >>
>> >>  That could be a good way.  I haven't experimented that really, but I
>> >>> think it would at least give the freedom to the resolver to reuse
>> >>> locally installed bundles, so that's obviously a really good start.
>> >>>
>> >>> As for OBR itself, I've added to the maven bundle plugin a goal that
>> >>> can be used to build an obr repository out of a maven repository in a
>> >>> directory.  This goal can also generated maven urls instead of the
>> >>> file:// urls that it would give.  Thus giving an additional
>> >>> indirection in the url instead of pointing directly to the http
>> >>> location.
>> >>>
>> >>> I think from a production pov, what would be needed is some kind of
>> >>> maven repository (nexus or archiva) coupled with an OBR repository.
>> >>> This way, the deployer would be responsibe for adding authorized
>> >>> artifacts in the repository and that would automatically update an obr
>> >>> repository descriptor with the added artifacts.
>> >>> The problem is that this way of seeing the problem does not work well
>> >>> in a non controlled environment such as most users do when they allow
>> >>> access to maven central ... So in that case, your approach of using
>> >>> the maven dependencies could be a good solution.
>> >>>
>> >>> On Fri, Jul 2, 2010 at 18:34, David Jencks<[hidden email]>
>> >>>  wrote:
>> >>>
>> >>>>
>> >>>> On Jul 2, 2010, at 8:03 AM, Guillaume Nodet wrote:
>> >>>>
>> >>>>  I've just added support for pluggable resolvers for features.
>> >>>>> I've also created an OBR based resolver that is installed with the
>> obr
>> >>>>>
>> >>>> feature.
>> >>>
>> >>>>
>> >>>>> Now you can do the following:
>> >>>>>
>> >>>>>  <feature name="xx" version="yy" resolver="obr">
>> >>>>>
>> >>>>>
>>  <bundle>bundle:(&(symbolicname=org.apache.camel.camel-blueprint)(version>=2.4.0)(version<2.4.1))</bundle>
>> >>>
>> >>>>  </feature>
>> >>>>>
>> >>>>> If OBR has been configured with the needed repositories, it will
>> >>>>> install camel-blueprint bundle with all the required dependencies.
>> >>>>> The benefit is that you don't have to specify all the dependencies,
>> >>>>> but only the key bundles.  The added benefit is that the deployment
>> >>>>> will leverage what is already installed and you don't have to
>> maintain
>> >>>>> an homogeneous set of repositories (for example, you should not have
>> >>>>> to specify which version of spring you want to use and obr will
>> reuse
>> >>>>> the one installed if possible, or choose which one to install based
>> on
>> >>>>> the constraints expressed by the bundles).
>> >>>>>
>> >>>>> I haven't updated the feature descriptor yet, mostly because we
>> don't
>> >>>>> have a obr repository which contain all the bundles we need.
>> >>>>> I have one locally that contain all the bundles present on maven
>> >>>>> central, but it's a bit too big to be used in this context, so not
>> >>>>> sure how to handle that yet.
>> >>>>>
>> >>>>> Anyway, just wanted to give a heads up on that.
>> >>>>>
>> >>>>
>> >>>>
>> >>>> One of the points of friction I see between maven and osgi is that in
>> >>>>
>> >>> maven you explicitly  specify which artifacts supply your needed
>> >>> dependencies whereas in osgi they magically appear from something like
>> >>> OBR.
>> >>>  I've always wondered where the OBR-like info is supposed to come
>> from.
>> >>>  On
>> >>> the other hand, if you are using maven to build, you have a reasonable
>> >>> set
>> >>> of candidate artifacts in the maven dependencies (assuming they are
>> all
>> >>> bundles).
>> >>>
>> >>>>
>> >>>> Something I started experimenting with in geronimo is to, for each
>> >>>>
>> >>> feature, construct an OBR xml file out of the maven dependencies.
>>  Just
>> >>> before you try to install the feature, you add the obr fragment to the
>> >>> OBR
>> >>> instance you are using for resolving the feature.  This pretty much
>> >>> assures
>> >>> that something that will enable the bundles in the features to resolve
>> >>> will
>> >>> be available.
>> >>>
>> >>>>
>> >>>> Writing the code for this was easy, but we weren't relying enough on
>> OBR
>> >>>>
>> >>> at the time to find out how well it works in practice.  I have been
>> >>> wondering if anyone else would think this is a reasonable approach to
>> >>> investigate.
>> >>>
>> >>>>
>> >>>> thanks
>> >>>> david jencks
>> >>>>
>> >>>>>
>> >>>>> --
>> >>>>> Cheers,
>> >>>>> Guillaume Nodet
>> >>>>> ------------------------
>> >>>>> Blog: http://gnodet.blogspot.com/
>> >>>>> ------------------------
>> >>>>> Open Source SOA
>> >>>>> http://fusesource.com
>> >>>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>
>> >>>
>> >>> --
>> >>> Cheers,
>> >>> Guillaume Nodet
>> >>> ------------------------
>> >>> Blog: http://gnodet.blogspot.com/
>> >>> ------------------------
>> >>> Open Source SOA
>> >>> http://fusesource.com
>> >>>
>> >>>
>> >>
>> >>
>> >>
>>
>>
>> --
>> *Ioannis Canellos*
>> http://iocanel.blogspot.com
>>
>> Integration Engineer @ Upstream S.A. <http://www.upstreamsystems.com>
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
>
>


--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Reply | Threaded
Open this post in threaded view
|

Logo proposal

Łukasz Dywicki
In reply to this post by Guillaume Nodet
Hello,

Currently Karaf Web page does not have Any logo. My intern have done some
drafts:

http://tinyurl.com/karaf-logo-proposal
 

What do you think about these proposals?


Best regards,
Lukasz


Reply | Threaded
Open this post in threaded view
|

Re: Logo proposal

iocanel
Hi splatch!

I like the version of the logo where the icon is before the karaf literal
(1st column). However I am not sure about font. 4th row maybe!
I also prefer the not "steaming" version, since the steaming one reminds me
of the java logo.

Keep up!

2010/10/21 Łukasz Dywicki <[hidden email]>

> Hello,
>
> Currently Karaf Web page does not have Any logo. My intern have done some
> drafts:
>
> http://tinyurl.com/karaf-logo-proposal
>
>
> What do you think about these proposals?
>
>
> Best regards,
> Lukasz
>
>
>


--
*Ioannis Canellos*
http://iocanel.blogspot.com
Integration Engineer @ Upstream S.A. <http://www.upstreamsystems.com>
Ioannis Canellos
http://iocanel.blogspot.com
Reply | Threaded
Open this post in threaded view
|

Re: Logo proposal

Guillaume Nodet
Nice work !
I also like the 4th row / 1st column one.   I wonder if there's a way to add
a feather above the ''karaf' word.

2010/10/21 Ioannis Canellos <[hidden email]>

> Hi splatch!
>
> I like the version of the logo where the icon is before the karaf literal
> (1st column). However I am not sure about font. 4th row maybe!
> I also prefer the not "steaming" version, since the steaming one reminds me
> of the java logo.
>
> Keep up!
>
> 2010/10/21 Łukasz Dywicki <[hidden email]>
>
> > Hello,
> >
> > Currently Karaf Web page does not have Any logo. My intern have done some
> > drafts:
> >
> > http://tinyurl.com/karaf-logo-proposal
> >
> >
> > What do you think about these proposals?
> >
> >
> > Best regards,
> > Lukasz
> >
> >
> >
>
>
> --
> *Ioannis Canellos*
> http://iocanel.blogspot.com
> Integration Engineer @ Upstream S.A. <http://www.upstreamsystems.com>
>



--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Reply | Threaded
Open this post in threaded view
|

Re: Logo proposal

jgoodyear
+1 to 4th row / 1st column. An Apache feather would be a nice touch. To keep
with ASF branding rules we'll need to include a little "TM" somewhere in the
graphic.

2010/10/21 Guillaume Nodet <[hidden email]>

> Nice work !
> I also like the 4th row / 1st column one.   I wonder if there's a way to
> add
> a feather above the ''karaf' word.
>
> 2010/10/21 Ioannis Canellos <[hidden email]>
>
> > Hi splatch!
> >
> > I like the version of the logo where the icon is before the karaf literal
> > (1st column). However I am not sure about font. 4th row maybe!
> > I also prefer the not "steaming" version, since the steaming one reminds
> me
> > of the java logo.
> >
> > Keep up!
> >
> > 2010/10/21 Łukasz Dywicki <[hidden email]>
> >
> > > Hello,
> > >
> > > Currently Karaf Web page does not have Any logo. My intern have done
> some
> > > drafts:
> > >
> > > http://tinyurl.com/karaf-logo-proposal
> > >
> > >
> > > What do you think about these proposals?
> > >
> > >
> > > Best regards,
> > > Lukasz
> > >
> > >
> > >
> >
> >
> > --
> > *Ioannis Canellos*
> > http://iocanel.blogspot.com
> > Integration Engineer @ Upstream S.A. <http://www.upstreamsystems.com>
> >
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
Reply | Threaded
Open this post in threaded view
|

Re: Logo proposal

Adrian Trenaman-2
+1001001

These look really great. Can we make t-shirts? :)

On 21/10/2010 11:31, Jamie G. wrote:

> +1 to 4th row / 1st column. An Apache feather would be a nice touch. To keep
> with ASF branding rules we'll need to include a little "TM" somewhere in the
> graphic.
>
> 2010/10/21 Guillaume Nodet<[hidden email]>
>
>> Nice work !
>> I also like the 4th row / 1st column one.   I wonder if there's a way to
>> add
>> a feather above the ''karaf' word.
>>
>> 2010/10/21 Ioannis Canellos<[hidden email]>
>>
>>> Hi splatch!
>>>
>>> I like the version of the logo where the icon is before the karaf literal
>>> (1st column). However I am not sure about font. 4th row maybe!
>>> I also prefer the not "steaming" version, since the steaming one reminds
>> me
>>> of the java logo.
>>>
>>> Keep up!
>>>
>>> 2010/10/21 Łukasz Dywicki<[hidden email]>
>>>
>>>> Hello,
>>>>
>>>> Currently Karaf Web page does not have Any logo. My intern have done
>> some
>>>> drafts:
>>>>
>>>> http://tinyurl.com/karaf-logo-proposal
>>>>
>>>>
>>>> What do you think about these proposals?
>>>>
>>>>
>>>> Best regards,
>>>> Lukasz
>>>>
>>>>
>>>>
>>>
>>> --
>>> *Ioannis Canellos*
>>> http://iocanel.blogspot.com
>>> Integration Engineer @ Upstream S.A.<http://www.upstreamsystems.com>
>>>
>>
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>>
Reply | Threaded
Open this post in threaded view
|

Re: Logo proposal

Charles Moulliard
Administrator
In reply to this post by jgoodyear
I prefer 2nd row / 1st column

On 21/10/10 12:31, Jamie G. wrote:

> +1 to 4th row / 1st column. An Apache feather would be a nice touch. To keep
> with ASF branding rules we'll need to include a little "TM" somewhere in the
> graphic.
>
> 2010/10/21 Guillaume Nodet<[hidden email]>
>
>> Nice work !
>> I also like the 4th row / 1st column one.   I wonder if there's a way to
>> add
>> a feather above the ''karaf' word.
>>
>> 2010/10/21 Ioannis Canellos<[hidden email]>
>>
>>> Hi splatch!
>>>
>>> I like the version of the logo where the icon is before the karaf literal
>>> (1st column). However I am not sure about font. 4th row maybe!
>>> I also prefer the not "steaming" version, since the steaming one reminds
>> me
>>> of the java logo.
>>>
>>> Keep up!
>>>
>>> 2010/10/21 Łukasz Dywicki<[hidden email]>
>>>
>>>> Hello,
>>>>
>>>> Currently Karaf Web page does not have Any logo. My intern have done
>> some
>>>> drafts:
>>>>
>>>> http://tinyurl.com/karaf-logo-proposal
>>>>
>>>>
>>>> What do you think about these proposals?
>>>>
>>>>
>>>> Best regards,
>>>> Lukasz
>>>>
>>>>
>>>>
>>>
>>> --
>>> *Ioannis Canellos*
>>> http://iocanel.blogspot.com
>>> Integration Engineer @ Upstream S.A.<http://www.upstreamsystems.com>
>>>
>>
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>>
Apache Committer / Sr. Pr. Consultant at FuseSource.com
Email: [hidden email]
Twitter : @cmoulliard, @fusenews
Blog : http://cmoulliard.blogspot.com
Reply | Threaded
Open this post in threaded view
|

Re: Logo proposal

Adrian Trenaman-2
I think the best logo is the big one on the right with the fumes coming
out the top - nicely reminicent of the old Java logo.

Whatever logo we use, I think they look best when the karaf image is on
the left or right of the text, not on the top.

So, ideally, I'd go for bottom right, adding the fumes above the Karaf
image.


On 21/10/2010 11:38, Charles Moulliard wrote:

> I prefer 2nd row / 1st column
>
> On 21/10/10 12:31, Jamie G. wrote:
>> +1 to 4th row / 1st column. An Apache feather would be a nice touch. To keep
>> with ASF branding rules we'll need to include a little "TM" somewhere in the
>> graphic.
>>
>> 2010/10/21 Guillaume Nodet<[hidden email]>
>>
>>> Nice work !
>>> I also like the 4th row / 1st column one.   I wonder if there's a way to
>>> add
>>> a feather above the ''karaf' word.
>>>
>>> 2010/10/21 Ioannis Canellos<[hidden email]>
>>>
>>>> Hi splatch!
>>>>
>>>> I like the version of the logo where the icon is before the karaf literal
>>>> (1st column). However I am not sure about font. 4th row maybe!
>>>> I also prefer the not "steaming" version, since the steaming one reminds
>>> me
>>>> of the java logo.
>>>>
>>>> Keep up!
>>>>
>>>> 2010/10/21 Łukasz Dywicki<[hidden email]>
>>>>
>>>>> Hello,
>>>>>
>>>>> Currently Karaf Web page does not have Any logo. My intern have done
>>> some
>>>>> drafts:
>>>>>
>>>>> http://tinyurl.com/karaf-logo-proposal
>>>>>
>>>>>
>>>>> What do you think about these proposals?
>>>>>
>>>>>
>>>>> Best regards,
>>>>> Lukasz
>>>>>
>>>>>
>>>>>
>>>> --
>>>> *Ioannis Canellos*
>>>> http://iocanel.blogspot.com
>>>> Integration Engineer @ Upstream S.A.<http://www.upstreamsystems.com>
>>>>
>>>
>>> --
>>> Cheers,
>>> Guillaume Nodet
>>> ------------------------
>>> Blog: http://gnodet.blogspot.com/
>>> ------------------------
>>> Open Source SOA
>>> http://fusesource.com
>>>
Reply | Threaded
Open this post in threaded view
|

Re: Logo proposal

Freeman-2
I prefer to "Karaf" text is on the right,
colume 1, row 3,4, or 5 are ok for me.

Freeman
On 2010-10-21, at 下午6:42, Adrian Trenaman wrote:

> I think the best logo is the big one on the right with the fumes  
> coming out the top - nicely reminicent of the old Java logo.
>
> Whatever logo we use, I think they look best when the karaf image is  
> on the left or right of the text, not on the top.
>
> So, ideally, I'd go for bottom right, adding the fumes above the  
> Karaf image.
>
>
> On 21/10/2010 11:38, Charles Moulliard wrote:
>> I prefer 2nd row / 1st column
>>
>> On 21/10/10 12:31, Jamie G. wrote:
>>> +1 to 4th row / 1st column. An Apache feather would be a nice  
>>> touch. To keep
>>> with ASF branding rules we'll need to include a little "TM"  
>>> somewhere in the
>>> graphic.
>>>
>>> 2010/10/21 Guillaume Nodet<[hidden email]>
>>>
>>>> Nice work !
>>>> I also like the 4th row / 1st column one.   I wonder if there's a  
>>>> way to
>>>> add
>>>> a feather above the ''karaf' word.
>>>>
>>>> 2010/10/21 Ioannis Canellos<[hidden email]>
>>>>
>>>>> Hi splatch!
>>>>>
>>>>> I like the version of the logo where the icon is before the  
>>>>> karaf literal
>>>>> (1st column). However I am not sure about font. 4th row maybe!
>>>>> I also prefer the not "steaming" version, since the steaming one  
>>>>> reminds
>>>> me
>>>>> of the java logo.
>>>>>
>>>>> Keep up!
>>>>>
>>>>> 2010/10/21 Łukasz Dywicki<[hidden email]>
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> Currently Karaf Web page does not have Any logo. My intern have  
>>>>>> done
>>>> some
>>>>>> drafts:
>>>>>>
>>>>>> http://tinyurl.com/karaf-logo-proposal
>>>>>>
>>>>>>
>>>>>> What do you think about these proposals?
>>>>>>
>>>>>>
>>>>>> Best regards,
>>>>>> Lukasz
>>>>>>
>>>>>>
>>>>>>
>>>>> --
>>>>> *Ioannis Canellos*
>>>>> http://iocanel.blogspot.com
>>>>> Integration Engineer @ Upstream S.A.<http://www.upstreamsystems.com 
>>>>> >
>>>>>
>>>>
>>>> --
>>>> Cheers,
>>>> Guillaume Nodet
>>>> ------------------------
>>>> Blog: http://gnodet.blogspot.com/
>>>> ------------------------
>>>> Open Source SOA
>>>> http://fusesource.com
>>>>


--
Freeman Fang

------------------------
blog: http://freemanfang.blogspot.com
twitter: http://twitter.com/freemanfang
Open Source SOA: http://fusesource.com
Apache Servicemix:http://servicemix.apache.org
Apache Cxf: http://cxf.apache.org
Apache Karaf: http://karaf.apache.org
Apache Felix: http://felix.apache.org

Reply | Threaded
Open this post in threaded view
|

RE: Logo proposal

Łukasz Dywicki
Hi all,
Rafal (our graphic designer) will work on logo improvements in next week. He going to show another three logos based on your proposals.

Best regards,
Lukasz

-----Original Message-----
From: Freeman Fang [mailto:[hidden email]]
Sent: Thursday, October 21, 2010 12:56 PM
To: [hidden email]
Subject: Re: Logo proposal

I prefer to "Karaf" text is on the right,
colume 1, row 3,4, or 5 are ok for me.

Freeman
On 2010-10-21, at 下午6:42, Adrian Trenaman wrote:

> I think the best logo is the big one on the right with the fumes  
> coming out the top - nicely reminicent of the old Java logo.
>
> Whatever logo we use, I think they look best when the karaf image is  
> on the left or right of the text, not on the top.
>
> So, ideally, I'd go for bottom right, adding the fumes above the  
> Karaf image.
>
>
> On 21/10/2010 11:38, Charles Moulliard wrote:
>> I prefer 2nd row / 1st column
>>
>> On 21/10/10 12:31, Jamie G. wrote:
>>> +1 to 4th row / 1st column. An Apache feather would be a nice  
>>> touch. To keep
>>> with ASF branding rules we'll need to include a little "TM"  
>>> somewhere in the
>>> graphic.
>>>
>>> 2010/10/21 Guillaume Nodet<[hidden email]>
>>>
>>>> Nice work !
>>>> I also like the 4th row / 1st column one.   I wonder if there's a  
>>>> way to
>>>> add
>>>> a feather above the ''karaf' word.
>>>>
>>>> 2010/10/21 Ioannis Canellos<[hidden email]>
>>>>
>>>>> Hi splatch!
>>>>>
>>>>> I like the version of the logo where the icon is before the  
>>>>> karaf literal
>>>>> (1st column). However I am not sure about font. 4th row maybe!
>>>>> I also prefer the not "steaming" version, since the steaming one  
>>>>> reminds
>>>> me
>>>>> of the java logo.
>>>>>
>>>>> Keep up!
>>>>>
>>>>> 2010/10/21 Łukasz Dywicki<[hidden email]>
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> Currently Karaf Web page does not have Any logo. My intern have  
>>>>>> done
>>>> some
>>>>>> drafts:
>>>>>>
>>>>>> http://tinyurl.com/karaf-logo-proposal
>>>>>>
>>>>>>
>>>>>> What do you think about these proposals?
>>>>>>
>>>>>>
>>>>>> Best regards,
>>>>>> Lukasz
>>>>>>
>>>>>>
>>>>>>
>>>>> --
>>>>> *Ioannis Canellos*
>>>>> http://iocanel.blogspot.com
>>>>> Integration Engineer @ Upstream S.A.<http://www.upstreamsystems.com 
>>>>> >
>>>>>
>>>>
>>>> --
>>>> Cheers,
>>>> Guillaume Nodet
>>>> ------------------------
>>>> Blog: http://gnodet.blogspot.com/
>>>> ------------------------
>>>> Open Source SOA
>>>> http://fusesource.com
>>>>


--
Freeman Fang

------------------------
blog: http://freemanfang.blogspot.com
twitter: http://twitter.com/freemanfang
Open Source SOA: http://fusesource.com
Apache Servicemix:http://servicemix.apache.org
Apache Cxf: http://cxf.apache.org
Apache Karaf: http://karaf.apache.org
Apache Felix: http://felix.apache.org


Reply | Threaded
Open this post in threaded view
|

RE: Logo proposal

Łukasz Dywicki
Hi,
Link to logo variants after all ideas (with colors!):
http://tinyurl.com/karaf-logo-proposal2

Please take a look and sey what do you think. If you think that it can be final please vote.

Best regards,
Lukasz



-----Original Message-----
From: Łukasz Dywicki [mailto:[hidden email]]
Sent: Friday, October 22, 2010 9:42 AM
To: [hidden email]
Subject: RE: Logo proposal

Hi all,
Rafal (our graphic designer) will work on logo improvements in next week. He going to show another three logos based on your proposals.

Best regards,
Lukasz

-----Original Message-----
From: Freeman Fang [mailto:[hidden email]]
Sent: Thursday, October 21, 2010 12:56 PM
To: [hidden email]
Subject: Re: Logo proposal

I prefer to "Karaf" text is on the right,
colume 1, row 3,4, or 5 are ok for me.

Freeman
On 2010-10-21, at 下午6:42, Adrian Trenaman wrote:

> I think the best logo is the big one on the right with the fumes  
> coming out the top - nicely reminicent of the old Java logo.
>
> Whatever logo we use, I think they look best when the karaf image is  
> on the left or right of the text, not on the top.
>
> So, ideally, I'd go for bottom right, adding the fumes above the  
> Karaf image.
>
>
> On 21/10/2010 11:38, Charles Moulliard wrote:
>> I prefer 2nd row / 1st column
>>
>> On 21/10/10 12:31, Jamie G. wrote:
>>> +1 to 4th row / 1st column. An Apache feather would be a nice  
>>> touch. To keep
>>> with ASF branding rules we'll need to include a little "TM"  
>>> somewhere in the
>>> graphic.
>>>
>>> 2010/10/21 Guillaume Nodet<[hidden email]>
>>>
>>>> Nice work !
>>>> I also like the 4th row / 1st column one.   I wonder if there's a  
>>>> way to
>>>> add
>>>> a feather above the ''karaf' word.
>>>>
>>>> 2010/10/21 Ioannis Canellos<[hidden email]>
>>>>
>>>>> Hi splatch!
>>>>>
>>>>> I like the version of the logo where the icon is before the  
>>>>> karaf literal
>>>>> (1st column). However I am not sure about font. 4th row maybe!
>>>>> I also prefer the not "steaming" version, since the steaming one  
>>>>> reminds
>>>> me
>>>>> of the java logo.
>>>>>
>>>>> Keep up!
>>>>>
>>>>> 2010/10/21 Łukasz Dywicki<[hidden email]>
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> Currently Karaf Web page does not have Any logo. My intern have  
>>>>>> done
>>>> some
>>>>>> drafts:
>>>>>>
>>>>>> http://tinyurl.com/karaf-logo-proposal
>>>>>>
>>>>>>
>>>>>> What do you think about these proposals?
>>>>>>
>>>>>>
>>>>>> Best regards,
>>>>>> Lukasz
>>>>>>
>>>>>>
>>>>>>
>>>>> --
>>>>> *Ioannis Canellos*
>>>>> http://iocanel.blogspot.com
>>>>> Integration Engineer @ Upstream S.A.<http://www.upstreamsystems.com 
>>>>> >
>>>>>
>>>>
>>>> --
>>>> Cheers,
>>>> Guillaume Nodet
>>>> ------------------------
>>>> Blog: http://gnodet.blogspot.com/
>>>> ------------------------
>>>> Open Source SOA
>>>> http://fusesource.com
>>>>


--
Freeman Fang

------------------------
blog: http://freemanfang.blogspot.com
twitter: http://twitter.com/freemanfang
Open Source SOA: http://fusesource.com
Apache Servicemix:http://servicemix.apache.org
Apache Cxf: http://cxf.apache.org
Apache Karaf: http://karaf.apache.org
Apache Felix: http://felix.apache.org



Reply | Threaded
Open this post in threaded view
|

Re: Logo proposal

iocanel
Awesome work Splatch & Rafal!

I prefer the numbers from 10 - 17. I would like to see them without the
"steams/flames".

Keep up the effort!


2010/10/25 Łukasz Dywicki <[hidden email]>

> Hi,
> Link to logo variants after all ideas (with colors!):
> http://tinyurl.com/karaf-logo-proposal2
>
> Please take a look and sey what do you think. If you think that it can be
> final please vote.
>
> Best regards,
> Lukasz
>
>
>
> -----Original Message-----
> From: Łukasz Dywicki [mailto:[hidden email]]
> Sent: Friday, October 22, 2010 9:42 AM
> To: [hidden email]
> Subject: RE: Logo proposal
>
> Hi all,
> Rafal (our graphic designer) will work on logo improvements in next week.
> He going to show another three logos based on your proposals.
>
> Best regards,
> Lukasz
>
> -----Original Message-----
> From: Freeman Fang [mailto:[hidden email]]
> Sent: Thursday, October 21, 2010 12:56 PM
> To: [hidden email]
> Subject: Re: Logo proposal
>
> I prefer to "Karaf" text is on the right,
> colume 1, row 3,4, or 5 are ok for me.
>
> Freeman
> On 2010-10-21, at 下午6:42, Adrian Trenaman wrote:
>
> > I think the best logo is the big one on the right with the fumes
> > coming out the top - nicely reminicent of the old Java logo.
> >
> > Whatever logo we use, I think they look best when the karaf image is
> > on the left or right of the text, not on the top.
> >
> > So, ideally, I'd go for bottom right, adding the fumes above the
> > Karaf image.
> >
> >
> > On 21/10/2010 11:38, Charles Moulliard wrote:
> >> I prefer 2nd row / 1st column
> >>
> >> On 21/10/10 12:31, Jamie G. wrote:
> >>> +1 to 4th row / 1st column. An Apache feather would be a nice
> >>> touch. To keep
> >>> with ASF branding rules we'll need to include a little "TM"
> >>> somewhere in the
> >>> graphic.
> >>>
> >>> 2010/10/21 Guillaume Nodet<[hidden email]>
> >>>
> >>>> Nice work !
> >>>> I also like the 4th row / 1st column one.   I wonder if there's a
> >>>> way to
> >>>> add
> >>>> a feather above the ''karaf' word.
> >>>>
> >>>> 2010/10/21 Ioannis Canellos<[hidden email]>
> >>>>
> >>>>> Hi splatch!
> >>>>>
> >>>>> I like the version of the logo where the icon is before the
> >>>>> karaf literal
> >>>>> (1st column). However I am not sure about font. 4th row maybe!
> >>>>> I also prefer the not "steaming" version, since the steaming one
> >>>>> reminds
> >>>> me
> >>>>> of the java logo.
> >>>>>
> >>>>> Keep up!
> >>>>>
> >>>>> 2010/10/21 Łukasz Dywicki<[hidden email]>
> >>>>>
> >>>>>> Hello,
> >>>>>>
> >>>>>> Currently Karaf Web page does not have Any logo. My intern have
> >>>>>> done
> >>>> some
> >>>>>> drafts:
> >>>>>>
> >>>>>> http://tinyurl.com/karaf-logo-proposal
> >>>>>>
> >>>>>>
> >>>>>> What do you think about these proposals?
> >>>>>>
> >>>>>>
> >>>>>> Best regards,
> >>>>>> Lukasz
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>> --
> >>>>> *Ioannis Canellos*
> >>>>> http://iocanel.blogspot.com
> >>>>> Integration Engineer @ Upstream S.A.<http://www.upstreamsystems.com
> >>>>> >
> >>>>>
> >>>>
> >>>> --
> >>>> Cheers,
> >>>> Guillaume Nodet
> >>>> ------------------------
> >>>> Blog: http://gnodet.blogspot.com/
> >>>> ------------------------
> >>>> Open Source SOA
> >>>> http://fusesource.com
> >>>>
>
>
> --
> Freeman Fang
>
> ------------------------
> blog: http://freemanfang.blogspot.com
> twitter: http://twitter.com/freemanfang
> Open Source SOA: http://fusesource.com
> Apache Servicemix:http://servicemix.apache.org
> Apache Cxf: http://cxf.apache.org
> Apache Karaf: http://karaf.apache.org
> Apache Felix: http://felix.apache.org
>
>
>
>


--
*Ioannis Canellos*
http://iocanel.blogspot.com
Integration Engineer @ Upstream S.A. <http://www.upstreamsystems.com>
Ioannis Canellos
http://iocanel.blogspot.com
1234