Consider breaking down and mavenizing the project

[GoogleCodeExporter]

I took your trunk and mavenized it here: 
https://github.com/Pyrolistical/mobjectify

As you can see your project became 4 modules.  

Your project structure had some potential bugs. Including the "super" files in 
the same jar is not a good idea.  The goal was to fix gwt issues with the 
appengine domain classes but this can fail due to classpath ordering.  If the 
appengine jar is included ahead of the objectify jar then your super classes 
would never be loaded.  The solution is to break them out into their own jar so 
you can ensure to put the super files ahead of the appengine jar.

I broke the super classes into two projects appengine-gwt-adapter and 
mobjectify-gwt-adapter.

I also moved the custom field serializers into its own jar 
appengine-gwt-custom-field-serializer.

What remains is the main objectify classes.  This allows the user of your 
library to include what they need.  If they are not using gwt they can leave 
out all those extra jars.

Now I understand you wanted to not have any dependencies and I am sorry to say 
that is not the maven way of doing things.  Because you needed to extract 
classes from the appengine sdk to build objectify this means if appengine ever 
updates those files your project is then out of date.  And because you have 
appengine classes in your jar you run into the same problem I described in the 
beginning.

By declaring your dependencies it gives your users the power to control exactly 
which version they will use.

Also I fixed your test so they don't fail.  Yes I understand they fail because 
of bugs in appengine, but you should just make your test expect to fail and 
test for it.  If the bug ever gets fixed then the test will fail and you can 
fix your test.  You shouldn't ever have to say "All the tests pass, except..."

I kept your full revision history so all you need to do is clone my git repo 
and continue development.

Original issue reported on code.google.com by pyrogx1...@gmail.com on 7 May 2011 at 5:22

[GoogleCodeExporter]

Mavenizing the project is a non-starter, but I'd like to understand your 
specific issues better.

How can the super-source possibly conflict with the appengine jar?  We do not 
include the binary .class files, only the .java files for GWT compilation.  
Appengine does not include the java source.  Conflict should be impossible.

The Objectify jar is a svelte 200k.  We will not break it down into multiple 
jars just for the sake of breaking it down.  The "maven way of doing things" is 
broken.

However, your point is taken WRT the tests.

Original comment by j...@infohazard.org on 8 May 2011 at 11:23

[GoogleCodeExporter]

Ok I didn't understand the GWT part too well.  You are correct it will not 
conflict as they are not .class files.

What part of the Maven way do you consider broken?  I don't want to start a 
religious argument or anything.  I just want to understand any draw backs Maven 
has.

Original comment by ronald.p...@gmail.com on 9 May 2011 at 12:02

[GoogleCodeExporter]

Also do you have an integration test for the gwt source parts?  That would have 
reduced confusion of the purpose of the super source

Original comment by ronald.p...@gmail.com on 9 May 2011 at 12:06

[GoogleCodeExporter]

I've written much vitriol on the subject of Maven, as have many others.  It's a 
bit of a sore subject.  Read through the comments of this:

http://tapestryjava.blogspot.com/2007/11/maven-wont-get-fooled-again.html

There aren't any GWT-related integration tests.  I'm actually not entirely 
certain how to go about writing one, to be honest.  If you know how to approach 
that, we'd love help.  I just have some projects that use GWT + Objectify, and 
since the integration isn't too deep there haven't been many issues.

Original comment by lhori...@gmail.com on 6 Aug 2011 at 10:59

• Changed state: WontFix
• Added labels: Type-Enhancement, Priority-Low
• Removed labels: Type-Defect, Priority-Medium