Let me know if you need me to create anything (modules, etc.). I have full rights, so it should be easy, just send me names. It's VERY easy to upload releases - especially if you use the existing build.xml as a template. I added a "release" task that will generate bin.zip, bin.tar.gz and src.zip, src.tar.gz files - then use the "ftp" task to upload to SF.
Then read the docs to determine how to release: http://sourceforge.net/docman/display_doc.php?docid=6445&group_id=1 HTH, Matt > Well put John. I am +1 for this approach. What permissions in SourceForge > are necessary to make the modules appear ("directed to any seasoned Source > Forge Admin")? If I have sufficient permissions and group consent, > I will go ahead and make modules for John, Myself and any others > who want to participate. > > I further propose that if you are willing to put your refactorings > out there, they should only be considered if sufficient > documentation and examples accompany them. A readme, buildme, seeme > and whyme set of files? Get me? > > This might correct that the way we are progressing with "one off" > bug fixes and a tendency towards struts as an assumed underlying framework > > Ben > > ----- Original Message ----- > From: "John York" <[EMAIL PROTECTED]> > To: "Scott Smith" <[EMAIL PROTECTED]> > Cc: "displayTag" <[EMAIL PROTECTED]> > Sent: Friday, March 28, 2003 8:46 AM > Subject: Re: [displaytag-devel] Whither Future Development after 0.8.5? > > > Scott, I've also got a completely refactored version of it. I've been > > trying to make it backwards compatible, but it seems almost hopeless. With > > the way I've got my tag setup, many of the features of the existing tag > > aren't part of the tag anymore and can be done with simple JSP. I've got > > what seems to be a decent Model-View-Controller structure for the tag. The > > JSP part ends up being a simple iterate that allows any other JSP within > > it, which automatically lets things like 'autolinking' and 'decorating' > > happen without any support within the tag itself. I think we need to focus > > the features of the tag more and make it more easily customizable within > > the JSP rather than adding features in the code. > > > > My structure simply iterates over a collection, fills in a table model > > with the data, then once it has the dataset, it renders it using one of > > the extendable view classes. This works very well in use and my company > > has been using it for close to a year now, so it's very stable. My design > > isn't perfect and I know could use some help in a few places. > > > > That being said, I'm sure many others have done similar things. In > > sourceforge, we can have multiple modules, so should some of us add our > > 'proposal' refactorings as a starting point? Regardless, we need to decide > > whether we will try to support backward compatability fully or only > > partially. I had planned to get full backward support done, but there are > > just too many features supported by this tag that in my opinion are > > outside the scope of it. > > > > John > > > > > > On Thu, 27 Mar 2003, Scott Smith wrote: > > > > > Everyone, > > > > > > Looks like 0.8.5 is "delivered". Congratulations to > > > all concerned! > > > > > > Now, what's next? > > > > > > I have one immediate agenda: I'd like (me and/or > > > anyone else) to quickly refactor the existing code > > > according to modern object-oriented/pattern practices > > > to achieve the following benefits: > > > > > > 1. Reusability. It is virtually useless to subclass > > > anything in the TableTag; its methods are excessively > > > "coarse". > > > > > > 2. Appropriate Coupling. There is no reason for the > > > same class to handle HTML output _AND_ XML _AND_ Excel > > > _AND_ etc. etc. These renderers should be in separate > > > classes. > > > > > > There are probably other reasons as well, but these > > > reasons are the driving forces for me. I have already > > > refactored TableTag for internal use and have added > > > several features I think the group would be interested > > > in; however there is no chance of folding them in > > > smoothly with the code implemented the way it is. > > > > > > When this is done, it will be much more likely that > > > people who are presently hacking away at copies of > > > this tag library will instead offer their enhancements > > > to the open source. > > > > > > Perhaps we could, as a group, play with a class > > > diagram; when we're close one of us could refactor the > > > actual code. Maybe test the code on a branch. > > > > > > Anyways, I'm in favor of moving now while the table > > > tag is not so complex that it can't be done quickly. > > > > > > Any other thoughts? > > > > > > -Scott Smith > > > > > > > > > ------------------------------------------------------- > > > This SF.net email is sponsored by: > > > The Definitive IT and Networking Event. Be There! > > > NetWorld+Interop Las Vegas 2003 -- Register today! > > > http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en > > > _______________________________________________ > > > displaytag-devel mailing list > > > [EMAIL PROTECTED] > > > https://lists.sourceforge.net/lists/listinfo/displaytag-devel > > > > > > > -- > > John York > > Software Engineer > > CareerSite Corporation > > > > > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: > > The Definitive IT and Networking Event. Be There! > > NetWorld+Interop Las Vegas 2003 -- Register today! > > http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en > > _______________________________________________ > > displaytag-devel mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/displaytag-devel > > > > ------------------------------------------------------- > This SF.net email is sponsored by: > The Definitive IT and Networking Event. Be There! > NetWorld+Interop Las Vegas 2003 -- Register today! > http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en > _______________________________________________ > displaytag-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/displaytag-devel -- Matt Raible, Raible Designs, Morrison CO US -- Tel: +1 303 979-5340 -- Mob: +1 720 560-8460 -- Fax: +1 508 256-6471 -- Web: http://www.raibledesigns.com ------------------------------------------------------- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en _______________________________________________ displaytag-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/displaytag-devel
