Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [orbit-dev] building orbit bundles

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?


Back to the top