felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicolas Lalevée <nicolas.lale...@hibnet.org>
Subject Re: Maven & OSGi plans
Date Mon, 25 Aug 2008 15:31:21 GMT

Le 25 août 08 à 15:24, Craig Phillips a écrit :

> Hi,
> I may not completely understand your question... My answer may be  
> "old school lib folder" or there abouts, but I can't be certain of  
> that answer just yet...

My actual question was how do you setup your build classpath without  
using maven (and you answered more precisely than I expected, talking  
about the api/impl separation, which is one of my concern with using  

> [on an aside, take a look at BUILDR, although it's still in  
> incubation: http://incubator.apache.org/buildr/ ... I give them an A 
> + for attitude :) ]
> For the most part, I am not [currently] building big systems of  
> large numbers of bundles... That type of setup would likely require  
> something sophisticated (more so than probably any toolset would  
> provide out of the box); I've been amassing mostly small self  
> contained bundles / services -- for this purpose, ANT/BND is more  
> than fine;

ok, that's what I called having an "old-school" library folder (note I  
don't mean old school is bad practice, I sometimes do use it :) )

> In all my cases, I have all of the necessary bundles to build (if  
> not run) on hand; One of my pet peeves, especially abused on the  
> equinox side that I've seen [not just provider, but end user], is a  
> lack of separation of interface/api from implementation...
> to this end, for build, you should only have API bundles on hand for  
> the project/classpath/lib; As for run time, that's when you'd bring  
> in the IMPL's... Whether you bring the IMPL's in a la OBR or local  
> dir at run time, that's a run time decision on your part, but  
> shouldn't cause issue with compile time; Of course, this is all  
> predicated on separating API from IMPL, which I practice like a  
> religion, but others don't -- OSGi changes your mind set and you  
> need to get used to having large numbers of small / tiny bundles  
> ('er, dot.jars) -- this way, at run time, you can upgrade and rewire  
> (reference Newton as well) and keep your "system" running 24x7; You  
> can upgrade versions of IMPLs and let the re-wiring do it's magic  
> (noting you probably shouldn't be upgrading your LogService IMPL  
> every 15 minutes, obviously)...

Actually that's what I was not sure: is there a different classpath  
for building and running. In your project you do. So the solution I  
tried with an obr doesn't fit well for your use case.
About API / impl separation of concerns, I was thinking that OSGi  
actually address it. If there is a proper manifest on a bundle that  
contains both API and implementation, it should export only its API,  
so the bundle can represent both: the API for compile time classpath,  
and the implementation contained in the same bundle for the runtime.  
Neil Bartlett wrote an interesting article about it [1].
Thought I am not sure if having both merged in one bundle would affect  
the upgrade process, I have no much experience in running an OSGi  


[1] http://neilbartlett.name/blog/2008/07/29/module-dependencies-and-the-gruesome-version-99/

> Not sure where this is all leading in the discussion, nor if it  
> addressed your specific concerns / questions... but I keep coming  
> back to building against APIs...
> For how ever many gains of salt are necessary, Craig
> ________________________________
> From: Nicolas Lalevée [mailto:nicolas.lalevee@hibnet.org]
> Sent: Mon 8/25/2008 8:38 AM
> To: dev@felix.apache.org
> Subject: Re: Maven & OSGi plans
> Le 25 août 08 à 12:44, Rob Walker a écrit :
> I am then interested to know how you manage the classpath of your
> project. Because there is a little gap between the bnd/MANIFEST.MF
> that only declare a dependency on some packages, and the actually jars
> your are building against.
> So do you manage your jars dependencies manually ? with an old-school
> lib folder ?
> Or you have a dependency manager setup ? Ivy or maven just to retrieve
> the jars ?
> I thought of a third solution, but I didn't found any such tool: use
> an OBR to compute the dependencies and retrieve the jars. I used the
> Felix OBR resolver implementation and I managed to do a similar plugin
> to IvyDE [1] (just a proof of concept here, implemented with lot of
> hacks). But I am not sure if the "obr service" can be used for that
> kind of classpath computing, as its main goal, as far as I understand,
> is to get bundle into a OSGi runtime environment. There is that
> "compile" vs "runtime" classpath issue. But not sure if that is an
> issue... WDYT ?
> Nicolas
> [1] http://ant.apache.org/ivy/ivyde/
>>> ________________________________
>>> From: Richard S. Hall [mailto:heavy@ungoverned.org]
>>> Sent: Fri 8/22/2008 9:15 PM
>>> To: dev@felix.apache.org
>>> Subject: Maven & OSGi plans
>>> I am not sure if this will be beneficial to us or not, since it
>>> sounds
>>> like a) they plan on duplicating or effort around the Bundle Plugin
>>> and
>>> b) they are getting really cozy with Eclipse, but it is an
>>> interesting
>>> read nonetheless:
>>>   http://blogs.sonatype.com/jvanzyl/2008/08/21/1219331495607.html
>>> -> richard
>> --
>> Ascert - Taking systems to the Edge
>> robw@ascert.com
>> +44 (0)20 7488 3470
>> www.ascert.com

View raw message