Re:[uportal-dev] [uportal-user] Can't initportal 2.6GA -- Resolution
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 this problem. Any ideas and suggestions are welcome. -Eric Cris J Holdorph wrote: > Just to bring this issue back to the foreground. I believe the state > of affairs that Drew describes below, means that one of the primary > goals stated by Eric Dalquist, for a 2.6.1 release, has not been met. > > "It looks like this deployPortletApp issue is causing quite a few people > problems. I'd like to get http://www.ja-sig.org/issues/browse/UP-1792 > fixed and a 2.6.1 release out ASAP to address the problem so people can > actually use 2.6." > > To sum up, I believe the issues with deployPortletApp (and drew gives > the latest version below) are with people trying to do "ant > initportal" from machines without general internet connectivity. > > The current "ant initportal" will still not run without internet > connectivity. Just pull out your internet connection and try it. > > Previously, Eric had said he would tag up 2.6.1RC1 tomorrow morning. > Does this mean we should hold off tagging that RC, until we have a > solution for "ant initportal" with no internet? > > Cris J H > > ps. fwiw, the 'logging' issue is at least fixed ;) > > Drew Wills wrote: >> For anyone who remembers and wondered about the issues with >> deployPortletApp that Sherwin of BYU was having last week... >> >> I worked with Sherwin off-list to get to the heart of the matter. >> >> At first, you'll remember, Sherwin wasn't able to connect to >> svn.apache.org to pull the portlet.tld because the server he was >> using wasn't able to see the outside Internet. We all agreed that >> the deployer should be reworked to pull that tld file from somewhere >> local. Additionally, Eric Dalquist pointed out that the version of >> the tld was incorrect: the script was pointing to the pluto 1.1 >> version where we needed 1.0.1. >> >> Eric created 2 JIRA issues (one to pull locally, one to fix the >> version) and I made the changes -- 2.6.1 will have both fixes. But >> Sherwin was still having problems. >> >> It turns out he wasn't able to deploy any portletApp that contains a >> web.xml file with a declaration like the following: >> >> > 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd";> >> >> It looks as though the XML parser will *always* try to load the DTD >> from java.sun.com, even if validation is turned off. I suppose it >> makes sense, since the DTD may contain entities (or default >> attributes?) used in the document. >> >> This means that the 'deployPortletApp' target requires an Internet >> connection, or (alternately) someone must manually remove the DTD >> references or entire declarations (it works without them) >> from the web.xml files of any portletApps that will be deployed. >> >> For comparison, the previous deployer used the WebAppDtdResolver >> class to intercept the XML parser's attempt to load a DTD and supply >> a local copy. The DTD to use was hard-coded (the 'systemId' >> parameter was not even referenced), such that all web.xml files >> essentially referenced the servlet spec 2.3 DTD... which is of course >> the major problem the new deployer fixes. >> >> Does anyone have a problem with *not* intercepting these DTD >> references? Does anyone have any other really cool suggestions? >> >> drew wills > > --- You are currently subscribed to [EMAIL PROTECTED] as: > [EMAIL PROTECTED] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/uportal-user smime.p7s Description: S/MIME Cryptographic Signature
[uportal-dev] uPortal 2.6.0 - default theme with AJAX on - horizontal scrollbar
I created Jira issue UP-1799 and attached as a comment the fix suggested by Parker. Can someone who is more skilled in the way of CSS verify his fix is correct. I will check it into subversion if someone can at least tell me it looks correct. Cris J H -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: [EMAIL PROTECTED] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
Re: [uportal-dev] Requiring Jira issue ids in commit messages
I'm all for. If you use Mylyn this will be done automatically for you when you do a commit. +1 George Eric Dalquist wrote: > Brad Szabo was kind enough to share a SVN script that would require a > Jira issue id to be referenced in the commit message for any commit. The > script can be bypassed explicitly by adding NOJIRA instead of an issue > ID and also allow commits from some automated tools such as the maven > release plugin. > > What are people's feelings on adding this script to our repository? It > would require developers to at least acknowledge if there isn't a > relevant Jira issue and remind us when we forget to add a reference to > the relevant issue that does exist. I don't want to add something that > is going to cause headaches or difficulties for commitiers but an > automated catch might be nice to help enforce good behavior. > > -Eric > -- [EMAIL PROTECTED] ITServices, UBC Senior Programmer Analyst phone:604.822.4375 fax: 604.822.5116 -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: [EMAIL PROTECTED] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
Re: [uportal-dev] Requiring Jira issue ids in commit messages
I am definitely for requiring a jira number. + 1 Eric Dalquist wrote: Brad Szabo was kind enough to share a SVN script that would require a Jira issue id to be referenced in the commit message for any commit. The script can be bypassed explicitly by adding NOJIRA instead of an issue ID and also allow commits from some automated tools such as the maven release plugin. What are people's feelings on adding this script to our repository? It would require developers to at least acknowledge if there isn't a relevant Jira issue and remind us when we forget to add a reference to the relevant issue that does exist. I don't want to add something that is going to cause headaches or difficulties for commitiers but an automated catch might be nice to help enforce good behavior. -Eric -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: [EMAIL PROTECTED] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
Re: [uportal-dev] Requiring Jira issue ids in commit messages
I'm in favor of it as well. I was just lamenting this morning, that another project I am on, does not have it and I hope they introduce it soon. Cris J H Andrew Petro wrote: Eric, I favor adopting the script. We use it internally at Unicon and headaches are minimal. It's relatively gentle and friendly -- since SVN is transactional you don't get broken half-commits with it, and it gives you an error message telling you how to conform to the commit message requirement, this even shows up in the Eclipse console. Andrew Eric Dalquist wrote: Brad Szabo was kind enough to share a SVN script that would require a Jira issue id to be referenced in the commit message for any commit. The script can be bypassed explicitly by adding NOJIRA instead of an issue ID and also allow commits from some automated tools such as the maven release plugin. What are people's feelings on adding this script to our repository? It would require developers to at least acknowledge if there isn't a relevant Jira issue and remind us when we forget to add a reference to the relevant issue that does exist. I don't want to add something that is going to cause headaches or difficulties for commitiers but an automated catch might be nice to help enforce good behavior. -Eric -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: [EMAIL PROTECTED] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
Re: [uportal-dev] Requiring Jira issue ids in commit messages
Eric, I favor adopting the script. We use it internally at Unicon and headaches are minimal. It's relatively gentle and friendly -- since SVN is transactional you don't get broken half-commits with it, and it gives you an error message telling you how to conform to the commit message requirement, this even shows up in the Eclipse console. Andrew Eric Dalquist wrote: Brad Szabo was kind enough to share a SVN script that would require a Jira issue id to be referenced in the commit message for any commit. The script can be bypassed explicitly by adding NOJIRA instead of an issue ID and also allow commits from some automated tools such as the maven release plugin. What are people's feelings on adding this script to our repository? It would require developers to at least acknowledge if there isn't a relevant Jira issue and remind us when we forget to add a reference to the relevant issue that does exist. I don't want to add something that is going to cause headaches or difficulties for commitiers but an automated catch might be nice to help enforce good behavior. -Eric -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: [EMAIL PROTECTED] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
[uportal-dev] Requiring Jira issue ids in commit messages
Brad Szabo was kind enough to share a SVN script that would require a Jira issue id to be referenced in the commit message for any commit. The script can be bypassed explicitly by adding NOJIRA instead of an issue ID and also allow commits from some automated tools such as the maven release plugin. What are people's feelings on adding this script to our repository? It would require developers to at least acknowledge if there isn't a relevant Jira issue and remind us when we forget to add a reference to the relevant issue that does exist. I don't want to add something that is going to cause headaches or difficulties for commitiers but an automated catch might be nice to help enforce good behavior. -Eric smime.p7s Description: S/MIME Cryptographic Signature
[uportal-dev] Merging & SVN
Not sure how many people here used the CVS merge functionality when committing to a branch & trunk or to multiple branches. If you did you may have noticed that SVN's merge support is less than stellar. I've started using svnmerge ( http://www.orcaware.com/svn/wiki/Svnmerge.py ) which uses properties to keep track of revisions that have and have not been merged between branches. The wiki page they have gives good examples of common use cases and can make moving changes between branches much easier. People are welcome to use this to facilitate merges and post questions about the tool here if you have them. -Eric smime.p7s Description: S/MIME Cryptographic Signature
