You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@marmotta.apache.org by Qihong Lin <co...@gmail.com> on 2014/05/02 16:18:34 UTC

Re: [GSoC] community bonding period

Dear Sergio,

I follow your instructions to complete these task, with some questions:

1) I fork the mirror as confidencesun/marmotta [1], while
confidencesun is my github id.
I add you in the "Collaborators" of this repository [1]. Is that the
way you get the admin permissions?

2) I create a branch of MARMOTTA-444 from develop
I use eclipse (Juno), egit and m2e as the development tools to work it
out. Do you the same toolkit?

3) I clone the repository [1] to the local git.
I also try to import the local "marmotta-ldp" into eclipse as a maven
project. But at the step of "Setup Maven plugin connectors", I get the
error:
----
No marketplace entries found to handle
maven-download-plugin:1.1.0:wget in Eclipse.  Please see Help for more
information.
----
I choose to "resolve later", and pom of the project "marmotta-ldp"
shows the error:
----
Plugin execution not covered by lifecycle configuration:
com.googlecode.maven-download-plugin:maven-download-plugin:1.1.0:wget
(execution: download-ldp-test-cases, phase: process-test-resources)
----
It seems the m2e connector of "maven-download-plugin" is not installed
properly. I google for a long time, without successful solutions.
Could you please help me out?

4) I have to comment out the "maven-download-plugin" in the pom to
make everything compiles in eclipse. The project of "marmotta-ldp" and
its dependency projects look fine now in eclipse (see the attachment
picture). I think, the project of "marmotta-ldp" is the place I'd play
around, in this summer.

5) I "push" the modification of 4) to the remote github branch of
"MARMOTTA-444". It seems OK. I think this is the way to commit code :)
Could you please make any modification to the upstream? I'd like to
test the "pull" synchronization.


Cheers,
Qihong Lin

[1] https://github.com/confidencesun/marmotta
[2] https://github.com/maven-download-plugin/maven-download-plugin




On Tue, Apr 29, 2014 at 5:46 PM, Sergio Fernández <wi...@apache.org> wrote:
> Hi Qihong Lin,
>
>
> On 26/04/14 15:13, Qihong Lin wrote:
>>
>> Thanks for your reminder! I'm so happy to be accepted by GSoC. I'll
>> try my best in this summer to contribute to Marmotta.
>
>
> I'm sure you will ;-)
>
>
>> In the first place, I'd like to set up the development environment.
>> I've read the documentation of Marmotta development [1]. Could you
>> please tell me where I should commit the code, in asf [2] or github
>> [3]? Which branch am I supposed to work with, the hotfix branch,
>> develop branch or the master branch? Shall I submit the patches to the
>> community or directly commit the code to git?
>
>
> I do not have so much experience with GSoC, and as far as I've checked there
> is no common approach among all ASF projects...
>
> For me the best approach would be to use github for developing your project.
> So, you can:
>
>   * Fork our mirror there [1] and give me (wikier) admin permissions.
>   * Create, at least,  a branch from 'develop' for your project;
>     according our development guidelines [2], I'd recommend you to
>     use the issue [3] as name for the branch: MARMOTTA-444.
>   * I'll closely follow your development there, using the comments on
>     the code committed to provide you early feedback.
>   * Create issues there for internal issues of the project.
>   * But please use this mailing list for any further discussion.
>   * Since your project is related with code that is still evolving,
>     try to keep periodically updated your fork from upstream [4].
>
> Therefore, at the end we have all information to evaluate if your code it's
> suitable to be integrated with Marmotta, legally and technically.
>
> I think that could work. Before May 19, you still have some weeks to play
> with this environment, get used with Marmotta, and ask us any other
> question.
>
> Good luck!
>
> Cheers,
>
>
> [1] https://github.com/apache/marmotta
> [2] http://marmotta.apache.org/development
> [3] https://issues.apache.org/jira/browse/MARMOTTA-444
> [4] https://help.github.com/articles/syncing-a-fork
>
>
> --
> Sergio Fernández
> Senior Researcher
> Knowledge and Media Technologies
> Salzburg Research Forschungsgesellschaft mbH
> Jakob-Haringer-Straße 5/3 | 5020 Salzburg, Austria
> T: +43 662 2288 318 | M: +43 660 2747 925
> sergio.fernandez@salzburgresearch.at
> http://www.salzburgresearch.at

Re: [GSoC] dev period

Posted by Sergio Fernández <se...@salzburgresearch.at>.
Hi Qihong Lin,

On 20/06/14 11:51, Qihong Lin wrote:
> The wiki is very helpful. Thanks!
> I'll code following the restrictions. I think the best way to make it,
> is to study LdpServiceImpl and provide the corresponding identical
> methods for LdpServiceSPARQLImpl, because LdpServiceImpl is supposed
> to be strictly stick to the restrictions, isn't it?
>
> I just made 2 commits [1] of the methods of addResource() and
> deleteResource(), with the unit tests [2]. As is promised in the
> project plan, you can assess both the reading and writing capabilities
> of LDP-RS in the mid-term evaluation.
>
> Until the mid-term evaluation, I think things are going well at my
> side. I'll complete the rest of the implementations of the methods. I
> appreciate your help very much.

This week I'll take a closer code to your work for the mid-term 
evaluation, and I'll come back to you with more concrete details. But I 
think the project is going in the right direction.

Please, take into account that the official LDP Test Suite has 
significantly evolved in the last week, and it can be a very useful 
resource for you:

   http://w3c.github.io/ldp-testsuite

Cheers,

-- 
Sergio Fernández
Senior Researcher
Knowledge and Media Technologies
Salzburg Research Forschungsgesellschaft mbH
Jakob-Haringer-Straße 5/3 | 5020 Salzburg, Austria
T: +43 662 2288 318 | M: +43 660 2747 925
sergio.fernandez@salzburgresearch.at
http://www.salzburgresearch.at

Re: [GSoC] dev period

Posted by Qihong Lin <co...@gmail.com>.
Hi Sergio,

The wiki is very helpful. Thanks!
I'll code following the restrictions. I think the best way to make it,
is to study LdpServiceImpl and provide the corresponding identical
methods for LdpServiceSPARQLImpl, because LdpServiceImpl is supposed
to be strictly stick to the restrictions, isn't it?

I just made 2 commits [1] of the methods of addResource() and
deleteResource(), with the unit tests [2]. As is promised in the
project plan, you can assess both the reading and writing capabilities
of LDP-RS in the mid-term evaluation.

Until the mid-term evaluation, I think things are going well at my
side. I'll complete the rest of the implementations of the methods. I
appreciate your help very much.

Cheers,
Qihong Lin

[1] https://github.com/confidencesun/marmotta/commits/MARMOTTA-444
[2] https://github.com/confidencesun/marmotta/blob/926ae5de17d8c414184c0051f688101adf17003e/platform/marmotta-ldp/src/test/java/org/apache/marmotta/platform/ldp/testsuite/LdpServiceSPARQLImplTest.java

On Wed, Jun 11, 2014 at 6:50 AM, Sergio Fernández <wi...@apache.org> wrote:
> Dear Qihong Lin,
>
> apologize for the late reply.
>
>
> On 10/06/14 13:38, Qihong Lin wrote:
>>
>> Dear Sergio,
>>
>> I just figured out the reason of the problem 1). The bean.xml was not
>> copied into the building output folder, although was in the source
>> folder. I fixed it in eclipse. Everything works well now.
>
>
> Great, so the issue was actually in your IDE. Please, verify it does not
> appear on a regular build environment (raw maven).
>
>
>> Could you please just help me with the problem 2)? Thanks a lot!
>
>
> Remember that the scope of your project is restricted to the internals of
> Marmotta. All related with HTTP (headers and so on) are handled by the web
> service, where any of the two service implementations can be plug-in.
>
> For the second part of your question, that's an internal decision of
> Marmotta. The storage layer is out of the scope of the LDP spec. More
> precisely, LDP Marmotta storage is implemented by:
>
> * Using <http://www.w3.org/ns/ldp#> as "management" context, where store
> some management data
> * Internally every LDP-R will be stored in its own context
>
> Further details about our implementation restrictions are available from the
> wiki:
>
> http://wiki.apache.org/marmotta/LDPImplementationReport#Implementation_Restrictions
>
> Thanks for binging here that questions. Finding out those details means that
> you are in the right path for developing your project.
>
> Cheers,
>
>
> --
> Sergio Fernández
> Partner Technology Manager
> Redlink GmbH
> m: +43 660 2747 925
> e: sergio.fernandez@redlink.co
> w: http://redlink.co

Re: [GSoC] dev period

Posted by Sergio Fernández <wi...@apache.org>.
Dear Qihong Lin,

apologize for the late reply.

On 10/06/14 13:38, Qihong Lin wrote:
> Dear Sergio,
>
> I just figured out the reason of the problem 1). The bean.xml was not
> copied into the building output folder, although was in the source
> folder. I fixed it in eclipse. Everything works well now.

Great, so the issue was actually in your IDE. Please, verify it does not 
appear on a regular build environment (raw maven).

> Could you please just help me with the problem 2)? Thanks a lot!

Remember that the scope of your project is restricted to the internals 
of Marmotta. All related with HTTP (headers and so on) are handled by 
the web service, where any of the two service implementations can be 
plug-in.

For the second part of your question, that's an internal decision of 
Marmotta. The storage layer is out of the scope of the LDP spec. More 
precisely, LDP Marmotta storage is implemented by:

* Using <http://www.w3.org/ns/ldp#> as "management" context, where store 
some management data
* Internally every LDP-R will be stored in its own context

Further details about our implementation restrictions are available from 
the wiki:

http://wiki.apache.org/marmotta/LDPImplementationReport#Implementation_Restrictions

Thanks for binging here that questions. Finding out those details means 
that you are in the right path for developing your project.

Cheers,


-- 
Sergio Fernández
Partner Technology Manager
Redlink GmbH
m: +43 660 2747 925
e: sergio.fernandez@redlink.co
w: http://redlink.co

Re: [GSoC] dev period

Posted by Qihong Lin <co...@gmail.com>.
Dear Sergio,

I just figured out the reason of the problem 1). The bean.xml was not
copied into the building output folder, although was in the source
folder. I fixed it in eclipse. Everything works well now.

Could you please just help me with the problem 2)? Thanks a lot!

Yours,
Qihong Lin

On Tue, Jun 3, 2014 at 8:46 PM, Qihong Lin <co...@gmail.com> wrote:
> Dear Sergio,
>
> I try to fix the problems you commented. The code have been just committed [1].
>
> But there're some further issues to discuss:
>
> 1) EmbeddedMarmotta
> I change the test case [2] to use EmbeddedMarmotta. The bean.xml file
> is added at "src\test\resources\META-INF". But it throws
> "DeploymentException: WELD-001408" (see Apendix (1): stack trace for
> running LdpServiceSPARQLImplTest). In addition , EmbeddedMarmottaTest
> in marmotta-core also throws "UnsatisfiedResolutionException:
> WELD-001308" at my side (Eclipse+egit+m2e, see Appendix (2) ). Does
> EmbeddedMarmotta itself have some problems? Or am I wrong for any
> configuration mistakes of weld CDI? Finally, I have to restore the
> code to the ugly "new LdpServiceSPARQLImpl()" approach for testing.
>
> 2) RDF resource VS. LDP-RS
> I read the W3C LDP documentation[3]. There're some rules for LDP-RS.
> But it seems that most of the rules are out of the scopes of my SPARQL
> implementation work. For example, the rules like "HTTP Link header"
> and "HTTP Request-URI" for LDP-RS are not concerned in the level of my
> work. Is that correct?
> I try to make the equivalent method for LdpServiceImpl.exists(), which
> has only one sentence:
> "return connection.hasStatement(resource, null, null, true, ldpContext);"
> It uses "ldpContext" pointing to "http://www.w3.org/ns/ldp#", which is
> a graph name in the triplestore. Does it mean all of the LDP-RSs must
> be in the graph of "http://www.w3.org/ns/ldp#"? I don't see this
> request in the W3C LDP documentation[3]. What's your opinion?
> It uses "true" for the 4th parameter of connection.hasStatement()
> method, which includes inferred ones during querying. But I see this
> in the W3C LDP documenation [3]:
> "4.3.1.10 LDP servers must not require LDP clients to implement
> inferencing in order to recognize the subset of content defined by LDP
> ... The practical implication is that all content defined by LDP must
> be explicitly represented, unless noted otherwise within this
> document."
> Therefore, shall we change it to "false" to avoid inferred triples?
> Further more, should I care about SPARQL Entailment Regimes [4]? No?
>
> Best regards,
> Qihong Lin
>
>
> [1] https://github.com/confidencesun/marmotta/commit/d8e8048931de8a5f92c90ebf6a728822a2d3ed74
> [2] https://github.com/confidencesun/marmotta/blob/d8e8048931de8a5f92c90ebf6a728822a2d3ed74/platform/marmotta-ldp/src/test/java/org/apache/marmotta/platform/ldp/testsuite/LdpServiceSPARQLImplTest.java
> [3] http://www.w3.org/TR/ldp/#ldprs
> [4] http://www.w3.org/TR/sparql11-entailment/
>
> Appendix (1): stack trace for running LdpServiceSPARQLImplTest
> org.jboss.weld.exceptions.DeploymentException: Exception List with 4 exceptions:
> Exception 0 :
> org.jboss.weld.exceptions.DeploymentException: WELD-001408:
> Unsatisfied dependencies for type ConfigurationService with qualifiers
> @Default
>   at injection point [BackedAnnotatedField] @Inject protected
> org.apache.marmotta.platform.core.logging.BaseLoggingModule.configurationService
>   at org.apache.marmotta.platform.core.logging.BaseLoggingModule.configurationService(BaseLoggingModule.java:0)
>
> at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:368)
> at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:289)
> at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:135)
> at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:166)
> at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:514)
> at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:68)
> at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:66)
> at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:60)
> at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:53)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:722)
> Exception 0 :
> org.jboss.weld.exceptions.DeploymentException: WELD-001408:
> Unsatisfied dependencies for type ConfigurationService with qualifiers
> @Default
>   at injection point [BackedAnnotatedField] @Inject private
> org.apache.marmotta.platform.ldp.services.LdpServiceImpl.configurationService
>   at org.apache.marmotta.platform.ldp.services.LdpServiceImpl.configurationService(LdpServiceImpl.java:0)
>
> at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:368)
> at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:289)
> at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:135)
> at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:166)
> at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:514)
> at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:68)
> at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:66)
> at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:60)
> at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:53)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:722)
> Exception 0 :
> org.jboss.weld.exceptions.DeploymentException: WELD-001408:
> Unsatisfied dependencies for type ConfigurationService with qualifiers
> @Default
>   at injection point [BackedAnnotatedField] @Inject private
> org.apache.marmotta.platform.ldp.webservices.LdpWebService.configurationService
>   at org.apache.marmotta.platform.ldp.webservices.LdpWebService.configurationService(LdpWebService.java:0)
>
> at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:368)
> at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:289)
> at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:135)
> at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:166)
> at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:514)
> at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:68)
> at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:66)
> at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:60)
> at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:53)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:722)
> Exception 0 :
> org.jboss.weld.exceptions.DeploymentException: WELD-001408:
> Unsatisfied dependencies for type ConfigurationService with qualifiers
> @Default
>   at injection point [BackedAnnotatedField] @Inject private
> org.apache.marmotta.platform.ldp.services.LdpBinaryStoreServiceImpl.configurationService
>   at org.apache.marmotta.platform.ldp.services.LdpBinaryStoreServiceImpl.configurationService(LdpBinaryStoreServiceImpl.java:0)
>
> at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:368)
> at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:289)
> at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:135)
> at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:166)
> at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:514)
> at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:68)
> at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:66)
> at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:60)
> at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:53)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:722)
>
> at org.jboss.weld.bootstrap.ConcurrentValidator.validateBeans(ConcurrentValidator.java:76)
> at org.jboss.weld.bootstrap.Validator.validateDeployment(Validator.java:475)
> at org.jboss.weld.bootstrap.WeldStartup.validateBeans(WeldStartup.java:392)
> at org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:85)
> at org.jboss.weld.bootstrap.api.helpers.ForwardingBootstrap.validateBeans(ForwardingBootstrap.java:75)
> at org.jboss.weld.environment.se.Weld.initialize(Weld.java:144)
> at org.apache.marmotta.platform.core.test.base.AbstractMarmotta.<init>(AbstractMarmotta.java:66)
> at org.apache.marmotta.platform.core.test.base.EmbeddedMarmotta.<init>(EmbeddedMarmotta.java:35)
> at org.apache.marmotta.platform.ldp.testsuite.LdpServiceSPARQLImplTest.before(LdpServiceSPARQLImplTest.java:61)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
> at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
>
> Appendix (2): stack trace for running EmbeddedMarmottaTest
> org.jboss.weld.exceptions.UnsatisfiedResolutionException: WELD-001308:
> Unable to resolve any beans for Types: [class
> org.apache.marmotta.platform.core.startup.MarmottaStartupService];
> Bindings: [QualifierInstance{annotationClass=interface
> javax.enterprise.inject.Any, values={}, hashCode=1250708224}]
> at org.jboss.weld.manager.BeanManagerImpl.getBean(BeanManagerImpl.java:815)
> at org.jboss.weld.bean.builtin.InstanceImpl.get(InstanceImpl.java:75)
> at org.apache.marmotta.platform.core.test.base.AbstractMarmotta.getService(AbstractMarmotta.java:92)
> at org.apache.marmotta.platform.core.test.base.AbstractMarmotta.<init>(AbstractMarmotta.java:88)
> at org.apache.marmotta.platform.core.test.base.EmbeddedMarmotta.<init>(EmbeddedMarmotta.java:35)
> at org.apache.marmotta.platform.core.test.embedded.EmbeddedMarmottaTest.testMarmottaStartup(EmbeddedMarmottaTest.java:34)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
> at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
>
> On Mon, May 26, 2014 at 3:57 PM, Sergio Fernández <wi...@apache.org> wrote:
>> Hi,
>>
>> On 24/05/14 05:02, Qihong Lin wrote:
>>>
>>> I've completed the code of LdpServiceSPARQLImpl.exist() for RDF
>>> resource. The unit test has been made as well.
>>> Please check my last 2 commits:
>>> https://github.com/confidencesun/marmotta/commits/MARMOTTA-444
>>
>>
>> Great. I reviewed and commented directly there.
>>
>>> However, the unit test seems to be ugly. You can see in
>>> LdpServiceSPARQLImplTest.testResourceExist() that I directly new the
>>> object of LdpServiceSPARQLImpl. Is there other more elegant way to
>>> test LdpServiceSPARQLImpl?
>>> Also, I find that LdpServiceSPARQLImpl uses LdpBinaryStoreService,
>>> ConfigurationService and ldpContext. How can I make the unit test by
>>> injecting them into LdpServiceSPARQLImpl?
>>
>>
>> You can get services from the EmbeddedMarmotta, see this example:
>>
>> https://github.com/confidencesun/marmotta/blob/MARMOTTA-444/platform/marmotta-core/src/test/java/org/apache/marmotta/platform/core/test/prefix/PrefixServiceTest.java#L39
>>
>> But for preventing random behaviors, since now you have two implementations
>> of the LdpService, you have to take a look how to have alternatives with CDI
>> and get the right one:
>>
>> http://docs.jboss.org/weld/reference/latest/en-US/html_single/#alternatives
>>
>> Cheers,
>>
>> --
>> Sergio Fernández
>> Senior Researcher
>> Knowledge and Media Technologies
>> Salzburg Research Forschungsgesellschaft mbH
>> Jakob-Haringer-Straße 5/3 | 5020 Salzburg, Austria
>> T: +43 662 2288 318 | M: +43 660 2747 925
>> sergio.fernandez@salzburgresearch.at
>> http://www.salzburgresearch.at

Re: [GSoC] dev period

Posted by Qihong Lin <co...@gmail.com>.
Dear Sergio,

I try to fix the problems you commented. The code have been just committed [1].

But there're some further issues to discuss:

1) EmbeddedMarmotta
I change the test case [2] to use EmbeddedMarmotta. The bean.xml file
is added at "src\test\resources\META-INF". But it throws
"DeploymentException: WELD-001408" (see Apendix (1): stack trace for
running LdpServiceSPARQLImplTest). In addition , EmbeddedMarmottaTest
in marmotta-core also throws "UnsatisfiedResolutionException:
WELD-001308" at my side (Eclipse+egit+m2e, see Appendix (2) ). Does
EmbeddedMarmotta itself have some problems? Or am I wrong for any
configuration mistakes of weld CDI? Finally, I have to restore the
code to the ugly "new LdpServiceSPARQLImpl()" approach for testing.

2) RDF resource VS. LDP-RS
I read the W3C LDP documentation[3]. There're some rules for LDP-RS.
But it seems that most of the rules are out of the scopes of my SPARQL
implementation work. For example, the rules like "HTTP Link header"
and "HTTP Request-URI" for LDP-RS are not concerned in the level of my
work. Is that correct?
I try to make the equivalent method for LdpServiceImpl.exists(), which
has only one sentence:
"return connection.hasStatement(resource, null, null, true, ldpContext);"
It uses "ldpContext" pointing to "http://www.w3.org/ns/ldp#", which is
a graph name in the triplestore. Does it mean all of the LDP-RSs must
be in the graph of "http://www.w3.org/ns/ldp#"? I don't see this
request in the W3C LDP documentation[3]. What's your opinion?
It uses "true" for the 4th parameter of connection.hasStatement()
method, which includes inferred ones during querying. But I see this
in the W3C LDP documenation [3]:
"4.3.1.10 LDP servers must not require LDP clients to implement
inferencing in order to recognize the subset of content defined by LDP
... The practical implication is that all content defined by LDP must
be explicitly represented, unless noted otherwise within this
document."
Therefore, shall we change it to "false" to avoid inferred triples?
Further more, should I care about SPARQL Entailment Regimes [4]? No?

Best regards,
Qihong Lin


[1] https://github.com/confidencesun/marmotta/commit/d8e8048931de8a5f92c90ebf6a728822a2d3ed74
[2] https://github.com/confidencesun/marmotta/blob/d8e8048931de8a5f92c90ebf6a728822a2d3ed74/platform/marmotta-ldp/src/test/java/org/apache/marmotta/platform/ldp/testsuite/LdpServiceSPARQLImplTest.java
[3] http://www.w3.org/TR/ldp/#ldprs
[4] http://www.w3.org/TR/sparql11-entailment/

Appendix (1): stack trace for running LdpServiceSPARQLImplTest
org.jboss.weld.exceptions.DeploymentException: Exception List with 4 exceptions:
Exception 0 :
org.jboss.weld.exceptions.DeploymentException: WELD-001408:
Unsatisfied dependencies for type ConfigurationService with qualifiers
@Default
  at injection point [BackedAnnotatedField] @Inject protected
org.apache.marmotta.platform.core.logging.BaseLoggingModule.configurationService
  at org.apache.marmotta.platform.core.logging.BaseLoggingModule.configurationService(BaseLoggingModule.java:0)

at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:368)
at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:289)
at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:135)
at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:166)
at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:514)
at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:68)
at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:66)
at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:60)
at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:53)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:722)
Exception 0 :
org.jboss.weld.exceptions.DeploymentException: WELD-001408:
Unsatisfied dependencies for type ConfigurationService with qualifiers
@Default
  at injection point [BackedAnnotatedField] @Inject private
org.apache.marmotta.platform.ldp.services.LdpServiceImpl.configurationService
  at org.apache.marmotta.platform.ldp.services.LdpServiceImpl.configurationService(LdpServiceImpl.java:0)

at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:368)
at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:289)
at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:135)
at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:166)
at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:514)
at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:68)
at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:66)
at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:60)
at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:53)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:722)
Exception 0 :
org.jboss.weld.exceptions.DeploymentException: WELD-001408:
Unsatisfied dependencies for type ConfigurationService with qualifiers
@Default
  at injection point [BackedAnnotatedField] @Inject private
org.apache.marmotta.platform.ldp.webservices.LdpWebService.configurationService
  at org.apache.marmotta.platform.ldp.webservices.LdpWebService.configurationService(LdpWebService.java:0)

at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:368)
at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:289)
at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:135)
at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:166)
at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:514)
at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:68)
at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:66)
at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:60)
at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:53)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:722)
Exception 0 :
org.jboss.weld.exceptions.DeploymentException: WELD-001408:
Unsatisfied dependencies for type ConfigurationService with qualifiers
@Default
  at injection point [BackedAnnotatedField] @Inject private
org.apache.marmotta.platform.ldp.services.LdpBinaryStoreServiceImpl.configurationService
  at org.apache.marmotta.platform.ldp.services.LdpBinaryStoreServiceImpl.configurationService(LdpBinaryStoreServiceImpl.java:0)

at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:368)
at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:289)
at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:135)
at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:166)
at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:514)
at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:68)
at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:66)
at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:60)
at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:53)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:722)

at org.jboss.weld.bootstrap.ConcurrentValidator.validateBeans(ConcurrentValidator.java:76)
at org.jboss.weld.bootstrap.Validator.validateDeployment(Validator.java:475)
at org.jboss.weld.bootstrap.WeldStartup.validateBeans(WeldStartup.java:392)
at org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:85)
at org.jboss.weld.bootstrap.api.helpers.ForwardingBootstrap.validateBeans(ForwardingBootstrap.java:75)
at org.jboss.weld.environment.se.Weld.initialize(Weld.java:144)
at org.apache.marmotta.platform.core.test.base.AbstractMarmotta.<init>(AbstractMarmotta.java:66)
at org.apache.marmotta.platform.core.test.base.EmbeddedMarmotta.<init>(EmbeddedMarmotta.java:35)
at org.apache.marmotta.platform.ldp.testsuite.LdpServiceSPARQLImplTest.before(LdpServiceSPARQLImplTest.java:61)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)

Appendix (2): stack trace for running EmbeddedMarmottaTest
org.jboss.weld.exceptions.UnsatisfiedResolutionException: WELD-001308:
Unable to resolve any beans for Types: [class
org.apache.marmotta.platform.core.startup.MarmottaStartupService];
Bindings: [QualifierInstance{annotationClass=interface
javax.enterprise.inject.Any, values={}, hashCode=1250708224}]
at org.jboss.weld.manager.BeanManagerImpl.getBean(BeanManagerImpl.java:815)
at org.jboss.weld.bean.builtin.InstanceImpl.get(InstanceImpl.java:75)
at org.apache.marmotta.platform.core.test.base.AbstractMarmotta.getService(AbstractMarmotta.java:92)
at org.apache.marmotta.platform.core.test.base.AbstractMarmotta.<init>(AbstractMarmotta.java:88)
at org.apache.marmotta.platform.core.test.base.EmbeddedMarmotta.<init>(EmbeddedMarmotta.java:35)
at org.apache.marmotta.platform.core.test.embedded.EmbeddedMarmottaTest.testMarmottaStartup(EmbeddedMarmottaTest.java:34)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)

On Mon, May 26, 2014 at 3:57 PM, Sergio Fernández <wi...@apache.org> wrote:
> Hi,
>
> On 24/05/14 05:02, Qihong Lin wrote:
>>
>> I've completed the code of LdpServiceSPARQLImpl.exist() for RDF
>> resource. The unit test has been made as well.
>> Please check my last 2 commits:
>> https://github.com/confidencesun/marmotta/commits/MARMOTTA-444
>
>
> Great. I reviewed and commented directly there.
>
>> However, the unit test seems to be ugly. You can see in
>> LdpServiceSPARQLImplTest.testResourceExist() that I directly new the
>> object of LdpServiceSPARQLImpl. Is there other more elegant way to
>> test LdpServiceSPARQLImpl?
>> Also, I find that LdpServiceSPARQLImpl uses LdpBinaryStoreService,
>> ConfigurationService and ldpContext. How can I make the unit test by
>> injecting them into LdpServiceSPARQLImpl?
>
>
> You can get services from the EmbeddedMarmotta, see this example:
>
> https://github.com/confidencesun/marmotta/blob/MARMOTTA-444/platform/marmotta-core/src/test/java/org/apache/marmotta/platform/core/test/prefix/PrefixServiceTest.java#L39
>
> But for preventing random behaviors, since now you have two implementations
> of the LdpService, you have to take a look how to have alternatives with CDI
> and get the right one:
>
> http://docs.jboss.org/weld/reference/latest/en-US/html_single/#alternatives
>
> Cheers,
>
> --
> Sergio Fernández
> Senior Researcher
> Knowledge and Media Technologies
> Salzburg Research Forschungsgesellschaft mbH
> Jakob-Haringer-Straße 5/3 | 5020 Salzburg, Austria
> T: +43 662 2288 318 | M: +43 660 2747 925
> sergio.fernandez@salzburgresearch.at
> http://www.salzburgresearch.at

Re: [GSoC] dev period

Posted by Sergio Fernández <wi...@apache.org>.
Hi,

On 24/05/14 05:02, Qihong Lin wrote:
> I've completed the code of LdpServiceSPARQLImpl.exist() for RDF
> resource. The unit test has been made as well.
> Please check my last 2 commits:
> https://github.com/confidencesun/marmotta/commits/MARMOTTA-444

Great. I reviewed and commented directly there.

> However, the unit test seems to be ugly. You can see in
> LdpServiceSPARQLImplTest.testResourceExist() that I directly new the
> object of LdpServiceSPARQLImpl. Is there other more elegant way to
> test LdpServiceSPARQLImpl?
> Also, I find that LdpServiceSPARQLImpl uses LdpBinaryStoreService,
> ConfigurationService and ldpContext. How can I make the unit test by
> injecting them into LdpServiceSPARQLImpl?

You can get services from the EmbeddedMarmotta, see this example:

https://github.com/confidencesun/marmotta/blob/MARMOTTA-444/platform/marmotta-core/src/test/java/org/apache/marmotta/platform/core/test/prefix/PrefixServiceTest.java#L39

But for preventing random behaviors, since now you have two 
implementations of the LdpService, you have to take a look how to have 
alternatives with CDI and get the right one:

http://docs.jboss.org/weld/reference/latest/en-US/html_single/#alternatives

Cheers,

-- 
Sergio Fernández
Senior Researcher
Knowledge and Media Technologies
Salzburg Research Forschungsgesellschaft mbH
Jakob-Haringer-Straße 5/3 | 5020 Salzburg, Austria
T: +43 662 2288 318 | M: +43 660 2747 925
sergio.fernandez@salzburgresearch.at
http://www.salzburgresearch.at

Re: [GSoC] community bonding period

Posted by Qihong Lin <co...@gmail.com>.
Dear Sergio,

I've completed the code of LdpServiceSPARQLImpl.exist() for RDF
resource. The unit test has been made as well.
Please check my last 2 commits:
https://github.com/confidencesun/marmotta/commits/MARMOTTA-444

However, the unit test seems to be ugly. You can see in
LdpServiceSPARQLImplTest.testResourceExist() that I directly new the
object of LdpServiceSPARQLImpl. Is there other more elegant way to
test LdpServiceSPARQLImpl?
Also, I find that LdpServiceSPARQLImpl uses LdpBinaryStoreService,
ConfigurationService and ldpContext. How can I make the unit test by
injecting them into LdpServiceSPARQLImpl?

Best regards,
Qihong Lin


On Tue, May 20, 2014 at 4:47 PM, Sergio Fernández <wi...@apache.org> wrote:
> Hi Qihong,
>
>
> On 20/05/14 10:30, Qihong Lin wrote:
>>
>> I've already set up the development environment. I'm ready to begin
>> coding in that fork.
>
>
> Great.
>
>
>> The test suite and the test cases were removed from the code
>> repository on 5th May. Could you please tell me why? Any problems with
>> the tests? Can I reuse the removed test cases in my fork to ensure the
>> expected behaviors of my code?
>
>
> The work on the test suite has been moved to github in collaboration with
> other member of the LDP WG:
>
>   https://github.com/w3c/ldp-testsuite
>
> I've closed MARMOTTA-438 accordingly.
>
> Anyway, it still needs to be stabilized until it reports proper results. In
> the meantime you can use our custom unit tests, that's more than enough for
> the earlier phases.
>
>
> Cheers,
>
> --
> Sergio Fernández
> Senior Researcher
> Knowledge and Media Technologies
> Salzburg Research Forschungsgesellschaft mbH
> Jakob-Haringer-Straße 5/3 | 5020 Salzburg, Austria
> T: +43 662 2288 318 | M: +43 660 2747 925
> sergio.fernandez@salzburgresearch.at
> http://www.salzburgresearch.at

Re: [GSoC] community bonding period

Posted by Sergio Fernández <wi...@apache.org>.
Hi Qihong,

On 20/05/14 10:30, Qihong Lin wrote:
> I've already set up the development environment. I'm ready to begin
> coding in that fork.

Great.

> The test suite and the test cases were removed from the code
> repository on 5th May. Could you please tell me why? Any problems with
> the tests? Can I reuse the removed test cases in my fork to ensure the
> expected behaviors of my code?

The work on the test suite has been moved to github in collaboration 
with other member of the LDP WG:

   https://github.com/w3c/ldp-testsuite

I've closed MARMOTTA-438 accordingly.

Anyway, it still needs to be stabilized until it reports proper results. 
In the meantime you can use our custom unit tests, that's more than 
enough for the earlier phases.

Cheers,

-- 
Sergio Fernández
Senior Researcher
Knowledge and Media Technologies
Salzburg Research Forschungsgesellschaft mbH
Jakob-Haringer-Straße 5/3 | 5020 Salzburg, Austria
T: +43 662 2288 318 | M: +43 660 2747 925
sergio.fernandez@salzburgresearch.at
http://www.salzburgresearch.at

Re: [GSoC] community bonding period

Posted by Qihong Lin <co...@gmail.com>.
Dear Sergio,

I've already set up the development environment. I'm ready to begin
coding in that fork.

The test suite and the test cases were removed from the code
repository on 5th May. Could you please tell me why? Any problems with
the tests? Can I reuse the removed test cases in my fork to ensure the
expected behaviors of my code?

Best regards,
Qihong Lin


On Mon, May 19, 2014 at 9:01 PM, Sergio Fernández <wi...@apache.org> wrote:
> Hi,
>
> according to the official timeline:
>
> http://www.google-melange.com/gsoc/events/google/gsoc2014
>
> today students begin coding for their Google Summer of Code projects;
> Google begins issuing initial student payments provided tax forms are on
> file and students are in good standing with their communities.
>
> I've saw some activity at the MARMOTTA-444 fork at github:
>
> https://github.com/confidencesun/marmotta/commits/MARMOTTA-444
>
> Please Qihong Lin, let me know if you have any question to actually start to
> work. I think we can privately talk for some internal details of your
> project (you can find me at skype as sergio.fernandez.lopez), but you should
> periodically report your progress here, probably according the project plan
> submitted with your proposal:
>
> http://www.google-melange.com/gsoc/proposal/review/org/google/gsoc2014/confidence_sun/5629499534213120
>
> Good luck!
>
> Cheers,
>
>
> --
> Sergio Fernández
> Senior Researcher
> Knowledge and Media Technologies
> Salzburg Research Forschungsgesellschaft mbH
> Jakob-Haringer-Straße 5/3 | 5020 Salzburg, Austria
> T: +43 662 2288 318 | M: +43 660 2747 925
> sergio.fernandez@salzburgresearch.at
> http://www.salzburgresearch.at

Re: [GSoC] community bonding period

Posted by Sergio Fernández <wi...@apache.org>.
Hi,

according to the official timeline:

http://www.google-melange.com/gsoc/events/google/gsoc2014

today students begin coding for their Google Summer of Code projects;
Google begins issuing initial student payments provided tax forms are on 
file and students are in good standing with their communities.

I've saw some activity at the MARMOTTA-444 fork at github:

https://github.com/confidencesun/marmotta/commits/MARMOTTA-444

Please Qihong Lin, let me know if you have any question to actually 
start to work. I think we can privately talk for some internal details 
of your project (you can find me at skype as sergio.fernandez.lopez), 
but you should periodically report your progress here, probably 
according the project plan submitted with your proposal:

http://www.google-melange.com/gsoc/proposal/review/org/google/gsoc2014/confidence_sun/5629499534213120 


Good luck!

Cheers,

-- 
Sergio Fernández
Senior Researcher
Knowledge and Media Technologies
Salzburg Research Forschungsgesellschaft mbH
Jakob-Haringer-Straße 5/3 | 5020 Salzburg, Austria
T: +43 662 2288 318 | M: +43 660 2747 925
sergio.fernandez@salzburgresearch.at
http://www.salzburgresearch.at

Re: [GSoC] community bonding period

Posted by Sergio Fernández <wi...@apache.org>.
On 02/05/14 16:18, Qihong Lin wrote:
> Could you please make any modification to the upstream? I'd like to
> test the "pull" synchronization.

You have new changes in upstream:

https://git-wip-us.apache.org/repos/asf?p=marmotta.git;a=log;h=refs/heads/develop

Try to get updated your fork to play with that.

-- 
Sergio Fernández
Senior Researcher
Knowledge and Media Technologies
Salzburg Research Forschungsgesellschaft mbH
Jakob-Haringer-Straße 5/3 | 5020 Salzburg, Austria
T: +43 662 2288 318 | M: +43 660 2747 925
sergio.fernandez@salzburgresearch.at
http://www.salzburgresearch.at

Re: [GSoC] community bonding period

Posted by Sergio Fernández <wi...@apache.org>.
Dear Qihong Lin,

First, one question, sorry if it sounds impolite, but it's always 
confusing for me: Qihong is your first name and Lin your family name, or 
the other way around? Better to clarify it asap ;-)

On 02/05/14 16:18, Qihong Lin wrote:
> I follow your instructions to complete these task, with some questions:
>
> 1) I fork the mirror as confidencesun/marmotta [1], while
> confidencesun is my github id.
> I add you in the "Collaborators" of this repository [1]. Is that the
> way you get the admin permissions?

Exactly that. Perfect. Thanks.

> 2) I create a branch of MARMOTTA-444 from develop

Looks good.

> I use eclipse (Juno), egit and m2e as the development tools to work it
> out. Do you the same toolkit?

Nomrally I use git form the command line, not so many time directly from 
the IDE (I use IntelliJ). But you are free to you those tools with which 
you feel more comfortable.

If you are not used to git, I'd recommend you to practice a bit. This is 
a great resource:

   https://try.github.io

> 3) I clone the repository [1] to the local git.
> I also try to import the local "marmotta-ldp" into eclipse as a maven
> project. But at the step of "Setup Maven plugin connectors", I get the
> error:
> ----
> No marketplace entries found to handle
> maven-download-plugin:1.1.0:wget in Eclipse.  Please see Help for more
> information.
> ----
> I choose to "resolve later", and pom of the project "marmotta-ldp"
> shows the error:
> ----
> Plugin execution not covered by lifecycle configuration:
> com.googlecode.maven-download-plugin:maven-download-plugin:1.1.0:wget
> (execution: download-ldp-test-cases, phase: process-test-resources)
> ----
> It seems the m2e connector of "maven-download-plugin" is not installed
> properly. I google for a long time, without successful solutions.
> Could you please help me out?

This is not so important, you do not need a completely integrated build 
lifecyle in Eclipse.

Besides that task is deprectaed with the new W3C LDP Test Suite. I'll 
removed it the upstream develop branch, so a good exercise to practice 
is update your fork.

> 4) I have to comment out the "maven-download-plugin" in the pom to
> make everything compiles in eclipse. The project of "marmotta-ldp" and
> its dependency projects look fine now in eclipse (see the attachment
> picture). I think, the project of "marmotta-ldp" is the place I'd play
> around, in this summer.

Correct.

> 5) I "push" the modification of 4) to the remote github branch of
> "MARMOTTA-444". It seems OK. I think this is the way to commit code :)

Looks good.

Thanks.

Cheers,

-- 
Sergio Fernández
Senior Researcher
Knowledge and Media Technologies
Salzburg Research Forschungsgesellschaft mbH
Jakob-Haringer-Straße 5/3 | 5020 Salzburg, Austria
T: +43 662 2288 318 | M: +43 660 2747 925
sergio.fernandez@salzburgresearch.at
http://www.salzburgresearch.at