Gianugo Rabellino wrote:
So I think you've missed my point in the end, giving up on the details of making it happen. Just because I have an opinion on *how* it should happen, doesn't mean that everyone agrees.Kevin Ross wrote:
I also think creating a binary w/Jetty should be a product of a build, not by having Jetty in the main trunk
Please tell me more on this. I'm not really getting it... do you mean that there might be a target that downloads Jetty somewhere, creates a bundle with Xindice and prepares a sort of distribution? If that's the case... well, I don't really see a difference between what you call "deployable" and "standalone". As of now, supporting Jetty is just a matter of writing a ridicolously simple configuration file and point it to the war, nothing else is needed. But maybe I'm not getting your point.
My point is, regardless of size, no extra jars should be forced down the throat of every user of Xindice. Maybe I don't understand, but as far as I can infer, you need to include the jetty jar and were suggestion it's inclusion in CVS.
Yep. CVS, meaning "source reporitory for developers". CVS has little or nothing to do with users, I might understand debating about inclusion of jars in a binary release, but I don't see how including a library in CVS (in order to be able to use it as developers) might be seen as imposing it to users. We might discuss later on about releasing "standalone", "embedded" or "deployable" binary versions, but again this doesn't really have to do much with having a jar in CVS.
Besides, I see yours as a legitimate concern, but then please explain me why we have now Ant and Junit in the general java/lib directory (not even in a separate one like, say, "/tools"). These are really "forced down the throat" libraries, totally useless to users, so what? Jetty would be even more useful, since it would ease the life of both users and developers (not developers alone), so while again I sympathize with the concept of not bloating the codebase, I still think that pros and cons might be in favor of including it. But since it looks like it's only me, then let's keep (again...:-/) the current setup.
Ciao,
I'm FOR a standalone version. I'm FOR an embedded version. I'm FOR a .war deployable version.
I think that we can all agree to that. Why not include the jar in cvs main trunk? What if 18 other mutations stroll along, which are all viable? Include them all in cvs? or find a better way to make them all happen? Wouldn't it then be confusing, looking at cvs to see what xindice core really depends on?
CVS is for developers, not users, I agree. We also need the people who start off as 'users' to become contributing 'developers'. But if the cvs includes everything under the sun, it can become a daunting, overwhelming task to new members wanting to contribute.
-Kevin
