Bug 50064 - bundle-ify the taglibs jars
Summary: bundle-ify the taglibs jars
Status: RESOLVED FIXED
Alias: None
Product: Taglibs
Classification: Unclassified
Component: Standard Taglib (show other bugs)
Version: 1.2.0
Hardware: PC Windows XP
: P2 normal (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
URL:
Keywords:
Depends on: 50414 50462
Blocks:
  Show dependency tree
 
Reported: 2010-10-09 03:16 UTC by Rex Wang
Modified: 2010-12-31 18:33 UTC (History)
0 users



Attachments
A patch for approach #2 (3.80 KB, application/octet-stream)
2010-10-09 03:20 UTC, Rex Wang
Details
the patch for impl and spec (2.33 KB, patch)
2010-10-26 02:03 UTC, Rex Wang
Details | Diff
the patch for parent pom (829 bytes, patch)
2010-10-26 02:04 UTC, Rex Wang
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Rex Wang 2010-10-09 03:16:25 UTC
Hi Devs,

Hope tomcat community can consider bundle-ify the jars so that they can be used in OSGi framework. Currently, we have to make the bundles by ourselves. There are two approaches to achieve this.
One is bundle-ify the "spec" and "impl" jars directly. 
The other one is make a separate mvn project to do this job and bind the two jar together as a bundle. As shown in the patch.

Any comments about this idea?

-Rex
Comment 1 Rex Wang 2010-10-09 03:20:20 UTC
Created attachment 26145 [details]
A patch for approach #2
Comment 2 Jeremy Boynes 2010-10-16 14:51:08 UTC
Should we add the meta-data to all jars anyway (option 1)? Could you provide a patch to the POMs to run the OSGi plugins?

If we produce a bundle of spec and impl, would it just expose the spec API and keep the impl internal? Would this work with a standalone JSP container where the JSTL library would be in the webapp rather than the container classpath?
Comment 3 Rex Wang 2010-10-26 02:02:05 UTC

(In reply to comment #2)
> Should we add the meta-data to all jars anyway (option 1)? Could you provide a
> patch to the POMs to run the OSGi plugins?

Hi Jeremy,
Sure, the attachment are the 2 patches for option #1.
One for impl and spec;
One for parent.

> 
> If we produce a bundle of spec and impl, would it just expose the spec API and
> keep the impl internal? Would this work with a standalone JSP container where
> the JSTL library would be in the webapp rather than the container classpath?

I not sure I understand the situation. A OSGi bundle is a normal jar with some special metadatas in MANIFEST.MF, so I think the EXPORT header won't take any effect when the bundle is put in normal Java class path. It will just be considered as a normal jar.


thanks
-Rex
Comment 4 Rex Wang 2010-10-26 02:03:44 UTC
Created attachment 26211 [details]
the patch for impl and spec
Comment 5 Rex Wang 2010-10-26 02:04:30 UTC
Created attachment 26212 [details]
the patch for parent pom
Comment 6 Rex Wang 2010-10-26 02:08:12 UTC
Hi Jeremy,

If you decide apply the patches. Could you please deploy the build artifacts to Apache snapshot site after that? Then we can run the TCK to test the jstl bundles in the Geronimo community.

regards,

-Rex
Comment 7 Jeremy Boynes 2010-10-31 14:26:45 UTC
Patches applied, thanks.
Comment 8 Jeremy Boynes 2010-11-13 12:12:24 UTC
I'm seeing the following warning for the compat and jstlel modules:

[WARNING] Warning building bundle org.apache.taglibs:taglibs-standard-compat:bundle:1.2-SNAPSHOT : Did not find matching referal for org.apache.x*

Do we need to add something to their configuration?
Comment 9 Rex Wang 2010-11-14 22:21:51 UTC
(In reply to comment #8)
> I'm seeing the following warning for the compat and jstlel modules:
> 
> [WARNING] Warning building bundle
> org.apache.taglibs:taglibs-standard-compat:bundle:1.2-SNAPSHOT : Did not find
> matching referal for org.apache.x*
> 
> Do we need to add something to their configuration?

I think that because the jstlel and compat don't need the dependency:
    <dependency>
      <groupId>xalan</groupId>
      <artifactId>xalan</artifactId>
      <version>2.7.1</version>
      <scope>provided</scope>
    </dependency>

you can remove it and also the
    <Import-Package>org.apache.x*;resolution:=optional,*</Import-Package>
in maven-bundle-plugin instructions.

-Rex
Comment 10 Rex Wang 2010-12-21 21:43:05 UTC
hi 

should we also remove the dependency in jstlel and compat?
    <dependency>
      <groupId>xalan</groupId>
      <artifactId>xalan</artifactId>
      <version>2.7.1</version>
      <scope>provided</scope>
    </dependency>


I did not find any class import the packages from xalan in these two projects.

-Rex
Comment 11 Jeremy Boynes 2010-12-31 18:33:39 UTC
Resolving now #50462 has been fixed.