Happy birthday Hugi 

> 
> 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
>>>>> 
>> 
> 

Reply via email to