[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.
Fair enough.
However, in consequence neither the -e nor -m option have any influence.
It just takes the version which was chosen the last time when it had to download.

The "easiest" fix seems to be to delete the zip file after successful installation

Implementation
With the new tomcat & webapp feature - (https://jira.magnolia-cms.com/browse/NPMCLI-120) the directory starts to get cluttered with the downloads.

  • The webapp and tomcat are downloaded to a new directory "downloads".
  • The files are not renamed to generic names but keep their full names.
  • When user runs jumpstart - if the exact requested webapp is present in the downloads directory, then it is used. If they had requested a different webapp, then that webapp is downloaded and extracted. This ensures that the user always gets the exact webapp that they had requested.


 Comments   
Comment by Christopher Zimmermann [ 24/Feb/17 ]

Im not sure the best approach - but a few things to consider:

  • Its a benefit to be able to run jumpstart with an already downloaded bundle. People may have a local custom bundle, People may have no internet connection.
  • Its a little wierd to have the downloaded magnoila.zip hanging around, but again it can be a benefit. would it be better if the name was the actual bundle name - so someone knows what it is?
  • I think that when the command notices a local bundle - it should ask to use it - or to do the normal download path (possibly deleting and overrideing it - or instructing user to remove the bundle zip if they dont want to jumpstart it.
  • Possibly add another option to specify which local or remote bundle to use with a path or url. Could be helpful for automating things like CI.
Comment by Christoph Meier [ 28/Feb/17 ]

czimmermann,
the current situation definitively is a "bug" - or leads to situations where the CLI does not what the user expects.
About the solution, i am open. But " ... when the command notices a local bundle - it should ask to use ..." ... is like:
Ok, you asked to install EE bundle 5.5.1 but i have found here a zip of another version, what should i do?
???

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.
2. On installation we take a look if we have the version already in the cache. --redownload would overwrite the cached version
3. If jumpstart is run in a directory where magnolia was already installed we error with a message like: "Magnolia v5.5.0 was already installed in this directory. Overwriting it can lead to unwanted side-effects. Use --force if you want to continue anyway"

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.
Independent from the version which is installed: I guess Overwriting / over-installing is never or only rarely desired. So, a warning and --force sounds good for me.

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
I also like the "cache" concept proposed by rkowalski on 06/March.
Can you suggest where a good location for this cache directory would be? Any objections to the cache concept? Could we expect permissions problems? Will it work cross-platform?

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 .
Caching is already a new feature. (Depends how much time we can invest in this issue.)

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".
I'd propose that when running jumpstart we get a new "downloads" or "downloaded" directory where these two files are put, but the webapp keeps its actual name as previously discussed.

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?
Has the issue been resolved?

Comment by Christopher Zimmermann [ 23/Feb/18 ]

cmeier Please see "implementation" in the ticket description.

Generated at Mon Feb 12 04:46:31 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.