Re: [Geotools-devel] IRC Logs

[Martin D. <mar...@no...>]

Hello all

Some answers to the IRC meeting:

Jody Garnett a =E9crit :
> 	jgarnett	problem is I do not recognize everything - like main/modified=
-src - what is that for?

As answered in a previous email a few hour ago, it is (or was?) for javac=
c. The javacc compiler=20
creates automatically a set of Java files, to be put in the target/genera=
ted-sources directory=20
before being compiled like any other java sources as part of "mvn install=
". The "modified-src"=20
directory contains Java source that should replace the source automatical=
ly generated by javacc.

The javacc thing was setup by James, but I ported it from Maven 1 to Mave=
n 2. I really don't know if=20
it still used however. The generated classes lives in the org/geotools/fi=
lter/parser package.

Do we have a new filter parser engine in Geotools? If yes, then I assume =
that the javacc stuff can=20
be removed. In such case, I can volunter for removing the javacc stuff fr=
om the Maven 2 build.


> 	aaime	Martin does not keep us very up to date :-(
> 	aaime	He's not only merging, also refactoring a lot

This is true that I'm doing a lot of refactoring in the process. But I'm =
leaving the original name=20
space untouched. I mean, I do not modify ImageUtilities.addTransparency2I=
ndexColorModel for example.=20
I create a new method in a new class (namely ImageWorker), and bring it f=
or consideration as a=20
replacement. With the refactoring, I try to avoid some hard-coded constan=
ts (e.g. the transparent=20
pixel value hard-coded to 255), avoid the requirement for a PlanarImage w=
here a RenderedImage=20
interface would suffice, try to separate some concerns when a method does=
 two things or more that=20
could have been separated in some logical steps (e.g. factor a "mask" met=
hod out of=20
"addTransparency2IndexColorModel"), avoid the overhead of creating a Rend=
eredOp (by wrapping a=20
RenderedImage into a "Null" operation) when the user only wants a Rendere=
dImage, avoid some apparent=20
dupplication (e.g. "direct2ComponentColorModel" and "reformatColorModel2C=
omponentColorModel" seem=20
quite similar) etc.

I commited today the ImageUtilities methods from the coverage branch to t=
he trunk, so Andrea and=20
Simone will be able to run their code unchanged. For every methods, I add=
ed the proposed replacement=20
in a disabled block. For example the "rescale2Byte" methods is as below:

         if (PROPOSED_REPLACEMENT) {
             ImageWorker w =3D new ImageWorker(surrogateImage);
             w.rescaleToBytes();
             return w.getPlanarImage();
         }
         // The coverage branch code, unchanged.

Because PROPOSED_REPLACEMENT is a private static final boolean initialize=
d to 'false', the proposed=20
replacement is trimed by javac and the compiled code should be identical =
to the coverage branch=20
code. In some later stage, Andrea or Simone can turn the "if (PROPOSED_RE=
PLACEMENT)" statement into=20
"if (true)" statement once at time and test if it work as expected. They =
can do that at whatever=20
time is nice for them - in the main time, the coverage branch code is the=
re, so their applications=20
should be unaffected.


> 	jgarnett	I would also really like it if we were able to proceed on the=
 OSGEO iccubation process

What is missing?

 From the referencing module point of view, I think the IP is okay (since=
 we got Frank authorization=20
to distribute the Proj4 derived code under LGPL). I need to update the he=
aders however.

For the coverage module, I believe that the IP is okay as well.


> 	simboss	martin is meging on trunk directly
> 	simboss	so would anybody get mad at me
> 	simboss	if i start meging the plugins
> 	simboss	to test what I have to change
> 	simboss	as a consequence of his refactor
> 	simboss	?
> 	simboss	this might imply
> 	simboss	having broken builds on some plugins-modules
> 	aaime	I see... maybe you can remove those modules from the build?
> 	aaime	It' just a matter of modifying the parent's pom.xml

Temporary removal of module from the parent pom.xml seems fine to me.

Is the following approach acceptable for futur development?

Incremental work done more often on trunk (a little bit less branch). We =
would create a branch when=20
a deep refactoring is in progress, but if the changes can be done increme=
ntaly without breaking "mvn=20
install". I would like to see such work more often on the trunk. I sugges=
t that we "only" insist for=20
the following rules:

* "mvn install" should always work (by commenting-out some modules
   from the parent pom.xml if needed).

* ALL new public/protected class/field/method must have a "@since 2.3" ja=
vadoc tag
   (or "@since 2.4" after the 2.3 release, etc.).

* All classes/fields/methods with a "@since 2.3" javadoc tag can be modif=
ied, renamed,
   moved or deleted in an incompatible way as long as 2.3 has not be been=
 released. Geotools
   developpers working with trunk are warned that they should avoid all m=
ethods with such
   javadoc tag, or use them at their own risks.

* All public or protected classes/fields/methods with "@since 2.2", "@sin=
ce 2.1" or
   "@since 2.0" javadoc tags are not allowed to be deleted or modified in=
 an incompatible
   way (unless the method was obviously broken). They can only be depreca=
ted for the 2.3
   release, and deleted in a post 2.3 release.


If the above rules are respected, I would be happy to work with a more "u=
nstable" trunk. Would it be=20
an acceptable approach?


	Regards,

		Martin.