date:20060706

There are still a few places where you must do the same thing with  
Confluence.


But the new repository client plugin kicks much ass to get new  
plugins and update those that are installed.


--jason


On Jul 6, 2006, at 1:16 AM, James Strachan wrote:


On 7/6/06, Jason Dillon [EMAIL PROTECTED] wrote:
You must install a new jar in the WEB-INF/lib and redeploy the web- 
app.


No nice and easy web admin for plugins in JIRA.


Shame! :)

I like the new confluence do-it-all-via-web stuff.

Anyone know how to get on the box to upgrade it etc?

--

James
---
http://radio.weblogs.com/0112098/

RE: ActiveMQ-CPP Mac changes dropped

2006-07-06 Thread Mittler, Nathan

Hey Hiram,
BTW, I just googled for svn:eol-style and ran across this link
http://www.apache.org/dev/svn-eol-style.txt

I'm guessing I should probably have these settings before I commit?  ...
oops! :)

Nate 

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf 
 Of Hiram Chirino
 Sent: Wednesday, July 05, 2006 10:34 PM
 To: activemq-dev@geronimo.apache.org
 Subject: Re: ActiveMQ-CPP Mac changes dropped
 
 The only thing I did was use the
 svn propset svn:eol-style native
 command.  So It's weird that there woudl be any loss of data. 
  Do you got a link to jame's svn revistion?
 
 On 7/5/06, Timothy Bish [EMAIL PROTECTED] wrote:
 
  Hiram
 
 
 
  I was taking a look at the code in activemq-cpp to sync up all the 
  changes that James had made for the Mac, and I noticed that as of 
  6:27pm today you had touched almost all the files, and now 
 the changes 
  James had made are gone.
 
 
 
  I think I got most of them into my own local SVN, but I am 
 not 100%.  
  I'm working on some additional things locally for the next rev.
 
 
 
  -
 
  Timothy A. Bish
 
  [EMAIL PROTECTED]
 
 
 
 
 
 
 
 --
 Regards,
 Hiram
 
 Blog: http://hiramchirino.com

Re: Update to the wiki for the ActiveMQ CPP library

2006-07-06 Thread James Strachan


On 7/6/06, Mittler, Nathan [EMAIL PROTECTED] wrote:

FYI, I've added a page to the wiki for ActiveMQ CPP:
http://www.activemq.org/site/activemq-cpp-client.html

Also updated the Integration C++ link on the navigation pane to
reference this page instead of CMS and I updated the C Integration page
to add a link to this page as well.


Great stuff Nate! Documentation rocks :)

--

James
---
http://radio.weblogs.com/0112098/

[jira] Commented: (GERONIMO-2161) [RTC] Remove Geronimo modules from dependencyManagement in root pom.xml

2006-07-06 Thread Jacek Laskowski (JIRA)

[ 
http://issues.apache.org/jira/browse/GERONIMO-2161?page=comments#action_12419427
 ] 

Jacek Laskowski commented on GERONIMO-2161:
---

What will happen after I've tested it out? How will we proceed? How do you want 
the changes to be applied to trunk? svn merge?

 [RTC] Remove Geronimo modules from dependencyManagement in root pom.xml
 ---

  Key: GERONIMO-2161
  URL: http://issues.apache.org/jira/browse/GERONIMO-2161
  Project: Geronimo
 Type: Task
 Security: public(Regular issues) 
   Components: buildsystem
 Reporter: Jason Dillon
 Assignee: Jason Dillon
  Fix For: 1.2
  Attachments: GERONIMO-2161-configs-v1.1.sub.patch, GERONIMO-2161-v1.patch, 
 GERONIMO-2161-v2.patch, GERONIMO-2161-v3.patch, GERONIMO-2161-v4.patch, 
 GERONIMO-2161-v5.patch

 As I have mentioned before, I believe we should remove the Geronimo modules 
 that are currently listed in the root pom.xml:
 This reduces the configuration of the pom by *~500 lines*.
 Modules that reference these as dependencies will need their pom's adjusted 
 to include version${pom.version}/version and typecar/type for the 
 configs.  But in many places version already exists with the 
 ${geronimoVersion} property... which kinda negates the purpose of the 
 dependencyManagement section anyways.
 I believe that it is more work to keep track of every module in the root pom 
 than it is to specify the additonal elements (mostly just 
 version${pom.version}/version) in child poms.  There is no additional 
 maintenance, as the new elements never need to be changed.
 Net effect if this change is less configuration to maintain and thus a less 
 brittle build that can adapt to change easier.
 Specifically these should be removed:
 {code:xml}
 dependency
 groupIdorg.apache.geronimo.modules/groupId
 artifactIdge-activemq-rar/artifactId
 version${geronimoVersion}/version
 typerar/type
 /dependency
 dependency
 groupIdorg.apache.geronimo.modules/groupId
 artifactIdgeronimo-activation/artifactId
 version${geronimoVersion}/version
 /dependency
 dependency
 groupIdorg.apache.geronimo.modules/groupId
 artifactIdgeronimo-client/artifactId
 version${geronimoVersion}/version
 /dependency
 dependency
 groupIdorg.apache.geronimo.modules/groupId
 artifactIdgeronimo-client-builder/artifactId
 version${geronimoVersion}/version
 /dependency
 dependency
 groupIdorg.apache.geronimo.modules/groupId
 artifactIdgeronimo-common/artifactId
 version${geronimoVersion}/version
 /dependency
 dependency
 groupIdorg.apache.geronimo.modules/groupId
 artifactIdgeronimo-connector/artifactId
 version${geronimoVersion}/version
 /dependency
 dependency
 groupIdorg.apache.geronimo.modules/groupId
 artifactIdgeronimo-connector-builder/artifactId
 version${geronimoVersion}/version
 /dependency
 dependency
 groupIdorg.apache.geronimo.modules/groupId
 artifactIdgeronimo-converter/artifactId
 version${geronimoVersion}/version
 /dependency
 dependency
 groupIdorg.apache.geronimo.modules/groupId
 artifactIdgeronimo-core/artifactId
 version${geronimoVersion}/version
 /dependency
 dependency
 groupIdorg.apache.geronimo.modules/groupId
 artifactIdgeronimo-deploy-config/artifactId
 version${geronimoVersion}/version
 /dependency
 dependency
 groupIdorg.apache.geronimo.modules/groupId
 artifactIdgeronimo-deploy-jsr88/artifactId
 version${geronimoVersion}/version
 /dependency
 dependency
 groupIdorg.apache.geronimo.modules/groupId
 artifactIdgeronimo-deploy-tool/artifactId
 version${geronimoVersion}/version
 /dependency
 dependency
 groupIdorg.apache.geronimo.modules/groupId
 artifactIdgeronimo-deployment/artifactId
 version${geronimoVersion}/version
 /dependency
 dependency
 groupIdorg.apache.geronimo.modules/groupId
 artifactIdgeronimo-derby/artifactId
 version${geronimoVersion}/version
 /dependency
 dependency
 groupIdorg.apache.geronimo.modules/groupId
 artifactIdgeronimo-directory/artifactId
 version${geronimoVersion}/version
 /dependency
 dependency
 groupIdorg.apache.geronimo.modules/groupId
 artifactIdgeronimo-javamail-transport/artifactId
 version${geronimoVersion}/version
 /dependency
 dependency
 groupIdorg.apache.geronimo.modules/groupId
 artifactIdgeronimo-j2ee/artifactId
 version${geronimoVersion}/version
 /dependency
 dependency
 groupIdorg.apache.geronimo.modules/groupId

Re: Geronimo specs pre-RTC


On 7/6/06, Alan D. Cabrera [EMAIL PROTECTED] wrote:

I had an ah ha experience after my fourth beer, before my third
hamburger, yesterday.  One word, branch.

I'll cook something up in geronimo/specs/branch.  I'll include Jason's
suggestions.


Yeah, it happened to me as well, but it was way faster than after the
proverbial fourth beer - I couldn't survive after the second not
mentioning the following ones ;-)

May I read it as you being a not-yet-but-soon proponent of using
branches before a commit to trunk with RTC? That would be great to
hear a friendly soul nearby. ;-)


Alan


Jacek

--
Jacek Laskowski
http://www.laskowski.net.pl

[jira] Commented: (GERONIMO-2161) [RTC] Remove Geronimo modules from dependencyManagement in root pom.xml

2006-07-06 Thread Jacek Laskowski (JIRA)

[ 
http://issues.apache.org/jira/browse/GERONIMO-2161?page=comments#action_12419429
 ] 

Jacek Laskowski commented on GERONIMO-2161:
---

After some thinking...may I find out how the patch was cut? I mean what 
revisions it holds of svkmerge/m2migration? I'd like to apply the patch to my 
local copy of a fresh Geronimo srcs check-out with svn merge and give it a shot 
rather than relying on the incompatible patch.

 [RTC] Remove Geronimo modules from dependencyManagement in root pom.xml
 ---

  Key: GERONIMO-2161
  URL: http://issues.apache.org/jira/browse/GERONIMO-2161
  Project: Geronimo
 Type: Task
 Security: public(Regular issues) 
   Components: buildsystem
 Reporter: Jason Dillon
 Assignee: Jason Dillon
  Fix For: 1.2
  Attachments: GERONIMO-2161-configs-v1.1.sub.patch, GERONIMO-2161-v1.patch, 
 GERONIMO-2161-v2.patch, GERONIMO-2161-v3.patch, GERONIMO-2161-v4.patch, 
 GERONIMO-2161-v5.patch

 As I have mentioned before, I believe we should remove the Geronimo modules 
 that are currently listed in the root pom.xml:
 This reduces the configuration of the pom by *~500 lines*.
 Modules that reference these as dependencies will need their pom's adjusted 
 to include version${pom.version}/version and typecar/type for the 
 configs.  But in many places version already exists with the 
 ${geronimoVersion} property... which kinda negates the purpose of the 
 dependencyManagement section anyways.
 I believe that it is more work to keep track of every module in the root pom 
 than it is to specify the additonal elements (mostly just 
 version${pom.version}/version) in child poms.  There is no additional 
 maintenance, as the new elements never need to be changed.
 Net effect if this change is less configuration to maintain and thus a less 
 brittle build that can adapt to change easier.
 Specifically these should be removed:
 {code:xml}
 dependency
 groupIdorg.apache.geronimo.modules/groupId
 artifactIdge-activemq-rar/artifactId
 version${geronimoVersion}/version
 typerar/type
 /dependency
 dependency
 groupIdorg.apache.geronimo.modules/groupId
 artifactIdgeronimo-activation/artifactId
 version${geronimoVersion}/version
 /dependency
 dependency
 groupIdorg.apache.geronimo.modules/groupId
 artifactIdgeronimo-client/artifactId
 version${geronimoVersion}/version
 /dependency
 dependency
 groupIdorg.apache.geronimo.modules/groupId
 artifactIdgeronimo-client-builder/artifactId
 version${geronimoVersion}/version
 /dependency
 dependency
 groupIdorg.apache.geronimo.modules/groupId
 artifactIdgeronimo-common/artifactId
 version${geronimoVersion}/version
 /dependency
 dependency
 groupIdorg.apache.geronimo.modules/groupId
 artifactIdgeronimo-connector/artifactId
 version${geronimoVersion}/version
 /dependency
 dependency
 groupIdorg.apache.geronimo.modules/groupId
 artifactIdgeronimo-connector-builder/artifactId
 version${geronimoVersion}/version
 /dependency
 dependency
 groupIdorg.apache.geronimo.modules/groupId
 artifactIdgeronimo-converter/artifactId
 version${geronimoVersion}/version
 /dependency
 dependency
 groupIdorg.apache.geronimo.modules/groupId
 artifactIdgeronimo-core/artifactId
 version${geronimoVersion}/version
 /dependency
 dependency
 groupIdorg.apache.geronimo.modules/groupId
 artifactIdgeronimo-deploy-config/artifactId
 version${geronimoVersion}/version
 /dependency
 dependency
 groupIdorg.apache.geronimo.modules/groupId
 artifactIdgeronimo-deploy-jsr88/artifactId
 version${geronimoVersion}/version
 /dependency
 dependency
 groupIdorg.apache.geronimo.modules/groupId
 artifactIdgeronimo-deploy-tool/artifactId
 version${geronimoVersion}/version
 /dependency
 dependency
 groupIdorg.apache.geronimo.modules/groupId
 artifactIdgeronimo-deployment/artifactId
 version${geronimoVersion}/version
 /dependency
 dependency
 groupIdorg.apache.geronimo.modules/groupId
 artifactIdgeronimo-derby/artifactId
 version${geronimoVersion}/version
 /dependency
 dependency
 groupIdorg.apache.geronimo.modules/groupId
 artifactIdgeronimo-directory/artifactId
 version${geronimoVersion}/version
 /dependency
 dependency
 groupIdorg.apache.geronimo.modules/groupId
 artifactIdgeronimo-javamail-transport/artifactId
 version${geronimoVersion}/version
 /dependency
 dependency
 groupIdorg.apache.geronimo.modules/groupId

Re: [jira] Commented: (GERONIMO-2161) [RTC] Remove Geronimo modules from dependencyManagement in root pom.xml

I'm sorry... but I do not understand what you are asking Jacek.   
Could you please rephrase your question/request?


Thanks,

--jason


On Jul 6, 2006, at 12:22 AM, Jacek Laskowski (JIRA) wrote:

[ http://issues.apache.org/jira/browse/GERONIMO-2161? 
page=comments#action_12419429 ]


Jacek Laskowski commented on GERONIMO-2161:
---

After some thinking...may I find out how the patch was cut? I mean  
what revisions it holds of svkmerge/m2migration? I'd like to apply  
the patch to my local copy of a fresh Geronimo srcs check-out with  
svn merge and give it a shot rather than relying on the  
incompatible patch.


[RTC] Remove Geronimo modules from dependencyManagement in root  
pom.xml
- 
--


 Key: GERONIMO-2161
 URL: http://issues.apache.org/jira/browse/GERONIMO-2161
 Project: Geronimo
Type: Task
Security: public(Regular issues)
  Components: buildsystem
Reporter: Jason Dillon
Assignee: Jason Dillon
 Fix For: 1.2
 Attachments: GERONIMO-2161-configs-v1.1.sub.patch, GERONIMO-2161- 
v1.patch, GERONIMO-2161-v2.patch, GERONIMO-2161-v3.patch,  
GERONIMO-2161-v4.patch, GERONIMO-2161-v5.patch


As I have mentioned before, I believe we should remove the  
Geronimo modules that are currently listed in the root pom.xml:

This reduces the configuration of the pom by *~500 lines*.
Modules that reference these as dependencies will need their pom's  
adjusted to include version${pom.version}/version and  
typecar/type for the configs.  But in many places version  
already exists with the ${geronimoVersion} property... which kinda  
negates the purpose of the dependencyManagement section anyways.
I believe that it is more work to keep track of every module in  
the root pom than it is to specify the additonal elements (mostly  
just version${pom.version}/version) in child poms.  There is  
no additional maintenance, as the new elements never need to be  
changed.
Net effect if this change is less configuration to maintain and  
thus a less brittle build that can adapt to change easier.

Specifically these should be removed:
{code:xml}
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdge-activemq-rar/artifactId
version${geronimoVersion}/version
typerar/type
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-activation/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-client/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-client-builder/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-common/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-connector/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-connector-builder/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-converter/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-core/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-deploy-config/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-deploy-jsr88/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-deploy-tool/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-deployment/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-derby/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-directory/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-javamail-transport/artifactId
version${geronimoVersion}/version

Re: [jira] Commented: (GERONIMO-2161) [RTC] Remove Geronimo modules from dependencyManagement in root pom.xml


On 7/6/06, Jason Dillon [EMAIL PROTECTED] wrote:

I'm sorry... but I do not understand what you are asking Jacek.
Could you please rephrase your question/request?


How did you cut the latest patch v5? What commands did you use? I
guess it was something like 'svn diff ...  GERONIMO-2161-v5.patch',
wasn't it? If so and the changes are part of a branch (e.g.
svkmerge/m2migration), we (testers) could apply it to our local
Geronimo srcs using 'svn merge' nor 'patch' that we've just found is
incompatible. This way we will use svn commands only and be able to
apply and test it.


--jason


Jacek

--
Jacek Laskowski
http://www.laskowski.net.pl

Re: [jira] Updated: (GERONIMO-2161) [RTC] Remove Geronimo modules from dependencyManagement in root pom.xml



--- Jason Dillon [EMAIL PROTECTED] wrote:

 What user friendliness are you talking about?
 
 --jason
 
 
 On Jul 5, 2006, at 2:25 AM, anita kulshreshtha wrote:
 
 I would also prefer to see any changes to improve the
  maintainability  and user friendliness of M2 build be held off
 until
  the server assembly is functional.
 
  Thanks
  Anita
 
  --- David Jencks [EMAIL PROTECTED] wrote:
 
 
  On Jul 5, 2006, at 12:25 AM, John Sisson wrote:
 
  Jacek Laskowski wrote:
  On 7/3/06, Jason Dillon [EMAIL PROTECTED] wrote:
  NOTE... the m2 build in trunk is already broken... this patches
  help
  FIX MANY OF THOSE PROBLEMS!
 
  NOTED, but... it's not broken. it has never worked so we can
  pretend
  to call it broken. It's a small, but important point we cannot
  dismiss.
 
  Since the official build is still m1 and this will not affect
 the
  m1
  build, I don't see why your point about breakage is applicable
 at
 
  all.
  ...
  When I first created the m1 build for Geronimo years ago there
  were
  certainly a few moments of breakage due to build changes, but
  since
  there was no commit by committee junk going on then it was easy
  to
  just fix when things happened to get a bit askew.
 
  The branch idea was just to make it easier to actually make
  progress,
  as I am move on this stuff way way faster than the lot of you
 can
  react to emails and JIRAs which often (as this one did) need
  several
  sets of emails to clarify.
 
  That's the point in RTC - discussing, discussing, over and over
  again.
  I'm not in favour of RTC, but some of its rules are fine. It
  fosters
  discussions we lacked. That's the main point of RTC. Isn't it
  funny
  that you've mentioned it as an argument against RTC?
 
  What's wrong with committing changes made in the branch back to
  trunk
  once they've been tested? My proposal is not to wait until the
  migration is done, but rather apply it in small portions,
  gradually.
  It should work, shouldn't it? I'd greatly appreciate your
 comment
  on
  it as I guess I don't see the whole picture and keep thinking
 the
  branch might help when others have already seen it would fall
  short.
 
  Can we avoid the concerns that have been aired regarding svn
  merging issues when directories are reorganised by leaving the
  reorganization of directories as a last phase of the m2
 migration?
 
  I would have thought that we could move further along with the
  migration without reorganizing directories (AFAIK, maven should
 be
 
  able to work with existing directory structures, although doing
 so
 
  may incur more work).  We would also need to coordinate the
  reorganization of directories with the owners of other branches
  from trunk, to minimize the impact on them.
 
  I would prefer to wait to reorganize the directories until after
 the
 
  work in the dead-1.2 branch is merged with trunk.  I plan to go
 back
 
  to this activity now.  Other committers may wish to note that
 merging
 
  the work in dead-1.2 should not need RTC as it is already part of
 a
  main development line.
 
  thanks
  david jencks
 
 
  John
  --jason
 
  Jacek
 
 
 
 
 
 
  __
  Do You Yahoo!?
  Tired of spam?  Yahoo! Mail has the best spam protection around
  http://mail.yahoo.com
 
 


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

OSCON Geronimo BOF Scheduled

2006-07-06 Thread Matt Hogstrom


For those committers that will be at the OSCON Conference we have a BOF 
scheduled.  It is:

Your BoF for OSCON 2006 has been scheduled for:

•  Wednesday, July 26
•  7:30 pm - 8:30 pm
•  Location:  D139-140
•  BoF Name:  New Features of Apache Geronimo 1.1 (including new plug-in 
capability)

Who all will be at OSCON?

Re: [jira] Updated: (GERONIMO-2161) [RTC] Remove Geronimo modules from dependencyManagement in root pom.xml

The existing commands to build are -
cd modules, mvn clean
cd ..\m2-plugins, mvn
and After this as long as you do not wipe out the plugin, one can use
just mvn from the top directory to get a full build. 
Did these not work for you (after you had the right xmlbeans
plugin)?
The new build (GERONIMO-2161) uses 2 step process -
mvn -Dstaqge=bootstrap
mvn -Dstage=assemble
   The bootstrap stage still builds all the modules! The assemble stage
does not build them. User will be forced to always use 2 commannds -
clean repo or not. Which I think is not very user firendly. 
Hiding building modules and plugins in a bootstrap phase is more
user friendly. Because the users will not be exposed to the shortcoming
of maven. 

Thanks
Anita
--- Jason Dillon [EMAIL PROTECTED] wrote:

 What user friendliness are you talking about?
 
 --jason
 
 
 On Jul 5, 2006, at 2:25 AM, anita kulshreshtha wrote:
 
 I would also prefer to see any changes to improve the
  maintainability  and user friendliness of M2 build be held off
 until
  the server assembly is functional.
 
  Thanks
  Anita
 
  --- David Jencks [EMAIL PROTECTED] wrote:
 
 
  On Jul 5, 2006, at 12:25 AM, John Sisson wrote:
 
  Jacek Laskowski wrote:
  On 7/3/06, Jason Dillon [EMAIL PROTECTED] wrote:
  NOTE... the m2 build in trunk is already broken... this patches
  help
  FIX MANY OF THOSE PROBLEMS!
 
  NOTED, but... it's not broken. it has never worked so we can
  pretend
  to call it broken. It's a small, but important point we cannot
  dismiss.
 
  Since the official build is still m1 and this will not affect
 the
  m1
  build, I don't see why your point about breakage is applicable
 at
 
  all.
  ...
  When I first created the m1 build for Geronimo years ago there
  were
  certainly a few moments of breakage due to build changes, but
  since
  there was no commit by committee junk going on then it was easy
  to
  just fix when things happened to get a bit askew.
 
  The branch idea was just to make it easier to actually make
  progress,
  as I am move on this stuff way way faster than the lot of you
 can
  react to emails and JIRAs which often (as this one did) need
  several
  sets of emails to clarify.
 
  That's the point in RTC - discussing, discussing, over and over
  again.
  I'm not in favour of RTC, but some of its rules are fine. It
  fosters
  discussions we lacked. That's the main point of RTC. Isn't it
  funny
  that you've mentioned it as an argument against RTC?
 
  What's wrong with committing changes made in the branch back to
  trunk
  once they've been tested? My proposal is not to wait until the
  migration is done, but rather apply it in small portions,
  gradually.
  It should work, shouldn't it? I'd greatly appreciate your
 comment
  on
  it as I guess I don't see the whole picture and keep thinking
 the
  branch might help when others have already seen it would fall
  short.
 
  Can we avoid the concerns that have been aired regarding svn
  merging issues when directories are reorganised by leaving the
  reorganization of directories as a last phase of the m2
 migration?
 
  I would have thought that we could move further along with the
  migration without reorganizing directories (AFAIK, maven should
 be
 
  able to work with existing directory structures, although doing
 so
 
  may incur more work).  We would also need to coordinate the
  reorganization of directories with the owners of other branches
  from trunk, to minimize the impact on them.
 
  I would prefer to wait to reorganize the directories until after
 the
 
  work in the dead-1.2 branch is merged with trunk.  I plan to go
 back
 
  to this activity now.  Other committers may wish to note that
 merging
 
  the work in dead-1.2 should not need RTC as it is already part of
 a
  main development line.
 
  thanks
  david jencks
 
 
  John
  --jason
 
  Jacek
 
 
 
 
 
 
  __
  Do You Yahoo!?
  Tired of spam?  Yahoo! Mail has the best spam protection around
  http://mail.yahoo.com
 
 


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

Re: [jira] Updated: (GERONIMO-2161) [RTC] Remove Geronimo modules from dependencyManagement in root pom.xml

The existing commands to build are -
cd modules, mvn clean
cd ..\m2-plugins, mvn
and After this as long as you do not wipe out the plugin, one can use
just mvn from the top directory to get a full build. 
Did these not work for you (after you had the right xmlbeans
plugin)?
The new build (GERONIMO-2161) uses 2 step process -
mvn -Dstaqge=bootstrap
mvn -Dstage=assemble
   The bootstrap stage still builds all the modules! The assemble stage
does not build them. User will be forced to always use 2 commannds -
clean repo or not. Which I think is not very user firendly. 
Hiding building modules and plugins in a bootstrap phase is more
user friendly. Because the users will not be exposed to the shortcoming
of maven. 

Thanks
Anita
--- Jason Dillon [EMAIL PROTECTED] wrote:

 What user friendliness are you talking about?
 
 --jason
 
 
 On Jul 5, 2006, at 2:25 AM, anita kulshreshtha wrote:
 
 I would also prefer to see any changes to improve the
  maintainability  and user friendliness of M2 build be held off
 until
  the server assembly is functional.
 
  Thanks
  Anita
 
  --- David Jencks [EMAIL PROTECTED] wrote:
 
 
  On Jul 5, 2006, at 12:25 AM, John Sisson wrote:
 
  Jacek Laskowski wrote:
  On 7/3/06, Jason Dillon [EMAIL PROTECTED] wrote:
  NOTE... the m2 build in trunk is already broken... this patches
  help
  FIX MANY OF THOSE PROBLEMS!
 
  NOTED, but... it's not broken. it has never worked so we can
  pretend
  to call it broken. It's a small, but important point we cannot
  dismiss.
 
  Since the official build is still m1 and this will not affect
 the
  m1
  build, I don't see why your point about breakage is applicable
 at
 
  all.
  ...
  When I first created the m1 build for Geronimo years ago there
  were
  certainly a few moments of breakage due to build changes, but
  since
  there was no commit by committee junk going on then it was easy
  to
  just fix when things happened to get a bit askew.
 
  The branch idea was just to make it easier to actually make
  progress,
  as I am move on this stuff way way faster than the lot of you
 can
  react to emails and JIRAs which often (as this one did) need
  several
  sets of emails to clarify.
 
  That's the point in RTC - discussing, discussing, over and over
  again.
  I'm not in favour of RTC, but some of its rules are fine. It
  fosters
  discussions we lacked. That's the main point of RTC. Isn't it
  funny
  that you've mentioned it as an argument against RTC?
 
  What's wrong with committing changes made in the branch back to
  trunk
  once they've been tested? My proposal is not to wait until the
  migration is done, but rather apply it in small portions,
  gradually.
  It should work, shouldn't it? I'd greatly appreciate your
 comment
  on
  it as I guess I don't see the whole picture and keep thinking
 the
  branch might help when others have already seen it would fall
  short.
 
  Can we avoid the concerns that have been aired regarding svn
  merging issues when directories are reorganised by leaving the
  reorganization of directories as a last phase of the m2
 migration?
 
  I would have thought that we could move further along with the
  migration without reorganizing directories (AFAIK, maven should
 be
 
  able to work with existing directory structures, although doing
 so
 
  may incur more work).  We would also need to coordinate the
  reorganization of directories with the owners of other branches
  from trunk, to minimize the impact on them.
 
  I would prefer to wait to reorganize the directories until after
 the
 
  work in the dead-1.2 branch is merged with trunk.  I plan to go
 back
 
  to this activity now.  Other committers may wish to note that
 merging
 
  the work in dead-1.2 should not need RTC as it is already part of
 a
  main development line.
 
  thanks
  david jencks
 
 
  John
  --jason
 
  Jacek
 
 
 
 
 
 
  __
  Do You Yahoo!?
  Tired of spam?  Yahoo! Mail has the best spam protection around
  http://mail.yahoo.com
 
 


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

Re: Additions to the Apache Geronimo project management ctte

Congratulations! Matt and Jeff

Cheers
Anita

--- Dain Sundstrom [EMAIL PROTECTED] wrote:

 On Jul 5, 2006, at 1:32 PM, Rodent of Unusual Size wrote:
 
  Last week the PMC voted to invite Jeff Genender and
  Matt Hogstrom to join it.  Both have accepted the
  invitation and will be part of the team responsible
  for overseeing the healthy development of the project.
 
  Welcome, Matt  Jeff!
  - --
  #kenP-)}
 
 Congratulation!
 
 -dain
 
 
 


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

Re: OSCON Geronimo BOF Scheduled

2006-07-06 Thread Jan Bartel


Matt,

I'll be there. I seem to be becoming a conference addict :-)

cheers
Jan

Matt Hogstrom wrote:
For those committers that will be at the OSCON Conference we have a BOF 
scheduled.  It is:


Your BoF for OSCON 2006 has been scheduled for:

•  Wednesday, July 26
•  7:30 pm - 8:30 pm
•  Location:  D139-140
•  BoF Name:  New Features of Apache Geronimo 1.1 (including new plug-in 
capability)


Who all will be at OSCON?

Re: Additions to the Apache Geronimo project management ctte


Cool ! Congrats guys !

Cheers
Prasad

On 7/6/06, anita kulshreshtha [EMAIL PROTECTED] wrote:

Congratulations! Matt and Jeff

Cheers
Anita

--- Dain Sundstrom [EMAIL PROTECTED] wrote:

 On Jul 5, 2006, at 1:32 PM, Rodent of Unusual Size wrote:

  Last week the PMC voted to invite Jeff Genender and
  Matt Hogstrom to join it.  Both have accepted the
  invitation and will be part of the team responsible
  for overseeing the healthy development of the project.
 
  Welcome, Matt  Jeff!
  - --
  #kenP-)}

 Congratulation!

 -dain





__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

AMQ production status

2006-07-06 Thread Naveen Rawat



Hi James 



We have our servers in C/C++. We are trying out available open source MQ 
services for maintaining persistent communication with our servers through 
our C++ and web clients. 

We tried the tests available for both Stomp and Openwire and got very little 
success with Stomp C++ (caught up with the persistency issue) and 
considerable with openwire C++ (I have an issue regarding this mailed to the 
mailing list on 06-July-2006). 

1) Are both these C++ APIs (Stomp and Openwire) worth implementation and 
usage right now, or they are being made more ROBUST? 

2) When can we see a PRODUCTION-able AMQ along with its full throttled APIs? 





Hearty Regards
Naveen Rawat

[jira] Commented: (GERONIMO-2066) Openejb migration to M2

2006-07-06 Thread Anita Kulshreshtha (JIRA)

[ 
http://issues.apache.org/jira/browse/GERONIMO-2066?page=comments#action_12419493
 ] 

Anita Kulshreshtha commented on GERONIMO-2066:
--

Oops! I named it openejb.patch. Use the latest patch. These patches are 
deceptive. The openejb builds even without them. When the jars are used to 
build Geronimo configs, the build fails. Prasad has been unable to build 
openejb configuraitons. This will be very helpful. Thanks! 
I think Jason has submitted a patch For G to use org.openejb groupId. This 
patch is a bug fix now. Because there is no 2.2 openejb with groupId openejb. 

 Openejb migration to M2
 ---

  Key: GERONIMO-2066
  URL: http://issues.apache.org/jira/browse/GERONIMO-2066
  Project: Geronimo
 Type: Sub-task
 Security: public(Regular issues) 
  Environment: All
 Reporter: Anita Kulshreshtha
  Attachments: openejb.patch, openejb.patch, openejb.patch, openejb.patch

 The attached patch provides a local openejb build for Geronimo using 
 o.a.g.modules groupId. 
 This is to ensure that the latest openejb jars are available. The results for 
 rev 2659 are below :
 Path: .
 URL: https://svn.codehaus.org/openejb/branches/v2_1/openejb2
 Repository UUID: 2b0c1533-c60b-0410-b8bd-89f67432e5c6
 Revision: 2659
 Node Kind: directory
 Schedule: normal
 Last Changed Author: gdamour
 Last Changed Rev: 2659
 Last Changed Date: 2006-05-27 08:00:16 -0400 (Sat, 27 May 2006)
 Properties Last Updated: 2006-05-26 19:05:28 -0400 (Fri, 26 May 2006)
 Todo - fix the test failures.
 
 
 APSHOT\openejb-builder-2.1-SNAPSHOT.jar
 [INFO]
 [INFO]
 [INFO] 
 
 [INFO] Reactor Summary:
 [INFO] 
 
 [INFO] OpenEJB  SUCCESS 
 [3.953s]
 [INFO] OpenEJB :: Core  SUCCESS 
 [30.515s]
 [INFO] OpenEJB :: PK Generation :: Builder  SUCCESS 
 [9.297s]
 [INFO] OpenEJB :: Builder . SUCCESS 
 [27.875s]
 [INFO] 
 
 [INFO] 
 
 [INFO] BUILD SUCCESSFUL
 [INFO] 
 
 [INFO] Total time: 1 minute 12 seconds
 [INFO] Finished at: Mon May 29 08:11:40 EDT 2006
 [INFO] Final Memory: 17M/53M
 [INFO] 
 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

RE: AMQ production status

2006-07-06 Thread Mittler, Nathan

Hi Naveen,
Comments inline ...

 -Original Message-
 From: Naveen Rawat [mailto:[EMAIL PROTECTED] 
 Sent: Thursday, July 06, 2006 7:48 AM
 To: activemq-dev@geronimo.apache.org
 Subject: AMQ production status

 Hi James 

 We have our servers in C/C++. We are trying out available 
 open source MQ services for maintaining persistent 
 communication with our servers through our C++ and web clients. 

 We tried the tests available for both Stomp and Openwire and 
 got very little success with Stomp C++ (caught up with the 
 persistency issue) and considerable with openwire C++ (I have 
 an issue regarding this mailed to the mailing list on 06-July-2006). 

Just out of curiosity, which Stomp C++ client did you try?  The reason I
ask is that we just submitted a replacement for the CMS client in
activemq-cpp. This API does appear to have support for persistence,
although I'm not sure that we have a unit test that verifies it yet.

 1) Are both these C++ APIs (Stomp and Openwire) worth 
 implementation and usage right now, or they are being made 
 more ROBUST? 

The activemq-cpp is new and will be the beginning of creating a single
C++ client that will support both stomp and openwire (you will be able
to choose which protocol in the url).  So, there is definitely activity
in this area and they should continue to improve.

 2) When can we see a PRODUCTION-able AMQ along with its full 
 throttled APIs? 

I would try activemq-cpp, if you haven't already - it's leaps and bounds
above the old CMS code!

 Hearty Regards
 Naveen Rawat

Regards,
Nate

Re: [jira] Updated: (GERONIMO-2161) [RTC] Remove Geronimo modules from dependencyManagement in root pom.xml

Please ignore this.. (hit send accidentally)

Anita

--- anita kulshreshtha [EMAIL PROTECTED] wrote:

 
 
 --- Jason Dillon [EMAIL PROTECTED] wrote:
 
  What user friendliness are you talking about?
  
  --jason
  
  
  On Jul 5, 2006, at 2:25 AM, anita kulshreshtha wrote:
  
  I would also prefer to see any changes to improve the
   maintainability  and user friendliness of M2 build be held off
  until
   the server assembly is functional.
  
   Thanks
   Anita
  
   --- David Jencks [EMAIL PROTECTED] wrote:
  
  
   On Jul 5, 2006, at 12:25 AM, John Sisson wrote:
  
   Jacek Laskowski wrote:
   On 7/3/06, Jason Dillon [EMAIL PROTECTED] wrote:
   NOTE... the m2 build in trunk is already broken... this
 patches
   help
   FIX MANY OF THOSE PROBLEMS!
  
   NOTED, but... it's not broken. it has never worked so we can
   pretend
   to call it broken. It's a small, but important point we cannot
   dismiss.
  
   Since the official build is still m1 and this will not affect
  the
   m1
   build, I don't see why your point about breakage is
 applicable
  at
  
   all.
   ...
   When I first created the m1 build for Geronimo years ago
 there
   were
   certainly a few moments of breakage due to build changes, but
   since
   there was no commit by committee junk going on then it was
 easy
   to
   just fix when things happened to get a bit askew.
  
   The branch idea was just to make it easier to actually make
   progress,
   as I am move on this stuff way way faster than the lot of you
  can
   react to emails and JIRAs which often (as this one did) need
   several
   sets of emails to clarify.
  
   That's the point in RTC - discussing, discussing, over and
 over
   again.
   I'm not in favour of RTC, but some of its rules are fine. It
   fosters
   discussions we lacked. That's the main point of RTC. Isn't it
   funny
   that you've mentioned it as an argument against RTC?
  
   What's wrong with committing changes made in the branch back
 to
   trunk
   once they've been tested? My proposal is not to wait until the
   migration is done, but rather apply it in small portions,
   gradually.
   It should work, shouldn't it? I'd greatly appreciate your
  comment
   on
   it as I guess I don't see the whole picture and keep thinking
  the
   branch might help when others have already seen it would fall
   short.
  
   Can we avoid the concerns that have been aired regarding svn
   merging issues when directories are reorganised by leaving the
   reorganization of directories as a last phase of the m2
  migration?
  
   I would have thought that we could move further along with the
   migration without reorganizing directories (AFAIK, maven should
  be
  
   able to work with existing directory structures, although doing
  so
  
   may incur more work).  We would also need to coordinate the
   reorganization of directories with the owners of other branches
   from trunk, to minimize the impact on them.
  
   I would prefer to wait to reorganize the directories until after
  the
  
   work in the dead-1.2 branch is merged with trunk.  I plan to go
  back
  
   to this activity now.  Other committers may wish to note that
  merging
  
   the work in dead-1.2 should not need RTC as it is already part
 of
  a
   main development line.
  
   thanks
   david jencks
  
  
   John
   --jason
  
   Jacek
  
  
  
  
  
  
   __
   Do You Yahoo!?
   Tired of spam?  Yahoo! Mail has the best spam protection around
   http://mail.yahoo.com
  
  
 
 
 __
 Do You Yahoo!?
 Tired of spam?  Yahoo! Mail has the best spam protection around 
 http://mail.yahoo.com 
 


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

Re: Errors while using Geronimo Eclipse Plugin RC2

2006-07-06 Thread Shiva Kumar H R

Hi Sachin,I tried using WTP 1.5 and Eclipse 3.2. The problems mentioned earlier disappear and I am able to start/stop the server successfully.However after the server gets started, when I right click on the server, I see that Launch Geronimo Console is disabled. 
Isn't this a bug? Shall I open a JIRA for the same?I also observed that the .log file in my eclipse\workspace\.metadata directory has the following messages logged. 
Do you suspect any problem here?--!SESSION 2006-07-06 17:50:
17.529 ---eclipse.buildId=M20060629-1905java.version=1.4.2_08java.vendor=Sun Microsystems Inc.BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en_USCommand-line arguments: -os win32 -ws win32 -arch x86 -clean
!ENTRY org.eclipse.emf.ecore 2 0 2006-07-06 17:50:41.524!MESSAGE Both 'org.apache.geronimo.deployment.model' and 'org.apache.geronimo.v11.deployment.model' register an extension parser for 'deployment'
!ENTRY org.eclipse.emf.ecore 2 0 2006-07-06 17:50:41.524!MESSAGE Both 'org.apache.geronimo.deployment.model' and 'org.apache.geronimo.v11.deployment.model' register an extension parser for 'naming'!ENTRY org.eclipse.emf.ecore
 2 0 2006-07-06 17:50:41.534!MESSAGE Both 'org.apache.geronimo.deployment.model' and 'org.apache.geronimo.v11.deployment.model' register an extension parser for 'web'--
- Shiva KumarOn 7/5/06, Sachin Patel [EMAIL PROTECTED] wrote:
Can you retry using the callisto release (WTP 1.5, and Eclipse 3.2)?This is what the plugin is built on and supports.On Jul 5, 2006, at 9:05 AM, Shiva Kumar H R wrote: Hi, I am using 
http://people.apache.org/dist/geronimo/eclipse/unstable/ g-eclipse-plugin-1.1-RC2.zip with Eclipse 3.1.2 and WTP 1.0.2 (buildwtp-sdk-R-1.0.2-200604200208). 1) While defining a New Server, during this dialog New Apache
 Geronimo v1.1 Runtime: Please enter the directory where Geronimo is currently installed or where you would like it to be installed. as shown in attachment  1.GIF, once I specify the Application
 Server Installation Directory, the upper portion of the Dialog gets reduced in size leaving me unable to see the message/info there, as shown in attachment 2.GIF . Although this doesn't stop
 me from defining a new server, I miss out on the information which was displayed during that dialog. 2) After defining the server (I have the following server installed: Geronimo 1.1
 with Jetty with Sun JDK 1.4.2_08), when I try to start the server, server does get started with the below messages in Console view: --
 - ... 18:22:49,519 DEBUG [GBeanSingleReference] Waiting to start geronimo/ remote-deploy-jetty/1.1/car?J2EEApplication=null,WebModule=geronimo/
 remote-deploy-jetty/1.1/car,j2eeType=Servlet,name=jsp because no targets are running for reference JettyServletRegistration matching the patterns geronimo/remote-deploy-jetty/1.1/car? J2EEApplication=null,j2eeType=WebModule,name=geronimo/remote-deploy-
 jetty/1.1/car 18:22:49,649 DEBUG [GBeanSingleReference] Waiting to start geronimo/ remote-deploy-jetty/1.1/car?J2EEApplication=null,WebModule=geronimo/ remote-deploy-jetty/1.1/car,j2eeType=Servlet,name=file-upload
 because no targets are running for reference Previous matching the patterns geronimo/remote-deploy-jetty/1.1/car? J2EEApplication=null,WebModule=geronimo/remote-deploy-jetty/1.1/ car,j2eeType=Servlet,name=404-error
 Geronimo startup complete -- - However the Servers view still shows the server status as
 Starting.. as shown in attachment  3.GIF. And after a while, an Error message Timeout waiting for Apache Geronimo 1.1 to start. Server did not start after 24s. (as shown in attachment
 4.GIF) gets thrown. The .log file in eclipse\workspace \.metadata directory has the following messages logged: --
 - !SESSION 2006-07-05 17:53:56.827 --- eclipse.buildId=M20060118-1600 java.version=1.4.2_08
 java.vendor=Sun Microsystems Inc. BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en_US Command-line arguments:-os win32 -ws win32 -arch x86 !ENTRY org.eclipse.wst.server.core
 4 0 2006-07-05 18:26:00.293 !MESSAGE Timeout waiting for Apache Geronimo 1.1 to start. Server did not start after 24s. --
 - - Shiva Kumar 1.GIF 2.GIF 3.GIF 4.GIF-sachin

Fwd: Errors while using Geronimo Eclipse Plugin RC2

2006-07-06 Thread Shiva Kumar H R

I intended to send my first mail to dev@geronimo.apache.org and copy 
user@geronimo.apache.org on the CC list. But mistakenly I CC'ed it to [EMAIL PROTECTED]. After that, I see some mails getting missed from the user list. I am sorry for the confusion caused. Now sending this mail to both dev  user lists.
Thx,Shiva Kumar-- Forwarded message --From: Shiva Kumar H R [EMAIL PROTECTED]
Date: Jul 6, 2006 5:58 PMSubject: Re: Errors while using Geronimo Eclipse Plugin RC2To: dev@geronimo.apache.orgHi Sachin,I tried using WTP 1.5
 and Eclipse 3.2. The problems mentioned earlier disappear and I am able to start/stop the server successfully.However after the server gets started, when I right click on the server, I see that Launch Geronimo Console is disabled. 
Isn't this a bug? Shall I open a JIRA for the same?I also observed that the .log file in my eclipse\workspace\.metadata directory has the following messages logged. 
Do you suspect any problem here?--!SESSION 2006-07-06 17:50:
17.529 ---eclipse.buildId=M20060629-1905java.version=1.4.2_08java.vendor=Sun Microsystems Inc.BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en_US
Command-line arguments: -os win32 -ws win32 -arch x86 -clean
!ENTRY org.eclipse.emf.ecore 2 0 2006-07-06 17:50:41.524!MESSAGE Both 'org.apache.geronimo.deployment.model' and 'org.apache.geronimo.v11.deployment.model' register an extension parser for 'deployment'

!ENTRY org.eclipse.emf.ecore 2 0 2006-07-06 17:50:41.524!MESSAGE Both 'org.apache.geronimo.deployment.model' and 'org.apache.geronimo.v11.deployment.model' register an extension parser for 'naming'!ENTRY org.eclipse.emf.ecore

 2 0 2006-07-06 17:50:41.534!MESSAGE Both 'org.apache.geronimo.deployment.model' and 'org.apache.geronimo.v11.deployment.model' register an extension parser for 'web'--
- Shiva KumarOn 7/5/06, Sachin Patel 
[EMAIL PROTECTED] wrote:
Can you retry using the callisto release (WTP 1.5, and Eclipse 3.2)?This is what the plugin is built on and supports.On Jul 5, 2006, at 9:05 AM, Shiva Kumar H R wrote: Hi, I am using 

http://people.apache.org/dist/geronimo/eclipse/unstable/ g-eclipse-plugin-1.1-RC2.zip with Eclipse 3.1.2 and WTP 1.0.2 (buildwtp-sdk-R-1.0.2-200604200208). 1) While defining a New Server, during this dialog New Apache
 Geronimo v1.1 Runtime: Please enter the directory where Geronimo is currently installed or where you would like it to be installed. as shown in attachment  1.GIF, once I specify the Application
 Server Installation Directory, the upper portion of the Dialog gets reduced in size leaving me unable to see the message/info there, as shown in attachment 2.GIF . Although this doesn't stop
 me from defining a new server, I miss out on the information which was displayed during that dialog. 2) After defining the server (I have the following server installed: Geronimo 
1.1
 with Jetty with Sun JDK 1.4.2_08), when I try to start the server, server does get started with the below messages in Console view: --
 - ... 18:22:49,519 DEBUG [GBeanSingleReference] Waiting to start geronimo/ remote-deploy-jetty/1.1/car?J2EEApplication=null,WebModule=geronimo/
 remote-deploy-jetty/1.1/car,j2eeType=Servlet,name=jsp because no targets are running for reference JettyServletRegistration matching the patterns geronimo/remote-deploy-jetty/1.1/car? J2EEApplication=null,j2eeType=WebModule,name=geronimo/remote-deploy-
 jetty/1.1/car 18:22:49,649 DEBUG [GBeanSingleReference] Waiting to start geronimo/ remote-deploy-jetty/1.1/car?J2EEApplication=null,WebModule=geronimo/ remote-deploy-jetty/1.1/car,j2eeType=Servlet,name=file-upload
 because no targets are running for reference Previous matching the patterns geronimo/remote-deploy-jetty/1.1/car? J2EEApplication=null,WebModule=geronimo/remote-deploy-jetty/1.1/ car,j2eeType=Servlet,name=404-error
 Geronimo startup complete -- - However the Servers view still shows the server status as
 Starting.. as shown in attachment  3.GIF. And after a while, an Error message Timeout waiting for Apache Geronimo 1.1 to start. Server did not start after 24s. (as shown in attachment
 4.GIF) gets thrown. The .log file in eclipse\workspace \.metadata directory has the following messages logged: --
 - !SESSION 2006-07-05 17:53:56.827 ---

Re: Implementing Global JNDI

2006-07-06 Thread Krishnakumar B


Hi David,

I tried this and it works for Custom Resource Adapters. There is still
a problem for Registering GBeans in Global JNDI through the builder (
ServiceConfigBuilder ). The Builder is a part of
geronimo-gbean-deployer plan which is parent of j2ee-deployer.  The
geronimo-naming jars are loaded in j2ee-deployer. Hence we dont get
access in ServiceConfigBuilder to GBeanReference thats part of naming.

Currently all the binding GBeans are in naming package. So it works
for all j2ee deployments.

Is there a way to work around this ClassLoading problem heirarchy for
binding GBeans through builder?

Regards
Krishnakumar


On 6/28/06, David Jencks [EMAIL PROTECTED] wrote:


I think there is a simpler solution, or perhaps I don't understand all the
details of what you are proposing.  I think if you give your binding gbeans
the magic classLoader attribute everything will work.  This will be set to
the configuration classloader for the configuration the gbean is in, not the
configuration the gbeans class is loaded in.  This classloader should always
have the necessary classes in it.

thanks
david jencks


On Jun 28, 2006, at 12:39 AM, Manu George wrote:
Hi,
 The problem we are facing regarding adapters is because the binding
gbeans were added to the naming module of geronimo. We are planning to
change this by creating a separate module for global jndi and then adding it
as a dependency in the configuration that is getting deployed. This will be
done in the builders.  All the reference creation logic can also be moved to
the gbeans.The Binding GBeans will then have access to application level
classes as they will be loaded in the app class loader.  We hope this
approach will solve the current problem.  We will post the code again after
making these changes.

Thanks
Manu

On 6/28/06, Krishnakumar B [EMAIL PROTECTED] wrote:
 Hi,

 We have created  a JIRA
 (http://issues.apache.org/jira/browse/GERONIMO-2153  )
and attached
 the initial draft. We have tried two approaches.

 * Adding to plan
 * Deploying from Builder.

 The EJBJNDIBindingGBean deploys from OpenEJBModuleBuilder and has a tag
   global-jndi/ in opene ejb plan.

 Resource Adapter and GBean have a gbean plan added to deployment plan.

 gbean name=JMSQueueFactoryJNDIBindingGBean

class=org.apache.geronimo.connector.jndi.ConnectorJNDIBindingGBean
 attribute
name=configIdtest/jms.rar/1.0/rar/attribute
 attribute
name=jndiNameglobalJMSQueueFactory/attribute
 attribute
name=componentNameJMSQueueFactory/attribute
 attribute
name=j2eeTypeJCAManagedConnectionFactory/attribute
 attribute
name=interfaceNameorg.apache.geronimo.jms.connector.JMSQueueConnectionFactory/attribute
 /gbean

 and

 gbean name=TestGBeanJNDIBindingGBean

class=org.apache.geronimo.service.jndi.ServiceJNDIBindingGBean
 attribute name=configIdtest/gbean/1.0/car/attribute
 attribute name=jndiNameglobalTestGBean/attribute
 attribute name=componentNameTestGBean/attribute
 attribute name=j2eeTypeGBean/attribute
 attribute name=classNamegbean.test.TestGBean/attribute
 /gbean

 We have a Classloading issue when trying to maintain all the
 BindingGbeans at one level. ( rmi-naming ). For GBeans and Resource
 Adapters that are not J2EE interfaces like javax.sql.DataSource /
 javax.jms.QueueConnectionFactory we get a ClassNotFound
as the class
 is not available at Classloader of rmi-naming.

 We spent a lot of time trying to solve this issue but are not able to
 find a solution as the application level interface or class is not
 available. This problem will not occur for j2ee interfaces like
 DataSource, EJB interfaces, Queue, Topic etc..

 If the approach is correct we would like to add the other features to
 make this more suitable for adding into the product.

 Regards
 Krishnakumar B


 On 6/26/06, Jacek Laskowski [EMAIL PROTECTED] wrote:
  On 6/23/06, Krishnakumar B  [EMAIL PROTECTED] wrote:
 
   The plan needs to have some XML Tag to say this resource needs to gets
   into Global JNDI and the builder can then add it to geronimo: Context.
   This is not implemented yet. Currently if we deploy a connector it
   gets in global jndi.
 
  I might've misunderstood it, but isn't Global JNDI == geronimo:
  context == global: context? If so, why is this copying from Global
  JNDI to the geronimo: namespace?
 
  Looking forward to seeing your patch for it. Just as Guillaume
  suggested, please create an JIRA issue and attach the patch to it.
 
   Krishnakumar B
 
  Jacek
 
  --
  Jacek Laskowski
  http://www.laskowski.net.pl

[jira] Created: (AMQ-798) provide a new JMS header to indiciate the first message in a sequence being dispatched to a consumer

2006-07-06 Thread james strachan (JIRA)

provide a new JMS header to indiciate the first message in a sequence being 
dispatched to a consumer


 Key: AMQ-798
 URL: https://issues.apache.org/activemq/browse/AMQ-798
 Project: ActiveMQ
Type: New Feature

Reporter: james strachan
 Assigned to: james strachan 


This would allow consumers to listen for this message and if the boolean is set 
its the first message being dispatched for a group  so the consumer could 
flush a cache or something

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: How do we build the Eclipse Plugin assembly?

2006-07-06 Thread Shiva Kumar H R

Hi Sachin,Thanks for pointing out those areas where I can start contributing. I will look at the code for Form page editors for deployment plans and Wizards. I will start a separate discussion thread on them. Meanwhile I will also see if I can fix some of the JIRAs in GeronimoDevtools.
- ShivaOn 7/5/06, Sachin Patel [EMAIL PROTECTED] wrote:
Hi Shiva,On Jul 3, 2006, at 2:56 AM, Shiva Kumar H R wrote: Hi Sachin, I too am facing the same problem as Donald during the assembly of Eclipse Plugin. I am building Revision 418691 of the trunk, using
Sun JDK 1.4.2_08 Maven 2.0.4 on a WinXP sp2 machine.Ok, I'll see if I can reproduce on another machine and dig into it. By the way, I am interested in contributing to Geronimo Eclipse
Plugin. Last year I have done some work on Eclipse Plugin Development and I am comfortable with SWT, JFace and Plugin Development. Also, some of the work I did in Eclipse Drag and Drop got published here:
http://www-128.ibm.com/developerworks/library/ os-ecl-dragdrop/index.htmlGreat! SWT and JFace experience is definitely something we coulduse.So one of the big things we need coverage on is providing Form
Page editors for our deployment plans.Currently if you double clickfor example on the geronimo-web.xml it will open up a form editor.You will see that the coverage is currently very minimal and due tomy lack of UI creativity many of the tables and such look exactly the
same. :)The wizards are also very primative and we desperately needto enhance these.So if you're interested this would be a greatplace to contribute.This would also help you get a goodunderstanding of each of the geronimo deployment plans.
Last one week I have been browsing through the Geronimo Dev Mailing Lists, as well as JIRA, to figure out how I can contribute to the Eclipse plugin development. If you can point me to a few to-do
items of immediate interest, I would be more than happy to pick them up and start working on them right away. Thanks, Shiva Kumar On 7/1/06, Sachin Patel
[EMAIL PROTECTED] wrote: You have to invoke it manually as you've done.I haven't figured out how to invoke a build+assembly in one step.As far as the file sizes kevan saw the same problem, and we couldn't figure out why.
On Jun 30, 2006, at 5:15 PM, Donald Woods wrote: I just checked out Rev418113 of the Eclipse plugin trunk, started with a clean m2 repo and successfully got a mvn install to
complete after several attempts. But, when I look in the assembly/ directory, no target/ directory was created.Is this expected? When I ran mvn from the assembly directory, it created a target
directory, but the following zipfiles were only 22 bytes each - g-eclipse-plugin-1.1-deployable.zip g-eclipse-plugin-1.1-updatesite.zip I'm building on WinXP with Maven
2.0.4 and Sun Java 1.4.2_12-b03.-Donald -sachin-sachin-- Thanks,
Shiva Kumar

RE: AMQ production status

2006-07-06 Thread Naveen Rawat



Hi Nate 

Thanks for the information. 




Just out of curiosity, which Stomp C++ client did you try?  The reason I
ask is that we just submitted a replacement for the CMS client in
activemq-cpp. This API does appear to have support for persistence,
although I'm not sure that we have a unit test that verifies it yet.


We are using the main.cpp file that comes in /test along with the Stomp C++ 
APIs from svn : 
https://svn.apache.org/repos/asf/incubator/activemq/trunk/cms. We have 
segregated the main.cpp into a sender and a receiver. 

1) From where can I get the fresh CMS replacement as told by you. Can you 
provide the specific location? 




I would try activemq-cpp, if you haven't already - it's leaps and bounds
above the old CMS code!


2) I am using ActiveMQ 4.0.x java version. Is activemq-cpp a C++ MQ server? 
If, then what's its capacity against Java, .Net clients. 





Hearty Regards
Naveen Rawat

RE: AMQ production status

2006-07-06 Thread Bish, Tim

Comments inline:

 
 Just out of curiosity, which Stomp C++ client did you try?  The
reason I
 ask is that we just submitted a replacement for the CMS client in
 activemq-cpp. This API does appear to have support for persistence,
 although I'm not sure that we have a unit test that verifies it yet.
 
 We are using the main.cpp file that comes in /test along with the
Stomp
 C++
 APIs from svn :
 https://svn.apache.org/repos/asf/incubator/activemq/trunk/cms. We have
 segregated the main.cpp into a sender and a receiver.
 
 1) From where can I get the fresh CMS replacement as told by you. Can
you
 provide the specific location?

The CMS replacement is called activemq-cpp and its located here:
https://svn.apache.org/repos/asf/incubator/activemq/trunk/activemq-cpp

It is still under active development by Nathan and me.

 
 
 I would try activemq-cpp, if you haven't already - it's leaps and
bounds
 above the old CMS code!
 
 2) I am using ActiveMQ 4.0.x java version. Is activemq-cpp a C++ MQ
 server?
 If, then what's its capacity against Java, .Net clients.

Activemq-cpp is a c++ implementation of the JMS Client API, currently it
only speaks the stomp protocol, but in time it should also gain the
ability to use the openwire protocol as well.  You still need to run an
AMQ broker just as you did before.

The tests in the test-integration folder show example usage, which is
now very much like using the Java based JMS client API.


-
Timothy A. Bish
Sensis Corporation
-

[RTC] Vote on GERONIMO-2161 - restart 1

2006-07-06 Thread Matt Hogstrom

+1 to getting this patch in...

I spent some time working with Jason and Jacek last night on this patch. It is fairly large and
reaching. There appears to be an issue with SVN creating a bad patch file for several files but I
don't believe this is Jason's issue but rather with SVN.

There are 5 failed hunks in the v5 patch. I manually copied the files from branches/m2migration
into trunk as these were the source of the modification. The build was successful and I understand
what Jason is doing here.

I am giving this patch a +1 and would like to see Jason get this applied at his
earliest convenience.

There are issues with moving forward but getting on a better code base will accelerate progress on
getting to a fully integrated build.

We need to understand why SVN is creating bad patches but this shouldn't hold up the migration to M2
effort. This is not an issue with the current patch but a problem with SVN we need to undestand.

I would like to see Jason get these changes into trunk as well as resolve the
patch issue.

Matt

*** Notations of applicability ***

Here is the output from the patch when I applied it. I increased the FUZZ factor to a horrible 8
but it had no effect.

hogstrom:~/dev/geronimo/trunk hogstrom$ patch -p0 -l
~/Downloads/GERONIMO-2161-v5.patch.txt
patching file applications/ldap-realm-demo/pom.xml
Hunk #1 succeeded at 17 with fuzz 2.
patching file applications/console/console-standard/pom.xml
Hunk #1 succeeded at 17 with fuzz 2.
patching file applications/console/console-ear/pom.xml
Hunk #1 succeeded at 17 with fuzz 2.
patching file applications/console/console-core/pom.xml
Hunk #1 succeeded at 17 with fuzz 2.
patching file applications/console/pom.xml
Hunk #1 succeeded at 17 with fuzz 2.
patching file applications/console/console-framework/pom.xml
Hunk #1 succeeded at 17 with fuzz 2.
patching file applications/magicGball/magicGball-ejb/pom.xml
Hunk #1 succeeded at 17 with fuzz 2.
patching file applications/magicGball/magicGball-ear/pom.xml
Hunk #1 succeeded at 17 with fuzz 2.
patching file applications/magicGball/pom.xml
Hunk #1 succeeded at 17 with fuzz 2.
patching file applications/magicGball/magicGball-web/pom.xml
Hunk #1 succeeded at 17 with fuzz 2.
patching file applications/magicGball/magicGball-client/pom.xml
Hunk #1 succeeded at 17 with fuzz 2.
patching file applications/demo/pom.xml
Hunk #1 succeeded at 17 with fuzz 2.
patching file applications/remote-deploy/pom.xml
Hunk #1 succeeded at 17 with fuzz 2.
patching file applications/uddi-db/pom.xml
Hunk #1 succeeded at 17 with fuzz 2.
patching file applications/uddi-server/pom.xml
Hunk #1 succeeded at 17 with fuzz 2.
patching file applications/pom.xml
Hunk #1 succeeded at 17 with fuzz 2.
patching file applications/welcome/pom.xml
Hunk #1 succeeded at 17 with fuzz 2.
patching file configs/unavailable-client-deployer/pom.xml
patching file configs/welcome-tomcat/pom.xml
patching file configs/client-security/pom.xml
patching file configs/javamail/pom.xml
patching file configs/console-tomcat/pom.xml
Hunk #1 succeeded at 16 with fuzz 3.
patching file configs/tomcat/pom.xml
patching file configs/j2ee-server/pom.xml
patching file configs/pom.xml
Hunk #1 succeeded at 17 with fuzz 2.
patching file configs/activemq-broker/pom.xml
Hunk #1 succeeded at 16 with fuzz 3.
patching file configs/jsp-examples-tomcat/pom.xml
patching file configs/sharedlib/pom.xml
patching file configs/jetty/pom.xml
patching file configs/console-jetty/pom.xml
patching file configs/client-system/pom.xml
patching file configs/unavailable-ejb-deployer/pom.xml
patching file configs/openejb-deployer/pom.xml
patching file configs/directory/pom.xml
patching file configs/jsp-examples-jetty/pom.xml
patching file configs/online-deployer/pom.xml
patching file configs/j2ee-deployer/pom.xml
patching file configs/tomcat-deployer/pom.xml
patching file configs/activemq/pom.xml
Hunk #1 succeeded at 16 with fuzz 3.
patching file configs/geronimo-gbean-deployer/pom.xml
patching file configs/shutdown/pom.xml
patching file configs/hot-deployer/pom.xml
patching file configs/servlets-examples-jetty/pom.xml
patching file configs/jetty-deployer/pom.xml
patching file configs/openejb/pom.xml
patching file configs/unavailable-webservices-deployer/pom.xml
patching file configs/axis-deployer/pom.xml
patching file configs/system-database/pom.xml
patching file configs/ldap-demo-tomcat/pom.xml
patching file configs/upgrade/pom.xml
patching file configs/welcome-jetty/pom.xml
patching file configs/j2ee-security/pom.xml
patching file configs/upgrade-cli/pom.xml
patching file configs/rmi-naming/pom.xml
patching file configs/ldap-demo-jetty/pom.xml
patching file configs/client-deployer/pom.xml
patching file configs/client-corba/src/plan/plan.xml
Hunk #2 succeeded at 17 with fuzz 2.
patching file configs/client-corba/pom.xml
patching file configs/axis/pom.xml
Hunk #1 succeeded at 16 with fuzz 3.
patching file configs/j2ee-system/pom.xml
patching file

Re: openejb itests?

2006-07-06 Thread Bill Dudney


Hi Prasad,



First we needed the geronimo-deployment-plugin to be in m2. So in
http://issues.apache.org/jira/browse/GERONIMO-1738, I got the
deployment-plugin migarted to m2. The RTC for this is pending 2 more
votes. Now, if you and Jason can review and approve it, we can get it
in the build.



I applied the patch but it appears that there is a problem with it,  
AppTest.java has 3 copies of the code in it for example (as well as  
pom.xml and many if not all the other files).


 Here is the url to what I downloaded and I'm looking at;
http://issues.apache.org/jira/secure/attachment/12324416/geronimo- 
deployment-plugin.patch


which is the first patch from JIRA #1738 referenced above.


Next, I came up with a simple m2 multi-build project for itests.
Jacek put it in the sandbox for us.
http://issues.apache.org/jira/browse/GERONIMO-1654.

(I think I also opened some JIRAs in OpenEJB project with itest
patches. Let me search for those).



Sounds good, looking forward to reviewing the jira's.


I used to take an m1 binary distribution and manually put it into an
m2 local repo for this work. Now that we are working on m2, hopefully
we shall soon have the binary distributions for us to work with
directly.



An m1 distribution of G or something else?

We could then to try to bring itests out of the sandbox and merge  
it with trunk.


The vision I have for itests is to make it the all encompassing system
integration test for Geronimo. We have unit tests in the individual
modules. Even that covers only a third of our code approx. Then we
have the J2EE CTK tests that ensures G's J2EE compliance.  But
geronimo being a sum of many individual parts, there must be a whole
range of tests that are applicable to the whole system when put
together but fall beyond the purview of CTK. These are what I hope
itests will catch.



Agreed that having more tests would be a very 'good thing'


I began playing with itests but quickly moved on the m2 migration work
since that was so much necessary both for G and for itests. It would
be nice to get the itests running and into the project soon.



agreed

TTFN,

-bd-


Cheers
Prasad.

On 7/5/06, Bill Dudney [EMAIL PROTECTED] wrote:


Hi Prasad,

I would like to see the itests for openejb running from m2. David  
mentioned
that you might have already done a bunch of work on that front.  
Could you
update me on the status of that? I'm happy to jump in where ever  
to help

make them functional again.

Thanks!


Bill Dudney
MyFaces - http://myfaces.apache.org
Cayenne - http://incubator.apache.org/projects/cayenne.html

Re: Errors while using Geronimo Eclipse Plugin RC2



On Jul 6, 2006, at 8:28 AM, Shiva Kumar H R wrote:


Hi Sachin,
I tried using WTP 1.5 and Eclipse 3.2. The problems mentioned  
earlier disappear and I am able to start/stop the server successfully.


However after the server gets started, when I right click on the  
server, I see that Launch Geronimo Console is disabled. Isn't  
this a bug? Shall I open a JIRA for the same?


Yes, I noticed this as well, please open a JIRA.



I also observed that the .log file in my eclipse\workspace 
\.metadata directory has the following messages logged. Do you  
suspect any problem here?


No this is ok and just a warning.  I can't remove the duplicate  
extensions because they are being inserted automatically by EMF  
during the build.


-- 

!SESSION 2006-07-06 17:50: 17.529  
---

eclipse.buildId=M20060629-1905
java.version=1.4.2_08
java.vendor=Sun Microsystems Inc.
BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en_US
Command-line arguments:  -os win32 -ws win32 -arch x86 -clean

!ENTRY org.eclipse.emf.ecore 2 0 2006-07-06 17:50:41.524
!MESSAGE Both 'org.apache.geronimo.deployment.model' and  
'org.apache.geronimo.v11.deployment.model' register an extension  
parser for 'deployment'


!ENTRY org.eclipse.emf.ecore 2 0 2006-07-06 17:50:41.524
!MESSAGE Both 'org.apache.geronimo.deployment.model' and  
'org.apache.geronimo.v11.deployment.model' register an extension  
parser for 'naming'


!ENTRY org.eclipse.emf.ecore 2 0 2006-07-06 17:50:41.534
!MESSAGE Both 'org.apache.geronimo.deployment.model' and  
'org.apache.geronimo.v11.deployment.model' register an extension  
parser for 'web'
-- 



- Shiva Kumar

On 7/5/06, Sachin Patel [EMAIL PROTECTED] wrote: Can you retry  
using the callisto release (WTP 1.5, and Eclipse 3.2)?

This is what the plugin is built on and supports.

On Jul 5, 2006, at 9:05 AM, Shiva Kumar H R wrote:

 Hi,
 I am using http://people.apache.org/dist/geronimo/eclipse/unstable/
 g-eclipse-plugin-1.1-RC2.zip with Eclipse 3.1.2 and WTP 1.0.2
 (build  wtp-sdk-R-1.0.2-200604200208).

 1) While defining a New Server, during this dialog New Apache
 Geronimo v1.1 Runtime: Please enter the directory where Geronimo is
 currently installed or where you would like it to be installed. as
 shown in attachment  1.GIF, once I specify the Application
 Server Installation Directory, the upper portion of the Dialog
 gets reduced in size leaving me unable to see the message/info
 there, as shown in attachment 2.GIF . Although this doesn't stop
 me from defining a new server, I miss out on the information which
 was displayed during that dialog.

 2) After defining the server (I have the following server
 installed: Geronimo 1.1 with Jetty with Sun JDK 1.4.2_08), when I
 try to start the server, server does get started with the below
 messages in Console view:
  
--

 -
 ...
 18:22:49,519 DEBUG [GBeanSingleReference] Waiting to start geronimo/
 remote-deploy-jetty/1.1/car?J2EEApplication=null,WebModule=geronimo/
 remote-deploy-jetty/1.1/car,j2eeType=Servlet,name=jsp because no
 targets are running for reference JettyServletRegistration matching
 the patterns geronimo/remote-deploy-jetty/1.1/car?
 J2EEApplication=null,j2eeType=WebModule,name=geronimo/remote-deploy-
 jetty/1.1/car
 18:22:49,649 DEBUG [GBeanSingleReference] Waiting to start geronimo/
 remote-deploy-jetty/1.1/car?J2EEApplication=null,WebModule=geronimo/
 remote-deploy-jetty/1.1/car,j2eeType=Servlet,name=file-upload
 because no targets are running for reference Previous matching the
 patterns geronimo/remote-deploy-jetty/1.1/car?
 J2EEApplication=null,WebModule=geronimo/remote-deploy-jetty/1.1/
 car,j2eeType=Servlet,name=404-error
 Geronimo startup complete
  
--

 -

 However the Servers view still shows the server status as
 Starting.. as shown in attachment  3.GIF. And after a while, an
 Error message Timeout waiting for Apache Geronimo 1.1 to start.
 Server did not start after 24s. (as shown in attachment
 4.GIF) gets thrown. The .log file in eclipse\workspace
 \.metadata directory has the following messages logged:
  
--

 -
 !SESSION 2006-07-05 17:53:56.827
 ---
 eclipse.buildId=M20060118-1600
 java.version=1.4.2_08
 java.vendor=Sun Microsystems Inc.
 BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en_US
 Command-line

Re: How do we build the Eclipse Plugin assembly?


Great! We look forward to your contributions.

On Jul 6, 2006, at 9:16 AM, Shiva Kumar H R wrote:


Hi Sachin,
Thanks for pointing out those areas where I can start contributing.  
I will look at the code for Form page editors for deployment plans  
and Wizards. I will start a separate discussion thread on them.  
Meanwhile I will also see if I can fix some of the JIRAs in  
GeronimoDevtools.


- Shiva

On 7/5/06, Sachin Patel [EMAIL PROTECTED] wrote: Hi Shiva,

On Jul 3, 2006, at 2:56 AM, Shiva Kumar H R wrote:

 Hi Sachin,
 I too am facing the same problem as Donald during the assembly of
 Eclipse Plugin. I am building Revision 418691 of the trunk, using
 Sun JDK 1.4.2_08  Maven 2.0.4 on a WinXP sp2 machine.

Ok, I'll see if I can reproduce on another machine and dig into it.


 By the way, I am interested in contributing to Geronimo Eclipse
 Plugin. Last year I have done some work on Eclipse Plugin
 Development and I am comfortable with SWT, JFace and Plugin
 Development. Also, some of the work I did in Eclipse Drag and Drop
 got published here: http://www-128.ibm.com/developerworks/library/
 os-ecl-dragdrop/index.html

Great! SWT and JFace experience is definitely something we could
use.  So one of the big things we need coverage on is providing Form
Page editors for our deployment plans.  Currently if you double click
for example on the geronimo-web.xml it will open up a form editor.
You will see that the coverage is currently very minimal and due to
my lack of UI creativity many of the tables and such look exactly the
same. :)  The wizards are also very primative and we desperately need
to enhance these.  So if you're interested this would be a great
place to contribute.  This would also help you get a good
understanding of each of the geronimo deployment plans.


 Last one week I have been browsing through the Geronimo Dev Mailing
 Lists, as well as JIRA, to figure out how I can contribute to the
 Eclipse plugin development. If you can point me to a few to-do
 items of immediate interest, I would be more than happy to pick
 them up and start working on them right away.

 Thanks,
 Shiva Kumar

 On 7/1/06, Sachin Patel  [EMAIL PROTECTED] wrote: You have to
 invoke it manually as you've done.  I haven't figured out
 how to invoke a build+assembly in one step.  As far as the file  
sizes

 kevan saw the same problem, and we couldn't figure out why.

 On Jun 30, 2006, at 5:15 PM, Donald Woods wrote:

  I just checked out Rev418113 of the Eclipse plugin trunk, started
  with a clean m2 repo and successfully got a mvn install to
  complete after several attempts.
 
  But, when I look in the assembly/ directory, no target/ directory
  was created.  Is this expected?
 
  When I ran mvn from the assembly directory, it created a target
  directory, but the following zipfiles were only 22 bytes each -
 g-eclipse-plugin-1.1-deployable.zip
 g-eclipse-plugin-1.1-updatesite.zip
 
  I'm building on WinXP with Maven 2.0.4 and Sun Java 1.4.2_12-b03.
 
 
  -Donald


 -sachin





-sachin





--
Thanks,
Shiva Kumar



-sachin

[jira] Created: (GERONIMODEVTOOLS-89) Can't use Launch Geronimo Console after right clicking on Server, with Eclipse Plugin 1.1 RC2

2006-07-06 Thread Shiva Kumar H R (JIRA)

Can't use Launch Geronimo Console after right clicking on Server, with 
Eclipse Plugin 1.1 RC2
---

 Key: GERONIMODEVTOOLS-89
 URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-89
 Project: Geronimo-Devtools
Type: Bug

  Components: eclipse-plugin  
Versions: 1.1.0
 Environment: Eclipse Plugin 1.1 RC2, Geronimo 1.1,
WTP 1.5, Eclipse 3.2,
WinXP sp2 on an Intel32 desktop.
Reporter: Shiva Kumar H R


I am using Geronimo Eclipse Plugin RC2 (available from 
http://people.apache.org/dist/geronimo/eclipse/unstable/g-eclipse-plugin-1.1-RC2.zip)
 with Eclipse 3.2 and WTP 1.5 (build wtp-sdk-R-1.5.0-200606281455.zip). 

I am able to define a new server and start/stop the server successfully. 
However after the server gets started, when I right click on the server, I see 
that Launch Geronimo Console is disabled. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: openejb itests?


Hi Bill,

Inline-

On 7/6/06, Bill Dudney [EMAIL PROTECTED] wrote:

Hi Prasad,


 First we needed the geronimo-deployment-plugin to be in m2. So in
 http://issues.apache.org/jira/browse/GERONIMO-1738, I got the
 deployment-plugin migarted to m2. The RTC for this is pending 2 more
 votes. Now, if you and Jason can review and approve it, we can get it
 in the build.


I applied the patch but it appears that there is a problem with it,
AppTest.java has 3 copies of the code in it for example (as well as
pom.xml and many if not all the other files).

  Here is the url to what I downloaded and I'm looking at;
http://issues.apache.org/jira/secure/attachment/12324416/geronimo-
deployment-plugin.patch

which is the first patch from JIRA #1738 referenced above.


You might want to pick up the latest patch from the Manage
Attachments link. The patches on the JIRA page are sorted
alphabetically. The patch that you downloaded was my initial
submission. The other one with (
http://issues.apache.org/jira/secure/attachment/12335875/geronimo-deployment-plugin-RTC-VOTE.2.patch
) is what you need. This was uploaded by David Jencks after reviewing
mine and making some changes based on other reviews.


 I used to take an m1 binary distribution and manually put it into an
 m2 local repo for this work. Now that we are working on m2, hopefully
 we shall soon have the binary distributions for us to work with
 directly.


An m1 distribution of G or something else?



Yes, of G.


Cheers
Prasad

Re: [RTC] Vote on GERONIMO-2161 - restart 1

2006-07-06 Thread Jeff Genender

I get similar issues, but upon carefully reviewing the patch(es), I am
in full agreement. +1 to the patch.

Jeff

Matt Hogstrom wrote:
 +1 to getting this patch in...
 
 I spent some time working with Jason and Jacek last night on this
 patch.  It is fairly large and reaching.  There appears to be an issue
 with SVN creating a bad patch file for several files but I don't believe
 this is Jason's issue but rather with SVN.
 
 There are 5 failed hunks in the v5 patch.  I manually copied the files
 from branches/m2migration into trunk as these were the source of the
 modification.  The build was successful and I understand what Jason is
 doing here.
 
 I am giving this patch a +1 and would like to see Jason get this applied
 at his earliest convenience.
 
 There are issues with moving forward but getting on a better code base
 will accelerate progress on getting to a fully integrated build.
 
 We need to understand why SVN is creating bad patches but this shouldn't
 hold up the migration to M2 effort.  This is not an issue with the
 current patch but a problem with SVN we need to undestand.
 
 I would like to see Jason get these changes into trunk as well as
 resolve the patch issue.
 
 
 Matt
 
 *** Notations of applicability ***
 
 Here is the output from the patch when I applied it.  I increased the
 FUZZ factor to a horrible 8 but it had no effect.
 
 
 hogstrom:~/dev/geronimo/trunk hogstrom$ patch -p0 -l  
 ~/Downloads/GERONIMO-2161-v5.patch.txt
 patching file applications/ldap-realm-demo/pom.xml
 Hunk #1 succeeded at 17 with fuzz 2.
 patching file applications/console/console-standard/pom.xml
 Hunk #1 succeeded at 17 with fuzz 2.
 patching file applications/console/console-ear/pom.xml
 Hunk #1 succeeded at 17 with fuzz 2.
 patching file applications/console/console-core/pom.xml
 Hunk #1 succeeded at 17 with fuzz 2.
 patching file applications/console/pom.xml
 Hunk #1 succeeded at 17 with fuzz 2.
 patching file applications/console/console-framework/pom.xml
 Hunk #1 succeeded at 17 with fuzz 2.
 patching file applications/magicGball/magicGball-ejb/pom.xml
 Hunk #1 succeeded at 17 with fuzz 2.
 patching file applications/magicGball/magicGball-ear/pom.xml
 Hunk #1 succeeded at 17 with fuzz 2.
 patching file applications/magicGball/pom.xml
 Hunk #1 succeeded at 17 with fuzz 2.
 patching file applications/magicGball/magicGball-web/pom.xml
 Hunk #1 succeeded at 17 with fuzz 2.
 patching file applications/magicGball/magicGball-client/pom.xml
 Hunk #1 succeeded at 17 with fuzz 2.
 patching file applications/demo/pom.xml
 Hunk #1 succeeded at 17 with fuzz 2.
 patching file applications/remote-deploy/pom.xml
 Hunk #1 succeeded at 17 with fuzz 2.
 patching file applications/uddi-db/pom.xml
 Hunk #1 succeeded at 17 with fuzz 2.
 patching file applications/uddi-server/pom.xml
 Hunk #1 succeeded at 17 with fuzz 2.
 patching file applications/pom.xml
 Hunk #1 succeeded at 17 with fuzz 2.
 patching file applications/welcome/pom.xml
 Hunk #1 succeeded at 17 with fuzz 2.
 patching file configs/unavailable-client-deployer/pom.xml
 patching file configs/welcome-tomcat/pom.xml
 patching file configs/client-security/pom.xml
 patching file configs/javamail/pom.xml
 patching file configs/console-tomcat/pom.xml
 Hunk #1 succeeded at 16 with fuzz 3.
 patching file configs/tomcat/pom.xml
 patching file configs/j2ee-server/pom.xml
 patching file configs/pom.xml
 Hunk #1 succeeded at 17 with fuzz 2.
 patching file configs/activemq-broker/pom.xml
 Hunk #1 succeeded at 16 with fuzz 3.
 patching file configs/jsp-examples-tomcat/pom.xml
 patching file configs/sharedlib/pom.xml
 patching file configs/jetty/pom.xml
 patching file configs/console-jetty/pom.xml
 patching file configs/client-system/pom.xml
 patching file configs/unavailable-ejb-deployer/pom.xml
 patching file configs/openejb-deployer/pom.xml
 patching file configs/directory/pom.xml
 patching file configs/jsp-examples-jetty/pom.xml
 patching file configs/online-deployer/pom.xml
 patching file configs/j2ee-deployer/pom.xml
 patching file configs/tomcat-deployer/pom.xml
 patching file configs/activemq/pom.xml
 Hunk #1 succeeded at 16 with fuzz 3.
 patching file configs/geronimo-gbean-deployer/pom.xml
 patching file configs/shutdown/pom.xml
 patching file configs/hot-deployer/pom.xml
 patching file configs/servlets-examples-jetty/pom.xml
 patching file configs/jetty-deployer/pom.xml
 patching file configs/openejb/pom.xml
 patching file configs/unavailable-webservices-deployer/pom.xml
 patching file configs/axis-deployer/pom.xml
 patching file configs/system-database/pom.xml
 patching file configs/ldap-demo-tomcat/pom.xml
 patching file configs/upgrade/pom.xml
 patching file configs/welcome-jetty/pom.xml
 patching file configs/j2ee-security/pom.xml
 patching file configs/upgrade-cli/pom.xml
 patching file configs/rmi-naming/pom.xml
 patching file configs/ldap-demo-jetty/pom.xml
 patching file configs/client-deployer/pom.xml
 patching file configs/client-corba/src/plan/plan.xml

[jira] Resolved: (GERONIMODEVTOOLS-89) Can't use Launch Geronimo Console after right clicking on Server, with Eclipse Plugin 1.1 RC2

2006-07-06 Thread Sachin Patel (JIRA)

 [ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-89?page=all ]
 
Sachin Patel resolved GERONIMODEVTOOLS-89:
--

Fix Version: 1.1.0
 Resolution: Fixed
  Assign To: Sachin Patel

This should be fixed now.

 Can't use Launch Geronimo Console after right clicking on Server, with 
 Eclipse Plugin 1.1 RC2
 ---

  Key: GERONIMODEVTOOLS-89
  URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-89
  Project: Geronimo-Devtools
 Type: Bug

   Components: eclipse-plugin
 Versions: 1.1.0
  Environment: Eclipse Plugin 1.1 RC2, Geronimo 1.1,
 WTP 1.5, Eclipse 3.2,
 WinXP sp2 on an Intel32 desktop.
 Reporter: Shiva Kumar H R
 Assignee: Sachin Patel
  Fix For: 1.1.0


 I am using Geronimo Eclipse Plugin RC2 (available from 
 http://people.apache.org/dist/geronimo/eclipse/unstable/g-eclipse-plugin-1.1-RC2.zip)
  with Eclipse 3.2 and WTP 1.5 (build wtp-sdk-R-1.5.0-200606281455.zip). 
 I am able to define a new server and start/stop the server successfully. 
 However after the server gets started, when I right click on the server, I 
 see that Launch Geronimo Console is disabled. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Updated: (GERONIMO-2163) WADI Integration for Jetty

2006-07-06 Thread Gianny Damour (JIRA)

 [ http://issues.apache.org/jira/browse/GERONIMO-2163?page=all ]

Gianny Damour updated GERONIMO-2163:


Attachment: geronimo.patch

Refreshed Geronimo patch against trunk

 WADI Integration for Jetty
 --

  Key: GERONIMO-2163
  URL: http://issues.apache.org/jira/browse/GERONIMO-2163
  Project: Geronimo
 Type: New Feature
 Security: public(Regular issues) 
   Components: Clustering
 Reporter: Gianny Damour
 Assignee: Gianny Damour
 Priority: Minor
  Attachments: geronimo-wadi-integration-preview.patch, geronimo.patch, 
 wadi-geronimo-integration-preview.patch

 Email sent to the dev@ list.
 Hi,
 I have been working on a second integration attempt of WADI and I am posting 
 here a high-level description of the current state of progress such that 
 people can jump in.
 At this stage, this is a Jetty only attempt and I do believe that the same 
 approach can be applied for Tomcat. The current integration provides (very 
 unreliable) HttpSession state migration. It only works for a single 
 Web-application; more effort is required on the WADI side to support multiple 
 Web-applications and this will not impact the integration piece of code. I 
 (more or less successfully) tested the integration with mod_proxy + 
 mod_proxy_balancer and mod_proxy + mod_rewrite in front of three Geronimo 
 servers running the WADI demo web-app.
 The code changes are:
 * new module to capture some clustering contracts - geronimo-clustering: 
 there Node, SessionManager, Session and ClusteredInvocation are defined.
 * new module to provide a WADI implementation of the above - 
 geronimo-clustering-wadi;
 * new module to capture clustering builder contracts - 
 geronimo-clustering-builder: there is only one interesting interface 
 JettyClusteringBuilder. This later defines a couple of methods to augment the 
 environment of a Web module being built and add clustering specific GBeans;
 * new module to provide a WADI implementation of the above - 
 Geronimo-clustering-builder-wadi; and
 * geronimo-jetty-builder and geronimo-jetty are impacted to hook in 
 clustering. These two modules depend on geronimo-clustering and 
 geronimo-clustering-builder and not on WADI specific modules.
 Two new modules are added:
 * jetty-clustering- wadi: this module defines default WADI GBeans such as 
 Dispatcher, ReplicationManagerFactory, BackingStrategyFactory et cetera; and
 * jetty-clustering-builder-wadi: this module defines a builder to process 
 Jetty DD and add various GBeans to the module being built.
 I think that the implementation is flexible enough to plug in another 
 clustering implementation such as Kache.
 As a matter of fact, there are some severe reliability (e.g. locking issues) 
 and integration (only one Web-app can be clustered) issues, which need to be 
 fixed. So, this work is not yet ready to be RTC voted. Having said that, I 
 have opened a JIRA such that people can have a look to the integration.
 Thanks,
 Gianny

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Updated: (GERONIMO-2163) WADI Integration for Jetty

2006-07-06 Thread Gianny Damour (JIRA)

 [ http://issues.apache.org/jira/browse/GERONIMO-2163?page=all ]

Gianny Damour updated GERONIMO-2163:


Attachment: wadi.patch

Refreshed WADI patch.

 WADI Integration for Jetty
 --

  Key: GERONIMO-2163
  URL: http://issues.apache.org/jira/browse/GERONIMO-2163
  Project: Geronimo
 Type: New Feature
 Security: public(Regular issues) 
   Components: Clustering
 Reporter: Gianny Damour
 Assignee: Gianny Damour
 Priority: Minor
  Attachments: geronimo-wadi-integration-preview.patch, geronimo.patch, 
 wadi-geronimo-integration-preview.patch, wadi.patch

 Email sent to the dev@ list.
 Hi,
 I have been working on a second integration attempt of WADI and I am posting 
 here a high-level description of the current state of progress such that 
 people can jump in.
 At this stage, this is a Jetty only attempt and I do believe that the same 
 approach can be applied for Tomcat. The current integration provides (very 
 unreliable) HttpSession state migration. It only works for a single 
 Web-application; more effort is required on the WADI side to support multiple 
 Web-applications and this will not impact the integration piece of code. I 
 (more or less successfully) tested the integration with mod_proxy + 
 mod_proxy_balancer and mod_proxy + mod_rewrite in front of three Geronimo 
 servers running the WADI demo web-app.
 The code changes are:
 * new module to capture some clustering contracts - geronimo-clustering: 
 there Node, SessionManager, Session and ClusteredInvocation are defined.
 * new module to provide a WADI implementation of the above - 
 geronimo-clustering-wadi;
 * new module to capture clustering builder contracts - 
 geronimo-clustering-builder: there is only one interesting interface 
 JettyClusteringBuilder. This later defines a couple of methods to augment the 
 environment of a Web module being built and add clustering specific GBeans;
 * new module to provide a WADI implementation of the above - 
 Geronimo-clustering-builder-wadi; and
 * geronimo-jetty-builder and geronimo-jetty are impacted to hook in 
 clustering. These two modules depend on geronimo-clustering and 
 geronimo-clustering-builder and not on WADI specific modules.
 Two new modules are added:
 * jetty-clustering- wadi: this module defines default WADI GBeans such as 
 Dispatcher, ReplicationManagerFactory, BackingStrategyFactory et cetera; and
 * jetty-clustering-builder-wadi: this module defines a builder to process 
 Jetty DD and add various GBeans to the module being built.
 I think that the implementation is flexible enough to plug in another 
 clustering implementation such as Kache.
 As a matter of fact, there are some severe reliability (e.g. locking issues) 
 and integration (only one Web-app can be clustered) issues, which need to be 
 fixed. So, this work is not yet ready to be RTC voted. Having said that, I 
 have opened a JIRA such that people can have a look to the integration.
 Thanks,
 Gianny

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: [RTC] Vote on GERONIMO-2161 - restart 1


On 7/6/06, Matt Hogstrom [EMAIL PROTECTED] wrote:


We need to understand why SVN is creating bad patches but this shouldn't hold 
up the migration to M2
effort.  This is not an issue with the current patch but a problem with SVN we 
need to undestand.


Don't we have it behind us already? I thought we agreed upon the fact
that unix patch is incompatible with svn diff and thus we need to use
svn diff to create a patch for review and merge it to our own local
copies using svn merge. The point is to get the revisions a patch is
built from, but the rest should work.


I would like to see Jason get these changes into trunk as well as resolve the 
patch issue.


(Oh, poor Jacek and his poor English that doesn't let him explain how
we should proceed :-))

To be honest, I don't like how the patch has been reviewed and voted.
How can we say it works if we (me, including) couldn't apply it to our
local source copies? If one's going to say it's because of the unix
patch I'll start screaming...That's why svn merge exists, doesn't it?
Ok, stop whining...

I wonder how the changes will be applied to trunk if patch doesn't work?

Jacek

--
Jacek Laskowski
http://www.laskowski.net.pl

[jira] Assigned: (AMQ-797) ActiveMQ Cpp Windows Makefiles fail to link the test, and test-integration targets

2006-07-06 Thread Nathan Mittler (JIRA)

 [ https://issues.apache.org/activemq/browse/AMQ-797?page=all ]

Nathan Mittler reassigned AMQ-797:
--

Assign To: Nathan Mittler

 ActiveMQ Cpp Windows Makefiles fail to link the test, and test-integration 
 targets
 --

  Key: AMQ-797
  URL: https://issues.apache.org/activemq/browse/AMQ-797
  Project: ActiveMQ
 Type: Bug

   Components: CMS
  Environment: Windows Mingw GNU builds
 Reporter: Timothy Bish
 Assignee: Nathan Mittler
 Priority: Minor
  Attachments: patch-makefile-windows-debug.txt, 
 patch-makefile-windows-release.txt

 Original Estimate: 1 minute
 Remaining: 1 minute

 The windows makefiles for the MinGW targets fail to link the test and 
 test-integration targets.
 When the code was submitted the makefiles were changed to build the library 
 with the libactivemq-cpp.a name, but the windows makefiles still try and link 
 the tests against libactivemq.a

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: Errors while using Geronimo Eclipse Plugin RC2

As far as the UI problem of the dialog size, can you open a JIRA and  
attach the screen shot to it.  Also since you're the SWT/JFace  
expert :) if I point you to the code, would you be able to provide a  
quick fix?


Thanks.

On Jul 6, 2006, at 10:08 AM, Sachin Patel wrote:



On Jul 6, 2006, at 8:28 AM, Shiva Kumar H R wrote:


Hi Sachin,
I tried using WTP 1.5 and Eclipse 3.2. The problems mentioned  
earlier disappear and I am able to start/stop the server  
successfully.


However after the server gets started, when I right click on the  
server, I see that Launch Geronimo Console is disabled. Isn't  
this a bug? Shall I open a JIRA for the same?


Yes, I noticed this as well, please open a JIRA.



I also observed that the .log file in my eclipse\workspace 
\.metadata directory has the following messages logged. Do you  
suspect any problem here?


No this is ok and just a warning.  I can't remove the duplicate  
extensions because they are being inserted automatically by EMF  
during the build.


- 
-
!SESSION 2006-07-06 17:50: 17.529  
---

eclipse.buildId=M20060629-1905
java.version=1.4.2_08
java.vendor=Sun Microsystems Inc.
BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en_US
Command-line arguments:  -os win32 -ws win32 -arch x86 -clean

!ENTRY org.eclipse.emf.ecore 2 0 2006-07-06 17:50:41.524
!MESSAGE Both 'org.apache.geronimo.deployment.model' and  
'org.apache.geronimo.v11.deployment.model' register an extension  
parser for 'deployment'


!ENTRY org.eclipse.emf.ecore 2 0 2006-07-06 17:50:41.524
!MESSAGE Both 'org.apache.geronimo.deployment.model' and  
'org.apache.geronimo.v11.deployment.model' register an extension  
parser for 'naming'


!ENTRY org.eclipse.emf.ecore 2 0 2006-07-06 17:50:41.534
!MESSAGE Both 'org.apache.geronimo.deployment.model' and  
'org.apache.geronimo.v11.deployment.model' register an extension  
parser for 'web'
- 
-


- Shiva Kumar

On 7/5/06, Sachin Patel [EMAIL PROTECTED] wrote: Can you retry  
using the callisto release (WTP 1.5, and Eclipse 3.2)?

This is what the plugin is built on and supports.

On Jul 5, 2006, at 9:05 AM, Shiva Kumar H R wrote:

 Hi,
 I am using http://people.apache.org/dist/geronimo/eclipse/unstable/
 g-eclipse-plugin-1.1-RC2.zip with Eclipse 3.1.2 and WTP 1.0.2
 (build  wtp-sdk-R-1.0.2-200604200208).

 1) While defining a New Server, during this dialog New Apache
 Geronimo v1.1 Runtime: Please enter the directory where Geronimo is
 currently installed or where you would like it to be installed. as
 shown in attachment  1.GIF, once I specify the Application
 Server Installation Directory, the upper portion of the Dialog
 gets reduced in size leaving me unable to see the message/info
 there, as shown in attachment 2.GIF . Although this doesn't stop
 me from defining a new server, I miss out on the information which
 was displayed during that dialog.

 2) After defining the server (I have the following server
 installed: Geronimo 1.1 with Jetty with Sun JDK 1.4.2_08), when I
 try to start the server, server does get started with the below
 messages in Console view:
  
- 
-

 -
 ...
 18:22:49,519 DEBUG [GBeanSingleReference] Waiting to start  
geronimo/
 remote-deploy-jetty/1.1/car? 
J2EEApplication=null,WebModule=geronimo/

 remote-deploy-jetty/1.1/car,j2eeType=Servlet,name=jsp because no
 targets are running for reference JettyServletRegistration matching
 the patterns geronimo/remote-deploy-jetty/1.1/car?
 J2EEApplication=null,j2eeType=WebModule,name=geronimo/remote- 
deploy-

 jetty/1.1/car
 18:22:49,649 DEBUG [GBeanSingleReference] Waiting to start  
geronimo/
 remote-deploy-jetty/1.1/car? 
J2EEApplication=null,WebModule=geronimo/

 remote-deploy-jetty/1.1/car,j2eeType=Servlet,name=file-upload
 because no targets are running for reference Previous matching the
 patterns geronimo/remote-deploy-jetty/1.1/car?
 J2EEApplication=null,WebModule=geronimo/remote-deploy-jetty/1.1/
 car,j2eeType=Servlet,name=404-error
 Geronimo startup complete
  
- 
-

 -

 However the Servers view still shows the server status as
 Starting.. as shown in attachment  3.GIF. And after a while, an
 Error message Timeout waiting for Apache Geronimo 1.1 to start.
 Server did not start after 24s. (as shown in attachment
 4.GIF) gets thrown. The .log file in eclipse\workspace
 \.metadata directory has the following messages logged:
  
- 
-

How were the Geronimo 1.0 and 1.1 artifacts published to a Maven2 Repo?

2006-07-06 Thread Donald Woods

For Geronimo 1.1, both of the Eclipse plugin and Daytrader sample 
require valid Maven2 POM files in order to determine the 
dependencies/imports when building, so how were these created from the 
current Maven1 based Geronimo 1.0 and 1.1 builds?  Is there a way we can 
automate this for our local Geronimo 1.1.1-SNAPSHOT builds?



-Donald


smime.p7s
Description: S/MIME Cryptographic Signature

[jira] Commented: (AMQ-797) ActiveMQ Cpp Windows Makefiles fail to link the test, and test-integration targets

2006-07-06 Thread Nathan Mittler (JIRA)

[ 
https://issues.apache.org/activemq/browse/AMQ-797?page=comments#action_36530 ] 

Nathan Mittler commented on AMQ-797:


Tim, I've applied the patch ... give it a try and make sure everything is as it 
should be.

Thanks,
Nate

 ActiveMQ Cpp Windows Makefiles fail to link the test, and test-integration 
 targets
 --

  Key: AMQ-797
  URL: https://issues.apache.org/activemq/browse/AMQ-797
  Project: ActiveMQ
 Type: Bug

   Components: CMS
  Environment: Windows Mingw GNU builds
 Reporter: Timothy Bish
 Assignee: Nathan Mittler
 Priority: Minor
  Attachments: patch-makefile-windows-debug.txt, 
 patch-makefile-windows-release.txt

 Original Estimate: 1 minute
 Remaining: 1 minute

 The windows makefiles for the MinGW targets fail to link the test and 
 test-integration targets.
 When the code was submitted the makefiles were changed to build the library 
 with the libactivemq-cpp.a name, but the windows makefiles still try and link 
 the tests against libactivemq.a

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

M2 assembly question

Is it better to have an separate assembly module that generates the  
assemblies or is it better to have the assembly plugin configured in  
the root pom?  Currently in devtools I have it as a seperate module  
and use dependencySets to specify what gets included in the binaries.  
However as mentioned in earlier threads this is having problems  
working on one platform but not on another.  I don't know if it would  
make a difference if I define the assembly config in the root POM and  
use moduleSets instead.


I'm wanting to put out a vote on the release of the 1.1 version of  
the eclipse plugin but need to get this problem fixed as currently my  
machine seems to be the only machine in which the assembly generation  
seems to be working :(.


-sachin

Derby/JMX and GBeans

2006-07-06 Thread Sanket Sharma


Hi,

I' writing JMX MBeans for Apache Derby and would like to know how
Geronimo handles calls to normal MBeans and getPlatformMBean.
One of my aims to make sure that Derby's MBeans integrate well into
existing JMX enabled containers. Therefore, instead of starting a new
MBean server for Derby, I would like to register Derby's MBeans in the
containers MBeanServer.

I looked at the Geronimo code and found that Derby is already
implemented as a GBean which can be managed within Geronimo. However,
the functionality is very limited. My MBeans expose much more stats
about derby and provide a lot more configurability.

I'm not very sure on this, but AFAIK, if I add MBeans to Derby via
normal JMX calls, they will appear in JConsole, but distinct from
Geronimo.
Therefore, If I do want to make these as part of GBean management, I
need to write wrapper calls around my MBeans and expose them as GBean
calls?

I have just started reading Geronimo's code and documentation and any
help would be greatly appriciated.

Thank you.

Best Regards,
Sanket Sharma

[jira] Commented: (AMQ-797) ActiveMQ Cpp Windows Makefiles fail to link the test, and test-integration targets

2006-07-06 Thread Timothy Bish (JIRA)

[ 
https://issues.apache.org/activemq/browse/AMQ-797?page=comments#action_36531 ] 

Timothy Bish commented on AMQ-797:
--

I gave them a try, works fine now.

 ActiveMQ Cpp Windows Makefiles fail to link the test, and test-integration 
 targets
 --

  Key: AMQ-797
  URL: https://issues.apache.org/activemq/browse/AMQ-797
  Project: ActiveMQ
 Type: Bug

   Components: CMS
  Environment: Windows Mingw GNU builds
 Reporter: Timothy Bish
 Assignee: Nathan Mittler
 Priority: Minor
  Attachments: patch-makefile-windows-debug.txt, 
 patch-makefile-windows-release.txt

 Original Estimate: 1 minute
 Remaining: 1 minute

 The windows makefiles for the MinGW targets fail to link the test and 
 test-integration targets.
 When the code was submitted the makefiles were changed to build the library 
 with the libactivemq-cpp.a name, but the windows makefiles still try and link 
 the tests against libactivemq.a

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: Implementing Global JNDI

2006-07-06 Thread David Jencks

See my comment in the jira about this, I don't think you need to use  
any naming References at all, nor do you need anything but a GBean  
reference to the appropriate GBean.


http://issues.apache.org/jira/browse/GERONIMO-2153

thanks
david jencks

On Jul 6, 2006, at 6:06 AM, Krishnakumar B wrote:


Hi David,

I tried this and it works for Custom Resource Adapters. There is still
a problem for Registering GBeans in Global JNDI through the builder (
ServiceConfigBuilder ). The Builder is a part of
geronimo-gbean-deployer plan which is parent of j2ee-deployer.  The
geronimo-naming jars are loaded in j2ee-deployer. Hence we dont get
access in ServiceConfigBuilder to GBeanReference thats part of naming.

Currently all the binding GBeans are in naming package. So it works
for all j2ee deployments.

Is there a way to work around this ClassLoading problem heirarchy for
binding GBeans through builder?

Regards
Krishnakumar


On 6/28/06, David Jencks [EMAIL PROTECTED] wrote:


I think there is a simpler solution, or perhaps I don't understand  
all the
details of what you are proposing.  I think if you give your  
binding gbeans
the magic classLoader attribute everything will work.  This will  
be set to
the configuration classloader for the configuration the gbean is  
in, not the
configuration the gbeans class is loaded in.  This classloader  
should always

have the necessary classes in it.

thanks
david jencks


On Jun 28, 2006, at 12:39 AM, Manu George wrote:
Hi,
 The problem we are facing regarding adapters is because  
the binding
gbeans were added to the naming module of geronimo. We are  
planning to
change this by creating a separate module for global jndi and then  
adding it
as a dependency in the configuration that is getting deployed.  
This will be
done in the builders.  All the reference creation logic can also  
be moved to
the gbeans.The Binding GBeans will then have access to application  
level

classes as they will be loaded in the app class loader.  We hope this
approach will solve the current problem.  We will post the code  
again after

making these changes.

Thanks
Manu

On 6/28/06, Krishnakumar B [EMAIL PROTECTED] wrote:
 Hi,

 We have created  a JIRA
 (http://issues.apache.org/jira/browse/GERONIMO-2153  )
and attached
 the initial draft. We have tried two approaches.

 * Adding to plan
 * Deploying from Builder.

 The EJBJNDIBindingGBean deploys from OpenEJBModuleBuilder and  
has a tag

   global-jndi/ in opene ejb plan.

 Resource Adapter and GBean have a gbean plan added to deployment  
plan.


 gbean name=JMSQueueFactoryJNDIBindingGBean

class=org.apache.geronimo.connector.jndi.ConnectorJNDIBindingGBean
 attribute
name=configIdtest/jms.rar/1.0/rar/attribute
 attribute
name=jndiNameglobalJMSQueueFactory/attribute
 attribute
name=componentNameJMSQueueFactory/attribute
 attribute
name=j2eeTypeJCAManagedConnectionFactory/attribute
 attribute
name=interfaceNameorg.apache.geronimo.jms.connector.JMSQueueConnec 
tionFactory/attribute

 /gbean

 and

 gbean name=TestGBeanJNDIBindingGBean

class=org.apache.geronimo.service.jndi.ServiceJNDIBindingGBean
 attribute name=configIdtest/gbean/1.0/car/attribute
 attribute name=jndiNameglobalTestGBean/attribute
 attribute name=componentNameTestGBean/attribute
 attribute name=j2eeTypeGBean/attribute
 attribute name=classNamegbean.test.TestGBean/attribute
 /gbean

 We have a Classloading issue when trying to maintain all the
 BindingGbeans at one level. ( rmi-naming ). For GBeans and Resource
 Adapters that are not J2EE interfaces like javax.sql.DataSource /
 javax.jms.QueueConnectionFactory we get a ClassNotFound
as the class
 is not available at Classloader of rmi-naming.

 We spent a lot of time trying to solve this issue but are not  
able to

 find a solution as the application level interface or class is not
 available. This problem will not occur for j2ee interfaces like
 DataSource, EJB interfaces, Queue, Topic etc..

 If the approach is correct we would like to add the other  
features to

 make this more suitable for adding into the product.

 Regards
 Krishnakumar B


 On 6/26/06, Jacek Laskowski [EMAIL PROTECTED] wrote:
  On 6/23/06, Krishnakumar B  [EMAIL PROTECTED] wrote:
 
   The plan needs to have some XML Tag to say this resource  
needs to gets
   into Global JNDI and the builder can then add it to  
geronimo: Context.
   This is not implemented yet. Currently if we deploy a  
connector it

   gets in global jndi.
 
  I might've misunderstood it, but isn't Global JNDI == geronimo:
  context == global: context? If so, why is this copying from  
Global

  JNDI to the geronimo: namespace?
 
  Looking forward to seeing your patch for it. Just as Guillaume
  suggested, please create an JIRA issue and attach the patch to  
it.

 
   Krishnakumar B
 
  Jacek
 
  --
  Jacek Laskowski
  http://www.laskowski.net.pl

Re: [RTC] Vote on GERONIMO-2161 - restart 1

2006-07-06 Thread Matt Hogstrom


Jacek,

I agree that that it has been hard to install.  We need to figure out why.  That is another issue I 
think.


Matt

Jacek Laskowski wrote:

On 7/6/06, Matt Hogstrom [EMAIL PROTECTED] wrote:

We need to understand why SVN is creating bad patches but this 
shouldn't hold up the migration to M2
effort.  This is not an issue with the current patch but a problem 
with SVN we need to undestand.


Don't we have it behind us already? I thought we agreed upon the fact
that unix patch is incompatible with svn diff and thus we need to use
svn diff to create a patch for review and merge it to our own local
copies using svn merge. The point is to get the revisions a patch is
built from, but the rest should work.

I would like to see Jason get these changes into trunk as well as 
resolve the patch issue.


(Oh, poor Jacek and his poor English that doesn't let him explain how
we should proceed :-))

To be honest, I don't like how the patch has been reviewed and voted.
How can we say it works if we (me, including) couldn't apply it to our
local source copies? If one's going to say it's because of the unix
patch I'll start screaming...That's why svn merge exists, doesn't it?
Ok, stop whining...

I wonder how the changes will be applied to trunk if patch doesn't work?

Jacek

[jira] Resolved: (AMQ-797) ActiveMQ Cpp Windows Makefiles fail to link the test, and test-integration targets

2006-07-06 Thread Nathan Mittler (JIRA)

 [ https://issues.apache.org/activemq/browse/AMQ-797?page=all ]
 
Nathan Mittler resolved AMQ-797:


Resolution: Fixed

 ActiveMQ Cpp Windows Makefiles fail to link the test, and test-integration 
 targets
 --

  Key: AMQ-797
  URL: https://issues.apache.org/activemq/browse/AMQ-797
  Project: ActiveMQ
 Type: Bug

   Components: CMS
  Environment: Windows Mingw GNU builds
 Reporter: Timothy Bish
 Assignee: Nathan Mittler
 Priority: Minor
  Attachments: patch-makefile-windows-debug.txt, 
 patch-makefile-windows-release.txt

 Original Estimate: 1 minute
 Remaining: 1 minute

 The windows makefiles for the MinGW targets fail to link the test and 
 test-integration targets.
 When the code was submitted the makefiles were changed to build the library 
 with the libactivemq-cpp.a name, but the windows makefiles still try and link 
 the tests against libactivemq.a

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Found a fix but don't know why...Re: M2 assembly question

So I'm not sure if this is a bug in Maven or not... but in a given  
module if the POM packaging is set to pom and if assembly descriptors  
use dependencySet the dependencies as specified in the POM seem to be  
ignored and the assembly zips end up being empty.  If I set the  
packaging to jar then the dependencies get picked up and packaged.


I'm going to go and and fix this in the devtools assembly module by  
changing the packaging to a jar, if anyone thinks this is wrong let  
me know.


On Jul 6, 2006, at 12:34 PM, Sachin Patel wrote:

Is it better to have an separate assembly module that generates the  
assemblies or is it better to have the assembly plugin configured  
in the root pom?  Currently in devtools I have it as a seperate  
module and use dependencySets to specify what gets included in the  
binaries. However as mentioned in earlier threads this is having  
problems working on one platform but not on another.  I don't know  
if it would make a difference if I define the assembly config in  
the root POM and use moduleSets instead.


I'm wanting to put out a vote on the release of the 1.1 version of  
the eclipse plugin but need to get this problem fixed as currently  
my machine seems to be the only machine in which the assembly  
generation seems to be working :(.


-sachin





-sachin

[jira] Updated: (GERONIMO-2082) [m2] stax dependencies are all wrong

2006-07-06 Thread David Jencks (JIRA)

 [ http://issues.apache.org/jira/browse/GERONIMO-2082?page=all ]

David Jencks updated GERONIMO-2082:
---

Component: buildsystem

 [m2] stax dependencies are all wrong
 

  Key: GERONIMO-2082
  URL: http://issues.apache.org/jira/browse/GERONIMO-2082
  Project: Geronimo
 Type: Bug
 Security: public(Regular issues) 
   Components: buildsystem
 Versions: 1.2
 Reporter: David Jencks
 Assignee: David Jencks
  Fix For: 1.2
  Attachments: geronimo-no-stax-v2.diff, geronimo-no-stax.diff, m2-repo.jar, 
 openejb-no-stax-v2.diff, openejb-no-stax.diff, xbean-2.0.0.pom, 
 xmlbeans-maven-plugin-2.0.1-SNAPSHOT.jar, 
 xmlbeans-maven-plugin-2.0.1-SNAPSHOT.jar

 The dependencies for xmlbeans and the maven xmlbeans plugins are all wrong.
 xmlbeans pom needs to depend on stax-api, see 
 http://jira.codehaus.org/browse/MEV-406
 xmlbeans plugin needs to have stax-api and stax dependencies removed, see 
 http://jira.codehaus.org/browse/MXMLBEANS-19
 At this point we can remove all stax and stax-api dependencies from our (and 
 openejb) poms.
 I'll attach the modified xmlbeans pom, the modified plugin, and the patches 
 to remove all stax mentions from our poms.  I'd appreciate some verification 
 of my results.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: [jira] Commented: (GERONIMO-2161) [RTC] Remove Geronimo modules from dependencyManagement in root pom.xml


The exact command used to make the v5 patch was (from trunk):

svn diff  GERONIMO-2161.patch

And, as I thought I explained to you before, the same changes are  
applied to this branch:


https://svn.apache.org/repos/asf/geronimo/sandbox/svkmerge/ 
m2migration/


You can just use the branch to test the changes, or merge those  
changes into your branch, which should have the same results at the  
cost of additional merging.


--jason


On Jul 6, 2006, at 4:09 AM, Jacek Laskowski wrote:


On 7/6/06, Jason Dillon [EMAIL PROTECTED] wrote:

I'm sorry... but I do not understand what you are asking Jacek.
Could you please rephrase your question/request?


How did you cut the latest patch v5? What commands did you use? I
guess it was something like 'svn diff ...  GERONIMO-2161-v5.patch',
wasn't it? If so and the changes are part of a branch (e.g.
svkmerge/m2migration), we (testers) could apply it to our local
Geronimo srcs using 'svn merge' nor 'patch' that we've just found is
incompatible. This way we will use svn commands only and be able to
apply and test it.


--jason


Jacek

--
Jacek Laskowski
http://www.laskowski.net.pl

[jira] Updated: (GERONIMO-1737) Plugin migration to Maven 2: geronimo-assembly-plugin

2006-07-06 Thread David Jencks (JIRA)

 [ http://issues.apache.org/jira/browse/GERONIMO-1737?page=all ]

David Jencks updated GERONIMO-1737:
---

Attachment: m2-jetty-server.patch

Using prasad's assembly plugin that I believe he is attaching to this issue, 
and trunk as of rev 419642, I got a jetty server with 13 modules to build  
using this patch, and it starts!.  Many of the changes such as fixing the 
openejb groupId may be duplicated in other patches.

 Plugin migration to Maven 2: geronimo-assembly-plugin
 -

  Key: GERONIMO-1737
  URL: http://issues.apache.org/jira/browse/GERONIMO-1737
  Project: Geronimo
 Type: Sub-task
 Security: public(Regular issues) 
   Components: buildsystem
 Versions: 1.x
 Reporter: Jacek Laskowski
 Assignee: Prasad Kashyap
  Attachments: m2-jetty-server.patch

 It's a task to keep track of the progress of the plugin build migration to 
 Maven2

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: [RTC] Vote on GERONIMO-2161 - restart 1


On Jul 6, 2006, at 9:13 AM, Jacek Laskowski wrote:
I wonder how the changes will be applied to trunk if patch doesn't  
work?


It is easy enough to apply the patch and then copy the files from the  
svkmerge/m2migration branch manually to recreate the complete v5  
patch changes.


--jason

Re: Found a fix but don't know why...Re: M2 assembly question


Thanks Jason!,

Comparing your pom to mine, I changed the packaging back to pom, and  
noticed your configuration for the assembly plugin invoked the goal  
attached where mine invoked assembly.  Changing it to attached  
seemed to correct the problem.  Although I still don't understand why  
as looking at both of the goal descriptions they do the same thing.


On Jul 6, 2006, at 3:08 PM, Jason Dillon wrote:

I am using pom packaging for GShell assemblies (as well for other  
projects) with no problems using dependencySets:


http://svn.apache.org/repos/asf/geronimo/sandbox/gshell/trunk/ 
gshell-assemblies/gshell-complete-assembly/pom.xml


But, that assembly's pom can not depend on another pom with pom  
packaging and expect to pick up all of the dependencies it has listed.


--jason


On Jul 6, 2006, at 11:04 AM, Sachin Patel wrote:

So I'm not sure if this is a bug in Maven or not... but in a given  
module if the POM packaging is set to pom and if assembly  
descriptors use dependencySet the dependencies as specified in the  
POM seem to be ignored and the assembly zips end up being empty.   
If I set the packaging to jar then the dependencies get picked up  
and packaged.


I'm going to go and and fix this in the devtools assembly module  
by changing the packaging to a jar, if anyone thinks this is wrong  
let me know.


On Jul 6, 2006, at 12:34 PM, Sachin Patel wrote:

Is it better to have an separate assembly module that generates  
the assemblies or is it better to have the assembly plugin  
configured in the root pom?  Currently in devtools I have it as a  
seperate module and use dependencySets to specify what gets  
included in the binaries. However as mentioned in earlier threads  
this is having problems working on one platform but not on  
another.  I don't know if it would make a difference if I define  
the assembly config in the root POM and use moduleSets instead.


I'm wanting to put out a vote on the release of the 1.1 version  
of the eclipse plugin but need to get this problem fixed as  
currently my machine seems to be the only machine in which the  
assembly generation seems to be working :(.


-sachin





-sachin







-sachin

Re: [RTC] Vote on GERONIMO-2161 - restart 1


On Jul 6, 2006, at 9:13 AM, Jacek Laskowski wrote:

On 7/6/06, Matt Hogstrom [EMAIL PROTECTED] wrote:
We need to understand why SVN is creating bad patches but this  
shouldn't hold up the migration to M2
effort.  This is not an issue with the current patch but a problem  
with SVN we need to undestand.


Don't we have it behind us already? I thought we agreed upon the fact
that unix patch is incompatible with svn diff and thus we need to use
svn diff to create a patch for review and merge it to our own local
copies using svn merge. The point is to get the revisions a patch is
built from, but the rest should work.


We must resolve why svn diff + patch does not work... else it will be  
very, very difficult to take in changes from non-commiters who do not  
have access to create branches for us to merge.




To be honest, I don't like how the patch has been reviewed and voted.
How can we say it works if we (me, including) couldn't apply it to our
local source copies? If one's going to say it's because of the unix
patch I'll start screaming...That's why svn merge exists, doesn't it?
Ok, stop whining...


Dude!  You can apply the changes to your workspace... many other have  
done so.  Yes, patch barfs on a few bits, but copy over the changed  
files, which are all minor anyways, and you are set.


--jason

Re: Found a fix but don't know why...Re: M2 assembly question

From what I understand, the assembly goal is a tad broke and causes  
a duplicate assembly to run.   It was meant to be run as in `mvn  
assembly:assembly' not as part of a phase.  But lucky for us they  
added these new goals that work better when attached to a phase.


--jason


On Jul 6, 2006, at 12:23 PM, Sachin Patel wrote:


Thanks Jason!,

Comparing your pom to mine, I changed the packaging back to pom,  
and noticed your configuration for the assembly plugin invoked the  
goal attached where mine invoked assembly.  Changing it to  
attached seemed to correct the problem.  Although I still don't  
understand why as looking at both of the goal descriptions they do  
the same thing.


On Jul 6, 2006, at 3:08 PM, Jason Dillon wrote:

I am using pom packaging for GShell assemblies (as well for other  
projects) with no problems using dependencySets:


http://svn.apache.org/repos/asf/geronimo/sandbox/gshell/trunk/ 
gshell-assemblies/gshell-complete-assembly/pom.xml


But, that assembly's pom can not depend on another pom with pom  
packaging and expect to pick up all of the dependencies it has  
listed.


--jason


On Jul 6, 2006, at 11:04 AM, Sachin Patel wrote:

So I'm not sure if this is a bug in Maven or not... but in a  
given module if the POM packaging is set to pom and if assembly  
descriptors use dependencySet the dependencies as specified in  
the POM seem to be ignored and the assembly zips end up being  
empty.  If I set the packaging to jar then the dependencies get  
picked up and packaged.


I'm going to go and and fix this in the devtools assembly module  
by changing the packaging to a jar, if anyone thinks this is  
wrong let me know.


On Jul 6, 2006, at 12:34 PM, Sachin Patel wrote:

Is it better to have an separate assembly module that generates  
the assemblies or is it better to have the assembly plugin  
configured in the root pom?  Currently in devtools I have it as  
a seperate module and use dependencySets to specify what gets  
included in the binaries. However as mentioned in earlier  
threads this is having problems working on one platform but not  
on another.  I don't know if it would make a difference if I  
define the assembly config in the root POM and use moduleSets  
instead.


I'm wanting to put out a vote on the release of the 1.1 version  
of the eclipse plugin but need to get this problem fixed as  
currently my machine seems to be the only machine in which the  
assembly generation seems to be working :(.


-sachin





-sachin







-sachin

Re: [jira] Commented: (GERONIMO-2161) [RTC] Remove Geronimo modules from dependencyManagement in root pom.xml


On 7/6/06, Jason Dillon [EMAIL PROTECTED] wrote:

The exact command used to make the v5 patch was (from trunk):

 svn diff  GERONIMO-2161.patch

And, as I thought I explained to you before, the same changes are
applied to this branch:

 https://svn.apache.org/repos/asf/geronimo/sandbox/svkmerge/
m2migration/

You can just use the branch to test the changes, or merge those
changes into your branch, which should have the same results at the
cost of additional merging.


Understood. Would you consider a small improvement in the process (let
me call it this way before we'll find a better name for it ;-))?

You've been working on the patch in your local copy of Geronimo trunk.
You did svn co ...trunk. Correct? When you finished your work, you
executed 'svn diff' to cut the patch. Correct? The patch turned out to
be 'broken' or 'incompatible' for unix patch command and thus noone
could test it out extensively, but look at it and verify reading.
Correct?

I can see a few issues with that approach:

1/ You're working alone with no help from anyone. No, I don't mind
your working alone and show changes when they're ready. The point is
that I don't foster an interest of others to be involved and possibly
contribute/help you.

2/ As we have already found out, unix patch is not reliable and thus
is not an option in a long turn. We need to figure out a way to work
in a collaborative manner without the overhead of unix patch that
makes the process of applying changes more complicated than it really
needs to be. If your changes are between some revisions (e.g. initial
branch creation revision and HEAD) anyone can use the branch and apply
the change with svn merge command to his/her local Geronimo sources
copy and test it out. Once an issue is found, the one who spot it
could fix it in your branch and again call a vote.

There're some other benefits, but these should be enough for now
(unless you're not convinced and I'll have to write them down ;-))

WDYT?


--jason


Jacek

--
Jacek Laskowski
http://www.laskowski.net.pl

Re: How do we build the Eclipse Plugin assembly?

This problem (thanks Jason) is now fixed.  An mvn at the root will  
build all modules and generate the assemblies in one shot.


On Jun 30, 2006, at 5:15 PM, Donald Woods wrote:

I just checked out Rev418113 of the Eclipse plugin trunk, started  
with a clean m2 repo and successfully got a mvn install to  
complete after several attempts.


But, when I look in the assembly/ directory, no target/ directory  
was created.  Is this expected?


When I ran mvn from the assembly directory, it created a target  
directory, but the following zipfiles were only 22 bytes each -

   g-eclipse-plugin-1.1-deployable.zip
   g-eclipse-plugin-1.1-updatesite.zip

I'm building on WinXP with Maven 2.0.4 and Sun Java 1.4.2_12-b03.


-Donald



-sachin

Re: [RTC] Vote on GERONIMO-2161 - restart 1


On 7/6/06, Jason Dillon [EMAIL PROTECTED] wrote:

On Jul 6, 2006, at 9:13 AM, Jacek Laskowski wrote:
 I wonder how the changes will be applied to trunk if patch doesn't
 work?

It is easy enough to apply the patch and then copy the files from the
svkmerge/m2migration branch manually to recreate the complete v5
patch changes.


I must be missing something as I don't understand how you can use
'easy enough' when we all were struggling with applying it. Could you
elaborate a bit more?


--jason


Jacek

--
Jacek Laskowski
http://www.laskowski.net.pl

Re: openejb itests?


Yep. This is it.

So what you could do is take a m1 binary and run the mvn
install:install-file command to install it into your m2 local repo.

The exact syntax of that command is in the error message that you have pasted.

Cheers
Prasad



On 7/6/06, Bill Dudney [EMAIL PROTECTED] wrote:

Hi Prasad,

Is this error that causes you to manually install an m1 built bit
into the m2 repo?

If so could you point me to exactly what bits to copy?

Thanks!

-bd-

[INFO] Configured Artifact:
org.apache.geronimo.distributions:geronimo-jetty-j2ee:null:1.1-
SNAPSHOT:zip
[INFO]

[ERROR] BUILD ERROR
[INFO]

[INFO] Failed to resolve artifact.

GroupId: org.apache.geronimo.distributions
ArtifactId: geronimo-jetty-j2ee
Version: 1.1-SNAPSHOT

Reason: 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.distributions -DartifactId=geronimo-
jetty-j2ee \
 -Dversion=1.1-SNAPSHOT -Dpackaging=zip -Dfile=/path/to/file


   org.apache.geronimo.distributions:geronimo-jetty-j2ee:zip:1.1-
SNAPSHOT

from the specified remote repositories:
   central (http://repo1.maven.org/maven2),
   Maven snapshots (http://cvs.apache.org/maven-snapshot-repository)


[INFO]

[INFO] For more information, run Maven with the -e switch
[INFO]

[INFO] Total time: 4 seconds
[INFO] Finished at: Thu Jul 06 12:32:17 MDT 2006
[INFO] Final Memory: 5M/9M
[INFO]



On Jul 6, 2006, at 8:35 AM, Prasad Kashyap wrote:

 Hi Bill,

 Inline-

 On 7/6/06, Bill Dudney [EMAIL PROTECTED] wrote:
 Hi Prasad,

 
  First we needed the geronimo-deployment-plugin to be in m2. So in
  http://issues.apache.org/jira/browse/GERONIMO-1738, I got the
  deployment-plugin migarted to m2. The RTC for this is pending 2
 more
  votes. Now, if you and Jason can review and approve it, we can
 get it
  in the build.
 

 I applied the patch but it appears that there is a problem with it,
 AppTest.java has 3 copies of the code in it for example (as well as
 pom.xml and many if not all the other files).

   Here is the url to what I downloaded and I'm looking at;
 http://issues.apache.org/jira/secure/attachment/12324416/geronimo-
 deployment-plugin.patch

 which is the first patch from JIRA #1738 referenced above.

 You might want to pick up the latest patch from the Manage
 Attachments link. The patches on the JIRA page are sorted
 alphabetically. The patch that you downloaded was my initial
 submission. The other one with (
 http://issues.apache.org/jira/secure/attachment/12335875/geronimo-
 deployment-plugin-RTC-VOTE.2.patch
 ) is what you need. This was uploaded by David Jencks after reviewing
 mine and making some changes based on other reviews.

  I used to take an m1 binary distribution and manually put it
 into an
  m2 local repo for this work. Now that we are working on m2,
 hopefully
  we shall soon have the binary distributions for us to work with
  directly.
 

 An m1 distribution of G or something else?


 Yes, of G.


 Cheers
 Prasad

[jira] Commented: (GERONIMO-1737) Plugin migration to Maven 2: geronimo-assembly-plugin

2006-07-06 Thread Prasad Kashyap (JIRA)

[ 
http://issues.apache.org/jira/browse/GERONIMO-1737?page=comments#action_12419600
 ] 

Prasad Kashyap commented on GERONIMO-1737:
--

David, I think the following are missing from the bin.xml. They have to be 
merged under the relavant sections to your bin.xml


fileSets 
fileSet
  directory${basedir}/src/var/directory
  outputDirectory/var/outputDirectory
  lineEndingcrlf/lineEnding
/fileSet
/filesets


  files
file
  source${basedir}/src/var/config/config.xml/source
  outputDirectoryvar/config/outputDirectory
  destNameconfig.xml.orig/destName
  filteredtrue/filtered
  lineEndingcrlf/lineEnding
/file
file
  source${basedir}/src/var/config/config.xml/source
  outputDirectoryvar/config/outputDirectory
  destNameoffline-deployer-list/destName
  filteredtrue/filtered
  lineEndingcrlf/lineEnding
/file
  /files

 Plugin migration to Maven 2: geronimo-assembly-plugin
 -

  Key: GERONIMO-1737
  URL: http://issues.apache.org/jira/browse/GERONIMO-1737
  Project: Geronimo
 Type: Sub-task
 Security: public(Regular issues) 
   Components: buildsystem
 Versions: 1.x
 Reporter: Jacek Laskowski
 Assignee: Prasad Kashyap
  Attachments: geronimo-assembly-plugin.patch, m2-jetty-server.patch, 
 maven-assembly-plugin.patch

 It's a task to keep track of the progress of the plugin build migration to 
 Maven2

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: [RTC] Vote on GERONIMO-2161 - restart 1

IIUC, after this restart, we need one more +1 from a PMC member to  
allow these changes to be committed to the trunk.


Assuming that another +1 comes in soonish, how long shall I wait  
before applying?


--jason


On Jul 6, 2006, at 6:57 AM, Matt Hogstrom wrote:


+1 to getting this patch in...

I spent some time working with Jason and Jacek last night on this  
patch.  It is fairly large and reaching.  There appears to be an  
issue with SVN creating a bad patch file for several files but I  
don't believe this is Jason's issue but rather with SVN.


There are 5 failed hunks in the v5 patch.  I manually copied the  
files from branches/m2migration into trunk as these were the source  
of the modification.  The build was successful and I understand  
what Jason is doing here.


I am giving this patch a +1 and would like to see Jason get this  
applied at his earliest convenience.


There are issues with moving forward but getting on a better code  
base will accelerate progress on getting to a fully integrated build.


We need to understand why SVN is creating bad patches but this  
shouldn't hold up the migration to M2 effort.  This is not an issue  
with the current patch but a problem with SVN we need to undestand.


I would like to see Jason get these changes into trunk as well as  
resolve the patch issue.



Matt

*** Notations of applicability ***

Here is the output from the patch when I applied it.  I increased  
the FUZZ factor to a horrible 8 but it had no effect.



hogstrom:~/dev/geronimo/trunk hogstrom$ patch -p0 -l   ~/Downloads/ 
GERONIMO-2161-v5.patch.txt

patching file applications/ldap-realm-demo/pom.xml
Hunk #1 succeeded at 17 with fuzz 2.
patching file applications/console/console-standard/pom.xml
Hunk #1 succeeded at 17 with fuzz 2.
patching file applications/console/console-ear/pom.xml
Hunk #1 succeeded at 17 with fuzz 2.
patching file applications/console/console-core/pom.xml
Hunk #1 succeeded at 17 with fuzz 2.
patching file applications/console/pom.xml
Hunk #1 succeeded at 17 with fuzz 2.
patching file applications/console/console-framework/pom.xml
Hunk #1 succeeded at 17 with fuzz 2.
patching file applications/magicGball/magicGball-ejb/pom.xml
Hunk #1 succeeded at 17 with fuzz 2.
patching file applications/magicGball/magicGball-ear/pom.xml
Hunk #1 succeeded at 17 with fuzz 2.
patching file applications/magicGball/pom.xml
Hunk #1 succeeded at 17 with fuzz 2.
patching file applications/magicGball/magicGball-web/pom.xml
Hunk #1 succeeded at 17 with fuzz 2.
patching file applications/magicGball/magicGball-client/pom.xml
Hunk #1 succeeded at 17 with fuzz 2.
patching file applications/demo/pom.xml
Hunk #1 succeeded at 17 with fuzz 2.
patching file applications/remote-deploy/pom.xml
Hunk #1 succeeded at 17 with fuzz 2.
patching file applications/uddi-db/pom.xml
Hunk #1 succeeded at 17 with fuzz 2.
patching file applications/uddi-server/pom.xml
Hunk #1 succeeded at 17 with fuzz 2.
patching file applications/pom.xml
Hunk #1 succeeded at 17 with fuzz 2.
patching file applications/welcome/pom.xml
Hunk #1 succeeded at 17 with fuzz 2.
patching file configs/unavailable-client-deployer/pom.xml
patching file configs/welcome-tomcat/pom.xml
patching file configs/client-security/pom.xml
patching file configs/javamail/pom.xml
patching file configs/console-tomcat/pom.xml
Hunk #1 succeeded at 16 with fuzz 3.
patching file configs/tomcat/pom.xml
patching file configs/j2ee-server/pom.xml
patching file configs/pom.xml
Hunk #1 succeeded at 17 with fuzz 2.
patching file configs/activemq-broker/pom.xml
Hunk #1 succeeded at 16 with fuzz 3.
patching file configs/jsp-examples-tomcat/pom.xml
patching file configs/sharedlib/pom.xml
patching file configs/jetty/pom.xml
patching file configs/console-jetty/pom.xml
patching file configs/client-system/pom.xml
patching file configs/unavailable-ejb-deployer/pom.xml
patching file configs/openejb-deployer/pom.xml
patching file configs/directory/pom.xml
patching file configs/jsp-examples-jetty/pom.xml
patching file configs/online-deployer/pom.xml
patching file configs/j2ee-deployer/pom.xml
patching file configs/tomcat-deployer/pom.xml
patching file configs/activemq/pom.xml
Hunk #1 succeeded at 16 with fuzz 3.
patching file configs/geronimo-gbean-deployer/pom.xml
patching file configs/shutdown/pom.xml
patching file configs/hot-deployer/pom.xml
patching file configs/servlets-examples-jetty/pom.xml
patching file configs/jetty-deployer/pom.xml
patching file configs/openejb/pom.xml
patching file configs/unavailable-webservices-deployer/pom.xml
patching file configs/axis-deployer/pom.xml
patching file configs/system-database/pom.xml
patching file configs/ldap-demo-tomcat/pom.xml
patching file configs/upgrade/pom.xml
patching file configs/welcome-jetty/pom.xml
patching file configs/j2ee-security/pom.xml
patching file configs/upgrade-cli/pom.xml
patching file configs/rmi-naming/pom.xml
patching file configs/ldap-demo-jetty/pom.xml
patching file configs/client-deployer/pom.xml

Re: [RTC] Vote on GERONIMO-2161 - restart 1

2006-07-06 Thread Jeff Genender

If Jacek +1d it (I don't recall if he did) you have 3 +1s.

Jeff

Jason Dillon wrote:
 IIUC, after this restart, we need one more +1 from a PMC member to allow
 these changes to be committed to the trunk.
 
 Assuming that another +1 comes in soonish, how long shall I wait before
 applying?
 
 --jason
 
 
 On Jul 6, 2006, at 6:57 AM, Matt Hogstrom wrote:
 
 +1 to getting this patch in...

 I spent some time working with Jason and Jacek last night on this
 patch.  It is fairly large and reaching.  There appears to be an issue
 with SVN creating a bad patch file for several files but I don't
 believe this is Jason's issue but rather with SVN.

 There are 5 failed hunks in the v5 patch.  I manually copied the files
 from branches/m2migration into trunk as these were the source of the
 modification.  The build was successful and I understand what Jason is
 doing here.

 I am giving this patch a +1 and would like to see Jason get this
 applied at his earliest convenience.

 There are issues with moving forward but getting on a better code base
 will accelerate progress on getting to a fully integrated build.

 We need to understand why SVN is creating bad patches but this
 shouldn't hold up the migration to M2 effort.  This is not an issue
 with the current patch but a problem with SVN we need to undestand.

 I would like to see Jason get these changes into trunk as well as
 resolve the patch issue.


 Matt

 *** Notations of applicability ***

 Here is the output from the patch when I applied it.  I increased the
 FUZZ factor to a horrible 8 but it had no effect.


 hogstrom:~/dev/geronimo/trunk hogstrom$ patch -p0 -l  
 ~/Downloads/GERONIMO-2161-v5.patch.txt
 patching file applications/ldap-realm-demo/pom.xml
 Hunk #1 succeeded at 17 with fuzz 2.
 patching file applications/console/console-standard/pom.xml
 Hunk #1 succeeded at 17 with fuzz 2.
 patching file applications/console/console-ear/pom.xml
 Hunk #1 succeeded at 17 with fuzz 2.
 patching file applications/console/console-core/pom.xml
 Hunk #1 succeeded at 17 with fuzz 2.
 patching file applications/console/pom.xml
 Hunk #1 succeeded at 17 with fuzz 2.
 patching file applications/console/console-framework/pom.xml
 Hunk #1 succeeded at 17 with fuzz 2.
 patching file applications/magicGball/magicGball-ejb/pom.xml
 Hunk #1 succeeded at 17 with fuzz 2.
 patching file applications/magicGball/magicGball-ear/pom.xml
 Hunk #1 succeeded at 17 with fuzz 2.
 patching file applications/magicGball/pom.xml
 Hunk #1 succeeded at 17 with fuzz 2.
 patching file applications/magicGball/magicGball-web/pom.xml
 Hunk #1 succeeded at 17 with fuzz 2.
 patching file applications/magicGball/magicGball-client/pom.xml
 Hunk #1 succeeded at 17 with fuzz 2.
 patching file applications/demo/pom.xml
 Hunk #1 succeeded at 17 with fuzz 2.
 patching file applications/remote-deploy/pom.xml
 Hunk #1 succeeded at 17 with fuzz 2.
 patching file applications/uddi-db/pom.xml
 Hunk #1 succeeded at 17 with fuzz 2.
 patching file applications/uddi-server/pom.xml
 Hunk #1 succeeded at 17 with fuzz 2.
 patching file applications/pom.xml
 Hunk #1 succeeded at 17 with fuzz 2.
 patching file applications/welcome/pom.xml
 Hunk #1 succeeded at 17 with fuzz 2.
 patching file configs/unavailable-client-deployer/pom.xml
 patching file configs/welcome-tomcat/pom.xml
 patching file configs/client-security/pom.xml
 patching file configs/javamail/pom.xml
 patching file configs/console-tomcat/pom.xml
 Hunk #1 succeeded at 16 with fuzz 3.
 patching file configs/tomcat/pom.xml
 patching file configs/j2ee-server/pom.xml
 patching file configs/pom.xml
 Hunk #1 succeeded at 17 with fuzz 2.
 patching file configs/activemq-broker/pom.xml
 Hunk #1 succeeded at 16 with fuzz 3.
 patching file configs/jsp-examples-tomcat/pom.xml
 patching file configs/sharedlib/pom.xml
 patching file configs/jetty/pom.xml
 patching file configs/console-jetty/pom.xml
 patching file configs/client-system/pom.xml
 patching file configs/unavailable-ejb-deployer/pom.xml
 patching file configs/openejb-deployer/pom.xml
 patching file configs/directory/pom.xml
 patching file configs/jsp-examples-jetty/pom.xml
 patching file configs/online-deployer/pom.xml
 patching file configs/j2ee-deployer/pom.xml
 patching file configs/tomcat-deployer/pom.xml
 patching file configs/activemq/pom.xml
 Hunk #1 succeeded at 16 with fuzz 3.
 patching file configs/geronimo-gbean-deployer/pom.xml
 patching file configs/shutdown/pom.xml
 patching file configs/hot-deployer/pom.xml
 patching file configs/servlets-examples-jetty/pom.xml
 patching file configs/jetty-deployer/pom.xml
 patching file configs/openejb/pom.xml
 patching file configs/unavailable-webservices-deployer/pom.xml
 patching file configs/axis-deployer/pom.xml
 patching file configs/system-database/pom.xml
 patching file configs/ldap-demo-tomcat/pom.xml
 patching file configs/upgrade/pom.xml
 patching file configs/welcome-jetty/pom.xml
 patching file configs/j2ee-security/pom.xml
 patching file

Re: [RTC] Vote on GERONIMO-2161 - restart 1


I don't recall Jacek +1'ing... before or after the restart.

 * * *

But, I was more curious how long after the next +1 comes in I should  
wait before applying this?


--jason


On Jul 6, 2006, at 2:08 PM, Jeff Genender wrote:


If Jacek +1d it (I don't recall if he did) you have 3 +1s.

Jeff

Jason Dillon wrote:
IIUC, after this restart, we need one more +1 from a PMC member to  
allow

these changes to be committed to the trunk.

Assuming that another +1 comes in soonish, how long shall I wait  
before

applying?

--jason


On Jul 6, 2006, at 6:57 AM, Matt Hogstrom wrote:


+1 to getting this patch in...

I spent some time working with Jason and Jacek last night on this
patch.  It is fairly large and reaching.  There appears to be an  
issue

with SVN creating a bad patch file for several files but I don't
believe this is Jason's issue but rather with SVN.

There are 5 failed hunks in the v5 patch.  I manually copied the  
files

from branches/m2migration into trunk as these were the source of the
modification.  The build was successful and I understand what  
Jason is

doing here.

I am giving this patch a +1 and would like to see Jason get this
applied at his earliest convenience.

There are issues with moving forward but getting on a better code  
base

will accelerate progress on getting to a fully integrated build.

We need to understand why SVN is creating bad patches but this
shouldn't hold up the migration to M2 effort.  This is not an issue
with the current patch but a problem with SVN we need to undestand.

I would like to see Jason get these changes into trunk as well as
resolve the patch issue.


Matt

*** Notations of applicability ***

Here is the output from the patch when I applied it.  I increased  
the

FUZZ factor to a horrible 8 but it had no effect.


hogstrom:~/dev/geronimo/trunk hogstrom$ patch -p0 -l  
~/Downloads/GERONIMO-2161-v5.patch.txt
patching file applications/ldap-realm-demo/pom.xml
Hunk #1 succeeded at 17 with fuzz 2.
patching file applications/console/console-standard/pom.xml
Hunk #1 succeeded at 17 with fuzz 2.
patching file applications/console/console-ear/pom.xml
Hunk #1 succeeded at 17 with fuzz 2.
patching file applications/console/console-core/pom.xml
Hunk #1 succeeded at 17 with fuzz 2.
patching file applications/console/pom.xml
Hunk #1 succeeded at 17 with fuzz 2.
patching file applications/console/console-framework/pom.xml
Hunk #1 succeeded at 17 with fuzz 2.
patching file applications/magicGball/magicGball-ejb/pom.xml
Hunk #1 succeeded at 17 with fuzz 2.
patching file applications/magicGball/magicGball-ear/pom.xml
Hunk #1 succeeded at 17 with fuzz 2.
patching file applications/magicGball/pom.xml
Hunk #1 succeeded at 17 with fuzz 2.
patching file applications/magicGball/magicGball-web/pom.xml
Hunk #1 succeeded at 17 with fuzz 2.
patching file applications/magicGball/magicGball-client/pom.xml
Hunk #1 succeeded at 17 with fuzz 2.
patching file applications/demo/pom.xml
Hunk #1 succeeded at 17 with fuzz 2.
patching file applications/remote-deploy/pom.xml
Hunk #1 succeeded at 17 with fuzz 2.
patching file applications/uddi-db/pom.xml
Hunk #1 succeeded at 17 with fuzz 2.
patching file applications/uddi-server/pom.xml
Hunk #1 succeeded at 17 with fuzz 2.
patching file applications/pom.xml
Hunk #1 succeeded at 17 with fuzz 2.
patching file applications/welcome/pom.xml
Hunk #1 succeeded at 17 with fuzz 2.
patching file configs/unavailable-client-deployer/pom.xml
patching file configs/welcome-tomcat/pom.xml
patching file configs/client-security/pom.xml
patching file configs/javamail/pom.xml
patching file configs/console-tomcat/pom.xml
Hunk #1 succeeded at 16 with fuzz 3.
patching file configs/tomcat/pom.xml
patching file configs/j2ee-server/pom.xml
patching file configs/pom.xml
Hunk #1 succeeded at 17 with fuzz 2.
patching file configs/activemq-broker/pom.xml
Hunk #1 succeeded at 16 with fuzz 3.
patching file configs/jsp-examples-tomcat/pom.xml
patching file configs/sharedlib/pom.xml
patching file configs/jetty/pom.xml
patching file configs/console-jetty/pom.xml
patching file configs/client-system/pom.xml
patching file configs/unavailable-ejb-deployer/pom.xml
patching file configs/openejb-deployer/pom.xml
patching file configs/directory/pom.xml
patching file configs/jsp-examples-jetty/pom.xml
patching file configs/online-deployer/pom.xml
patching file configs/j2ee-deployer/pom.xml
patching file configs/tomcat-deployer/pom.xml
patching file configs/activemq/pom.xml
Hunk #1 succeeded at 16 with fuzz 3.
patching file configs/geronimo-gbean-deployer/pom.xml
patching file configs/shutdown/pom.xml
patching file configs/hot-deployer/pom.xml
patching file configs/servlets-examples-jetty/pom.xml
patching file configs/jetty-deployer/pom.xml
patching file configs/openejb/pom.xml
patching file configs/unavailable-webservices-deployer/pom.xml
patching file configs/axis-deployer/pom.xml
patching file configs/system-database/pom.xml
patching file configs/ldap-demo-tomcat/pom.xml

Re: [RTC] Vote on GERONIMO-2161 - restart 1


On 7/6/06, Jason Dillon [EMAIL PROTECTED] wrote:

IIUC, after this restart, we need one more +1 from a PMC member to
allow these changes to be committed to the trunk.

Assuming that another +1 comes in soonish, how long shall I wait
before applying?


+1 (I did review it only as I had troubles test it out thorougly)

Wait 18 hours and go ahead. 18 hours will let the sun round the globe
so others get a chance to vote...against ;-)


--jason


Jacek

--
Jacek Laskowski
http://www.laskowski.net.pl

Re: openejb itests?

2006-07-06 Thread Bill Dudney

Hi Prasad,Thanks, - I guess I was hoping that it was something smaller :-)I had to;1) install the jetty version but changed version to 1.1 and updated itests/pom.xml to reflect 1.1. instead of 1.1-SNAPSHOT2) install the tomcat version but changed version to 1.1 and updated itests/pom.xml  to reflect 1.1. instead of 1.1-SNAPSHOT3) enable the utils 3) delete the explicit mention of version from the maven-site-plugin in teardown-tests.pom.xml4) add junit as a dependency otherwise the mvn failed unless -Dmaven.test.skip=true was specified5) run mvnAlthough the build succeeds, nothing appears to happen (see attached log)From what I can tell the geronimo-deployment-plugin is not being built correctly, none of the src's are being compiled and placed into the jar file. I poked around but the reason escapes me...TTFN,Bill DudneyMyFaces - http://myfaces.apache.orgCayenne - http://incubator.apache.org/projects/cayenne.html[INFO] Scanning for projects...[INFO] Reactor build order: [INFO]   Geronimo Integration Tests[INFO]   Geronimo :: itests :: system[INFO]   Geronimo :: itests :: webcontainer[INFO]   Geronimo :: itests :: teardown[INFO] [INFO] Building Geronimo Integration Tests[INFO]    task-segment: [install][INFO] [INFO] [site:attach-descriptor][INFO] [dependency:unpack {execution: unpack}][INFO] Configured Artifact: org.apache.geronimo.distributions:geronimo-jetty-j2ee:null:1.1:zip[INFO] geronimo-jetty-j2ee-1.1.zip already unpacked.Downloading: http://cvs.apache.org/maven-snapshot-repository/org/apache/geronimo/distributions/geronimo-tomcat-j2ee/1.1/geronimo-tomcat-j2ee-1.1.pom[WARNING] Unable to get resource from repository Maven snapshots (http://cvs.apache.org/maven-snapshot-repository)Downloading: http://repo1.maven.org/maven2/org/apache/geronimo/distributions/geronimo-tomcat-j2ee/1.1/geronimo-tomcat-j2ee-1.1.pom[WARNING] Unable to get resource from repository central (http://repo1.maven.org/maven2)Downloading: http://cvs.apache.org/maven-snapshot-repository/org/apache/geronimo/distributions/geronimo-jetty-j2ee/1.1/geronimo-jetty-j2ee-1.1.pom[WARNING] Unable to get resource from repository Maven snapshots (http://cvs.apache.org/maven-snapshot-repository)Downloading: http://repo1.maven.org/maven2/org/apache/geronimo/distributions/geronimo-jetty-j2ee/1.1/geronimo-jetty-j2ee-1.1.pom[WARNING] Unable to get resource from repository central (http://repo1.maven.org/maven2)[INFO] [antrun:run {execution: prepare}][INFO] Executing tasks   [delete] Deleting 1 files from /private/tmp/foo/sandbox/itests/target/logs    [touch] Creating /private/tmp/foo/sandbox/itests/target/logs/results.log[INFO] Executed tasks[INFO] [install:install][INFO] Installing /private/tmp/foo/sandbox/itests/pom.xml to /Users/bdudney/.m2/repository/org/apache/geronimo/itests/geronimo-itests-parent/1.0/geronimo-itests-parent-1.0.pom[INFO] [INFO] Building Geronimo :: itests :: system[INFO]    task-segment: [install][INFO] [INFO] [resources:resources][INFO] Using default encoding to copy filtered resources.[INFO] [compiler:compile][INFO] Nothing to compile - all classes are up to date[INFO] [resources:testResources][INFO] Using default encoding to copy filtered resources.[INFO] [compiler:testCompile][INFO] Nothing to compile - all classes are up to date[INFO] [surefire:test][INFO] No tests to run.[INFO] [jar:jar][WARNING] JAR will be empty - no content was marked for inclusion![INFO] Building jar: /private/tmp/foo/sandbox/itests/system-tests/target/system-tests-1.0.jar[INFO] [antrun:run {execution: prepare}][INFO] Executing tasks   [delete] Deleting 1 files from /private/tmp/foo/sandbox/itests/system-tests/target/logs    [touch] Creating /private/tmp/foo/sandbox/itests/system-tests/target/logs/results.log[INFO] Executed tasks[INFO] [install:install][INFO] Installing /private/tmp/foo/sandbox/itests/system-tests/target/system-tests-1.0.jar to /Users/bdudney/.m2/repository/org/apache/geronimo/itests/system-tests/1.0/system-tests-1.0.jar[INFO] [INFO] Building Geronimo :: itests :: webcontainer[INFO]    task-segment: [install][INFO] [INFO] [resources:resources][INFO] Using default encoding to copy filtered resources.[INFO] [compiler:compile][INFO] Nothing to compile - all classes are up to date[INFO] [resources:testResources][INFO] Using default encoding to copy filtered resources.[INFO] [compiler:testCompile][INFO] Nothing to compile - all classes are up to date[INFO] [surefire:test][INFO] Surefire report directory:

[jira] Commented: (GERONIMO-1737) Plugin migration to Maven 2: geronimo-assembly-plugin

2006-07-06 Thread David Jencks (JIRA)

[ 
http://issues.apache.org/jira/browse/GERONIMO-1737?page=comments#action_12419616
 ] 

David Jencks commented on GERONIMO-1737:


I agree about the additions to my patch.  Just to be clear, my patch is 
informative work in progress, it should not be committed at this point because 
it does not start a lot of the configs since they aren't available yet for the 
m2 server.

 Plugin migration to Maven 2: geronimo-assembly-plugin
 -

  Key: GERONIMO-1737
  URL: http://issues.apache.org/jira/browse/GERONIMO-1737
  Project: Geronimo
 Type: Sub-task
 Security: public(Regular issues) 
   Components: buildsystem
 Versions: 1.x
 Reporter: Jacek Laskowski
 Assignee: Prasad Kashyap
  Attachments: geronimo-assembly-plugin.patch, m2-jetty-server.patch, 
 maven-assembly-plugin.patch

 It's a task to keep track of the progress of the plugin build migration to 
 Maven2

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: [RTC] Vote on GERONIMO-2161 - restart 1

2006-07-06 Thread David Jencks



On Jul 6, 2006, at 2:09 PM, Jason Dillon wrote:


I don't recall Jacek +1'ing... before or after the restart.

 * * *

But, I was more curious how long after the next +1 comes in I  
should wait before applying this?
My point of view is that while there might be a minimum time needed  
in total for a vote, there is no need to wait after the 3rd +1 as  
long as that minumum time since the start of the vote has elapsed.   
This vote has been going on with additions for 5 days now with no  
technical objections, although  jason has enhanced the patch in  
several ways.  Anyone with the slightest concerns about this patch  
has had more than adequate time to object, and they continue to be  
able to object till the heat death of the universe.


Commit it now. (non binding)

david jencks



--jason


On Jul 6, 2006, at 2:08 PM, Jeff Genender wrote:


If Jacek +1d it (I don't recall if he did) you have 3 +1s.

Jeff

Jason Dillon wrote:
IIUC, after this restart, we need one more +1 from a PMC member  
to allow

these changes to be committed to the trunk.

Assuming that another +1 comes in soonish, how long shall I wait  
before

applying?

--jason


On Jul 6, 2006, at 6:57 AM, Matt Hogstrom wrote:


+1 to getting this patch in...

I spent some time working with Jason and Jacek last night on this
patch.  It is fairly large and reaching.  There appears to be an  
issue

with SVN creating a bad patch file for several files but I don't
believe this is Jason's issue but rather with SVN.

There are 5 failed hunks in the v5 patch.  I manually copied the  
files
from branches/m2migration into trunk as these were the source of  
the
modification.  The build was successful and I understand what  
Jason is

doing here.

I am giving this patch a +1 and would like to see Jason get this
applied at his earliest convenience.

There are issues with moving forward but getting on a better  
code base

will accelerate progress on getting to a fully integrated build.

We need to understand why SVN is creating bad patches but this
shouldn't hold up the migration to M2 effort.  This is not an issue
with the current patch but a problem with SVN we need to undestand.

I would like to see Jason get these changes into trunk as well as
resolve the patch issue.


Matt

*** Notations of applicability ***

Here is the output from the patch when I applied it.  I  
increased the

FUZZ factor to a horrible 8 but it had no effect.


hogstrom:~/dev/geronimo/trunk hogstrom$ patch -p0 -l  
~/Downloads/GERONIMO-2161-v5.patch.txt
patching file applications/ldap-realm-demo/pom.xml
Hunk #1 succeeded at 17 with fuzz 2.
patching file applications/console/console-standard/pom.xml
Hunk #1 succeeded at 17 with fuzz 2.
patching file applications/console/console-ear/pom.xml
Hunk #1 succeeded at 17 with fuzz 2.
patching file applications/console/console-core/pom.xml
Hunk #1 succeeded at 17 with fuzz 2.
patching file applications/console/pom.xml
Hunk #1 succeeded at 17 with fuzz 2.
patching file applications/console/console-framework/pom.xml
Hunk #1 succeeded at 17 with fuzz 2.
patching file applications/magicGball/magicGball-ejb/pom.xml
Hunk #1 succeeded at 17 with fuzz 2.
patching file applications/magicGball/magicGball-ear/pom.xml
Hunk #1 succeeded at 17 with fuzz 2.
patching file applications/magicGball/pom.xml
Hunk #1 succeeded at 17 with fuzz 2.
patching file applications/magicGball/magicGball-web/pom.xml
Hunk #1 succeeded at 17 with fuzz 2.
patching file applications/magicGball/magicGball-client/pom.xml
Hunk #1 succeeded at 17 with fuzz 2.
patching file applications/demo/pom.xml
Hunk #1 succeeded at 17 with fuzz 2.
patching file applications/remote-deploy/pom.xml
Hunk #1 succeeded at 17 with fuzz 2.
patching file applications/uddi-db/pom.xml
Hunk #1 succeeded at 17 with fuzz 2.
patching file applications/uddi-server/pom.xml
Hunk #1 succeeded at 17 with fuzz 2.
patching file applications/pom.xml
Hunk #1 succeeded at 17 with fuzz 2.
patching file applications/welcome/pom.xml
Hunk #1 succeeded at 17 with fuzz 2.
patching file configs/unavailable-client-deployer/pom.xml
patching file configs/welcome-tomcat/pom.xml
patching file configs/client-security/pom.xml
patching file configs/javamail/pom.xml
patching file configs/console-tomcat/pom.xml
Hunk #1 succeeded at 16 with fuzz 3.
patching file configs/tomcat/pom.xml
patching file configs/j2ee-server/pom.xml
patching file configs/pom.xml
Hunk #1 succeeded at 17 with fuzz 2.
patching file configs/activemq-broker/pom.xml
Hunk #1 succeeded at 16 with fuzz 3.
patching file configs/jsp-examples-tomcat/pom.xml
patching file configs/sharedlib/pom.xml
patching file configs/jetty/pom.xml
patching file configs/console-jetty/pom.xml
patching file configs/client-system/pom.xml
patching file configs/unavailable-ejb-deployer/pom.xml
patching file configs/openejb-deployer/pom.xml
patching file configs/directory/pom.xml
patching file configs/jsp-examples-jetty/pom.xml
patching file configs/online-deployer/pom.xml
patching

Re: [RTC] Vote on GERONIMO-2161 - restart 1


w00t!

--jason


On Jul 6, 2006, at 4:54 PM, Jeff Genender wrote:


Consider it blessed. ;-)

Jason Dillon wrote:

On Jul 6, 2006, at 4:23 PM, David Jencks wrote:
My point of view is that while there might be a minimum time  
needed in
total for a vote, there is no need to wait after the 3rd +1 as  
long as
that minumum time since the start of the vote has elapsed.  This  
vote

has been going on with additions for 5 days now with no technical
objections, although  jason has enhanced the patch in several ways.
Anyone with the slightest concerns about this patch has had more  
than

adequate time to object, and they continue to be able to object till
the heat death of the universe.

Commit it now. (non binding)


I'd be more than happy to do so if someone from the PMC would  
bless that

action.

--jason

[jira] Created: (GERONIMO-2167) deployer.jar not cleaning up properly during redeploy and undeploy

2006-07-06 Thread Leonard Wu (JIRA)

deployer.jar not cleaning up properly during redeploy and undeploy
--

 Key: GERONIMO-2167
 URL: http://issues.apache.org/jira/browse/GERONIMO-2167
 Project: Geronimo
Type: Bug
Security: public (Regular issues) 
  Components: deployment  
Versions: 1.1
 Environment: Win32/XP SP1
Sun JDK 1.5_06
Reporter: Leonard Wu


deployment using deploy.jar doesn't appear to clean up correctly.

first deploy always works. subsequent re-deploy and un-deploy are problematic.

following illustrates the full sequence of events as i had encountered:

--

D:\work\SERVER\geronimo-1.1\binc:\JDK\jdk1.5.0_06\bin\java.exe -jar deployer.ja
r --user system --password manager deploy D:/work/SERVER/dwr-demo.war
Deployed littleoldme/dwrdemo/1.1/war @ http://vaio:8080/dwr-demo

D:\work\SERVER\geronimo-1.1\binc:\JDK\jdk1.5.0_06\bin\java.exe -jar deployer.ja
r --user system --password manager redeploy D:/work/SERVER/dwr-demo.war
No ModuleID or TargetModuleID provided.  Attempting to guess based
on the content of the archive.
Attempting to use ModuleID 'littleoldme/dwrdemo/1.1/war'
Stopped littleoldme/dwrdemo/1.1/war
Unloaded littleoldme/dwrdemo/1.1/war
Uninstalled littleoldme/dwrdemo/1.1/war
Deployed littleoldme/dwrdemo/1.1/war
Started littleoldme/dwrdemo/1.1/war
Redeployed littleoldme/dwrdemo/1.1/war

D:\work\SERVER\geronimo-1.1\binc:\JDK\jdk1.5.0_06\bin\java.exe -jar deployer.ja
r --user system --password manager redeploy D:/work/SERVER/dwr-demo.war
No ModuleID or TargetModuleID provided.  Attempting to guess based
on the content of the archive.
Attempting to use ModuleID 'littleoldme/dwrdemo/1.1/war'
Stopped littleoldme/dwrdemo/1.1/war
Unloaded littleoldme/dwrdemo/1.1/war
Uninstalled littleoldme/dwrdemo/1.1/war
Error: Operation failed:
org.apache.geronimo.kernel.config.ConfigurationAlreadyExistsException:
Configuration already exists: littleoldme/dwrdemo/1.1/war

Configuration already exists: littleoldme/dwrdemo/1.1/war

D:\work\SERVER\geronimo-1.1\binc:\JDK\jdk1.5.0_06\bin\java.exe -jar deployer.ja
r --user system --password manager undeploy littleoldme/dwrdemo/1.1/war
Error: littleoldme/dwrdemo/1.1/war does not appear to be a the name
of a module available on the selected server. Perhaps it has already
been stopped or undeployed?  If you're trying to specify a
TargetModuleID, use the syntax TargetName|ModuleName instead. If
you're not sure what's running, try the list-modules command.

--

While in this broken state, i'm able to recover by manually removing the 
${geronimo}/repository/littleoldme directory and removing the one line in 
${geronimo}/var/config/config.xml that says

module load=false name=littleoldme/dwrdemo/1.1/war/

However, this only gets me to a fresh beginning, and then the whole sequence 
starts again as I repeat (re/un)deploying.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Commented: (GERONIMO-2167) deployer.jar not cleaning up properly during redeploy and undeploy

2006-07-06 Thread Leonard Wu (JIRA)

[ 
http://issues.apache.org/jira/browse/GERONIMO-2167?page=comments#action_12419630
 ] 

Leonard Wu commented on GERONIMO-2167:
--

deployment plan, geronimo-web.xml is included in the WAR

 deployer.jar not cleaning up properly during redeploy and undeploy
 --

  Key: GERONIMO-2167
  URL: http://issues.apache.org/jira/browse/GERONIMO-2167
  Project: Geronimo
 Type: Bug
 Security: public(Regular issues) 
   Components: deployment
 Versions: 1.1
  Environment: Win32/XP SP1
 Sun JDK 1.5_06
 Reporter: Leonard Wu
  Attachments: dwr-demo.war

 deployment using deploy.jar doesn't appear to clean up correctly.
 first deploy always works. subsequent re-deploy and un-deploy are problematic.
 following illustrates the full sequence of events as i had encountered:
 --
 D:\work\SERVER\geronimo-1.1\binc:\JDK\jdk1.5.0_06\bin\java.exe -jar 
 deployer.ja
 r --user system --password manager deploy D:/work/SERVER/dwr-demo.war
 Deployed littleoldme/dwrdemo/1.1/war @ http://vaio:8080/dwr-demo
 D:\work\SERVER\geronimo-1.1\binc:\JDK\jdk1.5.0_06\bin\java.exe -jar 
 deployer.ja
 r --user system --password manager redeploy D:/work/SERVER/dwr-demo.war
 No ModuleID or TargetModuleID provided.  Attempting to guess based
 on the content of the archive.
 Attempting to use ModuleID 'littleoldme/dwrdemo/1.1/war'
 Stopped littleoldme/dwrdemo/1.1/war
 Unloaded littleoldme/dwrdemo/1.1/war
 Uninstalled littleoldme/dwrdemo/1.1/war
 Deployed littleoldme/dwrdemo/1.1/war
 Started littleoldme/dwrdemo/1.1/war
 Redeployed littleoldme/dwrdemo/1.1/war
 D:\work\SERVER\geronimo-1.1\binc:\JDK\jdk1.5.0_06\bin\java.exe -jar 
 deployer.ja
 r --user system --password manager redeploy D:/work/SERVER/dwr-demo.war
 No ModuleID or TargetModuleID provided.  Attempting to guess based
 on the content of the archive.
 Attempting to use ModuleID 'littleoldme/dwrdemo/1.1/war'
 Stopped littleoldme/dwrdemo/1.1/war
 Unloaded littleoldme/dwrdemo/1.1/war
 Uninstalled littleoldme/dwrdemo/1.1/war
 Error: Operation failed:
 org.apache.geronimo.kernel.config.ConfigurationAlreadyExistsException:
 Configuration already exists: littleoldme/dwrdemo/1.1/war
 Configuration already exists: littleoldme/dwrdemo/1.1/war
 D:\work\SERVER\geronimo-1.1\binc:\JDK\jdk1.5.0_06\bin\java.exe -jar 
 deployer.ja
 r --user system --password manager undeploy littleoldme/dwrdemo/1.1/war
 Error: littleoldme/dwrdemo/1.1/war does not appear to be a the name
 of a module available on the selected server. Perhaps it has already
 been stopped or undeployed?  If you're trying to specify a
 TargetModuleID, use the syntax TargetName|ModuleName instead. If
 you're not sure what's running, try the list-modules command.
 --
 While in this broken state, i'm able to recover by manually removing the 
 ${geronimo}/repository/littleoldme directory and removing the one line in 
 ${geronimo}/var/config/config.xml that says
 module load=false name=littleoldme/dwrdemo/1.1/war/
 However, this only gets me to a fresh beginning, and then the whole sequence 
 starts again as I repeat (re/un)deploying.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Created: (AMQ-799) Handle async ConnectionError that may happen between brokers using a network bridge.

2006-07-06 Thread Hiram Chirino (JIRA)

Handle async ConnectionError that may happen between brokers using a network 
bridge.


 Key: AMQ-799
 URL: https://issues.apache.org/activemq/browse/AMQ-799
 Project: ActiveMQ
Type: Bug

  Components: Broker  
Versions: 4.0
Reporter: Hiram Chirino
 Fix For: 4.1, 4.0.2




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Resolved: (AMQ-799) Handle async ConnectionError that may happen between brokers using a network bridge.

2006-07-06 Thread Hiram Chirino (JIRA)

 [ https://issues.apache.org/activemq/browse/AMQ-799?page=all ]
 
Hiram Chirino resolved AMQ-799:
---

Resolution: Fixed

 Handle async ConnectionError that may happen between brokers using a network 
 bridge.
 

  Key: AMQ-799
  URL: https://issues.apache.org/activemq/browse/AMQ-799
  Project: ActiveMQ
 Type: Bug

   Components: Broker
 Versions: 4.0
 Reporter: Hiram Chirino
  Fix For: 4.1, 4.0.2





-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Added confluence pages Committing patches to the Subversion Repository and How to prepare and contribute patches

2006-07-06 Thread John Sisson

I have added the page Committing patches to the Subversion Repository 
as a place to document the issues/recommendations involved in applying 
and committing patches. See 
http://cwiki.apache.org/confluence/display/GMOxDEV/Committing+patches+to+the+Subversion+Repository


It is very much under construction and is based upon a mail from the 
derby lists that discussed processes for committing patches 
http://mail-archives.apache.org/mod_mbox/db-derby-dev/200603.mbox/[EMAIL PROTECTED] 



I haven't spent much time on it yet, but thought it would be worthwhile 
getting a confluence page started that everyone can update with their 
encounters with patches so we can develop some guidelines that can be 
used for people new to the project in the future.


I have also created a related How to prepare and contribute patches 
page.  
http://cwiki.apache.org/confluence/display/GMOxDEV/How+to+prepare+and+contribute+patches
Currently this just contains some links to some similar pages on other 
projects that may have some useful content.  If anyone knows of other 
pages that may provide a good base to work from, please to add them to 
the page.


Regards,

John

Re: openejb itests?


I just built the geronimo-deployment-plugin from this patch (
http://issues.apache.org/jira/secure/attachment/12335875/geronimo-deployment-plugin-RTC-VOTE.2.patch
). It built successfully and installed in the local m2 repo.

It's been a good 3-4 months since I last worked on itests but it is
all coming back to me now. This seems to be a good time for me to
start looking at itests again. Currently I could make use of this
breather in the m2 migration work as issues like RTC, trunk or branch,
invalid poms etc are sorted out.  We still don't have a m2
distribution but we are slowly getting there.

Cheers
Prasad.


On 7/6/06, Bill Dudney [EMAIL PROTECTED] wrote:


Hi Prasad,

Thanks, - I guess I was hoping that it was something smaller :-)

I had to;
1) install the jetty version but changed version to 1.1 and updated
itests/pom.xml to reflect 1.1. instead of 1.1-SNAPSHOT
2) install the tomcat version but changed version to 1.1 and updated
itests/pom.xml  to reflect 1.1. instead of 1.1-SNAPSHOT
3) enable the utils
3) delete the explicit mention of version from the maven-site-plugin in
teardown-tests.pom.xml
4) add junit as a dependency otherwise the mvn failed unless
-Dmaven.test.skip=true was specified
5) run mvn

Although the build succeeds, nothing appears to happen (see attached log)

From what I can tell the geronimo-deployment-plugin is not being built
correctly, none of the src's are being compiled and placed into the jar
file. I poked around but the reason escapes me...

TTFN,


Bill Dudney
MyFaces - http://myfaces.apache.org
Cayenne - http://incubator.apache.org/projects/cayenne.html



[INFO] Scanning for projects...
[INFO] Reactor build order:
[INFO]   Geronimo Integration Tests
[INFO]   Geronimo :: itests :: system
[INFO]   Geronimo :: itests :: webcontainer
[INFO]   Geronimo :: itests :: teardown
[INFO]

[INFO] Building Geronimo Integration Tests
[INFO]task-segment: [install]
[INFO]

[INFO] [site:attach-descriptor]
[INFO] [dependency:unpack {execution: unpack}]
[INFO] Configured Artifact:
org.apache.geronimo.distributions:geronimo-jetty-j2ee:null:1.1:zip
[INFO] geronimo-jetty-j2ee-1.1.zip already unpacked.
Downloading:
http://cvs.apache.org/maven-snapshot-repository/org/apache/geronimo/distributions/geronimo-tomcat-j2ee/1.1/geronimo-tomcat-j2ee-1.1.pom
[WARNING] Unable to get resource from repository Maven snapshots
(http://cvs.apache.org/maven-snapshot-repository)
Downloading:
http://repo1.maven.org/maven2/org/apache/geronimo/distributions/geronimo-tomcat-j2ee/1.1/geronimo-tomcat-j2ee-1.1.pom
[WARNING] Unable to get resource from repository central
(http://repo1.maven.org/maven2)
Downloading:
http://cvs.apache.org/maven-snapshot-repository/org/apache/geronimo/distributions/geronimo-jetty-j2ee/1.1/geronimo-jetty-j2ee-1.1.pom
[WARNING] Unable to get resource from repository Maven snapshots
(http://cvs.apache.org/maven-snapshot-repository)
Downloading:
http://repo1.maven.org/maven2/org/apache/geronimo/distributions/geronimo-jetty-j2ee/1.1/geronimo-jetty-j2ee-1.1.pom
[WARNING] Unable to get resource from repository central
(http://repo1.maven.org/maven2)
[INFO] [antrun:run {execution: prepare}]
[INFO] Executing tasks
   [delete] Deleting 1 files from
/private/tmp/foo/sandbox/itests/target/logs
[touch] Creating
/private/tmp/foo/sandbox/itests/target/logs/results.log
[INFO] Executed tasks
[INFO] [install:install]
[INFO] Installing /private/tmp/foo/sandbox/itests/pom.xml
to
/Users/bdudney/.m2/repository/org/apache/geronimo/itests/geronimo-itests-parent/1.0/geronimo-itests-parent-1.0.pom
[INFO]

[INFO] Building Geronimo :: itests :: system
[INFO]task-segment: [install]
[INFO]

[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] Nothing to compile - all classes are up to date
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
[INFO] Nothing to compile - all classes are up to date
[INFO] [surefire:test]
[INFO] No tests to run.
[INFO] [jar:jar]
[WARNING] JAR will be empty - no content was marked for inclusion!
[INFO] Building jar:
/private/tmp/foo/sandbox/itests/system-tests/target/system-tests-1.0.jar
[INFO] [antrun:run {execution: prepare}]
[INFO] Executing tasks
   [delete] Deleting 1 files from
/private/tmp/foo/sandbox/itests/system-tests/target/logs
[touch] Creating
/private/tmp/foo/sandbox/itests/system-tests/target/logs/results.log
[INFO] Executed tasks
[INFO] [install:install]
[INFO] Installing
/private/tmp/foo/sandbox/itests/system-tests/target/system-tests-1.0.jar
to

FYI: Planning to upgrade to Derby 10.1.3 for the Geronimo 1.1.1 release (GERONIMO-2155)

2006-07-06 Thread John Sisson

In the Derby library does not have line number debug information mail 
thread [1] a few weeks ago I asked whether people wanted to upgrade to 
the Derby 10.1.3 maintenance release [2].


David Jencks was the only person who mentioned it should go in the 1.1.1 
release but did not hear any objections from others.  If anyone 
disagrees with this plan, please speak up before I start looking into 
this next week.


John

[1] http://www.mail-archive.com/dev@geronimo.apache.org/msg25051.html
[2] 
http://mail-archives.apache.org/mod_mbox/db-derby-user/200607.mbox/[EMAIL PROTECTED]

Re: tag 1.0.0 does not build - missing dependencies

2006-07-06 Thread Kevan Miller



On Jul 3, 2006, at 8:29 PM, Simon Godik wrote:

I'm having difficulty building 1.0.0 tag. Dependencies are missing:  
commons-fileupload-1.1-dev.jar, dwr-1.0.jar,  
org.apache.geronimo.specs/geronimo-corba_2.3_spec/1.0/jar
I did not get past corba dependency. Any special instructions for  
1.0 tag?


Simon,
There was an inconsistency between the Geronimo and OpenEJB  
dependencies in Geronimo 1.0. See http://issues.apache.org/jira/ 
browse/GERONIMO-1449


To fix, you can apply the patch attached to the Jira to your configs/ 
j2ee-server/project.xml file or manually download the jar.


Also, you'll want to change line 29 of your etc/project.properties  
file to use the new apache repo url (I suspect you've done this  
already):


Index: etc/project.properties
===
--- etc/project.properties  (revision 419225)
+++ etc/project.properties  (working copy)
@@ -26,7 +26,7 @@
#
maven.repo.remote=\
-http://cvs.apache.org/repository,\
+http://people.apache.org/repository,\
http://dist.codehaus.org,\
http://www.mortbay.org/maven,\
http://www.ibiblio.org/maven,\

--kevan

Re: svn commit: r419764 - /geronimo/trunk/m2-plugins/pom.xml