On Thu, Jul 5, 2012 at 11:12 AM, Andy Seaborne <[email protected]> wrote:
http://wiki.apache.org/incubator/ZhuguProposal > > > This proposal combines two things if I read it right - I'm not sure linking > them is the best approach. > > One strand is a home for sparQLed codebase (at least the browser-side > editor part, unclear about the analysis engine part). The issue I see is > that it is based, in part, on another open source project "Flint". It may > look like a fork, a derived work, or something else. The Flint community > may even be willing to make an ASF grant - I don't know them. > Yes that's true. I'm not sure how much SparQLed is a fork of flint, if it merely integrate flint or if changed the flint codebase. Licensewise it's unproblematic because of flint is MIT Licensed, but if we could the flint community participating to Zhugu this would be great. > > The other strand is a consolidation of other open source and packaging > with maven. I'd describe this part of Zhugu as a collection libraries, not > frame it as an application because "application" to me is something an end > user can use. > Indeed I was insecure about which term to use, using both terms seemed a bit long winded. I thought to emphasize more tools like createjs[1] and sparQLed which are frontend applications or at least more pervasive libraries than something like VIE or rdfquery. The user might not see that two different applications use rdfquery on the other hand the user might not see that two sparQLed web-apps use a different backend so she might consider sparQLed to be the app. But I'm happy to use the term library if this leads to less misunderstandings. > > It is certainly useful to provide a consistent, tested cut of javascript > libraries so developers get a collection that works together - but I > wouldn't want to downplay the amount of work this needs to be complete > because of needing the transitive closure effect e.g rdfquery (last > released 2009), depends on jQuery and jQuery isn't in maven. > I think we need to be pragmatic about this and start with some concrete apps/libraries like create.js and in a first step just integrate their dependencies. In a second step we can care about the modularization and mavenization of the decency chain. It's not a perfect world but its better than the current situations where different projects just have bunches js files somewhere in their resource forks. To come back to your doubt that linking the two aspects is a good approach: I think that while at some point it might be good to separate things it would be now a first project for client side semantic libraries and having one community around this is challenging enough. The mavenization of js-project is similar to the providing of OSGi bundles from existing java libraries, the latter is currently done in many projects like service-mix, sling and clerezza and it's often not clear where the bundleized version of a certain library can be found. By putting the packaging of third party libraries as a goal into the Zhugu proposal we have a place that dedicates to this which prevents just doing the mavenization where it is first needed, the hope is that the various projects depending on these artifacts would contribute to Zhugu if they need an newer version rather than creating a new mavenization (like this is frequent for OSGi bundleizations). Doe this make sense? Reto 1. http://createjs.org/
