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

Uwe Schindler edited comment on SOLR-9109 at 5/16/16 8:39 PM:
--------------------------------------------------------------

Hi Steve,

yes that trick works. I was thinking about the same last hour, but was not sure 
if this works. But yes, it works, because Ant propertes can be seen by ivy, but 
not the other way round.

About the solr common-build.xml file and forbidden: I thought the include was 
private to the target, but you are right, its global and polutes. There is 
another one using the ivy-versions.properties, where it includes a prefix: See 
lucene/analyzers/common/build.xml for getting icu4j version:

{code:xml}
  <target xmlns:ivy="antlib:org.apache.ivy.ant" name="-resolve-icu4j" 
unless="icu4j.resolved" depends="ivy-availability-check,ivy-configure">
    <loadproperties prefix="ivyversions" 
srcFile="${common.dir}/ivy-versions.properties"/>
    <ivy:cachepath organisation="com.ibm.icu" module="icu4j" 
revision="${ivyversions./com.ibm.icu/icu4j}"
      inline="true" conf="default" transitive="true" pathid="icu4j.classpath"/>
    <property name="icu4j.resolved" value="true"/>
  </target>
{code}

Can we change the forbiddenapis one to work in a similar way? I can do that in 
a separate commit, but as you are already working on it, maybe change it!


was (Author: thetaphi):
Hi Steve,

yes that trick works. I was thinking about the same last hour, but was not sure 
if this works. But yes, it works, because Ant propertes can be seen by ivy, but 
not the other way round.

About the solr common-cuild file. I thought the include was private to the 
target, but you are right, its global and polutes. There is another one using 
the ivy-versions.properties, where it includes a prefix: See 
lucene/analyzers/common/build.xml for getting icu4j version:

{code:xml}
  <target xmlns:ivy="antlib:org.apache.ivy.ant" name="-resolve-icu4j" 
unless="icu4j.resolved" depends="ivy-availability-check,ivy-configure">
    <loadproperties prefix="ivyversions" 
srcFile="${common.dir}/ivy-versions.properties"/>
    <ivy:cachepath organisation="com.ibm.icu" module="icu4j" 
revision="${ivyversions./com.ibm.icu/icu4j}"
      inline="true" conf="default" transitive="true" pathid="icu4j.classpath"/>
    <property name="icu4j.resolved" value="true"/>
  </target>
{code}

Can we change the forbiddenapis one to work in a similar way? I can do that in 
a separate commit, but as you are already working on it, maybe change it!

> Add support for custom ivysettings.xml
> --------------------------------------
>
>                 Key: SOLR-9109
>                 URL: https://issues.apache.org/jira/browse/SOLR-9109
>             Project: Solr
>          Issue Type: Improvement
>            Reporter: Misha Dmitriev
>         Attachments: 0001-Support-for-custom-ivysettings.xml.patch, 
> SOLR-9109.patch, SOLR-9109.patch, SOLR-9109.patch
>
>
> Currently solr/lucene/common-build.xml hardcodes file ivy-settings.xml in the 
> ivy.configure task. It means that, unlike all other CDH components that use 
> Ant, Solr does not allow the user to provide a custom ivysettings.xml.
> In the Cauldron CDH build, we need to make some adjustments in the build 
> process to satisfy CDH-internal build dependencies with artifacts generated 
> locally, rather than download them from repo1.maven.org etc. E.g. all 
> component should use locally-generated avro-snapshot jars instead of publicly 
> released ones, etc. For Ant, we achieve that by giving it a special 
> ivysettings.xml file, that limits artifact downloading to the local on-disk 
> maven repository and Cloudera artifactory server.
> All CDH components except Solr allow the user to specify a custom 
> ivysettings.xml file by overriding -Divysettings.xml property. We need to add 
> the same feature to Solr. It can be easily achieved by changing several lines 
> in solr/lucene/common-build.xml.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Reply via email to