Ah, excellent question. The basic answer is that I was waiting for us to get the 0.9 release out for our existing community before we switch to the Apache Jira 100%. The _only_ reason being is that Jira will auto-generate release notes for us, and if all the issues for a given release are entirely under one Jira installation, then we can be sure it generates the complete list. If we had half our resolved issues in one location and the other half in Jira, it would be a pain to deal with when release time comes, which is why I wanted to make a clean break at a well-delimited point in time.
Since there are only 2 outstanding issues for 0.9 RC1, I can just move over the remaining issues (by hand) for 0.9 RC2 and above. This would make the transition a tad earlier than I originally expected, but that is as good a time as any probably. > There's no easy way than by hand. May as well start w/ the new ones. > > > Regards, > Alan > > On Jul 10, 2008, at 3:34 PM, Jeremy Haile wrote: > > > We haven't transitioned to the Apache JIRA yet. Our issues haven't > > been migrated over yet. > > > > > On Jul 10, 2008, at 6:24 PM, Alan D. Cabrera wrote: > >> Why hasn't this been filed on the Apache Jira? >> >> >> Regards, >> Alan On Thu, Jul 10, 2008 at 3:46 PM, Les Hazlewood <[EMAIL PROTECTED]> wrote: > > http://issues.jsecurity.org/browse/JSEC-117 > > On Thu, Jul 10, 2008 at 3:37 PM, Les Hazlewood <[EMAIL PROTECTED]> wrote: >> >> Hi all, >> >> I was contacted via private email yesterday about a company that wishes to >> use JSecurity in their product, but they were concerned about our use of >> Commons Logging, citing the now familiar classloader issues. It was >> interesting timing because of my proposal to use SLF4J last week. >> >> This gent's recommendation was that we have our own (very minimal) Log >> interface that we would use in our classes instead of Commons Logging. He >> brought up a number of cases of difficulty implementing frameworks in >> companies that have their own proprietary logging framework (events, >> monitoring, etc), and said it would be much easier and more flexible if they >> could implement their own version of a Log interface to do what they need, >> using their companies' APIs. >> >> I think it is a good idea, and would be super easy - it is basically one >> interface (Log) and maybe a 2nd (LogFactory, whatever). Then our default >> implementation could use the JVM logger or SLF4J to allow any number of >> pluggable logging implementations. This provides greater flexibility for >> any environment. We already do the same thing for caching (Cache, >> CacheManager) which in turn delegates to Caching product implementation >> specific classes (ehcache, JCache, etc). Same concept. >> >> The thing that sounds clean to me about this, is that if it was implemented, >> we would have NO required dependencies on any 3rd party library. That just >> feels sexy. But we can still have default implementations that use our >> favorite infrastructure. >> >> Any thoughts or objections? >
