You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@lenya.apache.org by Wolfgang Jeltsch <zs...@acme.softbase.org> on 2008/06/07 22:20:50 UTC
getting rid of unwanted resource types
Hello,
if I use the default publication as a template for a new publication, I get
several resource types I don’t want, e.g., ODT. I tried to get rid of them
by inserting an explicit resource type list into the resource-types element
in file
build/lenya/webapp/lenya/pubs/$MYPUB/config/publication.xml
and restarting Lenya. However, this didn’t have any visible effect. Then I
commented out the respective resource-type elements in the default
publication’s configuration file
build/lenya/webapp/lenya/pubs/$MYPUB/config/publication.xml
and restarted Lenya which didn’t work either. So what’s the solution to my
problem?
By the way, is it okay to just edit those publication.xml files and restart
Lenya? I did this to change the set of supported languages and it seemed to
work. On the other hand, the Lenya website seems to tell me that I should
rerun the build process or something like that.
And what are the resource types “resource” and “usecase” for? They have
respective entries in the default publication’s publication.xml file but I
cannot create documents of type “resource” or “usecase”.
Best wishes,
Wolfgang
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org
Re: getting rid of unwanted resource types
Posted by Andreas Hartmann <an...@apache.org>.
Wolfgang Jeltsch schrieb:
> Am Montag, 9. Juni 2008 10:13 schrieb Andreas Hartmann:
>> […]
>
>> Wolfgang Jeltsch schrieb:
>> […]
>
>> ATM the only purpose of the <resource-type> elements in publication.xml
>> is to assign workflow schemas to resource types.
>>
>> The menu items are inserted by the modules. To get rid of a resource
>> type menu item, you have to remove the corresponding <module> element
>> from publication.xconf.
>
> You mean publication.xml, don’t you?
Yes, sorry.
> However, the modules element in my publication’s publication.xml is empty.
> Nevertheless, there are those menu items for creating ODT documents, etc.
> Are the modules inherited from the default publication? If yes, how can I
> derive my publication from the default publication without inheriting all the
> modules?
This is not possible, you can only add modules.
If you think this functionality is required, you could add an
enhancement request to bugzilla (a patch would of course be welcome).
-- Andreas
--
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
Tel.: +41 (0) 43 818 57 01
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org
Re: getting rid of unwanted resource types
Posted by Wolfgang Jeltsch <zs...@acme.softbase.org>.
Am Montag, 9. Juni 2008 10:13 schrieb Andreas Hartmann:
> […]
> Wolfgang Jeltsch schrieb:
> […]
> ATM the only purpose of the <resource-type> elements in publication.xml
> is to assign workflow schemas to resource types.
>
> The menu items are inserted by the modules. To get rid of a resource
> type menu item, you have to remove the corresponding <module> element
> from publication.xconf.
You mean publication.xml, don’t you?
However, the modules element in my publication’s publication.xml is empty.
Nevertheless, there are those menu items for creating ODT documents, etc.
Are the modules inherited from the default publication? If yes, how can I
derive my publication from the default publication without inheriting all the
modules?
> […]
Best wishes,
Wolfgang
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org
Re: getting rid of unwanted resource types
Posted by Andreas Hartmann <an...@apache.org>.
Wolfgang Jeltsch schrieb:
[…]
>>>>> Second, I don’t know how Lucene knows to what base directory the
>>>>> relative paths in lucene_index.xml refer. The example lucene_index.xml
>>>>> contains paths starting with lenya/pubs/$MYPUB.
>>>> IndexManagerImpl:370
>>>>
>>>> if (!directory.startsWith(File.separator)) {
>>>> directory = getServletContextPath() + File.separator + directory;
>>>> }
>>> But this would mean that the servlet context path would have to be
>>> $HOME/src while lenya is installed in $HOME/apache/lenya-2.0.
>> Hmm, why should that be the case?
>>
>> With Jetty, the servlet context is $LENYA_HOME/build/lenya/webapp.
>> If you deploy to Tomcat (using /lenya as servlet path), the servlet
>> context is $TOMCAT_HOME/webapps/lenya.
>
> I’m talking about the directory layout used in the tutorial (at
> <http://lenya.apache.org/docs/2_0_x/tutorials/newpublication/index.html>).
> Lenya is installed there in $HOME/apache/lenya-2.0. The Lucene indexing
> stuff is intended to go into $HOME/src/lenya/pubs/$MYPUB/work/lucene/index.
Hmm, where does it say that? Actually it is intended to go into
$HOME/apache/lenya-2.0/build/lenya/webapp/lenya/pubs/$MYPUB/work/lucene/index
Another (probably better) option would be to keep it in
$HOME/src/lenya/data/$MYPUB/lucene/index
Or, if you don't keep the data in SVN, the whole structure should be
changed to something like this:
$HOME/
apache/
lenya-2.0/ Lenya installation directory
build/lenya/webapp/ Web application directory (servlet context)
src/
lenya/ Lenya-related sources.
pubs/ Your publications.
$MYPUB/ Your first publication.
$MYPUB2/
…
modules/ Your modules.
data/ Here you'll store your data:
$MYPUB/
content/ Content (documents, images, ...)
access-control/ Access control data
passwd/ Users, groups, etc.
policies/ Policies (page permissions)
lucene/ Lucene index
$MYPUB2/
…
-- Andreas
--
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
Tel.: +41 (0) 43 818 57 01
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org
Re: getting rid of unwanted resource types
Posted by Wolfgang Jeltsch <zs...@acme.softbase.org>.
Am Sonntag, 22. Juni 2008 20:01 schrieb Andreas Hartmann:
> Wolfgang Jeltsch schrieb:
> > Am Montag, 16. Juni 2008 11:28 schrieb Andreas Hartmann:
> > > Wolfgang Jeltsch schrieb:
> […]
> > But look at the directory structure in the section “Prerequisites”. All
> > access control data is meant to be stored under
> > $HOME/src/lenya/data/access-control. The publication name isn’t
> > mentioned in this path. So if I would create a second publication
> > according to the same scheme, its access control data would be stored in
> > the same path.
>
> In this case you can just add another directory to the hierarchy:
>
> $HOME/src/lenya/{pub}/data/…
Yes, but this should also be done in the tutorial, otherwise it is misleading.
> […]
> >>> Second, I don’t know how Lucene knows to what base directory the
> >>> relative paths in lucene_index.xml refer. The example lucene_index.xml
> >>> contains paths starting with lenya/pubs/$MYPUB.
> >>
> >> IndexManagerImpl:370
> >>
> >> if (!directory.startsWith(File.separator)) {
> >> directory = getServletContextPath() + File.separator + directory;
> >> }
> >
> > But this would mean that the servlet context path would have to be
> > $HOME/src while lenya is installed in $HOME/apache/lenya-2.0.
>
> Hmm, why should that be the case?
>
> With Jetty, the servlet context is $LENYA_HOME/build/lenya/webapp.
> If you deploy to Tomcat (using /lenya as servlet path), the servlet
> context is $TOMCAT_HOME/webapps/lenya.
I’m talking about the directory layout used in the tutorial (at
<http://lenya.apache.org/docs/2_0_x/tutorials/newpublication/index.html>).
Lenya is installed there in $HOME/apache/lenya-2.0. The Lucene indexing
stuff is intended to go into $HOME/src/lenya/pubs/$MYPUB/work/lucene/index.
The paths in lucene_index.xml start with lenya/pubs/$MYPUB/work/lucene/index.
So the base directory should be $HOME/src. I doubt that this is the servlet
context path. So the tutorial should probably be corrected at this point.
> […]
Best wishes,
Wolfgang
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org
Re: getting rid of unwanted resource types
Posted by Andreas Hartmann <an...@apache.org>.
Wolfgang Jeltsch schrieb:
> Am Montag, 16. Juni 2008 11:28 schrieb Andreas Hartmann:
>> Wolfgang Jeltsch schrieb:
>>> Am Freitag, 13. Juni 2008 16:39 schrieb Andreas Hartmann:
>
>> […]
>
>>>> I'd start with this tutorial:
>>>> http://lenya.apache.org/docs/2_0_x/tutorials/newpublication/index.html
>
>> […]
>
>>> First, I don’t understand why access control data isn’t held inside the
>>> publication directory like it seems to be the case with the default
>>> publication. Is this for sharing authentication data between
>>> publications?
>> No, the separation of application and data is meant to simplify
>> maintenance: […]
>
> But look at the directory structure in the section “Prerequisites”. All
> access control data is meant to be stored under
> $HOME/src/lenya/data/access-control. The publication name isn’t mentioned in
> this path. So if I would create a second publication according to the same
> scheme, its access control data would be stored in the same path.
In this case you can just add another directory to the hierarchy:
$HOME/src/lenya/{pub}/data/…
>> […]
>
>>> Second, I don’t know how Lucene knows to what base directory the relative
>>> paths in lucene_index.xml refer. The example lucene_index.xml contains
>>> paths starting with lenya/pubs/$MYPUB.
>> IndexManagerImpl:370
>>
>> if (!directory.startsWith(File.separator)) {
>> directory = getServletContextPath() + File.separator + directory;
>> }
>
> But this would mean that the servlet context path would have to be $HOME/src
> while lenya is installed in $HOME/apache/lenya-2.0.
Hmm, why should that be the case?
With Jetty, the servlet context is $LENYA_HOME/build/lenya/webapp.
If you deploy to Tomcat (using /lenya as servlet path), the servlet
context is $TOMCAT_HOME/webapps/lenya.
With Jetty, the Lucene index would then be stored in
$LENYA_HOME/build/lenya/webapp/lenya/pubs/$MYPUB/work/lucene
which is correct, isn't it?
Or am I misunderstanding something?
-- Andreas
--
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
Tel.: +41 (0) 43 818 57 01
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org
Re: getting rid of unwanted resource types
Posted by Wolfgang Jeltsch <zs...@acme.softbase.org>.
Am Montag, 16. Juni 2008 11:28 schrieb Andreas Hartmann:
> Wolfgang Jeltsch schrieb:
> > Am Freitag, 13. Juni 2008 16:39 schrieb Andreas Hartmann:
> […]
> >> I'd start with this tutorial:
> >> http://lenya.apache.org/docs/2_0_x/tutorials/newpublication/index.html
> […]
> > First, I don’t understand why access control data isn’t held inside the
> > publication directory like it seems to be the case with the default
> > publication. Is this for sharing authentication data between
> > publications?
>
> No, the separation of application and data is meant to simplify
> maintenance: […]
But look at the directory structure in the section “Prerequisites”. All
access control data is meant to be stored under
$HOME/src/lenya/data/access-control. The publication name isn’t mentioned in
this path. So if I would create a second publication according to the same
scheme, its access control data would be stored in the same path.
> […]
> > Second, I don’t know how Lucene knows to what base directory the relative
> > paths in lucene_index.xml refer. The example lucene_index.xml contains
> > paths starting with lenya/pubs/$MYPUB.
>
> IndexManagerImpl:370
>
> if (!directory.startsWith(File.separator)) {
> directory = getServletContextPath() + File.separator + directory;
> }
But this would mean that the servlet context path would have to be $HOME/src
while lenya is installed in $HOME/apache/lenya-2.0.
> […]
Best wishes,
Wolfgang
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org
Re: getting rid of unwanted resource types
Posted by Andreas Hartmann <an...@apache.org>.
Wolfgang Jeltsch schrieb:
> Am Freitag, 13. Juni 2008 16:39 schrieb Andreas Hartmann:
>> […]
>
>> I'd start with this tutorial:
>> http://lenya.apache.org/docs/2_0_x/tutorials/newpublication/index.html
>>
>> Some details might be outdated, if something doesn't work don't hesitate
>> to complain.
>
> I complain.
>
> First, I don’t understand why access control data isn’t held inside the
> publication directory like it seems to be the case with the default
> publication. Is this for sharing authentication data between publications?
No, the separation of application and data is meant to simplify maintenance:
- easier backup of data
- convenient if you store the data in SVN
- you can deploy the webapp as a WAR file
- easier handling of file system permissions
> Does such a sharing work reliably by just using the same access control data
> directory for different publications or are there synchronisation issues?
It shouldn't make a difference whether the data are shared across
publications. AFAIK the ItemManager service objects are created per
directory and not per publication, so if two publications share the same
data directory, they share the same ItemManager object. So, if
synchronisation issues occur, they could also occur in a single publication.
> Second, I don’t know how Lucene knows to what base directory the relative
> paths in lucene_index.xml refer. The example lucene_index.xml contains paths
> starting with lenya/pubs/$MYPUB.
IndexManagerImpl:370
if (!directory.startsWith(File.separator)) {
directory = getServletContextPath() + File.separator + directory;
}
> Third, if I click on „My First Publication“ as told at the end of the
> tutorial, I don’t get the introduction page but a page with the following
> content:
>
>> Resource Not Found
>>
>> Message: Resource Not Found
>> Description: The requested resource "/fcgs/introduction.html" could not be
>> found
I'll try to take a look at it as soon as I find the time.
-- Andreas
--
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
Tel.: +41 (0) 43 818 57 01
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org
Re: getting rid of unwanted resource types
Posted by Wolfgang Jeltsch <zs...@acme.softbase.org>.
Am Freitag, 13. Juni 2008 16:39 schrieb Andreas Hartmann:
> […]
> I'd start with this tutorial:
> http://lenya.apache.org/docs/2_0_x/tutorials/newpublication/index.html
>
> Some details might be outdated, if something doesn't work don't hesitate
> to complain.
I complain.
First, I don’t understand why access control data isn’t held inside the
publication directory like it seems to be the case with the default
publication. Is this for sharing authentication data between publications?
Does such a sharing work reliably by just using the same access control data
directory for different publications or are there synchronisation issues?
Second, I don’t know how Lucene knows to what base directory the relative
paths in lucene_index.xml refer. The example lucene_index.xml contains paths
starting with lenya/pubs/$MYPUB.
Third, if I click on „My First Publication“ as told at the end of the
tutorial, I don’t get the introduction page but a page with the following
content:
> Resource Not Found
>
> Message: Resource Not Found
> Description: The requested resource "/fcgs/introduction.html" could not be
> found
> Sender: org.apache.cocoon.servlet.CocoonServlet
> Source: Cocoon Servlet
>
> Apache Cocoon 2.1.11-dev
> HTH,
>
> -- Andreas
Wolfgang
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org
Re: getting rid of unwanted resource types
Posted by Andreas Hartmann <an...@apache.org>.
Wolfgang Jeltsch schrieb:
> Am Freitag, 13. Juni 2008 16:39 schrieb Andreas Hartmann:
>> […]
>
>> Wolfgang Jeltsch schrieb:
>>> Am Freitag, 13. Juni 2008 15:17 schrieb Andreas Hartmann:
>
>> […]
>
>>>> The "Create publication" web interface is not intended for development,
>>>> rather to create new publication instances in a production environment.
>>> So what do I “develop” then? I thought, I develop a publication. Do I
>>> develop a “publication template” or whatever which can be instantiated
>>> several times?
>> Yes, this is a typical application scenario. The publication templating
>> feature is targeted for large organisations like universities. They
>> provide a template which is instanciated for all their departements.
>
> But I thought that a template *is* a (special kind of) publication.
Yes, this is true.
> Could you please tell me what
>
> * a publication
Originally, a publication was a collection of content objects and a set
of functions (in 1.2 tasks, in 2.0 usecases). In 2.0, these aspects have
been separated for better reusability and maintainability. But you can
still have both (content and function declarations) in one publication
(if you don't need publication templating).
> * a publication template
A publication template is a publication which defines the fundamental
presentation and behaviour for other publications. In fact, every
publication can be a template if it provides an instantiator. A
publication template may contain content, but I wouldn't recommend this
for SoC reasons. For each template, an arbitrary number of instances can
be created. Changes to all fallback-referenced resources in the template
will be visible in all instances.
> * a publication instance
A publication instance is a publication which contains only data and
configuration. The functions and layout are defined by its template
publication. It is possible, though, to declare certain additional
functions or override functions and rendering components (sitemaps,
XSLTs, …) of the template publication.
-- Andreas
--
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
Tel.: +41 (0) 43 818 57 01
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org
Re: getting rid of unwanted resource types
Posted by Wolfgang Jeltsch <zs...@acme.softbase.org>.
Am Freitag, 13. Juni 2008 16:39 schrieb Andreas Hartmann:
> […]
> Wolfgang Jeltsch schrieb:
> > Am Freitag, 13. Juni 2008 15:17 schrieb Andreas Hartmann:
> […]
> > > The "Create publication" web interface is not intended for development,
> > > rather to create new publication instances in a production environment.
> >
> > So what do I “develop” then? I thought, I develop a publication. Do I
> > develop a “publication template” or whatever which can be instantiated
> > several times?
>
> Yes, this is a typical application scenario. The publication templating
> feature is targeted for large organisations like universities. They
> provide a template which is instanciated for all their departements.
But I thought that a template *is* a (special kind of) publication. Could you
please tell me what
* a publication
* a publication template
* a publication instance
is?
> […]
Best wishes,
Wolfgang
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org
Re: getting rid of unwanted resource types
Posted by Andreas Hartmann <an...@apache.org>.
Hi Wolfgang,
Wolfgang Jeltsch schrieb:
> Am Freitag, 13. Juni 2008 15:17 schrieb Andreas Hartmann:
>> […]
>
>> Wolfgang Jeltsch schrieb:
>> […]
>
>>> Where’s the source tree if I created my publication using the web
>>> interface? Is there any at all?
>> no, there is no source tree. The "Create publication" web interface is
>> not intended for development, rather to create new publication instances
>> in a production environment.
>
> So what do I “develop” then? I thought, I develop a publication. Do I
> develop a “publication template” or whatever which can be instantiated
> several times?
Yes, this is a typical application scenario. The publication templating
feature is targeted for large organisations like universities. They
provide a template which is instanciated for all their departements.
> I have to say that it’s really difficult to get all this information because
> the Lenya documentation is really lacking at this point. You have some
> tutorials with step-by-step instructions, some isolated descriptions of
> concepts and some in-depth descriptions of very specialized things but you
> don’t have any documentation which gives you an introduction to the whole
> picture and the relationships between the different things. This makes it
> really hard to start using Lenya and it might frighten off many potential
> users. If I wouldn’t have been impressed by the pro-standards and
> pro-flexibility approach of Lenya that much, I’d probably have switched to
> some other CMS and in fact, I almost had used OpenCms instead of Lenya.
Yes, unfortunately our documentation is by far not sufficient given the
complexity of the product. Any help is greatly appreciated, if you're
interested in providing documentation, don't hesitate to ask for an
editor account.
>
>> […]
>
>>> What about the documents of my publication? Will they be lost during
>>> redeployment?
>> I'd recommend not having any content in the source tree to avoid the
>> risk of overriding productive documents.
>
> Why does Lenya mix content and “source” by default then?
This is for historical reasons. In earlier versions, it was not possible
to keep the content outside the application directory. Nobody took the
time to change the default content location yet.
> (I think, you meant “build”, not “source” by the way.)
No, I meant "source". But the same applies to the build tree (see below).
>> […]
>
> So I want to build a simple website first. Basically, I want a publication
> similar to the default publication but with less features (e.g., resource
> types). Later I’ll probably want more advanced things and therefore use
> additional features. How should I start?
I'd start with this tutorial:
http://lenya.apache.org/docs/2_0_x/tutorials/newpublication/index.html
Some details might be outdated, if something doesn't work don't hesitate
to complain.
HTH,
-- Andreas
--
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
Tel.: +41 (0) 43 818 57 01
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org
Re: getting rid of unwanted resource types
Posted by Wolfgang Jeltsch <zs...@acme.softbase.org>.
Am Freitag, 13. Juni 2008 15:17 schrieb Andreas Hartmann:
> […]
> Wolfgang Jeltsch schrieb:
> […]
> > Where’s the source tree if I created my publication using the web
> > interface? Is there any at all?
>
> no, there is no source tree. The "Create publication" web interface is
> not intended for development, rather to create new publication instances
> in a production environment.
So what do I “develop” then? I thought, I develop a publication. Do I
develop a “publication template” or whatever which can be instantiated
several times?
I have to say that it’s really difficult to get all this information because
the Lenya documentation is really lacking at this point. You have some
tutorials with step-by-step instructions, some isolated descriptions of
concepts and some in-depth descriptions of very specialized things but you
don’t have any documentation which gives you an introduction to the whole
picture and the relationships between the different things. This makes it
really hard to start using Lenya and it might frighten off many potential
users. If I wouldn’t have been impressed by the pro-standards and
pro-flexibility approach of Lenya that much, I’d probably have switched to
some other CMS and in fact, I almost had used OpenCms instead of Lenya.
> […]
> > What about the documents of my publication? Will they be lost during
> > redeployment?
>
> I'd recommend not having any content in the source tree to avoid the
> risk of overriding productive documents.
Why does Lenya mix content and “source” by default then? (I think, you
meant “build”, not “source” by the way.)
> […]
So I want to build a simple website first. Basically, I want a publication
similar to the default publication but with less features (e.g., resource
types). Later I’ll probably want more advanced things and therefore use
additional features. How should I start?
> -- Andreas
Best wishes,
Wolfgang
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org
Re: getting rid of unwanted resource types
Posted by Andreas Hartmann <an...@apache.org>.
Wolfgang Jeltsch schrieb:
> Am Sonntag, 22. Juni 2008 20:04 schrieb Andreas Hartmann:
>> Wolfgang Jeltsch schrieb:
>
>> […]
>
>>> My current solution is to have a source tree with all files I want to
>>> change manually (like publication.xml) and have symbolic links in the
>>> publication directory, pointing to the files/directories in the source
>>> tree.
>> BTW, another approach is putting as many files as possible in modules
>> (which I'd recommend for several reasons) and set modules.copy=false in
>> local.build.properties.
>
> What can be put into a module?
>
> * publication.xml?
This one has to be located in $PUB_HOME/config/.
> * XSLT files?
> * CSS files?
> * I18n files?
> * Images to be automatically inserted into each page?
Yes, all of these can be kept in modules.
-- Andreas
--
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
Tel.: +41 (0) 43 818 57 01
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org
Re: getting rid of unwanted resource types
Posted by so...@apache.org.
On 6/22/08, Wolfgang Jeltsch <zs...@acme.softbase.org> wrote:
> Am Sonntag, 22. Juni 2008 20:04 schrieb Andreas Hartmann:
> > Wolfgang Jeltsch schrieb:
> > > My current solution is to have a source tree with all files I want to
> > > change manually (like publication.xml) and have symbolic links in the
> > > publication directory, pointing to the files/directories in the source
> > > tree.
> >
> > BTW, another approach is putting as many files as possible in modules
> > (which I'd recommend for several reasons) and set modules.copy=false in
> > local.build.properties.
>
> What can be put into a module?
> * publication.xml?
> * XSLT files?
> * CSS files?
> * I18n files?
> * Images to be automatically inserted into each page?
>
> Best wishes,
> Wolfgang
Thank you for an idea. (This coud be theoretical since I am not
familiar with Lenya 2.x, but the thoughts do apply to my demo.) The
last four items should be in Modules. publication.xml needs to define
the Publication:
- content: the location and type of repository.
- code: which Modules to include and where are any Publication-specific Modules.
- security: the type and connection information for a directory or the
location of Lenya's XML files (whether shared or
Publication-specific.)
The new idea is that a file named publication.xml does not need to be
in a directory named with the publication-id. The information could
be placed in a file named {publication-id}.xml in the pubs directory.
A publication directory is not needed if the content-code-security
data can be stored outside the Lenya directory. Lenya can be upgraded
or reinstalled without affecting the Publications (assuming everything
in the Publication is compatible with the different versions of
Lenya.)
Thank you,
solprovider
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org
Re: getting rid of unwanted resource types
Posted by Wolfgang Jeltsch <zs...@acme.softbase.org>.
Am Sonntag, 22. Juni 2008 20:04 schrieb Andreas Hartmann:
> Wolfgang Jeltsch schrieb:
> […]
> > My current solution is to have a source tree with all files I want to
> > change manually (like publication.xml) and have symbolic links in the
> > publication directory, pointing to the files/directories in the source
> > tree.
>
> BTW, another approach is putting as many files as possible in modules
> (which I'd recommend for several reasons) and set modules.copy=false in
> local.build.properties.
What can be put into a module?
* publication.xml?
* XSLT files?
* CSS files?
* I18n files?
* Images to be automatically inserted into each page?
> […]
Best wishes,
Wolfgang
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org
Re: getting rid of unwanted resource types
Posted by Andreas Hartmann <an...@apache.org>.
Wolfgang Jeltsch schrieb:
> Am Montag, 16. Juni 2008 11:37 schrieb Andreas Hartmann:
>> Wolfgang Jeltsch schrieb:
>
>> […]
>
>>> As far as I can see, running build.sh just copies all source files of the
>>> publication to build/lenya/webapp/lenya/pubs/$MYPUB. So what’s the problem
>>> with syncing the latter directory with my source code repository instead
>>> of syncing some “source tree” with the repository and “deploying” its
>>> contents.
>> If you are disciplined enough not to apply any manual changes, you can
>> use the repository directly (if it doesn't bother you to have .svn files
>> in your web application). I, personally, feel better if I have separate
>> source and build trees on the server, but maybe the other option is more
>> appropriate for your requirements.
>
> My current solution is to have a source tree with all files I want to change
> manually (like publication.xml) and have symbolic links in the publication
> directory, pointing to the files/directories in the source tree.
BTW, another approach is putting as many files as possible in modules
(which I'd recommend for several reasons) and set modules.copy=false in
local.build.properties.
-- Andreas
--
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
Tel.: +41 (0) 43 818 57 01
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org
Re: getting rid of unwanted resource types
Posted by Wolfgang Jeltsch <zs...@acme.softbase.org>.
Am Montag, 16. Juni 2008 11:37 schrieb Andreas Hartmann:
> Wolfgang Jeltsch schrieb:
> […]
> > As far as I can see, running build.sh just copies all source files of the
> > publication to build/lenya/webapp/lenya/pubs/$MYPUB. So what’s the problem
> > with syncing the latter directory with my source code repository instead
> > of syncing some “source tree” with the repository and “deploying” its
> > contents.
>
> If you are disciplined enough not to apply any manual changes, you can
> use the repository directly (if it doesn't bother you to have .svn files
> in your web application). I, personally, feel better if I have separate
> source and build trees on the server, but maybe the other option is more
> appropriate for your requirements.
My current solution is to have a source tree with all files I want to change
manually (like publication.xml) and have symbolic links in the publication
directory, pointing to the files/directories in the source tree.
> […]
Best wishes,
Wolfgang
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org
Re: getting rid of unwanted resource types
Posted by Andreas Hartmann <an...@apache.org>.
Wolfgang Jeltsch schrieb:
> Am Freitag, 13. Juni 2008 15:17 schrieb Andreas Hartmann:
>> […]
>
>> Wolfgang Jeltsch schrieb:
>> […]
>
>>> What’s the point of having a separate source tree?
>> You have more control - you can change several files in your source tree
>> without influencing the productive application, and deploy all changes
>> with a single command.
>
> What does “deploying” mean?
In this case, copying the changed files from the source tree to the
build tree, like you already mentioned.
> As far as I can see, running build.sh just copies
> all source files of the publication to build/lenya/webapp/lenya/pubs/$MYPUB.
> So what’s the problem with syncing the latter directory with my source code
> repository instead of syncing some “source tree” with the repository
> and “deploying” its contents.
If you are disciplined enough not to apply any manual changes, you can
use the repository directly (if it doesn't bother you to have .svn files
in your web application). I, personally, feel better if I have separate
source and build trees on the server, but maybe the other option is more
appropriate for your requirements.
> It seem preferable to create a new publication via the web interface and adapt
> the files in the build directory to fit my needs. In contrast to following
> <http://lenya.apache.org/docs/2_0_x/tutorials/newpublication/index.html>,
> this seems to get the contents of pubs/$MYPUB right. At least, it creates
> some more files than the description under the above-mentioned URL tells me
> to create.
Thanks for the hint, it seems like the tutorial is not up to date with
the default publication's instantiator.
-- Andreas
--
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
Tel.: +41 (0) 43 818 57 01
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org
Re: getting rid of unwanted resource types
Posted by Wolfgang Jeltsch <zs...@acme.softbase.org>.
Am Freitag, 13. Juni 2008 15:17 schrieb Andreas Hartmann:
> […]
> Wolfgang Jeltsch schrieb:
> […]
> > What’s the point of having a separate source tree?
>
> You have more control - you can change several files in your source tree
> without influencing the productive application, and deploy all changes
> with a single command.
What does “deploying” mean? As far as I can see, running build.sh just copies
all source files of the publication to build/lenya/webapp/lenya/pubs/$MYPUB.
So what’s the problem with syncing the latter directory with my source code
repository instead of syncing some “source tree” with the repository
and “deploying” its contents.
It seem preferable to create a new publication via the web interface and adapt
the files in the build directory to fit my needs. In contrast to following
<http://lenya.apache.org/docs/2_0_x/tutorials/newpublication/index.html>,
this seems to get the contents of pubs/$MYPUB right. At least, it creates
some more files than the description under the above-mentioned URL tells me
to create.
> -- Andreas
Wolfgang
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org
Re: getting rid of unwanted resource types
Posted by Andreas Hartmann <an...@apache.org>.
Hi Wolfgang,
Wolfgang Jeltsch schrieb:
> Am Montag, 9. Juni 2008 10:13 schrieb Andreas Hartmann:
>> […]
>
>>> By the way, is it okay to just edit those publication.xml files and
>>> restart Lenya? I did this to change the set of supported languages and
>>> it seemed to work. On the other hand, the Lenya website seems to tell me
>>> that I should rerun the build process or something like that.
>> If you change publication.xml in the build tree, you don't have to run
>> the deployment process again. But I'd generally recommended to apply
>> important changes to the source tree (which is usually held in a source
>> code repository).
>
> Where’s the source tree if I created my publication using the web interface?
> Is there any at all?
no, there is no source tree. The "Create publication" web interface is
not intended for development, rather to create new publication instances
in a production environment. Actually the instantiator that ships with
the default publication is just a simple example, the actual
implementation depends on the specific requirements of your deployment
model.
> What’s the point of having a separate source tree?
You have more control - you can change several files in your source tree
without influencing the productive application, and deploy all changes
with a single command.
> Do I have to remove the build directory before deploying again?
No, this is not necessary.
> What about the documents of my publication?
> Will they be lost during redeployment?
I'd recommend not having any content in the source tree to avoid the
risk of overriding productive documents. Apart from that, I think it's a
good idea to separate the content location from the web application (see
http://lenya.apache.org/docs/2_0_x/tutorials/production.html).
-- Andreas
--
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
Tel.: +41 (0) 43 818 57 01
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org
Re: getting rid of unwanted resource types
Posted by Wolfgang Jeltsch <zs...@acme.softbase.org>.
Am Montag, 9. Juni 2008 10:13 schrieb Andreas Hartmann:
> […]
> > By the way, is it okay to just edit those publication.xml files and
> > restart Lenya? I did this to change the set of supported languages and
> > it seemed to work. On the other hand, the Lenya website seems to tell me
> > that I should rerun the build process or something like that.
>
> If you change publication.xml in the build tree, you don't have to run
> the deployment process again. But I'd generally recommended to apply
> important changes to the source tree (which is usually held in a source
> code repository).
Where’s the source tree if I created my publication using the web interface?
Is there any at all? What’s the point of having a separate source tree? Do
I have to remove the build directory before deploying again? What about the
documents of my publication? Will they be lost during redeployment?
> […]
Best wishes,
Wolfgang
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org
Re: getting rid of unwanted resource types
Posted by Andreas Hartmann <an...@apache.org>.
Hi Wolfgang,
Wolfgang Jeltsch schrieb:
> if I use the default publication as a template for a new publication, I get
> several resource types I don’t want, e.g., ODT. I tried to get rid of them
> by inserting an explicit resource type list into the resource-types element
> in file
>
> build/lenya/webapp/lenya/pubs/$MYPUB/config/publication.xml
>
> and restarting Lenya. However, this didn’t have any visible effect. Then I
> commented out the respective resource-type elements in the default
> publication’s configuration file
>
> build/lenya/webapp/lenya/pubs/$MYPUB/config/publication.xml
>
> and restarted Lenya which didn’t work either. So what’s the solution to my
> problem?
ATM the only purpose of the <resource-type> elements in publication.xml
is to assign workflow schemas to resource types.
The menu items are inserted by the modules. To get rid of a resource
type menu item, you have to remove the corresponding <module> element
from publication.xconf.
> By the way, is it okay to just edit those publication.xml files and restart
> Lenya? I did this to change the set of supported languages and it seemed to
> work. On the other hand, the Lenya website seems to tell me that I should
> rerun the build process or something like that.
If you change publication.xml in the build tree, you don't have to run
the deployment process again. But I'd generally recommended to apply
important changes to the source tree (which is usually held in a source
code repository).
> And what are the resource types
> “resource”
This one is for binary resources ("New Media Document").
> and “usecase”
The usecasedocument module provides a resource type which allows to
include usecases as documents.
http://lenya.apache.org/docs/modules/usecasedocument/index.html
HTH,
-- Andreas
--
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
Tel.: +41 (0) 43 818 57 01
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org