openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kevin Sutter" <>
Subject Re: [DISCUSS] use backport-concurrent instead of repackaged concurrent classes
Date Wed, 06 Jun 2007 13:53:16 GMT
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.


On 6/4/07, Brian McCallister <> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message