Re: svn commit: r378746 - /geronimo/trunk/etc/project.properties
Was there a particular reason why we are upgrading the version (not that I have a problem with it)? IMHO we should have a JIRA for this so it is clear to users it was upgraded in the release notes. Regards, John [EMAIL PROTECTED] wrote: Author: jgenender Date: Sat Feb 18 10:02:03 2006 New Revision: 378746 URL: http://svn.apache.org/viewcvs?rev=378746view=rev Log: Update to Tomcat 5.5.15 Modified: geronimo/trunk/etc/project.properties Modified: geronimo/trunk/etc/project.properties URL: http://svn.apache.org/viewcvs/geronimo/trunk/etc/project.properties?rev=378746r1=378745r2=378746view=diff == --- geronimo/trunk/etc/project.properties (original) +++ geronimo/trunk/etc/project.properties Sat Feb 18 10:02:03 2006 @@ -141,7 +141,7 @@ howl_version=0.1.11 #security: hsqldb_version=1.7.2.2 -jasper_version=5.5.12 +jasper_version=5.5.15 javacc_version=2.1 jdbm_version=0.20-dev jdom_version=1.0 @@ -170,8 +170,8 @@ standard_taglibs_version=1.1.1 stax_version=1.1.1-dev stax_api_version=1.0 -tomcat_ajp_version=5.5.12 -tomcat_version=5.5.12 +tomcat_ajp_version=5.5.15 +tomcat_version=5.5.15 tomcat_servlet_examples_version=5.5.15 tomcat_jsp_examples_version=5.5.15 backport_util_concurrent_version=2.0_01_pd
Re: Migrating to maven 2
2006/2/20, Alan D. Cabrera [EMAIL PROTECTED]: Does the entire system need to build using a single command for this interim conversion? Why not have people do a mvn install maven new The mvn install will build both maven 1 and 2 jars. The maven new will use the maven 1 jars. Very good idea, but the real PITA is not how to build Geronimo using M1 *and* M2, but how to minimize the redundancy of information in their respective files, cf dependencies. I'll be writing about it in minutes. Gotta run now... Alan Jacek -- Jacek Laskowski http://www.laskowski.org.pl
Re: svn commit: r378746 - /geronimo/trunk/etc/project.properties
2006/2/20, John Sisson [EMAIL PROTECTED]: IMHO we should have a JIRA for this so it is clear to users it was upgraded in the release notes. +1 Any major upgrade, refactoring, etc. ought to have its JIRA item so that the release mgmt is much, much easier with JIRA. John Jacek -- Jacek Laskowski http://www.laskowski.org.pl
[M2] Failing *one* test in the kernel module
Hi, Over the weekend I tried to convert a module to execute M2 from within M1, i.e. usig the concept of exec'ing M2 in maven.xml. It works fine, but there's one caveat (well, there might be more than one, but that's the most irritating). In revision 379071 I've just committed, you can execute M2 commands over a single module. This is done using the M2 concept of profiles where you can tweak how the commands are executed, etc. This is defined in the main pom.xml in the root of Geronimo's sources. Whenever you run any M2 command from within the root of the sources with the module property set, the singlemodule profile is activated and only the module pointed out by the property is taken into account. Without the property all modules are processed. As an example run: mvn -Dmodule=kernel test That's the command that took my whole weekend away and I'm still stuck with no idea how to work it out :( It seems that I chose one of the worst modules to convert (as it was with the class I used in my tests right after Dave wiped it out ;)). Before I leave it out and move on to another module, I'll describe what I found out so far wrt the failing org.apache.geronimo.gbean.GBeanNameTest test of the kernel module. Here's the snippet of the test report: $ more modules/kernel/target/surefire-reports/org.apache.geronimo.gbean.GBeanNameTest.txt ... java.net.MalformedURLException: no protocol: and at java.net.URL.init(URL.java:537) at java.net.URL.init(URL.java:434) at java.net.URL.init(URL.java:383) at sun.rmi.server.LoaderHandler.pathToURLs(LoaderHandler.java:747) at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:147) at java.rmi.server.RMIClassLoader$2.loadClass(RMIClassLoader.java:631) at java.rmi.server.RMIClassLoader.loadClass(RMIClassLoader.java:257) at sun.rmi.server.MarshalInputStream.resolveClass(MarshalInputStream.java:200) at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1513) at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1435) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1626) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1274) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:324) at java.rmi.MarshalledObject.get(MarshalledObject.java:135) at org.apache.geronimo.gbean.GBeanNameTest.testSerialization(GBeanNameTest.java:168) Chances are it won't happen on operating systems (MacOS, *nix) that their user home directories, thus Maven repo, have on paths without spaces. That's where the 'and' comes from - on Windows it's c:/Documents and Settings/account/.m2. The question is why it fails on M2, but M1 works fine. It is because the test machinery changed a little in M2 and now surefire is used. I think it's a brand new test solution in Maven2, but it might be that it's based on M1 test plugin somehow. Anyway, the following commands let you step over and see yourself what's going on behind the scenes. For Maven2 (run it off the top directory): MAVEN_OPTS=-Xdebug -Xrunjdwp:transport=dt_socket,server=y,address=8000 mvn -o -Dmodule=kernel clean test For Maven1 (run it off the module/kernel directory): MAVEN_OPTS=-Xdebug -Xrunjdwp:transport=dt_socket,server=y,address=8000 maven -o clean test:test According to http://java.sun.com/j2se/1.4.2/docs/api/java/rmi/MarshalledObject.html, during the serialization (MarshalledObject.get) an object is annotated with information that's necessary for deserialization. Upon closer look, during debugging session, I've noticed that java.rmi.server.RMIClassLoader is provided with the value of null for codebase parameter in Maven1 while codebase is set to the entire test classpath in M2. Since it contains entires separated with spaces, any directory with spaces is divided inappropriately leading to the above exception. Is there anyone who could lend me a hand and sort it out? Should I find for help in the [EMAIL PROTECTED] mailing list? Brett, Jason, Vincent - could you help with it? Jacek (utterly frustrated by not achieving at least a partial success with M2 after the *whole* weekend) -- Jacek Laskowski http://www.laskowski.org.pl
Re: [M2] Failing *one* test in the kernel module
Jacek Laskowski wrote: Hi, snip Here's the snippet of the test report: $ more modules/kernel/target/surefire-reports/org.apache.geronimo.gbean.GBeanNameTest.txt ... java.net.MalformedURLException: no protocol: and at java.net.URL.init(URL.java:537) at java.net.URL.init(URL.java:434) at java.net.URL.init(URL.java:383) snip According to http://java.sun.com/j2se/1.4.2/docs/api/java/rmi/MarshalledObject.html, during the serialization (MarshalledObject.get) an object is annotated with information that's necessary for deserialization. Upon closer look, during debugging session, I've noticed that java.rmi.server.RMIClassLoader is provided with the value of null for codebase parameter in Maven1 while codebase is set to the entire test classpath in M2. Since it contains entires separated with spaces, any directory with spaces is divided inappropriately leading to the above exception. Is there anyone who could lend me a hand and sort it out? Should I find for help in the [EMAIL PROTECTED] mailing list? Brett, Jason, Vincent - could you help with it? As a work-around, I have committed the reset of the RMI code base property prior to use MarshalledObject. Thanks, Gianny Jacek (utterly frustrated by not achieving at least a partial success with M2 after the *whole* weekend) -- Jacek Laskowski http://www.laskowski.org.pl
[jira] Created: (GERONIMO-1640) Upgrade to Tomcat 5.5.15
Upgrade to Tomcat 5.5.15 Key: GERONIMO-1640 URL: http://issues.apache.org/jira/browse/GERONIMO-1640 Project: Geronimo Type: Improvement Components: Tomcat Versions: 1.0 Reporter: Jeff Genender Assigned to: Jeff Genender Priority: Critical Fix For: 1.x Upgrading to Tomcat 5.5.15 due to bug in 5.5.12. WIll keep this issue open for a while to track issues. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: svn commit: r378746 - /geronimo/trunk/etc/project.properties
John Sisson wrote: Was there a particular reason why we are upgrading the version (not that I have a problem with it)? Yes, because it was currently at 5.5.12 in HEAD which is a broken release and it was discussed that 5.5.15 contains the fix. HEAD was never downgraded to 5.5.9 and was left as-is in hopes of a work-around or fix. It was agreed upon that as soon as 5.5.15 was officially released and was available via ibiblio, that we would upgrade. Sorry if this wasn't clarified in this list...maybe too much IRC and separate lists being used (yeah I know...should keep it on this list). IMHO we should have a JIRA for this so it is clear to users it was upgraded in the release notes. http://issues.apache.org/jira/browse/GERONIMO-1640 Regards, John [EMAIL PROTECTED] wrote: Author: jgenender Date: Sat Feb 18 10:02:03 2006 New Revision: 378746 URL: http://svn.apache.org/viewcvs?rev=378746view=rev Log: Update to Tomcat 5.5.15 Modified: geronimo/trunk/etc/project.properties Modified: geronimo/trunk/etc/project.properties URL: http://svn.apache.org/viewcvs/geronimo/trunk/etc/project.properties?rev=378746r1=378745r2=378746view=diff == --- geronimo/trunk/etc/project.properties (original) +++ geronimo/trunk/etc/project.properties Sat Feb 18 10:02:03 2006 @@ -141,7 +141,7 @@ howl_version=0.1.11 #security: hsqldb_version=1.7.2.2 -jasper_version=5.5.12 +jasper_version=5.5.15 javacc_version=2.1 jdbm_version=0.20-dev jdom_version=1.0 @@ -170,8 +170,8 @@ standard_taglibs_version=1.1.1 stax_version=1.1.1-dev stax_api_version=1.0 -tomcat_ajp_version=5.5.12 -tomcat_version=5.5.12 +tomcat_ajp_version=5.5.15 +tomcat_version=5.5.15 tomcat_servlet_examples_version=5.5.15 tomcat_jsp_examples_version=5.5.15 backport_util_concurrent_version=2.0_01_pd
Re: svn commit: r378746 - /geronimo/trunk/etc/project.properties
Jacek Laskowski wrote: 2006/2/20, John Sisson [EMAIL PROTECTED]: IMHO we should have a JIRA for this so it is clear to users it was upgraded in the release notes. +1 Any major upgrade, refactoring, etc. ought to have its JIRA item so that the release mgmt is much, much easier with JIRA. Yeah but this is not a major upgrade or refactoring. Its a bug fix release from Tomcat (note the revision number) that fixes one minor bug. Regardless, I agree that it should be in JIRA...so it is. John Jacek -- Jacek Laskowski http://www.laskowski.org.pl
[jira] Unassigned Patches: week of 02-20-2006
Project: Apache Geronimo Status: Open Assignee: Unassigned Geronimo Info: Patch Available Total: 20 items DATE UPDATED KEY SUMMARY Dec 18 2005 - GERONIMO-1381 - [Daytrader] Removed unused code Dec 22 2005 - GERONIMO-1400 - modularize daytrader deployment plan Jan 3 2006 - GERONIMO-1413 - Console needs to set JSP and Servlet contentType to UTF-8 Jan 3 2006 - GERONIMO-1414 - Console About page does not set the shortcut icon Jan 4 2006 - GERONIMO-1418 - allow user to specify deployment targets by nickname Jan 6 2006 - GERONIMO-1392 - update additional samples redirect in geronimo website Jan 8 2006 - GERONIMO-1260 - simplify construction of the combined deployment plan: deployment plan template and preprocessor Jan 9 2006 - GERONIMO-1163 - improve jmx debug console Jan 14 2006 - GERONIMO-1453 - GBeanOverride throws NullPointerException when more than one reference element specified Jan 19 2006 - GERONIMO-1498 - DriverDownloader.DriverInfo causes java.io.NotSerializableException during server shutdown Jan 19 2006 - GERONIMO-1499 - Daytrader: uncomment the drop table statements in daytrader.sql Jan 19 2006 - GERONIMO-1501 - Daytrader: remove hardcoded dependency versions in project.xml Jan 23 2006 - GERONIMO-1534 - Daytrader: ejb-ql-compiler-factory element is wrong for DB2 or Oracle db Jan 26 2006 - GERONIMO-1037 - Clicking on uninstall link in Applications management pages deletes the configuration without any confirmation from user Jan 27 2006 - GERONIMO-1341 - POP3 Implementation Jan 30 2006 - GERONIMO-1503 - keystore generated by KeyStore portlet could not be used to add either Jetty or Tomcat HTTPS Listeners Feb 9 2006 - GERONIMO-1531 - KeyStore portlet should support deletion of certificates and private keys Feb 13 2006 - GERONIMO-1623 - Preliminary port of the OpenWire C# into C++. Feb 15 2006 - GERONIMO-1518 - Installer - only copy jars needed by selected configuration Feb 16 2006 - GERONIMO-1634 - NoClassDefFoundError from Derby Log Viewer
Re: [M2] Failing *one* test in the kernel module
2006/2/20, Gianny Damour [EMAIL PROTECTED]: As a work-around, I have committed the reset of the RMI code base property prior to use MarshalledObject. Hi Gianny, Thanks for the help! It doesn't work for me, though :( [EMAIL PROTECTED] /cygdrive/c/oss/geronimo $ svn up Umodules/kernel/src/test/org/apache/geronimo/gbean/GBeanNameTest.java Updated to revision 379110. [EMAIL PROTECTED] /cygdrive/c/oss/geronimo/modules/kernel $ maven -o clean test:test ... test:compile: [javac] Compiling 21 source files to C:\oss\geronimo\modules\kernel\target\test-classes [javac] C:\oss\geronimo\modules\kernel\src\test\org\apache\geronimo\gbean\GBeanNameTest.java:171: cannot resolve symbol [javac] symbol : method clearProperty (java.lang.String) [javac] location: class java.lang.System [javac] System.clearProperty(codeBaseProperty); [javac] ^ [javac] 1 error ... [EMAIL PROTECTED] /cygdrive/c/oss/geronimo/modules/kernel $ java -version java version 1.4.2_10 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_10-b03) Java HotSpot(TM) Client VM (build 1.4.2_10-b03, mixed mode) Gianny Jacek -- Jacek Laskowski http://www.laskowski.org.pl
Re: [M2] Failing *one* test in the kernel module
Jacek Laskowski wrote: 2006/2/20, Gianny Damour [EMAIL PROTECTED]: As a work-around, I have committed the reset of the RMI code base property prior to use MarshalledObject. Hi Gianny, Thanks for the help! It doesn't work for me, though :( [EMAIL PROTECTED] /cygdrive/c/oss/geronimo $ svn up Umodules/kernel/src/test/org/apache/geronimo/gbean/GBeanNameTest.java Updated to revision 379110. [EMAIL PROTECTED] /cygdrive/c/oss/geronimo/modules/kernel $ maven -o clean test:test ... test:compile: [javac] Compiling 21 source files to C:\oss\geronimo\modules\kernel\target\test-classes [javac] C:\oss\geronimo\modules\kernel\src\test\org\apache\geronimo\gbean\GBeanNameTest.java:171: cannot resolve symbol [javac] symbol : method clearProperty (java.lang.String) [javac] location: class java.lang.System [javac] System.clearProperty(codeBaseProperty); Sorry for that - clearProperty has only been introduced in 1.5. (I need to downgrade to 1.4 while working with G.) This is now fixed. Thanks, Gianny
Re: Migrating to maven 2
I would like to migrate tomcat and tomcat-builder if it is not already taken? Thanks Anita --- Jacek Laskowski [EMAIL PROTECTED] wrote: 2006/2/20, Gianny Damour [EMAIL PROTECTED]: I think that this has already been suggested by David J.: we add a goal, e.g. new000, which is executed between new00 and new1. new000 launches mvn install in the root project directory. We add to the excludes list of new1 the migrated modules (we could also remove the M1 project files after migration). It's an excellent idea and to let others work towards it, I've just committed a change to the top-level pom.xml that let you execute a single module, just to see if it works before executing it from the main build. If everyone agrees on the above, then let's start this migration :) - +1 (btw, I thought the migration was on its way for a week or so ;)) and I also volunteer to do the migration. Welcome on board! AFAIK, there 4 people who're working on it - you, Anders, Prasad and me. With 2 committers and 2 non-committers it should be pretty straighforward ;) Before you touch a module, please drop a line. Gianny Jacek -- Jacek Laskowski http://www.laskowski.org.pl __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Build tools: Groovy scripts
On 20 Feb 2006, at 09:05, Mats Forslöf wrote: Hi, According to the source in module openwire-dotnet the commands are auto generated via a set of Grovvy scripts located in the activemq- openwire module. It would be nice to do the same for the openwire- cpp commands - anyone that knows where the scripts are, can't find them? BTW I'm just in the process of refactoring those scripts a little to make it easier to reuse the same code across C++ and C# (along with making the scripts a little easier to understand). I've recently tried to auto-create some unit tests for Java want to make those reusable across C++ and C# too... The scripts are here... http://svn.apache.org/repos/asf/incubator/activemq/trunk/activemq- core/src/gram/script/ James --- http://radio.weblogs.com/0112098/
Re: Migrating to maven 2
2006/2/20, anita kulshreshtha [EMAIL PROTECTED]: I would like to migrate tomcat and tomcat-builder if it is not already taken? AFAIK, it is not. Go for it! Create a JIRA task item. Attach it to http://issues.apache.org/jira/browse/GERONIMO-851 and go ahead. Anita Jacek -- Jacek Laskowski http://www.laskowski.org.pl
[jira] Commented: (GERONIMO-1035) tomcat integration should wrap each servlet indiviudally
[
http://issues.apache.org/jira/browse/GERONIMO-1035?page=comments#action_12367032
]
Jeff Genender commented on GERONIMO-1035:
-
The management patch fails on the compile...looks like its missing something?
java:compile:
depend closure=false srcdir=1.4 dump=false
destdir=/Users/powerbook/Projects/geronimo/modules/management/target/classes/depend
[echo] Compiling to
/Users/powerbook/Projects/geronimo/modules/management/target/classes
[javac] Compiling 3 source files to
/Users/powerbook/Projects/geronimo/modules/management/target/classes
[javac]
/Users/powerbook/Projects/geronimo/modules/management/src/java/org/apache/geronimo/management/stats/WebModuleStatsImpl.java:19:
cannot resolve symbol
[javac] symbol : class WebModuleStats
[javac] location: package stats
[javac] import org.apache.geronimo.management.geronimo.stats.WebModuleStats;
[javac] ^
[javac]
/Users/powerbook/Projects/geronimo/modules/management/src/java/org/apache/geronimo/management/stats/WebModuleStatsImpl.java:31:
cannot resolve symbol
[javac] symbol : class WebModuleStats
[javac] location: class
org.apache.geronimo.management.stats.WebModuleStatsImpl
[javac] public class WebModuleStatsImpl extends StatsImpl implements
WebModuleStats {
[javac] ^
[javac] 2 errors
tomcat integration should wrap each servlet indiviudally
Key: GERONIMO-1035
URL: http://issues.apache.org/jira/browse/GERONIMO-1035
Project: Geronimo
Type: New Feature
Components: Tomcat
Versions: 1.0-M5
Environment: All
Reporter: Anita Kulshreshtha
Assignee: Jeff Genender
Fix For: 1.1
Attachments: geronimo-stats-1.1-SNAPSHOT.war, management.patch, stats.zip,
tomcat-builder.patch, tomcat-builder.patch, tomcat-builder.patch,
tomcat-builder.patch, tomcat.patch, tomcat.patch
TomcatModuleBuilder should wrap each servlet specified in the deployment
descriptor individually. This is needed by JSR-77 and for gathering tomcat
internal statistics.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Re: [M2] Failing *one* test in the kernel module
2006/2/20, Gianny Damour [EMAIL PROTECTED]: I am rewritten the test to perform a standard serialization w/o the annotation mechanism. Whoohooo! It works now. You're the man! $ mvn -Dmodule=kernel clean test [INFO] [INFO] Reactor Summary: [INFO] [INFO] Geronimo ... SUCCESS [1.102s] [INFO] Geronimo :: Kernel . SUCCESS [11.877s] [INFO] [INFO] [INFO] BUILD SUCCESSFUL [INFO] The lesson learnt - the next time I'll see such annoying error I'll rewrite the test instead of wasting time fixing the build. Thanks again! Gianny Jacek -- Jacek Laskowski http://www.laskowski.org.pl
Re: [jira] Commented: (GERONIMO-1035) tomcat integration should wrap each servlet indiviudally
I am looking into it. Will get get back to you
soon.
Thanks
Anita
--- Jeff Genender (JIRA) dev@geronimo.apache.org
wrote:
[
http://issues.apache.org/jira/browse/GERONIMO-1035?page=comments#action_12367032
]
Jeff Genender commented on GERONIMO-1035:
-
The management patch fails on the compile...looks
like its missing something?
java:compile:
depend closure=false srcdir=1.4 dump=false
destdir=/Users/powerbook/Projects/geronimo/modules/management/target/classes/depend
[echo] Compiling to
/Users/powerbook/Projects/geronimo/modules/management/target/classes
[javac] Compiling 3 source files to
/Users/powerbook/Projects/geronimo/modules/management/target/classes
[javac]
/Users/powerbook/Projects/geronimo/modules/management/src/java/org/apache/geronimo/management/stats/WebModuleStatsImpl.java:19:
cannot resolve symbol
[javac] symbol : class WebModuleStats
[javac] location: package stats
[javac] import
org.apache.geronimo.management.geronimo.stats.WebModuleStats;
[javac]
^
[javac]
/Users/powerbook/Projects/geronimo/modules/management/src/java/org/apache/geronimo/management/stats/WebModuleStatsImpl.java:31:
cannot resolve symbol
[javac] symbol : class WebModuleStats
[javac] location: class
org.apache.geronimo.management.stats.WebModuleStatsImpl
[javac] public class WebModuleStatsImpl extends
StatsImpl implements WebModuleStats {
[javac]
^
[javac] 2 errors
tomcat integration should wrap each servlet
indiviudally
Key: GERONIMO-1035
URL:
http://issues.apache.org/jira/browse/GERONIMO-1035
Project: Geronimo
Type: New Feature
Components: Tomcat
Versions: 1.0-M5
Environment: All
Reporter: Anita Kulshreshtha
Assignee: Jeff Genender
Fix For: 1.1
Attachments: geronimo-stats-1.1-SNAPSHOT.war,
management.patch, stats.zip, tomcat-builder.patch,
tomcat-builder.patch, tomcat-builder.patch,
tomcat-builder.patch, tomcat.patch, tomcat.patch
TomcatModuleBuilder should wrap each servlet
specified in the deployment descriptor individually.
This is needed by JSR-77 and for gathering tomcat
internal statistics.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of
the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
RE: Build tools: Groovy scripts
Excellent, thanks! Looking at them now, please let me know if I can assist in any way. Regards, Mats -Original Message- From: James Strachan [mailto:[EMAIL PROTECTED] Sent: den 20 februari 2006 14:25 To: activemq-dev@geronimo.apache.org Subject: Re: Build tools: Groovy scripts On 20 Feb 2006, at 09:05, Mats Forslöf wrote: Hi, According to the source in module openwire-dotnet the commands are auto generated via a set of Grovvy scripts located in the activemq- openwire module. It would be nice to do the same for the openwire- cpp commands - anyone that knows where the scripts are, can't find them? BTW I'm just in the process of refactoring those scripts a little to make it easier to reuse the same code across C++ and C# (along with making the scripts a little easier to understand). I've recently tried to auto-create some unit tests for Java want to make those reusable across C++ and C# too... The scripts are here... http://svn.apache.org/repos/asf/incubator/activemq/trunk/activemq- core/src/gram/script/ James --- http://radio.weblogs.com/0112098/
[jira] Commented: (GERONIMO-1035) tomcat integration should wrap each servlet indiviudally
[
http://issues.apache.org/jira/browse/GERONIMO-1035?page=comments#action_12367045
]
Jeff Genender commented on GERONIMO-1035:
-
Thanks. The management patch works, but now your Tomcat cat patch will not
compile. There seems to be some missing classes here as well also.
depend closure=false srcdir=1.4 dump=false
destdir=/Users/powerbook/Projects/geronimo/modules/tomcat/target/classes/depend
[echo] Compiling to
/Users/powerbook/Projects/geronimo/modules/tomcat/target/classes
[javac] Compiling 46 source files to
/Users/powerbook/Projects/geronimo/modules/tomcat/target/classes
[javac]
/Users/powerbook/Projects/geronimo/modules/tomcat/src/java/org/apache/geronimo/tomcat/stats/ConnectorStats.java:31:
cannot find symbol
[javac] symbol : class WebConnectorStatsImpl
[javac] location: package org.apache.geronimo.management.stats
[javac] import org.apache.geronimo.management.stats.WebConnectorStatsImpl;
[javac] ^
[javac]
/Users/powerbook/Projects/geronimo/modules/tomcat/src/java/org/apache/geronimo/tomcat/stats/ConnectorStats.java:43:
cannot find symbol
[javac] symbol : class WebConnectorStatsImpl
[javac] location: class org.apache.geronimo.tomcat.stats.ConnectorStats
[javac] private WebConnectorStatsImpl stats = new
WebConnectorStatsImpl();
[javac] ^
[javac]
/Users/powerbook/Projects/geronimo/modules/tomcat/src/java/org/apache/geronimo/tomcat/stats/ConnectorStats.java:64:
cannot find symbol
[javac] symbol : class WebConnectorStatsImpl
[javac] location: class org.apache.geronimo.tomcat.stats.ConnectorStats
[javac] private void getStats(WebConnectorStatsImpl stats, String
port){
[javac] ^
[javac]
/Users/powerbook/Projects/geronimo/modules/tomcat/src/java/org/apache/geronimo/tomcat/TomcatServletHolder.java:40:
cannot find symbol
[javac] symbol : class WebServletStatsImpl
[javac] location: package org.apache.geronimo.management.stats
[javac] import org.apache.geronimo.management.stats.WebServletStatsImpl;
[javac] ^
[javac]
/Users/powerbook/Projects/geronimo/modules/tomcat/src/java/org/apache/geronimo/tomcat/TomcatServletHolder.java:66:
cannot find symbol
[javac] symbol : class WebServletStatsImpl
[javac] location: class org.apache.geronimo.tomcat.TomcatServletHolder
[javac] private WebServletStatsImpl stats = new WebServletStatsImpl();
[javac] ^
[javac]
/Users/powerbook/Projects/geronimo/modules/tomcat/src/java/org/apache/geronimo/tomcat/TomcatWebAppContext.java:49:
cannot find symbol
[javac] symbol : class WebModuleStatsImpl
[javac] location: package org.apache.geronimo.management.stats
[javac] import org.apache.geronimo.management.stats.WebModuleStatsImpl;
[javac] ^
[javac]
/Users/powerbook/Projects/geronimo/modules/tomcat/src/java/org/apache/geronimo/tomcat/stats/ModuleStats.java:33:
cannot find symbol
[javac] symbol : class WebModuleStatsImpl
[javac] location: package org.apache.geronimo.management.stats
[javac] import org.apache.geronimo.management.stats.WebModuleStatsImpl;
[javac] ^
[javac]
/Users/powerbook/Projects/geronimo/modules/tomcat/src/java/org/apache/geronimo/tomcat/stats/ModuleStats.java:45:
cannot find symbol
[javac] symbol : class WebModuleStatsImpl
[javac] location: class org.apache.geronimo.tomcat.stats.ModuleStats
[javac] private WebModuleStatsImpl stats = new WebModuleStatsImpl();
[javac] ^
[javac]
/Users/powerbook/Projects/geronimo/modules/tomcat/src/java/org/apache/geronimo/tomcat/stats/ModuleStats.java:81:
cannot find symbol
[javac] symbol : class WebModuleStatsImpl
[javac] location: class org.apache.geronimo.tomcat.stats.ModuleStats
[javac] private void getStats(WebModuleStatsImpl stats, long
processingTime, long startupTime,
[javac] ^
[javac]
/Users/powerbook/Projects/geronimo/modules/tomcat/src/java/org/apache/geronimo/tomcat/stats/ModuleStats.java:81:
getStats(java.lang.String,long,long,long) is already defined in
org.apache.geronimo.tomcat.stats.ModuleStats
[javac] private void getStats(WebModuleStatsImpl stats, long
processingTime, long startupTime,
[javac] ^
[javac]
/Users/powerbook/Projects/geronimo/modules/tomcat/src/java/org/apache/geronimo/tomcat/stats/ConnectorStats.java:43:
cannot find symbol
[javac] symbol : class WebConnectorStatsImpl
[javac] location: class org.apache.geronimo.tomcat.stats.ConnectorStats
[javac] private WebConnectorStatsImpl stats = new
WebConnectorStatsImpl();
[javac] ^
[javac]
How to configure a remote HTTPd
Hi All, I just updated the documentation. The following article covers how to configure the Apache HTTPd to forward client requests to Geronimo in two different ways, either as a reverse proxy or using the Jakarta Tomcat Connector. http://opensource2.atlassian.com/confluence/oss/display/GERONIMO/Remote+HTTPd+Server Cheers! Hernan
[jira] Commented: (GERONIMO-1035) tomcat integration should wrap each servlet indiviudally
[ http://issues.apache.org/jira/browse/GERONIMO-1035?page=comments#action_12367050 ] Jeff Genender commented on GERONIMO-1035: - I have to go back to the management patch again...One more swag on the management.patch. It was not built form the top of the module, it was built from the src directory. Now the management and tomcat components build. The final problem is the tomcat-builder patch. It fails the TomcatModuleBuilderTest. The results of the test are below. Please rebuild your patches and apply them to a fresh check out. Please be sure they all compile and all unit tests pass. Thanks Here is the result of the failed unit test in the Tomcat Builder : Testcase: testDeployWar3(org.apache.geronimo.tomcat.deployment.TomcatModuleBuilderTest): Caused an ERROR Unable to initialize webapp GBean org.apache.geronimo.common.DeploymentException: Unable to initialize webapp GBean at org.apache.geronimo.tomcat.deployment.TomcatModuleBuilder.addGBeans(TomcatModuleBuilder.java:404) at org.apache.geronimo.tomcat.deployment.TomcatModuleBuilderTest.deployWar(TomcatModuleBuilderTest.java:192) at org.apache.geronimo.tomcat.deployment.TomcatModuleBuilderTest.testDeployWar3(TomcatModuleBuilderTest.java:148) Caused by: java.lang.IllegalArgumentException: Qualifier patterns in the URLPatternSpec cannot match the first URLPattern at javax.security.jacc.URLPatternSpec.init(URLPatternSpec.java:54) at javax.security.jacc.WebResourcePermission.init(WebResourcePermission.java:54) at org.apache.geronimo.tomcat.deployment.AbstractTomcatModuleBuilder.buildSpecSecurityConfig(AbstractTomcatModuleBuilder.java:677) at org.apache.geronimo.tomcat.deployment.TomcatModuleBuilder.addGBeans(TomcatModuleBuilder.java:377) ... 17 more tomcat integration should wrap each servlet indiviudally Key: GERONIMO-1035 URL: http://issues.apache.org/jira/browse/GERONIMO-1035 Project: Geronimo Type: New Feature Components: Tomcat Versions: 1.0-M5 Environment: All Reporter: Anita Kulshreshtha Assignee: Jeff Genender Fix For: 1.1 Attachments: geronimo-stats-1.1-SNAPSHOT.war, management.patch, management.patch, stats.zip, tomcat-builder.patch, tomcat-builder.patch, tomcat-builder.patch, tomcat-builder.patch, tomcat.patch, tomcat.patch TomcatModuleBuilder should wrap each servlet specified in the deployment descriptor individually. This is needed by JSR-77 and for gathering tomcat internal statistics. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Migrating to maven 2
We should have a wiki page with the modules list so that people can sign up ? The page could also mark complete those modules already done. I shall spare some cycles for it during this week as I wrap up my itests subproject infrastructure. I shall devote full time towards more modules conversion from next week. Cheers Prasad On 2/20/06, Jacek Laskowski [EMAIL PROTECTED] wrote: 2006/2/20, anita kulshreshtha [EMAIL PROTECTED]: I would like to migrate tomcat and tomcat-builder if it is not already taken? AFAIK, it is not. Go for it! Create a JIRA task item. Attach it to http://issues.apache.org/jira/browse/GERONIMO-851 and go ahead. Anita Jacek -- Jacek Laskowski http://www.laskowski.org.pl
Re: How to configure a remote HTTPd
Hi Jeff, I normally use the console as the sample application because it is the easiest application to test and everybody knows where it is. I personally do not believe that anybody will be interested in having the console exposed :) but for the just in case, I added a couple of *WARNINGS* in red to catch the readers attention there ;) ..btw, thanks for the feedback.. I am planning to add an article to discuss different topologies for implementing Geronimo, discuss the pros and cons of each topology (security, performance, high availability, etc). I think it would be good to have a few different topologies described (solution oriented) where you could see the different nodes (remote http, app server, db, ldap, etc.), likelyhood of firewalls and the connectivity requirements between the nodes. It would be great to have a few extra hands for working on this topic, volunteers welcome :) Cheers! Hernan Jeff Genender wrote: Hernan, Great article. One thing you may wish to add is discussion of the security consequences of exposing /console. This will usually be a URL that is not exposed to the public via a front ended httpd setup...as it would be considered a security risk. Typically, a front ended web server will be used for production, so this may be a good tip to add. Perhaps in your examples you could expose one of the example applications, or show how to expose the whole server, but offer an example of where you can deny access to the console for security purposes. Its just a small hint for security conscious folks. Jeff Hernan Cunico wrote: Hi All, I just updated the documentation. The following article covers how to configure the Apache HTTPd to forward client requests to Geronimo in two different ways, either as a reverse proxy or using the Jakarta Tomcat Connector. http://opensource2.atlassian.com/confluence/oss/display/GERONIMO/Remote+HTTPd+Server Cheers! Hernan
reorg devtools tree
I'm wanting to create a tag for the 1.0 version plugin, and currently I don't like layout of the devtools as isn't organized properly to do so Currently we have... ./devtools/trunk/modules/eclipse-plugin/ ./devtools/trunk/sandbox/ I'd like to reorganize this to just... ./devtools/eclipse-plugin/trunk ./devtools/sandbox/ This way I can create a tags directory at the same level as the trunk.. ./devtools/eclipse-plugin/trunk ./devtools/eclipse-plugin/tags Any objections? - sachin
Re: Multiple servers sharing the same repo and config store
Can you please elaborate a bit more on what exactly this provides? Can I now have two separate instances each with their own unique applications/configurations/logs (i.e. config-store, deploy and var directories) sharing the same geronimo installation binaries (i.e. bin, lib and repository directories)? If so, how do we create the additional instances? I assume the binary distribution creates the the first instance during the build and that users need to create the additional instances manually for now.. Thanks -Dave- Gianny Damour wrote: Hi, The second solution has been implemented. When starting G, it is now possible to specify one of these two system properties: * org.apache.geronimo.server.name: name of the server to be started. If server1 is specified, then G will use the directory geronimo installation dir/server1; or * org.apache.geronimo.server.dir: directory of the server to be started. This can be either a relative or an absolute path. For instance, if ./server1 is specified, then G will use the directory geronimo installation dir/server1. I still need to provide a patch for an AMQ GBean, JournalPersistenceAdapterGBean, in order to resolve its directory attribute based on the server directory - will do that during the day. Thanks, Gianny David Jencks wrote: On Feb 12, 2006, at 9:17 AM, Vincent Massol wrote: Hi David and everyone, Any progress on this? not yet, sorry. it is pretty easy, but I am tied up in the configid branch right now. david jencks Thanks -Vincent -Original Message- From: David Jencks [mailto:[EMAIL PROTECTED] Sent: lundi 30 janvier 2006 08:23 To: dev@geronimo.apache.org Subject: Multiple servers sharing the same repo and config store Many people have talked on and off about how to set up multiple servers sharing the same repository and config-store, but we haven't arrived at an agreed on way to do it. We have a prospective customer for this feature (Vincent Massol with Cargo) so I'd like to move beyond thinking about it in my head, discuss it, and have someone implement it. I believe any implementation will be more or less trivial, the hard part is figuring out what to do. I've only thought of ways to extend what we have now, rather than restructure anything or add big new capabilities. If someone sees a better way, please speak up. So, we have a ServerInfo gbean that knows where geronimo is located and can resolve absolute locations for other components. Then we have things like the repository and config store gbeans that typically are located outside the var dir and things like the logging framework, local attribute manager, derby, and tomcat, that typically keep stuff in the var directory. All or most of these start with the first configuration loaded so they can't have any attributes overridden by config.xml: in fact this file is read by one of the gbeans that we need to relocate. I've thought of two related solutions. Both of them involve giving ServerInfo knowledge of another path and another resolve method. One would be something like resolveVar and would normally resolve to geronimo_home/var. This would involve all the gbeans currently looking inside var having the var trimmed off the front of their paths and using the new resolveVar method. In this case we'd have different servers represented as e.g. var1 var2 var3 ... The other would give ServerInfo something like resolveServer which would normally resolve to geronimo_home. The gbeans looking inside var would keep their current paths and just call the new resolve method instead of the old one. In this case we'd have servers like var server1/var server2/var ... In either case I think starting geronimo with a command line argument pointing to the var directory is the only way to specify which server you want to run; the default would presumably be as now var. Several people have suggested putting an additional config-store into var for private use by a particular server. At the moment I think that providing a different config-store class that uses the new resolve method on server info would be the best way to do this. I'm not attached to these ideas but this is as far as my thinking has gone. Please comment. thanks david jencks
[jira] Commented: (GERONIMO-1035) tomcat integration should wrap each servlet indiviudally
[ http://issues.apache.org/jira/browse/GERONIMO-1035?page=comments#action_12367063 ] Anita Kulshreshtha commented on GERONIMO-1035: -- As noted in the comment on 12Feb, item 1, a test for G-1585 (/* in security-constraint) is included. This test will fail unless the change suggested in G-1585 is applied. If you want I can disable this test. tomcat integration should wrap each servlet indiviudally Key: GERONIMO-1035 URL: http://issues.apache.org/jira/browse/GERONIMO-1035 Project: Geronimo Type: New Feature Components: Tomcat Versions: 1.0-M5 Environment: All Reporter: Anita Kulshreshtha Assignee: Jeff Genender Fix For: 1.1 Attachments: geronimo-stats-1.1-SNAPSHOT.war, management.patch, management.patch, stats.zip, tomcat-builder.patch, tomcat-builder.patch, tomcat-builder.patch, tomcat-builder.patch, tomcat.patch, tomcat.patch TomcatModuleBuilder should wrap each servlet specified in the deployment descriptor individually. This is needed by JSR-77 and for gathering tomcat internal statistics. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Geronimo Documentation update
Hi All, Here is another update to the doc. I added Administering applications to the Administrative tasks section. http://opensource2.atlassian.com/confluence/oss/display/GERONIMO/Administrative+tasks#Administrativetasks-Administeringapplications Cheers! Hernan
Re: Migrating to maven 2
2006/2/20, Prasad Kashyap [EMAIL PROTECTED]: We should have a wiki page with the modules list so that people can sign up ? Hi Prasad, Wouldn't it be better off having a set of JIRA tasks and let people pick their favorities? I'll create them. I'm about to commit some changes wrt Maven2 support that should help people get started and jump in. I'm checking it out at the moment. The page could also mark complete those modules already done. JIRA is just for that. I don't think Wiki would help in any way. What do you think? I shall spare some cycles for it during this week as I wrap up my itests subproject infrastructure. I shall devote full time towards more modules conversion from next week. Excellent! I've got some tasks assigned, too, and would be glad to see more people involved so that we all don't get swamped with the migration very quickly ;) Prasad Jacek -- Jacek Laskowski http://www.laskowski.org.pl
[jira] Created: (GERONIMO-1641) Using default Console Realm, when delete a user it will not be removed from the groups
Using default Console Realm, when delete a user it will not be removed from the groups -- Key: GERONIMO-1641 URL: http://issues.apache.org/jira/browse/GERONIMO-1641 Project: Geronimo Type: Bug Components: console Versions: 1.0 Reporter: Hernan Cunico When using the default console realm and you add a user to a group, if that user is deleted later it will not be removed from the group it was added. The Geronimo console shows that the user has been removed but the groups.properties still shows the user. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: reorg devtools tree
2006/2/20, Sachin Patel [EMAIL PROTECTED]: I'd like to reorganize this to just... ./devtools/eclipse-plugin/trunk ./devtools/sandbox/ This way I can create a tags directory at the same level as the trunk.. ./devtools/eclipse-plugin/trunk ./devtools/eclipse-plugin/tags Any objections? Nope. It will eventually reflect how the trunk of Geronimo is made. +1 for the change. - sachin Jacek -- Jacek Laskowski http://www.laskowski.org.pl
[jira] Updated: (GERONIMO-1035) tomcat integration should wrap each servlet indiviudally
[ http://issues.apache.org/jira/browse/GERONIMO-1035?page=all ] Anita Kulshreshtha updated GERONIMO-1035: - Attachment: tomcat-builder.patch Sorry for the confusion. I included the test thinking that G-1585 can also be resolved at the same time. Since G-1585 affects both Jetty and tomcat, it will be best to deal with it separately. A similar test will have to be added to Jetty. I have disabled the test in this patch for now. I am working on reformatting everything and will submit a clean version of everything either tonight or tomorrow. tomcat integration should wrap each servlet indiviudally Key: GERONIMO-1035 URL: http://issues.apache.org/jira/browse/GERONIMO-1035 Project: Geronimo Type: New Feature Components: Tomcat Versions: 1.0-M5 Environment: All Reporter: Anita Kulshreshtha Assignee: Jeff Genender Fix For: 1.1 Attachments: geronimo-stats-1.1-SNAPSHOT.war, management.patch, management.patch, stats.zip, tomcat-builder.patch, tomcat-builder.patch, tomcat-builder.patch, tomcat-builder.patch, tomcat-builder.patch, tomcat.patch, tomcat.patch TomcatModuleBuilder should wrap each servlet specified in the deployment descriptor individually. This is needed by JSR-77 and for gathering tomcat internal statistics. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-851) Move Geronimo Build to M2 (Maven 2)
[ http://issues.apache.org/jira/browse/GERONIMO-851?page=comments#action_12367087 ] Jacek Laskowski commented on GERONIMO-851: -- $ svn ci maven.xml Sendingmaven.xml Transmitting file data . Committed revision 379245. With the revision, you can execute Maven2 together with the new Geronimo build based on Maven1. + The m2 property is to ignite the build of the kernel module using Maven2 + The goal: m2 is to create a template to execute Maven2 commands via goal property + The execmvn goal is to execute Maven2 shell script either mvn.bat or mvn based on OS (it surely needs more appropriate OS names) Run maven -Dm2=true new to build Geronimo with the new goal and execute mvn install on the kernel module Run maven m2 to execute mvn install on the kernel module only Move Geronimo Build to M2 (Maven 2) --- Key: GERONIMO-851 URL: http://issues.apache.org/jira/browse/GERONIMO-851 Project: Geronimo Type: Task Components: buildsystem Reporter: John Sisson Assignee: John Sisson Fix For: 1.x Created this issue to keep track of the status of work to move the Geronimo build to Maven 2. Does anyone know the status of this effort? I believe some work was done in OpenEJB? When is the move to M2 planned for? 1.0 or 1.1 FYI.. In June I attempted to use Maven 1.1 beta 1 to build geronimo and got some parse exceptions in maven. As a result, some small changes were made to some project.xml files by David Jencks, which fixed the parse problem, but we then ran into another problem where we were getting a java.lang.NoSuchMethodError in maven. This should now be fixed using an updated artifact plugin, see http://jira.codehaus.org/browse/MAVEN-1625 (but I have not verified this). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Migrating to maven 2
2006/2/20, Jacek Laskowski [EMAIL PROTECTED]: I'm about to commit some changes wrt Maven2 support that should help people get started and jump in. I'm checking it out at the moment. Done. The change is committed and ready to give it a try. It won't possibly work on operating systems other than Windows XP since the os attribute of the execmvn goal is incomplete/invalid. You can run M2 install command of the kernel module right after running the new build when m2 property is set, e.g. maven -Dm2=true new Give it a try and report back how it works. I'll go on with the kernel module (as an example for others) and will try to get rid of Maven1 files from it. It will make the m2 property obligatory. Jacek -- Jacek Laskowski http://www.laskowski.org.pl
[jira] Created: (GERONIMODEVTOOLS-68) Use ServerInfo to validate target runtime version
Use ServerInfo to validate target runtime version - Key: GERONIMODEVTOOLS-68 URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-68 Project: Geronimo-Devtools Type: Task Components: eclipse-plugin Reporter: Sachin Patel Priority: Minor -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-1642) Deployment plan namespace validation
Deployment plan namespace validation Key: GERONIMO-1642 URL: http://issues.apache.org/jira/browse/GERONIMO-1642 Project: Geronimo Type: Improvement Components: web, deployment, OpenEJB Versions: 1.0 Reporter: Aaron Mulder Fix For: 1.1 When you deploy with a geronimo deployment plan packaged in the archive, but it has the wrong namespace, the file is ignored. If anything, you get a message saying the plan is required, or that the archive is not a WAR/JAR/etc. We should have special detection for geronimo-application.xml, geronimo-ra.xml, geronimo-web.xml, and openejb-jar.xml that notices if the file is present but has the wrong namespace, and prints a suggestive WARN or ERROR message to the console. Probably for the application.xml, web.xml, ra.xml, and ejb-jar.xml too. People have asked for help on the mailing list several times recently when they had this (bad namespace) problem. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: New site ready?
Looks like some images are missing. - sachin On Feb 20, 2006, at 10:55 PM, Sachin Patel wrote: I just checked out from site and looks like everything has been changed over to the epiq look and feel. Is this ready to go live? I need to add content but if its not ready I can't publish my changes. - sachin
Changing Trunk to 1.2 in anticipation of 1.0.1 becoming 1.1
I was thinking that in order to expedite getting 1.1 our the door that it would make sense to move trunk to 1.2. Then we'll have to do the same in the 1.0 branch. I'm going to start working on that this week. Comments, suggestions, ? I'll post before making the change. Matt
Re: Changing Trunk to 1.2 in anticipation of 1.0.1 becoming 1.1
On 2/20/2006 8:23 PM, Matt Hogstrom wrote: I was thinking that in order to expedite getting 1.1 our the door that it would make sense to move trunk to 1.2. Then we'll have to do the same in the 1.0 branch. I'm going to start working on that this week. Comments, suggestions, ? So what is in trunk now? What is in branches/1_0 now? Where is the work for 1_1 taking place? Regards, Alan
Re: Migrating to maven 2
On 2/20/2006 12:29 AM, Jacek Laskowski wrote: 2006/2/20, Alan D. Cabrera [EMAIL PROTECTED]: Does the entire system need to build using a single command for this interim conversion? Why not have people do a mvn install maven new The "mvn install" will build both maven 1 and 2 jars. The "maven new" will use the maven 1 jars. Very good idea, but the real PITA is not how to build Geronimo using M1 *and* M2, but how to minimize the redundancy of information in their respective files, cf dependencies. I'll be writing about it in minutes. Gotta run now... What redundant information? Just make sure that the m2 POMs are clean and make the m1 modules depend on m2 and m1 jars. It should be simple. Regards, Alan
Re: Changing Trunk to 1.2 in anticipation of 1.0.1 becoming 1.1
I have been wondering the exact questions Alan asked as well. I have some fixes that were supposed to be in 1.0.1, but then I heard 1.0.1 is no more, and we have named HEAD the 1.1, so I never ported some of my changes. So now I am thoroughly confused. An official stance on versioning and what is what, and where would really be helpful ;-) Jeff Alan D. Cabrera wrote: On 2/20/2006 8:23 PM, Matt Hogstrom wrote: I was thinking that in order to expedite getting 1.1 our the door that it would make sense to move trunk to 1.2. Then we'll have to do the same in the 1.0 branch. I'm going to start working on that this week. Comments, suggestions, ? So what is in trunk now? What is in branches/1_0 now? Where is the work for 1_1 taking place? Regards, Alan
Re: Migrating to maven 2
On 2/20/2006 3:20 AM, Gianny Damour wrote: Alan D. Cabrera wrote: Does the entire system need to build using a single command for this interim conversion? Why not have people do a mvn install maven new The mvn install will build both maven 1 and 2 jars. The maven new will use the maven 1 jars. That also works. This approach assmes that the M2 modules that we migrate do not depend on modules which have not yet been migrated to M2 - basically, this implies that modules are migrated in the same order than the build order derived by the M1 reactor. I think that I like this approach better than my previous idea, where any module could be migrated - whatever its dependencies. However, I am not really keen to have people use two commands and would prefer to simply use the maven command which triggers the mvn command under the cover. I think that this has already been suggested by David J.: we add a goal, e.g. new000, which is executed between new00 and new1. new000 launches mvn install in the root project directory. We add to the excludes list of new1 the migrated modules (we could also remove the M1 project files after migration). If I see yet *another* new fangled way to build Geronimo, I'll go postal. Let's go w/ the two command system whereby we do things the sane way in maven 2, i.e. mvn install. Let us leave our sordid past behind and begin anew. Seriously, this futzing has got to stop. Regards, Alan
Re: Changing Trunk to 1.2 in anticipation of 1.0.1 becoming 1.1
Alan D. Cabrera wrote: On 2/20/2006 8:23 PM, Matt Hogstrom wrote: I was thinking that in order to expedite getting 1.1 our the door that it would make sense to move trunk to 1.2. Then we'll have to do the same in the 1.0 branch. I'm going to start working on that this week. Comments, suggestions, ? So what is in trunk now? What is in branches/1_0 now? Where is the work for 1_1 taking place? Matt, Could you please confirm the following.. AFAIK, work for the 1.1 release (that was previously going to be called the 1.0.1 release) should be done in the 1.0 branch (until we branch for 1.1?). Matt is proposing to change the version numbers in files in branches/1.0 to be 1.1. I assume you plan on doing this before we create the 1.1 branch? Once the configId changes are merged in to branches/1.0 and we are ready for a release we would create branches/1.1 from the 1.0 branch. If we are creating a 1.1 branch then does that mean there would be no further work happening in the 1.0 branch once the branch is made? Work for the 1.2 release should be done in trunk. I think Matt is proposing to change the version numbers in files in trunk to be 1.2. Are we releasing version 1.1 of all the specs for the 1.1 release? Thanks, John Regards, Alan
