[forge-issues] [JBoss JIRA] (FORGE-957) Create "Stacks" addon, that allows providing stack implementations to supply default values in dialogs

[ https://issues.jboss.org/browse/FORGE-957?page=com.atlassian.jira.plugin.... ] George Gastaldi commented on FORGE-957: --------------------------------------- As I was speaking with [~vineet.reynolds]: {quote} <gastaldi> I am not sure if the stacks.yaml may help in this scenario <vineetreynolds> hmm well I'm not entirely sure about storing everything in a configuration file <vineetreynolds> stacks.yaml is for jboss as only <gastaldi> yes <vineetreynolds> It wouldnt help for other containers <vineetreynolds> And also for other 'stacks' <vineetreynolds> Besides some of this configuration that we speak of, can come from Facets <gastaldi> I think it is meant to be something like FORGE-378 <vineetreynolds> Well yes <vineetreynolds> That is one part of the solution <gastaldi> Do you have any suggestions ? <vineetreynolds> The other is to read this information out from project POMs etc <gastaldi> but the POM may not have this info <gastaldi> I mean, if we take only the dependencies in account <vineetreynolds> Yes, POMs are just one possible source <vineetreynolds> We have to account for multiple sources to evaluate whether some portion of a stack is already available <vineetreynolds> I think we should also consider extracting that info from .settings (if I'm not mistaken) <vineetreynolds> The Eclipse .settings dir to be specific <gastaldi> hummm <gastaldi> that would be another source of information <vineetreynolds> Yeah, we could start with the more definite sources and then work our way down <vineetreynolds> Container choices could have multiple sources of info <gastaldi> but this won't tell if the user wishes to run in Wildfly, for example <vineetreynolds> like usage of the deploy plugins in POMs <vineetreynolds> Hmm no, isnt the stacks addon supposed to help the user reduce the number of choices based on what's in the stack <gastaldi> well, given the description of FORGE-957, I am not so sure <vineetreynolds> In that case, if he wishes to run on a new stack, he'd have to configure/choose the container first <vineetreynolds> Hmm I think there are too many feature requests in here <vineetreynolds> All bringing their own constraints <gastaldi> yes, that's the point where I stood <vineetreynolds> I think we should nail down what 957 is all about <vineetreynolds> In my opinion, it means that if WildFly is a chosen container, then in dialogs should provide inputs from stacks.yaml <vineetreynolds> I dont think stacks.yaml supports WF but I might be wrong <gastaldi> that's only an example <gastaldi> it does not actually <vineetreynolds> The idea behind stacks.yaml is that if you have AS 7.1.1 or EAP 6.0 , 6.0.1 or 6.1, then different versions of dependencies tested on those containers would be populated in the project POMs <vineetreynolds> Thats my idea about how 957 should work <vineetreynolds> Ditto for WF <vineetreynolds> So if WF 8.0 Final is tested against RF 5.0 <gastaldi> Yes <vineetreynolds> then the RichFaces 5.0 BOM should be proposed first <vineetreynolds> or should be chosen <vineetreynolds> Whatever <gastaldi> it's a matter of choosing the right BOM <vineetreynolds> Yep <vineetreynolds> So maybe we should ask Lincoln for confirmation on the scope <gastaldi> probably yeah, I think the scope is too abroad <vineetreynolds> and then set out different ways to obtain info on whether the user will deploy on the containers <vineetreynolds> Yeah <vineetreynolds> Obtaining sources of this info is one part, plugging these inputs into various addons is another {quote} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira