M5 spin status :: no aggregate or JBDS installers available yet; many bot and non-UI test failures, plus one inter-build compilation failure
by Nick Boldt
Since turning on the stable branch jobs, here's what's borked...
https://issues.jboss.org/browse/JBIDE-10349
Still trying to get a clean stable_branch aggregate build (and then JBT
builds too) - last time the aggregate failed due to missing Central,
OTDT, and OpenShift (hadn't spun clean yet).
---
Details:
- hibernate : test failure in org.hibernate.eclipse.console.test
- jbpm : test failure in org.jboss.tools.jbpm.convert.test
- jsf : test failure in org.jboss.tools.jsf.vpe.jsf.test
- maven : 15 bot test failures (same failures in trunk) ... should these
just be turned off and only run locally / manually?
- struts : COMPILE FAILED - upstream bits missing? "The import
org.jboss.tools.jst.web.validation cannot be resolved."
---
There are also a few jobs for which the latest build failed, but at
least we have one good build since branching. This suggests we're having
some stability issues w/ a few Jenkins slaves, but at least we're
getting clean spins when the server is quiet(er).
= archives : aborted build? [Dec 4 ok]
= birt : failed to find usage bits (poor timing between builds) [Dec 4 ok]
= seam : no more locks failure [Dec 4 ok]
--
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
http://nick.divbyzero.com
8 months
How should we deal with components of projects which have not changed since JBT 4.1.0.Final (eg., jbosstools-base/runtime) ?
by Nick Boldt
In looking at the JBT 4.1.1.Alpha2 build [1], I see that some features
have not yet changed since JBT 4.1.0.Final [2]. 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 [3], this presents a question.
[1] http://download.jboss.org/jbosstools/updates/nightly/core/4.1.kepler/
[2] http://download.jboss.org/jbosstools/updates/stable/kepler/
[3]
http://download.jboss.org/jbosstools/builds/staging/jbosstools-base_41/al...
Currently, the base build [3] is producing this plugin:
org.jboss.tools.runtime.core 2.1.0.Alpha2-v20130927-0137-B114
But the JBT 4.1.1.Alpha2 build [1] contains this version, which is
code-wise identical except for the qualifier change in the manifest.
org.jboss.tools.runtime.core 2.1.0.Final-v20130717-0450-B102
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
version.
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 [3] so that only the older version from [2]
will be included.
This is basically the process I used to build JBT 4.1.0.1 - I excluded
everything from jbosstools-central's site/category.xml except the
feature which had actually changed [4].
[4]
https://github.com/jbosstools/jbosstools-central/commit/16279020cbf872f4e...
Looking for feedback here -- is this a good idea?
--
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
http://nick.divbyzero.com
13 years
[action] jbosstools-base/runtimes packages have been re-organized
by Rob Stryker
Hi All:
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
code.
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.
13 years
