Jesse you are correct. If you are compiling for one java version but running on another… you can get java.lang.NoClassDefFoundError - that’s because the object you used at compile time might not be available in that other runtime.
While the error is the same, this feels different but your point is a good one and I’ll consider it some more. AARON ROSENZWEIG / Chat 'n Bike <http://www.chatnbike.com/> e: aa...@chatnbike.com <mailto:aa...@chatnbike.com> t: (301) 956-2319 > On Jan 23, 2020, at 4:24 PM, Jesse Tayler <jtay...@oeinc.com> wrote: > > Isn’t that what you get with some java version mismatch ?? > >> On Jan 23, 2020, at 11:41 AM, Aaron Rosenzweig via Webobjects-dev >> <webobjects-dev@lists.apple.com <mailto:webobjects-dev@lists.apple.com>> >> wrote: >> >> I tried this call: >> >> NSBundle MYBUNDLE = NSBundle.mainBundle(); >> >> It fails immediately with: >> java.lang.NoClassDefFoundError: Could not initialize class >> com.webobjects.foundation.NSBundle >> >> I’m suspecting it has to do with the static initializer of NSBundle. >> AARON ROSENZWEIG / Chat 'n Bike <http://www.chatnbike.com/> >> e: aa...@chatnbike.com <mailto:aa...@chatnbike.com> t: (301) 956-2319 >> >> >> >>> On Jan 23, 2020, at 11:23 AM, Aaron Rosenzweig <aa...@chatnbike.com >>> <mailto:aa...@chatnbike.com>> wrote: >>> >>> Riddle me this… how can you get a class not defined error from the class >>> itself? >>> >>> java.lang.NoClassDefFoundError: Could not initialize class >>> com.webobjects.foundation.NSBundle >>> at com.webobjects.foundation.NSBundle.mainBundle(NSBundle.java:526) >>> >>> You are already in NSBundle.mainBundle() and then out pops a >>> NoClassDefFoundError… that must be a red herring but I cannot figure it >>> out. >>> AARON ROSENZWEIG / Chat 'n Bike <http://www.chatnbike.com/> >>> e: aa...@chatnbike.com <mailto:aa...@chatnbike.com> t: (301) 956-2319 >>> >>> >>> >>>> On Jan 23, 2020, at 10:03 AM, Aaron Rosenzweig <aa...@chatnbike.com >>>> <mailto:aa...@chatnbike.com>> wrote: >>>> >>>> Hi Dennis - I hadn’t thought of that - we could have a fast failsafe and >>>> then a slow one run at different times. Thanks! good idea. >>>> AARON ROSENZWEIG / Chat 'n Bike <http://www.chatnbike.com/> >>>> e: aa...@chatnbike.com <mailto:aa...@chatnbike.com> t: (301) 956-2319 >>>> >>>> >>>> >>>>> On Jan 23, 2020, at 9:58 AM, Dennis Scheffer <den...@selbstdenker.ag >>>>> <mailto:den...@selbstdenker.ag>> wrote: >>>>> >>>>> >>>>>> Cloning a “company” EO and testing unique constraints in SQL - is >>>>>> heavier than testing an “isCamelCase()” function but lighter than >>>>>> selenium. Maybe we have to do it in failsafe but it feels closer to >>>>>> regular unit tests that should fire every time there is a checkin to the >>>>>> repo. In other words if your tests take 5 minutes to run, why not let >>>>>> Agnes tell you immediately that the build is broken rather than waiting >>>>>> till midnight for selenium to do so? >>>>> >>>>> If there are multiple ways in which you would like to use the failsafe >>>>> plugin, you can always add multiple executions and put them in their own >>>>> build profiles >>>>> (https://maven.apache.org/guides/introduction/introduction-to-profiles.html >>>>> >>>>> <https://maven.apache.org/guides/introduction/introduction-to-profiles.html>). >>>>> Then you can fire failsafe every time you check in new code without >>>>> selenium and you can do something like this if your want selenium tests >>>>> to be run: 'mvn clean verify -P with-selenium'. There are a bunch of ways >>>>> to configure profiles to do something like that. >>>>> >>>>> -- >>>>> Dennis >>>>> >>>>>> On 23. Jan 2020, at 15:39, Aaron Rosenzweig <aa...@chatnbike.com >>>>>> <mailto:aa...@chatnbike.com>> wrote: >>>>>> >>>>>> Dennis that is a good point, >>>>>> >>>>>> At the moment I have not cleaned and the product is there but it’s not >>>>>> working but your point is still well taken. In Jenkins, in the cloud, it >>>>>> will do a clean and I really should be doing a clean every time so the >>>>>> product won’t be there to test with… there won’t be a bundle. >>>>>> >>>>>> Maven “Failsafe” makes sense for selenium… which is technically a JUnit >>>>>> test too but it’s very heavy and flexes the UI of a bundled and launched >>>>>> app. >>>>>> >>>>>> Cloning a “company” EO and testing unique constraints in SQL - is >>>>>> heavier than testing an “isCamelCase()” function but lighter than >>>>>> selenium. Maybe we have to do it in failsafe but it feels closer to >>>>>> regular unit tests that should fire every time there is a checkin to the >>>>>> repo. In other words if your tests take 5 minutes to run, why not let >>>>>> Agnes tell you immediately that the build is broken rather than waiting >>>>>> till midnight for selenium to do so? >>>>>> >>>>>> http://www.globalnerdy.com/wp-content/uploads/2008/08/you_broke_the_build.jpg >>>>>> >>>>>> <http://www.globalnerdy.com/wp-content/uploads/2008/08/you_broke_the_build.jpg> >>>>>> >>>>>> When we run from within Eclipse we have a “bundless build” that uses the >>>>>> Fluffy Bunny NSBundle variant and works great… without a product… and >>>>>> the destructive EOF unit tests work there. I think what Markus did was >>>>>> patch NSBundle to treat the maven target with the intermediate classes >>>>>> and resources as a “maven bundless build” or a “maven black-ops bunny” >>>>>> if-you-will. >>>>>> >>>>>> I’m still confused but clarity is setting in. Thank you everyone for >>>>>> this hearty discussion. >>>>>> AARON ROSENZWEIG / Chat 'n Bike <http://www.chatnbike.com/> >>>>>> e: aa...@chatnbike.com <mailto:aa...@chatnbike.com> t: (301) 956-2319 >>>>>> >>>>>> >>>>>> >>>>>>> On Jan 23, 2020, at 2:54 AM, Dennis Scheffer <den...@selbstdenker.ag >>>>>>> <mailto:den...@selbstdenker.ag>> wrote: >>>>>>> >>>>>>> Hi everyone, >>>>>>> >>>>>>> >>>>>>>> // That's the main bundle when running tests from Eclipse >>>>>>>> Path mainBundlePath = Paths.get("build/your-project.woa"); >>>>>>>> >>>>>>>> if (Files.notExists(mainBundlePath)) { >>>>>>>> // Maven doesn't create a build directory. The WOA bundle goes into >>>>>>>> the target folder instead. >>>>>>>> mainBundlePath = Paths.get("target/your-project.woa"); >>>>>>>> } >>>>>>>> >>>>>>>> ERXExtensions.initApp("your-project", mainBundlePath.toUri().toURL(), >>>>>>>> ACUnitTestingApplication.class, args); >>>>>>> >>>>>>> This may not work under certain circumstances because the surefire >>>>>>> plugin usually runs in the Maven 'test' phase which is before the >>>>>>> 'package' phase. Therefore, there may not be a bundle at >>>>>>> 'target/your-project.woa' – especially if you do a 'mvn clean test'. >>>>>>> >>>>>>> The solution is very simple: I would consider tests that depend on a >>>>>>> pre-build bundle integration tests (which makes sense because most of >>>>>>> the time all the application's 'units' are integrated in a bundle). And >>>>>>> just use the Maven failsafe pugin >>>>>>> (https://maven.apache.org/surefire/maven-failsafe-plugin/ >>>>>>> <https://maven.apache.org/surefire/maven-failsafe-plugin/>). It works >>>>>>> exactly the same as the surefire plugin but runs in the 'verify' phase >>>>>>> which is after the 'package' phase. So 'mvn clean verify' will clean >>>>>>> your target directory, create a fresh new bundle and run your tests on >>>>>>> your fresh bundle with the solution mentioned above. >>>>>>> >>>>>>> With regards, >>>>>>> -- >>>>>>> Dennis >>>>>>> >>>>>>> >>>>>>>> On 23. Jan 2020, at 02:28, Henrique Prange via Webobjects-dev >>>>>>>> <webobjects-dev@lists.apple.com >>>>>>>> <mailto:webobjects-dev@lists.apple.com>> wrote: >>>>>>>> >>>>>>>> Hey Aaron, >>>>>>>> >>>>>>>> This error rings a bell. I don't recall all the details. It looks like >>>>>>>> the collectMainProps method is trying to find the Properties file of >>>>>>>> your project in the wrong place. >>>>>>>> >>>>>>>> When you build your project in Eclipse with WOLips, it generates a >>>>>>>> build folder containing your project's WOA bundle. Maven, however, >>>>>>>> puts the generated WOA bundle in the target folder. I'm afraid the >>>>>>>> application initialization code keeps looking for the build folder >>>>>>>> when you run your tests with Maven. >>>>>>>> >>>>>>>> I'm not sure if there's a better way to solve this problem. Anyway, >>>>>>>> the code below may fix it. >>>>>>>> >>>>>>>> // That's the main bundle when running tests from Eclipse >>>>>>>> Path mainBundlePath = Paths.get("build/your-project.woa"); >>>>>>>> >>>>>>>> if (Files.notExists(mainBundlePath)) { >>>>>>>> // Maven doesn't create a build directory. The WOA bundle goes into >>>>>>>> the target folder instead. >>>>>>>> mainBundlePath = Paths.get("target/your-project.woa"); >>>>>>>> } >>>>>>>> >>>>>>>> ERXExtensions.initApp("your-project", mainBundlePath.toUri().toURL(), >>>>>>>> ACUnitTestingApplication.class, args); >>>>>>>> >>>>>>>> Cheers, >>>>>>>> >>>>>>>> HP >>>>>>>> >>>>>>>>> On Jan 22, 2020, at 2:09 PM, Aaron Rosenzweig via Webobjects-dev >>>>>>>>> <webobjects-dev@lists.apple.com >>>>>>>>> <mailto:webobjects-dev@lists.apple.com>> wrote: >>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I’m trying to run maven unit tests with the surefire plugin that make >>>>>>>>> use of EOF but it’s not working out. >>>>>>>>> >>>>>>>>> I can run them in Eclipse with a direct launch as a bundless build >>>>>>>>> and it works. I make a call in the static initializer of the test >>>>>>>>> case to: >>>>>>>>> ERXExtensions.initApp(ACUnitTestingApplication.class, arguments); >>>>>>>>> >>>>>>>>> And it thinks it’s a WO app and has access to the model group and all >>>>>>>>> of EOF and I can do destructive stuff like creating and saving Eos to >>>>>>>>> the DB all inside a launch from Eclipse. >>>>>>>>> >>>>>>>>> Where I’m running into trouble is trying to do it with Maven. At the >>>>>>>>> moment I’m getting a null pointer from maven launch at the following >>>>>>>>> place. >>>>>>>>> >>>>>>>>> er.extensions.appserver.ERXApplication$Loader.collectMainProps(ERXApplication.java:757) >>>>>>>>> >>>>>>>>> I think because it is wanting to treat it as a bundle but it isn’t >>>>>>>>> and so… I’m not sure where to go from here. Any advice? >>>>>>>>> >>>>>>>>> AARON ROSENZWEIG / Chat 'n Bike <http://www.chatnbike.com/> >>>>>>>>> e: aa...@chatnbike.com <mailto:aa...@chatnbike.com> t: (301) >>>>>>>>> 956-2319 >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Do not post admin requests to the list. They will be ignored. >>>>>>>>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com >>>>>>>>> <mailto:Webobjects-dev@lists.apple.com>) >>>>>>>>> Help/Unsubscribe/Update your Subscription: >>>>>>>>> https://lists.apple.com/mailman/options/webobjects-dev/hprange%40gmail.com >>>>>>>>> >>>>>>>>> <https://lists.apple.com/mailman/options/webobjects-dev/hprange%40gmail.com> >>>>>>>>> >>>>>>>>> This email sent to hpra...@gmail.com <mailto:hpra...@gmail.com> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Do not post admin requests to the list. They will be ignored. >>>>>>>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com >>>>>>>> <mailto:Webobjects-dev@lists.apple.com>) >>>>>>>> Help/Unsubscribe/Update your Subscription: >>>>>>>> https://lists.apple.com/mailman/options/webobjects-dev/dennis%40selbstdenker.ag >>>>>>>> >>>>>>>> <https://lists.apple.com/mailman/options/webobjects-dev/dennis%40selbstdenker.ag> >>>>>>>> >>>>>>>> This email sent to den...@selbstdenker.ag >>>>>>>> <mailto:den...@selbstdenker.ag> >>>>>> >>>>> >>>> >>> >> >> _______________________________________________ >> Do not post admin requests to the list. They will be ignored. >> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com >> <mailto:Webobjects-dev@lists.apple.com>) >> Help/Unsubscribe/Update your Subscription: >> https://lists.apple.com/mailman/options/webobjects-dev/jtayler%40oeinc.com >> <https://lists.apple.com/mailman/options/webobjects-dev/jtayler%40oeinc.com> >> >> This email sent to jtay...@oeinc.com >
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
