Review and suppress usage of deprecated code (MAGNOLIA-2245)

[MAGNOLIA-2504] DeploymentUtilsPage is completely outdated Created: 09/Dec/08  Updated: 02/Dec/13  Resolved: 02/Dec/13

Status: Closed
Project: Magnolia
Component/s: admininterface, core
Affects Version/s: None
Fix Version/s: 4.2.2

Type: Sub-task Priority: Major
Reporter: Magnolia International Assignee: Magnolia International
Resolution: Fixed Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Template:
Date of First Response:

 Description   

DeploymentUtilsPage is outdated - the only part of it that still works is the i18n reload button. The rest... we're not sure. It's hardly relevant now that we also support freemarker. We'll move the i18n button to the development tools page, and trash this one completely.



 Comments   
Comment by Vasko Gjurovski [ 10/Dec/08 ]

What about for those that still use jsp? How are the changes going to be redeployed now?

Comment by Magnolia International [ 10/Dec/08 ]

Vasko - I don't mind readding this at all, if you briefly explain your working scenario. Are you copying a new jar to your running system ?

Comment by Vasko Gjurovski [ 10/Dec/08 ]

Standard maven webapp development. I have my modules in source. I have the magnolia-empty-webapp in source as well. Add the module in the pom of the webapp. Build the module, build the webapp . Run the webapp. I f iI make any changes in the module (jsp) I must click redeploy in order for the changes to be visible (the new jars to be extracted). And, yes, for "live" sites, I copy the newjars into the lib folder, of the webapp. Is there another way, that I am not aware of?

Comment by Magnolia International [ 10/Dec/08 ]

You didn't say if you copied your new jar when the webapp was running.
However, I highly suspect that the reason you need this button is because module files are (by default) only extracted 1) when updating to a new version of this module 2) when they haven't been modified on the filesystem.

I might re-add it on the dev-tools page, with a dropdown to select your module, then; however, you might want to check the module/update mechanism out.

Comment by Magnolia International [ 10/Dec/08 ]

Moved it to the dev-tools page, would be great if you could have a shot at it

Comment by Vasko Gjurovski [ 10/Dec/08 ]

Just to answer the question above..

No.. the webapp was not running when I was adding the jars.... and 1) No I was not using a new version of the module (which would bu default cause a bootstrap of the files, right?) and 2) No, they have been modified in the jar, but the webapp by default works with the previous state of the files in the file system, until a newer version of the file is supplied (like via redeployment or adding a new version). This probably confirms your suspectoins..

I will try your new deployment page, and provide feedback tommorow... and looking forward to try the new modules as well..

And, if you could provide more info on the module/update mechanizam

Regards,
Vasko

Comment by Philipp Bracher [ 11/Dec/08 ]

It is a general need to extract the jsps on any restart. While developing I normally use an ant builder in eclipse to copy the templates to the webapp. See :MAGNOLIA-1200.

I have written for one project a module version handler which extract the files on every startup if the version is a snapshot. I should probably checkin this version handler.

An other option could be to extract the jsps, when ever magnolia.develop property is set to true (for instance by using a startup task).

Opinions are welcome.

Comment by Vasko Gjurovski [ 16/Dec/08 ]

Yes, I like the idea of automatically extract the jsps. However, I tried it and it does not extract all of the files (hmm..?). I know that the files are supposed to be in mgnl-files, and xmls in mgnl-bootrap (and so on), but am I required to have some kind of predefined structure beyond those folders (ex: in docroot are only css, js and imgs folders allowed?). I tried the new "extractor" of files, but it didnt help either. So what I have now is the following situation, some of the modules have all of their files extracted, some (one) has none, and one module have some of the files extracted, and some not.. very, very, very weird...

Comment by Magnolia International [ 26/Jan/09 ]

We'll hopefully review this completely for 4.0

Generated at Mon Feb 12 03:37:21 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.