Thanks for the clarification. I understood that we were going to replace Doug's libraries with the backport stuff, but it didn't sound like we were proposing the binary prereq approach. I also just checked on the licensing of the backport stuff ( http://dcl.mathcs.emory.edu/util/backport-util-concurrent/index.php) and it looks like it's covered by the Creative Commons public domain licensing, so that's good. This sounds like an okay approach.
On 6/6/07, Patrick Linskey <[EMAIL PROTECTED]> wrote:
No, I'm suggesting that we pull it in as a binary prereq, and that we use the backport stuff instead of Doug's old stuff. -Patrick On 6/6/07, Kevin Sutter <[EMAIL PROTECTED]> wrote: > Let me see if I understand the proposal... > > We want to get an updated version of Doug Lea's concurrency libraries into > OpenJPA. Not as a binary prereq like Serp or Commons Collections. But, > rather we will bring the source into the OpenJPA svn repository and build it > like it was ours, but we don't want to change the package names? > > I think this is asking for problems down the road. At least with binary > prereqs, we can identify the specific version that we require and deal with > any incompatibilities between releases. But, if we just bring the source > into our tree without re-packaging, then we have no idea whether we are > running with the version that we ship or some other version that happens to > be available via the application's classpath. As OpenJPA continues to be > incorporated into larger and larger environments, we have to be concerned > about our prereqs (source or binary) and how they will interact with the > rest of the environment. > > I would vote to stick with our current practice of bringing in Doug Lea's > libraries and putting them into our own packaging scheme to avoid any > possible conflicts with other instances of these libraries. > > Thanks, > Kevin > > On 6/4/07, Brian McCallister <[EMAIL PROTECTED]> wrote: > > > > > > On Jun 4, 2007, at 6:58 PM, Patrick Linskey wrote: > > > > > In fact, I think that not repackaging the > > > backport classes is a good thing, as it lets people easily plug in the > > > faster Java 5 version without having to then re-repackage those > > > classes and recompile them. > > > > This is a really good reason to not renamespace, actually, as it is > > reasonable for people to want to change between distributed options. > > > > -Brian > > > -- Patrick Linskey 202 669 5907
