Just Launched: You can now import projects and releases from Google Code onto SourceForge
We are excited to release new functionality to enable a 1-click import from Google Code onto the Allura platform on SourceForge. You can import tickets, wikis, source, releases, and more with a few simple steps. Read More
From: David Avendasora <webobjects@av...> - 2009-04-29 14:10:32
I'm trying to work out the best way to allow WO Java Client
applications to use parts of Wonder with no changes to Wonder, other
than adding some additional build products that should _not_ interfere
with non-JC projects.
Basically, The client-side of a WebStart deployed JC project looks for
it's classes and Libraries in the /WebServerResources/Java directory
for the application and in /MyFramework.framework/WebServerResources/
Java for any frameworks on the classpath.
If you look at the Apple WebObjects frameworks you will see this
arrangement. The default build.xml file for new WO Frameworks and
Applications in WOLips has already been modified to create this .jar
file for any project where javaclient=true has been set in the
build.properties file. Yea progress!
The problem is that none of the Wonder frameworks do this. In most
cases that's fine as many of the Wonder frameworks are either server-
specific, or they mix EOAccess calls in without regards to MVC
separation (why should ERXStringUtilities need access to the DB?) and
that's not going to be fixed/changed anytime soon. However, there are
a few frameworks that can be used on the client, WOJavaRebel for
I would like it if the Wonder build files could be modified to handle
client-side jars the same way that the standard WO Framework and
Application build.xml files have been modified. It keeps server-
specific classes from being put in the client-side jar and client-
specific classes from being put in the server-side jar. The build.xml
file checks the build.properties file for javaClient=true, if present,
it builds the /WebServerResources/Java/ProjectName.jar file.
Since there aren't any client-specific classes in Wonder the server-
side jar would be the same as it is now. For the client-side .jar we'd
simply be adding all classes. In the future we could try to repackage
classes that are server-specific, client-specific or common so the
client-side jar would only contain the things that were functional on
the client, but we don't have to do that to start with since we'd only
turn it on for Frameworks that are actually useful to the client-side.
What does everyone think? This shouldn't be difficult and it shouldn't
impact web-applications at all.