Re: Re: Maven2 Conversation Status
Changing to use http instead of https fixes... But something recently changed at the haus. anonymous svn acces on the haus is limited to http now. -chris
Re: Maven2 Conversation Status
Jason Dillon wrote: On Jul 20, 2006, at 10:02 PM, John Sisson wrote: It built successfully for me in cygwin (first attempt failed in timer tests). I'll try to do some tests on the weekend. Timer tests are known to fail on slower or more resource constrained systems. All of the failures should be expected '20' found (something less than 20). The tests need to be redesigned to work in all environments regardless of cpu/resource availability. I agree with Jeff's comments that we should have this pass the TCK before it is merged back to trunk. I find it very hard to believe that we are going to spend time to setup the TCK to run on sandbox/svkmerge/m2migration. How does this differ from what you are doing today with the G codebase? We will get the TCK to run, but we should do so from trunk. It will happen very soon after the merge is complete. It is not like we are going to drop this work once the merge has been done. I'd appreciate a little flexibility here, else it just wastes our time. --jason
Re: Maven2 Conversation Status
On Jul 21, 2006, at 3:20 AM, Jeff Genender wrote: I find it very hard to believe that we are going to spend time to setup the TCK to run on sandbox/svkmerge/m2migration. How does this differ from what you are doing today with the G codebase? Sorry, I do not understand what you are asking. * * * My understanding is that to get the TCK bits working and automated in GBuild that we need to have a CI process that is publishing artifacts and I do not believe that we want to spend time to setup that process on this sandbox branch. I believe that we want to do this for trunk. In fact we need to do that to get the OpenEJB2 build automated, which is also required to get the G build automated. I believe that setting this up for my m2migration branch would be an intermediate step that benefits us very little and overall just slows down the progress of getting the TCK up and running for the long run using m2. If you mean to have me (or someone) run the TCK locally I'm not sure that will fly either as I certainly don't have cycles on my laptop to run the TCK for however many days it takes for the thing to run, nor do I have the expertise at this moment to know how to fix it if it breaks on something. IIUC there is significant configuration involved to get everything up and running, and significant time to actually run, therefor we could easily burn a week or more to perform the intermediate setup and then have to reburn that time to do it again. The best option to get the TCK up and running fastest and in a permanent state of continuous integration is to merge the work to the trunk and then setup GBuild to use trunk to run tests against. Its like we have just performed some major renovations on your house and need the inspector to come and make sure that everything is up to code... well, the inspector is not going to demand that the renovations be applied to a mock house build out in your backyard first before allowing them to be applied to your house proper. --jason
Re: Maven2 Conversation Status
On Jul 21, 2006, at 8:15 AM, Matt Hogstrom wrote: Based on this note and the others it sounds like the build is working and that you are suggesting a temporary blackout period when the migration is completed. During the migration period the Maven 1 build will no longer work so we will effectively halt any development in trunk. Not exactly. The m1 build will still function, just it is not preferred... and use would be discouraged. Soon afterwards once we have the TCK up and everyone is happy (or happy enough) then the m1 build will be removed. Development on trunk using m1 _should_ halt... and be replaced by development using m2... but by no means will the migration force anyone to halt for the initial steps. Based on the commit log it doesn't really look like there is much going on now anyway so its probably not a huge issue. Looks like some folks have left trunk for branches or the sandbox which is unfortunate. There is almost nothing going on in trunk right now except for merges from 1.1 that Sachin has been doing. How long do you estimate that the work will take and what happens if its not completed before your vacation? I'm uncomfortable throwing M1 out if its going to be a three week conversion period. You may have answered this in the thread and if I missed it I apologize. I'm taking a vacation? Where am I going? Do I need my bathing suite? :-P The build with m2 works now. The conversion period would be the time it takes for me to merge m2migration back to trunk (and verify w/ bootstrap which takes ~30m or so on my laptop). Using svk that should be maybe an hour. But lets say it will take a day for a nice 8x buffer. I'm planning on merging with svk from svkmerge/m2migration to svkmerge/trunk and then from svkmerge/trunk to trunk. I've been doing the opposite to keep svkmerge/m2migration in sync with trunk periodically, which is mostly brainless and works flawlessly. --jason
Re: Maven2 Conversation Status
FYI... windows users should extract the assembly dist into c:\ to avoid long file issues. Looks like the longest file in the dist is about 218c (including the basedir name), so extracting into c:\ should avoid any issues on the evil platform of names that must be short. If anyone believes they have run into a log filename problem on windows either building or running the server please let me know asap. --jason On Jul 20, 2006, at 10:02 PM, John Sisson wrote: It built successfully for me in cygwin (first attempt failed in timer tests). I'll try to do some tests on the weekend. I agree with Jeff's comments that we should have this pass the TCK before it is merged back to trunk. Thanks, John Jason Dillon wrote: This should do the trick: svn co https://svn.apache.org/repos/asf/geronimo/sandbox/ svkmerge/m2migration cd m2migration ./bootstrap gunzip -c m2-assemblies/geronimo-jetty-j2ee/target/geronimo- jetty-j2ee-1.2-SNAPSHOT-bin.tar.gz | tar xf - ./geronimo-jetty-j2ee/bin/startup.sh tail -f geronimo-jetty- j2ee/var/log/geronimo.out ... ./geronimo-jetty-j2ee/bin/startup.sh --user system --password manager --jason PS. I just typed this up in this email, did not actually run this... in my drunken stupor I might have mistyped something... but the general steps are solid (i've been testing w/this for some time). On Jul 19, 2006, at 12:24 AM, Jacek Laskowski wrote: On 7/19/06, Jason Dillon [EMAIL PROTECTED] wrote: Can we get some commitment from PMC members to review and vote in these changes so that we can finally finish the move to Maven 2? I'm on holidays in 2 weeks and would be happy to help out as much as it requires to get it tested and merged with the trunk. How do you want us to help out with it? How should we test it out? Will you send some helpful hints to get us started? Taking the chance I'd like to encourage *anyone* to check out svkmerge/m2conversion branch and give it a whirl. It's a great chance to learn a couple of tips and tricks of using M2 in a project. Jacek --Jacek Laskowski http://www.laskowski.net.pl
Re: Maven2 Conversation Status
Jason Dillon wrote: John, if you can please post the surefire reports for the failed tests in timer so I can verify they are indeed related to GERONIMO-2183 (and unrelated to the m2 work). Unfortunately I didn't keep the reports from when it failed. I assumed it was due to other stuff running on my machine (Thunderbird seems to be looping a lot lately consuming most of the cpu). I did try again today and for some reason I am being prompted for a svn password for codehaus, which I didn't get before: [INFO] Geronimo :: Timer . SUCCESS [1:22.672s] [INFO] Geronimo :: Tomcat SUCCESS [1:13.828s] [INFO] Geronimo :: Tomcat :: Builder . SUCCESS [20.610s] [INFO] Geronimo :: Upgrade ... SUCCESS [5.203s] [INFO] Geronimo :: Plugins ... SUCCESS [0.125s] [INFO] Geronimo Plugins :: CAR ... SUCCESS [11.047s] [INFO] Geronimo Plugins :: Deployment SUCCESS [2.968s] [INFO] [INFO] [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 10 minutes 34 seconds [INFO] Finished at: Sat Jul 22 10:52:38 EST 2006 [INFO] Final Memory: 27M/56M [INFO] Building OpenEJB2... Authentication realm: https://svn.codehaus.org:443 openejb Repo Password for 'sissonj': John Thanks, --jason On Jul 20, 2006, at 10:02 PM, John Sisson wrote: It built successfully for me in cygwin (first attempt failed in timer tests). I'll try to do some tests on the weekend. I agree with Jeff's comments that we should have this pass the TCK before it is merged back to trunk. Thanks, John
Re: Maven2 Conversation Status
Yes, I just started seeing that too... not sure wtf is going on... Changing to use http instead of https fixes... But something recently changed at the haus. --jason On Jul 21, 2006, at 6:01 PM, John Sisson wrote: Jason Dillon wrote: John, if you can please post the surefire reports for the failed tests in timer so I can verify they are indeed related to GERONIMO-2183 (and unrelated to the m2 work). Unfortunately I didn't keep the reports from when it failed. I assumed it was due to other stuff running on my machine (Thunderbird seems to be looping a lot lately consuming most of the cpu). I did try again today and for some reason I am being prompted for a svn password for codehaus, which I didn't get before: [INFO] Geronimo :: Timer . SUCCESS [1:22.672s] [INFO] Geronimo :: Tomcat SUCCESS [1:13.828s] [INFO] Geronimo :: Tomcat :: Builder . SUCCESS [20.610s] [INFO] Geronimo :: Upgrade ... SUCCESS [5.203s] [INFO] Geronimo :: Plugins ... SUCCESS [0.125s] [INFO] Geronimo Plugins :: CAR ... SUCCESS [11.047s] [INFO] Geronimo Plugins :: Deployment SUCCESS [2.968s] [INFO] -- -- [INFO] -- -- [INFO] BUILD SUCCESSFUL [INFO] -- -- [INFO] Total time: 10 minutes 34 seconds [INFO] Finished at: Sat Jul 22 10:52:38 EST 2006 [INFO] Final Memory: 27M/56M [INFO] -- -- Building OpenEJB2... Authentication realm: https://svn.codehaus.org:443 openejb Repo Password for 'sissonj': John Thanks, --jason On Jul 20, 2006, at 10:02 PM, John Sisson wrote: It built successfully for me in cygwin (first attempt failed in timer tests). I'll try to do some tests on the weekend. I agree with Jeff's comments that we should have this pass the TCK before it is merged back to trunk. Thanks, John
Re: Maven2 Conversation Status
Unfortunately I didn't keep the reports from when it failed. I assumed it was due to other stuff running on my machine (Thunderbird seems to be looping a lot lately consuming most of the cpu). No worries, I'm 99% sure they failed in a harmless way to due to lack of cpu availability for the test to complete in the alloted time. I'm considering turning those tests off until they are fixed to pass unless something is actually broken. - Building OpenEJB2... Authentication realm: https://svn.codehaus.org:443 openejb Repo Password for 'sissonj': This is fixed now. If you sync your workspace (to at least #424511), then run this, it should take off from where it failed asking for a passwd: ./bootstrap openejb2 ./build -Dstage=assemble --jason
Re: Maven2 Conversation Status
Any other PMC members want to comment on this? --jason On 7/18/06, Jason Dillon [EMAIL PROTECTED] wrote: Good news... we are almost there. Bad news... it will probably take another week or so get everything *fully* functional. Right now we have a functional Jetty J2EE assembly, which almost all components enabled. Tomcat J2EE assembly is complaining still, but my hunch is that the fix is relatively simple... for someone who knows better than I. The minimal assemblies are in close seconds, and should be easy to get functional once the J2EE assemblies are finished. As many of you have noticed I have been working out of the sandbox/ svkmerge/m2migration branch for this work. I've been tracking changes made to trunk and merging them periodically to my sandbox so that m2migration is kept up to date wrt to other changes. I think that this could start to get out of hand the longer that this work is kept separate. Already I've had to merge a few changes that would not be needed if we had one tree to work from. It is my opinion that we should probably start the RTC process now for merging the svkmerge/m2migration branch to trunk and to deprecate the Maven 1 build... and nuke its build files. I believe that the m2 build is functional enough for people to work with for bug fixes and other changes going into trunk. I also believe that the longer we keep m1 and m2 files around the more work it will be for use to keep them in sync with each other. My recommendation is that we: * RTC vote genesis to be a peer-project to trunk * RTC vote the m2migration branch to be merged back to trunk I would prefer to finish up the work on trunk, but I am fine to merge back to trunk a working m2 build and then continue on the m2migration for another week or so to bunch up changes into per-week intervals for RTC merge-back to trunk (this is not ideal, but will work if that is what is required to get it done). IMO it is better to get trunk sync'd up with the new m2 work that has been done so that when others change configuration that it will get applied to the new build and not get lost in the transition. I am confident that we can get the m2 build finished in the next few weeks... pending the time required to RTC. Can we get some commitment from PMC members to review and vote in these changes so that we can finally finish the move to Maven 2? Please let me know what your opinion is. We are almost there... let's finish the job. --jason
Re: Maven2 Conversation Status
IMHO, until its all completely functional and working, I would not wage a +1 for moving it in and deprecating 1.0. If you are interested in moving in POMs and plugins, then I would be amenable to that. However, I would not at all be amenable to any sort of deprecation until the M2 build is 100% functional. Jason Dillon wrote: Any other PMC members want to comment on this? --jason On 7/18/06, Jason Dillon [EMAIL PROTECTED] wrote: Good news... we are almost there. Bad news... it will probably take another week or so get everything *fully* functional. Right now we have a functional Jetty J2EE assembly, which almost all components enabled. Tomcat J2EE assembly is complaining still, but my hunch is that the fix is relatively simple... for someone who knows better than I. The minimal assemblies are in close seconds, and should be easy to get functional once the J2EE assemblies are finished. As many of you have noticed I have been working out of the sandbox/ svkmerge/m2migration branch for this work. I've been tracking changes made to trunk and merging them periodically to my sandbox so that m2migration is kept up to date wrt to other changes. I think that this could start to get out of hand the longer that this work is kept separate. Already I've had to merge a few changes that would not be needed if we had one tree to work from. It is my opinion that we should probably start the RTC process now for merging the svkmerge/m2migration branch to trunk and to deprecate the Maven 1 build... and nuke its build files. I believe that the m2 build is functional enough for people to work with for bug fixes and other changes going into trunk. I also believe that the longer we keep m1 and m2 files around the more work it will be for use to keep them in sync with each other. My recommendation is that we: * RTC vote genesis to be a peer-project to trunk * RTC vote the m2migration branch to be merged back to trunk I would prefer to finish up the work on trunk, but I am fine to merge back to trunk a working m2 build and then continue on the m2migration for another week or so to bunch up changes into per-week intervals for RTC merge-back to trunk (this is not ideal, but will work if that is what is required to get it done). IMO it is better to get trunk sync'd up with the new m2 work that has been done so that when others change configuration that it will get applied to the new build and not get lost in the transition. I am confident that we can get the m2 build finished in the next few weeks... pending the time required to RTC. Can we get some commitment from PMC members to review and vote in these changes so that we can finally finish the move to Maven 2? Please let me know what your opinion is. We are almost there... let's finish the job. --jason
Re: Maven2 Conversation Status
On Jul 20, 2006, at 2:59 PM, Jeff Genender wrote: IMHO, until its all completely functional and working, I would not wage a +1 for moving it in and deprecating 1.0. If you are interested in moving in POMs and plugins, then I would be amenable to that. However, I would not at all be amenable to any sort of deprecation until the M2 build is 100% functional. What does 100% cover exactly? * * * Before when we had talked about removing the m1 build from /trunk the objections were that the m2 build was not functional enough for folks to work with it on unrelated features/fixes. I do not believe that this is the case anymore. I believe that the m2 build is quite functional enough for normal development. What I am concerned about is the longer we keep m1 and m2 around, the larger the gap is going to get between the two systems. They already produce slightly different outputs and there is no way to get them to be 100% identical due to the dependency requirements for m1 vs. m2 artifacts. Do we run the TCK against the m1 build? or the m2 build? or both? That would be a large waste of time and resource IMO. The end goal is to use m2, and I believe that right now that m2 is functional enough to replace m1 in /trunk. It is not 100% perfect yet... but it is very close. I believe that it would be the best direction for the project to really get the m2 work finished by merging in the m2migration changes and then remove the m1 build (and the related build artifacts that are left over to support the m1 build that duplicate files for the m2 build). IMO, the amount of time that it will take to get the m2 build up to 100% will be much, much less if there was *just* the m2 build. Keeping both around will probably take 2-5x longer to actually complete to transition. * * * But at the same time I would love to deliver the m2 build at 100% now... but I think we need more eyes to get there, which means more developers and PMC members running the build and testing the distribution. I'm positive that you (or someone else) will find something wrong... and we will fix it... but I don't think (unless you find something massively broken) that it should block the merge to trunk and deprecation and removal of the m1 build. To be clear(er) I am suggesting a staged move... 1) Merge svkmerge/m2migration to trunk 2) Deprecate the m1 build (ie... don't use it, use m2, but we leave the files as it) 3) Remove the m1 build (as another merge from svkmerge/m2migration to trunk) I believe that, with *active* PMC involvement for the required RTC, that we can complete this process in the next few weeks. --jason
Re: Maven2 Conversation Status
Jason, I would give you a +0 at this point. You asked what does 100% cover? Based on your description, you said you had Jetty working but not Tomcat, unless I read that wrong. IMHO, that is not acceptable to begin deprecating M1. 100% to me means that I can, from the top of the G tree...with an empty m2 local repo, do a mvn install and minimally end up with a tomcat J2EE, jetty J2EE, and little-G assemblies on the back end. As for the TCK, I would suggest you garner other comments, in particular, those from folks who work with the TCK daily. If we are unable to run the TCK because all of our artifacts are in a M2 repo, then this kind of makes our ability to release nearly impossible. I would like to alter your suggestions slightly. I would recommend: 1) Merge m2 into trunk when M2 can build assemblies from a clean local repo. 2) Work on a TCK m2 and get it working. 3) Merge in the TCK m2 to trunk. 4) Deprecate M1. I cannot support removing/deprecating the M1 build until we can build assemblies and have a working TCK. Jeff Jason Dillon wrote: On Jul 20, 2006, at 2:59 PM, Jeff Genender wrote: IMHO, until its all completely functional and working, I would not wage a +1 for moving it in and deprecating 1.0. If you are interested in moving in POMs and plugins, then I would be amenable to that. However, I would not at all be amenable to any sort of deprecation until the M2 build is 100% functional. What does 100% cover exactly? * * * Before when we had talked about removing the m1 build from /trunk the objections were that the m2 build was not functional enough for folks to work with it on unrelated features/fixes. I do not believe that this is the case anymore. I believe that the m2 build is quite functional enough for normal development. What I am concerned about is the longer we keep m1 and m2 around, the larger the gap is going to get between the two systems. They already produce slightly different outputs and there is no way to get them to be 100% identical due to the dependency requirements for m1 vs. m2 artifacts. Do we run the TCK against the m1 build? or the m2 build? or both? That would be a large waste of time and resource IMO. The end goal is to use m2, and I believe that right now that m2 is functional enough to replace m1 in /trunk. It is not 100% perfect yet... but it is very close. I believe that it would be the best direction for the project to really get the m2 work finished by merging in the m2migration changes and then remove the m1 build (and the related build artifacts that are left over to support the m1 build that duplicate files for the m2 build). IMO, the amount of time that it will take to get the m2 build up to 100% will be much, much less if there was *just* the m2 build. Keeping both around will probably take 2-5x longer to actually complete to transition. * * * But at the same time I would love to deliver the m2 build at 100% now... but I think we need more eyes to get there, which means more developers and PMC members running the build and testing the distribution. I'm positive that you (or someone else) will find something wrong... and we will fix it... but I don't think (unless you find something massively broken) that it should block the merge to trunk and deprecation and removal of the m1 build. To be clear(er) I am suggesting a staged move... 1) Merge svkmerge/m2migration to trunk 2) Deprecate the m1 build (ie... don't use it, use m2, but we leave the files as it) 3) Remove the m1 build (as another merge from svkmerge/m2migration to trunk) I believe that, with *active* PMC involvement for the required RTC, that we can complete this process in the next few weeks. --jason
Re: Maven2 Conversation Status
I would give you a +0 at this point. You asked what does 100% cover? Based on your description, you said you had Jetty working but not Tomcat, unless I read that wrong. IMHO, that is not acceptable to begin deprecating M1. Jetty and Tomcat J2EE and Minimal all work as of yesterday. 100% to me means that I can, from the top of the G tree...with an empty m2 local repo, do a mvn install and minimally end up with a tomcat J2EE, jetty J2EE, and little-G assemblies on the back end. As of right now mvn install from an empty repo will never work due to issues with Maven that are pending fixes in 2.0.5. This is what the 'build' script resolves. Also due to the OpenEJB2 jars built with m2 not being published, due to G 1.2 jars built with m2 not being published, you need to manually compile OpenEJB2 w/m2 half-way through the m2 build of G 1.2. This is what the 'bootstrap' script resolves. So, if you replaced mvn install with bootstrap then the above statement is accurate. As for the TCK, I would suggest you garner other comments, in particular, those from folks who work with the TCK daily. If we are unable to run the TCK because all of our artifacts are in a M2 repo, then this kind of makes our ability to release nearly impossible. I agree, need to get some input from Keven to see what is needed to get the TCK running off of the m2 build. I think that can happen in parallel to the first step (or steps if you include deprecation of m1). I would like to alter your suggestions slightly. I would recommend: 1) Merge m2 into trunk when M2 can build assemblies from a clean local repo. 2) Work on a TCK m2 and get it working. 3) Merge in the TCK m2 to trunk. 4) Deprecate M1. I cannot support removing/deprecating the M1 build until we can build assemblies and have a working TCK. Jeff, I believe (strongly) that it is very important to deprecate (not remove, but deprecate) the m1 build ASAP to prevent widening the gap of differences between the outputs of the two builds. --jason
Re: Maven2 Conversation Status
Jason Dillon wrote: I would give you a +0 at this point. You asked what does 100% cover? Based on your description, you said you had Jetty working but not Tomcat, unless I read that wrong. IMHO, that is not acceptable to begin deprecating M1. Jetty and Tomcat J2EE and Minimal all work as of yesterday. Ok...well...based on your statement before, you did not clarify this. If I can get an assembly, then this is good. 100% to me means that I can, from the top of the G tree...with an empty m2 local repo, do a mvn install and minimally end up with a tomcat J2EE, jetty J2EE, and little-G assemblies on the back end. As of right now mvn install from an empty repo will never work due to issues with Maven that are pending fixes in 2.0.5. This is what the 'build' script resolves. Also due to the OpenEJB2 jars built with m2 not being published, due to G 1.2 jars built with m2 not being published, you need to manually compile OpenEJB2 w/m2 half-way through the m2 build of G 1.2. This is what the 'bootstrap' script resolves. So, if you replaced mvn install with bootstrap then the above statement is accurate. Ok...so you have a script I can run...have a clean repo...and at the end have a full assembly? If so, then this is somewhat acceptable to me. As for the TCK, I would suggest you garner other comments, in particular, those from folks who work with the TCK daily. If we are unable to run the TCK because all of our artifacts are in a M2 repo, then this kind of makes our ability to release nearly impossible. I agree, need to get some input from Keven to see what is needed to get the TCK running off of the m2 build. I think that can happen in parallel to the first step (or steps if you include deprecation of m1). Sounds good...get his input. But a TCK build, one way or the other, without manual intervention would be a gate for this IMHO. I would like to alter your suggestions slightly. I would recommend: 1) Merge m2 into trunk when M2 can build assemblies from a clean local repo. 2) Work on a TCK m2 and get it working. 3) Merge in the TCK m2 to trunk. 4) Deprecate M1. I cannot support removing/deprecating the M1 build until we can build assemblies and have a working TCK. Jeff, I believe (strongly) that it is very important to deprecate (not remove, but deprecate) the m1 build ASAP to prevent widening the gap of differences between the outputs of the two builds --jason
Re: Maven2 Conversation Status
Jetty and Tomcat J2EE and Minimal all work as of yesterday. Ok...well...based on your statement before, you did not clarify this. If I can get an assembly, then this is good. The work has been moving fast. At the time of the initial Maven2 Conversation Status there was an issue, but it was trivial to fix... just needed someone to tell my why it was broken, which David Jencks did. This is one of the reasons I'd like to get the m1 build deprecated, because the sooner we have everyone looking at the m2 build the faster we will get it up to 100%. So, if you replaced mvn install with bootstrap then the above statement is accurate. Ok...so you have a script I can run...have a clean repo...and at the end have a full assembly? If so, then this is somewhat acceptable to me. Yes, it is checked in. You need cygwin on windows to run it, not going to be making a .bat for it as it is temporary until this work is done and G and OpenEJB2 are deploying m2 built artifacts, at which time the build (build.bat) will work, until Maven 2.0.5 is out with the fix to allow `mvn install` to do the trick. I agree, need to get some input from Keven to see what is needed to get the TCK running off of the m2 build. I think that can happen in parallel to the first step (or steps if you include deprecation of m1). Sounds good...get his input. But a TCK build, one way or the other, without manual intervention would be a gate for this IMHO. It will happen, no question about it. The TCK is critical, but IMO it should not limit the move to m2 in /trunk... I believe that the move to m2 on /trunk is a prerequisite for getting the TCK going for the m2 build. We will get it up and running ASAP. --jason
Re: Maven2 Conversation Status
It built successfully for me in cygwin (first attempt failed in timer tests). I'll try to do some tests on the weekend. I agree with Jeff's comments that we should have this pass the TCK before it is merged back to trunk. Thanks, John Jason Dillon wrote: This should do the trick: svn co https://svn.apache.org/repos/asf/geronimo/sandbox/svkmerge/m2migration cd m2migration ./bootstrap gunzip -c m2-assemblies/geronimo-jetty-j2ee/target/geronimo-jetty-j2ee-1.2-SNAPSHOT-bin.tar.gz | tar xf - ./geronimo-jetty-j2ee/bin/startup.sh tail -f geronimo-jetty-j2ee/var/log/geronimo.out ... ./geronimo-jetty-j2ee/bin/startup.sh --user system --password manager --jason PS. I just typed this up in this email, did not actually run this... in my drunken stupor I might have mistyped something... but the general steps are solid (i've been testing w/this for some time). On Jul 19, 2006, at 12:24 AM, Jacek Laskowski wrote: On 7/19/06, Jason Dillon [EMAIL PROTECTED] wrote: Can we get some commitment from PMC members to review and vote in these changes so that we can finally finish the move to Maven 2? I'm on holidays in 2 weeks and would be happy to help out as much as it requires to get it tested and merged with the trunk. How do you want us to help out with it? How should we test it out? Will you send some helpful hints to get us started? Taking the chance I'd like to encourage *anyone* to check out svkmerge/m2conversion branch and give it a whirl. It's a great chance to learn a couple of tips and tricks of using M2 in a project. Jacek --Jacek Laskowski http://www.laskowski.net.pl
Re: Maven2 Conversation Status
On Jul 20, 2006, at 10:02 PM, John Sisson wrote: It built successfully for me in cygwin (first attempt failed in timer tests). I'll try to do some tests on the weekend. Timer tests are known to fail on slower or more resource constrained systems. All of the failures should be expected '20' found (something less than 20). The tests need to be redesigned to work in all environments regardless of cpu/resource availability. I agree with Jeff's comments that we should have this pass the TCK before it is merged back to trunk. I find it very hard to believe that we are going to spend time to setup the TCK to run on sandbox/svkmerge/m2migration. We will get the TCK to run, but we should do so from trunk. It will happen very soon after the merge is complete. It is not like we are going to drop this work once the merge has been done. I'd appreciate a little flexibility here, else it just wastes our time. --jason
Re: Maven2 Conversation Status
John, if you can please post the surefire reports for the failed tests in timer so I can verify they are indeed related to GERONIMO-2183 (and unrelated to the m2 work). Thanks, --jason On Jul 20, 2006, at 10:02 PM, John Sisson wrote: It built successfully for me in cygwin (first attempt failed in timer tests). I'll try to do some tests on the weekend. I agree with Jeff's comments that we should have this pass the TCK before it is merged back to trunk. Thanks, John Jason Dillon wrote: This should do the trick: svn co https://svn.apache.org/repos/asf/geronimo/sandbox/ svkmerge/m2migration cd m2migration ./bootstrap gunzip -c m2-assemblies/geronimo-jetty-j2ee/target/geronimo- jetty-j2ee-1.2-SNAPSHOT-bin.tar.gz | tar xf - ./geronimo-jetty-j2ee/bin/startup.sh tail -f geronimo-jetty- j2ee/var/log/geronimo.out ... ./geronimo-jetty-j2ee/bin/startup.sh --user system --password manager --jason PS. I just typed this up in this email, did not actually run this... in my drunken stupor I might have mistyped something... but the general steps are solid (i've been testing w/this for some time). On Jul 19, 2006, at 12:24 AM, Jacek Laskowski wrote: On 7/19/06, Jason Dillon [EMAIL PROTECTED] wrote: Can we get some commitment from PMC members to review and vote in these changes so that we can finally finish the move to Maven 2? I'm on holidays in 2 weeks and would be happy to help out as much as it requires to get it tested and merged with the trunk. How do you want us to help out with it? How should we test it out? Will you send some helpful hints to get us started? Taking the chance I'd like to encourage *anyone* to check out svkmerge/m2conversion branch and give it a whirl. It's a great chance to learn a couple of tips and tricks of using M2 in a project. Jacek --Jacek Laskowski http://www.laskowski.net.pl
Re: Maven2 Conversation Status
On 7/19/06, Jason Dillon [EMAIL PROTECTED] wrote: Can we get some commitment from PMC members to review and vote in these changes so that we can finally finish the move to Maven 2? I'm on holidays in 2 weeks and would be happy to help out as much as it requires to get it tested and merged with the trunk. How do you want us to help out with it? How should we test it out? Will you send some helpful hints to get us started? Taking the chance I'd like to encourage *anyone* to check out svkmerge/m2conversion branch and give it a whirl. It's a great chance to learn a couple of tips and tricks of using M2 in a project. Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: Maven2 Conversation Status
This should do the trick: svn co https://svn.apache.org/repos/asf/geronimo/sandbox/ svkmerge/m2migration cd m2migration ./bootstrap gunzip -c m2-assemblies/geronimo-jetty-j2ee/target/geronimo- jetty-j2ee-1.2-SNAPSHOT-bin.tar.gz | tar xf - ./geronimo-jetty-j2ee/bin/startup.sh tail -f geronimo-jetty- j2ee/var/log/geronimo.out ... ./geronimo-jetty-j2ee/bin/startup.sh --user system --password manager --jason PS. I just typed this up in this email, did not actually run this... in my drunken stupor I might have mistyped something... but the general steps are solid (i've been testing w/this for some time). On Jul 19, 2006, at 12:24 AM, Jacek Laskowski wrote: On 7/19/06, Jason Dillon [EMAIL PROTECTED] wrote: Can we get some commitment from PMC members to review and vote in these changes so that we can finally finish the move to Maven 2? I'm on holidays in 2 weeks and would be happy to help out as much as it requires to get it tested and merged with the trunk. How do you want us to help out with it? How should we test it out? Will you send some helpful hints to get us started? Taking the chance I'd like to encourage *anyone* to check out svkmerge/m2conversion branch and give it a whirl. It's a great chance to learn a couple of tips and tricks of using M2 in a project. Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: Maven2 Conversation Status
inline.. --- Jason Dillon [EMAIL PROTECTED] wrote: Good news... we are almost there. Bad news... it will probably take another week or so get everything *fully* functional. Right now we have a functional Jetty J2EE assembly, which almost all components enabled. Tomcat J2EE assembly is complaining still, but my hunch is that the fix is relatively simple... for someone who knows better than I. The minimal assemblies are in close seconds, and should be easy to get functional once the J2EE assemblies are finished. As many of you have noticed I have been working out of the sandbox/ svkmerge/m2migration branch for this work. I've been tracking changes made to trunk and merging them periodically to my sandbox so that m2migration is kept up to date wrt to other changes. I think that this could start to get out of hand the longer that this work is kept separate. Already I've had to merge a few changes that would not be needed if we had one tree to work from. It is my opinion that we should probably start the RTC process now for merging the svkmerge/m2migration branch to trunk and to deprecate the Maven 1 build... and nuke its build files. Is this necessary? It is a nice thing to have during bug fixes. I believe that the m2 build is functional enough for people to work with for bug fixes and other changes going into trunk. I also believe that the longer we keep m1 and m2 files around the more work it will be for use to keep them in sync with each other. My recommendation is that we: * RTC vote genesis to be a peer-project to trunk * RTC vote the m2migration branch to be merged back to trunk I would prefer to finish up the work on trunk, but I am fine to merge back to trunk a working m2 build and then continue on the m2migration for another week or so to bunch up changes into per-week intervals for RTC merge-back to trunk (this is not ideal, but will work if that is what is required to get it done). IMO it is better to get trunk sync'd up with the new m2 work that has been done so that when others change configuration that it will get applied to the new build and not get lost in the transition. I am planning to maintain the packaging plugin and configs on the trunk despite all the cosmetic changes done by RTC-2161. I still need to add some functionality and tie some loose ends. I need to add classPath fix and explicit-version.properties fix. Jason, Do I have your permission to do so? We should submit 3 patches for RTC - 1. One from the branch 2. One with packaging plugin and configs made from the trunk 3. One with assembly plugin and Assemblies made from the trunk The patches 2 and 3 can be reviewed and tested independently of 1. IMO this is the only way to keep the build current at all times while we wait for RTC and other issues to be resolved. What do PMC members who will be reviewing this work feel about this approach? I am confident that we can get the m2 build finished in the next few weeks... pending the time required to RTC. Things do not always go as planned. I had planned to have all the servers running on the trunk before I left for my vacation. Thanks Anita Can we get some commitment from PMC members to review and vote in these changes so that we can finally finish the move to Maven 2? Please let me know what your opinion is. We are almost there... let's finish the job. --jason __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Maven2 Conversation Status
Inline - On 7/19/06, anita kulshreshtha [EMAIL PROTECTED] wrote: inline.. --- Jason Dillon [EMAIL PROTECTED] wrote: It is my opinion that we should probably start the RTC process now for merging the svkmerge/m2migration branch to trunk and to deprecate the Maven 1 build... and nuke its build files. Is this necessary? It is a nice thing to have during bug fixes. Hmmm Anita, I too don't see the need for it. Why can't the m2 build be used for bug fixes ? For bugs in the m2 build itself, we can always refer to an older branch or revision that had maven 1. I think we just have to force people to switch to m2. My recommendation is that we: * RTC vote genesis to be a peer-project to trunk * RTC vote the m2migration branch to be merged back to trunk I would prefer to finish up the work on trunk, but I am fine to merge back to trunk a working m2 build and then continue on the m2migration for another week or so to bunch up changes into per-week intervals for RTC merge-back to trunk (this is not ideal, but will work if that is what is required to get it done). IMO it is better to get trunk sync'd up with the new m2 work that has been done so that when others change configuration that it will get applied to the new build and not get lost in the transition. I am planning to maintain the packaging plugin and configs on the trunk despite all the cosmetic changes done by RTC-2161. I still need to add some functionality and tie some loose ends. I need to add classPath fix and explicit-version.properties fix. Jason, Do I have your permission to do so? We should submit 3 patches for RTC - 1. One from the branch 2. One with packaging plugin and configs made from the trunk 3. One with assembly plugin and Assemblies made from the trunk The patches 2 and 3 can be reviewed and tested independently of 1. IMO this is the only way to keep the build current at all times while we wait for RTC and other issues to be resolved. What do PMC members who will be reviewing this work feel about this approach? Just a word of caution - The more the number of RTC, the more the delay. I am confident that we can get the m2 build finished in the next few weeks... pending the time required to RTC. Things do not always go as planned. I had planned to have all the servers running on the trunk before I left for my vacation. Thanks Anita Cheers Prasad
Re: Maven2 Conversation Status
the Maven 1 build... and nuke its build files. Is this necessary? It is a nice thing to have during bug fixes. Yes this is necessary. We already have had several commits to trunk that changed Maven 1 configurations and skipped Maven 2... the longer we have both systems in place the more likely they will get out of sync. I am planning to maintain the packaging plugin and configs on the trunk despite all the cosmetic changes done by RTC-2161. I still need to add Please do not work from trunk... it will be very difficult to apply patches you make to trunk to the m2migration branch which is what is under active development. some functionality and tie some loose ends. I need to add classPath fix and explicit-version.properties fix. Jason, Do I have your permission to do so? What are the changes? We should submit 3 patches for RTC - 1. One from the branch 2. One with packaging plugin and configs made from the trunk 3. One with assembly plugin and Assemblies made from the trunk The patches 2 and 3 can be reviewed and tested independently of 1. IMO this is the only way to keep the build current at all times while we wait for RTC and other issues to be resolved. I do not plan on submitting a patch for RTC. I can produce a rather nasty diff of the trees for review if that is what the PMC wants, but IMO that would be a waste of time for them to review. Instead I suggest that the review be done by checking out the branch, building and then starting the Jetty assembly. --jason
Re: Maven2 Conversation Status
We should submit 3 patches for RTC - 1. One from the branch 2. One with packaging plugin and configs made from the trunk 3. One with assembly plugin and Assemblies made from the trunk The patches 2 and 3 can be reviewed and tested independently of 1. IMO this is the only way to keep the build current at all times while we wait for RTC and other issues to be resolved. What do PMC members who will be reviewing this work feel about this approach? Just a word of caution - The more the number of RTC, the more the delay. I agree. I'd rather get patches applied to m2migration and then use that branch for RTC review. --jason
Re: Maven2 Conversation Status
On 7/19/06, Jason Dillon [EMAIL PROTECTED] wrote: I do not plan on submitting a patch for RTC. I can produce a rather nasty diff of the trees for review if that is what the PMC wants, but IMO that would be a waste of time for them to review. Instead I suggest that the review be done by checking out the branch, building and then starting the Jetty assembly. What I expect is to check out the svkmerge/m2conversion branch and diff it against the trunk, then review the changes, apply them to my local trunk copy and give it a whirl. If it works, it will receive my +1. Anyone care to comment on it. Will it be enough to check it out? Have I already said I'm looking forward to giving it a shot? ;-) Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: Maven2 Conversation Status
What I expect is to check out the svkmerge/m2conversion branch and diff it against the trunk, then review the changes, apply them to my local trunk copy and give it a whirl. If it works, it will receive my +1. Good luck ;-) I would encourage you (and others) to try the build from the branch first. If you feel the need to diff that is fine, though we will probably be merging this change back, not patching. Anyone care to comment on it. Will it be enough to check it out? Have I already said I'm looking forward to giving it a shot? ;-) Good :-) --jason
Re: Maven2 Conversation Status
On 7/20/06, Jason Dillon [EMAIL PROTECTED] wrote: I would encourage you (and others) to try the build from the branch first. If you feel the need to diff that is fine, though we will probably be merging this change back, not patching. That's exactly what I had in mind, I believe. I'm going to merge the changes rather than creating a patch off svkmerge/m2migration and apply it to my local trunk copy. I don't see any other way to manage it. Is this what you had in mind? Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: Maven2 Conversation Status
On Jul 19, 2006, at 3:18 PM, Jacek Laskowski wrote: On 7/20/06, Jason Dillon [EMAIL PROTECTED] wrote: I would encourage you (and others) to try the build from the branch first. If you feel the need to diff that is fine, though we will probably be merging this change back, not patching. That's exactly what I had in mind, I believe. I'm going to merge the changes rather than creating a patch off svkmerge/m2migration and apply it to my local trunk copy. I don't see any other way to manage it. Is this what you had in mind? Yup. Diff would only be for reference. --jason
