tika-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris A. Mattmann (JIRA)" <j...@apache.org>
Subject [jira] Commented: (TIKA-41) Resource files occur twice in jar file.
Date Sat, 06 Oct 2007 00:10:50 GMT

    [ 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.


Mime
View raw message