[jira] [Commented] (CONNECTORS-1492) GSOC: Add support for Docker

[Chanuka Abeysinghe (JIRA)]

[ 
https://issues.apache.org/jira/browse/CONNECTORS-1492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16394396#comment-16394396
 ] 

Chanuka Abeysinghe commented on CONNECTORS-1492:


Hi [~piergiorgioluc...@gmail.com],

I am Chanuka Abeysinghe , a computer science undergraduate student at IIT, Sri 
Lanka. I would like contribute to this project as a GSOC student. I have good 
experience with java programming so I think this project is a good match for 
me. Currently I am building the project and following the documentation.

i will be very grateful if you can tell me the necessary steps contribute to 
the project.

Thank you,

Chanuka.  

> GSOC: Add support for Docker
> 
>
> Key: CONNECTORS-1492
> URL: https://issues.apache.org/jira/browse/CONNECTORS-1492
> Project: ManifoldCF
>  Issue Type: New Feature
>Reporter: Piergiorgio Lucidi
>Assignee: Piergiorgio Lucidi
>Priority: Major
>  Labels: devops, docker, gsoc2018
>   Original Estimate: 240h
>  Remaining Estimate: 240h
>
> This is a project idea for [Google Summer of 
> Code|https://summerofcode.withgoogle.com/] (GSOC).
> To discuss this or other ideas with your potential mentor from the Apache 
> ManifoldCF project, sign up and post to the dev@manifoldcf.apache.org list, 
> including "[GSOC]" in the subject. You may also comment on this Jira issue if 
> you have created an account. 
> We would like to adopt Docker to provide ready to use images with 
> preconfigured architecture stack for ManifoldCF. This will include ManifoldCF 
> itself but also the related database that can be MySQL, PostgreSQL and so on.
> This will help developers to work and put in production a complete ManifoldCF 
> installation.
> You will be involved in the development of the following tasks, you will 
> learn how to:
>  * Write Docker files
>  * Write Docker Compose files
>  * Implement unit tests
>  * Build all the integration tests
>  * Write the documentation for new component
> We have a complete documentation about ManifioldCF:
> [https://manifoldcf.apache.org/release/release-2.9.1/en_US/concepts.html]
> Take a look at our book to understand better the framework and how to extend 
> it in different ways:
> [https://github.com/DaddyWri/manifoldcfinaction/tree/master/pdfs]
>  
> Prospective GSOC mentor: 
> [piergior...@apache.org|mailto:piergior...@apache.org]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [GSOC] '18 - Add support for Docker - Abhishek Kapoor - TU Munich

[Abhishek Kapoor]

Hello Piergiorgio,

Greetings!

I wanted to inform you that I finished main parts of the ManifoldCF
Documentation and the Book which provided relevant information for the
Project. Also, I am done with my exams now so can devote much more time. I
will start drafting my proposal from today onwards.

*Questions:*
1. What should be the next steps from Apache side? Is there anything I need
to do before jumping into the proposal?
2. Is there anything else that may provide helpful information in preparing
the proposal?

Please let me know how to proceed forward and I will do accordingly.

*Best Regards*
Abhishek Kapoor
Mobile: +49-15143586760, +91-9873703731
Linkedin <https://de.linkedin.com/in/kapoorabhishek24>

"The important thing is not to stop questioning. Curiosity has its own
reason for existing." - Albert Einstein

On Fri, Feb 16, 2018 at 3:30 PM, Piergiorgio Lucidi <piergior...@apache.org>
wrote:

> Hi Abhishek,
>
> nice to meet you and thank you for your interest in participating in the
> Apache ManifoldCF project.
>
> What can I say?
> Welcome to the ManifoldCF Community :)
>
> It will be a pleasure to work with you and I think that you could bring a
> lot of value to the project, not only for your academic career but also for
> the next steps ;)
>
> Actually we have a previous request for working on this task that was
> arrived before yours:
> https://issues.apache.org/jira/browse/CONNECTORS-1492
>
> Could you please leave also a message on that issue?
> Then we can try to understand if we can enable both of you to work
> together on the same task or we could split the project in two separated
> tasks.
> I'll have to discuss this internally before giving you a confirmation that
> anyway will arrive only when you will apply officially starting from March.
>
> For chatting, no problem, you could join our public HipChat room at the
> following link:
> https://www.hipchat.com/gOSgu3lH8
>
> It is pretty new and we will publish it later on our new website.
> Thank you and welcome again in the community.
>
> Cheers,
> PJ
>
> 2018-02-15 19:35 GMT+01:00 Abhishek Kapoor <kapoorabhishe...@gmail.com>:
>
>> Hello Piergiorgio Lucidi,
>>
>> I am Abhishek Kapoor, currently pursuing my *Masters of Science -
>> Informatics *at *Technical University of Munich, Germany*. I am writing
>> to you to express my interest in the *Add support for Docker* project
>> offered by Apache Software Foundation under* GSOC ‘18*. I would like to
>> tell you that my research interest lies in the area of Distributed Systems,
>> Cloud Computing, Data Mining, Data Science, Networks, and Security.
>>
>> *Background Information:* I have a prior industrial experience of 2+
>> years. I have worked as a Site Reliability Engineer at Adobe for the
>> Marketing Cloud Product – Target. Few of my tasks were Product
>> Releases/Deployments, Automation (Fabric/CFEngine/Bash/Python), rectifying
>> issues in Production, Beta and Staging environment (JIRA), researching on
>> and implementing new technologies (Docker, Kubernetes) related to the
>> field. Also, I did few internships during my Bachelors and Masters, and I
>> worked on infrastructure-as-code and played around Technologies - AWS,
>> Docker, Kubernetes, Hadoop, Spark, Elasticsearch, Linux, Python, Raspberry
>> Pi, CI/CD (Jenkins, Puppet), etc. I like to read about new technologies and
>> the cutting-edge research that is going on related to my field.
>>
>> I am really excited about working on Add support for Docker project and I
>> have the required skills and background to execute a well-finished project.
>> I am very well experienced with Docker and containerized concepts and have
>> a strong understanding and working knowledge of Linux fundamentals. Also, I
>> have looked into the Tech Stack for ManifoldCF; I have worked with most of
>> the technologies in my past work experience.
>>
>> *Questions:*
>> 1. Guide me on how to start off. I am already going through the
>> documentation.
>> 2. Is there any IRC channel where I can collaborate with you and ask my
>> questions. I checked the list provided by Apache Software Foundation but
>> couldn't find the link for ManifoldCF (https://wiki.apache.org/gener
>> al/IRC).
>>
>> It will be an honor to contribute towards Apache manifoldCF project and I
>> am highly motivated to work on this project and start as soon as possible.
>> I don't have any commitments for next summer. I am almost done with my
>> masters and thus can work as many hours as I want.
>>
>> I am attaching my CV and transcript for your reference.
>> Looking forward to your response.
>>
>> *Yours sincerely*
>> Abhishek Kapoor
>> Mobile: +49-15143586760 <+49%201514%203586760>, +91-9873703731
>> <+91%2098737%2003731>
>> Linkedin <https://de.linkedin.com/in/kapoorabhishek24>
>>
>
>
>
> --
> Piergiorgio Lucidi
> https://www.open4dev.com
>

Re: GSOC 2018: MongoDB Output Connector

[Karl Wright]

Hi Irindu,

I'm the wrong person to ask this question of in any case, but I would like
to point out that your inline images did not make it through.

Karl

On Mon, Feb 26, 2018 at 11:07 PM, Irindu Nugawela 
wrote:

> Hi All,
> I was able to build ManifoldCF from command line using ant issuing the
> commands ant make core-deps , ant make deps, ant build test but the build
> fails when I try to build with Intelij Idea. Here are the steps I followed.
> I imported the build.xml with Ant Build tab and clicked on build phase and
> ran in also tried with All phase here is the error message I got
> [image: Inline images 1]
>
> I also tried with maven importing the root pom but the maven build also
> fails
>
> [image: Inline images 2]
>
> Please point me out what I am doing wrong here.
>
> On 25 February 2018 at 23:35, Irindu Nugawela 
> wrote:
>
>> Hi Karl,
>> Thank you very much for the quick reply, where can I find the particular
>> model, I think it is in XML format and I have to convert from that to BSON
>> format within my connector please correct me If I am wrong, and also please
>> answer this also, what are the activities or operations that the MongoDB
>> connector need to support apart from the regular document creation and
>> deletion operations?
>>
>> Sent from my iPhone
>>
>> > On Feb 25, 2018, at 7:54 PM, Karl Wright  wrote:
>> >
>> > Hi Irindu,
>> >
>> > Piergiorgio will answer your detailed questions -- however, I think he
>> is
>> > looking to extend the suite of connectors that can be used to allow
>> > ManifoldCF to synchronize documents between repositories.  That really
>> > means there will be both a repository connector and an output connector
>> for
>> > each "repository" we want to work with in this way.
>> >
>> > Please bear in mind that ManifoldCF is about documents and metadata, not
>> > general database.  There will necessarily be a model for document
>> > representation when you are writing a connector for a general database
>> that
>> > we would expect people to adhere to.  Piergiorgio can explain that in
>> more
>> > detail.
>> >
>> > Thanks,
>> > Karl
>> >
>> >
>> > On Sun, Feb 25, 2018 at 7:53 AM, Irindu Nugawela 
>> > wrote:
>> >
>> >> Hi All,
>> >> I am currently to working on the $subject.  I have some issues that I
>> need
>> >> to clarify.
>> >> First of all, why did we choose Mongo DB as an output target? My first
>> >> thought of the project was that it was about writing a repository
>> connector
>> >> for MongoDB because MongoDB is a database programme. ( I am aware of
>> its
>> >> NoSQL
>> >> architecture and its indexing capabilities ). But it is not a search
>> engine
>> >> per se.
>> >>
>> >> Then what are the expected operations other than document addition and
>> >> deletion? (what activities should be supported?)
>> >>
>> >> What capabilities of MongoDB you have already identified that you
>> expect to
>> >> be useful for us. (what capabilities of MongoDB you have identified as
>> >> useful That you've decided to write an Output connector for it.)
>> >>
>> >> I have been through the ManifoldCF Architecture with DaddyWri
>> >> /manifoldcfinaction Chapter1.
>> >>
>> >> --
>> >> Thanks and Regards,
>> >> Irindu Nugawela,
>> >> Computer Engineering  Undergraduate,
>> >> Faculty of Engineering University of Peradeniya
>> >>
>> >> > >> source=link_campaign=sig-email_content=webmail_term=icon>
>> >> Virus-free.
>> >> www.avast.com
>> >> > >> source=link_campaign=sig-email_content=webmail_term=link>
>> >> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>> >>
>>
>
>
>
> --
> Thanks and Regards,
> Irindu Nugawela,
> Computer Engineering  Undergraduate,
> Faculty of Engineering University of Peradeniya
>

Re: GSOC 2018: MongoDB Output Connector

[Irindu Nugawela]

Hi Karl, 
Thank you very much for the quick reply, where can I find the particular model, 
I think it is in XML format and I have to convert from that to BSON format 
within my connector please correct me If I am wrong, and also please answer 
this also, what are the activities or operations that the MongoDB connector 
need to support apart from the regular document creation and deletion 
operations?

Sent from my iPhone

> On Feb 25, 2018, at 7:54 PM, Karl Wright  wrote:
> 
> Hi Irindu,
> 
> Piergiorgio will answer your detailed questions -- however, I think he is
> looking to extend the suite of connectors that can be used to allow
> ManifoldCF to synchronize documents between repositories.  That really
> means there will be both a repository connector and an output connector for
> each "repository" we want to work with in this way.
> 
> Please bear in mind that ManifoldCF is about documents and metadata, not
> general database.  There will necessarily be a model for document
> representation when you are writing a connector for a general database that
> we would expect people to adhere to.  Piergiorgio can explain that in more
> detail.
> 
> Thanks,
> Karl
> 
> 
> On Sun, Feb 25, 2018 at 7:53 AM, Irindu Nugawela 
> wrote:
> 
>> Hi All,
>> I am currently to working on the $subject.  I have some issues that I need
>> to clarify.
>> First of all, why did we choose Mongo DB as an output target? My first
>> thought of the project was that it was about writing a repository connector
>> for MongoDB because MongoDB is a database programme. ( I am aware of its
>> NoSQL
>> architecture and its indexing capabilities ). But it is not a search engine
>> per se.
>> 
>> Then what are the expected operations other than document addition and
>> deletion? (what activities should be supported?)
>> 
>> What capabilities of MongoDB you have already identified that you expect to
>> be useful for us. (what capabilities of MongoDB you have identified as
>> useful That you've decided to write an Output connector for it.)
>> 
>> I have been through the ManifoldCF Architecture with DaddyWri
>> /manifoldcfinaction Chapter1.
>> 
>> --
>> Thanks and Regards,
>> Irindu Nugawela,
>> Computer Engineering  Undergraduate,
>> Faculty of Engineering University of Peradeniya
>> 
>> > source=link_campaign=sig-email_content=webmail_term=icon>
>> Virus-free.
>> www.avast.com
>> > source=link_campaign=sig-email_content=webmail_term=link>
>> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>> 

Re: GSOC 2018: MongoDB Output Connector

[Karl Wright]

Hi Irindu,

Piergiorgio will answer your detailed questions -- however, I think he is
looking to extend the suite of connectors that can be used to allow
ManifoldCF to synchronize documents between repositories.  That really
means there will be both a repository connector and an output connector for
each "repository" we want to work with in this way.

Please bear in mind that ManifoldCF is about documents and metadata, not
general database.  There will necessarily be a model for document
representation when you are writing a connector for a general database that
we would expect people to adhere to.  Piergiorgio can explain that in more
detail.

Thanks,
Karl


On Sun, Feb 25, 2018 at 7:53 AM, Irindu Nugawela 
wrote:

> Hi All,
> I am currently to working on the $subject.  I have some issues that I need
> to clarify.
> First of all, why did we choose Mongo DB as an output target? My first
> thought of the project was that it was about writing a repository connector
> for MongoDB because MongoDB is a database programme. ( I am aware of its
> NoSQL
> architecture and its indexing capabilities ). But it is not a search engine
> per se.
>
> Then what are the expected operations other than document addition and
> deletion? (what activities should be supported?)
>
> What capabilities of MongoDB you have already identified that you expect to
> be useful for us. (what capabilities of MongoDB you have identified as
> useful That you've decided to write an Output connector for it.)
>
> I have been through the ManifoldCF Architecture with DaddyWri
> /manifoldcfinaction Chapter1.
>
> --
> Thanks and Regards,
> Irindu Nugawela,
> Computer Engineering  Undergraduate,
> Faculty of Engineering University of Peradeniya
>
>  source=link_campaign=sig-email_content=webmail_term=icon>
> Virus-free.
> www.avast.com
>  source=link_campaign=sig-email_content=webmail_term=link>
> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>

GSOC 2018: MongoDB Output Connector

[Irindu Nugawela]

Hi All,
I am currently to working on the $subject.  I have some issues that I need
to clarify.
First of all, why did we choose Mongo DB as an output target? My first
thought of the project was that it was about writing a repository connector
for MongoDB because MongoDB is a database programme. ( I am aware of its NoSQL
architecture and its indexing capabilities ). But it is not a search engine
per se.

Then what are the expected operations other than document addition and
deletion? (what activities should be supported?)

What capabilities of MongoDB you have already identified that you expect to
be useful for us. (what capabilities of MongoDB you have identified as
useful That you've decided to write an Output connector for it.)

I have been through the ManifoldCF Architecture with DaddyWri
/manifoldcfinaction Chapter1.

-- 
Thanks and Regards,
Irindu Nugawela,
Computer Engineering  Undergraduate,
Faculty of Engineering University of Peradeniya


Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

[jira] [Comment Edited] (CONNECTORS-1490) GSOC: MongoDB Output Connector

[Irindu Nugawela (JIRA)]

[ 
https://issues.apache.org/jira/browse/CONNECTORS-1490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16372313#comment-16372313
 ] 

Irindu Nugawela edited comment on CONNECTORS-1490 at 2/22/18 2:03 AM:
--

Hi Piergiorgio, 

Following [URL 
|{color:#33}[http://manifoldcfinaction/svn/examples/edition_2_revised/output_connector_example/src/org/apache/manifoldcf/agents/output/docs4u/Docs4UOutputConnector.java]{color}]which
 is mentioned in Chapter 9 of the PDF is supposed to lead to the 
Docs4UOutputConnector.java seems to be not working can you please check.

I think it needs to be updated to 
[link|https://github.com/DaddyWri/manifoldcfinaction/blob/master/examples/output_connector_example/src/org/apache/manifoldcf/agents/output/docs4u/Docs4UOutputConnector.java]


was (Author: irindupera):
Hi Piergiorgio, 

Following [URL 
|{color:#33}http://manifoldcfinaction/svn/examples/edition_2_revised/output_connector_example/src/org/apache/manifoldcf/agents/output/docs4u/Docs4UOutputConnector.java{color}]which
 is mentioned in Chapter 9 of the PDF is supposed to lead to the 
Docs4UOutputConnector.java seems to be not working can you please check.

 

> GSOC: MongoDB Output Connector
> --
>
> Key: CONNECTORS-1490
> URL: https://issues.apache.org/jira/browse/CONNECTORS-1490
> Project: ManifoldCF
>  Issue Type: New Feature
>  Components: MongoDB Output Connector
>Reporter: Piergiorgio Lucidi
>Assignee: Piergiorgio Lucidi
>Priority: Major
>  Labels: MongoDB, gsoc2018, java, junit
>   Original Estimate: 480h
>  Remaining Estimate: 480h
>
> This is a project idea for [Google Summer of 
> Code|https://summerofcode.withgoogle.com/] (GSOC).
> To discuss this or other ideas with your potential mentor from the Apache 
> ManifoldCF project, sign up and post to the dev@manifoldcf.apache.org list, 
> including "[GSOC]" in the subject. You may also comment on this Jira issue if 
> you have created an account. 
> We would like to extend the Content Migration capabilities adding MongoDB / 
> GridFS as a new output connector for importing contents from one or more 
> repositories supported by ManifoldCF. In this way we will help developers on 
> migrating contents from different data sources on MongoDB.
> You will be involved in the development of the following tasks, you will 
> learn how to:
>  * Write the connector implementation
>  * Implement unit tests
>  * Build all the integration tests for testing the connector inside the 
> framework
>  * Write the documentation for this connector
> We have a complete documentation on how to implement an Output Connector:
> [https://manifoldcf.apache.org/release/release-2.9.1/en_US/writing-output-connectors.html]
> Take a look also at our book to understand better the framework and how to 
> implement connectors:
> [https://github.com/DaddyWri/manifoldcfinaction/tree/master/pdfs]
>  
> Prospective GSOC mentor: 
> [piergior...@apache.org|mailto:piergior...@apache.org]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CONNECTORS-1490) GSOC: MongoDB Output Connector

[Irindu Nugawela (JIRA)]

[ 
https://issues.apache.org/jira/browse/CONNECTORS-1490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16372313#comment-16372313
 ] 

Irindu Nugawela commented on CONNECTORS-1490:
-

Hi Piergiorgio, 

Following [URL 
|{color:#33}http://manifoldcfinaction/svn/examples/edition_2_revised/output_connector_example/src/org/apache/manifoldcf/agents/output/docs4u/Docs4UOutputConnector.java{color}]which
 is mentioned in Chapter 9 of the PDF is supposed to lead to the 
Docs4UOutputConnector.java seems to be not working can you please check.

 

> GSOC: MongoDB Output Connector
> --
>
> Key: CONNECTORS-1490
> URL: https://issues.apache.org/jira/browse/CONNECTORS-1490
> Project: ManifoldCF
>  Issue Type: New Feature
>  Components: MongoDB Output Connector
>Reporter: Piergiorgio Lucidi
>Assignee: Piergiorgio Lucidi
>Priority: Major
>  Labels: MongoDB, gsoc2018, java, junit
>   Original Estimate: 480h
>  Remaining Estimate: 480h
>
> This is a project idea for [Google Summer of 
> Code|https://summerofcode.withgoogle.com/] (GSOC).
> To discuss this or other ideas with your potential mentor from the Apache 
> ManifoldCF project, sign up and post to the dev@manifoldcf.apache.org list, 
> including "[GSOC]" in the subject. You may also comment on this Jira issue if 
> you have created an account. 
> We would like to extend the Content Migration capabilities adding MongoDB / 
> GridFS as a new output connector for importing contents from one or more 
> repositories supported by ManifoldCF. In this way we will help developers on 
> migrating contents from different data sources on MongoDB.
> You will be involved in the development of the following tasks, you will 
> learn how to:
>  * Write the connector implementation
>  * Implement unit tests
>  * Build all the integration tests for testing the connector inside the 
> framework
>  * Write the documentation for this connector
> We have a complete documentation on how to implement an Output Connector:
> [https://manifoldcf.apache.org/release/release-2.9.1/en_US/writing-output-connectors.html]
> Take a look also at our book to understand better the framework and how to 
> implement connectors:
> [https://github.com/DaddyWri/manifoldcfinaction/tree/master/pdfs]
>  
> Prospective GSOC mentor: 
> [piergior...@apache.org|mailto:piergior...@apache.org]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (CONNECTORS-1490) GSOC: MongoDB Output Connector

[Pratik Parashar (JIRA)]

[ 
https://issues.apache.org/jira/browse/CONNECTORS-1490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16370596#comment-16370596
 ] 

Pratik Parashar edited comment on CONNECTORS-1490 at 2/20/18 8:57 PM:
--

Hi, [~piergiorgioluc...@gmail.com]

I would like to contribute to this project as a part of GSOC2018. I am 
currently a masters student at the University of Southern California. Being an 
Oracle Certified Java Programmer I have a good understanding of JAVA. 

I am new to GSOC, It would be really great if you could guide me for next steps.

 


was (Author: pratikgp):
Hi, Piergiorgio Lucidi

I would like to contribute to this project as a part of GSOC2018. I am 
currently a masters student at the University of Southern California. Being an 
Oracle Certified Java Programmer I have a good understanding of JAVA. 

I am new to GSOC, It would be really great if you could guide me for next steps.

 

> GSOC: MongoDB Output Connector
> --
>
> Key: CONNECTORS-1490
> URL: https://issues.apache.org/jira/browse/CONNECTORS-1490
> Project: ManifoldCF
>  Issue Type: New Feature
>  Components: MongoDB Output Connector
>Reporter: Piergiorgio Lucidi
>Assignee: Piergiorgio Lucidi
>Priority: Major
>  Labels: MongoDB, gsoc2018, java, junit
>   Original Estimate: 480h
>  Remaining Estimate: 480h
>
> This is a project idea for [Google Summer of 
> Code|https://summerofcode.withgoogle.com/] (GSOC).
> To discuss this or other ideas with your potential mentor from the Apache 
> ManifoldCF project, sign up and post to the dev@manifoldcf.apache.org list, 
> including "[GSOC]" in the subject. You may also comment on this Jira issue if 
> you have created an account. 
> We would like to extend the Content Migration capabilities adding MongoDB / 
> GridFS as a new output connector for importing contents from one or more 
> repositories supported by ManifoldCF. In this way we will help developers on 
> migrating contents from different data sources on MongoDB.
> You will be involved in the development of the following tasks, you will 
> learn how to:
>  * Write the connector implementation
>  * Implement unit tests
>  * Build all the integration tests for testing the connector inside the 
> framework
>  * Write the documentation for this connector
> We have a complete documentation on how to implement an Output Connector:
> [https://manifoldcf.apache.org/release/release-2.9.1/en_US/writing-output-connectors.html]
> Take a look also at our book to understand better the framework and how to 
> implement connectors:
> [https://github.com/DaddyWri/manifoldcfinaction/tree/master/pdfs]
>  
> Prospective GSOC mentor: 
> [piergior...@apache.org|mailto:piergior...@apache.org]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CONNECTORS-1490) GSOC: MongoDB Output Connector

[Pratik Parashar (JIRA)]

[ 
https://issues.apache.org/jira/browse/CONNECTORS-1490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16370596#comment-16370596
 ] 

Pratik Parashar commented on CONNECTORS-1490:
-

Hi, Piergiorgio Lucidi

I would like to contribute to this project as a part of GSOC2018. I am 
currently a masters student at the University of Southern California. Being an 
Oracle Certified Java Programmer I have a good understanding of JAVA. 

I am new to GSOC, It would be really great if you could guide me for next steps.

 

> GSOC: MongoDB Output Connector
> --
>
> Key: CONNECTORS-1490
> URL: https://issues.apache.org/jira/browse/CONNECTORS-1490
> Project: ManifoldCF
>  Issue Type: New Feature
>  Components: MongoDB Output Connector
>Reporter: Piergiorgio Lucidi
>Assignee: Piergiorgio Lucidi
>Priority: Major
>  Labels: MongoDB, gsoc2018, java, junit
>   Original Estimate: 480h
>  Remaining Estimate: 480h
>
> This is a project idea for [Google Summer of 
> Code|https://summerofcode.withgoogle.com/] (GSOC).
> To discuss this or other ideas with your potential mentor from the Apache 
> ManifoldCF project, sign up and post to the dev@manifoldcf.apache.org list, 
> including "[GSOC]" in the subject. You may also comment on this Jira issue if 
> you have created an account. 
> We would like to extend the Content Migration capabilities adding MongoDB / 
> GridFS as a new output connector for importing contents from one or more 
> repositories supported by ManifoldCF. In this way we will help developers on 
> migrating contents from different data sources on MongoDB.
> You will be involved in the development of the following tasks, you will 
> learn how to:
>  * Write the connector implementation
>  * Implement unit tests
>  * Build all the integration tests for testing the connector inside the 
> framework
>  * Write the documentation for this connector
> We have a complete documentation on how to implement an Output Connector:
> [https://manifoldcf.apache.org/release/release-2.9.1/en_US/writing-output-connectors.html]
> Take a look also at our book to understand better the framework and how to 
> implement connectors:
> [https://github.com/DaddyWri/manifoldcfinaction/tree/master/pdfs]
>  
> Prospective GSOC mentor: 
> [piergior...@apache.org|mailto:piergior...@apache.org]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (CONNECTORS-1491) GSOC: Azure Storage Output Connector

[Abhishek Kumar (JIRA)]

[ 
https://issues.apache.org/jira/browse/CONNECTORS-1491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16369303#comment-16369303
 ] 

Abhishek Kumar edited comment on CONNECTORS-1491 at 2/19/18 5:04 PM:
-

Hi Piergiorgio,

I'm Abhishek Kumar. I am currently pursuing Master's degree(Final year) in 
Computer Applications from BIT Mesra, Ranchi, India.

I've worked with Azure Java SDK as well as AWS SDK and as far as I have 
understood, we are going to develop a connector for Azure storage for migrating 
data/contents from different databases and provide a cross platform support to 
migrate data. Kindly correct me, If I've understood any part of it wrong.

 

This topic is fascinating me and I would definitely like to contribute to it as 
a GSOC-2018 project.

Thanks :)


was (Author: abhishekchourasiya):
Hi Piergiorgio,

I'm Abhishek Kumar. I am currently pursuing Master's degree(Final year) in 
Computer Applications from BIT Mesra, Ranchi, India.

I've worked with Azure Java SDK as well as AWS SDK and as far as I have I 
understood, we are going to develop a connector for Azure storage for migrating 
data/contents from different databases and provide a cross platform support to 
migrate data. Kindly correct me, If I've understood any part of it wrong.

 

This topic is fascinating me and I would definitely like to contribute to it as 
a GSOC-2018 project.

Thanks :)

> GSOC: Azure Storage Output Connector
> 
>
> Key: CONNECTORS-1491
> URL: https://issues.apache.org/jira/browse/CONNECTORS-1491
> Project: ManifoldCF
>  Issue Type: New Feature
>  Components: Azure Storage Output Connector
>Reporter: Piergiorgio Lucidi
>Assignee: Piergiorgio Lucidi
>Priority: Major
>  Labels: cloud, gsoc2018, java, junit
>   Original Estimate: 480h
>  Remaining Estimate: 480h
>
> This is a project idea for [Google Summer of 
> Code|https://summerofcode.withgoogle.com/] (GSOC).
> To discuss this or other ideas with your potential mentor from the Apache 
> ManifoldCF project, sign up and post to the dev@manifoldcf.apache.org list, 
> including "[GSOC]" in the subject. You may also comment on this Jira issue if 
> you have created an account. 
> We would like to extend the Content Migration capabilities adding Azure 
> Storage as a new output connector for importing contents from one or more 
> repositories supported by ManifoldCF. In this way we will help developers on 
> migrating contents from different data sources on Azure Storage.
> You will be involved in the development of the following tasks, you will 
> learn how to:
>  * Write the connector implementation
>  * Implement unit tests
>  * Build all the integration tests for testing the connector inside the 
> framework
>  * Write the documentation for this connector
> You will find a technical description about all the references to the Azure 
> Java SDK on an existing issue on our JIRA:
> https://issues.apache.org/jira/browse/CONNECTORS-1441
>  
> We have a complete documentation on how to implement an Output Connector:
> [https://manifoldcf.apache.org/release/release-2.9.1/en_US/writing-output-connectors.html]
> Take a look at our book to understand better the framework and how to 
> implement connectors:
> [https://github.com/DaddyWri/manifoldcfinaction/tree/master/pdfs]
>  
> Prospective GSOC mentor: 
> [piergior...@apache.org|mailto:piergior...@apache.org]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (CONNECTORS-1491) GSOC: Azure Storage Output Connector

[Abhishek Kumar (JIRA)]

[ 
https://issues.apache.org/jira/browse/CONNECTORS-1491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16369303#comment-16369303
 ] 

Abhishek Kumar edited comment on CONNECTORS-1491 at 2/19/18 5:03 PM:
-

Hi Piergiorgio,

I'm Abhishek Kumar. I am currently pursuing Master's degree(Final year) in 
Computer Applications from BIT Mesra, Ranchi, India.

I've worked with Azure Java SDK as well as AWS SDK and as far as I have I 
understood, we are going to develop a connector for Azure storage for migrating 
data/contents from different databases and provide a cross platform support to 
migrate data. Kindly correct me, If I've understood any part of it wrong.

 

This topic is fascinating me and I would definitely like to contribute to it as 
a GSOC-2018 project.

Thanks :)


was (Author: abhishekchourasiya):
Hi Piergiorgio,

I'm Abhishek Kumar. I am currently pursuing Master's degree in Computer 
Applications from BIT Mesra, Ranchi, India.

I've worked with Azure Java SDK as well as AWS SDK and as far as I have I 
understood, we are going to develop a connector for Azure storage for migrating 
data/contents from different databases and provide a cross platform support to 
migrate data. Kindly correct me, If I've understood any part of it wrong.

 

This topic is fascinating me and I would definitely like to contribute to it as 
a GSOC-2018 project.

Thanks :)

> GSOC: Azure Storage Output Connector
> 
>
> Key: CONNECTORS-1491
> URL: https://issues.apache.org/jira/browse/CONNECTORS-1491
> Project: ManifoldCF
>  Issue Type: New Feature
>  Components: Azure Storage Output Connector
>Reporter: Piergiorgio Lucidi
>Assignee: Piergiorgio Lucidi
>Priority: Major
>  Labels: cloud, gsoc2018, java, junit
>   Original Estimate: 480h
>  Remaining Estimate: 480h
>
> This is a project idea for [Google Summer of 
> Code|https://summerofcode.withgoogle.com/] (GSOC).
> To discuss this or other ideas with your potential mentor from the Apache 
> ManifoldCF project, sign up and post to the dev@manifoldcf.apache.org list, 
> including "[GSOC]" in the subject. You may also comment on this Jira issue if 
> you have created an account. 
> We would like to extend the Content Migration capabilities adding Azure 
> Storage as a new output connector for importing contents from one or more 
> repositories supported by ManifoldCF. In this way we will help developers on 
> migrating contents from different data sources on Azure Storage.
> You will be involved in the development of the following tasks, you will 
> learn how to:
>  * Write the connector implementation
>  * Implement unit tests
>  * Build all the integration tests for testing the connector inside the 
> framework
>  * Write the documentation for this connector
> You will find a technical description about all the references to the Azure 
> Java SDK on an existing issue on our JIRA:
> https://issues.apache.org/jira/browse/CONNECTORS-1441
>  
> We have a complete documentation on how to implement an Output Connector:
> [https://manifoldcf.apache.org/release/release-2.9.1/en_US/writing-output-connectors.html]
> Take a look at our book to understand better the framework and how to 
> implement connectors:
> [https://github.com/DaddyWri/manifoldcfinaction/tree/master/pdfs]
>  
> Prospective GSOC mentor: 
> [piergior...@apache.org|mailto:piergior...@apache.org]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CONNECTORS-1491) GSOC: Azure Storage Output Connector

[Abhishek Kumar (JIRA)]

[ 
https://issues.apache.org/jira/browse/CONNECTORS-1491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16369303#comment-16369303
 ] 

Abhishek Kumar commented on CONNECTORS-1491:


Hi Piergiorgio,

I'm Abhishek Kumar. I am currently pursuing Master's degree in Computer 
Applications from BIT Mesra, Ranchi, India.

I've worked with Azure Java SDK as well as AWS SDK and as far as I have I 
understood, we are going to develop a connector for Azure storage for migrating 
data/contents from different databases and provide a cross platform support to 
migrate data. Kindly correct me, If I've understood any part of it wrong.

 

This topic is fascinating me and I would definitely like to contribute to it as 
a GSOC-2018 project.

Thanks :)

> GSOC: Azure Storage Output Connector
> 
>
> Key: CONNECTORS-1491
> URL: https://issues.apache.org/jira/browse/CONNECTORS-1491
> Project: ManifoldCF
>  Issue Type: New Feature
>  Components: Azure Storage Output Connector
>Reporter: Piergiorgio Lucidi
>Assignee: Piergiorgio Lucidi
>Priority: Major
>  Labels: cloud, gsoc2018, java, junit
>   Original Estimate: 480h
>  Remaining Estimate: 480h
>
> This is a project idea for [Google Summer of 
> Code|https://summerofcode.withgoogle.com/] (GSOC).
> To discuss this or other ideas with your potential mentor from the Apache 
> ManifoldCF project, sign up and post to the dev@manifoldcf.apache.org list, 
> including "[GSOC]" in the subject. You may also comment on this Jira issue if 
> you have created an account. 
> We would like to extend the Content Migration capabilities adding Azure 
> Storage as a new output connector for importing contents from one or more 
> repositories supported by ManifoldCF. In this way we will help developers on 
> migrating contents from different data sources on Azure Storage.
> You will be involved in the development of the following tasks, you will 
> learn how to:
>  * Write the connector implementation
>  * Implement unit tests
>  * Build all the integration tests for testing the connector inside the 
> framework
>  * Write the documentation for this connector
> You will find a technical description about all the references to the Azure 
> Java SDK on an existing issue on our JIRA:
> https://issues.apache.org/jira/browse/CONNECTORS-1441
>  
> We have a complete documentation on how to implement an Output Connector:
> [https://manifoldcf.apache.org/release/release-2.9.1/en_US/writing-output-connectors.html]
> Take a look at our book to understand better the framework and how to 
> implement connectors:
> [https://github.com/DaddyWri/manifoldcfinaction/tree/master/pdfs]
>  
> Prospective GSOC mentor: 
> [piergior...@apache.org|mailto:piergior...@apache.org]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CONNECTORS-1492) GSOC: Add support for Docker

[Ankur Garg (JIRA)]

[ 
https://issues.apache.org/jira/browse/CONNECTORS-1492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16368836#comment-16368836
 ] 

Ankur Garg commented on CONNECTORS-1492:


Hi,

I am a final year undergraduate student enrolled in computer science department 
at IIT Kharagpur. I am interested in this project and would like to contribute 
for the same.

I have prior experience with java and used docker in experimental mode for the 
purpose of mirgation. I have started reading the documentation provided in the 
task description and successfully completed the setup of the latest version 
described in the first chapter.

Please let me know on the steps to proceed forward.

Thank you

> GSOC: Add support for Docker
> 
>
> Key: CONNECTORS-1492
> URL: https://issues.apache.org/jira/browse/CONNECTORS-1492
> Project: ManifoldCF
>  Issue Type: New Feature
>Reporter: Piergiorgio Lucidi
>Assignee: Piergiorgio Lucidi
>Priority: Major
>  Labels: devops, docker, gsoc2018
>   Original Estimate: 240h
>  Remaining Estimate: 240h
>
> This is a project idea for [Google Summer of 
> Code|https://summerofcode.withgoogle.com/] (GSOC).
> To discuss this or other ideas with your potential mentor from the Apache 
> ManifoldCF project, sign up and post to the dev@manifoldcf.apache.org list, 
> including "[GSOC]" in the subject. You may also comment on this Jira issue if 
> you have created an account. 
> We would like to adopt Docker to provide ready to use images with 
> preconfigured architecture stack for ManifoldCF. This will include ManifoldCF 
> itself but also the related database that can be MySQL, PostgreSQL and so on.
> This will help developers to work and put in production a complete ManifoldCF 
> installation.
> You will be involved in the development of the following tasks, you will 
> learn how to:
>  * Write Docker files
>  * Write Docker Compose files
>  * Implement unit tests
>  * Build all the integration tests
>  * Write the documentation for new component
> We have a complete documentation about ManifioldCF:
> [https://manifoldcf.apache.org/release/release-2.9.1/en_US/concepts.html]
> Take a look at our book to understand better the framework and how to extend 
> it in different ways:
> [https://github.com/DaddyWri/manifoldcfinaction/tree/master/pdfs]
>  
> Prospective GSOC mentor: 
> [piergior...@apache.org|mailto:piergior...@apache.org]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CONNECTORS-1491) GSOC: Azure Storage Output Connector

[Jeff Chen (JIRA)]

[ 
https://issues.apache.org/jira/browse/CONNECTORS-1491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16368285#comment-16368285
 ] 

Jeff Chen commented on CONNECTORS-1491:
---

Hi Piergiorgio,

I have sent an email to you. :)

> GSOC: Azure Storage Output Connector
> 
>
> Key: CONNECTORS-1491
> URL: https://issues.apache.org/jira/browse/CONNECTORS-1491
> Project: ManifoldCF
>  Issue Type: New Feature
>  Components: Azure Storage Output Connector
>Reporter: Piergiorgio Lucidi
>Assignee: Piergiorgio Lucidi
>Priority: Major
>  Labels: cloud, gsoc2018, java, junit
>   Original Estimate: 480h
>  Remaining Estimate: 480h
>
> This is a project idea for [Google Summer of 
> Code|https://summerofcode.withgoogle.com/] (GSOC).
> To discuss this or other ideas with your potential mentor from the Apache 
> ManifoldCF project, sign up and post to the dev@manifoldcf.apache.org list, 
> including "[GSOC]" in the subject. You may also comment on this Jira issue if 
> you have created an account. 
> We would like to extend the Content Migration capabilities adding Azure 
> Storage as a new output connector for importing contents from one or more 
> repositories supported by ManifoldCF. In this way we will help developers on 
> migrating contents from different data sources on Azure Storage.
> You will be involved in the development of the following tasks, you will 
> learn how to:
>  * Write the connector implementation
>  * Implement unit tests
>  * Build all the integration tests for testing the connector inside the 
> framework
>  * Write the documentation for this connector
> You will find a technical description about all the references to the Azure 
> Java SDK on an existing issue on our JIRA:
> https://issues.apache.org/jira/browse/CONNECTORS-1441
>  
> We have a complete documentation on how to implement an Output Connector:
> [https://manifoldcf.apache.org/release/release-2.9.1/en_US/writing-output-connectors.html]
> Take a look at our book to understand better the framework and how to 
> implement connectors:
> [https://github.com/DaddyWri/manifoldcfinaction/tree/master/pdfs]
>  
> Prospective GSOC mentor: 
> [piergior...@apache.org|mailto:piergior...@apache.org]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CONNECTORS-1492) GSOC: Add support for Docker

[Aditya Visvanathan (JIRA)]

[ 
https://issues.apache.org/jira/browse/CONNECTORS-1492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16368103#comment-16368103
 ] 

Aditya Visvanathan commented on CONNECTORS-1492:


Hi Piergiorgio Lucidi,

Thank you very much for your reply. I have begun reading the documentation you 
mentioned.I look forward to working on this.


> GSOC: Add support for Docker
> 
>
> Key: CONNECTORS-1492
> URL: https://issues.apache.org/jira/browse/CONNECTORS-1492
> Project: ManifoldCF
>  Issue Type: New Feature
>Reporter: Piergiorgio Lucidi
>Assignee: Piergiorgio Lucidi
>Priority: Major
>  Labels: devops, docker, gsoc2018
>   Original Estimate: 240h
>  Remaining Estimate: 240h
>
> This is a project idea for [Google Summer of 
> Code|https://summerofcode.withgoogle.com/] (GSOC).
> To discuss this or other ideas with your potential mentor from the Apache 
> ManifoldCF project, sign up and post to the dev@manifoldcf.apache.org list, 
> including "[GSOC]" in the subject. You may also comment on this Jira issue if 
> you have created an account. 
> We would like to adopt Docker to provide ready to use images with 
> preconfigured architecture stack for ManifoldCF. This will include ManifoldCF 
> itself but also the related database that can be MySQL, PostgreSQL and so on.
> This will help developers to work and put in production a complete ManifoldCF 
> installation.
> You will be involved in the development of the following tasks, you will 
> learn how to:
>  * Write Docker files
>  * Write Docker Compose files
>  * Implement unit tests
>  * Build all the integration tests
>  * Write the documentation for new component
> We have a complete documentation about ManifioldCF:
> [https://manifoldcf.apache.org/release/release-2.9.1/en_US/concepts.html]
> Take a look at our book to understand better the framework and how to extend 
> it in different ways:
> [https://github.com/DaddyWri/manifoldcfinaction/tree/master/pdfs]
>  
> Prospective GSOC mentor: 
> [piergior...@apache.org|mailto:piergior...@apache.org]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [GSOC] '18 - Add support for Docker - Abhishek Kapoor - TU Munich

[Abhishek Kapoor]

Hello Piergiorgio Lucidi,

Thanks for all the response and for all the information.
I checked your response on the Jira ticket and would go through the
ManifoldCF documentation.

Also, joined the hipchat channel.

Looking forward to working with you.

On Fri, Feb 16, 2018 at 3:30 PM, Piergiorgio Lucidi <piergior...@apache.org>
wrote:

> Hi Abhishek,
>
> nice to meet you and thank you for your interest in participating in the
> Apache ManifoldCF project.
>
> What can I say?
> Welcome to the ManifoldCF Community :)
>
> It will be a pleasure to work with you and I think that you could bring a
> lot of value to the project, not only for your academic career but also for
> the next steps ;)
>
> Actually we have a previous request for working on this task that was
> arrived before yours:
> https://issues.apache.org/jira/browse/CONNECTORS-1492
>
> Could you please leave also a message on that issue?
> Then we can try to understand if we can enable both of you to work
> together on the same task or we could split the project in two separated
> tasks.
> I'll have to discuss this internally before giving you a confirmation that
> anyway will arrive only when you will apply officially starting from March.
>
> For chatting, no problem, you could join our public HipChat room at the
> following link:
> https://www.hipchat.com/gOSgu3lH8
>
> It is pretty new and we will publish it later on our new website.
> Thank you and welcome again in the community.
>
> Cheers,
> PJ
>
> 2018-02-15 19:35 GMT+01:00 Abhishek Kapoor <kapoorabhishe...@gmail.com>:
>
>> Hello Piergiorgio Lucidi,
>>
>> I am Abhishek Kapoor, currently pursuing my *Masters of Science -
>> Informatics *at *Technical University of Munich, Germany*. I am writing
>> to you to express my interest in the *Add support for Docker* project
>> offered by Apache Software Foundation under* GSOC ‘18*. I would like to
>> tell you that my research interest lies in the area of Distributed Systems,
>> Cloud Computing, Data Mining, Data Science, Networks, and Security.
>>
>> *Background Information:* I have a prior industrial experience of 2+
>> years. I have worked as a Site Reliability Engineer at Adobe for the
>> Marketing Cloud Product – Target. Few of my tasks were Product
>> Releases/Deployments, Automation (Fabric/CFEngine/Bash/Python), rectifying
>> issues in Production, Beta and Staging environment (JIRA), researching on
>> and implementing new technologies (Docker, Kubernetes) related to the
>> field. Also, I did few internships during my Bachelors and Masters, and I
>> worked on infrastructure-as-code and played around Technologies - AWS,
>> Docker, Kubernetes, Hadoop, Spark, Elasticsearch, Linux, Python, Raspberry
>> Pi, CI/CD (Jenkins, Puppet), etc. I like to read about new technologies and
>> the cutting-edge research that is going on related to my field.
>>
>> I am really excited about working on Add support for Docker project and I
>> have the required skills and background to execute a well-finished project.
>> I am very well experienced with Docker and containerized concepts and have
>> a strong understanding and working knowledge of Linux fundamentals. Also, I
>> have looked into the Tech Stack for ManifoldCF; I have worked with most of
>> the technologies in my past work experience.
>>
>> *Questions:*
>> 1. Guide me on how to start off. I am already going through the
>> documentation.
>> 2. Is there any IRC channel where I can collaborate with you and ask my
>> questions. I checked the list provided by Apache Software Foundation but
>> couldn't find the link for ManifoldCF (https://wiki.apache.org/gener
>> al/IRC).
>>
>> It will be an honor to contribute towards Apache manifoldCF project and I
>> am highly motivated to work on this project and start as soon as possible.
>> I don't have any commitments for next summer. I am almost done with my
>> masters and thus can work as many hours as I want.
>>
>> I am attaching my CV and transcript for your reference.
>> Looking forward to your response.
>>
>> *Yours sincerely*
>> Abhishek Kapoor
>> Mobile: +49-15143586760 <+49%201514%203586760>, +91-9873703731
>> <+91%2098737%2003731>
>> Linkedin <https://de.linkedin.com/in/kapoorabhishek24>
>>
>
>
>
> --
> Piergiorgio Lucidi
> https://www.open4dev.com
>



-- 
*Best Regards*
Abhishek Kapoor
Mobile: +49-15143586760, +91-9873703731
Linkedin <https://de.linkedin.com/in/kapoorabhishek24>  | Facebook
<https://www.facebook.com/kapoorabhishek24>

[jira] [Commented] (CONNECTORS-1492) GSOC: Add support for Docker

[Abhishek (JIRA)]

[ 
https://issues.apache.org/jira/browse/CONNECTORS-1492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16367810#comment-16367810
 ] 

Abhishek commented on CONNECTORS-1492:
--

Hi Piergiorgio Lucidi,

Thank you for the information. 
As I informed over the email, I am also interested in this project and would 
like to contribute towards this. I will go through the documentation mentioned 
above.

Looking forward to working with you.

Best Regards
Abhishek Kapoor

> GSOC: Add support for Docker
> 
>
> Key: CONNECTORS-1492
> URL: https://issues.apache.org/jira/browse/CONNECTORS-1492
> Project: ManifoldCF
>  Issue Type: New Feature
>Reporter: Piergiorgio Lucidi
>Assignee: Piergiorgio Lucidi
>Priority: Major
>  Labels: devops, docker, gsoc2018
>   Original Estimate: 240h
>  Remaining Estimate: 240h
>
> This is a project idea for [Google Summer of 
> Code|https://summerofcode.withgoogle.com/] (GSOC).
> To discuss this or other ideas with your potential mentor from the Apache 
> ManifoldCF project, sign up and post to the dev@manifoldcf.apache.org list, 
> including "[GSOC]" in the subject. You may also comment on this Jira issue if 
> you have created an account. 
> We would like to adopt Docker to provide ready to use images with 
> preconfigured architecture stack for ManifoldCF. This will include ManifoldCF 
> itself but also the related database that can be MySQL, PostgreSQL and so on.
> This will help developers to work and put in production a complete ManifoldCF 
> installation.
> You will be involved in the development of the following tasks, you will 
> learn how to:
>  * Write Docker files
>  * Write Docker Compose files
>  * Implement unit tests
>  * Build all the integration tests
>  * Write the documentation for new component
> We have a complete documentation about ManifioldCF:
> [https://manifoldcf.apache.org/release/release-2.9.1/en_US/concepts.html]
> Take a look at our book to understand better the framework and how to extend 
> it in different ways:
> [https://github.com/DaddyWri/manifoldcfinaction/tree/master/pdfs]
>  
> Prospective GSOC mentor: 
> [piergior...@apache.org|mailto:piergior...@apache.org]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CONNECTORS-1490) GSOC: MongoDB Output Connector

[Piergiorgio Lucidi (JIRA)]

[ 
https://issues.apache.org/jira/browse/CONNECTORS-1490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16367520#comment-16367520
 ] 

Piergiorgio Lucidi commented on CONNECTORS-1490:


Probably it could be useful for you to take a look at the ElasticSearch Output 
Connector and please also see chapter 9 of the book:

[https://github.com/DaddyWri/manifoldcfinaction/blob/master/pdfs/MCFiA%20CH%2009.pdf]

Hope this helps.

> GSOC: MongoDB Output Connector
> --
>
> Key: CONNECTORS-1490
> URL: https://issues.apache.org/jira/browse/CONNECTORS-1490
> Project: ManifoldCF
>  Issue Type: New Feature
>  Components: MongoDB Output Connector
>Reporter: Piergiorgio Lucidi
>Assignee: Piergiorgio Lucidi
>Priority: Major
>  Labels: MongoDB, gsoc2018, java, junit
>   Original Estimate: 480h
>  Remaining Estimate: 480h
>
> This is a project idea for [Google Summer of 
> Code|https://summerofcode.withgoogle.com/] (GSOC).
> To discuss this or other ideas with your potential mentor from the Apache 
> ManifoldCF project, sign up and post to the dev@manifoldcf.apache.org list, 
> including "[GSOC]" in the subject. You may also comment on this Jira issue if 
> you have created an account. 
> We would like to extend the Content Migration capabilities adding MongoDB / 
> GridFS as a new output connector for importing contents from one or more 
> repositories supported by ManifoldCF. In this way we will help developers on 
> migrating contents from different data sources on MongoDB.
> You will be involved in the development of the following tasks, you will 
> learn how to:
>  * Write the connector implementation
>  * Implement unit tests
>  * Build all the integration tests for testing the connector inside the 
> framework
>  * Write the documentation for this connector
> We have a complete documentation on how to implement an Output Connector:
> [https://manifoldcf.apache.org/release/release-2.9.1/en_US/writing-output-connectors.html]
> Take a look also at our book to understand better the framework and how to 
> implement connectors:
> [https://github.com/DaddyWri/manifoldcfinaction/tree/master/pdfs]
>  
> Prospective GSOC mentor: 
> [piergior...@apache.org|mailto:piergior...@apache.org]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CONNECTORS-1491) GSOC: Azure Storage Output Connector

[Piergiorgio Lucidi (JIRA)]

[ 
https://issues.apache.org/jira/browse/CONNECTORS-1491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16367395#comment-16367395
 ] 

Piergiorgio Lucidi commented on CONNECTORS-1491:


Hi Jeff,

nice to meet you and thank you for your interest in ManifoldCF :)

Do you have any experience on Azure? Or are you starting from scratch?

Could you please introduce your technical experience and how many exams you 
need to finish your academic career?

Consider that we also have a HipChat public room:

[https://www.hipchat.com/gOSgu3lH8]

Thank you so much and a warm welcome to the ManifoldCF Community.

 

> GSOC: Azure Storage Output Connector
> 
>
> Key: CONNECTORS-1491
> URL: https://issues.apache.org/jira/browse/CONNECTORS-1491
> Project: ManifoldCF
>  Issue Type: New Feature
>  Components: Azure Storage Output Connector
>Reporter: Piergiorgio Lucidi
>Assignee: Piergiorgio Lucidi
>Priority: Major
>  Labels: cloud, gsoc2018, java, junit
>   Original Estimate: 480h
>  Remaining Estimate: 480h
>
> This is a project idea for [Google Summer of 
> Code|https://summerofcode.withgoogle.com/] (GSOC).
> To discuss this or other ideas with your potential mentor from the Apache 
> ManifoldCF project, sign up and post to the dev@manifoldcf.apache.org list, 
> including "[GSOC]" in the subject. You may also comment on this Jira issue if 
> you have created an account. 
> We would like to extend the Content Migration capabilities adding Azure 
> Storage as a new output connector for importing contents from one or more 
> repositories supported by ManifoldCF. In this way we will help developers on 
> migrating contents from different data sources on Azure Storage.
> You will be involved in the development of the following tasks, you will 
> learn how to:
>  * Write the connector implementation
>  * Implement unit tests
>  * Build all the integration tests for testing the connector inside the 
> framework
>  * Write the documentation for this connector
> You will find a technical description about all the references to the Azure 
> Java SDK on an existing issue on our JIRA:
> https://issues.apache.org/jira/browse/CONNECTORS-1441
>  
> We have a complete documentation on how to implement an Output Connector:
> [https://manifoldcf.apache.org/release/release-2.9.1/en_US/writing-output-connectors.html]
> Take a look at our book to understand better the framework and how to 
> implement connectors:
> [https://github.com/DaddyWri/manifoldcfinaction/tree/master/pdfs]
>  
> Prospective GSOC mentor: 
> [piergior...@apache.org|mailto:piergior...@apache.org]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CONNECTORS-1492) GSOC: Add support for Docker

[Piergiorgio Lucidi (JIRA)]

[ 
https://issues.apache.org/jira/browse/CONNECTORS-1492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16367384#comment-16367384
 ] 

Piergiorgio Lucidi commented on CONNECTORS-1492:


Hi Aditya,

nice to meet you and thank you for your interest in ManifoldCF :)

I suggest you to take a look at the book *ManifoldCF in Action* written by our 
[~kwri...@metacarta.com], that you find in one of the links in the task 
description above.

The book will give you a complete introduction to the framework and all the 
typical scenarios where it is used.

Anyway you can also chat with us using our public HipChat room at the following 
link:

[https://www.hipchat.com/gOSgu3lH8]

We have another request arrived from the mailing list to work on this task and 
we will discuss about how eventually split this task or we will try to create a 
team working together for the same goal. This will be discussed later anyway 
your official application should arrive in March and I think that we have 
enough time to arrange a potential plan for both of you.

Welcome to the ManifoldCF Community.

> GSOC: Add support for Docker
> 
>
> Key: CONNECTORS-1492
> URL: https://issues.apache.org/jira/browse/CONNECTORS-1492
> Project: ManifoldCF
>  Issue Type: New Feature
>Reporter: Piergiorgio Lucidi
>Assignee: Piergiorgio Lucidi
>Priority: Major
>  Labels: devops, docker, gsoc2018
>   Original Estimate: 240h
>  Remaining Estimate: 240h
>
> This is a project idea for [Google Summer of 
> Code|https://summerofcode.withgoogle.com/] (GSOC).
> To discuss this or other ideas with your potential mentor from the Apache 
> ManifoldCF project, sign up and post to the dev@manifoldcf.apache.org list, 
> including "[GSOC]" in the subject. You may also comment on this Jira issue if 
> you have created an account. 
> We would like to adopt Docker to provide ready to use images with 
> preconfigured architecture stack for ManifoldCF. This will include ManifoldCF 
> itself but also the related database that can be MySQL, PostgreSQL and so on.
> This will help developers to work and put in production a complete ManifoldCF 
> installation.
> You will be involved in the development of the following tasks, you will 
> learn how to:
>  * Write Docker files
>  * Write Docker Compose files
>  * Implement unit tests
>  * Build all the integration tests
>  * Write the documentation for new component
> We have a complete documentation about ManifioldCF:
> [https://manifoldcf.apache.org/release/release-2.9.1/en_US/concepts.html]
> Take a look at our book to understand better the framework and how to extend 
> it in different ways:
> [https://github.com/DaddyWri/manifoldcfinaction/tree/master/pdfs]
>  
> Prospective GSOC mentor: 
> [piergior...@apache.org|mailto:piergior...@apache.org]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [GSOC] '18 - Add support for Docker - Abhishek Kapoor - TU Munich

[Piergiorgio Lucidi]

Hi Abhishek,

nice to meet you and thank you for your interest in participating in the
Apache ManifoldCF project.

What can I say?
Welcome to the ManifoldCF Community :)

It will be a pleasure to work with you and I think that you could bring a
lot of value to the project, not only for your academic career but also for
the next steps ;)

Actually we have a previous request for working on this task that was
arrived before yours:
https://issues.apache.org/jira/browse/CONNECTORS-1492

Could you please leave also a message on that issue?
Then we can try to understand if we can enable both of you to work together
on the same task or we could split the project in two separated tasks.
I'll have to discuss this internally before giving you a confirmation that
anyway will arrive only when you will apply officially starting from March.

For chatting, no problem, you could join our public HipChat room at the
following link:
https://www.hipchat.com/gOSgu3lH8

It is pretty new and we will publish it later on our new website.
Thank you and welcome again in the community.

Cheers,
PJ

2018-02-15 19:35 GMT+01:00 Abhishek Kapoor <kapoorabhishe...@gmail.com>:

> Hello Piergiorgio Lucidi,
>
> I am Abhishek Kapoor, currently pursuing my *Masters of Science -
> Informatics *at *Technical University of Munich, Germany*. I am writing
> to you to express my interest in the *Add support for Docker* project
> offered by Apache Software Foundation under* GSOC ‘18*. I would like to
> tell you that my research interest lies in the area of Distributed Systems,
> Cloud Computing, Data Mining, Data Science, Networks, and Security.
>
> *Background Information:* I have a prior industrial experience of 2+
> years. I have worked as a Site Reliability Engineer at Adobe for the
> Marketing Cloud Product – Target. Few of my tasks were Product
> Releases/Deployments, Automation (Fabric/CFEngine/Bash/Python), rectifying
> issues in Production, Beta and Staging environment (JIRA), researching on
> and implementing new technologies (Docker, Kubernetes) related to the
> field. Also, I did few internships during my Bachelors and Masters, and I
> worked on infrastructure-as-code and played around Technologies - AWS,
> Docker, Kubernetes, Hadoop, Spark, Elasticsearch, Linux, Python, Raspberry
> Pi, CI/CD (Jenkins, Puppet), etc. I like to read about new technologies and
> the cutting-edge research that is going on related to my field.
>
> I am really excited about working on Add support for Docker project and I
> have the required skills and background to execute a well-finished project.
> I am very well experienced with Docker and containerized concepts and have
> a strong understanding and working knowledge of Linux fundamentals. Also, I
> have looked into the Tech Stack for ManifoldCF; I have worked with most of
> the technologies in my past work experience.
>
> *Questions:*
> 1. Guide me on how to start off. I am already going through the
> documentation.
> 2. Is there any IRC channel where I can collaborate with you and ask my
> questions. I checked the list provided by Apache Software Foundation but
> couldn't find the link for ManifoldCF (https://wiki.apache.org/general/IRC
> ).
>
> It will be an honor to contribute towards Apache manifoldCF project and I
> am highly motivated to work on this project and start as soon as possible.
> I don't have any commitments for next summer. I am almost done with my
> masters and thus can work as many hours as I want.
>
> I am attaching my CV and transcript for your reference.
> Looking forward to your response.
>
> *Yours sincerely*
> Abhishek Kapoor
> Mobile: +49-15143586760 <+49%201514%203586760>, +91-9873703731
> <+91%2098737%2003731>
> Linkedin <https://de.linkedin.com/in/kapoorabhishek24>
>



-- 
Piergiorgio Lucidi
https://www.open4dev.com

[jira] [Commented] (CONNECTORS-1491) GSOC: Azure Storage Output Connector

[Jeff Chen (JIRA)]

[ 
https://issues.apache.org/jira/browse/CONNECTORS-1491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16366721#comment-16366721
 ] 

Jeff Chen commented on CONNECTORS-1491:
---

Hi, 

I'm Jeff Chen. Currently, I'm a grad student at Santa Clara University. I would 
like to contribute my professional skills to this topic as a project for GSOC 
2018.

 

> GSOC: Azure Storage Output Connector
> 
>
> Key: CONNECTORS-1491
> URL: https://issues.apache.org/jira/browse/CONNECTORS-1491
> Project: ManifoldCF
>  Issue Type: New Feature
>  Components: Azure Storage Output Connector
>Reporter: Piergiorgio Lucidi
>Assignee: Piergiorgio Lucidi
>Priority: Major
>  Labels: cloud, gsoc2018, java, junit
>   Original Estimate: 480h
>  Remaining Estimate: 480h
>
> This is a project idea for [Google Summer of 
> Code|https://summerofcode.withgoogle.com/] (GSOC).
> To discuss this or other ideas with your potential mentor from the Apache 
> ManifoldCF project, sign up and post to the dev@manifoldcf.apache.org list, 
> including "[GSOC]" in the subject. You may also comment on this Jira issue if 
> you have created an account. 
> We would like to extend the Content Migration capabilities adding Azure 
> Storage as a new output connector for importing contents from one or more 
> repositories supported by ManifoldCF. In this way we will help developers on 
> migrating contents from different data sources on Azure Storage.
> You will be involved in the development of the following tasks, you will 
> learn how to:
>  * Write the connector implementation
>  * Implement unit tests
>  * Build all the integration tests for testing the connector inside the 
> framework
>  * Write the documentation for this connector
> You will find a technical description about all the references to the Azure 
> Java SDK on an existing issue on our JIRA:
> https://issues.apache.org/jira/browse/CONNECTORS-1441
>  
> We have a complete documentation on how to implement an Output Connector:
> [https://manifoldcf.apache.org/release/release-2.9.1/en_US/writing-output-connectors.html]
> Take a look at our book to understand better the framework and how to 
> implement connectors:
> [https://github.com/DaddyWri/manifoldcfinaction/tree/master/pdfs]
>  
> Prospective GSOC mentor: 
> [piergior...@apache.org|mailto:piergior...@apache.org]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CONNECTORS-1492) GSOC: Add support for Docker

[Aditya Visvanathan (JIRA)]

[ 
https://issues.apache.org/jira/browse/CONNECTORS-1492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16364518#comment-16364518
 ] 

Aditya Visvanathan commented on CONNECTORS-1492:


Hello,

I'm Aditya Visvanathan, a 2nd year Engineering undergrad from Manipal 
University,India. 

I would love to work on this project as a part GSOC. I have some experience 
with Docker and Java and was wondering if there are any resources apart from 
the ManifoldCF documentation I can refer to reliably and anything special I 
should be aware of before attempting this project.

Thanks in advance.

> GSOC: Add support for Docker
> 
>
> Key: CONNECTORS-1492
> URL: https://issues.apache.org/jira/browse/CONNECTORS-1492
> Project: ManifoldCF
>  Issue Type: New Feature
>Reporter: Piergiorgio Lucidi
>Assignee: Piergiorgio Lucidi
>Priority: Major
>  Labels: devops, docker, gsoc2018
>   Original Estimate: 240h
>  Remaining Estimate: 240h
>
> This is a project idea for [Google Summer of 
> Code|https://summerofcode.withgoogle.com/] (GSOC).
> To discuss this or other ideas with your potential mentor from the Apache 
> ManifoldCF project, sign up and post to the dev@manifoldcf.apache.org list, 
> including "[GSOC]" in the subject. You may also comment on this Jira issue if 
> you have created an account. 
> We would like to adopt Docker to provide ready to use images with 
> preconfigured architecture stack for ManifoldCF. This will include ManifoldCF 
> itself but also the related database that can be MySQL, PostgreSQL and so on.
> This will help developers to work and put in production a complete ManifoldCF 
> installation.
> You will be involved in the development of the following tasks, you will 
> learn how to:
>  * Write Docker files
>  * Write Docker Compose files
>  * Implement unit tests
>  * Build all the integration tests
>  * Write the documentation for new component
> We have a complete documentation about ManifioldCF:
> [https://manifoldcf.apache.org/release/release-2.9.1/en_US/concepts.html]
> Take a look at our book to understand better the framework and how to extend 
> it in different ways:
> [https://github.com/DaddyWri/manifoldcfinaction/tree/master/pdfs]
>  
> Prospective GSOC mentor: 
> [piergior...@apache.org|mailto:piergior...@apache.org]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CONNECTORS-1490) GSOC: MongoDB Output Connector

[Irindu Nugawela (JIRA)]

[ 
https://issues.apache.org/jira/browse/CONNECTORS-1490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16363422#comment-16363422
 ] 

Irindu Nugawela commented on CONNECTORS-1490:
-

Hi, Thanks for the quick reply, What activities do we need to support in 
addition to document ingestion and document deletion,

And also I've seen that MongoDB is a NoSQL type of document-oriented database 
programme also I've seen few other implementations of OutputConnector interface 
such as KafKaConnector and GTSConnector can I use any of those implementations 
as a reference for my implementation or does MongoDB has no relevance to all 
those implementations other than extending the similar interface, can you 
please suggest a good reference implementation that would make me understand 
the task quickly if there is any. 

> GSOC: MongoDB Output Connector
> --
>
> Key: CONNECTORS-1490
> URL: https://issues.apache.org/jira/browse/CONNECTORS-1490
> Project: ManifoldCF
>  Issue Type: New Feature
>  Components: MongoDB Output Connector
>Reporter: Piergiorgio Lucidi
>Assignee: Piergiorgio Lucidi
>Priority: Major
>  Labels: MongoDB, gsoc2018, java, junit
>   Original Estimate: 480h
>  Remaining Estimate: 480h
>
> This is a project idea for [Google Summer of 
> Code|https://summerofcode.withgoogle.com/] (GSOC).
> To discuss this or other ideas with your potential mentor from the Apache 
> ManifoldCF project, sign up and post to the dev@manifoldcf.apache.org list, 
> including "[GSOC]" in the subject. You may also comment on this Jira issue if 
> you have created an account. 
> We would like to extend the Content Migration capabilities adding MongoDB / 
> GridFS as a new output connector for importing contents from one or more 
> repositories supported by ManifoldCF. In this way we will help developers on 
> migrating contents from different data sources on MongoDB.
> You will be involved in the development of the following tasks, you will 
> learn how to:
>  * Write the connector implementation
>  * Implement unit tests
>  * Build all the integration tests for testing the connector inside the 
> framework
>  * Write the documentation for this connector
> We have a complete documentation on how to implement an Output Connector:
> [https://manifoldcf.apache.org/release/release-2.9.1/en_US/writing-output-connectors.html]
> Take a look also at our book to understand better the framework and how to 
> implement connectors:
> [https://github.com/DaddyWri/manifoldcfinaction/tree/master/pdfs]
>  
> Prospective GSOC mentor: 
> [piergior...@apache.org|mailto:piergior...@apache.org]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CONNECTORS-1490) GSOC: MongoDB Output Connector

[Shinichiro Abe (JIRA)]

[ 
https://issues.apache.org/jira/browse/CONNECTORS-1490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16362991#comment-16362991
 ] 

Shinichiro Abe commented on CONNECTORS-1490:


Hi,

You would to need to impl mongo output connector extending 
[OutputConnector|https://github.com/apache/manifoldcf/blob/trunk/framework/agents/src/main/java/org/apache/manifoldcf/agents/output/BaseOutputConnector.java].

> GSOC: MongoDB Output Connector
> --
>
> Key: CONNECTORS-1490
> URL: https://issues.apache.org/jira/browse/CONNECTORS-1490
> Project: ManifoldCF
>  Issue Type: New Feature
>  Components: MongoDB Output Connector
>Reporter: Piergiorgio Lucidi
>Assignee: Piergiorgio Lucidi
>Priority: Major
>  Labels: MongoDB, gsoc2018, java, junit
>   Original Estimate: 480h
>  Remaining Estimate: 480h
>
> This is a project idea for [Google Summer of 
> Code|https://summerofcode.withgoogle.com/] (GSOC).
> To discuss this or other ideas with your potential mentor from the Apache 
> ManifoldCF project, sign up and post to the dev@manifoldcf.apache.org list, 
> including "[GSOC]" in the subject. You may also comment on this Jira issue if 
> you have created an account. 
> We would like to extend the Content Migration capabilities adding MongoDB / 
> GridFS as a new output connector for importing contents from one or more 
> repositories supported by ManifoldCF. In this way we will help developers on 
> migrating contents from different data sources on MongoDB.
> You will be involved in the development of the following tasks, you will 
> learn how to:
>  * Write the connector implementation
>  * Implement unit tests
>  * Build all the integration tests for testing the connector inside the 
> framework
>  * Write the documentation for this connector
> We have a complete documentation on how to implement an Output Connector:
> [https://manifoldcf.apache.org/release/release-2.9.1/en_US/writing-output-connectors.html]
> Take a look also at our book to understand better the framework and how to 
> implement connectors:
> [https://github.com/DaddyWri/manifoldcfinaction/tree/master/pdfs]
>  
> Prospective GSOC mentor: 
> [piergior...@apache.org|mailto:piergior...@apache.org]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CONNECTORS-1490) GSOC: MongoDB Output Connector

[Irindu Nugawela (JIRA)]

[ 
https://issues.apache.org/jira/browse/CONNECTORS-1490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16362502#comment-16362502
 ] 

Irindu Nugawela commented on CONNECTORS-1490:
-

Hi, Piergiorgio Lucidi, 

I went through your presentation and Shinichiro Abe's presentation, from that I 
figured that there are 3 types of connectors

1.Repository Connectors

2.Authority Connectors

3.Output Connectors.

and that I have to write a repository connector for MongoDB please correct me 
If I am wrong

> GSOC: MongoDB Output Connector
> --
>
> Key: CONNECTORS-1490
> URL: https://issues.apache.org/jira/browse/CONNECTORS-1490
> Project: ManifoldCF
>  Issue Type: New Feature
>  Components: MongoDB Output Connector
>Reporter: Piergiorgio Lucidi
>Assignee: Piergiorgio Lucidi
>Priority: Major
>  Labels: MongoDB, gsoc2018, java, junit
>   Original Estimate: 480h
>  Remaining Estimate: 480h
>
> This is a project idea for [Google Summer of 
> Code|https://summerofcode.withgoogle.com/] (GSOC).
> To discuss this or other ideas with your potential mentor from the Apache 
> ManifoldCF project, sign up and post to the dev@manifoldcf.apache.org list, 
> including "[GSOC]" in the subject. You may also comment on this Jira issue if 
> you have created an account. 
> We would like to extend the Content Migration capabilities adding MongoDB / 
> GridFS as a new output connector for importing contents from one or more 
> repositories supported by ManifoldCF. In this way we will help developers on 
> migrating contents from different data sources on MongoDB.
> You will be involved in the development of the following tasks, you will 
> learn how to:
>  * Write the connector implementation
>  * Implement unit tests
>  * Build all the integration tests for testing the connector inside the 
> framework
>  * Write the documentation for this connector
> We have a complete documentation on how to implement an Output Connector:
> [https://manifoldcf.apache.org/release/release-2.9.1/en_US/writing-output-connectors.html]
> Take a look also at our book to understand better the framework and how to 
> implement connectors:
> [https://github.com/DaddyWri/manifoldcfinaction/tree/master/pdfs]
>  
> Prospective GSOC mentor: 
> [piergior...@apache.org|mailto:piergior...@apache.org]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CONNECTORS-1490) GSOC: MongoDB Output Connector

[Piergiorgio Lucidi (JIRA)]

[ 
https://issues.apache.org/jira/browse/CONNECTORS-1490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16362299#comment-16362299
 ] 

Piergiorgio Lucidi commented on CONNECTORS-1490:


Hi [~irinduPera], thank you for your interest and welcome to the ManifoldCF 
community!

I saw also your private message and I'll reply to you soon.

> GSOC: MongoDB Output Connector
> --
>
> Key: CONNECTORS-1490
> URL: https://issues.apache.org/jira/browse/CONNECTORS-1490
> Project: ManifoldCF
>  Issue Type: New Feature
>  Components: MongoDB Output Connector
>Reporter: Piergiorgio Lucidi
>Assignee: Piergiorgio Lucidi
>Priority: Major
>  Labels: MongoDB, gsoc2018, java, junit
>   Original Estimate: 480h
>  Remaining Estimate: 480h
>
> This is a project idea for [Google Summer of 
> Code|https://summerofcode.withgoogle.com/] (GSOC).
> To discuss this or other ideas with your potential mentor from the Apache 
> ManifoldCF project, sign up and post to the dev@manifoldcf.apache.org list, 
> including "[GSOC]" in the subject. You may also comment on this Jira issue if 
> you have created an account. 
> We would like to extend the Content Migration capabilities adding MongoDB / 
> GridFS as a new output connector for importing contents from one or more 
> repositories supported by ManifoldCF. In this way we will help developers on 
> migrating contents from different data sources on MongoDB.
> You will be involved in the development of the following tasks, you will 
> learn how to:
>  * Write the connector implementation
>  * Implement unit tests
>  * Build all the integration tests for testing the connector inside the 
> framework
>  * Write the documentation for this connector
> We have a complete documentation on how to implement an Output Connector:
> [https://manifoldcf.apache.org/release/release-2.9.1/en_US/writing-output-connectors.html]
> Take a look also at our book to understand better the framework and how to 
> implement connectors:
> [https://github.com/DaddyWri/manifoldcfinaction/tree/master/pdfs]
>  
> Prospective GSOC mentor: 
> [piergior...@apache.org|mailto:piergior...@apache.org]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GSOC]

[Irindu Nugawela]

[jira] [Commented] (CONNECTORS-1490) GSOC: MongoDB Output Connector

[Irindu Nugawela (JIRA)]

[ 
https://issues.apache.org/jira/browse/CONNECTORS-1490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16361800#comment-16361800
 ] 

Irindu Nugawela commented on CONNECTORS-1490:
-

Hi, I am a Final Year Computer Engineering undergraduate from university of 
Peradeniya. I am interested in working on this project for GSOC 2018.

> GSOC: MongoDB Output Connector
> --
>
> Key: CONNECTORS-1490
> URL: https://issues.apache.org/jira/browse/CONNECTORS-1490
> Project: ManifoldCF
>  Issue Type: New Feature
>  Components: MongoDB Output Connector
>Reporter: Piergiorgio Lucidi
>Assignee: Piergiorgio Lucidi
>Priority: Major
>  Labels: MongoDB, gsoc2018, java, junit
>   Original Estimate: 480h
>  Remaining Estimate: 480h
>
> This is a project idea for [Google Summer of 
> Code|https://summerofcode.withgoogle.com/] (GSOC).
> To discuss this or other ideas with your potential mentor from the Apache 
> ManifoldCF project, sign up and post to the dev@manifoldcf.apache.org list, 
> including "[GSOC]" in the subject. You may also comment on this Jira issue if 
> you have created an account. 
> We would like to extend the Content Migration capabilities adding MongoDB / 
> GridFS as a new output connector for importing contents from one or more 
> repositories supported by ManifoldCF. In this way we will help developers on 
> migrating contents from different data sources on MongoDB.
> You will be involved in the development of the following tasks, you will 
> learn how to:
>  * Write the connector implementation
>  * Implement unit tests
>  * Build all the integration tests for testing the connector inside the 
> framework
>  * Write the documentation for this connector
> We have a complete documentation on how to implement an Output Connector:
> [https://manifoldcf.apache.org/release/release-2.9.1/en_US/writing-output-connectors.html]
> Take a look also at our book to understand better the framework and how to 
> implement connectors:
> [https://github.com/DaddyWri/manifoldcfinaction/tree/master/pdfs]
>  
> Prospective GSOC mentor: 
> [piergior...@apache.org|mailto:piergior...@apache.org]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (CONNECTORS-1492) GSOC: Add support for Docker

[Piergiorgio Lucidi (JIRA)]

Piergiorgio Lucidi created CONNECTORS-1492:
--

 Summary: GSOC: Add support for Docker
 Key: CONNECTORS-1492
 URL: https://issues.apache.org/jira/browse/CONNECTORS-1492
 Project: ManifoldCF
  Issue Type: New Feature
Reporter: Piergiorgio Lucidi
Assignee: Piergiorgio Lucidi


This is a project idea for [Google Summer of 
Code|https://summerofcode.withgoogle.com/] (GSOC).

To discuss this or other ideas with your potential mentor from the Apache 
ManifoldCF project, sign up and post to the dev@manifoldcf.apache.org list, 
including "[GSOC]" in the subject. You may also comment on this Jira issue if 
you have created an account. 

We would like to adopt Docker to provide ready to use images with preconfigured 
architecture stack for ManifoldCF. This will include ManifoldCF itself but also 
the related database that can be MySQL, PostgreSQL and so on.

This will help developers to work and put in production a complete ManifoldCF 
installation.

You will be involved in the development of the following tasks, you will learn 
how to:
 * Write Docker files
 * Write Docker Compose files
 * Implement unit tests
 * Build all the integration tests
 * Write the documentation for new component

We have a complete documentation about ManifioldCF:

[https://manifoldcf.apache.org/release/release-2.9.1/en_US/concepts.html]

Take a look at our book to understand better the framework and how to extend it 
in different ways:

[https://github.com/DaddyWri/manifoldcfinaction/tree/master/pdfs]

 

Prospective GSOC mentor: [piergior...@apache.org|mailto:piergior...@apache.org]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (CONNECTORS-1491) GSOC: Azure Storage Output Connector

[Piergiorgio Lucidi (JIRA)]

Piergiorgio Lucidi created CONNECTORS-1491:
--

 Summary: GSOC: Azure Storage Output Connector
 Key: CONNECTORS-1491
 URL: https://issues.apache.org/jira/browse/CONNECTORS-1491
 Project: ManifoldCF
  Issue Type: New Feature
  Components: Azure Storage Output Connector
Reporter: Piergiorgio Lucidi
Assignee: Piergiorgio Lucidi


This is a project idea for [Google Summer of 
Code|https://summerofcode.withgoogle.com/] (GSOC).

To discuss this or other ideas with your potential mentor from the Apache 
ManifoldCF project, sign up and post to the dev@manifoldcf.apache.org list, 
including "[GSOC]" in the subject. You may also comment on this Jira issue if 
you have created an account. 

We would like to extend the Content Migration capabilities adding Azure Storage 
as a new output connector for importing contents from one or more repositories 
supported by ManifoldCF. In this way we will help developers on migrating 
contents from different data sources on Azure Storage.

You will be involved in the development of the following tasks, you will learn 
how to:
 * Write the connector implementation
 * Implement unit tests
 * Build all the integration tests for testing the connector inside the 
framework
 * Write the documentation for this connector

You will find a technical description about all the references to the Azure 
Java SDK on an existing issue on our JIRA:

https://issues.apache.org/jira/browse/CONNECTORS-1441

 

We have a complete documentation on how to implement an Output Connector:

[https://manifoldcf.apache.org/release/release-2.9.1/en_US/writing-output-connectors.html]

Take a look at our book to understand better the framework and how to implement 
connectors:

[https://github.com/DaddyWri/manifoldcfinaction/tree/master/pdfs]

 

Prospective GSOC mentor: [piergior...@apache.org|mailto:piergior...@apache.org]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (CONNECTORS-1490) GSOC: MongoDB Output Connector

[Piergiorgio Lucidi (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CONNECTORS-1490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Piergiorgio Lucidi updated CONNECTORS-1490:
---
Description: 
This is a project idea for [Google Summer of 
Code|https://summerofcode.withgoogle.com/] (GSOC).

To discuss this or other ideas with your potential mentor from the Apache 
ManifoldCF project, sign up and post to the dev@manifoldcf.apache.org list, 
including "[GSOC]" in the subject. You may also comment on this Jira issue if 
you have created an account. 

We would like to extend the Content Migration capabilities adding MongoDB / 
GridFS as a new output connector for importing contents from one or more 
repositories supported by ManifoldCF. In this way we will help developers on 
migrating contents from different data sources on MongoDB.

You will be involved in the development of the following tasks, you will learn 
how to:
 * Write the connector implementation
 * Implement unit tests
 * Build all the integration tests for testing the connector inside the 
framework
 * Write the documentation for this connector

We have a complete documentation on how to implement an Output Connector:

[https://manifoldcf.apache.org/release/release-2.9.1/en_US/writing-output-connectors.html]

Take a look also at our book to understand better the framework and how to 
implement connectors:

[https://github.com/DaddyWri/manifoldcfinaction/tree/master/pdfs]

 

Prospective GSOC mentor: [piergior...@apache.org|mailto:piergior...@apache.org]

  was:
This is a project idea for [Google Summer of 
Code|https://summerofcode.withgoogle.com/] (GSOC).

To discuss this or other ideas with your potential mentor from the Apache 
ManifoldCF project, sign up and post to the dev@manifoldcf.apache.org list, 
including "[GSOC]" in the subject. You may also comment on this Jira issue if 
you have created an account. 

We would like to extend the Content Migration capabilities adding MongoDB / 
GridFS as a new output connector for importing contents from one or more 
repositories supported by ManifoldCF. In this way we will help developers on 
migrating contents from different data sources on MongoDB.

You will be involved in the development of the following tasks, you will learn 
how to:
 * Write the connector implementation
 * Implement unit tests
 * Build all the integration tests for testing the connector inside the 
framework
 * Write the documentation for this connector

We have a complete documentation on how to implement an Output Connector on 
documentation:

[https://manifoldcf.apache.org/release/release-2.9.1/en_US/writing-output-connectors.html]

Take a look also at our book to understand better the framework and how to 
implement connectors:

[https://github.com/DaddyWri/manifoldcfinaction/tree/master/pdfs]

 

Prospective GSOC mentor: [piergior...@apache.org|mailto:piergior...@apache.org]


> GSOC: MongoDB Output Connector
> --
>
> Key: CONNECTORS-1490
> URL: https://issues.apache.org/jira/browse/CONNECTORS-1490
> Project: ManifoldCF
>  Issue Type: New Feature
>  Components: MongoDB Output Connector
>Reporter: Piergiorgio Lucidi
>Assignee: Piergiorgio Lucidi
>Priority: Major
>  Labels: MongoDB, gsoc2018, java, junit
>   Original Estimate: 480h
>  Remaining Estimate: 480h
>
> This is a project idea for [Google Summer of 
> Code|https://summerofcode.withgoogle.com/] (GSOC).
> To discuss this or other ideas with your potential mentor from the Apache 
> ManifoldCF project, sign up and post to the dev@manifoldcf.apache.org list, 
> including "[GSOC]" in the subject. You may also comment on this Jira issue if 
> you have created an account. 
> We would like to extend the Content Migration capabilities adding MongoDB / 
> GridFS as a new output connector for importing contents from one or more 
> repositories supported by ManifoldCF. In this way we will help developers on 
> migrating contents from different data sources on MongoDB.
> You will be involved in the development of the following tasks, you will 
> learn how to:
>  * Write the connector implementation
>  * Implement unit tests
>  * Build all the integration tests for testing the connector inside the 
> framework
>  * Write the documentation for this connector
> We have a complete documentation on how to implement an Output Connector:
> [https://manifoldcf.apache.org/release/release-2.9.1/en_US/writing-output-connectors.html]
> Take a look also at our book to understand better the framework and how to 
> implement connectors:
> [https://github.com/DaddyWri/manifoldcfinaction/tree/master/pdfs]
>  
> Prospective GSOC mentor: 
> [piergior...@apache.org|mailto:piergior...@apache.org]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (CONNECTORS-1490) GSOC: MongoDB Output Connector

[Piergiorgio Lucidi (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CONNECTORS-1490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Piergiorgio Lucidi updated CONNECTORS-1490:
---
Description: 
This is a project idea for [Google Summer of 
Code|https://summerofcode.withgoogle.com/] (GSOC).

To discuss this or other ideas with your potential mentor from the Apache 
ManifoldCF project, sign up and post to the dev@manifoldcf.apache.org list, 
including "[GSOC]" in the subject. You may also comment on this Jira issue if 
you have created an account. 

We would like to extend the Content Migration capabilities adding MongoDB / 
GridFS as a new output connector for importing contents from one or more 
repositories supported by ManifoldCF. In this way we will help developers on 
migrating contents from different data sources on MongoDB.

You will be involved in the development of the following tasks, you will learn 
how to:
 * Write the connector implementation
 * Implement unit tests
 * Build all the integration tests for testing the connector inside the 
framework
 * Write the documentation for this connector

We have a complete documentation on how to implement an Output Connector on 
documentation:

[https://manifoldcf.apache.org/release/release-2.9.1/en_US/writing-output-connectors.html]

Take a look also at our book to understand better the framework and how to 
implement connectors:

[https://github.com/DaddyWri/manifoldcfinaction/tree/master/pdfs]

 

Prospective GSOC mentor: [piergior...@apache.org|mailto:piergior...@apache.org]

  was:
This is a project idea for [Google Summer of 
Code|https://summerofcode.withgoogle.com/] (GSOC).

To discuss this or other ideas with your potential mentor from the Apache 
ManifoldCF project, sign up and post to the dev@manifoldcf.apache.org list, 
including "[GSOC]" in the subject. You may also comment on this Jira issue if 
you have created an account.

 

We would like to extend the Content Migration capabilities adding MongoDB / 
GridFS as a new output connector for importing contents from one or more 
repositories supported by ManifoldCF. In this way we will help developers on 
migrating contents from different data sources on MongoDB.

You will be involved in the development of the following tasks, you will learn 
how to:
 * Write the connector implementation
 * Implement unit tests
 * Build all the integration tests for testing the connector inside the 
framework
 * Write the documentation for this connector

We have a complete documentation on how to implement an Output Connector on 
documentation:

[https://manifoldcf.apache.org/release/release-2.9.1/en_US/writing-output-connectors.html]

Take a look also at our book to understand better the framework and how to 
implement connectors:

[https://github.com/DaddyWri/manifoldcfinaction/tree/master/pdfs]

 

Prospective GSOC mentor: [piergior...@apache.org|mailto:piergior...@apache.org]


> GSOC: MongoDB Output Connector
> --
>
> Key: CONNECTORS-1490
> URL: https://issues.apache.org/jira/browse/CONNECTORS-1490
> Project: ManifoldCF
>  Issue Type: New Feature
>  Components: MongoDB Output Connector
>Reporter: Piergiorgio Lucidi
>Assignee: Piergiorgio Lucidi
>Priority: Major
>  Labels: MongoDB, gsoc2018, java, junit
>   Original Estimate: 480h
>  Remaining Estimate: 480h
>
> This is a project idea for [Google Summer of 
> Code|https://summerofcode.withgoogle.com/] (GSOC).
> To discuss this or other ideas with your potential mentor from the Apache 
> ManifoldCF project, sign up and post to the dev@manifoldcf.apache.org list, 
> including "[GSOC]" in the subject. You may also comment on this Jira issue if 
> you have created an account. 
> We would like to extend the Content Migration capabilities adding MongoDB / 
> GridFS as a new output connector for importing contents from one or more 
> repositories supported by ManifoldCF. In this way we will help developers on 
> migrating contents from different data sources on MongoDB.
> You will be involved in the development of the following tasks, you will 
> learn how to:
>  * Write the connector implementation
>  * Implement unit tests
>  * Build all the integration tests for testing the connector inside the 
> framework
>  * Write the documentation for this connector
> We have a complete documentation on how to implement an Output Connector on 
> documentation:
> [https://manifoldcf.apache.org/release/release-2.9.1/en_US/writing-output-connectors.html]
> Take a look also at our book to understand better the framework and how to 
> implement connectors:
> [https://github.com/DaddyWri/manifoldcfinaction/tree/master/pdfs]
>  
> Prospective GSOC mentor: 
> [piergior...@apache.org|mailto:piergior...@apache.org]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (CONNECTORS-1490) GSOC: MongoDB Output Connector

[Piergiorgio Lucidi (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CONNECTORS-1490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Piergiorgio Lucidi updated CONNECTORS-1490:
---
Description: 
This is a project idea for [Google Summer of 
Code|https://summerofcode.withgoogle.com/] (GSOC).

To discuss this or other ideas with your potential mentor from the Apache 
ManifoldCF project, sign up and post to the dev@manifoldcf.apache.org list, 
including "[GSOC]" in the subject. You may also comment on this Jira issue if 
you have created an account.

 

We would like to extend the Content Migration capabilities adding MongoDB / 
GridFS as a new output connector for importing contents from one or more 
repositories supported by ManifoldCF. In this way we will help developers on 
migrating contents from different data sources on MongoDB.

You will be involved in the development of the following tasks, you will learn 
how to:
 * Write the connector implementation
 * Implement unit tests
 * Build all the integration tests for testing the connector inside the 
framework
 * Write the documentation for this connector

We have a complete documentation on how to implement an Output Connector on 
documentation:

[https://manifoldcf.apache.org/release/release-2.9.1/en_US/writing-output-connectors.html]

Take a look also at our book to understand better the framework and how to 
implement connectors:

[https://github.com/DaddyWri/manifoldcfinaction/tree/master/pdfs]

 

Prospective GSOC mentor: [piergior...@apache.org|mailto:piergior...@apache.org]

  was:
This is a project idea for [Google Summer of 
Code|https://summerofcode.withgoogle.com/] (GSOC).

To discuss this or other ideas with your potential mentor from the Apache 
ManifoldCF project, sign up and post to the dev@manifoldcf.apache.org list, 
including "[GSOC]" in the subject. You may also comment on this Jira issue if 
you have created an account.

 

We would like to extend the Content Migration capabilities adding MongoDB / 
GridFS as a new output connector for importing contents from one or more 
repositories supported by ManifoldCF. In this way we will help developers on 
migrating contents from different data sources on MongoDB.

We have a complete documentation on how to implement an Output Connector on 
documentation:

[https://manifoldcf.apache.org/release/release-2.9.1/en_US/writing-output-connectors.html]

Take a look also at our book to understand better the framework and how to 
implement connectors:

[https://github.com/DaddyWri/manifoldcfinaction/tree/master/pdfs]

 

Prospective GSOC mentor: [mailto:piergior...@apache.org]


> GSOC: MongoDB Output Connector
> --
>
> Key: CONNECTORS-1490
> URL: https://issues.apache.org/jira/browse/CONNECTORS-1490
> Project: ManifoldCF
>  Issue Type: New Feature
>  Components: MongoDB Output Connector
>Reporter: Piergiorgio Lucidi
>Assignee: Piergiorgio Lucidi
>Priority: Major
>  Labels: MongoDB, gsoc2018, java, junit
>   Original Estimate: 480h
>  Remaining Estimate: 480h
>
> This is a project idea for [Google Summer of 
> Code|https://summerofcode.withgoogle.com/] (GSOC).
> To discuss this or other ideas with your potential mentor from the Apache 
> ManifoldCF project, sign up and post to the dev@manifoldcf.apache.org list, 
> including "[GSOC]" in the subject. You may also comment on this Jira issue if 
> you have created an account.
>  
> We would like to extend the Content Migration capabilities adding MongoDB / 
> GridFS as a new output connector for importing contents from one or more 
> repositories supported by ManifoldCF. In this way we will help developers on 
> migrating contents from different data sources on MongoDB.
> You will be involved in the development of the following tasks, you will 
> learn how to:
>  * Write the connector implementation
>  * Implement unit tests
>  * Build all the integration tests for testing the connector inside the 
> framework
>  * Write the documentation for this connector
> We have a complete documentation on how to implement an Output Connector on 
> documentation:
> [https://manifoldcf.apache.org/release/release-2.9.1/en_US/writing-output-connectors.html]
> Take a look also at our book to understand better the framework and how to 
> implement connectors:
> [https://github.com/DaddyWri/manifoldcfinaction/tree/master/pdfs]
>  
> Prospective GSOC mentor: 
> [piergior...@apache.org|mailto:piergior...@apache.org]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (CONNECTORS-1490) GSOC: MongoDB Output Connector

[Piergiorgio Lucidi (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CONNECTORS-1490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Piergiorgio Lucidi updated CONNECTORS-1490:
---
Labels: MongoDB gsoc2018 java junit  (was: MongoDB gsoc2018)

> GSOC: MongoDB Output Connector
> --
>
> Key: CONNECTORS-1490
> URL: https://issues.apache.org/jira/browse/CONNECTORS-1490
> Project: ManifoldCF
>  Issue Type: New Feature
>  Components: MongoDB Output Connector
>Reporter: Piergiorgio Lucidi
>Assignee: Piergiorgio Lucidi
>Priority: Major
>  Labels: MongoDB, gsoc2018, java, junit
>   Original Estimate: 480h
>  Remaining Estimate: 480h
>
> This is a project idea for [Google Summer of 
> Code|https://summerofcode.withgoogle.com/] (GSOC).
> To discuss this or other ideas with your potential mentor from the Apache 
> ManifoldCF project, sign up and post to the dev@manifoldcf.apache.org list, 
> including "[GSOC]" in the subject. You may also comment on this Jira issue if 
> you have created an account.
>  
> We would like to extend the Content Migration capabilities adding MongoDB / 
> GridFS as a new output connector for importing contents from one or more 
> repositories supported by ManifoldCF. In this way we will help developers on 
> migrating contents from different data sources on MongoDB.
> We have a complete documentation on how to implement an Output Connector on 
> documentation:
> [https://manifoldcf.apache.org/release/release-2.9.1/en_US/writing-output-connectors.html]
> Take a look also at our book to understand better the framework and how to 
> implement connectors:
> [https://github.com/DaddyWri/manifoldcfinaction/tree/master/pdfs]
>  
> Prospective GSOC mentor: [mailto:piergior...@apache.org]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (CONNECTORS-1490) GSOC: MongoDB Output Connector

[Piergiorgio Lucidi (JIRA)]

Piergiorgio Lucidi created CONNECTORS-1490:
--

 Summary: GSOC: MongoDB Output Connector
 Key: CONNECTORS-1490
 URL: https://issues.apache.org/jira/browse/CONNECTORS-1490
 Project: ManifoldCF
  Issue Type: New Feature
  Components: MongoDB Output Connector
Reporter: Piergiorgio Lucidi
Assignee: Piergiorgio Lucidi


This is a project idea for [Google Summer of 
Code|https://summerofcode.withgoogle.com/] (GSOC).

To discuss this or other ideas with your potential mentor from the Apache 
ManifoldCF project, sign up and post to the dev@manifoldcf.apache.org list, 
including "[GSOC]" in the subject. You may also comment on this Jira issue if 
you have created an account.

 

We would like to extend the Content Migration capabilities adding MongoDB / 
GridFS as a new output connector for importing contents from one or more 
repositories supported by ManifoldCF. In this way we will help developers on 
migrating contents from different data sources on MongoDB.

We have a complete documentation on how to implement an Output Connector on 
documentation:

[https://manifoldcf.apache.org/release/release-2.9.1/en_US/writing-output-connectors.html]

Take a look also at our book to understand better the framework and how to 
implement connectors:

[https://github.com/DaddyWri/manifoldcfinaction/tree/master/pdfs]

 

Prospective GSOC mentor: [mailto:piergior...@apache.org]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: CONNECTORS-1290 [GSOC 2016] Nuxeo repository and Authority connector for Apache ManifoldCF

[Antonio David Pérez Morales]

Hi all

I can review and help on this too.

As talked with David, I was waiting to GSoC results to be announced (30
August) and then move the new Nuxeo connectors (repository and authority)
to the project in SVN and adapt it to the Manifold way (ant, etc)

Regards

2016-08-29 10:48 GMT+02:00 Rafa Haro <rh...@apache.org>:

> Hi David,
>
> Thanks a lot for your contribution. @Karl, I can review this too.
>
> Cheers,
> Rafa
>
> On Tue, Aug 23, 2016 at 9:22 PM Karl Wright <daddy...@gmail.com> wrote:
>
> > Hi David,
> >
> > Thank you so much for participating in GSoC with ManifoldCF this year.  I
> > hope to look at pulling your code into our repository soon.
> >
> > Thanks again!
> > Karl
> >
> >
> > On Tue, Aug 23, 2016 at 3:08 PM, David Arroyo <
> > arroyoescobarda...@gmail.com>
> > wrote:
> >
> > > Hi,
> > >
> > > Today is the last day of Final Evaluation and I have already submitted
> > the
> > > project. I would thank my mentor Antonio David and ManifoldCf
> community,
> > > specially Karl, for the support.
> > >
> > > The project can be found in github [1] and you can read the
> documentation
> > > in the readme.md [2].
> > >
> > > I hope the project be useful and I am really grateful for having me for
> > > developing this project which has given me the opportunity to get new
> > > knowledge.
> > >
> > > Regards.
> > >
> > >
> > > [1] https://github.com/davarresc/nuxeo-manifold-connector
> > >
> > > [2]
> > > https://github.com/davarresc/nuxeo-manifold-connector/blob/
> > > master/README.md
> > >
> > > --
> > > David Arroyo Escobar
> > >
> >
>

Re: CONNECTORS-1290 [GSOC 2016] Nuxeo repository and Authority connector for Apache ManifoldCF

[Rafa Haro]

Hi David,

Thanks a lot for your contribution. @Karl, I can review this too.

Cheers,
Rafa

On Tue, Aug 23, 2016 at 9:22 PM Karl Wright <daddy...@gmail.com> wrote:

> Hi David,
>
> Thank you so much for participating in GSoC with ManifoldCF this year.  I
> hope to look at pulling your code into our repository soon.
>
> Thanks again!
> Karl
>
>
> On Tue, Aug 23, 2016 at 3:08 PM, David Arroyo <
> arroyoescobarda...@gmail.com>
> wrote:
>
> > Hi,
> >
> > Today is the last day of Final Evaluation and I have already submitted
> the
> > project. I would thank my mentor Antonio David and ManifoldCf community,
> > specially Karl, for the support.
> >
> > The project can be found in github [1] and you can read the documentation
> > in the readme.md [2].
> >
> > I hope the project be useful and I am really grateful for having me for
> > developing this project which has given me the opportunity to get new
> > knowledge.
> >
> > Regards.
> >
> >
> > [1] https://github.com/davarresc/nuxeo-manifold-connector
> >
> > [2]
> > https://github.com/davarresc/nuxeo-manifold-connector/blob/
> > master/README.md
> >
> > --
> > David Arroyo Escobar
> >
>

Re: CONNECTORS-1290 [GSOC 2016] Nuxeo repository and Authority connector for Apache ManifoldCF

[Karl Wright]

Hi David,

Thank you so much for participating in GSoC with ManifoldCF this year.  I
hope to look at pulling your code into our repository soon.

Thanks again!
Karl


On Tue, Aug 23, 2016 at 3:08 PM, David Arroyo <arroyoescobarda...@gmail.com>
wrote:

> Hi,
>
> Today is the last day of Final Evaluation and I have already submitted the
> project. I would thank my mentor Antonio David and ManifoldCf community,
> specially Karl, for the support.
>
> The project can be found in github [1] and you can read the documentation
> in the readme.md [2].
>
> I hope the project be useful and I am really grateful for having me for
> developing this project which has given me the opportunity to get new
> knowledge.
>
> Regards.
>
>
> [1] https://github.com/davarresc/nuxeo-manifold-connector
>
> [2]
> https://github.com/davarresc/nuxeo-manifold-connector/blob/
> master/README.md
>
> --
> David Arroyo Escobar
>

CONNECTORS-1290 [GSOC 2016] Nuxeo repository and Authority connector for Apache ManifoldCF

[David Arroyo]

Hi,

Today is the last day of Final Evaluation and I have already submitted the
project. I would thank my mentor Antonio David and ManifoldCf community,
specially Karl, for the support.

The project can be found in github [1] and you can read the documentation
in the readme.md [2].

I hope the project be useful and I am really grateful for having me for
developing this project which has given me the opportunity to get new
knowledge.

Regards.


[1] https://github.com/davarresc/nuxeo-manifold-connector

[2]
https://github.com/davarresc/nuxeo-manifold-connector/blob/master/README.md

-- 
David Arroyo Escobar

Re: CONNECTORS-1290 [GSOC 2016] Nuxeo repository and Authority connector for Apache ManifoldCF

[Karl Wright]

Hi David,

There are two possible approaches:

(1) Use the "document component" identifier when you index, or
(2) Have a means of representing document attachments in the connector's
document identifier.

The pertinent parts of IProcessActivity for components are as follows:

>>
  /** Check if a document needs to be reindexed, based on a computed
version string.
  * Call this method to determine whether reindexing is necessary.  Pass in
a newly-computed version
  * string.  This method will return "true" if the document needs to be
re-indexed.
  *@param documentIdentifier is the document identifier.
  *@param componentIdentifier is the component document identifier, if any.
  *@param newVersionString is the newly-computed version string.
  *@return true if the document needs to be reindexed.
  */
  public boolean checkDocumentNeedsReindexing(String documentIdentifier,
String componentIdentifier,
String newVersionString)
throws ManifoldCFException;

  /** Ingest the current document.
  *@param documentIdentifier is the document's identifier.
  *@param componentIdentifier is the component document identifier, if any.
  *@param version is the version of the document, as reported by the
getDocumentVersions() method of the
  *   corresponding repository connector.
  *@param documentURI is the URI to use to retrieve this document from the
search interface (and is
  *   also the unique key in the index).
  *@param data is the document data.  The data is closed after ingestion is
complete.
  *@throws IOException only when data stream reading fails.
  */
  public void ingestDocumentWithException(String documentIdentifier,
String componentIdentifier,
String version, String documentURI, RepositoryDocument data)
throws ManifoldCFException, ServiceInterruption, IOException;
<<

The assumption is that the document with all of its components are
considered and optionally (re)indexed at the same time.  This model was
developed for a connector where the primary document was an XML document
that contained all the actual content.

The alternate model, which involves making the attachments each completely
independent documents, is the preferred one, if it is possible to implement
it that way.  The SharePoint connector takes this approach, and uses MCF
carry-down information to preserve what it needs from the attachment's
parent.

Karl


On Mon, Aug 8, 2016 at 8:29 AM, David Arroyo 
wrote:

> Hi.
>
>
> I am currently dealing with document’s attachments for the Nuxeo connector.
> When consuming documents’ information using the Nuxeo REST API, I can
> access to documents’ attachments, but I’m not sure how to manage them
> within the connector. If I index them as a separated documents, I would
> need to find a way to relate them with the main or parent document, because
> if I need to delete or reindex it, I would need to find the attachments for
> deleting them also and/or reindex them if needed.
>
>
> Any idea about how to manage the attachments in ManifoldCF?
>
>
> Thanks you very much.
>
> Regards.
> --
> David Arroyo Escobar
>

CONNECTORS-1290 [GSOC 2016] Nuxeo repository and Authority connector for Apache ManifoldCF

[David Arroyo]

Hi.


I am currently dealing with document’s attachments for the Nuxeo connector.
When consuming documents’ information using the Nuxeo REST API, I can
access to documents’ attachments, but I’m not sure how to manage them
within the connector. If I index them as a separated documents, I would
need to find a way to relate them with the main or parent document, because
if I need to delete or reindex it, I would need to find the attachments for
deleting them also and/or reindex them if needed.


Any idea about how to manage the attachments in ManifoldCF?


Thanks you very much.

Regards.
-- 
David Arroyo Escobar

Re: CONNECTORS-1290 [GSOC 2016] Nuxeo repository and Authority connector for Apache ManifoldCF

[David Arroyo]

Hi Karl,


Let me answer your questions but anyway, next week I will provide a
document describing both connectors in detail.


- what the document ID's are
  The documents ID’s are the original document UID which is a unique ID
provided by Nuxeo.


- what the access tokens are
  For each document, the usernames and groups that have access to the
documents are stored.
  When the user search, his usernames and all his groups are used for
matching with these tokens.

- what the document specification has in it
  Sorry, I don't understand this question.


- what the configuration has in it
  The configuration currently supported is:
- Select domains to be crawled.
- Select documents type to be crawled.
- Give the option of choosing if the tags must be processed.


- a description of any metadata you include with the document

  The metadata include with de document are: Uid, title, last modified,
state, path, type, is checked out, repository, parent reference,
description, language, coverage, valid, creators, contributors, last
contributor, rights, expired, created, issued, nature, source, publisher
and subjects.

  Specifically to note are included the notes and mime type.


I have implemented some unit tests. Furthermore, I have been checking how I
could to do integration test, but it is not easy because Nuxeo doesn't seem
to provide Maven resources for easing the development of integration test.


Regards.

On 3 August 2016 at 09:56, Karl Wright  wrote:

> Thanks, David.
>
> Since we'll be picking up the nuxeo connector and authority into the
> project, it would be great to have a high-level description of what you did
> here.  Specifically:
>
> - what the document ID's are
> - what the access tokens are
> - what the document specification has in it
> - what the configuration has in it
> - a description of any metadata you include with the document
>
> I hope you also will consider supplying an integration test, ideally one
> that sets up its own Nuxeo instance.  If that's not possible that's OK but
> it is usually quite helpful to have such a thing.
>
> Thanks again!
> Karl
>
>
> On Wed, Aug 3, 2016 at 3:35 AM, David Arroyo  >
> wrote:
>
> > Hi,
> >
> > Last week, I finished developing the authority connector and I have been
> > testing it directly with a ManifoldCF instance. The authority connector
> has
> > been developed using Acls [1]. Each document stores users and groups
> which
> > have read permissions. When a user searches, they can only see the
> > documents which contain his groups or his username.
> >
> > The repository connector has been developed using an incremental mode for
> > seeding. At the moment, it just stores the basic properties of the
> > documents.
> >
> > During the next weeks, I will be doing some improvements until the last
> > week of my work period. During this last week, the connectors will be
> > tested and documented.
> >
> > Some improvements are:
> > - Get the document tags
> > - Give the option of choosing the domain and the documents type to be
> > crawled.
> >
> > Regards.
> >
> >
> > [1] https://doc.nuxeo.com/display/NXDOC/ACLs
> >
> > --
> > David Arroyo Escobar
> >
>



-- 
David Arroyo Escobar

Re: CONNECTORS-1290 [GSOC 2016] Nuxeo repository and Authority connector for Apache ManifoldCF

[Karl Wright]

Thanks, David.

Since we'll be picking up the nuxeo connector and authority into the
project, it would be great to have a high-level description of what you did
here.  Specifically:

- what the document ID's are
- what the access tokens are
- what the document specification has in it
- what the configuration has in it
- a description of any metadata you include with the document

I hope you also will consider supplying an integration test, ideally one
that sets up its own Nuxeo instance.  If that's not possible that's OK but
it is usually quite helpful to have such a thing.

Thanks again!
Karl


On Wed, Aug 3, 2016 at 3:35 AM, David Arroyo 
wrote:

> Hi,
>
> Last week, I finished developing the authority connector and I have been
> testing it directly with a ManifoldCF instance. The authority connector has
> been developed using Acls [1]. Each document stores users and groups which
> have read permissions. When a user searches, they can only see the
> documents which contain his groups or his username.
>
> The repository connector has been developed using an incremental mode for
> seeding. At the moment, it just stores the basic properties of the
> documents.
>
> During the next weeks, I will be doing some improvements until the last
> week of my work period. During this last week, the connectors will be
> tested and documented.
>
> Some improvements are:
> - Get the document tags
> - Give the option of choosing the domain and the documents type to be
> crawled.
>
> Regards.
>
>
> [1] https://doc.nuxeo.com/display/NXDOC/ACLs
>
> --
> David Arroyo Escobar
>

CONNECTORS-1290 [GSOC 2016] Nuxeo repository and Authority connector for Apache ManifoldCF

[David Arroyo]

Hi,

Last week, I finished developing the authority connector and I have been
testing it directly with a ManifoldCF instance. The authority connector has
been developed using Acls [1]. Each document stores users and groups which
have read permissions. When a user searches, they can only see the
documents which contain his groups or his username.

The repository connector has been developed using an incremental mode for
seeding. At the moment, it just stores the basic properties of the
documents.

During the next weeks, I will be doing some improvements until the last
week of my work period. During this last week, the connectors will be
tested and documented.

Some improvements are:
- Get the document tags
- Give the option of choosing the domain and the documents type to be
crawled.

Regards.


[1] https://doc.nuxeo.com/display/NXDOC/ACLs

-- 
David Arroyo Escobar

Re: CONNECTORS-1290 [GSOC 2016] Nuxeo repository and Authority connector for Apache ManifoldCF

[David Arroyo]

Hi Karl,

Nuxeo API is easy to use, but the Nuxeo java client gives some features for
more efficient management. Anyway, I will implement it with a httpclient
and only if is necessary in the future I will use the java client.


Regards,

David.

On 21 June 2016 at 13:21, Karl Wright  wrote:

> Hi David,
>
> If it is straightforward to use Nuxeo's REST API, I actually prefer that
> approach over the nuxeo java client.  MCF already has a huge number of
> dependencies, and managing them is a challenge.  Also, client code often
> introduces issues with thread blocking/interruptibility, since it's not
> usually designed with that use case in mind.
>
> Thanks!!
> Karl
>
>
> On Tue, Jun 21, 2016 at 7:12 AM, David Arroyo <
> arroyoescobarda...@gmail.com>
> wrote:
>
> > Hi,
> >
> >
> > Last week I started to develop the repository connector. I have been
> taking
> > a look to existent connectors for checking how they work, code structure
> > and so on.
> >
> >
> > For developing the repository connector, I have decided to implement the
> > seeding incrementally, since although the API not support it directly,
> > Nuxeo allows to do queries in a languague called  NXQL.
> >
> >
> > NXQL will be used a query to get the ids of the documents to be
> processed.
> > We can differentiate two cases:
> >
> > * The first job execution, in this case all documents are processed.
> >
> > * The following executions will use the last execution date, that is the
> > last modified date of the last processed document, which will be stored
> in
> > timestamp format, to get the documents modified from that date.
> >
> >
> > On the other hand, Nuxeo doesn´t delete the documents of the system, but
> > the state property of the document is set as deleted. So we know  what
> > documents should be removed.
> >
> >
> > The next week I will try to finish a first version of repository
> connector
> > using httpclient as client. This first version will be then tested and
> > improved. A possible improvement could be to use the official Nuxeo Java
> > Client[1] for implementing the connector.
> >
> >
> > Regards.
> >
> >
> > [1] https://github.com/nuxeo/nuxeo-java-client/
> >
>



-- 
David Arroyo Escobar

Re: CONNECTORS-1290 [GSOC 2016] Nuxeo repository and Authority connector for Apache ManifoldCF

[Karl Wright]

Hi David,

If it is straightforward to use Nuxeo's REST API, I actually prefer that
approach over the nuxeo java client.  MCF already has a huge number of
dependencies, and managing them is a challenge.  Also, client code often
introduces issues with thread blocking/interruptibility, since it's not
usually designed with that use case in mind.

Thanks!!
Karl


On Tue, Jun 21, 2016 at 7:12 AM, David Arroyo 
wrote:

> Hi,
>
>
> Last week I started to develop the repository connector. I have been taking
> a look to existent connectors for checking how they work, code structure
> and so on.
>
>
> For developing the repository connector, I have decided to implement the
> seeding incrementally, since although the API not support it directly,
> Nuxeo allows to do queries in a languague called  NXQL.
>
>
> NXQL will be used a query to get the ids of the documents to be processed.
> We can differentiate two cases:
>
> * The first job execution, in this case all documents are processed.
>
> * The following executions will use the last execution date, that is the
> last modified date of the last processed document, which will be stored in
> timestamp format, to get the documents modified from that date.
>
>
> On the other hand, Nuxeo doesn´t delete the documents of the system, but
> the state property of the document is set as deleted. So we know  what
> documents should be removed.
>
>
> The next week I will try to finish a first version of repository connector
> using httpclient as client. This first version will be then tested and
> improved. A possible improvement could be to use the official Nuxeo Java
> Client[1] for implementing the connector.
>
>
> Regards.
>
>
> [1] https://github.com/nuxeo/nuxeo-java-client/
>

CONNECTORS-1290 [GSOC 2016] Nuxeo repository and Authority connector for Apache ManifoldCF

[David Arroyo]

Hi,


Last week I started to develop the repository connector. I have been taking
a look to existent connectors for checking how they work, code structure
and so on.


For developing the repository connector, I have decided to implement the
seeding incrementally, since although the API not support it directly,
Nuxeo allows to do queries in a languague called  NXQL.


NXQL will be used a query to get the ids of the documents to be processed.
We can differentiate two cases:

* The first job execution, in this case all documents are processed.

* The following executions will use the last execution date, that is the
last modified date of the last processed document, which will be stored in
timestamp format, to get the documents modified from that date.


On the other hand, Nuxeo doesn´t delete the documents of the system, but
the state property of the document is set as deleted. So we know  what
documents should be removed.


The next week I will try to finish a first version of repository connector
using httpclient as client. This first version will be then tested and
improved. A possible improvement could be to use the official Nuxeo Java
Client[1] for implementing the connector.


Regards.


[1] https://github.com/nuxeo/nuxeo-java-client/

Re: CONNECTORS-1290 [GSOC 2016] Nuxeo repository and Authority connector for Apache ManifoldCF

[Antonio David Pérez Morales]

Hi David

Thanks for the information. It's very useful to keep the trace of your
progress during the GSoC project.

Apart from the information provided, I have to mention that we have had
several meetings (Skype and F2F) in order to introduce David in the context
of Manifold, architecture etc so that he can have a better understanding of
the tool and develop the new connectors in the best way possible.

Keep working hard.

Regards

2016-06-10 17:29 GMT+02:00 David Arroyo <arroyoescobarda...@gmail.com>:

> Hi,
>
> Following the milestones, I have designed and documented the architecture
> that I will use for the project, which has been approved by my mentor in
> the last week meeting.
>
> This week I am focused on exploring the ManifoldCF connector, performing
> some tests with existing connectors.
>
> I am checking the Nuxeo API, making request through Postman to see how it
> works. Also, I have set my environment installing locally ManifoldCF, Nuxeo
> and Solr.
>
> The next week, I will use a git repository[1] to start implementing the new
> manifold connector.
>
> Regards.
>
>
>
> [1] https://github.com/Davarresc/nuxeo-manifold-connector
>

CONNECTORS-1290 [GSOC 2016] Nuxeo repository and Authority connector for Apache ManifoldCF

[David Arroyo]

Hi,

Following the milestones, I have designed and documented the architecture
that I will use for the project, which has been approved by my mentor in
the last week meeting.

This week I am focused on exploring the ManifoldCF connector, performing
some tests with existing connectors.

I am checking the Nuxeo API, making request through Postman to see how it
works. Also, I have set my environment installing locally ManifoldCF, Nuxeo
and Solr.

The next week, I will use a git repository[1] to start implementing the new
manifold connector.

Regards.



[1] https://github.com/Davarresc/nuxeo-manifold-connector

Re: CONNECTORS-1290 [GSOC 2016] Nuxeo repository and Authority connector for Apache ManifoldCF

[Karl Wright]

Thank you for the update!

Karl


On Mon, May 9, 2016 at 4:55 AM, David Arroyo 
wrote:

> Hi,
>
> This week my mentor and me have met for reviewing the first milestones.
>
> Furthermore, my mentor gave me some guidelines about ManifoldCF, for that
> reason, I have been taken a look to ManifoldCF and Nuxeo documentation, in
> order to spread the knowledge about these two technologies I had during the
> proposal creation to be in a good position to start the implementation of
> this connector
>
> I have configured the environment also I downloaded the trunk of ManifoldCF
> and I have imported project in my IDE. The project will be developed using
> java and Git as version control system. Once the project started, it will
> be available in the Github platform.
>
> Regards.
>
> --
> David Arroyo Escobar
>

CONNECTORS-1290 [GSOC 2016] Nuxeo repository and Authority connector for Apache ManifoldCF

[David Arroyo]

Hi,

This week my mentor and me have met for reviewing the first milestones.

Furthermore, my mentor gave me some guidelines about ManifoldCF, for that
reason, I have been taken a look to ManifoldCF and Nuxeo documentation, in
order to spread the knowledge about these two technologies I had during the
proposal creation to be in a good position to start the implementation of
this connector

I have configured the environment also I downloaded the trunk of ManifoldCF
and I have imported project in my IDE. The project will be developed using
java and Git as version control system. Once the project started, it will
be available in the Github platform.

Regards.

-- 
David Arroyo Escobar

Re: CONNECTORS-1290 [GSOC 2016] Nuxeo repository and Authority connector for Apache ManifoldCF

[Karl Wright]

Welcome aboard, and good luck!
Karl

On Wed, Apr 27, 2016 at 7:18 AM, David Arroyo 
wrote:

> Hi,
>
> I wish to thank Apache ManifoldCF’s community for accepting my proposal for
> Google Summer of Code 2016, which consists of creating a Nuxeo Repository
> Connector [1]. A meeting has been scheduled with my mentor to review the
> milestones and deadlines proposed in order to split the work and create the
> corresponding issues in Jira [2].
>
> I hope my work to be useful for the community.
>
>
> Regards,
>
> David
>
>
> [1] https://summerofcode.withgoogle.com/serve/4928377030967296/
>
> [2] https://issues.apache.org/jira/browse/CONNECTORS-1290
>

CONNECTORS-1290 [GSOC 2016] Nuxeo repository and Authority connector for Apache ManifoldCF

[David Arroyo]

Hi,

I wish to thank Apache ManifoldCF’s community for accepting my proposal for
Google Summer of Code 2016, which consists of creating a Nuxeo Repository
Connector [1]. A meeting has been scheduled with my mentor to review the
milestones and deadlines proposed in order to split the work and create the
corresponding issues in Jira [2].

I hope my work to be useful for the community.


Regards,

David


[1] https://summerofcode.withgoogle.com/serve/4928377030967296/

[2] https://issues.apache.org/jira/browse/CONNECTORS-1290

Re: Gsoc 2016

[Rafa Haro]

That's right Antonio. I can see the email anyway, probably both addresses
are working but anyway, please send the email again to
ment...@community.apache.org AND priv...@manifoldcf.apache.org, not in
separated emails. You would need to subscribe to the mentors list just
sending an email to dev-subscr...@community.apache.org

Cheers,
Rafa

El El jue, 17 mar 2016 a las 9:24, Karl Wright <daddy...@gmail.com>
escribió:

> Hi Antonio,
>
> I think the list is actually "ment...@community.apache.org".  Sorry for
> the
> confusion.
>
> Karl
>
>
> On Thu, Mar 17, 2016 at 4:02 AM, Antonio David Pérez Morales <
> adperezmora...@gmail.com> wrote:
>
> > Hi
> >
> > I've just created the issue for this connector [1]. Moreover, I already
> > sent an email to ment...@apache.org requesting becoming a mentor for the
> > Apache ManifoldCF project.
> > The next step is to send an email to the Manifold PMC mail list to
> receive
> > the acknowledge.
> > Could you point me to the address for that list?
> > And in order to move forward, the next steps for after sending the email.
> >
> > Regards
> >
> > [1] https://issues.apache.org/jira/browse/CONNECTORS-1290
> >
> > 2016-03-15 15:24 GMT+01:00 David Arroyo <arroyoescobarda...@gmail.com>:
> >
> > > Hi
> > >
> > > Thank you both for answering
> > >
> > > Antonio's proposal to create a Nuxeo connector seems very interesting.
> I
> > am
> > > going to prepare and submit a proposal.
> > >
> > > Thanks,
> > > regards.
> > >
> > > On 15 March 2016 at 13:32, Karl Wright <daddy...@gmail.com> wrote:
> > >
> > > > Hi Antonio,
> > > >
> > > > I think it is perfectly reasonable to build a Nuxeo connector for a
> > GSoC
> > > > 2016 project.  You'll need to find out if David is interested, and
> sign
> > > up
> > > > to be a mentor, of course.  There's also a mentor list you need to
> join
> > > --
> > > > ment...@apache.org, I think.
> > > >
> > > > Thanks!
> > > > Karl
> > > >
> > > >
> > > > On Tue, Mar 15, 2016 at 8:21 AM, Antonio David Pérez Morales <
> > > > adperezmora...@gmail.com> wrote:
> > > >
> > > > > Hi
> > > > >
> > > > > The ideas proposed by Karl are very interesting and are needed to
> > have
> > > a
> > > > > more stable version of ManifoldCF in terms of supported connectors.
> > > > >
> > > > > Regarding the idea of implement new connectors, I have been working
> > > > lately
> > > > > with Nuxeo [1] and I would like to propose it as a potential new
> > > > connector
> > > > > to be implemented during this GSoC period.
> > > > > The idea behind this new connector is to use the Nuxeo REST API [2]
> > to
> > > > > implement a native connector for Nuxeo.
> > > > >
> > > > > Karl, in case you think this is an interesting connector to have, I
> > can
> > > > > create a new Jira ticket for that and I volunteer to act as mentor
> of
> > > > this
> > > > > possible GSoC project.
> > > > >
> > > > > Regards
> > > > >
> > > > > [1] http://www.nuxeo.com
> > > > > [2] https://doc.nuxeo.com/display/NXDOC/REST+API
> > > > >
> > > > > 2016-03-15 12:27 GMT+01:00 Karl Wright <daddy...@gmail.com>:
> > > > >
> > > > > > Hi David,
> > > > > >
> > > > > > Thank you for considering ManifoldCF for your GSoC project.
> > > > > >
> > > > > > Most of our potential GSoC projects left over from 2015 involve
> > > > > connectors
> > > > > > for proprietary repositories, unfortunately.  These are:
> > > > > >
> > > > > > (1) Livelink connector (CONNECTORS-1117) -- need to reimplement
> > using
> > > > the
> > > > > > newer REST API
> > > > > > (2) Finishing off the Alfresco Webscript connector
> > (CONNECTORS-1058)
> > > --
> > > > > > need to add the ability to support thread interruptibility
> > > > > >
> > > > > > Other projects that have been discussed include working with
> > > > SharePoint;
> > > > 

Re: Gsoc 2016

[Piergiorgio Lucidi]

Hi,

I agree that the Nuxeo connector could be a good idea :)

+1 from me

Piergiorgio

2016-03-17 9:46 GMT+01:00 Antonio David Pérez Morales <
adperezmora...@gmail.com>:

> Hi
>
> Subscribed and mail sent to both mentors and Manifold PMC list.
>
> Regards
>
> 2016-03-17 9:35 GMT+01:00 Karl Wright <daddy...@gmail.com>:
>
> > mentors-subscr...@community.apache.org
> >
> > Also, header should be something like this:
> >
> > GSoC 2016 mentor request for Ian Dunlop
> >
> > and contents:
> >
> > >>>>>>
> > Hello,
> >
> > Apache Taverna (Incubating) PMC,
> >
> > Please acknowledge my request to become a mentor for Google Summer of
> Code
> > 2016 projects for Apache Taverna (Incubating).
> >
> > I would like to receive the mentor invite to ianwdun...@apache.org
> >
> > Cheers,
> >
> > Ian
> >
> > <<<<<<
> >
> > Karl
> >
> >
> > On Thu, Mar 17, 2016 at 4:31 AM, Rafa Haro <rh...@apache.org> wrote:
> >
> > > That's right Antonio. I can see the email anyway, probably both
> addresses
> > > are working but anyway, please send the email again to
> > > ment...@community.apache.org AND priv...@manifoldcf.apache.org, not in
> > > separated emails. You would need to subscribe to the mentors list just
> > > sending an email to dev-subscr...@community.apache.org
> > >
> > > Cheers,
> > > Rafa
> > >
> > > El El jue, 17 mar 2016 a las 9:24, Karl Wright <daddy...@gmail.com>
> > > escribió:
> > >
> > > > Hi Antonio,
> > > >
> > > > I think the list is actually "ment...@community.apache.org".  Sorry
> > for
> > > > the
> > > > confusion.
> > > >
> > > > Karl
> > > >
> > > >
> > > > On Thu, Mar 17, 2016 at 4:02 AM, Antonio David Pérez Morales <
> > > > adperezmora...@gmail.com> wrote:
> > > >
> > > > > Hi
> > > > >
> > > > > I've just created the issue for this connector [1]. Moreover, I
> > already
> > > > > sent an email to ment...@apache.org requesting becoming a mentor
> for
> > > the
> > > > > Apache ManifoldCF project.
> > > > > The next step is to send an email to the Manifold PMC mail list to
> > > > receive
> > > > > the acknowledge.
> > > > > Could you point me to the address for that list?
> > > > > And in order to move forward, the next steps for after sending the
> > > email.
> > > > >
> > > > > Regards
> > > > >
> > > > > [1] https://issues.apache.org/jira/browse/CONNECTORS-1290
> > > > >
> > > > > 2016-03-15 15:24 GMT+01:00 David Arroyo <
> > arroyoescobarda...@gmail.com
> > > >:
> > > > >
> > > > > > Hi
> > > > > >
> > > > > > Thank you both for answering
> > > > > >
> > > > > > Antonio's proposal to create a Nuxeo connector seems very
> > > interesting.
> > > > I
> > > > > am
> > > > > > going to prepare and submit a proposal.
> > > > > >
> > > > > > Thanks,
> > > > > > regards.
> > > > > >
> > > > > > On 15 March 2016 at 13:32, Karl Wright <daddy...@gmail.com>
> wrote:
> > > > > >
> > > > > > > Hi Antonio,
> > > > > > >
> > > > > > > I think it is perfectly reasonable to build a Nuxeo connector
> > for a
> > > > > GSoC
> > > > > > > 2016 project.  You'll need to find out if David is interested,
> > and
> > > > sign
> > > > > > up
> > > > > > > to be a mentor, of course.  There's also a mentor list you need
> > to
> > > > join
> > > > > > --
> > > > > > > ment...@apache.org, I think.
> > > > > > >
> > > > > > > Thanks!
> > > > > > > Karl
> > > > > > >
> > > > > > >
> > > > > > > On Tue, Mar 15, 2016 at 8:21 AM, Antonio David Pérez Morales <
> > > > > > > adperezmora...@gmail.com> wrote:
> > > > > > >
> > > > > > > > Hi

Re: Gsoc 2016

[Karl Wright]

Hi Antonio,

I think the list is actually "ment...@community.apache.org".  Sorry for the
confusion.

Karl


On Thu, Mar 17, 2016 at 4:02 AM, Antonio David Pérez Morales <
adperezmora...@gmail.com> wrote:

> Hi
>
> I've just created the issue for this connector [1]. Moreover, I already
> sent an email to ment...@apache.org requesting becoming a mentor for the
> Apache ManifoldCF project.
> The next step is to send an email to the Manifold PMC mail list to receive
> the acknowledge.
> Could you point me to the address for that list?
> And in order to move forward, the next steps for after sending the email.
>
> Regards
>
> [1] https://issues.apache.org/jira/browse/CONNECTORS-1290
>
> 2016-03-15 15:24 GMT+01:00 David Arroyo <arroyoescobarda...@gmail.com>:
>
> > Hi
> >
> > Thank you both for answering
> >
> > Antonio's proposal to create a Nuxeo connector seems very interesting. I
> am
> > going to prepare and submit a proposal.
> >
> > Thanks,
> > regards.
> >
> > On 15 March 2016 at 13:32, Karl Wright <daddy...@gmail.com> wrote:
> >
> > > Hi Antonio,
> > >
> > > I think it is perfectly reasonable to build a Nuxeo connector for a
> GSoC
> > > 2016 project.  You'll need to find out if David is interested, and sign
> > up
> > > to be a mentor, of course.  There's also a mentor list you need to join
> > --
> > > ment...@apache.org, I think.
> > >
> > > Thanks!
> > > Karl
> > >
> > >
> > > On Tue, Mar 15, 2016 at 8:21 AM, Antonio David Pérez Morales <
> > > adperezmora...@gmail.com> wrote:
> > >
> > > > Hi
> > > >
> > > > The ideas proposed by Karl are very interesting and are needed to
> have
> > a
> > > > more stable version of ManifoldCF in terms of supported connectors.
> > > >
> > > > Regarding the idea of implement new connectors, I have been working
> > > lately
> > > > with Nuxeo [1] and I would like to propose it as a potential new
> > > connector
> > > > to be implemented during this GSoC period.
> > > > The idea behind this new connector is to use the Nuxeo REST API [2]
> to
> > > > implement a native connector for Nuxeo.
> > > >
> > > > Karl, in case you think this is an interesting connector to have, I
> can
> > > > create a new Jira ticket for that and I volunteer to act as mentor of
> > > this
> > > > possible GSoC project.
> > > >
> > > > Regards
> > > >
> > > > [1] http://www.nuxeo.com
> > > > [2] https://doc.nuxeo.com/display/NXDOC/REST+API
> > > >
> > > > 2016-03-15 12:27 GMT+01:00 Karl Wright <daddy...@gmail.com>:
> > > >
> > > > > Hi David,
> > > > >
> > > > > Thank you for considering ManifoldCF for your GSoC project.
> > > > >
> > > > > Most of our potential GSoC projects left over from 2015 involve
> > > > connectors
> > > > > for proprietary repositories, unfortunately.  These are:
> > > > >
> > > > > (1) Livelink connector (CONNECTORS-1117) -- need to reimplement
> using
> > > the
> > > > > newer REST API
> > > > > (2) Finishing off the Alfresco Webscript connector
> (CONNECTORS-1058)
> > --
> > > > > need to add the ability to support thread interruptibility
> > > > >
> > > > > Other projects that have been discussed include working with
> > > SharePoint;
> > > > > SharePoint has deprecated their web-services API and has instead
> gone
> > > to
> > > > a
> > > > > REST API, and we'd need a pair of connectors (authority and
> > repository)
> > > > to
> > > > > support that.  That's not properly ticketed in Jira for GSoC yet,
> and
> > > it
> > > > > may be too big for one GSoC project, but we can perhaps break it up
> > > into
> > > > > smaller pieces.
> > > > >
> > > > > So, if you can show you have access to one of these three
> proprietary
> > > > > repositories for the purposes of development, you could write a
> > > proposal
> > > > > along those lines.
> > > > >
> > > > > Alternatively, if you know of any repository that we may not
> > currently
> > > > have
> > > >

Re: Gsoc 2016

[Karl Wright]

Ok, you also need to sign up for a google groups list as well.  I would say
you needed to register with Melange, which was the tool that was used last
year to manage GSoC administration, but they seem to have discontinued it.
I don't know what they are using instead?

 google-summer-of-code-mentors-l...@googlegroups.com

Karl


On Thu, Mar 17, 2016 at 4:46 AM, Antonio David Pérez Morales <
adperezmora...@gmail.com> wrote:

> Hi
>
> Subscribed and mail sent to both mentors and Manifold PMC list.
>
> Regards
>
> 2016-03-17 9:35 GMT+01:00 Karl Wright <daddy...@gmail.com>:
>
> > mentors-subscr...@community.apache.org
> >
> > Also, header should be something like this:
> >
> > GSoC 2016 mentor request for Ian Dunlop
> >
> > and contents:
> >
> > >>>>>>
> > Hello,
> >
> > Apache Taverna (Incubating) PMC,
> >
> > Please acknowledge my request to become a mentor for Google Summer of
> Code
> > 2016 projects for Apache Taverna (Incubating).
> >
> > I would like to receive the mentor invite to ianwdun...@apache.org
> >
> > Cheers,
> >
> > Ian
> >
> > <<<<<<
> >
> > Karl
> >
> >
> > On Thu, Mar 17, 2016 at 4:31 AM, Rafa Haro <rh...@apache.org> wrote:
> >
> > > That's right Antonio. I can see the email anyway, probably both
> addresses
> > > are working but anyway, please send the email again to
> > > ment...@community.apache.org AND priv...@manifoldcf.apache.org, not in
> > > separated emails. You would need to subscribe to the mentors list just
> > > sending an email to dev-subscr...@community.apache.org
> > >
> > > Cheers,
> > > Rafa
> > >
> > > El El jue, 17 mar 2016 a las 9:24, Karl Wright <daddy...@gmail.com>
> > > escribió:
> > >
> > > > Hi Antonio,
> > > >
> > > > I think the list is actually "ment...@community.apache.org".  Sorry
> > for
> > > > the
> > > > confusion.
> > > >
> > > > Karl
> > > >
> > > >
> > > > On Thu, Mar 17, 2016 at 4:02 AM, Antonio David Pérez Morales <
> > > > adperezmora...@gmail.com> wrote:
> > > >
> > > > > Hi
> > > > >
> > > > > I've just created the issue for this connector [1]. Moreover, I
> > already
> > > > > sent an email to ment...@apache.org requesting becoming a mentor
> for
> > > the
> > > > > Apache ManifoldCF project.
> > > > > The next step is to send an email to the Manifold PMC mail list to
> > > > receive
> > > > > the acknowledge.
> > > > > Could you point me to the address for that list?
> > > > > And in order to move forward, the next steps for after sending the
> > > email.
> > > > >
> > > > > Regards
> > > > >
> > > > > [1] https://issues.apache.org/jira/browse/CONNECTORS-1290
> > > > >
> > > > > 2016-03-15 15:24 GMT+01:00 David Arroyo <
> > arroyoescobarda...@gmail.com
> > > >:
> > > > >
> > > > > > Hi
> > > > > >
> > > > > > Thank you both for answering
> > > > > >
> > > > > > Antonio's proposal to create a Nuxeo connector seems very
> > > interesting.
> > > > I
> > > > > am
> > > > > > going to prepare and submit a proposal.
> > > > > >
> > > > > > Thanks,
> > > > > > regards.
> > > > > >
> > > > > > On 15 March 2016 at 13:32, Karl Wright <daddy...@gmail.com>
> wrote:
> > > > > >
> > > > > > > Hi Antonio,
> > > > > > >
> > > > > > > I think it is perfectly reasonable to build a Nuxeo connector
> > for a
> > > > > GSoC
> > > > > > > 2016 project.  You'll need to find out if David is interested,
> > and
> > > > sign
> > > > > > up
> > > > > > > to be a mentor, of course.  There's also a mentor list you need
> > to
> > > > join
> > > > > > --
> > > > > > > ment...@apache.org, I think.
> > > > > > >
> > > > > > > Thanks!
> > > > > > > Karl
> > > > > > >
> > > > >

Re: Gsoc 2016

[Karl Wright]

And this tool seems to be germane as well:

https://summerofcode.withgoogle.com/dashboard/proposals/shared/

Karl

On Thu, Mar 17, 2016 at 6:28 AM, Karl Wright <daddy...@gmail.com> wrote:

> Ok, you also need to sign up for a google groups list as well.  I would
> say you needed to register with Melange, which was the tool that was used
> last year to manage GSoC administration, but they seem to have discontinued
> it.  I don't know what they are using instead?
>
>  google-summer-of-code-mentors-l...@googlegroups.com
>
> Karl
>
>
> On Thu, Mar 17, 2016 at 4:46 AM, Antonio David Pérez Morales <
> adperezmora...@gmail.com> wrote:
>
>> Hi
>>
>> Subscribed and mail sent to both mentors and Manifold PMC list.
>>
>> Regards
>>
>> 2016-03-17 9:35 GMT+01:00 Karl Wright <daddy...@gmail.com>:
>>
>> > mentors-subscr...@community.apache.org
>> >
>> > Also, header should be something like this:
>> >
>> > GSoC 2016 mentor request for Ian Dunlop
>> >
>> > and contents:
>> >
>> > >>>>>>
>> > Hello,
>> >
>> > Apache Taverna (Incubating) PMC,
>> >
>> > Please acknowledge my request to become a mentor for Google Summer of
>> Code
>> > 2016 projects for Apache Taverna (Incubating).
>> >
>> > I would like to receive the mentor invite to ianwdun...@apache.org
>> >
>> > Cheers,
>> >
>> > Ian
>> >
>> > <<<<<<
>> >
>> > Karl
>> >
>> >
>> > On Thu, Mar 17, 2016 at 4:31 AM, Rafa Haro <rh...@apache.org> wrote:
>> >
>> > > That's right Antonio. I can see the email anyway, probably both
>> addresses
>> > > are working but anyway, please send the email again to
>> > > ment...@community.apache.org AND priv...@manifoldcf.apache.org, not
>> in
>> > > separated emails. You would need to subscribe to the mentors list just
>> > > sending an email to dev-subscr...@community.apache.org
>> > >
>> > > Cheers,
>> > > Rafa
>> > >
>> > > El El jue, 17 mar 2016 a las 9:24, Karl Wright <daddy...@gmail.com>
>> > > escribió:
>> > >
>> > > > Hi Antonio,
>> > > >
>> > > > I think the list is actually "ment...@community.apache.org".  Sorry
>> > for
>> > > > the
>> > > > confusion.
>> > > >
>> > > > Karl
>> > > >
>> > > >
>> > > > On Thu, Mar 17, 2016 at 4:02 AM, Antonio David Pérez Morales <
>> > > > adperezmora...@gmail.com> wrote:
>> > > >
>> > > > > Hi
>> > > > >
>> > > > > I've just created the issue for this connector [1]. Moreover, I
>> > already
>> > > > > sent an email to ment...@apache.org requesting becoming a mentor
>> for
>> > > the
>> > > > > Apache ManifoldCF project.
>> > > > > The next step is to send an email to the Manifold PMC mail list to
>> > > > receive
>> > > > > the acknowledge.
>> > > > > Could you point me to the address for that list?
>> > > > > And in order to move forward, the next steps for after sending the
>> > > email.
>> > > > >
>> > > > > Regards
>> > > > >
>> > > > > [1] https://issues.apache.org/jira/browse/CONNECTORS-1290
>> > > > >
>> > > > > 2016-03-15 15:24 GMT+01:00 David Arroyo <
>> > arroyoescobarda...@gmail.com
>> > > >:
>> > > > >
>> > > > > > Hi
>> > > > > >
>> > > > > > Thank you both for answering
>> > > > > >
>> > > > > > Antonio's proposal to create a Nuxeo connector seems very
>> > > interesting.
>> > > > I
>> > > > > am
>> > > > > > going to prepare and submit a proposal.
>> > > > > >
>> > > > > > Thanks,
>> > > > > > regards.
>> > > > > >
>> > > > > > On 15 March 2016 at 13:32, Karl Wright <daddy...@gmail.com>
>> wrote:
>> > > > > >
>> > > > > > > Hi Antonio,
>> > > > > > >
>> > > > > > > I 

Re: Gsoc 2016

[Antonio David Pérez Morales]

Hi

I've just created the issue for this connector [1]. Moreover, I already
sent an email to ment...@apache.org requesting becoming a mentor for the
Apache ManifoldCF project.
The next step is to send an email to the Manifold PMC mail list to receive
the acknowledge.
Could you point me to the address for that list?
And in order to move forward, the next steps for after sending the email.

Regards

[1] https://issues.apache.org/jira/browse/CONNECTORS-1290

2016-03-15 15:24 GMT+01:00 David Arroyo <arroyoescobarda...@gmail.com>:

> Hi
>
> Thank you both for answering
>
> Antonio's proposal to create a Nuxeo connector seems very interesting. I am
> going to prepare and submit a proposal.
>
> Thanks,
> regards.
>
> On 15 March 2016 at 13:32, Karl Wright <daddy...@gmail.com> wrote:
>
> > Hi Antonio,
> >
> > I think it is perfectly reasonable to build a Nuxeo connector for a GSoC
> > 2016 project.  You'll need to find out if David is interested, and sign
> up
> > to be a mentor, of course.  There's also a mentor list you need to join
> --
> > ment...@apache.org, I think.
> >
> > Thanks!
> > Karl
> >
> >
> > On Tue, Mar 15, 2016 at 8:21 AM, Antonio David Pérez Morales <
> > adperezmora...@gmail.com> wrote:
> >
> > > Hi
> > >
> > > The ideas proposed by Karl are very interesting and are needed to have
> a
> > > more stable version of ManifoldCF in terms of supported connectors.
> > >
> > > Regarding the idea of implement new connectors, I have been working
> > lately
> > > with Nuxeo [1] and I would like to propose it as a potential new
> > connector
> > > to be implemented during this GSoC period.
> > > The idea behind this new connector is to use the Nuxeo REST API [2] to
> > > implement a native connector for Nuxeo.
> > >
> > > Karl, in case you think this is an interesting connector to have, I can
> > > create a new Jira ticket for that and I volunteer to act as mentor of
> > this
> > > possible GSoC project.
> > >
> > > Regards
> > >
> > > [1] http://www.nuxeo.com
> > > [2] https://doc.nuxeo.com/display/NXDOC/REST+API
> > >
> > > 2016-03-15 12:27 GMT+01:00 Karl Wright <daddy...@gmail.com>:
> > >
> > > > Hi David,
> > > >
> > > > Thank you for considering ManifoldCF for your GSoC project.
> > > >
> > > > Most of our potential GSoC projects left over from 2015 involve
> > > connectors
> > > > for proprietary repositories, unfortunately.  These are:
> > > >
> > > > (1) Livelink connector (CONNECTORS-1117) -- need to reimplement using
> > the
> > > > newer REST API
> > > > (2) Finishing off the Alfresco Webscript connector (CONNECTORS-1058)
> --
> > > > need to add the ability to support thread interruptibility
> > > >
> > > > Other projects that have been discussed include working with
> > SharePoint;
> > > > SharePoint has deprecated their web-services API and has instead gone
> > to
> > > a
> > > > REST API, and we'd need a pair of connectors (authority and
> repository)
> > > to
> > > > support that.  That's not properly ticketed in Jira for GSoC yet, and
> > it
> > > > may be too big for one GSoC project, but we can perhaps break it up
> > into
> > > > smaller pieces.
> > > >
> > > > So, if you can show you have access to one of these three proprietary
> > > > repositories for the purposes of development, you could write a
> > proposal
> > > > along those lines.
> > > >
> > > > Alternatively, if you know of any repository that we may not
> currently
> > > have
> > > > a connector for that could prove useful to someone, you could propose
> > > that
> > > > as a project.
> > > >
> > > > We're currently pretty shorthanded when it comes to mentors, so we
> will
> > > > only be able to accept one or two proposals at most this year.
> > > >
> > > > Thanks!
> > > > Karl
> > > >
> > > >
> > > > On Tue, Mar 15, 2016 at 6:44 AM, David Arroyo <
> > > > arroyoescobarda...@gmail.com>
> > > > wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > I am David Arroyo, undergraduate Software Engineer at University of
> > > > > Seville, Spain and I am graduat

Re: Gsoc 2016

[Karl Wright]

mentors-subscr...@community.apache.org

Also, header should be something like this:

GSoC 2016 mentor request for Ian Dunlop

and contents:

>>>>>>
Hello,

Apache Taverna (Incubating) PMC,

Please acknowledge my request to become a mentor for Google Summer of Code
2016 projects for Apache Taverna (Incubating).

I would like to receive the mentor invite to ianwdun...@apache.org

Cheers,

Ian

<<<<<<

Karl


On Thu, Mar 17, 2016 at 4:31 AM, Rafa Haro <rh...@apache.org> wrote:

> That's right Antonio. I can see the email anyway, probably both addresses
> are working but anyway, please send the email again to
> ment...@community.apache.org AND priv...@manifoldcf.apache.org, not in
> separated emails. You would need to subscribe to the mentors list just
> sending an email to dev-subscr...@community.apache.org
>
> Cheers,
> Rafa
>
> El El jue, 17 mar 2016 a las 9:24, Karl Wright <daddy...@gmail.com>
> escribió:
>
> > Hi Antonio,
> >
> > I think the list is actually "ment...@community.apache.org".  Sorry for
> > the
> > confusion.
> >
> > Karl
> >
> >
> > On Thu, Mar 17, 2016 at 4:02 AM, Antonio David Pérez Morales <
> > adperezmora...@gmail.com> wrote:
> >
> > > Hi
> > >
> > > I've just created the issue for this connector [1]. Moreover, I already
> > > sent an email to ment...@apache.org requesting becoming a mentor for
> the
> > > Apache ManifoldCF project.
> > > The next step is to send an email to the Manifold PMC mail list to
> > receive
> > > the acknowledge.
> > > Could you point me to the address for that list?
> > > And in order to move forward, the next steps for after sending the
> email.
> > >
> > > Regards
> > >
> > > [1] https://issues.apache.org/jira/browse/CONNECTORS-1290
> > >
> > > 2016-03-15 15:24 GMT+01:00 David Arroyo <arroyoescobarda...@gmail.com
> >:
> > >
> > > > Hi
> > > >
> > > > Thank you both for answering
> > > >
> > > > Antonio's proposal to create a Nuxeo connector seems very
> interesting.
> > I
> > > am
> > > > going to prepare and submit a proposal.
> > > >
> > > > Thanks,
> > > > regards.
> > > >
> > > > On 15 March 2016 at 13:32, Karl Wright <daddy...@gmail.com> wrote:
> > > >
> > > > > Hi Antonio,
> > > > >
> > > > > I think it is perfectly reasonable to build a Nuxeo connector for a
> > > GSoC
> > > > > 2016 project.  You'll need to find out if David is interested, and
> > sign
> > > > up
> > > > > to be a mentor, of course.  There's also a mentor list you need to
> > join
> > > > --
> > > > > ment...@apache.org, I think.
> > > > >
> > > > > Thanks!
> > > > > Karl
> > > > >
> > > > >
> > > > > On Tue, Mar 15, 2016 at 8:21 AM, Antonio David Pérez Morales <
> > > > > adperezmora...@gmail.com> wrote:
> > > > >
> > > > > > Hi
> > > > > >
> > > > > > The ideas proposed by Karl are very interesting and are needed to
> > > have
> > > > a
> > > > > > more stable version of ManifoldCF in terms of supported
> connectors.
> > > > > >
> > > > > > Regarding the idea of implement new connectors, I have been
> working
> > > > > lately
> > > > > > with Nuxeo [1] and I would like to propose it as a potential new
> > > > > connector
> > > > > > to be implemented during this GSoC period.
> > > > > > The idea behind this new connector is to use the Nuxeo REST API
> [2]
> > > to
> > > > > > implement a native connector for Nuxeo.
> > > > > >
> > > > > > Karl, in case you think this is an interesting connector to
> have, I
> > > can
> > > > > > create a new Jira ticket for that and I volunteer to act as
> mentor
> > of
> > > > > this
> > > > > > possible GSoC project.
> > > > > >
> > > > > > Regards
> > > > > >
> > > > > > [1] http://www.nuxeo.com
> > > > > > [2] https://doc.nuxeo.com/display/NXDOC/REST+API
> > > > > >
> > > > > > 2016-03-15 12:27 

Re: Gsoc 2016

[Antonio David Pérez Morales]

Yes, Melange has been discontinued and this year another tool is being used.

I will sign up for that google group list and create an account for the new
tool, checking if I can select the type of account (mentor instead of
normal student).

Regards

2016-03-17 11:30 GMT+01:00 Karl Wright <daddy...@gmail.com>:

> And this tool seems to be germane as well:
>
> https://summerofcode.withgoogle.com/dashboard/proposals/shared/
>
> Karl
>
> On Thu, Mar 17, 2016 at 6:28 AM, Karl Wright <daddy...@gmail.com> wrote:
>
> > Ok, you also need to sign up for a google groups list as well.  I would
> > say you needed to register with Melange, which was the tool that was used
> > last year to manage GSoC administration, but they seem to have
> discontinued
> > it.  I don't know what they are using instead?
> >
> >  google-summer-of-code-mentors-l...@googlegroups.com
> >
> > Karl
> >
> >
> > On Thu, Mar 17, 2016 at 4:46 AM, Antonio David Pérez Morales <
> > adperezmora...@gmail.com> wrote:
> >
> >> Hi
> >>
> >> Subscribed and mail sent to both mentors and Manifold PMC list.
> >>
> >> Regards
> >>
> >> 2016-03-17 9:35 GMT+01:00 Karl Wright <daddy...@gmail.com>:
> >>
> >> > mentors-subscr...@community.apache.org
> >> >
> >> > Also, header should be something like this:
> >> >
> >> > GSoC 2016 mentor request for Ian Dunlop
> >> >
> >> > and contents:
> >> >
> >> > >>>>>>
> >> > Hello,
> >> >
> >> > Apache Taverna (Incubating) PMC,
> >> >
> >> > Please acknowledge my request to become a mentor for Google Summer of
> >> Code
> >> > 2016 projects for Apache Taverna (Incubating).
> >> >
> >> > I would like to receive the mentor invite to ianwdun...@apache.org
> >> >
> >> > Cheers,
> >> >
> >> > Ian
> >> >
> >> > <<<<<<
> >> >
> >> > Karl
> >> >
> >> >
> >> > On Thu, Mar 17, 2016 at 4:31 AM, Rafa Haro <rh...@apache.org> wrote:
> >> >
> >> > > That's right Antonio. I can see the email anyway, probably both
> >> addresses
> >> > > are working but anyway, please send the email again to
> >> > > ment...@community.apache.org AND priv...@manifoldcf.apache.org, not
> >> in
> >> > > separated emails. You would need to subscribe to the mentors list
> just
> >> > > sending an email to dev-subscr...@community.apache.org
> >> > >
> >> > > Cheers,
> >> > > Rafa
> >> > >
> >> > > El El jue, 17 mar 2016 a las 9:24, Karl Wright <daddy...@gmail.com>
> >> > > escribió:
> >> > >
> >> > > > Hi Antonio,
> >> > > >
> >> > > > I think the list is actually "ment...@community.apache.org".
> Sorry
> >> > for
> >> > > > the
> >> > > > confusion.
> >> > > >
> >> > > > Karl
> >> > > >
> >> > > >
> >> > > > On Thu, Mar 17, 2016 at 4:02 AM, Antonio David Pérez Morales <
> >> > > > adperezmora...@gmail.com> wrote:
> >> > > >
> >> > > > > Hi
> >> > > > >
> >> > > > > I've just created the issue for this connector [1]. Moreover, I
> >> > already
> >> > > > > sent an email to ment...@apache.org requesting becoming a
> mentor
> >> for
> >> > > the
> >> > > > > Apache ManifoldCF project.
> >> > > > > The next step is to send an email to the Manifold PMC mail list
> to
> >> > > > receive
> >> > > > > the acknowledge.
> >> > > > > Could you point me to the address for that list?
> >> > > > > And in order to move forward, the next steps for after sending
> the
> >> > > email.
> >> > > > >
> >> > > > > Regards
> >> > > > >
> >> > > > > [1] https://issues.apache.org/jira/browse/CONNECTORS-1290
> >> > > > >
> >> > > > > 2016-03-15 15:24 GMT+01:00 David Arroyo <
> >> > arroyoescobarda...@gmail.com
> >> > > >:
> &g

Re: Gsoc 2016

[Antonio David Pérez Morales]

Hi

Subscribed and mail sent to both mentors and Manifold PMC list.

Regards

2016-03-17 9:35 GMT+01:00 Karl Wright <daddy...@gmail.com>:

> mentors-subscr...@community.apache.org
>
> Also, header should be something like this:
>
> GSoC 2016 mentor request for Ian Dunlop
>
> and contents:
>
> >>>>>>
> Hello,
>
> Apache Taverna (Incubating) PMC,
>
> Please acknowledge my request to become a mentor for Google Summer of Code
> 2016 projects for Apache Taverna (Incubating).
>
> I would like to receive the mentor invite to ianwdun...@apache.org
>
> Cheers,
>
> Ian
>
> <<<<<<
>
> Karl
>
>
> On Thu, Mar 17, 2016 at 4:31 AM, Rafa Haro <rh...@apache.org> wrote:
>
> > That's right Antonio. I can see the email anyway, probably both addresses
> > are working but anyway, please send the email again to
> > ment...@community.apache.org AND priv...@manifoldcf.apache.org, not in
> > separated emails. You would need to subscribe to the mentors list just
> > sending an email to dev-subscr...@community.apache.org
> >
> > Cheers,
> > Rafa
> >
> > El El jue, 17 mar 2016 a las 9:24, Karl Wright <daddy...@gmail.com>
> > escribió:
> >
> > > Hi Antonio,
> > >
> > > I think the list is actually "ment...@community.apache.org".  Sorry
> for
> > > the
> > > confusion.
> > >
> > > Karl
> > >
> > >
> > > On Thu, Mar 17, 2016 at 4:02 AM, Antonio David Pérez Morales <
> > > adperezmora...@gmail.com> wrote:
> > >
> > > > Hi
> > > >
> > > > I've just created the issue for this connector [1]. Moreover, I
> already
> > > > sent an email to ment...@apache.org requesting becoming a mentor for
> > the
> > > > Apache ManifoldCF project.
> > > > The next step is to send an email to the Manifold PMC mail list to
> > > receive
> > > > the acknowledge.
> > > > Could you point me to the address for that list?
> > > > And in order to move forward, the next steps for after sending the
> > email.
> > > >
> > > > Regards
> > > >
> > > > [1] https://issues.apache.org/jira/browse/CONNECTORS-1290
> > > >
> > > > 2016-03-15 15:24 GMT+01:00 David Arroyo <
> arroyoescobarda...@gmail.com
> > >:
> > > >
> > > > > Hi
> > > > >
> > > > > Thank you both for answering
> > > > >
> > > > > Antonio's proposal to create a Nuxeo connector seems very
> > interesting.
> > > I
> > > > am
> > > > > going to prepare and submit a proposal.
> > > > >
> > > > > Thanks,
> > > > > regards.
> > > > >
> > > > > On 15 March 2016 at 13:32, Karl Wright <daddy...@gmail.com> wrote:
> > > > >
> > > > > > Hi Antonio,
> > > > > >
> > > > > > I think it is perfectly reasonable to build a Nuxeo connector
> for a
> > > > GSoC
> > > > > > 2016 project.  You'll need to find out if David is interested,
> and
> > > sign
> > > > > up
> > > > > > to be a mentor, of course.  There's also a mentor list you need
> to
> > > join
> > > > > --
> > > > > > ment...@apache.org, I think.
> > > > > >
> > > > > > Thanks!
> > > > > > Karl
> > > > > >
> > > > > >
> > > > > > On Tue, Mar 15, 2016 at 8:21 AM, Antonio David Pérez Morales <
> > > > > > adperezmora...@gmail.com> wrote:
> > > > > >
> > > > > > > Hi
> > > > > > >
> > > > > > > The ideas proposed by Karl are very interesting and are needed
> to
> > > > have
> > > > > a
> > > > > > > more stable version of ManifoldCF in terms of supported
> > connectors.
> > > > > > >
> > > > > > > Regarding the idea of implement new connectors, I have been
> > working
> > > > > > lately
> > > > > > > with Nuxeo [1] and I would like to propose it as a potential
> new
> > > > > > connector
> > > > > > > to be implemented during this GSoC period.
> > > > > > > The idea behind this new connector is to

Re: Gsoc 2016

[David Arroyo]

Hi

Thank you both for answering

Antonio's proposal to create a Nuxeo connector seems very interesting. I am
going to prepare and submit a proposal.

Thanks,
regards.

On 15 March 2016 at 13:32, Karl Wright <daddy...@gmail.com> wrote:

> Hi Antonio,
>
> I think it is perfectly reasonable to build a Nuxeo connector for a GSoC
> 2016 project.  You'll need to find out if David is interested, and sign up
> to be a mentor, of course.  There's also a mentor list you need to join --
> ment...@apache.org, I think.
>
> Thanks!
> Karl
>
>
> On Tue, Mar 15, 2016 at 8:21 AM, Antonio David Pérez Morales <
> adperezmora...@gmail.com> wrote:
>
> > Hi
> >
> > The ideas proposed by Karl are very interesting and are needed to have a
> > more stable version of ManifoldCF in terms of supported connectors.
> >
> > Regarding the idea of implement new connectors, I have been working
> lately
> > with Nuxeo [1] and I would like to propose it as a potential new
> connector
> > to be implemented during this GSoC period.
> > The idea behind this new connector is to use the Nuxeo REST API [2] to
> > implement a native connector for Nuxeo.
> >
> > Karl, in case you think this is an interesting connector to have, I can
> > create a new Jira ticket for that and I volunteer to act as mentor of
> this
> > possible GSoC project.
> >
> > Regards
> >
> > [1] http://www.nuxeo.com
> > [2] https://doc.nuxeo.com/display/NXDOC/REST+API
> >
> > 2016-03-15 12:27 GMT+01:00 Karl Wright <daddy...@gmail.com>:
> >
> > > Hi David,
> > >
> > > Thank you for considering ManifoldCF for your GSoC project.
> > >
> > > Most of our potential GSoC projects left over from 2015 involve
> > connectors
> > > for proprietary repositories, unfortunately.  These are:
> > >
> > > (1) Livelink connector (CONNECTORS-1117) -- need to reimplement using
> the
> > > newer REST API
> > > (2) Finishing off the Alfresco Webscript connector (CONNECTORS-1058) --
> > > need to add the ability to support thread interruptibility
> > >
> > > Other projects that have been discussed include working with
> SharePoint;
> > > SharePoint has deprecated their web-services API and has instead gone
> to
> > a
> > > REST API, and we'd need a pair of connectors (authority and repository)
> > to
> > > support that.  That's not properly ticketed in Jira for GSoC yet, and
> it
> > > may be too big for one GSoC project, but we can perhaps break it up
> into
> > > smaller pieces.
> > >
> > > So, if you can show you have access to one of these three proprietary
> > > repositories for the purposes of development, you could write a
> proposal
> > > along those lines.
> > >
> > > Alternatively, if you know of any repository that we may not currently
> > have
> > > a connector for that could prove useful to someone, you could propose
> > that
> > > as a project.
> > >
> > > We're currently pretty shorthanded when it comes to mentors, so we will
> > > only be able to accept one or two proposals at most this year.
> > >
> > > Thanks!
> > > Karl
> > >
> > >
> > > On Tue, Mar 15, 2016 at 6:44 AM, David Arroyo <
> > > arroyoescobarda...@gmail.com>
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > > I am David Arroyo, undergraduate Software Engineer at University of
> > > > Seville, Spain and I am graduate in a Superior Grade Formative Course
> > on
> > > > multi-platform application development.
> > > >
> > > > During last months, I have been following the mailing list and also
> > > > reviewing some open issues (some of them tagged as gsoc gsoc2015). I
> > > would
> > > > be interested to collaborate in this project to get some experience
> > and I
> > > > think GSoC could be an interesting opportunity to learn about open
> > source
> > > > community development, unkown for me so far, and learning a bit more
> > > about
> > > > the technologies used in this project.
> > > >
> > > > My intention is continue collaborating with the project after GSoC
> > (both
> > > if
> > > > I'm accepted or not) because in summer I have a lot of free time and
> I
> > > can
> > > > work fixing issues or developing new functionalities.
> > > >
> > > > I am very interested in Manifold and I would like to get information
> > > about
> > > > some connectors that could be needed to be implemented.
> > > >
> > > > I really hope participate in Google Summer of Code 2016 and continue
> to
> > > > expand my current technical knowledge.
> > > >
> > > > Yours faithfully,
> > > > David Arroyo
> > > >
> > > > --
> > > > David Arroyo Escobar
> > > >
> > >
> >
>



-- 
David Arroyo Escobar

Re: Gsoc 2016

[Rafa Haro]

Hi Antonio,

After subscribing to Apache's mentors email list, you need to receive the
acknowledge from at least one Apache ManifoldCF PMC member. So, you would
need to write an email similar to this one:

ManifoldCF PMC,

Please acknowledge my request to become a mentor for Google Summer of Code
2016 projects for Apache ManifoldCF

I would like to receive the mentor invite to adperezmora...@gmail.com
I am already signed up on the mentor list.

You can find more information on the process here:
https://community.apache.org/gsoc.html

About the Nuxeo connector as an idea, I would be really interested on this
too. My current company is partially based on Nuxeo, so that would be great
for me also from a personal point of view. Because of that, I could help by
co-mentoring the project. I don't have enough time for mentoring, but I
could act as backup mentor for Antonio

Cheers,
Rafa

On Tue, Mar 15, 2016 at 1:37 PM Antonio David Pérez Morales <
adperezmora...@gmail.com> wrote:

> Hi Karl
>
> Yes, let's wait to see if David would like to implement this new connector
> and in that case prepare and submit a proposal.
> Where do I have to sign up to be a mentor?
>
> For the list ok, I will subscribe after signing up as mentor.
>
> Thanks Karl
>
> Regards
>
> 2016-03-15 13:32 GMT+01:00 Karl Wright <daddy...@gmail.com>:
>
> > Hi Antonio,
> >
> > I think it is perfectly reasonable to build a Nuxeo connector for a GSoC
> > 2016 project.  You'll need to find out if David is interested, and sign
> up
> > to be a mentor, of course.  There's also a mentor list you need to join
> --
> > ment...@apache.org, I think.
> >
> > Thanks!
> > Karl
> >
> >
> > On Tue, Mar 15, 2016 at 8:21 AM, Antonio David Pérez Morales <
> > adperezmora...@gmail.com> wrote:
> >
> > > Hi
> > >
> > > The ideas proposed by Karl are very interesting and are needed to have
> a
> > > more stable version of ManifoldCF in terms of supported connectors.
> > >
> > > Regarding the idea of implement new connectors, I have been working
> > lately
> > > with Nuxeo [1] and I would like to propose it as a potential new
> > connector
> > > to be implemented during this GSoC period.
> > > The idea behind this new connector is to use the Nuxeo REST API [2] to
> > > implement a native connector for Nuxeo.
> > >
> > > Karl, in case you think this is an interesting connector to have, I can
> > > create a new Jira ticket for that and I volunteer to act as mentor of
> > this
> > > possible GSoC project.
> > >
> > > Regards
> > >
> > > [1] http://www.nuxeo.com
> > > [2] https://doc.nuxeo.com/display/NXDOC/REST+API
> > >
> > > 2016-03-15 12:27 GMT+01:00 Karl Wright <daddy...@gmail.com>:
> > >
> > > > Hi David,
> > > >
> > > > Thank you for considering ManifoldCF for your GSoC project.
> > > >
> > > > Most of our potential GSoC projects left over from 2015 involve
> > > connectors
> > > > for proprietary repositories, unfortunately.  These are:
> > > >
> > > > (1) Livelink connector (CONNECTORS-1117) -- need to reimplement using
> > the
> > > > newer REST API
> > > > (2) Finishing off the Alfresco Webscript connector (CONNECTORS-1058)
> --
> > > > need to add the ability to support thread interruptibility
> > > >
> > > > Other projects that have been discussed include working with
> > SharePoint;
> > > > SharePoint has deprecated their web-services API and has instead gone
> > to
> > > a
> > > > REST API, and we'd need a pair of connectors (authority and
> repository)
> > > to
> > > > support that.  That's not properly ticketed in Jira for GSoC yet, and
> > it
> > > > may be too big for one GSoC project, but we can perhaps break it up
> > into
> > > > smaller pieces.
> > > >
> > > > So, if you can show you have access to one of these three proprietary
> > > > repositories for the purposes of development, you could write a
> > proposal
> > > > along those lines.
> > > >
> > > > Alternatively, if you know of any repository that we may not
> currently
> > > have
> > > > a connector for that could prove useful to someone, you could propose
> > > that
> > > > as a project.
> > > >
> > > > We're currently pretty shorthanded when it comes to mentors, so we
> will
> > > > only

Re: Gsoc 2016

[Antonio David Pérez Morales]

Hi Karl

Yes, let's wait to see if David would like to implement this new connector
and in that case prepare and submit a proposal.
Where do I have to sign up to be a mentor?

For the list ok, I will subscribe after signing up as mentor.

Thanks Karl

Regards

2016-03-15 13:32 GMT+01:00 Karl Wright <daddy...@gmail.com>:

> Hi Antonio,
>
> I think it is perfectly reasonable to build a Nuxeo connector for a GSoC
> 2016 project.  You'll need to find out if David is interested, and sign up
> to be a mentor, of course.  There's also a mentor list you need to join --
> ment...@apache.org, I think.
>
> Thanks!
> Karl
>
>
> On Tue, Mar 15, 2016 at 8:21 AM, Antonio David Pérez Morales <
> adperezmora...@gmail.com> wrote:
>
> > Hi
> >
> > The ideas proposed by Karl are very interesting and are needed to have a
> > more stable version of ManifoldCF in terms of supported connectors.
> >
> > Regarding the idea of implement new connectors, I have been working
> lately
> > with Nuxeo [1] and I would like to propose it as a potential new
> connector
> > to be implemented during this GSoC period.
> > The idea behind this new connector is to use the Nuxeo REST API [2] to
> > implement a native connector for Nuxeo.
> >
> > Karl, in case you think this is an interesting connector to have, I can
> > create a new Jira ticket for that and I volunteer to act as mentor of
> this
> > possible GSoC project.
> >
> > Regards
> >
> > [1] http://www.nuxeo.com
> > [2] https://doc.nuxeo.com/display/NXDOC/REST+API
> >
> > 2016-03-15 12:27 GMT+01:00 Karl Wright <daddy...@gmail.com>:
> >
> > > Hi David,
> > >
> > > Thank you for considering ManifoldCF for your GSoC project.
> > >
> > > Most of our potential GSoC projects left over from 2015 involve
> > connectors
> > > for proprietary repositories, unfortunately.  These are:
> > >
> > > (1) Livelink connector (CONNECTORS-1117) -- need to reimplement using
> the
> > > newer REST API
> > > (2) Finishing off the Alfresco Webscript connector (CONNECTORS-1058) --
> > > need to add the ability to support thread interruptibility
> > >
> > > Other projects that have been discussed include working with
> SharePoint;
> > > SharePoint has deprecated their web-services API and has instead gone
> to
> > a
> > > REST API, and we'd need a pair of connectors (authority and repository)
> > to
> > > support that.  That's not properly ticketed in Jira for GSoC yet, and
> it
> > > may be too big for one GSoC project, but we can perhaps break it up
> into
> > > smaller pieces.
> > >
> > > So, if you can show you have access to one of these three proprietary
> > > repositories for the purposes of development, you could write a
> proposal
> > > along those lines.
> > >
> > > Alternatively, if you know of any repository that we may not currently
> > have
> > > a connector for that could prove useful to someone, you could propose
> > that
> > > as a project.
> > >
> > > We're currently pretty shorthanded when it comes to mentors, so we will
> > > only be able to accept one or two proposals at most this year.
> > >
> > > Thanks!
> > > Karl
> > >
> > >
> > > On Tue, Mar 15, 2016 at 6:44 AM, David Arroyo <
> > > arroyoescobarda...@gmail.com>
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > > I am David Arroyo, undergraduate Software Engineer at University of
> > > > Seville, Spain and I am graduate in a Superior Grade Formative Course
> > on
> > > > multi-platform application development.
> > > >
> > > > During last months, I have been following the mailing list and also
> > > > reviewing some open issues (some of them tagged as gsoc gsoc2015). I
> > > would
> > > > be interested to collaborate in this project to get some experience
> > and I
> > > > think GSoC could be an interesting opportunity to learn about open
> > source
> > > > community development, unkown for me so far, and learning a bit more
> > > about
> > > > the technologies used in this project.
> > > >
> > > > My intention is continue collaborating with the project after GSoC
> > (both
> > > if
> > > > I'm accepted or not) because in summer I have a lot of free time and
> I
> > > can
> > > > work fixing issues or developing new functionalities.
> > > >
> > > > I am very interested in Manifold and I would like to get information
> > > about
> > > > some connectors that could be needed to be implemented.
> > > >
> > > > I really hope participate in Google Summer of Code 2016 and continue
> to
> > > > expand my current technical knowledge.
> > > >
> > > > Yours faithfully,
> > > > David Arroyo
> > > >
> > > > --
> > > > David Arroyo Escobar
> > > >
> > >
> >
>

Re: Gsoc 2016

[Karl Wright]

Hi Antonio,

I think it is perfectly reasonable to build a Nuxeo connector for a GSoC
2016 project.  You'll need to find out if David is interested, and sign up
to be a mentor, of course.  There's also a mentor list you need to join --
ment...@apache.org, I think.

Thanks!
Karl


On Tue, Mar 15, 2016 at 8:21 AM, Antonio David Pérez Morales <
adperezmora...@gmail.com> wrote:

> Hi
>
> The ideas proposed by Karl are very interesting and are needed to have a
> more stable version of ManifoldCF in terms of supported connectors.
>
> Regarding the idea of implement new connectors, I have been working lately
> with Nuxeo [1] and I would like to propose it as a potential new connector
> to be implemented during this GSoC period.
> The idea behind this new connector is to use the Nuxeo REST API [2] to
> implement a native connector for Nuxeo.
>
> Karl, in case you think this is an interesting connector to have, I can
> create a new Jira ticket for that and I volunteer to act as mentor of this
> possible GSoC project.
>
> Regards
>
> [1] http://www.nuxeo.com
> [2] https://doc.nuxeo.com/display/NXDOC/REST+API
>
> 2016-03-15 12:27 GMT+01:00 Karl Wright <daddy...@gmail.com>:
>
> > Hi David,
> >
> > Thank you for considering ManifoldCF for your GSoC project.
> >
> > Most of our potential GSoC projects left over from 2015 involve
> connectors
> > for proprietary repositories, unfortunately.  These are:
> >
> > (1) Livelink connector (CONNECTORS-1117) -- need to reimplement using the
> > newer REST API
> > (2) Finishing off the Alfresco Webscript connector (CONNECTORS-1058) --
> > need to add the ability to support thread interruptibility
> >
> > Other projects that have been discussed include working with SharePoint;
> > SharePoint has deprecated their web-services API and has instead gone to
> a
> > REST API, and we'd need a pair of connectors (authority and repository)
> to
> > support that.  That's not properly ticketed in Jira for GSoC yet, and it
> > may be too big for one GSoC project, but we can perhaps break it up into
> > smaller pieces.
> >
> > So, if you can show you have access to one of these three proprietary
> > repositories for the purposes of development, you could write a proposal
> > along those lines.
> >
> > Alternatively, if you know of any repository that we may not currently
> have
> > a connector for that could prove useful to someone, you could propose
> that
> > as a project.
> >
> > We're currently pretty shorthanded when it comes to mentors, so we will
> > only be able to accept one or two proposals at most this year.
> >
> > Thanks!
> > Karl
> >
> >
> > On Tue, Mar 15, 2016 at 6:44 AM, David Arroyo <
> > arroyoescobarda...@gmail.com>
> > wrote:
> >
> > > Hi,
> > >
> > > I am David Arroyo, undergraduate Software Engineer at University of
> > > Seville, Spain and I am graduate in a Superior Grade Formative Course
> on
> > > multi-platform application development.
> > >
> > > During last months, I have been following the mailing list and also
> > > reviewing some open issues (some of them tagged as gsoc gsoc2015). I
> > would
> > > be interested to collaborate in this project to get some experience
> and I
> > > think GSoC could be an interesting opportunity to learn about open
> source
> > > community development, unkown for me so far, and learning a bit more
> > about
> > > the technologies used in this project.
> > >
> > > My intention is continue collaborating with the project after GSoC
> (both
> > if
> > > I'm accepted or not) because in summer I have a lot of free time and I
> > can
> > > work fixing issues or developing new functionalities.
> > >
> > > I am very interested in Manifold and I would like to get information
> > about
> > > some connectors that could be needed to be implemented.
> > >
> > > I really hope participate in Google Summer of Code 2016 and continue to
> > > expand my current technical knowledge.
> > >
> > > Yours faithfully,
> > > David Arroyo
> > >
> > > --
> > > David Arroyo Escobar
> > >
> >
>

Re: Gsoc 2016

[Antonio David Pérez Morales]

Hi

The ideas proposed by Karl are very interesting and are needed to have a
more stable version of ManifoldCF in terms of supported connectors.

Regarding the idea of implement new connectors, I have been working lately
with Nuxeo [1] and I would like to propose it as a potential new connector
to be implemented during this GSoC period.
The idea behind this new connector is to use the Nuxeo REST API [2] to
implement a native connector for Nuxeo.

Karl, in case you think this is an interesting connector to have, I can
create a new Jira ticket for that and I volunteer to act as mentor of this
possible GSoC project.

Regards

[1] http://www.nuxeo.com
[2] https://doc.nuxeo.com/display/NXDOC/REST+API

2016-03-15 12:27 GMT+01:00 Karl Wright <daddy...@gmail.com>:

> Hi David,
>
> Thank you for considering ManifoldCF for your GSoC project.
>
> Most of our potential GSoC projects left over from 2015 involve connectors
> for proprietary repositories, unfortunately.  These are:
>
> (1) Livelink connector (CONNECTORS-1117) -- need to reimplement using the
> newer REST API
> (2) Finishing off the Alfresco Webscript connector (CONNECTORS-1058) --
> need to add the ability to support thread interruptibility
>
> Other projects that have been discussed include working with SharePoint;
> SharePoint has deprecated their web-services API and has instead gone to a
> REST API, and we'd need a pair of connectors (authority and repository) to
> support that.  That's not properly ticketed in Jira for GSoC yet, and it
> may be too big for one GSoC project, but we can perhaps break it up into
> smaller pieces.
>
> So, if you can show you have access to one of these three proprietary
> repositories for the purposes of development, you could write a proposal
> along those lines.
>
> Alternatively, if you know of any repository that we may not currently have
> a connector for that could prove useful to someone, you could propose that
> as a project.
>
> We're currently pretty shorthanded when it comes to mentors, so we will
> only be able to accept one or two proposals at most this year.
>
> Thanks!
> Karl
>
>
> On Tue, Mar 15, 2016 at 6:44 AM, David Arroyo <
> arroyoescobarda...@gmail.com>
> wrote:
>
> > Hi,
> >
> > I am David Arroyo, undergraduate Software Engineer at University of
> > Seville, Spain and I am graduate in a Superior Grade Formative Course on
> > multi-platform application development.
> >
> > During last months, I have been following the mailing list and also
> > reviewing some open issues (some of them tagged as gsoc gsoc2015). I
> would
> > be interested to collaborate in this project to get some experience and I
> > think GSoC could be an interesting opportunity to learn about open source
> > community development, unkown for me so far, and learning a bit more
> about
> > the technologies used in this project.
> >
> > My intention is continue collaborating with the project after GSoC (both
> if
> > I'm accepted or not) because in summer I have a lot of free time and I
> can
> > work fixing issues or developing new functionalities.
> >
> > I am very interested in Manifold and I would like to get information
> about
> > some connectors that could be needed to be implemented.
> >
> > I really hope participate in Google Summer of Code 2016 and continue to
> > expand my current technical knowledge.
> >
> > Yours faithfully,
> > David Arroyo
> >
> > --
> > David Arroyo Escobar
> >
>

Re: Gsoc 2016

[Karl Wright]

Hi David,

Thank you for considering ManifoldCF for your GSoC project.

Most of our potential GSoC projects left over from 2015 involve connectors
for proprietary repositories, unfortunately.  These are:

(1) Livelink connector (CONNECTORS-1117) -- need to reimplement using the
newer REST API
(2) Finishing off the Alfresco Webscript connector (CONNECTORS-1058) --
need to add the ability to support thread interruptibility

Other projects that have been discussed include working with SharePoint;
SharePoint has deprecated their web-services API and has instead gone to a
REST API, and we'd need a pair of connectors (authority and repository) to
support that.  That's not properly ticketed in Jira for GSoC yet, and it
may be too big for one GSoC project, but we can perhaps break it up into
smaller pieces.

So, if you can show you have access to one of these three proprietary
repositories for the purposes of development, you could write a proposal
along those lines.

Alternatively, if you know of any repository that we may not currently have
a connector for that could prove useful to someone, you could propose that
as a project.

We're currently pretty shorthanded when it comes to mentors, so we will
only be able to accept one or two proposals at most this year.

Thanks!
Karl


On Tue, Mar 15, 2016 at 6:44 AM, David Arroyo <arroyoescobarda...@gmail.com>
wrote:

> Hi,
>
> I am David Arroyo, undergraduate Software Engineer at University of
> Seville, Spain and I am graduate in a Superior Grade Formative Course on
> multi-platform application development.
>
> During last months, I have been following the mailing list and also
> reviewing some open issues (some of them tagged as gsoc gsoc2015). I would
> be interested to collaborate in this project to get some experience and I
> think GSoC could be an interesting opportunity to learn about open source
> community development, unkown for me so far, and learning a bit more about
> the technologies used in this project.
>
> My intention is continue collaborating with the project after GSoC (both if
> I'm accepted or not) because in summer I have a lot of free time and I can
> work fixing issues or developing new functionalities.
>
> I am very interested in Manifold and I would like to get information about
> some connectors that could be needed to be implemented.
>
> I really hope participate in Google Summer of Code 2016 and continue to
> expand my current technical knowledge.
>
> Yours faithfully,
> David Arroyo
>
> --
> David Arroyo Escobar
>

Gsoc 2016

[David Arroyo]

Hi,

I am David Arroyo, undergraduate Software Engineer at University of
Seville, Spain and I am graduate in a Superior Grade Formative Course on
multi-platform application development.

During last months, I have been following the mailing list and also
reviewing some open issues (some of them tagged as gsoc gsoc2015). I would
be interested to collaborate in this project to get some experience and I
think GSoC could be an interesting opportunity to learn about open source
community development, unkown for me so far, and learning a bit more about
the technologies used in this project.

My intention is continue collaborating with the project after GSoC (both if
I'm accepted or not) because in summer I have a lot of free time and I can
work fixing issues or developing new functionalities.

I am very interested in Manifold and I would like to get information about
some connectors that could be needed to be implemented.

I really hope participate in Google Summer of Code 2016 and continue to
expand my current technical knowledge.

Yours faithfully,
David Arroyo

-- 
David Arroyo Escobar

Re: [GSOC 2016] Projects and introductory tickets

[Piergiorgio Lucidi]

Hi Bimalsha,

could you please confirm that you can access to an OpenText server for
implementing the new version of LiveLink connector?

Please let us know.
Thank you.

Piergiorgio

2016-03-14 10:23 GMT+01:00 Piergiorgio Lucidi <piergior...@apache.org>:

> Hi Bimalsha,
>
> first thank you very much for contributing on Apache ManifoldCF project
> and thank you for your request for the GSoC program.
>
> I think that we can discuss internally eventual tasks that can be
> implemented by students and then we can return to you for a potential
> confirmation.
>
> We had some opportunities in the past for the GSoC program and I have
> personally followed a student that now works in an Open Source company :)
>
> Piergiorgio
>
> 2016-03-02 6:27 GMT+01:00 Bimalsha Piumi <bimalshapi...@gmail.com>:
>
>> Hi,
>>
>> I am Bimalsha Piumi an Applied Science undergraduate at University of Sri
>> Jayawardenepura Sri Lanka. I already hold a  Bsc(Hons) Firstcalss in Civil
>> and Structural Engineering at Liverpool John Moores University (UK).
>>
>> Software programming and development is my leisure time activity. As I
>> have
>> ended up with my Civil Engineering degree there is plenty of time to
>> programming. Hence I thought about GSoc 2016 this time.
>>
>> I would like to contribute to Manifold project. Are there any connectors
>> (other than the LiveLink Connector) yet to be implemented? What are the
>> other possible projects for 2016?
>>
>> At the moment I am working on [1] getting access to LiveLink server. Will
>> be able to confirm within next three days.
>>
>> I would also like to fix jira issues to have a start. Is there any list of
>> introductory tickets?
>>
>> Would like to work with manifold and hope to get a lot of experience and
>> expose myself opensource community.
>>
>> [1] https://issues.apache.org/jira/browse/CONNECTORS-1117#
>>
>> Thanks & Regards
>>
>> --
>> Bimalsha Piumi
>> BSc (Hons) Civil & Structural Engineering
>> Liverpool John Moores University (UK)
>> BSc (General) Applied Sciences
>> University of Sri Jayewardenepura (SL)
>>
>
>
>
> --
> Piergiorgio Lucidi
> Open Source Tech Master of Enterprise Information Management @ Sourcesense
> Author and Technical Reviewer @ Packt Publishing
> http://www.open4dev.com
>



-- 
Piergiorgio Lucidi
Open Source Tech Master of Enterprise Information Management @ Sourcesense
Author and Technical Reviewer @ Packt Publishing
http://www.open4dev.com

Re: [GSOC 2016] Projects and introductory tickets

[Piergiorgio Lucidi]

Hi Bimalsha,

first thank you very much for contributing on Apache ManifoldCF project and
thank you for your request for the GSoC program.

I think that we can discuss internally eventual tasks that can be
implemented by students and then we can return to you for a potential
confirmation.

We had some opportunities in the past for the GSoC program and I have
personally followed a student that now works in an Open Source company :)

Piergiorgio

2016-03-02 6:27 GMT+01:00 Bimalsha Piumi <bimalshapi...@gmail.com>:

> Hi,
>
> I am Bimalsha Piumi an Applied Science undergraduate at University of Sri
> Jayawardenepura Sri Lanka. I already hold a  Bsc(Hons) Firstcalss in Civil
> and Structural Engineering at Liverpool John Moores University (UK).
>
> Software programming and development is my leisure time activity. As I have
> ended up with my Civil Engineering degree there is plenty of time to
> programming. Hence I thought about GSoc 2016 this time.
>
> I would like to contribute to Manifold project. Are there any connectors
> (other than the LiveLink Connector) yet to be implemented? What are the
> other possible projects for 2016?
>
> At the moment I am working on [1] getting access to LiveLink server. Will
> be able to confirm within next three days.
>
> I would also like to fix jira issues to have a start. Is there any list of
> introductory tickets?
>
> Would like to work with manifold and hope to get a lot of experience and
> expose myself opensource community.
>
> [1] https://issues.apache.org/jira/browse/CONNECTORS-1117#
>
> Thanks & Regards
>
> --
> Bimalsha Piumi
> BSc (Hons) Civil & Structural Engineering
> Liverpool John Moores University (UK)
> BSc (General) Applied Sciences
> University of Sri Jayewardenepura (SL)
>



-- 
Piergiorgio Lucidi
Open Source Tech Master of Enterprise Information Management @ Sourcesense
Author and Technical Reviewer @ Packt Publishing
http://www.open4dev.com

[GSOC 2016] Projects and introductory tickets

[Bimalsha Piumi]

Hi,

I am Bimalsha Piumi an Applied Science undergraduate at University of Sri
Jayawardenepura Sri Lanka. I already hold a  Bsc(Hons) Firstcalss in Civil
and Structural Engineering at Liverpool John Moores University (UK).

Software programming and development is my leisure time activity. As I have
ended up with my Civil Engineering degree there is plenty of time to
programming. Hence I thought about GSoc 2016 this time.

I would like to contribute to Manifold project. Are there any connectors
(other than the LiveLink Connector) yet to be implemented? What are the
other possible projects for 2016?

At the moment I am working on [1] getting access to LiveLink server. Will
be able to confirm within next three days.

I would also like to fix jira issues to have a start. Is there any list of
introductory tickets?

Would like to work with manifold and hope to get a lot of experience and
expose myself opensource community.

[1] https://issues.apache.org/jira/browse/CONNECTORS-1117#

Thanks & Regards

-- 
Bimalsha Piumi
BSc (Hons) Civil & Structural Engineering
Liverpool John Moores University (UK)
BSc (General) Applied Sciences
University of Sri Jayewardenepura (SL)

Re: [GSoC] Confluence Authority Connector

[Antonio David Pérez Morales]

.

   

Karl

   

   

On Tue, Aug 4, 2015 at 1:22 PM, Antonio David Pérez Morales 

adperezmora...@gmail.com wrote:

   

 Hi guys



 Following the work already done in the Confluence connector, I
 have

 developed some tests for the Authority connector and also I have

  fixed

and

 improved the tests related to the repository connector because I

   changed

 the check to know if a document needs to be reindexed or not, so I

  have

 modified the tests accordingly to avoid problems and in order to

  tests

the

 behavior properly.



 Regarding the documentation and after talked with Rafa, I have

  started

with

 the README.md file and I have also put configuration screenshots
 on

  it

 using embedded images (unluckily if you go to GitHub, the embedded

   images

 are not rendered I don't know why, but  using the Markdown content

  in a

 Markdown syntax viewer, the images are properly shown). We have

  agreed

that

 when the connectors are ready to be contributed, then we can port
 the

 documentation to the format expected by Manifold framework.



 As always, if you have any comments or suggestions for
 improvements

  or

new

 requirements, please let me know.



 Regards









 2015-07-25 10:45 GMT+02:00 Rafa Haro rh...@apache.org:



  Hi Antonio,

 

 

  Sorry I have been out for a couple of days, so I couldn't answer

   until

  today.

 

 

 

 

 

 

  —

  Enviado desde Mailbox

 

 

 

  El jueves, 23 de jul de 2015 a las 21:28, Antonio David Pérez

   Morales 

  adperezmora...@gmail.com escribió:

  Hi devs

 

 

  I continue working on the Authority connector for Confluence
 [1].

 

  Basically I'm finishing the tests and doing some improvements. I

   would

 like

 

  to do some UI tests (like Active Directory connector does), so I

  will

try

 

  to include them along with unit tests with mocks.

 

  In parallel, I'm going to start with the documentation to be
 ready

   for

 the

 

  contribution to Manifold.

 

  ​

 

  ​Fine. I will take a look to the GitHub project to check the

   authority

  connector progress. Actually this one should be easier and
 faster

  to

test

  for me.

 

 

 

 

 

 

  Moreover, right now, I keep separated both repository and
 authority

 

  connectors (different modules in the maven project) but once

   finished,

I

 

  think it is better to join them into only one, merging the
 clients

   used

 to

 

  interact with Confluence, and reusing some model classes. I
 will do

   it

as

 

  soon as I finish the tests and some improvements and in parallel

  with

the

 

  documentation.

 

 

 

 

 

  ​

 

  ​Yeah, there are probably some code that could be merged. If the

  configuration is barely the same for both clients, they should
 be

merged

 in

  a single client module. For now, you can keep it at one of the

connectors

  packages and cross the reference in the other one. As soon as
 you

finish

  the authority connector I will take a look to see if we can
 merge

 something

  else.

 

 

 

 

  As always, if you have any suggestions, please let me know and I

  will

try

 

  to include it in the current code.

 

 

  Regards

 

 

  [1]

 

 

 



   

  

 
 https://github.com/adperezmorales/confluence-manifold-connector/tree/develop

 

 

  2015-07-11 12:52 GMT+02:00 Karl Wright daddy...@gmail.com:

 

 

   The feature was developed for a user that was trying to index

documents

 

   by creating multiple XML files, each containing a specific
 set of

 

   documents. But we don't have any supported connectors yet that

  rely

on

 

   this feature.

 

  

 

   Thanks,

 

   Karl

 

  

 

   Sent from my Windows Phone

 

   From: Antonio David Pérez Morales

 

   Sent: 7/11/2015 3:55 AM

 

   To: dev@manifoldcf.apache.org

 

   Subject: Re: [GSoC] Confluence Authority Connector

 

   Hi Karl

 

  

 

   Thanks for your response.

 

  

 

   No, I'm not using document components, so I will change the
 call

  to

 

   checkDocumentNeedsReindexing.

 

  

 

   Only for curiosity, do you have any example showing how to use

document

 

   components with the RepositoryDocument model used in Manifold?

 

  

 

   Regards

Re: [GSoC] Confluence Authority Connector

[Antonio David Pérez Morales]

Hi Karl

After talked with Rafa yesterday, while I'm working on some improvements
and fixes, Rafa is testing the connector against some Confluence instances
(on premise and cloud) to check the connector's behavior.
After that, we can think to merge both connectors into only one project
(right now it is a Maven project with two maven modules, one for repository
connector and one for authority connector) if needed and then move towards
importing it into Apache SVN.

I don't know if I can do that step or else only Manifold committers can do
that. If the second, I can help anyone to move the project into Apache SVN.

Regards



2015-08-04 20:25 GMT+02:00 Karl Wright daddy...@gmail.com:

 If you feel that this connector is largely complete, we can move towards
 importing it into Apache svn.  Please let us know when you are ready.

 Karl


 On Tue, Aug 4, 2015 at 1:22 PM, Antonio David Pérez Morales 
 adperezmora...@gmail.com wrote:

  Hi guys
 
  Following the work already done in the Confluence connector, I have
  developed some tests for the Authority connector and also I have fixed
 and
  improved the tests related to the repository connector because I changed
  the check to know if a document needs to be reindexed or not, so I have
  modified the tests accordingly to avoid problems and in order to tests
 the
  behavior properly.
 
  Regarding the documentation and after talked with Rafa, I have started
 with
  the README.md file and I have also put configuration screenshots on it
  using embedded images (unluckily if you go to GitHub, the embedded images
  are not rendered I don't know why, but  using the Markdown content in a
  Markdown syntax viewer, the images are properly shown). We have agreed
 that
  when the connectors are ready to be contributed, then we can port the
  documentation to the format expected by Manifold framework.
 
  As always, if you have any comments or suggestions for improvements or
 new
  requirements, please let me know.
 
  Regards
 
 
 
 
  2015-07-25 10:45 GMT+02:00 Rafa Haro rh...@apache.org:
 
   Hi Antonio,
  
  
   Sorry I have been out for a couple of days, so I couldn't answer until
   today.
  
  
  
  
  
  
   —
   Enviado desde Mailbox
  
  
  
   El jueves, 23 de jul de 2015 a las 21:28, Antonio David Pérez Morales 
   adperezmora...@gmail.com escribió:
   Hi devs
  
  
   I continue working on the Authority connector for Confluence [1].
  
   Basically I'm finishing the tests and doing some improvements. I would
  like
  
   to do some UI tests (like Active Directory connector does), so I will
 try
  
   to include them along with unit tests with mocks.
  
   In parallel, I'm going to start with the documentation to be ready for
  the
  
   contribution to Manifold.
  
   ​
  
   ​Fine. I will take a look to the GitHub project to check the authority
   connector progress. Actually this one should be easier and faster to
 test
   for me.
  
  
  
  
  
  
   Moreover, right now, I keep separated both repository and authority
  
   connectors (different modules in the maven project) but once finished,
 I
  
   think it is better to join them into only one, merging the clients used
  to
  
   interact with Confluence, and reusing some model classes. I will do it
 as
  
   soon as I finish the tests and some improvements and in parallel with
 the
  
   documentation.
  
  
  
  
  
   ​
  
   ​Yeah, there are probably some code that could be merged. If the
   configuration is barely the same for both clients, they should be
 merged
  in
   a single client module. For now, you can keep it at one of the
 connectors
   packages and cross the reference in the other one. As soon as you
 finish
   the authority connector I will take a look to see if we can merge
  something
   else.
  
  
  
  
   As always, if you have any suggestions, please let me know and I will
 try
  
   to include it in the current code.
  
  
   Regards
  
  
   [1]
  
  
  
 
 https://github.com/adperezmorales/confluence-manifold-connector/tree/develop
  
  
   2015-07-11 12:52 GMT+02:00 Karl Wright daddy...@gmail.com:
  
  
The feature was developed for a user that was trying to index
 documents
  
by creating multiple XML files, each containing a specific set of
  
documents. But we don't have any supported connectors yet that rely
 on
  
this feature.
  
   
  
Thanks,
  
Karl
  
   
  
Sent from my Windows Phone
  
From: Antonio David Pérez Morales
  
Sent: 7/11/2015 3:55 AM
  
To: dev@manifoldcf.apache.org
  
Subject: Re: [GSoC] Confluence Authority Connector
  
Hi Karl
  
   
  
Thanks for your response.
  
   
  
No, I'm not using document components, so I will change the call to
  
checkDocumentNeedsReindexing.
  
   
  
Only for curiosity, do you have any example showing how to use
 document
  
components with the RepositoryDocument model used in Manifold?
  
   
  
Regards
  
   
  
2015-07-11 1:19 GMT+02:00 Karl

Re: [GSoC] Confluence Authority Connector

[Karl Wright]

 of
   
 documents. But we don't have any supported connectors yet that rely
  on
   
 this feature.
   

   
 Thanks,
   
 Karl
   

   
 Sent from my Windows Phone
   
 From: Antonio David Pérez Morales
   
 Sent: 7/11/2015 3:55 AM
   
 To: dev@manifoldcf.apache.org
   
 Subject: Re: [GSoC] Confluence Authority Connector
   
 Hi Karl
   

   
 Thanks for your response.
   

   
 No, I'm not using document components, so I will change the call to
   
 checkDocumentNeedsReindexing.
   

   
 Only for curiosity, do you have any example showing how to use
  document
   
 components with the RepositoryDocument model used in Manifold?
   

   
 Regards
   

   
 2015-07-11 1:19 GMT+02:00 Karl Wright daddy...@gmail.com:
   

   
  bq. Karl one question about repository connector document
  retainment.
I'm
   
  using
   
  the activities.retainAllComponentDocument(docId) method of
   
 IProcessActivity
   
  to retain the document and avoid to be reindexed.
   
 
   
  Hi Antonio,
   
 
   
  checkDocumentNeedsReindexing() is the standard way of determining
   
 whether a
   
  document needs to be reindexed or not.  You can follow the
 template
   
 present
   
  in multiple other connectors that use this method.
   
 
   
  retainAllComponentDocuments() is basically a shorthand way of
determining
   
  the disposition of document components.  I don't believe you even
  use
   
  document components in the confluence connector, although I could
  be
   
 wrong
   
  about that?  In general, if your connector doesn't do anything
 with
   
  components at all, you will not need to call this method.
   
 
   
  Thanks,
   
  Karl
   
 
   
 
   
 
   
 
   
  On Fri, Jul 10, 2015 at 10:43 AM, Antonio David Pérez Morales 
   
  adperezmora...@gmail.com wrote:
   
 
   
   Hi devs
   
  
   
   Continuing with the work, I have developed a first version of
 the
   
   Confluence Authority connector aligned with the ACLs used by
 the
   
  Confluence
   
   Repository Connector.
   
   I have fixed and improved some parts in the repository
 connector
   and
   
   committed the code and also I have updated the Jira issue [1]
 to
   keep
   
  track
   
   of the new additions.
   
   Both branches have been merged into master and I have created a
  new
   
  develop
   
   branch [2] from it, so further improvements and fixes can be
 done
from
   
  this
   
   branch and then merged into master.
   
   Right now, the connectors are in different maven modules and
  maybe
   in
   
 the
   
   future I can merge into one single maven project without
 modules,
   so
   
 that
   
   with one jar file we will have both connectors ready to be used
  in
   
   Manifold.
   
   As of now, I will work in the Authority connector improvements
  and
   
 tests
   
   and also I will do all the things Rafa (or you guys) can report
   
 regarding
   
   the functionality of the connectors.
   
  
   
   Karl one question about repository connector document
 retainment.
   I'm
   
  using
   
   the activities.retainAllComponentDocument(docId) method of
   
  IProcessActivity
   
   to retain the document and avoid to be reindexed.
   
   Rafa, while checking and reviewing the code, noticed that other
   
  connectors
   
   are using the checkDocumentNeedsReindexing(documentIdentifier,
   
   newVersionString) method also from IProcessActivity. I checked
  the
code
   
   from both methods and internally they act differently. Is it
 fine
   to
   
 use
   
   the retainAllComponentDocument or it is better to switch to
   
   checkDocumentNeedsReindexing one?
   
  
   
   As always, if you have suggestions about improvements or more
   things
   
  which
   
   can be done for these connectors, please let me know.
   
  
   
   Regards
   
  
   
   [1] https://issues.apache.org/jira/browse/CONNECTORS-1161
   
   [2]
   
  
   
  
   
 
   

   
  
 
 https://github.com/adperezmorales/confluence-manifold-connector/tree/develop
   
  
   
  
   
   2015-07-09 17:17 GMT+02:00 Rafa Haro rh...@apache.org:
   
  
   
Hi Antonio,
   
   
   
Thanks for the new update. Let me make some comments inline:
   
   
   
On Wed, Jul 8, 2015 at 6:31 PM, Antonio David Pérez Morales 
   
adperezmora...@gmail.com wrote:
   
   
   
 Hi devs
   

   
 After the midterm, I continue with the proposed work and I
already
   
started
   
 to work on the second part of the project, which is the
development

Re: [GSoC] Confluence Authority Connector

[Antonio David Pérez Morales]

 the authority connector I will take a look to see if we can merge
something
 else.




 As always, if you have any suggestions, please let me know and I
 will
   try

 to include it in the current code.


 Regards


 [1]



   
  
 
 https://github.com/adperezmorales/confluence-manifold-connector/tree/develop


 2015-07-11 12:52 GMT+02:00 Karl Wright daddy...@gmail.com:


  The feature was developed for a user that was trying to index
   documents

  by creating multiple XML files, each containing a specific set of

  documents. But we don't have any supported connectors yet that
 rely
   on

  this feature.

 

  Thanks,

  Karl

 

  Sent from my Windows Phone

  From: Antonio David Pérez Morales

  Sent: 7/11/2015 3:55 AM

  To: dev@manifoldcf.apache.org

  Subject: Re: [GSoC] Confluence Authority Connector

  Hi Karl

 

  Thanks for your response.

 

  No, I'm not using document components, so I will change the call
 to

  checkDocumentNeedsReindexing.

 

  Only for curiosity, do you have any example showing how to use
   document

  components with the RepositoryDocument model used in Manifold?

 

  Regards

 

  2015-07-11 1:19 GMT+02:00 Karl Wright daddy...@gmail.com:

 

   bq. Karl one question about repository connector document
   retainment.
 I'm

   using

   the activities.retainAllComponentDocument(docId) method of

  IProcessActivity

   to retain the document and avoid to be reindexed.

  

   Hi Antonio,

  

   checkDocumentNeedsReindexing() is the standard way of
 determining

  whether a

   document needs to be reindexed or not.  You can follow the
  template

  present

   in multiple other connectors that use this method.

  

   retainAllComponentDocuments() is basically a shorthand way of
 determining

   the disposition of document components.  I don't believe you
 even
   use

   document components in the confluence connector, although I
 could
   be

  wrong

   about that?  In general, if your connector doesn't do anything
  with

   components at all, you will not need to call this method.

  

   Thanks,

   Karl

  

  

  

  

   On Fri, Jul 10, 2015 at 10:43 AM, Antonio David Pérez Morales 

   adperezmora...@gmail.com wrote:

  

Hi devs

   

Continuing with the work, I have developed a first version of
  the

Confluence Authority connector aligned with the ACLs used by
  the

   Confluence

Repository Connector.

I have fixed and improved some parts in the repository
  connector
and

committed the code and also I have updated the Jira issue [1]
  to
keep

   track

of the new additions.

Both branches have been merged into master and I have
 created a
   new

   develop

branch [2] from it, so further improvements and fixes can be
  done
 from

   this

branch and then merged into master.

Right now, the connectors are in different maven modules and
   maybe
in

  the

future I can merge into one single maven project without
  modules,
so

  that

with one jar file we will have both connectors ready to be
 used
   in

Manifold.

As of now, I will work in the Authority connector
 improvements
   and

  tests

and also I will do all the things Rafa (or you guys) can
 report

  regarding

the functionality of the connectors.

   

Karl one question about repository connector document
  retainment.
I'm

   using

the activities.retainAllComponentDocument(docId) method of

   IProcessActivity

to retain the document and avoid to be reindexed.

Rafa, while checking and reviewing the code, noticed that
 other

   connectors

are using the
 checkDocumentNeedsReindexing(documentIdentifier,

newVersionString) method also from IProcessActivity. I
 checked
   the
 code

from both methods and internally they act differently. Is it
  fine
to

  use

the retainAllComponentDocument or it is better to switch to

checkDocumentNeedsReindexing one?

   

As always, if you have suggestions about improvements or more
things

   which

can be done

Re: [GSoC] Confluence Authority Connector

[Rafa Haro]

 to do some UI tests (like Active Directory connector does), so I

 will

   try



 to include them along with unit tests with mocks.



 In parallel, I'm going to start with the documentation to be ready

  for

the



 contribution to Manifold.



 ​



 ​Fine. I will take a look to the GitHub project to check the

  authority

 connector progress. Actually this one should be easier and faster

 to

   test

 for me.













 Moreover, right now, I keep separated both repository and authority



 connectors (different modules in the maven project) but once

  finished,

   I



 think it is better to join them into only one, merging the clients

  used

to



 interact with Confluence, and reusing some model classes. I will do

  it

   as



 soon as I finish the tests and some improvements and in parallel

 with

   the



 documentation.











 ​



 ​Yeah, there are probably some code that could be merged. If the

 configuration is barely the same for both clients, they should be

   merged

in

 a single client module. For now, you can keep it at one of the

   connectors

 packages and cross the reference in the other one. As soon as you

   finish

 the authority connector I will take a look to see if we can merge

something

 else.









 As always, if you have any suggestions, please let me know and I

 will

   try



 to include it in the current code.





 Regards





 [1]







   

  

 

 https://github.com/adperezmorales/confluence-manifold-connector/tree/develop





 2015-07-11 12:52 GMT+02:00 Karl Wright daddy...@gmail.com:





  The feature was developed for a user that was trying to index

   documents



  by creating multiple XML files, each containing a specific set of



  documents. But we don't have any supported connectors yet that

 rely

   on



  this feature.



 



  Thanks,



  Karl



 



  Sent from my Windows Phone



  From: Antonio David Pérez Morales



  Sent: 7/11/2015 3:55 AM



  To: dev@manifoldcf.apache.org



  Subject: Re: [GSoC] Confluence Authority Connector



  Hi Karl



 



  Thanks for your response.



 



  No, I'm not using document components, so I will change the call

 to



  checkDocumentNeedsReindexing.



 



  Only for curiosity, do you have any example showing how to use

   document



  components with the RepositoryDocument model used in Manifold?



 



  Regards



 



  2015-07-11 1:19 GMT+02:00 Karl Wright daddy...@gmail.com:



 



   bq. Karl one question about repository connector document

   retainment.

 I'm



   using



   the activities.retainAllComponentDocument(docId) method of



  IProcessActivity



   to retain the document and avoid to be reindexed.



  



   Hi Antonio,



  



   checkDocumentNeedsReindexing() is the standard way of

 determining



  whether a



   document needs to be reindexed or not.  You can follow the

  template



  present



   in multiple other connectors that use this method.



  



   retainAllComponentDocuments() is basically a shorthand way of

 determining



   the disposition of document components.  I don't believe you

 even

   use



   document components in the confluence connector, although I

 could

   be



  wrong



   about that?  In general, if your connector doesn't do anything

  with



   components at all, you will not need to call this method.



  



   Thanks,



   Karl



  



  



  



  



   On Fri, Jul 10, 2015 at 10:43 AM, Antonio David Pérez Morales 



   adperezmora...@gmail.com wrote:



  



Hi devs



   



Continuing with the work, I have developed a first version of

  the



Confluence Authority connector aligned with the ACLs used by

  the



   Confluence



Repository Connector.



I have fixed and improved some parts in the repository

  connector

and



committed the code and also I have updated the Jira issue [1]

  to

keep



   track



of the new additions.



Both branches have been merged into master and I have

 created a

   new



   develop



branch [2] from it, so further improvements and fixes can be

  done

 from

Re: [GSoC] Confluence Authority Connector

[Antonio David Pérez Morales]

Hi guys

Following the work already done in the Confluence connector, I have
developed some tests for the Authority connector and also I have fixed and
improved the tests related to the repository connector because I changed
the check to know if a document needs to be reindexed or not, so I have
modified the tests accordingly to avoid problems and in order to tests the
behavior properly.

Regarding the documentation and after talked with Rafa, I have started with
the README.md file and I have also put configuration screenshots on it
using embedded images (unluckily if you go to GitHub, the embedded images
are not rendered I don't know why, but  using the Markdown content in a
Markdown syntax viewer, the images are properly shown). We have agreed that
when the connectors are ready to be contributed, then we can port the
documentation to the format expected by Manifold framework.

As always, if you have any comments or suggestions for improvements or new
requirements, please let me know.

Regards




2015-07-25 10:45 GMT+02:00 Rafa Haro rh...@apache.org:

 Hi Antonio,


 Sorry I have been out for a couple of days, so I couldn't answer until
 today.






 —
 Enviado desde Mailbox



 El jueves, 23 de jul de 2015 a las 21:28, Antonio David Pérez Morales 
 adperezmora...@gmail.com escribió:
 Hi devs


 I continue working on the Authority connector for Confluence [1].

 Basically I'm finishing the tests and doing some improvements. I would like

 to do some UI tests (like Active Directory connector does), so I will try

 to include them along with unit tests with mocks.

 In parallel, I'm going to start with the documentation to be ready for the

 contribution to Manifold.

 ​

 ​Fine. I will take a look to the GitHub project to check the authority
 connector progress. Actually this one should be easier and faster to test
 for me.






 Moreover, right now, I keep separated both repository and authority

 connectors (different modules in the maven project) but once finished, I

 think it is better to join them into only one, merging the clients used to

 interact with Confluence, and reusing some model classes. I will do it as

 soon as I finish the tests and some improvements and in parallel with the

 documentation.





 ​

 ​Yeah, there are probably some code that could be merged. If the
 configuration is barely the same for both clients, they should be merged in
 a single client module. For now, you can keep it at one of the connectors
 packages and cross the reference in the other one. As soon as you finish
 the authority connector I will take a look to see if we can merge something
 else.




 As always, if you have any suggestions, please let me know and I will try

 to include it in the current code.


 Regards


 [1]


 https://github.com/adperezmorales/confluence-manifold-connector/tree/develop


 2015-07-11 12:52 GMT+02:00 Karl Wright daddy...@gmail.com:


  The feature was developed for a user that was trying to index documents

  by creating multiple XML files, each containing a specific set of

  documents. But we don't have any supported connectors yet that rely on

  this feature.

 

  Thanks,

  Karl

 

  Sent from my Windows Phone

  From: Antonio David Pérez Morales

  Sent: 7/11/2015 3:55 AM

  To: dev@manifoldcf.apache.org

  Subject: Re: [GSoC] Confluence Authority Connector

  Hi Karl

 

  Thanks for your response.

 

  No, I'm not using document components, so I will change the call to

  checkDocumentNeedsReindexing.

 

  Only for curiosity, do you have any example showing how to use document

  components with the RepositoryDocument model used in Manifold?

 

  Regards

 

  2015-07-11 1:19 GMT+02:00 Karl Wright daddy...@gmail.com:

 

   bq. Karl one question about repository connector document retainment.
 I'm

   using

   the activities.retainAllComponentDocument(docId) method of

  IProcessActivity

   to retain the document and avoid to be reindexed.

  

   Hi Antonio,

  

   checkDocumentNeedsReindexing() is the standard way of determining

  whether a

   document needs to be reindexed or not.  You can follow the template

  present

   in multiple other connectors that use this method.

  

   retainAllComponentDocuments() is basically a shorthand way of
 determining

   the disposition of document components.  I don't believe you even use

   document components in the confluence connector, although I could be

  wrong

   about that?  In general, if your connector doesn't do anything with

   components at all, you will not need to call this method.

  

   Thanks,

   Karl

  

  

  

  

   On Fri, Jul 10, 2015 at 10:43 AM, Antonio David Pérez Morales 

   adperezmora...@gmail.com wrote:

  

Hi devs

   

Continuing with the work, I have developed a first version of the

Confluence Authority connector aligned with the ACLs used by the

   Confluence

Repository Connector.

I have fixed and improved some parts in the repository connector

Re: [GSoC] Confluence Authority Connector

[Karl Wright]

If you feel that this connector is largely complete, we can move towards
importing it into Apache svn.  Please let us know when you are ready.

Karl


On Tue, Aug 4, 2015 at 1:22 PM, Antonio David Pérez Morales 
adperezmora...@gmail.com wrote:

 Hi guys

 Following the work already done in the Confluence connector, I have
 developed some tests for the Authority connector and also I have fixed and
 improved the tests related to the repository connector because I changed
 the check to know if a document needs to be reindexed or not, so I have
 modified the tests accordingly to avoid problems and in order to tests the
 behavior properly.

 Regarding the documentation and after talked with Rafa, I have started with
 the README.md file and I have also put configuration screenshots on it
 using embedded images (unluckily if you go to GitHub, the embedded images
 are not rendered I don't know why, but  using the Markdown content in a
 Markdown syntax viewer, the images are properly shown). We have agreed that
 when the connectors are ready to be contributed, then we can port the
 documentation to the format expected by Manifold framework.

 As always, if you have any comments or suggestions for improvements or new
 requirements, please let me know.

 Regards




 2015-07-25 10:45 GMT+02:00 Rafa Haro rh...@apache.org:

  Hi Antonio,
 
 
  Sorry I have been out for a couple of days, so I couldn't answer until
  today.
 
 
 
 
 
 
  —
  Enviado desde Mailbox
 
 
 
  El jueves, 23 de jul de 2015 a las 21:28, Antonio David Pérez Morales 
  adperezmora...@gmail.com escribió:
  Hi devs
 
 
  I continue working on the Authority connector for Confluence [1].
 
  Basically I'm finishing the tests and doing some improvements. I would
 like
 
  to do some UI tests (like Active Directory connector does), so I will try
 
  to include them along with unit tests with mocks.
 
  In parallel, I'm going to start with the documentation to be ready for
 the
 
  contribution to Manifold.
 
  ​
 
  ​Fine. I will take a look to the GitHub project to check the authority
  connector progress. Actually this one should be easier and faster to test
  for me.
 
 
 
 
 
 
  Moreover, right now, I keep separated both repository and authority
 
  connectors (different modules in the maven project) but once finished, I
 
  think it is better to join them into only one, merging the clients used
 to
 
  interact with Confluence, and reusing some model classes. I will do it as
 
  soon as I finish the tests and some improvements and in parallel with the
 
  documentation.
 
 
 
 
 
  ​
 
  ​Yeah, there are probably some code that could be merged. If the
  configuration is barely the same for both clients, they should be merged
 in
  a single client module. For now, you can keep it at one of the connectors
  packages and cross the reference in the other one. As soon as you finish
  the authority connector I will take a look to see if we can merge
 something
  else.
 
 
 
 
  As always, if you have any suggestions, please let me know and I will try
 
  to include it in the current code.
 
 
  Regards
 
 
  [1]
 
 
 
 https://github.com/adperezmorales/confluence-manifold-connector/tree/develop
 
 
  2015-07-11 12:52 GMT+02:00 Karl Wright daddy...@gmail.com:
 
 
   The feature was developed for a user that was trying to index documents
 
   by creating multiple XML files, each containing a specific set of
 
   documents. But we don't have any supported connectors yet that rely on
 
   this feature.
 
  
 
   Thanks,
 
   Karl
 
  
 
   Sent from my Windows Phone
 
   From: Antonio David Pérez Morales
 
   Sent: 7/11/2015 3:55 AM
 
   To: dev@manifoldcf.apache.org
 
   Subject: Re: [GSoC] Confluence Authority Connector
 
   Hi Karl
 
  
 
   Thanks for your response.
 
  
 
   No, I'm not using document components, so I will change the call to
 
   checkDocumentNeedsReindexing.
 
  
 
   Only for curiosity, do you have any example showing how to use document
 
   components with the RepositoryDocument model used in Manifold?
 
  
 
   Regards
 
  
 
   2015-07-11 1:19 GMT+02:00 Karl Wright daddy...@gmail.com:
 
  
 
bq. Karl one question about repository connector document retainment.
  I'm
 
using
 
the activities.retainAllComponentDocument(docId) method of
 
   IProcessActivity
 
to retain the document and avoid to be reindexed.
 
   
 
Hi Antonio,
 
   
 
checkDocumentNeedsReindexing() is the standard way of determining
 
   whether a
 
document needs to be reindexed or not.  You can follow the template
 
   present
 
in multiple other connectors that use this method.
 
   
 
retainAllComponentDocuments() is basically a shorthand way of
  determining
 
the disposition of document components.  I don't believe you even use
 
document components in the confluence connector, although I could be
 
   wrong
 
about that?  In general, if your connector doesn't do anything with
 
components at all, you

Re: [GSoC] Confluence Authority Connector

[Rafa Haro]

Hi Antonio,


Sorry I have been out for a couple of days, so I couldn't answer until today.






—
Enviado desde Mailbox



El jueves, 23 de jul de 2015 a las 21:28, Antonio David Pérez Morales 
adperezmora...@gmail.com escribió:
Hi devs


I continue working on the Authority connector for Confluence [1].

Basically I'm finishing the tests and doing some improvements. I would like

to do some UI tests (like Active Directory connector does), so I will try

to include them along with unit tests with mocks.

In parallel, I'm going to start with the documentation to be ready for the

contribution to Manifold. 

​

​Fine. I will take a look to the GitHub project to check the authority 
connector progress. Actually this one should be easier and faster to test for 
me.






Moreover, right now, I keep separated both repository and authority

connectors (different modules in the maven project) but once finished, I

think it is better to join them into only one, merging the clients used to

interact with Confluence, and reusing some model classes. I will do it as

soon as I finish the tests and some improvements and in parallel with the

documentation. 





​

​Yeah, there are probably some code that could be merged. If the configuration 
is barely the same for both clients, they should be merged in a single client 
module. For now, you can keep it at one of the connectors packages and cross 
the reference in the other one. As soon as you finish the authority connector I 
will take a look to see if we can merge something else.




As always, if you have any suggestions, please let me know and I will try

to include it in the current code.


Regards


[1]

https://github.com/adperezmorales/confluence-manifold-connector/tree/develop


2015-07-11 12:52 GMT+02:00 Karl Wright daddy...@gmail.com:


 The feature was developed for a user that was trying to index documents

 by creating multiple XML files, each containing a specific set of

 documents. But we don't have any supported connectors yet that rely on

 this feature.



 Thanks,

 Karl



 Sent from my Windows Phone

 From: Antonio David Pérez Morales

 Sent: 7/11/2015 3:55 AM

 To: dev@manifoldcf.apache.org

 Subject: Re: [GSoC] Confluence Authority Connector

 Hi Karl



 Thanks for your response.



 No, I'm not using document components, so I will change the call to

 checkDocumentNeedsReindexing.



 Only for curiosity, do you have any example showing how to use document

 components with the RepositoryDocument model used in Manifold?



 Regards



 2015-07-11 1:19 GMT+02:00 Karl Wright daddy...@gmail.com:



  bq. Karl one question about repository connector document retainment. I'm

  using

  the activities.retainAllComponentDocument(docId) method of

 IProcessActivity

  to retain the document and avoid to be reindexed.

 

  Hi Antonio,

 

  checkDocumentNeedsReindexing() is the standard way of determining

 whether a

  document needs to be reindexed or not.  You can follow the template

 present

  in multiple other connectors that use this method.

 

  retainAllComponentDocuments() is basically a shorthand way of determining

  the disposition of document components.  I don't believe you even use

  document components in the confluence connector, although I could be

 wrong

  about that?  In general, if your connector doesn't do anything with

  components at all, you will not need to call this method.

 

  Thanks,

  Karl

 

 

 

 

  On Fri, Jul 10, 2015 at 10:43 AM, Antonio David Pérez Morales 

  adperezmora...@gmail.com wrote:

 

   Hi devs

  

   Continuing with the work, I have developed a first version of the

   Confluence Authority connector aligned with the ACLs used by the

  Confluence

   Repository Connector.

   I have fixed and improved some parts in the repository connector and

   committed the code and also I have updated the Jira issue [1] to keep

  track

   of the new additions.

   Both branches have been merged into master and I have created a new

  develop

   branch [2] from it, so further improvements and fixes can be done from

  this

   branch and then merged into master.

   Right now, the connectors are in different maven modules and maybe in

 the

   future I can merge into one single maven project without modules, so

 that

   with one jar file we will have both connectors ready to be used in

   Manifold.

   As of now, I will work in the Authority connector improvements and

 tests

   and also I will do all the things Rafa (or you guys) can report

 regarding

   the functionality of the connectors.

  

   Karl one question about repository connector document retainment. I'm

  using

   the activities.retainAllComponentDocument(docId) method of

  IProcessActivity

   to retain the document and avoid to be reindexed.

   Rafa, while checking and reviewing the code, noticed that other

  connectors

   are using the checkDocumentNeedsReindexing(documentIdentifier,

   newVersionString) method

Re: [GSoC] Confluence Authority Connector

[Antonio David Pérez Morales]

Hi devs

I continue working on the Authority connector for Confluence [1].
Basically I'm finishing the tests and doing some improvements. I would like
to do some UI tests (like Active Directory connector does), so I will try
to include them along with unit tests with mocks.
In parallel, I'm going to start with the documentation to be ready for the
contribution to Manifold.

Moreover, right now, I keep separated both repository and authority
connectors (different modules in the maven project) but once finished, I
think it is better to join them into only one, merging the clients used to
interact with Confluence, and reusing some model classes. I will do it as
soon as I finish the tests and some improvements and in parallel with the
documentation.

As always, if you have any suggestions, please let me know and I will try
to include it in the current code.

Regards

[1]
https://github.com/adperezmorales/confluence-manifold-connector/tree/develop

2015-07-11 12:52 GMT+02:00 Karl Wright daddy...@gmail.com:

 The feature was developed for a user that was trying to index documents
 by creating multiple XML files, each containing a specific set of
 documents. But we don't have any supported connectors yet that rely on
 this feature.

 Thanks,
 Karl

 Sent from my Windows Phone
 From: Antonio David Pérez Morales
 Sent: 7/11/2015 3:55 AM
 To: dev@manifoldcf.apache.org
 Subject: Re: [GSoC] Confluence Authority Connector
 Hi Karl

 Thanks for your response.

 No, I'm not using document components, so I will change the call to
 checkDocumentNeedsReindexing.

 Only for curiosity, do you have any example showing how to use document
 components with the RepositoryDocument model used in Manifold?

 Regards

 2015-07-11 1:19 GMT+02:00 Karl Wright daddy...@gmail.com:

  bq. Karl one question about repository connector document retainment. I'm
  using
  the activities.retainAllComponentDocument(docId) method of
 IProcessActivity
  to retain the document and avoid to be reindexed.
 
  Hi Antonio,
 
  checkDocumentNeedsReindexing() is the standard way of determining
 whether a
  document needs to be reindexed or not.  You can follow the template
 present
  in multiple other connectors that use this method.
 
  retainAllComponentDocuments() is basically a shorthand way of determining
  the disposition of document components.  I don't believe you even use
  document components in the confluence connector, although I could be
 wrong
  about that?  In general, if your connector doesn't do anything with
  components at all, you will not need to call this method.
 
  Thanks,
  Karl
 
 
 
 
  On Fri, Jul 10, 2015 at 10:43 AM, Antonio David Pérez Morales 
  adperezmora...@gmail.com wrote:
 
   Hi devs
  
   Continuing with the work, I have developed a first version of the
   Confluence Authority connector aligned with the ACLs used by the
  Confluence
   Repository Connector.
   I have fixed and improved some parts in the repository connector and
   committed the code and also I have updated the Jira issue [1] to keep
  track
   of the new additions.
   Both branches have been merged into master and I have created a new
  develop
   branch [2] from it, so further improvements and fixes can be done from
  this
   branch and then merged into master.
   Right now, the connectors are in different maven modules and maybe in
 the
   future I can merge into one single maven project without modules, so
 that
   with one jar file we will have both connectors ready to be used in
   Manifold.
   As of now, I will work in the Authority connector improvements and
 tests
   and also I will do all the things Rafa (or you guys) can report
 regarding
   the functionality of the connectors.
  
   Karl one question about repository connector document retainment. I'm
  using
   the activities.retainAllComponentDocument(docId) method of
  IProcessActivity
   to retain the document and avoid to be reindexed.
   Rafa, while checking and reviewing the code, noticed that other
  connectors
   are using the checkDocumentNeedsReindexing(documentIdentifier,
   newVersionString) method also from IProcessActivity. I checked the code
   from both methods and internally they act differently. Is it fine to
 use
   the retainAllComponentDocument or it is better to switch to
   checkDocumentNeedsReindexing one?
  
   As always, if you have suggestions about improvements or more things
  which
   can be done for these connectors, please let me know.
  
   Regards
  
   [1] https://issues.apache.org/jira/browse/CONNECTORS-1161
   [2]
  
  
 
 https://github.com/adperezmorales/confluence-manifold-connector/tree/develop
  
  
   2015-07-09 17:17 GMT+02:00 Rafa Haro rh...@apache.org:
  
Hi Antonio,
   
Thanks for the new update. Let me make some comments inline:
   
On Wed, Jul 8, 2015 at 6:31 PM, Antonio David Pérez Morales 
adperezmora...@gmail.com wrote:
   
 Hi devs

 After the midterm, I continue with the proposed work and I already

RE: [GSoC] Confluence Authority Connector

[Karl Wright]

The feature was developed for a user that was trying to index documents
by creating multiple XML files, each containing a specific set of
documents. But we don't have any supported connectors yet that rely on
this feature.

Thanks,
Karl

Sent from my Windows Phone
From: Antonio David Pérez Morales
Sent: 7/11/2015 3:55 AM
To: dev@manifoldcf.apache.org
Subject: Re: [GSoC] Confluence Authority Connector
Hi Karl

Thanks for your response.

No, I'm not using document components, so I will change the call to
checkDocumentNeedsReindexing.

Only for curiosity, do you have any example showing how to use document
components with the RepositoryDocument model used in Manifold?

Regards

2015-07-11 1:19 GMT+02:00 Karl Wright daddy...@gmail.com:

 bq. Karl one question about repository connector document retainment. I'm
 using
 the activities.retainAllComponentDocument(docId) method of IProcessActivity
 to retain the document and avoid to be reindexed.

 Hi Antonio,

 checkDocumentNeedsReindexing() is the standard way of determining whether a
 document needs to be reindexed or not.  You can follow the template present
 in multiple other connectors that use this method.

 retainAllComponentDocuments() is basically a shorthand way of determining
 the disposition of document components.  I don't believe you even use
 document components in the confluence connector, although I could be wrong
 about that?  In general, if your connector doesn't do anything with
 components at all, you will not need to call this method.

 Thanks,
 Karl




 On Fri, Jul 10, 2015 at 10:43 AM, Antonio David Pérez Morales 
 adperezmora...@gmail.com wrote:

  Hi devs
 
  Continuing with the work, I have developed a first version of the
  Confluence Authority connector aligned with the ACLs used by the
 Confluence
  Repository Connector.
  I have fixed and improved some parts in the repository connector and
  committed the code and also I have updated the Jira issue [1] to keep
 track
  of the new additions.
  Both branches have been merged into master and I have created a new
 develop
  branch [2] from it, so further improvements and fixes can be done from
 this
  branch and then merged into master.
  Right now, the connectors are in different maven modules and maybe in the
  future I can merge into one single maven project without modules, so that
  with one jar file we will have both connectors ready to be used in
  Manifold.
  As of now, I will work in the Authority connector improvements and tests
  and also I will do all the things Rafa (or you guys) can report regarding
  the functionality of the connectors.
 
  Karl one question about repository connector document retainment. I'm
 using
  the activities.retainAllComponentDocument(docId) method of
 IProcessActivity
  to retain the document and avoid to be reindexed.
  Rafa, while checking and reviewing the code, noticed that other
 connectors
  are using the checkDocumentNeedsReindexing(documentIdentifier,
  newVersionString) method also from IProcessActivity. I checked the code
  from both methods and internally they act differently. Is it fine to use
  the retainAllComponentDocument or it is better to switch to
  checkDocumentNeedsReindexing one?
 
  As always, if you have suggestions about improvements or more things
 which
  can be done for these connectors, please let me know.
 
  Regards
 
  [1] https://issues.apache.org/jira/browse/CONNECTORS-1161
  [2]
 
 
 https://github.com/adperezmorales/confluence-manifold-connector/tree/develop
 
 
  2015-07-09 17:17 GMT+02:00 Rafa Haro rh...@apache.org:
 
   Hi Antonio,
  
   Thanks for the new update. Let me make some comments inline:
  
   On Wed, Jul 8, 2015 at 6:31 PM, Antonio David Pérez Morales 
   adperezmora...@gmail.com wrote:
  
Hi devs
   
After the midterm, I continue with the proposed work and I already
   started
to work on the second part of the project, which is the development
 of
  an
Authority Connector for Confluence.
   
I have created a new branch [1] for that in my GitHub account and I
   already
committed the basic structure of the connector along with the code
   related
to Confluence instance configuration. After that I will develop the
   proper
strategy to get the ACLs for the user as stated in the proposal.
   
For this case, I have been evaluating the two scenarios contained in
  the
proposal and I will start developing the space-based permissions
 which
requires no customizations of Confluence instance (coarse grain).
   
I made some tests with Confluence APIs trying to go more fine-grain
  using
the user groups but there is not endpoint method to get the groups
 that
   can
view a specific page. So in the end, I think the space-based
 permission
   is
a good solution, because implementing a Confluence plugin for that to
   cover
some very specific use cases I think most people won't be willing to
   patch
Confluence only for those specific use

Re: [GSoC] Confluence Authority Connector

[Antonio David Pérez Morales]

Hi Karl

Thanks for your response.

No, I'm not using document components, so I will change the call to
checkDocumentNeedsReindexing.

Only for curiosity, do you have any example showing how to use document
components with the RepositoryDocument model used in Manifold?

Regards

2015-07-11 1:19 GMT+02:00 Karl Wright daddy...@gmail.com:

 bq. Karl one question about repository connector document retainment. I'm
 using
 the activities.retainAllComponentDocument(docId) method of IProcessActivity
 to retain the document and avoid to be reindexed.

 Hi Antonio,

 checkDocumentNeedsReindexing() is the standard way of determining whether a
 document needs to be reindexed or not.  You can follow the template present
 in multiple other connectors that use this method.

 retainAllComponentDocuments() is basically a shorthand way of determining
 the disposition of document components.  I don't believe you even use
 document components in the confluence connector, although I could be wrong
 about that?  In general, if your connector doesn't do anything with
 components at all, you will not need to call this method.

 Thanks,
 Karl




 On Fri, Jul 10, 2015 at 10:43 AM, Antonio David Pérez Morales 
 adperezmora...@gmail.com wrote:

  Hi devs
 
  Continuing with the work, I have developed a first version of the
  Confluence Authority connector aligned with the ACLs used by the
 Confluence
  Repository Connector.
  I have fixed and improved some parts in the repository connector and
  committed the code and also I have updated the Jira issue [1] to keep
 track
  of the new additions.
  Both branches have been merged into master and I have created a new
 develop
  branch [2] from it, so further improvements and fixes can be done from
 this
  branch and then merged into master.
  Right now, the connectors are in different maven modules and maybe in the
  future I can merge into one single maven project without modules, so that
  with one jar file we will have both connectors ready to be used in
  Manifold.
  As of now, I will work in the Authority connector improvements and tests
  and also I will do all the things Rafa (or you guys) can report regarding
  the functionality of the connectors.
 
  Karl one question about repository connector document retainment. I'm
 using
  the activities.retainAllComponentDocument(docId) method of
 IProcessActivity
  to retain the document and avoid to be reindexed.
  Rafa, while checking and reviewing the code, noticed that other
 connectors
  are using the checkDocumentNeedsReindexing(documentIdentifier,
  newVersionString) method also from IProcessActivity. I checked the code
  from both methods and internally they act differently. Is it fine to use
  the retainAllComponentDocument or it is better to switch to
  checkDocumentNeedsReindexing one?
 
  As always, if you have suggestions about improvements or more things
 which
  can be done for these connectors, please let me know.
 
  Regards
 
  [1] https://issues.apache.org/jira/browse/CONNECTORS-1161
  [2]
 
 
 https://github.com/adperezmorales/confluence-manifold-connector/tree/develop
 
 
  2015-07-09 17:17 GMT+02:00 Rafa Haro rh...@apache.org:
 
   Hi Antonio,
  
   Thanks for the new update. Let me make some comments inline:
  
   On Wed, Jul 8, 2015 at 6:31 PM, Antonio David Pérez Morales 
   adperezmora...@gmail.com wrote:
  
Hi devs
   
After the midterm, I continue with the proposed work and I already
   started
to work on the second part of the project, which is the development
 of
  an
Authority Connector for Confluence.
   
I have created a new branch [1] for that in my GitHub account and I
   already
committed the basic structure of the connector along with the code
   related
to Confluence instance configuration. After that I will develop the
   proper
strategy to get the ACLs for the user as stated in the proposal.
   
For this case, I have been evaluating the two scenarios contained in
  the
proposal and I will start developing the space-based permissions
 which
requires no customizations of Confluence instance (coarse grain).
   
I made some tests with Confluence APIs trying to go more fine-grain
  using
the user groups but there is not endpoint method to get the groups
 that
   can
view a specific page. So in the end, I think the space-based
 permission
   is
a good solution, because implementing a Confluence plugin for that to
   cover
some very specific use cases I think most people won't be willing to
   patch
Confluence only for those specific use cases (for example where a
  person
   is
not allowed to view a space but it is allowed to view a single page
 in
   that
space).
   
  
   Let's focus right now on permissions at space level. As you said, to
  patch
   confluence API is not  a good solution, specially for those using it in
  the
   Cloud. If in the future they extend the API with more fine grained
   permissions approach, we 

Re: [GSoC] Confluence Authority Connector

[Antonio David Pérez Morales]

Hi devs

Continuing with the work, I have developed a first version of the
Confluence Authority connector aligned with the ACLs used by the Confluence
Repository Connector.
I have fixed and improved some parts in the repository connector and
committed the code and also I have updated the Jira issue [1] to keep track
of the new additions.
Both branches have been merged into master and I have created a new develop
branch [2] from it, so further improvements and fixes can be done from this
branch and then merged into master.
Right now, the connectors are in different maven modules and maybe in the
future I can merge into one single maven project without modules, so that
with one jar file we will have both connectors ready to be used in Manifold.
As of now, I will work in the Authority connector improvements and tests
and also I will do all the things Rafa (or you guys) can report regarding
the functionality of the connectors.

Karl one question about repository connector document retainment. I'm using
the activities.retainAllComponentDocument(docId) method of IProcessActivity
to retain the document and avoid to be reindexed.
Rafa, while checking and reviewing the code, noticed that other connectors
are using the checkDocumentNeedsReindexing(documentIdentifier,
newVersionString) method also from IProcessActivity. I checked the code
from both methods and internally they act differently. Is it fine to use
the retainAllComponentDocument or it is better to switch to
checkDocumentNeedsReindexing one?

As always, if you have suggestions about improvements or more things which
can be done for these connectors, please let me know.

Regards

[1] https://issues.apache.org/jira/browse/CONNECTORS-1161
[2]
https://github.com/adperezmorales/confluence-manifold-connector/tree/develop


2015-07-09 17:17 GMT+02:00 Rafa Haro rh...@apache.org:

 Hi Antonio,

 Thanks for the new update. Let me make some comments inline:

 On Wed, Jul 8, 2015 at 6:31 PM, Antonio David Pérez Morales 
 adperezmora...@gmail.com wrote:

  Hi devs
 
  After the midterm, I continue with the proposed work and I already
 started
  to work on the second part of the project, which is the development of an
  Authority Connector for Confluence.
 
  I have created a new branch [1] for that in my GitHub account and I
 already
  committed the basic structure of the connector along with the code
 related
  to Confluence instance configuration. After that I will develop the
 proper
  strategy to get the ACLs for the user as stated in the proposal.
 
  For this case, I have been evaluating the two scenarios contained in the
  proposal and I will start developing the space-based permissions which
  requires no customizations of Confluence instance (coarse grain).
 
  I made some tests with Confluence APIs trying to go more fine-grain using
  the user groups but there is not endpoint method to get the groups that
 can
  view a specific page. So in the end, I think the space-based permission
 is
  a good solution, because implementing a Confluence plugin for that to
 cover
  some very specific use cases I think most people won't be willing to
 patch
  Confluence only for those specific use cases (for example where a person
 is
  not allowed to view a space but it is allowed to view a single page in
 that
  space).
 

 Let's focus right now on permissions at space level. As you said, to patch
 confluence API is not  a good solution, specially for those using it in the
 Cloud. If in the future they extend the API with more fine grained
 permissions approach, we can always update later the connector.


 
  I have also updated the README file putting a guide to configure both
  connectors using screenshots about configuration tabs for the connectors.
  I'm using embedded images (using Data URIs syntax for images) but it
 seems
  they are not supported by GitHub in the README (although they are in the
  code, and other Markdown viewers can show them).
 

 Ok, thanks!


 
  The connectors are in separated branches until I merge them into master.
 
  Moreover, I have been talking and reviewing with Rafa through Skype the
  current work, and we have agreed to track all the things also in the Jira
  issue (apart from these mails), so I will put the configuration
 screenshots
  there and the links to the GitHub repositories.
 

 Perfect!. Let me know when we can start testing the Authority connector
 too. My intention is to test the whole connector in a real environment
 extensively sometime before the pencil downs looking for possible bugs,
 additions and so on.

 Well done so far!
 Cheers,
 Rafa


 
  Comments and suggestions are more than welcome as always.
 
  Regards
 
  
 
  [1]
 
 
 https://github.com/adperezmorales/confluence-manifold-connector/tree/feature/authority-connector
 

Re: [GSoC] Confluence Authority Connector

[Karl Wright]

bq. Karl one question about repository connector document retainment. I'm
using
the activities.retainAllComponentDocument(docId) method of IProcessActivity
to retain the document and avoid to be reindexed.

Hi Antonio,

checkDocumentNeedsReindexing() is the standard way of determining whether a
document needs to be reindexed or not.  You can follow the template present
in multiple other connectors that use this method.

retainAllComponentDocuments() is basically a shorthand way of determining
the disposition of document components.  I don't believe you even use
document components in the confluence connector, although I could be wrong
about that?  In general, if your connector doesn't do anything with
components at all, you will not need to call this method.

Thanks,
Karl




On Fri, Jul 10, 2015 at 10:43 AM, Antonio David Pérez Morales 
adperezmora...@gmail.com wrote:

 Hi devs

 Continuing with the work, I have developed a first version of the
 Confluence Authority connector aligned with the ACLs used by the Confluence
 Repository Connector.
 I have fixed and improved some parts in the repository connector and
 committed the code and also I have updated the Jira issue [1] to keep track
 of the new additions.
 Both branches have been merged into master and I have created a new develop
 branch [2] from it, so further improvements and fixes can be done from this
 branch and then merged into master.
 Right now, the connectors are in different maven modules and maybe in the
 future I can merge into one single maven project without modules, so that
 with one jar file we will have both connectors ready to be used in
 Manifold.
 As of now, I will work in the Authority connector improvements and tests
 and also I will do all the things Rafa (or you guys) can report regarding
 the functionality of the connectors.

 Karl one question about repository connector document retainment. I'm using
 the activities.retainAllComponentDocument(docId) method of IProcessActivity
 to retain the document and avoid to be reindexed.
 Rafa, while checking and reviewing the code, noticed that other connectors
 are using the checkDocumentNeedsReindexing(documentIdentifier,
 newVersionString) method also from IProcessActivity. I checked the code
 from both methods and internally they act differently. Is it fine to use
 the retainAllComponentDocument or it is better to switch to
 checkDocumentNeedsReindexing one?

 As always, if you have suggestions about improvements or more things which
 can be done for these connectors, please let me know.

 Regards

 [1] https://issues.apache.org/jira/browse/CONNECTORS-1161
 [2]

 https://github.com/adperezmorales/confluence-manifold-connector/tree/develop


 2015-07-09 17:17 GMT+02:00 Rafa Haro rh...@apache.org:

  Hi Antonio,
 
  Thanks for the new update. Let me make some comments inline:
 
  On Wed, Jul 8, 2015 at 6:31 PM, Antonio David Pérez Morales 
  adperezmora...@gmail.com wrote:
 
   Hi devs
  
   After the midterm, I continue with the proposed work and I already
  started
   to work on the second part of the project, which is the development of
 an
   Authority Connector for Confluence.
  
   I have created a new branch [1] for that in my GitHub account and I
  already
   committed the basic structure of the connector along with the code
  related
   to Confluence instance configuration. After that I will develop the
  proper
   strategy to get the ACLs for the user as stated in the proposal.
  
   For this case, I have been evaluating the two scenarios contained in
 the
   proposal and I will start developing the space-based permissions which
   requires no customizations of Confluence instance (coarse grain).
  
   I made some tests with Confluence APIs trying to go more fine-grain
 using
   the user groups but there is not endpoint method to get the groups that
  can
   view a specific page. So in the end, I think the space-based permission
  is
   a good solution, because implementing a Confluence plugin for that to
  cover
   some very specific use cases I think most people won't be willing to
  patch
   Confluence only for those specific use cases (for example where a
 person
  is
   not allowed to view a space but it is allowed to view a single page in
  that
   space).
  
 
  Let's focus right now on permissions at space level. As you said, to
 patch
  confluence API is not  a good solution, specially for those using it in
 the
  Cloud. If in the future they extend the API with more fine grained
  permissions approach, we can always update later the connector.
 
 
  
   I have also updated the README file putting a guide to configure both
   connectors using screenshots about configuration tabs for the
 connectors.
   I'm using embedded images (using Data URIs syntax for images) but it
  seems
   they are not supported by GitHub in the README (although they are in
 the
   code, and other Markdown viewers can show them).
  
 
  Ok, thanks!
 
 
  
   The connectors are in separated 

Re: [GSoC] Confluence Authority Connector

[Rafa Haro]

Hi Antonio,

Thanks for the new update. Let me make some comments inline:

On Wed, Jul 8, 2015 at 6:31 PM, Antonio David Pérez Morales 
adperezmora...@gmail.com wrote:

 Hi devs

 After the midterm, I continue with the proposed work and I already started
 to work on the second part of the project, which is the development of an
 Authority Connector for Confluence.

 I have created a new branch [1] for that in my GitHub account and I already
 committed the basic structure of the connector along with the code related
 to Confluence instance configuration. After that I will develop the proper
 strategy to get the ACLs for the user as stated in the proposal.

 For this case, I have been evaluating the two scenarios contained in the
 proposal and I will start developing the space-based permissions which
 requires no customizations of Confluence instance (coarse grain).

 I made some tests with Confluence APIs trying to go more fine-grain using
 the user groups but there is not endpoint method to get the groups that can
 view a specific page. So in the end, I think the space-based permission is
 a good solution, because implementing a Confluence plugin for that to cover
 some very specific use cases I think most people won't be willing to patch
 Confluence only for those specific use cases (for example where a person is
 not allowed to view a space but it is allowed to view a single page in that
 space).


Let's focus right now on permissions at space level. As you said, to patch
confluence API is not  a good solution, specially for those using it in the
Cloud. If in the future they extend the API with more fine grained
permissions approach, we can always update later the connector.



 I have also updated the README file putting a guide to configure both
 connectors using screenshots about configuration tabs for the connectors.
 I'm using embedded images (using Data URIs syntax for images) but it seems
 they are not supported by GitHub in the README (although they are in the
 code, and other Markdown viewers can show them).


Ok, thanks!



 The connectors are in separated branches until I merge them into master.

 Moreover, I have been talking and reviewing with Rafa through Skype the
 current work, and we have agreed to track all the things also in the Jira
 issue (apart from these mails), so I will put the configuration screenshots
 there and the links to the GitHub repositories.


Perfect!. Let me know when we can start testing the Authority connector
too. My intention is to test the whole connector in a real environment
extensively sometime before the pencil downs looking for possible bugs,
additions and so on.

Well done so far!
Cheers,
Rafa



 Comments and suggestions are more than welcome as always.

 Regards

 

 [1]

 https://github.com/adperezmorales/confluence-manifold-connector/tree/feature/authority-connector

[GSoC] Confluence Authority Connector

[Antonio David Pérez Morales]

Hi devs

After the midterm, I continue with the proposed work and I already started
to work on the second part of the project, which is the development of an
Authority Connector for Confluence.

I have created a new branch [1] for that in my GitHub account and I already
committed the basic structure of the connector along with the code related
to Confluence instance configuration. After that I will develop the proper
strategy to get the ACLs for the user as stated in the proposal.

For this case, I have been evaluating the two scenarios contained in the
proposal and I will start developing the space-based permissions which
requires no customizations of Confluence instance (coarse grain).

I made some tests with Confluence APIs trying to go more fine-grain using
the user groups but there is not endpoint method to get the groups that can
view a specific page. So in the end, I think the space-based permission is
a good solution, because implementing a Confluence plugin for that to cover
some very specific use cases I think most people won't be willing to patch
Confluence only for those specific use cases (for example where a person is
not allowed to view a space but it is allowed to view a single page in that
space).

I have also updated the README file putting a guide to configure both
connectors using screenshots about configuration tabs for the connectors.
I'm using embedded images (using Data URIs syntax for images) but it seems
they are not supported by GitHub in the README (although they are in the
code, and other Markdown viewers can show them).

The connectors are in separated branches until I merge them into master.

Moreover, I have been talking and reviewing with Rafa through Skype the
current work, and we have agreed to track all the things also in the Jira
issue (apart from these mails), so I will put the configuration screenshots
there and the links to the GitHub repositories.

Comments and suggestions are more than welcome as always.

Regards



[1]
https://github.com/adperezmorales/confluence-manifold-connector/tree/feature/authority-connector

Re: [GSoC] Confluence Authority Connector

[Antonio David Pérez Morales]

Hi Karl

I think so as well. So I will go for the first proposed solution that will
bring us permissions at space level.

Thanks for your response

Regards

2015-07-08 18:55 GMT+02:00 Karl Wright daddy...@gmail.com:

 I made some tests with Confluence APIs trying to go more fine-grain using
 the user groups but there is not endpoint method to get the groups that can
 view a specific page.

 Hi Antonio,
 I had a very similar problem with Jira.  It's not apparently possible to
 get back a list of groups for a user without writing a special plugin that
 runs on Jira.  This may be a common feature of all Atlassian software.

 Karl


 On Wed, Jul 8, 2015 at 12:31 PM, Antonio David Pérez Morales 
 adperezmora...@gmail.com wrote:

  Hi devs
 
  After the midterm, I continue with the proposed work and I already
 started
  to work on the second part of the project, which is the development of an
  Authority Connector for Confluence.
 
  I have created a new branch [1] for that in my GitHub account and I
 already
  committed the basic structure of the connector along with the code
 related
  to Confluence instance configuration. After that I will develop the
 proper
  strategy to get the ACLs for the user as stated in the proposal.
 
  For this case, I have been evaluating the two scenarios contained in the
  proposal and I will start developing the space-based permissions which
  requires no customizations of Confluence instance (coarse grain).
 
  I made some tests with Confluence APIs trying to go more fine-grain using
  the user groups but there is not endpoint method to get the groups that
 can
  view a specific page. So in the end, I think the space-based permission
 is
  a good solution, because implementing a Confluence plugin for that to
 cover
  some very specific use cases I think most people won't be willing to
 patch
  Confluence only for those specific use cases (for example where a person
 is
  not allowed to view a space but it is allowed to view a single page in
 that
  space).
 
  I have also updated the README file putting a guide to configure both
  connectors using screenshots about configuration tabs for the connectors.
  I'm using embedded images (using Data URIs syntax for images) but it
 seems
  they are not supported by GitHub in the README (although they are in the
  code, and other Markdown viewers can show them).
 
  The connectors are in separated branches until I merge them into master.
 
  Moreover, I have been talking and reviewing with Rafa through Skype the
  current work, and we have agreed to track all the things also in the Jira
  issue (apart from these mails), so I will put the configuration
 screenshots
  there and the links to the GitHub repositories.
 
  Comments and suggestions are more than welcome as always.
 
  Regards
 
  
 
  [1]
 
 
 https://github.com/adperezmorales/confluence-manifold-connector/tree/feature/authority-connector
 

Re: [GSoC] Confluence Authority Connector

[Karl Wright]

I made some tests with Confluence APIs trying to go more fine-grain using
the user groups but there is not endpoint method to get the groups that can
view a specific page.

Hi Antonio,
I had a very similar problem with Jira.  It's not apparently possible to
get back a list of groups for a user without writing a special plugin that
runs on Jira.  This may be a common feature of all Atlassian software.

Karl


On Wed, Jul 8, 2015 at 12:31 PM, Antonio David Pérez Morales 
adperezmora...@gmail.com wrote:

 Hi devs

 After the midterm, I continue with the proposed work and I already started
 to work on the second part of the project, which is the development of an
 Authority Connector for Confluence.

 I have created a new branch [1] for that in my GitHub account and I already
 committed the basic structure of the connector along with the code related
 to Confluence instance configuration. After that I will develop the proper
 strategy to get the ACLs for the user as stated in the proposal.

 For this case, I have been evaluating the two scenarios contained in the
 proposal and I will start developing the space-based permissions which
 requires no customizations of Confluence instance (coarse grain).

 I made some tests with Confluence APIs trying to go more fine-grain using
 the user groups but there is not endpoint method to get the groups that can
 view a specific page. So in the end, I think the space-based permission is
 a good solution, because implementing a Confluence plugin for that to cover
 some very specific use cases I think most people won't be willing to patch
 Confluence only for those specific use cases (for example where a person is
 not allowed to view a space but it is allowed to view a single page in that
 space).

 I have also updated the README file putting a guide to configure both
 connectors using screenshots about configuration tabs for the connectors.
 I'm using embedded images (using Data URIs syntax for images) but it seems
 they are not supported by GitHub in the README (although they are in the
 code, and other Markdown viewers can show them).

 The connectors are in separated branches until I merge them into master.

 Moreover, I have been talking and reviewing with Rafa through Skype the
 current work, and we have agreed to track all the things also in the Jira
 issue (apart from these mails), so I will put the configuration screenshots
 there and the links to the GitHub repositories.

 Comments and suggestions are more than welcome as always.

 Regards

 

 [1]

 https://github.com/adperezmorales/confluence-manifold-connector/tree/feature/authority-connector

Re: [GSoC] Confluence connector project status after bonding period

[Rafa Haro]

Hi Antonio,

Thanks a lot for the update and congratulations for reaching GSoC's midterm
successfully. I have been checking the proposal again carefully and, as I
have remarked in your evaluation, you are on schedule so far. Let me
comment your previous email:

On Sat, Jun 27, 2015 at 11:30 AM, Antonio David Pérez Morales 
adperezmora...@gmail.com wrote:

 Hi all

 Continuing with the development of Confluence repository connector [1] I
 have added support for processing attachments (configurable per job) for
 pages, ability to crawl each kind of pages and extract the page labels if
 they have been set.


Good. During this week, I will pull the last version from github and will
be testing it against a real Confluence instance on my current company. I
will also take a look to the code to check if some refactor is needed.
After testing, I should have a better idea about possible changes regarding
configuration, performance, integration details and so on. I will provide
my feedback ASAP both to you directly and here in the ManifoldCF's
developers list. In that way, anyone also interested in the connector
within the community can also provide feedback, ideas... I won't delay too
much the testing because this is the right moment to accomplish possible
changes/additions before continuing with the second part of the project
that, according to the proposal planning, should be focused on the
Authority connector, unit testing and final documentation. In summary,
let's close the repository connector first :-).


 Besides, a complete refactor of the code and client has been done, so now
 the connector has a better code flow and the specific components have been
 simplified.


Perfect, I will take a look to the code and will provide feedback also.


 Right now, the connector is able to process Page and attachments, being
 Page each supported confluence page type (blog, table, etc). As an
 improvement I want to add specific support for each kind of Page, giving
 the connector the ability to process Page-specific features. For example,
 for Blog pages, the connector is extracting the default/common properties,
 but adding the specific support for Blog page model (like it has been done
 for attachments) would allow to extract Blog page-specific properties and
 set the specific type for that page to Blog instead of Page (by default).


Well, I suppose that we should decide a scope here, because to take into
account all types of Confluence Pages would probably complicate too much
the connector right now. This is something that we can progressively
improve or contribute after GSoC have finished. Which it is important now
is to come up with a good design for Confluence Pages in the connector in
order to ease the inclusion of concrete behavior for any kind of Page. Let
me take a look to the current code and also check how many different kind
of pages is currently supporting Confluence and will come back to you with
a suggestion.



 Another things that is being done in parallel is the development of the
 tests, to have a complete set of unit tests for the midterm.


 The code can be found at [1]. It is a git branch. After the midterm, I will
 merge that branch with master one and create another one for the
 development of the authority connector to keep them separated at the
 moment.


Ok. I aim the rest of the community to take a look also to the code and
provide feedback. I will try to do the same with the other ManifoldCF's
GSoC project for integrating Kafka. If it is make it easier, once you merge
the connector to the master branch I could setup a branch at ManifoldCF's
svn space for easing the testing.

Cheers,
Rafa



 If you have any question/suggestion/comment, please drop a message here
 which will be more than welcome.

 Regards
 --

 [1]

 https://github.com/adperezmorales/confluence-manifold-connector/tree/feature/repository-connector

 2015-06-05 18:48 GMT+02:00 Antonio David Pérez Morales 
 adperezmora...@gmail.com:

  Hi devs and all
 
  As part of the development of the Atlassian Confluence connector for
  Manifold, I have created a repository [1] on my GitHub account
  Moreover I have developed and pushed the first version of the Confluence
  repository connector on a branch called 'feature/repository-connector'.
  This first version of the repository connector allows to crawl all the
  Confluence pages contained in the spaces (only pages), with the
 possibility
  to filter by a space.
  At this moment, only one space or all of them can be configured to be
  crawled, but I will continue improving the connector adding more features
  like configuring more than one space or others you may see interesting to
  be added.
  The ACLs of the documents crawled are the space it belongs to, so that it
  is aligned with the proposal for the Authority connector starting at
 Space
  level and then going more fine grain if necessary.
  There are no tests included at this moment, because I'm working on them.
 
  To see

Re: [GSoC] Confluence connector project status after bonding period

[Antonio David Pérez Morales]

Hi all

Continuing with the development of Confluence repository connector [1] I
have added support for processing attachments (configurable per job) for
pages, ability to crawl each kind of pages and extract the page labels if
they have been set.
Besides, a complete refactor of the code and client has been done, so now
the connector has a better code flow and the specific components have been
simplified.
Right now, the connector is able to process Page and attachments, being
Page each supported confluence page type (blog, table, etc). As an
improvement I want to add specific support for each kind of Page, giving
the connector the ability to process Page-specific features. For example,
for Blog pages, the connector is extracting the default/common properties,
but adding the specific support for Blog page model (like it has been done
for attachments) would allow to extract Blog page-specific properties and
set the specific type for that page to Blog instead of Page (by default).

Another things that is being done in parallel is the development of the
tests, to have a complete set of unit tests for the midterm.

The code can be found at [1]. It is a git branch. After the midterm, I will
merge that branch with master one and create another one for the
development of the authority connector to keep them separated at the moment.

If you have any question/suggestion/comment, please drop a message here
which will be more than welcome.

Regards
--

[1]
https://github.com/adperezmorales/confluence-manifold-connector/tree/feature/repository-connector

2015-06-05 18:48 GMT+02:00 Antonio David Pérez Morales 
adperezmora...@gmail.com:

 Hi devs and all

 As part of the development of the Atlassian Confluence connector for
 Manifold, I have created a repository [1] on my GitHub account
 Moreover I have developed and pushed the first version of the Confluence
 repository connector on a branch called 'feature/repository-connector'.
 This first version of the repository connector allows to crawl all the
 Confluence pages contained in the spaces (only pages), with the possibility
 to filter by a space.
 At this moment, only one space or all of them can be configured to be
 crawled, but I will continue improving the connector adding more features
 like configuring more than one space or others you may see interesting to
 be added.
 The ACLs of the documents crawled are the space it belongs to, so that it
 is aligned with the proposal for the Authority connector starting at Space
 level and then going more fine grain if necessary.
 There are no tests included at this moment, because I'm working on them.

 To see if the proposed Authority connector could be developed in a good
 way, I have done a quick proof of concept with the logic of it and I was
 able to get the spaces which the user has permission to access. So I can
 confirm that at space level, we can add permissions to the documents
 crawled in order to filter them later on the search engine being used.

 One important thing is that the new Confluence REST Api does not include
 any endpoints for permissions yet, so legacy API's have to be used for that
 while Confluence developers port completely the legacy methods to the new
 api.

 I will continue improving the repository connector and thinking new
 features to be added, but if you think some feature is interesting or good
 to have, please let me know and I will take a look in order to include it.

 As stated in the proposal, the Authority Connector is planned for the
 second part of the project, but I started to work a bit on it to make sure
 we can have a general working version and then iteratively improving it.

 As always, comments and suggestions are more than welcome.

 Regards


 [1] https://github.com/adperezmorales/confluence-manifold-connector/

 2015-05-26 17:10 GMT+02:00 Antonio David Pérez Morales 
 adperezmora...@gmail.com:

 Hi all

 During the bonding period and these days I have been taking a look and
 familiarizing with Confluence API,
 doing some tests using CURL before start the implementation of the
 repository connector which is the first step as stated in the proposal.

 I have deployed a local instance of Confluence as well, so that I can do
 the development and tests using that instance.

 As stated in the proposal, Confluence is migrating its old APIs (rpc-xml,
 rpc-json) to the new REST API, so all the methods are not migrated yet.
 For getting the changes, fields and content of the documents there won't
 be any problem, but for permissions I have to check more in deep if the new
 REST API already support it.
 If not, we will have to do a mix using the methods provided by the
 rpc-json api for that, and update it when the REST API contains all the
 methods.

 After the first tests, there is no easy way to retrieve the user
 permissions because they are tied to documents and/or spaces. So in order
 to retrieve the user permissions,
 documentId or SpaceId and user have to be provided. I 

Re: [GSoC] Confluence connector project status after bonding period

[Rafa Haro]

Hi Antonio,

First of all, it is nice to see such good progress here. I will fork the
repo at github and will give it a try very soon because I'm starting to
need it for a real use case, so I will be able to provide user feedback
very soon. Let me make some comments over your email:

On Fri, Jun 5, 2015 at 6:48 PM, Antonio David Pérez Morales 
adperezmora...@gmail.com wrote:

 Hi devs and all

 As part of the development of the Atlassian Confluence connector for
 Manifold, I have created a repository [1] on my GitHub account
 Moreover I have developed and pushed the first version of the Confluence
 repository connector on a branch called 'feature/repository-connector'.
 This first version of the repository connector allows to crawl all the
 Confluence pages contained in the spaces (only pages), with the possibility
 to filter by a space.
 At this moment, only one space or all of them can be configured to be
 crawled, but I will continue improving the connector adding more features
 like configuring more than one space or others you may see interesting to
 be added.


Do we know something about pages metadata? How is the content retrieved, in
a raw format or is it possible to get also formatted content?


 The ACLs of the documents crawled are the space it belongs to, so that it
 is aligned with the proposal for the Authority connector starting at Space
 level and then going more fine grain if necessary.
 There are no tests included at this moment, because I'm working on them.


Ok, perfect. Probably it is too soon for having tests, but it would be
great to include them progressively while you are developing the connector.



 To see if the proposed Authority connector could be developed in a good
 way, I have done a quick proof of concept with the logic of it and I was
 able to get the spaces which the user has permission to access. So I can
 confirm that at space level, we can add permissions to the documents
 crawled in order to filter them later on the search engine being used.

 One important thing is that the new Confluence REST Api does not include
 any endpoints for permissions yet, so legacy API's have to be used for that
 while Confluence developers port completely the legacy methods to the new
 api.


Let's hope they include them for the second part of the project and if not
we can always use the legacy API and update it after GSoC as a normal
contribution



 I will continue improving the repository connector and thinking new
 features to be added, but if you think some feature is interesting or good
 to have, please let me know and I will take a look in order to include it.

 As stated in the proposal, the Authority Connector is planned for the
 second part of the project, but I started to work a bit on it to make sure
 we can have a general working version and then iteratively improving it.


Ok, let's focus on the repository connector then until midterm evaluation.
Next step would be probably to include more filtering options and check
what kind of metadata can be extracted from the pages. I will check the
code, but the kind of this we should be thinking now are for example page's
URLs to be indexed, seeding strategy and so on.



 As always, comments and suggestions are more than welcome.


Nothing else from my side. Well done so far!



 Regards


 [1] https://github.com/adperezmorales/confluence-manifold-connector/

 2015-05-26 17:10 GMT+02:00 Antonio David Pérez Morales 
 adperezmora...@gmail.com:

  Hi all
 
  During the bonding period and these days I have been taking a look and
  familiarizing with Confluence API,
  doing some tests using CURL before start the implementation of the
  repository connector which is the first step as stated in the proposal.
 
  I have deployed a local instance of Confluence as well, so that I can do
  the development and tests using that instance.
 
  As stated in the proposal, Confluence is migrating its old APIs (rpc-xml,
  rpc-json) to the new REST API, so all the methods are not migrated yet.
  For getting the changes, fields and content of the documents there won't
  be any problem, but for permissions I have to check more in deep if the
 new
  REST API already support it.
  If not, we will have to do a mix using the methods provided by the
  rpc-json api for that, and update it when the REST API contains all the
  methods.
 
  After the first tests, there is no easy way to retrieve the user
  permissions because they are tied to documents and/or spaces. So in order
  to retrieve the user permissions,
  documentId or SpaceId and user have to be provided. I proposed two
  approaches to tackle this, one not so efficient, making many requests to
  Confluence and the other developing a Confluence plugin to get them
  (because at least at Java API level it is possible, but don't know yet
 what
  kind of permissions it returns)
 
  So I think, for that part, we can start using (trying) permissions at
  Space level and then try to go finer at document

Re: [GSoC] Confluence connector project status after bonding period

[Antonio David Pérez Morales]

Hi devs and all

As part of the development of the Atlassian Confluence connector for
Manifold, I have created a repository [1] on my GitHub account
Moreover I have developed and pushed the first version of the Confluence
repository connector on a branch called 'feature/repository-connector'.
This first version of the repository connector allows to crawl all the
Confluence pages contained in the spaces (only pages), with the possibility
to filter by a space.
At this moment, only one space or all of them can be configured to be
crawled, but I will continue improving the connector adding more features
like configuring more than one space or others you may see interesting to
be added.
The ACLs of the documents crawled are the space it belongs to, so that it
is aligned with the proposal for the Authority connector starting at Space
level and then going more fine grain if necessary.
There are no tests included at this moment, because I'm working on them.

To see if the proposed Authority connector could be developed in a good
way, I have done a quick proof of concept with the logic of it and I was
able to get the spaces which the user has permission to access. So I can
confirm that at space level, we can add permissions to the documents
crawled in order to filter them later on the search engine being used.

One important thing is that the new Confluence REST Api does not include
any endpoints for permissions yet, so legacy API's have to be used for that
while Confluence developers port completely the legacy methods to the new
api.

I will continue improving the repository connector and thinking new
features to be added, but if you think some feature is interesting or good
to have, please let me know and I will take a look in order to include it.

As stated in the proposal, the Authority Connector is planned for the
second part of the project, but I started to work a bit on it to make sure
we can have a general working version and then iteratively improving it.

As always, comments and suggestions are more than welcome.

Regards


[1] https://github.com/adperezmorales/confluence-manifold-connector/

2015-05-26 17:10 GMT+02:00 Antonio David Pérez Morales 
adperezmora...@gmail.com:

 Hi all

 During the bonding period and these days I have been taking a look and
 familiarizing with Confluence API,
 doing some tests using CURL before start the implementation of the
 repository connector which is the first step as stated in the proposal.

 I have deployed a local instance of Confluence as well, so that I can do
 the development and tests using that instance.

 As stated in the proposal, Confluence is migrating its old APIs (rpc-xml,
 rpc-json) to the new REST API, so all the methods are not migrated yet.
 For getting the changes, fields and content of the documents there won't
 be any problem, but for permissions I have to check more in deep if the new
 REST API already support it.
 If not, we will have to do a mix using the methods provided by the
 rpc-json api for that, and update it when the REST API contains all the
 methods.

 After the first tests, there is no easy way to retrieve the user
 permissions because they are tied to documents and/or spaces. So in order
 to retrieve the user permissions,
 documentId or SpaceId and user have to be provided. I proposed two
 approaches to tackle this, one not so efficient, making many requests to
 Confluence and the other developing a Confluence plugin to get them
 (because at least at Java API level it is possible, but don't know yet what
 kind of permissions it returns)

 So I think, for that part, we can start using (trying) permissions at
 Space level and then try to go finer at document level.
 These problems are mainly related to the second part of the project
 (Authority Connector) but I think it is interesting to put here some
 results after the first overall tests I have performed.

 Regards

Re: [GSoC] Confluence connector project status after bonding period

[Karl Wright]

Hi Antonio,

I agree that it's pretty important to understand pretty much what will be
needed before actually beginning coding.  Thanks!

Karl


On Tue, May 26, 2015 at 11:10 AM, Antonio David Pérez Morales 
adperezmora...@gmail.com wrote:

 Hi all

 During the bonding period and these days I have been taking a look and
 familiarizing with Confluence API,
 doing some tests using CURL before start the implementation of the
 repository connector which is the first step as stated in the proposal.

 I have deployed a local instance of Confluence as well, so that I can do
 the development and tests using that instance.

 As stated in the proposal, Confluence is migrating its old APIs (rpc-xml,
 rpc-json) to the new REST API, so all the methods are not migrated yet.
 For getting the changes, fields and content of the documents there won't be
 any problem, but for permissions I have to check more in deep if the new
 REST API already support it.
 If not, we will have to do a mix using the methods provided by the rpc-json
 api for that, and update it when the REST API contains all the methods.

 After the first tests, there is no easy way to retrieve the user
 permissions because they are tied to documents and/or spaces. So in order
 to retrieve the user permissions,
 documentId or SpaceId and user have to be provided. I proposed two
 approaches to tackle this, one not so efficient, making many requests to
 Confluence and the other developing a Confluence plugin to get them
 (because at least at Java API level it is possible, but don't know yet what
 kind of permissions it returns)

 So I think, for that part, we can start using (trying) permissions at Space
 level and then try to go finer at document level.
 These problems are mainly related to the second part of the project
 (Authority Connector) but I think it is interesting to put here some
 results after the first overall tests I have performed.

 Regards

[GSoC] Confluence connector project status after bonding period

[Antonio David Pérez Morales]

Hi all

During the bonding period and these days I have been taking a look and
familiarizing with Confluence API,
doing some tests using CURL before start the implementation of the
repository connector which is the first step as stated in the proposal.

I have deployed a local instance of Confluence as well, so that I can do
the development and tests using that instance.

As stated in the proposal, Confluence is migrating its old APIs (rpc-xml,
rpc-json) to the new REST API, so all the methods are not migrated yet.
For getting the changes, fields and content of the documents there won't be
any problem, but for permissions I have to check more in deep if the new
REST API already support it.
If not, we will have to do a mix using the methods provided by the rpc-json
api for that, and update it when the REST API contains all the methods.

After the first tests, there is no easy way to retrieve the user
permissions because they are tied to documents and/or spaces. So in order
to retrieve the user permissions,
documentId or SpaceId and user have to be provided. I proposed two
approaches to tackle this, one not so efficient, making many requests to
Confluence and the other developing a Confluence plugin to get them
(because at least at Java API level it is possible, but don't know yet what
kind of permissions it returns)

So I think, for that part, we can start using (trying) permissions at Space
level and then try to go finer at document level.
These problems are mainly related to the second part of the project
(Authority Connector) but I think it is interesting to put here some
results after the first overall tests I have performed.

Regards

Re: [GSoC] Confluence Connector

[Antonio David Perez Morales]

Hi Karl

Thanks for your response. For (4) , I have access to Confluence instances
(dev and prod if needed) so it won't be a problem.
I have also some other ideas for new connectors and other improvements.
So I will try to create the tickets for that and the proposals (when the
student application opens next week).

Regards

On Thu, Mar 12, 2015 at 11:42 AM, Karl Wright daddy...@gmail.com wrote:

 Hi Antonio (and ALL GSoC applicants),

 The ticket for this GSoC feature is CONNECTORS-1161.  I think it's a good
 idea for all applicants to attach their proposal to the ticket.  The
 proposal should include (according to the GSoC mentor rules): (1) your
 previous experience with GSoC; (2) the number of hours you will be able to
 spend on the project; (3) a bit of your background; and (for ManifoldCF
 especially!) (4) your ability to access instances of the third-party
 systems you'd need to do the development, e.g. a Confluence instance.

 There is currently another person interested in working on this as well,
 and there are other tickets with GSoC2015 tags, so I'd encourage you to
 apply to all tickets you may be interested in.  The team here will decide
 on the best fits. We want everyone to be successful.

 (Antonio, your writeup above is sufficient for all points except (4)).

 Thanks!
 Karl


 On Wed, Mar 11, 2015 at 11:08 AM, Antonio David Perez Morales 
 ape...@zaizi.com wrote:

  Hi all
 
  I'm Antonio David Perez Morales, a Senior Software Engineer of Zaizi and
 a
  student of a Master in Technology and Software Engineering from the
  University of Seville.
 
  Some of you already meet me since I work with Apache Manifold in my daily
  job, and I have had to fix, improve and create new connectors and also I
  created some initial idea of processor connector here at work , which
  finally was implemented by Karl as Transformation connector stuff. so I
  have a strong knowledge about the ManifoldCF project.
 
  I also use Confluence at work and I had to integrate it with Atlassian
  Crowd (a solution for authentication/authorization from Atlassian) so I
  have also a good understanding on Confluence API and how it works.
  I did my last two GSoCs projects within the Apache Stanbol project and I
  also had to integrate it with Manifold at work as well. You can check my
  github account [1] for more information about such projects.
 
  Now, I'm most focused on extending ManifoldCF features, so I think it is
 a
  great opportunity to collaborate directly inside ManifoldCF community.
 
  Regards
 
  [1] https://github.com/adperezmorales
 
  --
 
  --
  This message should be regarded as confidential. If you have received
 this
  email in error please notify the sender and destroy it immediately.
  Statements of intent shall only become binding when confirmed in hard
 copy
  by an authorised signatory.
 
  Zaizi Ltd is registered in England and Wales with the registration number
  6440931. The Registered Office is Brook House, 229 Shepherds Bush Road,
  London W6 7AN.
 


-- 

--
This message should be regarded as confidential. If you have received this 
email in error please notify the sender and destroy it immediately. 
Statements of intent shall only become binding when confirmed in hard copy 
by an authorised signatory.

Zaizi Ltd is registered in England and Wales with the registration number 
6440931. The Registered Office is Brook House, 229 Shepherds Bush Road, 
London W6 7AN. 

Re: [GSoC-idea] Confluence Connector

[Rafa Haro]

Hi Karl, 

Completely agree with those points. Of course, later, the students would need 
to make a most detailed proposal (planning, estimations, development steps and 
so on) at Google Melange. That proposal will be the final base of our 
evaluations.

Cheers,
Rafa


En 12 de marzo de 2015 en 12:28:26, Karl Wright (daddy...@gmail.com) escrito:

Hi Dimuthu and Rafa,  

I just laid out a 4-point proposal checklist in my response to Antonio --  
it is important that all proposals at least touch on all four points. I'd  
also echo Rafa's point and maybe consider applying for more than one  
project, just in case. ;-)  

Karl  


On Wed, Mar 11, 2015 at 11:30 AM, Rafa Haro rh...@apache.org wrote:  

 Hi Dimuthu,  
  
 Yes, I created that ticket because there was also another student  
 interested in developing the Confluence connector. There was also another  
 ticket for this edition of GSoC related to Manifold that was about  
 implementing an output connector for Apache Kafka. Unfortunately, I only  
 have time for mentoring one of the projects due to my time availability  
 restrictions. In this situation, usually the way to proceed is the  
 following: if there is more than one student interested in the same  
 project, I will evaluate both proposal and the best one will win. If there  
 is enough mentors or another committer would like to mentor the other  
 project, one of the student can make a proposal to the other one. I was  
 mentoring another Apache project last year and we really tried, whenever  
 was possible, to not get the students competing between them for the same  
 project for several reasons:  
  
 - If we cover all the GSoC tickets, that is of course better for Apache  
 Manifold  
 - Sometimes it is quite hard to score the proposals because normally they  
 are all very good  
  
 Anyway, the probability to have several students competing for the same  
 GSoC project is always high. So in the absence of more mentors, I would aim  
 all the students to make their proposal (you can of course apply for more  
 than one project) and the mentors will internally score them.  
  
 All the best,  
 Rafa  
  
  
 En 11 de marzo de 2015 en 14:53:17, Karl Wright (daddy...@gmail.com)  
 escrito:  
  
 Hi Dlmuthu,  
  
 I saw your comment in the ticket for this connector. The ticket was  
 created by Rafa Haro, who would be the mentor for this project. Please  
 wait for his response.  
  
 Thanks,  
 Karl  
  
  
 On Wed, Mar 11, 2015 at 9:35 AM, DImuthu Upeksha   
 dimuthu.upeks...@gmail.com  
  wrote:  
  
  Hi all,  
   
  I'm Dimuthu Upeksha, a Computer Engineering Undergraduate from University  
  of Moratuwa - Sri Lanka. I did my last two GSoCs with Apache ISIS and  
  Apache PDFBox. I'm hope to participate to GSoC this time also. I found  
 the  
  issue [1] mentioned in ManifoldCF jira page very interesting. I believe  
  that I have basic context knowledge to continue that project.  
   
  As a part of my final year project I have been working in implementing  
 web  
  crawlers. I specially implemented a web crawler to extract content from  
  Sinhala blogs using Google blogger API and Google feed burner. Also I  
  have a good experience in both REST and SOAP API communication. [3] is  
 the  
  REST API project we have developed for our final year project. In my  
  internship at WSO2 I have been working in developing connectors for  
  Confluence, Jira, LDAP and SVN that support for WSO2 ESB. So I have a  
 good  
  idea about Confluence API. [4] is the LDAP connector for WSO2 ESB.  
   
  For now, to have an initial idea about MainifildCF I'm referring to  
  ManifioldCF in Action book. Also I have managed to clone ManifildCF  
 project  
  from Github [5]. I found a document [6] that gives an idea about  
  implementing both Repository and Authority Connectors for ManifoldCF. In  
  addition to above resources is there anything I can use to have an idea  
  about the project and scope of the project idea?  
   
  [1] https://issues.apache.org/jira/browse/CONNECTORS-1161  
  [2] https://github.com/DImuthuUpe/BlogCrawler  
  [3] https://github.com/DImuthuUpe/SinminREST  
  [4]  
   
   
 https://github.com/DImuthuUpe/esb-connectors/tree/master/ldap/ldap-connector/ldap-connector-1.0.0
   
  [5] https://github.com/apache/manifoldcf  
  [6]  
   
 http://manifoldcf.apache.org/release/trunk/en_US/technical-resources.html  
   
  Thank You  
  Dimuthu  
   
  --  
  Regards  
   
  W.Dimuthu Upeksha  
  Undergraduate  
  Department of Computer Science And Engineering  
   
  University of Moratuwa, Sri Lanka  
   
  

Re: [GSoC] Confluence Connector

[Karl Wright]

Hi Antonio (and ALL GSoC applicants),

The ticket for this GSoC feature is CONNECTORS-1161.  I think it's a good
idea for all applicants to attach their proposal to the ticket.  The
proposal should include (according to the GSoC mentor rules): (1) your
previous experience with GSoC; (2) the number of hours you will be able to
spend on the project; (3) a bit of your background; and (for ManifoldCF
especially!) (4) your ability to access instances of the third-party
systems you'd need to do the development, e.g. a Confluence instance.

There is currently another person interested in working on this as well,
and there are other tickets with GSoC2015 tags, so I'd encourage you to
apply to all tickets you may be interested in.  The team here will decide
on the best fits. We want everyone to be successful.

(Antonio, your writeup above is sufficient for all points except (4)).

Thanks!
Karl


On Wed, Mar 11, 2015 at 11:08 AM, Antonio David Perez Morales 
ape...@zaizi.com wrote:

 Hi all

 I'm Antonio David Perez Morales, a Senior Software Engineer of Zaizi and a
 student of a Master in Technology and Software Engineering from the
 University of Seville.

 Some of you already meet me since I work with Apache Manifold in my daily
 job, and I have had to fix, improve and create new connectors and also I
 created some initial idea of processor connector here at work , which
 finally was implemented by Karl as Transformation connector stuff. so I
 have a strong knowledge about the ManifoldCF project.

 I also use Confluence at work and I had to integrate it with Atlassian
 Crowd (a solution for authentication/authorization from Atlassian) so I
 have also a good understanding on Confluence API and how it works.
 I did my last two GSoCs projects within the Apache Stanbol project and I
 also had to integrate it with Manifold at work as well. You can check my
 github account [1] for more information about such projects.

 Now, I'm most focused on extending ManifoldCF features, so I think it is a
 great opportunity to collaborate directly inside ManifoldCF community.

 Regards

 [1] https://github.com/adperezmorales

 --

 --
 This message should be regarded as confidential. If you have received this
 email in error please notify the sender and destroy it immediately.
 Statements of intent shall only become binding when confirmed in hard copy
 by an authorised signatory.

 Zaizi Ltd is registered in England and Wales with the registration number
 6440931. The Registered Office is Brook House, 229 Shepherds Bush Road,
 London W6 7AN.