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.

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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbosstools-dev _______________________________________________ jbosstools-dev mailing list jbosstools-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbosstools-dev

license, size, and disclaimer can all be added in the labels section of the yaml. Max has already made it clear that having three things that do the same thing is wasteful and confusing, so the question isn't *if* we will unify them, but rather *how*. On 03/01/2013 09:29 PM, Snjezana Peco wrote: > 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(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev >> _______________________________________________ >> jbosstools-dev mailing list >> jbosstools-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jbosstools-dev _______________________________________________ jbosstools-dev mailing list jbosstools-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbosstools-dev

Hi Fred and all JBDS team! The idea of "merge data from separate yaml files" doesn't worked and we (JDF team) didn't put any more effort on it. The original idea is that we could join the information (appending a new content to the original stacks.yaml) and use its YAML anchors. To clarify what I'm saying, look the matrix.yaml file (https://github.com/jboss-jdf/jdf-stack/blob/1.0.0.Final/matrix.yaml) it has some references to BOMs and archtypes that is defined on original stacks.yaml. The main problem is that the new generarate yaml file is not parsable via StacksClient (because it expects the original 1.0.0 format only) and a new "client" should be built to each new format extension. This could make us loose the control since any data change on stacks.uaml could impact all extensions that uses it. So in fact: It was not a good idea to have this extensions on separate files. The next "Stacks 1.0" planned evolution is https://issues.jboss.org/browse/JDF-222 - Stacks should permit a "Early Access" Runtimes - And because of the file format, this "Early Acccess" will be a new "label" but I have afraid that consumers must know that "allAvailableRuntimes" has "Released/Final" and "Early Access" runtimes mixed. They should query the labels to distinguish them. That's my 2 cents. Em 26/03/13 10:25, Fred Bricon escreveu: > Hey Rafael, > > what's the status on the "merge data from separate yaml files"? I > know you worked on that at some point. > We'll most certainly need to combine JBoss Tools specific runtimes or > infos with the existing JDF ones. > > Fred > > Le 02/03/2013 08:52, Rob Stryker a écrit : >> license, size, and disclaimer can all be added in the labels section of >> the yaml. >> >> Max has already made it clear that having three things that do the same >> thing is wasteful and confusing, so the question isn't *if* we will >> unify them, but rather *how*. >> >> On 03/01/2013 09:29 PM, Snjezana Peco wrote: >>> 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(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev >>>> _______________________________________________ >>>> jbosstools-dev mailing list >>>> jbosstools-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev >> _______________________________________________ >> jbosstools-dev mailing list >> jbosstools-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jbosstools-dev >

Hi! Since we can always add these informations as we need. I'm using a "on demand" approach, where someone or team who needs it, I ask to provide a Pull Request with the Runtime/BOM/Archetype needed. Them I test again and merge. Anyone can do the tests with 'mvn test'. Just this :) Since we haven't any other Runtimes than AS and EAP, I think we can use the following ' runtime-type': JPP, SOAP, BRMS, GateIn, etc and keep the same 'runtime-category: SERVER'. Thank you :) Em 01/04/13 05:39, Rob Stryker escreveu: >Hi Rafael: > >I'm sure I and the tools team will have more questions in the >future, but, right now one question I have is whether it's planned >to add ALL of our runtimes to the stacks? Things like jpp, GateIn, >SOA-P, etc? > >So far it seems limited to AS and EAP. > >Thanks! > >- Rob Stryker > >On 03/27/2013 12:39 AM, Rafael Benevides wrote: >>Hi Fred and all JBDS team! >> >>The idea of "merge data from separate yaml files" doesn't worked >>and we (JDF team) didn't put any more effort on it. >> >>The original idea is that we could join the information (appending >>a new content to the original stacks.yaml) and use its YAML >>anchors. To clarify what I'm saying, look the matrix.yaml file (https://github.com/jboss-jdf/jdf-stack/blob/1.0.0.Final/matrix.yaml) >>it has some references to BOMs and archtypes that is defined on >>original stacks.yaml. >> >>The main problem is that the new generarate yaml file is not >>parsable via StacksClient (because it expects the original 1.0.0 >>format only) and a new "client" should be built to each new format >>extension. This could make us loose the control since any data >>change on stacks.uaml could impact all extensions that uses it. So >>in fact: It was not a good idea to have this extensions on >>separate files. >> >>The next "Stacks 1.0" planned evolution is >>https://issues.jboss.org/browse/JDF-222 - Stacks should permit a >>"Early Access" Runtimes - And because of the file format, this >>"Early Acccess" will be a new "label" but I have afraid that >>consumers must know that "allAvailableRuntimes" has >>"Released/Final" and "Early Access" runtimes mixed. They should >>query the labels to distinguish them. >> >>That's my 2 cents. >> >> >>Em 26/03/13 10:25, Fred Bricon escreveu: >>>Hey Rafael, >>> >>>what's the status on the "merge data from separate yaml files"? >>>I know you worked on that at some point. >>>We'll most certainly need to combine JBoss Tools specific >>>runtimes or infos with the existing JDF ones. >>> >>>Fred >>> >>>Le 02/03/2013 08:52, Rob Stryker a écrit : >>>>license, size, and disclaimer can all be added in the labels >>>>section of >>>>the yaml. >>>> >>>>Max has already made it clear that having three things that do >>>>the same >>>>thing is wasteful and confusing, so the question isn't *if* we will >>>>unify them, but rather *how*. >>>> >>>>On 03/01/2013 09:29 PM, Snjezana Peco wrote: >>>>>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(a)lists.jboss.org >>>>>>>https://lists.jboss.org/mailman/listinfo/jbosstools-dev >>>>>>_______________________________________________ >>>>>>jbosstools-dev mailing list >>>>>>jbosstools-dev(a)lists.jboss.org >>>>>>https://lists.jboss.org/mailman/listinfo/jbosstools-dev >>>>_______________________________________________ >>>>jbosstools-dev mailing list >>>>jbosstools-dev(a)lists.jboss.org >>>>https://lists.jboss.org/mailman/listinfo/jbosstools-dev >>> >> >

_______________________________________________ jbosstools-dev mailing list jbosstools-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbosstools-dev

On 2 Apr 2013, at 12:39, Max Rydahl Andersen <max.andersen(a)redhat.com&gt; wrote: > Hi Rafael, > > We also got runtimes like drools and seam which aren't exactly servers. In the classification we've used, Drools and Seam aren't runtimes, they are frameworks - the key difference being they are embedded into an existing app, and they don't require you to start the JVM. We can add this to stacks.yml, but I wonder whether runtimes is the right place to put it. > Also, can we have runtimes listed without having matching archetypes ? > i.e. if we would like to move all our existing info over to stacks.yml > instead of having it spread over we would need this runtime list without > having matching bom's etc. > > /max > > On Mon, Apr 01, 2013 at 09:25:52AM -0300, Rafael Benevides wrote: >> Hi! >> >> Since we can always add these informations as we need. I'm using a "on demand" approach, where someone or team who needs it, I ask to provide a Pull Request with the Runtime/BOM/Archetype needed. Them I test again and merge. Anyone can do the tests with 'mvn test'. >> Just this :) >> >> Since we haven't any other Runtimes than AS and EAP, I think we can use the following ' runtime-type': JPP, SOAP, BRMS, GateIn, etc and keep the same 'runtime-category: SERVER'. >> >> Thank you :) >> >> >> Em 01/04/13 05:39, Rob Stryker escreveu: >>> Hi Rafael: >>> >>> I'm sure I and the tools team will have more questions in the future, but, right now one question I have is whether it's planned to add ALL of our runtimes to the stacks? Things like jpp, GateIn, SOA-P, etc? >>> >>> So far it seems limited to AS and EAP. >>> >>> Thanks! >>> >>> - Rob Stryker >>> >>> On 03/27/2013 12:39 AM, Rafael Benevides wrote: >>>> Hi Fred and all JBDS team! >>>> >>>> The idea of "merge data from separate yaml files" doesn't worked and we (JDF team) didn't put any more effort on it. >>>> >>>> The original idea is that we could join the information (appending a new content to the original stacks.yaml) and use its YAML anchors. To clarify what I'm saying, look the matrix.yaml file (https://github.com/jboss-jdf/jdf-stack/blob/1.0.0.Final/matrix.yaml) it has some references to BOMs and archtypes that is defined on original stacks.yaml. >>>> >>>> The main problem is that the new generarate yaml file is not parsable via StacksClient (because it expects the original 1.0.0 format only) and a new "client" should be built to each new format extension. This could make us loose the control since any data change on stacks.uaml could impact all extensions that uses it. So in fact: It was not a good idea to have this extensions on separate files. >>>> >>>> The next "Stacks 1.0" planned evolution is https://issues.jboss.org/browse/JDF-222 - Stacks should permit a "Early Access" Runtimes - And because of the file format, this "Early Acccess" will be a new "label" but I have afraid that consumers must know that "allAvailableRuntimes" has "Released/Final" and "Early Access" runtimes mixed. They should query the labels to distinguish them. >>>> >>>> That's my 2 cents. >>>> >>>> >>>> Em 26/03/13 10:25, Fred Bricon escreveu: >>>>> Hey Rafael, >>>>> >>>>> what's the status on the "merge data from separate yaml files"? I know you worked on that at some point. >>>>> We'll most certainly need to combine JBoss Tools specific runtimes or infos with the existing JDF ones. >>>>> >>>>> Fred >>>>> >>>>> Le 02/03/2013 08:52, Rob Stryker a écrit : >>>>>> license, size, and disclaimer can all be added in the labels section of >>>>>> the yaml. >>>>>> >>>>>> Max has already made it clear that having three things that do the same >>>>>> thing is wasteful and confusing, so the question isn't *if* we will >>>>>> unify them, but rather *how*. >>>>>> >>>>>> On 03/01/2013 09:29 PM, Snjezana Peco wrote: >>>>>>> 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(a)lists.jboss.org >>>>>>>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev >>>>>>>> _______________________________________________ >>>>>>>> jbosstools-dev mailing list >>>>>>>> jbosstools-dev(a)lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev >>>>>> _______________________________________________ >>>>>> jbosstools-dev mailing list >>>>>> jbosstools-dev(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev >> _______________________________________________ >> jbosstools-dev mailing list >> jbosstools-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jbosstools-dev

Just remembering that stacks-client (https://github.com/jboss-jdf/jdf-stacks-client) have the java stacks model and also the mechanism to download the stacks.yaml that it wasn't used on JBDS for some reason related to Eclipse proxy. Anyway, the model can be used to avoid duplicated code. Em 02/04/13 10:46, Rob Stryker escreveu: > I think so long as its available in stacks.yaml, it should be fine. > > Perhaps on our side we can have our various plugins traverse the > stacks model, find the information relevant to them and then provide > them to our "runtime-detector" as "runtimes" in our terminology. > > For example, low-level code (jbt-stacks plugin) fetches and generates > stacks model (using jboss stacks), then drools eclipse plugins > traverse / visit that model, find what they know about (drools > "framework" from stacks model), and then provides it to jbt-runtimes > as downloadable runtimes. > > I think this should work fine. > > On 04/02/2013 09:27 PM, Pete Muir wrote: >> On 2 Apr 2013, at 12:39, Max Rydahl Andersen >> <max.andersen(a)redhat.com&gt; wrote: >> >>> Hi Rafael, >>> >>> We also got runtimes like drools and seam which aren't exactly >>> servers. >> In the classification we've used, Drools and Seam aren't runtimes, >> they are frameworks - the key difference being they are embedded >> into an existing app, and they don't require you to start the JVM. >> >> We can add this to stacks.yml, but I wonder whether runtimes is the >> right place to put it. >> >>> Also, can we have runtimes listed without having matching archetypes ? >>> i.e. if we would like to move all our existing info over to stacks.yml >>> instead of having it spread over we would need this runtime list >>> without >>> having matching bom's etc. >>> >>> /max >>> >>> On Mon, Apr 01, 2013 at 09:25:52AM -0300, Rafael Benevides wrote: >>>> Hi! >>>> >>>> Since we can always add these informations as we need. I'm using a >>>> "on demand" approach, where someone or team who needs it, I ask >>>> to provide a Pull Request with the Runtime/BOM/Archetype needed. >>>> Them I test again and merge. Anyone can do the tests with 'mvn test'. >>>> Just this :) >>>> >>>> Since we haven't any other Runtimes than AS and EAP, I think we >>>> can use the following ' runtime-type': JPP, SOAP, BRMS, GateIn, >>>> etc and keep the same 'runtime-category: SERVER'. >>>> >>>> Thank you :) >>>> >>>> >>>> Em 01/04/13 05:39, Rob Stryker escreveu: >>>>> Hi Rafael: >>>>> >>>>> I'm sure I and the tools team will have more questions in the >>>>> future, but, right now one question I have is whether it's >>>>> planned to add ALL of our runtimes to the stacks? Things like >>>>> jpp, GateIn, SOA-P, etc? >>>>> >>>>> So far it seems limited to AS and EAP. >>>>> >>>>> Thanks! >>>>> >>>>> - Rob Stryker >>>>> >>>>> On 03/27/2013 12:39 AM, Rafael Benevides wrote: >>>>>> Hi Fred and all JBDS team! >>>>>> >>>>>> The idea of "merge data from separate yaml files" doesn't worked >>>>>> and we (JDF team) didn't put any more effort on it. >>>>>> >>>>>> The original idea is that we could join the information >>>>>> (appending a new content to the original stacks.yaml) and use >>>>>> its YAML anchors. To clarify what I'm saying, look the >>>>>> matrix.yaml file >>>>>> (https://github.com/jboss-jdf/jdf-stack/blob/1.0.0.Final/matrix.yaml) >>>>>> it has some references to BOMs and archtypes that is defined on >>>>>> original stacks.yaml. >>>>>> >>>>>> The main problem is that the new generarate yaml file is not >>>>>> parsable via StacksClient (because it expects the original 1.0.0 >>>>>> format only) and a new "client" should be built to each new >>>>>> format extension. This could make us loose the control since any >>>>>> data change on stacks.uaml could impact all extensions that uses >>>>>> it. So in fact: It was not a good idea to have this extensions >>>>>> on separate files. >>>>>> >>>>>> The next "Stacks 1.0" planned evolution is >>>>>> https://issues.jboss.org/browse/JDF-222 - Stacks should permit a >>>>>> "Early Access" Runtimes - And because of the file format, this >>>>>> "Early Acccess" will be a new "label" but I have afraid that >>>>>> consumers must know that "allAvailableRuntimes" has >>>>>> "Released/Final" and "Early Access" runtimes mixed. They should >>>>>> query the labels to distinguish them. >>>>>> >>>>>> That's my 2 cents. >>>>>> >>>>>> >>>>>> Em 26/03/13 10:25, Fred Bricon escreveu: >>>>>>> Hey Rafael, >>>>>>> >>>>>>> what's the status on the "merge data from separate yaml files"? >>>>>>> I know you worked on that at some point. >>>>>>> We'll most certainly need to combine JBoss Tools specific >>>>>>> runtimes or infos with the existing JDF ones. >>>>>>> >>>>>>> Fred >>>>>>> >>>>>>> Le 02/03/2013 08:52, Rob Stryker a écrit : >>>>>>>> license, size, and disclaimer can all be added in the labels >>>>>>>> section of >>>>>>>> the yaml. >>>>>>>> >>>>>>>> Max has already made it clear that having three things that do >>>>>>>> the same >>>>>>>> thing is wasteful and confusing, so the question isn't *if* we >>>>>>>> will >>>>>>>> unify them, but rather *how*. >>>>>>>> >>>>>>>> On 03/01/2013 09:29 PM, Snjezana Peco wrote: >>>>>>>>> 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(a)lists.jboss.org >>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev >>>>>>>>>> _______________________________________________ >>>>>>>>>> jbosstools-dev mailing list >>>>>>>>>> jbosstools-dev(a)lists.jboss.org >>>>>>>>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev >>>>>>>> _______________________________________________ >>>>>>>> jbosstools-dev mailing list >>>>>>>> jbosstools-dev(a)lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev >>>> _______________________________________________ >>>> jbosstools-dev mailing list >>>> jbosstools-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev >

We need only to decide what 'runtime-category' to use for these other "runtimes".

On Tue, Apr 02, 2013 at 10:48:05AM -0300, Rafael Benevides wrote: >>> We also got runtimes like drools and seam which aren't exactly >>> servers. >> In the classification we've used, Drools and Seam aren't runtimes, >> they are frameworks - the key difference being they are embedded >> into an existing app, and they don't require you to start the JVM. >> >> We can add this to stacks.yml, but I wonder whether runtimes is the >> right place to put it. > Yes. That's the kind of discussion that is recurrent :) - To refresh > what we discussed about it, we decided that we will use these > runtimes (drools, seam, etc) under runtimes section. On that > occasion (stacks cr1 release), we decided to created the > 'runtime-category' label to distinguish these runtime types. I'll > improve the tests to make this label required to all runtimes. We > need only to decide what 'runtime-category' to use for these other > "runtimes". frameworks or should we even add some more specific type i.e. drools-fwk, seam-fwk ? Or is there some other way we can know what specific type they are ?

>>> Also, can we have runtimes listed without having matching archetypes ? >>> i.e. if we would like to move all our existing info over to stacks.yml >>> instead of having it spread over we would need this runtime list >>> without >>> having matching bom's etc. > Yes. it's is possible to have a runtime with a 'empty list' of > archetypes and boms. The tests only complains about having an > archetype or a bom that isn't used on any runtime. great.