Re: Welcome back Henri Biestro to the PMC
Hi Henri, Glad to see you back Siegfried Goeschl > On 13.06.2021, at 15:51, Gary Gregory wrote: > > Let's welcome back Henri Biestro to the PMC. > > Gary - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [exec][email] Java 7 to 8
Hi folks, I probably missed most of the fun here (overworked) but IMHO it makes sense to update both projects to JDK 8 A related question - someone volunteering as release manager? Having said that I can lend a hand for the code changes :) Thanks in advance Siegfried Goeschl > On 29.03.2021, at 02:38, Matt Sicker wrote: > > Calling it technical debt is pretty useful, too, because just like > monetary debt, it can be useful to accumulate some in the short term > for productive reasons, but if you don't pay it off and manage it > properly, the interest payments begin to dominate expenses. Interest > on technical debt comes in the form of what would normally be a five > minute effort taking five months and three separate line managers to > sign off on the budget to have it maybe deployed to production after > the last 20 fires have been sufficiently extinguished. :) > > On Sun, 28 Mar 2021 at 17:09, Gary Gregory wrote: >> >> WRT rant: >> We call that "technical debt" and to move the needle on that developers are >> (sometimes or always depending on you company) asked to explain the >> "business value" for spending the time (IOW the money) to do so. At which >> point said developers roll their eyes, pull their remaining hair out, or >> both, before being asked to go another "death march"... >> >> Gary >> >> >> On Sun, Mar 28, 2021, 16:18 Thomas Schapitz wrote: >> >>>> If they are still on Java 6 or 7, then updating libraries might not be a >>>> priority. >>>> >>>> Gary >>> >>> >>> I second that. >>> >>> If an organization is still reluctant to upgrade at least to JDK 8, its >>> rather unlikely that the same organization is urgently requiring to update >>> to any latest commons release. >>> >>> And if they do in fact urgently require functionality, that is only >>> available in a commons lib requiring JDK 8, it would be a nice incentive >>> for finally considering an to upgrade at least to JDK 8. >>> >>> To me, Apache, especially commons, does a terrific job guarding BC, but in >>> the end, trying to keep this up for the eternity will overstretch the >>> communities resources, and it is breaking the stride. >>> >>> On a more personal note: being 20+ years in the industry, I'm really >>> fed up with organizations wanting me to build the newest, shiniest, >>> fanciest crystal palaces of applications, while at the same time >>> restricting me to use the tools from the stone age to achieve that, just >>> because some oaf up there needs the money to upgrade the gadgets in his >>> super yacht. You know, there is something wrong, when the model of the >>> CEO's car is changing more frequently than the versions of your tools. >>> >>> Basically, an organization showing this behaviour is dumping their >>> leniency as a debt into the community, so complaints about that shouldn't >>> be taken too serious. >>> >>> >>> >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [email and vfs] about adding class FileObjectDataSource
Hi, I do not fully understand the problem - AFAIK there is an attach method which takes a DataSource sou can just pass your FileObjectDataSource? But I guess I miss something here :-) Thanks in advance, Siegfried Goeschl > On 27.05.2020, at 11:30, Xeno Amess wrote: > > Hi. > I'm trying to maintain commons-email today, and I want to make a new class > FileObjectDataSource, who implements javax.activation.DataSource. > But things is not as easy as I want. > 1. the reason. > the reason for making such a class is when last month I was doing some > school work for graduation project, and in that system I need a backend > server to send emails. > And I want to attach some FileObject (from vfs) as attachments of the > emails sent, so I have to make a class FileObjectDataSource (something > which is actually very similar to javax.activation.FileDataSource but > dealing not File but FileObject). > then I thought this class might be helpful to others, so I want to put it > into some place. > the question is, where shall I put it? commons-email, or commons-vfs? > 2. commons-email. > start with commons-email. > If I make such a class into commons-email, then commons-email must add > commons-vfs as a dependency. > which sounds crazy to implement so small a feature to include a large new > dependency. > 3. commons-vfs > If I make such a class into commons-vfs, then some worse things might > happen. > First, the javax.activation.DataSource is actually deleted since jdk11, and > commons-email use [jakarta.mail] for Infrastructure, whitch contains a copy > of javax.activation.DataSource. > So commons-vfs must make [jakarta.mail] as a dependency. > which sounds crazy to implement so small a feature to include a large new > dependency. > Second, [jakarta.mail] is actually 2.0rc now, and they claimed they would > release 2.0 soon. > and in jakarta2.0, all uses of javax.activation.DataSource will be > replaced by jakarta.activation.DataSource. > Also, it is not actually related to vfs itself, but only a usage of vfs, so > I don't think it good to be added to vfs. > 4. so maybe I should make another repo for storing such a class? > man, starting a repo for a single class sounds crazy. > 5. any better ideas? - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[email] Preparing Commons Email Release 1.5 ...
Hi folks, I think is is time to get a commons-email-1.5 out of the door - any objection to start a release Thanks in advance, Siegfried Goeschl - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Time is running out....CFP submission deadline is Feb 12th
Hi folks, I made my proposal for “Apache Commons Email & Exec” today :-) Cheers, Siegfried Goeschl > On 05 Feb 2016, at 18:24, Melissa Warnkin wrote: > > Want to go to the beautiful city of Vancouver, BC? > > enjoy the evening receptions with the delicious (free) food and great > (free) drinks? did I mention FREE food and drinks??!! > > .mingle with your peers and engage in some awesome geek talk? > > Then get your talk proposal in now because the deadline of February 12th is > quickly approaching!! > > The CFP for ApacheCon Big Data is here: > > http://events.linuxfoundation.org/events/apache-big-data-north-america > <http://events.linuxfoundation.org/events/apache-big-data-north-america> > > The CFP for ApacheCon Core is here: > > http://events.linuxfoundation.org/events/apachecon-north-america > <http://events.linuxfoundation.org/events/apachecon-north-america> > > > If you want to run an abstract by someone for content, grammar, or anything > else, please feel free to ask on d...@community.apache.org > <mailto:d...@community.apache.org> where someone will be delighted to help. > > If you want to discuss any aspect of the conference, there's usually someone > on #apachecon on the Freenode IRC network who can answer your questions. > > I look forward to seeing all of you in Vancouver! > > Have a great day! > > ~Melissa > on behalf of the ApacheCon Team
Re: Anyone for Apache Commons & Apache Con Core 2016 CFP?!
Hi Sergio, the is no “backup just in case” :-) IMHO we all just apply regularly and send a note to the conference planning team, that there is a bunch of Apache Commons talks which should be scheduled together Cheers, Siegfried Goeschl > On 29 Jan 2016, at 14:01, Sergio Fernández wrote: > > On Fri, Jan 29, 2016 at 12:59 PM, Siegfried Göschl < > siegfried.goes...@it20one.com> wrote: >> >> there are no "best" persons to make a presentation :-) >> > > Well, meritocracy does not say no... ;-) > > Anyway, I understand your points, so keep me as backup just in case > (although by today I can't warranty 100% I'm attending). > > > -- > Sergio Fernández > Partner Technology Manager > Redlink GmbH > m: +43 6602747925 > e: sergio.fernan...@redlink.co > w: http://redlink.co - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Anyone for Apache Commons & Apache Con Core 2016 CFP?!
Hi folks, anyone out who would volunteer for a presentation at Apache Con Core - I miss a little bit of enthusiasm :-) We have volunteers/proposals for * commons-exec * commons-email * commons-pool * commons-dbcp For the less enthusiastic among us - don’t worry - we have done this before - we assigned two presentation for a 45 slot to avoid boring the audience to death. In other words * You could present your favourite Apache Commons project for 20 minutes * You could participate as speaker which is a completely different experience than being a visitor - I still have my very first speaker badge at home :-) * You could improve you CV (assuming that it is not already 10 pages long) * You could give yourself a nice journey to lovely Vancouver Cheers, Siegfried Goeschl PS: Please keep in mind this is not a wildcard to present at ApacheCon - each presentation needs still be accepted but chance are a lot better if we team up :-) - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Accept Naomi
Hi Uwe, I would not say commonly used but this is an option for smaller projects to find a home - and Apache Commons Sandbox IS the incubator of Apache Commons. To make the things clearer * checkout commons-email or commons-exec (Disclaimer - I contributed to both projects) * commons-email actually stems from Apache Turbine and was probably promoted to a regular component quickly * commons-exec was a dormant in the sandbox for some time before there was enough activity to justify a regular Apache Commons component * both can be considered useful but there are not sexy (actually you could call them outright boring), have little code and get an occasionally a release * as Apache Commons committer you have a SVN karma for all components Cheers, Siegfried Goeschl > On 31 Oct 2015, at 11:35, Uwe Barthel wrote: > > Hi Siegfried, > > Thanks for your clarification. > > It's really commonly use to bypass the incubator for small projects to become > Apache Commons subproject status? > > I’m a contributor and not deeply involved to assimilate new projects in ASF. > Thats is, why I vote with zero. > > mit freundlichen Grüßen > Uwe Barthel > -- > bart...@x-reizend.de > > >> On 31 Oct 2015, at 11:01, Siegfried Goeschl >> wrote: >> >> Hi Uwe, >> >> for such small components Apache incubator is sort of overkill - setup can >> be daunting and Naomi is unlikely to attract a large community. That’s the >> reason why small potential ASF projects are looking for an umbrella project >> and Apache Commons is designed to be such an umbrella project - AFAIK every >> ASF committer has commit rights on sandbox components (anyone out there who >> knows that for sure) >> >> In other words - if Naomi becomes ASF it should be Apache Commons >> >> Cheers, >> >> Siegfried Goeschl >> >> >>> On 31 Oct 2015, at 10:28, Uwe Barthel wrote: >>> >>> [x] -0 OK, but… >>> >>> … on going over Incubator instead. >>> It gives the chance to grow up a community and re-invite the code and >>> documentation. >>> >>> I’m with Benedikt pointing to the rock-star-thing and people behind the ASF. >>> Why not use the Incubator as described by the ASF[1]? >>> >>> [1] http://www.apache.org/foundation/how-it-works.html#incubator >>> >>> mit freundlichen Grüßen >>> Uwe Barthel >>> -- >>> bart...@x-reizend.de >>> >>> >>>> On 30 Oct 2015, at 01:42, Phil Steitz wrote: >>>> >>>> This is a VOTE to accept the code discussed in [1] and available for >>>> review using the git commands below. All are welcome to vote, votes >>>> from PMC members are binding. Assuming a positive vote, we will >>>> execute a software grant with the authors and use the code as the >>>> basis for a new Commons Sandbox component. >>>> >>>> This VOTE will close in 72 hours. More discussion on the code and >>>> its fit in Commons is always welcome, but please do not reply to >>>> this thread with discussion, other than embedded justification for >>>> negative VOTES. Use the thread from [1] instead. >>>> >>>> Git commands to grab the code: >>>> >>>> git clone g...@github.com:NormanShapiro/Naomi.git >>>> git checkout gh-pages >>>> >>>> Thanks! >>>> >>>> Phil >>>> [1] http://markmail.org/message/imoi5aipf63f7rsa >>>> >>>> [ ] +1 Yes! >>>> [ ] +0 OK... >>>> [ ] -0 OK, but... >>>> [ ] -1 We should not do this, because... >>>> >>>> >>>> - >>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>> >>> >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Accept Naomi
Hi Uwe, for such small components Apache incubator is sort of overkill - setup can be daunting and Naomi is unlikely to attract a large community. That’s the reason why small potential ASF projects are looking for an umbrella project and Apache Commons is designed to be such an umbrella project - AFAIK every ASF committer has commit rights on sandbox components (anyone out there who knows that for sure) In other words - if Naomi becomes ASF it should be Apache Commons Cheers, Siegfried Goeschl > On 31 Oct 2015, at 10:28, Uwe Barthel wrote: > > [x] -0 OK, but… > > … on going over Incubator instead. > It gives the chance to grow up a community and re-invite the code and > documentation. > > I’m with Benedikt pointing to the rock-star-thing and people behind the ASF. > Why not use the Incubator as described by the ASF[1]? > > [1] http://www.apache.org/foundation/how-it-works.html#incubator > > mit freundlichen Grüßen > Uwe Barthel > -- > bart...@x-reizend.de > > >> On 30 Oct 2015, at 01:42, Phil Steitz wrote: >> >> This is a VOTE to accept the code discussed in [1] and available for >> review using the git commands below. All are welcome to vote, votes >> from PMC members are binding. Assuming a positive vote, we will >> execute a software grant with the authors and use the code as the >> basis for a new Commons Sandbox component. >> >> This VOTE will close in 72 hours. More discussion on the code and >> its fit in Commons is always welcome, but please do not reply to >> this thread with discussion, other than embedded justification for >> negative VOTES. Use the thread from [1] instead. >> >> Git commands to grab the code: >> >> git clone g...@github.com:NormanShapiro/Naomi.git >> git checkout gh-pages >> >> Thanks! >> >> Phil >> [1] http://markmail.org/message/imoi5aipf63f7rsa >> >> [ ] +1 Yes! >> [ ] +0 OK... >> [ ] -0 OK, but... >> [ ] -1 We should not do this, because... >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Proposed Contribution to Apache Commons,
Hi folks, I basically agree here with Bernd * the project needs clean-up * I think the idea is worthwhile * having something similar to “grok” as a stand-alone package together with a programmatic approach to build regexp could be the way to go * there is no community around so I think GitHub is currently a better place to see the project mature So I’m -0 for adding the project in its current state to Commons Sandbox Cheers, Siegfried Goeschl > On 26 Oct 2015, at 00:12, Gary Gregory wrote: > > On Sun, Oct 25, 2015 at 4:10 PM, Bernd Eckenfels > wrote: > >> Am Sun, 25 Oct 2015 15:58:28 -0700 >> schrieb Phil Steitz : >> >>> On 10/25/15 3:53 PM, Gary Gregory wrote: >>>> Let's see, would we run this through the Apache Incubator or could >>>> we simply run it through our Commons Sandbox and then up to Commons >>>> itself? >>> I think we can just start in the sandbox, following the Incubator IP >>> clearance process as we have done before. I volunteered above to >>> manage the IP clearance process and VOTE to accept. It seems like >>> there is some interest here in working on it, so that qualifies for >>> the Sandbox, IMO. >> >> I think the project is in a pretty bad shape. I would prefer to wait >> till it is overhauled and mavenized (I did not understand the >> merge into ghpages, if this can be renamed to master and fix the broken >> links in the README, that would be a start. I still havent seen any >> sample of the Naomi syntax/power...) >> >> And from my POV that would be a precondition to see some commitment of >> the original submitters. Why would we rush things? >> > > It seems OK to put Naomi in the Sandbox and then let anyone hack on making > it Mavenized, Common-ized and so on. Then we can all see and play with it > better it would seem to me. > > Gary > > >> >> Gruss >> Bernd >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > > > -- > 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 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Proposed Contribution to Apache Commons,
Hi Norman & Jeff, I skimmed through the email conversation …. * Personally I really like the idea that retired computer scientists turn to Open Source :-) * Looking at the GitHub project I indeed see a cultural gap which needs be closed to do meaningful Open Source work * I try to ignore the fact that you are well-regarded computer scientist and I’m an unknown software developer :-) Having said that * no matter if you are joining Apache Commons or just live on GitHub - you need a good introduction to the project (think of unique selling point). Sit down and write a cool Markdown document to get people enthusiastic - only enthusiastic people will use your contributions and maybe participate later on. * there is a GitHub pull request out there from Dave Brosius - if you are unhappy about it please comment it otherwise merge it with your repo. Ignoring a pull request might be considered impolite :-) * you need to clean up the project - Maven build (I assume mostly done by Dave Brosius), separate test folder, javadoc, site documentation and code style - and this will take some (all, a lot of ) time and could/will be frustrating since the bar is quite high at Apache Commons (and many other FOSS communities). Cheers, Siegfried Goeschl > On 24 Oct 2015, at 17:14, n...@dad.org wrote: > > My colleague, Jeff Rothenberg, and I are retired computer scientists and are > no strangers to regular expression theory and practice. Both of us have used > regular expressions for decades and have taught many other programmers how to > use them. Stephen Kleene (https://en.wikipedia.org/wiki/Stephen_Cole_Kleene), > the inventor of regular expressions and I > (https://en.wikipedia.org/wiki/Norman_Shapiro) were both doctoral students of > Alonzo Church (https://en.wikipedia.org/wiki/Alonzo_Church). Rothenberg used > SNOBOL3 and SNOBOL4 (more powerful than all but a few of the most recent > versions of regular expressions) extensively in his graduate work in > Artificial Intelligence in the late 1960 and early 1970s. > > In our experience, although skilled programmers can write regular expressions > that solve a wide range of problems, for all but the simplest tasks regular > expressions quickly become "write only". That is, once they have aged for a > while, no one other than their authors (and, in our experience, often not even > they) can understand them well enough to verify, modify, debug, or maintain > them without considerable effort. Analogous low-level programming formalisms, > such as machine code and assembly language, have been replaced by > higher-level, more readable and modular languages to produce programs that > have proven easier and more cost-effective to debug, verify, maintain, reuse, > and extend. > > In a similar fashion, Naomi is a means of "taming" complex regular > expressions, as well as offering an easier alternative for those who are > unfamiliar with them. Naomi makes pattern matching programs more readable, > modular, and therefore verifiable, maintainable, and extensible. Naomi > ultimately generates regular expressions, and it can do everything they can > do, but it provides a higher-level API that uses object-oriented constructs to > define complex, modular, parameterized patterns and subpatterns. > > Naomi's advantages over bare regular expressions become apparent only for > larger scale pattern matching tasks. Whereas regular expressions are highly > compact and terse, this virtue becomes a vice for complex patterns. Coupled > with the extensive use of metacharacters and escape sequences, this makes even > moderately complex regular expressions effectively unreadable for all but the > most experienced and practiced regular expression programmers. Newer features > that go beyond the original regular expression formalism--such as namable > groups, built-in names for common character classes, comments, and free white > space--make regular expressions less terse. But their use is not enough to > render complex regular expressions easily readable. These extensions are > analogous to replacing binary machine language by assembly language coding. It > is only necessary to consider a complex problem--such as that of parsing the > e-mail date-time specification of RFC 2822 in src/DateTime.java--to appreciate > the obscurity of regular expressions and to understand Naomi's advantages. > > > >Norman Shapiro > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Math] Utilitzation of SLF4J?
Hi folks, as far as I understand the mail thread (while not being a Commons Math developer) * logging could be helpful but it could be argued/reasoned that logging is not required for an utility package * there is no perfect logging framework for all use-cases and deployments * Apache Commons strive for minimal dependencies One thing I did in the past is to add a dummy singleton logger implementation which can be replaced by the user of the library * The dummy implementation will do nothing * Adding another level of indirection will not win a software engineering award * Having a singleton could be an issue if multiple parties within the deployed application is using Commons Math * Replacing the dummy logging stub with you logging framework of choice is a bit tedious In other words - it is not beautiful implementation but could be reasonable work-around to make our two camps happy (or both unhappy) Cheers, Siegfried Goeschl > On 27 Sep 2015, at 04:05, Romain Manni-Bucau wrote: > > Le 26 sept. 2015 15:19, "Ralph Goers" a écrit : >> >> Romain, >> >> Choosing JUL for a framework does a HUGE disservice to the users of your > framework. JUL is by far the worst logging framework design of anything you > could choose. It is like the JDK designers purposely chose to use a > mechanism to map their API to another implementation that really doesn’t > work. SLF4J handles this by not bypassing it and using a JUL handler to > map everything into it, and then uses an “interesting” scheme to try to > make that perform well. Log4j tries to use the method documented by JUL but > it has a few problems. >> > > It is contextual, slf4j with its classloader handling is the worse for > other users...all analyzis lead to a really "common" lib shouldnt rely on > any logging API IMHO. > >> Ralph >> >>> On Sep 26, 2015, at 12:49 PM, Romain Manni-Bucau > wrote: >>> >>> Le 26 sept. 2015 12:07, "Luc Maisonobe" l...@spaceroots.org>> a écrit : >>>> >>>> Le 26/09/2015 20:59, Ralph Goers a écrit : >>>>> I don’t normally participate in Math but I do feel the need to stick > my >>> nose in here. >>>>> 1. You are absolutely correct to determine whether you need logging at >>> all before discussing what to choose. >>>>> 2. If you do decide logging is required: >>>>> a. Please stay away from java.util.logging. It really would be the >>> best solution for a framework like math except it is extremely > difficult to >>> redirect efficiently to some other logging framework. The methods used > by >>> SLF4J and Log4j are imperfect to say the least. >>>>> b. Log4j 1.x has reached eol. It effectively has not been supported >>> for 5 years. >>>>> c. Log4j 2 has an API that can be redirected to another logging >>> framework if desired. >>>>> d. Commons logging still works but its API is very primitive by >>> todays standards. That said, it does work. >>>> >>>> From what I have seen, if I ever were to choose a logging framework for >>>> any project, I agree log4j 2 is currently the best choice. I was >>>> impressed by slf4j a few years ago, but think now the step further is >>>> log4j 2 (without any accurate reason, just a rough feeling). >>>> >>> >>> And in 2 years foolog4j will be better. JUL is not perfect for sure but >>> ensures: >>> - no dep >>> - always usable >>> - allows to let the user integrate with the lib without having to fork > it >>> to get rid of a logging dep - think to tomee which consumes N commons > deps, >>> if all uses a different logging framework it is worse to configure and >>> highly inconsistent - that is why we chose jul by default >>> >>> That is for the logging framework choice. >>> Now commons shouldnt log much IMO otherwise it would start to loose > commons >>> in sense of shareable component cause of the integration issues it >>> generates in the final application. >>> >>> - Romain >>> >>>> best regards, >>>> Luc >>>> >>>>> >>>>> Ralph >>>>> >>>>> >>>>>> On Sep 26, 2015, at 10:07 AM, Luc Maisonobe > wrote: >>>>>> >>>>>> Le 26/09/2015 18:42, Gilles a écrit : >>>>>>> On Sat, 26 Sep 2015 09:03:06 -0700, Phil Steitz wrote: >>>>>>>> On 9/26/15 4:56 AM, Thomas Neidhart wrote: >>>>>>>
Re: [VOTE] Move COMPRESS to git
+1 (Non-binding) Siegfried Goeschl > On 22 Aug 2015, at 21:29, Stefan Bodewig wrote: > > Hi all > > more thann half a year ago I promised to call for a vote for migrating > to git as soon as 1.10 has been released. Well that took longer than > expected :-) > > Anyway, here is the vote: > > +1 Move to git > -1 Stick with svn > > vote will be open for 72 hours > > Cheers > >Stefan > > - > 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: how to refine programming skill
Hi Daniel, IMHO the best approach is picking an Apache Commons (or any other OSS) project you have a special interest in, e.g. you are using it at work or have implemented something similar and would like to improve it a bit. The improvement could be documentation, answering emails, a bug fix or a new feature :-) What I usually do - pick the project of my choice - build the project and have a close look at the tests - subscribe to the user & developer mailing list & JIRA - read the stuff on the mailing list to get a better understanding - fix a simple bug or improve the user documentation - answer incoming question on the mailing list - after a while I have a good understanding of the project and the developer community But again - working on an arbitrary OSS project (just to refine my skills) does not work for me since I have to have a good reason to spent my time. So over the time I move from one project to another one ... Cheers, Siegfried Goeschl > On 10 Jul 2015, at 13:35, Daniel C. S. Yeh wrote: > > Dear all, > > I am newer here. I want to involve in open source project development. > > By this way, I can see the good software architecture and bugs fixing > practice. > > could anyone kind tell me how to do it step by step, slowly? > > Many thanks > Daniel - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [jelly] Working on some old issues
Go for it :-) Siegfried Goeschl > On 01 May 2015, at 12:00, Benedikt Ritter wrote: > > 2015-05-01 10:22 GMT+02:00 Bruno P. Kinoshita : > >> Hi all, >> Since I joined Commons I've had a special interest in [jelly] due to its >> importance in the Jenkins project. >> >> Jenkins uses a patched version of [jelly]. Kohsuke, creator of Jenkins, >> is/was a Commons committer too, and submitted some issues. I intend to >> investigate if that'd be doable fix the issues to a point that Jenkins can >> drop the patched version, and [jelly] can be updated and released again. >> >> Any objections? >> > > I would love to see this kind of inter-project collaboration happen. Please > go ahead! > > >> Bruno >> >> > > > -- > 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: [PROPOSAL] Create new sandbox component "Commons Crypto"
Hi folks, sounds good to me * it would be appreciated to have no additional dependencies, e.g. BC library mismatch can be painful * one point to keep in mind is https://www.apache.org/dev/crypto.html <https://www.apache.org/dev/crypto.html> * I wrote some crypto-related code over the years so I won’t be a big help but I’m interested in the project * I fully agree with the documentation aspect - crypto is somehow self-defending :-) Cheers, Siegfried Goeschl > On 02 Apr 2015, at 23:34, Phil Steitz wrote: > > On 4/2/15 1:47 PM, Duncan Jones wrote: >> On 18 March 2015 at 15:47, Phil Steitz wrote: >>> On 3/18/15 5:57 AM, Duncan Jones wrote: >>>> Hi everyone, >>>> >>>> I would like to begin work on a new sandbox component, Commons Crypto, >>>> that makes it easier for developers to use crypto from the standard >>>> Java libraries. The component would have two goals: 1) To make it >>>> harder for users to make typical crypto errors, 2) To make it easier >>>> to perform common crypto tasks. Some select examples are below: >>>> >>>> Typical errors to avoid: >>>> - Weak conversion of passwords to keys. >>>> - Specifying algorithms that rely on system defaults. >>>> - Bad conversions of ciphertext to strings. >>>> - Encryption/decryption of strings without charsets. >>>> >>>> Common tasks that could be easier: >>>> - Specifying typical algorithms without figuring out >>>> "AES/CBC/PKCS5Padding". >>>> - Working with X.509 certificates >>>> - Generating keys (particularly using password derivation). >>>> >>>> The scope of this library would be limited to the most commonly used >>>> algorithms, key sizes, etc. The goal is to satisfy 80-90% of potential >>>> use cases with a really well documented, compact library. Given that >>>> crypto is confusing to many, documentation will be exceptionally >>>> verbose. >>>> >>>> Two existing open-source libraries might spring to mind when >>>> considering this proposal: BouncyCastle [1] is a well-known crypto >>>> library with a Java implementation. However, this has different goals, >>>> namely to implement actual crypto algorithms. Commons Crypto, by >>>> contrast, is focussed on working with existing JDK implementations. >>>> JASYPT [2] is another library aimed at simplifying use of encryption, >>>> yet in my mind it goes too far, focussing only on password-based >>>> encryption, with limited control over how that's carried out. >>>> >>>> If no-one objects, I'll begin work on this component, asking the Infra >>>> team to create a new Git repository. Before committing any code, I'll >>>> follow the instructions at [3] to ensure this project is compliant >>>> with US Export Control Laws. >>>> >>>> Comments, thoughts and objections very welcome. >>>> >>>> Kind regards, >>>> >>>> Duncan >>>> >>>> >>>> [1] https://www.bouncycastle.org/java.html >>>> [2] http://www.jasypt.org/ >>>> [3] http://www.apache.org/dev/crypto.html >>> +1 to the idea. Fits nicely into Commons, IMO. Also have a look >>> and maybe see if collaboration might be possible with Apache Shiro, >>> which has a nice embedded, separately packaged crypto lib with sort >>> of the same flavor as what you are describing (though probably more >>> low-level). And have a look at the already existing, but more >>> limited scope (and really just BC wrapper) OpenPGP already in the >>> sandbox. >> Thanks for pointing out Apache Shiro - this seems quite interesting; >> not sure how I missed it. They are certainly aiming to achieve similar >> goals with their Cryptography component [1]. >> >> Perhaps it might be better for me to contribute to that project >> instead. I need to get stuck into their API a little more deeply to >> see what's available versus my concept for Commons Crypto. >> >> Sorry for long delay in response, my mail filters are too aggressive >> and I thought nobody had responded! >> >> Duncan >> >> [1] http://shiro.apache.org/cryptography-features.html > > Of course you - and they - are welcome to carve the Shiro crypto lib > out and move it here. That's how some of our current components > were born. > > Phil >> >>> Phil >>>> - >>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>> >>>> >>> >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >> - >> 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: [logging] Commons Logging 2.0?
Hi Christian, one of those unlikely users of Avalon is the Turbine framework but I can lend a hand with AvalonLogger :-) Cheers, Siegfried Goeschl > On 01 Dec 2014, at 19:17, Christian Grobmeier wrote: > > On Mon, Dec 1, 2014, at 18:04, sebb wrote: >> On 1 December 2014 at 09:28, Christian Grobmeier >> wrote: >>> That aside, I would do the following: >>> >>> - jdk support for at least >7 (varargs need 5, but MessageFormat 7) > > Just saw MessageFormat is even available in jdk 5. So I would opt for > this one. > >> -1 if this means that CL no longer works on earlier versions of Java. > > -1? haha come on, what versions would you like to support? :) Jdk 1.3 is > dead. And 1.4.2 is dead too. We speak of a CL 2.0 version, it must be > allowed to work with more recent jdks. I can't even install that old > versions on my mac. If you want to block any innovation then keep that > approach of supporting 1.3. > > Spring needs Java 6, unarchived Tomcat versions require Java >5. > We can discuss Java 5, but I am definitely not doing anything when I > need to install a vm to test with 1.3. > >>> - remove AvalonLogger and LogKitLogger >> >> Why? >> >> AFAIK they just work, so why drop them? > > Why keeping them? The frameworks are dead for ages, it's unlikely users > of Avalon might ever tend to upgrade to CL 2.0. Of course, if you would > implement these methods for that frameworks, you are welcome. > > You need touch them to implement the new logging methods. > > Cheers > Christian > >> >>> >>>> >>>>> For anything more I would point to log4j 2. >>>>> >>>>> Gary >>>>> >>>>> Original message From: Christian >>>>> Grobmeier Date:11/30/2014 16:27 >>>>> (GMT-05:00) To: Commons Developers List >>>>> Cc: Subject: [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 >>>>> >>>> >>>> - >>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>> >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[OT] Java Image Processing Survival Guide - Re: [imaging] - Release Date and Production Suitability?
Hi Josh, this message is a little bit off-topic (since it promotes some of my work which is not directly related to Apache Commons Imaging) but you might check out * https://github.com/sgoeschl/java-image-processing-survival-guide/tree/master/paper <https://github.com/sgoeschl/java-image-processing-survival-guide/tree/master/paper> * https://github.com/sgoeschl/java-image-processing-survival-guide/raw/master/slides/jipsg.pdf <https://github.com/sgoeschl/java-image-processing-survival-guide/raw/master/slides/jipsg.pdf> * https://github.com/sgoeschl/java-image-processing-survival-guide/tree/master/code/jipsg For two customer projects I converted millions of images using Apache Commons Imaging, Apache PDFBox, ImageIO, JAI & TwelveMonkeys and wrote a paper & presentation including sample code to compare the various image processing libraries. Depending on the scale of image processing you might experience a few of my problems and there are better things in life than tracing image conversion problems :-) Cheers, Siegfried Goeschl > On 18 Nov 2014, at 20:36, Mickley, Joshua R (Genworth) > wrote: > > Greetings All, > > I am evaluating the use of Commons Imaging for a project involving image > conversion and manipulation. > > My question is around a timeline for an official release of Commons Imaging > and suitability for use in a Production environment. > > I am currently using the SNAPSHOT version and am curious what bits of > functionality are needed prior to releasing the code. The unit testing I > have achieved to date gives me a good impression but I wanted to inquire and > gain some additional insight. > > Let me know if there are any specific areas where I can help contribute. > > Thanks! > -Josh
Re: [VOTE] Release Commons Exec 1.1-RC1
Hi Gary, I think there is a copy & pasta error mixing up Commons Exec & Commons CSV :-) Cheers, Siegfried Goeschl > On 17 Nov 2014, at 03:54, Gary Gregory wrote: > > Hello All: > > This is a VOTE to release Commons Exec 1.1-RC1 as 1.1. > > The Apache Commons CSV library provides a simple interface for reading and > writing > CSV files of various types. > > This is our second release. > > Changes in this version include: > > New features: > o [CSV-129] Add CSVFormat#with 0-arg methods matching boolean arg methods. > o [CSV-131] Save positions of records to enable random access. Thanks to > Holger Stratmann. > o [CSV-139] CSVPrinter.printRecord(ResultSet) with metadata. > > Fixed Bugs: > o [CSV-140] QuoteMode.NON_NUMERIC doesn't work with > CSVPrinter.printRecords(ResultSet). Thanks to Damjan Jovanovic. > o [CSV-130] CSVFormat#withHeader doesn't work well with #printComment, add > withHeaderComments(String...). Thanks to Sergei Lebedev. > o [CSV-128] CSVFormat.EXCEL should ignore empty header names. > o [CSV-132] Incorrect Javadoc referencing org.apache.commons.csv.CSVFormat > withQuote(). Thanks to Sascha Szott. > > Changes: > o [CSV-124] Improve toString() implementation of CSVRecord. Thanks to > Kalyan. > o [CSV-134] Unified parameter validation. Thanks to wu wen. > > > This VOTE is open for at least 72 hours until January 19 2014 at 22:00 EST. > > The files: > > https://repository.apache.org/content/repositories/orgapachecommons-1063/ > > The tag: > > https://svn.apache.org/repos/asf/commons/proper/csv/tags/1.1-RC1 > > The site: > > https://people.apache.org/~ggregory/commons-csv/site/ > (note some *relative* links are broken - these will be OK once the site > is deployed) > > Links to versions of sites and Javadocs will be live when deployed. > > Thank you, > Gary Gregory > > -- > 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 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [PROPOSAL] Setup up new sandbox component "Commons Text" with git as primary vcs (Was: Re: [sandbox] New sandbox component)
+1 Cheers, Siegfried Goeschl > On 07 Nov 2014, at 09:47, Benedikt Ritter wrote: > > Hi all, > > as disucssed, we'd like to create a new component which is focused on > algorithms for string/text processing. > > We (= Bruno and I) would like to create this new component with git as > primary vcs right away, which will make Commons Text the second Commons > component to use git. Please let me know if you have objections against > this. I'll open an INFRA ticket for the new git repo, this weekend. > > Thanks! > Benedikt > > 2014-10-27 12:57 GMT+01:00 Benedikt Ritter : > >> >> >> 2014-10-27 12:32 GMT+01:00 Bruno P. Kinoshita >> : >> >>> Hi Benedikt! >>>> Just let me know if you need help with the bootstraping of the new >>> project. >>> Yes, please :) >>> >> >> I'll give folks some more time to share their thoughts about this and >> create the new project then. >> >> >>> >>>> Maybe we should even announce this on announce@. There my be other >>> projects interested in a library like this (for example Apache Tika [1]) >>> Good idea! Should we drop a note there once the project has been created >>> or after we already have some code in there? >>> >> >> The latter seems appropriate to me. >> >> >>> >>> Thanks!Bruno >>> >>> >>> From: Benedikt Ritter >>> To: Commons Developers List ; Bruno P. >>> Kinoshita >>> Sent: Monday, October 27, 2014 5:45 AM >>> Subject: Re: [sandbox] New sandbox component >>> >>> No objections from my site. I think this is a good idea. Just let me know >>> if you need help with the bootstraping of the new project. Maybe we should >>> even announce this on announce@. There my be other projects interested >>> in a library like this (for example Apache Tika [1]) >>> >>> Benedikt >>> >>> [1] http://tika.apache.org/ >>> >>> >>> >>> 2014-10-27 0:41 GMT+01:00 Bruno P. Kinoshita >>> : >>> >>> Hello all, >>> At the moment I'm working with data matching and record linkage, and had >>> to port some existing string comparison algorithms found in several open >>> source projects (fuzzy-search-tools, simmetrics, lingpipe, [lang], [codec]). >>> At that time I noticed LANG-591 [1], which suggests a more complex >>> levenshtein distance algorithm. There are several other algorithms too >>> (damerau-levenshtein, jaro, jaro-wrinkler, jaccard, bitap, q-gram, soundex, >>> metaphone). Instead of trying to put them all in, say, [lang], I'd like to >>> experiment with a new [text] component in the sandbox, if there are no >>> objections. >>> I will take a look at the existing code and its license, but most of >>> these algorithms have good Wiki pages with pseudo code available; as well >>> as academic papers. >>> Maybe this component could be useful for other projects like [lang], >>> Lucene, larsga/Duke, and Talend Open Studio. And even though my initial use >>> case for this would be string comparison, I think it could support other >>> use cases too. >>> Thoughts on this? Anyone else interested on such a component? >>> Thanks!Bruno >>> [1] https://issues.apache.org/jira/browse/LANG-591 >>> >>> >>> >>> -- >>> >>> http://people.apache.org/~britter/http://www.systemoutprintln.de/http://twitter.com/BenediktRitterhttp://github.com/britter >>> >>> -- >>> >>> <http://people.apache.org/~britter/http://www.systemoutprintln.de/http://twitter.com/BenediktRitterhttp://github.com/britter> >>> >>> <http://people.apache.org/~britter/http://www.systemoutprintln.de/http://twitter.com/BenediktRitterhttp://github.com/britter> >>> http://people.apache.org/~britter/ >>> http://www.systemoutprintln.de/ >>> http://twitter.com/BenediktRitter >>> http://github.com/britter >>> >> > > > -- > 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: [VOTE] Release Email 1.3.3 based on RC2
+1 (non-binding) Cheers, Siegfried Goeschl On 05 Jul 2014, at 17:42, Thomas Neidhart wrote: > This is a vote to release Commons Email 1.3.3 based on RC2. > > Changes since RC1: > > * fix test execution with Java 8 > * fix javadoc generation with Java 8 > > > Email 1.3.3 RC2 is available for review here: > https://dist.apache.org/repos/dist/dev/commons/email/ > (svn revision 5753) > > Maven artifacts are here: > > > https://repository.apache.org/content/repositories/orgapachecommons-1037/org/apache/commons/commons-email/1.3.3/ > > Details of changes since 1.3.2 are in the release notes: > > https://dist.apache.org/repos/dist/dev/commons/email/RELEASE-NOTES.txt > > http://people.apache.org/builds/commons/email/1.3.3/RC2/changes-report.html > > The tag is here: > > > https://svn.apache.org/repos/asf/commons/proper/email/tags/EMAIL_1_3_3_RC2/ > (svn 1608038) > > Site: > http://people.apache.org/builds/commons/email/1.3.3/RC2/ > (note some *relative* links are broken and some new directories are > not yet created - these will be OK once the site is deployed) > > KEYS: > http://www.apache.org/dist/commons/KEYS > > Please review the release candidate and vote. > This vote will close no sooner that 72 hours from now. > > [ ] +1 Release these artifacts > [ ] +0 OK, but... > [ ] -0 OK, but really should fix... > [ ] -1 I oppose this release because... > > Thanks! > > 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
Re: [csv] release 1.0?
Hi Gary, what are the JIRAs for the “corner issues”? Cheers, Siegfried Goeschl On 16 Jun 2014, at 17:00, Gary Gregory wrote: > Hi All, > > It seems we have been stuck for a while and that we are all busy. > > Should we pull the trigger and try to release 1.0? > > Or, is anyone willing to step up and do work on the 1 or 2 remaining corner > issues? > > Gary > > -- > 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 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] ApacheCon EU
Hi folks, re-open the following mail thread http://apache-commons.680414.n4.nabble.com/Apache-Commons-ApacheCon-Europe-2014-tp4662314p4662471.html http://apache-commons.680414.n4.nabble.com/Apache-Commons-ApacheCon-Europe-2014-tp4662314p4662992.html with the following outcome Commons SCXML - Ate Douma - will present Commons Email - Siegfried Goeschl - will present Commons Math - Thomas Neidhart - likely to present (depending on personal plans) Commons Collections - Thomas Neidhart - likely to present (depending on personal plans) Commons JCS - Thomas Vandahl - would like to present depending on the JCS 2.0 release Commons VFS - Schalk W. Cronjé - would like to present Commons Compress - Stefan Bodewig - might be interested Commons Exec - Siegfried Goeschl - can give a presentation if feasible Commons CLI - Siegfried Goeschl - can give a presentation if feasible but I’m only a user Any changes? If we apply for a block of Apache Commons presentations for the next ApacheCon we should get our act together :-) Thanks in advance Siegfried Goeschl On 16.06.14 10:39, Thomas Neidhart wrote: Hi, I wanted to ask if somebody else is planning to go to ApacheCon EU this year and willing to give a talk about Commons Math. The deadline for proposals is getting closer and I plan to submit one for Collections and Math if nobody else is volunteering. Thomas - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Apache Commons & ApacheCon Europe 2014 ...
Hi Benedikt, there might be a lot of different kinds there :-) IMHO the problem with "Let people tell us, what they like about lang and what they don't like" is that your presentation depends on the input of the attendees and the presentation setup (good for a small room but bad if you have a large room). One option could for the presentation could be picking common problems and how they are solved with commons-lang * Variable expansion using StrSubstitutor * Dumping third-party objects using ReflectionToStringBuilder * StopWatch for mirco-benchmarks Cheers, Siegfried Goeschl On 02.05.14 09:46, Benedikt Ritter wrote: 2014-04-30 21:24 GMT+02:00 Siegfried Goeschl : Hi folks, I collected the responses/feedback so far sorted according to the given committment Commons SCXML - Ate Douma - will present Commons Email - Siegfried Goeschl - will present Commons Math - Thomas Neidhart - likely to present (depending on personal plans) Commons Collections - Thomas Neidhart - likely to present (depending on personal plans) Commons JCS - Thomas Vandahl - would like to present depending on the JCS 2.0 release Commons VFS - Schalk W. Cronjé - would like to present Commons Compress - Stefan Bodewig - might be interested Commons Exec - Siegfried Goeschl - can give a presentation if feasible Commons CLI - Siegfried Goeschl - can give a presentation if feasible but I’m only a user So far * IMHO the Apache Commons Community should be able to present 5-6 components which would fill 3 regular slots * I would really appreciate if more developers would volunteer for a component - it is a great experience to present at a conference :-) I'm interested to present something. Since I work mostly on commons-lang that would be the component I could talk about. Problem is, I don't really know what kind of talk people a interested in. commons-lang has been around for a long time know and there isn't really something special about it. I'm wondering if it is possible to use a slot for a discussion or something. Let people tell us, what they like about lang and what they don't like. This could lead to some ideas for the design of 4.0 which I'm planning to start latter this year. Benedikt Cheers, Siegfried Goeschl On 28 Apr 2014, at 22:59, Thomas Neidhart wrote: On 04/17/2014 04:02 PM, Siegfried Goeschl wrote: Hi folks, thanks to Phil and Ate to present Apache Commons at the ApacheCon in Denver :-) I would like to follow up the idea of having a dedicated Apache Commons slots for ApacheCon Europe as we have done it in Atlanta * give the Apache Commons committers the chance to present at ApacheCon while NOT working in BigData, Hadoop or NoSQL * use a regular 45 minutes slot to present two Apache Commons components assuming that many components are rather small * present a couple of Apache Commons component within a dedicated block of slots (conference within the conference) * I chatted with Ate Douma about it and he in turn chatted with other guys so I think this idea is in general appreciated So the questions are * Is this idea appreciated? * Who would volunteer for presenting his/her Apache Commons component? I would be interested to go there and give a talk about some components I am contributing to, like math and collections. Can not give a guarantee yet, as I might be occupied for personal reasons in November. 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 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Apache Commons & ApacheCon Europe 2014 ...
Hi folks, I collected the responses/feedback so far sorted according to the given committment Commons SCXML - Ate Douma - will present Commons Email - Siegfried Goeschl - will present Commons Math - Thomas Neidhart - likely to present (depending on personal plans) Commons Collections - Thomas Neidhart - likely to present (depending on personal plans) Commons JCS - Thomas Vandahl - would like to present depending on the JCS 2.0 release Commons VFS - Schalk W. Cronjé - would like to present Commons Compress - Stefan Bodewig - might be interested Commons Exec - Siegfried Goeschl - can give a presentation if feasible Commons CLI - Siegfried Goeschl - can give a presentation if feasible but I’m only a user So far * IMHO the Apache Commons Community should be able to present 5-6 components which would fill 3 regular slots * I would really appreciate if more developers would volunteer for a component - it is a great experience to present at a conference :-) Cheers, Siegfried Goeschl On 28 Apr 2014, at 22:59, Thomas Neidhart wrote: > On 04/17/2014 04:02 PM, Siegfried Goeschl wrote: >> Hi folks, >> >> thanks to Phil and Ate to present Apache Commons at the ApacheCon in Denver >> :-) >> >> I would like to follow up the idea of having a dedicated Apache Commons >> slots for ApacheCon Europe as we have done it in Atlanta >> >> * give the Apache Commons committers the chance to present at ApacheCon >> while NOT working in BigData, Hadoop or NoSQL >> * use a regular 45 minutes slot to present two Apache Commons components >> assuming that many components are rather small >> * present a couple of Apache Commons component within a dedicated block of >> slots (conference within the conference) >> * I chatted with Ate Douma about it and he in turn chatted with other guys >> so I think this idea is in general appreciated >> >> So the questions are >> >> * Is this idea appreciated? >> * Who would volunteer for presenting his/her Apache Commons component? > > I would be interested to go there and give a talk about some components > I am contributing to, like math and collections. > > Can not give a guarantee yet, as I might be occupied for personal > reasons in November. > > 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
Re: svn commit: r1590035 - /commons/proper/io/trunk/pom.xml
For the records and not-soo-old-hands - http://www.apache.org/memorials/ Siegfried Goeschl On 25 Apr 2014, at 21:38, Phil Steitz wrote: > On 4/25/14, 12:14 PM, Oliver Heger wrote: >> >> Am 25.04.2014 16:11, schrieb brit...@apache.org: >>> Author: britter >>> Date: Fri Apr 25 14:11:14 2014 >>> New Revision: 1590035 >>> >>> URL: http://svn.apache.org/r1590035 >>> Log: >>> Fix typo >>> >>> Modified: >>>commons/proper/io/trunk/pom.xml >>> >>> Modified: commons/proper/io/trunk/pom.xml >>> URL: >>> http://svn.apache.org/viewvc/commons/proper/io/trunk/pom.xml?rev=1590035&r1=1590034&r2=1590035&view=diff >>> == >>> --- commons/proper/io/trunk/pom.xml (original) >>> +++ commons/proper/io/trunk/pom.xml Fri Apr 25 14:11:14 2014 >>> @@ -65,7 +65,7 @@ file comparators, endian transformation >>> >>> >>> >>> - dIon Gillard >>> + Dion Gillard >> AFAIK, this was not a typo, but the usual way he spelled his name. > > Indeed. You can see his original add to the parent of the parent of > this file here: > http://svn.apache.org/viewvc/commons/proper/io/tags/IO_1_0/STATUS.html?r1=140285&r2=140297 > > I remember I used to think the second letter was an "L." A little > sad today thinking he is no longer with us. He certainly > contributed a lot to this community and helped quite a few of us get > involved. > > Phil >> >> Oliver >> >>> dion >>> d...@apache.org >>> >>> >>> >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [jcs] jcache support?
Hi folks, don't know the official view of things (current ASF Git support) but I use GitHub to work on refactoring since it allows broader contribution (only GitHub account is required) Cheers, Siegfried Goeschl On 25.04.14 09:28, Romain Manni-Bucau wrote: yep was the idea. promoting jcs to incubator would definively be great. The short term question and sandbox reference was more: how can we work together on tcks. Using patches makes it hard (you need to merge all patches etc if several people are contributing). Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-04-25 9:09 GMT+02:00 Jean-Louis MONTEIRO : You mean move to the sandbox area to work more easily on JCache specification implementation. And maybe try to get JCS to incubator and then try to promote to TLP? Not sure I got all your points. JLouis 2014-04-25 8:43 GMT+02:00 Romain Manni-Bucau : Did some more work ( still attached to https://issues.apache.org/jira/browse/JCS-118 - side note: i didnt recheck defaults tests here so maybe seomthing is broken regarding the configuration I changed a bit as mentionned in a comment ) The question at this point is how to go ahead? My main issue is while we don't have a fully working patch how can we share changes. Not sure patches are the best solution. [sandbox] could be since we are more to have perms. wdyt? Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-04-22 9:41 GMT+02:00 Jean-Louis MONTEIRO : +1, that'd be awesome. I don't think it's a big word/rework. Crossing fingers, it's just a matter of some interfaces and an SPI to implement. JLouis 2014-04-21 20:39 GMT+02:00 Thomas Vandahl : On 21.04.14 19:06, Romain Manni-Bucau wrote: saw it, I can rephrase the question this way: will tomee be able to rely on jcs or should we directly use ehcache as do cxf already for other needs. I'd like to see an apache product in the box but not sure we'll find enough time to make it real short term Me too. I think it should be not too hard and the 2.0 release is certainly a good milestone to work on this. At the moment, however, I maintain this project pretty much alone and I have no idea what JCache means and how it is related to the current architecture of JCS. I'm willing to help as much as I can. Bye, Thomas. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Jean-Louis - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Jean-Louis - 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: Apache Commons & ApacheCon Europe 2014
Hi folks, so judging from the conversation we have volunteers for Apache Commons VFS :-) Reclaiming the message thread - who else would like to present his/her pet component? Thanks in advance Siegfried Goeschl On 17 Apr 2014, at 17:28, Schalk Cronjé wrote: > On 17/04/2014 23:45, Mark Fortner wrote: >> Schalk, >> It's my understanding that new providers in NIO2 are simply added using the >> ServiceLoader. >> >> Cheers, >> >> Mark > Hi Mark, > > Maybe I should have explained better, > > In Apache VFS one can either add custom providers via a > META-INF/vfs-providers.xml file (behaviour of StandardFileSystemManager). > This means just compiling a JAR accordingly and have it available on the > classpath. Let's call this Approach A. > > Alternatively one can call addProvider (on DefaultFileSystemManager) > directly. This is quite useful in certain circumstances to do this > programmatically. This is Approach B. > > With NIO2 loading occurs by providing a > META-INF/services/java.nio.file.spi.FileSystemProvider file and ServiceLoader > should take care of it. This is effectively the NIO2 way of Approach A. > > What I am saying is that I would like to have an Approach B for NIO2 as well, > except that I have seen no clear way of accomplishing it. It could just be a > lack of knowledge on my side. > >> >> >> On Thu, Apr 17, 2014 at 3:31 PM, Schalk Cronj é wrote: >> >>> On 17/04/2014 22:38, Bernd Eckenfels wrote: >>> >>> >>> >>> But theoretically both is possible: consume FileSystems as a provider >>>> or implement an adapter which makes a VFS filesystem(manager) to >>>> provide the FileSystem SPI. >>>> >>> I have been playing with that and it looks possible, but it is far from >>> trivial. The meagre documentation or even lack of published success in >>> writing NIO2 providers shows that this is a road less travelled. I have >>> looked at the supplied ZIP example that comes with the JDK and IMHO still >>> very much prototype code. >>> >>> I think VFS has some things going for it that I could not see in NIO2 - >>> even something as simple as having two schemes for one provider. In >>> addition, adding providers on the fly is easy in VFS, by just calling >>> addProvider on FilesystemManager. From my initial investigation I could not >>> see a clear way of doing the equivalent in NIO2. There will be more things >>> like these, I am sure. >>> >>> I am very interesting in where this is going in future and the maintainer >>> of Groovy VFS, I have a vested interest. I might be interested to go to >>> Budapest in November if this gets discussed. >>> >>> >>> >>> -- >>> Schalk W. Cronjé >>> @ysb33r >>> >>> >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> > > > -- > Schalk W. Cronjé > @ysb33r > > > - > 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
Apache Commons & ApacheCon Europe 2014 ...
Hi folks, thanks to Phil and Ate to present Apache Commons at the ApacheCon in Denver :-) I would like to follow up the idea of having a dedicated Apache Commons slots for ApacheCon Europe as we have done it in Atlanta * give the Apache Commons committers the chance to present at ApacheCon while NOT working in BigData, Hadoop or NoSQL * use a regular 45 minutes slot to present two Apache Commons components assuming that many components are rather small * present a couple of Apache Commons component within a dedicated block of slots (conference within the conference) * I chatted with Ate Douma about it and he in turn chatted with other guys so I think this idea is in general appreciated So the questions are * Is this idea appreciated? * Who would volunteer for presenting his/her Apache Commons component? Thanks in advance Siegfried Goeschl - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release of Commons Email 1.3.2 based on RC2
Hi Gary, I check tonight ... Cheers, Siegfried Goeschl On 24.10.13 15:35, Gary Gregory wrote: What is happening with this [vote] thread? Would anyone else care to chime in? Gary On Sun, Oct 20, 2013 at 12:51 PM, Thomas Neidhart wrote: Hi, I'd like to call a vote for releasing Commons Email 1.3.2 based on RC2. Changes since RC1: - fixed unit test SimpleHtmlEmail.testDefaultMimeCharset which failed in certain environments Email 1.3.2 RC2 is available for review here: https://dist.apache.org/repos/dist/dev/commons/email/ (svn revision 3303) Maven artifacts are here: https://repository.apache.org/content/repositories/orgapachecommons-004/org/apache/commons/commons-email/1.3.2/ The tag is here: https://svn.apache.org/repos/asf/commons/proper/email/tags/EMAIL_1_3_2_RC2 (svn revision 1533925) Site: http://people.apache.org/builds/commons/email/1.3.2/RC2/ Details of changes since 1.3.1 are in the release notes: https://dist.apache.org/repos/dist/dev/commons/email/RELEASE-NOTES.txt http://people.apache.org/builds/commons/email/1.3.2/RC2/changes-report.html Please review the release candidate and vote. This vote will close no sooner than 72 hours from now. [ ] +1 Release these artifacts [ ] +0 OK, but... [ ] -0 OK, but really should fix... [ ] -1 I oppose this release because... Thank you for your reviews, 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
Re: [VOTE] Release of Commons Email 1.3.2 based on RC1
Hi Thomas, I have issue when builing on the command line - > mvn clean install Oct 16, 2013 10:39:02 AM org.subethamail.smtp.server.ServerThread run INFO: SMTP server *:2510 stopped emailMessage === Received: from 172.22.120.122 (localhost [127.0.0.1]) by 172.22.120.122 with SMTP (SubEthaSMTP 3.1.7) id HMUB60OT for test...@apache.org; Wed, 16 Oct 2013 10:39:02 +0200 (CEST) Date: Wed, 16 Oct 2013 10:39:02 +0200 (CEST) From: test_f...@apache.org To: test...@apache.org Message-ID: <429777281.42.1381912742908.JavaMail.sgoeschl@district9.local> Subject: Test Msg Subject MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 VGVzdCBNc2cgQm9keSDDo8KCwrAgw6PCgsKxIMOjwoLCsiDDo8KCwrMgw6PCgsK0 - 578 strMessage === strMessage - 33 Test Msg Body ??? ??? ??? ??? ??? Tests run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.021 sec <<< FAILURE! - in org.apache.commons.mail.SimpleEmailTest testDefaultMimeCharset(org.apache.commons.mail.SimpleEmailTest) Time elapsed: 0.012 sec <<< FAILURE! java.lang.AssertionError: didn't find expected message content in message body at org.junit.Assert.fail(Assert.java:88) at org.junit.Assert.assertTrue(Assert.java:41) at org.apache.commons.mail.AbstractEmailTest.validateSend(AbstractEmailTest.java:395) at org.apache.commons.mail.SimpleEmailTest.testDefaultMimeCharset(SimpleEmailTest.java:155) Running org.apache.commons.mail.util.MimeMessageParserTest Tests run: 9, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.029 sec - in org.apache.commons.mail.util.MimeMessageParserTest Results : Failed tests: SimpleEmailTest.testDefaultMimeCharset:155->AbstractEmailTest.validateSend:395 didn't find expected message content in message body Tests run: 169, Failures: 1, Errors: 0, Skipped: 0 [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 13.110s [INFO] Finished at: Wed Oct 16 10:39:02 CEST 2013 [INFO] Final Memory: 12M/81M Some thoughts along the line * this problem does not occur in IntellJ with JDK 1.6 / 1.7 * I'm running Mac OS X java version "1.6.0_31", Java(TM) SE Runtime Environment (build 1.6.0_31-b04-415-12D78), Java HotSpot(TM) 64-Bit Server VM (build 20.6-b01-415, mixed mode) * I think the email message is the error case still Base64 decoded * It would be safer to use Unicode Escape Sequences instead of UTF-8 message string since you have ASCII code only Cheers, Siegfried Goeschl This problem On 16.10.13 00:20, Thomas Neidhart wrote: Hi, I'd like to call a vote for releasing Commons Email 1.3.2 based on RC1. Email 1.3.2 RC1 is available for review here: https://dist.apache.org/repos/dist/dev/commons/email/ (svn revision 3275) Maven artifacts are here: https://repository.apache.org/content/repositories/orgapachecommons-182/org/apache/commons/commons-email/1.3.2/ The tag is here: https://svn.apache.org/repos/asf/commons/proper/email/tags/EMAIL_1_3_2_RC1 (svn revision 1532553) Site: http://people.apache.org/builds/commons/email/1.3.2/RC1/ Details of changes since 1.3.1 are in the release notes: https://dist.apache.org/repos/dist/dev/commons/email/RELEASE-NOTES.txt http://people.apache.org/builds/commons/email/1.3.2/RC1/changes-report.html Please review the release candidate and vote. This vote will close no sooner than 72 hours from now. [ ] +1 Release these artifacts [ ] +0 OK, but... [ ] -0 OK, but really should fix... [ ] -1 I oppose this release because... Thank you for your reviews, 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
Re: [DISCUSS] Creating Project for Release Process Testing...
+1 on that I did a few releases over the year and had ALWAYS issues - for me the biggest obstacles are * getting a positive vote on a RC (that's a different story) * getting the release out of the door - a test project would help immensely since I can blow it up without any consequences Cheers, Siegfried Goeschl On 10.10.13 17:29, Gary Gregory wrote: Nice idea, but push it to central to test the whole chain. G On Thu, Oct 10, 2013 at 11:24 AM, James Carman wrote: Why don't we create a real project that we can cut real releases on to test our release procedures? Perhaps we can set it up so that it doesn't sync with central and just gets staged locally. This way, we can test out changes to the release process and see how they work. Also, a new release manager can play around with that project and get it right before diving into the real work. - 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: [DISCUSS] API compatibility policy
Hi Gary, A new major release requires a new package name, site, build and so on - think of commons-lang v1,2,3 Cheers, Siegfried Goeschl > Am 08.10.2013 um 22:54 schrieb Gary Gregory : > > On Tue, Oct 8, 2013 at 4:50 PM, Siegfried Goeschl > wrote: >> That's a reasonable style of versioning :) >> >> I had many issues with binary compatibilty with a commons-email release due >> to changing the return value from void to a this reference plus some moving >> of constants. You basically end up with either many restrictions or creating >> major releases > > Then just create major releases! ;) Why would you not want to provide > BC? Why add to the jar hell problem? I, the developer, have no control > over how the API I provide will be used and distributed... > > G > >> >> Cheers, >> >> Siegfried Goeschl >> >>> Am 08.10.2013 um 12:40 schrieb Torsten Curdt : >>> >>> Cannot remember which component from the top of my head - but it was >>> related to package name changes. >>> >>> My style of thinking: x.y.z >>> >>> x - no compatibility >>> y - source compatibility >>> z - binary compatibility >>> >>> is simple and makes sense. >>> >>> It's OK to put some burden on the users when upgrading - as long as the >>> expectations are set correctly. >>> But I am pretty sure we discussed that before and some people did not agree. >>> >>> cheers, >>> Torsten >>> >>> >>>>> On Tue, Oct 8, 2013 at 12:08 PM, Stefan Bodewig >>>>> wrote: >>>>> >>>>> On 2013-10-08, Emmanuel Bourg wrote: >>>>> >>>>> Le 07/10/2013 20:14, Benedikt Ritter a écrit : >>>> >>>>>> - loosen API compatibility policy? >>>> >>>>> This topic alone deserves its own thread I think. >>>> >>>>> Ensuring binary/source compatibility is very important. >>>> >>>> +1 >>>> >>>> I guess I've done too much ruby with "every bundle update runs the risk >>>> of breaking everything" lately. I really value the stability commons >>>> provides. >>>> >>>> That being said, I'm sure there are cases where our policy seems >>>> stricter than it needs to be - even though I haven't seen a really >>>> difficult case in the one component I contribute to. >>>> >>>> Stefan >>>> >>>> - >>>> 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 > > > > -- > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org > Java Persistence with Hibernate, Second Edition > JUnit in Action, Second Edition > Spring Batch in Action > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory > > - > 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: [DISCUSS] API compatibility policy
That's a reasonable style of versioning :) I had many issues with binary compatibilty with a commons-email release due to changing the return value from void to a this reference plus some moving of constants. You basically end up with either many restrictions or creating major releases Cheers, Siegfried Goeschl > Am 08.10.2013 um 12:40 schrieb Torsten Curdt : > > Cannot remember which component from the top of my head - but it was > related to package name changes. > > My style of thinking: x.y.z > > x - no compatibility > y - source compatibility > z - binary compatibility > > is simple and makes sense. > > It's OK to put some burden on the users when upgrading - as long as the > expectations are set correctly. > But I am pretty sure we discussed that before and some people did not agree. > > cheers, > Torsten > > >> On Tue, Oct 8, 2013 at 12:08 PM, Stefan Bodewig wrote: >> >>> On 2013-10-08, Emmanuel Bourg wrote: >>> >>> Le 07/10/2013 20:14, Benedikt Ritter a écrit : >> >>>> - loosen API compatibility policy? >> >>> This topic alone deserves its own thread I think. >> >>> Ensuring binary/source compatibility is very important. >> >> +1 >> >> I guess I've done too much ruby with "every bundle update runs the risk >> of breaking everything" lately. I really value the stability commons >> provides. >> >> That being said, I'm sure there are cases where our policy seems >> stricter than it needs to be - even though I haven't seen a really >> difficult case in the one component I contribute to. >> >> Stefan >> >> - >> 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: [email] Problem reading filename from inline email
Hi Olaf,
can you create a JIRA with the attached file?
Cheers,
Siegfried Goeschl
On 20.09.13 19:13, Olaf Kaus wrote:
Hi,
how can I extract the filename from an included email.
If I use mimeMessageParser.getAttachmentList() and then
dataSource.getName() but I received null for attched emails.
The incoming email was created with outlook (html-email) and via
drag-n-drop I include an other email as an attachment.
To resolve this behavior I patched the Methode "getDataSourceName" in
"MimeMessageParser" as follows.
...
if ("message/rfc822".equalsIgnoreCase(contentType)) {
result = ((Message) part.getContent()).getSubject();
if (StringUtils.isNotBlank(result)) {
result += ".eml";
} else {
result = "unknown.eml";
}
...
(I stripped some null-checks)
Do you have an other solution?
Thx in advance
Olaf
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [compress] Support for strong encryption in zip files?
Hi folks, don't know if this was already mentioned but providing strong encryption causes administrative head-ache http://www.apache.org/dev/crypto.html Cheers, Siegfried Goeschl On 12.06.13 16:29, Bear Giles wrote: This morning I realized that the license requirement could be a real problem if it applies to the end developer instead of or in addition to any libraries. On the other hand it might just be a completely reasonable requirement that the code be tested for compatibility with PKWARE and the license requirement would stop with the library. I have no idea. Fortunately I think it would be easy to design this around a injected interface, something like byte[] encrypt(byte[] plaintext, List fields) and likewise for decryption. The fields are immutable for decryption but not encryption. (It looks like streaming isn't always possible since the headers contain checksum information but I need to re-check that.) This could be generalized to allow arbitrary transformations - compression, encryption, etc., albeit at the loss of interoperability if developers create their own. In this case the encryption could be provided in a separate library. On the encryption itself I can understand the concerns about the false sense of security with the legacy encryption but the newer stuff looks strong - it supports AES, has a unique encryption key for each file, prepends randomized data to block known plaintext attacks, etc. You can encrypt the metadata (filenames, etc.) I definitely think embedded encryption is better than running it through PGP since a damaged file is much more recoverable - just scan through the file for the next (unencrypted) header. PGP also chunks data but there's no correlation between the PGP chunks and the zip entries. A clean room implementation based on the APPNOTE is looking like it might be a challenge. It's a good overview but it doesn't document key things like how the per-file session key is generated from the master key. I don't know how much I can peek into other open-source implementations without running afoul of "original work" requirements - obviously I would never cut-and-paste but some of this has only one possible implementation modulo window-dressing. (E.g., how do you call the method?) Maybe that's provided as part of a developer pack after you contact them about a license. Bear - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Launcher] [Exec] Merge Proposal
Hi folks, had a quick look * similar functionality of both components * launcher has some bells and whistles regarding launching Java processes compared to commons-exec * commons-launcher has Ant dependencies IMHO retiring commons-launcher and moving it to commons-exec is a good idea Cheers, Siegfried Goeschl On 10.06.13 12:07, Ricardo Espírito Santo wrote: Hi Emmanuel, Thank you for your comments. Please find mine @inline. Regards, Ricardo Espírito Santo On 10 June 2013 00:48, Emmanuel Bourg wrote: Le 09/06/2013 22:03, Ricardo Espírito Santo a écrit : - Very similar objectives, features and aims exec: Invoke an external application from Java launcher: Start a Java application from the shell Besides launching something they don't look that similar to me. That's a very good similarity! They both launch something and since that is 99% of what they do I'd say they do pretty much the same thing. If you look at any other Commons sub project I believe you will find that none of them addresses only one issue. - Simplification of the overall Commons project by reducing the number of specific projects without compromising feature delivery That doesn't look like an issue. It is not an issue on its own but having a lot of choices requires a more intricate knowledge of the components and more specific nuances between them. Surely we want to move towards a simpler and easier user experience. - The merged project will probably involve and capture attention of new contributors Not sure to see how merging projects attracts new contributors. But if it works I suggest merging all Commons projects into a big one :) The memento in both Exec and Launch seems to have halted and I believe that by creating a new project, new users who have actually done some work for either project in the past and also for those just looking for something easy and small to start contributing to Commons will be drawn in - No one likes to commit work to a project which has been parked for over 5 years. - Code share and total lines of code reduction Not an issue considering the small size of these components. I agree, not an issue but surely this should be an aim and a philosophy rather than a technical consideration. - My reasoning is: even if its just 10 duplicate lines they shouldn't be duplicate in the first place. - General update of both project’s source code This can be done without merging. True but it hasn't been done so far. Why? no interest in either projects... Aren't the most active projects the ones which do more than one thing and interest more users ? [Reasons not to merge] - Broadening the focus of each project - The actual work of planning the merge, merging and documenting imply person-hours that could be applied to more functional tasks I agree, let's fix the issues that actually matter to our users. Again a few issues have been raises, patches have been proposed and yet the development has nevertheless halted. Emmanuel Bourg - 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: [Launcher] [Exec] Merge Proposal
Hi folks, there is actually "launcher" code in commons-exec - see org.apache.commons.exec.launcher I'm having a look "Launcher" code this evening Cheers, Siegfried Goeschl On 10.06.13 12:07, Ricardo Espírito Santo wrote: Hi Emmanuel, Thank you for your comments. Please find mine @inline. Regards, Ricardo Espírito Santo On 10 June 2013 00:48, Emmanuel Bourg wrote: Le 09/06/2013 22:03, Ricardo Espírito Santo a écrit : - Very similar objectives, features and aims exec: Invoke an external application from Java launcher: Start a Java application from the shell Besides launching something they don't look that similar to me. That's a very good similarity! They both launch something and since that is 99% of what they do I'd say they do pretty much the same thing. If you look at any other Commons sub project I believe you will find that none of them addresses only one issue. - Simplification of the overall Commons project by reducing the number of specific projects without compromising feature delivery That doesn't look like an issue. It is not an issue on its own but having a lot of choices requires a more intricate knowledge of the components and more specific nuances between them. Surely we want to move towards a simpler and easier user experience. - The merged project will probably involve and capture attention of new contributors Not sure to see how merging projects attracts new contributors. But if it works I suggest merging all Commons projects into a big one :) The memento in both Exec and Launch seems to have halted and I believe that by creating a new project, new users who have actually done some work for either project in the past and also for those just looking for something easy and small to start contributing to Commons will be drawn in - No one likes to commit work to a project which has been parked for over 5 years. - Code share and total lines of code reduction Not an issue considering the small size of these components. I agree, not an issue but surely this should be an aim and a philosophy rather than a technical consideration. - My reasoning is: even if its just 10 duplicate lines they shouldn't be duplicate in the first place. - General update of both project’s source code This can be done without merging. True but it hasn't been done so far. Why? no interest in either projects... Aren't the most active projects the ones which do more than one thing and interest more users ? [Reasons not to merge] - Broadening the focus of each project - The actual work of planning the merge, merging and documenting imply person-hours that could be applied to more functional tasks I agree, let's fix the issues that actually matter to our users. Again a few issues have been raises, patches have been proposed and yet the development has nevertheless halted. Emmanuel Bourg - 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: [VOTE] Release of Commons Email 1.3.1 based on RC2
Hi Thomas, don't take it personally - a Commons release is not for the faint-hearted and you doing a brilliant job ... ;-) Cheers, Siegfried Goeschl On 27.02.13 09:41, Thomas Neidhart wrote: It is easy to fix, so I will start another RC this evening. It just annoys me that I overlooked such small things which now delay a release (and it is a shame that it takes 3 RCs to release 2 bugfixes, but ok, thats my fault). Thomas On Wed, Feb 27, 2013 at 3:16 AM, Jörg Schaible wrote: Hi Gary, Gary Gregory wrote: OK, sounds like a respin then? The situation is no more worse than for 1.3. Currently 1.3.1 simply means some important(?) bug fixes with the same amount of failing tests on IBM JDK. Therefore I abstained from the vote, but it can be reasonable to release it anyway. - Jörg - 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: [ANNOUNCE] Commons Email version 1.3 released
Hi Thomas, without your effort there would be no release - no matter what I implemented over the time - Cui honorem, honorem Cheers, Siegfried Goeschl PS: Not sure if I'm on annou...@apache.org any more ... On 11.01.13 19:11, Thomas Neidhart wrote: On 01/11/2013 06:40 PM, Siegfried Goeschl wrote: Congratulations :-) thanks, but I just finished what you did all the time ;-). It was a bit painful in the end, but I learned a lot, so hopefully the next release(s) will go faster. btw. did anyone receive the announcement from annou...@apache.org? I had some problems first as I did not send it with my @apache.org email, and it is not yet in the mailinglist archive. 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
Re: [ANNOUNCE] Commons Email version 1.3 released
Congratulations :-) Siegfried Goeschl On 11.01.13 16:36, Thomas Neidhart wrote: Hello. The Apache Commons team is pleased to announce the release of commons-email-1.3. Commons-Email aims to provide an API for sending email. It is built on top of the JavaMail API, which it aims to simplify. Commons Email can be downloaded from the following page: http://commons.apache.org/email/download_email.cgi For information on Commons Email, please visit our website: http://commons.apache.org/email/ Details of the changes and bug fixes in this release can be found in the release notes: http://www.apache.org/dist/commons/email/RELEASE-NOTES.txt The changes are also available at: http://commons.apache.org/email/changes-report.html Commons Email now requires Java 5 or later. The Maven coordinates are: org.apache.commons commons-email 1.3 Best regards, Thomas, on behalf of the Apache Commons community - 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
Fwd: Re: [VOTE] Release of commons-email-1.3 based on RC5
Original Message Subject: Re: [VOTE] Release of commons-email-1.3 based on RC5 Date: Wed, 12 Dec 2012 21:49:39 +0100 From: Siegfried Goeschl Reply-To: sgoes...@gmx.at To: Gary Gregory Hi Gary, just checked the Apache site and you are right - no way to remove a deprecated method using the same major release version Siegfried Goeschl On 12.12.12 21:44, Gary Gregory wrote: On Wed, Dec 12, 2012 at 3:40 PM, Siegfried Goeschl mailto:sgoes...@gmx.at>> wrote: Hi Thomas, there is some code out there using it to build emails based on maps https://turbine.apache.org/__fulcrum/fulcrum-commonsemail/__xref/index.html <https://turbine.apache.org/fulcrum/fulcrum-commonsemail/xref/index.html> AFAIK we are free to drop deprecated stuff when doing a minor release - which of course breaks binary compatibility. I do not think so, not for a minor release. Breaking BC is for major releases, which also involves a package name and artifact name change, if we follow what we've done for [lang] and [vfs]. Gary Cheers, Siegfried Goeschl On 12.12.12 21:31, Thomas Neidhart wrote: On 12/12/2012 08:39 PM, Siegfried Goeschl wrote: Hi folks, to avoid the full circles here * I hopefully fixed the binary compatibility issue, wrote test and also tested it with my production code * I moved the constants to EmailConstants because there are many constants and using an non-trivial implementation class (Email) to access a few constants is also questionable in my opinion * The design of commons-email is flawed in a few ways and there is not a lot you can fix in a major version. So I suggest that we focus on delivered value instead Hi Siegfried, thanks for your feedback. Taking this into account, together with the posts from sebb and Gary, imho the best solutions is as sebb proposed: * Change EmailConstants to a public final class * Add back the constants to the Email class by referencing them from EmailConstants * Mark the constants in Email as deprecated btw. there are several constants that have not been in use since the 1.0 release: String SENDER_EMAIL = "sender.email"; String SENDER_NAME = "sender.name <http://sender.name>"; String RECEIVER_EMAIL = "receiver.email"; String RECEIVER_NAME = "receiver.name <http://receiver.name>"; String EMAIL_SUBJECT = "email.subject"; String EMAIL_BODY = "email.body"; String CONTENT_TYPE = "content.type"; String ATTACHMENTS = "attachments"; String FILE_SERVER = "file.server"; Does anybody know how or if they are in use? They are now marked as deprecated, but I am really curious about there origin. Does everybody agree on wha? Thomas Cheers, Siegfried Goeschl On 12.12.12 15:06, sebb wrote: On 12 December 2012 13:17, Gary Gregory mailto:garydgreg...@gmail.com>> wrote: On Wed, Dec 12, 2012 at 3:59 AM, Thomas Neidhart mailto:thomas.neidh...@gmail.com>>__wrote: On Wed, Dec 12, 2012 at 4:58 AM, Gary Gregory mailto:garydgreg...@gmail.com> wrote: Thank you for doing another RC. While I was digging for a justification of the Clirr errors, I found this in the release notes: "Clirr reports several errors for this release due to moving constants from the Email class to the newly introduced EmailConstants interface. These changes are guaranteed to be binary compatible." Is it really binary compatible? What if I use reflection to access the constant on Email, will the reflection call be redirected to EmailConstants? There's unit test for ya ;) Using an interface to define constants is a no-no in my book. I've seen this discus
Re: [VOTE] Release of commons-email-1.3 based on RC5
Hi Thomas, there is some code out there using it to build emails based on maps https://turbine.apache.org/fulcrum/fulcrum-commonsemail/xref/index.html AFAIK we are free to drop deprecated stuff when doing a minor release - which of course breaks binary compatibility. Cheers, Siegfried Goeschl On 12.12.12 21:31, Thomas Neidhart wrote: On 12/12/2012 08:39 PM, Siegfried Goeschl wrote: Hi folks, to avoid the full circles here * I hopefully fixed the binary compatibility issue, wrote test and also tested it with my production code * I moved the constants to EmailConstants because there are many constants and using an non-trivial implementation class (Email) to access a few constants is also questionable in my opinion * The design of commons-email is flawed in a few ways and there is not a lot you can fix in a major version. So I suggest that we focus on delivered value instead Hi Siegfried, thanks for your feedback. Taking this into account, together with the posts from sebb and Gary, imho the best solutions is as sebb proposed: * Change EmailConstants to a public final class * Add back the constants to the Email class by referencing them from EmailConstants * Mark the constants in Email as deprecated btw. there are several constants that have not been in use since the 1.0 release: String SENDER_EMAIL = "sender.email"; String SENDER_NAME = "sender.name"; String RECEIVER_EMAIL = "receiver.email"; String RECEIVER_NAME = "receiver.name"; String EMAIL_SUBJECT = "email.subject"; String EMAIL_BODY = "email.body"; String CONTENT_TYPE = "content.type"; String ATTACHMENTS = "attachments"; String FILE_SERVER = "file.server"; Does anybody know how or if they are in use? They are now marked as deprecated, but I am really curious about there origin. Does everybody agree on wha? Thomas Cheers, Siegfried Goeschl On 12.12.12 15:06, sebb wrote: On 12 December 2012 13:17, Gary Gregory wrote: On Wed, Dec 12, 2012 at 3:59 AM, Thomas Neidhart wrote: On Wed, Dec 12, 2012 at 4:58 AM, Gary Gregory wrote: Thank you for doing another RC. While I was digging for a justification of the Clirr errors, I found this in the release notes: "Clirr reports several errors for this release due to moving constants from the Email class to the newly introduced EmailConstants interface. These changes are guaranteed to be binary compatible." Is it really binary compatible? What if I use reflection to access the constant on Email, will the reflection call be redirected to EmailConstants? There's unit test for ya ;) Using an interface to define constants is a no-no in my book. I've seen this discussed before in other places and for a long time, but to summarize, I see an interface as defining a contract for a class to implement. A constant does not fit. Constants in interface feels like a hack to provide the short hand of a class implementing an interface just to be able to access the constants without qualifying them with a type. Not nice design IMO and a dubious us of an interface, very Java 1.0. It seems that static imports is another attempt to solve this desire for a short hand to use constants. What to do? Move the constants back to their 1.2? What's so bad about that? Hm... Make the EmailConstants a class instead of an interface? If binary compatible is broken, the constants have to move back, and you can still have a new EmailConstants class and deprecate the old constants to point to the new class. Maybe I'll see this more clearly in the AM... Interested in you all's feedback. Hi Gary, well, I think we go in circles with this change ;-). I assumed that this topic is settled after reading the comment from sebb in the RC2 thread (see http://markmail.org/message/svrb7nf3ocz7lgmd). Otoh, it's the first time I see constants in an interface and would be in favor of reverting to the previous version (also because I do not fully understand the rationale behind the change, some of the constants are not even used and thus have been deprecated). -- Maybe we should postpone this kind of refactoring to 2.0 and do it then in a proper way. Introducing this interface just created headaches and I also had to disable some checks (e.g. InterfaceIsAType in checkstyle) because of it. That sounds like a good way to go to get 1.3 out the door. Agreed. Gary Thomas On Tue, Dec 11, 2012 at 5:24 PM, Thomas Neidhart wrote: Hi, I would like to call a vote from commons-email-1.3 based on RC5. This release candidate has the following changes compared to RC4 +) update index and building page with correct information wrt Java compatibility +) update release notes with info on Java compatibility and Clirr errors +) fix svn:keywords for all source files and remove use of $Date$ tags +) add $Id$ tags for all newl
Re: [VOTE][CANCEL] Release of commons-email-1.3 based on RC4
Unfortunately I do remember ... :-( Siegfried Goeschl On 11.12.12 22:08, Mark Struberg wrote: we had this over here at UPC as well. This did cost Sigi a release as well if you remember ;) Most times this can be disabled by your provider. Just phone them and explain that they are breaking your computer and this creates costs by them not acting standard conform ;) LieGrue, strub - Original Message - From: sebb To: Commons Developers List Cc: Sent: Tuesday, December 11, 2012 9:18 PM Subject: Re: [VOTE][CANCEL] Release of commons-email-1.3 based on RC4 On 11 December 2012 12:11, Gary Gregory wrote: On Tue, Dec 11, 2012 at 6:56 AM, sebb wrote: On 11 December 2012 08:58, Thomas Neidhart wrote: > Hi, > > thanks for looking into it. > > I will fix the issues wrt build page, release notes and findbugs warnings. > > Regarding the unit test failure: > > I have not seen the problem before, and just validated it. The unit test > tries to open a connection to an invalid url: http://example.invalid > For some reason this seems to succeed in your environment. Could it be that > you have a custom hosts entry for this domain? Or it could be a faulty DNS server. I used to have this exact problem with the OpenDNS server. They resolve unknown hosts to their home page (extra advertising). They used to do this for *.invalid as well, but after years of complaints that this behaviour was contrary to the RFC they fixed the issue. Try pinging example.invalid and then do an nslookup on the IP address. That is what Cox must be doing indeed: Pinging example.invalid [72.215.225.9] with 32 bytes of data: Request timed out. Request timed out. Request timed out. My browser redirects this IP to http://finder.cox.net/dnserror.html So Cox are violating the RFC. Perhaps you could direct them to the relevant RFC: There are several TLD names which are reserved by RFC 2606, section 2. Amongst them is the TLD "invalid". ".invalid" is intended for use in online construction of domain names that are sure to be invalid and which it is obvious at a glance are invalid. Note the phrase "that are sure to be invalid". An invalid domain name cannot have an IP address. No DNS server should ever resolve addresses in the TLD "invalid". Gary - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release of commons-email-1.3 based on RC5
Hi folks, to avoid the full circles here * I hopefully fixed the binary compatibility issue, wrote test and also tested it with my production code * I moved the constants to EmailConstants because there are many constants and using an non-trivial implementation class (Email) to access a few constants is also questionable in my opinion * The design of commons-email is flawed in a few ways and there is not a lot you can fix in a major version. So I suggest that we focus on delivered value instead Cheers, Siegfried Goeschl On 12.12.12 15:06, sebb wrote: On 12 December 2012 13:17, Gary Gregory wrote: On Wed, Dec 12, 2012 at 3:59 AM, Thomas Neidhart wrote: On Wed, Dec 12, 2012 at 4:58 AM, Gary Gregory wrote: Thank you for doing another RC. While I was digging for a justification of the Clirr errors, I found this in the release notes: "Clirr reports several errors for this release due to moving constants from the Email class to the newly introduced EmailConstants interface. These changes are guaranteed to be binary compatible." Is it really binary compatible? What if I use reflection to access the constant on Email, will the reflection call be redirected to EmailConstants? There's unit test for ya ;) Using an interface to define constants is a no-no in my book. I've seen this discussed before in other places and for a long time, but to summarize, I see an interface as defining a contract for a class to implement. A constant does not fit. Constants in interface feels like a hack to provide the short hand of a class implementing an interface just to be able to access the constants without qualifying them with a type. Not nice design IMO and a dubious us of an interface, very Java 1.0. It seems that static imports is another attempt to solve this desire for a short hand to use constants. What to do? Move the constants back to their 1.2? What's so bad about that? Hm... Make the EmailConstants a class instead of an interface? If binary compatible is broken, the constants have to move back, and you can still have a new EmailConstants class and deprecate the old constants to point to the new class. Maybe I'll see this more clearly in the AM... Interested in you all's feedback. Hi Gary, well, I think we go in circles with this change ;-). I assumed that this topic is settled after reading the comment from sebb in the RC2 thread (see http://markmail.org/message/svrb7nf3ocz7lgmd). Otoh, it's the first time I see constants in an interface and would be in favor of reverting to the previous version (also because I do not fully understand the rationale behind the change, some of the constants are not even used and thus have been deprecated). -- Maybe we should postpone this kind of refactoring to 2.0 and do it then in a proper way. Introducing this interface just created headaches and I also had to disable some checks (e.g. InterfaceIsAType in checkstyle) because of it. That sounds like a good way to go to get 1.3 out the door. Agreed. Gary Thomas On Tue, Dec 11, 2012 at 5:24 PM, Thomas Neidhart wrote: Hi, I would like to call a vote from commons-email-1.3 based on RC5. This release candidate has the following changes compared to RC4 +) update index and building page with correct information wrt Java compatibility +) update release notes with info on Java compatibility and Clirr errors +) fix svn:keywords for all source files and remove use of $Date$ tags +) add $Id$ tags for all newly introduced source files in 1.3 +) update javax.mail.mail dependency to 1.4.5 +) fix PMD warnings and add NOPMD comment for false positives +) added findbugs exclude filter for false positives +) fix release date in changes.xml +) correctly removed *.asc.[md5,sha1] files from Nexus staging area The files: The artifacts are deployed to Nexus: https://repository.apache.org/content/repositories/orgapachecommons-137/ The tag: https://svn.apache.org/repos/asf/commons/proper/email/tags/EMAIL_1_3_RC5/ The site: http://people.apache.org/builds/commons/email/1.3/RC5/ Additional Notes: o the download page and api links to older releases only work on the published site and will be corrected after release. Please take a look at the commons-email-1.3 artifacts and vote! [ ] +1 release it [ ] +0 go ahead I don't care [ ] -1 no, do not release it because Vote will remain open for at least 72 hours. Thanks in advance, Thomas - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0 Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly
Re: [email] release 1.3?
Hi Thomas, I would be very happy if someone would push a release ... :-) Cheers, Siegfried Goeschl For the records : http://www.mail-archive.com/dev@commons.apache.org/msg31265.html On 09.12.12 16:10, Thomas Neidhart wrote: Hi, the last release of email is already some time ago (2009-10-26), but there are lots of changes in trunk that would be worthwhile to be released: * 21 bugfixes * 8 new features Additionally, the trunk has been upgraded to JDK 1.5 and all checkstyle warnings have been fixed (2 remaining findbugs warnings though). The warnings reported by Clirr are safe and binary compatibility with the 1.2 release has been verified already. Afaik, there was an attempt to release 1.3 a few months ago, but it was not successful due to reasons I am not aware of. So, what do you think? 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
Re: Retiring as Apache Commons Committer and PMC
Hi folks, I actually took my break already ... :-) The problem is that I'm too old-fashioned - being a Commons Committer and PMC also comes with certain responsibilities and I'm currently unable to fulfill the responsibilities properly. And this is exactly the point in time when you should go emeritus ... :) Cheers, Siegfried Goeschl On 01.11.12 14:56, Simone Tripodi wrote: +1 http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Thu, Nov 1, 2012 at 2:26 PM, James Carman wrote: Luc, can we let him respond first? If he decides to just "take a break" as opposed to officially resigning (or going emeritus), then we don't need to vote him back in and what not. On Thu, Nov 1, 2012 at 9:23 AM, Luc Maisonobe wrote: Le 01/11/2012 12:48, Siegfried Goeschl a écrit : Hi folks, Hi Siegfried, due to some unwelcome changes in my private life I want/need to retire from most of my Apache activities - in this case * Apache Commons Committer * Apache Commons PMC I am really sorry to hear that. I wish you the best and hope you will come back one day. I enjoyed the time and hope someone will step up to further maintain commons-email and commons-exec Cheers, Siegfried Goeschl Former Release Candidate Manager PS: Luc - Any other actions I need to take No, don't worry. I'll notify board about PMC changes. best regards, Luc - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[Cancelled] [VOTE] Release of commons-email-1.3 based on RC3
Hi folks, the vote is cancelled +1 votes : none +0 votes : none -1 votes : none The following issues were identified by Oliver Heger * commons-email-1.3.jar from the binary distribution does not contain the license and NOTICE files in its META-INF folder. * The binary distribution lacks the apidocs Both issues are somehow Maven-related so I will cut a new RC next week Cheers, Siegfried Goeschl On 04.05.12 17:31, Siegfried Goeschl wrote: Hi, I would like to call a vote from commons-email-1.3 based on RC3 Changes in this version include: New features: o Update the current trunk to be binary compatible with the commons-email-1.2 release. Issue: EMAIL-111. Thanks to Florian Pirchner. o Added unit test to ensure that parsing the broken mime message does not cause an OutOfMemoryException. Issue: EMAIL-110. Thanks to Thomas Pummer. o HtmlmageEmail should support class path resources Issue: EMAIL-108. Thanks to Elisabeth Kasimir, Alexander Kasimir. o Added a MultiPartEmail.attach(File) method since attaching a file is a simple and common. o Added MimeMessageParser and MimeMessageUtils. Fixed Bugs: o DataSourceFileResolverTest fails under IBM JDK 1.4 and 1.6 running on Windows. Issue: EMAIL-112. Thanks to Peter Kofler. o Maven Site fails with error in Checkstyle configuration. Issue: EMAIL-113. Thanks to Peter Kofler. o The patch actually broke sending emails over a secured connection - disabled the "MAIL_SMTP_SSL_CHECKSERVERIDENTITY" and "MAIL_SMTP_SSL_ENABLE" activation. Tested the functionality using GMail, GMX and Office365 so the code is at least working for a couple of existing SMTP servers. Also added 'sslCheckServerIdentity' including setter and getter. Also added a chapter regarding "Security" to the user manual. Issue: EMAIL-105. Thanks to Siegfried Goeschl. o Added mime.types to META-INF - the definition is actually found in activation.jar but did not work. Issue: EMAIL-107. Thanks to Claus Polanka, Michael Jakl. o STARTTLS can be used even without authenticator. Issue: EMAIL-106. Thanks to Bruno Harbulot. o Clarified the meaning of setTLS() which actually sends a "STARTTLS" command from the client to the SMTP server. Please note that some "protected" variables were renamed which could break existing code. Issue: EMAIL-105. Thanks to Bruno Harbulot. o Fixed HtmlEmail embed toLowerCase bug with Turkish locale. Issue: EMAIL-102. Thanks to Okan Özeren. o Specified Content-ID is now used when embedding a File object in an HtmlEmail. Issue: EMAIL-101. Thanks to Andrew Starodub. o Restore Java 1.4 compatibility. o Throwing an IllegalStateException when setting mail session properties for an already created mail session because the settings would be ignored. Please note that this change could potentially break existing (but invalid) code. Issue: EMAIL-96. o Encoding and folding of headers is now done by commons-email. Issue: EMAIL-98. Thanks to Mario Daepp. o The default connection timeout is set to a reasonable default value of 60 seconds. Issue: EMAIL-100. Thanks to David Parks. o Moving the various constants from 'EMail' to 'EmailConstants' o All setters are returning "this" to simplify building an email. Issue: EMAIL-76. Thanks to Yu Kobayashi. o Adding ImageHtmlEmail to create HTML emails with embedded images either downloaded from HTTP or from the local file system. Issue: EMAIL-92. Thanks to Dominik Stadler. o Calling buildMimeMessage() before invoking send() caused duplicated mime parts for HtmlEmail. The implementation now enforces that an email can be only used once and throw an exception when multiple invocations of buildMimeMessage() are detected. Issue: EMAIL-95. o Incorrect SMTP Port number shown in error message when an email fails to send due to a blocked port and SSL is used. Issue: EMAIL-91. Thanks to Kevin Lester. The files: The artifacts are deployed to Nexus [1] (and [2]). The tag: http://svn.apache.org/viewvc/commons/proper/email/tags/EMAIL_1_3_RC3/ The site: http://people.apache.org/builds/commons/email/1.3/RC3/site/ Additional Notes: o the RC is binary compatible to commons-email-1.2 whereas the remaining Clirr warnings stem from moving constants to an interface Please take a look at the commons-email-1.3 artifacts and vote! Please note: This vote is "majority approval" with a minimum of three +1 votes (see [3]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks in advance, Siegfried Goeschl [1] https://repository.apache.org/content/repositories/orgapachecommons-095/ [2] https://repository.apache.org/content/repositories/orgapachecommons-095/org/apache/commons/commons-email/1.3
Re: [VOTE] Release of commons-email-1.3 based on RC3
Hi Oliver, thanks for checking the RC 1) missing LICENSE.txt & NOTICE.txt - This is actually handled by commons-parent-24.pom in the resource section and should work out-of-the-box. Having said that it does not work for commons-email - currently investigating. 2) Clirr Warnings - We get CLIRR warnings due to moving constants from Email.java to EmailConstants.java. This refactoring actually maintains source and binary compatibility Some other changes (changing return value) were reverted to avoid having a major release so the Clirr warnings are false positives. 3) Minimalistic Binary Distribution - Mhmm, according to the "bin" assembly descriptor that should be the case since it includes "target/site/apidocs". I checked the build and the I think the javadoc was simply not generated at the the time the binary distribution was built - please note that both plugins are executed at the "package" phase and I'm not sure if Maven make guarantees in which order the plugins are executed assuming that they are assigned to the exactly the same life-cycle phase. Cheers, Siegfried Goeschl On 06.05.12 18:55, Oliver Heger wrote: Hi, build worked for me with Java 1.5 and 1.6 on Windows 7. However, I found the following problems: - commons-email-1.3.jar from the binary distribution does not contain the license and NOTICE files in its META-INF folder. - The clirr report contains 29 errors. I did not follow discussions during development of [email], so I don't know whether this is a problem for users or not. However, I would at least expect that incompatible changes are clearly stated in the release notes. - The binary distribution is pretty minimalistic. Other commons components typically ship the Javadocs and other artifacts like the sources jar. (Maybe not a major problem, but it would be nice if we were more consistent within Commons.) - Minor nit: Could the source distribution deflate in a different directory than the binary one? Is it possible with our current Common Parent setup to test the release with Maven 3 on a JDK 1.4? When I run mvn package -P java-1.4 I get the following error: java.lang.UnsupportedClassVersionError: org/apache/maven/surefire/junit/JUnit3Pr ovider (Unsupported major.minor version 49.0) at java.lang.ClassLoader.defineClass0(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:539) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:12 3) at java.net.URLClassLoader.defineClass(URLClassLoader.java:251) at java.net.URLClassLoader.access$100(URLClassLoader.java:55) at java.net.URLClassLoader$1.run(URLClassLoader.java:194) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:187) at java.lang.ClassLoader.loadClass(ClassLoader.java:289) at java.lang.ClassLoader.loadClass(ClassLoader.java:235) at org.apache.maven.surefire.booter.IsolatedClassLoader.loadClass(Isolat edClassLoader.java:97) at org.apache.maven.surefire.util.ReflectionUtils.loadClass(ReflectionUt ils.java:228) at org.apache.maven.surefire.util.ReflectionUtils.instantiateOneArg(Refl ectionUtils.java:128) at org.apache.maven.surefire.booter.SurefireReflector.instantiateProvide r(SurefireReflector.java:239) at org.apache.maven.surefire.booter.ProviderFactory.createProvider(Provi derFactory.java:122) at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(Provi derFactory.java:81) at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(Fork edBooter.java:103) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java: 74) Oliver Am 04.05.2012 17:31, schrieb Siegfried Goeschl: Hi, I would like to call a vote from commons-email-1.3 based on RC3 Changes in this version include: New features: o Update the current trunk to be binary compatible with the commons-email-1.2 release. Issue: EMAIL-111. Thanks to Florian Pirchner. o Added unit test to ensure that parsing the broken mime message does not cause an OutOfMemoryException. Issue: EMAIL-110. Thanks to Thomas Pummer. o HtmlmageEmail should support class path resources Issue: EMAIL-108. Thanks to Elisabeth Kasimir, Alexander Kasimir. o Added a MultiPartEmail.attach(File) method since attaching a file is a simple and common. o Added MimeMessageParser and MimeMessageUtils. Fixed Bugs: o DataSourceFileResolverTest fails under IBM JDK 1.4 and 1.6 running on Windows. Issue: EMAIL-112. Thanks to Peter Kofler. o Maven Site fails with error in Checkstyle configuration. Issue: EMAIL-113. Thanks to Peter Kofler. o The patch actually broke sending emails over a secured connection - disabled the "MAIL_SMTP_SSL_CHECKSERVERIDENTITY" and "MAIL_SMTP_SSL_ENABLE
[VOTE] Release of commons-email-1.3 based on RC3
Hi, I would like to call a vote from commons-email-1.3 based on RC3 Changes in this version include: New features: o Update the current trunk to be binary compatible with the commons-email-1.2 release. Issue: EMAIL-111. Thanks to Florian Pirchner. o Added unit test to ensure that parsing the broken mime message does not cause an OutOfMemoryException. Issue: EMAIL-110. Thanks to Thomas Pummer. o HtmlmageEmail should support class path resources Issue: EMAIL-108. Thanks to Elisabeth Kasimir, Alexander Kasimir. o Added a MultiPartEmail.attach(File) method since attaching a file is a simple and common. o Added MimeMessageParser and MimeMessageUtils. Fixed Bugs: o DataSourceFileResolverTest fails under IBM JDK 1.4 and 1.6 running on Windows. Issue: EMAIL-112. Thanks to Peter Kofler. o Maven Site fails with error in Checkstyle configuration. Issue: EMAIL-113. Thanks to Peter Kofler. o The patch actually broke sending emails over a secured connection - disabled the "MAIL_SMTP_SSL_CHECKSERVERIDENTITY" and "MAIL_SMTP_SSL_ENABLE" activation. Tested the functionality using GMail, GMX and Office365 so the code is at least working for a couple of existing SMTP servers. Also added 'sslCheckServerIdentity' including setter and getter. Also added a chapter regarding "Security" to the user manual. Issue: EMAIL-105. Thanks to Siegfried Goeschl. o Added mime.types to META-INF - the definition is actually found in activation.jar but did not work. Issue: EMAIL-107. Thanks to Claus Polanka, Michael Jakl. o STARTTLS can be used even without authenticator. Issue: EMAIL-106. Thanks to Bruno Harbulot. o Clarified the meaning of setTLS() which actually sends a "STARTTLS" command from the client to the SMTP server. Please note that some "protected" variables were renamed which could break existing code. Issue: EMAIL-105. Thanks to Bruno Harbulot. o Fixed HtmlEmail embed toLowerCase bug with Turkish locale. Issue: EMAIL-102. Thanks to Okan Özeren. o Specified Content-ID is now used when embedding a File object in an HtmlEmail. Issue: EMAIL-101. Thanks to Andrew Starodub. o Restore Java 1.4 compatibility. o Throwing an IllegalStateException when setting mail session properties for an already created mail session because the settings would be ignored. Please note that this change could potentially break existing (but invalid) code. Issue: EMAIL-96. o Encoding and folding of headers is now done by commons-email. Issue: EMAIL-98. Thanks to Mario Daepp. o The default connection timeout is set to a reasonable default value of 60 seconds. Issue: EMAIL-100. Thanks to David Parks. o Moving the various constants from 'EMail' to 'EmailConstants' o All setters are returning "this" to simplify building an email. Issue: EMAIL-76. Thanks to Yu Kobayashi. o Adding ImageHtmlEmail to create HTML emails with embedded images either downloaded from HTTP or from the local file system. Issue: EMAIL-92. Thanks to Dominik Stadler. o Calling buildMimeMessage() before invoking send() caused duplicated mime parts for HtmlEmail. The implementation now enforces that an email can be only used once and throw an exception when multiple invocations of buildMimeMessage() are detected. Issue: EMAIL-95. o Incorrect SMTP Port number shown in error message when an email fails to send due to a blocked port and SSL is used. Issue: EMAIL-91. Thanks to Kevin Lester. The files: The artifacts are deployed to Nexus [1] (and [2]). The tag: http://svn.apache.org/viewvc/commons/proper/email/tags/EMAIL_1_3_RC3/ The site: http://people.apache.org/builds/commons/email/1.3/RC3/site/ Additional Notes: o the RC is binary compatible to commons-email-1.2 whereas the remaining Clirr warnings stem from moving constants to an interface Please take a look at the commons-email-1.3 artifacts and vote! Please note: This vote is "majority approval" with a minimum of three +1 votes (see [3]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why...... Thanks in advance, Siegfried Goeschl [1] https://repository.apache.org/content/repositories/orgapachecommons-095/ [2] https://repository.apache.org/content/repositories/orgapachecommons-095/org/apache/commons/commons-email/1.3/commons-email-1.3-source-release.zip [3] http://www.apache.org/foundation/voting.html#ReleaseVotes - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[email] Preparing RC3 for commons-email
Hi folks, I'm preparing a RC3 for commons-email-1.3 - please don't make any commits to trunk ... :-) Thanks in advance Siegfried RC Goeschl - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Promote [csv] to Commons proper
+1 Siegfried Goeschl On 06.03.12 18:42, Emmanuel Bourg wrote: Commons CSV is approaching a releasable state. Considering the general interest in this component I think it's time to promote it to Commons proper. There are a few points I'd like to address before a release: - Handle CSV headers, a CSV API looks incomplete to me without this - Examine the feasibility of adding a simple bean mapping feature - Extract the unicode unescaping feature as an implementation of java.io.Reader, and maybe contribute it to Commons IO - Improve the documentation [ ] +1 Promote it! [ ] -1 Let it crawl in the sandbox because... Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: When to create a new major release - Was [VOTE][CANCEL] The vote for commons-email-1.3 based on RC2 in cancelled
Hi folks, I think the best for commons-email-1.3 will be reverting the changes of the setters from Email setXXX(arg) to void setXXX(arg) which in turn gives me binary backward compatibility. I would like to see a commons-email-1.3 out there which gives me time to work on 2.0 Cheers, Siegfried Goeschl On 10.01.12 19:19, sebb wrote: On 10 January 2012 16:45, Siegfried Goeschl wrote: Hi folks, the main reason for the failed vote of commons-email-1.3 is that the release is only source but not binary compatible +) if you compile your application with the new version everything is fine +) if you replace simply the JAR the invocation fails Is it mandatory that a minor release is binary compatible with the previous one or do I have to create a new major version? There is a lot of ugly stuff (mainly protected member variables) which should be done but is currently not in the scope of this release. If the jar is not a drop-in replacement for the previous version, then yes, IMO that requires a major release. [1] The only possible exception might be if the incompatibilities are in internal parts of the API, i.e. classes/methods etc. that are not used externally. Note also that a binary incompatibility involving the external API will also require the package name to be changed (which in turn requires the Maven coordinates to be changed). The package name change is required because there can be only one instance of a class in a single class loader. See discussion here [2] [1] http://commons.apache.org/releases/versioning.html [2] http://wiki.apache.org/commons/MavenGroupIDChange#Classpath_considerations Feedback appreciated Siegfried Goeschl - 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
When to create a new major release - Was [VOTE][CANCEL] The vote for commons-email-1.3 based on RC2 in cancelled
Hi folks, the main reason for the failed vote of commons-email-1.3 is that the release is only source but not binary compatible +) if you compile your application with the new version everything is fine +) if you replace simply the JAR the invocation fails Is it mandatory that a minor release is binary compatible with the previous one or do I have to create a new major version? There is a lot of ugly stuff (mainly protected member variables) which should be done but is currently not in the scope of this release. Feedback appreciated Siegfried Goeschl - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] graduate [graph] as a proper component
+1 Siegfried Goeschl On 18.12.11 21:12, Simone Tripodi wrote: Hi all, Since I proposed[1] to resurrect commons-graph from dormant to sandbox, there's been not only my personal activity, but we have recorded a good number of discussions on the ML and received contributions on JIRA[2], involving not only PMC such as James but also from users, such as Claudio Squarcella, Matthew Pococ and Marco Speranza. I think we have now, including users that took part with the unbinding vote in the proposal, a good number of people interested in this commons component and see it released, that's why today I'm calling for a vote to accept it in the propers. So please cast your vote! [ ] +1 Accept [graph] as a proper component [ ] +/- 0 uhm... [ ] -1 Don't accept it - and please explain why Open will stay open for 72h and closes on Wed 21th, 8:15 PM CET. Many thanks in advance, all the best! -Simo [1] http://markmail.org/message/mlvqiqhqm2nqhofr [2] SANDBOX-334 SANDBOX-336 SANDBOX-338 SANDBOX-332 SANDBOX-333 SANDBOX-335 SANDBOX-337 SANDBOX-344 SANDBOX-345 http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE][CANCEL] The vote for commons-email-1.3 based on RC2 in cancelled
Hi folks,
I ran the commons-email-1.2 test suite with commons-email-1.3 and got
[junit] Running org.apache.commons.mail.EmailTest
[junit] Testsuite: org.apache.commons.mail.EmailTest
[junit] Tests run: 39, Failures: 0, Errors: 17, Time elapsed: 0.252 sec
[junit] Tests run: 39, Failures: 0, Errors: 17, Time elapsed: 0.252 sec
[junit] Testcase: testGetSetSession took 0.012 sec
[junit] Caused an ERROR
[junit]
org.apache.commons.mail.mocks.MockEmailConcrete.setMailSession(Ljavax/mail/Session;)V
[junit] java.lang.NoSuchMethodError:
org.apache.commons.mail.mocks.MockEmailConcrete.setMailSession(Ljavax/mail/Session;)V
[junit] at
org.apache.commons.mail.EmailTest.testGetSetSession(EmailTest.java:108)
Well, had another run with some other code getting
ests run: 11, Failures: 0, Errors: 10, Skipped: 0, Time elapsed: 0.451
sec <<< FAILURE!
testDefaultDomain(org.apache.fulcrum.commonsemail.CommonsEmailServiceTest)
Time elapsed: 0.147 sec <<< ERROR!
java.lang.NoSuchMethodError:
org.apache.commons.mail.Email.setAuthentication(Ljava/lang/String;Ljava/lang/String;)V
at
org.apache.fulcrum.commonsemail.impl.CommonsEmailServiceImpl.configure(CommonsEmailServiceImpl.java:1007)
at
org.apache.fulcrum.commonsemail.impl.CommonsEmailServiceImpl.createSimpleEmail(CommonsEmailServiceImpl.java:285)
at
org.apache.fulcrum.commonsemail.CommonsEmailServiceTest.testDefaultDomain(CommonsEmailServiceTest.java:274)
So Sebastian was right ...
+) changing the return type from "void" to something else breaks binary
compatibility
+) moving the constants from Email to EmailConstants.java was had no impact
Sebastian, kudos given ... :-)
Cheers,
Siegfried Goeschl
On 11.12.11 22:06, Siegfried Goeschl wrote:
Hi folks,
reviewing the release candidate showed a few problems/discussion points
1) Moving constant from Email.java to EmailConstants,java
==
I made the following change
+) adding EmailConstants
+) Email implements EmailConstants
public interface EmailConstants {}
public abstract class Email implements EmailConstants {}
We have different opinions out there
+) Gary - in general unhappy about an interface containing constants
only, and see issues with source code and binary compatibility
+) Sebastian - sees no issues with binary compatibility
+) I personally don't see any issues otherwise I would not have made the
change
2) Renaming of protected fields
==
The code exposes every field as protected which makes me unhappy since
the same filed could be accessed using a getter/setter as well. Due to
EMAIL-105 (https://issues.apache.org/jira/browse/EMAIL-105) I renamed
two protected fields on order to clarify the behavior
* tls ==> startTlsEnabled
* ssl ==> sslOnConnect
The original getters/setters are still there but deprecated now
+) Sebastian pointed out that this breaks binary compatibility
+) I think along the lines that the protected fields should not be used
at all if there is a getter/setter available
The question - does this change requires a new major release?
3) Return type of setters changed from "void" to "this"
==
I changed the return type of setters to support something like this
email.setMailSession()setDebug().setContent();
instead of
email.setMailSession();
email.setDebug();
email.setContent();
+) Sebastian pointed out that this breaks binary compatibility (a
similar issues happened in commons-io)
+) based on my knowledge I doubt that but have to admit that Sebastian
knows a lot of things better than I do ... :-)
I thing the way to go is to run the commons-email-1.2 test suite with
commons-email-1.3 and to report the result
4) The source zip is missing
==
No discussions about that ... :-)
5) OS-dependency in DataSourceFileResolverTest.testResolvingFileLenient
==
No discussions about that ... :-)
6) RAT Complaints
==
The "mime.type" and four test email messages have no ASL - with the
newest commons-parent it should be possible to exclude files from RAT
I'm sort of stuck here - IMHO the changes regarding 1), 2) and 3) are
not big enough to justify a new major release whereas the library has
enough rough edges to look forward an clean-up and major release. But
for doing that I simple have not enough time for the next weeks ... any
opinions out there?
Cheers,
Siegfried Goeschl
-
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
[VOTE][CANCEL] The vote for commons-email-1.3 based on RC2 in cancelled
Hi folks,
reviewing the release candidate showed a few problems/discussion points
1) Moving constant from Email.java to EmailConstants,java
==
I made the following change
+) adding EmailConstants
+) Email implements EmailConstants
public interface EmailConstants {}
public abstract class Email implements EmailConstants {}
We have different opinions out there
+) Gary - in general unhappy about an interface containing constants
only, and see issues with source code and binary compatibility
+) Sebastian - sees no issues with binary compatibility
+) I personally don't see any issues otherwise I would not have made the
change
2) Renaming of protected fields
==
The code exposes every field as protected which makes me unhappy since
the same filed could be accessed using a getter/setter as well. Due to
EMAIL-105 (https://issues.apache.org/jira/browse/EMAIL-105) I renamed
two protected fields on order to clarify the behavior
* tls ==> startTlsEnabled
* ssl ==> sslOnConnect
The original getters/setters are still there but deprecated now
+) Sebastian pointed out that this breaks binary compatibility
+) I think along the lines that the protected fields should not be used
at all if there is a getter/setter available
The question - does this change requires a new major release?
3) Return type of setters changed from "void" to "this"
==
I changed the return type of setters to support something like this
email.setMailSession()setDebug().setContent();
instead of
email.setMailSession();
email.setDebug();
email.setContent();
+) Sebastian pointed out that this breaks binary compatibility (a
similar issues happened in commons-io)
+) based on my knowledge I doubt that but have to admit that Sebastian
knows a lot of things better than I do ... :-)
I thing the way to go is to run the commons-email-1.2 test suite with
commons-email-1.3 and to report the result
4) The source zip is missing
==
No discussions about that ... :-)
5) OS-dependency in DataSourceFileResolverTest.testResolvingFileLenient
==
No discussions about that ... :-)
6) RAT Complaints
==
The "mime.type" and four test email messages have no ASL - with the
newest commons-parent it should be possible to exclude files from RAT
I'm sort of stuck here - IMHO the changes regarding 1), 2) and 3) are
not big enough to justify a new major release whereas the library has
enough rough edges to look forward an clean-up and major release. But
for doing that I simple have not enough time for the next weeks ... any
opinions out there?
Cheers,
Siegfried Goeschl
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE][email] Release Commons Email 1.3 based on RC2
Hi Sebastian,
thanks for your help - I will look at commons-email over the weekend.
Cheers,
Siegfried Goeschl
On 08.12.11 00:28, sebb wrote:
On 7 December 2011 16:10, sebb wrote:
On 6 December 2011 15:38, Siegfried Goeschl wrote:
Hi Gary,
ad RAT - I added a license header for "mime.types" but doing this for the
mail messages is not possible AFAIK since there is no such thing as a
comment for mail messages
Did you try using # as the comment marker?
Works for me.
ad src zip - need to check since I did a last minute upgrade to the latest
commons-parent.pom
ad Clirr errors - this reported errors are stemming from two changes
1) I introduced an "EmailConstants.java" to collect all the constants and
Email implements EmailConstants
Not sure about that one, I'll check.
It may be a false positive as far as binary compatibility is
concerned, but it certainly breaks source compatibility and should be
clearly documented in the release notes.
Constants are OK to remove, because the Java compiler inlines them.
However, mutable fields are not OK to remove unless they are
guaranteed not to be used by user code.
The protected fields ssl and tls have been removed from the Email class.
2) the setter methods of Email return now consistently "this" instead of
void
This definitely breaks binary compatibilty; we had a similar issue in
Commons IO.
The JVM includes the return type in the method signature when
resolving references; changing the return type will cause "method not
found" or similar.
IMHO both changes do not break binary compatibility for the minor release
Sorry, not true.
==
Also just discovered a test failure when compiling and testing on Win/XP:
testResolvingFileLenient(org.apache.commons.mail.resolver.DataSourceFileResolverTest)
Time elapsed: 0 sec<<< FAILURE!
junit.framework.AssertionFailedError:
at junit.framework.Assert.fail(Assert.java:47)
at junit.framework.Assert.assertTrue(Assert.java:20)
at junit.framework.Assert.assertNull(Assert.java:230)
at
org.apache.commons.mail.resolver.DataSourceFileResolverTest.testResolvingFileLenient(DataSourceFileResolverTest.java:50)
Appears to be due to an OS-specific bug in DataSource resolver.
It checks if the resource "/images/asf_logo_wide.gif" is absolute.
Unfortunately File("/images/asf_logo_wide.gif") is not absolute on
Windows:
On Microsoft Windows systems, a pathname is absolute if its prefix is
a drive specifier followed by "\\", or if its prefix is "\\".
Cheers,
Siegfried Goeschl
On 05.12.11 23:11, Gary Gregory wrote:
Hi Siegfried:
Thank you for preparing the RC.
This /sounds/ worrisome from RAT:
Unapproved licenses:
src/resources/META-INF/mime.types
src/test/eml/attachment-only.eml
src/test/eml/html-attachment.eml
src/test/eml/multipart-report.eml
src/test/eml/simple-reply.eml
src/test/eml/simple.eml
Where is the 'src' zip I can build from?
Looks like there are three easy to fix checkstyle errors (not the
missing Javadocs.)
-1: Can you justify the 51 Clirr errors in a minor release?
Our current guideline is that such a change means a major version and
new package. I do not care which way we go but we should be mindful of
binary compatibility for minor release.
Thank you,
Gary
On Mon, Dec 5, 2011 at 4:31 PM, Siegfried Goeschlmailto:sgoes...@gmx.at>> wrote:
Hi folks,
I would like to call a vote to release commons-email-1.3 which
contains the following bug fixes and improvements found here
http://people.apache.org/__builds/commons/email/1.3/RC2/__site/changes-report.html
<http://people.apache.org/builds/commons/email/1.3/RC2/site/changes-report.html>
Tag:
https://svn.apache.org/repos/__asf/commons/proper/email/tags/__EMAIL_1_3_RC2
<https://svn.apache.org/repos/asf/commons/proper/email/tags/EMAIL_1_3_RC2>
Site:
http://people.apache.org/__builds/commons/email/1.3/RC2/__site/index.html
<http://people.apache.org/builds/commons/email/1.3/RC2/site/index.html>
Binaries:
http://people.apache.org/__builds/commons/email/1.3/RC2/__staged/org/apache/commons/__commons-email/1.3/
<http://people.apache.org/builds/commons/email/1.3/RC2/staged/org/apache/commons/commons-email/1.3/>
[ ] +1 release it
[ ] +0 go ahead I don't care
[ ] -1 no, do not release it because
Thanks in advance
Siegfried Goeschl
--__--__-
To unsubscribe, e-mail: dev-unsubscribe@commons.__apache.org
<mailto:dev-unsubscr...@commons.apache.org>
For additional commands, e-mail: dev-h...@commons.apache.org
<mailto:dev-h...@commons.apache.org>
--
E-Mail: garydgreg...@gmail.com<mailto:garydgreg...@gmail.com> |
ggreg...@apache.org<mailto:ggreg...@
Re: [VOTE][email] Release Commons Email 1.3 based on RC2
Hi Stefan, sounds good - I will check Siegfried Goeschl On 06.12.11 16:52, Stefan Bodewig wrote: On 2011-12-06, Siegfried Goeschl wrote: ad RAT - I added a license header for "mime.types" but doing this for the mail messages is not possible AFAIK since there is no such thing as a comment for mail messages Since you use the latest Commons parent you now have access to RAT 0.7 (I think) which allows you to exclude files that you know cannot contain a license. Stefan - 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: [VOTE][email] Release Commons Email 1.3 based on RC2
Hi Gary,
ad RAT - I added a license header for "mime.types" but doing this for
the mail messages is not possible AFAIK since there is no such thing as
a comment for mail messages
ad src zip - need to check since I did a last minute upgrade to the
latest commons-parent.pom
ad Clirr errors - this reported errors are stemming from two changes
1) I introduced an "EmailConstants.java" to collect all the constants
and Email implements EmailConstants
2) the setter methods of Email return now consistently "this" instead of
void
IMHO both changes do not break binary compatibility for the minor release
Cheers,
Siegfried Goeschl
On 05.12.11 23:11, Gary Gregory wrote:
Hi Siegfried:
Thank you for preparing the RC.
This /sounds/ worrisome from RAT:
Unapproved licenses:
src/resources/META-INF/mime.types
src/test/eml/attachment-only.eml
src/test/eml/html-attachment.eml
src/test/eml/multipart-report.eml
src/test/eml/simple-reply.eml
src/test/eml/simple.eml
Where is the 'src' zip I can build from?
Looks like there are three easy to fix checkstyle errors (not the
missing Javadocs.)
-1: Can you justify the 51 Clirr errors in a minor release?
Our current guideline is that such a change means a major version and
new package. I do not care which way we go but we should be mindful of
binary compatibility for minor release.
Thank you,
Gary
On Mon, Dec 5, 2011 at 4:31 PM, Siegfried Goeschl mailto:sgoes...@gmx.at>> wrote:
Hi folks,
I would like to call a vote to release commons-email-1.3 which
contains the following bug fixes and improvements found here
http://people.apache.org/__builds/commons/email/1.3/RC2/__site/changes-report.html
<http://people.apache.org/builds/commons/email/1.3/RC2/site/changes-report.html>
Tag:
https://svn.apache.org/repos/__asf/commons/proper/email/tags/__EMAIL_1_3_RC2
<https://svn.apache.org/repos/asf/commons/proper/email/tags/EMAIL_1_3_RC2>
Site:
http://people.apache.org/__builds/commons/email/1.3/RC2/__site/index.html
<http://people.apache.org/builds/commons/email/1.3/RC2/site/index.html>
Binaries:
http://people.apache.org/__builds/commons/email/1.3/RC2/__staged/org/apache/commons/__commons-email/1.3/
<http://people.apache.org/builds/commons/email/1.3/RC2/staged/org/apache/commons/commons-email/1.3/>
[ ] +1 release it
[ ] +0 go ahead I don't care
[ ] -1 no, do not release it because
Thanks in advance
Siegfried Goeschl
--__--__-
To unsubscribe, e-mail: dev-unsubscribe@commons.__apache.org
<mailto:dev-unsubscr...@commons.apache.org>
For additional commands, e-mail: dev-h...@commons.apache.org
<mailto:dev-h...@commons.apache.org>
--
E-Mail: garydgreg...@gmail.com <mailto:garydgreg...@gmail.com> |
ggreg...@apache.org <mailto:ggreg...@apache.org>
JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com <http://garygregory.wordpress.com/>
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
[VOTE][email] Release Commons Email 1.3 based on RC2
Hi folks, I would like to call a vote to release commons-email-1.3 which contains the following bug fixes and improvements found here http://people.apache.org/builds/commons/email/1.3/RC2/site/changes-report.html Tag: https://svn.apache.org/repos/asf/commons/proper/email/tags/EMAIL_1_3_RC2 Site: http://people.apache.org/builds/commons/email/1.3/RC2/site/index.html Binaries: http://people.apache.org/builds/commons/email/1.3/RC2/staged/org/apache/commons/commons-email/1.3/ [ ] +1 release it [ ] +0 go ahead I don't care [ ] -1 no, do not release it because Thanks in advance Siegfried Goeschl - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Rejoin the PMC...
But it is good to see the all the "grandpa's" returning :-) Siegfried Goeschl On 24.05.11 11:06, Christian Grobmeier wrote: wrote: Since my work life is changing, I may just have more cycles to devote to my role as a PMC member. I would like to re-join the PMC. What is the process? Hopefully its just a case of asking, as you have done. If not, we should change the way it is. I have just read through: http://www.apache.org/dev/pmc.html#karma http://www.apache.org/dev/pmc.html#newpmc There is nothing about the reactivation of a grandpa, but it seems the PMC can decide freely (and I am for "just ask"). I only suggest the Chair should inform the board. That being said, welcome back James :-) And good luck with your job search Cheers, 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: [exec] Use of System.out in unit tests
Hi folks, I understand your motivation but the output is helpful in understanding problems when the regression tests are executed on an arbitrary machine - assume that you have an exotic server where you would like to test commons-exec without development tools. The output is the only hint I get in order to fix the problems 0 : if you the output can be enabled/disabled -1 : deleting the output Cheers, Siegfried Goeschl On 04.02.11 08:34, Jörg Schaible wrote: sebb wrote: On 3 February 2011 21:02, Gary Gregory wrote: Hi All, I see a lot of noise on the console when running [exec] unit tests (from Maven, Eclipse, and so on.) I would like to remove calls to System.out from the unit tests. IMO, unit tests should assert all they need and put any error information in assert messages, not the console. Thoughts? +1 to removing any console output that does not add anything useful. Definitely +1 - Jörg - 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: [codec] Release 1.4.1/1.5, Release Manager for 1.4.1/1.5
Hi Gary, no objection from my side (the guy at the very back) ... :-) Cheers, Siegfried Goeschl On 1/16/11 10:18 PM, Gary Gregory wrote: Hi All: In accordance with http://commons.apache.org/releases/prepare.html I would like to offer my services as release manager for 1.4.1 (or 1.5 is that is more appropriate for trunk.) If you (yes, you there in the back) want to be the RM, or object to me performing this role (http://www.apache.org/foundation/glossary.html#LazyConsensus) please speak up. FWIW, I RM'd [codec] 1.3. My plan is to take what we have in trunk today and turn it into a release. My main goal is to resolve the pain of https://issues.apache.org/jira/browse/CODEC-94, one way or another. Gary Gregory Senior Software Engineer Rocket Software 3340 Peachtree Road, Suite 820 * Atlanta, GA 30326 * USA Tel: +1.404.760.1560 Email: ggreg...@seagullsoftware.com<mailto:ggreg...@seagullsoftware.com> Web: seagull.rocketsoftware.com<http://www.seagull.rocketsoftware.com/> - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[VOTE] Cancelling vote for commons-email-1.3 based on RC1
Hi folks, I would like to fix the JDK 1.4 issues and call for a new vote - and this is the last JDK 1.4 compatible release anyway Cheers, Siegfried Goeschl On 11/6/10 7:18 PM, Siegfried Goeschl wrote: +1 Siegfried Goeschl On 11/6/10 6:19 PM, Siegfried Goeschl wrote: Hi folks, I would like to call a vote to release commons-email-1.3 based on RC1 - see the release coordinates below. Tag: http://svn.apache.org/viewvc/commons/proper/email/tags/EMAIL_1_3_RC1/ Site: http://people.apache.org/builds/commons/email/1.3/RC1/site/ Binaries: http://people.apache.org/builds/commons/email/1.3/RC1/staged/org/apache/commons/commons-email/1.3/ [ ] +1 release it [ ] +0 go ahead I don't care [ ] -1 no, do not release it because Thanks in advance Siegfried Goeschl - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release commons-email-1.3 based on RC1
Hi Oliver, thanks for the hint - as a Mac OS X user I have currently a limited choice of JVMs ... :-( I'm getting the JDK 1.4 installed on my Linux image ... Cheers, Siegfried Goeschl On 11/7/10 6:28 PM, Oliver Heger wrote: Based on entries in the pom and in the manifest of the jar I expect that email should be compatible with Java 1.4. However, the build fails on a JDK 1.4 with compilation failures (see below): With StringBuilder and String.contains() classes and methods are used which are available in JDK 1.5 only. Oliver [INFO] Compilation failure \data\projects\OpenSource\email\commons-email-1.3-src\src\test\org\apache\common s\mail\HtmlEmailTest.java:[536,19] cannot resolve symbol symbol : method contains (java.lang.String) location: class java.lang.String \data\projects\OpenSource\email\commons-email-1.3-src\src\test\org\apache\common s\mail\HtmlEmailTest.java:[537,20] cannot resolve symbol symbol : method contains (java.lang.String) location: class java.lang.String \data\projects\OpenSource\email\commons-email-1.3-src\src\test\org\apache\common s\mail\ImageHtmlEmailTest.java:[80,16] cannot resolve symbol symbol : class StringBuilder location: class org.apache.commons.mail.ImageHtmlEmailTest \data\projects\OpenSource\email\commons-email-1.3-src\src\test\org\apache\common s\mail\ImageHtmlEmailTest.java:[80,40] cannot resolve symbol symbol : class StringBuilder location: class org.apache.commons.mail.ImageHtmlEmailTest \data\projects\OpenSource\email\commons-email-1.3-src\src\test\org\apache\common s\mail\ImageHtmlEmailTest.java:[106,51] cannot resolve symbol symbol : method contains (java.lang.String) location: class java.lang.String \data\projects\OpenSource\email\commons-email-1.3-src\src\test\org\apache\common s\mail\ImageHtmlEmailTest.java:[121,63] cannot resolve symbol symbol : method contains (java.lang.String) location: class java.lang.String \data\projects\OpenSource\email\commons-email-1.3-src\src\test\org\apache\common s\mail\ImageHtmlEmailTest.java:[137,63] cannot resolve symbol symbol : method contains (java.lang.String) location: class java.lang.String \data\projects\OpenSource\email\commons-email-1.3-src\src\test\org\apache\common s\mail\EmailTest.java:[1121,19] cannot resolve symbol symbol : method contains (java.lang.String) location: class java.lang.String Am 06.11.2010 18:19, schrieb Siegfried Goeschl: Hi folks, I would like to call a vote to release commons-email-1.3 based on RC1 - see the release coordinates below. Tag: http://svn.apache.org/viewvc/commons/proper/email/tags/EMAIL_1_3_RC1/ Site: http://people.apache.org/builds/commons/email/1.3/RC1/site/ Binaries: http://people.apache.org/builds/commons/email/1.3/RC1/staged/org/apache/commons/commons-email/1.3/ [ ] +1 release it [ ] +0 go ahead I don't care [ ] -1 no, do not release it because Thanks in advance Siegfried Goeschl - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release commons-email-1.3 based on RC1
+1 Siegfried Goeschl On 11/6/10 6:19 PM, Siegfried Goeschl wrote: Hi folks, I would like to call a vote to release commons-email-1.3 based on RC1 - see the release coordinates below. Tag: http://svn.apache.org/viewvc/commons/proper/email/tags/EMAIL_1_3_RC1/ Site: http://people.apache.org/builds/commons/email/1.3/RC1/site/ Binaries: http://people.apache.org/builds/commons/email/1.3/RC1/staged/org/apache/commons/commons-email/1.3/ [ ] +1 release it [ ] +0 go ahead I don't care [ ] -1 no, do not release it because Thanks in advance Siegfried Goeschl - 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
[VOTE] Release commons-email-1.3 based on RC1
Hi folks, I would like to call a vote to release commons-email-1.3 based on RC1 - see the release coordinates below. Tag: http://svn.apache.org/viewvc/commons/proper/email/tags/EMAIL_1_3_RC1/ Site: http://people.apache.org/builds/commons/email/1.3/RC1/site/ Binaries: http://people.apache.org/builds/commons/email/1.3/RC1/staged/org/apache/commons/commons-email/1.3/ [ ] +1 release it [ ] +0 go ahead I don't care [ ] -1 no, do not release it because Thanks in advance Siegfried Goeschl - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[ANNOUNCEMENT] Apache Commons Exec 1.1 Released
The commons-exec-team is pleased to announce the commons-exec-1.1.jar release! A library to reliably execute external processes from within the JVM Changes in this version include: New features: o Adding 'Argument' class and quote the arguments after expansion. o Added TutorialTest as a playground for new user and removed similar code from DefaultExecutorTest. o Added 'DefaultExecuteResultHandler' Fixed Bugs: o OpenVMS now uses symbols instead of logicals for environment variables. o String substitution handles now java.io.File instances in order to create a cross-platform file name. o The 'forever.bat' accidentally overwrite the 'forever.txt' instead of appending. o Process.waitFor should clear interrupt status when throwing InterruptedException Issue: EXEC-46. Thanks to Zimmermann Nir. o Because the ExecuteWatchdog is the only way to destroy asynchronous processes, it should be possible to set it to an infinite timeout, for processes which should not timeout, but manually destroyed under some circumstances. Issue: EXEC-44. Changes: o DefaultExecutor() now sets the working directory with the current working directory. o Added 'DefaultExecutorTest#testStdInHandling' to show how commons-exec can feed the 'stdin' of a child process. o Improved the documentation. Issue: EXEC-42. Thanks to Konrad Windzus. o Added a new section to the tutorial to show working with asynchronous processes. Thanks to Pablo Hoertner. Have fun! -commons-exec-team - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[VOTE][RESULT] Release commons-exec-1.1 based on RC1
Hi folks, the vote to release commons-exec-1.1 based on RC1 resulted in 7 binding +1 votes +) Oliver Heger (binding) +) Niall Pemberton (binding) +) Rahul Akolkar (binding) +) Sebastian Bazley (binding) +) Henri Biestro (binding) +) Jörg Schaible (binding) +) Siegfried Goeschl (binding) Cheers, Siegfried Goeschl On 10/10/10 9:40 PM, Siegfried Goeschl wrote: Hi folks, I would like to call a vote for releasing commons-exec-1.1 based on RC1. Below you find the RC coordinates Cheers, Siegfried Goeschl Tag: https://svn.apache.org/repos/asf/commons/proper/exec/tags/COMMONS_EXEC_1_1_RC1 Site: http://people.apache.org/builds/commons/exec/1.1/RC1/site/index.html Binaries: http://people.apache.org/builds/commons/exec/1.1/RC1/staged/org/apache/commons/commons-exec/1.1/ [ ] +1 release it [ ] +0 go ahead I don't care [ ] -1 no, do not release it because - 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: [VOTE] Release commons-exec-1.1 based on RC1
As usual forgetting my own vote +1 Siegfried Goeschl On 10/10/10 9:40 PM, Siegfried Goeschl wrote: Hi folks, I would like to call a vote for releasing commons-exec-1.1 based on RC1. Below you find the RC coordinates Cheers, Siegfried Goeschl Tag: https://svn.apache.org/repos/asf/commons/proper/exec/tags/COMMONS_EXEC_1_1_RC1 Site: http://people.apache.org/builds/commons/exec/1.1/RC1/site/index.html Binaries: http://people.apache.org/builds/commons/exec/1.1/RC1/staged/org/apache/commons/commons-exec/1.1/ [ ] +1 release it [ ] +0 go ahead I don't care [ ] -1 no, do not release it because - 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
[VOTE] Release commons-exec-1.1 based on RC1
Hi folks, I would like to call a vote for releasing commons-exec-1.1 based on RC1. Below you find the RC coordinates Cheers, Siegfried Goeschl Tag: https://svn.apache.org/repos/asf/commons/proper/exec/tags/COMMONS_EXEC_1_1_RC1 Site: http://people.apache.org/builds/commons/exec/1.1/RC1/site/index.html Binaries: http://people.apache.org/builds/commons/exec/1.1/RC1/staged/org/apache/commons/commons-exec/1.1/ [ ] +1 release it [ ] +0 go ahead I don't care [ ] -1 no, do not release it because - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [lang] Wildcard regex
Hi folks,
assuming that "standard wildcard" is actually globbing I came around of
an globbing to regexp converter somewhere - I will have a look
Cheers,
Siegfried Goeschl
On 10/8/10 4:32 PM, Stephen Colebourne wrote:
Human users enter wildcards * and ? (because regex is too complex). In
my case, I'm passing it to MongoDB, which needs regex.
Stephen
On 8 October 2010 15:10, Paul Benedict wrote:
Can I get some sense of use case? What would you use it for? Just curious.
On Fri, Oct 8, 2010 at 9:06 AM, Stephen Colebourne wrote:
I don't think comons lang has a routine for converting a standard
wildcard string (with * and ?) to a regex.
Here is a first suggestion, although I'm sure it can be improved.
public Pattern createPattern(String text) {
StringTokenizer tkn = new StringTokenizer(text, "?*", true);
StringBuilder buf = new StringBuilder(text.length() + 10);
buf.append('^');
boolean lastStar = false;
while (tkn.hasMoreTokens()) {
String str = tkn.nextToken();
if (str.equals("?")) {
buf.append('.');
lastStar = false;
} else if (str.equals("*")) {
if (lastStar == false) {
buf.append(".*");
}
lastStar = true;
} else {
buf.append(Pattern.quote(str));
lastStar = false;
}
}
buf.append('$');
return Pattern.compile(buf.toString(), Pattern.CASE_INSENSITIVE);
}
Other possile conversions would be * and ? to databse wildcards, so
perhaps there is scope for a few related methods here?
Stephen
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [EXEC] OpenVMS failures
Hi folks, one note regarding the regression tests - check if there are still background processes running because they will break the next test run as well. Cheers, Siegfried Goeschl On 10/6/10 6:19 PM, sebb wrote: On 6 October 2010 05:44, Tim Sneddon wrote: On 10/06/2010 07:23 AM, sebb wrote: On 2 October 2010 16:11, sebbwrote: These are all due to failure to destroy the subprocess on OpenVMS. I don't know if there is a workround. I know some time ago I had some fixes to the OpenVMS support. Sadly I had to move on to something else before I got round to submitting them. Java has dropped slightly on the priority list for the next few months :-(. I will have some time over the next few days to check this out and hopefully pass on my fixes. That would be very good. I can help with testing any such changes (I have an account on the OpenVMS Open Source test systems, and used to work a lot on VMS). Tim. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [exec] Looking for some field testing before cutting release candidate ...
Hi folks, thanks for all the effort and I'm assembling the updated test matrix page Some thoughts along the line +) [sebb] Dropping JDK 1.3 support but keeping 1.4 is fine for me. Testing for different JDKs is a bit complicated on Mac OS X (to put that politely) +) [sebb] I added a few more tests so it is likely to break on OpenVMS (no chance to test that). Having said that I don't have a problem to mark OpenVMS as partly supported (and this might save Sebatian a day) +) [sebb] Good idea - I have a look at the waitFor() suggestion +) [niall] Thanks for the patch +) [gary] Fixed the batch file as you suggested Cheers, Siegfried Goeschl PS: Would appreciate even more test reports :-) On 10/1/10 7:20 PM, Siegfried Goeschl wrote: Hi folks, anyone out who can do some field testing for commons-exec before I prepare the release candidate? The test harness can be downloaded from http://people.apache.org/~sgoeschl/download/exec/ After unpacking the archive and making the shell scripts (check src/test/scripts) executable you can run the test harness using +) testme.bat +) test.sh Feedback would be highly appreciated containing +) OS +) JVM version +) reporter +) status as collected for the previous release (http://commons.apache.org/exec/testmatrix.html) Thanks in advance, Siegfried Goeschl - 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
[exec] Looking for some field testing before cutting release candidate ...
Hi folks, anyone out who can do some field testing for commons-exec before I prepare the release candidate? The test harness can be downloaded from http://people.apache.org/~sgoeschl/download/exec/ After unpacking the archive and making the shell scripts (check src/test/scripts) executable you can run the test harness using +) testme.bat +) test.sh Feedback would be highly appreciated containing +) OS +) JVM version +) reporter +) status as collected for the previous release (http://commons.apache.org/exec/testmatrix.html) Thanks in advance, Siegfried Goeschl - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] Apachecon US slot open
Hi folks, good news and a happy Luc ... :-) Cheers, Siegfried Goeschl On 9/6/10 3:34 PM, Phil Steitz wrote: On 9/6/10 4:08 AM, luc.maison...@free.fr wrote: Hi all, I finally got a green light for the conference, assuming I can speak and benefit from lodging and conference fees. I'm afraid the only topic I am able to speak about would be [math]. Great news! Less work for me - he he. This will be great! Phil, could you tell me if the slot is still available and how I should register as a speaker ? We had initially planned to combine [math] and [pool]/[dbcp] into one 50-min slot, but I was frankly worried about the different audiences and also being able to get into meaty stuff for both, so I am really happy to split these, have you do [math] and I will do [pool]/[dbcp]. So yes, we can rearrange to make this work. Siegfried - are you OK with this? We can talk about how to spread the "intro to commons" bits across our three sessions or shove it into the beginning of one of them. Luc - subscribe to speakers-2010...@apachecon.com. I will give heads up to the planners. Thanks!! Phil Thanks, Luc - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [exec] unix-like stream processing
Hi Philippe, still waiting for your contribution to see if I can add it to commons-exec ... :-) Thanks in advance Siegfried Goeschl On 21.07.10 17:02, Siegfried Goeschl wrote: Hi Phillippe, welcome at Commons ... :-) ... the best way to provide a patch is to open a JIRA ticket (https://issues.apache.org/jira/browse/EXEC) and add the code. Cheers, Siegfried Goeschl On 21.07.10 14:59, Philippe Marchesseault wrote: Hello, I have developped a few classes that might be of interest for the Commons Exec project. These classes provide a unix-like functionality by doing stream formatting and filtering. They are of course chainable, 100% Java and come with a few unit tests. The command implemented thus far are - grep - cut - head - tail - sort - paste - tee - tr - A stream to String array adapter - A stream to String table adapter Those classes are usefull by themselves, but I think they would make a nice addition to the exec project. Let me know if you are interested in integrating them to exec. Since this is my first contribution, please advise on how to contribute. Regards, Philippe - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[exec] EXEC-36 and ExecParseUtils
Hi Mitko, I had a look at the code and tested it within commons-exec but it did not solve the command line parsing problems the users are tackling. I added two additional tests to document my problems in ExecParseUtilTests.java (attachement to EXEC-36). Do you mind looking at the code? Cheers, Siegfried Goeschl - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Commons Compress based on RC1
Hi Christian, +) works on Mac OS X 10.6 and java 1.6.0_20 from SVN tag +) IntelliJ complained about a few JavaDoc & PMD issues but only minor stuff +) RELEASE-NOTES.txt contains wrong version number [X] +1 release it [ ] +0 go ahead I don't care [ ] -1 no, do not release it because Cheers, Siegfried Goeschl On 10.08.10 06:59, Christian Grobmeier wrote: Hello, Commons Compress 1.1 is available for testing :-) Please have a look at it and vote. Note: this release has been made with Nexus and the new process described here: http://wiki.apache.org/commons/UsingNexus Tag: https://svn.apache.org/repos/asf/commons/proper/compress/tags/commons-compress-1.1/ Site: http://people.apache.org/builds/commons/compress/1.1/RC1/ Binaries: https://repository.apache.org/content/repositories/orgapachecommons-072/org/apache/commons/commons-compress/1.1/ [ ] +1 release it [ ] +0 go ahead I don't care [ ] -1 no, do not release it because The vote will stay open at least for 72 hours. Thanks, 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: svn commit: r983137 - /commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ArrayUtils.java
Hi James, we are paying attention but it is hard to provide useful comments if you are distracted with payed work ... :-) As far as I understand the discussion I would lean towards Sebastion reasoning - but still wondering how he finds the time to review every single commit ... :-) Cheers, Siegfried Goeschl On 09.08.10 14:08, James Carman wrote: On Mon, Aug 9, 2010 at 7:32 AM, sebb wrote: Why not split the code into two methods: public static Map toMap(Map.Entry[] array) and public static Map toMap(Class keyType, Class valueType, Object[][] array) Both methods can be made type-safe. Well, we did just bump the version number, so we are free to do something like that I guess. Anyone else have any thoughts on the subject (are you even paying attention anymore)? - 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: [exec] unix-like stream processing
Hi Phillippe, welcome at Commons ... :-) ... the best way to provide a patch is to open a JIRA ticket (https://issues.apache.org/jira/browse/EXEC) and add the code. Cheers, Siegfried Goeschl On 21.07.10 14:59, Philippe Marchesseault wrote: Hello, I have developped a few classes that might be of interest for the Commons Exec project. These classes provide a unix-like functionality by doing stream formatting and filtering. They are of course chainable, 100% Java and come with a few unit tests. The command implemented thus far are - grep - cut - head - tail - sort - paste - tee - tr - A stream to String array adapter - A stream to String table adapter Those classes are usefull by themselves, but I think they would make a nice addition to the exec project. Let me know if you are interested in integrating them to exec. Since this is my first contribution, please advise on how to contribute. Regards, Philippe - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] ApacheCon North America 2010
Hi Phil, my short blurb for the website regarding ApacheCon 2010 Cheers, Siegfried Goeschl >>> START >>> Commons Email = You just wanted to send an email from within your application and got confused with BodyParts, MimeBodyParts, MimeMultiparts and friends of the Java Mail API?! If yes - have a look at commons-email to see how you can easily create text emails with attachments or HTML emails with embedded images in just a few lines of code. Commons Exec = Using a simple "Runtime.exec()" in production code won't cut it and might break your application. Using commons-exec shields you from platform-specific exit codes, blocking error streams, run-away child processes, asynchronous process execution and cross-platform issues. <<< END <<< On 18.07.10 00:38, Phil Steitz wrote: Ralph Goers wrote: If you want another talk I could put something together to talk about VFS and Configuration and how we are using it for multi-tenant configuration. Great! How much time would you like? In any case, can you provide a short blurb for the web site? Thanks! Phil Ralph On Jul 17, 2010, at 11:37 AM, Phil Steitz wrote: Phil Steitz wrote: Phil Steitz wrote: We are in luck! Our friends in ComCom are creating a "tracklet" for us. We have three hours to work with, which we can cut up as we wish. So who wants to volunteer to speak? As I said above, I will volunteer for [math] and/or [dbcp]/[pool] with length "configurable." I would also be willing to do a short blast on how Commons works (or listen to someone else do that). I am perfectly happy letting others do any / all of these or using the time for other things altogether. I like all of the other suggestions above. The conference is 1-5 Nov in Atlanta, GA (US) and there is some registration and lodging assistance available for speakers. I don't have the exact time of our block, but will share when I have it. We are likely going to need to get descriptions on the web site pretty soon, so it would be good to agree on the agenda and who is going to speak RSN. Thanks in advance! Phil Thanks, all for the feedback. As of now, Siegfried and I have volunteered to speak. Any other volunteers? Any other suggestions for content? So far, here is what we have. +/- Feedback would be great on the items below, as would additional volunteers to speak or other ideas for talks. I need to provide abstracts for the Apachecon web pages in the next couple of days. Looks like it's me and Siegfried doing the talking. Given that and the feedback so far, I propose that we split the 3 50 min slots as follows: 1) Commons overview (combination of how-it-works, what it is, what's happening, with brainstorming at end) 2) Component drilldowns: [email], [exec], [math], [dbcp/pool] The "component drilldown" sections would be 20 mins each, run as separate mini-sessions. If we could get someone to volunteer to present [scxml] as a mini, we could work it in as well. Any thoughts on this? Any other components we should be highlighting? Phil email* exec* math* dbcp/pool* scxml** introduction/overview/how-it-works* last 12 months what's new new components brainstorming *volunteer to prepare and present available **volunteer to prepare available Phil - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - 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] ApacheCon North America 2010
Hi Ralph and Phil, +) I would highly appreciate VFS and Configuration ... :-) +) having at least three committers to present altogether six commons components looks reasonable. I will provide the abstracts on Tuesday night (CET) ... Cheers, Siegfried Goeschl On 18.07.10 00:13, Ralph Goers wrote: If you want another talk I could put something together to talk about VFS and Configuration and how we are using it for multi-tenant configuration. Ralph On Jul 17, 2010, at 11:37 AM, Phil Steitz wrote: Phil Steitz wrote: Phil Steitz wrote: We are in luck! Our friends in ComCom are creating a "tracklet" for us. We have three hours to work with, which we can cut up as we wish. So who wants to volunteer to speak? As I said above, I will volunteer for [math] and/or [dbcp]/[pool] with length "configurable." I would also be willing to do a short blast on how Commons works (or listen to someone else do that). I am perfectly happy letting others do any / all of these or using the time for other things altogether. I like all of the other suggestions above. The conference is 1-5 Nov in Atlanta, GA (US) and there is some registration and lodging assistance available for speakers. I don't have the exact time of our block, but will share when I have it. We are likely going to need to get descriptions on the web site pretty soon, so it would be good to agree on the agenda and who is going to speak RSN. Thanks in advance! Phil Thanks, all for the feedback. As of now, Siegfried and I have volunteered to speak. Any other volunteers? Any other suggestions for content? So far, here is what we have. +/- Feedback would be great on the items below, as would additional volunteers to speak or other ideas for talks. I need to provide abstracts for the Apachecon web pages in the next couple of days. Looks like it's me and Siegfried doing the talking. Given that and the feedback so far, I propose that we split the 3 50 min slots as follows: 1) Commons overview (combination of how-it-works, what it is, what's happening, with brainstorming at end) 2) Component drilldowns: [email], [exec], [math], [dbcp/pool] The "component drilldown" sections would be 20 mins each, run as separate mini-sessions. If we could get someone to volunteer to present [scxml] as a mini, we could work it in as well. Any thoughts on this? Any other components we should be highlighting? Phil email* exec* math* dbcp/pool* scxml** introduction/overview/how-it-works* last 12 months what's new new components brainstorming *volunteer to prepare and present available **volunteer to prepare available Phil - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r961524 - in /commons/proper/email/trunk: ./ src/changes/ src/java/org/apache/commons/mail/ src/java/org/apache/commons/mail/impl/ src/test/attachments/ src/test/html/ src/test/image
Thanks for the reminder ... I will correct it in the evening Siegfried Goeschl On 08.07.10 00:55, sebb wrote: On 7 July 2010 23:26, wrote: Author: sgoeschl Date: Wed Jul 7 22:26:19 2010 New Revision: 961524 URL: http://svn.apache.org/viewvc?rev=961524&view=rev Log: [EMAIL-92] Adding ImageHtmlEmail to automatically embed images into an HTML email. Added: commons/proper/email/trunk/src/java/org/apache/commons/mail/ImageHtmlEmail.java commons/proper/email/trunk/src/java/org/apache/commons/mail/impl/ commons/proper/email/trunk/src/java/org/apache/commons/mail/impl/URLFactory.java commons/proper/email/trunk/src/java/org/apache/commons/mail/impl/package.html - copied, changed from r960092, commons/proper/email/trunk/src/java/org/apache/commons/mail/package.html commons/proper/email/trunk/src/test/attachments/download_email.cgi.html commons/proper/email/trunk/src/test/html/ commons/proper/email/trunk/src/test/html/www.apache.org.html commons/proper/email/trunk/src/test/images/logos/ commons/proper/email/trunk/src/test/images/logos/maven-feather.png (with props) commons/proper/email/trunk/src/test/org/apache/commons/mail/ImageHtmlEmailTest.java commons/proper/email/trunk/src/test/org/apache/commons/mail/mocks/MockImageHtmlEmailConcrete.java Please set the SVN property eol-style=native on the .java files. You probably need to change your subversion config file. - 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] ApacheCon North America 2010
Hi folks, brilliant news - I volunteer for one or more of the following talks * [email] * [exec] * [introduction] Regarding [introduction] - I would see a few people more qualified than me such as Phil, Niall, Sebastian or Henri ... :-) Regarding [scxml] - I would really like to see someone talking about it even when Rahoul is unable to do so. Cheers, Siegfried Goeschl On 03.07.10 15:49, Phil Steitz wrote: We are in luck! Our friends in ComCom are creating a "tracklet" for us. We have three hours to work with, which we can cut up as we wish. So who wants to volunteer to speak? As I said above, I will volunteer for [math] and/or [dbcp]/[pool] with length "configurable." I would also be willing to do a short blast on how Commons works (or listen to someone else do that). I am perfectly happy letting others do any / all of these or using the time for other things altogether. I like all of the other suggestions above. The conference is 1-5 Nov in Atlanta, GA (US) and there is some registration and lodging assistance available for speakers. I don't have the exact time of our block, but will share when I have it. We are likely going to need to get descriptions on the web site pretty soon, so it would be good to agree on the agenda and who is going to speak RSN. Thanks in advance! Phil - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Call for Participation: Technical Talks -- ApacheCon North America 2010
Hi folks, of course I can propose the two usual suspects - commons-email and commons-exec. My personal favorites +) commons-scxml +) commons-vfs +) commons-jexl Cheers, Siegfried Goeschl On 02.05.10 08:10, Rahul Akolkar wrote: On Sat, May 1, 2010 at 7:35 PM, Phil Steitz wrote: Siegfried Goeschl wrote: Hi folks, quite frankly I would love to give a presentation at ApacheCon but it should be something that +) is of general interest +) and I have good knowledge about +) and I also should actively contribute to the topic which rules out pretty much everything ... :-) Having said that I would like to pick up Rahoul's idea of doing a joint presentation of Apache Commons (Rahoul organized a small scale one for ApacheCon Europe 2007) "Would it be a good idea to organize a Apache Commons track covering 2-3 regular speaking slots where we can present various Apache Commons components?" The point is that a Commons component presentation is probably be smaller than a regular speaking slot but we have interesting stuff. Feedback appreciated, Siegfried Goeschl We may be a little late to the party on this, but if there is still time / room to set up another track, I am +1. I thought about suggesting a pool/dbcp talk for the tomcat track, but it would probably be better to do this as part of a commons track, if we can get that organized in time. I could also do something on math if we have critical mass to do some other talks and can still get this in. Sally - is is possible to still add a track? All - any other volunteers / ideas? First week of November I'll likely be in France, though generally speaking I'm happy to participate. -Rahul - 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: Call for Participation: Technical Talks -- ApacheCon North America 2010
Hi folks, quite frankly I would love to give a presentation at ApacheCon but it should be something that +) is of general interest +) and I have good knowledge about +) and I also should actively contribute to the topic which rules out pretty much everything ... :-) Having said that I would like to pick up Rahoul's idea of doing a joint presentation of Apache Commons (Rahoul organized a small scale one for ApacheCon Europe 2007) "Would it be a good idea to organize a Apache Commons track covering 2-3 regular speaking slots where we can present various Apache Commons components?" The point is that a Commons component presentation is probably be smaller than a regular speaking slot but we have interesting stuff. Feedback appreciated, Siegfried Goeschl On 28.04.10 19:48, Sally Khudairi wrote: ApacheCon North America 2010 1-5 November 2010 -- Westin Peachtree in Atlanta Technical Tracks: Call For Participation All submissions must be received by Friday, 28 May 2010 at midnight Pacific Time. The official conference, trainings, and expo of The Apache Software Foundation (ASF) returns to Atlanta this November, with dozens of technical, business, and community-focused sessions at the beginner, intermediate, and advanced levels. Over the past decade, the ASF has gone from strength to strength, developing and shepherding nearly 150 Top-Level Projects and new initiatives in the Apache Incubator and Labs. This year's ApacheCon celebrates how Apache technologies have sparked creativity, challenged processes, streamlined development, improved collaboration, launched businesses, bolstered economies, and improved lives. We are proud of our achievements and recognize that the global Apache community --both developers and users-- are responsible for the success and popularity of our products. The ApacheCon Planning Team are soliciting 50-minute technical presentations for the next conference, which will focus on the theme “Servers, the Cloud, and Innovation”. We are particularly interested in highly-relevant, professionally-directed presentations that demonstrate specific probrlems and real-world solutions. Part of the technical program has already been planned; we welcome proposals based on the following Apache Projects and related technical areas: - Cassandra/NoSQL - Content Technologies - (Java) Enterprise Development - Felix/OSGi - Geronimo - Hadoop + friends/Cloud Computing - Lucene, Mahout + friends/Search - Tomcat - Tuscany Submissions are open to anyone with relevant expertise: ASF affiliation is not required to present at, attend, or otherwise participate in ApacheCon. Please keep in mind that whilst we encourage submissions that the highlight the use of specific Apache solutions, we are unable to accept marketing/commercially-oriented presentations. Other proposals, such as panels, or those longer than 50 minutes in duration have been considered in the past. You are welcome to submit an alternate presentation, however, such sessions are accepted under exceptional circumstances. Please be as descriptive as possible, including names/bios of proposed panelists and any related details. All accepted speakers (not co-presenters) qualify for general conference admission and a minimum of two nights lodging at the conference hotel. Additional hotel nights and travel assistance are possible, depending on the number of presentations given and type of assistance needed. To submit a presentation proposal, please send an email to submissions AT apachecon DOT com containing the following information in plaintext (no attachments, please): 1. Your full name, title, and organization 2. Contact information, including your address 3. The name of your proposed session (keep your title simple and relevant to the topic) 4. The technical category of the intended presentation (Cassandra/NoSQL; Content Technologies; (Java) Enterprise Development; Felix/OSGi; Geronimo; Hadoop + friends/Cloud Computing; Lucene, Mahout + friends/Search; Tomcat; or Tuscany) 5. The classification for each presentation (Servers, Cloud, or Innovation) – some presentations may have more than one theme (e.g., a next-generation server can be classified both as "Servers" and "Innovation" 6. The intended audience level (beginner, intermediate, advanced) 7. A 75-200 word overview of your presentation 8. A 100-200-word speaker bio that includes prior conference speaking or related experience 9. Feedback or references (with contact information) on presentations given within the last three years To be considered, proposals must be received by Friday, 28 May 2010 at midnight Pacific Time. Please email any questions regarding proposal submissions to cfp AT apachecon DOT com. Technical Tracks Key Dates 23 April 2010: Call For Participation Open 28 May 2010: Call For Participation Closes 11 June 2010: Speaker Acceptance/Rejection Notification 1-5 November
Re: [SANDBOX] Need Help Building A Sandbox Site
Hi Adam,
+) you should get this message only once, afterwards the entry is found
in ~/.ssh/known_hosts (on my box). If you see that more than once your
SSH connection probably won't work
+) the message you are seeing comes from people.apache.org
Siegfried Goeschl
On 06.04.10 23:31, Adrian Crum wrote:
Btw, I'm getting one message about authenticity - I don't know if it has any
effect:
[INFO] [site:deploy {execution: default-cli}]
The authenticity of host 'people.apache.org' can't be established.
RSA key fingerprint is 51:85:7d:8f:57:54:e7:6f:27:26:98:7a:c7:c1:47:87.
Are you sure you want to continue connecting? (yes/no): yes
Note that too many successive login failures will result in further
logins from your IP address being blocked. If this happens, contact
, mentioning your IP address so that it can
be unblocked.
--- On Tue, 4/6/10, Adrian Crum wrote:
From: Adrian Crum
Subject: Re: [SANDBOX] Need Help Building A Sandbox Site
To: "Commons Developers List"
Date: Tuesday, April 6, 2010, 2:13 PM
Siegfried,
I have done all of that - everything is exactly as you described. I even tried
it on two different PCs on two different networks - same result.
If you wouldn't mind uploading the site until I get this issue resolved, that
would be great! I want to do it myself, but it's taking me a while to track
down the problem.
-Adrian
--- On Tue, 4/6/10, Siegfried Goeschl wrote:
From: Siegfried Goeschl
Subject: Re: [SANDBOX] Need Help Building A Sandbox Site
To: "Commons Developers List"
Date: Tuesday, April 6, 2010, 1:53 PM
Hi Adrian,
not sure what was discussed but here is my configuration
+) using Apache Maven 2.2.1 (otherwise deployment does not work)
+) I think for the release process SVN client 1.5.0 is required
(recently upgraded to Mac OS 10.6 so I lost my good SVN installation)
+) you need a proper settings.xml containing the user name for
'apache.website'
apache1.website
XXX
664
775
I know that mastering commons infrastructure can be intimidating but I
can upload your site for while to keep your back free ...
Cheers,
Siegfried Goeschl
On 06.04.10 22:17, Adrian Crum wrote:
--- On Tue, 4/6/10, Siegfried Goeschl wrote:
Hi folks,
the email is pretty much unreadable but I generated und
uploaded the
site without problems
Thanks Siegfried! I can generate the site okay, but the mvn site:deploy command
fails with an authorization error. I'm using Maven 2.2.1, and I confirmed I can
log into people.apache.org using SSH (Putty).
-Adrian
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [SANDBOX] Need Help Building A Sandbox Site
Hi Adrian, not sure what was discussed but here is my configuration +) using Apache Maven 2.2.1 (otherwise deployment does not work) +) I think for the release process SVN client 1.5.0 is required (recently upgraded to Mac OS 10.6 so I lost my good SVN installation) +) you need a proper settings.xml containing the user name for 'apache.website' apache1.website XXX 664 775 I know that mastering commons infrastructure can be intimidating but I can upload your site for while to keep your back free ... Cheers, Siegfried Goeschl On 06.04.10 22:17, Adrian Crum wrote: --- On Tue, 4/6/10, Siegfried Goeschl wrote: Hi folks, the email is pretty much unreadable but I generated und uploaded the site without problems Thanks Siegfried! I can generate the site okay, but the mvn site:deploy command fails with an authorization error. I'm using Maven 2.2.1, and I confirmed I can log into people.apache.org using SSH (Putty). -Adrian - 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: [SANDBOX] Need Help Building A Sandbox Site
Hi folks, the email is pretty much unreadable but I generated und uploaded the site without problems Cheers, Siegfried Goeschl On 06.04.10 16:45, Adrian Crum wrote: --- On Tue, 4/6/10, Phil Steitz wrote: Adrian Crum wrote: --- On Sun, 3/28/10, Phil Steitz wrote: Adrian Crum wrote: --- On Sun, 3/28/10, Luc Maisonobe wrote: Adrian Crum a écrit : --- On Sat, 3/27/10, Phil Steitz wrote: Adrian Crum wrote: --- On Sat, 3/27/10, Rahul Akolkar wrote: Adrian Crum wrote: I noticed all of the sandbox sub-project links generate a 404 error. I tried to update the sandbox convert site by following the instructions here: http://commons.apache.org/building.html It appeared the mvn site command downloaded poms and jars from the entire Commons project, then ran a build on convert. I'm not sure what I'm supposed to do now. Any guidance would be greatly appreciated! Usually just a deploy (assuming mvn site succeeded, the following in the WC of convert): mvn site:deploy You may get 404s for other components locally, but should be ok on the webserver assuming the component (pom etc.) is set up correctly. Thanks Rahul! the mvn site:deploy command asked me for a password. I tried my svn password, but that didn't work. Any other ideas? Try putting the following into your maven settings.xml (with your availId in place of mine): ... people.apache.org psteitz 664 775 Then respond to the pwd challenge with your shell account pwd (the push to people.apache.org is using scp, so you are authenticating to the box, not svn). Drat. That didn't work either. The script got stuck in a loop that repeatedly asked me for my password. Previously, it just failed to log in and then exited. I think it requires the password a few times (say two or three) but really proceeds. Is it stuck more than three times in the loop ? I just tried it again. It asked for my password six times, then failed with an auth error. What was the auth error and what version of maven are you using? Sorry I forgot about the ssh agent compat issue with earlier versions of m2. I had to upgrade to 2.2.1 to get ssh deploys to work. Below... Looks like what I used to get with 2.0.x versions of Maven. What version are you running? IIRC, this problem is caused by ssh library incompatibility between what is now running on minotaur and the version of jsch that is being dragged along by maven. If you have not done so, try upgrading to maven 2.2.1. Phil That is the version I'm using. I confirmed I can log in using SSH. I apologize for my newbie-ness. Adam - the developer I count on to make these things work - is busy with other things right now. scp://people.apache.org/www/commons.apache.org/sandbox/commons-convert - Session : Connection refused scp://people.apache.org/www/commons.apache.org/sandbox/commons-convert - Session : Disconnecting scp://people.apache.org/www/commons.apache.org/sandbox/commons-convert - Session : Disconnected [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error uploading site Embedded error: Cannot connect. Reason: Auth fail [INFO] [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Error uploading site at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa ultLifecycleExecutor.java:719) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandalone Goal(DefaultLifecycleExecutor.java:569) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau ltLifecycleExecutor.java:539) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan dleFailures(DefaultLifecycleExecutor.java:387) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen ts(DefaultLifecycleExecutor.java:348) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi fecycleExecutor.java:180) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138) at org.apache.maven.cli.MavenCli.main(MavenCli.java:362) at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:6 0) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.classworlds.Launcher.lau
Re: [email][exec] Somehow not getting JIRA issues notification?!
Hi folks, probably I messed up somewhere but it is still embarrassing - anyway +) I subscribed to issues again +) I disabled my mail filters for now +) I have a close look at my spam folder and that should solve my problem ... :-( Thanks, Siegfried Goeschl On 27.03.10 13:18, Luc Maisonobe wrote: Siegfried Goeschl a écrit : Hi folks, I just checked JIRA for commons-email and commons-exec and found that there are a couple of new issues - I'm pretty sure that I have not got any notification from JIRA. Is that possible ?! +) the email address of my account is correct and works *) the JIRA issues whould go to dev at commons dot apache dot org I think they go to issues at commons dot apache dot org. AFAIK this list has been created when we got TLP and there was an automatic subscribe from the previous lists from jakarta. Luc Anything wrong with the setup or did I somehow miss the emails? A highly embarrased Siegfried Goeschl - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[email][exec] Somehow not getting JIRA issues notification?!
Hi folks, I just checked JIRA for commons-email and commons-exec and found that there are a couple of new issues - I'm pretty sure that I have not got any notification from JIRA. Is that possible ?! +) the email address of my account is correct and works *) the JIRA issues whould go to dev at commons dot apache dot org Anything wrong with the setup or did I somehow miss the emails? A highly embarrased Siegfried Goeschl - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release commons-parent 14
Hi Niall, did a quick test on commons-exec on Mac OS 10.6 and everything seems okay +1 Cheers, Siegfried Goeschl On 11.03.10 01:04, Niall Pemberton wrote: Hi, I'd like to release version 14 of the commons-parent pom to fix the problems in the last release. The changes are: 1. Downgrade maven-site-plugin to 2.0.1 (MSITE-464) 2. Downgrade maven-javadoc-plugin to 2.5 (MJAVADOC-275) 3. Downgrade maven-bundle-plugin to 1.4.3 (JDK 1.4 compat) 4. Downgrade maven-remote-resources-plugin to 1.1 (JDK 1.4 compat) 5. Move maven-javadoc-plugin config out of A full diff of the pom.xml can be found at this address: http://svn.apache.org/viewvc/commons/proper/commons-parent/trunk/pom.xml?r1=920946&r2=920037&diff_format=h The version number in the pom will be updated automatically during the release process. [ ] +1 [ ] =0 [ ] -1 Vote is open for 72 hours Niall - 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: [VOTE] Release commons-parent 14
Hi Niall, can I politely ask for an extended voting period - I would like to have a closer look on Sunday/Monday ... Thanks in advance Siegfried Goeschl On 11.03.10 14:37, Niall Pemberton wrote: I have added the new profiles for different java versions suggested by Sebb: http://svn.apache.org/viewvc?view=revision&revision=921843 New diff of the pom.xml can be found at this address: http://svn.apache.org/viewvc/commons/proper/commons-parent/trunk/pom.xml?r1=921843&r2=920037&diff_format=h If anyone wants more time to review these changes then please shout and we can extend the voting period. Thanks Niall On Thu, Mar 11, 2010 at 12:40 AM, sebb wrote: On 11/03/2010, Niall Pemberton wrote: Hi, I'd like to release version 14 of the commons-parent pom to fix the problems in the last release. The changes are: 1. Downgrade maven-site-plugin to 2.0.1 (MSITE-464) 2. Downgrade maven-javadoc-plugin to 2.5 (MJAVADOC-275) 3. Downgrade maven-bundle-plugin to 1.4.3 (JDK 1.4 compat) 4. Downgrade maven-remote-resources-plugin to 1.1 (JDK 1.4 compat) 5. Move maven-javadoc-plugin config out of A full diff of the pom.xml can be found at this address: http://svn.apache.org/viewvc/commons/proper/commons-parent/trunk/pom.xml?r1=920946&r2=920037&diff_format=h The version number in the pom will be updated automatically during the release process. [ ] +1 [ ] =0 [ ] -1 Can we include the new java profiles? Sorry, I have been away, otherwise I would have produced COMMONSSITE-49 earlier. The patch adds 3 profiles to the parent pom; these are not enabled by default so should not affect any existing builds. Vote is open for 72 hours Niall - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] why no tag for MATH_2_0?
Luc - assuming that RC2 was the accepted release candidate than a svn copy is missing?! If the RC2 is correct I can do the svn stuff ... Siegfried Goeschl Benson Margulies wrote: > There is a tag for RC2 of 2.0, but not for 2.0 itself. > > - > 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: [IO] OK to drop Maven1 build files?
+1 Siegfried Goeschl sebb wrote: > Is it OK to delete the Maven1 build files from IO? The code now > requires Java 1.5. > > - > 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: Colt vs. Primitives
Hi Benson, I would assume that contributing to commons-math requires some good math background whereas primitives seem a little bit easier ... :-) Cheers, Siegfried Goeschl Benson Margulies wrote: > So, the silence is rather noisy in response to the discussion about > commons-math. Commons PMC members, what's the story here? Why is it > apparently easy for me to tee up code for primitives and impossible > for the corresponding activity for -math? > > On Mon, Dec 7, 2009 at 5:26 PM, Ted Dunning wrote: > >> Bring them in! We will likely need them as well. >> >> On Mon, Dec 7, 2009 at 2:23 PM, Benson Margulies >> wrote: >> >> >>> maps. >>> >>> >>> On Dec 7, 2009, at 5:16 PM, Ted Dunning wrote: >>> >>> Which part did you care about? >>> >>>> On Mon, Dec 7, 2009 at 2:12 PM, Benson Margulies >>> >>>>> wrote: >>>>> >>>> Aha, you didn't take the part I care about most, but your grab of the >>>> >>>>> jet stuff may help me grab the collections stuff. This is almost messy >>>>> enough for me to go back to coding from scratch from Knuth. >>>>> >>>>> >>>>> >>>>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> >>> >> -- >> Ted Dunning, CTO >> DeepDyve >> >> > > - > 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: Using maven 2 on non-MSFT platform to build JEXL
Shall I upload the site? Cheers, Siegfried Goeschl henrib wrote: > If it is styled in Blue - as the Jexl 1.0 site looks - and if you have the > menu for reports (cobertura, etc), then you're good and I'm doing something > totally stupid on my end. > If site is styled in Red, no menu for reports, then we look at the same > problem. > Thanks for checking. > Cheers, > Henrib > > Siegfried Goeschl wrote: > >> Hi folks, >> >> just generated the site on Mac OS 10.4 and it looks good - the site says >> it it 2.0-SNAPSHOT (is this correct)? >> >> Cheers, >> >> Siegfried Goeschl >> >> >> >> > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Using maven 2 on non-MSFT platform to build JEXL
Hi folks, just generated the site on Mac OS 10.4 and it looks good - the site says it it 2.0-SNAPSHOT (is this correct)? Cheers, Siegfried Goeschl henrib wrote: > No, that does not change the output. > But with a parent pom version 11, it looks ok. > > > Niall Pemberton wrote: > >> ... >> Does it make any difference if you remove the leading slash from the >> href="/...html" attribute on the elements in site.xml? >> ... >> >> > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
