Please help, I'm going slightly mad!!
I'm using Eclipse-generated antfiles to build a project with dependencies, one of which has its own buildfile in a directory which is a sibling to the direct ancestor of the project I'm building. E.g. if my directory is "/base/modules/clinicalcontext", the directory of one of the dependencies is simply "/base/core".
So, the generated build.xml uses ../../core which afaik is correct. But it is not!! From the console it is apparent that Ant goes back three levels and not just two (it gives FileNotFound on "/core/build.xml").
I tried to change the relative path to "../core" and much to my astonishment, this way Ant goes back by one level (it laments "/base/modules/core" being nonexistent). So how in the world I tell Ant t go back by two levels? I'd prefer to avoid using absolute paths, since I might have to move the project to a different machine someday.
Thanks everybody.
All Ant path will be relative to your current working directory.
So, check what directory you are running your script from.
I suggest that you start using ${basedir} to get a path relative to a location of build.xml.
In your case, the relative path should be constructed like this: ${basedir}/../../core, instead of ../../core.
The inconsistencies you encounter illustrate a point why eclipse-generated ant scripts are a good starting point, but never a good project build system.
EDIT. I wonder why eclipse ant generator does not insert ${basedir} in relative paths? Maybe you should report it as a bug.
Related
I'm trying to create a "Java/AspectJ application" run configuration for my Maven built project. Because i'm using Spring aspects i have to include the spring-aspects artifact in the run configuration's Aspect Path list. I'm adding it via the "Advanced.." button selecting "Add Classpath variable" and extending from the M2_REPO variable. So in the end i have a classpath variable entry in the list like this with a blue dot icon next to it:
M2_REPO/org/springframework/spring-aspects/3.1.3.RELEASE/spring-aspects-3.1.3.RELEASE.jar
However once i save it, Eclipse automatically replaces it in the launch file with the real path of the JAR on my machine making impossible to share the launch file with others since it's hard coding the entry to my environment.
Editing the launch file by hand doesn't help either because once i run it Eclipse replaces the expression the same way as above.
Is there any way to solve this?
The solution was to create the entry under the "Aspectj Load-Time weaving application" run configuration category instead of the "Aspectj/Java Application". For some strange reason the path of the Aspect is kept in it's unresolved format only with the first run configuration type. I guess it's a bug.
Obviously this makes the launch time longer because it does the waving in run time aswell. However i can't seem to find other solution.
I am currently working on an effort which makes use of Windriver's Workbench tool, which I understand is built on top of Eclipse.
Our source control tool is ClearCase and we are working primarily out of snapshot views located on the workstations of individual developers. As a result the absolute path for each developer's view is different. As deeply nested relative paths can be somewhat cumbersome (e.g. ../../../../../Some_Package/src/) we are using a Linked Resource PROGRAM_ROOT_PATH which identifies the particular view directory for a given developer.
This is working relatively well for for referencing header and library directories in the build properties, but we are trying to reference that Linked Resource from our build scripts in order to do build post processing such as copying the compiled program to a release area.
Accessing the Linked Resource as though it were an environmental variable appears to be the wrong thing to do as $(SOURCE_ROOT_PATH) provides an empty string. Is there a way to access this information from Eclipse / Workbench from a makefile?
Look inside the .classpath and .project files in the root of your workspace project - I believe the linked resource should be defined in one or the other of those (probably .classpath). From your script (you don't mention if it is Ant, Maven, Gradle, etc.) you should be able to find a way to get that value out of the .classpath (through some plugin or custom code).
We use Eclipse, ClearCase, and Ant. The easiest way I have found to share projects is to include the .project, .classpath, and build.xml files in the top level of the project in ClearCase. Then when you create your view, mount it in your Eclipse workspace, and do a File -> Import, then choose Existing Project from the popup. Browse to the top-level of the project in the view and import it.
The paths in the build.xml and .classpath are relative from that point down, so it doesn't matter what the absolute path is up to the project. For example, your build will define your source directory as something like ./src/java, test directory as ./test/java, etc. Whether your absolute path is c:\workspace\project or /home/someuser/project or whatever doesn't matter to your build script.
I want my Ant build to take all Java sources from src/main/*, compile them, and place them inside bin/main/. I also want it to compile src/test/* sources to bin/test/. I wan this behavior because I want to package the binaries into different JARs, and if they all just go to a single bin/ directory it will be impossible* (extremely difficult!) to know which class files belong where.
When I go to configure my build path and then click the Source tab I see an area toward the bottom where it reads Default output folder: and then allows you to browser for its location.
I'm wondering how to create bin/main and bin/test in an existing project without "breaking" Eclipse (it happens). I'm also wondering that if I just have my Ant build make and delete those directories during the clean-n-build process, that Eclipse might not care what the default output is set to. But I can't find any documentation either way.
Thanks in advance for any help here.
In Eclipse, you can only have one output folder per project for your compiled Java files. So you cannot get Eclipse to do the split you want (i.e. compile src/main to bin/main and src/test to bin/test).
You can, if you want, create two Eclipse projects, one main project and one test project, where the test project depends on (and tests) the main project. However, in that case, each project should be in its own directory structure, which is not what you are asking for. But this is a common approach.
Another way, which I would recommend, would be to not mix Ant compilation and Eclipse's compilation. Make the Ant script the way you describe (i. e. compile the main and test directories separately and create two separate jar files). Change the Eclipse compile directory to something different, for instance bin/eclipse. Use the Ant script when making official builds or building for release. Use Eclipse's building only for development/debugging. This way, your two build systems will not get in each other's way and confuse each other.
Hope this answers your question and I understood it correctly. Good luck!
Is there way to tell IntelliJ IDEA which output folder to use for GWT compiler ? I know it copies artifacts to project folder but it doesn't copy extras which I set using "-extra" command line parameter of gwt compiler.
IntelliJ IDEA leaves it in USER_HOME/.IntelliJIdea10/system/gwt/project_name_with_hash/module_name_with_hash/compile/www
UPDATE: Strangely I didn't find list of possible path macroses on IntelliJ's website. But I found them in idea.jar. Possible macroses are:
APPLICATION_HOME_DIR
PROJECT_DIR
MODULE_DIR
USER_HOME
Have you tried constructing the path using ${PROJECT_DIR} path variable? That will resolve to the project location and then you can specify the rest of the path. Like ${PROJECT_DIR}/reports/extras. I haven't used IntelliJ for a few years, but I am pretty sure that's the path variable name.
EDIT: sorry built in path macros in IntelliJ are specified using $...$ syntax. So I think it should be $PROJECT_DIR$
There is no way to change output folder for GWT compiler in IDEA. However you can specify absolute path to any directory after '-extra' parameter.
By the way for what purpose do you use '-extra'?
As of November 18, 2011 it is impossible to use path macroses in settings of project modules. Jetbrain is aware of this and there is feature request in their JIRA.
My work-around for a team with multiple engineers for now is to use system TEMP folder for GWT compiler extra output and move files in post-build event to folder I want it to be at.
I created an Eclipse project and now I want to put it on my SVN repository. Which files should I put on ignore list? There are many files that I don't know what they are used for. There are folders like .history, .root, .safetable, .log, .settings ... and many .index files, also some .running files. Can I put all that to ignore list? Do you know which extensions/folders can always be on ignore?
Thanks.
The answer is very dependent on your project. Committing the source is a good thing however it'll force new developer to recreate the project environment which can be painful. If you are using Maven with the m2eclipse plugin committing only src and pom.xml is a good approach as it only takes a few minutes to recreate the Eclipse environment from src and pom.xml.
On the other hand it is ok to commit .classpath and .project but that also means extra work such as never using external jar directly but through variables or user library, etc.
If you have time to experiment, why not check in everything, have a colleague check out the project, and see what throws up errors? Anything that references paths outside the project is likely to fail if your colleague doesn't organize her harddrive the same as yours. Those things should be changed to reference variables, or not placed under version control.
Let your colleague build the project, run the IDE through its paces, and then sync up to the repository to see what changed. Files that are volatile, run time logs, and temp files should be omitted. Anything that makes it easier for another developer to setup the project and get running should be included. Taking time to experiment will help you gain a better understanding how your project is setup.
Basically, you want to avoid checking in anything derived from source (like .class files in a Java project) or anything that every developer would have to change for their local environment, like a file with absolute references outside the project directory. One approach I have used in the past for handling configuration files that require customization by developers is to include a copy of the file, usually with extra comments, with a .example extension. Make it clear in a README or other documentation which example files need to be customized and what the "real" name for the file should be. Also include he "real" file name in the svnignore list so it doesn't get checked in and overwrite everyone's local customizations.
To address your specific examples:
.history, .root, .safetable, .log,
.settings ... and many .index files,
also some .running
.settings is one you'll have to experiment with. If you have settings, such as code style or formatting guidelines, that all developers need to follow, then it can be handy to have those under version control, but some other settings may not be appropriate for all developers. The other examples are not familiar to me, possibly because they are associated with a type of Eclipse project I don't work with.
My first guess would be that any file whose name is starting with a dot should not be versioned. Most commonly such files refer to Eclipse settings which are not project-relevant.
Now, the .project and the .classpath files, in a Java project, are quite "project dependant" and I usually include them.
To get a more precise answer you should specify which project type you are working on.