Skip to Content
Last modified by Pascal Robert on 2010/09/19 10:26
From version 3.1
edited by Quinton Dolan
on 2007/07/12 21:07
Change comment: There is no comment for this version
To version 6.1
edited by Pascal Robert
on 2007/12/22 20:36
Change comment: There is no comment for this version

Summary

Details

Page properties
Title
... ... @@ -1,1 +1,1 @@
1 -Programming__WebObjects-Web Applications-Development-Third Party Jars
1 +Web Applications-Development-Third Party Jars
Author
... ... @@ -1,1 +1,1 @@
1 -XWiki.qdolan
1 +XWiki.probert
Content
... ... @@ -1,14 +1,45 @@
1 -== Third Party Jars with Xcode ==
1 +== Third Party Jars with Eclipse/WOLips ==
2 2  
3 -=== Problem ===
3 +=== Problem ===
4 4  
5 +You're using Eclipse, and you'd like to use one or more third party JAR files in your project.
6 +
7 +=== Solution ===
8 +
9 +{{warning}}
10 +
11 +First, a word of warning: DO NOT PUT YOUR JARS INTO _/Library/WebObjects/Extensions/_ \!. You're heading for deployment and classpath problems if you do that.
12 +
13 +{{/warning}}
14 +
15 +It's really easy to add third party jars into your WOLips project. Add your third party JARs by dragging the JARs from the Finder to the //Libraries// folder of your Eclipse project.
16 +
17 +Next step: right-click on the JAR in Eclipse and select //Build Path// > //Add To Build Path//. The JAR should now be visible in //Referenced Libraries//.
18 +
19 +This solves the problem of adding JARs for development. For deployment, what do you need to do ? If you put your JARs into the //Libraries// folders, the Ant build system will put the JARs into your .woa (or .framework). If you put your JARs in another folder, you need to modify the //build.xml// file. Locate this part:
20 +
21 +{{code}}
22 +
23 +<lib dir="Libraries">
24 + <include name="*.jar"/>
25 + <exclude name="**/*.woa/**"/>
26 + </lib>
27 +
28 +{{/code}}
29 +
30 +Copy and paste this action and replace //Libraries// with the folder containing your JARs.
31 +
32 +== Third Party Jars with Xcode ==
33 +
34 +=== Problem ===
35 +
5 5  You're using Xcode, and you'd like to use one or more third party JAR files in your project.
6 6  
7 -As of WO 5.2, one reasonable solution would be to just toss all the JAR files that you need into /Library/WebObjects/Extensions/ (see What's New in WebObjects 5.2 in the section on Launch Architecture: http:~/~/developer.apple.com/documentation/WebObjects/WhatsNew5.2/ ). The problem with this solution is that it creates a bit of a management headache. You don't necessarily know which projects are using which JAR files, and you might have trouble if different projects were to need different versions of the same third party JARs.
38 +As of WO 5.2, one reasonable solution would be to just toss all the JAR files that you need into /Library/WebObjects/Extensions/ (see What's New in WebObjects 5.2 in the section on Launch Architecture: [[http://developer.apple.com/documentation/WebObjects/WhatsNew5.2/]] ). The problem with this solution is that it creates a bit of a management headache. You don't necessarily know which projects are using which JAR files, and you might have trouble if different projects were to need different versions of the same third party JARs.
8 8  
9 9  For example, we have a project that uses the Batik SVG Toolkit. We needed classes from many of the jar files that are included with batik-1.5.1. But what happens when another project comes along that needs a different (e.g. a newer) version of Batik? We'd have to either make sure the old project works with the newer batik, or restrict ourselves to the old batik code for the new project.
10 10  
11 -=== Solution ===
42 +=== Solution ===
12 12  
13 13  One solution to this problem is to create a WebObjects framework that contains all the jar files for a particular version of an external project (like Batik). That way, several WO apps can use the same WO framework (e.g. batik-1.5.1.framework), but if a newer batik comes out that we need to use for a new project, and if it turns out to be at all incompatible with the old version, then we can just create another batik WO framework, named for the new version; e.g. something like batik-2.0.framework, if/when a batik-2.0 is released.
14 14  
... ... @@ -20,19 +20,19 @@
20 20  
21 21  (3) Add the desired JAR files to this group. For my batik example, I selected all the .jar files in my batik-1.5.1/lib directory. Check Copy items into destination group's folder (if needed), and select the aggregate target (i.e. the one with the same name as your project).
22 22  
23 -(4) We want to add a new build phase to the aggregate target. Open the Targets group (under Groups & Files) and double-click on the aggregate target. It's essential that this new build phase be added to the aggregate target rather than the Application Server target!
54 +(4) We want to add a new build phase to the aggregate target. Open the Targets group (under Groups & Files) and double-click on the aggregate target. It's essential that this new build phase be added to the aggregate target rather than the Application Server target
24 24  
25 25  (5) We want to add the new build phase at or near the end of the list of Build Phases. So right-click (or control-click) on the last build phase, select New Build Phase, then New Copy Files Build Phase. You can also drag the new build phase to a new position after you create it.
26 26  
27 27  (6) Change the Where: popup for your new build phase to Java Resources.
28 28  
29 -(7) Back in the main project window, select all the JAR files that you added to your new Resources -> Java group, and drag them into the Files: area for your new Copy Files build phase (in the aggregate Target panel).
60 +(7) Back in the main project window, select all the JAR files that you added to your new Resources > Java group, and drag them into the Files: area for your new Copy Files build phase (in the aggregate Target panel).
30 30  
31 31  (8) Build and install your WO framework:
32 32  
33 33  {{code}}
34 34  
35 -xcodebuild install -buildstyle Deployment DSTROOT=/
66 +xcodebuild install -buildstyle Deployment DSTROOT=/
36 36  
37 37  {{/code}}
38 38  
... ... @@ -44,7 +44,6 @@
44 44  
45 45  === Another Solution ===
46 46  
47 -A WebObjects application will automatically load any .jars located in the sub-folder "Contents/Extensions" inside the .woa wrapper. Compared to the Frameworks method, it has the advantages of keeping the .woa completely self-contained and avoiding potential version conflicts if different WebObjects applications need different versions of the .jar file. The downside is that the .jar is not shared between applications, so that if you want to update it you need to update it for each .woa individually, and you can have multiple copies of the .jar taking up disk space. (The latter is usually not a problem these days.)
78 +A WebObjects application will automatically load any .jars located in the sub-folder "Contents/Extensions" inside the .woa wrapper. Compared to the Frameworks method, it has the advantages of keeping the .woa completely self-contained and avoiding potential version conflicts if different WebObjects applications need different versions of the .jar file. The downside is that the .jar is not shared between applications, so that if you want to update it you need to update it for each .woa individually, and you can have multiple copies of the .jar taking up disk space. (The latter is usually not a problem these days.)
48 48  
49 -To automate this as a part of the build process in XCode, add a Copy Files build phase to the top-level target. Set the Destination to "Wrapper" and the Path to "Contents/Extensions".
50 -Category:WebObjects
80 +To automate this as a part of the build process in XCode, add a Copy Files build phase to the top-level target. Set the Destination to "Wrapper" and the Path to "Contents/Extensions".