Hi Hugi,
What you propose seems reasonable to me. :-) That would require changing ERFoundation for which there is no source right? only ERFoundation.jar. Thanks > On Nov 11, 2025, at 2:39 AM, Hugi Thordarson <[email protected]> wrote: > > 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
