Yes, I see NSStandardProjectBundle which resides in the ERFoundation.jar that was patched is now correctly using the latest nature for maven.
Therefore, now the mavenProject variable gets set to true now. Then in the lines below it uses that to decide whether to create a NSMavenProjectBundle instance otherwise it creates an NSFluffyBunnyProjectBundle instance. So yes, going back to ERFoundation 1.0 now creates fluffy bundle instances and now it works!!! So it appears I’m now running bundleless fluffy bunny successfully!!! Thank you Ricardo Parada > > On Nov 10, 2025, at 12:57 PM, Hugi <[email protected]> wrote: > > Ah, that’s an interesting one. If you’ve upgraded to ERFoundation-1.1, it > will now properly identify your project as a maven project and assume you’re > using the maven project layout (creating an NSMavenProjectBundle). But as you > point out, project layouts and build systems are separate things. > > I’m away from the computer for a couple of hours, but I’ll have to think on > that. In the meantime, I bet if you go back to ERFoundation-1.0, your project > will work. > > - hugi > > >> On 10 Nov 2025, at 17:35, Ricardo Parada <[email protected]> wrote: >> >> Hi Hugi >> >> I added all commits to our fork of Wonder. I turned off the Generate bundles >> option. I made sure the there is no build folder. >> >> When I run with a new plain java launch config I get the same >> NullPointerException. >> >> So I started debugging inside collectMainProps() method and the first line >> gets the mainBundle(). >> >> The main bundle name is correct but the class is NSMavenProjectBundle. I >> believe when it was working the class was specific to fluffy bunny. I >> assumed the bundle class has knowledge of where things are to be found. >> >> So it seems the next couple of lines to read Properties file does not find >> the Properties which should have been found under Resources. Then it enters >> the more complicated search which is where the NullPointerException occurs. >> >> Anyways, if you can think of something that may be causing the app to use >> the maven bundle class as opposed to the fluffy bunny one please let me know. >> >> Thank you >> Ricardo Parada >> >>> >>>> On Nov 10, 2025, at 11:29 AM, Hugi Thordarson <[email protected]> wrote: >>> >>> Hi Ricardo, >>> >>> yeah, all of this has become a little muddled over the years :). >>> >>> -- wolifecycle-maven-plugin -- >>> >>> Doesn't do any work at all during development, it's only there for you to >>> invoke manually to build a product. WO, Wonder and WOLips don't care if >>> it's in your pom or not. >>> >>> -- "woproject" folder -- >>> >>> Used by WOLips and wolifecycle-maven-plugin to locate resources when >>> building. >>> However, if you're in bundleless mode (i.e. "generate bundles" is off) no >>> building of bundles needs to happen during development, since bundle >>> resources are loaded directly from the application project (and any related >>> framework projects in the workspace). >>> So; you don't need a "woproject" folder in bundleless mode since no >>> WO-specific building needs to happen. >>> >>> These are the basics, really quite simple, but Wonder and ERFoundation have >>> muddled the picture by mixing Eclipse's .project file into the picture… >>> >>> -- .project -- >>> >>> ERFoundation still checks Eclipse's ".project" to determine if a project is >>> a maven project. I think that should be changed to just check for a pom.xml >>> file instead. That would eliminate the final reliance of WO/Wonder on the >>> .project file, meaning you're fine in any IDE (without faking a .project >>> file) ( https://github.com/wocommunity/wonder/issues/1030 ). >>> >>> -- More? -- >>> >>> The only remaining issue then is WOLips itself. As you discovered. It's >>> currently "activated" in a project by adding a <nature> to the .project >>> file. I played around last week, changing that to be activated in the >>> presence of a build.properties file containing a "project.name" property >>> instead. Works remarkably well and for instance, that modified WOLips is >>> fully functional in the simple project I created in the YouTube video :). >>> It would be nice if the only "custom" thing needed for a WO project to >>> function was a build.properties file (and of course a "woproject" folder, >>> if you're building with wolifecycle-maven-plugin). But yeah, that needs >>> more work, discussions, and consensus. >>> >>> https://github.com/wocommunity/wolips/issues/198 >>> https://github.com/hugithordarson/wolips/compare/fc75fd5...c796508 >>> >>> Cheers, >>> - hugi >>> >>> >>> >>> >>> >>>>> On 10 Nov 2025, at 15:15, Ricardo Parada <[email protected]> wrote: >>>> >>>> Hi Hugi, good morning. >>>> >>>> I just followed your steps in the video to create the bundleless WOnder >>>> app. >>>> >>>> I also added a Session.java and a Main.wo in src/main/components and a >>>> Main.java. >>>> >>>> It runs and displays the page!! >>>> >>>> I’m still trying to understand what just happened. :-) >>>> >>>> How did it build the application without wolifecycle-maven-plugin? >>>> >>>> I can edit the Main.wo component in WOLips component editor. I was not >>>> able to create it with WOLips though. I added it by hand. >>>> >>>> Also, I noticed that there is no woproject folder. What uses that folder >>>> by the way? >>>> >>>> I’m reviewing your commits in to Wonder 7.5 and I’m trying to incorporate >>>> them into our fork of Wonder and see if I can get bundleless to work with >>>> our application. >>>> >>>> Thank you >>>> Ricardo Parada >>>> >>>> >>>> >>>>> >>>>>> On Nov 9, 2025, at 6:16 AM, Hugi Thordarson <[email protected]> wrote: >>>>> >>>>> Just committed all of the stuff I've been doing to Wonder's main branch, >>>>> less confusing than having all of those separate PRs. >>>>> >>>>> I also deployed ERFoundation-1.1 to maven.wocommunity.org, which fixes >>>>> that check for the project's <nature>. >>>>> >>>>> It's my birthday so I do what I want to :). >>>>> >>>>> Here's a 2 minute video that shows how little "formalities" should now be >>>>> required for WO/Wonder to work, >>>>> we start with an absolutely plain java project, no WOLips, no bundle >>>>> generation or /build folder, just plain WO and Wonder. >>>>> >>>>> https://www.youtube.com/watch?v=iDQcMVRUhyk >>>>> >>>>> Cheers, >>>>> - hugi >>>>> >>>>> >>>>>> On 9 Nov 2025, at 07:40, Hugi Thordarson <[email protected]> wrote: >>>>>> >>>>>> Thanks for trying this out Ricardo. Sorry, one thing I should have >>>>>> mentioned, for bundleless to work (generate bundles off and no build >>>>>> folder), >>>>>> you need to have the old maven nature in the .project file ( >>>>>> <nature>org.maven.ide.eclipse.maven2Nature</nature> ). >>>>>> >>>>>> Fixed in a different PR: >>>>>> https://github.com/wocommunity/wonder/issues/1029 . >>>>>> >>>>>> Cheers, >>>>>> - hugi >>>>>> >>>>>> >>>>>> >>>>>>>> On 9 Nov 2025, at 03:39, Ricardo Parada <[email protected]> wrote: >>>>>>> >>>>>>> Hugi, >>>>>>> >>>>>>> If I turn off the “Generate bundles” in WOLips : Build, and delete the >>>>>>> build folder then I get back the exception when I run the application. >>>>>>> I’m using the java launch configuration. >>>>>>> >>>>>>> It does not matter if I set the Working directory as you suggested with >>>>>>> ${working_dir_loc_WOLips:MyApp} and even if I add >>>>>>> -DNSProjectBundleEnabled=true in the VM arguments. >>>>>>> >>>>>>> However, if I turn the “Generate bundles” option back on and make sure >>>>>>> it generates the build folder by doing clean and build automatically, >>>>>>> set the Working directory to ${working_dir_loc_WOLips:MyApp} then it >>>>>>> works. No need to set -DNSProjectBundleEnabled=true in the VM >>>>>>> arguments. It does not seem to have an effect. >>>>>>> >>>>>>> Then if I remove your ERXApplication changes then the exception comes >>>>>>> back. >>>>>>> >>>>>>> Then I put your changes back and everything works again. >>>>>>> >>>>>>> So your commits definitely fix the problem but I can’t say that >>>>>>> bundleless works. >>>>>>> >>>>>>> Were your commits supposed to make bundleless work? Where bundleless >>>>>>> means no build folder and the Generate bundles option turned off. >>>>>>> >>>>>>> Thank you very much, >>>>>>> Ricardo >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> On Nov 8, 2025, at 9:43 PM, Ricardo Parada <[email protected]> wrote: >>>>>>>> >>>>>>>> I’ll do more testing and then comment on the pull request. >>>>>>>> >>>>>>>> :-) >>>>>>>> >>>>>>>> Thank you >>>>>>>>> >>>>>>>>> On Nov 8, 2025, at 5:58 PM, Hugi Thordarson <[email protected]> wrote: >>>>>>>>> >>>>>>>>> The project layout looks fine at first sight, so I can't think of >>>>>>>>> what's causing your application to fail in WOApplication >>>>>>>>> launch/bundle-mode. >>>>>>>>> >>>>>>>>> But glad to hear that you're up and running! And that the fixes to >>>>>>>>> bundleless development work. I might just count that as a review and >>>>>>>>> merge into main :). >>>>>>>>> >>>>>>>>> - hugi >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> On 8 Nov 2025, at 22:07, Ricardo Parada <[email protected]> wrote: >>>>>>>>>> >>>>>>>>>> I’m gonna summarize here. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Nov 8, 2025, at 3:03 AM, Hugi Thordarson <[email protected]> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> - Does your ".project" file contain >>>>>>>>>>> <nature>org.maven.ide.eclipse.maven2Nature</nature> — and a WOLips >>>>>>>>>>> builder? >>>>>>>>>>> - Does your application project contain a "build" folder on disk? >>>>>>>>>>> (should be getting generated by WOLips). And does it look pretty >>>>>>>>>>> much like an application bundle or do you see something missing? >>>>>>>>>> >>>>>>>>>> Yes, it has a build folder as shown below: >>>>>>>>>> >>>>>>>>>> % ls build >>>>>>>>>> Phynance.woa >>>>>>>>>> % ls build/Phynance.woa >>>>>>>>>> Contents >>>>>>>>>> % ls build/Phynance.woa/Contents >>>>>>>>>> Info.plist Resources WebServerResources >>>>>>>>>> >>>>>>>>>>> - Does woproject/resources.include.patternset properly define your >>>>>>>>>>> resources? (kind of pointless to ask since your build works with >>>>>>>>>>> maven so it should be fine — but can't hurt to ask) >>>>>>>>>> >>>>>>>>>> It is as follows: >>>>>>>>>> >>>>>>>>>> % cat woproject/resources.include.patternset >>>>>>>>>> Components/**/*.wo/**/* >>>>>>>>>> Components/**/*.api >>>>>>>>>> Resources/**/*% >>>>>>>>>> also In my build.properties I have classes.dir=target/classes. It >>>>>>>>>> used to be set to “bin”. Do you think it hay has any effect on this? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Launching as a WOApplication should work if you have "generate >>>>>>>>>>> bundles" enabled. But if you launch as a "java application" (not a >>>>>>>>>>> WOApplication), you will see the error you described unless you: >>>>>>>>>>> 1. Set the working directory for the Debug/Run configuration to >>>>>>>>>>> ${working_dir_loc_WOLips:SW} and >>>>>>>>>>> 2. Pass in the VM argument -DNSProjectBundleEnabled=true >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> This worked for my java launch configuration. And I think that is >>>>>>>>>> what I had when things used to work. When I started from scratch I >>>>>>>>>> recreated the launch configurations from zero and forgot I was using >>>>>>>>>> this. >>>>>>>>>> >>>>>>>>>> In my case I set working directory to: >>>>>>>>>> >>>>>>>>>> ${working_dir_loc_WOLips:MyApp >>>>>>>>>> >>>>>>>>>> This works!!! >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> >>>>>>>>>>> "Generate bundles" does pretty much what it says on the tin. It >>>>>>>>>>> activates the WOLips builder, which generates that "build" folder >>>>>>>>>>> in the root of your project, containing a bundle that WOLips will >>>>>>>>>>> constantly keep "built" as you make changes. Your WO application >>>>>>>>>>> will then locate everything from there. >>>>>>>>>>> >>>>>>>>>>> The nicer alternative is bundleless development, meaning no >>>>>>>>>>> generated build-folder/bundles and resources get located directly >>>>>>>>>>> in the project rather than from the fake bundle in the "build" >>>>>>>>>>> folder. >>>>>>>>>>> >>>>>>>>>>> Bundleles is faster, simpler and better. But there's a bug in >>>>>>>>>>> project Wonder which prevents you from using bundleless with it >>>>>>>>>>> when using maven ( >>>>>>>>>>> https://github.com/wocommunity/wonder/issues/1025 ). >>>>>>>>>>> It's fixed by one of the patches I submitted yesterday, those >>>>>>>>>>> patches exactly being meant to ease life for those migrating to >>>>>>>>>>> maven (everyone hits these problems in the first steps, and I think >>>>>>>>>>> we should really fix those). >>>>>>>>>> >>>>>>>>>> I incorporated those two commits into our fork of Wonder. >>>>>>>>>> >>>>>>>>>> We are using Wonder 7.3 which we converted a while ago to use slf4j >>>>>>>>>> throughout. That was a significant effort. >>>>>>>>>> >>>>>>>>>> And we also upgraded jar files in it that had been flagged by the >>>>>>>>>> security scanning software as having vulnerabilities. >>>>>>>>>> >>>>>>>>>> Anyways, I just added your two commits to that version and it fixes >>>>>>>>>> the problem. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Cheers, >>>>>>>>>>> - hugi >>>>>>>>> >>>>>> >>>>> >>> >
