You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by David Jencks <da...@yahoo.com> on 2006/06/26 19:09:21 UTC
Lets start moving to m2
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
Posted by Paul McMahan <pa...@gmail.com>.
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 <da...@yahoo.com> 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
Posted by Jacek Laskowski <ja...@laskowski.net.pl>.
On 6/26/06, Prasad Kashyap <go...@gmail.com> 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
Posted by Prasad Kashyap <go...@gmail.com>.
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 <da...@yahoo.com> wrote:
>
> On Jun 26, 2006, at 11:05 AM, Jacek Laskowski wrote:
>
> > On 6/26/06, David Jencks <da...@yahoo.com> 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
Posted by Matt Hogstrom <ma...@hogstrom.org>.
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 <da...@yahoo.com> 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
Posted by Joe Bohn <jo...@earthlink.net>.
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 <ja...@laskowski.net.pl> wrote:
>
>
>>On 6/28/06, Matt Hogstrom <ma...@hogstrom.org> 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
Posted by anita kulshreshtha <a_...@yahoo.com>.
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 <ja...@laskowski.net.pl> wrote:
> On 6/28/06, Matt Hogstrom <ma...@hogstrom.org> 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
Posted by Jacek Laskowski <ja...@laskowski.net.pl>.
On 6/28/06, Matt Hogstrom <ma...@hogstrom.org> 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
Posted by Matt Hogstrom <ma...@hogstrom.org>.
-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 <ma...@hogstrom.org> 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 <build>
>> >> 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 <build>
>> >> 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 <bd...@apache.org> 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
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
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 <ma...@hogstrom.org> 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 <build>
> >> 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 <build>
> >> 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 <bd...@apache.org> 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
Posted by Jacek Laskowski <ja...@laskowski.net.pl>.
On 6/27/06, Bill Dudney <bd...@apache.org> 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
Posted by Jacek Laskowski <ja...@laskowski.net.pl>.
On 6/28/06, Jacek Laskowski <ja...@laskowski.net.pl> wrote:
> On 6/28/06, David Jencks <da...@yahoo.com> 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:
jlaskowski@dev /cygdrive/c/oss
$ rm -rf ~/.maven
jlaskowski@dev /cygdrive/c/oss
$ rm -rf geronimo
jlaskowski@dev /cygdrive/c/oss
$ svn co https://svn.apache.org/repos/asf/geronimo/trunk geronimo
...
jlaskowski@dev /cygdrive/c/oss
$ cd geronimo
jlaskowski@dev /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 <build>
section of project.xml instead of maven.xml
DEPRECATED: the default goal should be specified in the <build>
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(<generated>)
...
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
Posted by Jacek Laskowski <ja...@laskowski.net.pl>.
On 6/27/06, Bill Dudney <bd...@apache.org> 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
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
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 <ja...@planet57.com> 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.
>
> <soapbox>
> I know that Perforce would be able to handle these types of merges...
> </soapbox>
>
> 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
Posted by Jacek Laskowski <ja...@laskowski.net.pl>.
On 6/28/06, David Jencks <da...@yahoo.com> 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
Posted by David Jencks <da...@yahoo.com>.
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 <build>
>>> 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 <build>
>>> 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 <bd...@apache.org> 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
Posted by Jason Dillon <ja...@planet57.com>.
> 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
Posted by Matt Hogstrom <ma...@hogstrom.org>.
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.
>
> <soapbox>
> I know that Perforce would be able to handle these types of merges...
> </soapbox>
>
> 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
Posted by Jason Dillon <ja...@planet57.com>.
> 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.
<soapbox>
I know that Perforce would be able to handle these types of merges...
</soapbox>
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
Posted by John Sisson <jr...@gmail.com>.
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 <build>
>>>> 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 <build>
>>>> 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 <bd...@apache.org> 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
Posted by Jason Dillon <ja...@planet57.com>.
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 <build>
>>> 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 <build>
>>> 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 <bd...@apache.org> 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
Posted by Matt Hogstrom <ma...@hogstrom.org>.
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 <build>
>> 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 <build>
>> 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 <bd...@apache.org> 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
Posted by Jason Dillon <ja...@planet57.com>.
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 <build>
> 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 <build>
> 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 <bd...@apache.org> 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
Posted by Bill Dudney <bd...@apache.org>.
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 <build>
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 <build>
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 <bd...@apache.org> 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
Posted by Jacek Laskowski <ja...@laskowski.net.pl>.
On 6/27/06, Bill Dudney <bd...@apache.org> 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
Posted by Bill Dudney <bd...@apache.org>.
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
Posted by Jason Dillon <ja...@planet57.com>.
>> 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
Posted by John Sisson <jr...@gmail.com>.
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 <da...@yahoo.com> 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
Posted by Jason Dillon <ja...@planet57.com>.
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 <da...@yahoo.com> 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
Posted by John Sisson <jr...@gmail.com>.
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 <da...@yahoo.com> 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
Posted by Sachin Patel <sp...@gmail.com>.
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 <da...@yahoo.com> 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
Posted by Jason Dillon <ja...@planet57.com>.
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 <da...@yahoo.com> 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
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
Jacek Laskowski wrote:
> On 6/26/06, David Jencks <da...@yahoo.com> 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
Posted by Jacek Laskowski <ja...@laskowski.net.pl>.
On 6/26/06, David Jencks <da...@yahoo.com> 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
Posted by David Jencks <da...@yahoo.com>.
On Jun 26, 2006, at 11:05 AM, Jacek Laskowski wrote:
> On 6/26/06, David Jencks <da...@yahoo.com> 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
Posted by Jacek Laskowski <ja...@laskowski.net.pl>.
On 6/26/06, David Jencks <da...@yahoo.com> 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
Posted by Jason Dillon <ja...@planet57.com>.
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 <ja...@planet57.com> 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
Posted by Prasad Kashyap <go...@gmail.com>.
The trunk
Cheers
Prasad
On 6/26/06, Jason Dillon <ja...@planet57.com> 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
Posted by Jason Dillon <ja...@planet57.com>.
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
Posted by Prasad Kashyap <go...@gmail.com>.
I was unable to attach the zip file of the plugin. Here's the patch.
Cheers
Prasad.
On 6/26/06, Prasad Kashyap <go...@gmail.com> 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 <da...@yahoo.com> 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
Posted by Prasad Kashyap <go...@gmail.com>.
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 <da...@yahoo.com> 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
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
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