I'm trying to better understand and reflect about the day to day changes that might come from this discussion, and here are some questions :
I think this scenario is really good between projects (e.g SCA and Axis, and/or SCA and DAS), but does it really make sense to have DAS Container from trunk not working with SCA from trunk ? I think this will be a side effect of having a DAS container based on a old SCA or Kernel or any other SNAPSHOT module. Also, on the scenario where I'm working on the DAS container and need to change/add functionality to DAS, how do I grab the source of the SNAPSHOT of that DAS,make necessary updates, and start using that, instead of the published SNAPSHOT ? Or I'll have to add the functionality to DAS, publish a new SNAPSHOT (that might bring other instabilities) and then I can use it. ? This would be a problem for interactive parallel development, no ? Also, are we going to flood IPMC with release votes (I'm only counting the final release votes), as we need to vote for DAS and SDO, Kernel, etc, once that is released then we need to vote for all containers, etc no ? Have we looked on how other Apache Projects are handling this ? -- Luciano Resende http://people.apache.org/~lresende On 1/9/07, Raymond Feng <[EMAIL PROTECTED]> wrote:
Hi, To better evaulate if the code base is ready to be a release, there are two useful techiques discribed in the "Better Builds with Maven" book (http://www.mergere.com/m2book_download.jsp): 6.9. Monitoring and Improving the Health of Your Dependencies Run "mvn site" to create dependency and dependency convergence reports. The report shows all of the dependencies included in all of the modules within the project. It also includes some statistics and reports on two important factors: * Whether the versions of dependencies used for each module is in alignment. This helps ensure your build is consistent and reduces the probability of introducing an accidental incompatibility. * Whether there are outstanding SNAPSHOT dependencies in the build, which indicates dependencies that are in development, and must be updated before the project can be released. 6.10. Monitoring and Improving the Health of Your Releases An important tool in determining whether a project is ready to be released is Clirr (http://clirr.sf.net/). Clirr detects whether the current version of a library has introduced any binary incompatibilities with the previous release. Thanks, Raymond ----- Original Message ----- From: "Jim Marino" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Tuesday, January 09, 2007 1:27 AM Subject: Re: tuscany-sca revision 493223 does not build? (mvn claims missing jar dependency) >I know very little about Maven except to follow how it expects projects to >be structured and behave or it will inflict untold amounts of pain (which >is probably fair given its goal of trying to standardize project build >structures) :-) Here is how I picture things will work: > > 1. We decided that modules are either independent or grouped by function. > For example, the Axis2 binding extension and the WSDL to Java tool if it > is specific to Axis. Modules are grouped independently from their > dependencies. For example, the JPA extension is independent from the > Geronimo transaction manager since the two are not inherently tied > together (the former only requires a JTA implementation). > > 2. We also decided that modules will be organized in the source tree by > how they are released. For example, the Axis2 binding extension will be > grouped with the WSDL to Java tool. This will have the side effect of > solving the problem of specifying versions of common dependencies. > > 3. The above assumes modules will be developed independently or by how > they are grouped. Consequently, most of the time, they will never > reference a SNAPSHOT version of a dependency. Instead, modules will > reference a released version. This hold whether the dependency is on > another Tuscany Java SCA module or third-party software. For example, the > kernel, SDO, Spring, or ActiveMQ. Another way of viewing this is that > dependencies on other Tuscany modules are treated as if they were > third-party software. Sometimes a module may choose to work off a > SNAPSHOT version. If that is the case, the developers of the module are > responsible for keeping up with changes as the SNAPSHOT version is > updated. Consequently, relying on a SNAPSHOT version may result in > instability. It will more often be the case that modules will upgrade to > a new released version of a dependency. From a process standpoint, there > should be no difference between upgrading Axis2 and Tuscany kernel > versions. > > 4. Samples will be grouped with their respective modules. For example, > the JavaScript samples would be grouped with the JavaScript extension > module. Samples which span multiple technologies will be grouped > separately and will behave the same as modules, i.e. they will most often > reference released versions of dependencies. Grouping samples with their > extensions will allow them to be released without having to release all > of the other (unrelated) samples. It will also provide a more modular > distribution as end-users will receive only the samples they are > interested in. > > 5. Modules will be released either independently or by grouping. They > will not be released with their dependencies. For example, the Axis2 > extension and the WSDL to Java tool will be released independently from > kernel. This is the same process we have been following on a more macro > level between the SCA, SDO and DAS subprojects. This is more of a > release "caravan" as opposed to "train". Modules can choose to provide > follow on releases after a new dependency version is published (e.g. > kernel, SDO, etc.) or they may choose to wait depending on the module > lifecycle. > > 6. Samples may be released with their extensions or independently; it is > up to the module. > > In practice, I would expect upstream modules such as kernel to release > early and often. When a downstream module is ready, it will cutover to > using the new released version of the upstream modules. If downstream > modules all rely on SNAPSHOT versions, we will wind up with the same > monolithic and unstable build we currently have since SNAPSHOTs represent > the state of HEAD. Sometimes a module will require a new feature in a > dependency. In this case, Tuscany dependencies will work the same as > third-party ones: either a new release is cut or SNAPSHOT is used. > > What happens when B and C reference incompatible versions of A and > someone wants to use them together? For end-users, in the runtime, we > will load different versions of A using SCA deployment mechanisms and > classloader isolation. Similarly, in development, their dependencies need > to be isolated by referencing different versions of A and making sure the > proper classloader isolation is in effect, otherwise they cannot use them > together. > > Given this, specific comments inline... > > Jim > > >> I'm perfectly cool. Thanks for your thoughts, I'm just trying to >> understand what you're saying and how this modular build scheme is going >> to work, and I'm still looking for answers to some of my questions :) >> >> - Are we going to update snapshot Jars over time? or use a >> <uniqueVersion>true</uniqueVersion> repository config to publish unique >> timestamped versions (which, if I understand correctly will not update >> over time)? or do we only want to use releases of pieces of Tuscany to >> build working assemblies? >> > By their nature SNAPSHOTS evolve over time. However, "working" assemblies > should generally never reference SNAPSHOT versions as they change causing > instability. Rather, working assemblies should reference released > versions of dependencies. > >> - If we're going to use timestamped snapshots, does anybody know how to >> reference a specific timestamp (I couldn't figure this out from the >> Maven docs). >> > I don't think we need to reference specific timestamps. Either a module > references a released version or SNAPSHOT. If it references the latter, > it is responsible for tracking changes. If the module developers require > ongoing stability, they should not reference SNAPSHOT. > >> - How do people in the group want to associate a specific SVN revision >> with a published snapshot? Jeremy, do you know the recommended Maven way >> to do that? >> > We should never need to do this. > >> Thanks, >> >> -- >> Jean-Sebastien >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
