Re: [GSoC] status reports?

[Robert Graham]

Hello all,

Let me preface this by saying that I've really enjoyed this project
and everything that I've learned. I hope, time constraints under my
studies permitting, that I can continue to be a community member. I'm
working hard at the end to wrap it up and I think that it looks
something like the final goal for this project.

Progress:

I have taught myself XSLT and learned a lot about Cocoon. I've even
picked up some information about SAX processing (I've really only got
previous experience with DOM). Though that has little to do with the
project's goals except that I have to be the achiever.

I have expanded the prototype code that Bertrand gave me in fixing
bugs, creating functionality that we needed for the project, and
learning about the technologies. The system now can be pointed at any
directory with little effort and used to create an index of doktor
comments that can even be searched. The app can generate an xml stream
enumerating only those snippets that correspond to the searched for
key and order them in an unsatisfactory but better than no order sort
of way.

Problems:

I am not sure of issues in ordering the items with XSLT which I will
address in more detail in a moment. Hopefully I can get some feedback
and ideas on how to implement that. The last thing is simply that we
don't have a lot of time left and I'd like to finally publish
something detailing the work as it is and as it should be using the
system itself, but I'm not familiar with Forrest and even if I liked
the current state of the system I doubt I could create the desired
publication without guide and in time unless Forrest is far simpler
than Cocoon.

The ordering issues are fairly simple to describe. I can't make XSLT
do what I want. Most likely because I'm not too familiar with it. I
have snippets (many of them) in a file with attributes of key, type,
and name. I'd like to order them by type first which I've done. The
snippets that have the same name attribute, however, are related to
each other and should be ordered adjacent to each other. I can't see
how to get each () with the same name attribute to
stick together without knowing the name attributes I'm interested in
beforehand. (look at ordering-neutral.xsl)

The last issue I have is a bug I haven't been able to solve. Sometimes
in the way of processing the comments and indexing them and them
grabbing the stored fields and processing them again I lose the actual
comment contents and haven't been able to locate this bug. I think
Bertrand may know what the issue is, however, as I think it has
something to do with the way I interact with his prototype code.

Perspectives:
Hopefully get some initial feedback from this email while trying to
solve the three issues above. If I can't solve them I will in parallel
setup comments in the code I've written that will be there so I can
generate publishable documentation for the project (the goal). I will
then try to use Forrest and whatever other tools to get it into a
reasonable published form.

The issues are in my mind from most to least important: publishing,
ordering, content bug (as I think the solution to the last is simple,
but hard for me to see)

I'd be happy to clarify anything or provide more information. I thank
anyone who looks things over in advance for it and any help/advice
they may offer.

Thanks,
Robert Graham

Re: [GSoC] status reports?

[Torsten Curdt]

On 22.08.2005, at 08:55, Bertrand Delacretaz wrote:

With ten days left to finish the GSoC projects, I think it would be  
good for our three students to provide a short status report here.


+1

cheers
--
Torsten



PGP.sig
Description: This is a digitally signed message part

Re: svn commit: r234450 - in /cocoon/trunk: legal/jakarta-regexp-1.3.jar.license.txt legal/jakarta-regexp-1.4.jar.license.txt lib/endorsed/jakarta-regexp-1.3.jar lib/endorsed/jakarta-regexp-1.4.jar li

[Daniel Fagerstrom]

Joerg Heinicke wrote:
Could you please update the Bundle-Classpath (used by OSGi) in 
trunk/src/java/Manifest.mf when you update jars in lib/core or 
lib/endorsed. I did it for your update, but I might miss updates so it 
is good if more people remember it. This is only a temporary 
situation, the jars should be separate bundles instead of being 
packaged in the Cocoon core bundle, also I didn't felt to write 
something more automatic until we have finished changning build system 
to Maven2.


What about generating this file?


We have discussed that, some people would prefer to generate the 
manifest files from block.xml and some other, I for example, prefer to 
have explicit manifest files. There are a number of configuration files 
that we will need that might have some overlap: Manifest.mf, block.xml 
gump.xml and pom.xml. We decided to wait a little bit until we have 
implemented more of the block and sitemap handling stuff in the block 
architecture before we decide.


Also there is some activity in the Oscar project on writing a 
OSGi-plugin for Maven2.


Normally bundle (block) manifest files will not be as complicated as the 
 one for the Cocoon core bundle, which currently is far to monolithic. 
The long term plan is to remove almost all of the jars that currently is 
part of the Cocoon core bundle (most of lib/core and lib/endorsed) and 
package them as bundles. But it will require some work to write (or 
generate) bundle files for all these jars. Hopefully we can work 
together with the maintainers for at least some of these jars so that 
they put a bundle manifest file in the jars, (this should IMO be 
possible for the Excalibur and Commons jars).


The Cocoon core bundle should probably also be split into a number of 
blocks.


OTH, it should be rather easy to generate the Bundle-Classpath during 
the build, so if anyone have feel like it, please go ahead.


/Daniel

Re: svn commit: r234450 - in /cocoon/trunk: legal/jakarta-regexp-1.3.jar.license.txt legal/jakarta-regexp-1.4.jar.license.txt lib/endorsed/jakarta-regexp-1.3.jar lib/endorsed/jakarta-regexp-1.4.jar li

[Joerg Heinicke]

Could you please update the Bundle-Classpath (used by OSGi) in 
trunk/src/java/Manifest.mf when you update jars in lib/core or 
lib/endorsed. I did it for your update, but I might miss updates so it 
is good if more people remember it. This is only a temporary situation, 
the jars should be separate bundles instead of being packaged in the 
Cocoon core bundle, also I didn't felt to write something more automatic 
until we have finished changning build system to Maven2.


What about generating this file?

Joerg

Re: [GT2005] ANNOUNCE: Cocoon GetTogether registration NOW open

[Ralph Goers]

Thanks.

Ralph

Joerg Heinicke wrote:


Is there a cost for the hackathon?




See the button of the registration page.



Ouch! *Bottom* of course.

Joerg

Re: [GT2005] ANNOUNCE: Cocoon GetTogether registration NOW open

[Joerg Heinicke]

Is there a cost for the hackathon?



See the button of the registration page.


Ouch! *Bottom* of course.

Joerg

Re: [GT2005] ANNOUNCE: Cocoon GetTogether registration NOW open

[Joerg Heinicke]

On 22.08.2005 19:12, Ralph Goers wrote:

Is there a cost for the hackathon?


See the button of the registration page.

Joerg

Re: [GT2005] ANNOUNCE: Cocoon GetTogether registration NOW open

[Ralph Goers]

Is there a cost for the hackathon?

Arje Cahn wrote:



Cocoon GetTogether 2005
Friday, October 7th in Amsterdam, The Netherlands
Hackathon on October 5th & 6th
http://www.cocoongt.org


In 6 weeks time, for the fourth year, there'll be plenty of Cocoon talks, 
hacking, food, beers and laughs - everything you've been waiting for since you 
left Ghent on October 12th last year...

The yearly Cocoon GetTogether runs as a series of presentations by Cocoon 
developers, sharing their knowledge about the Apache Cocoon framework in a 
leisurely fashion, with plenty of time for interaction and probing questions. 
Whether you're a Cocoon developer or user, either expert, beginner, or only 
curious about it, this event is for you. Want to know more about the technology 
and the people behind it? Come join us at this year's Cocoon GetTogether in 
Amsterdam!

Last year's GetTogether was a big succes, drawing no less than 138 people from 
18 different countries to Ghent, Belgium. If you want to know more about last 
year's program, visit http://www.orixo.com/events/gt2004/program.html.

The GetTogether participation cost is 85 EUR - Hackathon and events not included. You can pay either through an international money transfer or through Paypal. 


Registration for the GetTogether is *now* open, until September 28th. Be sure 
to register on time!
For more information and to register right away, visit http://www.cocoongt.org.

Hope to see you in October in Amsterdam!

On behalf of the GT 2005 organising team,

Arjé Cahn



Hippo  


Oosteinde 11
1017WT Amsterdam
The Netherlands
Tel  +31 (0)20 5224466
-
[EMAIL PROTECTED] / www.hippo.nl
--



 

[ANN] Daisy 1.3 released

[Steven Noels]

Hi all,

We are happy to announce the next release of Daisy, the Open Source  
CMS/Wiki framework.


Daisy 1.3 has been in development for 6 months, and packs many new  
features while providing a wealth of improvements to ensure easier  
implementation and integration. Daisy 1.3 has been reviewed favorably  
("Very Good") in Infoworld's IT Product Guide  
(http://www.infoworld.com/Outerthought_Daisy/product_62007.html? 
view=0&curNodeId=16).


Notable new features in this release are:

* the introduction of document variants, to support different document  
branches and multi-linguality

* document tasks for the automation of batched document operations
* easier installation with more defaults and less configuration work
* scriptability using JavaScript (based on Rhino)
* support for multiple authentication schemes (ships with LDAP and NTLM  
support)
* multi-value fields for management of keyword-like metadata fields  
("tags")
* a faceted navigation browser for metadata-based exploration of large  
document sets
* improved role management providing "group"-based access control  
organization
* a totally revamped and vastly improved skinning and publishing  
mechanism, allowing easier creation of custom look-and-feels, and  
easier implementation of custom Daisy-based applications

* preliminary RSS feed support

Daisy 1.3 is available - free of charge and liberally licensed - from  
http://cocoondev.org/daisy/.


Furthermore, Outerthought will be expanding its range of services  
around Daisy in the near future: managed Daisy Hosting, and  
fixed-price, turn-key Daisy-based CMS and knowledge management  
projects. Keep an eye on our corporate website for news updates:  
http://outerthought.org/


For more information, please contact us at [EMAIL PROTECTED] or +32  
9 338 82 20 - or using the Daisy mailing list of course.


Thanks,


--
Steven Noelshttp://outerthought.org/
Outerthought  Open Source Java & XML
stevenn at outerthought.orgstevenn at apache.org

Re: Lucene Block 1.1

[Robert Goene]

Thanks! I have included the lucene2.roles in the lenya.roles 
configuration. I assume i have to do some more configuration on the 
IndexManager part, because i get an error.


Do you happen to have an example of a complete configuration? I have 
some troubles finding some good documentation. Some URL's would be great 
too!


Thanks again, Robert

Nicolas Maisonneuve wrote:

sorry to forgot to answer to your question   ;-)

the components declaration is differents between 2.1 and 2.2 . 
in 2.2 the component declaration are in WEB-INF/xconf/ 
(searchengine.xconf for the lucene block)

in 2.1 you have to modify the cocoon.xconf  (i think you have to add
user-role="xconf/myuser.xconf" attribute  in the cocoon tag or
something like that, seek into the mailing list )  to use the
searchengine.xconf
maybe the declaration format changes , see the doc for the component
declaration in 2.1

but there are not speacial 2.2 feature used in the lucene block. so
the transformer is 2.1 compatible. It's just a configuration pb.

nicolas 




On 8/22/05, Robert Goene <[EMAIL PROTECTED]> wrote:


Hi,

Thanks for your reply. I actually meant the LuceneIndexTransformer, not
a searchTransformer. I cannot make the one found in bugzilla work in my
setup. It is probably something very simple, but it could also be caused
by a fundamental difference betweeen cocoon 2.1 and 2.2

Are there any extra steps i need to take to use the
LuceneIndexTransformer2, like adding components to cocoon.xconf?

Thanks a lot!

Robert

Nicolas Maisonneuve wrote:


i have a old searchTransformer that didn't work because i was
refactoring all the project 'SearchTransformer, IndexTransformer) for
working with Spring. and Hibernate and  cforms  for the configuration.

the searchTransformer have a xml search query,  with 3 query type,
fulltext query (choose the set of indexed field and  boost the raking
of some  fields (ex: Title more important than body etc),   faceted
classification  query, for hierarchical key word, and simple field
search

but i'm really not proud  about my code , it's tirdy .. . maybe i can
upload the code event if doesn't work , after cleaning and documenting
the source.


nicolas


On 8/22/05, Robert Goene <[EMAIL PROTECTED]> wrote:



Hi,

I am working on the Apache Lenya project and integrating the
LuceneSearchTransformer. I saw the contribution of Nicolas Maisonneuve
to the Cocoon community
(http://issues.apache.org/bugzilla/show_bug.cgi?id=32263) and it
contained a number of features i wanted to implement myself. Of course,
i would love to use your contribution

The problem is that Lenya uses the 2.1.x version of Cocoon and not the
2.2 trunk. I get errors when running the transformer: the
org.apache.cocoon.components.search.components.IndexManager component
could not be found.

Is this error caused by my version of cocoon or is it caused by a faulty
configuration?

Thanks, Robert





--
Cleancode
Robert Goené

Kadijksplein 14-II
1018 AC Amsterdam
06 26090816




--
Cleancode
Robert Goené

Kadijksplein 14-II
1018 AC Amsterdam
06 26090816

DO NOT REPLY [Bug 36299] New: - WebServiceProxyGenerator sample block error

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=36299

   Summary: WebServiceProxyGenerator sample block error
   Product: Cocoon 2
   Version: 2.1.7
  Platform: Other
OS/Version: other
Status: NEW
  Severity: normal
  Priority: P2
 Component: blocks
AssignedTo: dev@cocoon.apache.org
ReportedBy: [EMAIL PROTECTED]


http://localhost:/samples/blocks/proxy/wsproxy/ doesn't work in 2.1.7 
build.

I get this error message:
"Impossible de résoudre le préfixe de l'espace de noms : xalan"
(wich means in english: "unable to resolve xalan namespace"

I've seen that this block has bugs (14916, 21339, 21340, 21399) open in the 
main SVN trunk... but they don't seem to deal with this problem.

I tried to remove: 
  exclude-result-prefixes="xalan"
from newWizard2html.xsl
(just to see...)
I get an other error message:
C:\...\cocoon-2.1.7\build\webapp\stylesheets\system\xmlform2html.xslt (Le 
fichier spécifié est introuvable)
(in english: unable to find .../xmlform2html.xslt)

Is it solve in the main trunk ?



--
Full stacktrace of "unable to resolve xalan namespace":

org.apache.cocoon.ProcessingException: Unable to get transformer handler for 
file:/C:/developpement/apache/cocoon-
2.1.7/build/webapp/samples/blocks/proxy/stylesheets/newWizard2html.xsl: 
org.apache.excalibur.xml.xslt.XSLTProcessorException: Exception in creating 
Transform Handler
at org.apache.cocoon.transformation.TraxTransformer.setup
(TraxTransformer.java:318)
at 
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.setupPipeline
(AbstractProcessingPipeline.java:398)
at 
org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipeline.se
tupPipeline(AbstractCachingProcessingPipeline.java:620)
at 
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.preparePipelin
e(AbstractProcessingPipeline.java:503)
at 
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process
(AbstractProcessingPipeline.java:455)
at 
org.apache.cocoon.components.treeprocessor.sitemap.SerializeNode.invoke
(SerializeNode.java:120)
at 
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeN
odes(AbstractParentProcessingNode.java:46)
at 
org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke
(PreparableMatchNode.java:130)
at 
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeN
odes(AbstractParentProcessingNode.java:68)
at 
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke
(PipelineNode.java:138)
at 
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeN
odes(AbstractParentProcessingNode.java:68)
at 
org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke
(PipelinesNode.java:92)
at 
org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process
(ConcreteTreeProcessor.java:234)
at 
org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process
(ConcreteTreeProcessor.java:176)
at org.apache.cocoon.components.treeprocessor.TreeProcessor.process
(TreeProcessor.java:243)
at org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke
(MountNode.java:117)
at 
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeN
odes(AbstractParentProcessingNode.java:46)
at 
org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke
(PreparableMatchNode.java:130)
at 
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeN
odes(AbstractParentProcessingNode.java:68)
at 
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke
(PipelineNode.java:138)
at 
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeN
odes(AbstractParentProcessingNode.java:68)
at 
org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke
(PipelinesNode.java:92)
at 
org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process
(ConcreteTreeProcessor.java:234)
at 
org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process
(ConcreteTreeProcessor.java:176)
at org.apache.cocoon.components.treeprocessor.TreeProcessor.process
(TreeProcessor.java:243)
at org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke
(MountNode.java:117)
at 
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeN
odes(AbstractParentProcessingNode.java:46)
at 
org.apache.cocoon.components.treeprocessor.sitem

Re: [JCR Block] Viewing content of properties and last modified

[Michael Wechner]

Andreas Hartmann wrote:


Michael Wechner wrote:

what I meant was that I want to use the Source to get the content of 
the property, e.g.



[EMAIL PROTECTED]


whereas I am not sure if the above is correct JCR path syntax



OK, now I see what you mean. That would be really useful,
for instance to access Lenya meta data in presentation pipelines.



I'll try to change the JCR block re properties.

Any objections?

Thanks

Michi

--
Michael Wechner
Wyona  -   Open Source Content Management   -Apache Lenya
http://www.wyona.com  http://lenya.apache.org
[EMAIL PROTECTED][EMAIL PROTECTED]

[GT2005] ANNOUNCE: Cocoon GetTogether registration NOW open

[Arje Cahn]

Cocoon GetTogether 2005
Friday, October 7th in Amsterdam, The Netherlands
Hackathon on October 5th & 6th
http://www.cocoongt.org


In 6 weeks time, for the fourth year, there'll be plenty of Cocoon talks, 
hacking, food, beers and laughs - everything you've been waiting for since you 
left Ghent on October 12th last year...

The yearly Cocoon GetTogether runs as a series of presentations by Cocoon 
developers, sharing their knowledge about the Apache Cocoon framework in a 
leisurely fashion, with plenty of time for interaction and probing questions. 
Whether you're a Cocoon developer or user, either expert, beginner, or only 
curious about it, this event is for you. Want to know more about the technology 
and the people behind it? Come join us at this year's Cocoon GetTogether in 
Amsterdam!

Last year's GetTogether was a big succes, drawing no less than 138 people from 
18 different countries to Ghent, Belgium. If you want to know more about last 
year's program, visit http://www.orixo.com/events/gt2004/program.html.

The GetTogether participation cost is 85 EUR - Hackathon and events not 
included. You can pay either through an international money transfer or through 
Paypal. 

Registration for the GetTogether is *now* open, until September 28th. Be sure 
to register on time!
For more information and to register right away, visit http://www.cocoongt.org.

Hope to see you in October in Amsterdam!

On behalf of the GT 2005 organising team,

Arjé Cahn



Hippo  

Oosteinde 11
1017WT Amsterdam
The Netherlands
Tel  +31 (0)20 5224466
-
[EMAIL PROTECTED] / www.hippo.nl
--

Re: Lucene Block 1.1

[Nicolas Maisonneuve]

sorry to forgot to answer to your question   ;-)

the components declaration is differents between 2.1 and 2.2 . 
in 2.2 the component declaration are in WEB-INF/xconf/ 
(searchengine.xconf for the lucene block)
in 2.1 you have to modify the cocoon.xconf  (i think you have to add
user-role="xconf/myuser.xconf" attribute  in the cocoon tag or
something like that, seek into the mailing list )  to use the
searchengine.xconf
maybe the declaration format changes , see the doc for the component
declaration in 2.1

but there are not speacial 2.2 feature used in the lucene block. so
the transformer is 2.1 compatible. It's just a configuration pb.

nicolas 



On 8/22/05, Robert Goene <[EMAIL PROTECTED]> wrote:
> Hi,
> 
> Thanks for your reply. I actually meant the LuceneIndexTransformer, not
> a searchTransformer. I cannot make the one found in bugzilla work in my
> setup. It is probably something very simple, but it could also be caused
> by a fundamental difference betweeen cocoon 2.1 and 2.2
> 
> Are there any extra steps i need to take to use the
> LuceneIndexTransformer2, like adding components to cocoon.xconf?
> 
> Thanks a lot!
> 
> Robert
> 
> Nicolas Maisonneuve wrote:
> > i have a old searchTransformer that didn't work because i was
> > refactoring all the project 'SearchTransformer, IndexTransformer) for
> > working with Spring. and Hibernate and  cforms  for the configuration.
> >
> > the searchTransformer have a xml search query,  with 3 query type,
> > fulltext query (choose the set of indexed field and  boost the raking
> > of some  fields (ex: Title more important than body etc),   faceted
> > classification  query, for hierarchical key word, and simple field
> > search
> >
> > but i'm really not proud  about my code , it's tirdy .. . maybe i can
> > upload the code event if doesn't work , after cleaning and documenting
> > the source.
> >
> >
> > nicolas
> >
> >
> > On 8/22/05, Robert Goene <[EMAIL PROTECTED]> wrote:
> >
> >>Hi,
> >>
> >>I am working on the Apache Lenya project and integrating the
> >>LuceneSearchTransformer. I saw the contribution of Nicolas Maisonneuve
> >>to the Cocoon community
> >>(http://issues.apache.org/bugzilla/show_bug.cgi?id=32263) and it
> >>contained a number of features i wanted to implement myself. Of course,
> >>i would love to use your contribution
> >>
> >>The problem is that Lenya uses the 2.1.x version of Cocoon and not the
> >>2.2 trunk. I get errors when running the transformer: the
> >>org.apache.cocoon.components.search.components.IndexManager component
> >>could not be found.
> >>
> >>Is this error caused by my version of cocoon or is it caused by a faulty
> >>configuration?
> >>
> >>Thanks, Robert
> >>
> >>
> 
> 
> --
> Cleancode
> Robert Goené
> 
> Kadijksplein 14-II
> 1018 AC Amsterdam
> 06 26090816
>

Re: Lucene Block 1.1

[Robert Goene]

Hi,

Thanks for your reply. I actually meant the LuceneIndexTransformer, not 
a searchTransformer. I cannot make the one found in bugzilla work in my 
setup. It is probably something very simple, but it could also be caused 
by a fundamental difference betweeen cocoon 2.1 and 2.2


Are there any extra steps i need to take to use the 
LuceneIndexTransformer2, like adding components to cocoon.xconf?


Thanks a lot!

Robert

Nicolas Maisonneuve wrote:

i have a old searchTransformer that didn't work because i was
refactoring all the project 'SearchTransformer, IndexTransformer) for
working with Spring. and Hibernate and  cforms  for the configuration.

the searchTransformer have a xml search query,  with 3 query type,
fulltext query (choose the set of indexed field and  boost the raking
of some  fields (ex: Title more important than body etc),   faceted
classification  query, for hierarchical key word, and simple field
search

but i'm really not proud  about my code , it's tirdy .. . maybe i can
upload the code event if doesn't work , after cleaning and documenting
the source.


nicolas


On 8/22/05, Robert Goene <[EMAIL PROTECTED]> wrote:


Hi,

I am working on the Apache Lenya project and integrating the
LuceneSearchTransformer. I saw the contribution of Nicolas Maisonneuve
to the Cocoon community
(http://issues.apache.org/bugzilla/show_bug.cgi?id=32263) and it
contained a number of features i wanted to implement myself. Of course,
i would love to use your contribution

The problem is that Lenya uses the 2.1.x version of Cocoon and not the
2.2 trunk. I get errors when running the transformer: the
org.apache.cocoon.components.search.components.IndexManager component
could not be found.

Is this error caused by my version of cocoon or is it caused by a faulty
configuration?

Thanks, Robert





--
Cleancode
Robert Goené

Kadijksplein 14-II
1018 AC Amsterdam
06 26090816

Re: Lucene Block 1.1

[Nicolas Maisonneuve]

i have a old searchTransformer that didn't work because i was
refactoring all the project 'SearchTransformer, IndexTransformer) for
working with Spring. and Hibernate and  cforms  for the configuration.

the searchTransformer have a xml search query,  with 3 query type,
fulltext query (choose the set of indexed field and  boost the raking
of some  fields (ex: Title more important than body etc),   faceted
classification  query, for hierarchical key word, and simple field
search

but i'm really not proud  about my code , it's tirdy .. . maybe i can
upload the code event if doesn't work , after cleaning and documenting
the source.


nicolas


On 8/22/05, Robert Goene <[EMAIL PROTECTED]> wrote:
> Hi,
> 
> I am working on the Apache Lenya project and integrating the
> LuceneSearchTransformer. I saw the contribution of Nicolas Maisonneuve
> to the Cocoon community
> (http://issues.apache.org/bugzilla/show_bug.cgi?id=32263) and it
> contained a number of features i wanted to implement myself. Of course,
> i would love to use your contribution
> 
> The problem is that Lenya uses the 2.1.x version of Cocoon and not the
> 2.2 trunk. I get errors when running the transformer: the
> org.apache.cocoon.components.search.components.IndexManager component
> could not be found.
> 
> Is this error caused by my version of cocoon or is it caused by a faulty
> configuration?
> 
> Thanks, Robert
> 
>

Re: svn commit: r234450 - in /cocoon/trunk: legal/jakarta-regexp-1.3.jar.license.txt legal/jakarta-regexp-1.4.jar.license.txt lib/endorsed/jakarta-regexp-1.3.jar lib/endorsed/jakarta-regexp-1.4.jar li

[Daniel Fagerstrom]

Antonio (and others),

Could you please update the Bundle-Classpath (used by OSGi) in 
trunk/src/java/Manifest.mf when you update jars in lib/core or 
lib/endorsed. I did it for your update, but I might miss updates so it 
is good if more people remember it. This is only a temporary situation, 
the jars should be separate bundles instead of being packaged in the 
Cocoon core bundle, also I didn't felt to write something more automatic 
until we have finished changning build system to Maven2.


/Daniel

[EMAIL PROTECTED] wrote:


Author: antonio
Date: Mon Aug 22 00:55:43 2005
New Revision: 234450

URL: http://svn.apache.org/viewcvs?rev=234450&view=rev
Log:
Update jakarta-regexp to 1.4.

Added:
   cocoon/trunk/legal/jakarta-regexp-1.4.jar.license.txt
 - copied, changed from r234448, 
cocoon/trunk/legal/commons-collections-3.1.jar.license.txt
   cocoon/trunk/lib/endorsed/jakarta-regexp-1.4.jar   (with props)
Removed:
   cocoon/trunk/legal/jakarta-regexp-1.3.jar.license.txt
   cocoon/trunk/lib/endorsed/jakarta-regexp-1.3.jar
Modified:
   cocoon/trunk/lib/jars.xml
   cocoon/trunk/status.xml
 

Lucene Block 1.1

[Robert Goene]

Hi,

I am working on the Apache Lenya project and integrating the
LuceneSearchTransformer. I saw the contribution of Nicolas Maisonneuve
to the Cocoon community
(http://issues.apache.org/bugzilla/show_bug.cgi?id=32263) and it
contained a number of features i wanted to implement myself. Of course,
i would love to use your contribution

The problem is that Lenya uses the 2.1.x version of Cocoon and not the
2.2 trunk. I get errors when running the transformer: the
org.apache.cocoon.components.search.components.IndexManager component
could not be found.

Is this error caused by my version of cocoon or is it caused by a faulty
configuration?

Thanks, Robert

Lucene Block 1.1

[Robert Goene]

Hi,

I am working on the Apache Lenya project and integrating the 
LuceneSearchTransformer. I saw the contribution of Nicolas Maisonneuve 
to the Cocoon community 
(http://issues.apache.org/bugzilla/show_bug.cgi?id=32263) and it 
contained a number of features i wanted to implement myself. Of course, 
i would love to use your contribution


The problem is that Lenya uses the 2.1.x version of Cocoon and not the 
2.2 trunk. I get errors when running the transformer: the 
org.apache.cocoon.components.search.components.IndexManager component 
could not be found.


Is this error caused by my version of cocoon or is it caused by a faulty 
configuration?


Thanks, Robert

DO NOT REPLY [Bug 33746] - [Link] TanakhML Project

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=33746





--- Additional Comments From [EMAIL PROTECTED]  2005-08-22 09:03 ---
(In reply to comment #1)
> > How can we verify this site is actually built with Cocoon? 
> Or you can ask for a page that does not exist on our site, 
> like "http://verboomen.starline-inc.de/dummy.htm"; ("tanakhml.org" is 
currently 
> redirected to "verboomen.starline-inc.de"). You will get an error message 
from 
> Cocoon.

Please, replace the test proposed hereabove with this one, as TanakhML Project 
moved to a new web hosting service provider:
http://tanakhml2.alacartejava.net/cocoon/tanakhml/dummy.htm



-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.