I'm a contributor at the FreeMarker project, and would like to help
maintaining JBoss Tools / FreeMarker IDE
(org.jboss.ide.eclipse.freemarker). The problem I'm facing is that
pull requests get merged with too big delay. For example, I have a few
simple pull requests waiting for 4 months now, because of the limited
resources available for reviewing them (as I was told). I wonder if I
can help improving this situation somehow.
If the above can be addressed, then I guess I could specify the
nightly build update site URL to the users, so that they aren't
affected by the release cycle of JBoss Tools. After all, FreeMarker
IDE is technically quite independent of it.
(Previously, on "migrating to jgit timestamps"...)
Instead of a BUILD_ALIAS like Alpha1 or Beta1, which forces users to
download a whole JBT or devstudio install each time we release a new
milestone, plugins and features will soon use the timestamp of their
last change in github.
Note that two plugins will continue to have a BUILD_ALIAS applied:
foundation.core & devstudio.core.central, which define the version of JBoss
Tools / devstudio used by ide-config.properties to assign the correct
URLs for Central and quickstarts. But as you may have seen in another
thread, we are now using milestone numbers instead of quality labels
or Beta. These milestones will be called AM1, AM2, AM3, because we
need a letter that's ascii-wise a lower value that Final & GA.
Previously, I had said that you need to *check in your local changes*
(to your local github clone, not to origin!)
in order to ensure that those local changes are seen as "newer" than
the stuff available on download.jboss.org, or in your ~/.m2/repo.
This is no longer true -- a dirty github workspace will still result
in upversioned plugin timestamps. I believe this should even work
across timezones, since the plugins I built appear to be timestamped
in GMT, not EST.
Anyway, thanks for reading this far. The PRs in JBIDE-13671 have been
applied, and fresh CI builds should be available tomorrow.
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
I'm currently trying to improve test structure for Jboss Fuse Tooling
On Max recommendation, I take a look at jbosstools-devdoc
When i take a look to
. This project is in tests folder but it launches tycho-surefire-plugin.
As far as I understand Tycho, it means that it is launching an OSGi
platform. From my point of view, it means that these tests are already
integration tests and the only difference between tests and itests
currently is more fast vs slow tests.
What I wanted to achieve is to have really fast unit test, so I created
a fragment and so use maven-surefire-plugin. You can see the fragment
and the parent pom configuration:
Did I misunderstood something?
Are there counterpoints to use fragments and maven-surefire-plugin?
Are there other examples which are matching more closely to my usecase
in jboss tools codebase?
Thanks by advance for your help
Senior Software Engineer in JBoss Fuse Tooling Team
I started to see more and more freemarker issues being open on github
the readme says to use https://jira.jboss.org/jira/browse/JBIDE.
I wanted to leave a comment on the issues that bugs should be open on
but before that I just tried to click the "Enable issues" checkbox on
and surprise: github nukes the issues instantly ;/
That was not supposed to happen. Wanted to give a headsup first.
Anyways, in short - freemarker repo is now like others that pull-request
is open and bugs goes to the relevant component in jira.
Paul - sorry for nuking the issues ;/ but please use
for freemarker work.
I'm still mostly a Docker beginner, and I just viewed the Docker Tools
Two related questions:
Will it be possible to have the Docker Tooling work with a remote
container (not on localhost)?
Will it be possible to integrate with Docker Swarm?
The latter is likely an academic issue, but perhaps not the former.
The current release of the openshift-restclient-java, for not so obvious
reasons, depends on no less then 3 libraries to provide the underlying
communication to the cluster server. The following PR
this dependency to a single client which is based on OkHttp. We are
looking to make this change to:
* Provide a common way to make REST calls
* Simplify the authorization semantics to an openshift cluster
* Simplify the pattern of making REST calls over what is done today
* In future, take advantage of its SPDY support to move away from the oc
* Put us in a better position to move to the Fabric8 client (if that ever
Any comments or objects are welcome
Senior Software Engineer, Red Hat Engineering
OpenShift Integration Services
Red Hat, Inc.
*Office*: 703-748-4420 | 866-546-8970 ext. 8162420