Re: [RTC] update contributors page
Jacek Laskowski wrote: On 6/27/06, Jeff Genender <[EMAIL PROTECTED]> wrote: I did it the old fashioned way... I updated the svn for the raw code, then I made a short cut and just edited the actual site. Made it so I didn't have to publish the whole thing...I cheated ;-) Does anyone know what the proper steps are? I wish to give it a shot. Jeff Jacek Try following the instructions in the following file: https://svn.apache.org/repos/asf/geronimo/site/trunk/NOTES.txt If it doesn't work, discuss it and lets ensure the instructions get updated. Regards, John
Re: Enable wiki-rendering for GERONIMO JIRA project
Jacek Laskowski wrote: On 6/27/06, Jason Dillon <[EMAIL PROTECTED]> wrote: Any objections to enabling wiki-rendering for the GERONIMO JIRA project? This will allow comment and description fields to utilize Confluence- style wiki markup. Don't know what it will give us, but sounds fine. Its basically just a configuration change, done project by project. I think this is a good idea. Do we need to vote this change in? Or shall we just enable it if there is no negative comments? No, you don't need a RTC vote (it falls into documentation category), but awaiting others' comment is greatly appreciated. Just wait till 48 hours pass and implement it (looking forward to seeing it myself what you meant :-)). --jason Jacek Sounds fine to me. John
Re: Enable wiki-rendering for GERONIMO JIRA project
This will allow comment and description fields to utilize Confluence- style wiki markup. Don't know what it will give us, but sounds fine. Basically it allows JIRA content to be tailored for better visual comprehension. I know that is rather subjective... but have a peek for yourself: http://issues.apache.org/jira/browse/GSHELL-27 http://issues.apache.org/jira/browse/GSHELL-25 --jason
Re: Enable wiki-rendering for GERONIMO JIRA project
On 6/27/06, Jason Dillon <[EMAIL PROTECTED]> wrote: Any objections to enabling wiki-rendering for the GERONIMO JIRA project? This will allow comment and description fields to utilize Confluence- style wiki markup. Don't know what it will give us, but sounds fine. Its basically just a configuration change, done project by project. I think this is a good idea. Do we need to vote this change in? Or shall we just enable it if there is no negative comments? No, you don't need a RTC vote (it falls into documentation category), but awaiting others' comment is greatly appreciated. Just wait till 48 hours pass and implement it (looking forward to seeing it myself what you meant :-)). --jason Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: [RTC] update contributors page
On 6/27/06, Jeff Genender <[EMAIL PROTECTED]> wrote: I did it the old fashioned way... I updated the svn for the raw code, then I made a short cut and just edited the actual site. Made it so I didn't have to publish the whole thing...I cheated ;-) Does anyone know what the proper steps are? I wish to give it a shot. Jeff Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: [openejb-dev] [RTC] Update for new OpenEJB 2.2
On 6/27/06, Dain Sundstrom <[EMAIL PROTECTED]> wrote: A patch for this change can be found in GERONIMO-12345, but the attached patch is not expected work perfectly. Any mismatches or problems will be worked out during the final merge with trunk. Hi Dain, It had really worried me as what you said implies that we won't be able to verify whether what has been voted is really what has been applied to trunk. Before I spend time applying the patch, would you comment on the problems you might've encountered which ended up as 'not expected work perfectly'. Other than that I'm awaiting a response to Alan's question about OpenEJB 3 being considered deprecated. -dain Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: [RTC] update contributors page
I did it the old fashioned way... I updated the svn for the raw code, then I made a short cut and just edited the actual site. Made it so I didn't have to publish the whole thing...I cheated ;-) Jeff Jacek Laskowski wrote: > On 6/27/06, Jeff Genender <[EMAIL PROTECTED]> wrote: >> Thanks John...done. > > How did you publish it? What are the steps? (I think I've already > asked it, but can't find the answer). > > Jacek >
Re: [RTC] update contributors page
On 6/27/06, Jeff Genender <[EMAIL PROTECTED]> wrote: Thanks John...done. How did you publish it? What are the steps? (I think I've already asked it, but can't find the answer). Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: Why do we have pom.xml files in the 1.1 branch?
On 6/27/06, John Sisson <[EMAIL PROTECTED]> wrote: Are these being used/maintained? Should they be deleted to avoid confusion? They have found their place there when the branch was created. They're not necessary as M2 build is not working well. +1 to remove it. John Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: Why do we have pom.xml files in the 1.1 branch?
+1 Probably a good idea if they are not used. --jason On Jun 26, 2006, at 11:05 PM, John Sisson wrote: Are these being used/maintained? Should they be deleted to avoid confusion? Thanks, John
Why do we have pom.xml files in the 1.1 branch?
Are these being used/maintained? Should they be deleted to avoid confusion? Thanks, John
Re: Unable to build using m2
OMG, this xmlbeans plugin is really whacked... need to fix that. Sucks, that you have to do this to build: while true; do mvn install done Anyone know any details about this 2.0-dev xmlbeans plugin? --jason On Jun 26, 2006, at 8:13 PM, Prasad Kashyap wrote: http://www.mail-archive.com/dev@geronimo.apache.org/msg25378.html On 6/26/06, Jason Dillon <[EMAIL PROTECTED]> wrote: What the heck is up with the xmlbeans plugin? I keep getting this from the top-level: [INFO] - --- [ERROR] BUILD ERROR [INFO] - --- [INFO] Failed to resolve artifact. Missing: -- 1) xmlbeans:xmlbeans-jsr173-api:jar:2.0-dev Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=xmlbeans - DartifactId=xmlbeans-jsr173-api \ -Dversion=2.0-dev -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.geronimo.modules:geronimo-j2ee-builder:jar: 1.2- SNAPSHOT 2) stax:stax:jar:1.1.1-dev 3) xmlbeans:xmlbeans-jsr173-api:jar:2.0-dev -- 1 required artifact is missing. for artifact: org.apache.geronimo.modules:geronimo-j2ee-builder:jar:1.2-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2), codehaus-dist (http://dist.codehaus.org), Apache CVS (http://people.apache.org/maven-snapshot-repository), maven1-ibiblio (http://www.ibiblio.org/maven), snapshots (http://snapshots.maven.codehaus.org/maven2), apache-cvs (http://cvs.apache.org/repository) But when I build from the directory it is fine and then the top-level will continue. Something is horked... not sure why though... Where did this jsr plugin come from? --jason On Jun 26, 2006, at 1:05 PM, Prasad Kashyap wrote: > Alan, > > You'd have to build the geronimo-packaging-plugin manually first. It's > under geronimo/m2-plugins > > cd geronimo/m2-plugins > mvn clean > mvn -N > mvn > > Cheers > Prasad > > On 6/25/06, Alan D. Cabrera <[EMAIL PROTECTED]> wrote: >> I get this error: >> >> Try downloading the file manually from the project website. >> >> Then, install it using the command: >> mvn install:install-file -DgroupId=org.apache.geronimo.plugins >> -DartifactId=geronimo-packaging-plugin \ >> -Dversion=1.2.0 -Dpackaging=maven-plugin -Dfile=/path/ to/file >> >> >> org.apache.geronimo.plugins:geronimo-packaging-plugin:maven- >> plugin:1.2.0 >> >> from the specified remote repositories: >> central (http://repo1.maven.org/maven2), >> codehaus-dist (http://dist.codehaus.org/mojo/m2-snapshots), >> snapshots (http://snapshots.maven.codehaus.org/maven2) >> >> org.apache.geronimo.plugins:geronimo-packaging-plugin:maven- >> plugin:1.2.0 >> >> from the specified remote repositories: >> central (http://repo1.maven.org/maven2), >> codehaus-dist (http://dist.codehaus.org/mojo/m2-snapshots), >> snapshots (http://snapshots.maven.codehaus.org/maven2) >> >> >> >> Regards, >> Alan >> >> >>
Re: [RTC] Update for new OpenEJB 2.2
Can you explain in more detail the rearchitecture that was done in this update? If this from openejb3 does that mean that we can deprecate openejb3? Regards, Alan Dain Sundstrom wrote: I have finished the work to update the openejb dead-2.2 branch to run with Geronimo 1.2. The dead-2.2 branch contains a major rearchitecture of the OpenEJB container system which split the deployment units from reusable container and this rearchitecture has already been adopted in OpenEJB 3. This work was done in the https://svn.apache.org/repos/asf/geronimo/branches/dain/openejb-2.2-merge branch, and is largely composed of merges from the Geronimo dead-1.2 branch. A patch for this change can be found in GERONIMO-12345, but the attached patch is not expected work perfectly. Any mismatches or problems will be worked out during the final merge with trunk. The best way to test this change is to checkout and build the branch directly. The maven m:co goal should work to check out the https://svn.codehaus.org/openejb/branches/dain-2.2-merge/merged branch from openejb. For those with tck access, there is a dain-openejb-2.2-merge branch available for testing the tck. Please, review this quickly so the branch doesn't drift too much. Thanks in advance, -dain A quick history of this branch follows: 417321 Fixed openejb version number in project.properties 416533 Applied GERONIMO-1960 which verifies GBean references when the final configuration data is created in a deployment context 416483 Fixed deployment plans to match newest openejb changes 416428 Fixed more plans 415721 Biggest change which updates the j2ee deployment context to contain the transactionManager name amongst some smaller changes 415720 Update maven.xml to use new openejb module names 415225 Set svn:ignore on new interceptor module 415224 svn merge -r 378403:378404 https://svn.apache.org/repos/asf/geronimo/[EMAIL PROTECTED] 415222 svn merge -r 378358:378359 https://svn.apache.org/repos/asf/geronimo/[EMAIL PROTECTED] 415220 svn merge -r 378346:378347 https://svn.apache.org/repos/asf/geronimo/[EMAIL PROTECTED] 415218 svn merge -r 378182:378183 https://svn.apache.org/repos/asf/geronimo/[EMAIL PROTECTED] 415217 svn merge -r 378161:378162 https://svn.apache.org/repos/asf/geronimo/[EMAIL PROTECTED]
Re: Unable to build using m2
Are there *any good reasons* why it should be in the build? If not... then lets remove it. --jason On Jun 26, 2006, at 9:13 PM, Alan D. Cabrera wrote: IMO, it should not be in our build at all. Regards, Alan Jason Dillon wrote: Why is openejb included in "our" build at all? --jason On Jun 26, 2006, at 8:25 PM, Prasad Kashyap wrote: These are the problems I encountered, encountering. openejb: 1. openejb/modules/pom.xml specified dependency on tranql-1.3-SNAPSHOT. That version of tranql doesn'tr exist. Think it should use 1.4-SNAPSHOT. It should also add dist.codehaus.org into it's 2. openejb/modules/pom.xml specified dependency on geronimo-spec:geronimo-spec-corba:1.0-SNAPSHOT which again doesn't exist. It should specify version 2.3-rc4. 3. openejb/modules/pom.xml specified dependency on org.codehaus.org:xmlbeans-maven-plugin:2.0.3-SNAPSHOT. Don't know where that version is deployed. Maybe that will fix the xmlbeans:xmlbeans-jsr173-api:jar:2.0-dev exclusion. If only we can find that repo. Changed it 2.0 and built it successfully. 4. unable to build configs/openejb-deployer. Caused by: org.apache.geronimo.kernel.config.InvalidConfigException: Error starting configuration gbean org.apache.geronimo.configs/openejb-deployer/1.2-SNAPSHOT/car Cheers Prasad On 6/26/06, Prasad Kashyap <[EMAIL PROTECTED]> wrote: http://www.mail-archive.com/dev@geronimo.apache.org/msg25378.html On 6/26/06, Jason Dillon <[EMAIL PROTECTED]> wrote: > What the heck is up with the xmlbeans plugin? > > I keep getting this from the top-level: > > > [INFO] > --- - > [ERROR] BUILD ERROR > [INFO] > --- - > [INFO] Failed to resolve artifact. > > Missing: > -- > 1) xmlbeans:xmlbeans-jsr173-api:jar:2.0-dev > >Try downloading the file manually from the project website. > >Then, install it using the command: >mvn install:install-file -DgroupId=xmlbeans - > DartifactId=xmlbeans-jsr173-api \ >-Dversion=2.0-dev -Dpackaging=jar -Dfile=/path/to/file > >Path to dependency: > 1) org.apache.geronimo.modules:geronimo-j2ee- builder:jar:1.2- > SNAPSHOT > 2) stax:stax:jar:1.1.1-dev > 3) xmlbeans:xmlbeans-jsr173-api:jar:2.0-dev > > -- > 1 required artifact is missing. > > for artifact: >org.apache.geronimo.modules:geronimo-j2ee-builder:jar:1.2- SNAPSHOT > > from the specified remote repositories: >central (http://repo1.maven.org/maven2), >codehaus-dist (http://dist.codehaus.org), >Apache CVS (http://people.apache.org/maven-snapshot- repository), >maven1-ibiblio (http://www.ibiblio.org/maven), >snapshots (http://snapshots.maven.codehaus.org/maven2), >apache-cvs (http://cvs.apache.org/repository) > > > > > But when I build from the directory it is fine and then the top-level > will continue. Something is horked... not sure why though... > > Where did this jsr plugin come from? > > --jason > > > On Jun 26, 2006, at 1:05 PM, Prasad Kashyap wrote: > > > Alan, > > > > You'd have to build the geronimo-packaging-plugin manually first. It's > > under geronimo/m2-plugins > > > > cd geronimo/m2-plugins > > mvn clean > > mvn -N > > mvn > > > > Cheers > > Prasad > > > > On 6/25/06, Alan D. Cabrera <[EMAIL PROTECTED]> wrote: > >> I get this error: > >> > >> Try downloading the file manually from the project website. > >> > >> Then, install it using the command: > >> mvn install:install-file - DgroupId=org.apache.geronimo.plugins > >> -DartifactId=geronimo-packaging-plugin \ > >> -Dversion=1.2.0 -Dpackaging=maven-plugin -Dfile=/ path/to/file > >> > >> > >> org.apache.geronimo.plugins:geronimo-packaging-plugin:maven- > >> plugin:1.2.0 > >> > >> from the specified remote repositories: > >> central (http://repo1.maven.org/maven2), > >> codehaus-dist (http://dist.codehaus.org/mojo/m2-snapshots), > >> snapshots (http://snapshots.maven.codehaus.org/maven2) > >> > >> org.apache.geronimo.plugins:geronimo-packaging-plugin:maven- > >> plugin:1.2.0 > >> > >> from the specified remote repositories: > >> central (http://repo1.maven.org/maven2), > >> codehaus-dist (http://dist.codehaus.org/mojo/m2-snapshots), > >> snapshots (http://snapshots.maven.codehaus.org/maven2) > >> > >> > >> > >> Regards, > >> Alan > >> > >> > >> > >
Re: Lets start moving to m2
I think that removing the m1 files is a good idea, as it will help force us to get m2 to build... which really should not take that long to get functional 100% of the time. --jason On Jun 26, 2006, at 9:19 PM, Alan D. Cabrera wrote: Jacek Laskowski wrote: On 6/26/06, David Jencks <[EMAIL PROTECTED]> wrote: I'm suggesting that we declare the m1 build obsolete and remove it, except possibly for the assembly step and perhaps modules where the tests do not run under m2. Well, don't get it annoying, but I still don't understand it. Let's pretend we've named the m1 build obsolete, what's next? Shall we call a vote? If it passes, what would be the next steps? If you removed the top-level build.xml I'd know what it'd mean, but now I don't get it. Yes, we call a vote then remove the project.xml/project.properties files. build.xml is for Ant; I don't think we use that. Regards, Alan
Re: Lets start moving to m2
Jacek Laskowski wrote: On 6/26/06, David Jencks <[EMAIL PROTECTED]> wrote: I'm suggesting that we declare the m1 build obsolete and remove it, except possibly for the assembly step and perhaps modules where the tests do not run under m2. Well, don't get it annoying, but I still don't understand it. Let's pretend we've named the m1 build obsolete, what's next? Shall we call a vote? If it passes, what would be the next steps? If you removed the top-level build.xml I'd know what it'd mean, but now I don't get it. Yes, we call a vote then remove the project.xml/project.properties files. build.xml is for Ant; I don't think we use that. Regards, Alan
Re: Unable to build using m2
It's clear to me that we need to break out our plugins build and get the plugins published ASAP. I asked this in another thread, what will it take to get this published? I don't think that it's too much trouble, just an RTC to break the plugin out and then we just start publishing the snapshots. We can shoot for a plugin release around the time of G v1.2.0> Regards, Alan Jason Dillon wrote: IMO we should have a completely separate tree for our build support tools. And once the plugins are stable we release them, until they are stable we make regular snaps, so that the main tree(s) can just build w/o having to worry about building plugins first. --jason On Jun 26, 2006, at 1:05 PM, Prasad Kashyap wrote: Alan, You'd have to build the geronimo-packaging-plugin manually first. It's under geronimo/m2-plugins cd geronimo/m2-plugins mvn clean mvn -N mvn Cheers Prasad On 6/25/06, Alan D. Cabrera <[EMAIL PROTECTED]> wrote: I get this error: Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.geronimo.plugins -DartifactId=geronimo-packaging-plugin \ -Dversion=1.2.0 -Dpackaging=maven-plugin -Dfile=/path/to/file org.apache.geronimo.plugins:geronimo-packaging-plugin:maven-plugin:1.2.0 from the specified remote repositories: central (http://repo1.maven.org/maven2), codehaus-dist (http://dist.codehaus.org/mojo/m2-snapshots), snapshots (http://snapshots.maven.codehaus.org/maven2) org.apache.geronimo.plugins:geronimo-packaging-plugin:maven-plugin:1.2.0 from the specified remote repositories: central (http://repo1.maven.org/maven2), codehaus-dist (http://dist.codehaus.org/mojo/m2-snapshots), snapshots (http://snapshots.maven.codehaus.org/maven2) Regards, Alan
Re: Unable to build using m2
IMO, it should not be in our build at all. Regards, Alan Jason Dillon wrote: Why is openejb included in "our" build at all? --jason On Jun 26, 2006, at 8:25 PM, Prasad Kashyap wrote: These are the problems I encountered, encountering. openejb: 1. openejb/modules/pom.xml specified dependency on tranql-1.3-SNAPSHOT. That version of tranql doesn'tr exist. Think it should use 1.4-SNAPSHOT. It should also add dist.codehaus.org into it's 2. openejb/modules/pom.xml specified dependency on geronimo-spec:geronimo-spec-corba:1.0-SNAPSHOT which again doesn't exist. It should specify version 2.3-rc4. 3. openejb/modules/pom.xml specified dependency on org.codehaus.org:xmlbeans-maven-plugin:2.0.3-SNAPSHOT. Don't know where that version is deployed. Maybe that will fix the xmlbeans:xmlbeans-jsr173-api:jar:2.0-dev exclusion. If only we can find that repo. Changed it 2.0 and built it successfully. 4. unable to build configs/openejb-deployer. Caused by: org.apache.geronimo.kernel.config.InvalidConfigException: Error starting configuration gbean org.apache.geronimo.configs/openejb-deployer/1.2-SNAPSHOT/car Cheers Prasad On 6/26/06, Prasad Kashyap <[EMAIL PROTECTED]> wrote: http://www.mail-archive.com/dev@geronimo.apache.org/msg25378.html On 6/26/06, Jason Dillon <[EMAIL PROTECTED]> wrote: > What the heck is up with the xmlbeans plugin? > > I keep getting this from the top-level: > > > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Failed to resolve artifact. > > Missing: > -- > 1) xmlbeans:xmlbeans-jsr173-api:jar:2.0-dev > >Try downloading the file manually from the project website. > >Then, install it using the command: >mvn install:install-file -DgroupId=xmlbeans - > DartifactId=xmlbeans-jsr173-api \ >-Dversion=2.0-dev -Dpackaging=jar -Dfile=/path/to/file > >Path to dependency: > 1) org.apache.geronimo.modules:geronimo-j2ee-builder:jar:1.2- > SNAPSHOT > 2) stax:stax:jar:1.1.1-dev > 3) xmlbeans:xmlbeans-jsr173-api:jar:2.0-dev > > -- > 1 required artifact is missing. > > for artifact: >org.apache.geronimo.modules:geronimo-j2ee-builder:jar:1.2-SNAPSHOT > > from the specified remote repositories: >central (http://repo1.maven.org/maven2), >codehaus-dist (http://dist.codehaus.org), >Apache CVS (http://people.apache.org/maven-snapshot-repository), >maven1-ibiblio (http://www.ibiblio.org/maven), >snapshots (http://snapshots.maven.codehaus.org/maven2), >apache-cvs (http://cvs.apache.org/repository) > > > > > But when I build from the directory it is fine and then the top-level > will continue. Something is horked... not sure why though... > > Where did this jsr plugin come from? > > --jason > > > On Jun 26, 2006, at 1:05 PM, Prasad Kashyap wrote: > > > Alan, > > > > You'd have to build the geronimo-packaging-plugin manually first. It's > > under geronimo/m2-plugins > > > > cd geronimo/m2-plugins > > mvn clean > > mvn -N > > mvn > > > > Cheers > > Prasad > > > > On 6/25/06, Alan D. Cabrera <[EMAIL PROTECTED]> wrote: > >> I get this error: > >> > >> Try downloading the file manually from the project website. > >> > >> Then, install it using the command: > >> mvn install:install-file -DgroupId=org.apache.geronimo.plugins > >> -DartifactId=geronimo-packaging-plugin \ > >> -Dversion=1.2.0 -Dpackaging=maven-plugin -Dfile=/path/to/file > >> > >> > >> org.apache.geronimo.plugins:geronimo-packaging-plugin:maven- > >> plugin:1.2.0 > >> > >> from the specified remote repositories: > >> central (http://repo1.maven.org/maven2), > >> codehaus-dist (http://dist.codehaus.org/mojo/m2-snapshots), > >> snapshots (http://snapshots.maven.codehaus.org/maven2) > >> > >> org.apache.geronimo.plugins:geronimo-packaging-plugin:maven- > >> plugin:1.2.0 > >> > >> from the specified remote repositories: > >> central (http://repo1.maven.org/maven2), > >> codehaus-dist (http://dist.codehaus.org/mojo/m2-snapshots), > >> snapshots (http://snapshots.maven.codehaus.org/maven2) > >> > >> > >> > >> Regards, > >> Alan > >> > >> > >> > >
Re: Unable to build using m2
Probably... But is it really needed to build the sever? --jason On Jun 26, 2006, at 8:33 PM, Prasad Kashyap wrote: Maybe 'coz we built it with "new2" before ? Not sure. Cheers Prasad On 6/26/06, Jason Dillon <[EMAIL PROTECTED]> wrote: Why is openejb included in "our" build at all? --jason On Jun 26, 2006, at 8:25 PM, Prasad Kashyap wrote: > These are the problems I encountered, encountering. > > openejb: > > 1. openejb/modules/pom.xml specified dependency on > tranql-1.3-SNAPSHOT. That version of tranql doesn'tr exist. Think it > should use 1.4-SNAPSHOT. It should also add dist.codehaus.org into > it's > > 2. openejb/modules/pom.xml specified dependency on > geronimo-spec:geronimo-spec-corba:1.0-SNAPSHOT which again doesn't > exist. It should specify version 2.3-rc4. > > 3. openejb/modules/pom.xml specified dependency on > org.codehaus.org:xmlbeans-maven-plugin:2.0.3-SNAPSHOT. Don't know > where that version is deployed. Maybe that will fix the > xmlbeans:xmlbeans-jsr173-api:jar:2.0-dev exclusion. If only we can > find that repo. Changed it 2.0 and built it successfully. > > 4. unable to build configs/openejb-deployer. > Caused by: org.apache.geronimo.kernel.config.InvalidConfigException: > Error starting configuration gbean > org.apache.geronimo.configs/openejb-deployer/1.2-SNAPSHOT/car > > Cheers > Prasad > > On 6/26/06, Prasad Kashyap <[EMAIL PROTECTED]> wrote: >> http://www.mail-archive.com/dev@geronimo.apache.org/msg25378.html >> >> On 6/26/06, Jason Dillon <[EMAIL PROTECTED]> wrote: >> > What the heck is up with the xmlbeans plugin? >> > >> > I keep getting this from the top-level: >> > >> > >> > [INFO] >> > >> - >> --- >> > [ERROR] BUILD ERROR >> > [INFO] >> > >> - >> --- >> > [INFO] Failed to resolve artifact. >> > >> > Missing: >> > -- >> > 1) xmlbeans:xmlbeans-jsr173-api:jar:2.0-dev >> > >> >Try downloading the file manually from the project website. >> > >> >Then, install it using the command: >> >mvn install:install-file -DgroupId=xmlbeans - >> > DartifactId=xmlbeans-jsr173-api \ >> >-Dversion=2.0-dev -Dpackaging=jar -Dfile=/path/to/ file >> > >> >Path to dependency: >> > 1) org.apache.geronimo.modules:geronimo-j2ee- >> builder:jar:1.2- >> > SNAPSHOT >> > 2) stax:stax:jar:1.1.1-dev >> > 3) xmlbeans:xmlbeans-jsr173-api:jar:2.0-dev >> > >> > -- >> > 1 required artifact is missing. >> > >> > for artifact: >> >org.apache.geronimo.modules:geronimo-j2ee-builder:jar:1.2- >> SNAPSHOT >> > >> > from the specified remote repositories: >> >central (http://repo1.maven.org/maven2), >> >codehaus-dist (http://dist.codehaus.org), >> >Apache CVS (http://people.apache.org/maven-snapshot- repository), >> >maven1-ibiblio (http://www.ibiblio.org/maven), >> >snapshots (http://snapshots.maven.codehaus.org/maven2), >> >apache-cvs (http://cvs.apache.org/repository) >> > >> > >> > >> > >> > But when I build from the directory it is fine and then the top- >> level >> > will continue. Something is horked... not sure why though... >> > >> > Where did this jsr plugin come from? >> > >> > --jason >> > >> > >> > On Jun 26, 2006, at 1:05 PM, Prasad Kashyap wrote: >> > >> > > Alan, >> > > >> > > You'd have to build the geronimo-packaging-plugin manually >> first. It's >> > > under geronimo/m2-plugins >> > > >> > > cd geronimo/m2-plugins >> > > mvn clean >> > > mvn -N >> > > mvn >> > > >> > > Cheers >> > > Prasad >> > > >> > > On 6/25/06, Alan D. Cabrera <[EMAIL PROTECTED]> wrote: >> > >> I get this error: >> > >> >> > >> Try downloading the file manually from the project website. >> > >> >> > >> Then, install it using the command: >> > >> mvn install:install-file - >> DgroupId=org.apache.geronimo.plugins >> > >> -DartifactId=geronimo-packaging-plugin \ >> > >> -Dversion=1.2.0 -Dpackaging=maven-plugin -Dfile=/ path/ >> to/file >> > >> >> > >> >> > >> org.apache.geronimo.plugins:geronimo-packaging- plugin:maven- >> > >> plugin:1.2.0 >> > >> >> > >> from the specified remote repositories: >> > >> central (http://repo1.maven.org/maven2), >> > >> codehaus-dist (http://dist.codehaus.org/mojo/m2-snapshots), >> > >> snapshots (http://snapshots.maven.codehaus.org/maven2) >> > >> >> > >> org.apache.geronimo.plugins:geronimo-packaging- plugin:maven- >> > >> plugin:1.2.0 >> > >> >> > >> from the specified remote repositories: >> > >> central (http://repo1.maven.org/maven2), >> > >> codehaus-dist (http://dist.codehaus.org/mojo/m2-snapshots), >> > >> snapshots (http://snapshots.maven.codehaus.org/maven2) >> > >> >> > >> >> > >> >> > >> Regards, >> > >> Alan >> > >> >> > >> >> > >> >> > >> > >>
Re: Unable to build using m2
Any idea where the stax:stax-api:1.1.1-dev comes from? The root pom states that stax:stax-api:1.0 should be used... but the errors with the xmlbeans plugin all state 1.1.1-dev. --jason On Jun 26, 2006, at 8:25 PM, Prasad Kashyap wrote: These are the problems I encountered, encountering. openejb: 1. openejb/modules/pom.xml specified dependency on tranql-1.3-SNAPSHOT. That version of tranql doesn'tr exist. Think it should use 1.4-SNAPSHOT. It should also add dist.codehaus.org into it's 2. openejb/modules/pom.xml specified dependency on geronimo-spec:geronimo-spec-corba:1.0-SNAPSHOT which again doesn't exist. It should specify version 2.3-rc4. 3. openejb/modules/pom.xml specified dependency on org.codehaus.org:xmlbeans-maven-plugin:2.0.3-SNAPSHOT. Don't know where that version is deployed. Maybe that will fix the xmlbeans:xmlbeans-jsr173-api:jar:2.0-dev exclusion. If only we can find that repo. Changed it 2.0 and built it successfully. 4. unable to build configs/openejb-deployer. Caused by: org.apache.geronimo.kernel.config.InvalidConfigException: Error starting configuration gbean org.apache.geronimo.configs/openejb-deployer/1.2-SNAPSHOT/car Cheers Prasad On 6/26/06, Prasad Kashyap <[EMAIL PROTECTED]> wrote: http://www.mail-archive.com/dev@geronimo.apache.org/msg25378.html On 6/26/06, Jason Dillon <[EMAIL PROTECTED]> wrote: > What the heck is up with the xmlbeans plugin? > > I keep getting this from the top-level: > > > [INFO] > - --- > [ERROR] BUILD ERROR > [INFO] > - --- > [INFO] Failed to resolve artifact. > > Missing: > -- > 1) xmlbeans:xmlbeans-jsr173-api:jar:2.0-dev > >Try downloading the file manually from the project website. > >Then, install it using the command: >mvn install:install-file -DgroupId=xmlbeans - > DartifactId=xmlbeans-jsr173-api \ >-Dversion=2.0-dev -Dpackaging=jar -Dfile=/path/to/file > >Path to dependency: > 1) org.apache.geronimo.modules:geronimo-j2ee- builder:jar:1.2- > SNAPSHOT > 2) stax:stax:jar:1.1.1-dev > 3) xmlbeans:xmlbeans-jsr173-api:jar:2.0-dev > > -- > 1 required artifact is missing. > > for artifact: >org.apache.geronimo.modules:geronimo-j2ee-builder:jar:1.2- SNAPSHOT > > from the specified remote repositories: >central (http://repo1.maven.org/maven2), >codehaus-dist (http://dist.codehaus.org), >Apache CVS (http://people.apache.org/maven-snapshot-repository), >maven1-ibiblio (http://www.ibiblio.org/maven), >snapshots (http://snapshots.maven.codehaus.org/maven2), >apache-cvs (http://cvs.apache.org/repository) > > > > > But when I build from the directory it is fine and then the top- level > will continue. Something is horked... not sure why though... > > Where did this jsr plugin come from? > > --jason > > > On Jun 26, 2006, at 1:05 PM, Prasad Kashyap wrote: > > > Alan, > > > > You'd have to build the geronimo-packaging-plugin manually first. It's > > under geronimo/m2-plugins > > > > cd geronimo/m2-plugins > > mvn clean > > mvn -N > > mvn > > > > Cheers > > Prasad > > > > On 6/25/06, Alan D. Cabrera <[EMAIL PROTECTED]> wrote: > >> I get this error: > >> > >> Try downloading the file manually from the project website. > >> > >> Then, install it using the command: > >> mvn install:install-file - DgroupId=org.apache.geronimo.plugins > >> -DartifactId=geronimo-packaging-plugin \ > >> -Dversion=1.2.0 -Dpackaging=maven-plugin -Dfile=/path/ to/file > >> > >> > >> org.apache.geronimo.plugins:geronimo-packaging-plugin:maven- > >> plugin:1.2.0 > >> > >> from the specified remote repositories: > >> central (http://repo1.maven.org/maven2), > >> codehaus-dist (http://dist.codehaus.org/mojo/m2-snapshots), > >> snapshots (http://snapshots.maven.codehaus.org/maven2) > >> > >> org.apache.geronimo.plugins:geronimo-packaging-plugin:maven- > >> plugin:1.2.0 > >> > >> from the specified remote repositories: > >> central (http://repo1.maven.org/maven2), > >> codehaus-dist (http://dist.codehaus.org/mojo/m2-snapshots), > >> snapshots (http://snapshots.maven.codehaus.org/maven2) > >> > >> > >> > >> Regards, > >> Alan > >> > >> > >> > >
Re: Unable to build using m2
Maybe 'coz we built it with "new2" before ? Not sure. Cheers Prasad On 6/26/06, Jason Dillon <[EMAIL PROTECTED]> wrote: Why is openejb included in "our" build at all? --jason On Jun 26, 2006, at 8:25 PM, Prasad Kashyap wrote: > These are the problems I encountered, encountering. > > openejb: > > 1. openejb/modules/pom.xml specified dependency on > tranql-1.3-SNAPSHOT. That version of tranql doesn'tr exist. Think it > should use 1.4-SNAPSHOT. It should also add dist.codehaus.org into > it's > > 2. openejb/modules/pom.xml specified dependency on > geronimo-spec:geronimo-spec-corba:1.0-SNAPSHOT which again doesn't > exist. It should specify version 2.3-rc4. > > 3. openejb/modules/pom.xml specified dependency on > org.codehaus.org:xmlbeans-maven-plugin:2.0.3-SNAPSHOT. Don't know > where that version is deployed. Maybe that will fix the > xmlbeans:xmlbeans-jsr173-api:jar:2.0-dev exclusion. If only we can > find that repo. Changed it 2.0 and built it successfully. > > 4. unable to build configs/openejb-deployer. > Caused by: org.apache.geronimo.kernel.config.InvalidConfigException: > Error starting configuration gbean > org.apache.geronimo.configs/openejb-deployer/1.2-SNAPSHOT/car > > Cheers > Prasad > > On 6/26/06, Prasad Kashyap <[EMAIL PROTECTED]> wrote: >> http://www.mail-archive.com/dev@geronimo.apache.org/msg25378.html >> >> On 6/26/06, Jason Dillon <[EMAIL PROTECTED]> wrote: >> > What the heck is up with the xmlbeans plugin? >> > >> > I keep getting this from the top-level: >> > >> > >> > [INFO] >> > >> - >> --- >> > [ERROR] BUILD ERROR >> > [INFO] >> > >> - >> --- >> > [INFO] Failed to resolve artifact. >> > >> > Missing: >> > -- >> > 1) xmlbeans:xmlbeans-jsr173-api:jar:2.0-dev >> > >> >Try downloading the file manually from the project website. >> > >> >Then, install it using the command: >> >mvn install:install-file -DgroupId=xmlbeans - >> > DartifactId=xmlbeans-jsr173-api \ >> >-Dversion=2.0-dev -Dpackaging=jar -Dfile=/path/to/file >> > >> >Path to dependency: >> > 1) org.apache.geronimo.modules:geronimo-j2ee- >> builder:jar:1.2- >> > SNAPSHOT >> > 2) stax:stax:jar:1.1.1-dev >> > 3) xmlbeans:xmlbeans-jsr173-api:jar:2.0-dev >> > >> > -- >> > 1 required artifact is missing. >> > >> > for artifact: >> >org.apache.geronimo.modules:geronimo-j2ee-builder:jar:1.2- >> SNAPSHOT >> > >> > from the specified remote repositories: >> >central (http://repo1.maven.org/maven2), >> >codehaus-dist (http://dist.codehaus.org), >> >Apache CVS (http://people.apache.org/maven-snapshot-repository), >> >maven1-ibiblio (http://www.ibiblio.org/maven), >> >snapshots (http://snapshots.maven.codehaus.org/maven2), >> >apache-cvs (http://cvs.apache.org/repository) >> > >> > >> > >> > >> > But when I build from the directory it is fine and then the top- >> level >> > will continue. Something is horked... not sure why though... >> > >> > Where did this jsr plugin come from? >> > >> > --jason >> > >> > >> > On Jun 26, 2006, at 1:05 PM, Prasad Kashyap wrote: >> > >> > > Alan, >> > > >> > > You'd have to build the geronimo-packaging-plugin manually >> first. It's >> > > under geronimo/m2-plugins >> > > >> > > cd geronimo/m2-plugins >> > > mvn clean >> > > mvn -N >> > > mvn >> > > >> > > Cheers >> > > Prasad >> > > >> > > On 6/25/06, Alan D. Cabrera <[EMAIL PROTECTED]> wrote: >> > >> I get this error: >> > >> >> > >> Try downloading the file manually from the project website. >> > >> >> > >> Then, install it using the command: >> > >> mvn install:install-file - >> DgroupId=org.apache.geronimo.plugins >> > >> -DartifactId=geronimo-packaging-plugin \ >> > >> -Dversion=1.2.0 -Dpackaging=maven-plugin -Dfile=/path/ >> to/file >> > >> >> > >> >> > >> org.apache.geronimo.plugins:geronimo-packaging-plugin:maven- >> > >> plugin:1.2.0 >> > >> >> > >> from the specified remote repositories: >> > >> central (http://repo1.maven.org/maven2), >> > >> codehaus-dist (http://dist.codehaus.org/mojo/m2-snapshots), >> > >> snapshots (http://snapshots.maven.codehaus.org/maven2) >> > >> >> > >> org.apache.geronimo.plugins:geronimo-packaging-plugin:maven- >> > >> plugin:1.2.0 >> > >> >> > >> from the specified remote repositories: >> > >> central (http://repo1.maven.org/maven2), >> > >> codehaus-dist (http://dist.codehaus.org/mojo/m2-snapshots), >> > >> snapshots (http://snapshots.maven.codehaus.org/maven2) >> > >> >> > >> >> > >> >> > >> Regards, >> > >> Alan >> > >> >> > >> >> > >> >> > >> > >>
Re: [RTC] update contributors page
Thanks John...done. John Sisson wrote: > Jeff Genender wrote: >> Hey folks, >> >> I want to update the contributors page of the geronimo.apache.org site... >> >> - Jeff Genender >> Virtuas > bgcolor="#f3f4f5">--- >> + Jeff Genender >> Savoir Technologies >> --- >> >> Is this ok? >> >> Thanks, >> >> Jeff >> >> > Congratulations. > > You should be fine to make the change as Ken's original mail "Change to > commit model for Apache Geronimo" said that RTC applies to all code > changes that aren't for documentation or a specific bug fix. > > AFAIK, the website can be considered documentation. > > John
Re: Unable to build using m2
Why is openejb included in "our" build at all? --jason On Jun 26, 2006, at 8:25 PM, Prasad Kashyap wrote: These are the problems I encountered, encountering. openejb: 1. openejb/modules/pom.xml specified dependency on tranql-1.3-SNAPSHOT. That version of tranql doesn'tr exist. Think it should use 1.4-SNAPSHOT. It should also add dist.codehaus.org into it's 2. openejb/modules/pom.xml specified dependency on geronimo-spec:geronimo-spec-corba:1.0-SNAPSHOT which again doesn't exist. It should specify version 2.3-rc4. 3. openejb/modules/pom.xml specified dependency on org.codehaus.org:xmlbeans-maven-plugin:2.0.3-SNAPSHOT. Don't know where that version is deployed. Maybe that will fix the xmlbeans:xmlbeans-jsr173-api:jar:2.0-dev exclusion. If only we can find that repo. Changed it 2.0 and built it successfully. 4. unable to build configs/openejb-deployer. Caused by: org.apache.geronimo.kernel.config.InvalidConfigException: Error starting configuration gbean org.apache.geronimo.configs/openejb-deployer/1.2-SNAPSHOT/car Cheers Prasad On 6/26/06, Prasad Kashyap <[EMAIL PROTECTED]> wrote: http://www.mail-archive.com/dev@geronimo.apache.org/msg25378.html On 6/26/06, Jason Dillon <[EMAIL PROTECTED]> wrote: > What the heck is up with the xmlbeans plugin? > > I keep getting this from the top-level: > > > [INFO] > - --- > [ERROR] BUILD ERROR > [INFO] > - --- > [INFO] Failed to resolve artifact. > > Missing: > -- > 1) xmlbeans:xmlbeans-jsr173-api:jar:2.0-dev > >Try downloading the file manually from the project website. > >Then, install it using the command: >mvn install:install-file -DgroupId=xmlbeans - > DartifactId=xmlbeans-jsr173-api \ >-Dversion=2.0-dev -Dpackaging=jar -Dfile=/path/to/file > >Path to dependency: > 1) org.apache.geronimo.modules:geronimo-j2ee- builder:jar:1.2- > SNAPSHOT > 2) stax:stax:jar:1.1.1-dev > 3) xmlbeans:xmlbeans-jsr173-api:jar:2.0-dev > > -- > 1 required artifact is missing. > > for artifact: >org.apache.geronimo.modules:geronimo-j2ee-builder:jar:1.2- SNAPSHOT > > from the specified remote repositories: >central (http://repo1.maven.org/maven2), >codehaus-dist (http://dist.codehaus.org), >Apache CVS (http://people.apache.org/maven-snapshot-repository), >maven1-ibiblio (http://www.ibiblio.org/maven), >snapshots (http://snapshots.maven.codehaus.org/maven2), >apache-cvs (http://cvs.apache.org/repository) > > > > > But when I build from the directory it is fine and then the top- level > will continue. Something is horked... not sure why though... > > Where did this jsr plugin come from? > > --jason > > > On Jun 26, 2006, at 1:05 PM, Prasad Kashyap wrote: > > > Alan, > > > > You'd have to build the geronimo-packaging-plugin manually first. It's > > under geronimo/m2-plugins > > > > cd geronimo/m2-plugins > > mvn clean > > mvn -N > > mvn > > > > Cheers > > Prasad > > > > On 6/25/06, Alan D. Cabrera <[EMAIL PROTECTED]> wrote: > >> I get this error: > >> > >> Try downloading the file manually from the project website. > >> > >> Then, install it using the command: > >> mvn install:install-file - DgroupId=org.apache.geronimo.plugins > >> -DartifactId=geronimo-packaging-plugin \ > >> -Dversion=1.2.0 -Dpackaging=maven-plugin -Dfile=/path/ to/file > >> > >> > >> org.apache.geronimo.plugins:geronimo-packaging-plugin:maven- > >> plugin:1.2.0 > >> > >> from the specified remote repositories: > >> central (http://repo1.maven.org/maven2), > >> codehaus-dist (http://dist.codehaus.org/mojo/m2-snapshots), > >> snapshots (http://snapshots.maven.codehaus.org/maven2) > >> > >> org.apache.geronimo.plugins:geronimo-packaging-plugin:maven- > >> plugin:1.2.0 > >> > >> from the specified remote repositories: > >> central (http://repo1.maven.org/maven2), > >> codehaus-dist (http://dist.codehaus.org/mojo/m2-snapshots), > >> snapshots (http://snapshots.maven.codehaus.org/maven2) > >> > >> > >> > >> Regards, > >> Alan > >> > >> > >> > >
Re: Unable to build using m2
These are the problems I encountered, encountering. openejb: 1. openejb/modules/pom.xml specified dependency on tranql-1.3-SNAPSHOT. That version of tranql doesn'tr exist. Think it should use 1.4-SNAPSHOT. It should also add dist.codehaus.org into it's 2. openejb/modules/pom.xml specified dependency on geronimo-spec:geronimo-spec-corba:1.0-SNAPSHOT which again doesn't exist. It should specify version 2.3-rc4. 3. openejb/modules/pom.xml specified dependency on org.codehaus.org:xmlbeans-maven-plugin:2.0.3-SNAPSHOT. Don't know where that version is deployed. Maybe that will fix the xmlbeans:xmlbeans-jsr173-api:jar:2.0-dev exclusion. If only we can find that repo. Changed it 2.0 and built it successfully. 4. unable to build configs/openejb-deployer. Caused by: org.apache.geronimo.kernel.config.InvalidConfigException: Error starting configuration gbean org.apache.geronimo.configs/openejb-deployer/1.2-SNAPSHOT/car Cheers Prasad On 6/26/06, Prasad Kashyap <[EMAIL PROTECTED]> wrote: http://www.mail-archive.com/dev@geronimo.apache.org/msg25378.html On 6/26/06, Jason Dillon <[EMAIL PROTECTED]> wrote: > What the heck is up with the xmlbeans plugin? > > I keep getting this from the top-level: > > > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Failed to resolve artifact. > > Missing: > -- > 1) xmlbeans:xmlbeans-jsr173-api:jar:2.0-dev > >Try downloading the file manually from the project website. > >Then, install it using the command: >mvn install:install-file -DgroupId=xmlbeans - > DartifactId=xmlbeans-jsr173-api \ >-Dversion=2.0-dev -Dpackaging=jar -Dfile=/path/to/file > >Path to dependency: > 1) org.apache.geronimo.modules:geronimo-j2ee-builder:jar:1.2- > SNAPSHOT > 2) stax:stax:jar:1.1.1-dev > 3) xmlbeans:xmlbeans-jsr173-api:jar:2.0-dev > > -- > 1 required artifact is missing. > > for artifact: >org.apache.geronimo.modules:geronimo-j2ee-builder:jar:1.2-SNAPSHOT > > from the specified remote repositories: >central (http://repo1.maven.org/maven2), >codehaus-dist (http://dist.codehaus.org), >Apache CVS (http://people.apache.org/maven-snapshot-repository), >maven1-ibiblio (http://www.ibiblio.org/maven), >snapshots (http://snapshots.maven.codehaus.org/maven2), >apache-cvs (http://cvs.apache.org/repository) > > > > > But when I build from the directory it is fine and then the top-level > will continue. Something is horked... not sure why though... > > Where did this jsr plugin come from? > > --jason > > > On Jun 26, 2006, at 1:05 PM, Prasad Kashyap wrote: > > > Alan, > > > > You'd have to build the geronimo-packaging-plugin manually first. It's > > under geronimo/m2-plugins > > > > cd geronimo/m2-plugins > > mvn clean > > mvn -N > > mvn > > > > Cheers > > Prasad > > > > On 6/25/06, Alan D. Cabrera <[EMAIL PROTECTED]> wrote: > >> I get this error: > >> > >> Try downloading the file manually from the project website. > >> > >> Then, install it using the command: > >> mvn install:install-file -DgroupId=org.apache.geronimo.plugins > >> -DartifactId=geronimo-packaging-plugin \ > >> -Dversion=1.2.0 -Dpackaging=maven-plugin -Dfile=/path/to/file > >> > >> > >> org.apache.geronimo.plugins:geronimo-packaging-plugin:maven- > >> plugin:1.2.0 > >> > >> from the specified remote repositories: > >> central (http://repo1.maven.org/maven2), > >> codehaus-dist (http://dist.codehaus.org/mojo/m2-snapshots), > >> snapshots (http://snapshots.maven.codehaus.org/maven2) > >> > >> org.apache.geronimo.plugins:geronimo-packaging-plugin:maven- > >> plugin:1.2.0 > >> > >> from the specified remote repositories: > >> central (http://repo1.maven.org/maven2), > >> codehaus-dist (http://dist.codehaus.org/mojo/m2-snapshots), > >> snapshots (http://snapshots.maven.codehaus.org/maven2) > >> > >> > >> > >> Regards, > >> Alan > >> > >> > >> > >
Re: Unable to build using m2
Why does it fail the first time? This seems fishy too... I'm rebuild again to see what it does, but that is painfully slow... If we really do depend on a development version of the plugin, then we should either... Lobby to get the plugin released or Checkin and manage our own version of that plugin The later is not ideal, but in an open-source world that we live in, sometimes that is the only option as we need stability and can not always rely on other groups to provide that for us. * * * Also, on a side note, we should explicitly list the versions of maven and mojo plugins that we use. I have run into problems many many times when these teams release new versions of the plugins which effectively break the build. It is _nice_ that Maven can download the latest and greatest release of artifacts... but since those latest versions might behave differently that the project is configured to use... it will just end up breaking things. So, don't buy into the "magic" be explicit and tell Maven what version to use. --jason On Jun 26, 2006, at 8:13 PM, Prasad Kashyap wrote: http://www.mail-archive.com/dev@geronimo.apache.org/msg25378.html On 6/26/06, Jason Dillon <[EMAIL PROTECTED]> wrote: What the heck is up with the xmlbeans plugin? I keep getting this from the top-level: [INFO] - --- [ERROR] BUILD ERROR [INFO] - --- [INFO] Failed to resolve artifact. Missing: -- 1) xmlbeans:xmlbeans-jsr173-api:jar:2.0-dev Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=xmlbeans - DartifactId=xmlbeans-jsr173-api \ -Dversion=2.0-dev -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.geronimo.modules:geronimo-j2ee-builder:jar: 1.2- SNAPSHOT 2) stax:stax:jar:1.1.1-dev 3) xmlbeans:xmlbeans-jsr173-api:jar:2.0-dev -- 1 required artifact is missing. for artifact: org.apache.geronimo.modules:geronimo-j2ee-builder:jar:1.2-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2), codehaus-dist (http://dist.codehaus.org), Apache CVS (http://people.apache.org/maven-snapshot-repository), maven1-ibiblio (http://www.ibiblio.org/maven), snapshots (http://snapshots.maven.codehaus.org/maven2), apache-cvs (http://cvs.apache.org/repository) But when I build from the directory it is fine and then the top-level will continue. Something is horked... not sure why though... Where did this jsr plugin come from? --jason On Jun 26, 2006, at 1:05 PM, Prasad Kashyap wrote: > Alan, > > You'd have to build the geronimo-packaging-plugin manually first. It's > under geronimo/m2-plugins > > cd geronimo/m2-plugins > mvn clean > mvn -N > mvn > > Cheers > Prasad > > On 6/25/06, Alan D. Cabrera <[EMAIL PROTECTED]> wrote: >> I get this error: >> >> Try downloading the file manually from the project website. >> >> Then, install it using the command: >> mvn install:install-file -DgroupId=org.apache.geronimo.plugins >> -DartifactId=geronimo-packaging-plugin \ >> -Dversion=1.2.0 -Dpackaging=maven-plugin -Dfile=/path/ to/file >> >> >> org.apache.geronimo.plugins:geronimo-packaging-plugin:maven- >> plugin:1.2.0 >> >> from the specified remote repositories: >> central (http://repo1.maven.org/maven2), >> codehaus-dist (http://dist.codehaus.org/mojo/m2-snapshots), >> snapshots (http://snapshots.maven.codehaus.org/maven2) >> >> org.apache.geronimo.plugins:geronimo-packaging-plugin:maven- >> plugin:1.2.0 >> >> from the specified remote repositories: >> central (http://repo1.maven.org/maven2), >> codehaus-dist (http://dist.codehaus.org/mojo/m2-snapshots), >> snapshots (http://snapshots.maven.codehaus.org/maven2) >> >> >> >> Regards, >> Alan >> >> >>
Re: Unable to build using m2
I'm really, REALLY, glad you have taken an interest in m2 migration :-) Your experience with other such migrations can surely help us. Alright so now you can guide us. :-) I need a buildable server too ;-) So we shall hardcode the parent in all pom.xml and remove the . element for that project itself. That should help us do a single build w/o the -N. Yup, each module should define the project/parent/version and only the root pom.xml should define project/version. Leave mgmnt of this number to the release process, don't try to fix it with properties now, since it just doesn't work like that in m2 yet. What else would u advise ? Well, I'm still assessing what the state of the m2 conversion is. Offhand I can think of a few things that we should do: Create some helper modules to carry build configuration. Specifically, we should create a new module that contains a simple Log4j configuration that can be shared by all modules. IMO, the default build should not spit out tons of output when running tests. It should capture all output into target/test.log and if needed allow the developer to enable system.out with a property setting. This is easily done be creating a new module that contains the shared log4j.properties and then hook it up as a default extension to the build. But, to do this, the module needs to be built separately and downloaded. Not a big deal really, but something needs to be done to setup/facilitate its build. I recommend that we setup a peer tree that holds build support modules. Starting out with the logging- config module... but there are also other reasons to have these support modules, especially as we add more and more projects that need to share the same basic configuration. I also think that we should remove any unneeded properties in the root pom. I mentioned the reasoning before... basically less is more. This file is going to get more and more complicated, no reason to inflate that with unneeded properties. Drop and configured modules that are not checked in to the tree (ie. modules/openejb). If this is really needed then it should be checked in. * * * Other thoughts are more about future reorganization of the tree. I think we may want to split up the tree as it exists now into a few smaller chunks that represent more functional areas. For example, I'd like to have all of the core modules grouped up, so that I could just build everything needed to just get the very basics up. Then another group for all of the J2EE support, and then another for thirdparty vendor support, etc. We should be willing to reorganize the tree after we get the basic build going, to facilitate separation of concerns from a component level... meaning that if I am only interested in building the bare server, then I should not need to bother with all of the other j2EE and 3rdparty stuff. But all of this will come in time. I think that once the m2 build it functional that we should reorganize right away into functional groups of modules. If I notice anything that I think is a bit "crazy" I will be sure to post it to the list. --jason
Re: Unable to build using m2
http://www.mail-archive.com/dev@geronimo.apache.org/msg25378.html On 6/26/06, Jason Dillon <[EMAIL PROTECTED]> wrote: What the heck is up with the xmlbeans plugin? I keep getting this from the top-level: [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Missing: -- 1) xmlbeans:xmlbeans-jsr173-api:jar:2.0-dev Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=xmlbeans - DartifactId=xmlbeans-jsr173-api \ -Dversion=2.0-dev -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.geronimo.modules:geronimo-j2ee-builder:jar:1.2- SNAPSHOT 2) stax:stax:jar:1.1.1-dev 3) xmlbeans:xmlbeans-jsr173-api:jar:2.0-dev -- 1 required artifact is missing. for artifact: org.apache.geronimo.modules:geronimo-j2ee-builder:jar:1.2-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2), codehaus-dist (http://dist.codehaus.org), Apache CVS (http://people.apache.org/maven-snapshot-repository), maven1-ibiblio (http://www.ibiblio.org/maven), snapshots (http://snapshots.maven.codehaus.org/maven2), apache-cvs (http://cvs.apache.org/repository) But when I build from the directory it is fine and then the top-level will continue. Something is horked... not sure why though... Where did this jsr plugin come from? --jason On Jun 26, 2006, at 1:05 PM, Prasad Kashyap wrote: > Alan, > > You'd have to build the geronimo-packaging-plugin manually first. It's > under geronimo/m2-plugins > > cd geronimo/m2-plugins > mvn clean > mvn -N > mvn > > Cheers > Prasad > > On 6/25/06, Alan D. Cabrera <[EMAIL PROTECTED]> wrote: >> I get this error: >> >> Try downloading the file manually from the project website. >> >> Then, install it using the command: >> mvn install:install-file -DgroupId=org.apache.geronimo.plugins >> -DartifactId=geronimo-packaging-plugin \ >> -Dversion=1.2.0 -Dpackaging=maven-plugin -Dfile=/path/to/file >> >> >> org.apache.geronimo.plugins:geronimo-packaging-plugin:maven- >> plugin:1.2.0 >> >> from the specified remote repositories: >> central (http://repo1.maven.org/maven2), >> codehaus-dist (http://dist.codehaus.org/mojo/m2-snapshots), >> snapshots (http://snapshots.maven.codehaus.org/maven2) >> >> org.apache.geronimo.plugins:geronimo-packaging-plugin:maven- >> plugin:1.2.0 >> >> from the specified remote repositories: >> central (http://repo1.maven.org/maven2), >> codehaus-dist (http://dist.codehaus.org/mojo/m2-snapshots), >> snapshots (http://snapshots.maven.codehaus.org/maven2) >> >> >> >> Regards, >> Alan >> >> >>
Re: Unable to build using m2
What the heck is up with the xmlbeans plugin? I keep getting this from the top-level: [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Missing: -- 1) xmlbeans:xmlbeans-jsr173-api:jar:2.0-dev Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=xmlbeans - DartifactId=xmlbeans-jsr173-api \ -Dversion=2.0-dev -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.geronimo.modules:geronimo-j2ee-builder:jar:1.2- SNAPSHOT 2) stax:stax:jar:1.1.1-dev 3) xmlbeans:xmlbeans-jsr173-api:jar:2.0-dev -- 1 required artifact is missing. for artifact: org.apache.geronimo.modules:geronimo-j2ee-builder:jar:1.2-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2), codehaus-dist (http://dist.codehaus.org), Apache CVS (http://people.apache.org/maven-snapshot-repository), maven1-ibiblio (http://www.ibiblio.org/maven), snapshots (http://snapshots.maven.codehaus.org/maven2), apache-cvs (http://cvs.apache.org/repository) But when I build from the directory it is fine and then the top-level will continue. Something is horked... not sure why though... Where did this jsr plugin come from? --jason On Jun 26, 2006, at 1:05 PM, Prasad Kashyap wrote: Alan, You'd have to build the geronimo-packaging-plugin manually first. It's under geronimo/m2-plugins cd geronimo/m2-plugins mvn clean mvn -N mvn Cheers Prasad On 6/25/06, Alan D. Cabrera <[EMAIL PROTECTED]> wrote: I get this error: Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.geronimo.plugins -DartifactId=geronimo-packaging-plugin \ -Dversion=1.2.0 -Dpackaging=maven-plugin -Dfile=/path/to/file org.apache.geronimo.plugins:geronimo-packaging-plugin:maven- plugin:1.2.0 from the specified remote repositories: central (http://repo1.maven.org/maven2), codehaus-dist (http://dist.codehaus.org/mojo/m2-snapshots), snapshots (http://snapshots.maven.codehaus.org/maven2) org.apache.geronimo.plugins:geronimo-packaging-plugin:maven- plugin:1.2.0 from the specified remote repositories: central (http://repo1.maven.org/maven2), codehaus-dist (http://dist.codehaus.org/mojo/m2-snapshots), snapshots (http://snapshots.maven.codehaus.org/maven2) Regards, Alan
Re: Unable to build using m2
Jason, I'm really, REALLY, glad you have taken an interest in m2 migration :-) Your experience with other such migrations can surely help us. Alright so now you can guide us. So we shall hardcode the parent in all pom.xml and remove the . element for that project itself. That should help us do a single build w/o the -N. What else would u advise ? Thanx Prasad On 6/26/06, Jason Dillon <[EMAIL PROTECTED]> wrote: I don't see what the problem is. Is this just about putting the version in the parent element? I don't really like that it has to be there, but I am okay with it and using the release plugin to manage that value, which is the main benefit of the release plugin IMO. Or am I missing something? I've recently converted a number of large m1 projects to using m2 and have run into very little issues. Most are related to use of custom jelly, requiring new mojos which is not a big issue. Others being due to projects dependent on those mojos, and keeping them under a separate lifecycle, and expecting that users will download them not build them. So the top-level pom.xml just says 1.2-SNAPSHOT and then all children have ...1.2-SNAPSHOT. This works very well to *build* and is only a slight pain when releasing, but as I mentioned the release plugin handles this. I would obviously rather that it inspect the relativePath first... up until it finds a version and if the parent is not available then pull from the repo... but that isn't gonna happen any time soonish for us to benefit from. IMO, we need to adapt to how m2 works now and then grow with it as we get features/bugs fixed and implemented. --jason On Jun 26, 2006, at 7:21 PM, Prasad Kashyap wrote: > Yes, that's the ideal situation and we very much desire it. But here's > what's preventing us > > http://issues.apache.org/jira/browse/GERONIMO-1755#action_12371755 > http://jira.codehaus.org/browse/MNG-624 > > Cheers > Prasad > > On 6/26/06, Jason Dillon <[EMAIL PROTECTED]> wrote: >> So what to do about openejb? >> >> Build fails: >> >> >> Bliss:~/ws/apache/geronimo/trunk jason$ mvn >> [INFO] Scanning for projects... >> [INFO] >> - >> --- >> [ERROR] FATAL ERROR >> [INFO] >> - >> --- >> [INFO] Error building POM (may not be this project's POM). >> >> >> Project ID: unknown >> >> Reason: Could not find the model file '/Users/jason/ws/apache/ >> geronimo/trunk/openejb/modules/pom.xml'. >> >> >> [INFO] >> - >> --- >> [INFO] Trace >> org.apache.maven.reactor.MavenExecutionException: Could not find the >> model file '/Users/jason/ws/apache/geronimo/trunk/openejb/modules/ >> pom.xml'. >> at org.apache.maven.DefaultMaven.getProjects >> (DefaultMaven.java:365) >> at org.apache.maven.DefaultMaven.doExecute >> (DefaultMaven.java: >> 278) >> at org.apache.maven.DefaultMaven.execute >> (DefaultMaven.java:115) >> at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native >> Method) >> at sun.reflect.NativeMethodAccessorImpl.invoke >> (NativeMethodAccessorImpl.java:39) >> at sun.reflect.DelegatingMethodAccessorImpl.invoke >> (DelegatingMethodAccessorImpl.java:25) >> at java.lang.reflect.Method.invoke(Method.java:324) >> at org.codehaus.classworlds.Launcher.launchEnhanced >> (Launcher.java:315) >> at org.codehaus.classworlds.Launcher.launch(Launcher.java: >> 255) >> at org.codehaus.classworlds.Launcher.mainWithExitCode >> (Launcher.java:430) >> at org.codehaus.classworlds.Launcher.main(Launcher.java:375) >> Caused by: org.apache.maven.project.ProjectBuildingException: Could >> not find the model file '/Users/jason/ws/apache/geronimo/trunk/ >> openejb/modules/pom.xml'. >> at >> org.apache.maven.project.DefaultMavenProjectBuilder.readModel >> (DefaultMavenProjectBuilder.java:1274) >> at >> org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFi >> leI >> nternal(DefaultMavenProjectBuilder.java:414) >> at org.apache.maven.project.DefaultMavenProjectBuilder.build >> (DefaultMavenProjectBuilder.java:192) >> at org.apache.maven.DefaultMaven.getProject >> (DefaultMaven.java:515) >> at org.apache.maven.DefaultMaven.collectProjects >> (DefaultMaven.java:447) >> at org.apache.maven.DefaultMaven.collectProjects >> (DefaultMaven.java:491) >> at org.apache.maven.DefaultMaven.getProjects >> (DefaultMaven.java:351) >> ... 11 more >> Caused by: java.io.FileNotFoundException: /Users/jason/ws/apache/ >> geronimo/trunk/openejb/modules/pom.xml (No such file or directory) >> at java.io.FileInputStream.open(Native Method) >> at java.io.FileInputStream.(FileInputStream.java:106) >> at java.io.FileReader.(
Re: [RTC] update contributors page
Jeff Genender wrote: Hey folks, I want to update the contributors page of the geronimo.apache.org site... - Jeff Genender Virtuas --- + Jeff Genender Savoir Technologies --- Is this ok? Thanks, Jeff Congratulations. You should be fine to make the change as Ken's original mail "Change to commit model for Apache Geronimo" said that RTC applies to all code changes that aren't for documentation or a specific bug fix. AFAIK, the website can be considered documentation. John
Re: Unable to build using m2
I don't see what the problem is. Is this just about putting the version in the parent element? I don't really like that it has to be there, but I am okay with it and using the release plugin to manage that value, which is the main benefit of the release plugin IMO. Or am I missing something? I've recently converted a number of large m1 projects to using m2 and have run into very little issues. Most are related to use of custom jelly, requiring new mojos which is not a big issue. Others being due to projects dependent on those mojos, and keeping them under a separate lifecycle, and expecting that users will download them not build them. So the top-level pom.xml just says 1.2-SNAPSHOT and then all children have ...1.2-SNAPSHOTversion>. This works very well to *build* and is only a slight pain when releasing, but as I mentioned the release plugin handles this. I would obviously rather that it inspect the relativePath first... up until it finds a version and if the parent is not available then pull from the repo... but that isn't gonna happen any time soonish for us to benefit from. IMO, we need to adapt to how m2 works now and then grow with it as we get features/bugs fixed and implemented. --jason On Jun 26, 2006, at 7:21 PM, Prasad Kashyap wrote: Yes, that's the ideal situation and we very much desire it. But here's what's preventing us http://issues.apache.org/jira/browse/GERONIMO-1755#action_12371755 http://jira.codehaus.org/browse/MNG-624 Cheers Prasad On 6/26/06, Jason Dillon <[EMAIL PROTECTED]> wrote: So what to do about openejb? Build fails: Bliss:~/ws/apache/geronimo/trunk jason$ mvn [INFO] Scanning for projects... [INFO] - --- [ERROR] FATAL ERROR [INFO] - --- [INFO] Error building POM (may not be this project's POM). Project ID: unknown Reason: Could not find the model file '/Users/jason/ws/apache/ geronimo/trunk/openejb/modules/pom.xml'. [INFO] - --- [INFO] Trace org.apache.maven.reactor.MavenExecutionException: Could not find the model file '/Users/jason/ws/apache/geronimo/trunk/openejb/modules/ pom.xml'. at org.apache.maven.DefaultMaven.getProjects (DefaultMaven.java:365) at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java: 278) at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.codehaus.classworlds.Launcher.launchEnhanced (Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java: 255) at org.codehaus.classworlds.Launcher.mainWithExitCode (Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.project.ProjectBuildingException: Could not find the model file '/Users/jason/ws/apache/geronimo/trunk/ openejb/modules/pom.xml'. at org.apache.maven.project.DefaultMavenProjectBuilder.readModel (DefaultMavenProjectBuilder.java:1274) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFi leI nternal(DefaultMavenProjectBuilder.java:414) at org.apache.maven.project.DefaultMavenProjectBuilder.build (DefaultMavenProjectBuilder.java:192) at org.apache.maven.DefaultMaven.getProject (DefaultMaven.java:515) at org.apache.maven.DefaultMaven.collectProjects (DefaultMaven.java:447) at org.apache.maven.DefaultMaven.collectProjects (DefaultMaven.java:491) at org.apache.maven.DefaultMaven.getProjects (DefaultMaven.java:351) ... 11 more Caused by: java.io.FileNotFoundException: /Users/jason/ws/apache/ geronimo/trunk/openejb/modules/pom.xml (No such file or directory) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.(FileInputStream.java:106) at java.io.FileReader.(FileReader.java:55) at org.apache.maven.project.DefaultMavenProjectBuilder.readModel (DefaultMavenProjectBuilder.java:1269) ... 17 more [INFO] - --- [INFO] Total time: 33 seconds [INFO] Finished at: Mon Jun 26 18:30:25 PDT 2006 [INFO] Final Memory: 7M/14M [INFO] - --- Do I need to check something else out? If so... WHY? Or do I need to pass some-other configuration? If so... WHY? I've said this before and will say it again (and again)...
Re: Unable to build using m2
Yes, that's the ideal situation and we very much desire it. But here's what's preventing us http://issues.apache.org/jira/browse/GERONIMO-1755#action_12371755 http://jira.codehaus.org/browse/MNG-624 Cheers Prasad On 6/26/06, Jason Dillon <[EMAIL PROTECTED]> wrote: So what to do about openejb? Build fails: Bliss:~/ws/apache/geronimo/trunk jason$ mvn [INFO] Scanning for projects... [INFO] [ERROR] FATAL ERROR [INFO] [INFO] Error building POM (may not be this project's POM). Project ID: unknown Reason: Could not find the model file '/Users/jason/ws/apache/ geronimo/trunk/openejb/modules/pom.xml'. [INFO] [INFO] Trace org.apache.maven.reactor.MavenExecutionException: Could not find the model file '/Users/jason/ws/apache/geronimo/trunk/openejb/modules/ pom.xml'. at org.apache.maven.DefaultMaven.getProjects (DefaultMaven.java:365) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java: 278) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.codehaus.classworlds.Launcher.launchEnhanced (Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode (Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.project.ProjectBuildingException: Could not find the model file '/Users/jason/ws/apache/geronimo/trunk/ openejb/modules/pom.xml'. at org.apache.maven.project.DefaultMavenProjectBuilder.readModel (DefaultMavenProjectBuilder.java:1274) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileI nternal(DefaultMavenProjectBuilder.java:414) at org.apache.maven.project.DefaultMavenProjectBuilder.build (DefaultMavenProjectBuilder.java:192) at org.apache.maven.DefaultMaven.getProject (DefaultMaven.java:515) at org.apache.maven.DefaultMaven.collectProjects (DefaultMaven.java:447) at org.apache.maven.DefaultMaven.collectProjects (DefaultMaven.java:491) at org.apache.maven.DefaultMaven.getProjects (DefaultMaven.java:351) ... 11 more Caused by: java.io.FileNotFoundException: /Users/jason/ws/apache/ geronimo/trunk/openejb/modules/pom.xml (No such file or directory) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.(FileInputStream.java:106) at java.io.FileReader.(FileReader.java:55) at org.apache.maven.project.DefaultMavenProjectBuilder.readModel (DefaultMavenProjectBuilder.java:1269) ... 17 more [INFO] [INFO] Total time: 33 seconds [INFO] Finished at: Mon Jun 26 18:30:25 PDT 2006 [INFO] Final Memory: 7M/14M [INFO] Do I need to check something else out? If so... WHY? Or do I need to pass some-other configuration? If so... WHY? I've said this before and will say it again (and again)... I should be able to: 1) svn co .../geronimo/trunk 2) mvn install ... 3) start the server The only assumption made is that Maven 2.0 is installed and that JAVA_HOME (or the equiv on OS X) is setup correctly. If there are more than 3 steps to go from src to server, then something is wrong... and should be fixed. * * * Its been months since I have been able to actually build G... I'd recommend that people periodically blow away your repository cache so that you get really clean builds. Often m2 problems will only start to show up when a clean repo is used... :-( --jason On Jun 26, 2006, at 6:46 PM, Prasad Kashyap wrote: > I'm sorry but I'm confused about this main build and the plugins > build. I thought they are all one single build like we did in m1 with > all the new(xx). > > This is how the build order is specified in the geronimo/pom.xml > > > modules > m2-plugins > applications > openejb/modules > configs > assemblies > > > There's no cyclical dependency there. > > > Jason, as for the , I tried that. It didn't help. Also, > the default value of is ../pom.xml anyways. > > Cheers > Prasad > > > > > On 6/26/06, Jason Dillon <[EMAIL PROTECTED]> wrote: >> FYI, seems that you need to build trunk first (probably until it >> fails with a missing plugin), then build the plugins, t
Re: Unable to build using m2
FYI... if I comment the openejb/modules and `mvn install` I get: [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Plugin could not be found - check that the goal name is correct: Unable to download the artifact from any repository Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.geronimo.plugins - DartifactId=geronimo-packaging-plug in \ -Dversion=1.2.0 -Dpackaging=maven-plugin -Dfile=/path/to/file org.apache.geronimo.plugins:geronimo-packaging-plugin:maven-plugin: 1.2.0 from the specified remote repositories: central (http://repo1.maven.org/maven2), codehaus-dist (http://dist.codehaus.org/mojo/m2-snapshots), snapshots (http://snapshots.maven.codehaus.org/maven2) org.apache.geronimo.plugins:geronimo-packaging-plugin:maven-plugin: 1.2.0 from the specified remote repositories: central (http://repo1.maven.org/maven2), codehaus-dist (http://dist.codehaus.org/mojo/m2-snapshots), snapshots (http://snapshots.maven.codehaus.org/maven2) I'm also a little bit mystified as to why we are managing versions of modules that we build with properties in each module. There should be one tag in the top-level module, and all children omit this tag and pick it up be inheritance. The added properties and tag configuration is just adding extra complexity to the build with no reason. I understand that some of this might be legacy picked up from exp using m1, but m2 is a different beast and IMO we should drop any of the m1-isms whenever possible/prudent. Also, why is the main-build using 1.2-SNAPSHOT and the plugin is 1.2.0? This all seems kinda fishy to me. And, I don't see any reason why the root pom needs to define properties and then use those properties for each and every dependency in the dependencyManagement section. I believe that when a version number is used more than once, say for the spring jars that it is easier/better to manage a single property that is used by all of the dependencies. But to force all dependencies to use these properties when the property is used in only one place is added overhead which means more complex and fragile builds when configuration changes. --jason On Jun 26, 2006, at 6:46 PM, Prasad Kashyap wrote: I'm sorry but I'm confused about this main build and the plugins build. I thought they are all one single build like we did in m1 with all the new(xx). This is how the build order is specified in the geronimo/pom.xml modules m2-plugins applications openejb/modules configs assemblies There's no cyclical dependency there. Jason, as for the , I tried that. It didn't help. Also, the default value of is ../pom.xml anyways. Cheers Prasad On 6/26/06, Jason Dillon <[EMAIL PROTECTED]> wrote: FYI, seems that you need to build trunk first (probably until it fails with a missing plugin), then build the plugins, then rebuild trunk. Just building m2-plugins pukes with: [INFO] - --- [ERROR] BUILD ERROR [INFO] - --- [INFO] Failed to resolve artifact. Missing: -- 1) org.apache.geronimo.modules:geronimo-deploy-tool:jar:1.2-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.geronimo.modules -DartifactId=geronimo-deploy-tool \ -Dversion=1.2-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/ file Path to dependency: 1) org.apache.geronimo.plugins:geronimo-packaging- plugin:maven-plugin:1.2.0 2) org.apache.geronimo.modules:geronimo-deploy-tool:jar:1.2- SNAPSHOT 2) org.apache.geronimo.modules:geronimo-kernel:jar:1.2-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.geronimo.modules -DartifactId=geronimo-kernel \ -Dversion=1.2-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/ file Path to dependency: 1) org.apache.geronimo.plugins:geronimo-packaging- plugin:maven-plugin:1.2.0 2) org.apache.geronimo.modules:geronimo-kernel:jar:1.2- SNAPSHOT 3) org.apache.geronimo.modules:geronimo-service-builder:jar:1.2- SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.geronimo.modules -DartifactId=geronimo-service-builder \ -Dversion=1.2-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/ file Path to dependency: 1) org.apache.geronimo.plugins:geronimo-packaging- plugin:maven-plugin:1.2.0 2)
Re: Unable to build using m2
So what to do about openejb? Build fails: Bliss:~/ws/apache/geronimo/trunk jason$ mvn [INFO] Scanning for projects... [INFO] [ERROR] FATAL ERROR [INFO] [INFO] Error building POM (may not be this project's POM). Project ID: unknown Reason: Could not find the model file '/Users/jason/ws/apache/ geronimo/trunk/openejb/modules/pom.xml'. [INFO] [INFO] Trace org.apache.maven.reactor.MavenExecutionException: Could not find the model file '/Users/jason/ws/apache/geronimo/trunk/openejb/modules/ pom.xml'. at org.apache.maven.DefaultMaven.getProjects (DefaultMaven.java:365) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java: 278) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.codehaus.classworlds.Launcher.launchEnhanced (Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode (Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.project.ProjectBuildingException: Could not find the model file '/Users/jason/ws/apache/geronimo/trunk/ openejb/modules/pom.xml'. at org.apache.maven.project.DefaultMavenProjectBuilder.readModel (DefaultMavenProjectBuilder.java:1274) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileI nternal(DefaultMavenProjectBuilder.java:414) at org.apache.maven.project.DefaultMavenProjectBuilder.build (DefaultMavenProjectBuilder.java:192) at org.apache.maven.DefaultMaven.getProject (DefaultMaven.java:515) at org.apache.maven.DefaultMaven.collectProjects (DefaultMaven.java:447) at org.apache.maven.DefaultMaven.collectProjects (DefaultMaven.java:491) at org.apache.maven.DefaultMaven.getProjects (DefaultMaven.java:351) ... 11 more Caused by: java.io.FileNotFoundException: /Users/jason/ws/apache/ geronimo/trunk/openejb/modules/pom.xml (No such file or directory) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.(FileInputStream.java:106) at java.io.FileReader.(FileReader.java:55) at org.apache.maven.project.DefaultMavenProjectBuilder.readModel (DefaultMavenProjectBuilder.java:1269) ... 17 more [INFO] [INFO] Total time: 33 seconds [INFO] Finished at: Mon Jun 26 18:30:25 PDT 2006 [INFO] Final Memory: 7M/14M [INFO] Do I need to check something else out? If so... WHY? Or do I need to pass some-other configuration? If so... WHY? I've said this before and will say it again (and again)... I should be able to: 1) svn co .../geronimo/trunk 2) mvn install ... 3) start the server The only assumption made is that Maven 2.0 is installed and that JAVA_HOME (or the equiv on OS X) is setup correctly. If there are more than 3 steps to go from src to server, then something is wrong... and should be fixed. * * * Its been months since I have been able to actually build G... I'd recommend that people periodically blow away your repository cache so that you get really clean builds. Often m2 problems will only start to show up when a clean repo is used... :-( --jason On Jun 26, 2006, at 6:46 PM, Prasad Kashyap wrote: I'm sorry but I'm confused about this main build and the plugins build. I thought they are all one single build like we did in m1 with all the new(xx). This is how the build order is specified in the geronimo/pom.xml modules m2-plugins applications openejb/modules configs assemblies There's no cyclical dependency there. Jason, as for the , I tried that. It didn't help. Also, the default value of is ../pom.xml anyways. Cheers Prasad On 6/26/06, Jason Dillon <[EMAIL PROTECTED]> wrote: FYI, seems that you need to build trunk first (probably until it fails with a missing plugin), then build the plugins, then rebuild trunk. Just building m2-plugins pukes with: [INFO] - --- [ERROR] BUILD ERROR [INFO] - --- [INFO] Failed to resolve artifact. Mis
Re: Unable to build using m2
Jason, as for the , I tried that. It didn't help. Also, the default value of is ../pom.xml anyways. There are a few cases when this will not work, a bug in m2 code AFAIK. Better to make it explicit IMO. --jason
[RTC] Update for new OpenEJB 2.2
I have finished the work to update the openejb dead-2.2 branch to run with Geronimo 1.2. The dead-2.2 branch contains a major rearchitecture of the OpenEJB container system which split the deployment units from reusable container and this rearchitecture has already been adopted in OpenEJB 3. This work was done in the https:// svn.apache.org/repos/asf/geronimo/branches/dain/openejb-2.2-merge branch, and is largely composed of merges from the Geronimo dead-1.2 branch. A patch for this change can be found in GERONIMO-12345, but the attached patch is not expected work perfectly. Any mismatches or problems will be worked out during the final merge with trunk. The best way to test this change is to checkout and build the branch directly. The maven m:co goal should work to check out the https:// svn.codehaus.org/openejb/branches/dain-2.2-merge/merged branch from openejb. For those with tck access, there is a dain-openejb-2.2- merge branch available for testing the tck. Please, review this quickly so the branch doesn't drift too much. Thanks in advance, -dain A quick history of this branch follows: 417321 Fixed openejb version number in project.properties 416533 Applied GERONIMO-1960 which verifies GBean references when the final configuration data is created in a deployment context 416483 Fixed deployment plans to match newest openejb changes 416428 Fixed more plans 415721 Biggest change which updates the j2ee deployment context to contain the transactionManager name amongst some smaller changes 415720 Update maven.xml to use new openejb module names 415225 Set svn:ignore on new interceptor module 415224 svn merge -r 378403:378404 https://svn.apache.org/repos/asf/ geronimo/[EMAIL PROTECTED] 415222 svn merge -r 378358:378359 https://svn.apache.org/repos/asf/ geronimo/[EMAIL PROTECTED] 415220 svn merge -r 378346:378347 https://svn.apache.org/repos/asf/ geronimo/[EMAIL PROTECTED] 415218 svn merge -r 378182:378183 https://svn.apache.org/repos/asf/ geronimo/[EMAIL PROTECTED] 415217 svn merge -r 378161:378162 https://svn.apache.org/repos/asf/ geronimo/[EMAIL PROTECTED]
Re: Unable to build using m2
I'm sorry but I'm confused about this main build and the plugins build. I thought they are all one single build like we did in m1 with all the new(xx). This is how the build order is specified in the geronimo/pom.xml modules m2-plugins applications openejb/modules configs assemblies There's no cyclical dependency there. Jason, as for the , I tried that. It didn't help. Also, the default value of is ../pom.xml anyways. Cheers Prasad On 6/26/06, Jason Dillon <[EMAIL PROTECTED]> wrote: FYI, seems that you need to build trunk first (probably until it fails with a missing plugin), then build the plugins, then rebuild trunk. Just building m2-plugins pukes with: [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Missing: -- 1) org.apache.geronimo.modules:geronimo-deploy-tool:jar:1.2-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.geronimo.modules -DartifactId=geronimo-deploy-tool \ -Dversion=1.2-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.geronimo.plugins:geronimo-packaging- plugin:maven-plugin:1.2.0 2) org.apache.geronimo.modules:geronimo-deploy-tool:jar:1.2- SNAPSHOT 2) org.apache.geronimo.modules:geronimo-kernel:jar:1.2-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.geronimo.modules -DartifactId=geronimo-kernel \ -Dversion=1.2-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.geronimo.plugins:geronimo-packaging- plugin:maven-plugin:1.2.0 2) org.apache.geronimo.modules:geronimo-kernel:jar:1.2-SNAPSHOT 3) org.apache.geronimo.modules:geronimo-service-builder:jar:1.2-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.geronimo.modules -DartifactId=geronimo-service-builder \ -Dversion=1.2-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.geronimo.plugins:geronimo-packaging- plugin:maven-plugin:1.2.0 2) org.apache.geronimo.modules:geronimo-service-builder:jar: 1.2-SNAPSHOT 4) org.apache.geronimo.modules:geronimo-system:jar:1.2-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.geronimo.modules -DartifactId=geronimo-system \ -Dversion=1.2-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.geronimo.plugins:geronimo-packaging- plugin:maven-plugin:1.2.0 2) org.apache.geronimo.modules:geronimo-system:jar:1.2-SNAPSHOT -- 4 required artifacts are missing. for artifact: org.apache.geronimo.plugins:geronimo-packaging-plugin:maven-plugin: 1.2.0 from the specified remote repositories: central (http://repo1.maven.org/maven2), codehaus-dist (http://dist.codehaus.org), Apache CVS (http://people.apache.org/maven-snapshot-repository), maven1-ibiblio (http://www.ibiblio.org/maven), snapshots (http://snapshots.maven.codehaus.org/maven2), apache-cvs (http://cvs.apache.org/repository) Looks like bad news... if the main build needs the plugin, and the plugin needs the main build, and m2 won't let it all run/build at the same time due to its plugin resolution fluff. May need to provide a bootstrap, which builds a few select modules, then the entire system... but that is not very friendly either. * * * Also, start adding ../pom.xml to the parent element, so that you can skip the mvn -N install bits. --jason On Jun 26, 2006, at 1:05 PM, Prasad Kashyap wrote: > Alan, > > You'd have to build the geronimo-packaging-plugin manually first. It's > under geronimo/m2-plugins > > cd geronimo/m2-plugins > mvn clean > mvn -N > mvn > > Cheers > Prasad > > On 6/25/06, Alan D. Cabrera <[EMAIL PROTECTED]> wrote: >> I get this error: >> >> Try downloading the file manually from the project website. >> >> Then, install it using the command: >> mvn install:install-file -DgroupId=org.apache.geronimo.plugins >> -DartifactId=geronimo-packaging-plugin \ >> -Dversion=1.2.0 -Dpackaging=maven-plugin -Dfile=/path/to/file >> >> >> org.apache.geronimo.plugins:geronimo-packaging-plugin:maven- >> plugin:1.2.0 >> >> from the specified remote repositories: >> central (http://repo1.maven.org/maven2), >> codehaus-dist (http://dist.codehaus.org/mojo/m2-snapshots), >> snapshots (http://snapshots.maven.codehaus.org/maven2) >> >> org.apache.geronimo.plugins:geronimo-packaging-plugin:ma
[jira] Updated: (GERONIMO-2152) Update for new OpenEJB 2.2
[ http://issues.apache.org/jira/browse/GERONIMO-2152?page=all ] Dain Sundstrom updated GERONIMO-2152: - Attachment: openejb-2.2-merge.patch > Update for new OpenEJB 2.2 > -- > > Key: GERONIMO-2152 > URL: http://issues.apache.org/jira/browse/GERONIMO-2152 > Project: Geronimo > Type: Improvement > Security: public(Regular issues) > Components: OpenEJB > Reporter: Dain Sundstrom > Assignee: Dain Sundstrom > Fix For: 1.2 > Attachments: openejb-2.2-merge.patch > > OpenEJB 2.2 will be based on the > https://svn.apache.org/repos/asf/geronimo/branches/dain/openejb-2.2-merge > branch which includes a major rearchitecture of the container system. This > architecture is the basis of OpenEJB 3. The attached patch will update > Geronimo to support the changes. This patch was generated with the > following SVN command: > svn diff -r 415216:HEAD > https://svn.apache.org/repos/asf/geronimo/branches/dain/openejb-2.2-merge > Note the attached patch is not expected work perfectly. Any mismatches or > problems will be worked out during the final merge with trunk. The best way > to test this change is to checkout the > https://svn.apache.org/repos/asf/geronimo/branches/dain/openejb-2.2-merge > branch directly. -- 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: (GERONIMO-2152) Update for new OpenEJB 2.2
Update for new OpenEJB 2.2 -- Key: GERONIMO-2152 URL: http://issues.apache.org/jira/browse/GERONIMO-2152 Project: Geronimo Type: Improvement Security: public (Regular issues) Components: OpenEJB Reporter: Dain Sundstrom Assigned to: Dain Sundstrom Fix For: 1.2 Attachments: openejb-2.2-merge.patch OpenEJB 2.2 will be based on the https://svn.apache.org/repos/asf/geronimo/branches/dain/openejb-2.2-merge branch which includes a major rearchitecture of the container system. This architecture is the basis of OpenEJB 3. The attached patch will update Geronimo to support the changes. This patch was generated with the following SVN command: svn diff -r 415216:HEAD https://svn.apache.org/repos/asf/geronimo/branches/dain/openejb-2.2-merge Note the attached patch is not expected work perfectly. Any mismatches or problems will be worked out during the final merge with trunk. The best way to test this change is to checkout the https://svn.apache.org/repos/asf/geronimo/branches/dain/openejb-2.2-merge branch directly. -- 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: (GSHELL-1) Add ${...} parsing to the CommandLineParser; remove VariableExpressionParser
[
http://issues.apache.org/jira/browse/GSHELL-1?page=comments#action_12417940 ]
Jason Dillon commented on GSHELL-1:
---
Still need to hold on to something like JEXL to handle the variable expression
expansion.
> Add ${...} parsing to the CommandLineParser; remove VariableExpressionParser
>
>
> Key: GSHELL-1
> URL: http://issues.apache.org/jira/browse/GSHELL-1
> Project: GShell (Sandbox)
> Type: Improvement
> Security: public(Regular issues)
> Components: Core
> Versions: 0.0.1
> Reporter: Jason Dillon
> Assignee: Jason Dillon
> Priority: Critical
>
> Currently variable references are post-parsed because that was easier to get
> implemented. The CL parser should be able to handle all parsing.
--
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
Enable wiki-rendering for GERONIMO JIRA project
Any objections to enabling wiki-rendering for the GERONIMO JIRA project? This will allow comment and description fields to utilize Confluence- style wiki markup. Its basically just a configuration change, done project by project. I think this is a good idea. Do we need to vote this change in? Or shall we just enable it if there is no negative comments? --jason
Re: Extend class path from config.xml
Seems like a reasonable thing to have. Is this an extension to the plan's xsd or just a specialized gbean that can augment the classpath? --jason On Jun 26, 2006, at 5:26 PM, Dain Sundstrom wrote: I think we should add support to extend the class path from the config.xml file. Without this it is not possible to add GBeans via a the configuration.xml using classes not declared in the original plan. Another problem revolves around extension hooks in services. It is common for a service to allow you to specify a alternative implementation for some internal service. For example, our SecurityService GBean allows for the replacement of the policyConfigurationFactory and the policyProvider. Unfortunately, these hooks are virtually useless since the replacement classes must have been included in the environment of the original plan. Of course, the best option would be to rewrite this service to use references, which are easily replaceable and externalizable in another plan, but that is not always possible. I have no plans to implement this myself, but wanted to get a discussion going, and if we decide that is want to add this feature, I'll create a JIRA to track it. -dain
Re: Unable to build using m2
FYI, seems that you need to build trunk first (probably until it fails with a missing plugin), then build the plugins, then rebuild trunk. Just building m2-plugins pukes with: [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Missing: -- 1) org.apache.geronimo.modules:geronimo-deploy-tool:jar:1.2-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.geronimo.modules -DartifactId=geronimo-deploy-tool \ -Dversion=1.2-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.geronimo.plugins:geronimo-packaging- plugin:maven-plugin:1.2.0 2) org.apache.geronimo.modules:geronimo-deploy-tool:jar:1.2- SNAPSHOT 2) org.apache.geronimo.modules:geronimo-kernel:jar:1.2-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.geronimo.modules -DartifactId=geronimo-kernel \ -Dversion=1.2-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.geronimo.plugins:geronimo-packaging- plugin:maven-plugin:1.2.0 2) org.apache.geronimo.modules:geronimo-kernel:jar:1.2-SNAPSHOT 3) org.apache.geronimo.modules:geronimo-service-builder:jar:1.2-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.geronimo.modules -DartifactId=geronimo-service-builder \ -Dversion=1.2-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.geronimo.plugins:geronimo-packaging- plugin:maven-plugin:1.2.0 2) org.apache.geronimo.modules:geronimo-service-builder:jar: 1.2-SNAPSHOT 4) org.apache.geronimo.modules:geronimo-system:jar:1.2-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.geronimo.modules -DartifactId=geronimo-system \ -Dversion=1.2-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.geronimo.plugins:geronimo-packaging- plugin:maven-plugin:1.2.0 2) org.apache.geronimo.modules:geronimo-system:jar:1.2-SNAPSHOT -- 4 required artifacts are missing. for artifact: org.apache.geronimo.plugins:geronimo-packaging-plugin:maven-plugin: 1.2.0 from the specified remote repositories: central (http://repo1.maven.org/maven2), codehaus-dist (http://dist.codehaus.org), Apache CVS (http://people.apache.org/maven-snapshot-repository), maven1-ibiblio (http://www.ibiblio.org/maven), snapshots (http://snapshots.maven.codehaus.org/maven2), apache-cvs (http://cvs.apache.org/repository) Looks like bad news... if the main build needs the plugin, and the plugin needs the main build, and m2 won't let it all run/build at the same time due to its plugin resolution fluff. May need to provide a bootstrap, which builds a few select modules, then the entire system... but that is not very friendly either. * * * Also, start adding ../pom.xml to the parent element, so that you can skip the mvn -N install bits. --jason On Jun 26, 2006, at 1:05 PM, Prasad Kashyap wrote: Alan, You'd have to build the geronimo-packaging-plugin manually first. It's under geronimo/m2-plugins cd geronimo/m2-plugins mvn clean mvn -N mvn Cheers Prasad On 6/25/06, Alan D. Cabrera <[EMAIL PROTECTED]> wrote: I get this error: Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.geronimo.plugins -DartifactId=geronimo-packaging-plugin \ -Dversion=1.2.0 -Dpackaging=maven-plugin -Dfile=/path/to/file org.apache.geronimo.plugins:geronimo-packaging-plugin:maven- plugin:1.2.0 from the specified remote repositories: central (http://repo1.maven.org/maven2), codehaus-dist (http://dist.codehaus.org/mojo/m2-snapshots), snapshots (http://snapshots.maven.codehaus.org/maven2) org.apache.geronimo.plugins:geronimo-packaging-plugin:maven- plugin:1.2.0 from the specified remote repositories: central (http://repo1.maven.org/maven2), codehaus-dist (http://dist.codehaus.org/mojo/m2-snapshots), snapshots (http://snapshots.maven.codehaus.org/maven2) Regards, Alan
Extend class path from config.xml
I think we should add support to extend the class path from the config.xml file. Without this it is not possible to add GBeans via a the configuration.xml using classes not declared in the original plan. Another problem revolves around extension hooks in services. It is common for a service to allow you to specify a alternative implementation for some internal service. For example, our SecurityService GBean allows for the replacement of the policyConfigurationFactory and the policyProvider. Unfortunately, these hooks are virtually useless since the replacement classes must have been included in the environment of the original plan. Of course, the best option would be to rewrite this service to use references, which are easily replaceable and externalizable in another plan, but that is not always possible. I have no plans to implement this myself, but wanted to get a discussion going, and if we decide that is want to add this feature, I'll create a JIRA to track it. -dain
Re: [RTC] update contributors page
Jacek Laskowski wrote: > On 6/27/06, Jeff Genender <[EMAIL PROTECTED]> wrote: >> Hey folks, >> >> I want to update the contributors page of the geronimo.apache.org site... >> >> - Jeff Genender >> Virtuas > bgcolor="#f3f4f5">--- >> + Jeff Genender >> Savoir Technologies >> --- >> >> Is this ok? > > +1 iff Jeff Genender is indeed employed by Savoir Technologies :-) Indeed I am ;-) > > Do docs changes require a vote? I don't think so. > >> Jeff > > Jacek >
Re: [RTC] update contributors page
Thanks!! Sachin Patel wrote: > +1 and congratulations! > > On Jun 26, 2006, at 7:31 PM, Jeff Genender wrote: > >> Hey folks, >> >> I want to update the contributors page of the geronimo.apache.org site... >> >> - Jeff Genender >> Virtuas > bgcolor="#f3f4f5">--- >> + Jeff Genender >> Savoir Technologies >> --- >> >> Is this ok? >> >> Thanks, >> >> Jeff > > > -sachin >
Re: [RTC] update contributors page
+1 and congratulations! On Jun 26, 2006, at 7:31 PM, Jeff Genender wrote: Hey folks, I want to update the contributors page of the geronimo.apache.org site... - Jeff Genender Virtuas --- + Jeff Genender Savoir Technologies --- Is this ok? Thanks, Jeff -sachin
Re: [RTC] update contributors page
On 6/27/06, Jeff Genender <[EMAIL PROTECTED]> wrote: Hey folks, I want to update the contributors page of the geronimo.apache.org site... - Jeff Genender Virtuas --- + Jeff Genender Savoir Technologies --- Is this ok? +1 iff Jeff Genender is indeed employed by Savoir Technologies :-) Do docs changes require a vote? I don't think so. Jeff Jacek -- Jacek Laskowski http://www.laskowski.net.pl
[RTC] update contributors page
Hey folks, I want to update the contributors page of the geronimo.apache.org site... - Jeff Genender Virtuas --- + Jeff Genender Savoir Technologies --- Is this ok? Thanks, Jeff
Re: Unable to build using m2
IMO we should have a completely separate tree for our build support tools. And once the plugins are stable we release them, until they are stable we make regular snaps, so that the main tree(s) can just build w/o having to worry about building plugins first. --jason On Jun 26, 2006, at 1:05 PM, Prasad Kashyap wrote: Alan, You'd have to build the geronimo-packaging-plugin manually first. It's under geronimo/m2-plugins cd geronimo/m2-plugins mvn clean mvn -N mvn Cheers Prasad On 6/25/06, Alan D. Cabrera <[EMAIL PROTECTED]> wrote: I get this error: Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.geronimo.plugins -DartifactId=geronimo-packaging-plugin \ -Dversion=1.2.0 -Dpackaging=maven-plugin -Dfile=/path/to/file org.apache.geronimo.plugins:geronimo-packaging-plugin:maven- plugin:1.2.0 from the specified remote repositories: central (http://repo1.maven.org/maven2), codehaus-dist (http://dist.codehaus.org/mojo/m2-snapshots), snapshots (http://snapshots.maven.codehaus.org/maven2) org.apache.geronimo.plugins:geronimo-packaging-plugin:maven- plugin:1.2.0 from the specified remote repositories: central (http://repo1.maven.org/maven2), codehaus-dist (http://dist.codehaus.org/mojo/m2-snapshots), snapshots (http://snapshots.maven.codehaus.org/maven2) Regards, Alan
[jira] Created: (AMQ-777) maxReconnectAttempts has no effect
maxReconnectAttempts has no effect -- Key: AMQ-777 URL: https://issues.apache.org/activemq/browse/AMQ-777 Project: ActiveMQ Type: Bug Versions: 4.0.1 Reporter: Jonny Wray I saw this entry in the forums and I'm having the same problem, setting maxReconnectAttempts to a specific value does not stop the infinite loop of "Waiting for transport to reconnect" from occuring. http://www.nabble.com/Discovery-Fail-if-no-Broker-t1824894.html#a4977620 The forum reply from Hiram Chirino suggests it's a bug but I didn't find an associated JIRA issue. Jonny -- 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: [VOTE] Release branching process (was Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.)
Thanks David. David Blevins wrote: On Jun 25, 2006, at 8:49 PM, Alan D. Cabrera wrote: Greg Wilkins wrote: I think the wiki should clarify the patch process for release branches. Agreed. I have added slight caveats for New Features: develop in trunk patch to current x.y branch (if to be captured in next x.y.z release) Fixes develop in x.y branch (if to be captured in next x.y.z release else develop in trunk) patch to trunk patch to current x.y.z (if it is a TCK bug). This is good discussion. In the interests of seeing it continue while keeping clear what we've voted on and what is still open for discussion, i've split this out into a new wiki page titled with the soft word "guidelines." http://cwiki.apache.org/GMOxPMGT/development-and-patch-guidelines.html Further, i've added a "Notice" section at the bottom of this page that states, "The process in this document was voted on by the Geronimo community. Please formally propose all changes to dev@geronimo.apache.org" http://cwiki.apache.org/GMOxPMGT/release-branching-process.html -David Regards, Alan
[jira] Updated: (GERONIMO-2046) no caching implementation
[ http://issues.apache.org/jira/browse/GERONIMO-2046?page=all ] Bill Dudney updated GERONIMO-2046: -- Attachment: geronimo-cache-2.patch this patch adds JMS impl to the replicated server I also did some refactoring so there are some svn commands to apply to get that refactoring done properly (doc'ed below) apply the patch from $geronimo_sandbox/geronimo-cache > patch -p0 < geronimo-cache-2.patch delete the old copy of the code; svn del src/main/java/org/apache/geronimo/cache/comm/impl add the new directories; svn add src/test/java/org/apache/geronimo/cache/comm/amqimpl svn add src/main/java/org/apache/geronimo/cache/comm/amqimpl svn add src/main/java/org/apache/geronimo/cache/comm/CacheCommListener.java svn add src/main/java/org/apache/geronimo/cache/comm/udpimpl which should get the patch properly applied. Let me know if there are any issues. Thanks! > no caching implementation > - > > Key: GERONIMO-2046 > URL: http://issues.apache.org/jira/browse/GERONIMO-2046 > Project: Geronimo > Type: New Feature > Security: public(Regular issues) > Components: general > Reporter: Bill Dudney > Assignee: Jeff Genender > Priority: Minor > Attachments: geronimo-cache-2.patch, geronimo-cache.patch > > This is a first cut at a replicating cache for caching stuff behind the > session api (the session api is in the 1.2 branch). > To make it build you have to install the session api first (i.e. mvn install). > There is currenly only a maven 2 build in place. -- 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: Unable to build using m2
Alan, You'd have to build the geronimo-packaging-plugin manually first. It's under geronimo/m2-plugins cd geronimo/m2-plugins mvn clean mvn -N mvn Cheers Prasad On 6/25/06, Alan D. Cabrera <[EMAIL PROTECTED]> wrote: I get this error: Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.geronimo.plugins -DartifactId=geronimo-packaging-plugin \ -Dversion=1.2.0 -Dpackaging=maven-plugin -Dfile=/path/to/file org.apache.geronimo.plugins:geronimo-packaging-plugin:maven-plugin:1.2.0 from the specified remote repositories: central (http://repo1.maven.org/maven2), codehaus-dist (http://dist.codehaus.org/mojo/m2-snapshots), snapshots (http://snapshots.maven.codehaus.org/maven2) org.apache.geronimo.plugins:geronimo-packaging-plugin:maven-plugin:1.2.0 from the specified remote repositories: central (http://repo1.maven.org/maven2), codehaus-dist (http://dist.codehaus.org/mojo/m2-snapshots), snapshots (http://snapshots.maven.codehaus.org/maven2) Regards, Alan
Re: Lets start moving to m2
On 6/26/06, Prasad Kashyap <[EMAIL PROTECTED]> wrote: Do we have to go thro the RTC for the geronimo-assembly-plugin ? It is essentially the same code that we had in m1's BaseConfigInstaller.java modified to be a mojo. That's it. Is it a fix? Is it applied to the trunk? If the answers are 'no' and 'yes', call a vote. Painful, but that's how we operate at the moment. Prasad Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: Lets start moving to m2
On 6/26/06, David Jencks <[EMAIL PROTECTED]> wrote: I'm suggesting that we declare the m1 build obsolete and remove it, except possibly for the assembly step and perhaps modules where the tests do not run under m2. Well, don't get it annoying, but I still don't understand it. Let's pretend we've named the m1 build obsolete, what's next? Shall we call a vote? If it passes, what would be the next steps? If you removed the top-level build.xml I'd know what it'd mean, but now I don't get it. david jencks Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: Lets start moving to m2
I'm whiskers away from finishing the assembly plugin. I am down to the nitty grittties of ensuring the correct file mode on the various files and directories. I also have to set and ensure the correct line endings. What else ? We have to get maven to apply the patch for the assembly plugin and deploy the plugin to a remote repo. Do we have to go thro the RTC for the geronimo-assembly-plugin ? It is essentially the same code that we had in m1's BaseConfigInstaller.java modified to be a mojo. That's it. Cheers Prasad On 6/26/06, David Jencks <[EMAIL PROTECTED]> wrote: On Jun 26, 2006, at 11:05 AM, Jacek Laskowski wrote: > On 6/26/06, David Jencks <[EMAIL PROTECTED]> wrote: >> Although there are still some problems (such as not running all the >> tests) I think we have pretty much all of the build working in m2 >> except for the assembly stage, due to the lack of an m2 assembly >> plugin. I'm not sure of the status of such a plugin, but I'd like to >> suggest that we try to make the build be m2-only except for assembly, >> and m1 for the assembly step until a suitable plugin exists. >> >> Comments? Objections? > > Worth to try out, but...haven't we been doing it since a couple of > months? I don't understand what else we could do. Do you think about > something concrete? I think I didn't read your email well. I'm suggesting that we declare the m1 build obsolete and remove it, except possibly for the assembly step and perhaps modules where the tests do not run under m2. thanks david jencks > >> david jencks > > Jacek > > -- > Jacek Laskowski > http://www.laskowski.net.pl
[jira] Commented: (GERONIMO-1980) Move Plugin Installer from rmi-naming to j2ee-system
[ http://issues.apache.org/jira/browse/GERONIMO-1980?page=comments#action_12417888 ] David Jencks commented on GERONIMO-1980: About the thread pool, perhaps we should consider having a system thread pool for long lived system level threads such as the plugin installer's, the connection pool idle timeout cleanup, etc etc, and having "user" threads from a separate pool? I'd be ok with such a system thread pool in j2ee-system. > Move Plugin Installer from rmi-naming to j2ee-system > > > Key: GERONIMO-1980 > URL: http://issues.apache.org/jira/browse/GERONIMO-1980 > Project: Geronimo > Type: Improvement > Security: public(Regular issues) > Components: buildsystem, Plugins > Versions: 1.1 > Reporter: Aaron Mulder > Fix For: 1.2 > > Ideally, the plugin installer will be as high in the food chain as possible, > so it can replace as much as possible without shutting itself down. > Currently it is in rmi-naming. > I tried moving it to j2ee-system, which requires the following new > dependencies for j2ee-system: > - geronimo-core > - geronimo-management > - geronimo-util > - geronimo-j2ee-management_1.0_spec > - concurrent > Somehow, the net result of this was that the OpenEJB config could not load > javax.ejb.EJBObject, so there's something funky going on with the class > loaders when the above changes are made. -- 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: [VOTE] Release branching process (was Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.)
David Blevins wrote: On Jun 25, 2006, at 8:49 PM, Alan D. Cabrera wrote: Greg Wilkins wrote: I think the wiki should clarify the patch process for release branches. Agreed. I have added slight caveats for New Features: develop in trunk patch to current x.y branch (if to be captured in next x.y.z release) Fixes develop in x.y branch (if to be captured in next x.y.z release else develop in trunk) patch to trunk patch to current x.y.z (if it is a TCK bug). This is good discussion. In the interests of seeing it continue while keeping clear what we've voted on and what is still open for discussion, i've split this out into a new wiki page titled with the soft word "guidelines." http://cwiki.apache.org/GMOxPMGT/development-and-patch-guidelines.html Further, i've added a "Notice" section at the bottom of this page that states, "The process in this document was voted on by the Geronimo community. Please formally propose all changes to dev@geronimo.apache.org" http://cwiki.apache.org/GMOxPMGT/release-branching-process.html Makes sense. Thanks David. Regards, Alan
Re: Lets start moving to m2
On Jun 26, 2006, at 11:05 AM, Jacek Laskowski wrote: On 6/26/06, David Jencks <[EMAIL PROTECTED]> wrote: Although there are still some problems (such as not running all the tests) I think we have pretty much all of the build working in m2 except for the assembly stage, due to the lack of an m2 assembly plugin. I'm not sure of the status of such a plugin, but I'd like to suggest that we try to make the build be m2-only except for assembly, and m1 for the assembly step until a suitable plugin exists. Comments? Objections? Worth to try out, but...haven't we been doing it since a couple of months? I don't understand what else we could do. Do you think about something concrete? I think I didn't read your email well. I'm suggesting that we declare the m1 build obsolete and remove it, except possibly for the assembly step and perhaps modules where the tests do not run under m2. thanks david jencks david jencks Jacek -- Jacek Laskowski http://www.laskowski.net.pl
[jira] Closed: (GERONIMO-1864) Deploy no longer starts a web application by default
[ http://issues.apache.org/jira/browse/GERONIMO-1864?page=all ] Joe Bohn closed GERONIMO-1864: -- > Deploy no longer starts a web application by default > > > Key: GERONIMO-1864 > URL: http://issues.apache.org/jira/browse/GERONIMO-1864 > Project: Geronimo > Type: Bug > Security: public(Regular issues) > Components: deployment > Versions: 1.1 > Environment: windows xp > Reporter: Joe Bohn > Attachments: no-geronimo-plan.war > > I deployed a very simple web applicaion from the command line. The > application deployed successfully and no error messages or any sort were > issued (aside from the message the indicated a plan was not provided and a > default plan would be used). When I couldn't access the application I > checked and noticed that it had not been started. Another individual has > also mentioned hitting the same problem so I don't believe it is unique to me. -- 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] Closed: (GERONIMO-1882) Deploy from web console fails with NoSuchOperationException
[ http://issues.apache.org/jira/browse/GERONIMO-1882?page=all ] Joe Bohn closed GERONIMO-1882: -- > Deploy from web console fails with NoSuchOperationException > --- > > Key: GERONIMO-1882 > URL: http://issues.apache.org/jira/browse/GERONIMO-1882 > Project: Geronimo > Type: Bug > Security: public(Regular issues) > Components: console > Versions: 1.1 > Environment: windows xp > Reporter: Joe Bohn > Assignee: Aaron Mulder > Priority: Blocker > Fix For: 1.1 > > Following exception is thrown when attempting to deploy from the web console > portlet: > 09:01:07,467 ERROR [PortletInvokerImpl] PortletInvokerImpl.render() - Error > while dispatching portlet. > javax.portlet.PortletException > at > org.apache.geronimo.console.configmanager.DeploymentPortlet.processAction(DeploymentPortlet.java:139) > at > org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229) > at > org.apache.pluto.core.PortletServlet.doPost(PortletServlet.java:163) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:615) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) > at > org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) > at > org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428) > at > org.apache.geronimo.jetty.JettyServletHolder.handle(JettyServletHolder.java:97) > at > org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:830) > at > org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:170) > at > org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821) > at > org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:471) > at org.mortbay.jetty.servlet.Dispatcher.dispatch(Dispatcher.java:283) > at org.mortbay.jetty.servlet.Dispatcher.include(Dispatcher.java:163) > at > org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120) > at > org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvokerImpl.java:68) > at > org.apache.pluto.PortletContainerImpl.processPortletAction(PortletContainerImpl.java:164) > at > org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.processPortletAction(PortletContainerWrapperImpl.java:82) > at org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:227) > at org.apache.pluto.portalImpl.Servlet.doPost(Servlet.java:267) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:615) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) > at > org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428) > at > org.apache.geronimo.jetty.JettyServletHolder.handle(JettyServletHolder.java:97) > at > org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:830) > at > org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:170) > at > org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821) > at > org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:471) > at > org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:568) > at org.mortbay.http.HttpContext.handle(HttpContext.java:1530) > at > org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:633) > at org.mortbay.http.HttpContext.handle(HttpContext.java:1482) > at org.mortbay.http.HttpServer.service(HttpServer.java:909) > at org.mortbay.http.HttpConnection.service(HttpConnection.java:816) > at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:982) > at org.mortbay.http.HttpConnection.handle(HttpConnection.java:833) > at > org.mortbay.http.SocketListener.handleConnection(SocketListener.java:244) > at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357) > at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534) > Caused by: org.apache.geronimo.kernel.NoSuchOperationException: Unknown > operation deploy(java.io.File, java.io.File) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:836) > at > org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:244) > at > org.apache.geronimo.console.configmanager.DeploymentPortlet.processAction(DeploymentPortlet.java:112) > ... 38 more > Nested Exception is > org.apache.geronimo.kernel.NoSuchOperationException: Unknown operation > deploy(java.io.File, java.io.File) > at > org.apache.geronimo.gbean.ru
[jira] Closed: (GERONIMO-1918) NoClassDefFoundError/ClassNotFoundException when attempting to deploy web app from console GUI
[ http://issues.apache.org/jira/browse/GERONIMO-1918?page=all ] Joe Bohn closed GERONIMO-1918: -- > NoClassDefFoundError/ClassNotFoundException when attempting to deploy web app > from console GUI > -- > > Key: GERONIMO-1918 > URL: http://issues.apache.org/jira/browse/GERONIMO-1918 > Project: Geronimo > Type: Bug > Security: public(Regular issues) > Components: console > Versions: 1.1 > Environment: windows xp - tomcat & jetty servers > Reporter: Joe Bohn > Assignee: Aaron Mulder > Fix For: 1.1 > Attachments: snoop.war > > rev. 397044 > Deploying a war from the web console GUI results in a NoClassDefFoundError > Here is the exception from the server: > 09:57:10,683 ERROR [[Deployment]] Servlet.service() for servlet Deployment > threw exception > java.lang.NoClassDefFoundError > at > org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.class$(AbstractDeployCommand.java:44) > at > org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.getDeployerName(AbstractDeployCommand.java:64) > at > org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.(AbstractDeployCommand.java:60) > at > org.apache.geronimo.deployment.plugin.local.DistributeCommand.(DistributeCommand.java:35) > at > org.apache.geronimo.deployment.plugin.jmx.JMXDeploymentManager.createDistributeCommand(JMXDeploymentManager.java:299) > at > org.apache.geronimo.deployment.plugin.jmx.JMXDeploymentManager.distribute(JMXDeploymentManager.java:173) > at > org.apache.geronimo.console.configmanager.DeploymentPortlet.processAction(DeploymentPortlet.java:122) > at > org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229) > at > org.apache.pluto.core.PortletServlet.doPost(PortletServlet.java:163) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:615) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) > at > org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) > at > org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672) > at > org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:574) > at > org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:499) > at > org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120) > at > org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvokerImpl.java:68) > at > org.apache.pluto.PortletContainerImpl.processPortletAction(PortletContainerImpl.java:164) > at > org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.processPortletAction(PortletContainerWrapperImpl.java:82) > at org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:227) > at org.apache.pluto.portalImpl.Servlet.doPost(Servlet.java:267) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:615) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) > at > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) > at > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) > at > org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:52) > at > org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:482) > at > org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:336) > at > org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:31) > at > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) > at > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) > at > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) > at > org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:526) > at > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) > at > org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856) > at > org.apache.coyote.http11.Http11Protocol$Http11ConnectionHan
[jira] Created: (GSHELL-27) Exec command eats an additional char after finishing
Exec command eats an additional char after finishing
Key: GSHELL-27
URL: http://issues.apache.org/jira/browse/GSHELL-27
Project: GShell (Sandbox)
Type: Bug
Security: public (Regular issues)
Components: Commands
Versions: 0.0.2
Reporter: Jason Dillon
Assigned to: Jason Dillon
Priority: Minor
The exec command seems to be eating an extra char after running something like:
{noformat}
exec find .
{noformat}
For example, after running the above, to exit you need to:
{noformat}
eexit
{noformat}
--
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] Closed: (GSHELL-18) New command: exec
[ http://issues.apache.org/jira/browse/GSHELL-18?page=all ] Jason Dillon closed GSHELL-18: -- Fix Version: 0.0.2 Resolution: Fixed > New command: exec > - > > Key: GSHELL-18 > URL: http://issues.apache.org/jira/browse/GSHELL-18 > Project: GShell (Sandbox) > Type: New Feature > Security: public(Regular issues) > Components: Commands > Reporter: Jason Dillon > Assignee: Jason Dillon > Fix For: 0.0.2 > -- 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: [VOTE] Release branching process (was Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.)
On Jun 25, 2006, at 8:49 PM, Alan D. Cabrera wrote: Greg Wilkins wrote: I think the wiki should clarify the patch process for release branches. Agreed. I have added slight caveats for New Features: develop in trunk patch to current x.y branch (if to be captured in next x.y.z release) Fixes develop in x.y branch (if to be captured in next x.y.z release else develop in trunk) patch to trunk patch to current x.y.z (if it is a TCK bug). This is good discussion. In the interests of seeing it continue while keeping clear what we've voted on and what is still open for discussion, i've split this out into a new wiki page titled with the soft word "guidelines." http://cwiki.apache.org/GMOxPMGT/development-and-patch-guidelines.html Further, i've added a "Notice" section at the bottom of this page that states, "The process in this document was voted on by the Geronimo community. Please formally propose all changes to dev@geronimo.apache.org" http://cwiki.apache.org/GMOxPMGT/release-branching-process.html -David Regards, Alan
Re: Lets start moving to m2
Good :-) Just checking. --jason On Jun 26, 2006, at 11:17 AM, Prasad Kashyap wrote: The trunk Cheers Prasad On 6/26/06, Jason Dillon <[EMAIL PROTECTED]> wrote: What branch is this on? IMO, the sooner we get to m2 the better. --jason On Jun 26, 2006, at 10:09 AM, David Jencks wrote: > Although there are still some problems (such as not running all the > tests) I think we have pretty much all of the build working in m2 > except for the assembly stage, due to the lack of an m2 assembly > plugin. I'm not sure of the status of such a plugin, but I'd like > to suggest that we try to make the build be m2-only except for > assembly, and m1 for the assembly step until a suitable plugin exists. > > Comments? Objections? > > thanks > david jencks >
Re: Lets start moving to m2
The trunk Cheers Prasad On 6/26/06, Jason Dillon <[EMAIL PROTECTED]> wrote: What branch is this on? IMO, the sooner we get to m2 the better. --jason On Jun 26, 2006, at 10:09 AM, David Jencks wrote: > Although there are still some problems (such as not running all the > tests) I think we have pretty much all of the build working in m2 > except for the assembly stage, due to the lack of an m2 assembly > plugin. I'm not sure of the status of such a plugin, but I'd like > to suggest that we try to make the build be m2-only except for > assembly, and m1 for the assembly step until a suitable plugin exists. > > Comments? Objections? > > thanks > david jencks >
Re: geronimo services/plugins tools
On 6/26/06, Dain Sundstrom <[EMAIL PROTECTED]> wrote: Yes, XBean will allow us to use just POJOs. I plan on starting the integration work as soon as I get the merged OpenEJB 2.2 code working in the TCK (hopefully today or tomorrow). Great! I was thinking about XBean while writing the email and am not surprised to have read your response :-) -dain Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: Lets start moving to m2
What branch is this on? IMO, the sooner we get to m2 the better. --jason On Jun 26, 2006, at 10:09 AM, David Jencks wrote: Although there are still some problems (such as not running all the tests) I think we have pretty much all of the build working in m2 except for the assembly stage, due to the lack of an m2 assembly plugin. I'm not sure of the status of such a plugin, but I'd like to suggest that we try to make the build be m2-only except for assembly, and m1 for the assembly step until a suitable plugin exists. Comments? Objections? thanks david jencks
Re: Lets start moving to m2
On 6/26/06, David Jencks <[EMAIL PROTECTED]> wrote: Although there are still some problems (such as not running all the tests) I think we have pretty much all of the build working in m2 except for the assembly stage, due to the lack of an m2 assembly plugin. I'm not sure of the status of such a plugin, but I'd like to suggest that we try to make the build be m2-only except for assembly, and m1 for the assembly step until a suitable plugin exists. Comments? Objections? Worth to try out, but...haven't we been doing it since a couple of months? I don't understand what else we could do. Do you think about something concrete? I think I didn't read your email well. david jencks Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: Lets start moving to m2
I was unable to attach the zip file of the plugin. Here's the patch. Cheers Prasad. On 6/26/06, Prasad Kashyap <[EMAIL PROTECTED]> wrote: Here's the status of the assembly plugin. The geronimo-assembly-plugin is ready and is undergoing tests. It has only 1 goal, i.e., the "installConfig" goal. This goal runs thro' the dependency list in the pom.xml and installs all dependencies of type "car". I have attached a patch of this plugin for those wishing to play with it. The maven-assembly-plugin is what will be used to do the bulk of the assembly. This plugin had to be patched to meet our requirements. Special thanks to Jesse McConnel and John Casey from maven for answering my myriad questions and agreeing to apply the patch to the assembly plugin. The last remaining thing is our (in)ability to execute the maven-assembly-plugin twice. I am trying to get this resolved. Here's the thread for those wishing to follow - http://www.mail-archive.com/dev@maven.apache.org/msg58756.html Cheers Prasad On 6/26/06, David Jencks <[EMAIL PROTECTED]> wrote: > Although there are still some problems (such as not running all the > tests) I think we have pretty much all of the build working in m2 > except for the assembly stage, due to the lack of an m2 assembly > plugin. I'm not sure of the status of such a plugin, but I'd like to > suggest that we try to make the build be m2-only except for assembly, > and m1 for the assembly step until a suitable plugin exists. > > Comments? Objections? > > thanks > david jencks > > geronimo-assembly-plugin.patch Description: Binary data
Re: Lets start moving to m2
Here's the status of the assembly plugin. The geronimo-assembly-plugin is ready and is undergoing tests. It has only 1 goal, i.e., the "installConfig" goal. This goal runs thro' the dependency list in the pom.xml and installs all dependencies of type "car". I have attached a patch of this plugin for those wishing to play with it. The maven-assembly-plugin is what will be used to do the bulk of the assembly. This plugin had to be patched to meet our requirements. Special thanks to Jesse McConnel and John Casey from maven for answering my myriad questions and agreeing to apply the patch to the assembly plugin. The last remaining thing is our (in)ability to execute the maven-assembly-plugin twice. I am trying to get this resolved. Here's the thread for those wishing to follow - http://www.mail-archive.com/dev@maven.apache.org/msg58756.html Cheers Prasad On 6/26/06, David Jencks <[EMAIL PROTECTED]> wrote: Although there are still some problems (such as not running all the tests) I think we have pretty much all of the build working in m2 except for the assembly stage, due to the lack of an m2 assembly plugin. I'm not sure of the status of such a plugin, but I'd like to suggest that we try to make the build be m2-only except for assembly, and m1 for the assembly step until a suitable plugin exists. Comments? Objections? thanks david jencks
Re: Lets start moving to m2
I'm excited about moving to m2 and have just been waiting on the green light. As I recall, Anita offered to contribute some wiki doc on building Geronimo with m2. Is that doc still on its way in or am I overlooking it? Best wishes, Paul On 6/26/06, David Jencks <[EMAIL PROTECTED]> wrote: Although there are still some problems (such as not running all the tests) I think we have pretty much all of the build working in m2 except for the assembly stage, due to the lack of an m2 assembly plugin. I'm not sure of the status of such a plugin, but I'd like to suggest that we try to make the build be m2-only except for assembly, and m1 for the assembly step until a suitable plugin exists. Comments? Objections? thanks david jencks
Re: Lets start moving to m2
David Jencks wrote: Although there are still some problems (such as not running all the tests) I think we have pretty much all of the build working in m2 except for the assembly stage, due to the lack of an m2 assembly plugin. I'm not sure of the status of such a plugin, but I'd like to suggest that we try to make the build be m2-only except for assembly, and m1 for the assembly step until a suitable plugin exists. Comments? Objections? Sounds great. Regards, Alan
Re: m2 builds
What do we need to do to publish these snapshots? Regards, Alan anita kulshreshtha wrote: This is not a requirement. There is a patch to build openejb only when necessary (comment out openejb). Once the 1.2-snapshots (geronimo and openejb) are published somewhere, we will be able to do : svn ... mvn Until then the following steps must be used - mvn -Dall=modules mvn -Dall=plugins Once the plugin is built, just mvn or mvn clean install is sufficient to build everything. Thanks Anita --- Jason Dillon <[EMAIL PROTECTED]> wrote: I agree this is a bad idea. IMO, you should be able to `svn co` (of our sources only), and them `mvn install` to go from nothing to a functional server assembly. Nothing else should be required. --jason On Jun 25, 2006, at 8:24 PM, Alan D. Cabrera wrote: It seems that we must have openejb in our root in order to build. I do not think that this is a good idea. What do others think? Regards, Alan __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Lets start moving to m2
Although there are still some problems (such as not running all the tests) I think we have pretty much all of the build working in m2 except for the assembly stage, due to the lack of an m2 assembly plugin. I'm not sure of the status of such a plugin, but I'd like to suggest that we try to make the build be m2-only except for assembly, and m1 for the assembly step until a suitable plugin exists. Comments? Objections? thanks david jencks
Re: geronimo services/plugins tools
On Jun 24, 2006, at 4:10 PM, Jacek Laskowski wrote: On 6/24/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote: Gbean wizard would be nice that provides a GBean skeleton and plan. That raises a question whether GBean skeleton/plan are required at all? Could that be worked out with annotations (and retrotranslator)? Would XBean help us in any way so just POJOs would work fine? Just thinking out loud. Yes, XBean will allow us to use just POJOs. I plan on starting the integration work as soon as I get the merged OpenEJB 2.2 code working in the TCK (hopefully today or tomorrow). -dain
Re: geronimo services/plugins tools
Thanks for your input Paul..
On Jun 26, 2006, at 10:26 AM, Paul McMahan wrote:
If you haven't already you might want to look at the plugin export
screen in the admin console. A similar screen for collecting the
various user inputs could be provided in an eclipse based wizard.
Yes, definitely. There may be ways around, but as mentioned before
would love for the APIs to be more flexible to work directly with the
eclipse project structure. Will need to discuss this more in-depth
with Aaron.
It would also be nice if a wizard could generate the static block of a
gbean where the GBeanInfoBuilder is created:
Yes, this is what I was thinking and possibly being able to
automatically promote/synchronize attributes/elements you add to your
plan with entries in this static block.
static {
GBeanInfoBuilder infoFactory =
GBeanInfoBuilder.createStatic(MyGBean.class);
GBEAN_INFO = infoFactory.getBeanInfo();
}
public static GBeanInfo getGBeanInfo() {
return GBEAN_INFO;
}
Paul
On 6/24/06, Sachin Patel <[EMAIL PROTECTED]> wrote:
So for next release, I was thinking about working on some
enhancements to the eclipse-plugin to provide some g-plugin/services
creation tools & wizards that could do some basic things like
automatic codegeneration to provide stubbed out classes/methods. Do
people see any value in this? Are there a set of common things that
we could auto generate for users? If so what?
Thanks.
-sachin
-sachin
Re: geronimo services/plugins tools
If you haven't already you might want to look at the plugin export
screen in the admin console. A similar screen for collecting the
various user inputs could be provided in an eclipse based wizard.
It would also be nice if a wizard could generate the static block of a
gbean where the GBeanInfoBuilder is created:
static {
GBeanInfoBuilder infoFactory =
GBeanInfoBuilder.createStatic(MyGBean.class);
GBEAN_INFO = infoFactory.getBeanInfo();
}
public static GBeanInfo getGBeanInfo() {
return GBEAN_INFO;
}
Paul
On 6/24/06, Sachin Patel <[EMAIL PROTECTED]> wrote:
So for next release, I was thinking about working on some
enhancements to the eclipse-plugin to provide some g-plugin/services
creation tools & wizards that could do some basic things like
automatic codegeneration to provide stubbed out classes/methods. Do
people see any value in this? Are there a set of common things that
we could auto generate for users? If so what?
Thanks.
-sachin
[jira] Created: (AMQ-776) ConduitBridge can malfunction when first of a set of consumers goes away
ConduitBridge can malfunction when first of a set of consumers goes away Key: AMQ-776 URL: https://issues.apache.org/activemq/browse/AMQ-776 Project: ActiveMQ Type: Bug Components: Broker Versions: 4.0.1 Reporter: Kevin Yaussy Priority: Critical Attachments: ConduitBridge.patch When the following scenario is followed, any of the subsequent consumers will stop receiving messages. I've reproduced this using the ConsumerTool, and ProducerTool supplied in the example area of the distribution. +++ Start Broker A Start Broker B Start Consumer 1, connecting to Broker B, consuming FOO Start Consumer 2, connecting to Broker B, consuming FOO Start Publisher, connecting to Broker A, publishing FOO Ctl-C out of Consumer 1 Consumer 2 stops receiving messages +++ Seems to me that ConduitBridge is supposed to track all consumers for a given subscription, by way of DemandSubscription. It is seeding DemandSubscription with the originating consumer, but when subsequent consumers are added, the ConduitBridge::addToAlreadyInterestedConsumers re-adds the original subscriber to the DemandSubscription's map - so the map only ever has the original subscription. I've attached a patch. Hope the change is good. -- 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: m2 migration status
These are known problems. comments inline.. --- Prasad Kashyap <[EMAIL PROTECTED]> wrote: > I got myself a fresh clean checkout of trunk and built just the > modules. I encountered the following problems - > > 1. The j2ee module compilation failed due to a dependency on ejb spec > jar. Currently the spec jars used in m2 build do not have an associated pom, this causes the compilation failure. The specs will be available on an m2 repo soon after the release. > > 2. The web-builder modules failed compilation due to a dependency on > servlet spec jar. > > I have attached a patch to resolve 1 & 2 above. If others see the > same > problem too, then we should open a JIRA and apply this patch. > > 3. All builder modules fail the first time on dependency > xmlbeans:xmlbeans-jsr173-api:jar:2.0-dev. The second attempt will > succeed. This requires latest xmlbeans-maven-plugin. I have not checked if it has been published. I am travelling and have only email access till Tuesday afternoon. Thanks Anita > > I thought it's exclusion from the stax:stax-api would take care of > that. Right now, I don't know why it fails. The build is successful > the second time. > > Cheers > Prasad > > On 6/12/06, Prasad Kashyap <[EMAIL PROTECTED]> wrote: > > Please see comments inline - > > > > On 6/11/06, David Jencks <[EMAIL PROTECTED]> wrote: > > > I'm finding it a bit hard to keep track of the m2 migration > status, > > > so I thought I'd try to put it all on one page. > > > > > > > > > http://issues.apache.org/jira/browse/GERONIMO-1737 : assembly > plugin: > > > no patch. I understand our assembly plugin working requires some > bug > > > fixes in maven. > > > > > > > http://jira.codehaus.org/browse/MASSEMBLY-45 is needed to "flatten" > > dir structures during assembly. > > I'll work on this patch. > > > > http://jira.codehaus.org/browse/MASSEMBLY-41 can help us extract > > *-builder-* artifacts for our schemas. > > Jason to look at this. > > > > http://jira.codehaus.org/browse/MWAR-45 is needed to jar up classes > > into web-inf/lib/classes.jar > > Patch submitted and applied. > > > > http://jira.codehaus.org/browse/MASSEMBLY-116 - ability to use a > temp > > dir and discard it (not include it in zip). Ability to unpack > > too. > > > > > > > assemblies: no assembly plugin, none built. > > > > > > > > I think we're getting moderately close to having a working m2 > build. > > > > > > > We currently have our version info hardcoded in all our (150+) > > pom.xml. Maven JIRA http://jira.codehaus.org/browse/MNG-624 should > > help us solve that problem. > > > > > > > thanks > > > david jencks > > > > > > > > > > > > > > > > > > > > > > > > __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: [RTC] m2-plugins deployment plugin: PLEASE VOTE
AFAIK, maven makes sure that it has all the plugins even before sorting the projects. It can not distinguish the fact that a subset of the projects do not need the plugin. Ideally maven should distinguish between a maven plugin and other plugins. If m2 snapshots are published somewhere, it will get an older copy of the plugins and happily continue the build. Thanks Anita --- David Jencks <[EMAIL PROTECTED]> wrote: > > On Jun 25, 2006, at 4:06 AM, Jacek Laskowski wrote: > > > On 6/13/06, David Jencks <[EMAIL PROTECTED]> wrote: > >> Last (and only, depending on how you count) +1 was 4 days ago, any > >> chance 2 more people are willing to review this? > > > > I can't seem to test it out on my laptop with no Geronimo m2 builds > > done before. See > > http://issues.apache.org/jira/browse/GERONIMO-1738#action_12417669 > for > > more information. > > Something is odd, you should be able to build all the modules before > > any plugins. Have you run mvn -N install in geronimo's root > directory? > > I'd expect this to work: > > cd /cygdrive/c/oss/geronimo > mvn -N install > cd modules > mvn clean install > cd ../m2-plugins > mvn clean install > > I haven't tried this myself yet with a fresh repo will try to > find some time for this. > > > > > > Therefore, I can't vote for it. Does it mean I should vote against > it > > in such a case? > > > > I think we should investigate the problems further before voting > further. > > thanks > david jencks > > > >> david jencks > > > > Jacek > > > > -- > > Jacek Laskowski > > http://www.laskowski.net.pl > > __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: m2 builds
This is not a requirement. There is a patch to build openejb only when necessary (comment out openejb). Once the 1.2-snapshots (geronimo and openejb) are published somewhere, we will be able to do : svn ... mvn Until then the following steps must be used - mvn -Dall=modules mvn -Dall=plugins Once the plugin is built, just mvn or mvn clean install is sufficient to build everything. Thanks Anita --- Jason Dillon <[EMAIL PROTECTED]> wrote: > I agree this is a bad idea. > > IMO, you should be able to `svn co` (of our sources only), and them > `mvn install` to go from nothing to a functional server assembly. > Nothing else should be required. > > --jason > > > On Jun 25, 2006, at 8:24 PM, Alan D. Cabrera wrote: > > > It seems that we must have openejb in our root in order to build. > > > I do not think that this is a good idea. What do others think? > > > > > > Regards, > > Alan > > > > > > __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
[jira] Commented: (GERONIMO-2151) geronino should ignore .DS_Store files in the deploy dir
[ http://issues.apache.org/jira/browse/GERONIMO-2151?page=comments#action_12417806 ] Mario Ruebsam commented on GERONIMO-2151: - Geronimo should igrone all files and directories starting with '.' and for some apps and compaibility issues "_" in the deploy dir. Some people like to checkout their apps so ".svn" or ".cvs" directories could also ignored this way. > geronino should ignore .DS_Store files in the deploy dir > > > Key: GERONIMO-2151 > URL: http://issues.apache.org/jira/browse/GERONIMO-2151 > Project: Geronimo > Type: Improvement > Security: public(Regular issues) > Components: Hot Deploy Dir > Versions: 1.1 > Environment: osx > Reporter: Christoph Sturm > Priority: Minor > > osx stores extended file attributes in a dir called .DS_Store. > after copying a war file to the geronimo deploy dir with the finder it > creates the .DS_Store file, and geronimo tries to deploy it: > 14:47:48,065 INFO [Hot Deployer] Deploying .DS_Store > 14:47:48,284 ERROR [Hot Deployer] Unable to deploy: > org.apache.xmlbeans.XmlException: > /Users/christophsturm/Projects/geronimo-1.1/deploy/.DS_Store:1: error: > Illegal XML character: 0x0 > org.apache.xmlbeans.impl.piccolo.io.IllegalCharException: Illegal XML > character: 0x0 > at > org.apache.xmlbeans.impl.piccolo.xml.UTF8XMLDecoder.decode(UTF8XMLDecoder.java:196) > at > org.apache.xmlbeans.impl.piccolo.xml.XMLStreamReader$FastStreamDecoder.read(XMLStreamReader.java:762) > at > org.apache.xmlbeans.impl.piccolo.xml.XMLStreamReader.read(XMLStreamReader.java:162) > at > org.apache.xmlbeans.impl.piccolo.xml.PiccoloLexer.yy_refill(PiccoloLexer.java:3469) > at > org.apache.xmlbeans.impl.piccolo.xml.PiccoloLexer.yylex(PiccoloLexer.java:3953) > at > org.apache.xmlbeans.impl.piccolo.xml.Piccolo.yylex(Piccolo.java:1290) > at > org.apache.xmlbeans.impl.piccolo.xml.Piccolo.yyparse(Piccolo.java:1400) > at > org.apache.xmlbeans.impl.piccolo.xml.Piccolo.parse(Piccolo.java:714) > at > org.apache.xmlbeans.impl.store.Locale$SaxLoader.load(Locale.java:3354) > at > org.apache.xmlbeans.impl.store.Locale.parseToXmlObject(Locale.java:1267) > at > org.apache.xmlbeans.impl.store.Locale.parseToXmlObject(Locale.java:1254) > at > org.apache.xmlbeans.impl.schema.SchemaTypeLoaderBase.parse(SchemaTypeLoaderBase.java:345) > at > org.apache.xmlbeans.impl.schema.SchemaTypeLoaderBase.parse(SchemaTypeLoaderBase.java:309) > at org.apache.xmlbeans.XmlObject$Factory.parse(XmlObject.java:656) > at > org.apache.geronimo.deployment.xmlbeans.XmlBeansUtil.parse(XmlBeansUtil.java:74) > at > org.apache.geronimo.j2ee.deployment.EARConfigBuilder.getEarPlan(EARConfigBuilder.java:326) > at > org.apache.geronimo.j2ee.deployment.EARConfigBuilder.getDeploymentPlan(EARConfigBuilder.java:263) > at > org.apache.geronimo.j2ee.deployment.EARConfigBuilder$$FastClassByCGLIB$$38e56ec6.invoke() > at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) > at > org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) > at > org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:817) > at > org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) > at > org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) > at > org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) > at > org.apache.geronimo.deployment.ConfigurationBuilder$$EnhancerByCGLIB$$f226e5bd.getDeploymentPlan() > at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:232) > at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:124) > at > org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke() > at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) > at > org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) > at > org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:852) > at > org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) > at > org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.doDeploy(AbstractDeployCommand.java:106) > at > org.apache.geronimo.deployment.plugin.local.DistributeCommand.run(DistributeCommand.java:60) > at java.lang.Thread.run(Thread.java:613) > I think it would be best if the auto deployer would just ignore all fil
[jira] Updated: (GERONIMO-2151) geronino should ignore .DS_Store files in the deploy dir
[ http://issues.apache.org/jira/browse/GERONIMO-2151?page=all ] Christoph Sturm updated GERONIMO-2151: -- type: Improvement (was: Bug) oops, i created this a bug instead of improvement by mistake. sorry :) > geronino should ignore .DS_Store files in the deploy dir > > > Key: GERONIMO-2151 > URL: http://issues.apache.org/jira/browse/GERONIMO-2151 > Project: Geronimo > Type: Improvement > Security: public(Regular issues) > Components: Hot Deploy Dir > Versions: 1.1 > Environment: osx > Reporter: Christoph Sturm > Priority: Minor > > osx stores extended file attributes in a dir called .DS_Store. > after copying a war file to the geronimo deploy dir with the finder it > creates the .DS_Store file, and geronimo tries to deploy it: > 14:47:48,065 INFO [Hot Deployer] Deploying .DS_Store > 14:47:48,284 ERROR [Hot Deployer] Unable to deploy: > org.apache.xmlbeans.XmlException: > /Users/christophsturm/Projects/geronimo-1.1/deploy/.DS_Store:1: error: > Illegal XML character: 0x0 > org.apache.xmlbeans.impl.piccolo.io.IllegalCharException: Illegal XML > character: 0x0 > at > org.apache.xmlbeans.impl.piccolo.xml.UTF8XMLDecoder.decode(UTF8XMLDecoder.java:196) > at > org.apache.xmlbeans.impl.piccolo.xml.XMLStreamReader$FastStreamDecoder.read(XMLStreamReader.java:762) > at > org.apache.xmlbeans.impl.piccolo.xml.XMLStreamReader.read(XMLStreamReader.java:162) > at > org.apache.xmlbeans.impl.piccolo.xml.PiccoloLexer.yy_refill(PiccoloLexer.java:3469) > at > org.apache.xmlbeans.impl.piccolo.xml.PiccoloLexer.yylex(PiccoloLexer.java:3953) > at > org.apache.xmlbeans.impl.piccolo.xml.Piccolo.yylex(Piccolo.java:1290) > at > org.apache.xmlbeans.impl.piccolo.xml.Piccolo.yyparse(Piccolo.java:1400) > at > org.apache.xmlbeans.impl.piccolo.xml.Piccolo.parse(Piccolo.java:714) > at > org.apache.xmlbeans.impl.store.Locale$SaxLoader.load(Locale.java:3354) > at > org.apache.xmlbeans.impl.store.Locale.parseToXmlObject(Locale.java:1267) > at > org.apache.xmlbeans.impl.store.Locale.parseToXmlObject(Locale.java:1254) > at > org.apache.xmlbeans.impl.schema.SchemaTypeLoaderBase.parse(SchemaTypeLoaderBase.java:345) > at > org.apache.xmlbeans.impl.schema.SchemaTypeLoaderBase.parse(SchemaTypeLoaderBase.java:309) > at org.apache.xmlbeans.XmlObject$Factory.parse(XmlObject.java:656) > at > org.apache.geronimo.deployment.xmlbeans.XmlBeansUtil.parse(XmlBeansUtil.java:74) > at > org.apache.geronimo.j2ee.deployment.EARConfigBuilder.getEarPlan(EARConfigBuilder.java:326) > at > org.apache.geronimo.j2ee.deployment.EARConfigBuilder.getDeploymentPlan(EARConfigBuilder.java:263) > at > org.apache.geronimo.j2ee.deployment.EARConfigBuilder$$FastClassByCGLIB$$38e56ec6.invoke() > at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) > at > org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) > at > org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:817) > at > org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) > at > org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) > at > org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) > at > org.apache.geronimo.deployment.ConfigurationBuilder$$EnhancerByCGLIB$$f226e5bd.getDeploymentPlan() > at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:232) > at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:124) > at > org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke() > at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) > at > org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) > at > org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:852) > at > org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) > at > org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.doDeploy(AbstractDeployCommand.java:106) > at > org.apache.geronimo.deployment.plugin.local.DistributeCommand.run(DistributeCommand.java:60) > at java.lang.Thread.run(Thread.java:613) > I think it would be best if the auto deployer would just ignore all files > starting with a dot. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators:
[jira] Created: (GERONIMO-2151) geronino should ignore .DS_Store files in the deploy dir
geronino should ignore .DS_Store files in the deploy dir Key: GERONIMO-2151 URL: http://issues.apache.org/jira/browse/GERONIMO-2151 Project: Geronimo Type: Bug Security: public (Regular issues) Components: Hot Deploy Dir Versions: 1.1 Environment: osx Reporter: Christoph Sturm Priority: Minor osx stores extended file attributes in a dir called .DS_Store. after copying a war file to the geronimo deploy dir with the finder it creates the .DS_Store file, and geronimo tries to deploy it: 14:47:48,065 INFO [Hot Deployer] Deploying .DS_Store 14:47:48,284 ERROR [Hot Deployer] Unable to deploy: org.apache.xmlbeans.XmlException: /Users/christophsturm/Projects/geronimo-1.1/deploy/.DS_Store:1: error: Illegal XML character: 0x0 org.apache.xmlbeans.impl.piccolo.io.IllegalCharException: Illegal XML character: 0x0 at org.apache.xmlbeans.impl.piccolo.xml.UTF8XMLDecoder.decode(UTF8XMLDecoder.java:196) at org.apache.xmlbeans.impl.piccolo.xml.XMLStreamReader$FastStreamDecoder.read(XMLStreamReader.java:762) at org.apache.xmlbeans.impl.piccolo.xml.XMLStreamReader.read(XMLStreamReader.java:162) at org.apache.xmlbeans.impl.piccolo.xml.PiccoloLexer.yy_refill(PiccoloLexer.java:3469) at org.apache.xmlbeans.impl.piccolo.xml.PiccoloLexer.yylex(PiccoloLexer.java:3953) at org.apache.xmlbeans.impl.piccolo.xml.Piccolo.yylex(Piccolo.java:1290) at org.apache.xmlbeans.impl.piccolo.xml.Piccolo.yyparse(Piccolo.java:1400) at org.apache.xmlbeans.impl.piccolo.xml.Piccolo.parse(Piccolo.java:714) at org.apache.xmlbeans.impl.store.Locale$SaxLoader.load(Locale.java:3354) at org.apache.xmlbeans.impl.store.Locale.parseToXmlObject(Locale.java:1267) at org.apache.xmlbeans.impl.store.Locale.parseToXmlObject(Locale.java:1254) at org.apache.xmlbeans.impl.schema.SchemaTypeLoaderBase.parse(SchemaTypeLoaderBase.java:345) at org.apache.xmlbeans.impl.schema.SchemaTypeLoaderBase.parse(SchemaTypeLoaderBase.java:309) at org.apache.xmlbeans.XmlObject$Factory.parse(XmlObject.java:656) at org.apache.geronimo.deployment.xmlbeans.XmlBeansUtil.parse(XmlBeansUtil.java:74) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.getEarPlan(EARConfigBuilder.java:326) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.getDeploymentPlan(EARConfigBuilder.java:263) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder$$FastClassByCGLIB$$38e56ec6.invoke() at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:817) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.deployment.ConfigurationBuilder$$EnhancerByCGLIB$$f226e5bd.getDeploymentPlan() at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:232) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:124) at org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke() at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:852) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) at org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.doDeploy(AbstractDeployCommand.java:106) at org.apache.geronimo.deployment.plugin.local.DistributeCommand.run(DistributeCommand.java:60) at java.lang.Thread.run(Thread.java:613) I think it would be best if the auto deployer would just ignore all files starting with a dot. -- 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: (GERONIMO-2150) error when restarting geronimo after deploying xfire spring example
error when restarting geronimo after deploying xfire spring example --- Key: GERONIMO-2150 URL: http://issues.apache.org/jira/browse/GERONIMO-2150 Project: Geronimo Type: Bug Security: public (Regular issues) Versions: 1.1 Environment: Java 1.5.0_06 osx Reporter: Christoph Sturm AG acts weird if I restart it after deploying the xfire-spring example: I think it has to do with the artifactId it autogenerates if there is no geronimo-web.xml (i dont think it has anything to do with the xfire spring example, just with its filename and that it doenst have a geronimo-web.xml) to reproduce: start a fresh unpacked geronimo 1.1 after its started cp xfire-spring-example-1.2-SNAPSHOT.war /deploy geronimo deploys the war: 13:51:36,831 INFO [Hot Deployer] Deploying xfire-spring-example-1.2-SNAPSHOT.war 13:51:37,863 WARN [JettyModuleBuilder] Web application . does not contain a WEB-INF/geronimo-web.xml deployment plan. This may or may not be a problem, depending on whether you have things like resource references that need to be resolved. You can also give the deployer a separate deployment plan file on the command line. 2006-06-26 13:51:39,094 INFO [org.springframework.web.context.ContextLoader] - Root WebApplicationContext: initialization started 2006-06-26 13:51:39,149 INFO [org.springframework.beans.factory.xml.XmlBeanDefinitionReader] - Loading XML bean definitions from ServletContext resource [/WEB-INF/applicationContext.xml] 2006-06-26 13:51:39,223 INFO [org.springframework.beans.factory.xml.XmlBeanDefinitionReader] - Loading XML bean definitions from class path resource [org/codehaus/xfire/spring/xfire.xml] 2006-06-26 13:51:39,247 INFO [org.springframework.beans.factory.xml.XmlBeanDefinitionReader] - Loading XML bean definitions from class path resource [org/codehaus/xfire/spring/customEditors.xml] 2006-06-26 13:51:39,272 INFO [org.springframework.core.CollectionFactory] - JDK 1.4+ collections available 2006-06-26 13:51:39,429 INFO [org.springframework.web.context.support.XmlWebApplicationContext] - Bean factory for application context [Root WebApplicationContext]: org.springframework.beans.factory.support.DefaultListableBeanFactory defining beans [echoBean,customEditorConfigurer,xfire.serviceRegistry,xfire.transportManager,xfire,xfire.typeMappingRegistry,xfire.aegisBindingProvider,xfire.serviceFactory,xfire.servletController,xfire.messageServiceFactory,xfire.messageBindingProvider]; root of BeanFactory hierarchy 2006-06-26 13:51:39,435 INFO [org.springframework.web.context.support.XmlWebApplicationContext] - 11 beans defined in application context [Root WebApplicationContext] 2006-06-26 13:51:39,665 INFO [org.springframework.web.context.support.XmlWebApplicationContext] - Unable to locate MessageSource with name 'messageSource': using default [EMAIL PROTECTED] 2006-06-26 13:51:39,667 INFO [org.springframework.web.context.support.XmlWebApplicationContext] - Unable to locate ApplicationEventMulticaster with name 'applicationEventMulticaster': using default [EMAIL PROTECTED] 2006-06-26 13:51:39,670 INFO [org.springframework.ui.context.support.UiApplicationContextUtils] - Unable to locate ThemeSource with name 'themeSource': using default [EMAIL PROTECTED] 2006-06-26 13:51:39,671 INFO [org.springframework.beans.factory.support.DefaultListableBeanFactory] - Pre-instantiating singletons in factory [org.springframework.beans.factory.support.DefaultListableBeanFactory defining beans [echoBean,customEditorConfigurer,xfire.serviceRegistry,xfire.transportManager,xfire,xfire.typeMappingRegistry,xfire.aegisBindingProvider,xfire.serviceFactory,xfire.servletController,xfire.messageServiceFactory,xfire.messageBindingProvider]; root of BeanFactory hierarchy] 2006-06-26 13:51:39,866 INFO [org.springframework.web.context.ContextLoader] - Using context class [org.springframework.web.context.support.XmlWebApplicationContext] for root WebApplicationContext 2006-06-26 13:51:39,866 INFO [org.springframework.web.context.ContextLoader] - Root WebApplicationContext: initialization completed in 772 ms Deployed default/xfire-spring-example-1.2-SNAPSHOT/1151322697067/war @ http://globalmobil:8080/xfire-spring-example-1.2-SNAPSHOT press ctrl-c start geronimo again after the restart this error is logged: 2006-06-26 13:52:32,059 ERROR [org.apache.geronimo.deployment.hot.DirectoryMonitor] - Unable to scan file /Users/christophsturm/Projects/geronimo-1.1/deploy/xfire-spring-example-1.2-SNAPSHOT.war during initialization java.lang.IllegalArgumentException: Invalid id: xfire-spring-example-1.2-SNAPSHOT at org.apache.geronimo.kernel.repository.Artifact.create(Artifact.java:49) at org.apache.geronimo.deployment.hot.DirectoryHotDeployer.getDeploymentTime(DirectoryHotDeployer.java:215) at org.apache.geronimo.deployment.hot.DirectoryMonitor.initial
Unassigned Patches: week of 06-26-2006
Project: Apache Geronimo Status: Open Assignee: Unassigned Geronimo Info: Patch Available Total: 25 items DATE UPDATED KEY SUMMARY Dec 18 2005 - GERONIMO-1381 - [Daytrader] Removed unused code Dec 22 2005 - GERONIMO-1400 - modularize daytrader deployment plan Jan 3 2006 - GERONIMO-1413 - Console needs to set JSP and Servlet contentType to UTF-8 Jan 8 2006 - GERONIMO-1260 - simplify construction of the combined deployment plan: deployment plan template and preprocessor Jan 9 2006 - GERONIMO-1163 - improve jmx debug console Jan 19 2006 - GERONIMO-1499 - Daytrader: uncomment the drop table statements in daytrader.sql Jan 19 2006 - GERONIMO-1501 - Daytrader: remove hardcoded dependency versions in project.xml Jan 23 2006 - GERONIMO-1534 - Daytrader: ejb-ql-compiler-factory element is wrong for DB2 or Oracle db Jan 27 2006 - GERONIMO-1341 - POP3 Implementation Feb 21 2006 - GERONIMO-1396 - Provide consistent look and feel for table views in the web console across all portlets Feb 23 2006 - GERONIMO-1648 - Eliminate unnecessary config parent (import) dependencies Feb 25 2006 - GERONIMO-1652 - EJBModuleImpl.getEJBs() always return an empty array Mar 6 2006 - GERONIMO-1700 - Web Console prints a stack trace when attempting to deploy an application that is already deployed. Mar 6 2006 - GERONIMO-1701 - Improve the EJB Server portlet Mar 7 2006 - GERONIMO-1657 - CommandSupport doesn't bubble up the exception. Prints stacktrace. Mar 16 2006 - GERONIMO-1130 - Implement WebServer Manager (statistics gathering/reporting) management interface Mar 21 2006 - GERONIMO-1757 - rarRelativePath is not set correctly cause showplan.jsp displayswrong instruction Apr 6 2006 - GERONIMO-1783 - Welcome application i18n Apr 10 2006 - GERONIMO-1804 - The name of JNDI/RMI service provider is hardcoded in the sources. Apr 11 2006 - GERONIMO-1826 - Naming tests might not work on non-Sun VMs. Apr 12 2006 - GERONIMO-1833 - Non-public Sun classes dependencies in tests Apr 13 2006 - GERONIMO-1840 - NamingPropertiesTest is not compatible with non-Sun VMs. Apr 26 2006 - GERONIMO-1911 - HTTPS algorithm=Default is not preserved after the server is started May 3 2006 - GERONIMO-1976 - Change Welcome Application for G1.1 May 10 2006 - GERONIMO-1518 - Installer - only copy jars needed by selected configuration
[jira] Commented: (GERONIMO-2147) Remove javamail-transport from Geronimo build and replace with javamail-provider dependency.
[ http://issues.apache.org/jira/browse/GERONIMO-2147?page=comments#action_12417756 ] Rick McGuire commented on GERONIMO-2147: svn diff doesn't seem to handle file/directory deletion particularly well. The net of all of the Reversed patches is supposed to be the deletion of the javamail-transport module. You'll need to ensure that directory is deleted before doing the build. My apologies, I meant to add that bit of information when I added the patch, but I got distracted when I was in the process. > Remove javamail-transport from Geronimo build and replace with > javamail-provider dependency. > > > Key: GERONIMO-2147 > URL: http://issues.apache.org/jira/browse/GERONIMO-2147 > Project: Geronimo > Type: Improvement > Security: public(Regular issues) > Components: mail > Versions: 1.2 > Reporter: Rick McGuire > Assignee: Rick McGuire > Fix For: 1.2 > Attachments: notrans.diff > > Now that the javamail-provider repository and build is available, it's time > to replace the javamail-transport module in the Geronimo code tree with a > dependency on the javamail_provider_1.3.1 jar file. -- 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] Removal of the javamail-transport code.
Alan D. Cabrera wrote: Rick McGuire wrote: Ok, on to the next phase of the javamail reorganization. This patch http://issues.apache.org/jira/browse/GERONIMO-2147 is to remove the javamail-transport module and replace it with references to the javamail-providers-1.3.1 jar file. Rick +1 BTW, do you think that this code is ready for the Apache James people to start using? I noticed that they have sun specific classes in their server. I just did a quick scan of the code, and the only javamail sun class I see used is com.sun.mail.handlers.message_rfc822, which the G. version has an equivalent. The javamail api should be robust enough to use (bugs not with standing, of course). Rick Regards, Alan
[jira] Commented: (GERONIMO-2148) Add javamail 1.4 to geronimo specs.
[ http://issues.apache.org/jira/browse/GERONIMO-2148?page=comments#action_12417752 ] Rick McGuire commented on GERONIMO-2148: Here's the original discussion thread where these changes were debated: http://www.mail-archive.com/dev@geronimo.apache.org/msg23693.html Javamail 1.4 is going to be needed to pass the tck for j2ee 5, eventually. Additionally, we're already getting questions on the user list about using javamail 1.4 under Geronimo. The only option currently is using the Sun implementation. > Add javamail 1.4 to geronimo specs. > --- > > Key: GERONIMO-2148 > URL: http://issues.apache.org/jira/browse/GERONIMO-2148 > Project: Geronimo > Type: New Feature > Security: public(Regular issues) > Components: mail > Versions: 1.2 > Reporter: Rick McGuire > Assignee: Rick McGuire > Fix For: 1.2 > Attachments: 1.4.diff, javamail-1.4.diff > > Create a 1.4 version of the javamail API in the specs component. -- 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] m2-plugins deployment plugin: PLEASE VOTE
On 6/26/06, Aaron Mulder <[EMAIL PROTECTED]> wrote: I think if you try again the stax and jsr173 problems will not happen. It's only after the first clean build in an XMLBeans directory that they happen. Unfortunately, that may mean they happen on like 10 different modules. Apparently this is due to errors in the XMLBeans plugin or POM and David J had an idea of how to patch things locally to make this go away. Thanks Aaron, but it didn't help, either. I tried building j2ee-schema a couple of times and all finished with the exception: Missing: -- 1) xmlbeans:xmlbeans-jsr173-api:jar:2.0-dev You're right about XMLBeans issue with its pom which I remember I read on maven-dev mailing list. I think it might be that others use not-that-recent xmlbeans from maven2 repo and unless they run with -U option set they won't experience it. Aaron Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Pushing the 1.1 jars out to the mirror system today
I got a bit distracted over the weekend. I'll be pushing the release out to the mirror system today and get the rest of the release work done. I'll plan to update the website tomorrow after the mirrors have had a chance to catch up. Cheers, Matt
Re: [RTC] m2-plugins deployment plugin: PLEASE VOTE
I think if you try again the stax and jsr173 problems will not happen. It's only after the first clean build in an XMLBeans directory that they happen. Unfortunately, that may mean they happen on like 10 different modules. Apparently this is due to errors in the XMLBeans plugin or POM and David J had an idea of how to patch things locally to make this go away. Thanks, Aaron On 6/26/06, Jacek Laskowski <[EMAIL PROTECTED]> wrote: On 6/26/06, Prasad Kashyap <[EMAIL PROTECTED]> wrote: > Yes modules should first be built > > The execeptions are caused by missing deps in the modules. Nothing to > do with the deployment plugin. Almost there. I was misled by the exception wrt xmlbeans and didn't apply the patch for the missing deps. Anyway, once done the build failed with the following error: Downloading: http://dist.codehaus.org/xmlbeans/poms/xmlbeans-jsr173-api-2.0-dev.pom [WARNING] Unable to get resource from repository codehaus-dist (http://dist.codehaus.org) Downloading: http://people.apache.org/maven-snapshot-repository/xmlbeans/xmlbeans-jsr173-api/2.0-dev/xmlbeans-jsr173-api-2.0-dev.pom [WARNING] Unable to get resource from repository Apache CVS (http://people.apache.org/maven-snapshot-repository) Downloading: http://www.ibiblio.org/maven/xmlbeans/poms/xmlbeans-jsr173-api-2.0-dev.pom [WARNING] Unable to get resource from repository maven1-ibiblio (http://www.ibiblio.org/maven) Downloading: http://www.ibiblio.org/maven2/xmlbeans/xmlbeans-jsr173-api/2.0-dev/xmlbeans-jsr173-api-2.0-dev.pom [WARNING] Unable to get resource from repository central (http://repo1.maven.org/maven2) Downloading: http://cvs.apache.org/repository/xmlbeans/poms/xmlbeans-jsr173-api-2.0-dev.pom [WARNING] Unable to get resource from repository apache-cvs (http://cvs.apache.org/repository) Downloading: http://dist.codehaus.org/xmlbeans/jars/xmlbeans-jsr173-api-2.0-dev.jar [WARNING] Unable to get resource from repository codehaus-dist (http://dist.codehaus.org) Downloading: http://people.apache.org/maven-snapshot-repository/xmlbeans/xmlbeans-jsr173-api/2.0-dev/xmlbeans-jsr173-api-2.0-dev.jar [WARNING] Unable to get resource from repository Apache CVS (http://people.apache.org/maven-snapshot-repository) Downloading: http://www.ibiblio.org/maven/xmlbeans/jars/xmlbeans-jsr173-api-2.0-dev.jar [WARNING] Unable to get resource from repository maven1-ibiblio (http://www.ibiblio.org/maven) Downloading: http://cvs.apache.org/repository/xmlbeans/jars/xmlbeans-jsr173-api-2.0-dev.jar [WARNING] Unable to get resource from repository apache-cvs (http://cvs.apache.org/repository) Downloading: http://www.ibiblio.org/maven2/xmlbeans/xmlbeans-jsr173-api/2.0-dev/xmlbeans-jsr173-api-2.0-dev.jar [WARNING] Unable to get resource from repository central (http://repo1.maven.org/maven2) [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Missing: -- 1) xmlbeans:xmlbeans-jsr173-api:jar:2.0-dev Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=xmlbeans -DartifactId=xmlbeans-jsr173-api \ -Dversion=2.0-dev -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.geronimo.modules:geronimo-j2ee-schema:jar:1.2-SNAPSHOT 2) stax:stax:jar:1.1.1-dev 3) xmlbeans:xmlbeans-jsr173-api:jar:2.0-dev -- 1 required artifact is missing. for artifact: org.apache.geronimo.modules:geronimo-j2ee-schema:jar:1.2-SNAPSHOT > Prasad Jacek -- Jacek Laskowski http://www.laskowski.net.pl
