another modularity issue? No instances of [org.jboss.forge.parser.spi.WildcardImportResolver]
by Thomas Frühbeck
did anyone get this exception when running scaffold generateFromEntity:
Caused by: java.lang.RuntimeException: Error generating default
scaffolding: java.lang.IllegalStateException: No instances of
[org.jboss.forge.parser.spi.WildcardImportResolver] were found on the
classpath.
at
org.jboss.forge.scaffold.faces.FacesScaffold.generateFromEntity(FacesScaffold.java:324)
at
org.jboss.forge.scaffold.plugins.ScaffoldPlugin.generateFromEntity(ScaffoldPlugin.java:174)
... 36 more
Caused by: org.metawidget.inspector.iface.InspectorException:
java.lang.IllegalStateException: No instances of
[org.jboss.forge.parser.spi.WildcardImportResolver] were found on the
classpath.
at
org.metawidget.inspector.iface.InspectorException.newException(InspectorException.java:51)
at
org.metawidget.inspector.impl.BaseObjectInspector.inspectAsDom(BaseObjectInspector.java:279)
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:301)
at
org.metawidget.statically.StaticMetawidget.write(StaticMetawidget.java:247)
at
org.jboss.forge.scaffold.faces.FacesScaffold.generateFromEntity(FacesScaffold.java:253)
... 37 more
Caused by: java.lang.IllegalStateException: No instances of
[org.jboss.forge.parser.spi.WildcardImportResolver] were found on the
classpath.
at
org.jboss.forge.parser.java.impl.AbstractJavaSource.getImportResolvers(AbstractJavaSource.java:363)
at
org.jboss.forge.parser.java.impl.AbstractJavaSource.resolveType(AbstractJavaSource.java:331)
at
org.jboss.forge.parser.java.impl.TypeImpl.getQualifiedName(TypeImpl.java:174)
at
org.jboss.forge.scaffold.faces.metawidget.inspector.propertystyle.ForgePropertyStyle$ForgeProperty.getGenericType(ForgePropertyStyle.java:539)
at
org.metawidget.inspector.propertytype.PropertyTypeInspector.inspectProperty(PropertyTypeInspector.java:176)
at
org.metawidget.inspector.impl.BaseObjectInspector.inspectTraits(BaseObjectInspector.java:343)
at
org.metawidget.inspector.impl.BaseObjectInspector.inspectAsDom(BaseObjectInspector.java:243)
Please help!
12 years, 1 month
[IMPORTANT] API Breakage in Scaffold Modules
by Lincoln Baxter, III
Hi Everyone,
I've *broken the following API* in the *Scaffold API module*. Since we only
have three scaffolds at this time, it seemed best to do this now, since it
will not affect most other plugins:
https://github.com/forge/core/commit/8a366fc0eb6913922b0b31ff21d9869c2fd1...
It is a trivial change, and should be simple to update. In version 2.0, we
should consider passing a ScaffoldConfiguration object instead of
individual parameters, thus allowing us to continue updating without
breaking API compatability.
This breakage will occur in version 1.0.1.CR1 (or .Final if we skip
releasing CR1)
***BEFORE YOU UPDATE to use the new API:*
Be sure to *create a Branch or Tag named "1.0.0.Final"* in your plugin git
repository. This will ensure that those who have not updated to the latest
API will still receive a working version of the plugin.
Thanks,
Lincoln
--
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
12 years, 1 month
JavaClassTest.testFormattingIsNotChanged fails on Windows
by Ivan St. Ivanov
Hi folks,
I was going to create a JIRA issue for this, but I didn't find where to
click (probably I don't have permissions). Anyway... When I run the unit
tests on Windows, I keep getting an error
at JavaClassTest.testFormattingIsNotChanged. The issue is at this assertion:
assertTrue(output.contains(
"Telephone" + System.getProperty("line.separator") +
"{"
));
On windows the line.separator system property resolves to \r\n. However,
the output variable contains actually Telephone\n{. Which means that a \r
is missing.
I hoped I can resolve this by myself. However, the output variable is
initialized by the JavaClass's toString() method. Which is actually
implemented in the AbstractJavaSource class. And there it uses the Document
and TextEdit classes that come from org.eclipse.jface.text
and org.eclipse.text.edits packages respectively. Which is outside Forge.
Does anybody have an idea how can we solve this? Of course we can change
the test. But I'm afraid that the Forge-generated entities look really ugly
on my machine. And I'm afraid that the reason is in this Eclipse library.
Cheers,
Ivan
P.S. Just for the record, I'm running a 64-bit Windows 7.
12 years, 1 month
DISCUSS: Forge Plugin Versioning Strategy
by Lincoln Baxter, III
In order to keep Plugin versioning sane, we should discuss the actual rules
of our versioning strategy. From our meeting today, we discussed the
following possible initial rules:
- Using OSGI versioning system
- Plugins referencing older forge API should run on newer Forge versions
within the same N release for a version number N.x.x
- Plugins referencing newer forge API should not run on older Forge
versions within the same N release for a version number N.x.x
Thoughts? Would someone care to explain the OSGI versioning system?
--
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"
12 years, 1 month
Re: [forge-dev] plugin versioning
by Dan Allen
Although it has a slightly different focus, I advise reading up on Bundler,
the Ruby library versioning tool created by Yehuda Katz to bring sanity to
rails plugins.
It has an interesting version symbol to indicate upgrading along a major
version:
~> 1.1.0
That will allow 1.2.0, but not 2.0.0.
Bundler also has the idea of version locking across the transitive closure.
--
Sent from my CyanogenMod-powered
Android device, an open platform for
carriers, developers and consumers.
On Mar 8, 2012 10:21 AM, "Lincoln Baxter, III" <lincolnbaxter(a)gmail.com>
wrote:
12 years, 1 month
Best Place for Integration Tests
by Koen Aers
Hi guys,
In a discussion earlier today it was suggested that we should not only test the scaffolding with Forge generated entities but also with:
1) quick starts and the maven archetypes
2) the output of the database reverse engineering as generated by the Hibernate Tools plugin
I will create a JIRA to track this issue but I first wanted to know where this issue (and these tests) should live?
Cheers,
Koen
12 years, 1 month
Re: [forge-dev] rest refactoring
by Lincoln Baxter, III
Hey Paul!
Back from Vaca.
My first thought here is that this is excellent use of the Configuration
API, but I think currently the way this is written, it depends on the
Configuration in order to recognize the fact that there is an application
class serving as a REST activator?
We could use the JavaParser TreeVisiting API that was just introduced, in
order to search project sources and make this determination.
https://github.com/forge/core/blob/master/shell-api/src/main/java/org/jbo...
Thoughts?
~Lincoln
On Wed, Feb 15, 2012 at 5:48 PM, Paul Bakker <paul.bakker(a)luminis.eu> wrote:
> Hi Lincoln,
>
> I made some progress on refactoring the rest stuff, plus I added the
> option to use an Application class instead of web.xml. Because it changed
> quite a lot and this is the first time we use the idea of having "nested"
> facets it would probably be good if you review before I merge to master.
>
>
> https://github.com/forge/core/commit/ec0275a821c6bb3ccf690b55d66816073ba0...
>
> Let me know what you think :-)
>
> Paul
>
--
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"
12 years, 1 month
Working outside of a project during test case execution.
by Lincoln Baxter, III
Hey guys,
I saw this come up during the meeting, and wanted to share the answer. It
should be straightforward to simulate working "outside" of a project in a
test case. Just create a temp folder (using the Java file API) then either
CD to that folder, or get a resource handle to it by @Injecting the
ResourceFactory, then set that resource as the current resource using:
shell.setCurrentResource(directory);
>
This is the best way I can think of to achieve this. If it's not working,
then there's a bug somewhere, probably a nasty one :)
~Lincoln
--
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"
12 years, 1 month
