[
https://issues.apache.org/jira/browse/TIKA-41?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12532676
]
Chris A. Mattmann commented on TIKA-41:
---------------------------------------
> To me the cleanest and simplest solution is to have a direct one-to-one
> mapping between the src tree and the resulting jar file entries
I am on the complete opposite end of the spectrum with this. If there should
always be a 1-to-1 mapping between build and src, then why have jar files in
the first place? Why not just compile class files directly into the directories
that contain their source code and deliver that as the build time package?
The reason to have decoupling between src and build structures is for
independent evolution. It's to apply a filter on the things that exist in the
source area, and the things that get delivered as part of the build. As an
example of this, what if I wanted to drop an MS Word document containing some
diagrams/figures for Tika in src/main/resources, because logically, to me,
that's the place where that file should live in src (and subsequently CM). Now,
when I go to build Tika, should this MS Word file be placed in the delivered
jar file? IMO, the answer is no.
Here we have a somewhat different, but also simliar issue, of config files that
need to end up in some build-time location as a run-time dependency within the
Tika jar file. Why do we have to mandate within the src tree in CM that this
file (which in some ways is just as much of a resource as that MS Word Tika
document) be placed in its build-time location which is namespace delimited,
and 3 levels deeper within the already deep enough directory hierarchy?
So, anyways, I agree with one of your points, Jukka. The proposed method of
placing those config files within org/apache/tika is definitely the simplest
solution: I'm just not sure it's the cleanest.
> Resource files occur twice in jar file.
> ---------------------------------------
>
> Key: TIKA-41
> URL: https://issues.apache.org/jira/browse/TIKA-41
> Project: Tika
> Issue Type: Improvement
> Affects Versions: 0.1-incubator
> Reporter: Keith R. Bennett
> Priority: Minor
> Fix For: 0.1-incubator
>
>
> The Tika and Mime config files occur in two places in the jar file. This is
> because they are not stored in our src/test/resources directory tree in the
> same place that they need to be in the target/classes directory tree, and
> there is a copy directive in the POM file that copies the files to different
> directory.
> For example, tika-config.xml is in src/main/resources, but needs to go to
> target/class/org/apache/tika. Maven automatically copies the files in
> src/main/resources to the same location in target/classes, so tika-config.xml
> is copied to target/classes. Then, the copy directive in the POM file copies
> the file to target/classes/org/apache/tika. So the file is copied twice.
> I recommend the following to fix this:
> * Move tika-config.xml to src/main/resources/org/apache/tika.
> * Move tika-mimetypes.xml to src/main/resources/org/apache/tika/mime.
> * Remove the copy directives for the above two from the POM file.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
