David Lloyd wrote:
Jason Greene wrote:
David Lloyd wrote:
Well, any of the following solutions would work:
- Run embedded stuff in a fully modularized environment
- Put everything on the app classpath (and hope there's no duplicate dependencies...)
- Use a hybrid solution with a customized module repos where no packages are duplicated between modules and the app class path
Just using the app classpath is the simplest, assuming you don't hit any duplicate issues.
I had typed up this nice really well thought out post, but the forums decided to eat it. So instead I will summarize :)
Basically I think 2 is a non-option as it will be brittle and it directly contradicts with our hide internal impl requirement. Not to mention if we are testing a client server protocol we actually do want the classes to be in separate loaders.
I don't think all our requirements apply for all embedded use cases. That said I don't think that the flat-classpath embedded arrangement is suitable for testing our own stuff in most cases, but I think some users will want to do it that way. I agree that long-term we should focus on encouraging users to run in a modularized environment.
For our tests I am going with 1 (or really 3), the custom test runner makes it a lot nicer and easier than what I had before.
Once this has taken a bit more shape, I would like to extract the embedded startup into an embedded/ module with options for starting embedded AS in both flat and modular modes so that it can be consumed directly, at the moment this is hidden away in the testsuite.