Kevin Ross wrote:

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,

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.

Let me see if I got your point correctly. You are saying "let's have the possibility to have all version, and use tools such as the ant <get> task in order to automate the process, so that we don't overcrowd the CVS repository". Have I got it right?


I'm FOR a standalone version. I'm FOR an embedded version. I'm FOR a .war deployable version.

OK, +1 here.

I think that we can all agree to that. Why not include the jar in cvs main trunk?

This is the question I'm asking, actually. :-)

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?

I really don't think so. As of now Xindice depends on an application server to have network access. We are just providing one. I would be of course much happier if we could provide Tomcat, but given that Bloatcat as of now is...well... we all know :-), then Jetty looked to me as a good compromise. If another suitable servlet engine shows up, or if we find a better way to access Xindice remotely, we might just change it and it would be transparent to the user. Not to mention that this is totally transparent to the current setup too, you still get your deployable war if you like it, but you have an easy way to test Xindice out in a matter of minutes.


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.

Oh well... I don't really think that a couple of jars placed under /tools might make that big mess to the eye of the potential developer, given also the usability boost that they might provide, but I reckon that this is a matter of personal taste and I sure might be wrong.


Ciao,

--
Gianugo



Reply via email to