[jira] [Commented] (SYNCOPE-315) "Persistent" feedback messages

[Hudson (JIRA)]

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

Hudson commented on SYNCOPE-315:


Integrated in Syncope-1_0_X #148 (See 
[https://builds.apache.org/job/Syncope-1_0_X/148/])
[SYNCOPE-315] Fixing add new mapping on a resource (Revision 1447304)

 Result = SUCCESS
ilgrosso : 
Files : 
* 
/syncope/branches/1_0_X/console/src/main/java/org/apache/syncope/console/pages/ResourceModalPage.java
* 
/syncope/branches/1_0_X/console/src/main/java/org/apache/syncope/console/pages/panels/ResourceMappingPanel.java


> "Persistent" feedback messages
> --
>
> Key: SYNCOPE-315
> URL: https://issues.apache.org/jira/browse/SYNCOPE-315
> Project: Syncope
>  Issue Type: Bug
>  Components: console
>Affects Versions: 1.0.5, 1.1.0
>Reporter: Francesco Chicchiriccò
>Assignee: Francesco Chicchiriccò
>Priority: Minor
> Fix For: 1.0.6, 1.1.0
>
>
> Once feedback messages have been reported, they stay on the page until 
> navigating away of that page: note that this does not apply to AJAX 
> navigation.

--
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

[jira] [Resolved] (SYNCOPE-257) Schema Mapping for propagation and synchronization

[fabio martelli (JIRA)]

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

fabio martelli resolved SYNCOPE-257.


Resolution: Fixed

> Schema Mapping for propagation and synchronization
> --
>
> Key: SYNCOPE-257
> URL: https://issues.apache.org/jira/browse/SYNCOPE-257
> Project: Syncope
>  Issue Type: Improvement
>  Components: console, core
>Affects Versions: 1.1.0
>Reporter: fabio martelli
>Assignee: fabio martelli
> Fix For: 1.1.0
>
>
> Syncope should give the possibility to specify two different mappings for 
> synchronization and propagation.
> My suggestion is to provide two boolean flags: the former to specify a 
> propagation mapping and the latter to specify a synchronization mapping.
> Of course, each mapping must have a flag to true at least.
> About the administration console, I'd suggest to have all the mappings about 
> the same resource into a single tab. I think that, in this way, mapping 
> configuration would be simple and easy to manage (in terms of troubleshooting 
> as well).

--
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

[jira] [Commented] (SYNCOPE-315) "Persistent" feedback messages

[Hudson (JIRA)]

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

Hudson commented on SYNCOPE-315:


Integrated in Syncope-trunk #99 (See 
[https://builds.apache.org/job/Syncope-trunk/99/])
[SYNCOPE-315] Merge from 1_0_X (Revision 1447321)

 Result = SUCCESS
ilgrosso : 
Files : 
* /syncope/trunk
* 
/syncope/trunk/console/src/main/java/org/apache/syncope/console/pages/ResourceModalPage.java
* 
/syncope/trunk/console/src/main/java/org/apache/syncope/console/pages/panels/ResourceMappingPanel.java
* 
/syncope/trunk/console/src/main/java/org/apache/syncope/console/rest/ConnectorRestClient.java


> "Persistent" feedback messages
> --
>
> Key: SYNCOPE-315
> URL: https://issues.apache.org/jira/browse/SYNCOPE-315
> Project: Syncope
>  Issue Type: Bug
>  Components: console
>Affects Versions: 1.0.5, 1.1.0
>Reporter: Francesco Chicchiriccò
>Assignee: Francesco Chicchiriccò
>Priority: Minor
> Fix For: 1.0.6, 1.1.0
>
>
> Once feedback messages have been reported, they stay on the page until 
> navigating away of that page: note that this does not apply to AJAX 
> navigation.

--
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

[jira] [Commented] (SYNCOPE-317) Error executing SyncTask twice or more

[Hudson (JIRA)]

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

Hudson commented on SYNCOPE-317:


Integrated in Syncope-trunk #99 (See 
[https://builds.apache.org/job/Syncope-trunk/99/])
[SYNCOPE-317] Fixing SyncopeUser.suspended management across different 
players (Revision 1447284)

 Result = SUCCESS
ilgrosso : 
Files : 
* 
/syncope/trunk/client/src/main/java/org/apache/syncope/client/services/proxy/TaskServiceProxy.java
* 
/syncope/trunk/core/src/main/java/org/apache/syncope/core/policy/AccountPolicyEnforcer.java
* 
/syncope/trunk/core/src/main/java/org/apache/syncope/core/security/SyncopeUserDetailsService.java
* 
/syncope/trunk/core/src/main/java/org/apache/syncope/core/sync/impl/SyncopeSyncResultHandler.java
* 
/syncope/trunk/core/src/main/java/org/apache/syncope/core/workflow/WorkflowException.java
* 
/syncope/trunk/core/src/main/java/org/apache/syncope/core/workflow/WorkflowUserSuspender.java
* 
/syncope/trunk/core/src/main/java/org/apache/syncope/core/workflow/user/AbstractUserWorkflowAdapter.java
* 
/syncope/trunk/core/src/main/java/org/apache/syncope/core/workflow/user/NoOpUserWorkflowAdapter.java
* 
/syncope/trunk/core/src/main/java/org/apache/syncope/core/workflow/user/UserWorkflowAdapter.java
* 
/syncope/trunk/core/src/main/java/org/apache/syncope/core/workflow/user/activiti/ActivitiUserWorkflowAdapter.java
* 
/syncope/trunk/core/src/main/java/org/apache/syncope/core/workflow/user/activiti/task/AutoActivate.java
* 
/syncope/trunk/core/src/test/java/org/apache/syncope/core/rest/TaskTestITCase.java


> Error executing SyncTask twice or more
> --
>
> Key: SYNCOPE-317
> URL: https://issues.apache.org/jira/browse/SYNCOPE-317
> Project: Syncope
>  Issue Type: Bug
>  Components: core
>Affects Versions: 1.1.0
>Reporter: Francesco Chicchiriccò
>Assignee: Francesco Chicchiriccò
> Fix For: 1.1.0
>
>
> When executing a SyncTask (with update allowed), the first run goes fine and 
> users get created.
> If executing the same task again, an error is thrown and no action is 
> performed:
> org.activiti.engine.ActivitiException: No outgoing sequence flow of the 
> exclusive gateway 'activeGw' could be selected for continuing the process
> This can be replicated by executing twice the SyncTask 4 of the test data set.

--
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

[jira] [Commented] (SYNCOPE-257) Schema Mapping for propagation and synchronization

[Hudson (JIRA)]

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

Hudson commented on SYNCOPE-257:


Integrated in Syncope-trunk #99 (See 
[https://builds.apache.org/job/Syncope-trunk/99/])
SYNCOPE-257 fixed (Revision 1447396)
[SYNCOPE-257] Filtering out template attributes with no values (Revision 
1447376)

 Result = SUCCESS
fmartelli : 
Files : 
* 
/syncope/trunk/common/src/main/java/org/apache/syncope/common/to/MappingItemTO.java
* 
/syncope/trunk/common/src/main/java/org/apache/syncope/common/types/MappingPurpose.java
* 
/syncope/trunk/console/src/main/java/org/apache/syncope/console/pages/panels/ResourceMappingPanel.java
* 
/syncope/trunk/console/src/main/resources/org/apache/syncope/console/pages/ResourceModalPage.properties
* 
/syncope/trunk/console/src/main/resources/org/apache/syncope/console/pages/ResourceModalPage_it.properties
* 
/syncope/trunk/console/src/main/resources/org/apache/syncope/console/pages/panels/ResourceMappingPanel.html
* 
/syncope/trunk/core/src/main/java/org/apache/syncope/core/connid/ConnObjectUtil.java
* 
/syncope/trunk/core/src/main/java/org/apache/syncope/core/persistence/beans/AbstractMappingItem.java
* 
/syncope/trunk/core/src/main/java/org/apache/syncope/core/propagation/impl/AbstractPropagationTaskExecutor.java
* 
/syncope/trunk/core/src/main/java/org/apache/syncope/core/propagation/impl/PropagationManager.java
* 
/syncope/trunk/core/src/main/java/org/apache/syncope/core/rest/controller/ResourceController.java
* 
/syncope/trunk/core/src/main/java/org/apache/syncope/core/rest/data/AbstractAttributableDataBinder.java
* 
/syncope/trunk/core/src/main/java/org/apache/syncope/core/sync/impl/SyncopeSyncResultHandler.java
* 
/syncope/trunk/core/src/main/java/org/apache/syncope/core/util/AttributableUtil.java
* 
/syncope/trunk/core/src/test/java/org/apache/syncope/core/persistence/dao/ResourceTest.java
* 
/syncope/trunk/core/src/test/java/org/apache/syncope/core/persistence/relationships/ResourceTest.java
* 
/syncope/trunk/core/src/test/java/org/apache/syncope/core/rest/ResourceTestITCase.java
* 
/syncope/trunk/core/src/test/java/org/apache/syncope/core/rest/TaskTestITCase.java
* 
/syncope/trunk/core/src/test/java/org/apache/syncope/core/rest/UserTestITCase.java
* 
/syncope/trunk/core/src/test/java/org/apache/syncope/core/rest/data/ResourceDataTest.java
* /syncope/trunk/core/src/test/resources/content.xml
* /syncope/trunk/pom.xml

ilgrosso : 
Files : 
* 
/syncope/trunk/core/src/main/java/org/apache/syncope/core/connid/ConnObjectUtil.java
* 
/syncope/trunk/core/src/main/java/org/apache/syncope/core/rest/controller/TaskController.java


> Schema Mapping for propagation and synchronization
> --
>
> Key: SYNCOPE-257
> URL: https://issues.apache.org/jira/browse/SYNCOPE-257
> Project: Syncope
>  Issue Type: Improvement
>  Components: console, core
>Affects Versions: 1.1.0
>Reporter: fabio martelli
>Assignee: fabio martelli
> Fix For: 1.1.0
>
>
> Syncope should give the possibility to specify two different mappings for 
> synchronization and propagation.
> My suggestion is to provide two boolean flags: the former to specify a 
> propagation mapping and the latter to specify a synchronization mapping.
> Of course, each mapping must have a flag to true at least.
> About the administration console, I'd suggest to have all the mappings about 
> the same resource into a single tab. I think that, in this way, mapping 
> configuration would be simple and easy to manage (in terms of troubleshooting 
> as well).

--
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

Re: Commons Lang version

[Colm O hEigeartaigh]

Hi Francesco,

This means that if commons-lang:2.6 is pulled in by some dependency (in
> addition to being listed in syncope-common), we will be forced to use both
> versions.


Ok I guess this is unavoidable. Let's just leave things as they are then I
guess until Activiti upgrades.

Colm.

On Tue, Feb 19, 2013 at 7:58 AM, Francesco Chicchiriccò  wrote:

> On 18/02/2013 18:00, Francesco Chicchiriccň wrote:
>
>> On 18/02/2013 17:13, Colm O hEigeartaigh wrote:
>>
>>> Hi all,
>>>
>>> We have two different dependencies of Commons Lang in 'core':
>>>
>>> commons-lang:commons-lang:jar:**2.6:compile
>>> org.apache.commons:commons-**lang3:jar:3.1:compile
>>>
>>> 2.6 is coming in from syncope-common, 3.1 via Apache bval. Should we just
>>> upgrade Syncope to use 3.1?
>>>
>>
>> +1
>>
>> Also consider that, as reported in commons-lang homepage,
>>
>>  Note that Lang 3.0 (and subsequent versions) use a different package
>>> (/org.apache.commons.lang3/) than the previous versions
>>> (/org.apache.commons.lang/), allowing it to be used at the same time as an
>>> earlier version.
>>>
>>
>> This means that if commons-lang:2.6 is pulled in by some dependency (in
>> addition to being listed in syncope-common), we will be forced to use both
>> versions.
>>
>
>
> [INFO] +- org.activiti:activiti-engine:**jar:5.11:compile
> [INFO] |  +- org.apache.commons:commons-**email:jar:1.2:compile
> [INFO] |  +- commons-lang:commons-lang:jar:**2.4:compile
> [INFO] |  +- org.mybatis:mybatis:jar:3.1.1:**compile
> [INFO] |  \- joda-time:joda-time:jar:2.1:**compile
>
> Any idea?
>
> --
> Francesco Chicchiriccň
>
>
> ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
> http://people.apache.org/~**ilgrosso/
>
>


-- 
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

[jira] [Created] (SYNCOPE-318) No way to see Connector help message for multi-valued property

[Colm O hEigeartaigh (JIRA)]

Colm O hEigeartaigh created SYNCOPE-318:
---

 Summary: No way to see Connector help message for multi-valued 
property
 Key: SYNCOPE-318
 URL: https://issues.apache.org/jira/browse/SYNCOPE-318
 Project: Syncope
  Issue Type: Bug
Reporter: Colm O hEigeartaigh



When configuring a Connector in Syncope, it is possible to hover the mouse 
pointer over the textfield to see the corresponding help message associated 
with the property. However, when the property is a multi-valued field, no help 
message appears.

--
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

CSV Connector SNAPSHOT version

[Colm O hEigeartaigh]

Hi all,

Following the query on the CSV SNAPSHOT in Syncope, just wondering why are
we including 0.6.1-SNAPSHOT on trunk instead of 0.7-SNAPSHOT? The former
does not include the fixes I made recently (in particular the properties
file is in the wrong package name, and so the correct property keys are not
displayed in Syncope).

Colm.


-- 
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

[jira] [Updated] (SYNCOPE-318) No way to see Connector help message for multi-valued property

[JIRA]

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

Francesco Chicchiriccò updated SYNCOPE-318:
---

Component/s: console

> No way to see Connector help message for multi-valued property
> --
>
> Key: SYNCOPE-318
> URL: https://issues.apache.org/jira/browse/SYNCOPE-318
> Project: Syncope
>  Issue Type: Bug
>  Components: console
>Reporter: Colm O hEigeartaigh
>
> When configuring a Connector in Syncope, it is possible to hover the mouse 
> pointer over the textfield to see the corresponding help message associated 
> with the property. However, when the property is a multi-valued field, no 
> help message appears.

--
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

[jira] [Updated] (SYNCOPE-318) No way to see Connector help message for multi-valued property

[JIRA]

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

Francesco Chicchiriccò updated SYNCOPE-318:
---

Fix Version/s: 1.1.0

> No way to see Connector help message for multi-valued property
> --
>
> Key: SYNCOPE-318
> URL: https://issues.apache.org/jira/browse/SYNCOPE-318
> Project: Syncope
>  Issue Type: Bug
>  Components: console
>Reporter: Colm O hEigeartaigh
> Fix For: 1.1.0
>
>
> When configuring a Connector in Syncope, it is possible to hover the mouse 
> pointer over the textfield to see the corresponding help message associated 
> with the property. However, when the property is a multi-valued field, no 
> help message appears.

--
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

Re: CSV Connector SNAPSHOT version

[Francesco Chicchiriccò]

On 19/02/2013 11:13, Colm O hEigeartaigh wrote:

Hi all,

Following the query on the CSV SNAPSHOT in Syncope, just wondering why are
we including 0.6.1-SNAPSHOT on trunk instead of 0.7-SNAPSHOT? The former
does not include the fixes I made recently (in particular the properties
file is in the wrong package name, and so the correct property keys are not
displayed in Syncope).


When using the CSVDir 0.7-SNAPSHOT we would be forced to use ConnId 
1.3.3-SNAPSHOT instead of 1.3.2.


Why not backporting your fix on 0.7-SNAPSHOT to 0.6.1-SNAPSHOT?

Regards.

--
Francesco Chicchiriccò

ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/

Re: CSV Connector SNAPSHOT version

[Colm O hEigeartaigh]

> When using the CSVDir 0.7-SNAPSHOT we would be forced to use ConnId
> 1.3.3-SNAPSHOT instead of 1.3.2.
>

Is there any reason why we can't just do that on trunk anyway? I assume
we're going to release Syncope 1.1 with ConnId 1.3.3 anyway?


> Why not backporting your fix on 0.7-SNAPSHOT to 0.6.1-SNAPSHOT?
>

I will do.

Colm.



On Tue, Feb 19, 2013 at 10:25 AM, Francesco Chicchiriccò <
ilgro...@apache.org> wrote:

> On 19/02/2013 11:13, Colm O hEigeartaigh wrote:
>
>> Hi all,
>>
>> Following the query on the CSV SNAPSHOT in Syncope, just wondering why are
>> we including 0.6.1-SNAPSHOT on trunk instead of 0.7-SNAPSHOT? The former
>> does not include the fixes I made recently (in particular the properties
>> file is in the wrong package name, and so the correct property keys are
>> not
>> displayed in Syncope).
>>
>
> When using the CSVDir 0.7-SNAPSHOT we would be forced to use ConnId
> 1.3.3-SNAPSHOT instead of 1.3.2.
>
> Why not backporting your fix on 0.7-SNAPSHOT to 0.6.1-SNAPSHOT?
>
> Regards.
>
> --
> Francesco Chicchiriccò
>
> ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
> http://people.apache.org/~**ilgrosso/
>
>


-- 
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

Re: CSV Connector SNAPSHOT version

[Francesco Chicchiriccò]

On 19/02/2013 11:28, Colm O hEigeartaigh wrote:

When using the CSVDir 0.7-SNAPSHOT we would be forced to use ConnId
1.3.3-SNAPSHOT instead of 1.3.2.

Is there any reason why we can't just do that on trunk anyway? I assume
we're going to release Syncope 1.1 with ConnId 1.3.3 anyway?


Not sure: I think it heavily depends on when this ConnId 1.3.3 will be 
available; personally, I will go with 1.3.2 for Syncope 1.1.0.



Why not backporting your fix on 0.7-SNAPSHOT to 0.6.1-SNAPSHOT?


I will do.


Fine.

Regards.


On Tue, Feb 19, 2013 at 10:25 AM, Francesco Chicchiriccò <
ilgro...@apache.org> wrote:


On 19/02/2013 11:13, Colm O hEigeartaigh wrote:


Hi all,

Following the query on the CSV SNAPSHOT in Syncope, just wondering why are
we including 0.6.1-SNAPSHOT on trunk instead of 0.7-SNAPSHOT? The former
does not include the fixes I made recently (in particular the properties
file is in the wrong package name, and so the correct property keys are
not
displayed in Syncope).


When using the CSVDir 0.7-SNAPSHOT we would be forced to use ConnId
1.3.3-SNAPSHOT instead of 1.3.2.

Why not backporting your fix on 0.7-SNAPSHOT to 0.6.1-SNAPSHOT?

Regards.

--
Francesco Chicchiriccò

ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~**ilgrosso/







--
Francesco Chicchiriccò

ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/

Re: CSV Connector SNAPSHOT version

[Francesco Chicchiriccò]

On 19/02/2013 11:32, Francesco Chicchiriccò wrote:

On 19/02/2013 11:28, Colm O hEigeartaigh wrote:

When using the CSVDir 0.7-SNAPSHOT we would be forced to use ConnId
1.3.3-SNAPSHOT instead of 1.3.2.

Is there any reason why we can't just do that on trunk anyway? I assume
we're going to release Syncope 1.1 with ConnId 1.3.3 anyway?


Not sure: I think it heavily depends on when this ConnId 1.3.3 will be 
available; personally, I will go with 1.3.2 for Syncope 1.1.0.


I should have said "I would go"... sorry.


Why not backporting your fix on 0.7-SNAPSHOT to 0.6.1-SNAPSHOT?


I will do.


Fine.

Regards.


On Tue, Feb 19, 2013 at 10:25 AM, Francesco Chicchiriccò <
ilgro...@apache.org> wrote:


On 19/02/2013 11:13, Colm O hEigeartaigh wrote:


Hi all,

Following the query on the CSV SNAPSHOT in Syncope, just wondering 
why are
we including 0.6.1-SNAPSHOT on trunk instead of 0.7-SNAPSHOT? The 
former
does not include the fixes I made recently (in particular the 
properties
file is in the wrong package name, and so the correct property keys 
are

not
displayed in Syncope).


When using the CSVDir 0.7-SNAPSHOT we would be forced to use ConnId
1.3.3-SNAPSHOT instead of 1.3.2.

Why not backporting your fix on 0.7-SNAPSHOT to 0.6.1-SNAPSHOT?

Regards.

--
Francesco Chicchiriccò

ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~**ilgrosso/ 












--
Francesco Chicchiriccò

ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/

Re: CSV Connector SNAPSHOT version

[Fabio Martelli]

Il giorno 19/feb/2013, alle ore 11.28, Colm O hEigeartaigh ha scritto:

>> When using the CSVDir 0.7-SNAPSHOT we would be forced to use ConnId
>> 1.3.3-SNAPSHOT instead of 1.3.2.
>> 
> 
> Is there any reason why we can't just do that on trunk anyway? I assume
> we're going to release Syncope 1.1 with ConnId 1.3.3 anyway?

Guys, I'd prefere to keep the 1.3.2 for Syncope 1.1.0.
Since we are expecting to release soon I'd like to be sure about the 
reliability of the 1.1.0.

Regards,
F.

>> Why not backporting your fix on 0.7-SNAPSHOT to 0.6.1-SNAPSHOT?
> I will do.
> 
> Colm.
> 
> 
> 
> On Tue, Feb 19, 2013 at 10:25 AM, Francesco Chicchiriccò <
> ilgro...@apache.org> wrote:
> 
>> On 19/02/2013 11:13, Colm O hEigeartaigh wrote:
>> 
>>> Hi all,
>>> 
>>> Following the query on the CSV SNAPSHOT in Syncope, just wondering why are
>>> we including 0.6.1-SNAPSHOT on trunk instead of 0.7-SNAPSHOT? The former
>>> does not include the fixes I made recently (in particular the properties
>>> file is in the wrong package name, and so the correct property keys are
>>> not
>>> displayed in Syncope).
>>> 
>> 
>> When using the CSVDir 0.7-SNAPSHOT we would be forced to use ConnId
>> 1.3.3-SNAPSHOT instead of 1.3.2.
>> 
>> Why not backporting your fix on 0.7-SNAPSHOT to 0.6.1-SNAPSHOT?
>> 
>> Regards.
>> 
>> --
>> Francesco Chicchiriccò
>> 
>> ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
>> http://people.apache.org/~**ilgrosso/
>> 
>> 
> 
> 
> -- 
> Colm O hEigeartaigh
> 
> Talend Community Coder
> http://coders.talend.com

Re: CSV Connector SNAPSHOT version

[Colm O hEigeartaigh]

>
> Guys, I'd prefere to keep the 1.3.2 for Syncope 1.1.0.
> Since we are expecting to release soon I'd like to be sure about the
> reliability of the 1.1.0.


Why do you think 1.3.3 would be particularly unreliable? There have not
been many fixes made from what I can see.

I don't have strong objections to using 1.3.2 for Syncope 1.1, however I
would like if the fixes I've made make it into Syncope for 1.1. I will
backport the CSV fixes to the branch. How about a new branch for the LDAP +
DB bundles that I can backport fixes to? In particular I would like to have
LDAP-2, LDAP-5 and LDAP-6 available in Syncope 1.1.

Colm.

On Tue, Feb 19, 2013 at 10:36 AM, Fabio Martelli
wrote:

>
> Il giorno 19/feb/2013, alle ore 11.28, Colm O hEigeartaigh ha scritto:
>
> >> When using the CSVDir 0.7-SNAPSHOT we would be forced to use ConnId
> >> 1.3.3-SNAPSHOT instead of 1.3.2.
> >>
> >
> > Is there any reason why we can't just do that on trunk anyway? I assume
> > we're going to release Syncope 1.1 with ConnId 1.3.3 anyway?
>
> Guys, I'd prefere to keep the 1.3.2 for Syncope 1.1.0.
> Since we are expecting to release soon I'd like to be sure about the
> reliability of the 1.1.0.
>
> Regards,
> F.
>
> >> Why not backporting your fix on 0.7-SNAPSHOT to 0.6.1-SNAPSHOT?
> > I will do.
> >
> > Colm.
> >
> >
> >
> > On Tue, Feb 19, 2013 at 10:25 AM, Francesco Chicchiriccò <
> > ilgro...@apache.org> wrote:
> >
> >> On 19/02/2013 11:13, Colm O hEigeartaigh wrote:
> >>
> >>> Hi all,
> >>>
> >>> Following the query on the CSV SNAPSHOT in Syncope, just wondering why
> are
> >>> we including 0.6.1-SNAPSHOT on trunk instead of 0.7-SNAPSHOT? The
> former
> >>> does not include the fixes I made recently (in particular the
> properties
> >>> file is in the wrong package name, and so the correct property keys are
> >>> not
> >>> displayed in Syncope).
> >>>
> >>
> >> When using the CSVDir 0.7-SNAPSHOT we would be forced to use ConnId
> >> 1.3.3-SNAPSHOT instead of 1.3.2.
> >>
> >> Why not backporting your fix on 0.7-SNAPSHOT to 0.6.1-SNAPSHOT?
> >>
> >> Regards.
> >>
> >> --
> >> Francesco Chicchiriccò
> >>
> >> ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
> >> http://people.apache.org/~**ilgrosso/<
> http://people.apache.org/~ilgrosso/>
> >>
> >>
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
>
>


-- 
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

Re: CSV Connector SNAPSHOT version

[Fabio Martelli]

Il giorno 19/feb/2013, alle ore 11.44, Colm O hEigeartaigh ha scritto:

>> 
>> Guys, I'd prefere to keep the 1.3.2 for Syncope 1.1.0.
>> Since we are expecting to release soon I'd like to be sure about the
>> reliability of the 1.1.0.
> 
> 
> Why do you think 1.3.3 would be particularly unreliable? There have not
> been many fixes made from what I can see.
> 
> I don't have strong objections to using 1.3.2 for Syncope 1.1, however I
> would like if the fixes I've made make it into Syncope for 1.1. I will
> backport the CSV fixes to the branch. How about a new branch for the LDAP +
> DB bundles that I can backport fixes to? In particular I would like to have
> LDAP-2, LDAP-5 and LDAP-6 available in Syncope 1.1.

OK Colm, probably we can do the following.
Since I'd like to maintain the possibility to switch from a newest connector 
version  to an old one I'd ask you to verify before the possibility to run, for 
example,  CsvDir 0.6.1-SNAPSHOT with the latest framework version.
If I well remember this should be possible (the opposite is not possible for 
sure). This would be sufficient to have my +1.

Best regards,
F.

> On Tue, Feb 19, 2013 at 10:36 AM, Fabio Martelli
> wrote:
> 
>> 
>> Il giorno 19/feb/2013, alle ore 11.28, Colm O hEigeartaigh ha scritto:
>> 
 When using the CSVDir 0.7-SNAPSHOT we would be forced to use ConnId
 1.3.3-SNAPSHOT instead of 1.3.2.
 
>>> 
>>> Is there any reason why we can't just do that on trunk anyway? I assume
>>> we're going to release Syncope 1.1 with ConnId 1.3.3 anyway?
>> 
>> Guys, I'd prefere to keep the 1.3.2 for Syncope 1.1.0.
>> Since we are expecting to release soon I'd like to be sure about the
>> reliability of the 1.1.0.
>> 
>> Regards,
>> F.
>> 
 Why not backporting your fix on 0.7-SNAPSHOT to 0.6.1-SNAPSHOT?
>>> I will do.
>>> 
>>> Colm.
>>> 
>>> 
>>> 
>>> On Tue, Feb 19, 2013 at 10:25 AM, Francesco Chicchiriccò <
>>> ilgro...@apache.org> wrote:
>>> 
 On 19/02/2013 11:13, Colm O hEigeartaigh wrote:
 
> Hi all,
> 
> Following the query on the CSV SNAPSHOT in Syncope, just wondering why
>> are
> we including 0.6.1-SNAPSHOT on trunk instead of 0.7-SNAPSHOT? The
>> former
> does not include the fixes I made recently (in particular the
>> properties
> file is in the wrong package name, and so the correct property keys are
> not
> displayed in Syncope).
> 
 
 When using the CSVDir 0.7-SNAPSHOT we would be forced to use ConnId
 1.3.3-SNAPSHOT instead of 1.3.2.
 
 Why not backporting your fix on 0.7-SNAPSHOT to 0.6.1-SNAPSHOT?
 
 Regards.
 
 --
 Francesco Chicchiriccò
 
 ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
 http://people.apache.org/~**ilgrosso/<
>> http://people.apache.org/~ilgrosso/>
 
 
>>> 
>>> 
>>> --
>>> Colm O hEigeartaigh
>>> 
>>> Talend Community Coder
>>> http://coders.talend.com
>> 
>> 
> 
> 
> -- 
> Colm O hEigeartaigh
> 
> Talend Community Coder
> http://coders.talend.com

Re: CSV Connector SNAPSHOT version

[Colm O hEigeartaigh]

Hi Fabio,


> OK Colm, probably we can do the following.
> Since I'd like to maintain the possibility to switch from a newest
> connector version  to an old one I'd ask you to verify before the
> possibility to run, for example,  CsvDir 0.6.1-SNAPSHOT with the latest
> framework version.
> If I well remember this should be possible (the opposite is not possible
> for sure). This would be sufficient to have my +1.


Ok great, I will do this.

Colm.

On Tue, Feb 19, 2013 at 10:56 AM, Fabio Martelli
wrote:

>
> Il giorno 19/feb/2013, alle ore 11.44, Colm O hEigeartaigh ha scritto:
>
> >>
> >> Guys, I'd prefere to keep the 1.3.2 for Syncope 1.1.0.
> >> Since we are expecting to release soon I'd like to be sure about the
> >> reliability of the 1.1.0.
> >
> >
> > Why do you think 1.3.3 would be particularly unreliable? There have not
> > been many fixes made from what I can see.
> >
> > I don't have strong objections to using 1.3.2 for Syncope 1.1, however I
> > would like if the fixes I've made make it into Syncope for 1.1. I will
> > backport the CSV fixes to the branch. How about a new branch for the
> LDAP +
> > DB bundles that I can backport fixes to? In particular I would like to
> have
> > LDAP-2, LDAP-5 and LDAP-6 available in Syncope 1.1.
>
> OK Colm, probably we can do the following.
> Since I'd like to maintain the possibility to switch from a newest
> connector version  to an old one I'd ask you to verify before the
> possibility to run, for example,  CsvDir 0.6.1-SNAPSHOT with the latest
> framework version.
> If I well remember this should be possible (the opposite is not possible
> for sure). This would be sufficient to have my +1.
>
> Best regards,
> F.
>
> > On Tue, Feb 19, 2013 at 10:36 AM, Fabio Martelli
> > wrote:
> >
> >>
> >> Il giorno 19/feb/2013, alle ore 11.28, Colm O hEigeartaigh ha scritto:
> >>
>  When using the CSVDir 0.7-SNAPSHOT we would be forced to use ConnId
>  1.3.3-SNAPSHOT instead of 1.3.2.
> 
> >>>
> >>> Is there any reason why we can't just do that on trunk anyway? I assume
> >>> we're going to release Syncope 1.1 with ConnId 1.3.3 anyway?
> >>
> >> Guys, I'd prefere to keep the 1.3.2 for Syncope 1.1.0.
> >> Since we are expecting to release soon I'd like to be sure about the
> >> reliability of the 1.1.0.
> >>
> >> Regards,
> >> F.
> >>
>  Why not backporting your fix on 0.7-SNAPSHOT to 0.6.1-SNAPSHOT?
> >>> I will do.
> >>>
> >>> Colm.
> >>>
> >>>
> >>>
> >>> On Tue, Feb 19, 2013 at 10:25 AM, Francesco Chicchiriccò <
> >>> ilgro...@apache.org> wrote:
> >>>
>  On 19/02/2013 11:13, Colm O hEigeartaigh wrote:
> 
> > Hi all,
> >
> > Following the query on the CSV SNAPSHOT in Syncope, just wondering
> why
> >> are
> > we including 0.6.1-SNAPSHOT on trunk instead of 0.7-SNAPSHOT? The
> >> former
> > does not include the fixes I made recently (in particular the
> >> properties
> > file is in the wrong package name, and so the correct property keys
> are
> > not
> > displayed in Syncope).
> >
> 
>  When using the CSVDir 0.7-SNAPSHOT we would be forced to use ConnId
>  1.3.3-SNAPSHOT instead of 1.3.2.
> 
>  Why not backporting your fix on 0.7-SNAPSHOT to 0.6.1-SNAPSHOT?
> 
>  Regards.
> 
>  --
>  Francesco Chicchiriccò
> 
>  ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
>  http://people.apache.org/~**ilgrosso/<
> >> http://people.apache.org/~ilgrosso/>
> 
> 
> >>>
> >>>
> >>> --
> >>> Colm O hEigeartaigh
> >>>
> >>> Talend Community Coder
> >>> http://coders.talend.com
> >>
> >>
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
>
>


-- 
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

Re: CSV Connector SNAPSHOT version

[Francesco Chicchiriccò]

On 19/02/2013 12:03, Colm O hEigeartaigh wrote:

Hi Fabio,

OK Colm, probably we can do the following.
Since I'd like to maintain the possibility to switch from a newest
connector version  to an old one I'd ask you to verify before the
possibility to run, for example,  CsvDir 0.6.1-SNAPSHOT with the latest
framework version.


According to [1], an image coming from the old IdentityConnectors 
Framework, it should be this way; hence, you should be able to run 
CSVDir 0.6 (or 0.6.1-SNAPSHOT) with ConnId 1.3.3-SNAPSHOT but not CSVDir 
0.7-SNAPSHOT with ConnId 1.3.2.



If I well remember this should be possible (the opposite is not possible
for sure). This would be sufficient to have my +1.


Ok great, I will do this.


Cool: this will save us from being forced to manage various branches on 
connectors.


Regards.

[1] https://raw.github.com/Tirasa/ConnId/master/images/compatibility.png


On Tue, Feb 19, 2013 at 10:56 AM, Fabio Martelli
wrote:


Il giorno 19/feb/2013, alle ore 11.44, Colm O hEigeartaigh ha scritto:


Guys, I'd prefere to keep the 1.3.2 for Syncope 1.1.0.
Since we are expecting to release soon I'd like to be sure about the
reliability of the 1.1.0.


Why do you think 1.3.3 would be particularly unreliable? There have not
been many fixes made from what I can see.

I don't have strong objections to using 1.3.2 for Syncope 1.1, however I
would like if the fixes I've made make it into Syncope for 1.1. I will
backport the CSV fixes to the branch. How about a new branch for the

LDAP +

DB bundles that I can backport fixes to? In particular I would like to

have

LDAP-2, LDAP-5 and LDAP-6 available in Syncope 1.1.

OK Colm, probably we can do the following.
Since I'd like to maintain the possibility to switch from a newest
connector version  to an old one I'd ask you to verify before the
possibility to run, for example,  CsvDir 0.6.1-SNAPSHOT with the latest
framework version.
If I well remember this should be possible (the opposite is not possible
for sure). This would be sufficient to have my +1.

Best regards,
F.


On Tue, Feb 19, 2013 at 10:36 AM, Fabio Martelli
wrote:


Il giorno 19/feb/2013, alle ore 11.28, Colm O hEigeartaigh ha scritto:


When using the CSVDir 0.7-SNAPSHOT we would be forced to use ConnId
1.3.3-SNAPSHOT instead of 1.3.2.


Is there any reason why we can't just do that on trunk anyway? I assume
we're going to release Syncope 1.1 with ConnId 1.3.3 anyway?

Guys, I'd prefere to keep the 1.3.2 for Syncope 1.1.0.
Since we are expecting to release soon I'd like to be sure about the
reliability of the 1.1.0.

Regards,
F.


Why not backporting your fix on 0.7-SNAPSHOT to 0.6.1-SNAPSHOT?

I will do.

Colm.



On Tue, Feb 19, 2013 at 10:25 AM, Francesco Chicchiriccò <
ilgro...@apache.org> wrote:


On 19/02/2013 11:13, Colm O hEigeartaigh wrote:


Hi all,

Following the query on the CSV SNAPSHOT in Syncope, just wondering

why

are

we including 0.6.1-SNAPSHOT on trunk instead of 0.7-SNAPSHOT? The

former

does not include the fixes I made recently (in particular the

properties

file is in the wrong package name, and so the correct property keys

are

not
displayed in Syncope).


When using the CSVDir 0.7-SNAPSHOT we would be forced to use ConnId
1.3.3-SNAPSHOT instead of 1.3.2.

Why not backporting your fix on 0.7-SNAPSHOT to 0.6.1-SNAPSHOT?

Regards.

--
Francesco Chicchiriccò

ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~**ilgrosso/<

http://people.apache.org/~ilgrosso/>




--
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com




--
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com







--
Francesco Chicchiriccò

ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/

[jira] [Assigned] (SYNCOPE-209) DB Table connector does not see changes in underlying table until restart

[JIRA]

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

Francesco Chicchiriccò reassigned SYNCOPE-209:
--

Assignee: Francesco Chicchiriccò  (was: fabio martelli)

> DB Table connector does not see changes in underlying table until restart
> -
>
> Key: SYNCOPE-209
> URL: https://issues.apache.org/jira/browse/SYNCOPE-209
> Project: Syncope
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 1.0.1-incubating
>Reporter: Francesco Chicchiriccò
>Assignee: Francesco Chicchiriccò
> Fix For: 1.1.0
>
>
> Steps to reproduce:
> 1. generate a project from 1.0.2-incubating-SNAPSHOT or 
> 1.1.0-incubating-SNAPSHOT archetypes (both tested)
> 2. mvn clean package
> 3. cd console && mvn -P embedded
> 1. log in http://localhost:9080/syncope-console/
> 2, go to resources -> resource-testdb -> mapping
> 1. go to http://localhost:9082
> 2. select "Generic H2 (Server)"
> 3. set JDBC URL to "jdbc:h2:tcp://localhost:9092/testdb"
> 4. set username 'sa' and password 'sa'
> 5. connect
> 6. send SQL statement 'ALTER TABLE TEST ADD COLUMN newcol VARCHAR(255)'
> 1. log in http://localhost:9080/syncope-console/
> 2, go to resources -> resource-testdb -> mapping
> At this point, when trying to add a new schema mapping, 'newcol' is not shown 
> among available values until restart

--
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

[jira] [Reopened] (SYNCOPE-257) Schema Mapping for propagation and synchronization

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh reopened SYNCOPE-257:
-



There's a minor UI bug I ran into when adding some User mappings. If you have a 
mapping from a user schema and forget to select a "purpose" you get an error 
when trying to "Save". However, if you then select a purpose the error persists.

Colm.

> Schema Mapping for propagation and synchronization
> --
>
> Key: SYNCOPE-257
> URL: https://issues.apache.org/jira/browse/SYNCOPE-257
> Project: Syncope
>  Issue Type: Improvement
>  Components: console, core
>Affects Versions: 1.1.0
>Reporter: fabio martelli
>Assignee: fabio martelli
> Fix For: 1.1.0
>
>
> Syncope should give the possibility to specify two different mappings for 
> synchronization and propagation.
> My suggestion is to provide two boolean flags: the former to specify a 
> propagation mapping and the latter to specify a synchronization mapping.
> Of course, each mapping must have a flag to true at least.
> About the administration console, I'd suggest to have all the mappings about 
> the same resource into a single tab. I think that, in this way, mapping 
> configuration would be simple and easy to manage (in terms of troubleshooting 
> as well).

--
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

[jira] [Created] (SYNCOPE-319) Provide feature for reloading all connectors

[JIRA]

Francesco Chicchiriccò created SYNCOPE-319:
--

 Summary: Provide feature for reloading all connectors
 Key: SYNCOPE-319
 URL: https://issues.apache.org/jira/browse/SYNCOPE-319
 Project: Syncope
  Issue Type: Improvement
Reporter: Francesco Chicchiriccò
 Fix For: 1.1.0


It is a feature particularly useful during project deployment that will allow 
to refresh all connector bundles and configuration.

--
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

[jira] [Assigned] (SYNCOPE-319) Provide feature for reloading all connectors

[JIRA]

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

Francesco Chicchiriccò reassigned SYNCOPE-319:
--

Assignee: Francesco Chicchiriccò

> Provide feature for reloading all connectors
> 
>
> Key: SYNCOPE-319
> URL: https://issues.apache.org/jira/browse/SYNCOPE-319
> Project: Syncope
>  Issue Type: Improvement
>Reporter: Francesco Chicchiriccò
>Assignee: Francesco Chicchiriccò
> Fix For: 1.1.0
>
>
> It is a feature particularly useful during project deployment that will allow 
> to refresh all connector bundles and configuration.

--
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

Re: CSV Connector SNAPSHOT version

[Colm O hEigeartaigh]

> How about a new branch for the LDAP + DB bundles that I can backport fixes
> to?


In terms of the DB Connector first, trunk is at 2.1.5-SNAPSHOT. How about I
update trunk to 2.2-SNAPSHOT + create a new branch called "2.1.X" (with
version 2.1.5-SNAPSHOT) before the recent revisions were made? I will then
selectively merge various fixes. Any objections to this?

Colm.

On Tue, Feb 19, 2013 at 10:56 AM, Fabio Martelli
wrote:

>
> Il giorno 19/feb/2013, alle ore 11.44, Colm O hEigeartaigh ha scritto:
>
> >>
> >> Guys, I'd prefere to keep the 1.3.2 for Syncope 1.1.0.
> >> Since we are expecting to release soon I'd like to be sure about the
> >> reliability of the 1.1.0.
> >
> >
> > Why do you think 1.3.3 would be particularly unreliable? There have not
> > been many fixes made from what I can see.
> >
> > I don't have strong objections to using 1.3.2 for Syncope 1.1, however I
> > would like if the fixes I've made make it into Syncope for 1.1. I will
> > backport the CSV fixes to the branch. How about a new branch for the
> LDAP +
> > DB bundles that I can backport fixes to? In particular I would like to
> have
> > LDAP-2, LDAP-5 and LDAP-6 available in Syncope 1.1.
>
> OK Colm, probably we can do the following.
> Since I'd like to maintain the possibility to switch from a newest
> connector version  to an old one I'd ask you to verify before the
> possibility to run, for example,  CsvDir 0.6.1-SNAPSHOT with the latest
> framework version.
> If I well remember this should be possible (the opposite is not possible
> for sure). This would be sufficient to have my +1.
>
> Best regards,
> F.
>
> > On Tue, Feb 19, 2013 at 10:36 AM, Fabio Martelli
> > wrote:
> >
> >>
> >> Il giorno 19/feb/2013, alle ore 11.28, Colm O hEigeartaigh ha scritto:
> >>
>  When using the CSVDir 0.7-SNAPSHOT we would be forced to use ConnId
>  1.3.3-SNAPSHOT instead of 1.3.2.
> 
> >>>
> >>> Is there any reason why we can't just do that on trunk anyway? I assume
> >>> we're going to release Syncope 1.1 with ConnId 1.3.3 anyway?
> >>
> >> Guys, I'd prefere to keep the 1.3.2 for Syncope 1.1.0.
> >> Since we are expecting to release soon I'd like to be sure about the
> >> reliability of the 1.1.0.
> >>
> >> Regards,
> >> F.
> >>
>  Why not backporting your fix on 0.7-SNAPSHOT to 0.6.1-SNAPSHOT?
> >>> I will do.
> >>>
> >>> Colm.
> >>>
> >>>
> >>>
> >>> On Tue, Feb 19, 2013 at 10:25 AM, Francesco Chicchiriccò <
> >>> ilgro...@apache.org> wrote:
> >>>
>  On 19/02/2013 11:13, Colm O hEigeartaigh wrote:
> 
> > Hi all,
> >
> > Following the query on the CSV SNAPSHOT in Syncope, just wondering
> why
> >> are
> > we including 0.6.1-SNAPSHOT on trunk instead of 0.7-SNAPSHOT? The
> >> former
> > does not include the fixes I made recently (in particular the
> >> properties
> > file is in the wrong package name, and so the correct property keys
> are
> > not
> > displayed in Syncope).
> >
> 
>  When using the CSVDir 0.7-SNAPSHOT we would be forced to use ConnId
>  1.3.3-SNAPSHOT instead of 1.3.2.
> 
>  Why not backporting your fix on 0.7-SNAPSHOT to 0.6.1-SNAPSHOT?
> 
>  Regards.
> 
>  --
>  Francesco Chicchiriccò
> 
>  ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
>  http://people.apache.org/~**ilgrosso/<
> >> http://people.apache.org/~ilgrosso/>
> 
> 
> >>>
> >>>
> >>> --
> >>> Colm O hEigeartaigh
> >>>
> >>> Talend Community Coder
> >>> http://coders.talend.com
> >>
> >>
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
>
>


-- 
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

Re: CSV Connector SNAPSHOT version

[Francesco Chicchiriccò]

On 19/02/2013 12:51, Colm O hEigeartaigh wrote:

How about a new branch for the LDAP + DB bundles that I can backport fixes to?

In terms of the DB Connector first, trunk is at 2.1.5-SNAPSHOT. How about I
update trunk to 2.2-SNAPSHOT + create a new branch called "2.1.X" (with
version 2.1.5-SNAPSHOT) before the recent revisions were made? I will then
selectively merge various fixes. Any objections to this?


I thought we could avoid this branching if we are able to verify that 
you can use "old" (e.g. compiled against ConnId 1.3.2) connectors with 
"new" (e.g. 1.3.3-SNAPSHOT) framework,


Am I wrong?

Regards.


On Tue, Feb 19, 2013 at 10:56 AM, Fabio Martelli
wrote:


Il giorno 19/feb/2013, alle ore 11.44, Colm O hEigeartaigh ha scritto:


Guys, I'd prefere to keep the 1.3.2 for Syncope 1.1.0.
Since we are expecting to release soon I'd like to be sure about the
reliability of the 1.1.0.


Why do you think 1.3.3 would be particularly unreliable? There have not
been many fixes made from what I can see.

I don't have strong objections to using 1.3.2 for Syncope 1.1, however I
would like if the fixes I've made make it into Syncope for 1.1. I will
backport the CSV fixes to the branch. How about a new branch for the

LDAP +

DB bundles that I can backport fixes to? In particular I would like to

have

LDAP-2, LDAP-5 and LDAP-6 available in Syncope 1.1.

OK Colm, probably we can do the following.
Since I'd like to maintain the possibility to switch from a newest
connector version  to an old one I'd ask you to verify before the
possibility to run, for example,  CsvDir 0.6.1-SNAPSHOT with the latest
framework version.
If I well remember this should be possible (the opposite is not possible
for sure). This would be sufficient to have my +1.

Best regards,
F.


On Tue, Feb 19, 2013 at 10:36 AM, Fabio Martelli
wrote:


Il giorno 19/feb/2013, alle ore 11.28, Colm O hEigeartaigh ha scritto:


When using the CSVDir 0.7-SNAPSHOT we would be forced to use ConnId
1.3.3-SNAPSHOT instead of 1.3.2.


Is there any reason why we can't just do that on trunk anyway? I assume
we're going to release Syncope 1.1 with ConnId 1.3.3 anyway?

Guys, I'd prefere to keep the 1.3.2 for Syncope 1.1.0.
Since we are expecting to release soon I'd like to be sure about the
reliability of the 1.1.0.

Regards,
F.


Why not backporting your fix on 0.7-SNAPSHOT to 0.6.1-SNAPSHOT?

I will do.

Colm.



On Tue, Feb 19, 2013 at 10:25 AM, Francesco Chicchiriccò <
ilgro...@apache.org> wrote:


On 19/02/2013 11:13, Colm O hEigeartaigh wrote:


Hi all,

Following the query on the CSV SNAPSHOT in Syncope, just wondering

why

are

we including 0.6.1-SNAPSHOT on trunk instead of 0.7-SNAPSHOT? The

former

does not include the fixes I made recently (in particular the

properties

file is in the wrong package name, and so the correct property keys

are

not
displayed in Syncope).


When using the CSVDir 0.7-SNAPSHOT we would be forced to use ConnId
1.3.3-SNAPSHOT instead of 1.3.2.

Why not backporting your fix on 0.7-SNAPSHOT to 0.6.1-SNAPSHOT?

Regards.


--
Francesco Chicchiriccò

ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/

Re: CSV Connector SNAPSHOT version

[Colm O hEigeartaigh]

Hi Francesco,

I thought we could avoid this branching if we are able to verify that you
> can use "old" (e.g. compiled against ConnId 1.3.2) connectors with "new"
> (e.g. 1.3.3-SNAPSHOT) framework,


Ok, I guess I misunderstood. I understand that we want to run an "old"
connector with the new framework, and so for example the CSV 0.6.x branch
should be able to run against the 1.3.3-SNAPSHOT framework version.

I don't understand though how we can avoid branching DB + LDAP if we want
to have the fixes I mentioned available in Syncope 1.1?

Colm.

On Tue, Feb 19, 2013 at 11:56 AM, Francesco Chicchiriccò <
ilgro...@apache.org> wrote:

> On 19/02/2013 12:51, Colm O hEigeartaigh wrote:
>
>> How about a new branch for the LDAP + DB bundles that I can backport
>>> fixes to?
>>>
>> In terms of the DB Connector first, trunk is at 2.1.5-SNAPSHOT. How about
>> I
>> update trunk to 2.2-SNAPSHOT + create a new branch called "2.1.X" (with
>> version 2.1.5-SNAPSHOT) before the recent revisions were made? I will then
>> selectively merge various fixes. Any objections to this?
>>
>
> I thought we could avoid this branching if we are able to verify that you
> can use "old" (e.g. compiled against ConnId 1.3.2) connectors with "new"
> (e.g. 1.3.3-SNAPSHOT) framework,
>
> Am I wrong?
>
> Regards.
>
>  On Tue, Feb 19, 2013 at 10:56 AM, Fabio Martelli
>> **wrote:
>>
>>  Il giorno 19/feb/2013, alle ore 11.44, Colm O hEigeartaigh ha scritto:
>>>
>>>  Guys, I'd prefere to keep the 1.3.2 for Syncope 1.1.0.
> Since we are expecting to release soon I'd like to be sure about the
> reliability of the 1.1.0.
>

 Why do you think 1.3.3 would be particularly unreliable? There have not
 been many fixes made from what I can see.

 I don't have strong objections to using 1.3.2 for Syncope 1.1, however I
 would like if the fixes I've made make it into Syncope for 1.1. I will
 backport the CSV fixes to the branch. How about a new branch for the

>>> LDAP +
>>>
 DB bundles that I can backport fixes to? In particular I would like to

>>> have
>>>
 LDAP-2, LDAP-5 and LDAP-6 available in Syncope 1.1.

>>> OK Colm, probably we can do the following.
>>> Since I'd like to maintain the possibility to switch from a newest
>>> connector version  to an old one I'd ask you to verify before the
>>> possibility to run, for example,  CsvDir 0.6.1-SNAPSHOT with the latest
>>> framework version.
>>> If I well remember this should be possible (the opposite is not possible
>>> for sure). This would be sufficient to have my +1.
>>>
>>> Best regards,
>>> F.
>>>
>>>  On Tue, Feb 19, 2013 at 10:36 AM, Fabio Martelli
 **wrote:

  Il giorno 19/feb/2013, alle ore 11.28, Colm O hEigeartaigh ha scritto:
>
>  When using the CSVDir 0.7-SNAPSHOT we would be forced to use ConnId
>>> 1.3.3-SNAPSHOT instead of 1.3.2.
>>>
>>>  Is there any reason why we can't just do that on trunk anyway? I
>> assume
>> we're going to release Syncope 1.1 with ConnId 1.3.3 anyway?
>>
> Guys, I'd prefere to keep the 1.3.2 for Syncope 1.1.0.
> Since we are expecting to release soon I'd like to be sure about the
> reliability of the 1.1.0.
>
> Regards,
> F.
>
>  Why not backporting your fix on 0.7-SNAPSHOT to 0.6.1-SNAPSHOT?
>>>
>> I will do.
>>
>> Colm.
>>
>>
>>
>> On Tue, Feb 19, 2013 at 10:25 AM, Francesco Chicchiriccò <
>> ilgro...@apache.org> wrote:
>>
>>  On 19/02/2013 11:13, Colm O hEigeartaigh wrote:
>>>
>>>  Hi all,

 Following the query on the CSV SNAPSHOT in Syncope, just wondering

>>> why
>>>
 are
>
>> we including 0.6.1-SNAPSHOT on trunk instead of 0.7-SNAPSHOT? The

>>> former
>
>> does not include the fixes I made recently (in particular the

>>> properties
>
>> file is in the wrong package name, and so the correct property keys

>>> are
>>>
 not
 displayed in Syncope).

  When using the CSVDir 0.7-SNAPSHOT we would be forced to use ConnId
>>> 1.3.3-SNAPSHOT instead of 1.3.2.
>>>
>>> Why not backporting your fix on 0.7-SNAPSHOT to 0.6.1-SNAPSHOT?
>>>
>>> Regards.
>>>
>>
> --
> Francesco Chicchiriccò
>
> ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
> http://people.apache.org/~**ilgrosso/
>
>


-- 
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

Re: CSV Connector SNAPSHOT version

[Fabio Martelli]

Il giorno 19/feb/2013, alle ore 12.56, Francesco Chicchiriccò ha scritto:

> On 19/02/2013 12:51, Colm O hEigeartaigh wrote:
>>> How about a new branch for the LDAP + DB bundles that I can backport fixes 
>>> to?
>> In terms of the DB Connector first, trunk is at 2.1.5-SNAPSHOT. How about I
>> update trunk to 2.2-SNAPSHOT + create a new branch called "2.1.X" (with
>> version 2.1.5-SNAPSHOT) before the recent revisions were made? I will then
>> selectively merge various fixes. Any objections to this?
> 
> I thought we could avoid this branching if we are able to verify that you can 
> use "old" (e.g. compiled against ConnId 1.3.2) connectors with "new" (e.g. 
> 1.3.3-SNAPSHOT) framework,
Agree with Francesco. I think we can avoid the branch.
> 
> Am I wrong?
> 
> Regards.
> 
>> On Tue, Feb 19, 2013 at 10:56 AM, Fabio Martelli
>> wrote:
>> 
>>> Il giorno 19/feb/2013, alle ore 11.44, Colm O hEigeartaigh ha scritto:
>>> 
> Guys, I'd prefere to keep the 1.3.2 for Syncope 1.1.0.
> Since we are expecting to release soon I'd like to be sure about the
> reliability of the 1.1.0.
 
 Why do you think 1.3.3 would be particularly unreliable? There have not
 been many fixes made from what I can see.
 
 I don't have strong objections to using 1.3.2 for Syncope 1.1, however I
 would like if the fixes I've made make it into Syncope for 1.1. I will
 backport the CSV fixes to the branch. How about a new branch for the
>>> LDAP +
 DB bundles that I can backport fixes to? In particular I would like to
>>> have
 LDAP-2, LDAP-5 and LDAP-6 available in Syncope 1.1.
>>> OK Colm, probably we can do the following.
>>> Since I'd like to maintain the possibility to switch from a newest
>>> connector version  to an old one I'd ask you to verify before the
>>> possibility to run, for example,  CsvDir 0.6.1-SNAPSHOT with the latest
>>> framework version.
>>> If I well remember this should be possible (the opposite is not possible
>>> for sure). This would be sufficient to have my +1.
>>> 
>>> Best regards,
>>> F.
>>> 
 On Tue, Feb 19, 2013 at 10:36 AM, Fabio Martelli
 wrote:
 
> Il giorno 19/feb/2013, alle ore 11.28, Colm O hEigeartaigh ha scritto:
> 
>>> When using the CSVDir 0.7-SNAPSHOT we would be forced to use ConnId
>>> 1.3.3-SNAPSHOT instead of 1.3.2.
>>> 
>> Is there any reason why we can't just do that on trunk anyway? I assume
>> we're going to release Syncope 1.1 with ConnId 1.3.3 anyway?
> Guys, I'd prefere to keep the 1.3.2 for Syncope 1.1.0.
> Since we are expecting to release soon I'd like to be sure about the
> reliability of the 1.1.0.
> 
> Regards,
> F.
> 
>>> Why not backporting your fix on 0.7-SNAPSHOT to 0.6.1-SNAPSHOT?
>> I will do.
>> 
>> Colm.
>> 
>> 
>> 
>> On Tue, Feb 19, 2013 at 10:25 AM, Francesco Chicchiriccò <
>> ilgro...@apache.org> wrote:
>> 
>>> On 19/02/2013 11:13, Colm O hEigeartaigh wrote:
>>> 
 Hi all,
 
 Following the query on the CSV SNAPSHOT in Syncope, just wondering
>>> why
> are
 we including 0.6.1-SNAPSHOT on trunk instead of 0.7-SNAPSHOT? The
> former
 does not include the fixes I made recently (in particular the
> properties
 file is in the wrong package name, and so the correct property keys
>>> are
 not
 displayed in Syncope).
 
>>> When using the CSVDir 0.7-SNAPSHOT we would be forced to use ConnId
>>> 1.3.3-SNAPSHOT instead of 1.3.2.
>>> 
>>> Why not backporting your fix on 0.7-SNAPSHOT to 0.6.1-SNAPSHOT?
>>> 
>>> Regards.
> 
> -- 
> Francesco Chicchiriccò
> 
> ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
> http://people.apache.org/~ilgrosso/
> 

Re: CSV Connector SNAPSHOT version

[Francesco Chicchiriccò]

On 19/02/2013 13:04, Colm O hEigeartaigh wrote:

Hi Francesco,


I thought we could avoid this branching if we are able to verify that you can use "old" 
(e.g. compiled against ConnId 1.3.2) connectors with "new"
(e.g. 1.3.3-SNAPSHOT) framework,


Ok, I guess I misunderstood. I understand that we want to run an "old"
connector with the new framework, and so for example the CSV 0.6.x branch
should be able to run against the 1.3.3-SNAPSHOT framework version.

I don't understand though how we can avoid branching DB + LDAP if we want
to have the fixes I mentioned available in Syncope 1.1?


Given the retro-compatibility feature reported above, if confirmed 
working, I think that we can move Syncope 1.1.0 to ConnId 
1.3.3-SNAPSHOT, thus avoid branching.


Sorry for not having made this re-thinking clear.

Regards.


On Tue, Feb 19, 2013 at 11:56 AM, Francesco Chicchiriccò <
ilgro...@apache.org> wrote:


On 19/02/2013 12:51, Colm O hEigeartaigh wrote:


How about a new branch for the LDAP + DB bundles that I can backport

fixes to?


In terms of the DB Connector first, trunk is at 2.1.5-SNAPSHOT. How about
I
update trunk to 2.2-SNAPSHOT + create a new branch called "2.1.X" (with
version 2.1.5-SNAPSHOT) before the recent revisions were made? I will then
selectively merge various fixes. Any objections to this?


I thought we could avoid this branching if we are able to verify that you
can use "old" (e.g. compiled against ConnId 1.3.2) connectors with "new"
(e.g. 1.3.3-SNAPSHOT) framework,

Am I wrong?

Regards.

  On Tue, Feb 19, 2013 at 10:56 AM, Fabio Martelli

**wrote:

  Il giorno 19/feb/2013, alle ore 11.44, Colm O hEigeartaigh ha scritto:

  Guys, I'd prefere to keep the 1.3.2 for Syncope 1.1.0.

Since we are expecting to release soon I'd like to be sure about the
reliability of the 1.1.0.


Why do you think 1.3.3 would be particularly unreliable? There have not
been many fixes made from what I can see.

I don't have strong objections to using 1.3.2 for Syncope 1.1, however I
would like if the fixes I've made make it into Syncope for 1.1. I will
backport the CSV fixes to the branch. How about a new branch for the


LDAP +


DB bundles that I can backport fixes to? In particular I would like to


have


LDAP-2, LDAP-5 and LDAP-6 available in Syncope 1.1.


OK Colm, probably we can do the following.
Since I'd like to maintain the possibility to switch from a newest
connector version  to an old one I'd ask you to verify before the
possibility to run, for example,  CsvDir 0.6.1-SNAPSHOT with the latest
framework version.
If I well remember this should be possible (the opposite is not possible
for sure). This would be sufficient to have my +1.

Best regards,
F.

  On Tue, Feb 19, 2013 at 10:36 AM, Fabio Martelli

**wrote:

  Il giorno 19/feb/2013, alle ore 11.28, Colm O hEigeartaigh ha scritto:

  When using the CSVDir 0.7-SNAPSHOT we would be forced to use ConnId

1.3.3-SNAPSHOT instead of 1.3.2.

  Is there any reason why we can't just do that on trunk anyway? I

assume
we're going to release Syncope 1.1 with ConnId 1.3.3 anyway?


Guys, I'd prefere to keep the 1.3.2 for Syncope 1.1.0.
Since we are expecting to release soon I'd like to be sure about the
reliability of the 1.1.0.

Regards,
F.

  Why not backporting your fix on 0.7-SNAPSHOT to 0.6.1-SNAPSHOT?

I will do.

Colm.



On Tue, Feb 19, 2013 at 10:25 AM, Francesco Chicchiriccò <
ilgro...@apache.org> wrote:

  On 19/02/2013 11:13, Colm O hEigeartaigh wrote:

  Hi all,

Following the query on the CSV SNAPSHOT in Syncope, just wondering


why

are

we including 0.6.1-SNAPSHOT on trunk instead of 0.7-SNAPSHOT? The

former

does not include the fixes I made recently (in particular the

properties

file is in the wrong package name, and so the correct property keys

are

not

displayed in Syncope).

  When using the CSVDir 0.7-SNAPSHOT we would be forced to use ConnId

1.3.3-SNAPSHOT instead of 1.3.2.

Why not backporting your fix on 0.7-SNAPSHOT to 0.6.1-SNAPSHOT?

Regards.


--
Francesco Chicchiriccò

ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/

Re: LDAP Role queries

[Emmanuel Lécharny]

Le 2/18/13 4:08 PM, Colm O hEigeartaigh a écrit :
>
>>> attribute name, whereas LDAPMembershipSyncActions has "uniquemember". Is
>>> there a reason why it is different in both cases? Shouldn't they also
>>> check
>>> the value of the "groupMemberAttribute" property of the LDAP Connector?
>>
> Could you explain the difference between "ldapGroups" and "uniquemember"
> here? Shouldn't the latter be "uniqueMember"?
Don't use uniqueMemeber. Never. Nine. Niet. Nix.

http://rfc-ref.org/RFC-TEXTS/4519/chapter2.html#d4e443387

This is far from what you expect it to be, and you'll get hard time with some 
Windows identifier having a # in their DN.


-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com 

Extraneous configuration in core main content.xml

[Colm O hEigeartaigh]

Hi all,

Is there any reason 'content.xml' in the Archetype core
(src/main/resources) has a handful of schema type definitions, etc.? I
would have thought it would make more sense to have the most minimal set of
configuration that you can use to set up a Syncope install. Obviously, the
content.xml in src/test/resources can be used to get an idea for how
Syncope can be configured, etc.

Colm.



-- 
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

Re: Extraneous configuration in core main content.xml

[Francesco Chicchiriccò]

On 19/02/2013 14:44, Colm O hEigeartaigh wrote:

Hi all,

Is there any reason 'content.xml' in the Archetype core
(src/main/resources) has a handful of schema type definitions, etc.? I
would have thought it would make more sense to have the most minimal set of
configuration that you can use to set up a Syncope install. Obviously, the
content.xml in src/test/resources can be used to get an idea for how
Syncope can be configured, etc.


I don't see problems in "minimizing" core/src/main/resources/content.xml.

Regards.

--
Francesco Chicchiriccò

ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/

Re: [connid-dev] Re: CSV Connector SNAPSHOT version

[Colm O hEigeartaigh]

> Given the retro-compatibility feature reported above, if confirmed
> working, I think that we can move Syncope 1.1.0 to ConnId 1.3.3-SNAPSHOT,
> thus avoid branching.
>
> Sorry for not having made this re-thinking clear.


Ah, ok got it, thanks.

Colm.

On Tue, Feb 19, 2013 at 12:30 PM, Francesco Chicchiriccò <
ilgro...@apache.org> wrote:

> On 19/02/2013 13:04, Colm O hEigeartaigh wrote:
>
>> Hi Francesco,
>>
>>  I thought we could avoid this branching if we are able to verify that
>>> you can use "old" (e.g. compiled against ConnId 1.3.2) connectors with "new"
>>> (e.g. 1.3.3-SNAPSHOT) framework,
>>>
>>
>> Ok, I guess I misunderstood. I understand that we want to run an "old"
>> connector with the new framework, and so for example the CSV 0.6.x branch
>> should be able to run against the 1.3.3-SNAPSHOT framework version.
>>
>> I don't understand though how we can avoid branching DB + LDAP if we want
>> to have the fixes I mentioned available in Syncope 1.1?
>>
>
> Given the retro-compatibility feature reported above, if confirmed
> working, I think that we can move Syncope 1.1.0 to ConnId 1.3.3-SNAPSHOT,
> thus avoid branching.
>
> Sorry for not having made this re-thinking clear.
>
> Regards.
>
>  On Tue, Feb 19, 2013 at 11:56 AM, Francesco Chicchiriccò <
>> ilgro...@apache.org> wrote:
>>
>>  On 19/02/2013 12:51, Colm O hEigeartaigh wrote:
>>>
>>>  How about a new branch for the LDAP + DB bundles that I can backport

> fixes to?
>
>  In terms of the DB Connector first, trunk is at 2.1.5-SNAPSHOT. How
 about
 I
 update trunk to 2.2-SNAPSHOT + create a new branch called "2.1.X" (with
 version 2.1.5-SNAPSHOT) before the recent revisions were made? I will
 then
 selectively merge various fixes. Any objections to this?

  I thought we could avoid this branching if we are able to verify that
>>> you
>>> can use "old" (e.g. compiled against ConnId 1.3.2) connectors with "new"
>>> (e.g. 1.3.3-SNAPSHOT) framework,
>>>
>>> Am I wrong?
>>>
>>> Regards.
>>>
>>>   On Tue, Feb 19, 2013 at 10:56 AM, Fabio Martelli
>>>
 wrote:


   Il giorno 19/feb/2013, alle ore 11.44, Colm O hEigeartaigh ha scritto:

>   Guys, I'd prefere to keep the 1.3.2 for Syncope 1.1.0.
>
>> Since we are expecting to release soon I'd like to be sure about the
>>> reliability of the 1.1.0.
>>>
>>>  Why do you think 1.3.3 would be particularly unreliable? There have
>> not
>> been many fixes made from what I can see.
>>
>> I don't have strong objections to using 1.3.2 for Syncope 1.1,
>> however I
>> would like if the fixes I've made make it into Syncope for 1.1. I will
>> backport the CSV fixes to the branch. How about a new branch for the
>>
>>  LDAP +
>
>  DB bundles that I can backport fixes to? In particular I would like to
>>
>>  have
>
>  LDAP-2, LDAP-5 and LDAP-6 available in Syncope 1.1.
>>
>>  OK Colm, probably we can do the following.
> Since I'd like to maintain the possibility to switch from a newest
> connector version  to an old one I'd ask you to verify before the
> possibility to run, for example,  CsvDir 0.6.1-SNAPSHOT with the latest
> framework version.
> If I well remember this should be possible (the opposite is not
> possible
> for sure). This would be sufficient to have my +1.
>
> Best regards,
> F.
>
>   On Tue, Feb 19, 2013 at 10:36 AM, Fabio Martelli
>
>> wrote:
>>
>>
>>   Il giorno 19/feb/2013, alle ore 11.28, Colm O hEigeartaigh ha
>> scritto:
>>
>>>   When using the CSVDir 0.7-SNAPSHOT we would be forced to use ConnId
>>>
 1.3.3-SNAPSHOT instead of 1.3.2.
>
>   Is there any reason why we can't just do that on trunk anyway? I
>
 assume
 we're going to release Syncope 1.1 with ConnId 1.3.3 anyway?

  Guys, I'd prefere to keep the 1.3.2 for Syncope 1.1.0.
>>> Since we are expecting to release soon I'd like to be sure about the
>>> reliability of the 1.1.0.
>>>
>>> Regards,
>>> F.
>>>
>>>   Why not backporting your fix on 0.7-SNAPSHOT to 0.6.1-SNAPSHOT?
>>>
 I will do.

 Colm.



 On Tue, Feb 19, 2013 at 10:25 AM, Francesco Chicchiriccò <
 ilgro...@apache.org> wrote:

   On 19/02/2013 11:13, Colm O hEigeartaigh wrote:

>   Hi all,
>
>> Following the query on the CSV SNAPSHOT in Syncope, just wondering
>>
>>  why
>
 are
>>
>>> we including 0.6.1-SNAPSHOT on trunk instead of 0.7-SNAPSHOT? The

> former
>
 does not include the fixes I made recently (in particular the

> properties
>
 file is in the wrong package name, and so the correct property keys

> 

[jira] [Updated] (SYNCOPE-293) Show information (version, license, ...)

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh updated SYNCOPE-293:


Attachment: Screenshot from 2013-02-19 15.png


Here is a SNAPSHOT of the information panel in Firefox. My scenario is a new 
archetype project with version "5.3". Not sure if I am missing something here, 
or if this is a bug that's crept in since this issue was fixed.

Colm.

> Show information (version, license, ...)
> 
>
> Key: SYNCOPE-293
> URL: https://issues.apache.org/jira/browse/SYNCOPE-293
> Project: Syncope
>  Issue Type: Improvement
>  Components: console
>Reporter: Massimiliano Perrone
>Assignee: Massimiliano Perrone
> Fix For: 1.1.0
>
> Attachments: bp.png, infoModalOnChrome.png, infoModalOnFirefox.png, 
> Screenshot from 2013-02-19 15.png, welcomeOnChrome.png, wp.png
>
>
> Currently there is only a static label with core and console versions.
> Add a new Link to open a ModalPage with version and other project information 
> (eg. link to license)

--
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

[jira] [Reopened] (SYNCOPE-293) Show information (version, license, ...)

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh reopened SYNCOPE-293:
-


> Show information (version, license, ...)
> 
>
> Key: SYNCOPE-293
> URL: https://issues.apache.org/jira/browse/SYNCOPE-293
> Project: Syncope
>  Issue Type: Improvement
>  Components: console
>Reporter: Massimiliano Perrone
>Assignee: Massimiliano Perrone
> Fix For: 1.1.0
>
> Attachments: bp.png, infoModalOnChrome.png, infoModalOnFirefox.png, 
> welcomeOnChrome.png, wp.png
>
>
> Currently there is only a static label with core and console versions.
> Add a new Link to open a ModalPage with version and other project information 
> (eg. link to license)

--
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

[jira] [Commented] (SYNCOPE-293) Show information (version, license, ...)

[Massimiliano Perrone (JIRA)]

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

Massimiliano Perrone commented on SYNCOPE-293:
--

Running -Pdev in trunk console the info-panel is ok.
I have the same problem with my overlay 1.1.0-SNAPSHOT.

> Show information (version, license, ...)
> 
>
> Key: SYNCOPE-293
> URL: https://issues.apache.org/jira/browse/SYNCOPE-293
> Project: Syncope
>  Issue Type: Improvement
>  Components: console
>Reporter: Massimiliano Perrone
>Assignee: Massimiliano Perrone
> Fix For: 1.1.0
>
> Attachments: bp.png, infoModalOnChrome.png, infoModalOnFirefox.png, 
> Screenshot from 2013-02-19 15.png, welcomeOnChrome.png, wp.png
>
>
> Currently there is only a static label with core and console versions.
> Add a new Link to open a ModalPage with version and other project information 
> (eg. link to license)

--
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

Re: svn commit: r1447768 - /syncope/trunk/core/src/main/resources/content.xml

[Francesco Chicchiriccò]

These are needed, indeed:

-  
-  
-  
-  


--
Francesco Chicchiriccò

ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/

Re: svn commit: r1447768 - /syncope/trunk/core/src/main/resources/content.xml

[Colm O hEigeartaigh]

Ok can revert - but why are they needed if you are not intending to create
any notification jobs?

Colm.

On Tue, Feb 19, 2013 at 3:43 PM, Francesco Chicchiriccò  wrote:

> These are needed, indeed:
>
> -  
> -  
> -  
> -  
>
> --
> Francesco Chicchiriccò
>
> ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
> http://people.apache.org/~**ilgrosso/
>
>


-- 
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

Re: svn commit: r1447768 - /syncope/trunk/core/src/main/resources/content.xml

[Francesco Chicchiriccò]

On 19/02/2013 16:49, Colm O hEigeartaigh wrote:

Ok can revert - but why are they needed if you are not intending to create
any notification jobs?


The SMTP stuff is needed not only for notifications, it is a general 
conf param.


About notification cron expression, if you remove that comment and 
property, we should be sure to add this information in the wiki page [1].


Regards.

[1] https://cwiki.apache.org/confluence/display/SYNCOPE/Notifications


On Tue, Feb 19, 2013 at 3:43 PM, Francesco Chicchiriccò 
wrote:
These are needed, indeed:

-  
-  
-  
-  


--
Francesco Chicchiriccò

ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/

[jira] [Resolved] (SYNCOPE-257) Schema Mapping for propagation and synchronization

[fabio martelli (JIRA)]

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

fabio martelli resolved SYNCOPE-257.


Resolution: Fixed

> Schema Mapping for propagation and synchronization
> --
>
> Key: SYNCOPE-257
> URL: https://issues.apache.org/jira/browse/SYNCOPE-257
> Project: Syncope
>  Issue Type: Improvement
>  Components: console, core
>Affects Versions: 1.1.0
>Reporter: fabio martelli
>Assignee: fabio martelli
> Fix For: 1.1.0
>
>
> Syncope should give the possibility to specify two different mappings for 
> synchronization and propagation.
> My suggestion is to provide two boolean flags: the former to specify a 
> propagation mapping and the latter to specify a synchronization mapping.
> Of course, each mapping must have a flag to true at least.
> About the administration console, I'd suggest to have all the mappings about 
> the same resource into a single tab. I think that, in this way, mapping 
> configuration would be simple and easy to manage (in terms of troubleshooting 
> as well).

--
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

[jira] [Commented] (SYNCOPE-257) Schema Mapping for propagation and synchronization

[Hudson (JIRA)]

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

Hudson commented on SYNCOPE-257:


Integrated in Syncope-trunk #101 (See 
[https://builds.apache.org/job/Syncope-trunk/101/])
SYNCOPE-257 - makes the solution more robust (Revision 1447819)

 Result = SUCCESS
fmartelli : 
Files : 
* 
/syncope/trunk/console/src/main/java/org/apache/syncope/console/pages/panels/ResourceMappingPanel.java
* 
/syncope/trunk/core/src/main/java/org/apache/syncope/core/persistence/validation/entity/ExternalResourceValidator.java
* 
/syncope/trunk/core/src/test/java/org/apache/syncope/core/persistence/dao/ResourceTest.java


> Schema Mapping for propagation and synchronization
> --
>
> Key: SYNCOPE-257
> URL: https://issues.apache.org/jira/browse/SYNCOPE-257
> Project: Syncope
>  Issue Type: Improvement
>  Components: console, core
>Affects Versions: 1.1.0
>Reporter: fabio martelli
>Assignee: fabio martelli
> Fix For: 1.1.0
>
>
> Syncope should give the possibility to specify two different mappings for 
> synchronization and propagation.
> My suggestion is to provide two boolean flags: the former to specify a 
> propagation mapping and the latter to specify a synchronization mapping.
> Of course, each mapping must have a flag to true at least.
> About the administration console, I'd suggest to have all the mappings about 
> the same resource into a single tab. I think that, in this way, mapping 
> configuration would be simple and easy to manage (in terms of troubleshooting 
> as well).

--
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