Any way to make FreeMarker IDE fixes avilable with less delay?
by Daniel Dekany
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.
--
Thanks,
Daniel Dekany
7 years, 9 months
Migration to jgit timestamps
by Nick Boldt
(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
like Alpha
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.
Ref: https://issues.jboss.org/browse/JBIDE-13671
--
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
http://nick.divbyzero.com
7 years, 9 months
Eclipse plugins testing structure
by Aurelien Pupier
Hi,
I'm currently trying to improve test structure for Jboss Fuse Tooling
project (https://github.com/fusesource/fuseide).
On Max recommendation, I take a look at jbosstools-devdoc
https://github.com/jbosstools/jbosstools-devdoc/blob/master/source/how_to...
When i take a look to
https://github.com/jbosstools/jbosstools-server/blob/master/as/tests/org....
. 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
https://github.com/fusesource/fuseide/tree/master/editor/tests/org.fuseso...
and the parent pom configuration:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.19.1</version>
<executions>
<execution>
<id>test</id>
<phase>test</phase>
<configuration>
<systemProperties>
<osgi.nls.warnings>ignore</osgi.nls.warnings>
</systemProperties>
<includes>
<include>**/*Test.java</include>
</includes>
</configuration>
<goals>
<goal>test</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.eclipse.tycho</groupId>
<artifactId>tycho-surefire-plugin</artifactId>
<version>${tychoVersion}</version>
<configuration>
<useUIThread>true</useUIThread>
<useUIHarness>true</useUIHarness>
<includes>
<include>**/*IT.class</include>
</includes>
<argLine>${tycho.testArgLine}
-XX:+HeapDumpOnOutOfMemoryError</argLine>
</configuration>
</plugin>
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
--
Aurelien Pupier
Senior Software Engineer in JBoss Fuse Tooling Team
@apupier
7 years, 9 months
closed freemarker issues
by Max Rydahl Andersen
Hey,
I started to see more and more freemarker issues being open on github
despite
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
JBIDE,
but before that I just tried to click the "Enable issues" checkbox on
github
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
https://jira.jboss.org/jira/browse/JBIDE
for freemarker work.
/max
http://about.me/maxandersen
7 years, 10 months
Work with remote container(s)?
by David M. Karr
I'm still mostly a Docker beginner, and I just viewed the Docker Tools
recorded video.
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.
7 years, 10 months
