On 30 October 2013 19:48, Matthieu Moy wrote:
> Local disk space is cheap. NFS-shared, RAID & backed-up disk space, less
> so. I can live with a few Gb of waste, but I was just wondering whether
> we could do any better.
As others have pointed out, its not possible to do better at the moment.
Th
gah, resending with the link this time.
http://openbenchmarking.org/result/1304257-FO-MERGE786390
On 10/30/13 11:21 AM, "Lyons, Roy" wrote:
>I am trying to get my unix admins to use it for us. here are some
>benchmarks I have seen.
>
>
>On 10/30/13 10:51 AM, "Curtis Rueden" wrote:
>
>>Hi Ro
I am trying to get my unix admins to use it for us. here are some
benchmarks I have seen.
On 10/30/13 10:51 AM, "Curtis Rueden" wrote:
>Hi Roy,
>
>> zfs has built in de-duplication.
>
>ZFS sounds awesome in theory but have you actually tried it? If so, how is
>it working for you? In particular
Hi Roy,
> zfs has built in de-duplication.
ZFS sounds awesome in theory but have you actually tried it? If so, how is
it working for you? In particular, how is the performance?
-Curtis
On Wed, Oct 30, 2013 at 10:43 AM, Lyons, Roy wrote:
> :) but like I said, you wouldnt worry about the space
:) but like I said, you wouldnt worry about the space if it was all on
zfs. zfs has built in de-duplication. you could have 2000 local maven
repos and probably not fill your disk since most of it has to do with
duplicate jars and such.
On 10/30/13 10:37 AM, "Curtis Rueden" wrote:
>Hi all,
>
>T
Hi all,
There is plenty of room for improvement regarding reuse of Maven's local
repository cache. Releases in particular are supposed to be immutable so
once they are downloaded they could go into a read-only tier as suggested
by Stephen. Inventing such a scheme to reuse large portions of the rep
Looking at the *MetadataSource components in the Maven source they're only
bound under:
org.apache.maven.artifact.metadata.ArtifactMetadataSource
and not:
org.apache.maven.repository.legacy.metadata.ArtifactMetadataSource
For example in MavenMetadataSource.java:
import
You're probably missing a dependency.
Jeff
On Wed, Oct 30, 2013 at 2:24 PM, Romain Gilles wrote:
> Hi all,
> I'm developing a maven plugin and I want to discover the last version of a
> specific artifact. I had a look to the maven-vesions-plugin. But I don't
> know why when I try to get a (depr
On Wed, Oct 30, 2013 at 10:18:49AM +0100, Matthieu Moy wrote:
> Barrie Treloar writes:
>
> > On 29 October 2013 23:56, Lyons, Roy wrote:
> >> Unfortunately, you will always have something in $HOME/.m2/repository
> >> because that's how maven works.
> >>
> >> Can I suggest perhaps that you use zf
Hi all,
I'm developing a maven plugin and I want to discover the last version of a
specific artifact. I had a look to the maven-vesions-plugin. But I don't
know why when I try to get a (deprecated) ArtifacteMetadataSource as follow:
@Component
private ArtifactMetadataSource artifactMetadataS
If you can control the version of Maven they run, you could create a aether
plugin that would let you use a tiered set of repositories... at least if I
understand aether correctly... then by putting that in the $MAVEN_HOME/lib
and doing some magic you might be able to at least share the read-only
p
Barrie Treloar writes:
> On 29 October 2013 23:56, Lyons, Roy wrote:
>> Unfortunately, you will always have something in $HOME/.m2/repository
>> because that's how maven works.
>>
>> Can I suggest perhaps that you use zfs for deduplication in /home?
>> Otherwise, you can add something like
>
> O
Am 2013-10-29 20:38, schrieb Steve Cohen:
When building a .tar.gz archive with the maven assembly plugin, should
it not be keeping the timestamps of the files it is adding to the
archive? This is how tar behaves. I find it NOT to be the case with
the assembly plugin. The files are dated with t
13 matches
Mail list logo
