While generally I have no objections to doing it one step at a time,
let's look at the practical side of it. At the minimum we'll need to
exclude cayenne-jpa-unpublished from cayenne-server aggregated
artifact. This is easy and non-invasive. But... we'll also need to
remove the JPA docs from the release bundle, and make a clear
statement on the site about the JPA status ("not a part of Cayenne").
As a result it doesn't look like any marketing benefit will be
preserved, so is it worth the trouble of going half way with it?
Andrus
On Apr 9, 2009, at 10:24 AM, Aristedes Maniatis wrote:
On 09/04/2009, at 4:03 PM, Andrus Adamchik wrote:
What needs to be moved out is "cayenne-jpa-unpublished" (and the
corresponding itest modules), NOT the lifecycle events or EJBQL
stuff in "cayenne-jdk1.5-unpublished" - these we will keep. As I
mentioned before we are legally prohibited by the JSR license
agreement from releasing non-compliant provider as a final release.
So we can't make 3.0-final that includes classes from "cayenne-jpa-
unpublished". This was the driving factor behind this discussion.
Having to support API compliance of the backend is also a
consideration, albeit minor for now.
That makes sense. Could the simple solution for the legal issue be
just a change to the maven scripts so that JPA doesn't end up in the
final packaging. Then soul searching can be postponed for a while to
let the dust settle.
Ari Maniatis
-------------------------->
ish
http://www.ish.com.au
Level 1, 30 Wilson Street Newtown 2042 Australia
phone +61 2 9550 5001 fax +61 2 9550 4001
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
