Re: [orbit-dev] building orbit bundles
With the Apache Felix Maven plugin would orbit accept pre-build bundles? We have just been thinking about using the Maven plugins to generate both the OSGI bundle and maybe a testing bundle (containing any testcases) - also maybe Maven could create the source bundle with it? It might be a great way of getting Maven based projects ready for Orbit?
On 1/18/07, Jeff McAffer <Jeff_McAffer@xxxxxxxxxx> wrote:
I'm not sure which tool you are refering
to. There is the stuff going on in Apache Felix (I believe
that is documented there) and there is the process we use to bundle things
in Orbit. That is not a tool but is documented on the Orbit wiki.
Is there something else?
If you could provide a more elaborate requirement spec. for this tool (a
wiki page that explains how Orbit does this would be great), we would be
interested in incorporating it into Buckminster. The way I see it, it
ought to be possible to directly materialize any jar as a bundle.
Jeff McAffer wrote:
> Ben Konrath wrote on 01/17/2007 03:34:53 PM:
> > Once Eclipse projects start using bundles provided by Orbit,
we will no
> > longer be able to symlink to the jars installed on the system.
> > possible solution is to build the Orbit bundle along with our
> > build and create a sub-package that is exclusively used by our
> > packages. For example, if we needed to use an orbit provided
> > bundle, we would do a regular build of tomcat with the sources
> > by apache and then use a tool to make the tomcat bundle, putting
> > bundle in a separate package. Our eclipse build and package would
> > require this tomcat eclipse package. Is there a tool to create
> > Orbit bundles from regular java jars? If not, are there any plans
> > create one?
> Such a tool would be interesting and there has been some work in that
> direction in the Apache Felix area. They are looking mostly
> manifest generation. We have some different requirements (e.g.,
> file injection, hand crafted manifests, ...) that have partially
> driven the current approach. The short answer then is no, the
> has not come up.
> Having said that, what is happening here is not rocket science.
> Basically we are taking built thing and adding a few files to
> JAR'ing it up. Your build could, for example, check out the
> stuff, build the lib from source, replace the Orbit supplied compiled
> classes with your compiled classes and then "build" the
> Yucky perhaps but it would indeed work.
> Remember, Orbit is for the most part not changing how we are shipping
> things or really even how they are produced, just where they are
> There will be an interesting question as to how you ensure that the
> thing you built is the same as what we ship from Eclipse but that
> not unique to or brought on by Orbit.
> > Speaking of which, the icu4j bundles included with the SDK currently
> > require Eclipse to generate the build files. Is this something
> > be addressed with the efforts of this project? Or should I just
> > bug to resolve this problem. My naive solution would be to import
> > contributed icu4j plugin sources into cvs and generate the build
> > in the same way that build files are currently generated for
> > plugins in the SDK.
> ICU is a different kettle of fish. ICU comes to us as bundles
> really don't do anything at all to it. For simplicity I think
> decided to explode the ICU budnle into CVS projects and then
> reassemble but that is goofy. All we really need to do is figure
> how to stash the original ICU bundles in a safe spot and then
> materialize them on the appropriate download page.
> In any event, ICU (and SSH) issues likely have to be taken up with
> original projects.
> Hope that helps
> orbit-dev mailing list
orbit-dev mailing list
orbit-dev mailing list