The second milestone release ( Alpha2 ) for Teiid Designer 8.2 is available.
New in Alpha2:
* Provides Teiid client drivers for each installed teiid client version, without requiring
connection to a server
* Improvements to the model refactoring framework (rename, delete, cut/copy) to integrate better
* Teiid servers can be added that exist on the same host
* Major refactoring of DDL importer, now supporting database extension properties
* Auto generate REST WARs at deployment time to expose your VDBs as REST services and allow for
REST based ad hoc queries.
* Significant number of issues fixed (see the JIRA summary for details )
Find downloads at: http://www.jboss.org/teiiddesigner/downloads
Update Site URL:
Teiid Designer Project Team
* mob: +44 (0)9780 869490
In looking at the JBT 4.1.1.Alpha2 build , I see that some features
have not yet changed since JBT 4.1.0.Final . This is fine for a
project like GWT or Freemarker, where the entire project is versioned
the same way and we can simply include the previous .Final release, but
for a subcomponent of a project, like the runtime component in
jbosstools-base , this presents a question.
Currently, the base build  is producing this plugin:
But the JBT 4.1.1.Alpha2 build  contains this version, which is
code-wise identical except for the qualifier change in the manifest.
Where it becomes an issue is that when we start building 4.1.1.Final in
November, we will be including both 2.1.0.Final-v20130717-0450-B102
(from JBT 4.1.0.Final) and 2.1.0.Final-v20131200-0000-Bxxx (from JBT
4.1.1.Final). Since these are bitwise identical, there's no point making
users update from an identical feature or plugin to a newer identical
So how do we prevent the build from including a newer-versioned but
identical feature or plugin?
The only thing I can currently think of is to *exclude* these features
from the base_41 update site  so that only the older version from 
will be included.
This is basically the process I used to build JBT 126.96.36.199 - I excluded
everything from jbosstools-central's site/category.xml except the
feature which had actually changed .
Looking for feedback here -- is this a good idea?
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
I did use-scans everywhere I possibly could, and tried to maintain that
all current APIs still work, but I did finally get around to marking
most of runtimes code to be internal. I also did not stop exporting any
of the original packages, yet. But this is the notice that in the next
major release, those packages will no longer be exported.
So... sometime in the next few weeks / months, if your code uses the
runtimes component, go through your code and make sure deprecated
methods aren't used, internal packages aren't referenced, and respect
the new restrictions.
I've bumped the major version to 3.0.0 to make clear that all old
deprecated code will be removed for the next major release.
If your code is using a method for which there is no obvious
alternative, PING ME and REQUEST the api, or some similar replacement,
be made public for your use, or ask me to help you migrate your existing
Again, as I said, no code should break at this point. I've locally built
base, server, javaee, and central. But there will be further cleanup
eventually, so this is basically your warning.
if you're wondering why I made the large changes first, instead of sent
the email first, it's because it needed to be done this way. If I
alerted you first that I plan to change versions to 3.0.0, you'd update
your manifest.mf to make 3.0.0 the minimal range BEFORE i bumped hte
version, which would mean your code wouldn't compile because the 3.0.0
bundle would not be found.
So, I made the changes as API-Compatible as I can, everything is set up,
all code is marked clearly whether it's public or not, everything's
javadoc'd, and all packages are still exported. Now it's your turn to
clean your code, before I make everything hidden.
I'm not in a super rush to mark everything as hidden, but it will be for
the next major release once we can guarantee all clients are migrated.
Also, you MAY need to depend on foundation.core and foundation.ui.
Runtimes does not re-export these plugins, but it does make use of
them. Previously, runtimes depended on common, but I have severed this
link and runtimes now depends on the lower-level foundation instead.
Again, nothing should break currently. if anything has broken, please
ping me immediately.
- Rob Stryker
Causing Problems, as usual.
We supply printing service with good quality and very competitive price. Hope to be a partner of your company.
Printing Products: catalogue, Magazines, Picture Albums, Books, Booklets, labels/stickers, tri-fold, Calendars, flyers, business cards, Sticky memo pad, paper bags, etc.
Competitive quote will be provided upon receipt of your detailed requirements.
More details about our factory will be sent to you if you are interested.