Opening WOLips properties in a non-WO project doesn't work

[hugithordarson]

What works

Opening project properties for a WO project, going to "WOLips Development", unchecking "WebObjects Project" and closing the properties panel causes WOLips-related natures and buildCommands to be removed from the project's .project file. As expected. All well and fine.

What doesn't

However, if you open the project properties again and attempt to open either of the WOLips panels, an exception occurs. WOLips project properties won't work unless you manually add a WOLips nature to .project again.

This applies to any non-WO project, meaning you can't turn an Eclipse project into a WOLips project without hacking around in the .project file. Apparently WOLips loses track of build.properties if a WO nature isn't present.

java.lang.NullPointerException: Cannot invoke "org.objectstyle.wolips.variables.BuildProperties.getPrincipalClass(boolean)" because the return value of "org.objectstyle.wolips.core.resources.types.project.ProjectAdapter.getBuildProperties()" is null
	at org.objectstyle.wolips.ui.propertypages.WOLipsDevelopmentPropertyPage._addBundleSettingsSection(WOLipsDevelopmentPropertyPage.java:290)
	at org.objectstyle.wolips.ui.propertypages.WOLipsDevelopmentPropertyPage._createContents(WOLipsDevelopmentPropertyPage.java:308)

[nullterminated]

It would be really nice if we could tell Eclipse that it should add that nature if it sees a wolifecycle plugin in the pom file. The .project file is really the only eclipse file I can't .gitignore because of what you're pointing out here.

[hugithordarson]

Agreed, not having to rely on any Eclipse or WOLips specific files or values being present for WOLips to recognize a WO project would be totally awesome.

I'd personally like if it was deduced from either the pom's specified packaging (woapplication/woframework) or even preferably, the project root containing a build.properties file with at least a project.name and/or project.type present (I don't use the wolifecycle plugin).

[nullterminated]

I don't use the wolifecycle plugin

Oh yeah, now I remember :) I wonder, with a maven aware NSBundle in development, if we even need a project nature at all?

[hugithordarson]

Oh yeah, now I remember :)

I'm a special guy with special needs :)

I wonder, with a maven aware NSBundle in development, if we even need a project nature at all?

I think you're right that we really don't need it when a ProjectBundle is being used. The only thing I really add the nature for is to "enable" the project WRT WOLips, since that seems to be the way WOLips uses to identify it should be "active" on the project (or something like that).

[hugithordarson]

I just did a small experiment. Modified WOLipsNatureUtils.isWOLipsNature( IProject ) to return true if a build.properties file containing project.name is present in the project.

The change: hugithordarson@a0c6dbb

Effectively this means that WOLips becomes "active" when a build.properties file is present, and you can go to the project's WOLips settings and turn "WebObjects Project" on an off at will to add and remove the WOLips natures/builders.

However, some quick testing shows that with this hack, doing development with WOLips works fine without any WOLips natures or builders in .project when you're doing bundleless development (i.e. using ProjectBundles), meaning you don't need them at all. So I'd say this hack is an improvement over the current situation (although it's implementation should probably be more…proper since this will no doubt clobber up functionality in unexpected ways. This is mostly a proof of concept).

You're vastly more qualified than me to to consider something like this is a good idea or not @nullterminated . I'm just poking at things and seeing what works :).