I also slap myself on the wrist, because I didn't include any tests for the struts patch.
I will always raise public bug reports or enhancement requests, but I've found the checkout-and-patch approach quite workable with open source in general, not just XDoclet. This is not a complaint, by any means, but rather a recognition of the nature of OSS. What I want isn't necessarily what the committer team wants, so I'll make it what I want by patching.
On two side notes, (a) I agree that merge files are better for action mappings, however I do what I'm told by our lead developers :-), and (b) I too am waiting to see XDoclet2 kick off, which is why I haven't been too vocal about changes to 1.2. We've got it working the way we want, albeit with patches, and it saves us a heck of a lot of dev time. I'd like to help with XDoclet2 if I can, but I haven't yet found the time to check it out and delve into it. When I do, I'll be submitting modules/patches us much as I can, and pushing for them to be applied.
Again, I did not intend to slight the efforts of the XDoclet committers - you're a great bunch, and I've harvested the benefits of your efforts in many OSS projects. Please keep up the good work.
Matt
Erik Hatcher wrote:
On Jan 4, 2004, at 8:03 PM, matt wrote:
You may find it useful with XDoclet to have a big patchfile to apply whenever you checkout XDoclet, as the committers do not seem to get much time for applying patches
I'll speak for myself here since I might be the most savvy (ex!) Struts committer. I'm weary of apply patches that do not directly relate to our usage patterns that I can easily test. For example, I don't use XDoclet-generated action mappings, rather I use a merge file for these.
I understand users frustrations with broken open source software though. I've been there myself and in fact I'm routinely there and often have to resort stepping up to the plate myself and fix things locally and then make a lot of noise in the community until the fixes are applied (or to shut me up they make me a committer to fix it myself :).
I'm not sure what the lifespan of XDoclet 1.x is at this point, but I'm currently in a wait-and-see mode with it. XDoclet 1.2 is doing everything we need it to do quite well at the moment so I'm not eager to apply patches. XDoclet2 is around the corner, so pragmatically my next move may be to shift entirely to that camp.
Perhaps you'd be interested in being a 1.x codebase committer, Matt? If so, keep bugging us and pointing us to your patches and we can bring up a vote.
Erik
------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ xdoclet-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-user
------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ xdoclet-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-user
