On 27/01/2012, at 9:08 AM, Greg Brown wrote: > On Jan 20, 2012, at 6:39 PM, Lachlan Deck wrote: > >> I've been away over the Christmas break, but it appears no one's replied, >> so... >> >> Henrique and I worked on those archetypes a few years ago. I've not been >> doing any WebObjects development for a couple of years now; hence I've not >> had the need nor the opportunity to update them. >> >> But please feel free to attempt to improve them, via github. > > Yes, the maven stuff needs a little love and attention. This makes me wonder > if there can be a streamlining of maven.
It's pretty streamlined as it is from my point of view. The only thing to complain about is that the current templates give you a pom.xml file that may need updating. That's easy to fix. > Right now it is designed to be a totally separate system from the wolips > system. That's not true. But I think it's the other way around. WOLips makes assumptions about the kinds of dependencies being (such as framework bundles rather than jars). That's the chief cause of any pain using maven (or any build system other than wolips + ant). > The archetypes for project creation do need some updating. But--do we need > maven archetypes? Yes, imho. Maven has standard ways of doing things such as creating a new project that works for *any* type of project with an archetype. They're simple to maintain and provide standard ways of creating projects that do not require an Eclipse installation. > One way to use maven would be to use the regular FluffyBunny (FB) projects > creation, then have a wolips | goodie | option | choice that would take a FB > project and write a POM.xml. This option could be extended to even clone the > FB project, and put it in a src/main folder structure instead of the FB > folder structure, and make it a maven nature project in eclipse, if it > really mattered or was necessary. Development/debugging would then take place > with the same standard eclipse/wolips setup, which has many useful debugging > tools, debugging screens, some of which don't work with maven-natured eclipse > projects. If people using maven want to use FB by all means create a feature for it or additional archetypes. Debugging should just work because it's java not because of the project layout. > All the wiki documentation would not need anything special for maven, as > everybody would be developing/debugging with the standard wolips. However, if > somebody wanted to turn in a project, and not require downloading Wonder, and > all the directory setup, Wonder installation, etc.--then they could just > generate a pom.xml and turn in their project. I don't agree with your premise that no documentation etc is required for using a differing build system. It does. It's a different set-up in Eclipse, with differing dependency management, installation and so forth. > I don't know if the development part of a maven project in eclipse is what > people (4 or 5 people?) like; development seems to work better using standard > wolips. There were a couple of gotcha's for working with maven + wolips because of wolips insistence on FB and so forth. It's not too bad or unworkable. Just needs clearer docs and some additional effort in wolips itself to fix the assumptions. I added to wolips, for example, a component wizard that knows about both FB and maven directory structures. It was never made the official one but it could be easily promoted. Having done that, one problem would be solved. > Maybe a more streamlined approach, which piggybacks on all the wolips stuff > would be a useful future direction. It would be more efficient, require less > upkeep. > > Any thoughts about this? Personally I think the community would benefit by putting effort into making wolips more agnostic to the build system underneath it. i.e., it should just care that there is a classpath and resources should work whether as a file on disk or in a jar dependency. Put your efforts there and then you won't need to try and retrofit maven (or any other build system) to a particular FB layout or whatever. My 5c :-) Lachlan Deck [email protected] _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
