New and Noteworthy
WOLips project properties are split into two sections -- Development and Deployment.
Development settings look about the same with the exception of a new text field "Framework Folder". In this field, you can specify the name of a folder within your project that contains project-local Frameworks (essentially it's like having a Library/Frameworks inside your WOLips project). This is likely a rare setup, but the option is there if you need it. Setting this isn't particularly smooth at the moment -- you probably need to close and reopen your project to have it pickup that change for now.
Deployment settings has several new additions. For one, checking Servlet deployment now automatically adds the JavaWOJSPWhateverItsCalled.framework to your project, so you don't have to do any second steps. For JavaClient people, there is now a checkbox to specify that you are building JavaClient (and then optionally JavaWebStart). The build files for these are based on the ones from the Wiki, and I don't do JavaClient, so those files will probably go through revisions.
Embedding can now be controlled from the panel. You can check which sets of frameworks get embedded in your deployment (incidentally, checking Servlet presumes embedding, so these are disabled).
And now the big one ... Classpath management is completely reworked. If you use jar frameworks or maven, this doesn't really impact you at all (you just ... do ... whatever it is you do, I guess). However, if you use bundle frameworks (i.e. the traditional .framework folders), then this affects you:
* Previously you had to add references to .framework bundles in the WO frameworks section.
* If you wanted to link to the source projects, you would link them also but had to move them above the WO frameworks.
* Framework ordering was not preserved when generating the deployment classpath file (it alphabetized)
* Framework ordering between eclipse runtime and deployment was different.
* If a team member was missing a framework file, the dependency was removed upon checkout, which would break deployment when s/he committed again.
* woproject/ant.* files are generated on each developer's machine, which can be different for everyone and different than deployment.
The new system addresses all of these. Some power and flexibility is removed, but in exchange for much greater ease-of-use.
* Frameworks now behave like normal Libraries in Eclipse:
* The system tracks where a framework is located dynamically. If you open a framework project, all projects that reference the framework are dynamically rebound to the project. If you close the project, all referencing projects are rebound to the /Library/Frameworks (or the next lower in the precedence) version:
* Frameworks are independent Libraries in the build path, so you can reorder them independently. This is only SOOOORT of true, however, because both the ant build and the runtime system need to reorder your build path to make sure that launching proceeds correctly (for instance, Apple System frameworks will always be ordered below Library Frameworks at launch and deployment, but ordering of Library Frameworks will be preserved).
* The code for computing the build path order is shared between Eclipse and the Ant tasks, so the ordering is consistent.
* The ant tasks now parse eclipse .classpath files to determine build path order (and the format of this file is easy enough that you could generate this from other IDE's or build systems), so there is a single project artifact for specifying this in both places.
* On a related note, resource and wsr patternsets are now properly shared between the ant build files and Eclipse, and should evaluate in the same way.
* woproject/ant.* files are gone. Dead and gone. Forever. No more conflicts. No more missing frameworks. No more NullPointerException from UpdateClasspathIncludeFiles (that is also gone).
* If a framework is missing, the classpath is preserved, but the build path will just be broken. Missing framework does not equal framework removal from the project files.
* ~/Library/wobuild.properties is now cleansed of weird duplicate data and lives in (by default) ~/Library/Application Support/WOLips/wolips.properties along with all the other WOLips artifacts. The file will be autogenerated for Windows and OS X with the correct default values and should just work out of the box.
* Project build.properties can override wolips.properties settings now. There is no UI for this yet, but you can manually override the wo system root, wo local root, on a per-project basis, which allows you to build some projects against WO 5.4, and some against 5.3 (for instance). This probably also requires a close-and-reopen, but at least it's possible now. I haven't tested this with the ant builds yet, so I'm not positive the precedence of those two files is correct, but it should be close.
Conversion
Within Eclipse, the first time your project opens in the new system, your .classpath will be autoconverted to the new format. woproject/ant.* files are not deleted automatically, but they are no longer used and are safe to delete.
For the build system, the easiest route is probably to generate a new Wonder App (or WO App, or framework, or whatever) and copy the generated build.xml into your projects to try out. For projects using the Fluffy Bunny Layout (with correct FBL woproject patternsets -- copy these from a new project if you don't know for sure), this should "just work" (assuming you don't do anything out of the ordinary).
One nice side effect of this is that if you don't deploy from your Eclipse machine (meaning, you have a build server), you don't need any WO frameworks installed in /Library/Frameworks -- You can JUST have project frameworks and things will work. So if you are checking out Wonder, you no longer have to remember to have the /Lib/Fram versions relatively up-to-date, too.
Note that ant building does NOT cross project boundaries. To do a deployment (ant) build, you will still need frameworks built into the folders specified in your wolips.properties (or build.properties). This is a nasty problem and very hard to solve in the general case, but we might address this later.
I would expect this to go to nightly sometime this weekend. This is to be considered UNSTABLE. I have been building against it and using it for about a week, but this is a LOT of new code that touches a LOT of both the wolips runtime as well as the ant build system. It will have problems, and I can almost assure you that if you have some sort of crazy custom build.xml that you'll run into them. Going forward, you will be rewarded for drinking our kool aid. If you buy into things like the standard project layouts and build files, you life will go smoothly. If you don't, your life will go less smoothly.
That is all :)
