There are conditions where Eclipse builds Codename One projects endlessly.
This is always the case when "Refresh using native hooks or polling" is activated for the workspace.
I am wondering why this is happening. Eclipses automatic build tracks changes in source folders and automaticalls builds when changes occur.
Any idea what causes those endless builds with Codename One projects?
Adding a resource filter in the dist-folders properties is to no avail.
Our build process generates files since it uses Ant, it replaces existing project files (especially if you use the new GUI builder) so this is probably throwing Eclipse for a spin which re-runs the build which regenerates the files resulting in endless loop.
I'd love to improve building on Eclipse but I'm not really sure how we can do that in a way that still works well with the whole build process.
Related
I have a collection of C++ projects that use managed makefiles inside Eclipse. I build them all, and run an existing deploy script to place all the compiled results into a target directory on the system.
I'd like a way to automate the build process without having to open the IDE, but due to external constraints from the project owner, I have to use managed make.
Once I kickoff a build for the first time inside the Eclipse IDE, the Debug / Release directories are created, and the makefiles are autogenerated. Once they are all present, I can call make from the command line, across all the projects, run an overall deploy script, etc. This will work up until the point that code changes would cause the makefiles to differ (adding/removing source files, or changing build parameters) The big problem with this is that it requires me to open eclipse and manually cause the generation of the makefiles.
I see two options:
Check the generated makefiles into revsion control (even though they're generated, I know), and commit them whenever they, after generation, have differed from the previous content.
Find a way to either open eclipse in a scriptable way, and cause makefile generation, or to find some alternate way to generate the makefiles from the .project files.
Option 1 is obviously subject to problems if I or other developers don't remember to commit the files, or if we update the Debug makefile but not the Release makefile, etc. It also makes me feel dirty to commit a generated file.
Option 2 seems much better, if its feasible.
Does a method to do option 2 exist? Are there other options I haven't considered?
I recognize similarity with a continouous integration server, but This is not the same use case. Essentially I'm building a package that gets installed on a development system as a testing release of a system library. So I'm operating as a developer, I just want to reduce variance out of the deploy process itself.
I have some data resources that I would like eclipse to not copy every time it builds. I put them as part of the build path so they get copied, but I don't want that to happen every time as it's time consuming.
Any idea on a better strategy?
I don't even want them to be deleted when clean is invoked. In Visual Studio one can mark a resource file as "copy once" is there such a thing in Eclipse.
Thank You
Having eclipse not copy some file that you have modified even after a clean will be a nightmare: you'll have to remember to copy it manually each time it's modified.
And Eclipse only copies files which have been modified when building incrementally.
If it's so slow, it probably means you have too many such files, and they should perhaps be put in a jar in the build path.
As you ask for a strategy, then ...
Eclipse is not a build tool, it's IDE. So you better not try to setup some build logic based on it. Use eclipse for coding and for performing specific tasks during build use build tools like maven or ant.
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.
I have a bit of code for a dll that is needed by two or more projects in eclipse. Currently each project has a copy of the code and builds the DLL separately. I want to separate the dll code into a separate eclipse project so there is a common location. But I want to avoid the situation where we have to build the dll in the one project, then copy the dll back to the other projects and check the dll to each respective project. This will create a dll for each project that isn't traceable to the exact code that it was built with.
Is there a way to somehow symbolically link the dlls to another eclipse project that is using CVS as the version control system so that it is possible to tell which version of the code was used to create the dll? Am I making this too complicated or missing something obvious?
I thought about working sets in the package manager for eclipse, but I have to investigate more on how to use them with CVS to avoid making it a nightmare for the next person who checks it out and can't figure out why their project won't compile.
Thanks.
What about creating a new folder in a separate project. In the advanced section of creating a new folder there is an option to link to another location on the file system.
Or you could also create a container project that makes use of a projectset.psf file. Have the projectset file link to the different projects in your repository. When you want to check out that project, check out the container instead and right click on the projectset file and select Import Project Set...
If you are working with one workspace, you end up with three projects, each mirrored in CVS: One is the dll, the others are the projects using the dll (configured as a project dependency of these projects upon the dll project).
With three projects I wouldn't aim for working sets - they are good for managing a lot of projects within one workspace, for three projects, I'd consider them overkill. I usually tend to aim for several workspaces instead of working sets.
Regarding the next person working with these projects: You need to keep some kind of documentation about how to setup your projects. You might say that your eclipse project files do just that (as they define a project dependency upon another project) but this is for the machine - humans tend to like other communication means.
If you are worried about changes to the dll being incompatible to one project (because the person applying these changes doesn't care about the other project), aim for a build server. This will build all projects and dependent projects whenever something under version control changes, run all tests, provide a build number and package it all ready for use. This way you can be sure that - whatever is in your deliverable - can be reproduced, because the buildserver is not able to make local (uncommitted) changes to the code. Also a buildserver will signal failure (either broken API or broken tests) at the moment of the last commit (well - a few minutes later) and place the burden of repairing the damage on the one causing the damage.
I've set an external tool (sablecc) in eclipse (3.4) that generates a bunch of classes in the current project. I need to run this tool and regenerate these classes fairly frequently. This means that every time I want to run sablecc, I have to manually delete the packages/classes that sablecc creates in order to ensure that I don't have conflicts between the old and new generated classes. Is there some easy way to automate this from within eclipse or otherwise?
Not sure if I understand your point right, I suppose you need to delete old classes before running sablecc because some of them would not be eventually created in new run.
It is probably best to write short Ant build.xml with the target, which first removes the classes (Ant delete task) and then runs sablecc (Ant exec task). It is also possible to preset eclipse so that it refreshes workspace after Ant finishes.
Put the build.xml anywhere to project, right click, Run As/Ant Build.
Just for the sake of the clean style, you could then call sablecc with its Ant task (implemented by org.sablecc.ant.taskdef), instead of running it externally in new process.
You can tell Eclipse to refresh the workspace (or parts of it) after an external tool has been run. This should force Eclipse to detect any new/deleted classes.
JesperE is referring to the option Refresh->Refresh resources on completion in your external tools configuration for running sablecc.