You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lenya.apache.org by Michael Wechner <mi...@wyona.com> on 2006/02/22 22:25:29 UTC
Requirements and Dependencies
Hi
I think we should extend the build process (but also hot pluggable
in a second phase) that requirements and dependencies of each
publication are being checked.
E.g. if a publication is dependent on the module "atom-entry" and
this module has not been referenced, then an error should be thrown.
Or if a publication is based on Cocoon 2.1.8, but the build is being
done on Cocoon-2.1.9-dev then also an error should be thrown.
This way we are able to reduce questions and time consuming debugging
for something actual obvious.
WDYT?
Michi
--
Michael Wechner
Wyona - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
michael.wechner@wyona.com michi@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Requirements and Dependencies
Posted by Michael Wechner <mi...@wyona.com>.
Gregor J. Rothfuss wrote:
> Michael Wechner wrote:
>
>> Hi
>>
>> I think we should extend the build process (but also hot pluggable
>> in a second phase) that requirements and dependencies of each
>> publication are being checked.
>>
>> E.g. if a publication is dependent on the module "atom-entry" and
>> this module has not been referenced, then an error should be thrown.
>
>
> it might be possible to use the mavenized cocoon 2.2 for this. i tried
> to run lenya under cocoon 2.2 about a year ago, it worked reasonably
> well. given that 1.4 is still a fair bit away, why not base it on 2.2?
I am not talking about downloading stuff automatically, but to validate
the dependencies and requirements, which is not exactly the
same thing, whereas introducing Maven does certainly make sense. But I
am talking something similar to Gump.
I don't think Lenya 1.4 is very far away, whereas I cannot say that for
Cocoon 2.2, so I don't think it's a good
idea to base Lenya 1.4 on Cocoon 2.2
Michi
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
> For additional commands, e-mail: dev-help@lenya.apache.org
>
>
--
Michael Wechner
Wyona - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
michael.wechner@wyona.com michi@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Requirements and Dependencies
Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
Michael Wechner wrote:
> Hi
>
> I think we should extend the build process (but also hot pluggable
> in a second phase) that requirements and dependencies of each
> publication are being checked.
>
> E.g. if a publication is dependent on the module "atom-entry" and
> this module has not been referenced, then an error should be thrown.
it might be possible to use the mavenized cocoon 2.2 for this. i tried
to run lenya under cocoon 2.2 about a year ago, it worked reasonably
well. given that 1.4 is still a fair bit away, why not base it on 2.2?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Requirements and Dependencies
Posted by Andreas Hartmann <an...@apache.org>.
Andreas Hartmann wrote:
> Michael Wechner wrote:
>> solprovider@apache.org wrote:
>>
>>> On 2/22/06, Michael Wechner <mi...@wyona.com> wrote:
>>>
>>>
>>>> I think we should extend the build process (but also hot pluggable
>>>> in a second phase) that requirements and dependencies of each
>>>> publication are being checked.
[...]
> Before building our own dependency resolving mechanism, I'd rather
> review the Cocoon block concept again (maybe they allow external
> blocks by now) and convert modules to blocks if this is appropriate.
I played a little with Cocoon blocks and Gump:
- added 2 gump.xml patch files to declare the Lenya core and a module
as blocks, declaring the dependency from module to core
- changed the directory structure a little (locations of java files and
libraries)
- removed circular dependencies (moved some classes from the core to the
sitetree module), otherwise the build would fail
I got the Cocoon build to compile our stuff as blocks and apply the
xpatch files to cocoon.xconf etc. It would be necessary to extend our
build process to copy the gump.xml patch files to Cocoon, but we already
do this with the local.*.properties.
I'll do some more investigation and report again.
-- Andreas
--
Andreas Hartmann
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
andreas.hartmann@wyona.com andreas@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Requirements and Dependencies
Posted by Michael Wechner <mi...@wyona.com>.
solprovider@apache.org wrote:
>If Modules can contain Java, then:
>1. Every Lenya Developer must have a development environment.
>2. We have the dependency issues that started this thread.
>I cannot see how it is good to force Users to install a development
>environment. It increases the complexity and reduces the audience.
>Lenya should become both easier and more powerful. Modules including
>Java that needs to be compiled is a step in the wrong direction.
>
>
I am using vi and ant ;-)
I think modules are just a way of grouping stuff in a structured way.
Michi
>solprovider
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
>For additional commands, e-mail: dev-help@lenya.apache.org
>
>
>
>
--
Michael Wechner
Wyona - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
michael.wechner@wyona.com michi@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Requirements and Dependencies
Posted by so...@apache.org.
On 2/27/06, Andreas Hartmann <an...@apache.org> wrote:
> solprovider@apache.org wrote:
> > http://lenya.apache.org/1_4/reference/modules/index.html
> > suggests that Modules will be able to add protocols. Protocols are
> > part of the platform and should not be added dynamically. Anyone
> > adding a protocol would have a development environment.
> Yes, but this doesn't mean that adding Java code to modules
> is a bad thing, does it?
>
> > Lenya has been usable and very flexible without a development
> > environment. A binary version of Lenya is very flexible. I realize
> > that most Committers and some Developers have a development
> > environment, but most Developers do not, and should not, need one.
> >
> > If Modules can contain Java, then:
> > 1. Every Lenya Developer must have a development environment.
> I don't understand this implication. You're not required to
> add Java code to your modules.
Good.
> > 2. We have the dependency issues that started this thread.
> Yes, they have to be solved.
Just have the ClassNotFound Exception open the "Sorry" page and add a
line to the log in any Class that could look for code in a Module.
Each of those Classes needs to be documented to explain how the hook
for Module code works. Will loading a Module dynamically add to the
information read from WEB-INF/cocoon.xconf? (That may be the central
place to check for ClassNotFound.)
> > I cannot see how it is good to force Users to install a development
> > environment.
> We're not forcing anyone. We're allowing to use Java.
Good.
> > It increases the complexity and reduces the audience.
> It allows modularization. We have to break up our monolithic
> core into modules, otherwise we'll end up with too many
> connections between components and circular dependencies.
> If we don't allow Java code in modules, people will start to
> implement their stuff using server pages and other suboptimal
> technologies.
I am migrating my Lenya1.2.2 publication to use my interpretation of
Modules. I moved most of the XMAPs into the Modules, fixed the URLs,
and added a module: protocol. Tonight's work will be to add template
inheritance to the module: protocol. Then I will move the rest of the
files into the Modules, and separate parts of the "live" Module into
"authoring" and "xhtml" Modules.
I have not found any function that required or could be improved with
Java, but my Publication could be too simple to need it.
One concern is Cocoon already has a "module:" protocol, which my
version overrides. I could not find anything in Lenya that used the
Cocoon protocol (and Lenya still works), but this could cause problems
for Cocoon users that are migrating to Lenya. Opinions?
> > Lenya should become both easier and more powerful. Modules including
> > Java that needs to be compiled is a step in the wrong direction.
> I disagree.
(Hoping you are not disagreeing with the first sentence) You have
answered my objections.
Thank you,
solprovider
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Requirements and Dependencies
Posted by Doug Chestnut <dh...@virginia.edu>.
Andreas Hartmann wrote:
> solprovider@apache.org wrote:
>
> [...]
>
>> Lenya should become both easier and more powerful. Modules including
>> Java that needs to be compiled is a step in the wrong direction.
>
>
> I disagree.
same here. modules and usecases in 1.4 (along with pub templating) are
very easy to use. By using java one can work with the lenya api easier,
and the modularization removes the conflicts (no core customization
needed) from my "svn up" in the lenya directory. Java is a breeze to
debug as well ;).
One can still "roll your own" in the 1.4 module, so it should be fairly
easy to port 1.2 customizations.
--Doug
>
> -- Andreas
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Requirements and Dependencies
Posted by Andreas Hartmann <an...@apache.org>.
solprovider@apache.org wrote:
[...]
> http://lenya.apache.org/1_4/reference/modules/index.html
> suggests that Modules will be able to add protocols. Protocols are
> part of the platform and should not be added dynamically. Anyone
> adding a protocol would have a development environment.
Yes, but this doesn't mean that adding Java code to modules
is a bad thing, does it?
> Lenya has been usable and very flexible without a development
> environment. A binary version of Lenya is very flexible. I realize
> that most Committers and some Developers have a development
> environment, but most Developers do not, and should not, need one.
>
> If Modules can contain Java, then:
> 1. Every Lenya Developer must have a development environment.
I don't understand this implication. You're not required to
add Java code to your modules.
> 2. We have the dependency issues that started this thread.
Yes, they have to be solved.
> I cannot see how it is good to force Users to install a development
> environment.
We're not forcing anyone. We're allowing to use Java.
> It increases the complexity and reduces the audience.
It allows modularization. We have to break up our monolithic
core into modules, otherwise we'll end up with too many
connections between components and circular dependencies.
If we don't allow Java code in modules, people will start to
implement their stuff using server pages and other suboptimal
technologies.
> Lenya should become both easier and more powerful. Modules including
> Java that needs to be compiled is a step in the wrong direction.
I disagree.
-- Andreas
--
Andreas Hartmann
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
andreas.hartmann@wyona.com andreas@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Requirements and Dependencies
Posted by so...@apache.org.
On 2/24/06, Andreas Hartmann <an...@apache.org> wrote:
> solprovider@apache.org wrote:
> > Are you thinking of them like Cocoon's Input and
> > Output Modules?
> No, rather like Cocoon blocks.
> > Java code that requires compilation for use?
> Yes, they can contain Java code. But dependencies have to be checked
> even if there's no Java code.
> > That
> > sounds much less useful, flexible, and easy to implement or modify
> > than what I was expecting.
> Why?
>
> > I thought Lenya Modules were the evolution of Usecases: one directory
> > under {pub}/modules for each function. The entry point for each is
> > {pub}/modules/{moduleID}/sitemap.xmap. Depending on the purpose and
> > the parameters, Modules return a binary file "Asset", an HTML "Page",
> > or (most often) an XML "Document", all handled with XMAPs, XSL, XSP,
> > XML, and JS. Of course the XMAP can use various Generators,
> > Transformers, Serializers and other stuff compiled from Java, but
> > everything in the Module is interpreted for easy updates.
> No, that's not the way it works at the moment. A module can provide
> Java code and libraries as well, it has to be deployed on compile time.
>
> > With this architecture, inheritance is simply checking the parent
> > templates until each file is found. Most of the "live" Module is at
> > the global level, but "page2xhtml.xsl" can be overridden by each
> > Publication.
> > Is this close to your concept of Modules, or should this
> > implementation still be called Usecases?
> As I understand it, you're describing functionality offered by
> resource types (generating assets / pages), modules (providing
> arbitrary resources and classes), and usecases (classes and templates
> for user interaction). Modules can contain resource types and usecases.
I think I understand the disconnect. In Lenya 1.2, we can add most
functionality simply by adding a Usecase. The Usecase can contain
XMAPs, XSL, XSP, XML, and JS (Flow). We can build complex
applications with those components. I have not found a function that
cannot be implemented with these components. As soon as the hook is
added (usecase-function.xmap), the function is usable. As soon as a
change is made, it is active. None of this requires compiling or
restarting Lenya.
These Usecases depend on the Lenya platform for certain things:
- Generators, Transformers, Serializers and other elements of XMAPs
- Various protocols for retrieving data.
- Some standard functions implemented in XMAPs that could/should be
moved to Usecases.
http://lenya.apache.org/1_4/reference/modules/index.html
suggests that Modules will be able to add protocols. Protocols are
part of the platform and should not be added dynamically. Anyone
adding a protocol would have a development environment.
Lenya has been usable and very flexible without a development
environment. A binary version of Lenya is very flexible. I realize
that most Committers and some Developers have a development
environment, but most Developers do not, and should not, need one.
If Modules can contain Java, then:
1. Every Lenya Developer must have a development environment.
2. We have the dependency issues that started this thread.
I cannot see how it is good to force Users to install a development
environment. It increases the complexity and reduces the audience.
Lenya should become both easier and more powerful. Modules including
Java that needs to be compiled is a step in the wrong direction.
solprovider
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Requirements and Dependencies
Posted by Andreas Hartmann <an...@apache.org>.
solprovider@apache.org wrote:
> On 2/23/06, Andreas Hartmann <an...@apache.org> wrote:
>> solprovider@apache.org wrote:
>>> I am a little confused about how this would work, and doubt any
>>> existing code would handle it properly. The code must check inherited
>>> Templates, and that is a Lenya-specific feature. Three Templates
>>> could have identically named Modules; this Publication only cares
>>> about the Module it inherits.
>> IMO we shouldn't support this, at least not at the moment. I think
>> module dependencies should be resolved during compile time. Publication
>> templating is IMO a runtime concept, at least this is what I had in
>> mind when I implemented the first steps (creating several versions of
>> the same publication, maybe overriding some XSLTs / pipelines)
>> A publication instance shouldn't be allowed to declare additional
>> modules.
>>
>> If we clearly separate compile time dependencies (which could be
>> resolved using Gump) and runtime dependencies (instance -> template)
>> there shouldn't be a problem.
>>
>> As soon as we've got this working properly we can think of adding
>> runtime dependencies (hot-deploying modules, OSGi, ...), but IMO
>> it's too early for that.
>>
>>> Missing modules is a completely different issue. Lenya will run
>>> without a Module.
>> IMO the build should fail if a required module is missing.
>
> I am still confused. I may need to look at how "Lenya Modules" are
> being implemented. Are you thinking of them like Cocoon's Input and
> Output Modules?
No, rather like Cocoon blocks.
> Java code that requires compilation for use?
Yes, they can contain Java code. But dependencies have to be checked
even if there's no Java code.
> That
> sounds much less useful, flexible, and easy to implement or modify
> than what I was expecting.
Why?
> I thought Lenya Modules were the evolution of Usecases: one directory
> under {pub}/modules for each function. The entry point for each is
> {pub}/modules/{moduleID}/sitemap.xmap. Depending on the purpose and
> the parameters, Modules return a binary file "Asset", an HTML "Page",
> or (most often) an XML "Document", all handled with XMAPs, XSL, XSP,
> XML, and JS. Of course the XMAP can use various Generators,
> Transformers, Serializers and other stuff compiled from Java, but
> everything in the Module is interpreted for easy updates.
No, that's not the way it works at the moment. A module can provide
Java code and libraries as well, it has to be deployed on compile time.
> With this architecture, inheritance is simply checking the parent
> templates until each file is found. Most of the "live" Module is at
> the global level, but "page2xhtml.xsl" can be overridden by each
> Publication.
>
> Is this close to your concept of Modules, or should this
> implementation still be called Usecases?
As I understand it, you're describing functionality offered by
resource types (generating assets / pages), modules (providing
arbitrary resources and classes), and usecases (classes and templates
for user interaction). Modules can contain resource types and usecases.
-- Andreas
--
Andreas Hartmann
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
andreas.hartmann@wyona.com andreas@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Requirements and Dependencies
Posted by Renaud Richardet <re...@wyona.com>.
solprovider@apache.org wrote:
>On 2/23/06, Andreas Hartmann <an...@apache.org> wrote:
>
>
>>solprovider@apache.org wrote:
>>
>>
>>>I am a little confused about how this would work, and doubt any
>>>existing code would handle it properly. The code must check inherited
>>>Templates, and that is a Lenya-specific feature. Three Templates
>>>could have identically named Modules; this Publication only cares
>>>about the Module it inherits.
>>>
>>>
>>IMO we shouldn't support this, at least not at the moment. I think
>>module dependencies should be resolved during compile time. Publication
>>templating is IMO a runtime concept, at least this is what I had in
>>mind when I implemented the first steps (creating several versions of
>>the same publication, maybe overriding some XSLTs / pipelines)
>>A publication instance shouldn't be allowed to declare additional
>>modules.
>>
>>If we clearly separate compile time dependencies (which could be
>>resolved using Gump) and runtime dependencies (instance -> template)
>>there shouldn't be a problem.
>>
>>As soon as we've got this working properly we can think of adding
>>runtime dependencies (hot-deploying modules, OSGi, ...), but IMO
>>it's too early for that.
>>
>>
>>
>>>Missing modules is a completely different issue. Lenya will run
>>>without a Module.
>>>
>>>
>>IMO the build should fail if a required module is missing.
>>
>>
>
>I am still confused. I may need to look at how "Lenya Modules" are
>being implemented. Are you thinking of them like Cocoon's Input and
>Output Modules? Java code that requires compilation for use? That
>sounds much less useful, flexible, and easy to implement or modify
>than what I was expecting.
>
>I thought Lenya Modules were the evolution of Usecases: one directory
>under {pub}/modules for each function. The entry point for each is
>{pub}/modules/{moduleID}/sitemap.xmap. Depending on the purpose and
>the parameters, Modules return a binary file "Asset", an HTML "Page",
>or (most often) an XML "Document", all handled with XMAPs, XSL, XSP,
>XML, and JS. Of course the XMAP can use various Generators,
>Transformers, Serializers and other stuff compiled from Java, but
>everything in the Module is interpreted for easy updates.
>
>With this architecture, inheritance is simply checking the parent
>templates until each file is found. Most of the "live" Module is at
>the global level, but "page2xhtml.xsl" can be overridden by each
>Publication.
>
>Is this close to your concept of Modules, or should this
>implementation still be called Usecases?
>
>
IIUC, usecases can be implemented in modules in 1.4, but you can also
use modules to implement other functionalities. Modules can have java
code, but some don't.
"Modules are packages providing a certain set of resources or
functionality" (from
http://lenya.apache.org/1_4/reference/modules/index.html, good overview
of modules).
HTH,
Renaud
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Requirements and Dependencies
Posted by so...@apache.org.
On 2/23/06, Andreas Hartmann <an...@apache.org> wrote:
> solprovider@apache.org wrote:
> > I am a little confused about how this would work, and doubt any
> > existing code would handle it properly. The code must check inherited
> > Templates, and that is a Lenya-specific feature. Three Templates
> > could have identically named Modules; this Publication only cares
> > about the Module it inherits.
>
> IMO we shouldn't support this, at least not at the moment. I think
> module dependencies should be resolved during compile time. Publication
> templating is IMO a runtime concept, at least this is what I had in
> mind when I implemented the first steps (creating several versions of
> the same publication, maybe overriding some XSLTs / pipelines)
> A publication instance shouldn't be allowed to declare additional
> modules.
>
> If we clearly separate compile time dependencies (which could be
> resolved using Gump) and runtime dependencies (instance -> template)
> there shouldn't be a problem.
>
> As soon as we've got this working properly we can think of adding
> runtime dependencies (hot-deploying modules, OSGi, ...), but IMO
> it's too early for that.
>
> > Missing modules is a completely different issue. Lenya will run
> > without a Module.
> IMO the build should fail if a required module is missing.
I am still confused. I may need to look at how "Lenya Modules" are
being implemented. Are you thinking of them like Cocoon's Input and
Output Modules? Java code that requires compilation for use? That
sounds much less useful, flexible, and easy to implement or modify
than what I was expecting.
I thought Lenya Modules were the evolution of Usecases: one directory
under {pub}/modules for each function. The entry point for each is
{pub}/modules/{moduleID}/sitemap.xmap. Depending on the purpose and
the parameters, Modules return a binary file "Asset", an HTML "Page",
or (most often) an XML "Document", all handled with XMAPs, XSL, XSP,
XML, and JS. Of course the XMAP can use various Generators,
Transformers, Serializers and other stuff compiled from Java, but
everything in the Module is interpreted for easy updates.
With this architecture, inheritance is simply checking the parent
templates until each file is found. Most of the "live" Module is at
the global level, but "page2xhtml.xsl" can be overridden by each
Publication.
Is this close to your concept of Modules, or should this
implementation still be called Usecases?
solprovider
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Requirements and Dependencies
Posted by Michael Wechner <mi...@wyona.com>.
Andreas Hartmann wrote:
>
>> Missing modules is a completely different issue. Lenya will run
>> without a Module.
>
>
> IMO the build should fail if a required module is missing.
exactly :-) at least for phase 1 ;-)
Michi
>
> -- Andreas
>
>
--
Michael Wechner
Wyona - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
michael.wechner@wyona.com michi@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Requirements and Dependencies
Posted by Andreas Hartmann <an...@apache.org>.
solprovider@apache.org wrote:
[...]
> I am a little confused about how this would work, and doubt any
> existing code would handle it properly. The code must check inherited
> Templates, and that is a Lenya-specific feature. Three Templates
> could have identically named Modules; this Publication only cares
> about the Module it inherits.
IMO we shouldn't support this, at least not at the moment. I think
module dependencies should be resolved during compile time. Publication
templating is IMO a runtime concept, at least this is what I had in
mind when I implemented the first steps (creating several versions of
the same publication, maybe overriding some XSLTs / pipelines)
A publication instance shouldn't be allowed to declare additional
modules.
If we clearly separate compile time dependencies (which could be
resolved using Gump) and runtime dependencies (instance -> template)
there shouldn't be a problem.
As soon as we've got this working properly we can think of adding
runtime dependencies (hot-deploying modules, OSGi, ...), but IMO
it's too early for that.
[...]
> Missing modules is a completely different issue. Lenya will run
> without a Module.
IMO the build should fail if a required module is missing.
-- Andreas
--
Andreas Hartmann
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
andreas.hartmann@wyona.com andreas@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Requirements and Dependencies
Posted by so...@apache.org.
On 2/23/06, Michael Wechner <mi...@wyona.com> wrote:
> Andreas Hartmann wrote:
> > Michael Wechner wrote:
> >> Andreas Hartmann wrote:
> >>> Michael Wechner wrote:
> >>>> Andreas Hartmann wrote:
> >>>>> Before building our own dependency resolving mechanism, I'd rather
> >>>>> review the Cocoon block concept again (maybe they allow external
> >>>>> blocks by now) and convert modules to blocks if this is appropriate.
> >>>> sure, but as said it's not about building something very complex,
> >>>> but very simple.
> >>>> It's basically parsing publication.xconf and check if the modules
> >>>> listed there are
> >>>> actually available ...
> >>> I'm generally against introducing a custom mechanism for something
> >>> that is already supported by a product which Lenya is based on.
> >> well, modules are no blocks, right? Are we going to change this? And
> >> if so, by when?
> > This has to be analyzed and decided. As soon as I find the time
> > I'll take a look at blocks again - I hope next week.
> >> Does it bother you if the publication.xconf is being checked and will
> >> help you to
> >> save time instead wasting time on debugging why something doesn't work?
> > I'm not against the concept of dependency checks, I'm just against
> > hurriedly implementing a custom mechanism when a mature solution
> > exists for the problem. I'd rather invest the time to see what Cocoon
> > does
> that's your time ;-)
> > - but of course that's just my personal opinion.
I am a little confused about how this would work, and doubt any
existing code would handle it properly. The code must check inherited
Templates, and that is a Lenya-specific feature. Three Templates
could have identically named Modules; this Publication only cares
about the Module it inherits.
I created the bugzilla about the Xalan libraries because, at the time,
it seemed every third thread on the mailing list was caused by
library issues. Checking for the files during the first boot would
have great ROI, and later boots could just check if the files found
were unchanged, unless a command line option, or a flag is configured
when Lenya had certain errors, forced a complete check during the next
launch. The administrator could look at the console window or a log
file to see the problem.
Missing modules is a completely different issue. Lenya will run
without a Module. A Publication will run as long as the default
Module (usually "live") exists. The Publication or Module may be
inactive; should there be error messages when the code is unused? The
big question is when would the Module dependency check happen, and how
would it be reported.
Consider these situations:
- A visitor mistypes a URL with a bad ModuleID..
- A visitor enters a URL for a Module that is not configured for this
Publication.
- A visitor enters a URL for a Module that is configured but missing
from the Publication.
- A visitor enters a URL for a Module they are not authorized to use.
- A visitor enters a URL for a Module that is broken.
True security demands that all of these return the same error page.
If the visitor complains, the administrator should:
- Check publication.xconf to see if the Module is configured for this
Publication.
- Check publication.xconf to see if the Module is configured.as
"external" for this Publication.
- Check if the Modules can be found in the Publication or its inheritance.
- Check if this visitor is allowed to use the Module. (They may do
this first by checking the URL with their superuser login.)
- Check if the Module is broken.
We could assist the first three items by having a Publication "Modules
Status" admin screen:
ModuleID, External?, Directory/Files found?
If the ModuleID is not listed, external is false, or no
"modules/{moduleid}/sitemap.xmap" is found in the inheritance, then
the admin knows the problem. If those settings are good, and it is
not an authorization issue, then the admin knows the Module is broken
(and tells a developer.)
Is there a better method for reporting about missing Modules?
solprovider
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Requirements and Dependencies
Posted by Michael Wechner <mi...@wyona.com>.
Andreas Hartmann wrote:
> Michael Wechner wrote:
>
>> Andreas Hartmann wrote:
>>
>>> Michael Wechner wrote:
>>>
>>>> Andreas Hartmann wrote:
>>>
>>>
>>>
>>> [...]
>>>
>>>>> Before building our own dependency resolving mechanism, I'd rather
>>>>> review the Cocoon block concept again (maybe they allow external
>>>>> blocks by now) and convert modules to blocks if this is appropriate.
>>>>
>>>>
>>>>
>>>>
>>>> sure, but as said it's not about building something very complex,
>>>> but very simple.
>>>> It's basically parsing publication.xconf and check if the modules
>>>> listed there are
>>>> actually available ...
>>>
>>>
>>>
>>> I'm generally against introducing a custom mechanism for something
>>> that is already supported by a product which Lenya is based on.
>>
>>
>>
>> well, modules are no blocks, right? Are we going to change this? And
>> if so, by when?
>
>
> This has to be analyzed and decided. As soon as I find the time
> I'll take a look at blocks again - I hope next week.
>
>
>> Does it bother you if the publication.xconf is being checked and will
>> help you to
>> save time instead wasting time on debugging why something doesn't work?
>
>
> I'm not against the concept of dependency checks, I'm just against
> hurriedly implementing a custom mechanism when a mature solution
> exists for the problem. I'd rather invest the time to see what Cocoon
> does
that's your time ;-)
Michi
> - but of course that's just my personal opinion.
>
> -- Andreas
>
>
--
Michael Wechner
Wyona - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
michael.wechner@wyona.com michi@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Requirements and Dependencies
Posted by Andreas Hartmann <an...@apache.org>.
Michael Wechner wrote:
> Andreas Hartmann wrote:
>
>> Michael Wechner wrote:
>>
>>> Andreas Hartmann wrote:
>>
>>
>> [...]
>>
>>>> Before building our own dependency resolving mechanism, I'd rather
>>>> review the Cocoon block concept again (maybe they allow external
>>>> blocks by now) and convert modules to blocks if this is appropriate.
>>>
>>>
>>>
>>> sure, but as said it's not about building something very complex, but
>>> very simple.
>>> It's basically parsing publication.xconf and check if the modules
>>> listed there are
>>> actually available ...
>>
>>
>> I'm generally against introducing a custom mechanism for something
>> that is already supported by a product which Lenya is based on.
>
>
> well, modules are no blocks, right? Are we going to change this? And if
> so, by when?
This has to be analyzed and decided. As soon as I find the time
I'll take a look at blocks again - I hope next week.
> Does it bother you if the publication.xconf is being checked and will
> help you to
> save time instead wasting time on debugging why something doesn't work?
I'm not against the concept of dependency checks, I'm just against
hurriedly implementing a custom mechanism when a mature solution
exists for the problem. I'd rather invest the time to see what Cocoon
does - but of course that's just my personal opinion.
-- Andreas
--
Andreas Hartmann
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
andreas.hartmann@wyona.com andreas@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Requirements and Dependencies
Posted by Michael Wechner <mi...@wyona.com>.
Andreas Hartmann wrote:
> Michael Wechner wrote:
>
>> Andreas Hartmann wrote:
>
>
> [...]
>
>>> Before building our own dependency resolving mechanism, I'd rather
>>> review the Cocoon block concept again (maybe they allow external
>>> blocks by now) and convert modules to blocks if this is appropriate.
>>
>>
>>
>> sure, but as said it's not about building something very complex, but
>> very simple.
>> It's basically parsing publication.xconf and check if the modules
>> listed there are
>> actually available ...
>
>
> I'm generally against introducing a custom mechanism for something
> that is already supported by a product which Lenya is based on.
well, modules are no blocks, right? Are we going to change this? And if
so, by when?
Does it bother you if the publication.xconf is being checked and will
help you to
save time instead wasting time on debugging why something doesn't work?
What about all the emails on these mailing lists of people asking why
doesn't it
work with this and this version?
Michi
>
> -- Andreas
>
>
--
Michael Wechner
Wyona - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
michael.wechner@wyona.com michi@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Requirements and Dependencies
Posted by Andreas Hartmann <an...@apache.org>.
Michael Wechner wrote:
> Andreas Hartmann wrote:
[...]
>> Before building our own dependency resolving mechanism, I'd rather
>> review the Cocoon block concept again (maybe they allow external
>> blocks by now) and convert modules to blocks if this is appropriate.
>
>
> sure, but as said it's not about building something very complex, but
> very simple.
> It's basically parsing publication.xconf and check if the modules listed
> there are
> actually available ...
I'm generally against introducing a custom mechanism for something
that is already supported by a product which Lenya is based on.
-- Andreas
--
Andreas Hartmann
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
andreas.hartmann@wyona.com andreas@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Requirements and Dependencies
Posted by Michael Wechner <mi...@wyona.com>.
Andreas Hartmann wrote:
> Michael Wechner wrote:
>
>> solprovider@apache.org wrote:
>>
>>> On 2/22/06, Michael Wechner <mi...@wyona.com> wrote:
>>>
>>>
>>>> I think we should extend the build process (but also hot pluggable
>>>> in a second phase) that requirements and dependencies of each
>>>> publication are being checked.
>>>>
>>>> E.g. if a publication is dependent on the module "atom-entry" and
>>>> this module has not been referenced, then an error should be thrown.
>>>>
>>>> Or if a publication is based on Cocoon 2.1.8, but the build is being
>>>> done on Cocoon-2.1.9-dev then also an error should be thrown.
>>>>
>>>> This way we are able to reduce questions and time consuming debugging
>>>> for something actual obvious.
>>>>
>>>> WDYT?
>>>>
>>>
>>>
>>> I think this is a more ambitious version of:
>>> "Check Xalan libraries during install/boot"
>>> http://issues.apache.org/bugzilla/show_bug.cgi?id=35305
>>>
>>> and I am all for it.
>>>
>>>
>>
>> we can start it simple by it least checking if the modules have been
>> included by name.
>
>
> Before building our own dependency resolving mechanism, I'd rather
> review the Cocoon block concept again (maybe they allow external
> blocks by now) and convert modules to blocks if this is appropriate.
sure, but as said it's not about building something very complex, but
very simple.
It's basically parsing publication.xconf and check if the modules listed
there are
actually available ...
Michi
>
> -- Andreas
>
>
--
Michael Wechner
Wyona - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
michael.wechner@wyona.com michi@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Requirements and Dependencies
Posted by Andreas Hartmann <an...@apache.org>.
Michael Wechner wrote:
> solprovider@apache.org wrote:
>
>> On 2/22/06, Michael Wechner <mi...@wyona.com> wrote:
>>
>>
>>> I think we should extend the build process (but also hot pluggable
>>> in a second phase) that requirements and dependencies of each
>>> publication are being checked.
>>>
>>> E.g. if a publication is dependent on the module "atom-entry" and
>>> this module has not been referenced, then an error should be thrown.
>>>
>>> Or if a publication is based on Cocoon 2.1.8, but the build is being
>>> done on Cocoon-2.1.9-dev then also an error should be thrown.
>>>
>>> This way we are able to reduce questions and time consuming debugging
>>> for something actual obvious.
>>>
>>> WDYT?
>>>
>>
>> I think this is a more ambitious version of:
>> "Check Xalan libraries during install/boot"
>> http://issues.apache.org/bugzilla/show_bug.cgi?id=35305
>>
>> and I am all for it.
>>
>>
>
> we can start it simple by it least checking if the modules have been
> included by name.
Before building our own dependency resolving mechanism, I'd rather
review the Cocoon block concept again (maybe they allow external
blocks by now) and convert modules to blocks if this is appropriate.
-- Andreas
--
Andreas Hartmann
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
andreas.hartmann@wyona.com andreas@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Requirements and Dependencies
Posted by Michael Wechner <mi...@wyona.com>.
solprovider@apache.org wrote:
>On 2/22/06, Michael Wechner <mi...@wyona.com> wrote:
>
>
>>I think we should extend the build process (but also hot pluggable
>>in a second phase) that requirements and dependencies of each
>>publication are being checked.
>>
>>E.g. if a publication is dependent on the module "atom-entry" and
>>this module has not been referenced, then an error should be thrown.
>>
>>Or if a publication is based on Cocoon 2.1.8, but the build is being
>>done on Cocoon-2.1.9-dev then also an error should be thrown.
>>
>>This way we are able to reduce questions and time consuming debugging
>>for something actual obvious.
>>
>>WDYT?
>>
>>
>
>I think this is a more ambitious version of:
>"Check Xalan libraries during install/boot"
>http://issues.apache.org/bugzilla/show_bug.cgi?id=35305
>
>and I am all for it.
>
>
we can start it simple by it least checking if the modules have been
included by name.
Michi
>solprovider
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
>For additional commands, e-mail: dev-help@lenya.apache.org
>
>
>
>
--
Michael Wechner
Wyona - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
michael.wechner@wyona.com michi@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Requirements and Dependencies
Posted by so...@apache.org.
On 2/22/06, Michael Wechner <mi...@wyona.com> wrote:
> I think we should extend the build process (but also hot pluggable
> in a second phase) that requirements and dependencies of each
> publication are being checked.
>
> E.g. if a publication is dependent on the module "atom-entry" and
> this module has not been referenced, then an error should be thrown.
>
> Or if a publication is based on Cocoon 2.1.8, but the build is being
> done on Cocoon-2.1.9-dev then also an error should be thrown.
>
> This way we are able to reduce questions and time consuming debugging
> for something actual obvious.
>
> WDYT?
I think this is a more ambitious version of:
"Check Xalan libraries during install/boot"
http://issues.apache.org/bugzilla/show_bug.cgi?id=35305
and I am all for it.
solprovider
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org