On 8/8/12 1:37 AM, Eric Johnson wrote: > As I've mentioned before on this list, I've done a port of the Santuario > Java project to work with the GenXDM library.
> This seems to me like a pretty unequivocal improvement to the code. This > change better conveys the intent of the code, decouples the marshalling > logic from Santuario specific object and ties it instead to standard > javax.xml.crypto interfaces, and importantly for the port that I'm > maintaining, hides the "DOM" aspects found throughout the current > version of the method. This sounds like a potentially useful contribution, so I would encourage you to submit a patch according to Colm's suggestions. Any additional explanation of the changes that you think would help us when reviewing them would also be helpful. Thanks, Sean > > The proposed changes avoid adding or removing any functionality, because > a goal of the GenXDM has been slavish compatibility to the existing code > base. For example, I've gone through some trouble even to match up and > eliminate changes in white space in my port. All my changes also > preserve API compatibility, as I've aimed to preserve the existing test > cases without modification. Thus these changes might be considered low > priority to the team. However, I wouldn't be proposing them unless I > thought them of real value for improving the existing code. > > As I said, I'm interested in making these contributions, but I'd like to > understand from the existing contributors the best way to go about > contributing my proposed changes. > > Should I open a bug report for each type of contribution, and attach my > patches to those bug reports? Or should I first submit patches to the > mailing list for discussion? What's your preferred way of working? > > Should I generate a patch relative to the current trunk code, or > relative to the tag of the latest release (1.5.2) in Subversion? > > Any advice and direction you can provide would help greatly. > > -Eric Johnson. >
