bloritsch 2002/12/26 07:22:43 Modified: src/proposal/avalon5 discussion-points.txt Log: reformat points.txt to Wiki format Revision Changes Path 1.4 +111 -173 jakarta-avalon/src/proposal/avalon5/discussion-points.txt Index: discussion-points.txt =================================================================== RCS file: /home/cvs/jakarta-avalon/src/proposal/avalon5/discussion-points.txt,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- discussion-points.txt 20 Dec 2002 06:42:30 -0000 1.3 +++ discussion-points.txt 26 Dec 2002 15:22:42 -0000 1.4 @@ -1,178 +1,116 @@ += Tabled Discussions = + This document is to keep track of discusstion points related to Avalon 5 development. When things get to a point where they can be focused on in the Avalon-Dev -site without being considered noise. +site without being considered noise. Just follow the +format already outlined below. + +== Should we incorporate Commons Logging? == +This move would increase synergy with other +projects and reduce the amount of code that we +need to maintain. The issue was raised by Mauro +Telivi, and we need further communication to +figure out what is the best solution. + +=== PRO: === +* (bloritsch) It has the appeal of synergy with other communities. + +=== CON: === +* (bloritsch) I think that synergy comes at too high a price for Avalon's architecture. +* (pdonald) Nah. For the sharing of one interface it does not seem useful to couple the projects. Commons also passes down objects which is not a great idea as it means that you are binding to specific subsystems if you use that "feature". + +== Topic: Should we use Maven for the build? == +Our current build architecture is chaotic to say +the least. We have no less than three methods +of generating documentation, and serveral fairly +complex build scripts. Maven helps smooth out +the inconsistencies in the approach, and still +allows for plugging in a documentation building +tool like Fortress. Most importantly, it will +get rid of many JAR files in our CVS directory, +and simplify the build process for our users. + +=== PRO: === +* (bloritsch) We are in desparate need of a unified and simple build architecture. IMO, Maven is the best choice we have available. Let's simplify. Speed is only part of the issue here. We need to be able to manage project dependencies properly, and Maven's repository is a good solution. We can treat each individual project separately for the time being, so there is no heirarchy to worry about. When Maven does support it, and I think they will, we can consolidate things again. +* (pdonald) I am using maven to build the site for all the stuff I am moving out of Avalon. It is absolutely fantastic. There is a few hickups and it is definetly still alpha quality but it is better than what we have now. The great thing about it is that a lot of people have already done all the integration work and it is easy enough to get coverage, junit etc all integrated in. + +=== CON: === +* (pdonald) The negatives: + - speed (not a great problem in CVS version because of + "console" plugin) + - project inheritance is not fully done so we have to + copy a 3 line property file around when we are using; + however, this is supposed to be fixed before next release + - inheritance of maven.xmls is not possible as far as I + know so you can end up copying some around. Not sure + if this will be fixed .. but will become irrelevent if + next point picked up ... + - painful to manage your own plugins if not in maven CVS. + I believe this will hopefully be fixed sometime in the + future ... maybe :) + +I am using their last release and it seems to work well. +However it may be best to wait till next release +before converting Avalon (Just to avoid a few bugs that +the last Maven has). However I suggest we keep our current +ANT build system around until Maven gets the ability to +easily install plugins on per project basis at which +point we can dump our exisitng build system. + + +== Topic: Should we unify the CVS structures? == +We currently have ~9 CVS structures. The purpose +was to separate the different projects and make +it very clear what code belongs to which project. +That project also helps us identify areas of tight +coupling and what projects depend on which other +projects. That can still be done in one CVS +structure, using directories to distinguish the +projects. + +=== PRO: === +* (bloritsch) We have some projects that are no longer supported or needed (like Testlet). It would be a good way to clean out the cruft, and help manage the focus and scope of Avalon. +* (pdonald) Yes, BUT Maybe we should wait for subversion (subversion.tigris.org). It looks like a much better tool and if we go to that we can do the big re-arrange then. + +=== CON: === + +== Topic: Should we make the Avalon maling lists from avalon.apache.org? == +We are currently our own entity. We are not +a Jakarta project any more. I would suggest +the mailing lists (in addition to [EMAIL PROTECTED]): dev@, users@, +cvs@, and possibly general@ and [EMAIL PROTECTED] + +=== PRO: === +* (bloritsch) It would help establish the Avalon brand instead of Jakarta. +* (pdonald) +1 (aka me too) + +=== CON: === + +== Topic: Should we use our avalon.apache.org site? == +Whether we asked for it or not, the site does +exist, but it is currently empty. We should +put our current stuff in the new location, and +use redirects to point us all to the new +location. It would also enable us to make +sure we have mirror friendly distributions. + +=== PRO: === +* (bloritsch) Again we are solidifying Avalon. +* (pdonald) +1, though personally I would prefer that our website removed some of the crap that it has about. + +=== CON: === + +== Topic: Should we remove unused sets of code? == +Excalibur is rife with obsolete, competing, +and confusing stuff. Also mixed in there are +some *really* useful gold nuggets. By getting +rid of the failed experiments, we can focus our +energies and web site on what is good. -The general format will be something like this: +=== PRO: === +* (bloritsch) For competing technologies, they should be merged back into the parent project they came out of. Nine times out of ten, the only maintainers and developers for those projects support the parent project. We should also archive and remove all the CVS stuff for our deprecated packages. We aren't maintaining them any more--and they are still draining energies (of users, etc.). It will help clean the slate. -Topic: Should we do XYZ? -Explanation: - The following text should be a more descriptive - form of the XYZ topic. Either provide - justification, or clarification of what the - proposal entails. -PRO: - bloritsch - It looks good to me. -CON: - -Each topic will be separated by a row of dashes. - ----------------------------------------------------- - -Topic: Should we incorporate Commons Logging? -Explanation: - This move would increase synergy with other - projects and reduce the amount of code that we - need to maintain. The issue was raised by Mauro - Telivi, and we need further communication to - figure out what is the best solution. -PRO: - bloritsch - It has the appeal of synergy with other - communities. -CON: - bloritsch - I think that synergy comes at too high - a price for Avalon's architecture. - pdonald - Nah. For the sharing of one interface - it does not seem useful to couple the projects. - Commons also passes down objects which is not a - great idea as it means that you are binding to - specific subsystems if you use that "feature". - ---------------------------------------------------- - -Topic: Should we use Maven for the build? -Explanation: - Our current build architecture is chaotic to say - the least. We have no less than three methods - of generating documentation, and serveral fairly - complex build scripts. Maven helps smooth out - the inconsistencies in the approach, and still - allows for plugging in a documentation building - tool like Fortress. Most importantly, it will - get rid of many JAR files in our CVS directory, - and simplify the build process for our users. -PRO: - bloritsch - We are in desparate need of a unified - and simple build architecture. IMO, Maven is - the best choice we have available. Let's - simplify. Speed is only part of the issue here. - We need to be able to manage project dependencies - properly, and Maven's repository is a good - solution. We can treat each individual project - separately for the time being, so there is no - heirarchy to worry about. When Maven does - support it, and I think they will, we can - consolidate things again. - pdonald - I am using maven to build the site for - all the stuff I am moving out of Avalon. It is - absolutely fantastic. There is a few hickups - and it is definetly still alpha quality but it - is better than what we have now. The great thing - about it is that a lot of people have already - done all the integration work and it is easy - enough to get coverage, junit etc all integrated - in. -CON: - pdonald - The negatives: - - speed (not a great problem in CVS version because - of "console" plugin) - - project inheritance is not fully done so we have - to copy a 3 line property file around when we are - using - however this is supposed to be fixed before - next release - - inheritance of maven.xmls is not possibel as far as - I know so you can end up copying some around. Not - sure if this will be fixed .. but will become - irrelevent if next point picked up ... - - painful to manage your own plugins if not in maven - CVS. I believe this will hopefully be fixed sometime - in the future ... maybe :) - - I am using their last release and it seems to work - well. However it may be best to wait till next release - before converting Avalon (Just to avoid a few bugs that - the last Maven has). However I suggest we keep our current - ant build system around until Maven gets the ability to - easily install plugins on per project basis at which - point we can dump our exisitng build system. - --------------------------------------------------- - -Topic: Should we unify the CVS structures? -Explanation: - We currently have ~9 CVS structures. The purpose - was to separate the different projects and make - it very clear what code belongs to which project. - That project also helps us identify areas of tight - coupling and what projects depend on which other - projects. That can still be done in one CVS - structure, using directories to distinguish the - projects. -PRO: - bloritsch - We have some projects that are no - longer supported or needed (like Testlet). - It would be a good way to clean out the cruft, - and help manage the focus and scope of Avalon. - pdonald - Yes, BUT Maybe we should wait for subversion - (subversion.tigris.org) - it looks like a much - better tool and if we go to that we can do the - big re-arrange then. -CON: - --------------------------------------------------- - -Topic: Should we make the Avalon maling lists from - avalon.apache.org? -Explanation: - We are currently our own entity. We are not - a Jakarta project any more. I would suggest - the mailing lists (in addition to - [EMAIL PROTECTED]): dev@, users@, - cvs@, and possibly general@ and [EMAIL PROTECTED] -PRO: - bloritsch - It would help establish the - Avalon brand instead of Jakarta. - pdonald - +1 (aka me too) -CON: - ------------------------------------------------- - -Topic: Should we use our avalon.apache.org site? -Explanation: - Whether we asked for it or not, the site does - exist, but it is currently empty. We should - put our current stuff in the new location, and - use redirects to point us all to the new - location. It would also enable us to make - sure we have mirror friendly distributions. -PRO: - bloritsch - Again we are solidifying Avalon. - pdonald - +1, though personally I would prefer - that our website removed some of the crap - that it has about. -CON: - ------------------------------------------------ - -Topic: Should we remove unused sets of code? -Explanation: - Excalibur is rife with obsolete, competing, - and confusing stuff. Also mixed in there are - some *really* useful gold nuggets. By getting - rid of the failed experiments, we can focus our - energies and web site on what is good. -PRO: - bloritsch - For competing technologies, they - should be merged back into the parent project - they came out of. Nine times out of ten, - the only maintainers and developers for those - projects support the parent project. We - should also archive and remove all the CVS - stuff for our deprecated packages. We aren't - maintaining them any more--and they are still - draining energies (of users, etc.). It will - help clean the slate. -CON: - bloritsch - What projects are we removing? It - is a potential sticking point, and we still - need a copy of the old code. \ No newline at end of file +=== CON: === +* (bloritsch) What projects are we removing? It is a potential sticking point, and we still need a copy of the old code.
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
