Home » Eclipse Projects » Orbit » Automatic downloads
Automatic downloads [message #2830] |
Tue, 11 July 2006 05:59 |
Eclipse User |
|
|
|
Originally posted by: stepper.sympedia.de
Hi,
There are a number of libraries with a rather restrictive license.
I don't believe that mysql-connector.jar for example would ever be approved.
It would be great to have a maven/ibiblio like mechanism to specify such
dependencies and let a framework download the jars at the user side.
Could this be in the scope of this project?
Cheers
Eike
|
|
|
Re: Automatic downloads [message #2864 is a reply to message #2830] |
Tue, 11 July 2006 06:37 |
Eclipse User |
|
|
|
Originally posted by: ohurley.iona.com
Eike Stepper wrote:
> It would be great to have a maven/ibiblio like mechanism to specify such
> dependencies and let a framework download the jars at the user side.
This would certainly be a good way to automate the construction of
approved bundles. For many license-compatible pieces of OSS, there are
releases and snapshots available in maven repositories. The Apache
Felix [0,1] project, an effort to implement the OSGi R4 Service Platform,
contains a maven plugin [2] that will construct OSGi bundles, given
either an existing manifest as a file, or following embedded manifest
instructions with the maven project file. Using the maven dependency
approach, it will construct a bundle as a jar file, and will incorporate
the declared dependencies as jars within the bundle. There are a
only a small number of kinks, e.g. the versioning scheme is maven-like
rather than Eclipse-like and the embedded manifest instructions only
support OSGi-compliant properties, and this are minor.
regards
Oisin
[0] http://incubator.apache.org/felix/
[1] http://docs.safehaus.org/display/OSGI/Home
[2] http://docs.safehaus.org/display/OSGI/OSGi+Plugin+for+Maven+ 2.0
|
|
|
Re: Automatic downloads [message #2900 is a reply to message #2864] |
Tue, 11 July 2006 07:53 |
Martin Oberhuber Messages: 1007 Registered: July 2009 |
Senior Member |
|
|
Hi,
it may be out of scope of the Orbit project, but when Eike wrote
"download the jars at the user side", I thought about a tool like
a very improved Update/Packaging Manager, something like the Linux
packagers yum, apt etc.
Looks like there's two complementary approaches to 3rd party libs --
(a) Redistributing them on Eclipse Servers & Projects, which has
the advantage that everybody knows the licensing has been
aproved so redistributing in commercial packages is easier
[looks like that's what's Orbit is going to do]
(b) Writing tools for automatic retrieval at the user's side at
runtime, which has the potential of making lots more libraries,
plugins and extensions available from their native sources, at
the cost of offloading the licensing questions to the actual
users.
[anybody knows of any efforts here?]
For me, both approaches seem worth taking in their own right.
I truly hope that somebody picks up on (b) soon?
Cheers,
Martin Oberhuber
Target Management Project Lead
|
|
|
Re: Automatic downloads [message #2918 is a reply to message #2900] |
Tue, 11 July 2006 09:03 |
Eclipse User |
|
|
|
Originally posted by: ohurley.iona.com
[Martin]
> it may be out of scope of the Orbit project, but when Eike wrote
> "download the jars at the user side", I thought about a tool like
> a very improved Update/Packaging Manager....
Of course - my reply went off on a tangent that was more relevant
to the Orbit project team than the expected Orbit users. I'm
probably just over-keen to see some approved bundles :)
regards
Oisin
|
|
|
Re: Automatic downloads [message #2969 is a reply to message #2900] |
Tue, 11 July 2006 17:22 |
Eclipse User |
|
|
|
Originally posted by: stepper.sympedia.de
Martin,
Yes that's exactly what I meant ;-)
Why can't this be included in the scope of Orbit?
Cheers
/Eike
Martin Oberhuber schrieb:
> Hi,
>
> it may be out of scope of the Orbit project, but when Eike wrote
> "download the jars at the user side", I thought about a tool like
> a very improved Update/Packaging Manager, something like the Linux
> packagers yum, apt etc.
>
> Looks like there's two complementary approaches to 3rd party libs --
>
> (a) Redistributing them on Eclipse Servers & Projects, which has
> the advantage that everybody knows the licensing has been
> aproved so redistributing in commercial packages is easier
> [looks like that's what's Orbit is going to do]
>
> (b) Writing tools for automatic retrieval at the user's side at
> runtime, which has the potential of making lots more libraries,
> plugins and extensions available from their native sources, at
> the cost of offloading the licensing questions to the actual
> users.
> [anybody knows of any efforts here?]
>
> For me, both approaches seem worth taking in their own right.
> I truly hope that somebody picks up on (b) soon?
>
> Cheers,
> Martin Oberhuber
> Target Management Project Lead
|
|
|
Re: Automatic downloads [message #2985 is a reply to message #2918] |
Tue, 11 July 2006 17:24 |
Eclipse User |
|
|
|
Originally posted by: stepper.sympedia.de
Oisin,
I'd also be happy to see more jars directly contained in Orbit (given
that one can selectively reference them).
Cheers
/Eike
Oisin Hurley schrieb:
> [Martin]
>> it may be out of scope of the Orbit project, but when Eike wrote
>> "download the jars at the user side", I thought about a tool like
>> a very improved Update/Packaging Manager....
>
> Of course - my reply went off on a tangent that was more relevant
> to the Orbit project team than the expected Orbit users. I'm
> probably just over-keen to see some approved bundles :)
>
> regards
> Oisin
|
|
|
Re: Automatic downloads [message #3058 is a reply to message #2900] |
Wed, 12 July 2006 07:01 |
Eclipse User |
|
|
|
Originally posted by: paradies.transit-online.de
[Martin]
> (a) Redistributing them on Eclipse Servers & Projects, which has
> the advantage that everybody knows the licensing has been
> aproved so redistributing in commercial packages is easier
> [looks like that's what's Orbit is going to do]
IMO the consequences for (a) are well demonstrated by the Derby Core
feature which I like to see as a mandatory Orbit component. Currently
the Derby Core jars version 10.1.2.1 are provided as Enabling Feature
for BIRT. So far, so good.
Recently the Apache Derby project has announced the release of Derby
10.1.3.1 and a new Derby Core plugin with an APL2 is provided for
download at the Derby site. The BIRT update site is unaware of this
update until the project releases the Derby Core feature with the new
jars and an EPL.
I would appreciate an ibiblio like repository for common Eclipse
features as Eike proposed. And I like to see an Orbit update site in the
near future ...
Thomas
|
|
|
Re: Automatic downloads [message #4318 is a reply to message #2830] |
Wed, 12 July 2006 17:46 |
Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer.REMOVE.ca.ibm.com
What you propose is interesting but is out of Orbit :-) This project is
intended to manage only libs/bundles that have been approved by the EMO
IP process.
What you are really talking about is an improved Update mechanism such
as was mentioned in another reply (e.g., one that could use ibiblio
directly). This is indeed interesting. You should consult with the
Update team and contribute your ideas, time and code to make that happen.
Jeff
Eike Stepper wrote:
> Hi,
>
> There are a number of libraries with a rather restrictive license.
> I don't believe that mysql-connector.jar for example would ever be
> approved.
>
> It would be great to have a maven/ibiblio like mechanism to specify such
> dependencies and let a framework download the jars at the user side.
>
> Could this be in the scope of this project?
>
> Cheers
> Eike
|
|
|
Re: Automatic downloads [message #5075 is a reply to message #2864] |
Fri, 28 July 2006 10:43 |
|
Oisin Hurley wrote:
> Eike Stepper wrote:
>> It would be great to have a maven/ibiblio like mechanism to specify such
>> dependencies and let a framework download the jars at the user side.
>
> This would certainly be a good way to automate the construction of
> approved bundles. For many license-compatible pieces of OSS, there are
> releases and snapshots available in maven repositories. The Apache
> Felix [0,1] project, an effort to implement the OSGi R4 Service Platform,
> contains a maven plugin [2] that will construct OSGi bundles, given
> either an existing manifest as a file, or following embedded manifest
> instructions with the maven project file. Using the maven dependency
> approach, it will construct a bundle as a jar file, and will incorporate
> the declared dependencies as jars within the bundle. There are a
> only a small number of kinks, e.g. the versioning scheme is maven-like
> rather than Eclipse-like and the embedded manifest instructions only
> support OSGi-compliant properties, and this are minor.
>
Buckminster (www.eclipse.org/buckminster) can resolve a lot of the issues mentioned here.
Among other things, we can handle plugins that have dependencies to components that can be
found at ibiblio.org A ResourceMap that map components to locations, takes care of the
actual mapping using providers streamlined for various component types. Maven is one of the
supported types and it will enable transitive resolvement by reading the maven POM files.
Eclipse plugins and features are of course also supported.
Buckminster can also deal with different types of versions so mixing OSGi versions with
maven snapshot timestamps is possible.
Regards,
Thomas Hallgren
|
|
|
Re: Automatic downloads [message #5144 is a reply to message #2900] |
Fri, 28 July 2006 10:44 |
|
Martin Oberhuber wrote:
> Hi,
>
> it may be out of scope of the Orbit project, but when Eike wrote
> "download the jars at the user side", I thought about a tool like
> a very improved Update/Packaging Manager, something like the Linux
> packagers yum, apt etc.
>
> Looks like there's two complementary approaches to 3rd party libs --
>
> (a) Redistributing them on Eclipse Servers & Projects, which has
> the advantage that everybody knows the licensing has been
> aproved so redistributing in commercial packages is easier
> [looks like that's what's Orbit is going to do]
>
> (b) Writing tools for automatic retrieval at the user's side at
> runtime, which has the potential of making lots more libraries,
> plugins and extensions available from their native sources, at
> the cost of offloading the licensing questions to the actual
> users.
> [anybody knows of any efforts here?]
>
> For me, both approaches seem worth taking in their own right.
> I truly hope that somebody picks up on (b) soon?
>
Someone already has. Buckminster aims to do exactly what you describe in (b). See
www.eclipse.org/buckminster. Most of the info is on our wiki.
Regards,
Thomas Hallgren
|
|
|
Re: Automatic downloads [message #560794 is a reply to message #2830] |
Tue, 11 July 2006 06:37 |
Oisin Hurley Messages: 204 Registered: July 2009 |
Senior Member |
|
|
Eike Stepper wrote:
> It would be great to have a maven/ibiblio like mechanism to specify such
> dependencies and let a framework download the jars at the user side.
This would certainly be a good way to automate the construction of
approved bundles. For many license-compatible pieces of OSS, there are
releases and snapshots available in maven repositories. The Apache
Felix [0,1] project, an effort to implement the OSGi R4 Service Platform,
contains a maven plugin [2] that will construct OSGi bundles, given
either an existing manifest as a file, or following embedded manifest
instructions with the maven project file. Using the maven dependency
approach, it will construct a bundle as a jar file, and will incorporate
the declared dependencies as jars within the bundle. There are a
only a small number of kinks, e.g. the versioning scheme is maven-like
rather than Eclipse-like and the embedded manifest instructions only
support OSGi-compliant properties, and this are minor.
regards
Oisin
[0] http://incubator.apache.org/felix/
[1] http://docs.safehaus.org/display/OSGI/Home
[2] http://docs.safehaus.org/display/OSGI/OSGi+Plugin+for+Maven+ 2.0
|
|
|
Re: Automatic downloads [message #560818 is a reply to message #2864] |
Tue, 11 July 2006 07:53 |
Martin Oberhuber Messages: 1007 Registered: July 2009 |
Senior Member |
|
|
Hi,
it may be out of scope of the Orbit project, but when Eike wrote
"download the jars at the user side", I thought about a tool like
a very improved Update/Packaging Manager, something like the Linux
packagers yum, apt etc.
Looks like there's two complementary approaches to 3rd party libs --
(a) Redistributing them on Eclipse Servers & Projects, which has
the advantage that everybody knows the licensing has been
aproved so redistributing in commercial packages is easier
[looks like that's what's Orbit is going to do]
(b) Writing tools for automatic retrieval at the user's side at
runtime, which has the potential of making lots more libraries,
plugins and extensions available from their native sources, at
the cost of offloading the licensing questions to the actual
users.
[anybody knows of any efforts here?]
For me, both approaches seem worth taking in their own right.
I truly hope that somebody picks up on (b) soon?
Cheers,
Martin Oberhuber
Target Management Project Lead
|
|
| |
Re: Automatic downloads [message #560873 is a reply to message #2900] |
Tue, 11 July 2006 17:22 |
|
Martin,
Yes that's exactly what I meant ;-)
Why can't this be included in the scope of Orbit?
Cheers
/Eike
Martin Oberhuber schrieb:
> Hi,
>
> it may be out of scope of the Orbit project, but when Eike wrote
> "download the jars at the user side", I thought about a tool like
> a very improved Update/Packaging Manager, something like the Linux
> packagers yum, apt etc.
>
> Looks like there's two complementary approaches to 3rd party libs --
>
> (a) Redistributing them on Eclipse Servers & Projects, which has
> the advantage that everybody knows the licensing has been
> aproved so redistributing in commercial packages is easier
> [looks like that's what's Orbit is going to do]
>
> (b) Writing tools for automatic retrieval at the user's side at
> runtime, which has the potential of making lots more libraries,
> plugins and extensions available from their native sources, at
> the cost of offloading the licensing questions to the actual
> users.
> [anybody knows of any efforts here?]
>
> For me, both approaches seem worth taking in their own right.
> I truly hope that somebody picks up on (b) soon?
>
> Cheers,
> Martin Oberhuber
> Target Management Project Lead
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
Re: Automatic downloads [message #560887 is a reply to message #2918] |
Tue, 11 July 2006 17:24 |
|
Oisin,
I'd also be happy to see more jars directly contained in Orbit (given
that one can selectively reference them).
Cheers
/Eike
Oisin Hurley schrieb:
> [Martin]
>> it may be out of scope of the Orbit project, but when Eike wrote
>> "download the jars at the user side", I thought about a tool like
>> a very improved Update/Packaging Manager....
>
> Of course - my reply went off on a tangent that was more relevant
> to the Orbit project team than the expected Orbit users. I'm
> probably just over-keen to see some approved bundles :)
>
> regards
> Oisin
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
| | |
Re: Automatic downloads [message #561228 is a reply to message #2864] |
Fri, 28 July 2006 10:43 |
|
Oisin Hurley wrote:
> Eike Stepper wrote:
>> It would be great to have a maven/ibiblio like mechanism to specify such
>> dependencies and let a framework download the jars at the user side.
>
> This would certainly be a good way to automate the construction of
> approved bundles. For many license-compatible pieces of OSS, there are
> releases and snapshots available in maven repositories. The Apache
> Felix [0,1] project, an effort to implement the OSGi R4 Service Platform,
> contains a maven plugin [2] that will construct OSGi bundles, given
> either an existing manifest as a file, or following embedded manifest
> instructions with the maven project file. Using the maven dependency
> approach, it will construct a bundle as a jar file, and will incorporate
> the declared dependencies as jars within the bundle. There are a
> only a small number of kinks, e.g. the versioning scheme is maven-like
> rather than Eclipse-like and the embedded manifest instructions only
> support OSGi-compliant properties, and this are minor.
>
Buckminster (www.eclipse.org/buckminster) can resolve a lot of the issues mentioned here.
Among other things, we can handle plugins that have dependencies to components that can be
found at ibiblio.org A ResourceMap that map components to locations, takes care of the
actual mapping using providers streamlined for various component types. Maven is one of the
supported types and it will enable transitive resolvement by reading the maven POM files.
Eclipse plugins and features are of course also supported.
Buckminster can also deal with different types of versions so mixing OSGi versions with
maven snapshot timestamps is possible.
Regards,
Thomas Hallgren
|
|
|
Re: Automatic downloads [message #561241 is a reply to message #2900] |
Fri, 28 July 2006 10:44 |
|
Martin Oberhuber wrote:
> Hi,
>
> it may be out of scope of the Orbit project, but when Eike wrote
> "download the jars at the user side", I thought about a tool like
> a very improved Update/Packaging Manager, something like the Linux
> packagers yum, apt etc.
>
> Looks like there's two complementary approaches to 3rd party libs --
>
> (a) Redistributing them on Eclipse Servers & Projects, which has
> the advantage that everybody knows the licensing has been
> aproved so redistributing in commercial packages is easier
> [looks like that's what's Orbit is going to do]
>
> (b) Writing tools for automatic retrieval at the user's side at
> runtime, which has the potential of making lots more libraries,
> plugins and extensions available from their native sources, at
> the cost of offloading the licensing questions to the actual
> users.
> [anybody knows of any efforts here?]
>
> For me, both approaches seem worth taking in their own right.
> I truly hope that somebody picks up on (b) soon?
>
Someone already has. Buckminster aims to do exactly what you describe in (b). See
www.eclipse.org/buckminster. Most of the info is on our wiki.
Regards,
Thomas Hallgren
|
|
|
Goto Forum:
Current Time: Thu Sep 26 05:17:33 GMT 2024
Powered by FUDForum. Page generated in 0.08194 seconds
|