ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jerry Huth <jerry.h...@Sun.COM>
Subject Re: The RIGHT Direction for ANT (was Re: Problem using script task)
Date Thu, 11 Jan 2001 20:45:31 GMT
Diane Holt wrote:
> Jerry,
> Can you give a (even semi-set) concrete example of what you'd envision the
> "template" files looking like? And what the generated build files would
> look like once they're generated? Also, maybe expand a bit more on how
> much flexibility you see the buildfile-generator having.

I'll post examples within the next few days.

> I have a complex compile situation (as most people here have become
> probably too familiar with :) I change the classpath from <javac> to
> <javac> within a single target (and I have lots of <javac> tasks in lots
> of "compile" targets). I also have to specify much of the order in which
> the java source gets compiled. There's no way I can think of to not have a
> human specify all of that, since there's really no pattern to any of it. I
> simply had to "walk the build" -- ie., find what seemed like a logical
> starting point, then start compiling and finding out what needed to come
> next, and next, and next, etc., etc. -- not fun, but there wasn't any
> other way to do it, since the build has to be very controlled about what
> gets compiled against jdk118 classes vs. some of jdk122 vs. some jdk13,
> and Java compilers go compile what they need when they need it, so I had
> to make sure it wasn't compiling anything that would pull in something
> else at the wrong point in (classpath) time (tricky, since it can be a
> rather long chain of pulled-in files, and the one at the very end, which
> could be very far down the chain, could be the one that ends up pulling in
> a file that requires a different classpath).

I had a similar situation a while back, although not on this scale.  I
had a module that was compiling with the modern compiler, but 5 of the
source files had to use the classic compiler.  In my case the 5 files
actually compiled with the modern compiler, but they didn't run correctly.
So, I made the build script compile all the files with the modern 
compiler, then delete the 5 .class files, then recompile with the 
classic compiler.  Since javac says it will never recompile a .java
file unless the .class file is older or missing, this worked.  In this
way I got around the problem of trying to figure out what the dependencies
were and what the order of compilation has to be.

This may work in your case, but only if your source files don't actually
crash any of the compilers or trigger bugs (such as incorrect error
messages) that may stop the compiler.

> At this point, I'd be happy to just have some way to not have to duplicate
> the entire <javac> task every time -- having a "template" task defined
> somewhere that specifies defaults, so I could then specify in the <javac>
> tasks only those things that need a value other than the default (which
> would probably only be <classpath> elements, and <include>/<exclude>'s).

I'll address this more when I post some examples.


> Diane
> --- Jerry Huth <jerry.huth@Sun.COM> wrote:
> > Jason Rosenberg wrote:
> > > In my experience, the "dependency-generator" program to which
> > > you refer is usually a manual process.  Assuming you have built up
> > > a workable build environment, the job of generating the build-sets
> > > and dependent deliverable modules, requires little overhead above
> > > and beyond writing the code itself for which dependencies you are
> > > trying to track.
> >
> >
> > Actually I wasn't talking about just dependency generation.  Maybe I
> > should have called the program I was referring to a "build script
> > generator".  What I'm talking about is a program that generates the
> > ANT files (or Make files).  I'm not talking about just automatically
> > generating dependencies.  I'm talking about automatically generating
> > the complete build scripts!  I'm talking about using MAKE or ANT for
> > all they're really good at: processing low-level computer-generated
> > dependency scripts!
> >
> > You can think of it as "smart templating": using a program rather than
> > static templates so that the generated build scripts can be extremely
> > complex (i.e. feature-rich) with a Constant time programming effort.
> >
> >
> > > So, frankly it is essential that the build environment is easy to work
> > > with, and has a set of features which make it easy to create the
> > > "dependency-reading" programs needed for each module.
> >
> >
> > Exactly:  Nothing is easier than using a program to automatically
> > create the build scripts.
> >
> >
> > > So, if I have a working template that builds Weblogic EJB's in my
> > > environment, for instance, then certainly, I don't want to have to
> > > painstakingly redefine the sequence of compiling and jarring and
> > > distributing the EJB individually, but rather, I want to reuse it.
> > > So, I create a template that knows how to build and jar and distribute
> > > my ejb's, knows how to clean up after them, knows how
> > > to update them from cvs, in a standard way.  This is all above
> > > and beyond the simple 'ejbjar' task that is currently an 'optional'
> > > task in Ant.  Because I can write a reusable template that
> > > knows for my environment where all the important classes
> > > are located (for setting the classpath), etc., the ability to
> > > have a reusable, customized procedure, really isn't asking
> > > for too much.
> > >
> > > Now, I simply declare that project X is an EJB, and my
> > > template now knows what to do with it.  That is the power
> > > of templating.
> >
> >
> > I know that simply adding a static template feature to ANT seems like
> > a great idea if all you've ever done before is written the ANT or MAKE
> > scripts manually (and honestly you are "on the right track" since you
> > intuitively understand that there is a better way than writing them by
> > hand).  However, the programming effort to go the next step and have a
> > separate program that completely generates the build scripts requires,
> > as I say, only a Constant time effort but is infinitely more powerful
> > than static templates.
> >
> >
> > > I have now done this, but it is rather ugly, since the process of
> > > creating reusable templates amounts to transferring the bulk
> > > of my Ant implementation to javascript code called from the
> > > <script> task.
> > >
> > > Your high-browed discussion of dependency-reading vs.
> > > dependency-generating programs is a bit off base, not sure
> > > if it has much of an audience in the real world.
> >
> >
> > Of course it depends which "real world" you're in.  The simple fact of
> > the matter is that companies with very large software projects
> > (millions or tens of millions of LOC's or more) simply do not use ANT
> > or MAKE directly.  They use generator programs such as I described.
> >
> > I didn't just make up my analysis of the effort required to develop
> > and maintain large software build systems; it came from my own
> > experience.  And in that experience I've found that it was easier to
> > work on very large software projects with a build script generator
> > program than on medium-sized projects using just ANT or MAKE.
> >
> >
> > > What is the big-"O" order for the job of writing software?
> > > If I write some new code, I also need to define how the
> > > software should be built, and how it should be deployed.
> > > This doesn't add significantly to the 'order'.  Especially,
> > > if the job of stating how to build the module is nothing
> > > more than labelling the project as (an ejb, a java package,
> > > a jsp page, or whatever).
> > >
> > > Templating is truly powerful, and I now see how great
> > > it can be, with my Ant/Javascript implementation.  This
> > > would have been a royal pain in the butt with Make.
> > >
> > > Probably the biggest flaw in your argument is to have
> > > lumped together Make and Ant as equivalents.  Ant
> > > is clearly much easier and much more powerful and
> > > much more portable than Make.  That's why Ant is
> > > attractive.  It has little to do with dependency tracking.
> >
> >
> > But this really gets to the heart of why you can't see my point.  When
> > you're in the forest one tree may look a lot bigger than another, but
> > when you're at 20,000 feet they're all just a bunch of toothpicks.
> >

View raw message