JIRA tickets for changes are good. If you're in doubt of any change, bring it up on the list. If you think you're right, just go for it. Changes can always be rolled-back if they turn out bad.
If you know there is someone else is actively working on the plugin it could prevent conflict if you contact him/her before doing some drastic changes. However, a jira ticket could serve the same purpose. /Anders On Wed, May 15, 2013 at 4:22 PM, Eric Dalquist <[email protected]>wrote: > Thanks for welcoming me to the mojo development team. I've been doing Java > development in the open source world for close to 10 years now. I'm the > technical lead of the uPortal <https://github.com/jasig/uPortal> project, > a enterprise portal targeted at higher education. Most of the deployments > and contributors are .edu's or companies that provide professional services > to .edu's. > > My interest in the JSPC plugin stems from the uPortal project as we end up > with a lot of portlets all rendering JSPs on a page and initial load times > on a fresh server start can be pretty bad and even cause some weird > problems due to how the portlet specification works. So pretty much all of > the portlets that uPortal uses and all uPortal deployers use the JSPC > plugin to handle pre-compilation and solve the first-load issue. > > As was pointed out in the vote I had forked the JSPC plugin and have > actually cut a 2.0.0 release of it under the org.jasig groupId. I did a > pretty significant refactoring and updating of the portlet so before I just > do "merge" of that and completely re-write the Codehaus version of the JSPC > plugin is there some sort of discussion I should kick off? > > Thanks again for giving me access, I just want to make sure I follow the > established contribution policy. > > -Eric >
