All, I'll play 'devil's advocate' a bit more, based on Sands' good points.
On 8/2/2010 9:50 AM, Sands Alden Fish wrote: > - Maven is #1, a developer's tool, and #2, implements best-practices. > Changing the default behavior is implementing less-than-best-practices. I agree that Maven is a developer's tool -- the oddity here is that for DSpace, we are also using it as an installation tool for end users. > > For #1, I mean to say that Maven is not a basic end-user's tool, and we > shouldn't make compromises based on a scenario that the tool wasn't > designed for. Don't the binary releases exist for for those who don't > need to work at the level of source code? Documentation (the same that > would suggest an inexperienced user run `mvn package`) could easily > describe to the user why they might want to run `mvn > -Dmaven.test.skip=true package` instead. It's worth pointing out that "binary" releases & source releases both require that users still run 'mvn package' during the installation process. In this way, our "binary" releases are not truly a "binary" installer -- they just don't include the full Java source code (instead they only download the necessary JARs via Maven). Sands is correct that we could change all our install instructions to have that extra "-Dmaven.test.skip=true" option. This does add an extra (albeit small) layer of complexity to the install process. That extra layer of complexity may or may not lead to more install/upgrade questions or confusion on listservs. (It's hard to say for sure. It likely all depends on whether people follow the new install/upgrade instructions word-for-word, or just do what they've always done in the past.) [As a sidenote:] I'd like to remind us all that the more complex we make our installs/upgrades, the more we begin to build a DSpace which requires (or highly recommends) that institutions need to have a developer to install/use DSpace software. I want to avoid this direction, as in reality, we are trying to support a community of 900+ institutions who all currently run DSpace (and have many different levels of developer support available). In itself, this small change to install instructions may not add much additional complexity, but I just wanted to bring up this concern (which has been in the back of my mind for some time). In my mind, the root of the matter is that we *don't* use Maven just as a development tool (it's also our "installer"). If it was only for development, Sands is correct that our choices would be obvious. E.g. if we had something like a OneJAR installer (http://one-jar.sourceforge.net/), similar to Fedora, we wouldn't need to require Maven for all installs/upgrades (and we could recommend it only for sites with developer support or having extra customization needs). > As for #2, yes, we can recommend that developers should always include > this switch to run the tests, but the reason that it is default behavior > in Maven is because inevitably, people take short-cuts or forget to > cover their bases, as good as a community is at being comprehensive. I > think this should stay as a default, as it was intended. Couldn't we setup a Continuous Integration server to help keep us honest? We could have a Bamboo server set up to auto-run these tests on a regular basis and let us know if developers are taking short-cuts or accidentally forgetting to cover their bases. So, there may be other ways to still get the benefit of the ongoing unit testing (if we decide we need to disable unit testing by default). I should mention, I'm really just trying to advocate for more discussion of options here (i.e. I'm not trying to force us into a particular direction). If we all determine that it's not a big deal to change our install instructions to require the extra flag to disable testing, then that's fine. I just wanted to point out that we need to think about how this change may/may not affect all 900+ institutions using the software and not just our smaller, highly dedicated team of developers. - Tim ------------------------------------------------------------------------------ The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm _______________________________________________ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
