With regard to me moving some code around in the main trunk (of which apparently one or two commit messages haven't made it to the svm list), we briefly discussed it as part of the "Excalibur != Component Repository" thread and there were no objections then. If there's a reason why this is a bad idea please say so and its easily reverted.
I don't think there will be a problem with moving code around as such but I think that you should at least engage the community before you start restructuring a repository.
This is especially true when it is just going to create more work for others if they are not given enough notice. I had uncommitted files that I was playing around with and it was a PITA to go through the steps in updating my local setup. Subversion also does not deal well with things like inability to delete local directories that are deleted in remote repo due to local files that were not version controlled.
In the end I had to spend about 30 minutes fixing up my local repo and this could have been avoided if I had been given warning that such a global change was imminent.
A "commit-then-review" way of doing things involves reverting things every now and then, which is now less of a hassle than when we were doing CVS. I've found this style of development can be very efficient if everyone is fine with it. Since it sounds like you don't like it, we can put a stop to it. What do others think? Is "commit-then-review" a bad idea?
Commit then review is fine except for design changes or changes that are likely to break other peoples code. (Branches are much more free-for-all). The change in structure is what I would call a design issue. I think people should be allowed to have an opinion on a change like this before it occurs.
Theres several questions that I would imediately ask;
* Why re-use the term containerkit?
* Why is the instrument part of containerkit? (It is independent of containers and could easily sit in its own hierarchy)
* Why is Lifecycle part of containerkit? Presumably Avalon/Merlin have forked a version of this by now and thus would it not make sense to migrate Lifecycle to fortress?
* Why is Logger in containerkit and monitor not?
* Why separate out deprecated elements? Isn't that going to lead to more churns as components are moved between different lifecycles? WHy not break the hierarchy up in how they are used? (ie why not have ecm/, fortress/, instrument/ etc as base dir names)
yadda yadda yadda
The answers are not as important as the ability to ask them and for each of us given the chance to influence how the changes are implemented.
With regard to the experiments hammett is doing, I hope its been made clear that they are just experiments, and that we agree this radical stuff isn't actually the way forward. From my own experience, dabbling with writing a different container or two can be a good way to better learn the way existing containers work, and I have no problems with it going on over here.
To be honest I have not looked at it and I really don't have any problem with whatever is occuring there. I have written a couple of interceptor toolkits myself and know how much work and pain it can be so I think hammett is probably doing a lot fo work that we should be thankful for.
However I would also be very concerned that one of the many numerous "AOP" toolktis were not considered. Many of them are relatively mature products that have already gone through several development cycles. They are going to be faster, better supported and more versatile than the toolkit in excalibur simply because they have had many more development hours funneled into them. No offense intended hammet ;)
If they are innapropriate (ie licensing, architecture or whatever) or we simply decide to reinvent for fun then thats fine but there should be some discussion about it.
Theres no use in drowning the project in beuracracy so that every change is a PITA but there should at least be some active discussion on whats going on and what people intend to do etc.
-- Cheers,
Peter Donald *------------------------------------------------* | You can't wake a person who is pretending | | to be asleep. -Navajo Proverb. | *------------------------------------------------*
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Apache Excalibur Project -- URL: http://excalibur.apache.org/
