[ https://jira.jboss.org/jira/browse/GTNPORTAL-870?page=com.atlassian.jira.... ] Matt Wringe updated GTNPORTAL-870: ---------------------------------- JBoss Forum Reference: http://community.jboss.org/message/531437 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/GTNPORTAL-870?page=com.atlassian.jira.... ] Julien Viet updated GTNPORTAL-870: ---------------------------------- Summary: Portal entity creation and configuration in a war file. (was: add portlet configuration via xml files) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/GTNPORTAL-870?page=com.atlassian.jira.plugi... ] Antoine Herzog commented on GTNPORTAL-870: ------------------------------------------ Hello, I fully agree with the comment of Nic Essling. I have help several companies to set up their portal, and always recommended the "files and war for config of portal". I have seen some project starting with using the "Portal Admin + DB storing for config of portal"... and ending to a big mess. They usually rollback to the "files and war config of portal". if this can help : some point of view. The "Portal Admin + DB storing for config of portal" is a nice feature. It allows quick start of a portal, for a newbie, and for evaluation. It allows a easy way to view the portal config (read only), for dev. This is sometime usefull to see what's going on with the "files and war config of portal", when deploying, re-deploy, hot deploy. It allows prototyping of the portal, very usefull for workshop with the end users and designer. The "DB storing for config of portal" is necessary, as a way to centralize all the config of the portals. It is a central point when running the portal, to get all the config. But there is a big drawback cause by this centralization. It is not possible to put together several developments made on several DB. So no incremental or teams development on separate environment. It is not easy to go from dev environment to integration/test to production. It is not easy to redeploy only a part of the portal (sometime usefull in production). so... my point of view is : - keep (of course) the "Portal Admin + DB storing for config of portal" (or storing in the JCR) and add (or retrieve) the "files and war for config of portal" ie : config in file and hot redeploy mechanism. - may be there a trick to find to get the "files and war for config of portal" or something similar with the storing in the JCR. - see the other JIRA about the redeploy of extension portal container : https://jira.jboss.org/browse/GTNPORTAL-315 the aim is to ease the portal deployment from dev environment to integration/test to production, and allow multiple dev environments. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/GTNPORTAL-870?page=com.atlassian.jira.plugi... ] Antoine Herzog commented on GTNPORTAL-870: ------------------------------------------ on my opinion, the round-trip configuration have been asked and discussed a lot for JBoss Portal... and it is not really feasible. the trouble is : centralization. if you have several bags of rock stones, and you put all of them together in one bag... how do you separate them back in each of their origin bag ? especially if you add one or two stone directly in the big bag : in which original bag to you attribute it ? so... round-trip configuration could be done... but it would be a huge and complex tool... and it is not really useable then. on my opinion, the focus is : - configuration of a new portal and new portlets can be done in GateIn, even if a bit more complicated than in JBoss Portal : may be allow/add some more simple way. - globally maintain a focus and high priority on this way of making portal and portlet deployment. - hot deploy of these artifacts (cf jira GTNPORTAL-315) not sure there a lot to do in this jira itself. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/GTNPORTAL-870?page=com.atlassian.jira.plugi... ] Antoine Herzog commented on GTNPORTAL-870: ------------------------------------------ Nic, yes, the idea of an export of the config that is in the DB "as it is" could be usefull to get the xml fragments for each things. the idea would be to separate only on the Portal Container level. but separation for each Portal Container does not means separation for each artifact (extensions) that provided the final DB configuration. so it is not really a round trip configuration tool, but yes, it could be a usefull export tool... after prototyping a portal (with users/designer participation), this could help a lot to build the xml descriptor files to make the portal. also, this could be an help to learn how to make the descriptor : make a change in the portal with the UI admin, export the config, then see the diff in the files. well... this have been discussed too for JBoss Portal. don't know why it has not been made. may be not enough interest by the developpers. surely nobody proposed the feature as a contribution. as far as I am concerned, I managed with descriptors written by hand, and some rare times to go and look in the UI admin. this for several portals, on several projects... this way was ok. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira