RE: [VFS] SCM cleanup, Deleting Tags and Branches
In general I do not think we should delete things unless they are harmful. Who knows what bits of history will be helpful... we can certainly have better docs of what we think is useful. That said, I won't stand in the way of folks who consider this helpful work. Gary div Original message /divdivFrom: Bernd Eckenfels e...@zusammenkunft.net /divdivDate:11/29/2014 22:16 (GMT-05:00) /divdivTo: dev@commons.apache.org /divdivCc: /divdivSubject: [VFS] SCM cleanup, Deleting Tags and Branches /divdiv /divHello, I was struggling a bit with a backport of fixes to 2.0. There are some tags and branches in the repo which are not self explanatory. I found out that tags/commons-vfs2-project-2.0 seems to be the 2.0 release source. It looks like branch/VFS-2.0 and branch/POMRELEASE are unused. Can we actually delete tags and branches? I think the following can be removed: branches/POMRELEASE branches/VFS-2.0 branches/VFS281 tags/preVFS2package tags/pre_filenameparsing tags/sandbox What do you think? Greetings Bernd - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] Do we need help?
On 29 Nov 2014 10:53, Benedikt Ritter brit...@apache.org wrote: Hi all, currently I feel really overwhelmed by the stuff I'd like to do at commons and the little time I can spend for it. Here is an (incomplete) list of the things I'd like to work on: - get a new release of the build plugin out of the door for auto creating README.md and CONTRIBUTING.md - Work on [VALIDATOR] and get a new release out of the door - Work on [DBUTILS] and get a new release out of the door - Push [lang] 3.4 out of the door - Have a look at [compress] 2.0 - Backport important fixes from [collections] 4.0 to 3.x and create a last service update - work on [text] - help releasing [imaging] 1.0 - Improve docs on how to get involved at commons - Organize a logo contest for commons - ... many more I wonder how you feel about this. I have the feeling that a lot of people ask us to fix stuff and release components but we don't really catch up with this. This will give people the feeling that we are slow or we simply don't care. Is the release process unnecessarily cumbersome for the RM? If so, perhaps some time spent automating more of the procedure would be worthwhile. Maybe we could consider some guidelines for when a release is needed. E.g. After X fixes or Y new features then a release ought to happen unless there is a strong reason not to. Duncan Whenever I see someone posting on JIRA can you please fix this, we need this in out application and nobody is reacting, I feel tempted to jump right in, even if I don't know the component (which adds another entry to the list above). I don't see a way how we can improve this. My feeling is, that we need more committers. But then I have the comments of people I've talked to in my ear: to old school, to difficult to get involved, to slow development process, to unwelcoming community. So what do we do? Do we need help? I'm excited to hear your thoughts :-) Best regards, Benedikt -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter
Re: [ALL] Do we need help?
On Sun, Nov 30, 2014 at 9:25 AM, Duncan Jones djo...@apache.org wrote: On 29 Nov 2014 10:53, Benedikt Ritter brit...@apache.org wrote: Hi all, currently I feel really overwhelmed by the stuff I'd like to do at commons and the little time I can spend for it. Here is an (incomplete) list of the things I'd like to work on: - get a new release of the build plugin out of the door for auto creating README.md and CONTRIBUTING.md - Work on [VALIDATOR] and get a new release out of the door - Work on [DBUTILS] and get a new release out of the door - Push [lang] 3.4 out of the door - Have a look at [compress] 2.0 - Backport important fixes from [collections] 4.0 to 3.x and create a last service update - work on [text] - help releasing [imaging] 1.0 - Improve docs on how to get involved at commons - Organize a logo contest for commons - ... many more I wonder how you feel about this. I have the feeling that a lot of people ask us to fix stuff and release components but we don't really catch up with this. This will give people the feeling that we are slow or we simply don't care. Is the release process unnecessarily cumbersome for the RM? RM'ing is a PITA IMO. I do not see it changing any time soon. The dual distribution to Maven Central and the Apache Dist server complicates things of course. It's plain silly IMO, we should just push to an Apache Maven repo and be done. But... that's a topic for Apache at large. If so, perhaps some time spent automating more of the procedure would be worthwhile. Maybe we could consider some guidelines for when a release is needed. E.g. After X fixes or Y new features then a release ought to happen unless there is a strong reason not to. While I appreciate the good intention, you still need a volunteer RM. It does not matter how many fixes are pending and whether we have rules that say we must release. I like RERO myself but the release gymnastics are lame... but that is what we have now and I do not see change it an easy thing to do... Perhaps we can pick some topics to discuss individually. Gary Duncan Whenever I see someone posting on JIRA can you please fix this, we need this in out application and nobody is reacting, I feel tempted to jump right in, even if I don't know the component (which adds another entry to the list above). I don't see a way how we can improve this. My feeling is, that we need more committers. But then I have the comments of people I've talked to in my ear: to old school, to difficult to get involved, to slow development process, to unwelcoming community. So what do we do? Do we need help? I'm excited to hear your thoughts :-) Best regards, Benedikt -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition http://www.manning.com/bauer3/ JUnit in Action, Second Edition http://www.manning.com/tahchiev/ Spring Batch in Action http://www.manning.com/templier/ Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
Re: [ALL] Do we need help?
Releasing VFS is long overdue. Whether it should be 2.1 or 3.0 (WRT compatiblity) is the first thing we should discuss. Gary On Sat, Nov 29, 2014 at 9:54 PM, Ralph Goers ralph.go...@dslextreme.com wrote: I acted as release manager for 2.0. I did that because at the time I had a need for Commons VFS, I had a need to fix a bunch of stuff that didn’t work in 1.0, and I had the necessary privileges to do it. Since that time I have been focused on Log4j 2 almost completely with what little time I have. I have seen others commit fixes and enhancements and like you, I have been surprised that no one has bothered to perform a release. It should have happened a long time ago. One challenge to releasing VFS is that unlike most Commons projects, it is a multi-module project and it uses the Maven release plugin to perform a release. While this makes things a bit more complicated it still isn’t that hard to do. Unfortunately, I don’t believe I documented the release process but it should be similar to http://wiki.apache.org/logging/Log4j2ReleaseGuide http://wiki.apache.org/logging/Log4j2ReleaseGuide, since I based the Log4j build and release process after VFS. Ralph On Nov 29, 2014, at 8:27 AM, dlmar...@comcast.net wrote: My 2 cents as an outsider, for what it's worth. I have contributed code to VFS and we use VFS in Accumulo. I and several others have asked for a 2.1 release, or at least a plan/roadmap so that we know what has to happen before a release can occur. I even offered to help in any way possible[1]. The answer I received was that a release manager was assigned, but no other information. Since then I have seen a bunch of other commons projects being released. I figure that maybe they are dependencies and need to be released first before a VFS release. Personally, I would like to remove the VFS objects from Accumulo when VFS 2.1 is released. I know that we are also running into VFS-487, which I spent some time updating the patch and verifying the tests work. I would like to update the HDFS dependency to the latest before the 2.1 release (VFS-530), but I don't know when that is going to happen. I would also like to take advantage of some of the fixes in 2.1, like VFS-500. I understand this is a volunteer organization and everyone is busy. However, from my perspective, you have turned down an offer to help. FWIW, I have thought about taking VFS 2.1-SNAPSHOT, applying the patches I want, and creating a release for use on my project (not Accumulo). [1] http://mail-archives.apache.org/mod_mbox/commons-dev/201406.mbox/%3c423905266.3540581.1402347208157.javamail.r...@comcast.net%3E - Dave - Original Message - From: Gary Gregory garydgreg...@gmail.com To: Commons Developers List dev@commons.apache.org Sent: Saturday, November 29, 2014 7:42:35 AM Subject: RE: [ALL] Do we need help? It feels overwhelming sometimes sure, but for me I just realize that this is just a self inflicted feeling. We are all volunteers here with no contractual or hard expectations. We could do better at managing expectations for certain and recruiting new blood, yes. But that takes time away from fun development tasks... I usually ask for patches as soon as someone asks for a fix or feature. At least that should make it more obvious to users and the community that you get out of Commons what you put in to some extent. Gary div Original message /divdivFrom: Benedikt Ritter brit...@apache.org /divdivDate:11/29/2014 05:53 (GMT-05:00) /divdivTo: Commons Developers List dev@commons.apache.org /divdivCc: /divdivSubject: [ALL] Do we need help? /divdiv /divHi all, currently I feel really overwhelmed by the stuff I'd like to do at commons and the little time I can spend for it. Here is an (incomplete) list of the things I'd like to work on: - get a new release of the build plugin out of the door for auto creating README.md and CONTRIBUTING.md - Work on [VALIDATOR] and get a new release out of the door - Work on [DBUTILS] and get a new release out of the door - Push [lang] 3.4 out of the door - Have a look at [compress] 2.0 - Backport important fixes from [collections] 4.0 to 3.x and create a last service update - work on [text] - help releasing [imaging] 1.0 - Improve docs on how to get involved at commons - Organize a logo contest for commons - ... many more I wonder how you feel about this. I have the feeling that a lot of people ask us to fix stuff and release components but we don't really catch up with this. This will give people the feeling that we are slow or we simply don't care. Whenever I see someone posting on JIRA can you please fix this, we need this in out application and nobody is reacting, I feel tempted to jump right in, even if I don't know the component (which adds another entry to the list above). I don't see a way how we can improve this. My
Re: [ALL] Do we need help?
We should start a separate ML thread of VFS. Gary On Sat, Nov 29, 2014 at 9:56 PM, Bernd Eckenfels e...@zusammenkunft.net wrote: Hello, well I dont think we need to dig into the past, no matter if a RM is assigned or not, a release will happen when people get around to do it. And since the people who can do it are already overloaded it can get tricky. And I think the biggest roadblock is the large number of changes which have been implemented and which need to be ironed out in terms of compatibility. (Clirr Report especially). Greetings Bernd PS: in VFS-523 there are some open questions. I would like to go with the removal. However I think with updated hdfs libraries the windows tests do not work anymore, which makes it hard for me to test. Am Sat, 29 Nov 2014 21:36:35 -0500 schrieb dlmar...@comcast.net: Sorry, I thought a RM had been assigned[1]. I don't think I have any patches for open tickets, the tickets that I am interested in (487,500,530) already have patches waiting to be applied. Additionally, if there are open issues w/r/t HDFS integration, then I can address them as well. The only HDFS related issues I see at this time are 523 and 530, both of which have patches. I can update 530 with a more recent version of HDFS before a release of VFS. I don't remember seeing a previous discussion regarding a 2.1 release. It's very possible I missed it or it was filtered. Please let me know how I can help. [1] http://mail-archives.apache.org/mod_mbox/commons-dev/201407.mbox/%3CCACZkXPz M5a3PEqk8Yq6TJdued6bNLd_286xKeEqAeuNMv6Svyg%40mail.gmail.com%3E -Original Message- From: Bernd Eckenfels [mailto:e...@zusammenkunft.net] Sent: Saturday, November 29, 2014 3:21 PM To: dlmar...@comcast.net Cc: Commons Developers List Subject: Re: [ALL] Do we need help? Hello, I dont think we have a release manager for VFS, but I am still working on Bugs. If you have a patch for a Bug which affects you, please upload it to Jira. We can need all helps to prune them down. Right now we have 3 blockers open. 2 in the area of FTP which I do not have much experience with and one memory leaks where I am working on. Once those are closed or downgraded we can try a release. However last time I tried to start a discussion not much help was received. I suspect this might chnage when the first RC is put out and all the negative votes come in (there is a large Clirr report and while I think most of it is acceptable, I really think we need to talk about it). This is where Garys question comes in. Yes we might be a volunteering organisation, but certain things bottleneck on experienced people in the PMC. And I dont really know a way around this. Gruss Bernd Am Sat, 29 Nov 2014 15:27:02 + (UTC) schrieb dlmar...@comcast.net: My 2 cents as an outsider, for what it's worth. I have contributed code to VFS and we use VFS in Accumulo. I and several others have asked for a 2.1 release, or at least a plan/roadmap so that we know what has to happen before a release can occur. I even offered to help in any way possible[1]. The answer I received was that a release manager was assigned, but no other information. Since then I have seen a bunch of other commons projects being released. I figure that maybe they are dependencies and need to be released first before a VFS release. Personally, I would like to remove the VFS objects from Accumulo when VFS 2.1 is released. I know that we are also running into VFS-487, which I spent some time updating the patch and verifying the tests work. I would like to update the HDFS dependency to the latest before the 2.1 release (VFS-530), but I don't know when that is going to happen. I would also like to take advantage of some of the fixes in 2.1, like VFS-500. I understand this is a volunteer organization and everyone is busy. However, from my perspective, you have turned down an offer to help. FWIW, I have thought about taking VFS 2.1-SNAPSHOT, applying the patches I want, and creating a release for use on my project (not Accumulo). [1] http://mail-archives.apache.org/mod_mbox/commons-dev/201406.mbox/%3C42 3905266.3540581.1402347208157.javamail.r...@comcast.net%3E - Dave - Original Message - From: Gary Gregory garydgreg...@gmail.com To: Commons Developers List dev@commons.apache.org Sent: Saturday, November 29, 2014 7:42:35 AM Subject: RE: [ALL] Do we need help? It feels overwhelming sometimes sure, but for me I just realize that this is just a self inflicted feeling. We are all volunteers here with no contractual or hard expectations. We could do better at managing expectations for certain and recruiting new blood, yes. But that takes time away from fun development tasks... I usually ask for patches as soon as someone asks for a fix or
Re: [csv] Object Mapping Proposal
FYI: the proposal depends on Java 8 and BeanUtils which is fine if it is in a separate module. Unless we want to make a Commons CSV 1.2 depend on Java 8. I'm not sure if I like the 'story' from a user-POV but it's a start ;-) I was wondering more about an annotation based system, but that would be more intrusive... Discuss! Gary On Sat, Nov 29, 2014 at 3:34 PM, Ulbricht, Frank f.ulbri...@qualitype.de wrote: Hello guys, I have created a new feature request CSV-146, so you may have a look on my code. Thanks, Frank. Von: Gary Gregorymailto:garydgreg...@gmail.com Gesendet: Samstag, 29. November 2014 13:38 An: dev@commons.apache.orgmailto:dev@commons.apache.org Hibernate is all about mappings. Yes, it sits on top of JDBC but that just means you need a CSV or perhaps Excel driver. There is a lot more value in creating/reusing a simple CSV JDBC driver than creating another custom mapping/binding framework which duplicates some features of a JDBC driver and Hibernate... My 2c, Gary div Original message /divdivFrom: Benedikt Ritter brit...@apache.org /divdivDate:11/29/2014 05:34 (GMT-05:00) /divdivTo: Commons Developers List dev@commons.apache.org /divdivCc: /divdivSubject: Re: [csv] Object Mapping Proposal /divdiv /div2014-11-28 19:41 GMT+01:00 Gary Gregory garydgreg...@gmail.com: This is probably out of scope for a light weight component like Commons CSV. You could use Hibernate for all your mapping needs. I don't understand what hibernate has to do with this, since it is an object-relational mapping framework and Frank's proposal is about mapping between CSV data and pojos... We talked about a mapping functionality for csv before. I agree that it is out of scope of what we have currently. but I could imagine to transform csv to a multiproject, that has a core component and a mapping component (and probably more) Frank, the mailing list server will strip any attachments. Can you create a github repository, so we can discuss your proposal in more detail? TIA! Benedikt Gary div Original message /divdivFrom: Ulbricht, Frank f.ulbri...@qualitype.de /divdivDate:11/28/2014 03:13 (GMT-05:00) /divdivTo: dev@commons.apache.org /divdivCc: /divdivSubject: [csv] Object Mapping Proposal /divdiv /divHello there, about 15 years ago I started to write a CSV library. Our company is using it for a long time now. Over the time a lot of interesting features were added. Now I have decided to replace it with the commons-csv. This API looks very good and it provides some low-level features our library is missing (e.g. multi-line records with escaping). Nevertheless, we have a lot of high-level features for easily mapping between objects and the csv files. I am planning to migrate those to use the commons-csv for the I/O work. And I want to use this chance to redesign our APIs. Now a thought crossed my mind, how about contributing this to the commons-csv? In order to get an idea want I am planning to do I have attached a sample project to this mail. It is just an idea, far from being perfect. It shall demonstrate how it may look like one day. Sure, in the moment this sample uses a lot of pretty cool Java 8 stuff, but there are ways to make it available to earlier Java versions too. Please have a look at the class “CSVObjectParserTest” it and tell me what you think. Thank you, Frank. P.S. Looks like my previous mail was ignored because the subscription process was not yet finished. If not, please ignore the duplicate mail. -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition http://www.manning.com/bauer3/ JUnit in Action, Second Edition http://www.manning.com/tahchiev/ Spring Batch in Action http://www.manning.com/templier/ Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
Re: [ALL] Do we need help?
Hello James, 2014-11-29 19:30 GMT+01:00 James Sawle jamessa...@hotmail.com: Hi all, Two things from me, a relatively new member of the community. I think much more effort needs to be on pushing things through code-review and to completion. There are many issues in LANG that have been awaiting review for well over a year or two. This means the commiters are no longer around to justify their decisions, and new contributors feel they are pushed aside whilst awaiting feedback. I've already recognized your activity on JIRA. Unfortunately Review work of James Sawle is just another entry on my TODO list. Secondly, there are too many long discussions around various issues, leading to either flame wars on decisions or no action being taken at all. The project leads should take the comments made and make a decision on what is to be done after a sensible set of comments have been made. This would be hard with how few people run the project, but maybe this would help rebalance and focus the project. I haven't experienced the flame wars you're talking about. There a two problems with long disucssions. 1. (as Mark has pointed out) there is no project lead you can just decide. 2. Long discussions are a hint that a problem is not fully understood or that there are two (or more) equally valid solutions to a problem. So it's hard (for me as a committer) to pick one... Benedikt Would be willing to discuss this further Sent from my iPhone On 29 Nov 2014, at 16:33, Thomas Neidhart thomas.neidh...@gmail.com wrote: On 11/29/2014 11:53 AM, Benedikt Ritter wrote: Hi all, currently I feel really overwhelmed by the stuff I'd like to do at commons and the little time I can spend for it. Here is an (incomplete) list of the things I'd like to work on: Hi Benedikt, - get a new release of the build plugin out of the door for auto creating README.md and CONTRIBUTING.md - Work on [VALIDATOR] and get a new release out of the door - Work on [DBUTILS] and get a new release out of the door - Push [lang] 3.4 out of the door - Have a look at [compress] 2.0 - Backport important fixes from [collections] 4.0 to 3.x and create a last service update - work on [text] - help releasing [imaging] 1.0 - Improve docs on how to get involved at commons - Organize a logo contest for commons - ... many more this sounds like you set your goals too high and are frustrated that you don't get all the things done. I guess this is a common scheme for ambitious/passionate people. Try to set more realistic goals and finish them before doing other / more things. Then you will get the positive feedback of achieving something and everything will be better. I wonder how you feel about this. I have the feeling that a lot of people ask us to fix stuff and release components but we don't really catch up with this. This will give people the feeling that we are slow or we simply don't care. Whenever I see someone posting on JIRA can you please fix this, we need this in out application and nobody is reacting, I feel tempted to jump right in, even if I don't know the component (which adds another entry to the list above). I don't see a way how we can improve this. My feeling is, that we need more committers. But then I have the comments of people I've talked to in my ear: to old school, to difficult to get involved, to slow development process, to unwelcoming community. So what do we do? Do we need help? I'm excited to hear your thoughts :-) yeah, this is a general problem of commons imho. There are too many components for a too small community as most of the original committers have long left. The only way out is to do what we tried a couple of months ago: move not maintained components to dormant, and keep the others alive with the existing people. Just one example: jelly is a nice thing and actually used within jenkins as the backbone html generator. But it is re-packaged within jenkins custom bugfixes as the last jelly release (1.0) was in 2005. Similar things apply for el or primitives. These components are long dead and there are very good alternatives available, so they should be abandoned. Cut off the dead branches to keep the tree alive. Thomas - 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 -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter
Re: [ALL] Do we need help?
Hello Bruno 2014-11-30 0:31 GMT+01:00 Bruno P. Kinoshita brunodepau...@yahoo.com.br: Hi Thomas! I use Jelly almost every week in Jenkins plug-ins. Talked about the forked repo they have in the project, and even told them I could spend some hours every week to fix the necessary issues. Even though it is possible to use Groovy in Jenkins views too now, there are so many existing plug-ins (that are used as basis for new plug-ins) that I find it very hard to see jelly removed from Jenkins. Would anyone be interested and have time to push a new release ? I could check what needed to be done in [jelly] and either update or add new issues. Bruno You always seem to be forgetting, that you're commons committer :-) If you feel like working on any component, just drop a mail on the ML and start work ;-) Other people will eventually join you. Benedikt From: Thomas Neidhart thomas.neidh...@gmail.com To: Commons Developers List dev@commons.apache.org Sent: Saturday, November 29, 2014 2:31 PM Subject: Re: [ALL] Do we need help? On 11/29/2014 11:53 AM, Benedikt Ritter wrote: Hi all, currently I feel really overwhelmed by the stuff I'd like to do at commons and the little time I can spend for it. Here is an (incomplete) list of the things I'd like to work on: Hi Benedikt, - get a new release of the build plugin out of the door for auto creating README.md and CONTRIBUTING.md - Work on [VALIDATOR] and get a new release out of the door - Work on [DBUTILS] and get a new release out of the door - Push [lang] 3.4 out of the door - Have a look at [compress] 2.0 - Backport important fixes from [collections] 4.0 to 3.x and create a last service update - work on [text] - help releasing [imaging] 1.0 - Improve docs on how to get involved at commons - Organize a logo contest for commons - ... many more this sounds like you set your goals too high and are frustrated that you don't get all the things done. I guess this is a common scheme for ambitious/passionate people. Try to set more realistic goals and finish them before doing other / more things. Then you will get the positive feedback of achieving something and everything will be better. I wonder how you feel about this. I have the feeling that a lot of people ask us to fix stuff and release components but we don't really catch up with this. This will give people the feeling that we are slow or we simply don't care. Whenever I see someone posting on JIRA can you please fix this, we need this in out application and nobody is reacting, I feel tempted to jump right in, even if I don't know the component (which adds another entry to the list above). I don't see a way how we can improve this. My feeling is, that we need more committers. But then I have the comments of people I've talked to in my ear: to old school, to difficult to get involved, to slow development process, to unwelcoming community. So what do we do? Do we need help? I'm excited to hear your thoughts :-) yeah, this is a general problem of commons imho. There are too many components for a too small community as most of the original committers have long left. The only way out is to do what we tried a couple of months ago: move not maintained components to dormant, and keep the others alive with the existing people. Just one example: jelly is a nice thing and actually used within jenkins as the backbone html generator. But it is re-packaged within jenkins custom bugfixes as the last jelly release (1.0) was in 2005. Similar things apply for el or primitives. These components are long dead and there are very good alternatives available, so they should be abandoned. Cut off the dead branches to keep the tree alive. Thomas - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter
Re: [TEXT] Problems with the site build
TEXT inherits from commons parent (like BeanUtils2 does) because the sandbox parent pom only adds unnecessary complexity and yet another thing we need to release. I updated BeanUtils2 to commons parent because I wanted to use the new commons skin for example. Since the BeanUtils2 site build works, I think it has nothing to do with the parent pom. I'm trying to deploy the site with mvn clean site-deploy and mvn clean site-deploy -Dmaven.site.deploy.skip=false Thank you, Benedikt 2014-11-29 12:55 GMT+01:00 sebb seb...@gmail.com: TEXT is a Sandbox component, so it should inherit from the Commons-Sandbox POM. That may or may not help, but ought to be done to prevent accidental deployment. What exact commands have you used? On 29 November 2014 at 11:31, Benedikt Ritter brit...@apache.org wrote: Hi all, I've tried to create the site for commons-text but the site build doesn't work. It always prints out maven.site.deploy.skip = true: Skipping site deployment [1]. I've tried to override this via -D but it doesn't work. Can anybody help? TIA! Benedikt [1] https://github.com/apache/maven-plugins/blob/3b34d1bbf0ff0347fce83084ce4670755e1cee7c/maven-site-plugin/src/main/java/org/apache/maven/plugins/site/deploy/AbstractDeployMojo.java#L162 -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter
Re: [TEXT] Problems with the site build
On 30 November 2014 at 18:23, Benedikt Ritter brit...@apache.org wrote: TEXT inherits from commons parent (like BeanUtils2 does) because the sandbox parent pom only adds unnecessary complexity and yet another thing Using the sandbox pom instead of the normal pom does not affect the complexity. we need to release. I updated BeanUtils2 to commons parent because I wanted to use the new commons skin for example. Since the BeanUtils2 site build works, I think it has nothing to do with the parent pom. The sandbox pom was designed for use with sandbox components. If it no longer serves its purpose it should be retired, but using the wrong parent pom may cause problems. I'm trying to deploy the site with mvn clean site-deploy and mvn clean site-deploy -Dmaven.site.deploy.skip=false Does the same problem occur with other components? Are they sandbox or proper? Thank you, Benedikt 2014-11-29 12:55 GMT+01:00 sebb seb...@gmail.com: TEXT is a Sandbox component, so it should inherit from the Commons-Sandbox POM. That may or may not help, but ought to be done to prevent accidental deployment. What exact commands have you used? On 29 November 2014 at 11:31, Benedikt Ritter brit...@apache.org wrote: Hi all, I've tried to create the site for commons-text but the site build doesn't work. It always prints out maven.site.deploy.skip = true: Skipping site deployment [1]. I've tried to override this via -D but it doesn't work. Can anybody help? TIA! Benedikt [1] https://github.com/apache/maven-plugins/blob/3b34d1bbf0ff0347fce83084ce4670755e1cee7c/maven-site-plugin/src/main/java/org/apache/maven/plugins/site/deploy/AbstractDeployMojo.java#L162 -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] Do we need help?
On 2014-11-29, Benedikt Ritter wrote: currently I feel really overwhelmed by the stuff I'd like to do at commons and the little time I can spend for it. As many others have already said, most of us know exactly what you are talking about and IMHO the only solution for you is to not pick too many goals at once. And accept that you are human with a limited amount of time at hand. Doing one thing always means you decide against doing a different thing. I wonder how you feel about this. I have the feeling that a lot of people ask us to fix stuff and release components but we don't really catch up with this. This will give people the feeling that we are slow or we simply don't care. Maybe we are not good at explaining that we need help to fix stuff and more oftne than not the people who experience the problems are best suited to provide said help. I don't see a way how we can improve this. My feeling is, that we need more committers. Right. I'm not sure there is a recipe for this, though. But then I have the comments of people I've talked to in my ear: to old school, to difficult to get involved, to slow development process, to unwelcoming community. So what do we do? Do we need help? If we are perceived as unwelcoming then this is a real problem - and one we need to solve. old school and slow development could easily solved by fresh blood - much more than by anything the old schoolers would do. Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[logging] Commons Logging 2.0?
Hi folks, I am perfectly aware that I was saying CL needs to be deprecated only before month. Tomcat uses CL and that was more or less the reason it would stay - so I thought. Recently I talked to a person actively involved in Spring. He explained, Spring would use CL and they are quite happy with it. Reason: it's always the same. He also told me that - rather having a new JSR with new interfaces which would be difficult to get into the JDK - he would love to have some kind of CL 2.0. To be honest, it made me think and reconsider whatever I have thought or said in the past. I know Mark did say similar things, but maybe it is the power of a direct conversation. I am still unsure if a CL 2.0 would be needed or not and thats why I outreach here to ask for your feelings/opinions whatever. We have a Log4j2 which is really good. We have a slf4j which is fine. And we have a CL 1.x which is, well dated. Would it make sense to have a CL 2.0 which is more or less (maybe with small adjustments, despite the major version jump) a drop in replacement? It could just add some methods or things like variable substitutions, and thats it. Nothing big. Modern JVM support, some more methods. The rest all the same, except log4j 2 support (which is also provided by the log4j project). As mentioned I am still undecided. But CL 2.0 could be a minimal interface for consumers looking for stability instead of tons of features. However a bit more modern taste doesn't hurt, as long as it doesn't break things (too much). Thoughts? Christian - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
RE: [logging] Commons Logging 2.0?
2.0 would mean breaking BC to me. Keep it at 1.x to convey a warm and fuzzy feeling of compatibility. I would keep the changes to a minimum. For anything more I would point to log4j 2. Gary div Original message /divdivFrom: Christian Grobmeier grobme...@gmail.com /divdivDate:11/30/2014 16:27 (GMT-05:00) /divdivTo: Commons Developers List dev@commons.apache.org /divdivCc: /divdivSubject: [logging] Commons Logging 2.0? /divdiv /divHi folks, I am perfectly aware that I was saying CL needs to be deprecated only before month. Tomcat uses CL and that was more or less the reason it would stay - so I thought. Recently I talked to a person actively involved in Spring. He explained, Spring would use CL and they are quite happy with it. Reason: it's always the same. He also told me that - rather having a new JSR with new interfaces which would be difficult to get into the JDK - he would love to have some kind of CL 2.0. To be honest, it made me think and reconsider whatever I have thought or said in the past. I know Mark did say similar things, but maybe it is the power of a direct conversation. I am still unsure if a CL 2.0 would be needed or not and thats why I outreach here to ask for your feelings/opinions whatever. We have a Log4j2 which is really good. We have a slf4j which is fine. And we have a CL 1.x which is, well dated. Would it make sense to have a CL 2.0 which is more or less (maybe with small adjustments, despite the major version jump) a drop in replacement? It could just add some methods or things like variable substitutions, and thats it. Nothing big. Modern JVM support, some more methods. The rest all the same, except log4j 2 support (which is also provided by the log4j project). As mentioned I am still undecided. But CL 2.0 could be a minimal interface for consumers looking for stability instead of tons of features. However a bit more modern taste doesn't hurt, as long as it doesn't break things (too much). Thoughts? Christian - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] Commons Logging 2.0?
On 30 November 2014 at 21:57, Gary Gregory garydgreg...@gmail.com wrote: 2.0 would mean breaking BC to me. Not necessarily. A big jump in minimum Java version might deserve a major version bump. Keep it at 1.x to convey a warm and fuzzy feeling of compatibility. Compatibility is not guaranteed by keeping the same major version number. What's important is whether it really is compatible or not, and that needs to be clearly documented. I would keep the changes to a minimum. Here, I agree. If it ain't broke, don't try and fix it. But it would be interesting to know why the Spring dev thought a new version would be useful. For anything more I would point to log4j 2. Gary div Original message /divdivFrom: Christian Grobmeier grobme...@gmail.com /divdivDate:11/30/2014 16:27 (GMT-05:00) /divdivTo: Commons Developers List dev@commons.apache.org /divdivCc: /divdivSubject: [logging] Commons Logging 2.0? /divdiv /divHi folks, I am perfectly aware that I was saying CL needs to be deprecated only before month. Tomcat uses CL and that was more or less the reason it would stay - so I thought. Recently I talked to a person actively involved in Spring. He explained, Spring would use CL and they are quite happy with it. Reason: it's always the same. He also told me that - rather having a new JSR with new interfaces which would be difficult to get into the JDK - he would love to have some kind of CL 2.0. To be honest, it made me think and reconsider whatever I have thought or said in the past. I know Mark did say similar things, but maybe it is the power of a direct conversation. I am still unsure if a CL 2.0 would be needed or not and thats why I outreach here to ask for your feelings/opinions whatever. We have a Log4j2 which is really good. We have a slf4j which is fine. And we have a CL 1.x which is, well dated. Would it make sense to have a CL 2.0 which is more or less (maybe with small adjustments, despite the major version jump) a drop in replacement? It could just add some methods or things like variable substitutions, and thats it. Nothing big. Modern JVM support, some more methods. The rest all the same, except log4j 2 support (which is also provided by the log4j project). As mentioned I am still undecided. But CL 2.0 could be a minimal interface for consumers looking for stability instead of tons of features. However a bit more modern taste doesn't hurt, as long as it doesn't break things (too much). Thoughts? Christian - 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: [ALL] Do we need help?
Hello Benedikt! I guess I'm being too cautious to commit or work on issues in other components :) I'll slowly start working on [jelly] to port the changes made in Jenkins. But first will spend more time on [text], [functor] and [lang]. Thanks!Bruno From: Benedikt Ritter brit...@apache.org To: Commons Developers List dev@commons.apache.org; Bruno P. Kinoshita brunodepau...@yahoo.com.br Sent: Sunday, November 30, 2014 4:15 PM Subject: Re: [ALL] Do we need help? Hello Bruno 2014-11-30 0:31 GMT+01:00 Bruno P. Kinoshita brunodepau...@yahoo.com.br: Hi Thomas! I use Jelly almost every week in Jenkins plug-ins. Talked about the forked repo they have in the project, and even told them I could spend some hours every week to fix the necessary issues. Even though it is possible to use Groovy in Jenkins views too now, there are so many existing plug-ins (that are used as basis for new plug-ins) that I find it very hard to see jelly removed from Jenkins. Would anyone be interested and have time to push a new release ? I could check what needed to be done in [jelly] and either update or add new issues. Bruno You always seem to be forgetting, that you're commons committer :-) If you feel like working on any component, just drop a mail on the ML and start work ;-) Other people will eventually join you. Benedikt From: Thomas Neidhart thomas.neidh...@gmail.com To: Commons Developers List dev@commons.apache.org Sent: Saturday, November 29, 2014 2:31 PM Subject: Re: [ALL] Do we need help? On 11/29/2014 11:53 AM, Benedikt Ritter wrote: Hi all, currently I feel really overwhelmed by the stuff I'd like to do at commons and the little time I can spend for it. Here is an (incomplete) list of the things I'd like to work on: Hi Benedikt, - get a new release of the build plugin out of the door for auto creating README.md and CONTRIBUTING.md - Work on [VALIDATOR] and get a new release out of the door - Work on [DBUTILS] and get a new release out of the door - Push [lang] 3.4 out of the door - Have a look at [compress] 2.0 - Backport important fixes from [collections] 4.0 to 3.x and create a last service update - work on [text] - help releasing [imaging] 1.0 - Improve docs on how to get involved at commons - Organize a logo contest for commons - ... many more this sounds like you set your goals too high and are frustrated that you don't get all the things done. I guess this is a common scheme for ambitious/passionate people. Try to set more realistic goals and finish them before doing other / more things. Then you will get the positive feedback of achieving something and everything will be better. I wonder how you feel about this. I have the feeling that a lot of people ask us to fix stuff and release components but we don't really catch up with this. This will give people the feeling that we are slow or we simply don't care. Whenever I see someone posting on JIRA can you please fix this, we need this in out application and nobody is reacting, I feel tempted to jump right in, even if I don't know the component (which adds another entry to the list above). I don't see a way how we can improve this. My feeling is, that we need more committers. But then I have the comments of people I've talked to in my ear: to old school, to difficult to get involved, to slow development process, to unwelcoming community. So what do we do? Do we need help? I'm excited to hear your thoughts :-) yeah, this is a general problem of commons imho. There are too many components for a too small community as most of the original committers have long left. The only way out is to do what we tried a couple of months ago: move not maintained components to dormant, and keep the others alive with the existing people. Just one example: jelly is a nice thing and actually used within jenkins as the backbone html generator. But it is re-packaged within jenkins custom bugfixes as the last jelly release (1.0) was in 2005. Similar things apply for el or primitives. These components are long dead and there are very good alternatives available, so they should be abandoned. Cut off the dead branches to keep the tree alive. Thomas - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- http://people.apache.org/~britter/http://www.systemoutprintln.de/http://twitter.com/BenediktRitterhttp://github.com/britter
Re: [TEXT] Problems with the site build
Hi there,
Tried the mvn clean site-deploy, and noticed a similar message.
kinow@chuva:~/java/apache/commons-text$ mvn clean site-deploy -e -XApache Maven
3.2.1 (ea8b2b07643dbb1b84b6d16e1f08391b666bc1e9;
2014-02-14T15:37:52-03:00)Maven home: /opt/apache-maven-3.2.1Java version:
1.7.0_65, vendor: Oracle CorporationJava home: /opt/jdk1.7.0_65/jreDefault
locale: en_US, platform encoding: UTF-8OS name: linux, version:
3.13.0-36-generic, arch: amd64, family: unix
Looking at the commons-parent-35 pom.xml [1], it contains the following comment:
plugin groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-site-plugin/artifactId
version${commons.site-plugin.version}/version configuration
!-- don't deploy site with maven-site-plugin --
skipDeploytrue/skipDeploy /configuration /plugin
So I guess that's why we are are presented with this message.
In another part of the commons-parent pom, it mentions the scm-publish. Maybe
mvn clean scm-publish:publish-scm ? Just my 0.02 cents.HTH,Bruno
[1]
https://svn.apache.org/repos/asf/commons/proper/commons-parent/tags/commons-parent-35/pom.xml
From: Benedikt Ritter brit...@apache.org
To: Commons Developers List dev@commons.apache.org
Sent: Sunday, November 30, 2014 4:23 PM
Subject: Re: [TEXT] Problems with the site build
TEXT inherits from commons parent (like BeanUtils2 does) because the
sandbox parent pom only adds unnecessary complexity and yet another thing
we need to release. I updated BeanUtils2 to commons parent because I wanted
to use the new commons skin for example. Since the BeanUtils2 site build
works, I think it has nothing to do with the parent pom.
I'm trying to deploy the site with
mvn clean site-deploy
and
mvn clean site-deploy -Dmaven.site.deploy.skip=false
Thank you,
Benedikt
2014-11-29 12:55 GMT+01:00 sebb seb...@gmail.com:
TEXT is a Sandbox component, so it should inherit from the Commons-Sandbox
POM.
That may or may not help, but ought to be done to prevent accidental
deployment.
What exact commands have you used?
On 29 November 2014 at 11:31, Benedikt Ritter brit...@apache.org wrote:
Hi all,
I've tried to create the site for commons-text but the site build doesn't
work. It always prints out maven.site.deploy.skip = true: Skipping site
deployment [1]. I've tried to override this via -D but it doesn't work.
Can anybody help?
TIA!
Benedikt
[1]
https://github.com/apache/maven-plugins/blob/3b34d1bbf0ff0347fce83084ce4670755e1cee7c/maven-site-plugin/src/main/java/org/apache/maven/plugins/site/deploy/AbstractDeployMojo.java#L162
--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter
Re: [TEXT] Problems with the site build
The CP35 says:
configuration
!-- don't deploy site with maven-site-plugin --
skipDeploytrue/skipDeploy
...
phasesite-deploy/phase!-- deploy site with
maven-scm-publish-plugin --
Looks like
http://commons.apache.org/site-publish.html
needs updating for the single module component.
On 1 December 2014 at 01:24, Bruno P. Kinoshita
brunodepau...@yahoo.com.br wrote:
Hi there,
Tried the mvn clean site-deploy, and noticed a similar message.
kinow@chuva:~/java/apache/commons-text$ mvn clean site-deploy -e -XApache
Maven 3.2.1 (ea8b2b07643dbb1b84b6d16e1f08391b666bc1e9;
2014-02-14T15:37:52-03:00)Maven home: /opt/apache-maven-3.2.1Java version:
1.7.0_65, vendor: Oracle CorporationJava home: /opt/jdk1.7.0_65/jreDefault
locale: en_US, platform encoding: UTF-8OS name: linux, version:
3.13.0-36-generic, arch: amd64, family: unix
Looking at the commons-parent-35 pom.xml [1], it contains the following
comment:
plugin groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-site-plugin/artifactId
version${commons.site-plugin.version}/version configuration
!-- don't deploy site with maven-site-plugin --
skipDeploytrue/skipDeploy /configuration/plugin
So I guess that's why we are are presented with this message.
In another part of the commons-parent pom, it mentions the scm-publish. Maybe
mvn clean scm-publish:publish-scm ? Just my 0.02 cents.HTH,Bruno
[1]
https://svn.apache.org/repos/asf/commons/proper/commons-parent/tags/commons-parent-35/pom.xml
From: Benedikt Ritter brit...@apache.org
To: Commons Developers List dev@commons.apache.org
Sent: Sunday, November 30, 2014 4:23 PM
Subject: Re: [TEXT] Problems with the site build
TEXT inherits from commons parent (like BeanUtils2 does) because the
sandbox parent pom only adds unnecessary complexity and yet another thing
we need to release. I updated BeanUtils2 to commons parent because I wanted
to use the new commons skin for example. Since the BeanUtils2 site build
works, I think it has nothing to do with the parent pom.
I'm trying to deploy the site with
mvn clean site-deploy
and
mvn clean site-deploy -Dmaven.site.deploy.skip=false
Thank you,
Benedikt
2014-11-29 12:55 GMT+01:00 sebb seb...@gmail.com:
TEXT is a Sandbox component, so it should inherit from the Commons-Sandbox
POM.
That may or may not help, but ought to be done to prevent accidental
deployment.
What exact commands have you used?
On 29 November 2014 at 11:31, Benedikt Ritter brit...@apache.org wrote:
Hi all,
I've tried to create the site for commons-text but the site build doesn't
work. It always prints out maven.site.deploy.skip = true: Skipping site
deployment [1]. I've tried to override this via -D but it doesn't work.
Can anybody help?
TIA!
Benedikt
[1]
https://github.com/apache/maven-plugins/blob/3b34d1bbf0ff0347fce83084ce4670755e1cee7c/maven-site-plugin/src/main/java/org/apache/maven/plugins/site/deploy/AbstractDeployMojo.java#L162
--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] Do we need help?
Whenever I've felt like there is too much work and too little people to do it, I remind myself Apache is not a job (unless someone is paying you for your work), but a volunteer organization. Everyone does what he/she wants to do... and if it's not personally fun or interesting, those people will move on. The same with you, too. Enjoy participating and don't get overwhelmed with any expectations, because there are no expectations put on you. Cheers, Paul On Sun, Nov 30, 2014 at 6:42 PM, Bruno P. Kinoshita brunodepau...@yahoo.com.br wrote: Hello Benedikt! I guess I'm being too cautious to commit or work on issues in other components :) I'll slowly start working on [jelly] to port the changes made in Jenkins. But first will spend more time on [text], [functor] and [lang]. Thanks!Bruno From: Benedikt Ritter brit...@apache.org To: Commons Developers List dev@commons.apache.org; Bruno P. Kinoshita brunodepau...@yahoo.com.br Sent: Sunday, November 30, 2014 4:15 PM Subject: Re: [ALL] Do we need help? Hello Bruno 2014-11-30 0:31 GMT+01:00 Bruno P. Kinoshita brunodepau...@yahoo.com.br: Hi Thomas! I use Jelly almost every week in Jenkins plug-ins. Talked about the forked repo they have in the project, and even told them I could spend some hours every week to fix the necessary issues. Even though it is possible to use Groovy in Jenkins views too now, there are so many existing plug-ins (that are used as basis for new plug-ins) that I find it very hard to see jelly removed from Jenkins. Would anyone be interested and have time to push a new release ? I could check what needed to be done in [jelly] and either update or add new issues. Bruno You always seem to be forgetting, that you're commons committer :-) If you feel like working on any component, just drop a mail on the ML and start work ;-) Other people will eventually join you. Benedikt From: Thomas Neidhart thomas.neidh...@gmail.com To: Commons Developers List dev@commons.apache.org Sent: Saturday, November 29, 2014 2:31 PM Subject: Re: [ALL] Do we need help? On 11/29/2014 11:53 AM, Benedikt Ritter wrote: Hi all, currently I feel really overwhelmed by the stuff I'd like to do at commons and the little time I can spend for it. Here is an (incomplete) list of the things I'd like to work on: Hi Benedikt, - get a new release of the build plugin out of the door for auto creating README.md and CONTRIBUTING.md - Work on [VALIDATOR] and get a new release out of the door - Work on [DBUTILS] and get a new release out of the door - Push [lang] 3.4 out of the door - Have a look at [compress] 2.0 - Backport important fixes from [collections] 4.0 to 3.x and create a last service update - work on [text] - help releasing [imaging] 1.0 - Improve docs on how to get involved at commons - Organize a logo contest for commons - ... many more this sounds like you set your goals too high and are frustrated that you don't get all the things done. I guess this is a common scheme for ambitious/passionate people. Try to set more realistic goals and finish them before doing other / more things. Then you will get the positive feedback of achieving something and everything will be better. I wonder how you feel about this. I have the feeling that a lot of people ask us to fix stuff and release components but we don't really catch up with this. This will give people the feeling that we are slow or we simply don't care. Whenever I see someone posting on JIRA can you please fix this, we need this in out application and nobody is reacting, I feel tempted to jump right in, even if I don't know the component (which adds another entry to the list above). I don't see a way how we can improve this. My feeling is, that we need more committers. But then I have the comments of people I've talked to in my ear: to old school, to difficult to get involved, to slow development process, to unwelcoming community. So what do we do? Do we need help? I'm excited to hear your thoughts :-) yeah, this is a general problem of commons imho. There are too many components for a too small community as most of the original committers have long left. The only way out is to do what we tried a couple of months ago: move not maintained components to dormant, and keep the others alive with the existing people. Just one example: jelly is a nice thing and actually used within jenkins as the backbone html generator. But it is re-packaged within jenkins custom bugfixes as the last jelly release (1.0) was in 2005. Similar things apply for el or primitives. These components are long dead and there are very good alternatives available, so they should be abandoned. Cut off the dead branches to keep the tree alive. Thomas - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional
[VFS] VFS sandbox?
Hello all! I'm writing a program that uses the VFS (2.0) so I could manage SFTP and samba connections. When I try to reach smb server I get FileSystemException - Badly formed uri I understand that I have to import the sandbox jar, but do I get it from?
