Bug 33794

i agree with your assessment. if you are prepared to move these to lenya and
change the pipelines accordingly, i will remove them from kupu.

(In reply to comment #1)
> i agree with your assessment. if you are prepared to move these to lenya and
> change the pipelines accordingly, i will remove them from kupu.

I'd just like to think a bit about where to put it. I mean the directory
structure. I would like to try to prepare for moving Kupu to a kind of block if
possible. I wonder if that would have an impact on the directory structure.

(In reply to comment #2)

> I'd just like to think a bit about where to put it. I mean the directory
> structure. I would like to try to prepare for moving Kupu to a kind of block if
> possible. I wonder if that would have an impact on the directory structure.

bxe related things are under resources/misc/bxe, so resources/misc/kupu makes a
lot of sense.  

(In reply to comment #3)

> bxe related things are under resources/misc/bxe, so resources/misc/kupu makes a
> lot of sense.  

I don't like the "misc" in there. But its not consequently used anyway. See 

find . -name bxe -print
./lenya/pubs/blog/resources/misc/bxe
./lenya/pubs/default/resources/misc/bxe
./lenya/xslt/bxe
./lenya/resources/bxe
./lenya/resources/misc/bxe

Also one thing is where we put our stuff (the Lenya artifacts) and where to put
the kupu tree. For the Lenya artifacts, I wonder if this should be

lenya/resources/kupu/xslt or just

lenya/xslt/kupu

I mean, what exactly is "resources"? Sometimes we use it to store pretty static
stuff that get's served like images, css, etc. And then in other places we put
xslts under resources.

I am thinking of 

$LENYA_WEBAPP/external/...

such as 

$LENYA_WEBAPP/external/kupu
$LENYA_WEBAPP/external/bxe
$LENYA_WEBAPP/external/foo

as the place to link external reositories. This would make it quite clear.

On the other hand, the integration between Kupu and Lenya is a two-way street.
Kupu provides stuff to Lenya but Lenya also provides stuff to Kupu. This needs
to go somewhere as well.

How about 

$LENYA_WEBAPP/export/kupu

for this kind of stuff?

The convention would be:

- Whatever is in $LENYA_WEBAPP/export is stuff which Lenya provides to plugins.
- Whetever is in $LENYA_WEBAPP/external does not come from the Lenya developers
but from a 3rd party

(In reply to comment #4)

the reason why it is in misc is because resources/kupu and resources/bxe are
taken by svn:external already (for the checkout)

i don't think we should do a "moving stuff around" excercise at this point.

(In reply to comment #5)
> i don't think we should do a "moving stuff around" excercise at this point.

Why?
We will get a much clearer structure that way.
It's easier to do it know then it will be at a later point in time.
I would have to touch all the references anyway as the apache-lenya folder has 
to move, as we agreed upon.

(In reply to comment #6)
> (In reply to comment #5)
> > i don't think we should do a "moving stuff around" excercise at this point.
> 
> Why?
> We will get a much clearer structure that way.
> It's easier to do it know then it will be at a later point in time.
> I would have to touch all the references anyway as the apache-lenya folder has 
> to move, as we agreed upon.

we did a big directory structure reorg between 0.8 and 1.0. while it has
improved things (see
http://cvs.apache.org/viewcvs.cgi/cocoon-lenya/src/webapp/lenya/pubs/docs/content/live/bas-dir.xml?hideattic=0&rev=1.3&view=markup
to get a taste how it used to be..), we were never able to put files into the
one right place. whether you order them by file type, purpose or another
criteria, you'll always find cases that do not fit.

and trying to find the perfect directory structure is bikeshedding in my opinion
while incurring unnecessary migration costs at the same time.

so in summary, i do not believe that a new structure is sufficiently better to
justify the costs of migration.

i started to port the kupu usecase to the usecase framework. there is now a
editors.kupu.Kupu class, but the view still needs to be changed (taking the
concerns in this thread into account), the usecase name needs to be changed from
kupu to edit.kupu, all menus need to be changed to reflect that

*** Bug 37978 has been marked as a duplicate of this bug. ***

i see that we now have a kupu module, but the kupu usecase that gets actually
registered is still the one in usecases/edit/kupu/kupu.jx.
what's the state of kupu modularization? i think it should be done before 1.4
goes out.

with the addition of jonathan's patch, all kupu resources are now in the kupu
module. (see bug 39890)
all that's left to do is port kupu to use the 1.4 usecase framework. but i'm not
sufficiently interested in kupu to try that. afaic, legacy code is ok as long as
it's self-contained and does not clutter global namespaces, sitemaps etc.
hence, i'm reducing the severity to "minor". change back if you disagree.

(In reply to comment #0)
> The XSL and HTML stuff for Kupu integration which lives in the apache-lenya
> directory of the Kupu SVN needs to be moved to the Lenya-SVN. There are several
> reasons:
> 
> 1. It's cleaner. If someone is using Kupu without Lenya why should he have this
> lying around?
> 2. The stuff in that directory is specific to a Lenya version. For example, page
> envelope parameter names have changed in Lenya from 1.2 to 1.4. As some of these
> parameters are used in there as well we need separate versions for 1.2 and 1.4
> (example: node-id versus document-name).

Are these original concerns addressed?

i'm moving this out of the 1.4 queue. we should address that some time, but not
necessarily now.

Kupu will not be supported in future versions.