Recursive class addition

[mmatloka]

I'd like to propose to add to Shrinkwrap API possibility of recursive class addition to the archive. E.g. user wants to test class A, class A uses class B (e.g. has field of this type). Adds A to the archive using apropriate function, B will be added automatically. I've created a while ago ticket with sample implementation https://issues.jboss.org/browse/SHRINKWRAP-436 . This could make Shrinkwrap more user friendly and much easier to use in case of complicated class structures. It would be nice to include this in shrinkwrap 2.0 but API needs to be discussed.

Recursivenes could be included in addClass and addClasses methods. Each one with variants with and without option to specifiy 'depth' of dependency resolution (as shown in proof of concept implementation).

[kpiwko]

Prolinking Michal's proof-of-concept implementation. It is available here https://github.com/mmatloka/shrinkwrap/commit/39d5c3aa63a9bb85e6d7b68782879ca10cca273b

[mmatloka]

Any comments ?:)

[kpiwko]

My only concern is that recursive class addition might cause a class to be present twice on classpath in case that user adds a JAR via Resolver. I think it would make more sense to limit recusion only on classes defined in the project itself.

[aslak]

In general I like the idea, but I'm not sure it can be sensible automated at this level.

One problem is as soon as you introduce an interface or di you no longer have any 'link' to follow. At this point you sound worse off then with no help. You have to know the internal rules of how the automated scanning works and your own structure to know what more you have to add to get it to work. Pluss it probably needs Filter support to avoid including Classes from other Archives etc as Karel mentioned.

I think this type of automation fits better in IDE Tooling where you have access to more information and can give the user a choice. Eclipse can answer things like: who implements this interface. And the user can choose which and if the impl should be included. The output of this tooling would be a 'standard' addClass/addPackage created Archive.

HibernateTooling has a similar scanner for Entities.

[mmatloka]

Karel Piwko wrote:

My only concern is that recursive class addition might cause a class to be present twice on classpath in case that user adds a JAR via Resolver. I think it would make more sense to limit recusion only on classes defined in the project itself.

Hm, true, that might be a problem. btw Theoretically currently user can manually add on his own both class nad JAR?

Aslak Knutsen wrote:

In general I like the idea, but I'm not sure it can be sensible automated at this level.

One problem is as soon as you introduce an interface or di you no longer have any 'link' to follow. At this point you sound worse off then with no help. You have to know the internal rules of how the automated scanning works and your own structure to know what more you have to add to get it to work. Pluss it probably needs Filter support to avoid including Classes from other Archives etc as Karel mentioned.

I think this type of automation fits better in IDE Tooling where you have access to more information and can give the user a choice. Eclipse can answer things like: who implements this interface. And the user can choose which and if the impl should be included. The output of this tooling would be a 'standard' addClass/addPackage created Archive.

HibernateTooling has a similar scanner for Entities.

Maybe this feature would fit also Forge, e.g. during Arquillian test creation? (of course finding interface implementations would be harder)