11:42 a.m.
Guys
I'm just looking at having Infinispan sync'd to Maven central. One issue raised is
that we have a number of releases which refer to SNAPSHOT dependencies (which is a really
bad idea anyway). I can have them sync only 5.1.0 releases newer ALPHA1 which appear to be
clear. But if we do this, we need to be much more careful going forward about not using
SNAPSHOTs in releases.
WDYT? IMO We should definitely do this, it's good practice anyway, and much easier for
users as a result.
Pete
11:52 a.m.
right, sounds a reasonable requirement. Any suggestion to automate this check?
Since we use scripts for the release anyway, it shouldn't be hard to
add an extra step and sign the artifacts too: that's appreciated by
some.
Sanne
On 20 October 2011 17:42, Pete Muir <pmuir(a)redhat.com> wrote:
Guys
I'm just looking at having Infinispan sync'd to Maven central. One issue raised
is that we have a number of releases which refer to SNAPSHOT dependencies (which is a
really bad idea anyway). I can have them sync only 5.1.0 releases newer ALPHA1 which
appear to be clear. But if we do this, we need to be much more careful going forward about
not using SNAPSHOTs in releases.
WDYT? IMO We should definitely do this, it's good practice anyway, and much easier
for users as a result.
Pete
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
11:57 a.m.
On 20 Oct 2011, at 17:52, Sanne Grinovero wrote:
right, sounds a reasonable requirement. Any suggestion to automate
this check?
Use regexp and parse the transformed-for-release (i.e. with their own versions swapped
out) for SNAPSHOT? That's what I've used before and it works.
Since we use scripts for the release anyway, it shouldn't be hard
to
add an extra step and sign the artifacts too: that's appreciated by
some.
Yes. Here is my guide to using signing -
http://seamframework.org/Weld/WeldReleasesGettingStarted#H-PublishingBuil... - and
here is the plugin config I used in the release profile
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-gpg-plugin</artifactId>
<configuration>
<passphrase>${gpg.passphrase}</passphrase>
<useAgent>${gpg.useAgent}</useAgent>
</configuration>
<executions>
<execution>
<id>sign-artifacts</id>
<phase>verify</phase>
<goals>
<goal>sign</goal>
</goals>
</execution>
</executions>
</plugin>
12:01 p.m.
On 20 Oct 2011, at 17:57, Pete Muir wrote:
On 20 Oct 2011, at 17:52, Sanne Grinovero wrote:
> right, sounds a reasonable requirement. Any suggestion to automate this check?
Use regexp and parse the transformed-for-release (i.e. with their own versions swapped
out) for SNAPSHOT? That's what I've used before and it works.
Actually a better approach is:
1) Make sure snapshot repos are explicitly disabled on release (this is good practice)
2) Run the build against an empty maven repo (this is good practice as it ensures the
build is reproducible without your local junk). To do this use
-Dmaven.repo.local=/some/tmp/path
This will then ensure we don't have any snapshots at all in the build.
BTW the eventual goal is to be able to have POMs that don't reference any repositories
at all. However the Maven guys are willing to overlook this whilst we get more stuff
sync'd to central. So if we do this, it's critically important that we don't
add any repositories to POMs. Anything must be proxied through JBoss.org.
We should also do a proper dependency analysis at some point.
I'm also trying to find out if we can get artifact level filters applied, so we can
exclude stuff like jclouds (as it pulls in so much stuff) and focus on syncing core etc.
for now.
> Since we use scripts for the release anyway, it shouldn't be hard to
> add an extra step and sign the artifacts too: that's appreciated by
> some.
Yes. Here is my guide to using signing -
http://seamframework.org/Weld/WeldReleasesGettingStarted#H-PublishingBuil... - and
here is the plugin config I used in the release profile
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-gpg-plugin</artifactId>
<configuration>
<passphrase>${gpg.passphrase}</passphrase>
<useAgent>${gpg.useAgent}</useAgent>
</configuration>
<executions>
<execution>
<id>sign-artifacts</id>
<phase>verify</phase>
<goals>
<goal>sign</goal>
</goals>
</execution>
</executions>
</plugin>
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
12:24 p.m.
On 20 October 2011 18:01, Pete Muir <pmuir(a)redhat.com> wrote:
On 20 Oct 2011, at 17:57, Pete Muir wrote:
> On 20 Oct 2011, at 17:52, Sanne Grinovero wrote:
>
>> right, sounds a reasonable requirement. Any suggestion to automate this check?
>
> Use regexp and parse the transformed-for-release (i.e. with their own versions
swapped out) for SNAPSHOT? That's what I've used before and it works.
Actually a better approach is:
1) Make sure snapshot repos are explicitly disabled on release (this is good practice)
+1, it should be easy to have a settings.xml around for Infinispan
releases. Actually assuming the security tokens can be externalized
this could be committed with the release scripts.
2) Run the build against an empty maven repo (this is good practice
as it ensures the build is reproducible without your local junk). To do this use
-Dmaven.repo.local=/some/tmp/path
This will then ensure we don't have any snapshots at all in the build.
Right, and could be included in the custom settings.xml as well.
Or just use:
mvn dependency:purge-local-repository
But I don't trust that as much as the empty repository ;)
BTW the eventual goal is to be able to have POMs that don't
reference any repositories at all. However the Maven guys are willing to overlook this
whilst we get more stuff sync'd to central. So if we do this, it's critically
important that we don't add any repositories to POMs. Anything must be proxied through
JBoss.org.
I can't find any <repository> element left? We've been fighting this
for some time already.
We should also do a proper dependency analysis at some point.
The only weirdness I see is the org.rhq.helpers stuff. It's mostly
flagged optional or provided but it's a lie, it's required and depends
on lots of pointless stuff (like Hibernate 3 ??).
For the rest, I'm monitoring it regularly but some help on it is always welcome.
I'm also trying to find out if we can get artifact level filters
applied, so we can exclude stuff like jclouds (as it pulls in so much stuff) and focus on
syncing core etc. for now.
I don't see it importing additional repositories; how is that a problem?
Sanne
12:28 p.m.
On 20 Oct 2011, at 18:24, Sanne Grinovero wrote:
On 20 October 2011 18:01, Pete Muir <pmuir(a)redhat.com> wrote:
> On 20 Oct 2011, at 17:57, Pete Muir wrote:
>> On 20 Oct 2011, at 17:52, Sanne Grinovero wrote:
>>
>>> right, sounds a reasonable requirement. Any suggestion to automate this
check?
>>
>> Use regexp and parse the transformed-for-release (i.e. with their own versions
swapped out) for SNAPSHOT? That's what I've used before and it works.
>
> Actually a better approach is:
>
> 1) Make sure snapshot repos are explicitly disabled on release (this is good
practice)
+1, it should be easy to have a settings.xml around for Infinispan
releases. Actually assuming the security tokens can be externalized
this could be committed with the release scripts.
> 2) Run the build against an empty maven repo (this is good practice as it ensures the
build is reproducible without your local junk). To do this use
-Dmaven.repo.local=/some/tmp/path
>
> This will then ensure we don't have any snapshots at all in the build.
Right, and could be included in the custom settings.xml as well.
Or just use:
mvn dependency:purge-local-repository
But I don't trust that as much as the empty repository ;)
:-)
> BTW the eventual goal is to be able to have POMs that don't reference any
repositories at all. However the Maven guys are willing to overlook this whilst we get
more stuff sync'd to central. So if we do this, it's critically important that we
don't add any repositories to POMs. Anything must be proxied through JBoss.org.
I can't find any <repository> element left? We've been fighting this
for some time already.
https://github.com/infinispan/infinispan/blob/master/parent/pom.xml#L697
Just the JBoss repo.
> We should also do a proper dependency analysis at some point.
The only weirdness I see is the org.rhq.helpers stuff. It's mostly
flagged optional or provided but it's a lie, it's required and depends
on lots of pointless stuff (like Hibernate 3 ??).
For the rest, I'm monitoring it regularly but some help on it is always welcome.
> I'm also trying to find out if we can get artifact level filters applied, so we
can exclude stuff like jclouds (as it pulls in so much stuff) and focus on syncing core
etc. for now.
I don't see it importing additional repositories; how is that a problem?
I think we managed to proxy all of it through the JBoss repo. But if we eventually are
aiming to get rid of that as well...
4:46 a.m.
On Oct 20, 2011, at 7:24 PM, Sanne Grinovero wrote:
On 20 October 2011 18:01, Pete Muir <pmuir(a)redhat.com> wrote:
> On 20 Oct 2011, at 17:57, Pete Muir wrote:
>> On 20 Oct 2011, at 17:52, Sanne Grinovero wrote:
>>
>>> right, sounds a reasonable requirement. Any suggestion to automate this
check?
>>
>> Use regexp and parse the transformed-for-release (i.e. with their own versions
swapped out) for SNAPSHOT? That's what I've used before and it works.
>
> Actually a better approach is:
>
> 1) Make sure snapshot repos are explicitly disabled on release (this is good
practice)
+1, it should be easy to have a settings.xml around for Infinispan
releases. Actually assuming the security tokens can be externalized
this could be committed with the release scripts.
> 2) Run the build against an empty maven repo (this is good practice as it ensures the
build is reproducible without your local junk). To do this use
-Dmaven.repo.local=/some/tmp/path
>
> This will then ensure we don't have any snapshots at all in the build.
Right, and could be included in the custom settings.xml as well.
Or just use:
mvn dependency:purge-local-repository
Don't really wanna purge my local repo unless I have a very good reason to do it cos
it'd take forever to recreate.
Using an alternative -Dmaven.repo.local=/some/tmp/path when you're releasing sounds
like a much more sane option.
But I don't trust that as much as the empty repository ;)
> BTW the eventual goal is to be able to have POMs that don't reference any
repositories at all. However the Maven guys are willing to overlook this whilst we get
more stuff sync'd to central. So if we do this, it's critically important that we
don't add any repositories to POMs. Anything must be proxied through JBoss.org.
I can't find any <repository> element left? We've been fighting this
for some time already.
> We should also do a proper dependency analysis at some point.
The only weirdness I see is the org.rhq.helpers stuff. It's mostly
flagged optional or provided but it's a lie, it's required and depends
on lots of pointless stuff (like Hibernate 3 ??).
There's two aspects to this:
1. We hijack javadoc processing to generate the RHQ xml file, which means that the
annotations need be available beyond the compile phase. This forces the annotation, and
rhq annotations, dependencies to be required. At the time of writing this, I wasn't
aware of annotation processors and that would have been the right way to solve this issue.
That should avoid dependencies going beyond compilation time, but would bring other
issues, i.e. annotation processor discovery (we'd need one for JBoss Logging and one
for this)…etc.
2. RHQ dependencies themselves which are rather dubious.
For the rest, I'm monitoring it regularly but some help on it is
always welcome.
> I'm also trying to find out if we can get artifact level filters applied, so we
can exclude stuff like jclouds (as it pulls in so much stuff) and focus on syncing core
etc. for now.
I don't see it importing additional repositories; how is that a problem?
Sanne
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
5:05 a.m.
>
> The only weirdness I see is the org.rhq.helpers stuff. It's mostly
> flagged optional or provided but it's a lie, it's required and depends
> on lots of pointless stuff (like Hibernate 3 ??).
There's two aspects to this:
1. We hijack javadoc processing to generate the RHQ xml file, which means that the
annotations need be available beyond the compile phase. This forces the annotation, and
rhq annotations, dependencies to be required. At the time of writing this, I wasn't
aware of annotation processors and that would have been the right way to solve this issue.
That should avoid dependencies going beyond compilation time, but would bring other
issues, i.e. annotation processor discovery (we'd need one for JBoss Logging and one
for this)…etc.
What has annotation processor discovery to do with RHQ?
2. RHQ dependencies themselves which are rather dubious.
yes, can we move this to a separate module? Why does Infinispan core need them?
5:48 a.m.
On Oct 24, 2011, at 12:05 PM, Sanne Grinovero wrote:
>>
>> The only weirdness I see is the org.rhq.helpers stuff. It's mostly
>> flagged optional or provided but it's a lie, it's required and depends
>> on lots of pointless stuff (like Hibernate 3 ??).
>
> There's two aspects to this:
>
> 1. We hijack javadoc processing to generate the RHQ xml file, which means that the
annotations need be available beyond the compile phase. This forces the annotation, and
rhq annotations, dependencies to be required. At the time of writing this, I wasn't
aware of annotation processors and that would have been the right way to solve this issue.
That should avoid dependencies going beyond compilation time, but would bring other
issues, i.e. annotation processor discovery (we'd need one for JBoss Logging and one
for this)…etc.
What has annotation processor discovery to do with RHQ?
All JMX methods are annotated with JMX annotations and RHQ annotations too. The latter are
used to generate the RHQ configuration file which is what tells RHQ what a jmx value is
used for, whether a numeric measuremen, a text field…etc.
> 2. RHQ dependencies themselves which are rather dubious.
yes, can we move this to a separate module? Why does Infinispan core need them?
See above explanation
CacheMgmtInterceptor:
@ManagedAttribute(description = "Number of entries currently in the cache")
@Metric(displayName = "Number of current cache entries", displayType =
DisplayType.SUMMARY)
public int getNumberOfEntries() {
return dataContainer.size();
}
@Metric is an RHQ annotation
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
6:04 a.m.
>> 1. We hijack javadoc processing to generate the RHQ xml file,
which means that the annotations need be available beyond the compile phase. This forces
the annotation, and rhq annotations, dependencies to be required. At the time of writing
this, I wasn't aware of annotation processors and that would have been the right way
to solve this issue. That should avoid dependencies going beyond compilation time, but
would bring other issues, i.e. annotation processor discovery (we'd need one for JBoss
Logging and one for this)…etc.
>
> What has annotation processor discovery to do with RHQ?
All JMX methods are annotated with JMX annotations and RHQ annotations too. The latter
are used to generate the RHQ configuration file which is what tells RHQ what a jmx value
is used for, whether a numeric measuremen, a text field…etc.
I see, but this package only includes plain annotations right? Even
looking into the infinispan-tool package I don't see annotation
PROCESSORS, are we making confusion on the terms here?
Also when I explicitly disabled annotation processors discovery to
list only the jboss-logger this didn't break.
4:57 a.m.
On Oct 24, 2011, at 12:04 PM, Sanne Grinovero wrote:
>>> 1. We hijack javadoc processing to generate the RHQ xml
file, which means that the annotations need be available beyond the compile phase. This
forces the annotation, and rhq annotations, dependencies to be required. At the time of
writing this, I wasn't aware of annotation processors and that would have been the
right way to solve this issue. That should avoid dependencies going beyond compilation
time, but would bring other issues, i.e. annotation processor discovery (we'd need one
for JBoss Logging and one for this)…etc.
>>
>> What has annotation processor discovery to do with RHQ?
>
> All JMX methods are annotated with JMX annotations and RHQ annotations too. The
latter are used to generate the RHQ configuration file which is what tells RHQ what a jmx
value is used for, whether a numeric measuremen, a text field…etc.
I see, but this package only includes plain annotations right? Even
looking into the infinispan-tool package I don't see annotation
PROCESSORS, are we making confusion on the terms here?
Also when I explicitly disabled annotation processors discovery to
list only the jboss-logger this didn't break.
Yeah, it only contains annotations. I might have been confusing with the actual RHQ
dependencies that the rhq-plugin/ module has, which might have a Hibernate 3.x
dependency.
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
5:35 a.m.
Are the annotations source retention only?
On 24 Oct 2011, at 10:46, Galder Zamarreño wrote:
On Oct 20, 2011, at 7:24 PM, Sanne Grinovero wrote:
> On 20 October 2011 18:01, Pete Muir <pmuir(a)redhat.com> wrote:
>> On 20 Oct 2011, at 17:57, Pete Muir wrote:
>>> On 20 Oct 2011, at 17:52, Sanne Grinovero wrote:
>>>
>>>> right, sounds a reasonable requirement. Any suggestion to automate this
check?
>>>
>>> Use regexp and parse the transformed-for-release (i.e. with their own
versions swapped out) for SNAPSHOT? That's what I've used before and it works.
>>
>> Actually a better approach is:
>>
>> 1) Make sure snapshot repos are explicitly disabled on release (this is good
practice)
>
> +1, it should be easy to have a settings.xml around for Infinispan
> releases. Actually assuming the security tokens can be externalized
> this could be committed with the release scripts.
>
>> 2) Run the build against an empty maven repo (this is good practice as it ensures
the build is reproducible without your local junk). To do this use
-Dmaven.repo.local=/some/tmp/path
>>
>> This will then ensure we don't have any snapshots at all in the build.
>
> Right, and could be included in the custom settings.xml as well.
> Or just use:
> mvn dependency:purge-local-repository
Don't really wanna purge my local repo unless I have a very good reason to do it cos
it'd take forever to recreate.
Using an alternative -Dmaven.repo.local=/some/tmp/path when you're releasing sounds
like a much more sane option.
>
> But I don't trust that as much as the empty repository ;)
>
>> BTW the eventual goal is to be able to have POMs that don't reference any
repositories at all. However the Maven guys are willing to overlook this whilst we get
more stuff sync'd to central. So if we do this, it's critically important that we
don't add any repositories to POMs. Anything must be proxied through JBoss.org.
>
> I can't find any <repository> element left? We've been fighting this
> for some time already.
>
>> We should also do a proper dependency analysis at some point.
>
> The only weirdness I see is the org.rhq.helpers stuff. It's mostly
> flagged optional or provided but it's a lie, it's required and depends
> on lots of pointless stuff (like Hibernate 3 ??).
There's two aspects to this:
1. We hijack javadoc processing to generate the RHQ xml file, which means that the
annotations need be available beyond the compile phase. This forces the annotation, and
rhq annotations, dependencies to be required. At the time of writing this, I wasn't
aware of annotation processors and that would have been the right way to solve this issue.
That should avoid dependencies going beyond compilation time, but would bring other
issues, i.e. annotation processor discovery (we'd need one for JBoss Logging and one
for this)…etc.
2. RHQ dependencies themselves which are rather dubious.
> For the rest, I'm monitoring it regularly but some help on it is always welcome.
>
>> I'm also trying to find out if we can get artifact level filters applied, so
we can exclude stuff like jclouds (as it pulls in so much stuff) and focus on syncing core
etc. for now.
>
> I don't see it importing additional repositories; how is that a problem?
>
> Sanne
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
4:56 a.m.
Nope, they're RUNTIME at the moment. Ian Springer's checking the retention policy
could be altered. In the current config, they need to be available to a maven javadoc step
where we generate the RHQ xml file.
On Oct 25, 2011, at 11:35 AM, Pete Muir wrote:
Are the annotations source retention only?
On 24 Oct 2011, at 10:46, Galder Zamarreño wrote:
>
> On Oct 20, 2011, at 7:24 PM, Sanne Grinovero wrote:
>
>> On 20 October 2011 18:01, Pete Muir <pmuir(a)redhat.com> wrote:
>>> On 20 Oct 2011, at 17:57, Pete Muir wrote:
>>>> On 20 Oct 2011, at 17:52, Sanne Grinovero wrote:
>>>>
>>>>> right, sounds a reasonable requirement. Any suggestion to automate
this check?
>>>>
>>>> Use regexp and parse the transformed-for-release (i.e. with their own
versions swapped out) for SNAPSHOT? That's what I've used before and it works.
>>>
>>> Actually a better approach is:
>>>
>>> 1) Make sure snapshot repos are explicitly disabled on release (this is good
practice)
>>
>> +1, it should be easy to have a settings.xml around for Infinispan
>> releases. Actually assuming the security tokens can be externalized
>> this could be committed with the release scripts.
>>
>>> 2) Run the build against an empty maven repo (this is good practice as it
ensures the build is reproducible without your local junk). To do this use
-Dmaven.repo.local=/some/tmp/path
>>>
>>> This will then ensure we don't have any snapshots at all in the build.
>>
>> Right, and could be included in the custom settings.xml as well.
>> Or just use:
>> mvn dependency:purge-local-repository
>
> Don't really wanna purge my local repo unless I have a very good reason to do it
cos it'd take forever to recreate.
>
> Using an alternative -Dmaven.repo.local=/some/tmp/path when you're releasing
sounds like a much more sane option.
>
>>
>> But I don't trust that as much as the empty repository ;)
>>
>>> BTW the eventual goal is to be able to have POMs that don't reference any
repositories at all. However the Maven guys are willing to overlook this whilst we get
more stuff sync'd to central. So if we do this, it's critically important that we
don't add any repositories to POMs. Anything must be proxied through JBoss.org.
>>
>> I can't find any <repository> element left? We've been fighting
this
>> for some time already.
>>
>>> We should also do a proper dependency analysis at some point.
>>
>> The only weirdness I see is the org.rhq.helpers stuff. It's mostly
>> flagged optional or provided but it's a lie, it's required and depends
>> on lots of pointless stuff (like Hibernate 3 ??).
>
> There's two aspects to this:
>
> 1. We hijack javadoc processing to generate the RHQ xml file, which means that the
annotations need be available beyond the compile phase. This forces the annotation, and
rhq annotations, dependencies to be required. At the time of writing this, I wasn't
aware of annotation processors and that would have been the right way to solve this issue.
That should avoid dependencies going beyond compilation time, but would bring other
issues, i.e. annotation processor discovery (we'd need one for JBoss Logging and one
for this)…etc.
>
> 2. RHQ dependencies themselves which are rather dubious.
>
>
>> For the rest, I'm monitoring it regularly but some help on it is always
welcome.
>>
>>> I'm also trying to find out if we can get artifact level filters applied,
so we can exclude stuff like jclouds (as it pulls in so much stuff) and focus on syncing
core etc. for now.
>>
>> I don't see it importing additional repositories; how is that a problem?
>>
>> Sanne
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> --
> Galder Zamarreño
> Sr. Software Engineer
> Infinispan, JBoss Cache
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
11:20 a.m.
+1, also all for making sure we don't have any SNAPSHOT dependencies moving forward.
As you say it is a bad idea.
On 20 Oct 2011, at 17:42, Pete Muir wrote:
Guys
I'm just looking at having Infinispan sync'd to Maven central. One issue raised
is that we have a number of releases which refer to SNAPSHOT dependencies (which is a
really bad idea anyway). I can have them sync only 5.1.0 releases newer ALPHA1 which
appear to be clear. But if we do this, we need to be much more careful going forward about
not using SNAPSHOTs in releases.
WDYT? IMO We should definitely do this, it's good practice anyway, and much easier
for users as a result.
Pete
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Manik Surtani
manik(a)jboss.org
twitter.com/maniksurtani
Lead, Infinispan
http://www.infinispan.org
5092
days inactive
5098
days old
infinispan-dev@lists.jboss.org
13 comments
4 participants
participants (4)
-
Galder Zamarreño -
Manik Surtani -
Pete Muir -
Sanne Grinovero