We should have the 2 outstanding remaining issues for 0.9.0 RC1 to be complete in the next few days. Any issues other than those 2 are essentially in the backlog. I think maybe it would be better to have a 'backlog' in the Apache Jira and manually copy over those 7 issues.
That is, it probably isn't necessary to create a 'migrated' version just for those 7... Les On Fri, Jul 18, 2008 at 1:09 AM, Alan D. Cabrera <[EMAIL PROTECTED]> wrote: > Do you guys think this is the way to go or no? > > > Regards, > Alan > > > On Jul 11, 2008, at 9:18 PM, Alan D. Cabrera wrote: > > Les, >> >> If you make a version called, say, "moved-to-asf" I will be happy to copy >> anything in there over to the new Jira. >> >> >> Regards, >> Alan >> >> On Jul 10, 2008, at 8:39 PM, Les Hazlewood wrote: >> >> 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? >>>>> >>>> >>>> >>> >> >> >
