Missing cordovasim feature on VPE site
by Mickael Istria
Hi all,
As we are integrating all new features into JBoss Tools aggregation at
the very last time, we notice some issues very late.
One of these issue is that the new CordovaSim feature is not published
on VPE site, so it cannot be aggregated. So in order to make it easier
to have a good code freeze, it would be nice if someone could merge this
PR soon: https://github.com/jbosstools/jbosstools-vpe/pull/78
In general, whenever you create a new feature that is meant to be
distributed as part of JBoss Tools, make sure it's published on your
component so it can be consumed. This can be achieved by simply running
a "mvn clean verify" in your component, and checking the output of
site/target/repository. Then make sure build crew is aware that this
features need to be aggregated, and feel free to harass Nick or I until
the feature is actually integrated. It will be less annoying than fixing
it in the few hours before a code freeze. If you understand enough of
the aggregation process, feel free to contribute pull request to this
file:
https://github.com/jbosstools/jbosstools-build-sites/blob/master/aggregat...
But in any case, do it as early as possible!
Cheers,
--
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>
12 years, 9 months
Who uses jmock in tests?
by Mickael Istria
Hi all,
I noticed the parent pom has a reference to include jmock in the
platform at test execution. I'd like to remove it since it should be
something projects enable by themselves since we don't want the parent
pom to contain all the dependencies of all the possible tests.
So in order to evaluate the feasibility of removing jmock from default
surefire configuration, I'd like to know if some of you do actually
require it in their tests.
Cheers,
--
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>
12 years, 9 months
JBDS 7 / JBT 4.1 target platform w/ Kepler M7 bits ... finally!
by Nick Boldt
After a rather harrowing week of failed builds, failed tests, failed
validations, failed solutions, and an overwhelming amount frustration,
we finally have a working target platform which includes the Kepler M7
bits, just in time for tomorrow's code freeze.
If you encounter problems when building your bits against it, consider
two things:
== Test Run Failures ==
Make sure you're using the latest parent pom from the master branch
(Beta1), as a change was required to make tests run correctly [1]. If
you do something similar in your own project's test poms, you will need
to change your poms accordingly, as there is no longer a
org.eclipse.platform.ide IU available, only a org.eclipse.platform one.
== Dependency Resolution or Other Failures ==
Issues can be reported here [2] - note the various subtasks and related
issues, too.
---
The new target platform replaces the previous one by the same name,
Alpha4-SNAPSHOT. It can be found here:
http://download.jboss.org/jbosstools/targetplatforms/jbosstoolstarget/4.3...
http://www.qa.jboss.com/binaries/RHDS/targetplatforms/jbdevstudiotarget/4...
--
If you require SOURCES when provisioning the target platform to your
local machine, use this flag to build it locally.
$ mvn clean verify -Dmirror-target-to-repo.includeSources=true
You should see new source bundles for TM, RSE and EGit have been added.
If you require additional sources for your work which are NOT available,
please report it here [3].
Any questions, you know where to reach me.
---
[1]
https://github.com/jbosstools/jbosstools-build/commit/d47bb0c3faffcfa554a...
[2] https://issues.jboss.org/browse/JBIDE-14420
[3] https://issues.jboss.org/browse/JBIDE-14088
--
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
http://nick.divbyzero.com
12 years, 9 months
3rd Party Certification - updated sites means reopened JIRAs & more stuff to review
by Nick Boldt
Since Alpha1, a number of our 3rd party requirements have been updated.
So, as I figured it was less work to reopen existing JIRAs than to
create new ones. For those re-opened, I've also renamed (where needed)
and re-targeted to Beta1.
Here's the overall JIRA:
https://issues.jboss.org/browse/JBDS-2484
In it you'll find links to the JIRAs related to reviewing these changes:
* Atlassian 3.2.0.v20130212 -> 3.2.1
* egit 2.3 -> 3.0
* GWT 3.2.1 -> 3.2.3.v201304260926-rel-r42
* PMD 3.2.6 -> 4.0.0
* SpringIDE (same version 3.2.0.201303060654-RELEASE but now on a
Kepler-based update site instead of Juno-based one, so installation /
dependencies might have changed?)
* Subclipse 1.8.18_1.7.8.1 -> 1.8.20_1.7.9.1
* SWTBot 2.1 -> 2.1.1.201305101559
* TestNG 6.8.0.20121120_1820 -> 6.8.1.20130330_0839
Cheers,
--
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
http://nick.divbyzero.com
12 years, 9 months
m2e-wtp 1.0.0 M7 build available
by Fred Bricon
Hi,
This milestone (1.0.0.20130507-1357) can be installed from the new p2 repo
at [1].
It is primarely focused on bringing JavaEE 7 support to m2e-wtp, but also
contains a few other notable improvements :
- the optional JPA/JAX-RS/JSF configurators can be enabled/disabled at the
pom level using maven properties
- 3rd party adopters can contribute Facet detection strategies for these
configurators
- With WTP 3.5.0, if files must be deployed under a non-default name for
war projects, they won't be copied under target/ anymore (this could cause
file handle leaks on windows)
- when converting eclipse to Maven projects, m2e-wtp will try to use the
latest maven-plugin version available.
See [2] for a complete list of bug fixes and improvements for this
milestone. As always, feedback is welcome.
Regards,
Fred Bricon
[1] http://download.eclipse.org/m2e-wtp/miestones/kepler/1.0.0
[2]
https://bugs.eclipse.org/bugs/buglist.cgi?columnlist=product%2Ctarget_mil...
12 years, 10 months
Still using the JBoss Tools 4.1.Alpha2 parent pom? Yes, and you SHOULD NOT BE! :: ACTION REQUIRED
by Nick Boldt
<public-shaming-mode>
== Who is this email meant for? ==
These projects need to fix their root pom:
* Server (archives, as, jmx)
* Forge
* Openshift
* Webservices
* Hibernate
== What's wrong with my parent pom? ==
Reminder, if your root pom still points at the Alpha2 parent pom, You're
Doing It Wrong, and need to fix this before code freeze next week. Your
root pom needs to be bumped every time we branch, so it can build w/ the
latest version from the master branch [0].
[0]
https://github.com/jbosstools/jbosstools-build/blob/master/parent/pom.xml#L7
This will also ensure you're using the correct target platform when you
build locally. Since the Beta1 target platform is changing from Kepler
M6 to M7 later this week, *THIS IS URGENT.*
== How do I know you haven't updated yet? ==
Other than looking at your sources in github, the easiest way to see
who's conforming and who isn't is the JBT nightly aggregate site [1],
which lists versions of features w/ their suffix. This suffix is
inherited from the parent pom. So if you're using the Alpha2 parent pom,
your features will have "Alpha2" in their qualifier.
[1] http://download.jboss.org/jbosstools/updates/nightly/core/trunk/
== How do you fix your root pom? ==
Like this:
diff --git a/pom.xml b/pom.xml
index 4749cb1..28ef6ca 100644
--- a/pom.xml
+++ b/pom.xml
@@ -5,7 +5,7 @@
<parent>
<groupId>org.jboss.tools</groupId>
<artifactId>parent</artifactId>
- <version>4.1.0.Alpha2-SNAPSHOT</version>
+ <version>4.1.0.Beta1-SNAPSHOT</version>
<relativePath>../jbosstools-build/parent/pom.xml</relativePath>
</parent>
<groupId>org.jboss.tools</groupId>
</public-shaming-mode>
--
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
http://nick.divbyzero.com
12 years, 10 months
[JBIDE-14405] WaitJob not safe, thought I'd ping you
by Rob Stryker
Hey All:
When browsing code, I found something very interesting and dangerous.
The wait job inside ECFTransport is not a safe implementation. It seems
there's an upstream eclipse issue on join() which was a workaround for
UI deadlocks but makes a join() not able to be interrupted.
You can read more on the eclipse bug:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=293312
Any time your code uses Join, you should pay extra attention as to who
can interrupt you, for what reason, or not. If join() is not able to be
interrupted, and the job you join against freezes, both threads may be
deadlocked forever. Stopping the job will NOT un-lock your job OR the
joined thread, either, unless your job overrides the canceling() method
to interrupt itself!
So be aware.
My new implementation of WaitJob is here below:
https://github.com/jbosstools/jbosstools-base/blob/master/common/plugins/...
12 years, 10 months
