Thanks! On Fri, Jul 18, 2008 at 10:30 AM, Alan D. Cabrera <[EMAIL PROTECTED]> wrote:
> I've transferred all the post 0.9 issues over to ASF. > > > Regards, > Alan > > On Jul 18, 2008, at 7:21 AM, Les Hazlewood wrote: > > Once we transfer to the new Jira site, I'm going to disable the old one. >> I'm trying to shut that instance on the server down... >> >> On Fri, Jul 18, 2008 at 10:09 AM, Jeremy Haile <[EMAIL PROTECTED]> >> wrote: >> >> I think the advantage of the migrated version is that anyone who stumbles >>> on the old JIRA site knows that they have been moved to Apache. >>> >>> >>> On Jul 18, 2008, at 9:40 AM, Les Hazlewood wrote: >>> >>> 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? >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>> >
