[
https://issues.apache.org/jira/browse/TIKA-41?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12532802
]
Chris A. Mattmann commented on TIKA-41:
---------------------------------------
>If you have a document that shouldn't go into the jar artifact, then by the
>Maven conventions you'd place it in src/test/resources (if it's needed for
>testing), src/site/resources (if it should go to the web site), or
>src/main/javadoc (if it should be a par t of the javadocs). I don't see why we
>should reinvent the wheel by maintaining our own build rules for such
>resources.
What about resources that don't fit into any of these buckets? What about
design docs that aren't meant to be published on the website, but should be
CM'ed for tracking purposes? Figures? Diagrams? Things such as this that aren't
necessarily for the website, for the unit tests, or for the source code to be
delivered? Where do these go?
Of course, I'm being fecicious here, as the files we're debating are XML config
files that *are* definitely part of the build. My only concern is mandating
that the build time representation of the tika library (currently a jar file)
look 100% the same as the source tree takes us down a slippery slope. I'll
admit that Tika is in its currently nascent stages and its current deliverable
is most likely going to be a jar file. However, how do we want to handle things
like dependencies? Or packaging up scripts to go along with Tika? I'm not sure
it makes sense to put *everything* in a jar file, right?
Finally with respect to your point about IDEs, I'm not sure I agree that
putting someting in:
src/main/resources/org/apache/tika/tika-config.xml
src/main/resources/org/apache/tika/mime/tika-mimetypes.xml
is easier to figure out/understand than:
src/main/resources/tika-config.xml
src/main/resources/mime/tika-mimetypes.xml
which, to me, have a much cleaner structurer, and aren't nested 3 levels deeper?
I may just not be seeing the point here :), so maybe you'll have to englighten
me.
> 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.