The DSpace 2.0 has moved it's weekly skype conference to an IRC chat on #dspace. This meeting is usually on Mondays at 16:00 GMT. Below is a transcript.
bradmc__: Folks, the DSpace 2.0 team is going to have a meeting here (and regularly at times TBD). Feel free to ignore, or jump in as appropriate. [12:04pm] bradmc__: Shall we start with discussion next steps for packaging and documentation? [12:06pm] mdiggory: packaging requires build scripts [12:06pm] grahamtriggs joined the chat room. [12:06pm] mdiggory: That was more a question... [12:06pm] bradmc__: Mark, thanks for pinging Graham. Hi Graham. [12:06pm] grahamtriggs: hi [12:06pm] bradmc__: So build scripts would be on the list of steps for packaging [12:08pm] mdiggory: We need to discuss if we are approaching a build system similar to 1.6 or if we are looking to do something different/better [12:09pm] bradmc__: mdiggory asks the question I was typing. I think we should look beyond the current blended maven / ant approach if we can. [12:09pm] mdiggory: Overlays were ok in 1.x, I'm not sure how much we want to promote the continued use of them. [12:10pm] mdiggory: ant portion needs to EOL in 1.x [12:10pm] mdiggory: we need one build process for the end user. [12:10pm] bradmc__: Is maven sufficient now? [12:11pm] bradmc__: Or can we avoid even that for the end user, and just configure in place? [12:11pm] mdiggory: depends on "what" DSpace is... [12:12pm] mdiggory: or more specifically "what" a DSpace distribution is. [12:13pm] • mdiggory thinks if this is going to be the pace of the discussion maybe IRC may not be best [12:14pm] mdiggory: I hope we can think about a better distribution/installation management solution in 2.0 [12:14pm] bradmc__: I think a DSpace distribution should be ready to use out of the box with minimal to no configuration. Then, we need a reasonable small set of actions to upgrade / reconfigure / extend. [12:15pm] mdiggory: I.E. Are we going to use dspace.cfg or "DSPACE_HOME", are we going to have separate installations for client and webapps [12:15pm] azeckoski: I would argue strongly for binary with configuration [12:16pm] mdiggory: bradmc__: challenge is that in DSpace 1.x thats a monstrous hydra. [12:16pm] bradmc__: All of the above is somewhat distinct from getting to a point where other developers can easily work with the code, and that point may be part of getting to the eventual end user. [12:17pm] mdiggory: ok... so your not talking installation, your talking svn checkout [12:17pm] bradmc__: Yes, so let's try not to recreate that. I note that for DS 1.x we've had several successes at creating bootable images, so it is possible to choose a set of functionality and make it work. [12:17pm] bradmc__: I'm talking about both; pointing out that we need to solve the svn checkout piece sooner, and the install later. [12:18pm] mdiggory: Well, before we start having more hands in the code, we need to work on svn organization in 2.0 [12:18pm] azeckoski: for svn co, I think the easiest thing is to checkout a big chunk of stuff (everything) for now and use build profiles [12:18pm] azeckoski: but eventually we will want binaries of the core in maven repos [12:18pm] bradmc__: mdiggory: What's the short list that needs reorg before general use? [12:18pm] mdiggory: for those working onthe core that makes sense [12:18pm] azeckoski: and then separate projects that just refer to the binaries [12:19pm] mdiggory: that was directed to azeckoski [12:19pm] azeckoski: right [12:19pm] azeckoski: and for now, that includes everyone [12:19pm] mdiggory: In my presentation, I was showing that if your developing an addon for DSpace XMLUI, you don't need to use that strategy, and its lighter to do the work and to test it [12:20pm] mdiggory: and I think that can apply somehow tot he core as well... and the promotes encapsulation and keeping out of the core unless neccessary [12:21pm] mdiggory: bradmc__: 1.) still moving api,impl,util into a "core' space [12:21pm] mdiggory: bradmc__: 2.) XMLUI needs better org [12:22pm] mdiggory: bradmc__: 3.) still have the strong opinion we shouldn't working on more tha one UI... [12:22pm] mdiggory: (that doesn't mean throwing one out... it means working more on a unified solution) [12:23pm] mdiggory: (but thats a bigger seperate topic) [12:23pm] azeckoski: 1 - yes, 2 - ok, 3 - ok [12:23pm] bradmc__: 1 - yes, 2 - maybe, how much delay?, 3 - no, too much delay. I think we should fast-track to getting more hands involved. [12:24pm] mdiggory: bradmc__: 2, not much more than (1)... probibly done at same time [12:26pm] mdiggory: So, I think we should have a requirement that every Maven project can be checked out and built independently of the others. [12:26pm] azeckoski: that one will be hard without a snapshot repository [12:26pm] mdiggory: I've worked to enforce this in the use of a "repositories" section in each POM that have teh maven.dspace.org repo in it [12:27pm] mdiggory: azeckoski: yes thats why we have one [12:27pm] azeckoski: and if you just try to build version 222 of the impl without having built version 222 of the api then it will fail for sure [12:27pm] azeckoski: regardless of how many repositories you have [12:28pm] bradmc__: That is implied. I think Mark's trying to set guidelines for the various components and applications outside the core that will start to multiply soon. [12:28pm] mdiggory: azeckoski: so are suggesting we ties snapshot versioning in sync with svn revision numbers? [12:28pm] bradmc__: I think it's a good place to start. [12:28pm] azeckoski: not with svn no [12:29pm] bradmc__: Is there a reason not to use datestamped snapshots? [12:29pm] azeckoski: yes, laziness [12:29pm] mdiggory: yes, but somehow an impl version needs to stay tied closely with an api version [12:29pm] azeckoski: yeah, I would lockstep the core versions [12:29pm] azeckoski: for now anyway [12:29pm] azeckoski: that can change later [12:30pm] mdiggory: dated snapshots do not garuntee that tie. [12:30pm] azeckoski: agree [12:30pm] azeckoski: and the release plugin makes incrementing versions easy [12:30pm] azeckoski: using dates is less easy [12:31pm] mdiggory: So maybe we have lots more minor releases and less reliance on data snapshots [12:31pm] azeckoski: not sure what a data snapshot is [12:31pm] mdiggory: data = dated [12:31pm] azeckoski: ah [12:31pm] azeckoski: I would say this is a good approach [12:31pm] azeckoski: lots of small releases [12:31pm] bradmc__: That's fine by me. [12:32pm] azeckoski: I would like to tag what is there now before I break the heck out of it [12:32pm] mdiggory: IMO this means that the release of the core, UI and providers are "NOT" in lockstep [12:32pm] azeckoski: but I don't think I have permissions to write to the maven repo [12:32pm] azeckoski: oops [12:32pm] azeckoski: how do I send message to a person without sending a private message? [12:33pm] mdiggory: CI manages that but also working getting the maven repo ported to WEBDAV at OSL so we can all deploye [12:33pm] bradmc__: mdiggory: I think that's right, although I'd expect substantial breakage in the early days, and then occasional pain over time if you get a mismatch. [12:33pm] azeckoski: mdiggory: IMO this means that the release of the core, UI and providers are "NOT" in lockstep - agree [12:33pm] azeckoski: what does CI manage? [12:33pm] mdiggory: by CI more specifically Elliots Bamboo instance running "deploy" for us [12:33pm] azeckoski: oh [12:34pm] azeckoski: there is a way to trigger a maven repo release? [12:34pm] mdiggory: Elliot and I will need to check into that... I think we should use the maven release plugin [12:35pm] mdiggory: which means its more the developers job to deploy [12:35pm] azeckoski: I think so also [12:35pm] azeckoski: I just need server/user/pass for the maven repo [12:36pm] mdiggory: Not sure it makes sense to do CI on a tag does it? I guess if its dependencies shift its a good thing to be doing. [12:36pm] azeckoski: nope [12:36pm] azeckoski: you do the CI on the trunk and tag from the trunk [12:36pm] mdiggory: azeckoski: I agree it should be that easy... right now its still at MIT on a server that we want tog et it off of [12:36pm] azeckoski: if CI passed then the tag will pass [12:37pm] azeckoski: ok [12:38pm] mdiggory: azeckoski: ok... so CI on trunks and branches only... good practice [12:38pm] azeckoski: yep [12:38pm] mdiggory: So... if we are not in lockstep for core, providers and UI, then I assume they should be separate SVN projects? [12:38pm] azeckoski: even branches are unusual [12:39pm] mdiggory: so we can maintain seperate tags for them [12:39pm] azeckoski: mdiggory: I would say separate subfolders is ok [12:39pm] azeckoski: like trunk/core and trunk/xmlui [12:39pm] azeckoski: or reversed [12:40pm] mdiggory: that means that the tags for both end up piled into branches together... [12:40pm] azeckoski: why? [12:40pm] azeckoski: you could make the branch from trunk/xmlui [12:40pm] mdiggory: i.e. branches/core-2.0.1 and branches/xmlui-2.3.4 [12:40pm] azeckoski: oh [12:41pm] azeckoski: you are talking about the maven structure or the svn structure? [12:41pm] azeckoski: they are not necessarily related [12:41pm] mdiggory: it effects both [12:41pm] azeckoski: well, for svn, things are just folders [12:41pm] azeckoski: it does not care if it is called trunk or whatever right? [12:41pm] azeckoski: so you can make a branch from any folder [12:42pm] azeckoski: or make a tag from any folder [12:42pm] mdiggory: there are conventions that are best adhered to [12:42pm] azeckoski: yes [12:42pm] mdiggory: where does the "tag" for "any folder" go? [12:42pm] azeckoski: tags/path-to/folder probably [12:43pm] mdiggory: I worry that that will get messy [12:43pm] azeckoski: I have seen it done 2 ways [12:43pm] azeckoski: trunk/subs [12:43pm] azeckoski: and subs/trunk [12:43pm] azeckoski: subs/trunk seems to be what you prefer so let's do that [12:43pm] mdiggory: https://scm.dspace.org/svn/repo/modules/ [12:43pm] mdiggory: vs [12:44pm] mdiggory: https://scm.dspace.org/svn/repo/dspace [12:44pm] azeckoski: I'm lost [12:44pm] mdiggory: modules = project/trunk [12:44pm] mdiggory: dspace = trunk/project/subproject [12:44pm] azeckoski: isn't this the path to the repo root? https://scm.dspace.org/svn/repo/dspace [12:44pm] mdiggory: no [12:44pm] azeckoski: https://scm.dspace.org/svn/repo [12:45pm] azeckoski: that? [12:45pm] mdiggory: yes [12:45pm] azeckoski: ah [12:45pm] azeckoski: so then [12:45pm] azeckoski: https://scm.dspace.org/svn/repo/ds-core/trunk [12:45pm] azeckoski: https://scm.dspace.org/svn/repo/xmlui/trunk [12:45pm] azeckoski: this is what you wanted? [12:46pm] mdiggory: sort of... I was allowing for more directories at the top [12:46pm] azeckoski: sure, you can make as many as you like [12:46pm] mdiggory: https://scm.dspace.org/svn/repo/modules/xmlui [12:46pm] azeckoski: https://scm.dspace.org/svn/repo/1/trunk [12:46pm] azeckoski: https://scm.dspace.org/svn/repo/2/trunk [12:46pm] azeckoski: oh [12:46pm] mdiggory: https://scm.dspace.org/svn/repo/modules/xmlui/trunk [12:46pm] azeckoski: you want to nest all the non-core stuff under one name? [12:47pm] azeckoski: https://scm.dspace.org/svn/repo/modules/xmlui/trunk [12:47pm] azeckoski: https://scm.dspace.org/svn/repo/modules/blah/trunk [12:47pm] azeckoski: like that? [12:47pm] mdiggory: allowing room for projects to define that for themselves? [12:48pm] azeckoski: I would give projects root level names [12:48pm] azeckoski: then you can control the permissions on each one [12:48pm] mdiggory: modules was mostly an attempt to keep separate svn projects for each modules [12:49pm] mdiggory: I was working for "spaces" that represented specific community areas (sandbox, modules, core) [12:49pm] azeckoski: oh [12:49pm] azeckoski: so everyone gets commit to sandbox [12:49pm] mdiggory: sort of like that [12:49pm] azeckoski: but only a few to core and a bunch to modules? [12:49pm] mdiggory: right [12:49pm] azeckoski: seems fine [12:50pm] azeckoski: I doubt anyone will go messing around in someone else's module or sandbox anyway [12:50pm] bradmc__: agreed. [12:50pm] azeckoski: and if they do, they get no cookies [12:51pm] azeckoski: and have to eat extra vegetables [12:51pm] bradmc__: So, in this new world, would it be possible to hand an end-user one (rather long) maven command line that generated a running instance? [12:51pm] azeckoski: only if that mvn command includes some shell scripts [12:51pm] mdiggory: I guess my only reservation is that the "dspace" 1.x project space deviates from this while sitting in the middle of it [12:52pm] azeckoski: j/k it is totally possible [12:52pm] bradmc__: mdiggory: Isn't that inevitable? [12:52pm] mdiggory: bradmc__: I expect it would not be a "rather long" command [12:52pm] mdiggory: but a "rather short" command [12:52pm] azeckoski: I think it would be mvn clean install [12:53pm] azeckoski: or mvn install if you want to shorten it up [12:53pm] bradmc__: By "rather long" I was thinking of things like passing in the database credentials... [12:53pm] mdiggory: um, "install" suggests it created something that can run when all it did is build something and put it in your maven repo [12:54pm] mdiggory: bradmc__: I think we keep configuration separate from creating a distribution [12:54pm] azeckoski: I would do it a little more like moodle/wordpress [12:54pm] azeckoski: build binary, edit config, start [12:54pm] grahamtriggs left the chat room. [12:54pm] bradmc__: I'm asking if 'mvn deploy' should be getting closer to a distribution. [12:55pm] mdiggory: most mvn goals are about building and packaging, not about configuring and installing a distribution.... this is why we ended up with the Ant script still around [12:55pm] bradmc__: And I'm noticing that 'edit config' in it's minimal form requires only a couple of parameters. [12:55pm] azeckoski: maven deploy puts it in the remote repo [12:55pm] azeckoski: I don't think end users will be running that [12:55pm] bradmc__: mdiggory: Yes, we might need to mojo or something. [12:55pm] mdiggory: still a developer activity [12:56pm] mdiggory: bradmc__: SAKAI did go that path already... Aaron probibly has oppinions about it [12:56pm] azeckoski: it sux [12:56pm] azeckoski: and guess what... it is gone in sakai 3 [12:56pm] mdiggory: sorry, I set you up for that one azeckoski [12:57pm] azeckoski: np [12:57pm] bradmc__: Let me try this a different way. Presume that there is a natural progression from: [12:57pm] bradmc__: 1) Download a preconfigured system and smoketest it. [12:58pm] mdiggory: Guess what! That brings us around to "plugin management" and "OSGi like distribuions to install them into".... [12:58pm] bradmc__: 2) Get some source and configure it to your own specs and deploy it. [12:58pm] bradmc__: 3) Start writing your own pieces of code. [12:58pm] azeckoski: no more guessing [12:58pm] bradmc__: I'm suggesting that we should have a goal of keeping those activities congruent. [12:58pm] azeckoski: #2 should just be editing a config file [12:59pm] azeckoski: which I think it low enough without requiring full automation [12:59pm] mdiggory: Preconfigured means it runs standalone whereever you drop it without rebuilding it just to set some silly dspace.dir [12:59pm] azeckoski: granted, it is not as cool as the "your system is not configured yet" that you get with PHP apps [1:00pm] azeckoski: but it is probably fine [1:00pm] bradmc__: So let's make it that cool, then. [1:00pm] azeckoski: in an ideal world [1:00pm] mdiggory: Well, our current "Container" for managing "Components" seems to be a servlet container [1:01pm] mdiggory: should (1) be a servlet engine + wars... [1:01pm] azeckoski: why not make 1 a jar that you can run? [1:01pm] bradmc__: We have a piece of java code that initializes the database, it's a question of how that code is packaged and called. [1:02pm] mdiggory: whats in the jar? [1:03pm] mdiggory: I wouls assume (1) would use a JAva RDBMS delivered with it [1:03pm] azeckoski: dsapce core, xmlui, jetty [1:03pm] azeckoski: yeah, H2 probably [1:03pm] mdiggory: I'm thinking of something like the way Confluence and JIRA are distributed [1:03pm] azeckoski: or derby [1:03pm] azeckoski: it is getting extremely common to distribute executable jars now [1:04pm] azeckoski: especially in the apache projects [1:04pm] bradmc__: We're at one hour. I think we had some agreement on the structuring of the SVN and maven snapshots, so we can proceed on that. Mark, you seem to think we can get XMLUI in shape soon too. [1:04pm] bradmc__: I agree on the Java RDBMS executable jars as a goal for the future. [1:04pm] bradmc__: We need to pick up on the moving JSPUI / XMLUI together thread at another time. [1:05pm] bradmc__: Is that a fair summary thus far? [1:05pm] mdiggory: seems the jar needs to "unpack" somewhere to support serialing things tot he filesystem?? [1:05pm] mdiggory: serialing = serializing [1:06pm] mdiggory: I.E. db, lucene indexes, asset storage etc [1:06pm] mdiggory: yes, I need to finish up and get out he door [1:08pm] bradmc__: Okay. Same approx time and channel next week? And we can start early / run late for those so inclined? [1:08pm] mdiggory: agreed... I suppose we will post this to dev/arch lists? [1:08pm] azeckoski: on the exec jar: if we want to go cheap we can do this: java -jar jetty-runner.jar my.war [1:08pm] bradmc__: Sure. I can do the posting. [1:08pm] azeckoski: otherwise, it is easy to embed it [1:09pm] mdiggory: many of the Simile projects use maven jetty goal to launch from a maven project [1:10pm] mdiggory: seemed pretty effective, but ties us to maven for deployment... [1:10pm] RichardJones left the chat room. (Read error: 60 (Operation timed out)) [1:10pm] azeckoski: yeah, mvn jetty:run-war is how I test the dspace rest stuff [1:10pm] mdiggory: I'd rather just have one requirement in that situation... java [1:10pm] azeckoski: and most everything else [1:10pm] azeckoski: yep [1:10pm] azeckoski: embedded is better [1:10pm] azeckoski: download jar [1:10pm] azeckoski: java -jar blah.jar [1:10pm] mdiggory: right [1:11pm] mdiggory: ok... ------------------------------------------------------------------------------ Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com _______________________________________________ Dspace-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-devel
