Fwd: Re: FORGE-568 "Allow running/debugging Forge in eclipse" opinion quest
by Thomas Frühbeck
OK, the size limit killed me, another go to send this message:
Hi,
I just finished a first draft of the ForgeConsole in Debug mode.
The loading of the embedded Forge runtime ist still not working, this
needs real experts :-/
So if you would like to give it a try, pleas load your own runtime in
the Forge preferences.
The implementation is still a bit shaky, but at least the direction
seems to be clear.
Still missing:
- automatic source lookup of Forge sources in eclipse
- and of course most interesting: the lookup of sources which are
used by Forge during debug - that will be real fun :-))
Load the attached plugin: unzip in <eclipse-home>/dropins/
To run the DebugForge: [SHIFT]+[CTRL]+[4]
Please find attached:
- the zip of the plugin for dropins folder
- the source I adapted included in the soure.jar files will come in
separate message
So, how do we go from here, to whom can I pass over the sources for
quality check / check-in?
Any ideas welcome,
Thomas
Am 26.05.2012 19:51, schrieb Lincoln Baxter, III:
> This is a really great idea! Fantastic!
>
> On Sat, May 26, 2012 at 5:49 AM, Koen Aers <koen.aers(a)gmail.com
> <mailto:koen.aers@gmail.com>> wrote:
>
> Yes, that's actually a good idea. It would also be cool if we
> could pickup the classes being worked upon directly in the
> class/module path of this Forge launch, but I guess that will not
> be so easy...
>
> Cheers,
> Koen
>
11 years, 10 months
How should plugins keep up with api updates
by Koen Aers
Hi Folks,
The Forge meeting today started off with a discussion spawned by this JIRA issue: https://issues.jboss.org/browse/FORGE-584.
You can find the complete discussion in the logs: http://transcripts.jboss.org/meeting/irc.freenode.org/forge/2012/forge.20.... By the way why was there no email send around with this info? Isn't this supposed to happen automatically?
The summary is that there are 2 aspects to this problem:
1. When installing a Forge plugin, the correct version of this plugin, compatible with the runtime that is requesting the install should be selected
2. When launching a Forge runtime, the plugins that are not compatible with the runtime that is launched cannot be enabled
AFAIK both aspects have been addressed to some extent but the discussion proves that there is room for improvement. This email thread is the place where we can continue this discussion and maybe hash out some JIRA issues.
As I understand, FORGE-584 was due to the fact that the plugin referenced version 1.0.0-SNAPSHOT of the Forge API in the 1.0.2.Final branch of the plugin. It is not abnormal that this does not work. The plugins should be compatible at runtime but not necessarily building with the latest and greatest version of the Forge API. So this was IMO a bug in the plugin code where the plugin writer had not properly updated the dependencies in one (or more) branch(es). I believe we already had this discussion before and I really don't see a way to make this updating process go smoother. Ideas here are more than welcome.
To address the second aspect above, it is a bit awkward to have to reinstall all the plugins when the runtime is for example updated from version 1.0.6.Final to 1.1.0.Final. And what if you need to maintain 1.0.x and 1.1.x at the same time? To address these problems I see 2 possibilities. The first is to allow multiple versions of plugins to be installed next to each other and the runtime will select the most appropriate version when it starts. When the compatible version of an already existing plugin is not available, Forge could ask the user if it can be installed automatically, thus addressing the manual reinstall mentioned earlier. The second solution would be that every runtime has its own location to install plugins and comes already bundled with a number of 'blessed' plugins, much like the Eclipse way of doing stuff. Again, ideas more than welcome.
WDYT?
Cheers,
Koen
11 years, 11 months
Forge Hack Night
by George Gastaldi
Hello Everyone !!!
I picked some issues which may work as the starting point for our
Forge Hack night. If you feel confortable with any other let me know.
I added the "HackNight" label on it.
Anyway, these are the issues and their descriptions:
FORGE-578: Faces setup fails when project is created with --type war
FORGE-564: Allow multiple @Alias for a plugin
FORGE-553: Forge Console does not display special characters
FORGE-360: FacesPlugin should automatically add the faces mapping if
the servlet version < 3
FORGE-85: Shell cannot parse command values containing '!' exclaimation points
We´ll be on IRC and if you feel you can help, join us ! :D
The forge hack night is every Wednesday, on 19:00 to 20:00 GMT-3, so,
may the Forge be with you.
Regards,
George Gastaldi
11 years, 11 months
Dev meeting today.
by Lincoln Baxter, III
I may be late or miss the dev meeting today. Would someone else mind
leading today?
Topics to discuss:
* Ideas for upcoming hack night
* other?
---
Lincoln Baxter's Droid
http://ocpsoft.org
"Simpler is better."
11 years, 11 months
Forge License
by George Gastaldi
Hello all,
Dan Allen, Lincoln and I were discussing about moving Forge license to
EPL (Eclipse) instead of the current Apache one.
What are your thoughts about it? Glad if you could post your comments
on https://issues.jboss.org/browse/FORGE-580
Thanks,
George Gastaldi
11 years, 11 months
FORGE-568 "Allow running/debugging Forge in eclipse" opinion quest
by Thomas Frühbeck
Hi,
browsing the issues of Forge I found this one:
https://issues.jboss.org/browse/FORGE-568
It would be most easily done by a small change of /core/dist/pom.xml in
the "runForge" profile.
To make the setup easier it is necessary to make eclipse think it's a
java project, AFAIK by adding the JavaNature in project.xml.
Even more simplified would be a locally stored eclipse run configuration
file, making the setup a "one-line-howto" :-)
My question is: is it acceptable to commit IDE specific files in the
core/dist/ directory?
Files namely:
/dist/.project.xml
/dist/runForge.launch
Thomas
11 years, 11 months
