from:"Antonio David Pérez Morales"

Re: [ANNOUNCE] Cihad Guzel has joined the ManifoldCF project as a committer

2019-08-21 Thread Antonio David Pérez Morales

Welcome on board Cihad

El mar., 20 ago. 2019 20:51, Kishore Kumar 
escribió:

> Welcome to the team, Cihad.
>
> Regards,
> Kishore Kumar
>
> -Original Message-
> From: Karl Wright 
> Sent: 17 August 2019 07:25
> To: dev 
> Subject: [ANNOUNCE] Cihad Guzel has joined the ManifoldCF project as a
> committer
>
> Cihad has had a long association with ManifoldCF and also Project Gora.
> He's now agreed to join us as a committer.  Please welcome him warmly.
>
> Karl
>

Re: [VOTE] Release Apache ManifoldCF 2.13, RC1

2019-05-01 Thread Antonio David Pérez Morales

Built and ran tests

+1 for me

El mar., 30 abr. 2019 8:34, Karl Wright  escribió:

> Ran tests.
> +1 from me.
> Karl
>
>
> On Mon, Apr 29, 2019 at 4:32 AM Rafa Haro  wrote:
>
> > Downloaded source code and built the release correctly. +1
> >
> > On Thu, Apr 25, 2019 at 11:54 PM Karl Wright  wrote:
> >
> > > Please vote on whether to release Apache ManifoldCF 2.13, RC0.  The
> > release
> > > artifact can be found at:
> > >
> https://dist.apache.org/repos/dist/dev/manifoldcf/apache-manifoldcf-2.13
> > .
> > > There is also a release tag at
> > > https://svn.apache.org/repos/asf/manifoldcf/tags/release-2.13-RC1.
> > >
> > > This release contains primarily a redeveloped Jcifs connector, to work
> > with
> > > jcifs-ng, plus a modest number of bug fixes.
> > >
> > > The release has been respun due to a syntax error in the jcifs
> connector
> > > pom.
> > >
> > > Karl
> > >
> >
>

Re: [VOTE] Release Apache ManifoldCF 2.9, RC1

2017-12-19 Thread Antonio David Pérez Morales

+1 from me.

build, ran tests and quick UI test.

Regards

2017-12-19 9:20 GMT+01:00 Furkan KAMACI :

> +1 from me.
>
> Compiled project, ran tests and tested UI.
>
> Kind Regards,
> Furkan KAMACI
>
> On Mon, Dec 18, 2017 at 5:30 PM, Piergiorgio Lucidi <
> piergior...@apache.org>
> wrote:
>
> > +1 from me.
> >
> > Ran tests and started a job using the UI with proprietary and standard
> > example.
> >
> > PJ
> >
> > 2017-12-16 19:58 GMT+01:00 Karl Wright :
> >
> > > Please vote on whether to release Apache ManifoldCF 2.9, RC1.
> > >
> > > This release includes many bug fixes, as well as the Rocket Chat
> > > Notification Connector.
> > >
> > > The release artifact can be downloaded from:
> > > https://dist.apache.org/repos/dist/dev/manifoldcf/apache-
> manifoldcf-2.9
> > >
> > > There is also an svn tag at:
> > > https://svn.apache.org/repos/asf/manifoldcf/tags/release-2.9-RC1
> > >
> > > This also includes a fix for CONNECTORS-1477 (mislabeled
> CONNECTORS-1474
> > in
> > > the CHANGES.txt file unfortunately).
> > >
> > > Thanks!
> > > Karl
> > >
> >
> >
> >
> > --
> > Piergiorgio Lucidi
> > Open Source Evangelist and Enterprise Information Management Specialist
> > Mentor / PMC Member / Committer @ Apache Software Foundation
> > Community Star / Wiki Gardener / Global Forum Moderator @ Alfresco
> > Author and Technical Reviewer @ Packt Publishing
> > Technical Advisory Group Member @ Microsoft
> > Top Community Contributor @ Crafter
> > Project Leader / Committer @ JBoss
> > https://www.open4dev.com
> >
>

Re: [VOTE] Release Apache ManifoldCF 2.8, RC0

2017-08-16 Thread Antonio David Pérez Morales

Hi,

Ran the tests and ran a job

+1 from my side

2017-08-16 5:20 GMT+02:00 Shinichiro Abe :

> Hi,
>
> Ran tests, unpacked the bin and ran a job.
>
> +1 from me.
>
> Shinichiro Abe
>
> 2017-08-15 18:08 GMT+09:00 Karl Wright :
>
> > Please vote on whether to release Apache ManifoldCF version 2.8, RC0.
> >
> > The release artifacts can be found at:
> >
> > https://dist.apache.org/repos/dist/dev/manifoldcf/apache-manifoldcf-2.8
> >
> > There is also a tag at:
> >
> > https://svn.apache.org/repos/asf/manifoldcf/tags/release-2.8-RC0
> >
> > This release includes a new connector (for Nuxeo), as well as many
> > significant bug
> > fixes for the new UI and for many individual connectors.  Please check it
> > out!
> >
> > Thanks,
> >
> > Karl
> >
>

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

2016-08-29 Thread 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 :

> 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  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: Confluence Connector gives wrong WebUrl

2016-07-13 Thread Antonio David Pérez Morales

Hi all

Thanks for taking a look Chalitha.

I am out this week but I will take a look when I come back in order to see
if your patch works with previous versions as well.

Regards
El 12 jul. 2016 11:24 p. m., "Chalitha Perera"  escribió:

> Hi Rafa,
>
> At the moment I only have access to confluence enterprise version 5.7 and
> trial version 5.10.
> I have checked with the both.
> Could not yet check with versions before 5.
>
> Thanks,
> Chalitha
>
> On Tue, Jul 12, 2016 at 4:58 PM, Karl Wright  wrote:
>
> > I committed the patch, but obviously if there's a version dependency
> we'll
> > need to add a switch for that in the connector.
> >
> > Karl
> >
> >
> > On Tue, Jul 12, 2016 at 4:03 AM, Rafa Haro  wrote:
> >
> > > Hi Chalitha,
> > >
> > > Thanks for the patch! Could you confirm please that URL is not
> depending
> > on
> > > different confluence versions and it is always the same ?
> > >
> > > Cheers,
> > >
> > > Rafa
> > > El El mar, 12 jul 2016 a las 7:16, Chalitha Perera 
> > > escribió:
> > >
> > > > As attachments are not working with mail. Please follow the ticket on
> > > this
> > > > issue
> > > > https://issues.apache.org/jira/browse/CONNECTORS-1326
> > > >
> > > > Thanks,
> > > > Chalitha
> > > >
> > > > On Tue, Jul 12, 2016 at 10:32 AM, Chalitha Perera  >
> > > > wrote:
> > > >
> > > > > Hi All,
> > > > >
> > > > > We found a small issue in Confluence connector. For weburl, url
> > context
> > > > > gets replicated.
> > > > > E.g.
> > > > > https://{Host}/confluence/confluence/display/{page}
> > > > >
> > > > > It should be
> > > > > https://{Host}/confluence/display/{page}
> > > > >
> > > > > Here I have attached a temporary fix for this issue.
> > > > >
> > > > > @Antonio: Can you please have a look ?
> > > > >
> > > > > Thanks,
> > > > > Chalitha
> > > > >
> > > >
> > > > --
> > > >
> > > > --
> > > > 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: CONNECTORS-1290 [GSOC 2016] Nuxeo repository and Authority connector for Apache ManifoldCF

2016-06-10 Thread 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 :

> 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: [VOTE] Release Apache ManifoldCF 2.4, RC0

2016-04-20 Thread Antonio David Pérez Morales

Hi all

ran all the tests.

+1 from my side

Agree with Rafa about Spanish translations. They should be improved a lot

Regards

2016-04-20 12:11 GMT+02:00 Piergiorgio Lucidi :

> Hi,
>
> ran all the tests.
>
> +1 from me
>
> Piergiorgio
>
> 2016-04-19 11:37 GMT+02:00 Rafa Haro :
>
> > Hi devs,
> >
> > Taking a deeper look to the Spanish Translation, it is a little bit
> > strange. I wasn't able to understand most of it and I am native Spanish
> > speaker. That is probably not enough for rejecting a release, but I'm
> going
> > to create a ticket for improving this myself
> >
> > Cheers,
> > Rafa
> >
> > On Tue, Apr 19, 2016 at 11:22 AM Rafa Haro  wrote:
> >
> >> Hi Karl,
> >>
> >> I was checking directly the binary and, because my browser is configured
> >> with Spanish language, the User Interface is completely in Spanish,
> which
> >> is totally ok. The problem is that there is some issue with the
> >> codification that typically affect latin characters like accents. I have
> >> attached a screenshot with the codification errors. I have tested with
> >> different browser and also changing the codification in the browser is
> not
> >> working. This is probably due to the codification of the locale files
> >>
> >> I probably should create a Jira issue for this, but I would like others
> >> to take a look on this.
> >>
> >> Cheers,
> >> [image: Captura de pantalla 2016-04-19 a las 11.22.00.png]Rafa
> >>
> >> On Sun, Apr 17, 2016 at 11:12 PM Karl Wright 
> wrote:
> >>
> >>> Please vote on whether to release Apache ManifoldCF 2.4, RC0.  The
> >>> release
> >>> artifacts can be found at:
> >>>
> >>>
> https://dist.apache.org/repos/dist/dev/manifoldcf/apache-manifoldcf-2.4
> >>>
> >>> There is also a release tag at:
> >>>
> >>> https://svn.apache.org/repos/asf/manifoldcf/tags/release-2.4-RC0
> >>>
> >>> This release contains mainly bug fixes.  The bugs fixed are listed in
> >>> CHANGES.txt.
> >>>
> >>> Thanks,
> >>> Karl
> >>>
> >>
>
>
> --
> Piergiorgio Lucidi
> Open Source Tech Master of Enterprise Information Management @ Sourcesense
> Author and Technical Reviewer @ Packt Publishing
> http://www.open4dev.com
>

Re: Gsoc 2016

2016-03-19 Thread 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

2016-03-18 Thread 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

2016-03-18 Thread 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

2016-03-15 Thread 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

2016-03-15 Thread 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 :

> 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: ManifoldCF transformation connector for Apache Stanbol

2015-11-13 Thread Antonio David Pérez Morales

Hi

The removal of the SolrWrapper is a must. It was a requirement for an
internal project which has nothing to do here with a normal operation of
Manifold, so forcing the users to use Solr does not fit the Manifold
philosophy.

In my opinion, at this moment, a Stanbol connector with such a big
dependency which will not fit almost any use case is not very useful.

You should think a way to convert Stanbol connector into a normal
Transformation connector without assuming that a specific output connector
will be used.

Regards


2015-11-13 11:20 GMT+01:00 Dileepa Jayakody <djayak...@zaizi.com>:

> Hi guys,
>
> I have developed a Stanbol connector for MCF. You can check it out from our
> github repo here:
>
> https://github.com/zaizi/sensefy-connectors/tree/master/transformation/mcf-stanbol-connector
>
> It requires the SolrWrapper output connector which indexes enhanced
> documents, entities and entityTypes in separate Solr cores. Basically it
> requires 3 separate solr cores configured with a specific Solr schema for
> primary documents, entities and entityTypes separately. This was done for
> our specific use-case.
>
> The SolrWrapper code is here :
>
> https://github.com/zaizi/sensefy-connectors/tree/master/output/mcf-solrwrapperconnector
>
> Perhaps we can discuss and remove the Stanbol connector's dependency with
> SolrWrapper and have it working with any output connector.
> Please note that the Stanbol connector currently has a bug in the UI
> (editSpecification) which I'm working on at the moment. After fixing that I
> will update here. And also I will provide documentations for configuring
> the connector.
>
> Thanks,
> Dileepa
>
> On Thu, Jul 9, 2015 at 8:36 PM, Antonio David Pérez Morales <
> adperezmora...@gmail.com> wrote:
>
> > Hi Joshua
> >
> > It is not the list for that, but Marmotta is already integrated in Apache
> > Stanbol. You can take a look at this issue
> > https://issues.apache.org/jira/browse/STANBOL-1165 .
> >
> > Anyway, as I said this is not the list for that, so let's use the proper
> > list for these things.
> >
> > Regards
> >
> >
> >
> > 2015-07-09 15:29 GMT+02:00 Joshua Dunham <joshua.dun...@gmail.com>:
> >
> > > Hey Dileepa,
> > >
> > >   In case you were interested, I pinged the list a few days ago
> > asking
> > > for integration tips for Apache Marmotta.
> > >
> > > I got some great tips on how to do this which could help you. Since
> > > Marmotta is a drop in replacement for Clarezza on Stanbol it may be
> > easier
> > > for you to take this way.
> > >
> > > I'm not a Java programmer but I'm bringing this problem to the
> > development
> > > staff at my company for assistance. If you like the Marmotta approach
> we
> > > may gain more traction solving the same integration.
> > >
> > > I'm also integrating Marmotta with Stanbol so the effect would be the
> > same
> > > except not using the Stanbol API for data import in favor of Marmotta.
> > >
> > > Best,
> > >
> > > -J
> > >
> > > > On Jul 9, 2015, at 1:03 AM, Dileepa Jayakody <djayak...@zaizi.com>
> > > wrote:
> > > >
> > > > Hi all,
> > > >
> > > > Thanks you for the feedback and offering your help in this.
> > > > Let me get back to you on where to start the code base.
> > > > As the first step, I would like to start by creating a architecture
> > > diagram
> > > > for the connector.
> > > > I will send the diagram for your review soon.
> > > >
> > > > Thanks,
> > > > Dileepa
> > > >
> > > > --
> > > >
> > > > --
> > > > 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: [VOTE] Release respin of Apache ManifoldCF 1.10

2015-09-08 Thread Antonio David Pérez Morales

+1

2015-09-08 14:48 GMT+01:00 Karl Wright :

> This release has no source code changes at all vs. the 1.10 release we just
> voted on.  It is just a respin to include the documentation.
>
> Please vote +1 to accept these new release artifacts.  They can be found at
> https://dist.apache.org/repos/dist/dev/manifoldcf/apache-manifoldcf-1.10 .
>
> Thanks!
> Karl
>

Re: [VOTE] Release respin of Apache ManifoldCF 2.2

2015-09-08 Thread Antonio David Pérez Morales

+1

2015-09-08 14:50 GMT+01:00 Karl Wright :

> This release has no source code changes at all vs. the 1.10 release we just
> voted on.  It is just a respin to include the documentation.
>
> Please vote +1 to accept these new release artifacts.  They can be found at
> https://dist.apache.org/repos/dist/dev/manifoldcf/apache-manifoldcf-2.2 .
>
> Thanks!
> Karl
>

Re: [VOTE] Release Apache ManifoldCF 1.10 RC0

2015-09-04 Thread Antonio David Pérez Morales

Hi

Ran tests and ran examples.

+1 from me.

Regards


2015-09-03 18:20 GMT+02:00 Ahmet Arslan :

> Hi,
>
> Check signatures and ran 'ant test'.
>
> +1 from me.
>
> Ahmet
>
>
>
> On Wednesday, September 2, 2015 12:58 PM, Karl Wright 
> wrote:
> I'd like to add that this is the last *scheduled* 1.x release, so it makes
> sense to be extra cautious about its quality.
>
> Thanks!
> Karl
>
>
> On Wed, Sep 2, 2015 at 5:51 AM, Rafa Haro  wrote:
>
> > Please vote on whether to release Apache ManifoldCF 2.2, RC0.
> >
> >
> > The artifacts can be found at:
> >
> >
> https://dist.apache.org/repos/dist/dev/manifoldcf/apache-manifoldcf-1.10/
> >
> >
> > There is also a tag at:
> >
> >
> > https://svn.apache.org/repos/asf/manifoldcf/tags/release-1.10-RC0/
> >
> >
> >
> > NOTE: This release contains several fixes and modifications.
> > The entire list can be seen in CHANGES.txt. Some new features for Tika
> and
> > Metadata Adjuster Transformation connectors have been included also
> >
> > Thanks,
> > Rafa Haro
> >
>

Re: [GSoC] Confluence Authority Connector

2015-08-12 Thread Antonio David Pérez Morales

Hi all again

Patch attached to Jira issue [1]. Please test the patch and let me know if
further changes are needed.

Regards

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

2015-08-12 13:24 GMT+02:00 Antonio David Pérez Morales 
adperezmora...@gmail.com:

 Hi all

 I have continued working on all the things commented in the Jira issue
 [1]. After Rafa tested both connectors, we identified some bugs to fix and
 some improvements which have already been implemented and committed in the
 GitHub repository in the develop branch [2] which will be merged to master
 early next week if no further modifications are needed.

 Moreover I have tested the connector building inside ManifoldCF framework
 both Maven based and Ant based.
 For Maven building, there is only necessary to add the new confluence
 connector as a new Maven module in connectors/pom.xml file.
 For Ant building, a new build.xml file is provided in the project to build
 and register repository and authority connectors in the connectors.xml file
 . While building ManifoldCF with the new connector with ant, it fails due
 to Guava is not present in the building classpath. To fix that, I have
 extended the connector-classpath path at connector-build.xml file with the
 Guava dependency located under connector-lib (after executing
 make-core-deps target). After that fix, executing ant build finishes
 successfully.

 Rafa, Karl, I can provide a patch over the latest code in trunk and attach
 it to the Jira issue [1] so that you guys can apply it and test before
 merging and committing to trunk.
 What do you think?

 Regards

 

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

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

 2015-08-05 18:30 GMT+02:00 Rafa Haro rharoapa...@gmail.com:

 Hi all,




 I’m having some issues for testing the connector against a cloud
 instance. Apparently it could be something related to permissions for using
 the REST API for my atlassian user in our instance. I have discussed this
 with the administrator of our Atlassian Cloud instance and he will check if
 there is any granting option for using the REST API for the regular users.
 I hope to have more news tomorrow about this. Anyway, I will setup a local
 Confluence instance also for testing. The thing is I wanted to test with
 our cloud instance because we have a considerable amount of content, so
 would be a great test.




 Anyway Antonio, as Karl suggested, I think you can proceed with the final
 additions/modifications we agreed yesterday and start preparing the code
 for contributing. I can help with this and also I will probably need to ask
 Karl for some help also. You can include the User Documentation and with
 that plus code comments/documentation I think we can consider the project
 properly documented.




 Cheers,

 Rafa










 On miércoles, ago 5, 2015 at 1:27 p. m., Antonio David Pérez Morales 
 adperezmora...@gmail.com, wrote:
 Hi Karl



 Perfect. Once I finish some things and Rafa finishes his tests, I will

 start with that and I will do some tests adding the whole connector into

 ManifoldCF structure.

 For that, I think it will be useful to merge both Maven modules in order
 to

 have only one project (jar) providing both connectors, but let's wait
 until

 Rafa's response.



 Regards









 2015-08-05 13:06 GMT+02:00 Karl Wright daddy...@gmail.com:



  Hi Antonio,

 

  Only ManifoldCF committers can import the project into Apache svn.

  However, before that happens, you will need to insure the following:

  (1) Directory structure is compatible with connectors under the

  connectors area of ManifoldCF

  (2) There is both a pom.xml and a build.xml that work

  (3) Any additional imports that you need for building using Ant have

  license research done so that we know they can be included in the Apache

  distribution

 

  Thanks!

  Karl

 

 

  On Wed, Aug 5, 2015 at 5:52 AM, Antonio David Pérez Morales 

  adperezmora...@gmail.com wrote:

 

   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

Re: [GSoC] Confluence Authority Connector

2015-08-05 Thread 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

2015-08-05 Thread Antonio David Pérez Morales

Hi Karl

Perfect. Once I finish some things and Rafa finishes his tests, I will
start with that and I will do some tests adding the whole connector into
ManifoldCF structure.
For that, I think it will be useful to merge both Maven modules in order to
have only one project (jar) providing both connectors, but let's wait until
Rafa's response.

Regards




2015-08-05 13:06 GMT+02:00 Karl Wright daddy...@gmail.com:

 Hi Antonio,

 Only ManifoldCF committers can import the project into Apache svn.
 However, before that happens, you will need to insure the following:
 (1) Directory structure is compatible with connectors under the
 connectors area of ManifoldCF
 (2) There is both a pom.xml and a build.xml that work
 (3) Any additional imports that you need for building using Ant have
 license research done so that we know they can be included in the Apache
 distribution

 Thanks!
 Karl


 On Wed, Aug 5, 2015 at 5:52 AM, Antonio David Pérez Morales 
 adperezmora...@gmail.com wrote:

  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

Re: [GSoC] Confluence Authority Connector

2015-08-04 Thread 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

2015-07-23 Thread 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

2015-07-11 Thread 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

2015-07-10 Thread 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: ManifoldCF transformation connector for Apache Stanbol

2015-07-09 Thread Antonio David Pérez Morales

Hi Joshua

It is not the list for that, but Marmotta is already integrated in Apache
Stanbol. You can take a look at this issue
https://issues.apache.org/jira/browse/STANBOL-1165 .

Anyway, as I said this is not the list for that, so let's use the proper
list for these things.

Regards



2015-07-09 15:29 GMT+02:00 Joshua Dunham joshua.dun...@gmail.com:

 Hey Dileepa,

   In case you were interested, I pinged the list a few days ago asking
 for integration tips for Apache Marmotta.

 I got some great tips on how to do this which could help you. Since
 Marmotta is a drop in replacement for Clarezza on Stanbol it may be easier
 for you to take this way.

 I'm not a Java programmer but I'm bringing this problem to the development
 staff at my company for assistance. If you like the Marmotta approach we
 may gain more traction solving the same integration.

 I'm also integrating Marmotta with Stanbol so the effect would be the same
 except not using the Stanbol API for data import in favor of Marmotta.

 Best,

 -J

  On Jul 9, 2015, at 1:03 AM, Dileepa Jayakody djayak...@zaizi.com
 wrote:
 
  Hi all,
 
  Thanks you for the feedback and offering your help in this.
  Let me get back to you on where to start the code base.
  As the first step, I would like to start by creating a architecture
 diagram
  for the connector.
  I will send the diagram for your review soon.
 
  Thanks,
  Dileepa
 
  --
 
  --
  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.

[GSoC] Confluence Authority Connector

2015-07-08 Thread 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.

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

2015-07-08 Thread 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.

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

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

2015-06-27 Thread 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

2015-06-05 Thread 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

[GSoC] Confluence connector project status after bonding period

2015-05-26 Thread 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: [ANNOUNCE] Cihad Guzel has joined the ManifoldCF project as a committer

Re: [VOTE] Release Apache ManifoldCF 2.13, RC1

Re: [VOTE] Release Apache ManifoldCF 2.9, RC1

Re: [VOTE] Release Apache ManifoldCF 2.8, RC0

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

Re: Confluence Connector gives wrong WebUrl

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

Re: [VOTE] Release Apache ManifoldCF 2.4, RC0

Re: Gsoc 2016

Re: Gsoc 2016

Re: Gsoc 2016

Re: Gsoc 2016

Re: Gsoc 2016

Re: ManifoldCF transformation connector for Apache Stanbol

Re: [VOTE] Release respin of Apache ManifoldCF 1.10

Re: [VOTE] Release respin of Apache ManifoldCF 2.2

Re: [VOTE] Release Apache ManifoldCF 1.10 RC0

Re: [GSoC] Confluence Authority Connector

Re: [GSoC] Confluence Authority Connector

Re: [GSoC] Confluence Authority Connector

Re: [GSoC] Confluence Authority Connector

Re: [GSoC] Confluence Authority Connector

Re: [GSoC] Confluence Authority Connector

Re: [GSoC] Confluence Authority Connector

Re: ManifoldCF transformation connector for Apache Stanbol

[GSoC] Confluence Authority Connector

Re: [GSoC] Confluence Authority Connector

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

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

[GSoC] Confluence connector project status after bonding period

30 matches

Site Navigation

Mail list logo

Footer information