automatic dependency detection problem
by Thomas Frühbeck
Hi Lincoln,
I understand absolutely, that you didn't want to open an _impl_.
It is important to know, that it's not my fault, that it's not working.
I do (not) think that your faces plugin is limited:
No: I am really impressed by the power of the plugin, the integration of
Metawidget is a great showcase!
Yes: when trying to apply Forge to an existing persistence model I was
confronted with some interesting questions :)
After having applied the reverse engineer to my database, I found that
the legacy primary keys were not picked up by the system.
At first I thought, that some minor changes to the templates and the
widgets would suffice, but then I realized, that the changes would be
too much distributed all over the impl.
The options I reviewed so far:
- redesign the DB: not so bad, but more than one project use the
entities - very bad
- accept the (preferred) generation of "id" strings an remap the
generated ID via JPA-annotations to the physical XXID
Downside: a lot of legacy code (e.g. HQL statements) to refactor, very
few tests :/
- use the PK-names from legacy persistence model so I can reuse legacy code
a) when importing the legacy model, the scaffold will not use my PK, but
render the PK as normal fields
b) when changing only the templates and some widgets, the application
will break between view and bean layer
The beauty of Forge is the possibility to continuously use it to develop
the application.
In my case it would be kind of generate-repair-use-cycle (which is not
so much fun) mainly because of the primary key handling.
So I decided to investigate the situation in more detail and I think
that I found a kinda viable solution by implementing some changes to the
inspectors, widgets, templates ....
I am sure you know what I mean, you did the really big part, isn't it :-)
That's where I am now and I am really grateful for the insights I got
into the inner workings of this bunch of brand new technology.
So I decided to start a new plugin project based on the faces scaffold
as close as possible, being able to follow your development without
interrupting your progress. I don't know if and when I can spend enough
time to get it working.
In short: after having analyzed the problem I think that the primary key
handling is to be fixed.
Forge is a great tool and I think it's worth spending some time on this.
I have started to do so, and I would be very grateful if you could take
the time and have a look at it - when it works :-)
Any remarks, hints appreciated,
Thomas
> We intentionally block this module because there should not be direct
> access to the implementation classes. I know that the current Scaffold API
> is very limited, but I think that in most cases, we can add SPIs and
> extension points in order to give you access to what you need.
>
> We can try to figure out a non-impl specific way to do this depending on
> what you need. Otherwise we could consider exposing the impl, but I think
> that should be a last resort.
>
> What is it that you are trying to access in the impl, and why?
14 years
automatic dependency detection problem
by Thomas Frühbeck
Hi,
I am working on a plugin extending for the Faces scaffold. I want to
reference classes of the existing forge-scaffold-faces plugin.
Compilation and testing works so far in Netbeans / Maven.
Unfortunately when loading the module via "forge source-plugin" not all
dependencies are detected and written to module.xml.
I need the dependency to scaffold.impl too:
<module name="org.jboss.forge.scaffold.impl" services="import"/>
I find the following:
<module xmlns="urn:jboss:module:1.0"
name="at.tfr.forge.forge-scaffold-faces-id-aware"
slot="1.0.0-SNAPSHOT-411d1fc6-b52d-42c5-9518-773a6d759dbe">
<resources>
<resource-root path="forge-scaffold-faces-id-aware.jar"/>
</resources>
<dependencies>
<module name="at.tfr.forge.forge-scaffold-faces-id-aware.dependencies"
slot="1.0.0-SNAPSHOT-411d1fc6-b52d-42c5-9518-773a6d759dbe"/>
<module name="org.jboss.forge.javaee.api" services="import"/>
<module name="org.jboss.forge.maven.api" services="import"/>
<module name="org.jboss.forge.scaffold.api" services="import"/>
<module name="org.jboss.forge.shell.api" services="import"/>
<module name="org.jboss.seam.render" services="import"/>
<module name="javax.api"/>
</dependencies>
</module>
If I add the dependency manually after installation, everything works.
I just cant find the problem :-/
Regards,
Thomas
14 years
Code coverage metrics
by Richard Kennard
Hi guys,
Just curious: what is the consensus on code coverage tools within JBoss?
Metawidget used to have great, combined unit test and integration test coverage reports (http://metawidget.org/doc/coverage/index.html). But since moving
to Maven/Jenkins a couple years ago I haven't found an equivalent tool. The closest I have found is Sonar and Jacoco but these doesn't give a combined report?
Regards,
Richard.
14 years
Re: [forge-dev] [forge-users] Get a list of all classes extending a specific class
by Lincoln Baxter, III
(Switching to Dev List)
Hey Rudy,
Awesome! I figure adding a new set of methods in the JavaSourceFacet would
do the trick... something like this:
JavaSourceFacet java = project.getFacet(JavaSourceFacet.class);
>
> java.visitSources("com.base.package", new JavaSourceVisitor() {...});
> java.visitTestSourceTree("com.base.package", new JavaSourceVisitor()
> {...});
>
> java.visitSources(new JavaSourceVisitor() {
> public void visit(VisitContext context, JavaSource source) {
>
> // to end the visit after this method returns, call this method
>
context.visitComplete();
>
> }
> } );
>
> java.visitTestSources(new JavaSourceVisitor() {
> public void visit(VisitContext context, JavaSource source) {
> context.visitComplete();
> }
> } );
>
Thoughts?
~Lincoln
On Wed, Feb 1, 2012 at 7:21 AM, Rudy De Busscher <rdebusscher(a)gmail.com>wrote:
> I'll have try
>
> Rudy
>
>
> On 31 January 2012 19:01, Lincoln Baxter, III <lincolnbaxter(a)gmail.com>wrote:
>
>> Hi Rudy,
>>
>> Source scanning is on the list of things to implement in the
>> JavaSourceFacet, but unfortunately we don't have it yet. Actually, we could
>> use some help with this feature. Is that something you'd be interested in
>> creating, since you know what you need?
>>
>> https://issues.jboss.org/browse/FORGE-469
>>
>> There are methods called: javaClass.getSuperType() and getInterfaces()
>> that you can use, though, but there just isn't any way to walk over all
>> source files yet. Wouldn't be hard to implement!
>>
>> ~Lincoln
>>
>> On Tue, Jan 31, 2012 at 9:23 AM, Rudy De Busscher <rdebusscher(a)gmail.com>wrote:
>>
>>> Hi all,
>>>
>>> For a plugin, I could use some functionality that scans the source
>>> directories and report me all the java classes that extend a certain class.
>>>
>>> But I couldn't find anything for that in Forge.
>>>
>>> Is there some way of getting the parent class ? (or do I have the
>>> 'parse' the source myself (find extend clause and see what come next))
>>>
>>> Thx
>>>
>>> Best regards
>>>
>>> --
>>> Rudy De Busscher
>>> http://www.c4j.be
>>>
>>>
>>> _______________________________________________
>>> forge-users mailing list
>>> forge-users(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/forge-users
>>>
>>>
>>
>>
>> --
>> Lincoln Baxter, III
>> http://ocpsoft.com
>> http://scrumshark.com
>> "Keep it Simple"
>>
>> _______________________________________________
>> forge-users mailing list
>> forge-users(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/forge-users
>>
>>
>
>
> --
> Rudy De Busscher
> http://www.c4j.be
>
>
> _______________________________________________
> forge-users mailing list
> forge-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-users
>
>
--
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"
14 years, 1 month
