You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@turbine.apache.org by Jon Scott Stevens <jo...@latchkey.com> on 2002/02/12 21:41:43 UTC
Build processes
Hey guys, what the heck is going on with the build processes right now?
Things are really messed up and it really sucks. I can't easily build
stratum from CVS right now. It doesn't seem to do dependency checking
properly.
Come on...if we want to attract people to helping out with development of
and use of these tools, the build process needs to work...
Having days and days of Gump failures is not acceptable...
On top of it, we still have Sun jar's on the website...turbine/jars/...and
Sam asked them to be removed a long time ago...
What is going on?
-jon
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: tomcat not a good housecat
Posted by Aaron Smuts <aa...@verizon.net>.
The list archive is daunting:
http://w4.metronet.com/~wjm/cgi-bin/eglimpse.cgi/search?title=Tomcat+Arc
hive+search&file_base=%2Fhome%2Fwjm%2Fpublic_html%2Ftomcat&url_base=http
%3A%2F%2Fw4.metronet.com%2F%7Ewjm%2Ftomcat&output_format=standard&case_s
ensitive=no&words_only=yes&misspellings=0&file_pattern=&date_filter=&que
ry=sealing+violation
> -----Original Message-----
> From: Aaron Smuts [mailto:aaron.smuts3@verizon.net]
> Sent: Tuesday, February 12, 2002 11:58 PM
> To: 'Turbine Developers List'
> Subject: tomcat not a good housecat
>
> I get this awful error when trying to embed tomcat. It is kind enough
> to call system.exit() for me.
>
> I'm not sure where to start.? Any suggestions. If you set tomcat to
> true in the remote.cache.ccf and start the remote cache, does anyone
> else get this.
>
> I think it has to do with incompatible parsers or the parser classes
> existing in multiple jars.
>
>
> RemoteGroupCacheServer:tomcatOn = true >main
> FATAL: configuration error
> java.lang.SecurityException: sealing violation
> at
java.net.URLClassLoader.defineClass(URLClassLoader.java:234)
> at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:297)
> at
sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:286)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:253)
> at
java.lang.ClassLoader.loadClassInternal(ClassLoader.java:313)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:120)
> at
> javax.xml.parsers.SAXParserFactory.newInstance(SAXParserFactory.java:
> 117)
> at
> org.apache.tomcat.util.xml.XmlMapper.readXml(XmlMapper.java:210)
> at org.apache.tomcat.startup.Tomcat.execute(Tomcat.java:187)
> at org.apache.tomcat.startup.Tomcat.main(Tomcat.java:235)
> at
> org.apache.stratum.jcs.auxiliary.remote.server.group.RemoteGroupCache
> ServerFactory.startupTomcat(RemoteGroupCacheServerFactory.java:162)
> at
> org.apache.stratum.jcs.auxiliary.remote.server.group.RemoteGroupCache
> ServerFactory.startup(RemoteGroupCacheServerFactory.java:137)
> at
> org.apache.stratum.jcs.auxiliary.remote.server.group.RemoteGroupCache
> ServerFactory.main(RemoteGroupCacheServerFactory.java:347)
>
>
>
> --
> To unsubscribe, e-mail: <mailto:turbine-dev-
> unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:turbine-dev-
> help@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: tomcat not a good housecat
Posted by Jon Scott Stevens <jo...@latchkey.com>.
on 2/12/02 8:57 PM, "Aaron Smuts" <aa...@verizon.net> wrote:
> I get this awful error when trying to embed tomcat. It is kind enough
> to call system.exit() for me.
>
> I'm not sure where to start.? Any suggestions. If you set tomcat to
> true in the remote.cache.ccf and start the remote cache, does anyone
> else get this.
>
> I think it has to do with incompatible parsers or the parser classes
> existing in multiple jars.
My suggestion is that you ask on the tomcat-dev list.
You could also pull down something like EJBoss and look at how it integrates
Tomcat.
Oh yea, sealing violations have historically been related to XML parsers and
the fact that JAXP is sealed.
-jon
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
tomcat not a good housecat
Posted by Aaron Smuts <aa...@verizon.net>.
I get this awful error when trying to embed tomcat. It is kind enough
to call system.exit() for me.
I'm not sure where to start.? Any suggestions. If you set tomcat to
true in the remote.cache.ccf and start the remote cache, does anyone
else get this.
I think it has to do with incompatible parsers or the parser classes
existing in multiple jars.
RemoteGroupCacheServer:tomcatOn = true >main
FATAL: configuration error
java.lang.SecurityException: sealing violation
at java.net.URLClassLoader.defineClass(URLClassLoader.java:234)
at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:297)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:286)
at java.lang.ClassLoader.loadClass(ClassLoader.java:253)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:313)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:120)
at
javax.xml.parsers.SAXParserFactory.newInstance(SAXParserFactory.java:
117)
at
org.apache.tomcat.util.xml.XmlMapper.readXml(XmlMapper.java:210)
at org.apache.tomcat.startup.Tomcat.execute(Tomcat.java:187)
at org.apache.tomcat.startup.Tomcat.main(Tomcat.java:235)
at
org.apache.stratum.jcs.auxiliary.remote.server.group.RemoteGroupCache
ServerFactory.startupTomcat(RemoteGroupCacheServerFactory.java:162)
at
org.apache.stratum.jcs.auxiliary.remote.server.group.RemoteGroupCache
ServerFactory.startup(RemoteGroupCacheServerFactory.java:137)
at
org.apache.stratum.jcs.auxiliary.remote.server.group.RemoteGroupCache
ServerFactory.main(RemoteGroupCacheServerFactory.java:347)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Build processes
Posted by Jason van Zyl <jv...@zenplex.com>.
On 2/12/02 6:44 PM, "Jon Scott Stevens" <jo...@latchkey.com> wrote:
> compile:
> [javac] Compiling 37 source files to
> /Users/jon/checkout/jakarta-turbine-stratum/bin/classes
> [javac]
> [javac] Issued 1 semantic warning compiling
> "/Users/jon/checkout/jakarta-turbine-stratum/src/java/org/apache/stratum/uti
> l/lru/LRUStore.java":
> [javac]
> [javac] 232. catch ( Exception e )
> [javac] <--------->
> [javac] *** Caution: This try block cannot throw a "checked exception"
> (JLS section 14.7) that can be caught here. You may have intended to catch a
> RuntimeException instead of an Exception.
Yes, until Merline is out jikes is the only compiler that is up to spec so
it catches code that isn't up to snuff. I haven't been seeing that because
I've been using javac lately. I guess we could ask Sam to run Gump with
jikes as it's the only compiler up to spec.
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
jvz.
Jason van Zyl
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Build processes
Posted by Jon Scott Stevens <jo...@latchkey.com>.
compile:
[javac] Compiling 37 source files to
/Users/jon/checkout/jakarta-turbine-stratum/bin/classes
[javac]
[javac] Issued 1 semantic warning compiling
"/Users/jon/checkout/jakarta-turbine-stratum/src/java/org/apache/stratum/uti
l/lru/LRUStore.java":
[javac]
[javac] 232. catch ( Exception e )
[javac] <--------->
[javac] *** Caution: This try block cannot throw a "checked exception"
(JLS section 14.7) that can be caught here. You may have intended to catch a
RuntimeException instead of an Exception.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Build processes
Posted by Jason van Zyl <jv...@zenplex.com>.
On 2/12/02 6:24 PM, "Jon Scott Stevens" <jo...@latchkey.com> wrote:
> on 2/12/02 1:18 PM, "Jason van Zyl" <jv...@zenplex.com> wrote:
>
>> All that was required for me was the addition of the xmlrpc jar. I updated
>> the deps.list so all you have to do is update-jars.
>
> Clearly that was something broken, right?
That build didn't work, but I don't think that means the build processes are
broken. By that I mean the methods we're using to build and the ones I want
to move toward.
Sure, it didn't build. I've fixed tons of things like that. Would have taken
you less time to fix it than it would have to complain about it.
>
>> I have received nothing but thanks since the update-jars target went into
>> the build file. If you have specific complaints I will address them, but as
>> far as I know the build process is working and it will be better over the
>> next few days. The work in the rundata_branch is evidence of that.
>
> I'm not running off a branch, I'm running off of head.
I merely suggested looking at it as it prevents problems like what just
happened in Stratum. Adding a jar requires changes in too many places, which
I admit is my doing, and it will be fixed.
>> I take gump warnings with a very huge grain of salt. Gump helps but is still
>> jar from any certain indication that there is actually anything wrong.
>
> Honestly, the fact that Gump is failing is a HUGE error
No it's not, I'm sorry but it's not. Gump has been failing on Stratum
because JGL couldn't be found, and it couldn't be found because Sam removed
it, and Sam removed it because he is publicly nudging us away from products
with licenses that aren't 100% clear. That is not a build problem, that is
Sam's opinion. An opinion I'm not averse to but not willing to move on as
quickly as Gump wants.
Gump is a useful tool, but it is also a public coercion mechanism which Sam
is fully cognizant of. Again, it doesn't bother me but call a spade a spade.
Sometimes the Gump errors are a direct result of what Sam feels we should
do. Everyone jumps to fix stratum and it fucks up all over the place.
Or Aaron takes your suggestion at trying to put in XMLRPC and he typo'd,
it's a simple mistake. The world isn't going end because of it, just fix it
and go about your business.
Just because Gump can't build it doesn't mean the rest of the world can't.
> I'm *still* waiting for Gump to produce javadocs for Turbine3...it has been
> about a month now...
>
> http://nagoya.apache.org/gump/
Time for you to pull out one of those magic shell scripts to do the trick
:-)
>> Other than the JAR available on the website I don't really see anything
>> wrong. I'm not having huge problems I just built stratum after adding xmlrpc
>> and I just built everything else.
>
> As far as I know, the jdbc*ext*.jar is also not supposed to be on there.
Ok, I will update the deps.list files to account for that.
>> Remember the build systems are for building turbine products and will move
>> away from being oriented toward someone trying to build absolutely
>> everything under the sun. If you want to do that then use gump. I agree that
>> the build systems are a bit of a mess but they are working and when I'm
>> finished with some changes in the t3 branch that I'm working it will be much
>> cleaner.
>
> They aren't working, you admit that yourself above...you just had to fix
> something to get it working again...
Yes, I had to fix something.
I think this is a natural process of decoupling, things get messier. I'm
trying to make a single build.xml file that will work for all of our
projects (I actually have it working, it's not vapourware this time) so that
the errors are reduced, building is easy while not having to keep JARs in
CVS and moving toward a build system that we can share with other projects.
I am used to you but do you think you could try to be a tad more supportive.
You of all people are smart enough to fix these little glitches. Maybe you
don't feel you should have to anymore, maybe I should be more diligent with
the build files but the glitches are always going to be there.
> -jon
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
jvz.
Jason van Zyl
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Build processes
Posted by Jon Scott Stevens <jo...@latchkey.com>.
on 2/12/02 1:18 PM, "Jason van Zyl" <jv...@zenplex.com> wrote:
> All that was required for me was the addition of the xmlrpc jar. I updated
> the deps.list so all you have to do is update-jars.
Clearly that was something broken, right?
> I have received nothing but thanks since the update-jars target went into
> the build file. If you have specific complaints I will address them, but as
> far as I know the build process is working and it will be better over the
> next few days. The work in the rundata_branch is evidence of that.
I'm not running off a branch, I'm running off of head.
> I take gump warnings with a very huge grain of salt. Gump helps but is still
> jar from any certain indication that there is actually anything wrong.
Honestly, the fact that Gump is failing is a HUGE error...it should build.
I'm *still* waiting for Gump to produce javadocs for Turbine3...it has been
about a month now...
http://nagoya.apache.org/gump/
> Other than the JAR available on the website I don't really see anything
> wrong. I'm not having huge problems I just built stratum after adding xmlrpc
> and I just built everything else.
As far as I know, the jdbc*ext*.jar is also not supposed to be on there.
> Remember the build systems are for building turbine products and will move
> away from being oriented toward someone trying to build absolutely
> everything under the sun. If you want to do that then use gump. I agree that
> the build systems are a bit of a mess but they are working and when I'm
> finished with some changes in the t3 branch that I'm working it will be much
> cleaner.
They aren't working, you admit that yourself above...you just had to fix
something to get it working again...
-jon
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Build processes
Posted by Jason van Zyl <jv...@zenplex.com>.
On 2/12/02 10:52 PM, "Aaron Smuts" <aa...@verizon.net> wrote:
> Maybe the default build should run update jars. For development we
> could use a dev target if we didn't want to run update jars. This would
> make it easier for people less familiar with the project.
Once all the build files are the same we can decide. I would go for this
provided a property could be set in a local build.properties so this
behaviour could be easily overridden.
> Aaron
>
>> -----Original Message-----
>> From: Jason van Zyl [mailto:jvanzyl@zenplex.com]
>> Sent: Tuesday, February 12, 2002 10:22 PM
>> To: Turbine Developers List
>> Subject: Re: Build processes
>>
>> On 2/12/02 7:27 PM, "Age Mooy" <am...@home.nl> wrote:
>>
>>>
>>> It's working now, thanx.
>>> CVS didn't update the tdk.jar though, so I'm kind of mystified why
> it
>> suddenly
>>> works.
>>
>> It must have been a problem on your side because I actually forgot to
>> update
>> the stratum repository. It's done now to indicate that JAF is not
>> distributable via CVS.
>>
>>> You might want to remove the activation-1.0.1.jar from the stratum
> deps
>>> list... it breaks the update-jars
>>> task.
>>
>> Done. The JAR has been removed, I will also be updating for the JDBC
> jar
>> later on.
>>
>>> Age
>>>
>>>> I assume this is stratum as I see the JGL reference. Have you tried
>> today? I
>>>> update the task which is a little more tolerant.
>>>>
>>>> I have run the update-jars target a couple hundred times now and
> I've
>> only
>>>> had a couple problems which I've fixed. I have only tested this on
> a
>> Linux
>>>> box so if it is a windows thing then I'm not going to find the
> problem.
>>>>
>>>> I can also put some debugging code in and make a switch for it if
>> you're
>>>> still having problems.
>>>>
>>>> If you update the stratum repository now, do you still get the same
>> problem?
>>>
>>>
>>> --
>>> To unsubscribe, e-mail: <mailto:turbine-dev-
>> unsubscribe@jakarta.apache.org>
>>> For additional commands, e-mail: <mailto:turbine-dev-
>> help@jakarta.apache.org>
>>
>> --
>>
>> jvz.
>>
>> Jason van Zyl
>>
>> http://tambora.zenplex.org
>> http://jakarta.apache.org/turbine
>> http://jakarta.apache.org/velocity
>> http://jakarta.apache.org/alexandria
>> http://jakarta.apache.org/commons
>>
>>
>>
>> --
>> To unsubscribe, e-mail: <mailto:turbine-dev-
>> unsubscribe@jakarta.apache.org>
>> For additional commands, e-mail: <mailto:turbine-dev-
>> help@jakarta.apache.org>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
jvz.
Jason van Zyl
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Build processes
Posted by Aaron Smuts <aa...@verizon.net>.
Maybe the default build should run update jars. For development we
could use a dev target if we didn't want to run update jars. This would
make it easier for people less familiar with the project.
Aaron
> -----Original Message-----
> From: Jason van Zyl [mailto:jvanzyl@zenplex.com]
> Sent: Tuesday, February 12, 2002 10:22 PM
> To: Turbine Developers List
> Subject: Re: Build processes
>
> On 2/12/02 7:27 PM, "Age Mooy" <am...@home.nl> wrote:
>
> >
> > It's working now, thanx.
> > CVS didn't update the tdk.jar though, so I'm kind of mystified why
it
> suddenly
> > works.
>
> It must have been a problem on your side because I actually forgot to
> update
> the stratum repository. It's done now to indicate that JAF is not
> distributable via CVS.
>
> > You might want to remove the activation-1.0.1.jar from the stratum
deps
> > list... it breaks the update-jars
> > task.
>
> Done. The JAR has been removed, I will also be updating for the JDBC
jar
> later on.
>
> > Age
> >
> >> I assume this is stratum as I see the JGL reference. Have you tried
> today? I
> >> update the task which is a little more tolerant.
> >>
> >> I have run the update-jars target a couple hundred times now and
I've
> only
> >> had a couple problems which I've fixed. I have only tested this on
a
> Linux
> >> box so if it is a windows thing then I'm not going to find the
problem.
> >>
> >> I can also put some debugging code in and make a switch for it if
> you're
> >> still having problems.
> >>
> >> If you update the stratum repository now, do you still get the same
> problem?
> >
> >
> > --
> > To unsubscribe, e-mail: <mailto:turbine-dev-
> unsubscribe@jakarta.apache.org>
> > For additional commands, e-mail: <mailto:turbine-dev-
> help@jakarta.apache.org>
>
> --
>
> jvz.
>
> Jason van Zyl
>
> http://tambora.zenplex.org
> http://jakarta.apache.org/turbine
> http://jakarta.apache.org/velocity
> http://jakarta.apache.org/alexandria
> http://jakarta.apache.org/commons
>
>
>
> --
> To unsubscribe, e-mail: <mailto:turbine-dev-
> unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:turbine-dev-
> help@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Build processes
Posted by Jason van Zyl <jv...@zenplex.com>.
On 2/12/02 7:27 PM, "Age Mooy" <am...@home.nl> wrote:
>
> It's working now, thanx.
> CVS didn't update the tdk.jar though, so I'm kind of mystified why it suddenly
> works.
It must have been a problem on your side because I actually forgot to update
the stratum repository. It's done now to indicate that JAF is not
distributable via CVS.
> You might want to remove the activation-1.0.1.jar from the stratum deps
> list... it breaks the update-jars
> task.
Done. The JAR has been removed, I will also be updating for the JDBC jar
later on.
> Age
>
>> I assume this is stratum as I see the JGL reference. Have you tried today? I
>> update the task which is a little more tolerant.
>>
>> I have run the update-jars target a couple hundred times now and I've only
>> had a couple problems which I've fixed. I have only tested this on a Linux
>> box so if it is a windows thing then I'm not going to find the problem.
>>
>> I can also put some debugging code in and make a switch for it if you're
>> still having problems.
>>
>> If you update the stratum repository now, do you still get the same problem?
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
jvz.
Jason van Zyl
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Build processes
Posted by Age Mooy <am...@home.nl>.
It's working now, thanx.
CVS didn't update the tdk.jar though, so I'm kind of mystified why it suddenly works.
You might want to remove the activation-1.0.1.jar from the stratum deps list... it breaks the update-jars
task.
Age
> I assume this is stratum as I see the JGL reference. Have you tried today? I
> update the task which is a little more tolerant.
>
> I have run the update-jars target a couple hundred times now and I've only
> had a couple problems which I've fixed. I have only tested this on a Linux
> box so if it is a windows thing then I'm not going to find the problem.
>
> I can also put some debugging code in and make a switch for it if you're
> still having problems.
>
> If you update the stratum repository now, do you still get the same problem?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Build processes
Posted by Jason van Zyl <jv...@zenplex.com>.
On 2/12/02 5:56 PM, "Age Mooy" <am...@home.nl> wrote:
>
>
>> I have received nothing but thanks since the update-jars target went into
>> the build file. If you have specific complaints I will address them, but as
>> far as I know the build process is working and it will be better over the
>> next few days. The work in the rundata_branch is evidence of that.
>
> Well.... I send the below message to this list yesterday and I still don't
> have a clue what's going wrong :(
I assume this is stratum as I see the JGL reference. Have you tried today? I
update the task which is a little more tolerant.
I have run the update-jars target a couple hundred times now and I've only
had a couple problems which I've fixed. I have only tested this on a Linux
box so if it is a windows thing then I'm not going to find the problem.
I can also put some debugging code in and make a switch for it if you're
still having problems.
If you update the stratum repository now, do you still get the same problem?
>
> Hi,
>
> I've tried it time and time again but when I use "ant update-jars" (in
> stratum/torque/turbine-2), it always
> fails with a socket exception, leaving one or more jar files corrupted. Here
> are some output samples:
>
> - with jdk 1.3.1:
> ----------------------
> update-jars:
> ..
> [httpget] Writing E:\src\apache\lib\jgl3.1.0.jar
> [httpget] Error getting null to E:\src\apache\lib\jgl3.1.0.jar
>
> BUILD FAILED
> E:\src\Apache\jakarta-turbine-stratum\build.xml:65: java.net.SocketException:
> JVM_recv in socket input stream
> read (code=10055)
>
> - with jdk 1.4.0 rc
> ----------------------
> update-jars:
> ..
> [httpget] Writing E:\src\apache\lib\jgl3.1.0.jar
> [httpget] Error getting null to E:\src\apache\lib\jgl3.1.0.jar
>
> BUILD FAILED
> E:\src\Apache\jakarta-turbine-stratum\build.xml:65: java.net.SocketException:
> No buffer space available
> (maximum connections reached?): JVM_recv in socket input stream read
>
> The jdk 1.4 output seems to indicate too many connections but that doesn't
> sound very likely to me.
>
> Anyone have any idea what is gong wrong ?
>
> Age
>
> PS
> I run win2k server, if that means anything.
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
jvz.
Jason van Zyl
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Build processes
Posted by Age Mooy <am...@home.nl>.
> I have received nothing but thanks since the update-jars target went into
> the build file. If you have specific complaints I will address them, but as
> far as I know the build process is working and it will be better over the
> next few days. The work in the rundata_branch is evidence of that.
Well.... I send the below message to this list yesterday and I still don't have a clue what's going wrong :(
Hi,
I've tried it time and time again but when I use "ant update-jars" (in stratum/torque/turbine-2), it always
fails with a socket exception, leaving one or more jar files corrupted. Here are some output samples:
- with jdk 1.3.1:
----------------------
update-jars:
..
[httpget] Writing E:\src\apache\lib\jgl3.1.0.jar
[httpget] Error getting null to E:\src\apache\lib\jgl3.1.0.jar
BUILD FAILED
E:\src\Apache\jakarta-turbine-stratum\build.xml:65: java.net.SocketException: JVM_recv in socket input stream
read (code=10055)
- with jdk 1.4.0 rc
----------------------
update-jars:
..
[httpget] Writing E:\src\apache\lib\jgl3.1.0.jar
[httpget] Error getting null to E:\src\apache\lib\jgl3.1.0.jar
BUILD FAILED
E:\src\Apache\jakarta-turbine-stratum\build.xml:65: java.net.SocketException: No buffer space available
(maximum connections reached?): JVM_recv in socket input stream read
The jdk 1.4 output seems to indicate too many connections but that doesn't sound very likely to me.
Anyone have any idea what is gong wrong ?
Age
PS
I run win2k server, if that means anything.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Build processes
Posted by Jason van Zyl <jv...@zenplex.com>.
On 2/12/02 3:41 PM, "Jon Scott Stevens" <jo...@latchkey.com> wrote:
> Hey guys, what the heck is going on with the build processes right now?
If you look in the rundata_changes branch you'll see what I'm working on and
I'm going to clean up all the builds in one shot. But I'm not having any
particular problems building anything.
> Things are really messed up and it really sucks. I can't easily build
> stratum from CVS right now. It doesn't seem to do dependency checking
> properly.
All that was required for me was the addition of the xmlrpc jar. I updated
the deps.list so all you have to do is update-jars.
> Come on...if we want to attract people to helping out with development of
> and use of these tools, the build process needs to work...
I have received nothing but thanks since the update-jars target went into
the build file. If you have specific complaints I will address them, but as
far as I know the build process is working and it will be better over the
next few days. The work in the rundata_branch is evidence of that.
> Having days and days of Gump failures is not acceptable...
I take gump warnings with a very huge grain of salt. Gump helps but is still
jar from any certain indication that there is actually anything wrong.
> On top of it, we still have Sun jar's on the website...turbine/jars/...and
> Sam asked them to be removed a long time ago...
>
> What is going on?
Other than the JAR available on the website I don't really see anything
wrong. I'm not having huge problems I just built stratum after adding xmlrpc
and I just built everything else.
Remember the build systems are for building turbine products and will move
away from being oriented toward someone trying to build absolutely
everything under the sun. If you want to do that then use gump. I agree that
the build systems are a bit of a mess but they are working and when I'm
finished with some changes in the t3 branch that I'm working it will be much
cleaner.
> -jon
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
jvz.
Jason van Zyl
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>