Closed GoogleCodeExporter closed 9 years ago
The voodoo performed by the Spring PathMatchingResourcePatternResolver is
pretty hefty. I doubt this is easily replaced by something else. The long list
of imports of that class leads me to believe that we'd have to copy a
significant amount of code to our codebase if we chose that - and we'd have to
maintain that...
The dependency on the apache commons logging API may be regarded annoying.
The dependency on spring-asm is afaik not necessary as I do not make any use of
that aspect of the Spring framework atm.
The dependency on spring-core is sensible as Spring implements very descent
class-path scanning capabilities. I would very much prefer using that than
adding a dependency on another jar instead.
If you are really worried about the dependency, I would suggest moving
org.uimafit.factory.TypeSystemDescriptionFactory.createTypeSystemDescription()
to a separate class org.uimafit.util.TypeSystemDetector.findAllTypes() and make
the dependency on Spring an optional one. Thus people can select to use the
feature and have Spring in the classpath - or not use it.
For the time being, I'll exclude spring-asm... and while I am at it, I'll also
make jdom a test dependency since it is only every used in a testing code.
Original comment by richard.eckart
on 27 Sep 2010 at 9:13
Original comment by pvogren@gmail.com
on 4 Jan 2011 at 12:15
Won't happen. In fact, with issue 79, Spring was integrated even more.
Original comment by richard.eckart
on 5 Jul 2012 at 9:33
Original issue reported on code.google.com by
pvogren@gmail.com
on 27 Sep 2010 at 7:31