I'm using ant as my primary builder for a flex project in IntelliJ. Every time I build, IntelliJ runs the code analysis tool and finds a bunch of errors in my build file, which pops up the "Messages" window every time. Actually, the errors that it finds are complaining mostly about properties which are defined in a separate file, which it doesn't actually parse when running the analysis.
Edit: Additionally, I am making use of ant tasks which generate properties on the fly, which IntelliJ is unaware of.
Is there any way to turn off file inspection for ant build files during the build process?
That sounds weird. IDEA on the fly inspections which you get while editing the build.xml file should not pop-up when you actually build the project unless they are really errors and are reported by Ant to IDEA while the build file is executed.
IDEA can perform additional validation and report errors on Make for certain components (see Settings | Compiler | Validation), but it doesn't include Ant build files and is not triggered when you just run the Ant target.
If you don't want to see warnings from the Ant Messages Window, you need to toggle off the "Show All Messages" button.
If you don't want IDEA to analyze your build.xml file for errors, click the Hector icon in the status bar and disable the inspections per file by changing the highlighting level from the Inspections to Syntax.
Clarify the problem if it's not the case (knowing IDEA version would be also useful).
Does the .properties file exist, and is it in your CLASSPATH? IntelliJ is very smart about figuring that stuff out. When IntelliJ complains, I usually assume that I'm making a mistake. That posture usually gets me to a solution pretty quickly.
You can disable Ant plugin altogether. IDEA becomes quite slow on large Ant builds, so found this to be of help:
Crtl+Alt+S (for settings) -> Plugins -> Ant Support (uncheck)
Related
Currently I'm in the progress of updating TFS 2012 to 2013. My plan is to use the default build process template and stick to it, if possible. The existing build definitions use the old TFS method with TFSBuild.proj files. In thse proj files everything happens. Initializing the solution directory, build, clean, run unit test, drop files, etc. Compared to the 2013 build process template this is incorrect, since the workflow has activities for build, clean, run tests, drop files, etc. As well it seems that the targets file used in the TFSBuild.proj files is of a previous TFS version and hasn't been updated to a 2013 version.
The problem is that besides the build, clean, run test an drop files activities there are other activities needed. Version numbers are changed in certain files, obfuscation for dlls, check procedures if the source doesn't contain any unwanted files, zipping of pdb files, etc.
Of course it is possible to execute these tasks/activities with PowerShell scripts. On the other hand working with tasks in the a project file also seems logical. My concern with performing extra tasks in a project files is that TFS is running the activities for test, dropping files, etc. after calling the MSBuild activity.
Can someone point me in the right direction? Do I need custom developed activities that I can use in the build process template? Or is working with PowerShell scripts best practice?
I think you've answered your own question! Poweshell is the way forward!
I would say that modifying the XAML and writing a custom activity should only be considered if powershell isn't working for you, or if your scripts are becoming so big and difficult to debug that it makes sense to turn them in to code. As you mention, some of these tasks will need to be performed well after the MSbuild activity has completed so that's not going to work.
It looks like you want to do some fairly simple steps at defined points in the process and the powershell extensibility points are perfect for this.
A simple script for versioning in the pre-build step. Checking the source for unwanted files could happen here as well.
The obfuscation, zipping and copying stuff can happen post test.
From a Maintainability point of view, I would say that powershell has a much bigger user base than Windows Workflow and MSBuild so that's another advantage to this approach.
Is there an equivalent of the Eclipse "Project" menu "Clean..." command in the Dart Editor? If not, how can a project be cleaned of the files generated by the various tools?
Never heard of such a functionality in Dart.
What files of what tools? I guess from Run as JavaScript?
I guess the development goes in the direction that files are generated only in the build directory.
These files will be purged before rebuild.
But this is WIP.
I have the same question. However I am coming to this question with a suggestion. I would like people to consider the build model implemented by Apache Maven for Dart builds.
The nice thing about the maven model is that you can:
Define custom actions aside from the built-in ones.
Implement custom handlers for actions.
As for the clean action in Eclipse -- Add my vote for Dart Editor.
Eclipse normally use either Apache Ant or Apache Maven for build actions. 'Clean' is a standard action and found its way to the Build menu at a very early stage. Which gives me an idea;
Add some UI meta-management to the Dart Editor
Build tool = Current Dart build (default), OR user specified: Ant, Maven, ...
Build menu = Set standard actions, allow custom actions against the current build tool; e.g. a "database load".
I know with new frameworks and languages there's always more things to do that time to do it. There are probably better examples than just And or Maven. I'm just pondering some flexible options to make the Dart development environment a little "future proof". ;-)
i have this ant build.xml file with 3 targets in it:
target1, target2 and target3.
If the user simply runs ant and not an explicit ant target1 or something like that, i want to prompt the user asking which target he would like to call.
Remember, the user should only be prompted for this only if he doesnt explicitly call a target while running ant
Ant is not a programming language, it's a dependency matrix language. There's a big difference between the two.
In a program language, you can specify the absolute order of sequence. Plus, you have a lot more flexibility in doing things. In Ant, you don't specify the execution order. You specify various short how to build this steps and then specify their dependencies. Ant automatically will figure out the execution order needed.
It's one of the hardest things for developers to learn about Ant. I've seen too many times when developers try to force execution order and end up executing the same set of targets dozens of times over and over. I recently had a build her that took almost 10 minutes to build, and I rewrote the build.xml to produce the same build in under 2 minutes.
You could use <input/> to get the user input, then use <exec> or <java> to execute another Ant process to execute the requested target. However, this breaks the way Ant is suppose to work.
The default target should be the default target that developers would want to execute on a regular basis while they program. It should not clean the build. It should not run 10 minutes of testing. It should compile any changed files, and rebuild the war or jar. That's what I want about 99% of the time. The whole process takes 10 seconds.
I get really, really pissed when someone doesn't understand this. I hate it when I type ant and I get directions on how to execute my build. I get really irritated when the default target cleans out my previous compiles. And, I get filled with the deadly desire to pummel the person who wrote the damn build file with a large blunt object if I am prompted for something. That's because I will run Ant, do something else while the build happens, then come back to that command window when I think the build is done. Nothing makes me angrier to come back to a build only to find out it's sitting there waiting for me to tell it which target.
If you really, really need to do this. Use a shell script called build.sh. Don't futz with the build.xmlto do this because that affects development.
What you really need to do is teach everyone how to use Ant:
Ant will list user executable targets when you type in ant -p. This will list all targets, and their descriptions. If a target doesn't have a description, it won't list it. This is great for internal targets that a user shouldn't execute on their own. (For example, a target that merely does some sort of test to see if another target should execute). To make this work, make sure your targets have descriptions. I get angry when the person who wrote the Ant file puts a description for some minor target that I don't want, but forgets the description of the target I do want (like compile). Don't make David angry. You don't want to make David angry.
Use default target names for your group. That way, I know what targets do what across the entire project instead of one project using BUILD vs. build-programs vs. Compile vs build-my-stuff vs. StuffBuild. We standardized on Maven lifecycle names names. They're documented and there's no arguments or debates.
Do not use <ant/> or <antcall> to enforce build order. Do not divide your build.xml into a dozen separate build.xml programs. All of these probably break Ant's ability to build a target dependency matrix. Besides, many Ant tools that show dependency hierarchy in a build and they can't work across multiple build files.
Do not wrap your builds inside a shell script. If you do this, you're probably not understanding how builds work.
The build should not update any files in my working directory that were checked out by me. It shouldn't polute my working directory with all sorts of build artifacts spread out all over the place. It shouldn't do anything outside of the working directory (except maybe do some sort of deploy, but only when I run the deploy target). In fact, all build processing should take place in a sub-directory INSIDE my working directory. A clean should merely delete this one directory. Sometimes, this is called build, sometimes dist. I usually call it target because I've adopted Maven naming conventions.
Your build script should be a build script. It shouldn't do checkouts or updates -- at least not automatically. I know that if you use CruiseControl as a continuous build process, you have to have update and checkout functionality inside your build.xml. It's one of the reasons I now use Jenkins.
Sorry about this answer not necessarily being the one you're looking for. You didn't really state what you're doing with Ant. If you're doing builds, don't do what you're trying to do. If you're writing some sort of program, use a real programming language and not Ant.
An Ant build should typically finish in under a minute or two, and redoing a build because you changed a file shouldn't take more than 30 seconds. This is important to understand because I want to encourage my developers to build with Ant, and to use the same targets that my Jenkins server uses. That way, they can test out their build the same way my Jenkins server will do the official build.
you may use the input task provided by ant and make it your default target.
<input
message="Please enter Target ID (1,2 or 3):"
validargs="1,2,3"
addproperty="targetID"
/>
Use the value of this property to decide which target to execute.
From the ant documentation:
message : The Message which gets displayed to the user during the build run.
validargs: Comma separated String containing valid input arguments. If set, input task will reject any input not defined here.
You may pass any arguments according to your needs.
addproperty : The name of a property to be created from input.Behaviour is equal to property task which means that existing
properties cannot be overridden.
I'm trying to figure out how the DITA Open Toolkit performs DITA to XHTML conversions, and it's difficult since the process is managed by dozens of ant targets spread over multiple ant files.
I need a tool that can provide a visualization of the execution flow plus property dependencies of an ant invocation. VizAnt and Grand only graph target invocations, so I'm looking for something heavier-duty. Ideally, such a tool would identify the order of target invocations, as well as property values live at invocation, and properties, files, directories, classpath entries, etc. that are referenced in the body of a target.
My first thought was to manually graph it all in OmniGraffle, but the complexity quickly became unmanageable. Surely there's something more recent out there?
yWorks Ant Explorer is kind of cool.
Graphical representation of the ANT build targets and dependencies http://www.yworks.com/demos/images/ae1.jpg
Execute code through the GUI explorer of the ANT build file http://www.yworks.com/demos/images/ae3.jpg
Run it by executing the jar file: java -jar antexplorer.jar
It looks like yWorks no longer supports it and have removed it from their website. Links that used to go to Ant Explorer now just take you to their product listing page.
But there appear to be several places that have it available for download:
http://yworks-ant-explorer.software.informer.com/
http://webscripts.softpedia.com/script/Development-Scripts-js/yWorks-Ant-Explorer-29247.html
http://plugins.jetbrains.com/plugin/?idea&id=135
I have a vcproj file that includes a simple pre-build event along the lines of:
Helpertask.exe $(ProjectDir)
This works fine on developer PCs, but when the solution is built on our TFS 2008 build server under MSBuild, $(ProjectDir) is either blank or points to an unrelated folder on the server!
So far the best workaround I have managed is to hard code the developer and server paths instead:
if exist C:\DeveloperCode\MyProject HelperTask.exe C:\DeveloperCode\MyProject
if exist D:\BuildServerCode\MyProject HelperTask.exe D:\BuildServerCode\MyProject
This hack works in post-build steps but it doesn't work for a pre-build step (the Pre-build task now does nothing at all under MSBuild!)
Do you have any ideas for a fix or workaround? I have very little hair left!
$(MSBuildProjectDirectory) worked for me
I think your problem may be related to how items are initalized. An items include attribute is evaluated at the begining of a build. So if you depend on files that are created in the build process you must declare these as dynamic items. Dynamic items are those defined inside of a target, or by using the CreateItem task. I've detailed this on my blog MSBuild: Item and Property Evaluation.
Sayed Ibrahim Hashimi
My Book: Inside the Microsoft Build Engine : Using MSBuild and Team Foundation Build
I think the problem is that build server's workspace probably isn't initialized properly.
I just kept getting problems with this - I tried many different approaches but they all failed in mysterious ways.
Once $(ProjectDir) started behaving properly again, the pre-build step stopped executing the command (I added echo commands above and below it - they were both executed, but the program in between them was not. No errors or output of any kind were generated to indicate why it failed).
I don't know if this is a dodgy server of if MSBuild is having a laugh.
I've given up now. I gave the build server a big kick and have changed tack: We now run this tool offline (manually) and check in the results for the build server to use. So much for an automated build :-( If only MSBuild would run solutions in the same way as Visual Studio does - it's maddening that it sets up the environment completely differently (different paths coming out of the solution variables, ouptus redirected into different folders so you can't find them where they're supposed to be, etc)
I branched an existing project and $(ProjectDir) kept the old directory in the newly branched code. But that's because I had some compiling errors. Once every project in the solution compiled without errors, $(ProjectDir) changed to the correct path.
Carlos A Merighe