Hi Christian,
great stuff! Can you please also raise issues in JIRA :
http://jira.codehaus.org/browse/JBEHAVE
Component "Eclipse Support" and Fix Version "eclipse-1.0"?
In the description you can simply put the URL of the pull request or the
github commit.
Reason is that we're not using github for issue tracking.
Thanks!
On 28/02/2013 11:04, HAAS Christian wrote:
Hello there!
Thanks for the info; I already started with my work and created two
pull requests;
One for fixing compile errors with the new wizard (Identified in #7,
pull request is #8), the second is the handling of steps from
referenced jars (#5 & #9).
I opted to work on the references first as I saw this one easier for
starting to work by-the-book with git & github :)
As for the conventions, I used the Eclipse built-in "Java conventions"
for my new files.
On to the next...
Regards,
ch
*From:*Mauro Talevi [mailto:mauro.tal...@aquilonia.org]
*Sent:* Mittwoch, 27. Februar 2013 20:32
*To:* user@jbehave.codehaus.org
*Subject:* Re: [jbehave-user] Modifying Eclipse editor plugin
Hi
There is no strict formatting policy. Using the default Eclipse or
Java one will do fine.
Feel free to provide patches by cloning the GitHub repo and sending
pull requests.
Cheers
On 26 Feb 2013, at 15:34, HAAS Christian
<christian.h...@frequentis.com <mailto:christian.h...@frequentis.com>>
wrote:
Hello there!
I want to modify the Eclipse plugin, specifically handle the
issues #1/#6 and possibly #5 (as numbered on GitHub
https://github.com/jbehave/jbehave-eclipse/issues).
Before I do any drastic changes, I'd like to know whether the
code-format settings are available somewhere. Is there a download
available? If a standard, which one?
We have quite strict and quite different ones, so I want to use
the right ones before running into discussions like where the
opening curly bracket goes and have the commit rejected...
I'll also give some technical background regarding the issues
about the cache invalidation, for anyone interested:
As I see it for any step-lookup the cache first needs to be
rebuilt (when invalid) before it is used. This is done blocking
(JBehaveProject.traverseSteps() -> rebuild() -> awaitTermination() ).
I want to split this up and make the editor become "eventually
consistent". Step traversal will reference the last known cache
and only trigger a cache-rebuild, not wait for its return, if
necessary. After having a new cache, a new editor update could be
fired.
I haven't looked into #5 so far...
Thanks & kind regards,
ch
____________________________________________________
*Christian Haas
*Software Engineer
FREQUENTIS AG
Innovationsstraße 1, 1100 Vienna, Austria
Phone +43-1-811 50 – 8353
Mobile +43-664-60 850 – 8353
Fax +43-1-811 50 – 77 8353
Webwww.frequentis.com
E-Mail christian.h...@frequentis.com
<mailto:christian.h...@frequentis.com>
Handelsgericht Wien (Vienna Commercial Court): FN 72115 b
DVR 0364797, ATU 14715600
____________________________________________________
Diese E-Mail könnte vertrauliche und/oder rechtlich geschützte
Informationen enthalten. Wenn Sie nicht der richtige Adressat sind
oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte
sofort den Absender und vernichten Sie diese E-Mail. Das
unerlaubte Kopieren sowie die unbefugte Weitergabe dieser E-Mail
sind nicht gestattet.
This e-mail may contain confidential and/or privileged
information. If you are not the intended recipient (or have
received this e-mail in error) please notify the sender
immediately and destroy this e-mail. Any unauthorised copying,
disclosure or distribution of the material in this e-mail is
strictly forbidden.
