Re: [uportal-dev] Can't initportal 2.6GA -- Resolution

2007-08-21 Thread Drew Wills
I created JIRA UP-1800 (http://www.ja-sig.org/issues/browse/UP-1800) to track this effort, then I created a solution based on Alex's suggestion. The enhancement is checked into 2-6-patches & trunk, and the JIRA is resolved. As it stands, the only DTD that the EntityResolver can load locally i

Re: [uportal-dev] Requiring Jira issue ids in commit messages

2007-08-21 Thread Elliot Metsger
Yeah. I agree with Jason. No need to validate that the issue actually exists. Plus, I wouldn't want to be unable to commit if Jira was down or slow or whatever. Elliot Jason Shao wrote: On Aug 21, 2007, at 2:58 PM, Eric Dalquist wrote: Sounds like a good plan for the expressions. As for

Re: [uportal-dev] Requiring Jira issue ids in commit messages

2007-08-21 Thread Jason Shao
On Aug 21, 2007, at 2:58 PM, Eric Dalquist wrote: > Sounds like a good plan for the expressions. > > As for validating against Jira. I had thought about that but I'm > not sure I want commits to fail if Jira is down. Does anyone else > have thoughts on doing Jira issue ID validation? > > -Eric

Re: [uportal-dev] Requiring Jira issue ids in commit messages

2007-08-21 Thread Eric Dalquist
Sounds like a good plan for the expressions. As for validating against Jira. I had thought about that but I'm not sure I want commits to fail if Jira is down. Does anyone else have thoughts on doing Jira issue ID validation? -Eric George Lindholm wrote: > Eric Dalquist wrote: > >> I just ha

Re: [uportal-dev] Requiring Jira issue ids in commit messages

2007-08-21 Thread George Lindholm
Eric Dalquist wrote: > I just had the same comment from the CAS side. I think I'll replace > the 'JIRA Issue: AA-' with a rule that allows any commit through > that starts with 'AA-'. Just doing AA- anywhere in the > message is very likely to find false positives which is why I would

Re: [uportal-dev] Requiring Jira issue ids in commit messages

2007-08-21 Thread Eric Dalquist
I just had the same comment from the CAS side. I think I'll replace the 'JIRA Issue: AA-' with a rule that allows any commit through that starts with 'AA-'. Just doing AA- anywhere in the message is very likely to find false positives which is why I would require it at the start o

Re: [uportal-dev] Requiring Jira issue ids in commit messages

2007-08-21 Thread George Lindholm
Eric Dalquist wrote: > Sounds like everyone is for it (the CAS folks are as well), I'll work > on getting this set up next week. > > Currently the script will allow commits with any of these strings in > the message to go through (none are case sensitive): > NOJIRA > JIRA Issue: AA- > [maven-re

Re: [uportal-dev] Requiring Jira issue ids in commit messages

2007-08-21 Thread Eric Dalquist
Sounds like everyone is for it (the CAS folks are as well), I'll work on getting this set up next week. Currently the script will allow commits with any of these strings in the message to go through (none are case sensitive): NOJIRA JIRA Issue: AA- [maven-release-plugin] If people have sugg

Re: [uportal-dev] [uportal-user] Can't initportal 2.6GA -- Resolution

2007-08-21 Thread Eric Dalquist
That is a great link Alex, I was thinking there had to be a common EntityResolver impl that could look at the local file system first before going to the net. We'll look at using this for the portlet deployer for 2.6.1 -Eric Alex Vigdor wrote: > Hey Eric (and everybody), > Just a tip since

Re: [uportal-dev] [uportal-user] Can't initportal 2.6GA -- Resolution

2007-08-21 Thread Alex Vigdor
Hey Eric (and everybody), Just a tip since I've dealt with this problem a few times before, first with HyperContent. You just need to configure a SAX EntityResolver that will look up local copies of resources that are normally found online. This way you can leave doctypes intact and sti

Re: [uportal-dev] [uportal-user] Can't initportal 2.6GA -- Resolution

2007-08-21 Thread Jason Shao
On Aug 20, 2007, at 7:13 PM, Eric Dalquist wrote: > Moving this to the dev list. > > After further consideration I would also like to put of the 2.6.1 > release until more time can be spent on this issue. I'll be doing some > more digging tomorrow to see what the options are for a resolution to >