On 19 Apr 2026, at 19:29, Aaron Rosenzweig <webobjects-dev@wocommunity.org> wrote:
Claude says: Smoking gun in the full debug output. Line 567 says it outright: Property "wo.local.root.bundles" has not been set
Yes, but No!
Defined wo.local.root.bundles according to the suggestion at the bottom of Claude’s text and ran the build again. Makes no difference in the result but now the wocompile classpath somehow includes these bundles in a weird way and some entries in the class path point into ~/Roots for the standard WO frameworks but the standard WebObjects files are not there. Of course not because they only live in wo.system.root. But the generated class path says differently!
Ok, went back to Eclipse and debugged the build.xml there. Output in the console looks good, not too much weird stuff but there is a lot going on in the background that does not make it into the console. No big help then.
Next try: Build the applications from WonderSource (BugTracker, and others) with -debug set. At the end things are so convoluted, ant tasks calling other ant tasks and properties being assigned recursively. More or less impossible to follow. Oh, and tell Claude that the smoking gun is just a piece of rusty old steel. The property wo.local.root.bundles either does not show up at all or sometimes is also mentioned to be unset for standard WonderSource build (like with ant frameworks, or ant applications)
This ant stuff is an incredible mess with millions of similarly named properties (wo.local.root, wo.wolocalroot, etc) and properties defined by referencing other properties.
Next tries will probably be an even more desperate thing: duplicate the whole WonderSource tree, then removing the wonder frameworks and apps and adding my stuff instead. Will have to edit the main build file ./Build/build/build.xml. We’ll see.
I’ve written a lot of convoluted stuff myself but this beats me hands down.
I will have to experiment further. Anyway the issue is still wide open: if anyone has any way to ant build your own frameworks and projects please help me. ---markus---
And the very next line shows the consequence — the FrameworkSet that's supposed to pick up Wonder frameworks ends up with a literal unresolved pattern: FrameworkSet: Setup scanner in dir /Users/Shared/Developer/Libraries/Wonder/wo.local.root with patternSet{ includes: [${wo.local.root.bundles}.framework] excludes: [] }
That pattern matches nothing, so zero Wonder frameworks make it onto the classpath. If you look back at the -classpath argument markus pasted, you can confirm it: every entry is under wo.system.root/Library/Frameworks (the Apple-provided stuff — JavaFoundation, JavaEOAccess, JavaEOControl, JavaWebObjects, JavaJDBCAdaptor, JavaXML, JavaWebServicesSupport, JavaWOJSPServlet). Not a single jar from wo.local.root/Library/Frameworks, which is where ERExtensions.framework and the rest of Wonder live. So naturally er.extensions.appserver.ERXApplication can't be resolved — javac is never told it exists. The reason the property isn't set is visible earlier in the log. At line 189 the build loads /Users/ruggiero/workspace/ImmoData/build.properties and from lines 190–206 you can see every property it contributes — principalClass, project.base, embed.Local, embed.System, project.name.lowercase, etc. But no framework list. The project's build.properties never declares which Wonder frameworks the app depends on. wo.system.root.bundles gets a default from Wonder's default.properties (the eight Apple frameworks, hardcoded), but wo.local.root.bundles has no default by design — it varies per project — so if the project doesn't supply it, you get nothing. Note also line 564 — wo.external.root.bundles is likewise unset. If ImmoData pulls anything from /Users/ruggiero/Roots (markus's wo.external.frameworks), that'll silently drop off the classpath too. The fix: add the Wonder framework list to the project's build.properties (slash-separated, no .framework suffix), e.g. wo.local.root.bundles=ERExtensions/ERJars/ERPrototypes/Ajax/WOOgnl/ERCayenne — substituting whatever frameworks ImmoData actually needs. The authoritative list is already in the project's Eclipse .classpath file (WOLips drives its in-IDE builds from that); markus can just transcribe the framework names from there. And if the app references any frameworks living under /Users/ruggiero/Roots, set wo.external.root.bundles the same way. For a one-off test before editing files, he can also just pass it on the command line: -Dwo.local.root.bundles=ERExtensions/ERJars/ERPrototypes/Ajax/... If the compile still complains about missing packages after that, it'll be obvious which framework is missing from the list — the error message will name the offending package and he can add the matching framework name. One extra tip for the scripting work: since he's automating 40+ apps, it might be worth writing a small script that reads each project's .classpath and emits the corresponding wo.local.root.bundles=... line, so the two sources of truth stay in sync rather than drifting.
Hi Peer,
Hi Markus,
I also use an ant build outside of Eclipse. I could imagine that a missing reference to
~/Library/Application Support/WOLips/wolips.properties
this exists and is properly found and read. You can see this clearly from the full log (which I attached to my original message). might be the problem. However, I’m building against installed Wonder frameworks, not against the Wonder source code… What do you think?
I am also not building agains “the source”. I used the wonder source to build and install the binaries into the paths ...wo.local.root... and ...wo.system.root.. ( I named the locations accordingly). When I check the classpath generated I can pick any arbitrary framework reference and confirm it exists at that path. Some of the frameworks have attached sources and these are in the same location as the binaries. That is why they end up on the classpath. However this should not matter as the classpath is just a list of jars that are searched for a class. If a class is found in one of the files, good, if not the search continues until the class is found or the classpath is exhausted. This is exactly what confuses me. The classpath seems ok so the classes should be found.
Would you mind sharing your build command/script? I must miss something but clearly cannot see it.
Thank you ---markus---
Regards, Peer
No one doing command line builds with ant? Or has ever done so? I cannot change my environment and go to maven with 50+ projects and absolutely no experience yet. So if anyone has any idea what’s wrong here.....
I know I am outdated and old-fashioned and not modern but I still have ant based projects. Until now I have built frameworks and applications with the WOLips ant tools. Works perfect. But now I have a project that uses some 40+ frameworks and in total consists of well over 40 WOapps. Building all those by hand .... well, you guess --> automation is the key. So I started looking into command line build that can be scripted. Here is one of the apps I build with the help of generic.xml ant build file. The wocompile phase fails because it cannot find the WO and Wonder frameworks. But they are there, in the regular place and so far all paths seem to be correct (java class path). I must miss something but fail to see it. Anyone having better eyes than me? Directly included here is just the failing part. I have attached a ZIP file containing the full output for reference (hope the attachment makes it through)
Thanks for helping me ---markus---
$ ant -debug -emacs -f /Users/Shared/Developer/SourceDistributions/WonderSource/Build/build/generic.xml \ -Dproject.type=application \ -Dproject.name=ImmoData \ -Dproject.principal.class=ch.kastl.immodata.Application \ -Dproject.dir=/Users/ruggiero/workspace/ImmoData \ -Dwo.local.root.bundles.embed=true \ -Dwo.system.root.bundles.embed=true \ generic.build
. . . . [snip tons of output, all looking perfectly ok] . . . .
Compilation arguments: '-d' '/Users/ruggiero/Roots/classes/ImmoData' '-classpath' '/Users/ruggiero/Roots/classes/ImmoData:/Users/ruggiero/workspace/ImmoData/Libraries/fop.jar:/Users/ruggiero/workspace/ImmoData/Libraries/mysql-connector-java-5.1.46-bin.jar:/Users/Shared/Developer/Libraries/Wonder/wo.system.root/Library/Frameworks/JavaEOAccess.framework/Resources/Java/javaeoaccess.jar.src.zip:/Users/Shared/Developer/Libraries/Wonder/wo.system.root/Library/Frameworks/JavaEOAccess.framework/Resources/Java/javaeoaccess.jar:/Users/Shared/Developer/Libraries/Wonder/wo.system.root/Library/Frameworks/JavaEOControl.framework/Resources/Java/javaeocontrol.jar:/Users/Shared/Developer/Libraries/Wonder/wo.system.root/Library/Frameworks/JavaEOControl.framework/Resources/Java/javaeocontrol.jar.src.zip:/Users/Shared/Developer/Libraries/Wonder/wo.system.root/Library/Frameworks/JavaFoundation.framework/Resources/Java/javafoundation.jar.src.zip:/Users/Shared/Developer/Libraries/Wonder/wo.system.root/Library/Frameworks/JavaFoundation.framework/Resources/Java/javafoundation.jar:/Users/Shared/Developer/Libraries/Wonder/wo.system.root/Library/Frameworks/JavaJDBCAdaptor.framework/Resources/Java/javajdbcadaptor.jar.src.zip:/Users/Shared/Developer/Libraries/Wonder/wo.system.root/Library/Frameworks/JavaJDBCAdaptor.framework/Resources/Java/javajdbcadaptor.jar:/Users/Shared/Developer/Libraries/Wonder/wo.system.root/Library/Frameworks/JavaWOJSPServlet.framework/Resources/Java/javawojspservlet.jar.src.zip:/Users/Shared/Developer/Libraries/Wonder/wo.system.root/Library/Frameworks/JavaWOJSPServlet.framework/Resources/Java/javawojspservlet.jar:/Users/Shared/Developer/Libraries/Wonder/wo.system.root/Library/Frameworks/JavaWebObjects.framework/Resources/Java/javawebobjects.jar.src.zip:/Users/Shared/Developer/Libraries/Wonder/wo.system.root/Library/Frameworks/JavaWebObjects.framework/Resources/Java/javawebobjects.jar:/Users/Shared/Developer/Libraries/Wonder/wo.system.root/Library/Frameworks/JavaWebServicesSupport.framework/Resources/Java/javawebservicessupport.jar.src.zip:/Users/Shared/Developer/Libraries/Wonder/wo.system.root/Library/Frameworks/JavaWebServicesSupport.framework/Resources/Java/javawebservicessupport.jar:/Users/Shared/Developer/Libraries/Wonder/wo.system.root/Library/Frameworks/JavaXML.framework/Resources/Java/javaxml.jar:/Users/Shared/Developer/Libraries/Wonder/wo.system.root/Library/Frameworks/JavaXML.framework/Resources/Java/javaxml.jar.src.zip' '-sourcepath' '/Users/ruggiero/workspace/ImmoData/Sources' '-target' '1.8' '-encoding' 'utf-8' '-g' '-source' '1.8'
The ' characters around the executable and arguments are not part of the command. Files to be compiled: ......[snip]...... warning: [options] bootstrap class path not set in conjunction with -source 8 /Users/ruggiero/workspace/ImmoData/Sources/ch/kastl/immodata/Application.java:14: error: package er.extensions.appserver does not exist import er.extensions.appserver.ERXApplication; ^
Markus Ruggiero
4051 Basel / Switzerland mobile +41 79 508 4701
Markus Ruggiero
4051 Basel / Switzerland mobile +41 79 508 4701
Markus Ruggiero
4051 Basel / Switzerland mobile +41 79 508 4701
Markus Ruggiero
rucotec GmbH web https://rucotec.ch Leonhardsberg 1 email markus.ruggiero@rucotec.ch 4051 Basel / Switzerland mobile +41 79 508 4701
|