Re: Release hell WAS: [VOTE] Release Apache Commons Codec 1.5-RC1
Le 30/03/2011 03:36, Gary Gregory a écrit : > Wait! I'm not done or I'm loosing my marbles... > > I followed the whole song and dance from: > > http://wiki.apache.org/commons/UsingNexus > > It's the last time I'll pick that route. For what its worth, for math 2.2 I used a mix of Phil scripts for the beginning and Nexus for the rest, using the wiki as a guideline. In this case the process was a little convoluted, because we create both a trimmed down version of the site to hold only the user guide and to be put in the docs archives, and we create a complete site to be uploaded. For the last release candidate, it worked well. Phil asked me to document it and extend the scripts if needed, and I forgot to do it in time, sorry :-( The one thing I found cumbersome was that part of the process pushed non-maven artifacts on Nexus, that had to be manually moved away. Furthermore, these are what we consider here the real Apache artifacts (i.e. the ones that are available in the download page, not the ones that are at last published in maven repository). I also have some slight concerns using a proprietary product, but as it secures some things as Sebb says, I can live with it. Is it possible to find some intermediate approach, extending Phil scripts, pushing only the maven part on Nexus directly without having to log on Nexus web interface ? The last part (not logging to close the staging area) may reduce the safety we get and risk some spurious publish as Sebb explained, but with several independent scripts, this could leverage the risk. Luc > > I cannot seem to have published the Maven bits to Maven places. There is no > 1.5 here: > > http://repo1.maven.org/maven2/commons-codec/commons-codec/ > > Because it is not here: > > /x1/www/people.apache.org/repo/m2-ibiblio-rsync-repository/commons-codec > > What does "Promote" out of Nexus do then? > > Should I copy the files to /www/ > people.apache.org/repo/m2-ibiblio-rsync-repository myself per > > http://commons.apache.org/releases/release.html > > under the section "3 Deploy Maven Artifacts"? > > Or will that cause problem with work I did in Nexus (for the last time?) > > Thank you > > Gary > > -- Forwarded message -- > From: sebb > Date: Tue, Mar 29, 2011 at 10:15 AM > Subject: Re: [VOTE] Release Apache Commons Codec 1.5-RC1 > To: Commons Developers List > > > On 29 March 2011 04:45, Gary Gregory wrote: >> On Mon, Mar 28, 2011 at 11:21 PM, Phil Steitz > wrote: >> >>> On 3/28/11 4:49 PM, Gary Gregory wrote: I am having a heck of a time pushing the release out. I cannot seem to be able to create the sym links per the instructions > in http://wiki.apache.org/commons/UsingNexus I cannot get the symlinks.sh script working. I copied it to my home bin directory. When I invoke it, it is not found. Just running it from my >>> home bin w/o args does give me the usage I get: >>> You need to run it from the dist directory where the links are going >>> to be created and you need to give it the release number. See steps >>> 1 and 2 here: >>> http://commons.apache.org/releases/release.html >>> >>> Step 2 assumes that the tars and zips have somehow made their way to >>> /www/www.apache.org/dist/commons/foo/ >>> >>> Step 1 provides instructions on how to move things there. I think >>> Nexus tries to do this moving for you. >>> >>> To get the symlinks created properly, you need to invoke symlinks.sh >>> with the release number as its command line argument from >>> /www/www.apache.org/dist/commons/foo/ >>> >>> For that to work, you have to have the script available and >>> executable. That should happen if you put it in your bin directory >>> and do chmod +x on it. Have a look at your .profile file (cat >>> ~/.profile). If it does not contain a line that looks something like >>> >>> > PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/usr/X11R6/bin:$HOME/bin; >>> export PATH >>> then you need to add that line (maybe minus the games and X11R6 >>> stuff) or just copy a new .profile. Let me know if you are having >>> problems with this and I will help. >>> >>> Sebb is right though that you should close the VOTE before moving >>> stuff to dist/ >>> >> >> Thank you for the detailed instructions. I am going to go through those >> next. >> >> I must have misunderstood the voting process, which I thought was, if all >> goes well: >> - Send a [VOTE] email (this thread) >> - Wait 72 hours >> - Send a [VOTE][RESULT] email: >> > http://mail-archives.apache.org/mod_mbox/commons-dev/201103.mbox/%3caanlktikgpm0lo-aoi8wfkjxznoxzodtgza2cwjdcq...@mail.gmail.com%3E >> >> Is there a [VOTE][CLOSE] email that needs to go out as well after 72 > hours? > > No, but for some reason I did not see the [RESULT] e-mail - sounds > like Phil did not either. > >> I can see that I should have mentioned the vote timeline in the [VOTE] > email >> as documented in http://commons.apache.org/releases
Re: Release hell WAS: [VOTE] Release Apache Commons Codec 1.5-RC1
On Mar 29, 2011, at 7:40 PM, Stephen Williams wrote: > On 3/29/11 7:33 PM, Ralph Goers wrote: >> On Mar 29, 2011, at 7:24 PM, Stephen Williams wrote: >>> ... >>> So, lesson learned: Don't use Maven! ;-) >>> No, the other one: make copies of your code through multiple means until it >>> is completely safe. I hadn't lost code (or any data through paranoid >>> backups that have survived about 20 hard drive failures over the years) for >>> a long time. It will be a very long time before it happens again. >>> >> I have no idea what you did, but Maven won't delete your source code doing a >> mvn clean install unless you've placed your source files under the "target" >> subdirectory. This could have just as easily been something Eclipse did to >> you as much as Maven. Maybe you should stop using Eclipse then. > > It was under 'src' at the project top... Using Eclipse, without Maven, > before and after has always worked fine. I've never seen Eclipse delete > source files automatically ever, other than when triggering that Maven build. > Probably it was some obscure thing about the already-existing Maven > environment or something. I couldn't explain it and didn't have extra time > or energy to debug or duplicate. But that's what happened. I don't doubt that it happened. I just doubt it was caused by Maven itself. I know of no operation that will delete the src directory or anything under it. While you are perfectly free to decide to not use Maven, basing the decision solely on the experience you related is not rational. The choice almost always comes down to Maven being "inflexible" (i.e. requiring you to do things its way) vs having hand coded builds with little consistency from project to project. Ralph
Re: Release Commons Pool 1.5.6 based on RC2
+1 :) Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Wed, Mar 30, 2011 at 8:17 AM, Phil Steitz wrote: > The tag is here: > http://svn.apache.org/repos/asf/commons/proper/pool/tags/POOL_1_5_6_RC2 > > The distribution zips/tars are here: > http://people.apache.org/~psteitz/pool-1.5.6-rc2/ > > Maven artifacts are here: > http://people.apache.org/~psteitz/pool-1.5.6-rc2/maven/ > > Site: > http://people.apache.org/~psteitz/pool-1.5.6-rc2/docs/ > > Release notes: > http://people.apache.org/~psteitz/pool-1.5.6-rc2/RELEASE-NOTES.txt > > Votes, please. This vote will close in 72 hours (2 April, 06:30 GMT). > > Thanks in advance. > > Phil > > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Release hell WAS: [VOTE] Release Apache Commons Codec 1.5-RC1
On Mar 30, 2011, at 12:01 AM, Luc Maisonobe wrote: > Le 30/03/2011 03:36, Gary Gregory a écrit : >> Wait! I'm not done or I'm loosing my marbles... >> >> I followed the whole song and dance from: >> >> http://wiki.apache.org/commons/UsingNexus >> >> It's the last time I'll pick that route. > > For what its worth, for math 2.2 I used a mix of Phil scripts for the > beginning and Nexus for the rest, using the wiki as a guideline. In this > case the process was a little convoluted, because we create both a > trimmed down version of the site to hold only the user guide and to be > put in the docs archives, and we create a complete site to be uploaded. > > For the last release candidate, it worked well. Phil asked me to > document it and extend the scripts if needed, and I forgot to do it in > time, sorry :-( > > The one thing I found cumbersome was that part of the process pushed > non-maven artifacts on Nexus, that had to be manually moved away. > Furthermore, these are what we consider here the real Apache artifacts > (i.e. the ones that are available in the download page, not the ones > that are at last published in maven repository). > > I also have some slight concerns using a proprietary product, but as it > secures some things as Sebb says, I can live with it. > > Is it possible to find some intermediate approach, extending Phil > scripts, pushing only the maven part on Nexus directly without having to > log on Nexus web interface ? The last part (not logging to close the > staging area) may reduce the safety we get and risk some spurious > publish as Sebb explained, but with several independent scripts, this > could leverage the risk. Is this what you are looking for? http://www.sonatype.com/books/nexus-book/reference/staging-sect-managing-plugin.html Ralph - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Release Commons Pool 1.5.6 based on RC2
+1 Two comments: - At the site top left javadocs for 1.5.6 are not linked - groupId is commons-pool. Shouldn't it change to org.apache or something? Guess that one is for later I have not checked sigs On Wed, Mar 30, 2011 at 8:17 AM, Phil Steitz wrote: > The tag is here: > http://svn.apache.org/repos/asf/commons/proper/pool/tags/POOL_1_5_6_RC2 > > The distribution zips/tars are here: > http://people.apache.org/~psteitz/pool-1.5.6-rc2/ > > Maven artifacts are here: > http://people.apache.org/~psteitz/pool-1.5.6-rc2/maven/ > > Site: > http://people.apache.org/~psteitz/pool-1.5.6-rc2/docs/ > > Release notes: > http://people.apache.org/~psteitz/pool-1.5.6-rc2/RELEASE-NOTES.txt > > Votes, please. This vote will close in 72 hours (2 April, 06:30 GMT). > > Thanks in advance. > > Phil > > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- http://www.grobmeier.de - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Release hell WAS: [VOTE] Release Apache Commons Codec 1.5-RC1
On 3/30/11 12:02 AM, Ralph Goers wrote: On Mar 29, 2011, at 7:40 PM, Stephen Williams wrote: On 3/29/11 7:33 PM, Ralph Goers wrote: On Mar 29, 2011, at 7:24 PM, Stephen Williams wrote: ... So, lesson learned: Don't use Maven! ;-) No, the other one: make copies of your code through multiple means until it is completely safe. I hadn't lost code (or any data through paranoid backups that have survived about 20 hard drive failures over the years) for a long time. It will be a very long time before it happens again. I have no idea what you did, but Maven won't delete your source code doing a mvn clean install unless you've placed your source files under the "target" subdirectory. This could have just as easily been something Eclipse did to you as much as Maven. Maybe you should stop using Eclipse then. It was under 'src' at the project top... Using Eclipse, without Maven, before and after has always worked fine. I've never seen Eclipse delete source files automatically ever, other than when triggering that Maven build. Probably it was some obscure thing about the already-existing Maven environment or something. I couldn't explain it and didn't have extra time or energy to debug or duplicate. But that's what happened. I don't doubt that it happened. I just doubt it was caused by Maven itself. I know of no operation that will delete the src directory or anything under it. While you are perfectly free to decide to not use Maven, basing the decision solely on the experience you related is not rational. The choice almost always comes down to Maven being "inflexible" (i.e. requiring It was rational given my evidence so far. Just not given your evidence. I'll chalk it up to an unlucky combination of beginner steps. I'm likely to dig into it again soon. you to do things its way) vs having hand coded builds with little consistency from project to project. I don't mind the consistency, however I am not happy when things are more complicated than they need to be. I see the advantage of Maven for automatically providing apt/yum/CPAN-like package management for Java. I'm just not sure it is the simplest way to do it or that it is something I'd choose for my own project code. Ralph sdw
Re: Release hell WAS: [VOTE] Release Apache Commons Codec 1.5-RC1
Le 30/03/2011 09:07, Ralph Goers a écrit : > > On Mar 30, 2011, at 12:01 AM, Luc Maisonobe wrote: > >> Le 30/03/2011 03:36, Gary Gregory a écrit : >>> Wait! I'm not done or I'm loosing my marbles... >>> >>> I followed the whole song and dance from: >>> >>> http://wiki.apache.org/commons/UsingNexus >>> >>> It's the last time I'll pick that route. >> >> For what its worth, for math 2.2 I used a mix of Phil scripts for the >> beginning and Nexus for the rest, using the wiki as a guideline. In this >> case the process was a little convoluted, because we create both a >> trimmed down version of the site to hold only the user guide and to be >> put in the docs archives, and we create a complete site to be uploaded. >> >> For the last release candidate, it worked well. Phil asked me to >> document it and extend the scripts if needed, and I forgot to do it in >> time, sorry :-( >> >> The one thing I found cumbersome was that part of the process pushed >> non-maven artifacts on Nexus, that had to be manually moved away. >> Furthermore, these are what we consider here the real Apache artifacts >> (i.e. the ones that are available in the download page, not the ones >> that are at last published in maven repository). >> >> I also have some slight concerns using a proprietary product, but as it >> secures some things as Sebb says, I can live with it. >> >> Is it possible to find some intermediate approach, extending Phil >> scripts, pushing only the maven part on Nexus directly without having to >> log on Nexus web interface ? The last part (not logging to close the >> staging area) may reduce the safety we get and risk some spurious >> publish as Sebb explained, but with several independent scripts, this >> could leverage the risk. > > Is this what you are looking for? > http://www.sonatype.com/books/nexus-book/reference/staging-sect-managing-plugin.html Almost. As a maven plugin, I suspect it will be difficult to select exactly what we want and what we don't want on nexus. For example I had to manually remove the non-maven artifacts (files for the donwload area and spurious checksum of signature files). With this plugin, I see we can list what has been uploaded but I don't see how to delete some of the files before closing the staging area. Luc > > Ralph > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[GUMP@vmgump]: Project commons-scxml-test (in module apache-commons) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at gene...@gump.apache.org. Project commons-scxml-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 170 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-scxml-test : Apache Commons Full details are available at: http://vmgump.apache.org/gump/public/apache-commons/commons-scxml-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -WARNING- Overriding Maven settings: [/srv/gump/public/workspace/apache-commons/scxml/gump_mvn_settings.xml] -DEBUG- (Apache Gump generated) Apache Maven Settings in: /srv/gump/public/workspace/apache-commons/scxml/gump_mvn_settings.xml -INFO- Failed with reason build failed -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/scxml/pom.xml -INFO- Project Reports in: /srv/gump/public/workspace/apache-commons/scxml/target/surefire-reports The following work was performed: http://vmgump.apache.org/gump/public/apache-commons/commons-scxml-test/gump_work/build_apache-commons_commons-scxml-test.html Work Name: build_apache-commons_commons-scxml-test (Type: Build) Work ended in a state of : Failed Elapsed: 18 secs Command Line: /opt/maven2/bin/mvn --batch-mode --settings /srv/gump/public/workspace/apache-commons/scxml/gump_mvn_settings.xml test [Working Directory: /srv/gump/public/workspace/apache-commons/scxml] M2_HOME: /opt/maven2 - --- T E S T S --- Running org.apache.commons.scxml.invoke.InvokeTestSuite Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.399 sec Running org.apache.commons.scxml.test.TestingTestSuite Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.01 sec Running org.apache.commons.scxml.env.EnvTestSuite Tests run: 21, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.167 sec Running org.apache.commons.scxml.SCXMLTestSuite Tests run: 71, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 3.02 sec <<< FAILURE! Running org.apache.commons.scxml.issues.IssuesTestSuite Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.347 sec Running org.apache.commons.scxml.model.ModelTestSuite Tests run: 78, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 2.259 sec <<< FAILURE! Running org.apache.commons.scxml.env.faces.EnvFacesTestSuite Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.006 sec Running org.apache.commons.scxml.semantics.SemanticsTestSuite Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.005 sec Running org.apache.commons.scxml.env.jsp.EnvJspTestSuite Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.048 sec Running org.apache.commons.scxml.env.jexl.EnvJexlTestSuite Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.052 sec Running org.apache.commons.scxml.env.servlet.EnvServletTestSuite Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Running org.apache.commons.scxml.io.IOTestSuite Tests run: 30, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.447 sec Results : Failed tests: testNamespacePrefixedXPathsEL(org.apache.commons.scxml.NamespacePrefixedXPathsTest) testDatamodelSimultaneousJsp(org.apache.commons.scxml.model.DatamodelTest) Tests run: 228, Failures: 2, Errors: 0, Skipped: 0 [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] There are test failures. Please refer to /srv/gump/public/workspace/apache-commons/scxml/target/surefire-reports for the individual test results. [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 17 seconds [INFO] Finished at: Wed Mar 30 10:36:43 UTC 2011 [INFO] Final Memory: 25M/61M [INFO] - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/apache-commons/commons-scxml-test/rss.xml - Atom: http://vmgump.apache.org/gump/public/apache-commons/commons-scxml-test/atom.xml == Gump Tracking Only === Produced by Apache Gump(TM) version 2.3. Gump Run 07000630032011, vmgump.apache.org:vmgump:07000630032011 Gump E-mail Identifier (unique with
Re: [Math] What's the problem with interfaces?
On Wed, Mar 30, 2011 at 02:21:04AM +0100, sebb wrote: > On 30 March 2011 01:15, Gilles Sadowski wrote: > > Hi. > > > >> We have been talking about moving away from interfaces as the > >> preferred way to support people plugging in alternative > >> implementations because they have in several places gotten "behind" > >> due to the fact that adding anything to them breaks compatibility. > >> We should probably continue that discussion in a different thread. > > > > [This is the different thread.] > > > > From comments that were posted to the other thread, I gather the main trend > > that, because some interfaces needed an upgrade, the "interface" design tool > > is becoming "evil". Did I get this right? > > It's not as clear-cut as that. > Interfaces have their place, but have drawbacks if the original > interface is later found wanting. I have no problem with that; especially, I am against creating interfaces just to follow the "programming by interface" paradigm. This was done at a few places in CM, and I wholeheartedly welcome the simplification brought by removing all interfaces for which there is only one implementation. > > I guess that you refer to "RandomData" and "RandomDataImpl". This is indeed > > the typical example of abusing the "interface" tool. When only one > > implementation is meaningful, an "interface" need not be defined. > > > > The "interface" is not the way (preferred or not) to support alternative > > implementations. As was already said, this is done with (abstract or not) > > classes which an alternative implementation can inherit from. > > Rather, the (Java) "interface" is supposed to represent the abstraction > > (from the "real" world object) of everything that is needed to interact with > > that object (i.e. its interface). It makes it possible to treat different > > objects on a equal footing (from the caller's point-of-view). > > But you all know that... > > > > So what's the problem? Is it the binary compatibility, again? This is a > > configuration management issue. When the compatibility is broken, you change > > the major version number and/or the base package name. That was settled, or > > not? > > That solves the problem, but at the cost of forcing all users to edit > and recompile, so should not be undertaken lightly. I'm sorry: I still might not have gotten something quite fundamental, as I continue to not understand. Either the user wants to use new features and he *has* to recompile or he doesn't want to be bothered by incompatible changes and he keeps using the previous release. The other case is when a bug has been discovered, so that the user might rightly want to use a drop-in replacement with the bug fixed. Then it is a release and support policy issue. The right thing would be to provide a compatible release with all bugs removed. As I see it, the problem in CM is one of lacking resources. IMHO erecting the binary compatibility principle as the ideal goal is not a substitute of support of old releases. As a mitigating measure, the minor numbers releases will be binary compatible. For the user, there remains the risk that a bug has been fixed before just before a major release: If he wants to benefit from that, he'll have to edit and recompile. That's the balance between the user's slight discomfort, sometimes, and a project that will be stuck in dead ends. > > It would be a pity to sacrifice a tool aimed at improving the design because > > of such considerations as keeping backward compatibility with versions that > > nobody here is going to support. > > If some user is happy with version "M.m", he can use it forever. If he wants > > to use a newer version "N.n", he should not expect it to be compatible. It > > does not have to be! Non-compatible modifications are not performed out of > > some urge for change but stem from the desire to get a better product, bits > > by bits. > > > > Yes, it's not easy to get the interfaces right; so what? If you find that > > you can improve the design, you do it and bump the major verion number. > > As someone pointed out, it's not as if we'll run out of numbers. > > But users could run out of patience if every release requires them to > edit and recompile. I'm not advocating for making each new release incompatible with the previous one. It's releasing too rarely which leads to this situation! Rather I'm in favour (and I'm not the only one in the Commons community) of releasing often, because there will be a higher probablility that a backward-compatible official release exists that contains the bug fixes which a user might want. > > Part of the real problem (as shown by the amazing amount of done and undone > > work for 2.2) is that you (collectively) want to do too many things at the > > same time (lots of changes *and* few releases). > > I don't think that's fair. > > Making lots of releases all of which may be binary incompatible with > each other just compounds the problem. > > IMO it's important to minimi
[GUMP@vmgump]: Project commons-id (in module commons-sandbox) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at gene...@gump.apache.org. Project commons-id has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 9 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-id : Commons Identifier Package Full details are available at: http://vmgump.apache.org/gump/public/commons-sandbox/commons-id/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole jar output [commons-id-30032011.jar] identifier set to project name -DEBUG- (Apache Gump generated) Apache Maven Properties in: /srv/gump/public/workspace/commons-sandbox/id/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /srv/gump/public/workspace/commons-sandbox/id/project.xml -DEBUG- Maven project properties in: /srv/gump/public/workspace/commons-sandbox/id/project.properties -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/commons-sandbox/commons-id/gump_work/build_commons-sandbox_commons-id.html Work Name: build_commons-sandbox_commons-id (Type: Build) Work ended in a state of : Failed Elapsed: 28 secs Command Line: maven --offline jar [Working Directory: /srv/gump/public/workspace/commons-sandbox/id] - [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.805 sec [junit] Running org.apache.commons.id.uuid.state.NodeTest [junit] Tests run: 8, Failures: 0, Errors: 0, Time elapsed: 0.304 sec [junit] Running org.apache.commons.id.uuid.state.ReadOnlyResourceStateImplTest [junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 0.454 sec [junit] Running org.apache.commons.id.uuid.state.ReadWriteFileStateImplTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.393 sec [junit] Running org.apache.commons.id.uuid.state.StateHelperTest [junit] Tests run: 6, Failures: 0, Errors: 0, Time elapsed: 0.301 sec [junit] Running org.apache.commons.id.uuid.state.InMemoryStateImplTest [junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 0.344 sec [junit] Running org.apache.commons.id.uuid.UUIDTest [junit] Tests run: 17, Failures: 0, Errors: 0, Time elapsed: 0.269 sec [junit] Running org.apache.commons.id.uuid.NodeManagerImplTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.434 sec [junit] Running org.apache.commons.id.uuid.task.UUIDTaskTest [junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 0.477 sec [junit] Running org.apache.commons.id.uuid.clock.ThreadClockImplTest [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.248 sec [junit] Running org.apache.commons.id.uuid.clock.SystemClockImplTest [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.249 sec [junit] Running org.apache.commons.id.serial.AlphanumericGeneratorTest [junit] Tests run: 9, Failures: 0, Errors: 0, Time elapsed: 0.264 sec [junit] Running org.apache.commons.id.serial.LongGeneratorTest [junit] Tests run: 8, Failures: 0, Errors: 0, Time elapsed: 0.264 sec [junit] Running org.apache.commons.id.serial.PrefixedNumericGeneratorTest [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0.251 sec [junit] Running org.apache.commons.id.serial.NumericGeneratorTest [junit] Tests run: 8, Failures: 0, Errors: 0, Time elapsed: 0.254 sec [junit] Running org.apache.commons.id.serial.PrefixedLeftPaddedNumericGeneratorTest [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0.25 sec [junit] Running org.apache.commons.id.serial.PrefixedAlphanumericGeneratorTest [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0.251 sec [junit] Running org.apache.commons.id.serial.TimeBasedAlphanumericIdentifierGeneratorTest [junit] Tests run: 12, Failures: 1, Errors: 0, Time elapsed: 0.742 sec [junit] [ERROR] TEST org.apache.commons.id.serial.TimeBasedAlphanumericIdentifierGeneratorTest FAILED [junit] Running org.apache.commons.id.CompositeIdentifierGeneratorTest [junit] Tests run: 7, Failures: 0, Errors: 0, Time elapsed: 0.27 sec [junit] Running org.apache.commons.id.ConstantIdentifierGeneratorTest [junit] Tests run: 6, Failures: 0, Errors: 0, Time elapsed: 0.262 sec BUILD FAILED File.. /home/gump/.maven/cache/maven-test-plugin-1.6.2/plugin.jelly Element... fail Line.. 181 Column 54 There were test failures. Total time: 26 seconds Finished at: Wed Mar 30 12:04:44 UTC 2011 - To subscribe to this inform
[GUMP@vmgump]: Project commons-proxy-test (in module apache-commons) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at gene...@gump.apache.org. Project commons-proxy-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 170 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-proxy-test : Apache Commons Full details are available at: http://vmgump.apache.org/gump/public/apache-commons/commons-proxy-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -WARNING- Overriding Maven settings: [/srv/gump/public/workspace/apache-commons/proxy/gump_mvn_settings.xml] -DEBUG- (Apache Gump generated) Apache Maven Settings in: /srv/gump/public/workspace/apache-commons/proxy/gump_mvn_settings.xml -INFO- Failed with reason build failed -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/proxy/pom.xml -INFO- Project Reports in: /srv/gump/public/workspace/apache-commons/proxy/target/surefire-reports The following work was performed: http://vmgump.apache.org/gump/public/apache-commons/commons-proxy-test/gump_work/build_apache-commons_commons-proxy-test.html Work Name: build_apache-commons_commons-proxy-test (Type: Build) Work ended in a state of : Failed Elapsed: 14 secs Command Line: /opt/maven2/bin/mvn --batch-mode --settings /srv/gump/public/workspace/apache-commons/proxy/gump_mvn_settings.xml test [Working Directory: /srv/gump/public/workspace/apache-commons/proxy] M2_HOME: /opt/maven2 - Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Running org.apache.commons.proxy.factory.util.TestMethodSignature Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec Running org.apache.commons.proxy.provider.TestConstantProvider Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Running org.apache.commons.proxy.interceptor.TestFilteredInterceptor Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.033 sec Running org.apache.commons.proxy.interceptor.filter.TestPatternFilter Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec Running org.apache.commons.proxy.interceptor.TestSerializingInterceptor Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.015 sec Running org.apache.commons.proxy.interceptor.TestInterceptorChain Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.007 sec Running org.apache.commons.proxy.invoker.TestNullInvoker Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.013 sec Running org.apache.commons.proxy.provider.remoting.TestBurlapProvider Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.009 sec Running org.apache.commons.proxy.exception.TestDelegateProviderException Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Running org.apache.commons.proxy.invoker.TestChainInvoker Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.01 sec Running org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory Tests run: 37, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.159 sec Running org.apache.commons.proxy.exception.TestProxyFactoryException Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec Running org.apache.commons.proxy.interceptor.filter.TestReturnTypeFilter Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Running org.apache.commons.proxy.provider.TestBeanProvider Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.007 sec Results : Tests in error: testInvalidHandlerName(org.apache.commons.proxy.invoker.TestXmlRpcInvoker) Tests run: 179, Failures: 0, Errors: 1, Skipped: 0 [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] There are test failures. Please refer to /srv/gump/public/workspace/apache-commons/proxy/target/surefire-reports for the individual test results. [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 12 seconds [INFO] Finished at: Wed Mar 30 12:05:55 UTC 2011 [INFO] Final Memory: 24M/58M [INFO] - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/apache-commons/commons-proxy-test/rss.xml - Atom: http://vmgump.apache.o
Re: [Math] What's the problem with interfaces?
Hi Jorg. > > > > From comments that were posted to the other thread, I gather the main > > trend that, because some interfaces needed an upgrade, the "interface" > > design tool is becoming "evil". Did I get this right? > > > > I guess that you refer to "RandomData" and "RandomDataImpl". This is > > indeed the typical example of abusing the "interface" tool. When only one > > implementation is meaningful, an "interface" need not be defined. > > No. It is about adding something to the interface, just like Phil said. If > you add a method to an abstract class, the dervied ones are still binary > compatible, the same does not apply for interfaces. > > We had discussions in *length* about this and I am not interested in > starting over again. Well, I was not part of those discussions, and CM is _still_ full of Java "interface"s; so I assume that it's acceptable that I give my point-of-view now. As I said, I'm not in favour of creating interface for the sake of having everything separated in "Foo" and "FooImpl". I understand that having an abstract class has some definite practical advantages. And for the things I had in mind and which I'm most concerned about (coherent design), it might well be a non-issue: "interface" could be changed to "abstract class". The problems might come from the one thing which you can do with interface but cannot with classes, namely, multiple inheritance. Did someone already analyze the situation in CM? The issue might well be resolved similarly to the debate about checked exceptions, i.e. within CM, "interface" may also prove to be an unneccessary feature of the Java language. > > The "interface" is not the way (preferred or not) to support alternative > > implementations. As was already said, this is done with (abstract or not) > > classes which an alternative implementation can inherit from. > > Rather, the (Java) "interface" is supposed to represent the abstraction > > (from the "real" world object) of everything that is needed to interact > > with that object (i.e. its interface). It makes it possible to treat > > different objects on a equal footing (from the caller's point-of-view). > > But you all know that... > > > > So what's the problem? Is it the binary compatibility, again? This is a > > configuration management issue. When the compatibility is broken, you > > change the major version number and/or the base package name. That was > > settled, or not? > > The point is that an interface should not be changed for a long time. > Otherwise every new release is a major one. It is not a question of time but of major (incompatible) and minor (compatible) releases. As I noted in the reply to Sebb, the real problem is not supporting older releases. That's a policy issue. > > It would be a pity to sacrifice a tool aimed at improving the design > > because of such considerations as keeping backward compatibility with > > versions that nobody here is going to support. > > It's a pity for the user, because he will *never* be able to use the next > version as drop in. I also answered that in other post. > > If some user is happy with version "M.m", he can use it forever. If he > > wants to use a newer version "N.n", he should not expect it to be > > compatible. It does not have to be! Non-compatible modifications are not > > performed out of some urge for change but stem from the desire to get a > > better product, bits by bits. > > If that were true, you would currently have 10 different commons-lang, 10 > different commons-collections and so on in your classpath. No, it's the user's choice to select which version he wants. You cannot have multiple versions of Linux running at the same time, but nevertheless the kernel developers make releases at a much higher pace than Commons... > > Yes, it's not easy to get the interfaces right; so what? If you find that > > you can improve the design, you do it and bump the major verion number. > > As someone pointed out, it's not as if we'll run out of numbers. > > And people will stop using it, because they are annoyed when they are > depending in the end on n different versions of math, simply because of > transitive dependencies. I think that you reason on the basic assumption that CM is close to stability. Many problems (some bugs but also design consistency) have shown that it is not. So, my opinion is that users will prefer a product that continues to improve rather than something that is backward-compatible. I'm one of those. If not, I'd be content with what is there and would not feel the need to contribute. > > Part of the real problem (as shown by the amazing amount of done and > > undone work for 2.2) is that you (collectively) want to do too many things > > at the same time (lots of changes *and* few releases). To be clear, the > > problem is not the "lots of changes" part (which you would like to "solve" > > by vetoing future compatibility-breaking improvements). Note that the > > following is not a
Re: svn commit: r1086810 - /commons/proper/pool/branches/POOL_1_X/pom.xml
On 30 March 2011 06:30, Phil Steitz wrote: > On 3/29/11 6:30 PM, sebb wrote: >> On 30 March 2011 01:13, wrote: >>> Author: psteitz >>> Date: Wed Mar 30 00:13:51 2011 >>> New Revision: 1086810 >>> >>> URL: http://svn.apache.org/viewvc?rev=1086810&view=rev >>> Log: >>> Upgraded parent pom, downgraded assembly plugin to working version. >> What is the exact problem? I'm happy to raise a bug and create test >> cases etc., but I don't know what the issue is. > > Per Niall's comments during the vote on parent 19 or 20, with the > later version of the assembly plugin in the current Commons parent > mvn -Prc -DcreateChecksum=true install > does not create, sign and install the tars/zips to the local repo. Of course - sorry, I remember now. > Phil >> >>> Modified: >>> commons/proper/pool/branches/POOL_1_X/pom.xml >>> >>> Modified: commons/proper/pool/branches/POOL_1_X/pom.xml >>> URL: >>> http://svn.apache.org/viewvc/commons/proper/pool/branches/POOL_1_X/pom.xml?rev=1086810&r1=1086809&r2=1086810&view=diff >>> == >>> --- commons/proper/pool/branches/POOL_1_X/pom.xml (original) >>> +++ commons/proper/pool/branches/POOL_1_X/pom.xml Wed Mar 30 00:13:51 2011 >>> @@ -22,7 +22,7 @@ >>> >>> org.apache.commons >>> commons-parent >>> - 17 >>> + 20 >>> >>> 4.0.0 >>> commons-pool >>> @@ -148,6 +148,10 @@ >>> maven-source-plugin >>> 2.1 >>> >>> + >>> + maven-assembly-plugin >>> + 2.2-beta-5 >>> + >>> >>> >>> src/java >>> >>> >>> >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Math] What's the problem with interfaces?
Le 30/03/2011 13:33, Gilles Sadowski a écrit : > On Wed, Mar 30, 2011 at 02:21:04AM +0100, sebb wrote: >> On 30 March 2011 01:15, Gilles Sadowski wrote: >>> Hi. >>> We have been talking about moving away from interfaces as the preferred way to support people plugging in alternative implementations because they have in several places gotten "behind" due to the fact that adding anything to them breaks compatibility. We should probably continue that discussion in a different thread. >>> >>> [This is the different thread.] >>> >>> From comments that were posted to the other thread, I gather the main trend >>> that, because some interfaces needed an upgrade, the "interface" design tool >>> is becoming "evil". Did I get this right? >> >> It's not as clear-cut as that. >> Interfaces have their place, but have drawbacks if the original >> interface is later found wanting. > > I have no problem with that; especially, I am against creating interfaces > just to follow the "programming by interface" paradigm. > This was done at a few places in CM, and I wholeheartedly welcome the > simplification brought by removing all interfaces for which there is only > one implementation. I guess we all agree on this. There are many places where interfaces as the right way to go, and there are some misuses too that we try to avoid. > >>> I guess that you refer to "RandomData" and "RandomDataImpl". This is indeed >>> the typical example of abusing the "interface" tool. When only one >>> implementation is meaningful, an "interface" need not be defined. >>> >>> The "interface" is not the way (preferred or not) to support alternative >>> implementations. As was already said, this is done with (abstract or not) >>> classes which an alternative implementation can inherit from. >>> Rather, the (Java) "interface" is supposed to represent the abstraction >>> (from the "real" world object) of everything that is needed to interact with >>> that object (i.e. its interface). It makes it possible to treat different >>> objects on a equal footing (from the caller's point-of-view). >>> But you all know that... >>> >>> So what's the problem? Is it the binary compatibility, again? This is a >>> configuration management issue. When the compatibility is broken, you change >>> the major version number and/or the base package name. That was settled, or >>> not? >> >> That solves the problem, but at the cost of forcing all users to edit >> and recompile, so should not be undertaken lightly. > > I'm sorry: I still might not have gotten something quite fundamental, as I > continue to not understand. > Either the user wants to use new features and he *has* to recompile or he > doesn't want to be bothered by incompatible changes and he keeps using the > previous release. > The other case is when a bug has been discovered, so that the user might > rightly want to use a drop-in replacement with the bug fixed. Then it is a > release and support policy issue. The right thing would be to provide a > compatible release with all bugs removed. As I see it, the problem in CM is > one of lacking resources. IMHO erecting the binary compatibility principle > as the ideal goal is not a substitute of support of old releases. You have perfectly identified the problems. We do try to add features and improve existing ones, and we also try to fix bugs. The recent history is an example of trying to address both goals in two different development branches: trunk for 3.0 new features on one side and a branch for 2.X fixes. Near the end, it was a nightmare to handle. A few part of the team was working only on the 3.0 features, another part was trying to only fix bugs in 2.X and port the fixes in 3.0, and yet from time to time there were attempts to retrofit interesting stuff between the branches. In addition, we changed our mind before releasing and had to roll back. Our main priority has been to avoid incompatible changes at some stages (minor releases), and to allow them at other stages (major releases). I completely agree with you that we must go forward and that sometimes change is needed, we are precisely at one such point so we can do a lot of things just now. I also agree it is difficult to get an interface right the first time. So sometimes, an abstract class may be better if an interface is not mandatory. That does not mean interfaces are forbidden, of course. For some (in fact many) cases, they are good. Just as Sebb said, it's not clear-cut, there are fuzzy borders. > As a mitigating measure, the minor numbers releases will be binary > compatible. For the user, there remains the risk that a bug has been fixed > before just before a major release: If he wants to benefit from that, he'll > have to edit and recompile. That's the balance between the user's slight > discomfort, sometimes, and a project that will be stuck in dead ends. Yes. > >>> It would be a pity to sacrifice a tool aimed at improving the design because >>> of such c
Re: Release hell WAS: [VOTE] Release Apache Commons Codec 1.5-RC1
On 30 March 2011 08:07, Ralph Goers wrote: > > On Mar 30, 2011, at 12:01 AM, Luc Maisonobe wrote: > >> Le 30/03/2011 03:36, Gary Gregory a écrit : >>> Wait! I'm not done or I'm loosing my marbles... >>> >>> I followed the whole song and dance from: >>> >>> http://wiki.apache.org/commons/UsingNexus >>> >>> It's the last time I'll pick that route. >> >> For what its worth, for math 2.2 I used a mix of Phil scripts for the >> beginning and Nexus for the rest, using the wiki as a guideline. In this >> case the process was a little convoluted, because we create both a >> trimmed down version of the site to hold only the user guide and to be >> put in the docs archives, and we create a complete site to be uploaded. >> >> For the last release candidate, it worked well. Phil asked me to >> document it and extend the scripts if needed, and I forgot to do it in >> time, sorry :-( >> >> The one thing I found cumbersome was that part of the process pushed >> non-maven artifacts on Nexus, that had to be manually moved away. >> Furthermore, these are what we consider here the real Apache artifacts >> (i.e. the ones that are available in the download page, not the ones >> that are at last published in maven repository). >> >> I also have some slight concerns using a proprietary product, but as it >> secures some things as Sebb says, I can live with it. >> >> Is it possible to find some intermediate approach, extending Phil >> scripts, pushing only the maven part on Nexus directly without having to >> log on Nexus web interface ? The last part (not logging to close the >> staging area) may reduce the safety we get and risk some spurious >> publish as Sebb explained, but with several independent scripts, this >> could leverage the risk. > > Is this what you are looking for? > http://www.sonatype.com/books/nexus-book/reference/staging-sect-managing-plugin.html Oh dear. I was hoping that had not been implemented. Using that plugin means that one can effectively bypass Nexus. > > Ralph > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Release hell WAS: [VOTE] Release Apache Commons Codec 1.5-RC1
On 30 March 2011 08:01, Luc Maisonobe wrote: > Le 30/03/2011 03:36, Gary Gregory a écrit : >> Wait! I'm not done or I'm loosing my marbles... >> >> I followed the whole song and dance from: >> >> http://wiki.apache.org/commons/UsingNexus >> >> It's the last time I'll pick that route. > > For what its worth, for math 2.2 I used a mix of Phil scripts for the > beginning and Nexus for the rest, using the wiki as a guideline. In this > case the process was a little convoluted, because we create both a > trimmed down version of the site to hold only the user guide and to be > put in the docs archives, and we create a complete site to be uploaded. > > For the last release candidate, it worked well. Phil asked me to > document it and extend the scripts if needed, and I forgot to do it in > time, sorry :-( > > The one thing I found cumbersome was that part of the process pushed > non-maven artifacts on Nexus, that had to be manually moved away. > Furthermore, these are what we consider here the real Apache artifacts > (i.e. the ones that are available in the download page, not the ones > that are at last published in maven repository). I asked about extending Nexus so it could handle non-Maven staging, and that did seem to be possible, but whether it will ever be implemented, I don't know. That would be ideal. > I also have some slight concerns using a proprietary product, but as it > secures some things as Sebb says, I can live with it. > > Is it possible to find some intermediate approach, extending Phil > scripts, pushing only the maven part on Nexus directly without having to > log on Nexus web interface ? The last part (not logging to close the > staging area) may reduce the safety we get and risk some spurious > publish as Sebb explained, but with several independent scripts, this > could leverage the risk. Separating the deployments of Maven and non-Maven artifacts might be possible, but I'm not sure I have enough Maven-foo to do it. It would mean removing the non-maven stuff from deploy, and using some other means to copy the non-maven stuff to a separate staging directory. > Luc > >> >> I cannot seem to have published the Maven bits to Maven places. There is no >> 1.5 here: >> >> http://repo1.maven.org/maven2/commons-codec/commons-codec/ >> >> Because it is not here: >> >> /x1/www/people.apache.org/repo/m2-ibiblio-rsync-repository/commons-codec >> >> What does "Promote" out of Nexus do then? >> >> Should I copy the files to /www/ >> people.apache.org/repo/m2-ibiblio-rsync-repository myself per >> >> http://commons.apache.org/releases/release.html >> >> under the section "3 Deploy Maven Artifacts"? >> >> Or will that cause problem with work I did in Nexus (for the last time?) >> >> Thank you >> >> Gary >> >> -- Forwarded message -- >> From: sebb >> Date: Tue, Mar 29, 2011 at 10:15 AM >> Subject: Re: [VOTE] Release Apache Commons Codec 1.5-RC1 >> To: Commons Developers List >> >> >> On 29 March 2011 04:45, Gary Gregory wrote: >>> On Mon, Mar 28, 2011 at 11:21 PM, Phil Steitz >> wrote: >>> On 3/28/11 4:49 PM, Gary Gregory wrote: > I am having a heck of a time pushing the release out. > > I cannot seem to be able to create the sym links per the instructions >> in > http://wiki.apache.org/commons/UsingNexus > > I cannot get the symlinks.sh script working. I copied it to my home bin > directory. When I invoke it, it is not found. Just running it from my home > bin w/o args does give me the usage I get: > You need to run it from the dist directory where the links are going to be created and you need to give it the release number. See steps 1 and 2 here: http://commons.apache.org/releases/release.html Step 2 assumes that the tars and zips have somehow made their way to /www/www.apache.org/dist/commons/foo/ Step 1 provides instructions on how to move things there. I think Nexus tries to do this moving for you. To get the symlinks created properly, you need to invoke symlinks.sh with the release number as its command line argument from /www/www.apache.org/dist/commons/foo/ For that to work, you have to have the script available and executable. That should happen if you put it in your bin directory and do chmod +x on it. Have a look at your .profile file (cat ~/.profile). If it does not contain a line that looks something like >> PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/usr/X11R6/bin:$HOME/bin; export PATH then you need to add that line (maybe minus the games and X11R6 stuff) or just copy a new .profile. Let me know if you are having problems with this and I will help. Sebb is right though that you should close the VOTE before moving stuff to dist/ >>> >>> Thank you for the detailed instructions. I am going to go through those >>> next. >>> >>> I must have mi
Re: [codec] Moving on to codec 2.0
On Tue, Mar 29, 2011 at 8:52 PM, sebb wrote: > I think that should be avoided unless the API is also being changed in > an incompatible way, and then only if it really is impossible to > maintain backwards compatibility. I think there are excellent reasons to change the API in codec. Reasons include lack of support for streaming in most cases, lack of support for integration in SAX or StAX streams and the like, which could be relatively easy with standard interfaces. Take, for example, http://www.jarvana.com/jarvana/view/org/apache/ws/commons/util/ws-commons-util/1.0.2/ws-commons-util-1.0.2-javadoc.jar!/org/apache/ws/commons/util/Base64.html -- I Am What I Am And That's All What I Yam (Popeye) - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Release hell WAS: [VOTE] Release Apache Commons Codec 1.5-RC1
On 3/30/11 5:39 AM, sebb wrote: > On 30 March 2011 08:01, Luc Maisonobe wrote: >> Le 30/03/2011 03:36, Gary Gregory a écrit : >>> Wait! I'm not done or I'm loosing my marbles... >>> >>> I followed the whole song and dance from: >>> >>> http://wiki.apache.org/commons/UsingNexus >>> >>> It's the last time I'll pick that route. >> For what its worth, for math 2.2 I used a mix of Phil scripts for the >> beginning and Nexus for the rest, using the wiki as a guideline. In this >> case the process was a little convoluted, because we create both a >> trimmed down version of the site to hold only the user guide and to be >> put in the docs archives, and we create a complete site to be uploaded. >> >> For the last release candidate, it worked well. Phil asked me to >> document it and extend the scripts if needed, and I forgot to do it in >> time, sorry :-( >> >> The one thing I found cumbersome was that part of the process pushed >> non-maven artifacts on Nexus, that had to be manually moved away. >> Furthermore, these are what we consider here the real Apache artifacts >> (i.e. the ones that are available in the download page, not the ones >> that are at last published in maven repository). > I asked about extending Nexus so it could handle non-Maven staging, > and that did seem to be possible, but whether it will ever be > implemented, I don't know. > > That would be ideal. > >> I also have some slight concerns using a proprietary product, but as it >> secures some things as Sebb says, I can live with it. >> >> Is it possible to find some intermediate approach, extending Phil >> scripts, pushing only the maven part on Nexus directly without having to >> log on Nexus web interface ? The last part (not logging to close the >> staging area) may reduce the safety we get and risk some spurious >> publish as Sebb explained, but with several independent scripts, this >> could leverage the risk. > Separating the deployments of Maven and non-Maven artifacts might be > possible, but I'm not sure I have enough Maven-foo to do it. > > It would mean removing the non-maven stuff from deploy, and using some > other means to copy the non-maven stuff to a separate staging > directory. > There is this cool command called "cp" that works very well. There is another one called "tar" and even one called "scp" ;) If the problem is that we want to be more paranoid than we are with the mirrors for the maven stuff, why can't we just get access and copy the files we want to put in the staging repo? Or write a simple script that moves the kind of thing that I have sitting now in http://people.apache.org/~psteitz/pool-1.5.6-rc2/maven/ to the "staging repository" and another script or command that "promotes" it. It seems ridiculous to me that we need to introduce a proprietary GUI tool to just move files on ASF hosts. Phil Phil >> Luc >> >>> I cannot seem to have published the Maven bits to Maven places. There is no >>> 1.5 here: >>> >>> http://repo1.maven.org/maven2/commons-codec/commons-codec/ >>> >>> Because it is not here: >>> >>> /x1/www/people.apache.org/repo/m2-ibiblio-rsync-repository/commons-codec >>> >>> What does "Promote" out of Nexus do then? >>> >>> Should I copy the files to /www/ >>> people.apache.org/repo/m2-ibiblio-rsync-repository myself per >>> >>> http://commons.apache.org/releases/release.html >>> >>> under the section "3 Deploy Maven Artifacts"? >>> >>> Or will that cause problem with work I did in Nexus (for the last time?) >>> >>> Thank you >>> >>> Gary >>> >>> -- Forwarded message -- >>> From: sebb >>> Date: Tue, Mar 29, 2011 at 10:15 AM >>> Subject: Re: [VOTE] Release Apache Commons Codec 1.5-RC1 >>> To: Commons Developers List >>> >>> >>> On 29 March 2011 04:45, Gary Gregory wrote: On Mon, Mar 28, 2011 at 11:21 PM, Phil Steitz >>> wrote: > On 3/28/11 4:49 PM, Gary Gregory wrote: >> I am having a heck of a time pushing the release out. >> >> I cannot seem to be able to create the sym links per the instructions >>> in >> http://wiki.apache.org/commons/UsingNexus >> >> I cannot get the symlinks.sh script working. I copied it to my home bin >> directory. When I invoke it, it is not found. Just running it from my > home >> bin w/o args does give me the usage I get: >> > You need to run it from the dist directory where the links are going > to be created and you need to give it the release number. See steps > 1 and 2 here: > http://commons.apache.org/releases/release.html > > Step 2 assumes that the tars and zips have somehow made their way to > /www/www.apache.org/dist/commons/foo/ > > Step 1 provides instructions on how to move things there. I think > Nexus tries to do this moving for you. > > To get the symlinks created properly, you need to invoke symlinks.sh > with the release number as its command line argument from > /www/www.apache.org/dist/commons/foo/ > > For that to work
Re: Release hell WAS: [VOTE] Release Apache Commons Codec 1.5-RC1
On Mar 30, 2011, at 12:04, Phil Steitz wrote: > On 3/30/11 5:39 AM, sebb wrote: >> On 30 March 2011 08:01, Luc Maisonobe wrote: >>> Le 30/03/2011 03:36, Gary Gregory a �crit : Wait! I'm not done or I'm loosing my marbles... I followed the whole song and dance from: http://wiki.apache.org/commons/UsingNexus It's the last time I'll pick that route. >>> For what its worth, for math 2.2 I used a mix of Phil scripts for the >>> beginning and Nexus for the rest, using the wiki as a guideline. In this >>> case the process was a little convoluted, because we create both a >>> trimmed down version of the site to hold only the user guide and to be >>> put in the docs archives, and we create a complete site to be uploaded. >>> >>> For the last release candidate, it worked well. Phil asked me to >>> document it and extend the scripts if needed, and I forgot to do it in >>> time, sorry :-( >>> >>> The one thing I found cumbersome was that part of the process pushed >>> non-maven artifacts on Nexus, that had to be manually moved away. >>> Furthermore, these are what we consider here the real Apache artifacts >>> (i.e. the ones that are available in the download page, not the ones >>> that are at last published in maven repository). >> I asked about extending Nexus so it could handle non-Maven staging, >> and that did seem to be possible, but whether it will ever be >> implemented, I don't know. >> >> That would be ideal. >> >>> I also have some slight concerns using a proprietary product, but as it >>> secures some things as Sebb says, I can live with it. >>> >>> Is it possible to find some intermediate approach, extending Phil >>> scripts, pushing only the maven part on Nexus directly without having to >>> log on Nexus web interface ? The last part (not logging to close the >>> staging area) may reduce the safety we get and risk some spurious >>> publish as Sebb explained, but with several independent scripts, this >>> could leverage the risk. >> Separating the deployments of Maven and non-Maven artifacts might be >> possible, but I'm not sure I have enough Maven-foo to do it. >> >> It would mean removing the non-maven stuff from deploy, and using some >> other means to copy the non-maven stuff to a separate staging >> directory. >> > There is this cool command called "cp" that works very well. There > is another one called "tar" and even one called "scp" ;) If the > problem is that we want to be more paranoid than we are with the > mirrors for the maven stuff, why can't we just get access and copy > the files we want to put in the staging repo? Or write a simple > script that moves the kind of thing that I have sitting now in > http://people.apache.org/~psteitz/pool-1.5.6-rc2/maven/ > to the "staging repository" and another script or command that > "promotes" it. It seems ridiculous to me that we need to introduce > a proprietary GUI tool to just move files on ASF hosts. +1. How we got a proprietary vendor in there I do not know but the value is not there for me now. I much prefer to keep on growing our own release management 'software' instead of learning more about the mysteries of maven-nexus. Releasing needs to be less of a time suck. Gary > > Phil > > Phil >>> Luc >>> I cannot seem to have published the Maven bits to Maven places. There is no 1.5 here: http://repo1.maven.org/maven2/commons-codec/commons-codec/ Because it is not here: /x1/www/people.apache.org/repo/m2-ibiblio-rsync-repository/commons-codec What does "Promote" out of Nexus do then? Should I copy the files to /www/ people.apache.org/repo/m2-ibiblio-rsync-repository myself per http://commons.apache.org/releases/release.html under the section "3 Deploy Maven Artifacts"? Or will that cause problem with work I did in Nexus (for the last time?) Thank you Gary -- Forwarded message -- From: sebb Date: Tue, Mar 29, 2011 at 10:15 AM Subject: Re: [VOTE] Release Apache Commons Codec 1.5-RC1 To: Commons Developers List On 29 March 2011 04:45, Gary Gregory wrote: > On Mon, Mar 28, 2011 at 11:21 PM, Phil Steitz wrote: >> On 3/28/11 4:49 PM, Gary Gregory wrote: >>> I am having a heck of a time pushing the release out. >>> >>> I cannot seem to be able to create the sym links per the instructions in >>> http://wiki.apache.org/commons/UsingNexus >>> >>> I cannot get the symlinks.sh script working. I copied it to my home bin >>> directory. When I invoke it, it is not found. Just running it from my >> home >>> bin w/o args does give me the usage I get: >>> >> You need to run it from the dist directory where the links are going >> to be created and you need to give it the release number. See steps >> 1 and 2 here: >> http://commons.apache.org/releases/release.html >> >>>
Re: [Math] What's the problem with interfaces?
I think that you reason on the basic assumption that CM is close to stability. Many problems (some bugs but also design consistency) have shown that it is not. So, my opinion is that users will prefer a product that continues to improve rather than something that is backward-compatible. I'm one of those. If not, I'd be content with what is there and would not feel the need to contribute. I'm a user as well and agree with this. I'd gladly deal with upgrading my code and configuration if it means that CM has gotten more elegant from an architectural point of view. Cheers, - Ole - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [codec] Moving on to codec 2.0
On 30 March 2011 16:19, Jochen Wiedmann wrote: > On Tue, Mar 29, 2011 at 8:52 PM, sebb wrote: > >> I think that should be avoided unless the API is also being changed in >> an incompatible way, and then only if it really is impossible to >> maintain backwards compatibility. > > I think there are excellent reasons to change the API in codec. > Reasons include lack of support for streaming in most cases, lack of > support for integration in SAX or StAX streams and the like, which > could be relatively easy with standard interfaces. Take, for example, > > > http://www.jarvana.com/jarvana/view/org/apache/ws/commons/util/ws-commons-util/1.0.2/ws-commons-util-1.0.2-javadoc.jar!/org/apache/ws/commons/util/Base64.html > But does the API have to change, or could these additional features be supported by adding new methods and classes? For example, I originally thought that the fixes to Net NNTP to support long article Ids would require a compatibilty break, as ints were used throughout, but having done the work it turned out that compatibility could be maintained by adding one or two new classes, and some new methods. Users wanting to use the new methods will of course have to edit and recompile, but other Net users won't be affected. > > -- > I Am What I Am And That's All What I Yam (Popeye) > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Math] What's the problem with interfaces?
We are mixing two things in this thread - how much we care about backward compatibility and how and when to use interfaces. I think we need to settle both topics. I have stated my view, which is really just to standard Commons policy, on the backward compatibility issue. Based on many years experience using, developing and maintaining libraries here and elsewhere, I agree with others who have stated that constant incompatible change makes a library almost worthless for use across a wide range of applications. Something just used inside one application or relatively small development group can be constantly refactored and productively used; but broadly reusable components need to have stable APIs. Incompatible changes have to be well-documented and introduced in major releases that are relatively few and far between. That is essentially how we have operated in Commons for 10+ years now and it is the reason that some suggest that when we do a major API refactoring of a component we change the package name and even the component name. I don't buy the argument that we really *need* to keep making incompatible API changes in [math] because there are features or bugs that can't be added in compatible ways. I have seen only a tiny handful of these - just one in 2.2. Luc mentions SVD as a frustrating problem for us. The bugs have nothing to do with the API definition, unless I am missing something basic. We have numerical problems. We need to solve them. Gilles is right that we have limited resources. I would much rather that these resources be focused on solving the numerical and algorithmic problems involved in delivering robust and stable mathematical software than endless arguments about how to refactor the API. As a user, I would be much happier with a stable API with a few warts that provides well-documented, well-tested (because lots of users are using the *same* core impl) mathematics than a beautiful but unstable API with buggy implementation code. Regarding interfaces, I think we are starting to focus on the right question. I think we agree that use of interfaces just to separate interface from implementation in support of the strategy pattern is, let's just say "deprecated." When we started [math] back in 2003, that was not considered bad design. We went overboard with it, though, and ran into the problems we have been discussing on this thread around extensibility. Most of the bad designs came from my contributions, so I have to apologize for putting us into this position. To allow multiple implementations of a fully defined interface, we seem to have learned in Commons that abstract classes work better. I am fine with that principle and will volunteer to start first suggesting and discussing changes individually and then making them. I already started this with RandomData/RandomDataImpl. We can continue discussion on that thread about whether we even need an abstract class in that case. Other use for interfaces are to a) designate behaviors for implementation units that can be "plugged in" to algorithms (where the interface defines only some of the behaviors of the class - as in the multiple inheritance example). An example of this is the RandomGenerator interface, which encapsulates the behavior of a low-level source of random data. b) encapsulate abstract data types, e.g. Field. I think we need to keep at least these interfaces, but we should think long and hard about exactly what they should contain. Here again, I think we need to look at each example individually. Examples like RealMatrix could be argued to be good "b)" examples or restrictive handcuffs that should be eliminated. I think we need to be very careful with these decisions so that we can aim to really stabilize the API in 3.0. I honestly do not think that is an unrealistic expectation. Phil - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Release hell WAS: [VOTE] Release Apache Commons Codec 1.5-RC1
On 30 March 2011 17:03, Phil Steitz wrote: > On 3/30/11 5:39 AM, sebb wrote: >> On 30 March 2011 08:01, Luc Maisonobe wrote: >>> Le 30/03/2011 03:36, Gary Gregory a écrit : Wait! I'm not done or I'm loosing my marbles... I followed the whole song and dance from: http://wiki.apache.org/commons/UsingNexus It's the last time I'll pick that route. >>> For what its worth, for math 2.2 I used a mix of Phil scripts for the >>> beginning and Nexus for the rest, using the wiki as a guideline. In this >>> case the process was a little convoluted, because we create both a >>> trimmed down version of the site to hold only the user guide and to be >>> put in the docs archives, and we create a complete site to be uploaded. >>> >>> For the last release candidate, it worked well. Phil asked me to >>> document it and extend the scripts if needed, and I forgot to do it in >>> time, sorry :-( >>> >>> The one thing I found cumbersome was that part of the process pushed >>> non-maven artifacts on Nexus, that had to be manually moved away. >>> Furthermore, these are what we consider here the real Apache artifacts >>> (i.e. the ones that are available in the download page, not the ones >>> that are at last published in maven repository). >> I asked about extending Nexus so it could handle non-Maven staging, >> and that did seem to be possible, but whether it will ever be >> implemented, I don't know. >> >> That would be ideal. >> >>> I also have some slight concerns using a proprietary product, but as it >>> secures some things as Sebb says, I can live with it. >>> >>> Is it possible to find some intermediate approach, extending Phil >>> scripts, pushing only the maven part on Nexus directly without having to >>> log on Nexus web interface ? The last part (not logging to close the >>> staging area) may reduce the safety we get and risk some spurious >>> publish as Sebb explained, but with several independent scripts, this >>> could leverage the risk. >> Separating the deployments of Maven and non-Maven artifacts might be >> possible, but I'm not sure I have enough Maven-foo to do it. >> >> It would mean removing the non-maven stuff from deploy, and using some >> other means to copy the non-maven stuff to a separate staging >> directory. >> > There is this cool command called "cp" that works very well. There Does not work natively on Windows or various other OSes. > is another one called "tar" and even one called "scp" ;) If the > problem is that we want to be more paranoid than we are with the > mirrors for the maven stuff, why can't we just get access and copy > the files we want to put in the staging repo? Or write a simple > script that moves the kind of thing that I have sitting now in > http://people.apache.org/~psteitz/pool-1.5.6-rc2/maven/ > to the "staging repository" and another script or command that > "promotes" it. It seems ridiculous to me that we need to introduce > a proprietary GUI tool to just move files on ASF hosts. Nexus does more than just move files around. It maintains the maven-metadata.xml file, and checks that the signature is correct. It also ensures that the file is uploaded to the correct directory based on the groupId. There are probably other features I have not encountered. If someone wants to spend time creating and maintaining an alternative tool, fine, but don't overlook the benefits that Nexus brings. At present I think it's great that I can do a "mvn deploy" and not worry that it might be published accidentally. Nexus makes it easy for non-Unix types to inspect the files and delete any that should not be there or upload others that are missing. > Phil > > Phil >>> Luc >>> I cannot seem to have published the Maven bits to Maven places. There is no 1.5 here: http://repo1.maven.org/maven2/commons-codec/commons-codec/ Because it is not here: /x1/www/people.apache.org/repo/m2-ibiblio-rsync-repository/commons-codec What does "Promote" out of Nexus do then? Should I copy the files to /www/ people.apache.org/repo/m2-ibiblio-rsync-repository myself per http://commons.apache.org/releases/release.html under the section "3 Deploy Maven Artifacts"? Or will that cause problem with work I did in Nexus (for the last time?) Thank you Gary -- Forwarded message -- From: sebb Date: Tue, Mar 29, 2011 at 10:15 AM Subject: Re: [VOTE] Release Apache Commons Codec 1.5-RC1 To: Commons Developers List On 29 March 2011 04:45, Gary Gregory wrote: > On Mon, Mar 28, 2011 at 11:21 PM, Phil Steitz wrote: >> On 3/28/11 4:49 PM, Gary Gregory wrote: >>> I am having a heck of a time pushing the release out. >>> >>> I cannot seem to be able to create the sym links per the instructions in >>> http://wiki.apache.org/commons/UsingNexus >>> >>> I cannot get the symlin
Re: Release hell WAS: [VOTE] Release Apache Commons Codec 1.5-RC1
On Mar 30, 2011, at 13:24, sebb wrote: > On 30 March 2011 17:03, Phil Steitz wrote: >> On 3/30/11 5:39 AM, sebb wrote: >>> On 30 March 2011 08:01, Luc Maisonobe wrote: Le 30/03/2011 03:36, Gary Gregory a écrit : > Wait! I'm not done or I'm loosing my marbles... > > I followed the whole song and dance from: > > http://wiki.apache.org/commons/UsingNexus > > It's the last time I'll pick that route. For what its worth, for math 2.2 I used a mix of Phil scripts for the beginning and Nexus for the rest, using the wiki as a guideline. In this case the process was a little convoluted, because we create both a trimmed down version of the site to hold only the user guide and to be put in the docs archives, and we create a complete site to be uploaded. For the last release candidate, it worked well. Phil asked me to document it and extend the scripts if needed, and I forgot to do it in time, sorry :-( The one thing I found cumbersome was that part of the process pushed non-maven artifacts on Nexus, that had to be manually moved away. Furthermore, these are what we consider here the real Apache artifacts (i.e. the ones that are available in the download page, not the ones that are at last published in maven repository). >>> I asked about extending Nexus so it could handle non-Maven staging, >>> and that did seem to be possible, but whether it will ever be >>> implemented, I don't know. >>> >>> That would be ideal. >>> I also have some slight concerns using a proprietary product, but as it secures some things as Sebb says, I can live with it. Is it possible to find some intermediate approach, extending Phil scripts, pushing only the maven part on Nexus directly without having to log on Nexus web interface ? The last part (not logging to close the staging area) may reduce the safety we get and risk some spurious publish as Sebb explained, but with several independent scripts, this could leverage the risk. >>> Separating the deployments of Maven and non-Maven artifacts might be >>> possible, but I'm not sure I have enough Maven-foo to do it. >>> >>> It would mean removing the non-maven stuff from deploy, and using some >>> other means to copy the non-maven stuff to a separate staging >>> directory. >>> >> There is this cool command called "cp" that works very well. There > > Does not work natively on Windows or various other OSes. Cygwin is great for that. What other OSes? > >> is another one called "tar" and even one called "scp" ;) If the >> problem is that we want to be more paranoid than we are with the >> mirrors for the maven stuff, why can't we just get access and copy >> the files we want to put in the staging repo? Or write a simple >> script that moves the kind of thing that I have sitting now in >> http://people.apache.org/~psteitz/pool-1.5.6-rc2/maven/ >> to the "staging repository" and another script or command that >> "promotes" it. It seems ridiculous to me that we need to introduce >> a proprietary GUI tool to just move files on ASF hosts. > > Nexus does more than just move files around. > > It maintains the maven-metadata.xml file, and checks that the > signature is correct. > It also ensures that the file is uploaded to the correct directory > based on the groupId. > There are probably other features I have not encountered. > > If someone wants to spend time creating and maintaining an alternative > tool, fine, but don't overlook the benefits that Nexus brings. > > At present I think it's great that I can do a "mvn deploy" and not > worry that it might be published accidentally. > > Nexus makes it easy for non-Unix types to inspect the files and delete > any that should not be there or upload others that are missing. > >> Phil >> >> Phil Luc > I cannot seem to have published the Maven bits to Maven places. There is > no > 1.5 here: > > http://repo1.maven.org/maven2/commons-codec/commons-codec/ > > Because it is not here: > > /x1/www/people.apache.org/repo/m2-ibiblio-rsync-repository/commons-codec > > What does "Promote" out of Nexus do then? > > Should I copy the files to /www/ > people.apache.org/repo/m2-ibiblio-rsync-repository myself per > > http://commons.apache.org/releases/release.html > > under the section "3 Deploy Maven Artifacts"? > > Or will that cause problem with work I did in Nexus (for the last time?) > > Thank you > > Gary > > -- Forwarded message -- > From: sebb > Date: Tue, Mar 29, 2011 at 10:15 AM > Subject: Re: [VOTE] Release Apache Commons Codec 1.5-RC1 > To: Commons Developers List > > > On 29 March 2011 04:45, Gary Gregory wrote: >> On Mon, Mar 28, 2011 at 11:21 PM, Phil Steitz > wrote: >>> On 3/28/11 4:49 PM, Gary Gregory wrote: I am havin
Re: Release hell WAS: [VOTE] Release Apache Commons Codec 1.5-RC1
On 3/30/11 10:24 AM, sebb wrote: > On 30 March 2011 17:03, Phil Steitz wrote: >> On 3/30/11 5:39 AM, sebb wrote: >>> On 30 March 2011 08:01, Luc Maisonobe wrote: Le 30/03/2011 03:36, Gary Gregory a écrit : > Wait! I'm not done or I'm loosing my marbles... > > I followed the whole song and dance from: > > http://wiki.apache.org/commons/UsingNexus > > It's the last time I'll pick that route. For what its worth, for math 2.2 I used a mix of Phil scripts for the beginning and Nexus for the rest, using the wiki as a guideline. In this case the process was a little convoluted, because we create both a trimmed down version of the site to hold only the user guide and to be put in the docs archives, and we create a complete site to be uploaded. For the last release candidate, it worked well. Phil asked me to document it and extend the scripts if needed, and I forgot to do it in time, sorry :-( The one thing I found cumbersome was that part of the process pushed non-maven artifacts on Nexus, that had to be manually moved away. Furthermore, these are what we consider here the real Apache artifacts (i.e. the ones that are available in the download page, not the ones that are at last published in maven repository). >>> I asked about extending Nexus so it could handle non-Maven staging, >>> and that did seem to be possible, but whether it will ever be >>> implemented, I don't know. >>> >>> That would be ideal. >>> I also have some slight concerns using a proprietary product, but as it secures some things as Sebb says, I can live with it. Is it possible to find some intermediate approach, extending Phil scripts, pushing only the maven part on Nexus directly without having to log on Nexus web interface ? The last part (not logging to close the staging area) may reduce the safety we get and risk some spurious publish as Sebb explained, but with several independent scripts, this could leverage the risk. >>> Separating the deployments of Maven and non-Maven artifacts might be >>> possible, but I'm not sure I have enough Maven-foo to do it. >>> >>> It would mean removing the non-maven stuff from deploy, and using some >>> other means to copy the non-maven stuff to a separate staging >>> directory. >>> >> There is this cool command called "cp" that works very well. There > Does not work natively on Windows or various other OSes. Last I checked, we do not run Windows on ASF infra at this point. We are talking about moving stuff from ASF host to ASF host here. For that, unix commands work just fine. >> is another one called "tar" and even one called "scp" ;) If the >> problem is that we want to be more paranoid than we are with the >> mirrors for the maven stuff, why can't we just get access and copy >> the files we want to put in the staging repo? Or write a simple >> script that moves the kind of thing that I have sitting now in >> http://people.apache.org/~psteitz/pool-1.5.6-rc2/maven/ >> to the "staging repository" and another script or command that >> "promotes" it. It seems ridiculous to me that we need to introduce >> a proprietary GUI tool to just move files on ASF hosts. > Nexus does more than just move files around. > > It maintains the maven-metadata.xml file, and checks that the > signature is correct. > It also ensures that the file is uploaded to the correct directory > based on the groupId. > There are probably other features I have not encountered. > > If someone wants to spend time creating and maintaining an alternative > tool, fine, but don't overlook the benefits that Nexus brings. > > At present I think it's great that I can do a "mvn deploy" and not > worry that it might be published accidentally. > > Nexus makes it easy for non-Unix types to inspect the files and delete > any that should not be there or upload others that are missing. > I get that, which is why I think some kind of middle ground where we provide simple scripts to move stuff around on the ASF hosts might be a good compromise. This is essentially what the ibiblio-rysnch stuff does. The only manual missing piece is correctly updating the maven-metadata (which logically the assembly or other such plugin could do locally) and maybe some kind of check to make sure that things are deployed to the right directories. I like much better to be able to inspect the artifacts that I am about to put out to vote locally. That is why I have never liked "mvn deploy." I understand that others don't care so much about that and are willing to trust maven to put what they think it is going to deploy to where they think it is going to. With all the layers of pom inheritance and history of bugs, I don't trust this approach and it saves me no time personally. I also understand that some Windows users may not want to mess with Cygwin or other tools to provide scp and such, but I would prefer that at
Re: [Math] What's the problem with interfaces?
Hi Gilles, Gilles Sadowski wrote: > Hi Jorg. > >> > >> > From comments that were posted to the other thread, I gather the main >> > trend that, because some interfaces needed an upgrade, the "interface" >> > design tool is becoming "evil". Did I get this right? >> > >> > I guess that you refer to "RandomData" and "RandomDataImpl". This is >> > indeed the typical example of abusing the "interface" tool. When only >> > one implementation is meaningful, an "interface" need not be defined. >> >> No. It is about adding something to the interface, just like Phil said. >> If you add a method to an abstract class, the dervied ones are still >> binary compatible, the same does not apply for interfaces. >> >> We had discussions in *length* about this and I am not interested in >> starting over again. > > Well, I was not part of those discussions, and CM is _still_ full of Java > "interface"s; so I assume that it's acceptable that I give my > point-of-view now. > > As I said, I'm not in favour of creating interface for the sake of having > everything separated in "Foo" and "FooImpl". > I understand that having an abstract class has some definite practical > advantages. And for the things I had in mind and which I'm most concerned > about (coherent design), it might well be a non-issue: "interface" could > be changed to "abstract class". > > The problems might come from the one thing which you can do with interface > but cannot with classes, namely, multiple inheritance. I never said that using abtract classes over interfaces is a mantra, but for a common library you should always prefer abstract classes if in doubt. More on this later. > Did someone already analyze the situation in CM? > The issue might well be resolved similarly to the debate about checked > exceptions, i.e. within CM, "interface" may also prove to be an > unneccessary feature of the Java language. It is a case by case decision, but an interface can be a heavy burden. [snip] >> > So what's the problem? Is it the binary compatibility, again? This is a >> > configuration management issue. When the compatibility is broken, you >> > change the major version number and/or the base package name. That was >> > settled, or not? >> >> The point is that an interface should not be changed for a long time. >> Otherwise every new release is a major one. > > It is not a question of time but of major (incompatible) and minor > (compatible) releases. As I noted in the reply to Sebb, the real problem > is not supporting older releases. That's a policy issue. For common libraries this is a very bad policy. Again more on this later. >> > It would be a pity to sacrifice a tool aimed at improving the design >> > because of such considerations as keeping backward compatibility with >> > versions that nobody here is going to support. >> >> It's a pity for the user, because he will *never* be able to use the next >> version as drop in. > > I also answered that in other post. > >> > If some user is happy with version "M.m", he can use it forever. If he >> > wants to use a newer version "N.n", he should not expect it to be >> > compatible. It does not have to be! Non-compatible modifications are >> > not performed out of some urge for change but stem from the desire to >> > get a better product, bits by bits. >> >> If that were true, you would currently have 10 different commons-lang, 10 >> different commons-collections and so on in your classpath. > > No, it's the user's choice to select which version he wants. This is the whole point, because it is probably not. Again more on it later. > You cannot have multiple versions of Linux running at the same time, but > nevertheless the kernel developers make releases at a much higher pace > than Commons... Nice example, I remember that Linux has explicit stable kernel lines that are used in business environment and patches from newer kernel versions are backported. The stable API is also a business requirement for Linux. And this has nothing to do which kernel version *I* currently run on my box and how often I upgrade. >> > Yes, it's not easy to get the interfaces right; so what? If you find >> > that you can improve the design, you do it and bump the major verion >> > number. As someone pointed out, it's not as if we'll run out of >> > numbers. >> >> And people will stop using it, because they are annoyed when they are >> depending in the end on n different versions of math, simply because of >> transitive dependencies. > > I think that you reason on the basic assumption that CM is close to > stability. Many problems (some bugs but also design consistency) have > shown that it is not. No. There are always times, when too many stuff piled up that requires an API change. But then you may have more radical changes and combine it with e.g. new (incompatible) JDK features. New digester is a very good example of it. But you have to make very wise decisions about the new API to keep it stable a
Re: Release hell WAS: [VOTE] Release Apache Commons Codec 1.5-RC1
On 30/03/2011 18:43, Phil Steitz wrote: > I get that, which is why I think some kind of middle ground where we > provide simple scripts to move stuff around on the ASF hosts might > be a good compromise. This is essentially what the ibiblio-rysnch > stuff does. The only manual missing piece is correctly updating the > maven-metadata (which logically the assembly or other such plugin > could do locally) and maybe some kind of check to make sure that > things are deployed to the right directories. You might want to take a look at how Tomcat 7 does this. It is built with Ant [1] and has a separate Ant script [2] for uploading stuff to the ASF snapshot, staging and release repositories which also handles the meta-data. Timing wise: - creating the release: 2 mins work + ~15 mins build time - uploading for voting: 2 mins work + ~60 mins transfer time - moving to dist if vote passes: 2 mins work - updating the site: 5 mins work - creating maven artifacts: 2 mins work + ~60 mins transfer time It constantly amazes me how much more complicated the release process appears to be in Commons for what should be much simpler components than Tomcat (no Windows installer, no native libraries, no fun with different NOTICE and LICENSE files for different jars, etc.). I assume it shouldn't be too difficult to do a similar thing with a couple of Maven scripts. Mark [1] http://svn.apache.org/viewvc/tomcat/trunk/build.xml?view=annotate [2] http://svn.apache.org/viewvc/tomcat/trunk/res/maven/mvn-pub.xml?view=annotate - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Release hell WAS: [VOTE] Release Apache Commons Codec 1.5-RC1
On 30 March 2011 19:23, Mark Thomas wrote: > On 30/03/2011 18:43, Phil Steitz wrote: >> I get that, which is why I think some kind of middle ground where we >> provide simple scripts to move stuff around on the ASF hosts might >> be a good compromise. This is essentially what the ibiblio-rysnch >> stuff does. The only manual missing piece is correctly updating the >> maven-metadata (which logically the assembly or other such plugin >> could do locally) and maybe some kind of check to make sure that >> things are deployed to the right directories. > > You might want to take a look at how Tomcat 7 does this. It is built > with Ant [1] and has a separate Ant script [2] for uploading stuff to > the ASF snapshot, staging and release repositories which also handles > the meta-data. But the script appears to need quite a lot of configuration that has to match the release. > Timing wise: > - creating the release: 2 mins work + ~15 mins build time > - uploading for voting: 2 mins work + ~60 mins transfer time > - moving to dist if vote passes: 2 mins work > - updating the site: 5 mins work > - creating maven artifacts: 2 mins work + ~60 mins transfer time > > It constantly amazes me how much more complicated the release process > appears to be in Commons for what should be much simpler components than > Tomcat (no Windows installer, no native libraries, no fun with different > NOTICE and LICENSE files for different jars, etc.). However, Commons has a lot of different components with differing numbers of release artifacts and diferent source directory layouts. And at least one component does have native code (Daemon) and one has special processing for user guide (Math) and another requires multiple builds and jars (DBCP). And I think some may still use Maven 1. I think a lot of the (perceived) complication is due to the fact that the build instructions have not been fully updated since Maven 1. Also, there are a lot of different RMs (generally one per component) rather than one per Tomcat version, so the RMs are generally not as familiar with the process. If there is a problem with the Tomcat script, you can tweak it and test it quite easily as there's only one product to test against. Does the Tomcat 7 script work as is with Tomcat 6 and 5? I'm not saying that the Commons release process could not be improved, but I do think that: - it is not as bad as people make out - though the docs need lots of work - replacing it will not be a trivial task, because of the number of components > I assume it shouldn't be too difficult to do a similar thing with a > couple of Maven scripts. Unfortunately Maven is much harder to tweak than Ant if one wants to do anything slightly unusual, and debugging problems is much harder than with Ant. > Mark > > [1] http://svn.apache.org/viewvc/tomcat/trunk/build.xml?view=annotate > [2] > http://svn.apache.org/viewvc/tomcat/trunk/res/maven/mvn-pub.xml?view=annotate > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Release hell WAS: [VOTE] Release Apache Commons Codec 1.5-RC1
> > > I cannot seem to have published the Maven bits to Maven places. There is > no > > 1.5 here: > > > > http://repo1.maven.org/maven2/commons-codec/commons-codec/ > Still nothing there. :( Gary
Re: Release hell WAS: [VOTE] Release Apache Commons Codec 1.5-RC1
On 3/30/11 11:23 AM, Mark Thomas wrote: > On 30/03/2011 18:43, Phil Steitz wrote: >> I get that, which is why I think some kind of middle ground where we >> provide simple scripts to move stuff around on the ASF hosts might >> be a good compromise. This is essentially what the ibiblio-rysnch >> stuff does. The only manual missing piece is correctly updating the >> maven-metadata (which logically the assembly or other such plugin >> could do locally) and maybe some kind of check to make sure that >> things are deployed to the right directories. > You might want to take a look at how Tomcat 7 does this. It is built > with Ant [1] and has a separate Ant script [2] for uploading stuff to > the ASF snapshot, staging and release repositories which also handles > the meta-data. > > Timing wise: > - creating the release: 2 mins work + ~15 mins build time > - uploading for voting: 2 mins work + ~60 mins transfer time > - moving to dist if vote passes: 2 mins work > - updating the site: 5 mins work > - creating maven artifacts: 2 mins work + ~60 mins transfer time > > It constantly amazes me how much more complicated the release process > appears to be in Commons for what should be much simpler components than > Tomcat (no Windows installer, no native libraries, no fun with different > NOTICE and LICENSE files for different jars, etc.). > > I assume it shouldn't be too difficult to do a similar thing with a > couple of Maven scripts. Thanks, Mark! The mvn-pub script looks like it could be modified to do what we need. I will see if I can get something like that working for the next release I cut. The big advantage of that over my scripts and manual moves on p.a.o is that it is platform independent and does not require shell access for the maven deployment. Phil > Mark > > [1] http://svn.apache.org/viewvc/tomcat/trunk/build.xml?view=annotate > [2] > http://svn.apache.org/viewvc/tomcat/trunk/res/maven/mvn-pub.xml?view=annotate > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Release Commons Pool 1.5.6 based on RC2
+1 Thank you to Phil for RM'ing. All is well on my system: Apache Maven 2.2.1 (r801777; 2009-08-06 15:16:01-0400) Java version: 1.6.0_24 Java home: C:\Program Files\Java\jdk1.6.0_24\jre Default locale: en_US, platform encoding: Cp1252 OS name: "windows 7" version: "6.1" arch: "amd64" Family: "windows" To do when possible: - Better test code coverage, CursorableSubList has 0% coverage for example. - Upgrade POM to current so I am not forced to use M2 to build instead of M3. - In [parent] or [skin] I think: The RAT and Project License report use syntax highlighting which is not right. - Add the publish date for this version in changes.xml Gary On Wed, Mar 30, 2011 at 2:17 AM, Phil Steitz wrote: > The tag is here: > http://svn.apache.org/repos/asf/commons/proper/pool/tags/POOL_1_5_6_RC2 > > The distribution zips/tars are here: > http://people.apache.org/~psteitz/pool-1.5.6-rc2/ > > Maven artifacts are here: > http://people.apache.org/~psteitz/pool-1.5.6-rc2/maven/ > > Site: > http://people.apache.org/~psteitz/pool-1.5.6-rc2/docs/ > > Release notes: > http://people.apache.org/~psteitz/pool-1.5.6-rc2/RELEASE-NOTES.txt > > Votes, please. This vote will close in 72 hours (2 April, 06:30 GMT). > > Thanks in advance. > > Phil > > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- Thank you, Gary http://garygregory.wordpress.com/ http://garygregory.com/ http://people.apache.org/~ggregory/ http://twitter.com/GaryGregory
Re: Release Commons Pool 1.5.6 based on RC2
On 30/03/2011 07:17, Phil Steitz wrote: > The tag is here: > http://svn.apache.org/repos/asf/commons/proper/pool/tags/POOL_1_5_6_RC2 > > The distribution zips/tars are here: > http://people.apache.org/~psteitz/pool-1.5.6-rc2/ MD5/SHA1s match for source distributions. OpenPGP signatures valid and key in ASF web of trust src-zip distro matches svn less 3 files (doap and 2 * release script) src-tar-gz distro matches svn less 3 files (doap and 2 * release script) Both the src-zip distro and the src-tar-gz distro have LF line-endings. I expected CRLF in the src-zip distro but there is no reason why it has to be. Unit tests all pass. +1 to release from me. Mark - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Release Commons Pool 1.5.6 based on RC2
On 3/30/11 1:21 PM, Mark Thomas wrote: > On 30/03/2011 07:17, Phil Steitz wrote: >> The tag is here: >> http://svn.apache.org/repos/asf/commons/proper/pool/tags/POOL_1_5_6_RC2 >> >> The distribution zips/tars are here: >> http://people.apache.org/~psteitz/pool-1.5.6-rc2/ > MD5/SHA1s match for source distributions. > OpenPGP signatures valid and key in ASF web of trust > > src-zip distro matches svn less 3 files (doap and 2 * release script) > src-tar-gz distro matches svn less 3 files (doap and 2 * release script) By design, these files are omitted from the release. > Both the src-zip distro and the src-tar-gz distro have LF line-endings. > I expected CRLF in the src-zip distro but there is no reason why it has > to be. I would like CRLF for src-zip as well. Seems maven used to do that by default. Does anyone know how to get maven to do this? Phil > Unit tests all pass. > > +1 to release from me. > > Mark > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Release Commons Pool 1.5.6 based on RC2
On 30 March 2011 21:37, Phil Steitz wrote: > On 3/30/11 1:21 PM, Mark Thomas wrote: >> On 30/03/2011 07:17, Phil Steitz wrote: >>> The tag is here: >>> http://svn.apache.org/repos/asf/commons/proper/pool/tags/POOL_1_5_6_RC2 >>> >>> The distribution zips/tars are here: >>> http://people.apache.org/~psteitz/pool-1.5.6-rc2/ >> MD5/SHA1s match for source distributions. >> OpenPGP signatures valid and key in ASF web of trust >> >> src-zip distro matches svn less 3 files (doap and 2 * release script) >> src-tar-gz distro matches svn less 3 files (doap and 2 * release script) > By design, these files are omitted from the release. >> Both the src-zip distro and the src-tar-gz distro have LF line-endings. >> I expected CRLF in the src-zip distro but there is no reason why it has >> to be. > I would like CRLF for src-zip as well. Seems maven used to do that > by default. Does anyone know how to get maven to do this? You can do it in the assembly desciptors. http://maven.apache.org/plugins/maven-assembly-plugin/assembly.html#fileSet lineEnding If you don't mind duplicating the contents for zip and tar.gz you can create one with CRLF and the other with LF. > Phil >> Unit tests all pass. >> >> +1 to release from me. >> >> Mark >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1086810 - /commons/proper/pool/branches/POOL_1_X/pom.xml
On 30 March 2011 06:30, Phil Steitz wrote: > On 3/29/11 6:30 PM, sebb wrote: >> On 30 March 2011 01:13, wrote: >>> Author: psteitz >>> Date: Wed Mar 30 00:13:51 2011 >>> New Revision: 1086810 >>> >>> URL: http://svn.apache.org/viewvc?rev=1086810&view=rev >>> Log: >>> Upgraded parent pom, downgraded assembly plugin to working version. >> What is the exact problem? I'm happy to raise a bug and create test >> cases etc., but I don't know what the issue is. > > Per Niall's comments during the vote on parent 19 or 20, with the > later version of the assembly plugin in the current Commons parent > mvn -Prc -DcreateChecksum=true install > does not create, sign and install the tars/zips to the local repo. http://jira.codehaus.org/browse/MASSEMBLY-553 The basic problem seems to be that the assembly plugin does not process the attached descriptors. This then affects the signing and installation. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[Nexus] Commons-codec release not showing up in Maven Central after 24 hours
Commons Codec 1.5 was promoted from Nexus on 29 March 2011 06:21 and is showing up here: https://repository.apache.org/content/groups/staging/commons-codec/commons-codec/1.5/ However it has yet to show up in Maven Central over 24 hours later. http://repo1.maven.org/maven2/commons-codec/commons-codec/ Has something gone wrong with the process? - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[discovery] moving on to 0.5
Hi all guys, I recently needed the Discovery in a project of mine and noticed we haven't had releases since 2008. I would like to update it, improving a little the design - like, for example, using the generics. Any objection? Thanks in advance, have a nice day, Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Release hell WAS: [VOTE] Release Apache Commons Codec 1.5-RC1
On Wed, Mar 30, 2011 at 6:03 PM, Phil Steitz wrote: > There is this cool command called "cp" that works very well. There > is another one called "tar" and even one called "scp" ;) If the > problem is that we want to be more paranoid than we are with the > mirrors for the maven stuff, why can't we just get access and copy > the files we want to put in the staging repo? Yes, and there is a stupid little thing called "human", which tends to introduce slight little errors on the way like wrong permissions, ownership, missing MD5 sums, and the like. Just believe me, if you did than once with 40 files or so, then you start to like Nexus and the release plugin real soon. > Or write a simple > script that moves the kind of thing that I have sitting now in > http://people.apache.org/~psteitz/pool-1.5.6-rc2/maven/ > to the "staging repository" and another script or command that > "promotes" it. It seems ridiculous to me that we need to introduce > a proprietary GUI tool to just move files on ASF hosts. That would simply mean to rewrite the release plugin plus maintain it whenever Apache, Maven, or Commons change their policies. Do you really think that makes sense? I am sorry for everyone who's forced to publish a release with Nexus. But I'm much more sorry for everyone who's forced to do it without. And, believe me, I've had plenty of both variants as a release manager for various projects in commons and ws, and Rat. Jochen -- I Am What I Am And That's All What I Yam (Popeye) - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [codec] Moving on to codec 2.0
On Wed, Mar 30, 2011 at 7:04 PM, sebb wrote: > But does the API have to change, or could these additional features be > supported by adding new methods and classes? Not necessarily. But my point is that codec is in a state where breaking the API will make work just easier. So why not take the opportunity? -- I Am What I Am And That's All What I Yam (Popeye) - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Release process WAS [VOTE] Release Apache Commons Codec 1.5-RC1
On Tue, Mar 29, 2011 at 5:52 PM, Phil Steitz wrote: > I disagree with this. The most important artifacts are the > zips/tars that go to dist/. These *are* the ASF release. Nexus > makes it *harder* IMO to maintain provenance of these artifacts. These artifacts are present in Nexus. Pulling them to a temporary directory is quite easy with wget. At which point I can see no difference between your proposed solution and this one. And there's nothing to do for all the other files that live in Nexus (and must live, because Maven is just too important, whether we like it or not). > I also don't see why we *must* rely on proprietary software to > manage replication. I'm mostly with you on that. I strongly opposed choosing Nexus in favour of Archiva for that very reason. But we have Nexus now and I wouldn't want to have Commons a swimmer against the rest of the Apache tide. Jochen -- I Am What I Am And That's All What I Yam (Popeye) - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [codec] Moving on to codec 2.0
On 31 March 2011 00:17, Jochen Wiedmann wrote: > On Wed, Mar 30, 2011 at 7:04 PM, sebb wrote: > >> But does the API have to change, or could these additional features be >> supported by adding new methods and classes? > > Not necessarily. But my point is that codec is in a state where > breaking the API will make work just easier. So why not take the > opportunity? Because making work easier for a few developers has to be balanced against making more work for lots of users. > > -- > I Am What I Am And That's All What I Yam (Popeye) > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Release process WAS [VOTE] Release Apache Commons Codec 1.5-RC1
On 31 March 2011 00:22, Jochen Wiedmann wrote: > On Tue, Mar 29, 2011 at 5:52 PM, Phil Steitz wrote: > >> I disagree with this. The most important artifacts are the >> zips/tars that go to dist/. These *are* the ASF release. Nexus >> makes it *harder* IMO to maintain provenance of these artifacts. > > These artifacts are present in Nexus. Pulling them to a temporary > directory is quite easy with wget. At which point I can see no > difference between your proposed solution and this one. And there's > nothing to do for all the other files that live in Nexus (and must > live, because Maven is just too important, whether we like it or not). IMO, moving the non-Maven files out of Nexus is the main irritation with the way it works at present. AFAIK, wget alone won't do, as the files also have to be deleted. Also, it would be best if that part of the process could be done from the users system, rather than having to login to people.a.o and run commands there. If that could be automated, I would be happy, but would everyone else? > >> I also don't see why we *must* rely on proprietary software to >> manage replication. > > I'm mostly with you on that. I strongly opposed choosing Nexus in > favour of Archiva for that very reason. But we have Nexus now and I > wouldn't want to have Commons a swimmer against the rest of the Apache > tide. AIUI Archive does not currently support staging. > Jochen > > > -- > I Am What I Am And That's All What I Yam (Popeye) > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Release process WAS [VOTE] Release Apache Commons Codec 1.5-RC1
On 3/30/11 4:22 PM, Jochen Wiedmann wrote: > On Tue, Mar 29, 2011 at 5:52 PM, Phil Steitz wrote: > >> I disagree with this. The most important artifacts are the >> zips/tars that go to dist/. These *are* the ASF release. Nexus >> makes it *harder* IMO to maintain provenance of these artifacts. > These artifacts are present in Nexus. Pulling them to a temporary > directory is quite easy with wget. And then you need to check the hashes and sigs again since you are now working with downloaded copies of the files that we voted on. Seems much easier and more correct to me to just scp the files to p.a.o., let people vote on them and *move* exactly those files to /dist. > At which point I can see no > difference between your proposed solution and this one. And there's > nothing to do for all the other files that live in Nexus (and must > live, because Maven is just too important, whether we like it or not). Sorry, I don't buy that. The tars and zips need to "live" in /dist. The maven artifacts need to make their way to the maven mirrors. Having a "staging" repo where we can inspect the maven bits before they get pushed out is great (though I think our homes on p.a.o are fine for this). Why can't we just push files directly there using scp or Ant tasks and then "promote" them to the rsynch repo using a little script including commands like those in step 3 of http://commons.apache.org/releases/release.html? >> I also don't see why we *must* rely on proprietary software to >> manage replication. > I'm mostly with you on that. I strongly opposed choosing Nexus in > favour of Archiva for that very reason. But we have Nexus now and I > wouldn't want to have Commons a swimmer against the rest of the Apache > tide. Based on Mark's response, I don't think we are the only ones :) Phil > Jochen > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1086810 - /commons/proper/pool/branches/POOL_1_X/pom.xml
On Wed, Mar 30, 2011 at 6:30 AM, Phil Steitz wrote: > On 3/29/11 6:30 PM, sebb wrote: >> On 30 March 2011 01:13, wrote: >>> Author: psteitz >>> Date: Wed Mar 30 00:13:51 2011 >>> New Revision: 1086810 >>> >>> URL: http://svn.apache.org/viewvc?rev=1086810&view=rev >>> Log: >>> Upgraded parent pom, downgraded assembly plugin to working version. >> What is the exact problem? I'm happy to raise a bug and create test >> cases etc., but I don't know what the issue is. > > Per Niall's comments during the vote on parent 19 or 20, with the > later version of the assembly plugin in the current Commons parent > mvn -Prc -DcreateChecksum=true install > does not create, sign and install the tars/zips to the local repo. I found that doing "mvn -Prc install" didn't work - but adding clean (i.e. "mvn -Prc clean install") caused it to work just fine. Niall > Phil >> >>> Modified: >>> commons/proper/pool/branches/POOL_1_X/pom.xml >>> >>> Modified: commons/proper/pool/branches/POOL_1_X/pom.xml >>> URL: >>> http://svn.apache.org/viewvc/commons/proper/pool/branches/POOL_1_X/pom.xml?rev=1086810&r1=1086809&r2=1086810&view=diff >>> == >>> --- commons/proper/pool/branches/POOL_1_X/pom.xml (original) >>> +++ commons/proper/pool/branches/POOL_1_X/pom.xml Wed Mar 30 00:13:51 2011 >>> @@ -22,7 +22,7 @@ >>> >>> org.apache.commons >>> commons-parent >>> - 17 >>> + 20 >>> >>> 4.0.0 >>> commons-pool >>> @@ -148,6 +148,10 @@ >>> maven-source-plugin >>> 2.1 >>> >>> + >>> + maven-assembly-plugin >>> + 2.2-beta-5 >>> + >>> >>> >>> src/java >>> >>> >>> >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1086810 - /commons/proper/pool/branches/POOL_1_X/pom.xml
On 31 March 2011 02:00, Niall Pemberton wrote: > On Wed, Mar 30, 2011 at 6:30 AM, Phil Steitz wrote: >> On 3/29/11 6:30 PM, sebb wrote: >>> On 30 March 2011 01:13, wrote: Author: psteitz Date: Wed Mar 30 00:13:51 2011 New Revision: 1086810 URL: http://svn.apache.org/viewvc?rev=1086810&view=rev Log: Upgraded parent pom, downgraded assembly plugin to working version. >>> What is the exact problem? I'm happy to raise a bug and create test >>> cases etc., but I don't know what the issue is. >> >> Per Niall's comments during the vote on parent 19 or 20, with the >> later version of the assembly plugin in the current Commons parent >> mvn -Prc -DcreateChecksum=true install >> does not create, sign and install the tars/zips to the local repo. > > I found that doing "mvn -Prc install" didn't work - but adding clean > (i.e. "mvn -Prc clean install") caused it to work just fine. Odd, why should clean work? I found that mvn -Prc package install works, but that makes a bit more sense as the package presumably needs to attach the goal. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Release process WAS [VOTE] Release Apache Commons Codec 1.5-RC1
On 31 March 2011 01:38, Phil Steitz wrote: > On 3/30/11 4:22 PM, Jochen Wiedmann wrote: >> On Tue, Mar 29, 2011 at 5:52 PM, Phil Steitz wrote: >> >>> I disagree with this. The most important artifacts are the >>> zips/tars that go to dist/. These *are* the ASF release. Nexus >>> makes it *harder* IMO to maintain provenance of these artifacts. >> These artifacts are present in Nexus. Pulling them to a temporary >> directory is quite easy with wget. > And then you need to check the hashes and sigs again since you are > now working with downloaded copies of the files that we voted on. Huh? If we create a script to move the files directly from Nexus staging to dist/, surely there's no chance that the cp+rm will somehow mangle the files? > Seems much easier and more correct to me to just scp the files to > p.a.o., let people vote on them and *move* exactly those files to > /dist. Which is much what happens with Nexus now, apart from the dist/ move phase which is not yet automated. >> At which point I can see no >> difference between your proposed solution and this one. And there's >> nothing to do for all the other files that live in Nexus (and must >> live, because Maven is just too important, whether we like it or not). > Sorry, I don't buy that. The tars and zips need to "live" in > /dist. The maven artifacts need to make their way to the maven > mirrors. Having a "staging" repo where we can inspect the maven > bits before they get pushed out is great (though I think our homes > on p.a.o are fine for this). Why can't we just push files directly > there using scp or Ant tasks and then "promote" them to the rsynch > repo using a little script including commands like those in step 3 > of http://commons.apache.org/releases/release.html? >>> I also don't see why we *must* rely on proprietary software to >>> manage replication. >> I'm mostly with you on that. I strongly opposed choosing Nexus in >> favour of Archiva for that very reason. But we have Nexus now and I >> wouldn't want to have Commons a swimmer against the rest of the Apache >> tide. > Based on Mark's response, I don't think we are the only ones :) > > Phil >> Jochen >> >> > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Release process WAS [VOTE] Release Apache Commons Codec 1.5-RC1
I'm seeing a lot of complaining on these threads but no actual proposal. If the proposal is to move away from Maven/Nexus for a release for all of commons I'll vote -1. OTOH, If some release managers want to do the release some other way I'm not going to force them to use Maven/Nexus. Ralph On Mar 30, 2011, at 6:57 PM, sebb wrote: > On 31 March 2011 01:38, Phil Steitz wrote: >> On 3/30/11 4:22 PM, Jochen Wiedmann wrote: >>> On Tue, Mar 29, 2011 at 5:52 PM, Phil Steitz wrote: >>> I disagree with this. The most important artifacts are the zips/tars that go to dist/. These *are* the ASF release. Nexus makes it *harder* IMO to maintain provenance of these artifacts. >>> These artifacts are present in Nexus. Pulling them to a temporary >>> directory is quite easy with wget. >> And then you need to check the hashes and sigs again since you are >> now working with downloaded copies of the files that we voted on. > > Huh? > > If we create a script to move the files directly from Nexus staging to > dist/, surely there's no chance that the cp+rm will somehow mangle the > files? > >> Seems much easier and more correct to me to just scp the files to >> p.a.o., let people vote on them and *move* exactly those files to >> /dist. > > Which is much what happens with Nexus now, apart from the dist/ move > phase which is not yet automated. > >>> At which point I can see no >>> difference between your proposed solution and this one. And there's >>> nothing to do for all the other files that live in Nexus (and must >>> live, because Maven is just too important, whether we like it or not). >> Sorry, I don't buy that. The tars and zips need to "live" in >> /dist. The maven artifacts need to make their way to the maven >> mirrors. Having a "staging" repo where we can inspect the maven >> bits before they get pushed out is great (though I think our homes >> on p.a.o are fine for this). Why can't we just push files directly >> there using scp or Ant tasks and then "promote" them to the rsynch >> repo using a little script including commands like those in step 3 >> of http://commons.apache.org/releases/release.html? I also don't see why we *must* rely on proprietary software to manage replication. >>> I'm mostly with you on that. I strongly opposed choosing Nexus in >>> favour of Archiva for that very reason. But we have Nexus now and I >>> wouldn't want to have Commons a swimmer against the rest of the Apache >>> tide. >> Based on Mark's response, I don't think we are the only ones :) >> >> Phil >>> Jochen >>> >>> >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Release process WAS [VOTE] Release Apache Commons Codec 1.5-RC1
On 3/30/11 6:57 PM, sebb wrote: > On 31 March 2011 01:38, Phil Steitz wrote: >> On 3/30/11 4:22 PM, Jochen Wiedmann wrote: >>> On Tue, Mar 29, 2011 at 5:52 PM, Phil Steitz wrote: >>> I disagree with this. The most important artifacts are the zips/tars that go to dist/. These *are* the ASF release. Nexus makes it *harder* IMO to maintain provenance of these artifacts. >>> These artifacts are present in Nexus. Pulling them to a temporary >>> directory is quite easy with wget. >> And then you need to check the hashes and sigs again since you are >> now working with downloaded copies of the files that we voted on. > Huh? > > If we create a script to move the files directly from Nexus staging to > dist/, surely there's no chance that the cp+rm will somehow mangle the > files? mv is no problem. wget via http means you get a copy with the network between. That is what I was referring to. In that case, just like we tell the users, the RM should check hashes and sigs to make sure that what actually ends up in dist/ is identical to what we voted on. >> Seems much easier and more correct to me to just scp the files to >> p.a.o., let people vote on them and *move* exactly those files to >> /dist. > Which is much what happens with Nexus now, apart from the dist/ move > phase which is not yet automated. > So the nexus staging repo lives on p.a.o? Does not look like it from the IPs, unless there is some aliasing going on. If dist/ is itself mirrored on r.a.o, then mv is possible; otherwise the files have to be copied across the network, rather than moved. That requires a recheck of the hashes. Phil >>> At which point I can see no >>> difference between your proposed solution and this one. And there's >>> nothing to do for all the other files that live in Nexus (and must >>> live, because Maven is just too important, whether we like it or not). >> Sorry, I don't buy that. The tars and zips need to "live" in >> /dist. The maven artifacts need to make their way to the maven >> mirrors. Having a "staging" repo where we can inspect the maven >> bits before they get pushed out is great (though I think our homes >> on p.a.o are fine for this). Why can't we just push files directly >> there using scp or Ant tasks and then "promote" them to the rsynch >> repo using a little script including commands like those in step 3 >> of http://commons.apache.org/releases/release.html? I also don't see why we *must* rely on proprietary software to manage replication. >>> I'm mostly with you on that. I strongly opposed choosing Nexus in >>> favour of Archiva for that very reason. But we have Nexus now and I >>> wouldn't want to have Commons a swimmer against the rest of the Apache >>> tide. >> Based on Mark's response, I don't think we are the only ones :) >> >> Phil >>> Jochen >>> >>> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Release process WAS [VOTE] Release Apache Commons Codec 1.5-RC1
On 3/30/11 7:07 PM, Ralph Goers wrote: > I'm seeing a lot of complaining on these threads but no actual proposal. I started the thread with a proposal, which was to standardize on the process documented on the web site. I know you don't like that process and I am not going to insist that we force everyone to use the same process. That is obviously not going to be possible, since several of us will -1 forcing everyone to use either Nexus or the maven release plugin. An improvement of the process on the web site has been suggested, basically replacing step 3 with an Ant script that pushes maven artifacts generated by the build automatically. I will get a prototype for that working when I cut my next release. Phil > If the proposal is to move away from Maven/Nexus for a release for all of > commons I'll vote -1. OTOH, If some release managers want to do the release > some other way I'm not going to force them to use Maven/Nexus. > > Ralph > > > On Mar 30, 2011, at 6:57 PM, sebb wrote: > >> On 31 March 2011 01:38, Phil Steitz wrote: >>> On 3/30/11 4:22 PM, Jochen Wiedmann wrote: On Tue, Mar 29, 2011 at 5:52 PM, Phil Steitz wrote: > I disagree with this. The most important artifacts are the > zips/tars that go to dist/. These *are* the ASF release. Nexus > makes it *harder* IMO to maintain provenance of these artifacts. These artifacts are present in Nexus. Pulling them to a temporary directory is quite easy with wget. >>> And then you need to check the hashes and sigs again since you are >>> now working with downloaded copies of the files that we voted on. >> Huh? >> >> If we create a script to move the files directly from Nexus staging to >> dist/, surely there's no chance that the cp+rm will somehow mangle the >> files? >> >>> Seems much easier and more correct to me to just scp the files to >>> p.a.o., let people vote on them and *move* exactly those files to >>> /dist. >> Which is much what happens with Nexus now, apart from the dist/ move >> phase which is not yet automated. >> At which point I can see no difference between your proposed solution and this one. And there's nothing to do for all the other files that live in Nexus (and must live, because Maven is just too important, whether we like it or not). >>> Sorry, I don't buy that. The tars and zips need to "live" in >>> /dist. The maven artifacts need to make their way to the maven >>> mirrors. Having a "staging" repo where we can inspect the maven >>> bits before they get pushed out is great (though I think our homes >>> on p.a.o are fine for this). Why can't we just push files directly >>> there using scp or Ant tasks and then "promote" them to the rsynch >>> repo using a little script including commands like those in step 3 >>> of http://commons.apache.org/releases/release.html? > I also don't see why we *must* rely on proprietary software to > manage replication. I'm mostly with you on that. I strongly opposed choosing Nexus in favour of Archiva for that very reason. But we have Nexus now and I wouldn't want to have Commons a swimmer against the rest of the Apache tide. >>> Based on Mark's response, I don't think we are the only ones :) >>> >>> Phil Jochen >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Release Commons Pool 1.5.6 based on RC2
On 3/29/11 11:17 PM, Phil Steitz wrote: > The tag is here: > http://svn.apache.org/repos/asf/commons/proper/pool/tags/POOL_1_5_6_RC2 > > The distribution zips/tars are here: > http://people.apache.org/~psteitz/pool-1.5.6-rc2/ > > Maven artifacts are here: > http://people.apache.org/~psteitz/pool-1.5.6-rc2/maven/ > > Site: > http://people.apache.org/~psteitz/pool-1.5.6-rc2/docs/ > > Release notes: > http://people.apache.org/~psteitz/pool-1.5.6-rc2/RELEASE-NOTES.txt > > Votes, please. This vote will close in 72 hours (2 April, 06:30 GMT). > > Thanks in advance. > > Phil > > Here is my +1 Phil - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
