upgrading uP3 to acegi security 1.0.1
gjgi...@gmail.com
I'm planning to check in the changes for acegi 1.0.1 but wanted to run
the details past everyone and make there are no objections.
Changes from acegi 0.8.3 to 1.0.1 relevant to uP3:
- package structure change from "net.sf.acegisecurity" to
"org.acegisecurity"
- Interfaces Context and SecureContext replaced by interface
SecurityContext
- AuthenticationDAO replaced by UserDetailsService
- SecurityContextHolder replaced by ContextHolder
There were a significant number of files changed in the uP3 codebase,
most significantly security_context.xml. If anyone wants a detailed
listing of the changes for each file let me know and I can email it to
you.
If there are no objections, I'll commit the changes tomorrow morning.
Gary
jayshao
> I was granted committer access. Thanks Scott for the fast turn around.
>
> I'm planning to check in the changes for acegi 1.0.1 but wanted to run
> the details past everyone and make there are no objections.
If we're looking to "do things right" then I think the process should
look like:
1) Create a JIRA issue briefly detailing the change, benefits, yada...
2) Create a patch as an attachment to the JIRA issue and email this
list with a link
3) Give a couple days for people to look at it (esp. if it touches lots
of pieces) and then commit it.
I know in the past we've talked about wanting to grow a culture of
patch submission to broaden the number of people who might put in
bug-fixes and the like, this seems like a good opportunity.
Jason
Scott Battaglia
>
> If we're looking to "do things right" then I think the process should
> look like:
>
> 1) Create a JIRA issue briefly detailing the change, benefits, yada...
> 2) Create a patch as an attachment to the JIRA issue and email this
> list with a link
> 3) Give a couple days for people to look at it (esp. if it touches lots
> of pieces) and then commit it.
>
> I know in the past we've talked about wanting to grow a culture of
> patch submission to broaden the number of people who might put in
> bug-fixes and the like, this seems like a good opportunity.
>
to upgrade Acegi versions is a good idea I don't think he needs to
submit a patch or wait a few days. I don't believe committers to the
uPortal 2.x branch submit patches for every JIRA issue (though I could
be wrong, I haven't checked in a while).
His changeset will be record of the changes made as long as he places
the JIRA issue in the commit message.
-Scott
Jason Shao
Gary is a committer to the project. So while I do believe a JIRA issue
to upgrade Acegi versions is a good idea I don't think he needs to
submit a patch or wait a few days. I don't believe committers to the
uPortal 2.x branch submit patches for every JIRA issue (though I could
be wrong, I haven't checked in a while).
His changeset will be record of the changes made as long as he places
the JIRA issue in the commit message.
My suggestion is less about the mandating a review of his changes - though in a distributed project without the opportunity for in-person code reviews that would be valuable, and more about providing an example for other people interested in contributing to the project.
Jason
gjgi...@gmail.com
http://www.ja-sig.org/issues/browse/UPT-172
I attached two patches. An Eclipse generated CVS patch and a zip with
the required changes that can be extracted on top of the project.
Gary
Andrew Petro
Thanks for creating the JIRA issue and attaching the patch. I
wholeheartedly think this is a worthwhile and "right" way to go about
business, making patches available so folks can review / selectively apply /
etc.
In the instant case, uP3 is in "sandbox" status, you're a committer on the
project, and this is the tip of what I hope will be a iceberg-full of active
collaboration with frequent and thorough communication among uPortal 3
developers. As such, I'd advise against introducing any delays before
commit on principle, instead going with a "continuous integration" approach
of, if you've got these changes, get them in there so we can go ahead and
experience them.
Try not to break anything and try to communicate. Your heads up about
intent to make a major commit was appreciated and seems "good enough" to me.
Of course, if you wanted to introduce a delay for other reasons, such as
being unsure about whether the proposed patch would work or having concerns
about the direction it adopts, then of course you could ask for review
before committing the patch. But let's not introduce any delays for the
sake of having delays.
Andrew
Gary Gilbert
I'm certainly on board with a continuous integration approach. Just
trying to play it safe. That said, I've checked the changes in so have
at them.
Gary