See, I really want it to be part of Shiro, and I'm "prepared" to loose control. Sorry if I did't make this clear before.
It's only that I prefer to maintain code in a proper VCS/maven repo than in a JIRA's attached patch. It's easy for me to work on it, and to share with other users while it's not an official part of Shiro. I was thinking to do something like the tomahawk-facelets project, that was a standalone project util it was incorporated by Facelets project. And when it's time for the taglib to be incorporated by the Shiro project, you would have an up-to-date version and I'd stop mantaining it and direct new users to the *right* way of using it, officially from Shiro. Is it feasible? For example, having the taglib published in a maven repo would make it easier for Philip, from shiro-user list, to test it in his Iceface project. Deluan. On Mon, Nov 1, 2010 at 2:11 PM, Kalle Korhonen <[email protected]>wrote: > On Mon, Nov 1, 2010 at 8:44 AM, Deluan Quintão <[email protected]> wrote: > > So back to my original question: You think it's better to remove the > patch > > from JIRA, as it is already old, and put there a reference to > > the GitHub's repo I created to work with the project? > > Completely up to you. Both Grails and Tynamo projects (I founded the > latter) host deep integration libraries with Shiro and we host some > support libraries as part of Shiro itself. You know, it's trade off: > if you want completely control and release whenever you like, then > host it yourself (e.g. github) but the bugs are yours as well; if you > want more visibility for your works, bring it over but prepare to > loose control of "your code" and assume more responsibilities if you > want to become a committer (just maintaining a JSF component library > is not going be enough to qualify), in return you'll get "free" bug > fixes and maintenance. > > Kalle > > > > On Mon, Nov 1, 2010 at 1:21 PM, Kalle Korhonen > > <[email protected]>wrote: > > > >> On Mon, Nov 1, 2010 at 8:13 AM, Deluan Quintão <[email protected]> > wrote: > >> > Yes, it already works with both 1.0.x and 1.1.x. So following your > >> > rationale, do you think it's a good idea to release it as a > independent > >> > project (independent source and maven repos) while it's not officially > >> > adopt/endorsed by Shiro project? > >> > >> Obviously you could release it completely independently and/or do > >> whatever you like with it, but no, I was only suggesting that it would > >> not be part of the Shiro's core build. The only practical implication > >> is that it has a separate version number from Shiro core libs. We > >> would still take it and maintain it - since we have a jsp tag library, > >> I don't see a problem with jsf as well. > >> > >> Kalle > >> > >> > >> > On Mon, Nov 1, 2010 at 12:40 PM, Kalle Korhonen > >> > <[email protected]>wrote: > >> > > >> >> I'd expect the same jsf module would work both with 1.0.x and 1.1.x > >> >> Shiro - there were no drastic interface changes. Furthermore, I've > >> >> been proposing that the support libraries would become independently > >> >> releasable modules and so we could release the jsf module alone after > >> >> 1.1.0 Shiro. > >> >> > >> >> Kalle > >> >> > >> >> > >> >> On Mon, Nov 1, 2010 at 4:09 AM, Deluan Quintão <[email protected]> > >> wrote: > >> >> > Hi, > >> >> > > >> >> > I've already submitted the patch to JIRA containing the shiro-faces > >> >> module, > >> >> > but I see you guys are very busy with the 1.1 release. I'm using > the > >> >> faces > >> >> > module in one of my projects and making changes to it's code, so I > >> >> published > >> >> > it in a public repository as an independent module/library. > >> >> > > >> >> > So, in order to not leave an older version of the module attached > to > >> >> JIRA, > >> >> > I'd like to hear your opinions of whether it's better to remove the > >> patch > >> >> > from there and add a comment pointing to the source repo I'm using > >> right > >> >> > now. Then, when you have a chance to look at it, you let me know > and I > >> >> > prepare an updated patch and attach again to the JIRA ticket. > >> >> > > >> >> > What do you think? > >> >> > > >> >> > Deluan > >> >> > > >> >> > On Mon, Oct 25, 2010 at 1:32 PM, Deluan Quintão <[email protected] > > > >> >> wrote: > >> >> > > >> >> >> As I only have the JSF 1.2/Facelets module working and tested, > I'll > >> >> focus > >> >> >> on this for now, and when it's done I'll try to port it to JSF 2. > >> >> >> > >> >> >> I'll create a shiro-faces module under 'support', and > >> >> >> use org.apache.shiro.web.faces as package. > >> >> >> > >> >> >> Deluan > >> >> >> > >> >> >> > >> >> >> On Mon, Oct 25, 2010 at 12:34 PM, Kalle Korhonen < > >> >> >> [email protected]> wrote: > >> >> >> > >> >> >>> Two modules sounds right. They *could* have the same name, or > >> >> >>> artifactid, and reserve the first two version numbers to denote > the > >> >> >>> compatible jsf version, e.g. 1.1.x and 2.0.x. I can see these > being > >> >> >>> yet other independently releasable modules... (related to the > other > >> >> >>> thread). > >> >> >>> > >> >> >>> Kalle > >> >> >>> > >> >> >>> > >> >> >>> On Mon, Oct 25, 2010 at 4:29 AM, Deluan Quintão < > [email protected]> > >> >> >>> wrote: > >> >> >>> > Hi All, > >> >> >>> > > >> >> >>> > I have a issue regarding JSF/Facelets versions and would like > to > >> hear > >> >> >>> your > >> >> >>> > opinion. > >> >> >>> > > >> >> >>> > The tags I develop were meant to be used with JSF 1.2/Facelets > >> >> 1.1.14. > >> >> >>> > > >> >> >>> > I don't use JSF 2.0 in my company yet, but taking a quick look > on > >> it, > >> >> I > >> >> >>> saw > >> >> >>> > that Facelets were integrated in the 2.0 and the packages for > it > >> have > >> >> >>> > changed! > >> >> >>> > > >> >> >>> > How do I go about it? Two libs, shiro-facelets (for JSF > >> 1.1/Facelets) > >> >> >>> and > >> >> >>> > shiro-jsf (for JSF 2.0) ? > >> >> >>> > > >> >> >>> > What do you think? > >> >> >>> > > >> >> >>> > Thanks, > >> >> >>> > Deluan. > >> >> >>> > > >> >> >>> > ---------- Forwarded message ---------- > >> >> >>> > From: Les Hazlewood <[email protected]> > >> >> >>> > Date: Fri, Oct 22, 2010 at 3:50 PM > >> >> >>> > Subject: Re: Shiro tags not working in Icefaces page. > >> >> >>> > To: Deluan Quintão <[email protected]> > >> >> >>> > > >> >> >>> > > >> >> >>> > Hi Deluan, > >> >> >>> > > >> >> >>> > Sounds good! > >> >> >>> > > >> >> >>> > I have one quick request: could you please send further emails > to > >> >> the > >> >> >>> > [email protected] list? All development-related discussion > >> >> should > >> >> >>> > be out in the open with the community so everyone benefits from > >> the > >> >> >>> > discussion, not just me ;). I didn't CC the dev list in case > you > >> >> >>> > needed to keep this communication private for some reason, but > if > >> >> not, > >> >> >>> > can you please use the dev list from now on? Thanks! > >> >> >>> > > >> >> >>> > As for the source/Maven organization: > >> >> >>> > > >> >> >>> > If the classes you're using are in JDK 5 without needing any > 3rd > >> >> party > >> >> >>> > dependency, your classes can go directly in the 'web' module. > If > >> >> they > >> >> >>> > can, then the starting package should be > >> org.apache.shiro.web.faces > >> >> to > >> >> >>> > be congruent with the other similar web support packages that > >> exist > >> >> >>> > (e.g. org.apache.shiro.web.servlet, org.apache.shiro.web.tags, > >> etc). > >> >> >>> > > >> >> >>> > If your code requires a 3rd party library, the base code > >> >> >>> > (JDK5-compliant) should go in the 'web' module as noted above, > and > >> >> any > >> >> >>> > 3rd-party implementation-specific code would go into a new > >> 'support' > >> >> >>> > module, i.e. <project root>/support/myfaces (or similar, > depending > >> on > >> >> >>> > the library). > >> >> >>> > > >> >> >>> > As for mercurial/git, Apache only uses subversion, so we use > that. > >> >> >>> > The best way to share code with us is check out the code from > >> >> >>> > subversion (trunk), make edits there, and upload patches to > Jira. > >> >> >>> > > >> >> >>> > Cheers, > >> >> >>> > > >> >> >>> > Les > >> >> >>> > > >> >> >>> > >> >> >> > >> >> >> > >> >> > > >> >> > >> > > >> > > >
