On Tue, Apr 24, 2012 at 10:45 AM, Uwe Schindler wrote:
> Hi,
>
>> BTW, fedora 16 has lucene 2.9.4 and does not have solr. Looks like F17 will
>> have the same. I'd also be interested to know why they don't have 3.x or
>> solr.
>
> I think that unrelated here, but the answer is simple: Those distr
Hi,
> BTW, fedora 16 has lucene 2.9.4 and does not have solr. Looks like F17 will
> have the same. I'd also be interested to know why they don't have 3.x or solr.
I think that unrelated here, but the answer is simple: Those distributions
don't have Lucene JARS to provide "Lucene" as a library to
Responding to the thread as a whole, having read it with great interest.
I'd be interested to know what packagers for distributions such as
debian and fedora do with systems that patch 3rd party dependencies.
I'll guess that if it is internalized as mentioned below that there is
no problem.
On Tue, Apr 24, 2012 at 9:57 AM, Benson Margulies wrote:
> Maven does not, in fact, require publication in this case. An
> ephemeral jar can travel into a war or an assembly without ever being
> published.
>
OK, I opened https://issues.apache.org/jira/browse/SOLR-3405: maven
artifacts should mat
On Tue, Apr 24, 2012 at 9:57 AM, Benson Margulies wrote:
> Maven is guilty as charged that the simple, obvious, way of dealing
> with this requires publication. In the pressurized circumstances of
> 3.6.0, no one was going to get past that. Now, we can if you want.
>
well FWIW: we got past it fo
>
> Putting someone's jar inside a lib/ folder or war as a dependency is
> hardly 'publishing'.
>
> Its maven that requires 'publishing' and that causes all the fuss.
>
> I've tried to explain this over and over again, but maven supporters
> just get defensive and claim its not a maven problem: but
On Tue, Apr 24, 2012 at 9:26 AM, Nicolas Lalevée
wrote:
>> The rule we are dealing with goes as follows, stated pseudo-biblically:
>>
>> * No PMC shall publish a JAR file containing modified versions of some
>> other PMC's output unless you change the package names.
>
> Does this apply to any bin
Le 24 avr. 2012 à 03:10, Benson Margulies a écrit :
> On Mon, Apr 23, 2012 at 8:42 PM, Chris Male wrote:
>> I'm with Steve here, -1. I think the arguments have already been well
>> articulated and the issue seems to be about dependency management in general
>> not just about Maven. However I a
On Tue, Apr 24, 2012 at 7:12 AM, Michael McCandless
wrote:
> This thread is impossible for me to keep up with!
It's a very complex topic, and I wish I could find more concise ways
to talk about it.
Anyhow, since you all seem to have a consensus not to push the rewind
button back to the days of '
This thread is impossible for me to keep up with! Some responses:
> In fact, I expect if there is real demand, a downstream contributor
> would easily pick this up.
Exactly: just like the numerous useful Linux repositories... it's
clearly not this PMC's job to push to all of those repositories.
On Mon, Apr 23, 2012 at 8:42 PM, Chris Male wrote:
> I'm with Steve here, -1. I think the arguments have already been well
> articulated and the issue seems to be about dependency management in general
> not just about Maven. However I also absolutely agree with Robert that we
> need to make thi
On Mon, Apr 23, 2012 at 8:28 PM, Benson Margulies wrote:
>
> If you like (or can live with) everything about the situation except
> for the additional Maven burden, then it's worthwhile for us
> Maven-heads to offer schemes that purport to do Maven without making
> it (much) worse. But if the situ
I'm with Steve here, -1. I think the arguments have already been well
articulated and the issue seems to be about dependency management in
general not just about Maven. However I also absolutely agree with Robert
that we need to make this easier somehow.
One thing I thought, is there any way we
> Its definitely overwhelming right now, the size of the codebase and
> the number of dependencies, given what we have. I think we should be
> considering all options. Maven packaging just adds to the complexity
> due to the fact of how it manages dependencies (they must themselves
> be in maven so
> for Solr, as an application, maybe we should just be making a massive
> solr.jar anyway for the binary release that you java -jar (leaving the
> webapp as an implementation detail or something):
The solr application is solr.war (not .jar) -- we can safely dump
whatever hacked/patched jar files i
On Mon, Apr 23, 2012 at 7:46 PM, Benson Margulies wrote:
> It makes perfect sense. Some of us do, however, embed Solr (for tests
> or other unrecommended reasons), or build our own Solr plugins with
> dependencies on the existing Solr plugins, and we would thus mourn, or
> have to go back to doing
On Mon, Apr 23, 2012 at 7:45 PM, Robert Muir wrote:
> On Mon, Apr 23, 2012 at 7:31 PM, Benson Margulies
> wrote:
>> I have a suggestion for how to get from here to the exit.
>>
>> Forget about maven for the moment, and please explain to me exactly
>> how you'd like to handle bugfixes to other Ap
On Mon, Apr 23, 2012 at 7:30 PM, Robert Muir wrote:
> On Mon, Apr 23, 2012 at 6:49 PM, Benson Margulies
> wrote:
>> On Mon, Apr 23, 2012 at 6:31 PM, Robert Muir wrote:
>>> On Mon, Apr 23, 2012 at 6:28 PM, Dawid Weiss
>>> wrote:
The issue with such poms is that once you want to publis
On Mon, Apr 23, 2012 at 7:31 PM, Benson Margulies wrote:
> I have a suggestion for how to get from here to the exit.
>
> Forget about maven for the moment, and please explain to me exactly
> how you'd like to handle bugfixes to other Apache items in releases if
> all you had to worry about was ant
On Mon, Apr 23, 2012 at 7:21 PM, Robert Muir wrote:
> On Mon, Apr 23, 2012 at 6:49 PM, Benson Margulies
> wrote:
>
>> Thus, I claim that this debate is fundamentally about package
>> renaming, not publication.
>>
>> Shall I be maximally annoying and mention OSGi again?
>>
>
> Its not really a de
On Mon, Apr 23, 2012 at 6:49 PM, Benson Margulies wrote:
> On Mon, Apr 23, 2012 at 6:31 PM, Robert Muir wrote:
>> On Mon, Apr 23, 2012 at 6:28 PM, Dawid Weiss
>> wrote:
>>>
>>> The issue with such poms is that once you want to publish your stuff
>>> to maven central it won't work (because all de
On Mon, Apr 23, 2012 at 6:49 PM, Benson Margulies wrote:
> Thus, I claim that this debate is fundamentally about package
> renaming, not publication.
>
> Shall I be maximally annoying and mention OSGi again?
>
Its not really a debate, its 'how do we do this'. (I can argue your
claim is wrong, bu
On Mon, Apr 23, 2012 at 6:31 PM, Robert Muir wrote:
> On Mon, Apr 23, 2012 at 6:28 PM, Dawid Weiss
> wrote:
>>
>> The issue with such poms is that once you want to publish your stuff
>> to maven central it won't work (because all dependencies must be
>> available and there is no "local" repositor
On Mon, Apr 23, 2012 at 6:28 PM, Dawid Weiss
wrote:
>
> The issue with such poms is that once you want to publish your stuff
> to maven central it won't work (because all dependencies must be
> available and there is no "local" repository).
>
This is the problem I am asking about.
I don't care a
>> And now you hit the nail on the head. Because your 'option 2'
>> (download+patch) with ivy doesnt involve 'publishing'. we just
>> download and patch.
You can take a look at Google Caliper -- they used maven for building
but required
JARs that were inside the project (not on maven central). The
On Mon, Apr 23, 2012 at 6:15 PM, Robert Muir wrote:
> On Mon, Apr 23, 2012 at 6:13 PM, Benson Margulies
> wrote:
>> On Mon, Apr 23, 2012 at 5:49 PM, Robert Muir wrote:
>>> On Mon, Apr 23, 2012 at 5:47 PM, Benson Margulies
>>> wrote:
>>>
b) Create a patching process that grabs their relea
On Mon, Apr 23, 2012 at 6:11 PM, Dawid Weiss
wrote:
>> I feel that currently, there is no option (maven limits us here). I'm
>> not sure if thats due to actual technical limitations in maven, or
>
> What Benson mentioned will work for maven, I don't see how it holds
> you back. If you publish an a
On Mon, Apr 23, 2012 at 6:13 PM, Benson Margulies wrote:
> On Mon, Apr 23, 2012 at 5:49 PM, Robert Muir wrote:
>> On Mon, Apr 23, 2012 at 5:47 PM, Benson Margulies
>> wrote:
>>
>>> b) Create a patching process that grabs their release package, fixes
>>> it, and builds it, renaming packages. Inc
On Mon, Apr 23, 2012 at 5:49 PM, Robert Muir wrote:
> On Mon, Apr 23, 2012 at 5:47 PM, Benson Margulies
> wrote:
>
>> b) Create a patching process that grabs their release package, fixes
>> it, and builds it, renaming packages. Include the patching process in
>> your source release.
>>
>
> I wou
> I feel that currently, there is no option (maven limits us here). I'm
> not sure if thats due to actual technical limitations in maven, or
What Benson mentioned will work for maven, I don't see how it holds
you back. If you publish an artefact for Ivy somewhere you can package
this JAR and publi
On 4/23/2012 at 5:58 PM, Robert Muir wrote:
> I feel that currently, there is no option (maven limits us here).
> I'm not sure if thats due to actual technical limitations in maven,
> or just because its complicated or unconventional or whatever, but
> I don't think we should let maven hold us bac
On Mon, Apr 23, 2012 at 5:54 PM, Mark Miller wrote:
>
> On Apr 23, 2012, at 5:46 PM, Uwe Schindler wrote:
>
>> And OUR source code was correct - PERIOD.
>
> I think more important than our code being correct is that our distributions
> work correctly. Being correct for the sake of it has no prac
On Apr 23, 2012, at 5:46 PM, Uwe Schindler wrote:
> And OUR source code was correct - PERIOD.
I think more important than our code being correct is that our distributions
work correctly. Being correct for the sake of it has no practical value. We
should strive for the best user experience. T
gt; From: Robert Muir [mailto:[email protected]]
> Sent: Monday, April 23, 2012 11:50 PM
> To: [email protected]
> Subject: Re: [DISCUSS] Build/deploy Maven artifacts outside of Lucene/Solr
>
> On Mon, Apr 23, 2012 at 5:47 PM, Benson Margulies
> wrote:
>
> > b) Create a p
On Mon, Apr 23, 2012 at 5:47 PM, Benson Margulies wrote:
> b) Create a patching process that grabs their release package, fixes
> it, and builds it, renaming packages. Include the patching process in
> your source release.
>
I would *love* to be able to have this option available, but how will
t
On Mon, Apr 23, 2012 at 5:40 PM, Dawid Weiss
wrote:
>> Instead I'm asking how we handle bugfixes.
>
> This is a real problem. I've gone through this with recent updates to
> randomizedtesting package. There is
> no "clean" way of integrating a snapshot build or an interim package.
Thank you! This
Rob,
I personally think that the Apache policy issues here are not entirely
worked out, but let me try to summarize the situation.
Starting condition: a marooned bugfix or feature in some other Apache TLP.
1. Communicate with the other TLP, possibly siccing Uwe on their chair.
2. If they are un
remen
http://www.thetaphi.de
eMail: [email protected]
> -Original Message-
> From: Robert Muir [mailto:[email protected]]
> Sent: Monday, April 23, 2012 11:39 PM
> To: [email protected]
> Subject: Re: [DISCUSS] Build/deploy Maven artifacts outside of Lucene/Solr
>
> On Mo
> Instead I'm asking how we handle bugfixes.
This is a real problem. I've gone through this with recent updates to
randomizedtesting package. There is
no "clean" way of integrating a snapshot build or an interim package.
With maven the integration can be done via snapshot repositories
(there are d
On 4/23/2012 at 5:33 PM, Robert Muir wrote:
> On Mon, Apr 23, 2012 at 5:29 PM, Uwe Schindler wrote:
> > Robert: I know that IVY also supports downloading from arbitrary
> > URLs, but that is missing stability and metadata).
>
> My questions have nothing to do with whether or not we release maven
>
On Mon, Apr 23, 2012 at 5:37 PM, Uwe Schindler wrote:
> Hi,
>
> The answer is quite clear: Not our problem! Note that bug in our release
> notes that there is a not-yet fixed zookeeper bug. We cannot make the world
> perfect. If there is a bug outside our responsibility, we can document it,
> b
-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: [email protected]
> -Original Message-
> From: Robert Muir [mailto:[email protected]]
> Sent: Monday, April 23, 2012 11:33 PM
> To: [email protected]
> Subject: Re: [DISCUSS] Build/deploy Maven artifacts outside
On Mon, Apr 23, 2012 at 5:29 PM, Uwe Schindler wrote:
> Robert: I know
> that IVY also supports downloading from arbitrary URLs, but that is missing
> stability and metadata).
>
My questions have nothing to do with whether or not we release maven
artifacts (if you read them, you will see that).
> Unless we get a wave of anti maven sentiment, it looks like things are
staying
> as they are right now anyway though. I just don't think any of us arguing
that
> Maven should not be our responsibility thinks that that would mean Maven
> support for Lucene/Solr would go away.
+1
No Anti-Maven st
[email protected]
> -Original Message-
> From: Steven A Rowe [mailto:[email protected]]
> Sent: Monday, April 23, 2012 11:21 PM
> To: [email protected]
> Subject: RE: [DISCUSS] Build/deploy Maven artifacts outside of Lucene/Solr
>
> On 4/23/2012 at 5:09 PM, Uwe Schindler wrote:
>
On Apr 23, 2012, at 5:09 PM, Uwe Schindler wrote:
> So we must publish maven artifacts to be successful on the open source
> market, sorry! (that's my opinion!)
I disagree that Lucene/Solr would not be popular if the committers and PMC did
not support Maven. In fact, I expect if there is real
On 4/23/2012 at 5:09 PM, Uwe Schindler wrote:
> Finally, publishing maven artifacts has nothing to do with
> maven at all. We don't need a maven build to do that!
The Maven build is there to enable using Maven to check the correctness of the
POMs. I think this is essential. Prior to this, the L
> copying them to the maven servers can be done completely without maven (at
This is true but doing it via maven (that is: compiling and testing
with actual dependencies) helps you to ensure it really is a usable
artefact. I've been doing tricks like building a JAR in ANT and then
simply attaching
sage-
> From: Michael McCandless [mailto:[email protected]]
> Sent: Monday, April 23, 2012 4:15 PM
> To: Lucene/Solr dev
> Subject: [DISCUSS] Build/deploy Maven artifacts outside of Lucene/Solr
>
> I've had a lingering frustration with the recent blowup due to t
On Mon, Apr 23, 2012 at 4:54 PM, Dawid Weiss
wrote:
>
> I wouldn't be so sure that github's idea is to create endless forks,
> each ending up in a separate distribution :) I think it's to
> facilitate pulling changes back to the origin?
>
Not so sure, the idea is that forking is part of the desig
> If these projects don't want their code forked... dont offer it up on
> github under the Apache 2.0 license?
I wouldn't be so sure that github's idea is to create endless forks,
each ending up in a separate distribution :) I think it's to
facilitate pulling changes back to the origin?
Dawid
--
On Mon, Apr 23, 2012 at 4:32 PM, Dawid Weiss
wrote:
>> Its also a good point that what i do on my github account, the apache
>> board has no control over (despite how powerful they might think they
>
> To my best knowledge this is the case, yes. People may not like the
> fact that you re-publish t
> Its also a good point that what i do on my github account, the apache
> board has no control over (despite how powerful they might think they
To my best knowledge this is the case, yes. People may not like the
fact that you re-publish the same code under the same packages but
there's really no r
On Mon, Apr 23, 2012 at 3:53 PM, Dawid Weiss
wrote:
>> Really ??? But they won't criticize the fact someone put
>> http://code.google.com/p/language-detection/ into maven central?
>> http://search.maven.org/#artifactdetails|com.cybozu.labs|langdetect|1.1-20120112|jar
>
> I don't think even people
On Mon, Apr 23, 2012 at 3:53 PM, Dawid Weiss
wrote:
> I don't think even people who first accused Lucene of releasing
> commons-csv artifacts can address your question here. And I think if
> you published commons-csv on github they'd be equally upset.
>
Ok: so we just use https://github.com/Gasol
> Really ??? But they won't criticize the fact someone put
> http://code.google.com/p/language-detection/ into maven central?
> http://search.maven.org/#artifactdetails|com.cybozu.labs|langdetect|1.1-20120112|jar
I don't think even people who first accused Lucene of releasing
commons-csv artifacts
On Mon, Apr 23, 2012 at 3:23 PM, Benson Margulies wrote:
> Rob, did you mean 'Benson' by 'you' in that sentence? If so, I'm
> really sorry if I've given you the impression I think that that
> there's anything amiss with 3.6.0. All I meant to say was that, over
> the long haul, if the PMC was very
On Mon, Apr 23, 2012 at 3:09 PM, Robert Muir wrote:
> On Mon, Apr 23, 2012 at 3:02 PM, Benson Margulies
> wrote:
>>
>> That's right. If you, Rob Muir, just so happen to set up a github
>> project with a fix to Xerces, and I, Benson Margulies, just happen to
>> help you publish it to Maven Centra
On Mon, Apr 23, 2012 at 3:02 PM, Benson Margulies wrote:
>
> That's right. If you, Rob Muir, just so happen to set up a github
> project with a fix to Xerces, and I, Benson Margulies, just happen to
> help you publish it to Maven Central, then the PMC, without (much)
> fear of hassle, can consume
On Mon, Apr 23, 2012 at 2:43 PM, Robert Muir wrote:
> On Mon, Apr 23, 2012 at 2:40 PM, Benson Margulies
> wrote:
>> On Mon, Apr 23, 2012 at 2:32 PM, Robert Muir wrote:
>>> On Mon, Apr 23, 2012 at 2:27 PM, Benson Margulies
>>> wrote:
How do you know it's done 'appropriately' in your scena
On Mon, Apr 23, 2012 at 2:40 PM, Benson Margulies wrote:
> On Mon, Apr 23, 2012 at 2:32 PM, Robert Muir wrote:
>> On Mon, Apr 23, 2012 at 2:27 PM, Benson Margulies
>> wrote:
>>> How do you know it's done 'appropriately' in your scenario? You could
>>> have had just as many board members up your
On Mon, Apr 23, 2012 at 2:32 PM, Robert Muir wrote:
> On Mon, Apr 23, 2012 at 2:27 PM, Benson Margulies
> wrote:
>> How do you know it's done 'appropriately' in your scenario? You could
>> have had just as many board members up your nose by using your
>> ant/github procedure and depositing the r
On Mon, Apr 23, 2012 at 2:27 PM, Benson Margulies wrote:
> How do you know it's done 'appropriately' in your scenario? You could
> have had just as many board members up your nose by using your
> ant/github procedure and depositing the resulting bundle on Apache
> 'dist' as an 'auxiliary binary bu
On Mon, Apr 23, 2012 at 2:20 PM, Robert Muir wrote:
> On Mon, Apr 23, 2012 at 2:17 PM, Benson Margulies
> wrote:
>
>> If it's a maven project, you do the same thing, patching the pom to
>> shade to change the packages if you want, or just changing the
>> coordinates.
>>
>> You publish the result
On Mon, Apr 23, 2012 at 2:17 PM, Benson Margulies wrote:
> If it's a maven project, you do the same thing, patching the pom to
> shade to change the packages if you want, or just changing the
> coordinates.
>
> You publish the results to central via OSSRH under your coordinates.
>
I think this i
On Mon, Apr 23, 2012 at 11:17 AM, Benson Margulies
wrote:
> On Mon, Apr 23, 2012 at 2:10 PM, Robert Muir wrote:
>> On Mon, Apr 23, 2012 at 2:07 PM, Benson Margulies
>> wrote:
How do we handle situations like
https://issues.apache.org/jira/browse/XERCESJ-1257 (open for 5 years,
>>
On Mon, Apr 23, 2012 at 2:10 PM, Robert Muir wrote:
> On Mon, Apr 23, 2012 at 2:07 PM, Benson Margulies
> wrote:
>>>
>>> How do we handle situations like
>>> https://issues.apache.org/jira/browse/XERCESJ-1257 (open for 5 years,
>>> still not incorporated in a release), without doing hackish thin
On Mon, Apr 23, 2012 at 2:10 PM, Robert Muir wrote:
> On Mon, Apr 23, 2012 at 2:07 PM, Benson Margulies
> wrote:
>>>
>>> How do we handle situations like
>>> https://issues.apache.org/jira/browse/XERCESJ-1257 (open for 5 years,
>>> still not incorporated in a release), without doing hackish thin
On Mon, Apr 23, 2012 at 2:07 PM, Benson Margulies wrote:
>>
>> How do we handle situations like
>> https://issues.apache.org/jira/browse/XERCESJ-1257 (open for 5 years,
>> still not incorporated in a release), without doing hackish things
>> (releasing someone elses code, sucking their entire code
>
> How do we handle situations like
> https://issues.apache.org/jira/browse/XERCESJ-1257 (open for 5 years,
> still not incorporated in a release), without doing hackish things
> (releasing someone elses code, sucking their entire codebase into
> ours), or relying upon Uwe Schindler to come up wit
On Mon, Apr 23, 2012 at 1:45 PM, Benson Margulies wrote:
> Publishing artifacts benefits users; I acknowledge that you accept
> that, and are weighing it against costs. Taking on this publication
> process is like any adding support for any other additional
> infrastructure in incurring costs.
>
Mark,
As penance for my initial snappish response, here is a bit of
additional (I hope) constructive commentary, which may or may not make
you feel any better. As a mere occasional patch contributor I accept
that the decision should reflect the PMC as a whole, not especially my
view.
Publishing a
On Apr 23, 2012, at 1:00 PM, Benson Margulies wrote:
> if you want a second volunteer to care and feed you have me.
I do feel better the more people that are contributing - at the same time that
scares me too ;) The world moves closer and closer to where I *must* eventually
contribute to these
ok, sorry, I read viral as the classic anti-maven slam. sorry for the noise.
On Apr 23, 2012, at 1:14 PM, Mark Miller wrote:
>
> On Apr 23, 2012, at 1:00 PM, Benson Margulies wrote:
>
>> when I see ' viral' in one of these debates, I get frustrated. please
>> state an actual practical problem, n
I agree with David. The maven error was not earth shattering --
working within the PMC was a good thing for the community at large.
We made the requested changes within a few days now things are better.
Imagining a parallel world where the PMC was not involved turns out
much worse for many users.
On Apr 23, 2012, at 1:00 PM, Benson Margulies wrote:
> when I see ' viral' in one of these debates, I get frustrated. please
> state an actual practical problem, not a scare word.
It's not really a scare word - its just the reason I have been against Maven as
part of our core project - I mean v
> But in thinking it over, and avoiding rehashing all the technical
> details, what bothers me most about what happened is that the Lucene
> PMC is/was held accountable for "having released code in another
> project's namespace", yet, none of us realized we had done so. We are
I don't know how ma
when I see ' viral' in one of these debates, I get frustrated. please
state an actual practical problem, not a scare word.
publishing to central should be a central concern of this pmc, as an
ever-growing multitude uses gradle or ivy or maven or some other
consumer.
if you want a second volunteer
> I think, to fix this, we (the Apache Lucene PMC) should stop
> officially posting artifacts to Maven ourselves.
-1
I'm not happy that we're having this conversation again.
I personally don't have the resources to set up continuous integration for
this, and I think that's a requirement that is
On Apr 23, 2012, at 10:14 AM, Michael McCandless wrote:
> I think, to fix this, we (the Apache Lucene PMC) should stop
> officially posting artifacts to Maven ourselves. I think it's great
> if Steve (and/or others) continue to do so, just outside of the Apache
> Lucene project and outside of th
I've had a lingering frustration with the recent blowup due to the
solr-commons-csv Maven artifact (SOLR-3204). We've worked around the
particular issue (we now hide the dependency)...
But in thinking it over, and avoiding rehashing all the technical
details, what bothers me most about what happe
aven repo using generate-maven-artifacts
> in dev-tools/maven/README.maven in your local working copy.
>
> ** **
>
> Here's the relevant snippet from <
> http://svn.apache.org/viewvc/lucene/dev/trunk/dev-tools/maven/README.maven?view=markup
> >:
>
> ** **
ee
<http://maven.apache.org/settings.html#Servers> for more information.
(Note that as of version 2.1.3, Maven Ant Tasks cannot handle encrypted
passwords.)
From: Mikhail Khludnev [mailto:[email protected]]
Sent: Tuesday, March 20, 2012 4:14 PM
To: [email protected]
Subject: deplo
Hello,
Solr build has a great target "generate-maven-artifacts". Can't you share a
snippet which deploys artefacts into repo? How do you do that, by sh or by
ant? Don't we need to have "deploy" target in build?
Thanks in advance.
--
Sincerely yours
Mikhail Khludnev
Lucid Certified
Apache Lucene
84 matches
Mail list logo
