[jbosstools-dev] Regarding Stacks, Runtimes, and Remote Descriptors

[Snjezana Peco]

I think we need to keep all of those options (since they already exist). 
Each of them has its advantages/disadvantages.
I agree with the proposed changes and emphasize that stacks don't have 
the following properties:

- license
- size
- requireSso (see https://github.com/jbosstools/jbosstools-base/pull/50)
- disclaimer

Snjeza

On 3/1/2013 10:22 AM, Rob Stryker wrote:
> I would like to hear some feedback here from Max and Snjezana.
>
> On 02/28/2013 08:05 PM, Fred Bricon wrote:
>> I  mostly agree with the changes you described. Here's my 0.02€ :
>> - I strongly believe runtimes should be split into different stacks
>> descriptors, but I don't like the idea of having to maintain a fork of
>> the JDF one. We should only add extensions (old AS'es, seam, ESB ...).
>> - I believe the merge all stacks descriptors in one metamodel should be
>> done in stacks client. I know Raphael kinda started working on that a
>> few months back, he probably can give us his insight.
>> - runtimes in stacks could list their managing JBT plugins in the
>> labels property : i.e if ESB runtime can be downloaded, but no ESB
>> plugin is installed, the we'd be able to discover both the runtime AND
>> its associated plugin
>>
>> Fred
>>
>> Le mercredi 27 février 2013 18:22:35, Rob Stryker a écrit :
>>> Regarding Stacks, Runtimes, and Remote Descriptors
>>>
>>> Hi All:
>>>
>>> This email is to try to begin discussion on some recent duplication of
>>> code and responsibilities, which should probably be fixed before
>>> things get too comfortable.  I'm speaking specifically about the role
>>> of discovering runtimes to download, where that's done, how that's
>>> done, and which responsibility belongs to who. Forgive me if the email
>>> is long, as I am trying to be thorough.
>>>
>>> Currently, there are three places from which runtimes to download may
>>> be discovered.
>>>
>>> 1) base/runtimes has an extension point named downloadRuntimes, which
>>> is used by AS Tools and Seam Tools (and perhaps others).
>>>
>>> 2) a remote descriptor file which acts as a second arm of 1) and is
>>> basically an xml form of 1) used to dynamically add new runtimes as
>>> they become available
>>>
>>> 3) The new Stacks methodology, currently stored in
>>> jbosstools-central/maven/plugins/org.jboss.tools.maven.project.examples
>>>
>>> We should begin unifying these three locations into one, but the goal
>>> is to do it correctly. So, I would first like to list the benefits of
>>> each.
>>>
>>> a) downloadable runtimes provided through the extension point cannot
>>> be removed without a maintenance or major release of some type, and
>>> for this reason are semi-permanent
>>>
>>> b) downloadable runtimes available via the remote descriptor file may
>>> be added OR removed at will. This provides flexibility and
>>> post-release updates are easy.
>>>
>>> c) The new stacks section has a more robust model capable of providing
>>> more information than the downloadable runtimes does. However, the
>>> plugin requires several libraries and is currently placed in the
>>> jboss-central module, where others may not make use of it.
>>>
>>> d) the Stacks yaml file does not provide a place to access the file
>>> size for the download, however it does provide a 'labels' section,
>>> which seems extendable to add whatever properties you may want to add.
>>>
>>> At first glance, it seems that Stacks is the superior framework. It is
>>> extensible, it can have unlimited labels (aka properties) if desired,
>>> and it already provides more information which is usable to others who
>>> may want it. To make use of stacks inside Runtimes, however, we'd
>>> either need to:
>>>      a) Expand the API in runtimes to allow other plugins (like in
>>> central) to provide downloadable runtimes,  or,
>>>      b) Push 'stacks' out of central and down into runtimes, as its own
>>> plugin upon which runtimes.core and runtime.ui can depend.
>>>
>>> The main negative of pushing stacks into base/runtimes, in my opinion,
>>> is that there are a significant number of libraries required. It's not
>>> too much, by far, but it is about 7 jars totalling about 1 megabyte.
>>> Whether these jars belong in base/runtimes is debatable, and currently
>>> we do not have a "3rd-party dependencies" section in base where we
>>> organize common dependencies and versions together so that each plugin
>>> doesn't need to bundle their own 3rd party libraries. I admit, this is
>>> a debate for another time, but, I just wanted to point out that
>>> pushing the stacks logic down into runtimes would be another example
>>> of this issue.
>>>
>>> Even still, I would argue that we should push stacks into its own
>>> small plugin below runtimes, deprecate the "downloadRuntimes"
>>> extension point, and the online downloadRuntime.xml (wherever the file
>>> is, I forget).
>>>
>>> However, once we do that, there are many more questions. The first is,
>>> who's job is it to provide the yaml file from which stacks are generated?
>>>
>>> Currently there is only one yaml file, and it is referenced directly
>>> via a github url. Aside from how (IMO) this is fairly crazy in itself,
>>> it causes another problem. The stacks client jar *can* cache the yaml
>>> file and only update if the timestamp has changed, however, when
>>> checking the timestamp on a github file, there isn't one...
>>>
>>> This would seem to imply we should take control of the yaml file
>>> ourselves and put it NOT in github but rather in a release-specific
>>> online-accessible folder, ex: jbt4.1/stacks.yaml, jbt5.0/stacks.yaml,
>>> etc.
>>>
>>> The problem with this is that we are then taking control away from the
>>> jdf team, and once we take the file away, it is our job to keep it
>>> updated and in synch. This may cause errors if we are not very careful.
>>>
>>> Assuming we do this, though, the next question is, do we add seam and
>>> esb runtimes to this yaml file, which currently only provides
>>> application servers? Remember, the purpose of moving stacks down would
>>> be to deprecate the downloadRuntime extension point, therefore any
>>> replacement would need to do everything downloadRuntime does, which
>>> includes providing seam and esb runtimes for download.
>>>
>>> Let's assume (for now) that we simply add lines to the yaml to allow
>>> it to provide seam and esb runtimes. We may come back to this point
>>> later, but for now, assume we do that.
>>>
>>>
>>> Then which plugin will provide the url to our copied yaml? Who's
>>> responsibility is it to point to this yaml file? Let's look at our
>>> options:
>>>
>>> 1) The runtimes plugin references the yaml
>>> 2) The central plugin references the yaml
>>>
>>> Both of these fail after thinking about it. How?
>>>
>>> 1) If the runtimes plugin references the yaml, then the download
>>> runtimes dialog will list things (like seam) which may not be present
>>> in the installation. Imagine an installation with only base and server
>>> plugins installed, and so no seam or esb. A user clicking 'download
>>> runtimes' will see esb and seam downloads, but the plugins which are
>>> prepared to handle those runtimes after the download are not present.
>>>
>>> 2) If central is in charge of providing this yaml, perhaps through a
>>> new extension point to the base/runtimes/stacks plugin we add there,
>>> then an installation including only plugins from base / server will
>>> have a BLANK download list. Users who install only ASTools will not be
>>> able to download JBoss Application Servers.
>>>
>>> So both of these fail in their own way. The only solution as I can
>>> see, the only way it would work, would be to have multiple such yaml
>>> files, one for astools, one for seam, one for esb, etc. Each of these
>>> modules would provide their own yaml url to base/runtimes/stacks via
>>> an extension point in base/runtimes/stacks, and let stacks fetch each
>>> one and build a unified model.
>>>
>>> Problems:
>>>     a) multiple urls need to be loaded
>>>     b) multiple yaml files need to be kept up to date, instead of just
>>> one. Multiply number of contributing plugins by number of major releases
>>>     c) Possibility of duplicates. Once you have multiple yaml files
>>> generating models, it's possible some duplication leaks in. I'm not so
>>> sure about this one, but Fred listed it as a concern.
>>>
>>> So, by my analysis, this is the only way I can imagine a unification
>>> of these three models. I'll summarize the changes below, but it does
>>> seem there would be a bit of work to do.
>>>
>>> Summary of changes:
>>>    1) Deprecate downloadRuntimes extension point
>>>    2) Create new plugin in runtimes module called "stacks"
>>>    3) Add extension point to 'stacks' plugin called stacksProvider
>>>    4) modify runtime.core and runtime.ui to use the model built in 'stacks'
>>>    5) Create a web-accessible location for jbt-release-relevent data on
>>> a per-module basis. For example,
>>> http://wherever/jbt/4.1.0/stacks/astools.yaml, etc.
>>>    6) Copy the current jdf yaml file to that location for astools.yaml
>>>    7) Create a new yaml file which can build stacks for esb, seam, etc
>>>    8) Ensure astools, esb, seam, etc, make use of the new stacksProvider
>>> extension point
>>>    9) Test the shit out of it
>>>
>>> There are other benefits to this approach. Currently there's no really
>>> good mapping of downloadRuntimes id's to an app-server id. This is
>>> done in a hard-coded fashion in astools. This could instead be added
>>> to the labels in the astools.yaml file if desired. It would allow
>>> dynamic addition or removal of any runtimes, though in the yaml
>>> syntax. It would minimize connections and re-downloads of the yaml
>>> files, since they'll actually have a timestamp now (as opposed to in
>>> github, where they don't). And it could help clean up some other areas
>>> that could benefit from a cleanup.
>>>
>>> I'd really like feedback on this issue from anyone who knows anything
>>> about the topic, because I know for sure I'm lacking a bit in fully
>>> understanding the entire api. But I'd love at the least for someone to
>>> tell me which of the logic here is obviously bad or if i'm wrong on
>>> any details.
>>>
>>> Thanks and look forward to the feedback
>>>
>>> - Rob Stryker
>>> I break things, and then put them back together.
>> _______________________________________________
>> jbosstools-dev mailing list
>> jbosstools-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev