Re: [BSF][VOTE] Release BSF 3.1 (based on RC3)
Hi Sebb, sebb wrote: > [Resending because I left off the VOTE prefix, and the subject change > does not seem to be filtering down ...] > > [Third time lucky?] > > Please review and vote on the BSF 3.1 release. > > The artifacts are available at: > > http://people.apache.org/~sebb/bsf-3.1-RC3/ > > The Maven artifacts are at: > > https://repository.apache.org/content/repositories/orgapachebsf-004/ > > The SVN tag is at: > > http://svn.apache.org/repos/asf/jakarta/bsf/tags/bsf-3.1-RC3 > > This will be renamed following a successful vote. > > Keys are here: > http://www.apache.org/dist/jakarta/bsf/KEYS > > Vote will remain open for at least 72 hours. > > [ ] +1 I support this release. > [ ] -1 I am against releasing the packages (must include a reason). +1 (non-binding), builds fine from delivered sources with Sun JDK 1.5/1.6/1.7 and IBM JDK 1.6 - Jörg - To unsubscribe, e-mail: general-unsubscr...@jakarta.apache.org For additional commands, e-mail: general-h...@jakarta.apache.org
Re: [VOTE] Release BSF 3.1 (based on RC2)
sebb wrote: > On 04/06/2010, Jörg Schaible wrote: >> sebb wrote: >> >> > I've hopefully fixed all the problems reported with the previous RC1. >> > >> > Please review and vote on the BSF 3.1 release. >> > >> > The artifacts are available at: >> > >> > http://people.apache.org/~sebb/bsf-3.1-RC2/ >> > >> > The Maven artifacts are at: >> > >> > https://repository.apache.org/content/repositories/orgapachebsf-037/ >> > >> > The SVN tag is at: >> > >> > http://svn.apache.org/repos/asf/jakarta/bsf/tags/bsf-3.1-RC2 >> > >> > This will be renamed following a successful vote. >> > >> > Keys are here: >> > http://www.apache.org/dist/jakarta/bsf/KEYS >> > >> > Vote will remain open for at least 72 hours. >> > >> > [ ] +1 I support this release. >> > [ ] -1 I am against releasing the packages (must include a reason). >> >> >> -1 >> >> The source tarball does no longer contains the engines submodule, >> therefore the build fails: > > Bother. I thought I had checked that. Should be easy enough to fix. > > I assume you are referring to the non-Maven source tarball? Yes. I was a bit surprised, since it was there with RC1. - Jörg - To unsubscribe, e-mail: general-unsubscr...@jakarta.apache.org For additional commands, e-mail: general-h...@jakarta.apache.org
Re: [VOTE] Release BSF 3.1 (based on RC2)
sebb wrote: > I've hopefully fixed all the problems reported with the previous RC1. > > Please review and vote on the BSF 3.1 release. > > The artifacts are available at: > > http://people.apache.org/~sebb/bsf-3.1-RC2/ > > The Maven artifacts are at: > > https://repository.apache.org/content/repositories/orgapachebsf-037/ > > The SVN tag is at: > > http://svn.apache.org/repos/asf/jakarta/bsf/tags/bsf-3.1-RC2 > > This will be renamed following a successful vote. > > Keys are here: > http://www.apache.org/dist/jakarta/bsf/KEYS > > Vote will remain open for at least 72 hours. > > [ ] +1 I support this release. > [ ] -1 I am against releasing the packages (must include a reason). -1 The source tarball does no longer contains the engines submodule, therefore the build fails: %< === $ mvn clean package [INFO] Scanning for projects... [INFO] [ERROR] FATAL ERROR [INFO] [INFO] Error building POM (may not be this project's POM). Project ID: unknown Reason: Could not find the model file './bsf-engines'. for project unknown [INFO] [INFO] Trace org.apache.maven.reactor.MavenExecutionException: Could not find the model file '/home/joehni/tmp/download/bsf-3.1-src/bsf-engines'. for project unknown at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:404) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:272) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138) at org.apache.maven.cli.MavenCli.main(MavenCli.java:362) at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.project.ProjectBuildingException: Could not find the model file '/home/joehni/tmp/download/bsf-3.1-src/bsf-engines'. for project unknown at org.apache.maven.project.DefaultMavenProjectBuilder.readModel(DefaultMavenProjectBuilder.java:1575) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMavenProjectBuilder.java:506) at org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:200) at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:604) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:487) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:560) at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:391) ... 12 more Caused by: java.io.FileNotFoundException: /home/joehni/tmp/download/bsf-3.1- src/bsf-engines (No such file or directory) at java.io.FileInputStream.open(Native Method)
Re: [VOTE] Release BSF 3.1
Hi Sebb, sebb wrote: > On 18/05/2010, Jörg Schaible wrote: [snip] >> BTW: Is BSF 3.1 now compatible with Jexl2? Jexl2 has now its own script >> engine support, but BSF engines will force Jexl 1.2 in which creates >> incompatibilities for Jexl2 in BSF 3.0. > > Start a new thread for that. I opened directly an issue now: BSF-32 - Jörg - To unsubscribe, e-mail: general-unsubscr...@jakarta.apache.org For additional commands, e-mail: general-h...@jakarta.apache.org
Re: [VOTE] Release BSF 3.1
sebb wrote: > On 18/05/2010, Jörg Schaible wrote: >> sebb wrote: >> >> > On 18/05/2010, Jörg Schaible wrote: >> >> [snip] >> >> >> >> Yes, if I add this, the build runs through. However, you're aware that >> >> the >> >> usage of repositories within the POMs is strongly discouraged and >> >> IIRC will no longer work in M3? >> > >> > No, I was not aware of that. >> > >> > How are such dependencies supposed to be managed then? >> >> >> The problem is that in a company environment you want normally to control >> the accessed remote resources (or with a repo manager like Nexus) and >> with such repository declarations arbitrary locations are added. >> http://www.sonatype.com/people/2009/02/why-putting-repositories-in-your- >> poms-is-a-bad-idea/ > > I've read the article, and I don't think it applies here, because: > - it only affects one test project > - the test projects are not uploaded to Maven. > > So I think the best is to re-instate the repo reference. It seems the discussion is still open: http://thread.gmane.org/gmane.comp.jakarta.turbine.maven.devel/93721 However, it is pointless for BSF 3.1 release ... - Jörg - To unsubscribe, e-mail: general-unsubscr...@jakarta.apache.org For additional commands, e-mail: general-h...@jakarta.apache.org
Re: [VOTE] Release BSF 3.1
sebb wrote: > On 18/05/2010, Jörg Schaible wrote: [snip] >> Yes, if I add this, the build runs through. However, you're aware that >> the >> usage of repositories within the POMs is strongly discouraged and IIRC >> will no longer work in M3? > > No, I was not aware of that. > > How are such dependencies supposed to be managed then? The problem is that in a company environment you want normally to control the accessed remote resources (or with a repo manager like Nexus) and with such repository declarations arbitrary locations are added. http://www.sonatype.com/people/2009/02/why-putting-repositories-in-your- poms-is-a-bad-idea/ All you can do then is to ensure that the stuff will go to central or you have to add the repo information to some file like BUILDING so that a user can add the repo to its settings on its own. There have been discussions about exceptions to the rule, but I do not know the latest status. - Jörg - To unsubscribe, e-mail: general-unsubscr...@jakarta.apache.org For additional commands, e-mail: general-h...@jakarta.apache.org
Re: [VOTE] Release BSF 3.1
Jörg Schaible wrote: > Hi Sebb, > > sebb wrote: [snip] >> I'd like to see if there are any further problems before proceeding >> with another RC. > > Fine with me, I have some more pets in my compiler zoo ... ;-) There's more ... IBM 1.6.0.8: %< === Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200) Java version: 1.6.0 Java home: /opt/ibm-jdk-bin-1.6.0.8/jre Default locale: en_US, platform encoding: UTF-8 OS name: "linux" version: "2.6.32-gentoo-r7" arch: "x86" Family: "unix" Running org.apache.bsf.testing.javascript.RubyTestcase Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 2.258 sec <<< FAILURE! junit.framework.AssertionFailedError: Engine should not be null at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.assertTrue(Assert.java:20) at junit.framework.Assert.assertNotNull(Assert.java:217) at org.apache.bsf.testing.javascript.RubyTestcase.testInvokeFunction(RubyTestcase.java:41) %< === Sun JDK 1.7.0-ea (looks more like an incompatibility of ancient Groovy 1.1 with this JDK): %< === Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200) Java version: 1.7.0-ea Java home: /opt/sun-jdk-1.7.0.0_alpha69/jre Default locale: en_US, platform encoding: UTF-8 OS name: "linux" version: "2.6.32-gentoo-r7" arch: "i386" Family: "unix" Running org.apache.bsf.testing.groovy.GroovyTestcase Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.155 sec <<< FAILURE! java.lang.NoClassDefFoundError: org/mozilla/javascript/ContextFactory at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:264) at sun.misc.Service$LazyIterator.next(Service.java:288) at javax.script.ScriptEngineManager.initEngines(ScriptEngineManager.java:127) at javax.script.ScriptEngineManager.access$000(ScriptEngineManager.java:55) at javax.script.ScriptEngineManager$1.run(ScriptEngineManager.java:98) at java.security.AccessController.doPrivileged(Native Method) at javax.script.ScriptEngineManager.init(ScriptEngineManager.java:96) at javax.script.ScriptEngineManager.<init> (ScriptEngineManager.java:69) at org.apache.bsf.testing.groovy.GroovyTestcase.testInvokeFunction(GroovyTestcase.java:34) Caused by: java.lang.ClassNotFoundException: org.mozilla.javascript.ContextFactory at java.net.URLClassLoader$1.run(URLClassLoader.java:299) at java.net.URLClassLoader$1.run(URLClassLoader.java:288) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:287) at java.lang.ClassLoader.loadClass(ClassLoader.java:392) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:334) at java.lang.ClassLoader.loadClass(ClassLoader.java:332) ... 36 more %< === JRockit 1.5.0.14 (pathetic version, just for info): %< === Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200) Java version: 1.5.0_14 Java home: /opt/jrockit-jdk-bin-1.5.0.14/jre Default locale: en_US, platform encoding: UTF-8 OS name: "linux" version: "2.6.32-gentoo-r7" arch: "i386" Family: "unix" Running org.apache.bsf.testing.javascript.RubyTestcase [JRockit] ERROR: The JVM has crashed. Writing crash information to /home/joehni/tmp/download/bsf-3.1-src/testing/ruby/jrockit.12652.dump. %< === However, it did build fine with Sun JDK 1.6, Sun JDK 1.5 and IcedTea6 1.7.2. Since M2.2 requires Java 5, I tried to build for JDK 1.4 (according BUILDING file JDK 1.4 is minimum) with M2.0, but this is not possible, because the plugins in use have a requirement for M2.1. The build with Sun JDK 1.4 and M2.1 fails also, because another plugin uses Java 5. So *building* BSF requires 1.5. However, I am able to run the tests for the engines (after building with Sun JDK 1.6) with Maven 2.1 and Blackdown 1.4.2, Sun JDK 1.4.2, JRockit 1.4. So compatibility with JDK 1.4 looks good. IBM JDK 1.5 and 1.4 fail as usual with Maven itself. - Jörg - To unsubscribe, e-mail: general-unsubscr...@jakarta.apache.org For additional commands, e-mail: general-h...@jakarta.apache.org
Re: [VOTE] Release BSF 3.1
Hi Sebb, sebb wrote: > On 18/05/2010, Jörg Schaible wrote: [snip] >> 1 required artifact is missing. >> >> for artifact: >> org.apache.bsf.testing:bsf-testing-e4x-1.6R7-Axiom:jar:3.1 >> >> from the specified remote repositories: >> apache.snapshots (http://repository.apache.org/snapshots), >> central (http://repo1.maven.org/maven2) >> = %< == >> > > Rats - it builds OK for me and for Hudson - I guess those must have > got local copies. > > BTW, what JVM and OS are you using? Currently: $ mvn -version Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200) Java version: 1.6.0_20 Java home: /opt/sun-jdk-1.6.0.20/jre Default locale: en_US, platform encoding: UTF-8 OS name: "linux" version: "2.6.32-gentoo-r7" arch: "i386" Family: "unix" >> BUILDING text file does not give any hint where this artifact should be >> coming from. > > Nor should it need to - it should be in the maven POMs. > > I tidied up some of the repo dependencies as I thought I found it in > central. I assumed that Maven would tell me if the dependency could not be > resolved. > > Is there any way to check this, apart from deleting the local maven repo? No, but you might use an alternate settings.xml file (-s) instead that locates the local repo somewhere else to a temporary path. > Try adding > > > > wso2 > http://dist.wso2.org/maven2 > > true > > > > > to testing/e4x-1.6R7-Axiom/pom.xml > > and see if that allows the test to continue. Yes, if I add this, the build runs through. However, you're aware that the usage of repositories within the POMs is strongly discouraged and IIRC will no longer work in M3? > I'd like to see if there are any further problems before proceeding > with another RC. Fine with me, I have some more pets in my compiler zoo ... ;-) > >> BTW: Is BSF 3.1 now compatible with Jexl2? Jexl2 has now its own script >> engine support, but BSF engines will force Jexl 1.2 in which creates >> incompatibilities for Jexl2 in BSF 3.0. > > Start a new thread for that. OK. - Jörg - To unsubscribe, e-mail: general-unsubscr...@jakarta.apache.org For additional commands, e-mail: general-h...@jakarta.apache.org
Re: [VOTE] Release BSF 3.1
sebb wrote:
> Please review and vote on the BSF 3.1 release.
>
> The artifacts are available at:
>
> http://people.apache.org/~sebb/bsf-3.1-RC1/
>
> The Maven artifacts are at:
>
> https://repository.apache.org/content/repositories/orgapachebsf-001/
>
> The SVN tag is at:
>
> http://svn.apache.org/repos/asf/jakarta/bsf/tags/bsf-3.1-RC1
>
> This will be renamed following a successful vote.
>
> Keys are here:
> http://www.apache.org/dist/jakarta/bsf/KEYS
>
> Vote will remain open for at least 72 hours.
>
> [ ] +1 I support this release.
> [ ] -1 I am against releasing the packages (must include a reason).
-1, package cannot be build from source:
= %< ==
$ mvn clean install
[INFO]
[INFO] Building Apache BSF testing for JavaScript/E4X 1.6R7 Axiom
[INFO]task-segment: [clean, install]
[INFO]
[INFO] [clean:clean {execution: default-clean}]
[INFO] [remote-resources:process {execution: default}]
Downloading:
http://repo1.maven.org/maven2/org/apache/ws/commons/axiom/axiom-
api/1.2.5/axiom-api-1.2.5.pom
Downloading:
http://repo1.maven.org/maven2/org/apache/ws/commons/axiom/axiom-
parent/1.2.5/axiom-parent-1.2.5.pom
Downloading:
http://repo1.maven.org/maven2/org/apache/ws/commons/axiom/axiom-
impl/1.2.5/axiom-impl-1.2.5.pom
Downloading: http://repo1.maven.org/maven2/org/wso2/wsf/javascript/axiom-
e4x/0.29/axiom-e4x-0.29.pom
[INFO] Unable to find resource 'org.wso2.wsf.javascript:axiom-e4x:pom:0.29'
in repository central (http://repo1.maven.org/maven2)
Downloading:
http://repo1.maven.org/maven2/org/apache/ws/commons/axiom/axiom-
api/1.2.5/axiom-api-1.2.5.jar
Downloading: http://repo1.maven.org/maven2/org/wso2/wsf/javascript/axiom-
e4x/0.29/axiom-e4x-0.29.jar
Downloading:
http://repo1.maven.org/maven2/org/apache/ws/commons/axiom/axiom-
impl/1.2.5/axiom-impl-1.2.5.jar
[INFO] Unable to find resource 'org.wso2.wsf.javascript:axiom-e4x:jar:0.29'
in repository central (http://repo1.maven.org/maven2)
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Failed to resolve dependencies for one or more projects in the
reactor. Reason: Missing:
--
1) org.wso2.wsf.javascript:axiom-e4x:jar:0.29
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file -DgroupId=org.wso2.wsf.javascript -
DartifactId=axiom-e4x -Dversion=0.29 -Dpackaging=jar -Dfile=/path/to/file
Alternatively, if you host your own repository you can deploy the file
there:
mvn deploy:deploy-file -DgroupId=org.wso2.wsf.javascript -
DartifactId=axiom-e4x -Dversion=0.29 -Dpackaging=jar -Dfile=/path/to/file -
Durl=[url] -DrepositoryId=[id]
Path to dependency:
1) org.apache.bsf.testing:bsf-testing-e4x-1.6R7-Axiom:jar:3.1
2) org.wso2.wsf.javascript:axiom-e4x:jar:0.29
--
1 required artifact is missing.
for artifact:
org.apache.bsf.testing:bsf-testing-e4x-1.6R7-Axiom:jar:3.1
from the specified remote repositories:
apache.snapshots (http://repository.apache.org/snapshots),
central (http://repo1.maven.org/maven2)
= %< ==
BUILDING text file does not give any hint where this artifact should be
coming from.
BTW: Is BSF 3.1 now compatible with Jexl2? Jexl2 has now its own script
engine support, but BSF engines will force Jexl 1.2 in which creates
incompatibilities for Jexl2 in BSF 3.0.
- Jörg
-
To unsubscribe, e-mail: general-unsubscr...@jakarta.apache.org
For additional commands, e-mail: general-h...@jakarta.apache.org
Re: [VOTE] Merge dev lists
Henri Yandell wrote: > Non-binding +1. > > Whether or not the projects find they like being on one list or not, > it will be good. If it's not liked, then it's another reason to go > TLP. +1 (non-binding) - Jörg - To unsubscribe, e-mail: general-unsubscr...@jakarta.apache.org For additional commands, e-mail: general-h...@jakarta.apache.org
Re: [PROPOSAL] One development list
Henri Yandell wrote: > On Wed, Oct 14, 2009 at 3:40 PM, Henri Yandell wrote: >> On Tue, Oct 13, 2009 at 12:31 PM, Daniel F. Savarese >> wrote: >>> >> >>> >>> Although I think we need to discuss and resolve what the future of >>> Jakarta is to be, I agree with Rahul that it should be a separate >>> discussion after resolving his more narrowly scoped dev@/commits@ >>> proposal. The only reason I haven't resigned from the Jakarta PMC >>> (after attic'ing ORO, now that there's an attic) is because JMeter >>> continues to use ORO and someone needs to be willing and able to >>> fix any issues that may arise. At least with a combined dev list, >>> there can be some assurance that other committers will be alerted >>> to any problems that require fixing (not that there have been any >>> for the better part of a decade). >> >> Help migrate JMeter off of ORO? :) > > Slightly less tongue in cheek - maybe now is the time to move ORO, > Regexp and ECS over to Commons. +1 > I'm happy to help out with the move if desired. If active projects > then moving to a new site style and JIRA would come up, but given the > lack of activity I think a gentler migration would imo be fine. > > Hen - To unsubscribe, e-mail: general-unsubscr...@jakarta.apache.org For additional commands, e-mail: general-h...@jakarta.apache.org
Re: [Jakarta Wiki] Update of "JakartaBoardReport-current" by MartinvandenBemt
Martin van den Bemt wrote: > If everyone is ok with it, I will send the current state of this page as > the board report ? Reconsider the "June 2009" ;-) - Jörg > > Mvgr, > Martin > - Original Message - > From: "Apache Wiki" > To: general@jakarta.apache.org > Sent: Monday, May 18, 2009 9:45:42 PM GMT +01:00 Amsterdam / Berlin / Bern > / Rome / Stockholm / Vienna Subject: [Jakarta Wiki] Update of > "JakartaBoardReport-current" by MartinvandenBemt > > Dear Wiki user, > > You have subscribed to a wiki page or wiki category on "Jakarta Wiki" for > change notification. > > The following page has been changed by MartinvandenBemt: > http://wiki.apache.org/jakarta/JakartaBoardReport-current > > -- > > === Status === > > - Chair to summarize Jakarta-wide news + the current state of affairs. > + It has been a while since I reported the last time. In june 2009 I > announced + that I wanted to be replaced because of time constraints, with > no one + volunteering. After that however I got caught up with what was > happening in my + personal life and also was shutdown for over 3 months, > which ended up in a + long period of silence. > + Now all major personal events (positive I might add, so please don't > worry) + have passed, I however still find myself fighting to find time > (and energy) to + spend at Apache. > + > + In the light of this, I hand in my resignation as VP Apache Jakarta. > + To my relieve a discussion about the (in reality already effective) > vacancy + started and some people stood up to volunteer to take over the > position. + > + I myself regret the long absence and silence and I hope it didn't cause > to + much worry and problems. > + > > === Releases === > > > - > To unsubscribe, e-mail: general-unsubscr...@jakarta.apache.org > For additional commands, e-mail: general-h...@jakarta.apache.org - To unsubscribe, e-mail: general-unsubscr...@jakarta.apache.org For additional commands, e-mail: general-h...@jakarta.apache.org
Re: [VOTE] Release Candidate JMeter 2.3 RC3
sebb wrote: [snip] > Thanks for all the useful information. > > I have not yet investigated why the IBM JVMs have problems with the > XMLSchema and XPath tests, but given that none of the other JVMs show > the same errors I'm not too worried. > > The other errors are all problems in the test code, rather than errors > in JMeter itself. > > I've fixed the Class Cast problem, and the tests now run OK on Windows and > Unix. > > Given that it is a release candidate rather than a full release, I'm > inclined to leave fixing these errors until the full release. +1 from me :) - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Candidate JMeter 2.3 RC3
Hi Sebastian, sebb wrote: > Following on from the helpful feedback on RC1, I've now created JMeter > 2.3 RC3 in the directory: > > http://people.apache.org/~sebb/jmeter-2.3/dist > > Site documentation is here: > http://people.apache.org/~sebb/jmeter-2.3/site > > > It should now build and test OK on Unix (and in non-English Locales). > > [Please note that the 2 BeanShell tests require the optional beanshell > jar to be downloaded from www.beanshell.org and put in the lib/opt > directory.] > > All feedback welcome. > > > [ ]+1 - the release candidate looks OK, proceed with releasing it > [ ]-1 - there is a problem (please indicate what it is) > > There have been quite a few major updates since 2.2, so I think it > would be prudent to release 2.3 initially as a release candidate; a > full release can follow in a month or so. > > sebb AT apache DOT org After using the offical bsh-2.0-beta-4.jar from the website (and not the one provided by Gentoo) the tests run much better. I build now RC3 with my complete compiler zoo, running "ant all test". One strange error is always present: The ClassFinder detects 72 TestCase classes, but 1 cannot be instantiated: = %< [java] Creating test suite [java] Scanning /home/joehni/java/jakarta-jmeter-2.3RC3/build/test,../lib/ext for test cases [java] ClassFinder found: 72 TestCase classes [java] INFO: JMeterGUIComponent: skipping some tests org.apache.jmeter.testbeans.gui.TestBeanGUI [java] Error adding test for class org.apache.jmeter.protocol.http.sampler.TestHTTPSamplersAgainstHttpMirrorServer java.lang.ClassCastException: org.apache.jmeter.protocol.http.sampler.TestHTTPSamplersAgainstHttpMirrorServer$1 [java] Created: 71 tests including 5 suites [java] Starting test run, test count = 1286 = %< Apart from this following JDKs run all the tests fine: - Blackdown 1.4.2_03 - Sun JDK 1.5.0_12 - Sun JDK 1.6.0_01 These JDKs failed: - IBM JDK 1.4.2_08 with = %< [java] There were 4 failures: [java] 1) testAssertionBadXSDFile(org.apache.jmeter.assertions.XMLSchemaAssertionTest)junit.framework.AssertionFailedError [java] at org.apache.jmeter.assertions.XMLSchemaAssertionTest.testAssertionBadXSDFile(XMLSchemaAssertionTest.java:107) [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [java] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:85) [java] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:58) [java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java(Compiled Code)) [java] at org.apache.jorphan.test.AllTests.main(AllTests.java:214) [java] 2) testAssertionBlankResult(org.apache.jmeter.assertions.XMLSchemaAssertionTest)junit.framework.AssertionFailedError [java] at org.apache.jmeter.assertions.XMLSchemaAssertionTest.testAssertionBlankResult(XMLSchemaAssertionTest.java:151) [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [java] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:85) [java] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:58) [java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java(Compiled Code)) [java] at org.apache.jorphan.test.AllTests.main(AllTests.java:214) [java] 3) testXMLTrailingcontent(org.apache.jmeter.assertions.XMLSchemaAssertionTest)junit.framework.AssertionFailedError [java] at org.apache.jmeter.assertions.XMLSchemaAssertionTest.testXMLTrailingcontent(XMLSchemaAssertionTest.java:164) [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [java] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:85) [java] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:58) [java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java(Compiled Code)) [java] at org.apache.jorphan.test.AllTests.main(AllTests.java:214) [java] 4) testAssertionBlankResult(org.apache.jmeter.assertions.XPathAssertionTest)junit.framework.AssertionFailedError [java] at org.apache.jmeter.assertions.XPathAssertionTest.testAssertionBlankResult(XPathAssertionTest.java:183) [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [java] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:85) [java] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:58) [java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java(Compiled Code)) [java] at org.apache.jorphan.test.AllTests.main(AllTests.java:214) [java] [java] FAILURES!!! [java] Tests
Re: [VOTE] Release Candidate JMeter 2.3 RC1
Hi Sebastian, sebb wrote: > On 06/07/07, Jörg Schaible <[EMAIL PROTECTED]> wrote: >> sebb wrote: >> >> > I've created JMeter 2.3 RC1 in the directory: >> > >> > http://people.apache.org/~sebb/jmeter-2.3/dist >> > >> > Site/Docs are here: >> > http://people.apache.org/~sebb/jmeter-2.3/site >> > >> > All feedback welcome. >> > >> > [ ]+1 - the release candidate looks OK, proceed with full release >> > [ ]-1 - there is a problem (please indicate what it is) >> > >> > sebb AT apache DOT org >> >> Hmmm. Downloaded and extracted both .tgz versions. Go into /lib, >> copy bsh.jar into it. cd .. > > Actually needs to be in lib/opt. It gets worse, if I move it there ... [java] Tests run: 1272, Failures: 8, Errors: 6 .. basically it does not find the BeanShellInterpreter anymore. >> Building with JDK 6 under Linux. Gentoo [snip] jmeter-report will be sent in private ... - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Candidate JMeter 2.3 RC1
sebb wrote:
> I've created JMeter 2.3 RC1 in the directory:
>
> http://people.apache.org/~sebb/jmeter-2.3/dist
>
> Site/Docs are here:
> http://people.apache.org/~sebb/jmeter-2.3/site
>
> All feedback welcome.
>
> [ ]+1 - the release candidate looks OK, proceed with full release
> [ ]-1 - there is a problem (please indicate what it is)
>
> sebb AT apache DOT org
Hmmm. Downloaded and extracted both .tgz versions. Go into /lib, copy
bsh.jar into it. cd ..
Building with JDK 6 under Linux.
ant clean test
... fails, not everything compiled
ant
... everything is build
ant test
... 9 Failures, 1 Error:
_test:
[echo]
[echo]gump.run = false
[echo]java.awt.headless = ${java.awt.headless}
[echo]test.headless =
[echo]user.dir = /home/joehni/java/jakarta-jmeter-2.3RC1
[echo]basedir = /home/joehni/java/jakarta-jmeter-2.3RC1
[echo]test dir = /home/joehni/java/jakarta-jmeter-2.3RC1/build/test
[echo]test dir gump
= /home/joehni/java/jakarta-jmeter-2.3RC1/build/test
[echo]testsaveservice.saveout = ${testsaveservice.saveout}
[echo]
[java] Setting up logging props using file: ./jmetertest.properties
[java] Using initializeProperties() from
org.apache.jmeter.util.JMeterUtils
[java] Setting up initial properties using: ./jmetertest.properties
[java] Initializing Properties: ./jmetertest.properties
[java] Setting JMeter
home: /home/joehni/java/jakarta-jmeter-2.3RC1/bin/./..
[java] java.version=1.6.0_01
[java] java.home=/opt/sun-jdk-1.6.0.01/jre
[java] user.dir=/home/joehni/java/jakarta-jmeter-2.3RC1/bin
[java] +++
[java] java.awt.headless=
[java] java.awt.graphicsenv=sun.awt.X11GraphicsEnvironment
[java]
[java] Creating test suite
[java]
Scanning /home/joehni/java/jakarta-jmeter-2.3RC1/build/test,../lib/ext for
test cases
[java] ClassFinder found: 72 TestCase classes
[java] INFO: JMeterGUIComponent: skipping some tests
org.apache.jmeter.testbeans.gui.TestBeanGUI
[java] Created: 72 tests including 5 suites
[java] Starting test run, test count = 1292
[java] .
[java] .
[java] .
[java] ...F...F..E.
[java] .
[java] ..F...
[java] .
[java] .
[java] .
[java] .
[java] .
[java] .
[java] .
[java] .
[java] .
[java] .
[java] .
[java] .
[java] .
[java] .
[java] .
[java] .
[java] .
[java] .
[java] .
[java] .
[java] .
[java] .
[java] F.title=mytitle&description=mydescription
[java]
[java]
[java]
[java] F.-7d159c1302d0y0
[java] Content-Disposition: form-data; name="title"
[java] Content-Type: text/plain; charset=ISO-8859-1
[java] Content-Transfer-Encoding: 8bit
[java]
[java] mytitle
[java] -7d159c1302d0y0
[java] Content-Disposition: form-data; name="description"
[java] Content-Type: text/plain; charset=ISO-8859-1
[java] Content-Transfer-Encoding: 8bit
[java]
[java] mydescription
[java] -7d159c1302d0y0--
[java]
[java]
[java]
[java]
[java] F..F.F
[java] .
[java] ..F...
[java] .
[java] Time: 34,24
[java] There was 1 error:
[java] 1) SFFTest
(org.apache.jmeter.functions.PackageTest)org.apache.jorphan.util.JMeterStopThreadException:
End of sequence
[java] at
org.apache.jmeter.functions.StringFromFile.execute(StringFromFile.java:281)
[java] at
org.apache.jmeter.functions.Abstr
RE: [VOTE] Commons moving to TLP
Folks, I am on holidays and offline for two weeks, so if anything is decided inbetween, the statement below is my official position. Cheers, Jörg Jörg Schaible wrote: > Hi Henri, > > Henri Yandell wrote on Wednesday, May 23, 2007 7:00 AM: > > [snip] > >> If that, or something like it, sounds like a good consensus plan, then >> I'm definitely more in favour of that than Commons going to TLP. There >> are really only four steps: >> >> Step 0: Consensus. >> Step 1: Move 3 projects to the Incubator. >> Step 2: Move other projects into Commons. >> Step 3: Re-establish Jakarta PMC - we'd use pretty much the same >> resolution we just voted on here. >> >> So the question is; is the above direction worth discussing, or should >> we just go with the Commons TLP. > > I voted +1 for commons TLP, but only since it seems the only solution for > a way out of this situation. If there is a possibility that in the end > Jakarta ends up as an enhanced commons, I'd prefer this. > > - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] Commons moving to TLP
Hi Henri, Henri Yandell wrote on Wednesday, May 23, 2007 7:00 AM: [snip] > If that, or something like it, sounds like a good consensus plan, then > I'm definitely more in favour of that than Commons going to TLP. There > are really only four steps: > > Step 0: Consensus. > Step 1: Move 3 projects to the Incubator. > Step 2: Move other projects into Commons. > Step 3: Re-establish Jakarta PMC - we'd use pretty much the same > resolution we just voted on here. > > So the question is; is the above direction worth discussing, or should > we just go with the Commons TLP. I voted +1 for commons TLP, but only since it seems the only solution for a way out of this situation. If there is a possibility that in the end Jakarta ends up as an enhanced commons, I'd prefer this. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [PROPOSAL] The future of Jakarta
Hi Stephen, Stephen Colebourne wrote on Tuesday, May 22, 2007 2:43 PM: [snip] > In summary: > a) I believe the status quo is not viable > b) I believe that merging commons into Jakarta merges two > mismatched groups > c) I believe that commons is big enough and strong enough to be a TLP > > So, I support Apache Commons TLP - Just as Tomcat grew up and > left the Jakarta brand name, so should Commons. But we should > assert our right for that to be Java only - we really did get > the name first, and the commons community (one-list, one-pmc) > is fundamentally tied to Java. The point is (b). Is it really that different: A merged jakarta commons vs. commons alone? Commons has also some projects with different weight. Compare lang and digester. Any current Jakarta project that feels uneasy with such an absorbtion (possibly HttpComponnets, Taglibs ??), may head for an own TLP. All the others will not make much difference - since there are view committers left and most of them have dwindling communities. Additionally most of the left ones fit quite good into commons like oro, regexp, ECS, ... - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [PROPOSAL] The future of Jakarta
Martin van den Bemt wrote on Tuesday, May 22, 2007 2:16 AM: > That's quite problematic : Jakarta is responsible for > jakarta.apache.org, not commons, sharing that > responsibility will just complicate things a lot. > > It's pretty simple to solve this though (even though > repeating myself here) : Let (a flattened) > commons become Jakarta.. +1 We have the brand and lot of people do not even recognize that Jakarta Commons != Jakarta (nor do they probably care). Especially now that most of the original jakarta projects went to TLPs. Assimilate the rest in one flat hierarchy. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [PROPOSAL] The future of Jakarta
Hi Danny, Danny Angus wrote on Monday, May 21, 2007 10:47 AM: > On 5/21/07, Jörg Schaible <[EMAIL PROTECTED]> wrote: > >> Any attempt in any kind of direction has been vetoed down > and for me it is pointless to bring the same arguments again > in a new thread. > > Jorg, > Searching through my mail I don't really see you advancing any > "arguments" about the future of Jakarta. > > Perhaps you could consider repeating them for the benefit of those of > us who didn't hear what you said? Well, I follow the discussion quite for a while and anything was already said or proposed by other people and I could not add something new. So I limited myself to vote. > It would be sad if people who have an opinion choose not to express it > in a thread explicity about the future of Jakarta on the pmc list > just because it may have already been expressed in Commons dev or poi > dev or wherever else. IMHO it does not help, repeating the same arguments. > On the other hand if there really is the level of apathy which the > inactivity in this thread hints at then the choices are pretty clear. So, here you do imply something ;-) But to recap, we had 1/ Open-up Jakarta to all committers, was vetoed 2/ Merge commons into Jakarta, was vetoed 3/ Move commons into own TLP, was vetoed So what's left in your opinion? I don't buy the Jakarta=Java-Portal solution, since I believe it fails the doing. Option 2 would have been my personal choice, since - we keep the brand - we state that we're Java centric - we wrap a greater community about "matured/left-over/maintained only" components Any Jakarta project that feels uneasy because it - has an isolated community - has a broader scope than "Java" should consider a TLP Option 3 from above was raised, because 2 did not make it and it would have forced the Jakarta left behind projects to make a real statement of their own. Now we're stuck to the status-quo and I see no way out of it anymore (or should we try to start a vote on those issues in periodic times of 6 months unless one of it passes?). Out of ideas, Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [PROPOSAL] The future of Jakarta
Torsten Curdt wrote on Thursday, May 17, 2007 1:42 AM: > so this thread died again without a conclusion or resulution. because there seems none. Any attempt in any kind of direction has been vetoed down and for me it is pointless to bring the same arguments again in a new thread. [snip] - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [RESULT] [VOTE] Move POI to TLP
Nick Burch wrote on Friday, May 11, 2007 1:28 PM: > On Fri, 11 May 2007, Jörg Schaible wrote: >> there were more votes: >> http://thread.gmane.org/gmane.comp.jakarta.general/9842 > > Hmm, that's odd. Yours doesn't seem to be showing on > mail-archives.apache.org, which is what I was using. Sorry I missed > you off! > > http://mail-archives.apache.org/mod_mbox/jakarta-poi-dev/20070 > 5.mbox/browser > http://mail-archives.apache.org/mod_mbox/jakarta-general/20070 > 5.mbox/browser Strange, indeed! :-/ - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [RESULT] [VOTE] Move POI to TLP
Hi Nick, there were more votes: http://thread.gmane.org/gmane.comp.jakarta.general/9842 at least you did not count mine... - Jörg Nick Burch wrote on Friday, May 11, 2007 1:00 PM: > Hi All > > The voting has now closed, and the votes are in. We had 23 +1 votes, > of which 15 were from pmc members. Martin will now present the > proposal to the board for their approval. > > Nick Burch (pmc) > Andrew Oliver (pmc) > David Fisher > Henri Yandel (pmc) > Avik Sengupta (pmc) > Rainer Klute > N. Hira > Joern Muehlencord > Davanum Srinivas (pmc) > Henning Schmiedehausen (pmc) > Petar Tahchiev > Sebb > Thomas Vandahl > Roland Weber (pmc) > Rahul Akolkar (pmc) > Mark Thomas (pmc) > Dennis Lundberg (pmc?) > Martin van den Bemt (pmc) > Scott Eade (pmc) > Stefan Bodewig (pmc) > Robert Burrell Donkin (pmc) > Shawn Laubach > Niall Pemberton (pmc) > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] Commons moving to TLP
+1 Henri Yandell wrote on Tuesday, May 08, 2007 7:20 PM: > Sadly a bit too late to make the next board meeting I suspect. > > However, here's a vote for Commons to officially request that > it move to TLP. > > http://wiki.apache.org/jakarta-commons/TLPResolution > > Please add your name if you're a Commons developer and haven't added > your name yet. > > [ ] +1 I support the proposal > [ ] +0 I don't care > [ ] -1 I'm opposed to the proposal because... > > Voting will close in one week. > > Hen > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] Move POI to TLP
+1 Nick Burch wrote on Friday, May 04, 2007 11:18 AM: > Hi All > > After lots of discussion within POI, and Jakarta in general, > we think POI > is ready to graduate to its own TLP. Thanks to the magic of ApacheCon, > lots of people have been on-hand to help finalise the > proposal for this, > which is attached below. > > So, now is the time to vote on the proposal: > [ ] +1 I support the proposal > [ ] +0 I don't care > [ ] -1 I'm opposed to the proposal because... > > Voting will close in one week. [snip] - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Move Turbine to TLP
+1 Scott Eade wrote: > The Turbine project has been discussing a proposal to the board that the > Turbine projects leave the Jakarta umbrella and become their own top > level project. We are now at the point in the process that calls for a > vote to take place. > > The proposal is available at: > http://wiki.apache.org/jakarta-turbine/TLPTurbine > > For the interested, most of the discussion took place in the following > thread: > http://www.nabble.com/-DISCUSS--TLP--tf3574436.html > > Here are the vote options: > [ ] +1 I support the proposal > [ ] +0 I don't care > [ ] -1 I'm opposed to the proposal because... > > Voting will close in one week. > > Thanks, > > Scott - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] Petar Tahchiev as Jakarta Committer
+1 Felipe Leme wrote on Sunday, March 25, 2007 4:17 PM: > Hi all, > > I'd like to call a vote to have Petar Tahchiev as a Jakarta Committer. > > Petar currently works as software engineer in Bulgaria, but was a MSc > student last year, when we proposed porting the Cactus build to Maven > 2 as a "GSOC" (Google Summer of Code) project. Although the project > didn't make it to the allotted ASF projects, Petar kept doing the > (hard) work, despite my slowness to support him. > > Prior to participate on Cactus development, he made some contributions > to Apache Ant and other ASF projects. He also has a blog at java.net > (http://weblogs.java.net/blog/paranoiabla/). > > A couple of months ago, I failed (again :-() to setup a sandbox SVN > branch at ASF for him to continue his work, so he ended up creating a > separated repository on SourceForge where we could do some work in > parallel. Now that code is ready to come back to the Jakarta codebase, > and the proper legal measures has already been taken (see > http://incubator.apache.org/ip-clearance/jakarta-cactus-tahchi > ev.html). > > Besides the technical aspect, I can tell from personal experience that > he is a talented and enthusiastic developer, and will be a valuable > contributor to the Cactus/Jakarta communities. So, here is my (PMC > binding) +1 vote. > > -- Felipe > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] Release Regexp 1.5
sebb wrote on Monday, March 19, 2007 3:09 PM: > On 19/03/07, Vadim Gritsenko <[EMAIL PROTECTED]> wrote: >> sebb wrote: >>> Surely voting on creating a tag (if this is necessary) >> >> Absolutely. Any release tag must be a community decision == vote is >> required. >> >> >>> is completely different from voting on a release? >> >> Not to me. >> >> Voting on a release (on a tag) signifies that software is in a state >> where it can be released to general public. >> >> Voting on a files (produced from release tag) is a mechanical vote on >> correctness of files produced by ant. >> > > AFAIK, the ASF rules are that files must not be released to the > general public without a formal vote by the PMC on the release, which > I take to mean voting on the files which are proposed to be released. > > Requiring consensus on tagging seems sensible, but I'm not > sure it is required. > > The problem here seems to be that it is not possible to use one vote > to do both; therefore it seems to me that the sensible thing to do is > to have two votes. > > The first vote (on tagging) seems to me to be something that relates > mainly to committers working on the project. > > The second vote has to involve PMC members; others can vote, but their > votes generally do not count (though I guess a -1 would need to be > investigated). And since no-one wants to vote twice, the vote is done on the released artifacts in the RM's private area (or a more official staging area). This includes also that the version is already tagged. If for whatever reason the vote does not pass we can drop the version from the SCM again ... since it did not represent a valid release anymore. > Seems to me that there needs to be formal documentation of the > required and recommended release processes. - Jörg BTW: I did not vote, exactly because I should have to check out from svn - and nobody can guarantee me that I have a proper environment to check the release I build myself. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [PROPOSAL] Create [EMAIL PROTECTED] mailinglist..
Rainer Klute wrote on Sunday, March 04, 2007 7:49 AM: > Daniel F. Savarese schrieb: >> In message <[EMAIL PROTECTED]>, "Andrew C. Oliver" writes: >> >>> lists. (If you disagree look at the list archive for >>> each over the last 6 months and see if you REALLY disagree in more >>> than THEORY). >>> >> >> At least for oro, some Linux distributions continue to ship it as >> part of their core packages. For example, Fedora Core 4, 5, and 6 >> all included it and 7 will include it as well. That's millions of >> real installations. It would be negligent to give the impression >> that Apache will no longer support the software should maintenance >> requests be made when there are in fact committers dedicated to >> doing the work. No, there haven't been any bug reports for oro for >> years and I don't know why it ships with Linux distributions, but it >> does and until it doesn't, it's not a "dead" project. There's no >> need for project-specific mailing lists anymore, but I'm -1 on >> putting up a "closed" page for any project with a user base that >> continues to require support and for which we are able to provide >> support. Users do need to be directed somewhere for support and I >> don't care if that's general@ or some other list as long as there's >> an avenue for providing that support. +1 > I strogly agree with Daniel. Even if there are no ongoing > activities on > a project, we should never, NEVER call it "dead" or give it any other > attributation with a negative tone. "Dormant" also has negative > implications. "Mature" would be fine. "Maintenance mode" - it implies that there is not much activity, but bugs get addressed. Additionally it has not that unfortunate touch of final i.e. new functionality/refactoring may happen if enough interested peaople work together. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Move Velocity to TLP
+1 Nathan Bubna wrote: > The Velocity project has for some time now been making plans for a > proposal to the board that the Velocity projects leave the Jakarta > umbrella and become their own top level project. Martin has asked us > to hold a vote on the proposal here before he passes it along to the > board. So... > > The proposal is available for your perusal at: > http://wiki.apache.org/jakarta/TLPVelocity > > For the interested, most of the discussion took place on the following > thread: > http://marc.theaimsgroup.com/?t=11553094014&r=1&w=2 > > And the vote happens here: > [ ] +1 I support the proposal > [ ] +0 I don't care > [ ] -1 I'm opposed to the proposal because... > > Thanks! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] Move Jakarta Cactus/JMeter to new Testing TLP
+1 (non-binding) What about the domrant commons-test? I already tried to reactivate the project, but due to a current lack of time I stopped this for now. Nevertheless I have a proposal in my outbox for an official attempt to reactivate it. - Jörg Felipe Leme wrote on Tuesday, April 18, 2006 6:42 PM: > Hi all, > > In the last months, there have been some discussions internally (at > Jakarta PMC, Cactus and JMeter lists) about creating a new Testing TLP > (Apache Top Level Project) and moving Cactus and JMeter out of Jakarta > to this new project (which eventually could grow and 'acquire' more > projects, like DbUnit). > > The overall consensus seems that such TLP should be created, even > though the previous proposal did not get enough votes (looks like it > was an misunderstanding from the way it was proposed). > > So, in order to move the process ahead, I would like to propose a new > vote here on the general list (I will notify the dev lists about it). > The options are: > > [ ] +1 I am favorable to the move and would like to > contribute to the new TLP > [ ] +1 I am favorable to the move but would not be > participating in the new TLP > [ ] +0 it does not matter to me > [ ] -1 I am against it because > > Notice that I have included 2 +1 options to make it clear that voting > +1 does not imply a participation in the new TLP - it only means an > agreement that these projects should leave Jakarta to form a new TLP. > OTOH, people willing to contribute to the new TLP might also propose > themselves to its PMC by editing the proposal on Jakarta's wiki > (http://wiki.apache.org/jakarta/TLPCactusAndJMeter). > > []s, > > -- Felipe > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invitation
robert burrell donkin wrote: > On Sat, 2006-03-18 at 23:32 -0500, Henri Yandell wrote: >> I'm assuming at the moment that this is a case of somebody spoofing >> Karthik's address. I doubt the spam is from Karthik - just something that >> snuck through the spamassassin and various other email controls and >> happens to be a subscribed address. > > looks like we're going to need to think about turning on address > checking sooner or later this year. probably need to think about ways to > allow committers to post from their apache addresses... My "standrad address" has definitely been used as spoofed address for sending spam and I also remember receiving other spam that claimed to be from some Apache commiters here. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Jakarta Language Components
Andrew C. Oliver wrote: > Stephen Colebourne wrote: >> Reposted (edited) from original commons proposal. >> Currently this proposal has general, though not unanimous, support. >> A vote thread may follow this thread if the mood remains positive. >> >> > ... >> >> Jakarta Language Components will: >> - develop multiple independent components > > I will vote -1 based soley on item 1 of the list for the reasons I've > already explained. I think that having ANOTHER jak-commons is a > fundementally bad idea. If these are truly enahancements to JavaSE, > they are one community, and share a mailinglist...then make them one > distribution and version them together. See the list for how many users complain already now about the *size* of some of those components. Obviously these are often people from the J2ME camp or people dealing with applets. OTOH if a look at my last bigger app and the proposed list, I find only two of the packages, that I did not use. The problem with providing a combined jar of all and separated ones are again the dependencies, that will be a real mess then. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Sandbox?
Yoav Shapira wrote: > Hola, > >> > Yoav (who still bristles at the name Jakarta X Components -- we need >> > to get creative!) >> >> Jakarta Core Components/Pills/Marbles/Gems/Diamonds >> Jakarta Web Components/Pills/Marbles/Gems/Diamonds > > Gems would be a particularly interesting choice in light of the Ruby > use of the term ;) > > I'm hoping for more of a one-word catchy name, like we had for Apache > Silk. Actually, like Jakarta itself, or Tomcat, or Xerces, or Struts. > These one-word names catch on and suggest an identity that is far > more sticky than a technical 3-word term like "Jakarta Web > Components." Those types of names become another drop in the TLA > (three letter acronym) soup very quickly... Since those Java Language Components have some kind of Core nature, I think of something solid ... what about Jakarta Rocks ... and we have additional a nice word-play :D - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Jakarta Sandbox?
Yoav Shapira wrote on Tuesday, March 07, 2006 2:47 PM: > Hola, > > > On 3/6/06, Henri Yandell <[EMAIL PROTECTED]> wrote: >> >> Over on Commons-Dev, Stephen has suggested that we split some of the >> components out to form a Jakarta Language Components group. Consensus >> is in favour of the idea, so I'm sure we'll see a vote on that and >> some movement soon. >> >> Commons ID (and Commons CSV perhaps) are two elements in the Commons >> Sandbox which would potentially go to JLC, but there are (wisely) no >> plans for a separare JLC Sandbox. > >> Thoughts? > > Stating the obvious here -- commons-lang would also go into this new > Jakarta Language Components, right? > > Yoav (who still bristles at the name Jakarta X Components -- we need > to get creative!) Jakarta Core Components/Pills/Marbles/Gems/Diamonds Jakarta Web Components/Pills/Marbles/Gems/Diamonds Take your choice ... :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
