search

fangfangli / cleartk

Automatically exported from code.google.com/p/cleartk
0 stars 0 forks source link

Remove cleartk-util dependency on args4j and hppc #255

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
cleartk-util has a dependency on args4j because of the Options_ImplBase class 
which is essentially a single six-line method. Either this should just be 
inlined in the 4 places it's used, or we should create a separate 
cleartk-commandline module. As it currently stands, all cleartk-* modules 
depend on args4j because they all depend on cleartk-util.

Original issue reported on code.google.com by steven.b...@gmail.com on 23 Sep 2011 at 10:50

GoogleCodeExporter commented 9 years ago 
My opinion is that we should use args4j liberally across all projects for 
creating simple command line interface programs that demonstrate/provide 
functionality.  My assumption was that this little bit of code that I have 
introduced would be the seed of additional args4j infrastructure as we got busy 
writing CLIs throughout ClearTK.  

Args4j is small, has no additional dependencies, has a favorable license, is 
widely used, and appears to be actively maintained.  So, I haven't had any 
reason to worry about adding it as a dependency.  Also, the notion of a project 
called 'cleartk-commandline' does not seem to be at quite the level of 
granularity for cleartk projects as I would like (i.e. it's too granular) - but 
that's a very subjective opinion.  Even still, you're suggesting a new project 
for 6 lines of code seems a bit overkill.

Perhaps we might discuss what your concerns about args4j are?

Original comment by phi...@ogren.info on 27 Sep 2011 at 3:36

GoogleCodeExporter commented 9 years ago 
Basically, I was taking a careful look at cleartk-util's dependencies because 
*everything* in ClearTK depends on cleartk-util, so those dependencies get 
added to *every* ClearTK project. I saw:

* uimafit - used in almost all ClearTK code, so this is fine
* commons-io - used in quite a bit of ClearTK code, so this is fine
* guava - used in quite a bit of ClearTK code, so this is fine
* hppc - used only by SVM models, so this is odd
* args4j - used only in 4 places, so this is odd

I don't feel super strongly about this, it's just that those bottom two 
dependencies are propagated to all ClearTK modules but are used in almost none 
of them.

Original comment by steven.b...@gmail.com on 27 Sep 2011 at 8:17

GoogleCodeExporter commented 9 years ago 
I'm ambivalent about the hppc dependency.  I appreciate your distaste for 
propagating dependencies that are used very seldom to all of the projects.  On 
the other hand, I don't like seeing lots and lots of little projects that have 
very little code in them.  

Args4j I don't feel ambivalent about.  I would like to see us have lots of 
CLI's throughout ClearTK and so moving the code into a separate project seems 
*somewhat* counter to this objective.

Original comment by phi...@ogren.info on 28 Sep 2011 at 2:43

GoogleCodeExporter commented 9 years ago 
Agreed that we should just keep an args4j dependency around and use it for all 
our command line interfaces.

Original comment by steven.b...@gmail.com on 12 Feb 2012 at 5:04

GoogleCodeExporter commented 9 years ago 
I'm reopening this issue. Having used both args4j and jewelcli for a while now, 
I'm of the opinion that jewelcli is a significantly better library. So I think 
we don't want args4j in cleartk-util.

Note that I don't think we should put jewelcli into cleartk-util either. It 
doesn't need any helper code (as apparently args4j does) so it can just be 
added as a dependency to the projects that need it. See 
org.cleartk.timeml.eval.TempEval2013Evaluation for an example.

Original comment by steven.b...@gmail.com on 30 May 2013 at 5:54

GoogleCodeExporter commented 9 years ago 
I think for hppc, we could probably make it an optional dependency:

http://maven.apache.org/guides/introduction/introduction-to-optional-and-exclude
s-dependencies.html

Then the three places where it's used (cleartk-ml-libsvm, cleartk-ml-svmlight 
and cleartk-ml-tksvmlight) can declare that they need that dependency, and 
everything else should be free of it.

I guess we could do the same thing for args4j, though as I mentioned in the 
last comment, I think jewelcli is a superior library, and I'd rather we just 
ditched args4j.

Original comment by steven.b...@gmail.com on 28 Jul 2013 at 8:32

GoogleCodeExporter commented 9 years ago 
I replaced all uses of args4j with jewelcli in revision 
2726491edd1b4b03273433284b80f5d093f1bc92, revision 
3a3cdd5c4f8872bab68458291c200628297ca3cb and revision 
83fdcc1659efad66e1416fcacebdc2c0f4624adf.

I removed hppc entirely, because it turned out it wasn't any faster than a 
regular HashMap<String, Integer> where it was being used. So that's gone in 
revision 2aac23b0cee31a39710ead6e0769f9b92e96819d.

Two classes were deleted as a result: 
org.cleartk.util.collection.WrappedHPPCStringIntMap and 
org.cleartk.util.Options_ImplBase.

Original comment by steven.b...@gmail.com on 29 Jul 2013 at 12:24

GoogleCodeExporter commented 9 years ago

Original comment by steven.b...@gmail.com on 29 Jul 2013 at 12:25