this change really killed me for all of the build automation I have
been working on... and was one of the reasons why I had warned
against using this style of versioning.
basically since this was removed, checking out the specs project and
building it produces nothing, except for this:
org/apache/geronimo/specs/specs/maven-metadata-local.xml
org/apache/geronimo/specs/specs/1.2/specs-1.2.pom
org/apache/geronimo/specs/specs/1.2/specs-1.2-site.xml
since my automation setup actually builds projects, then holds on to
the *exact* build output for use by a project which depends on them,
anything that depends on a spec which is not already released and
propagated to central and its mirrors will fail. This means that
anything that needs a snapshot will always fail.
* * *
one critical error I believe that everyone is making is thinking that
deployed artifacts are permanent... which they are most certainly
not, so we should generally always build from source to ensure that
everything is being included at the right version. IMO the remote
repos are for user connivence *ONLY*, so that you don't need to
always go and build everything. For automated builds it is much
easier to build projects one by one, hold on to the exact outputs,
then use those outputs as dependencies directly to ensure that
dependent builds use the right artifacts.
if the project is not going to build as one might expect when running
`mvn install` from the root.... and if that is because you want to
version each of those bits separately and use the half-functional
maven release plugin to handle releases... then each of these really
needs to be a self-contained project.
I really feel that the little short-cuts and side-steps around maven
problems are going to kill us. And really, I don't see how any
medium to large sized group can effectively use maven to manage
releases of their projects... especially not by following in the
footsteps of the mvn community wrt they way it versions its
components or assumes that remote repositories always contain
permanent artifacts which are always trusted.
--jason
