Re: [Fwd: [proposal] Oscar OSGi Project]

[Reinhard Poetz]

Ralph Goers wrote:

Hmm. The email would lead one to think otherwise...

"We have established a list for discussions. Unless your comment is 
directed

to the general Incubator community or the Incubator PMC, please post
everything to :

   [EMAIL PROTECTED]

You can subscribe by sending an email to

   [EMAIL PROTECTED]

Until this proposal has been accepted by the Apache Incubator PMC, these 
lists

are provisional."


hmmm, have tried it myself without success. I will ask on Incubator about this 
issue.


--
Reinhard Pötz   Independent Consultant, Trainer & (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

Re: [Fwd: [proposal] Oscar OSGi Project]

[Ralph Goers]

Hmm. The email would lead one to think otherwise...

"We have established a list for discussions. Unless your comment is 
directed

to the general Incubator community or the Incubator PMC, please post
everything to :

   [EMAIL PROTECTED]

You can subscribe by sending an email to

   [EMAIL PROTECTED]

Until this proposal has been accepted by the Apache Incubator PMC, these 
lists

are provisional."

Ralph


Reinhard Poetz wrote:


Ralph Goers wrote:

Well, I'm very much in favor of this. Unfortunately, my messages sent 
to [EMAIL PROTECTED] are failing with no such 
mailbox.



The project has been proposed but not been accepted yet. Therefore no 
mailing lists yet.

Re: [Fwd: [proposal] Oscar OSGi Project]

[Reinhard Poetz]

Ralph Goers wrote:
Well, I'm very much in favor of this. Unfortunately, my messages sent to 
[EMAIL PROTECTED] are failing with no such mailbox.


The project has been proposed but not been accepted yet. Therefore no mailing 
lists yet.


--
Reinhard Pötz   Independent Consultant, Trainer & (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

Re: [Fwd: [proposal] Oscar OSGi Project]

[Ralph Goers]

Well, I'm very much in favor of this. Unfortunately, my messages sent to 
[EMAIL PROTECTED] are failing with no such mailbox.


Ralph

Reinhard Poetz wrote:



Alex Karasulu has proposed Oscar as Apache Projekt to the Incubator 
project. For those who don't know Oscar: Oscar is one of the available 
OSGi opensource implementations. In short, the goal of the Apache 
projekt will be the implementation of OSGi R4.


From what I can see, the feedback so far is overwhelming (see the list 
of supporters!) and we hopefully can use it soon as the base for our 
next Cocoon.





Subject:
[proposal] Oscar OSGi Project
From:
Alex Karasulu <[EMAIL PROTECTED]>
Date:
Thu, 14 Jul 2005 19:59:21 -0400
To:
Apache Incubator general discussion , 
[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]


To:
Apache Incubator general discussion , 
[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]



Hello,

The OSGi community at large, several Apache committers and members 
would like to start a new project based on the existing Oscar OSGi 
Container which Richard Hall is graciously willing to donate.  Without 
further commentary we present to you the proposal for the Oscar project:


Project Oscar
==


Motivation
--

Unlike .NET, which requires that applications are packaged as assemblies
with explicit dependencies among them, the Java platform does not offer
sufficient support for modularity. This lack of support complicates not
only Java application development, but also subsequent deployment and
administration. Many of the complications result from the fact that
every project that requires some form of modularity ends up inventing
their own ClassLoader-based approach for solving their needs. This
phenomenon is evident in application servers, integrated development
environments, and any component- or plugin-oriented systems. The OSGi
framework defined by the OSGi Alliance has a long history of addressing
these types of issues and the imminent release of version R4 of the OSGi
specification is set to move the OSGi framework even further along
this path.

The recent adoption of OSGi technology as the modularity layer of the
Eclipse Rich Client Platform (RCP) underscores the inroads that OSGi
technology has made. Further, the announcement of JSR 277 verifies that
demand for modularity in Java has reached a critical point.

This project can serve the greater Java open source community by
providing immediate modularity support for Java applications today
through the OSGi framework, creating a unifying community around open
source OSGi technology, and tracking and participating in the progression
of JSR 277.


Proposal


We propose the creation of a new Apache project, Oscar, that will achieve
the following goals :

1) create a compliant, independent implementation of the OSGi R4 core
  framework with framework-dependent services under the Apache License,
  Version 2.0.

2) unify resources from the OSGi community to implement, document, 
maintain,

  and support standard OSGi R4 services.

3) provide a focal point for the OSGi community to develop interfaces, 
APIs,
  and other common needs not fully specified by the OSGi R4 
specification,

  such as store interfaces, aspects of the runtime container's packaging
  and configuration, and the design and behavior of bundle repositories.
  4) provide a focal point for the open-source OSGi community to 
develop next

  generation enhancements to the core framework and act as a conduit for
  the open-source community to the OSGi Alliance.
  5) evangelize the OSGi Service Platform within Apache and provide 
documentation

  and support for successful container migrations.


Starting Participants
-

We propose that the following people are considered the starting 
participants.
We hope to start with a diverse cross-section of the community and 
preserve

this as we grow. The information in parenthesis indicates other community
participation or relevant experiences of that individual.

These individuals have expressed an interest in participating in the
architecture and design work and in participating as committers for the
Apache-licensed implementation :

  Richard Hall (OSGi Alliance (Invited Researcher) and Founder of the 
Oscar project)

  Alex Karasulu (Apache)
  Enrique Rodriguez (Apache)
  Trustin Lee (Apache)

These individuals will participate as Incubator Mentors :

  Alex Karasulu (Apache)

The following Apache Members will be the sponsoring members :

  Alex Karasulu (Apache)
  Noel Bergman (Apache)
  Carsten Ziegeler (Apache)
  Berin Loritsch (Apache)

The following community members support this effort :

  Daniel Fagerstrom (Apache)
  Niclas Hedhman (Apache)
  Peter Kriens (OSGi Alliance (Director of Technology) and Managing 
Director, aQute)

  Reinhard Poetz (Apache)
  Stefano Mazzocchi (Apache)
  Marcel Offermans (+2 others, Luminis)
  Rob Walker (As

[Fwd: [proposal] Oscar OSGi Project]

[Reinhard Poetz]

Alex Karasulu has proposed Oscar as Apache Projekt to the Incubator project. For 
those who don't know Oscar: Oscar is one of the available OSGi opensource 
implementations. In short, the goal of the Apache projekt will be the 
implementation of OSGi R4.


From what I can see, the feedback so far is overwhelming (see the list of 
supporters!) and we hopefully can use it soon as the base for our next Cocoon.


--
Reinhard Pötz   Independent Consultant, Trainer & (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

--- Begin Message ---

Hello,

The OSGi community at large, several Apache committers and members would 
like to start a new project based on the existing Oscar OSGi Container 
which Richard Hall is graciously willing to donate.  Without further 
commentary we present to you the proposal for the Oscar project:


Project Oscar
==


Motivation
--

Unlike .NET, which requires that applications are packaged as assemblies
with explicit dependencies among them, the Java platform does not offer
sufficient support for modularity. This lack of support complicates not
only Java application development, but also subsequent deployment and
administration. Many of the complications result from the fact that
every project that requires some form of modularity ends up inventing
their own ClassLoader-based approach for solving their needs. This
phenomenon is evident in application servers, integrated development
environments, and any component- or plugin-oriented systems. The OSGi
framework defined by the OSGi Alliance has a long history of addressing
these types of issues and the imminent release of version R4 of the OSGi
specification is set to move the OSGi framework even further along
this path.

The recent adoption of OSGi technology as the modularity layer of the
Eclipse Rich Client Platform (RCP) underscores the inroads that OSGi
technology has made. Further, the announcement of JSR 277 verifies that
demand for modularity in Java has reached a critical point.

This project can serve the greater Java open source community by
providing immediate modularity support for Java applications today
through the OSGi framework, creating a unifying community around open
source OSGi technology, and tracking and participating in the progression
of JSR 277.


Proposal


We propose the creation of a new Apache project, Oscar, that will achieve
the following goals :

1) create a compliant, independent implementation of the OSGi R4 core
  framework with framework-dependent services under the Apache License,
  Version 2.0.

2) unify resources from the OSGi community to implement, document, maintain,
  and support standard OSGi R4 services.

3) provide a focal point for the OSGi community to develop interfaces, APIs,
  and other common needs not fully specified by the OSGi R4 specification,
  such as store interfaces, aspects of the runtime container's packaging
  and configuration, and the design and behavior of bundle repositories.
  
4) provide a focal point for the open-source OSGi community to develop next

  generation enhancements to the core framework and act as a conduit for
  the open-source community to the OSGi Alliance.
  
5) evangelize the OSGi Service Platform within Apache and provide documentation

  and support for successful container migrations.


Starting Participants
-

We propose that the following people are considered the starting participants.
We hope to start with a diverse cross-section of the community and preserve
this as we grow. The information in parenthesis indicates other community
participation or relevant experiences of that individual.

These individuals have expressed an interest in participating in the
architecture and design work and in participating as committers for the
Apache-licensed implementation :

  Richard Hall (OSGi Alliance (Invited Researcher) and Founder of the Oscar 
project)
  Alex Karasulu (Apache)
  Enrique Rodriguez (Apache)
  Trustin Lee (Apache)

These individuals will participate as Incubator Mentors :

  Alex Karasulu (Apache)

The following Apache Members will be the sponsoring members :

  Alex Karasulu (Apache)
  Noel Bergman (Apache)
  Carsten Ziegeler (Apache)
  Berin Loritsch (Apache)

The following community members support this effort :

  Daniel Fagerstrom (Apache)
  Niclas Hedhman (Apache)
  Peter Kriens (OSGi Alliance (Director of Technology) and Managing Director, 
aQute)
  Reinhard Poetz (Apache)
  Stefano Mazzocchi (Apache)
  Marcel Offermans (+2 others, Luminis)
  Rob Walker (Ascert, LLC)
  Gerald Friedland (Researcher, Freie Universität Berlin, E-Chalk Project)
  Timothy Bennett (Apache and Metro Government of Nashville/Davidson County)
  Juan Alonso (Independent)
  Stéphane Frénot (Associate Professor, INSA-Lyon/INRIA)
  Humbe

Re: DirectoryGenerator using abstract Source

[Joerg Heinicke]

On 14.07.2005 10:59, Gianugo Rabellino wrote:


Don't want to rain on the party, but this has been exactly the kind of
discussion that led nowhere a couple years ago.


Sorry for that ...


I'm now convinced that
File/DirectoryGenerator are there to stay, there is just too much
stuff depending on it. Apart from naming issues (beware the bikeshed
effect), my take would be:

1. move TraversableGenerator to src/core,


+1


deprecate DirectoryGenerator leaving it untouched


Read below.


2. insert some log.xxx("DG is now deprecated, please use TG instead"),
where "xxx" is promoted from debug to error in a few release cycles

3. optionally start introducing XMLGenerator the same way (though the
only path I can foresee is via c&p)

In any case, avoid "extends" like the plague. If anything, the hassle
we're going to have because of that bunch of generators extending DG
should prove how extends can be harmful. Actually, it might be worth
thinking about refactoring the whole stuff using composition.


Yeah, I know: "prefer composition over inheritance". And it might 
improve the DGs we have. But when we make DG extending TG just for a 
naming issue I see no advantage in composition and adding so many 
delegating methods.


And why do you want to leave DG untouched at all? Couldn't TG do the same?

Regarding 3.: +1 for doing it the same way - what ever we will decide.

Joerg

RefDoc Direction

[Robert Graham]

Hi All,

This is mostly a question for the mentors on the project, but ideas
are welcome. I posted to dev mostly to have it backed up.

I've been through the prototype code and I've even gotten a couple of
the TODO's taken care of (specifically the matching multiple key-value
pairs and most of a refactoring of slop/xml-to-snippets.xsl). I'm not
sure how to accomplish the selecting of multiple codebases, but I'm
interested in ideas. I thought we should make a minor change to the
doktor comment syntax in adding commas between key-value pairs to make
it more reasonable to process. Past all that I'm looking for a little
more direction. I understand the goal and the prototype as it is, but
I'm a little confused as to the next step.

Thanks,
Robert

Re: [OT] Top 10 things to do in Stuttgart

[Jochen Kuhnle]

Upayavira <[EMAIL PROTECTED]> wrote on 14.07.2005 15:31:11:

> Thanks for this nice little (or not so little) list :-)
> 
> Do you mind if I push this out a little more widely, so that non-Cocoon 
> Apache people can see it? On the slight-offchance that people might have 

> time to do something other than techie stuff and drink beer, it might be 

> useful :-)
> 
> Regards, Upayavira

Not at all. Please do whatever you want with the list. Although you might 
add this disclaimer: Warning! I do NOT suggest in any way that visiting a 
"Biergarten" implies that you have to drink beer there ;)

Regards,
Jochen

DO NOT REPLY [Bug 35741] New: - [Link] iHOP - Information Hyperlinked over Proteins

[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=35741

   Summary: [Link] iHOP - Information Hyperlinked over Proteins
   Product: Cocoon 2
   Version: Current SVN 2.1
  Platform: Other
   URL: http://www.pdg.cnb.uam.es/UniPub/iHOP/
OS/Version: All
Status: NEW
  Severity: enhancement
  Priority: P2
 Component: Documentation
AssignedTo: dev@cocoon.apache.org
ReportedBy: [EMAIL PROTECTED]


Version used: Cocoon 2.17

---
Summary
iHOP (Information Hyperlinked over Proteins) is a public information system for
the biomedical sciences, providing the network of gene synonyms as a mean of
navigating the scientific literature. 
By employing genes and proteins as hyperlinks between sentences and abstracts,
the information in PubMed (National Library of Medicine) can be converted into
one navigable resource. This way the information in more than twelve million
abstracts in PubMed can be converted into one small world that brings all
advantages of the internet to scientific literature research.
The current network provided in iHOP contains two million sentences and 3
different genes from human, mouse, fly, worm, fish, plants and yeast.

Hoffmann, R., Valencia, A. A Gene Network for Navigating the Literature. Nature
Genetics 36, 664 (2004)
---

Additional Technical information

Underlying data
In a process previous to the web application, genes and proteins and MeSH terms
(biomedical thesaurus) are identified in about 12 million biomedical abstracts
from PubMed. Of a total number of 20 genes, about 3 genes were
identified in 2 million abstracts.
Starting from this index, 1 XML document was created for each abstract, 1 for
each gene and 2 different xml documents for each of the gene in the literature.
Thus the total number of different XML documents is around 2.3 million. 
These documents essentially contain the original text divided into individual
sentences with gene synonyms, MeSH terms, and verbs tagged. Gene documents also
contain general information, such as database references, synonyms, and a list
of homologous genes, which in the web application are used to provide links to
external resources.

Web application
The web application currently consists of the data in 2.3 million XML-documents,
33 XSP scripts and 37 different transformation style sheets for all the
different views on the gene and abstract data. 
Dynamic effects are achieved through the HTML and JavaScript layer on the client
side to minimize server load and to avoid complex front-end database queries.
This way, extremely fast response times are obtained and multiple concurrent
usage of the system is possible.

---

* How can we verify this site is actually built with Cocoon?
Calling an inexistent page, e.g.
"http://www.pdg.cnb.uam.es/UniPub/iHOP/nil/anything";, will lead to the Cocoon
error message.
Credit is given to the Cocoon project on the first page of iHOP. 

* How much time did it take to build the site from design to publication?
16 month

* How many people were involved in the project?
Just me.

* How much traffic does the site handle?
Around 1 different IPs per day.

* What made you choose Cocoon to build the site?
The book "Java and XML by Brett McLaughlin. The perfect separation between lots
of fairly stable data in XML and it's everchanging HTML representation.

* What other information do you want to disclose (e.g. how does it work, how did
you build it, what parts of Cocoon did you use)?
See technical information. 

* Contact 
Robert Hoffmann
Memorial Sloan-Kettering Cancer Center, MSKCC
[EMAIL PROTECTED], http://www.cbio.mskcc.org/~hoffmann/

-- 
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.

[cforms] event handler called twice?

[Max Pfingsthorn]

Hi!

I'm having a little trouble with the flowscript event handlers (previous 
problem is solved, by the way). Somehow, the code gets called twice, once with 
a valid value, once with null as a value. Any ideas why?

Best regards,

Max Pfingsthorn

Hippo  

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

Re: [OT] Top 10 things to do in Stuttgart

[John L. Webber]

Hi Jochen,

After 3 Mass Bier, do you think anyone will still be up for volleyball? ;-)

John (who lives in Munich and frequents the Biergärten there)

Jochen Kuhnle wrote:
> Hi,
> 
> 3. Have a "Mass" (1 Litre of Beer) at the "Biergarten im Schlossgarten": 
> This is where the crowd is when the weather's good.
> 
>http://www.biergarten-schlossgarten.de/
> 
> 4. Have another "Mass" at the "Karlshöhe": Very nice view over western 
> Stuttgart, nice to walk up there.
> 
>http://www.stuttgarter-nachrichten.de/stn/page/detail.php/16710
> 
> 5. Take a bike through Killesberg Park, Rosenstein Park and Schlossgarten 
> back to the city centre. You have to push the bike through Killesberg Park 
> (no cycling there), but afterwards its a nice downhill ride to Rosenstein. 
> There is also a nice "Biergarten" between Killesberg and Rosenstein Park 
> near Pragsattel where you might have yet another "Mass". Takes 1.5 hours.
> 
> 6. Go to the beach at "Sky beach". Trendy "beach" bar on top of a parking 
> garage, volleyball field included (though you have to go down 5 storeys if 
> you kick the ball over the side ;).
> 
>http://www.skybeach.de/

Re: [OT] Top 10 things to do in Stuttgart

[Upayavira]

Thanks for this nice little (or not so little) list :-)

Do you mind if I push this out a little more widely, so that non-Cocoon 
Apache people can see it? On the slight-offchance that people might have 
time to do something other than techie stuff and drink beer, it might be 
useful :-)


Regards, Upayavira

Jochen Kuhnle wrote:

Hi,

for everyone going there, here are a few suggestions, in no particular 
order, and of course highly biased:


1. Visit the "Fernsehturm" (TV-Tower): Touristy, but nice view.

   http://www.fernsehturm-stuttgart.de/index_en.html

2. Eat suabian food at the "Stuttgarter Stäffele": Slightly expensive but 
good, book ahead.


   http://www.staeffele.de/

3. Have a "Mass" (1 Litre of Beer) at the "Biergarten im Schlossgarten": 
This is where the crowd is when the weather's good.


   http://www.biergarten-schlossgarten.de/

4. Have another "Mass" at the "Karlshöhe": Very nice view over western 
Stuttgart, nice to walk up there.


   http://www.stuttgarter-nachrichten.de/stn/page/detail.php/16710

5. Take a bike through Killesberg Park, Rosenstein Park and Schlossgarten 
back to the city centre. You have to push the bike through Killesberg Park 
(no cycling there), but afterwards its a nice downhill ride to Rosenstein. 
There is also a nice "Biergarten" between Killesberg and Rosenstein Park 
near Pragsattel where you might have yet another "Mass". Takes 1.5 hours.


   http://www.killesberg-stuttgart.de/
   http://www.stuttgarter-zeitung.de/stz/page/detail.php/16660
   
http://www.killesberg-kleinbahn.de/Downloads/schul_ausflug_killesberg.pdf


6. Go to the beach at "Sky beach". Trendy "beach" bar on top of a parking 
garage, volleyball field included (though you have to go down 5 storeys if 
you kick the ball over the side ;).


   http://www.skybeach.de/

7. Visit "Städtisches Lapidarium": A bit of old Stuttgart -- garden with 
parts (portals, colums, etc.) of old buildings.


   http://www.stuttgart-tourist.de/deutsch/stuttgart/sehen/lapidarium.html

8. Visit Weissenhof-Siedlung: If you like Bauhaus architecture...
 
   http://en.wikipedia.org/wiki/Bauhaus


9. Visit Wilhelma: Botanical garden & zoo, one of the nicest. You need 
time to do this.


   http://www.wilhelma.de/

10. Mercedes Benz and Porsche museums: For the car buffs. I think both 
companies are building new ones right now, so call ahead and ask if 
they're open.



http://www.mercedes-benz.com/mbcom/international/international_website/en/com/international_home/home/services/meetus/museum.html

http://content2.eu.porsche.com/prod/service/classic.nsf/usaenglish/worldmuseum
 


Have fun!

Regards,
Jochen

[OT] Top 10 things to do in Stuttgart

[Jochen Kuhnle]

Hi,

for everyone going there, here are a few suggestions, in no particular 
order, and of course highly biased:

1. Visit the "Fernsehturm" (TV-Tower): Touristy, but nice view.

   http://www.fernsehturm-stuttgart.de/index_en.html

2. Eat suabian food at the "Stuttgarter Stäffele": Slightly expensive but 
good, book ahead.

   http://www.staeffele.de/

3. Have a "Mass" (1 Litre of Beer) at the "Biergarten im Schlossgarten": 
This is where the crowd is when the weather's good.

   http://www.biergarten-schlossgarten.de/

4. Have another "Mass" at the "Karlshöhe": Very nice view over western 
Stuttgart, nice to walk up there.

   http://www.stuttgarter-nachrichten.de/stn/page/detail.php/16710

5. Take a bike through Killesberg Park, Rosenstein Park and Schlossgarten 
back to the city centre. You have to push the bike through Killesberg Park 
(no cycling there), but afterwards its a nice downhill ride to Rosenstein. 
There is also a nice "Biergarten" between Killesberg and Rosenstein Park 
near Pragsattel where you might have yet another "Mass". Takes 1.5 hours.

   http://www.killesberg-stuttgart.de/
   http://www.stuttgarter-zeitung.de/stz/page/detail.php/16660
   
http://www.killesberg-kleinbahn.de/Downloads/schul_ausflug_killesberg.pdf

6. Go to the beach at "Sky beach". Trendy "beach" bar on top of a parking 
garage, volleyball field included (though you have to go down 5 storeys if 
you kick the ball over the side ;).

   http://www.skybeach.de/

7. Visit "Städtisches Lapidarium": A bit of old Stuttgart -- garden with 
parts (portals, colums, etc.) of old buildings.

   http://www.stuttgart-tourist.de/deutsch/stuttgart/sehen/lapidarium.html

8. Visit Weissenhof-Siedlung: If you like Bauhaus architecture...
 
   http://en.wikipedia.org/wiki/Bauhaus

9. Visit Wilhelma: Botanical garden & zoo, one of the nicest. You need 
time to do this.

   http://www.wilhelma.de/

10. Mercedes Benz and Porsche museums: For the car buffs. I think both 
companies are building new ones right now, so call ahead and ask if 
they're open.


http://www.mercedes-benz.com/mbcom/international/international_website/en/com/international_home/home/services/meetus/museum.html

http://content2.eu.porsche.com/prod/service/classic.nsf/usaenglish/worldmuseum
 

Have fun!

Regards,
Jochen

[cforms] convenience functions in flowscript event handlers?

[Max Pfingsthorn]

Hi!

I'm getting to know cforms better everyday and I am very impressed. Currently, 
I am implementing a translation from schema to cforms. One constraint, which is 
already taken care of in cforms, is event handling. However, since I 
autogenerate widget IDs, I need to abstract the calls to 
event.source.lookupWidget() to include transformation of the names. Is there 
any way how I can define those convenience functions (e.g. 
lookup(event,'../../some/path')) once and use them in those flowscript snippets 
in , for example? Can I just include them in the sitemap 
like usual or are those scripts run in a different context?

Best regards,

Max Pfingsthorn

Hippo  

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

Re: DirectoryGenerator using abstract Source

[Daniel Fagerstrom]

Gianugo Rabellino wrote:


On 7/14/05, Joerg Heinicke <[EMAIL PROTECTED]> wrote:
 


Michael Wechner  wyona.com> writes:
   


Wow, 2 years ago! And what about starting a real migration now by
starting with the unclean way (DirectoryG extends TraversableG with
old namespace and directory/file metaphore as you wrote it),
deprecating it at the same time and making the TraversableG the
officially supported one?
   


just one note re such a migration. Wouldn't it make sense to actually
"rename" the TraversableGenerator to CollectionGenerator and introduce
something like
ResourceGenerator (or does that exist already?) and do

  DirectoryGenerator extends CollectionGenerator
  FileGenerator extends ResourceGenerator

such that the terminology is consistent?
 


For the FileGenerator I have another name in mind since a long time:
XMLGenerator. This would make it consistent with HTMLGenerator and nearly any
else generator too. From where the XML is read is independent on the generator
itself, but only depends on the source provided via @src in sitemap. Having this
in mind ResourceGenerator is not the best name possible IMO and will continue
the irritating naming.
   



Don't want to rain on the party, but this has been exactly the kind of
discussion that led nowhere a couple years ago. I'm now convinced that
File/DirectoryGenerator are there to stay, there is just too much
stuff depending on it. Apart from naming issues (beware the bikeshed
effect), my take would be:

1. move TraversableGenerator to src/core, deprecate DirectoryGenerator
leaving it untouched

2. insert some log.xxx("DG is now deprecated, please use TG instead"),
where "xxx" is promoted from debug to error in a few release cycles

3. optionally start introducing XMLGenerator the same way (though the
only path I can foresee is via c&p)
 

I don't think it is a good idea to deprecate things that have been 
arround in Cocoon from the very beginning and is part of about every 
book, tutorial and article that have been written about Cocoon.


If they where considered harmfull in some way, hard to maintain or was 
in the way for developing new important stuff I would agree in 
deprecating them. But I don't see that it is the case.


A much better way to handle old stuff where we have found better ways of 
achieving what they are intended for is IMO doing like we did for XSP, 
remove it from core and move it to a block.


For the DirectoryGenerator we could have a certain DirectoryGenerator 
block, or put it together with some other "obsololete" stuff that belong 
together in some way in a block. Or we could have an 
"backcompability2.1" block, with everything that we find old fashoned 
and want to move away from core.



In any case, avoid "extends" like the plague. If anything, the hassle
we're going to have because of that bunch of generators extending DG
should prove how extends can be harmful.


I don't follow you here, care to expand on it?


Actually, it might be worth
thinking about refactoring the whole stuff using composition.
 


So, what parts are you considering for the composition?

/Daniel

Re: DirectoryGenerator using abstract Source

[Gianugo Rabellino]

On 7/14/05, Joerg Heinicke <[EMAIL PROTECTED]> wrote:
> Michael Wechner  wyona.com> writes:
> 
> > > Wow, 2 years ago! And what about starting a real migration now by
> > > starting with the unclean way (DirectoryG extends TraversableG with
> > > old namespace and directory/file metaphore as you wrote it),
> > > deprecating it at the same time and making the TraversableG the
> > > officially supported one?
> >
> > just one note re such a migration. Wouldn't it make sense to actually
> > "rename" the TraversableGenerator to CollectionGenerator and introduce
> > something like
> > ResourceGenerator (or does that exist already?) and do
> >
> >DirectoryGenerator extends CollectionGenerator
> >FileGenerator extends ResourceGenerator
> >
> > such that the terminology is consistent?
> 
> For the FileGenerator I have another name in mind since a long time:
> XMLGenerator. This would make it consistent with HTMLGenerator and nearly any
> else generator too. From where the XML is read is independent on the generator
> itself, but only depends on the source provided via @src in sitemap. Having 
> this
> in mind ResourceGenerator is not the best name possible IMO and will continue
> the irritating naming.

Don't want to rain on the party, but this has been exactly the kind of
discussion that led nowhere a couple years ago. I'm now convinced that
File/DirectoryGenerator are there to stay, there is just too much
stuff depending on it. Apart from naming issues (beware the bikeshed
effect), my take would be:

1. move TraversableGenerator to src/core, deprecate DirectoryGenerator
leaving it untouched

2. insert some log.xxx("DG is now deprecated, please use TG instead"),
where "xxx" is promoted from debug to error in a few release cycles

3. optionally start introducing XMLGenerator the same way (though the
only path I can foresee is via c&p)

In any case, avoid "extends" like the plague. If anything, the hassle
we're going to have because of that bunch of generators extending DG
should prove how extends can be harmful. Actually, it might be worth
thinking about refactoring the whole stuff using composition.

Ciao,

-- 
Gianugo Rabellino
Pro-netics s.r.l. -  http://www.pro-netics.com
Orixo, the XML business alliance: http://www.orixo.com
(blogging at http://www.rabellino.it/blog/)

Re: DirectoryGenerator using abstract Source

[Joerg Heinicke]

Michael Wechner  wyona.com> writes:

> > Wow, 2 years ago! And what about starting a real migration now by 
> > starting with the unclean way (DirectoryG extends TraversableG with 
> > old namespace and directory/file metaphore as you wrote it), 
> > deprecating it at the same time and making the TraversableG the 
> > officially supported one?
> 
> just one note re such a migration. Wouldn't it make sense to actually 
> "rename" the TraversableGenerator to CollectionGenerator and introduce 
> something like
> ResourceGenerator (or does that exist already?) and do
> 
>DirectoryGenerator extends CollectionGenerator
>FileGenerator extends ResourceGenerator
> 
> such that the terminology is consistent?

For the FileGenerator I have another name in mind since a long time:
XMLGenerator. This would make it consistent with HTMLGenerator and nearly any
else generator too. From where the XML is read is independent on the generator
itself, but only depends on the source provided via @src in sitemap. Having this
in mind ResourceGenerator is not the best name possible IMO and will continue
the irritating naming.

Joerg

typo for mime-type image[s]/gif -- might be wise to check docos

[Marc Portier]

funny,

noticed some strange behaviour in firefox the other day on gif's
returned by cocoon

turns out that a typo in the mime-type for gifs over at
src/webapp/sitemap.xmap was causing it

it says images/gif versus image/gif
(see http://www.iana.org/assignments/media-types/ )

I can't really explain why we haven't noticed this earlier (or did we?)
but the typo surely made it's cut-and-paste way through our code-base
(see below) and documentation (see google)

> 
> [EMAIL PROTECTED]:~/projects/apache/cocoon$ find src -name sitemap.xmap | 
> xargs grep -l "images/gif"
> src/blocks/faces/trunk/samples/cardemo/sitemap.xmap
> src/blocks/forms/trunk/samples/dreamteam/sitemap.xmap
> src/blocks/petstore/trunk/samples/sitemap.xmap
> src/webapp/sitemap.xmap

luckily:
> [EMAIL PROTECTED]:~/projects/apache/cocoon$ find src -name sitemap.xmap | 
> xargs grep -l "image/gif"
> src/blocks/lucene/trunk/samples/sitemap.xmap
> src/blocks/scratchpad/trunk/samples/sitemap-viewer/sitemap.xmap
> src/blocks/scratchpad/trunk/samples/othello/sitemap.xmap
> src/blocks/mail/trunk/samples/mail/sitemap.xmap
> src/blocks/portal/trunk/samples/sitemap.xmap
> src/blocks/slop/trunk/samples/yapt/sitemap.xmap
> src/webapp/samples/aggregation/sitemap.xmap
> src/webapp/samples/catalog/sitemap.xmap
> src/webapp/samples/i18n/sitemap.xmap
> src/webapp/samples/modules/sitemap.xmap
> src/webapp/samples/sites/sitemap.xmap


I'll take care of the sitemap.xmap files that need fixing on trunk and
2_1_x branch in svn, please be all invited to track occurances in our
docos as well

regards,
-marc=
-- 
Marc Portierhttp://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog athttp://blogs.cocoondev.org/mpo/
[EMAIL PROTECTED]  [EMAIL PROTECTED]

Re: DirectoryGenerator using abstract Source

[Michael Wechner]

Joerg Heinicke wrote:


On 13.07.2005 23:38, Gianugo Rabellino wrote:


DirectoryGenerator extends TraversableGenerator



We've been through this before:

http://marc.theaimsgroup.com/?t=10578281593&r=1&w=2

In a word: backward compatibility.



Wow, 2 years ago! And what about starting a real migration now by 
starting with the unclean way (DirectoryG extends TraversableG with 
old namespace and directory/file metaphore as you wrote it), 
deprecating it at the same time and making the TraversableG the 
officially supported one?



just one note re such a migration. Wouldn't it make sense to actually 
"rename" the TraversableGenerator to CollectionGenerator and introduce 
something like

ResourceGenerator (or does that exist already?) and do

  DirectoryGenerator extends CollectionGenerator
  FileGenerator extends ResourceGenerator

such that the terminology is consistent?

Michi



Joerg




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