2013/1/9 Sergio Fernández <[email protected]> > Hi, > > so, taking all comments into account, I would suggest the following root > structure for the repository: > . > |-- pom.xml > |-- README.txt > |-- LICENSE.txt > |-- COPYING.txt > |-- ... > `-- server > `-- client > `-- tools > `-- extras > > Where: > * 'server' will contain the actual Linked Data server > * 'client' the different implementations of the client library > * 'tools' all useful tools, including installation infrastructure, maven > plugins and archetypes > * 'extras' all extra stuff, such as kiwi triple store, sesame tools, > ldpath and so on >
I would not call it extra then, because these are all libraries used by the server and/or client and not "just extra". How about "libs" or "backend"? > > Hope this proposal would fit with current and future modules. > > What I'm not sure is how to do with some things, such as SKOSjs... maybe > put it under 'extras'. > This yes. :) > > Cheers, > > > > On 08/01/13 14:24, Jakob Frank wrote: > >> Hi, >> >> from my point of view after reading through the thread we should have >> four main "products/branches/reop-parts" with the current lmf-modules >> assigned as followed >> >> - Linked Data Server >> - lmf-core >> - lmf-sparql >> - lmf-ldcache >> - lmf-ldpath >> - lmf-webapp >> - lmf-installer >> - lmf-splash (?) >> - Client Libraries >> - lmf-client-* >> - KiWi Triple Store >> - kiwi >> - lmf-reasoner >> - lmf-versioning >> - LDPath >> - ldpath >> - Tools& More >> >> - *-maven-plugin >> - lmf-archetype-* >> - sesame >> >> I'm not sure about lmf-splash (maybe this should be merged into >> lmf-installer?). >> >> Like Thomas, I think lmf-security in its current state should be rather >> merged into lmf-core and replaced by a resource/triple centered security >> module. >> >> On the other hand I believe lmf-user is too closely coupled to the >> backend database model to be used with a generic sesame backend. >> (Sebastian is currently working on this separation (KiWi Triple Store)). >> >> >> Best, >> Jakob >> >> On Thu, 2013-01-03 at 14:11 +0100, Sergio Fernández wrote: >> >>> Hi, >>> >>> Now that INFRA-5610 [1] has been solved, before work over MARMOTTA-2 >>> [2], in the following days I'd like to discuss with all people what code >>> we'll import into Marmotta. >>> >>> The idea is to have a milestone releasing LMF 2.4 this month, and then >>> move to Marmotta. But, as we asserted in the proposal [3], the whole LMF >>> will not be contributed to Marmotta; to focus the project, actually only >>> those parts that make up the "Linked Data Platform", that includes the >>> following modules: >>> >>> * lmf-core >>> * lmf-sparql >>> * lmf-cache >>> * lmf-reasoner >>> * lmf-scheduler >>> * lmf-security >>> * lmf-ldpath >>> * lmf-versioning >>> * lmf-webapp >>> >>> There are some generic libraries we may also include: >>> >>> * ldpath >>> * sesame-tools >>> >>> Plus some installation infrastructure: >>> >>> * lmf-installer >>> * lmf-splash >>> >>> Around that there are some Maven plugins: >>> >>> * lmf-maven-plugin >>> * buildinfo-maven-plugin >>> * refpack-maven-plugin >>> >>> And archetypes: >>> >>> * lmf-archetype-module >>> * lmf-archetype-webapp >>> >>> On top of that, the lmf client library is currently implemented in >>> different languages: >>> >>> * lmf-client-java >>> * lmf-client-php >>> * lmf-client-js >>> >>> Besides some refactorizations and reorganization, I consider all those >>> artifacts relevant for Marmotta. >>> >>> For instance, all the media stuff would be out of the importation, >>> including: >>> >>> * lmf-search >>> * lmf-social >>> * lmf-classifier >>> * lmf-stanbol >>> >>> But I have doubts regarding some third-party tools: >>> >>> * SKOSjs >>> * Module for Drupal >>> * Extension for Google/Open Refine >>> >>> >>> What do you think? >>> >>> Cheers, >>> >>> >>> [1] >>> https://issues.apache.org/**jira/browse/INFRA-5610<https://issues.apache.org/jira/browse/INFRA-5610> >>> [2] >>> https://issues.apache.org/**jira/browse/MARMOTTA-2<https://issues.apache.org/jira/browse/MARMOTTA-2> >>> [3] >>> http://wiki.apache.org/**incubator/MarmottaProposal#**Initial_Source<http://wiki.apache.org/incubator/MarmottaProposal#Initial_Source> >>> >>> >> > -- > Sergio Fernández >
