Home » Eclipse Projects » Orbit » a simple idea for more flexible bundle repository
|
Re: a simple idea for more flexible bundle repository [message #4808 is a reply to message #4527] |
Thu, 13 July 2006 19:01 |
Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer.REMOVE.ca.ibm.com
This makes alot of sense but is somewhat beyond the scope of Orbit.
Clearly we need to consider how the bundles will be delivered but we are
not in the business of doing new update support etc. I suspect that the
update team will be interested in these kinds of ideas for 3.3 however.
Jeff
Eugene Kuleshov wrote:
> Hi,
>
> I would like to toss a simple idea to the air and believe that it could
> allow much better flexibility and help non-eclipse hosted projects as well.
>
> As we all know there are several big repositories of jars around (most
> of them are using layouts supported by Maven and keep artifact
> descriptors outside of the jars as opposed by OSGi). So, the only
> missing part is to put those things together while bringing those jars
> down to the client and this task can be done by the custom update site.
> Not sure if it is a widely known fact that layout of update site and
> actual update is pluggable and can be customized, so this custom update
> could use own descriptor or external metadata (like maven's POM) to
> assemble OSGi bundles right on the client side. Then we won't really
> need hosting service and can use say ibiblio repository directly and
> plugins who needed special jars could host that custom update site
> descriptor on their own and would point to the external repository for
> the actual jars.
>
> What do you think?
>
> regards,
> Eugene
>
|
|
|
Re: a simple idea for more flexible bundle repository [message #5213 is a reply to message #4808] |
Fri, 28 July 2006 10:52 |
|
Hi Eugine,
I urge you to take a closer look at www.eclipse.org/buckminster. Our objectives are much
more in line with what you ask. We introduce concepts like reader types, component types,
version types, etc. as extensionpoints into a framework so that repositories like the
maven-repo at ibiblio.org can be treated much in the same way as an update site.
Your input and ideas would be very valuable to us.
I also think there is a great potential for collaboration between the Buckminster and the
Orbix project. Perhaps we should set up a meeting and discuss?
Kind Regards,
Thomas Hallgren
Jeff McAffer wrote:
> This makes alot of sense but is somewhat beyond the scope of Orbit.
> Clearly we need to consider how the bundles will be delivered but we are
> not in the business of doing new update support etc. I suspect that the
> update team will be interested in these kinds of ideas for 3.3 however.
>
> Jeff
>
> Eugene Kuleshov wrote:
>> Hi,
>>
>> I would like to toss a simple idea to the air and believe that it
>> could allow much better flexibility and help non-eclipse hosted
>> projects as well.
>>
>> As we all know there are several big repositories of jars around
>> (most of them are using layouts supported by Maven and keep artifact
>> descriptors outside of the jars as opposed by OSGi). So, the only
>> missing part is to put those things together while bringing those jars
>> down to the client and this task can be done by the custom update
>> site. Not sure if it is a widely known fact that layout of update site
>> and actual update is pluggable and can be customized, so this custom
>> update could use own descriptor or external metadata (like maven's
>> POM) to assemble OSGi bundles right on the client side. Then we won't
>> really need hosting service and can use say ibiblio repository
>> directly and plugins who needed special jars could host that custom
>> update site descriptor on their own and would point to the external
>> repository for the actual jars.
>>
>> What do you think?
>>
>> regards,
>> Eugene
>>
|
|
|
Re: a simple idea for more flexible bundle repository [message #5280 is a reply to message #5213] |
Fri, 28 July 2006 11:21 |
Eugene Kuleshov Messages: 504 Registered: July 2009 |
Senior Member |
|
|
Thomas,
I thought that Buckminster is actually design/development time
tool.That I've been suggestion suppose work right in the run time,
allowing to on the fly conversion of the non-OSGi bundles at the
installation time. Though Buckminster can be probably used to generate
some descriptors for that.
regards,
Eugene
Thomas Hallgren wrote:
> I urge you to take a closer look at www.eclipse.org/buckminster. Our
> objectives are much more in line with what you ask. We introduce
> concepts like reader types, component types, version types, etc. as
> extensionpoints into a framework so that repositories like the
> maven-repo at ibiblio.org can be treated much in the same way as an
> update site.
>
> Your input and ideas would be very valuable to us.
>
> I also think there is a great potential for collaboration between the
> Buckminster and the Orbix project. Perhaps we should set up a meeting
> and discuss?
>
> Kind Regards,
> Thomas Hallgren
>
>
> Jeff McAffer wrote:
>> This makes alot of sense but is somewhat beyond the scope of Orbit.
>> Clearly we need to consider how the bundles will be delivered but we
>> are not in the business of doing new update support etc. I suspect
>> that the update team will be interested in these kinds of ideas for
>> 3.3 however.
>>
>> Jeff
>>
>> Eugene Kuleshov wrote:
>>> Hi,
>>>
>>> I would like to toss a simple idea to the air and believe that it
>>> could allow much better flexibility and help non-eclipse hosted
>>> projects as well.
>>>
>>> As we all know there are several big repositories of jars around
>>> (most of them are using layouts supported by Maven and keep artifact
>>> descriptors outside of the jars as opposed by OSGi). So, the only
>>> missing part is to put those things together while bringing those
>>> jars down to the client and this task can be done by the custom
>>> update site. Not sure if it is a widely known fact that layout of
>>> update site and actual update is pluggable and can be customized, so
>>> this custom update could use own descriptor or external metadata
>>> (like maven's POM) to assemble OSGi bundles right on the client
>>> side. Then we won't really need hosting service and can use say
>>> ibiblio repository directly and plugins who needed special jars
>>> could host that custom update site descriptor on their own and would
>>> point to the external repository for the actual jars.
>>>
>>> What do you think?
>>>
>>> regards,
>>> Eugene
>>>
|
|
|
Re: a simple idea for more flexible bundle repository [message #6013 is a reply to message #5280] |
Fri, 28 July 2006 12:13 |
|
Eugene Kuleshov wrote:
> Thomas,
>
> I thought that Buckminster is actually design/development time
> tool.That I've been suggestion suppose work right in the run time,
> allowing to on the fly conversion of the non-OSGi bundles at the
> installation time. Though Buckminster can be probably used to generate
> some descriptors for that.
>
Buckminster can be used for component assembly at time of installation as well as during
development and one of the repository types that we support is the eclipse update site.
Buckminster do things in three steps.
1. Resolve a component query into a complete component tree where each node is a direct
pointer to a chosen component.
2. Materialize, i.e. download all components to your local disk.
3. Bind the components to your workspace.
We are currently discussing an extension point addition that would enable 'custom binders'
for the last phase. Such a binder could create an eclipse plugin on the fly based on a jar
file that it has downloaded from some source.
Given that we have this special binder, it would be relatively easy for us to create a
dynamic update site where buckminster would serve up the contents from various repositories
such as Maven at ibiblio. The Orbit project could benefit greatly from such a solution.
Kind Regards,
Thomas Hallgren
|
|
|
Re: a simple idea for more flexible bundle repository [message #6035 is a reply to message #6013] |
Fri, 04 August 2006 14:12 |
Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer.REMOVE.ca.ibm.com
I like this direction and it sounds interesting from a provisioning
point of view in the Equinox project. To clarify Orbit itself is not
mandated to figure out new provisioning technology but rather ensure
that bundled versions of approved libs are available -- by whatever
means. In practice we will seek to have the bundles available in
various convenient forms (e.g., zips, update sites, ...) but these forms
will need to be defined somewhere else.
Jeff
Thomas Hallgren wrote:
> Eugene Kuleshov wrote:
>> Thomas,
>>
>> I thought that Buckminster is actually design/development time
>> tool.That I've been suggestion suppose work right in the run time,
>> allowing to on the fly conversion of the non-OSGi bundles at the
>> installation time. Though Buckminster can be probably used to generate
>> some descriptors for that.
>>
> Buckminster can be used for component assembly at time of installation
> as well as during development and one of the repository types that we
> support is the eclipse update site.
>
> Buckminster do things in three steps.
> 1. Resolve a component query into a complete component tree where each
> node is a direct pointer to a chosen component.
> 2. Materialize, i.e. download all components to your local disk.
> 3. Bind the components to your workspace.
>
> We are currently discussing an extension point addition that would
> enable 'custom binders' for the last phase. Such a binder could create
> an eclipse plugin on the fly based on a jar file that it has downloaded
> from some source.
>
> Given that we have this special binder, it would be relatively easy for
> us to create a dynamic update site where buckminster would serve up the
> contents from various repositories such as Maven at ibiblio. The Orbit
> project could benefit greatly from such a solution.
>
> Kind Regards,
> Thomas Hallgren
|
|
| |
Re: a simple idea for more flexible bundle repository [message #561260 is a reply to message #4808] |
Fri, 28 July 2006 10:52 |
|
Hi Eugine,
I urge you to take a closer look at www.eclipse.org/buckminster. Our objectives are much
more in line with what you ask. We introduce concepts like reader types, component types,
version types, etc. as extensionpoints into a framework so that repositories like the
maven-repo at ibiblio.org can be treated much in the same way as an update site.
Your input and ideas would be very valuable to us.
I also think there is a great potential for collaboration between the Buckminster and the
Orbix project. Perhaps we should set up a meeting and discuss?
Kind Regards,
Thomas Hallgren
Jeff McAffer wrote:
> This makes alot of sense but is somewhat beyond the scope of Orbit.
> Clearly we need to consider how the bundles will be delivered but we are
> not in the business of doing new update support etc. I suspect that the
> update team will be interested in these kinds of ideas for 3.3 however.
>
> Jeff
>
> Eugene Kuleshov wrote:
>> Hi,
>>
>> I would like to toss a simple idea to the air and believe that it
>> could allow much better flexibility and help non-eclipse hosted
>> projects as well.
>>
>> As we all know there are several big repositories of jars around
>> (most of them are using layouts supported by Maven and keep artifact
>> descriptors outside of the jars as opposed by OSGi). So, the only
>> missing part is to put those things together while bringing those jars
>> down to the client and this task can be done by the custom update
>> site. Not sure if it is a widely known fact that layout of update site
>> and actual update is pluggable and can be customized, so this custom
>> update could use own descriptor or external metadata (like maven's
>> POM) to assemble OSGi bundles right on the client side. Then we won't
>> really need hosting service and can use say ibiblio repository
>> directly and plugins who needed special jars could host that custom
>> update site descriptor on their own and would point to the external
>> repository for the actual jars.
>>
>> What do you think?
>>
>> regards,
>> Eugene
>>
|
|
|
Re: a simple idea for more flexible bundle repository [message #561277 is a reply to message #5213] |
Fri, 28 July 2006 11:21 |
Eugene Kuleshov Messages: 504 Registered: July 2009 |
Senior Member |
|
|
Thomas,
I thought that Buckminster is actually design/development time
tool.That I've been suggestion suppose work right in the run time,
allowing to on the fly conversion of the non-OSGi bundles at the
installation time. Though Buckminster can be probably used to generate
some descriptors for that.
regards,
Eugene
Thomas Hallgren wrote:
> I urge you to take a closer look at www.eclipse.org/buckminster. Our
> objectives are much more in line with what you ask. We introduce
> concepts like reader types, component types, version types, etc. as
> extensionpoints into a framework so that repositories like the
> maven-repo at ibiblio.org can be treated much in the same way as an
> update site.
>
> Your input and ideas would be very valuable to us.
>
> I also think there is a great potential for collaboration between the
> Buckminster and the Orbix project. Perhaps we should set up a meeting
> and discuss?
>
> Kind Regards,
> Thomas Hallgren
>
>
> Jeff McAffer wrote:
>> This makes alot of sense but is somewhat beyond the scope of Orbit.
>> Clearly we need to consider how the bundles will be delivered but we
>> are not in the business of doing new update support etc. I suspect
>> that the update team will be interested in these kinds of ideas for
>> 3.3 however.
>>
>> Jeff
>>
>> Eugene Kuleshov wrote:
>>> Hi,
>>>
>>> I would like to toss a simple idea to the air and believe that it
>>> could allow much better flexibility and help non-eclipse hosted
>>> projects as well.
>>>
>>> As we all know there are several big repositories of jars around
>>> (most of them are using layouts supported by Maven and keep artifact
>>> descriptors outside of the jars as opposed by OSGi). So, the only
>>> missing part is to put those things together while bringing those
>>> jars down to the client and this task can be done by the custom
>>> update site. Not sure if it is a widely known fact that layout of
>>> update site and actual update is pluggable and can be customized, so
>>> this custom update could use own descriptor or external metadata
>>> (like maven's POM) to assemble OSGi bundles right on the client
>>> side. Then we won't really need hosting service and can use say
>>> ibiblio repository directly and plugins who needed special jars
>>> could host that custom update site descriptor on their own and would
>>> point to the external repository for the actual jars.
>>>
>>> What do you think?
>>>
>>> regards,
>>> Eugene
>>>
|
|
|
Re: a simple idea for more flexible bundle repository [message #561293 is a reply to message #5280] |
Fri, 28 July 2006 12:13 |
|
Eugene Kuleshov wrote:
> Thomas,
>
> I thought that Buckminster is actually design/development time
> tool.That I've been suggestion suppose work right in the run time,
> allowing to on the fly conversion of the non-OSGi bundles at the
> installation time. Though Buckminster can be probably used to generate
> some descriptors for that.
>
Buckminster can be used for component assembly at time of installation as well as during
development and one of the repository types that we support is the eclipse update site.
Buckminster do things in three steps.
1. Resolve a component query into a complete component tree where each node is a direct
pointer to a chosen component.
2. Materialize, i.e. download all components to your local disk.
3. Bind the components to your workspace.
We are currently discussing an extension point addition that would enable 'custom binders'
for the last phase. Such a binder could create an eclipse plugin on the fly based on a jar
file that it has downloaded from some source.
Given that we have this special binder, it would be relatively easy for us to create a
dynamic update site where buckminster would serve up the contents from various repositories
such as Maven at ibiblio. The Orbit project could benefit greatly from such a solution.
Kind Regards,
Thomas Hallgren
|
|
| |
Goto Forum:
Current Time: Sat Dec 21 17:21:48 GMT 2024
Powered by FUDForum. Page generated in 0.06124 seconds
|