Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Orbit » a simple idea for more flexible bundle repository
a simple idea for more flexible bundle repository [message #4527] Thu, 13 July 2006 03:24 Go to next message
Eugene Kuleshov is currently offline Eugene KuleshovFriend
Messages: 505
Registered: July 2009
Senior Member
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 #4808 is a reply to message #4527] Thu, 13 July 2006 19:01 Go to previous messageGo to next message
Eclipse UserFriend
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 Go to previous messageGo to next message
Thomas Hallgren is currently offline Thomas HallgrenFriend
Messages: 3232
Registered: July 2009
Senior Member
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 Go to previous messageGo to next message
Eugene Kuleshov is currently offline Eugene KuleshovFriend
Messages: 505
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 Go to previous messageGo to next message
Thomas Hallgren is currently offline Thomas HallgrenFriend
Messages: 3232
Registered: July 2009
Senior Member
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 Go to previous message
Eclipse UserFriend
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 #561161 is a reply to message #4527] Thu, 13 July 2006 19:01 Go to previous message
Jeff McAffer is currently offline Jeff McAfferFriend
Messages: 104
Registered: July 2009
Senior Member
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 #561260 is a reply to message #4808] Fri, 28 July 2006 10:52 Go to previous message
Thomas Hallgren is currently offline Thomas HallgrenFriend
Messages: 3232
Registered: July 2009
Senior Member
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 Go to previous message
Eugene Kuleshov is currently offline Eugene KuleshovFriend
Messages: 505
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 Go to previous message
Thomas Hallgren is currently offline Thomas HallgrenFriend
Messages: 3232
Registered: July 2009
Senior Member
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 #561325 is a reply to message #6013] Fri, 04 August 2006 14:12 Go to previous message
Jeff McAffer is currently offline Jeff McAfferFriend
Messages: 104
Registered: July 2009
Senior Member
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
Previous Topic:ISiteFactory implementation on top of the Buckminster Maven provider?
Next Topic:How many bundles from a library?
Goto Forum:
  


Current Time: Sat Dec 20 15:54:12 GMT 2014

Powered by FUDForum. Page generated in 0.02244 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software