santuario-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Colm O hEigeartaigh <>
Subject Re: Small milestone for genxdm-based port of Santuario - works with Axiom!
Date Thu, 05 May 2011 09:12:30 GMT
Hi Eric,

> Hmmm - does the reference to Maven mean that you're switching to Maven for
> the build?

Not really, you can build the current trunk code with both maven and
ant. However, the release artifacts will be generated with maven for
the 1.5.0 release, whereas previously they were generated with ant.


On Fri, Apr 29, 2011 at 4:36 PM, Eric Johnson <> wrote:
> Hi Colm,
> On 4/29/11 6:51 AM, Colm O hEigeartaigh wrote:
>> Hi Eric,
>>> I've already tracked changes for the 1.4.4 release. Obviously, this
>>> library
>>> being as sensitive as it is, I don't want it to fall too far out-of-step
>>> with the official releases.
>> 1.4.5 will be going out pretty soon, so I recommend porting the
>> changes made for this as well. I guess this is an obvious problem with
>> forking code, e.g. if you were to leave that project, would the next
>> maintainer bother merging security fixes etc.
> Yes, absolutely, I will be merging those changes. Also, I recognize that
> long term, some solution needs to be found to either completely fork, or
> merge back in, but maintaining an ongoing branch is quite tricky -
> especially when it is of such a huge magnitude of changes!
>>> Yes. We would consider that a wonderful outcome. However, GenXDM, at the
>>> moment, isn't an Apache hosted project. We're trying to prove out
>>> GenXDM's
>>> value. Mind you, we're eventually hoping to get enough interest that
>>> GenXDM
>>> that it can make for a viable Apache project.
>> Cool! I think this would be the best outcome, to mitigate concerns
>> about forking the codebase I raised above. One could envisage making
>> the current Santuario codebase into a multi-module maven project to
>> accommodate both approaches, or it could stay as a separate
>> sub-project.
> Well, my preferred outcome would be to have Santuario simply use GenXDM, and
> not have a fork at all. But then, you probably guessed that.
> Hmmm - does the reference to Maven mean that you're switching to Maven for
> the build?
>> What kind of process do you envisage happening to turn GenXDM into an
>> Apache project? Does it really matter for the santuario-genxdm project
>> whether the GenXDM code is in Apache or not?
> At this point, we're trying to prove the value of the GenXDM approach, and
> with that, get other people interested in contributing. Once we get a few
> more people interested, we'll resubmit our incubation proposal
> (
> Having GenXDM at Apache doesn't matter for the santuario-genxdm project, no.
> However, it does matter if we want to get wider adoption the project, or
> eliminate the fork of XML Security, and merge the branch back to the core
> code.
>>> I have considered one functional change. In canonicalization, there's a
>>> workaround for a bug in the Xalan XPath engine. That work-around requires
>>> modifying the input document to propagate namespace declarations down the
>>> tree. With GenXDM, that work-around is completely unnecessary, because
>>> that
>>> propagation is handled simply by passing a "true" value for a boolean to
>>> the
>>> method that traverses the namespace axis. I've been told by a colleague
>>> that
>>> that particular work-around has a serious performance impact, so
>>> switching
>>> to GenXDM's capability might have a benefit.
>> I plan on removing Xalan altogether from the code on trunk for a 1.5.0
>> release. I've already removed it from all of the tests, but I haven't
>> gotten around to tackling some of the lower-level stuff in the source
>> code yet.
> That shouldn't be too hard, as I recall it wasn't that hard to port the
> XPath filters to use the GenXDM APIs for XPath.
> -Eric.

View raw message