sudeep87 / uimafit

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

consider removing dependency on Spring #40

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
So, I am creating this issue as a placeholder for considering removing the 
Spring dependency.  The only class that is using it is 
TypeSystemDescriptionFactory which uses the classpath searching capabilities 
found in PathMatchingResourcePatternResolver.  

The concern is adding a dependency for a fairly large framework to get access 
to a single class that has one specific function that we use.  I think it is 
generally good policy to avoid dependencies where we can with larger 
dependencies being less attractive.  

Here are two possible solutions:
1) copy PathMatchingResourcePatternResolver into our code base and any code 
that it depends on.  This assumes that the class is fairly local and doesn't 
actually depend on the rest of spring.  
2) use java.net.commons AbstractClassLoaderResolver

both solutions are ASL 2.0 so there is no reason we can't just copy the code in 
and redistribute it so long as we don't change the copyright.  

Original issue reported on code.google.com by pvogren@gmail.com on 27 Sep 2010 at 7:31

GoogleCodeExporter commented 8 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

GoogleCodeExporter commented 8 years ago

Original comment by pvogren@gmail.com on 4 Jan 2011 at 12:15

GoogleCodeExporter commented 8 years ago
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