1 2 Previous Next 15 Replies Latest reply on Mar 2, 2013 10:30 AM by mmatloka

    New SW Subproject?


      From George:


      (06:32:03 PM) gastaldi: ALR, I have a suggestion for another ShrinkWrap subproject, not sure if it's in scope

      (06:33:38 PM) gastaldi: ping me if you're interested

      (06:33:43 PM) gastaldi: bye


      Well, speak!

        • 1. Re: New SW Subproject?

          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 !

          • 2. Re: New SW Subproject?

            What about naming it "ShrinkWrap Conception" ?

            Here is the code as it exists in Forge today:




            • 3. Re: New SW Subproject?

              OK, so:


              "You could create a Java class test INSIDE your test class during runtime "


              And the use case?

              • 4. Re: New SW Subproject?

                Test runtime deplyable EJB mocks?


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



                • 5. Re: New SW Subproject?

                  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.

                  • 6. Re: New SW Subproject?

                    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.)

                    • 7. Re: New SW Subproject?

                      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..

                      • 8. Re: New SW Subproject?

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

                        • 9. Re: New SW Subproject?

                          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?

                          • 10. Re: New SW Subproject?

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

                            • 11. Re: New SW Subproject?

                              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.

                              • 12. Re: New SW Subproject?

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

                                • 13. Re: New SW Subproject?

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

                                  • 14. Re: New SW Subproject?

                                    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.

                                    1 2 Previous Next