Re: [Beanshell-dev] Build file for BeanShel

Alexey Zinger <inline_four-/[email protected]> Tue, 1 Feb 2005 12:36:42 -0800 (PST)
Newsgroups gmane.comp.java.beanshell.user,gmane.comp.java.beanshell.devel
Message-ID <[email protected]>
Lemme prepend my answers with saying that I haven't tried your tool yet.  I'm
just going on what I've gathered so far, so I may be entirely wrong.

> 1. It is way to verbose.

Ant's output can be controlled externally.  The main ways to do it is through
-debug and -verbose keys.  Also, each command may or may not respect some log4j
verbosity settings.  I haven't looked into it.

> 2. You cannot build C++ projects with Ant.  I know there are people who 
> have tried and I've seen the plugins. To build a C++ project you need to 
> iterate through a list of files performing an operation on each one.  I 
> have yet to see Ant to such a thing.  Yes I could write a plugin to do 
> this and I could also alter the trunk of my car to haul dirt, but what I 
> really need is a truck.

To be honest, I haven't done it, but it was always my understanding that
generic tasks such as copy, zip, touch and so on would do the job no matter
what type of project, which was why I really liked Ant and always thought of it
as being flexible enough for anything.  It was always my assumption that if I
couldn't make it do something with regular commands or through ecaplsulating
some logic in a reusable task that took some parameters and translated it into
external exec calls, I could always write my own commands.  Granted, that would
require ensuring new tags were installed on the system in question, but writing
my own build tool wouldn't help with that particular problem, as it would have
to be installed itself.

> 3. Ant builds are based on tasks and not file dependencies.  Using file 
> dependencies is much more powerful.  If the project is up to date and 
> you try to build it, it should do nothing.

Couldn't you easily write a command that worked on filesets?  That concept
already exists in ant and you'd just have to use the write API in your command
code to easily step through the contents of a fileset object.  If you want a
generic one, you could write a loop command that accepted a fileset object and
some parameters to be able to make an antcall thereby calling your own task in
the project.  So you could define the body of the loop in a separate task from
the generic loop command.

> 4. Flexibility.  In order to get ant to do anything out of the ordinary 
> I have to write a new task plugin.  Then I have to make sure that 
> whoever is building my project has that plugin.

Same holds true for writing your very own build tool -- you have to install it.
 I do want to point out that ant allows you to make external exec calls right
out of the box, which can be used to call external programs to perform
operations not necessarily defined in any commands.

> 5. Lack of procedural constructs.  I would like to put some common 
> functionality in a method somewhere and call it from various places in 
> the build file.  Ant can't do that.  But wait you can use BeanShell in 
> ant using the BSF.  I say drop the Ant and keep the scripting language.

What about defining a task that accepts parameters?  You can then reuse that
task within the project.  Granted, you would have to stick that task in every
project if you wanted to reuse it in other projects, but that's where maven
comes in.  I myself never felt I needed maven, but it has lots of interesting
features and is considered an evolution of ant, so everything I've said above
holds true for it.

--- Brian Hawkins <brianhks-BYHubErIwDGZvNlLnfxc/[email protected]> wrote:

> This is a good question.  I defiantly feel that ant is insufficient.
> 
> Problems with Ant
> 1. It is way to verbose.
> 2. You cannot build C++ projects with Ant.  I know there are people who 
> have tried and I've seen the plugins. To build a C++ project you need to 
> iterate through a list of files performing an operation on each one.  I 
> have yet to see Ant to such a thing.  Yes I could write a plugin to do 
> this and I could also alter the trunk of my car to haul dirt, but what I 
> really need is a truck.
> 3. Ant builds are based on tasks and not file dependencies.  Using file 
> dependencies is much more powerful.  If the project is up to date and 
> you try to build it, it should do nothing.
> 4. Flexibility.  In order to get ant to do anything out of the ordinary 
> I have to write a new task plugin.  Then I have to make sure that 
> whoever is building my project has that plugin.
> 5. Lack of procedural constructs.  I would like to put some common 
> functionality in a method somewhere and call it from various places in 
> the build file.  Ant can't do that.  But wait you can use BeanShell in 
> ant using the BSF.  I say drop the Ant and keep the scripting language.
> 
> Yes my build file is structurally similar to the ant build file, but I 
> believe it to be functionally superior.  Here is an example.  Touch one 
> of the script files in the src/bsh/commands directory and then run the 
> distribute target with CPMake. and this is the output:
> Copied 1 files to classes/bsh/commands
> Creating dist/bsh-2.0b2.jar
> Creating docs\manual\bshcommands-bshdoc.xml
> Creating dist/bsh-2.0b2-src.jar
> Build time: 00:00:09
> 
> It built only what needed to be built.
> Now touch the file again and run "ant dist".  It pretty much recreates 
> the whole world.
> 
> Now for another test.  Rerun the cpmake command without touching the 
> file and you get this:
> Build time: 00:00:04
> 
> It knew that nothing needed to be done.  Ant pretty much does what it 
> did before.
> 
> And its not like my error messages aren't long enough without ant 
> prepending on the task tag for me.
> 
> Ant was developed to solve one problem.  Compile java programs.  Because 
> the only other solution at the time was GNU make and it does a horrible 
> job of java projects.  People have tried to work with it (out of sheer 
> desperation) to make it build other things besides java code, but it is 
> the wrong tool for the job.
> 
> I also developed CPMake to solve one problem.  "I want to build 
> anything".  I must admit that 90% of the coolness in CPMake is not what 
> I wrote, but the power of utilizing really awesome scripting languages 
> like BeanShell.
> 
> So do you agree with me or am I just full of hot air.  I honestly do not 
> care if you think I'm on a drug trip, but I want to know why you think 
> that way.  Is CPMake lacking somewhere?  If it is I'll fix it, because 
> I'm hell bent on making it the coolest make utility on the planet.
> 
> Thanks
> Brian
> 
> Alexey Zinger wrote:
> 
> >I presume you felt ant was not enough.  Did you try writing custom tags for
> it?
> > It doesn't seem like your build file is structurally different than what
> you'd
> >write with ant.
> >
> >--- Brian Hawkins <brianhks-BYHubErIwDGZvNlLnfxc/[email protected]> wrote:
> >
> >  
> >
> >>Being frustrated with the lack of flexibility of current make systems I 
> >>developed my own.  CPMake is written in Java and the build scripts can 
> >>be written in BeanShell.
> >>I would like to get some more feedback on this project so I have written 
> >>a build script for building BeanShell.  See the attached file.  Save 
> >>this file to the root of the BeanShell project and then download the 
> >>file cpmake_bsh.jar from the cpmake web site www.cpmake.org.  This file 
> >>has the cpmake binaries and the BeanShell 1.3 interpreter in it.
> >>
> >>You can then build BeanShell by running "java -jar cpmake_bsh.jar <target>"
> >>
> >>To keep from cluttering up this list with feedback you can send email 
> >>directly to me or use the mail list on sourceforge for cpmake.
> >>
> >>Thanks in advance
> >>
> >>Brian
> >>    
> >>
> >
> >=====
> >Alexey
> >Briggs & Stratton
> >1988 Kawasaki EX500 (CCS)
> >http://bsheet.sourceforge.net
> >
> >
> >		
> >__________________________________ 
> >Do you Yahoo!? 
> >The all-new My Yahoo! - What will yours do?
> >http://my.yahoo.com 
> >
> >
> >-------------------------------------------------------
> >This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
> >Tool for open source databases. Create drag-&-drop reports. Save time
> >by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
> >Download a FREE copy at http://www.intelliview.com/go/osdn_nl
> >_______________________________________________
> >Beanshell-developers mailing list
> >Beanshell-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> >https://lists.sourceforge.net/lists/listinfo/beanshell-developers
> >
> >  
> >
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
> Tool for open source databases. Create drag-&-drop reports. Save time
> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
> Download a FREE copy at http://www.intelliview.com/go/osdn_nl
> _______________________________________________
> Beanshell-developers mailing list
> Beanshell-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/beanshell-developers
> 


=====
Alexey
Briggs & Stratton
1988 Kawasaki EX500 (CCS)
http://bsheet.sourceforge.net


		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - now with 250MB free storage. Learn more.
http://info.mail.yahoo.com/mail_250


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl