Re: [orbit-dev] Contributed Jakarta ORO and Commons Net

[Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>]

Martin Oberhuber wrote on 12/21/2006 10:24:33 AM:
> I just contributed the following bundles to Orbit,
> and updated the corresponding Wiki pages:
>   org.apache.oro
>   org.apache.commons.net

Not sure if you got any comments on this.  I
realised that there is not alot of info on the Orbit site dealing with
some of these issues so I added a section
        http://wiki.eclipse.org/index.php/Adding_Bundles_To_Orbit#Project_setup
Check it out and see if the details make sense.

> I'd appreciate if a bundle expert from the Orbit
> community could have a look at how we've done the
> bundling and if there are perhaps bettwer ways of
> doing things. I'd especially like to know
> 
> - Does it make sense to disable the JDT builder
>   on the .project file since there is nothing to build?

Personally I don't think it matters.  The builder
won't do anything either way.

> - Does it make sense to explicitly specify the
>   project reference of commons.net into oro in the
>   .project file?

PDE takes care of all the project reference stuff
when you define a dependence on another bundle or package.  In general
you should NOT mess with the dependency or classpath settings in the Project
properties.

> - Does it make sense to link the Jakarta online Javadoc
>   into the projects (may be a later version!)

Not sure what this means.

> - Note that our bundles currently have the branding files
>   (about.ini, about.mappings, about.properties, eclipse32.png)
>   in them because they serve in the corresponding features 
>   in our repository for the Eclipse About Dialog -- does that
>   make sense?

While branding was not discussed, we did talk (in
some conf call) about how projects would deliver Orbit bundles in general.
 The direction seems to be that Orbit bundles are just added into
features with the other bundles from the project.  That is, there
need no be an Oro feature.  As such, there is no need for the branding
info.  If there was then I might actually make sense for it to be
the library provider's info and that's a whole new dimension of pain...

> - Did I set contributions to binary build and source build
>   correctly in the build.properties file?

Looked reasonable except the src.includes should not
identify the actual binary jars.  Note also that we are trying to
NOT ship nested JARs.  So the setup of your project (at least commons.net)
is incorrect.  It should have the binary JAR exploded at the root
and then include the org/ dir in bin.includes.

Jeff