> Multiple scanners make it difficult at best to define deployment ordering. > URLDeploymentScanner is already written (by you, I might add) to handle two
Thanks for reminding me of the obvious... > forms of deployment: Directory scanning and direct URL deployment. I am > trying very hard NOT to complicate this issue, but we do need a solution > for > exploded archives. You are trying very hard to implement exploded archives... which I personally have little need for. Granted it sounds usefull, but I don't think it should have been added to 3.0 this close to final... thus I think we should hold off, fix the deployment dependencies outside of the scanner (as was the assumption when I designed this level), then implement your exploded scanner as a peer to UDS. If you must add an explosed scanner now then subclass UDS and document how to replace UDS to gain this exploded behavior. I thought you said you were going to make sorting pluggable... why don't you just go do that and leave this issue for later? > The simplest at this point is to preserve the > functionality of URLDeploymentScanner, and that means make it understand > exploded archives. I think it would be simpiler to subclass, thus only complicating the config for the very small percentage of users who will use this. If I am wrong, fine we will have this fixced for 3.1 and then we will all be happy. > You call it a hack, and I agree. However, we already have a hacked system > that will hopefully be fixed shortly. This is a rather lame answer... lets hack it up more because it is hacked already? You don't work for microsoft do you? > Forcing me down the awkward path of > well architect code that must function within a design that has outlived > its > usefulness is not the right answer. Ic, so because your functionality does not fit into the DS design due to a problem with the deployment dependency system.... the DS design is now useless? And you would rather hackup a component in this flawed design rather than work on fixing the root of the problem... because you want to implement a feature that you are unwilling to put into a replacement component... blah > Let me hack this for now, and spend my > time on a better designed rewrite. If you want to add this, the make a subclass and put it there. Leave UDS as the default as it works as is. We are trying to get a final release out... which means we should not add frivoluos stuff to the core, just because we can. I don't want to hold you back from adding this functionality, as it does sound useful... but don't let it get in the way of the already working components. I agree there are some issues with the system as a whole, but we don't have the time to fix them such that DS peers will work... though if the dependencies are handled at a higher level, then all of this sorting timing crap is just nonsense. In fact I think that the URLComp* stuff is just another hack to make up for defficencies in the dependency system. * * * David, if you are reading this... and got this far down... what is the plan to have this issue tied down and solved once and for all. I think the approche that dain, you and I discussed in Tahoe is along the correct lines. Do you have any idea when the wrinkles will be sorted out? --jason ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/ _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
