[
https://issues.apache.org/jira/browse/SOLR-586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12622093#action_12622093
]
Craig McClanahan commented on SOLR-586:
---------------------------------------
bq. Can you update to the latest trunk and try again?
Bad News: Even with a fresh checkout of the source, the patch fails to apply.
Good News: This looks like a botch in the patch file itself; there's a missing
"-" to delete the previous line 53 of the old
"contrib/dataimporthandler/build.xml". OK, let's fix it manually and try the
build.
Bad News: "ant clean generate-maven-artifacts" fails. This time it's because
the patched version of the top-level build.xml is expecting the POM templates
to be in either "lib" or the top level directories for contrib stuff, where
they are actually all in the top level directory. Let's fix that as well.
Best News: Everything works.
I suspect that the second patch file doesn't necessarily reflect all the most
recent changes. My recommendation is to go ahead and commit the patch as it
actually exists in Shalin's tree, and then clean up anything that might still
be missed up. We shouldn't disrupt anything if the nightly build script hasn't
been changed yet. I can commit to check any newly committed change first thing
tomorrow (Pacific time).
> Maven - Solr Artifact Publishing
> --------------------------------
>
> Key: SOLR-586
> URL: https://issues.apache.org/jira/browse/SOLR-586
> Project: Solr
> Issue Type: New Feature
> Components: clients - java, contrib - DataImportHandler
> Affects Versions: 1.3
> Reporter: Spencer Crissman
> Assignee: Shalin Shekhar Mangar
> Priority: Minor
> Fix For: 1.3
>
> Attachments: SOLR-586-20080811-craigmcc.zip, SOLR-586.patch,
> SOLR-586.patch, solr-common.pom.xml, solr-dih.pom.xml, solr-server.pom.xml,
> solr2mvn.sh, solrj.pom.xml
>
>
> I know there is an issue open (SOLR-19) for getting a solr build going under
> Maven. This issue differs from that in that it does not concern the build
> process of the solr project, but rather simple dependency management for
> maven projects that depend on the solr artifacts. I've outlined a way to
> easily incorporate solrj + dependencies into your own maven projects, in
> hopes that others doing this find it useful.
> This issue's purpose is twofold:
> 1) Let others know the process.
> 2) Open the idea of whether this can be streamlined/incorporated into the
> standard build in some manner.
> Depending on Solrj in a Maven Project
> 1) Build a 1.3 snapshot.
> 1.1) Check out the code from http://svn.apache.org/repos/asf/lucene/solr/
> 1.2) Build using "ant dist"
> 2) Install the artifacts into your maven repo, using the included pom files.
> 2.1) Move to your dist/apache-solr-1.3-dev/dist directory.
> 2.2) Copy the attached pom files into this directory.
> 2.3) Install solr-common into your repo.
> ex) mvn install:install-file -Dfile=apache-solr-common-1.3-dev.jar
> -DpomFile=solr-common.pom.xml
> 2.4) Install solrj into your repo.
> ex) mvn install:install-file -Dfile=apache-solr-solrj-1.3-dev.jar
> -DpomFile=solrj.pom.xml
> 3) Use Solrj in your existing Maven projects by including it as a dependency
> in your own pom.xml
> <dependency>
> <groupId>org.apache.lucene.solr</groupId>
> <artifactId>solrj</artifactId>
> <version>1.3-SNAPSHOT</version>
> </dependency>
>
> So given the above process, it seems like it would be relatively simple to
> standardize this process by:
> 1) Including the solr-common and solrj pom files w/ the dist.
> 2) Automating the periodic installation of the artifacts to a central repo,
> such as the ibiblio repo.
> If those steps were performed, then creating a (maven) project based on solrj
> would be super simple: just #3 from above. Since most custom developments
> are probably for the clients, it seems like simplifying this would be a nice
> step to take.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
