> Look at the interface ;) > Now I was hoping the javadoc tool would "inherit" that
Ah. Also Eclipse isn't aware of it... Arjan. On May 4, 2010, at 2:49 AM, Grégory Joseph wrote: > > Hi Arjan, > > On May 3, 2010, at 22:50, Arjan wrote: >>> "startup tasks" are currently deprecated >> >> Hmmm, it's not marked deprecated in SVN. Is that something you can take care >> of then, or should I add a ticket to JIRA? >> >> http://svn.magnolia-cms.com/view/community/magnolia/trunk/magnolia-core/src/main/java/info/magnolia/module/AbstractModuleVersionHandler.java?annotate=32667#l202 > > Look at the interface ;) > Now I was hoping the javadoc tool would "inherit" that but it seems it > doesn't: > http://dev.magnolia-cms.com/ref/latest-stable/apidocs/info/magnolia/module/AbstractModuleVersionHandler.html > > >> >>> look into info.magnolia.module.AbstractModuleVersionHandler#getDeltas >> >> Ok, I'll have to ensure it's not giving me a "Magnolia needs to be updated" >> screen (or maybe I should simply set magnolia.update.auto instead). > > Yeah, if you don't want the update screen, magnolia.update.auto is an option > there. Another hook is the ModuleLifecycle interface, but there you currently > don't have the Task API. > >>> That's not correct [..] >> >> Thanks, I will change the wiki as well. >> >> Cheers, >> Arjan. >> >> >> On May 3, 2010, at 9:59 PM, Grégory Joseph wrote: >> >>> >>> Hi, >>> >>> Some inlined remarks: >>> >>> On May 3, 2010, at 21:20, Arjan wrote: >>> >>>> Hi all, >>>> >>>> For the archives, also added to >>>> http://wiki.magnolia-cms.com/display/WIKI/Handling+module+versions so >>>> comments/changes welcome: >>>> >>>> As #getExtraInstallTasks is only invoked when Magnolia knows the version >>>> has changed, >>> >>> That's not correct. getExtraInstallTasks() is invoked from >>> getInstallTasks() which in turn, as long as you're extended >>> AbstractModuleVersionHandler, is only invoked when *installing* the module, >>> i.e when it was not previously installed. >>> >>> >>>> I've now added extracting the files from "mgnl-files" to #getStartupTasks. >>>> Something like: >>>> >>>> public class MyVersionHandler extends DefaultModuleVersionHandler { >>>> >>>> [..] >>>> >>>> /** >>>> * Forces extraction of the module's files, like template JSPs, from >>>> * <code>classes/mgnl-files</code> into the web application's root. This >>>> * does not yield a "Magnolia needs to be updated" screen. To avoid >>>> * destroying changes, Magnolia will not override files which have been >>>> * modified in the web application. >>>> * >>>> * (In Magnolia, see also Tools, Development tools, to reload at >>>> request.) >>>> */ >>>> @Override >>>> protected List<Task> getStartupTasks(InstallContext installContext) { >>>> final List<Task> tasks = new ArrayList<Task>(); >>>> if ("SNAPSHOT".equalsIgnoreCase(installContext >>>> >>>> .getCurrentModuleDefinition().getVersion().getClassifier())) { >>>> >>>> log.warn("Found SNAPSHOT release; forcing reload of >>>> module files."); >>>> tasks.add(new ModuleFilesExtraction()); >>>> >>>> } >>>> return tasks; >>>> } >>>> } >>>> >>> >>> Good idea; but if you're looking for executing tasks no matter what the >>> current state is, you should probably look into >>> info.magnolia.module.AbstractModuleVersionHandler#getDeltas. (check the >>> source out before applying the following, which I haven't tested;)) >>> public List<Delta> getDeltas(InstallContext installContext, Version from) { >>> List<Deltas> deltas = super.getDeltas(installContext, from); >>> if snapshot { >>> // warning >>> deltas.add(DeltaBuilder.update(.., .., new ModuleFilesExtraction())); >>> } >>> return deltas; >>> } >>> >>> The reason I'm point this out is that "startup tasks" are currently >>> deprecated, for 2 reasons: 1) it's not exactly relevant to have *startup* >>> tasks in something called a "version handler" 2) they're executed in a >>> separate step of the install mechanism, which I've never been too fond of >>> (i.e they're executed "silently", bypassing the UI, no matter what the >>> value of magnolia.update.auto is). >>> >>> We haven't gotten around to remove them altogether, because, as this thread >>> shows once more, they *are* useful. In the future, maybe we'll provide a >>> simpler hook to do what I tried to explain with the code snippet above. >>> >>> Also check the source of >>> info.magnolia.module.AbstractModuleVersionHandler#getUpdateDeltas for >>> further hints as to what's going when starting up. >>> >>> HTH, >>> >>> -g >>> >>> >>>> (I guess this would copy the files twice if a SNAPSHOT module is installed >>>> for the very first time, but I have not tested that yet.) >>>> >>>> If one needs more than this, then maybe one could even execute all tasks >>>> returned by DefaultModuleVersionHandler #getBasicInstallTasks. >>>> >>>> Cheers, >>>> Arjan. >>>> >>>> >>>> >>>> On Apr 29, 2010, at 2:58 PM, Matteo Pelucco wrote: >>>> >>>>> >>>>> On 29.04.2010 10:29, Bert Leunis wrote: >>>>>> Hi Arjan, >>>>>> What I sometimes to force re-extraction of the module files is to >>>>>> manualy lower the version number in the config (in >>>>>> config/modules/mymodule/version), and then restart the app. The >>>>>> versionhandler will see it has a higher version than available in the >>>>>> repository, and bootstap the module. Be careful though: if you had >>>>>> changed for example paragraph or dialog definitions belonging to your >>>>>> module, and not saved those changes, they may be overwritten by the >>>>>> bootstrap and you lose your changes. >>>>>> Regards, Bert >>>>> >>>>> We do it so, but I think you can even force file extraction (it is a >>>>> standard MgnlTask) if your version contains "-SNAPSHOT" placeholder. >>>>> >>>>> It is a small customization of your Module class. >>>>> >>>>> HTH, >>>>> Matteo >>>>> ---------------------------------------------------------------- For list details see http://www.magnolia-cms.com/home/community/mailing-lists.html To unsubscribe, E-mail to: <[email protected]> ----------------------------------------------------------------
