Re: Lets start moving to m2
On 6/27/06, Bill Dudney <[EMAIL PROTECTED]> wrote: this code base; svn co https://svn.apache.org/repos/asf/geronimo/trunk geronimo remove repository; rm -rf ~/.maven deep clean; cd geronimo find . -name target -type d | xargs rm -rf build; maven -Dmaven.test.skip=true new fail; Hey Bill, Give it a shot now after OpenEJB jars are published and a fix is in. It should work like a charm. Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: Lets start moving to m2
FWIW I had talked with Jason Vanzyl yesterday here at Apachecon and asked him about how they would do the conversion. It was a short conversation but his comment was that reorganizing the tree wasnt overly critical but it makes sense at the right time. I think it is probably more critical than Jason, but agree that it is not a show-stopper. Lucky for us, out current module internal layout is reasonable enough to allow it to live asis for a while longer. The layout of the actual modules is more of an issue, as common modules share common dependencies and configuration, that we want to share in a common parent... but, we don't want to push those dependencies and configurations on all of the modules. So, it is fairly important to get to a point where we can reorganize modules into deeper trees and move away from the flat set of modules/configs/ assemblies. In his experience trying to move to a full M2 environment from M1 is best done incrementally and not all at once. Not sure I agree with Jason here. Experience has shown me that trying to do an incremental m1 to m2 while at the same time keeping a functional m1 build results in more work and much more time spent to achieve the same goal of getting onto m2 completely. In some cases that incremental move can take some groups upwards of 6 months (and those groups did not have RTC to worry about, but instead had real features to block the m2 work). It can be done... but can be costly. --jason
Re: Lets start moving to m2
FWIW I had talked with Jason Vanzyl yesterday here at Apachecon and asked him about how they would do the conversion. It was a short conversation but his comment was that reorganizing the tree wasnt overly critical but it makes sense at the right time. One of the suggestions he had was to make a list of things that need to be done and then get them done one at a time. In his experience trying to move to a full M2 environment from M1 is best done incrementally and not all at once. As Jason pointed out there may be some loss of functionality but that should be weighed against productivity. I have only been following this thread as e-mails come in but have not expended the time you guys have so forgive me if I ask obvious questions. Is there a set of steps that we need to accomplish to get the build working under M2? Is there a priority order to them? What are the fit and finish things we can do after the conversion is complete to allow people that working on Geronimo the ability to be as productive as possible? I know Prassad and Anita have been working on this very hard and I've seen David Jencks and others pulling this together. I think it would be good to outline the actions and help everyone understand what needs to be done to help get this important work completed. Also, can we start a new thread like "M2 Issues and Actions" :) Jason Dillon wrote: If we do move things around in trunk, will it make merging changes made in the 1.1 branch more difficult? Most likely... not sure how well SVN tracks changes and then merges back from branches after bits have been moved about. I know that Perforce would be able to handle these types of merges... Basically it will mean that files will need to be merged one by one explicitly, not using the recursive mechanism. If so, how important is it to move things now and would there be a better time to do it, e.g. when 1.1.1 is released? Well, I believe it is important... moderately important. We eventually need to bite the bullet and make these changes, which will cause some additional work when merging due to the way that SVN works. It is work that must be done at some time, and I think that the sooner the better. Its not just the organization of the module's files... but also the organization of the modules themselves. IMO we MUST do both to take the most advantage out of the new m2 build system. I can't stress enough that the current layout was designed around m1. m2 is quite different with respect to the rules that apply when organizing. I'm not sure that delaying these changes will making anything easier. It may reduce work by 5-10% in the short-term but will probably increase work in the long run if we keep delaying to keep merges simple. If we really want to keep merges simple, then we should use Perforce, which actually handles incremental merging and can handle any arbitrary branching and handle full integration history when merging back off of branches of branches. Sorry, back on the soapbox again... but really IMo there is no better SCM than Perforce for large projects that need advanced branching and merging. --jason
Re: Lets start moving to m2
I've found that for moderate patches (e.g. for the console which is already in a different place in trunk than 1.1) it's reasonably easy to just edit the file path in the patch file before attempting to apply it. It won't be a thrill, but it's manageable. Thanks, Aaron On 6/28/06, Jason Dillon <[EMAIL PROTECTED]> wrote: > If we do move things around in trunk, will it make merging changes > made in the 1.1 branch more difficult? Most likely... not sure how well SVN tracks changes and then merges back from branches after bits have been moved about. I know that Perforce would be able to handle these types of merges... Basically it will mean that files will need to be merged one by one explicitly, not using the recursive mechanism. > If so, how important is it to move things now and would there be a > better time to do it, e.g. when 1.1.1 is released? Well, I believe it is important... moderately important. We eventually need to bite the bullet and make these changes, which will cause some additional work when merging due to the way that SVN works. It is work that must be done at some time, and I think that the sooner the better. Its not just the organization of the module's files... but also the organization of the modules themselves. IMO we MUST do both to take the most advantage out of the new m2 build system. I can't stress enough that the current layout was designed around m1. m2 is quite different with respect to the rules that apply when organizing. I'm not sure that delaying these changes will making anything easier. It may reduce work by 5-10% in the short-term but will probably increase work in the long run if we keep delaying to keep merges simple. If we really want to keep merges simple, then we should use Perforce, which actually handles incremental merging and can handle any arbitrary branching and handle full integration history when merging back off of branches of branches. Sorry, back on the soapbox again... but really IMo there is no better SCM than Perforce for large projects that need advanced branching and merging. --jason
Re: Lets start moving to m2
If we do move things around in trunk, will it make merging changes made in the 1.1 branch more difficult? Most likely... not sure how well SVN tracks changes and then merges back from branches after bits have been moved about. I know that Perforce would be able to handle these types of merges... Basically it will mean that files will need to be merged one by one explicitly, not using the recursive mechanism. If so, how important is it to move things now and would there be a better time to do it, e.g. when 1.1.1 is released? Well, I believe it is important... moderately important. We eventually need to bite the bullet and make these changes, which will cause some additional work when merging due to the way that SVN works. It is work that must be done at some time, and I think that the sooner the better. Its not just the organization of the module's files... but also the organization of the modules themselves. IMO we MUST do both to take the most advantage out of the new m2 build system. I can't stress enough that the current layout was designed around m1. m2 is quite different with respect to the rules that apply when organizing. I'm not sure that delaying these changes will making anything easier. It may reduce work by 5-10% in the short-term but will probably increase work in the long run if we keep delaying to keep merges simple. If we really want to keep merges simple, then we should use Perforce, which actually handles incremental merging and can handle any arbitrary branching and handle full integration history when merging back off of branches of branches. Sorry, back on the soapbox again... but really IMo there is no better SCM than Perforce for large projects that need advanced branching and merging. --jason
Re: Lets start moving to m2
If we do move things around in trunk, will it make merging changes made in the 1.1 branch more difficult? If so, how important is it to move things now and would there be a better time to do it, e.g. when 1.1.1 is released? John Jason Dillon wrote: FYI, another reason to drop the old m1 files are aggressively get the m2 build working are that we can move some stuff around, w/o working about breaking m1... for example, we should follow the m2 standard module layout: http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html That, and pending some resolution about how the car/plan bits work, we may want to group module together like: axis/ pom.xml geronimo-axis/ pom.xml geronimo-asix-plan/ pom.xml It will take a little while to move stuff around, and it would suck to have to support the m1 build during that time. --jason On Jun 27, 2006, at 2:55 PM, Matt Hogstrom wrote: I'll retract my earlier comment. Sounds like trunk is broken either way. Damn the torpedoes as they say. +1 to to M2 and +1 to fixing the itests. Jason Dillon wrote: This is basically the same clean process I use, and I agree with the statement about the actual failure changing quite often. :-( IMO it is also really sucky that we have to force tests to skip by default to get things built... or in this case closer to being built. --jason On Jun 27, 2006, at 1:41 PM, Bill Dudney wrote: Hi Jacek, this code base; svn co https://svn.apache.org/repos/asf/geronimo/trunk geronimo remove repository; rm -rf ~/.maven deep clean; cd geronimo find . -name target -type d | xargs rm -rf build; maven -Dmaven.test.skip=true new fail; + | geronimo and geronimo-plugins Geronimo :: Scripts | Memory: 39M/73M + DEPRECATED: the default goal should be specified in the section of project.xml instead of maven.xml build:end: build:start: multiproject:install-callback: [echo] Running jar:install for Geronimo :: Scripts Tag library requested that is not present: 'geronimo:deploy' in plugin: 'null' java:prepare-filesystem: [mkdir] Created dir: /Users/bdudney/Development/geronimo/modules/scripts/target/classes java:compile: [echo] Compiling to /Users/bdudney/Development/geronimo/modules/scripts/target/classes [echo] No java source files to compile. java:jar-resources: Copying 14 files to /Users/bdudney/Development/geronimo/modules/scripts/target/classes test:prepare-filesystem: [mkdir] Created dir: /Users/bdudney/Development/geronimo/modules/scripts/target/test-classes [mkdir] Created dir: /Users/bdudney/Development/geronimo/modules/scripts/target/test-reports test:test-resources: test:compile: [echo] No test source files to compile. test:test: [echo] No tests to run. Running post goal: test:test [touch] Creating /Users/bdudney/Development/geronimo/modules/scripts/target/test-reports/tstamp jar:jar: [jar] Building jar: /Users/bdudney/Development/geronimo/modules/scripts/target/geronimo-scripts-1.2-SNAPSHOT.jar jar:install: [echo] Installing... Uploading to geronimo/jars/geronimo-scripts-1.2-SNAPSHOT.jar: (44K) Uploading to geronimo/poms/geronimo-scripts-1.2-SNAPSHOT.pom: (9K) + | geronimo and geronimo-plugins Geronimo :: Session | Memory: 43M/73M + DEPRECATED: the default goal should be specified in the section of project.xml instead of maven.xml build:end: Attempting to download backport-util-concurrent-.jar. WARNING: Failed to download backport-util-concurrent-.jar. BUILD FAILED File.. /Users/bdudney/Development/geronimo/maven.xml Element... maven:reactor Line.. 43 Column 115 The build cannot continue because of the following unsatisfied dependency: backport-util-concurrent-.jar Total time : 22 minutes 30 seconds Finished at : Tuesday, June 27, 2006 2:10:30 PM MDT This is not the only failure that I have received but just the one I could reproduce today. The actual failure seems to change quite often. The failures seem to come in spurts for a couple of weeks it won't build, other times it will build for a week or so then stop building. Thanks! Bill Dudney MyFaces - http://myfaces.apache.org Cayenne - http://incubator.apache.org/projects/cayenne.html On Jun 27, 2006, at 1:40 PM, Jacek Laskowski wrote: On 6/27/06, Bill Dudney <[EMAIL PROTECTED]> wrote: FWIW I am not able to get a clean build with either m1 or m2 either. What? I can't be. What error(s) do you encounter? I've just done it on a clean machine and it worked like a charm. The m2 build is another story, but it's not been announced official yet. Bill Dudney Jacek --Jacek Laskowski http://www.laskowski.net.pl
Re: Lets start moving to m2
I'll jump on that band wagon too. My m1 build on trunk works (or at least it does with my image from a few days ago). I'm going to give m2 a try later today, but would prefer to know that I have at least one way to build geronimo until the m2 build changes are complete. Joe anita kulshreshtha wrote: I agree. As of today M2 build requires building xmlbeans plugin, fixing xbeans pom and building spec jars. This is not the best way to introduce users to a new build system. Thanks Anita --- Jacek Laskowski <[EMAIL PROTECTED]> wrote: On 6/28/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote: -1 on removing M1 until M2 is working. I second that. No need to rush to M2 until it's fully workable solution. We may not break trunk only because few of us want to move to M2 whereas others might want to look into other areas, but be unable to work on them. Jacek -- Jacek Laskowski http://www.laskowski.net.pl __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- Joe Bohn joe.bohn at earthlink.net "He is no fool who gives what he cannot keep, to gain what he cannot lose." -- Jim Elliot
Re: Lets start moving to m2
I agree. As of today M2 build requires building xmlbeans plugin, fixing xbeans pom and building spec jars. This is not the best way to introduce users to a new build system. Thanks Anita --- Jacek Laskowski <[EMAIL PROTECTED]> wrote: > On 6/28/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote: > > -1 on removing M1 until M2 is working. > > I second that. No need to rush to M2 until it's fully workable > solution. We may not break trunk only because few of us want to move > to M2 whereas others might want to look into other areas, but be > unable to work on them. > > Jacek > > -- > Jacek Laskowski > http://www.laskowski.net.pl > __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Lets start moving to m2
On 6/28/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote: -1 on removing M1 until M2 is working. I second that. No need to rush to M2 until it's fully workable solution. We may not break trunk only because few of us want to move to M2 whereas others might want to look into other areas, but be unable to work on them. Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: Lets start moving to m2
-1 on removing M1 until M2 is working. Dain is working on integrating a large change for OEJB (he has an existing RTC outstanding) and I think it would be unfair to tell him to stop working in trunk since he is being productive now. I'd rather wait until M2 is working to decrease the disruption to folks that are working in trunk. If we need to suspend development activity to do the restructuring then that might make sense. Based on my understanding of the issues its more organizing plugins and modules than restructuring the directories at this point. Aaron Mulder wrote: It doesn't matter to me if M1 builds or not. I think we should switch to M2 immediately and remove all the M1 build stuff except for assemblies (until the M2 assembly plugin is done). It has to be done, and IMHO any users or developers who are looking for a stable build from source should use 1.1 until trunk is fully converted to M2. Thanks, Aaron On 6/27/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote: I'll retract my earlier comment. Sounds like trunk is broken either way. Damn the torpedoes as they say. +1 to to M2 and +1 to fixing the itests. Jason Dillon wrote: > This is basically the same clean process I use, and I agree with the > statement about the actual failure changing quite often. > > :-( > > IMO it is also really sucky that we have to force tests to skip by > default to get things built... or in this case closer to being built. > > --jason > > > On Jun 27, 2006, at 1:41 PM, Bill Dudney wrote: > >> Hi Jacek, >> >> this code base; >> >> svn co https://svn.apache.org/repos/asf/geronimo/trunk geronimo >> >> remove repository; >> >> rm -rf ~/.maven >> >> deep clean; >> >> cd geronimo >> find . -name target -type d | xargs rm -rf >> >> build; >> >> maven -Dmaven.test.skip=true new >> >> fail; >> >> >> + >> | geronimo and geronimo-plugins Geronimo :: Scripts >> | Memory: 39M/73M >> + >> DEPRECATED: the default goal should be specified in the >> section of project.xml instead of maven.xml >> >> build:end: >> >> build:start: >> >> multiproject:install-callback: >> [echo] Running jar:install for Geronimo :: Scripts >> Tag library requested that is not present: 'geronimo:deploy' in >> plugin: 'null' >> java:prepare-filesystem: >> [mkdir] Created dir: >> /Users/bdudney/Development/geronimo/modules/scripts/target/classes >> >> java:compile: >> [echo] Compiling to >> /Users/bdudney/Development/geronimo/modules/scripts/target/classes >> [echo] No java source files to compile. >> >> java:jar-resources: >> Copying 14 files to >> /Users/bdudney/Development/geronimo/modules/scripts/target/classes >> >> test:prepare-filesystem: >> [mkdir] Created dir: >> /Users/bdudney/Development/geronimo/modules/scripts/target/test-classes >> [mkdir] Created dir: >> /Users/bdudney/Development/geronimo/modules/scripts/target/test-reports >> >> test:test-resources: >> >> test:compile: >> [echo] No test source files to compile. >> >> test:test: >> [echo] No tests to run. >> Running post goal: test:test >> [touch] Creating >> /Users/bdudney/Development/geronimo/modules/scripts/target/test-reports/tstamp >> >> >> jar:jar: >> [jar] Building jar: >> /Users/bdudney/Development/geronimo/modules/scripts/target/geronimo-scripts-1.2-SNAPSHOT.jar >> >> >> jar:install: >> [echo] Installing... >> Uploading to geronimo/jars/geronimo-scripts-1.2-SNAPSHOT.jar: >> (44K) >> Uploading to geronimo/poms/geronimo-scripts-1.2-SNAPSHOT.pom: >> (9K) >> >> + >> | geronimo and geronimo-plugins Geronimo :: Session >> | Memory: 43M/73M >> + >> DEPRECATED: the default goal should be specified in the >> section of project.xml instead of maven.xml >> >> build:end: >> >> Attempting to download backport-util-concurrent-.jar. >> WARNING: Failed to download backport-util-concurrent-.jar. >> >> BUILD FAILED >> File.. /Users/bdudney/Development/geronimo/maven.xml >> Element... maven:reactor >> Line.. 43 >> Column 115 >> The build cannot continue because of the following unsatisfied >> dependency: >> >> backport-util-concurrent-.jar >> >> Total time : 22 minutes 30 seconds >> Finished at : Tuesday, June 27, 2006 2:10:30 PM MDT >> >> This is not the only failure that I have received but just the one I >> could reproduce today. The actual failure seems to change quite often. >> The failures seem to come in spurts for a couple of weeks it won't >> build, other times it will build for a week or so then stop building. >> >> Thanks! >> >> >> Bill Dudney >> MyFaces - http://myfaces.apache.org >> Cayenne - http://incubator.apache.org/projects/cayenne.html >> >> >> >> On Jun 27, 2006, at 1:40 PM, Jacek Laskowski wrote: >> >>> On 6/27/06, Bill Dudney <[EMAIL PROTECTED]> wrote: FWIW I am not able to g
Re: Lets start moving to m2
On 6/28/06, Jacek Laskowski <[EMAIL PROTECTED]> wrote: On 6/28/06, David Jencks <[EMAIL PROTECTED]> wrote: > WHAT?? the m1 build works fine modulo repository problems. I'm not happy with Matt's statement, either, but havign read Bill Dudney's email (http://article.gmane.org/gmane.comp.java.geronimo.devel/31749) in this thread I could agree with Matt. Testing it out... The build has just blown up with the error: [EMAIL PROTECTED] /cygdrive/c/oss $ rm -rf ~/.maven [EMAIL PROTECTED] /cygdrive/c/oss $ rm -rf geronimo [EMAIL PROTECTED] /cygdrive/c/oss $ svn co https://svn.apache.org/repos/asf/geronimo/trunk geronimo ... [EMAIL PROTECTED] /cygdrive/c/oss $ cd geronimo [EMAIL PROTECTED] /cygdrive/c/oss/geronimo $ maven -Dmaven.test.skip=true -Dmaven.itest.skip=true ... + | configurations openejb Configuration for performing J2EE deployments | Memory: 60M/254M + DEPRECATED: the default goal should be specified in the section of project.xml instead of maven.xml DEPRECATED: the default goal should be specified in the section of project.xml instead of maven.xml build:end: Attempting to download openejb-builder-2.2-SNAPSHOT.jar. 579K downloaded build:start: multiproject:install-callback: [echo] Running car:install for openejb Configuration for performing J2EE deployments car:prepare-plan: car:package: [mkdir] Created dir: C:\oss\geronimo\configs\openejb-deployer\target\repository Packaging configuration c:\oss\geronimo\configs\openejb-deployer\target\plan\plan.xml 09:00:22,546 ERROR [Deployer] Deployment failed due to org.apache.geronimo.gbean.InvalidConfigurationException: Could not load class org.openejb.deployment.OpenEJBModuleBuilder at org.apache.geronimo.gbean.GBeanInfo.getGBeanInfo(GBeanInfo.java:57) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.addGBeanData(ServiceConfigBuilder.java:295) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.addGBeans(ServiceConfigBuilder.java:290) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.buildConfiguration(ServiceConfigBuilder.java:256) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.buildConfiguration(ServiceConfigBuilder.java:211) at org.apache.geronimo.deployment.service.ServiceConfigBuilder$$FastClassByCGLIB$$9f173be6.invoke() ... Caused by: java.lang.ClassNotFoundException: org.openejb.deployment.OpenEJBModuleBuilder in classloader geronimo/openejb-deployer/1.2-SNAPSHOT/car at org.apache.geronimo.kernel.config.MultiParentClassLoader.loadClass(MultiParentClassLoader.java:249) at java.lang.ClassLoader.loadClass(ClassLoader.java:235) at org.apache.geronimo.gbean.GBeanInfo.getGBeanInfo(GBeanInfo.java:55) ... 75 more Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: Lets start moving to m2
It doesn't matter to me if M1 builds or not. I think we should switch to M2 immediately and remove all the M1 build stuff except for assemblies (until the M2 assembly plugin is done). It has to be done, and IMHO any users or developers who are looking for a stable build from source should use 1.1 until trunk is fully converted to M2. Thanks, Aaron On 6/27/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote: I'll retract my earlier comment. Sounds like trunk is broken either way. Damn the torpedoes as they say. +1 to to M2 and +1 to fixing the itests. Jason Dillon wrote: > This is basically the same clean process I use, and I agree with the > statement about the actual failure changing quite often. > > :-( > > IMO it is also really sucky that we have to force tests to skip by > default to get things built... or in this case closer to being built. > > --jason > > > On Jun 27, 2006, at 1:41 PM, Bill Dudney wrote: > >> Hi Jacek, >> >> this code base; >> >> svn co https://svn.apache.org/repos/asf/geronimo/trunk geronimo >> >> remove repository; >> >> rm -rf ~/.maven >> >> deep clean; >> >> cd geronimo >> find . -name target -type d | xargs rm -rf >> >> build; >> >> maven -Dmaven.test.skip=true new >> >> fail; >> >> >> + >> | geronimo and geronimo-plugins Geronimo :: Scripts >> | Memory: 39M/73M >> + >> DEPRECATED: the default goal should be specified in the >> section of project.xml instead of maven.xml >> >> build:end: >> >> build:start: >> >> multiproject:install-callback: >> [echo] Running jar:install for Geronimo :: Scripts >> Tag library requested that is not present: 'geronimo:deploy' in >> plugin: 'null' >> java:prepare-filesystem: >> [mkdir] Created dir: >> /Users/bdudney/Development/geronimo/modules/scripts/target/classes >> >> java:compile: >> [echo] Compiling to >> /Users/bdudney/Development/geronimo/modules/scripts/target/classes >> [echo] No java source files to compile. >> >> java:jar-resources: >> Copying 14 files to >> /Users/bdudney/Development/geronimo/modules/scripts/target/classes >> >> test:prepare-filesystem: >> [mkdir] Created dir: >> /Users/bdudney/Development/geronimo/modules/scripts/target/test-classes >> [mkdir] Created dir: >> /Users/bdudney/Development/geronimo/modules/scripts/target/test-reports >> >> test:test-resources: >> >> test:compile: >> [echo] No test source files to compile. >> >> test:test: >> [echo] No tests to run. >> Running post goal: test:test >> [touch] Creating >> /Users/bdudney/Development/geronimo/modules/scripts/target/test-reports/tstamp >> >> >> jar:jar: >> [jar] Building jar: >> /Users/bdudney/Development/geronimo/modules/scripts/target/geronimo-scripts-1.2-SNAPSHOT.jar >> >> >> jar:install: >> [echo] Installing... >> Uploading to geronimo/jars/geronimo-scripts-1.2-SNAPSHOT.jar: >> (44K) >> Uploading to geronimo/poms/geronimo-scripts-1.2-SNAPSHOT.pom: >> (9K) >> >> + >> | geronimo and geronimo-plugins Geronimo :: Session >> | Memory: 43M/73M >> + >> DEPRECATED: the default goal should be specified in the >> section of project.xml instead of maven.xml >> >> build:end: >> >> Attempting to download backport-util-concurrent-.jar. >> WARNING: Failed to download backport-util-concurrent-.jar. >> >> BUILD FAILED >> File.. /Users/bdudney/Development/geronimo/maven.xml >> Element... maven:reactor >> Line.. 43 >> Column 115 >> The build cannot continue because of the following unsatisfied >> dependency: >> >> backport-util-concurrent-.jar >> >> Total time : 22 minutes 30 seconds >> Finished at : Tuesday, June 27, 2006 2:10:30 PM MDT >> >> This is not the only failure that I have received but just the one I >> could reproduce today. The actual failure seems to change quite often. >> The failures seem to come in spurts for a couple of weeks it won't >> build, other times it will build for a week or so then stop building. >> >> Thanks! >> >> >> Bill Dudney >> MyFaces - http://myfaces.apache.org >> Cayenne - http://incubator.apache.org/projects/cayenne.html >> >> >> >> On Jun 27, 2006, at 1:40 PM, Jacek Laskowski wrote: >> >>> On 6/27/06, Bill Dudney <[EMAIL PROTECTED]> wrote: FWIW I am not able to get a clean build with either m1 or m2 either. >>> >>> What? I can't be. What error(s) do you encounter? I've just done it on >>> a clean machine and it worked like a charm. The m2 build is another >>> story, but it's not been announced official yet. >>> Bill Dudney >>> >>> Jacek >>> >>> --Jacek Laskowski >>> http://www.laskowski.net.pl >> > > > >
Re: Lets start moving to m2
On 6/28/06, David Jencks <[EMAIL PROTECTED]> wrote: WHAT?? the m1 build works fine modulo repository problems. I'm not happy with Matt's statement, either, but havign read Bill Dudney's email (http://article.gmane.org/gmane.comp.java.geronimo.devel/31749) in this thread I could agree with Matt. Testing it out... david jencks Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: Lets start moving to m2
On Jun 27, 2006, at 2:55 PM, Matt Hogstrom wrote: I'll retract my earlier comment. Sounds like trunk is broken either way. WHAT?? the m1 build works fine modulo repository problems. The m2 build appears to work fine up to assemblies, which is not implemented. As a result we don't know if the m2 build actually produces usable cars. david jencks Damn the torpedoes as they say. +1 to to M2 and +1 to fixing the itests. Jason Dillon wrote: This is basically the same clean process I use, and I agree with the statement about the actual failure changing quite often. :-( IMO it is also really sucky that we have to force tests to skip by default to get things built... or in this case closer to being built. --jason On Jun 27, 2006, at 1:41 PM, Bill Dudney wrote: Hi Jacek, this code base; svn co https://svn.apache.org/repos/asf/geronimo/trunk geronimo remove repository; rm -rf ~/.maven deep clean; cd geronimo find . -name target -type d | xargs rm -rf build; maven -Dmaven.test.skip=true new fail; + | geronimo and geronimo-plugins Geronimo :: Scripts | Memory: 39M/73M + DEPRECATED: the default goal should be specified in the section of project.xml instead of maven.xml build:end: build:start: multiproject:install-callback: [echo] Running jar:install for Geronimo :: Scripts Tag library requested that is not present: 'geronimo:deploy' in plugin: 'null' java:prepare-filesystem: [mkdir] Created dir: /Users/bdudney/Development/geronimo/ modules/scripts/target/classes java:compile: [echo] Compiling to /Users/bdudney/Development/geronimo/ modules/scripts/target/classes [echo] No java source files to compile. java:jar-resources: Copying 14 files to /Users/bdudney/Development/geronimo/modules/ scripts/target/classes test:prepare-filesystem: [mkdir] Created dir: /Users/bdudney/Development/geronimo/ modules/scripts/target/test-classes [mkdir] Created dir: /Users/bdudney/Development/geronimo/ modules/scripts/target/test-reports test:test-resources: test:compile: [echo] No test source files to compile. test:test: [echo] No tests to run. Running post goal: test:test [touch] Creating /Users/bdudney/Development/geronimo/modules/ scripts/target/test-reports/tstamp jar:jar: [jar] Building jar: /Users/bdudney/Development/geronimo/ modules/scripts/target/geronimo-scripts-1.2-SNAPSHOT.jar jar:install: [echo] Installing... Uploading to geronimo/jars/geronimo-scripts-1.2-SNAPSHOT.jar: (44K) Uploading to geronimo/poms/geronimo-scripts-1.2-SNAPSHOT.pom: (9K) + | geronimo and geronimo-plugins Geronimo :: Session | Memory: 43M/73M + DEPRECATED: the default goal should be specified in the section of project.xml instead of maven.xml build:end: Attempting to download backport-util-concurrent-.jar. WARNING: Failed to download backport-util-concurrent-.jar. BUILD FAILED File.. /Users/bdudney/Development/geronimo/maven.xml Element... maven:reactor Line.. 43 Column 115 The build cannot continue because of the following unsatisfied dependency: backport-util-concurrent-.jar Total time : 22 minutes 30 seconds Finished at : Tuesday, June 27, 2006 2:10:30 PM MDT This is not the only failure that I have received but just the one I could reproduce today. The actual failure seems to change quite often. The failures seem to come in spurts for a couple of weeks it won't build, other times it will build for a week or so then stop building. Thanks! Bill Dudney MyFaces - http://myfaces.apache.org Cayenne - http://incubator.apache.org/projects/cayenne.html On Jun 27, 2006, at 1:40 PM, Jacek Laskowski wrote: On 6/27/06, Bill Dudney <[EMAIL PROTECTED]> wrote: FWIW I am not able to get a clean build with either m1 or m2 either. What? I can't be. What error(s) do you encounter? I've just done it on a clean machine and it worked like a charm. The m2 build is another story, but it's not been announced official yet. Bill Dudney Jacek --Jacek Laskowski http://www.laskowski.net.pl
Re: Lets start moving to m2
FYI, another reason to drop the old m1 files are aggressively get the m2 build working are that we can move some stuff around, w/o working about breaking m1... for example, we should follow the m2 standard module layout: http://maven.apache.org/guides/introduction/introduction-to-the- standard-directory-layout.html That, and pending some resolution about how the car/plan bits work, we may want to group module together like: axis/ pom.xml geronimo-axis/ pom.xml geronimo-asix-plan/ pom.xml It will take a little while to move stuff around, and it would suck to have to support the m1 build during that time. --jason On Jun 27, 2006, at 2:55 PM, Matt Hogstrom wrote: I'll retract my earlier comment. Sounds like trunk is broken either way. Damn the torpedoes as they say. +1 to to M2 and +1 to fixing the itests. Jason Dillon wrote: This is basically the same clean process I use, and I agree with the statement about the actual failure changing quite often. :-( IMO it is also really sucky that we have to force tests to skip by default to get things built... or in this case closer to being built. --jason On Jun 27, 2006, at 1:41 PM, Bill Dudney wrote: Hi Jacek, this code base; svn co https://svn.apache.org/repos/asf/geronimo/trunk geronimo remove repository; rm -rf ~/.maven deep clean; cd geronimo find . -name target -type d | xargs rm -rf build; maven -Dmaven.test.skip=true new fail; + | geronimo and geronimo-plugins Geronimo :: Scripts | Memory: 39M/73M + DEPRECATED: the default goal should be specified in the section of project.xml instead of maven.xml build:end: build:start: multiproject:install-callback: [echo] Running jar:install for Geronimo :: Scripts Tag library requested that is not present: 'geronimo:deploy' in plugin: 'null' java:prepare-filesystem: [mkdir] Created dir: /Users/bdudney/Development/geronimo/ modules/scripts/target/classes java:compile: [echo] Compiling to /Users/bdudney/Development/geronimo/ modules/scripts/target/classes [echo] No java source files to compile. java:jar-resources: Copying 14 files to /Users/bdudney/Development/geronimo/modules/ scripts/target/classes test:prepare-filesystem: [mkdir] Created dir: /Users/bdudney/Development/geronimo/ modules/scripts/target/test-classes [mkdir] Created dir: /Users/bdudney/Development/geronimo/ modules/scripts/target/test-reports test:test-resources: test:compile: [echo] No test source files to compile. test:test: [echo] No tests to run. Running post goal: test:test [touch] Creating /Users/bdudney/Development/geronimo/modules/ scripts/target/test-reports/tstamp jar:jar: [jar] Building jar: /Users/bdudney/Development/geronimo/ modules/scripts/target/geronimo-scripts-1.2-SNAPSHOT.jar jar:install: [echo] Installing... Uploading to geronimo/jars/geronimo-scripts-1.2-SNAPSHOT.jar: (44K) Uploading to geronimo/poms/geronimo-scripts-1.2-SNAPSHOT.pom: (9K) + | geronimo and geronimo-plugins Geronimo :: Session | Memory: 43M/73M + DEPRECATED: the default goal should be specified in the section of project.xml instead of maven.xml build:end: Attempting to download backport-util-concurrent-.jar. WARNING: Failed to download backport-util-concurrent-.jar. BUILD FAILED File.. /Users/bdudney/Development/geronimo/maven.xml Element... maven:reactor Line.. 43 Column 115 The build cannot continue because of the following unsatisfied dependency: backport-util-concurrent-.jar Total time : 22 minutes 30 seconds Finished at : Tuesday, June 27, 2006 2:10:30 PM MDT This is not the only failure that I have received but just the one I could reproduce today. The actual failure seems to change quite often. The failures seem to come in spurts for a couple of weeks it won't build, other times it will build for a week or so then stop building. Thanks! Bill Dudney MyFaces - http://myfaces.apache.org Cayenne - http://incubator.apache.org/projects/cayenne.html On Jun 27, 2006, at 1:40 PM, Jacek Laskowski wrote: On 6/27/06, Bill Dudney <[EMAIL PROTECTED]> wrote: FWIW I am not able to get a clean build with either m1 or m2 either. What? I can't be. What error(s) do you encounter? I've just done it on a clean machine and it worked like a charm. The m2 build is another story, but it's not been announced official yet. Bill Dudney Jacek --Jacek Laskowski http://www.laskowski.net.pl
Re: Lets start moving to m2
I'll retract my earlier comment. Sounds like trunk is broken either way. Damn the torpedoes as they say. +1 to to M2 and +1 to fixing the itests. Jason Dillon wrote: This is basically the same clean process I use, and I agree with the statement about the actual failure changing quite often. :-( IMO it is also really sucky that we have to force tests to skip by default to get things built... or in this case closer to being built. --jason On Jun 27, 2006, at 1:41 PM, Bill Dudney wrote: Hi Jacek, this code base; svn co https://svn.apache.org/repos/asf/geronimo/trunk geronimo remove repository; rm -rf ~/.maven deep clean; cd geronimo find . -name target -type d | xargs rm -rf build; maven -Dmaven.test.skip=true new fail; + | geronimo and geronimo-plugins Geronimo :: Scripts | Memory: 39M/73M + DEPRECATED: the default goal should be specified in the section of project.xml instead of maven.xml build:end: build:start: multiproject:install-callback: [echo] Running jar:install for Geronimo :: Scripts Tag library requested that is not present: 'geronimo:deploy' in plugin: 'null' java:prepare-filesystem: [mkdir] Created dir: /Users/bdudney/Development/geronimo/modules/scripts/target/classes java:compile: [echo] Compiling to /Users/bdudney/Development/geronimo/modules/scripts/target/classes [echo] No java source files to compile. java:jar-resources: Copying 14 files to /Users/bdudney/Development/geronimo/modules/scripts/target/classes test:prepare-filesystem: [mkdir] Created dir: /Users/bdudney/Development/geronimo/modules/scripts/target/test-classes [mkdir] Created dir: /Users/bdudney/Development/geronimo/modules/scripts/target/test-reports test:test-resources: test:compile: [echo] No test source files to compile. test:test: [echo] No tests to run. Running post goal: test:test [touch] Creating /Users/bdudney/Development/geronimo/modules/scripts/target/test-reports/tstamp jar:jar: [jar] Building jar: /Users/bdudney/Development/geronimo/modules/scripts/target/geronimo-scripts-1.2-SNAPSHOT.jar jar:install: [echo] Installing... Uploading to geronimo/jars/geronimo-scripts-1.2-SNAPSHOT.jar: (44K) Uploading to geronimo/poms/geronimo-scripts-1.2-SNAPSHOT.pom: (9K) + | geronimo and geronimo-plugins Geronimo :: Session | Memory: 43M/73M + DEPRECATED: the default goal should be specified in the section of project.xml instead of maven.xml build:end: Attempting to download backport-util-concurrent-.jar. WARNING: Failed to download backport-util-concurrent-.jar. BUILD FAILED File.. /Users/bdudney/Development/geronimo/maven.xml Element... maven:reactor Line.. 43 Column 115 The build cannot continue because of the following unsatisfied dependency: backport-util-concurrent-.jar Total time : 22 minutes 30 seconds Finished at : Tuesday, June 27, 2006 2:10:30 PM MDT This is not the only failure that I have received but just the one I could reproduce today. The actual failure seems to change quite often. The failures seem to come in spurts for a couple of weeks it won't build, other times it will build for a week or so then stop building. Thanks! Bill Dudney MyFaces - http://myfaces.apache.org Cayenne - http://incubator.apache.org/projects/cayenne.html On Jun 27, 2006, at 1:40 PM, Jacek Laskowski wrote: On 6/27/06, Bill Dudney <[EMAIL PROTECTED]> wrote: FWIW I am not able to get a clean build with either m1 or m2 either. What? I can't be. What error(s) do you encounter? I've just done it on a clean machine and it worked like a charm. The m2 build is another story, but it's not been announced official yet. Bill Dudney Jacek --Jacek Laskowski http://www.laskowski.net.pl
Re: Lets start moving to m2
This is basically the same clean process I use, and I agree with the statement about the actual failure changing quite often. :-( IMO it is also really sucky that we have to force tests to skip by default to get things built... or in this case closer to being built. --jason On Jun 27, 2006, at 1:41 PM, Bill Dudney wrote: Hi Jacek, this code base; svn co https://svn.apache.org/repos/asf/geronimo/trunk geronimo remove repository; rm -rf ~/.maven deep clean; cd geronimo find . -name target -type d | xargs rm -rf build; maven -Dmaven.test.skip=true new fail; + | geronimo and geronimo-plugins Geronimo :: Scripts | Memory: 39M/73M + DEPRECATED: the default goal should be specified in the section of project.xml instead of maven.xml build:end: build:start: multiproject:install-callback: [echo] Running jar:install for Geronimo :: Scripts Tag library requested that is not present: 'geronimo:deploy' in plugin: 'null' java:prepare-filesystem: [mkdir] Created dir: /Users/bdudney/Development/geronimo/ modules/scripts/target/classes java:compile: [echo] Compiling to /Users/bdudney/Development/geronimo/modules/ scripts/target/classes [echo] No java source files to compile. java:jar-resources: Copying 14 files to /Users/bdudney/Development/geronimo/modules/ scripts/target/classes test:prepare-filesystem: [mkdir] Created dir: /Users/bdudney/Development/geronimo/ modules/scripts/target/test-classes [mkdir] Created dir: /Users/bdudney/Development/geronimo/ modules/scripts/target/test-reports test:test-resources: test:compile: [echo] No test source files to compile. test:test: [echo] No tests to run. Running post goal: test:test [touch] Creating /Users/bdudney/Development/geronimo/modules/ scripts/target/test-reports/tstamp jar:jar: [jar] Building jar: /Users/bdudney/Development/geronimo/modules/ scripts/target/geronimo-scripts-1.2-SNAPSHOT.jar jar:install: [echo] Installing... Uploading to geronimo/jars/geronimo-scripts-1.2-SNAPSHOT.jar: (44K) Uploading to geronimo/poms/geronimo-scripts-1.2-SNAPSHOT.pom: (9K) + | geronimo and geronimo-plugins Geronimo :: Session | Memory: 43M/73M + DEPRECATED: the default goal should be specified in the section of project.xml instead of maven.xml build:end: Attempting to download backport-util-concurrent-.jar. WARNING: Failed to download backport-util-concurrent-.jar. BUILD FAILED File.. /Users/bdudney/Development/geronimo/maven.xml Element... maven:reactor Line.. 43 Column 115 The build cannot continue because of the following unsatisfied dependency: backport-util-concurrent-.jar Total time : 22 minutes 30 seconds Finished at : Tuesday, June 27, 2006 2:10:30 PM MDT This is not the only failure that I have received but just the one I could reproduce today. The actual failure seems to change quite often. The failures seem to come in spurts for a couple of weeks it won't build, other times it will build for a week or so then stop building. Thanks! Bill Dudney MyFaces - http://myfaces.apache.org Cayenne - http://incubator.apache.org/projects/cayenne.html On Jun 27, 2006, at 1:40 PM, Jacek Laskowski wrote: On 6/27/06, Bill Dudney <[EMAIL PROTECTED]> wrote: FWIW I am not able to get a clean build with either m1 or m2 either. What? I can't be. What error(s) do you encounter? I've just done it on a clean machine and it worked like a charm. The m2 build is another story, but it's not been announced official yet. Bill Dudney Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: Lets start moving to m2
On 6/27/06, Bill Dudney <[EMAIL PROTECTED]> wrote: Hi Jacek, this code base; svn co https://svn.apache.org/repos/asf/geronimo/trunk geronimo remove repository; rm -rf ~/.maven deep clean; cd geronimo find . -name target -type d | xargs rm -rf build; maven -Dmaven.test.skip=true new fail; Doing it now... Attempting to download backport-util-concurrent-.jar. WARNING: Failed to download backport-util-concurrent-.jar. BUILD FAILED File.. /Users/bdudney/Development/geronimo/maven.xml Element... maven:reactor Line.. 43 Column 115 The build cannot continue because of the following unsatisfied dependency: backport-util-concurrent-.jar I've already seen it, but can't find anything in my archive nor Google. The version info is not resolved properly. Bill Dudney Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: Lets start moving to m2
Hi Jacek, this code base; svn co https://svn.apache.org/repos/asf/geronimo/trunk geronimo remove repository; rm -rf ~/.maven deep clean; cd geronimo find . -name target -type d | xargs rm -rf build; maven -Dmaven.test.skip=true new fail; + | geronimo and geronimo-plugins Geronimo :: Scripts | Memory: 39M/73M + DEPRECATED: the default goal should be specified in the section of project.xml instead of maven.xml build:end: build:start: multiproject:install-callback: [echo] Running jar:install for Geronimo :: Scripts Tag library requested that is not present: 'geronimo:deploy' in plugin: 'null' java:prepare-filesystem: [mkdir] Created dir: /Users/bdudney/Development/geronimo/modules/ scripts/target/classes java:compile: [echo] Compiling to /Users/bdudney/Development/geronimo/modules/ scripts/target/classes [echo] No java source files to compile. java:jar-resources: Copying 14 files to /Users/bdudney/Development/geronimo/modules/ scripts/target/classes test:prepare-filesystem: [mkdir] Created dir: /Users/bdudney/Development/geronimo/modules/ scripts/target/test-classes [mkdir] Created dir: /Users/bdudney/Development/geronimo/modules/ scripts/target/test-reports test:test-resources: test:compile: [echo] No test source files to compile. test:test: [echo] No tests to run. Running post goal: test:test [touch] Creating /Users/bdudney/Development/geronimo/modules/ scripts/target/test-reports/tstamp jar:jar: [jar] Building jar: /Users/bdudney/Development/geronimo/modules/ scripts/target/geronimo-scripts-1.2-SNAPSHOT.jar jar:install: [echo] Installing... Uploading to geronimo/jars/geronimo-scripts-1.2-SNAPSHOT.jar: (44K) Uploading to geronimo/poms/geronimo-scripts-1.2-SNAPSHOT.pom: (9K) + | geronimo and geronimo-plugins Geronimo :: Session | Memory: 43M/73M + DEPRECATED: the default goal should be specified in the section of project.xml instead of maven.xml build:end: Attempting to download backport-util-concurrent-.jar. WARNING: Failed to download backport-util-concurrent-.jar. BUILD FAILED File.. /Users/bdudney/Development/geronimo/maven.xml Element... maven:reactor Line.. 43 Column 115 The build cannot continue because of the following unsatisfied dependency: backport-util-concurrent-.jar Total time : 22 minutes 30 seconds Finished at : Tuesday, June 27, 2006 2:10:30 PM MDT This is not the only failure that I have received but just the one I could reproduce today. The actual failure seems to change quite often. The failures seem to come in spurts for a couple of weeks it won't build, other times it will build for a week or so then stop building. Thanks! Bill Dudney MyFaces - http://myfaces.apache.org Cayenne - http://incubator.apache.org/projects/cayenne.html On Jun 27, 2006, at 1:40 PM, Jacek Laskowski wrote: On 6/27/06, Bill Dudney <[EMAIL PROTECTED]> wrote: FWIW I am not able to get a clean build with either m1 or m2 either. What? I can't be. What error(s) do you encounter? I've just done it on a clean machine and it worked like a charm. The m2 build is another story, but it's not been announced official yet. Bill Dudney Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: Lets start moving to m2
On 6/27/06, Bill Dudney <[EMAIL PROTECTED]> wrote: FWIW I am not able to get a clean build with either m1 or m2 either. What? I can't be. What error(s) do you encounter? I've just done it on a clean machine and it worked like a charm. The m2 build is another story, but it's not been announced official yet. Bill Dudney Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: Lets start moving to m2
FWIW I am not able to get a clean build with either m1 or m2 either. TTFN, Bill Dudney MyFaces - http://myfaces.apache.org Cayenne - http://incubator.apache.org/projects/cayenne.html On Jun 27, 2006, at 12:47 PM, Jason Dillon wrote: I agree that trunk should always be buildable... though its been months since I've been able to build from the trunk :-P I assume you mean you haven't been able to build using m2, not m1. m1 builds work fine for me. Nope, I have not been able to get a m1 build up in months either. Though I think that is mostly due to constant remote remote failures and the occasional configuration error. But each time I end up giving up after a few hours. --jason
Re: Lets start moving to m2
I agree that trunk should always be buildable... though its been months since I've been able to build from the trunk :-P I assume you mean you haven't been able to build using m2, not m1. m1 builds work fine for me. Nope, I have not been able to get a m1 build up in months either. Though I think that is mostly due to constant remote remote failures and the occasional configuration error. But each time I end up giving up after a few hours. --jason
Re: Lets start moving to m2
I'm not currently working in trunk so it doesn't really matter to me but I think to not disrupt our users and potential developers it would be nice to simply say we've switched to maven 2 and not break them if they are being productive on Maven 1. Is there something about Maven 1 that is impeding the conversion? Or is the disruption to generate a sense of urgency? Matt Jason Dillon wrote: I think that removing the m1 files is a good idea, as it will help force us to get m2 to build... which really should not take that long to get functional 100% of the time. --jason On Jun 26, 2006, at 9:19 PM, Alan D. Cabrera wrote: Jacek Laskowski wrote: On 6/26/06, David Jencks <[EMAIL PROTECTED]> wrote: I'm suggesting that we declare the m1 build obsolete and remove it, except possibly for the assembly step and perhaps modules where the tests do not run under m2. Well, don't get it annoying, but I still don't understand it. Let's pretend we've named the m1 build obsolete, what's next? Shall we call a vote? If it passes, what would be the next steps? If you removed the top-level build.xml I'd know what it'd mean, but now I don't get it. Yes, we call a vote then remove the project.xml/project.properties files. build.xml is for Ant; I don't think we use that. Regards, Alan
Re: Lets start moving to m2
I agree On Jun 27, 2006, at 12:25 AM, Jason Dillon wrote: I think that removing the m1 files is a good idea, as it will help force us to get m2 to build... which really should not take that long to get functional 100% of the time. --jason On Jun 26, 2006, at 9:19 PM, Alan D. Cabrera wrote: Jacek Laskowski wrote: On 6/26/06, David Jencks <[EMAIL PROTECTED]> wrote: I'm suggesting that we declare the m1 build obsolete and remove it, except possibly for the assembly step and perhaps modules where the tests do not run under m2. Well, don't get it annoying, but I still don't understand it. Let's pretend we've named the m1 build obsolete, what's next? Shall we call a vote? If it passes, what would be the next steps? If you removed the top-level build.xml I'd know what it'd mean, but now I don't get it. Yes, we call a vote then remove the project.xml/project.properties files. build.xml is for Ant; I don't think we use that. Regards, Alan -sachin
Re: Lets start moving to m2
Jason Dillon wrote: I agree that trunk should always be buildable... though its been months since I've been able to build from the trunk :-P I assume you mean you haven't been able to build using m2, not m1. m1 builds work fine for me. John --jason On Jun 27, 2006, at 12:33 AM, John Sisson wrote: I don't think we should be removing files until we have a 100% functional m2 build. The trunk should always be buildable. If the M2 build isn't going to be straightforward we should have some information in something like the README.txt file documenting how the build should be executed. John Jason Dillon wrote: I think that removing the m1 files is a good idea, as it will help force us to get m2 to build... which really should not take that long to get functional 100% of the time. --jason On Jun 26, 2006, at 9:19 PM, Alan D. Cabrera wrote: Jacek Laskowski wrote: On 6/26/06, David Jencks <[EMAIL PROTECTED]> wrote: I'm suggesting that we declare the m1 build obsolete and remove it, except possibly for the assembly step and perhaps modules where the tests do not run under m2. Well, don't get it annoying, but I still don't understand it. Let's pretend we've named the m1 build obsolete, what's next? Shall we call a vote? If it passes, what would be the next steps? If you removed the top-level build.xml I'd know what it'd mean, but now I don't get it. Yes, we call a vote then remove the project.xml/project.properties files. build.xml is for Ant; I don't think we use that. Regards, Alan
Re: Lets start moving to m2
I agree that trunk should always be buildable... though its been months since I've been able to build from the trunk :-P --jason On Jun 27, 2006, at 12:33 AM, John Sisson wrote: I don't think we should be removing files until we have a 100% functional m2 build. The trunk should always be buildable. If the M2 build isn't going to be straightforward we should have some information in something like the README.txt file documenting how the build should be executed. John Jason Dillon wrote: I think that removing the m1 files is a good idea, as it will help force us to get m2 to build... which really should not take that long to get functional 100% of the time. --jason On Jun 26, 2006, at 9:19 PM, Alan D. Cabrera wrote: Jacek Laskowski wrote: On 6/26/06, David Jencks <[EMAIL PROTECTED]> wrote: I'm suggesting that we declare the m1 build obsolete and remove it, except possibly for the assembly step and perhaps modules where the tests do not run under m2. Well, don't get it annoying, but I still don't understand it. Let's pretend we've named the m1 build obsolete, what's next? Shall we call a vote? If it passes, what would be the next steps? If you removed the top-level build.xml I'd know what it'd mean, but now I don't get it. Yes, we call a vote then remove the project.xml/ project.properties files. build.xml is for Ant; I don't think we use that. Regards, Alan
Re: Lets start moving to m2
I don't think we should be removing files until we have a 100% functional m2 build. The trunk should always be buildable. If the M2 build isn't going to be straightforward we should have some information in something like the README.txt file documenting how the build should be executed. John Jason Dillon wrote: I think that removing the m1 files is a good idea, as it will help force us to get m2 to build... which really should not take that long to get functional 100% of the time. --jason On Jun 26, 2006, at 9:19 PM, Alan D. Cabrera wrote: Jacek Laskowski wrote: On 6/26/06, David Jencks <[EMAIL PROTECTED]> wrote: I'm suggesting that we declare the m1 build obsolete and remove it, except possibly for the assembly step and perhaps modules where the tests do not run under m2. Well, don't get it annoying, but I still don't understand it. Let's pretend we've named the m1 build obsolete, what's next? Shall we call a vote? If it passes, what would be the next steps? If you removed the top-level build.xml I'd know what it'd mean, but now I don't get it. Yes, we call a vote then remove the project.xml/project.properties files. build.xml is for Ant; I don't think we use that. Regards, Alan
Re: Lets start moving to m2
I think that removing the m1 files is a good idea, as it will help force us to get m2 to build... which really should not take that long to get functional 100% of the time. --jason On Jun 26, 2006, at 9:19 PM, Alan D. Cabrera wrote: Jacek Laskowski wrote: On 6/26/06, David Jencks <[EMAIL PROTECTED]> wrote: I'm suggesting that we declare the m1 build obsolete and remove it, except possibly for the assembly step and perhaps modules where the tests do not run under m2. Well, don't get it annoying, but I still don't understand it. Let's pretend we've named the m1 build obsolete, what's next? Shall we call a vote? If it passes, what would be the next steps? If you removed the top-level build.xml I'd know what it'd mean, but now I don't get it. Yes, we call a vote then remove the project.xml/project.properties files. build.xml is for Ant; I don't think we use that. Regards, Alan
Re: Lets start moving to m2
Jacek Laskowski wrote: On 6/26/06, David Jencks <[EMAIL PROTECTED]> wrote: I'm suggesting that we declare the m1 build obsolete and remove it, except possibly for the assembly step and perhaps modules where the tests do not run under m2. Well, don't get it annoying, but I still don't understand it. Let's pretend we've named the m1 build obsolete, what's next? Shall we call a vote? If it passes, what would be the next steps? If you removed the top-level build.xml I'd know what it'd mean, but now I don't get it. Yes, we call a vote then remove the project.xml/project.properties files. build.xml is for Ant; I don't think we use that. Regards, Alan
Re: Lets start moving to m2
On 6/26/06, Prasad Kashyap <[EMAIL PROTECTED]> wrote: Do we have to go thro the RTC for the geronimo-assembly-plugin ? It is essentially the same code that we had in m1's BaseConfigInstaller.java modified to be a mojo. That's it. Is it a fix? Is it applied to the trunk? If the answers are 'no' and 'yes', call a vote. Painful, but that's how we operate at the moment. Prasad Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: Lets start moving to m2
On 6/26/06, David Jencks <[EMAIL PROTECTED]> wrote: I'm suggesting that we declare the m1 build obsolete and remove it, except possibly for the assembly step and perhaps modules where the tests do not run under m2. Well, don't get it annoying, but I still don't understand it. Let's pretend we've named the m1 build obsolete, what's next? Shall we call a vote? If it passes, what would be the next steps? If you removed the top-level build.xml I'd know what it'd mean, but now I don't get it. david jencks Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: Lets start moving to m2
I'm whiskers away from finishing the assembly plugin. I am down to the nitty grittties of ensuring the correct file mode on the various files and directories. I also have to set and ensure the correct line endings. What else ? We have to get maven to apply the patch for the assembly plugin and deploy the plugin to a remote repo. Do we have to go thro the RTC for the geronimo-assembly-plugin ? It is essentially the same code that we had in m1's BaseConfigInstaller.java modified to be a mojo. That's it. Cheers Prasad On 6/26/06, David Jencks <[EMAIL PROTECTED]> wrote: On Jun 26, 2006, at 11:05 AM, Jacek Laskowski wrote: > On 6/26/06, David Jencks <[EMAIL PROTECTED]> wrote: >> Although there are still some problems (such as not running all the >> tests) I think we have pretty much all of the build working in m2 >> except for the assembly stage, due to the lack of an m2 assembly >> plugin. I'm not sure of the status of such a plugin, but I'd like to >> suggest that we try to make the build be m2-only except for assembly, >> and m1 for the assembly step until a suitable plugin exists. >> >> Comments? Objections? > > Worth to try out, but...haven't we been doing it since a couple of > months? I don't understand what else we could do. Do you think about > something concrete? I think I didn't read your email well. I'm suggesting that we declare the m1 build obsolete and remove it, except possibly for the assembly step and perhaps modules where the tests do not run under m2. thanks david jencks > >> david jencks > > Jacek > > -- > Jacek Laskowski > http://www.laskowski.net.pl
Re: Lets start moving to m2
On Jun 26, 2006, at 11:05 AM, Jacek Laskowski wrote: On 6/26/06, David Jencks <[EMAIL PROTECTED]> wrote: Although there are still some problems (such as not running all the tests) I think we have pretty much all of the build working in m2 except for the assembly stage, due to the lack of an m2 assembly plugin. I'm not sure of the status of such a plugin, but I'd like to suggest that we try to make the build be m2-only except for assembly, and m1 for the assembly step until a suitable plugin exists. Comments? Objections? Worth to try out, but...haven't we been doing it since a couple of months? I don't understand what else we could do. Do you think about something concrete? I think I didn't read your email well. I'm suggesting that we declare the m1 build obsolete and remove it, except possibly for the assembly step and perhaps modules where the tests do not run under m2. thanks david jencks david jencks Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: Lets start moving to m2
Good :-) Just checking. --jason On Jun 26, 2006, at 11:17 AM, Prasad Kashyap wrote: The trunk Cheers Prasad On 6/26/06, Jason Dillon <[EMAIL PROTECTED]> wrote: What branch is this on? IMO, the sooner we get to m2 the better. --jason On Jun 26, 2006, at 10:09 AM, David Jencks wrote: > Although there are still some problems (such as not running all the > tests) I think we have pretty much all of the build working in m2 > except for the assembly stage, due to the lack of an m2 assembly > plugin. I'm not sure of the status of such a plugin, but I'd like > to suggest that we try to make the build be m2-only except for > assembly, and m1 for the assembly step until a suitable plugin exists. > > Comments? Objections? > > thanks > david jencks >
Re: Lets start moving to m2
The trunk Cheers Prasad On 6/26/06, Jason Dillon <[EMAIL PROTECTED]> wrote: What branch is this on? IMO, the sooner we get to m2 the better. --jason On Jun 26, 2006, at 10:09 AM, David Jencks wrote: > Although there are still some problems (such as not running all the > tests) I think we have pretty much all of the build working in m2 > except for the assembly stage, due to the lack of an m2 assembly > plugin. I'm not sure of the status of such a plugin, but I'd like > to suggest that we try to make the build be m2-only except for > assembly, and m1 for the assembly step until a suitable plugin exists. > > Comments? Objections? > > thanks > david jencks >
Re: Lets start moving to m2
What branch is this on? IMO, the sooner we get to m2 the better. --jason On Jun 26, 2006, at 10:09 AM, David Jencks wrote: Although there are still some problems (such as not running all the tests) I think we have pretty much all of the build working in m2 except for the assembly stage, due to the lack of an m2 assembly plugin. I'm not sure of the status of such a plugin, but I'd like to suggest that we try to make the build be m2-only except for assembly, and m1 for the assembly step until a suitable plugin exists. Comments? Objections? thanks david jencks
Re: Lets start moving to m2
On 6/26/06, David Jencks <[EMAIL PROTECTED]> wrote: Although there are still some problems (such as not running all the tests) I think we have pretty much all of the build working in m2 except for the assembly stage, due to the lack of an m2 assembly plugin. I'm not sure of the status of such a plugin, but I'd like to suggest that we try to make the build be m2-only except for assembly, and m1 for the assembly step until a suitable plugin exists. Comments? Objections? Worth to try out, but...haven't we been doing it since a couple of months? I don't understand what else we could do. Do you think about something concrete? I think I didn't read your email well. david jencks Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: Lets start moving to m2
I was unable to attach the zip file of the plugin. Here's the patch. Cheers Prasad. On 6/26/06, Prasad Kashyap <[EMAIL PROTECTED]> wrote: Here's the status of the assembly plugin. The geronimo-assembly-plugin is ready and is undergoing tests. It has only 1 goal, i.e., the "installConfig" goal. This goal runs thro' the dependency list in the pom.xml and installs all dependencies of type "car". I have attached a patch of this plugin for those wishing to play with it. The maven-assembly-plugin is what will be used to do the bulk of the assembly. This plugin had to be patched to meet our requirements. Special thanks to Jesse McConnel and John Casey from maven for answering my myriad questions and agreeing to apply the patch to the assembly plugin. The last remaining thing is our (in)ability to execute the maven-assembly-plugin twice. I am trying to get this resolved. Here's the thread for those wishing to follow - http://www.mail-archive.com/dev@maven.apache.org/msg58756.html Cheers Prasad On 6/26/06, David Jencks <[EMAIL PROTECTED]> wrote: > Although there are still some problems (such as not running all the > tests) I think we have pretty much all of the build working in m2 > except for the assembly stage, due to the lack of an m2 assembly > plugin. I'm not sure of the status of such a plugin, but I'd like to > suggest that we try to make the build be m2-only except for assembly, > and m1 for the assembly step until a suitable plugin exists. > > Comments? Objections? > > thanks > david jencks > > geronimo-assembly-plugin.patch Description: Binary data
Re: Lets start moving to m2
Here's the status of the assembly plugin. The geronimo-assembly-plugin is ready and is undergoing tests. It has only 1 goal, i.e., the "installConfig" goal. This goal runs thro' the dependency list in the pom.xml and installs all dependencies of type "car". I have attached a patch of this plugin for those wishing to play with it. The maven-assembly-plugin is what will be used to do the bulk of the assembly. This plugin had to be patched to meet our requirements. Special thanks to Jesse McConnel and John Casey from maven for answering my myriad questions and agreeing to apply the patch to the assembly plugin. The last remaining thing is our (in)ability to execute the maven-assembly-plugin twice. I am trying to get this resolved. Here's the thread for those wishing to follow - http://www.mail-archive.com/dev@maven.apache.org/msg58756.html Cheers Prasad On 6/26/06, David Jencks <[EMAIL PROTECTED]> wrote: Although there are still some problems (such as not running all the tests) I think we have pretty much all of the build working in m2 except for the assembly stage, due to the lack of an m2 assembly plugin. I'm not sure of the status of such a plugin, but I'd like to suggest that we try to make the build be m2-only except for assembly, and m1 for the assembly step until a suitable plugin exists. Comments? Objections? thanks david jencks
Re: Lets start moving to m2
I'm excited about moving to m2 and have just been waiting on the green light. As I recall, Anita offered to contribute some wiki doc on building Geronimo with m2. Is that doc still on its way in or am I overlooking it? Best wishes, Paul On 6/26/06, David Jencks <[EMAIL PROTECTED]> wrote: Although there are still some problems (such as not running all the tests) I think we have pretty much all of the build working in m2 except for the assembly stage, due to the lack of an m2 assembly plugin. I'm not sure of the status of such a plugin, but I'd like to suggest that we try to make the build be m2-only except for assembly, and m1 for the assembly step until a suitable plugin exists. Comments? Objections? thanks david jencks
Re: Lets start moving to m2
David Jencks wrote: Although there are still some problems (such as not running all the tests) I think we have pretty much all of the build working in m2 except for the assembly stage, due to the lack of an m2 assembly plugin. I'm not sure of the status of such a plugin, but I'd like to suggest that we try to make the build be m2-only except for assembly, and m1 for the assembly step until a suitable plugin exists. Comments? Objections? Sounds great. Regards, Alan
