Hi P.K.
Correct. What I'm talking about as the "quick build" is merely the
building of the Overlay Modules. One of those overlay modules is the
Mirage 2 theme (which is a larger build process in itself), and that
theme is *only* built in that second command. So, that second step is
just there to ensure that overlay process & building of Mirage 2 is
functioning properly.
The "assembly" process for DSpace is merely the process of creating the
final [src]/dspace/target/dspace-installer/ directory (which is where
you can then run "ant" to install or update DSpace). That "assembly" is
controlled by the [src]/dspace/ module, specifically in this Maven
Profile: https://github.com/DSpace/DSpace/blob/master/dspace/pom.xml#L45
- Tim
On 6/30/2016 2:46 PM, Pantelis Karamolegkos wrote:
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 [email protected] <javascript:>.
To post to this group, send email to [email protected]
<javascript:>.
Visit this group at https://groups.google.com/group/dspace-tech
<https://groups.google.com/group/dspace-tech>.
For more options, visit https://groups.google.com/d/optout
<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 [email protected]
<mailto:[email protected]>.
To post to this group, send email to [email protected]
<mailto:[email protected]>.
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 [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/dspace-tech.
For more options, visit https://groups.google.com/d/optout.
