Please see the issue 221667 (or module maven.j2ee, class EmbeddableEJBContainerHint, line 181) for some background. In Java EE Maven project we need to access glassfish embedded static shell pom file for correct project configuration in some cases.
Currently there is a hard-coded value with an URL for the latest version of glassfish (e.g.  is the current URL). This is obviously not a good approach, because we need to fix this value with each new GF version.
Would be great if you could create an simple API that provides either this URL or at least latest GF version which we can use for constructing the URL (assuming that the repository is not changed much often).
Not a user visible problem - shouldn't this be ENHANCEMENT?
Of course it could be (maybe TASK is even better) ..the question is if it will be ever fixed if we change the type. But agree, user does not need to care about NB internal code.
Ok, for now I am leaving as defect and adding NO73.
Postponed for next release. I do not have enough time to fix/implement P3 issues now. :(
So does this mean that the hint to "Use EJBContainer from installation ..." that was available before in the generated test is not available if the target server is 4.0?
So for 7.4 will the user need to manually modify the pom to add the property and dependency for the static-shell.jar if they are using GF4.0?
(In reply to Kenneth Ganfield from comment #5)
> So does this mean that the hint to "Use EJBContainer from installation ..."
> that was available before in the generated test is not available if the
> target server is 4.0?
I'm afraid yes. I can fix it on Maven side (by changing the hard-coded value to url pointing to GF 4.0), but the problem will occur again for GF 4.0.1 or whatever the future GF release will be..
> So for 7.4 will the user need to manually modify the pom to add the property
> and dependency for the static-shell.jar if they are using GF4.0?
That was the reason why I create this ticket - to avoid forgetting of this problem with every new release of GF. And we have forgotten again. As I said, I can fix it again in Maven, but the problem will persist if GF plugin won't be exposing some API for it..
Thanks for the confirmation.
I agree that hard-coding it for every new GF release is not a good solution.
I think that it would be good if there was some hint that the property and/or dependency needs to be specified in the pom if it is not there. I do not know if that is possible though. Right now there is no indication that the configuration is not correct.
However, any user who uses this testing scenario often will soon recognize the output when the test fails and know how to fix it.