[NPMCLI-120] Jumpstart can download and use webapps instead of bundles Created: 20/Mar/17 Updated: 28/Feb/18 Resolved: 30/Jan/18 |
|
| Status: | Closed |
| Project: | Magnolia CLI |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 3.0.0 |
| Type: | Story | Priority: | Neutral |
| Reporter: | Christopher Zimmermann | Assignee: | Milan Divilek |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
||||||||||||||||||||||||||||
| Issue Links: |
|
||||||||||||||||||||||||||||
| 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)
|
||||||||||||||||||||||||||||
| Date of First Response: | |||||||||||||||||||||||||||||
| Epic Link: | CLI v3 | ||||||||||||||||||||||||||||
| Sprint: | Kromeriz 126, Kromeriz 130, Kromeriz 131, Kromeriz 132 | ||||||||||||||||||||||||||||
| Story Points: | 8 | ||||||||||||||||||||||||||||
| Description |
|
Jumpstart should support grabbing a magnolia webapp and a tomcat and putting them together in a working setup that functions the same as a bundle. Reason:
Info on existing bundles and webapps: — Proposed options: Propsal 1Behaviour with no options mgnl jumpstart Default becomes:
Additional options Specify the full webapp or bundle name: ie Proposal 2Same as above - but
|
| Comments |
| Comment by Federico Grilli [ 05/Apr/17 ] |
|
I'd rather not have tons of options for available webapps cause I'm afraid that would get messy, also considering that the offer might be increased in the future. I like the idea of a --list option to display available web app flavours. |
| Comment by Robert Kowalski [ 06/Apr/17 ] |
|
Lets work in an iterative way on this and split this up.
This way we get several benefits:
|
| Comment by Robert Kowalski [ 06/Apr/17 ] |
|
Set Storypoints to 3, have to readjust as soon as we know how we want to continue in Step 2 / 3 Probably overall Storypoints are 5 |
| Comment by Christopher Zimmermann [ 06/Apr/17 ] |
|
Splitup plan sounds good to me. |
| Comment by Robert Kowalski [ 11/Apr/17 ] |
|
depends on |
| Comment by Robert Kowalski [ 11/Apr/17 ] |
|
Notes from discussion with creichenbach:
|
| Comment by Christopher Zimmermann [ 11/Apr/17 ] |
|
"even if we just need the additional scripts and small mods for tomcat we still introduce another dependency which makes releasing harder" Could the zip build of these files be automated into one of the existing releases? I think the additional work here is less then the work of providing additional bundles. |
| Comment by Robert Kowalski [ 12/Apr/17 ] |
|
I think it has to be tested that everything still works for the CLI. Right now the bundles are self-contained and integration tested. I will double check with someone who knows the release process better. |
| Comment by Cedric Reichenbach [ 12/Apr/17 ] |
|
I'm not sure about the required effort for releasing those scripts and config files separately. If we did such a thing, it would probably be in the form of a blank, pre-configured, magnolia-ready tomcat. However, this would need some thorough architectural considerations first, about in which form to release, how to integrate with existing bundles etc. On the other hand, if you have a look at what those files actually do, it's questionable if we need them at all. All they add on top of standard tomcat is:
|
| Comment by Christopher Zimmermann [ 08/Jun/17 ] |
|
I like the point "it's questionable if we need them at all". Worth considering. An important consideration is simply the consistancy between what you get with the CLI vs the bundles. Ideally they would behave similiarly - for example so that existing docs and tutorials are correct. It would be great to do the "thorough architectural considerations first, about in which form to release, how to integrate with existing bundles etc." and have a proposal or two about how to proceed. |
| Comment by Christopher Zimmermann [ 28/Nov/17 ] |
|
I think a good next step would be to identify the tasks and estimate the effort that the CLI could get a webapp and get all other necessary files so that it behaves just like the bundles. IF this effort is not to high, then it's probably the best approach simply because Magnolia will behave in a consistent way - and so docs and trainers do not need to make exceptions. |
| Comment by Jaroslav Simak [ 11/Dec/17 ] |
|
I can see couple of ways this can be done:
Imho we should stay consistent and provide same functionality (=use same tomcat setup) for bundles and webapps when using mgnl jumpstart. I'd try to avoid confusion as much as possible, ideally user shouldn't notice if he's using bundle or webapp (except for webapp specific setup of course). And for the solution, separate maven module for the tomcat seems most robust to me. The other ones are kinda "meh" |
| Comment by Cedric Reichenbach [ 11/Dec/17 ] |
|
I was involved the last time this was discussed (and then postponed), and the reason was basically that simple solutions (roughly 2. - 4. in your list) would be rather hacky, e.g. rely on content from our git repos. So it seems you came to the same conclusion as us regarding those. What exactly would 1. mean? Would that be something similar to the bundle projects we already have, just a larger variety of supported webapps (and possibly without demo content)? |
| Comment by Jaroslav Simak [ 11/Dec/17 ] |
|
Hey Cedric, what i meant is to add new generated zip file that would be created upon release. That file would contain clean tomcat and stuff that is in our ce/ee bundle. Afaict we do create bundles for some of the modules we have (backup for example), this would be just yet another bundle containing mentioned stuff. Since we already know how to create such bundles, it shouldn't be a problem to add a maven plugin that would create it to the ce/ee bundles. I hope that what i wrote makes sense. |
| Comment by Cedric Reichenbach [ 11/Dec/17 ] |
|
Not sure if I understand correctly... The backup bundle seems to be just a collection of related libraries/jars, but doesn't contain a tomcat or webapp if I'm not mistaken, right? So what I understand is that:
This sounds like the cleanest solution without ripping apart our current setup, but has the disadvantage of having to create a bundle project for each webapp to be supported. On a side note, from what I've seen and heard, the current state of bundle building is a bit messy, sprinkled with boilerplate config and could be refactored a bit before extending it even further. Then again, this sounds like a lot of headache. (feelsbadman) |
| Comment by Jaroslav Simak [ 11/Dec/17 ] |
|
That's not what i meant, choosing backup module as an example was a poor idea, i will try to explain it better If you have a look at this pom.xml, theres maven-assembly-plugin that creates a bundle. It's descriptor can be found here. What i propose is either to add new configuration that would create "empty tomcat bundle" (no webapps inside), or add a new maven submodule to ce-packs/ee-packs, that would contain configuration for "empty tomcat bundle" and would contain the maven-assembly-plugin config in it's pom.xml. This way we'd have magnolia-ready tomcat tar.gz / zip file available for us on our nexus. We could download this file, unpack it, download webapp specified via cli, put it in and be ready to go. Having bundles for all of the webapps seems too much overkill for me if we can generate tomcat with all the files we need without webapps. I hope it's now clear what i meant |
| Comment by Cedric Reichenbach [ 12/Dec/17 ] |
|
Ah, now I see. Ideally, this could be used for the current bundles as well to mitigate the boilerplate config problem I mentioned above. If you look at the assembly config of community-demo and enterprise-pro-demo, they are largely the same. So e.g. the new barebone project would do most of that, and the bundle-specific ones would just drop in their corresponding webapps. |
| Comment by Jaroslav Simak [ 12/Dec/17 ] |
|
Sounds good to me |
| Comment by Milan Divilek [ 23/Jan/18 ] |
|
mgnl jumpstart --webapp magnolia‑enterprise‑standard‑webapp magnolia‑enterprise‑standard‑webapp is not enough information to get the webapp. Also repository(e.g. magnolia.enterprise.releases) and groupId(e.g. info.magnolia.eebundle) are required. So I decided not implement --webapp and --bundle options Implemented solution |
| Comment by Christopher Zimmermann [ 23/Jan/18 ] |
|
Im fine with the list of all webapps right away - rather than the two part thing I proposed. I think the default should be the magnolia-community-webapp. I still think we should support the --webapp parameter, it supports documentation and training exercises and automation. It could be limited to only work on the webapps that are "configured" in that list. Im not sure how much use there would be to support getting ANY webapp by also being able to specify repository and groupid. (Seems nice for completeness, but I dont see a pressing usecase) And, of course my original proposal to also be able to get bundles is totally redundant with being able to get webapps and was nonsense. |
| Comment by Milan Divilek [ 24/Jan/18 ] |
that make sense, I'll implement it
Would be nice to have it, but i don't see use case if we limit download only from magnolia nexus.. |
| Comment by Christopher Zimmermann [ 24/Jan/18 ] |
|
Great. |
| Comment by Christopher Zimmermann [ 25/Jan/18 ] |
|
Error message: Your mgnl-cli.json configuration ([path to mgnl-cli.json file]) does not contain the new tomcatDownloadUrl and availableWebapps nodes introduced in version 3.0. Please either: |