Thanks Paul, That’s an insightful reply!
If I understand you right you are using the surefire plugin but setting the nature for Maven to find the files? That’s a neat way to do it. I think that nature was there for people who wanted to build with Maven inside of eclipse, but you can use it the way you have done as well. I had to stop trying but I should revisit soon. I think it is probably better to use the “failsafe / verify” instead of “surefire / test” because it will have the bundled .woa or .framework by then and should be a standard bundle. AARON ROSENZWEIG / Chat 'n Bike <http://www.chatnbike.com/> e: aa...@chatnbike.com <mailto:aa...@chatnbike.com> t: (301) 956-2319 > On Feb 12, 2020, at 10:37 PM, Paul Hoadley <pa...@logicsquad.net> wrote: > > Hi Aaron, > > I don't know whether you went on to solve your problem here, but I've just > spent a few hours of my life that I'll never get back debugging something > similar. I had just built a new framework from scratch, and WOUnit testing > under maven-surefire-plugin failed, with WOUnit complaining that it couldn't > find my models. I started by logging out NSBundle.mainBundle(), and recalled > your recent post: > > On 23 Jan 2020, at 15:01, Aaron Rosenzweig <aa...@chatnbike.com > <mailto:aa...@chatnbike.com>> wrote: > >> There are three types of concrete (not abstract) NSBundles: >> 1) NSLegacyBundle >> 2) NSFluffyBunnyProjectBundle >> 3) NSMavenProjectBundle > > During unit test initialisation it was reporting that the main bundle was an > NSFluffyBunnyProjectBundle, but the project type is Maven. > >> When I run this from Eclipse I can hit breakpoints and I confirmed that it >> is making an NSFluffyBunnyProjectBundle. > > The model-finding issue described above was apparent only when running "mvn > verify" from the command line, and Eclipse does have a habit of doing > additional classpath setup, so if you're just talking about "Run As > JUnit > Test" from within Eclipse, then all bets are off, but if you're seeing this > from the command line and your project is a Maven project, then this is > wrong. If you dig down into ERFoundation.jar and decompile > NSStandardProjectBundle.Factory, you'll find this: > > if ("org.maven.ide.eclipse.maven2Nature".equals(nature)) { > mavenProject = true; > } > > It's scanning the project's .project file and checking for: > > <nature>org.maven.ide.eclipse.maven2Nature</nature> > > If it finds that, it creates an NSMavenProjectBundle. If it doesn't, then > it's NSFluffyBunnyProjectBundle, which will be deficient because everything > is in the wrong places. (For example, it can't find models because they're in > src/main/resources, not Resources.) > > Adding that nature element to .project immediately fixed my issue. Why wasn't > it there in the first place? Because the Wonder archetype (and our custom > archetype that's based on it) no longer adds it because it's obsolete. > > <natures> > <nature>org.eclipse.m2e.core.maven2Nature</nature> > <nature>org.eclipse.jdt.core.javanature</nature> > > <nature>org.objectstyle.wolips.incrementalframeworknature</nature> > </natures> > > So, does your framework's .project file contain that nature element, and if > not does adding it in fix your issue? > > > -- > Paul Hoadley > https://logicsquad.net/ <https://logicsquad.net/> > https://www.linkedin.com/company/logic-squad/ > > >
_______________________________________________ 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
