Handle external dependencies better
Brought to you by:
keeskuip
Menu
▾
▴
#10 Handle external dependencies better
I can see how to some extent it's advantageous bundling everything (including other 3rd party packages) in one jar. However, this is causing me some grief.
For instance, my own app's maven pom had a dependency on 1.0.2 of the jgoodies forms. It appears earlier in the classpath, so I presume that's why I ran into some method not found error in the jgoodies code.
I then upgraded forms to 1.2.1; this time a different error.
Ultimately realized you were dependent on 1.0.7, so I've stuck with that and all is well.
Don't get me wrong, this to some extent reflects poorly on jGoodies' backwards compatibility. What I'd like to know is if we could improve the packaging (i.e. don't internalize all 3rd party code) and have the dependencies clearly stated somewhere.
Just my two cents. This is definitely low priority
If you checkout the project with svn you can see all libraries in the ./lib directory.
These names of these libs are also in the build.xml.
If you want to package without JGoodies just change the build.xml and rebuild with ant.