Hello Adrian and all Adrian Custer a écrit : > Hey Martin, > > Could you write a blurb about each of these and what it is used for? I > can now guess at what these are but I'm not positive. I'd like to be > totally sure before I go in and delete javadoc/ for example since this > is presumably now outdated. > > > ll maven/ > total 36K > drwxr-xr-x 6 acuster acuster 4.0K 2006-10-10 12:04 build-configs/
This one was added by Andrea. This module contains some global configuration files in this directory, like Jaloppy configuration and Clover license (required for running). I believe that it is used in the default Maven build for formatting the API module - more modules may be added in the future. As for Clover, last time I tried, I had to copy the 'maven/build-configs/src/gt2/clover.license' file by hand in a 'gt2' directory in order to get Clover running. I don't know if it is the intented behavior or not. > drwxr-xr-x 6 acuster acuster 4.0K 2006-10-10 12:04 jar-collector/ Used in order to copy every JAR in a single directory, namely '<geotools root>/target', together with their dependencies. The rational was to reduce the number of JAR files duplicated in different directories. Back in our old Maven 1 days, we were distributing a huge ZIP file with Geotools JARs in different directories (basically keeping the '<module>/target' directory structure) together with their dependencies. The result was that if an external JAR file (e.g. postgresql.jar) were used in many modules, this JAR was copied in different directory, resulting in Geotools releases distributing a much bigger ZIP file than required. We created a 'shared' directory for avoiding this duplication, but it was not up to date. Some JAR files was still duplicated in various directories because we forget to put them in the 'shared' directory. Putting all JAR files in a single directory make sure that we don't have duplication. In addition, it allows the META-INF/MANIFEST.MF/<classpath entry> to work, thus making usage of Geotools JAR much easier (just one file to put explicitly in the user classpath, all other JARs are found automatically). It may duplicate in some way the standard Maven 'assembly' plugin - I must admit that I didn't investigated the assembly plugin deep enough (at the time I wrote jar-collector, Maven plugins were poorly documented). If the standard Maven plugin can do the same work, it is probably better to use it and abandon jar-collector. > drwxr-xr-x 7 acuster acuster 4.0K 2006-10-10 12:04 javadoc/ Contains the custom taglets (namely @source and @tutorial}, as well as a few utilities, like CommentUpdater that I used for adding automatically "@source $URL$" in every .java files. CommentUpdater was used only once - I keept it in case a similar work would be needed again in the future. The taglets are theorically used everytime we build the javadoc. > drwxr-xr-x 6 acuster acuster 4.0K 2006-10-10 12:04 javamaker/ Used for the openoffice addin. No equivalent in the Maven community I'm aware of. This is called "javamaker" because in theory, it should invoke the "javamaker" tools from the OpenOffice SDK, which is a compiler generating .class files from an OpenOffice IDL file (indirectly). In practice, I can't assume that every developpers have an OpenOffice SDK installed on their machine, so I commited the .class files in the SVN and our "javamaker" plugin similate the real OpenOffice "javamaker" tools be copying the .class file in the right place. We can't use the standard Maven resources mechanism for copying those classes because the copy must overwrite the .class files generated by javac (javamaker creates .class files in a particular way for OpenOffice - trying to generate the same .class files with javac doesn't work). > drwxr-xr-x 6 acuster acuster 4.0K 2006-10-10 12:04 jjtree-javacc/ Used for copiling this file from the main module: http://svn.geotools.org/geotools/trunk/gt/module/main/src/org/geotools/filter/parser/expr.jjt which produces automatically those classes: http://javadoc.geotools.fr/2.2/org/geotools/filter/parser/package-summary.html I have no idea if those classes are effectively used, or if this is a remanescence of some old Geotools way. I asked the question two or three times on the mailing list and never got an answer. I don't know what is the current way to parse filters in Geotools. If we want to keep this expr.jjt file, then it would be nice if we could get some volunter for getting Maven to work with the following plugin: http://mojo.codehaus.org/javacc-maven-plugin/ Again, this plugin didn't existed at the time I wrote jjtree-javacc. It would be nice to get ride of our custom plugin and use the official one instead. > drwxr-xr-x 6 acuster acuster 4.0K 2006-10-10 12:04 rmic/ Used for invoking the JDK "rmic" tools. Was used by the legacy CTS module, now removed from the trunk. In addition, Mojo provide this tools now (but in a unsupported way): https://svn.codehaus.org/mojo/trunk/mojo/mojo-sandbox/rmic-maven-plugin/ So we can probably delete this module from SVN. > drwxr-xr-x 6 acuster acuster 4.0K 2006-10-10 12:05 unopkg/ Again used for the OpenOffice addin. It creates the final ".uno.pkg" file, which is the installation file for OpenOffice users. It has no equivalent in the Maven community as far as I know. > drwxr-xr-x 7 acuster acuster 4.0K 2006-07-28 21:22 www/ Contains web page for http://javadoc.geotools.fr and http://maven.geotools.fr home (in English despite the .fr prefix). The geotools.fr server (or any other server wishing to provide the same services) uses symbolic links pointing directly to those files in our local SVN repository. This means that if you or anybody else edit those pages, the update will appears in http://???.geotools.fr as soon as an "svn update" is executed on this machine (currently every Sunday). Martin ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
