The small Ant library I have talked about before has undergone some changes and it has been polished up a little.
The <dotnetexec> task now works well on Linux if I place the assemblies somewhere arbitrary into my PATH, <nant> works like a charm, in particular this here
<ant:project xmlns:ant="antlib:org.apache.tools.ant"
xmlns="antlib:org.apache.tools.ant.taskdefs.optional.dotnet">
<nant>
<build>
<echo message="This is NAnt"/>
</build>
</nant>
</ant:project>
results in
Buildfile: /tmp/nant.xml
[nant] NAnt version 0.8.4 Copyright (C) 2001-2003 Gerry Shaw
[nant] http://nant.sourceforge.net
[nant] Buildfile: file://tmp/build2001946168.xml
[nant] [echo] This is NAnt
[nant] BUILD SUCCEEDED
[nant] Total time: 0.1 seconds.
BUILD SUCCESSFUL
which means, I've just run NAnt's <echo> task from within an Ant build file using Mono 0.28 on Linux. All that is required to do so is NAnt.exe in my PATH and dotnet.jar in my CLASSPATH (and a freshly bootstrapped CVS version of Ant).
The docs are online as well.
path: /en/Apache/Ant/dotnet | #
I've started to write some Ant tasks to improve Ant's .NET support even further (it already compiles C# or J# and does a couple of more development centric things). I started with a task that extends <exec> in a way that it should transparently invoke Mono if I point its executable attribute to my assembly on Linux - it still has some problems that are probably more due to Mono and my inexperience with it than with the task.
As a side effect and to test it, I've written <nant> and <msbuild> tasks that can invoke either build tool. So far only build file, targets and properties are supported, but I plan to support nested build file snippets in the future.
Right now you can use something like
<nant buildfile="src/nant.build">
<target name="echo"/>
<property name="foo" value="bar"/>
</nant>
but in the future one should be able to use
<nant>
<build>
<nunit2>
<test assemblyname="MyProject.Tests.dll"/>
</nunit2>
</build>
</nant>
to invoke NAnt's <nunit2> task. Ant would create a temporary build file with the snippet and run NAnt on it.
The <msbuild> task is complete speculation as I don't have access to MSBuild at all (I've written the task only from reading the command line reference) and the <nant> task fails on Linux unless I install NAnt and all related assemblies (they are in my PATH) in /usr/local/bin - there must be something wrong here, setting MONO_PATH doesn't help either.
The code can be found in the proposal/sandbox/dotnet directory in Ant's CVS module. The top in WebCVS is here.
path: /en/Apache/Ant/dotnet | #
Alex Kipman posts pointers to an online version of chapter 2 of Brent Rector's book.
The part talking about Ant and NAnt has been completely rewritten and now looks a lot nicer and more informed than the original version (search for the English language text under TLS347).
I'm sure Alex has played a significant role in this and want to thank him - as well as I want to thank Brent for reconsidering the section.
Brent's main point now is that Ant places the burden of timestamp based dependency tracking on task writers, I think I've addressed this already. I obviously still think that Ant's choice is the better one 8-)
The other point is about "build scripts" vs. "project manifest", that I'll have to think about a bit more.
path: /en/dotNet/msbuild | #
Steven Noels: Envy me.
Oh man, I do.
Unfortunately I couldn't make it to ApacheCon in Las Vegas, I certainly hope we'll have one in Europe next year. I also envy him for having the member T-Shirt and hope Erik will be able to pick up one for me.
path: /en/Apache/ApacheCon | #
During the past weeks we've been going back and forth about a way to make <macrodef> even more powerful and easier to grasp at the same time.
The implementation in 1.6betas so far has performed textual replacements for the attributes you have defined using the same syntax that Ant uses for property expansions - although they are no properties. There seem to be two solutions to this, really use properties or use a different syntax.
We haven't reached a decision yet, but it will almost certainly require a third beta, incompatible with the first two, before we can go to the final release.
Also on the table is local scoping for (special) properties as they are required if you want to replace certain <antcall> use-cases with <macrodef>. For example
<target name="check-and-fail">
<available classname="${class}" property="it-is-there"/>
<fail unless="it-is-there">Couldn't find ${class}</fail>
</target>
...
<antcall target="check-and-fail">
<param name="class" value="org.example.Foo"/>
</antcall>
<antcall target="check-and-fail">
<param name="class" value="org.example.Bar"/>
</antcall>
cannot be replaced with
<macrodef name="check-and-fail">
<attribute name="class"/>
<sequential>
<available classname="${class}" property="it-is-there"/>
<fail unless="it-is-there">Couldn't find ${class}</fail>
</sequential>
</macrodef>
<check-and-fail class="org.example.Foo"/>
<check-and-fail class="org.example.Bar"/>
as the first invocation could set the property and there is no way to change its value or reset it later. Each <antcall> in turn runs in an isolated context and cannot see the properties set by previous invocations.
path: /en/Apache/Ant | #
It has become a tradition for OpenBSD to create a song for each new release and include it as sound track on their CDs. Lyrics and MP3s are available online as well.
The song for 3.4, released about two weeks, ago covers OpenBSD's problems with DARPA from last year. And it features Theo de Raadt (founder of OpenBSD) as a background singer for the first time AFAIK.
I talk about sweets and Sankt Martin tradition in Germany and completely forget the most important part of it - no, not the fire, Weckmännchen.
Weckmännchen - that's what they are called in my part of Germany, they may have different names in other parts, I've heard Stutenmann at least once - are men (well gender has to be guessed) made of bread and may be covered by sugar or almonds. Very tasty, in particular with a nice thick layer of chocolate cream on top of it.
Here is a recipe and a nice picture for one. The pipe is definitively not optional.
path: /en/Germany/culture | #
Whenever I need a backtick or a tilde on my iBook, I have to press space after that to get the character I really want. I've been using X11 with a no-deadkeys keymaps for many years now and have never had any problems inserting the characters I needed manually as I rarely want to type é or similar characters at all.
By now I've created my own keymap file that I use via ~/.Xmodmap so at least for X applications I've solved the issue. Given that XEmacs's next-error function is bound to C-x ` this is a major improvement.
If you know how to disable deadkeys on a German keyboard for "normal" applications as well, please drop me a note.
St. Martin has been a Roman soldier who - according to the legend - shared half his coat with a beggar who would have died because of the cold otherwise. At the beginning of November we have lantern parades in Germany in memory of this legend.
Children create their own lanterns - usually out of paper - in school or kindergarten and at dusk they are lead through the streets of town by a man dressed up as a Roman soldier sitting on a horse singing lantern songs (the kids are supposed to be singing, not the horse) - with the help of brass bands.
After the parade, the kids will get bags of sweets and as that usually is not enough they'll go from house to house and sing to gain more sweets. Unlike Halloween they won't threaten people who don't want to give anything, although I remember songs like "Hier wohnt ein reicher Mann, der uns noch viel geben kann" - so it is better to open the door and donate 8-)
This year I'll have to attend three of such parades, the first one was last Saturday. Sarah was sick so I went with Florian and the lantern he has made in kindergarten last year. I'm looking forward to next Wednesday when Sarah will be with us, it's hard to top the light in the eyes a two year old when she sees all those colorful lanterns. It will also be the debut for Florian's new lantern.
I hope I'll get through this without catching a bad cold.
path: /en/Germany/culture | #
In Target Dependencies in MSBuild vs. Ant I claim that Ant's model was more powerful than the file name based approach taken by make and MSBuild's target inputs/outputs dependencies.
Let me give some reasons:
The name mangling performed by a task can be quite complex.
Let's take rmic as an example. If you use RMI over IIOP, it creates
a/b/c/_D_Stub.classfora/b/c/D.classifDis an interface. If you want to express this with patterns, you have to add full regular expression support to the core of your build system (or something similar), so users can specify (.*)([^/\.]+)\.class => \1_\2_Stub.class as a transformation rule.What's even worse than this IMHO, is that the user has to specify this transformation at all. With Ant's <rmic>, the user doesn't have to care for the name mangling rules.
Name mangling may depend on the value of an attribute.
Continuing with the rmic example, the above rules apply only if you use
iiop=true, otherwise it would be the same resulting class but without the leading underscore.If the user decides to switch from IIOP to JRMP as transport, she will also have to modify the pattern in the build file. No need to do so in Ant.
Name mangling may even depend on the content of the file.
Once again rmic. If you use IIOP and the class is a concrete class and not an interface, you get two files. One is
a/b/c/_D_Tie.classand an additional_Stubclass for the interface implemented byD.If you want to capture this upfront, you have to state the dependency explicitly. No pattern matching is going to work. You end up with one target per concrete class that way - and the user has to keep it up to date. Ant's rmic uses reflection on
Dto find the correct names.The same applies to source files generated from Corba IDL (in case Java's RMI is too esoteric). The file name of the generated source doesn't have to be related to the name of the IDL file at all. You can hard-code the file names or you can write a smart task for this purpose.
Name mangling depends on a concrete implementation of an abstract, vendor-neutral task.
Again rmic. Ant supports pluggable back-ends for this, and one of them is the rmic compiler of Weblogic which uses a different name mangling scheme. So the user will have to know which tool is going to be used and adapt the patterns in the build file to it. The same is true for <jspc> for example where the generated names depend on the container.
I understand that vendor-neutral tasks are not that important for MSBuild. ;-)
Non-local dependencies.
What if your source or target is a file reached via ftp or scp? Build ftp, WebDAV, ssh, cvs, VSS and what-not support into the core of the tool?
Non-file dependencies.
<jar> allows users to specify the manifest in-line.
The task reads the original manifest of an existing archive and compares it to the manifest it would create now. If they are different, the archive gets recreated. To achieve the same with file dependencies, the archiving target must use the build file itself as an input file - and may end up recreating the archive much more often than necessary.
What if you want to do something based on interactive user input?
Sometimes you want to get around dependency checking.
See Ant <copy>'s overwrite attribute for example, it will copy files even when the target is newer than the source.
Tasks that delete files.
How do you specify that the result of a target is the removal of input files?
Complex class dependencies
Say class
Aextends classBand they end up in two different assemblies. Now you changeB, changing its public or protected API, you should recompileAas well.Ant's <javac> doesn't catch this, neither can a simplistic input/output dependency. Possible solutions are (1) hard-coding the dependencies, creating targets for each such dependency. (2) write a smart task that removes the assembly that contains
A, this is what Ant's <depend> task does - see the previous point, how do you express this? (3) write an even smarter task that understands the programming language, sorts out what needs to be recompiled and then invokes the compiler, here it is for Ant and Java.
Like I previously said, you can create smart tasks in MSBuild as well. But if you start out with the target input/output checking in your build file, switching to smarter tasks may become a steep learning curve. You may even have to implement them yourself when the shipped tasks are not smart enough.
path: /en/dotNet/msbuild | #
John Lam doesn't like my usage of property files at the bottom of Conditions in MSBuild vs. Ant.
Well, I could have used
<xmlproperty file="${config}.xml" keepRoot="false"/>
instead. And what used to be
Optimze=false OutputPath=bin\\Debug\\ WarningLevel=1in
DEBUG.properties would become
<root> <Optimze>false</Optimize> <OutputPath>bin\Debug\</OutputPath> <WarningLevel>1</WarningLevel> </root>in
DEBUG.xml.
Better?
path: /en/Apache/Ant | #
If you should be reading Brent Rector's "Introducing Longhorn for Developers" by Microsoft Press that has been handed out at PDC apparently, make sure you also read what a Program Manager of Microsoft's Visual Studio Core Team says about the NAnt chapter.
Update: a revised version of the chapter is now online at MSDN and this will be the version that's going to appear in press.
path: /en/dotNet/msbuild | #
Last post on MSBuild for today, promised.
MSBuild supports something called Item. This is basically the same as a data-type with an id attribute in Ant. Its main use in MSBuild is to specify inputs and outputs of tasks and targets - in Ant the references are only used for task inputs.
While I don't like the inputs/outputs for Target too much, I think the idea to have a task accept a reference as input and provide its output as a reference is useful. For some tasks it may be difficult to calculate the output, if possible at all, but as a general concept this may work.
The input for tasks like <copy> could be some type of file-collection, as would be the output. Let's assume we want to copy some files and add those that we've just copied to an archive.
What we'd do with Ant now
<fileset id="templates" dir="styles">
<patternset id="template-patterns">
<include name="**/*.xsl"/>
</patternset>
</fileset>
<copy todir="${build}">
<fileset refid="templates"/>
</copy>
<zip destfile="files.zip">
<fileset dir="${build}">
<patternset refid="template-patterns"/>
</fileset>
</zip>
Let's assume all task can specify inputs (<copy> and <zip> would accept <fileset> among other things as inputs) and outputs via inputItems and outputItems attributes respectively. inputItems points to an existing project reference, outputItems creates such a reference.
Then we could write:
<fileset id="templates" dir="styles">
<include name="**/*.xsl"/>
</fileset>
<copy todir="${build}" inputItems="templates"
outputItems="copy-of-templates"/>
<zip destfile="files.zip" inputItems="copy-of-templates"/>
We could even create a special TaskContainer that magically connected the output of task n to the input of task n+1, avoiding temporary references like "copy-of-templates":
<fileset id="templates" dir="styles">
<include name="**/*.xsl"/>
</fileset>
<pipe>
<copy todir="${build}" inputItems="templates"/>
<zip destfile="files.zip"/>
</pipe>
Something that needs more thought, of course.
path: /en/dotNet/msbuild | #
MSBuild like NAnt allows conditions to be placed on all tasks, targets and the grouping elements for properties and items. Ant allows conditions on targets and a very small subset of tasks (basically <fail> and nothing else).
MSBuild and NAnt conditions can test for String (in)equality and file existence/absence. NAnt adds a couple of more conditions and supports boolean AND when multiple attributes are used. In Ant, the only condition you can test at the task/target level is whether a property has been set or not.
So Ant looks quite limited in comparison. Ant makes up for much of this via the condition task. With this, you can set properties based on conditions, those conditions can do all of the things that NAnt and MSBuild can do plus try to access HTTP URLs, connect to arbitrary sockets, compare file checksums, ... . On top of that, and/or/not are supported as boolean operations.
The Ant-Contrib project adds an <if> task that leverages Ant's condition framework, and I would rather add <if> to Ant than have all tasks support conditions. Otherwise you are going to repeat the same condition over and over again.
But then again, I've never had a build situation complex enough to ever use the <if> task (and I'm the author of it). The first example for conditionals you see in the MSBuild docs is
<PropertyGroup Condition="'$(Config)'== 'DEBUG'">
<Property Optimize = "false" />
<Property OutputPath = "bin\Debug\" />
<Property WarningLevel = "1" />
</PropertyGroup>
<PropertyGroup condition="'$(Config)'=='RETAIL'">
<Property Optimize = "true" />
<Property OutputPath = "bin\Release\" />
<Property WarningLevel = "4" />
</PropertyGroup>
in Ant, I'd use
<pre class="code">
<property file="${config}.properties"/>
</pre>
and two property files instead. YMMV.
path: /en/dotNet/msbuild | #
I should have opened the archives before I took them home. I don't have OpenOffice installed at home (and downloading it via my modem is no fun), so I couldn't read the docs that come as Word documents over the weekend.
In the meantime, Steve has had a first look at the docs as well. I agree with most of his points, but disagree on the target dependencies.
In Ant (and I think NAnt as well) targets depend on other targets, period. You declare the dependencies between targets and (N)Ant sorts out which targets to run in which order if you ask it to execute one.
In traditional make, you create files and those files depend on other files and you have rules that tell make how to build files from files. make will sort out which files to build when you tell it your "target" file. If your "target" cannot be expressed as a file, you need ".PHONY" targets, something that is the normal mode of operation in Ant.
This difference is one of the major stumbling blocks for people used to make when they come to Ant. All dependencies in Ant are "phony" and the file timestamp level dependencies are resolved by the tasks themselves. Ant doesn't avoid to run the target containing your compilation tasks by checking timestamps, it leaves this up to the <javac> task which looks at the timestamps.
Ant's model is more powerful1 as it allows tasks to perform smarter dependency checking that just looking at file timestamps. Like <zip> looking into the archive or <cc> parsing header files to calculate dependencies.
At the same time, it requires users to write a new task when all they need is a file-timestamp-checking on top of a target that performs a couple of operations. This is why we invented <apply> and <uptodate>. The former adds file dependency checking to <exec>, the latter sets a property that can be used in <target>'s if/unless attributes.
MSBuild supports both notions of dependencies. <Target> has a DependsOnTargets attribute that can be used in the way Ant's depends attribute works. In addition <Target> can specify its required inputs and the generated outputs. The inputs and outputs can be used by MSBuild to calculate the inter-target dependencies.
I'm not sure what happens when you use both dependency mechanisms together. It may lead to strange situations where the implicit dependencies and the ones stated explicitly in DependsOnTargets contradict each other.
Where Ant puts the burden of dependency checking onto the task writer, MSBuild does that in its core. Ant offers the functionality via utility classes, but the task writer still has to write the code herself.
MSBuild's model does not preclude smarter dependency checking in tasks (this is where I disagree with Steve), but it buries it under the more traditional make like dependency mechanism. I wonder whether for example the compilation tasks perform any file timestamp comparisons at all, the docs are not clear, but from my reading of the walk-through, I'd say they don't. In "Add dependency analysis to 301" they avoid recompilation in CSC by adding Inputs/Outputs to the Target containing the Task.
Supporting both types of dependencies inside MSBuild may be confusing to users. In the end I'd guess only one will survive and the other mechanism will become more or less unused. As it is probably easier to write a task without task-internal dependency checking, this may lead to "dumber" tasks than their (N)Ant counterparts.
If you wanted to write a Zip task that adds all files to an archive that are not already part of it (or are newer than the files inside of the archive) without making the task perform the tests, you'll end up with an incredibly complex dependency engine in the MSBuild core, though. Looking at the file name transformations that they already have to support now (prepend a directory, change the extension, ...), this is asking for trouble IMHO.
path: /en/dotNet/msbuild | #