Rick Hillegas wrote:
Kathey Marsden wrote:
On 7/20/2010 7:03 PM, Kathey Marsden wrote:
I agree wholeheartedly as well with these points. As for my
admittedly gut level concerns for adding the JQuery (non-Apache
license) build dependency and necessary NOTICE update, I sent an
email query to someone that understands these issues better than I
and hope to hear back soon. I will post as soon as I understand it
better.
Well Nirmal, I still don't understand things yet, but don't think I
should ask you to wait any longer. I think you should investigate
build options that are as loosely coupled as possible as Bryan
suggests and ideally a build that will succeed if JQuery is not
present, but not build the functionality that needs it. This is what
we used to do with the osgi.jar requirement before we checked in the
felix source for building.
Thanks
Kathey
We put considerable effort into making it possible to build the entire
product code from what's checked into subversion. The previous
arrangement forced developers to hunt around on the web for other assets
before they could even get a complete build. We need to continue to have
a product which builds completely out of the box. A complicated build
setup is a real turnoff to newcomers. In fact, it's the number 1
community killer on this list compiled by Postgres core team member Josh
Berkus: http://blogs.sun.com/javaone2008/entry/ten_ways_to_destroy_your
-1 to regressing this situation.
Given the added dependency I wonder if this project/code would be better
in another project. I would rather see supporting tools on top of derby
handled by another project rather than increasing the dependencies and
complexities of the server.
Maybe concentrate on building things into Derby that allow open
extensions by add on's that are built separate from the base database
server component.
Would it fit in ddutils?
Regards,
-Rick
