[ 
https://issues.apache.org/jira/browse/LUCENE-3946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13245911#comment-13245911
 ] 

Hoss Man commented on LUCENE-3946:
----------------------------------


bq. I passed --execdebug to ant, and when it fails (w/ the builtin Fedora ant) 
I get this:

the interesting thing being that neither of those lines actually seem to 
contain your ivy.jar -- but when it fails for you, the java.class.path echoing 
that my patch adds to the ivy-check target does show ivy in _that_ classpath 
(even though it's clearly not the one being used to load the taskdef) ... so 
something in the actual Launcher class is deciding when/if to add that ivy jar 
to that java.class.path (which again: is clearly not hte classpath that 
actually seems to matter)

bq. So forget about loading ivy, I think these ants shipped with linux 
distributions are hopelessly broken and I don't think there is a lot we can do.

that's not really fair ... many distros split things up ito multiple pacakges, 
you probably have the core one but not some optional ones.

as mike has shown it's clearly possible to get a functional ant with a fedora 
install, but you do have to override/edit a config setting

bq. Maybe this 'compiled-on-date' is available via an ant property we can early 
detect?

that *REALLY* smells bad ... and would go out of it's way to break things for 
people who might have already fixed their ant install (using "--noconfig" or 
edited /etc/ant.conf)

I think it's enough to make the failure message say "we did our best, try 
--noconfig and see the URL below for more info about how your ant install may 
be fucked up" ... if we can show them the _correct_ classpath ant is trying to 
use t load ivy, to make the point clear, then great -- if not, then we rip it 
out of hte error message

                
> improve docs & ivy verification output to explain classpath problems and 
> mention "--noconfig"
> ---------------------------------------------------------------------------------------------
>
>                 Key: LUCENE-3946
>                 URL: https://issues.apache.org/jira/browse/LUCENE-3946
>             Project: Lucene - Java
>          Issue Type: Task
>    Affects Versions: 3.6
>            Reporter: Hoss Man
>            Assignee: Hoss Man
>             Fix For: 4.0
>
>         Attachments: LUCENE-3946.patch
>
>
> offshoot of LUCENE-3930, where shawn reported...
> {quote}
> I can't get either branch_3x or trunk to build now, on a system that used to 
> build branch_3x without complaint.  It
> says that ivy is not available, even after doing "ant ivy-bootstrap" to 
> download ivy into the home directory.
> Specifically I am trying to build solrj from trunk, but I can't even get 
> "ant" in the root directory of the checkout
> to work.  I'm on CentOS 6 with oracle jdk7 built using the city-fan.org 
> SRPMs.  Ant (1.7.1) and junit are installed
> from package repositories.  Building a checkout of lucene_solr_3_5 on the 
> same machine works fine.
> {quote}
> The root cause is that ant's global configs can be setup to ignore the users 
> personal lib dir.  suggested work arround is to run "ant --noconfig" but we 
> should also try to give the user feedback in our failure about exactly what 
> classpath ant is currently using (because apparently ${java.class.path} is 
> not actually it)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

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

Reply via email to