please help me get started with building a website

Discussion in 'Java' started by mr_wu, Apr 23, 2010.

  1. mr_wu

    mr_wu Guest

    Dear Group,

    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. Webserver I'm
    familiar is apache, sql server will be postgres.

    My background: I've already built a long running successful site with
    mod_perl/apache/dbi as backend/front end with very little javascripts.

    I wish to build on my java skills. I have already built a few
    original desktop apps using j2se and in terms of lines of code my
    experience with java is higher than perl. But I have known perl much
    longer and I can build a website very fast in perl.

    I am looking for something equivalent to mod_perl with perhaps a
    templating feature built-in. I've looked into Tomcat but after
    reading their intro + a bit more i'm not clear whether they have what
    i want or even how it fits into apache if at all. Is glassfish an
    alternative to Tomcat? What about jboss?

    I've also written a tiny java applet on my mod_perl site and I notice
    that the applet takes its time to load the first time. It's because
    the browser has to load JVM the first time? I'm afraid that this type
    of problem will be present if I were to use java for interactivity
    i.e. AJAX. True or false? If I use JAVA just for server side (JSP?),
    I won't see the problem? Will it be more interactive than pure
    mod_perl site? Just easier to develop? More scalable?

    Sorry for the long post

    Thanks in advance for any suggestions. Any reading material online or
    print? Server will be on linux. Development on Windows/Linux/Mac
    better?
     
    mr_wu, Apr 23, 2010
    #1
    1. Advertising

  2. mr_wu

    markspace Guest

    mr_wu wrote:

    >
    > I am looking for something equivalent to mod_perl with perhaps a
    > templating feature built-in. I've looked into Tomcat but after



    JSPs are templates for Java EE. You want primarily Parts I and II of
    this document:

    <http://java.sun.com/javaee/5/docs/tutorial/doc/>

    Look at the end part too for the sample applications. There are also
    lots of good books on JEE (used to be called J2EE). Check out some
    reviews on Amazon.


    > reading their intro + a bit more i'm not clear whether they have what
    > i want or even how it fits into apache if at all. Is glassfish an
    > alternative to Tomcat? What about jboss?



    Yes, Glassfish, JBoss and Weblogic all do basically the same thing as
    Tomcat. Tomcat is very popular, free, and used by lots of ISP and
    companies. Note that Tomcat primarily does just JSP and Servlets, which
    is the real core of the JEE spec. The rest of the spec (EJP, etc.) is
    not implemented by Tomcat. There are tons of books on Tomcat out there.

    To "fit Tomcat into Apache," use mod_jk:

    <http://tomcat.apache.org/connectors-doc/>


    >
    > I've also written a tiny java applet on my mod_perl site and I notice
    > that the applet takes its time to load the first time. It's because
    > the browser has to load JVM the first time? I'm afraid that this type
    > of problem will be present if I were to use java for interactivity
    > i.e. AJAX. True or false?



    True. Most Java websites use HTML and JavaScript for the front end, not
    Java applets. You might want to look into Java Server Faces.


    > If I use JAVA just for server side (JSP?),
    > I won't see the problem? Will it be more interactive than pure
    > mod_perl site? Just easier to develop? More scalable?



    Generally easier to develop with Java, I think, and more maintainable
    and scalable. Perl turns in to a big ball of ... something pretty
    quickly. Java tends to be more organized.

    <http://en.wikipedia.org/wiki/Big_ball_of_mud>

    >
    > Sorry for the long post
    >
    > Thanks in advance for any suggestions. Any reading material online or
    > print? Server will be on linux. Development on Windows/Linux/Mac
    > better?



    I think Windows/Ubuntu pretty much the same. Check out the JEE features
    of a good IDE. For example:

    <http://netbeans.org/kb/trails/java-ee.html>
     
    markspace, Apr 23, 2010
    #2
    1. Advertising

  3. mr_wu

    Tom Anderson Guest

    On Thu, 22 Apr 2010, markspace wrote:

    > The rest of the spec (EJP, etc.) is not implemented by Tomcat.


    I knew Esmond was a vital resource for java development, but i didn't
    realise he was mandated by the spec! :)

    tom

    --
    Per Dementia ad Astra
     
    Tom Anderson, Apr 23, 2010
    #3
  4. mr_wu

    markspace Guest

    Tom Anderson wrote:
    > On Thu, 22 Apr 2010, markspace wrote:
    >
    >> The rest of the spec (EJP, etc.) is not implemented by Tomcat.

    >
    > I knew Esmond was a vital resource for java development, but i didn't
    > realise he was mandated by the spec! :)



    Yeah that was supposed to be "EJB," just so the OP isn't totally
    confused by my typo.
     
    markspace, Apr 23, 2010
    #4
  5. mr_wu

    mr_wu Guest

    Thanks for very informative reply. JEE does have rather steep
    learning curve. But I believe it will pay off in the end.


    On Apr 22, 10:10 pm, markspace <> wrote:
    > mr_wu wrote:
    >
    > > I am looking for something equivalent to mod_perl with perhaps a
    > > templating feature built-in.   I've looked into Tomcat but after

    >
    > JSPs are templates for Java EE.  You want primarily Parts I and II of
    > this document:
    >
    > <http://java.sun.com/javaee/5/docs/tutorial/doc/>
    >
    > Look at the end part too for the sample applications.  There are also
    > lots of good books on JEE (used to be called J2EE).  Check out some
    > reviews on Amazon.
    >
    > > reading their intro + a bit more i'm not clear whether they have what
    > > i want or even how it fits into apache if at all.  Is glassfish an
    > > alternative to Tomcat?  What about jboss?

    >
    > Yes, Glassfish, JBoss and Weblogic all do basically the same thing as
    > Tomcat.  Tomcat is very popular, free, and used by lots of ISP and
    > companies.  Note that Tomcat primarily does just JSP and Servlets, which
    > is the real core of the JEE spec.  The rest of the spec (EJP, etc.) is
    > not implemented by Tomcat.  There are tons of books on Tomcat out there..
    >
    > To "fit Tomcat into Apache," use mod_jk:
    >
    > <http://tomcat.apache.org/connectors-doc/>
    >
    >
    >
    > > I've also written a tiny java applet on my mod_perl site and I notice
    > > that the applet takes its time to load the first time.  It's because
    > > the browser has to load JVM the first time?  I'm afraid that this type
    > > of problem will be present if I were to use java for interactivity
    > > i.e. AJAX.  True or false?  

    >
    > True.  Most Java websites use HTML and JavaScript for the front end, not
    > Java applets.  You might want to look into Java Server Faces.
    >
    > > If I use JAVA just for server side (JSP?),
    > > I won't see the problem?  Will it be more interactive than pure
    > > mod_perl site?  Just easier to develop?  More scalable?

    >
    > Generally easier to develop with Java, I think, and more maintainable
    > and scalable.  Perl turns in to a big ball of ... something pretty
    > quickly.  Java tends to be more organized.
    >
    > <http://en.wikipedia.org/wiki/Big_ball_of_mud>
    >
    >
    >
    > > Sorry for the long post

    >
    > > Thanks in advance for any suggestions.  Any reading material online or
    > > print?  Server will be on linux.  Development on Windows/Linux/Mac
    > > better?

    >
    > I think Windows/Ubuntu pretty much the same.  Check out the JEE features
    > of a good IDE.  For example:
    >
    > <http://netbeans.org/kb/trails/java-ee.html>
     
    mr_wu, Apr 27, 2010
    #5
  6. mr_wu

    Arne Vajhøj Guest

    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.

    The second is very standard Java EE.

    > Webserver I'm
    > familiar is apache, sql server will be postgres.
    >
    > My background: I've already built a long running successful site with
    > mod_perl/apache/dbi as backend/front end with very little javascripts.
    >
    > I wish to build on my java skills. I have already built a few
    > original desktop apps using j2se and in terms of lines of code my
    > experience with java is higher than perl. But I have known perl much
    > longer and I can build a website very fast in perl.
    >
    > I am looking for something equivalent to mod_perl with perhaps a
    > templating feature built-in. I've looked into Tomcat but after
    > reading their intro + a bit more i'm not clear whether they have what
    > i want or even how it fits into apache if at all. Is glassfish an
    > alternative to Tomcat? What about jboss?


    Tomcat, Glassfish and JBoss are all servers. Tomcat only implements the
    web part of Java EE while Glassfish and JBoss implements everything (and
    actually Glassfish and JBoss usually comes with Tomcat embedded for the
    web part).

    All of them give you the option of:
    - speaking HTTP directly with them
    - speak HTTP with Apache HTTPD and have that speak AJP with them

    > I've also written a tiny java applet on my mod_perl site and I notice
    > that the applet takes its time to load the first time. It's because
    > the browser has to load JVM the first time? I'm afraid that this type
    > of problem will be present if I were to use java for interactivity
    > i.e. AJAX. True or false? If I use JAVA just for server side (JSP?),
    > I won't see the problem? Will it be more interactive than pure
    > mod_perl site? Just easier to develop? More scalable?


    Java applets do come with a small load time. But on a new system
    it should not be that bad.

    Server side Java obviously does not have this problem.

    Server side Java is good for:
    - large sites with lots of code
    - sites with stateful clustering
    - sites with transaction requirements
    - sites that needs to integrate with web services, message queues and
    ERP systems

    > 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.

    Arne
     
    Arne Vajhøj, Apr 27, 2010
    #6
  7. mr_wu

    Tom Anderson Guest

    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/

    >> 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.

    tom

    --
    hypnopomp rapist
     
    Tom Anderson, Apr 27, 2010
    #7
  8. mr_wu

    Lew Guest

    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
     
    Lew, Apr 27, 2010
    #8
  9. mr_wu

    Tom Anderson Guest

    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
     
    Tom Anderson, Apr 27, 2010
    #9
  10. mr_wu

    Lew Guest

    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
     
    Lew, Apr 27, 2010
    #10
  11. mr_wu

    Arne Vajhøj Guest

    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
     
    Arne Vajhøj, Apr 28, 2010
    #11
  12. mr_wu

    Thufir Guest

    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
     
    Thufir, Apr 28, 2010
    #12
  13. mr_wu

    Tom Anderson Guest

    On Tue, 27 Apr 2010, Arne Vajh?j wrote:

    > 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.


    It connects java applets and javascript, in both directions. AJAX uses
    javascript. It could be used to build a front end which used applets and
    AJAX. So it has something to do with AJAX, and it's relevant to the OP's
    question.

    >> 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 burden of a very complex environment is common.
    >
    > But if it is managed properly it should not become a big problem.


    I wouldn't say it's a problem. But managing it properly is itself a
    significant amount of work. That's just the nature of the beast - the
    complexity has to go somewhere, it can't just go away.

    tom

    --
    I have no idea if its infected or anything, I don't check for viruses. Its
    gay. -- The Laird
     
    Tom Anderson, Apr 28, 2010
    #13
  14. mr_wu

    Tom Anderson Guest

    On Wed, 28 Apr 2010, Thufir wrote:

    > 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.


    Maven's not an alternative to ant, AIUI, it's more of a wrapper - it does
    a lot of standardised donkey work (fetching dependencies, compiling,
    building JARs, running tests etc) for you, as long as you submit to its
    rules for laying out packages, but if you want to do something that isn't
    standardised donkey work (and i'm not certain how far that goes, but i
    think things like loading databases, starting app servers etc are not
    covered), you're back to writing your own ant job.

    > 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?


    Yes, if you're willing to use one of those. I would absolutely love to
    move our build process over to groovy (and gant, which is a groovy API to
    ant's tasks, which are themselves often pretty useful), but that would
    involve adding a new language to the project - a language which nobody in
    our office knows, and which our clients don't know (so far, at least). At
    least with the bash-ant-java hybrid we have at the moment, when we hand a
    system over to a client they have a hope in hell of understanding it based
    on their existing knowledge.

    Yes, groovy is easy to learn. But that doesn't really matter, because when
    a project manager or a less-inquisitive developer sees the bullet point
    that says 'build system written in groovy', they go ballistic.

    That's the argument that's stopped us moving to groovy so far, anyway.
    There is a faction here which does not believe it, and continues to
    agitate for groovy, but so far he hasn't won out.

    tom

    --
    IMPORTANCE MEMO: >>> WHEN YOU BUY AN N-GAGE QD <<< PLEASE, please CONTINUE
    TO TALK ON THE SIDE!!$ Note: the other party will not be able to hear you,
    BUT WHO REALLY CRAPS A THING, SIDETALKIN' 2009++!!!
     
    Tom Anderson, Apr 28, 2010
    #14
  15. mr_wu

    Tom Anderson Guest

    On Tue, 27 Apr 2010, Lew wrote:

    > 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.


    Your brain may know all that, but my gut tells me otherwise.

    Okay, sounds like i should give cygwin a shot. Or rather, get one of the
    contractors who has a windows laptop to give cygwin a shot.

    tom

    --
    IMPORTANCE MEMO: >>> WHEN YOU BUY AN N-GAGE QD <<< PLEASE, please CONTINUE
    TO TALK ON THE SIDE!!$ Note: the other party will not be able to hear you,
    BUT WHO REALLY CRAPS A THING, SIDETALKIN' 2009++!!!
     
    Tom Anderson, Apr 28, 2010
    #15
  16. mr_wu

    mr_wu Guest

    Thanks for all replies which are very informative.

    Ideally I would like to develop on git + Ubuntu and push to a redhat
    server.
    But I'm currently using Netbeans on Mac to learn jee since
    virtualization
    on this Mac isn't acceptably fast.

    My other question is what packages must be installed on linux live
    server
    if I am not doing most development on there? In principle I don't
    need to install
    jdk right? I make jar or war or ear on development box and then push
    these to live server where JRE there would take care of serving pages
    and app?

    Learning with IDE makes these issues not very obvious. Is there any
    learning trail out there
    which involves only shell and on linux?
     
    mr_wu, May 6, 2010
    #16
  17. mr_wu

    Roedy Green Guest

    On Wed, 5 May 2010 16:50:43 -0700 (PDT), mr_wu <>
    wrote, quoted or indirectly quoted someone who said :

    >My other question is what packages must be installed on linux live
    >server
    >if I am not doing most development on there? In principle I don't
    >need to instal


    You want to run your IDE/editor on a local desktop. You might consider
    setting up a LAN with some old machines to do things like testing.
    You will want your JDK on whatever machine you do your editing.
    --
    Roedy Green Canadian Mind Products
    http://mindprod.com

    What is the point of a surveillance camera with insufficient resolution to identify culprits?
     
    Roedy Green, May 6, 2010
    #17
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.

Share This Page