Hi Adrian, For the demo code I was going to *not* make use of any other pom.xml files and make each one freestanding. I had hoped that users would not have to worry about how we organized our code base, and could simply depend on jars that were published in the usual maven way (tm).
My only question was how to make unsupported things look unsupported, perhaps we should have them published out with a different prefix then "gt", something like "rnd-". For Martin's hacking he is mostly trying to make use of the traditional maven build structure with in each module - so that it is less of a pain for those working with other projects. I think his motivation comes from wanting to have more then just java code considered as "src". As for the short names that is my fault, I hate typing. Jody > Hey Martin, all, > > Thanks for taking this on. > > > I don't really need an answer to this email, merely wanted to throw out > an idea that you might want to digest and might influence the result. > > I'm a bit puzzled however by the resulting structure of your reshuffle. > The Maven site says: > There are just two subdirectories of this structure: src and > target. The only other directories that would be expected here > are metadata like CVS or .svn, and any subprojects in a > multiproject build (each of which would be laid out as above). > Are we going to have nothing but 'subprojects' and conserve our > demo > ext > module > plugin > unsupported > structure? The advantage would be that it would be trivial for a user to > take our layout and add their app as the top level src/main/java > project! > > If so, I'd like you to consider making the subproject directories more > explicitly > (1) code holding folders, > (2) equivalent but with different purpose. > I'm thinking of pluralized, whole words like > demonstrations > extensions > plugins > modules > unsupported (!) > or even > modules_demonstration > modules_extension > modules_core > modules_plugin > modules_unsupported > the idea being to get users to see immediately that these directories > have code, in a modular structure, with different levels of importance > to the project. Okay, the latter is mega clunky but would be easy for a > user to understand; maven seems to have decided that parallelism is more > important than a sparse layout. > > --adrian > > > ------------------------------------------------------------------------- > 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&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Geotools-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/geotools-devel > ------------------------------------------------------------------------- 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&kid=120709&bid=263057&dat=121642 _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
