db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bryan Pendleton (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-4120) derbyclient.jar is not a complete OSGi bundle
Date Fri, 23 Oct 2009 20:51:59 GMT

     [ https://issues.apache.org/jira/browse/DERBY-4120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Bryan Pendleton updated DERBY-4120:
-----------------------------------

    Attachment: addToManifest.diff

Here's a simple diff to the master build.xml file which causes the Manifest.mf
for derbyclient.jar to have the following additional lines:

Bundle-SymbolicName: derbyclient
DynamicImport-Package: *
Export-Package: org.apache.derby.jdbc

Regression tests with this modified derbyclient.jar file were clean.

I see that we already had

Bundle-Vendor: Apache Software Foundation
Bundle-Name: Apache Derby 10.6
Bundle-Version: 10.6.0000000.828905M

Do we need to set 

Bundle-ManifestVersion:2

I'm not sure what Bundle-ManifestVersion does, but I see it referenced here:
http://publib.boulder.ibm.com/infocenter/forms/v3r0m0/index.jsp?topic=/com.ibm.help.forms.doc/forms_services_platform/fsp_t_creating_manifest_file.html

According to this, if we don't set Bundle-ManifestVersion to 2, we may be 
recognized as a legacy bundle:
http://markmail.org/message/lnfjsdgpoh2qj3li

I'm also still uncertain about which packages we ought to list in the
Export-Package line. In my own experience, I don't ever need to
refer to any other classes from derbyclient.jar other than the packages
in org.apache.derby.jdbc. In fact, for my applications I only use
org.apache.derby.jdbc.ClientDriver directly, so that would be sufficient for me.

To get some other examples, I tried grepping around in the .java files in the
java/testing subdirectory of the trunk, to see if any of our existing regression
test programs access other packages from derbyclient. There were only a handful
of hits, and from what I can tell these occur in code which would NOT be
written by typical client applications.

So I'm tempted to leave the Export-Package line very short for now, and
only add to it if we come across cases where an application needs to access
one of these classes.

-bash-2.05b$ find . -name '*.java' -exec grep org.apache.derby.client {} \; -print
import org.apache.derby.client.ClientXid;
./jdbcapi/XATransactionTest.java
        if (c instanceof org.apache.derby.client.am.Connection) {
                    ((org.apache.derby.client.am.Connection) c).
./jdbcapi/CacheSessionDataTest.java
        // org.apache.derby.client.net.EbcdicCcsidManager
./jdbcapi/AuthenticationTest.java
                        || s.startsWith("org.apache.derby.client"))
./jdbcapi/ParameterMappingTest.java
import org.apache.derby.client.am.ByteArrayCombinerStream;
./derbynet/ByteArrayCombinerStreamTest.java
import org.apache.derby.client.am.SqlException;
import org.apache.derby.client.am.ClientMessageId;
./derbynet/SqlExceptionTest.java



> derbyclient.jar is not a complete OSGi bundle
> ---------------------------------------------
>
>                 Key: DERBY-4120
>                 URL: https://issues.apache.org/jira/browse/DERBY-4120
>             Project: Derby
>          Issue Type: Bug
>          Components: Eclipse Plug-in, Services
>    Affects Versions: 10.4.2.0
>         Environment: OSGi
>            Reporter: JJ Snyder
>            Assignee: Bryan Pendleton
>         Attachments: addToManifest.diff
>
>
> The manifest in derbyclient.jar is incomplete for usage in OSGi.  There are no packages
exported.  This appears to only be a problem in standalone equinox (outside of eclipse). 
Note that I did not try other OSGi containers.
> The fix is relatively simple.  Adding the Export-Package manifest header should take
care of the problem.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message