determining the defined/exported packages

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

determining the defined/exported packages

Holger
Hey guys,

I found some interesting ant tasks in the OSGI implementation
Knopflerfish 2.0, see http://www.knopflerfish.org/.

In particular, the BundleInfoTask is able to analyse a fileset of
java sources or java classes to produce a comma separated list
of defined/exported packages:
http://www.knopflerfish.org/releases/2.0.0/javadoc/org/knopflerfish/ant/taskdefs/bundle/BundleInfoTask.html

So after building a jar with the ant task definitions and putting it
into my antlib directory I was able to do a test like this in our buildfile:

<taskdef name="bundleinfo" classname = "org.knopflerfish.ant.taskdefs.bundle.BundleInfoTask"/>

<target name="packageinfo" depends="compileall">
        <bundleinfo exports="packagelist">
            <fileset dir="${basedir}">
                <include name="**/source/**/*.java"/>
                <exclude name="**/com/publicobject/**/*.java"/>
                <exclude name="**/impl/**/*.java"/>  
           </fileset>
        </bundleinfo>
        <echo message="${packagelist}"/>
</target>

As a result, the packagelist property contains a comma separated list of all
'public' package names that could be used for the Export-Package manifest entry.
If we want to export all packages, we could just remove the last exclude in the fileset.

If we go this way, perhaps we can dynamically download the jar with the ant tasks
just like the javanettasks.jar.
But the Knopflerfish ant tasks have a dependency on BCEL, so I don't know yet, if
this would work.

What do you think?

Holger

_______________________________________________________________________
Viren-Scan für Ihren PC! Jetzt für jeden. Sofort, online und kostenlos.
Gleich testen! http://www.pc-sicherheit.web.de/freescan/?mc=022222

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: determining the defined/exported packages

Bruce Alspaugh-2
Hi all,

As if constructing the package list for the manifest file wasn't
complicated enough already, I think the convention is to include all the
packages and then tag the packages that are internal using the
x-internal directive.  See:

http://help.eclipse.org/help32/index.jsp?topic=/org.eclipse.platform.doc.isv/reference/misc/bundle_manifest.html

The OSGI resolver mode can be set to "strict" to enforce the access
restrictions at runtime.  The default mode is not strict.  I have a
question posted on the Eclipse newsgroup to see if this convention
applies to non Eclipse SDK plug-ins.

Eclipse itself separates classes into two categories:  public API and
"for internal use only."  Any classes located in a package that has
"internal" in its name (e.g. org.eclipse.core.internal.boot) are
internal to the plug-in, should not be referenced by any code outside
the plug-in itself, and may change drastically between different
versions of Eclipse.  A simple text search for "internal" detects
suspicious references in source files.  A developer can still reference
those classes provided they are not tagged x-internal with the resolver
mode set to strict, but they do so at their own risk.  I gather your
"impl" packages are analogous to Eclipse's "internal" packages.

http://help.eclipse.org/help32/index.jsp?topic=/org.eclipse.platform.doc.isv/reference/misc/naming.html

Bruce

Holger Brands wrote:

> Hey guys,
>
> I found some interesting ant tasks in the OSGI implementation
> Knopflerfish 2.0, see http://www.knopflerfish.org/.
>
> In particular, the BundleInfoTask is able to analyse a fileset of
> java sources or java classes to produce a comma separated list
> of defined/exported packages:
> http://www.knopflerfish.org/releases/2.0.0/javadoc/org/knopflerfish/ant/taskdefs/bundle/BundleInfoTask.html
>
> So after building a jar with the ant task definitions and putting it
> into my antlib directory I was able to do a test like this in our buildfile:
>
> <taskdef name="bundleinfo" classname = "org.knopflerfish.ant.taskdefs.bundle.BundleInfoTask"/>
>
> <target name="packageinfo" depends="compileall">
> <bundleinfo exports="packagelist">
>    <fileset dir="${basedir}">
> <include name="**/source/**/*.java"/>
> <exclude name="**/com/publicobject/**/*.java"/>
> <exclude name="**/impl/**/*.java"/>  
>   </fileset>
> </bundleinfo>
> <echo message="${packagelist}"/>
> </target>
>
> As a result, the packagelist property contains a comma separated list of all
> 'public' package names that could be used for the Export-Package manifest entry.
> If we want to export all packages, we could just remove the last exclude in the fileset.
>
> If we go this way, perhaps we can dynamically download the jar with the ant tasks
> just like the javanettasks.jar.
> But the Knopflerfish ant tasks have a dependency on BCEL, so I don't know yet, if
> this would work.
>
> What do you think?
>
> Holger
>
> _______________________________________________________________________
> Viren-Scan für Ihren PC! Jetzt für jeden. Sofort, online und kostenlos.
> Gleich testen! http://www.pc-sicherheit.web.de/freescan/?mc=022222
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
>  

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]