Here is the situation: I have a large project and I made breaking changes that affect many files but I want to test these changes on these files in small groups. Which means I want in each phase to run the project and compile only say for example 3 files to see how they are affected by these changes, and the rest of the files must not be compiled (the project runs normally with only these 3 files compiled for example). I tried commenting all the code in these unwanted files but this solution is not practical as there are too many of them, I am searching if there is a solution like giving a command line option to exclude these files without touching them or any other similar clean solution.
note: I mentioned flutter just in case it may be relevant and I don't think I should provide any code for this question
Related
The feature build automatically under the eclipse is much faster than the ./gradlew build.
My findings after some research is that it compiles and builds only the changed file and replaces it in build folder.
So why can't ./gradlew build command compiles and builds files that have changed and replace it in build folder and make the whole building process faster.
I have recently started using build automatically feature with hotswap agent + DCEVM.
Why can't gradlew build command compile and build only the things that have changed and make the process faster?
There's no dependable way how to determine what needs to be recompiled. For example, compile-time constants get inlined and there's no trace of where they come from in the class files (it can be found in the source files, that implies parsing them and losing time; it can be stored in some auxiliary files and some tools do it).
See the "Limitations" section of this for details.
The reason maybe is that they don't go through configure step of gradle.
Sure, but the configure step doesn't usually take that long.
Eclipse knows which files have changed
Good point (in a comment by holwgler).
Some time ago I spent some time trying to make my gradle compilation faster and I gave up. Eclipse is damn fast for many reasons:
incremental compilation
multithreading using all cores
knowing all changed files
having the whole compiler code optimized by the JIT
probably caching file dependencies
ugly highly optimized code
My "solution" is ignoring the problem. I do everything in Eclipse, except for integration tests (which take way longer than the compilation) and production builds (which are rare enough so I don't care).
You may want to read these performance tips.
To find out where the time gets spent, use
./gradlew clean; ./gradlew --profile jar
For me, 90% of the time is just :compileJava.
I'm trying to figure out why my APK is 21 MB large when I export it. I was using HoloEverywhere and ActionBarSherlock, so I'm doing an experiment to see how big my APK will be without them. To do this, I de-referenced both of the libraries. However, I notice that inside the src->.git->modules folder, there is still a folder for ActionBarSherlock that is adding around 10 MB to the whole project file. Why is it still in there if I've de-referenced both libraries and have no other connection to ABS in my project? I tried cleaning my project as well, but no luck.
Everything in the .git directory is for your git repo. Since git is a SCM library, it doesn't just forget about things. The .git directory will just continue getting bigger as you commit more code, even if those commits delete things. (Delete one file and it gets a tiny bit bigger since it is adding an entry to say it was deleted)
Now as far as the .git/module directory goes, I believe that is used by git to track submodules. Removing it will probably corrupt your repo for the main project. If you decide you want to remove it, start by moving it to another directory and see if you can do checkouts of old tags/branches/commits and get a commit history. Even if that all works, I doubt you'll be able to extract an old tag/branch and do a build as you'll be missing the module that it relies on.
If you're concerned about why your APK is so big, pull it apart to find out why. Check the second part of my answer here:
Android Http client library issue
It's a simple unzip of the APK. That will allow you to take a look at sizes of all of the non-java files and the classes.dex file. If you're wondering what the sizes of things inside the dex are, use the dex2jar. Note that because the JVM is stack based and Dalvik is register based, .class files are actually slightly smaller than the equivalent Dalvik bytecode.
IDE misconfiguration is a big source of inefficient time use in our team.
I wanted to know if other teams have tried to check the health of the eclipse workspace with continuous integration.
Eclipse is open source and extensible, and most (all?) of its files are in xml. So it should not be difficult to add a step to continuous integration that checks the health of the workspace, such as no missing Jar files, no errors, etc.
What we have is a separate ant script to do the real builds that go to QA and to the customers. This ant script is run with continuous integration and we have put in place a few simple checks that catch most big showstoppers.
The workspace configuration is a different story and we sometimes detect problems when it's too late (the dev left home).
EDIT: Note that we share our Eclipse config files.
There is some information on building with Eclipse from the command line here.
(Should be a comment, but I can't).
I don't see why you want to do that. Eclipse complains loudly if anything is broken, so leave it to the developer.
What you should consider instead, in my opinion is to write tests that check that everything is as you expect it to in the building process of those builds from source code that the developer has checked in the source repository.
If a build breaks due to a jar is missing in the build, add a check. If a build breaks because it is dependent on a certain feature in the JVM, add a check.
Only ship builds outside of the development team that pass all tests. Those builds that fail, should be fixed by the developer introducing the change that broke the build.
Since you are using Ant, you can create a custom task that verifies the following files against pre-defined ones. If they don't match, report problem:
workspace/.metadata/*.* (whichever configurations you think are important)
workspace/project/.classpath
workspace/project/.project
workspace/project/.settings/*.* (whichever configurations you think are important)
Of course, these files include some hard-coded paths, so you can use regular expressions in the pre-defined files.
If you want to check only simple things like "the project doesn't compile", then just compile the project in the ant script (using the javac task) and see if there are errors.
Another thing - continuous integration should better be IDE-agnostic. I.e. you must have a IDE-less environment (a CI Engine) that compiles the project. Imagine the following:
three developers, one of them accidentally removed a jar from his Eclipse, but the project in the repository is compiling. No need to report problems in that case
one of the developers adds a new jar and commits. The others have not updated. No problems are reported in there workspaces, although after they update, they might get the problem.
That all said, I think you'd better look at Hudson, which is a continuous integration engine. Thus you won't be dependent on IDE settings for your builds.
I'm working in a Java project where the axis 2 library from Apache is being used. The axis 2 library is composed of about 20 jar files and some of these are not used project. What I want to know if there is a method to identify which of those jar files are the unused ones.
I'm using the Eclipse IDE an I thought that one way to solve the problem is to add one jar at time until the I get no error messages about the missing classes. However, I'm not sure if this will work as some of the missing classes errors show up only at runtime.
Does anyone know a better way to solve this problem?
tattletale FTW
http://www.jboss.org/tattletale
JBoss Tattletale is a tool that can help you get an overview of the project you are working on or a product that you depend on.
The tool will provide you with reports that can help you
Identify dependencies between JAR files
Spot if a class is located in multiple JAR files
Spot if the same JAR file is located in multiple locations
With a list of what each JAR file requires and provides
I would follow your original idea of adding one jar at time until it compiles.
You're right that you can still find run-time errors, but unless the application is too big for a good coverage with manual tests, I would simply run and test it to add any missing jars.
I don't think you can reliably remove jars since classes may be resolved at runtime e.g. using
Class.forName(className);
You may be able to determine the class names used for the above, but it's unlikely.
Since classes will be requested/resolved at runtime, you could run your (comprehensive) test suite to determine whether stuff still works. But ultimately I would be very wary of removing jars from a package like Axis. I assume they're there for a purpose. Is the jar file size really a problem ?
I am using Eclipse 3.4.2 to develop my code. As part of my project definition I reference a utility library to which I have attached the source code. So far, so good - I can see that source when I bring up classes from the library and while I am debugging.
Now however I would like to make a change to one of the classes while still retaining all the features of the Eclipse Java editor (specifically things like tool tips and quick fix). These features seem to work when I'm viewing the source (I can CTRL+LClick through method names for instance), but it is read-only. On the other hand I can explicitly open the source file which will allow me to edit it, but I lose all of the "smart" editing features.
I've recently switched to Eclipse from IntelliJ where this was possible so I'm hoping it is in Eclipse as well. Note that although I could simply include the code as a project in my workspace, I'd really rather not. The workspace is already quite large and I don't want to further slow Eclipse down by adding projects I rarely would ever touch.
I am not sure I get your question right. When you add a precompiled library to your projects build path (the JAR) and attach source to this JAR, Eclipse will show you the source code when you click on a .class inside the JAR. The same goes for the debugger, which will also allow you to step through the code lines in the source, if the classes in the JAR were compiled with line number information.
Now what you seem to want to do is modify the classes inside the JAR (the source view is just an overlay which can even be off, if you attach a different version of the source), which is not possible, because they are wrapped up in binary form in the JAR archive - even though Eclipse is smart enough to display them individually.
I guess you would expect your changes to be hot-swapped into the running program by the debugger. This can only be done through a recompile once you finished your changes. Usually Eclipse does that automatically when you save a Java source file. As your source file is however not part of the workspace (or an external folder explicitly declared as Java source) - it will not do that recompile and swap.
I'd recommend to include the source of your external library as a project in Eclipse and not worry about performance too much - I work with 3.4.2 every day and my workspace has about 45 open projects with several 10.000 classes and millions of lines of code. I assign a Gigabyte of RAM to the Eclipse VM and have no problems with that on a Core2Duo 2.6GHz machine.