Prev: OutOfMemory using ThreadPoolExecutor
Next: JAVA Applet Security Question
From: Lew on 27 Apr 2010 15:06
Tom Anderson wrote:
> Still, in practice what we end up doing is writing trillions of lines of
> bash script. The trouble is that ant is an utterly, utterly appalling
> language, far more verbose and fiddly than shell script, and agonising if
> you want to anything even a bit unusual. So we write shell script. And hey
> presto, while we can run on any linux machine with only minor tweaking (eg
> the xmlstarlet command-line XML processor is invoked as xmlstar on Debian,
> but xml on CentOS), and on OS X with a bit more tweaking (install lots of
> GNU utilities from MacPorts, change readlink to greadlink throughout,
> etc), you're hosed if you want to run on Windows.
>

Not so much so if you use bash.

> Luckily, our development landscape is almost always linux from development to production,
> with the very occasional sidestep onto OS X for laptops, so the pain is minimal.
>
> Conversely, if you developed on Windows, but deployed on unix, if you
> wrote your build system in batch script, you'd be stuffed. Luckily, batch
> script is so awful that you wouldn't do this; you'd even use ant in
> preference, so you'd have a better shot at being portable from the start.
>

Fortunately you can use bash on Windows if you install Cygwin, which
restores your portability.

--
Lew

From: Tom Anderson on 27 Apr 2010 16:01
On Tue, 27 Apr 2010, Lew wrote:

> Tom Anderson wrote:
>
>> Still, in practice what we end up doing is writing trillions of lines
>> of bash script. The trouble is that ant is an utterly, utterly
>> appalling language, far more verbose and fiddly than shell script, and
>> agonising if you want to anything even a bit unusual. So we write shell
>> script. And hey presto, while we can run on any linux machine with only
>> minor tweaking (eg the xmlstarlet command-line XML processor is invoked
>> as xmlstar on Debian, but xml on CentOS), and on OS X with a bit more
>> tweaking (install lots of GNU utilities from MacPorts, change readlink
>> to greadlink throughout, etc), you're hosed if you want to run on
>> Windows.
>
> Not so much so if you use bash.
>
>> Luckily, our development landscape is almost always linux from development to production,
>> with the very occasional sidestep onto OS X for laptops, so the pain is minimal.
>>
>> Conversely, if you developed on Windows, but deployed on unix, if you
>> wrote your build system in batch script, you'd be stuffed. Luckily, batch
>> script is so awful that you wouldn't do this; you'd even use ant in
>> preference, so you'd have a better shot at being portable from the start.
>
> Fortunately you can use bash on Windows if you install Cygwin, which
> restores your portability.

It's not just bash. It's bash and all the other unix utilities the scripts
use, and the existence of /tmp, the ability to ssh to another machine and
run commands on it, etc. It would be interesting to see if it could be
ported, but i'd very much prefer that someone other than me tried it!

tom

--
Infantry err, infantry die. Artillery err, infantry die. -- IDF proverb
From: Lew on 27 Apr 2010 18:44
Lew wrote:
>> Fortunately you can use bash on Windows if you install Cygwin, which
>> restores your portability.

Tom Anderson wrote:
> It's not just bash. It's bash and all the other unix utilities the
> scripts use, and the existence of /tmp, the ability to ssh to another
> machine and run commands on it, etc. It would be interesting to see if
> it could be ported, but i'd [sic] very much prefer that someone other than me
> tried it!

All of that is in the Cygwin suite. I've been doing it for a decade,
including port-forwarding X-Windows over SSH, database connections, using
"scp", whatever.

--
Lew
From: Arne Vajhøj on 27 Apr 2010 19:48
On 27-04-2010 13:58, Tom Anderson wrote:
> On Mon, 26 Apr 2010, Arne Vajh?j wrote:
>
>> On 22-04-2010 21:39, mr_wu wrote:
>>> Can you kindly give me suggestions on using Java as the main component
>>> in website building? I'm especially interested in using it in backend
>>> as well as front end and incorporate hopefully AJAX.
>>
>> Do you want to use Java both in frontend of the server side and backend
>> of the server side or both at client and server?
>>
>> The first rules out AJAX unless you plan on using GWT.
>
> Or LiveConnect. No school like the old school!
>
> https://jdk6.dev.java.net/plugin2/liveconnect/

That has nothing to do with AJAX.

>>> Thanks in advance for any suggestions. Any reading material online or
>>> print? Server will be on linux. Development on Windows/Linux/Mac
>>> better?
>>
>> It should not matter that you develop on another platform than the one
>> you deploy at.
>
> As far as everything inside the WAR/EAR is concerned, this is true.
> Although if there's a lot of money depending on your app, i'd certainly
> suggest doing QA on the same platform.
>
> However, things outside the WAR/EAR may not be so portable. In my apps
> i've worked on, there is a colossal amount of what we generically term
> 'build scripts', which is the stuff that takes a fresh checkout from CVS
> on a blank machine and turns it into a running system: that's everything
> from compilation, management and implementation of configuration
> options, EAR/WAR assembly, configuration file preparation, database
> schema definition, data load, app server startup and monitoring (and
> shutdown), and post-startup configuration and activation steps. And
> running unit tests.
>
> It's possible to do much or all of that portably - ant was made to do
> this (more or less), and what you can't do in ant, you can do in java
> (perhaps by writing an ant task). The only places where you're in real
> trouble are when you're interacting with different interfaces (eg the
> start scripts for Tomcat and JBoss, which take different parameters),
> but that's just a matter of isolating that and writing implementations
> for each interface.
>
> Still, in practice what we end up doing is writing trillions of lines of
> bash script. The trouble is that ant is an utterly, utterly appalling
> language, far more verbose and fiddly than shell script, and agonising
> if you want to anything even a bit unusual. So we write shell script.
> And hey presto, while we can run on any linux machine with only minor
> tweaking (eg the xmlstarlet command-line XML processor is invoked as
> xmlstar on Debian, but xml on CentOS), and on OS X with a bit more
> tweaking (install lots of GNU utilities from MacPorts, change readlink
> to greadlink throughout, etc), you're hosed if you want to run on
> Windows. Luckily, our development landscape is almost always linux from
> development to production, with the very occasional sidestep onto OS X
> for laptops, so the pain is minimal.
>
> Conversely, if you developed on Windows, but deployed on unix, if you
> wrote your build system in batch script, you'd be stuffed. Luckily,
> batch script is so awful that you wouldn't do this; you'd even use ant
> in preference, so you'd have a better shot at being portable from the
> start.

The burden of a very complex environment is common.

But if it is managed properly it should not become a big problem.

KISS is good for the software itself. But it is even better for
the "home made tools" to support the software.

Arne

From: Thufir on 28 Apr 2010 03:28
On Tue, 27 Apr 2010 18:58:47 +0100, Tom Anderson wrote:


> It's possible to do much or all of that portably - ant was made to do
> this (more or less), and what you can't do in ant, you can do in java
> (perhaps by writing an ant task).

There are other build scripts besides ant, most notably maven. In java,
there's groovy. I've used ruby & rake, and there are a variety of java
build projects based upon ruby and rake which simplify things.

Would any of those solve that problem, I wonder?

-Thufir
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: OutOfMemory using ThreadPoolExecutor
Next: JAVA Applet Security Question