You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cayenne.apache.org by Andrus Adamchik <an...@objectstyle.org> on 2013/02/07 20:15:15 UTC
[VOTE] 3.1B2
So, the second Beta is ready and can be found at [1] in its Maven form and at [2] as source and binary assemblies. Please evaluate the release and cast your votes.
Since the docs are still work in progress, I decided not to make it an RC release, but I think we are getting there.
Thanks,
Andrus
[1] https://repository.apache.org/content/repositories/orgapachecayenne-200/
[2] http://people.apache.org/~aadamchik/release/3.1B2/
Re: [VOTE] 3.1B2
Posted by Andrus Adamchik <an...@objectstyle.org>.
Good news - we've fully confirmed the issue to be unrelated to this release [3], and we have binding votes to conclude the vote and publish the release. I am adding my +1 here too. So the vote tally:
Ari Maniatis +1
Tore Halset +1
John Huss +1
Andrus Adamchik +1
Congratulations on the release! I will push the artifacts (probably today) and will prepare the announcement (probably tomorrow).
Thanks,
Andrus
[3] https://issues.apache.org/jira/browse/CAY-1795
On Feb 7, 2013, at 7:15 PM, Andrus Adamchik <an...@objectstyle.org> wrote:
> So, the second Beta is ready and can be found at [1] in its Maven form and at [2] as source and binary assemblies. Please evaluate the release and cast your votes.
>
> Since the docs are still work in progress, I decided not to make it an RC release, but I think we are getting there.
>
> Thanks,
> Andrus
>
> [1] https://repository.apache.org/content/repositories/orgapachecayenne-200/
> [2] http://people.apache.org/~aadamchik/release/3.1B2/
Re: [VOTE] 3.1B2
Posted by Tore Halset <ha...@pvv.ntnu.no>.
+1
examined the mac bundle, run it with the test suite for our cayenne-based product. We are already using almost the same (up to and including CAY-1741) in production.
Regards,
Tore.
On 7. feb. 2013, at 20:15, Andrus Adamchik <an...@objectstyle.org> wrote:
> So, the second Beta is ready and can be found at [1] in its Maven form and at [2] as source and binary assemblies. Please evaluate the release and cast your votes.
>
> Since the docs are still work in progress, I decided not to make it an RC release, but I think we are getting there.
>
> Thanks,
> Andrus
>
> [1] https://repository.apache.org/content/repositories/orgapachecayenne-200/
> [2] http://people.apache.org/~aadamchik/release/3.1B2/
Re: [VOTE] 3.1B2
Posted by John Huss <jo...@gmail.com>.
+1 Looks good to me.
On Sun, Feb 17, 2013 at 7:49 AM, Andrus Adamchik <an...@objectstyle.org>wrote:
> Resuming the vote..
>
> I investigated the issue with the mapping and found it to be a user
> mapping error. There's room for validation improvement there, but no
> Cayenne bug as such. I'll wait till Dima confirms this before closing the
> vote, but I think it is safe now to resume the vote.
>
> Andrus
>
> On Feb 15, 2013, at 4:43 PM, Andrus Adamchik <an...@objectstyle.org>
> wrote:
>
> > Ok, I checked with Dima - my fix per CAY-1794 didn't help. I'll have to
> spend some more time reproducing the problem. I guess I'll be suspending
> the vote for a few days until we identify the problem and decide whether it
> warrants the release cancelation.
> >
> > Andrus
> >
> > On Feb 15, 2013, at 2:50 PM, Andrus Adamchik <an...@objectstyle.org>
> wrote:
> >
> >> Thanks for the information. Let me try to reproduce this.
> >>
> >> On Feb 15, 2013, at 11:32 AM, Dzmitry Kazimirchyk <
> dkazimirchyk@gmail.com> wrote:
> >>
> >>> From what I was able to find now it seems like it is related to
> CAY-1729. I'm not sure how it used to work before but now for us the
> problem is that we have id property declared in super entity and inherited
> by sub entities. Now this property is present in every sub entity
> descriptor's declaredProperties list which itself looks like it is meant to
> accumulate only NEW UNIQUE properties declared in sub entities and not
> present in parent. This in turn leads to id column descriptor type of super
> entity always being reset to VOID by following code inside SelectTranslator
> and therefore field always containing null value.
> >>>
> >>> private void appendColumn(.......... {
> >>> if (skipSet.add(new ColumnTracker(alias, attribute))) {
> >>> ..... add new column descriptor.......
> >>> }
> >>> else if (objAttribute != null) {
> >>> .............
> >>> for (ColumnDescriptor column : columns) {
> >>> if (attribute.getName().equals(column.getName())) {
> >>> ........
> >>> if (original != null) {
> >>> if (attributeOverrides == null) {
> >>> attributeOverrides = new
> HashMap<ObjAttribute, ColumnDescriptor>();
> >>> }
> >>>
> >>> attributeOverrides.put(original, column);
> >>> column.setJavaClass(Void.TYPE.getName());
> >>> }
> >>> ..............
> >>> }
> >>> }
> >>> }
> >>> }
> >>>
> >>> ELSE part is executed if the attribute is already present: the case we
> get with id props coming again from sub entities.
> >>>
> >>> Not sure if my rough investigation is helpful in some way but probably
> might be a place to start with.
> >>>
> >>> Dima
> >>>
> >>> On 02/15/2013 01:29 PM, Andrus Adamchik wrote:
> >>>> Dima, do you have the details of the problem to post on this list?
> >>>
> >>>
> >>
> >>
> >
> >
>
>
Re: [VOTE] 3.1B2
Posted by Andrus Adamchik <an...@objectstyle.org>.
Resuming the vote..
I investigated the issue with the mapping and found it to be a user mapping error. There's room for validation improvement there, but no Cayenne bug as such. I'll wait till Dima confirms this before closing the vote, but I think it is safe now to resume the vote.
Andrus
On Feb 15, 2013, at 4:43 PM, Andrus Adamchik <an...@objectstyle.org> wrote:
> Ok, I checked with Dima - my fix per CAY-1794 didn't help. I'll have to spend some more time reproducing the problem. I guess I'll be suspending the vote for a few days until we identify the problem and decide whether it warrants the release cancelation.
>
> Andrus
>
> On Feb 15, 2013, at 2:50 PM, Andrus Adamchik <an...@objectstyle.org> wrote:
>
>> Thanks for the information. Let me try to reproduce this.
>>
>> On Feb 15, 2013, at 11:32 AM, Dzmitry Kazimirchyk <dk...@gmail.com> wrote:
>>
>>> From what I was able to find now it seems like it is related to CAY-1729. I'm not sure how it used to work before but now for us the problem is that we have id property declared in super entity and inherited by sub entities. Now this property is present in every sub entity descriptor's declaredProperties list which itself looks like it is meant to accumulate only NEW UNIQUE properties declared in sub entities and not present in parent. This in turn leads to id column descriptor type of super entity always being reset to VOID by following code inside SelectTranslator and therefore field always containing null value.
>>>
>>> private void appendColumn(.......... {
>>> if (skipSet.add(new ColumnTracker(alias, attribute))) {
>>> ..... add new column descriptor.......
>>> }
>>> else if (objAttribute != null) {
>>> .............
>>> for (ColumnDescriptor column : columns) {
>>> if (attribute.getName().equals(column.getName())) {
>>> ........
>>> if (original != null) {
>>> if (attributeOverrides == null) {
>>> attributeOverrides = new HashMap<ObjAttribute, ColumnDescriptor>();
>>> }
>>>
>>> attributeOverrides.put(original, column);
>>> column.setJavaClass(Void.TYPE.getName());
>>> }
>>> ..............
>>> }
>>> }
>>> }
>>> }
>>>
>>> ELSE part is executed if the attribute is already present: the case we get with id props coming again from sub entities.
>>>
>>> Not sure if my rough investigation is helpful in some way but probably might be a place to start with.
>>>
>>> Dima
>>>
>>> On 02/15/2013 01:29 PM, Andrus Adamchik wrote:
>>>> Dima, do you have the details of the problem to post on this list?
>>>
>>>
>>
>>
>
>
Re: [VOTE] 3.1B2
Posted by Andrus Adamchik <an...@objectstyle.org>.
Ok, I checked with Dima - my fix per CAY-1794 didn't help. I'll have to spend some more time reproducing the problem. I guess I'll be suspending the vote for a few days until we identify the problem and decide whether it warrants the release cancelation.
Andrus
On Feb 15, 2013, at 2:50 PM, Andrus Adamchik <an...@objectstyle.org> wrote:
> Thanks for the information. Let me try to reproduce this.
>
> On Feb 15, 2013, at 11:32 AM, Dzmitry Kazimirchyk <dk...@gmail.com> wrote:
>
>> From what I was able to find now it seems like it is related to CAY-1729. I'm not sure how it used to work before but now for us the problem is that we have id property declared in super entity and inherited by sub entities. Now this property is present in every sub entity descriptor's declaredProperties list which itself looks like it is meant to accumulate only NEW UNIQUE properties declared in sub entities and not present in parent. This in turn leads to id column descriptor type of super entity always being reset to VOID by following code inside SelectTranslator and therefore field always containing null value.
>>
>> private void appendColumn(.......... {
>> if (skipSet.add(new ColumnTracker(alias, attribute))) {
>> ..... add new column descriptor.......
>> }
>> else if (objAttribute != null) {
>> .............
>> for (ColumnDescriptor column : columns) {
>> if (attribute.getName().equals(column.getName())) {
>> ........
>> if (original != null) {
>> if (attributeOverrides == null) {
>> attributeOverrides = new HashMap<ObjAttribute, ColumnDescriptor>();
>> }
>>
>> attributeOverrides.put(original, column);
>> column.setJavaClass(Void.TYPE.getName());
>> }
>> ..............
>> }
>> }
>> }
>> }
>>
>> ELSE part is executed if the attribute is already present: the case we get with id props coming again from sub entities.
>>
>> Not sure if my rough investigation is helpful in some way but probably might be a place to start with.
>>
>> Dima
>>
>> On 02/15/2013 01:29 PM, Andrus Adamchik wrote:
>>> Dima, do you have the details of the problem to post on this list?
>>
>>
>
>
Re: [VOTE] 3.1B2
Posted by Andrus Adamchik <an...@objectstyle.org>.
Thanks for the information. Let me try to reproduce this.
On Feb 15, 2013, at 11:32 AM, Dzmitry Kazimirchyk <dk...@gmail.com> wrote:
> From what I was able to find now it seems like it is related to CAY-1729. I'm not sure how it used to work before but now for us the problem is that we have id property declared in super entity and inherited by sub entities. Now this property is present in every sub entity descriptor's declaredProperties list which itself looks like it is meant to accumulate only NEW UNIQUE properties declared in sub entities and not present in parent. This in turn leads to id column descriptor type of super entity always being reset to VOID by following code inside SelectTranslator and therefore field always containing null value.
>
> private void appendColumn(.......... {
> if (skipSet.add(new ColumnTracker(alias, attribute))) {
> ..... add new column descriptor.......
> }
> else if (objAttribute != null) {
> .............
> for (ColumnDescriptor column : columns) {
> if (attribute.getName().equals(column.getName())) {
> ........
> if (original != null) {
> if (attributeOverrides == null) {
> attributeOverrides = new HashMap<ObjAttribute, ColumnDescriptor>();
> }
>
> attributeOverrides.put(original, column);
> column.setJavaClass(Void.TYPE.getName());
> }
> ..............
> }
> }
> }
> }
>
> ELSE part is executed if the attribute is already present: the case we get with id props coming again from sub entities.
>
> Not sure if my rough investigation is helpful in some way but probably might be a place to start with.
>
> Dima
>
> On 02/15/2013 01:29 PM, Andrus Adamchik wrote:
>> Dima, do you have the details of the problem to post on this list?
>
>
Re: [VOTE] 3.1B2
Posted by Dzmitry Kazimirchyk <dk...@gmail.com>.
From what I was able to find now it seems like it is related to
CAY-1729. I'm not sure how it used to work before but now for us the
problem is that we have id property declared in super entity and
inherited by sub entities. Now this property is present in every sub
entity descriptor's declaredProperties list which itself looks like it
is meant to accumulate only NEW UNIQUE properties declared in sub
entities and not present in parent. This in turn leads to id column
descriptor type of super entity always being reset to VOID by following
code inside SelectTranslator and therefore field always containing null
value.
private void appendColumn(.......... {
if (skipSet.add(new ColumnTracker(alias, attribute))) {
..... add new column descriptor.......
}
else if (objAttribute != null) {
.............
for (ColumnDescriptor column : columns) {
if (attribute.getName().equals(column.getName())) {
........
if (original != null) {
if (attributeOverrides == null) {
attributeOverrides = new
HashMap<ObjAttribute, ColumnDescriptor>();
}
attributeOverrides.put(original, column);
column.setJavaClass(Void.TYPE.getName());
}
..............
}
}
}
}
ELSE part is executed if the attribute is already present: the case we
get with id props coming again from sub entities.
Not sure if my rough investigation is helpful in some way but probably
might be a place to start with.
Dima
On 02/15/2013 01:29 PM, Andrus Adamchik wrote:
> Dima, do you have the details of the problem to post on this list?
Re: [VOTE] 3.1B2
Posted by Andrus Adamchik <an...@objectstyle.org>.
Dima, do you have the details of the problem to post on this list?
On Feb 15, 2013, at 9:12 AM, Aristedes Maniatis <ar...@maniatis.org> wrote:
> On 15/02/13 3:17am, Andrus Adamchik wrote:
>> I know you are all using trunk builds;). Anyone else can take a look at the release please?
>
>
> I recommend we hold off on promoting the release until you talk to Dima. It looks as though he may have discovered a regression in inheritance. It may be nothing, but it is worth checking out. At any rate it breaks unit tests in one of our applications where 3.1b1 had no problem.
>
>
> Ari
>
> --
> -------------------------->
> Aristedes Maniatis
> GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
>
Re: [VOTE] 3.1B2
Posted by Aristedes Maniatis <ar...@maniatis.org>.
On 15/02/13 3:17am, Andrus Adamchik wrote:
> I know you are all using trunk builds;). Anyone else can take a look at the release please?
I recommend we hold off on promoting the release until you talk to Dima. It looks as though he may have discovered a regression in inheritance. It may be nothing, but it is worth checking out. At any rate it breaks unit tests in one of our applications where 3.1b1 had no problem.
Ari
--
-------------------------->
Aristedes Maniatis
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
Re: [VOTE] 3.1B2
Posted by Michael Gentry <mg...@masslight.net>.
It is still on my To Do List, but just haven't had time yet. It will most
likely be this weekend before I can get to it.
Sorry,
mrg
On Thu, Feb 14, 2013 at 11:17 AM, Andrus Adamchik <an...@objectstyle.org>wrote:
> Hey Cayenne PMC'ers,
>
> I know you are all using trunk builds ;). Anyone else can take a look at
> the release please?
>
> Thanks,
> Andrus
>
> On Feb 7, 2013, at 7:15 PM, Andrus Adamchik <an...@objectstyle.org>
> wrote:
>
> > So, the second Beta is ready and can be found at [1] in its Maven form
> and at [2] as source and binary assemblies. Please evaluate the release and
> cast your votes.
> >
> > Since the docs are still work in progress, I decided not to make it an
> RC release, but I think we are getting there.
> >
> > Thanks,
> > Andrus
> >
> > [1]
> https://repository.apache.org/content/repositories/orgapachecayenne-200/
> > [2] http://people.apache.org/~aadamchik/release/3.1B2/
>
>
Re: [VOTE] 3.1B2
Posted by Andrus Adamchik <an...@objectstyle.org>.
Hey Cayenne PMC'ers,
I know you are all using trunk builds ;). Anyone else can take a look at the release please?
Thanks,
Andrus
On Feb 7, 2013, at 7:15 PM, Andrus Adamchik <an...@objectstyle.org> wrote:
> So, the second Beta is ready and can be found at [1] in its Maven form and at [2] as source and binary assemblies. Please evaluate the release and cast your votes.
>
> Since the docs are still work in progress, I decided not to make it an RC release, but I think we are getting there.
>
> Thanks,
> Andrus
>
> [1] https://repository.apache.org/content/repositories/orgapachecayenne-200/
> [2] http://people.apache.org/~aadamchik/release/3.1B2/
Re: [VOTE] 3.1B2
Posted by Aristedes Maniatis <ar...@maniatis.org>.
On 8/02/13 6:15am, Andrus Adamchik wrote:
> So, the second Beta is ready and can be found at [1] in its Maven form and at [2] as source and binary assemblies. Please evaluate the release and cast your votes.
>
> Since the docs are still work in progress, I decided not to make it an RC release, but I think we are getting there.
>
> Thanks,
> Andrus
>
> [1] https://repository.apache.org/content/repositories/orgapachecayenne-200/
> [2] http://people.apache.org/~aadamchik/release/3.1B2/
+1
This looks pretty good. I like that the docs are just the pdf with the html linking back to the live site which will be potentially more up to date. I looked through the notices, ran RAT (found some tests and xml not covered, but nothing that I think we care about since a lot of it is trivial config files or java which is regenerated). When RAT 0.9 is released with proper exclusions we can make a more rigorous part of our release process.
So this release looks good, but we should probably perform a triage of the tasks in Jira to see which ones need handling (if any before release) and clean up the others.
Ari
--
-------------------------->
Aristedes Maniatis
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
Re: [VOTE] 3.1B2
Posted by Andrus Adamchik <an...@objectstyle.org>.
On Feb 8, 2013, at 2:46 AM, Aristedes Maniatis <ar...@maniatis.org> wrote:
> Nicely done. Very good time to get this out. I'd like to ask some questions:
>
> 1. Why is the repository folder named the way it is? What doesorgapachecayenne-200 refer to?
This is a semi-opaque unique ID generated by Nexus. This is a temporary staging repo per ASF release procedure doc. Once the vote is complete, these artifacts are propagated to Maven Central, and the temp repo is deleted.
> 2.What are all the things in that folder:
>
> - cayenne-project
> - unpublished (di injection)... why is that in an unpublished folder? I know that comes from the src folder naming, but should that be in the repository?
Unfortunately we have to expose unpublished modules (and cayenne-project that is otherwise packaged inside the Modeler) via Maven for the sake of Cayenne Maven plugins. Maven reorg is certainly in order in 3.2.
> - the tutorials are in a folder called "parents". But the actual Cayenne parent is in a folder called "cayenne-parent"
These I would actually completely exclude from Maven deployment in the future. Also need to check on the pom structure (see Maven reog mention above). All I can remember now is that tutorials needed their own parent, and could not use the common Cayenne parent to stay self-contained and easy to understand by the new users.
> -the top level archetype-catalog.xml is empty
I am not even sure what this file is for. Nexus creates it, it is not ours :)
> 3. What are we reviewing and voting on anyway? The repository items or the items which are built in the usual way and found in p.a.o/~aadamchik?
Per Apache legal requirements, we are voting on http://people.apache.org/~aadamchik/release/3.1B2/cayenne-3.1B2-src.tar.gz - the source distro only. In practical terms we are voting on all of the above together.
Andrus
Re: [VOTE] 3.1B2
Posted by Aristedes Maniatis <ar...@maniatis.org>.
Nicely done. Very good time to get this out. I'd like to ask some questions:
1. Why is the repository folder named the way it is? What doesorgapachecayenne-200 refer to?
2.What are all the things in that folder:
- cayenne-project
- unpublished (di injection)... why is that in an unpublished folder? I know that comes from the src folder naming, but should that be in the repository?
- the tutorials are in a folder called "parents". But the actual Cayenne parent is in a folder called "cayenne-parent"
-the top level archetype-catalog.xml is empty
3. What are we reviewing and voting on anyway? The repository items or the items which are built in the usual way and found in p.a.o/~aadamchik?
Ari Maniatis
On 8/02/13 6:15am, Andrus Adamchik wrote:
> So, the second Beta is ready and can be found at [1] in its Maven form and at [2] as source and binary assemblies. Please evaluate the release and cast your votes.
>
> Since the docs are still work in progress, I decided not to make it an RC release, but I think we are getting there.
>
> Thanks,
> Andrus
>
> [1] https://repository.apache.org/content/repositories/orgapachecayenne-200/
> [2] http://people.apache.org/~aadamchik/release/3.1B2/
>
--
-------------------------->
Aristedes Maniatis
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A