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

Hoss Man commented on SOLR-10728:
---------------------------------

bq. I don't think we really need to move the Java Tools files. But for a more 
Maven like setup it should be sec/tools/java. This allows the build tools to 
better do checks, as it's somewhere where common's glob patterns match.

Ok, now I'm more confused...

First you said "In addition other checks are missing, too - because the 
non-standard folder names (e.g. forbidden-apis)."  Since the *only* java code 
in solr/solr-ref-guide is the "tools" that seemed like a pretty clear 
indication that you felt the tools needed to move.  but now you're saying we 
don't need to move them unless we want to be "more maven like".

The crux of my confusion is this...

# Assuming we _do_ want to be more maven like, and we want to do things "the 
right way" as far as the existing common build assumptions work, to ensure 
things like forbidden-apis work w/as few customizations as possible in 
solr/solr-ref-guide then how exactly you do you suggest we organize the various 
types of files in solr/solr-ref-guide ?
# for #1, please remember that the true "Source" of the solr-ref-guide is the 
asciidoc files -- not any code -- and that we want to ensure these (java) 
"Tools" don't pollute the "Source" ... so if we move solr/solr-ref-guide/tools 
to solr/solr-ref-guide/src/tools(/java?) then where exactly do you feel that 
the asciidoc files currently in solr/solr-ref-guide/src should live?

(if we still also need custom RAT includes because the *.adoc files are 
atypical then so be it, but i'd prefer to make sure i understand how exactly 
you feel like the directory structure should be organized before getting too 
deep in the weeds with build.xml customizations that in some cases may not be 
needed if the directories are "fixed")

> fix/improve rat-sources and check-forbidden-api in solr-ref-guide
> -----------------------------------------------------------------
>
>                 Key: SOLR-10728
>                 URL: https://issues.apache.org/jira/browse/SOLR-10728
>             Project: Solr
>          Issue Type: Sub-task
>      Security Level: Public(Default Security Level. Issues are Public) 
>          Components: documentation
>            Reporter: Hoss Man
>            Assignee: Uwe Schindler
>
> via email from uwe...
> {noformat}
> We have already a check for licenses by default enabled in all sub 
> directories of the build. It's called "rat-sources"
> The problem with the rat-sources ant target is, that although it runs on the 
> ref-guide subdirectory, it does not catch
> violations for several reasons:
> 1. it does not yet look into all file types
> 2. for some files, e.g. the java code, you are using a non-standard 
> subdirectory of the project folder. To fix this, there are
> two options: a) move to src/.../java or tools like in other modules (by that 
> they are also compiled automatically without extra
> compilation tasks in build.xml) or b) add the additional directories  to some 
> special ANT property _before_ loading
> common-build.xml:
>   <!-- These patterns can be defined to add additional files for checks, 
> relative to module's home dir -->
>   <property name="rat.additional-includes" value=""/>
>   <property name="rat.additional-excludes" value=""/>
> In the local build, you can configure the license checker by adding those 
> lines fillesd out *before* including
> common-build.xml. If you open an issue, I can maybe take care of that this 
> week (I am a bit busy). I'd also like to clean up
> the build directory, because it has some code duplication automatically 
> handled by common-build.xml. In addition other checks
> are missing, too - because the non-standard folder names (e.g. 
> forbidden-apis).
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

Reply via email to