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]
