geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Dillon <ja...@planet57.com>
Subject no more modules for specs...
Date Fri, 15 Dec 2006 23:41:36 GMT
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

Mime
View raw message