Package system

Next topic

Author	Message
Jan Borsodi	Thursday 24 July 2003 1:19:14 am For eZ publish 3.2 we are currently working with the new class import/export system. For the basis of this we are starting the work on a package system which could be used for handling any kind of contributions or site exports. For 3.2 we will only have time for the class (with templates) export. A short overview of the package system. Central to the system is the package definition which is an XML format defining what the package contains, who made etc, what is required for it to work etc.. It's loosely based on the RPM and PEAR package formats. The package definition will be placed in an archive file of some sort. We will probably use tar.gz or zip files (maybe both). A document of the package format will be added at a later time. Here's some of my ideas on how the package system should work (in the future). 1. Create a package module which will store all package data in db tables. For instance you will start a new project/package, create a new release and add entries to the release. Possible entries are just about anything the eZ publish system has available. For instance you could pick classes for export, nodes/objects with children, datatypes, workflowevents, modules, design and plain files. You could manage documentation for the package using eZ publish objects and export it to a general xml format which is included in the package. Since all data is in the DB you can go back to the project, improve you templates or add new entries to the class and then create a new release and export the package again. 2. Allow people on ez.no to start projects. They could request a custom eZ publish installation in which they can do development, create new datatypes, new modules etc. all from the web browser (or with webdav, soap). When they are making a release they would export the package file and send a soap request (automatically) to ez.no for upload to contributions. I think this would boost development of eZ publish parts and it would also make it easier for many people to work together on a project. 3. Detect packages in contribution upload. If it is detected a more advanced page is shown with all relevant information from the package. This avoids the need to repeat changelogs and descriptions which are already in the package. 4. Allow the package system to work with svn, it could for instance fetch the difference between two revisions and include the diff in the package. This would make it a lot easier to create security and important bugfixes. 5. Download new packages from ez.no. This can be addons made by eZ system or contributed packages by the community. Any comments? -- Amos Documentation: http://ez.no/ez_publish/documentation FAQ: http://ez.no/ez_publish/documentation/faq
Paul Forsyth	Thursday 24 July 2003 1:42:32 am Sounds good, Jan. Im a little worried that there wont be an import facility in 3.2 for the exported classes. Can you clarify this? How soon after 3.2 can we expect objects to be packaged in this way? paul
Jan Borsodi	Thursday 24 July 2003 1:45:49 am 3.2 will come with an import facility for class exports. If not the exports would be useless ;) -- Amos Documentation: http://ez.no/ez_publish/documentation FAQ: http://ez.no/ez_publish/documentation/faq
Paul Forsyth	Thursday 24 July 2003 2:07:40 am Yes, i saw that. Had to ask the question though :) Once the class import/export is complete will the matter of implementing the object part be straightforward, and come not long after the release of 3.2? Having class export/import is v good, but having this work with objects is v important. paul
Jeroen van Gorkum	Thursday 24 July 2003 2:09:22 am this worries me a bit from an administration point of view. * is a package only allowed to make changes / add to the database, or to the filesystem, too? * would it be possible to revert to the state before the import completely? * what if 2 packages 'depend' on each other, i.e. package 'x.a' is an extension to package 'x', and i uninstall them in the wrong order (x first), or only uninstall 'x'? jeroen.
Tony Wood	Thursday 24 July 2003 2:41:55 am I think one of the things to look out for with the package system will be the varying versions of eZ that people use. Some project are developed using 3.0 some 3.1 etc. If I produce a package that only works with 3.2 because it uses widget x, then this will break any version 3.1 systems. I think the package system needs 1. Each package needs a list of eZ versions it compatible with. 2. List possible/know conflicts. Manually tasks etc 3. List if it requires extra components and may download of list them. I am guessing that many packages will be conduits to other systems. 4. System version PHP, MySQL versions. I think there needs to be a test and safe upgrade option for eZ. This should be as automated as possible, with checks and warnings where manual intervention is required. It does raise a problem though, this will not work if major changes such as overrides are implemented in every release ;-) tony Tony Wood : twitter.com/tonywood Vision with Technology Experts in eZ Publish consulting & development Power to the Editor! Free eZ Training : http://www.VisionWT.com/training eZ Future Podcast : http://www.VisionWT.com/eZ-Future
Jan Borsodi	Thursday 24 July 2003 6:53:52 am We've already thought about dependencies etc. I'll add the 'example' xml format as a document so you can see what our current ideas are. -- Amos Documentation: http://ez.no/ez_publish/documentation FAQ: http://ez.no/ez_publish/documentation/faq
Jan Borsodi	Thursday 24 July 2003 7:16:43 am First version of the document here: http://ez.no/developer/ez_publish_3/documentation/incoming/package_format -- Amos Documentation: http://ez.no/ez_publish/documentation FAQ: http://ez.no/ez_publish/documentation/faq
Zoltan Szabo	Sunday 27 July 2003 10:03:05 pm Please don't forget about PostgreSQL users...
Tony Wood	Tuesday 29 July 2003 4:46:31 am Could the package system also include a database integrity checker, this would ensure all the correct database changes have been made for the package and the version of eZ they are running. This would be a useful standalone tool for developers anyway. Tony Wood : twitter.com/tonywood Vision with Technology Experts in eZ Publish consulting & development Power to the Editor! Free eZ Training : http://www.VisionWT.com/training eZ Future Podcast : http://www.VisionWT.com/eZ-Future
Jan Borsodi	Tuesday 29 July 2003 1:37:22 pm Database integrity checks is important. They fit right into the <require> part. And the package will be made to work with any database eZ publish supports. PostgreSQL users should not worry ;) I'm also thinking about having interactivity in the packages. For instance for an object import you could asked to choose the starting point of the import. -- Amos Documentation: http://ez.no/ez_publish/documentation FAQ: http://ez.no/ez_publish/documentation/faq
Tony Wood	Thursday 31 July 2003 1:53:18 am Could you explain this interactive element further Jan, I don't see what you mean. Tony Wood : twitter.com/tonywood Vision with Technology Experts in eZ Publish consulting & development Power to the Editor! Free eZ Training : http://www.VisionWT.com/training eZ Future Podcast : http://www.VisionWT.com/eZ-Future
Paul Borgermans	Thursday 31 July 2003 2:08:42 am >I'm also thinking about having interactivity in the >packages. For instance for an object import you could >asked to choose the starting point of the import. Great, I assume you mean here the entire xml archive to be relocated. Do you have plans/ideas to do this in a fragmented way (different object trees in the xml archive are relocated to different nodes)? Or maybe this is better left to other tools that can manipulate the xml archive, like mapping attributes to a different class than the original. Or maybe even extract parts of the data from the xml attribute text fields which could be stored in other dedicated attributes. Regards -paul eZ Publish, eZ Find, Solr expert consulting and training http://twitter.com/paulborgermans