Jerome Dochez wrote:
> One of the difficulty of "being" part of the same build is that they
> come from different java.net projects with different contributor
> lists, different SCM so I am not exactly clear on how you can easily
> have this in place. On top of that, building everything all the time
> which is the only sure way to have the SNAPSHOTS right is going to
> slow down the overall build time.
It will be done by RE and hudson, so a few extra minutes is not that
important. I consider GlassFish to be a release vehicle for various
sub-projects like HK2, jsp, scripting support, etc.
> So we need to review the upcoming proposal carefully before doing this
> (which won't be before SCF).
+1
>
> Finally snapshot will make life the external projects very
> complicated, as they cannot rely on un-versioned modules like
> glassfish-api. I believe we could alleviate the problem by tagging the
> snapshot builds but these are in a sense versions.
In the new proposal (more to follow next week), RE will promote builds
that carries a non-SNAPSHOT version. External projects can depend on
such promoted builds.
>
> For the time being, I think we should continue with the current way of
> doing things until we are sure there is a better way. Therefore,
> jspimpl should not be integrated as a snapshot, however jspimpl seems
> to be depending on web-common (end of the dependency trail) so that
> would force us into releasing this module too.
jsp team is aware of this circular dependency and they are working on it.
Thanks,
Sahoo