> I have suggested delivering the jetty-plugin UNPACKED numerous times (as > you will now find it if you build HEAD).
Unpacked means there is a deploy/jetty-plugin/* I have not looked, but I was hoping to avoid this type of inconsitency in the default release. Personally I think the unpacked stuff is a hack... sure some people want it, and we have it so they can use it, but I think it is ugly and confusing and we should avoid using it in the default release. Or do you mean something else by unpacked? > There is NO unpack/repack needed to edit the configuration. You just > edit deploy/jetty-plugin.sar/META-INF/jboss-service.xml. Yes, I see, so this is what I wanted to avoid... now we have just complicated the configuration of the system even more... thanks. How does this make it any easier for a user to manage the configuration? Should we now unpack all sars like this so things are consistent? No this is garbage. > If I see one more reference to having to pack/repack the sar, I will go > mad. Well, the problem is not pack/repack anymore... > The only difference between what you suggest and I suggest is the > location of the Jetty files. Right so do you not see that you have special cased Jetty, based on a hack, which will only confuse users... why, why, why? > You want to split them up (into 2 different dirs) across the JBoss distrib. > > I want to keep them together (in 1 dir), so that it is clearer exactly > which parts of JBoss constitute Jetty, in order that anyone can replace > that module trivially. > > I can't make it much clearer than that. Ok, so you keep sidestepping the solution which seems to make the most sence. 2 files, jetty-plugin & jetty-service. This is still easier to manage and maintain than the unpacked version. It even provides better isolation, so that the files in the plugin archive are consistent. Really, who benifits from the exploded archive? Who? > However in the interests of conformity and world peace, I shall fall on > my sword and repackage Jetty according to a greater wisdom. > > Ouch :-) This has very little todo with world peace Jules... perhaps the sanity and learning curve of users... the ease of use by administrators and the simplification of release documentation. Fuck me... I get yelled at for using an abstract class (which was fully justified and isolated the thread logic)... with wild crys for how much I have complicated the system... blah, whatever. This is where the complication comes in. Special casing configuration of a core component... um for what reason? Because you can? You can and therefor you did complicate the configuration of the system? Tell me Jules, how does this simplify the user/admins expercence (which is what I have been pushing for all this time)? It seems that it only simplifies the release management, which I think should be simple, but there are alternatives to simplify both... you just do not want to listen to them. Why? --jason _______________________________________________________________ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
