I'm not in favor of this approach. People writing java applications have to deal with classpath issues, and our TIMs are no harder nor no easier than any other library (actually, I think the availability as maven dependencies does make them easier to consume, but only for maven users).
The major concern I have here is along the same lines of Alex's reasoning - making the job ultimately more difficult due to the asymmetrical nature of the compile time processes vs. deployment time processes. I guess if we can somehow solve the problem of ALSO exposing these classes into userland at runtime, then maybe you could get away with it, but can we solve that problem? Because if we can't then the user STILL has to deploy those libraries per their particular application policies, and so we are really just making it harder for the developer in the long run to parse out what the proper strategy is. If OTOH we go the simple route, the developer figures out the classpath and jar issues upfront and that doesn't change as they go to deploy the app. And if we can, I'm still not sure we should embark on a process to provide the end user with even more magic. My $0.02 ----- Original Message ----- From: "Alex Miller" <amil...@terracottatech.com> To: tc-dev@lists.terracotta.org Sent: Saturday, January 31, 2009 3:21:29 AM GMT -08:00 US/Canada Pacific Subject: Re: [tc-dev] ConcurrentStringMap and eclipse On the Eclipse plugin, my initial thought was that this wasn't worth it. Seemed like explaining the magic of auto-including the tim as a library is more complicated than having someone include the library. But, on a second thought, if we integrate tim-get like functionality into the Eclipse plugin (which I don't think is there yet?) then, it might make sense for that piece to also offer to update your Eclipse classpath for certain libraries. I worry about making the classpath stuff in Maven any harder to understand than it already is so I think I would tread very carefully. There is maybe a bigger discussion that we've touched on in the past about whether it is a good thing to be merging end-user library code and tim configuration in a single jar used from two locations. To me, that's a more important discussion than the ones above. ----- Original Message ----- From: "Tim Eck" <t...@terracottatech.com> To: tc-dev@lists.terracotta.org Sent: Friday, January 30, 2009 1:03:49 PM GMT -06:00 US/Canada Central Subject: Re: [tc-dev] ConcurrentStringMap and eclipse RE: [tc-dev] ConcurrentStringMap and eclipse I kinda feel like this might be paving the cow path, but I wonder if we might want some special treatment in the TC eclipse plugin for TIMs that have compile time APIs. Seems like specially tagged TIMs could be auto-added to the classpath of the project. What about something similar in the tc-maven-plugin? > -----Original Message----- > From: tc-dev-boun...@lists.terracotta.org [ mailto:tc-dev- > boun...@lists.terracotta.org] On Behalf Of Geert Bevin > Sent: Friday, January 30, 2009 2:07 AM > To: tc-dev@lists.terracotta.org > Subject: Re: [tc-dev] ConcurrentStringMap and eclipse > > If you set it up as a Maven dependency and use the project as a Maven > project in Eclipse, it should automatically be added to your build > path. Otherwise, the manual method should work just fine. > > On 30 Jan 2009, at 11:03, Steven Harris wrote: > > > When using a tim that has an api to it, what is the proper way in > > eclipse to have that api in your build path. > > Is it just the old standby add external jar (which I did and worked) > > or is their something simpler? > > -- > Geert Bevin > Terracotta - http://www.terracotta.org > Uwyn "Use what you need" - http://uwyn.com > RIFE Java application framework - http://rifers.org > Flytecase Band - http://flytecase.be > Music and words - http://gbevin.com > > _______________________________________________ > tc-dev mailing list > tc-dev@lists.terracotta.org > http://lists.terracotta.org/mailman/listinfo/tc-dev _______________________________________________ tc-dev mailing list tc-dev@lists.terracotta.org http://lists.terracotta.org/mailman/listinfo/tc-dev _______________________________________________ tc-dev mailing list tc-dev@lists.terracotta.org http://lists.terracotta.org/mailman/listinfo/tc-dev
_______________________________________________ tc-dev mailing list tc-dev@lists.terracotta.org http://lists.terracotta.org/mailman/listinfo/tc-dev
