openejb-2.2 tag is not buildable

2006-12-18 Thread Jason Dillon
I'm trying to build the OpenEJB 2.2 release so that I can continue  
working on Geronimo CTS/TCK automation... but the openejb-2.2 release  
tag is not buildable in a clean environment:


snip
+ Error stacktraces are turned on.
[INFO] Scanning for projects...
[INFO] Reactor build order:
[INFO]   OpenEJB
[INFO]   OpenEJB :: Modules
[INFO]   OpenEJB :: Core
[INFO]   OpenEJB :: Axis
[INFO]   OpenEJB :: PK Generation :: Builder
[INFO]   OpenEJB :: CORBA
[INFO]   OpenEJB :: Builder
[INFO]   OpenEJB :: CORBA Builder
[INFO]   OpenEJB :: CORBA :: Yoko
[INFO]   OpenEJB :: iTests
[INFO]   OpenEJB :: iTests :: Core
[INFO] snapshot org.apache.geronimo.genesis.plugins:tools-maven- 
plugin:1.1-SNAPSHOT: checking for updates from codehaus-snapshots
[INFO] snapshot org.apache.geronimo.genesis.plugins:tools-maven- 
plugin:1.1-SNAPSHOT: checking for updates from apache-snapshots
Downloading: http://people.apache.org/repo/m2-snapshot-repository/org/ 
apache/geronimo/genesis/plugins/tools-maven-plugin/1.1-SNAPSHOT/tools- 
maven-plugin-1.1-20061214.032036-20.pom

1K downloaded
[INFO] snapshot org.apache.geronimo.genesis.plugins:plugins:1.1- 
SNAPSHOT: checking for updates from codehaus-snapshots
[INFO] snapshot org.apache.geronimo.genesis.plugins:plugins:1.1- 
SNAPSHOT: checking for updates from apache-snapshots
Downloading: http://people.apache.org/repo/m2-snapshot-repository/org/ 
apache/geronimo/genesis/plugins/plugins/1.1-SNAPSHOT/ 
plugins-1.1-20061214.032036-13.pom

9K downloaded
[INFO] snapshot org.apache.geronimo.genesis:genesis:1.1-SNAPSHOT:  
checking for updates from codehaus-snapshots
[INFO] snapshot org.apache.geronimo.genesis:genesis:1.1-SNAPSHOT:  
checking for updates from apache-snapshots
Downloading: http://people.apache.org/repo/m2-snapshot-repository/org/ 
apache/geronimo/genesis/genesis/1.1-SNAPSHOT/ 
genesis-1.1-20061214.032036-13.pom

10K downloaded
Downloading: http://repository.codehaus.org/org/apache/apache/3/ 
apache-3.pom
[WARNING] Unable to get resource from repository codehaus (http:// 
repository.codehaus.org)
Downloading: http://repo1.maven.org/maven2/org/apache/apache/3/ 
apache-3.pom

3K downloaded
Downloading: http://snapshots.repository.codehaus.org/org/apache/ 
geronimo/genesis/plugins/tools-maven-plugin/1.1-SNAPSHOT/tools-maven- 
plugin-1.1-SNAPSHOT.jar
[WARNING] Unable to get resource from repository codehaus-snapshots  
(http://snapshots.repository.codehaus.org)
[INFO]  


[ERROR] BUILD ERROR
[INFO]  

[INFO] Plugin could not be found - check that the goal name is  
correct: Unable to download the artifact from any repository

Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file - 
DgroupId=org.apache.geronimo.genesis.plugins -DartifactId=tools-maven- 
plugin \
-Dversion=1.1-SNAPSHOT -Dpackaging=maven-plugin -Dfile=/path/ 
to/file
  org.apache.geronimo.genesis.plugins:tools-maven-plugin:maven- 
plugin:1.1-SNAPSHOT

from the specified remote repositories:
  central (http://repo1.maven.org/maven2),
  codehaus (http://repository.codehaus.org),
  codehaus-snapshots (http://snapshots.repository.codehaus.org)
  org.apache.geronimo.genesis.plugins:tools-maven-plugin:maven- 
plugin:1.1-SNAPSHOT

from the specified remote repositories:
  central (http://repo1.maven.org/maven2),
  codehaus (http://repository.codehaus.org),
  codehaus-snapshots (http://snapshots.repository.codehaus.org)
[INFO]  


[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Plugin could  
not be found - check that the goal name is correct: Unable to  
download the artifact from any repository

Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file - 
DgroupId=org.apache.geronimo.genesis.plugins -DartifactId=tools-maven- 
plugin \
-Dversion=1.1-SNAPSHOT -Dpackaging=maven-plugin -Dfile=/path/ 
to/file
  org.apache.geronimo.genesis.plugins:tools-maven-plugin:maven- 
plugin:1.1-SNAPSHOT

from the specified remote repositories:
  central (http://repo1.maven.org/maven2),
  codehaus (http://repository.codehaus.org),
  codehaus-snapshots (http://snapshots.repository.codehaus.org)
  org.apache.geronimo.genesis.plugins:tools-maven-plugin:maven- 
plugin:1.1-SNAPSHOT

from the specified remote repositories:
  central (http://repo1.maven.org/maven2),
  codehaus (http://repository.codehaus.org),
  codehaus-snapshots (http://snapshots.repository.codehaus.org)
	at org.apache.maven.lifecycle.DefaultLifecycleExecutor.findExtensions 
(DefaultLifecycleExecutor.java:179)
	at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute 
(DefaultLifecycleExecutor.java:138)

at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322

Re: openejb-2.2 tag is not buildable

2006-12-18 Thread David Blevins


On Dec 18, 2006, at 1:51 PM, Jason Dillon wrote:

I'm trying to build the OpenEJB 2.2 release so that I can continue  
working on Geronimo CTS/TCK automation... but the openejb-2.2  
release tag is not buildable in a clean environment:

[...]
I am not sure that this is a priority for many folks, but I hope  
that someday it will become more important in your eyes.


As you know you don't need to build openejb-2.2 to do your CTS/TCK  
testing.  You can build 1.2-beta or 2.0-m1 as Dain or Matt did when  
they built those releases by adding this repo to your list temporarily:


  http://people.apache.org/~dblevins/stage/

But you're right, tags should be buildable.  As openejb depends on  
geronimo and geronimo depends on openejb -- it's hard.  As you and  
David J. have mentioned, it would be possible to:

 1. release geronimo modules
 2. release openejb
 3. release geromimo applications, configs, and assemblies.

But since we don't do that and I don't think anyone is willing to  
propose it, someone has to release with an imperfect tag and OpenEJB  
is always the one to fall on that sword.  It has nothing to do with  
it not being important, that's just the compromise we make until  
either 1. OpenEJB stops depending on Geronimo snapshots, 2. Geronimo  
stops depending on OpenEJB snapshots, or 3. Geronimo releases modules  
and other in serial with a wait period in the middle for the  
OpenEJB release.


You already know that too and I'm just reiterating what we've all  
gone over before.  My perspective is we need a bit of 1, 2 and 3.


In the meantime comments like I hope that someday it will become  
more important in your eyes don't sit well with me.


So, the here and now:  It's poor form to update tags, but it's also  
poor form to release stuff with snapshots, so I went with (hopefully)  
the lesser of the two evils and updated the tag.


geronimo.*:  1.2-SNAPSHOT - 1.2-beta
tools-maven-plugin:  1.1-SNAPSHOT - 1.1

Fair warning, the tag will still not build due to the missing  
geronimo dependencies.  Geronimo 1.2-beta is waiting on OpenEJB 2.2  
to be released.


As you also know, you can add this repo to your list temporarily to  
build:

  http://people.apache.org/~dain/stage/

Hope this helps,

-David





Re: openejb-2.2 tag is not buildable

2006-12-18 Thread Jason Dillon

On Dec 18, 2006, at 5:15 PM, David Blevins wrote:

On Dec 18, 2006, at 1:51 PM, Jason Dillon wrote:

I'm trying to build the OpenEJB 2.2 release so that I can continue  
working on Geronimo CTS/TCK automation... but the openejb-2.2  
release tag is not buildable in a clean environment:

[...]
I am not sure that this is a priority for many folks, but I hope  
that someday it will become more important in your eyes.


As you know you don't need to build openejb-2.2 to do your CTS/TCK  
testing.  You can build 1.2-beta or 2.0-m1 as Dain or Matt did when  
they built those releases by adding this repo to your list  
temporarily:


  http://people.apache.org/~dblevins/stage/


This requires a change to the source code, which I can not  
automate... and kinda defeats the purpose of the automated builds.


IMO relying on users to change the source in order to build a  
codeline is a serious flaw.



But you're right, tags should be buildable.  As openejb depends on  
geronimo and geronimo depends on openejb -- it's hard.  As you and  
David J. have mentioned, it would be possible to:

 1. release geronimo modules
 2. release openejb
 3. release geromimo applications, configs, and assemblies.

But since we don't do that and I don't think anyone is willing to  
propose it, someone has to release with an imperfect tag and  
OpenEJB is always the one to fall on that sword.  It has nothing to  
do with it not being important, that's just the compromise we make  
until either 1. OpenEJB stops depending on Geronimo snapshots, 2.  
Geronimo stops depending on OpenEJB snapshots, or 3. Geronimo  
releases modules and other in serial with a wait period in the  
middle for the OpenEJB release.


Okay, I understand that... though the deps on Genesis and xmlbeans-m- 
p are completely different.



You already know that too and I'm just reiterating what we've all  
gone over before.  My perspective is we need a bit of 1, 2 and 3.


Ya, would be better in this case to have G split up into components  
and assemblies, and release them separately... that is how I had to  
model it for automated builds.



In the meantime comments like I hope that someday it will become  
more important in your eyes don't sit well with me.


Sorry... though I think that we could have all done a better job at  
this if we had more longer term perspective... though I realize that  
given the circumstances that some corners needed to be cut to  
actually move forward.



So, the here and now:  It's poor form to update tags, but it's also  
poor form to release stuff with snapshots, so I went with  
(hopefully) the lesser of the two evils and updated the tag.


geronimo.*:  1.2-SNAPSHOT - 1.2-beta
tools-maven-plugin:  1.1-SNAPSHOT - 1.1

Fair warning, the tag will still not build due to the missing  
geronimo dependencies.  Geronimo 1.2-beta is waiting on OpenEJB 2.2  
to be released.


As you also know, you can add this repo to your list temporarily to  
build:

  http://people.apache.org/~dain/stage/

Hope this helps,


Thanks... though I hope we can avoid this in the future if  
possible... needing modify source to add these repos really does not  
help me when working from automated builds.  It should have been  
possible to change each branch to use the right dependencies, then  
build them in order and produce a functional system... and a  
repeatable build.   Inclusion of snapshots and split of specs to many  
branches has simply made it more difficult to make a reproducible build.


--jason