[
https://issues.apache.org/jira/browse/TIKA-41?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12535262
]
Chris A. Mattmann commented on TIKA-41:
---------------------------------------
Hi Thilo:
While I understand both yours and Keith's concerns, what's nagging me is that I
too use eclipse to work on code, both on Tika and Nutch. However,when the time
to build comes along, I pull out my trusty command line and go from there. I've
never had much luck with integrating IDEs and build tools. Never got Mevenide
to work properly (really buggy in my environment), and despite the fact that it
works most of the time, even have some trouble with ant projects within eclipse.
I've found it's far easier, and doesn't cause one side or the other to
sacrifice anything really (besides the "feeling" of building within an IDE) if
you use an IDE to edit/code (and take advantage of all the language features,
and auto-compilation, etc.). Then when the time comes to make a delivery, or
build, or test the software, pull up that trusty command line and build the
project using the command line version of the tool which developers outside an
IDE environment can also use. It's also important to recognize that if both IDE
developers and vi/command line guys use the command line, they will have more
reproduceable results. I think it may be harder say, to track down build
problems when you're using the integrated build environment (that wraps an
external build tool like Maven or Ant). I have had trouble in the past, where
it's actually been a problem with the Eclipse/Maven plugin (rather than a
problem with the actual POM file), and I've spent way too many hours tracking
this down.
I'm not trying to prevent people from using the software or contributing, but
to me (as I stated before in a comment on this post), I think we're on a
slippery slope here. While I agree that in the short term, and in isolation,
this is a small concession to make, that helps out folks who are in the IDE for
everything world. I don't want to shut them out. However, I also think it's a
bad idea for Tika as a project to make code-level/build-level concessions
simply to support technology choices that users make. To me, that's letting
technology dictate the (implementation) architecture, which in my experience as
a software architect, never leads to a good thing.
My 2 cents,
Chris
> 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
> Assignee: Jukka Zitting
> Priority: Minor
> Fix For: 0.1-incubator
>
> Attachments: TIKA-41.patch
>
>
> 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.
