Agreed - I think we are all upset on this one.
I have a slightly different take on matters - I saw email discussion
start up three or four times - the missing part for me was a decision.
I think all the developers know by now that changing anything in the
build system costs at least a day in order to confirm everything works.
Also running Maven 2.0.6 when the official process is at Maven 2.0.5
will introduce conflicts etc....
So if I was setting up a wiki page on care and feeding of the maven
build process what needs to be in it?
1. Justification - do you have a really good reason to upgrade (so good
you are willing to spend a day of your time on it)
- list some alternatives like specifically depending on a maven plugin
(not sure if this is a good idea - ever)
2. Sanity Check
Try out the change to see if it is a good idea:
- check that mvn install works on your box (15 mins)
- check that mvn -Psite.build site works on your box (40 mins)
If either of these fail see if you can figure out why, and perhaps talk
to module maintainers for specific problems. Often upgrading maven
reveals existing problems.
3. Warning
Email developer list before hand for both discussion of:
- your Justification and Sanity Check
- picking a day to test, individual developers may try the change on
their own in order to explore the problem
4. Decision
- Gather up enough developers on different platforms to have a good
test, email or IRC will work
- Email the change around (upgrade Maven), or perform the change on a
branch (messing with pom.xml files)
- Gather up feedback from the different platforms and configurations:
mvn install (this takes 15 mins per attempt)
There are two show stopers:
- Ensure that the build boxs are upgraded successfully (Justin and Cory
as contacts)
- Ensure a release can be made: mvn -Psite.build site (this takes 40
mins per attempt)
3. Anouncement
- update developers guide either way (Maven 2.0.99 is good or Maven
2.0.99 has known problems)
- post news anouncement of the same
Adrian Custer wrote:
> This change suffers from:
>
> 1) No justification: There has been no well defined explanation as to
> why it was necessary to change the core build tool. (i.e. no one other
> than Martin answered Andrea's repeated questions, and Martin said he
> could downgrade).
>
> 2) No warning: while there has been discussion, there was no plan, no
> vote, not much of any decision, and no room to help other developers
> adapt to the change. (i.e. the announcement sounds an awful lot like
> "oh, btw. you need to have changed yesterday to keep working").
>
> A stable development system would include both of the above.
>
> --adrian
>
>
>
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
