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
>>
>