Thanks, Vijay. We'll evaluate this, too.
On Friday, January 17, 2014 5:20:12 PM UTC-5, Vijay Kiran wrote:
>
>
> May be this would help? https://github.com/flatland/classlojure
>
> On Thursday, January 16, 2014 5:13:11 PM UTC+1, solo...@gmail.com wrote:
>>
>> Quick update and question: We've put to
Good deal, thanks for keeping me posted. Let me know if you run in to
any issues.
- Toby
solo.l...@gmail.com writes:
> An update, Toby--my colleague wrote a simple app with ShimDandy and it's
> working. So far so good. We're going to present it as a possible solution
> to our users on Wednesda
An update, Toby--my colleague wrote a simple app with ShimDandy and it's
working. So far so good. We're going to present it as a possible solution
to our users on Wednesday and see what happens.
On Thursday, January 16, 2014 12:59:47 PM UTC-5, Toby Crawley wrote:
>
> The isolation in Immutant i
Thank you, Toby. I've shared this with my colleagues involved in this
project and we're taking a look at it now.
On Thursday, January 16, 2014 12:59:47 PM UTC-5, Toby Crawley wrote:
>
> The isolation in Immutant is achieved (in part) by ShimDandy[1], which
> can be used outside of Immutant with
May be this would help? https://github.com/flatland/classlojure
On Thursday, January 16, 2014 5:13:11 PM UTC+1, solo...@gmail.com wrote:
>
> Quick update and question: We've put together a preliminary migration plan
> and are considering options.
>
> Can someone share information or point me t
The isolation in Immutant is achieved (in part) by ShimDandy[1], which
can be used outside of Immutant with a bit of work. It's been on my list
for a while now to provide a sample application demonstrating usage -
there is a minimal example in the README.
Let me know if you are interested in the S
Yes, but this requires custom class loaders. AFAIK this is already
implemented in Immutant project (http://immutant.org/)
On Thursday, January 16, 2014 11:13:11 PM UTC+7, solo...@gmail.com wrote:
>
> Quick update and question: We've put together a preliminary migration plan
> and are considering
Quick update and question: We've put together a preliminary migration plan
and are considering options.
Can someone share information or point me to where I can learn whether two
different versions of Clojure (1.2 and 1.5) can run in the same JVM?
--
--
You received this message because you
Thanks, Alex.
I agree that migrating these tiny 1.2 applications would be wasted effort
as the majority won't change and will become obsolete soon anyway.The ones
which will remain relevant will be easy to identify and may be worth
migrating.
Regarding testing, no, I have no confidence in thes
Will do. Once the migration is steady (that is, we have a 1.2 and 1.5
environment running concurrently), I'll write a post about the experience
and how we will eventually decommission the 1.2 environment.
On Tuesday, December 24, 2013 1:48:22 PM UTC-5, Sean Corfield wrote:
>
> On Tue, Dec 24, 20
Hi Solo,
I did a big migration from 1.2 to 1.5 at work this past February. Here are
a few of the things that I gleaned from that experience, i addition to the
great advice mentioned already in this thread:
* with 1000's of these applications, I'd take the approach of only
migrating to 1.5 when t
On Tue, Dec 24, 2013 at 7:23 AM, wrote:
> Yes, after looking into this, upgrading the libraries before upgrade the
> Clojure version is unfeasible in our case. I prefer not to keep a 1.2
> environment around forever but take our time phasing it out to avoid service
> disruption. I think the dual
That's exactly right. Almost all the report writers started their report by
copying and pasting something previously and winging along. As a result, I
see a lot of them with the same namespace setup but I suspect most of that
functionality is not being used. I'm selling the idea that we'll need
Yes, after looking into this, upgrading the libraries before upgrade the
Clojure version is unfeasible in our case. I prefer not to keep a 1.2
environment around forever but take our time phasing it out to avoid
service disruption. I think the dual environment consensus here is the way
to go.
It sounds like the vast majority of these apps will simply sit on the
shelf, with no need to ever run them again. So, as long as you have
a way to run them at need, in an accurate and acceptably prompt manner,
you don't have to worry about porting the code.
So, if you can keep a Clojure 1.2 envir
One difficulty with this approach (which I largely following on a similar
operation a while back) is that the modular counterparts have continued
forward and in many cases are not API-compatible with the 1.2 version
anymore (tools.cli is one example that I remember from this transition as
its A
Yep, those links were useful. Cheers, Sean.
--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To
On Sun, Dec 22, 2013 at 4:07 PM, wrote:
> A third option I'm considering is to simply keep running 1.2 and replace the
> contrib libraries with their modular counterparts, moving to 1.5 only after
> that's done. The two difficulties I see here are:
> 1) Ensuring all new reports written during thi
On Sun, Dec 22, 2013 at 4:13 PM, wrote:
> Could you point to more information regarding the numeric changes? I can't
> seem to pinpoint anything in particular here:
> https://github.com/clojure/clojure/blob/1.3.x/changes.txt
That document links to these:
* http://dev.clojure.org/display/design/
Could you point to more information regarding the numeric changes? I can't
seem to pinpoint anything in particular here:
https://github.com/clojure/clojure/blob/1.3.x/changes.txt
On Sunday, December 22, 2013 7:05:13 PM UTC-5, Sean Corfield wrote:
>
> If you truly have "thousands" of Clojure 1.2 a
Thanks, Sean. Yes, the reports are static and not maintained. The lifecycle
of the typical report is as follows:
1) Business requests data
2) Someone writes a report using Clojure
3) Business views the report and may request changes now and then
4) Business eventually loses interest
Part of my pl
A third option I'm considering is to simply keep running 1.2 and replace
the contrib libraries with their modular counterparts, moving to 1.5 only
after that's done. The two difficulties I see here are:
1) Ensuring all new reports written during this process use the modular
libraries
2) What to
If you truly have "thousands" of Clojure 1.2 apps, I'd go with option
1), and look at migrating legacy reports over if you need to do any
maintenance on them. Since Clojure is "just" a Java library, it's
fairly easy to keep the Clojure version locked in each individual
project so there's no reason
At my company, we use Clojure for reporting. Specifically, reports are
written in Clojure which integrate data from a variety of sources and
display the final output to the user in a WPF-based webapp.
For all intents and purposes, each 'report' is a standalone Clojure app,
and most of them use
24 matches
Mail list logo
