[jira] Updated: (GERONIMO-4346) c-m-p leaves invalid plugin in plugin catalog and doesn't update plugin catalog when desp is updated
[ https://issues.apache.org/jira/browse/GERONIMO-4346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lin Sun updated GERONIMO-4346: -- Summary: c-m-p leaves invalid plugin in plugin catalog and doesn't update plugin catalog when desp is updated (was: c-m-p doesn't update plugin catalog when desp is added/updated to a plugin's pom.xml file) > c-m-p leaves invalid plugin in plugin catalog and doesn't update plugin > catalog when desp is updated > > > Key: GERONIMO-4346 > URL: https://issues.apache.org/jira/browse/GERONIMO-4346 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: car-maven-plugin >Affects Versions: 2.2 >Reporter: Lin Sun >Assignee: Lin Sun >Priority: Minor > > when I made changes (http://svn.apache.org/viewvc?rev=703224&view=rev) and > build locally at trunk/plugins/console, I found out the local m2's > geronimo-plugins.xml isn't updated with the new description I added. This is > likely a c-m-p issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4346) c-m-p doesn't update plugin catalog when desp is added/updated to a plugin's pom.xml file
[ https://issues.apache.org/jira/browse/GERONIMO-4346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12638469#action_12638469 ] Lin Sun commented on GERONIMO-4346: --- There are two probs here - 1. when some information of plugin is changed (such as license, category, name, url, etc.), we keep the plugin in the plugin catalog but remove the associated pluginArtifact and add the new plugin into the catalog. This would result invalid plugin in the catalog, as pluginArtifact is required. 2. when description of a plugin is updated, we treat the old plugin and new plugin key unchanged, thus we would only update the pluginartifact. > c-m-p doesn't update plugin catalog when desp is added/updated to a plugin's > pom.xml file > - > > Key: GERONIMO-4346 > URL: https://issues.apache.org/jira/browse/GERONIMO-4346 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: car-maven-plugin >Affects Versions: 2.2 >Reporter: Lin Sun >Assignee: Lin Sun >Priority: Minor > > when I made changes (http://svn.apache.org/viewvc?rev=703224&view=rev) and > build locally at trunk/plugins/console, I found out the local m2's > geronimo-plugins.xml isn't updated with the new description I added. This is > likely a c-m-p issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r700238 [1/4] - in /geronimo/sandbox/failover: ./ grinder-3.0.1/ grinder-3.0.1/bin/ grinder-3.0.1/contrib/ grinder-3.0.1/contrib/mq/ grinder-3.0.1/etc/ grinder-3.0.1/examples/ grinder-
On Sep 29, 2008, at 4:19 PM, [EMAIL PROTECTED] wrote: Author: dblevins Date: Mon Sep 29 13:19:05 2008 New Revision: 700238 URL: http://svn.apache.org/viewvc?rev=700238&view=rev Log: First ref of the failover sample Added: geronimo/sandbox/failover/README.txt geronimo/sandbox/failover/cycleservers.sh (with props) geronimo/sandbox/failover/deploy.sh (with props) geronimo/sandbox/failover/grinder-3.0.1/ geronimo/sandbox/failover/grinder-3.0.1/AUTHORS geronimo/sandbox/failover/grinder-3.0.1/CHANGES geronimo/sandbox/failover/grinder-3.0.1/LICENSE geronimo/sandbox/failover/grinder-3.0.1/LICENSE-HTTPClient geronimo/sandbox/failover/grinder-3.0.1/LICENSE-Jython geronimo/sandbox/failover/grinder-3.0.1/LICENSE-PicoContainer geronimo/sandbox/failover/grinder-3.0.1/LICENSE-jEditSyntax David Blevins, Unfortunately, looks like Grinder contains HTTPCLIENT which is LGPL licensed. So, Growler is not something we can maintain in svn. Seems like we can document how to download and install growler for use by the demo. This demo is great! --kevan
Re: Grails, JRuby on Rails, etc... scripting languages/environments and Geronimo integration
Joe Bohn wrote: Any ideas on PHP and if this would be another potential area for integration? Python Joe Bill
Grails, JRuby on Rails, etc... scripting languages/environments and Geronimo integration
I think it was Kevan that originally proposed we might consider integrating some of these scripting languages/environments in with Geronimo ... possibly for Geronimo 2.2. I've started to look into a few of these technologies with an eye toward integration in Geronimo. I'm not coming into this with any first hand experience in these technologies (beyond what I've read and experimented with thus far) ... so any informed opinions are certainly welcome. So far, this is my initial take on these technologies and the feasibility of integration with Geronimo: Grails framework - This is a self contained framework that leverages groovy for scripting. It uses a rails like code by convention approach to generate and host web applications. It is licensed under Apache. It embeds Jetty for hosting the generated web applications but can also export WAR files which can be then deployed application servers like Geronimo. There is an article that gives a nice description on how to utilize Grails to generate a web app and deploy it into Geronimo (http://www.ibm.com/developerworks/opensource/library/os-ag-grails/). As far as integration with Geronimo goes, I'm not sure that there is much to we can do. I guess we could document this in our wiki or perhaps generate a plugin (or whatever the Grails term is) so that the geronimo deployment plan can be generated rather than created manually, but I'm not sure that is worth the effort. There doesn't seem to be a good place for programmatic integration with regard to the framework itself. JRuby on Rails - My understanding is that this is basically a Ruby implementation that runs on the Java VM (the JRuby portion) and leverages the Rails framework. It is licensed under CPL/GPL/LGPL. In many ways it is similar to Grails using an embedded web server to facilitate a rapid application development environment ... this time built upon the JRuby language interpreter. Here again, I suspect we can provide some directions so that an exported war could be deployed in Geronimo (or perhaps a plugin to generate geronimo deployment plans) but there doesn't seem to be much in the way of direct integration that we can provide. There are other frameworks as well. Trails is one that I stumbled on which is also in the same vein as Grails with a focus on definition of the domain model and generating the rest of the app dynamically. However, this has me thinking that perhaps I should focus more on the language interpreters and integrating those (JRuby, Groovy, etc...) rather than the frameworks. Thoughts? Any ideas on PHP and if this would be another potential area for integration? Joe
[jira] Assigned: (GERONIMO-4346) c-m-p doesn't update plugin catalog when desp is added/updated to a plugin's pom.xml file
[ https://issues.apache.org/jira/browse/GERONIMO-4346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lin Sun reassigned GERONIMO-4346: - Assignee: Lin Sun > c-m-p doesn't update plugin catalog when desp is added/updated to a plugin's > pom.xml file > - > > Key: GERONIMO-4346 > URL: https://issues.apache.org/jira/browse/GERONIMO-4346 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: car-maven-plugin >Affects Versions: 2.2 >Reporter: Lin Sun >Assignee: Lin Sun >Priority: Minor > > when I made changes (http://svn.apache.org/viewvc?rev=703224&view=rev) and > build locally at trunk/plugins/console, I found out the local m2's > geronimo-plugins.xml isn't updated with the new description I added. This is > likely a c-m-p issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4346) c-m-p doesn't update plugin catalog when desp is added/updated to a plugin's pom.xml file
c-m-p doesn't update plugin catalog when desp is added/updated to a plugin's pom.xml file - Key: GERONIMO-4346 URL: https://issues.apache.org/jira/browse/GERONIMO-4346 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: car-maven-plugin Affects Versions: 2.2 Reporter: Lin Sun Priority: Minor when I made changes (http://svn.apache.org/viewvc?rev=703224&view=rev) and build locally at trunk/plugins/console, I found out the local m2's geronimo-plugins.xml isn't updated with the new description I added. This is likely a c-m-p issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Java EE 6 Spec Info
Already started putting together a page in the GMOxPMGT space - http://cwiki.apache.org/confluence/display/GMOxPMGT/Java+EE+6+Releases -Donald Kevan Miller wrote: All, FYI, here's an update on information on the expected Java EE 6 schedule -- http://weblogs.java.net/blog/robc/archive/2008/10/update_on_the_s.html As this information is published, I'm assuming that we'll be starting to build up our EE 6 road map/report card to help with planning our Java EE 6 support. --kevan
[jira] Resolved: (GERONIMO-4328) change boilerplate geronimo plugin to use car format (instead of current jar format)
[ https://issues.apache.org/jira/browse/GERONIMO-4328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor resolved GERONIMO-4328. --- Resolution: Fixed Committed a fix for the "Maven2Repository must have a root that's a valid readable directory" problem to the geronimo-maven-plugin: revision 703199 > change boilerplate geronimo plugin to use car format (instead of current jar > format) > > > Key: GERONIMO-4328 > URL: https://issues.apache.org/jira/browse/GERONIMO-4328 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) >Affects Versions: 2.2 >Reporter: Lin Sun >Assignee: Jarek Gawor >Priority: Minor > Fix For: 2.2 > > > This has been discussed on dev list here - > http://www.nabble.com/boilerplate,-jaxws-tools-(convert-from-jar-to-car-format-)-td19727867s134.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Continuous TCK Testing
Yup, it was manually installed on each machine ;-) --jason On Oct 9, 2008, at 6:43 PM, Jason Warner wrote: My apologies. I didn't phrase my question properly. Most of the software necessary was pulled down via svn, but I saw no such behaviour for AHP. After looking at it some more, I imagine the software was just manually installed on the machine. It was kind of a silly question to begin with, I suppose. On Thu, Oct 9, 2008 at 4:16 AM, Jason Dillon <[EMAIL PROTECTED]> wrote: On Oct 8, 2008, at 11:05 PM, Jason Warner wrote: Here's a quick question. Where does AHP come from? http://www.anthillpro.com (ever heard of google :-P) --jason On Mon, Oct 6, 2008 at 1:18 PM, Jason Dillon <[EMAIL PROTECTED]> wrote: Sure np, took me a while to get around to writing it too ;-) --jason On Oct 6, 2008, at 10:24 PM, Jason Warner wrote: Just got around to reading this. Thanks for the brain dump, Jason. No questions as of yet, but I'm sure I'll need a few more reads before I understand it all. On Thu, Oct 2, 2008 at 2:34 PM, Jason Dillon <[EMAIL PROTECTED]> wrote: On Oct 1, 2008, at 11:20 PM, Jason Warner wrote: Is the GBuild stuff in svn the same as the anthill-based code or is that something different? GBuild seems to have scripts for running tck and that leads me to think they're the same thing, but I see no mention of anthill in the code. The Anthill stuff is completely different than the GBuild stuff. I started out trying to get the TCK automated using GBuild, but decided that the system lacked too many features to perform as I desired, and went ahead with Anthill as it did pretty much everything, though had some stability problems. One of the main reasons why I choose Anthill (AHP, Anthill Pro that is) was its build agent and code repository systems. This allowed me to ensure that each build used exactly the desired artifacts. Another was the configurable workflow, which allowed me to create a custom chain of events to handle running builds on remote agents and control what data gets set to them, what it will collect and what logic to execute once all distributed work has been completed for a particular build. And the kicker which help facilitate bringing it all together was its concept of a build life. At the time I could find *no other* build tool which could meet all of these needs, and so I went with AHP instead of spending months building/testing features in GBuild. While AHP supports configuring a lot of stuff via its web- interface, I found that it was very cumbersome, so I opted to write some glue, which was stored in svn here: https://svn.apache.org/viewvc/geronimo/sandbox/build-support/?pathrev=632245 Its been a while, so I have to refresh my memory on how this stuff actually worked. First let me explain about the code repository (what it calls codestation) and why it was critical to the TCK testing IMO. When we use Maven normally, it pulls data from a set of external repositories, picks up more repositories from the stuff it downloads and quickly we loose control where stuff comes from. After it pulls down all that stuff, it churns though a build and spits out the stuff we care about, normally stuffing them (via mvn install) into the local repository. AHP supports by default tasks to publish artifacts (really just a set of files controlled by an Ant-like include/exclude path) from a build agent into Codestation, as well as tasks to resolve artifacts (ie. download them from Codestation to the local working directory on the build agents system). Each top-level build in AHP gets assigned a new (empty) build life. Artifacts are always published to/resolved from a build life, either that of the current build, or of a dependency build. So what I did was I setup builds for Geronimo Server (the normal server/trunk stuff), which did the normal mvn install thingy, but I always gave it a custom -Dmaven.local.repository which resolved to something inside the working directory for the running build. The build was still online, so it pulled down a bunch of stuff into an empty local repository (so it was a clean build wrt the repository, as well as the source code, which was always fetched for each new build). Once the build had finished, I used the artifact publisher task to push *all* of the stuff in the local repository into Codestation, labled as something like "Maven repository artifacts" for the current build life. Then I setup another build for Apache Geronimo CTS Server (the porting/branches/* stuff). This build was dependent upon the "Maven repository artifacts" of the Geronimo Server build, and I configured those artifacts to get installed on the build agents system in the same directory that I configured the CTS Server build to use for its local maven repository. So again the repo started out empty, then got populated with all of t
[jira] Reopened: (GERONIMO-4328) change boilerplate geronimo plugin to use car format (instead of current jar format)
[ https://issues.apache.org/jira/browse/GERONIMO-4328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor reopened GERONIMO-4328: --- Assignee: Jarek Gawor (was: Lin Sun) This change or related change does break the geronimo-maven-plugin (installer mojo). Sometimes you will see this "Maven2Repository must have a root that's a valid readable directory" error message as Donald pointed out as the plugin will incorrect detect the root directory of Geronimo. > change boilerplate geronimo plugin to use car format (instead of current jar > format) > > > Key: GERONIMO-4328 > URL: https://issues.apache.org/jira/browse/GERONIMO-4328 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) >Affects Versions: 2.2 >Reporter: Lin Sun >Assignee: Jarek Gawor >Priority: Minor > Fix For: 2.2 > > > This has been discussed on dev list here - > http://www.nabble.com/boilerplate,-jaxws-tools-(convert-from-jar-to-car-format-)-td19727867s134.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Java EE 6 Spec Info
All, FYI, here's an update on information on the expected Java EE 6 schedule -- http://weblogs.java.net/blog/robc/archive/2008/10/update_on_the_s.html As this information is published, I'm assuming that we'll be starting to build up our EE 6 road map/report card to help with planning our Java EE 6 support. --kevan
[jira] Created: (GERONIMO-4345) jar-file in persistence.xml overwrites toplink.ddl-generation
jar-file in persistence.xml overwrites toplink.ddl-generation
-
Key: GERONIMO-4345
URL: https://issues.apache.org/jira/browse/GERONIMO-4345
Project: Geronimo
Issue Type: Bug
Security Level: public (Regular issues)
Affects Versions: 2.1.3
Environment: assumedly all
Reporter: Matthias Berndt
Priority: Critical
If an addtional jar with entities is specified in the persistence.xml with
{{}}, the {{}}
is overwritten or ignored an OpenJPA tries to create tables in the database.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4343) Tuscany Geronimo plugin bring up
[ https://issues.apache.org/jira/browse/GERONIMO-4343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder updated GERONIMO-4343: Attachment: up-to-tuscany-1.4-snapshot.diff The up-to-tuscany-1.4-snapshot.diff patch moves the plugin from the Tuscany 1.3 release to use Tuscany 1.4-SNAPSHOT release which is the latest trunk. As part of this i've copied the class ModelResolverImpl to here instead of using the one in the tuscany-spring module as it that seems better than having a dependeny in this plugin on tuscanys spring support when nothing else in the plugin needs spring. I'll look at moving that class out of the spring module to somewhere else in tuscany as there is nothing specific in that class to spring. After this change the plugin now works without needing the local patch to the tuscany-core module. I'm publishing the lastest Tuscany modules SNAPSHOTS right now but it takes a couple of hours to finish that on my slow network connection. > Tuscany Geronimo plugin bring up > > > Key: GERONIMO-4343 > URL: https://issues.apache.org/jira/browse/GERONIMO-4343 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) >Reporter: ant elder > Attachments: asm.diff, GeronimoServletHost1.diff, > GeronimoServletHost2.diff, tuscany-core-1.3.jar, tuscany-xsd-dependency.diff, > up-to-tuscany-1.4-snapshot.diff, wsdlgen-depenency.diff > > > JIRA to cover getting the Tuscany Geronimo Plugin working again with the > latest releases of Tuscany and Geronimo. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[BUILD] trunk: Failed for Revision: 703160
Geronimo Revision: 703160 built with tests included
See the full build-0900.log file at
http://people.apache.org/builds/geronimo/server/binaries/trunk/20081009/build-0900.log
Download the binaries from
http://people.apache.org/builds/geronimo/server/binaries/trunk/20081009
[INFO] BUILD SUCCESSFUL
[INFO]
[INFO] Total time: 38 minutes 21 seconds
[INFO] Finished at: Thu Oct 09 09:42:47 EDT 2008
[INFO] Final Memory: 379M/1015M
[INFO]
TESTSUITE RESULTS (Failures only)
=
See detailed results at
http://people.apache.org/builds/geronimo/server/testsuite/ResultsSummary.html
Assembly: tomcat
=
See the full test.log file at
http://people.apache.org/builds/geronimo/server/binaries/trunk/20081009/logs-0900-tomcat/test.log
[INFO] [geronimo:start-server {execution: start}]
[INFO] Using assembly configuration: tomcat
[INFO] snapshot
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:2.2-SNAPSHOT: checking
for updates from apache-snapshots
[INFO] snapshot
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:2.2-SNAPSHOT: checking
for updates from codehaus-snapshots
[INFO] snapshot
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:2.2-SNAPSHOT: checking
for updates from apache.snapshots
[INFO] Using assembly artifact:
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:zip:bin:2.2-SNAPSHOT:provided
[INFO] Using geronimoHome:
/home/geronimo/geronimo/trunk/testsuite/target/geronimo-tomcat6-javaee5-2.2-SNAPSHOT
[INFO] Installing assembly...
[INFO] Expanding:
/home/geronimo/.m2/repository/org/apache/geronimo/assemblies/geronimo-tomcat6-javaee5/2.2-SNAPSHOT/geronimo-tomcat6-javaee5-2.2-SNAPSHOT-bin.zip
into /home/geronimo/geronimo/trunk/testsuite/target
[INFO] Starting Geronimo server...
[INFO] Selected option set: default
[INFO] Redirecting output to:
/home/geronimo/geronimo/trunk/testsuite/target/geronimo-logs/org.apache.geronimo.mavenplugins.geronimo.server.StartServerMojo.log
[INFO] Waiting for Geronimo server...
[INFO] Geronimo server started in 0:00:42.064
[INFO] [shitty:install {execution: default}]
[INFO] Installing /home/geronimo/geronimo/trunk/testsuite/pom.xml to
/home/geronimo/.m2/repository/org/apache/geronimo/testsuite/testsuite/2.2-SNAPSHOT/testsuite-2.2-SNAPSHOT.pom
[INFO] [shitty:test {execution: default}]
[INFO] Starting 33 test build(s)
[INFO]
[INFO]
---
[INFO]
[INFO] commands-testsuite/deployRUNNING
[INFO] commands-testsuite/deploySUCCESS (0:01:09.346)
[INFO] commands-testsuite/gshellRUNNING
[INFO] commands-testsuite/gshellSUCCESS (0:00:29.627)
[INFO] commands-testsuite/jaxws RUNNING
[INFO] commands-testsuite/jaxws SUCCESS (0:00:19.154)
[INFO] commands-testsuite/shutdown RUNNING
[INFO] commands-testsuite/shutdown SUCCESS (0:00:16.392)
[INFO] concurrent-testsuite/concurrent-basicRUNNING
[INFO] concurrent-testsuite/concurrent-basicSUCCESS (0:06:14.046)
[INFO] console-testsuite/advanced RUNNING
[INFO] console-testsuite/advanced SUCCESS (0:01:36.683)
[INFO] console-testsuite/basic RUNNING
[INFO] console-testsuite/basic SUCCESS (0:01:43.550)
[INFO] corba-testsuite/corba-helloworld RUNNING
[INFO] corba-testsuite/corba-helloworld SUCCESS (0:00:43.002)
[INFO] corba-testsuite/corba-marshalRUNNING
[INFO] corba-testsuite/corba-marshalSUCCESS (0:00:44.635)
[INFO] corba-testsuite/corba-mytime RUNNING
[INFO] corba-testsuite/corba-mytime SUCCESS (0:00:45.303)
[INFO] deployment-testsuite/deployment-testsRUNNING
[INFO] deployment-testsuite/deployment-testsSUCCESS (0:00:31.432)
[INFO] deployment-testsuite/jca-cms-tests RUNNING
[INFO] deployment-testsuite/jca-cms-tests SUCCESS (0:00:27.404)
[INFO] deployment-testsuite/manifestcp-testsRUNNING
[INFO] deployment-testsuite/manifestcp-testsSUCCESS (0:00:28.858)
[INFO] enterprise-testsuite/ejb-tests RUNNING
[INFO] enterprise-testsuite/ejb-tests SUCCESS (0:00:41.438)
[INFO] enterprise-testsuite/jms-tests RUNNING
[INFO] enterprise-testsuite/jms-tests SUCCESS (0:00:47.331)
[INFO] enterprise-testsuite/jpa-tests RUNNING
[INFO] enterprise-testsuite/jpa-tests SUCCESS (0:00:54.681)
[INFO] enterprise-testsuite/sec-client RUNNING
[INFO] enterprise-testsuite/sec-client SUCCESS (0:00:26.456)
[INFO] enterprise-testsuite/sec-tests RUNNING
[INFO] enterprise-testsuite/sec-tests SUCCESS (0:00:48.512)
[INFO] security-testsuite/test-security RUNNING
[INFO] security
Re: [jira] Commented: (GERONIMO-4343) Tuscany Geronimo plugin bring up
Thanks for applying all the patches for this and Vamsi for the other changes you've been doing to it. The plugin is now working for me with the Tomcat version of Geronimo and is able to run an SCA contribution that uses a Web service binding. Thats does require the local mod to the tuscany-core-1.3.jar though so i think the next step is to move the plugin up to use the latest snapshot release of tuscany so it can pick up fixes and also start to use the latest Tuscany Node APIs. I'll go look at doing this now. ...ant On Wed, Oct 8, 2008 at 4:09 PM, ant elder (JIRA) <[EMAIL PROTECTED]> wrote: > >[ > https://issues.apache.org/jira/browse/GERONIMO-4343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12637953#action_12637953] > > ant elder commented on GERONIMO-4343: > - > > That is the problem fixed in the tuscany-core-1.3.jar thats attached to > the JIRA. > > To fix that properly we need to change the plugin to use the latest Tuscany > SNAPSHOT jars instead of the 1.3 release jars so we can make fixes in the > Tuscany code base for the plugin to pick up > > > Tuscany Geronimo plugin bring up > > > > > > Key: GERONIMO-4343 > > URL: https://issues.apache.org/jira/browse/GERONIMO-4343 > > Project: Geronimo > > Issue Type: Bug > > Security Level: public(Regular issues) > >Reporter: ant elder > > Attachments: asm.diff, GeronimoServletHost1.diff, > GeronimoServletHost2.diff, tuscany-core-1.3.jar, > tuscany-xsd-dependency.diff, wsdlgen-depenency.diff > > > > > > JIRA to cover getting the Tuscany Geronimo Plugin working again with the > latest releases of Tuscany and Geronimo. > > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online. > >
Re: Continuous TCK Testing
My apologies. I didn't phrase my question properly. Most of the software necessary was pulled down via svn, but I saw no such behaviour for AHP. After looking at it some more, I imagine the software was just manually installed on the machine. It was kind of a silly question to begin with, I suppose. On Thu, Oct 9, 2008 at 4:16 AM, Jason Dillon <[EMAIL PROTECTED]> wrote: > On Oct 8, 2008, at 11:05 PM, Jason Warner wrote: > > Here's a quick question. Where does AHP come from? > > > http://www.anthillpro.com > > (ever heard of google :-P) > > --jason > > > > On Mon, Oct 6, 2008 at 1:18 PM, Jason Dillon <[EMAIL PROTECTED]>wrote: > >> Sure np, took me a while to get around to writing it too ;-) >> --jason >> >> >> On Oct 6, 2008, at 10:24 PM, Jason Warner wrote: >> >> Just got around to reading this. Thanks for the brain dump, Jason. No >> questions as of yet, but I'm sure I'll need a few more reads before I >> understand it all. >> >> On Thu, Oct 2, 2008 at 2:34 PM, Jason Dillon <[EMAIL PROTECTED]>wrote: >> >>> On Oct 1, 2008, at 11:20 PM, Jason Warner wrote: >>> >>> Is the GBuild stuff in svn the same as the anthill-based code or is that something different? GBuild seems to have scripts for running tck and that leads me to think they're the same thing, but I see no mention of anthill in the code. >>> >>> The Anthill stuff is completely different than the GBuild stuff. I >>> started out trying to get the TCK automated using GBuild, but decided that >>> the system lacked too many features to perform as I desired, and went ahead >>> with Anthill as it did pretty much everything, though had some stability >>> problems. >>> >>> One of the main reasons why I choose Anthill (AHP, Anthill Pro that is) >>> was its build agent and code repository systems. This allowed me to ensure >>> that each build used exactly the desired artifacts. Another was the >>> configurable workflow, which allowed me to create a custom chain of events >>> to handle running builds on remote agents and control what data gets set to >>> them, what it will collect and what logic to execute once all distributed >>> work has been completed for a particular build. And the kicker which help >>> facilitate bringing it all together was its concept of a build life. >>> >>> At the time I could find *no other* build tool which could meet all of >>> these needs, and so I went with AHP instead of spending months >>> building/testing features in GBuild. >>> >>> While AHP supports configuring a lot of stuff via its web-interface, I >>> found that it was very cumbersome, so I opted to write some glue, which was >>> stored in svn here: >>> >>> >>> https://svn.apache.org/viewvc/geronimo/sandbox/build-support/?pathrev=632245 >>> >>> Its been a while, so I have to refresh my memory on how this stuff >>> actually worked. First let me explain about the code repository (what it >>> calls codestation) and why it was critical to the TCK testing IMO. When we >>> use Maven normally, it pulls data from a set of external repositories, picks >>> up more repositories from the stuff it downloads and quickly we loose >>> control where stuff comes from. After it pulls down all that stuff, it >>> churns though a build and spits out the stuff we care about, normally >>> stuffing them (via mvn install) into the local repository. >>> >>> AHP supports by default tasks to publish artifacts (really just a set of >>> files controlled by an Ant-like include/exclude path) from a build agent >>> into Codestation, as well as tasks to resolve artifacts (ie. download them >>> from Codestation to the local working directory on the build agents system). >>> Each top-level build in AHP gets assigned a new (empty) build life. >>> Artifacts are always published to/resolved from a build life, either that >>> of the current build, or of a dependency build. >>> >>> So what I did was I setup builds for Geronimo Server (the normal >>> server/trunk stuff), which did the normal mvn install thingy, but I always >>> gave it a custom -Dmaven.local.repository which resolved to something inside >>> the working directory for the running build. The build was still online, so >>> it pulled down a bunch of stuff into an empty local repository (so it was a >>> clean build wrt the repository, as well as the source code, which was always >>> fetched for each new build). Once the build had finished, I used the >>> artifact publisher task to push *all* of the stuff in the local repository >>> into Codestation, labled as something like "Maven repository artifacts" for >>> the current build life. >>> >>> Then I setup another build for Apache Geronimo CTS Server (the >>> porting/branches/* stuff). This build was dependent upon the "Maven >>> repository artifacts" of the Geronimo Server build, and I configured those >>> artifacts to get installed on the build agents system in the same directory >>> that I configured the CTS Server build to use for its local maven >>> repos
[jira] Resolved: (GERONIMO-4344) IMAPMessage#updateHeader updates header with wrong value
[ https://issues.apache.org/jira/browse/GERONIMO-4344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick McGuire resolved GERONIMO-4344. Resolution: Fixed Committed revision 702800. Thank you once again! Keep up the good work. > IMAPMessage#updateHeader updates header with wrong value > > > Key: GERONIMO-4344 > URL: https://issues.apache.org/jira/browse/GERONIMO-4344 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: mail >Reporter: Andreas Veithen >Assignee: Rick McGuire > Attachments: GERONIMO-4344.patch.txt > > > IMAPMessage#updateHeader always updates the header with the value of > envelope.from instead of the value passed as argument. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-4344) IMAPMessage#updateHeader updates header with wrong value
[ https://issues.apache.org/jira/browse/GERONIMO-4344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick McGuire reassigned GERONIMO-4344: -- Assignee: Rick McGuire > IMAPMessage#updateHeader updates header with wrong value > > > Key: GERONIMO-4344 > URL: https://issues.apache.org/jira/browse/GERONIMO-4344 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: mail >Reporter: Andreas Veithen >Assignee: Rick McGuire > Attachments: GERONIMO-4344.patch.txt > > > IMAPMessage#updateHeader always updates the header with the value of > envelope.from instead of the value passed as argument. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Continuous TCK Testing
I'd imagine we need to ask the AHP folks for a new license. --jason On Oct 9, 2008, at 10:56 AM, Kevan Miller wrote: On Oct 8, 2008, at 4:31 PM, Jason Warner wrote: We had some suggestions earlier for some alternate means of implementing this (Hudson, Conitnuum, etc...). Now that we've had Jason Dillon provide an overview of what we had in place before, does anyone have thoughts on what we should go with? I'm thinking we should stick with the AHP based solution. It will need to be updated most likely, but it's been tried and tested and shown to meet our needs. I'm wondering, though, why we stopped using it before. Was there a specific issue we're going to have to deal with again? IIRC, the overwhelming reason we stopped using it before was because of hosting issues -- spotty networking, hardware failures, poor colo support, etc. We shouldn't have any of these problems, now. If we do run into problems, they should now be fixable. I have no reason to favor Hudson/Continuum over AHP. So, if we can get AHP running easily, I'm all for it. There's only one potential issue, that I'm aware of. We previously had an Open Source License issued for our use of Anthill. Here's some of the old discussion -- http://www.nabble.com/Geronimo-build-automation-status-(longish)-tt7649902.html#a7649902 Although the board was aware of our usage of AntHill, since we weren't running AntHill on ASF hardware, I'm not sure the license was fully vetted by Infra. I don't see any issues, but I'll want to run this by Infra. Jason D, will the existing license cover the version of AntHill that we'll want to use? I'll run the license by Infra and will also describe the issue for review by the Board, in our quarterly report. IMO, I'd proceed with the assumption that we'll be using AHP. Just don't install it on Apache hardware, yet. --kevan
Re: Continuous TCK Testing
On Oct 8, 2008, at 11:05 PM, Jason Warner wrote: Here's a quick question. Where does AHP come from? http://www.anthillpro.com (ever heard of google :-P) --jason On Mon, Oct 6, 2008 at 1:18 PM, Jason Dillon <[EMAIL PROTECTED]> wrote: Sure np, took me a while to get around to writing it too ;-) --jason On Oct 6, 2008, at 10:24 PM, Jason Warner wrote: Just got around to reading this. Thanks for the brain dump, Jason. No questions as of yet, but I'm sure I'll need a few more reads before I understand it all. On Thu, Oct 2, 2008 at 2:34 PM, Jason Dillon <[EMAIL PROTECTED]> wrote: On Oct 1, 2008, at 11:20 PM, Jason Warner wrote: Is the GBuild stuff in svn the same as the anthill-based code or is that something different? GBuild seems to have scripts for running tck and that leads me to think they're the same thing, but I see no mention of anthill in the code. The Anthill stuff is completely different than the GBuild stuff. I started out trying to get the TCK automated using GBuild, but decided that the system lacked too many features to perform as I desired, and went ahead with Anthill as it did pretty much everything, though had some stability problems. One of the main reasons why I choose Anthill (AHP, Anthill Pro that is) was its build agent and code repository systems. This allowed me to ensure that each build used exactly the desired artifacts. Another was the configurable workflow, which allowed me to create a custom chain of events to handle running builds on remote agents and control what data gets set to them, what it will collect and what logic to execute once all distributed work has been completed for a particular build. And the kicker which help facilitate bringing it all together was its concept of a build life. At the time I could find *no other* build tool which could meet all of these needs, and so I went with AHP instead of spending months building/testing features in GBuild. While AHP supports configuring a lot of stuff via its web- interface, I found that it was very cumbersome, so I opted to write some glue, which was stored in svn here: https://svn.apache.org/viewvc/geronimo/sandbox/build-support/?pathrev=632245 Its been a while, so I have to refresh my memory on how this stuff actually worked. First let me explain about the code repository (what it calls codestation) and why it was critical to the TCK testing IMO. When we use Maven normally, it pulls data from a set of external repositories, picks up more repositories from the stuff it downloads and quickly we loose control where stuff comes from. After it pulls down all that stuff, it churns though a build and spits out the stuff we care about, normally stuffing them (via mvn install) into the local repository. AHP supports by default tasks to publish artifacts (really just a set of files controlled by an Ant-like include/exclude path) from a build agent into Codestation, as well as tasks to resolve artifacts (ie. download them from Codestation to the local working directory on the build agents system). Each top-level build in AHP gets assigned a new (empty) build life. Artifacts are always published to/resolved from a build life, either that of the current build, or of a dependency build. So what I did was I setup builds for Geronimo Server (the normal server/trunk stuff), which did the normal mvn install thingy, but I always gave it a custom -Dmaven.local.repository which resolved to something inside the working directory for the running build. The build was still online, so it pulled down a bunch of stuff into an empty local repository (so it was a clean build wrt the repository, as well as the source code, which was always fetched for each new build). Once the build had finished, I used the artifact publisher task to push *all* of the stuff in the local repository into Codestation, labled as something like "Maven repository artifacts" for the current build life. Then I setup another build for Apache Geronimo CTS Server (the porting/branches/* stuff). This build was dependent upon the "Maven repository artifacts" of the Geronimo Server build, and I configured those artifacts to get installed on the build agents system in the same directory that I configured the CTS Server build to use for its local maven repository. So again the repo started out empty, then got populated with all of the outputs from the normal G build, and then the cts-server build was started. The build of the components and assemblies is normally fairly quick and aside from some stuff in the private tck repo won't download muck more stuff, because it already had most of its dependencies installed via the Codestation dependency resolution. Once the build finished, I published to cts-server assembly artifacts back to Codestation under like "CTS Server Assemblies" or something. Up until this
[BUILD] trunk: Failed for Revision: 703079
Geronimo Revision: 703079 built with tests included See the full build-0300.log file at http://people.apache.org/builds/geronimo/server/binaries/trunk/20081009/build-0300.log See the unit test reports at http://people.apache.org/builds/geronimo/server/binaries/trunk/20081009/unit-test-reports local:org.apache.cxf:cxf-common-utilities:jar:2.1.3-SNAPSHOT:compile local:org.apache.ws.commons.schema:XmlSchema:jar:1.4.2:compile local:org.apache.geronimo.specs:geronimo-annotation_1.0_spec:jar:1.1.1:compile already in car, returning:org.apache.geronimo.specs:geronimo-annotation_1.0_spec:jar:1.1.1:compile local:org.codehaus.woodstox:wstx-asl:jar:3.2.1:compile already in car, returning:org.codehaus.woodstox:wstx-asl:jar:3.2.1:compile local:org.apache.neethi:neethi:jar:2.0:compile local:org.apache.cxf:cxf-common-utilities:jar:2.1.3-SNAPSHOT:compile local:org.springframework:spring-core:jar:2.0.5:compile already in car, returning:org.springframework:spring-core:jar:2.0.5:compile local:org.springframework:spring-beans:jar:2.0.5:compile already in car, returning:org.springframework:spring-beans:jar:2.0.5:compile local:org.springframework:spring-context:jar:2.0.5:compile already in car, returning:org.springframework:spring-context:jar:2.0.5:compile local:org.apache.geronimo.specs:geronimo-annotation_1.0_spec:jar:1.1.1:compile already in car, returning:org.apache.geronimo.specs:geronimo-annotation_1.0_spec:jar:1.1.1:compile local:javax.xml.bind:jaxb-api:jar:2.1:compile already in car, returning:javax.xml.bind:jaxb-api:jar:2.1:compile local:org.apache.geronimo.specs:geronimo-stax-api_1.0_spec:jar:1.0.1:compile already in car, returning:org.apache.geronimo.specs:geronimo-stax-api_1.0_spec:jar:1.0.1:compile local:wsdl4j:wsdl4j:jar:1.6.2:compile already in car, returning:wsdl4j:wsdl4j:jar:1.6.2:compile local:xml-resolver:xml-resolver:jar:1.2:compile local:org.apache.ws.commons.schema:XmlSchema:jar:1.4.2:compile local:org.apache.cxf:cxf-rt-bindings-soap:jar:2.1.3-SNAPSHOT:compile local:org.apache.cxf:cxf-api:jar:2.1.3-SNAPSHOT:compile local:org.apache.cxf:cxf-tools-common:jar:2.1.3-SNAPSHOT:compile local:org.apache.cxf:cxf-rt-databinding-jaxb:jar:2.1.3-SNAPSHOT:compile local:javax.xml.bind:jaxb-api:jar:2.1:compile already in car, returning:javax.xml.bind:jaxb-api:jar:2.1:compile local:org.apache.cxf:cxf-rt-bindings-xml:jar:2.1.3-SNAPSHOT:compile local:org.apache.cxf:cxf-api:jar:2.1.3-SNAPSHOT:compile local:org.apache.cxf:cxf-rt-databinding-jaxb:jar:2.1.3-SNAPSHOT:compile local:org.apache.cxf:cxf-rt-core:jar:2.1.3-SNAPSHOT:compile local:org.apache.cxf:cxf-api:jar:2.1.3-SNAPSHOT:compile local:org.apache.ws.commons.schema:XmlSchema:jar:1.4.2:compile local:org.springframework:spring-core:jar:2.0.5:compile already in car, returning:org.springframework:spring-core:jar:2.0.5:compile local:org.apache.cxf:cxf-rt-databinding-jaxb:jar:2.1.3-SNAPSHOT:compile local:org.apache.cxf:cxf-api:jar:2.1.3-SNAPSHOT:compile local:org.apache.cxf:cxf-rt-core:jar:2.1.3-SNAPSHOT:compile local:org.apache.geronimo.specs:geronimo-activation_1.1_spec:jar:1.0.2:compile already in car, returning:org.apache.geronimo.specs:geronimo-activation_1.1_spec:jar:1.0.2:compile local:org.codehaus.woodstox:wstx-asl:jar:3.2.1:compile already in car, returning:org.codehaus.woodstox:wstx-asl:jar:3.2.1:compile local:org.apache.cxf:cxf-rt-frontend-jaxws:jar:2.1.3-SNAPSHOT:compile local:org.apache.geronimo.specs:geronimo-jaxws_2.1_spec:jar:1.0:compile already in car, returning:org.apache.geronimo.specs:geronimo-jaxws_2.1_spec:jar:1.0:compile local:asm:asm:jar:2.2.3:compile already in car, returning:asm:asm:jar:2.2.3:compile local:org.apache.cxf:cxf-api:jar:2.1.3-SNAPSHOT:compile local:org.apache.cxf:cxf-rt-core:jar:2.1.3-SNAPSHOT:compile local:org.apache.cxf:cxf-rt-bindings-soap:jar:2.1.3-SNAPSHOT:compile local:org.apache.cxf:cxf-rt-bindings-xml:jar:2.1.3-SNAPSHOT:compile local:org.apache.cxf:cxf-rt-frontend-simple:jar:2.1.3-SNAPSHOT:compile local:org.apache.cxf:cxf-rt-ws-addr:jar:2.1.3-SNAPSHOT:compile local:com.sun.xml.messaging.saaj:saaj-impl:jar:1.3:compile already in car, returning:com.sun.xml.messaging.saaj:saaj-impl:jar:1.3:compile local:com.sun.xml.parsers:jaxp-ri:jar:1.4.2:compile local:javax.xml.parsers:jaxp-api:jar:1.4.2:compile local:org.apache.cxf:cxf-rt-frontend-simple:jar:2.1.3-SNAPSHOT:compile local:org.apache.geronimo.specs:geronimo-jaxws_2.1_spec:jar:1.0:compile already in car, returning:org.apache.geronimo.specs:geronimo-jaxws_2.1_spec:jar:1.0:compile local:org.apache.cxf:cxf-api:jar:2.1.3-SNAPSHOT:compile local:org.apache.cxf:cxf-rt-core:jar:2.1.3-SNAPSHOT:compile local:org.apache.cxf:cxf-rt-bindings-soap:jar:2.1.3-SNAPSHOT:compile local:org.apache.cxf:cxf-rt-transports-http:jar:2.1.3-SNAPSHOT:compile local:org.apache.cxf:cxf-api:jar:2.1.3-SNAPSHOT:compile local:org.apache.cxf:cxf-rt-core:jar:2.1.3-SNAPSHOT:compile
