How to develop without an IDE?

[Rui Maciel]

Is it possible to set up a Java project so that it can be built without
relying on an IDE? If it is, where can I find any information on how to set
up this sort of project?

Bonus points if it's possible to pull this off by writing a single makefile.


Thanks in advance,
Rui Maciel

[David Lamb]

On 22/04/2012 11:15 AM, Rui Maciel wrote:
> Is it possible to set up a Java project so that it can be built without
> relying on an IDE? If it is, where can I find any information on how to set
> up this sort of project?
>
> Bonus points if it's possible to pull this off by writing a single makefile.

I've always used a combination of Emacs and make. Given your "single
makefile" question, though, I suspect you may have more sophisticated
needs than I do. Care to elaborate?

[Knute Johnson]

I use Vim to edit, and a batch file to compile and jar up the classes.
And often a batch file to start them as well.

--

Knute Johnson

[Andreas Leitgeb]

Not sure if I clarify the OP, or "hijack" his thread, but
suppose you created a working environment in eclipse consisting
of a couple of projects, then what tools are there to create
e.g. an "ant" or "maven"-script from eclipse's own project-
control files, that would allow a headless machine to build
a runnable jar-file with all project-dependencies just like
eclipse does?

Even if the OP didn't mean that, I'd still like to know - so
much for hijacking ;)

[Arne Vajhøj]

On 4/22/2012 11:15 AM, Rui Maciel wrote:
> Is it possible to set up a Java project so that it can be built without
> relying on an IDE? If it is, where can I find any information on how to set
> up this sort of project?
>
> Bonus points if it's possible to pull this off by writing a single makefile.

Very few rely on their IDE to build for serious projects.

They use tools like Ant or Maven to build with.

You can also write the code without an IDE, but why not utilize
the extra support you get from a Java aware IDE.

Arne

[markspace]

On 4/22/2012 8:15 AM, Rui Maciel wrote:
> Is it possible to set up a Java project so that it can be built
> without relying on an IDE? If it is, where can I find any
> information on how to set up this sort of project?
>
> Bonus points if it's possible to pull this off by writing a single
> makefile.

Yes of course. The devil will be in the details however.

<http://docs.oracle.com/javase/7/docs/technotes/tools/>

<http://www.gnu.org/software/make/manual/make.html>

[Lew]

OP: Be careful that your problem statement doesn't limit your solution space.

Arne knew that makefiles are not literally the best build mechanism for Java,
so unlike those others who specifically dicussed make with you, he gave you
the idiomatically Java equivalent.

I'm not aware of any prevalence of make in the Java build-and-deployment world.

Ant and Maven are the two most standard mechanisms. Real-life Java
build-and-deployment systems are edifices of scripts (shell, Python, Ruby,
...), continuous-integration (CI) platforms, Ant and/or Maven,
intelligently-crafted logging (of the builds, not just the program runs), and
often much more.

As a solo practitioner you can readily put together a decent ecosystem with
open-source tools, e.g., for Java EE:

git version-control repository
Jenkins continuous-integration framework
Ant build system
bash
Python
Junit unit test framework
EasyMock mock objects for testing code
FindBugs find bugs in source code
Glassfish application server
Geronimo, JBoss
Tomcat, Jetty simpler app server
JSPs, no EJBs, JMX, etc., unless plugins
Apache Web Server HTTP server - all kinds of proxy magic, etc.
EclipseLink, OpenJPA JPA - Java Persistence API)
Postgres RDBMS
Your favorite editor(s) and IDE(s)

You certainly do not need an IDE for any of that, and quite frankly, none of
your build and test stuff should use any IDE files directly, nor should most
editor- or IDE-specific files be in the trunk of your code repository.

With such a suite of tools, I still would add NetBeans or Eclipse (among the
free options) or Aptana (based on Eclipse) as an IDE. While an IDE is not
essential to system development, it is very helpful.

They not only help with code development, they make great dashboards to manage
your libraries, databases, servers, logs, test frameworks, and other tools,
and the interactions amongst them. We programmers tend to monomaniacally focus
only on how IDEs help code production. They are also very handy, particularly
for the solo stages (developer workstation or individual consultant's
production box), to manage the myriad operations matters.

http://git-scm.com/
http://jenkins-ci.org/
http://ant.apache.org/
http://www.ubuntu.com/
http://www.cygwin.com/
http://www.python.org/
http://www.junit.org/
http://www.easymock.org/
http://findbugs.sourceforge.net/
http://glassfish.java.net/
http://geronimo.apache.org/
http://www.jboss.org/
http://tomcat.apache.org/
http://www.eclipse.org/jetty/
http://httpd.apache.org/
http://www.eclipse.org/eclipselink/
http://openjpa.apache.org/
http://www.postgresql.org/
http://www.gnu.org/software/emacs/
http://netbeans.org/
http://eclipse.org/
http://www.aptana.com/

--
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

[Martin Gregorie]

On Sun, 22 Apr 2012 16:15:30 +0100, Rui Maciel wrote:

> Is it possible to set up a Java project so that it can be built without
> relying on an IDE? If it is, where can I find any information on how to
> set up this sort of project?
>

Simple. Do just as you would for, say, a C project but use Ant instead of
make.

> Bonus points if it's possible to pull this off by writing a single
> makefile.
>

Its the norm to use a single build.xml (ant's equivalent of Makefile) to
do everything that make will, i.e. build, clean the source structure,
install the jarfiles. The only significant differences are that its
working with a package hierarchy rather than a set of modules in separate
directories and that it will usually run javadocs too.

This is how I usually work with Java projects, often over an ssh session.


--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |

[Arne Vajhøj]

On 4/22/2012 2:35 PM, Lew wrote:
> On 04/22/2012 09:36 AM, Arne Vajhøj wrote:
>> On 4/22/2012 11:15 AM, Rui Maciel wrote:
>>> Is it possible to set up a Java project so that it can be built without
>>> relying on an IDE? If it is, where can I find any information on how
>>> to set
>>> up this sort of project?
>>>
>>> Bonus points if it's possible to pull this off by writing a single
>>> makefile.
>>
>> Very few rely on their IDE to build for serious projects.
>>
>> They use tools like Ant or Maven to build with.
>>
>> You can also write the code without an IDE, but why not utilize
>> the extra support you get from a Java aware IDE.
>
> OP: Be careful that your problem statement doesn't limit your solution
> space.
>
> Arne knew that makefiles are not literally the best build mechanism for
> Java, so unlike those others who specifically dicussed make with you, he
> gave you the idiomatically Java equivalent.
>
> I'm not aware of any prevalence of make in the Java build-and-deployment
> world.

make and Java is like square form and wheels. Not a good mix.

Arne

[Steven Simpson]

On 22/04/12 16:15, Rui Maciel wrote:
> Is it possible to set up a Java project so that it can be built without
> relying on an IDE? If it is, where can I find any information on how to set
> up this sort of project?
>
> Bonus points if it's possible to pull this off by writing a single makefile.

Though I use Eclipse for any project of more than a few source files, I
don't use it for building. The projects include the necessary scripts
to be built stand-alone.

I did explore trying to get 'make' to handle per-file dependencies, and
I haven't totally given up yet, but for now I've settled for per-jar
dependencies. I have a pre-packaged 'make' include file, and tell it
that jar foo depends upon the 'API' of jar bar, and it works out rules
that allow compilation of foo to be necessary only if any of foo's
sources have changed (of course), or the API of bar has changed - so bar
can change internally without necessarily triggering recompilation of foo.

Within a jar, nothing special is going on - it's a clean build.

A jar's API is derived from the class files immediately after
compilation. I originally used javap and gawk for this, but javap's
text output is not a consistent format from one vendor to the next, and
the gawk processing is slow, so I eventually wrote a Java program to
parse the class files directly. It's a little faster, and should be
more broadly compatible. However, I think it's still substantially
slower than simply doing clean builds on all jars unconditionally.

Details here:

<http://www.comp.lancs.ac.uk/~ss/software/pkg-jardeps>

Cheers,

Steven

--
ss at comp dot lancs dot ac dot uk

[BGB]

it does technically work though, and may make some sense, say, if one is
also building a bunch of C code (say, as part of a JNI wrapper for
native code or similar), or is generally part of a larger project for
which make is already used.

[Arne Vajhøj]

I would rather call ant from make or make from ant to handle those
situations.

Arne

[BGB]

yes, this works as well.

I guess it is probably whichever is more convenient.

[Nasser M. Abbasi]

On 4/22/2012 10:28 PM, BGB wrote:

>>>
>>> it does technically work though, and may make some sense, say, if one is
>>> also building a bunch of C code (say, as part of a JNI wrapper for
>>> native code or similar), or is generally part of a larger project for
>>> which make is already used.
>>
>> I would rather call ant from make or make from ant to handle those
>> situations.
>>
>
> yes, this works as well.
>
> I guess it is probably whichever is more convenient.

I found that using one good tool for everything is better than
mixing things.

Also, gnumake can do so many more things than just build source
code. I use it to update my html files and pdf files from
Latex sources, and other such things.

As long as the idea that drives the tool is: Perform this action
to update these prerequisites that this target depends on, then better
to use one tool that does this better and for many other things, not
just .java files.

In my tree, I have .f, .f90, .c, .c++, .java, .tex, and many
other files that I want to 'update' in my tree.

Using one tool for all, is better, because one becomes better
at using this one tool, and things are integrated better.
gnumake+bash is pretty much all what I need.

I tried ant, and found that I am doing the same thing I
am already doing in my Makefile, just had to use different
syntax. (I also did not like XML syntax). Also looked at Ruby
script, and few other things. They all pretty much try to do
what Make allready does but using different syntax.

It is very easy to use gnumake to build Java and make jar files and
all. Here is a link showing Makefile for Java from the best book
on gnumake "Managing Projects with GNU make" by Robert Mecklenburg

http://www.makelinux.net/make3/make3-CHP-9#make3-CHP-9

Chapter 9 is all about using make for build Java.

As others said. If you are using an IDE with its own build
system. It is better to have your own makefile to build
your tree, independent of what the IDE has. This way, if
you changed IDE, or move your tree somewhere else where
this IDE is not available, you can still build your tree
any where.

--Nasser

[Leif Roar Moldskred]

Nasser M. Abbasi <n...@12000.org> wrote:
>
> I found that using one good tool for everything is better than
> mixing things.

[SNIP]

> In my tree, I have .f, .f90, .c, .c++, .java, .tex, and many
> other files that I want to 'update' in my tree.

You see no contradiction here?

--
Leif Roar Moldskred

[Nasser M. Abbasi]

What contradiction?

I use Makefile to build all the my programs?

Do you mean, why I use different languages? And I should
use one programming language? is that what you mean?

If I can find one programming language that meets all my
programming needs, then I'll use that one language, but
have not found one yet.

--Nasser

[Roedy Green]

On Sun, 22 Apr 2012 16:15:30 +0100, Rui Maciel <rui.m...@gmail.com>
wrote, quoted or indirectly quoted someone who said :

>Is it possible to set up a Java project so that it can be built without
>relying on an IDE? If it is, where can I find any information on how to set
>up this sort of project?

see http://mindprod.com/jgloss/ant.html
--
Roedy Green Canadian Mind Products
http://mindprod.com
When you were a child, if you did your own experiment
to see if it was better to put to cocoa into your cup first
or the hot milk first, then you likely have the programmer gene..

[BGB]

yeah...

in my case, my project currently uses 5 different programming languages
(to a greater or lesser degree, list does not include makefiles),
several smaller/special purpose DSLs, and an assortment of specialized
file-formats.


I also generally use Make as well...

[Leif Roar Moldskred]

I'm just saying that "using one good tool for everything" is no more
(nor less) the right approach when it comes to build systems than when
it comes to programming languages.

--
Leif Roar Moldskred

[Daniel Pitts]

for small scale projects, a command line works perfectly well.

I would run commands such as: javac net/virtualinfinity/myproject/Main.java

Once in a while I'd have to do a rm `find . | grep ".class$"` and the
like to do a "clean" build.

Why not use an IDE though? They provide so much!

[Robert Klemme]

On 23.04.2012 06:57, Nasser M. Abbasi wrote:
> On 4/22/2012 10:28 PM, BGB wrote:
>
>>>>
>>>> it does technically work though, and may make some sense, say, if
>>>> one is
>>>> also building a bunch of C code (say, as part of a JNI wrapper for
>>>> native code or similar), or is generally part of a larger project for
>>>> which make is already used.
>>>
>>> I would rather call ant from make or make from ant to handle those
>>> situations.
>>>
>>
>> yes, this works as well.
>>
>> I guess it is probably whichever is more convenient.
>
> I found that using one good tool for everything is better than
> mixing things.

Which, if followed religiously, will lead you into a situation where it
can get really awkward to do things with tool A which would be extremely
easy with tool B.

> Also, gnumake can do so many more things than just build source
> code. I use it to update my html files and pdf files from
> Latex sources, and other such things.

No wonder because make doesn't do *any* of these things. Make evaluates
timestamps along dependencies (mostly between files) and invokes other
programs that do all the work. GNU make additionally has an extremely
large database of predefined rules, has functions and other capabilities.

> As long as the idea that drives the tool is: Perform this action
> to update these prerequisites that this target depends on, then better
> to use one tool that does this better and for many other things, not
> just .java files.

Interestingly GNU make's large built in rule database does not contain
anything related to compiling Java. How do you create your Makefiles in
a way as to invoke javac only for those files which have changed -
especially in light of the fact that one Java source file might create
multiple .class files?

> In my tree, I have .f, .f90, .c, .c++, .java, .tex, and many
> other files that I want to 'update' in my tree.
>
> Using one tool for all, is better, because one becomes better
> at using this one tool, and things are integrated better.
> gnumake+bash is pretty much all what I need.

I'm with Leif: if you drink your own cool aid you should be throwing out
all those languages and resort to language [ ] only.

> I tried ant, and found that I am doing the same thing I
> am already doing in my Makefile, just had to use different
> syntax. (I also did not like XML syntax). Also looked at Ruby
> script, and few other things. They all pretty much try to do
> what Make allready does but using different syntax.

I disagree: ant is very different from make. Ant has built in tasks and
knows itself how to accomplish them. You can even teach it more tasks
via its extension interface. ant rules for building Java projects are
almost certainly a lot simpler than the same for make - as that example
proves.

> It is very easy to use gnumake to build Java and make jar files and
> all. Here is a link showing Makefile for Java from the best book
> on gnumake "Managing Projects with GNU make" by Robert Mecklenburg
>
> http://www.makelinux.net/make3/make3-CHP-9#make3-CHP-9

I did not see the advertized Makefile example but found this gem
(quoting from that page):

"Code declared to be within the a.b.c package would be compiled to class
files in the a/b/c directory. This means that make's normal algorithm
for associating a binary file with its source fails."

Or did you mean this link?
http://www.makelinux.net/make3/make3-CHP-9-SECT-2

I am counting 200+ lines in this Makefile. It inefficiently invokes
javac on all Java sources and defines functions for things that ant can
do out of the box. As a consequence you have to search in different
locations to find out which packages go into which jar file. The same
is probably 15% of the lines as an ant file. Sorry, but that example is
no advertisement for using make to build Java projects.

> Chapter 9 is all about using make for build Java.
>
> As others said. If you are using an IDE with its own build
> system. It is better to have your own makefile to build
> your tree, independent of what the IDE has. This way, if
> you changed IDE, or move your tree somewhere else where
> this IDE is not available, you can still build your tree
> any where.

Modern IDE's usually have integration with ant and / or maven and will
happily generate appropriate build files.

Kind regards

robert

--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

[Rui Maciel]

Robert Klemme wrote:

> On 23.04.2012 06:57, Nasser M. Abbasi wrote:
>> I found that using one good tool for everything is better than
>> mixing things.
>
> Which, if followed religiously, will lead you into a situation where it
> can get really awkward to do things with tool A which would be extremely
> easy with tool B.

This isn't necessarily a problem, particularly if a person is already
familiar with tool A while being completely unaware that tool B even
existed.

Then there is a significant issue with being forced to learn an entirely new
tool just because there might be a single thing that it might be able to
handle in a simpler way, and then being forced to deal with a significant
list of things where the new tool fails to perform. Unfortunately, this
appears to be an undistinguishing feature of every automated build system
that has been released.

>> Also, gnumake can do so many more things than just build source
>> code. I use it to update my html files and pdf files from
>> Latex sources, and other such things.
>
> No wonder because make doesn't do *any* of these things. Make evaluates
> timestamps along dependencies (mostly between files) and invokes other
> programs that do all the work. GNU make additionally has an extremely
> large database of predefined rules, has functions and other capabilities.

There is nothing wrong with this. In fact, I see it as an extremelly
valuable feature. It's a pain in the neck to shoe-horn custom build rules
to an automated build system which was developed with them as an
afterthought.

>> As long as the idea that drives the tool is: Perform this action
>> to update these prerequisites that this target depends on, then better
>> to use one tool that does this better and for many other things, not
>> just .java files.
>
> Interestingly GNU make's large built in rule database does not contain
> anything related to compiling Java. How do you create your Makefiles in
> a way as to invoke javac only for those files which have changed -
> especially in light of the fact that one Java source file might create
> multiple .class files?

Maybe build-in rules aren't needed, considering Make's static pattern rules.

http://www.gnu.org/software/make/manual/make.html#Static-Pattern

<snip/>


Rui Maciel

[Rui Maciel]

David Lamb wrote:

> I've always used a combination of Emacs and make. Given your "single
> makefile" question, though, I suspect you may have more sophisticated
> needs than I do. Care to elaborate?

There is nothing sophisticated in my needs. The only reason I mentioned
makefiles is that I'm already familiar with them. I would prefer to develop
a skill which I already have than being forced to start from scratch by
being forced to use another tool.


Rui Maciel

[Rui Maciel]

Daniel Pitts wrote:

> Why not use an IDE though? They provide so much!

They also tend to be inferior in a considerable number of aspects,
particularly when compared with the features provided by some text editors.
Between being forced to stick with an IDE and managing the build process by
hand, the latter option sounds a lot better.


Rui Maciel

[markspace]

On 4/23/2012 3:15 PM, Rui Maciel wrote:
>
> Maybe build-in rules aren't needed, considering Make's static pattern rules.
>
> http://www.gnu.org/software/make/manual/make.html#Static-Pattern
>

That's a good find, and I appreciate you pointing it out to this list.
It's actually been several years since I've dealt with make's build
rules in any way, and a small refresher wouldn't be bad for me.

However, in the Java world, ant is the standard build program. (Or
maven; however I haven't got into maven yet.) There's no way you can
avoid ant. Any project that exists in Java, any deliverable you get
from an outside contractor or firm, will invariably use ant. It is
simply "the standard."

So I'd recommend you learn to use it. First, it avoids fumbling around
making your own static rules, and second you will have to learn it
eventually, regardless. So it might as well be on your own terms, and
on your own schedule.

I found ant's use of XML off-putting at first as well, but it becomes
easier to deal with, and more natural to write, after you've hand
written a couple of basic project definitions. Just go for it, and
don't sweat the new stuff you'll learn.

[markspace]

Modern IDEs are far superior to any text editor. 10 years ago I was a
vim (actually just vi) fan. No longer. The features provided by modern
IDEs are leaps and bounds beyond what any text editor provides.

If you can show me a text editor that is superior in any significant
regard to my IDE, I'd like to see what those features are, and know
which editor provides them. Productivity is important to me, so if
there's a productivity tool out there that I'm missing, I'd like to know.

(And I'd like actual objective features, please. If this degenerates
into trolling editor wars... well, you'll know when I start ignoring
your posts. "Don't feed the trolls.")

[Patricia Shanahan]

Same here.

I have absolutely no nostalgia for the way I started programming, coding
sheets and punch cards, so I have always been quite open to changing how
I edit code.

Currently, I use Eclipse. I use Eclipse's refactoring capabilities a
lot, not just during formal refactoring passes but also while I'm
writing new code.

However, if there is a significantly better way of editing Java code,
I'd like to know about it.

Patricia

[Lew]

Rui Maciel wrote:

> Robert Klemme wrote:
>
>> Nasser M. Abbasi wrote:
>>> I found that using one good tool for everything is better than
>>> mixing things.
>>
>> Which, if followed religiously, will lead you into a situation where it
>> can get really awkward to do things with tool A which would be extremely
>> easy with tool B.
>
> This isn't necessarily a problem, particularly if a person is already
> familiar with tool A while being completely unaware that tool B even
> existed.

You cannot make claim to being a Java programmer if you've never heard of Ant.

> Then there is a significant issue with being forced to learn an entirely new
> tool just because there might be a single thing that it might be able to
> handle in a simpler way, and then being forced to deal with a significant
> list of things where the new tool fails to perform. Unfortunately, this

Not Ant's problem.

> appears to be an undistinguishing feature of every automated build system
> that has been released.

Not Ant. Not that Ant is perfect, but it works as advertised.

You're full of fine generalities that simply do not apply to the Ant vs. make "debate".

>>> Also, gnumake can do so many more things than just build source
>>> code. I use it to update my html files and pdf files from
> >> Latex sources, and other such things.
>>
>> No wonder because make doesn't do *any* of these things. Make evaluates
>> timestamps along dependencies (mostly between files) and invokes other
>> programs that do all the work. GNU make additionally has an extremely
>> large database of predefined rules, has functions and other capabilities.
>
> There is nothing wrong with this. In fact, I see it as an extremelly
> valuable feature. It's a pain in the neck to shoe-horn custom build rules
> to an automated build system which was developed with them as an
> afterthought.

Also a benefit of Ant. Ant is extensible, unlike make. You can write new targets for it in Java.

>>> As long as the idea that drives the tool is: Perform this action
>>> to update these prerequisites that this target depends on, then better
>>> to use one tool that does this better and for many other things, not
>>> just .java files.

Not really. For one thing, Ant works better than make for Java, not the other way around. For another, Ant works on things besides Java. Come to think of it, your argument favors Ant over make.

>> Interestingly GNU make's large built in rule database does not contain
>> anything related to compiling Java. How do you create your Makefiles in
>> a way as to invoke javac only for those files which have changed -
>> especially in light of the fact that one Java source file might create
>> multiple .class files?
>

> Maybe build-in rules aren't needed, considering Make's [sic] static pattern rules.

Or considering that Ant is better and more standard for the purpose.

> http://www.gnu.org/software/make/manual/make.html#Static-Pattern

--
Lew

[Lew]

Rui Maciel wrote:
> I would prefer to develop
> a skill which I already have than being forced to start from scratch by
> being forced to use another tool.

The sound of the career death knells tolling.

--
Lew

[Lew]

Baloney. Love the vague statements, "tend to be inferior" without specifics or statistics. Classic Troll-speak.

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

Duck season!
Wabbit season!
Duck season!
Wabbit season!
Wabbit season!
Duck season!
BLAM!

--
Lew

[Arved Sandstrom]

On 12-04-23 07:44 PM, markspace wrote:
> On 4/23/2012 3:15 PM, Rui Maciel wrote:
>>
>> Maybe build-in rules aren't needed, considering Make's static pattern
>> rules.
>>
>> http://www.gnu.org/software/make/manual/make.html#Static-Pattern
>>
>
>
> That's a good find, and I appreciate you pointing it out to this list.
> It's actually been several years since I've dealt with make's build
> rules in any way, and a small refresher wouldn't be bad for me.
>
> However, in the Java world, ant is the standard build program. (Or
> maven; however I haven't got into maven yet.) There's no way you can
> avoid ant. Any project that exists in Java, any deliverable you get
> from an outside contractor or firm, will invariably use ant. It is
> simply "the standard."
>

[ SNIP ]

That's the main argument. It's the best argument. Proposing the use of
"make" in a typical Java shop will elicit the same reaction as if you
proposed the use of Ant to Haskell developers. "make" is a non-standard
tool in Java development, whereas Java IDE build systems, Ant and Maven
_are_ standard. I note the Java IDE build systems separately, because a
lot of developers don't use Ant or Maven, they just produce JARs or WARs
or EARs with their IDE.

This argument implies that it doesn't even really matter how many
problems Ant addressed viz "make" for Java builds, or how successfully
it addressed all of them, or even what extra cruft and complexity that
Ant itself now has. All that matters in 2012 is that Ant is a major
build standard for Java, and "make" isn't.

AHS
--
A fly was very close to being called a "land," cause that's what they do
half the time.
-- Mitch Hedberg

[Arne Vajhøj]

Yes, but you also need a tool that work well with Java.

Make does not.

Arne

[Arne Vajhøj]

Given that with mentioning any specific IDE's/editors then
an editor is a subset of an IDE, then that does not make
much sense..

Arne

[Arved Sandstrom]

On 12-04-23 07:50 PM, markspace wrote:
> On 4/23/2012 3:38 PM, Rui Maciel wrote:
>> Daniel Pitts wrote:
>>
>>> Why not use an IDE though? They provide so much!
>>
>> They also tend to be inferior in a considerable number of aspects,
>> particularly when compared with the features provided by some text
>> editors.
>> Between being forced to stick with an IDE and managing the build
>> process by
>> hand, the latter option sounds a lot better.
>
>
> Modern IDEs are far superior to any text editor. 10 years ago I was a
> vim (actually just vi) fan. No longer. The features provided by modern
> IDEs are leaps and bounds beyond what any text editor provides.

I agree. For Java I'll use Eclipse or NetBeans or IDEA. For C++ it's
Eclipse or Code::Blocks or VS. For C# it's VS or MonoDevelop. For
Haskell it's Leksah. For Scala it's Eclipse (well, Scala IDE) and maybe
soon NetBeans. For XML I prefer XMLMind XML Editor. Lazarus for Pascal.
Etc etc.

I actually write Clojure using VIM because it has good "GNU screen"
integration with consoles for REPLs. That's maybe the only holdout.

Some languages barely need an IDE, and may not have one really. J is
like that, you can write an entire complex program in a few dozen lines
so who needs an IDE? :-)

> If you can show me a text editor that is superior in any significant
> regard to my IDE, I'd like to see what those features are, and know
> which editor provides them. Productivity is important to me, so if
> there's a productivity tool out there that I'm missing, I'd like to know.
>
> (And I'd like actual objective features, please. If this degenerates
> into trolling editor wars... well, you'll know when I start ignoring
> your posts. "Don't feed the trolls.")

I'm fond of TextWrangler on Mac OS X, Notepad++ on Windows, and Sublime
Text 2 on basically everything (:-)). I use them in the one situation
where they are superior to an IDE, which is that I don't have to launch
an IDE. In a nutshell. A lot of files have nothing whatsoever to do with
a "project", for example. In other cases an IDE may expose parts of
server configuration but I want to edit the raw text, or get at parts
that aren't exposed.

That's about the only objective feature I can think of, that IDEs are
not meant for editing every file you've got.

[Robert Klemme]

On 24.04.2012 00:15, Rui Maciel wrote:
> Robert Klemme wrote:
>
>> On 23.04.2012 06:57, Nasser M. Abbasi wrote:
>>> I found that using one good tool for everything is better than
>>> mixing things.
>>
>> Which, if followed religiously, will lead you into a situation where it
>> can get really awkward to do things with tool A which would be extremely
>> easy with tool B.
>
> This isn't necessarily a problem, particularly if a person is already
> familiar with tool A while being completely unaware that tool B even
> existed.

Whoever claims he is Java developer AND unaware of ant cannot be a
professional. Also: sticking with a known strategy for too long instead
of knowing when to check other approaches is not a winning strategy.

>>> Also, gnumake can do so many more things than just build source
>>> code. I use it to update my html files and pdf files from
>>> Latex sources, and other such things.
>>
>> No wonder because make doesn't do *any* of these things. Make evaluates
>> timestamps along dependencies (mostly between files) and invokes other
>> programs that do all the work. GNU make additionally has an extremely
>> large database of predefined rules, has functions and other capabilities.
>
> There is nothing wrong with this. In fact, I see it as an extremelly
> valuable feature. It's a pain in the neck to shoe-horn custom build rules
> to an automated build system which was developed with them as an
> afterthought.

But there is something wrong with claiming "gnumake can do so many more
things than just build source code" - because it does not even compile
source code.

> Maybe build-in rules aren't needed, considering Make's static pattern rules.
>
> http://www.gnu.org/software/make/manual/make.html#Static-Pattern

Maybe or really? Please provide a proper static pattern rule which does
a similar job as ant does. As far as I can see still get one javac
invocation per .java file. This is hugely less efficient than what ant
does.

[Rui Maciel]

Arne Vajhøj wrote:

> Given that with mentioning any specific IDE's/editors then
> an editor is a subset of an IDE, then that does not make
> much sense..

It can only make no sense if you believe that any statement regarding how a
particular text editor compares to the text editor made available by a
specific IDE is something which can be expressed objectively in absolute
terms. It isn't. Taste and personal preferences are, well, personal.
These are subjective opinions, which each of us holds, that reflect nothing
more than our personal tastes, preferences and even habits.

So, unless we believe it is a good idea to waste time discussing how a
particular text editor is better or worse than any other text editor,
mentioning specific text editors, and how someone uses them, is perfectly
irrelevant, and we would only focus on that irrelevant detail if we had
missed the point.


Rui Maciel

[Rui Maciel]

Lew wrote:

> Baloney. Love the vague statements, "tend to be inferior" without
> specifics or statistics. Classic Troll-speak.

Noticed that you, in the same paragraph, assert that no text editor is
superior to an IDE, complain about the absense of "specifics or statistics",
and then proceed with throwing troll accusations and references to any
hypothetical editor war.

Meanwhile, the post you've replied to doesn't mention any of that, and it
does so due to a simple fact that you've missed: this is not, nor it ever
was supposed to be, an editor war. Everyone uses the tools they choose to
use, and if everyone is happy with their choice then all is well.
Criticising others for using a different tool than the one they chose is a
complete waste of time. I didn't made that mistake. So, I wonder why you
chose to make it.

To make things as clear as possible for you, this discussion is never, nor
it will be, about which editor is better than some other editor. It is
about setting up an automatic build process that doesn't rely on a IDE. If
you wish to waste your time going off on a tangent about any given IDE fares
against a text editor then go for it. I can tell you I won't make that
mistake, nor any reasonable person.


Rui Maciel

[Rui Maciel]

wrote:

> Modern IDEs are far superior to any text editor. 10 years ago I was a
> vim (actually just vi) fan. No longer. The features provided by modern
> IDEs are leaps and bounds beyond what any text editor provides.
>
> If you can show me a text editor that is superior in any significant
> regard to my IDE

<snip/>

If you read what I wrote, I said that, in some aspects (which, to me, there
are a considerable number), some text editors are better than IDEs. I did
not said that there was any editor which "is superior in any significant
regard to" any IDE. IDEs are purpose-built for the task of developing
software, which also integrate a significant number of features which are
fundamental to the task of developing software. Therefore, it would be
really odd if every piece of software which was developed with the sole
purpose of helping developers write their software ended up doing the exact
opposite in every conceivable aspect related to that job.

Nonetheless, we should understand that there is no such thing as a "one size
fits all" solution. No IDE is the best tool for every conceivable scenario
ever faced by every programmer that ever lived. One way to prove this is by
pointing out the fact that there is more than a single IDE out there, and
even in this day there are fools who waste their time with IDE flame wars
complaining how their IDE is better than someone else's, and how those who
don't use a specific IDE are somehow idiots and trolls.

Now, just to point out how a "modern IDE" is inadequate in some
circumstances, I can point you to those cases where a programmer, for some
reason, happens to need to work on some project with one of those flimsy
netbook computers, the ones with tiny monitors and limited disk space.
Running an IDE on one of those systems is an experience that only a
masochist can enjoy, and even then he would have trouble doing any work.
Meanwhile, it isn't hard to find a bunch of text editors that work perfectly
well with those limitations.


Rui Maciel

[Rui Maciel]

Robert Klemme wrote:

> On 24.04.2012 00:15, Rui Maciel wrote:
>> Robert Klemme wrote:
>>
>>> On 23.04.2012 06:57, Nasser M. Abbasi wrote:
>>>> I found that using one good tool for everything is better than
>>>> mixing things.
>>>
>>> Which, if followed religiously, will lead you into a situation where it
>>> can get really awkward to do things with tool A which would be extremely
>>> easy with tool B.
>>
>> This isn't necessarily a problem, particularly if a person is already
>> familiar with tool A while being completely unaware that tool B even
>> existed.
>
> Whoever claims he is Java developer AND unaware of ant cannot be a
> professional.

It was a hyperbole.

And surely you are aware that a considerable number of people who spend a
portion of their time writing Java code don't exactly make that their
profession.

> Also: sticking with a known strategy for too long instead
> of knowing when to check other approaches is not a winning strategy.

It isn't. But wasting time checking each and every alternative that some
bloke on the internet said was the winning strategy is also not a winning
strategy.

>> There is nothing wrong with this. In fact, I see it as an extremelly
>> valuable feature. It's a pain in the neck to shoe-horn custom build
>> rules to an automated build system which was developed with them as an
>> afterthought.
>
> But there is something wrong with claiming "gnumake can do so many more
> things than just build source code" - because it does not even compile
> source code.

It isn't expected to. That's the job for the compiler, which is called by
the automated build tool.

If I'm not mistaken, this is also what ant does. Someone correct me if I'm
wrong.
http://ant.apache.org/manual/Tasks/javac.html

>> Maybe build-in rules aren't needed, considering Make's static pattern
>> rules.
>>
>> http://www.gnu.org/software/make/manual/make.html#Static-Pattern
>
> Maybe or really? Please provide a proper static pattern rule which does
> a similar job as ant does. As far as I can see still get one javac
> invocation per .java file. This is hugely less efficient than what ant
> does.

As you can imagine due to the fact that I've started this thread, I never
managed to do this nor know how to pull this off. The reason I said that
maybe built-in rules aren't needed to build java programs with the make tool
is the fact that it is quite possible to build software written in a number
of programming languagea without relying on built-in rules.

Nevertheless, after a quick google, I stumbled on a tutorial on how to
"write and use makefiles to build java applications". It doesn't rely on
static pattern rules, and instead uses suffix rules. I don't know how well
this works, but you are free to give it a try and see if it doesn't work.

On a side note, I don't believe that the point is to prove that the make
tool can be made to work better than alternatives such as ant, but only that
it actually works.


Rui Maciel

[Rui Maciel]

Rui Maciel wrote:

> Nevertheless, after a quick google, I stumbled on a tutorial on how to
> "write and use makefiles to build java applications".

I forgot the link to the tutorial:

http://www.cs.swarthmore.edu/~newhall/unixhelp/javamakefiles.html


Rui Maciel

[Rui Maciel]

Lew wrote:

> Rui Maciel wrote:
>> Robert Klemme wrote:
>>
>>> Nasser M. Abbasi wrote:
>>>> I found that using one good tool for everything is better than
>>>> mixing things.
>>>
>>> Which, if followed religiously, will lead you into a situation where it
>>> can get really awkward to do things with tool A which would be extremely
>>> easy with tool B.
>>
>> This isn't necessarily a problem, particularly if a person is already
>> familiar with tool A while being completely unaware that tool B even
>> existed.
>
> You cannot make claim to being a Java programmer if you've never heard of
> Ant.

Read up on "hyperbole".

>> Then there is a significant issue with being forced to learn an entirely
>> new tool just because there might be a single thing that it might be able
>> to handle in a simpler way, and then being forced to deal with a
>> significant
>> list of things where the new tool fails to perform. Unfortunately, this
>
> Not Ant's problem.

It isn't supposed to be ant's problem. Yet, it doesn't make it an
acceptable alternative for every conceivable scenario, let alone the ideal
solution. And that's precisely the point.

>> appears to be an undistinguishing feature of every automated build system
>> that has been released.
>
> Not Ant. Not that Ant is perfect, but it works as advertised.
>
> You're full of fine generalities that simply do not apply to the Ant vs.
> make "debate".

Your own admition that ant isn't perfect already demonstrates that we aren't
dealing with mere "fine generalities", but with a matter of fact. Just
because ant may be "the devil you know" it doesn't mean that it is the
perfect solution for everyone's problems, particularly those of us who
happen to know other "devils" a bit better than they know ant.

>>>> Also, gnumake can do so many more things than just build source
>>>> code. I use it to update my html files and pdf files from
>> >> Latex sources, and other such things.
>>>
>>> No wonder because make doesn't do *any* of these things. Make evaluates
>>> timestamps along dependencies (mostly between files) and invokes other
>>> programs that do all the work. GNU make additionally has an extremely
>>> large database of predefined rules, has functions and other
>>> capabilities.
>>
>> There is nothing wrong with this. In fact, I see it as an extremelly
>> valuable feature. It's a pain in the neck to shoe-horn custom build
>> rules to an automated build system which was developed with them as an
>> afterthought.
>
> Also a benefit of Ant. Ant is extensible, unlike make. You can write new
> targets for it in Java.

I don't understand. Are you saying that it it impossible to add new targets
to a makefile?

>>>> As long as the idea that drives the tool is: Perform this action
>>>> to update these prerequisites that this target depends on, then better
>>>> to use one tool that does this better and for many other things, not
>>>> just .java files.
>
> Not really. For one thing, Ant works better than make for Java, not the
> other way around. For another, Ant works on things besides Java. Come to
> think of it, your argument favors Ant over make.

You missed the point. No one is claiming that ant is worse than make for
Java projects, only that make can be used to build Java projects.

>>> Interestingly GNU make's large built in rule database does not contain
>>> anything related to compiling Java. How do you create your Makefiles in
>>> a way as to invoke javac only for those files which have changed -
>>> especially in light of the fact that one Java source file might create
>>> multiple .class files?
>>
>> Maybe build-in rules aren't needed, considering Make's [sic] static
>> pattern rules.
>
> Or considering that Ant is better and more standard for the purpose.

I don't believe it is reasonable to declare that make isn't standard for
managing build processes.

But again, the point is not that make, or any other tool, is supposed to be
better or worse than ant at building Java projects; it's only if, and how,
make can also be used to build Java projects. And if make can be used to
build Java projects then, for some people, and in some particular
situations, no matter how superior ant might be, using make may still be the
best option available for that particular task under those particular
circumstances. And I don't see how this fact can rile you that much, or
anyone.


Rui Maciel

[Rui Maciel]

You are assuming that everyone's career depends on how well they are able to
manually set up an ant build script to build a Java project. That's a bad
assumption. I would bet that a significant number of people who write Java
code for a living never bothered to manually tweak an ant build script, let
alone took the time to learn that tool.


Rui Maciel

[Arved Sandstrom]

Like I alluded to in another post in this thread, building with IDE
build systems is a common method along with Ant and Maven. I've worked
at any number of sites where a JAR/WAR/EAR built by an IDE is a
deliverable from a developer to a deployer. There's nothing evil or
shoddy about that methodology, actually...if you don't trust your IDE
build system to produce a correct artifact then why are you using the IDE?

I've also worked at quite a few client sites where developers doing
_development_ don't bother with Ant or Maven, but for formal testing and
production deployments then a CI system with Ant scripts is used. This
defeats the purpose of CI in the first place (in such a shop the CI is
only pointed at source control branches that the developers don't
directly commit to, and the CI build is manually triggered), but it's
not uncommon.

In both of these scenarios there are very few people who write or edit
Ant build scripts, true. But I've also noticed that the majority of Java
developers in both scenarios are aware of Ant. Over the course of time,
as maintenance needs to be done on Ant build scripts, or new ones need
to be written, or a build/deployment scenario calls for something more
than an IDE build, a lot of these developers do end up doing _some_ work
with Ant. Sure, it's infrequent and maybe trivial, but it's an accepted
tool.

A decent Java developer has heard of Ant and has some idea of how it
works. Maybe they've done some simple experiments with it. Even if
they've never had to write an Ant build script on the job they know that
they may be called on at any time to do it.

I'll tell you what no Java developer's career depends on: being able to
write a makefile to build a Java project.

[markspace]

On 4/24/2012 5:53 AM, Rui Maciel wrote:
> wrote:
>
>> Modern IDEs are far superior to any text editor. 10 years ago I
>> was a vim (actually just vi) fan. No longer. The features
>> provided by modern IDEs are leaps and bounds beyond what any text
>> editor provides.
>>
>> If you can show me a text editor that is superior in any
>> significant regard to my IDE
> <snip/>
>
> If you read what I wrote, I said that, in some aspects (which, to
> me, there are a considerable number), some text editors are better
> than IDEs. I did

What you wrote was, with the full context:

On 4/23/2012 3:38 PM, Rui Maciel wrote:
> Daniel Pitts wrote:
>
>> Why not use an IDE though? They provide so much!
>
> They also tend to be inferior in a considerable number of aspects,
> particularly when compared with the features provided by some text
> editors. Between being forced to stick with an IDE and managing the
> build process by hand, the latter option sounds a lot better.

"A considerable number of aspects." Which is greatly different that
"some," according to my grade school English teacher.

> Nonetheless, we should understand that there is no such thing as a
> "one size fits all" solution. No IDE is the best tool for every
> conceivable scenario ever faced by every programmer that ever lived.

Which was going to be my next point. I still use vim, grep, find,
strings, zip/jar as well as any other tool that happens to be the best
for the job at the time. I've got no problem using a different editor
for a job if it happens to provide some cool feature that I need. I'm
happy with my IDE is most respects, but sometimes I do use a different
tool if it does something my current tool won't.

> Now, just to point out how a "modern IDE" is inadequate in some
> circumstances, I can point you to those cases where a programmer,
> for some reason, happens to need to work on some project with one of
> those flimsy netbook computers, the ones with tiny monitors and
> limited disk space. Running an IDE on one of those systems is an
> experience that only a masochist can enjoy, and even then he would
> have trouble doing any work. Meanwhile, it isn't hard to find a
> bunch of text editors that work perfectly well with those
> limitations.

Weak sauce. I do develop on a flimsy notebook with a small screen
exclusively -- a Fujitsu Lifebook. And with a couple of mouse clicks my
IDE will expand to full screen (and back, with a couple of more). If I
bother to use the actual options menu, I can increase the font size to
anything I like. (I just increased it to 14 point, just to check it. I
can read my text from across the room now!)

[markspace]

On 4/24/2012 5:53 AM, Rui Maciel wrote:

> wrote:
>
>> Modern IDEs are far superior to any text editor. 10 years ago I
>> was a vim (actually just vi) fan. No longer. The features
>> provided by modern IDEs are leaps and bounds beyond what any text
>> editor provides.
>>
>> If you can show me a text editor that is superior in any
>> significant regard to my IDE
> <snip/>
>
> If you read what I wrote, I said that, in some aspects (which, to
> me, there are a considerable number), some text editors are better
> than IDEs. I did

What you wrote was, with the full context:

On 4/23/2012 3:38 PM, Rui Maciel wrote:
> Daniel Pitts wrote:
>
>> Why not use an IDE though? They provide so much!
>
> They also tend to be inferior in a considerable number of aspects,
> particularly when compared with the features provided by some text
> editors. Between being forced to stick with an IDE and managing the
> build process by hand, the latter option sounds a lot better.

"A considerable number of aspects." Which is greatly different that
"some," according to my grade school English teacher.

> Nonetheless, we should understand that there is no such thing as a
> "one size fits all" solution. No IDE is the best tool for every
> conceivable scenario ever faced by every programmer that ever lived.

Which was going to be my next point. I still use vim, grep, find,
strings, zip/jar as well as any other tool that happens to be the best
for the job at the time. I've got no problem using a different editor
for a job if it happens to provide some cool feature that I need. I'm
happy with my IDE is most respects, but sometimes I do use a different
tool if it does something my current tool won't.

> Now, just to point out how a "modern IDE" is inadequate in some
> circumstances, I can point you to those cases where a programmer,
> for some reason, happens to need to work on some project with one of
> those flimsy netbook computers, the ones with tiny monitors and
> limited disk space. Running an IDE on one of those systems is an
> experience that only a masochist can enjoy, and even then he would
> have trouble doing any work. Meanwhile, it isn't hard to find a
> bunch of text editors that work perfectly well with those
> limitations.

[Gene Wirchenko]

On Tue, 24 Apr 2012 11:24:14 -0300, Arved Sandstrom
<asandstr...@eastlink.ca> wrote:

[snip]

>I'll tell you what no Java developer's career depends on: being able to
>write a makefile to build a Java project.

Does someone's career depend on being able to use Ant? If it
does, then why can he not simply pick it up when he needs it?

I prefer to learn to use tools that will be of use to me in
preference to those that only might. There is so much software out
there that I have to budget my learning time to items which will give
me a return.

Sincerely,

Gene Wirchenko

[Gene Wirchenko]

On Mon, 23 Apr 2012 23:38:47 +0100, Rui Maciel <rui.m...@gmail.com>
wrote:

>Daniel Pitts wrote:
>
>> Why not use an IDE though? They provide so much!
>
>They also tend to be inferior in a considerable number of aspects,
>particularly when compared with the features provided by some text editors.

I am using Dreamweaver for Web development. Its editor forces
tabs into files and does not have a current column indicator. Both
lacks are antipathetic to how I code. When I know enough, I am very
likely to switch to something else.

>Between being forced to stick with an IDE and managing the build process by
>hand, the latter option sounds a lot better.

I like the idea of an automated build, but I would want the
option of handling it myself. The problem with too much of this
automation is that one has to really dig to find out how to do it
without the IDE.

Sincerely,

Gene Wirchenko

[Gene Wirchenko]

On Tue, 24 Apr 2012 08:12:00 -0700, markspace <-@.> wrote:

[snip]

>"A considerable number of aspects." Which is greatly different that
>"some," according to my grade school English teacher.

I hope you fired him.

How many aspects? Say, 32. Is that a considerable number of
aspects? Yes. Does 32 qualify as some? Yes.

"A considerable number of aspects" is a subset of "some". Since
one includes the other, they are not greatly different.

Your statement is like claiming that white dogs and dogs are
greatly different.

[snip]

Sincerely,

Gene Wirchenko

[Gene Wirchenko]

On Mon, 23 Apr 2012 16:46:46 -0700 (PDT), Lew <lewb...@gmail.com>
wrote:

>On Monday, April 23, 2012 3:38:47 PM UTC-7, Rui Maciel wrote:
>> Daniel Pitts wrote:
>>
>> > Why not use an IDE though? They provide so much!
>>
>> They also tend to be inferior in a considerable number of aspects,
>> particularly when compared with the features provided by some text editors.
>> Between being forced to stick with an IDE and managing the build process by
>> hand, the latter option sounds a lot better.
>
>Baloney. Love the vague statements, "tend to be inferior" without specifics or statistics. Classic Troll-speak.

Since an IDE is a combination of a number of things (editor,
compiler, debugger, what else) and since preferences vary so greatly,
a given user may well be able to select a better set of things that do
the job. "better" is by his standards. And you could do the same by
yours.

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

So which losing side are you on? (I think all sides lose when it
gets past editor *discussion*.)

[snip]

Sincerely,

Gene Wirchenko

[BGB]

On 4/23/2012 3:38 PM, Rui Maciel wrote:
> Daniel Pitts wrote:
>
>> Why not use an IDE though? They provide so much!
>
> They also tend to be inferior in a considerable number of aspects,
> particularly when compared with the features provided by some text editors.
> Between being forced to stick with an IDE and managing the build process by
> hand, the latter option sounds a lot better.
>

yeah, there are a few problems IMO with many IDEs:
trying to manage and automate too much of the process;
not being terribly flexible for allowing the developer to do what *they*
want regarding the build.

ultimately, it largely renders an IDE a glorified text editor and
debugging interface, with much more building-related tasks being handled
on the command-line.

sadly, this seems to be a common problem with many sorts of tools.

or such...

[Arved Sandstrom]

Does someone's career - let's say current job - *depend* on knowing Ant?
I doubt it, not in and of itself. But if I had someone working for me as
a Java developer, unless they were an absolute newbie I'd look askance
at them not knowing certain things by a certain point in their
professional development.

I have worked with intermediate Java developers - people who have used
basically nothing but Java in their entire career - who don't know Ant,
don't know Maven, don't know Ivy, don't know Hudson/Jenkins or any other
CI system, only know JUnit - sort of - out of all the available test
frameworks, aren't up to speed on any Java API except for the ones that
they've had to use for work. You then come to find out that they barely
know XML: no knowledge (or very deficient knowledge) of XSLT or XPath,
for example. You come to find out that they don't know Powershell on
Windows, bash or sh or ksh on UNIX, or even DOS-type batch files. They
have only superficial knowledge of regular expressions.

The list goes on and on, and I've worked with plenty of intermediate
(and some senior) developers who have a poor grasp of *everything* I
just listed. And more.

So is not knowing Ant a kiss of death for some Java developer's career?
Not by itself, probably not. But it's, in my experience, a strong
indicator that they've probably neglected whole swathes of stuff they
should be conversant with.

I have a great deal of tolerance for someone who has to learn something
unexpected. We all have to do that on occasion. I have considerably less
tolerance for an intermediate or senior developer who is _routinely_
having to "pick up" skills just when they need it. They're doing it on
company time and client time.

[Arved Sandstrom]

The funny thing is, it's not such a big deal to build, package and
deploy even complicated-looking projects to typical Java EE app servers
on the command line. The information - I find - is readily available.
It's a useful exercise to do this every so often - no Ant, no IDE,
nothing except command line - so that you have a good feel for what your
IDE is doing under the hood. This includes all configuration and
operation of the app server as well.

[BGB]

personally, I would be more happy with many IDEs (or, at least leaving
them in control of the "project" and "build process"), if the build
process were itself readily available and an editable part of the project.

after all, a person builds the GUI, they get code, and they can edit the
code if they need to.

how much control do they have over, say, which tools are run, or the
command-lines passed to the tools?...

not a whole lot.

if one is lucky, it is partly available in some arcane-looking set of
dialog boxes off in a menu somewhere, and in others, it is nowhere to be
found.


meanwhile, if manually building a project, it is fairly easy to add
custom tools or build-targets to the process (assuming the person knows
and understands the process), ...


now, why is it this way?...

OTOH, some fancier text editors, end up sort of resembling an IDE, but
generally without project-management features or integrated debugger or
profiler support (kind of a loss).


or such...

[Martin Gregorie]

On Tue, 24 Apr 2012 14:44:50 +0100, Rui Maciel wrote:

> It isn't supposed to be ant's problem. Yet, it doesn't make it an
> acceptable alternative for every conceivable scenario, let alone the
> ideal solution. And that's precisely the point.
>

Sure, but there scenarios where not knowing it is very definitely your
problem. Here's a fairly common one: you join a project team where the
project standards are enforced and they say Ant is the project build
tool, but you don't know it. You may be cut some slack while you get up
to speed on Ant but you may well find yourself out on your ear if you
insist on using something else, e.g. make. As AJS says, if the project is
about to hit a deadline your need to learn on the job will not make you
popular with the PM or other team members if your reduced productivity
while learning the tool causes a milestone to be missed.


--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |

[Lew]

Rui Maciel wrote:
> Robert Klemme wrote:
>> Rui Maciel wrote:
>>> Robert Klemme wrote:
>>>> Nasser M. Abbasi wrote:
>>>>> I found that using one good tool for everything is better than
>>>>> mixing things.
>>>>
>>>> Which, if followed religiously, will lead you into a situation where it
>>>> can get really awkward to do things with tool A which would be extremely
>>>> easy with tool B.
>>>
>>> This isn't necessarily a problem, particularly if a person is already
>>> familiar with tool A while being completely unaware that tool B even
>>> existed.
>>
>> Whoever claims he is Java developer AND unaware of ant cannot be a
>> professional.
>
> It was a hyperbole.

And we were supposed to know that how...?

I see no exaggeration in your comment at all.

> And surely you are aware that a considerable number of people who spend a
> portion of their time writing Java code don't exactly make that their
> profession.

Are you claiming that non-professionals should deliberately flout best practices, simply because they don't make a living at it?

The main point here, which you're ducking, is that no one can be a Java programmer, professional or otherwise, without having heard of Ant or being more than superficially aware of it. Your statement about being "unaware that tool B even existed" is utterly irrelevant to this issue.

> > Also: sticking with a known strategy for too long instead
> > of knowing when to check other approaches is not a winning strategy.
>
> It isn't. But wasting time checking each and every alternative that some
> bloke on the internet said was the winning strategy is also not a winning
> strategy.

This isn't a case of that, so why mention it?

>>> There is nothing wrong with this. In fact, I see it as an extremelly
>>> valuable feature. It's a pain in the neck to shoe-horn custom build
>>> rules to an automated build system which was developed with them as an
> >> afterthought.
> >
> > But there is something wrong with claiming "gnumake can do so many more
> > things than just build source code" - because it does not even compile
> > source code.
>
> It isn't expected to. That's the job for the compiler, which is called by
> the automated build tool.
>
> If I'm not mistaken, this is also what ant does. Someone correct me if I'm
> wrong.
> http://ant.apache.org/manual/Tasks/javac.html

Ant does all sorts of things superficially similar to make, but better when it comes to Java.

>>> Maybe build-in rules aren't needed, considering Make's static pattern
>>> rules.
>>>
>>> http://www.gnu.org/software/make/manual/make.html#Static-Pattern
>>
>> Maybe or really? Please provide a proper static pattern rule which does
>> a similar job as ant does. As far as I can see still get one javac
>> invocation per .java file. This is hugely less efficient than what ant
>> does.
>
> As you can imagine due to the fact that I've started this thread, I never
> managed to do this nor know how to pull this off. The reason I said that
> maybe built-in rules aren't needed to build java programs with the make tool
> is the fact that it is quite possible to build software written in a number
> of programming languagea without relying on built-in rules.
>
> Nevertheless, after a quick google, I stumbled on a tutorial on how to
> "write and use makefiles to build java applications". It doesn't rely on
> static pattern rules, and instead uses suffix rules. I don't know how well
> this works, but you are free to give it a try and see if it doesn't work.
>
> On a side note, I don't believe that the point is to prove that the make
> tool can be made to work better than alternatives such as ant, but only that
> it actually works.

It would have to be better to justify its use, since Ant is the standard. As it happens, make is worse for Java projects than make, so that's a huge strike against it.

Unwillingness to learn the standard tool (which really only takes about an hour or two to learn, BTW) is a pitiful and non-engineering reason to avoid using Ant.

--
Lew

[markspace]

On 4/24/2012 12:59 PM, BGB wrote:
>
> personally, I would be more happy with many IDEs (or, at least leaving
> them in control of the "project" and "build process"), if the build
> process were itself readily available and an editable part of the project.

Just FYI: NetBeans actually generates an ant build file and uses it
exclusively to build projects. Anytime you want to change the internals
of how NetBeans builds, just edit the build.xml file.

I'd recommend checking the project's Properties first, but if you don't
find what you need there, a little work with the build script will fix
things right up.

[Lew]

markspace wrote:
> BGB wrote:
> > personally, I would be more happy with many IDEs (or, at least leaving
> > them in control of the "project" and "build process"), if the build
> > process were itself readily available and an editable part of the project.
>
> Just FYI: NetBeans actually generates an ant build file and uses it
> exclusively to build projects. Anytime you want to change the internals
> of how NetBeans builds, just edit the build.xml file.

Uh-huh. Have you tried this yourself?

In the first place, you don't edit the build.xml but the ancillary build file that build.xml incorporates.

In the second place, the generated build script is a tour de force, but verbose and heavy. It is likely more than you'd hand-craft. I usually eschew the NetBeans build.xml as too IDE-specific, and create one from first principles. I recommend that practice.

> I'd recommend checking the project's Properties first, but if you don't
> find what you need there, a little work with the build script will fix
> things right up.

A "little" work indeed - seriously, have you tried this?

--
Lew

[BGB]

can't really claim to have used NetBeans.

mostly, I was writing from experience with Visual Studio and Eclipse,
which are not exactly all that friendly IME to a user-customizable build
process...

yes, there are some workarounds, but still...

[markspace]

On 4/24/2012 2:59 PM, Lew wrote:

> In the first place, you don't edit the build.xml but the ancillary
> build file that build.xml incorporates.
>

> A "little" work indeed - seriously, have you tried this?
>

I've added small changes to a NetBeans build file. I've never attempted
large or wholesale changes.

I just double checked, and it's the other way around: The main
build.xml file is the one you edit. It's empty, except for the project
header and an include of the generated targets (one line), and a really
long comment explaining the targets that NetBeans uses to build your
program.

The trick is to get the right dependency on the right target. I've
found that the -pre and -post targets should be ignored. Those never
seem to do anything useful. Just base your own stuff on the real
targets, and it all builds normally.

If you're doing large changes, I can see that it might be unworkable.
You're probably better off using the "free form" NetBeans project type,
and just managing the build file entirely yourself. But if you're
adding small bits to the existing paths or other configuration, or
you're adding small build targets, it's easy.

[Arne Vajhøj]

On 4/24/2012 7:36 AM, Rui Maciel wrote:
> Arne Vajhøj wrote:
>
>> Given that with mentioning any specific IDE's/editors then
>> an editor is a subset of an IDE, then that does not make
>> much sense..
>
> It can only make no sense if you believe that any statement regarding how a
> particular text editor compares to the text editor made available by a
> specific IDE is something which can be expressed objectively in absolute
> terms. It isn't. Taste and personal preferences are, well, personal.
> These are subjective opinions, which each of us holds, that reflect nothing
> more than our personal tastes, preferences and even habits.

????

There is certainly a strong element in personal preferences for
specific tools.

But that has absolutely no relevance.

You were not talking about specific tools but about IDE's and
text editors.

And you were talking about features provided not whether
you liked them or not.

> So, unless we believe it is a good idea to waste time discussing how a
> particular text editor is better or worse than any other text editor,
> mentioning specific text editors, and how someone uses them, is perfectly
> irrelevant, and we would only focus on that irrelevant detail if we had
> missed the point.

Well - you brought up the discussion about features provide by IDE's
and editors.

And we pointed out that you were wrong because editor+tools does
not have less features than editor.

And the rest is just your hopeless pathetic attempts to avoid
admitting your fault.

Arne

[Arne Vajhøj]

On 4/24/2012 12:13 PM, Gene Wirchenko wrote:
> On Mon, 23 Apr 2012 23:38:47 +0100, Rui Maciel<rui.m...@gmail.com>
> wrote:
>> Daniel Pitts wrote:
>>> Why not use an IDE though? They provide so much!
>>
>> They also tend to be inferior in a considerable number of aspects,
>> particularly when compared with the features provided by some text editors.
>
> I am using Dreamweaver for Web development. Its editor forces
> tabs into files and does not have a current column indicator. Both
> lacks are antipathetic to how I code. When I know enough, I am very
> likely to switch to something else.

I would be tempted to consider Dreamweaver a design tool and not an IDE.

>> Between being forced to stick with an IDE and managing the build process by
>> hand, the latter option sounds a lot better.
>
> I like the idea of an automated build, but I would want the
> option of handling it myself. The problem with too much of this
> automation is that one has to really dig to find out how to do it
> without the IDE.

I can not think of one widely used IDE that does not work
with command line build tools (typical ant for Java IDE's).

Arne

[Arne Vajhøj]

Almost no good Java developers.

Good Java developers like good developers in any language like
to learn and broaden their skills.

The "I don't want to do build scripts - I will leave that to the
integration engineers" developers will be considered second class
developers.

Arne

[Rui Maciel]

Lew wrote:

> Rui Maciel wrote:
>> Robert Klemme wrote:
>>> Rui Maciel wrote:
>>>> Robert Klemme wrote:
>>>>> Nasser M. Abbasi wrote:
>>>>>> I found that using one good tool for everything is better than
>>>>>> mixing things.
>>>>>
>>>>> Which, if followed religiously, will lead you into a situation where
>>>>> it can get really awkward to do things with tool A which would be
>>>>> extremely easy with tool B.
>>>>
>>>> This isn't necessarily a problem, particularly if a person is already
>>>> familiar with tool A while being completely unaware that tool B even
>>>> existed.
>>>
>>> Whoever claims he is Java developer AND unaware of ant cannot be a
>>> professional.
>>
>> It was a hyperbole.
>
> And we were supposed to know that how...?
>
> I see no exaggeration in your comment at all.

You already shown that you have a bit of a problem in basing your arguments
and criticism on unfounded assumptions. In this case, you even choosed to
ignore that the example I gave was between "tool A" and "tool B", not make
and ant, which certainly no one else had any trouble understanding that it
was purely figurative.

>> And surely you are aware that a considerable number of people who spend a
>> portion of their time writing Java code don't exactly make that their
>> profession.
>
> Are you claiming that non-professionals should deliberately flout best
> practices, simply because they don't make a living at it?

I made no such claim. I would appreciate it if you stopped trying to pin on
me these wild claims you are making up as you go along.

> The main point here, which you're ducking, is that no one can be a Java
> programmer, professional or otherwise, without having heard of Ant or
> being more than superficially aware of it. Your statement about being
> "unaware that tool B even existed" is utterly irrelevant to this issue.

This is not nor it ever was the main point. Nor a side note, even. You
knack for making wild assumptions led you to make this stuff up. If you
have any doubt then simply point out exactly where anyone besides yourself
ever mentioned anything remotely similar to that.

>> > Also: sticking with a known strategy for too long instead
>> > of knowing when to check other approaches is not a winning strategy.
>>
>> It isn't. But wasting time checking each and every alternative that some
>> bloke on the internet said was the winning strategy is also not a winning
>> strategy.
>
> This isn't a case of that, so why mention it?

Frankly, that's what every single one of those blokes on the internet says.

As a warning, I should inform you that this was also a hyperbole.

> It would have to be better to justify its use, since Ant is the standard.

By your reasoning, you should be using make as it is actually the standard
in the real sense of the word. ISO standard and all. Instead, it appears
you are hell-bent on criticising make.

> As it happens, make is worse for Java projects than make, so that's a huge
> strike against it.
>
> Unwillingness to learn the standard tool (which really only takes about an
> hour or two to learn, BTW) is a pitiful and non-engineering reason to
> avoid using Ant.

Again with your unfounded assumptions and baseless accusations. Can you
point out exactly where anyone stated that they refused to learn how to use
ant or even maven? You can't, because no one, besides you with your wild
imagination, ever said it.

So, you either are a functional illiterate or a troll. Either way, you are
not helpful. So, if you don't have anything helpful to add then go waste
your time and your wild imagination elsewhere.

Rui Maciel

[Arne Vajhøj]

It is almost 100% sure that a developer will need to work with
Ant within a reasonable time frame (like 5 years).

But it is only 1/3 of the problem that is the actual lack
of Ant skills - the 2/3 of the problem is the attitude.

Arne

[Arne Vajhøj]

On 4/24/2012 9:20 AM, Rui Maciel wrote:
> Robert Klemme wrote:
>

>> On 24.04.2012 00:15, Rui Maciel wrote:
>>> Robert Klemme wrote:
>>>
>>>> On 23.04.2012 06:57, Nasser M. Abbasi wrote:
>>>>> I found that using one good tool for everything is better than
>>>>> mixing things.
>>>>
>>>> Which, if followed religiously, will lead you into a situation where it
>>>> can get really awkward to do things with tool A which would be extremely
>>>> easy with tool B.
>>>
>>> This isn't necessarily a problem, particularly if a person is already
>>> familiar with tool A while being completely unaware that tool B even
>>> existed.
>>
>> Whoever claims he is Java developer AND unaware of ant cannot be a
>> professional.
>
> It was a hyperbole.
>

> And surely you are aware that a considerable number of people who spend a
> portion of their time writing Java code don't exactly make that their
> profession.

That is true.

But best practices for Java programming is what works for professionals
not what hobby programmers consider fun.

>> Also: sticking with a known strategy for too long instead
>> of knowing when to check other approaches is not a winning strategy.
>
> It isn't. But wasting time checking each and every alternative that some
> bloke on the internet said was the winning strategy is also not a winning
> strategy.

Not particular relevant.

We are discussing whether to use one of the tools that 95-99% of
all Java developers use.

We are not discussing every alternative under the some.

Learning from others is a winning strategy.

> Nevertheless, after a quick google, I stumbled on a tutorial on how to
> "write and use makefiles to build java applications". It doesn't rely on
> static pattern rules, and instead uses suffix rules. I don't know how well
> this works, but you are free to give it a try and see if it doesn't work.
>
> On a side note, I don't believe that the point is to prove that the make
> tool can be made to work better than alternatives such as ant, but only that
> it actually works.

All experience shows that make and Java is not a good mix.

Use the tools designed for the task.

Arne

[Rui Maciel]

wrote:

> That's a good find, and I appreciate you pointing it out to this list.
> It's actually been several years since I've dealt with make's build
> rules in any way, and a small refresher wouldn't be bad for me.

Thanks. I'm glad I could help. I was only aware of this because a while ago
I happened to stumble on it while reading up on suffix rules. It appears
that nowadays there isn't a lot of people who write their own makefiles,
instead relying on tools to generate scripts for tools that generate scripts
for tools that... So, this sort of stuff tends to be left in obscurity.


> However, in the Java world, ant is the standard build program. (Or
> maven; however I haven't got into maven yet.) There's no way you can
> avoid ant. Any project that exists in Java, any deliverable you get
> from an outside contractor or firm, will invariably use ant. It is
> simply "the standard."
>
> So I'd recommend you learn to use it. First, it avoids fumbling around
> making your own static rules, and second you will have to learn it
> eventually, regardless. So it might as well be on your own terms, and
> on your own schedule.

I see what you mean.


> I found ant's use of XML off-putting at first as well, but it becomes
> easier to deal with, and more natural to write, after you've hand
> written a couple of basic project definitions. Just go for it, and
> don't sweat the new stuff you'll learn.

The XML bit was really off-putting, mainly because XML is off-putting in
general.

One aspect where apache ant appears to be more helpful than make is the
explicit support for setting up a project to handle compilation on a
dedicated directory somewhere in the project tree. This is also possible
with make, but it requires a tiny bit of added work than simply pointing out
a path.


Thanks for the help,
Rui Maciel

[Rui Maciel]

Martin Gregorie wrote:

> On Sun, 22 Apr 2012 16:15:30 +0100, Rui Maciel wrote:
>
>> Is it possible to set up a Java project so that it can be built without
>> relying on an IDE? If it is, where can I find any information on how to
>> set up this sort of project?
>>
> Simple. Do just as you would for, say, a C project but use Ant instead of
> make.
>
>> Bonus points if it's possible to pull this off by writing a single
>> makefile.
>>
> Its the norm to use a single build.xml (ant's equivalent of Makefile) to
> do everything that make will, i.e. build, clean the source structure,
> install the jarfiles. The only significant differences are that its
> working with a package hierarchy rather than a set of modules in separate
> directories and that it will usually run javadocs too.
>
> This is how I usually work with Java projects, often over an ssh session.

Thanks for the help, Martin. I had read your post a while ago, but waited
until after I read up on your suggestion before posting a reply.

It appears you are right on the money. As an added bonus, as some IDEs rely
on apache ant to manage builds, it appears it makes it possible to develop
with IDEs and text editors (and also switch between both), not only to write
code but also update the build script, without experiencing any hickup in
the process. That's nice.


Once again, thanks for the help, Martin. Kudos!
Rui Maciel

[markspace]

On 4/24/2012 6:33 PM, Rui Maciel wrote:
> The XML bit was really off-putting, mainly because XML is off-putting in
> general.

You can copy the basic build file from the tutorial, and save it as a
"template" for future build files. You only have to change two strings
normally to get it to work on a new project.

> One aspect where apache ant appears to be more helpful than make is the
> explicit support for setting up a project to handle compilation on a
> dedicated directory somewhere in the project tree. This is also possible
> with make, but it requires a tiny bit of added work than simply pointing out
> a path.

Another thing that ant does is makes portability easier. I develop on
Windows. Ant converts all paths with a '/' to the proper file separator
for the local OS. That's a nice feature if you've got a team switching
between Unix and Windows.

There's other portability issues too, like using FileSets or PatternSets
instead of relying on tools like ls, find and grep that might not be
available on non-Unix systems.

[Robert Klemme]

On 04/25/2012 03:09 AM, Rui Maciel wrote:
> So, you either are a functional illiterate or a troll.

Ad hominem isn't really helpful either...

> Either way, you are
> not helpful. So, if you don't have anything helpful to add then go waste
> your time and your wild imagination elsewhere.

Lew is usually pretty good at exhibiting the weak points of an argument.
People tend to not like to hear that, but it is totally possible that
they waste good advice that way...

Kind regards

robert

[Lew]

On 04/24/2012 07:03 AM, Rui Maciel wrote:
> Lew wrote:
>
>> Rui Maciel wrote:

>>> I would prefer to develop
>>> a skill which I already have than being forced to start from scratch by
>>> being forced to use another tool.
>>
>> The sound of the career death knells tolling.
>
> You are assuming that everyone's career depends on how well they are able to

No, I'm not.

> manually set up an ant build script to build a Java project. That's a bad
> assumption. I would bet that a significant number of people who write Java
> code for a living never bothered to manually tweak an ant build script, let
> alone took the time to learn that tool.

My point went right over your head, apparently.

I was referring to your unwillingness to learn tools and skills needed for new
environments. Your resistance to learning is what is the death knell. That's a
universal requirement for success as a programmer, not just in Java, and
without the commitment to learn and grow, you'll wither and die, or worse, end
up a manager because your programming skills, such as they are, will utterly
cease to be relevant and you won't be able to adapt for lack of practice.
Bongggg. Bongggg.

I'll take your bet. How much? Every single Java shop where I've worked since
2000 or 2001 has used Ant, or later, Maven, or both to build Java
applications. Every single Java programmer with whom I've worked in that time,
and every one with whom I've associated in Java Users Groups, has been at
least minimally conversant with Ant.

And what do you deem "significant"? The worst 5% of Java programmers? The
worst 10%? How much to be significant?

In every profession there are the virtuosi and the, let's call them barely
competent. Those in the Java world who refuse to learn the standards of that
world doom themselves to the latter category, just as in any profession. Those
who refuse to learn, or take the universal advice (has any of our experts
advised you to ignore Ant and focus on make for Java?) are hurting themselves
and all their clients. Do you really want to be that guy?

--
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

[Lew]

Rui Maciel wrote:
> So, you either are a functional illiterate or a troll. Either way, you are
> not helpful. So, if you don't have anything helpful to add then go waste
> your time and your wild imagination elsewhere.

Plonk.

Too bad for you.

[Rui Maciel]

Arne Vajhøj wrote:

> On 4/24/2012 7:36 AM, Rui Maciel wrote:
>> Arne Vajhøj wrote:
>>
>>> Given that with mentioning any specific IDE's/editors then
>>> an editor is a subset of an IDE, then that does not make
>>> much sense..
>>
>> It can only make no sense if you believe that any statement regarding how
>> a particular text editor compares to the text editor made available by a
>> specific IDE is something which can be expressed objectively in absolute
>> terms. It isn't. Taste and personal preferences are, well, personal.
>> These are subjective opinions, which each of us holds, that reflect
>> nothing more than our personal tastes, preferences and even habits.
>
> ????
>
> There is certainly a strong element in personal preferences for
> specific tools.
>
> But that has absolutely no relevance.
>
> You were not talking about specific tools but about IDE's and
> text editors.
>
> And you were talking about features provided not whether
> you liked them or not.

I talked about the features provided by some text editors and some IDEs, and
to me some text editors provide a set of features which are invaluable and
still up to this day can't be had with any IDE. Surely you understand that
the decision of whether something is better or worse than something else is
subjective and a matter of personal opinion. Don't you?

Then, I don't know about you, but when I express an opinion I express my own
and no one else's, and I also do not believe I represent anyone but me.
Don't you, or do you actually believe that when you state your opinion you
are actually speaking for a group of people?

> Well - you brought up the discussion about features provide by IDE's
> and editors.
>
> And we pointed out that you were wrong because editor+tools does
> not have less features than editor.

And so you admit that you got confused and in the process managed to both
entirely miss the point and fail to read or, worse, failed to understand
what I wrote. Quite possibly both are related. After all, no one but
yourself said anything about IDEs having more or less features than editors.
No one else made that mistake. If you doubt this then do point out exactly
where anyone else, particularly me, made that idiotic claim. Don't be
surprised if you find yourself on a wild goose chase or facing the fact that
you failed to read something.

So, if you have a problem with silly claims then, well, just stop making
them, and stop using your imagination as a basis for silly arguments.

> And the rest is just your hopeless pathetic attempts to avoid
> admitting your fault.

It looks like you don't enjoy making mistakes, and when you do you have a
hard time admitting to them. Resorting to name-calling doesn't help
you,either, as it isn't a magic matra that makes all your screwups go
magically away. It only shows how desperate you become.

So, come back after you searched where exactly anyone else made that idiotic
claim you invented, and then let's see who is is engaged in "hopeless
pathetic attempts to avoid admitting" their fault.


Rui Maciel

[Rui Maciel]

Robert Klemme wrote:

> On 04/25/2012 03:09 AM, Rui Maciel wrote:
>> So, you either are a functional illiterate or a troll.
>
> Ad hominem isn't really helpful either...

In this case it's not ad hominem. If he is basing his complaints on
something he believes he read instead of what has been actually written.
This inability to comprehend what has been read is, by definition,
functional illiteracy, and someone who suffers from this problem is a
functinal illiterate.

On the other hand, if he actually read and was able to understand what he
wrote then his repeated intention to willingly misrepresent what others have
said is both dishonest and provocative; hence, the troll.

So, as this was not about "negating the truth" but just a case of calling a
spade a spade, this was no ad hominem.

But I agree this is a a waste of time, and completely unhelpful.


Rui Maciel

[Rui Maciel]

Lew wrote:

> On 04/24/2012 07:03 AM, Rui Maciel wrote:
>> Lew wrote:
>>
>>> Rui Maciel wrote:
>>>> I would prefer to develop
>>>> a skill which I already have than being forced to start from scratch by
>>>> being forced to use another tool.
>>>
>>> The sound of the career death knells tolling.
>>
>> You are assuming that everyone's career depends on how well they are able
>> to
>
> No, I'm not.

Of course you don't. Nevermind what you actually wrote, or how you
proceeded to rant about how anyone's career is affected by it.

>> manually set up an ant build script to build a Java project. That's a
>> bad
>> assumption. I would bet that a significant number of people who write
>> Java code for a living never bothered to manually tweak an ant build
>> script, let alone took the time to learn that tool.
>
> My point went right over your head, apparently.
>
> I was referring to your unwillingness to learn tools and skills needed for
> new environments.

As I've pointed out before, you repeatedly show that you have a bit of a

problem in basing your arguments and criticism on unfounded assumptions.

In this case, how exactly do you go from "I would prefer" to
"unwillingness"?

> Your resistance to learning is what is the death knell.
> That's a universal requirement for success as a programmer, not just in
> Java, and without the commitment to learn and grow, you'll wither and die,
> or worse, end up a manager because your programming skills, such as they
> are, will utterly cease to be relevant and you won't be able to adapt for
> lack of practice.

here you are again with your wild assumptions and making up accusations as
you go along. I'm still not sure if you engage in this sort of behaviour
because you honestly have difficulty reading other people's comments, or
because you choose to intentionally misrepresent what they actually say to
the point where you actually make stuff up to base your criticism.

In this particular case, you are trying to accuse someone who started a
thread to help him learn how to manually set up a build process of...
"unwillingness to learn" and "resistance to learning". This is how much far
off the deep-end you insist in putting yourself.

> Bongggg. Bongggg.
>
> I'll take your bet. How much? Every single Java shop where I've worked
> since 2000 or 2001 has used Ant, or later, Maven, or both to build Java
> applications. Every single Java programmer with whom I've worked in that
> time, and every one with whom I've associated in Java Users Groups, has
> been at least minimally conversant with Ant.
>
> And what do you deem "significant"? The worst 5% of Java programmers? The
> worst 10%? How much to be significant?

I see you felt the need to leave the "no true scotsman" door opened for your
silly argument. You know quite well why you felt the need to set up that
subterfuge.

> In every profession there are the virtuosi and the, let's call them barely
> competent. Those in the Java world who refuse to learn the standards of
> that world doom themselves to the latter category, just as in any
> profession. Those who refuse to learn, or take the universal advice (has
> any of our experts advised you to ignore Ant and focus on make for Java?)
> are hurting themselves and all their clients. Do you really want to be
> that guy?

Here you go again, making up accusations as you go along. You can't help
yourself, can you? Far from me to screw up another of your baseless rants
and raves, but where exactly did I said anything about "refusing to learn
the standards"? Nowhere. Once again you felt the need make this stuff up.
It's like you have a hard time dealing with reality and so you feel
compelled to take refuge in your imaginary world, where everything is a
figment of your imagination and the only connections to reality are only
there for your personal convenience, and only when they are convenient.
Once it isn't convenient, you just contradict yourself and proceed as
before.

I've started this thread to try to get some helpful tips from knowledgeable
and experienced people on how to set up an automatic build system that can
be used through a CLI and doesn't depend on an IDE. In the process I've
received quite a few helpful tips, to which I'm grateful. Yet, this
discussion also managed to attract the likes of you, who appear to believe
that it's acceptable to vent your frustrations with your life by repeatedly
assuming a petty and contentious attitude regarding anything at all, and
inthe process wasting your time ranting and raving about accusations you
repeatedly make up from the top of your heads. You, with your anti-social
attitude, your lies and your made-up accusations, are not helping others or
even yourself.

So, if you don't have anything positive or helpful to add to any discussion
then don't. Don't even bother wasting your time writing and posting a
reply. Find another way to vent the frustrations you have with your life.
This newsgroup doesn't need more noise to muffle those who are genuinely
knowledgeable and helpful, and the world doesn't need yet another troll
throwing a tantrum on the internet.


Rui Maciel

[Gene Wirchenko]

On Tue, 24 Apr 2012 14:07:48 -0300, Arved Sandstrom
<asandstr...@eastlink.ca> wrote:

[snip]

>Does someone's career - let's say current job - *depend* on knowing Ant?
>I doubt it, not in and of itself. But if I had someone working for me as
>a Java developer, unless they were an absolute newbie I'd look askance
>at them not knowing certain things by a certain point in their
>professional development.

Given that there are so many tools out there, I would not take
such an attitude. I *would* want to see that the person had done
something adequate.

>I have worked with intermediate Java developers - people who have used
>basically nothing but Java in their entire career - who don't know Ant,
>don't know Maven, don't know Ivy, don't know Hudson/Jenkins or any other
>CI system, only know JUnit - sort of - out of all the available test
>frameworks, aren't up to speed on any Java API except for the ones that
>they've had to use for work. You then come to find out that they barely
>know XML: no knowledge (or very deficient knowledge) of XSLT or XPath,
>for example. You come to find out that they don't know Powershell on
>Windows, bash or sh or ksh on UNIX, or even DOS-type batch files. They
>have only superficial knowledge of regular expressions.

That is not the situation I was referring to. I mean someone who
does know the language well, can produce, but just has not worked with
the particular tool in question.

[snip]

>I have a great deal of tolerance for someone who has to learn something
>unexpected. We all have to do that on occasion. I have considerably less
>tolerance for an intermediate or senior developer who is _routinely_
>having to "pick up" skills just when they need it. They're doing it on
>company time and client time.

But we are almost always doing that. Determining what is needed
is learning just in time. That might entail having to dig into the
libraries some more, for example.

Sincerely,

Gene Wirchenko

[Gene Wirchenko]

On Tue, 24 Apr 2012 21:10:46 -0400, Arne Vajhøj <ar...@vajhoej.dk>
wrote:

[snip]

>But it is only 1/3 of the problem that is the actual lack
>of Ant skills - the 2/3 of the problem is the attitude.

Yes.

I am highly-resistant to flavour of the <time period>. If I have
something that is working well for me, I am unlikely to change short
of a compelling reason. If there is good reason, I will try new
things. There is so much noise though of so many tools that I
generally need a reason before proceeding, and I am very likely to
drop something cold if it turns into a time-waster.

Sincerely,

Gene Wirchenko

[Gordon Levi]

Arne Vajhøj <ar...@vajhoej.dk> wrote:

>I would be tempted to consider Dreamweaver a design tool and not an IDE.

Why?

[Gene Wirchenko]

OTOH, knowing something else might help deal with the problem.

Sincerely,

Gene Wirchenko

[Gene Wirchenko]

On Wed, 25 Apr 2012 01:01:20 -0700, Lew <no...@lewscanon.com> wrote:

>Rui Maciel wrote:
>> So, you either are a functional illiterate or a troll. Either way, you are
>> not helpful. So, if you don't have anything helpful to add then go waste
>> your time and your wild imagination elsewhere.
>
>Plonk.
>
>Too bad for you.

Please plonk me, too.

Sincerely,

Gene Wirchenko

[Arved Sandstrom]

On 12-04-25 01:10 PM, Gene Wirchenko wrote:
> On Tue, 24 Apr 2012 14:07:48 -0300, Arved Sandstrom
> <asandstr...@eastlink.ca> wrote:
>
> [snip]
>
>> Does someone's career - let's say current job - *depend* on knowing Ant?
>> I doubt it, not in and of itself. But if I had someone working for me as
>> a Java developer, unless they were an absolute newbie I'd look askance
>> at them not knowing certain things by a certain point in their
>> professional development.
>
> Given that there are so many tools out there, I would not take
> such an attitude. I *would* want to see that the person had done
> something adequate.

From my standpoint that includes self-motivated professional
development. If I see a guy who only ever picked up skills that his
employers demanded of him, and only when they required those skills and
not before, I am not impressed by his motivation.

>> I have worked with intermediate Java developers - people who have used
>> basically nothing but Java in their entire career - who don't know Ant,
>> don't know Maven, don't know Ivy, don't know Hudson/Jenkins or any other
>> CI system, only know JUnit - sort of - out of all the available test
>> frameworks, aren't up to speed on any Java API except for the ones that
>> they've had to use for work. You then come to find out that they barely
>> know XML: no knowledge (or very deficient knowledge) of XSLT or XPath,
>> for example. You come to find out that they don't know Powershell on
>> Windows, bash or sh or ksh on UNIX, or even DOS-type batch files. They
>> have only superficial knowledge of regular expressions.
>
> That is not the situation I was referring to. I mean someone who
> does know the language well, can produce, but just has not worked with
> the particular tool in question.

Here's the thing, though, Gene. Once a language (or languages) have been
picked, there are almost always only a very small number of common
choices for building. With Java the triad of IDE build system, Ant and
Maven covers a large majority of non-trivial builds. This is simply fact.

I don't expect that a Java programmer has necessarily been required to
use Ant or Maven professionally. I _do_ expect that before they are ever
called upon to use a *common* Java build tool that they use their own
time to learn it well enough that they don't waste an employer's or
customer's time on picking up a basic skill.

We're not talking about a niche tool here.

> [snip]
>
>> I have a great deal of tolerance for someone who has to learn something
>> unexpected. We all have to do that on occasion. I have considerably less
>> tolerance for an intermediate or senior developer who is _routinely_
>> having to "pick up" skills just when they need it. They're doing it on
>> company time and client time.
>
> But we are almost always doing that. Determining what is needed
> is learning just in time. That might entail having to dig into the
> libraries some more, for example.
>
> Sincerely,
>
> Gene Wirchenko

Of course we do, and sometimes there is a grey area as to what you can
reasonably expect a developer to anticipate. But often there's not.

Let me give you an example. Java 7 has been the current release for some
time now. I doubt that the majority of Java developers use it
professionally yet. But do you think there could be any excuse for a
professional Java programmer to know nothing about what's new in Java 7,
as of right now? Do you think it would be OK for them to say that
they'll learn Java 7 on customer time when the need arises?

I don't think that's OK.

AHS
--
A fly was very close to being called a "land," cause that's what they do
half the time.
-- Mitch Hedberg

[Arne Vajhøj]

http://www.adobe.com/products/dreamweaver.html

<quote>
What is Dreamweaver?

Adobe® Dreamweaver® CS6 web design software provides an intuitive visual
interface for making and editing HTML websites and mobile apps. Use
fluid grid layout designed for cross-platform compatibility to create
adaptive layouts. Review designs with Multiscreen Preview before publishing.
</quote>

:-)

Arne

[Arne Vajhøj]

On 4/25/2012 12:10 PM, Gene Wirchenko wrote:
> On Tue, 24 Apr 2012 14:07:48 -0300, Arved Sandstrom
> <asandstr...@eastlink.ca> wrote:
>> Does someone's career - let's say current job - *depend* on knowing Ant?
>> I doubt it, not in and of itself. But if I had someone working for me as
>> a Java developer, unless they were an absolute newbie I'd look askance
>> at them not knowing certain things by a certain point in their
>> professional development.
>
> Given that there are so many tools out there, I would not take
> such an attitude.

You should.

You need to distinguish between any tool and tools that are very
widely used.

It is not a problem not to know anything about some rare obscure tool,
but knowing tools that are used by 50% or 30% of all Java developers
is a problem.

Arne

[Arne Vajhøj]

On 4/25/2012 12:13 PM, Gene Wirchenko wrote:
> On Tue, 24 Apr 2012 21:10:46 -0400, Arne Vajhøj<ar...@vajhoej.dk>
> wrote:
>
> [snip]
>
>> But it is only 1/3 of the problem that is the actual lack
>> of Ant skills - the 2/3 of the problem is the attitude.
>
> Yes.
>
> I am highly-resistant to flavour of the<time period>.

Ant has been widely used for over a decade!

> If I have
> something that is working well for me, I am unlikely to change short
> of a compelling reason.

You need to have the skills in demand. If you want to work in
the business - if you are coding as a hobby or part of an entirely
different profession, then it may not matter much.

> If there is good reason, I will try new
> things. There is so much noise though of so many tools that I
> generally need a reason before proceeding, and I am very likely to
> drop something cold if it turns into a time-waster.

There may be a lot of noise.

But if you actually read some of it you would find out that
ant is used by about 50% of Java projects for builds (Maven
takes the majority of the rest).

That is fact.

Arne

[Arne Vajhøj]

On 4/25/2012 7:18 AM, Rui Maciel wrote:
> Robert Klemme wrote:
>
>> On 04/25/2012 03:09 AM, Rui Maciel wrote:
>>> So, you either are a functional illiterate or a troll.
>>
>> Ad hominem isn't really helpful either...
>
> In this case it's not ad hominem.

It certainly is.

> If he is basing his complaints on
> something he believes he read instead of what has been actually written.
> This inability to comprehend what has been read is, by definition,
> functional illiteracy, and someone who suffers from this problem is a
> functinal illiterate.
>
> On the other hand, if he actually read and was able to understand what he
> wrote then his repeated intention to willingly misrepresent what others have
> said is both dishonest and provocative; hence, the troll.
>
> So, as this was not about "negating the truth" but just a case of calling a
> spade a spade, this was no ad hominem.

It is a personal attack with absolute no substance in.

A textbook example of ad hominem.

Arne

[Arne Vajhøj]

On 4/24/2012 9:44 AM, Rui Maciel wrote:
> Lew wrote:

>> Rui Maciel wrote:
>>> Robert Klemme wrote:

>>>> Nasser M. Abbasi wrote:
>>>>> I found that using one good tool for everything is better than
>>>>> mixing things.
>>>>
>>>> Which, if followed religiously, will lead you into a situation where it
>>>> can get really awkward to do things with tool A which would be extremely
>>>> easy with tool B.
>>>
>>> This isn't necessarily a problem, particularly if a person is already
>>> familiar with tool A while being completely unaware that tool B even
>>> existed.
>>

>> You cannot make claim to being a Java programmer if you've never heard of
>> Ant.
>
> Read up on "hyperbole".

Read up on usenet.

>>>>> Also, gnumake can do so many more things than just build source
>>>>> code. I use it to update my html files and pdf files from
>>>>> Latex sources, and other such things.
>>>>
>>>> No wonder because make doesn't do *any* of these things. Make evaluates
>>>> timestamps along dependencies (mostly between files) and invokes other
>>>> programs that do all the work. GNU make additionally has an extremely
>>>> large database of predefined rules, has functions and other
>>>> capabilities.
>>>
>>> There is nothing wrong with this. In fact, I see it as an extremelly
>>> valuable feature. It's a pain in the neck to shoe-horn custom build
>>> rules to an automated build system which was developed with them as an
>>> afterthought.
>>
>> Also a benefit of Ant. Ant is extensible, unlike make. You can write new
>> targets for it in Java.
>
> I don't understand. Are you saying that it it impossible to add new targets
> to a makefile?

No.

He is saying that ant has a plugin architecture that allows
developers to create their own tasks.

Which you would know if you bothered to read about the tools you
are choosing between.

>>>> Interestingly GNU make's large built in rule database does not contain
>>>> anything related to compiling Java. How do you create your Makefiles in
>>>> a way as to invoke javac only for those files which have changed -
>>>> especially in light of the fact that one Java source file might create
>>>> multiple .class files?
>>>
>>> Maybe build-in rules aren't needed, considering Make's [sic] static
>>> pattern rules.
>>
>> Or considering that Ant is better and more standard for the purpose.
>
> I don't believe it is reasonable to declare that make isn't standard for
> managing build processes.

Make is very much a standard for building C/C++ code and some other
languages.

But make is not a standard for building Java code.

And the topic is the second.

Arne

[Arne Vajhøj]

On 4/24/2012 9:09 PM, Rui Maciel wrote:
> Lew wrote:

>>> And surely you are aware that a considerable number of people who spend a
>>> portion of their time writing Java code don't exactly make that their
>>> profession.
>>
>> Are you claiming that non-professionals should deliberately flout best
>> practices, simply because they don't make a living at it?
>
> I made no such claim. I would appreciate it if you stopped trying to pin on
> me these wild claims you are making up as you go along.

Well - you posted it in this thread.

Lew just make the mistake of assuming that you posted it with a purpose.

You can prevent that type of mistakes by not posting
irrelevant comments.

>>>> Also: sticking with a known strategy for too long instead
>>>> of knowing when to check other approaches is not a winning strategy.
>>>
>>> It isn't. But wasting time checking each and every alternative that some
>>> bloke on the internet said was the winning strategy is also not a winning
>>> strategy.
>>
>> This isn't a case of that, so why mention it?
>
> Frankly, that's what every single one of those blokes on the internet says.
>
> As a warning, I should inform you that this was also a hyperbole.

Stop posting irrelevant info.

>> It would have to be better to justify its use, since Ant is the standard.
>
> By your reasoning, you should be using make as it is actually the standard
> in the real sense of the word. ISO standard and all. Instead, it appears
> you are hell-bent on criticising make.

I don't think he or anybody else criticized make.

It is just not a good tool for building Java.

But since make is not supposed to be used for building Java, then
that is not criticism of make.

>> As it happens, make is worse for Java projects than make, so that's a huge
>> strike against it.
>>
>> Unwillingness to learn the standard tool (which really only takes about an
>> hour or two to learn, BTW) is a pitiful and non-engineering reason to
>> avoid using Ant.
>
> Again with your unfounded assumptions and baseless accusations. Can you
> point out exactly where anyone stated that they refused to learn how to use
> ant or even maven? You can't, because no one, besides you with your wild
> imagination, ever said it.

Let me quote:

#But wasting time checking each and every alternative that some
#bloke on the internet said was the winning strategy is also not a
#winning strategy.

Either that was about ant or it was irrelevant for the thread.

Arne

[Arne Vajhøj]

On 4/24/2012 7:47 AM, Rui Maciel wrote:
> Meanwhile, the post you've replied to doesn't mention any of that, and it
> does so due to a simple fact that you've missed: this is not, nor it ever
> was supposed to be, an editor war. Everyone uses the tools they choose to
> use, and if everyone is happy with their choice then all is well.
> Criticising others for using a different tool than the one they chose is a
> complete waste of time. I didn't made that mistake. So, I wonder why you
> chose to make it.
>
> To make things as clear as possible for you, this discussion is
never, nor
> it will be, about which editor is better than some other editor.

You actually wrote:

#They also tend to be inferior in a considerable number of aspects,
#particularly when compared with the features provided by some text
#editors.

If you did not want to discuss IDE vs editor, then do not bring
up the topic.

Very simple!

> It is
> about setting up an automatic build process that doesn't rely on a IDE.

It has been explained to you many times that ant and maven are the tools
to use.

And they can be used command line, inside an IDE or from a text editor
with capabilities to run external tools.

Arne

[Arne Vajhøj]

On 4/25/2012 7:05 AM, Rui Maciel wrote:
> Arne Vajhøj wrote:
>
>> On 4/24/2012 7:36 AM, Rui Maciel wrote:
>>> Arne Vajhøj wrote:
>>>
>>>> Given that with mentioning any specific IDE's/editors then
>>>> an editor is a subset of an IDE, then that does not make
>>>> much sense..
>>>
>>> It can only make no sense if you believe that any statement regarding how
>>> a particular text editor compares to the text editor made available by a
>>> specific IDE is something which can be expressed objectively in absolute
>>> terms. It isn't. Taste and personal preferences are, well, personal.
>>> These are subjective opinions, which each of us holds, that reflect
>>> nothing more than our personal tastes, preferences and even habits.
>>
>> ????
>>
>> There is certainly a strong element in personal preferences for
>> specific tools.
>>
>> But that has absolutely no relevance.
>>
>> You were not talking about specific tools but about IDE's and
>> text editors.
>>
>> And you were talking about features provided not whether
>> you liked them or not.
>
> I talked about the features provided by some text editors and some IDEs,

No.

You talked about IDE's in general not about some IDE's.

> and
> to me some text editors provide a set of features which are invaluable and
> still up to this day can't be had with any IDE.

Still without any examples.

> Surely you understand that
> the decision of whether something is better or worse than something else is
> subjective and a matter of personal opinion

Don't you understand English??

Let me quote myself.

# And you were talking about features provided not whether
# you liked them or not.

Is that difficult to understand?

> Then, I don't know about you, but when I express an opinion I express my own
> and no one else's, and I also do not believe I represent anyone but me.

Nobody cares about your opinion.

We do care about whether features are present or not.

>> Well - you brought up the discussion about features provide by IDE's
>> and editors.
>>
>> And we pointed out that you were wrong because editor+tools does
>> not have less features than editor.
>
> And so you admit that you got confused and in the process managed to both
> entirely miss the point and fail to read or, worse, failed to understand
> what I wrote. Quite possibly both are related. After all, no one but
> yourself said anything about IDEs having more or less features than editors.

That was what you wrote.

> No one else made that mistake.

Not true. You have gotten several responses along those lines.

> If you doubt this then do point out exactly
> where anyone else, particularly me,

#They also tend to be inferior in a considerable number of aspects,

#particularly when compared with the features provided by some text
#editors.

>> And the rest is just your hopeless pathetic attempts to avoid
>> admitting your fault.
>
> It looks like you don't enjoy making mistakes, and when you do you have a
> hard time admitting to them.

That sounds as a perfect description of yourself.

> Resorting to name-calling doesn't help
> you,either, as it isn't a magic matra that makes all your screwups go
> magically away. It only shows how desperate you become.

Let me quote what you wrote in another post:

#So, you either are a functional illiterate or a troll.

You were saying what?

Arne

[Arne Vajhøj]

On 4/24/2012 8:53 AM, Rui Maciel wrote:
>> Modern IDEs are far superior to any text editor. 10 years ago I was a
>> vim (actually just vi) fan. No longer. The features provided by modern
>> IDEs are leaps and bounds beyond what any text editor provides.
>>
>> If you can show me a text editor that is superior in any significant
>> regard to my IDE

> Nonetheless, we should understand that there is no such thing as a "one size
> fits all" solution. No IDE is the best tool for every conceivable scenario
> ever faced by every programmer that ever lived. One way to prove this is by
> pointing out the fact that there is more than a single IDE out there, and
> even in this day there are fools who waste their time with IDE flame wars
> complaining how their IDE is better than someone else's, and how those who
> don't use a specific IDE are somehow idiots and trolls.

????

it was you that starting call people trolls!

> Now, just to point out how a "modern IDE" is inadequate in some
> circumstances, I can point you to those cases where a programmer, for some
> reason, happens to need to work on some project with one of those flimsy
> netbook computers, the ones with tiny monitors and limited disk space.
> Running an IDE on one of those systems is an experience that only a
> masochist can enjoy, and even then he would have trouble doing any work.
> Meanwhile, it isn't hard to find a bunch of text editors that work perfectly
> well with those limitations.

It is certainly true.

But does not really related to your original claim about features.

And it is not a particular important aspect for a discussion about
development tools as netbooks are not intended for that purpose.

Arne

[Arne Vajhøj]

On 4/25/2012 8:48 AM, Rui Maciel wrote:
> Lew wrote:
>> In every profession there are the virtuosi and the, let's call them barely
>> competent. Those in the Java world who refuse to learn the standards of
>> that world doom themselves to the latter category, just as in any
>> profession. Those who refuse to learn, or take the universal advice (has
>> any of our experts advised you to ignore Ant and focus on make for Java?)
>> are hurting themselves and all their clients. Do you really want to be
>> that guy?
>
> Here you go again, making up accusations as you go along. You can't help
> yourself, can you? Far from me to screw up another of your baseless rants
> and raves, but where exactly did I said anything about "refusing to learn
> the standards"? Nowhere. Once again you felt the need make this stuff up.

Let me quote:

#But wasting time checking each and every alternative that some
#bloke on the internet said was the winning strategy is also not a
#winning strategy.

> I've started this thread to try to get some helpful tips from knowledgeable
> and experienced people on how to set up an automatic build system that can
> be used through a CLI and doesn't depend on an IDE. In the process I've
> received quite a few helpful tips, to which I'm grateful. Yet, this
> discussion also managed to attract the likes of you, who appear to believe
> that it's acceptable to vent your frustrations with your life by repeatedly
> assuming a petty and contentious attitude regarding anything at all, and
> inthe process wasting your time ranting and raving about accusations you
> repeatedly make up from the top of your heads. You, with your anti-social
> attitude, your lies and your made-up accusations, are not helping others or
> even yourself.
>
> So, if you don't have anything positive or helpful to add to any discussion
> then don't. Don't even bother wasting your time writing and posting a
> reply. Find another way to vent the frustrations you have with your life.
> This newsgroup doesn't need more noise to muffle those who are genuinely
> knowledgeable and helpful, and the world doesn't need yet another troll
> throwing a tantrum on the internet.

You attack people and tell them not to reply??

Not the smartest move I have seen. More the opposite.

Arne

[Arne Vajhøj]

On 4/23/2012 12:57 AM, Nasser M. Abbasi wrote:
> On 4/22/2012 10:28 PM, BGB wrote:
>>>> it does technically work though, and may make some sense, say, if
>>>> one is
>>>> also building a bunch of C code (say, as part of a JNI wrapper for
>>>> native code or similar), or is generally part of a larger project for
>>>> which make is already used.
>>>
>>> I would rather call ant from make or make from ant to handle those
>>> situations.
>>
>> yes, this works as well.
>>
>> I guess it is probably whichever is more convenient.

>
> I found that using one good tool for everything is better than
> mixing things.

The one language, one IDE/editor, one build tool, one OS etc.
idiom does not work well in the real world.

If you want to develop in Java (at least for a longer time)
one should learn the proper tools.

> As long as the idea that drives the tool is: Perform this action
> to update these prerequisites that this target depends on, then better
> to use one tool that does this better and for many other things, not
> just .java files.
>
> In my tree, I have .f, .f90, .c, .c++, .java, .tex, and many
> other files that I want to 'update' in my tree.
>
> Using one tool for all, is better, because one becomes better
> at using this one tool, and things are integrated better.
> gnumake+bash is pretty much all what I need.
>
> I tried ant, and found that I am doing the same thing I
> am already doing in my Makefile, just had to use different
> syntax. (I also did not like XML syntax). Also looked at Ruby
> script, and few other things. They all pretty much try to do
> what Make allready does but using different syntax.
>
> It is very easy to use gnumake to build Java and make jar files and
> all. Here is a link showing Makefile for Java from the best book
> on gnumake "Managing Projects with GNU make" by Robert Mecklenburg
>
> http://www.makelinux.net/make3/make3-CHP-9#make3-CHP-9
>
> Chapter 9 is all about using make for build Java.
>
> As others said. If you are using an IDE with its own build
> system. It is better to have your own makefile to build
> your tree, independent of what the IDE has. This way, if
> you changed IDE, or move your tree somewhere else where
> this IDE is not available, you can still build your tree
> any where.

All major Java IDE's support ant from inside the IDE.

And if you have followed the Java world a bit then you would
see that make is not the tool of choice in the Java world.

That honor goes to ant and Maven.

And let me quote something from the link you gave:

<quote>
This is primarily due to the way the import directive works. Similar to
a #include in C, this directive is used to allow access to externally
defined symbols.
</quote>

Java import is not similar to C include.

And neither are used specifically to allow access to symbols.

Arne

[Robert Klemme]

On 24.04.2012 14:53, Rui Maciel wrote:
> Nonetheless, we should understand that there is no such thing as a "one size
> fits all" solution. No IDE is the best tool for every conceivable scenario
> ever faced by every programmer that ever lived.

You apply a common discussion method here: make the claim of the other
side much bigger than what actually was said to make it easy to show how
absurd it is.

Please stop posting commonplaces like this and discuss concrete claims -
not abstract statements about tool A vs. tool B as you did before.

> Now, just to point out how a "modern IDE" is inadequate in some
> circumstances, I can point you to those cases where a programmer, for some
> reason, happens to need to work on some project with one of those flimsy
> netbook computers, the ones with tiny monitors and limited disk space.
> Running an IDE on one of those systems is an experience that only a
> masochist can enjoy, and even then he would have trouble doing any work.
> Meanwhile, it isn't hard to find a bunch of text editors that work perfectly
> well with those limitations.

If a program needs to be deployed on such a machine this does not
automatically mean that it needs to be edited or compiled there.

Regards

robert

--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

[BGB]

On 4/28/2012 8:27 PM, Arne Vajhøj wrote:
> On 4/23/2012 12:57 AM, Nasser M. Abbasi wrote:
>> On 4/22/2012 10:28 PM, BGB wrote:
>>>>> it does technically work though, and may make some sense, say, if
>>>>> one is
>>>>> also building a bunch of C code (say, as part of a JNI wrapper for
>>>>> native code or similar), or is generally part of a larger project for
>>>>> which make is already used.
>>>>
>>>> I would rather call ant from make or make from ant to handle those
>>>> situations.
>>>
>>> yes, this works as well.
>>>
>>> I guess it is probably whichever is more convenient.
>>
>> I found that using one good tool for everything is better than
>> mixing things.
>
> The one language, one IDE/editor, one build tool, one OS etc.
> idiom does not work well in the real world.
>

agreed.

not disagreeing here...

but, it may depend some on the project (like, which languages are
already most dominant in the project, ...). it is a little harder to
make a clear case if the Java code is only actually a small part of the
total codebase.

> And let me quote something from the link you gave:
>
> <quote>
> This is primarily due to the way the import directive works. Similar to
> a #include in C, this directive is used to allow access to externally
> defined symbols.
> </quote>
>
> Java import is not similar to C include.
>
> And neither are used specifically to allow access to symbols.
>

I think it may depend some on "how does it look from afar?".

the casual observer may not much think or care much about the
differences between, say, "inlining big globs of text" and "gaining
visibility into packages filled with classes" or similar.

they may instead think "using this directive allows me to use the
library", while paying little attention to the hows or whys.

so, to them, "X looks like Y" may be more important than "X is Y" or "X
is not Y" (even if this can get annoying sometimes, 1).

1: it is sad, but sometimes it is still necessary to try to explain to
people the concept of "call-by-value" and "call-by-reference" and why
they can't just assign an argument in a called method and expect the
caller to see the change "even if the variables have the same name".

nevermind trying to explain to people why things like indentation are
important, ...


this seems to be more the type of people the quoted paragraph was
intended for (vague wording more intended to give the basic idea than to
be strictly accurate).

[Arne Vajhøj]

On 4/29/2012 2:16 PM, BGB wrote:
> On 4/28/2012 8:27 PM, Arne Vajhøj wrote:
>> And let me quote something from the link you gave:
>>
>> <quote>
>> This is primarily due to the way the import directive works. Similar to
>> a #include in C, this directive is used to allow access to externally
>> defined symbols.
>> </quote>
>>
>> Java import is not similar to C include.
>>
>> And neither are used specifically to allow access to symbols.
>>
>
> I think it may depend some on "how does it look from afar?".
>
> the casual observer may not much think or care much about the
> differences between, say, "inlining big globs of text" and "gaining
> visibility into packages filled with classes" or similar.
>
> they may instead think "using this directive allows me to use the
> library", while paying little attention to the hows or whys.
>
> so, to them, "X looks like Y" may be more important than "X is Y" or "X

> this seems to be more the type of people the quoted paragraph was
> intended for (vague wording more intended to give the basic idea than to
> be strictly accurate).

It can be fine to come with an approximate correct explanation
if it is simpler to understand.

But it is not good to come with a completely false explanation
just because it is simple.

Java import and C include is not similar at any distance.

Try ask a C++ programmer if he thinks that include and using
are similar!

Arne

[Gene Wirchenko]

On Sat, 28 Apr 2012 22:29:45 -0400, Arne Vajhøj <ar...@vajhoej.dk>
wrote:

>On 4/25/2012 12:10 PM, Gene Wirchenko wrote:
>> On Tue, 24 Apr 2012 14:07:48 -0300, Arved Sandstrom
>> <asandstr...@eastlink.ca> wrote:
>>> Does someone's career - let's say current job - *depend* on knowing Ant?
>>> I doubt it, not in and of itself. But if I had someone working for me as
>>> a Java developer, unless they were an absolute newbie I'd look askance
>>> at them not knowing certain things by a certain point in their
>>> professional development.
>>
>> Given that there are so many tools out there, I would not take
>> such an attitude.
>
>You should.
>
>You need to distinguish between any tool and tools that are very
>widely used.

Very widely used does not mean everywhere. I would be curious as
to why he does not know the tool. For al I know, it might be that the
unusual tools worked better than the usual tools on the projects that
the person had worked on. Or maybe, he just had no choice in the
matter.

>It is not a problem not to know anything about some rare obscure tool,
>but knowing tools that are used by 50% or 30% of all Java developers
>is a problem.

So the 50% to 70% who do not use a tool should still know it?
Rather a waste of time.

I am more interested in the reaction to "We use <tool> here."'

Sincerely,

Gene Wirchenko

[Gene Wirchenko]

On Sat, 28 Apr 2012 22:34:24 -0400, Arne Vajhøj <ar...@vajhoej.dk>

wrote:

>On 4/25/2012 12:13 PM, Gene Wirchenko wrote:
>> On Tue, 24 Apr 2012 21:10:46 -0400, Arne Vajhøj<ar...@vajhoej.dk>
>> wrote:
>>
>> [snip]
>>
>>> But it is only 1/3 of the problem that is the actual lack
>>> of Ant skills - the 2/3 of the problem is the attitude.
>>
>> Yes.
>>
>> I am highly-resistant to flavour of the<time period>.
>
>Ant has been widely used for over a decade!

I was discussing the general case. I have seen too many cases of
"This is the greatest tool since ..." and when I try it, it fails on
very simple cases of mine.

>> If I have
>> something that is working well for me, I am unlikely to change short
>> of a compelling reason.
>
>You need to have the skills in demand. If you want to work in
>the business - if you are coding as a hobby or part of an entirely
>different profession, then it may not matter much.

True, but I am not going to drop everything because something
else comes out.

>> If there is good reason, I will try new
>> things. There is so much noise though of so many tools that I
>> generally need a reason before proceeding, and I am very likely to
>> drop something cold if it turns into a time-waster.
>
>There may be a lot of noise.

"may"?

>But if you actually read some of it you would find out that
>ant is used by about 50% of Java projects for builds (Maven
>takes the majority of the rest).

Fine. I am not coding in Java anymore, because I found that it
did not match what I needed. I do like the discussions such as this
one.

>That is fact.

I am not challenging it. I still decide what I use though.

Sincerely,

Gene Wirchenko

[BGB]

well, both are used to make use of a library, even if what they do and
how they work is considerably different.

both also have a word starting with the same letter and appear near the
top of a source file, and are vaguely similar looking, also sort of
making them "similar".


I also did once see a person try to do something like (in C++):
#include <javax.swing>

and then respond in their defense that "C++ and Java were basically the
same thing"... (nevermind if they are not...).

> Try ask a C++ programmer if he thinks that include and using
> are similar!
>

well, there is an important difference here:
you can't use 'using' to see a namespace which hasn't already been
included, and also 'using' is typically used differently as well.

so, it is more like comparing C / C++ #include and C# using.

[Arved Sandstrom]

I don't think it is, not in this case. There are few Java build tools:
it really comes down to command line, IDE, Ant and Maven. Developers
should understand C.L., so we are really talking about whether they
should know all of Ant, Maven and the build methodology for at least one
IDE.

If they use an IDE at all they'll know how to build in it, that's taken
care of. So what about Ant and/or Maven?

If they have any kind of build automation, and ideally a CI system, then
a build system like Ant or Maven is attractive. And they _should_ have
CI triggered off scheduling and/or commits, so it all ties together.

If they think they'll switch IDEs, or team members use different IDEs,
or they simply don't want to tie builds to an IDE, then Ant or Maven are
also attractive.

Over the course of a few years any decent developer can try at least one
realistic Ant buildfile for a project, and a POM for Maven for the same
or different project. It's maybe a few days' worth of hours, and once
you've learnt the fundamentals of both systems you're better prepared to
assess which one to use in the context of project builds in a larger CI
system.

If you know the basics of all the major Java build systems then you are
seriously better placed to decide which one should be used for a given
situation. If you don't have that knowledge you may as well keep your
mouth shut during build discussions. As senior as you might be, it'll be
*you* that's the waste of time.

You could just ignore almost all of that. In which case, sooner or later
as a senior or intermediate Java developer you'll end up in a new
company or in a new project where Ant or Maven is used. If I am the
technical guy in charge of you in that new environment and I find out
you're clueless about And and Maven *and* you've got 5 or 10 years in
the biz with most of that being Java, you'd best hope you're not on your
probationary period.

> I am more interested in the reaction to "We use <tool> here."'

So would I be. And you know something, if we say "we use Ant here", and
someone gets pissy because they don't know Ant and prefer Maven, I'm
shutting them out - they are getting told in no uncertain terms that
they are already making themselves look bad, and that they'd best be
busy on their own time learning Ant.

If on the other hand the new guy says, when learning that "we use Ant
here", that he knows both Ant and Maven well, and makes a reasoned
argument that he should continue to use Maven (Ant->Maven and Maven->Ant
conversions aren't that grotesque), and even that maybe *all of us*
should switch to Maven, I'll listen. I'll listen because he's bothered
to learn his tools.

> Sincerely,
>
> Gene Wirchenko

[Arne Vajhøj]

Neither of them are used to make use of a library.

Java import allows you to reference classes without package name.

C include includes some source code from another file in the
compilation of current file.

> both also have a word starting with the same letter and appear near the
> top of a source file, and are vaguely similar looking, also sort of
> making them "similar".

C include can be anywhere in the file.

They do both start with "i", but so does ice cream.

>> Try ask a C++ programmer if he thinks that include and using
>> are similar!
>
> well, there is an important difference here:
> you can't use 'using' to see a namespace which hasn't already been
> included, and also 'using' is typically used differently as well.

Namespaces are not necessarily included and you can be using
using without any include at all.

Arne

[Arne Vajhøj]

On 4/29/2012 11:35 PM, Gene Wirchenko wrote:
> On Sat, 28 Apr 2012 22:34:24 -0400, Arne Vajhøj<ar...@vajhoej.dk>
> wrote:
>
>> On 4/25/2012 12:13 PM, Gene Wirchenko wrote:
>>> On Tue, 24 Apr 2012 21:10:46 -0400, Arne Vajhøj<ar...@vajhoej.dk>
>>> wrote:
>>>
>>> [snip]
>>>
>>>> But it is only 1/3 of the problem that is the actual lack
>>>> of Ant skills - the 2/3 of the problem is the attitude.
>>>
>>> Yes.
>>>
>>> I am highly-resistant to flavour of the<time period>.
>>
>> Ant has been widely used for over a decade!
>
> I was discussing the general case. I have seen too many cases of
> "This is the greatest tool since ..." and when I try it, it fails on
> very simple cases of mine.

Well the thread was about build tools.

And the argument were to use ant.

I don't think anyone has claimed a need to learn any tool under
the SUN.

>
>>> If I have
>>> something that is working well for me, I am unlikely to change short
>>> of a compelling reason.
>>
>> You need to have the skills in demand. If you want to work in
>> the business - if you are coding as a hobby or part of an entirely
>> different profession, then it may not matter much.
>
> True, but I am not going to drop everything because something
> else comes out.

As explained then Java build tools is a relative stable market.

>>> If there is good reason, I will try new
>>> things. There is so much noise though of so many tools that I
>>> generally need a reason before proceeding, and I am very likely to
>>> drop something cold if it turns into a time-waster.
>>
>> There may be a lot of noise.
>
> "may"?
>
>> But if you actually read some of it you would find out that
>> ant is used by about 50% of Java projects for builds (Maven
>> takes the majority of the rest).
>
> Fine. I am not coding in Java anymore, because I found that it
> did not match what I needed. I do like the discussions such as this
> one.
>
>> That is fact.
>
> I am not challenging it. I still decide what I use though.

Obviously.

The point people were trying to make is that you will not look
good at the Java job market if you don't know ant - especially
not with arguments like some of those posted here.

Arne