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