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
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
ACTION REQUIRED: Code Freeze for Sprint 115 :: prepare for this week's staging build
by Nick Boldt
* Target platform will be updated ASAP to move to *Neon.0.RC2*. Watch for
email updates.
* Task JIRAs will be sent out tomorrow, and you will *create a branch &
update your root poms* to use the latest parent pom.
* Code freeze for all projects' jbosstools-4.4.x branches will start *Thursday
at 2pm PST / 5pm EST / 11pm CST*.
(We're back to the old way of branching and updating root & parent poms.
Did you enjoy the lightweight approach? Tell us!)
* *build will run Thursday night* and be copied to /staging/ on Friday
morning EST.
* *From Fri until the end of the sprint, you should *NOT* push anything
into the jbosstools-4.4.x stable branch unless it's a blocker fix approved
by Alexey*
** *master branch is open for new work once you've created your
jbosstools-4.4.x branch.
----
Looking ahead...
We will be moving from Neon.0.RC2 to RC4 next week as soon as the *RC4 bits
are available, starting on Jun 8 or 9*.
There will be a *respin on Jun 10* to move up to RC4. This will hopefully
the LAST build before *GA on June 14.*
I hope to go rock climbing at a place call Bon Echo the weekend of June
11-12. So... please, if you need to cause/find/fix blockers, please do so
before Jun 8 so they can be fixed at the same time as the TP update on Jun
9 -- thanks!
--
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
http://nick.divbyzero.com
--
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
http://nick.divbyzero.com
7 years, 10 months
Re: [jbosstools-dev] [aeri] Friendly Reminder - Reviewer Feedback
by Marcel Bruch
Hi,
I’m resending this since it seems that this mail went into the spam folder of many - so far I got 4 feedbacks. Your input is welcome.
Best regards,
Marcel
[1] http://goo.gl/forms/103G9e18bA <http://goo.gl/forms/103G9e18bA>
> Am 27.05.2016 um 10:42 schrieb Radim Hopp <rhopp(a)redhat.com>:
>
> Hi.
> I just noticed you sent this mail to jbosstools-dev mailing list (long
> time ago :-D). It ended in my Spam folder (that's why i found it now)
> and it is highly probable, that lot of people on this mailing list
> have been migrated to gmail as well and thus it probably ended in
> their spam folder too. If you got low response rate on this feedback
> you may consider to re-send it and check with some people if it didn't
> end in in spam folder again ;-)
> Radim
> Devstudio QA
>
> On Mon, May 9, 2016 at 8:55 AM, Marcel Bruch
> <marcel.bruch(a)codetrails.com> wrote:
>> Hi,
>>
>> this is a friendly reminder to participate in the first AERI evaluation poll
>> [1]. Your feedback is greatly appreciated.
>>
>> Thank you,
>> Marcel
>>
>>
>> [1] http://goo.gl/forms/103G9e18bA
7 years, 11 months
Pull Request against jbosstools-target-platforms repository validated automatically
by Mickael Istria
Hi all,
With https://issues.jboss.org/browse/JBIDE-22312 , a new CI job [1] now
validates, mirror and runs p2diff [2] automatically whenever a pull
request is submitted against the
jhttps://github.com/jbosstools/jbosstools-target-platforms/ repository.
This automated validation then report its success or failure on the pull
request directly, annotating it like Travis CI does (with a green or red
box depending on success).
It returns a failure if TP validation or mirroring fail. It's most
likely to happen because of a wrong reference to a p2 repository, a
missing IU or an incorrect version, or a missing requirement.
It returns a successful build if it managed to validate the PR and
mirror its content. In such case, there is still need to follow the
links to the jenkins job have a human look at the p2diff attached to the
build, and to comment whether p2diff looks fine on the PR. Then, when
build is successful and p2diff looks good, the PR can be announced to
the team and considered for a merge.
Notes:
* p2diff report is now generated automatically on regular Maven build
(even local ones), building the TP with the -Pmultiple2repo profile.
* Triggering validation build is setup as a cron running every 5
minutes, so it's fine if the build doesn't start immediately after your
PR creation/update. Just check it again a bit later and in case of
issue, ping @mickaelistria and/or @nickboldt on this PR
* The validation build takes about 1 hour. There are for sure
opportunities to speed it up, but as the TP process is slow anyway and
that this approach is already faster than the previous ones requiring
local mirror and p2diff, speeding it up isn't high priority at the moment.
Cheers,
[1]
https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/DevStudio/view/DevS...
[2] https://issues.jboss.org/browse/JBIDE-22308
--
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>
7 years, 11 months
