Android has an ant script file with generic targets for compile, clean, etc.
Are there any open source ant scripts that define standard targets such as these for general java projects?
I don't want to bother installing and using maven, but I also don't want to bother creating and maintaining ant scripts for each project.
I'm guessing you are new to both Maven and Ant. If I'm wrong you can ignore the rest of this post :)
I don't know of any generic open source Ant files. I've never had the need to look for one. I think its well worth the effort to learn Ant and create your own generic script. Ant is easy to learn and it is a very flexible, powerful and reliable build tool. You'll find it quite easy to create a build file that you can reuse over and over again on different projects.
With regards to having to maintain Ant scripts, its a bit of a fallacy. You'll find that once you've got a script that works in a generic way you'll hardly ever have to touch it again except when you need to do things in a custom way (usually around packaging and deployment). When that happens, you'll be glad you're using a tool like Ant that gives you the flexibility to do what you want to be able to do without getting in your way.
Related
So, at work, I frequently have to create virtually identical ant scripts. Basically the application we provide to our clients is designed to be easily extensible, and we offer a service of designing and creating custom modules for it. Because of the complexity of our application, with lots of cross dependencies, I tend to develop the module within our core dev environment, compile it using IntelliJ, and then run a basic ant script that does the following tasks:
1) Clean build directory
2) Create build directory and directory hierarchy based on package paths.
3) Copy class files (and source files to a separate sources directory).
4) Jar it up.
The thing is, to do this I need to go through the script line by line and change a bunch of property names, so it works for the new use case. I also save all the scripts in case I need to go back to them.
This isn't the worst thing in the world, but I'm always looking for a better way to do things. Hence my idea:
For each specific implementation I would provide an ant script (or other file) of just properties. Key-value pairs, which would have specific prefixes for each key based on what it's used for. I would then want my ant script to run the various tasks, executing each one for the key-value pairs that are appropriate.
For example, copying the class files. I would have a property with a name like "classFile.filePath". I would want the script to call the task for every property it detects that starts with "classFile...".
Honestly, from my current research so far, I'm not confident that this is possible. But... I'm super stubborn, and always looking for new creative options. So, what options do I have? Or are there none?
It's possible to dynamically generate ANT scripts, for example the following does this using an XML input file:
Use pure Ant to search if list of files exists and take action based on condition
Personally I would always try and avoid this level of complexity. Ant is not a programming language.
Looking at what you're trying to achieve it does appear you could benefit from packaging your dependencies as jars and using a Maven repository manager like Nexus or Artifactory for storage. This would simplify each sub-project build. When building projects that depend on these published libraries you can use a dependency management tool like Apache ivy to download them.
Hope that helps your question is fairly broad.
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". ;-)
For those of you that use Ant with multiple projects, where do you put the build.xml files? Do you put one in each project, or do you put them in a separate project that contains all your Ant-related files?
The usual recommendation is to put a build.xml in each project. But this has a few drawbacks:
It makes it hard to reuse common targets in multiple projects.
Sometimes you want to use Ant to export a project from source control and deploy it. Obviously you can't do this if the build file is in the project itself.
But if you put them all in a common location:
People need to be aware of their location to use them; they can't just use "ant -find" to find the current project's file.
You can't have different build instructions for different branches of the project.
What do you guys do?
EDIT: Thanks for the good suggestions so far. As far Maven, these aren't Java projects, and I get the impression that Maven is only meant for Java.
Place the Ant files with the project. That is the de facto standard and recommended by the creator of Ant. I will try to address some of the issues you have brought up:
Reuse of common targets should be done using techniques as described by Eric Hatcher in his book Java Development with Ant. Basically, you extract all commonality into a some top level files that all other Ant files "inherit" from.
Using Ant to export a project from source control seems odd to me, but if you want to do this, use a different Ant file :-) You can make a target like ant export -Dproject=foo/bar.
For Ant, I recommend you grab that book - it has a ton of helpful techniques.
The real recommendation I would make though is to drop Ant and convert over to Maven - like the Apache Software Foundation did (they maintain both Ant and Maven).
If you're working with independent projects, you can:
put your build.xml at the top level
place common Ant definitions (Antlib) into another project (e.g. config)
use svn:externals to import the common Antlib definition (from 'config') into your project
EDIT The trick with svn:externals is that if you link to the HEAD of some common files, it may happen that they will change after a couple of months/years. So each time you tag, you should change the svn:externals to point to a fix version of the included project. This may come handy when a project has to be rebuild years after it was last built.
My rule of thumb is to put the build.xml file in the directory under which all files are referenced. In other words, no relative paths should start with "../". Where I live, that usually means putting it in the "trunk" directory, which has src, lib, build, docs, etc underneath it.
Doing this makes the paths much cleaner in the file, and it makes it obvious how to build the project.
Where I have multiple projects that need to build, I will create a separate build.xml for each project, and a central build.xml in the directory all the project are in that calls those other build.xml files. That gives you a lot of flexibility with very little work.
I'd expect an Ant build file to be located at the top of a project (it's already a pain to have to look at a the build file to "discover" how to build the project, so if I have to locate it first, it'll drive me totally crazy). Now, regarding all the drawbacks you mentioned, I'm tempted to say: why don't you use Maven?
The way I have done this is in the past (Now I just use Maven):
Have a build.xml in the root of each project
Create an overarching build.xml
for all projects and place it in
the trunk of my repository
The overarching buid.xml has
checkout tasks for each project.
I am guessing when you mentioned
export from repository, you
actually meant import.
The overarching build file also
defines the dependencies, if any
You may update individual projects using each project's individual build file
If you do have common tasks defined, you may inherit from a common build file as well as someone else suggested.
Looks like your set of projects might be a good candidate for migration to Maven, I realize it is not always possible but if you have time, you might want to look into it.
I'm picking up support on a project that is currently built with MyEclipse and has a decent sized development team that has been working without any CI processes.
From what I can tell, the MyEclipse folks don't see any value in being able to build outside of the Eclipse platform, which makes no sense at all to me. Continuous Integration is extremely helpful when you have to integrate changes into a codebase from more than one development environment, and it's pretty tough to automate builds when you're tied to a GUI.
Does anyone have continuous integration processes set up around MyEclipse style project-sets? If so, what strategy did you use to accomplish it?
AFAIKT there is no OOTB feature that can generate an Ant script (or equivalent headless-build script) from MyEclipse, nor is there an exposed way to invoke MyEclipse builders from a build-script platform.
This would lead me to believe that I'll need to reverse engineer the scripts based on what MyEclipse generates, which I'd rather not have to do.
I'm not particularly concerned with a Maven-style solution for my needs, but if you know of one I'd like to hear about it. From my initial research it looks like Maven/MyEclipse integration is even worse.
This is remarkably similar to the problems I had working with a websphere 5.1 application that could only be built from WSAD6 running on build machine built from a disk image from the company IT dept. WSAD did have a headless mode. It was a real pain to get that working from Hudson.
I would not be surprised if there was a Maven plugin and/or Ant task for each of the builders you are using. I would start there.
Here is a Maven based solution so maybee a bit off topic for you..
In our company, we use MyEclipse as IDE and Hudson and Team City for continuous integration. The projects are Maven based, so Hudson and TC can work with them.
When you want to open the project in Eclipse, you have to check out the sources, setup maven repository path for eclipse with mvn eclispse:add-maven-repo, build them with mvn install and then run target mvn eclipse:eclipse, which creates the Eclipse project setup from the maven's POM configuration. Then it is possible to import the project into Eclipse and work with it seamlessly..
More information can be found on maven-eclipse-plugin project page
..seamlessly until you change something in the POM configuration - then you have to run the mvn eclipse:eclipse again and have the eclipse project configuration recreated acording to the new POM.. it's important not to forget about this step, unless your project in the IDE won't work properly and you'll be wondering why ;)
Me personally don't find this solution the best, but that's the way how Eclipse folks work with Maven :/
Hope this should inspire you at least :)
This is another reason why I intensely dislike Eclipse. The fact that an IDE can force you away from something that's acknowledged to be a best practice is shameful.
"AFAIKT there is no OOTB feature that can generate an Ant script (or equivalent headless-build script) from MyEclipse" - I'm not sure I understand why this is a problem. It's possible to write a simple Ant build.xml in an hour or two that would do the job for most Java EE apps packaged as WAR files. I don't know if you're using EJBs, but even adding app server specific tasks such as EJB and JSP compilation wouldn't be much of a challenge. If you can agree on a common directory structure it would even be reusable across projects.
With that Ant build.xml in hand, you should be able to drive your CI process simply by checking into Subversion. The Eclipse plug-ins to do that work well, I hear.
If it's really a problem, I'd recommend IntelliJ. It works nicely with CI based on either Cruise Control or Hudson or Jet Brains' own Team City. The cost isn't excessive, and it'll pay for itself quickly.
If I'm misreading your question, I apologize. But if I've got it right, there's no way I'd let the IDE dictate to the team this way.
I have a bunch of modules which I'd like to all have their own ant build files. However, modules have dependencies on other modules. What's the best way to define dependencies between build files?
I've looked at the <import>, <ant>, and <antcall> tasks, but it seems like maybe there's a better way to do this.
You could look into using Apache Ivy (features) for managing your dependencies. There's a tutorial on how to use Ivy in a multiple project environment which sounds like what you're after. I'd recommend following through the tutorials from the beginning as it can be a bit tricky to get your head around it to start with.
I try to put all the definitions into Antlib and including them into the main build.xml file. If you write your macros following the "convention over configuration" rule, you'll be surprised to see how concise Ant can be.
If you want to see an example, you can take a look at my sandbox on Google code