Re: solrj & http client 4

[Stevo Slavić <ss...@gmail.com>]

In those poms, not all modules have explicit version and groupId which
is a bad practice. Also some parent references contain invalid default
(../pom.xml) relativePath - path to their parent pom.xml. Paths to
build directories look suspicious to me. lucene-bdb module references
missing library com.sleepycat:berkeleydb:jar:4.7.25 - I see
lib/db-4.7.25.jar, if it's supposed to be installed in local
repository then pom would be handy.

Wiki page http://wiki.apache.org/solr/HowToContribute references this
http://markmail.org/message/yb5qgeamosvdscao mail but files
(.classpath) in archives attached to that email are very outdated.
eclipse target in base ant build script generates .classpath and
.settings so it seems mentioned wiki page is outdated too.

Steps to get Lucene/Solr trunk in eclipse IDE for me were:
1) In SVN Repository Exploring perspective add repository with
http://svn.apache.org/repos/asf/lucene/dev
2) Right-click trunk and choose "Find/Check Out As..."
3) Choose "Check out as a project configured using the New Project Wizard"
4) Choose "Java Project" wizard
5) Enter lucene-solr as project name, make sure Java 1.6 is selected
execution environment and "Create separate folders for sources and
class files" is selected layout, and click Finish
6) After checkout is complete, delete src directory that eclipse
created in project root directory
7) Turn on ant view (Window --> Show View --> Ant)
8) In ant view add build.xml from checked-out trunk root and double
click eclipse target
9) Once ant completes right-click project and choose refresh

Regards,
Stevo.

On Wed, Dec 22, 2010 at 6:29 PM, Steven A Rowe <sa...@syr.edu> wrote:
> Stevo,
>
> You may be interested in LUCENE-2657 <https://issues.apache.org/jira/browse/LUCENE-2657>, which provides full POMs for Lucene/Solr trunk.
>
> I don't use Eclipse, but I think it can use POMs to bootstrap project configuration.  (I know IntelliJ can do this.)
>
> Steve
>
>> -----Original Message-----
>> From: Stevo Slavić [mailto:sslavic@gmail.com]
>> Sent: Wednesday, December 22, 2010 9:17 AM
>> To: solr-user@lucene.apache.org
>> Subject: Re: solrj & http client 4
>>
>> Tried to checkout lucene/solr and setup projects and classpath in eclipse
>> -
>> there seems to be circular dependency between modules - this is not
>> possible/allowed in maven built project, would require refactoring.
>>
>> Regards,
>> Stevo.
>>
>> On Wed, Dec 8, 2010 at 1:42 PM, Stevo Slavić <ss...@gmail.com> wrote:
>>
>> > OK, thanks. Can't promise anything, but would love to contribute. First
>> > impression on the source code - ant is used as build tool, wish it was
>> > maven. If it was maven then
>> > https://issues.apache.org/jira/browse/SOLR-1218 would be trivial or
>> > wouldn't exist in the first place.
>> >
>> > Regards,
>> > Stevo.
>> >
>> >
>> > On Wed, Dec 8, 2010 at 10:25 AM, Chantal Ackermann <
>> > chantal.ackermann@btelligent.de> wrote:
>> >
>> >> SOLR-2020 addresses upgrading to HttpComponents (form HttpClient). I
>> >> have had no time to work more on it, yet, though. I also don't have
>> that
>> >> much experience with the new version, so any help is much appreciated.
>> >>
>> >> Cheers,
>> >> Chantal
>> >>
>> >> On Tue, 2010-12-07 at 18:35 +0100, Yonik Seeley wrote:
>> >> > On Tue, Dec 7, 2010 at 12:32 PM, Stevo Slavić <ss...@gmail.com>
>> >> wrote:
>> >> > > Hello solr users and developers,
>> >> > >
>> >> > > Are there any plans to upgraded http client dependency in solrj
>> from
>> >> 3.x to
>> >> > > 4.x?
>> >> >
>> >> > I'd certainly be for moving to 4.x (and I think everyone else would
>> >> too).
>> >> > The issue is that it's not a drop-in replacement, so someone needs to
>> >> > do the work.
>> >> >
>> >> > -Yonik
>> >> > http://www.lucidimagination.com
>> >> >
>> >> > > Found this <https://issues.apache.org/jira/browse/SOLR-861> ticket
>> -
>> >> > > judging by comments in it upgrade might help fix the issue. I have
>> a
>> >> project
>> >> > > in jar hell, getting different versions of http client as
>> transitive
>> >> > > dependency...
>> >> > >
>> >> > > Regards,
>> >> > > Stevo.
>> >>
>> >>
>> >>
>> >>
>> >
>

RE: solrj & http client 4

[Steven A Rowe <sa...@syr.edu>]

Hi Stevo,

Thanks for reviewing the Maven POMs in LUCENE-2657 - I appreciate it.

> In those poms, not all modules have explicit version and groupId which
> is a bad practice.

Really?  According to the "POM best practices" section in Sonatype's Maven book <http://www.sonatype.com/books/mvnref-book/reference/pom-relationships-sect-pom-best-practice.html>, inheriting version and groupId is standard and acceptable.

However, since the Lucene/Solr source tree contains two groupIds (org.apache.lucene and org.apache.solr), I agree that all modules should have an explicit groupId, and you're right: several of the aggregator POMs don't have explicit groupId.  I'll fix this.

But I don't think it's a bad practice to inherit the version from the parent POM.  All Lucene and Solr modules have synchronized versions - it doesn't make sense for them to be specified independent of the whole project.

> Also some parent references contain invalid default
> (../pom.xml) relativePath - path to their parent pom.xml.

AFAICT, the default relativePath concept no longer exists (as of Maven 2.2+).  That is, the parent POM resolution method uses the explicit relativePath if specified, then the local repository -- ../pom.xml is never used unless explicitly specified.  (I don't know this for a fact, I just found that I had to "mvn install" before parent POM changes because visible to child POMs, even when the parent POM location was in the parent directory.)

That said, I agree it would be useful to have explicit relativePaths - I'll add them.

> Paths to build directories look suspicious to me. lucene-bdb module references
> missing library com.sleepycat:berkeleydb:jar:4.7.25 - I see lib/db-4.7.25.jar,
> if it's supposed to be installed in local repository then pom would be handy.

Run "mvn -N -P bootstrap install" from the top level to install non-mavenized dependencies into your local repository.

> Wiki page http://wiki.apache.org/solr/HowToContribute references this
> http://markmail.org/message/yb5qgeamosvdscao mail but files
> (.classpath) in archives attached to that email are very outdated.
> eclipse target in base ant build script generates .classpath and
> .settings so it seems mentioned wiki page is outdated too.

I agree, this should be changed.  Go for it!

Steve