Matthias Basler a écrit :
> I not use maven for my project(s). I have always had a little ant script for
> downloading the required GT jars and dependencies (like uDig did) and have
> thrown them in one flat directory too. This has worked nicely so far until
> now.
Jody pasted their Ant script. I'm looking at it in order to see if I could help.
Note: I love JARs in flat directory too... Maven can do that for you, including
putting the right prefix in from of JAR files.
I can understand that you don't want to use Maven. But I wonder if there is any
chance to setup a minimal pom.xml listing your dependencies. Just invoking "mvn
clean install" would download the needed GeoTools JAR (and only them), the
needed transitive dependencies (and only them) and put all this stuff in a flat
directory with the right names. If you don't use Maven for compiling your
project, I guess that it would be fast.
Would you like me to try to setup such a pom.xml for you?
> By the way: I don't know any other project whose jars are named differently
> in the maven repositories and in the release ... which is what is intended
> currently if I understand the mails correctly. I find this plainly irritating.
The problem is that we have a somewhat deep hierarchy, e.g.:
modules/extension/xsd/core
Using full names:
gt-modules/gt-extension/gt-xsd/gt-core
They were also a request to distinguish between core library and unsupported
stuff, which leads us to:
gt-modules/gt-extension/gt-est-xsd/gt-ext-core
We get quite long and redundant filename.
groupID is supposed to avoid the need to prefix artifactId. If peoples continue
to prefix it, maybe it is because Maven is unfortunatly not bug-free and
groupId
is not providing the expected behavior? My hope is that it will be
progressively
fixed as Maven improves.
> So I wonder:
> - Do you really expect every user to use maven and actually build GT?
To build GT, definitively not. To use Maven... well if they do they can have
this flat directory. If they don't, then I agree that we need to find some way
to help them.
> What about providing a separate location in an online repository where the GT
> shapshot jars can be found with names similar to how they will appear in the
> final release (i.e not conflicting with each other and other dependencies)?
> This would be my idea how to solve this in the most simple way.
This one is built daily:
http://hudson.geomatys.fr/job/GeoTools/ws/gt/target/binaries/
Martin
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
