On Aug 7, 2007, at 1:19 PM, Eric Dalquist wrote: +1 for releasing GA, and documenting this as a known issue. Further musings below:
Points of order: * The tag in SVN is rel-2-6-0-GA. The tag for the last couple minor releases was 2-5-3-GA & 2-5-3-1-GA. All previous releases though just used the version number. Did we intentionally change the naming convention and have I just forgotten it? * In the future, we should likely vote against a specific changeset or milestone being tagged as a GA, not on releasing the GA tag. Afterall, if we voted no what would we do? Retag GA but pointed at a different revision number? Seems to violate the contract of a tag if it changes over the lifetime of the repository. > the version of DOM needed to be changed so the JAR had to be put in > the > JDK's endorsed directory. I just double checked and I don't have any > libraries in my JDK's endorsed directory. Even for JAXP in JDK 1.4 it was possible to build & run w/o using the JDK endorsed directory - Dan M. figured out some classpath magic we used in the myRutgers build for a while. Having pointed that out... >> IIRC, the requirement is to put the xalan-2.7.0.jar in to the >> endorsed >> directory on the JDK specifically for use by uPortal. By putting >> that jar >> into that directory (which affects the entire JDK that's being >> used), I >> don't think this is necessarily just a Netbeans issue. Some observations: 1. This doesn't block deploying/running uPortal. 2. Most of the core development team isn't currently using Netbeans. My take: First we should make sure this issue is documented in JIRA, then include the JIRA number in all these emails so Google pops up this thread :) We could even CC: JIRA on this thread ;). While likely fixable (maybe requiring editing Netbeans app bundle on the Mac, or ANT classpath manipulation) I don't think this issue is something that we can call a blocker. My thoughts aren't because supporting Netbeans isn't important, but because none of the core developers using, fixing and confirming that this is fixed and stays fixed is going to be hard, and cutting a release before Fall madness is very important. Now, if Tim, Andy, or someone whose more familiar with Netbeans wants to take a lead in exploring alternate deployment scenarios or other fixes I can volunteer some of my time as well, since I may need to fix this for some training I'm slated to give to some Netbeans users. I do use a Mac as my primary machine, though admittedly I haven't done more than poke at Netbeans. I think it is worth targeting for a 2.6.1 -- especially if the changes are small. I do think it would be worth cutting a 2.6.1 that contained nothing but a fix like this, and it would be nice to have smaller, easier to merge dot releases. Side thought, Does Netbeans run on Apple's Java 6 beta? Anyone know off hand what version of Xalan is included with Java 6? >> Is there a way to install this jar so that there is less of an >> impact to the >> entire JDK? For example, the endorsed/lib directory in Tomcat >> would be a >> good place since its on the classpath for all its own internal >> workings and >> web applications. And, this directory could easily be added to the >> classpath for the command line tools in build.xml. This would >> (theoretically) allow Netbeans to be used without changing the JDK. I believe so, but opine that this is not a blocker to 2.6 -- because it doesn't affect deployment and the timeline/resource for fixing it is unclear. Jason -- Jason Shao Application Developer Rutgers University, Office of Instructional & Research Technology v. 732-445-8726 | f. 732-445-5539 | [EMAIL PROTECTED] | http:// jay.shao.org -- 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-dev
