[jira] Created: (SOLR-1989) Re-Compilation of source needs to be possible in release artifacts

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

[jira] Created: (SOLR-1989) Re-Compilation of source needs to be possible in release artifacts

Michael Gibney (Jira)
Re-Compilation of source needs to be possible in release artifacts
------------------------------------------------------------------

                 Key: SOLR-1989
                 URL: https://issues.apache.org/jira/browse/SOLR-1989
             Project: Solr
          Issue Type: Bug
            Reporter: Hoss Man
             Fix For: 3.1, 4.0


Users who download Solr 3.1 or 4.0 should be able to recompile the source - at the present moment, this is not possible with nightly builds because of assumptions about compiling (and compiling against) .../modules and ../lucene -- even though the jars are included in the "lucene-libs" directory.

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


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

[jira] Commented: (SOLR-1989) Re-Compilation of source needs to be possible in release artifacts

Michael Gibney (Jira)

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

Hoss Man commented on SOLR-1989:
--------------------------------

This is easily reproducable  by trying to run "ant example" from a nightly download from hudson.

--

In general, the solr build.xml doesn't seem to be looking at the "lucene-libs" directory consistently.  This is particularly noticable if you download a nightly build artifact from hudson, which only includes the Solr source, and the lucene+modules dependencies are only available in compiled form.

Running "ant example" or "ant compile-solrj" causes the build to fail with messages like this...
{noformat}
compile-lucene:

compile-solrj:
    [javac] Compiling 89 source files to /tmp/apache-solr-4.0-2010-07-06_08-06-42/build/solrj
    [javac] /tmp/apache-solr-4.0-2010-07-06_08-06-42/src/common/org/apache/solr/common/util/ConcurrentLRUCache.java:19: package org.apache.lucene.util does not exist
    [javac] import org.apache.lucene.util.PriorityQueue;
...
{noformat}

Running "ant compile" fails even faster, with the "compile-lucene" target being unable to find the modules...

{noformat}
hossman@bester:/tmp/apache-solr-4.0-2010-07-06_08-06-42$ ant compile
Buildfile: build.xml

init-forrest-entities:

compile-lucene:

BUILD FAILED
/tmp/apache-solr-4.0-2010-07-06_08-06-42/common-build.xml:212: /tmp/modules/analysis/common not found.

Total time: 0 seconds
{noformat}

(It's not entirely clear to me what special magic causes "compile-lucene" to succeed silently when using "ant example" ... a property is getting set somewhere i'm not seeing)


> Re-Compilation of source needs to be possible in release artifacts
> ------------------------------------------------------------------
>
>                 Key: SOLR-1989
>                 URL: https://issues.apache.org/jira/browse/SOLR-1989
>             Project: Solr
>          Issue Type: Bug
>            Reporter: Hoss Man
>             Fix For: 3.1, 4.0
>
>
> Users who download Solr 3.1 or 4.0 should be able to recompile the source - at the present moment, this is not possible with nightly builds because of assumptions about compiling (and compiling against) .../modules and ../lucene -- even though the jars are included in the "lucene-libs" directory.

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


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

[jira] Commented: (SOLR-1989) Re-Compilation of source needs to be possible in release artifacts

Michael Gibney (Jira)
In reply to this post by Michael Gibney (Jira)

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

Hoss Man commented on SOLR-1989:
--------------------------------

My suggested way of dealing with this...

* all of the relevant classpaths should be fixed to include lucene-libs when compiling solr source
* two new (overridable) system properties should be added for locating the "modules.base.dir" and "lucene.base.dir".  These should default to "../modules" and "../lucene" respectively
* a new (overridable) system property "build.lucene.dependencies" should be added, which defaults to "true" if "${modules.base.dir}" and "${lucene.base.dir}" both exist and are readble.
* if "${build.lucene.dependencies}" is false, and the lucene-libs dir is empty (or non-existent) the "compile-lucene" target should fail with a helpful error message saying that the neccessary lucene libraries can't be found, and point to a wiki with more info on how to build Solr.  (if "${build.lucene.dependencies}" is true, "compile-lucene" should continue to work as it currently does)

If the image i have in my head is correct, that should result in people who check out "dev/trunk" having the same experience they have now -- compilation at the top level, or within solr, will result in everything being re-compiled as needed.  It should also result in people who only download the solr artifacts (and nothing else) being able to recompile solr using the jars in lucene-libs dir.  The added new feature is that people who download solr (or checkout just dev/trunk/solr) will be ableto set system properties as needed to recompile solr against whatever version of dev/\*/modules and dev/\*/lucene they want.

> Re-Compilation of source needs to be possible in release artifacts
> ------------------------------------------------------------------
>
>                 Key: SOLR-1989
>                 URL: https://issues.apache.org/jira/browse/SOLR-1989
>             Project: Solr
>          Issue Type: Bug
>            Reporter: Hoss Man
>             Fix For: 3.1, 4.0
>
>
> Users who download Solr 3.1 or 4.0 should be able to recompile the source - at the present moment, this is not possible with nightly builds because of assumptions about compiling (and compiling against) .../modules and ../lucene -- even though the jars are included in the "lucene-libs" directory.

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


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

[jira] Commented: (SOLR-1989) Re-Compilation of source needs to be possible in release artifacts

Michael Gibney (Jira)
In reply to this post by Michael Gibney (Jira)

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

Robert Muir commented on SOLR-1989:
-----------------------------------

Hoss I worry about your suggested way, especially given the current complexity of the solr build system (it really really really really needs a cleanup).

wouldnt it just be easier to have the source artifacts include lucene and modules source?

I worry about compiling/testing solr not using the latest version of lucene src, i mean i already worry about this now and often do 'clean'
to ensure i havent screwed something up with solr if i am messing with lucene. I think doing this would add even more complexity.


> Re-Compilation of source needs to be possible in release artifacts
> ------------------------------------------------------------------
>
>                 Key: SOLR-1989
>                 URL: https://issues.apache.org/jira/browse/SOLR-1989
>             Project: Solr
>          Issue Type: Bug
>            Reporter: Hoss Man
>             Fix For: 3.1, 4.0
>
>
> Users who download Solr 3.1 or 4.0 should be able to recompile the source - at the present moment, this is not possible with nightly builds because of assumptions about compiling (and compiling against) .../modules and ../lucene -- even though the jars are included in the "lucene-libs" directory.

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


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

[jira] Commented: (SOLR-1989) Re-Compilation of source needs to be possible in release artifacts

Michael Gibney (Jira)
In reply to this post by Michael Gibney (Jira)

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

Mark Miller commented on SOLR-1989:
-----------------------------------

I also think that running off source is sweet.

> Re-Compilation of source needs to be possible in release artifacts
> ------------------------------------------------------------------
>
>                 Key: SOLR-1989
>                 URL: https://issues.apache.org/jira/browse/SOLR-1989
>             Project: Solr
>          Issue Type: Bug
>            Reporter: Hoss Man
>             Fix For: 3.1, 4.0
>
>
> Users who download Solr 3.1 or 4.0 should be able to recompile the source - at the present moment, this is not possible with nightly builds because of assumptions about compiling (and compiling against) .../modules and ../lucene -- even though the jars are included in the "lucene-libs" directory.

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


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]