I'm trying to run the Ivy repreport however it is taking a very long time (>48 hours before I kill it).
The repository that it is being run against is reasonably large but not ridiculously so (~150 Company artifacts and maybe ~1K dependencies).
Running with verbose produces no output.
Does anyone have an idea of what might be happening or how to speed it up?
Thanks.
I would limit the repreport to your organization like:
<ivy:repreport organisation="youroganization" />
This way artifacts that are not linked to your organization are ignored.
On my machine the first lines of output are:
ivy-report:
[ivy:repreport] :: resolving dependencies :: caller#all-caller;working
So getting no output at all is very suspicious, but I have no idea what could cause that.
And if all fails you could try to clean the cache.
Related
My IntelliJ 13.1.5 constantly indexes my project which really slows my machine down. It does it when I rebuild my project as well as when I start my jetty server.
Does anybody know how to disable or at least limit that behavior?
The previous version didn't do that so often.
Actually, I found what was wrong.
Once of my modules didn't have the target folder excluded and that was causing IntelliJ to always index and since that module is big it would take forever to index it.
Solution:
Go to "Project Structure" -> "Modules" and excluded all target folders.
Starting from IntelliJ 2017.2, indexing can at least be paused:
To other unfortunate souls working for enterprise mostly on VDI-s without an SSD: Idea actually parses/indexes a lot more then your project folders. Likely candidates that makes your whole day a rant session:
Libraries and Linters specified at a global level. For example "Languages & Frameworks/ Javascript/ Libraries" or "TypeScript / TsLint / TsLint Packages". If you work in multiple languages then this can bloat your index quite a lot. Its usually much better to open just one tiny bit from a project related to what your are working on to keep the index as small as possible.
as mentioned before: target, node_modules folders
dist, mock, resource folders
Do not open multiple projects/ modules in the same project scope. I theory this saves you time because you dont have to wait to reopen the given module in an other window, but the reality is that you just adding more stuff to index. If you happen to git pull a project with 5-6 different modules your idea will go into stasis for half an hour to index all the changes.
Try Invalidating the cache and restarting IntelliJ.
I had similar issue it solve with :
IntelliJ IDEA caches a great number of files, therefore the system cache may one day become overloaded. In certain situations the caches will never be needed again, for example, if you work with frequent short-term projects. Also, the only way to solve some conflicts is to clean out the cache.
To clean out the system caches:
On the main menu, choose File | Invalidate Caches/Restart. The Invalidate Caches message
Source link.
I'm having an issue which I'd have thought others might have come accross, but I can't find any posts.
My (small) WiX projects are taking ages (2-4mins each) to build on our build server, but are much quicker on my desktop (a few seconds).
After some poking around I've narrowed it down to McAfee scanning the temporary files created by light (located in the TEMP user environment variable). I don't know why it's taking so long to scan - disabling the AV has got the build time to well under 2 mins, previously it was over 20!
Now my issue is how to exclude these temp files from the AV. I don't want to exclude the TEMP folder for obvious reasons and there doesn't appear to be a way of excluding by file name without creating a big hole in the AV.
So I guess my question is, is there a way of configuring light.exe to use a different path other than TEMP? I tried some command line switches with no luck. Maybe I could add something to the Light.exe.config?
Cheers.
Can you not just disable real time antivirus scanning on your build machines? My argument for doing this would be that your VM should be full scanned and then disabled and that all files making it's way into the build machine are coming from source control and / or file shares that should have already been scanned at various points upstream in the process.
We ran over 100,000 builds a year at my last job and A/V would have killed us.
Otherwise, if you type light.exe -? you'll see there is an environment variable called WIX_TEMP that overrides the temp directory.
I really like IDEA, but when I work with a webapp running on Tomcat and I modify only a single java class file, I have to do an update classes and resources and it takes much more time to do it than in eclipse. In eclipse it's instant, at least I don't notice anything, in IDEA it does a make and updates caches and I don't know what else but it's really annoying.
Why is that and how can I solve this?
Update would depend on your project and its configuration in IDEA. Normally it should not take too long as only the required steps are performed. Compilation is incremental and would be instant. In order to understand why it takes long for your project, we'll need the sample project and the exact steps to reproduce it, please file an issue to our issue tracker.
If you want really fast updates, you may consider using JRebel, it has plug-in for IDEA.
Not so with IntelliJ 10.x. Updates don't require a complete build and redeployment. Try the new version.
I am not sure but you can actually check your Project Settings. There in the modules section you can mark some of your unnecessary folders as excluded.
This might speed up your process as the unnecessary files are now not been indexed.
Is there a way to run an ant build such that you get an output of what the build would do, but without actually doing it?
That is to say, it would list all of the commands that would be submitted to the system, output the expansion of all filesets, etc.
When I've searched 'ant' and 'test', I get overwhelming hits for running tests with ant. Any suggestions on actually testing ant build files?
It seems, that you are looking for a "dry run".
I googled it a bit and found no evidence that this is supoorted.
Heres a bugzilla-request for that feature, that explains things a bit:
https://issues.apache.org/bugzilla/show_bug.cgi?id=35464
This is impossible in theory and in practice. In theory, you cannot test a program meaningfully without actually running it (basically the halting problem).
In practice, since individual ant tasks very often depend on each other's output, this would be quite pointless for the vast majority of Ant scripts. Most of them compile some source code and build JARs from the class files - but what would the fileset for the JAR contain if the compiler didn't actually run?
The proper way to test an Ant script is to run it regularly, but on a test system, possibly a VM image that you can restory to the original state easily.
Here's a problem: You have target #1 that builds a bunch of stuff, then target #2 that copies it.
You run your Ant script in test mode, it pretends to do target #1. Now it comes to target #2 and there's nothing to copy. What should target #2 return? Things can get even more confusing when you have if and unless clauses in your ant targets.
I know that Make has a command line parameter that tells it to run without doing a build, but I never found it all that useful. Maybe that's why Ant doesn't have one.
Ant does have a -k parameter to tell it to keep going if something failed. You might find that useful.
As Michael already said, that's what Test Systems - VM's come in handy- are for
From my ant bookmarks => some years ago some tool called "Virtual Ant" has been announced, i never tried it. So don't regard it as a tip but as something someone heard of
From what the site says =
"With Virtual Ant you no longer have to get your hands dirty with XML to create or edit Ant build scripts. Work in a completely virtualized environment similar to Windows Explorer and run your tasks on a Virtual File System to see what they do, in real time, without affecting your real file system*. The actual Ant build script is generated in the background."
Hm, sounds to good to be true ;-)
..without affecting your real file system.. might be what you asked for !?
They provide a 30day trial license so you won't lose no money but only the time to have a look on..
I have MSbuild task like this to sign all the output modules of our project.
<SignFile Condition="Exists('$(OutputPath)\%(FilesToSign.identity)')"
CertificateThumbprint="$(THUMBPRINT)"
SigningTarget="$(OutputPath)\%(FilesToSign.identity)"
TimestampUrl="http://timestamp.verisign.com/scripts/timestamp.dll" />
It takes quite a while (10 minutes or more) when I have many files. It is possible to run stuff in parallel or in other ways speed it up. (I am trying to sign more than 100 files.. )
Another way of speeding up the signing is to remove the TimeStampUrl parameter. It may not be good enough for release build (to not have a time stamp on the signature), but it is good enough for a development build.
And it speeds up the signing process with 80-90%.
The only way to do parallel build with MsBuild is to have different instances of msbuild, thus different project files, I don't think that's recommended here. You cannot do task or target in parallels, yet you can build project in parallel (but you can create several project files with one target in each). You may have precision here : How to run tasks in parallel in MSBuild .
Moreover, I think you will be limited by your disk access speed and not by your memory.
I don't know the SignFile task enough to give advice on how optimize it, though, sorry.