From: Hussein Badakhchani
Subject: building JAVA applications with LISP/SCHEME
Date: 
Message-ID: <1049076345.398184@ananke.eclipse.net.uk>
If this question is a off topic I apologise, please direct me to the correct
news group.

Does anyone out there use LISP/SCHEME to manage the build process for there
JAVA applications. I want to compare build tools and strategies for building
and deploy JAVA and J2EE applications. I have plenty of information on Make
and ANT but very little on LISP. I know that there are some people using
LISP for this task and I want to understand the reasons for this choice.

(Please feel free to contact me directly as well as posting replys to the
list).

Cheers Hoos.

From: Gisle Sælensminde
Subject: Re: building JAVA applications with LISP/SCHEME
Date: 
Message-ID: <slrnb8g0k3.pc6.gisle@kaktus.ii.uib.no>
In article <·················@ananke.eclipse.net.uk>, Hussein Badakhchani wrote:
> If this question is a off topic I apologise, please direct me to the correct
> news group.
> 
> Does anyone out there use LISP/SCHEME to manage the build process for there
> JAVA applications. I want to compare build tools and strategies for building
> and deploy JAVA and J2EE applications. I have plenty of information on Make
> and ANT but very little on LISP. I know that there are some people using
> LISP for this task and I want to understand the reasons for this choice.
> 
> (Please feel free to contact me directly as well as posting replys to the
> list).

In my last job I made a build system our product, first in Make/shellscript and
then in ANT. I does quite well understand why some people would choose lisp
for such a task, although seen from the outside it is a nonobvious choice.

To make a build system for a product of several hundred tousand lines of code,
packaged in a varities of ways is a challenging task, and the reason to choose
a language like lisp, is that it support abstration and writing nontrivial code
quite well. It also make it easier to change the system once it's built. Code
for build processes will often be subject to change, more often than other kinds
of code. Often because the management decides to change the content of the
product packages, and add and remove 'editions', but can also be triggered by
changes in the product itself.

I does have experiences with both make and ANT. The problem with them is the
lack of expression. I made the build system for a program with about 300.000 
lines of code, which was delivered in at least 12 different packages, 
(enterprise and embedded edition, with and witout source, "legacy 
editions", that old customers had in their contract contract etc) and 
should work on java 1.1.x, pjava, (embedded environment) as well as jdk 
1.3 and 1.4 (enterprise environments), and use the right security model 
depending on target etc.
  
Make and shellscripts has little room for abstraction, so complex systems 
will be quite hard to maintain. The same is the case for ANT, but in ant 
you don't have the same possiblities as Make and Shellscripts to code 
around complex and changing  requirements. You either ends adding a lot of 
java pluggins (and effectivlly code the system in java), doing a lot of 
code duplications or try using ant as a programming language, which make 
the system very convoluted. Unfortunatly ANT can fool you, since it is 
quite elegant for trivial systems. I have seen ANT be the result of a 
"build system generator" though, and where quite successfull at that. Than 
it does not matter that there is a lot of code duplications in the ANT 
definition, since the system you maintain is not that ANT code. The system 
in mind was written in Java, but I think e.g. Lisp would make the system more
elegant managable, and require quite a lot less programming to do the same  
thing. This kind of processing is one of the strength of Lisps

PS: Lisp is a family of langauages, I talk about 'Common Lisp' when 
talking about lisp above.

--
Gisle S�lensminde  
Computational biology unit, University of Bergen, Norway
Email: ·····@cbu.uib.no 
Biology easily has 500 years of exciting problems to work on (Donald Knuth)
From: Hussein Badakhchani
Subject: Re: building JAVA applications with LISP/SCHEME
Date: 
Message-ID: <1049108052.846037@ananke.eclipse.net.uk>
"Gisle S�lensminde" <·····@kaktus.ii.uib.no> wrote in message
·························@kaktus.ii.uib.no...
> In article <·················@ananke.eclipse.net.uk>, Hussein Badakhchani
wrote:
> > If this question is a off topic I apologise, please direct me to the
correct
> > news group.
> >
> > Does anyone out there use LISP/SCHEME to manage the build process for
there
> > JAVA applications. I want to compare build tools and strategies for
building
> > and deploy JAVA and J2EE applications. I have plenty of information on
Make
> > and ANT but very little on LISP. I know that there are some people using
> > LISP for this task and I want to understand the reasons for this choice.
> >
> > (Please feel free to contact me directly as well as posting replys to
the
> > list).
>
> In my last job I made a build system our product, first in
Make/shellscript and
> then in ANT. I does quite well understand why some people would choose
lisp
> for such a task, although seen from the outside it is a nonobvious choice.
>
> To make a build system for a product of several hundred tousand lines of
code,
> packaged in a varities of ways is a challenging task, and the reason to
choose
> a language like lisp, is that it support abstration and writing nontrivial
code
> quite well. It also make it easier to change the system once it's built.
Code
> for build processes will often be subject to change, more often than other
kinds
> of code. Often because the management decides to change the content of the
> product packages, and add and remove 'editions', but can also be triggered
by
> changes in the product itself.
>
> I does have experiences with both make and ANT. The problem with them is
the
> lack of expression. I made the build system for a program with about
300.000
> lines of code, which was delivered in at least 12 different packages,
> (enterprise and embedded edition, with and witout source, "legacy
> editions", that old customers had in their contract contract etc) and
> should work on java 1.1.x, pjava, (embedded environment) as well as jdk
> 1.3 and 1.4 (enterprise environments), and use the right security model
> depending on target etc.
>
> Make and shellscripts has little room for abstraction, so complex systems
> will be quite hard to maintain. The same is the case for ANT, but in ant
> you don't have the same possiblities as Make and Shellscripts to code
> around complex and changing  requirements. You either ends adding a lot of
> java pluggins (and effectivlly code the system in java), doing a lot of
> code duplications or try using ant as a programming language, which make
> the system very convoluted. Unfortunatly ANT can fool you, since it is
> quite elegant for trivial systems. I have seen ANT be the result of a
> "build system generator" though, and where quite successfull at that. Than
> it does not matter that there is a lot of code duplications in the ANT
> definition, since the system you maintain is not that ANT code. The system
> in mind was written in Java, but I think e.g. Lisp would make the system
more
> elegant managable, and require quite a lot less programming to do the same
> thing. This kind of processing is one of the strength of Lisps
>
> PS: Lisp is a family of langauages, I talk about 'Common Lisp' when
> talking about lisp above.
>

Gisle,

Thank you for responding, I have created build processes on projects
comparable to the one  you describe but being a newcomer to LISP (I have
just started learning SCHEME) I stricktly used ANT. In order to reduce the
code replication and henece the maintenance overhead of changes to the build
process (I agree with you that the build process requirements can be
volatile especially early on in a project) I relied heavily on the XML
parsers ability to inline XML fragments and the AntCall task. While I found
the above solution to be adequate I have not objectivley compared it with
any other approach, hence this message.

Do you have any examples of implementing a simple build process with Common
LISP or do you know of any open source projects that use a LISP driven build
process?

Cheers Hoos.
From: Gisle Sælensminde
Subject: Re: building JAVA applications with LISP/SCHEME
Date: 
Message-ID: <slrnb8h99e.4p0.gisle@apal.ii.uib.no>
In article <·················@ananke.eclipse.net.uk>, Hussein Badakhchani wrote:
> 
> Gisle,
> 
> Thank you for responding, I have created build processes on projects
> comparable to the one  you describe but being a newcomer to LISP (I have
> just started learning SCHEME) I stricktly used ANT. In order to reduce the
> code replication and henece the maintenance overhead of changes to the build
> process (I agree with you that the build process requirements can be
> volatile especially early on in a project) I relied heavily on the XML
> parsers ability to inline XML fragments and the AntCall task. While I found
> the above solution to be adequate I have not objectivley compared it with
> any other approach, hence this message.
> 
> Do you have any examples of implementing a simple build process with Common
> LISP or do you know of any open source projects that use a LISP driven build
> process?

I'm sorry, but my answer is no. I have seen a system written in java,
(that generated ANT-xml code), as well as a huge number of make, shellscript
and ANT-based systems (including my own). I have not personally made a 
build system in Lisp, but I know that Lisp is a quite nice tool for 
handling complex tasks with changing requirements, and a build system for 
a large system goes into that category.

In my experience, the task of creating a build system is a kind of 
unpleasant task, which is invisible as long as everything works, but 
extremly visible when it breaks. It is also considered 'unsexy', and many 
developers seem to avoid comming in contact with build system development 
at any cost. That is probably the reason that quite old fashioned systems,
like make still dominates the field. It is not 'cool' to make better and 
more general build tools. In my experience a good build tool makes it 
easier to make frequent releses, and makes the relese schedule more 
smooth. What I especially miss is systems or methods for a system that
ensures that all the way from the versions controlled to the delivered
bundles sent to customers is well defined and reproducable. Every 
well-driven software house should do this, yet I have problems finding
literature on the subject. Maybe I looked the wrong places?


--
Gisle S�lensminde  
Computational biology unit, University of Bergen, Norway
Email: ·····@cbu.uib.no 
Biology easily has 500 years of exciting problems to work on. (Donald Knuth)
From: Jacob
Subject: Re: building JAVA applications with LISP/SCHEME
Date: 
Message-ID: <3E88230A.9030506@yahoo.com>
Gisle S�lensminde wrote:
> Make and shellscripts has little room for abstraction, so complex systems 
> will be quite hard to maintain. 

We use an adopted version of http://geosoft.no/javamake.html
for a baseline of more than 1 million LOC and more than
1000 packages/jars. It supports compilation of multiple
languages, jars, ears, javadoc, certificate generation,
deployment, backup routines, logging etc. Still it is
quite simple, basically just one single file.

The make syntax is not brilliant, but hard-to-read
Makefiles is more due to common Makefile writing practice
than the syntax itself.

And: More important than choosing build tools is to have a
well organized development environment and clean build
procedures.
From: Marco Antoniotti
Subject: Re: building JAVA applications with LISP/SCHEME
Date: 
Message-ID: <AA0ia.152$oj7.14535@typhoon.nyu.edu>
Jacob wrote:

> Gisle S�lensminde wrote:
>
> > Make and shellscripts has little room for abstraction, so complex
> > systems will be quite hard to maintain.
>
>
> We use an adopted version of http://geosoft.no/javamake.html
> for a baseline of more than 1 million LOC and more than
> 1000 packages/jars. It supports compilation of multiple
> languages, jars, ears, javadoc, certificate generation,
> deployment, backup routines, logging etc. Still it is
> quite simple, basically just one single file.
>
> The make syntax is not brilliant, but hard-to-read
> Makefiles is more due to common Makefile writing practice
> than the syntax itself.
>
> And: More important than choosing build tools is to have a
> well organized development environment and clean build
> procedures.
>

MK:DEFSYSTEM 4.x (MK4) has built in facilities to compile Java code. 
You can check the code (not yet released, but you are most welcome to 
play around with it and feedback) in the CLOCC (http://clocc.sf.net) CVS 
under the module name `defsystem-4.x'.

MK4 has provisions to compile C and Fortran code as well.

Cheers

--
Marco Antoniotti
From: Hussein Badakhchani
Subject: Re: building JAVA applications with LISP/SCHEME
Date: 
Message-ID: <1049127762.359574@ananke.eclipse.net.uk>
"Jacob" <·····@yahoo.com> wrote in message
·····················@yahoo.com...
> Gisle S�lensminde wrote:
> > Make and shellscripts has little room for abstraction, so complex
systems
> > will be quite hard to maintain.
>
> We use an adopted version of http://geosoft.no/javamake.html
> for a baseline of more than 1 million LOC and more than
> 1000 packages/jars. It supports compilation of multiple
> languages, jars, ears, javadoc, certificate generation,
> deployment, backup routines, logging etc. Still it is
> quite simple, basically just one single file.
>
> The make syntax is not brilliant, but hard-to-read
> Makefiles is more due to common Makefile writing practice
> than the syntax itself.
>


Jacob,

Thanks for the link I will take a look

> And: More important than choosing build tools is to have a
> well organized development environment and clean build
> procedures.

I agree an organised dev environment and clean build procedure is essential
for creating a simple scalable build process but I am considering this as a
given. I want to examine the approaches that build tools like Make and ANT
take and compare them with, in this case a LISP managed approach.

Hoos.
From: Hussein Badakhchani
Subject: Re: building JAVA applications with LISP/SCHEME
Date: 
Message-ID: <1049128074.35710@ananke.eclipse.net.uk>
"Jacob" <·····@yahoo.com> wrote in message
·····················@yahoo.com...
> Gisle S�lensminde wrote:
> > Make and shellscripts has little room for abstraction, so complex
systems
> > will be quite hard to maintain.
>
> We use an adopted version of http://geosoft.no/javamake.html
> for a baseline of more than 1 million LOC and more than
> 1000 packages/jars. It supports compilation of multiple
> languages, jars, ears, javadoc, certificate generation,
> deployment, backup routines, logging etc. Still it is
> quite simple, basically just one single file.
>
> The make syntax is not brilliant, but hard-to-read
> Makefiles is more due to common Makefile writing practice
> than the syntax itself.
>

"Jacob" <·····@yahoo.com> wrote in message
·····················@yahoo.com...
> Gisle S�lensminde wrote:
> > Make and shellscripts has little room for abstraction, so complex
systems
> > will be quite hard to maintain.
>
> We use an adopted version of http://geosoft.no/javamake.html
> for a baseline of more than 1 million LOC and more than
> 1000 packages/jars. It supports compilation of multiple
> languages, jars, ears, javadoc, certificate generation,
> deployment, backup routines, logging etc. Still it is
> quite simple, basically just one single file.
>
> The make syntax is not brilliant, but hard-to-read
> Makefiles is more due to common Makefile writing practice
> than the syntax itself.
>


Jacob,

Thanks for the link I will take a look

> And: More important than choosing build tools is to have a
> well organized development environment and clean build
> procedures.

I agree an organised dev environment and clean build procedure is essential
for creating a simple scalable build process but I am considering this as a
given. I want to examine the approaches that build tools like Make and ANT
take and compare them with, in this case a LISP managed approach.

Hoos.
From: Hussein Badakhchani
Subject: Re: building JAVA applications with LISP/SCHEME
Date: 
Message-ID: <1049128809.577866@ananke.eclipse.net.uk>
"Jacob" <·····@yahoo.com> wrote in message
·····················@yahoo.com...
> Gisle S�lensminde wrote:
> > Make and shellscripts has little room for abstraction, so complex
systems
> > will be quite hard to maintain.
>
> We use an adopted version of http://geosoft.no/javamake.html
> for a baseline of more than 1 million LOC and more than
> 1000 packages/jars. It supports compilation of multiple
> languages, jars, ears, javadoc, certificate generation,
> deployment, backup routines, logging etc. Still it is
> quite simple, basically just one single file.
>
> The make syntax is not brilliant, but hard-to-read
> Makefiles is more due to common Makefile writing practice
> than the syntax itself.


"Jacob" <·····@yahoo.com> wrote in message
·····················@yahoo.com...
> Gisle S�lensminde wrote:
> > Make and shellscripts has little room for abstraction, so complex
systems
> > will be quite hard to maintain.
>
> We use an adopted version of http://geosoft.no/javamake.html
> for a baseline of more than 1 million LOC and more than
> 1000 packages/jars. It supports compilation of multiple
> languages, jars, ears, javadoc, certificate generation,
> deployment, backup routines, logging etc. Still it is
> quite simple, basically just one single file.
>
> The make syntax is not brilliant, but hard-to-read
> Makefiles is more due to common Makefile writing practice
> than the syntax itself.
>


Jacob,

Thanks for the link I will take a look

> And: More important than choosing build tools is to have a
> well organized development environment and clean build
> procedures.

I agree an organised dev environment and clean build procedure is essential
for creating a simple scalable build process but I am considering this as a
given. I want to examine the approaches that build tools like Make and ANT
take and compare them with, in this case a LISP managed approach.

Hoos.
From: Pedro Pinto
Subject: Re: building JAVA applications with LISP/SCHEME
Date: 
Message-ID: <2ecbc75f.0303310909.15eb76fe@posting.google.com>
I have used the MzScheme make library and was quite happy with it. My
needs were simple though I got the feeling it would be easy to
accomodate more complex needs. Certainly easier than studying Make's
horrible sintax.

-pp



> Does anyone out there use LISP/SCHEME to manage the build process for there
> JAVA applications. I want to compare build tools and strategies for building
> and deploy JAVA and J2EE applications. I have plenty of information on Make
> and ANT but very little on LISP. I know that there are some people using
> LISP for this task and I want to understand the reasons for this choice.
> 
> (Please feel free to contact me directly as well as posting replys to the
> list).
> 
> Cheers Hoos.
From: Joe Marshall
Subject: Re: building JAVA applications with LISP/SCHEME
Date: 
Message-ID: <el4neg7i.fsf@ccs.neu.edu>
"Hussein Badakhchani" <····@email.com> writes:

> If this question is a off topic I apologise, please direct me to the correct
> news group.
> 
> Does anyone out there use LISP/SCHEME to manage the build process for their
> JAVA applications. 

At content integrity we coded up (in lisp) an ad-hoc system to compile
our java applets.  The reason was that there were several applets that
shared some code, and there were several environments that they needed
to run upon (signed CAB file for IE, signed JAR file for Netscape, Sun
Java on Unix, Sun or Microsoft Java on Windows).  The config
management was tricky.
From: Noel Welsh
Subject: Re: building JAVA applications with LISP/SCHEME
Date: 
Message-ID: <cdac2dde.0304010028.3b18957f@posting.google.com>
"Hussein Badakhchani" <····@email.com> wrote in message news:<·················@ananke.eclipse.net.uk>...
> Does anyone out there use LISP/SCHEME to manage the build process for there
> JAVA applications.

At LShift there is semi-internal project to build such a build system,
probably using SISC and Schelog.  The plan is to open-source it when
something is working.

Noel