I am testing XD locally. I am using eclipse. For each code change, I am using gradlew copyInstall task to build XD and test it. It takes upto 15 mins to build. As I keep making changes, anyway I can reflect latest code changes in XD distribution (like copying a JAR or making eclipse copy the class files). Any less tome consuming way to test incremental changes will be very much helpful.
./gradlew copyInstall -xtest -xjavadoc -xsetupui will speed things up significantly
Related
IDEA. For most time, when I modify a build.gradle file. It takes a long time to importing or sync the changes. What does it doing? How can I see action details.
IntelliJ has to run the gradle build file to import its configuration. Sorry I don't remember what exact task it runs.
When Gradle runs any task, it first has a configuration stage where it reads through all of the build files and gets ready to run tasks. For larger build files this can take quite some time.
To find out what is taking Gradle so long, check out the "Build Scans" section and other performance optimization tips here: https://guides.gradle.org/performance/
I'm dealing with weird behavior using gradle build-cache with composite builds.
I have a repo where i have 3 independent projects:
app
mocks
integration-tests
Integration-tests are including 2 builds - mocks and app and starting both services as java apps (depending on jar task of both projects).
Running locally
When running locally, everything seems fine (also using build cache), but on integration machine, something weird is happening.
Integration testing
We use gitlab, and pipiline is quite simple:
---|-- junit-mocks --|--- integration-tests
|-- junit-app ----|
junit mocks and junit app in parallel (with build cache) and next stage is int-testing where java compilation of app and mocks is loaded from build-cache. (as you can see in picture attached).
The error is only a consequence, that Main class was not found (weird#1). When i looked inside the jar file, it was truly half empty, missing a lot of classes, but static resources were there. When i looked into gradle's build/classes dir, it was completely empty. It's like cache was hit, but classes were not copied?
Weird#2: is that mocks has built successfully (and started), but not the app.
When I turned off build cache, build passed.
Any ideas what could cause the issue?
What type of gitlab executor/runner are you using?
Your cache is intended to be shared between gitlab stages however if you are using a docker executor, each stage will use a fresh docker image/environment so unless you are using artifacts, you would not be able to share a cache between them.
If you were using a shell executor which targets a specific machine on every build then you would be able to leverage a cache as long as it was not within the build directory because that changes on every gitlab stage in the pipeline.
If I want to test my changes, I do it in the local setup by making changes in the .war files of the project. This is a time consuming process. Is there any alternative to this testing step ? Any software or tool which helps me test my changes without building again ?
I've tried building it:
parallel (helps a bit)
daemon=true
preDexLibraries true/false ( no big difference )
incremental true
offline
It takes >40s EVERY time. It doesn't matter if I change anything or not. Building it after "gradle clean" takes >50s.
I hope that I'm doing something wrong. Eclipse/ant could build consecutive builds WITH CHANGES in <10s.
Any help how to bring this <10s appreciated.
Yes, we have a lot of modules, some jar libraries, some maven dependancies. Still don't get why would it take >40s for two consecutive builds with no changes.
Gradle used: 2.2.1
Android studio: not really relevant, usually building it only with Gradle.
EDIT: adding some profiling logs.
:app:dexProjDebug 22.541s
:app:shrinkProjDebugMultiDexComponents 4.279s
:app:compileProjDebugJava 3.478s
:app:packageProjDebug 2.591s
:app:processProjDebugResources 2.590s
:app:packageAllProjDebugClassesForMultiDex 2.536s
:app:createProjDebugMainDexClassList 2.126s
You need to properly define inputs and outputs even for library projects with source code. (Gradle Documentation). Do you get UP-TO-DATE message when you rebuild second time onwards?
If you have no changes to the other modules, you can build the app itself using gradlew :app:build. This will eliminate the time Gradle spends on building the other modules. You can build any module separately like this as well, using gradlew :moduledirectoryname:build. If you need to build one module and the app, you can execute both tasks at once to avoid going through Gradle's configuration stage twice: gradlew :app:build :moduledirectoryname:build
If possible, update to Gradle 2.4. It's significantly faster (claiming 20-40%).
One of the most significant build time reducers is the preDex task. Check whether preDex is running in your build. It increases build time the first time you run it, but dramatically reduces build times in subsequent builds, as most of your SDKs and libraries will already be dexed. Note however that it won't run under some conditions, e.g. if you use multidex.
Btw Google are well aware of build times with Gradle and Android Studio and are going to introduce significant improvements in upcoming releases, including Jack and Jill which will allow compiling from source code directly to dex. You can already try to experiment with them - see here: http://tools.android.com/tech-docs/jackandjill.
Also worth watching this video from recent Google I/O: https://youtu.be/f7ihSQ44WO0?t=327
Download Genymotion emulator. It is very fast and good to run android apps. It will save you a lot of time.
Here is the link - GenyMotionDownload
I need solution to speed up maven build process.
The project is based on Adobe cq5 otherwise AEM and i have more than 10 modules in my project where the build happens in linear way.
Currently Build process takes more than 10 min to compile.
is any other specific tool available or other way to speed up the process?
Thanks
I have one suggestion,If you have 10 modules than make separate profile for each module,and build only that part in which you are changing and modifying,no need to deploy 10 modules each time unnecessarily.It will not speed up maven project build but can help you to save your time.It is a workaround but will be helpful .
Try mvn -T 4 clean install #Builds with 4 threads
Its a multi-threaded mode to run Maven and is faster. Apache documentation here.
To add to the other answers:
1) Give more memory resources to the server where the AEM instance is installed, content creation involves a lot of disk access so using SSD is a must.
2) Having a clean AEM instance helps to speed up the process. As you may know the AEM repository grows because of revisions so each time you deploy the repository size grows and it becomes slower. if it's a production environment use maintenance tools like revision clean up and compaction.
revision clean up
how to maintain repository
As per my knowledge there are no such mechanism to speed up.
better to make a build of particular module, it will deploy faster rather waiting for all 10 module to be happened.
Thanks
You can try using the suggested answers to build modules in parallel. It should speed up the build in theory.
But really there is no magic answer. You have to find the bottleneck in your build, it could be the number of dependencies, it could be a specific slow plugin, it could be hardware related, and it could be something else.
Try this: https://github.com/lptr/maven-time-tracker
It may help you find the bottleneck.
I would like to answer this question, knowing it was posted a really long time back.
Currently I am using AEM 6.3 and to recompile and deploy CORE module changes there is a simple maven trick -
This command tells us to -
run 1 thread/core
compile just the core module of the list of projects
and of course, zip package and send it to running AEM instance.
In my observation, this reduced the turnaround time by a huge margin.