Q posted details on the generics support in the binding validator -- here's the rest of the changes to wolips since the last post (in roughly chronological order):
Ant 1.7 is required to use woproject.jar now
Updated default build.xml: compile is always called, framework/app name fully depends on build.properties now, added a package target that will tar up the build products, split install is supported out of the box and is on by default
New EOModel Wizard lets you pick the plugin you want to use (it finds all the reachable plugin frameworks) and automatically adds the framework dependency for you.
Fixes for Windows users.
woproject/ant.* files are no longer necessary and have been removed from the default templates.
Lots and lots of enhancements for maven support.
XML formatting now uses our HTML formatter (which is a lot better than the default)
Lots of new ways to override wolips.properties:
1) you can set wolips.properties= in your build.properties (relative path = loads from ~/Library/Application Support/WOLips/whatever, absolute = ... absolute)
2) you can set WOLips Properties File in the global WOLips Build Preferences (to set a workspace default) -- same rules as #1
3) you can override any settings from wolips.properties in your build.properties (this was supported before, but just reminding)
This should make it easier to experiment with different versions of WO on a per-project (or per-workspace) basis. These changes require either project close/reopen or possibly an eclipse restart.
Better support for models in jar-based frameworks
Support for executing SQL on Oracle
Kind of big change for dependencies -- frameworks must be added to the app level. They are no longer automatically cascaded up the dependency tree. This is required if you want to support things like overriding classes in Wonder in your own code, where Wonder itself also overrides classes in core. Without this, you end up cascading up JavaWebObjects too early and you only get one chance at a "first" framework. Unfortunately, to change this is to rewrite the Eclipse classpath system.
Namespaced attributes are now parsed properly in template html (i.e. something:key="value")
Performance enhancements for automatic EOGen generation (duplicate removal in the queue, support for cancel, etc).
Performance enhancements for Entity Modeler (only models that match a resource patternset are loaded, and some big speed improvements on saving).
LLLOOTS of fixes in Entity Modeler.
Upgraded for Eclipse 3.4.1.
Entity Modeler now only rewrites files that contain changes (for instance, changing an entity will only rewrite that single entity plist).
Entity Modeler now tries to preserve EOModeler syntax for connection dictionaries when it can.
Entity Modeler now has an option to now show relationship optionality warnings (if you have huge models and you get a lot of these, it can be annoying)
Entity Modeler now supports the new custom prototypes naming convention from Wonder.
Tag shortcuts default to include all of the shortcuts from 5.4.
Made the templating system is now much more generic to support more than just project templates (for instance, Component templates).
Added support for project-relative component templates.
Support for custom display group subclasses and generics in the display group wizard.
Support for binding validation and completion of generic types.
Blog Archive
Contributors
4 comments:
Yes indeed, a lot of progress by the WOLips team in this last phase. Thanks for the great work. I especially love the new dynamic classpath features.
I have a couple of questions:
Lots of new ways to override wolips.properties:
1) you can set wolips.properties= in your build.properties (relative path = loads from ~/Library/Application Support/WOLips/whatever, absolute = ... absolute)
What does that stuff in parenthesis mean?? :-)
And also, can someone elaborate on the namespaced attributes:
Namespaced attributes are now parsed properly in template html (i.e. something:key="value")
it means you can set the property "wolips.properties=something.properties" in your build.properties to point to a different wolips.properties file to load from. In the example above, it will load ~/Library/App Support/WOLips/something.properties. If you give it a relative path, it will load relative to the WOLips app support folder. If you give it an absolute path, it will load from the absolute path directly. I use this to have WO 5.4 and WO 5.3 projects in the same workspace. In app support, I have wolips.properties.53, wolips.properties.54, wolips.properties.52 (and a few others) and for each project, I just set wolips.properties=wolips.properties.54 for the 5.4 ones, etc.
I need help to open a existing project. I have the code but I know if the project is complete. Help
My email is aseguraa96@gmail.com
Post a Comment