Page tree
Skip to end of metadata
Go to start of metadata


Angular meeting



Slack Logs (times are all CST)

Tim Donohue [9:52 AM]
@here: a reminder that we'll be holding our first DSpace 7 UI text chat meeting via Slack (starting in this channel) at the top of the hour. This is a status update meeting, so there's no formal agenda, but relevant links are at:

Tim Donohue [10:00 AM]
@here: It's DSpace 7 UI Meeting time! I'll get things started...

First off, as a reminder, we'll be meeting for an hour. The first 30 mins will be in this channel & include updates on Angular UI work (over the last week

The second 30 mins will be in #rest-api channel, where we'll do the REST API updates

@art-lowel : would you like to get us started here with updates on Angular UI work?

Art Lowel [10:01 AM]

The PR for the first version of the HAL serializer is ready

It takes a model class as a param to its constructor

e.g.: `new DSpaceRESTv2Serializer(Bitstream)`

It can use any model that has @autoserialize annotations


The PR also contains a validator, that can use JSON schema to ensure documents fit the spec

Weeding out malformatted responses before you start makes serialization easier, as you don't have to test whether everything exists before you do something with it

JSON Schema is something like XSD for JSON

I started with the default hal json-schema - we can expand on it later by adding rules more specific to dspace.

but our current mock responses don't fit that default hal schema (something about the structure of the `_embedded` element).
So the validator isn't used yet.

Building on the serializer PR, there's also a PR that adds a CollectionDataService and an ItemDataService

These services offer a `findById` method, and a `findAll` method with an optional `scope` param, for Items and Collections

The PR *doesn’t* have all the required documentation and tests at the moment.

I'd also like to refactor it, as there is too much code duplication between the Item and Collection Services, and their corresponding actions, reducers and effects.

But these services can be used to start making UI components such as collection homepages and item view pages

So I suggest that people review them as they are, and that we merge them ASAP so other work can start

Their issues will stay open until docs, tests and refactoring are complete.

Tim Donohue [10:05 AM]
Nice, sounds like some good progress here :wink:

Art Lowel [10:05 AM]
do you agree/disagree with that approach?

Tim Donohue [10:06 AM]
So, to clarify, we need to merge the HAL serializer first, #61 (ASAP). Then we'd merge the Collection/Item services (#62) and work to refactor them later?

Art Lowel [10:06 AM]

the HAL PR should be up to snuff

Bram Luyten (Atmire) [10:06 AM]
joined #angular-ui

Art Lowel [10:06 AM]
the other one isnt

Tim Donohue [10:07 AM]
That seems reasonable assuming the refactor work in #62 is still made a priority. It sounds like that's important and shouldn't be forgotten

Art Lowel [10:07 AM]
I’d still like other people to test them first

yes the issues will remain open until that is completed

Hardy Pottinger [10:07 AM]
"merge first" = "enforced testing" :wink:

Tim Donohue [10:08 AM]
@art-lowel : How does one go about testing the HAL Serializer (#61)? Is that one really just a code review (that we later test in #62)?

Art Lowel [10:08 AM]
I just hurried to get something out there people could start developing against

code review, and review of its unit tests

Tim Donohue [10:08 AM]
makes sense

Art Lowel [10:08 AM]
I made it against the unit tests

but it worked in practice when I was working on #62 :slightly_smiling_face:

Tim Donohue [10:09 AM]
Do we have a volunteer who wishes to help/perform a code review of PR #61? @wwelling is this of interest to you? I can also help, but might appreciate a second pair of eyes (my Angular is a tad rusty and needs brushing off)

Art Lowel [10:11 AM]
this part has very little angular specific code in it btw

James Creel [10:11 AM]
I have put a little time into the mock responses which need reconciling with the schema, so I may be of some service

Art Lowel [10:11 AM]
If you’re good with java, you should be able to work it out

Tim Donohue [10:11 AM]
Thanks @jcreel256. If you can help review #61, I'd appreciate it. I will also review it (though I have meetings all morning, and may not get to it till this afternoon)

How about a volunteer here on testing #62 as well? Anyone interested in helping move along the Collection/Item services?

Art Lowel [10:12 AM]
That one is more complex though

although I tried to give somwhat of an explanation in the PR description

Tim Donohue [10:13 AM]
Is there a recommended testing approach? Or is this another code review (for now), until we get UI components built out?

Art Lowel [10:14 AM]
I’d say, use it: create a component that uses CollectionDataService.findAll for example

and use it to list collections somewhere

then use the redux dev tools to see what state changes occur

Antoine Snyers [10:15 AM]
I’ll take a look at it :wink:

Tim Donohue [10:15 AM]
Thanks @antoine , sounds great! I can again look at the code, but not sure I'll get to testing. So, please let us know what you find!

Ok, we are 15mins into the meeting already. Other major updates to share while we are all here?

Art Lowel [10:16 AM]
I've looked up why yarn was removed from the universal starter project

The only mention I can find about this is: _“I"m going to remove yarn.lock since it causes too much merge conflicts”_ in this PR:

Looking in to it, merge conflicts with the lock file seem to be a problem with yarn, there is an open issue about it on github.

But it is a problem inherent with the use of lockfiles, so it also affects npm-shrinkwrap

Since the lock files for both tools are automatically generated, there's a chance they'll clash when two people independently add dependencies to them.

For now the solution to this issue seems to be to take `origin/master`'s version of the lock file, and then running yarn install again. That way yarn will merge them for you.


Since npm shrinkwrap lockfiles have the exact same problem I don't see this as a dealbreaker for yarn.

It will need to be automated as best we can in an npm script, and explained in the docs.

Tim Donohue [10:17 AM]
+1 to docs / automation here

It also doesn't sound like a dealbreaker to me. So, as there are benefits (and since yarn is "backwards compatible) I'm OK with us trying out Yarn

Art Lowel [10:18 AM]

last time @wwelling said something about using OpaqueToken for the config.

I did some reading about it, and I can see the benefits of injecting environment variables. It makes it easier to mock them during tests for example.

so that idea has my +1

Tim Donohue [10:20 AM]
Sounds good

Art Lowel [10:20 AM]
but I’m not sure I understand the details well enough to write a task for someone else to do it

so I wanted to ask @wwelling if he could write the issue, or implement it himself

Tim Donohue [10:20 AM]
@wwelling or @jcreel256 , any chance you could help out here (writing a task or implementation)?

We can touch base with them post meeting as needed. I don't want to wait too long for a response (in essence of time) :wink:

Art Lowel [10:21 AM]
makes sense

James Creel [10:21 AM]
excuse us, multitasking :slightly_smiling_face:

Tim Donohue [10:22 AM]
Are there other updates (either from @art-lowel or anyone else here)? Or other questions/topics folks want to discuss regarding Angular UI?

William Welling [10:22 AM]
I can create the task.

Tim Donohue [10:22 AM]
thanks @wwelling!

William Welling [10:22 AM]
I have some questions about the spinner feature.

Do we still intend to have a spinner that intercepts route change and displays conditional on pending asynchronous requests?

Tim Donohue [10:23 AM]
aforementioned "spinner" (PR):

William Welling [10:23 AM]
I recall saying a Guard CanActivate may be able to achieve this, but it may be easier than that.

Yes, I am curious on the requirement of this feature.

Art Lowel [10:24 AM]
Yeah, I believe last time we agreed you’d look in to it, and perhaps come up with an alternative

William Welling [10:24 AM]
A single page app should have notification when pending data is being requested, but I dod not think any navigation should be affected.

Art Lowel [10:25 AM]
The CanActivate would prevent you from navigating to the route before it was loaded?

William Welling [10:25 AM]
The navigation should occur immediately displaying whatever is available. A notification should only be for the asynchronous requests. If we end up having to wait between navigations it will be a poor user experience.

Such as selecting next page of a pagination or selecting a item from a list. The requests should be minimal and only retrieve data that is needed at the time and if it takes longer we should make other affordances.

The practical use of a user affected spinner is creation, save, or update where the completion of a request is necessary for any further user interaction.

Art Lowel [10:27 AM]
That’s a good point

William Welling [10:27 AM]
@art-lowel yes, that is correct. But could activate and set a process that enables the spinner and waits for the one to complete its asynchronous tasks.

James Creel [10:28 AM]
I've got to duck out for another quick meeting, and I will join the REST discussion a little late.

Tim Donohue [10:28 AM]
As we are running short on time here, I wonder if it'd be worth considering creating a (discussion) ticket for this in GitHub, so that @art-lowel and @wwelling can discuss in more detail & come to consensus? (and others can take part too)

Art Lowel [10:28 AM]
We can use the spinner issue that’s already there

William Welling [10:28 AM]

Art Lowel [10:28 AM]

Tim Donohue [10:28 AM]
In general, I wonder if such detailed discussions (and even requirements gathering/clarification) could be done more in GitHub Issues?

Hardy Pottinger [10:29 AM]
+1 github discussions

Tim Donohue [10:29 AM]
It might make these text chat meetings go a bit more smoothly, as it means we can bring *proposals* here, rather than having all the discussions here :wink:

But, it sounds like @wwelling has some good ideas here, I'd just recommend figuring out the final details/requirements in the ticket and come back with a proposal (as needed)

@here: As it has now been 30 mins, the meeting will now move into REST API discussions in #rest-api channel. If there are further angular-ui discussions, you can still hang out here, but my attention will move to #rest-api

Andrea Bollini [10:31 AM]
anyway, it is useful to have an half hour appointment to be sure that some discussion happen

Tim Donohue [10:33 AM]
Yes, this mtg structure is a work in progress here...i'm sure these first few Slack mtgs will be a bit "rough", but hopefully it will smooth out a bit more as we learn how to fit discussions into time allotted. Nonetheless, feedback is welcome :wink:

REST meeting



Slack Logs (times are all CST)

Andrea Bollini [10:22 AM]
in the #angular-ui is running the first half of the weekly dspace 7 meeting, we move here in 10 minutes

Tim Donohue [10:31 AM]
@here: we are now into the REST API updates portion of our meeting. @bollini, would you like to kick us off here?

Giuseppe Digilio [10:32 AM]
joined #rest-api

Andrea Bollini [10:32 AM]
ok since our last video call we are slowly moving thing ahead

first: the initial sourcecode is now on DSpace/DSpace

second: we have tracked some urgent activities here

third: some discussion around the mock data has started, see

fourth: we have an empty repository for the REST contract here:

this is more or less my agenda for the today chat

Tim Donohue [10:35 AM]
@bollini: good progress here as well!

Andrea Bollini [10:36 AM]
current source code is very rough and there are several issue. some already spot by @terrywbrady

Tim Donohue [10:36 AM]
Starting at the source code itself, I know @terrywbrady has been working to get things "running", so it sounds like we need a little concentration on docs & fixing builds (to allow other developers to jump in)

(ha, we said the same thing)

Terry Brady [10:36 AM]
I am trying to get the rest7 branch to run on our test server

progress since yesterday, but I am not yet seeing the /api/core/xxxs calls returning data

I am trying to troubleshoot that issue

It will be good to have this common branch to work from!

Andrea Bollini [10:37 AM]
if you access the / of the dspace-spring-rest do you see the hal browser?

Terry Brady [10:38 AM]
How do I access that? [myserver]/?

Andrea Bollini [10:39 AM]
are you deploying the war as root? is so, yes

I have it under localhost:8080/dspace-spring-rest

Terry Brady [10:39 AM]
I am using the old mvn/ant workflow so I am not yet convinced that I am deploying the right stuff

Andrea Bollini [10:40 AM]
mmm... I see

Tim Donohue [10:40 AM]
I wonder if it'd be useful to begin "drafting" some build/deploy documentation (either in a PR to the README, or in a Wiki page)?

It sounds like it's possible we need clarification there...and it might point out where the difficulties are

Andrea Bollini [10:41 AM]
yes, it is the idea behind the readme in the webapp

Hardy Pottinger [10:41 AM]
more howtos are great, and will help us get more people to test for us

Tim Donohue [10:41 AM]
Right, so this README is the one we should enhance:

Terry Brady [10:41 AM]
I see 5 dirs in the webapps folder, and I am unclear where to find the war for spring rest

Andrea Bollini [10:42 AM]
I'm not sure that it is packaged at all

again, right now I focus on having things working in eclipse so the packaging process is not complete/tested

Tim Donohue [10:43 AM]
So, it sounds to me like we need a new ticket here (a subticket of We need a ticket to fix the build/deploy process

As it sounds like the WAR may only be "runnable" in an IDE at this time

Andrea Bollini [10:44 AM]
ok we can open an issue for that

should we focus on a fast solution to improve later or we need a clean build process right now?

Tim Donohue [10:44 AM]
I think the stumbling point we have here is that it's unclear what "works" and what doesn't. A fast solution is perfectly fine as long as it's one that others can reproduce (and we can clean it up later)

Andrea Bollini [10:45 AM]
I'm asking because I see three current stops for the build

ok, so we can disable dspace-solr and the mvn-enforcer plugin for now and focus on the war packaging

the issue spot by the mvn-enforcer plugin is more or less the goal of the

Terry Brady [10:46 AM]
Let's try that. I am hoping to find an entry point to be able to contribute to the project.

Mark Wood [10:47 AM]
That sounds like a place I could get started, too.

Tim Donohue [10:47 AM]
Yes, I say disable Solr & mvn-enforcer for now. I just added a note to DS-3482 about enforcer, and we can re-enable it later

Andrea Bollini [10:47 AM]
me and @lap82 can help on that as well tomorrow in the Italian afternoon

Andrea Pascarelli [10:47 AM]
joined #rest-api by invitation from @bollini

Tim Donohue [10:48 AM]
that sounds great, @bollini and @lap82

Terry Brady [10:48 AM]

Andrea Bollini [10:48 AM]
ok before to move to the other points last words about the current code

Andrea Pascarelli [10:48 AM]
Hello everybody!

Tim Donohue [10:48 AM]
Hi @lap82, welcome :wink:

Andrea Bollini [10:49 AM]
we have initial endpoints for items (only metadata are shown), bitstreams (metadata, atttributes and link to bitstreamformat)

just few hours ago I pushed a fix version to have also the bitstreamformat endpoint so to navigate from bitstream to the registry

once we solve the issue with the build it will be very useful to have volunteer to look to the test framework


Tim Donohue [10:50 AM]
sounds good

It seems like it's best to first get the build running, so folks can get a closer look at how this works/looks. Then maybe we can get others volunteering for the various tickets (all grouped under

Tim Donohue [10:52 AM]
notes I have to run to another meeting in 10mins

Andrea Bollini [10:52 AM]
ok, about the mock data

we have this PR

Tim Donohue [10:53 AM]
Should we merge that PR as-is and fix all the "wrong" links at once? (as it sounds like this PR was based on previous wrong links)

Andrea Bollini [10:54 AM]
I have sent this PR to @jcreel256

it changes the way that relations are linked

James Creel [10:55 AM]
and fixes some outright typos, thanks @bollini

Andrea Bollini [10:55 AM]
in a HAL document say a Collection you should always have the link to the relation also when it is empty

this because the relation link is also used to discover where you need to post new content to update the relation or add new links

Tim Donohue [10:56 AM]
That all looks reasonable to me. I don't have objections to these changes (though if we find future reasons why this won't work well with Angular UI, we can always revisit it later on)

Andrea Bollini [10:57 AM]
ok, so we can just wait for a fast review from @jcreel256 and when merged in the TAMUE repo I will merge in our dspace-labs

Tim Donohue [10:57 AM]
And, I think this is exactly what we had discussed & approved last week (that we don't want all sub-objects listed in their parent objects, e.g. items in collections) :wink:

Andrea Bollini [10:58 AM]
the next step for me is to add other mock-data aside the current ones where we show how these linked collection can be embedded in the initial request

Art Lowel [10:58 AM]
That would be interesting

esp if it can be done in a flat structure

Andrea Bollini [10:59 AM]
ok do you have any preference about which relation to embed in the samples?

Art Lowel [11:00 AM]
bundles and bitstreams in an item

that will be immediately useful for the design of the item view page

Tim Donohue [11:00 AM]
is going to have to run to another meeting. I would encourage you to continue discussions here though (or even jump back into #angular-ui if there's more questions/comments there). I'll be lurking & can copy these discussions into "Notes" on the wiki later today

Andrea Bollini [11:00 AM]
ok I will provide samples for item so that other can also help adding more. Today or tomorrow

Art Lowel [11:00 AM]
no rush :slightly_smiling_face:

Andrea Bollini [11:01 AM]
last question about the new repository for the rest contract

should we use the github issue to discuss around specific decision?

an example, in the current implementation I have skipped to include the uuid in the object attribute as it can be seen in the self link

Art Lowel [11:02 AM]
yeah, I just added an issue about that to the comparsion repo


but perhaps that should be on the new Rest7Contract repo?

Tim Donohue [11:04 AM]
has one last thing to quickly mention. Next DSpace 7 Meeting will be next week (Feb 23 @ 16:00 UTC). I'd like to use Google Hangouts again, as the limit is 25 attendees these days. More info later

Andrea Bollini [11:04 AM]
yes, the hal-xxx repo is temporary imho as soon as we have more samples we should move all the staff in the rest7contract repository

Art Lowel [11:04 AM]
sounds good

Andrea Bollini [11:05 AM]
I plan to do that as soon as we have mock data build on something that is shared across the developers like the data in the current

otherwise anytime that we build some mock data we will have changes due to different databases or hard-time trying to build manually relations with random uuid

Art Lowel [11:06 AM]

ideally it would still be something that we could easily deploy locally

because if there was a single server like

and the spec changes

things in the UI might break until we become compliant (edited)

so it would be good if a UI dev could deploy an older version to work with (edited)

Andrea Bollini [11:08 AM]
yes, we can share the initial AIP of the and just use these information for now

@art-lowel can you reopen the question on the rest7contract?

Art Lowel [11:09 AM]

Andrea Bollini [11:11 AM]
ok so there is lot of work to do before next hangout meeting. Unfortunately @terrywbrady @mwood @jcreel256 are on a different timezone but me and @lap82 will do our best to help to get all of you, and anyone else that like to join, started also on the webapp code

Mark Wood [11:11 AM]
Thank you.

Terry Brady [11:12 AM]
Thanks for keeping things moving. I will just post questions here as they arise

Andrea Bollini [11:12 AM]

I'm leaving from the office now. Keep in touch

Art Lowel [11:14 AM]

  • No labels