Tommaso,
I am more than happy to help out as I did for Annotation Ontology!

Being able to produce UIMA results in Open Annotation format through
Clerezza would be a great use case for the W3C Open annotation Community
Group as well!

Best,
Paolo

On Fri, Mar 1, 2013 at 10:38 AM, Tommaso Teofili
<tommaso.teofili@gmail.com>wrote:

> Hi all,
>
> what would you think of having a first implementation of the Open
> Annotation spec inside Apache Clerezza, probably starting with just
> serializing an OA graph, similarly as what we did for the
> AnnotationOntology [3] in the Clerezza UIMA Cas Consumer [4[5]].
>
> WDYT?
> Regards,
> Tommaso
>
> [1] : http://www.openannotation.org/
> [2] : http://www.w3.org/community/openannotation/
> [3] : https://code.google.com/p/annotation-ontology/
> [4] :
> http://www.slideshare.net/teofili/domeo-text-mining-uima-and-clerezza
> [5] :
>
> http://svn.apache.org/repos/asf/incubator/clerezza/trunk/uima/uima.casconsumer/
>

Hi all,

what would you think of having a first implementation of the Open
Annotation spec inside Apache Clerezza, probably starting with just
serializing an OA graph, similarly as what we did for the
AnnotationOntology [3] in the Clerezza UIMA Cas Consumer [4[5]].

WDYT?
Regards,
Tommaso

[1] : http://www.openannotation.org/
[2] : http://www.w3.org/community/openannotation/
[3] : https://code.google.com/p/annotation-ontology/
[4] : http://www.slideshare.net/teofili/domeo-text-mining-uima-and-clerezza
[5] :
http://svn.apache.org/repos/asf/incubator/clerezza/trunk/uima/uima.casconsumer/

OK Reto,
I'll implement the "sparql pre parser" first.

Best
Hasan

On Tue, Feb 26, 2013 at 4:36 AM, Reto Bachmann-Gmür <reto@apache.org> wrote:

> Hi Hasan
>
> On Tue, Feb 26, 2013 at 4:11 AM, Hasan <hasan@apache.org> wrote:
>
> > > - Create subclass of TcProvider that accepts sparql query as string
> > >
> >
> > Assumed that this string will be used when invoking the underlying engine
> >
> > Yes
>
> >
> > > - Have a minimum parsing of the queries to get the names a query is
> > > directed against
> > >
> >
> > this would be the datasetclause of the "sparql query" and in case of
> > "sparql update"
> > it would be the graphref.
> > So we need a simple parser to extract iri of the affected graphs.
> > How should the interface definition of the parser look like for sparql
> > update?
> >
>
> What about a class SparqlPreParser with a singe method Set<UriRef>
> getReferredGraphs(Sting query). The method should return all graphs the
> query is directed to excluding remote service graph. One issue is the
> default graph, the caller should know if the query explicitly sets a
> default graph. So it would probably better to have Set<UriRef>
> getQueryGraphs(Sting query, UriRef defaulGraph) instead. With this method
> defaultGraph is part of the result if the query has no FROM clause.
>
>
>
> >
> > >
> > > Question:
> > > - Did you already model the results of Sparql 1.1? I think there is no
> > big
> > > difference there to 1.0.
> > >
> >
> > afaik it is the same for query, but a sparql update results in success or
> > failure.
> >
>
> Which is the same as for ASK queries. So the result is an Object that can
> be cast either to a ResultSet, a Graph or a Boolean.
>
>
> Cheers,
> Reto
>

Hi Aaron

Thank you for the information and also for
CLEREZZA-733<https://issues.apache.org/jira/browse/CLEREZZA-733>
I haven't have time to proceed with
CLEREZZA-732<https://issues.apache.org/jira/browse/CLEREZZA-732>.
I'll do it latest this weekend.

Regards
Hasan

On Tue, Feb 26, 2013 at 5:48 PM, Aaron Coburn <acoburn@amherst.edu> wrote:

> You may also want to add a DOAP file for the project [1] -- that way
> Clerezza will be listed on projects.apache.org. The PMC chair will then
> need to send a pointer to the RDF file to infrastructure @apache. This is
> all outlined on the apache website.
>
> Aaron Coburn
>
> [1] http://projects.apache.org/doap.html
>
> On Feb 25, 2013, at 7:36 PM, Hasan (JIRA) <jira@apache.org> wrote:
>
> >
> >     [
> https://issues.apache.org/jira/browse/CLEREZZA-732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel]
> >
> > Hasan updated CLEREZZA-732:
> > ---------------------------
> >
> >    Description:
> > Once appointed, the new Chair needs to:
> >
> > a. Subscribe to the board mailing list
> > DONE
> >
> > b. Subscribe to the infrastructure mailing list
> > DONE
> >
> > c. Ensure that they have been added to the PMC chairs group (pmc-chairs)
> in LDAP.
> > DONE
> >
> > d. Check out the foundation/officers folder from the private repository.
> Users with member or pmc-chairs karma can do this.
> > DONE
> >
> > e. Add yourself to the foundation/officers/affiliations.txt and the
> foundation/officers/irs-disclosures.txt files with the appropriate
> information.
> > DONE
> >
> > f. Review appropriate documentation:
> > - PMC Chair Duties
> > - PMC documentation
> > - Jakarta Chair guide
> > - Incubator Chair guide
> > - Reporting calendar
> >
> > g. Work out a reporting schedule with the Board. For the first three
> months after graduation this will be monthly. After that, the project
> should slot into a quarterly reporting schedule. Now is a good time to
> remove the project from the Incubator reporting schedule.
> >
> > h. Work with the Apache Infrastructure team to set up the top level
> project infrastructure. The various infrastructure tasks that are required
> (see check list) should be consolidated into a single issue (see this for
> example). This should be created in the category TLP Admin.
> >
> > i. Add the PMC chair details to the foundation web site Officer list at
> http://www.apache.org/foundation/index.html
> > DONE
> >
> > j. Add the new project's PMC chair to the
> foundation/officers/irs-disclosures.txt file. You will need a member to
> help with this task.
> > ??? same as e ?
> >
> > k. Ensure the PMC is added to the committee-info.txt file at
> https://svn.apache.org/repos/private/committers/board/committee-info.txt
> > There are 3 sections which need to be updated; see instructions in the
> file. You may need to get a member to help with this.
> > DONE
> >
> > l. They should then be able to start assembling the new PMC. The
> starting membership is listed in the resolution. However, the Chair of the
> new project needs to ensure that private list is created and the membership
> subscribed.
> >
> >
> > Members of the new PMC need to:
> > 1. Subscribe to the private mailing list for the project
> > 2. Review appropriate documentation:
> > - Apache PMC Guide
> > - Related documentation
> >
> > Once all this is in place, resources can start to be handed over to the
> new project.
> >
> >
> >  was:
> > Once appointed, the new Chair needs to:
> >
> > a. Subscribe to the board mailing list
> > b. Subscribe to the infrastructure mailing list
> > c. Ensure that they have been added to the PMC chairs group (pmc-chairs)
> in LDAP.
> > d. Check out the foundation/officers folder from the private repository.
> Users with member or pmc-chairs karma can do this.
> > e. Add yourself to the foundation/officers/affiliations.txt and the
> foundation/officers/irs-disclosures.txt files with the appropriate
> information.
> > f. Review appropriate documentation:
> > - PMC Chair Duties
> > - PMC documentation
> > - Jakarta Chair guide
> > - Incubator Chair guide
> > - Reporting calendar
> > g. Work out a reporting schedule with the Board. For the first three
> months after graduation this will be monthly. After that, the project
> should slot into a quarterly reporting schedule. Now is a good time to
> remove the project from the Incubator reporting schedule.
> > h. Work with the Apache Infrastructure team to set up the top level
> project infrastructure. The various infrastructure tasks that are required
> (see check list) should be consolidated into a single issue (see this for
> example). This should be created in the category TLP Admin.
> > i. Add the PMC chair details to the foundation web site Officer list at
> http://www.apache.org/foundation/index.html
> > j. Add the new project's PMC chair to the
> foundation/officers/irs-disclosures.txt file. You will need a member to
> help with this task.
> > k. Ensure the PMC is added to the committee-info.txt file at
> https://svn.apache.org/repos/private/committers/board/committee-info.txt
> > There are 3 sections which need to be updated; see instructions in the
> file. You may need to get a member to help with this.
> >
> > They should then be able to start assembling the new PMC. The starting
> membership is listed in the resolution. However, the Chair of the new
> project needs to ensure that private list is created and the membership
> subscribed.
> >
> >
> > Members of the new PMC need to:
> > 1. Subscribe to the private mailing list for the project
> > 2. Review appropriate documentation:
> > - Apache PMC Guide
> > - Related documentation
> >
> > Once all this is in place, resources can start to be handed over to the
> new project.
> >
> >
> >
> >> Tasks to be performed after graduation
> >> --------------------------------------
> >>
> >>                Key: CLEREZZA-732
> >>                URL: https://issues.apache.org/jira/browse/CLEREZZA-732
> >>            Project: Clerezza
> >>         Issue Type: Task
> >>           Reporter: Hasan
> >>           Assignee: Hasan
> >>
> >> Once appointed, the new Chair needs to:
> >> a. Subscribe to the board mailing list
> >> DONE
> >> b. Subscribe to the infrastructure mailing list
> >> DONE
> >> c. Ensure that they have been added to the PMC chairs group
> (pmc-chairs) in LDAP.
> >> DONE
> >> d. Check out the foundation/officers folder from the private
> repository. Users with member or pmc-chairs karma can do this.
> >> DONE
> >> e. Add yourself to the foundation/officers/affiliations.txt and the
> foundation/officers/irs-disclosures.txt files with the appropriate
> information.
> >> DONE
> >> f. Review appropriate documentation:
> >> - PMC Chair Duties
> >> - PMC documentation
> >> - Jakarta Chair guide
> >> - Incubator Chair guide
> >> - Reporting calendar
> >> g. Work out a reporting schedule with the Board. For the first three
> months after graduation this will be monthly. After that, the project
> should slot into a quarterly reporting schedule. Now is a good time to
> remove the project from the Incubator reporting schedule.
> >> h. Work with the Apache Infrastructure team to set up the top level
> project infrastructure. The various infrastructure tasks that are required
> (see check list) should be consolidated into a single issue (see this for
> example). This should be created in the category TLP Admin.
> >> i. Add the PMC chair details to the foundation web site Officer list at
> http://www.apache.org/foundation/index.html
> >> DONE
> >> j. Add the new project's PMC chair to the
> foundation/officers/irs-disclosures.txt file. You will need a member to
> help with this task.
> >> ??? same as e ?
> >> k. Ensure the PMC is added to the committee-info.txt file at
> https://svn.apache.org/repos/private/committers/board/committee-info.txt
> >> There are 3 sections which need to be updated; see instructions in the
> file. You may need to get a member to help with this.
> >> DONE
> >> l. They should then be able to start assembling the new PMC. The
> starting membership is listed in the resolution. However, the Chair of the
> new project needs to ensure that private list is created and the membership
> subscribed.
> >> Members of the new PMC need to:
> >> 1. Subscribe to the private mailing list for the project
> >> 2. Review appropriate documentation:
> >> - Apache PMC Guide
> >> - Related documentation
> >> Once all this is in place, resources can start to be handed over to the
> new project.
> >
> > --
> > This message is automatically generated by JIRA.
> > If you think it was sent incorrectly, please contact your JIRA
> administrators
> > For more information on JIRA, see:
> http://www.atlassian.com/software/jira
>
>

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

Aaron Coburn updated CLEREZZA-733:
----------------------------------

    Attachment: doap_Clerezza.rdf
    
> Project DOAP file
> -----------------
>
>                 Key: CLEREZZA-733
>                 URL: https://issues.apache.org/jira/browse/CLEREZZA-733
>             Project: Clerezza
>          Issue Type: Improvement
>            Reporter: Aaron Coburn
>            Priority: Minor
>         Attachments: doap_Clerezza.rdf
>
>
> Many apache projects include DOAP files, which are used to populate the projects.apache.org
page. Details are available at http://projects.apache.org/doap.html
> Attached is a sample DOAP file with some information taken from the clerezza website.
Someone else may wish to add additional data. In any case, the attached DOAP points to the
existing incubator source repository -- that will need to be changed.
> The PMC chair will need to inform infrastructure about the location of the DOAP file.


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Aaron Coburn created CLEREZZA-733:
-------------------------------------

             Summary: Project DOAP file
                 Key: CLEREZZA-733
                 URL: https://issues.apache.org/jira/browse/CLEREZZA-733
             Project: Clerezza
          Issue Type: Improvement
            Reporter: Aaron Coburn
            Priority: Minor


Many apache projects include DOAP files, which are used to populate the projects.apache.org
page. Details are available at http://projects.apache.org/doap.html

Attached is a sample DOAP file with some information taken from the clerezza website. Someone
else may wish to add additional data. In any case, the attached DOAP points to the existing
incubator source repository -- that will need to be changed.

The PMC chair will need to inform infrastructure about the location of the DOAP file. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

You may also want to add a DOAP file for the project [1] -- that way Clerezza will be listed
on projects.apache.org. The PMC chair will then need to send a pointer to the RDF file to
infrastructure @apache. This is all outlined on the apache website.

Aaron Coburn

[1] http://projects.apache.org/doap.html

On Feb 25, 2013, at 7:36 PM, Hasan (JIRA) <jira@apache.org> wrote:

> 
>     [ https://issues.apache.org/jira/browse/CLEREZZA-732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
> 
> Hasan updated CLEREZZA-732:
> ---------------------------
> 
>    Description: 
> Once appointed, the new Chair needs to:
> 
> a. Subscribe to the board mailing list
> DONE
> 
> b. Subscribe to the infrastructure mailing list
> DONE
> 
> c. Ensure that they have been added to the PMC chairs group (pmc-chairs) in LDAP.
> DONE
> 
> d. Check out the foundation/officers folder from the private repository. Users with member
or pmc-chairs karma can do this.
> DONE
> 
> e. Add yourself to the foundation/officers/affiliations.txt and the foundation/officers/irs-disclosures.txt
files with the appropriate information.
> DONE
> 
> f. Review appropriate documentation:
> - PMC Chair Duties
> - PMC documentation
> - Jakarta Chair guide
> - Incubator Chair guide
> - Reporting calendar
> 
> g. Work out a reporting schedule with the Board. For the first three months after graduation
this will be monthly. After that, the project should slot into a quarterly reporting schedule.
Now is a good time to remove the project from the Incubator reporting schedule.
> 
> h. Work with the Apache Infrastructure team to set up the top level project infrastructure.
The various infrastructure tasks that are required (see check list) should be consolidated
into a single issue (see this for example). This should be created in the category TLP Admin.
> 
> i. Add the PMC chair details to the foundation web site Officer list at http://www.apache.org/foundation/index.html
> DONE
> 
> j. Add the new project's PMC chair to the foundation/officers/irs-disclosures.txt file.
You will need a member to help with this task.
> ??? same as e ?
> 
> k. Ensure the PMC is added to the committee-info.txt file at https://svn.apache.org/repos/private/committers/board/committee-info.txt
> There are 3 sections which need to be updated; see instructions in the file. You may
need to get a member to help with this.
> DONE
> 
> l. They should then be able to start assembling the new PMC. The starting membership
is listed in the resolution. However, the Chair of the new project needs to ensure that private
list is created and the membership subscribed.
> 
> 
> Members of the new PMC need to:
> 1. Subscribe to the private mailing list for the project
> 2. Review appropriate documentation:
> - Apache PMC Guide
> - Related documentation
> 
> Once all this is in place, resources can start to be handed over to the new project.
> 
> 
>  was:
> Once appointed, the new Chair needs to:
> 
> a. Subscribe to the board mailing list
> b. Subscribe to the infrastructure mailing list
> c. Ensure that they have been added to the PMC chairs group (pmc-chairs) in LDAP.
> d. Check out the foundation/officers folder from the private repository. Users with member
or pmc-chairs karma can do this.
> e. Add yourself to the foundation/officers/affiliations.txt and the foundation/officers/irs-disclosures.txt
files with the appropriate information.
> f. Review appropriate documentation:
> - PMC Chair Duties
> - PMC documentation
> - Jakarta Chair guide
> - Incubator Chair guide
> - Reporting calendar
> g. Work out a reporting schedule with the Board. For the first three months after graduation
this will be monthly. After that, the project should slot into a quarterly reporting schedule.
Now is a good time to remove the project from the Incubator reporting schedule.
> h. Work with the Apache Infrastructure team to set up the top level project infrastructure.
The various infrastructure tasks that are required (see check list) should be consolidated
into a single issue (see this for example). This should be created in the category TLP Admin.
> i. Add the PMC chair details to the foundation web site Officer list at http://www.apache.org/foundation/index.html
> j. Add the new project's PMC chair to the foundation/officers/irs-disclosures.txt file.
You will need a member to help with this task.
> k. Ensure the PMC is added to the committee-info.txt file at https://svn.apache.org/repos/private/committers/board/committee-info.txt
> There are 3 sections which need to be updated; see instructions in the file. You may
need to get a member to help with this.
> 
> They should then be able to start assembling the new PMC. The starting membership is
listed in the resolution. However, the Chair of the new project needs to ensure that private
list is created and the membership subscribed.
> 
> 
> Members of the new PMC need to:
> 1. Subscribe to the private mailing list for the project
> 2. Review appropriate documentation:
> - Apache PMC Guide
> - Related documentation
> 
> Once all this is in place, resources can start to be handed over to the new project.
> 
> 
> 
>> Tasks to be performed after graduation
>> --------------------------------------
>> 
>>                Key: CLEREZZA-732
>>                URL: https://issues.apache.org/jira/browse/CLEREZZA-732
>>            Project: Clerezza
>>         Issue Type: Task
>>           Reporter: Hasan
>>           Assignee: Hasan
>> 
>> Once appointed, the new Chair needs to:
>> a. Subscribe to the board mailing list
>> DONE
>> b. Subscribe to the infrastructure mailing list
>> DONE
>> c. Ensure that they have been added to the PMC chairs group (pmc-chairs) in LDAP.
>> DONE
>> d. Check out the foundation/officers folder from the private repository. Users with
member or pmc-chairs karma can do this.
>> DONE
>> e. Add yourself to the foundation/officers/affiliations.txt and the foundation/officers/irs-disclosures.txt
files with the appropriate information.
>> DONE
>> f. Review appropriate documentation:
>> - PMC Chair Duties
>> - PMC documentation
>> - Jakarta Chair guide
>> - Incubator Chair guide
>> - Reporting calendar
>> g. Work out a reporting schedule with the Board. For the first three months after
graduation this will be monthly. After that, the project should slot into a quarterly reporting
schedule. Now is a good time to remove the project from the Incubator reporting schedule.
>> h. Work with the Apache Infrastructure team to set up the top level project infrastructure.
The various infrastructure tasks that are required (see check list) should be consolidated
into a single issue (see this for example). This should be created in the category TLP Admin.
>> i. Add the PMC chair details to the foundation web site Officer list at http://www.apache.org/foundation/index.html
>> DONE
>> j. Add the new project's PMC chair to the foundation/officers/irs-disclosures.txt
file. You will need a member to help with this task.
>> ??? same as e ?
>> k. Ensure the PMC is added to the committee-info.txt file at https://svn.apache.org/repos/private/committers/board/committee-info.txt
>> There are 3 sections which need to be updated; see instructions in the file. You
may need to get a member to help with this.
>> DONE
>> l. They should then be able to start assembling the new PMC. The starting membership
is listed in the resolution. However, the Chair of the new project needs to ensure that private
list is created and the membership subscribed.
>> Members of the new PMC need to:
>> 1. Subscribe to the private mailing list for the project
>> 2. Review appropriate documentation:
>> - Apache PMC Guide
>> - Related documentation
>> Once all this is in place, resources can start to be handed over to the new project.
> 
> --
> This message is automatically generated by JIRA.
> If you think it was sent incorrectly, please contact your JIRA administrators
> For more information on JIRA, see: http://www.atlassian.com/software/jira

Hi Hasan

On Tue, Feb 26, 2013 at 4:11 AM, Hasan <hasan@apache.org> wrote:

> > - Create subclass of TcProvider that accepts sparql query as string
> >
>
> Assumed that this string will be used when invoking the underlying engine
>
> Yes

>
> > - Have a minimum parsing of the queries to get the names a query is
> > directed against
> >
>
> this would be the datasetclause of the "sparql query" and in case of
> "sparql update"
> it would be the graphref.
> So we need a simple parser to extract iri of the affected graphs.
> How should the interface definition of the parser look like for sparql
> update?
>

What about a class SparqlPreParser with a singe method Set<UriRef>
getReferredGraphs(Sting query). The method should return all graphs the
query is directed to excluding remote service graph. One issue is the
default graph, the caller should know if the query explicitly sets a
default graph. So it would probably better to have Set<UriRef>
getQueryGraphs(Sting query, UriRef defaulGraph) instead. With this method
defaultGraph is part of the result if the query has no FROM clause.



>
> >
> > Question:
> > - Did you already model the results of Sparql 1.1? I think there is no
> big
> > difference there to 1.0.
> >
>
> afaik it is the same for query, but a sparql update results in success or
> failure.
>

Which is the same as for ASK queries. So the result is an Object that can
be cast either to a ResultSet, a Graph or a Boolean.


Cheers,
Reto

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

Hasan updated CLEREZZA-732:
---------------------------

    Description: 
Once appointed, the new Chair needs to:

a. Subscribe to the board mailing list
DONE

b. Subscribe to the infrastructure mailing list
DONE

c. Ensure that they have been added to the PMC chairs group (pmc-chairs) in LDAP.
DONE

d. Check out the foundation/officers folder from the private repository. Users with member
or pmc-chairs karma can do this.
DONE

e. Add yourself to the foundation/officers/affiliations.txt and the foundation/officers/irs-disclosures.txt
files with the appropriate information.
DONE

f. Review appropriate documentation:
- PMC Chair Duties
- PMC documentation
- Jakarta Chair guide
- Incubator Chair guide
- Reporting calendar

g. Work out a reporting schedule with the Board. For the first three months after graduation
this will be monthly. After that, the project should slot into a quarterly reporting schedule.
Now is a good time to remove the project from the Incubator reporting schedule.

h. Work with the Apache Infrastructure team to set up the top level project infrastructure.
The various infrastructure tasks that are required (see check list) should be consolidated
into a single issue (see this for example). This should be created in the category TLP Admin.

i. Add the PMC chair details to the foundation web site Officer list at http://www.apache.org/foundation/index.html
DONE

j. Add the new project's PMC chair to the foundation/officers/irs-disclosures.txt file. You
will need a member to help with this task.
??? same as e ?

k. Ensure the PMC is added to the committee-info.txt file at https://svn.apache.org/repos/private/committers/board/committee-info.txt
There are 3 sections which need to be updated; see instructions in the file. You may need
to get a member to help with this.
DONE

l. They should then be able to start assembling the new PMC. The starting membership is listed
in the resolution. However, the Chair of the new project needs to ensure that private list
is created and the membership subscribed.


Members of the new PMC need to:
1. Subscribe to the private mailing list for the project
2. Review appropriate documentation:
- Apache PMC Guide
- Related documentation

Once all this is in place, resources can start to be handed over to the new project.


  was:
Once appointed, the new Chair needs to:

a. Subscribe to the board mailing list
b. Subscribe to the infrastructure mailing list
c. Ensure that they have been added to the PMC chairs group (pmc-chairs) in LDAP.
d. Check out the foundation/officers folder from the private repository. Users with member
or pmc-chairs karma can do this.
e. Add yourself to the foundation/officers/affiliations.txt and the foundation/officers/irs-disclosures.txt
files with the appropriate information.
f. Review appropriate documentation:
- PMC Chair Duties
- PMC documentation
- Jakarta Chair guide
- Incubator Chair guide
- Reporting calendar
g. Work out a reporting schedule with the Board. For the first three months after graduation
this will be monthly. After that, the project should slot into a quarterly reporting schedule.
Now is a good time to remove the project from the Incubator reporting schedule.
h. Work with the Apache Infrastructure team to set up the top level project infrastructure.
The various infrastructure tasks that are required (see check list) should be consolidated
into a single issue (see this for example). This should be created in the category TLP Admin.
i. Add the PMC chair details to the foundation web site Officer list at http://www.apache.org/foundation/index.html
j. Add the new project's PMC chair to the foundation/officers/irs-disclosures.txt file. You
will need a member to help with this task.
k. Ensure the PMC is added to the committee-info.txt file at https://svn.apache.org/repos/private/committers/board/committee-info.txt
There are 3 sections which need to be updated; see instructions in the file. You may need
to get a member to help with this.

They should then be able to start assembling the new PMC. The starting membership is listed
in the resolution. However, the Chair of the new project needs to ensure that private list
is created and the membership subscribed.


Members of the new PMC need to:
1. Subscribe to the private mailing list for the project
2. Review appropriate documentation:
- Apache PMC Guide
- Related documentation

Once all this is in place, resources can start to be handed over to the new project.


    
> Tasks to be performed after graduation
> --------------------------------------
>
>                 Key: CLEREZZA-732
>                 URL: https://issues.apache.org/jira/browse/CLEREZZA-732
>             Project: Clerezza
>          Issue Type: Task
>            Reporter: Hasan
>            Assignee: Hasan
>
> Once appointed, the new Chair needs to:
> a. Subscribe to the board mailing list
> DONE
> b. Subscribe to the infrastructure mailing list
> DONE
> c. Ensure that they have been added to the PMC chairs group (pmc-chairs) in LDAP.
> DONE
> d. Check out the foundation/officers folder from the private repository. Users with member
or pmc-chairs karma can do this.
> DONE
> e. Add yourself to the foundation/officers/affiliations.txt and the foundation/officers/irs-disclosures.txt
files with the appropriate information.
> DONE
> f. Review appropriate documentation:
> - PMC Chair Duties
> - PMC documentation
> - Jakarta Chair guide
> - Incubator Chair guide
> - Reporting calendar
> g. Work out a reporting schedule with the Board. For the first three months after graduation
this will be monthly. After that, the project should slot into a quarterly reporting schedule.
Now is a good time to remove the project from the Incubator reporting schedule.
> h. Work with the Apache Infrastructure team to set up the top level project infrastructure.
The various infrastructure tasks that are required (see check list) should be consolidated
into a single issue (see this for example). This should be created in the category TLP Admin.
> i. Add the PMC chair details to the foundation web site Officer list at http://www.apache.org/foundation/index.html
> DONE
> j. Add the new project's PMC chair to the foundation/officers/irs-disclosures.txt file.
You will need a member to help with this task.
> ??? same as e ?
> k. Ensure the PMC is added to the committee-info.txt file at https://svn.apache.org/repos/private/committers/board/committee-info.txt
> There are 3 sections which need to be updated; see instructions in the file. You may
need to get a member to help with this.
> DONE
> l. They should then be able to start assembling the new PMC. The starting membership
is listed in the resolution. However, the Chair of the new project needs to ensure that private
list is created and the membership subscribed.
> Members of the new PMC need to:
> 1. Subscribe to the private mailing list for the project
> 2. Review appropriate documentation:
> - Apache PMC Guide
> - Related documentation
> Once all this is in place, resources can start to be handed over to the new project.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Hasan created CLEREZZA-732:
------------------------------

             Summary: Tasks to be performed after graduation
                 Key: CLEREZZA-732
                 URL: https://issues.apache.org/jira/browse/CLEREZZA-732
             Project: Clerezza
          Issue Type: Task
            Reporter: Hasan
            Assignee: Hasan


Once appointed, the new Chair needs to:

a. Subscribe to the board mailing list
b. Subscribe to the infrastructure mailing list
c. Ensure that they have been added to the PMC chairs group (pmc-chairs) in LDAP.
d. Check out the foundation/officers folder from the private repository. Users with member
or pmc-chairs karma can do this.
e. Add yourself to the foundation/officers/affiliations.txt and the foundation/officers/irs-disclosures.txt
files with the appropriate information.
f. Review appropriate documentation:
- PMC Chair Duties
- PMC documentation
- Jakarta Chair guide
- Incubator Chair guide
- Reporting calendar
g. Work out a reporting schedule with the Board. For the first three months after graduation
this will be monthly. After that, the project should slot into a quarterly reporting schedule.
Now is a good time to remove the project from the Incubator reporting schedule.
h. Work with the Apache Infrastructure team to set up the top level project infrastructure.
The various infrastructure tasks that are required (see check list) should be consolidated
into a single issue (see this for example). This should be created in the category TLP Admin.
i. Add the PMC chair details to the foundation web site Officer list at http://www.apache.org/foundation/index.html
j. Add the new project's PMC chair to the foundation/officers/irs-disclosures.txt file. You
will need a member to help with this task.
k. Ensure the PMC is added to the committee-info.txt file at https://svn.apache.org/repos/private/committers/board/committee-info.txt
There are 3 sections which need to be updated; see instructions in the file. You may need
to get a member to help with this.

They should then be able to start assembling the new PMC. The starting membership is listed
in the resolution. However, the Chair of the new project needs to ensure that private list
is created and the membership subscribed.


Members of the new PMC need to:
1. Subscribe to the private mailing list for the project
2. Review appropriate documentation:
- Apache PMC Guide
- Related documentation

Once all this is in place, resources can start to be handed over to the new project.


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Hi Reto

On Sat, Feb 23, 2013 at 10:04 PM, Reto Bachmann-Gmür <reto@apache.org>wrote:

> Hi Hasan and all,
>
> I propose the following pragmatic approach to support sparql fastlane
> (CLEREZZA-468) and sparql 1.1:
>
> - Drop full query parsing
>

ok.


> - Create subclass of TcProvider that accepts sparql query as string
>

Assumed that this string will be used when invoking the underlying engine


> - Have a minimum parsing of the queries to get the names a query is
> directed against
>

this would be the datasetclause of the "sparql query" and in case of
"sparql update"
it would be the graphref.
So we need a simple parser to extract iri of the affected graphs.
How should the interface definition of the parser look like for sparql
update?



> - In TcManager route the query to the right TcProvider or fall back to
> slow-lane if multiple TcProviders are affected
> - This should be part of rdf.core and replace the existing funcionality
> tehre
>

ok


>
> Question:
> - Did you already model the results of Sparql 1.1? I think there is no big
> difference there to 1.0.
>

afaik it is the same for query, but a sparql update results in success or
failure.

cheers
hasan


>
> Cheers,
> Reto
>

On Tue, Feb 19, 2013 at 8:56 AM, Tommaso Teofili
<tommaso.teofili@gmail.com> wrote:
> ...after the discussion on dev list [1] please vote on the possibility of
> switching Clerezza SCM from SVN to Git....

+0, I'm ok with the move but won't have time to help.
-Bertrand

Hi Hasan and all,

I propose the following pragmatic approach to support sparql fastlane
(CLEREZZA-468) and sparql 1.1:

- Drop full query parsing
- Create subclass of TcProvider that accepts sparql query as string
- Have a minimum parsing of the queries to get the names a query is
directed against
- In TcManager route the query to the right TcProvider or fall back to
slow-lane if multiple TcProviders are affected
- This should be part of rdf.core and replace the existing funcionality
tehre

Question:
- Did you already model the results of Sparql 1.1? I think there is no big
difference there to 1.0.

Cheers,
Reto

Hi Minto,

I think making the support for large number of named graphs more efficient
should be feasible quite easily, so if you want to stick to the current
design let's fix it.

But I'm not really sure why you need one graph per tree, why can't you just
follow the relations to extract a graph from a single graph?

In general I think that its a design smell if multiple graphs are used for
semantic reason. RDF is powerful to describe a universe in one graph. In my
opinion multiple graphs should be used if they either have different
origins (i.e. the represent the universe from different observers) or they
have different access control setting (e.g. public/confidential/private).
As there are many origins of graphs having support for large number of
graphs in clerezza would still be nice.

Cheers,
Reto

On Fri, Feb 22, 2013 at 12:52 PM, Minto van der Sluis <minto@xup.nl> wrote:

> Hi folks,
>
> I am starting to wonder if I use Clerezza and semantic technology in
> general in the wrong way. To make it more clear I will first describe my
> situation and then why I think I might be using it incorrectly.
>
> Context
> =======
> Basically we are gathering and distributing annotations. For this we
> make use of OpenAnnotation (OA, see [1]).  Since OA is based on RDF we
> were looking for products capable of storing this data. We decided to
> use Clerezza as an abstraction for the actual storage layer. Like this
> we are able can switch storage engines quite easily.
>
> Now it turns out that our annotations should support annotations on
> annotations. Amongst others this is to be able to tell if a root
> annotation has been properly processed or rejected (status change). This
> leads us to the notion of annotation trees. Every one of these trees
> starts with a single annotation as the root/trunk.
>
> The system we work on not only stores annotation but also has to return
> complete annotation trees. For this reason we decided to store every
> tree in its own named graphs. Like this we can easily retrieve a full
> tree by returning the complete named graph. The downside of it well be
> that we will end up with a massive number of (small) named graphs.
>
> For the storage we decide (for the time being) to use
> SingleTdbDatasetTcProvider. Here also lies the root cause why I started
> wondering if we are on the right track. Looking at the
> SingleTdbDatasetTcProvider implementation I have the following
> observations:
>
> Observations
> ===========
> 1) SingleTdbDatasetTcProvider keeps names of graphs in 2 separate sets.
> This does not seem to be very efficient for large amounts of graphnames
> (100k+ or possible 1m+).
>
>     private Set<UriRef> graphNames;
>     private Set<UriRef> mGraphNames;
>
>
> 2) All graphnames are logged on startup (activation). This is feasible
> for a small number, but not for a rather large number of named graphs.
>
> 3) FileTcProvider (rdf.file.storage) also keeps names in memory.
>
>     private Map<UriRef, FileMGraph> uriRef2MGraphMap =
>             new HashMap<UriRef, FileMGraph>();
>
> 4) SesameNativeWeightedProvider () keeps not only the names in memory,
> but the graph objects as well.
>
>     private HashMap<UriRef, SesameMGraph> mGraphs;
>     private HashMap<UriRef, SesameGraph> graphs;
>
> Are we approaching this incorrectly or are we running into limitations
> of the current implementation? In other words is a large number of named
> graphs supported or isn't Clerezza and maybe even semantic technology in
> general designed for this?
>
> Any thoughts?
>
> Regards,
>
> Minto
>
> --
> ir. ing. Minto van der Sluis
> Software innovator / renovator
> Xup BV
>
> [1] http://www.openannotation.org/
>
>

On Thu, Feb 21, 2013 at 9:03 PM, Daniel Spicar <daniel.spicar@gmail.com>wrote:

> 2013/2/21 Reto Bachmann-Gmür <reto@apache.org>
>
> > On Thu, Feb 21, 2013 at 7:55 PM, Daniel Spicar <daniel.spicar@gmail.com
> > >wrote:
> >
> > > 2013/2/21 Reto Bachmann-Gmür <reto@apache.org>
> > >
> > > > Hi Daniel
> > > >
> > > > I'm not arguing for a centralized dependency management. so be both
> > agree
> > > > there. My question is how to best move the dependency versions from
> the
> > > > dependency management to the projects.
> > > >
> > > > The mvn versions plugin doesn't seem to support this.
> > > >
> > > > But there is an issue with this approach as well. Often you will want
> > to
> > > > > use the new features of a module A from some other module B. So you
> > > need
> > > > to
> > > > > go to B's pom and adapt the version number of its dependency. Maybe
> > you
> > > > > need to do this with several other modules as well. But you don't
> do
> > > this
> > > > > with all modules (e.g. Stable Module C has no changes and does not
> > > > require
> > > > > any new feature).
> > > >
> > > > No. I suggest you do this for all modules in trunk which is easily
> done
> > > by
> > > > executing the following:
> > > >
> > > > mvn versions:use-latest-versions -Dincludes="org.apache.clerezza"
> > > > -DallowSnapshots=true -DexcludeReactor=false
> > > >
> > > > If C is mantianes it should be adapted to use the new version of A.
> If
> > C
> > > is
> > > > not mantained it should be moved out of trunk.
> > > >
> > >
> > > And this is, what should be avoided in my opinion if possible. What you
> > > describe means a new version of C needs to be released.
> >
> >
> > No,  you only release C if added some new features there otherwise you
> just
> > have C 2-SNAPSHOT version in trunk which keeps being updated to depend on
> > the latest versions of the other modules.
>
>
> > If you have a module D that depends on C and you want to release this the
> > you either have to release C as well or have D depend on the released C 1
> > in the release branch (and for depending on the latest release the
> > versions-plugin has support too)..
> >
> >
> Yes this is the same in practice. Dependencies don't care about branches,
> because they are defined in maven. Maven cares about version numbers.
>
> But what happens with D is not so much the question. It's pretty clear.
> Either D needs new features from C or not. If not it can depend on the old
> version. Otherwise the new version of C is required for the new version of
> D and both need to be released.
>
> The question is what happens to C when it depends on B and B is changed
> (the other direction in the dependency graph). Of course you can update C's
> meta data in a SNAPSHOT version. As long as C not released we don't really
> care about it.
>
> But when you want to release a module A (or launcher) with updated B (maybe
> A needs new features from B or non API changing bugfixes have been
> implemented). What do you do with C?
>
You will use the latest relased version of C. Which means that as C is not
part of the release branch the dependency in the launcher pom will be
switched back to the latest released version.

The alternative is you release C as well because you don't want to mix
> version numbers in dependencies. This as quite awkward effects in my
> opinion. Stable modules will go trough various version changes without ever
> changing code, only because their dependencies change.
>
I fully agree.


>
> The whole scheme I came up with is aimed at preventing these unnecessary
> changes in version number. It's not my idea. I compiled it from other
> Apache projects using maven and OSGi that seem to have the hang of this
> (mainly sling [1,2]).
>



>
>
> >
> > >
> > > But you are right. Back when I investigated this there was no support
> for
> > > this workflow in the mvn release plugin. Nevertheless it strikes me
> wrong
> > > to have to change version numbers of modules that contain no changes.
> > >
> >
> > But that's like that also with normal usage of the relase plugin, After
> the
> > release you have a SNAPSHOT version in trunk which is identical (apart
> from
> > the version number) to the released version.
> >
>
> Well after battling it out with the release plugin many times already I am
> not so convinced it actually does the right thing. It does not seem to work
> well with modular projects in mind. The scheme I suggest will probably not
> work with the plugin but on the other hand there is no need to actually
> snapshotize every single module after release. I imagine many modules will
> remain stable (and untouched) for quite some time. It would shift the focus
> on releasing singular modules and small groups of collaborating modules at
> a time. How much effort this actually creates I can not tell now. It would
> need to be tested.
>
The Stanbol way is to snapshotize the module but still depend on the
released version in the other modules in trunk. In my experience this is
quite a pain developing. You cannot just build stanbol offline after
deleting org/apache/stanbol in your repo. And when you want to see who
depends on a method in eclipse you first have to update all depent modules
to use the snapshot version. So with my suggestion we might slightly
increase the release burden (but I think not too much, as the mvn version
plugin can roll back to the released version) but simplify development. It
doesn't change anything in terms of nut needing to release modules without
actual changes.


>
>
> >
> > But yes, rather than trying to foresee every possible future it would be
> > good to have some indispiputed things done. Do you see any options to
> move
> > our iternal dependencies out the dependency management without doing this
> > by hand?
> >
>
> I have spend a lot of time in 2011, early 2012 with this question.


I think you misunderstood the question. Its just about how to insert the
dependencie versions in the moduke poms after removing clerezza modules
from dependency management.

Cheers,
Reto

Hi Minto

I think checking and ensuring interoperability (in both directions) is a
great sanity check of the architecture. But my concrete motivation was
exploring way to have clerezza more modular, to have easy way to install
optional components (like UIMA or CRIS) and maybe to make the launcher
slimmer.

On the Karaf list I was asked why we don't use a the Karaf framework in
Clerezza. I'm not sure what advatages/disadvantatges this would bring. I
think having an executable jar as launcher is quite important. Also I'm not
sure how well the security stuff would work together.

What are the reasons for you to use Karaf?

Cheers,
Reto

On Mon, Feb 11, 2013 at 11:03 PM, Minto van der Sluis <minto@xup.nl> wrote:

> Hi,
>
> What I have done is the reverse (clerezza in karaf) and might be of
> interest to others:
>
> I have created a custom karaf based distribution containing:
> - clerezza components
> - stanbol rulestore and ontology manager
> - karaf cli commands to manipulate stanbol rulestore
> - custom components of my own
>
> For both clerezza and stanbol I created karaf features to only contain
> components used by me. This however can be easily extended to contain
> all features. It is still up to the distribution to decide which
> features to load on startup.
>
> If there is any interest please let me know. Then I will ask my client
> if I can share details with the community.
>
> Regards,
>
> Minto
>
> Op 11-2-2013 21:56, Reto Bachmann-Gmür schreef:
> > My experiments today.
> >
> > Goal: Be able to install Karaf features within clerezza
> >
> > Approach: use the service org.apache.karaf.features.FeaturesService
> provided by
> > the bundle Apache Karaf :: Features :: Core
> > (org.apache.karaf.features.core) [1].
> >
> > Unfortunately this bundle has quite some dependencies which need to be
> > satisfied. I've chosen a brute force approach and installed the list
> > of bundles of the karaf-framework feature. Because of chicken and egg
> > I can't yet install features. So  I needed the following scala on the
> > command line:
> >
> > import java.net._
> > val url = new
> URL("mvn:org.apache.karaf.assemblies.features/standard/2.3.0/xml/features")
> > val conn = url.openConnection
> > import xml._
> > val doc = XML.load(conn.getInputStream)
> >
> > for (b <- doc\"feature"\"bundle") {
> >  val mvnUri = b.text
> >  try {
> >  val bundle = bundleContext.installBundle(mvnUri)
> >  bundle.start()
> >  } catch {
> >    case ex => out.println("Exception installing bundle", ex)
> >  }
> > }
> >
> > The bundle org.apache.karaf.features.core is now satisfied but not
> > exposing any service. For some reason the blueprint service bundle
> > wasn't activated, activating it over the webconsole made the service
> > available. As new packages aren't avaiable on already open shells I
> > have to reconnect via ssh.
> >
> > Now I can access the service:
> >
> > zz>val fs = $[org.apache.karaf.features.FeaturesService]
> > fs: org.apache.karaf.features.FeaturesService =
> > org.apache.karaf.features.internal.FeaturesServiceImpl@9d8957d
> > zz>fs.[TAB]
> > addRepository           asInstanceOf            getFeature
> >  installFeature          installFeatures         isInstalled
> >   isInstanceOf            listFeatures
> > listInstalledFeatures   listRepositories        removeRepository
> >  restoreRepository       toString                uninstallFeature
> >   validateRepository
> > zz>fs.listFeatures
> > res0: Array[org.apache.karaf.features.Feature] = Array()
> > zz>fs.listRepositories
> > res1: Array[org.apache.karaf.features.Repository] = Array()
> >
> > The next step will be to add a repository.
> >
> > Reto
> >
> > 1. Thanks to Krzysztoffor pointing me to this:
> >
> http://mail-archives.apache.org/mod_mbox/karaf-user/201302.mbox/%3C2960186.kKK1vM5F7L%40dracula%3E
> >
> >
>
>
> --
> ir. ing. Minto van der Sluis
> Software innovator / renovator
> Xup BV
>
> Mobiel: +31 (0) 626 014541
>
>

Hi folks,

I am starting to wonder if I use Clerezza and semantic technology in
general in the wrong way. To make it more clear I will first describe my
situation and then why I think I might be using it incorrectly.

Context
=======
Basically we are gathering and distributing annotations. For this we
make use of OpenAnnotation (OA, see [1]).  Since OA is based on RDF we
were looking for products capable of storing this data. We decided to
use Clerezza as an abstraction for the actual storage layer. Like this
we are able can switch storage engines quite easily.

Now it turns out that our annotations should support annotations on
annotations. Amongst others this is to be able to tell if a root
annotation has been properly processed or rejected (status change). This
leads us to the notion of annotation trees. Every one of these trees
starts with a single annotation as the root/trunk.

The system we work on not only stores annotation but also has to return
complete annotation trees. For this reason we decided to store every
tree in its own named graphs. Like this we can easily retrieve a full
tree by returning the complete named graph. The downside of it well be
that we will end up with a massive number of (small) named graphs.

For the storage we decide (for the time being) to use
SingleTdbDatasetTcProvider. Here also lies the root cause why I started
wondering if we are on the right track. Looking at the
SingleTdbDatasetTcProvider implementation I have the following observations:

Observations
===========
1) SingleTdbDatasetTcProvider keeps names of graphs in 2 separate sets.
This does not seem to be very efficient for large amounts of graphnames
(100k+ or possible 1m+).

    private Set<UriRef> graphNames;
    private Set<UriRef> mGraphNames;


2) All graphnames are logged on startup (activation). This is feasible
for a small number, but not for a rather large number of named graphs.

3) FileTcProvider (rdf.file.storage) also keeps names in memory.

    private Map<UriRef, FileMGraph> uriRef2MGraphMap =
            new HashMap<UriRef, FileMGraph>();

4) SesameNativeWeightedProvider () keeps not only the names in memory,
but the graph objects as well.

    private HashMap<UriRef, SesameMGraph> mGraphs;
    private HashMap<UriRef, SesameGraph> graphs;

Are we approaching this incorrectly or are we running into limitations
of the current implementation? In other words is a large number of named
graphs supported or isn't Clerezza and maybe even semantic technology in
general designed for this?

Any thoughts?

Regards,

Minto

-- 
ir. ing. Minto van der Sluis
Software innovator / renovator
Xup BV

[1] http://www.openannotation.org/

Hi all,

just to make sure everyone on the list is aware: as of yesterday Apache
Clerezza has finally made it to be come a Top Level Project!

Thanks all for the nice trip so far, hopefully it'll be even nicer in the
future.
Cheers,
Tommaso

Hi,

2013/2/21 Daniel Spicar <daniel.spicar@gmail.com>:
> I believe
> Stanbol wanted to move to a similar versioning policy back then as well. I
> did not follow up on how they implemented it. Maybe we can get some
> inspiration there though.

yes in Stanbol we are trying to follow the approach that we release
independent components. It is basically the approach described by
Daniel and was also influenced by Sling. I have myself spent a lot of
time figuring out what the best process could be.

I can confirm that the release plugin sounds like a great tool but it
is based on a different release process in mind. Also my feeling is
that it has its problems with complex multi module structures.

For example, the release plugin has this process:
- Update everything to release versions
- Tag
- Update everything to dev versions

But the Apache release process is different
- Update everything to release versions
- Tag
- Stage the release
- Vote
- Only on success publish the release and then update dev versions or
use the released stable versions

The problem is that all the tools to update and manage dependency
versions have their problems. I am really missing tool support here.
There is the versions plugin but after many experiments it also has
problems with multi module project and parent POMs at different
hierarchy levels.

And this is only the Maven side. With OSGi we have a second layer of
dependency management which controls the runtime deps. For this layer,
there is absolutely no helping tool support.

So, practically cutting a release is not that easy and somewhere in
the process it is often inevitable to forget to update some dep on
Maven and/or OSGi level.

I am really interested in a working solution but I can not offer one
at the moment. Currently, I am also investigating the technique of
using release branches. This gives a little more freedom during the
process and people can work on the trunk without interfering with the
release in progress.

Best,
 - Fabian

-- 
Fabian
http://twitter.com/fctwitt

2013/2/21 Reto Bachmann-Gmür <reto@apache.org>

> On Thu, Feb 21, 2013 at 7:55 PM, Daniel Spicar <daniel.spicar@gmail.com
> >wrote:
>
> > 2013/2/21 Reto Bachmann-Gmür <reto@apache.org>
> >
> > > Hi Daniel
> > >
> > > I'm not arguing for a centralized dependency management. so be both
> agree
> > > there. My question is how to best move the dependency versions from the
> > > dependency management to the projects.
> > >
> > > The mvn versions plugin doesn't seem to support this.
> > >
> > > But there is an issue with this approach as well. Often you will want
> to
> > > > use the new features of a module A from some other module B. So you
> > need
> > > to
> > > > go to B's pom and adapt the version number of its dependency. Maybe
> you
> > > > need to do this with several other modules as well. But you don't do
> > this
> > > > with all modules (e.g. Stable Module C has no changes and does not
> > > require
> > > > any new feature).
> > >
> > > No. I suggest you do this for all modules in trunk which is easily done
> > by
> > > executing the following:
> > >
> > > mvn versions:use-latest-versions -Dincludes="org.apache.clerezza"
> > > -DallowSnapshots=true -DexcludeReactor=false
> > >
> > > If C is mantianes it should be adapted to use the new version of A. If
> C
> > is
> > > not mantained it should be moved out of trunk.
> > >
> >
> > And this is, what should be avoided in my opinion if possible. What you
> > describe means a new version of C needs to be released.
>
>
> No,  you only release C if added some new features there otherwise you just
> have C 2-SNAPSHOT version in trunk which keeps being updated to depend on
> the latest versions of the other modules.


> If you have a module D that depends on C and you want to release this the
> you either have to release C as well or have D depend on the released C 1
> in the release branch (and for depending on the latest release the
> versions-plugin has support too)..
>
>
Yes this is the same in practice. Dependencies don't care about branches,
because they are defined in maven. Maven cares about version numbers.

But what happens with D is not so much the question. It's pretty clear.
Either D needs new features from C or not. If not it can depend on the old
version. Otherwise the new version of C is required for the new version of
D and both need to be released.

The question is what happens to C when it depends on B and B is changed
(the other direction in the dependency graph). Of course you can update C's
meta data in a SNAPSHOT version. As long as C not released we don't really
care about it.

But when you want to release a module A (or launcher) with updated B (maybe
A needs new features from B or non API changing bugfixes have been
implemented). What do you do with C?

I say nothing. OSGi will happily satisfy C's dependency on B if version
numbers or dependency declarations are semantically correct. Semantically
speaking, if B evolves from 1.0 to 1.5, B needs to satisfy at least
dependencies for [1.0, 1.5] or OSGi will throw exceptions at you because C
can not satisfy its dependency for B. Note: this example ignores OSGi
semantic versioning, just speaking conceptually. Practically we can just
declare OSGi version 0.0.0 for all bundles and it will work (until someone
makes API breaking changes and forgets to update all modules that depend on
the changed module).

The alternative is you release C as well because you don't want to mix
version numbers in dependencies. This as quite awkward effects in my
opinion. Stable modules will go trough various version changes without ever
changing code, only because their dependencies change.

The whole scheme I came up with is aimed at preventing these unnecessary
changes in version number. It's not my idea. I compiled it from other
Apache projects using maven and OSGi that seem to have the hang of this
(mainly sling [1,2]).


>
> >
> > But you are right. Back when I investigated this there was no support for
> > this workflow in the mvn release plugin. Nevertheless it strikes me wrong
> > to have to change version numbers of modules that contain no changes.
> >
>
> But that's like that also with normal usage of the relase plugin, After the
> release you have a SNAPSHOT version in trunk which is identical (apart from
> the version number) to the released version.
>

Well after battling it out with the release plugin many times already I am
not so convinced it actually does the right thing. It does not seem to work
well with modular projects in mind. The scheme I suggest will probably not
work with the plugin but on the other hand there is no need to actually
snapshotize every single module after release. I imagine many modules will
remain stable (and untouched) for quite some time. It would shift the focus
on releasing singular modules and small groups of collaborating modules at
a time. How much effort this actually creates I can not tell now. It would
need to be tested.


>
> But yes, rather than trying to foresee every possible future it would be
> good to have some indispiputed things done. Do you see any options to move
> our iternal dependencies out the dependency management without doing this
> by hand?
>

I have spend a lot of time in 2011, early 2012 with this question. I don't
see an option to get a satisfactory workflow only with small changes. All
the elements I talked about are interdependent. Currently - from a
dependency management view - we treat Clerezza as one big software project.
If you change something in it - clerezza changes. So there's no clear way
how to only change small parts without affecting all of them.
The other approach means to shift to a module centric setup. Basically each
module is a software project that can evolve independently. Relations
between modules should be very similar to relations to external
dependencies. This means sacrificing central management.

If you know how to make small changes to improve the situation, I am all
for it. But I don't see such a solution. I have to admit that I also don't
have too much time currently to try things out. I just wanted to comment on
the things I noticed when I checked the situation last time. I believe
Stanbol wanted to move to a similar versioning policy back then as well. I
did not follow up on how they implemented it. Maybe we can get some
inspiration there though.


>
> Cheers,
> Reto
>

Daniel

[1]
https://cwiki.apache.org/confluence/display/SLING/Thoughts+on+Release+Management
[2] http://sling.apache.org/site/version-policy.html

On Thu, Feb 21, 2013 at 7:55 PM, Daniel Spicar <daniel.spicar@gmail.com>wrote:

> 2013/2/21 Reto Bachmann-Gmür <reto@apache.org>
>
> > Hi Daniel
> >
> > I'm not arguing for a centralized dependency management. so be both agree
> > there. My question is how to best move the dependency versions from the
> > dependency management to the projects.
> >
> > The mvn versions plugin doesn't seem to support this.
> >
> > But there is an issue with this approach as well. Often you will want to
> > > use the new features of a module A from some other module B. So you
> need
> > to
> > > go to B's pom and adapt the version number of its dependency. Maybe you
> > > need to do this with several other modules as well. But you don't do
> this
> > > with all modules (e.g. Stable Module C has no changes and does not
> > require
> > > any new feature).
> >
> > No. I suggest you do this for all modules in trunk which is easily done
> by
> > executing the following:
> >
> > mvn versions:use-latest-versions -Dincludes="org.apache.clerezza"
> > -DallowSnapshots=true -DexcludeReactor=false
> >
> > If C is mantianes it should be adapted to use the new version of A. If C
> is
> > not mantained it should be moved out of trunk.
> >
>
> And this is, what should be avoided in my opinion if possible. What you
> describe means a new version of C needs to be released.


No,  you only release C if added some new features there otherwise you just
have C 2-SNAPSHOT version in trunk which keeps being updated to depend on
the latest versions of the other modules.

If you have a module D that depends on C and you want to release this the
you either have to release C as well or have D depend on the released C 1
in the release branch (and for depending on the latest release the
versions-plugin has support too)..


>
> But you are right. Back when I investigated this there was no support for
> this workflow in the mvn release plugin. Nevertheless it strikes me wrong
> to have to change version numbers of modules that contain no changes.
>

But that's like that also with normal usage of the relase plugin, After the
release you have a SNAPSHOT version in trunk which is identical (apart from
the version number) to the released version.

But yes, rather than trying to foresee every possible future it would be
good to have some indispiputed things done. Do you see any options to move
our iternal dependencies out the dependency management without doing this
by hand?

Cheers,
Reto

2013/2/21 Reto Bachmann-Gmür <reto@apache.org>

> Hi Daniel
>
> I'm not arguing for a centralized dependency management. so be both agree
> there. My question is how to best move the dependency versions from the
> dependency management to the projects.
>
> The mvn versions plugin doesn't seem to support this.
>
> But there is an issue with this approach as well. Often you will want to
> > use the new features of a module A from some other module B. So you need
> to
> > go to B's pom and adapt the version number of its dependency. Maybe you
> > need to do this with several other modules as well. But you don't do this
> > with all modules (e.g. Stable Module C has no changes and does not
> require
> > any new feature).
>
> No. I suggest you do this for all modules in trunk which is easily done by
> executing the following:
>
> mvn versions:use-latest-versions -Dincludes="org.apache.clerezza"
> -DallowSnapshots=true -DexcludeReactor=false
>
> If C is mantianes it should be adapted to use the new version of A. If C is
> not mantained it should be moved out of trunk.
>

And this is, what should be avoided in my opinion if possible. What you
describe means a new version of C needs to be released. This is an
unnecessary release of C. C contains no changes. Only it's metadata is
changed and in this case not even that is necessary because (given that the
change in A does not break the old API), the new version of A satisfies C's
requirements at runtime. You only need to make sure OSGi is able to resolve
it correctly.

But you are right. Back when I investigated this there was no support for
this workflow in the mvn release plugin. Nevertheless it strikes me wrong
to have to change version numbers of modules that contain no changes.


>
> Cheers,
> Reto
>


Daniel

Hi Daniel

I'm not arguing for a centralized dependency management. so be both agree
there. My question is how to best move the dependency versions from the
dependency management to the projects.

The mvn versions plugin doesn't seem to support this.

But there is an issue with this approach as well. Often you will want to
> use the new features of a module A from some other module B. So you need to
> go to B's pom and adapt the version number of its dependency. Maybe you
> need to do this with several other modules as well. But you don't do this
> with all modules (e.g. Stable Module C has no changes and does not require
> any new feature).

No. I suggest you do this for all modules in trunk which is easily done by
executing the following:

mvn versions:use-latest-versions -Dincludes="org.apache.clerezza"
-DallowSnapshots=true -DexcludeReactor=false

If C is mantianes it should be adapted to use the new version of A. If C is
not mantained it should be moved out of trunk.

Cheers,
Reto

+1

On 02/20/2013 09:52 AM, Rupert Westenthaler wrote:
> ±0 as I do not have a personal preference and [1] does not provide any
> clues about specifics such as information about the planed workflow
>
> On Wed, Feb 20, 2013 at 6:53 AM, Hasan Hasan <hasan@trialox.org> wrote:
>> +1
>>
>> On Tue, Feb 19, 2013 at 4:30 PM, Enrico Daga <enricodaga@gmail.com> wrote:
>>
>>> +1
>>>
>>> On 19 February 2013 10:15, Daniel Spicar <daniel.spicar@gmail.com> wrote:
>>>> +1
>>>>
>>>> 2013/2/19 Tommaso Teofili <tommaso.teofili@gmail.com>
>>>>
>>>>> +1
>>>>>
>>>>> Tommaso
>>>>>
>>>>>
>>>>> 2013/2/19 Tommaso Teofili <tommaso.teofili@gmail.com>
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> after the discussion on dev list [1] please vote on the possibility
of
>>>>>> switching Clerezza SCM from SVN to Git.
>>>>>>
>>>>>> +1 yes, lets' move to Git.
>>>>>> +0 not sure
>>>>>> -1 no, because ...
>>>>>>
>>>>>> Vote is open for next 72 hours.
>>>>>>
>>>>>> Regards,
>>>>>> Tommaso
>>>>>>
>>>>>> [1] :
>>>>>>
>>>>>
>>> http://mail-archives.apache.org/mod_mbox/incubator-clerezza-dev/201302.mbox/%3CCALvhUEVHkRUS3iS244Swcnk_hSbXQkUspG1agv0g4LuRGn9BOA%40mail.gmail.com%3E
>>>>>>
>>>>>
>>>
>>>
>>>
>>> --
>>> Enrico Daga
>>>
>>> --
>>> http://www.enridaga.net
>>> skype: enri-pan
>>>
>
>
>

Hi Reto,

Well as I elaborated earlier, one of the problems is the dependency
management for our modules. As long as we manage dependency versions
centrally in a parent POM or reactor that is 'higher up the hierarchy',
each time you release a module, you want to update the parent or reactor
POM as well. And therefore you need to release the parent or reactor POM as
well. Now you will always need to do this in some form if you want to offer
a launcher with the latest modules. But this is not strictly necessary for
each module release. Not all modules are part of a launcher to start with
and it is possible to establish different release cycles for
launchers/reactors than that of single modules.

This is not so much a technical requirement but a change of thinking. You
can always achieve the same by having a mixture of central and module-level
dependency management but when you think of it. If modules should be able
to evolve over time independently of other modules you should let them
manage their dependencies (and dependency versions!) by themselves. This
makes them almost stand alone projects and in some cases you can change
things in them and release them without having to touch any other module
(provided of course your changes do not break the old interface and the
changes are self contained in the module).

But there is an issue with this approach as well. Often you will want to
use the new features of a module A from some other module B. So you need to
go to B's pom and adapt the version number of its dependency. Maybe you
need to do this with several other modules as well. But you don't do this
with all modules (e.g. Stable Module C has no changes and does not require
any new feature). The result is that now you have modules that require
different versions of the same module at runtime. In OSGi this can be done
and that is what I suggest to use in point 3. But it places more
responsibility on the developer. Not all changes are "backwards-compatible"
and the developer needs to be be aware that he makes such changes and has
to make sure to update the dependencies in all modules when he does such
changes. OSGi proposes its semantic versioning to help manage that [1].

Note most of the additional effort from non-backwards compatible changes
would happen as well with centralized dependency management because in both
cases you will actually need to touch the code of other modules and adapt
them to use the new API of the module in question.

Daniel

[1] http://www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf

2013/2/20 Reto Bachmann-Gmür <reto@apache.org>

> Hi Daniel
>
> I do not really understand your point 3. Why should a module not depend on
> the latest released version of the modules it depends on? I would say go
> for the newset version in maven and if there is a need for it configure the
> bundle plugin to make sure the older version are accepted. But the latter I
> would only do if people shout for it. OSGi is considered complex by many
> developers so I think we should keep it as easy as possible.
>
> Another thing: Do you know of any easy way to add the version numbers to
> the individul poms?
>
> Cheers,
> Reto
>
>
> On Wed, Feb 13, 2013 at 10:53 AM, Daniel Spicar <dspicar@apache.org>
> wrote:
>
> > Hi Reto,
> >
> > In general I agree with the approach.
> > I have been investigating this issue earlier too. I don't really have
> time
> > to get familiar with the details of this problem again but I remember,
> that
> > the method I suggested pretty much had the following features:
> >
> > 1. No Centralized Dependency Management in higher level POMs (except for
> > general utilities that we *want* all modules to use, e.g. slf4j).
> > 2. Modules have to be developed as if they are self-contained (so they
> > manage their own dependencies to other modules).
> > 3. (Released) modules can only depend on released versions but it is not
> > necessary to depend on the latest released version. This point is
> important
> > for not having to touch other modules that have no code changes when
> > releasing your module.
> >
> > More info for point 3: Modules depend on the oldest/lowest version they
> > *need*. There is not problem for a module to depend on version 1.0 when
> we
> > are at 1.8 - given the module does not need any of the new features.
> > However there should be a minimal version number policy that makes sure
> we
> > handle non-backwards compatible changes correctly because the OSGi
> > container will only have the latest version of the module running but it
> > needs to satisfy dependencies for older versions as well. When there a re
> > non-backwards compatible changes in the new version, this needs to be
> > addressed in some manner. There is a whole lot coming into this point if
> > you want to use OSGi semantic versioning though. Maybe we can just skip
> > that for now. But we need to make sure that the OSGi runtime will run
> with
> > the latest modules (e.g. Version 1.8) but dependencies on older Versions
> > (e.g. 1.0) will be satisfied by the 1.8 bundle (this is actually what the
> > OSGi semantic versioning is meant for - but it's quite complex because it
> > forces the devs to understand the version policy when making changes).
> >
> > Is that more or less what you meant?
> >
> > Regards,
> > Daniel
> >
> > 2013/2/12 Tommaso Teofili <tommaso.teofili@gmail.com>
> >
> > > I see your point, let's go with this approach and if we find anything
> > > better in the meantime then we'll switch to that ;)
> > >
> > > Tommaso
> > >
> > >
> > > 2013/2/12 Reto Bachmann-Gmür <reto@apache.org>
> > >
> > > > Hi Tommaso
> > > >
> > > > I know. But the alternative of updating internal dependencies only
> > > > when needed is quite tedious too. Also this way one can compile the
> > > > clerezza trunk without downloading any clerezza dependency (i.e.
> > > > offline after deleting org/apache/clerezza from the maven repository)
> > > > I thing its good to have such a self-contained set of sources.
> > > >
> > > > Cheers,
> > > > Reto
> > > >
> > > > On Tue, Feb 12, 2013 at 6:28 PM, Tommaso Teofili
> > > > <tommaso.teofili@gmail.com> wrote:
> > > > > Hi Reto,
> > > > > I generally agree but I've to say it doesn't sound really smart to
> > have
> > > > > this back and forth version work on the branch, or at least a
> little
> > > > > annoying for the release manager.
> > > > > Apart from that +1,
> > > > > Tommaso
> > > > >
> > > > >
> > > > > 2013/2/12 Reto Bachmann-Gmür <reto@apache.org>
> > > > >
> > > > >> Hallo
> > > > >>
> > > > >> We have already been discussing this once:
> > > > >>
> > > > >>
> > > >
> > >
> >
> http://mail-archives.apache.org/mod_mbox/incubator-clerezza-dev/201203.mbox/%3CCAEWfVJkK4Czkwy+w3afUoKOB8i+00e4_dyQ_-2WsT1eeqZDxKQ@mail.gmail.com%3E
> > > > >>
> > > > >> Now also after having more experience with the stanbol approach
I
> > > > >> would like to suggest the following:
> > > > >>
> > > > >> 1) The dependency management does not contain internal
> dependencies
> > > > >> 2) All modules in trunk depend on the latest versions of the
> modules
> > > > >> in trunk, this is achieved by regularly running the mvn dependency
> > > > >> plugin
> > > > >> 3) before modules are relased they are copied to a branch and
the
> > > > >> trunk snapshot-version is increased
> > > > >> 4) In the branch the module the dependencies to modules that
are
> not
> > > > >> part of the released are switched back to the latest released
> > version
> > > > >> (if incompatibilities become manifest the other modules are added
> to
> > > > >> the release branch)
> > > > >> 5) a release is prepared on the release branch
> > > > >> 6) vote
> > > > >>
> > > > >> The idea is to reduce to effort of developing in trunk whithout
> > having
> > > > >> to worry about dependencies while making it straight forward
to
> > > > >> release only a part of the modules.
> > > > >>
> > > > >>
> > > > >> WDYT?
> > > > >>
> > > > >> Cheers,
> > > > >> Reto
> > > > >>
> > > >
> > >
> >
>

+1
On Feb 19, 2013, at 9:00 AM, Reto Bachmann-Gmür <reto@apache.org> wrote:

> +1
> 
> On Tue, Feb 19, 2013 at 8:56 AM, Tommaso Teofili
> <tommaso.teofili@gmail.com>wrote:
> 
>> Hi all,
>> 
>> after the discussion on dev list [1] please vote on the possibility of
>> switching Clerezza SCM from SVN to Git.
>> 
>> +1 yes, lets' move to Git.
>> +0 not sure
>> -1 no, because ...
>> 
>> Vote is open for next 72 hours.
>> 
>> Regards,
>> Tommaso
>> 
>> [1] :
>> 
>> http://mail-archives.apache.org/mod_mbox/incubator-clerezza-dev/201302.mbox/%3CCALvhUEVHkRUS3iS244Swcnk_hSbXQkUspG1agv0g4LuRGn9BOA%40mail.gmail.com%3E
>> 

Hi Daniel

I do not really understand your point 3. Why should a module not depend on
the latest released version of the modules it depends on? I would say go
for the newset version in maven and if there is a need for it configure the
bundle plugin to make sure the older version are accepted. But the latter I
would only do if people shout for it. OSGi is considered complex by many
developers so I think we should keep it as easy as possible.

Another thing: Do you know of any easy way to add the version numbers to
the individul poms?

Cheers,
Reto


On Wed, Feb 13, 2013 at 10:53 AM, Daniel Spicar <dspicar@apache.org> wrote:

> Hi Reto,
>
> In general I agree with the approach.
> I have been investigating this issue earlier too. I don't really have time
> to get familiar with the details of this problem again but I remember, that
> the method I suggested pretty much had the following features:
>
> 1. No Centralized Dependency Management in higher level POMs (except for
> general utilities that we *want* all modules to use, e.g. slf4j).
> 2. Modules have to be developed as if they are self-contained (so they
> manage their own dependencies to other modules).
> 3. (Released) modules can only depend on released versions but it is not
> necessary to depend on the latest released version. This point is important
> for not having to touch other modules that have no code changes when
> releasing your module.
>
> More info for point 3: Modules depend on the oldest/lowest version they
> *need*. There is not problem for a module to depend on version 1.0 when we
> are at 1.8 - given the module does not need any of the new features.
> However there should be a minimal version number policy that makes sure we
> handle non-backwards compatible changes correctly because the OSGi
> container will only have the latest version of the module running but it
> needs to satisfy dependencies for older versions as well. When there a re
> non-backwards compatible changes in the new version, this needs to be
> addressed in some manner. There is a whole lot coming into this point if
> you want to use OSGi semantic versioning though. Maybe we can just skip
> that for now. But we need to make sure that the OSGi runtime will run with
> the latest modules (e.g. Version 1.8) but dependencies on older Versions
> (e.g. 1.0) will be satisfied by the 1.8 bundle (this is actually what the
> OSGi semantic versioning is meant for - but it's quite complex because it
> forces the devs to understand the version policy when making changes).
>
> Is that more or less what you meant?
>
> Regards,
> Daniel
>
> 2013/2/12 Tommaso Teofili <tommaso.teofili@gmail.com>
>
> > I see your point, let's go with this approach and if we find anything
> > better in the meantime then we'll switch to that ;)
> >
> > Tommaso
> >
> >
> > 2013/2/12 Reto Bachmann-Gmür <reto@apache.org>
> >
> > > Hi Tommaso
> > >
> > > I know. But the alternative of updating internal dependencies only
> > > when needed is quite tedious too. Also this way one can compile the
> > > clerezza trunk without downloading any clerezza dependency (i.e.
> > > offline after deleting org/apache/clerezza from the maven repository)
> > > I thing its good to have such a self-contained set of sources.
> > >
> > > Cheers,
> > > Reto
> > >
> > > On Tue, Feb 12, 2013 at 6:28 PM, Tommaso Teofili
> > > <tommaso.teofili@gmail.com> wrote:
> > > > Hi Reto,
> > > > I generally agree but I've to say it doesn't sound really smart to
> have
> > > > this back and forth version work on the branch, or at least a little
> > > > annoying for the release manager.
> > > > Apart from that +1,
> > > > Tommaso
> > > >
> > > >
> > > > 2013/2/12 Reto Bachmann-Gmür <reto@apache.org>
> > > >
> > > >> Hallo
> > > >>
> > > >> We have already been discussing this once:
> > > >>
> > > >>
> > >
> >
> http://mail-archives.apache.org/mod_mbox/incubator-clerezza-dev/201203.mbox/%3CCAEWfVJkK4Czkwy+w3afUoKOB8i+00e4_dyQ_-2WsT1eeqZDxKQ@mail.gmail.com%3E
> > > >>
> > > >> Now also after having more experience with the stanbol approach I
> > > >> would like to suggest the following:
> > > >>
> > > >> 1) The dependency management does not contain internal dependencies
> > > >> 2) All modules in trunk depend on the latest versions of the modules
> > > >> in trunk, this is achieved by regularly running the mvn dependency
> > > >> plugin
> > > >> 3) before modules are relased they are copied to a branch and the
> > > >> trunk snapshot-version is increased
> > > >> 4) In the branch the module the dependencies to modules that are not
> > > >> part of the released are switched back to the latest released
> version
> > > >> (if incompatibilities become manifest the other modules are added
to
> > > >> the release branch)
> > > >> 5) a release is prepared on the release branch
> > > >> 6) vote
> > > >>
> > > >> The idea is to reduce to effort of developing in trunk whithout
> having
> > > >> to worry about dependencies while making it straight forward to
> > > >> release only a part of the modules.
> > > >>
> > > >>
> > > >> WDYT?
> > > >>
> > > >> Cheers,
> > > >> Reto
> > > >>
> > >
> >
>

±0 as I do not have a personal preference and [1] does not provide any
clues about specifics such as information about the planed workflow

On Wed, Feb 20, 2013 at 6:53 AM, Hasan Hasan <hasan@trialox.org> wrote:
> +1
>
> On Tue, Feb 19, 2013 at 4:30 PM, Enrico Daga <enricodaga@gmail.com> wrote:
>
>> +1
>>
>> On 19 February 2013 10:15, Daniel Spicar <daniel.spicar@gmail.com> wrote:
>> > +1
>> >
>> > 2013/2/19 Tommaso Teofili <tommaso.teofili@gmail.com>
>> >
>> >> +1
>> >>
>> >> Tommaso
>> >>
>> >>
>> >> 2013/2/19 Tommaso Teofili <tommaso.teofili@gmail.com>
>> >>
>> >> > Hi all,
>> >> >
>> >> > after the discussion on dev list [1] please vote on the possibility
of
>> >> > switching Clerezza SCM from SVN to Git.
>> >> >
>> >> > +1 yes, lets' move to Git.
>> >> > +0 not sure
>> >> > -1 no, because ...
>> >> >
>> >> > Vote is open for next 72 hours.
>> >> >
>> >> > Regards,
>> >> > Tommaso
>> >> >
>> >> > [1] :
>> >> >
>> >>
>> http://mail-archives.apache.org/mod_mbox/incubator-clerezza-dev/201302.mbox/%3CCALvhUEVHkRUS3iS244Swcnk_hSbXQkUspG1agv0g4LuRGn9BOA%40mail.gmail.com%3E
>> >> >
>> >>
>>
>>
>>
>> --
>> Enrico Daga
>>
>> --
>> http://www.enridaga.net
>> skype: enri-pan
>>



-- 
| Rupert Westenthaler             rupert.westenthaler@gmail.com
| Bodenlehenstraße 11                             ++43-699-11108907
| A-5500 Bischofshofen

On Wed, Feb 20, 2013 at 6:53 AM, Hasan Hasan <hasan@trialox.org> wrote:
> +1
>
> On Tue, Feb 19, 2013 at 4:30 PM, Enrico Daga <enricodaga@gmail.com> wrote:
>
>> +1
>>
>> On 19 February 2013 10:15, Daniel Spicar <daniel.spicar@gmail.com> wrote:
>> > +1
>> >
>> > 2013/2/19 Tommaso Teofili <tommaso.teofili@gmail.com>
>> >
>> >> +1
>> >>
>> >> Tommaso
>> >>
>> >>
>> >> 2013/2/19 Tommaso Teofili <tommaso.teofili@gmail.com>
>> >>
>> >> > Hi all,
>> >> >
>> >> > after the discussion on dev list [1] please vote on the possibility
of
>> >> > switching Clerezza SCM from SVN to Git.
>> >> >
>> >> > +1 yes, lets' move to Git.
>> >> > +0 not sure
>> >> > -1 no, because ...
>> >> >
>> >> > Vote is open for next 72 hours.
>> >> >
>> >> > Regards,
>> >> > Tommaso
>> >> >
>> >> > [1] :
>> >> >
>> >>
>> http://mail-archives.apache.org/mod_mbox/incubator-clerezza-dev/201302.mbox/%3CCALvhUEVHkRUS3iS244Swcnk_hSbXQkUspG1agv0g4LuRGn9BOA%40mail.gmail.com%3E
>> >> >
>> >>
>>
>>
>>
>> --
>> Enrico Daga
>>
>> --
>> http://www.enridaga.net
>> skype: enri-pan
>>



--
| Rupert Westenthaler             rupert.westenthaler@gmail.com
| Bodenlehenstraße 11                             ++43-699-11108907
| A-5500 Bischofshofen

+1

On Tue, Feb 19, 2013 at 4:30 PM, Enrico Daga <enricodaga@gmail.com> wrote:

> +1
>
> On 19 February 2013 10:15, Daniel Spicar <daniel.spicar@gmail.com> wrote:
> > +1
> >
> > 2013/2/19 Tommaso Teofili <tommaso.teofili@gmail.com>
> >
> >> +1
> >>
> >> Tommaso
> >>
> >>
> >> 2013/2/19 Tommaso Teofili <tommaso.teofili@gmail.com>
> >>
> >> > Hi all,
> >> >
> >> > after the discussion on dev list [1] please vote on the possibility of
> >> > switching Clerezza SCM from SVN to Git.
> >> >
> >> > +1 yes, lets' move to Git.
> >> > +0 not sure
> >> > -1 no, because ...
> >> >
> >> > Vote is open for next 72 hours.
> >> >
> >> > Regards,
> >> > Tommaso
> >> >
> >> > [1] :
> >> >
> >>
> http://mail-archives.apache.org/mod_mbox/incubator-clerezza-dev/201302.mbox/%3CCALvhUEVHkRUS3iS244Swcnk_hSbXQkUspG1agv0g4LuRGn9BOA%40mail.gmail.com%3E
> >> >
> >>
>
>
>
> --
> Enrico Daga
>
> --
> http://www.enridaga.net
> skype: enri-pan
>

+1

On 19 February 2013 10:15, Daniel Spicar <daniel.spicar@gmail.com> wrote:
> +1
>
> 2013/2/19 Tommaso Teofili <tommaso.teofili@gmail.com>
>
>> +1
>>
>> Tommaso
>>
>>
>> 2013/2/19 Tommaso Teofili <tommaso.teofili@gmail.com>
>>
>> > Hi all,
>> >
>> > after the discussion on dev list [1] please vote on the possibility of
>> > switching Clerezza SCM from SVN to Git.
>> >
>> > +1 yes, lets' move to Git.
>> > +0 not sure
>> > -1 no, because ...
>> >
>> > Vote is open for next 72 hours.
>> >
>> > Regards,
>> > Tommaso
>> >
>> > [1] :
>> >
>> http://mail-archives.apache.org/mod_mbox/incubator-clerezza-dev/201302.mbox/%3CCALvhUEVHkRUS3iS244Swcnk_hSbXQkUspG1agv0g4LuRGn9BOA%40mail.gmail.com%3E
>> >
>>



-- 
Enrico Daga

--
http://www.enridaga.net
skype: enri-pan

+1

2013/2/19 Tommaso Teofili <tommaso.teofili@gmail.com>

> +1
>
> Tommaso
>
>
> 2013/2/19 Tommaso Teofili <tommaso.teofili@gmail.com>
>
> > Hi all,
> >
> > after the discussion on dev list [1] please vote on the possibility of
> > switching Clerezza SCM from SVN to Git.
> >
> > +1 yes, lets' move to Git.
> > +0 not sure
> > -1 no, because ...
> >
> > Vote is open for next 72 hours.
> >
> > Regards,
> > Tommaso
> >
> > [1] :
> >
> http://mail-archives.apache.org/mod_mbox/incubator-clerezza-dev/201302.mbox/%3CCALvhUEVHkRUS3iS244Swcnk_hSbXQkUspG1agv0g4LuRGn9BOA%40mail.gmail.com%3E
> >
>

+1

Tommaso


2013/2/19 Tommaso Teofili <tommaso.teofili@gmail.com>

> Hi all,
>
> after the discussion on dev list [1] please vote on the possibility of
> switching Clerezza SCM from SVN to Git.
>
> +1 yes, lets' move to Git.
> +0 not sure
> -1 no, because ...
>
> Vote is open for next 72 hours.
>
> Regards,
> Tommaso
>
> [1] :
> http://mail-archives.apache.org/mod_mbox/incubator-clerezza-dev/201302.mbox/%3CCALvhUEVHkRUS3iS244Swcnk_hSbXQkUspG1agv0g4LuRGn9BOA%40mail.gmail.com%3E
>

+1

On Tue, Feb 19, 2013 at 8:56 AM, Tommaso Teofili
<tommaso.teofili@gmail.com>wrote:

> Hi all,
>
> after the discussion on dev list [1] please vote on the possibility of
> switching Clerezza SCM from SVN to Git.
>
> +1 yes, lets' move to Git.
> +0 not sure
> -1 no, because ...
>
> Vote is open for next 72 hours.
>
> Regards,
> Tommaso
>
> [1] :
>
> http://mail-archives.apache.org/mod_mbox/incubator-clerezza-dev/201302.mbox/%3CCALvhUEVHkRUS3iS244Swcnk_hSbXQkUspG1agv0g4LuRGn9BOA%40mail.gmail.com%3E
>

Hi all,

after the discussion on dev list [1] please vote on the possibility of
switching Clerezza SCM from SVN to Git.

+1 yes, lets' move to Git.
+0 not sure
-1 no, because ...

Vote is open for next 72 hours.

Regards,
Tommaso

[1] :
http://mail-archives.apache.org/mod_mbox/incubator-clerezza-dev/201302.mbox/%3CCALvhUEVHkRUS3iS244Swcnk_hSbXQkUspG1agv0g4LuRGn9BOA%40mail.gmail.com%3E

ok so maybe the best idea is to open an official vote thread for this.
Tommaso


2013/2/18 Enrico Daga <enricodaga@gmail.com>

> +1
>
> Enrico
>
> On 18 February 2013 08:15, Tsuy Ito <tsuy.ito@trialox.org> wrote:
> > +1
> >
> > cheers
> > tsuy
> >
> > On Feb 17, 2013, at 7:29 PM, Tommaso Teofili <tommaso.teofili@gmail.com>
> wrote:
> >
> >> I'd be +1 for that.
> >> Tommaso
> >>
> >>
> >> 2013/2/17 Reto Bachmann-Gmür <reto@wymiwyg.com>
> >>
> >>> Maybe graduation would be a good opportunity for us to move to git.
> >>>
> >>> Wdyt?
> >>> Reto
> >>>
> >>> Forwarding from a thread on the any23 list.
> >>> On Feb 16, 2013 5:21 AM, "Lewis John Mcgibbney" <
> >>> lewis.mcgibbney@gmail.com>
> >>> wrote:
> >>>
> >>>> Hi Reto,
> >>>>
> >>>> On Fri, Feb 15, 2013 at 8:17 PM, <dev-digest-help@any23.apache.org>
> >>> wrote:
> >>>>
> >>>>>
> >>>>> Is infra supporting already?
> >>>>>
> >>>>
> >>>> Aye
> >>>>
> >>>> Have a great weekend
> >>>> Lewis
> >>>>
> >>>>>
> >>>>>
> >>>>
> >>>
> >
> > --trialox ag-------------------------------------
> >   tsuyoshi ito
> >   hardturmstrasse 101
> >   8005 zuerich
> >
>
>
>
> --
> Enrico Daga
>
> --
> http://www.enridaga.net
> skype: enri-pan
>

+1

Enrico

On 18 February 2013 08:15, Tsuy Ito <tsuy.ito@trialox.org> wrote:
> +1
>
> cheers
> tsuy
>
> On Feb 17, 2013, at 7:29 PM, Tommaso Teofili <tommaso.teofili@gmail.com> wrote:
>
>> I'd be +1 for that.
>> Tommaso
>>
>>
>> 2013/2/17 Reto Bachmann-Gmür <reto@wymiwyg.com>
>>
>>> Maybe graduation would be a good opportunity for us to move to git.
>>>
>>> Wdyt?
>>> Reto
>>>
>>> Forwarding from a thread on the any23 list.
>>> On Feb 16, 2013 5:21 AM, "Lewis John Mcgibbney" <
>>> lewis.mcgibbney@gmail.com>
>>> wrote:
>>>
>>>> Hi Reto,
>>>>
>>>> On Fri, Feb 15, 2013 at 8:17 PM, <dev-digest-help@any23.apache.org>
>>> wrote:
>>>>
>>>>>
>>>>> Is infra supporting already?
>>>>>
>>>>
>>>> Aye
>>>>
>>>> Have a great weekend
>>>> Lewis
>>>>
>>>>>
>>>>>
>>>>
>>>
>
> --trialox ag-------------------------------------
>   tsuyoshi ito
>   hardturmstrasse 101
>   8005 zuerich
>



-- 
Enrico Daga

--
http://www.enridaga.net
skype: enri-pan

+1

cheers
tsuy

On Feb 17, 2013, at 7:29 PM, Tommaso Teofili <tommaso.teofili@gmail.com> wrote:

> I'd be +1 for that.
> Tommaso
> 
> 
> 2013/2/17 Reto Bachmann-Gmür <reto@wymiwyg.com>
> 
>> Maybe graduation would be a good opportunity for us to move to git.
>> 
>> Wdyt?
>> Reto
>> 
>> Forwarding from a thread on the any23 list.
>> On Feb 16, 2013 5:21 AM, "Lewis John Mcgibbney" <
>> lewis.mcgibbney@gmail.com>
>> wrote:
>> 
>>> Hi Reto,
>>> 
>>> On Fri, Feb 15, 2013 at 8:17 PM, <dev-digest-help@any23.apache.org>
>> wrote:
>>> 
>>>> 
>>>> Is infra supporting already?
>>>> 
>>> 
>>> Aye
>>> 
>>> Have a great weekend
>>> Lewis
>>> 
>>>> 
>>>> 
>>> 
>> 

--trialox ag-------------------------------------
  tsuyoshi ito
  hardturmstrasse 101 
  8005 zuerich

I'd be +1 for that.
Tommaso


2013/2/17 Reto Bachmann-Gmür <reto@wymiwyg.com>

> Maybe graduation would be a good opportunity for us to move to git.
>
> Wdyt?
> Reto
>
> Forwarding from a thread on the any23 list.
>  On Feb 16, 2013 5:21 AM, "Lewis John Mcgibbney" <
> lewis.mcgibbney@gmail.com>
> wrote:
>
> > Hi Reto,
> >
> > On Fri, Feb 15, 2013 at 8:17 PM, <dev-digest-help@any23.apache.org>
> wrote:
> >
> > >
> > > Is infra supporting already?
> > >
> >
> > Aye
> >
> > Have a great weekend
> > Lewis
> >
> > >
> > >
> >
>

Maybe graduation would be a good opportunity for us to move to git.

Wdyt?
Reto

Forwarding from a thread on the any23 list.
 On Feb 16, 2013 5:21 AM, "Lewis John Mcgibbney" <lewis.mcgibbney@gmail.com>
wrote:

> Hi Reto,
>
> On Fri, Feb 15, 2013 at 8:17 PM, <dev-digest-help@any23.apache.org> wrote:
>
> >
> > Is infra supporting already?
> >
>
> Aye
>
> Have a great weekend
> Lewis
>
> >
> >
>

    [ https://issues.apache.org/jira/browse/CLEREZZA-724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13580134#comment-13580134
] 

Tommaso Teofili commented on CLEREZZA-724:
------------------------------------------

sure the OOM may not be related while I'm not sure about the NPE, now checking again.
                
> Remove internally used "org.apache.xerces.util" from bundle import-package/export-package
> -----------------------------------------------------------------------------------------
>
>                 Key: CLEREZZA-724
>                 URL: https://issues.apache.org/jira/browse/CLEREZZA-724
>             Project: Clerezza
>          Issue Type: Bug
>          Components: rdf.parse
>    Affects Versions: 0.2-incubating
>            Reporter: Minto van der Sluis
>         Attachments: Issue-724.patch
>
>
> I am experiencing LinkageError when using Clerezza in combination with CXF.
> Caused by: java.lang.LinkageError: loader constraint violation: when
> resolving method
> "org.apache.xerces.util.ParserConfigurationSettings.<init>(Lorg/apache/xerces/xni/parser/XMLComponentManager;)V"
> the class loader (instance of
> org/apache/felix/framework/BundleWiringImpl$BundleClassLoaderJava5) of
> the current class, org/apache/xerces/parsers/BasicParserConfiguration,
> and the class loader (instance of
> org/apache/felix/framework/BundleWiringImpl$BundleClassLoaderJava5) for
> resolved class, org/apache/xerces/util/ParserConfigurationSettings, have
> different Class objects for the type
> gs.<init>(Lorg/apache/xerces/xni/parser/XMLComponentManager;)V used in
> the signature
>     at org.apache.xerces.parsers.BasicParserConfiguration.<init>(Unknown
> Source)
>     at org.apache.xerces.parsers.DTDConfiguration.<init>(Unknown Source)
>     at
> org.apache.xerces.parsers.StandardParserConfiguration.<init>(Unknown Source)
>     at
> org.apache.xerces.parsers.StandardParserConfiguration.<init>(Unknown Source)
>     at
> com.hp.hpl.jena.rdf.arp.impl.RDFXMLParser.create(RDFXMLParser.java:117)
>     at com.hp.hpl.jena.rdf.arp.JenaReader.<init>(JenaReader.java:62)
>     at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)[:1.7.0_02]
>     at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)[:1.7.0_02]
>     at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)[:1.7.0_02]
>     at
> java.lang.reflect.Constructor.newInstance(Constructor.java:525)[:1.7.0_02]
>     at java.lang.Class.newInstance0(Class.java:372)[:1.7.0_02]
>     at java.lang.Class.newInstance(Class.java:325)[:1.7.0_02]
>     at
> com.hp.hpl.jena.rdf.model.impl.RDFReaderFImpl.getReader(RDFReaderFImpl.java:113)
>     at com.hp.hpl.jena.rdf.model.impl.ModelCom.read(ModelCom.java:226)
>     at
> org.apache.clerezza.rdf.jena.parser.JenaParserProvider.parse(JenaParserProvider.java:68)
>     ...
> Removing "org.apache.xerces.util" from the bundle import-package and export-package resuls
in expected operation. Since the Xerces library is embedded inside the bundle it needs not
to be exported.
> See also the mailing list:
> http://mail-archives.apache.org/mod_mbox/incubator-clerezza-dev/201212.mbox/%3C50C0B4BB.3030307%40xup.nl%3E

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira