You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@marmotta.apache.org by Sergio Fernández <wi...@apache.org> on 2013/01/03 14:11:35 UTC
code importation and repo organization
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
[2] https://issues.apache.org/jira/browse/MARMOTTA-2
[3] http://wiki.apache.org/incubator/MarmottaProposal#Initial_Source
--
Sergio Fernández
Re: code importation and repo organization
Posted by Sebastian Schaffert <se...@gmail.com>.
2013/1/9 Sergio Fernández <wi...@apache.org>
> 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
>
Re: code importation and repo organization
Posted by Fabian Christ <ch...@googlemail.com>.
2013/1/9 Andy Seaborne <an...@apache.org>
> And NOTICE (or NOTICE.txt)
and a DISCLAIMER as long as we are in incubation.
http://incubator.apache.org/guides/branding.html#disclaimers
--
Fabian
http://twitter.com/fctwitt
Re: code importation and repo organization
Posted by Andy Seaborne <an...@apache.org>.
On 09/01/13 10:49, Sergio Fernández wrote:
> Hi,
>
> so, taking all comments into account, I would suggest the following root
> structure for the repository:
> .
> |-- pom.xml
> |-- README.txt
> |-- LICENSE.txt
And NOTICE (or NOTICE.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
>
> 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'.
>
> 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
>>> [2] https://issues.apache.org/jira/browse/MARMOTTA-2
>>> [3] http://wiki.apache.org/incubator/MarmottaProposal#Initial_Source
>>>
>>
>
Re: code importation and repo organization
Posted by Peter Ansell <an...@gmail.com>.
On 10 January 2013 19:07, Raffaele Palmieri <ra...@gmail.com> wrote:
> I'd not keep out SKOSJS from project such as
>
>> * lmf-search
>
> because they actually are an important way for build useful applications
> over linked data, in the future I would try to import in Marmotta Project,
> maybe in "application" folder for having a single point of access to entire
> code base.
It may make it difficult to manage the Marmotta project if it becomes
a monolith that is a single point of access for everything related to
linked data. See Stanbol and Clerezza for experiences relating to the
difficulty managing monolithic projects.
Cheers,
Peter
Re: code importation and repo organization
Posted by Sebastian Schaffert <ss...@apache.org>.
Hi all,
2013/1/11 Sergio Fernández <se...@salzburgresearch.at>
> Raffaele,
>
> in the incubation proposal we asserted that:
>
> http://wiki.apache.org/**incubator/MarmottaProposal#**Initial_Source<http://wiki.apache.org/incubator/MarmottaProposal#Initial_Source>
>
> The idea is to focus Marmotta in its main business. Therefore LMF will be
> transformed into an app which, using Marmotta as core, keeps such media
> features.
>
> Hope this proposal would fit in your plans or usages of LMF/Marmotta.
>
I'd like to second that and emphasize the two following points:
- Marmotta should focus on the core business (Linked Data Platform) and be
very modular and extensible (and not follow the monolithic approach of
Stanbol and Clerezza)
- LMF will continue to exist as an application building on top of Marmotta
and adding features like Semantic Search (using SOLR) or content
enhancement (using Stanbol)
You could then even see the LMF as a "proof" that Marmotta is indeed
modular and extensible.
In case you are interested in the Semantic Search functionality of LMF, you
will still be able to use it. In case we later decide that these features
should also become part of Marmotta, this will always be possible (I can
ensure you that we will continue using the Apache License).
Greetings,
Sebastian
>
> Cheers,
>
>
> On 10/01/13 10:07, Raffaele Palmieri wrote:
>
>> I'd not keep out SKOSJS from project such as
>>
>> * lmf-search
>>>
>>
>> because they actually are an important way for build useful applications
>> over linked data, in the future I would try to import in Marmotta Project,
>> maybe in "application" folder for having a single point of access to
>> entire
>> code base.
>> I'd consider in the same way following projects:
>>
>> * lmf-social
>>> * lmf-classifier
>>> * lmf-stanbol
>>>
>>
>> Regards,
>> Raffaele.
>>
>> On 10 January 2013 09:00, Jakob Frank<ja...@apache.org> wrote:
>>
>> On Wed, 2013-01-09 at 17:07 +0100, Thomas Kurz wrote:
>>>
>>>> I'm not sure if we should include SKOSJS, as
>>>> it is a standalone project.
>>>>
>>> I'd leave SKOSJS out of Marmotta.
>>>
>>> Best,
>>> Jakob
>>>
>>>
>>
> --
> Sergio Fernández
> Salzburg Research
> +43 662 2288 318
> Jakob-Haringer Strasse 5/II
> A-5020 Salzburg (Austria)
> http://www.salzburgresearch.at
>
Re: code importation and repo organization
Posted by Sergio Fernández <se...@salzburgresearch.at>.
Hi Raffaele,
On 11/01/13 14:48, Raffaele Palmieri wrote:
> OK I share these objectives of Marmotta, but I ask myself and
> yourself what kind of deliverables project will product.
> Will Apache Marmotta's deliverables be only libraries to use in vertical
> projects, such as LMF could be? Or will they regard about typical use cases
> of LDP, that, other than classification and search, could include a subset of
> those specified as *Linked Data Platform Use Cases And Requirements*
> (ldp-ucr)?
Besides the reusable libraries internally used (Sesame Tools, LDPath,
etc.), Marmotta will deliver a server infrastructure supporting:
* Linked Data Platform 1.0, including LDP Resources and LDP Containers,
hopefully providing a full implementation of the uses cases and
requirements which are being specified by the working group at W3C.
* SPARQL 1.1, at least Protocol, Service Description and Graph Store
HTTP Protocol.
That's the main goal. Additionally we'll also provide some
infrastructure for the client side (the evolution of the current LMF
Client Library) and its integration with third-party tools (Refine,
Drupal and so on).
Hope this clarifies a bit more the roadmap. Further details at the
incubation proposal:
http://wiki.apache.org/incubator/MarmottaProposal#Initial_Goals
Cheers,
>
>
> On 11 January 2013 14:10, Sergio Fernández<
> sergio.fernandez@salzburgresearch.at> wrote:
>
>> Raffaele,
>>
>> in the incubation proposal we asserted that:
>>
>> http://wiki.apache.org/**incubator/MarmottaProposal#**Initial_Source<http://wiki.apache.org/incubator/MarmottaProposal#Initial_Source>
>>
>> The idea is to focus Marmotta in its main business. Therefore LMF will be
>> transformed into an app which, using Marmotta as core, keeps such media
>> features.
>>
>> Hope this proposal would fit in your plans or usages of LMF/Marmotta.
>>
>> Cheers,
>>
>> On 10/01/13 10:07, Raffaele Palmieri wrote:
>>
>>> I'd not keep out SKOSJS from project such as
>>>
>>> * lmf-search
>>>>
>>>
>>> because they actually are an important way for build useful applications
>>> over linked data, in the future I would try to import in Marmotta Project,
>>> maybe in "application" folder for having a single point of access to
>>> entire
>>> code base.
>>> I'd consider in the same way following projects:
>>>
>>> * lmf-social
>>>> * lmf-classifier
>>>> * lmf-stanbol
>>>>
>>>
>>> Regards,
>>> Raffaele.
>>>
>>> On 10 January 2013 09:00, Jakob Frank<ja...@apache.org> wrote:
>>>
>>> On Wed, 2013-01-09 at 17:07 +0100, Thomas Kurz wrote:
>>>>
>>>>> I'm not sure if we should include SKOSJS, as
>>>>> it is a standalone project.
>>>>>
>>>> I'd leave SKOSJS out of Marmotta.
>>>>
>>>> Best,
>>>> Jakob
>>>>
>>>>
>>>
>> --
>> Sergio Fernández
>> Salzburg Research
>> +43 662 2288 318
>> Jakob-Haringer Strasse 5/II
>> A-5020 Salzburg (Austria)
>> http://www.salzburgresearch.at
>>
>
--
Sergio Fernández
Salzburg Research
+43 662 2288 318
Jakob-Haringer Strasse 5/II
A-5020 Salzburg (Austria)
http://www.salzburgresearch.at
Re: code importation and repo organization
Posted by Raffaele Palmieri <ra...@gmail.com>.
Sergio, OK I share these objectives of Marmotta, but I ask myself and
yourself what kind of deliverables project will product.
Will Apache Marmotta's deliverables be only libraries to use in vertical
projects, such as LMF could be? Or will they regard about typical use cases
of LDP, that, other than classification and search, could include a subset of
those specified as *Linked Data Platform Use Cases And Requirements*
(ldp-ucr)?
Cheers,
Raffaele.
On 11 January 2013 14:10, Sergio Fernández <
sergio.fernandez@salzburgresearch.at> wrote:
> Raffaele,
>
> in the incubation proposal we asserted that:
>
> http://wiki.apache.org/**incubator/MarmottaProposal#**Initial_Source<http://wiki.apache.org/incubator/MarmottaProposal#Initial_Source>
>
> The idea is to focus Marmotta in its main business. Therefore LMF will be
> transformed into an app which, using Marmotta as core, keeps such media
> features.
>
> Hope this proposal would fit in your plans or usages of LMF/Marmotta.
>
> Cheers,
>
> On 10/01/13 10:07, Raffaele Palmieri wrote:
>
>> I'd not keep out SKOSJS from project such as
>>
>> * lmf-search
>>>
>>
>> because they actually are an important way for build useful applications
>> over linked data, in the future I would try to import in Marmotta Project,
>> maybe in "application" folder for having a single point of access to
>> entire
>> code base.
>> I'd consider in the same way following projects:
>>
>> * lmf-social
>>> * lmf-classifier
>>> * lmf-stanbol
>>>
>>
>> Regards,
>> Raffaele.
>>
>> On 10 January 2013 09:00, Jakob Frank<ja...@apache.org> wrote:
>>
>> On Wed, 2013-01-09 at 17:07 +0100, Thomas Kurz wrote:
>>>
>>>> I'm not sure if we should include SKOSJS, as
>>>> it is a standalone project.
>>>>
>>> I'd leave SKOSJS out of Marmotta.
>>>
>>> Best,
>>> Jakob
>>>
>>>
>>
> --
> Sergio Fernández
> Salzburg Research
> +43 662 2288 318
> Jakob-Haringer Strasse 5/II
> A-5020 Salzburg (Austria)
> http://www.salzburgresearch.at
>
Re: code importation and repo organization
Posted by Sergio Fernández <se...@salzburgresearch.at>.
Raffaele,
in the incubation proposal we asserted that:
http://wiki.apache.org/incubator/MarmottaProposal#Initial_Source
The idea is to focus Marmotta in its main business. Therefore LMF will
be transformed into an app which, using Marmotta as core, keeps such
media features.
Hope this proposal would fit in your plans or usages of LMF/Marmotta.
Cheers,
On 10/01/13 10:07, Raffaele Palmieri wrote:
> I'd not keep out SKOSJS from project such as
>
>> * lmf-search
>
> because they actually are an important way for build useful applications
> over linked data, in the future I would try to import in Marmotta Project,
> maybe in "application" folder for having a single point of access to entire
> code base.
> I'd consider in the same way following projects:
>
>> * lmf-social
>> * lmf-classifier
>> * lmf-stanbol
>
> Regards,
> Raffaele.
>
> On 10 January 2013 09:00, Jakob Frank<ja...@apache.org> wrote:
>
>> On Wed, 2013-01-09 at 17:07 +0100, Thomas Kurz wrote:
>>> I'm not sure if we should include SKOSJS, as
>>> it is a standalone project.
>> I'd leave SKOSJS out of Marmotta.
>>
>> Best,
>> Jakob
>>
>
--
Sergio Fernández
Salzburg Research
+43 662 2288 318
Jakob-Haringer Strasse 5/II
A-5020 Salzburg (Austria)
http://www.salzburgresearch.at
Re: code importation and repo organization
Posted by Raffaele Palmieri <ra...@gmail.com>.
I'd not keep out SKOSJS from project such as
> * lmf-search
because they actually are an important way for build useful applications
over linked data, in the future I would try to import in Marmotta Project,
maybe in "application" folder for having a single point of access to entire
code base.
I'd consider in the same way following projects:
> * lmf-social
> * lmf-classifier
> * lmf-stanbol
Regards,
Raffaele.
On 10 January 2013 09:00, Jakob Frank <ja...@apache.org> wrote:
> On Wed, 2013-01-09 at 17:07 +0100, Thomas Kurz wrote:
> > I'm not sure if we should include SKOSJS, as
> > it is a standalone project.
> I'd leave SKOSJS out of Marmotta.
>
> Best,
> Jakob
>
Re: code importation and repo organization
Posted by Sebastian Schaffert <ss...@apache.org>.
2013/1/13 Jakob Frank <ja...@apache.org>
> On 12 Jan 2013 20:02, "Sergio Fernández" <wi...@apache.org> wrote:
> >> Btw: I assume the history of the old repository will be lost during the
> >> import process, will it not?
> > What do you mean, the current lmf repos at google code?
> Let me clarify the question: The Marmotta git repository will not have all
> the LMF history. Or should we try to migrate it too?
>
I think it does not make sense moving all the history of the LMF to
Marmotta. There are still some things from KiWi and early LMF in it that do
not really make sense to keep (there are even videos we used for testing),
even if it was possible moving a repository from Mercurial to GIT (which it
is not, AFAIK). The LMF history can stay at Google Code, anyone can look at
it anyways. At Apache, we should start with a current snapshot instead.
>
> > Personally I'd move out from there the imported modules in Marmotta,
> reorganize LMF to depend on Marmotta, but keep the whole history for
> whatever it could be useful in the future. So do it differently than with
> KiWi, for instance.
> +1
>
+1
Greetings,
Sebastian
Re: code importation and repo organization
Posted by Jakob Frank <ja...@apache.org>.
On 12 Jan 2013 20:02, "Sergio Fernández" <wi...@apache.org> wrote:
>> Btw: I assume the history of the old repository will be lost during the
>> import process, will it not?
> What do you mean, the current lmf repos at google code?
Let me clarify the question: The Marmotta git repository will not have all
the LMF history. Or should we try to migrate it too?
> Personally I'd move out from there the imported modules in Marmotta,
reorganize LMF to depend on Marmotta, but keep the whole history for
whatever it could be useful in the future. So do it differently than with
KiWi, for instance.
+1
Best,
Jakob
Re: code importation and repo organization
Posted by Sergio Fernández <wi...@apache.org>.
Jakob,
On 11/01/13 19:32, Jakob Frank wrote:
> Btw: I assume the history of the old repository will be lost during the
> import process, will it not?
What do you mean, the current lmf repos at google code?
Personally I'd move out from there the imported modules in Marmotta,
reorganize LMF to depend on Marmotta, but keep the whole history for
whatever it could be useful in the future. So do it differently than
with KiWi, for instance.
Cheers,
--
Sergio Fernández
Re: code importation and repo organization
Posted by Jakob Frank <ja...@apache.org>.
On 11 Jan 2013 14:27, "Sergio Fernández" <
sergio.fernandez@salzburgresearch.at> wrote:
> .
> |-- pom.xml
> |-- COPYING.txt
> |-- DISCLAIMER.txt
> |-- LICENSE.txt
> |-- NOTICE.txt
> |-- README.txt
> |-- ...
> `-- platform
> `-- clients
> `-- libs
> `-- tools
> `-- extras
> `-- import
>
> Where 'import' could be remove whenever importation process would be
finish.
+1
> Regarding the issue with SKOSjs, I don't have a clear opinion. But we
should take into account that, if we leave it out at its independent
repository, the artifact should be available via Maven central before the
first Marmotta release.
+1 to keeping it independent.
Btw: I assume the history of the old repository will be lost during the
import process, will it not?
Best,
Jakob
Re: code importation and repo organization
Posted by Sebastian Schaffert <ss...@apache.org>.
2013/1/11 Sergio Fernández <se...@salzburgresearch.at>
> Ok, taking into account all comment, I'd update my proposal regarding
> repository structure would look like:
>
> .
> |-- pom.xml
> |-- COPYING.txt
> |-- DISCLAIMER.txt
> |-- LICENSE.txt
> |-- NOTICE.txt
> |-- README.txt
> |-- ...
> `-- platform
> `-- clients
> `-- libs
> `-- tools
> `-- extras
> `-- import
>
> Where 'import' could be remove whenever importation process would be
> finish.
>
+1
>
> Regarding the issue with SKOSjs, I don't have a clear opinion. But we
> should take into account that, if we leave it out at its independent
> repository, the artifact should be available via Maven central before the
> first Marmotta release.
>
>
Yes, either this or it should be part of Marmotta.
> BTW, as we already discussed internally, I'd suggest to use a branching
> workflow where we have a stable "master" branch and a unstable "develop"
> branch. Besides, optionally "topic" branches for each topic/issue, which
> don't need to be pushed to the public repository. Further details about
> this workflow at the Pro Git book:
>
> http://git-scm.com/book/en/**Git-Branching-Branching-**Workflows<http://git-scm.com/book/en/Git-Branching-Branching-Workflows>
>
>
+1
We will set this up next week after the proposal deadline on Tuesday.
Greetings,
Sebastian
Re: code importation and repo organization
Posted by Peter Ansell <an...@gmail.com>.
On 11 January 2013 23:26, Sergio Fernández
<se...@salzburgresearch.at> wrote:
> Ok, taking into account all comment, I'd update my proposal regarding
> repository structure would look like:
>
> .
> |-- pom.xml
> |-- COPYING.txt
> |-- DISCLAIMER.txt
> |-- LICENSE.txt
> |-- NOTICE.txt
> |-- README.txt
> |-- ...
> `-- platform
> `-- clients
> `-- libs
> `-- tools
> `-- extras
> `-- import
>
> Where 'import' could be remove whenever importation process would be finish.
>
> Regarding the issue with SKOSjs, I don't have a clear opinion. But we should
> take into account that, if we leave it out at its independent repository,
> the artifact should be available via Maven central before the first Marmotta
> release.
>
> BTW, as we already discussed internally, I'd suggest to use a branching
> workflow where we have a stable "master" branch and a unstable "develop"
> branch. Besides, optionally "topic" branches for each topic/issue, which
> don't need to be pushed to the public repository. Further details about this
> workflow at the Pro Git book:
Recently I have started using either just a Jira issue identifier for
topic branch names, or including the issue identifier with something
else if there are multiple topic branches for an issue. Ie, MARMOTTA-1
could be a branch in git for that issue (hypothetically) or
MARMOTTA-1-some-subtask if there was more than one branch needed for
the issue.
I have also used the git-flow methodology (master/develop)
successfully on a few projects.
> http://git-scm.com/book/en/Git-Branching-Branching-Workflows
Peter
Re: code importation and repo organization
Posted by Sergio Fernández <se...@salzburgresearch.at>.
Ok, taking into account all comment, I'd update my proposal regarding
repository structure would look like:
.
|-- pom.xml
|-- COPYING.txt
|-- DISCLAIMER.txt
|-- LICENSE.txt
|-- NOTICE.txt
|-- README.txt
|-- ...
`-- platform
`-- clients
`-- libs
`-- tools
`-- extras
`-- import
Where 'import' could be remove whenever importation process would be finish.
Regarding the issue with SKOSjs, I don't have a clear opinion. But we
should take into account that, if we leave it out at its independent
repository, the artifact should be available via Maven central before
the first Marmotta release.
BTW, as we already discussed internally, I'd suggest to use a branching
workflow where we have a stable "master" branch and a unstable "develop"
branch. Besides, optionally "topic" branches for each topic/issue, which
don't need to be pushed to the public repository. Further details about
this workflow at the Pro Git book:
http://git-scm.com/book/en/Git-Branching-Branching-Workflows
Cheers,
--
Sergio Fernández
Salzburg Research
+43 662 2288 318
Jakob-Haringer Strasse 5/II
A-5020 Salzburg (Austria)
http://www.salzburgresearch.at
Re: code importation and repo organization
Posted by Jakob Frank <ja...@apache.org>.
On Wed, 2013-01-09 at 17:07 +0100, Thomas Kurz wrote:
> I'm not sure if we should include SKOSJS, as
> it is a standalone project.
I'd leave SKOSJS out of Marmotta.
Best,
Jakob
Re: code importation and repo organization
Posted by Thomas Kurz <tk...@apache.org>.
Hi,
I think the structure is okay. I'm not sure if we should include SKOSJS, as
it is a standalone project.
If you want to include it, I would prefer 'extras' or 'application'.
Regards
Thomas
On Wed, Jan 9, 2013 at 11:49 AM, Sergio Fernández <wi...@apache.org> wrote:
> 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
>
> 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'.
>
> 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
>
Re: code importation and repo organization
Posted by Andy Seaborne <an...@apache.org>.
Just to add an idea, with no particular advocacy:
If you are both designing the layout and the performing the initiai code
import as per the grant, it can be useful is import the code as-is into
an "/import" area to get it onto Apache systems. Doesn't have to be
neat and well-planned or even build, but it achieves the import and
grant goals.
Then different parts from be copied across to the correct location, with
or without experimentation in layouts and without needing a proper
destination for every piece.
This has the useful side effect of keeping an record of exactly what was
imported in the first place. Some projects then delete /import, which
can be restored, or just leave it for the record.
Andy
Re: code importation and repo organization
Posted by Rupert Westenthaler <ru...@gmail.com>.
Hi,
On 09.01.2013, at 11:49, Sergio Fernández <wi...@apache.org> wrote:
> `-- server
> `-- client
> `-- tools
> `-- extras
>
> Where:
> * 'server' will contain the actual Linked Data server
I would not use "server" as root for the "Linked Data Platform" implementation but rather use it for providing different server configurations, packagings and so on. IMO "ldp" or "core" would be better candidates for modules implementing the "Linked Data Platform".
best
Rupert
> * '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
>
> 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'.
>
> 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
>>> [2] https://issues.apache.org/jira/browse/MARMOTTA-2
>>> [3] http://wiki.apache.org/incubator/MarmottaProposal#Initial_Source
>>>
>>
>
> --
> Sergio Fernández
Re: code importation and repo organization
Posted by Sergio Fernández <wi...@apache.org>.
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
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'.
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
>> [2] https://issues.apache.org/jira/browse/MARMOTTA-2
>> [3] http://wiki.apache.org/incubator/MarmottaProposal#Initial_Source
>>
>
--
Sergio Fernández
Re: code importation and repo organization
Posted by Jakob Frank <ja...@apache.org>.
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
> [2] https://issues.apache.org/jira/browse/MARMOTTA-2
> [3] http://wiki.apache.org/incubator/MarmottaProposal#Initial_Source
>
Re: code importation and repo organization
Posted by Sebastian Schaffert <se...@gmail.com>.
Hi Sergio,
2013/1/3 Sergio Fernández <wi...@apache.org>
> 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
>
I have one small addition here. I am currently working on separating the
KiWi triple store from the LMF so 1) it can be used outside the LMF as
Sesame SAIL, and 2) the LMF can be used with any other Sesame backend. I
would also consider this as a generic library. It is in the module
* kiwi
in the triplestore branch of Mercurial. Before importing the code into GIT,
we should merge back all branches to make sure everything is available
there.
>
> 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
>
My idea here was to keep them on the Google Code repository under the name
LMF, but let them depend on Apache Marmotta in future versions. But we
could also consider having "contrib" or "extra" modules in Marmotta itself.
>
> But I have doubts regarding some third-party tools:
>
> * SKOSjs
>
Should be a separate project, but Marmotta should depend on it. Maybe we
can use the Maven JavaScript dependency management for it?
> * Module for Drupal
>
"contrib" or "extra" ;-)
> * Extension for Google/Open Refine
>
>
"contrib" or "extra" ;-)
Greetings,
Sebastian
Re: code importation and repo organization
Posted by Peter Ansell <an...@gmail.com>.
Hi Fabian,
On Thursday, 3 January 2013, Fabian Christ wrote:
> Hi,
>
> just two things that come to my mind from the experiences we made with
> importing the first code for Stanbol from the IKS project.
>
> Do you know of the use of any third party libs that are either
>
> a) not available via Maven central
OpenRDF Sesame is in Maven Central as of 2.7.0-beta1. If necessary I could
also look into getting 2.6.10 redistributed to Maven Central.
Cheers,
Peter
Re: code importation and repo organization
Posted by Andy Seaborne <an...@apache.org>.
On 04/01/13 08:50, Sebastian Schaffert wrote:
> 2013/1/3 Andy Seaborne <an...@apache.org>
>
>> On 03/01/13 13:24, Fabian Christ wrote:
>>
>>> Hi,
>>>
>>> just two things that come to my mind from the experiences we made with
>>> importing the first code for Stanbol from the IKS project.
>>>
>>> Do you know of the use of any third party libs that are either
>>>
>>> a) not available via Maven central
>>> b) licensed under terms that are not compatible with the Apache License,
>>> 2.0? (e.g. GPL)
>>>
>>> For a): If libs are not available in Maven central we need to create
>>> appropriate "-deps" packages that contain everything needed for the build.
>>> Source releases of Marmotta are not allowed to include any binaries, like
>>> JAR files. This can be a struggling point for the build process.
>>>
>>> For b): Dealing with licensing issues can slow down the release process
>>> tremendously. Knowing of modules which may by problematic before importing
>>> them could make things easier.
>>>
>>> Best,
>>> - Fabian
>>>
>>
>> I completely agree with Fabian that sorting licenses can slow down the
>> release. It's not something to leave until everything else is ready.
>>
>
> We have always been careful with licensing for the LMF. To the best of my
> knowledge, the only incompatible library is XOM, which is still used in
> some places. I wanted to wait with rewriting to JDOM until we are finished
> with refactoring, but then it should be easy.
>
> I'll look through the rest of the mails today and add comments - just
> returned from vacations ;-)
Your prudence and care is about to be rewarded!
Andy
>
> Sebastian
>
Re: code importation and repo organization
Posted by Sebastian Schaffert <se...@gmail.com>.
2013/1/3 Andy Seaborne <an...@apache.org>
> On 03/01/13 13:24, Fabian Christ wrote:
>
>> Hi,
>>
>> just two things that come to my mind from the experiences we made with
>> importing the first code for Stanbol from the IKS project.
>>
>> Do you know of the use of any third party libs that are either
>>
>> a) not available via Maven central
>> b) licensed under terms that are not compatible with the Apache License,
>> 2.0? (e.g. GPL)
>>
>> For a): If libs are not available in Maven central we need to create
>> appropriate "-deps" packages that contain everything needed for the build.
>> Source releases of Marmotta are not allowed to include any binaries, like
>> JAR files. This can be a struggling point for the build process.
>>
>> For b): Dealing with licensing issues can slow down the release process
>> tremendously. Knowing of modules which may by problematic before importing
>> them could make things easier.
>>
>> Best,
>> - Fabian
>>
>
> I completely agree with Fabian that sorting licenses can slow down the
> release. It's not something to leave until everything else is ready.
>
We have always been careful with licensing for the LMF. To the best of my
knowledge, the only incompatible library is XOM, which is still used in
some places. I wanted to wait with rewriting to JDOM until we are finished
with refactoring, but then it should be easy.
I'll look through the rest of the mails today and add comments - just
returned from vacations ;-)
Sebastian
Re: code importation and repo organization
Posted by Andy Seaborne <an...@apache.org>.
On 03/01/13 13:24, Fabian Christ wrote:
> Hi,
>
> just two things that come to my mind from the experiences we made with
> importing the first code for Stanbol from the IKS project.
>
> Do you know of the use of any third party libs that are either
>
> a) not available via Maven central
> b) licensed under terms that are not compatible with the Apache License,
> 2.0? (e.g. GPL)
>
> For a): If libs are not available in Maven central we need to create
> appropriate "-deps" packages that contain everything needed for the build.
> Source releases of Marmotta are not allowed to include any binaries, like
> JAR files. This can be a struggling point for the build process.
>
> For b): Dealing with licensing issues can slow down the release process
> tremendously. Knowing of modules which may by problematic before importing
> them could make things easier.
>
> Best,
> - Fabian
I completely agree with Fabian that sorting licenses can slow down the
release. It's not something to leave until everything else is ready.
An Apache release is source code, normally a zip file. All this binary
stuff for maven is "just" convenient extras (and what the vast majority
of users actually use :-)
Looking at other projects can be very helpful. Pick a project - look in
their source code repository. NOTICE and LICENSE are easy to find -
they should be at the top of trunk.
The NOTICE file should be as short as possible, and include copyright
notices. The LICENSE file should have copies of all licenses.
For each dependency (binary), the licensing needs to be checked.
Usually, it's one of the common licenses and it's quite easy.
http://www.apache.org/legal/3party.html
You do need to be careful of variations (e.g. modified license text - we
had a few in Jena which were at first glance BSD-style but actually had
been rewritten a bit).
If any binaries produced repackage (redistribute) other systems, there
will need to be stuff done for that. For example, Jena redistributes
Xerces in the all-in-one zip download, so even though Xerces is ASL
there are some recursive copyrights to put in the NOTICE for the zip
download which are not there in the jena jar or source-release which
themselves use xerces by-POM but don't redistribute it.
For each piece of incorporated source code, both copyright and license
need to be noted. My experience is that this takes a bit more chasing
down than binaries.
All this legal stuff isn't zero effect but it's not as bad as it's
sometimes painted. Apache is just quite careful - indeed, having done
the legal side of a project, you'll look at some other places and tut a bit!
Andy
>
>
> 2013/1/3 Sergio Fernández <wi...@apache.org>
>
>> 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
>>
>
>
>
Re: code importation and repo organization
Posted by Fabian Christ <ch...@googlemail.com>.
Hi,
just two things that come to my mind from the experiences we made with
importing the first code for Stanbol from the IKS project.
Do you know of the use of any third party libs that are either
a) not available via Maven central
b) licensed under terms that are not compatible with the Apache License,
2.0? (e.g. GPL)
For a): If libs are not available in Maven central we need to create
appropriate "-deps" packages that contain everything needed for the build.
Source releases of Marmotta are not allowed to include any binaries, like
JAR files. This can be a struggling point for the build process.
For b): Dealing with licensing issues can slow down the release process
tremendously. Knowing of modules which may by problematic before importing
them could make things easier.
Best,
- Fabian
2013/1/3 Sergio Fernández <wi...@apache.org>
> 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
>
--
Fabian
http://twitter.com/fctwitt
Re: code importation and repo organization
Posted by Thomas Kurz <th...@googlemail.com>.
Hi all
first of all, happy new year. And thanks to Sergio!
I added some comments inline.
On Thu, Jan 3, 2013 at 2:11 PM, Sergio Fernández <wi...@apache.org> 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
>
I dont't think all of them are necessary for Marmotta. I would exclude:
* lmf-scheduler: I do not see why we need this in the Marmotta basic
functionality
* lmf-security: In the current implementation the name of the module in the
context of a Linked Data Platform is misleading We need a security module,
indeed. But it should be more resource centered (like the WebID, ACL
approach), the current one is for managing webservice access (via URI
prefixes). Maybe we can put the existing filter implementation in the core
as is a central functionality for a server application.
* lmf-user is missing. I think this is a basic functionality for read-write
web. Even the existing module is improvable we should integrate it.
> 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
>
As the project is independent from Marmotta (it uses SPARQL 1.1 query
language and protocol for read-write) I don't think, it should be moved to
Marmotta
> * 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
>
Best regards!
Thomas
Re: code importation and repo organization
Posted by Sebastian Schaffert <ss...@apache.org>.
Hi Peter,
2013/1/10 Peter Ansell <an...@gmail.com>
> On 3 January 2013 23:11, Sergio Fernández <wi...@apache.org> 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.
> >
>
> > * sesame-tools
>
> Just for reference, will my sesame-tools BitBucket Pull Request be
> merged before the transfer of the code to Marmotta. If not I can
> resubmit the patch to Apache Jira, to fulfill the legal obstacles that
> Apache is concerned about. I have signed an Apache ICLA for Any23,
> which should still be relevant to Marmotta unless there is some other
> hoop I have to jump through.
>
Both options are fine for me, whatever you prefer. :)
For submitting a patch to JIRA you AFAIK don't need a signed ICLA (but it
never hurts...).
Greetings,
Sebastian
Re: code importation and repo organization
Posted by Peter Ansell <an...@gmail.com>.
On 3 January 2013 23:11, Sergio Fernández <wi...@apache.org> 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.
>
> * sesame-tools
Just for reference, will my sesame-tools BitBucket Pull Request be
merged before the transfer of the code to Marmotta. If not I can
resubmit the patch to Apache Jira, to fulfill the legal obstacles that
Apache is concerned about. I have signed an Apache ICLA for Any23,
which should still be relevant to Marmotta unless there is some other
hoop I have to jump through.
Cheers,
Peter