>> Why are you using the jars from the app server would be my question. > > * Because I wouldn't want to modify the installation? > * Because I'd like to deliver my application to customers so that they > can deploy in an unmodified environment? > * Because it works fine that way with the current policy? > > Pick your choice.
No need to modify the installation. Just a matter of class loading. >> IMO that's irrelevant as the users decide whether they upgrade or not. > > You don't get the point. With the commons libraries, there frequently > isn't *the* user. In the scenario I outlined above, there are at least > 3 different "users" (from a commons perspective): > > - The quality managers and or programmers that decide what's > destributed as part of the application server. > - The application programmers (like me), that build generic > applications which are running within this application server. > - The customers programmers which are customizing or using the > applications I have built. Not sure why customers programmers matter here. There really is just one "user" - the guy that picks the version number. That can be you or the customers programmer. The containers jar shouldn't really be relevant if your app is setup correctly. > Decisions aren't done unilaterally. If you don't want the control you have to deal with what the container gives you. Then the container becomes part of you project dependency. Otherwise it's just that user type guy picking the version. Anyway ... that were already 3 cents. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
