Florent André schrieb:
=== Patch to Module.xml ===
* The idea is to add some tags in order to have "dev status" of each
module.
<module xmlns="http://apache.org/lenya/module/1.0";>
<moduleinformations>
<objectives> describe why do this module </objective>
<longdescription> description that is show to end
user</longdescription>
<curentstate> dev / usable with care / stable / ... </curentstate>
</moduleinformations
<technicalinformations>
I wouldn't require to change the structure of existing elements
(backwards compatibility).
So, what is the best way ?
- not add the "technicalinformations" section and just add other sections ?
I think this would be the best option – don't change the existing
structure, only add new sections. WDOT?
- create a specific file with this informations ?
Maybe we should use separate files for the module documentation (e.g.,
$MODULE_HOME/docs/*.xml) to avoid overloading the module.xml.
<id>org.apache.lenya.modules.ac</id>
<export package="..."/>
<depends module="..."/>
<package>org.apache.lenya.modules</package>
<version>0.1-dev</version>
<name>Access control</name>
<lenya-version>@lenya.version@</lenya-version>
<description>Access control</description>
</technicalinformations>
<statusinformations>
<curentversion>
<developers>
<person name=".." email="..." id="DB"/>
</developers>
<problems> (or warning?)
<problem priority=".."> knowing problems </problem>
<problems>
<changes>
<release version="2.1.12" date="..">
<action dev="all" type="update">
</release>
</change>
<howtoinstall> installation instructions if any </howtoinstall>
<howtouse> how to use module's functions or module's interface
</howtouse>
</curentversion>
The "future versions" section can IMO be omitted, we have bugzilla for
this purpose.
In my mind, bugzilla is more for "coding problems", here "future versions"
is more a end-user function description.
IMO Bugzilla is equally suitable for end-user requirements, e.g.
enhancement requests.
<futureversion>
[...]
<futureversion>
</module>
Some of this tags are inspired by the cocoon file :
apache-lenya-2.0.2-src/externals/cocoon_2_1_x/status.xml
Maybe the Maven POM would be another alternative?
http://maven.apache.org/pom.html#More_Project_Information
I really hope we'll move to Maven someday, this might simplify the
migration.
Yes this xsd seems to me very cool ! But, IMO this is a developer centric
view, I don't see information with end-user view.
OK, this is a good point. I'd suggest to include only
development-related info in module.xml and use a separate directory for
the user documentation (see above).
-- Andreas
My fist idea is to have an easy-filling file for dev that can be set in
visibility on the Lenya website with an automatic svn borwsing of this
file.
This user visibility is an important piece for a larger use of Lenya.
Maybe this proposal is a little bit complicated, but I think that this
informations will be useful for potential co-dev and for (end-)user :
see
what is the module spirits, his status and his future capabilities.
Is it realistic to assume that this information will be added? Well, I
guess we'll see :)
I hope too ! :) IMO if the system is simple and increase the use of modules
and community size, this information will be fill in.
[…]
=== SVN browsing ===
Andreas : "ATM the code to update the SVN changes is in the forrest
module,
which is rather confusing. I think we should create a new module for
this
purpose."
==> @andreas : Do you have a pointer (class or pipeline name) to the
code
in the forrest module ?
Sure, this is the usecase which updates the changes:
http://svn.apache.org/viewvc/lenya/docu/modules/forrest/java/src/org/apache/lenya/modules/forrest/UpdateChanges.java?view=log
Thanks ! This is a good starting point.
-- Andreas
--
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
Tel.: +41 (0) 43 818 57 01
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
