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
