I think this is an interesting discussion and I do hope we can get Sigil +
bndtools + bnd more together without loosing the strength of any one.
However, a slight warning. I am NOT doing any special effort to allow bnd to be
embedded except for a few people I work closely with. If you can fine, if you
can't too bad. There will be plugins for ant, eclipse, and there is a command
line and those are the interfaces. So bnd has NO public Java API.
Unfortunately, open source makes it impossible to make a business case out of
something like bnd that would make it worth to spent the extra effort to create
a public API.
Kind regards,
Peter Kriens
On 24 feb 2011, at 15:57, Martin Ždila wrote:
> Hi Dave
>
> On Tue, Feb 22, 2011 at 10:54 PM, David Savage <[email protected]>
> wrote:
>> I think it might be possible to use plain bnd files with ivy, but one
>> crucial difference between bnd and sigil files is that in bnd the meta
>> data describes what to do after the resources have been resolved and
>> in sigil the meta data describes both how to do the resolution and
>> what to do afterwards.
>
> In my case I have all imported packages with proper version range in
> the *.bnd files. I am not using Import-Package: * catchall, because
> this can't detect versions ranges. So, this information could be used
> also for compile-time dependency management.
>
> (You can also check this: https://github.com/bnd/bnd/issues/38)
>
>> There is a bnd hackathon [1] at this years eclipsecon which I'm
>> planning to attend maybe if there's enough interested parties there we
>> can finally get somewhere with this idea...
>
> This is a great news. I think it would be perfect to "merge" bnd and
> Sigil ;-). If you will be hacking, please think also on the developers
> embedding these tools to their own building frameworks so they can use
> some API of bnd/sigil. Also it would be good to be able to use only a
> subset of provided features - in my case I only need to resolve
> dependencies and then compute manifest headers. I will package the
> bundle externally. Also eclipse integration for dependency resolution
> is a big need.
>
>> If all you need from sigil at the moment is the 1.0.0.r${tstamp}
>> feature then raise a bug with the full details - I can probably patch
>> that in a couple of lines...
>
> Missing macros was the first I encountered, but I think there will be
> more. I think that Sgil doesn't support Service-Component annotations
> and other new cool stuff continuously being added to bnd.
>
>> [1] http://www.osgi.org/blog/2011/01/bndtools-hackaton.html
>>
>> On Tue, Feb 22, 2011 at 10:50 AM, Martin Ždila <[email protected]> wrote:
>>> Hello
>>>
>>> I have couple questions about Sigil. Currently we are using custom
>>> building framework written in java that embeds bnd, ivy, gwt, junit,
>>> javadoc and other build-support libraries.
>>>
>>> Compile-time dependency is described by plain ivy.xml module
>>> descriptors. Runtime dependency is described by plaind *.bnd files.
>>> This makes duplicity because compile-time dependencies could be also
>>> resolved from *.bnd files.
>>>
>>> Sigil uses it's own description file format. We would like to use
>>> Sigil only to resolve dependencies, but not to build the project
>>> itself. Also Eclispe integration is required and it seems to work to
>>> some degree. But we can't for example use versions like
>>> 1.0.0.r${tstamp} or other macros that bnd supports.
>>>
>>> Could you give me some hints how to only use Sigil ivy resolver with
>>> plain *.bnd files? If it is not possible, do you think it would be
>>> difficult for us to implement such an feature? And would it be from
>>> your point of view a good approach?
>
> Best regards
>
> --
> Ing. Martin Ždila
> tel:+421-908-363-848
> mailto:[email protected]
> http://www.zdila.sk/
>
> ---------------------------------------------------------------------
> 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]
