Re: Ant and eclipse related things in the pom.xml

[Mike Kienenberger]

> I remember, you mentioned it before. This is sad.

Yes, the last "new" project we used for Cayenne was in 2018, and that
was pretty much copying a small bit of the code base from my 3.1 app
into a small web service.

Actually, that project is using Cayenne 4.1 and maven.  I  thought
something was, but I had forgotten about this little web service.

On Mon, Aug 1, 2022 at 12:12 PM Andrus Adamchik  wrote:
>
>
>
> > On Aug 1, 2022, at 5:19 PM, Mike Kienenberger  wrote:
> >
> > Unfortunately, my most "up-to-date" cayenne project uses 3.x and it is
> > likely being replaced at the end of the year, which is why I haven't
> > commented much on Cayenne 5.0.
>
> I remember, you mentioned it before. This is sad.
>
> FWIW, we have other orgs migrating their whole codebases *to* Cayenne and 
> also looking at Agrest.io on top of it. So maybe the management needs a fresh 
> pitch? :) Anyways, I am kidding. I am sure it was a conscious decision. It is 
> what it is.
>
> Andrus

Re: Ant and eclipse related things in the pom.xml

[Mike Kienenberger]

[Offlist]

> So maybe the management needs a fresh pitch? :) Anyways, I am kidding. I am 
> sure it was a conscious decision. It is what it is.

Yeah, the management in this case is the current president of the
utility, and he's decided to do away with custom applications
entirely.   Everything is being replaced with an off-the-shelf
product, and, while it's never been admitted out loud, he's probably
doing away with the IT department as well.

4 of the 7 full-time employees have left over the last year, with none
of them being replaced.   I tried to get a straight answer from my
manager back in May as to whether my contract would be renewed at the
end of the year, but while he was effusive about how he planned to
renew my contract, when pressed he couldn't give me any examples of
what I might be working on next year.


On Mon, Aug 1, 2022 at 12:12 PM Andrus Adamchik  wrote:
>
>
>
> > On Aug 1, 2022, at 5:19 PM, Mike Kienenberger  wrote:
> >
> > Unfortunately, my most "up-to-date" cayenne project uses 3.x and it is
> > likely being replaced at the end of the year, which is why I haven't
> > commented much on Cayenne 5.0.
>
> I remember, you mentioned it before. This is sad.
>
> FWIW, we have other orgs migrating their whole codebases *to* Cayenne and 
> also looking at Agrest.io on top of it. So maybe the management needs a fresh 
> pitch? :) Anyways, I am kidding. I am sure it was a conscious decision. It is 
> what it is.
>
> Andrus

Re: Ant and eclipse related things in the pom.xml

[Mike Kienenberger]

Was I the culprit?   I guess I might have been.

It's only used to provide ant support to injecting dependencies into
velocity templates, if I recall correctly.

I'd say drop it.   If it's important to me or to someone else in the
future, we can look into adding it back, but there are probably easier
ways to do these things these days.

Unfortunately, my most "up-to-date" cayenne project uses 3.x and it is
likely being replaced at the end of the year, which is why I haven't
commented much on Cayenne 5.0.

On Mon, Aug 1, 2022 at 3:22 AM Andrus Adamchik  wrote:
>
>
> > On Jul 28, 2022, at 1:44 PM, Nikita Timofeev  
> > wrote:
> >
> > 1. Ant and vpp dependency. This one is really the last that prevents
> > us from switching to the Maven Central repo instead of the custom one
> > we are using, I want to change a bit this feature and use reflection
> > to get rid of compile-time dependency. Is there anything I need to
> > worry about?
>
> IIRC, Mike Kienenberger used (and contributed to) VPP integration. Mike, 
> maybe you have any comments? Is this something you'd still use in the future 
> Cayenne 5.0?
>
> Andrus
>
>

Re: cgen into the future

[Mike Kienenberger]

On Sun, Oct 10, 2021 at 5:09 AM Andrus Adamchik  wrote:

> I expected tools removal to be a controversial proposal. Still decided to
> throw it out there. I am always looking for opportunities to minimize our
> support footprint (hi, ROP :)). Properly maintaining the tools across 3
> build systems is a non-trivial effort (especially Gradle, due to the rest
> of Cayenne being built with Maven). Now we've only increased the footprint,
> as we'd need to be merging map.xml config with build file config. But of
> course I realize that lots of people have designed their Cayenne workflow
> around the build tools (and we encouraged it), and will not appreciate them
> being taken away.
>

I use cgen for more than just generating entity superclasses and
subclasses.   I use it for generating DAO objects, presentation layer
components, validation files, and even entire presentation layer pages in
some cases.   There is at least one internal CRUD app which is 99%
generated from cgen with very little original code.

Re: Cayenne geospacial features

[Mike Kienenberger]

On Sat, Feb 23, 2019 at 4:40 AM Tore Halset  wrote:

> A long time ago, I wrote about this over at
> http://objectstyle.org/confluence/display/CAY/Mapping+JTS+Geometries ,
> but that website does not exist anymore.
>

A google search turned out a mangled version here:

https://grokbase.com/t/cayenne/commits/088bkd5g1s/conf-apache-cayenne-mapping-jts-geometries-page-edited

For some reason it's not in the internet archive wayback machine.

Re: Cayenne release policy thoughts

[Mike Kienenberger]

Take a look at any of my release votes.  I only do the legal bare
minimum when voting for a release in most cases.   Each of my votes
gives the exact steps I take.


On Wed, May 2, 2018 at 4:59 PM, John Huss <johnth...@gmail.com> wrote:
> Thanks Mike,
>
> I wasn't aware of the specifics regard the review, so that is very helpful.
> Are there instructions around for how to verify these things? With a
> specific task list I can probably help with this more than I have before.
>
> I would be in favor of shorter release cycles - 5 years is crazy. I have
> always been using trunk/master versions because I started using Cayenne
> during the 3.2 time frame, so the official releases don't matter much to
> me. But it would be better to release more often.
>
> Thanks,
> John
>
> On Sun, Apr 29, 2018 at 11:44 AM Mike Kienenberger <mkien...@gmail.com>
> wrote:
>
>> All releases (no matter how they are named) must be reviewed by the
>> PMC, but people often forget that the required elements of the review
>> are licenses, signing and checksums, and source code.   The review
>> process could be shorted to just these three easily-evaluated items.
>>
>> The voting period could be shorted as long as each PMC member has a
>> chance to participate, but we have 3 PMC members who aren't currently
>> active, so that might be more difficult to determine.
>>
>>
>> On Sun, Apr 29, 2018 at 2:20 AM, Andrus Adamchik <and...@objectstyle.org>
>> wrote:
>> >> We've typically never added a feature to a x.y release once it is
>> final. But that doesn't have to be a hard and fast rule. For example, we
>> could decide to release 4.0.1 with new features as long as no existing
>> functionality is broken.
>> >
>> > I don't see a problem with that even under the current scheme. It is
>> more of a cost/benefit thing to the core devs, so usually backporting is
>> limited to bug fixes. I'd say in practice someone will need to lobby (or
>> send a PR) for a feature X to be ported to an N - M release.
>> >
>> >> 2. Faster release cycle signifies project health
>> >
>> >
>> > Yep.
>> >
>> >> 3. Separately versioned modeler
>> >> If the modeler was able to save older versions of the schema, then
>> there would be no need to maintain older branches for that app and it could
>> move forward more quickly without maintenance of old branches.
>> >
>> > That's be great in theory, though in practice it will actually result in
>> *more* maintenance and testing, as we'd need to handle the whole spectrum
>> of (possibly conflicting) model capabilities in the same version of the
>> tool. We may try to provide "Save as version N -M" option though. Not sure
>> if that is a helpful scenario.
>> >
>> >> 4. More lightweight alpha releases
>> >>
>> >> To make it quick and easy to cut development milestones, can we skip
>> the PMC voting process and go for something slightly less formal. Betas and
>> release candidates would have the full review process. Or even just have an
>> expedited 24 hour voting period.
>> >
>> > I don't think we can do this as an Apache project. All releases must be
>> approved by the PMC, and there's no wiggle room on that. IIRC there was
>> even pushback against posting direct CI links on the project website.
>> >
>> > Andrus
>> >
>> >
>> >
>> >
>> >> On Apr 28, 2018, at 2:50 PM, Aristedes Maniatis <a...@maniatis.org>
>> wrote:
>> >>
>> >> 1. More releases means more patching and releasing of bug fixes to
>> different branches.
>> >>
>> >> To understand the impact of this we need to consider what a new release
>> means and how many old releases we need to support.
>> >>
>> >> * API change
>> >>
>> >> * new features added
>> >>
>> >> * deprecated methods removed
>> >>
>> >> We've typically never added a feature to a x.y release once it is
>> final. But that doesn't have to be a hard and fast rule. For example, we
>> could decide to release 4.0.1 with new features as long as no existing
>> functionality is broken. Or conversely we could call it 4.1, but no longer
>> provide bug fixes for 4.0, requiring users to upgrade to get those fixes as
>> long as that upgrade doesn't require the user to change any code in their
>> app.
>> >>
>> >> So what is the balance between providing old bug fix releases and being
>>

Re: Cayenne release policy thoughts

[Mike Kienenberger]

All releases (no matter how they are named) must be reviewed by the
PMC, but people often forget that the required elements of the review
are licenses, signing and checksums, and source code.   The review
process could be shorted to just these three easily-evaluated items.

The voting period could be shorted as long as each PMC member has a
chance to participate, but we have 3 PMC members who aren't currently
active, so that might be more difficult to determine.


On Sun, Apr 29, 2018 at 2:20 AM, Andrus Adamchik  wrote:
>> We've typically never added a feature to a x.y release once it is final. But 
>> that doesn't have to be a hard and fast rule. For example, we could decide 
>> to release 4.0.1 with new features as long as no existing functionality is 
>> broken.
>
> I don't see a problem with that even under the current scheme. It is more of 
> a cost/benefit thing to the core devs, so usually backporting is limited to 
> bug fixes. I'd say in practice someone will need to lobby (or send a PR) for 
> a feature X to be ported to an N - M release.
>
>> 2. Faster release cycle signifies project health
>
>
> Yep.
>
>> 3. Separately versioned modeler
>> If the modeler was able to save older versions of the schema, then there 
>> would be no need to maintain older branches for that app and it could move 
>> forward more quickly without maintenance of old branches.
>
> That's be great in theory, though in practice it will actually result in 
> *more* maintenance and testing, as we'd need to handle the whole spectrum of 
> (possibly conflicting) model capabilities in the same version of the tool. We 
> may try to provide "Save as version N -M" option though. Not sure if that is 
> a helpful scenario.
>
>> 4. More lightweight alpha releases
>>
>> To make it quick and easy to cut development milestones, can we skip the PMC 
>> voting process and go for something slightly less formal. Betas and release 
>> candidates would have the full review process. Or even just have an 
>> expedited 24 hour voting period.
>
> I don't think we can do this as an Apache project. All releases must be 
> approved by the PMC, and there's no wiggle room on that. IIRC there was even 
> pushback against posting direct CI links on the project website.
>
> Andrus
>
>
>
>
>> On Apr 28, 2018, at 2:50 PM, Aristedes Maniatis  wrote:
>>
>> 1. More releases means more patching and releasing of bug fixes to different 
>> branches.
>>
>> To understand the impact of this we need to consider what a new release 
>> means and how many old releases we need to support.
>>
>> * API change
>>
>> * new features added
>>
>> * deprecated methods removed
>>
>> We've typically never added a feature to a x.y release once it is final. But 
>> that doesn't have to be a hard and fast rule. For example, we could decide 
>> to release 4.0.1 with new features as long as no existing functionality is 
>> broken. Or conversely we could call it 4.1, but no longer provide bug fixes 
>> for 4.0, requiring users to upgrade to get those fixes as long as that 
>> upgrade doesn't require the user to change any code in their app.
>>
>> So what is the balance between providing old bug fix releases and being able 
>> to move forward more quickly? saltstack is an example of a software project 
>> that adds new features from 2018.3.0 to 2018.3.1, but doesn't change 
>> existing functionality.
>>
>>
>> 2. Faster release cycle signifies project health
>>
>> Developers will look at the number of releases per year as a measurement of 
>> project health. So more releases are a good thing.
>>
>>
>> 3. Separately versioned modeler
>>
>> If the modeler was able to save older versions of the schema, then there 
>> would be no need to maintain older branches for that app and it could move 
>> forward more quickly without maintenance of old branches.
>>
>>
>> 4. More lightweight alpha releases
>>
>> To make it quick and easy to cut development milestones, can we skip the PMC 
>> voting process and go for something slightly less formal. Betas and release 
>> candidates would have the full review process. Or even just have an 
>> expedited 24 hour voting period.
>>
>>
>> Just a few thoughts. For our own projects we've been using milestone Cayenne 
>> releases in production for as long as I can remember, so I certainly like 
>> the idea of formalising them into shorter release cycles, particularly now 
>> that most of the disruptive (to users) changes in the API over the last 
>> years are probably behind us.
>>
>>
>> Ari
>>
>>
>>
>> On 28/4/18 8:50pm, Nikita Timofeev wrote:
>>> Hi all,
>>>
>>> Wanted to share my thoughts about our release policy.
>>>
>>> I think it will be better for Cayenne to reduce scopes of future
>>> releases, as not many users are ready to use milestone or even beta
>>> releases. At the same time we can't create final release if there are
>>> a lot of new things, because of long feedback cycle.
>>> Good example of this problem 

Re: Cayenne 4.0.RC1 release

[Mike Kienenberger]

Assuming that the slf4j-api.jar file isn't a showstopper,

- signatures and checksums match
- source builds
- apache rat passes

+1






Below are the linux commands I used to verify the release of the
cayenne-4.0.RC1 files:

=

wget 
https://dist.apache.org/repos/dist/dev/cayenne/4.0.RC1/cayenne-4.0.RC1-macosx.dmg
wget 
https://dist.apache.org/repos/dist/dev/cayenne/4.0.RC1/cayenne-4.0.RC1-macosx.dmg.asc
wget 
https://dist.apache.org/repos/dist/dev/cayenne/4.0.RC1/cayenne-4.0.RC1-macosx.dmg.md5
wget 
https://dist.apache.org/repos/dist/dev/cayenne/4.0.RC1/cayenne-4.0.RC1-src.tar.gz
wget 
https://dist.apache.org/repos/dist/dev/cayenne/4.0.RC1/cayenne-4.0.RC1-src.tar.gz.asc
wget 
https://dist.apache.org/repos/dist/dev/cayenne/4.0.RC1/cayenne-4.0.RC1-src.tar.gz.md5
wget 
https://dist.apache.org/repos/dist/dev/cayenne/4.0.RC1/cayenne-4.0.RC1-win.zip
wget 
https://dist.apache.org/repos/dist/dev/cayenne/4.0.RC1/cayenne-4.0.RC1-win.zip.asc
wget 
https://dist.apache.org/repos/dist/dev/cayenne/4.0.RC1/cayenne-4.0.RC1-win.zip.md5
wget 
https://dist.apache.org/repos/dist/dev/cayenne/4.0.RC1/cayenne-4.0.RC1.tar.gz
wget 
https://dist.apache.org/repos/dist/dev/cayenne/4.0.RC1/cayenne-4.0.RC1.tar.gz.asc
wget 
https://dist.apache.org/repos/dist/dev/cayenne/4.0.RC1/cayenne-4.0.RC1.tar.gz.md5

# check checksums
## made with  gpg --print-md MD5 cayenne-X.X.tar.gz
cat *.md5 | tr -d ' ' | awk 'BEGIN{OFS=" "; FS=":"}
{tmp=$1;$1=$2;$2=tmp;print}' | md5sum -c

# check signatures
wget http://www.apache.org/dist/cayenne/KEYS
gpg --import KEYS
find . -name '*.asc' -exec gpg --verify {} \;

# verify .tar.gz and -win.zip files are identical -- flawed process
due to platform building differences
mkdir src
cd src
tar xvf ../cayenne-4.0.RC1.tar.gz
mv cayenne-4.0.RC1/ cayenne-4.0.RC1-tar-gz
unzip ../cayenne-4.0.RC1-win.zip
# should be no output
# but windows and tar package are built with different java versions.
## differences in jars, pdfs, html, exe resources; whitespace diffs
for js, css, package-list between tar.gz and zip(win)
diff -rq cayenne-4.0.RC1* | grep -v "jar differ" | grep -v "html
differ" | grep -v "package-list differ" | grep -v "script.js" | grep
-v "pdf differ" | grep -v ".css differ"
# should be "are identical" output except for exe
diff -wsrq cayenne-4.0.RC1* | grep -v "jar differ" | grep -v "html
differ" | grep -v "pdf differ" | grep -v "are identical"



# unpack source
tar xvzf ../cayenne-4.0.RC1-src.tar.gz
# build source
cd cayenne-4.0.RC1-src
mvn install

## mvn apache-rat currently unused for cayenne
# manually verify that there are no unknown or unapproved licensed files
./rat.sh ../../../../java/apache-rat-0.11/apache-rat-0.11.jar
##mvn apache-rat:check
# To check for all errors, if more than one project is affected
#   mvn apache-rat:check -Drat.numUnapprovedLicenses=
# To see details of rat failure
#   mvn -e -X apache-rat:check




On Sat, Apr 21, 2018 at 9:43 AM, Mike Kienenberger <mkien...@gmail.com> wrote:
> Checking the release.  Why does slf4j-api-1.7.25.jar exist in
> cayenne-4.0.RC1-tar-gz but not in cayenne-4.0.RC1-win.zip?
>
> # diff -rq cayenne-4.0.RC1-tar-gz/ cayenne-4.0.RC1-win/
> [...]
> Only in cayenne-4.0.RC1-tar-gz/lib/third-party: slf4j-api-1.7.25.jar
> [...]

Re: Cayenne 4.0.RC1 release

[Mike Kienenberger]

Checking the release.  Why does slf4j-api-1.7.25.jar exist in
cayenne-4.0.RC1-tar-gz but not in cayenne-4.0.RC1-win.zip?

# diff -rq cayenne-4.0.RC1-tar-gz/ cayenne-4.0.RC1-win/
[...]
Only in cayenne-4.0.RC1-tar-gz/lib/third-party: slf4j-api-1.7.25.jar
[...]

Re: H2 rev engineer

[Mike Kienenberger]

I use H2 as my test environment (alternative to the Oracle instances
used for production) as it is almost drop-in compatible with Oracle.
I almost always use it in file mode, though.   I have used it in
tcp/ip mode a few times without issue.

I never have used the run script classes.

I recommend you try using the url format I sent you before that runs
it in file mode.  That will help you determine if the problem is
entirely with your tcp server setup (if it works in file mode but not
tcp/ip mode) or if there's some more general problem.

Also, I'm using H2 with JPA not Cayenne.   For my legacy Cayenne
project, I use HSQLDB for testing and a development oracle
environment.   So if there's some H2/Cayenne interaction that's
causing your problem, I can't help with that.   The H2 developer has
always been good responding to questions posted on the support
channels, though, especially if you can reduce the problem to
something specific to H2.





On Tue, Oct 24, 2017 at 8:30 AM, Andrus Adamchik <and...@objectstyle.org> wrote:
> This unfortunately goes way beyond my H2 knowledge. H2 is good for small 
> tests in embedded mode, but I never tried running it as a server.
>
> Since you are no longer embedding it, is there a reason to use H2 to begin 
> with? You can run MySQL or PostgreSQL on Docker or something.
>
> Andrus
>
>> On Oct 20, 2017, at 7:54 PM, Tony Giaccone <tgiacc...@gmail.com> wrote:
>>
>> Mike & Andrus,
>>
>> Thanks for your help you got me a bit closer.
>>
>> So one step forward.. but not quite there.
>>
>> So, here's the path now...
>>
>> In the first shell:
>>
>> $ java -cp bin/h2*.jar org.h2.tools.Server -tcp -tcpAllowOthers
>>
>> In a second shell
>>
>> java -cp h2*.jar org.h2.tools.RunScript -url
>> "jdbc:h2:tcp://localhost/mem:test" -user sa -script ../script.sql
>>
>>
>> This works. The SQL in the script.sql gets executed and I can connect with
>> Squirrel nwith the following URL:
>>
>> jdbc:h2:tcp://localhost/mem:test;MVCC=TRUE
>>
>> I can view the changes. New Schema's are present, new tables, selects
>> against the tables get the correct number of rows.  All done using Squirrel.
>>
>> I then go to Cayenne Modeller and try to connect for rev engineering.
>>
>> When I look at the log file, it's show's that it's connecting to the DB
>> succesfully...
>>
>> Oct 20, 2017 12:45:58 PM INFO: Connecting to
>> 'jdbc:h2:tcp://localhost/mem:test;MVCC=TRUE;' as 'sa'
>> Oct 20, 2017 12:45:58 PM INFO: +++ Connecting: SUCCESS.
>> Oct 20, 2017 12:45:58 PM INFO: Connecting to
>> 'jdbc:h2:tcp://localhost/mem:test;MVCC=TRUE;' as 'sa'
>> Oct 20, 2017 12:45:58 PM INFO: +++ Connecting: SUCCESS.
>> Oct 20, 2017 12:45:58 PM INFO: Connecting to
>> 'jdbc:h2:tcp://localhost/mem:test;MVCC=TRUE;' as 'sa'
>> Oct 20, 2017 12:45:58 PM INFO: +++ Connecting: SUCCESS.
>>
>> But the modeller puts up a dialog:
>>
>> Connection is broken: "unexpected status 16777216 [90067-192]
>>
>> And that's it, nothing more happens.
>>
>>
>> Now I should also point out that Squirrel also puts up a dialog box on
>> connection:
>>
>> Error occurred during task execution:
>> for input string: "127.0.0.1:9092"
>>
>> But when I dismiss that error and examine the log file, it shows:
>>
>> Caused by: java.lang.NumberFormatException: For input string: "
>> 127.0.0.1:9092"
>>at
>> java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
>>at java.lang.Integer.parseInt(Integer.java:580)
>>at java.lang.Integer.valueOf(Integer.java:740)
>>at java.lang.Integer.decode(Integer.java:1197)
>>at org.h2.tools.SimpleResultSet.getInt(SimpleResultSet.java:709)
>>
>>
>> But Squirrel continues on and manages to read the object tree and execute
>> SQL against the db.
>>
>>
>> Tony
>>
>>
>>
>> On Fri, Oct 20, 2017 at 12:04 PM, Mike Kienenberger <mkien...@gmail.com>
>> wrote:
>>
>>> I see a couple of possible reasons:
>>>
>>> First I would guess that "jdbc:h2:mem" is creating a separate
>>> in-memory database rather than using your tcp-served db.
>>>
>>> Second, you might need to specify your non-standard schemas like as
>>> follows.
>>>
>>> Below is a url I use modified for what values you provided:
>>>
>>> jdbc:h2:tcp://localhost/;AUTO_SERVER=TRUE;MVCC
>>> =TRUE;SCHEMA_SEARCH_PATH=CORE_OPERATION
>>>
>>> On Fri, Oct 20, 2017 at 11:5

Re: H2 rev engineer

[Mike Kienenberger]

I see a couple of possible reasons:

First I would guess that "jdbc:h2:mem" is creating a separate
in-memory database rather than using your tcp-served db.

Second, you might need to specify your non-standard schemas like as follows.

Below is a url I use modified for what values you provided:

jdbc:h2:tcp://localhost/;AUTO_SERVER=TRUE;MVCC=TRUE;SCHEMA_SEARCH_PATH=CORE_OPERATION

On Fri, Oct 20, 2017 at 11:55 AM, Tony Giaccone  wrote:
> I created an H2 database, using our standard SQL. Now I'd like to
> rev-engineer that db with cayenne, but the schema doesn't show up in the
> modeler.
>
> To reproduce this problem, I follow these steps:
>
> $ java -cp bin/h2*.jar org.h2.tools.Server -tcp -tcpAllowOthers
>
> this creates a H2 database.
>
> I connect with Squirrel SQL Client
> driver: org.h2.Driver
> URL: jdbc:h2:mem:test;MVCC=TRUE
>
> This connects to the H2 Db, where I execute
>
> CREATE SCHEMA IF NOT EXISTS CORE AUTHORIZATION SA;
>
> This creates the new schema which, when I refresh the tree in squirrel, is
> displayed.
>
> I then try to rev-engineer with the cayenne modeler 4.1.M1
>
> Only two schema's show up in the modeler drop down, INFORMATION_SCHEMA and
> PUBLIC the newly created  schema  CORE is not in the list.
>
>
> Any Suggestions?
>
>
> Tony Giaccone

Re: Cayenne own template renderer to replace Velocity

[Mike Kienenberger]

Just a note that Velocity 2.0 is finally released.
If I remember right, lots of dependency fixes there too.

On Mon, Aug 14, 2017 at 8:21 AM, Andrus Adamchik  wrote:
>> If we choose a 'provided' scope, won't that work and be better?
>
> I think it will be worse. Velocity is not like servlet spec jar or something 
> that comes from a container (and less and less ppl are using containers 
> anyways nowadays). The result of making it "provided" will be that our 
> library will no longer work out of the box, forcing the user to actively do 
> something about it. First they will need to realize that Velocity is required 
> in the first place, then they need to figure out which version to use.
>
> Only the users who already have Velocity in their system would care to 
> override the version. And they can either user the exclude, or just import 
> Velocity explicitly, which would take precedence over transient dependency.
>
> Nobody reads the docs these days, things need to work out of the box :)
>
> Andrus
>
>
>> On Aug 14, 2017, at 3:07 PM, Michael Gentry  wrote:
>>
>> Yes, but that's us kind of forcing a version of Velocity upon our users
>> rather than them choosing the version that works with their environment.
>> Sure, they can do dependency exclusions, etc, in the POM, but that's a
>> slight hassle.  If we choose a 'provided' scope, won't that work and be
>> better?  It'll be up to them to include the version of Velocity they want
>> in their POM and there won't be multiple versions provided, at least not
>> due to us.
>>
>> Thanks,
>>
>> mrg
>>
>>
>> On Mon, Aug 14, 2017 at 7:35 AM, Nikita Timofeev 
>> wrote:
>>
>>> Cayenne-velocity module should use version of Velocity we specify, the
>>> main point is that cayenne-server won't use it anymore.
>>> As for explicit "compile" scope that's just copy-past, it can be
>>> omitted as it's default anyway.
>>>
>>> On Mon, Aug 14, 2017 at 2:16 PM, Michael Gentry 
>>> wrote:
 Won't a compile scope pull in a version of Velocity we specify?

 https://github.com/apache/cayenne/pull/238/files#diff-
>>> e286320b0b1da27d2621bf787ddd75b1R48


 On Fri, Aug 11, 2017 at 7:23 AM, Andrus Adamchik > I'm assuming the template engine will be injectable
>
> Yes, and even better. With module auto-loading, you simply put your
> template engine jar on classpath, and you get it installed
>>> automatically.
> This is how backwards-compatible cayenne-velocity will operate.
>
> Andrus
>
>
>> On Aug 11, 2017, at 2:21 PM, Michael Gentry 
>>> wrote:
>>
>> I haven't looked into the details, but I like the idea of reducing
>> dependencies upon external libraries, which can cause headaches with
>> applications using Cayenne.
>>
>> I'm assuming the template engine will be injectable so that you can
> choose
>> Velocity, Freemarker, etc if you'd like?  (Of course, you might have
>>> to
>> create a bridge to your template engine of choice, but be able to
>>> inject
>> that bridge into Cayenne.)
>>
>> Thanks,
>>
>> mrg
>>
>>
>> On Thu, Aug 10, 2017 at 5:35 AM, Nikita Timofeev <
> ntimof...@objectstyle.com>
>> wrote:
>>
>>> Hi all,
>>>
>>> I've opened a PR [1] just now with new SQLTemplateProcessor
>>> implementation based on new Cayenne own parser (instead of Velocity).
>>>
>>> It doesn't support all features of Velocity but it's enough to
>>> seamlessly replace Velocity in all core and test code in Cayenne,
>>> plus
>>> it's faster (up to x15 in case of cache hit) and should have less
>>> memory footprint (though I've only checked speed and memory is my
>>> guess as new parser smaller and have no runtime).
>>>
>>> Plus cayenne-server now free of velocity and commons-lang
>>> dependencies, next step will be removing of commons-collections (it
>>> will be the last one).
>>>
>>> VelocitySQLTemplateProcessor now comes in optional auto-loaded module
>>> (cayenne-velocity), so if you relied on some advanced features of
>>> Velocity in your SQLTemplates you still can use it. And Velocity is
>>> still used for cgen templates.
>>>
>>> See PR [1] and Jira ticket [2] for details.
>>>
>>> Any thoughts or concerns?
>>>
>>> [1] https://github.com/apache/cayenne/pull/238
>>> [2] https://issues.apache.org/jira/browse/CAY-2345
>>>
>>> --
>>> Best regards,
>>> Nikita Timofeev
>>>
>
>
>>>
>>>
>>>
>>> --
>>> Best regards,
>>> Nikita Timofeev
>>>
>

Re: June 2017 Board Report

[Mike Kienenberger]

Remember that the board cares about community development far more
than technical development.
They'd be more interested in how the CM prototype is affecting community.

On Sat, Jun 10, 2017 at 9:06 AM, Michael Gentry  wrote:
> On Sat, Jun 10, 2017 at 8:55 AM, Andrus Adamchik 
> wrote:
>
>> >  The only thing that comes to my mind is *maybe* mention the CM
>> prototype [1],
>>
>> Certainly you can mention it for our own sake. The Board does not care one
>> way or the other though.
>>
>
> Yeah, it doesn't seem that worthy to me (yet).

Re: Switching Cayenne to SLF4J

[Mike Kienenberger]

On Mon, Mar 27, 2017 at 6:20 PM, Aristedes Maniatis  wrote:
> * using log4j or other library

Pick one logging library (ie, log4j).  Add the "log to log4j from slf4j" jar.
For all other logging libraries, add "log to slf4j from *" jars.

It's pretty much that simple, although really badly designed logging
libraries like java.util.logging may require extra steps or run
poorly.


> * having other libraries in the classpath with different versions of slf4j

the slf4j api is pretty much backward compatible no matter what
version you use, and jars don't inline slf4j.   So you can just pick
whatever version you like, generally the latest slf4j version
available.

Re: March 2017 Board Report

[Mike Kienenberger]

You'll be told to remove the mailing list statistics unless they are
showing something important, in which case you want to specifically
state it (such as saying that we've had a dramatic increase in mailing
list participation recently).


Also, I'd change "No activity" for 3.x to "In maintenance mode"

On Thu, Mar 9, 2017 at 6:10 PM, Michael Gentry  wrote:
> As always, please provide any feedback you might have before I submit it.
>
> Thanks,
>
> mrg
>
>
> ## Description:
>
> Apache Cayenne is a Java database persistence framework. It takes a
> distinct approach to object persistence and provides an ORM runtime,
> remote persistence services, and a GUI mapping/modeling tool.
>
>
> ## Issues:
>
> There are no issues requiring board attention at this time.
>
>
> ## Activity:
>
> - Cayenne 3.1 (stable)
>   - No activity.
>
> - Cayenne 4.0 (development)
>   - This is where all current development effort is taking place.
> We just released a new milestone, which we hope to be our final
> milestone release before going into beta.
>
>
> ## Health report:
>
> Cayenne is still under active development and has a stable user and
> developer community.
>
>
> ## PMC changes:
>
> - Currently 8 PMC members.
> - No new PMC members added in the last 3 months.
> - Last PMC addition was Savva Kolbachev on Tue Apr 12 2016.
>
>
> ## Committer base changes:
>
> - Currently 21 committers.
> - Nikita Timofeev was added as a committer on Fri Dec 23 2016
>
>
> ## Releases:
>
> - Cayenne 4.0.M5 was announced on Mon Mar 6 2016.
>
>
> ## Mailing list activity:
>
> - dev@cayenne.apache.org:
>   - 128 subscribers (up 0 in the last 3 months)
>   - 168 emails sent to list (81 in previous quarter)
>
> - u...@cayenne.apache.org:
>   - 250 subscribers (up 1 in the last 3 months)
>   - 208 emails sent to list (96 in previous quarter)
>
>
> ## JIRA activity:
>
> - 96 JIRA tickets created in the last 3 months
> - 82 JIRA tickets closed/resolved in the last 3 months

Re: [VOTE] 4.0.M5 release v2

[Mike Kienenberger]

It seems like it may make more sense to change the version to M6 rather
than create M5-v2 and have to deal with potential confusion.

On Fri, Feb 24, 2017 at 3:54 AM, Nikita Timofeev 
wrote:

> Hi all,
>
> I'm published new files for 4.0.M5 release and you can start voting
> (again).
> The only difference should be fix for CAY-2242.
>
> Here are links:
> Maven: https://repository.apache.org/content/repositories/
> orgapachecayenne-1013
> Assemblies: https://dist.apache.org/repos/dist/dev/cayenne/4.0.M5/
>
> Sorry for inconvenience, hope this one will be promoted to the official
> release.
>
> --
> Best regards,
> Nikita Timofeev
>

Re: Build failure

[Mike Kienenberger]

One of the classes (probably from the postgres driver) was compiled with a
java version higher than what is running the build.


On Thu, Dec 22, 2016 at 1:26 PM, buddha  wrote:

> Hi,
>
>
>
> I’m just trying to make a small commit which is a fix in two small xml
> files that generate html files for documentation. Created a pull
> request(#170), however continuous integration is failing. The change I did
> has nothing to do with the failure of the build. Build is failing with
> (Caused by: java.lang.UnsupportedClassVersionError: org/postgresql/Driver
> : Unsupported major.minor version 52.0)
>
>
>
> https://travis-ci.org/apache/cayenne/builds/186140745
>
>
>
> Can someone help me out as to what the issue is?
>
>
>
> Thanks
>
> Buddha
>
>

Re: [VOTE] 4.0.M4

[Mike Kienenberger]

- signatures and checksums match
- source builds
- apache rat passes

+1






Below are the linux commands I used to verify the release of the
cayenne-4.0.M4 files:

=

wget 
https://dist.apache.org/repos/dist/dev/cayenne/4.0.M4/cayenne-4.0.M4-macosx.dmg
wget 
https://dist.apache.org/repos/dist/dev/cayenne/4.0.M4/cayenne-4.0.M4-macosx.dmg.asc
wget 
https://dist.apache.org/repos/dist/dev/cayenne/4.0.M4/cayenne-4.0.M4-macosx.dmg.md5
wget 
https://dist.apache.org/repos/dist/dev/cayenne/4.0.M4/cayenne-4.0.M4-src.tar.gz
wget 
https://dist.apache.org/repos/dist/dev/cayenne/4.0.M4/cayenne-4.0.M4-src.tar.gz.asc
wget 
https://dist.apache.org/repos/dist/dev/cayenne/4.0.M4/cayenne-4.0.M4-src.tar.gz.md5
wget 
https://dist.apache.org/repos/dist/dev/cayenne/4.0.M4/cayenne-4.0.M4-win.zip
wget 
https://dist.apache.org/repos/dist/dev/cayenne/4.0.M4/cayenne-4.0.M4-win.zip.asc
wget 
https://dist.apache.org/repos/dist/dev/cayenne/4.0.M4/cayenne-4.0.M4-win.zip.md5
wget https://dist.apache.org/repos/dist/dev/cayenne/4.0.M4/cayenne-4.0.M4.tar.gz
wget 
https://dist.apache.org/repos/dist/dev/cayenne/4.0.M4/cayenne-4.0.M4.tar.gz.asc
wget 
https://dist.apache.org/repos/dist/dev/cayenne/4.0.M4/cayenne-4.0.M4.tar.gz.md5

# check checksums
## made with  gpg --print-md MD5 cayenne-X.X.tar.gz
cat *.md5 | tr -d ' ' | awk 'BEGIN{OFS=" "; FS=":"}
{tmp=$1;$1=$2;$2=tmp;print}' | md5sum -c

# check signatures
wget http://www.apache.org/dist/cayenne/KEYS
gpg --import KEYS
find . -name '*.asc' -exec gpg --verify {} \;

# verify .tar.gz and -win.zip files are identical -- flawed process
due to platform building differences
mkdir src
cd src
tar xvf ../cayenne-4.0.M4.tar.gz
mv cayenne-4.0.M4/ cayenne-4.0.M4-tar-gz
unzip ../cayenne-4.0.M4-win.zip
# should be no output
# but windows and tar package are built with different java versions.
## differences in jars, pdfs, html resources, css, html, package-info
between tar.gz and zip(win)
diff -rq cayenne-4.0.M4* | grep -v "jar differ" | grep -v "html
differ" | grep -v "pdf differ" | grep -v ".css differ"
# should be "are identical" output
diff -srq cayenne-4.0.M4* | grep -v "jar differ" | grep -v "html
differ" | grep -v "pdf differ" | grep -v ".css differ" | grep -v "are
identical"

# unpack source
tar xvzf ../cayenne-4.0.M4-src.tar.gz
# build source
cd cayenne-4.0.M4-src
mvn install

## mvn apache-rat currently unused for cayenne
# manually verify that there are no unknown or unapproved licensed files
./rat.sh ../../../../java/apache-rat-0.11/apache-rat-0.11.jar
##mvn apache-rat:check
# To check for all errors, if more than one project is affected
#   mvn apache-rat:check -Drat.numUnapprovedLicenses=
# To see details of rat failure
#   mvn -e -X apache-rat:check


On Tue, Dec 6, 2016 at 10:26 AM, Savva Kolbachev  wrote:
> Hi All,
> I'm glad to tell you that I've prepared 4.0.M4 artifacts for voting.
>
> Maven artifacts:
> https://repository.apache.org/content/repositories/orgapachecayenne-1011/
> Assemblies: https://dist.apache.org/repos/dist/dev/cayenne/4.0.M4/
>
> Please evaluate and cast your votes.
>
> --
> Best Regards,
> Savva Kolbachev

Re: December 2016 Board Report

[Mike Kienenberger]

Looks good

On Sat, Dec 10, 2016 at 7:20 AM, Michael Gentry  wrote:
> Per Andrus' suggestion, removed ICLA language and added Ruslan:
>
> ## Committer base changes:
>
> - Currently 20 committers.
> - No new committers added in the last 3 months.
> - Last committer addition was Savva Kolbachev at Mon Jan 19 2015.
>
> We'd also like to note that Nikita Timofeev and Ruslan Ibragimov,
> while not direct Cayenne committers, have been making many needed
> and welcomed improvements to Cayenne recently and we appreciate
> their contributions to the project.
>
>
> On Fri, Dec 9, 2016 at 6:03 PM, Michael Gentry  wrote:
>
>> For review.  Please add comments if you have them.
>>
>> Thanks,
>>
>> mrg
>>
>>
>>
>> ## Description:
>>
>> Apache Cayenne is a Java database persistence framework. It takes a
>> distinct approach to object persistence and provides an ORM runtime,
>> remote persistence services, and a GUI mapping/modeling tool.
>>
>>
>> ## Issues:
>>
>> There are no issues requiring board attention at this time.
>>
>>
>> ## Activity:
>>
>> There were no releases on the stable (3.1) or alpha (4.0) branches this
>> past reporting period, however there has been significant activity
>> resolving issues in preparation for a 4.0.M4 release, which is currently
>> being evaluated and voted upon.
>>
>>
>> ## Health report:
>>
>> Cayenne is still under active development and has a stable user and
>> developer community.
>>
>>
>> ## PMC changes:
>>
>>  - Currently 8 PMC members.
>>  - No new PMC members added in the last 3 months.
>>  - Last PMC addition was Savva Kolbachev on Tue Apr 12 2016.
>>  - PMC members decided it would be good to rotate the PMC Chair
>>from time-to-time and voted to change PMC Chair from Andrus
>>Adamchik to Michael Gentry (vote closed Mon Oct 17 2016).
>>
>>
>> ## Committer base changes:
>>
>>  - Currently 20 committers.
>>  - No new committers added in the last 3 months.
>>  - Last committer addition was Savva Kolbachev at Mon Jan 19 2015.
>>
>> It should be noted that Nikita Timofeev, who recently had his ICLA filed,
>> has been making many improvements to Cayenne recently, even though he is
>> not an official Cayenne contributor yet.
>>
>>
>> ## Releases:
>>
>>  - Last release was 4.0.M3 on Thu Feb 11 2016
>>
>> We hope to have 4.0.M4 released this month.
>>
>>
>> ## Mailing list activity:
>>
>>  - dev@cayenne.apache.org:
>> - 125 subscribers (up 1 in the last 3 months).
>> - 85 emails sent to list (43 in previous quarter).
>>
>>  - u...@cayenne.apache.org:
>> - 248 subscribers (up 2 in the last 3 months).
>> - 94 emails sent to list (177 in previous quarter).
>>
>>
>> ## JIRA activity:
>>
>>  - 51 JIRA tickets created in the last 3 months.
>>  - 33 JIRA tickets closed/resolved in the last 3 months.
>>
>>

Re: September 2016 Board Report

[Mike Kienenberger]

Oh, and you may as well drop the mailing list statistics as the board
doesn't want them unless they are being used to illustrate a
particular point.  But maybe that's what you meant by summer lull, in
which case you can disregard both of my comments :)

On Tue, Sep 13, 2016 at 8:41 PM, Mike Kienenberger <mkien...@gmail.com> wrote:
> Looks pretty good to me.  Although I'm not really sure there was a
> lull.  At least I didn't notice any lull in cayenne activity.
>
> On Tue, Sep 13, 2016 at 8:17 PM, Michael Gentry <blackn...@gmail.com> wrote:
>> Any feedback on the following?  Needs to be submitted tomorrow (9/14).
>>
>> Thanks!
>>
>> mrg
>>
>>
>>
>> ## Description:
>> Apache Cayenne is a Java persistence framework. It takes a distinct
>> approach to object persistence and provides an ORM runtime, remote
>> persistence services, and a GUI mapping/modeling tool.
>>
>> ## Issues:
>> There are no issues requiring board attention at this time.
>>
>> ## Activity:
>> There were no releases on the stable (3.1) or alpha (4.0) branches this
>> past reporting period.  Most effort was directed to 4.0 development
>> (expecially Remote Object Persistence - ROP) and bug fixes, environmental
>> updates (such as fixing build failures), and mailing list support.
>>
>> ## Health report:
>> Cayenne is still under active development and mailing list activity
>> indicates we have an active and stable community, although with a
>> summer vacation lull.
>>
>> ## PMC changes:
>>  - Currently 8 PMC members.
>>  - No new PMC members added in the last 3 months
>>  - Last PMC addition was Savva Kolbachev on Tue Apr 12 2016
>>
>> ## Committer base changes:
>>  - Currently 20 committers.
>>  - No new committers added in the last 3 months
>>  - Last committer addition was Savva Kolbachev at Mon Jan 19 2015
>>
>> ## Releases:
>>  - Last stable release was 3.1.1 on Mon May 16 2016
>>  - Last milestone release was 4.0.M3 on Fri February 12 2016
>>
>> ## Mailing list activity:
>> Mailing list activity was lower than normal for development, likely due to
>> summer vacations and other scheduling demands.  Activity on the user list
>> was near normal.
>>
>>  - dev@cayenne.apache.org:
>> - 124 subscribers (up 1 in the last 3 months):
>> - 44 emails sent to list (120 in previous quarter)
>>
>>  - u...@cayenne.apache.org:
>> - 247 subscribers (up 4 in the last 3 months):
>> - 172 emails sent to list (185 in previous quarter)
>>
>> ## JIRA activity:
>>  - 21 JIRA tickets created in the last 3 months
>>  - 17 JIRA tickets closed/resolved in the last 3 months

Re: September 2016 Board Report

[Mike Kienenberger]

Looks pretty good to me.  Although I'm not really sure there was a
lull.  At least I didn't notice any lull in cayenne activity.

On Tue, Sep 13, 2016 at 8:17 PM, Michael Gentry  wrote:
> Any feedback on the following?  Needs to be submitted tomorrow (9/14).
>
> Thanks!
>
> mrg
>
>
>
> ## Description:
> Apache Cayenne is a Java persistence framework. It takes a distinct
> approach to object persistence and provides an ORM runtime, remote
> persistence services, and a GUI mapping/modeling tool.
>
> ## Issues:
> There are no issues requiring board attention at this time.
>
> ## Activity:
> There were no releases on the stable (3.1) or alpha (4.0) branches this
> past reporting period.  Most effort was directed to 4.0 development
> (expecially Remote Object Persistence - ROP) and bug fixes, environmental
> updates (such as fixing build failures), and mailing list support.
>
> ## Health report:
> Cayenne is still under active development and mailing list activity
> indicates we have an active and stable community, although with a
> summer vacation lull.
>
> ## PMC changes:
>  - Currently 8 PMC members.
>  - No new PMC members added in the last 3 months
>  - Last PMC addition was Savva Kolbachev on Tue Apr 12 2016
>
> ## Committer base changes:
>  - Currently 20 committers.
>  - No new committers added in the last 3 months
>  - Last committer addition was Savva Kolbachev at Mon Jan 19 2015
>
> ## Releases:
>  - Last stable release was 3.1.1 on Mon May 16 2016
>  - Last milestone release was 4.0.M3 on Fri February 12 2016
>
> ## Mailing list activity:
> Mailing list activity was lower than normal for development, likely due to
> summer vacations and other scheduling demands.  Activity on the user list
> was near normal.
>
>  - dev@cayenne.apache.org:
> - 124 subscribers (up 1 in the last 3 months):
> - 44 emails sent to list (120 in previous quarter)
>
>  - u...@cayenne.apache.org:
> - 247 subscribers (up 4 in the last 3 months):
> - 172 emails sent to list (185 in previous quarter)
>
> ## JIRA activity:
>  - 21 JIRA tickets created in the last 3 months
>  - 17 JIRA tickets closed/resolved in the last 3 months

Re: EOModel importer testing

[Mike Kienenberger]

Yes, please continue to improve it.  I first used it back in 2003, and
it's still being used 13 years later.

On Thu, Aug 4, 2016 at 4:38 AM, Musall Maik  wrote:
>
>> Am 04.08.2016 um 01:26 schrieb Aristedes Maniatis :
>>
>> On 4/08/2016 5:27am, Musall Maik wrote:
>>> There's still a bunch of details to fix, like TEXT columns (postgresql 
>>> clobs) ending up as varchar with no length, the parser not being able to 
>>> cope with unicode umlauts in documentation (similar to CAY-1291 which is 
>>> also still unsolved), and more.
>>
>> Perhaps I'm telling you the obvious, but don't overlook the ability to write 
>> xslt or just regex against the XML model file in order to tidy up some 
>> things.
>>
>
> Of course. But you know, we just had the "From EOF to Cayenne" topic at the 
> WOWODC conference in June, and I guess (hope) a few more people might try to 
> move to Cayenne in the near future. So, the benefit of any work put into the 
> model importer instead of run-once-on-my-project tools is multiplied by the 
> number of users that are using the importer.
>
> Maik
>

Re: Custom Templates

[Mike Kienenberger]

I overlooked the part where you said it was a single file.

It is not convenient to edit velocity files inside xml data sections :)

Neither an xml editor nor a velocity editor will work well with those options.

On Fri, Apr 8, 2016 at 12:52 PM, Michael Gentry <blackn...@gmail.com> wrote:
> Well, my thought was to have just one XML file with all of the template
> data in it: all custom templates, all JavaDocs, all annotations, and all
> custom imports (mainly to support the annotations).  Basically a bunch of
> CDATA sections to store each piece, plus the surrounding markup to identify
> what it is supporting, of course.
>
> Everything would still be under version control and could still be edited
> with an external tool, just not as conveniently.  Basically, find the CDATA
> section you want to edit and change it.
>
> mrg
>
>
> On Fri, Apr 8, 2016 at 11:22 AM, Mike Kienenberger <mkien...@gmail.com>
> wrote:
>
>> More pros:
>>
>> * Templates be edited by an external tool without having to export the
>> original data then import it after making changes.
>>
>> * Individual templates remain under version control.
>>
>>
>> On Fri, Apr 8, 2016 at 11:12 AM, Michael Gentry <blackn...@gmail.com>
>> wrote:
>> > So, I've had another thought on this ...
>> >
>> > We could store the custom templates, JavaDoc, etc. in a separate XML
>> file.
>> > This information is really only useful for class generation, either in
>> > Cayenne Modeler or cgen.
>> >
>> >
>> > Pros:
>> >
>> > * Class generation data wouldn't clutter up the current XML mapping file.
>> > * Separate file can be omitted/excluded by the build tool, such as Maven,
>> > so it isn't packaged up in your JAR/WAR for deployment.
>> > * Class generation data wouldn't get loaded at run-time, which is more
>> > memory efficient for your server processes.
>> >
>> > Cons:
>> >
>> > * More difficult to implement/manage since there'd be duplication of
>> > information to tie the two files together.
>> >
>> >
>> > I think the pros outweigh the cons.  Thoughts?
>> >
>> > Thanks,
>> >
>> > mrg
>>

Re: merging process

[Mike Kienenberger]

There's been a lot of discussion on git policies and merging.

Here's a summary but you'll need to be an asf member to read it though.

https://svn.apache.org/repos/private/foundation/board/github-discussion/proposals/

On Tue, Apr 5, 2016 at 7:47 AM, Andrus Adamchik  wrote:
> I applied the patch. We already have symmetrical static and instance methods 
> in the Ordering class. The new ones make total sense to me. The process is 
> like this:
>
> git fetch origin pull/NNN/head:NNN
> git merge NNN
> test ... change ... commit .. push
>
> I even opened a Jira - CAY-2073 :)
>
> Missed the fact that javadocs were off. Still the code is fine. We can update 
> the javadocs now.
>
>> I'm confused about who is the asfgit user is who "merged" this to master.
>
> IIRC asfgit is the sync process that syncs ASF Git to GitHub. Never mind that 
> though. Look at the Git history instead. It only has this commit from Lon:
>
> commit 46b45279e5c6fba5b352c777927388298e73f9c3
> Author: Lon Varscsak 
>
> But yeah, confusing. I think we need to make a rule to use "--no-ff" when 
> merging. Then there will be a merge author in the history.
>
>> Also, what is our process for handling CLA from github users.
>
> Back in the day of Jira patches, we did not require a CLA for "simple" 
> patches. IIRC Git policies were at least as lenient. Anyone can confirm?
>
> Andrus
>
>
>
>
>> On Apr 5, 2016, at 2:24 PM, Aristedes Maniatis  wrote:
>>
>> Can we discuss the process by which 
>> https://github.com/apache/cayenne/pull/94 got merged just now?
>>
>> I'm confused about who is the asfgit user is who "merged" this to master. 
>> Also, what is our process for handling CLA from github users.
>>
>> And as for the commit itself: it has problems. Firstly the javadocs are 
>> wrong on one method and missing on the other. And I'm not sure why we'd be 
>> adding static methods to this class. That just seems like unnecessary 
>> clutter.
>>
>>
>> Ari
>>
>>
>> --
>> -->
>> Aristedes Maniatis
>> GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E 3E49 102A
>

[Was: [VOTE] 4.0.M3 second attempt]]

[Mike Kienenberger]

What files did you find?  I ran rat manually and didn't see anything.

On Thu, Feb 11, 2016 at 6:23 PM, Aristedes Maniatis <a...@maniatis.org> wrote:
> On 12/02/2016 7:56am, Mike Kienenberger wrote:
>> ## mvn apache-rat currently unused for cayenne
>> # manually verify that there are no unknown or unapproved licensed files
>> ./rat.sh ../../../../java/apache-rat-0.11/apache-rat-0.11.jar
>> ##mvn apache-rat:check
>> # To check for all errors, if more than one project is affected
>> #   mvn apache-rat:check -Drat.numUnapprovedLicenses=
>> # To see details of rat failure
>> #   mvn -e -X apache-rat:check
>
>
> The maven target works OK for me and discovered a couple of files missing 
> licenses. I'll tidy them up now, but I don't think they should cause us to 
> halt this release.
>
> My other reviews look good. +1
>
> Ari
>
>
>
> --
> -->
> Aristedes Maniatis
> GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E 3E49 102A

Re: Open Source license for Oxygen 17

[Mike Kienenberger]

On Thu, Jan 28, 2016 at 2:51 AM, Andrus Adamchik  wrote:
> Go a reply from Oxygen. They request us to add a link back to them from the 
> Cayenne web site:
>
>   https://www.oxygenxml.com/non_profit_program.html#open_source
>
> Sounds fair to me. (perhaps we place it under "Contributors" page?).

I know this has come up before for other projects.   I can't think how
to locate that conversation, though.   The closest I could find in a
quick search was what follows, so I guess a question to trademarks@ is
the best way forward.

=
http://www.apache.org/foundation/marks/pmcs.html#navigation

If you have alternate suggestions for the link text that better fit
with your project's web presence, please let trademarks@ know. In
particular, we would like to ensure that any project-specific "Thanks"
pages you may have (i.e. thanking third parties for donated software
licenses for your specific project, etc.) are represented in a
consistent manner across all projects, and are presented publicly in a
manner that is distinctly different than the formal Sponsorship
program.

Re: CM Thoughts

[Mike Kienenberger]

On Mon, Jan 11, 2016 at 10:49 AM, Mike Kienenberger <mkien...@gmail.com> wrote:
> ... I'm fairly certain that you can write code that would be
> mostly interchangeable between a standalone app and a plugin.
> However, I haven't done any specific plug-in work to the traditional
> eclipse IDE, but the architecture is identical, and I would imagine
> it's possible.

I guess I should probably say it's not only possible, but it's
probably easy.   A quick review of my code shows that I primarily just
provided sets of actions, perspectives, and views to the eclipse
workbench API.  I imagine that'e exactly the same thing that a plug-in
would do.   A standalone app based on a plug-in would likely just
provide the startup glue code, set the default perspective to the
plugin perspective, create a menu, etc.

Again, though, this is all based on work I did five years ago, so take
it with a grain of salt.

Re: CM Thoughts

[Mike Kienenberger]

And yeah, a quick google search shows that's about all there is to it

http://stackoverflow.com/questions/1809401/packaging-one-or-two-plugins-as-a-standalone-rcp-application


On Mon, Jan 11, 2016 at 10:58 AM, Mike Kienenberger <mkien...@gmail.com> wrote:
> On Mon, Jan 11, 2016 at 10:49 AM, Mike Kienenberger <mkien...@gmail.com> 
> wrote:
>> ... I'm fairly certain that you can write code that would be
>> mostly interchangeable between a standalone app and a plugin.
>> However, I haven't done any specific plug-in work to the traditional
>> eclipse IDE, but the architecture is identical, and I would imagine
>> it's possible.
>
> I guess I should probably say it's not only possible, but it's
> probably easy.   A quick review of my code shows that I primarily just
> provided sets of actions, perspectives, and views to the eclipse
> workbench API.  I imagine that'e exactly the same thing that a plug-in
> would do.   A standalone app based on a plug-in would likely just
> provide the startup glue code, set the default perspective to the
> plugin perspective, create a menu, etc.
>
> Again, though, this is all based on work I did five years ago, so take
> it with a grain of salt.

Re: CM Thoughts

[Mike Kienenberger]

On Tue, Jan 5, 2016 at 5:34 PM, Aristedes Maniatis  wrote:

> To my mind, there is only a small gain in moving away from Swing and quite a 
> bit of work. But if you had the time to put into it, JavaFX is most likely to 
> survive another 15 years from the options you give above.

It appears that JavaFx is also usable from javascript, which might be
another reason to use it -- maybe the modeler could run on a web page.
  No idea if that is really practical though as I have never tried
anything like that.

https://docs.oracle.com/javase/8/docs/technotes/guides/scripting/nashorn/javafx.html

Re: [jira] [Commented] (CAY-2038) Hessian serialization error when using JSR-310 Date types with ROP

[Mike Kienenberger]

I remember reading that, while kryonet uses kryo for serialization by
default, serialization is pluggable and jsonbeans was listed as the
alternative serialization framework which serializes to JSON
(including javascript variants).

https://github.com/EsotericSoftware/jsonbeans

Serialization interface here:

https://github.com/EsotericSoftware/kryonet/blob/master/src/com/esotericsoftware/kryonet/Serialization.java

So this might be a good place to get ideas for creating pluggable
serialization.  I also noticed a number of other apache projects were
listed as already using either kyro or kryonet directly.


On Tue, Dec 8, 2015 at 7:46 AM, Michael Gentry  wrote:
> I was thinking cgen could probably be used to generate JS classes for the
> entities.  A potential JSON issue is it is a flattened data stream, like
> XML, which means you don't get "free" relationships, so you'd need to
> correctly map that when you do a conversion (especially for
> reference/shared tables, like a Country or State table).
>
>
> On Tue, Dec 8, 2015 at 7:34 AM, Aristedes Maniatis  wrote:
>
>> On 8/12/2015 10:36pm, Michael Gentry wrote:
>> > At the risk of muddying the thread, I think the biggest weakness/hole for
>> > Cayenne as an ROP server is dealing with the evolving JavaScript UI
>> > frameworks (AngularJS, KnockoutJS, etc).
>>
>> The real advantage of Cayenne's ROP implementation is that the client code
>> looks a lot like code you'd write directly on the server. You manipulate
>> the same ObjectContexts. You get to roll back, validate records, use parent
>> contexts and all the same stuff you expect from Cayenne.
>>
>> Mostly you can be unaware of the magic that happens to get your queries
>> and commits from the client to the server and back again.
>>
>> Once you leave ROP, then you start to plan around RESTful url routing
>> paths, serialisation of objects into non-Java formats (often json into
>> Javascript) and a completely different environment between the server and
>> the client. Sometimes that's exactly what you need and the abstraction is
>> useful... you might have different development teams working on each end.
>>
>> But ROP is also nice. You can (often) share code between client and server
>> and (mostly) ignore what happens in between. In our testing environment we
>> even glue together the client and server, bypassing the http connection, so
>> the we can run unit tests on the client code without starting up a separate
>> server.
>>
>>
>> Ari
>>
>>
>> --
>> -->
>> Aristedes Maniatis
>> GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E 3E49 102A
>>

Re: [jira] [Commented] (CAY-2038) Hessian serialization error when using JSR-310 Date types with ROP

[Mike Kienenberger]

Keep in mind that standard java serialization recently was revealed to
have serious security issues.

https://blogs.apache.org/foundation/entry/apache_commons_statement_to_widespread


I wanted a quick way to send java data over the network last weekend
and I came across this BSD licensed project:

https://github.com/EsotericSoftware/kryonet

It uses kryo as the serialization framework:

https://github.com/EsotericSoftware/kryo

For the simplistic things I wanted to do so far, it's been trivial to use.

Unfortunately, I didn't save the link which compared a bunch of these
frameworks and eventually led me to kryonet/kryo.

But I did just find this page which benchmarks a large number of them,
including kryo/hessian/protobuf.   It might be helpful in determining
what is out there.

https://github.com/eishay/jvm-serializers/wiki


On Sat, Dec 5, 2015 at 9:05 AM, Aristedes Maniatis  wrote:
> Even better I think is to make the serialisation layer pluggable. Dima and I 
> were discussing that briefly, but a bit of work is needed to make that happen.
>
> Personally I like protobuf and the schema files (there are files called 
> 'proto') which carry the definition of the object fields are very simple. I 
> think they could be easily generated by cgen and velocity. They are no more 
> onerous than our existing "client entities" on the server.
>
> There is also a schema-less clone of protobuf called protostuff [1] and there 
> is no reason that json or xml couldn't be pluggable options. The latest 
> protobuf now in beta even has the ability to dump the entire communication 
> channel into json. That seems like a really cool way to debug things.
>
>
> At the same time, we are looking at replacing the Java http client libraries 
> used for ROP with Apache commons http implementation, because the default 
> Java ones don't properly handle keep-alive over SSL. It would make a lot of 
> sense to have clear separation/injection between ORM, serialisation and 
> transport. Right now they touch each other too much.
>
> I'd like to make some time for my team to have the freedom to explore some of 
> these ideas. Maybe after Christmas...
>
> Ari
>
>
> [1] https://github.com/protostuff/protostuff
>
>
> On 5/12/2015 7:33pm, Andrus Adamchik wrote:
>> Yeah, Hessian looks dead.
>>
>> Protobuf is widely used as a wire protocol for NoSQL databases, etc. From 
>> that perspective it is a very good candidate. Though IIRC it requires some 
>> form of a "schema", while ROP relies on a generic serialization approach.
>>
>> My earlier ideas of using LinkRest for ROP are probably not (yet?) 
>> practical. LinkRest stays away from generic data operations (in other words, 
>> each LR operation is rooted in some entity). Though we can create an 
>> extension that changes this assumption, and still use the underlying 
>> machinery.
>>
>> I think the cheapest option for us is to use Java built-in serialization. It 
>> kind of works already with a few quirks. The downside is that the client 
>> must be Java, but this is a reality of ROP anyways.
>>
>> Andrus
>>
>>
>>> On Nov 24, 2015, at 4:22 AM, Ari Maniatis (JIRA)  wrote:
>>>
>>>
>>>[ 
>>> https://issues.apache.org/jira/browse/CAY-2038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15023542#comment-15023542
>>>  ]
>>>
>>> Ari Maniatis commented on CAY-2038:
>>> ---
>>>
>>> I found an old post on the Hessian list [1], but with no reply. Looks like 
>>> we should consider Hessian effectively abandoned. To fix this and also 
>>> review the library for serialisation security issues (like was found for 
>>> the Java serialisation) we should decide whether we:
>>>
>>> 1. Fix Hessian and fork it
>>> 2. Move to something else
>>>
>>> If we move, some options are here: 
>>> http://docs.spring.io/spring/docs/current/spring-framework-reference/html/remoting.html
>>>   Also, there is a Google library 
>>> https://developers.google.com/protocol-buffers/ which is interesting and 
>>> licensed with something that looks like a simple BSD license.
>>>
>>> I think our criteria should be:
>>>
>>> * not XML (to keep the size of the data to a minimum)
>>> * over HTTP (that's a significant benefit of the current approach since it 
>>> makes things like SSL easy)
>>>
>>> Against some tests https://github.com/eishay/jvm-serializers/wiki 
>>> protocol-buffers look to be smaller/faster than Hessian. And the community 
>>> appears to be alive and well: 
>>> https://groups.google.com/forum/#!forum/protobuf  However, it appears that 
>>> protocol-buffers require a .proto file to define the object serialisation 
>>> so either that would need to be generated dynamically at runtime or by the 
>>> cgen velocity scripts. I think.
>>>
>>> If we stay, one of the bigger problems is that Caucho have historically 
>>> rarely accepted patches or responded to community discussions. There is no 
>>> bug tracker, no official separate source 

Re: CayenneModeler not generating classes

[Mike Kienenberger]

Even if these lines are right, they are using undocumented velocity
behavior -- I could find no reference to allowing multi-line #if
statements nor allowing "and" and "or" as logical expressions in the
velocity documents.

On Mon, Oct 12, 2015 at 12:51 PM, Andrus Adamchik
<and...@objectstyle.org> wrote:
> [taking to dev]
>
> @Savva : these were checked in on April 29th per CAY-1999. Could you please 
> check whether we need to make this change in the Cayenne code? (and perhaps 
> we can reproduce the issue with a unit test).
>
> Thanks,
> Andrus
>
>> On Oct 12, 2015, at 12:33 PM, Mike Kienenberger <mkien...@gmail.com> wrote:
>>
>> I haven't had time to test this yet, but I'm pretty sure that lines 38
>> & 39 in the template are wrong.
>>
>> Dipesh,
>>
>> Go to 
>> https://github.com/apache/cayenne/blob/master/cayenne-tools/src/main/resources/templates/v1_2/superclass.vm
>> in your checkout, and replace lines 38 and 39 with a single line 38
>> containing:
>>
>> #if((${object.DeclaredAttributes} &&
>> !${object.DeclaredAttributes.isEmpty()}) ||
>> (${object.DeclaredRelationships} &&
>> !${object.DeclaredRelationships.isEmpty()}))
>

Re: Cayenne video from WOWODC

[Mike Kienenberger]

I can't think of any reason why we wouldn't want this on our home
page, and many reasons why we do :)   Seems like a no-brainer.

On Sun, Sep 13, 2015 at 3:12 PM, Andrus Adamchik  wrote:
> https://www.youtube.com/watch?v=gSauEmPnkCU
>
> I just uploaded to YouTube a video with my talk about new features in Cayenne 
> 4.0. This was given at WOWODC in April. It is not as exciting as Game of 
> Thrones :) , but what's the community opinion on embedding it on our home 
> page?
>
> Andrus

Re: September 2015 Board Report

[Mike Kienenberger]

You sure this link doesn't work for you? I'm pretty sure it works for
any PMC member. (The ?cayenne is probably optional in your case.)

https://reporter.apache.org/?cayenne

In any case, here's the text-version of the output.

Report from the Apache Cayenne committee [Andrus Adamchik]

## Description:
   User-friendly Java ORM with tools

## Activity:
 - TODO - the PMC MUST provide this information

## Health report:
 - TODO - Please use this paragraph to elaborate on why
   the current project activity (mails, commits, bugs etc) is at its current
   level.

## Issues:
 - TODO - list any issues that require board attention,
  or say "there are no issues requiring board attention at this time"

## LDAP committee group/Committership changes:

 - Currently 20 committers and 7 LDAP committee group members.
 - No new LDAP committee group members added in the last 3 months
 - No new committers added in the last 3 months
 - Last committer addition was Savva Kolbachev at Mon Jan 19 2015

## Releases:

 - Last release was 4.0.M2 on Thu Mar 19 2015

## Mailing list activity:

 - dev@cayenne.apache.org:
- 115 subscribers (up 1 in the last 3 months):
- 57 emails sent to list (126 in previous quarter)

 - u...@cayenne.apache.org:
- 240 subscribers (down -1 in the last 3 months):
- 190 emails sent to list (81 in previous quarter)


## JIRA activity:

 - 10 JIRA tickets created in the last 3 months
 - 8 JIRA tickets closed/resolved in the last 3 months


On Thu, Sep 10, 2015 at 4:54 PM, Michael Gentry  wrote:
> It's that time again ... some of the data I don't have access to, such as
> mailing list activity.  I'm open to helping if someone can get me the data
> ...
>
> Thanks,
>
> mrg

Re: Change audit framework

[Mike Kienenberger]

I think the only thing missing from this approach is a guarantee that
the audit data is committed in the same transaction as the data being
logged.

This is a requirement for my various projects.  If the audit data
cannot be committed, then the changes cannot be committed.



On Thu, Aug 27, 2015 at 7:11 AM, Andrus Adamchik and...@objectstyle.org wrote:
 It appears that in mine and everybody else's work capturing object changes is 
 a must-have. We have these discussions on user@ periodically, and 70% of my 
 clients have one or another implementation in their apps. So maybe we can do 
 something about it in Cayenne. The first attempt at it is already available 
 since 3.1 [1]. Still AuditableFilter is more like an example to follow, than 
 a drop-in implementation. So everyone keeps coming back with that same 
 question about audit.

 The challenge here is spare the user from the change analysis, but allow to 
 customize a few extra things:

 1. the mechanism where this data is stored (can be saved in the DB, broadcast 
 via MQ, stored in Kafka, etc.)
 2. additional contents of the audit trail (security context, transaction id, 
 client IP address, etc.)
 3. filtering entities we want to audit from other data changes.

 I think I'll be able to open-source a new version of the AuditableFilter that 
 is pretty close to this. It emits a stream of changes as JSON:

 {ts:1427090346831,by:someuser,serverIP:127.0.0.1,op:UPDATE,id:MyEntity:954619,changes:{email:[r...@example.com,r...@example.org]}}

 The stream is a complete change log that doesn't lose anything. This includes 
 all possible object graph operations (create, update, delete, relationship 
 changes, ID changes). The object model behind this framework is quite 
 reusable. Filtering can be done either with entity annotations, or straight 
 on the change object stream. STDOUT can be the default storage (and JSON - 
 the default format for that), and we let the users to override it.

 Does it sound like something you can use to rewrite your current audit 
 framework?

 Comments?

 Andrus


 [1] 
 https://github.com/apache/cayenne/tree/master/cayenne-lifecycle/src/main/java/org/apache/cayenne/lifecycle/audit

Re: Version API

[Mike Kienenberger]

On Wed, Jul 29, 2015 at 7:04 AM, Andrus Adamchik and...@objectstyle.org wrote:
 (taking to dev)

 Seems kind of pointless API to me.

It would at least be a redundant API if there's a standardized way of
fetching the Implementation-Version field, which there is.

Re: Trouble with Web app deployment

[Mike Kienenberger]

Thanks.  I'll look into that for the next velocity release.

On Sat, Jun 13, 2015 at 11:43 AM, Dirk Olmes d...@xanthippe.ping.de wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 06/12/2015 04:41 PM, Mike Kienenberger wrote:
 On Fri, Jun 12, 2015 at 10:37 AM, Mike Kienenberger
 mkien...@gmail.com wrote:
 And we do always have the option of using the velocity release
 that internalizes all dependencies so that it has no external
 dependencies. I'll have to look at these again, but I think it
 packages them.

 No, I'm wrong.  It doesn't rename/repackage them, it only unpacks
 them, so that's not helpful.

 Using maven-shade-plugin you should be able to build a version of
 velocity that puts all (or only some) of its dependencies under a
 different package name into the velocity jar.

 - -dirk

 -BEGIN PGP SIGNATURE-
 Version: GnuPG v2

 iEYEARECAAYFAlV8T60ACgkQASL+9Yb0srf3uACfR1xgvvCFP6cwKBAiuocz1rT0
 dL0An08MRo430lnURisTgCeSMAOHkep7
 =DATJ
 -END PGP SIGNATURE-

Velocity 1.8 release pending

[Mike Kienenberger]

We're slowly preparing a release of velocity 1.8.   Are there any
issues the cayenne project would like to see fixed in 1.8?   This is
bug-fix/dependency/modernization release.  All new feature requests
continue to be velocity 2.x only.

I think the current plan is to officially support and release against
java 1.7, but I don't think we're going to do anything which would
prevent recompiling against an older version of java (unless one of
our dependency upgrades prevent that).

Re: Trouble with Web app deployment

[Mike Kienenberger]

Hah!   Well, you might want to hold off on that, as I took a different
approach to the velocity issue -- I joined the project and am working
on a new release :)

And we do always have the option of using the velocity release that
internalizes all dependencies so that it has no external dependencies.
I'll have to look at these again, but I think it packages them.

On Fri, Jun 12, 2015 at 10:34 AM, Andrus Adamchik
and...@objectstyle.org wrote:
 (taking to dev)

 Yeah, Velocity is the dirtiest of the remaining Cayenne dependencies that 
 drags a bunch of other things into the stack.

 I am thinking of creating a pluggable syntax for SQLTemplate. By default 
 Cayenne would provide a simple parser that is a subset of Velocity, but 
 without Velocity (support for $var variables, #bind, #result and other 
 Cayenne directives). And moving full Velocity integration into a separate 
 module to avoid the dependency tail.

 Andrus

 On Jun 12, 2015, at 5:27 PM, Mike Kienenberger mkien...@gmail.com wrote:

 On Fri, Jun 12, 2015 at 10:20 AM, Andrew Willerding
 awillerd...@itsurcom.com wrote:
 Which commons lang version?

 I'm including the one bundled with Cayenne - commons-collections-3.2.1

 That's not a commons-lang library.   That's commons-collections.

 I took a quick peek at the cayenne binary distribution, and we do not
 distribute commons-lang.

 The version of velocity distributed is 1.6.3.

 The dependency there is:

 jar.commons-lang.version= 2.4

 So you will need 2.4, 2.5, or 2.6 (2.4 is the safest if you have no
 other commons-lang 2.x dependencies).

Re: Trouble with Web app deployment

[Mike Kienenberger]

On Fri, Jun 12, 2015 at 10:37 AM, Mike Kienenberger mkien...@gmail.com wrote:
 And we do always have the option of using the velocity release that
 internalizes all dependencies so that it has no external dependencies.
 I'll have to look at these again, but I think it packages them.

No, I'm wrong.  It doesn't rename/repackage them, it only unpacks
them, so that's not helpful.

Re: New features in Select API

[Mike Kienenberger]

Even though it may not be as concise, using alternate form of might
be less confusing.

On Tue, Apr 7, 2015 at 9:54 AM, Andrus Adamchik and...@objectstyle.org wrote:
 Hey Mike,


 On Apr 7, 2015, at 4:43 PM, Michael Gentry mgen...@masslight.net wrote:

 Select.select(ObjectContext context, int size);

 Then selectFirst would just call it with a size = 1.  This would give you
 an easy way to support fetching the top 5 (or 10 or any other number)
 newest/hottest/etc news articles (to use your example).

 FWIW, an equivalent api for size  1 API would be:

 ObjectSelect.query(..).limit(5).select(context);

 Also, maybe I'm misreading the JavaDocs, but for Select.selectOne, it says:
 Essentially the inversion of ObjectContext.selectOne(Select).

 I don't think inversion is the correct word, since it means opposite, and
 they aren't opposites.  A couple others use the word inversion, too, when I
 don't think that is what is meant.

 I think this doc was copied from ObjectSelect.selectOne, etc. Here inversion 
 means call order inversion. I.e. you get the same result, but perform the 
 invocation in a different (opposite) way:

 1. ListT objects = ObjectSelect.query(T.class).select(context);
 2. ListT objects = context.select(ObjectSelect.query(T.class));

 Does it make sense with such explanation?

 Andrus

Re: New features in Select API

[Mike Kienenberger]

On Tue, Apr 7, 2015 at 10:37 AM, Andrus Adamchik and...@objectstyle.org wrote:
 Even though it may not be as concise, using alternate form of might
 be less confusing.

 I assume you are talking about limit comment, not select?

No, I was referring to select.

Essentially the alternate form of ObjectContext.selectOne(Select)

We could probably also drop Essentially the from anywhere it is
being used and use

An alternate form of ObjectContext.selectOne(Select)

Michael's equivalent is also fine.  Or A fluent alternative to
might be better still.

Re: [VOTE] 4.0.M2 third attempt

[Mike Kienenberger]

On Mon, Mar 16, 2015 at 10:49 AM, Andrus Adamchik
and...@objectstyle.org wrote:
 Looks like he doesn't have permissions to alter release repo (is this cause 
 he's not a PMC?). Otherwise the release is published.

Yes, it's because he's not on the project management committee.   Only
a PMC member is empowered to release a product with the endorsement of
the ASF.

Re: Board report

[Mike Kienenberger]

Looks good to me.

On Tue, Mar 10, 2015 at 12:01 PM, Andrus Adamchik
and...@objectstyle.org wrote:

 On Mar 10, 2015, at 6:54 PM, Michael Gentry mgen...@masslight.net wrote:

 That's been on my to-do list, but I haven't gotten to it yet.  Was going to
 try tonight along with building the release.


 With the new report generation service at https://reporter.apache.org/ it was 
 a breeze :) Here is what I just committed to the board repo. Let me know if I 
 missed anything and I will change it in SVN. Will hold off the email to 
 board@ until tomorrow.

 Andrus

 Report from the Apache Cayenne project [Andrus Adamchik]

 ## Description:
 Apache Cayenne is a Java persistence framework. It takes a distinct approach 
 to
 object persistence and provides an ORM runtime, remote persistence services, 
 and
 a GUI mapping/modeling tool.

 ## Activity:

 Last three months were mostly spent on preparation of 4.0.M2 release, which 
 is now
 being voted on. Fixing bugs and failing unit tests, etc.

 ## Issues:

 There are no issues requiring board attention at this time

 ## PMC/Committership changes:

  - Currently 20 committers and 7 PMC members in the project.
  - No new PMC members added in the last 3 months
  - New commmitters:
 - Savva Kolbachev was added as a committer on Mon Jan 19 2015
 - Alex Kolonitsky was added as a committer on Mon Jan 19 2015

 ## Releases:

  - Vote for 4.0.M2 release is now in progress.

 ## Mailing list activity:

  - dev@cayenne.apache.org:
 - 113 subscribers (down -3 in the last 3 months):
 - 74 emails sent to list (178 in previous quarter)

  - u...@cayenne.apache.org:
 - 240 subscribers (down -6 in the last 3 months):
 - 45 emails sent to list (85 in previous quarter)


 ## JIRA activity:

  - 12 JIRA tickets created in the last 3 months
  - 8 JIRA tickets closed/resolved in the last 3 months

Re: [VOTE] 4.0.M2 third attempt

[Mike Kienenberger]

I think that last error was caused by a flaw in my switch from sun
1.6 to openjdk 1.7 script.

When I set the default version of java to openjdk 1.7 and run mvn
install, it works fine.   So I'm still +1 on linux for this release.


[INFO] Cayenne Release Assembly .. SUCCESS [0.046s]
[INFO] 
[INFO] BUILD SUCCESS
[INFO] 
[INFO] Total time: 9:35.978s
[INFO] Finished at: Tue Mar 10 12:29:43 EDT 2015
[INFO] Final Memory: 126M/811M
[INFO] 
 uname -a
Linux linux-4eqv.site 3.16.7-7-desktop #1 SMP PREEMPT Wed Dec 17
18:00:44 UTC 2014 (762f27a) x86_64 x86_64 x86_64 GNU/Linux
 java -version
java version 1.7.0_75
OpenJDK Runtime Environment (IcedTea 2.5.4) (suse-4.1-x86_64)
OpenJDK 64-Bit Server VM (build 24.75-b04, mixed mode)

On Tue, Mar 10, 2015 at 12:13 PM, Mike Kienenberger mkien...@gmail.com wrote:
 The errors you posted seem to be network errors.

 I just rebuilt again without problems.

 uname -a
 Linux linux-4eqv.site 3.16.7-7-desktop #1 SMP PREEMPT Wed Dec 17
 18:00:44 UTC 2014 (762f27a) x86_64 x86_64 x86_64 GNU/Linux
 [Opensuse 13.2]

 java -version
 openjdk version 1.8.0_40
 OpenJDK Runtime Environment (build 1.8.0_40-b10)
 OpenJDK 64-Bit Server VM (build 25.40-b14, mixed mode)

 Oops!   My system upgrade on Feb 23rd apparently jumped me from Java
 1.6 to 1.8.  I did not notice that.

 When I build with Java 1.7

 java -version
 java version 1.7.0_75
 OpenJDK Runtime Environment (IcedTea 2.5.4) (suse-4.1-x86_64)
 OpenJDK 64-Bit Server VM (build 24.75-b04, mixed mode)


 I get:

 Tests in error:
   testNewDataMapImport(org.apache.cayenne.tools.dbimport.DbImportActionTest)

 Tests run: 76, Failures: 0, Errors: 1, Skipped: 0

 [INFO] 
 
 [INFO] Reactor Summary:
 [INFO]
 [INFO] Cayenne ... SUCCESS [3.069s]
 [INFO] Cayenne Build Tools Parent  SUCCESS [0.135s]
 [INFO] Cayenne License and Notice Bundle . SUCCESS [7.748s]
 [INFO] Common Unit Test Utilities  SUCCESS [3.225s]
 [INFO] Cayenne Code Checkers . SUCCESS [0.569s]
 [INFO] Cayenne Dependency Injection Container  SUCCESS [48.682s]
 [INFO] Cayenne Server  SUCCESS [4:20.241s]
 [INFO] Cayenne ROP Client  SUCCESS [51.797s]
 [INFO] Cayenne Project ... SUCCESS [9.432s]
 [INFO] Cayenne Tools . FAILURE [27.403s]
 [INFO] Cayenne Lifecycle Utilities ... SKIPPED

 So I got farther than you did, but not all the way.


 On Tue, Mar 10, 2015 at 12:03 PM, Michael Gentry mgen...@masslight.net 
 wrote:
 Yeah, I know Jenkins is building on Linux, so I'm confused as to why I'm
 having this issue, but you are probably right that it is specific to my
 network, although there is nothing complex or unusual about my network.


 On Tue, Mar 10, 2015 at 11:58 AM, Andrus Adamchik and...@objectstyle.org
 wrote:

 BTW, our Jenkins builds are all Linux.

 The error is likely about JGroups breaking in your network environment
 (not related to Cayenne, but of course very annoying). So hopefully it
 works on OS X.

 Andrus

  On Mar 10, 2015, at 6:49 PM, Michael Gentry mgen...@masslight.net
 wrote:
 
  I've still been unable to build on Linux, even with the changes Andrus
  suggested.  I can try Mac OS X tonight, but even if it builds there, I'm
  concerned about the failure on Linux until I can figure it out.
 
  mrg
 
 
  On Tue, Mar 10, 2015 at 11:37 AM, Mike Kienenberger mkien...@gmail.com
  wrote:
 
  Hey guys,
 
  We're still missing one more binding vote and it's been 12 days.
 
  On Sun, Mar 8, 2015 at 4:26 PM, Andrus Adamchik and...@objectstyle.org
 
  wrote:
  Googling shows that putting '-Djava.net.preferIPv4Stack=true' might
  help. We mention that in the dev guide actually, and just recently I was
  wondering which one of the tests actually requires IPv4 vs IPv6 :)
 
  http://cayenne.apache.org/dev/building-cayenne.html
 
  Andrus
 
  On Mar 6, 2015, at 9:50 PM, Michael Gentry mgen...@masslight.net
  wrote:
 
  I'm consistently getting this test failure when trying to build:
 
  Tests in error:
  DataRowStoreIT.testConstructorWithProperties:63 » CayenneRuntime
  [v.4.0.M2 Mar...
 
  Tests run: 1456, Failures: 0, Errors: 1, Skipped: 0
 
 
 
  [INFO] Reactor Summary:
  [INFO]
  [INFO] Cayenne ... SUCCESS
  [1.236s]
  [INFO] Cayenne Build Tools Parent  SUCCESS
  [0.021s]
  [INFO] Cayenne License and Notice Bundle . SUCCESS
  [2.770s]
  [INFO] Common Unit Test Utilities

Re: [VOTE] 4.0.M2 third attempt

[Mike Kienenberger]

Hey guys,

We're still missing one more binding vote and it's been 12 days.

On Sun, Mar 8, 2015 at 4:26 PM, Andrus Adamchik and...@objectstyle.org wrote:
 Googling shows that putting '-Djava.net.preferIPv4Stack=true' might help. We 
 mention that in the dev guide actually, and just recently I was wondering 
 which one of the tests actually requires IPv4 vs IPv6 :)

 http://cayenne.apache.org/dev/building-cayenne.html

 Andrus

 On Mar 6, 2015, at 9:50 PM, Michael Gentry mgen...@masslight.net wrote:

 I'm consistently getting this test failure when trying to build:

 Tests in error:
  DataRowStoreIT.testConstructorWithProperties:63 » CayenneRuntime
 [v.4.0.M2 Mar...

 Tests run: 1456, Failures: 0, Errors: 1, Skipped: 0



 [INFO] Reactor Summary:
 [INFO]
 [INFO] Cayenne ... SUCCESS [1.236s]
 [INFO] Cayenne Build Tools Parent  SUCCESS [0.021s]
 [INFO] Cayenne License and Notice Bundle . SUCCESS [2.770s]
 [INFO] Common Unit Test Utilities  SUCCESS [2.040s]
 [INFO] Cayenne Code Checkers . SUCCESS [0.173s]
 [INFO] Cayenne Dependency Injection Container  SUCCESS [15.565s]
 [INFO] Cayenne Server  FAILURE
 [3:10.456s]


 ---
 Test set: org.apache.cayenne.access.DataRowStoreIT
 ---
 Tests run: 4, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.244 sec
  FAILURE! - in org.apache.cayenne.access.DataRowStoreIT
 testConstructorWithProperties(org.apache.cayenne.access.DataRowStoreIT)
 Time elapsed: 0.172 sec   ERROR!
 org.apache.cayenne.CayenneRuntimeException: [v.4.0.M2 Mar 06 2015 13:39:49]
 Error initializing DataRowStore.
at org.jgroups.JChannel.connect(JChannel.java:328)
at
 org.apache.cayenne.event.JavaGroupsBridge.startupExternal(JavaGroupsBridge.java:130)
at org.apache.cayenne.event.EventBridge.startup(EventBridge.java:245)
at org.apache.cayenne.event.EventBridge.startup(EventBridge.java:193)
at org.apache.cayenne.event.EventBridge.startup(EventBridge.java:178)
at
 org.apache.cayenne.access.DataRowStore.startListeners(DataRowStore.java:613)
at
 org.apache.cayenne.access.DataRowStore.initWithProperties(DataRowStore.java:182)
at org.apache.cayenne.access.DataRowStore.init(DataRowStore.java:107)
at
 org.apache.cayenne.access.DataRowStoreIT.testConstructorWithProperties(DataRowStoreIT.java:63)
 ...
 [DownHandler (UDP)] INFO org.jgroups.protocols.UDP - unicast sockets will
 use interface 127.0.1.1
 [main] ERROR org.jgroups.JChannel - exception: java.lang.Exception:
 exception caused by UDP.start(): java.net.SocketException: bad argument for
 IP_MULTICAST_IF: address not bound to any interface


 mrg:~$ uname -a
 Linux 3.13.0-46-generic #77-Ubuntu SMP Mon Mar 2 18:26:13 UTC 2015 i686
 i686 i686 GNU/Linux
 mrg:~$ java -version
 java version 1.7.0_75
 OpenJDK Runtime Environment (IcedTea 2.5.4) (7u75-2.5.4-1~trusty1)
 OpenJDK Server VM (build 24.75-b04, mixed mode)


 Any suggestions?

 Thanks,

 mrg


 On Sat, Feb 28, 2015 at 4:48 AM, Andrus Adamchik and...@objectstyle.org
 wrote:


 On Feb 26, 2015, at 12:41 PM, Alex Kolonitsky 
 akolonit...@objectstyle.com wrote:

 Hi All,
 I've prepared 4.0.M2 artifacts for voting again, I hope this time
 everything will be fine.

 Maven artifacts:
 https://repository.apache.org/content/repositories/orgapachecayenne-1005 
 https://repository.apache.org/content/repositories/orgapachecayenne-1005
 Assemblies: https://dist.apache.org/repos/dist/dev/cayenne/4.0.M2/ 
 https://dist.apache.org/repos/dist/dev/cayenne/4.0.M2/

 Please evaluate and cast your votes.

 Regards,
 Alex Kolonitsky.

 +1 from me.


 1. rat.sh - no complaints
 (noticed .idea/ directory at the root of the source archive. Not a show
 stopper for the release, but let's add it to assembly excludes for the
 future)
 2. checksums - match
 3. signatures - match
 4. Source builds (mvn verify)
 5. Modeler OS X, Windows, Generic versions all start fine
 6. Random poking through the structure of the binary assemblies doesn't
 show anything abnormal.

 and thanks to Mike for providing a detailed release evaluation script.

 Andrus

Alex Kolonitsky and Savva Kolbachev. missing from contributors.html

[Mike Kienenberger]

Alex Kolonitsky and Savva Kolbachev.are still missing from the
contributors section on the web site at contributors.html.

I'm not sure if this is because they have not added themselves to the
page or if our web site is out of date.

Re: [VOTE] 4.0.M2 third attempt

[Mike Kienenberger]

The errors you posted seem to be network errors.

I just rebuilt again without problems.

 uname -a
Linux linux-4eqv.site 3.16.7-7-desktop #1 SMP PREEMPT Wed Dec 17
18:00:44 UTC 2014 (762f27a) x86_64 x86_64 x86_64 GNU/Linux
[Opensuse 13.2]

 java -version
openjdk version 1.8.0_40
OpenJDK Runtime Environment (build 1.8.0_40-b10)
OpenJDK 64-Bit Server VM (build 25.40-b14, mixed mode)

Oops!   My system upgrade on Feb 23rd apparently jumped me from Java
1.6 to 1.8.  I did not notice that.

When I build with Java 1.7

 java -version
java version 1.7.0_75
OpenJDK Runtime Environment (IcedTea 2.5.4) (suse-4.1-x86_64)
OpenJDK 64-Bit Server VM (build 24.75-b04, mixed mode)


I get:

Tests in error:
  testNewDataMapImport(org.apache.cayenne.tools.dbimport.DbImportActionTest)

Tests run: 76, Failures: 0, Errors: 1, Skipped: 0

[INFO] 
[INFO] Reactor Summary:
[INFO]
[INFO] Cayenne ... SUCCESS [3.069s]
[INFO] Cayenne Build Tools Parent  SUCCESS [0.135s]
[INFO] Cayenne License and Notice Bundle . SUCCESS [7.748s]
[INFO] Common Unit Test Utilities  SUCCESS [3.225s]
[INFO] Cayenne Code Checkers . SUCCESS [0.569s]
[INFO] Cayenne Dependency Injection Container  SUCCESS [48.682s]
[INFO] Cayenne Server  SUCCESS [4:20.241s]
[INFO] Cayenne ROP Client  SUCCESS [51.797s]
[INFO] Cayenne Project ... SUCCESS [9.432s]
[INFO] Cayenne Tools . FAILURE [27.403s]
[INFO] Cayenne Lifecycle Utilities ... SKIPPED

So I got farther than you did, but not all the way.


On Tue, Mar 10, 2015 at 12:03 PM, Michael Gentry mgen...@masslight.net wrote:
 Yeah, I know Jenkins is building on Linux, so I'm confused as to why I'm
 having this issue, but you are probably right that it is specific to my
 network, although there is nothing complex or unusual about my network.


 On Tue, Mar 10, 2015 at 11:58 AM, Andrus Adamchik and...@objectstyle.org
 wrote:

 BTW, our Jenkins builds are all Linux.

 The error is likely about JGroups breaking in your network environment
 (not related to Cayenne, but of course very annoying). So hopefully it
 works on OS X.

 Andrus

  On Mar 10, 2015, at 6:49 PM, Michael Gentry mgen...@masslight.net
 wrote:
 
  I've still been unable to build on Linux, even with the changes Andrus
  suggested.  I can try Mac OS X tonight, but even if it builds there, I'm
  concerned about the failure on Linux until I can figure it out.
 
  mrg
 
 
  On Tue, Mar 10, 2015 at 11:37 AM, Mike Kienenberger mkien...@gmail.com
  wrote:
 
  Hey guys,
 
  We're still missing one more binding vote and it's been 12 days.
 
  On Sun, Mar 8, 2015 at 4:26 PM, Andrus Adamchik and...@objectstyle.org
 
  wrote:
  Googling shows that putting '-Djava.net.preferIPv4Stack=true' might
  help. We mention that in the dev guide actually, and just recently I was
  wondering which one of the tests actually requires IPv4 vs IPv6 :)
 
  http://cayenne.apache.org/dev/building-cayenne.html
 
  Andrus
 
  On Mar 6, 2015, at 9:50 PM, Michael Gentry mgen...@masslight.net
  wrote:
 
  I'm consistently getting this test failure when trying to build:
 
  Tests in error:
  DataRowStoreIT.testConstructorWithProperties:63 » CayenneRuntime
  [v.4.0.M2 Mar...
 
  Tests run: 1456, Failures: 0, Errors: 1, Skipped: 0
 
 
 
  [INFO] Reactor Summary:
  [INFO]
  [INFO] Cayenne ... SUCCESS
  [1.236s]
  [INFO] Cayenne Build Tools Parent  SUCCESS
  [0.021s]
  [INFO] Cayenne License and Notice Bundle . SUCCESS
  [2.770s]
  [INFO] Common Unit Test Utilities  SUCCESS
  [2.040s]
  [INFO] Cayenne Code Checkers . SUCCESS
  [0.173s]
  [INFO] Cayenne Dependency Injection Container  SUCCESS
  [15.565s]
  [INFO] Cayenne Server  FAILURE
  [3:10.456s]
 
 
 
 
 ---
  Test set: org.apache.cayenne.access.DataRowStoreIT
 
 
 ---
  Tests run: 4, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.244
  sec
   FAILURE! - in org.apache.cayenne.access.DataRowStoreIT
 
 testConstructorWithProperties(org.apache.cayenne.access.DataRowStoreIT)
  Time elapsed: 0.172 sec   ERROR!
  org.apache.cayenne.CayenneRuntimeException: [v.4.0.M2 Mar 06 2015
  13:39:49]
  Error initializing DataRowStore.
at org.jgroups.JChannel.connect(JChannel.java:328)
at
 
 
 org.apache.cayenne.event.JavaGroupsBridge.startupExternal(JavaGroupsBridge.java:130)
at
 org.apache.cayenne.event.EventBridge.startup(EventBridge.java:245

Re: [VOTE] 4.0.M2 third attempt

[Mike Kienenberger]

https://cayenne.apache.org/download.html says that
http://www.apache.org/dist/cayenne/KEYS is the correct location, so
we're missing Alex's key.


On Thu, Feb 26, 2015 at 9:49 AM, Mike Kienenberger mkien...@gmail.com wrote:
 We can't check the release until Alex's keys are in
 http://www.apache.org/dist/cayenne/KEYS.

 Or am I looking in the wrong spot for Alex's keys?

 On Thu, Feb 26, 2015 at 4:41 AM, Alex Kolonitsky
 akolonit...@objectstyle.com wrote:
 Hi All,
 I've prepared 4.0.M2 artifacts for voting again, I hope this time everything 
 will be fine.

 Maven artifacts: 
 https://repository.apache.org/content/repositories/orgapachecayenne-1005 
 https://repository.apache.org/content/repositories/orgapachecayenne-1005
 Assemblies: https://dist.apache.org/repos/dist/dev/cayenne/4.0.M2/ 
 https://dist.apache.org/repos/dist/dev/cayenne/4.0.M2/

 Please evaluate and cast your votes.

 Regards,
 Alex Kolonitsky.

Re: [VOTE] 4.0.M2 third attempt

[Mike Kienenberger]

We can't check the release until Alex's keys are in
http://www.apache.org/dist/cayenne/KEYS.

Or am I looking in the wrong spot for Alex's keys?

On Thu, Feb 26, 2015 at 4:41 AM, Alex Kolonitsky
akolonit...@objectstyle.com wrote:
 Hi All,
 I've prepared 4.0.M2 artifacts for voting again, I hope this time everything 
 will be fine.

 Maven artifacts: 
 https://repository.apache.org/content/repositories/orgapachecayenne-1005 
 https://repository.apache.org/content/repositories/orgapachecayenne-1005
 Assemblies: https://dist.apache.org/repos/dist/dev/cayenne/4.0.M2/ 
 https://dist.apache.org/repos/dist/dev/cayenne/4.0.M2/

 Please evaluate and cast your votes.

 Regards,
 Alex Kolonitsky.

SVN access for Alex

[Mike Kienenberger]

On Thu, Feb 26, 2015 at 12:46 PM, Andrus Adamchik
and...@objectstyle.org wrote:
 Somehow Alex did not have the permissions to commit to SVN (perhaps it
 requires some action on my part to get him into proper SVN groups?)


You should know more about this than I, but the documented steps are here:

http://www.apache.org/dev/pmc.html#SVNaccess

Re: [VOTE] 4.0.M2 third attempt

[Mike Kienenberger]

- signatures and checksums match
- source builds
- apache rat passes

+1






Below are the linux commands I used to verify the release of the
cayenne-4.0.M2 files:

=

wget 
https://dist.apache.org/repos/dist/dev/cayenne/4.0.M2/cayenne-4.0.M2-macosx.dmg
wget 
https://dist.apache.org/repos/dist/dev/cayenne/4.0.M2/cayenne-4.0.M2-macosx.dmg.asc
wget 
https://dist.apache.org/repos/dist/dev/cayenne/4.0.M2/cayenne-4.0.M2-macosx.dmg.md5
wget 
https://dist.apache.org/repos/dist/dev/cayenne/4.0.M2/cayenne-4.0.M2-src.tar.gz
wget 
https://dist.apache.org/repos/dist/dev/cayenne/4.0.M2/cayenne-4.0.M2-src.tar.gz.asc
wget 
https://dist.apache.org/repos/dist/dev/cayenne/4.0.M2/cayenne-4.0.M2-src.tar.gz.md5
wget 
https://dist.apache.org/repos/dist/dev/cayenne/4.0.M2/cayenne-4.0.M2-win.zip
wget 
https://dist.apache.org/repos/dist/dev/cayenne/4.0.M2/cayenne-4.0.M2-win.zip.asc
wget 
https://dist.apache.org/repos/dist/dev/cayenne/4.0.M2/cayenne-4.0.M2-win.zip.md5
wget https://dist.apache.org/repos/dist/dev/cayenne/4.0.M2/cayenne-4.0.M2.tar.gz
wget 
https://dist.apache.org/repos/dist/dev/cayenne/4.0.M2/cayenne-4.0.M2.tar.gz.asc
wget 
https://dist.apache.org/repos/dist/dev/cayenne/4.0.M2/cayenne-4.0.M2.tar.gz.md5

# check checksums
## made with  gpg --print-md MD5 cayenne-X.X.tar.gz
cat *.md5 | tr -d ' ' | awk 'BEGIN{OFS= ; FS=:}
{tmp=$1;$1=$2;$2=tmp;print}' | md5sum -c

# check signatures
wget http://www.apache.org/dist/cayenne/KEYS
gpg --import KEYS
find . -name '*.asc' -exec gpg --verify {} \;

# verify .tar.gz and -win.zip files are identical -- flawed process
due to platform building differences
mkdir src
cd src
tar xvf ../cayenne-4.0.M2.tar.gz
mv cayenne-4.0.M2/ cayenne-4.0.M2-tar-gz
unzip ../cayenne-4.0.M2-win.zip
# should be no output
# but windows and tar package are built with different java versions.
## differences in jars, pdfs, html resources, css, html, package-info
between tar.gz and zip(win)
diff -rq cayenne-4.0.M2* | grep -v jar differ | grep -v html
differ | grep -v pdf differ | grep -v .css differ
# should be are identical output
diff -srq cayenne-4.0.M2* | grep -v jar differ | grep -v html
differ | grep -v pdf differ | grep -v .css differ | grep -v are
identical

# unpack source
tar xvzf ../cayenne-4.0.M2-src.tar.gz
# build source
cd cayenne-4.0.M2-src
mvn install

## mvn apache-rat currently unused for cayenne
# manually verify that there are no unknown or unapproved licensed files
./rat.sh ../../../apache-rat-0.9/apache-rat-0.9.jar
##mvn apache-rat:check
# To check for all errors, if more than one project is affected
#   mvn apache-rat:check -Drat.numUnapprovedLicenses=
# To see details of rat failure
#   mvn -e -X apache-rat:check


On Thu, Feb 26, 2015 at 4:41 AM, Alex Kolonitsky
akolonit...@objectstyle.com wrote:
 Hi All,
 I've prepared 4.0.M2 artifacts for voting again, I hope this time everything 
 will be fine.

 Maven artifacts: 
 https://repository.apache.org/content/repositories/orgapachecayenne-1005 
 https://repository.apache.org/content/repositories/orgapachecayenne-1005
 Assemblies: https://dist.apache.org/repos/dist/dev/cayenne/4.0.M2/ 
 https://dist.apache.org/repos/dist/dev/cayenne/4.0.M2/

 Please evaluate and cast your votes.

 Regards,
 Alex Kolonitsky.

Re: setter for toMany in generated classes

[Mike Kienenberger]

I am also of the opinion that this should be a per-user customization
that someone can make rather than something that should be provided
out of the box.  I don't think this should be part of Cayenne.

But since I'm not an active committer any more, I wasn't going to be
the first to say so.

On Sun, Jan 25, 2015 at 7:13 AM, Andrus Adamchik and...@objectstyle.org wrote:

 On Dec 27, 2014, at 6:07 PM, Johannes jotpe@gmail.com wrote:

 Hello, I moved the method to CayenneDataObject. I hope the documentation
 is more meaningfull now.

 The superclass.vm contains for every set-able relationship two method
 which calls the setter in CayenneDataObject. Two methods because a
 default value for deletion.

 Would be happy if anybody could review it again at
 https://github.com/jotpe/cayenne/commit/d7251014c9d5cb9396a83cd6e2f16e64af27e4b5

 Regards Johannes

 So we are talking about this pull request: 
 https://github.com/apache/cayenne/pull/61 .

 A question to Cayenne committers and community ... Proposed implementation 
 will require cleanup, optimization and very thorough testing. But aside from 
 that, do we think a collection setter is universally useful to a point that 
 all to-many relationships should expose it?

 Here is my feedback. I am ok with including a to-many collection sync 
 operation in CayenneDataObject, but I am against placing it in default .vm 
 template. This is based on the assumption that we are dealing with an 
 occasionally, but not universally useful operation. So e.g. if a user decides 
 he needs this op for Artist.paintings(..) collection, he would simply create 
 a method in a subclass:

 Artist extends _Artist {

void setPaintings(ListPaintings ps) {
setToManyTarget(_Artist.PAINTINGS, ps, true);
}
 }

 An ability to extend template behavior with custom per-object code is exactly 
 the reason we have sub/superclass separation.

 Also I am tentatively -1 on the delete option. I would generally handle it 
 with a proper delete rule in the model.

 Thoughts?
 Andrus

Re: setter for toMany in generated classes

[Mike Kienenberger]

As I said before, I think you need to call
removeToManyTarget(${rel.Name}, obj, true); instead of
iterator.remove() and removeAll(), and then you need to call
addToManyTarget() instead of addAll().  Otherwise, you are losing the
reverse relationship changes.

But the rest seems ok.

I'm not saying that adding setList() to the default template is a good
idea, though.   I think having it in your custom template is good
enough.

I do everything with custom templates and rarely use the default
cayenne templates.


On Thu, Dec 18, 2014 at 2:58 PM, Johannes jotpe@gmail.com wrote:
 Hello,

 following the conversation from
 http://mail-archives.apache.org/mod_mbox/cayenne-user/201412.mbox/%3C548BDF97.1040104%40gmail.com%3E
 there seems to be a common need for having a new method next to
 addXXX, removeXXX a setXXXs in generated classes from CayenneModeler.

 I created a first draft
 https://github.com/jotpe/cayenne/commit/6627c09936285c7650d69f44a95ba2f4b118f2b6

 Would anybody be so nice to review it? I'm not sure if these lines can
 run in every environment without trouble. What about tests?

 Best regards Johannes

Re: Finally

[Mike Kienenberger]

For me, my integration tests are all against hsqldb and my deployments
are all against Oracle.   I use h2 instead for my non-Cayenne project
for a dev deployment, but for testing, hsqldb seems to do a better
job.   I'd like to use H2 as a dev deployment in my cayenne project as
well, but I've never gotten around to setting it up (building a
selective data migrator from production to dev).

On Tue, Nov 25, 2014 at 7:59 AM, Aristedes Maniatis a...@maniatis.org wrote:
 On 25/11/2014 10:52pm, Andrus Adamchik wrote:
 Many thanks to Savva Kolbachev for the effort to reorganize our test suite 
 and implement a sound algorithm for maintaining test DB consistency without 
 sacrificing the performance. With this big randomness factor out of the 
 picture we have a good chance of maintaining the builds in the blue going 
 forward.

 That's terrific. Well done. That will also make it much easier to handle pull 
 requests from github which will automatically be tested.

 I guess next is to see what other databases we can test against. Does anyone 
 know what databases are available in the Apache build cluster? Oracle, mysql, 
 postgresql and MS-SQL are probably the most important targets.

 This also provides a good base to review code coverage, and I've just put in 
 a request to Sonar to move our repo from svn to git: 
 http://nemo.sonarqube.org/dashboard/index/org.apache.cayenne:cayenne-parent

 Ari


 --
 --
 Aristedes Maniatis
 GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E 3E49 102A

Re: Variations of 'like'

[Mike Kienenberger]

Yeah, I was about to comment along those lines as well.

For chained operations, readability of the code needs to be a primary focus.



On Fri, Nov 21, 2014 at 9:56 AM, Michael Gentry mgen...@masslight.net wrote:
 I'd avoid true/false for that purpose.  We had the same thing in
 orderings before I changed it to an enum.  I'd specify it in the
 method name or use an enum that makes sense when reading it.

 mrg


 On Fri, Nov 21, 2014 at 9:47 AM, Andrus Adamchik and...@objectstyle.org 
 wrote:
 So are you thinking something like:
 Artist.ARTIST_NAME.contains(Van)?

 yep.

 Also, what about
 case-insensitive?

 Probably as a second true/false argument? I started to dislike the look of 
 likeIgnoreCase recently :)

 Property.contains(string);
 Property.contains(string, true);
 Property.contains(string, false);


 Andrus


 On Nov 21, 2014, at 5:33 PM, Michael Gentry mgen...@masslight.net wrote:

 I 'like' this.

 So are you thinking something like:
 Artist.ARTIST_NAME.contains(Van)?  Also, what about
 case-insensitive?

 mrg


 On Fri, Nov 21, 2014 at 7:19 AM, Andrus Adamchik and...@objectstyle.org 
 wrote:
 Another API idea that I just had while analyzing boilerplate code of the 
 client Cayenne apps. An argument to Property.like(..) (or second argument 
 to ExpressionFactory.likeExp(..)) requires a full pattern to match 
 against. So people would often write their own utility code to wrap a 
 String in % signs. Cayenne can easily take care of this via the 
 following methods:


 Property.contains(string);
 // same as Property.like(% + string + %);

 Property.startsWith(string);
 // same as Property.like(string + %);

 Property.endsWith(string);
 // same as Property.like(% + string);

 In addition to saving the user from String concatenation, these new 
 methods can do proper symbol escaping, making like much safer to use.

 Andrus

Re: Variations of 'like'

[Mike Kienenberger]

Not only readability, but also picking the right options.

For me, code completion on a method name is the quickest way to work
through chained query options.   An enum argument is also workable,
but extra typing.   But a generic type like int or boolean makes it
difficult to figure out what to specify without looking up the
documentation.

On Fri, Nov 21, 2014 at 10:02 AM, Andrus Adamchik
and...@objectstyle.org wrote:
 enum also makes it needlessly verbose :-/

 But yeah, I take your point.


 On Nov 21, 2014, at 5:56 PM, Michael Gentry mgen...@masslight.net wrote:

 I'd avoid true/false for that purpose.  We had the same thing in
 orderings before I changed it to an enum.  I'd specify it in the
 method name or use an enum that makes sense when reading it.

 mrg


 On Fri, Nov 21, 2014 at 9:47 AM, Andrus Adamchik and...@objectstyle.org 
 wrote:
 So are you thinking something like:
 Artist.ARTIST_NAME.contains(Van)?

 yep.

 Also, what about
 case-insensitive?

 Probably as a second true/false argument? I started to dislike the look of 
 likeIgnoreCase recently :)

 Property.contains(string);
 Property.contains(string, true);
 Property.contains(string, false);


 Andrus


 On Nov 21, 2014, at 5:33 PM, Michael Gentry mgen...@masslight.net wrote:

 I 'like' this.

 So are you thinking something like:
 Artist.ARTIST_NAME.contains(Van)?  Also, what about
 case-insensitive?

 mrg


 On Fri, Nov 21, 2014 at 7:19 AM, Andrus Adamchik and...@objectstyle.org 
 wrote:
 Another API idea that I just had while analyzing boilerplate code of the 
 client Cayenne apps. An argument to Property.like(..) (or second argument 
 to ExpressionFactory.likeExp(..)) requires a full pattern to match 
 against. So people would often write their own utility code to wrap a 
 String in % signs. Cayenne can easily take care of this via the 
 following methods:


 Property.contains(string);
 // same as Property.like(% + string + %);

 Property.startsWith(string);
 // same as Property.like(string + %);

 Property.endsWith(string);
 // same as Property.like(% + string);

 In addition to saving the user from String concatenation, these new 
 methods can do proper symbol escaping, making like much safer to use.

 Andrus

Re: Chainable SelectQuery

[Mike Kienenberger]

Chainable fest testing assertions use isEqualTo to avoid confusion
with equals


On Mon, Nov 17, 2014 at 9:01 AM, Michael Gentry mgen...@masslight.net wrote:
 On Sun, Nov 16, 2014 at 9:13 AM, Andrus Adamchik and...@objectstyle.org 
 wrote:
 eq with is,

 I actually prefer eq[uals]. Considering all other operations in the 
 Property class, is creates a bit of asymmetry IMO.

 The problem with equals is it has other connotations in Java,
 otherwise I'd like it just fine.  Of course, you could argue that is
 also has other Java connotations (JavaBeans is* method naming
 convention).

 mrg

Re: Java 1.7 for 4.0 .. again

[Mike Kienenberger]

 J2EE 6 is still mainstream, and J2EE 7 is still relatively unsupported
(J2EE 7 is also only a 1.5 years old).

http://en.wikipedia.org/wiki/Java_Platform,_Enterprise_Edition#Certified_application_servers

On Sun, Oct 26, 2014 at 9:05 AM, Andrus Adamchik and...@objectstyle.org
wrote:

 So quite a bit of time has passed since our last Java 7 discussion. Java 6
 is even more distant memory now. Of which I was reminded today after I
 upgraded my laptop to Yosemite. My Modeler instance wouldn't start without
 installing legacy Java SE 6 runtime (of course I quickly switched to Java
 7 modeler and all was good). So I suggest two things, both applying to
 Cayenne 4.0 (aka 3.2) :

 1. Make Java 1.7 a minimal requirement.
 2. If #1 meets any opposition, at least stop supporting Java 6 friendly
 Modeler assembly on the Mac, which existence has no reasonable excuse
 anymore.

 Andrus

Re: Pull requests on Jenkins

[Mike Kienenberger]

I still think testng is a better choice.

And it will run junit3 tests as well.

On Thu, Oct 23, 2014 at 6:14 PM, Aristedes Maniatis a...@maniatis.org wrote:
 On 24/10/2014 3:58am, Andrus Adamchik wrote:
 No. Resetting the DB is currently hardcoded per test, so due to subtle bugs 
 in copy/paste of the boilerplate code it is order-dependent. Redoing this 
 (esp. in the view of Junit 4 upgrade) is on the list. Until then we'd chase 
 them one by one. Considering that we have hundreds of tests, this is a 
 losing battle.

 I assume you mean adding setUp where needed.

 In the meantime we can upgrade to junit 4 pretty easily. I started writing 
 some regex just now, and then stumbled on this:

 
 http://stackoverflow.com/questions/264680/best-way-to-automagically-migrate-tests-from-junit-3-to-junit-4

 Unless anyone objects, I might knock this one over when I'm not busy one day.


 Ari

 --
 --
 Aristedes Maniatis
 GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E 3E49 102A

Re: Chainable SelectQuery

[Mike Kienenberger]

I wonder if QueryBuilder is a better approach which would preserve
backwards compatibility.

On Thu, Oct 9, 2014 at 3:08 PM, Michael Gentry mgen...@masslight.net wrote:
 Yeah, I don't know if changing setXyz to *not* return 'void' would
 break things (like Tapestry).  That would be a huge downer.

 On Thu, Oct 9, 2014 at 3:03 PM, Andrus Adamchik and...@objectstyle.org 
 wrote:
 I thought of that. Unfortunately setXyz is a 'java bean' setter, so we'll 
 be redefining one of the most established Java conventions.

 Andrus

 On Oct 9, 2014, at 2:51 PM, Michael Gentry mgen...@masslight.net wrote:

 I don't know if it will be confusing or not.  At least with the
 current method names, I can type query.set[ctrl+space] and let Eclipse
 give me a list of set* method names to choose from (same applies for
 get*), but that option won't be available with the new chainable API.
 Part of me thinks just make setFetchLimit() return 'this' (at least
 where it makes sense to preserve existing API):

 query.setFetchLimit(100).setDistinct(true);

 You could continue that in the model objects, too:

 person.setFirstName(John).setLastName(Doe);

 mrg


 On Thu, Oct 9, 2014 at 1:31 PM, Andrus Adamchik and...@objectstyle.org 
 wrote:

 On Oct 7, 2014, at 9:30 PM, Michael Gentry mgen...@masslight.net wrote:

 On Tue, Oct 7, 2014 at 6:44 PM, Aristedes Maniatis a...@maniatis.org 
 wrote:
 That said, if returning this is the direction we're going, then really 
 all
 the currently void methods in SelectQuery should do the same thing - 
 like
 addOrdering for example.


 Correct, but we also need to gracefully deprecate the old methods and 
 make new fluent ones.

 I was looking at the changes and was wondering if we really need to
 deprecate the old methods.  Can't setFetchLimit() live along with
 limit()?

 I suspect having both will be rather confusing. Initially I even wanted to 
 leave SelectQuery alone and implement all the new ideas in a separate 
 query class (ObjectQuery?), but since we've already made a bunch of 
 changes to SelectQuery in the same direction, I ended up with a massive 
 change to the existing class.

 Andrus

Eclipse Static imports

[Mike Kienenberger]

John,

I had issues with static imports as well, but there is a solution.
Take a look at this url:

http://stackoverflow.com/questions/288861/eclipse-optimize-imports-to-include-static-imports

On Tue, Oct 7, 2014 at 10:31 AM, John Huss johnth...@gmail.com wrote:
 Hmm... I have a lot to say, so I might ramble a bit.

 1) Static imports

 I'll never been a big user of static imports, largely because the tooling
 (Eclipse) doesn't support them well.  Everytime I've used a static import
 (which is really only in JUnit) I've wanted to import all the members:
 import package.*;  Well, when you organize import Eclipse will replace the
 star with the specific items you've used.  So you end up have to fix the
 import over and over.  On the other side, Eclipse won't automatically add
 the static import or even recommend it based on your code, so it becomes a
 rarely used feature.

Re: 3.2 - 4

[Mike Kienenberger]

After this amount of time, I think renaming it will cause confusion
when projects which are currently running 3.2 pre-final find no
further 3.2 upgrades in the future.

And we've set a new precedent with 3.0 and 3.1, so I think we're ok
continuing down this this path.


But I don't feel strongly enough that I'd vote against it.

On Wed, Oct 1, 2014 at 8:03 AM, Andrus Adamchik and...@objectstyle.org wrote:
 There were some suggestions to rename 3.2 release to just 4. I think this is 
 a good idea, as historically each of our GA release was always a major thing. 
 No matter whether we incremented the version by 1 or by 0.1. So just throwing 
 this in here for a lazy consensus.

 Andrus

cayenne github project access

[Mike Kienenberger]

 Can someone add me to the cayenne github project so I can comment on
pull requests?

github username is the same: mkienenb

Also, should we be insisting that github patches are clean and not
containing extraneous commits?

ie,  ed8b7b0509ddfe216f035a2b7327a1b162a9167e and
8eb8defec3bc000c0a0e2c2e8f7330ce04e0c5ea dealing with the board
reports in https://github.com/apache/cayenne/pull/14/commits (CAY-1951
Support ISO-8601 date/time Strings in Expressions #14)

Re: cayenne github project access

[Mike Kienenberger]

Thanks, Ari.   After your comment, I realized that I wasn't clicking
in the right place to initiate a comment.   I was clicking on the
pencil icon rather than on the code itself.   I haven't used github
since April or March so I'm a bit out of practice.

Andrus,  I don't know that we really need a policy if we're all in
agreement and it's standard practice.

On Tue, Sep 23, 2014 at 9:47 AM, Aristedes Maniatis a...@maniatis.org wrote:
 None of us have admin rights there. But you should be able to still comment.

 Ari


 On 23/09/2014 11:16pm, Mike Kienenberger wrote:
  Can someone add me to the cayenne github project so I can comment on
 pull requests?

 github username is the same: mkienenb

 Also, should we be insisting that github patches are clean and not
 containing extraneous commits?

 ie,  ed8b7b0509ddfe216f035a2b7327a1b162a9167e and
 8eb8defec3bc000c0a0e2c2e8f7330ce04e0c5ea dealing with the board
 reports in https://github.com/apache/cayenne/pull/14/commits (CAY-1951
 Support ISO-8601 date/time Strings in Expressions #14)


 --
 --
 Aristedes Maniatis
 GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E 3E49 102A

Re: [VOTE] 3.1 final

[Mike Kienenberger]

- signatures and checksums match
- source builds
- apache rat passes

+1






Below are the linux commands I used to verify the release of the
cayenne-3.1 files:

=

# check checksums
## made with  gpg --print-md MD5 cayenne-X.X.tar.gz
cat *.md5 | tr -d ' ' | awk 'BEGIN{OFS= ; FS=:}
{tmp=$1;$1=$2;$2=tmp;print}' | md5sum -c

# check signatures
wget http://www.apache.org/dist/cayenne/KEYS
gpg --import KEYS
find . -name '*.asc' -exec gpg --verify {} \;

# verify .tar.gz and -win.zip files are identical -- flawed process
due to platform building differences
mkdir src
cd src
tar xvf ../cayenne-3.1.tar.gz
mv cayenne-3.1/ cayenne-3.1-tar-gz
unzip ../cayenne-3.1-win.zip
# should be no output
# but windows and tar package are built with different java versions.
## differences in jars, pdfs, html resources, css, html, package-info
between tar.gz and zip(win)
diff -rq cayenne-3.1* | grep -v jar differ | grep -v html differ |
grep -v pdf differ | grep -v .css differ
# should be are identical output
diff -srq cayenne-3.1* | grep -v jar differ | grep -v html differ
| grep -v pdf differ | grep -v .css differ | grep -v are
identical

# unpack source
tar xvzf ../cayenne-3.1-src.tar.gz
# build source
cd cayenne-3.1-src
mvn install

## mvn apache-rat currently unused for cayenne
./rat.sh ../../../apache-rat-0.9/apache-rat-0.9.jar
##mvn apache-rat:check
# To check for all errors, if more than one project is affected
#   mvn apache-rat:check -Drat.numUnapprovedLicenses=
# To see details of rat failure
#   mvn -e -X apache-rat:check


On Sat, Sep 20, 2014 at 11:41 AM, Andrus Adamchik
and...@objectstyle.org wrote:
 After half a day of fighting with the build system bit rot, I prepared and 
 posted release artifacts for 3.1 final. Rat and testing results were posted 
 here some time ago.

 Maven artifacts: 
 https://repository.apache.org/content/repositories/orgapachecayenne-1002
 Assemblies: https://dist.apache.org/repos/dist/dev/cayenne/3.1

 That was quite some time in the making. I am really excited to get it out.

 Please evaluate and cast your votes.

 Andrus

Checking md5 sums from a script for releases

[Mike Kienenberger]

I asked about this for the last release and the only comment was:

 Yeah, lately we've been using gpg for that instead of md5 command:

Is there a compelling reason to do this?   I have been unable to find
a simple scripted approach to validate an md5 signature produced by
gpg.

With a regular md5sum-produced file, I can use

find . -name '*.md5' -exec cat {} \; -printf '  %f\n' | sed
's|\.md5$||' | md5sum -c

and get a result for every file, no matter what the name.

The same exact approach works for sha1 signatures.

I haven't yet found a way to do with this gpg -print-md5 output,
although it could just be my own short-sightedness.

Re: Checking md5 sums from a script for releases

[Mike Kienenberger]

Never mind -- I gave up trying to used gpg to validate the md5
signature and instead rewrote the file data so that it'd go into
md5sum:

cat *.md5 | tr -d ' ' | awk 'BEGIN{OFS= ; FS=:}
{tmp=$1;$1=$2;$2=tmp;print}' | md5sum -c

That's not too bad, and I can live with that.


On Sat, Sep 20, 2014 at 5:09 PM, Mike Kienenberger mkien...@gmail.com wrote:
 I asked about this for the last release and the only comment was:

 Yeah, lately we've been using gpg for that instead of md5 command:

 Is there a compelling reason to do this?   I have been unable to find
 a simple scripted approach to validate an md5 signature produced by
 gpg.

 With a regular md5sum-produced file, I can use

 find . -name '*.md5' -exec cat {} \; -printf '  %f\n' | sed
 's|\.md5$||' | md5sum -c

 and get a result for every file, no matter what the name.

 The same exact approach works for sha1 signatures.

 I haven't yet found a way to do with this gpg -print-md5 output,
 although it could just be my own short-sightedness.

No apache-rat support for 3.1 candidate?

[Mike Kienenberger]

I've checked the signatures and checksums and successfully built the
source, but I can't get apache-rat to run.  I know I had it running
for the 3.1RC1 candidate.

[ERROR] No plugin found for prefix 'apache-rat' in the current project
and in the plugin groups [org.apache.maven.plugins, org.codehaus.mojo]
available from the repositories [local
(/home/mkienenb/.m2/repository), objectstyle
(http://maven.objectstyle.org/nexus/content/groups/cayenne-deps),
central (http://repo1.maven.org/maven2)] - [Help 1]
org.apache.maven.plugin.prefix.NoPluginFoundForPrefixException: No
plugin found for prefix 'apache-rat' in the current project and in the
plugin groups [org.apache.maven.plugins, org.codehaus.mojo] available
from the repositories [local (/home/mkienenb/.m2/repository),
objectstyle (http://maven.objectstyle.org/nexus/content/groups/cayenne-deps),
central (http://repo1.maven.org/maven2)]
at 
org.apache.maven.plugin.prefix.internal.DefaultPluginPrefixResolver.resolve(DefaultPluginPrefixResolver.java:94)
at 
org.apache.maven.lifecycle.internal.MojoDescriptorCreator.findPluginForPrefix(MojoDescriptorCreator.java:262)
at 
org.apache.maven.lifecycle.internal.MojoDescriptorCreator.getMojoDescriptor(MojoDescriptorCreator.java:222)
at 
org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments(DefaultLifecycleTaskSegmentCalculator.java:106)
at 
org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments(DefaultLifecycleTaskSegmentCalculator.java:86)
at 
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:98)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at 
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at 
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at 
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)

Re: 3.1-final test scoresheet

[Mike Kienenberger]

+1 to making the constructor protected.

On Tue, Sep 9, 2014 at 2:10 AM, Andrus Adamchik and...@objectstyle.org wrote:
 Usually we have private constructors for statics only classes (as is the case 
 here). It sort of indicates it to the end users that the class is not 
 supposed to be instantiated. While technically you won't get true 
 polymorphism by inheriting from statics-only class in Java, it may still be 
 beneficial to add more static methods to a subclass I guess. So how about we 
 change that to protected? (in 3.2?)

 Andrus


 On Sep 8, 2014, at 11:18 PM, Michael Gentry mgen...@masslight.net wrote:
 FWIW, I tried to extend the Cayenne class (we had a discussion about that
 ages ago) and even though it is no longer final, it cannot be extended
 because of the private constructor.  Should we remove the private
 constructor to allow subclassing like Apache Commons allows?

 Thanks,

 mrg


 On Sat, Sep 6, 2014 at 3:03 AM, Andrus Adamchik and...@objectstyle.org
 wrote:

 Done.

 Once I was a big fan of terse non-redundant APIs. Not anymore :) Now that
 we are moving in the direction of richer user-facing APIs, builders, etc,
 so this only makes sense to add this method back.

 Andrus


 On Sep 5, 2014, at 4:16 PM, Michael Gentry mgen...@masslight.net wrote:
 I seem to recall a discussion on that particular method years ago, but
 don't remember the details (I'd have to go back and find it).

 I'm fine with having deleteObject() just turn around and call
 deleteObjects() because it makes the calling code read better, even at
 the
 expense of cluttering up the API (although this isn't much, really).

 mrg



 On Fri, Sep 5, 2014 at 7:07 AM, Andrus Adamchik and...@objectstyle.org
 wrote:

 One possible last minute change is un-deprecating
 ObjectContext.deleteObject(..). It can easily coexist with
 'deleteObjects',
 and getting rid of it was not the best idea on my part.

 Andrus

 On Aug 30, 2014, at 9:28 PM, Andrus Adamchik and...@objectstyle.org
 wrote:

 In preparation to the 3.1-final vote, I ran the same set of tests as we
 did for RC1. All tests are on Java 1.6 unless specified otherwise. You
 can
 compare it with the previous results at
 http://markmail.org/message/slaj64iunxbeg4cs . Essentially everything
 is
 the same, so the latest 3.1 changes didn't break anything obvious.
 There's
 one less test failure on Oracle, which is related to my improved Oracle
 setup, rather than anything in Cayenne. Feel free to replicate the
 results
 in your own environment.

 rat:  PASSED
 hsql: PASSED
 h2: PASSED
 derby: PASSED
 derby/Java7: PASSED
 mysql 5.0:  [1] PASSED
 mysql 5.6:  [2] PASSED
 sqlserver  [3] PASSED
 postgresql: Failures: 1
 testBLOB(org.apache.cayenne.access.ReturnTypesMappingTest)
 oracle 11: Failed tests:
 testBIGINT(org.apache.cayenne.access.ReturnTypesMappingTest)
 testBIT(org.apache.cayenne.access.ReturnTypesMappingTest)
 testBOOLEAN(org.apache.cayenne.access.ReturnTypesMappingTest)
 testDOUBLE(org.apache.cayenne.access.ReturnTypesMappingTest)
 testFLOAT(org.apache.cayenne.access.ReturnTypesMappingTest)
 testREAL(org.apache.cayenne.access.ReturnTypesMappingTest)
 testSMALLINT(org.apache.cayenne.access.ReturnTypesMappingTest)
 testTINYINT(org.apache.cayenne.access.ReturnTypesMappingTest)

 Tests run: 2150, Failures: 8, Errors: 0, Skipped: 0

 [1] MySQL 5.0 config: [mysqld] max_allowed_packet=16M

 [2] MySQL 5.6 config: [mysqld] max_allowed_packet=16M
 lower_case_table_names = 1

 [3] SQL Server 2005 Expression config: collation -
 SQL_Latin1_general_CP1_CS_AS

 Andrus

Re: Copy/Clone Mutable Objects?

[Mike Kienenberger]

I think it would be difficult to enforce, even if we wanted to
disallow it, since any non-primitive could be mutable.

What I might do is to change my templates so that certain types, like
Date and byte[], are automatically cloned in the setter methods,
though.


On Mon, Sep 8, 2014 at 8:54 AM, Michael Gentry mgen...@masslight.net wrote:
 I think everyone is getting wrapped up around Dates.  My general question
 was about mutable types.

   byte[] data = { 1, 2, 3, 4 };
   person.setData(data);
   data[0] = 5;
   for (int i = 0; i  person.getData().length; i++)
   System.out.println(Data[ + i + ] =  + person.getData()[i]);

 Data[0] = 5

 Data[1] = 2

 Data[2] = 3

 Data[3] = 4

 Again, modifying the original value changes what is stored internally by
 Cayenne.

 Thanks,

 mrg


 On Mon, Sep 8, 2014 at 3:39 AM, Aristedes Maniatis a...@maniatis.org wrote:

 And https://github.com/ThreeTen/threetenbp for Java 6/7 users.

 Ari


 On 8/09/2014 4:42pm, Andrus Adamchik wrote:
  Also Java 8 Date and Time if Java 8 is an option:
 
 
 http://www.oracle.com/technetwork/articles/java/jf14-date-time-2125367.html
 
  Andrus
 
  On Sep 8, 2014, at 4:17 AM, John Huss johnth...@gmail.com wrote:
 
  Sure, use Joda time.
  On Sep 6, 2014 8:15 PM, Michael Gentry mgen...@masslight.net wrote:
 
  Is that a realistic option?
 
 
  On Sat, Sep 6, 2014 at 6:55 PM, John Huss johnth...@gmail.com wrote:
 
  My thoughts are: don't use Date.
  On Sep 6, 2014 4:58 PM, Michael Gentry mgen...@masslight.net
 wrote:
 
  Should Cayenne copy/clone mutable objects, such as Date?
 
  For example, if I modify a date after setting it in a Cayenne object
  (person), it modifies the value stored by Cayenne:
 
   SimpleDateFormat timeFormat = new SimpleDateFormat (-MM-dd);
   Date d1 = timeFormat.parse(2014-02-01);
   person.setStartDate(d1);
   d1.setYear(2013 - 1900); // Date hackery
   System.out.println(Start Date =  + person.getStartDate());
 
  This outputs:
 
  Start Date = Fri Feb 01 00:00:00 EST 2013
 
  I've never actually experienced an issue with Cayenne not copying a
  Date/etc, but was wondering your thoughts on this.
 
  Thanks,
 
  mrg
 
 
 
 

 --
 --
 Aristedes Maniatis
 GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E 3E49 102A

Re: Copy/Clone Mutable Objects?

[Mike Kienenberger]

Sure it will.


Object myMutableType = x;

entity.setType(myMutableType); // makes a copy of myMutableType with x value

myMutableType.changeTo(y);

(entity still has a copy that points to x rather than y)



On Mon, Sep 8, 2014 at 9:02 AM, Hugi Thordarson h...@karlmenn.is wrote:
 That won't help with mutable types, since modifying them will not use the 
 setter method.

 - hugi



 On 8.9.2014, at 12:58, Mike Kienenberger mkien...@gmail.com wrote:

 I think it would be difficult to enforce, even if we wanted to
 disallow it, since any non-primitive could be mutable.

 What I might do is to change my templates so that certain types, like
 Date and byte[], are automatically cloned in the setter methods,
 though.


 On Mon, Sep 8, 2014 at 8:54 AM, Michael Gentry mgen...@masslight.net wrote:
 I think everyone is getting wrapped up around Dates.  My general question
 was about mutable types.

  byte[] data = { 1, 2, 3, 4 };
  person.setData(data);
  data[0] = 5;
  for (int i = 0; i  person.getData().length; i++)
  System.out.println(Data[ + i + ] =  + person.getData()[i]);

 Data[0] = 5

 Data[1] = 2

 Data[2] = 3

 Data[3] = 4

 Again, modifying the original value changes what is stored internally by
 Cayenne.

 Thanks,

 mrg


 On Mon, Sep 8, 2014 at 3:39 AM, Aristedes Maniatis a...@maniatis.org 
 wrote:

 And https://github.com/ThreeTen/threetenbp for Java 6/7 users.

 Ari


 On 8/09/2014 4:42pm, Andrus Adamchik wrote:
 Also Java 8 Date and Time if Java 8 is an option:


 http://www.oracle.com/technetwork/articles/java/jf14-date-time-2125367.html

 Andrus

 On Sep 8, 2014, at 4:17 AM, John Huss johnth...@gmail.com wrote:

 Sure, use Joda time.
 On Sep 6, 2014 8:15 PM, Michael Gentry mgen...@masslight.net wrote:

 Is that a realistic option?


 On Sat, Sep 6, 2014 at 6:55 PM, John Huss johnth...@gmail.com wrote:

 My thoughts are: don't use Date.
 On Sep 6, 2014 4:58 PM, Michael Gentry mgen...@masslight.net
 wrote:

 Should Cayenne copy/clone mutable objects, such as Date?

 For example, if I modify a date after setting it in a Cayenne object
 (person), it modifies the value stored by Cayenne:

 SimpleDateFormat timeFormat = new SimpleDateFormat (-MM-dd);
 Date d1 = timeFormat.parse(2014-02-01);
 person.setStartDate(d1);
 d1.setYear(2013 - 1900); // Date hackery
 System.out.println(Start Date =  + person.getStartDate());

 This outputs:

 Start Date = Fri Feb 01 00:00:00 EST 2013

 I've never actually experienced an issue with Cayenne not copying a
 Date/etc, but was wondering your thoughts on this.

 Thanks,

 mrg





 --
 --
 Aristedes Maniatis
 GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E 3E49 102A

Re: GitHub

[Mike Kienenberger]

This is all I remember on the topic:




-- Forwarded message --
From: Noah Slater nsla...@apache.org
Date: Mon, Jan 20, 2014 at 6:23 AM
Subject: Show off your Apache affiliation on GitHub
To: committ...@apache.org


Hi folks,

We're now adding committers with GitHub accounts to the Apache GitHub
organisation.

Note: all this does is let you display your Apache affiliation on your
GitHub profile. Committers WILL NOT be granted write access to the
GitHub organisation, or any of the mirrors it contains. This is for
vanity purposes only! :)

If you want to be added, edit this file:

https://svn.apache.org/repos/private/committers/docs/github_team.txt

And add a line like this:

Committer ID: nslater - Name: Noah Slater - GitHub ID:nslater

Please also note: this is a LOW PRIORITY task for the infrastructure
team, so please be patient. You will be added eventually! :)

(You may want to add a note about this to your project's new
committers guide. It's probably also worth mentioning that if you want
your Apache contributions to show up on your GitHub profile, you need
to star the GitHub mirrors you have contributed to.)

Enjoy, and happy GitHubbing...

--
Noah Slater
https://twitter.com/nslater



On Thu, Sep 4, 2014 at 9:53 AM, Andrus Adamchik and...@objectstyle.org wrote:
 Anyone knows how to map Apache accounts to GitHub accounts?

 It appears that most of our committers are mapped properly (even if their 
 account IDs are different between github and apache) [1]. Mine is not, Tore's 
 is not. John's shows just one commit.

 Or is this an infra question (?)

 Andrus

 [1] https://github.com/apache/cayenne/graphs/contributors

Re: LGPL unit test dependencies - can we use them?

[Mike Kienenberger]

http://www.apache.org/legal/resolved.html#prohibited

Can Apache projects rely on components under prohibited licenses?

Apache projects cannot distribute any such components. As with the
previous question on platforms, the component can be relied on if the
component's licence terms do not affect the Apache product's
licensing. For example, using a GPL'ed tool during the build is OK.

Can Apache projects rely on components whose licensing affects the
Apache product?

Apache projects cannot distribute any such components. However, if the
component is only needed for optional features, a project can provide
the user with instructions on how to obtain and install the
non-included work. Optional means that the component is not required
for standard use of the product or for the product to achieve a
desirable level of quality. The question to ask yourself in this
situation is:

Will the majority of users want to use my product without adding the
optional components?



It's hard to tell without seeing the committed files, but is this
dependency referenced by anything outside of the build scripts/config
files?

If it is only used indirectly by our build process, then we probably
can have it as a dependency.

If it is directly referenced by our tests, then I would say we should
not have this as a dependency, since any code that references it is
now polluted by the viral nature of LGPL.


On Sat, Aug 30, 2014 at 7:21 AM, Andrus Adamchik and...@objectstyle.org wrote:
 Another one of Alex's patches adds a scopetest/scope dependency on 
 org.fluttercode.datafactory:datafactory, which helps assembling complex test 
 object trees. One caveat is that Datafactory is under LGPL:

 https://github.com/andygibson/datafactory/blob/master/license.txt

 I am about 80% certain that this is ok for a unit test dependency, but maybe 
 someone knows of precedents on other apache projects and can confirm this?

 Andrus

Re: Warning from u...@cayenne.apache.org

[Mike Kienenberger]

Andrus's user mailing list test message bounced for me, which is
pretty strange.   Never had that happen before so far as I know.

On Thu, May 29, 2014 at 5:45 AM,  user-h...@cayenne.apache.org wrote:
 Hi! This is the ezmlm program. I'm managing the
 u...@cayenne.apache.org mailing list.

 I'm working for my owner, who can be reached
 at user-ow...@cayenne.apache.org.


 Messages to you from the user mailing list seem to
 have been bouncing. I've attached a copy of the first bounce
 message I received.

 If this message bounces too, I will send you a probe. If the probe bounces,
 I will remove your address from the user mailing list,
 without further notice.


 I've kept a list of which messages from the user mailing list have
 bounced from your address.

 Copies of these messages may be in the archive.
 To retrieve a set of messages 123-145 (a maximum of 100 per request),
 send a short message to:
user-get.123_...@cayenne.apache.org

 To receive a subject and author list for the last 100 or so messages,
 send a short message to:
user-in...@cayenne.apache.org

 Here are the message numbers:

10265

 --- Enclosed is a copy of the bounce message I received.

 Return-Path: 
 Received: (qmail 94965 invoked for bounce); 17 May 2014 02:12:23 -
 Date: 17 May 2014 02:12:23 -
 From: mailer-dae...@apache.org
 To: user-return-102...@cayenne.apache.org
 Subject: failure notice

Re: Git leftovers

[Mike Kienenberger]

One of the projects I work with has jenkins polling Git on github
(several dozen different git repos, in fact).   I can ask how that's
done if it's not something specific to github.

On Wed, May 14, 2014 at 12:36 PM, Andrus Adamchik
and...@objectstyle.org wrote:
 There are a few unresolved smaller issues with Git migration that are being 
 discussed under INFRA-5936. On our end we need to reconfigure Jenkins to poll 
 Git instead of SVN. Anyone knows how to do that?

 Andrus

Re: Git leftovers

[Mike Kienenberger]

Maybe this helps?

-- Forwarded message --
From: Rasmus Praestholm
Date: Wed, May 14, 2014 at 2:46 PM
Subject: Fwd: Mike Kienenberger started a conversation with you:
Jenkins polling git

[...]

Maybe I'm missing some info, but using Git instead of SVN should be a
piece of cake simply with the plain Git (rather than GitHub) plugin
installed:

https://wiki.jenkins-ci.org/display/JENKINS/Git+Plugin

We actually used standard Git polling for the Terasology builds for a
while before switching to push notifications from GitHub. Easy easy
:-)

[...]

Is the Git repo in good shape now or still in need of more trimming /
etc ? From what I'm reading the GitHub front is just a mirror of an
Apache hosted Git ? Which may still be connected to SVN


On Wed, May 14, 2014 at 1:48 PM, Mike Kienenberger mkien...@gmail.com wrote:
 One of the projects I work with has jenkins polling Git on github
 (several dozen different git repos, in fact).   I can ask how that's
 done if it's not something specific to github.

 On Wed, May 14, 2014 at 12:36 PM, Andrus Adamchik
 and...@objectstyle.org wrote:
 There are a few unresolved smaller issues with Git migration that are being 
 discussed under INFRA-5936. On our end we need to reconfigure Jenkins to 
 poll Git instead of SVN. Anyone knows how to do that?

 Andrus

Re: Upgraded to JUnit 4

[Mike Kienenberger]

For what it's worth, I upgraded my cayenne project from junit 3.8.1 to
junit4 a couple of weeks ago.

After a couple of days, I decided that upgrading to TestNG made more
sense, as it supports everything that junit4 did plus a lot more.  The
latest versions of TestNG will also run junit tests -- all 1500 of my
tests are running under it.

A couple of other testing libraries that I have found to be extremely
helpful are Mockito and fest.   Mockito has greatly reduced the amount
of work I needed to write tests, and fest has made the assertions
human-readable.  No more wondering whether I switched expected with
actual.



On Sat, Mar 29, 2014 at 7:30 AM, Andrus Adamchik and...@objectstyle.org wrote:
 Just committed JUnit upgrade to version 4.11 from the ancient 3.8.1.

 Was pleasantly surprised that it is fully backwards compatible, so we don't 
 need to rewrite all our existing tests to use annotations. I had to do some 
 non-test file renaming though, so that surefire-plugin does not attempt to 
 run them as tests.

 So for now it is business as usual, but we have the ability to use all the 
 new features in JUnit 4, and eventually clean up our cross-DB test hacks.

 Andrus

Re: Upgraded to JUnit 4

[Mike Kienenberger]

Test dependencies is probably the biggest one.

Tests grouping (easier in TestNG)

Parameterized Tests (easier in TestNG, although I haven't used this
one yet, but I have several junit3 tests that try to do similar
things)

Lots of small things, like not requiring static methods in TestNG for
certain kinds of setup.



On Sat, Mar 29, 2014 at 11:46 AM, Andrus Adamchik
and...@objectstyle.org wrote:
 We are using Mockito in Cayenne.

 As for TestNG, I recall we did a research some time ago and found a few 
 things that we might take advantage of in Cayenne. Just don't remember what 
 those are :)

 Andrus

 On Mar 29, 2014, at 4:00 PM, Mike Kienenberger mkien...@gmail.com wrote:

 For what it's worth, I upgraded my cayenne project from junit 3.8.1 to
 junit4 a couple of weeks ago.

 After a couple of days, I decided that upgrading to TestNG made more
 sense, as it supports everything that junit4 did plus a lot more.  The
 latest versions of TestNG will also run junit tests -- all 1500 of my
 tests are running under it.

 A couple of other testing libraries that I have found to be extremely
 helpful are Mockito and fest.   Mockito has greatly reduced the amount
 of work I needed to write tests, and fest has made the assertions
 human-readable.  No more wondering whether I switched expected with
 actual.



 On Sat, Mar 29, 2014 at 7:30 AM, Andrus Adamchik and...@objectstyle.org 
 wrote:
 Just committed JUnit upgrade to version 4.11 from the ancient 3.8.1.

 Was pleasantly surprised that it is fully backwards compatible, so we don't 
 need to rewrite all our existing tests to use annotations. I had to do some 
 non-test file renaming though, so that surefire-plugin does not attempt to 
 run them as tests.

 So for now it is business as usual, but we have the ability to use all the 
 new features in JUnit 4, and eventually clean up our cross-DB test hacks.

 Andrus

Re: Java 8

[Mike Kienenberger]

Unless there is a compelling reason, I would not stop supporting Java
6 on 3.2.   Most of the app servers out there still require Java 6
when I looked last month --
http://en.wikipedia.org/wiki/Comparison_of_application_servers

My primary client is once again considering switching from JPA to
Cayenne, and all of our Oracle app servers run Java 6.   More on this
possibility on a separate thread.

On Fri, Mar 21, 2014 at 10:51 AM, Andrus Adamchik
and...@objectstyle.org wrote:
 Oh, nice! I missed the announcement.

 [ERROR] * Implementation of {@link #BatchQueryBuilderFactory}, which uses

 Should be BatchTranslator. This is a recent refactoring.

 [ERROR]
 /Users/john/cayenne/modeler/cayenne-modeler-mac-ext/src/main/java/org/apache/cayenne/modeler/osx/OSXPlatformInitializer.java:[39,21]
 error: package com.apple.eawt does not exist

 Yeah, this worked with Oracle Java 7, so there's gotta be a way to make it 
 work.

 I wonder if we use this occasion to stop supporting Java 6 on 3.2. This is 
 such an old news. Anyways just throwing it here to see if anyone has strong 
 objections.

 Andrus



 On Mar 21, 2014, at 5:38 PM, John Huss johnth...@gmail.com wrote:

 Still Java 8 just came out I decided to try and compile Cayenne using it
 (oracle version).  The code compiled without a problem.  There were a bunch
 of javadoc issues that caused that part to fail so I fixed all those except
 this one (since I'm not sure what to change it to):

 [ERROR]
 /Users/john/cayenne/docs/doc/target/sources/org/apache/cayenne/access/translator/batch/SoftDeleteTranslatorFactory.java:28:
 error: reference not found
 [ERROR] * Implementation of {@link #BatchQueryBuilderFactory}, which uses
 'soft' delete
 [ERROR] ^


 Then the modeler failed to build on Mac because it couldn't find
 com.apple.eawt:

 [ERROR] Failed to execute goal
 org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile
 (default-compile) on project cayenne-modeler-mac-ext: Compilation failure:
 Compilation failure:
 [ERROR]
 /Users/john/cayenne/modeler/cayenne-modeler-mac-ext/src/main/java/org/apache/cayenne/modeler/osx/OSXPlatformInitializer.java:[39,21]
 error: package com.apple.eawt does not exist

 This package (and the classes) DOES exist in rt.jar, so for some reason it
 is just not finding it.  If I comment out the apple code then the entire
 build completes successfully.


 John

Re: Interceptable ExtendedType

[Mike Kienenberger]

For what it's worth, I'm doing the same thing for our JPA app.

I store the encryption version number (unencrypted), then an encrypted
set of data fields.

We found that trying to encrypt individual fields wasn't as helpful
since the length and variety of individual columns tended not to be
all that unique.
Padding with random characters can help, but encrypting more fields
together in a single column seemed more appropriate in our case,
especially since you can't do any meaningful sql on the encrypted data
anyway.

Here's the api I ended up going with:

class DataBlockEncryptionManager {

public DataBlockEncryptionManager(EncryptionVersionProvider
encryptionVersionProvider)

/**
 * encrypt item in encrypted data block.
 *
 * @param encryptedData String containing previous encrypted
block, null to create new block
 * @param itemIndex from 0 to last item of item to encrypt
 * @param newValue to add to block
 * @return String containing encrypted block
 * @throws EncryptionException
 */
public String encryptDataBlock(String encryptedData, int
itemIndex, char[] newValue);

public char[] decryptDataBlock(String encryptedData, int
itemIndex) throws EncryptionException;

public interface EncryptionVersionProvider
{
/** Default version to use for new encryptions */
public String getDefaultVersion();

// with a few methods like these depending on our encryption
public String _xyzEncryptionProperty_ForVersion(String version);

}

}

then, assuming your column is named ENCRYPTED_DATA, your individual
attributes look like this:

public char[] getName() throws EncryptionException {
return decryptDataBlock(getEncryptedData(), ITEM_INDEX__NAME);
}
public void setName(char[] holderFirstName) throws EncryptionException {
String newData = encryptDataBlock(getEncryptedData(),
ITEM_INDEX__NAME, name);
setEncryptedData(newData);
}




On Thu, Mar 13, 2014 at 4:18 AM, Andrus Adamchik and...@objectstyle.org wrote:


 On Mar 13, 2014, at 11:06 AM, Aristedes Maniatis a...@maniatis.org wrote:

 On 13/03/2014 6:31pm, Andrus Adamchik wrote:

 On Mar 13, 2014, at 10:05 AM, Aristedes Maniatis a...@maniatis.org wrote:

 It would be nice public relations to have Cayenne has out-of-the-box 
 crypto support as a feature. Are you storing a key version as part of the 
 encrypted data stream?

 I am still working on this piece actually. It has to be attached to the 
 record. The question is whether we keep it unencrypted (simplifies 
 management and migration between keys), or encrypt it together with the 
 data (more secure).


 I don't see any value in encrypting it. What security does that create? 
 Also, keeping it in the same database column makes for simpler storage and 
 robustness. Much like storing the salt with a password hash, or the hashing 
 algorithm with the password in LDAP:

 86gwfku:tgiynv45zpyqaqqpucnp3f8k8uk3dzqy

 {SSHA}ddrd686254iteu9gqsz4aztufkgbctuz

 yeah, perhaps you are right. Encrypting it doesn't provide better protection 
 from brute-force attacks on the key. Just some obfuscation.

 Andrus

Re: Interceptable ExtendedType

[Mike Kienenberger]

Whoops.  hit send too soon.  Then an a superclass for all entities:

/**
 * do nothing, override in subclass
 */
protected EncryptionVersionProvider getEncryptionVersionProvider()
{
throw new RuntimeException(getEncryptionVersionProvider()
must be overridden in subclass);
}

protected char[] decryptDataBlock(String encryptedData, int itemIndex)
throws EncryptionException
{
DataBlockEncryptionManager dataBlockEncryptionManager = new
DataBlockEncryptionManager(getEncryptionVersionProvider());
return dataBlockEncryptionManager.decryptDataBlock(encryptedData,
itemIndex);
}

protected String encryptDataBlock(String encryptedData, int
itemIndex, char[] newValue)
throws EncryptionException
{
DataBlockEncryptionManager dataBlockEncryptionManager = new
DataBlockEncryptionManager(getEncryptionVersionProvider());
return dataBlockEncryptionManager.encryptDataBlock(encryptedData,
itemIndex, newValue);
}

Obviously, you can do whatever you like to for
getEncryptionVersionProvider(), but we went with this to allow each
entity to have a separate encryption provider.

On Thu, Mar 13, 2014 at 8:13 AM, Mike Kienenberger mkien...@gmail.com wrote:
 For what it's worth, I'm doing the same thing for our JPA app.

 I store the encryption version number (unencrypted), then an encrypted
 set of data fields.

 We found that trying to encrypt individual fields wasn't as helpful
 since the length and variety of individual columns tended not to be
 all that unique.
 Padding with random characters can help, but encrypting more fields
 together in a single column seemed more appropriate in our case,
 especially since you can't do any meaningful sql on the encrypted data
 anyway.

 Here's the api I ended up going with:

 class DataBlockEncryptionManager {

 public DataBlockEncryptionManager(EncryptionVersionProvider
 encryptionVersionProvider)

 /**
  * encrypt item in encrypted data block.
  *
  * @param encryptedData String containing previous encrypted
 block, null to create new block
  * @param itemIndex from 0 to last item of item to encrypt
  * @param newValue to add to block
  * @return String containing encrypted block
  * @throws EncryptionException
  */
 public String encryptDataBlock(String encryptedData, int
 itemIndex, char[] newValue);

 public char[] decryptDataBlock(String encryptedData, int
 itemIndex) throws EncryptionException;

 public interface EncryptionVersionProvider
 {
 /** Default version to use for new encryptions */
 public String getDefaultVersion();

 // with a few methods like these depending on our encryption
 public String _xyzEncryptionProperty_ForVersion(String version);

 }

 }

 then, assuming your column is named ENCRYPTED_DATA, your individual
 attributes look like this:

 public char[] getName() throws EncryptionException {
 return decryptDataBlock(getEncryptedData(), ITEM_INDEX__NAME);
 }
 public void setName(char[] holderFirstName) throws EncryptionException {
 String newData = encryptDataBlock(getEncryptedData(),
 ITEM_INDEX__NAME, name);
 setEncryptedData(newData);
 }




 On Thu, Mar 13, 2014 at 4:18 AM, Andrus Adamchik and...@objectstyle.org 
 wrote:


 On Mar 13, 2014, at 11:06 AM, Aristedes Maniatis a...@maniatis.org wrote:

 On 13/03/2014 6:31pm, Andrus Adamchik wrote:

 On Mar 13, 2014, at 10:05 AM, Aristedes Maniatis a...@maniatis.org wrote:

 It would be nice public relations to have Cayenne has out-of-the-box 
 crypto support as a feature. Are you storing a key version as part of 
 the encrypted data stream?

 I am still working on this piece actually. It has to be attached to the 
 record. The question is whether we keep it unencrypted (simplifies 
 management and migration between keys), or encrypt it together with the 
 data (more secure).


 I don't see any value in encrypting it. What security does that create? 
 Also, keeping it in the same database column makes for simpler storage and 
 robustness. Much like storing the salt with a password hash, or the hashing 
 algorithm with the password in LDAP:

 86gwfku:tgiynv45zpyqaqqpucnp3f8k8uk3dzqy

 {SSHA}ddrd686254iteu9gqsz4aztufkgbctuz

 yeah, perhaps you are right. Encrypting it doesn't provide better protection 
 from brute-force attacks on the key. Just some obfuscation.

 Andrus

Re: [VOTE] 3.1RC1

[Mike Kienenberger]

No, that's fine.  It shouldn't block the release.

I'd prefer we used the same jdk to build the release for all systems,
but perhaps that's not practical.



On Tue, Feb 18, 2014 at 9:57 AM, Andrus Adamchik and...@objectstyle.org wrote:
 So Mike, unless you'd like to follow up on that cross-JDK binary build, I am 
 going to post a release announcement on user@. To me the important piece that 
 guarantees valid binary assemblies regardless of JDK is this:

 plugin
 artifactIdmaven-compiler-plugin/artifactId
 version2.3.2/version
 configuration
 source1.5/source
 target1.5/target
 /configuration
 /plugin


 Andrus

 On Feb 16, 2014, at 10:37 PM, Andrus Adamchik and...@objectstyle.org wrote:

 Sorry, I should've waited for your vote and thanks a lot for doing a 
 thorough review.

 checksums match: check (Did we change our md5 formats? The current

 Yeah, lately we've been using gpg for that instead of md5 command:

 gpg --print-md MD5 cayenne-X.X.tar.gz

 Turns out we built the zip versions with
 java 1.6 and the tar.gz versions with java 1.7!  not sure exactly how
 that happened, but I wouldn't think we should be releasing like this!
 Users will potentially have different results depending on whether
 they grabbed the zip or the tar.gz, and I know that I'm not always
 particular about which format I use.   Will the 1.7 jar files work on
 a 1.6 JRE?


 Of course. The same set of sources is used on Mac to build .dmg and .tar.gz 
 and then on Windows to build .zip. My two envs happened to have different 
 JDKs. So that's causing these small difference. I'd say there are no 
 essential differences to worry about (although I'll try to keep my JDKs in 
 sync across platforms in the future).

 In fact we make a claim that Cayenne 3.1 is compatible with Java 1.5. So if 
 there was no backwards compatibility, we would've been forced to use JDK 
 1.5. If we actually see a problem, we should definitely pull the binary and 
 redo it, but I don't think we will.

 Andrus


 On Feb 16, 2014, at 9:02 PM, Mike Kienenberger mkien...@gmail.com wrote:
 I didn't realized the vote was closed, and finally finished my review today:

 Source provided: check
 checksums match: check (Did we change our md5 formats? The current
 format doesn't feed back into md5sum)
 signatures match: check
 Source builds: check
 appropriately licensed: checked by rat

 My src jar builds match the tar.gz versions (except for timestamps),
 but not the zip versions.   Turns out we built the zip versions with
 java 1.6 and the tar.gz versions with java 1.7!   not sure exactly how
 that happened, but I wouldn't think we should be releasing like this!
 Users will potentially have different results depending on whether
 they grabbed the zip or the tar.gz, and I know that I'm not always
 particular about which format I use.   Will the 1.7 jar files work on
 a 1.6 JRE?





 On Sat, Feb 15, 2014 at 11:17 PM, Andrus Adamchik
 and...@objectstyle.org wrote:
 I am adding my +1. And I am closing the vote. Here is the list of votes:

 John Huss +1
 Aristedes Maniatis +1
 Michael Gentry +1
 Andrus Adamchik +1

 We have 4 +1s and no other votes, so the release becomes official. I will 
 post the files now and update the downloads page.

 Thanks everyone, and let's get ready for 3.2 vote soon :)

 Andrus

Release differences?

[Mike Kienenberger]

I compared the cayenne-3.1RC1.tar.gz release with the
cayenne-3.1RC1.zip and was surprised by the number of differences.

The html, css, package-list is all different.   That's 1786 lines.
These seem to be line ending issues.

The jar files are different.   Maybe this is just due to our build
process using different date stamps?

Files cayenne-3.1RC1-tar-gz/bin/CayenneModeler.jar and
cayenne-3.1RC1-win/bin/CayenneModeler.jar differ
Files cayenne-3.1RC1-tar-gz/lib/cayenne-client-3.1RC1.jar and
cayenne-3.1RC1-win/lib/cayenne-client-3.1RC1.jar differ
Files cayenne-3.1RC1-tar-gz/lib/cayenne-lifecycle-3.1RC1.jar and
cayenne-3.1RC1-win/lib/cayenne-lifecycle-3.1RC1.jar differ
Files cayenne-3.1RC1-tar-gz/lib/cayenne-server-3.1RC1.jar and
cayenne-3.1RC1-win/lib/cayenne-server-3.1RC1.jar differ
Files cayenne-3.1RC1-tar-gz/lib/cayenne-tools-3.1RC1.jar and
cayenne-3.1RC1-win/lib/cayenne-tools-3.1RC1.jar differ


The pdf files are different -- this one was unexpected, but again,
maybe due to these being build artifacts with different date stamps?

Files cayenne-3.1RC1-tar-gz/doc/cayenne-guide.pdf and
cayenne-3.1RC1-win/doc/cayenne-guide.pdf differ
Files cayenne-3.1RC1-tar-gz/doc/getting-started.pdf and
cayenne-3.1RC1-win/doc/getting-started.pdf differ
Files cayenne-3.1RC1-tar-gz/doc/getting-started-rop.pdf and
cayenne-3.1RC1-win/doc/getting-started-rop.pdf differ
Files cayenne-3.1RC1-tar-gz/doc/upgrade-guide.pdf and
cayenne-3.1RC1-win/doc/upgrade-guide.pdf differ


Lastly, the resources used by the api docs are different.  This is the
one that seems like it's the biggest concern.

Only in cayenne-3.1RC1-tar-gz/doc/api/resources: background.gif
Only in cayenne-3.1RC1-win/doc/api/resources: inherit.gif
Only in cayenne-3.1RC1-tar-gz/doc/api/resources: tab.gif
Only in cayenne-3.1RC1-tar-gz/doc/api/resources: titlebar_end.gif
Only in cayenne-3.1RC1-tar-gz/doc/api/resources: titlebar.gif

Re: [VOTE] 3.1RC1

[Mike Kienenberger]

I didn't realized the vote was closed, and finally finished my review today:

Source provided: check
checksums match: check (Did we change our md5 formats? The current
format doesn't feed back into md5sum)
signatures match: check
Source builds: check
appropriately licensed: checked by rat

My src jar builds match the tar.gz versions (except for timestamps),
but not the zip versions.   Turns out we built the zip versions with
java 1.6 and the tar.gz versions with java 1.7!   not sure exactly how
that happened, but I wouldn't think we should be releasing like this!
 Users will potentially have different results depending on whether
they grabbed the zip or the tar.gz, and I know that I'm not always
particular about which format I use.   Will the 1.7 jar files work on
a 1.6 JRE?





On Sat, Feb 15, 2014 at 11:17 PM, Andrus Adamchik
and...@objectstyle.org wrote:
 I am adding my +1. And I am closing the vote. Here is the list of votes:

 John Huss +1
 Aristedes Maniatis +1
 Michael Gentry +1
 Andrus Adamchik +1

 We have 4 +1s and no other votes, so the release becomes official. I will 
 post the files now and update the downloads page.

 Thanks everyone, and let's get ready for 3.2 vote soon :)

 Andrus

Re: SonarQube Analysis

[Mike Kienenberger]

On Thu, Jan 30, 2014 at 12:32 PM, Andrus Adamchik
and...@objectstyle.org wrote:
 According to this we are completely awesome :) Everything is an A.

Not quite.  I clicked on a few things, not sure what they would do,
and came here:

http://nemo.sonarqube.org/drilldown/measures/330106?metric=sqale_rating

No access to datamap for a datamap template in 3.x?

[Mike Kienenberger]

Is it just me, or has the cgen templating been rewritten so that in
datamap mode, you can't actually access the datamap?  Instead, you can
only access some datamap query information.

That defeats the entire point of that mode.   I called it datamap
mode for a reason, not datamap-queries :-)

I was using this mode to generate DAO pattern objects, which requires
being able to iterate over all of the entities in a datamap.

Changes (probably between 1.1 and 1.2) in how Cayenne handles fetching relationships (overzealous now)

[Mike Kienenberger]

In the old days (1.1), a relationship to a table that didn't exist in
the current database and wasn't referenced explicitly by the java code
wasn't an issue.  But after my upgrade to 1.2/2.0/3.0 ending at 3.1, I
noticed that cayenne would generate relationship queries for these
items even when they were not necessary.

For awhile, I was able to deal with this by explicitly checking for
known bad relationships by detecting them and returning null.

public Query willPerformQuery(DataContext dataContext, Query query) {

if (query instanceof RelationshipQuery) {
RelationshipQuery relationshipQuery = (RelationshipQuery)query;
if (we_know_the_relationships_are_not_used_by_this_deployment) {
if
(Account.equals(relationshipQuery.getObjectId().getEntityName())) {
if
(accountBadRelationshipNameForThisDeployment.equals(relationshipQuery.getRelationshipName()))
{
// do nothing
return null;
}
}

But then I started to hit them for relationships being internally
generated by Cayenne, which is even more frustrating as these are now
relationships not used by any of my code in any situation, and I can't
detect them and ignore them any more.

It seems rather odd to me that we are executing database queries
against relationships which the end-user doesn't even define as an
ObjRelationship.

I am probably going to just create a separate datamap for each
deployment type (there are currently only two) rather than fight this
any more.   The timing is somewhat right as the application originally
ran at two divisions of the same company, and those have now split
into two separate companies and there is a desire to maintain the code
separately.   But it still seems as if this is a problem that Cayenne
should not be creating and has performance and efficiency issues.


Ebpp DEBUG [btpool0-14 01-01 10:09:28]
RestrictingQualifierDataContextDelegate: in
RestrictingQualifierDataContextDelegate.willPerformQuery(DataContext,
Query)
Ebpp DEBUG [btpool0-14 01-01 10:09:28]
RestrictingQualifierDataContextDelegate:
relationshipQuery.getRelationshipName()=runtimeRelationship2
Ebpp DEBUG [btpool0-14 01-01 10:09:28]
RestrictingQualifierDataContextDelegate:
relationshipQuery.getObjectId().getEntityName()=Account
Ebpp INFO  [btpool0-14 01-01 10:09:28] CommonsJdbcEventLogger: ---
transaction started.

Ebpp INFO  [btpool0-14 01-01 10:09:28] CommonsJdbcEventLogger: SELECT
DISTINCT t0.ALTITUDE AS c0, t0.DOOR_HANGER_NUMBER AS c1,
t0.INVALIDATED AS c2, t0.INVALIDATED_DATE AS c3,
t0.IS_ADDED_TO_MAP_DATABASE AS c4, t0.LATITUDE AS c5, t0.LONGITUDE AS
c6, t0.ID AS c7, t0.SERVICE_ADDRESS_ID AS c8, t0.TAX_DISTRICT_ID AS c9
FROM PREMISE t0 JOIN ACCOUNT_THISTABLEDOESNOTEXIST t1 ON (t0.ID =
t1.PREMISE_ID) WHERE t1.ID = ? [bind: 1:58401]
Ebpp INFO  [btpool0-14 01-01 10:09:28] CommonsJdbcEventLogger: *** error.
java.sql.SQLException: ORA-00942: table or view does not exist
[...]
at 
org.apache.cayenne.access.jdbc.SelectAction.performAction(SelectAction.java:75)
at 
org.apache.cayenne.access.DataNodeQueryAction.runQuery(DataNodeQueryAction.java:87)
at org.apache.cayenne.access.DataNode.performQueries(DataNode.java:280)
at 
org.apache.cayenne.access.DataDomainQueryAction.runQuery(DataDomainQueryAction.java:442)
at 
org.apache.cayenne.access.DataDomainQueryAction.access$000(DataDomainQueryAction.java:70)
at 
org.apache.cayenne.access.DataDomainQueryAction$2.transform(DataDomainQueryAction.java:415)
at 
org.apache.cayenne.access.DataDomain.runInTransaction(DataDomain.java:877)
at 
org.apache.cayenne.access.DataDomainQueryAction.runQueryInTransaction(DataDomainQueryAction.java:412)
at 
org.apache.cayenne.access.DataDomainQueryAction.execute(DataDomainQueryAction.java:122)
at 
org.apache.cayenne.access.DataDomain.onQueryNoFilters(DataDomain.java:758)
at 
org.apache.cayenne.access.DataDomain$DataDomainQueryFilterChain.onQuery(DataDomain.java:1009)
at org.apache.cayenne.access.DataDomain.onQuery(DataDomain.java:748)
at 
org.apache.cayenne.util.ObjectContextQueryAction.runQuery(ObjectContextQueryAction.java:350)
at 
org.apache.cayenne.util.ObjectContextQueryAction.executePostCache(ObjectContextQueryAction.java:106)
at 
org.apache.cayenne.util.ObjectContextQueryAction.execute(ObjectContextQueryAction.java:93)
at org.apache.cayenne.access.DataContext.onQuery(DataContext.java:989)
at org.apache.cayenne.access.DataContext.performQuery(DataContext.java:978)
at org.apache.cayenne.access.ToOneFault.doResolveFault(ToOneFault.java:81)
at org.apache.cayenne.access.ToOneFault.resolveFault(ToOneFault.java:54)
at 
org.apache.cayenne.CayenneDataObject.readProperty(CayenneDataObject.java:186)
at 
org.apache.cayenne.reflect.generic.DataObjectBaseProperty.readProperty(DataObjectBaseProperty.java:43)
at 

Re: Build failed in Jenkins: Cayenne-trunk » derby,JDK 1.6 (latest),Ubuntu #980

[Mike Kienenberger]

I recommend we add a supports sequences method.  I've seen this in
other frameworks like JPA.

On Fri, Dec 20, 2013 at 12:23 PM, Andrus Adamchik
and...@objectstyle.org wrote:
 “DbAdapter.supportsGeneratedKeys” is an unrelated dimension of PK generation. 
 This is what is called AUTO_INCREMENT columns on MySQL [1], and 
 “GeneratedKeys” in JDBC [2]. This is a very cool and “modern” way for 
 generating PK, regardless of the primary PK gen strategy employed by a given 
 adapter. For one thing it does not require any extraneous objects to be 
 present in DB (sequences, key lookup tables).

 However this is unrelated to what you are trying to figure out. Unfortunately 
 there’s no “sequence” flag … Sequence vs. AUTO_PK_SUPPORT is more of a opaque 
 strategy than a property of the adapter.

 Friday night here, so unfortunately don’t have any ready-to-use ideas to 
 suggest in your situation..

 Andrus

 [1] http://dev.mysql.com/doc/refman/5.6/en/example-auto-increment.html
 [2] 
 http://docs.oracle.com/javase/7/docs/api/java/sql/Statement.html#getGeneratedKeys%28%29


 On Dec 20, 2013, at 7:19 PM, John Huss johnth...@gmail.com wrote:

 I could use some guidance here.  I'm needing to distinguish between
 DbAdapters that support native sequence generation and those that use the
 AUTO_PK_SUPPORT table.  I see DbAdapter.supportsGeneratedKeys, but this is
 not true for Oracle, Postgres, etc, so I'm wondering if this is a reliable
 source.


 The reason I need to distinguish is that calling

 pkGenerator.dropAutoPk(node, Collections.singletonList(artistEntity));

 for an adapter that uses AUTO_PK_SUPPORT drops the whole table not just
 support for a single entity,which makes recreating support for a single
 table not possible.  Fixing this instead would be the ideal solution, but
 I'll settle for the other.



 On Thu, Dec 19, 2013 at 7:01 PM, Apache Jenkins Server 
 jenk...@builds.apache.org wrote:

 See 
 https://builds.apache.org/job/Cayenne-trunk/cayenneTestConnection=derby,jdk=JDK%201.6%20(latest),label=Ubuntu/980/changes


 Changes:

 [johnthuss] Fix overriding starting values for several PkGenerators; fix
 JdbcPkGeneratorTest

 --
 [...truncated 81215 lines...]
 Dec 20, 2013 1:01:42 AM org.apache.cayenne.test.jdbc.UtilityLogger log
 INFO: INSERT INTO PAINTING (PAINTING_ID, ARTIST_ID, PAINTING_TITLE,
 ESTIMATED_PRICE) VALUES (?, ?, ?, ?)
 Dec 20, 2013 1:01:42 AM org.apache.cayenne.log.CommonsJdbcEventLogger
 logBeginTransaction
 INFO: --- transaction started.
 Dec 20, 2013 1:01:42 AM org.apache.cayenne.log.CommonsJdbcEventLogger
 logQuery
 INFO: SELECT t0.ESTIMATED_PRICE AS ec0_0, t0.PAINTING_DESCRIPTION AS
 ec0_1, t0.PAINTING_TITLE AS ec0_2, t0.ARTIST_ID AS ec0_3, t0.GALLERY_ID AS
 ec0_4, t0.PAINTING_ID AS ec0_5 FROM PAINTING t0, ARTIST t1 WHERE EXISTS
 (SELECT 1 FROM PAINTING t2 WHERE t2.ARTIST_ID = t1.ARTIST_ID AND
 t2.PAINTING_ID = t0.PAINTING_ID) AND t1.ARTIST_NAME = ? [bind: 1:'B']
 Dec 20, 2013 1:01:42 AM org.apache.cayenne.log.CommonsJdbcEventLogger
 logSelectCount
 INFO: === returned 2 rows. - took 5 ms.
 Dec 20, 2013 1:01:42 AM org.apache.cayenne.log.CommonsJdbcEventLogger
 logCommitTransaction
 INFO: +++ transaction committed.
 Dec 20, 2013 1:01:42 AM
 org.apache.cayenne.configuration.XMLDataChannelDescriptorLoader load
 INFO: Loading XML configuration resource from
 file:/x1/jenkins/jenkins-slave/workspace/Cayenne-trunk/cayenneTestConnection/derby/jdk/JDK%201.6%20(latest)/label/Ubuntu/trunk/cayenne-server/target/test-classes/cayenne-testmap.xml
 Dec 20, 2013 1:01:42 AM
 org.apache.cayenne.configuration.XMLDataChannelDescriptorLoader$DataChannelChildrenHandler
 createChildTagHandler
 INFO: Loading XML DataMap resource from
 file:/x1/jenkins/jenkins-slave/workspace/Cayenne-trunk/cayenneTestConnection/derby/jdk/JDK%201.6%20(latest)/label/Ubuntu/trunk/cayenne-server/target/test-classes/testmap.map.xml
 Dec 20, 2013 1:01:42 AM org.apache.cayenne.map.EntityResolver
 applyDBLayerDefaults
 INFO: added runtime complimentary DbRelationship from ARTIST to PAINTING1
 Dec 20, 2013 1:01:42 AM
 org.apache.cayenne.configuration.XMLDataChannelDescriptorLoader load
 INFO: Loading XML configuration resource from
 file:/x1/jenkins/jenkins-slave/workspace/Cayenne-trunk/cayenneTestConnection/derby/jdk/JDK%201.6%20(latest)/label/Ubuntu/trunk/cayenne-server/target/test-classes/cayenne-testmap.xml
 Dec 20, 2013 1:01:42 AM
 org.apache.cayenne.configuration.XMLDataChannelDescriptorLoader$DataChannelChildrenHandler
 createChildTagHandler
 INFO: Loading XML DataMap resource from
 file:/x1/jenkins/jenkins-slave/workspace/Cayenne-trunk/cayenneTestConnection/derby/jdk/JDK%201.6%20(latest)/label/Ubuntu/trunk/cayenne-server/target/test-classes/testmap.map.xml
 Dec 20, 2013 1:01:42 AM org.apache.cayenne.map.EntityResolver
 applyDBLayerDefaults
 INFO: added runtime complimentary DbRelationship from ARTIST to PAINTING1
 Dec 20, 2013 1:01:42 AM
 

Re: cayenne 3.1 B3 dependencies missing commons-lang-2.6

[Mike Kienenberger]

I don't have a problem with dependencies, as long as we have a
reasonable need of them.
Velocity is pretty much required for code generation.   Runtime might
be a different story.

On Thu, Dec 19, 2013 at 6:31 AM, Andrus Adamchik and...@objectstyle.org wrote:
 Aha, JdbcPkGenerator uses SQLTemplate internally. Should probably change that.

 FWIW, Velocity dependency bothers me more than the recently discussed 
 commons-logging.

 A.

 On Dec 19, 2013, at 4:37 AM, Mike Kienenberger mkien...@gmail.com wrote:

 The commons-lang dependency looks like it may have to do with primary
 key generation.  This is an h2 database using the default pk generator
 -- I haven't taken the effort to set up sequences yet.

 Exception in thread main java.lang.NoClassDefFoundError:
 org/apache/commons/lang/StringUtils
at 
 org.apache.velocity.runtime.VelocimacroFactory.initVelocimacro(VelocimacroFactory.java:189)
at 
 org.apache.velocity.runtime.RuntimeInstance.init(RuntimeInstance.java:261)
at 
 org.apache.cayenne.access.jdbc.SQLTemplateProcessor.initVelocityRuntime(SQLTemplateProcessor.java:84)
at 
 org.apache.cayenne.access.jdbc.SQLTemplateProcessor.clinit(SQLTemplateProcessor.java:58)
at 
 org.apache.cayenne.access.jdbc.SQLTemplateAction.performAction(SQLTemplateAction.java:102)
at 
 org.apache.cayenne.access.DataNodeQueryAction.runQuery(DataNodeQueryAction.java:87)
at org.apache.cayenne.access.DataNode.performQueries(DataNode.java:280)
at 
 org.apache.cayenne.dba.JdbcPkGenerator.longPkFromDatabase(JdbcPkGenerator.java:310)
at 
 org.apache.cayenne.dba.JdbcPkGenerator.generatePk(JdbcPkGenerator.java:268)
at 
 org.apache.cayenne.access.DataDomainInsertBucket.createPermIds(DataDomainInsertBucket.java:171)
at 
 org.apache.cayenne.access.DataDomainInsertBucket.appendQueriesInternal(DataDomainInsertBucket.java:76)
at 
 org.apache.cayenne.access.DataDomainSyncBucket.appendQueries(DataDomainSyncBucket.java:78)
at 
 org.apache.cayenne.access.DataDomainFlushAction.preprocess(DataDomainFlushAction.java:188)
at 
 org.apache.cayenne.access.DataDomainFlushAction.flush(DataDomainFlushAction.java:144)
at org.apache.cayenne.access.DataDomain.onSyncFlush(DataDomain.java:853)
at org.apache.cayenne.access.DataDomain$2.transform(DataDomain.java:817)
at 
 org.apache.cayenne.access.DataDomain.runInTransaction(DataDomain.java:877)
at 
 org.apache.cayenne.access.DataDomain.onSyncNoFilters(DataDomain.java:814)
at 
 org.apache.cayenne.access.DataDomain$DataDomainSyncFilterChain.onSync(DataDomain.java:1031)
at org.apache.cayenne.access.DataDomain.onSync(DataDomain.java:785)
at 
 org.apache.cayenne.access.DataContext.flushToParent(DataContext.java:817)
at 
 org.apache.cayenne.access.DataContext.commitChanges(DataContext.java:756)
at 
 org.gamenet.duplicateFileOrganizer.DuplicateFileOrganizer.categorizeDirectory(DuplicateFileOrganizer.java:50)
at 
 org.gamenet.duplicateFileOrganizer.DuplicateFileOrganizer.main(DuplicateFileOrganizer.java:25)
 Caused by: java.lang.ClassNotFoundException: 
 org.apache.commons.lang.StringUtils
at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
... 24 more

 On Wed, Dec 18, 2013 at 11:59 AM, Mike Kienenberger mkien...@gmail.com 
 wrote:
 On Wed, Dec 18, 2013 at 11:43 AM, Andrus Adamchik
 and...@objectstyle.org wrote:
 “Got hit” in what way?

 Got hit with a ClassNotFound exception if I remember right.
 I'll try to provide a stack trace the next time I turn that system on.


 Are you using Maven?

 No, this is a simple just-started project in Eclipse at this point
 with no build system.


 On Dec 18, 2013, at 7:21 PM, Mike Kienenberger mkien...@gmail.com wrote:

 Yes, commons-lang is from velocity.  I'm not using SQLTemplate nor
 EJBQL so far as I can tell, but I still got hit with the dependency on
 a new 3.1 project.   I haven't been required to have oro, only
 commons-lang.

 On Wed, Dec 18, 2013 at 1:53 AM, Andrus Adamchik and...@objectstyle.org 
 wrote:
 Cayenne does not have commons-lang dependency. I think it is a 
 dependency of Velocity. Velocity 1.6.3 depends on commons-lang 2.4 (and 
 also oro 2.0.8 - why in the world people would still use oro?)

 So commons-lang will be needed if you are running SQLTemplate and EJBQL 
 queries (that are using Velocity). Yeah, I think we need to somehow 
 address that either in the docs and/or by packaging those in 
 third-party/ ..

 I also wish we reduce / remove our dependency on Velocity. Then we’ll be 
 pretty close to dependency-free holy grail for a typical user :)

 A.

 On Dec 18

Re: cayenne 3.1 B3 dependencies missing commons-lang-2.6

[Mike Kienenberger]

Yes, commons-lang is from velocity.  I'm not using SQLTemplate nor
EJBQL so far as I can tell, but I still got hit with the dependency on
a new 3.1 project.   I haven't been required to have oro, only
commons-lang.

On Wed, Dec 18, 2013 at 1:53 AM, Andrus Adamchik and...@objectstyle.org wrote:
 Cayenne does not have commons-lang dependency. I think it is a dependency of 
 Velocity. Velocity 1.6.3 depends on commons-lang 2.4 (and also oro 2.0.8 - 
 why in the world people would still use oro?)

 So commons-lang will be needed if you are running SQLTemplate and EJBQL 
 queries (that are using Velocity). Yeah, I think we need to somehow address 
 that either in the docs and/or by packaging those in third-party/ ..

 I also wish we reduce / remove our dependency on Velocity. Then we’ll be 
 pretty close to dependency-free holy grail for a typical user :)

 A.

 On Dec 18, 2013, at 6:08 AM, Mike Kienenberger mkien...@gmail.com wrote:
 This was on the windows distribution.  I haven't checked the other ones.

 On Tue, Dec 17, 2013 at 10:07 PM, Mike Kienenberger mkien...@gmail.com 
 wrote:
 We state:

 =

 When using cayenne-server-x.x.jar you'll need a few third party jars
 (all included in lib/third-party directory of the distribution):

 Apache Velocity Template Engine, version 1.6.x (and all its
 dependencies bundled with velocity-dep)

 Apache Commons Collections, version 3.2.1

 Apache Commons Logging, version 1.1
 =

 http://cayenne.apache.org/docs/3.1/cayenne-guide/including-cayenne-in-project.html#jar-files-and-depdendencies

 However, we are missing commons-lang-2.6

Re: cayenne 3.1 B3 dependencies missing commons-lang-2.6

[Mike Kienenberger]

On Wed, Dec 18, 2013 at 11:43 AM, Andrus Adamchik
and...@objectstyle.org wrote:
 “Got hit” in what way?

Got hit with a ClassNotFound exception if I remember right.
I'll try to provide a stack trace the next time I turn that system on.


 Are you using Maven?

No, this is a simple just-started project in Eclipse at this point
with no build system.


 On Dec 18, 2013, at 7:21 PM, Mike Kienenberger mkien...@gmail.com wrote:

 Yes, commons-lang is from velocity.  I'm not using SQLTemplate nor
 EJBQL so far as I can tell, but I still got hit with the dependency on
 a new 3.1 project.   I haven't been required to have oro, only
 commons-lang.

 On Wed, Dec 18, 2013 at 1:53 AM, Andrus Adamchik and...@objectstyle.org 
 wrote:
 Cayenne does not have commons-lang dependency. I think it is a dependency 
 of Velocity. Velocity 1.6.3 depends on commons-lang 2.4 (and also oro 2.0.8 
 - why in the world people would still use oro?)

 So commons-lang will be needed if you are running SQLTemplate and EJBQL 
 queries (that are using Velocity). Yeah, I think we need to somehow address 
 that either in the docs and/or by packaging those in third-party/ ..

 I also wish we reduce / remove our dependency on Velocity. Then we’ll be 
 pretty close to dependency-free holy grail for a typical user :)

 A.

 On Dec 18, 2013, at 6:08 AM, Mike Kienenberger mkien...@gmail.com wrote:
 This was on the windows distribution.  I haven't checked the other ones.

 On Tue, Dec 17, 2013 at 10:07 PM, Mike Kienenberger mkien...@gmail.com 
 wrote:
 We state:

 =

 When using cayenne-server-x.x.jar you'll need a few third party jars
 (all included in lib/third-party directory of the distribution):

 Apache Velocity Template Engine, version 1.6.x (and all its
 dependencies bundled with velocity-dep)

 Apache Commons Collections, version 3.2.1

 Apache Commons Logging, version 1.1
 =

 http://cayenne.apache.org/docs/3.1/cayenne-guide/including-cayenne-in-project.html#jar-files-and-depdendencies

 However, we are missing commons-lang-2.6

Re: cayenne 3.1 B3 dependencies missing commons-lang-2.6

[Mike Kienenberger]

The commons-lang dependency looks like it may have to do with primary
key generation.  This is an h2 database using the default pk generator
-- I haven't taken the effort to set up sequences yet.

Exception in thread main java.lang.NoClassDefFoundError:
org/apache/commons/lang/StringUtils
at 
org.apache.velocity.runtime.VelocimacroFactory.initVelocimacro(VelocimacroFactory.java:189)
at 
org.apache.velocity.runtime.RuntimeInstance.init(RuntimeInstance.java:261)
at 
org.apache.cayenne.access.jdbc.SQLTemplateProcessor.initVelocityRuntime(SQLTemplateProcessor.java:84)
at 
org.apache.cayenne.access.jdbc.SQLTemplateProcessor.clinit(SQLTemplateProcessor.java:58)
at 
org.apache.cayenne.access.jdbc.SQLTemplateAction.performAction(SQLTemplateAction.java:102)
at 
org.apache.cayenne.access.DataNodeQueryAction.runQuery(DataNodeQueryAction.java:87)
at org.apache.cayenne.access.DataNode.performQueries(DataNode.java:280)
at 
org.apache.cayenne.dba.JdbcPkGenerator.longPkFromDatabase(JdbcPkGenerator.java:310)
at 
org.apache.cayenne.dba.JdbcPkGenerator.generatePk(JdbcPkGenerator.java:268)
at 
org.apache.cayenne.access.DataDomainInsertBucket.createPermIds(DataDomainInsertBucket.java:171)
at 
org.apache.cayenne.access.DataDomainInsertBucket.appendQueriesInternal(DataDomainInsertBucket.java:76)
at 
org.apache.cayenne.access.DataDomainSyncBucket.appendQueries(DataDomainSyncBucket.java:78)
at 
org.apache.cayenne.access.DataDomainFlushAction.preprocess(DataDomainFlushAction.java:188)
at 
org.apache.cayenne.access.DataDomainFlushAction.flush(DataDomainFlushAction.java:144)
at org.apache.cayenne.access.DataDomain.onSyncFlush(DataDomain.java:853)
at org.apache.cayenne.access.DataDomain$2.transform(DataDomain.java:817)
at 
org.apache.cayenne.access.DataDomain.runInTransaction(DataDomain.java:877)
at org.apache.cayenne.access.DataDomain.onSyncNoFilters(DataDomain.java:814)
at 
org.apache.cayenne.access.DataDomain$DataDomainSyncFilterChain.onSync(DataDomain.java:1031)
at org.apache.cayenne.access.DataDomain.onSync(DataDomain.java:785)
at org.apache.cayenne.access.DataContext.flushToParent(DataContext.java:817)
at org.apache.cayenne.access.DataContext.commitChanges(DataContext.java:756)
at 
org.gamenet.duplicateFileOrganizer.DuplicateFileOrganizer.categorizeDirectory(DuplicateFileOrganizer.java:50)
at 
org.gamenet.duplicateFileOrganizer.DuplicateFileOrganizer.main(DuplicateFileOrganizer.java:25)
Caused by: java.lang.ClassNotFoundException: org.apache.commons.lang.StringUtils
at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
... 24 more

On Wed, Dec 18, 2013 at 11:59 AM, Mike Kienenberger mkien...@gmail.com wrote:
 On Wed, Dec 18, 2013 at 11:43 AM, Andrus Adamchik
 and...@objectstyle.org wrote:
 “Got hit” in what way?

 Got hit with a ClassNotFound exception if I remember right.
 I'll try to provide a stack trace the next time I turn that system on.


 Are you using Maven?

 No, this is a simple just-started project in Eclipse at this point
 with no build system.


 On Dec 18, 2013, at 7:21 PM, Mike Kienenberger mkien...@gmail.com wrote:

 Yes, commons-lang is from velocity.  I'm not using SQLTemplate nor
 EJBQL so far as I can tell, but I still got hit with the dependency on
 a new 3.1 project.   I haven't been required to have oro, only
 commons-lang.

 On Wed, Dec 18, 2013 at 1:53 AM, Andrus Adamchik and...@objectstyle.org 
 wrote:
 Cayenne does not have commons-lang dependency. I think it is a dependency 
 of Velocity. Velocity 1.6.3 depends on commons-lang 2.4 (and also oro 
 2.0.8 - why in the world people would still use oro?)

 So commons-lang will be needed if you are running SQLTemplate and EJBQL 
 queries (that are using Velocity). Yeah, I think we need to somehow 
 address that either in the docs and/or by packaging those in third-party/ 
 ..

 I also wish we reduce / remove our dependency on Velocity. Then we’ll be 
 pretty close to dependency-free holy grail for a typical user :)

 A.

 On Dec 18, 2013, at 6:08 AM, Mike Kienenberger mkien...@gmail.com wrote:
 This was on the windows distribution.  I haven't checked the other ones.

 On Tue, Dec 17, 2013 at 10:07 PM, Mike Kienenberger mkien...@gmail.com 
 wrote:
 We state:

 =

 When using cayenne-server-x.x.jar you'll need a few third party jars
 (all included in lib/third-party directory of the distribution):

 Apache Velocity Template Engine, version 1.6.x (and all its
 dependencies bundled with velocity-dep)

 Apache Commons Collections, version 3.2.1

 Apache Commons

Re: cayenne performance tuning issues

[Mike Kienenberger]

What you're showing here in the log doesn't seem to have anything to
do with Cayenne peformance problems.

2013-12-16 23:17:52,338 [http-bio-8080-exec-10] INFO

SELECT
[...t0.*...]

FROM EDU_SEC.dbo.APP_USER t0

WHERE ((t0.PWD = ?) OR (t0.PWD = ?)) AND (t0.UID = ?)

[bind: 1-PWD:'REDACTED', 2-PWD:'$REDACTED...', 3-UID:'michael.hatch'] -

 prepared in 7 ms.

2013-12-16 23:18:21,864 [http-bio-8080-exec-10] INFO
 log.CommonsJdbcEventLogger  - === returned 1 row. - took 29535 ms.


You have a single table simple sql query that takes 29.5 seconds to
return a single row.

Maybe there is a performance problem with how the password field
comparisons are being done on the database server, or maybe you have a
networking issue.

The prefetch statement is the next one, and it only took 3.6 seconds
to return 9 rows (using the same password field comparisons) so
perhaps by this time the result has been cached in the database.

One simple change you could make to test is to change your query to
compare against something other than PWD (maybe just UID) and see what
kind of difference that makes.   If no difference, then you've got
general server or network problems.   If it makes a huge difference,
then the PWD field on your database is likely the cause.





On Tue, Dec 17, 2013 at 12:29 PM, Michael Hatch mvha...@gmail.com wrote:
 I was asked to provide further details of the performance issues I'm facing.
 I have a simple grails app that logs a user into the app (with valid role
 permissions) and performs simple CRUD operations on object entities. The
 below output is the login sql generated during the login attempt. I am
 fetching a user object and saving it to http session. The query is simple,
 but takes way too long.

 The groovy code is as follows:

 def findUserAndRoles(String username, String password) {
 def usernameCriteria = ExpressionFactory.matchExp(uid, username)
 //def roleCriteria = ExpressionFactory.noMatchExp(roles, null)
 def pwdCriteria = [ExpressionFactory.matchExp(pwd,
 Rot13.encrypt(password))]
 pwdCriteria  ExpressionFactory.matchExp(pwd,
 BCrypt.hashpw(password, BCrypt.gensalt()))
 def criteria = ExpressionFactory.joinExp(Expression.OR,
 pwdCriteria).andExp(usernameCriteria)
 def query = new SelectQuery(AppUser, criteria)

 query.addPrefetch(roles)//.setSemantics(PrefetchTreeNode.JOINT_PREFETCH_SEMANTICS)

 //will return null if no row is found; will throw an exception if
 more than 1 row is found
 Cayenne.objectForQuery(context, query)
 //context.performQuery(query)
 }

 The output is:

 2013-12-16 23:17:51,508 [http-bio-8080-exec-10] INFO
  log.CommonsJdbcEventLogger  - Opening connection: jdbc:sqlserver://REDACTED
 Login: cf_user
 Password: ***
 2013-12-16 23:17:52,295 [http-bio-8080-exec-10] INFO
  log.CommonsJdbcEventLogger  - +++ Connecting: SUCCESS.
 2013-12-16 23:17:52,325 [http-bio-8080-exec-10] INFO
  log.CommonsJdbcEventLogger  - Detected and installed adapter:
 org.apache.cayenne.dba.sqlserver.SQLServerAdapter
 2013-12-16 23:17:52,338 [http-bio-8080-exec-10] INFO
  log.CommonsJdbcEventLogger  - SELECT t0.ADDRESS_GUID, t0.ARCHIVE_DT,
 t0.COUNTRY_CODE, t0.CREATE_DT, t0.CREATE_ID, t0.EMAIL, t0.ENTITY_TYPE_GUID,
 t0.FAX_PHONE, t0.FIRST_NAME, t0.ISDELETED, t0.LANGUAGE_CODE,
 t0.LAST_ACTIVITY_DT, t0.LAST_NAME, t0.MAIN_PHONE, t0.MIDDLE_NAME,
 t0.PUBLIC_KEY, t0.PWD, t0.REGION_CODE, t0.SECURITY_QUESTION_ANSWER,
 t0.SECURITY_QUESTION_GUID, t0.SITE_GUID, t0.SSOCODE, t0.TZOFFSET, t0.UID,
 t0.UPDATE_DT, t0.UPDATE_ID, t0.APP_USER_GUID FROM EDU_SEC.dbo.APP_USER t0
 WHERE ((t0.PWD = ?) OR (t0.PWD = ?)) AND (t0.UID = ?) [bind:
 1-PWD:'REDACTED', 2-PWD:'$REDACTED...', 3-UID:'michael.hatch'] -
 prepared in 7 ms.
 2013-12-16 23:18:21,864 [http-bio-8080-exec-10] INFO
  log.CommonsJdbcEventLogger  - === returned 1 row. - took 29535 ms.

 2013-12-16 23:18:21,872 [http-bio-8080-exec-10] INFO
  log.CommonsJdbcEventLogger  - SELECT DISTINCT t0.ASSIGN_ALL_SITES,
 t0.CODE, t0.CREATE_DT, t0.CREATE_ID, t0.DEFAULT_ROLE, t0.DESCRIPTION,
 t0.isExclusive, t0.PERMISSION_BIT_CODE, t0.PRODUCT_GUID, t0.SORT_ORDER,
 t0.UPDATE_DT, t0.UPDATE_ID, t0.ROLE_GUID, t2.APP_USER_GUID FROM
 EDU_SEC.dbo.ROLE t0 JOIN EDU_SEC.dbo.USER_ROLE t1 ON (t0.ROLE_GUID =
 t1.ROLE_GUID) JOIN EDU_SEC.dbo.APP_USER t2 ON (t1.APP_USER_GUID =
 t2.APP_USER_GUID) WHERE ((t2.PWD = ?) OR (t2.PWD = ?)) AND (t2.UID = ?)
 [bind: 1-PWD:'REDACTED', 2-PWD:'$REDACTED...', 3-UID:'michael.hatch'] -
 prepared in 7 ms.
 2013-12-16 23:18:25,488 [http-bio-8080-exec-10] INFO
  log.CommonsJdbcEventLogger  - === returned 9 rows. - took 3623 ms.
 2013-12-16 23:18:25,488 [http-bio-8080-exec-10] INFO
  log.CommonsJdbcEventLogger  - +++ no commit - transaction controlled
 externally.

 The first sql statement is fetching the user info, while the second sql is
 for inflating the roles relationship. I understand the documentation
 explicitly states that prefetching will inflate relationships for 

cayenne 3.1 B3 dependencies missing commons-lang-2.6

[Mike Kienenberger]

We state:

=

When using cayenne-server-x.x.jar you'll need a few third party jars
(all included in lib/third-party directory of the distribution):

Apache Velocity Template Engine, version 1.6.x (and all its
dependencies bundled with velocity-dep)

Apache Commons Collections, version 3.2.1

Apache Commons Logging, version 1.1
=

http://cayenne.apache.org/docs/3.1/cayenne-guide/including-cayenne-in-project.html#jar-files-and-depdendencies

However, we are missing commons-lang-2.6

Re: cayenne 3.1 B3 dependencies missing commons-lang-2.6

[Mike Kienenberger]

This was on the windows distribution.  I haven't checked the other ones.

On Tue, Dec 17, 2013 at 10:07 PM, Mike Kienenberger mkien...@gmail.com wrote:
 We state:

 =

 When using cayenne-server-x.x.jar you'll need a few third party jars
 (all included in lib/third-party directory of the distribution):

 Apache Velocity Template Engine, version 1.6.x (and all its
 dependencies bundled with velocity-dep)

 Apache Commons Collections, version 3.2.1

 Apache Commons Logging, version 1.1
 =

 http://cayenne.apache.org/docs/3.1/cayenne-guide/including-cayenne-in-project.html#jar-files-and-depdendencies

 However, we are missing commons-lang-2.6

Re: Cayenne[Modeler] on Linux

[Mike Kienenberger]

As a linux Cayenne user (and really, as a user on any platform), I
don't see the point of installing Cayenne as an RPM or with any kind
of installer.   Different projects require different versions of
Cayenne, and I wouldn't want an automatic upgrade changing the version
on me.

As for a desktop app, I think all that you have to do is create a
CayenneModeller.desktop file and copy it to the Desktop folder.   This
is under OpenSUSE Mate (previously Gnome) but I think it also works
for KDE and other window managers.

Here's an example of an entry I created for Eclipse:


mkienenb@linux-4eqv:~/Desktop cat eclipse.desktop
[Desktop Entry]
Version=1.0
Encoding=UTF-8
Name=Eclipse
X-SuSE-translate=true
Categories=Development;IDE;
Exec=/home/mkienenb/Apps/eclipse/eclipse.sh -vm /usr/java/jdk1.6.0_34/bin/java
GenericName=Eclipse IDE
X-KDE-StartupNotify=true
MimeType=application/x-designer;
Icon=/home/mkienenb/Apps/eclipse/eclipse128.png
Type=Application
Comment[en_US]=see eclipse.ini for command-line args
GenericName[en_US]=Eclipse IDE

Here's one I just threw together for Cayenne Modeler.   I don't
pretend to be an expert on what all of the parameters mean, so some of
them may be wrong.

mkienenb@linux-4eqv:~/Desktop cat CayenneModeler.desktop
[Desktop Entry]
Version=1.0
Encoding=UTF-8
Name=Cayenne 3.1 Modeler
X-SuSE-translate=true
Categories=Development;Programming
Exec=/usr/java/jdk1.6.0_34/bin/java -jar
/home/mkienenb/java/cayenne-3.1B2/bin/CayenneModeler.jar
GenericName=Cayenne 3.1 Modeler
X-KDE-StartupNotify=true
MimeType=application/x-designer;
Icon=/home/mkienenb/workspaces/cayenne-checkout/STABLE-3.1/modeler/cayenne-modeler/src/main/resources/org/apache/cayenne/modeler/images/CayenneModeler.jpg
Type=Application
Comment[en_US]=
GenericName[en_US]=Cayenne 3.1 Modeler

However, when I tried to use $JAVA_HOME/bin/java, that failed, so you
probably cannot have a path based on an environment variable, which
means you would need to create it with a shell script rather than just
drag it onto your desktop.

If you copy it into /usr/share/applications, it shows up in the menus
on my system, with Categories controlling which menus.


On Mon, Dec 2, 2013 at 3:03 AM, Andrus Adamchik and...@objectstyle.org wrote:
 So now we are talking about installer, i.e. something a level up from just a 
 desktop app packager. I wonder if having an .rpm and friends will do more 
 harm than good, with blanket system updates upgrading Cayenne to a version 
 not compatible with the user apps (Cayenne is not a system component after 
 all, it is a dev library).

 I wish there was something on Linux similar to OS X app bundle that would 
 allow people to drag a single folder from tar.gz to Desktop and get a 
 launcher with a Cayenne icon, not just a jar. I haven’t followed Linux 
 desktop development lately. Maybe there is such solution?

 Andrus


 On Dec 1, 2013, at 10:32 AM, Adrian A. a.adrian.t...@googlemail.com wrote:
 Hi,

 ... most of the work happened outside Cayenne, going into japp-maven-plugin 
 [1], which has become again a modern cross-platform tool to assemble Java 
 desktop apps.

 Any plans to support the various Unix distributions (so not just an
 executable JAR)? :
 http://mojo.codehaus.org/unix/

 The usefulness is of course limited, but the project's visibility
 would be increased since it could be submitted to those distributions
 too.

 Adrian.

Re: Cayenne[Modeler] on Linux

[Mike Kienenberger]

Apparently, ~/.local/share/applications is probably the better
location to use for this.


On Mon, Dec 2, 2013 at 9:09 AM, Mike Kienenberger mkien...@gmail.com wrote:
 As a linux Cayenne user (and really, as a user on any platform), I
 don't see the point of installing Cayenne as an RPM or with any kind
 of installer.   Different projects require different versions of
 Cayenne, and I wouldn't want an automatic upgrade changing the version
 on me.

 As for a desktop app, I think all that you have to do is create a
 CayenneModeller.desktop file and copy it to the Desktop folder.   This
 is under OpenSUSE Mate (previously Gnome) but I think it also works
 for KDE and other window managers.

 Here's an example of an entry I created for Eclipse:


 mkienenb@linux-4eqv:~/Desktop cat eclipse.desktop
 [Desktop Entry]
 Version=1.0
 Encoding=UTF-8
 Name=Eclipse
 X-SuSE-translate=true
 Categories=Development;IDE;
 Exec=/home/mkienenb/Apps/eclipse/eclipse.sh -vm /usr/java/jdk1.6.0_34/bin/java
 GenericName=Eclipse IDE
 X-KDE-StartupNotify=true
 MimeType=application/x-designer;
 Icon=/home/mkienenb/Apps/eclipse/eclipse128.png
 Type=Application
 Comment[en_US]=see eclipse.ini for command-line args
 GenericName[en_US]=Eclipse IDE

 Here's one I just threw together for Cayenne Modeler.   I don't
 pretend to be an expert on what all of the parameters mean, so some of
 them may be wrong.

 mkienenb@linux-4eqv:~/Desktop cat CayenneModeler.desktop
 [Desktop Entry]
 Version=1.0
 Encoding=UTF-8
 Name=Cayenne 3.1 Modeler
 X-SuSE-translate=true
 Categories=Development;Programming
 Exec=/usr/java/jdk1.6.0_34/bin/java -jar
 /home/mkienenb/java/cayenne-3.1B2/bin/CayenneModeler.jar
 GenericName=Cayenne 3.1 Modeler
 X-KDE-StartupNotify=true
 MimeType=application/x-designer;
 Icon=/home/mkienenb/workspaces/cayenne-checkout/STABLE-3.1/modeler/cayenne-modeler/src/main/resources/org/apache/cayenne/modeler/images/CayenneModeler.jpg
 Type=Application
 Comment[en_US]=
 GenericName[en_US]=Cayenne 3.1 Modeler

 However, when I tried to use $JAVA_HOME/bin/java, that failed, so you
 probably cannot have a path based on an environment variable, which
 means you would need to create it with a shell script rather than just
 drag it onto your desktop.

 If you copy it into /usr/share/applications, it shows up in the menus
 on my system, with Categories controlling which menus.


 On Mon, Dec 2, 2013 at 3:03 AM, Andrus Adamchik and...@objectstyle.org 
 wrote:
 So now we are talking about installer, i.e. something a level up from just a 
 desktop app packager. I wonder if having an .rpm and friends will do more 
 harm than good, with blanket system updates upgrading Cayenne to a version 
 not compatible with the user apps (Cayenne is not a system component after 
 all, it is a dev library).

 I wish there was something on Linux similar to OS X app bundle that would 
 allow people to drag a single folder from tar.gz to Desktop and get a 
 launcher with a Cayenne icon, not just a jar. I haven’t followed Linux 
 desktop development lately. Maybe there is such solution?

 Andrus


 On Dec 1, 2013, at 10:32 AM, Adrian A. a.adrian.t...@googlemail.com wrote:
 Hi,

 ... most of the work happened outside Cayenne, going into 
 japp-maven-plugin [1], which has become again a modern cross-platform tool 
 to assemble Java desktop apps.

 Any plans to support the various Unix distributions (so not just an
 executable JAR)? :
 http://mojo.codehaus.org/unix/

 The usefulness is of course limited, but the project's visibility
 would be increased since it could be submitted to those distributions
 too.

 Adrian.

Re: Cayenne[Modeler] on Linux

[Mike Kienenberger]

http://superuser.com/questions/68089/how-can-i-add-menu-items-to-the-gnome-applications-menu-from-the-command-line

https://developer.gnome.org/integration-guide/stable/desktop-files.html.en

And relative paths are not supported (security concern?)

http://stackoverflow.com/questions/3811032/using-relative-paths-for-gnome-launcher

On Mon, Dec 2, 2013 at 9:11 AM, Mike Kienenberger mkien...@gmail.com wrote:
 Apparently, ~/.local/share/applications is probably the better
 location to use for this.


 On Mon, Dec 2, 2013 at 9:09 AM, Mike Kienenberger mkien...@gmail.com wrote:
 As a linux Cayenne user (and really, as a user on any platform), I
 don't see the point of installing Cayenne as an RPM or with any kind
 of installer.   Different projects require different versions of
 Cayenne, and I wouldn't want an automatic upgrade changing the version
 on me.

 As for a desktop app, I think all that you have to do is create a
 CayenneModeller.desktop file and copy it to the Desktop folder.   This
 is under OpenSUSE Mate (previously Gnome) but I think it also works
 for KDE and other window managers.

 Here's an example of an entry I created for Eclipse:


 mkienenb@linux-4eqv:~/Desktop cat eclipse.desktop
 [Desktop Entry]
 Version=1.0
 Encoding=UTF-8
 Name=Eclipse
 X-SuSE-translate=true
 Categories=Development;IDE;
 Exec=/home/mkienenb/Apps/eclipse/eclipse.sh -vm 
 /usr/java/jdk1.6.0_34/bin/java
 GenericName=Eclipse IDE
 X-KDE-StartupNotify=true
 MimeType=application/x-designer;
 Icon=/home/mkienenb/Apps/eclipse/eclipse128.png
 Type=Application
 Comment[en_US]=see eclipse.ini for command-line args
 GenericName[en_US]=Eclipse IDE

 Here's one I just threw together for Cayenne Modeler.   I don't
 pretend to be an expert on what all of the parameters mean, so some of
 them may be wrong.

 mkienenb@linux-4eqv:~/Desktop cat CayenneModeler.desktop
 [Desktop Entry]
 Version=1.0
 Encoding=UTF-8
 Name=Cayenne 3.1 Modeler
 X-SuSE-translate=true
 Categories=Development;Programming
 Exec=/usr/java/jdk1.6.0_34/bin/java -jar
 /home/mkienenb/java/cayenne-3.1B2/bin/CayenneModeler.jar
 GenericName=Cayenne 3.1 Modeler
 X-KDE-StartupNotify=true
 MimeType=application/x-designer;
 Icon=/home/mkienenb/workspaces/cayenne-checkout/STABLE-3.1/modeler/cayenne-modeler/src/main/resources/org/apache/cayenne/modeler/images/CayenneModeler.jpg
 Type=Application
 Comment[en_US]=
 GenericName[en_US]=Cayenne 3.1 Modeler

 However, when I tried to use $JAVA_HOME/bin/java, that failed, so you
 probably cannot have a path based on an environment variable, which
 means you would need to create it with a shell script rather than just
 drag it onto your desktop.

 If you copy it into /usr/share/applications, it shows up in the menus
 on my system, with Categories controlling which menus.


 On Mon, Dec 2, 2013 at 3:03 AM, Andrus Adamchik and...@objectstyle.org 
 wrote:
 So now we are talking about installer, i.e. something a level up from just 
 a desktop app packager. I wonder if having an .rpm and friends will do more 
 harm than good, with blanket system updates upgrading Cayenne to a version 
 not compatible with the user apps (Cayenne is not a system component after 
 all, it is a dev library).

 I wish there was something on Linux similar to OS X app bundle that would 
 allow people to drag a single folder from tar.gz to Desktop and get a 
 launcher with a Cayenne icon, not just a jar. I haven’t followed Linux 
 desktop development lately. Maybe there is such solution?

 Andrus


 On Dec 1, 2013, at 10:32 AM, Adrian A. a.adrian.t...@googlemail.com wrote:
 Hi,

 ... most of the work happened outside Cayenne, going into 
 japp-maven-plugin [1], which has become again a modern cross-platform 
 tool to assemble Java desktop apps.

 Any plans to support the various Unix distributions (so not just an
 executable JAR)? :
 http://mojo.codehaus.org/unix/

 The usefulness is of course limited, but the project's visibility
 would be increased since it could be submitted to those distributions
 too.

 Adrian.

Re: back to monolithic cayenne.jar?

[Mike Kienenberger]

This one looks good to me..

On Sun, Nov 17, 2013 at 5:05 AM, Andrus Adamchik and...@objectstyle.org wrote:
 Now that I gave it some thought, I actually like the idea of a system modular 
 by default, but including cayenne-all.jar on top of that. It has none of the 
 drawbacks of our old “synthetic” cayenne-server and cayenne-client. More 
 practically, turns out that cleanly splitting the core and server classes is 
 much more effort than I am ready to undertake now. So we ended up with these 
 modules:

  cayenne-di.jar
  cayenne-server.jar = cayenne-di
  cayenne-client.jar = cayenne-di, cayenne-server

 I guess I’ll leave it at that until a later time when we can cut smaller 
 modules out of cayenne-server.

 Andrus


 On Nov 17, 2013, at 12:49 AM, Andrus Adamchik and...@objectstyle.org wrote:
 On Nov 17, 2013, at 12:27 AM, Adrian A. a.adrian.t...@googlemail.com wrote:

 1. Monolithic cayenne.jar for regular apps, for ROP clients, for 
 CayenneModeler
 2. Partial modularity - Client/server split between the modules, with 
 separate DI and backend-indepdendent “core” :
 ...
 Anyways, these are our options… Feel free to comment, while I continue my 
 refactoring.
 What about offering both? The modules, but also a cayenne-all.jar
 (or simply cayenne.jar) ?


 Adrian

 This will take us back to aggregation of multiple modules into one. It was 
 not a pretty picture, so now I am *hoping* we can align the source modules 
 with the binaries that we release. However this can be an option for 
 non-maven users I guess.

 A.