Re: Maven Unit tests with EOF
Re: Maven Unit tests with EOF
- Subject: Re: Maven Unit tests with EOF
- From: Aaron Rosenzweig via Webobjects-dev <email@hidden>
- Date: Thu, 23 Jan 2020 22:11:53 -0500
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: email@hidden <mailto:email@hidden> t: (301) 956-2319
> On Jan 23, 2020, at 4:24 PM, Jesse Tayler <email@hidden> 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
>> <email@hidden <mailto:email@hidden>>
>> 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: email@hidden <mailto:email@hidden> t: (301) 956-2319
>>
>>
>>
>>> On Jan 23, 2020, at 11:23 AM, Aaron Rosenzweig <email@hidden
>>> <mailto:email@hidden>> 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: email@hidden <mailto:email@hidden> t: (301) 956-2319
>>>
>>>
>>>
>>>> On Jan 23, 2020, at 10:03 AM, Aaron Rosenzweig <email@hidden
>>>> <mailto:email@hidden>> 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: email@hidden <mailto:email@hidden> t: (301) 956-2319
>>>>
>>>>
>>>>
>>>>> On Jan 23, 2020, at 9:58 AM, Dennis Scheffer <email@hidden
>>>>> <mailto:email@hidden>> 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 <email@hidden
>>>>>> <mailto:email@hidden>> 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: email@hidden <mailto:email@hidden> t: (301) 956-2319
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On Jan 23, 2020, at 2:54 AM, Dennis Scheffer <email@hidden
>>>>>>> <mailto:email@hidden>> 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
>>>>>>>> <email@hidden
>>>>>>>> <mailto:email@hidden>> 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
>>>>>>>>> <email@hidden
>>>>>>>>> <mailto:email@hidden>> 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: email@hidden <mailto:email@hidden> t: (301)
>>>>>>>>> 956-2319
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Do not post admin requests to the list. They will be ignored.
>>>>>>>>> Webobjects-dev mailing list (email@hidden
>>>>>>>>> <mailto:email@hidden>)
>>>>>>>>> Help/Unsubscribe/Update your Subscription:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> This email sent to email@hidden <mailto:email@hidden>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Do not post admin requests to the list. They will be ignored.
>>>>>>>> Webobjects-dev mailing list (email@hidden
>>>>>>>> <mailto:email@hidden>)
>>>>>>>> Help/Unsubscribe/Update your Subscription:
>>>>>>>>
>>>>>>>>
>>>>>>>> This email sent to email@hidden
>>>>>>>> <mailto:email@hidden>
>>>>>>
>>>>>
>>>>
>>>
>>
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Webobjects-dev mailing list (email@hidden
>> <mailto:email@hidden>)
>> Help/Unsubscribe/Update your Subscription:
>>
>> This email sent to email@hidden
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden