Re: ejb-jar.xml and EJB 3.0
zeros wrote: Thanks a lot. It was the solution. In the documentation which I have, the local and remote interfaces are shown by remote/remote and local/local, but substituing those by business-local/business-local and business-remote/business-remote it works perfectly. With tags i meant @Local and @Remote Thanks a lot again Just a note. In the latest trunk code we now fully check for this common mistake as well as any other possible misuses of the home, remote, local-home, local, business-local, and business-remote elements of the ejb-jar.xml. We don't just check that the value supplied is correct, but we also attempt to determine what you supplied and tell you the correct element should be. All combined there are now 44 different possible error messages we're prepared to issue to cover the many different scenarios. Hopefully no one else will have to loose any time to this mistake. -David -- View this message in context: http://www.nabble.com/ejb-jar.xml-and-EJB-3.0-tp16249489s134p18523547.html Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com.
Re: client accessing remote EJB -(OEJP 2.0)
On Jun 24, 2008, at 12:32 PM, dnsunil wrote: When accessing a remote EJB running on Websphere CE environment from a standalone client on Windows 2003 server throwing the below exception Unknown Container Exception: java.rmi.RemoteException: Cannot read the response from the server (OEJP/2.0) : null; nested exception is: java.io.EOFException Note:- File read/write process is being handled (approx 150 MB) and it failed after 4 hours of processing giving the above exception. Just a follow up note. In the latest trunk code this issue has been completely fixed. The client/server socket management code has been rewritten and now gives several times the throughput as the prior version. In the 2.1 version remote client/server transactions per second (TPS) starts at around 600-700 TPS and tapers off after a few hours. In the latest code we're seeing a sustained 7300 TPS over a 24 hr period. -David
Re: Liferay as a Geronimo Plugin
Gianny Damour wrote: On 14/07/2008, at 5:17 PM, Peter Petersson wrote: Gianny Damour wrote: Hello Peter, This is great news for Liferay developers! IMHO, one of the pain points with Liferay development is the time it takes to build, pack and deploy a WAR to Liferay. Even if Liferay is not so bad on this front when compared with other portals, a typical build-deploy-test cycle is way too time consuming and hence seriously impacts productivity. It would be fantastic to have an in-place WAR development mode in Geronimo. What do you think? I guess you are referring to working with/in the liferay ext development environment (?). I know to little of Liferay internals (and Geronimo for that mater) to be sure exactly what you are looking for, but I am sure the Liferay team is working hard on making there development environment easier and faster to work with. Maybe you can elaborate a bit more on what you are thinking of. Hello, My understanding is that each time that you make a change, you need to build a WAR; drop it in the deployment folder of Liferay; Liferay scans and transforms the WAR (looking for portlets, themes et cetera); it then hands it over to Geronimo for deployment. These deployment steps are time consuming, especially during development. What I had in mind is a Geronimo plugin allowing the in-place deployment of WARs to Liferay: 1. I define a specific WAR project structure; 2. I set-up my IDE to work against this well-known WAR project structure; 3. I implement my portlets and my IDE compiles the sources to the right folder of the WAR project structure; 4. I deploy to Geronimo my WAR project structure; 5. A custom ModuleBuilder identifies that this is a liferay WAR project structure; looks for the relevant Liferay components; and deploys it in-place. Hi, Maybe this is something on the line of what you are looking for: I have set up a small maven test project that wraps liferay portlets, themes et cetera into deployable Geronimo plugins. Looking at the logs wile deploying a liferay portlet geronimo plugin it seem to handle the deployment correctly and Liferay notifies you about a available update but looking in to it in the Update manager admin tool in liferay the Installation status never changes from Installation in progress so I suspect there is some configuration problem or module missing In my Geronimo Liferay server assembly for it to work correctly. Hopefully this is resolvable but at the moment I don't have a clue about whats causing the problem. Using this approach It would probably not be to hard to totally automate the installation process for Liferay extensions by using GShell (or is there a way to deploy to Geronimo plugins via maven directly ?) I was thinking of testing the portlet plugins on the new Liferay Geronimo (5.0.1/2.1.1) assembly available from Liferay but there is a (issue reported) problem with user authentication using derby db as back-end so I was unfortunately not able to see if it worked better on that one. regards peter petersson Personally I will look in to setting up a maven project for building Liferay portlets and have them deployed to Geronimo in some automated way instead of working with the ext environment, maybe this is what you are looking for? I don't know yet how the deployment could be done but I guess that I will making use of Liferays hot-deploy mechanism and/or if possible find some way to make use of Geronimo:s plugin concept. If possible I would certainly prefer the plugin solution. I believe that the Liferay hot-deployment mechanism is way too slow in development. Does that make sense? Thanks, Gianny Maybe the deployment could be done in a similar way of what we have done with the roller-themes plugin in the geromimo-roller project ? see https://svn.apache.org/repos/asf/geronimo/plugins/roller/trunk regards peter petersson Thanks, Gianny On 14/07/2008, at 4:11 AM, Peter Petersson wrote: I have posted a feature issue containing the build code over at http://support.liferay.com/browse/LEP-6680 regards peter petersson Peter Petersson wrote: Hi With the help of David J custom server assemblies document ( http://cwiki.apache.org/GMOxDOC21/custom-server-assemblies.html ) and my experience working with David on the roller plugin I have manage to put together a Liferay ( http://www.liferay.com ) plugin. For now the plugin is with liferay 5.0.1 rc1 on G 2.1.1 and consists of the following maven artifacts * geronimo-jetty-liferay -- A minimalistic server assembly with the geronimo kernel the lifray jetty plugin and the geronimo console plugin. * liferay-jetty -- The liferay jetty plugin built on the lesslibs liferay-portal war pulling in dependencys like lifray -kernel, -service and -portlet. * geronimo-tomcat-liferay -- A minimalistic server as above but with the liferay tomcat plugin. * liferay-tomcat -- The liferay tomcat plugin as liferay-jetty
[jira] Resolved: (GERONIMODEVTOOLS-441) Retrieving Metadata complete Deployment Descriptor for Web Projects
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shiva Kumar H R resolved GERONIMODEVTOOLS-441. -- Resolution: Fixed Assignee: Sainath Chowdary (was: Shiva Kumar H R) Another game winner from Sainath! Many thanks Sainath for the patch. Committed it in trunk at revision: 677890 Retrieving Metadata complete Deployment Descriptor for Web Projects --- Key: GERONIMODEVTOOLS-441 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-441 Project: Geronimo-Devtools Issue Type: Sub-task Components: eclipse-plugin Affects Versions: 2.1.2, 2.1.x Reporter: Sainath Chowdary Assignee: Sainath Chowdary Fix For: 2.1.2, 2.1.x Attachments: DeploymentDescriptor.patch Another critical aspect for porting plan creator work in GEP is to retrieve the metadata complete deployment descriptor. This also links the deployment descriptor and deployment plan effectively. This should emphasize at creating an architecture so that it can be easily extended for other type of projects like EJBs, EARs etc. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
branches/2.1 - 72 hour notice for 2.1.2 release processing
I know it's a little bit more than the usual 24 hours but since a weekend is involved I figured I'd give a bit more advanced notice so that nobody is caught unaware. As we've previously discussed, I plan to create a branch for 2.1.2 release processing on Monday, 7/21 around 10:00 ET. Joe
Samples for 2.1.2
We already decided to release samples for the upcoming Geronimo 2.1.2 server rather than attempting to release samples for Geronimo 2.1 and figure out how to make them work on 2.1.1 and 2.1.2. So, the next question is when should we release the samples for 2.1.2? My thoughts were to try to get these released a few weeks after our Geronimo 2.1.2 release. However, I've heard some comments that we should consider releasing the Samples for 2.1.2 concurrent with the server 2.1.2 release. This would most likely mean that we would have to delay our target for a 2.1.2 release beyond the end of the month. Regarding sample items that must be completed before we can release ... there are still a number of things ... general cleanup and validation, doc updates, verified functions, archetype, etc... There are also a few more decisions regarding how users would work with the samples that will influence how we structure things (more coming on that soon). You can find a more detailed list on this wiki page: http://cwiki.apache.org/GMOxPMGT/geronimo-samples-212-release-work-items.html Joe
[jira] Created: (GERONIMO-4209) Geronimo does not start on SAP JVM
Geronimo does not start on SAP JVM -- Key: GERONIMO-4209 URL: https://issues.apache.org/jira/browse/GERONIMO-4209 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Affects Versions: 2.1.1 Environment: Windows XP 64 SAP JVM 1.5.0_14 Reporter: Markus Ofterdinger Priority: Trivial I tried to get the Geronimo Application Server 2.1.1 running on a SAP JVM. But the startup fails. I found this error message in the log: Caused by: java.lang.StringIndexOutOfBoundsException: String index out of range: 7 at java.lang.String.substring(String.java:1799) at org.apache.geronimo.system.properties.JvmVendor.clinit(JvmVendor.java:50) ... 25 more At this line a subString(0, 7) is performed on the VM vendor name, but the full vendor name of a SAP JVM contains only 6 characters SAP AG. I did a small fix which adds an additional length check: Index: src/main/java/org/apache/geronimo/system/properties/JvmVendor.java === --- src/main/java/org/apache/geronimo/system/properties/JvmVendor.java (Revision 677904) +++ src/main/java/org/apache/geronimo/system/properties/JvmVendor.java (Arbeitskopie) @@ -47,7 +47,10 @@ boolean bApache = fullVendorName.substring(0, 6).equalsIgnoreCase(Apache);// aka. Apache Harmony boolean bIBM = fullVendorName.substring(0, 3).equalsIgnoreCase(IBM); // aka. IBM, but not IBM Hybrid boolean bSun = !bIBM !bApache; // default all others to Sun -boolean bHP = fullVendorName.substring(0, 7).equalsIgnoreCase(Hewlett); // aka. Hewlett-Packard Company +//boolean bHP = fullVendorName.substring(0, 7).equalsIgnoreCase(Hewlett); // aka. Hewlett-Packard Company +boolean bHP = false; +if (fullVendorName.length() = 7) +bHP = fullVendorName.substring(0, 7).equalsIgnoreCase(Hewlett); // aka. Hewlett-Packard Company boolean bIBMHybrid = false; // Special code for IBM Hybrid SDK (Sun JVM with IBM extensions on Solaris and HP-UX) After applying this fix the app-server started fine. Best regards, Markus Ofterdinger -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4209) Geronimo does not start on SAP JVM
[ https://issues.apache.org/jira/browse/GERONIMO-4209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Markus Ofterdinger updated GERONIMO-4209: - Attachment: sap_jvm.fix Patch Geronimo does not start on SAP JVM -- Key: GERONIMO-4209 URL: https://issues.apache.org/jira/browse/GERONIMO-4209 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 2.1.1 Environment: Windows XP 64 SAP JVM 1.5.0_14 Reporter: Markus Ofterdinger Priority: Trivial Attachments: sap_jvm.fix Original Estimate: 1h Remaining Estimate: 1h I tried to get the Geronimo Application Server 2.1.1 running on a SAP JVM. But the startup fails. I found this error message in the log: Caused by: java.lang.StringIndexOutOfBoundsException: String index out of range: 7 at java.lang.String.substring(String.java:1799) at org.apache.geronimo.system.properties.JvmVendor.clinit(JvmVendor.java:50) ... 25 more At this line a subString(0, 7) is performed on the VM vendor name, but the full vendor name of a SAP JVM contains only 6 characters SAP AG. I did a small fix which adds an additional length check: Index: src/main/java/org/apache/geronimo/system/properties/JvmVendor.java === --- src/main/java/org/apache/geronimo/system/properties/JvmVendor.java (Revision 677904) +++ src/main/java/org/apache/geronimo/system/properties/JvmVendor.java (Arbeitskopie) @@ -47,7 +47,10 @@ boolean bApache = fullVendorName.substring(0, 6).equalsIgnoreCase(Apache);// aka. Apache Harmony boolean bIBM = fullVendorName.substring(0, 3).equalsIgnoreCase(IBM); // aka. IBM, but not IBM Hybrid boolean bSun = !bIBM !bApache; // default all others to Sun -boolean bHP = fullVendorName.substring(0, 7).equalsIgnoreCase(Hewlett); // aka. Hewlett-Packard Company +//boolean bHP = fullVendorName.substring(0, 7).equalsIgnoreCase(Hewlett); // aka. Hewlett-Packard Company +boolean bHP = false; +if (fullVendorName.length() = 7) +bHP = fullVendorName.substring(0, 7).equalsIgnoreCase(Hewlett); // aka. Hewlett-Packard Company boolean bIBMHybrid = false; // Special code for IBM Hybrid SDK (Sun JVM with IBM extensions on Solaris and HP-UX) After applying this fix the app-server started fine. Best regards, Markus Ofterdinger -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [ANNOUNCE] Welcoming Yun Feng Ma as a Geronimo Committer
The account was finally created today - uid = yunfengma Welcome aboard! -Donald Donald Woods wrote: I'd like to welcome Yun Feng Ma as Geronimo's newest committer. He should have his Apache account and karma in the next week or so. Yun Feng, keep up all of the great work to test and submit patches, as you've helped make Geronimo a better server for all of our users. -Donald smime.p7s Description: S/MIME Cryptographic Signature
[Fwd: svn commit: r677660 - in /geronimo/server/branches/2.1: ./ assemblies/geronimo-boilerplate-minimal/ assemblies/geronimo-boilerplate-minimal/src/main/underlay/]
Does anybody know of a better way to accomplish this than the hack I
checked in for 2.1? The objective is to manage just one copy of the
README, RELEASE-NOTES, and DISCLAIMER files in the root svn and include
those as we build the assemblies. If there isn't a better way then I'll
check this same change into trunk.
Thanks,
Joe
Original Message
Subject: svn commit: r677660 - in /geronimo/server/branches/2.1: ./
assemblies/geronimo-boilerplate-minimal/
assemblies/geronimo-boilerplate-minimal/src/main/underlay/
Date: Thu, 17 Jul 2008 18:08:24 -
From: [EMAIL PROTECTED]
Reply-To: dev@geronimo.apache.org
To: [EMAIL PROTECTED]
Author: jbohn
Date: Thu Jul 17 11:08:24 2008
New Revision: 677660
URL: http://svn.apache.org/viewvc?rev=677660view=rev
Log:
include just one copy of text files (readme, release-notes, and
disclaimer) and copy them from root into the assembly images
Removed:
geronimo/server/branches/2.1/assemblies/geronimo-boilerplate-minimal/src/main/underlay/DISCLAIMER.txt
geronimo/server/branches/2.1/assemblies/geronimo-boilerplate-minimal/src/main/underlay/README.txt
geronimo/server/branches/2.1/assemblies/geronimo-boilerplate-minimal/src/main/underlay/RELEASE_NOTES-2.1.1.txt
Modified:
geronimo/server/branches/2.1/README.txt
geronimo/server/branches/2.1/assemblies/geronimo-boilerplate-minimal/pom.xml
Modified: geronimo/server/branches/2.1/README.txt
URL:
http://svn.apache.org/viewvc/geronimo/server/branches/2.1/README.txt?rev=677660r1=677659r2=677660view=diff
==
--- geronimo/server/branches/2.1/README.txt (original)
+++ geronimo/server/branches/2.1/README.txt Thu Jul 17 11:08:24 2008
@@ -1,5 +1,5 @@
==
-Apache Geronimo v2.1 (February 7, 2008)
+Apache Geronimo v2.1.2 (July 31, 2008)
http://geronimo.apache.org/
--
Modified:
geronimo/server/branches/2.1/assemblies/geronimo-boilerplate-minimal/pom.xml
URL:
http://svn.apache.org/viewvc/geronimo/server/branches/2.1/assemblies/geronimo-boilerplate-minimal/pom.xml?rev=677660r1=677659r2=677660view=diff
==
---
geronimo/server/branches/2.1/assemblies/geronimo-boilerplate-minimal/pom.xml
(original)
+++
geronimo/server/branches/2.1/assemblies/geronimo-boilerplate-minimal/pom.xml
Thu Jul 17 11:08:24 2008
@@ -293,6 +293,22 @@
/execution
execution
+phaseprocess-resources/phase
+idcopy-txt-files/id
+goals
+goalrun/goal
+/goals
+configuration
+tasks
+echoCopying README, RELEASE_NOTES,
and DISCLAIMER txt files ${project.basedir}/../.. to underlay -
${project.build.outputDirectory}/contents/echo
+copy file
=${project.basedir}/../../README.txt
todir=${project.build.outputDirectory}/contents failonerror=true
overwrite=true /
+copy file
=${project.basedir}/../../RELEASE_NOTES-2.1.2.txt
todir=${project.build.outputDirectory}/contents failonerror=true
overwrite=true /
+copy file
=${project.basedir}/../../DISCLAIMER.txt
todir=${project.build.outputDirectory}/contents failonerror=true
overwrite=true /
+/tasks
+/configuration
+/execution
+
+execution
idinstall-underlay/id
phaseprocess-classes/phase
goals
[jira] Closed: (GERONIMO-4209) Geronimo does not start on SAP JVM
[ https://issues.apache.org/jira/browse/GERONIMO-4209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods closed GERONIMO-4209. -- Resolution: Fixed Fix Version/s: 2.2 2.1.2 Assignee: Donald Woods r677975 in branches/2.1 (2.1.2-SNAPSHOT) r677976 in trunk (2.2-SNAPSHOT) Geronimo does not start on SAP JVM -- Key: GERONIMO-4209 URL: https://issues.apache.org/jira/browse/GERONIMO-4209 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 2.1.1 Environment: Windows XP 64 SAP JVM 1.5.0_14 Reporter: Markus Ofterdinger Assignee: Donald Woods Priority: Trivial Fix For: 2.1.2, 2.2 Attachments: sap_jvm.fix Original Estimate: 1h Remaining Estimate: 1h I tried to get the Geronimo Application Server 2.1.1 running on a SAP JVM. But the startup fails. I found this error message in the log: Caused by: java.lang.StringIndexOutOfBoundsException: String index out of range: 7 at java.lang.String.substring(String.java:1799) at org.apache.geronimo.system.properties.JvmVendor.clinit(JvmVendor.java:50) ... 25 more At this line a subString(0, 7) is performed on the VM vendor name, but the full vendor name of a SAP JVM contains only 6 characters SAP AG. I did a small fix which adds an additional length check: Index: src/main/java/org/apache/geronimo/system/properties/JvmVendor.java === --- src/main/java/org/apache/geronimo/system/properties/JvmVendor.java (Revision 677904) +++ src/main/java/org/apache/geronimo/system/properties/JvmVendor.java (Arbeitskopie) @@ -47,7 +47,10 @@ boolean bApache = fullVendorName.substring(0, 6).equalsIgnoreCase(Apache);// aka. Apache Harmony boolean bIBM = fullVendorName.substring(0, 3).equalsIgnoreCase(IBM); // aka. IBM, but not IBM Hybrid boolean bSun = !bIBM !bApache; // default all others to Sun -boolean bHP = fullVendorName.substring(0, 7).equalsIgnoreCase(Hewlett); // aka. Hewlett-Packard Company +//boolean bHP = fullVendorName.substring(0, 7).equalsIgnoreCase(Hewlett); // aka. Hewlett-Packard Company +boolean bHP = false; +if (fullVendorName.length() = 7) +bHP = fullVendorName.substring(0, 7).equalsIgnoreCase(Hewlett); // aka. Hewlett-Packard Company boolean bIBMHybrid = false; // Special code for IBM Hybrid SDK (Sun JVM with IBM extensions on Solaris and HP-UX) After applying this fix the app-server started fine. Best regards, Markus Ofterdinger -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Another samples issue ... how much does a user have to build?
In the past we had asserted that a user should be able to pick up an individual sample and build it. Because of a recent change in the samples this is no longer possible (at least not until we release some artifacts that can be downloaded without building locally - see details on the issue below). I personally think it is acceptable to provide some general directions on building samples that require a user (at least the first time) to checkout the entire samples svn tree and build from the top level. It takes about 5 minutes to build all of the samples. Following that initial build a user could choose to build just one sample at a time. We can also provide some more complicated directions for users that have some issue with building all of the samples. If I don't hear any strong objections (along with solutions to the current issue that requires a top level build) then I will go ahead and change the doc accordingly. Specifics on why this is an issue: - We had to add in the building of a tomcat utility (Txt2Html included in buildutil). This is used to generate html from java source and jsp files. The html is then included with the jsp servlet samples and can be displayed when running the samples (we might want to consider this for some of our other samples as well). The utility is run via ant and so we are using the maven-antrun-plugin. When the configuration for the execution of the utility was included in the specific sample it worked great for just that one sample but produced errors when attempting to build from a higher level. This is apparently because of the way the the maven plugin is resolved and loaded. To get the build working from the top level we had to move the dependency of the antrun-plugin on buildutil up under pluginmanagement. However, this has the effect of now requiring buildutil to be available for all samples even if it is not used (since most samples use the antrun-plugin for other purposes). There is a maven issue that describes our problem (and indicates that it is fixed in maven 2.1.* but not 2.0.*) - MNG-1323 (http://jira.codehaus.org/browse/MNG-1323). In addition to the issue above, there are other general build steps required which will benefit from a common build process rather than including them in each sample description. For example, we need to make the svn repository artifacts for the specific server release available in the user's local maven repo. I'd rather not have to include those steps in each sample but rather point to a common build. Thanks, Joe
[jira] Closed: (DAYTRADER-60) .sh files cannot be executed because of CRLF issue
[ https://issues.apache.org/jira/browse/DAYTRADER-60?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods closed DAYTRADER-60. - Resolution: Cannot Reproduce Files in daytrader/trunk are fine. Please make sure you have a svn config file setup - http://cwiki.apache.org/GMOxDEV/subversion-client-configuration.html .sh files cannot be executed because of CRLF issue -- Key: DAYTRADER-60 URL: https://issues.apache.org/jira/browse/DAYTRADER-60 Project: DayTrader Issue Type: Bug Affects Versions: 2.0 Reporter: Xia Ming Priority: Trivial Attachments: daytrader_crlfconvert.patch Three .sh files cannot be executed on unix/linux platforms because of CRLF issue. bin\deploy.sh bin\undeploy.sh bin\dbscripts\derby\createDerbyDB.sh -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMODEVTOOLS-435) Define new server testcase
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim McConnell closed GERONIMODEVTOOLS-435. -- Resolution: Fixed Applied BJ's 259-h patch to create the first abbot-based testcase in the new GEP testsuite. Thanks BJ -- it's working great now Define new server testcase -- Key: GERONIMODEVTOOLS-435 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-435 Project: Geronimo-Devtools Issue Type: Sub-task Components: eclipse-plugin Affects Versions: 2.1.2 Reporter: Tim McConnell Assignee: Tim McConnell Fix For: 2.1.2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMODEVTOOLS-438) Close Welcome pane testcase
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim McConnell closed GERONIMODEVTOOLS-438. -- Resolution: Fixed Fix Version/s: 2.1.2 Applied an update from BJ for the 259-h patch to fix this problem, which went into the . The welcome pane is now closed via abbot in the same manner that an end-user would do so (i.e., via the Eclipse UI). Thanks BJ. Close Welcome pane testcase --- Key: GERONIMODEVTOOLS-438 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-438 Project: Geronimo-Devtools Issue Type: Sub-task Reporter: Tim McConnell Assignee: B.J. Reed Fix For: 2.1.2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4204) Admin Console portlets layout messed up after accessibility changes
[ https://issues.apache.org/jira/browse/GERONIMO-4204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12614827#action_12614827 ] Donald Woods commented on GERONIMO-4204: r677981 - Commented out pluto.css:label for now, as Jack verified there was no prior code using it. This relates to GERONIMO-4081, where label attributes were added to fix our console accessibility. Admin Console portlets layout messed up after accessibility changes --- Key: GERONIMO-4204 URL: https://issues.apache.org/jira/browse/GERONIMO-4204 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.2 Reporter: Shrey Banga Assignee: Shrey Banga Fix For: 2.2 The layout of portlets in Admin Console such as: 1. All application portlets 2. Server Logs 3. Repository is messed up because of a css:float property assigned to labels in pluto.css -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: recent console changes in trunk
Thanks, I modified our copy of pluto.css in trunk to comment out the label definition, until we either merge everything into our main.css or decide just to use this hack as-is. -Donald Jack wrote: I searched the keyword label in all JSP files in an older revision which is before all the accessibility patches came in, and found no occurrences of label element. So I assume it's probably safe to remove the label style in pluto.css. Anyway it's safer if we can use main.css to override pluto.css. I can check this out later on. 2008/7/15 Joe Bohn [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]: YunFeng Ma wrote: I tested the console in FireFox 2.x and IE 6.x after removing label tag in pluto.css and didn't see any problem. I prefer to remove it before G v2.1.2 is out of the door. I agree we want this fixed before we ship 2.1.2. http://2.1.2. However, I'm not sure modifying pluto.css is the best way to go. All of our style sheet changes for the console have typically been restricted to main.css. I think pluto.css is pretty much a direct copy from pluto. It might be easier to maintain if we continue to keep our changes limited to main.css. Can you try fixing this by adding a new label entry in main.css without float:left? Joe smime.p7s Description: S/MIME Cryptographic Signature
Re: Another samples issue ... how much does a user have to build?
On Jul 18, 2008, at 10:35 AM, Joe Bohn wrote: In the past we had asserted that a user should be able to pick up an individual sample and build it. Because of a recent change in the samples this is no longer possible (at least not until we release some artifacts that can be downloaded without building locally - see details on the issue below). I personally think it is acceptable to provide some general directions on building samples that require a user (at least the first time) to checkout the entire samples svn tree and build from the top level. It takes about 5 minutes to build all of the samples. Following that initial build a user could choose to build just one sample at a time. We can also provide some more complicated directions for users that have some issue with building all of the samples. If I don't hear any strong objections (along with solutions to the current issue that requires a top level build) then I will go ahead and change the doc accordingly. I'm fine with this except I don't think we need to provide error-prone instructions that are likely to stop working soon for people who don't want to build all the samples. Specifics on why this is an issue: - We had to add in the building of a tomcat utility (Txt2Html included in buildutil). This is used to generate html from java source and jsp files. The html is then included with the jsp servlet samples and can be displayed when running the samples (we might want to consider this for some of our other samples as well). The utility is run via ant and so we are using the maven-antrun- plugin. When the configuration for the execution of the utility was included in the specific sample it worked great for just that one sample but produced errors when attempting to build from a higher level. This is apparently because of the way the the maven plugin is resolved and loaded. To get the build working from the top level we had to move the dependency of the antrun-plugin on buildutil up under pluginmanagement. However, this has the effect of now requiring buildutil to be available for all samples even if it is not used (since most samples use the antrun-plugin for other purposes). There is a maven issue that describes our problem (and indicates that it is fixed in maven 2.1.* but not 2.0.*) - MNG-1323 (http://jira.codehaus.org/browse/MNG-1323 ). I wonder if we should write a maven plugin to do this text to html conversion? I haven't looked at what is going on or the problem at all. It's hard to believe there is no solution available now. In addition to the issue above, there are other general build steps required which will benefit from a common build process rather than including them in each sample description. For example, we need to make the svn repository artifacts for the specific server release available in the user's local maven repo. I'd rather not have to include those steps in each sample but rather point to a common build. Maybe we should rethink our svn repository strategy. It doesn't really work with the idea of plugins. How about if we do something like shading the tomcat jars to another package and releasing them with our groupId? thanks david jencks Thanks, Joe
Re: Samples for 2.1.2
I like the idea of releasing samples concurrently with the server, so that we don't give us an excuse to not get the samples out in time. I 'd like to see a good set of samples released so that whenever a user has a specific question when developing their apps, we have something to point to. For example the other day, someone on the user list wants to run apps per port, great we have a sample to point to! A few things we want to think about- 1. Identify the duplicate samples and decide what we need to do about them. I am looking closely at the few samples David Jencks has pointed out as duplicate. 2. Identify the relationship between samples and tutorials. I started to see quite a few tutorials out there in our wiki. I think some of them provides duplicate functionalities as the samples in the svn repo. For example, the tutorial has an example for container managed persistence with JPA (http://cwiki.apache.org/GMOxDOC21/container-managed-persistence-with-jpa.html) and we also have a similar sample on this - customer. The tutorial has an example for application managed persistence with JPA (http://cwiki.apache.org/GMOxDOC21/bean-managed-persistence-with-jpa.html) and we have 2 similar samples on this - bank and myphonebook. Personally, I'd like to see the code in svn (no matter if it is tutorial or sample) and delete the duplicate. Lin On Fri, Jul 18, 2008 at 10:32 AM, Joe Bohn [EMAIL PROTECTED] wrote: We already decided to release samples for the upcoming Geronimo 2.1.2 server rather than attempting to release samples for Geronimo 2.1 and figure out how to make them work on 2.1.1 and 2.1.2. So, the next question is when should we release the samples for 2.1.2? My thoughts were to try to get these released a few weeks after our Geronimo 2.1.2 release. However, I've heard some comments that we should consider releasing the Samples for 2.1.2 concurrent with the server 2.1.2 release. This would most likely mean that we would have to delay our target for a 2.1.2 release beyond the end of the month. Regarding sample items that must be completed before we can release ... there are still a number of things ... general cleanup and validation, doc updates, verified functions, archetype, etc... There are also a few more decisions regarding how users would work with the samples that will influence how we structure things (more coming on that soon). You can find a more detailed list on this wiki page: http://cwiki.apache.org/GMOxPMGT/geronimo-samples-212-release-work-items.html Joe
Re: Remove samples myphonebook and mytime?
I agree with David - if two samples are completely duplicate we need to remove one, given the time we need to spend to maintain them in svn and wiki and the fact that the duplicate sample doesn't provide any extra usage. We should divide samples by its functionalities. At the end, the samples are used to demonstrate a particular function, and I don't think 3 entities or 1 entities will make a difference in helping users consume them. It will be annoying to the user if we release two samples with duplicate functions but we fail to update one of them due to lack of time/resource. I looked at bank and myphonebook closely (both are stateless ejb, and application managed persistence context with JPA) thus I think we should remove one of them. mytime and calculator (yes, we changed the name from calculator-stateless-pojo to calculator) are mostly the same too (both are stateless ejb). The only difference is that mytime web client uses JNDI to look up the bean while calculator client uses @EJB annotation to inject the session bean's interface. I don't know if it is worthy to keep them because of the difference here? Lin On Thu, Jun 12, 2008 at 1:41 PM, David Jencks [EMAIL PROTECTED] wrote: I think you , joe, donald, and hernan are being completely unrealistic about the likelihood of these samples being maintained even if they get updated and the value they add and the potential for total confusion for users when they see a bunch of samples doing exactly the same thing. Before suggesting removing them I considered the overlap. Let me restate the extent of overlap: bank has 3 entities, myphonebook has one. To me this is 100% overlap mytime and calculator-stateless both demonstrate a stateless ejb with no connection to the outside world. Again to me this is 100% overlap. Rather than spending our non-existent energy maintaining a bunch of badly written samples that do exactly the same thing I'd rather see some faintly more realistic samples with a broader range such as an ejb that sends jms messages and a jsf sample. There's also a lot of room for improvements in the samples I think we should keep such as: - having the web client in a different war than the jaxws service in the jaxws example - having an ejb that sends messages in the jms example, probably in a different ejb jar. - actually saving the new users in the timereport jar. I'd recommend using jpa here. This would be an example of using jpa from the web tier, currently missing IIUC. - demonstrating switching datasources Although bank and customer-service are pretty similar, I haven't recommended removing one because I modified customer-service to demonstrate container managed persistence contexts and left bank demonstrating application managed persistence contexts. I am not going to work on these two samples so if you really want to keep them please divvy up the work and update them and their documentation. My understanding is that Joe would like to get the samples released fairly soon. thanks david jencks On Jun 11, 2008, at 11:52 PM, Jacek Laskowski wrote: On Thu, Jun 12, 2008 at 2:18 AM, David Jencks [EMAIL PROTECTED] wrote: I'd like to remove the myphonebook and mytime samples. AFAICT they duplicate functionality demonstrated in bank. mytime has a web app accessing a stateless ejb myphonebook has a web app accessing a stateless ejb that uses a single jpa entity (with an application managed persistence context) bank has a web app accessing a stateless ejb that uses 3 jpa entities (although they aren't implemented well) using application managed persistence context customer-service has a web app accessing a stateless ejb that uses one jpa entity using a container managed persistence context. Any objections? Yup! Let's keep them till they're fixed and once they are we could notice their value (I know it sounds weird, but they're pretty small to digest for novices and that's their major value). Let me take a look at them, okey? Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl
[jira] Resolved: (GERONIMODEVTOOLS-427) Invalid text in generated geronimo-application-client.xml
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim McConnell resolved GERONIMODEVTOOLS-427. Resolution: Fixed Closing -- applied BJ's patch with revision 678032. Invalid text in generated geronimo-application-client.xml - Key: GERONIMODEVTOOLS-427 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-427 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.1.1 Reporter: Tim McConnell Assignee: B.J. Reed Fix For: 2.1.2 Attachments: GERONIMODEVTOOLS-427.patch The following text is in the automatically generated geronimo-application-client.xml and must be manually deleted name:service-ref name:service-ref-nameServiceRefName/name:service-ref-name /name:service-ref -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Remove samples myphonebook and mytime?
Lin Sun wrote: I agree with David - if two samples are completely duplicate we need to remove one, given the time we need to spend to maintain them in svn and wiki and the fact that the duplicate sample doesn't provide any extra usage. We should divide samples by its functionalities. At the end, the samples are used to demonstrate a particular function, and I don't think 3 entities or 1 entities will make a difference in helping users consume them. It will be annoying to the user if we release two samples with duplicate functions but we fail to update one of them due to lack of time/resource. I don't think users have ever been annoyed because we provided too many samples. However, I agree that if we keep them we must ensure that they are functional and documented. Is there some issue with functionality/doc of the mytime or myphonebook samples? If they are updated and functional (which I have validated that they are) then I think we should go ahead and release them. If they do fall behind on a future release we can decide at that time if it is a better use of our time to remove them rather than update them. However, for 2.1.2 I think the maintenance issue is a moot argument. I looked at bank and myphonebook closely (both are stateless ejb, and application managed persistence context with JPA) thus I think we should remove one of them. Ok, so if there isn't any difference between the 3 entities and 1 entity ... and we really want to eliminate duplication ... then let's remove the sample with 3 entities (bank). The original proposal here was to remove the sample with 1 entity (myphonebook). The sample with 1 entity was added as a very simple sample and, IIRC it was added after we had the 3 entity sample. So, it would seem there was already a case where a user was confused by 3 entities vs. 1 and hence the 1 entity sample was created. Also, it will be easier to maintain and update the sample with 1 entity in the future rather than 3 if your primary argument is the work involved in maintenance. One other thought on bank ... I wonder if it was envisioned as growing into a more complex sample and it just never grew-up. If we somehow decide to keep bank but remove myphonebook then I hope we can put something in place to prevent a simple sample from growing too complex. The thing I like about myphonebook and mytime is that they were created with the idea of being very simple and nothing else. mytime and calculator (yes, we changed the name from calculator-stateless-pojo to calculator) are mostly the same too (both are stateless ejb). The only difference is that mytime web client uses JNDI to look up the bean while calculator client uses @EJB annotation to inject the session bean's interface. I don't know if it is worthy to keep them because of the difference here? Here again, if we don't want to keep both, then let's remove the sample that is less common and/or more complex. I'm not sure which that is but the mytime sample was added long after calculator and the motivation for adding it was the need for a very simple example. Perhaps calculator has been simplified over time or perhaps it never grew-up either. But it seems that it didn't meet the need when mytime was first introduced. I wonder what has changed since then? Lin On Thu, Jun 12, 2008 at 1:41 PM, David Jencks [EMAIL PROTECTED] wrote: I think you , joe, donald, and hernan are being completely unrealistic about the likelihood of these samples being maintained even if they get updated and the value they add and the potential for total confusion for users when they see a bunch of samples doing exactly the same thing. Before suggesting removing them I considered the overlap. Let me restate the extent of overlap: bank has 3 entities, myphonebook has one. To me this is 100% overlap mytime and calculator-stateless both demonstrate a stateless ejb with no connection to the outside world. Again to me this is 100% overlap. Rather than spending our non-existent energy maintaining a bunch of badly written samples that do exactly the same thing I'd rather see some faintly more realistic samples with a broader range such as an ejb that sends jms messages and a jsf sample. There's also a lot of room for improvements in the samples I think we should keep such as: - having the web client in a different war than the jaxws service in the jaxws example - having an ejb that sends messages in the jms example, probably in a different ejb jar. - actually saving the new users in the timereport jar. I'd recommend using jpa here. This would be an example of using jpa from the web tier, currently missing IIUC. - demonstrating switching datasources Although bank and customer-service are pretty similar, I haven't recommended removing one because I modified customer-service to demonstrate container managed persistence contexts and left bank demonstrating application managed persistence contexts.
[jira] Updated: (GERONIMODEVTOOLS-208) Always appends default value into Server VM Arguments field after modifying this field.
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] B.J. Reed updated GERONIMODEVTOOLS-208: --- Attachment: GERONIMODEVTOOLS-208.patch The original patch is good, but the code has changed locations since it was created. This patch has the code change in the new place. Always appends default value into Server VM Arguments field after modifying this field. --- Key: GERONIMODEVTOOLS-208 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-208 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.0.0 Reporter: Kan Ogawa Assignee: Tim McConnell Attachments: GD-208.patch, GERONIMODEVTOOLS-208.patch Assumes that the following value is set in Server VM Arguments field now: - start - -javaagent:C:/Apache/Geronimo/2.0.1/bin/jpa.jar -Djava.ext.dirs=C:/Apache/Geronimo/2.0.1/lib/ext;C:\Program Files\Java\jdk1.5.0_11\jre\lib\ext -Djava.endorsed.dirs=C:/Apache/Geronimo/2.0.1/lib/endorsed;C:\Program Files\Java\jdk1.5.0_11\jre\lib\endorsed - end - ( NOTE: C:\Program Files\Java\jdk1.5.0_11 is JAVA_HOME. And C:/Apache/Geronimo/2.0.1 is GERONIMO_HOME. ) Issue scenario: 1. Opens Geronimo 2.0 Server in Servers view. 2. Inputs the following value to head of Server VM Arguments field. -server 3. Saves and closes Geronimo 2.0 Server overview page. 4. Reopens Geronimo 2.0 Server in Servers view. 5. Displays the following value in Server VM Arguments field. - start - -javaagent:C:/Apache/Geronimo/2.0.1/bin/jpa.jar -Djava.ext.dirs=C:/Apache/Geronimo/2.0.1/lib/ext;C:\Program Files\Java\jdk1.5.0_11\jre\lib\ext -Djava.endorsed.dirs=C:/Apache/Geronimo/2.0.1/lib/endorsed;C:\Program Files\Java\jdk1.5.0_11\jre\lib\endorsed -server -javaagent:C:/Apache/Geronimo/2.0.1/bin/jpa.jar -Djava.ext.dirs=C:/Apache/Geronimo/2.0.1/lib/ext;C:\Program Files\Java\jdk1.5.0_11\jre\lib\ext -Djava.endorsed.dirs=C:/Apache/Geronimo/2.0.1/lib/endorsed;C:\Program Files\Java\jdk1.5.0_11\jre\lib\endorsed - end - -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMODEVTOOLS-135) WTP server adapter creates wrong security markup
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] B.J. Reed resolved GERONIMODEVTOOLS-135. Resolution: Fixed This looks like it has been fixed with the updates to use JAXB. If this is still an issue, please re-open. WTP server adapter creates wrong security markup Key: GERONIMODEVTOOLS-135 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-135 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.1.x Environment: Rational Software Architect v7 Eclipse WTP server adapter V1.1 WASCE V1.1.0.1 java version 1.5.0 Java(TM) 2 Runtime Environment, Standard Edition (build pwi32devifx-20061016 (ifix 110599: SR3 + 109 092)) IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Windows XP x86-32 j9vmwi3223ifx-20061016 (JIT enabled) J9VM - 20061012_08722_lHdSMR JIT - 20060908_1811ifx1_r8 GC - 20060906_AA) JCL - 20061002 Reporter: Daniel S. Haischt Assignee: Tim McConnell Fix For: 2.1.x After having added a security role to geronimo-web.xml using the Eclipse deployment plan editor, I am getting the following error: Caused by: org.apache.xmlbeans.XmlException: Invalid deployment descriptor: [error: cvc-complex-type.2.4a: Expected elements ... Deployment Plan: ?xml version=1.0 encoding=UTF-8? web-app xmlns=http://geronimo.apache.org/xml/ns/j2ee/web-1.1; xmlns:nam=http://geronimo.apache.org/xml/ns/naming-1.1; xmlns:sec=http://geronimo.apache.org/xml/ns/security-1.1; xmlns:sys=http://geronimo.apache.org/xml/ns/deployment-1.1; sys:environment sys:moduleId sys:groupIddefault/sys:groupId sys:artifactIdMYARTIFACT/sys:artifactId sys:version1.0/sys:version sys:typecar/sys:type /sys:moduleId /sys:environment context-root/mymoduleWAR/context-root sec:security sec:role-mappings sec:role role-name=myconfig sec:descriptionmyconfig/sec:description /sec:role /sec:role-mappings /sec:security /web-app -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMODEVTOOLS-130) Geronimo service projects don't deploy
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] B.J. Reed resolved GERONIMODEVTOOLS-130. Resolution: Won't Fix The decision was made in GERONIMODEVTOOLS-427 to remove support for the utility projects. Any code that deals with this xml has been removed. Geronimo service projects don't deploy -- Key: GERONIMODEVTOOLS-130 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-130 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.1.x Environment: Eclipse 3.2.1; WST 1.5.2.v200610070620-X3Tmm8_VLz2EcCH; JST 1.5.2.v200610070620-kW-OA1vfaZTJtXg Reporter: Chris Curtis Assignee: Tim McConnell Fix For: 2.1.x Geronimo service projects (created as J2EE utility projects, with a geronimo-service.xml deployment plan) do not actually deploy into a running Geronimo server. The Server pane shows the service as deployed, and the normal synchronized/republish state tracking appears to work, but nothing actually happens in Geronimo itself. There appears to be an edit that addressed this issue (http://svn.apache.org/viewvc?view=revrevision=417199) but I'm not an Eclipse internals wizard. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMODEVTOOLS-231) Allow runtimes to be named
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] B.J. Reed resolved GERONIMODEVTOOLS-231. Resolution: Fixed Fix Version/s: 2.1.x I believe that this has been fixed with some recent changes. Please validate. If you still see this problem, please re-open. Allow runtimes to be named -- Key: GERONIMODEVTOOLS-231 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-231 Project: Geronimo-Devtools Issue Type: Improvement Components: eclipse-plugin Affects Versions: 2.0.2, 2.0.x, 2.1.0, 2.1.x Reporter: Ted Kirby Assignee: Tim McConnell Fix For: 2.1.x Currently, an installed Geronimo Runtime is named Apache Geronimo v2.0. If you want to install another runtime, say for Jetty if the first one is for Tomcat, it gets named Apache Geronimo v2.0 2. You have no choice in the runtime time. A server is named Apache Geronimo v2.0 Server at localhost. You don't have a choice here either (except for host name), but you can change the name later, by double-clicking the server in the Servers View, and changing the name. There is similar capability for a installed runtime. Steps to install a Jetty runtime after a Tom runtime is already installed: 1. From Servers view, right-click new-server 2. Click installed runtimes button 3. Click Add... button 4. Select server type (Apache Geronimo v2.0) and click Next 5. Choose directory (optionally select Jetty click Download and Install button) and click Next. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Another samples issue ... how much does a user have to build?
David Jencks wrote: On Jul 18, 2008, at 10:35 AM, Joe Bohn wrote: In the past we had asserted that a user should be able to pick up an individual sample and build it. Because of a recent change in the samples this is no longer possible (at least not until we release some artifacts that can be downloaded without building locally - see details on the issue below). I personally think it is acceptable to provide some general directions on building samples that require a user (at least the first time) to checkout the entire samples svn tree and build from the top level. It takes about 5 minutes to build all of the samples. Following that initial build a user could choose to build just one sample at a time. We can also provide some more complicated directions for users that have some issue with building all of the samples. If I don't hear any strong objections (along with solutions to the current issue that requires a top level build) then I will go ahead and change the doc accordingly. I'm fine with this except I don't think we need to provide error-prone instructions that are likely to stop working soon for people who don't want to build all the samples. I'm fine with eliminating the more complicated directions. Specifics on why this is an issue: - We had to add in the building of a tomcat utility (Txt2Html included in buildutil). This is used to generate html from java source and jsp files. The html is then included with the jsp servlet samples and can be displayed when running the samples (we might want to consider this for some of our other samples as well). The utility is run via ant and so we are using the maven-antrun-plugin. When the configuration for the execution of the utility was included in the specific sample it worked great for just that one sample but produced errors when attempting to build from a higher level. This is apparently because of the way the the maven plugin is resolved and loaded. To get the build working from the top level we had to move the dependency of the antrun-plugin on buildutil up under pluginmanagement. However, this has the effect of now requiring buildutil to be available for all samples even if it is not used (since most samples use the antrun-plugin for other purposes). There is a maven issue that describes our problem (and indicates that it is fixed in maven 2.1.* but not 2.0.*) - MNG-1323 (http://jira.codehaus.org/browse/MNG-1323). I wonder if we should write a maven plugin to do this text to html conversion? I haven't looked at what is going on or the problem at all. It's hard to believe there is no solution available now. In addition to the issue above, there are other general build steps required which will benefit from a common build process rather than including them in each sample description. For example, we need to make the svn repository artifacts for the specific server release available in the user's local maven repo. I'd rather not have to include those steps in each sample but rather point to a common build. Maybe we should rethink our svn repository strategy. It doesn't really work with the idea of plugins. How about if we do something like shading the tomcat jars to another package and releasing them with our groupId? I think it would be great if we could release these images under some other package so that they can be downloaded. However, I wonder if there are dependencies that might be broken if we did something like that (I mean apart from dependencies we create). At the moment we only change the version # for our artifacts so any reference from poms would not be affected unless the version number itself was included in the reference. thanks david jencks Thanks, Joe
