On Wed, May 18, 2011 at 7:06 PM, Manik Surtani ma...@jboss.org wrote:
Hi guys
Sorry I've been absent from this thread for a while now (it's been growing
faster than I've been able to deal with email backlog!)
Anyway, this is a very interesting discussion. To summarise - as Pete did at
As someone mentioned, the biggest issue would be to make sure the data
read from the file system isn't stale. If a node has been down for an
extended period of time, then this process might slow things down.
We'd have to implement some rsync like algorithm, which checks the local
data against
Hi all,
So, what's our current approach towards hardcoding maven repositories in the
pom.xml files?
Should we allow JBoss repos to be defined master/parent/pom.xml? This was added
by Adrian C when he upgraded JClouds:
repository
idjboss/id
On May 18, 2011, at 6:06 PM, Manik Surtani wrote:
Hi guys
Sorry I've been absent from this thread for a while now (it's been growing
faster than I've been able to deal with email backlog!)
Anyway, this is a very interesting discussion. To summarise - as Pete did at
some point - there
On May 18, 2011, at 6:06 PM, Manik Surtani wrote:
2) Class loader per invocation.
I've been less than happy with this, not just because it pollutes the API but
that it adds a layer of confusion. If all use cases discussed can be solved
with (1) above, then I'd prefer to just do that.
On Thu, May 19, 2011 at 10:52, Galder Zamarreño gal...@redhat.com wrote:
Hi all,
So, what's our current approach towards hardcoding maven repositories in the
pom.xml files?
Should we allow JBoss repos to be defined master/parent/pom.xml? This was
added by Adrian C when he upgraded
On May 19, 2011, at 11:45 AM, Galder Zamarreño wrote:
On May 18, 2011, at 6:06 PM, Manik Surtani wrote:
2) Class loader per invocation.
I've been less than happy with this, not just because it pollutes the API
but that it adds a layer of confusion. If all use cases discussed can be
On Thu, May 19, 2011 at 12:18, Pete Muir pm...@redhat.com wrote:
Maven guys used to recommend not putting repos in poms, but they changed that
a while back and now don't discourage it.
Don't know about that, but if you want something in Maven Central, it
cannot depend on external repos. You
2011/5/19 Pete Muir pm...@redhat.com:
The one argument for putting the (new) repo in the pom is that does make
getting started contributing easier, and buildable on a clean system with no
changes.
Maven guys used to recommend not putting repos in poms, but they changed that
a while back
On 19 May 2011, at 11:39, Tristan Tarrant wrote:
On Thu, May 19, 2011 at 12:18, Pete Muir pm...@redhat.com wrote:
Maven guys used to recommend not putting repos in poms, but they changed
that a while back and now don't discourage it.
Don't know about that, but if you want something in
Hi all,
Re: https://issues.jboss.org/browse/ISPN-1102
First of all thanks to Dan for his suggestion on reservoir
sampling+percentiles, very good suggestion:). So, I'm looking into this and
Trustin's
On 19 May 2011, at 11:47, Tristan Tarrant wrote:
On Thu, May 19, 2011 at 12:40, Sanne Grinovero
sanne.grinov...@gmail.com wrote:
I also assume that at some point we might want to have our artifacts
synched with central, I doubt they will accept poms pointing to other
repositories, that was
On 19 May 2011, at 11:40, Sanne Grinovero wrote:
2011/5/19 Pete Muir pm...@redhat.com:
The one argument for putting the (new) repo in the pom is that does make
getting started contributing easier, and buildable on a clean system with no
changes.
Maven guys used to recommend not putting
Assuming escape analysis does its job, Bela's idea makes sense. But,
I'm not sure it's always enabled in Java 6 or non-Oracle VMs.
What about using adaptive prediction, and copy the buffer to the array
of right size when prediction is way off?
On 05/19/2011 10:35 PM, Bela Ban wrote:
Have we
On Thu, May 19, 2011 at 1:31 PM, Galder Zamarreño gal...@redhat.com wrote:
On May 19, 2011, at 12:11 PM, Manik Surtani wrote:
Guys - what are we talking about? Specifying ClassLoaders is only
meaningful if storeAsBinary is set to true.
Ok, that was not clear to me throughout the
As mentioned on the user forum [1], people setting up a JDBC
cacheloader need to be able to define the size of columns to be used.
The Lucene Directory has a feature to autonomously chunk the segment
contents at a configurable specified byte number, and so has the
GridFS; still there are other
Am 18.05.11 13:19, schrieb Manik Surtani:
On 18 May 2011, at 12:07, 이희승 (Trustin Lee) wrote:
And finally there is that eternal question of how to properly name those
interface methods. Trustin has expressed his concern that
writeToKey(...), removeKey() and readFromKey(...) might fail to
On 05/20/2011 03:06 AM, Sanne Grinovero wrote:
As mentioned on the user forum [1], people setting up a JDBC
cacheloader need to be able to define the size of columns to be used.
The Lucene Directory has a feature to autonomously chunk the segment
contents at a configurable specified byte
18 matches
Mail list logo
