[NPMCLI-100] Existing magnolia.zip lets jumpstart ignore -m and -e option Created: 10/Feb/17 Updated: 03/Dec/20 Resolved: 21/Feb/18 |
|
| Status: | Closed |
| Project: | Magnolia CLI |
| Component/s: | None |
| Affects Version/s: | 1.0.7, 2.0.0-snapshot-167 |
| Fix Version/s: | 3.0.0 |
| Type: | Bug | Priority: | Neutral |
| Reporter: | Christoph Meier | Assignee: | Jaroslav Simak |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Template: |
|
| Acceptance criteria: |
Empty
|
| Task DoD: |
[ ]*
Doc/release notes changes? Comment present?
[ ]*
Downstream builds green?
[ ]*
Solution information and context easily available?
[ ]*
Tests
[ ]*
FixVersion filled and not yet released
[ ] 
Architecture Decision Record (ADR)
|
| Bug DoR: |
[ ]*
Steps to reproduce, expected, and actual results filled
[ ]*
Affected version filled
|
| Release notes required: |
Yes
|
| Documentation update required: |
Yes
|
| Date of First Response: | |
| Epic Link: | CLI v3 |
| Sprint: | Kromeriz 134, Kromeriz 135 |
| Story Points: | 3 |
| Description |
|
When running the jumpstart command,and if there is already magnolia.zip - no bundle artifact downloaded. The "easiest" fix seems to be to delete the zip file after successful installation Implementation
|
| Comments |
| Comment by Christopher Zimmermann [ 24/Feb/17 ] |
|
Im not sure the best approach - but a few things to consider:
|
| Comment by Christoph Meier [ 28/Feb/17 ] |
|
czimmermann, |
| Comment by Robert Kowalski [ 06/Mar/17 ] |
|
cool ok. right now we rename a bundle filename which contains informations about the version (version number and edition) to `magnolia.zip`. An example is `magnolia-community-demo-bundle-5.5.2-tomcat-bundle.zip` which gets renamed to `magnolia.zip`. While writing those lines I am not exactly sure anymore why someone would set up the same magnolia version twice in the same directory with jumpstart. When switching between different versions and zipfiles we will run into side-effects because of an unclean magnolia directory were different versions mix up. How about: 1. bundle-zipfiles are downloaded to a folder called "cache", located in a different location than the jumpstarted magnolia installation. |
| Comment by Christoph Meier [ 06/Mar/17 ] |
|
1, 2: The idea with the "cache" sounds good to me. 3: How can you figure out what version is installed? One possibility is to parse apache-tomcat/webapps/magnoliaAuthor/README.txt .. but probably there are better ways to do that. |
| Comment by Robert Kowalski [ 16/Mar/17 ] |
|
There is the idea of pulling in tomcat from the official apache download page and in parallel the files from magnolia. this would speed up download times and decrease cache size. how we are finding out the current magnolia version we have to investigate. parsing the readme is def. an option. |
| Comment by Robert Kowalski [ 16/Mar/17 ] |
|
hm actually the tomcat is just 9MB. not sure if its worth the implementation effort needed, at least for this issue. |
| Comment by Christopher Zimmermann [ 30/Oct/17 ] |
|
cmeierfgrillimmichel |
| Comment by Maxime Michel [ 31/Oct/17 ] |
|
I would see such a cache in a hidden folder in the user's directory, something like ~/.magnolia/ for instance. I don't know where that is on Windows but there is an equivalent for sure. However, I personally don't see much value in going this far. What business use case does this solve? |
| Comment by Christopher Zimmermann [ 31/Oct/17 ] |
|
The use case is solving the bug, but also letting someone jumpstart an already downloaded bundle. I've had this several times at home where I had a slow connection and wanted to use a bundle that I already had downloaded. |
| Comment by Christoph Meier [ 31/Oct/17 ] |
|
The easiest solution for the issue reported here is just to delete the zip at the end of jumpstart . |
| Comment by Federico Grilli [ 31/Oct/17 ] |
|
If I remember correctly, I had to rename that file to magnolia.zip due to some glitch in the unzip npm package we use there. If we could get rid of that workaround, we could have the original zip file there and simply check, in case an -m option is provided, if the file name is the same we have in the current folder, then proceed accordingly. I also like the idea of a magnolia cache folder. To make it work cross-platform, a good place may be npm's default directory for globally installed packages, e.g., on a Mac that could be /usr/local/lib/node_modules/mgnl/cached_bundles (even though, on second thoughts, that probably requires sudo permissions). |
| Comment by Maxime Michel [ 01/Nov/17 ] |
|
It would probably be worth investigating if the issue in the NPM package still is one, as a first step. At the pace those move, it's probably been solved. If not, evaluate if the package is still being worked on, and either create the issue or try to find an alternative. To avoid permission issues, most software that needs such hidden mechanics places it in the home folder. But to me this seems a big effort for the problem at hand. I would rather do that the day we have more than one feature that requires it. |
| Comment by Christopher Zimmermann [ 07/Feb/18 ] |
|
With version 3 and the new "webapps" feature now two files are downloaded to the directory: "magnolia.war" and "tomcat.zip". |
| Comment by Christoph Meier [ 23/Feb/18 ] |
|
Since this ticket is closed now: What has been done? Are files getting deleted now when been unpacked once, or are they still there? |
| Comment by Christopher Zimmermann [ 23/Feb/18 ] |
|
cmeier Please see "implementation" in the ticket description. |