14:27:02 - mmatloka: gastali I've seen you have ome proposition:)?

14:28:11 - gastaldi: mmatloka, ah yeah, I had the idea of a Java Parser as a subproject of ShrinkWrap. So you could create and parse classes dinamically

14:29:37 - gastaldi: The Eclipse JDT has an API for that

14:30:01 - gastaldi: makes sense ?

14:31:14 - gastaldi: You could create a Java class test INSIDE your test class during runtime

14:31:35 - gastaldi: how cool is that ?

14:35:37 - mmatloka: hmmm

14:38:15 - mmatloka: how parsing classes compares e.g. to ASM?

14:39:49 - gastaldi: well, I thought of an API to ease that instead of using the ASM library directly

14:39:56 - gastaldi: anyway, just a thought

14:40:30 - mmatloka: yeah, asm is not the most user friendly ;P

14:41:29 - mmatloka: I used it in that recursive class addition (sm)

14:41:34 - mmatloka: (asm)

14:41:46 - rmannibucau: asm is wonderful guys and pretty easy

14:42:29 - mmatloka: it is powerfull

14:42:52 - gastaldi: yes, It is very powerful, but I wouldn't say easy is the right word to describe it

14:48:11 - mmatloka: gastaldi i was thinking recently about topic of 'creating classes', for shrinkwrap descriptors, if there could be some more maitanable alternatives for used there xsl's etc

14:48:57 - gastaldi: XSL are such a pain I used to work directly with it for 6 years

14:51:26 - gastaldi: mmatloka, Forge has an API for it

14:58:09 - mmatloka: gastaldi concernig forge api, it automatically provides imports etc?

14:58:48 - gastaldi: yes

15:06:19 - mmatloka: maybe it is really a good option to create this new subproject and use it then in shrinkwrap, shrinkwrap descriptors and forge

15:06:34 - gastaldi: that was my thought

15:08:13 - gastaldi: where would it fit in descriptors and shrinkwrap projects ?

15:08:35 - gastaldi: ahh to generate the descriptors java classes ?

15:08:40 - mmatloka: yeah

15:08:42 - gastaldi: instead of using XSLT you mean

15:08:47 - gastaldi: right

15:09:02 - mmatloka: and shrinkwrap - resucrsive class addition - which now is based on ASM

15:09:10 - gastaldi: and shrinkwrap ?

15:09:22 - gastaldi: ah yeah

15:09:22 - gastaldi: fits perfectly !

What about naming it "ShrinkWrap Conception" ?

Here is the code as it exists in Forge today:

https://github.com/forge/core/tree/master/parser-java

https://github.com/forge/core/tree/master/parser-java-api

Test runtime deplyable EJB mocks?

createClass().annotate(@Statless).implements(SomeInterface.class).setMethodBody("SomeMethod", "return 300");

?

I'm not sure I see a need to create a new sub-project for this. There's also nothing Forge-specific about this module, and it can already be consumed simply by includning it in any Java SE project.

Not saying no, but If you guys did find this valuable and want to pursue a move, then I'd like to understand the reasons why it should be moved instead of staying where it is.

I think Andy's point is that you could just create a class file in the test sources for this. But on the converse side, you could also do non-typesafe class generation and avoid the need to reference libraries on the test-classpath just to get your mocks to compile. (Not saying it's better this way, just that it *could* be done.)

It's the same reason why Descriptors exists really. The need to test X number of variations. Having an XML file for each could be cumbersom. Not sure it belongs in ShrinkWrap but.. as a genral thought..

I certainly see the value in the ability to do something like this.

Just to be clear, I'm not pushing for this. I'm just adding my thoughts.

Just to clarify: The idea is NOT to donate the existing Forge code, but to bring a new project which, using a DSL approach, could manipulate / parse Java classes, by adding methods, fields, annotations and so on.

A use case could be a plain JavaBean which during deploy time could add a @Stateful or even a CDI qualifier, for example.

Actually that's what the Forge code actually does, so it's a good reference to start with

Defo +1 from my side. I was just starting to ask about wrapper for JDT AST... but then jumped to George's pom

Speaking of testing perspective, I see the biggest advantage of this project to be able to mock tests running AS_CLIENT in an easy way. For IN_CONTAINER testing, I can see a little value, as we already have @Mock.