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
>
>
>
This archive was generated by hypermail 2.0.0 : Thu Apr 09 2009 - 03:42:24 EDT