Maven2ized site alpha (with javadocs)

[ge0ffrey]

I am in the process of writing a script to maven2ize spring-rich.
I am already able to compile spring rich already and let maven generate some stuff, such as javadocs for example.
Next weekend I 'll clean it up some more and do petclinic too.
After that I 'll share the files to actually maven2ize it, starting making snapshot's, talk to Ollie, Larry and the other developers if they 'd actually want to take it in or not.
But for now I already uploaded the maven generated sites to my website.
However I haven't gotten a chance to merge them yet.
Also the changelogs don't show anything yet (fixable later).

http://users.telenet.be/geoffrey/Del...nt/site/parent (general info)
http://users.telenet.be/geoffrey/Del...ient/site/core (javadocs)
http://users.telenet.be/geoffrey/Del...t/site/sandbox (javadocs)
http://users.telenet.be/geoffrey/Del...site/resources

Once again, it's not finished by far yet, so don't base your decision on it yet wheter or not you like maven2 over ANT...

[ge0ffrey]

Links to wiki & jira are messed up, but fixed locally.

[ge0ffrey]

I am actually not a developer (yet?), that's wrong too in the project team page.

[Ben Alex]

You'd probably be best off bringing this up on the Spring Rich Developers' list.

[ge0ffrey]

You'd probably be best off bringing this up on the Spring Rich Developers' list.

Already did

Ben,

Some of the dependencies spring-richtclient needs aren't in ibiblio, so I 've made a remote repository in my ${basedir} (untill I can put that online somewhere). Have you had this problem in acegi and how did you fix it?
I 've maven2ized glazedlist (1.5.0 will be on ibiblio soon but breaks spring-richclient), but many others are still to do, including the spring-binding snapshot etc.

Is Spring (besides acegi) going the maven2 way (I noticed some project.xml's in their sources)?
Does spring have any conventions on their maven2 repositories?

[benoitx]

Hi Geoffrey

Way to go! Excellent move.

I definitely recommend the addition of findbugs, pmd, checkstyle, simian and cobertura, and, of course, qalab! (http://qalab.sourceforge.net). as well as links to the jars that are built.

My company launched this little open-source project that keeps track of the number of QA issues detected by pmd/findbugs/simian/cobertura/checstyle over time. We're working on an m2 plugin at the moment but have noticed that the cobertura plug in is badly broken...

Best regards

Benoit

[Ben Alex]

Some of the dependencies spring-richtclient needs aren't in ibiblio, so I 've made a remote repository in my ${basedir} (untill I can put that online somewhere). Have you had this problem in acegi and how did you fix it?

Made a new repo at http://acegisecurity.sourceforge.net/maven. You can easily add this under your project_home/htdocs directory on the shell.sourceforge.net server.

Is Spring (besides acegi) going the maven2 way (I noticed some project.xml's in their sources)?

project.xml is Maven 1.x. pom.xml is Maven 2.x. I would not think Spring core will shift to Maven 2.x within the foreseeable future, due to the investment in the existing Ant-based build system.

Does spring have any conventions on their maven2 repositories?

Carlos Sanchez would be the best person to ask. Carlos is a Maven developer, and also assists with Acegi Security's Maven build maintenance and initial migration. I know Carlos offered to assist the Spring team more to Maven 2.x on the developer list, but I don't recall there being any replies. If you do establish a Maven 2 build, you might consider running a nightly Maven build to publish to your project home page. We do this, which is why http://acegisecurity.org always reflects the latest CVS code. This is useful for the project team to see code coverage, demonstrate that the unit tests work to people who are having difficulty running them locally etc.

[wireframe]

I also think that spring-rcp would *highly* benefit from componatizing it's codebase. it should be modularized according to function:
* binding
* forms
* core
* etc

Maven2 makes this a snap, and it would greatly help pull new developers in if they didn't have to know "all of spring-rcp". just look at jgoodies (forms, looks, binding, etc)...

[ge0ffrey]

I also think that spring-rcp would *highly* benefit from componatizing it's codebase. it should be modularized according to function:
* binding
* forms
* core
* etc

Maven2 makes this a snap, and it would greatly help pull new developers in if they didn't have to know "all of spring-rcp". just look at jgoodies (forms, looks, binding, etc)...

I most definitly agree.
Spring itself goes far in this too, like hibernate2 and hibernate3 seperated.
I am already splitting up petclinic in common, server, client and standalone for the maven2ization.
Problem with the springrich is I don't dare do it now, as I have no idea where a good breakline would be to avoid cyclic dependencies. I 'll make some modules like binding, form, tiger (compiling with 1.5) and put everything in "core" for now, so the others can worry about migrating stuff out.

Tiger depends on form, binding.
Form depends on binding.
Binding depends on core.
Any other modules that would be handy?

[wireframe]

I think this is a great start, and you've got to start somewhere. Once these smaller modules are in place, it should become clear if there are any other componets that could be pulled out as well.

I also think that this modularization could be a big help for the developers that run the spring-rcp project. There's been a lot of talk lately about needing a strong lead developer to take hold of the project, but it would be much more effective to have multiple smaller projects with multiple stake holders. One single "dictator" for the project is not going to be effective. Spring-RCP is a lot like the main springframework. There are multiple components and there's no single developer that owns or knows the entire project. it's more of a loose collaboration of developers, each with their own expertise.

I'm no spring-rcp expert, but if the project was componatized, I would feel much more comfortable digging in and contributing to the pieces that I use and enhance the most...