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:
"You could create a Java class test INSIDE your test class during runtime "
And the use case?
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.
I see value too. I also see cost associated with creating and maintaining a new project, so I'm as of yet unsold by the investment. Who feels very strongly they need this? And do we have resourcing for building this out in mind?
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.