Re: Releasing from trunk
Simone Gianni wrote:
Reinhard Poetz wrote:
I've been working on the release for the past couple of hours. As it's
late here, I need some sleep. Unfortunatly this means that the trunk
is broken ATM. I will continue later today and fix all poms.
Sorry for any inconveniences.
Just a quick question. Why don't we use version ranges instead of fixed
version numbers in our internal pom dependencies?
While using a version range on an external dependency can be dangerous
'cause we are not sure they will respect versioning rules, we could use
them for internal dependencies and save a lot of work when the version
of a single component changes and avoid having to cleanup the
repository, rebuild everything, change the version in the pom, re-clean
the repository and so on. Also because when we will have "1.0.0" version
of a block published on public repository it will be a real pain to
debug which components are still pointing to instead than to the new
1.0.1 version.
Is there some hidden problem with version ranges?
Simone, I have to admit that I don't understand the problem that will be solved
by version ranges.
Let's assume that you use cocoon-forms-1.0.0.jar which has a dependency on
cocoon-core-2.2.0.jar. After a while we release cocoon-core-2.2.1.jar. If you
upgrade your own project descriptor to the new version, Maven will use this
instead of the version set in cocoon-forms.
What would be different with version ranges?
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: Releasing from trunk
Vadim Gritsenko wrote:
Reinhard Poetz wrote:
The build runs through again, at least for me. I tested with an
empty local repository. Could others please verify?
Consistently fails with
---
T E S T S
---
Running org.apache.cocoon.portal.event.impl.DefaultEventManagerTestCase
log4j:WARN No appenders could be found for logger
(org.springframework.core.CollectionFactory).
log4j:WARN Please initialize the log4j system properly.
[DEBUG] XMLizer: Default parser is
'org.apache.excalibur.xml.sax.SAXParser'.
[DEBUG] XMLizer: Default parser is
'org.apache.excalibur.xml.sax.SAXParser'.
[DEBUG] XMLizer: Default parser is
'org.apache.excalibur.xml.sax.SAXParser'.
[DEBUG] XMLizer: Default parser is
'org.apache.excalibur.xml.sax.SAXParser'.
[DEBUG] XMLizer: Default parser is
'org.apache.excalibur.xml.sax.SAXParser'.
[DEBUG] XMLizer: Default parser is
'org.apache.excalibur.xml.sax.SAXParser'.
[DEBUG] XMLizer: Default parser is
'org.apache.excalibur.xml.sax.SAXParser'.
Tests run: 7, Failures: 0, Errors: 7, Skipped: 0, Time elapsed: 0.6 sec
<<< FAILURE!
Strange :-(
Can you run the tests from within your IDE and find out what exactly is failing?
Do others see this behaviour too?
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: [VOTE] new excalibur release
Leo Simons wrote:
Hey Jorg,
w00t! Good goings! This has been a lng process :-)
On Feb 14, 2007, at 6:46 PM, Jorg Heymans wrote:
The new release of excalibur is long overdue, but finally here it is :
http://people.apache.org/~jheymans/excalibur-release.tar.bz2
Thanks Jorg!
One question: I would like to use the new artifacts with Cocoon trunk. Does some
staging Maven repository containing the new artifacts exist that could be used
for this purpose?
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: [VOTE] new excalibur release
Hey Jorg, w00t! Good goings! This has been a lng process :-) On Feb 14, 2007, at 6:46 PM, Jorg Heymans wrote: The new release of excalibur is long overdue, but finally here it is : http://people.apache.org/~jheymans/excalibur-release.tar.bz2 ... Also-1: i have provided the release binaries in maven layout. Should we provided other packagings ? While I can see how we can live with mostly just having these .jar releases these days (as weird as this maven 2 thing still feels to me, when I learned release management, installing javadocs offline was still important :-)), I do thing we should provide *some* sort of source release. Even if its just cd excalibur/trunk/buildsystem cat > release-r50771.sh <svn export -r 507711 http://svn.apache.org/repos/asf/excalibur/tags/ maven2-release-working-tag excalibur-r507711-20070214 tar cjf excalibur-r50771-20070214.tar.bz2 excalibur-r507711-20070214 md5sum -b excalibur-r50771-20070214.tar.bz2 > excalibur- r50771-20070214.tar.bz2.md5 echo gpg --armor --output excalibur-r50771-20070214.tar.bz2.asc -- detach-sig excalibur-r50771-20070214.tar.bz2 echo scp excalibur-r50771-20070214.tar.bz2 people.apache.org:/www/ www.apache.org/dist/excalibur/ END svn add release-r50771.sh svn commit release-r50771.sh "Release script for excalibur- r50771-20070214.tar.bz2" ./release-r50771.sh gpg --armor --output excalibur-r50771-20070214.tar.bz2.asc --detach- sig excalibur-r50771-20070214.tar.bz2 scp excalibur-r50771-20070214.tar.bz2 people.apache.org:/www/ www.apache.org/dist/excalibur/ (just made this up on the spot; not tested). Does that make sense to you? Please cast your votes. +1 from me. On the release notes... Here's two jira shared filters y'all should be able to see: https://issues.apache.org/jira/secure/IssueNavigator.jspa? mode=hide&requestId=12311589 https://issues.apache.org/jira/secure/IssueNavigator.jspa? mode=hide&requestId=12311590 there just isn't much there; I wouldn't bother with making release notes out of them. Instead, below is me spitting through two years of our SVN logs... cheers! - Leo Excalibur-r50771-20070214 release notes --- This is a backwards-compatible maintainance release of all maintained excalibur.apache.org software, including packages formerly part of the avalon.apache.org project: avalon-framework, avalon-logkit, and avalon-cornerstone. This is the first set of new excalibur releases since August 29, 2005. The binary version of the distribution takes the form of a maven2- structured jar repository. The main change has been a complete repackaging to work well with maven2-structured builds. All version numbers of all components have been bumped significantly to reflect the new structure. Changes not related to the rework to use maven 2: * r492442,r492443,r492443,r492447,r492448,r492449,r492451,r492452,r492453, r501342,r501344: removal of the "Component" marker interface on interfaces inside excalibur's components * re-instated excalibur-i18n package * updated license text and policies to comply with revised ASF licensing standards * code reformattings, cleanups, javadoc additions and corrections * r492440, fix for EXLBR-32, proper closing of URLConnection in excalibur-sourceresolve * r468933, fix for EXLBR-31, handle multi-level stylesheet caching in excalibur-xmlutil * r467579, more robust dealing with missing classes on default excalibur-fortress startup * r437037, reset lexical handler before reusing JAXP parser in excalibur-xmlutil * r391887, better debug handling for SMTP targets in excalibur-logger * r390538, fix broken timeout feature in URLSource in excalibur- sourceresolve * r374681, remove call to System.out.println() in JAXP parser in excalibur-xmlutil * r366060, make fortress' TestContainer public for external use in excalibur-fortress * r359876, improve null handling for logger in metainfo collector in excalibur-fortress * r358988,r358989,r358990, fix for FORTRESS-21, maven2 plugin for metainfo collection * r330744,r330745,r330799 add more reporting for resource limiting pools in excalibr-pool * r280457, add new removeCurrentContext() to ContextMap in avalon- logkit * r278681,r279496,r279498,r280510,r327966,r329206,r329208,r349071, extensive rework of excalibur-instrument, reporting on more details, fixing handling of null and NPEs, looking prettier Security-related changes: * none This is the best available release of excalibur software today. We recommend you upgrade if * you make use or intend to make use of a maven2-structured repository layout * you use any of the following packages: * excalibur-instrument * excalibur-fortress * excalibur-i18n * excalibur-sourceresolve * excalibur-xmlutil This release has not been tested with JDK/J
Postable source and servlet services problem
Hello, I would like to start implementing postable source and special pipeline components supporting them; all leading to implementation of servlet services general concept. Before going into implementation details I would like to express my main concern. Sitemap realization --- Daniel proposed[1] postable source and bunch of special pipeline components calling servlet services. Let's focus only on transforming case as others (reading, generation and serialization) are similar or simpler cases. Now, we have to think about two main problems. Unnecessary serialization/deserialization Daniel proposed[2] making servlet request and response objects SAX-aware. It's good idea, additionally we should provide fall back mechanism if target servlet was not SitemapServlet. Then stream of sax events should be seen as serialized into request body. In detail, we should conform with HTTP POST semantics. On the target sitemap side we would have pipeline like this: If request is SAX-aware ServiceConsumer would just provide it's sax stream. If not, generator would try to parse request body (octet data) as XML and provide SAX stream. Service producer would work symmetrically. This way we could have generic servlet service pipeline without introducing new syntax into sitemap language. Also, we get fall back mechanism. I think it's really clean solution and non intrusive into any pipeline/sitemap code. Caching problems That's really tricky part. Main problem is that ServiceConsumer has no information that could be used to calculate caching key. Caching key is unique (in component's context) identifier that identifies resource state (data) on processing stage. Normally generator provides some URI to the original resource or so. In our case, resource is SAX stream after some transformations applied. Thus, key must be an aggregation of the keys provided by components that applied some processing before service was called. Ok, so servlet service request should contain this aggregation (as ETag header or some request parameter). This is a right time to take a look on caller's sitemap: value="servlet:other_servlet:/some_service"/> We would like service transformer to pass cache key of generator to the request object created for calling the service. The problem is that AFAIK there is no way to obtain cache keys of the components that occur before any other component. I think we hit here little design flaw. Transformer is atomic sitemap component, but servlet service is pipeline fragment. We try to treat pipeline as transformer and this leads to problems like outlined above. From the user and elegance of the sitemap point of view it's justified to treat servlet service as exactly one transformer (or any other component) because it's aimed to hide any implementation details of the service and service really does the processing exactly the same (semantically) way as transformer. Even though it's technical problem, it *is* serious problem and I have to admit that have no idea how to fix it in a clever, clean way. Comments? Thoughts? -- Grzegorz Kossakowski
Re: [VOTE] new excalibur release
Jorg Heymans wrote: Also-2: i have not signed the release, if someone can help me out on how to do this that would be great as well. I usually follow [1], worked fine. Vadim [1] http://jakarta.apache.org/commons/releases/release.html
[jira] Subscription: COCOON-open-with-patch
Issue Subscription Filter: COCOON-open-with-patch (98 issues) Subscriber: cocoon Key Summary COCOON-2010 ServletConnection and ServletSource cache-aware https://issues.apache.org/jira/browse/COCOON-2010 COCOON-2009 Pipelines more HTTP-compliant (respecting and producing HTTP headers and status codes) https://issues.apache.org/jira/browse/COCOON-2009 COCOON-2002 HTML transformer only works with latin-1 characters https://issues.apache.org/jira/browse/COCOON-2002 COCOON-1997 Configure servlet: links rewriting https://issues.apache.org/jira/browse/COCOON-1997 COCOON-1996 New input module: StringConcatMetaModule https://issues.apache.org/jira/browse/COCOON-1996 COCOON-1994 Make Forms resources loaded directly https://issues.apache.org/jira/browse/COCOON-1994 COCOON-1993 Make Forms resources loaded directly https://issues.apache.org/jira/browse/COCOON-1993 COCOON-1992 Make Ajax resourced loaded directly from cocoon-ajax-impl https://issues.apache.org/jira/browse/COCOON-1992 COCOON-1974 Donating ContextAttributeInputModule https://issues.apache.org/jira/browse/COCOON-1974 COCOON-1973 CaptchaValidator: allow case-insensitive matching https://issues.apache.org/jira/browse/COCOON-1973 COCOON-1964 Redirects inside a block called via the blocks protocol fail https://issues.apache.org/jira/browse/COCOON-1964 COCOON-1963 Add a redirect action to the browser update handler https://issues.apache.org/jira/browse/COCOON-1963 COCOON-1960 Pipeline errors for "generator/reader already set" should provide more information https://issues.apache.org/jira/browse/COCOON-1960 COCOON-1955 [Patch] Allow shielded class loading for a single block https://issues.apache.org/jira/browse/COCOON-1955 COCOON-1954 [Patch] RequestProcessor swallows exceptions in blocks case https://issues.apache.org/jira/browse/COCOON-1954 COCOON-1949 [PATCH] load flowscript from file into specified Rhino context object https://issues.apache.org/jira/browse/COCOON-1949 COCOON-1946 [PATCH] - Javaflow Sample errors trying to enhance Javaflow classes and showing cform templates https://issues.apache.org/jira/browse/COCOON-1946 COCOON-1932 [PATCH] correct styling of disabled suggestion lists https://issues.apache.org/jira/browse/COCOON-1932 COCOON-1929 [PATCH] Reloading classloader in Cocoon 2.2 https://issues.apache.org/jira/browse/COCOON-1929 COCOON-1917 Request Encoding problem: multipart/form vs. url encoded https://issues.apache.org/jira/browse/COCOON-1917 COCOON-1915 Nullable value with additional String or XMLizable in JavaSelectionList https://issues.apache.org/jira/browse/COCOON-1915 COCOON-1914 Text as XMLizable in EmptySelectionList https://issues.apache.org/jira/browse/COCOON-1914 COCOON-1899 [PATCH] Cocoon XML:DB Implementation should not depend on Xindice https://issues.apache.org/jira/browse/COCOON-1899 COCOON-1898 [PATCH] XPatch support for maven-cocoon-deployer-plugin https://issues.apache.org/jira/browse/COCOON-1898 COCOON-1893 XML-Binding: Problem creating a new element https://issues.apache.org/jira/browse/COCOON-1893 COCOON-1887 Host selector should be case insensitive https://issues.apache.org/jira/browse/COCOON-1887 COCOON-1877 [PATCH] Pageable Repeater https://issues.apache.org/jira/browse/COCOON-1877 COCOON-1870 Lucene block does not store attributes when instructed so https://issues.apache.org/jira/browse/COCOON-1870 COCOON-1846 [PATCH] BooleanField and radio do not send on-value-changed at the rigth time with IE https://issues.apache.org/jira/browse/COCOON-1846 COCOON-1843 LDAPTransformer: add-entry tag doesn't work https://issues.apache.org/jira/browse/COCOON-1843 COCOON-1842 LDAPTransformer: ClassCastException with Binary fields https://issues.apache.org/jira/browse/COCOON-1842 COCOON-1838 Always use 3-digit version number https://issues.apache.org/jira/browse/COCOON-1838 COCOON-1810 [PATCH] JMSEventMessageListener does not work https://issues.apache.org/jira/browse/COCOON-1810 COCOON-1807 Workaround for IE Bug in https://issues.apache.org/jira/browse/COCOON-1807 COCOON-1794 [PATCH] Propagation of namespaces to a repeaters child bindings and implementation of a move-node binding https://issues.apache.org/jira/browse/COCOON-1794 COCOON-1738 double-listbox problem in repeaters https://issues.apache.org/jira/browse/COCOON-1738 COCOON-1726 Implementation of Source that supports conditional GETs https://issues.apache.org/jira/browse/COCOON-1726 COCOON-1717 Use custom cache keys for caching uri coplets using input modules. https://issues.apache.org/jira/browse/COCOON-1717 COC
[jira] Commented: (COCOON-1987) Unable to get the object model from the context
[ https://issues.apache.org/jira/browse/COCOON-1987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12473022 ] Felix Knecht commented on COCOON-1987: -- Now I'm getting some other error probably because of the configurations. I'll work on this and provide a patch as soon as I get the sample up and running. BTW: I think I haven't enough Karma to close the issue as I'm not a committer. > Unable to get the object model from the context > --- > > Key: COCOON-1987 > URL: https://issues.apache.org/jira/browse/COCOON-1987 > Project: Cocoon > Issue Type: Bug > Components: Blocks: Authentication Framework >Affects Versions: 2.2-dev (Current SVN) >Reporter: Felix Knecht > Assigned To: Carsten Ziegeler > Fix For: 2.2-dev (Current SVN) > > > Can't run blocks/cocoon-authentication-fw-sample because of: > 2007-01-22 08:34:23.388::WARN: Failed startup of context [EMAIL > PROTECTED]/,file:/home/felix/svn/apache/cocoon-2.2.x/core/cocoon-webapp/target/cocoon-webapp/} > org.springframework.beans.factory.BeanCreationException: Unable to initialize > Avalon component with role > org.apache.cocoon.webapps.authentication.AuthenticationManager; nested > exception is org.apache.cocoon.components.ContextResourceNotFoundException: > Unable to get the object model from the context. > Caused by: org.apache.cocoon.components.ContextResourceNotFoundException: > Unable to get the object model from the context. > at > org.apache.cocoon.components.ContextHelper.getObjectModel(ContextHelper.java:91) > at > org.apache.cocoon.webapps.authentication.components.DefaultAuthenticationManager.configure(DefaultAuthenticationManager.java:109) > at > org.apache.avalon.framework.container.ContainerUtil.configure(ContainerUtil.java:201) > at > org.apache.cocoon.core.container.spring.avalon.AvalonBeanPostProcessor.postProcessBeforeInitialization(AvalonBeanPostProcessor.java:235) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyBeanPostProcessorsBeforeInitialization(AbstractAutowireCapableBeanFactory.java:302) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1081) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:429) > at > org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:250) > at > org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:141) > at > org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:247) > at > org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:161) > at > org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:273) > at > org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:346) > at > org.springframework.web.context.support.AbstractRefreshableWebApplicationContext.refresh(AbstractRefreshableWebApplicationContext.java:156) > at > org.springframework.web.context.ContextLoader.createWebApplicationContext(ContextLoader.java:246) > at > org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:184) > at > org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:49) > at > org.mortbay.jetty.handler.ContextHandler.startContext(ContextHandler.java:451) > at org.mortbay.jetty.servlet.Context.startContext(Context.java:124) > at > org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1219) > at > org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:421) > at > org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:496) > at > org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40) > at > org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:156) > at > org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:120) > at > org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40) > at > org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:156) > at > org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40) > at > org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:119) > at org.mort
