Re: Lets start moving to m2

[Aaron Mulder]

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.

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

[Matt Hogstrom]

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

[Jason Dillon]

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

[David Jencks]

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 [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

[Jacek Laskowski]

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

[Aaron Mulder]

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 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 [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

[Jacek Laskowski]

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 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

[Matt Hogstrom]

-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 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 [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

 

Re: Lets start moving to m2

[Jacek Laskowski]

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

[anita kulshreshtha]

  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

[Joe Bohn]

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

[John Sisson]

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 [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

[Jason Dillon]

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

[John Sisson]

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

[Jason Dillon]

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

[John Sisson]

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

[Sachin Patel]

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

[Matt Hogstrom]

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

[Jason Dillon]

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

[Bill Dudney]

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

[Jacek Laskowski]

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

[Bill Dudney]

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 [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

[Matt Hogstrom]

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 [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

[Jason Dillon]

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 [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

[Alan D. Cabrera]

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

Re: Lets start moving to m2

[Paul McMahan]

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

[Prasad Kashyap]

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

[Prasad Kashyap]

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

[Jacek Laskowski]

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

[Jason Dillon]

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

[Prasad Kashyap]

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

[David Jencks]

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

[Prasad Kashyap]

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

[Jacek Laskowski]

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

[Jacek Laskowski]

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

[Alan D. Cabrera]

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

[Jason Dillon]

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