Re: [orbit-dev] building orbit bundles

[Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>]

Ben Konrath wrote on 01/20/2007 02:55:39 PM:

> On Thu, 2007-01-18 at 23:23 -0500, Jeff McAffer wrote:
> > We currently get the ICU binary and source bundles directly from
the
> > ICU team and simply include them in the build.  No ziping,
tarring,
> > jaring, slicing, dicing or even julien'ing.  The complete
built
> > bundles do happen to be in CVS somewhere to facilitate repeatable
> > builds but they are just stashed there in complete, built form.
 Does
> > a source JAR in the form we currently ship work for you? 
> 
> No, there's no way generate the build scripts with "src"
plugins so we
> can't build it. 

I'm not sure what you mean here.  If you get
a source jar from someone do you want to "build" it too?  
In the case of prebuilt things like ICU etc the idea is to deliver individual
source bundles which are basically what would be a source jar with OSGi
metadata etc injected.  

> I think I a lot of people get confused on this
point and
> think that it's possible to build a bundle from the source bundle.
If we
> could make a standalone app to build binary bundles from source bundles,
> only needing eclipse if the bundle needs eclipse to compile, that
would
> help.  

Yes, this is a confusion but Eclipse is by no means
unique in its interpretation of "source".  Our model is
that the source bundles include whatever is needed to develop code that
*uses* the corresponding binary bundle.  That is, the source bundles
are form of SDK.  

> > Unfortunately I did mean the ICU and SSH
projects.  Basically assume
> > that Eclipse was out of your picture but you were including some
> > random wad of Java code for some function and that wad used ICU.
> >  Would you expect the project creating the wad to also have
the source
> > for ICU in their repo?  Map this out to people who use commons
> > logging, log4j etc etc.   
> 
> I agree that in the general case of using a third party library, a
> project shouldn't include that source in their repo. But, the icu4j
> bundles are different because they require eclipse to create the build
> files which creates a cycle in the build dependency tree. 

I'm still not seeing the issue here.  Are you
saying that the code used to generate the build files to build ICU in fact
uses ICU?  Do you know where that dependency is coming from?  ICU
should not have to do anything too complicated to build since it does not
depend on any other bundles.  Perhaps another approach is for them
to supply pregenerated build files?

> If you were to
> include the source for the icu4j bundles in your repo, you could avoid
> this cycle because the build files would be generated and included
like
> all of the other bundles in the SDK.

I understand but we cannot be responsible for building
ICU.  Who knows how they decide to build there stuff.  For example
they might be one of those wild-eyed Maven guys (ok ok, I'm joking :-)
in which case we would have to accomodate their build infrastructure embedded
in the middle of ours.

> > BTW, what do you do for JSCH?  We don't
even have/ship source for
> > that. 
> 
> We build JSCH from the upstream source, unpack the bundle, remove
the
> class files you provide, replace them with the class files that we
> compiled from the original upstream source and finally repack the
jar. I
> think this is what all the Linux distros will have to do for all of
the
> Orbit provided bundles when projects start using them. 

Right.  That seems reasonable.  However
you are going to have similar issues with any bundle/JAR that is built
with PDE build or Maven (actually, is Maven built with Maven?  If
so, how do you get around that circularity for JARs built using Maven?).

As a point of interest, what do you use for a Java
compiler?  How is that built?

Jeff