Checking in on Gradle Addon
by Lincoln Baxter, III
Hey Adam,
Seems like things have been a bit quiet, but I've been reviewing the Forge
Gradle Addon, and it's looking good! I've reproduced the dependency
resolution issue you ran in to, but I'm not exactly sure where the error
lies. Looking in to it.
You asked what to work on next. And I think that if you have finished all
of the core/required functionality, it might be interesting to add a Forge
UICommand/UIWizard to set up this eclipse config:
http://www.gradle.org/docs/current/userguide/eclipse_plugin.html
That should make it easier for people to import Gradle projects into
eclipse. Do you think this has value?
Alternatively, have you tested the scenario where a user attempts to use an
existing Gradle project with Forge? It does not appear that this is tested
yet, so that might be useful to explore. I believe this may raise a few new
issues like, "Should we modify the user's gradle.build script in order to
support Forge operations?" and "How should we ask them?"
It's possible that you could simply create a temporary build descriptor
with the required forge library, execute that, then delete it. Or perhaps a
new command in Forge to "Make a gradle project editable by forge."
Thoughts?
--
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
12 years
[Scaffold Spring Problem]
by Valmir Justo
Hi,
My name is Valmir. I have been using the JBoss forge the 3 months ago.
I started the simple project, new-project, persistence setup, scaffold
--Type spring etc.
However, I have tried use the scaffold spring and when i execute the
command-line scaffold from-entity 'name Entity' and receive the
printStackTrace:
Exception encountered:
org.metawidget.util.simple.StringUtils.isCapitalized(Ljava/lang/String;)Z
(type "set VERBOSE true" to enable stack traces).
Set the VERBOSE mode,
java.lang.NoSuchMethodError:
org.metawidget.util.simple.StringUtils.isCapitalized(Ljava/lang/String;)Z
at
org.jboss.forge.scaffold.spring.metawidget.inspector.propertystyle.ForgePropertyStyle.isGetter(ForgePropertyStyle.java:250)
at
org.jboss.forge.scaffold.spring.metawidget.inspector.propertystyle.ForgePropertyStyle.lookupGetters(ForgePropertyStyle.java:198)
at
org.jboss.forge.scaffold.spring.metawidget.inspector.propertystyle.ForgePropertyStyle.inspectProperties(ForgePropertyStyle.java:151)
at
org.metawidget.inspector.impl.propertystyle.BasePropertyStyle.getUncachedTraits(BasePropertyStyle.java:172)
at
org.metawidget.inspector.impl.BaseTraitStyle.getTraits(BaseTraitStyle.java:126)
I look for the internet but without success.
Could help me?
Tks
Best regards.
Valmir Justo
12 years, 1 month
Feature Freeze on Forge 1.x Branch
by Lincoln Baxter, III
Hello Forge Devs!
As of Friday (6th) this week, we are initiating a feature freeze for Forge
1 and JBoss Tools functionality for Forge 1. This means that no new
functionality will be added to the Forge 1 branch. Only bug-fixes will be
allowed.
All new feature and enhancement work should proceed on Forge 2 on the
core/2.0 branch (and related repositories). These are exciting times and
we are moving into a new world of tooling productivity :)
Thanks,
--
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
12 years, 1 month
Questions about migrating git-tools to Forge 2
by Ivan St. Ivanov
Hey folks!
This weekend I've been hacking on migrating the git-tools to Forge 2 (
https://issues.jboss.org/browse/FORGE-1128). And I can say that I have
pretty much finished the task (although I haven't started yet with the
git-tools-tests, but I will do that as well).
And I have the following questions and observations:
1) How do you declare that a UI command requires to be executed in the
context of a project or in a context of a certain resource? In Forge 1 we
had the @RequiresProject and @RequiresResource annotations, but now we only
have @RequiresFacet (I hope it works ;)). What I do here is: implement
isEnabled and work with the initialSelection method of the UIContext to
check what is selected. BTW I find quite more declarative approaches in
Forge 1 than in Forge 2.
2) In Forge 1 we had one plugin class that represented a command with a lot
of options as methods of that class. Did I get it right that in Forge 2 I
have to create a separate UICommand implementation for every option (i.e.
method) of the plugin class? I don't say it's bad, I just want to
understand whether this is the way
3) How do you get the current resource (@Current as of Forge 1)? Is
it context.getInitialSelection().get()? How can I check that it is of any
particular type (e.g. GitIgnoreResource)?
4) Is there such a thing as setup command? I think there's no need, but
still I'd like to ask
5) If a facet has to write a message to a provider (GUI, shell), how does
it do it? Commands do that via the Result object, but I didn't get how
facets can. Or should they at all write anything?
6) I saw that some of the git commands in Forge 1 fire pickup events:
Event<PickupResource>::fire(new PickupResource(gitIgnoreResource()));
How is this done in Forge 2. I would appreciate a sample in existing plugin
7) How did you migrate existing completers? I see that the completer
interface has changed. I am afraid I can't figure out how I can rework
complete methods from Forge 1, that were using CommandCompleterState
parameter. I couldn't find samples
And of course I have some questions about the git-tools implementation that
have nothing to do with the migration:
1) At the moment the GitUtils class, which I have made an interface and
plan to export as addon, exposes some JGit classes as parameters. Do you
think it's a good idea to wrap them in our own classes like you have done
with the JDT parser API for example?
2) I see that in javaee-impl you have implemented an abstract command class
that exposes a class that returns the current project (or null):
org.jboss.forge.addon.javaee.ui.AbstractProjectUICommand. I copy-pasted the
getSelectedProject method to an abstract Git UI command class that I
created just becayse I saw that addon-ui does not have access to the
project API (outherwise I would put it in the AbstractUICommand class). Can
we find a better place for this code? In Forge 1 we just @Inject-ed a
Project instance, but now I am not sure what to do
So, that's all from me for now. Next to come - the questions about the
migration about the tests ;)
Cheers,
Ivan
12 years, 1 month