Git plugin broken under Forge 1.0.0.Final on Windows?
by Richard Kennard
Hi guys,
On Windows, under a clean install, I see the stack below. It's fine if I first create a new-project. Is this expected behaviour?
---
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.
C:\Users\Richard>z:
Z:\>cd forge-distribution-1.0.0.Final
Z:\forge-distribution-1.0.0.Final>bin\forge
_____
| ___|__ _ __ __ _ ___
| |_ / _ \| `__/ _` |/ _ \ \\
| _| (_) | | | (_| | __/ //
|_| \___/|_| \__, |\___|
|___/
Windows? Really? Okay...
[no project] forge-distribution-1.0.0.Final $ set VERBOSE true
set VERBOSE true
[no project] forge-distribution-1.0.0.Final $
[no project] forge-distribution-1.0.0.Final $ forge git-plugin git://github.com/forge/scaffold-aerogear.git
***ERROR*** [forge git-plugin] null
org.jboss.forge.shell.exceptions.CommandExecutionException
at org.jboss.forge.shell.command.Execution.perform(Execution.java:153)
at org.jboss.forge.shell.command.fshparser.FSHRuntime.run(FSHRuntime.java:125)
at org.jboss.forge.shell.command.fshparser.FSHRuntime.run(FSHRuntime.java:63)
at org.jboss.forge.shell.ShellImpl$ExecutorThread.run(ShellImpl.java:829)
at org.jboss.forge.shell.ShellImpl.execute(ShellImpl.java:852)
at org.jboss.forge.shell.ShellImpl.doShell(ShellImpl.java:642)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.weld.bean.proxy.AbstractBeanInstance.invoke(AbstractBeanInstance.java:48)
at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:125)
at org.jboss.forge.shell.ShellImpl$Proxy$_$$_WeldClientProxy.doShell(ShellImpl$Proxy$_$$_WeldClientProxy.java)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.weld.util.reflection.SecureReflections$13.work(SecureReflections.java:305)
at org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:54)
at org.jboss.weld.util.reflection.SecureReflectionAccess.runAsInvocation(SecureReflectionAccess.java:163)
at org.jboss.weld.util.reflection.SecureReflections.invoke(SecureReflections.java:299)
at org.jboss.weld.introspector.jlr.WeldMethodImpl.invokeOnInstance(WeldMethodImpl.java:188)
at org.jboss.weld.introspector.ForwardingWeldMethod.invokeOnInstance(ForwardingWeldMethod.java:59)
at org.jboss.weld.injection.MethodInjectionPoint.invokeOnInstanceWithSpecialValue(MethodInjectionPoint.java:198)
at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:282)
at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:265)
at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:234)
at org.jboss.weld.manager.BeanManagerImpl.notifyObservers(BeanManagerImpl.java:635)
at org.jboss.weld.manager.BeanManagerImpl.fireEvent(BeanManagerImpl.java:622)
at org.jboss.weld.manager.BeanManagerImpl.fireEvent(BeanManagerImpl.java:616)
at org.jboss.forge.shell.Bootstrap$1.run(Bootstrap.java:120)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.forge.shell.command.Execution.perform(Execution.java:149)
... 31 more
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.solder.unwraps.UnwrapsInvocationHandler.invoke(UnwrapsInvocationHandler.java:82)
at org.javassist.tmp.java.lang.Object_$$_javassist_0.getScopedConfiguration(Object_$$_javassist_0.java)
at org.jboss.forge.shell.plugins.builtin.ForgePlugin.getProxySettings(ForgePlugin.java:190)
at org.jboss.forge.shell.plugins.builtin.ForgePlugin.prepareProxyForJGit(ForgePlugin.java:472)
at org.jboss.forge.shell.plugins.builtin.ForgePlugin.installFromGit(ForgePlugin.java:405)
... 36 more
Caused by: java.lang.IllegalStateException
at org.jboss.forge.shell.env.ScopedConfigurationAdapter.getScopedConfiguration(ScopedConfigurationAdapter.java:74)
at org.jboss.forge.shell.env.ConfigurationAdapter.getScopedConfiguration(ConfigurationAdapter.java:59)
... 45 more
[no project] forge-distribution-1.0.0.Final $
12 years, 9 months
GSoC students are going to love Forge, don't miss it!
by Dan Allen
Forge is such a perfect fit for GSoC. The barrier to getting started is
reasonable, plugin ideas can branch out in almost any direction, and the
whole goal of Forge is to grow the plugin community. For more advanced
students, there's even an opportunity to work on the core.
What do you need to do to invite GSoC students to the Forge party?
It's pretty simple. Go to the GSoC 2012 ideas page [1], copy the idea
proposal template and fill in the details with your idea. Submissions for
mentoring organizations (e.g., JBoss) are due on Friday, so we need those
ideas listed there by then (there may be leeway, but I can't be sure).
[1] https://community.jboss.org/wiki/GSOC12Ideas
It doesn't take long. I've done 4 proposals already myself. Let's get
students involved in Forge!
-Dan
--
Dan Allen
Principal Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://google.com/profiles/dan.j.allen
http://mojavelinux.com
http://mojavelinux.com/seaminaction
12 years, 9 months
plugin versioning
by Paul Bakker
Hi all,
Yesterday during the meeting we talked about plugin versioning. Currently Forge checks if there is a tag/branch of the plugin that matches the Forge API version while installing. We discussed if we can test on compatibility of plugins on a CI server.
I started thinking about this again and actually think we should re-think the version checking mechanism. Now that Forge is final, the APIs should be stable. They should be stable until we go for a 2.0.0 version, which means plugins are not supposed to break on API changes for 1.0.1, 1.1.0 etc. If we do that correctly, it's also not necessary to upgrade plugins each time there is a new release (or be back at building to snapshots which is dangerous). Instead I suggest prompting available versions of plugins during plugin installation (still looking at tags for that), so that a user can choose to use a stable version, some beta or maybe a snapshot. This also gives us the freedom to do minor Forge releases more often without the hazzle of upgrading all plugins once again…
Thoughts?
Paul
12 years, 9 months
Presentation for the JUGs
by Ivan St. Ivanov
Hi everyone,
Now with Forge already final, it's time for us to advertise it to our local
JUGs. I would take the opportunity to talk about it in the Bulgarian JUG
(somewhere in April though :-(). Here is what I plan to show:
1) General rant about Forge: what it is good for and how it differs from
maven archetypes and Spring Roo (no religious stuff, I'm a Spring fan BTW)
2) Developing a Java EE application with scaffolding: here I would show
something more complex than the conference sample app that Lincoln already
presented on the Java2Days conference in Sofia last year. Here I would like
to talk about some of the not so common features of the metawidget
plugin. Any ideas? Of course also some Arquillian and OpenShift.
3) After a short break I would continue with a different type of
application that you could implement with Forge. Looking at the plugins,
maybe it could be the OSGi stuff.
4) Next: developing a plugin. Create a sample plugin, explanation of the
different settings: command, options, usage of the shell prompt, the
environment, the configuration API, etc.
5) Finally: the get involved section
What do you think? Should I add something else or drop anything?
Cheers,
Ivan
12 years, 9 months
AeroGear: unable to load JPA classes
by Richard Kennard
Hi guys,
I'm struggling to get the AeroGear plugin working. It runs fine in unit tests, but when packaged as a standalone plugin I get the error below.
It appears my module does not have access to javax.persistence.* (hibernate-jpa-2.0-api-1.0.1.Final.jar or similar). How do I declare this dependency?
Regards,
Richard.
---
[test] test $ scaffold from-entity com.test.model.* --scaffoldType aerogear
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.forge.shell.command.Execution.perform(Execution.java:149)
at org.jboss.forge.shell.command.fshparser.FSHRuntime.run(FSHRuntime.java:125)
at org.jboss.forge.shell.command.fshparser.FSHRuntime.run(FSHRuntime.java:63)
at org.jboss.forge.shell.ShellImpl$ExecutorThread.run(ShellImpl.java:829)
at org.jboss.forge.shell.ShellImpl.execute(ShellImpl.java:852)
at org.jboss.forge.shell.ShellImpl.doShell(ShellImpl.java:642)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.weld.bean.proxy.AbstractBeanInstance.invoke(AbstractBeanInstance.java:48)
at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:125)
at org.jboss.forge.shell.ShellImpl$Proxy$_$$_WeldClientProxy.doShell(ShellImpl$Proxy$_$$_WeldClientProxy.java)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.weld.util.reflection.SecureReflections$13.work(SecureReflections.java:305)
at org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:54)
at org.jboss.weld.util.reflection.SecureReflectionAccess.runAsInvocation(SecureReflectionAccess.java:163)
at org.jboss.weld.util.reflection.SecureReflections.invoke(SecureReflections.java:299)
at org.jboss.weld.introspector.jlr.WeldMethodImpl.invokeOnInstance(WeldMethodImpl.java:188)
at org.jboss.weld.introspector.ForwardingWeldMethod.invokeOnInstance(ForwardingWeldMethod.java:59)
at org.jboss.weld.injection.MethodInjectionPoint.invokeOnInstanceWithSpecialValue(MethodInjectionPoint.java:198)
at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:282)
at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:265)
at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:234)
at org.jboss.weld.manager.BeanManagerImpl.notifyObservers(BeanManagerImpl.java:635)
at org.jboss.weld.manager.BeanManagerImpl.fireEvent(BeanManagerImpl.java:622)
at org.jboss.weld.manager.BeanManagerImpl.fireEvent(BeanManagerImpl.java:616)
at org.jboss.forge.shell.Bootstrap$1.run(Bootstrap.java:120)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.lang.NoClassDefFoundError: javax/persistence/Lob
at org.metawidget.inspector.jpa.JpaInspector.inspectProperty(JpaInspector.java:86)
at org.metawidget.inspector.impl.BaseObjectInspector.inspectTraits(BaseObjectInspector.java:343)
at org.metawidget.inspector.impl.BaseObjectInspector.inspectAsDom(BaseObjectInspector.java:243)
at org.metawidget.inspector.impl.BaseObjectInspector.inspectAsDom(BaseObjectInspector.java:69)
at org.metawidget.inspector.composite.CompositeInspector.runInspector(CompositeInspector.java:241)
at org.metawidget.inspector.composite.CompositeInspector.runInspectors(CompositeInspector.java:220)
at org.metawidget.inspector.composite.CompositeInspector.inspectAsDom(CompositeInspector.java:167)
at org.metawidget.inspector.composite.CompositeInspector.inspectAsDom(CompositeInspector.java:151)
at org.metawidget.inspector.composite.CompositeInspector.inspectAsDom(CompositeInspector.java:53)
at org.metawidget.pipeline.base.BasePipeline.inspectAsDom(BasePipeline.java:344)
at org.metawidget.statically.StaticMetawidget.inspect(StaticMetawidget.java:305)
at org.metawidget.statically.StaticMetawidget.write(StaticMetawidget.java:251)
at org.jboss.forge.scaffold.aerogear.AeroGearScaffold.generateFromEntity(AeroGearScaffold.java:218)
at org.jboss.forge.scaffold.plugins.ScaffoldPlugin.generateFromEntity(ScaffoldPlugin.java:174)
... 36 more
12 years, 9 months
SOLVED: installing plugins on Windows
by Richard Kennard
Hi guys,
I have identified the problem with installing plugins of Windows and looking for .forge in the wrong location. It seems it has nothing to do with any Java
code. Rather, the file bin/forge.bat contains...
if "%HOME%" == "" (set "HOME=%HOMEDRIVE%%HOMEPATH%")
...
-modulepath %HOME%\.forge\plugins
So it is using the variable %HOME% *if it is not already set*. However, there is a small, fringe project (I don't think it'll ever catch on :) called 'Git'
which asks you to set an environment variable called HOME too. If I change all references to %HOME% to, say, %USERHOME%...
if "%USERHOME%" == "" (set "USERHOME=%HOMEDRIVE%%HOMEPATH%")
...
-modulepath %USERHOME%\.forge\plugins
Then it works. I haven't pushed any changes in case you disagree with this approach?
Regards,
Richard.
12 years, 9 months
Errai vs JDT, or?
by Ivan St. Ivanov
Hi everyone,
Today at the meeting I asked whether we could use the Errai code generation
APIs and not the ones from Eclipse. The reason for that was not that I am
an Eclipse API hater (which I am ;-)), but because I hope that with Errai
we will be able to solve problems more easily (it's a JBoss project and you
know each other ;-)). By problems that we may need to be solved, I mean
something like the discussion in this thread:
http://lists.jboss.org/pipermail/forge-dev/2011-December/001370.html
Lincoln mentioned on the meeting that the purpose of the Errai API is
different. However, I didn't get it. Why can't we use it instead of JDT?
BTW, the JavaClassTest keeps failing on my Windows machine and Forge
produces awfully formatted entities on this OS. :-(
Cheers,
Ivan
12 years, 9 months
