You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-dev@portals.apache.org by Raphaël Luta <ra...@networks.groupvu.com> on 2001/06/05 18:47:51 UTC
Branching for release
This is a message for all committers:
I'm ready to branch the CVS tree for the 1.3a2 release, please let me know
if it's OK for you ASAP.
I'll postpone the branch to tomorrow morning (French time) if I don't get any
acknowledgement in time today...
--
Raphael Luta - raphael.luta@networks.groupvu.com
Vivendi Universal Networks - Paris
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: Branching for release
Posted by Raphaël Luta <ra...@networks.groupvu.com>.
David Sean Taylor wrote:
>
> I'd prefer if you waited til tomorrow.
>
> I still haven't tried it out your latest commits, nor have I had a chance to
> resolve the JSP issues. Is it working for you now?
>
> This damn network card on my development machine is broken, and I really
> have to leave now...I will be back tonight
>
OK. Tomorrow near 12:00 GMT.
--
Raphael Luta - raphael.luta@networks.groupvu.com
Vivendi Universal Networks - Paris
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
RE: Branching for release
Posted by David Sean Taylor <da...@bluesunrise.com>.
I'd prefer if you waited til tomorrow.
I still haven't tried it out your latest commits, nor have I had a chance to
resolve the JSP issues. Is it working for you now?
This damn network card on my development machine is broken, and I really
have to leave now...I will be back tonight
-------------------------------------
David Sean Taylor
taylor@apache.org
-------------------------------------
http://jakarta.apache.org/jetspeed
-------------------------------------
> -----Original Message-----
> From: Raphael Luta [mailto:raphael.luta@networks.groupvu.com]
> Sent: Tuesday, June 05, 2001 9:48 AM
> To: jetspeed-dev@jakarta.apache.org
> Subject: Branching for release
>
>
> This is a message for all committers:
>
> I'm ready to branch the CVS tree for the 1.3a2 release,
> please let me know
> if it's OK for you ASAP.
>
> I'll postpone the branch to tomorrow morning (French time) if
> I don't get any
> acknowledgement in time today...
>
> --
> Raphael Luta - raphael.luta@networks.groupvu.com
> Vivendi Universal Networks - Paris
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: Branching for release
Posted by ra...@networks.groupvu.com.
David Sean Taylor wrote:
>
> Im experiencing problems with the latest cvs head.
> In summary, I fail to even get the home page with Catalina and Resin.
> With Tomcat, I get the homepage but the NewRSSPortlet is failing.
> See details below...
>
ABout the Catalina failure, I've found and fixed the bug (related to the
PSML loading). I'll commit the patch in a few minutes along with a patch
for using the JSP and/or the Velocity files independently (not perfect,
though)
The main problem that will remain is to clean up all the actions and the
URILookup class so that they don't reference anymore the screen Home but
rather the default template...
I don't experience any issue with the NewRSS or JetspeedContent portlet, did
you try with a completely fresh CVS checkout ?
> Im not having any problems with log4j, it appears to be logging our errors,
> but I will make sure that we use the same version of the jar as turbine.
>
While you're doing this can you also update the Turbine and Velocity to the one
found in the TDK 2.1 release ?
> WRT to the classes directory, I prefer it that way over having a
> jetspeed.jar. Its better for incremental development.
> I usually change my build to write its output to the WEB-INF/classes
> directory when developing.
>
I agree for development, for the release binary I think we should have a jetspeed.war
though, much tidier...
--
Raphaël Luta - luta.raphael@networks.vivendi.net
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: Branching for release
Posted by Santiago Gala <sg...@hisitech.com>.
David Sean Taylor wrote:
> Im experiencing problems with the latest cvs head.
> In summary, I fail to even get the home page with Catalina and Resin.
> With Tomcat, I get the homepage but the NewRSSPortlet is failing.
> See details below...
>
> My network card just quit working on my development machine at home.
> (Jason, what did you do, man!)
> I hope to be back online tonight (pst) with a new network card, and to make
> some commits.
>
This is the Spring coming (thermal and emotional stress for your
computer :-) ). All the computers I know fail during Spring and Fall. My
dual processor is currently a single processor, because the Motherboard
started failing with two processor when the temperatures went up, a
couple of weeks ago. I'm failing too :)))))
> Im not having any problems with log4j, it appears to be logging our errors,
> but I will make sure that we use the same version of the jar as turbine.
>
I think it is because you have a modern log4j in the classpath, so the
one in the war is not used.
> WRT to the classes directory, I prefer it that way over having a
> jetspeed.jar. Its better for incremental development.
> I usually change my build to write its output to the WEB-INF/classes
> directory when developing.
>
Good to know. I had problems when I modified classes, because they got
modified in the jetspeed.jar, and the ones in classes were used instead.
So I had to keep expanding the war every time.
> ----------------------------------------
> Here is the problem with Tomcat 3.2:
> ----------------------------------------
The error below is due to a xerces, crimson, parser.jar or xalan.jar
that is incompatible with the one in Jetspeed. Move the one in jetspeed
to the tomcat/lib (or remove it from wherever it is in the classpath)
and try again. If it does not support namespaces it should be a very old
parser. The JAXP processor is taking this one. I use to replace the
parser.jar in tomcat/lib by the most current xerces in my webapps.
Also, it could be due to the TRAX properties definition. It could be
hidden in the configuration of something you have around. Look for xalan
(or other TRAX processor) in the jdk/jre/lib/ext directory
I will look for a more robust way to make it work.
> Exception: org.xml.sax.SAXException: problem in SAX transform:
> javax.xml.transform.TransformerException: Namespace not supported by
> SAXParser
> Stack Trace follows:
> org.xml.sax.SAXException: problem in SAX transform:
> javax.xml.transform.TransformerException: Namespace not supported by
> SAXParser
> at
> org.apache.jetspeed.util.SimpleTransform.transform(SimpleTransform.java:387)
> at
> org.apache.jetspeed.util.SimpleTransform.transform(SimpleTransform.java:294)
> at
> org.apache.jetspeed.util.SimpleTransform.transform(SimpleTransform.java:258)
> at
> org.apache.jetspeed.portal.portlets.JetspeedContent.parse(JetspeedContent.ja
> va:189)
> at
> org.apache.jetspeed.portal.portlets.JetspeedContent.init(JetspeedContent.jav
> a:142)
> at
> org.apache.jetspeed.services.portletfactory.JetspeedPortletFactoryService.ge
> tPortlet(JetspeedPortletFactoryService.java:299)
> at
> org.apache.jetspeed.services.portletfactory.JetspeedPortletFactoryService.ge
> tPortlet(JetspeedPortletFactoryService.java:141)
> at
> org.apache.jetspeed.services.PortletFactory.getPortlet(PortletFactory.java:9
> 2)
> at
> org.apache.jetspeed.services.portaltoolkit.JetspeedPortalToolkitService.getS
> et(JetspeedPortalToolkitService.java:390)
> at
> org.apache.jetspeed.services.portaltoolkit.JetspeedPortalToolkitService.getS
> et(JetspeedPortalToolkitService.java:373)
> at
> org.apache.jetspeed.services.portaltoolkit.JetspeedPortalToolkitService.getS
> et(JetspeedPortalToolkitService.java:373)
> at
> org.apache.jetspeed.services.PortalToolkit.getSet(PortalToolkit.java:165)
> at
> org.apache.jetspeed.om.profile.BaseProfile.getRootSet(BaseProfile.java:116)
> at
> org.apache.jetspeed.util.template.JetspeedTool.getPane(JetspeedTool.java:139
> )
> at java.lang.reflect.Method.invoke(Native Method)
> at
> org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:245
> )
> at
> org.apache.velocity.runtime.parser.node.ASTReference.execute(ASTReference.ja
> va:171)
> at
> org.apache.velocity.runtime.parser.node.ASTReference.render(ASTReference.jav
> a:207)
> at
> org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:25
> 9)
> at org.apache.velocity.Template.merge(Template.java:283)
> at org.apache.velocity.app.Velocity.mergeTemplate(Velocity.java:441)
> at
> org.apache.turbine.services.velocity.TurbineVelocityService.decodeRequest(Tu
> rbineVelocityService.java:352)
> at
> org.apache.turbine.services.velocity.TurbineVelocityService.handleRequest(Tu
> rbineVelocityService.java:247)
> at
> org.apache.turbine.services.velocity.TurbineVelocity.handleRequest(TurbineVe
> locity.java:109)
> at
> org.apache.turbine.modules.screens.VelocityScreen.buildTemplate(VelocityScre
> en.java:151)
> at
> org.apache.turbine.modules.screens.TemplateScreen.doBuild(TemplateScreen.jav
> a:130)
> at org.apache.turbine.modules.Screen.build(Screen.java:99)
> at org.apache.turbine.modules.ScreenLoader.eval(ScreenLoader.java:129)
> at
> org.apache.turbine.modules.layouts.VelocityOnlyLayout.doBuild(VelocityOnlyLa
> yout.java:98)
> at org.apache.turbine.modules.Layout.build(Layout.java:91)
> at org.apache.turbine.modules.LayoutLoader.exec(LayoutLoader.java:123)
> at
> org.apache.turbine.modules.pages.DefaultPage.doBuild(DefaultPage.java:166)
> at org.apache.turbine.modules.Page.build(Page.java:90)
> at org.apache.turbine.modules.PageLoader.exec(PageLoader.java:123)
> at org.apache.turbine.Turbine.doGet(Turbine.java:447)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
> at org.apache.tomcat.core.ServletWrapper.doService(ServletWrapper.java:405)
> at org.apache.tomcat.core.Handler.service(Handler.java:287)
> at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372)
> at
> org.apache.tomcat.facade.RequestDispatcherImpl.doForward(RequestDispatcherIm
> pl.java:222)
> at
> org.apache.tomcat.facade.RequestDispatcherImpl.forward(RequestDispatcherImpl
> .java:162)
> at
> org.apache.jasper.runtime.PageContextImpl.forward(PageContextImpl.java:421)
> at
> _0002findex_0002ejspindex_jsp_0._jspService(_0002findex_0002ejspindex_jsp_0.
> java:59)
> at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:119)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
> at
> org.apache.jasper.servlet.JspServlet$JspCountedServlet.service(JspServlet.ja
> va:130)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
> at
> org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.ja
> va:282)
> at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:429)
> at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:500)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
> at org.apache.tomcat.core.ServletWrapper.doService(ServletWrapper.java:405)
> at org.apache.tomcat.core.Handler.service(Handler.java:287)
> at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372)
> at
> org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:79
> 7)
> at org.apache.tomcat.core.ContextManager.service(ContextManager.java:743)
> at
> org.apache.tomcat.service.http.HttpConnectionHandler.processConnection(HttpC
> onnectionHandler.java:213)
> at
> org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:416)
> at
> org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java:501)
> at java.lang.Thread.run(Thread.java:484)
>
> ----------------------------------------------
> Here is the problem in both Catalina and Resin:
> ----------------------------------------------
>
> [Tue Jun 05 22:20:39 PDT 2001] -- ERROR -- Error rendering Velocity
> template: screens/html/Home.vm: Invocation of method 'getPane' in class
> org.apache.jetspeed.util.template.JetspeedTool threw exception class
> java.lang.NullPointerException
>
I get a similar NPE with tomcat 3.2 in the turbine user, when I click
the RSS pane. I don't know if it is related.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: Branching for release
Posted by David Sean Taylor <da...@bluesunrise.com>.
Im experiencing problems with the latest cvs head.
In summary, I fail to even get the home page with Catalina and Resin.
With Tomcat, I get the homepage but the NewRSSPortlet is failing.
See details below...
My network card just quit working on my development machine at home.
(Jason, what did you do, man!)
I hope to be back online tonight (pst) with a new network card, and to make
some commits.
Im not having any problems with log4j, it appears to be logging our errors,
but I will make sure that we use the same version of the jar as turbine.
WRT to the classes directory, I prefer it that way over having a
jetspeed.jar. Its better for incremental development.
I usually change my build to write its output to the WEB-INF/classes
directory when developing.
----------------------------------------
Here is the problem with Tomcat 3.2:
----------------------------------------
Exception: org.xml.sax.SAXException: problem in SAX transform:
javax.xml.transform.TransformerException: Namespace not supported by
SAXParser
Stack Trace follows:
org.xml.sax.SAXException: problem in SAX transform:
javax.xml.transform.TransformerException: Namespace not supported by
SAXParser
at
org.apache.jetspeed.util.SimpleTransform.transform(SimpleTransform.java:387)
at
org.apache.jetspeed.util.SimpleTransform.transform(SimpleTransform.java:294)
at
org.apache.jetspeed.util.SimpleTransform.transform(SimpleTransform.java:258)
at
org.apache.jetspeed.portal.portlets.JetspeedContent.parse(JetspeedContent.ja
va:189)
at
org.apache.jetspeed.portal.portlets.JetspeedContent.init(JetspeedContent.jav
a:142)
at
org.apache.jetspeed.services.portletfactory.JetspeedPortletFactoryService.ge
tPortlet(JetspeedPortletFactoryService.java:299)
at
org.apache.jetspeed.services.portletfactory.JetspeedPortletFactoryService.ge
tPortlet(JetspeedPortletFactoryService.java:141)
at
org.apache.jetspeed.services.PortletFactory.getPortlet(PortletFactory.java:9
2)
at
org.apache.jetspeed.services.portaltoolkit.JetspeedPortalToolkitService.getS
et(JetspeedPortalToolkitService.java:390)
at
org.apache.jetspeed.services.portaltoolkit.JetspeedPortalToolkitService.getS
et(JetspeedPortalToolkitService.java:373)
at
org.apache.jetspeed.services.portaltoolkit.JetspeedPortalToolkitService.getS
et(JetspeedPortalToolkitService.java:373)
at
org.apache.jetspeed.services.PortalToolkit.getSet(PortalToolkit.java:165)
at
org.apache.jetspeed.om.profile.BaseProfile.getRootSet(BaseProfile.java:116)
at
org.apache.jetspeed.util.template.JetspeedTool.getPane(JetspeedTool.java:139
)
at java.lang.reflect.Method.invoke(Native Method)
at
org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:245
)
at
org.apache.velocity.runtime.parser.node.ASTReference.execute(ASTReference.ja
va:171)
at
org.apache.velocity.runtime.parser.node.ASTReference.render(ASTReference.jav
a:207)
at
org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:25
9)
at org.apache.velocity.Template.merge(Template.java:283)
at org.apache.velocity.app.Velocity.mergeTemplate(Velocity.java:441)
at
org.apache.turbine.services.velocity.TurbineVelocityService.decodeRequest(Tu
rbineVelocityService.java:352)
at
org.apache.turbine.services.velocity.TurbineVelocityService.handleRequest(Tu
rbineVelocityService.java:247)
at
org.apache.turbine.services.velocity.TurbineVelocity.handleRequest(TurbineVe
locity.java:109)
at
org.apache.turbine.modules.screens.VelocityScreen.buildTemplate(VelocityScre
en.java:151)
at
org.apache.turbine.modules.screens.TemplateScreen.doBuild(TemplateScreen.jav
a:130)
at org.apache.turbine.modules.Screen.build(Screen.java:99)
at org.apache.turbine.modules.ScreenLoader.eval(ScreenLoader.java:129)
at
org.apache.turbine.modules.layouts.VelocityOnlyLayout.doBuild(VelocityOnlyLa
yout.java:98)
at org.apache.turbine.modules.Layout.build(Layout.java:91)
at org.apache.turbine.modules.LayoutLoader.exec(LayoutLoader.java:123)
at
org.apache.turbine.modules.pages.DefaultPage.doBuild(DefaultPage.java:166)
at org.apache.turbine.modules.Page.build(Page.java:90)
at org.apache.turbine.modules.PageLoader.exec(PageLoader.java:123)
at org.apache.turbine.Turbine.doGet(Turbine.java:447)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at org.apache.tomcat.core.ServletWrapper.doService(ServletWrapper.java:405)
at org.apache.tomcat.core.Handler.service(Handler.java:287)
at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372)
at
org.apache.tomcat.facade.RequestDispatcherImpl.doForward(RequestDispatcherIm
pl.java:222)
at
org.apache.tomcat.facade.RequestDispatcherImpl.forward(RequestDispatcherImpl
.java:162)
at
org.apache.jasper.runtime.PageContextImpl.forward(PageContextImpl.java:421)
at
_0002findex_0002ejspindex_jsp_0._jspService(_0002findex_0002ejspindex_jsp_0.
java:59)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:119)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.jasper.servlet.JspServlet$JspCountedServlet.service(JspServlet.ja
va:130)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.ja
va:282)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:429)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:500)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at org.apache.tomcat.core.ServletWrapper.doService(ServletWrapper.java:405)
at org.apache.tomcat.core.Handler.service(Handler.java:287)
at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372)
at
org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:79
7)
at org.apache.tomcat.core.ContextManager.service(ContextManager.java:743)
at
org.apache.tomcat.service.http.HttpConnectionHandler.processConnection(HttpC
onnectionHandler.java:213)
at
org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:416)
at
org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java:501)
at java.lang.Thread.run(Thread.java:484)
----------------------------------------------
Here is the problem in both Catalina and Resin:
----------------------------------------------
[Tue Jun 05 22:20:39 PDT 2001] -- ERROR -- Error rendering Velocity
template: screens/html/Home.vm: Invocation of method 'getPane' in class
org.apache.jetspeed.util.template.JetspeedTool threw exception class
java.lang.NullPointerException
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: Problem with log4java (was: Branching for release)
Posted by Johnny Cass <jo...@epiuse.com>.
Santiago Gala wrote:
>
> Johnny Cass wrote:
>
> > Santiago Gala wrote:
> >
> >>
> >>Also, I'm seeing funny things with current CVS.
> >>
> >>- jetspeed.jar is not in the war, at least not in WEB-INF/lib ???
> >>
> >
> > The current build system does not add jetspeed.jar to the war. Instead,
> > the jetspeed classes are compiled into the 'classes' directory which
> > *is* distributed with the war. As far as I know, the net effect should
> > be the same (both are added to the classpath of the webapp).
> >
>
> OK. Since I had two errors mixed up, I will try without jetspeed.jar to
> see if/how it works.
>
> The problem I see with this setup is that we can no longer build and
> then move the jetspeed.jar to the tomcat directory.
The 'jar' target creates a jetspeed.jar. So, you could use 'war' to
create the webapp, copy this to ${tomcat.home}/webapps, run tomcat to
expand the war, delete the 'classes' directory, and then copy the
jetspeed.jar created by target 'jar' into WEB-INF/lib on subsequent
builds. Alternatively, you could simply replace the classes directory
for the jetspeed webapp in tomcat with the one under
${jetspeed.cvs.root}/bin/classes.
Having said this, I must admit that it sounds like way too much trouble.
I usually use soft links to accomplish the same effect.
> How do you manage
> incremental builds? Do we have a target where we can specify a webapp
> target directory for ant to copy the compiled files (and maybe content)
> there, w/o building and expanding the war under tomcat?
>
I usually set a soft link from ${jetspeed.cvs.root}/webapp to
${tomcat.home}/webapps/jetspeed and one from
${jetspeed.cvs.root}/bin/classes to
${jetspeed.cvs.root}/webapp/WEB-INF/classes. So, in effect, I am running
Jetspeed direct from my CVS repository. I'm sure somebody can educate me
on the perils of this approach! ;).
> Expanding the war destroys any permanent changes done by customization,
> the cache, etc.
>
I'm open for suggestions, it doesn't really make a difference either
way. We will need to have a 'classes' directory regardless of the
approach taken since the 'cactus.properties' file needs to be in the
webapp's classpath.
- Johnny
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Problem with log4java (was: Branching for release)
Posted by Santiago Gala <sg...@hisitech.com>.
Johnny Cass wrote:
> Santiago Gala wrote:
>
>>
>>Also, I'm seeing funny things with current CVS.
>>
>>- jetspeed.jar is not in the war, at least not in WEB-INF/lib ???
>>
>
> The current build system does not add jetspeed.jar to the war. Instead,
> the jetspeed classes are compiled into the 'classes' directory which
> *is* distributed with the war. As far as I know, the net effect should
> be the same (both are added to the classpath of the webapp).
>
OK. Since I had two errors mixed up, I will try without jetspeed.jar to
see if/how it works.
The problem I see with this setup is that we can no longer build and
then move the jetspeed.jar to the tomcat directory. How do you manage
incremental builds? Do we have a target where we can specify a webapp
target directory for ant to copy the compiled files (and maybe content)
there, w/o building and expanding the war under tomcat?
Expanding the war destroys any permanent changes done by customization,
the cache, etc.
>
>>- I get a catastrophic error about log4java (seems like updating
>>turbine.jar is not enough).
>>
>>After I added the jetspeed.jar to the webapp and changed the log4java
>>1.0.4 files by log4java 1.1 (coming from Turbine HEAD), it seems to work
>>again.
>>
>>
>
> Hmmm...not sure why this is happening, anybody else having the same
> problem?
>
The cause is probably this: David changed turbine.jar, to prepare for
the turbine release. Possibly he forgot to switch log4java versions:
> taylor 01/06/04 00:08:51
>
> Added: lib turbine-2.2-dev.jar velocity-1.0.jar
> Removed: lib turbine-TDKa13.jar velocity-1.0b2-dev.jar
> Log:
> upgraded to TDK 2.2
>
> Revision Changes Path
> 1.1 jakarta-jetspeed/lib/turbine-2.2-dev.jar
>
> <<Binary file>>
> 1.1 jakarta-jetspeed/lib/velocity-1.0.jar
>
> <<Binary file>>
>
I will not commit the change until David does it, or else says there is
a reason for not doing it (or tells me please do it :-) ). It should be
noticed for cvs checkouts after June 4th. If nobody removed the
webapps/jetspeed directory, to have the war expanded, you will still run
with the old turbine and velocity jars.
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: Branching for release
Posted by Johnny Cass <jo...@epiuse.com>.
Santiago Gala wrote:
>
>
> Also, I'm seeing funny things with current CVS.
>
> - jetspeed.jar is not in the war, at least not in WEB-INF/lib ???
The current build system does not add jetspeed.jar to the war. Instead,
the jetspeed classes are compiled into the 'classes' directory which
*is* distributed with the war. As far as I know, the net effect should
be the same (both are added to the classpath of the webapp).
> - I get a catastrophic error about log4java (seems like updating
> turbine.jar is not enough).
>
> After I added the jetspeed.jar to the webapp and changed the log4java
> 1.0.4 files by log4java 1.1 (coming from Turbine HEAD), it seems to work
> again.
>
Hmmm...not sure why this is happening, anybody else having the same
problem?
-Johnny.
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: Branching for release
Posted by Santiago Gala <sg...@hisitech.com>.
Raphaël Luta wrote:
>
> Jon Stevens wrote:
>
>>Why are you doing branches on alpha releases?
>>
>>Branches are for parallel forms of development. Since this is just an
>>alpha release, no branch is necessary.
>>
>>
>
> The idea is to have a stable work area for stabilization while new features
> get added to the main trunk, but I admit that considering the amount of committers
> currently active, I may as well not bother and just tag the CVS for each release
> candidate 8/
>
We could keep current work in HEAD, and have the new Portlet API
integration in the current portlet_api branch.
Also, I'm seeing funny things with current CVS.
- jetspeed.jar is not in the war, at least not in WEB-INF/lib ???
- I get a catastrophic error about log4java (seems like updating
turbine.jar is not enough).
After I added the jetspeed.jar to the webapp and changed the log4java
1.0.4 files by log4java 1.1 (coming from Turbine HEAD), it seems to work
again.
It seems that the build process forgets to add it to the war.
Just beginning to test the fresh war.
> --
> Raphael Luta - raphael.luta@networks.groupvu.com
> Vivendi Universal Networks - Paris
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: Branching for release
Posted by Jon Stevens <jo...@latchkey.com>.
on 6/6/01 12:53 PM, "raphael.luta@networks.groupvu.com"
<ra...@networks.groupvu.com> wrote:
> I was talking about a *alpha* release candidate. Jetspeed has to stay alpha
> currently
> since we know we're going to change some APIs
Just make alpha *releases*. You don't need a "alpha release candidate".
-jon
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: Branching for release
Posted by ra...@networks.groupvu.com.
Jon Stevens wrote:
>
> on 6/6/01 12:48 AM, "Raphaël Luta" <ra...@networks.groupvu.com>
> wrote:
>
> >, but I admit that considering the amount of
> > committers
> > currently active, I may as well not bother and just tag the CVS for each
> > release
> > candidate 8/
>
> Wait...why are you naming things 1.3aX if it is a release candidate? If it
> is a release candidate, it should be 1.3-rcX
>
I was talking about a *alpha* release candidate. Jetspeed has to stay alpha currently
since we know we're going to change some APIs
--
Raphaël Luta - luta.raphael@networks.vivendi.net
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: Branching for release
Posted by Jon Stevens <jo...@latchkey.com>.
on 6/6/01 12:48 AM, "Raphaël Luta" <ra...@networks.groupvu.com>
wrote:
>
>
> Jon Stevens wrote:
>>
>> Why are you doing branches on alpha releases?
>>
>> Branches are for parallel forms of development. Since this is just an
>> alpha release, no branch is necessary.
>>
>
> The idea is to have a stable work area for stabilization while new features
> get added to the main trunk
I'm sorry, that doesn't make any sense with regards to standard software
development. Alpha releases are based on HEAD. You don't do branches on
alpha's.
>, but I admit that considering the amount of
> committers
> currently active, I may as well not bother and just tag the CVS for each
> release
> candidate 8/
Wait...why are you naming things 1.3aX if it is a release candidate? If it
is a release candidate, it should be 1.3-rcX
-jon
--
"Open source is not available to commercial companies."
-Steve Balmer, CEO Microsoft
<http://www.suntimes.com/output/tech/cst-fin-micro01.html>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: Branching for release
Posted by Raphaël Luta <ra...@networks.groupvu.com>.
Jon Stevens wrote:
>
> Why are you doing branches on alpha releases?
>
> Branches are for parallel forms of development. Since this is just an
> alpha release, no branch is necessary.
>
The idea is to have a stable work area for stabilization while new features
get added to the main trunk, but I admit that considering the amount of committers
currently active, I may as well not bother and just tag the CVS for each release
candidate 8/
--
Raphael Luta - raphael.luta@networks.groupvu.com
Vivendi Universal Networks - Paris
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: Branching for release
Posted by Jon Stevens <jo...@latchkey.com>.
Why are you doing branches on alpha releases?
Branches are for parallel forms of development. Since this is just an
alpha release, no branch is necessary.
-jon
On Tue, 5 Jun 2001, [iso-8859-1] Rapha�l Luta wrote:
> This is a message for all committers:
>
> I'm ready to branch the CVS tree for the 1.3a2 release, please let me know
> if it's OK for you ASAP.
>
> I'll postpone the branch to tomorrow morning (French time) if I don't get any
> acknowledgement in time today...
>
> --
> Raphael Luta - raphael.luta@networks.groupvu.com
> Vivendi Universal Networks - Paris
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org