I think we can solve the issue in the short term with a faq and or a
short tutorial.
Cheers,
Steve Harris
"Terracotta. It's ten pounds of awesome in a five pound sack."
On Jan 31, 2009, at 11:16 PM, Taylor Gautier wrote:
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
_______________________________________________
tc-dev mailing list
tc-dev@lists.terracotta.org
http://lists.terracotta.org/mailman/listinfo/tc-dev
