> 18.09.2001 18:11:42, "Remy Maucherat" <[EMAIL PROTECTED]> wrote:
>
> >The title almost says it all. If we do, Struts will become a required
> >dependency, which I think is totally acceptable, as lots of
> >components will eventually use the taglib.
> >
> >Remy
> >
> >
>
> I wouldn't make it a requirement just yet. IMHO there are already too
> many dependencies for the default target, or rather the default target
> shouldn't be 'full-dist', and thus require all sorts of other packages
> (catalina, jdom, httpclient, for example).
Catalina should not be a required dependency. I don't see how we can avoid
jdom and http client, though.
I'm fine with changing what the default target is, but I plan to include the
taglibs in the full-dist build.
> Anyway, if we add the admin-webapp to the main build, that would
> implicitly also include the taglibs dist.
>
> While on the topic of the admin-webapp: I'm still a bit uncertain
> about the appropriate directory & package structures.
The one you used is fine. Feel free to commit it anytime you want.
> I've attached a
> zip that you can extract into a freshly checked-out-of-cvs slide, thus
> adding the source, JSPs, and build.xml additions required to build the
> admin-webapp. The ant target is 'admin-dist', which should create a
> slide-admin.war file in ${slide.dist}/slide/webapp. I'd be grateful
> for any comments. Some points to consider:
> - The users display uses the default role names 'user' and 'root', and
> if the user changes those names in the namespace configuration, the
> users will not be displayed, unless the user changes the users.jsp
> file correspondingly.
> - Creation of users uses the UserRoleImpl and RootRoleImpl classes, so
> the app can not yet be made aware of alternative implementations,
> and there's a compile&runtime dependancy on slide-roles.jar
Roles management should wait for Slide.next, IMO, since the roles is one
feature which will probably be refactored.
> - Error reporting of slide-exceptions that occurr while
> adding/removing/changing users and killing locks are not yet
> displayed.
> - The generated HTML is displayed fairly well on a wide range of
> browsers (IE, NS6/Mozilla, Opera5, Lynx, w3m), but still looks a bit
> awkward in NS4.x (Not that anyone should be using NS4.x nowadays
> ;>).
These limitations look perfectly acceptable to go to beta.
I would like to add support for the new non-static domain, which shouldn't
be too hard (you lookup for the NAT or namespace reference in the servlet
context).
Remy
