On Thu, 28 Mar 2002 22:32, Nicola Ken Barozzi wrote: > I know I'm repeating myself, but the current forrext.xgump descriptor is a > gump descriptor with these things added.
But it does waaaaaaaaaaaaaaaaaaaaay too much for me to be comfortable with and is not compatable with how I would like to do things or the way that maven does things (I believe). Some of my concerns would be; [1] <todo/> list should not be stored in there because it could be quite long and quite dynamic. For example; * Some projects use xdoclet to pull todos out of the source code (XDoclet is a Doclet that processes things and can be used to generate meta-data based on tags in source code and todo list generator is a standard xdoclet task) * Some projects use Bugzillas request for enhancement to keep track of todos * some projects keep track of it manually So keeping it in the project descriptor is not viable for those reasons. A possible solution would be to have <todo href="some/file.xtodo"/> *if* you could come with a DTD that both forrest and maven use then I would be +100 to include a <todo href=""/> tag but until then any such specification would only be forrest specific. I don't believe that mavern has a todo template at this point in time. Jason would you consider using forrests/stylebooks todo DTD? [2] <changes/> also has similar problems with todo (some projects update manually, some generate from CVS logs etc). I believe maven uses a CVS-specific format that is basically captures each log message. So in this case it is not compatable with mavens format. Personally I would prefer you to both work together to create a <changes/> DTD that is revision control independent (I drool for subversion) and is compatable with both your demands. Then you could maybe reference it via <changes href="some/file.xchanges"/> [3] <whoweare/> is similar to mavens developers descriptor but the problem is where do you place it. Should it be included in each module? in each project? in each repository? Apache wide? world wide? And I would also recomend that it use the users Apache account username as ID rather than BL, PD or whatever as that way you can map username to things like changes gathered via cvs log or from bugzilla or whatever. Anyways before this can go in you really need to combine forces with Mavern and get a consistent DTD. Then it may be time to consider putting them in the gump descriptors. [4] Misquote the license - There is no such thing as the Apache Public License there is only the Apache Software License ;) [5] The following seem a bit much and have no equivelent in mavern land so should probably be pushed into another file aswell. <detailed> <what> <why> Anywhows it mainly comes down to the fact that you and mavern do things differently and as yet there is no support for things like per-project scope, per-module scope, per-repository scope. Scope is important because try to think how difficult it would be to maintain a xgump descriptor with something like the avalon-excalibur CVS that will end up with something like 25 or so projects in one module. I guess most details should cascade from higher up scope but there should be some discussion on this. I would also like a lot more cross-talk with maven peeps to get the format of the shared data compatible with each other. I dont want to have to completely redo descriptors to move between products or at least not the common parts between forrest/mavern projects. So get together and standardize on basic DTDs for things like <changes/>, <todo/>, <people/> etc and I will gladly start converting the projects I am in to use these aspects. It will be good for both forrest and mavern to work together in these areas because it will feel safer to your users to know that they will only have to do the work once. > > BTW why is it forrest and not forest? > > forrest... gump... :-) Do you know how many times I have mis-typed it though - almost everytime ;) I would really recommend you don't name your project with a misspelling in it. -- Cheers, Pete ------------------------- All things considered, insanity may be the only reasonable alternative. ------------------------- -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
