I've recently been tasked with working on an existing eclipse project that makes use of Builders to run Ant tasks under given conditions. I've never heard of Builders before yesterday, and I'm having difficulties getting the project to work in IntelliJ.
First of all, I would like to know if there is a way I can effectively trick Ant into running from a different base directory than what it already does. Consider the following screenshot from Eclipse:
Here, project A is running an Ant task in a local build file that extends a build file from project B. As you can see from the Base Directory setting, it is different from that of A. When I try to run the task from this build file in IntelliJ, I get build errors because certain directories do not exist in the folder for project A -- they are located in project B.
Secondly, this Builder is set to trigger on Manual Build and Auto Build, but my understanding is that this only triggers if the project the builder is attached to gets built. As far as I can tell, in IntelliJ, I can set an Ant task to trigger before or after a build, but it seems like this will be for the whole project, instead of just the relevant module that represents this Eclipse project. Is there a way I can make it only apply to a given module, or will I have to trigger it for changes to all modules?
Related
We have an existing C++ project that is developed with eclipse. There is also a gui that is developed separately in Qt Creator.
We want to setup the eclipse project so that the gui is a sub-directory in the main project. The idea is that most of the gui development is done in Creator, but the entire project (including gui) can be built from eclipse.
I'm having trouble setting this up as a makefile build. I think I need to use eclipse' external tools to run qmake before building the project. The problem is that this creates the Qt makefile in the 'gui' directory and then eclipse doesn't see it.
This is how we ended up configuring this.
We have two build configurations, one for the main part of the project and one for the gui. For the main project, we exclude the gui from the build, and for the gui we exclude everything else but the gui from the build. The gui is build using a custom makefile that has targets for calling qmake and make. From QtCreator we just call "build" which runs the makefile, so qmake is never called from QtCreator.
It's not ideal but it works. The main drawback is that you have to switch build configurations in eclipse depending what you want to build. If I was setting it up again I'd make two different projects instead of two different build configurations in the same project. This way it's easier to manage the dependencies between the main program and the gui.
Indeed, you need to use the external tools. Add these in there: "qmake -project" and "qmake". The former is obviously not necessary if you have project file(s) already in there. You can then set the working directory, and arguments like the project file.
Then you can just run the externals tools from the menu. I am not sure what you mean by "Qt makefile" and by "Eclipse not seeing it."
If I create a test class I can't run it from eclipse until I have run it via maven on the command line first. My project build path output folder is pointing to project/target/classes. And build automatically is checked in the eclipse.
Anyone know why eclipse doesn't create the classes automatically?
Here's how the layout and build path of your project should look like.
Layout
Build path
In addition to what Marcel said, someone who runs into the same problem should look for dependencies between projects within Eclipse.
I was working with project A, which depended on project B. Project A was built and run normally, except for the problem mentioned in this post (run a JUnit class test). After digging for a while, I noticed that Project B had a build error (a source folder went missing, who knows why) and Eclipse was not building the project B, which caused an error on project A.
As soon as I fixed the project B build error, the problem with JUnit class was solved.
I'm trying to convert a Netbeans 6.9.1 project into a scripted build (without netbeans). Of course, it fails (or I wouldn't be asking for help).
In the failure it says that the org.apache.commons.httpclient package does not exist. (Of course, it worked when we ran the build in Netbeans).
Now I know exactly where the commons-httpclient.jar file is located in my project structure, but I can't seem to tell it to the compiler via the ant build files and the netbeans property files.
Perhaps related to this is when I ran "ant -v" to build my software, it said,
Property lib.mystuff.classpath has not been set. This variable is important, I guess, because
the file nbproject/project.properties uses lib.mystuff.classpath in its definition of javac.classpath, which of course tells the Java compiler where to find the JARs.
So...when moving a Netbeans project to a netbeans-independent scripted build, how can the build script set these properties? Also, how can I ensure that the jar file gets included in the ant build?
I appreciate any help I can get, as I am a Java newbie.
UPDATE AFTER ACCEPTING ANSWER FROM vkraemer:
There are a few best practices for build scripts for production software:
Put everything needed for a build under a single directory tree. (Netbeans = fail)
Put everything in source code control. (I did that)
The first line of the build script should clear all environment variables.
The next section of the build script should explicitly set all environment variables to values which are known to work.
The next part of the build should be able to execute using command-line programs such as javac, ant, cc, etc, and must not depend on firing up an IDE such as Eclipse or Netbeans.
It is a shame that Netbeans makes this hard.
I did a quick look in a Java Application project and found the following...
javac.classpath = ${libs.MyStuff.classpath}
libs.MyStuff.classpath is defined in %HOME%/.netbeans/6.9.1/build.properties.
You may be able to get by doing the following...
ant -Dlibs.MyStuff.classpath=c:\a\b\c.jar
You would need to do more if you have multiple jar files in the MyStuff library that you created in NetBeans.
We're using Eclipse on a flat multi-project set-up. Ant builders are set up on each project to create jars as needed; the ant files are used to manually kick off junit tests, create junit reports, etc.
One project is set up as a "master build" project, from which one has a convenient single ant target "test-all", which invokes the test target in all the other projects. This works, no problem.
The challenge is, that to some developers, certain projects represent optional components that aren't relevant to their immediate work task. So they close these projects to create some time-savings when doing things like clean and rebuild the whole workspace. This is fine, Eclipse ignores the closed projects as intended.
Problems occur when one goes to the "master build" project, and runs the ant test-all target. As you'd expect, it goes and tries to run the tests for all the projects, not just the "open" ones.
Any easy way to make the ant script smarter when running in an eclipse environment to know about "closed" projects, so I could make it ignore those?
Sort of adding an "unless=${CLOSED.UNDER.ECLIPSE}" type of ability to my ant files.
many thanks.
I have a large codebase added into the Eclipse project and have added one External Tool providing the path where the class for that java file is to be kept and the Classpath. The build folder is somewhere else.
Now when I need to compile only one file, Eclipse starts building whole of the codebase(>100 MB of Java files), it takes my system down and I have to wait for the whole compilation to go through.
Can only one java file be compiled without building the whole code?
Any pointers would be helpful.
I think you would benefit greatly with a build tool, such as ant or maven. You can have a target to compile only one class without building the whole code, or any other related task.
Have you built the project at least once ?
Eclipse builds incrementally using the saved state from the previous build. So if you build your project once, the subsequent builds would only pick up the changes made "after" the previous build.