Apple

Hi,

I wanted to look at the modern D2W stuff, and along the way found some issues/questions.

Maven can do some stuff for you, but it depends on a well maintained stable infrastructure. Maven really does not do work for you, it just pushes the work into the setup of repositories, project and so on. Then it appears that maven does all these things automagically for your project. Of course if the setup is not stable or maintained, then the whole maven thing won't work. Make no mistake, one is totally dependent on all this pre-existing setup that people have created. And in the past, maven got a bad name when the external components of maven changed, and broke peoples builds.

I used to think (3 yrs ago) that maven builds would eventually do everything that ant, eclipse could do, but I am not so sure that will ever happen now. Maven is a good system, and there are vast libraries of jars, etc. that are easy to access, but with Wonder and eclipse things work better with regular non-maven development. It is not worth the struggle; unless, of course, its required.

1. Maven archetypes–not working with eclipse? nor the wocommunity repositories, nor wonder source builds, and no modern D2w!

Archetypes create projects which use things like ERExtensions version 5.0.0-SNAPSHOT. But those things the archetypes reference don't exist anywhere. OK, now try to build those things from wonder source. Again it fails. It used to work. This is the Wonder_5_0_0_Legacy branch. The only wonder source build that works is with master, using jdk 1.6, and that creates jars of version 5.4-SNAPSHOT. Projects which used to build fail, they must be modified.

The various maven archetypes that I try to use to create projects generate errors with eclipse versions 3.6, and 3.7. There seems to be a conflict with of velocity. (different versions?)

Errors occurred during the build.

Errors running builder 'WOLips Incremental Builder' on project 'demet'.

The specified class for ResourceManager (org.apache.velocity.runtime.resource.ResourceManagerImpl) does not implement org.apache.velocity.runtime.resource.ResourceManager; Velocity is not initialized correctly.

Also, and this may just be a documentation error, the current recommended archetype–catalog.XML references the following versions of archetypes:

<groupId>org.objectstyle.woproject.maven2</groupId>

<artifactId>erxapplication-archetype</artifactId>

<version>2.1-SNAPSHOT</version>

http://maven.wocommunity.org/content/groups/public-snapshots

</repository>

<description>wonder application (snapshot)</description>

</archetype>

However, these 2.1-snapshot versions are not available anywhere.

2. Maven infrastructure

Maven requires an infrastructure in order to operate. This infrastructure includes a settings.XML, archetype–catalog.XML, repositories, and the project–object–model. As part of this infrastructure, wouldn't it be better to have a parent pom which could have all the generic webobjects common elements for webobject types of projects? This parent could have many elements like dependency management and default values for versions, and so on which would make the project pom to large and unwieldy. I imagine most of the people using maven already have parent poms. But wouldn't it make sense to supply a generic webobjects parent as part of the infrastructure? And of course put the parent in use with building Wonder, so it keeps relevant. The wonder top pom.xml would refer to this generic-woparent/pom.xml as its parent. Parts of the current wonder top pom.xml, shown below, could be cut out and modified to create the generic-woparent/pom.xml:

Using it in the wonder builds would insure the generic-woparent/pom.xml was correct and kept updated. The current project poms created by the various project archetypes would work with this generic-woparent/pom.xml. Everybody that currently is using parent poms could use the info in this generic-woparent/pom.xml as well.

I just had a strange problem where the 5.3.3 and 5.4.3 versions of jars were both listed as dependencies, and things did not work very well; my own generic-woparent/pom.xml straightened out the problem. But why have everybody re-invent the wheel? Something like this should just be part of the infrastructure, because sooner or later, every maven users will need it. (I can email mine if anybody is interested.)

2a. Also I noticed that when using the eclipse "Run as maven build" eclipse ignores plugin versions as specified in settings, pom, etc. and uses LATEST version:

[INFO] Attempting to resolve a version for plugin: org.objectstyle.woproject.maven2:maven-wolifecycle-plugin using meta-version: LATEST

[INFO] Using version: 2.3-SNAPSHOT of plugin: org.objectstyle.woproject.maven2:maven-wolifecycle-plugin

[INFO] Attempting to resolve a version for plugin: org.objectstyle.woproject.maven2:maven-wolifecycle-plugin using meta-version: LATEST

[INFO] Using version: 2.3-SNAPSHOT of plugin: org.objectstyle.woproject.maven2:maven-wolifecycle-plugin

[INFO] Scanning for projects...

[INFO] ------------------------------------------------------------------------

[INFO]

This could be a problem if there were a bad experimental plugin. Of course, the command line works as expected. This is for eclipse 3.4, 3.6, 3.7.

2b. Now that github replaces svn, will there be releases like 5.0.0-r11323 ? Maybe like 5.4-20111220 would be more meaningful.

3. Maven documentation

Because the versions of plug-ins, maven, etc. constantly change, wouldn't it make sense to have a documentation page which gathered all the correct, recommended, and current versions for maven? All the other pages would reference this ”current-versions” page, e.g. "...see the current_versions page for the correct current version to use" . That would mean there would be only one place to check, and also only one place to update this changing version information. I would update the documentation to make this so, unless people think that is a bad idea.

Also, an errata page. There are always going to be issues and things that don't work quite right. I would be useful to have a page that listed the know problems and solutions.

3. Maven and Wonder conflicts

I haven't been bitten--only nipped--but what all are the show stoppers in Wonder/maven? There is:

public enemy #1: ERXFileUtilities

public enemy #2: ERXStaticResourceRequestHandler- Is this a problem? does Henrique's JarResourceRequestHandler solve this?

ERXLocalizer?

Thanks for the answers.

G Brown

email@hidden