|This is using Ant as the deployment language. If the sar depends on the |war because it is adapting a legacy protocol to soap for example, you |would then need to repackage the above to: | |jar/ |---war/ |------sar |------jar2
that is correct, | |I would rather see an ear as the standalone deployment package and |include a jboss-application.xml descriptor that allows for the |specification |of deployment ordering in there. it is limited to ears scott, we need something that works across of deployment units. the right way (TM) is with 77 (objectname) dependencies when everything is an mbean with an objectname in 77 but 1- this is ways off and requires some work in all the layers 2- this requires xml coding, you need to code the exact names to achieve the right order, and these are jmx like object names that are subject to fucking up... i wasn't shooting for the stars, just something to start with and make sure we reach final with a foolproof way of explaining how to do dependencies. i am actually partial to the solution below 1- deployN directories as rcN 2- war/jar/sar/xml as implicit ordering within one directory (we are j2ee after all) 3- the S00MyJAR.jar numbering of unix within one directory as this will enable us to move to straight xml files, where we would have S78my-service.xml, S92mybean.xml (with unified xml a la david jencks), S333mywar.xml.... the need to package an ear as implicit unit then sorts of dissapear if we have a way to specify the URL context, which david unified proposal does. we have an explicit way of ordering them JUST BY NAME, you look at the directory and you know what is going on. i am sold... going back to training marcf PS: actually i think we can even REMOVE the deployN (rc.d) and just go with straightnumbering and voila... hmmm simpler. _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
