Re: contents of a 1.1 release
Next week, I'll start implementation of UI tests for all screens. Emmanuel Jason van Zyl a écrit : On 17 Oct 06, at 2:34 PM 17 Oct 06, Brett Porter wrote: I agree with Emmanuel. IIRC, the profiles are already in the model, and basic choice of which JDK and maven/ant installation to use should be straightforward and extremely useful. I agree that making it more pervasive and using the toolchain support would be even better, but I don't believe it needs to wait for that. I would be against any more radical changes until the testing setup is rock solid. We're slipping in this area. We don't really know what machines this stuff runs on and I don't think anything is automated anymore. We need to stop paying lip service to what we are preaching. Jason. - Brett On 18/10/2006, at 12:54 AM, Emmanuel Venisse wrote: The introduction of continuum profiles isn't impacted by the DefaultContinuum refactoring. If we don't provide a full continuum profiles implementation in 1.1, I think we can do a minimal one with only the possibility to choose the maven1/maven2/ant/java home directories and use them instead of using maven/ant/mvn/java from the PATH. This feature isn't big to do. In 1.1, I'd like to see the possibility to choose in build definitions if a project is built with an update (like it's done actually) or with a clean checkout. The last point, I'd like to see in 1.1 is the dependency/parent change build-trigger. All these features are awaited by users since a long time. I don't think the implementation will take lot of time, so they can be add in 1.1. Of course, we need a database migration tool for the release too. Emmanuel Jesse McConnell a écrit : I was going to try and wrap my head about what needed to get wrapped up for a 1.1 release of continuum this week when I got to talking to emmanuel this morning. I had been under the impression that we were getting near a point that we might want to polish things up and cut a 1.1 release but emm was thinking that we ought to have another big push for new features before we start polishing things up. So I told him I would mention our talk and see what kinda interest we got from people on new features and who might want to tackle what in the short term, or if we wanted to put some things out into the longer term bin. One of the major things that I had been thinking we would push off to the 1.2 release was the profiles. Its a slightly overridden term as it has little to do with maven profiles, but in my mind at least the profiles were going to be 1/3 of a trinity by which builds could be setup to run. The trinity being: profile (maven instance, env vars, maven profiles, jdk instance, etc), temporal ( scheduled cron, when dependency changes, scm activity, etc) and the project group (bundle of projects). I was figuring that those three things taken together ought meet the requirements for building what, where and when. It would be a matter of setting up the permutations of those three components, for example: 2 profiles, 1 schedule, 1 project group would make 2 instances of schedulable FOO. Anyway, I digress...profiles would be one large feature that would be wonderful to have in continuum, sooner the better. But it would be pretty massive effects on the codebase. So massive that I would think we ought to consider splitting up the DefaultContinuum object into the workflows that have been kicked around, making things like 'Add Project To Project Group' extensible by users so they can trigger any other processes they might want running on those events. Trygve has some definite ideas in this area, perhaps using the plexus-spe code. The actions in continuum have been a first pass attempt at starting to break things out of the DC object which is pretty big atm. If we were going to rip the top off of the DefaultContinuum object and add/modify in the profile concepts into the store then we really ought to clean up the whole store api which is more painful to work with then it really should be. joakim and I had a lot of success with structuring things nicely in the plexus-security jdo stores and we could probably apply a ton of the concepts there in terms of api to the continuum-store and make it scads easier to work with. and on and on. I agree with Emmanuel that since 1.1 as it currently stands is not backwards compatible (I think) with the old database we ought to just add in what we need now...But doing this will definitely move out a 1.1 release into the new year...and is that something we want to do? I dunno really, personally I would be cool with adding in profiles and refactoring the core chunks of continuum up now and get it over with, but does anyone else have anything to say on the matter? I know we have had a lot more interest recently by folks like rahul and christian on participating, would you guys be interested in taking on some of these challenges with us? Theres nothing like ripping through the guts of code
Re: contents of a 1.1 release
Just curious, what kind of web test framework are you going to use? -D On 10/18/06, Emmanuel Venisse [EMAIL PROTECTED] wrote: Next week, I'll start implementation of UI tests for all screens. Emmanuel Jason van Zyl a écrit : On 17 Oct 06, at 2:34 PM 17 Oct 06, Brett Porter wrote: I agree with Emmanuel. IIRC, the profiles are already in the model, and basic choice of which JDK and maven/ant installation to use should be straightforward and extremely useful. I agree that making it more pervasive and using the toolchain support would be even better, but I don't believe it needs to wait for that. I would be against any more radical changes until the testing setup is rock solid. We're slipping in this area. We don't really know what machines this stuff runs on and I don't think anything is automated anymore. We need to stop paying lip service to what we are preaching. Jason. - Brett On 18/10/2006, at 12:54 AM, Emmanuel Venisse wrote: The introduction of continuum profiles isn't impacted by the DefaultContinuum refactoring. If we don't provide a full continuum profiles implementation in 1.1, I think we can do a minimal one with only the possibility to choose the maven1/maven2/ant/java home directories and use them instead of using maven/ant/mvn/java from the PATH. This feature isn't big to do. In 1.1, I'd like to see the possibility to choose in build definitions if a project is built with an update (like it's done actually) or with a clean checkout. The last point, I'd like to see in 1.1 is the dependency/parent change build-trigger. All these features are awaited by users since a long time. I don't think the implementation will take lot of time, so they can be add in 1.1. Of course, we need a database migration tool for the release too. Emmanuel Jesse McConnell a écrit : I was going to try and wrap my head about what needed to get wrapped up for a 1.1 release of continuum this week when I got to talking to emmanuel this morning. I had been under the impression that we were getting near a point that we might want to polish things up and cut a 1.1 release but emm was thinking that we ought to have another big push for new features before we start polishing things up. So I told him I would mention our talk and see what kinda interest we got from people on new features and who might want to tackle what in the short term, or if we wanted to put some things out into the longer term bin. One of the major things that I had been thinking we would push off to the 1.2 release was the profiles. Its a slightly overridden term as it has little to do with maven profiles, but in my mind at least the profiles were going to be 1/3 of a trinity by which builds could be setup to run. The trinity being: profile (maven instance, env vars, maven profiles, jdk instance, etc), temporal ( scheduled cron, when dependency changes, scm activity, etc) and the project group (bundle of projects). I was figuring that those three things taken together ought meet the requirements for building what, where and when. It would be a matter of setting up the permutations of those three components, for example: 2 profiles, 1 schedule, 1 project group would make 2 instances of schedulable FOO. Anyway, I digress...profiles would be one large feature that would be wonderful to have in continuum, sooner the better. But it would be pretty massive effects on the codebase. So massive that I would think we ought to consider splitting up the DefaultContinuum object into the workflows that have been kicked around, making things like 'Add Project To Project Group' extensible by users so they can trigger any other processes they might want running on those events. Trygve has some definite ideas in this area, perhaps using the plexus-spe code. The actions in continuum have been a first pass attempt at starting to break things out of the DC object which is pretty big atm. If we were going to rip the top off of the DefaultContinuum object and add/modify in the profile concepts into the store then we really ought to clean up the whole store api which is more painful to work with then it really should be. joakim and I had a lot of success with structuring things nicely in the plexus-security jdo stores and we could probably apply a ton of the concepts there in terms of api to the continuum-store and make it scads easier to work with. and on and on. I agree with Emmanuel that since 1.1 as it currently stands is not backwards compatible (I think) with the old database we ought to just add in what we need now...But doing this will definitely move out a 1.1 release into the new year...and is that something we want to do? I dunno really, personally I would be cool with adding in profiles and refactoring the core chunks of continuum up now and get it over with, but does anyone else have anything to say on the matter? I know we have had a lot more interest recently
Re: contents of a 1.1 release
On 17 Oct 06, at 2:34 PM 17 Oct 06, Brett Porter wrote: I agree with Emmanuel. IIRC, the profiles are already in the model, and basic choice of which JDK and maven/ant installation to use should be straightforward and extremely useful. I agree that making it more pervasive and using the toolchain support would be even better, but I don't believe it needs to wait for that. I would be against any more radical changes until the testing setup is rock solid. We're slipping in this area. We don't really know what machines this stuff runs on and I don't think anything is automated anymore. We need to stop paying lip service to what we are preaching. Jason. - Brett On 18/10/2006, at 12:54 AM, Emmanuel Venisse wrote: The introduction of continuum profiles isn't impacted by the DefaultContinuum refactoring. If we don't provide a full continuum profiles implementation in 1.1, I think we can do a minimal one with only the possibility to choose the maven1/maven2/ant/java home directories and use them instead of using maven/ant/mvn/java from the PATH. This feature isn't big to do. In 1.1, I'd like to see the possibility to choose in build definitions if a project is built with an update (like it's done actually) or with a clean checkout. The last point, I'd like to see in 1.1 is the dependency/parent change build-trigger. All these features are awaited by users since a long time. I don't think the implementation will take lot of time, so they can be add in 1.1. Of course, we need a database migration tool for the release too. Emmanuel Jesse McConnell a écrit : I was going to try and wrap my head about what needed to get wrapped up for a 1.1 release of continuum this week when I got to talking to emmanuel this morning. I had been under the impression that we were getting near a point that we might want to polish things up and cut a 1.1 release but emm was thinking that we ought to have another big push for new features before we start polishing things up. So I told him I would mention our talk and see what kinda interest we got from people on new features and who might want to tackle what in the short term, or if we wanted to put some things out into the longer term bin. One of the major things that I had been thinking we would push off to the 1.2 release was the profiles. Its a slightly overridden term as it has little to do with maven profiles, but in my mind at least the profiles were going to be 1/3 of a trinity by which builds could be setup to run. The trinity being: profile (maven instance, env vars, maven profiles, jdk instance, etc), temporal ( scheduled cron, when dependency changes, scm activity, etc) and the project group (bundle of projects). I was figuring that those three things taken together ought meet the requirements for building what, where and when. It would be a matter of setting up the permutations of those three components, for example: 2 profiles, 1 schedule, 1 project group would make 2 instances of schedulable FOO. Anyway, I digress...profiles would be one large feature that would be wonderful to have in continuum, sooner the better. But it would be pretty massive effects on the codebase. So massive that I would think we ought to consider splitting up the DefaultContinuum object into the workflows that have been kicked around, making things like 'Add Project To Project Group' extensible by users so they can trigger any other processes they might want running on those events. Trygve has some definite ideas in this area, perhaps using the plexus-spe code. The actions in continuum have been a first pass attempt at starting to break things out of the DC object which is pretty big atm. If we were going to rip the top off of the DefaultContinuum object and add/modify in the profile concepts into the store then we really ought to clean up the whole store api which is more painful to work with then it really should be. joakim and I had a lot of success with structuring things nicely in the plexus-security jdo stores and we could probably apply a ton of the concepts there in terms of api to the continuum-store and make it scads easier to work with. and on and on. I agree with Emmanuel that since 1.1 as it currently stands is not backwards compatible (I think) with the old database we ought to just add in what we need now...But doing this will definitely move out a 1.1 release into the new year...and is that something we want to do? I dunno really, personally I would be cool with adding in profiles and refactoring the core chunks of continuum up now and get it over with, but does anyone else have anything to say on the matter? I know we have had a lot more interest recently by folks like rahul and christian on participating, would you guys be interested in taking on some of these challenges with us? Theres nothing like ripping through the guts of code to really get involved :) thoughts?
Re: contents of a 1.1 release
well, I am working on finishing up some lingering project group functionality now, but once I knock it off my list I'll work on the testing some. I'll need to get up to speed on the latest integration testing work you have been working on jason, and emm mentioned on irc a while back that he was going to take a stab at bringing the web testing back on line so I'll ping him and work with him on that... also, its looks like there is a bit of a split on where to go release wise atm, but I think we can all generally acknowledge that the tests need to get improved, at the very least getting the web testing back where it was before the ui refactor to webwork. Perhaps we should shoot for a feature freeze of sorts for the middle of november and check where we are for a 1.1 release around that time. A month should be more then enough time to get the test case positions recovered to an acceptable lvl and get a mess of the outstanding issues resolved/lacking features fixed up. jesse On 10/17/06, Jason van Zyl [EMAIL PROTECTED] wrote: On 17 Oct 06, at 2:34 PM 17 Oct 06, Brett Porter wrote: I agree with Emmanuel. IIRC, the profiles are already in the model, and basic choice of which JDK and maven/ant installation to use should be straightforward and extremely useful. I agree that making it more pervasive and using the toolchain support would be even better, but I don't believe it needs to wait for that. I would be against any more radical changes until the testing setup is rock solid. We're slipping in this area. We don't really know what machines this stuff runs on and I don't think anything is automated anymore. We need to stop paying lip service to what we are preaching. Jason. - Brett On 18/10/2006, at 12:54 AM, Emmanuel Venisse wrote: The introduction of continuum profiles isn't impacted by the DefaultContinuum refactoring. If we don't provide a full continuum profiles implementation in 1.1, I think we can do a minimal one with only the possibility to choose the maven1/maven2/ant/java home directories and use them instead of using maven/ant/mvn/java from the PATH. This feature isn't big to do. In 1.1, I'd like to see the possibility to choose in build definitions if a project is built with an update (like it's done actually) or with a clean checkout. The last point, I'd like to see in 1.1 is the dependency/parent change build-trigger. All these features are awaited by users since a long time. I don't think the implementation will take lot of time, so they can be add in 1.1. Of course, we need a database migration tool for the release too. Emmanuel Jesse McConnell a écrit : I was going to try and wrap my head about what needed to get wrapped up for a 1.1 release of continuum this week when I got to talking to emmanuel this morning. I had been under the impression that we were getting near a point that we might want to polish things up and cut a 1.1 release but emm was thinking that we ought to have another big push for new features before we start polishing things up. So I told him I would mention our talk and see what kinda interest we got from people on new features and who might want to tackle what in the short term, or if we wanted to put some things out into the longer term bin. One of the major things that I had been thinking we would push off to the 1.2 release was the profiles. Its a slightly overridden term as it has little to do with maven profiles, but in my mind at least the profiles were going to be 1/3 of a trinity by which builds could be setup to run. The trinity being: profile (maven instance, env vars, maven profiles, jdk instance, etc), temporal ( scheduled cron, when dependency changes, scm activity, etc) and the project group (bundle of projects). I was figuring that those three things taken together ought meet the requirements for building what, where and when. It would be a matter of setting up the permutations of those three components, for example: 2 profiles, 1 schedule, 1 project group would make 2 instances of schedulable FOO. Anyway, I digress...profiles would be one large feature that would be wonderful to have in continuum, sooner the better. But it would be pretty massive effects on the codebase. So massive that I would think we ought to consider splitting up the DefaultContinuum object into the workflows that have been kicked around, making things like 'Add Project To Project Group' extensible by users so they can trigger any other processes they might want running on those events. Trygve has some definite ideas in this area, perhaps using the plexus-spe code. The actions in continuum have been a first pass attempt at starting to break things out of the DC object which is pretty big atm. If we were going to rip the top off of the DefaultContinuum object and add/modify in the profile concepts into the store then we really ought to clean up the whole store api which is more painful
Re: contents of a 1.1 release
On 17 Oct 06, at 6:15 PM 17 Oct 06, Jesse McConnell wrote: well, I am working on finishing up some lingering project group functionality now, but once I knock it off my list I'll work on the testing some. I'll need to get up to speed on the latest integration testing work you have been working on jason, and emm mentioned on irc a while back that he was going to take a stab at bringing the web testing back on line so I'll ping him and work with him on that... I think the path of separating out ITs into a separate project is the way to go. So they are a separate project and become the gold standard. Many versions of Maven can be run against the Maven ITs, and the same would be useful for Continuum. also, its looks like there is a bit of a split on where to go release wise atm, but I think we can all generally acknowledge that the tests need to get improved, at the very least getting the web testing back where it was before the ui refactor to webwork. Perhaps we should shoot for a feature freeze of sorts for the middle of november and check where we are for a 1.1 release around that time. A month should be more then enough time to get the test case positions recovered to an acceptable lvl and get a mess of the outstanding issues resolved/lacking features fixed up. If the test are heading in the right direction that's cool and in a month they should be healthy as that's a good chunk of time. But the automated testing is key. Jason. jesse On 10/17/06, Jason van Zyl [EMAIL PROTECTED] wrote: On 17 Oct 06, at 2:34 PM 17 Oct 06, Brett Porter wrote: I agree with Emmanuel. IIRC, the profiles are already in the model, and basic choice of which JDK and maven/ant installation to use should be straightforward and extremely useful. I agree that making it more pervasive and using the toolchain support would be even better, but I don't believe it needs to wait for that. I would be against any more radical changes until the testing setup is rock solid. We're slipping in this area. We don't really know what machines this stuff runs on and I don't think anything is automated anymore. We need to stop paying lip service to what we are preaching. Jason. - Brett On 18/10/2006, at 12:54 AM, Emmanuel Venisse wrote: The introduction of continuum profiles isn't impacted by the DefaultContinuum refactoring. If we don't provide a full continuum profiles implementation in 1.1, I think we can do a minimal one with only the possibility to choose the maven1/maven2/ant/java home directories and use them instead of using maven/ant/mvn/java from the PATH. This feature isn't big to do. In 1.1, I'd like to see the possibility to choose in build definitions if a project is built with an update (like it's done actually) or with a clean checkout. The last point, I'd like to see in 1.1 is the dependency/parent change build-trigger. All these features are awaited by users since a long time. I don't think the implementation will take lot of time, so they can be add in 1.1. Of course, we need a database migration tool for the release too. Emmanuel Jesse McConnell a écrit : I was going to try and wrap my head about what needed to get wrapped up for a 1.1 release of continuum this week when I got to talking to emmanuel this morning. I had been under the impression that we were getting near a point that we might want to polish things up and cut a 1.1 release but emm was thinking that we ought to have another big push for new features before we start polishing things up. So I told him I would mention our talk and see what kinda interest we got from people on new features and who might want to tackle what in the short term, or if we wanted to put some things out into the longer term bin. One of the major things that I had been thinking we would push off to the 1.2 release was the profiles. Its a slightly overridden term as it has little to do with maven profiles, but in my mind at least the profiles were going to be 1/3 of a trinity by which builds could be setup to run. The trinity being: profile (maven instance, env vars, maven profiles, jdk instance, etc), temporal ( scheduled cron, when dependency changes, scm activity, etc) and the project group (bundle of projects). I was figuring that those three things taken together ought meet the requirements for building what, where and when. It would be a matter of setting up the permutations of those three components, for example: 2 profiles, 1 schedule, 1 project group would make 2 instances of schedulable FOO. Anyway, I digress...profiles would be one large feature that would be wonderful to have in continuum, sooner the better. But it would be pretty massive effects on the codebase. So massive that I would think we ought to consider splitting up the DefaultContinuum object into the workflows that have been kicked around, making things like 'Add Project To Project Group'
Re: contents of a 1.1 release
Actually, To Emannuel's point about building with clean checkout or update, I'm working on such a thing, and should have a patch this weekend. It'll also include the per-group/per-project/per-build-def working directories, per my conversation with Kenney, and the do you force a build on change, or always build key. Note: some of these options are mutually exclusive, but they're all related. Christian. Brett Porter wrote: I agree with Emmanuel. IIRC, the profiles are already in the model, and basic choice of which JDK and maven/ant installation to use should be straightforward and extremely useful. I agree that making it more pervasive and using the toolchain support would be even better, but I don't believe it needs to wait for that. - Brett On 18/10/2006, at 12:54 AM, Emmanuel Venisse wrote: The introduction of continuum profiles isn't impacted by the DefaultContinuum refactoring. If we don't provide a full continuum profiles implementation in 1.1, I think we can do a minimal one with only the possibility to choose the maven1/maven2/ant/java home directories and use them instead of using maven/ant/mvn/java from the PATH. This feature isn't big to do. In 1.1, I'd like to see the possibility to choose in build definitions if a project is built with an update (like it's done actually) or with a clean checkout. The last point, I'd like to see in 1.1 is the dependency/parent change build-trigger. All these features are awaited by users since a long time. I don't think the implementation will take lot of time, so they can be add in 1.1. Of course, we need a database migration tool for the release too. Emmanuel Jesse McConnell a écrit : I was going to try and wrap my head about what needed to get wrapped up for a 1.1 release of continuum this week when I got to talking to emmanuel this morning. I had been under the impression that we were getting near a point that we might want to polish things up and cut a 1.1 release but emm was thinking that we ought to have another big push for new features before we start polishing things up. So I told him I would mention our talk and see what kinda interest we got from people on new features and who might want to tackle what in the short term, or if we wanted to put some things out into the longer term bin. One of the major things that I had been thinking we would push off to the 1.2 release was the profiles. Its a slightly overridden term as it has little to do with maven profiles, but in my mind at least the profiles were going to be 1/3 of a trinity by which builds could be setup to run. The trinity being: profile (maven instance, env vars, maven profiles, jdk instance, etc), temporal ( scheduled cron, when dependency changes, scm activity, etc) and the project group (bundle of projects). I was figuring that those three things taken together ought meet the requirements for building what, where and when. It would be a matter of setting up the permutations of those three components, for example: 2 profiles, 1 schedule, 1 project group would make 2 instances of schedulable FOO. Anyway, I digress...profiles would be one large feature that would be wonderful to have in continuum, sooner the better. But it would be pretty massive effects on the codebase. So massive that I would think we ought to consider splitting up the DefaultContinuum object into the workflows that have been kicked around, making things like 'Add Project To Project Group' extensible by users so they can trigger any other processes they might want running on those events. Trygve has some definite ideas in this area, perhaps using the plexus-spe code. The actions in continuum have been a first pass attempt at starting to break things out of the DC object which is pretty big atm. If we were going to rip the top off of the DefaultContinuum object and add/modify in the profile concepts into the store then we really ought to clean up the whole store api which is more painful to work with then it really should be. joakim and I had a lot of success with structuring things nicely in the plexus-security jdo stores and we could probably apply a ton of the concepts there in terms of api to the continuum-store and make it scads easier to work with. and on and on. I agree with Emmanuel that since 1.1 as it currently stands is not backwards compatible (I think) with the old database we ought to just add in what we need now...But doing this will definitely move out a 1.1 release into the new year...and is that something we want to do? I dunno really, personally I would be cool with adding in profiles and refactoring the core chunks of continuum up now and get it over with, but does anyone else have anything to say on the matter? I know we have had a lot more interest recently by folks like rahul and christian on participating, would you guys be interested in taking on some of these challenges with us? Theres nothing like
