Hi Eric, Any (code) contribution is welcome of course!
> 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? I think it depends on the type of changes you are making. If the type of changes only affect internal APIs then just create a new JIRA and attach the patch granting ASF a license to use it. If you are making changes to external APIs, or are proposing any large changes, then it's probably best to discuss it on the dev list first. Note that Apache communities generally grant commit rights to the svn repo after receiving a reliable stream of patches... > 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? I will probably only accept patches for the 1.5.x branch if it falls into the realm of bug fixing, or a major improvement to the standard of the code, or if there is some compelling reason to merge it to that branch. So in general probably best to submit against trunk I guess. Thanks, Colm. On Wed, Aug 8, 2012 at 6:37 AM, Eric Johnson <[email protected]> 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. > > The port works, but now I've got an annoying problem - I don't wish to > maintain such a large fork forever. Barring the unlikely immediate uptake > of the GenXDM port in the Santuario project itself, I do fortunately have a > middle ground I can tackle - I've identified changes that I've made in my > port that make sense for Santuario with or without the "GenXDM" aspects of > my port. The changes I have in mind will reduce the size of my port, and > also I think improve the quality of the existing code base. > > For example, Santuario has code (in DOMKeyName) that looks like the > following: > > public void marshal(Node parent, String dsPrefix, DOMCryptoContext > context) > throws MarshalException > { > Document ownerDoc = DOMUtils.getOwnerDocument(**parent); > // prepend namespace prefix, if necessary > Element knElem = DOMUtils.createElement(**ownerDoc, "KeyName", > XMLSignature.XMLNS, > dsPrefix); > knElem.appendChild(ownerDoc.**createTextNode(name)); > parent.appendChild(knElem); > } > > Backporting my changes to the official project, this turns into this: > > public static void marshal(XmlWriter xwriter, KeyName keyName, String > dsPrefix) > throws MarshalException > { > xwriter.writeTextElement(**dsPrefix, "KeyName", > XMLSignature.XMLNS, keyName.getName()); > } > > 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. > > 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. > > -- Colm O hEigeartaigh Talend Community Coder http://coders.talend.com
