[jira] Commented: (SOLR-1807) UpdateHandler plugin is not fully supported

[Shalin Shekhar Mangar (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-1807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12842369#action_12842369
 ] 

Shalin Shekhar Mangar commented on SOLR-1807:
-

UpdateHandler is an interface so instead of adding a method to it and breaking 
compatibility, we added it to the DirectUpdateHandler2 class. I guess the only 
way is to change the UpdateHandler interface.

> UpdateHandler plugin is not fully supported
> ---
>
> Key: SOLR-1807
> URL: https://issues.apache.org/jira/browse/SOLR-1807
> Project: Solr
>  Issue Type: Bug
>  Components: update
>Affects Versions: 1.4
>Reporter: John Wang
>
> UpdateHandler is published as a supported Plugin, but code such as the 
> following:
> if (core.getUpdateHandler() instanceof DirectUpdateHandler2) {
> ((DirectUpdateHandler2) 
> core.getUpdateHandler()).forceOpenWriter();
>   } else {
> LOG.warn("The update handler being used is not an instance or 
> sub-class of DirectUpdateHandler2. " +
> "Replicate on Startup cannot work.");
>   } 
> suggest that it is really not fully supported.
> Must all implementations of UpdateHandler be subclasses of 
> DirectUpdateHandler2 for it to work with replication?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: A bit off topic, but...

[Erick Erickson]

OK, there's a first cut at this page up on the Wiki, see:

http://wiki.apache.org/solr/UsingMailingLists.html

I linked to it off the FAQ, I just added a link from the "Are there mailing
lists for SOLR" section at:
http://wiki.apache.org/solr/FAQ#Are_there_Mailing_lists_for_Solr.3F

I *think* I got the links right, although it took a few tries. Some of which
I forgot to comment on, sorry 'bout that.

I'm not sure whether it's too long or not. My intention here is to have a
page we can direct people to with some admonition like "please read this and
repost your question". I don't think it should turn into a list of specific
problem solutions. But I can see expanding it with other categories like:
> memory issues
> search performance
> multiple cores
> 

With the caveat that for each, all the page should do is identify the
information the poster should include when asking for help rather than
solutions. If we bury the "how to ask" in a thousand lines of possible
solutions, eyes will glaze over

Best
Erick

On Sat, Mar 6, 2010 at 10:15 AM, Yonik Seeley wrote:

> I think something would definitely be useful.
> Something *short* that people will read and can actually follow.
> Something that tells them what we will ask first in trying to diagnose
> a problem.
> Something/somewhere that they will be likely to run across before
> posting a question.
>
> Maybe right near the top of the solr faq or something?
> Along the lines of "If you're having a problem with X, ... post to
> solr-user with A B, C"
> We should keep the list small, or give different lists depending on
> the problem. We don't want people to have to fill out a 10 page form
> to ask for help :-)
>
> -Yonik
> http://www.lucidimagination.com
>
> On Sat, Mar 6, 2010 at 9:58 AM, Erick Erickson 
> wrote:
> > Sorry to put this on the dev list, but the folks who read this are also
> some
> > of the "heavy hitters" on the user list
> >
> > I'm seeing questions on the users list of the form "help, it doesn't
> work",
> > which then requires people to guess, ask for clarification, etc.  I often
> > try to grab them long enough to ask for more information and take some of
> > the load off the folks who really know things, but I'm starting to get
> > frustrated with the number of really vague posts that require three
> > back-and-forths before anything useful comes of it.
> >
> > In, I admit, 2 minutes of looking I couldn't find anything on the SOLR
> site
> > about how to use the user's list.
> >
> > Would it be useful If I created a much gentler (and shorter) version of
> > http://catb.org/~esr/faqs/smart-questions.html?
> If it'd be useful, is it
> > worth putting on the SOLR website? Or maybe Chris would be willing to put
> it
> > on his apache page so we could link to it easily.
> >
> > My goal here would be to have something welcoming (the above is pretty
> darn
> > off-putting, even if it accurately reflects my reactions sometime), but
> at
> > the same time conveying that there are things the poster can do to 1> get
> > answers much more quickly and 2> stop wasting everyone's time (OK, a
> little
> > frustration there).
> >
> > I know my first questions on the Lucene list sure could have used a bit
> of
> > etiquette guidance, but I'm not sure I'd have appreciated something in
> the
> > tone of the link above. That said, I'm tired of typing the same request
> for
> > more information over and over and over...
> >
> > Or, someone could say "Do you mean this page " and I'll just
> blush
> > in the privacy of my study
> >
> > Whaddya think?
> >
> > Erick
> >
>

[jira] Resolved: (SOLR-1798) Memory leak in FastLRUCache

[Yonik Seeley (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-1798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Yonik Seeley resolved SOLR-1798.


Resolution: Fixed

committed.

> Memory leak in FastLRUCache
> ---
>
> Key: SOLR-1798
> URL: https://issues.apache.org/jira/browse/SOLR-1798
> Project: Solr
>  Issue Type: Bug
>  Components: search
>Affects Versions: 1.4, 1.5
>Reporter: Laxman
>Assignee: Yonik Seeley
> Fix For: 1.5
>
> Attachments: SOLR-1798.patch, SOLR-1798.patch
>
>
> Every time a commit happens two Stats instances 
> [org.apache.solr.common.util.ConcurrentLRUCache.Stats] are leaking.
> Following code [org.apache.solr.search.FastLRUCache] to maintain cumulative 
> cache statistics causing this Stats object leak. 
> {noformat}
> cumulativeStats = (List) persistence;
> cumulativeStats.add(cache.getStats());
> {noformat}
> Everytime a *commit* happens a new cache object is getting created and its 
> stats is added to the list which is not released at all.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (SOLR-1798) Memory leak in FastLRUCache

[Yonik Seeley (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-1798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Yonik Seeley updated SOLR-1798:
---

Attachment: SOLR-1798.patch

New patch that fixes the cumulative stats by adding in an entry in the list for 
cumulative stats and incrementing them for every cache that is closed.

Longer term, we might want a hash set or something (if we start having 
per-segment caches) but more changes will be necessary then anyway.

> Memory leak in FastLRUCache
> ---
>
> Key: SOLR-1798
> URL: https://issues.apache.org/jira/browse/SOLR-1798
> Project: Solr
>  Issue Type: Bug
>  Components: search
>Affects Versions: 1.4, 1.5
>Reporter: Laxman
>Assignee: Yonik Seeley
> Fix For: 1.5
>
> Attachments: SOLR-1798.patch, SOLR-1798.patch
>
>
> Every time a commit happens two Stats instances 
> [org.apache.solr.common.util.ConcurrentLRUCache.Stats] are leaking.
> Following code [org.apache.solr.search.FastLRUCache] to maintain cumulative 
> cache statistics causing this Stats object leak. 
> {noformat}
> cumulativeStats = (List) persistence;
> cumulativeStats.add(cache.getStats());
> {noformat}
> Everytime a *commit* happens a new cache object is getting created and its 
> stats is added to the list which is not released at all.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-1798) Memory leak in FastLRUCache

[Yonik Seeley (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-1798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12842319#action_12842319
 ] 

Yonik Seeley commented on SOLR-1798:


Hmmm, right - fixes the memory leak, but breaks cumulative stats.

> Memory leak in FastLRUCache
> ---
>
> Key: SOLR-1798
> URL: https://issues.apache.org/jira/browse/SOLR-1798
> Project: Solr
>  Issue Type: Bug
>  Components: search
>Affects Versions: 1.4, 1.5
>Reporter: Laxman
>Assignee: Yonik Seeley
> Fix For: 1.5
>
> Attachments: SOLR-1798.patch
>
>
> Every time a commit happens two Stats instances 
> [org.apache.solr.common.util.ConcurrentLRUCache.Stats] are leaking.
> Following code [org.apache.solr.search.FastLRUCache] to maintain cumulative 
> cache statistics causing this Stats object leak. 
> {noformat}
> cumulativeStats = (List) persistence;
> cumulativeStats.add(cache.getStats());
> {noformat}
> Everytime a *commit* happens a new cache object is getting created and its 
> stats is added to the list which is not released at all.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (SOLR-1798) Memory leak in FastLRUCache

[Yonik Seeley (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-1798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Yonik Seeley updated SOLR-1798:
---

Attachment: SOLR-1798.patch

I think the fix is as simple as this patch.
Verifying that it fixes it is slightly harder - I'll try breaking out the 
profiler.

> Memory leak in FastLRUCache
> ---
>
> Key: SOLR-1798
> URL: https://issues.apache.org/jira/browse/SOLR-1798
> Project: Solr
>  Issue Type: Bug
>  Components: search
>Affects Versions: 1.4, 1.5
>Reporter: Laxman
>Assignee: Yonik Seeley
> Fix For: 1.5
>
> Attachments: SOLR-1798.patch
>
>
> Every time a commit happens two Stats instances 
> [org.apache.solr.common.util.ConcurrentLRUCache.Stats] are leaking.
> Following code [org.apache.solr.search.FastLRUCache] to maintain cumulative 
> cache statistics causing this Stats object leak. 
> {noformat}
> cumulativeStats = (List) persistence;
> cumulativeStats.add(cache.getStats());
> {noformat}
> Everytime a *commit* happens a new cache object is getting created and its 
> stats is added to the list which is not released at all.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Assigned: (SOLR-1798) Memory leak in FastLRUCache

[Yonik Seeley (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-1798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Yonik Seeley reassigned SOLR-1798:
--

Assignee: Yonik Seeley

> Memory leak in FastLRUCache
> ---
>
> Key: SOLR-1798
> URL: https://issues.apache.org/jira/browse/SOLR-1798
> Project: Solr
>  Issue Type: Bug
>  Components: search
>Affects Versions: 1.4, 1.5
>Reporter: Laxman
>Assignee: Yonik Seeley
> Fix For: 1.5
>
>
> Every time a commit happens two Stats instances 
> [org.apache.solr.common.util.ConcurrentLRUCache.Stats] are leaking.
> Following code [org.apache.solr.search.FastLRUCache] to maintain cumulative 
> cache statistics causing this Stats object leak. 
> {noformat}
> cumulativeStats = (List) persistence;
> cumulativeStats.add(cache.getStats());
> {noformat}
> Everytime a *commit* happens a new cache object is getting created and its 
> stats is added to the list which is not released at all.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: A bit off topic, but...

[Yonik Seeley]

I think something would definitely be useful.
Something *short* that people will read and can actually follow.
Something that tells them what we will ask first in trying to diagnose
a problem.
Something/somewhere that they will be likely to run across before
posting a question.

Maybe right near the top of the solr faq or something?
Along the lines of "If you're having a problem with X, ... post to
solr-user with A B, C"
We should keep the list small, or give different lists depending on
the problem. We don't want people to have to fill out a 10 page form
to ask for help :-)

-Yonik
http://www.lucidimagination.com

On Sat, Mar 6, 2010 at 9:58 AM, Erick Erickson  wrote:
> Sorry to put this on the dev list, but the folks who read this are also some
> of the "heavy hitters" on the user list
>
> I'm seeing questions on the users list of the form "help, it doesn't work",
> which then requires people to guess, ask for clarification, etc.  I often
> try to grab them long enough to ask for more information and take some of
> the load off the folks who really know things, but I'm starting to get
> frustrated with the number of really vague posts that require three
> back-and-forths before anything useful comes of it.
>
> In, I admit, 2 minutes of looking I couldn't find anything on the SOLR site
> about how to use the user's list.
>
> Would it be useful If I created a much gentler (and shorter) version of
> http://catb.org/~esr/faqs/smart-questions.html? If it'd be useful, is it
> worth putting on the SOLR website? Or maybe Chris would be willing to put it
> on his apache page so we could link to it easily.
>
> My goal here would be to have something welcoming (the above is pretty darn
> off-putting, even if it accurately reflects my reactions sometime), but at
> the same time conveying that there are things the poster can do to 1> get
> answers much more quickly and 2> stop wasting everyone's time (OK, a little
> frustration there).
>
> I know my first questions on the Lucene list sure could have used a bit of
> etiquette guidance, but I'm not sure I'd have appreciated something in the
> tone of the link above. That said, I'm tired of typing the same request for
> more information over and over and over...
>
> Or, someone could say "Do you mean this page " and I'll just blush
> in the privacy of my study
>
> Whaddya think?
>
> Erick
>

A bit off topic, but...

[Erick Erickson]

Sorry to put this on the dev list, but the folks who read this are also some
of the "heavy hitters" on the user list

I'm seeing questions on the users list of the form "help, it doesn't work",
which then requires people to guess, ask for clarification, etc.  I often
try to grab them long enough to ask for more information and take some of
the load off the folks who really know things, but I'm starting to get
frustrated with the number of really vague posts that require three
back-and-forths before anything useful comes of it.

In, I admit, 2 minutes of looking I couldn't find anything on the SOLR site
about how to use the user's list.

Would it be useful If I created a much gentler (and shorter) version of
http://catb.org/~esr/faqs/smart-questions.html? If it'd be useful, is it
worth putting on the SOLR website? Or maybe Chris would be willing to put it
on his apache page so we could link to it easily.

My goal here would be to have something welcoming (the above is pretty darn
off-putting, even if it accurately reflects my reactions sometime), but at
the same time conveying that there are things the poster can do to 1> get
answers much more quickly and 2> stop wasting everyone's time (OK, a little
frustration there).

I know my first questions on the Lucene list sure could have used a bit of
etiquette guidance, but I'm not sure I'd have appreciated something in the
tone of the link above. That said, I'm tired of typing the same request for
more information over and over and over...

Or, someone could say "Do you mean this page " and I'll just blush
in the privacy of my study

Whaddya think?

Erick

[jira] Commented: (SOLR-1809) Carrot2 clustering time logging

[Erik Hatcher (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-1809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12842249#action_12842249
 ] 

Erik Hatcher commented on SOLR-1809:


Stanislaw - how does this differ from the output debugQuery=true provides on 
the component timings?  Isn't that sufficient?

> Carrot2 clustering time logging
> ---
>
> Key: SOLR-1809
> URL: https://issues.apache.org/jira/browse/SOLR-1809
> Project: Solr
>  Issue Type: Improvement
>  Components: contrib - Clustering
>Reporter: Stanislaw Osinski
> Fix For: 1.5
>
> Attachments: SOLR-1809.patch
>
>
> It may be useful to log the amount of time Carrot2 spent on clustering. This 
> should be helpful when debugging performance issues.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Build failed in Hudson: Solr-trunk #1077

[Apache Hudson Server]

See 

Changes:

[markrmiller] SOLR-1722: small bug - defaultCoreName is looked for at /solr, 
but should be /solr/cores - also, defaultCoreName should really not default to 
DEFAULT_DEFAULT_CORENAME

--
[...truncated 2369 lines...]
[junit] Running org.apache.solr.client.solrj.embedded.LargeVolumeJettyTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 7.952 sec
[junit] Running 
org.apache.solr.client.solrj.embedded.MergeIndexesEmbeddedTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 5.333 sec
[junit] Running org.apache.solr.client.solrj.embedded.MultiCoreEmbeddedTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 5.407 sec
[junit] Running 
org.apache.solr.client.solrj.embedded.MultiCoreExampleJettyTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 5.008 sec
[junit] Running 
org.apache.solr.client.solrj.embedded.SolrExampleEmbeddedTest
[junit] Tests run: 9, Failures: 0, Errors: 0, Time elapsed: 20.627 sec
[junit] Running org.apache.solr.client.solrj.embedded.SolrExampleJettyTest
[junit] Tests run: 10, Failures: 0, Errors: 0, Time elapsed: 27.114 sec
[junit] Running 
org.apache.solr.client.solrj.embedded.SolrExampleStreamingTest
[junit] Tests run: 9, Failures: 0, Errors: 0, Time elapsed: 24.812 sec
[junit] Running org.apache.solr.client.solrj.embedded.TestSolrProperties
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 4.005 sec
[junit] Running org.apache.solr.client.solrj.request.TestUpdateRequestCodec
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.413 sec
[junit] Running 
org.apache.solr.client.solrj.response.AnlysisResponseBaseTest
[junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.501 sec
[junit] Running 
org.apache.solr.client.solrj.response.DocumentAnalysisResponseTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.415 sec
[junit] Running 
org.apache.solr.client.solrj.response.FieldAnalysisResponseTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.414 sec
[junit] Running org.apache.solr.client.solrj.response.QueryResponseTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.56 sec
[junit] Running org.apache.solr.client.solrj.response.TermsResponseTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 3.213 sec
[junit] Running org.apache.solr.client.solrj.response.TestSpellCheckResponse
[junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 7.379 sec
[junit] Running org.apache.solr.client.solrj.util.ClientUtilsTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.409 sec
[junit] Running org.apache.solr.common.SolrDocumentTest
[junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 0.443 sec
[junit] Running org.apache.solr.common.params.ModifiableSolrParamsTest
[junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 0.414 sec
[junit] Running org.apache.solr.common.params.SolrParamTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.541 sec
[junit] Running org.apache.solr.common.util.ContentStreamTest
[junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.443 sec
[junit] Running org.apache.solr.common.util.DOMUtilTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.537 sec
[junit] Running org.apache.solr.common.util.FileUtilsTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.417 sec
[junit] Running org.apache.solr.common.util.IteratorChainTest
[junit] Tests run: 7, Failures: 0, Errors: 0, Time elapsed: 0.438 sec
[junit] Running org.apache.solr.common.util.NamedListTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.395 sec
[junit] Running org.apache.solr.common.util.TestFastInputStream
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.923 sec
[junit] Running org.apache.solr.common.util.TestHash
[junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.526 sec
[junit] Running org.apache.solr.common.util.TestNamedListCodec
[junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 1.692 sec
[junit] Running org.apache.solr.common.util.TestXMLEscaping
[junit] Tests run: 7, Failures: 0, Errors: 0, Time elapsed: 0.41 sec
[junit] Running org.apache.solr.core.AlternateDirectoryTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 3.456 sec
[junit] Running org.apache.solr.core.AlternateIndexReaderTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 3.327 sec
[junit] Running org.apache.solr.core.IndexReaderFactoryTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 3.196 sec
[junit] Running org.apache.solr.core.RequestHandlersTest
[junit] Tests run: 2, Failures: 0, Errors: 0

Solr nightly build failure

[solr-dev]

init-forrest-entities:
[mkdir] Created dir: /tmp/apache-solr-nightly/build
[mkdir] Created dir: /tmp/apache-solr-nightly/build/web

compile-solrj:
[mkdir] Created dir: /tmp/apache-solr-nightly/build/solrj
[javac] Compiling 88 source files to /tmp/apache-solr-nightly/build/solrj
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.

compile:
[mkdir] Created dir: /tmp/apache-solr-nightly/build/solr
[javac] Compiling 434 source files to /tmp/apache-solr-nightly/build/solr
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.

compileTests:
[mkdir] Created dir: /tmp/apache-solr-nightly/build/tests
[javac] Compiling 210 source files to /tmp/apache-solr-nightly/build/tests
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.

dist-contrib:

init:
[mkdir] Created dir: 
/tmp/apache-solr-nightly/contrib/clustering/build/classes
[mkdir] Created dir: 
/tmp/apache-solr-nightly/contrib/clustering/lib/downloads
[mkdir] Created dir: /tmp/apache-solr-nightly/build/docs/api

init-forrest-entities:

compile-solrj:

compile:
[javac] Compiling 1 source file to /tmp/apache-solr-nightly/build/solr
[javac] Note: 
/tmp/apache-solr-nightly/src/java/org/apache/solr/search/DocSetHitCollector.java
 uses or overrides a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.

make-manifest:
[mkdir] Created dir: /tmp/apache-solr-nightly/build/META-INF

proxy.setup:

check-files:

get-colt:
  [get] Getting: 
http://repo1.maven.org/maven2/colt/colt/1.2.0/colt-1.2.0.jar
  [get] To: 
/tmp/apache-solr-nightly/contrib/clustering/lib/downloads/colt-1.2.0.jar

get-pcj:
  [get] Getting: http://repo1.maven.org/maven2/pcj/pcj/1.2/pcj-1.2.jar
  [get] To: 
/tmp/apache-solr-nightly/contrib/clustering/lib/downloads/pcj-1.2.jar

get-nni:
  [get] Getting: 
http://download.carrot2.org/maven2/org/carrot2/nni/1.0.0/nni-1.0.0.jar
  [get] To: 
/tmp/apache-solr-nightly/contrib/clustering/lib/downloads/nni-1.0.0.jar

get-simple-xml:
  [get] Getting: 
http://mirrors.ibiblio.org/pub/mirrors/maven2/org/simpleframework/simple-xml/1.7.3/simple-xml-1.7.3.jar
  [get] To: 
/tmp/apache-solr-nightly/contrib/clustering/lib/downloads/simple-xml-1.7.3.jar

get-libraries:

compile:
[javac] Compiling 7 source files to 
/tmp/apache-solr-nightly/contrib/clustering/build/classes
[javac] Note: 
/tmp/apache-solr-nightly/contrib/clustering/src/main/java/org/apache/solr/handler/clustering/carrot2/CarrotClusteringEngine.java
 uses or overrides a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.

build:
  [jar] Building jar: 
/tmp/apache-solr-nightly/contrib/clustering/build/apache-solr-clustering-1.5-dev.jar

dist:
 [copy] Copying 1 file to /tmp/apache-solr-nightly/dist

init:
[mkdir] Created dir: 
/tmp/apache-solr-nightly/contrib/dataimporthandler/target/classes

init-forrest-entities:

compile-solrj:

compile:
[javac] Compiling 1 source file to /tmp/apache-solr-nightly/build/solr
[javac] Note: 
/tmp/apache-solr-nightly/src/java/org/apache/solr/search/DocSetHitCollector.java
 uses or overrides a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.

make-manifest:

compile:
[javac] Compiling 49 source files to 
/tmp/apache-solr-nightly/contrib/dataimporthandler/target/classes
[javac] Note: 
/tmp/apache-solr-nightly/contrib/dataimporthandler/src/main/java/org/apache/solr/handler/dataimport/DocBuilder.java
 uses or overrides a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.

compileExtras:
[mkdir] Created dir: 
/tmp/apache-solr-nightly/contrib/dataimporthandler/target/extras/classes
[javac] Compiling 2 source files to 
/tmp/apache-solr-nightly/contrib/dataimporthandler/target/extras/classes
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.

build:
  [jar] Building jar: 
/tmp/apache-solr-nightly/contrib/dataimporthandler/target/apache-solr-dataimporthandler-1.5-dev.jar
  [jar] Building jar: 
/tmp/apache-solr-nightly/contrib/dataimporthandler/target/apache-solr-dataimporthandler-extras-1.5