By way of summary: when purging an object from a 3.0 repository, triples
that contain empty literals (i.e. "") are not deleted. For example, add
an object with an empty label, delete the object, the triple for the
label remains.
Originally, I treated this as a problem of failing to delete triples.
Morten,
Thanks for the patch. Were you able to reliably reproduce the error you
reported? I'd like to get a unit test to cover this, if possible.
Eddie
On 09/12/2008 04:46 AM, Morten Grouleff is rumored to have said:
> Never got a response, but instead found a bit of time to look into it
> my
problems with
> SourceForge mail. Not sure if you got it? Like Joe, we initially ended
> up with an empty ri!
>
> Richard
>
> -Original Message-
> From: Richard Green
> Sent: 19 September 2008 16:53
> To: 'Edwin Shin'; fedora-commons-developers@lists.sourcef
On Sat, Oct 18, 2008 at 1:43 AM, <[EMAIL PROTECTED]> wrote:
> Revision: 7787
>
> http://fedora-commons.svn.sourceforge.net/fedora-commons/?rev=7787&view=rev
> Author: pangloss
> Date: 2008-10-17 17:43:22 + (Fri, 17 Oct 2008)
>
> Log Message:
> ---
> updated Trippi to 1.4.1 (Mulga
On 10/21/2008 02:13 PM, Morten Grouleff is rumored to have said:
> When doing concurrent ingests we have experienced the occasional
> ingest-error. Not that many on Linux systems. but quite a few on Windows
> systems. We did a bit of debugging and discovered the following
> temporary file naming
On 10/22/2008 10:02 AM, Aaron Birkland is rumored to have said:
> 2) TestLargeDatastreams failed. Reason: URI syntax exception (happens
> with mulgara, mckoi as well)
> If this test is still valid, can someone verify this failure?
I see the same error. The test is failing because it's pass
On 10/22/2008 07:51 PM, Edwin Shin is rumored to have said:
> On 10/22/2008 10:02 AM, Aaron Birkland is rumored to have said:
>
>
>> 2) TestLargeDatastreams failed. Reason: URI syntax exception
>> (happens with mulgara, mckoi as well)
>
>
>
>> If t
All my tests have passed (release-3.1 & release-2.2.4 on Linux + Java 5
+ MySQL 5).
Testing of the manual upgrade from 2.2.3 to release-2.2.4 passed as
well. However, we need to note that upgraders will need to
1) update the Kowari configuration portions of fedora.fcfg w/ the new
Mulgara config
On 10/24/2008 10:41 PM, yf508 is rumored to have said:
> We're using Fedora 2.x/Muradora to build our digital library. I've got a
> problem while using fedora.utilities.FoxmlDocument. The addDataStream,
> addDataStreamVersion work correctly. However, when I tried to use
> addXmlContent method, I'v
...are up on the wiki
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source
Steve,
The first reference you listed states the following:
Note: In Tomcat 5.5.x, you can include all required JARs in WEB-INF/lib.
With this configuration carol.properties goes in WEB-INF/classes. For an
example WAR, see http://static.raibledesigns.com/downloads/dbtest.war.
I took that to m
Doug,
For the time being, your best bet would be to peruse the source of the
installer classes (the fedora.utilities.install package).
At the very least, there's the web.xml and fedora.fcfg that get tweaked
by the installer, which none of the ant targets will do for you.
It might be easier to
I generally like the new naming, although Chris & Dan see my email off-list for
a alternative prefix for the project as a whole. For the localservice renaming,
another option is to use the fedora-webapp module (now fedorarepo-webapp) as a
pom with child modules fedora, fop, saxon, and imagemani
is imminent, I'm calling for a vote between org.fedorarepo and
org.fcrepo by the next committer call, Tuesday 24 November.
On 20 Nov 2009, at 7:30 AM, Chris Wilper wrote:
> On Thu, Nov 19, 2009 at 7:01 PM, Edwin Shin wrote:
>> I generally like the new naming, although Chris &am
Update for the committers:
I've updated Maven repo, but I'm getting some runtime errors on test configB
which look to be related to picking up the transitive dependencies when the war
is being built. So I'll be holding off on committing my updates until I get
back home later tonight.
Eddie
---
Can we safely remove
- org/fedoracommons
- org/fedorarepo
from both thirdparty and releases? It looks like everything has already been
copied over to org/fcrepo and org/akubraproject
--
Join us December 9, 2009 for the
background: integration tests that used the imagemanip service were failing
with fesl (the new, experimental security layer) enabled.
The odd thing was, even requests to:
http://localhost:8080/imagemanip/ImageManipulation?op=resize&newWidth=50&url=http://localhost:8080/tomcat.gif
would h
;
> http://n2.nabble.com/A-ImageManipulation-that-kill-my-fedora-daemon-td2826668.html
>
> It seems odd that getting a new XACML PDP instance would have anything
> to do with awt...
>
> - Chris
>
> On Tue, Dec 15, 2009 at 5:54 PM, Edwin Shin wrote:
>> background: integration tes
Must be that post-release spring-cleaning sort of feeling going round. I was
just waiting to raise this very issue after everyone got back from the holidays
;)
>From a development standpoint, it's a no-brainer. It would be a good idea,
>however, to ping the users list and any large Fedora insta
I definitely support the proposal to have an object that represents the
repository itself (just as I would like to see objects that represent
fedora.fcfg, users, groups, etc.). Even before FeSL, we'd discussed the
desirability of representing policies as Fedora objects (in contrast to the set
o
ch policies are applicable--but I do believe that
that describes logically different parcels of work from what's scoped by
FCREPO-577.
On 12 Feb 2010, at 5:54 PM, Asger Askov Blekinge wrote:
> Hi
>
> On Fri, 2010-02-12 at 17:19 +0100, Edwin Shin wrote:
>> I definitely support
Are you using Java 5? Until just recently in the trunk, we employed some build
hackery to maintain source compatibility with Java5 and Java6. If you just did
a checkout of trunk from svn, you now need to be using Java 6 to build.
Eddie
On 16 Feb 2010, at 7:14 PM, wei yuan wrote:
> Hi,
>
> I s
I did some work for a client to get Fedora running on Weblogic in December &
January (post 3.3 release). If you're comfortable checking & building from
trunk, I'd test to see if that works for you in WL 9.2 (I tested against WL10).
If that works for you, you can see about backporting those chang
Huân,
Could you insert a print statement at line 90 to see which date string is
causing the problem? e.g.:
for (String element : dates) {
+System.out.println("parsing: " + element);
assertEquals(EPOCH, DateUtility.parseDateAsUTC(element));
}
And re-ru
w.fedora-commons.org/jira/browse/FCREPO-667
>
> But what var do I exactly have to change in windows ? Or is there any way to
> get it to work without changing any var ?
>
> Regards,
>
> -
> Huân Thebault
> Centre de Calcul de l'IN2P3
> Development Team
>
Can you find an earlier reference in the logs where the request has not already
been cached? Look for a debug message that includes "No item found in cache.
Sending to PDP for evaluation"
On 31 May 2010, at 3:48 PM, Huân Thebault wrote:
> Hello
>
> I’ve built fedora-3.4 from trunk but I can’t
Huân,
When you installed fedora, did you require authentication for API-A? (you can
check $FEDORA_HOME/install/install.properties for the value of
apia.auth.required). If it's false, then try applying the workaround Steve
suggested below. If it's true, then FCREPO-703 doesn't apply in case.
T
Hoping someone else can confirm this one, and even better, run this down, since
I'm not seeing anything obvious in the post 3.4RC1 commits that would suggest
this behavior change.
To reproduce:
- change the status of an object to Inactive
- attempt to fetch it, e.g., http://localhost:8080/fedor
+1
On 23 Nov 2010, at 9:10 PM, Chris Wilper wrote:
> Hi all,
>
> Over the past few weeks, several of us have been looking into a
> potential move of the core Fedora Repository code to GitHub. During
> today's developer call, we decided the investigation had progressed
> along far enough that we
Off a fresh clone of fcrepo, I'm getting the following running
mvn verify -Dconfig=Q -Dit.test=org.fcrepo.test.api.TestAPIA
Running org.fcrepo.test.api.TestAPIA
Ingesting demo objects...
Ingesting demo objects in FOXML format from //
Could not create managed clone test objects: java.lang.Error: Un
.org/maven2),
> apache-incubating
> (http://people.apache.org/repo/m2-incubating-repository/),
> java.net (https://maven-repository.dev.java.net/nonav/repository),
> aduna (http://repo.aduna-software.org/maven2/releases/),
> maven2-repository.dev.java.net (http://download.java.net/mave
t;>> -Dfile=/path/t
>>> o/file
>>>
>>>
>>>
>>>
>>>> -Original Message-
>>>> From: Chris Wilper [mailto:cwil...@duraspace.org]
>>>> Sent: 09 March 2011 13:00
>>>> To: fedora-commons-developers@lists.so
lled in.
Not positive that this the same sort of problem that Bamboo is hitting, but I
can't reproduce a test failure aside from the two methods described above.
On 18 Mar 2011, at 12:00 AM, DuraSpace Bamboo wrote:
> FCREPO-LINUXSAN-118 failed.
> Code has been updated by Edw
As I recall purgeDatastream used to only return a 204 status code, no payload.
See https://jira.duraspace.org/browse/FCREPO-708
Returning a JSON array of dates was intentional, so I suppose I would call that
a feature ;-)
On 2 Jun 2011, at 8:59 AM, Stephen Bayliss wrote:
> Hi Steffen
>
> This
; headers
> ().
>
> This happened with accept headers */* and application/json. I cannot imagine
> that the method does not work in some way - could you give me a hint?
>
> Thanks
> Steffen
>
>
>
> -Original Message-
> From: Edwin Shin [mailto:ed...
Just to summarize the background of the issue:
- Prior to Fedora 3.5.0, you were able to run Fedora within Jetty
1) without defining the FEDORA_HOME environment variable
2) only using relative paths to define the fedora.home property in web.xml
(https://github.com/projecthydra/hydra-jetty/blo
I'm not aware of any plans that scoped FCREPO-951 as part of the GSoC work.
So unless Adam/Jiri chime in otherwise, you're more than welcome to take it =)
On 22 Jul 2011, at 8:54 AM, Asseg, Frank wrote:
> Hola guys!
>
> i wanted to ask if
> https://jira.duraspace.org/browse/FCREPO-951
> is in l
Just to be clear, the order of precedence for determining Constants.FEDORA_HOME
is:
1) fedora.home init param via servlet.fedora.home system property
People shouldn't actually set the servlet.fedora.home system property directly
as org.fcrepo.server.utilities.LogSetupContextListener checks for t
+1 for openjdk
On 27 Jul 2011, at 1:37 PM, aj...@virginia.edu wrote:
> OpenJDK is one with which I've had no problems running Fedora, at least on
> Linux. Some of the others were mixtures of Apache Harmony with other VMs. A
> few of them worked well, others... not so much. {grin} Fedora, in fac
you're rolling out jdk 7 in production?
http://lucene.apache.org/solr/#28+July+2011+-+WARNING%3A+Index+corruption+and+crashes+in+Apache+Lucene+Core+%2F+Apache+Solr+with+Java+7
I would at least wait till the dust settles and a couple updates came through
before considering jdk7 for production.
A
Pablo,
Short answer is yes, Fedora can store and manage large files.
However, there have been bugs such as
https://jira.duraspace.org/browse/FCREPO-704 which caused errors for uploading
larger files.
Can you provide some more detail, e.g.:
1) Are you seeing the error with the SOAP or REST API,
Greg,
The Maven information you need to include in your pom is documented here:
http://mediashelf.github.com/fedora-client/usage.html
They are in the DuraSpace repo and at present not in Maven central because
fedora-client currently has dependencies which themselves are not in Maven
central.
Greg,
Pardon my jet-lag, I had assumed you were talking about the fedora-client
library at https://github.com/mediashelf/fedora-client
On 16 Oct 2011, at 8:55 PM, Greg Pendlebury wrote:
> Hello again,
>
> I started looking at later versions today. I've currently got v3.3, v3.3.1,
> v3.4.2 and
no reason other than we haven't gotten 'round to it.
I created a ticket for this. If you want to submit a pull request on Github,
feel free =)
On 15 Nov 2011, at 8:03 PM, Jesper Damkjaer wrote:
> Hi.
>
> I have looked at some of the tests during my attempt to test
> multi-threading in DefaultD
forgot to include the link: https://jira.duraspace.org/browse/FCREPO-1025
On 15 Nov 2011, at 8:55 PM, Edwin Shin wrote:
> no reason other than we haven't gotten 'round to it.
>
> I created a ticket for this. If you want to submit a pull request on Github,
> feel free =)
&
I've mavenized trippi in a branch creatively named, "maven".
https://github.com/fcrepo/trippi/compare/master...maven
Unless anyone sees any issues, I'll merge with master in the next couple of
days.
--
Virtualiza
few testing issues...both in the master branch and the
> maven branch. Have you been able to successfully run the existing tests yet?
> There seems to at least be some log configuration classpath wonkiness going
> on, but I haven't looked deeply at it.
>
> - Chris
>
>
I'll back them out since that was working better for me.
On 12 Feb 2012, at 10:52 PM, Chris Wilper wrote:
>
> On Sun, Feb 12, 2012 at 4:01 AM, Edwin Shin wrote:
> Maybe I'll just stick a release of 0.4-SNAPSHOT on the DuraSpace m2 repo for
> now. I still can't get wag
I see is that in the trippi pom, the DuraSpace thirdparty
> maven repo is listed *both* as a plugin repository and a regular repository.
> In the fedora-client pom, it's listed as a plugin repository only. So I
> suspect that's the problem, but I can't verify it t
aven2 and maven3.
>
> So if we want to support both major versions of maven, it seems like it
> really does need to go in both places.
>
> Ahh, maven.
>
> - Chris
>
> On Sun, Feb 12, 2012 at 11:43 AM, Edwin Shin wrote:
> I can't duplicate the error. I did the same
Since I was on such a roll with trippi, I mavenized mptstore as well. This one
was a bit more straightforward.
Same as before--I'll merge to master soon-ish if I no one raises any issues
regarding the maven branch.
--
Ke
in the pom instead of CONTRIBUTORS.txt for this and trippi. Thanks for
> getting these converted.
>
> On Mon, Feb 13, 2012 at 10:41 PM, Edwin Shin wrote:
> Since I was on such a roll with trippi, I mavenized mptstore as well. This
> one was a bit more straightforward.
>
> Same
*applause*
I'm putting together the 3.6 test plan at this very moment.
Today, we'll cover
i) what if anything stands in the way of code freeze,
ii) zip through open issues that are currently pegged against 3.6
iii) testing assignments
On 31 May 2012, at 5:12 PM, Benjam
It's a day after code-freeze, but I finally have fcrepo-954 merged locally and
passing all tests. There were actually some bugs in the fcrepo-954 branch which
took me awhile to run down--I ended up cherry-picking each individual commit to
narrow the problem space.
Do we want to make an exceptio
ok, fcrepo-954 is merged.
I cheated and also created and closed a new ticket: fcrepo-1095, to update
libraries. In particular, I realized that we were not using the latest releases
of trippi and mptstore, but then I got the bug and did a decent sweep of
dependencies, notable exception being Spr
AGE-
> Hash: SHA1
>
> +1 to #2.
>
> - ---
> A. Soroka
> Software & Systems Engineering :: Online Library Environment
> the University of Virginia Library
>
> On Jun 14, 2012, at 3:58 AM, Edwin Shin wrote:
>
>> ok, fcrepo-954 is merged.
>>
&
I spent some time looking into this, not much luck determining the cause on
HEAD, so I started traversing previous commits trying to determine when this
crept in.
I can reproduce the NPE as far back as 95cec2340fd7c026d95016eb3b24987de63ef803
(24 April)
The rebuilder works as of fe760b0e8204bf
fyi:
I continued to get test failures running mvn install on the ec2 instance I was
using. I've repeated this on two different ec2 (small) 64-bit instances running
Ubuntu 12.04, as noted in FCREPO-1104:
https://jira.duraspace.org/browse/fcrepo-1104
However, changing the instance type t
Dan reported issues with the Swing client which look like regressions from the
Axis-to-CXF migration. He's documenting some of the specifics in a Jira ticket
right now.
Some of the basic stuff works fine:
- login, search, ingest by single file, ingest by directory, purge object
However, ingesti
fyi, doc checklist is here:
https://jira.duraspace.org/browse/FCREPO-1115
Please add subtasks as you see fit and don't be shy about assigning tickets to
yourself ;-)
--
Live Security Virtual Conference
Exclusive l
We have a ton of fcrepo branches, most of which I'm reasonably certain can be
pruned.
Aside from master, the list comprises (I've put names against branches per JIRA
assignee). Branches with stars are ones I that I'm reasonably certain should be
deleted.
Can you please review your branches and
I think the partial fix is still valuable.
Incidentally, does the same issue apply for datatypes, then?
-Eddie
On Aug 13, 2012, at 10:57 PM, Benjamin Armintor wrote:
> I'm going to look at a few of the the bugfixes slated for 3.6.1 this
> week, starting with FCREPO-1107
> (https://jira.duraspa
nm my datatypes question :P
I blame it on responding to emails before my morning coffee
On Aug 16, 2012, at 8:27 AM, Edwin Shin wrote:
> I think the partial fix is still valuable.
>
> Incidentally, does the same issue apply for datatypes, then?
>
> -Eddie
>
> On Aug
Does this file actually need have to have the version string in the filename?
Would be one less thing to filter at release time if we could just keep it
named something like fcrepo-client-webadmin.swf
--
Live Security Vi
I can't seem to get the latest Tomcat 6.x onto our Maven repo. I've tried both
mvn deploy and using the Nexus web ui.
The Nexus UI is just displaying an endless progress bar.
Using the following mvn deploy command:
mvn deploy:deploy-file
-Durl=https://m2.duraspace.org/content/repositories/thir
t für Informationsinfrastruktur
> Hermann-von-Helmholtz-Platz 1
> 76344 Eggenstein-Leopoldshafen
>
> http://www.fiz-karlsruhe.de/
>
>
> From: Edwin Shin [ed...@fedora-commons.org]
> Sent: 23 August 2012 08:10
> To: fedora
Just a reminder that code freeze for 3.6.1 is Monday =)
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. D
Frank,
So, if I understand correctly, in order to close FCREPO-1023,
1) trippi/fcrepo-1023 needs to be applied to trippi/master,
2) a new release of Trippi needs to cut (including publishing to Maven central)
3) fcrepo/fcrepo-1023 needs to be applied fcrepo/master (including updating pom
to ref
's tests and the version bump get into master
> (if Frank can't) if you can cut a Trippi release.
>
> - Ben
>
> On Mon, Aug 27, 2012 at 12:41 PM, Edwin Shin wrote:
>> Frank,
>>
>> So, if I understand correctly, in order to close FCREPO-1023,
>> 1)
Not sure if Chris is back from holiday.
i did a really cursory review--sorry, I'm about to crash for the night. Looks
generally ok to me, but I didn't thoroughly review the expiry of cache items,
so someone with fresher eyes might want to have a look.
On Aug 27, 2012, at 2:33 PM, "Asseg, Fran
1:41 PM, frank wrote:
>> Ben, can you do this? it's 20.00h here and i'd like to call it a night
>> too.. ;)
>>
>> On 08/27/2012 07:39 PM, Edwin Shin wrote:
>>> I'm turning in for the night (it's 1:30am), so I'm not going to be able to
&g
d and now integrated in Guava.
LRU caches are pretty well-tread territory and I'd rather not re-invent the
wheel, other than as an instructional exercise.
On Aug 28, 2012, at 1:42 AM, Edwin Shin wrote:
> Not sure if Chris is back from holiday.
>
> i did a really cursory review--
*frank asseg*
> softwareentwicklung
> feichtmayrstr. 37
> 76646 bruchsal
> tel.: ++49-7251-322-6073
> fax.: ++49-7251-322-6078
> mail: frank.as...@congrace.de
> web: http://www.congrace.de/
>
> Edwin Shin wrote:
> Looking at this again over my morning coffee, I thi
licit some key signing, since I have no
> idea what's become of the keys I created (2? 3?) years ago for the
> project.
>
> - Ben
>
> On Mon, Aug 27, 2012 at 2:12 PM, Edwin Shin wrote:
>> ok, i've requested access for you (see
>> https://issues.sonatype.org
freeze. We are going to have to push another
release of Trippi, however, since something went awry with the 1.5.7 jars.
On Aug 28, 2012, at 3:31 PM, Edwin Shin wrote:
> It's more that this issue provided an excuse to revisit DOReaderCache, rather
> than any actual issue in your
in Armintor wrote:
> Not sure- I didn't do anything with the build tasks but run them.
>
> On Tue, Aug 28, 2012 at 4:35 AM, Edwin Shin wrote:
>> I'm not exactly sure what's happened, but trippi-mptstore and trippi-mulgara
>> have blown up tremendously with 1.5.7
&
jamin Armintor
> wrote:
>> A janky version of that (maybe just the last?), because I had done the
>> tag manually. I think it's worth running with the tools from the
>> get-go.
>>
>> On Tue, Aug 28, 2012 at 9:45 AM, Edwin Shin wrote:
>>> ok, I'
Assuming Bamboo will sort itself out once it can find the trippi-1.5.8, we can
start testing and docs for 3.6.1.
I don't think anyone's created a Test Plan for 3.6.1. We can discuss that on
Thursday or on list if people want. I'm fine w/ just keeping the assignments
from the 3.6 Test Plan. I di
This may be mostly directed at Adam, but just in case anyone else has any
experience or ideas on the matter:
I took another look at
https://github.com/mediashelf/fedora-client/tree/test-with-Cargo (which still
won't run correctly for me anyway), which uses Cargo to start up an instance of
Fedo
would minimize the Maven
>> complexity. The first option is clearly better, but it would require some
>> serious work.
>>
>> ---
>> A, Soroka
>> Online Library Environment
>> the University of Virginia Library
>>
>> On Fri, Aug 31, 2012 at 1
),
you just need to drop in the fedora-batch-core jar and you're done--no editing
of web.xml necessary.
Reminds me that it would be nice to push Fedora along to require Servlet 3.0
container support, but that's a whole 'mother discussion.
On Sep 3, 2012, at 1:55 PM, Edwin Shin w
I just tested this locally to confirm (selecting legacy-fs in the installer).
Initial run shows the following in the log:
INFO 2012-09-13 09:02:38.354 [main] (Server) loading spring beans from
/foo/bar/fedora/server/config/spring/akubra-llstore.xml
INFO 2012-09-13 09:02:38.542 [main] (Server)
On a brand new install, with legacy-fs selected, it seems enough to delete
$FEDORA_HOME/server/config/spring/akubra-llstore.xml before the first start of
Fedora
On Sep 13, 2012, at 9:08 AM, Edwin Shin wrote:
> I just tested this locally to confirm (selecting legacy-fs in the instal
Harry,
I think the issue you reported is, at base, the same that Nilani just reported
about Fedora using akubra even though the legacy store was selected.
-Eddie
On Sep 11, 2012, at 1:04 AM, Harry Sidhunata wrote:
> Hi All,
>
> I hope that someone can help to solve this migration issue.
> I
;
> I've just opened that issue and you can follow it:
>
> https://jira.duraspace.org/browse/FCREPO-1153
>
> - ---
> A. Soroka
> Software & Systems Engineering :: Online Library Environment
> the University of Virginia Library
>
> On Sep 13, 2012, at 10:20 AM, Ed
hmm, don't have the code before me, but I think you might be right (that you
need the atom xml). If memory serves, the REST API code just pre-fabricates a
foxml document for an ingest request when a foxml document isn't provided, but
doesn't do the same for the other formats (atom, mets).
seems
On Oct 26, 2012, at 11:04 PM, GitHub wrote:
>
> - I think i also fixed a bug in the test were XSD dates were used by tests
> for parsing
> Dates, but since these use as the year 1 BCE and joda time uses -0001
> i had to change these.
> Please check that i did it correctly
>
Frank,
Jesper,
I'd say fork master and submit a pull request. By the way, there's a committers
call today (Thursday) from 9-9:30am Eastern (UTC-5) if you want to jump in. I
think the agenda is mostly around the upcoming release of 3.6.2, but I'd
welcome having either (or both) of you and Nicolas join
Pierre-Yves,
My memory of 3.2.1 is a bit fuzzy. Are you saying that the /get//
request in 3.2.1 *does* return the Content-Length header but doesn't in 3.6.2?
All of "Lite" APIs (i.e. the /get/ requests) were deprecated as of Fedora 3.4
in favor of the REST API:
https://wiki.duraspace.o
Hi all,
I meant to send this out last week, but I forgot, mea culpa.
On our last call, we discussed some changes to the committers call:
i) re-focus the call to include Fedora Futures committers and FF general
discussion
ii) use Google Hangouts rather than FreeConferenceCallHD, which has been th
Thanks Don.
Fixed in the 3.6 docs
(https://wiki.duraspace.org/display/FEDORA36/REST+API#RESTAPI-getDatastreamHistory)
There was a point in development where it was /versions but we ultimately
settled on /history and the docs must not have followed, viz.
https://jira.duraspace.org/browse/FCREPO
I can't seem to find any information about the Aduna repo--i.e. is it gone
forever or if this was just an oversight by the domain owners.
I'll bring it up on the committers call today.
On Apr 18, 2013, at 5:57 PM, jan schnasse wrote:
> Hi all,
>
> fcrepo and mulgara, both define dependencies
Since most of the committers are traveling in Boston-area today, no call today.
Sorry for the late notice.
--
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance moni
On yesterday's standup, we discussed swapping the times for our thursday
standup and committers call.
Previously, the committers call was at 10:30am Eastern, followed by standup at
11:00am. That timing has proved a bit challenging since we typically end up
cutting short general discussions so i
94 matches
Mail list logo
