Hi Tim, many thanks for your very comprehensive reply. I am assuming that changing directory to [dspace-src]/dspace within the second command, before running mvn package is to ensure that the build process for the overlay modules (where customization / extensions are supposed to take place) work? (this should be the process you call quick build If I understand correctly)
P.K. P.S: Is there somewhere a brief explanation (or tutorial) about what the so called 'assembly' process (which I assume has its own maven profile) is? On Thursday, June 30, 2016 at 8:18:12 PM UTC+3, Tim Donohue wrote: > > Hi P.K. > > Those two Travis CI steps are doing two different things (based on the > flags passed to those Maven commands). The comments in the .travis.yml are > meant to describe the two commands: > > https://github.com/DSpace/DSpace/blob/master/.travis.yml > <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2FDSpace%2FDSpace%2Fblob%2Fmaster%2F.travis.yml&sa=D&sntz=1&usg=AFQjCNHpmSuuhygbsANn3QwlXh94AbeqHA> > > 1) The first command (mvn clean install) is the ONLY one that runs Unit > Tests & Integration Tests. It's role is to run all the tests for all API > classes, and install the resulting JARs in the .m2 (Maven cache) on the > Travis CI server. This command runs from the [src] directory, and > builds/tests *all* core modules. > > 2) The second command (mvn package) takes those installed JARs, and then > runs a test build of Mirage 2 (for XMLUI) and other modules *from* the > [src]/dspace/ directory (ensuring the "quick build" works). > So, the first command is the one that is often more likely to fail, as it > is where we run our tests. But, the second command is there to also ensure > the quick build and Mirage 2 build process is still working properly. > > The reason we split these up is that Travis CI has very strict policies on > memory usage for free accounts (we have a free acct). They could be run as > a single step. But, in the past, doing so often caused us to hit the Travis > CI memory usage limit (at which point Travis *kills* your tests, and they > all result in failures). Splitting them up helps us remain under that > limit. > > - Tim > > On 6/30/2016 5:49 AM, Pantelis Karamolegkos wrote: > > In the .travis.yml file, why is a > > mvn clean install (line 42 of the latest commit on master) > > followed by an > > mvn package (line 47) > > given that the mvn install will ALSO package the project(s)? > > (i.e. install seems to be a superset of package in maven terms) > > On Monday, June 6, 2016 at 6:56:35 PM UTC+3, Pantelis Karamolegkos wrote: >> >> Assuming someone wants to fork and proceed with heavy DSpace >> customization, what is the recommended testing strategy? >> i.e. which of the tests should be kept in a CI environment like travis? >> (apart from our own custom tests we may set up) >> (note: 99% of the customization will most likely take place on jspui) >> Is there any documentation on dspace's (Unit/Integration) tests? >> >> Thx, >> >> P.K. >> > -- > You received this message because you are subscribed to the Google Groups > "DSpace Technical Support" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to dspace-tech...@googlegroups.com <javascript:>. > To post to this group, send email to dspac...@googlegroups.com > <javascript:>. > Visit this group at https://groups.google.com/group/dspace-tech. > For more options, visit https://groups.google.com/d/optout. > > > -- > Tim Donohue > Technical Lead for DSpace & DSpaceDirect > DuraSpace.org | DSpace.org | DSpaceDirect.org > > -- You received this message because you are subscribed to the Google Groups "DSpace Technical Support" group. To unsubscribe from this group and stop receiving emails from it, send an email to dspace-tech+unsubscr...@googlegroups.com. To post to this group, send email to dspace-tech@googlegroups.com. Visit this group at https://groups.google.com/group/dspace-tech. For more options, visit https://groups.google.com/d/optout.
