Glad it worked for you :). Not so great about differentiating between Fluffy Bunny and NSMavenProjectBundle in general though… Still pondering that.
https://github.com/wocommunity/wonder/issues/1030 - hugi > On 10 Nov 2025, at 18:27, Ricardo Parada <[email protected]> wrote: > > 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 >>>>>>>>>> >>>>>>> >>>>>> >>>> >>
