Hi,
We solved 4 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11431&version=20125
There are still a couple of issues left in JIRA:
http://jira.codehaus.org/issues/?jql=project%20%3D%20MGPG%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC
Staging re
Hi,
We solved 11 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11134&version=20572
There are still a couple of issues left in JIRA:
http://jira.codehaus.org/issues/?jql=project%20%3D%20MEJB%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC
Staging r
Hi Karl,
I added a feature at gpg and bug fixes at wagon-ssh
Very much appreciated when ever you can release them
Thanks
-D
The Apache Maven team is pleased to announce the release of the
Apache Maven WAR Plugin, version 2.6
The WAR Plugin is responsible for collecting all artifact dependencies, classes
and resources of the web application and packaging them into a web application
archive.
http://maven.apache.org/plu
GitHub user Enygma2002 opened a pull request:
https://github.com/apache/maven-indexer/pull/11
Add minimal information to a newly created artifact info (using the
IndexUtils method), linking it to the context it belongs to.
While trying to write an IndexCreator, I`ve discovered that
Github user Enygma2002 commented on the pull request:
https://github.com/apache/maven-indexer/pull/9#issuecomment-69610327
Please see #10 instead, since I`ve initially made the changes on my fork's
master branch.
---
If your project is set up for it, you can reply to this email and h
GitHub user Enygma2002 opened a pull request:
https://github.com/apache/maven-indexer/pull/10
Indexing a repository with the indexer-cli (using -i and -r parameters)
creates an empty packed index.
Caused by the fact that the IndexSearcher obtained before indexer.scan() is
called is
Github user Enygma2002 closed the pull request at:
https://github.com/apache/maven-indexer/pull/9
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the featur
yes it goes to OS with one exception, I was trying to explain :)
The exception is that file system is mapped with memory, and so the writes
go to the memory fast, but they go to the file system as well however
slowly. The trick is that the data goes to both memory and IO, they can be
read immediate
400MB/s is way faster than any single spinning disk can do and actually
quite a bit faster than SATA I/II max speeds [1]. This suggests the data
was written to the operating system caches but never made it to the disk
physical media. That is, unless you had a RAID connected to system using
some so
GitHub user Enygma2002 opened a pull request:
https://github.com/apache/maven-indexer/pull/9
Indexing a repository with the indexer-cli (using -i and -r parameters)
creates an empty packed index.
Caused by the fact that the IndexSearcher obtained before indexer.scan() is
called is
Kristian, we tested only spinning media.
I think this test was done in 2010 or 2011.
We did not have SSD that time.
In build system I would still rather rely on spinning media.
Yes, right, constructing ButeBuffer every time is just bad idea. Since they
are not thread-safe, they should be stored in
https://github.com/apache/commons-compress/blob/trunk/src/main/java/org/apache/commons/compress/archivers/zip/ParallelScatterZipCreator.java#L84
I'm looking at using a PriorityQueue for scheduling the tasks so the
largest files get zipped first. Combined with ForkJoinPool work
stealing I'm hoping
I guess every virtual machine might be configured to use only few CPU out of
let's say 16 CPU.
I am convinced "use all available CPU cores" means application Threads and
not the CPU itself.
The customer should be convinced we don't make any selection on particular
processors.
Of course Java program
>
> TL;DR we should let the OS be responsible for applying resource limits, we
> should use every resource we are given to the full in order to reduce the
> build time as that shortens the feedback loop and makes developers mire
> productive
I guess I agree. Guidelines doesn't work anyways as the
2015-01-12 9:24 GMT+01:00 Kristian Rosenvold :
> Creating a 256MB zip file with typical jar content has a compression
> phase of 4 seconds on my 6 core machine, with 1.4 seconds in the
> "gather" phase. You'd need some really huge zips for this to become a
> real problem, and in that case I someho
2015-01-12 9:03 GMT+01:00 Anders Hammar :
> Do you foresee any issues with "use all available CPU cores" when used on a
> shared resource like CI server?
> When writing guidelines for my customers' devs I'm always very firm on that
> build jobs are not allowed to fork (or similar) freely and thereb
On Monday, 12 January 2015, Anders Hammar wrote:
> Do you foresee any issues with "use all available CPU cores" when used on a
> shared resource like CI server?
> When writing guidelines for my customers' devs I'm always very firm on that
> build jobs are not allowed to fork (or similar) freely a
I do not really doubt your numbers, Tibor. But I think there's a huge
difference between "real world" application benchmarks and just
measuring what can be done in a constructed test case. Both are of
course valuable, but they have somewhat different applicability. And I
think SSD's make a huge dif
Do you foresee any issues with "use all available CPU cores" when used on a
shared resource like CI server?
When writing guidelines for my customers' devs I'm always very firm on that
build jobs are not allowed to fork (or similar) freely and thereby
occupy more than their share of the resources on
20 matches
Mail list logo