|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 34
Messages: 34
Messages: 34
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
Ant and XML Build Files
James Duncan Davidson, the creator of Ant, has written about the very beginnings of the project. This history lesson shows us how Ant started out with properties files, and grew to XML... and how in many ways he wished it hadn't.In retrospect, and many years later, XML probably wasn't as good a choice as it seemed at the time. I have now seen build files that are hundreds, and even thousands, of lines long and, at those sizes, it turns out that XML isn't quite as friendly a format to edit as I had hoped for. As well, when you mix XML and the interesting reflection based internals of Ant that provide easy extensibility with your own tasks, you end up with an environment which gives you quite a bit of power and flexibility of a scripting language—but with a whole lot of headache in trying to express that flexibility with angle brackets. Read James Duncan Davidson in Ant and XML Build Files
|
|
|
Message #116174
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Ant and XML Build Files
Looks like Ant is just a copy of MSBuild Just like Java is a rip off C#...
|
|
|
Message #116182
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
not really an XML problem
The problem is big complex configuration files are just big
and complex. The format isn't going to make any significant
difference past a certain point of complexity. You really
need a GUI to manage a complex configuration. Simple things
are fine in an editor. Write the same thing in properties
or s expressions. Still horribly complex to a poor
person armed only with a text editor.
|
|
|
Message #116185
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Ant and XML Build Files
Boy is he right. I'm starting to get disgusted by XML already because it is used so much everywhere -- whether it fits the purpose or not. I'm glad I'm not alone to ask "Why?". Some things that never made sense to me:
- XML databases. I don't know why I'd store my data in such an inefficient way.
- XML to "program" something. Just think of the syntactical overhead of a loop or a conditional, in comparison to a foreach loop or an "if" in real programming languges. Tedious.
- parts of the same software system, all from he same vendor, communicate in XML. Hello?!
- XML config files instead of "*.properties", with a few dozens of options
- an amusing one: transforming database data to an XML format, then with XSLT to another, with the info finally winding up in HTML. Sheesh.
Most of these examples taken from our current project! Long live efficiency...
To me, the sensible advantages of XML are (1) it can be a good common communication format BETWEEN different software vendors or platforms, and (2) when (and only when) it must be externally represented, like the XML hierarchical diagrams in XMLSpy. But these are like UFOs to me, never actually seen XML used for these purposes. I know, I haven't been in the business as long as some others :-)
YMMV. I'd actually be happy to read a good use case!
Regards.
|
|
|
Message #116193
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
This has to be an april fools joke
although changing the file format from XML to some sort of script language might "make" sense.
|
|
|
Message #116204
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Ant and XML Build Files
When I was learning Ant I felt that XML is a little bit cumbersome and not very appropriate for Ant files.
I talked with a few people about that impression and started a thread about this topic in a forum. But many people didn't share my opinion in this respect.
So I am very happy that the creator of Ant wrote that XML was not the best choice at that time!
There are not many people who are self-critical. Respect!
How can you debug an Ant file? As soon as someone asks himself this question, he can easily recognize that XML is not the best format for Ant files. Just my opinion.
|
|
|
Message #116227
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Ant and XML Build Files
XML is easy to parse with "standard" parsers, I think it made XML popular for scripting, but probably it is better to learn to code parsers than to use XML for evrything (biuld scripts is not an exception too).
|
|
|
Message #116228
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Tools need GUI's to expose complexity and increase productivity
The one thing that continually strikes me about the java open source tools space is how many of these products are launched without a competent GUI.
In fact I've met a number of otherwise reasonable authorities who suggest that it's somehow "un-manly" to use a GUI wrapper, or that it's "not for real programmers".
Such views are perverse for a couple of reasons.
A capable GUI wrapper can complement the underlying tool by exposing its power through masking the implementation complexities. This leaves the developer to concentrate on solving the business/process problem rather than worrying about a particular syntax. With a strong GUI shell who cares whether its XML or whatever?!?
It can substantilly improve productivity. A competent GUI allows the job to be completed quicker, reduces the skill threshold, and allows problems to be spotted sooner. With the current trend of moving jobs offshore this point should be on everybodies agenda!
|
|
|
Message #116250
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java VM is rip off UCSD-P system
Chameleon: JMV is a rip off of UCSD-p system from > 10 years back.
Yup, and the UCSD-p system is a straight rip of the Turing Machine.
That took balls to take that one and not acknowledge it ;-)
Peace,
Cameron Purdy
Tangosol, Inc.
Coherence: Clustered JCache for Grid Computing!
|
|
|
Message #116288
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Tools need GUI's to expose complexity and increase productivity
I think there are times when a GUI is faster and times when a config file is faster. Once you cross a certain complexity threshold, GUIs actually slow down the process of working with things. If that weren't the case, WYSIWYG builders for applications would be a lot more useful than they are today. I think there is a place for a GUI when first learning to work with a particular kind of system (e.g, Java Swing programming), but once you understand what's going on, a GUI just gets in the way. Not in all cases, but in a lot. Also, I think that the reason a lot of open source projects don't have GUIs is because a good GUI is hard to write. I'd prefer, for example, that Hibernate concentrate on its core functionality than spend resources perfecting a GUI that might or might not see use.
I think personally that there's a place for both. Just as in the OS world, I prefer a combination of command line and GUI control, I prefer a combination of direct coding and GUI control. A GUI is great for helping to manage complexity, but if something can't be done outside of a GUI, there are severe limitations. Consider, for example, trying to manage a website using just notepad. You'd be foolish, because you need something like an IDE to manage complexity. Consider also trying to edit an HTML file to change a style. You could open it up in a text editor and make the change really quickly with a search and replace, or you could go into the GUI and find a properties window somewhere for each instance of a control that you want to change the style on. There's a strong case for both.
I certainly don't think that a GUI alone can do everything, and when dealing with things like deployment configurations, I think GUIs can just get in the way.
|
|
|
Message #116320
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Ant and XML Build Files
It seems I continually find myself on the wrong side of fashion.... :-(
I was having this same discussion the other day with someone (check out his fish!). I think Ant - and even Jelly are a good compromise for build systems.
Why?
Because its mostly declarative - not programmatic.
Consider:
<copy file="bongo.jar" todir="bollocks/lib" overwrite="false"/>
Looking past the (often exaggerated) angle-brackets aspect of readability, it is very clear what this is going to do - even if you have never seen Ant before. It is very brief and very unambigious.
I would be keen to see suggestions on how this could be done clearer in Python or Ruby. Or even Groovy.
Where ant starts to fall apart is when you want to do a load of conditional or iteration or more programmatic tasks. At that point, you want to write your own tags - and defer to a proper programming language. I dont thinke enough people do this. I dont know why.
The other place where Ant falls apart (referred to in the article) is when you have a large project - or many subprojects. The verbosity of Ant (and monotonous repetition of tasks) makes it a sea of text that, regardless of the angle-brackets, would make it difficult to read. (anyone tried reading a 6000-line java file?)
Here, Maven and Centipede have tried to address this by factoring out common tasks. With the Maven project.xml, you are back to a purely declarative approach that is very readable and maintainable...
-Nick
|
|
|
Message #116364
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Ant and XML Build Files
First I'd like to say:
OMG! So I'm not the only one who's been extremely annoyed by Ant XML config files. I actually suggested to one of my team mates, a couple of weeks ago, that we develop a custom domain-specific language (DSL) for Ant, because the config files were such a PITA. Moving along...Consider:
<copy file="bongo.jar" todir="bollocks/lib" overwrite="false"/>
Looking past the (often exaggerated) angle-brackets aspect of readability, it is very clear what this is going to do - even if you have never seen Ant before. It is very brief and very unambigious.
I would be keen to see suggestions on how this could be done clearer in Python or Ruby. Or even Groovy. I think the reason you see this as readable, is because element attributes are named. If the Ant DSL had named parameters (like many other languages - for example, Smalltalk), this would be just as readable:
copy( file="bongo.jar", todir="bollocks/lib", overwrite="true" );
And with a DSL, people could easily provide their own higher level abstractions complete with control flow if necessary.
God bless,
-Toby Reyelts
|
|
|
Message #116392
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Disagree: XML is fine for very large projects.
While I agree that build scripts can get out of hand quickly, I don't agree that this is amplified by the use of xml. This is the fault of some strategically placed documentation with ill advice, and lack of planning on behalf of whomever create the script.
In perusing the documentation available for ant, I've noticed advice about global targets and calls to other scripts which make maintenance a nightmare. The focus seems to be on getting the project build where half the thought should be given to future changes. Stop considering the overall organization of the script and you will pay for it later.
You can create a generic script which tackles the various types of Java deployments- application, applet, webstart app, war, ejb, ear, sar, etc - and allows the incorporation of other build facilities such as torque, without things getting out of hand and without restricting yourself. It's slower than slapping a build.xml file together and letting it evolve without regard, but much more enjoyable to work with and faster in the long run.
Here are some basic ideas:
1) Break the script into logical files using XML entity imports.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE project [
<!ENTITY general SYSTEM "file:../../Build/general.xml">
<!ENTITY library SYSTEM "file:../../Build/library.xml">
<!ENTITY cvs SYSTEM "file:../../Build/cvs.xml">
<!ENTITY j2ee SYSTEM "file:../../Build/j2ee.xml">
<!ENTITY format SYSTEM "file:../../Build/format.xml">
<!ENTITY servers SYSTEM "file:../../Build/servers.xml">
<!ENTITY testing SYSTEM "file:../../Build/testing.xml">
<!ENTITY xml SYSTEM "file:../../Build/xml.xml">
<!ENTITY application SYSTEM "file:../../Build/application.xml"> ]>
<!--======================================================================
Main build targets and project specific information.
=======================================================================-->
<project basedir=".." default="nightly" name="ProjectName">
<!-- ==================================================================
What to deploy when we say deploy
====================================================================-->
<target name="deploy.all" depends="deploy.ear, deploy.test">
</target>
&general;
&library;
&cvs;
&j2ee;
&format;
&metrics;
&servers;
&testing;
&xml;
&application;
</project>
Each referenced file keeps targets, taskdefs, and classpaths that directly relate to the file - e.g., the compile.ejb target is in j2ee.xml.
2) make an accompanying .properties file for each .xml file. Have the .xml import the .properties, and keep your key names consistent.
3) Keep your project specific files in a separate location from the generic build scripts. This include files which contain classpaths for each type of compile, settings for filters, names of ftp servers to post reports to, etc. If you believe the generic script sections will get used elsewhere and prepare for it, it will happen and other people will get it when you explain the intent.
Since I've started this effort, I've never used another script on development efforts I've worked on. All of my changes to accomodate the new project have stayed within a file called localproject.properties for my development and project.properties for the nightly builds.
So James might have seen some cases where the build became quite a mess, but it's no more the fault of the his choice of xml than a messy playroom is the fault of a particular type of plastic. Kid's are just messy.
|
|
|
Message #116422
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Ant and XML Build Files
Because its mostly declarative - not programmatic.Consider:<copy file="bongo.jar" todir="bollocks/lib" overwrite="false"/>Looking past the (often exaggerated) angle-brackets aspect of readability, it is very clear what this is going to do - even if you have never seen Ant before. It is very brief and very unambigious.I would be keen to see suggestions on how this could be done clearer in Python or Ruby. Or even Groovy. You need to see the big picture, not just a single example.
In most cases targets are called from another targets with "depends". This is not declarative for me, but programmatic. int a = 0 is also declarative for you? Is this an argument that Java should better use XML? There are many other programmatic features of Ant build files.
How do you want to debug a Ant script? If Ant build scripts were written in Java, this would be possible. It would also be possible to detect many bugs at compile time and not later at runtime. How do you want to write a productive JUnit test for your Ant scripts?
When someone learns Ant, he has to learn that pseudo Ant script which is hidden in a declarative XML format. In order to write build files one must learn the declarative and programmatic aspects of Ant. Its in no practical case enough to learn only the declarative part of Ant.
For example XHTML is very good for its purpose because its 99% declarative. Programmatic things are done with JavaScript. There is a clean separation: XHTML for the declarative things, JavaScript for the programmatic. Now try to separate that in Ant build files! Would not make sense. If it is such a mixture, then it is a sign that XML is not such a good choice for it.
Of course XML has the advantage that someone must not learn a programming script in order to use it. On the other side, he must learn the programmatic part of Ant, which decreases this advantage a little bit. But I doubt that this advantage is practical. I believe that 99% of the people who use Ant are programmers. Maybe only 1% of the Ant script writers are system administrators with no programming knowledge. So even if it is an advantage in this respect, its only an advantage to 1% of the Ant users.
|
|
|
Message #116436
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Ant and XML Build Files
1. It's clear that if/else and try/finally constructs being written imply Ant has stepped over the line from good design to copying language constructs. However, I don't know if this implies that using a scripting language is that natural evolution. It might just mean that more needs to be done in task classes and not in build XML, or just better designed build files.
2. I don't see how tasks dependencies are better defined programmatically rather than declaratively. Doing it programmatically requires writing code that executes the tasks in order based on dependency. Do you really care what order they get executed, as long as tasks A & B get done before F? If I were to do this in scripting form, many of my targets would be methods and depends would become metadata of the method.
|
|
|
Message #116518
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Tools need GUI's to expose complexity and increase productivity
I agree with Drew. There is time and place for GUI tools and for plain text editing. There are times when you need a convenient GUI – e.g. to quickly write, validate or transform a large XML document with some XML editor, or analyze java structure of the project with SA4J. At the same time it is often advantageous to be able to edit the same source file (especially XML-based) with a plain text editor. Having no choice but to use the vendor-given GUI per task is not a good thing. Back to Ant, I find Intellij and Jbuilder support of Ant quite good.
About the article:
I always missed some sort of scripting language in Ant for control flow. It’s not needed in 90% of cases, but would really help in those rare but crutial 10%. Still, if such scripting language had been available, I think, we would have seen it abused not less as XML is.
Kris Bravo: This is the fault of some strategically placed documentation with ill advice...
:-) The Ant Developer Handbook (Sams) and the Java Development with Ant (Manning) suggest, for example, different approaches to <antcall> task. The former recommend using it instead of “depends” because it facilitates modularization, the latter says that it’s better to let Ant figure out the target dependencies by providing the “depends” info. Well, we have room for experiment :)
|
|
|
Message #116543
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Ant and XML Build Files
If Ant build scripts were written in Java, this would be possible And how would you build the build scripts? :-)This is not declarative for me I agree with you that ant scripts are not 100% declarative. I guess that is why they are called "scripts" - and I guess thats why also I said they are mostly declarative. Even "depends" is mainly declarative.You need to see the big picture, not just a single example Apart from being a little condescending here, you have a point. At the individual task level, ant is mostly declarative. However, unless you follow some build-script styles to avoid it, the relationship between the tasks that make up a project build is lost in the details of the task implementation.
However, as I pointed out, this is not really to do with XML per se - but a lack of abstraction.
Projects sich as Maven and Centipede seek to get a higher level of abstraction - where you have a seperation between the project build and the individual task implementation. You can do the same with ant by yourself if you follow some rules.
a) Dont use "depends" for any of your target definitions.
b) Instead, write higher-level targets that wire the lower level tasks together.
There are a number of advantages to this:
Not using "depends" makes your scripts much easier to debug.
Not hard-coding your dependancies into the individual targets makes your build script more flexible - as the dependancies you want for development are very different to thos you want, say, for your overnight build - or even your cruisecontrol build.
-Nick
|
|
|
Message #156714
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Run command from ant
Can anybody please tell me how to run a command from ant.
I need to run the following command:
jad -r [-d<directory_for_sources>] [<other_options>] <directory_with_classes>**/*.class
Thanks
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
Reza Rahman explores the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(November 2, Article)
SAML is an XML-based standard for exchanging authentication and authorization data between security domains. The single most important problem that SAML was created to solve is the Web browser Single Sign-On problem. Many organizations are debating whether to stay with version 1.1 or move to 2.0. This article makes observations about both options.
(September 28, Article)
Joe Ottinger takes a look at how people learn, and applies it to the practice of programming. He notes that understanding how people learn is an essential part of working in a programming team.
(September 22, Article)
Stephen Maryka gave us an article about the Asynchronous Web and posed a number of questions that get examined like an approach to delivering Asynchronous Web capabilities through extensions to existing Java EE technologies.
(July 14, Article)
JavaServer Faces Flex goal is to provide users capability in creating standard Flex components, part of flexSDK which is open sourced through MPL license, as normal JSF components. This article by Ji Hoon Kim will provide an overview of creating a simple multilingual JSF page consisting of JSF Flex tags.
(June 29, Article)
In this session Jeff explores the key characteristics of successful SOA projects. He covers some of the patterns, and anti-patterns, tool sets, and strategies that he himself learned the hard way. Last, he provides a strategy and blueprint for achieving a high likelihood of success in your SOA project.
(June 23, Tech Talk)
Ari Zilka, CTO of Terracotta, Inc., talks about the new features in Terracotta 3.1, announced during JavaOne and available now.
(June 15, Tech Talk)
In this Tech Talk, Josh Long explores an integration challenge using Spring Integration and walks through the implementation, employing and expanding on the basic patterns of Enterprise Application Integration to tie together components into a function integration solution, and then demonstrates how Spring Integration helps address the integration requirements.
(June 15, Tech Talk)
In this Tech Talk, David Geary teaches you: The basics of Google Web Toolkit; How to implement Ajax-enabled applications in Java; Internationalization; Hooking into the browser history mechanism; Remote procedure calls.
(June 4, Tech Talk)
Jon Kern discusses the best architecture/technical solutions and ensure that they are repeated by all developers. By tackling the architecture up-front in a serial manner, subsequent parallel development will be much more manageable and predictable.
(May 28, Tech Talk)
This keynote describes the frustrations of modern knowledge workers in their quest to actually get some work done, and solutions for how to guard yourself against all those distractions. Neal Ford talks about environments, coding, acceleration, automation, and avoiding repetition as ways to defeat the misguided attempts to sap your ability to produce good work.
(May 26, Tech Talk)
Gil demonstrates how new, aggressive uses of already abundant compute capacity by common applications offer competitive value for application designers.
(May 21, Tech Talk)
Chris Keene introduces WaveMaker as a new way to automate the ability to generate Hibernate classes in order to more quickly bring OR mapping into an application.
(May 19, Article)
In this session Nati Shalom demonstrates how to take a standard Java EE web application and scale it out or down dynamically without changes to the application code. Seeing as most web applications are over-provisioned to meet infrequent peak loads, this is a dramatic change because it enables growing your application as needed, when needed, without paying for unutilized resources.
(May 19, Tech Talk)
Download the entire book of Jakarta-Struts Live and learn about Struts MVC, Tiles, the Validator, DynaActionForms, plug-ins, internationalization, and more.
(Book PDF Download)
The Application Server Matrix is a detailed listing of J2EE vendors and their application server products, with information on latest version numbers, J2EE spec support and licensing, pricing, platform support, and links to product downloads and reviews.
(Application Server Comparison Matrix)
|
|
