Martin Desruisseaux wrote:
Jody Garnett a écrit :
Any other ideas? Any wisdom? Any magic spells to restore sanity to the
class loader mechanism?
Ant!
Not needed, provided that next geotools-bin*.zip zipball are produced
with Maven 2 (in which case the user would not be required to use
Maven 2 himself). The trick is:
The original email spelled out that maven (of any description) was out
of bounds, and I suspect that Ant is too heavyweight as well. That said
I am not sure we *can* get geotools into a bite size gulp for Mr Custer.
Of course not sure if we should either ...
Note: is is also possible to instruct Maven 1 to fill the "Class-path"
entry in META-INF/MANIFEST.MF file, but it is a little bit more
complicated than Maven 2. Do we want to put more energy into Maven 1
build, or just try to finish the switch to Maven 2?
The maven 1 build is dead Martin, we are switching uDig over to grab
jars from the maven 2 Repo etc... GeoServer is switching over this week
as well, I did run into a bunch of trouble that only occurred when
*using* geotools jars, mostly in terms of "excludes" that became
required when importing more then one geotools jars. Suspect that we
need some "dummy" modules that just catch common geotools configurations...
Cheers,
Jody
-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid0709&bid&3057&dat1642
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
