Hello all
Some answers to the IRC meeting:
Jody Garnett a écrit :
> 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 javacc. The
javacc compiler
creates automatically a set of Java files, to be put in the
target/generated-sources directory
before being compiled like any other java sources as part of "mvn install". The
"modified-src"
directory contains Java source that should replace the source automatically
generated by javacc.
The javacc thing was setup by James, but I ported it from Maven 1 to Maven 2. I
really don't know if
it still used however. The generated classes lives in the
org/geotools/filter/parser package.
Do we have a new filter parser engine in Geotools? If yes, then I assume that
the javacc stuff can
be removed. In such case, I can volunter for removing the javacc stuff from 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
space untouched. I mean, I do not modify
ImageUtilities.addTransparency2IndexColorModel for example.
I create a new method in a new class (namely ImageWorker), and bring it for
consideration as a
replacement. With the refactoring, I try to avoid some hard-coded constants
(e.g. the transparent
pixel value hard-coded to 255), avoid the requirement for a PlanarImage where a
RenderedImage
interface would suffice, try to separate some concerns when a method does two
things or more that
could have been separated in some logical steps (e.g. factor a "mask" method
out of
"addTransparency2IndexColorModel"), avoid the overhead of creating a RenderedOp
(by wrapping a
RenderedImage into a "Null" operation) when the user only wants a
RenderedImage, avoid some apparent
dupplication (e.g. "direct2ComponentColorModel" and
"reformatColorModel2ComponentColorModel" seem
quite similar) etc.
I commited today the ImageUtilities methods from the coverage branch to the
trunk, so Andrea and
Simone will be able to run their code unchanged. For every methods, I added the
proposed replacement
in a disabled block. For example the "rescale2Byte" methods is as below:
if (PROPOSED_REPLACEMENT) {
ImageWorker w = new ImageWorker(surrogateImage);
w.rescaleToBytes();
return w.getPlanarImage();
}
// The coverage branch code, unchanged.
Because PROPOSED_REPLACEMENT is a private static final boolean initialized to
'false', the proposed
replacement is trimed by javac and the compiled code should be identical to the
coverage branch
code. In some later stage, Andrea or Simone can turn the "if
(PROPOSED_REPLACEMENT)" statement into
"if (true)" statement once at time and test if it work as expected. They can do
that at whatever
time is nice for them - in the main time, the coverage branch code is there, so
their applications
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
to distribute the Proj4 derived code under LGPL). I need to update the headers
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
a deep refactoring is in progress, but if the changes can be done incrementaly
without breaking "mvn
install". I would like to see such work more often on the trunk. I suggest that
we "only" insist for
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" javadoc
tag
(or "@since 2.4" after the 2.3 release, etc.).
* All classes/fields/methods with a "@since 2.3" javadoc tag can be modified,
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 methods
with such
javadoc tag, or use them at their own risks.
* All public or protected classes/fields/methods with "@since 2.2", "@since
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 deprecated
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
"unstable" trunk. Would it be
an acceptable approach?
Regards,
Martin.
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
