On 3/22/07, Luciano Resende <[EMAIL PROTECTED]> wrote:
I think this issue will be raised again and again every time new members come to try Tuscany trunk, and this is very bad for a project that is trying to build a community. Also, trying to quote an article Jim Marino sent from Martin Fowler about Continuous Integration [1] : "Automated environments for builds are a common feature of systems. The Unix world has had make for decades, the Java community developed Ant, the .NET community has had Nant and now has MSBuild. Make sure you can build and launch your system using these scripts using a single command. A common mistake is not to include everything in the automated build....." also, this has been already discussed in various other threads [2] [3]. Based on this, I'll start a VOTE around a proposal to get a set of profiles to allow for building the trunk in a more automated way. [1] - http://www.martinfowler.com/articles/continuousIntegration.html [2] - http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg14658.html [3] - http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg15303.html On 3/22/07, Raymond Feng <[EMAIL PROTECTED]> wrote: > > Hi, > > I hate to bring up this issue again, but I really share the pain that > Mario > just went through. Don't we think we have room for improvements to build > the > stuff in a much simpler fashion? To me, to have a build for a bundle which > consists of a set of the modules working together at the same level would > be > really helpful for the poor guys. It's very difficult to manually > coordinate > the build across modules even with published SNAPSHOTs (which I don't see > it > happens frequently and it's also very hard because a collection of > SNAPSHOTs > don't really establish a baseline for those who want to try the latest > code). > > I (assume that I) understand all the rationales and pricinples for > modulization. But I'm really scared by the user experiences. Where is the > reasonable middle ground? > > Thanks, > Raymond > > ----- Original Message ----- > From: "Antollini, Mario" <[EMAIL PROTECTED]> > To: <tuscany-dev@ws.apache.org> > Sent: Thursday, March 22, 2007 6:57 AM > Subject: RE: Compilation status > > > Meeraj, > > Finally, I was able to generate the server.star.jar file. > > This is compilation order that worked for me: > > java/spec/commonj/ > java/spec/sca-api-r1.0/ > java/sca/kernel/ > java/sca/runtime/ > java/sca/services/ > java/sca/contrib/discovery/ > java/sca/contrib/discovery/jms > java/sca/console/ > java/sca/core-samples/ > java/distribution/sca/demo.app > java/distribution/sca/demo/ > > Disclaimer: I have been struggling with the compilation for two days, I > cannot fully assure that the order of the above list is the actual > order. If anyone is able to compile this exact way, please let us know. > > BTW, java/sca/extensions/ cannot be compiled for now. > > Besides the good news, I was not able to start the servers (take a look > at the attachment to see the errors) > > Do you have any idea what could be happening? > > Thanks and regards, > Mario > > > -----Original Message----- > From: Meeraj Kunnumpurath [mailto:[EMAIL PROTECTED] > Sent: Thursday, March 22, 2007 10:13 AM > To: tuscany-dev@ws.apache.org > Subject: RE: Compilation status > > Mario, > > AFAIK extensions in trunk is still in a bit of a flux. If you want to > run the demo, you don't need to run the extensions (the demo uses Java > container with local bindings), I will try to post a dfeinitive list of > tasks to build and run the demo later in the day, which will be useful > to Simon as well. > > Ta > Meeraj > > -----Original Message----- > From: Antollini, Mario [mailto:[EMAIL PROTECTED] > Sent: Thursday, March 22, 2007 12:29 PM > To: tuscany-dev@ws.apache.org > Subject: Compilation status > > Meeraj, > > > > I just wanted you to know that I am still not able to compile the code I > checked out from SVN. The main problem is located in the *extensions* > project. I have been modifying the pom files within this project but I > did not manage to get it compiled yet. > > > > Basically, the main problems are related to inconsistencies between > parent references (e.g.; axis2's root project is using groupId > *org.apache.tuscany.sca.axis2* while the plugin subproject states that > its parent is *org.apache.tuscany.sca.extensions.axis2*). > > > > Any tips about this? > > > > Thanks, > > Mario > > > 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] > > > > > > -------------------------------------------------------------------------------- > > > > --------------------------------------------------------------------- > > 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] > > -- Luciano Resende http://people.apache.org/~lresende
I don't mind that all the modules build independently but would like an automated way of doing them all together if I want to to meet a specific purpose. A couple of weeks ago I went through this to build the calculator sample. It was a struggle to start with but worked out fine when the guys explained it to me. What really helped me get off the ground was script that someone wrote (Raymond? I don't remember) which just called all the right builds in the right order. As it turned out the script was wrong for the trunk at the time which causes its own problems but if we had some automated way for pulling the individual builds together for specific purposes that was up to date that would be cool. As was said before you need a specific set of things for a specific purpose. We are not in the position where we are trying to do 1000s of different combinations of modules at the moment so I'm sure we could codify the few that we need. For example, from higher up this thread, Mario has very usefully identified the right modules to build and right build order for the federation demo. Why can't we capture this using some simple automation and then use that when we need to and point new comes at that if they want/have to build from source. Regards Simon
