Where is the source for third-party jars that have been modified?

Turns out the jars distributed with Orbeon which have been modified specifically for OPS may cause us legal issues, as our lawyers are quite picky about exactly which FOSS packages we use. :(

My assumption for all the jars distributed in the "lib" folder is that unless they contain the word "orbeon" in their name, then I could replace them with the official version of the file from which project the jar is produced by.  In a handful of cases it appears I would have to grab a particular non-released version for the project's CVS/SVN repository and build it, but still, it is unchanged by OPS.   (Incidentally, could these latter ones not be replaced by one of the official releases?)

That leaves these "orbeon" jars:

- antlr-2_7_4_orbeon.jar
- exist-xmlrpc-1_2-patched.jar  ?
- jakarta-oro-2_0_8_orbeon.jar
- joost-20030623_orbeon.jar
- mondrian-0_5_orbeon.jar
- msv-20070407_orbeon.jar  
- resolver-xerces_2_6_2_orbeon.jar
- saxon-8_8_orbeon_20080516.jar  
- saxpath-dev_orbeon.jar
- xalan-2_5_1_orbeon.jar
- xerces-resolver-2_9_orbeon_20070711.jar
- xerces-serializer-2_9_orbeon_20070711.jar
- xerces-xercesImpl-2_9_orbeon_20070711.jar
- xerces-xml-apis-2_9_orbeon_20070711.jar
- xsltc-2_5_1_orbeon.jar

Where do I find the source for these?   I think we might be okay to use them, but we may have to go through the ugly exercise of verifying that the individual licenses have been satisfied by these modified releases, first.  And part of that is making sure the modifications are published.

And as an aside, I expect some of these might be no longer necessary (perhaps more-recent versions fixed whatever problem there was), but are carried along because it's simpler than going through the fix.  If this is the case, it might be that doing the fix is easier than working with our lawyers, so maybe we could help. ;-)

Thanks.

rodney





 

On Mon, Jun 30, 2008 at 11:17 AM, Rodney Gitzel <[hidden email]> wrote: In some cases, those libraries are just rerooted. For instance classes
will be moved from the packages org.apache.* to orbeon.apache.*, this
to avoid conflicts with the "same" libraries provided with some
application servers. When libraries are really changed, we do publish
those changes, but don't really have a central place for this. Changes
to YUI are on the Wiki
(https://wiki.objectweb.org/ops/Wiki.jsp?page=YUI), changes to Saxon
are checked in CVS, changes to eXist are applied by a script which is
checked in (patch_exist.sh).

You will find more about this here:
https://wiki.objectweb.org/ops/Wiki.jsp?page=ThirdPartyJavaLibraries
but this list is not exhaustive, so think it will take some effort to
compile an exhaustive list for legal purposes. If you do this work, or
if you find that some changes that were done in the past are not
required anymore, it would be great if you could contribute this back
:).

Alex
--
Orbeon Forms - Web 2.0 Forms, open-source, for the Enterprise
Orbeon's Blog: http://www.orbeon.com/blog/
Personal Blog: http://avernet.blogspot.com/
Twitter - http://twitter.com/avernet


--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
OW2 mailing lists service home page: http://www.ow2.org/wws

Alessandro Vernet wrote

In some cases, those libraries are just rerooted. For instance classes
will be moved from the packages org.apache.* to orbeon.apache.*, this
to avoid conflicts with the "same" libraries provided with some
application servers.

We just had this problem but in reverse:  OPS had worked fine everywhere until we deployed to a 'production' server.   I can provide more details later, but it turned out we can NOT use the Orbeon-modified Xerces jars.  Turns out that Xerces and Commons Logging are the only two packages out there that intentionally circumvent the normal classloader logic in a J2EE app.  Hence OPS in a completely separate EAR clobbers the log4j config in another EAR (I found you've since fixed that default config for 3.7, and I made them same change for our OPS).  And hence we hit exceptions where our own code out in the global classpath was dying when given the Orbeon parser, which it shouldn't even know exists!!!

Okay, that may not have made sense.  Upshot is this held us up for nearly two weeks and I now have a version of OPS 3.6 *without* the Orbeon Xerces implementation, and so far it's been fine -- with the caveat that the <xi:include> in the processors config doesn't work (but that's okay, I just manually pasted my elements in directly for now).

So... I have kind of already done some of the work of removing one of the packages, and my boss is willing for me to spend time to do it properly and contribute the change.  We might well do others, too.

I'm off on holiday the rest of the this week, but next week I could start in... in the meantime, could you determine if there is anything else specific to the Orbeon Xerces implementation other than how it handles includes?   That seems to be the case, from the wiki entry.   Also, when I looked at Saxon, it seemed odd, it seemed to be 8.8 but with a couple of classes (e.g. PathMap, IIRC) from 9.0 manually patched in?  I couldn't find a source zip from the Saxon folks that matched.


Cheers!

rodney