[alf-dev] RE: Rejection of Jaxen and workarounds

Hello Joel,

I remember our conversation at the EclipseCon 2008 poster session. Yes. Jaxen has been an issue for a number of projects.

Regarding Jaxen, I tried contacting the original project participants by various means and received no response at all, (Michael Chmielewski had a similar experience) so the most direct approach to fixing the IP problem (as described in Mary Ruddy's and my notes below) via the original participants is unlikely to be successful. So I recommend looking at alternative approaches (which may or may not be applicable for your situation):

1. Working through the Apache foundation to remove the dependency on Jaxen. I spoke with Rajith Attapattu (RedHat) who was involed with some of the Apache Axis2 projects. He was fairly certain that Axis 2 1.4 no longer has a dependency on Jaxen. I have not gotten back to confirmed that is correct. (And there are other good reasons to move to Axis 1.4). I do not recall the name, but Rajith mentioned there is a contributer to the WTP project who is also on the Axis2 project, who may be a godd liasion to finding a solution at Apache that will work for Eclipse.

2. As I recall, ALF had a theoretical dependency on Jaxen (as reported by Jar Analyzer), but not an actual one (the paths that made calls to Jaxen were never executed.) After some conversations with Eclipse legal, the approach would be to resubmit a CQ for the Axis 2 1.2 jar with the Jaxen jar removed from the Axis 2 jar. [I'm guessing this may not work for your situation.]

3. See David Bosschaert's refactoring approach (below).

Here are a few datapoints and excerpts from various emails (some authored by folks on the address list) that may be of use. Please keep the interested parties in the loop as you pursue a solution for Jaxen

Regards,

Brian

From an email I sent on 4/16/2008. Brian wrote:

"About EMO IP's rejection of Jaxen and the impact of that on our ability to conduct release reviews while still in incubation.) I believe we are largely past this, as we have verified that we actually can run ALF without Jaxen. ALF uses Axis 2 1.2 and Jaxen showed up as a dependency of Axis 2 v1.2 when running Jar Analyzer. So there may be a theoretical dependency though not an actual one. I spoke with Janet and Sharron at EclipseCon about this, and I think we will be OK as long as I resubmit the Axis 2 1.2 jar with the Jaxen jar removed from the Axis 2 jar. So I think we will soon be past this hurdle."

From an email by Mary Ruddy on 1/16.2008. Mary wrote:

"Higgins' initial request for Jaxen was also turned down. We still have a need for it. My general understanding from Eclipse legal is getting the project to confirm that Jaxen asks candidates to confirm that they authored all the code they are contributing, explicitly grant their consent to release their code as open source under the BSD license, and that to the best of their knowledge they possess all the rights to do so". is the big deal The other issues should be manageable/fixable once we get past that."

Here is a thread on the same topic with comments by David Bosschaert (iona), Michael Chmielewski, and myself

For the STP XEF editor I refactored the code (that was using Jaxen through JDom) to use the Dom-based JAXP XPath API's javax.xml.xpath.XPath/javax.xml.xpath.XPathFactory. These API's are part of the JRE so they don't introduce any additional dependencies.

For more details see the getXMLSnippet()/putXMLSnippet() methods in http://dev.eclipse.org/svnroot/stp/trunk/org.eclipse.stp.policy/org.eclipse.stp.xef/src/org/eclipse/stp/xef/XMLUtil.java

Cheers,

David

Michal Chmielewski wrote:

> Brian,

> I had made 2 inquires to Bob Werken regarding Jaxen and gotten no

> reply at all. Not a no, but no reply at all. I have not yet tried

> calling JBoss and finding him on the employee directory somehow yet.

> But that's going to be my last stand I think.

> We like Jaxen because it allows some semantic checking of XPath

> expressions trees in BPEL during validation (arguments, argument

> types, _expression_ types, etc). The other impl. that I looked at do

> basically just evaluation of XPath expressions and don't expose the

> internal _expression_ structures .... at least I have not found one.

> eclipse.org lawyers don't like 2 things: (a) some obscure (but copy

> righted) story about a dead company called "Napster" (the first

> napster) - ok I get it, but c'mon ...."common sense" here people [

> that could be removed they said, geez, you don't say ] (2) The BSD

> license that's in the Jaxen source is missing the "terms" of the

> license. But it is a BSD license and pretty much states to a layman

> like me what can done - absence of terms implies that there are no terms.

> Other project under the eclipse.org umbrella that had requested the

> use of Jaxen have been as you say turned down and must have adapted to

> other solutions or even abandoned XPath perhaps.

> -michal

> PS. In case you had not watched this law professor make an interesting

> argument about copyright law and "derivative" works,

> Larry Lessig says the law is strangling creativity

> <http://www.ted.com/index.php/talks/view/id/187>

> Brian Carroll wrote:

>> Hi,

>> I'm the Eclipse ALF Project Lead and we have an interest in using

>> Axis2. Axis 2, in turn, has a dependency on Jaxen, the XML Path

>> walker; in particular, we believe both Axis 2 1.2 and 1.3 versions

>> can use Jaxen-1.1.1, which is the current and best documented and

>> attributed version.

>> All of the CQ's we collectively have submitted for Jaxen have been

>> rejected by the Eclipse IP team; the key reason for rejection is an

>> inability to establish that: "/Jaxen asks candidates to confirm that

>> they authored all the code they are contributing, explicitly grant

>> their consent to release their code as open source under the BSD

>> license, and that to the best of their knowledge they possess all the

>> rights to do so/".

>> **

>> So I would be interested in learning:

>> 1. Whether you contacted the Jaxen team (or Bob McWhirter, James

>> Strachan, and the Werken company, ...) or otherwise attempted to

>> resolve the IP issue?

>> If so, what did you learn?

>> 2. Have you found a suitable replacement for Jaxen?

>> If so, what is it and what changes were required in your

>> code that used XPath processing?

>> 3. Given Eclipse's adoption of runtime environments (SOA in

>> particular), do any of your projects anticipate using Axis2?

>> If so, what are you planning to do about the dependency on

>> Jaxen?

>> I've made some initial inquiries and I'm planning on pursuing this

>> further with Apache and the Jaxen team. I would be interested in

>> learning what you have found, knowing whether you are still

>> interested in Jaxen, and whether you have found a replacement XPath

>> processor. Le me know your level of interest and I'll be happy to

>> share whatever we find.

>> Thanks in advance,

>> Brian

>> Brian Carroll | Eclipse ALF Project Lead | Serena Fellow

>> (O) (503) 617-2436 (C) (503) 318-2017

>> Serena Software - The Mashups are here!

>> <http://www.serena.com/go/mashups-are-coming>

>> **********************************************************************

>> This email and any files transmitted with it are confidential and

>> intended solely for the use of the individual or entity to whom they

>> are addressed. Any unauthorized review, use, disclosure or

>> distribution is prohibited. If you are not the intended recipient,

>> please contact the sender by reply e-mail and destroy all copies of

>> the original message.

>> **********************************************************************

> --

> Michal Chmielewski, CMTS, Oracle Corp,

> W:650-506-5952 / M:408-209-9321

> "Manuals ?! What manuals ? Son, it's Unix, you just gotta know."

----------------------------

IONA Technologies PLC (registered in Ireland)

Registered Number: 171387

Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

Brian Carroll | Eclipse ALF Project Lead | Serena Fellow
(O) (503) 617-2436 (C) (503) 318-2017

Serena Software - The Mashups are here!

From: Joel Rosi-Schwartz [mailto:Joel.Rosi-Schwartz@xxxxxxxxx]
Sent: Tuesday, August 05, 2008 6:30 AM
To: Brian Carroll; Tim Buss; bsubram@xxxxxxxxxx; eishay@xxxxxxxxx; mary@xxxxxxxxxxxxx
Cc: Bjorn Freeman-Benson; Oisin Hurley; The Open Requirements Management Framework project development list
Subject: Rejection of Jaxen and workarounds

Hello Brian, Balan, Eishay, Mary, Michal and David,

I am a project leads for a new EF project ORMF and I am in process of filing the CQ's for all our 3rd party library dependencies. The one serious glitch I have hit is that we are heavily dependent on Jaxen in our initial code contribution. All of you are obviously aware that Jaxen has been rejected on numerous CQ requests as you filed them.

I am hoping that you will be able share with me your experiences on how you worked around not being able to use Jaxen. In particular we are using Dom4J (extensively) which has a runtime dependency on Jaxen for its XPath support. Are any of you using Dom4J and if so how are you handling xpath support?

All the best,

Joel

P Please consider the environment before printing this e-mail. Thank you.

http://www.etish.org http://www.eclipse.org/ormf