Re: [COLLECTIONS] Heads up on 3.3 release
Proving Phil's point on release process, I'm staring at Collections and wondering just how to release it. Hen On Tue, Nov 4, 2008 at 10:01 PM, Henri Yandell <[EMAIL PROTECTED]> wrote: > If you look at https://issues.apache.org/jira/browse/COLLECTIONS > you'll see that Collections 3.3 is getting extremely close. > > In case anyone is holding back on a bug, wants to take a look or > mentally reserve some time etc to look at the rc :) > > I'm loosely thinking on making a first release candidate at the end of the > week. > > Hen > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Resurrecting commons-email - Was:MultiPartMail order of parts
Hi, 2008/11/10 Siegfried Goeschl <[EMAIL PROTECTED]> > > > Siegfried Goeschl wrote: > >> > >> Any hands out to help with commons-email and become a commons-email > >> maintainer? > >> > > I am willing to lend a hand. Not a committer in Commons, but an Apache committer. Cheers, Dave
Re: [jelly] Is jelly still in development vs. Open/FederatedCommons
Hi Paul, I agree that this is _not_ something where a technical solution is _needed_ to go forward, I'm simply trying to keep the options open so that Jelly does not disappear (IMHO marking a project as "Not Actively Maintained" is the beginning of the end). IMHO keeping Jelly in Commons Proper is the best choice for Jelly, while the 2nd choice is to keep it alive elsewhere as a federated Commons is a close second, the 3rd choice as a last resort is to create a fork. And I also agree that you need to be able to see who you're supporting, hence the reason for a patch submission to JIRA yesterday (with a follow-up in response to your comments today). John - Original Message - From: "Paul Libbrecht" <[EMAIL PROTECTED]> To: "Commons Developers List" Sent: Monday, November 10, 2008 11:16 AM Subject: Re: [jelly] Is jelly still in development vs. Open/FederatedCommons John, Le 10-nov.-08 à 07:11, John Spackman a écrit : Yes, kind of - I've only recently come across Git and the concept of DVCS but it was my intention to look at using a DVCS for this. But DVCS "only" does source code - setting up a seperate branch only works if the community at large see the new branch, whereas the Commons group are considering marking Jelly as "No Longer Maintained" and moving the repository out of the main branch. Hey no! It's lacking maintainer and we shall be more than happy to make you a committer having been able to measure the quality of contributions! The problem is not the technical approach of DVCS, the problem is only endorsement: it seems rather normal that a person that hasn't been seen is first a bit observed or? Setting up a separate fork for a while to achieve this sounds an avenue to me. Suggesting patches on jira or any other method or paced-down contribution should be supported. I'm happy to receive your source tree from time to time, in full, inspect it and commit it as is for example. From my point of view, I would only want to perform a public branch with the endorsment of the Commons team; IMHO it's important for new and existing users to see a future for the project, and for there to be a link from the official Commons website to the federated Jelly site. The original downloads would remain for backward compatability, but the Commons site would clearly refer users onto the new site for upgrades and future development. I don't see any reason why commons would say "things are happening elsewhere" while it could happen here real soon now. The issue is endorsement and not distribution. paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jelly] Is jelly still in development vs. Open/FederatedCommons
Hi Russel, Of course graceful demise is entirely appropriate. The question I have is whether putting effort into maintaining a demising system is worth it compared to putting that effort into transferring to a different (more appropriate, in my view) technology for dealing with the problem. There are some very nice candidates for Ant and Maven replacements out there: I think you're talking about a different "problem" - Jelly is used for far more than Ant/Maven replacement (I don't usually use either) and maintaining it is not an altruistic choice for me, but a practical one because I find it so very useful. John - Original Message - From: "Russel Winder" <[EMAIL PROTECTED]> To: "Commons Developers List" Sent: Monday, November 10, 2008 8:22 AM Subject: Re: [jelly] Is jelly still in development vs. Open/FederatedCommons - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jelly] Is jelly still in development vs. Open/Federated Commons
Repling inline to both Paul and John: On Sun, Nov 9, 2008 at 2:26 PM, Paul Libbrecht <[EMAIL PROTECTED]> wrote: > > Le 09-nov.-08 à 05:35, John Spackman a écrit : >> Using Henri's analogies from his recent blog, I took Jelly home from the >> Commons a couple of years ago and we're now ready to "put it in the window >> and see if we're invited to play". If we're invited to play then great - >> any changes we make will be contributed back (and documentation will come >> with those changes) - but my "home life" is a small business that keeps me >> very busy and my focus here is on gradually contributing fixes/improvements >> and documentation rather than taking Jelly a great leap forward as an O/S >> product. As below - analogy was about other Apache projects but probably applies here as you say. Don't worry about great leap forwards btw - scratch your itch to reduce maintenance pain of your fork; that's all anyone does and it adds up to value. > We can make a vote on that... or we can simply try to make it cleaner and > start applying code patches. I don't think retirement was what Henri > suggested. Paul: Well... definitely a strong line towards retirement. :) Informing users that it's an inactive project. >> Please don't get me wrong - I am very grateful for your offer to apply >> patches etc sent via JIRA but I am cautious as I think of the potential >> extra work that would entail and how much simpler it would be if I could >> just issue an SVN commit. > > I fully understand but Apache foundations' practice has really always been > such. There are a few bits at play here. There's a cultural pressure in that we don't want to give committer rights to people until they show commitment as we're indicating to the rest of Apache's communities that this person has shown commitment somewhere. There's also a legal bit - need to get committers to sign CLAs as they're expected to do larger pieces of work. >> Returning again to Henri's blog, instead of Jelly being a first use case >> for retiring a commons project, how about it being a first use case for a >> "Federated Commons" subproject? Blog wise that was targetted more at the Commons like components inside other Apache projects, than moving an item out of Commons. >> I appreciate the point that making commits >> open to anybody has it's problems and is not something the team want to do >> right now, but given that the list is contemplating retiring Jelly this >> could be an ideal opportunity to experiment with something where the team >> has little to lose. >> The original SVN archive would remain intact at Apache, >> and I'd take a copy of it for my 1.x trunk so that I could create branches >> (possibly using Git); any projects already using Jelly 1.0 would be >> completely unaffected, but new users and users wishing to update would be >> referred to the new Federated Jelly website & repository. There's a separate concept called Apache Attic that this fits into. Basically Apache will retire something and if people want it to continue life there are various ways back, including the one above of a fork being created elsewhere and linked to from Apache as a known fork that people are recommended to go get involved in. Though the plan isn't to do it for Commons components per se - as usual Commons doesn't quite fit the model :) Reminds me that I need to send in the board resolution/proposal for that ... I've been in a maintenance process mood recently it seems :/ Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]: Project commons-configuration-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 [EMAIL PROTECTED] Project commons-configuration-test has an issue affecting its community integration. This issue affects 1 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-configuration-test : Apache Commons Full details are available at: http://vmgump.apache.org/gump/public/apache-commons/commons-configuration-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -WARNING- Overriding Maven2 settings: [/srv/gump/public/workspace/apache-commons/configuration/gump_mvn_settings.xml] -DEBUG- (Gump generated) Maven2 Settings in: /srv/gump/public/workspace/apache-commons/configuration/gump_mvn_settings.xml -INFO- Failed with reason build failed -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/configuration/pom.xml The following work was performed: http://vmgump.apache.org/gump/public/apache-commons/commons-configuration-test/gump_work/build_apache-commons_commons-configuration-test.html Work Name: build_apache-commons_commons-configuration-test (Type: Build) Work ended in a state of : Failed Elapsed: 4 mins 58 secs Command Line: mvn --batch-mode --settings /srv/gump/public/workspace/apache-commons/configuration/gump_mvn_settings.xml test [Working Directory: /srv/gump/public/workspace/apache-commons/configuration] CLASSPATH: /usr/lib/jvm/java-1.5.0-sun/lib/tools.jar:/srv/gump/public/workspace/apache-commons/configuration/target/commons-configuration-1.6-SNAPSHOT.jar - testSaveAttributes(org.apache.commons.configuration.TestXMLConfiguration) testCloneWithSave(org.apache.commons.configuration.TestXMLConfiguration) testEmptyElements(org.apache.commons.configuration.TestXMLConfiguration) testSaveWithEncoding(org.apache.commons.configuration.TestXMLConfiguration) testSaveWithNullEncoding(org.apache.commons.configuration.TestXMLConfiguration) testSaveWithDoctype(org.apache.commons.configuration.TestXMLConfiguration) testSaveWithDoctypeIDs(org.apache.commons.configuration.TestXMLConfiguration) testSubsetWithReload(org.apache.commons.configuration.TestXMLConfiguration) testConfigurationAtWithReload(org.apache.commons.configuration.TestXMLConfiguration) testConfigurationsAtWithReload(org.apache.commons.configuration.TestXMLConfiguration) testGetKeysWithReload(org.apache.commons.configuration.TestXMLConfiguration) testSetTextRootElement(org.apache.commons.configuration.TestXMLConfiguration) testClearTextRootElement(org.apache.commons.configuration.TestXMLConfiguration) testAutoSaveWithSubnodeConfig(org.apache.commons.configuration.TestXMLConfiguration) testAutoSaveWithSubSubnodeConfig(org.apache.commons.configuration.TestXMLConfiguration) testSaveDelimiterParsingDisabled(org.apache.commons.configuration.TestXMLConfiguration) testSaveDelimiterParsingDisabledAttrs(org.apache.commons.configuration.TestXMLConfiguration) testMultipleAttrValuesEscaped(org.apache.commons.configuration.TestXMLConfiguration) testAutoSaveWithReloadingStrategy(org.apache.commons.configuration.TestXMLConfiguration) testAutoSaveAddNodes(org.apache.commons.configuration.TestXMLConfiguration) testAddNodesAndSave(org.apache.commons.configuration.TestXMLConfiguration) testRegisterEntityId(org.apache.commons.configuration.TestXMLConfiguration) testSaveAfterCreateWithCopyConstructor(org.apache.commons.configuration.TestXMLConfiguration) testCopyRootName(org.apache.commons.configuration.TestXMLConfiguration) testCopyRootNameNoDocument(org.apache.commons.configuration.TestXMLConfiguration) testParse(org.apache.commons.configuration.TestBaseConfigurationXMLReader) testSetRootName(org.apache.commons.configuration.TestBaseConfigurationXMLReader) testParentReloadNotSupported(org.apache.commons.configuration.TestSubnodeConfiguration) testParentReloadSupported(org.apache.commons.configuration.TestSubnodeConfiguration) testParentReloadSupportAccessParent(org.apache.commons.configuration.TestSubnodeConfiguration) testParentReloadSubSubnode(org.apache.commons.configuration.TestSubnodeConfiguration) testParentReloadSubSubnodeNoChangeSupport(org.apache.commons.configuration.TestSubnodeConfiguration) testParse(org.apache.commons.configuration.TestHierarchicalConfigurationXMLReader) testLoadXMLWithSettings(org.apache.commons.configuration.TestDefaultConfigurationBuilder) Tests run: 1268, Failures: 0, Errors: 47, Skipped: 0 [INFO] [ERROR] BUILD FAILURE [INFO]
Re: [jelly] Is jelly still in development
Hi all, Just for the record, I have used Jelly in a commercial project as well, in the installer of an application that supported multiple databases (like Oracle and MySql) - we developed the database installation/update script in Jelly. So, regardless of the discussion of wheter Jelly is appropriate or not, I think it has its merit and have been used out there more than we (ASF guys) suspect. That being said, it would be great if could bring the project back to life. I might even be able to help by applying a patch or two (I'm a Jakarta committer), but can't commit (no pun intended :-) to do much more than that. -- Felipe On Sat, Nov 8, 2008 at 1:20 AM, John Spackman <[EMAIL PROTECTED]> wrote: > We're still actively using Jelly and while the usefulness of some of the > extension modules may be debatable (and definitely without wishing to enter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jelly] Is jelly still in development vs. Open/FederatedCommons
On Mon, Nov 10, 2008 at 3:22 AM, Russel Winder <[EMAIL PROTECTED]> wrote: I think the bulk of this message would have been better off in a new thread, marked [OT]. Some of these discussions have been happening at the ASF, on a more appropriate list whose public archives are here: http://mail-archives.apache.org/mod_mbox/www-infrastructure-dev/ > > I guess I am in the "XML is a data specification language and has no > right having a computational model, that's what dynamic languages like > Groovy, Python and Ruby are for." camp, so I don't see the demise of > Jelly as a problem. > > Of course graceful demise is entirely appropriate. The question I have > is whether putting effort into maintaining a demising system is worth it > compared to putting that effort into transferring to a different (more > appropriate, in my view) technology for dealing with the problem. There > are some very nice candidates for Ant and Maven replacements out there: > Gant, Gradle and Buildr to name the obvious trio. (Disclosure: I work > on Gant and Gradle :-) These provides for scripting rather than having > to create a plugin. The fact is, any component in Commons Proper will continue to live on as long as folks contribute to it (and contributions are welcome for any part of Commons). Other options are often available, but thats besides the point if folks care to continue contributing. -Rahul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[OT] Open
On Sun, Nov 9, 2008 at 1:14 AM, Russel Winder <[EMAIL PROTECTED]> wrote: > > For a couple of my projects, Codehaus is the host so the central > mainline is a Subversion repository. However most work is done using > Bazaar or Git since people do not need an account to be able to work > using a full VCS. Using a DVCS makes working on a FOSS project truly > open. > Yes, there are many advantages, productivity improvements etc. But lets not tout openness. There are certain things to keep in mind. We are truly open in the sense that anyone can access the code and propose changes. We are not truly open in the sense that we make a concerted effort to vet any contributions and make sure they are encumbrance-free. We require folks demonstrate merit first. We require people to understand and agree to certain terms before they make significant contributions. In essence, we require contributors to be aware there are certain requirements that enable corporations, large and small, and individuals alike to pick up code developed here and use it in their products or work with a reasonable degree of assuredness. Lets call this requirement the state of awareness. Consider there is a DVCS master (say, a focal point for official releases) that pulls from N levels of a tree (the topology may be very different, but for the sake of this discussion, a tree may be a reasonable starting point). It is then, not sufficient to have this state of awareness for some levels n where n < N. It has to exist from the root to each leaf. Furthermore, it has to be transparent, trivial to ascertain, auditable and governable (governance is a slightly emphatic term). Any practice that dilutes the above value proposition that our software has for many of our users, be it a true or truthy (AKA popular perception) dilution, is not acceptable. This is all possible with DVCS. It is possible to make sure that all code is pulled in with this state of awareness, all parties involved understand and subscribe to the thinking that is behind our license etc. But therein you already have a restriction. And within those bounds, we are already truly open. -Rahul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]: Project commons-configuration-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 [EMAIL PROTECTED] Project commons-configuration-test has an issue affecting its community integration. This issue affects 1 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-configuration-test : Apache Commons Full details are available at: http://vmgump.apache.org/gump/public/apache-commons/commons-configuration-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -WARNING- Overriding Maven2 settings: [/srv/gump/public/workspace/apache-commons/configuration/gump_mvn_settings.xml] -DEBUG- (Gump generated) Maven2 Settings in: /srv/gump/public/workspace/apache-commons/configuration/gump_mvn_settings.xml -INFO- Failed with reason build failed -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/configuration/pom.xml The following work was performed: http://vmgump.apache.org/gump/public/apache-commons/commons-configuration-test/gump_work/build_apache-commons_commons-configuration-test.html Work Name: build_apache-commons_commons-configuration-test (Type: Build) Work ended in a state of : Failed Elapsed: 3 mins 11 secs Command Line: mvn --batch-mode --settings /srv/gump/public/workspace/apache-commons/configuration/gump_mvn_settings.xml test [Working Directory: /srv/gump/public/workspace/apache-commons/configuration] CLASSPATH: /usr/lib/jvm/java-1.5.0-sun/lib/tools.jar:/srv/gump/public/workspace/apache-commons/configuration/target/commons-configuration-1.6-SNAPSHOT.jar - testSaveAttributes(org.apache.commons.configuration.TestXMLConfiguration) testCloneWithSave(org.apache.commons.configuration.TestXMLConfiguration) testEmptyElements(org.apache.commons.configuration.TestXMLConfiguration) testSaveWithEncoding(org.apache.commons.configuration.TestXMLConfiguration) testSaveWithNullEncoding(org.apache.commons.configuration.TestXMLConfiguration) testSaveWithDoctype(org.apache.commons.configuration.TestXMLConfiguration) testSaveWithDoctypeIDs(org.apache.commons.configuration.TestXMLConfiguration) testSubsetWithReload(org.apache.commons.configuration.TestXMLConfiguration) testConfigurationAtWithReload(org.apache.commons.configuration.TestXMLConfiguration) testConfigurationsAtWithReload(org.apache.commons.configuration.TestXMLConfiguration) testGetKeysWithReload(org.apache.commons.configuration.TestXMLConfiguration) testSetTextRootElement(org.apache.commons.configuration.TestXMLConfiguration) testClearTextRootElement(org.apache.commons.configuration.TestXMLConfiguration) testAutoSaveWithSubnodeConfig(org.apache.commons.configuration.TestXMLConfiguration) testAutoSaveWithSubSubnodeConfig(org.apache.commons.configuration.TestXMLConfiguration) testSaveDelimiterParsingDisabled(org.apache.commons.configuration.TestXMLConfiguration) testSaveDelimiterParsingDisabledAttrs(org.apache.commons.configuration.TestXMLConfiguration) testMultipleAttrValuesEscaped(org.apache.commons.configuration.TestXMLConfiguration) testAutoSaveWithReloadingStrategy(org.apache.commons.configuration.TestXMLConfiguration) testAutoSaveAddNodes(org.apache.commons.configuration.TestXMLConfiguration) testAddNodesAndSave(org.apache.commons.configuration.TestXMLConfiguration) testRegisterEntityId(org.apache.commons.configuration.TestXMLConfiguration) testSaveAfterCreateWithCopyConstructor(org.apache.commons.configuration.TestXMLConfiguration) testCopyRootName(org.apache.commons.configuration.TestXMLConfiguration) testCopyRootNameNoDocument(org.apache.commons.configuration.TestXMLConfiguration) testParse(org.apache.commons.configuration.TestBaseConfigurationXMLReader) testSetRootName(org.apache.commons.configuration.TestBaseConfigurationXMLReader) testParentReloadNotSupported(org.apache.commons.configuration.TestSubnodeConfiguration) testParentReloadSupported(org.apache.commons.configuration.TestSubnodeConfiguration) testParentReloadSupportAccessParent(org.apache.commons.configuration.TestSubnodeConfiguration) testParentReloadSubSubnode(org.apache.commons.configuration.TestSubnodeConfiguration) testParentReloadSubSubnodeNoChangeSupport(org.apache.commons.configuration.TestSubnodeConfiguration) testParse(org.apache.commons.configuration.TestHierarchicalConfigurationXMLReader) testLoadXMLWithSettings(org.apache.commons.configuration.TestDefaultConfigurationBuilder) Tests run: 1268, Failures: 0, Errors: 47, Skipped: 0 [INFO] [ERROR] BUILD FAILURE [INFO]
[FILEUPLOAD] How to turn off FileUpload automatic cleanup feature?
Hi, I'm using ServletFileUpload to upload a file with a DiskFileItemFactory. The file gets written to the temporary location, but before the file can be processed by a queue that will pick it up, the file is deleted. I set the diskfileitemfactory.setFileCleaningTracker(null) according to the documentation in order to turn off the cleanup automatic feature. Is there another way to turn it off? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[g...@vmgump]: Project commons-cli (in module commons-cli-1.x) 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 [EMAIL PROTECTED] Project commons-cli has an issue affecting its community integration. This issue affects 49 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - apollo : Apollo Project - checkstyle : Java style checker - commons-cli : Commons CLI Package - commons-jelly : Commons Jelly - commons-jelly-tags-ant : Commons Jelly - commons-jelly-tags-antlr : Commons Jelly - commons-jelly-tags-avalon : Commons Jelly - commons-jelly-tags-bean : Commons Jelly - commons-jelly-tags-beanshell : Commons Jelly - commons-jelly-tags-betwixt : Commons Jelly - commons-jelly-tags-bsf : Commons Jelly - commons-jelly-tags-define : Commons Jelly - commons-jelly-tags-define-test : Commons Jelly - commons-jelly-tags-dynabean : Commons Jelly - commons-jelly-tags-email : Commons Jelly - commons-jelly-tags-fmt : Commons Jelly - commons-jelly-tags-fmt-test : Commons Jelly - commons-jelly-tags-html : Commons Jelly - commons-jelly-tags-http : Commons Jelly - commons-jelly-tags-interaction : Commons Jelly - commons-jelly-tags-jaxme : Commons Jelly - commons-jelly-tags-jetty : Commons Jelly - commons-jelly-tags-jface : Commons Jelly - commons-jelly-tags-jms : Commons Jelly - commons-jelly-tags-jmx : Commons Jelly - commons-jelly-tags-jsl : Commons Jelly - commons-jelly-tags-jsl-test : Commons Jelly - commons-jelly-tags-junit : Commons Jelly - commons-jelly-tags-log : Commons Jelly - commons-jelly-tags-memory : Commons Jelly - commons-jelly-tags-ojb : Commons Jelly - commons-jelly-tags-quartz : Commons Jelly - commons-jelly-tags-regexp : Commons Jelly - commons-jelly-tags-soap : Commons Jelly - commons-jelly-tags-sql : Commons Jelly - commons-jelly-tags-swing : Commons Jelly - commons-jelly-tags-swt : Commons Jelly - commons-jelly-tags-threads : Commons Jelly - commons-jelly-tags-util : Commons Jelly - commons-jelly-tags-validate : Commons Jelly - commons-jelly-tags-velocity : Commons Jelly - commons-jelly-tags-xml : Commons Jelly - commons-jelly-tags-xml-test : Commons Jelly - commons-jelly-tags-xmlunit : Commons Jelly - commons-jelly-test : Commons Jelly - htmlunit : A tool for testing web based applications - maven : Project Management Tools - maven-bootstrap : Project Management Tools - muse : Muse Project Full details are available at: http://vmgump.apache.org/gump/public/commons-cli-1.x/commons-cli/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-cli-10112008.jar] identifier set to project name -DEBUG- (Gump generated) Maven2 Settings in: /srv/gump/public/workspace/commons-cli-1.x/gump_mvn_settings.xml -INFO- Failed with reason build failed -DEBUG- Maven POM in: /srv/gump/public/workspace/commons-cli-1.x/pom.xml -DEBUG- Extracted fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/commons-cli-1.x/commons-cli/gump_work/build_commons-cli-1.x_commons-cli.html Work Name: build_commons-cli-1.x_commons-cli (Type: Build) Work ended in a state of : Failed Elapsed: 2 mins 49 secs Command Line: mvn --batch-mode -Dmaven.final.name=commons-cli-10112008 --settings /srv/gump/public/workspace/commons-cli-1.x/gump_mvn_settings.xml package [Working Directory: /srv/gump/public/workspace/commons-cli-1.x] CLASSPATH: /usr/lib/jvm/java-1.5.0-sun/lib/tools.jar:/srv/gump/public/workspace/commons-cli-1.x/target/classes:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-trax.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/packages/junit3.8.1/junit.jar:/srv/gump/public/workspace/xml-commons/java/build/resolver.jar:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar - Downloading: http://localhost:8192/maven2/org/codehaus/plexus/plexus-compiler-api/1.5.3/plexus-compiler-api-1.5.3.jar 19K downloaded Downloading: http://localhost:8192/maven2/org/codehaus/plexus/plexus-compiler-manager/1.5.3/plexus-compiler-manager-1.5.3.jar 5K downloaded Downloading: http://localhost:8192/maven2/org/codehaus/plexus/plexus-compiler-ja
Re: Resurrecting commons-email - Was:MultiPartMail order of parts
Hi Simone, I guess the "someone else" is me :-) Cheers, Siegfried Goeschl Simone Gianni wrote: > Hi Siegfried, > I'm using commons-email in a few projects, so I'm interested in its > future. I'm not a commons committer, but I'm an Apache committer so I > know how to help testing the patches, writing tests, and so on .. > unfortunately someone else will have to take the job of committing stuff. > > Simone > > Siegfried Goeschl wrote: > >> Hi Markus, >> >> I opened a JIRA a while ago >> (http://issues.apache.org/jira/browse/EMAIL-77) to no avail. So it seems >> that commons-email do need some additional attention :-). >> >> +) well, during the next 2-3 weeks I try to get my commons-exec release >> out of the door (politely spoken the release is overdue) >> +) after that I can spend some time on commons-email to fix the most >> pressing issues >> +) I have an snapshot which does not have the problem and is used in >> productions >> >> Any hands out to help with commons-email and become a commons-email >> maintainer? >> >> +) looking at the changes report none of the original developers are >> around and/or actively working on commons ... :-( >> +) as part of Apache Turbine folks I'm attached to this project since it >> originated from there ... :-) >> >> Cheers, >> >> Siegfried Goeschl >> >> PS: a bit off-topic, does anyone know what Eric Pugh is currently doing?! >> >> Markus Mehrwald wrote: >> >> >>> Hello, >>> >>> I use a HTMLEmail with attachments. If I only set the text of the mail >>> everything works fine but adding attachments messes up the parts and >>> something else then my original text (in this case the attached text >>> file) is shown in my mail client. >>> It makes no difference if I attach files before or after setting the >>> mail text. >>> >>> Thank you for help, >>> Markus >>> >>> - >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >>> >>> >>> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Resurrecting commons-email - Was:MultiPartMail order of parts
Hi Siegfried, I'm using commons-email in a few projects, so I'm interested in its future. I'm not a commons committer, but I'm an Apache committer so I know how to help testing the patches, writing tests, and so on .. unfortunately someone else will have to take the job of committing stuff. Simone Siegfried Goeschl wrote: > Hi Markus, > > I opened a JIRA a while ago > (http://issues.apache.org/jira/browse/EMAIL-77) to no avail. So it seems > that commons-email do need some additional attention :-). > > +) well, during the next 2-3 weeks I try to get my commons-exec release > out of the door (politely spoken the release is overdue) > +) after that I can spend some time on commons-email to fix the most > pressing issues > +) I have an snapshot which does not have the problem and is used in > productions > > Any hands out to help with commons-email and become a commons-email > maintainer? > > +) looking at the changes report none of the original developers are > around and/or actively working on commons ... :-( > +) as part of Apache Turbine folks I'm attached to this project since it > originated from there ... :-) > > Cheers, > > Siegfried Goeschl > > PS: a bit off-topic, does anyone know what Eric Pugh is currently doing?! > > Markus Mehrwald wrote: > >> Hello, >> >> I use a HTMLEmail with attachments. If I only set the text of the mail >> everything works fine but adding attachments messes up the parts and >> something else then my original text (in this case the attached text >> file) is shown in my mail client. >> It makes no difference if I attach files before or after setting the >> mail text. >> >> Thank you for help, >> Markus >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> >> > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Simone GianniCEO Semeru s.r.l. Apache Committer http://www.simonegianni.it/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Blogging on Commons
Martin Cooper a écrit : > On Sun, Nov 9, 2008 at 8:06 AM, Luc Maisonobe <[EMAIL PROTECTED]> wrote: > >> I would strongly protest against such a move. > > > I wasn't proposing such a move, merely speculating. > > >> Commons are used outside >> of the ASF and are successful there. I even think [math] is used almost >> only outside of ASF and not internally ... Commons appear also as low >> level libraries for general use and this should not be stopped. >> >> I have seen many projects that depend on a huge number of libraries. For >> such projects, a reliable set of reusable components with consistent >> look and feel is a sure gain. >> >> Low level components are important and from my experience often need >> specific development rules, very strict ones. The reason for that is >> that you can never make any assumptions on how a low level component >> will be called/integrated/reused from a random high level complete >> application. >> >> I see the views expressed in both the original post and the previous >> message as if high level applications were the only important thing and >> low level components were second class "toys" to share but not to care >> too much about. Is this really what you meant or did I misunderstood >> your point ? > > > I believe you misunderstood. I know that I did not mean to imply that, and > I'm certain that Hen didn't either. His uses of the word "toys" are a play > on an English idiom about "taking ones toys and going home", and are not > meant to imply that there's anything toy-like about Commons components. On > the contrary, I think we're both arguing that Commons components are > important enough that we want to find ways to encourage people to bring > reusable code here rather than simply keep it to themselves and not sharing > it. That's fine, then. Sorry for my lack of cultural background. Luc > > -- > Martin Cooper > > > Luc >>> No answers here, I'm afraid. Just some additional thoughts to add to the >>> mix. >>> >>> -- >>> Martin Cooper >>> >>> >>> On Fri, Nov 7, 2008 at 11:20 PM, Henri Yandell <[EMAIL PROTECTED]> >> wrote: Apologies for writing this as a blog rather than an email - it felt more natural and will pull in other opinions: >> http://blog.generationjava.com/roller/bayard/entry/the-open-and-federated-commons Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jelly] Is jelly still in development vs. Open/FederatedCommons
John, Le 10-nov.-08 à 07:11, John Spackman a écrit : Yes, kind of - I've only recently come across Git and the concept of DVCS but it was my intention to look at using a DVCS for this. But DVCS "only" does source code - setting up a seperate branch only works if the community at large see the new branch, whereas the Commons group are considering marking Jelly as "No Longer Maintained" and moving the repository out of the main branch. Hey no! It's lacking maintainer and we shall be more than happy to make you a committer having been able to measure the quality of contributions! The problem is not the technical approach of DVCS, the problem is only endorsement: it seems rather normal that a person that hasn't been seen is first a bit observed or? Setting up a separate fork for a while to achieve this sounds an avenue to me. Suggesting patches on jira or any other method or paced-down contribution should be supported. I'm happy to receive your source tree from time to time, in full, inspect it and commit it as is for example. From my point of view, I would only want to perform a public branch with the endorsment of the Commons team; IMHO it's important for new and existing users to see a future for the project, and for there to be a link from the official Commons website to the federated Jelly site. The original downloads would remain for backward compatability, but the Commons site would clearly refer users onto the new site for upgrades and future development. I don't see any reason why commons would say "things are happening elsewhere" while it could happen here real soon now. The issue is endorsement and not distribution. paul smime.p7s Description: S/MIME cryptographic signature
Re: [g...@vmgump]: Project commons-cli (in module commons-cli-1.x) failed
On 2008-11-10, Stefan Bodewig <[EMAIL PROTECTED]> wrote: > I'll look into the proxy logs to see whether something unexpected is > being downloaded. INFO: Redirecting via client connector to: http://repo1.maven.org/maven2/org/apa che/maven/plugins/maven-plugins/11/maven-plugins-11.pom Nov 10, 2008 12:47:00 AM com.noelios.restlet.LogFilter afterHandle INFO: 2008-11-1000:47:00127.0.0.1 - repo1.maven.org -1 GET /maven2/org/apache/maven/plugins/maven-plugins/11/maven-plugins- 11.pom - 200 10298 - 276 http://localhost:8192 Java/1.5 .0_11 - Nov 10, 2008 12:47:00 AM org.restlet.Redirector handle INFO: Redirecting via client connector to: http://repo1.maven.org/maven2/org/apa che/maven/plugins/maven-plugins/11/maven-plugins-11.pom.sha1 Nov 10, 2008 12:47:01 AM com.noelios.restlet.LogFilter afterHandle INFO: 2008-11-1000:47:01127.0.0.1 - repo1.maven.org -1 GET /maven2/org/apache/maven/plugins/maven-plugins/11/maven-plugins- 11.pom.sha1 - 500 193 - 291 http://localhost:8192 Java/1.5.0_11 - means we get a 500 HTTP return code for the SHA1 file. This seems to be transient since I find other logs (yesterday, for example) where things worked and I can download the file right now. No idea what is going on, but unless httpclient (used by the client lib of restlet) is doing something strange here, I'd say the 500 error has been real and I don't see how Gump could avoid it. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [g...@vmgump]: Project commons-cli (in module commons-cli-1.x) failed
On 2008-11-10, Emmanuel Bourg <[EMAIL PROTECTED]> wrote: > Russel Winder a écrit : >> This command works for me on Ubuntu Hardy with JDK 1.6.0_07-b06 and >> Maven 2.0.9. I have noticed that this build has failed for three weeks >> now but it seems there is no-one around picking up on it. > I guess there is an issue with Gump and Maven 2. I'm just ignoring > this warning for now, I'll look into this later. Gump puts a proxy between mvn and the central repository. For POM files the requests are just passed on without the proxy doing anything to them. For example http://localhost:8192/maven2/org/apache/maven/plugins/maven-plugins/11/maven-plugins-11.pom will be http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-plugins/11/maven-plugins-11.pom which indeed works for me. I have no idea what the actual error message means, this is Maven 2.0.9 on an oldish Ubuntu. Something similar seems to happen for all the mvn builds right now (bcel fails as well, only the version is 8 instead of 11). I'll look into the proxy logs to see whether something unexpected is being downloaded. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[g...@vmgump]: Project commons-compress-test (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 [EMAIL PROTECTED] Project commons-compress-test has an issue affecting its community integration. This issue affects 1 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-compress-test : Apache commons sandbox Full details are available at: http://vmgump.apache.org/gump/public/commons-sandbox/commons-compress-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -WARNING- Overriding Maven2 settings: [/srv/gump/public/workspace/commons-sandbox/compress/gump_mvn_settings.xml] -DEBUG- (Gump generated) Maven2 Settings in: /srv/gump/public/workspace/commons-sandbox/compress/gump_mvn_settings.xml -INFO- Failed with reason build failed -DEBUG- Maven POM in: /srv/gump/public/workspace/commons-sandbox/compress/pom.xml The following work was performed: http://vmgump.apache.org/gump/public/commons-sandbox/commons-compress-test/gump_work/build_commons-sandbox_commons-compress-test.html Work Name: build_commons-sandbox_commons-compress-test (Type: Build) Work ended in a state of : Failed Elapsed: 58 secs Command Line: mvn --batch-mode --settings /srv/gump/public/workspace/commons-sandbox/compress/gump_mvn_settings.xml package [Working Directory: /srv/gump/public/workspace/commons-sandbox/compress] CLASSPATH: /usr/lib/jvm/java-1.5.0-sun/lib/tools.jar:/srv/gump/public/workspace/commons-sandbox/compress/target/commons-compress-1.0-SNAPSHOT.jar - 5K downloaded Downloading: http://localhost:8192/maven2/org/apache/maven/maven-parent/5/maven-parent-5.pom 14K downloaded Downloading: http://localhost:8192/maven2/org/apache/apache/3/apache-3.pom 3K downloaded Downloading: http://localhost:8192/maven2/org/apache/maven/plugins/maven-compiler-plugin/2.0.2/maven-compiler-plugin-2.0.2.jar 17K downloaded Downloading: http://localhost:8192/maven2/org/apache/maven/plugins/maven-surefire-plugin/2.4.2/maven-surefire-plugin-2.4.2.pom 6K downloaded Downloading: http://localhost:8192/maven2/org/apache/maven/surefire/surefire/2.4.2/surefire-2.4.2.pom 6K downloaded Downloading: http://localhost:8192/maven2/org/apache/maven/maven-parent/7/maven-parent-7.pom 20K downloaded Downloading: http://localhost:8192/maven2/org/apache/maven/plugins/maven-surefire-plugin/2.4.2/maven-surefire-plugin-2.4.2.jar 21K downloaded Downloading: http://localhost:8192/maven2/org/apache/maven/plugins/maven-jar-plugin/2.2/maven-jar-plugin-2.2.pom 8K downloaded Downloading: http://localhost:8192/maven2/org/apache/maven/plugins/maven-plugins/10/maven-plugins-10.pom 7K downloaded Downloading: http://localhost:8192/maven2/org/apache/maven/plugins/maven-jar-plugin/2.2/maven-jar-plugin-2.2.jar 26K downloaded [INFO] artifact org.apache.maven.plugins:maven-idea-plugin: checking for updates from central Downloading: http://localhost:8192/maven2/org/apache/maven/plugins/maven-idea-plugin/2.2/maven-idea-plugin-2.2.pom 13K downloaded Downloading: http://localhost:8192/maven2/org/apache/maven/plugins/maven-plugins/11/maven-plugins-11.pom 10K downloaded [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. GroupId: org.apache.maven.plugins ArtifactId: maven-plugins Version: 11 Reason: Unable to download the artifact from any repository org.apache.maven.plugins:maven-plugins:pom:11 from the specified remote repositories: Gump (http://localhost:8192/maven2) [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 56 seconds [INFO] Finished at: Mon Nov 10 02:08:10 GMT-08:00 2008 [INFO] Final Memory: 3M/7M [INFO] - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/commons-sandbox/commons-compress-test/rss.xml - Atom: http://vmgump.apache.org/gump/public/commons-sandbox/commons-compress-test/atom.xml == Gump Tracking Only === Produced by Gump version 2.3. Gump Run 1110112008, vmgump:vmgump-public:1110112008 Gump E-mail Identifier (unique within run) #17. -- Apache Gump http://gump.apache.org/ [Instance: vmgump] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL
Re: Blogging on Commons
On Mon, Nov 10, 2008 at 8:51 AM, Viraj Turakhia <[EMAIL PROTECTED]>wrote: > If I have read it right, I do agree with the point that we need to give > committers access to people more freely. > Definitly.Primetime developing for Commons is no fun. It's a bit frustrating. Maybe there should be some kind of "mentoring" at commons. Means, a new developer who proved himself with some patches or interest gets committer access for some kind of propation time. In that time a commiter "mentors" that guy and takes a look at the sources. Chris.
Re: [g...@vmgump]: Project commons-cli (in module commons-cli-1.x) failed
Russel Winder a écrit : This command works for me on Ubuntu Hardy with JDK 1.6.0_07-b06 and Maven 2.0.9. I have noticed that this build has failed for three weeks now but it seems there is no-one around picking up on it. I guess there is an issue with Gump and Maven 2. I'm just ignoring this warning for now, I'll look into this later. Emmanuel Bourg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [g...@vmgump]: Project commons-cli (in module commons-cli-1.x) failed
On Mon, 2008-11-10 at 00:47 -0800, Gump wrote: [ . . . ] > Full details are available at: > > http://vmgump.apache.org/gump/public/commons-cli-1.x/commons-cli/index.html > > That said, some information snippets are provided here. > > The following annotations (debug/informational/warning/error messages) were > provided: > -DEBUG- Sole output [commons-cli-10112008.jar] identifier set to project name > -DEBUG- (Gump generated) Maven2 Settings in: > /srv/gump/public/workspace/commons-cli-1.x/gump_mvn_settings.xml > -INFO- Failed with reason build failed > -DEBUG- Maven POM in: /srv/gump/public/workspace/commons-cli-1.x/pom.xml > -DEBUG- Extracted fallback artifacts from Gump Repository > > > > The following work was performed: > http://vmgump.apache.org/gump/public/commons-cli-1.x/commons-cli/gump_work/build_commons-cli-1.x_commons-cli.html > Work Name: build_commons-cli-1.x_commons-cli (Type: Build) > Work ended in a state of : Failed > Elapsed: 1 min 10 secs > Command Line: mvn --batch-mode -Dmaven.final.name=commons-cli-10112008 > --settings /srv/gump/public/workspace/commons-cli-1.x/gump_mvn_settings.xml > package > [Working Directory: /srv/gump/public/workspace/commons-cli-1.x] > CLASSPATH: > /usr/lib/jvm/java-1.5.0-sun/lib/tools.jar:/srv/gump/public/workspace/commons-cli-1.x/target/classes:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-trax.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/packages/junit3.8.1/junit.jar:/srv/gump/public/workspace/xml-commons/java/build/resolver.jar:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar > - This command works for me on Ubuntu Hardy with JDK 1.6.0_07-b06 and Maven 2.0.9. I have noticed that this build has failed for three weeks now but it seems there is no-one around picking up on it. Is there anyone available to give Emmanuel a hand -- CLI 1.2 needs to get released and he is snowed under with other stuff. [ . . . ] -- Russel. Dr Russel Winder Partner Concertant LLP t: +44 20 7585 2200, +44 20 7193 9203 41 Buckmaster Road, f: +44 8700 516 084 London SW11 1EN, UK. m: +44 7770 465 077 signature.asc Description: This is a digitally signed message part
[g...@vmgump]: Project commons-cli (in module commons-cli-1.x) 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 [EMAIL PROTECTED] Project commons-cli has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 20 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-cli : Commons CLI Package Full details are available at: http://vmgump.apache.org/gump/public/commons-cli-1.x/commons-cli/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-cli-10112008.jar] identifier set to project name -DEBUG- (Gump generated) Maven2 Settings in: /srv/gump/public/workspace/commons-cli-1.x/gump_mvn_settings.xml -INFO- Failed with reason build failed -DEBUG- Maven POM in: /srv/gump/public/workspace/commons-cli-1.x/pom.xml -DEBUG- Extracted fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/commons-cli-1.x/commons-cli/gump_work/build_commons-cli-1.x_commons-cli.html Work Name: build_commons-cli-1.x_commons-cli (Type: Build) Work ended in a state of : Failed Elapsed: 1 min 10 secs Command Line: mvn --batch-mode -Dmaven.final.name=commons-cli-10112008 --settings /srv/gump/public/workspace/commons-cli-1.x/gump_mvn_settings.xml package [Working Directory: /srv/gump/public/workspace/commons-cli-1.x] CLASSPATH: /usr/lib/jvm/java-1.5.0-sun/lib/tools.jar:/srv/gump/public/workspace/commons-cli-1.x/target/classes:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-trax.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/packages/junit3.8.1/junit.jar:/srv/gump/public/workspace/xml-commons/java/build/resolver.jar:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar - 7K downloaded Downloading: http://localhost:8192/maven2/org/apache/maven/maven-parent/7/maven-parent-7.pom 20K downloaded Downloading: http://localhost:8192/maven2/org/apache/maven/plugins/maven-surefire-plugin/2.4.3/maven-surefire-plugin-2.4.3.jar 22K downloaded Downloading: http://localhost:8192/maven2/org/apache/maven/plugins/maven-jar-plugin/2.2/maven-jar-plugin-2.2.pom 8K downloaded Downloading: http://localhost:8192/maven2/org/apache/maven/plugins/maven-plugins/10/maven-plugins-10.pom 7K downloaded Downloading: http://localhost:8192/maven2/org/apache/maven/plugins/maven-jar-plugin/2.2/maven-jar-plugin-2.2.jar 26K downloaded Downloading: http://localhost:8192/maven2/org/apache/maven/plugins/maven-assembly-plugin/2.2-beta-1/maven-assembly-plugin-2.2-beta-1.pom 12K downloaded Downloading: http://localhost:8192/maven2/org/apache/maven/plugins/maven-assembly-plugin/2.2-beta-1/maven-assembly-plugin-2.2-beta-1.jar 150K downloaded Downloading: http://localhost:8192/maven2/org/apache/felix/maven-bundle-plugin/1.4.0/maven-bundle-plugin-1.4.0.pom 4K downloaded Downloading: http://localhost:8192/maven2/org/apache/felix/felix/1.0.2/felix-1.0.2.pom 13K downloaded Downloading: http://localhost:8192/maven2/org/apache/felix/maven-bundle-plugin/1.4.0/maven-bundle-plugin-1.4.0.jar 134K downloaded [INFO] artifact org.apache.maven.plugins:maven-idea-plugin: checking for updates from central Downloading: http://localhost:8192/maven2/org/apache/maven/plugins/maven-idea-plugin/2.2/maven-idea-plugin-2.2.pom 13K downloaded Downloading: http://localhost:8192/maven2/org/apache/maven/plugins/maven-plugins/11/maven-plugins-11.pom 10K downloaded [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. GroupId: org.apache.maven.plugins ArtifactId: maven-plugins Version: 11 Reason: Unable to download the artifact from any repository org.apache.maven.plugins:maven-plugins:pom:11 from the specified remote repositories: Gump (http://localhost:8192/maven2) [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 1 minute 9 seconds [INFO] Finished at: Mon Nov 10 00:47:01 GMT-08:00 2008 [INFO] Final Memory: 5M/9M [INFO]
Re: [jelly] Is jelly still in development vs. Open/FederatedCommons
John, On Mon, 2008-11-10 at 06:11 +, John Spackman wrote: [ . . . ] > >Isn't this whole Subversion centralism problem solved by using a DVCS > >such as Bazaar, or Git -- and soon, I gather, Mercurial. > > Yes, kind of - I've only recently come across Git and the concept of DVCS > but it was my intention to look at using a DVCS for this. Bazaar is probably easier for Subversion users to get used to as the command set is more aligned with that of Subversion. (The same goes for Mercurial, but it's Subversion interworking is not yet usable for production working as far as I know.) > But DVCS "only" does source code - setting up a seperate branch only works > if the community at large see the new branch, whereas the Commons group are > considering marking Jelly as "No Longer Maintained" and moving the > repository out of the main branch. I tend to use Launchpad as a place to store Bazaar branches where the host of the Subversion repository cannot support Bazaar. GitHub seems to be the place to store a Git repository in a similar circumstance. A word of warning: Using Bazaar or Git as a Subversion client is not the same as using them as fully-fledged DVCS. The need to rebase so as to remain consistent with the Subversion repository means that many of the aspects of workflow of using DVCS have to be amended. A Bazaar branch of a Subversion repository or a Git clone of a Subversion repository must always be treated as a view on the Subversion repository and not used as a free standing branch/repository. If anyone is in Oxford, UK 2009-04 then you might think about attending the ACCU 2009 conference. Jim Hague, Time Penhey and myself are doing a session on DVCS. > From my point of view, I would only want to perform a public branch with the > endorsment of the Commons team; IMHO it's important for new and existing > users to see a future for the project, and for there to be a link from the > official Commons website to the federated Jelly site. The original > downloads would remain for backward compatability, but the Commons site > would clearly refer users onto the new site for upgrades and future > development. I guess I am in the "XML is a data specification language and has no right having a computational model, that's what dynamic languages like Groovy, Python and Ruby are for." camp, so I don't see the demise of Jelly as a problem. Of course graceful demise is entirely appropriate. The question I have is whether putting effort into maintaining a demising system is worth it compared to putting that effort into transferring to a different (more appropriate, in my view) technology for dealing with the problem. There are some very nice candidates for Ant and Maven replacements out there: Gant, Gradle and Buildr to name the obvious trio. (Disclosure: I work on Gant and Gradle :-) These provides for scripting rather than having to create a plugin. -- Russel. Dr Russel Winder Partner Concertant LLP t: +44 20 7585 2200, +44 20 7193 9203 41 Buckmaster Road, f: +44 8700 516 084 London SW11 1EN, UK. m: +44 7770 465 077 signature.asc Description: This is a digitally signed message part
