Luciano, Your hijacked version of pom portrays all the issues associated with a top down pom with a single version in a complex project. You have included the modules you want to build. It may not be of any use to me, if I want to build a separate set of modules. So what is the point in committing your pom to the source tree, if it is of use to only yourself?
Then the solution would be to build the whole thing. That would never scale for complexity. Why would I want to build the whole kitchen sink, if I am interested in building only a subset that is pertinent to the task I am working on? A single version and top down build that builds everything, IMHO, would create unnecessary coupling in complex projects. If we rely on a top down build that builds everything, regardless of area of the project we are working on, I would say we lack clarity in terms of how the project is architecturally modularized. And for new comers to build samples, I agree with Jeremy that the best thing to do is use mvn assemblies based on published artifacts. On a side note, I think you should never give up :) IMHO we should have these constructive discussions, as long as they are in the best interest of the community and the project. ta Meeraj >> -----Original Message----- >> From: Luciano Resende [mailto:[EMAIL PROTECTED] >> Sent: 24 March 2007 00:05 >> To: tuscany-dev@ws.apache.org >> Subject: Re: Build structure - having cake and still eating >> >> OK, I give up on this, and I'll try not bring this subject >> up anymore !!! >> >> I'll continue with my hijacked java/pom.xml and update it as >> needed, I just feel sorry for the new people that will come >> to the Tuscany community and will fill the same pain as >> Mario and others. >> >> Just in case others might benefit from this, here are the >> profiles I have in my hijacked java/pom.xml that is working >> at the moment and building sca or sdo or das. >> >> <profiles> >> <!-- profile to build sdo --> >> <profile> >> <id>sdo</id> >> <modules> >> <module>sdo</module> >> </modules> >> </profile> >> >> <!-- profile to build das --> >> <profile> >> <id>das</id> >> <modules> >> <module>das</module> >> </modules> >> </profile> >> >> <!-- profile to build sca --> >> <profile> >> <id>sca</id> >> <modules> >> <!-- support modules --> >> <module>pom/parent</module> >> <module>pom/sca</module> >> <module>buildtools</module> >> >> <!-- spec --> >> <module>spec/sca-api-r1.0</module> >> >> <!-- sca modules --> >> <module>sca/kernel</module> >> <module>sca/runtime</module> >> <module>sca/services</module> >> <module>sca/console</module> >> <module>sca/jms-discovery</module> >> <module>sca/http.jetty</module> >> >> <!-- samples --> >> <module>sca/core-samples</module> >> >> <module>sca/core-samples/standalone/calculator</module> >> >> <module>sca/core-samples/standalone/loanapplication</module> >> >> >> <!-- integration tests --> >> <module>sca/integration-test</module> >> >> <!-- unstbale modules that are left out of the build >> <module>sca/core-samples/webapp/webcalc</module> >> --> >> </modules> >> </profile> >> </profiles> >> >> >> -- >> Luciano Resende >> http://people.apache.org/~lresende >> >> On 3/23/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote: >> > >> > >> > On Mar 23, 2007, at 2:16 PM, Luciano Resende wrote: >> > >> > > Jeremy >> > > >> > > So, having these assemblies modules sounded interesting to me >> > > until the moment you said you want to base them on deployed >> > > artifacts... we have never had a habit of publishing >> SNAPSHOTS for >> > > all possible artifacts, and even the members of the >> community that >> > > are proposing this approach are failing to deploy the SNAPSHOTS >> > > artifacts and Mario's pain is a prove of this. >> > >> > Ideally the deployed artifacts they would depend on would >> be stable >> > released ones - this is directly inline with the stability goals >> > expressed by the likes of Dave Booz. In general, >> aggregations should >> > not depend on SNAPSHOTs or a head revision except where absolutely >> > necessary. >> > >> > Mario's pain was caused because we had not put together an >> assembly of >> > the modules needed for the demo. It was the wee hours of >> the morning, >> > I hope you understand. Once the dust settled, the modular, >> independent >> > nature of what we had allowed us to put together a very simple >> > assembly for building exactly that (independent of any >> other activity >> > in trunk). You can see this here: >> > >> https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/tsss- >> > demo >> > >> > > >> > > You also mentioned before that we have M2 experience >> of a top down >> > > build not working, I'm not sure about all the details >> that comes to >> > > your mind when you say that, but I remember some build >> brakes (and I >> > > think this is acceptable in trunk, right ?) >> > >> > No, not really. >> > >> > > and we could set some conventions like, modules that are >> "unstable >> > > at the moment" would be removed from the maven profile >> (and maybe a >> > > JIRA would be created)... later on, when the module is >> back to it's >> > > stability, whoever fixed the issue would close the JIRA (if >> > > any) and put the module back to the stable profile. >> > >> > The problem of this approach is that it couples everything >> together >> > through the parent pom. Even if a separate parent is used, >> the reactor >> > will attempt to use common dependency versions across the modules. >> > This means that modules get coupled together based on the >> versions of >> > their dependencies and so we lose the independence between them. >> > >> > Basically, unless they all use the same version then they >> won't all >> > build. >> > >> > > >> > > Also, this is not about MAVEN PROFILE versus ASSEMBLY. >> I'm sure >> > > both can co-exist together in perfect harmony, and it would >> > > definitely be a good solution for members of the >> community that are >> > > interested only in a subset of Tuscany (e.g some >> embedder that only >> > > requires the kernel, and a Spring extension for >> example), and these >> > > assembly modules could be created as needed >> > > >> > > These profiles would probably make the user experience >> of someone >> > > that comes to evaluate Tuscany trunk much easier, as already >> > > mentioned by Mario [1], and help others to be more productive as >> > > already expressed on various other threads [2][3]. >> > >> > This is where we disagree. Doing what you suggest couples >> all modules >> > at a single monolithic version level. That may be desirable in a >> > commercial product but is not a way to scale an open >> source community. >> > >> > One of the problems we have is that the documentation on >> the build and >> > the pom structure is misleading and confusing users. I >> wanted to clean >> > that up by removing bad poms such as java/pom.xml but was >> overruled. >> > >> > > >> > > If I understand your concerns, having the convention of moving >> > > unstable modules out of the maven profile should help, >> but maybe you >> > > could explain what worries you, that you are fighting so >> hard not to >> > > allow people to build different modules with a simple >> mvn command. >> > > Nevertheless, it's good practice to build before committ, right ? >> > >> > Please can we not make this personal - I am not fighting >> hard not to >> > allow anything. I am trying to find a middle ground that >> allows people >> > who need to build groups of modules to do so and at the same time >> > preserve the independence between the modules. >> > >> > I do not know of a way to make what you want work with >> independently >> > versioned modules. I have proposed something that people >> seemed to be >> > able to live with and which I believe works. Let's hear >> technically >> > viable alternatives. >> > >> > -- >> > Jeremy >> > >> > >> > >> --------------------------------------------------------------------- >> > To unsubscribe, e-mail: [EMAIL PROTECTED] >> > For additional commands, e-mail: [EMAIL PROTECTED] >> > >> > >> >> >> This message has been checked for all email viruses by MessageLabs ***************************************************** You can find us at www.voca.com ***************************************************** This communication is confidential and intended for the exclusive use of the addressee only. You should not disclose its contents to any other person. If you are not the intended recipient please notify the sender named above immediately. Registered in England, No 1023742, Registered Office: Voca Limited Drake House, Three Rivers Court, Homestead Road, Rickmansworth, Hertfordshire, WD3 1FX. United Kingdom VAT No. 226 6112 87 This message has been checked for all email viruses by MessageLabs. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
