[EMAIL PROTECTED] wrote: > Yep, > > Gump help alerts the developers to the issue. > > But, how many people will use JDOM? It'd be better if API breakages were > reported as a group, rather than each group needing to > discover/report/troubleshoot them. > > And it would be nice if Gump could, on request, report the breakage to the > component being used, rather than a developer needing to sign up on the > mailing lists.
Do you mean reproting the error to the dependency which introduce the problem? I wonder how feasible it would be and how many false positives it would generate. Determining the root cause of a breakage is probably going to remain a wetware task at the point the breakage manifests itself. How would you determine to which dependency a failure is to be attributed, if indeed it is not a bug in the project itself? The recent Latka DTD problem could have had a number of causes 1. A change in Xerces making the DTD appear bad 2. A change in Ant causing the style task to encounter some fatal exception 3. A change in the DTD itself 4. A change in the external Gump environment (OS, network, etc). It usually requires detailed analysis to uncover the root cause. > On the JDOM issue, it was a decision they chose to make. I'm not convinced > changing a public API without first deprecating it, even to add an > exception, is a good thing. The work around code to support both is ugly. Agreed. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
