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