On Thu, Feb 24, 2011 at 2:57 PM, Martin Ždila <[email protected]> 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.
Right - yep that's exactly what we do in sigil with -imports. Though we also allow you to inherit imports from your parent much like maven pom's inherit versions from parent poms. This means you generally specify version-ranges once across a set of projects vs doing it in each leaf project. > > (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 ;-). Fingers crossed... > 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. Yep I've designed sigil with these thoughts in mind already - basically there's a set of core bundles that both the ivy and eclipse integrations depend on - if you were interested in using these elsewhere I think it should be relatively straight forward. I know someone a while back tried to do some Netbeans integration work and was partially successful. I've made some improvements since then so should be easier still. But I'd be interested in any feedback. 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. Right that should definitely be possible with the core api's - if you want to hack I could point you in the direction and you can see how it works out? > >> 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. Actually I added that already by just patching in the latest version of bnd a few months back - though please let me know if you have problems with it. > >> [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]
