Ben Konrath wrote on 01/17/2007 03:34:53 PM:
> Once Eclipse projects start using bundles provided by Orbit, we will
> longer be able to symlink to the jars installed on the system. One
> possible solution is to build the Orbit bundle along with our regular
> build and create a sub-package that is exclusively used by our eclispe
> packages. For example, if we needed to use an orbit provided tomcat
> bundle, we would do a regular build of tomcat with the sources provided
> by apache and then use a tool to make the tomcat bundle, putting this
> bundle in a separate package. Our eclipse build and package would
> require this tomcat eclipse package. Is there a tool to create these
> 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 at manifest generation. We have some different requirements
(e.g., about file injection, hand crafted manifests, ...) that have partially
driven the current approach. The short answer then is no, the topic
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 it and JAR'ing it up. Your build could, for example, check out
the Orbit stuff, build the lib from source, replace the Orbit supplied
compiled classes with your compiled classes and then "build"
the orbit bundle. 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 managed/created.
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 is 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 that
> be addressed with the efforts of this project? Or should I just file
> bug to resolve this problem. My naive solution would be to import
> contributed icu4j plugin sources into cvs and generate the build files
> in the same way that build files are currently generated for the other
> plugins in the SDK.
ICU is a different kettle of fish. ICU comes
to us as bundles so we really don't do anything at all to it. For
simplicity I think we decided to explode the ICU budnle into CVS projects
and then reassemble but that is goofy. All we really need to do is
figure out 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 the original projects.