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
maven).
[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
environment.
Nicolas
[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:[EMAIL PROTECTED]
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:[EMAIL PROTECTED]
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
[EMAIL PROTECTED]
+44 (0)20 7488 3470
www.ascert.com
