Regarding Stacks, Runtimes, and Remote Descriptors
by Rob Stryker
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.
11 years
Bluetooth speaker Supply与您共享了相册。
by Bluetooth speaker Supply
Dear Sir or Madam,
Wealth Land Electronics Co.,Ltd here.
We specialize in electronic devices field with full experience and we have
100 % confidence in our technology and quality.
Now our hot seller is bluetooth speaker .
Bluetooth speaker is very morden product which can work with all bluetooth
electronic device . Various shapes are available , It can offer you magical
sound when you listen music . Make your life more enjoyable .
If any interest, feel free to contact me.
Best regards,
Mr. Buick
Sales Manager
ELECTRONIC LIMITED
https://picasaweb.google.com/lh/sredir?uname=110579489846226962265&target...
11 years
Classpaths for projects targeting AS 7.2 / EAP 6.1
by Rob Stryker
Hey guys:
So I've had this in the back of my mind for a bit and kinda forgot about
it... But now users of JBossTools alpha release are starting to notice,
and its time to bring it up again.
In the past, up until as 7.1, JBossTools would set a list of jars to
automatically add to a project's classpath to help users get started. If
they create a web project, or ejb project, or ear project, we'd
helpfully add a bunch of common jars we're pretty sure users would on
their classpath automatically.
For AS 7.2/EAP6.1, we currently return 0 jars. A user creating an as7.2
runtime and a web project to go with it gets 0 jars, and 0 help at
starting their project (unless they're using maven stuff or jboss
central stuff). This was because we were informed it was inappropriate
for us to just go willy-nilly poking around the modules folder ;)
I do remember discussing with some of the AS guys about this, but I
can't seem to find a jira requesting API for us to figure out what jars
should be made available to a client. So if anyone remembers a jira
being created, that'd be great, otherwise I can make a new one.
Remember, our requirements are that this must be done based only on a
non-running server, and preferably not launching a new VM or process to
inspect an installation folder since that would count as long-running.
Ideally this would just return a best-guess of what's publicly available
to a majority of deployable units.
And of course I remember from the discussion that the list of jars would
obviously change based on what kind of deployment needs access... and
that any correct implementation would require a running server and
jboss-modules fully loaded etc, but that's not what JBT is looking for.
We're just looking for a best-guess that covers most of the bases.
Again, if we weren't told not to by the AS team, we'd probably just
hand-pick a nice subset of jars that include javax packages and the
like, but we've been repeatedly told that poking around the modules
folder is inappropriate, so, guidance is requested.
Anyway, if anyone knows a jira that was opened for this (if one indeed
was opened), I'd be glad to discuss the issue there. Otherwise, it'd be
good to get some sense of what's possible and if it will be included in
as7.2 or not.
Again, I'm not experienced at coding for app server, at all actually,
but if I can be of any help at all in any way, I'd definitely be willing
to try to make sure this stuff goes on. Currently exposing 0 jars seems
very wrong and users will complain.
11 years
Re: [jbosstools-dev] Funkyness with .target using google adt site
by Nick Boldt
Cannot reproduce your error.
If I install those two features from the Android site into Eclipse 4.3,
I get these 5 plugins and 2 features:
$➔ find . -maxdepth 2 -name "*android*" -o -name "*adt*"
./plugins/com.android.ide.eclipse.adt.package_21.1.0.v201302060044-569685
./plugins/com.android.ide.eclipse.base_21.1.0.v201302060044-569685.jar
./plugins/com.android.ide.eclipse.adt_21.1.0.v201302060044-569685.jar
./plugins/overlay.com.android.ide.eclipse.adt.overlay_21.1.0.v201302060044-569685.jar
./plugins/com.android.ide.eclipse.ddms_21.1.0.v201302060044-569685.jar
./features/com.android.ide.eclipse.ddms_21.1.0.v201302060044-569685
./features/com.android.ide.eclipse.adt_21.1.0.v201302060044-569685
If I resolve the target platform, I get the same 5 plugins and 2
features (except that they're all jars, none unpacked):
$➔ find . -name "*android*" -o -name "*adt*"
./jbosstools-multiple.target.repo/plugins/com.android.ide.eclipse.adt.package_21.1.0.v201302060044-569685.jar
./jbosstools-multiple.target.repo/plugins/com.android.ide.eclipse.base_21.1.0.v201302060044-569685.jar
./jbosstools-multiple.target.repo/plugins/com.android.ide.eclipse.adt_21.1.0.v201302060044-569685.jar
./jbosstools-multiple.target.repo/plugins/overlay.com.android.ide.eclipse.adt.overlay_21.1.0.v201302060044-569685.jar
./jbosstools-multiple.target.repo/plugins/com.android.ide.eclipse.ddms_21.1.0.v201302060044-569685.jar
./jbosstools-multiple.target.repo/features/com.android.ide.eclipse.adt_21.1.0.v201302060044-569685.jar
./jbosstools-multiple.target.repo/features/com.android.ide.eclipse.ddms_21.1.0.v201302060044-569685.jar
--
Here's what I did [1]:
BASEDIR=${HOME}/tru/targetplatforms/
for PROJECT in jbosstools; do
# 1. Merge changes in new target file to actual target file (this
verifies that the versions on the stated sites match the versions in the
.target file)
pushd ${BASEDIR}/${PROJECT}/multiple && mvn
org.jboss.tools.tycho-plugins:target-platform-utils:0.0.1-SNAPSHOT:fix-versions
-DtargetFile=${PROJECT}-multiple.target && rm -f
${PROJECT}-multiple.target ${PROJECT}-multiple.target_update_hints.txt
&& mv -f ${PROJECT}-multiple.target_fixedVersion.target
${PROJECT}-multiple.target && popd
# 2. Resolve the new target platform (pull all the IUs listed and
their dependencies into an update site on disk), using the updated
.target file
pushd ${BASEDIR}/${PROJECT}/multiple && mvn clean install
# 3. Verify the "multiple" target platform is self-contained by
building unified.target locally, pointed at the multiple site you
resolved in step 2
pushd ${BASEDIR}/${PROJECT}/unified && mvn install
-DtargetRepositoryUrl=file://${BASEDIR}/${PROJECT}/multiple/target/${PROJECT}-multiple.target.repo/
&& popd
done
[1]
https://github.com/jbosstools/jbosstools-target-platforms/blob/4.30.x/REA...
On 03/24/2013 12:56 PM, Nick Boldt wrote:
> Why add android to the TP? It's only a 3rd party thing for Central.
> Nothing in JBT depends on it... right?
>
> As to the failure...
>
> > Could not find
> "com.android.ide.eclipse.ddms.feature.group/21.1.0.v201302060044-569685"
> in the repositories of the current location
>
> Sounds like the feature you asked for isn't on the site.
>
> On 03/23/2013 11:40 PM, Max Rydahl Andersen wrote:
>> Hey,
>>
>> I made an experiment today at
>> https://github.com/maxandersen/jbosstools-target-platforms/blob/tp_process
>> where the jbosstools .targt file got the following added to it:
>>
>> <location includeAllPlatforms="false" includeMode="planner"
>> includeSource="true" type="InstallableUnit">
>> <unit id="com.android.ide.eclipse.ddms.feature.group"
>> version="21.1.0.v201302060044-569685"/>
>> <unit id="com.android.ide.eclipse.adt.feature.group"
>> version="21.1.0.v201302060044-569685"/>
>> <repository location="https://dl-ssl.google.com/android/eclipse"/>
>> </location>
>>
>> mvn install for the multiple completes, but the only IU's added are:
>>
>> ./multiple/target/jbosstools-multiple.target.repo/features/com.android.ide.eclipse.adt_21.1.0.v201302060044-569685.jar
>>
>> ./multiple/target/jbosstools-multiple.target.repo/plugins/com.android.ide.eclipse.adt.package_21.1.0.v201302060044-569685.jar
>>
>> ./multiple/target/jbosstools-multiple.target.repo/plugins/com.android.ide.eclipse.adt_21.1.0.v201302060044-569685.jar
>>
>> ./multiple/target/jbosstools-multiple.target.repo/plugins/overlay.com.android.ide.eclipse.adt.overlay_21.1.0.v201302060044-569685.jar
>>
>>
>> where it should include much more.
>>
>> After that it then fails during validation of unified stating:
>>
>> [INFO] Validating
>> /Users/max/code/jbosstools/jbosstools-target-platforms/jbosstools/unified/target/jbosstools-unified.target...
>>
>> [INFO] Failed, see Error log below
>> [ERROR] Validation found errors in 1 .target files:
>> Could not resolve content of jbosstools-unified.target
>> Could not find
>> "com.android.ide.eclipse.ddms.feature.group/21.1.0.v201302060044-569685"
>> in the repositories of the current location
>>
>> No other errors/warnings reported afaics.
>>
>> Anyone with an idea on what is going on here?
>>
>> /max
>>
>> _______________________________________________
>> jbosstools-dev mailing list
>> jbosstools-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>>
>
--
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
http://nick.divbyzero.com
11 years
Wiping out Target Platform 4.3.0.5.Alpha3-SNAPSHOT
by Mickael Istria
Hi all,
Many changes have been done on Target-Platforms recently (mainly to use
newer version of our dependencies), and TP versions was upgraded to
4.3.0.5.Alpha3-SNAPSHOT whereas we did not release a 4.3.0.5.Alpah2 version.
After discussion, we agreed that this 4.3.0.5.Alpha3-SNAPSHOT is useless
and currently confusing, since the changes that were made can be part of
the 4.3.0.5.Alpha2-SNAPSHOT target, that will be released later in order
to build JBT 4.1.0.Alpha2.
So I plan to set the version back to 4.3.0.5.Alpha2-SNAPSHOT for the
latest SNAPSHOT of TP. It's a very simple change and does not introduce
further complexity since it's just happening on SNAPSHOTs. If you've
never used explicity 4.3.0.5.Alpha3-SNAPSHOT, then you can totally
ignore this warning, nothing will change for you; and if you did use
4.3.0.5.Alpha3-SNAPSHOT, then it'll simply be about getting back to
4.3.0.5.Alpha2-SNAPSHOT
Does anyone see any objection?
Max?
--
Mickael Istria
Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
My blog <http://mickaelistria.wordpress.com> - My Tweets
<http://twitter.com/mickaelistria>
11 years
JBT 4.0.1.CR1a / JBDS 6.0.1.CR1a built with older target platform 4.22.1 instead of 4.22.2
by Nick Boldt
Due to recent changes to the way we run the Jenkins jobs, using explicit
commandline overrides to specify the target platform version used, the
new Juno-based 4.22.2 target platform listed in the parent pom was NOT
used to run the jobs for 4.0.1.CR1a / 6.0.1.CR1a.
(More manual steps / things to update == more chance something will be
forgotten.)
The result of this is that aggregate builds did not run with, and
therefore include, the newer m2e-wtp 0.17.0 bits
(https://issues.jboss.org/browse/JBIDE-13603). Thanks to Len for
exposing this problem.
So... I'm respinning the aggregate sites today (JBT WTP, JBT Core, JBT
Core Tests, JBDS Core + Installer).
I could also respin the individual projects too, if we want to verify
that all ours tests are run against the newer TP. Please advise.
--
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
http://nick.divbyzero.com
11 years
