Hi David,
everythings running nicely now with the Sigil classes in use and the eclipse
dependency, and I've included a simple repository browser in VisualOSGi
(http://eppleton.sharedhost.de/blog/?p=902). I've already started to
implement support for installing bundles via Drag and Drop.
I've got some problems running Equinox in embedded mode in the same manner I
can run Felix and Knopflerfish though. Equinox seems to be querying the
system for JVM and classloader info and jar location. The same code that
runs nicely in a regular java app, doesn't run in NetBeans classloader
infrastructure. I'm using this test code:
Map<String, Object> m = new HashMap<String, Object>();
m.put(Constants.FRAMEWORK_STORAGE_CLEAN, "onFirstInit");
EquinoxFactory ef = new EquinoxFactory();
fwk = ef.newFramework(m);
fwk.start();
Sorry for asking Equinox related questions here, but I saw that you had
similar problems
(http://osdir.com/ml/dev-felix-apache/2009-08/msg00128.html). I'm getting
the same error messages. Did you find a workaround?
--Toni
David Savage wrote:
>
> Hi Toni,
>
> You may want to replicate the ivy config I have in sigil for the
> eclipse dependencies - saves you typing anyway:
>
> $felix-trunk/sigil/bldcommon/ivysettings.xml
> <resolvers>
> ...
> <url name="eclipse">
> <artifact
> pattern="http://download.eclipse.org/releases/ganymede/plugins/[module]_[revision].[ext]";
> />
> </url>
> ...
> </resolvers>
>
> $felix-trunk/sigil/bldcommon/prepare/ivy.xml
> <dependencies>
> ...
> <dependency org="org.eclipse"
> name="org.eclipse.equinox.common" rev="3.4.0.v20080421-2006" />
> ...
> </dependencies>
>
> Regards,
>
> Dave
>
> On Thu, Aug 20, 2009 at 2:32 PM, eppleton<[email protected]> wrote:
>>
>> Hi David,
>>
>> Downloading the bundles for the build shouldn't be problematic. By
>> default
>> NB projects are ANT based, and I've been using Ivy in NB for downloading
>> the
>> libraries of my library wrapper modules. For the plugin I'd probably need
>> to
>> build a library wrapper for these jars anyway. Right now there's no other
>> way in NB for downloading and Installing plugins.
>>
>> I'm not familiar with IPath and IProgressMonitor, I'll have a look at
>> them.
>> For now I'll use the obr interfaces for VisualOSGi and check the Sigil
>> classes again, when it comes to the integration with NetBeans builds and
>> Bundle Project types. Right now I only need very basic functionality, but
>> I'll keep the basic structure I used with my Sigil tests, so it will be
>> easy
>> to switch back later.
>>
>> Thanks
>> --Toni
>>
>>
>> David Savage wrote:
>>>
>>> Hi Toni,
>>>
>>> Yep I've been thinking of refactoring this but haven't found a good
>>> alternative for the frankly extremely useful IPath and
>>> IProgressMonitor classes. Actually eclipse are very good citizens in
>>> this respect as you can get hold of these base classes via the
>>> following bundle:
>>>
>>> http://download.eclipse.org/releases/ganymede/plugins//org.eclipse.equinox.common_3.4.0.v20080421-2006.jar
>>>
>>> I've created an issue for this [1] but I guess the question is are
>>> there any alternative impls out there. I guess we could also define
>>> our own helper classes for sigil which mirror this functionality but
>>> this seems to be missing the point in modularization somewhat?
>>>
>>> In sigil-ivy I've set up the build such that it downloads these
>>> dependencies on the fly from eclipse.org so apache doesn't have to
>>> host the bundle. In eclipse the classes are obviously already there. I
>>> guess there's a question mark about how to get this bundle into a
>>> netbeans environment though - can netbeans download arbitary jars as
>>> part of a plugin install?
>>>
>>> Regards,
>>>
>>> Dave
>>>
>>> [1] https://issues.apache.org/jira/browse/FELIX-1509
>>>
>>> On Thu, Aug 20, 2009 at 1:05 PM, eppleton<[email protected]> wrote:
>>>>
>>>> Hi David,
>>>>
>>>> I've implemented a RepositoryManager for my RepositoryBrowser. I was
>>>> looking
>>>> into using a IRepositoryVisitor implementation for getting hold of the
>>>> Bundles but it seems that the ISigilBundle Interface depends on some
>>>> eclipse
>>>> classes for progressmonitoring. Is there a way around these
>>>> dependencies
>>>> in
>>>> Sigil?
>>>>
>>>> --Toni
>>>>
>>>>
>>>>
>>>> David Savage wrote:
>>>>>
>>>>> Hi Tony,
>>>>>
>>>>> So the good news is the OBR format is already integrated with the
>>>>> sigil resolver. There are two paths via which the resolver is used in
>>>>> sigil at the moment - either from the ivy build or the eclipse
>>>>> workspace.
>>>>>
>>>>> The class org.apache.felix.sigil.ivy.BldRepositoryManager loads the
>>>>> repositories specified in a properties file format, using an
>>>>> abstracted RepositoryProviderFactory pattern to load various instances
>>>>> of factories (obr, file, workspace). To see an example of this take a
>>>>> look at the file:
>>>>>
>>>>> $felix-trunk/sigil/bldcommon/sigil-repos.properties
>>>>>
>>>>> In eclipse the class to look at is
>>>>> org.apache.felix.sigil.eclipse.internal.repository.eclipse.SigilRepositoryManager
>>>>> which takes it's configuration from the eclipse preferences and does
>>>>> similar tricks with loading repository providers, though this time the
>>>>> providers are installed via eclipse extension points.
>>>>>
>>>>> To see examples of the repository in use you could look at:
>>>>>
>>>>> org.apache.felix.sigil.ui.eclipse.ui.views.resolution.BundleResolverView
>>>>> // draws a graph of bundle dependencies
>>>>> org.apache.felix.sigil.ui.eclipse.ui.views.RepositoryViewPart // draws
>>>>> a table of bundles in a particular repo
>>>>> org.apache.felix.sigil.eclipse.model.util.JavaHelper.resolveClasspathEntrys
>>>>> // builds up an eclipse classpath based on resolution of bundles from
>>>>> repository
>>>>>
>>>>> The conversation regarding resolvers is referenced here:
>>>>>
>>>>> http://www.mail-archive.com/[email protected]/msg10880.html
>>>>>
>>>>> No actual code has moved yet, but the general gist of the conversation
>>>>> was that it would be "nice" to be able to reuse a common fast OSGi
>>>>> resolution algorithm in the development, deployment and runtime parts
>>>>> of the osgi lifecycle.
>>>>>
>>>>> Hope that's of help...
>>>>>
>>>>> Regards,
>>>>>
>>>>> Dave
>>>>>
>>>>> On Tue, Aug 18, 2009 at 1:42 PM, eppleton<[email protected]> wrote:
>>>>>>
>>>>>> Hi David,
>>>>>>
>>>>>> I'm now at a point, where I want to integrate a repository browser
>>>>>> similar
>>>>>> to the Eclipse RepositoryBrowser to my tool (
>>>>>> http://eppleton.sharedhost.de/blog/?p=867 ). So I'm trying to decide
>>>>>> which
>>>>>> approach to use and I'm seeking your advice.
>>>>>>
>>>>>> One possible solution would be to use the Sigil resolver for this.
>>>>>> Could
>>>>>> you
>>>>>> give me some pointers how this is implemented for Eclipse?
>>>>>>
>>>>>> I'm also thinking about using the OSGi obr API. Again, I haven't
>>>>>> worked
>>>>>> with
>>>>>> those yet and I've been looking around the web for some pointers but
>>>>>> found
>>>>>> nothing. Is there a spec somewhere about the OBR format and some
>>>>>> explanations on the API (the API doc is quite cryptic :-)). You
>>>>>> mentioned
>>>>>> a
>>>>>> discussion going on about resolvers. Could you provide a link to this
>>>>>> discussion?
>>>>>>
>>>>>>
>>>>>> --Toni
>>>>>>
>>>>>>
>>>>>>
>>>>>> David Savage wrote:
>>>>>>>
>>>>>>> On Wed, Aug 12, 2009 at 2:23 PM, eppleton<[email protected]> wrote:
>>>>>>>
>>>>>>> In sigil we have built a resolver that understands this model and
>>>>>>> can
>>>>>>> navigate around various abstracted repository providers (currently
>>>>>>> just file system and obr) to pull the relevant OSGi artifacts that
>>>>>>> satisfy build dependencies. There is another conversation on going
>>>>>>> at
>>>>>>> the moment regarding potential pooling of resources and reusing
>>>>>>> either
>>>>>>> the Felix runtime resolver or the OBR resolver or some super set of
>>>>>>> all of these to do really fast resolution of hard problems like uses
>>>>>>> (which for the time being the sigil resolver neatly ignores)
>>>>>>>
>>>>>>>>
>>>>>>>> Do you have bnd file support, or are you creating the Properties
>>>>>>>> for
>>>>>>>> bnd
>>>>>>>> on-the-fly?
>>>>>>>
>>>>>>> We have our own file format, though it is very similar to BND in
>>>>>>> that
>>>>>>> it is just a simple properties file vs an xml file, the main reason
>>>>>>> for this being that it makes it easier to edit the file outside of
>>>>>>> the
>>>>>>> IDE environment. Currently we parse this file and generate bnd
>>>>>>> instructions based on the project environment (i.e. we support
>>>>>>> inheritance of properties from parent projects - which saves all the
>>>>>>> leaf nodes declaring boilerplate headers and version ranges).
>>>>>>>
>>>>>>>>
>>>>>>>> I'll start working on this part as soon as I've got my admin tool
>>>>>>>> running.
>>>>>>>
>>>>>>> No probs, talk later ;)
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> Dave
>>>>>>>
>>>>>>>>
>>>>>>>> Cheers
>>>>>>>>
>>>>>>>> --Toni
>>>>>>>>
>>>>>>>>
>>>>>>>> David Savage wrote:
>>>>>>>>>
>>>>>>>>> Hi Toni,
>>>>>>>>>
>>>>>>>>> So Sigil is new here at Felix too, we're currently in a migration
>>>>>>>>> phase at the moment as this used to be hosted at
>>>>>>>>> http://sigil.codecauldron.org, but there's some docs here:
>>>>>>>>>
>>>>>>>>> http://felix.apache.org/site/apache-felix-sigil.html
>>>>>>>>>
>>>>>>>>> and I've set up a bunch of issues here:
>>>>>>>>>
>>>>>>>>> http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=12310100&component=12312962&resolution=-1&sorter/field=priority&sorter/order=DESC
>>>>>>>>>
>>>>>>>>> I have sigil to a stage where it can build itself - i.e. resolve
>>>>>>>>> dependencies from external repositories based on import/require
>>>>>>>>> OSGi
>>>>>>>>> meta data and compile and build the bundles to then be manually
>>>>>>>>> installed in eclipse. There's currently no netbeans integration
>>>>>>>>> mainly
>>>>>>>>> due to bandwidth but the underlying model is pretty portable as it
>>>>>>>>> can
>>>>>>>>> be used in both ivy and eclipse environments.
>>>>>>>>>
>>>>>>>>> The plan at the moment for the debug support is to use the Felix
>>>>>>>>> launcher which is now able to launch any other OSGi framework via
>>>>>>>>> the
>>>>>>>>> new OSGi 4.2 launcher api - of course there's still work to plugin
>>>>>>>>> the
>>>>>>>>> process control to the IDE and visualise the various options for
>>>>>>>>> OSGi
>>>>>>>>> launching.
>>>>>>>>>
>>>>>>>>> Feel free to post questions here or on the dev mailing list if
>>>>>>>>> you're
>>>>>>>>> interested in getting involved :)
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>>
>>>>>>>>> Dave
>>>>>>>>>
>>>>>>>>> On Wed, Aug 12, 2009 at 11:43 AM, eppleton<[email protected]>
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> Hi David,
>>>>>>>>>>
>>>>>>>>>> no this is the first time IM on this list. Sure, maybe we can
>>>>>>>>>> join
>>>>>>>>>> forces.
>>>>>>>>>> Do you have a thread for this?
>>>>>>>>>>
>>>>>>>>>> --Toni
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> David Savage-3 wrote:
>>>>>>>>>>>
>>>>>>>>>>> Hi Toni,
>>>>>>>>>>>
>>>>>>>>>>> Sorry off topic from your question but, just wondering if you've
>>>>>>>>>>> seen
>>>>>>>>>>> sigil here on felix, which is attempting to build a common set
>>>>>>>>>>> of
>>>>>>>>>>> osgi
>>>>>>>>>>> developer tools. I'm currently looking runtime support in
>>>>>>>>>>> eclipse
>>>>>>>>>>> wondering if you'd be interested in joining forces to work on
>>>>>>>>>>> netbeans
>>>>>>>>>>> integration?
>>>>>>>>>>>
>>>>>>>>>>> Regards,
>>>>>>>>>>>
>>>>>>>>>>> Dave
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 12 Aug 2009, at 10:10, eppleton <[email protected]> wrote:
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> Is there a way to get the classes of the OSGi API and the Felix
>>>>>>>>>>>> implementation in two separate JARs?
>>>>>>>>>>>>
>>>>>>>>>>>> I'm creating a plugin for NetBeans to register and administrate
>>>>>>>>>>>> OSGi
>>>>>>>>>>>> containers. Felix ist the default, but I want my tool to rely
>>>>>>>>>>>> on
>>>>>>>>>>>> the
>>>>>>>>>>>> API
>>>>>>>>>>>> only in order to be able to plugin other implementations (e.g.
>>>>>>>>>>>> Knopflerfish). So the UI can display information for a Bundle
>>>>>>>>>>>> regardless
>>>>>>>>>>>> where it comes from.
>>>>>>>>>>>>
>>>>>>>>>>>> If there's nothing like that out-of-the-box, I'll do it
>>>>>>>>>>>> manually.
>>>>>>>>>>>> The
>>>>>>>>>>>> question then is: Would that work since it seems I'll also have
>>>>>>>>>>>> to
>>>>>>>>>>>> split up
>>>>>>>>>>>> the manifest then...
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks
>>>>>>>>>>>>
>>>>>>>>>>>> --Toni
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> View this message in context:
>>>>>>>>>>>> http://www.nabble.com/APi-and-Implementation-in-separate-JARs-tp24931883p24931883.html
>>>>>>>>>>>> Sent from the Apache Felix - Users mailing list archive at
>>>>>>>>>>>> Nabble.com.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>> To unsubscribe, e-mail: [email protected]
>>>>>>>>>>>> For additional commands, e-mail: [email protected]
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>> To unsubscribe, e-mail: [email protected]
>>>>>>>>>>> For additional commands, e-mail: [email protected]
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> View this message in context:
>>>>>>>>>> http://www.nabble.com/APi-and-Implementation-in-separate-JARs-tp24931883p24933924.html
>>>>>>>>>> Sent from the Apache Felix - Users mailing list archive at
>>>>>>>>>> Nabble.com.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: [email protected]
>>>>>>>>>> For additional commands, e-mail: [email protected]
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: [email protected]
>>>>>>>>> For additional commands, e-mail: [email protected]
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> View this message in context:
>>>>>>>> http://www.nabble.com/APi-and-Implementation-in-separate-JARs-tp24931883p24936379.html
>>>>>>>> Sent from the Apache Felix - Users mailing list archive at
>>>>>>>> Nabble.com.
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: [email protected]
>>>>>>>> For additional commands, e-mail: [email protected]
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: [email protected]
>>>>>>> For additional commands, e-mail: [email protected]
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> View this message in context:
>>>>>> http://www.nabble.com/APi-and-Implementation-in-separate-JARs-tp24931883p25024056.html
>>>>>> Sent from the Apache Felix - Users mailing list archive at
>>>>>> Nabble.com.
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: [email protected]
>>>>>> For additional commands, e-mail: [email protected]
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [email protected]
>>>>> For additional commands, e-mail: [email protected]
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> View this message in context:
>>>> http://www.nabble.com/APi-and-Implementation-in-separate-JARs-tp24931883p25060806.html
>>>> Sent from the Apache Felix - Users mailing list archive at Nabble.com.
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [email protected]
>>>> For additional commands, e-mail: [email protected]
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [email protected]
>>> For additional commands, e-mail: [email protected]
>>>
>>>
>>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/APi-and-Implementation-in-separate-JARs-tp24931883p25062110.html
>> Sent from the Apache Felix - Users mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>
>
--
View this message in context:
http://www.nabble.com/APi-and-Implementation-in-separate-JARs-tp24931883p25101626.html
Sent from the Apache Felix - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
