On Fri, 25 Feb 2005 22:50:11 -0500, James Mitchell <[EMAIL PROTECTED]> wrote: > > ----- Original Message ----- > From: "Joe Germuska" <[EMAIL PROTECTED]> > To: <dev@struts.apache.org> > Sent: Friday, February 25, 2005 3:01 PM > Subject: struts build change questions > > > Hey: > > > > I just went to do a couple of things with Struts SVN, and I wanted to > > check a couple of things James has done: > > > > If struts-mock is going to be a dependency, shouldn't it really be > > next to the others? James, I believe you voiced some hesitation on > > this, but at the time I didn't track that closely. I think it's just > > a little bit weird to break what is otherwise a very rigorous pattern > > for this one special case. I wouldn't veto it, but I wanted to at > > least give it one moment's consideration... > > Yes, I noticed that (once upon a time) we were using those in one place > until we split apart the repository. I wasn't sure if such a simple > set of classes deserved subproject-like status amoung the rest. I > wouldn't want to do that for everything, or we'll soon be overrun with > simple subprojects littering the landscape and causing more confusion > about our build than there already is ;)
It's true that this set of classes is simple, but it would be worth considering something I'm doing with Shale ... publishing the set of corresponding mock objects as a first class library, suitable for use by *applications* that want to build unit tests for their own classes (as well as for use in testing the framework itself). I plan to publish "test-framework" versions that match the corresponding "core-library" version, so it makes sense to have them parallel in the source tree as well. It seems to me that a framework which ships (and supports) a ready-made set of mock classes will have an advantage in today's world. > > My way of dealing with that was to put it right under core (since you > have to build core first anyway) and have it kicked off at the end of > 'maven dist'. > > I sort of did the same thing under apps. There is a dao folder there > that simply houses the mailreader database classes. My intention for > that was so to replicate what was already being done by Ant so that > other projects could 'borrow' that functionality. You'll notice when > you build apps, the reactor kicks off and builds dao first, then does > the rest. > > I don't believe Craig is using that jar for shale-mailreader yet. But > it's available non-the-less. > I was waiting for things to settle down a bit before re-establishing this dependency :-). > > > > The other thing which caught me was the change of the core project > > name from "struts" to "struts-core". In this case, it is moving > > towards a more close adherence with the pattern, and so while I > > wasn't sure at first, I think this is cool with me. > > Well, I'm not married to either one, but if it were struts.jar, then > with the next release, you would need struts.jar and struts-taglib.jar > whereas just one version ago you only needed struts.jar and you got > got both (whether you knew it or not). Just seems like it will only > confuse people, but (in all honesty) the same could be said about: > > ,-> struts-core.jar > struts.jar ---> struts-taglib.jar > `-> struts-tiles.jar > FWIW, in retrospect, I see that I chose "core-library" in both faces and shale. Might be worth considering. > > > > > Joe Craig > > > > -- > > Joe Germuska > > [EMAIL PROTECTED] > > http://blog.germuska.com > > "Narrow minds are weapons made for mass destruction" -The Ex > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > -- > James Mitchell > Software Engineer / Open Source Evangelist > EdgeTech, Inc. > 678.910.8017 > AIM: jmitchtx > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
