I probably would have still screwed it up... I just saw what looked
like a build file along some source folders, and "java" and "test"
still to me look like they would hold source code.

Really i should have said "WTF: why is there source code here at all"
but that didn't click either

I don't think normally someone would use codecs/ as a "template"
though. I just thought "who has resources" and i knew this guy had
META-INF for the codec stuff so it was the victim i picked.

On Tue, Sep 17, 2013 at 12:15 PM, Steve Rowe <[email protected]> wrote:
> Actually, now that I think about it, locating the submodules under src/java/ 
> and src/test/ is a vestige from when the interpolated pom.xml files went into 
> the source directories, and so had to use the existing structure.
>
> Under the top-level maven-build/, where the interpolated pom.xml files are 
> placed these days, the structure could be anything we want - the src/ 
> directory could just go away:
>
> maven/
> +--lucene/
>    +--codecs/
>       +--pom.xml.template     <-- aggregator POM
>       +--java/
>       |  +--pom.xml.template  <-- compile-phase POM
>       +--test/
>          +--pom.xml.template  <-- test-phase POM
>
> Robert, do you think the above structure would have provided the "nested 
> modules here" cue?
>
> Steve
>
> On Sep 17, 2013, at 2:58 PM, Steve Rowe <[email protected]> wrote:
>
>> Yeah, this configuration style is definitely a kludge around this Maven 
>> shortcoming.
>>
>> About submodules, though, you can see this in lucene/codecs/pom.xml.template 
>> aggregation POM - this is how maven specifies submodules (rather than via 
>> implicit recursive directories; submodules can be physically located in 
>> sibling directories):
>>
>>  <modules>
>>    <module>src/java</module>
>>    <module>src/test</module>
>>  </modules>
>>
>> Probably should be a comment in each of the three pom.xml.template files for 
>> each module: in the aggregation POM, the src/java POM and the src/test POM.
>>
>> On Sep 17, 2013, at 2:48 PM, Robert Muir <[email protected]> wrote:
>>
>>> yes a comment like that is good. i think what confused me was maybe
>>> the fact the submodules are under "src".
>>>
>>> if you look at this, you dont think there is any nested modules.
>>>
>>> [mac:maven/lucene/codecs] rmuir% ls -la
>>> total 8
>>> drwxr-xr-x   4 rmuir  staff   136 Oct 27  2012 .
>>> drwxr-xr-x  22 rmuir  staff   748 Jul 13 09:48 ..
>>> -rw-r--r--   1 rmuir  staff  1794 Sep  9  2012 pom.xml.template
>>> drwxr-xr-x   4 rmuir  staff   136 Oct 27  2012 src
>>>
>>> On Tue, Sep 17, 2013 at 2:45 PM, Steve Rowe <[email protected]> wrote:
>>>> +1 to add this comment to the pom.xml.template files for lucene-codec (and 
>>>> lucene-core, solr-core and solr-solrj), but the "dark magic" isn't 
>>>> necessary for Ant, since it's more flexible than Maven, so I don't think 
>>>> any mention needs to be made of this in build.xml files.
>>>>
>>>> Maven considers dependencies to be cyclic even if they are used in 
>>>> different build phases - e.g. lucene-test-framework has a compile-phase 
>>>> dependency on lucene-codecs, and lucene-codecs has a test-phase dependency 
>>>> on lucene-test-framework.
>>>>
>>>> On Sep 17, 2013, at 2:29 PM, Chris Hostetter <[email protected]> 
>>>> wrote:
>>>>> : Some background on the lucene-codec module's complex maven config
>>>>> : (lucene-core, solr-core, and solr-solrj all have the same setup):
>>>>> : <https://issues.apache.org/jira/browse/LUCENE-4365> - the two attached
>>>>> : images show the cyclic dependency situation involving the test-framework
>>>>> : modules before[1] and after[2] the maven config complexification.
>>>>>
>>>>> perhaps we need a comment in the lucene-codec pom.xml/build.xml files...
>>>>>
>>>>>     There is dark magic here, do not use this file as a template,
>>>>>      or inspiration, when adding new modules...
>>>>>         https://issues.apache.org/jira/browse/LUCENE-4365
>>>>>
>>>>>
>>>>> -Hoss
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [email protected]
>>>> For additional commands, e-mail: [email protected]
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [email protected]
>>> For additional commands, e-mail: [email protected]
>>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>

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

Reply via email to