Re: Build structure - having cake and still eating
On 3/24/07, ant elder <[EMAIL PROTECTED]> wrote: On 3/24/07, Luciano Resende <[EMAIL PROTECTED]> wrote: > > OK, I give up on this, and I'll try not bring this subject up anymore > !!! Don't give up, its important to get to the build we think is the best for Tuscany. I think the crux of the problem was said in the previous email - we can't see how to make what we want work with independently versioned modules. So are "independently versioned modules" worth it? Given all the past threads debating this, all the confusion and trouble users and developers have been having, and the current state of the project and community, how about we put independently versioned modules as a TODO to look at in the future when things are more clear and stable, and for now go back to a single version and a project you can build from the top with mvn? Discussion on this seems to have died down so I'm going to call a vote so we have closure on this for the next release. I'll leave it a couple more days to see if anything else comes up but given the whats been said i think the vote will be along the lines of having a single version for everything in java/sca and pom.xml that enables all that to be built from the top with mvn. ...ant
Re: Build structure - having cake and still eating
Jeremy, All excellent reasons!! Let's get a release out that everyone can back as a team and we can revisit this after that. For now, let's live with relativePath and it's consequences. No, please don't drag me into the technical discussions. that will make me take sides which i don't want to do. Objective again is to get a release out where all of us though unhappy for one reason or another but are willing to back it up as a community and works almost ok for all of us :) thanks, dims On 3/24/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote: On Mar 24, 2007, at 6:30 AM, Davanum Srinivas wrote: > Using assemblies is ok. It does not have to be published. Once > everyone is in the same bandwagon, then it's ok to publish. Till then, > please find a way to work with assemblies w/o having to rely on > published artifacts. If this is a maven problem, then find another way > to solve the problem or ask at least raise an issue with maven folks. Dims Our build to date relies on the ability to reuse stable, common definitions such as this: https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/pom/ sca/1.0-incubating/pom.xml What we are talking about publishing here is one parent pom, in line with mvn best practice. I don't think anyone has any issue with what's in it. There are several ways in which this can "work" without publishing things, but all of them have technical disadvantages. For example, you can use in the parent element of your pom, but that ties the logical project structure to the physical directory structure. That precludes you from reusing unstable modules via svn externals or copy, and means that if you want to refer to stable modules users would need to check out from the root *INCLUDING ALL TAGS, BRANCHES AND C++ CODE.* This is not SVN best practice. We can fix that by restructuring the project so that tags live alongside modules but that is a fairly radical change in layout. Alternatively, we can remove the dependency on a parent and repeat the plugin definitions that it contains in the pom for every module. The disadvantage of course is that there is a lot of repetition of common definitions. This is not Maven best practice. A third option is simply not to use Maven, or perhaps to use a hybrid of Maven and something else (e.g. Ant). Finally, I understand the stick here, but there is a difference between waving the stick and beating people with it. Changing the rules on publication requires broad technical changes in the project going against best practice for the tools we use - I ask that you actively involve yourself in the discussions around those rather than just telling others to find a way to make it work. > As for myself, am putting my foot down on publishing till everyone > shares. This is getting more and more like 3-4 year olds in the > sandbox not sharing their toys and saying hey you did not talk to me > when i talked to you. So shut up now. Everyone has a life, everyone > has priorities. When folks come to the table, the conversation should > begin again. Again, Please figure out a way everyone can work. At the start of this thread, I thought we /were/ making progress with good discussion between myself, Raymond, Meeraj, Simon and Jim and general agreement on a compromise solution. Then Luciano throws his toys out the pram and we are back to square one. I am at the table and willing to keep talking. Maybe we should change the subject, perhaps "are independently versioned modules worth it?" -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ways of working together [was - RE: Build structure - having cake and still eating]
Meeraj, Thanks!. No, am not advocating any technical direction. That is for you all to decide. All i insist is that everyone converge on the trunk. That's where we will make releases from. thanks, dims On 3/24/07, Meeraj Kunnumpurath <[EMAIL PROTECTED]> wrote: Dims, I am more than happy to find a middle ground where everyone can work together. I was just pointing out the technical issues with a top down pom. Worst case as a compromise, I may even agree to a top-down pom, even though I don't agree with it from a technical perspective, so that we can work together. On a side note what I suggested on the thread "Objective of the following sandbox", is that there had been lot of discussion and work in the last two months on stuff around the kernel. As I said, I am happy to discuss Sebastien's proposal. However, that should not be done in isolation. We should also take into consideration, the work we have done so far and why we want to start from scratch rather than improve the kernel incrementally. I am all for modularizing the kernel, this is something we all agree on. However, that doesn't mean we start from scratch. Some of the issues Sebastien has raised were discussed on the list more than ten moths ago, and we as a community took a decision to take the direction we now have in kernel. In my opinion that is water under bridge. However, if we need to go back and discuss those things again, I am happy to do it. But as I said, these discussions shouldn't be done in isolation, there should also be a strong rationale on what is so wrong with the current kernel, that it needs to be changed so drastically. Thanks Meeraj >> -Original Message- >> From: Davanum Srinivas [mailto:[EMAIL PROTECTED] >> Sent: 24 March 2007 13:31 >> To: tuscany-dev@ws.apache.org >> Subject: Re: Build structure - having cake and still eating >> >> Meeraj, >> >> Using assemblies is ok. It does not have to be published. >> Once everyone is in the same bandwagon, then it's ok to >> publish. Till then, please find a way to work with >> assemblies w/o having to rely on published artifacts. If >> this is a maven problem, then find another way to solve the >> problem or ask at least raise an issue with maven folks. >> As for myself, am putting my foot down on publishing till >> everyone shares. This is getting more and more like 3-4 year >> olds in the sandbox not sharing their toys and saying hey >> you did not talk to me when i talked to you. So shut up now. >> Everyone has a life, everyone has priorities. When folks >> come to the table, the conversation should begin again. >> Again, Please figure out a way everyone can work. >> >> thanks, >> dims >> >> On 3/23/07, Meeraj Kunnumpurath <[EMAIL PROTECTED]> wrote: >> > 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
Re: Build structure - having cake and still eating
On Mar 24, 2007, at 6:30 AM, Davanum Srinivas wrote: Using assemblies is ok. It does not have to be published. Once everyone is in the same bandwagon, then it's ok to publish. Till then, please find a way to work with assemblies w/o having to rely on published artifacts. If this is a maven problem, then find another way to solve the problem or ask at least raise an issue with maven folks. Dims Our build to date relies on the ability to reuse stable, common definitions such as this: https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/pom/ sca/1.0-incubating/pom.xml What we are talking about publishing here is one parent pom, in line with mvn best practice. I don't think anyone has any issue with what's in it. There are several ways in which this can "work" without publishing things, but all of them have technical disadvantages. For example, you can use in the parent element of your pom, but that ties the logical project structure to the physical directory structure. That precludes you from reusing unstable modules via svn externals or copy, and means that if you want to refer to stable modules users would need to check out from the root *INCLUDING ALL TAGS, BRANCHES AND C++ CODE.* This is not SVN best practice. We can fix that by restructuring the project so that tags live alongside modules but that is a fairly radical change in layout. Alternatively, we can remove the dependency on a parent and repeat the plugin definitions that it contains in the pom for every module. The disadvantage of course is that there is a lot of repetition of common definitions. This is not Maven best practice. A third option is simply not to use Maven, or perhaps to use a hybrid of Maven and something else (e.g. Ant). Finally, I understand the stick here, but there is a difference between waving the stick and beating people with it. Changing the rules on publication requires broad technical changes in the project going against best practice for the tools we use - I ask that you actively involve yourself in the discussions around those rather than just telling others to find a way to make it work. As for myself, am putting my foot down on publishing till everyone shares. This is getting more and more like 3-4 year olds in the sandbox not sharing their toys and saying hey you did not talk to me when i talked to you. So shut up now. Everyone has a life, everyone has priorities. When folks come to the table, the conversation should begin again. Again, Please figure out a way everyone can work. At the start of this thread, I thought we /were/ making progress with good discussion between myself, Raymond, Meeraj, Simon and Jim and general agreement on a compromise solution. Then Luciano throws his toys out the pram and we are back to square one. I am at the table and willing to keep talking. Maybe we should change the subject, perhaps "are independently versioned modules worth it?" -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Ways of working together [was - RE: Build structure - having cake and still eating]
Dims, I am more than happy to find a middle ground where everyone can work together. I was just pointing out the technical issues with a top down pom. Worst case as a compromise, I may even agree to a top-down pom, even though I don't agree with it from a technical perspective, so that we can work together. On a side note what I suggested on the thread "Objective of the following sandbox", is that there had been lot of discussion and work in the last two months on stuff around the kernel. As I said, I am happy to discuss Sebastien's proposal. However, that should not be done in isolation. We should also take into consideration, the work we have done so far and why we want to start from scratch rather than improve the kernel incrementally. I am all for modularizing the kernel, this is something we all agree on. However, that doesn't mean we start from scratch. Some of the issues Sebastien has raised were discussed on the list more than ten moths ago, and we as a community took a decision to take the direction we now have in kernel. In my opinion that is water under bridge. However, if we need to go back and discuss those things again, I am happy to do it. But as I said, these discussions shouldn't be done in isolation, there should also be a strong rationale on what is so wrong with the current kernel, that it needs to be changed so drastically. Thanks Meeraj >> -Original Message- >> From: Davanum Srinivas [mailto:[EMAIL PROTECTED] >> Sent: 24 March 2007 13:31 >> To: tuscany-dev@ws.apache.org >> Subject: Re: Build structure - having cake and still eating >> >> Meeraj, >> >> Using assemblies is ok. It does not have to be published. >> Once everyone is in the same bandwagon, then it's ok to >> publish. Till then, please find a way to work with >> assemblies w/o having to rely on published artifacts. If >> this is a maven problem, then find another way to solve the >> problem or ask at least raise an issue with maven folks. >> As for myself, am putting my foot down on publishing till >> everyone shares. This is getting more and more like 3-4 year >> olds in the sandbox not sharing their toys and saying hey >> you did not talk to me when i talked to you. So shut up now. >> Everyone has a life, everyone has priorities. When folks >> come to the table, the conversation should begin again. >> Again, Please figure out a way everyone can work. >> >> thanks, >> dims >> >> On 3/23/07, Meeraj Kunnumpurath <[EMAIL PROTECTED]> wrote: >> > 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 conti
Re: Build structure - having cake and still eating
Meeraj, Using assemblies is ok. It does not have to be published. Once everyone is in the same bandwagon, then it's ok to publish. Till then, please find a way to work with assemblies w/o having to rely on published artifacts. If this is a maven problem, then find another way to solve the problem or ask at least raise an issue with maven folks. As for myself, am putting my foot down on publishing till everyone shares. This is getting more and more like 3-4 year olds in the sandbox not sharing their toys and saying hey you did not talk to me when i talked to you. So shut up now. Everyone has a life, everyone has priorities. When folks come to the table, the conversation should begin again. Again, Please figure out a way everyone can work. thanks, dims On 3/23/07, Meeraj Kunnumpurath <[EMAIL PROTECTED]> wrote: 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. >> >> >> >> >> sdo >> >> sdo >> >> >> >> >> >> das >> >> das >> >> >> >> >> >> sca >> >> >> pom/parent >> pom/sca >> buildtools >> >> >> spec/sca-api-r1.0 >> >> >> sca/kernel >> sca/runtime >> sca/services >> sca/console >> sca/jms-discovery >> sca/http.jetty >> >> >> sca/core-samples >> >> sca/core-samples/standalone/calculator >> >> sca/core-samples/standalone/loanapplication >> >> >> >> sca/integration-test >> >> >> >> >> >> >> >> -- >> 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 de
RE: Build structure - having cake and still eating
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. >> >> >> >> >> sdo >> >> sdo >> >> >> >> >> >> das >> >> das >> >> >> >> >> >> sca >> >> >> pom/parent >> pom/sca >> buildtools >> >> >> spec/sca-api-r1.0 >> >> >> sca/kernel >> sca/runtime >> sca/services >> sca/console >> sca/jms-discovery >> sca/http.jetty >> >> >> sca/core-samples >> >> sca/core-samples/standalone/calculator >> >> sca/core-samples/standalone/loanapplication >> >> >> >> sca/integration-test >> >> >> >> >> >> >> >> -- >> 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 ex
Re: Build structure - having cake and still eating
+1 to move back to "single version and a project you can build from the top with mvn" On 3/23/07, ant elder <[EMAIL PROTECTED]> wrote: On 3/24/07, Luciano Resende <[EMAIL PROTECTED]> wrote: > > OK, I give up on this, and I'll try not bring this subject up anymore !!! Don't give up, its important to get to the build we think is the best for Tuscany. I think the crux of the problem was said in the previous email - we can't see how to make what we want work with independently versioned modules. So are "independently versioned modules" worth it? Given all the past threads debating this, all the confusion and trouble users and developers have been having, and the current state of the project and community, how about we put independently versioned modules as a TODO to look at in the future when things are more clear and stable, and for now go back to a single version and a project you can build from the top with mvn? ...ant -- Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Build structure - having cake and still eating
On 3/24/07, Luciano Resende <[EMAIL PROTECTED]> wrote: OK, I give up on this, and I'll try not bring this subject up anymore !!! Don't give up, its important to get to the build we think is the best for Tuscany. I think the crux of the problem was said in the previous email - we can't see how to make what we want work with independently versioned modules. So are "independently versioned modules" worth it? Given all the past threads debating this, all the confusion and trouble users and developers have been having, and the current state of the project and community, how about we put independently versioned modules as a TODO to look at in the future when things are more clear and stable, and for now go back to a single version and a project you can build from the top with mvn? ...ant
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. sdo sdo das das sca pom/parent pom/sca buildtools spec/sca-api-r1.0 sca/kernel sca/runtime sca/services sca/console sca/jms-discovery sca/http.jetty sca/core-samples sca/core-samples/standalone/calculator sca/core-samples/standalone/loanapplication sca/integration-test -- 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 t
Re: Build structure - having cake and still eating
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]
Re: Build structure - having cake and still eating
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. 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 ?) 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. 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]. 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 ? [1] - http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg15894.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/23/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote: On Mar 23, 2007, at 2:11 AM, Luciano Resende wrote: > Hi Jeremy > > For the assembly proposal, are you suggesting something like : > > https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/lresende/ > sca/distribution/tss-sample/ Something like that, yeah. You want to rely on things that are as stable as possible, preferably things that have been released. I would not have included pom/parent and buildtools as those are available from the release repo. Generally you want to include as few unstable dependencies as possible. Also, I noticed you have a assembly descriptor in your project but you also include distribution/sca/demo. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende http://people.apache.org/~lresende
Re: Build structure - having cake and still eating
On Mar 23, 2007, at 2:11 AM, Luciano Resende wrote: Hi Jeremy For the assembly proposal, are you suggesting something like : https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/lresende/ sca/distribution/tss-sample/ Something like that, yeah. You want to rely on things that are as stable as possible, preferably things that have been released. I would not have included pom/parent and buildtools as those are available from the release repo. Generally you want to include as few unstable dependencies as possible. Also, I noticed you have a assembly descriptor in your project but you also include distribution/sca/demo. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Build structure - having cake and still eating
Hi Jeremy For the assembly proposal, are you suggesting something like : https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/lresende/sca/distribution/tss-sample/ -- Luciano Resende http://people.apache.org/~lresende On 3/22/07, Davanum Srinivas <[EMAIL PROTECTED]> wrote: Jeremy, Please take a look at axis2 poms and geronimo poms. you don't need to install the parent pom before building modules. you can specify relative path to the parent. -- dims On 3/22/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote: > OK. > > If we're going to hold the vote, I'll pull the candidate artifacts. > We can republish them later. > > That does mean that everyone will need to install the sca parent pom > from the tag in SVN before any of the modules in trunk will build. > > -- > Jeremy > > On Mar 22, 2007, at 5:27 PM, Davanum Srinivas wrote: > > > Jeremy, > > > > I'd like to see some progress on the community front! Let's see this > > approach agreed upon and fleshed out a bit more. > > > > thanks, > > dims > > > > On 3/22/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote: > >> On Mar 22, 2007, at 12:31 PM, Simon Laws wrote: > >> > Jeremy. This sounds like a simpler approach than what is there now. > >> > I like > >> > the idea but a question. > >> > > >> > 1) move everything that does not logical depend on > >> > org.apache.tuscany:sca:1.0-incubating to contrib > >> > > >> > from your previous definition do you mean those things that are not > >> > considered to be independent. Or do you mean things that could be > >> > independent but just aren't packaged that way now. I assume that > >> > you mean > >> > the latter as your next point is to go ahead and make them > >> > independent. > >> > >> Yes things aren't really independent due to the intermediate poms in > >> the physical directory tree. > >> > >> > > >> > Also is the global parent version 1.0-incubating or 1.0-incubating- > >> > SNAPSHOT. > >> > I note that now you have it without SNAPSHOT but its children with > >> > SNAPSHOT. > >> > Are you just saying that the global parent doesn't get packaged/ > >> > released > >> > per-se SNAPSHOT or not. > >> > >> This is the pom defined in the tag here: > >>https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/pom/ > >> sca/1.0-incubating > >> > >> which is a stable artifact - one we have voted to release but are > >> waiting for the IPMC to approve. It will not move. > >> > >> [[ BIG NAG TO OUR MENTORS, PLEASE CAN YOU HELP BY VOTING ON THIS > >> THREAD]] > >>http://mail-archives.apache.org/mod_mbox/incubator-general/ > >> 200703.mbox/[EMAIL PROTECTED] > >> > >> The things in trunk are not stable and so have a SNAPSHOT version. > >> -- > >> Jeremy > >> > >> > >> - > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > > > > > > -- > > Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services > > Developers > > > > - > > 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] > > -- Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Build structure - having cake and still eating
Jeremy, Please take a look at axis2 poms and geronimo poms. you don't need to install the parent pom before building modules. you can specify relative path to the parent. -- dims On 3/22/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote: OK. If we're going to hold the vote, I'll pull the candidate artifacts. We can republish them later. That does mean that everyone will need to install the sca parent pom from the tag in SVN before any of the modules in trunk will build. -- Jeremy On Mar 22, 2007, at 5:27 PM, Davanum Srinivas wrote: > Jeremy, > > I'd like to see some progress on the community front! Let's see this > approach agreed upon and fleshed out a bit more. > > thanks, > dims > > On 3/22/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote: >> On Mar 22, 2007, at 12:31 PM, Simon Laws wrote: >> > Jeremy. This sounds like a simpler approach than what is there now. >> > I like >> > the idea but a question. >> > >> > 1) move everything that does not logical depend on >> > org.apache.tuscany:sca:1.0-incubating to contrib >> > >> > from your previous definition do you mean those things that are not >> > considered to be independent. Or do you mean things that could be >> > independent but just aren't packaged that way now. I assume that >> > you mean >> > the latter as your next point is to go ahead and make them >> > independent. >> >> Yes things aren't really independent due to the intermediate poms in >> the physical directory tree. >> >> > >> > Also is the global parent version 1.0-incubating or 1.0-incubating- >> > SNAPSHOT. >> > I note that now you have it without SNAPSHOT but its children with >> > SNAPSHOT. >> > Are you just saying that the global parent doesn't get packaged/ >> > released >> > per-se SNAPSHOT or not. >> >> This is the pom defined in the tag here: >>https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/pom/ >> sca/1.0-incubating >> >> which is a stable artifact - one we have voted to release but are >> waiting for the IPMC to approve. It will not move. >> >> [[ BIG NAG TO OUR MENTORS, PLEASE CAN YOU HELP BY VOTING ON THIS >> THREAD]] >>http://mail-archives.apache.org/mod_mbox/incubator-general/ >> 200703.mbox/[EMAIL PROTECTED] >> >> The things in trunk are not stable and so have a SNAPSHOT version. >> -- >> Jeremy >> >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > > -- > Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services > Developers > > - > 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] -- Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Build structure - having cake and still eating
OK. If we're going to hold the vote, I'll pull the candidate artifacts. We can republish them later. That does mean that everyone will need to install the sca parent pom from the tag in SVN before any of the modules in trunk will build. -- Jeremy On Mar 22, 2007, at 5:27 PM, Davanum Srinivas wrote: Jeremy, I'd like to see some progress on the community front! Let's see this approach agreed upon and fleshed out a bit more. thanks, dims On 3/22/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote: On Mar 22, 2007, at 12:31 PM, Simon Laws wrote: > Jeremy. This sounds like a simpler approach than what is there now. > I like > the idea but a question. > > 1) move everything that does not logical depend on > org.apache.tuscany:sca:1.0-incubating to contrib > > from your previous definition do you mean those things that are not > considered to be independent. Or do you mean things that could be > independent but just aren't packaged that way now. I assume that > you mean > the latter as your next point is to go ahead and make them > independent. Yes things aren't really independent due to the intermediate poms in the physical directory tree. > > Also is the global parent version 1.0-incubating or 1.0-incubating- > SNAPSHOT. > I note that now you have it without SNAPSHOT but its children with > SNAPSHOT. > Are you just saying that the global parent doesn't get packaged/ > released > per-se SNAPSHOT or not. This is the pom defined in the tag here: https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/pom/ sca/1.0-incubating which is a stable artifact - one we have voted to release but are waiting for the IPMC to approve. It will not move. [[ BIG NAG TO OUR MENTORS, PLEASE CAN YOU HELP BY VOTING ON THIS THREAD]] http://mail-archives.apache.org/mod_mbox/incubator-general/ 200703.mbox/[EMAIL PROTECTED] The things in trunk are not stable and so have a SNAPSHOT version. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers - 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]
Re: Build structure - having cake and still eating
Jeremy, I'd like to see some progress on the community front! Let's see this approach agreed upon and fleshed out a bit more. thanks, dims On 3/22/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote: On Mar 22, 2007, at 12:31 PM, Simon Laws wrote: > Jeremy. This sounds like a simpler approach than what is there now. > I like > the idea but a question. > > 1) move everything that does not logical depend on > org.apache.tuscany:sca:1.0-incubating to contrib > > from your previous definition do you mean those things that are not > considered to be independent. Or do you mean things that could be > independent but just aren't packaged that way now. I assume that > you mean > the latter as your next point is to go ahead and make them > independent. Yes things aren't really independent due to the intermediate poms in the physical directory tree. > > Also is the global parent version 1.0-incubating or 1.0-incubating- > SNAPSHOT. > I note that now you have it without SNAPSHOT but its children with > SNAPSHOT. > Are you just saying that the global parent doesn't get packaged/ > released > per-se SNAPSHOT or not. This is the pom defined in the tag here: https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/pom/ sca/1.0-incubating which is a stable artifact - one we have voted to release but are waiting for the IPMC to approve. It will not move. [[ BIG NAG TO OUR MENTORS, PLEASE CAN YOU HELP BY VOTING ON THIS THREAD]] http://mail-archives.apache.org/mod_mbox/incubator-general/ 200703.mbox/[EMAIL PROTECTED] The things in trunk are not stable and so have a SNAPSHOT version. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Build structure - having cake and still eating
This seems good +1. Jim On Mar 22, 2007, at 10:21 AM, Raymond Feng wrote: +1. I think it's in line with the proposal in my response to Meeraj. One question: For a bundle to reference a module in the Tuscany source tree, do we really have to copy (or use svn:externals property) if it points to a location (under trunk, tags, or branches) in the Tuscany tree? I think a relative path for the will work. Thanks, Raymond - Original Message - From: "Jeremy Boynes" <[EMAIL PROTECTED]> To: Sent: Thursday, March 22, 2007 10:10 AM Subject: Build structure - having cake and still eating We know from M2 experience and the number of "profiles" in the integration branch that a top-down, build-everything approach does not work. We also know from practical experience that people struggle building modules. I believe there is a middle ground that supports both approaches; * have a flat module structure that allows any module to be built on its own using dependencies from the mvn repos * have particular assemblies that pull modules together into whatever bundles people want. The assemblies can use released modules from mvn, snapshot modules from mvn, a copy of any revision of that module, or can track trunk using svn externals An example of this is the assembly I used for the tag for the TSSS demo code which uses a combination of released artifacts and known revisions. This gives module developers their own space to work in, and allows people consuming those modules to choose how stable the code they want to use is (from released through to head). Hopefully this will provide a middle ground we are all comfortable with. -- Jeremy - 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]
Re: Build structure - having cake and still eating
On 3/22/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote: On Mar 22, 2007, at 12:31 PM, Simon Laws wrote: > Jeremy. This sounds like a simpler approach than what is there now. > I like > the idea but a question. > > 1) move everything that does not logical depend on > org.apache.tuscany:sca:1.0-incubating to contrib > > from your previous definition do you mean those things that are not > considered to be independent. Or do you mean things that could be > independent but just aren't packaged that way now. I assume that > you mean > the latter as your next point is to go ahead and make them > independent. Yes things aren't really independent due to the intermediate poms in the physical directory tree. > > Also is the global parent version 1.0-incubating or 1.0-incubating- > SNAPSHOT. > I note that now you have it without SNAPSHOT but its children with > SNAPSHOT. > Are you just saying that the global parent doesn't get packaged/ > released > per-se SNAPSHOT or not. This is the pom defined in the tag here: https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/pom/ sca/1.0-incubating which is a stable artifact - one we have voted to release but are waiting for the IPMC to approve. It will not move. [[ BIG NAG TO OUR MENTORS, PLEASE CAN YOU HELP BY VOTING ON THIS THREAD]] http://mail-archives.apache.org/mod_mbox/incubator-general/ 200703.mbox/[EMAIL PROTECTED] The things in trunk are not stable and so have a SNAPSHOT version. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Ok, I get it. Thanks Jemery. S
Re: Build structure - having cake and still eating
On Mar 22, 2007, at 12:31 PM, Simon Laws wrote: Jeremy. This sounds like a simpler approach than what is there now. I like the idea but a question. 1) move everything that does not logical depend on org.apache.tuscany:sca:1.0-incubating to contrib from your previous definition do you mean those things that are not considered to be independent. Or do you mean things that could be independent but just aren't packaged that way now. I assume that you mean the latter as your next point is to go ahead and make them independent. Yes things aren't really independent due to the intermediate poms in the physical directory tree. Also is the global parent version 1.0-incubating or 1.0-incubating- SNAPSHOT. I note that now you have it without SNAPSHOT but its children with SNAPSHOT. Are you just saying that the global parent doesn't get packaged/ released per-se SNAPSHOT or not. This is the pom defined in the tag here: https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/pom/ sca/1.0-incubating which is a stable artifact - one we have voted to release but are waiting for the IPMC to approve. It will not move. [[ BIG NAG TO OUR MENTORS, PLEASE CAN YOU HELP BY VOTING ON THIS THREAD]] http://mail-archives.apache.org/mod_mbox/incubator-general/ 200703.mbox/[EMAIL PROTECTED] The things in trunk are not stable and so have a SNAPSHOT version. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Build structure - having cake and still eating
On 3/22/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote: On Mar 22, 2007, at 11:19 AM, Simon Laws wrote: > > When you talk about flattening the module hierarchy do you mean this > literally in svn (which I like the sound of as I can never find > anything in > all the nested dirs - my inexperience showing) or is this some virtual > flattening? > Not a at all. We can do either or both ... The logical/virtual tree here is the structure in the pom. Maven projects can inherit project definitions (stuff like dependencies, repo locations, plugins to use) from another project by specifying it in their element - this can be used to avoid repetition of stuff like dependency versions, plugin configurations and so on. This is actually independent of the physical directory structure, although often the pom in one directory is used as the parent for that it builds. This is actually conflating physical structure and logical structure together and although it seemed like a good idea at the time I don't think that it is working any more. I think we should first flatten the logical hierarchy so that all independent module groups inherit from a global parent. This would be org.apache.tuscany:sca:1.0-incubating. By "independent" I mean things that could be released independently - these could be groups of tightly coupled modules (such the current "kernel" or "runtime") or individual modules such as "http.jetty" I started on this for the modules that were part of 2.0-alpha but have not done it yet for the modules in extensions or services that were not. I think we should do this now for the others - I'll make a start on the ones used in the demo. An orthogonal issue is how we lay out the physical directory tree. It is probably simpler to get rid of midlevel parents like "extensions" and "services" all together and just have a flat structure under "sca" - I think that would help make things easier to find. We started doing that with a gradual migration of stuff from "services" to "extensions" but I think doing this gradually has probably just added to the confusion. I'd suggest we give up on the gradual approach and move everything under "contrib" until we can fix the logical structure as above. To summarize: 1) move everything that does not logical depend on org.apache.tuscany:sca:1.0-incubating to contrib 2) update each module or group in contrib to be logically independent 3) once the module is independent move it to the flat structure under sca so it is easy to find I'm going to get started with the modules used in the demo. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Jeremy. This sounds like a simpler approach than what is there now. I like the idea but a question. 1) move everything that does not logical depend on org.apache.tuscany:sca:1.0-incubating to contrib from your previous definition do you mean those things that are not considered to be independent. Or do you mean things that could be independent but just aren't packaged that way now. I assume that you mean the latter as your next point is to go ahead and make them independent. Also is the global parent version 1.0-incubating or 1.0-incubating-SNAPSHOT. I note that now you have it without SNAPSHOT but its children with SNAPSHOT. Are you just saying that the global parent doesn't get packaged/released per-se SNAPSHOT or not. S
Re: Build structure - having cake and still eating
On Mar 22, 2007, at 11:19 AM, Simon Laws wrote: When you talk about flattening the module hierarchy do you mean this literally in svn (which I like the sound of as I can never find anything in all the nested dirs - my inexperience showing) or is this some virtual flattening? Not a at all. We can do either or both ... The logical/virtual tree here is the structure in the pom. Maven projects can inherit project definitions (stuff like dependencies, repo locations, plugins to use) from another project by specifying it in their element - this can be used to avoid repetition of stuff like dependency versions, plugin configurations and so on. This is actually independent of the physical directory structure, although often the pom in one directory is used as the parent for that it builds. This is actually conflating physical structure and logical structure together and although it seemed like a good idea at the time I don't think that it is working any more. I think we should first flatten the logical hierarchy so that all independent module groups inherit from a global parent. This would be org.apache.tuscany:sca:1.0-incubating. By "independent" I mean things that could be released independently - these could be groups of tightly coupled modules (such the current "kernel" or "runtime") or individual modules such as "http.jetty" I started on this for the modules that were part of 2.0-alpha but have not done it yet for the modules in extensions or services that were not. I think we should do this now for the others - I'll make a start on the ones used in the demo. An orthogonal issue is how we lay out the physical directory tree. It is probably simpler to get rid of midlevel parents like "extensions" and "services" all together and just have a flat structure under "sca" - I think that would help make things easier to find. We started doing that with a gradual migration of stuff from "services" to "extensions" but I think doing this gradually has probably just added to the confusion. I'd suggest we give up on the gradual approach and move everything under "contrib" until we can fix the logical structure as above. To summarize: 1) move everything that does not logical depend on org.apache.tuscany:sca:1.0-incubating to contrib 2) update each module or group in contrib to be logically independent 3) once the module is independent move it to the flat structure under sca so it is easy to find I'm going to get started with the modules used in the demo. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Build structure - having cake and still eating
The svn:externals property seems to be very powerful since it can link to different revisions for sources from different SVN locations. This way, we can reference a particular revision in some cases. http://svnbook.red-bean.com/en/1.0/ch07s03.html Thanks, Raymond - Original Message - From: "Jeremy Boynes" <[EMAIL PROTECTED]> To: Sent: Thursday, March 22, 2007 10:34 AM Subject: Re: Build structure - having cake and still eating On Mar 22, 2007, at 10:21 AM, Raymond Feng wrote: +1. I think it's in line with the proposal in my response to Meeraj. One question: For a bundle to reference a module in the Tuscany source tree, do we really have to copy (or use svn:externals property) if it points to a location (under trunk, tags, or branches) in the Tuscany tree? I think a relative path for the will work. It will. The difference would be that with a ../.. type relative path someone can't just check out the assembly module, they need to check out the whole tree from some common root. With an external they could just check out the assembly module and the source for the dependency would be checked out as well. Of course, then they might have multiple copies of the dependency source to manage. Either works and it would up to the users of the assembly module to choose which style they prefer. -- Jeremy - 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]
Re: Build structure - having cake and still eating
On 3/22/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote: On Mar 22, 2007, at 10:21 AM, Raymond Feng wrote: > +1. > > I think it's in line with the proposal in my response to Meeraj. > > One question: For a bundle to reference a module in the Tuscany > source tree, do we really have to copy (or use svn:externals > property) if it points to a location (under trunk, tags, or > branches) in the Tuscany tree? I think a relative path for the > will work. It will. The difference would be that with a ../.. type relative path someone can't just check out the assembly module, they need to check out the whole tree from some common root. With an external they could just check out the assembly module and the source for the dependency would be checked out as well. Of course, then they might have multiple copies of the dependency source to manage. Either works and it would up to the users of the assembly module to choose which style they prefer. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Sounds like a good compromise to me When you talk about flattening the module hierarchy do you mean this literally in svn (which I like the sound of as I can never find anything in all the nested dirs - my inexperience showing) or is this some virtual flattening? Simon
Re: Build structure - having cake and still eating
On Mar 22, 2007, at 10:21 AM, Raymond Feng wrote: +1. I think it's in line with the proposal in my response to Meeraj. One question: For a bundle to reference a module in the Tuscany source tree, do we really have to copy (or use svn:externals property) if it points to a location (under trunk, tags, or branches) in the Tuscany tree? I think a relative path for the will work. It will. The difference would be that with a ../.. type relative path someone can't just check out the assembly module, they need to check out the whole tree from some common root. With an external they could just check out the assembly module and the source for the dependency would be checked out as well. Of course, then they might have multiple copies of the dependency source to manage. Either works and it would up to the users of the assembly module to choose which style they prefer. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Build structure - having cake and still eating
+1. I think it's in line with the proposal in my response to Meeraj. One question: For a bundle to reference a module in the Tuscany source tree, do we really have to copy (or use svn:externals property) if it points to a location (under trunk, tags, or branches) in the Tuscany tree? I think a relative path for the will work. Thanks, Raymond - Original Message - From: "Jeremy Boynes" <[EMAIL PROTECTED]> To: Sent: Thursday, March 22, 2007 10:10 AM Subject: Build structure - having cake and still eating We know from M2 experience and the number of "profiles" in the integration branch that a top-down, build-everything approach does not work. We also know from practical experience that people struggle building modules. I believe there is a middle ground that supports both approaches; * have a flat module structure that allows any module to be built on its own using dependencies from the mvn repos * have particular assemblies that pull modules together into whatever bundles people want. The assemblies can use released modules from mvn, snapshot modules from mvn, a copy of any revision of that module, or can track trunk using svn externals An example of this is the assembly I used for the tag for the TSSS demo code which uses a combination of released artifacts and known revisions. This gives module developers their own space to work in, and allows people consuming those modules to choose how stable the code they want to use is (from released through to head). Hopefully this will provide a middle ground we are all comfortable with. -- Jeremy - 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]
