Hi all
I ask here, as I am not sure this should go in the issues list in jira,
as it is not a issue for most people. Just those who compile on their own.
I have problems compiling the codebase a second time using ant (1.6.5).
I always need to do a clean before I do a compile.
If not I get a error like this:
all:
[javac] Compiling 2 source files to
D:\projects\subversion\geoserver\build
[javac] error: error reading
D:\projects\subversion\geoserver\build\META-INF\services\org.vfny.geoserver.wfs.FeatureResponseDelegateProducerSpi;
error in opening zip file
[javac] 1 error
This is due to the fact that the META-INF is included into the build
classpath by this:
<path id="path.build">
<path refid="path.lib" />
<fileset dir="${dir.build}">
<include name="**/*" />
</fileset>
<fileset dir="${dir.build}">
<include name="org/vfny/geoserver/requests/GetCapabilitiesSuite.class" />
</fileset>
</path>
This entry includes every file in the build folder:
<fileset dir="${dir.build}">
<include name="**/*" />
</fileset>
changing it to use just class files instead will make it work:
<fileset dir="${dir.build}">
<include name="**/*.class" />
</fileset>
but this brings me to another issue.
Why do we need to output folder in the classpath?
As long as we have the java source in the source path we are fine.
I tried to remove the build/ folder from the build classpath and it was
fine. I tried to start the inline jetty without it, and it was fine.
Could there be other targets that needs the output folder in the classpath?
Magne
Quoting Magne Skjeret <magne.skjeret@anonymised.com>:
Hi all
I ask here, as I am not sure this should go in the issues list in
jira,
as it is not a issue for most people. Just those who compile on their
own.
Developers are users too! 
Yeah, stick it in the JIRA.
I have problems compiling the codebase a second time using ant
(1.6.5).
I always need to do a clean before I do a compile.
If not I get a error like this:
all:
[javac] Compiling 2 source files to
D:\projects\subversion\geoserver\build
[javac] error: error reading
D:\projects\subversion\geoserver\build\META-INF\services\org.vfny.geoserver.wfs.FeatureResponseDelegateProducerSpi;
error in opening zip file
[javac] 1 error
Oh I've gotten this too once or twice. It seemed to be only with Java
1.5, but I rarely use Java 1.5 so didn't bother to figure it out.
This is due to the fact that the META-INF is included into the build
classpath by this:
<path id="path.build">
<path refid="path.lib" />
<fileset dir="${dir.build}">
<include name="**/*" />
</fileset>
<fileset dir="${dir.build}">
<include
name="org/vfny/geoserver/requests/GetCapabilitiesSuite.class" />
</fileset>
</path>
This entry includes every file in the build folder:
<fileset dir="${dir.build}">
<include name="**/*" />
</fileset>
changing it to use just class files instead will make it work:
<fileset dir="${dir.build}">
<include name="**/*.class" />
</fileset>
but this brings me to another issue.
Why do we need to output folder in the classpath?
As long as we have the java source in the source path we are fine.
I tried to remove the build/ folder from the build classpath and it
was
fine. I tried to start the inline jetty without it, and it was fine.
Could there be other targets that needs the output folder in the
classpath?
I'm not sure, never really thought about it. I think perhaps when we
did an embedded tomcat instead of embedded Jetty it may have actually
needed it. I'd say for now just fix the .class thing, and when we get
a dev branch after we get a stable 1.3.x branch we can put the fix
there. Just since it _could_ cause other weird errors for developers
trying to get the release out.
best regards,
Chris
Magne
----------------------------------------------------------
This mail sent through IMP: https://webmail.limegroup.com/
Hi Magne,
I am not 100% sure but I suspect the META-INF folder is included so that all the plugins in the META-INF/services directed are included on the classpath. If not, no plugins will get loaded. Probably also the reson for the **/* instead of **/*.class.
However you are right in that these things dont need be on the classpath unless you are actually running code (tests).
I am having trouble replicating the problem. Can you tell the exact sequence of targets to run.
If your modifications still allow all the unit tests to pass, and the "release" target is not affected, then I dont see a problem with the change.
Justin
Magne Skjeret wrote:
Hi all
I ask here, as I am not sure this should go in the issues list in jira,
as it is not a issue for most people. Just those who compile on their own.
I have problems compiling the codebase a second time using ant (1.6.5).
I always need to do a clean before I do a compile.
If not I get a error like this:
all:
[javac] Compiling 2 source files to
D:\projects\subversion\geoserver\build
[javac] error: error reading
D:\projects\subversion\geoserver\build\META-INF\services\org.vfny.geoserver.wfs.FeatureResponseDelegateProducerSpi;
error in opening zip file
[javac] 1 error
This is due to the fact that the META-INF is included into the build
classpath by this:
<path id="path.build">
<path refid="path.lib" />
<fileset dir="${dir.build}">
<include name="**/*" />
</fileset>
<fileset dir="${dir.build}">
<include name="org/vfny/geoserver/requests/GetCapabilitiesSuite.class" />
</fileset>
</path>
This entry includes every file in the build folder:
<fileset dir="${dir.build}">
<include name="**/*" />
</fileset>
changing it to use just class files instead will make it work:
<fileset dir="${dir.build}">
<include name="**/*.class" />
</fileset>
but this brings me to another issue.
Why do we need to output folder in the classpath?
As long as we have the java source in the source path we are fine.
I tried to remove the build/ folder from the build classpath and it was
fine. I tried to start the inline jetty without it, and it was fine.
Could there be other targets that needs the output folder in the classpath?
Magne
--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org
Hi Magne,
I am not 100% sure but I suspect the META-INF folder is included so that all the plugins in the META-INF/services directed are included on the classpath. If not, no plugins will get loaded. Probably also the reson for the **/* instead of **/*.class.
However you are right in that these things dont need be on the classpath unless you are actually running code (tests).
I am having trouble replicating the problem. Can you tell the exact sequence of targets to run.
If your modifications still allow all the unit tests to pass, and the "release" target is not affected, then I dont see a problem with the change.
Justin
Magne Skjeret wrote:
Hi all
I ask here, as I am not sure this should go in the issues list in jira,
as it is not a issue for most people. Just those who compile on their own.
I have problems compiling the codebase a second time using ant (1.6.5).
I always need to do a clean before I do a compile.
If not I get a error like this:
all:
[javac] Compiling 2 source files to
D:\projects\subversion\geoserver\build
[javac] error: error reading
D:\projects\subversion\geoserver\build\META-INF\services\org.vfny.geoserver.wfs.FeatureResponseDelegateProducerSpi;
error in opening zip file
[javac] 1 error
This is due to the fact that the META-INF is included into the build
classpath by this:
<path id="path.build">
<path refid="path.lib" />
<fileset dir="${dir.build}">
<include name="**/*" />
</fileset>
<fileset dir="${dir.build}">
<include name="org/vfny/geoserver/requests/GetCapabilitiesSuite.class" />
</fileset>
</path>
This entry includes every file in the build folder:
<fileset dir="${dir.build}">
<include name="**/*" />
</fileset>
changing it to use just class files instead will make it work:
<fileset dir="${dir.build}">
<include name="**/*.class" />
</fileset>
but this brings me to another issue.
Why do we need to output folder in the classpath?
As long as we have the java source in the source path we are fine.
I tried to remove the build/ folder from the build classpath and it was
fine. I tried to start the inline jetty without it, and it was fine.
Could there be other targets that needs the output folder in the classpath?
Magne
--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org
Justin Deoliveira wrote:
Hi Magne,
Hi
It seems to be related to java 5, as Chris pointed out.
It is fine that you might need some files at runtime, but they do not
need to be available at compile time.
Since it is a java 5 issue I understand that it is not high priority, as
the geoserver has not yet made the upgrade.
Magne
I am not 100% sure but I suspect the META-INF folder is included so that
all the plugins in the META-INF/services directed are included on the
classpath. If not, no plugins will get loaded. Probably also the reson
for the **/* instead of **/*.class.
However you are right in that these things dont need be on the classpath
unless you are actually running code (tests).
I am having trouble replicating the problem. Can you tell the exact
sequence of targets to run.
If your modifications still allow all the unit tests to pass, and the
"release" target is not affected, then I dont see a problem with the
change.
Justin
Magne Skjeret wrote:
Hi all
I ask here, as I am not sure this should go in the issues list in jira,
as it is not a issue for most people. Just those who compile on their
own.
I have problems compiling the codebase a second time using ant (1.6.5).
I always need to do a clean before I do a compile.
If not I get a error like this:
all:
[javac] Compiling 2 source files to
D:\projects\subversion\geoserver\build
[javac] error: error reading
D:\projects\subversion\geoserver\build\META-INF\services\org.vfny.geoserver.wfs.FeatureResponseDelegateProducerSpi;
error in opening zip file
[javac] 1 error
This is due to the fact that the META-INF is included into the build
classpath by this:
<path id="path.build">
<path refid="path.lib" />
<fileset dir="${dir.build}">
<include name="**/*" />
</fileset>
<fileset dir="${dir.build}">
<include
name="org/vfny/geoserver/requests/GetCapabilitiesSuite.class" />
</fileset>
</path>
This entry includes every file in the build folder:
<fileset dir="${dir.build}">
<include name="**/*" />
</fileset>
changing it to use just class files instead will make it work:
<fileset dir="${dir.build}">
<include name="**/*.class" />
</fileset>
but this brings me to another issue.
Why do we need to output folder in the classpath?
As long as we have the java source in the source path we are fine.
I tried to remove the build/ folder from the build classpath and it was
fine. I tried to start the inline jetty without it, and it was fine.
Could there be other targets that needs the output folder in the
classpath?
Magne