[jira] [Updated] (DIRSERVER-2077) Provide tools to migrate the config or the data between releases
[ https://issues.apache.org/jira/browse/DIRSERVER-2077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Smits updated DIRSERVER-2077: Fix Version/s: Upcoming release (was: 2.0.0.AM27) > Provide tools to migrate the config or the data between releases > > > Key: DIRSERVER-2077 > URL: https://issues.apache.org/jira/browse/DIRSERVER-2077 > Project: Directory ApacheDS > Issue Type: Task > Components: tools >Affects Versions: 2.0.0-M20 >Reporter: Emmanuel Lécharny >Priority: Critical > Fix For: Upcoming release > > > We have been lazy in the past, by not provided tools to migrate from one > version to the other, simply because they were milestones. > There are three things we need to migrate : > - configuration > - schemas > - data > for each of those data, we have to provide a tool that helps the migration > from one version to the next one. > Ideally, this should be cumulative : ie, migrating from N to, say, N+3 should > migrate those data from N to N+1, then N+1 to N+2 and finally N+2 to N+3 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
Re: Releases
Vote started! On 17/08/2023 14:27, Shawn McKinney wrote: I will be releasing fortress soon as well but will probably now wait for the api to go first. On Aug 17, 2023, at 4:56 AM, Emmanuel Lécharny wrote: Hi Colm, I was plunging back in the ApacheDS code lately, in order to preoper it for a release. In the mean time, I thnk we are good to go for the LDAP API 2.1.4 release with MINA 2.2.2, I can prepare it this week-end. On 17/08/2023 09:13, Colm O hEigeartaigh wrote: Hi Emmanuel, As the issue with updating the LDAP API in directory-server was fixed with the Mina upgrade, where are we with getting a new LDAP API release done and then releasing Directory? Is there much more that needs to be done? Colm. - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org -- *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE T. +33 (0)4 89 97 36 50 P. +33 (0)6 08 33 32 61 emmanuel.lecha...@busit.com https://www.busit.com/ - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org -- *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE T. +33 (0)4 89 97 36 50 P. +33 (0)6 08 33 32 61 emmanuel.lecha...@busit.com https://www.busit.com/ - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
Re: Releases
I will be releasing fortress soon as well but will probably now wait for the api to go first. > On Aug 17, 2023, at 4:56 AM, Emmanuel Lécharny wrote: > > Hi Colm, > > I was plunging back in the ApacheDS code lately, in order to preoper it for a > release. > > In the mean time, I thnk we are good to go for the LDAP API 2.1.4 release > with MINA 2.2.2, I can prepare it this week-end. > > > On 17/08/2023 09:13, Colm O hEigeartaigh wrote: >> Hi Emmanuel, >> As the issue with updating the LDAP API in directory-server was fixed >> with the Mina upgrade, where are we with getting a new LDAP API >> release done and then releasing Directory? Is there much more that >> needs to be done? >> Colm. >> - >> To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org >> For additional commands, e-mail: dev-h...@directory.apache.org > > -- > *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE > T. +33 (0)4 89 97 36 50 > P. +33 (0)6 08 33 32 61 > emmanuel.lecha...@busit.com https://www.busit.com/ > > - > To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org > For additional commands, e-mail: dev-h...@directory.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
Re: Releases
Hi Colm, I was plunging back in the ApacheDS code lately, in order to preoper it for a release. In the mean time, I thnk we are good to go for the LDAP API 2.1.4 release with MINA 2.2.2, I can prepare it this week-end. On 17/08/2023 09:13, Colm O hEigeartaigh wrote: Hi Emmanuel, As the issue with updating the LDAP API in directory-server was fixed with the Mina upgrade, where are we with getting a new LDAP API release done and then releasing Directory? Is there much more that needs to be done? Colm. - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org -- *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE T. +33 (0)4 89 97 36 50 P. +33 (0)6 08 33 32 61 emmanuel.lecha...@busit.com https://www.busit.com/ - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
Releases
Hi Emmanuel, As the issue with updating the LDAP API in directory-server was fixed with the Mina upgrade, where are we with getting a new LDAP API release done and then releasing Directory? Is there much more that needs to be done? Colm. - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Resolved] (DIRSTUDIO-1271) Oracle OUD 11.1.2.3 does not list any Naming Contexts in ldapbrowser with M16, previous releases are OK.
[ https://issues.apache.org/jira/browse/DIRSTUDIO-1271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seelmann resolved DIRSTUDIO-1271. Resolution: Fixed > Oracle OUD 11.1.2.3 does not list any Naming Contexts in ldapbrowser with > M16, previous releases are OK. > > > Key: DIRSTUDIO-1271 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1271 > Project: Directory Studio > Issue Type: Bug > Components: studio-ldapbrowser >Affects Versions: 2.0.0-M16 > Environment: Windows with Oracle JDK 11 or Graal/JDK11 >Reporter: Mark Davis >Assignee: Stefan Seelmann >Priority: Major > Fix For: 2.0.0-M17 > > > Using M16, and connecting to Oracle OUD 11.1.2.3 shows Root DSE only, and all > contexts underneath are missing. I can see the available namingContexts in > the Root DSE entry. > Release M14 and before are fine. > A fast test with Forgerock/OpenDJ7.0.1 (derived from the same source, but > diverged) is OK. > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
Re: API and Studio releases
Hi Stefan I'll do a quick check to see oif there is no urgent thing to push. On 10/05/2021 18:24, Stefan Seelmann wrote: Hi all, I plan to release the LDAP API [1] and afterwards Studio [2]. Let me know if some urgent fix should be included. Kind Regards, Stefan [1] https://issues.apache.org/jira/issues/?jql=project%20%3D%20DIRAPI%20AND%20fixVersion%20%3D%202.0.2 [2] https://issues.apache.org/jira/issues/?jql=project%20%3D%20DIRSTUDIO%20AND%20fixVersion%20%3D%202.0.0-M17 - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org -- *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE T. +33 (0)4 89 97 36 50 P. +33 (0)6 08 33 32 61 emmanuel.lecha...@busit.com https://www.busit.com/ - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
API and Studio releases
Hi all, I plan to release the LDAP API [1] and afterwards Studio [2]. Let me know if some urgent fix should be included. Kind Regards, Stefan [1] https://issues.apache.org/jira/issues/?jql=project%20%3D%20DIRAPI%20AND%20fixVersion%20%3D%202.0.2 [2] https://issues.apache.org/jira/issues/?jql=project%20%3D%20DIRSTUDIO%20AND%20fixVersion%20%3D%202.0.0-M17 - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Commented] (DIRSTUDIO-1271) Oracle OUD 11.1.2.3 does not list any Naming Contexts in ldapbrowser with M16, previous releases are OK.
[ https://issues.apache.org/jira/browse/DIRSTUDIO-1271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17312378#comment-17312378 ] Mark Davis commented on DIRSTUDIO-1271: --- Hi Stefan, my directory contents are back :) for the Windows client. (I don't update the Linux client due to dependency hell, I still have to support Linux 5/6, etc, hmmm, checking, using the 2013 client ;)) I'll let my client know - as they mentioned it to me. Can the release note be updated for M15/M16 to say OUD can't use ? It'll catch a lot of others out I think. I presume this is all related to removal of the JNDI client starting in M15. Thanks and Regards, /\/\ > Oracle OUD 11.1.2.3 does not list any Naming Contexts in ldapbrowser with > M16, previous releases are OK. > > > Key: DIRSTUDIO-1271 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1271 > Project: Directory Studio > Issue Type: Bug > Components: studio-ldapbrowser >Affects Versions: 2.0.0-M16 > Environment: Windows with Oracle JDK 11 or Graal/JDK11 >Reporter: Mark Davis >Assignee: Stefan Seelmann >Priority: Major > Fix For: 2.0.0-M17 > > > Using M16, and connecting to Oracle OUD 11.1.2.3 shows Root DSE only, and all > contexts underneath are missing. I can see the available namingContexts in > the Root DSE entry. > Release M14 and before are fine. > A fast test with Forgerock/OpenDJ7.0.1 (derived from the same source, but > diverged) is OK. > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Assigned] (DIRSTUDIO-1271) Oracle OUD 11.1.2.3 does not list any Naming Contexts in ldapbrowser with M16, previous releases are OK.
[ https://issues.apache.org/jira/browse/DIRSTUDIO-1271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seelmann reassigned DIRSTUDIO-1271: -- Assignee: Stefan Seelmann > Oracle OUD 11.1.2.3 does not list any Naming Contexts in ldapbrowser with > M16, previous releases are OK. > > > Key: DIRSTUDIO-1271 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1271 > Project: Directory Studio > Issue Type: Bug > Components: studio-ldapbrowser >Affects Versions: 2.0.0-M16 > Environment: Windows with Oracle JDK 11 or Graal/JDK11 >Reporter: Mark Davis >Assignee: Stefan Seelmann >Priority: Major > Fix For: 2.0.0-M17 > > > Using M16, and connecting to Oracle OUD 11.1.2.3 shows Root DSE only, and all > contexts underneath are missing. I can see the available namingContexts in > the Root DSE entry. > Release M14 and before are fine. > A fast test with Forgerock/OpenDJ7.0.1 (derived from the same source, but > diverged) is OK. > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Updated] (DIRSTUDIO-1271) Oracle OUD 11.1.2.3 does not list any Naming Contexts in ldapbrowser with M16, previous releases are OK.
[ https://issues.apache.org/jira/browse/DIRSTUDIO-1271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seelmann updated DIRSTUDIO-1271: --- Fix Version/s: 2.0.0-M17 > Oracle OUD 11.1.2.3 does not list any Naming Contexts in ldapbrowser with > M16, previous releases are OK. > > > Key: DIRSTUDIO-1271 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1271 > Project: Directory Studio > Issue Type: Bug > Components: studio-ldapbrowser >Affects Versions: 2.0.0-M16 > Environment: Windows with Oracle JDK 11 or Graal/JDK11 >Reporter: Mark Davis >Priority: Major > Fix For: 2.0.0-M17 > > > Using M16, and connecting to Oracle OUD 11.1.2.3 shows Root DSE only, and all > contexts underneath are missing. I can see the available namingContexts in > the Root DSE entry. > Release M14 and before are fine. > A fast test with Forgerock/OpenDJ7.0.1 (derived from the same source, but > diverged) is OK. > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Commented] (DIRSTUDIO-1271) Oracle OUD 11.1.2.3 does not list any Naming Contexts in ldapbrowser with M16, previous releases are OK.
[ https://issues.apache.org/jira/browse/DIRSTUDIO-1271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17312173#comment-17312173 ] Stefan Seelmann commented on DIRSTUDIO-1271: I integrated the LDAP-API change into Studio master. If you want you can try a snapshot build from https://ci-builds.apache.org/job/Directory/job/dir-studio-pipeline/ (no official release, no guarantee it works). > Oracle OUD 11.1.2.3 does not list any Naming Contexts in ldapbrowser with > M16, previous releases are OK. > > > Key: DIRSTUDIO-1271 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1271 > Project: Directory Studio > Issue Type: Bug > Components: studio-ldapbrowser >Affects Versions: 2.0.0-M16 > Environment: Windows with Oracle JDK 11 or Graal/JDK11 >Reporter: Mark Davis >Priority: Major > > Using M16, and connecting to Oracle OUD 11.1.2.3 shows Root DSE only, and all > contexts underneath are missing. I can see the available namingContexts in > the Root DSE entry. > Release M14 and before are fine. > A fast test with Forgerock/OpenDJ7.0.1 (derived from the same source, but > diverged) is OK. > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Commented] (DIRSTUDIO-1271) Oracle OUD 11.1.2.3 does not list any Naming Contexts in ldapbrowser with M16, previous releases are OK.
[ https://issues.apache.org/jira/browse/DIRSTUDIO-1271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17310700#comment-17310700 ] Stefan Seelmann commented on DIRSTUDIO-1271: Thanks for the error, it remembered me that a similar bug was reported recently: https://issues.apache.org/jira/browse/DIRAPI-366 > Oracle OUD 11.1.2.3 does not list any Naming Contexts in ldapbrowser with > M16, previous releases are OK. > > > Key: DIRSTUDIO-1271 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1271 > Project: Directory Studio > Issue Type: Bug > Components: studio-ldapbrowser >Affects Versions: 2.0.0-M16 > Environment: Windows with Oracle JDK 11 or Graal/JDK11 >Reporter: Mark Davis >Priority: Major > > Using M16, and connecting to Oracle OUD 11.1.2.3 shows Root DSE only, and all > contexts underneath are missing. I can see the available namingContexts in > the Root DSE entry. > Release M14 and before are fine. > A fast test with Forgerock/OpenDJ7.0.1 (derived from the same source, but > diverged) is OK. > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Commented] (DIRSTUDIO-1271) Oracle OUD 11.1.2.3 does not list any Naming Contexts in ldapbrowser with M16, previous releases are OK.
.process(AbstractPollingIoProcessor.java:1211) at org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run(AbstractPollingIoProcessor.java:683) at org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748) Caused by: java.lang.NullPointerException at org.apache.directory.api.ldap.codec.actions.controls.StoreControlValue.action(StoreControlValue.java:81) at org.apache.directory.api.ldap.codec.actions.controls.StoreControlValue.action(StoreControlValue.java:49) at org.apache.directory.api.asn1.ber.grammar.AbstractGrammar.executeAction(AbstractGrammar.java:136) at org.apache.directory.api.asn1.ber.Asn1Decoder.treatTLVDoneState(Asn1Decoder.java:604) at org.apache.directory.api.asn1.ber.Asn1Decoder.decode(Asn1Decoder.java:740) at org.apache.directory.api.ldap.codec.protocol.mina.LdapProtocolDecoder.decode(LdapProtocolDecoder.java:137) at org.apache.directory.api.ldap.codec.protocol.mina.LdapProtocolDecoder.decode(LdapProtocolDecoder.java:86) at org.apache.mina.filter.codec.ProtocolCodecFilter.messageReceived(ProtocolCodecFilter.java:254) ... 15 more > Oracle OUD 11.1.2.3 does not list any Naming Contexts in ldapbrowser with > M16, previous releases are OK. > > > Key: DIRSTUDIO-1271 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1271 > Project: Directory Studio > Issue Type: Bug > Components: studio-ldapbrowser >Affects Versions: 2.0.0-M16 > Environment: Windows with Oracle JDK 11 or Graal/JDK11 >Reporter: Mark Davis >Priority: Major > > Using M16, and connecting to Oracle OUD 11.1.2.3 shows Root DSE only, and all > contexts underneath are missing. I can see the available namingContexts in > the Root DSE entry. > Release M14 and before are fine. > A fast test with Forgerock/OpenDJ7.0.1 (derived from the same source, but > diverged) is OK. > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Commented] (DIRSTUDIO-1271) Oracle OUD 11.1.2.3 does not list any Naming Contexts in ldapbrowser with M16, previous releases are OK.
[ https://issues.apache.org/jira/browse/DIRSTUDIO-1271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17309906#comment-17309906 ] Stefan Seelmann commented on DIRSTUDIO-1271: Can you please check the "Search Logs" if it attempts to fetch the contexts, which search parameters are used, and if the entries are returned by the server? [1] Is it possible to fetch and set the base DN in the connection properties browser options [2]? Is it possible that I can access that server to debug the problem? Or is there a public server available for testing? [1] https://nightlies.apache.org/directory/studio/2.0.0.v20210213-M16/userguide/ldap_browser/tools_search_logs_view.html [2] https://nightlies.apache.org/directory/studio/2.0.0.v20210213-M16/userguide/ldap_browser/tools_connection_properties.html#tools_connection_properties_browser_options > Oracle OUD 11.1.2.3 does not list any Naming Contexts in ldapbrowser with > M16, previous releases are OK. > > > Key: DIRSTUDIO-1271 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1271 > Project: Directory Studio > Issue Type: Bug > Components: studio-ldapbrowser >Affects Versions: 2.0.0-M16 > Environment: Windows with Oracle JDK 11 or Graal/JDK11 >Reporter: Mark Davis >Priority: Major > > Using M16, and connecting to Oracle OUD 11.1.2.3 shows Root DSE only, and all > contexts underneath are missing. I can see the available namingContexts in > the Root DSE entry. > Release M14 and before are fine. > A fast test with Forgerock/OpenDJ7.0.1 (derived from the same source, but > diverged) is OK. > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Created] (DIRSTUDIO-1271) Oracle OUD 11.1.2.3 does not list any Naming Contexts in ldapbrowser with M16, previous releases are OK.
Mark Davis created DIRSTUDIO-1271: - Summary: Oracle OUD 11.1.2.3 does not list any Naming Contexts in ldapbrowser with M16, previous releases are OK. Key: DIRSTUDIO-1271 URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1271 Project: Directory Studio Issue Type: Bug Components: studio-ldapbrowser Affects Versions: 2.0.0-M16 Environment: Windows with Oracle JDK 11 or Graal/JDK11 Reporter: Mark Davis Using M16, and connecting to Oracle OUD 11.1.2.3 shows Root DSE only, and all contexts underneath are missing. I can see the available namingContexts in the Root DSE entry. Release M14 and before are fine. A fast test with Forgerock/OpenDJ7.0.1 (derived from the same source, but diverged) is OK. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Updated] (DIRSERVER-2077) Provide tools to migrate the config or the data between releases
[ https://issues.apache.org/jira/browse/DIRSERVER-2077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lécharny updated DIRSERVER-2077: - Fix Version/s: (was: 2.0.0.AM26) 2.0.0.AM27 > Provide tools to migrate the config or the data between releases > > > Key: DIRSERVER-2077 > URL: https://issues.apache.org/jira/browse/DIRSERVER-2077 > Project: Directory ApacheDS > Issue Type: Task > Components: tools >Affects Versions: 2.0.0-M20 >Reporter: Emmanuel Lécharny >Priority: Critical > Fix For: 2.0.0.AM27 > > > We have been lazy in the past, by not provided tools to migrate from one > version to the other, simply because they were milestones. > There are three things we need to migrate : > - configuration > - schemas > - data > for each of those data, we have to provide a tool that helps the migration > from one version to the next one. > Ideally, this should be cumulative : ie, migrating from N to, say, N+3 should > migrate those data from N to N+1, then N+1 to N+2 and finally N+2 to N+3 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
Re: New releases?
Ok, I'm starting the release (I hope I have enough network bandwith :-) Releasing during a LDAP conference: pricelss ! On 05/11/2019 11:30, Shawn McKinney wrote: Sounds good, go for it. (+1) — Shawn On Nov 5, 2019, at 10:03 AM, Emmanuel Lécharny wrote: I can start a new release of LDAP API today. On 04/11/2019 11:54, Colm O hEigeartaigh wrote: Where do we stand on new releases? There have been quite a few fixes in the API that could be released: https://github.com/apache/directory-ldap-api/compare/2.0.0.AM4...master Colm. - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
Re: New releases?
Sounds good, go for it. (+1) — Shawn > On Nov 5, 2019, at 10:03 AM, Emmanuel Lécharny wrote: > > I can start a new release of LDAP API today. > > > On 04/11/2019 11:54, Colm O hEigeartaigh wrote: >> Where do we stand on new releases? There have been quite a few fixes in the >> API that could be released: >> >> https://github.com/apache/directory-ldap-api/compare/2.0.0.AM4...master >> >> Colm. > > - > To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org > For additional commands, e-mail: dev-h...@directory.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
Re: New releases?
I can start a new release of LDAP API today. On 04/11/2019 11:54, Colm O hEigeartaigh wrote: Where do we stand on new releases? There have been quite a few fixes in the API that could be released: https://github.com/apache/directory-ldap-api/compare/2.0.0.AM4...master Colm. - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
New releases?
Where do we stand on new releases? There have been quite a few fixes in the API that could be released: https://github.com/apache/directory-ldap-api/compare/2.0.0.AM4...master Colm.
[jira] [Updated] (DIRSERVER-2077) Provide tools to migrate the config or the data between releases
[ https://issues.apache.org/jira/browse/DIRSERVER-2077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny updated DIRSERVER-2077: - Component/s: tools > Provide tools to migrate the config or the data between releases > > > Key: DIRSERVER-2077 > URL: https://issues.apache.org/jira/browse/DIRSERVER-2077 > Project: Directory ApacheDS > Issue Type: Task > Components: tools >Affects Versions: 2.0.0-M20 >Reporter: Emmanuel Lecharny >Priority: Critical > Fix For: 2.0.0.AM26 > > > We have been lazy in the past, by not provided tools to migrate from one > version to the other, simply because they were milestones. > There are three things we need to migrate : > - configuration > - schemas > - data > for each of those data, we have to provide a tool that helps the migration > from one version to the next one. > Ideally, this should be cumulative : ie, migrating from N to, say, N+3 should > migrate those data from N to N+1, then N+1 to N+2 and finally N+2 to N+3 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
Re: Releases...
Le 30/08/2018 à 21:58, Stefan Seelmann a écrit : > On 08/28/2018 12:33 PM, Emmanuel Lécharny wrote: >> Hi ! >> >> it seems like we need a few releases. Studio is being brewed, so is >> Fortress. The Apache LDAP API and ApacheDS have been released a week or >> so ago. Some performance issue have been found in Studio that are caused >> by some bad code in the LDAP API, and that means we need to cut a new >> release. >> >> So I'm going to cut a LDAP API release tonite, followed by a release of >> ApacheDS. That will allow Studio to use those releases. Fortress has >> some failing tests with the API, which will be investigated. > > FYI, release of ApacheDS is not required, we can just update the LDAP > API in Studio. yes, I intend to wait a bit for ApacheDS, like when the txn part is available. Might be a matter of weeks. The LDAP API is out, I'm waiting for the vote to end. -- Emmanuel Lecharny Symas.com directory.apache.org pEpkey.asc Description: application/pgp-keys
Re: Releases...
On 08/28/2018 12:33 PM, Emmanuel Lécharny wrote: > Hi ! > > it seems like we need a few releases. Studio is being brewed, so is > Fortress. The Apache LDAP API and ApacheDS have been released a week or > so ago. Some performance issue have been found in Studio that are caused > by some bad code in the LDAP API, and that means we need to cut a new > release. > > So I'm going to cut a LDAP API release tonite, followed by a release of > ApacheDS. That will allow Studio to use those releases. Fortress has > some failing tests with the API, which will be investigated. FYI, release of ApacheDS is not required, we can just update the LDAP API in Studio. > All in all, Studio startup will be way faster when you have many > connections (down from 30 seconds down to 7 seconds with 100 connections). > > Anyway, I have released a parent project this morning, and the release > of the LDAP API and ApacheDS will come soon. > > Thanks ! >
Releases...
Hi ! it seems like we need a few releases. Studio is being brewed, so is Fortress. The Apache LDAP API and ApacheDS have been released a week or so ago. Some performance issue have been found in Studio that are caused by some bad code in the LDAP API, and that means we need to cut a new release. So I'm going to cut a LDAP API release tonite, followed by a release of ApacheDS. That will allow Studio to use those releases. Fortress has some failing tests with the API, which will be investigated. All in all, Studio startup will be way faster when you have many connections (down from 30 seconds down to 7 seconds with 100 connections). Anyway, I have released a parent project this morning, and the release of the LDAP API and ApacheDS will come soon. Thanks ! -- Emmanuel Lecharny Symas.com directory.apache.org pEpkey.asc Description: application/pgp-keys
[jira] [Updated] (DIRSERVER-2077) Provide tools to migrate the config or the data between releases
[ https://issues.apache.org/jira/browse/DIRSERVER-2077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny updated DIRSERVER-2077: - Fix Version/s: (was: 2.0.0.AM25) 2.0.0.AM26 > Provide tools to migrate the config or the data between releases > > > Key: DIRSERVER-2077 > URL: https://issues.apache.org/jira/browse/DIRSERVER-2077 > Project: Directory ApacheDS > Issue Type: Task >Affects Versions: 2.0.0-M20 >Reporter: Emmanuel Lecharny >Priority: Critical > Fix For: 2.0.0.AM26 > > > We have been lazy in the past, by not provided tools to migrate from one > version to the other, simply because they were milestones. > There are three things we need to migrate : > - configuration > - schemas > - data > for each of those data, we have to provide a tool that helps the migration > from one version to the next one. > Ideally, this should be cumulative : ie, migrating from N to, say, N+3 should > migrate those data from N to N+1, then N+1 to N+2 and finally N+2 to N+3 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (DIRSERVER-2077) Provide tools to migrate the config or the data between releases
[ https://issues.apache.org/jira/browse/DIRSERVER-2077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny updated DIRSERVER-2077: - Fix Version/s: (was: 2.0.0-M24) 2.0.0-M25 > Provide tools to migrate the config or the data between releases > > > Key: DIRSERVER-2077 > URL: https://issues.apache.org/jira/browse/DIRSERVER-2077 > Project: Directory ApacheDS > Issue Type: Task >Affects Versions: 2.0.0-M20 >Reporter: Emmanuel Lecharny >Priority: Critical > Fix For: 2.0.0-M25 > > > We have been lazy in the past, by not provided tools to migrate from one > version to the other, simply because they were milestones. > There are three things we need to migrate : > - configuration > - schemas > - data > for each of those data, we have to provide a tool that helps the migration > from one version to the next one. > Ideally, this should be cumulative : ie, migrating from N to, say, N+3 should > migrate those data from N to N+1, then N+1 to N+2 and finally N+2 to N+3 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (DIRSERVER-2077) Provide tools to migrate the config or the data between releases
[ https://issues.apache.org/jira/browse/DIRSERVER-2077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16147502#comment-16147502 ] Emmanuel Lecharny commented on DIRSERVER-2077: -- And here is teh fix in the branch : http://svn.apache.org/viewvc?rev=1806703=rev > Provide tools to migrate the config or the data between releases > > > Key: DIRSERVER-2077 > URL: https://issues.apache.org/jira/browse/DIRSERVER-2077 > Project: Directory ApacheDS > Issue Type: Task >Affects Versions: 2.0.0-M20 >Reporter: Emmanuel Lecharny >Priority: Critical > Fix For: 2.0.0-M24 > > > We have been lazy in the past, by not provided tools to migrate from one > version to the other, simply because they were milestones. > There are three things we need to migrate : > - configuration > - schemas > - data > for each of those data, we have to provide a tool that helps the migration > from one version to the next one. > Ideally, this should be cumulative : ie, migrating from N to, say, N+3 should > migrate those data from N to N+1, then N+1 to N+2 and finally N+2 to N+3 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (DIRSERVER-2077) Provide tools to migrate the config or the data between releases
[
https://issues.apache.org/jira/browse/DIRSERVER-2077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16147327#comment-16147327
]
Emmanuel Lecharny commented on DIRSERVER-2077:
--
As usual, some more problem : the {{ConfigPartitionReader}} class does not like
empty attributes. Fix on its way.
> Provide tools to migrate the config or the data between releases
>
>
> Key: DIRSERVER-2077
> URL: https://issues.apache.org/jira/browse/DIRSERVER-2077
> Project: Directory ApacheDS
> Issue Type: Task
>Affects Versions: 2.0.0-M20
>Reporter: Emmanuel Lecharny
>Priority: Critical
> Fix For: 2.0.0-M24
>
>
> We have been lazy in the past, by not provided tools to migrate from one
> version to the other, simply because they were milestones.
> There are three things we need to migrate :
> - configuration
> - schemas
> - data
> for each of those data, we have to provide a tool that helps the migration
> from one version to the next one.
> Ideally, this should be cumulative : ie, migrating from N to, say, N+3 should
> migrate those data from N to N+1, then N+1 to N+2 and finally N+2 to N+3
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (DIRSERVER-2077) Provide tools to migrate the config or the data between releases
[
https://issues.apache.org/jira/browse/DIRSERVER-2077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16147265#comment-16147265
]
Emmanuel Lecharny commented on DIRSERVER-2077:
--
Ok, problem fixed : the {{LdifReader}} was correctly fixed but in the case of
an empty human readable attribute (like {{ads-baseDn}}), we were trying to
store a {{byte[]}} instead of {{""}} in the attribute, which led to a
(silentely ignored) error.
I fixed that with {{commit 1c8afb1c011d6dc16e1d2ab369cd70d49d49}} and
{{commit d81e587885309f1f5b5e5efbf30220e8c7c61b1d} for the previous fix.
It's still in a branch, I need more tests before moving those fixes to trunk.
> Provide tools to migrate the config or the data between releases
>
>
> Key: DIRSERVER-2077
> URL: https://issues.apache.org/jira/browse/DIRSERVER-2077
> Project: Directory ApacheDS
> Issue Type: Task
>Affects Versions: 2.0.0-M20
>Reporter: Emmanuel Lecharny
>Priority: Critical
> Fix For: 2.0.0-M24
>
>
> We have been lazy in the past, by not provided tools to migrate from one
> version to the other, simply because they were milestones.
> There are three things we need to migrate :
> - configuration
> - schemas
> - data
> for each of those data, we have to provide a tool that helps the migration
> from one version to the next one.
> Ideally, this should be cumulative : ie, migrating from N to, say, N+3 should
> migrate those data from N to N+1, then N+1 to N+2 and finally N+2 to N+3
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (DIRSERVER-2077) Provide tools to migrate the config or the data between releases
[
https://issues.apache.org/jira/browse/DIRSERVER-2077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16147265#comment-16147265
]
Emmanuel Lecharny edited comment on DIRSERVER-2077 at 8/30/17 2:00 PM:
---
Ok, problem fixed : the {{LdifReader}} was correctly fixed but in the case of
an empty human readable attribute (like {{ads-baseDn}}), we were trying to
store a {{byte[]}} instead of {{""}} in the attribute, which led to a
(silentely ignored) error.
I fixed that with {{commit 1c8afb1c011d6dc16e1d2ab369cd70d49d49}} and
{{commit d81e587885309f1f5b5e5efbf30220e8c7c61b1d}} for the previous fix.
It's still in a branch, I need more tests before moving those fixes to trunk.
was (Author: elecharny):
Ok, problem fixed : the {{LdifReader}} was correctly fixed but in the case of
an empty human readable attribute (like {{ads-baseDn}}), we were trying to
store a {{byte[]}} instead of {{""}} in the attribute, which led to a
(silentely ignored) error.
I fixed that with {{commit 1c8afb1c011d6dc16e1d2ab369cd70d49d49}} and
{{commit d81e587885309f1f5b5e5efbf30220e8c7c61b1d} for the previous fix.
It's still in a branch, I need more tests before moving those fixes to trunk.
> Provide tools to migrate the config or the data between releases
>
>
> Key: DIRSERVER-2077
> URL: https://issues.apache.org/jira/browse/DIRSERVER-2077
> Project: Directory ApacheDS
> Issue Type: Task
>Affects Versions: 2.0.0-M20
>Reporter: Emmanuel Lecharny
>Priority: Critical
> Fix For: 2.0.0-M24
>
>
> We have been lazy in the past, by not provided tools to migrate from one
> version to the other, simply because they were milestones.
> There are three things we need to migrate :
> - configuration
> - schemas
> - data
> for each of those data, we have to provide a tool that helps the migration
> from one version to the next one.
> Ideally, this should be cumulative : ie, migrating from N to, say, N+3 should
> migrate those data from N to N+1, then N+1 to N+2 and finally N+2 to N+3
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (DIRSERVER-2077) Provide tools to migrate the config or the data between releases
[
https://issues.apache.org/jira/browse/DIRSERVER-2077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16147132#comment-16147132
]
Emmanuel Lecharny commented on DIRSERVER-2077:
--
Rahhh... {{ads-baseDn}} is a {{MUST}} attributeType, it can't be optional.
> Provide tools to migrate the config or the data between releases
>
>
> Key: DIRSERVER-2077
> URL: https://issues.apache.org/jira/browse/DIRSERVER-2077
> Project: Directory ApacheDS
> Issue Type: Task
>Affects Versions: 2.0.0-M20
>Reporter: Emmanuel Lecharny
>Priority: Critical
> Fix For: 2.0.0-M24
>
>
> We have been lazy in the past, by not provided tools to migrate from one
> version to the other, simply because they were milestones.
> There are three things we need to migrate :
> - configuration
> - schemas
> - data
> for each of those data, we have to provide a tool that helps the migration
> from one version to the next one.
> Ideally, this should be cumulative : ie, migrating from N to, say, N+3 should
> migrate those data from N to N+1, then N+1 to N+2 and finally N+2 to N+3
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (DIRSERVER-2077) Provide tools to migrate the config or the data between releases
[
https://issues.apache.org/jira/browse/DIRSERVER-2077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16139184#comment-16139184
]
Emmanuel Lecharny commented on DIRSERVER-2077:
--
Incidentally, it's also a bug in the server, as teh {{ads-baseDn}} is
considered as mandatory (ie, not null) when it can be. Fixed in a branch, still
have to back port it in trunk.
> Provide tools to migrate the config or the data between releases
>
>
> Key: DIRSERVER-2077
> URL: https://issues.apache.org/jira/browse/DIRSERVER-2077
> Project: Directory ApacheDS
> Issue Type: Task
>Affects Versions: 2.0.0-M20
>Reporter: Emmanuel Lecharny
>Priority: Critical
> Fix For: 2.0.0-M24
>
>
> We have been lazy in the past, by not provided tools to migrate from one
> version to the other, simply because they were milestones.
> There are three things we need to migrate :
> - configuration
> - schemas
> - data
> for each of those data, we have to provide a tool that helps the migration
> from one version to the next one.
> Ideally, this should be cumulative : ie, migrating from N to, say, N+3 should
> migrate those data from N to N+1, then N+1 to N+2 and finally N+2 to N+3
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (DIRSERVER-2077) Provide tools to migrate the config or the data between releases
[ https://issues.apache.org/jira/browse/DIRSERVER-2077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16138442#comment-16138442 ] Emmanuel Lecharny commented on DIRSERVER-2077: -- I think I have a fix for this error. Will need to run the tests to see if it's not breaking anything, and I also have to add unit tests for some other corner cases. Note that the bug is in the LDAP API, not in the server, so I will open a JIRA on this project and close this one. > Provide tools to migrate the config or the data between releases > > > Key: DIRSERVER-2077 > URL: https://issues.apache.org/jira/browse/DIRSERVER-2077 > Project: Directory ApacheDS > Issue Type: Task >Affects Versions: 2.0.0-M20 >Reporter: Emmanuel Lecharny >Priority: Critical > Fix For: 2.0.0-M24 > > > We have been lazy in the past, by not provided tools to migrate from one > version to the other, simply because they were milestones. > There are three things we need to migrate : > - configuration > - schemas > - data > for each of those data, we have to provide a tool that helps the migration > from one version to the next one. > Ideally, this should be cumulative : ie, migrating from N to, say, N+3 should > migrate those data from N to N+1, then N+1 to N+2 and finally N+2 to N+3 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (DIRSERVER-2077) Provide tools to migrate the config or the data between releases
[
https://issues.apache.org/jira/browse/DIRSERVER-2077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16138047#comment-16138047
]
Emmanuel Lecharny commented on DIRSERVER-2077:
--
I concur.
The LDIF spec ([http://www.faqs.org/rfcs/rfc2849.html]) is pretty clear :
{noformat}
ldif-file= ldif-content / ldif-changes
ldif-content = version-spec 1*(1*SEP ldif-attrval-record)
ldif-attrval-record = dn-spec SEP 1*attrval-spec
attrval-spec = AttributeDescription value-spec SEP
value-spec = ":" (FILL 0*1(SAFE-STRING) / ":" FILL
(BASE64-STRING) / "<" FILL url)
FILL = *SPACE
SAFE-STRING = [SAFE-INIT-CHAR *SAFE-CHAR]
SAFE-INIT-CHAR = %x01-09 / %x0B-0C / %x0E-1F / %x21-39 / %x3B /
%x3D-7F
{noformat}
Which means something like {{ads-baseDn:}} is for a null value stored in
{{ads-baseDn}} (which is legit : {{rootDSE}}, for instance, {{ads-baseDN: }}
(with an ending space) is for the exact same thing as the leading space will be
taken for the {{FILL}} part of the LDIF grammar. So basically, they are
encoding for the same value, and if the ldif parser does not see them as the
same value, then it's a big bug.
> Provide tools to migrate the config or the data between releases
>
>
> Key: DIRSERVER-2077
> URL: https://issues.apache.org/jira/browse/DIRSERVER-2077
> Project: Directory ApacheDS
> Issue Type: Task
>Affects Versions: 2.0.0-M20
>Reporter: Emmanuel Lecharny
>Priority: Critical
> Fix For: 2.0.0-M24
>
>
> We have been lazy in the past, by not provided tools to migrate from one
> version to the other, simply because they were milestones.
> There are three things we need to migrate :
> - configuration
> - schemas
> - data
> for each of those data, we have to provide a tool that helps the migration
> from one version to the next one.
> Ideally, this should be cumulative : ie, migrating from N to, say, N+3 should
> migrate those data from N to N+1, then N+1 to N+2 and finally N+2 to N+3
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (DIRSERVER-2077) Provide tools to migrate the config or the data between releases
[
https://issues.apache.org/jira/browse/DIRSERVER-2077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16138047#comment-16138047
]
Emmanuel Lecharny edited comment on DIRSERVER-2077 at 8/23/17 8:10 AM:
---
I concur.
The LDIF spec ([http://www.faqs.org/rfcs/rfc2849.html]) is pretty clear :
{noformat}
ldif-file= ldif-content / ldif-changes
ldif-content = version-spec 1*(1*SEP ldif-attrval-record)
ldif-attrval-record = dn-spec SEP 1*attrval-spec
attrval-spec = AttributeDescription value-spec SEP
value-spec = ":" (FILL 0*1(SAFE-STRING) / ":" FILL
(BASE64-STRING) / "<" FILL url)
FILL = *SPACE
SAFE-STRING = [SAFE-INIT-CHAR *SAFE-CHAR]
SAFE-INIT-CHAR = %x01-09 / %x0B-0C / %x0E-1F / %x21-39 / %x3B /
%x3D-7F
{noformat}
Which means something like {{ads-baseDn:}} is for a null value stored in
{{ads-baseDn}} (which is legit : {{rootDSE}}), for instance, {{ads-baseDN: }}
(with an ending space) is for the exact same thing as the leading space will be
taken for the {{FILL}} part of the LDIF grammar. So basically, they are
encoding for the same value, and if the ldif parser does not see them as the
same value, then it's a big bug.
was (Author: elecharny):
I concur.
The LDIF spec ([http://www.faqs.org/rfcs/rfc2849.html]) is pretty clear :
{noformat}
ldif-file= ldif-content / ldif-changes
ldif-content = version-spec 1*(1*SEP ldif-attrval-record)
ldif-attrval-record = dn-spec SEP 1*attrval-spec
attrval-spec = AttributeDescription value-spec SEP
value-spec = ":" (FILL 0*1(SAFE-STRING) / ":" FILL
(BASE64-STRING) / "<" FILL url)
FILL = *SPACE
SAFE-STRING = [SAFE-INIT-CHAR *SAFE-CHAR]
SAFE-INIT-CHAR = %x01-09 / %x0B-0C / %x0E-1F / %x21-39 / %x3B /
%x3D-7F
{noformat}
Which means something like {{ads-baseDn:}} is for a null value stored in
{{ads-baseDn}} (which is legit : {{rootDSE}}, for instance, {{ads-baseDN: }}
(with an ending space) is for the exact same thing as the leading space will be
taken for the {{FILL}} part of the LDIF grammar. So basically, they are
encoding for the same value, and if the ldif parser does not see them as the
same value, then it's a big bug.
> Provide tools to migrate the config or the data between releases
>
>
> Key: DIRSERVER-2077
> URL: https://issues.apache.org/jira/browse/DIRSERVER-2077
> Project: Directory ApacheDS
> Issue Type: Task
>Affects Versions: 2.0.0-M20
>Reporter: Emmanuel Lecharny
>Priority: Critical
> Fix For: 2.0.0-M24
>
>
> We have been lazy in the past, by not provided tools to migrate from one
> version to the other, simply because they were milestones.
> There are three things we need to migrate :
> - configuration
> - schemas
> - data
> for each of those data, we have to provide a tool that helps the migration
> from one version to the next one.
> Ideally, this should be cumulative : ie, migrating from N to, say, N+3 should
> migrate those data from N to N+1, then N+1 to N+2 and finally N+2 to N+3
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (DIRSERVER-2077) Provide tools to migrate the config or the data between releases
[
https://issues.apache.org/jira/browse/DIRSERVER-2077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16138047#comment-16138047
]
Emmanuel Lecharny edited comment on DIRSERVER-2077 at 8/23/17 8:10 AM:
---
I concur.
The LDIF spec ([http://www.faqs.org/rfcs/rfc2849.html]) is pretty clear :
{noformat}
ldif-file= ldif-content / ldif-changes
ldif-content = version-spec 1*(1*SEP ldif-attrval-record)
ldif-attrval-record = dn-spec SEP 1*attrval-spec
attrval-spec = AttributeDescription value-spec SEP
value-spec = ":" (FILL 0*1(SAFE-STRING) / ":" FILL
(BASE64-STRING) / "<" FILL url)
FILL = *SPACE
SAFE-STRING = [SAFE-INIT-CHAR *SAFE-CHAR]
SAFE-INIT-CHAR = %x01-09 / %x0B-0C / %x0E-1F / %x21-39 / %x3B /
%x3D-7F
{noformat}
Which means something like {{ads-baseDn:}} is for a null value stored in
{{ads-baseDn}} (which is legit : {{rootDSE}}), for instance, {{ads-baseDN: }}
(with an ending space) is for the exact same thing as the leading space will be
taken for the {{FILL}} part of the LDIF grammar. So basically, they are
encoding for the same value, and if the ldif parser does not see them as the
same value, then it's a big bug.
was (Author: elecharny):
I concur.
The LDIF spec ([http://www.faqs.org/rfcs/rfc2849.html]) is pretty clear :
{noformat}
ldif-file= ldif-content / ldif-changes
ldif-content = version-spec 1*(1*SEP ldif-attrval-record)
ldif-attrval-record = dn-spec SEP 1*attrval-spec
attrval-spec = AttributeDescription value-spec SEP
value-spec = ":" (FILL 0*1(SAFE-STRING) / ":" FILL
(BASE64-STRING) / "<" FILL url)
FILL = *SPACE
SAFE-STRING = [SAFE-INIT-CHAR *SAFE-CHAR]
SAFE-INIT-CHAR = %x01-09 / %x0B-0C / %x0E-1F / %x21-39 / %x3B /
%x3D-7F
{noformat}
Which means something like {{ads-baseDn:}} is for a null value stored in
{{ads-baseDn}} (which is legit : {{rootDSE}}), for instance, {{ads-baseDN: }}
(with an ending space) is for the exact same thing as the leading space will be
taken for the {{FILL}} part of the LDIF grammar. So basically, they are
encoding for the same value, and if the ldif parser does not see them as the
same value, then it's a big bug.
> Provide tools to migrate the config or the data between releases
>
>
> Key: DIRSERVER-2077
> URL: https://issues.apache.org/jira/browse/DIRSERVER-2077
> Project: Directory ApacheDS
> Issue Type: Task
>Affects Versions: 2.0.0-M20
>Reporter: Emmanuel Lecharny
>Priority: Critical
> Fix For: 2.0.0-M24
>
>
> We have been lazy in the past, by not provided tools to migrate from one
> version to the other, simply because they were milestones.
> There are three things we need to migrate :
> - configuration
> - schemas
> - data
> for each of those data, we have to provide a tool that helps the migration
> from one version to the next one.
> Ideally, this should be cumulative : ie, migrating from N to, say, N+3 should
> migrate those data from N to N+1, then N+1 to N+2 and finally N+2 to N+3
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (DIRSERVER-2077) Provide tools to migrate the config or the data between releases
[
https://issues.apache.org/jira/browse/DIRSERVER-2077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16138047#comment-16138047
]
Emmanuel Lecharny edited comment on DIRSERVER-2077 at 8/23/17 8:11 AM:
---
I concur.
The LDIF spec ([http://www.faqs.org/rfcs/rfc2849.html]) is pretty clear :
{noformat}
ldif-file= ldif-content / ldif-changes
ldif-content = version-spec 1*(1*SEP ldif-attrval-record)
ldif-attrval-record = dn-spec SEP 1*attrval-spec
attrval-spec = AttributeDescription value-spec SEP
value-spec = ":" (FILL 0*1(SAFE-STRING) / ":" FILL
(BASE64-STRING) / "<" FILL url)
FILL = *SPACE
SAFE-STRING = [SAFE-INIT-CHAR *SAFE-CHAR]
SAFE-INIT-CHAR = %x01-09 / %x0B-0C / %x0E-1F / %x21-39 / %x3B /
%x3D-7F
{noformat}
Which means something like {{ads-baseDn:}} is for a null value stored in
{{ads-baseDn}} (which is legit : {{rootDSE}}), for instance, {{ads-baseDN\: }}
(with an ending space) is for the exact same thing as the leading space will be
taken for the {{FILL}} part of the LDIF grammar. So basically, they are
encoding for the same value, and if the ldif parser does not see them as the
same value, then it's a big bug.
was (Author: elecharny):
I concur.
The LDIF spec ([http://www.faqs.org/rfcs/rfc2849.html]) is pretty clear :
{noformat}
ldif-file= ldif-content / ldif-changes
ldif-content = version-spec 1*(1*SEP ldif-attrval-record)
ldif-attrval-record = dn-spec SEP 1*attrval-spec
attrval-spec = AttributeDescription value-spec SEP
value-spec = ":" (FILL 0*1(SAFE-STRING) / ":" FILL
(BASE64-STRING) / "<" FILL url)
FILL = *SPACE
SAFE-STRING = [SAFE-INIT-CHAR *SAFE-CHAR]
SAFE-INIT-CHAR = %x01-09 / %x0B-0C / %x0E-1F / %x21-39 / %x3B /
%x3D-7F
{noformat}
Which means something like {{ads-baseDn:}} is for a null value stored in
{{ads-baseDn}} (which is legit : {{rootDSE}}), for instance, {{ads-baseDN: }}
(with an ending space) is for the exact same thing as the leading space will be
taken for the {{FILL}} part of the LDIF grammar. So basically, they are
encoding for the same value, and if the ldif parser does not see them as the
same value, then it's a big bug.
> Provide tools to migrate the config or the data between releases
>
>
> Key: DIRSERVER-2077
> URL: https://issues.apache.org/jira/browse/DIRSERVER-2077
> Project: Directory ApacheDS
> Issue Type: Task
>Affects Versions: 2.0.0-M20
>Reporter: Emmanuel Lecharny
>Priority: Critical
> Fix For: 2.0.0-M24
>
>
> We have been lazy in the past, by not provided tools to migrate from one
> version to the other, simply because they were milestones.
> There are three things we need to migrate :
> - configuration
> - schemas
> - data
> for each of those data, we have to provide a tool that helps the migration
> from one version to the next one.
> Ideally, this should be cumulative : ie, migrating from N to, say, N+3 should
> migrate those data from N to N+1, then N+1 to N+2 and finally N+2 to N+3
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (DIRSERVER-2077) Provide tools to migrate the config or the data between releases
[
https://issues.apache.org/jira/browse/DIRSERVER-2077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16138047#comment-16138047
]
Emmanuel Lecharny edited comment on DIRSERVER-2077 at 8/23/17 8:17 AM:
---
I concur.
The LDIF spec ([http://www.faqs.org/rfcs/rfc2849.html]) is pretty clear :
{noformat}
ldif-file= ldif-content / ldif-changes
ldif-content = version-spec 1*(1*SEP ldif-attrval-record)
ldif-attrval-record = dn-spec SEP 1*attrval-spec
attrval-spec = AttributeDescription value-spec SEP
value-spec = ":" (FILL 0*1(SAFE-STRING) / ":" FILL
(BASE64-STRING) / "<" FILL url)
FILL = *SPACE
SAFE-STRING = [SAFE-INIT-CHAR *SAFE-CHAR]
SAFE-INIT-CHAR = %x01-09 / %x0B-0C / %x0E-1F / %x21-39 / %x3B /
%x3D-7F
{noformat}
Which means something like {{ads-baseDn:}} is for a null value stored in
{{ads-baseDn}} (which is legit : {{rootDSE}}), for instance,
{{ads-baseDN:}} (with an ending space: JIRA formater does not work when
using a ' ' beofre a '}') is for the exact same thing as the leading space will
be taken for the {{FILL}} part of the LDIF grammar. So basically, they are
encoding for the same value, and if the ldif parser does not see them as the
same value, then it's a big bug.
was (Author: elecharny):
I concur.
The LDIF spec ([http://www.faqs.org/rfcs/rfc2849.html]) is pretty clear :
{noformat}
ldif-file= ldif-content / ldif-changes
ldif-content = version-spec 1*(1*SEP ldif-attrval-record)
ldif-attrval-record = dn-spec SEP 1*attrval-spec
attrval-spec = AttributeDescription value-spec SEP
value-spec = ":" (FILL 0*1(SAFE-STRING) / ":" FILL
(BASE64-STRING) / "<" FILL url)
FILL = *SPACE
SAFE-STRING = [SAFE-INIT-CHAR *SAFE-CHAR]
SAFE-INIT-CHAR = %x01-09 / %x0B-0C / %x0E-1F / %x21-39 / %x3B /
%x3D-7F
{noformat}
Which means something like {{ads-baseDn:}} is for a null value stored in
{{ads-baseDn}} (which is legit : {{rootDSE}}), for instance, {{ads-baseDN\: }}
(with an ending space) is for the exact same thing as the leading space will be
taken for the {{FILL}} part of the LDIF grammar. So basically, they are
encoding for the same value, and if the ldif parser does not see them as the
same value, then it's a big bug.
> Provide tools to migrate the config or the data between releases
>
>
> Key: DIRSERVER-2077
> URL: https://issues.apache.org/jira/browse/DIRSERVER-2077
> Project: Directory ApacheDS
> Issue Type: Task
>Affects Versions: 2.0.0-M20
>Reporter: Emmanuel Lecharny
>Priority: Critical
> Fix For: 2.0.0-M24
>
>
> We have been lazy in the past, by not provided tools to migrate from one
> version to the other, simply because they were milestones.
> There are three things we need to migrate :
> - configuration
> - schemas
> - data
> for each of those data, we have to provide a tool that helps the migration
> from one version to the next one.
> Ideally, this should be cumulative : ie, migrating from N to, say, N+3 should
> migrate those data from N to N+1, then N+1 to N+2 and finally N+2 to N+3
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (DIRSERVER-2077) Provide tools to migrate the config or the data between releases
[ https://issues.apache.org/jira/browse/DIRSERVER-2077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16137778#comment-16137778 ] Warren Rogers commented on DIRSERVER-2077: -- I came across the original issue also with M24. After some troubleshooting, and not being able to use this workaround, I finally found the problem. The *config.ldif* has the attribute *ads-baseDn* with the value of " " (space). The config.ldif conversion works perfectly with the space, but if that space is removed so that the attribute reads just *ads-baseDn:* the conversion fails. So, how did the exported file have those spaces removed? My IDE (JetBrains Idea) is set to clean extra whitespace from files, for size and general cleanliness. Thus, the working file now fails with my new directory server vs the directory server I created via Apache Studio, which I used to export the *config.ldif*. So, I would say this is still a bug. Values of attributes should be allowed non-space, or no value. Or, require non-value attributes be some other value, such as 'null' If 'null' is not allowable, then the reader should add the space during initialization. > Provide tools to migrate the config or the data between releases > > > Key: DIRSERVER-2077 > URL: https://issues.apache.org/jira/browse/DIRSERVER-2077 > Project: Directory ApacheDS > Issue Type: Task >Affects Versions: 2.0.0-M20 >Reporter: Emmanuel Lecharny >Priority: Critical > Fix For: 2.0.0-M24 > > > We have been lazy in the past, by not provided tools to migrate from one > version to the other, simply because they were milestones. > There are three things we need to migrate : > - configuration > - schemas > - data > for each of those data, we have to provide a tool that helps the migration > from one version to the next one. > Ideally, this should be cumulative : ie, migrating from N to, say, N+3 should > migrate those data from N to N+1, then N+1 to N+2 and finally N+2 to N+3 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (DIRSERVER-2077) Provide tools to migrate the config or the data between releases
[ https://issues.apache.org/jira/browse/DIRSERVER-2077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seelmann updated DIRSERVER-2077: --- Fix Version/s: (was: 2.0.0-M23) 2.0.0-M24 > Provide tools to migrate the config or the data between releases > > > Key: DIRSERVER-2077 > URL: https://issues.apache.org/jira/browse/DIRSERVER-2077 > Project: Directory ApacheDS > Issue Type: Task >Affects Versions: 2.0.0-M20 >Reporter: Emmanuel Lecharny >Priority: Critical > Fix For: 2.0.0-M24 > > > We have been lazy in the past, by not provided tools to migrate from one > version to the other, simply because they were milestones. > There are three things we need to migrate : > - configuration > - schemas > - data > for each of those data, we have to provide a tool that helps the migration > from one version to the next one. > Ideally, this should be cumulative : ie, migrating from N to, say, N+3 should > migrate those data from N to N+1, then N+1 to N+2 and finally N+2 to N+3 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Project and Skins releases
Hi guys, I have updated the 'project' and 'skins' project, and I will cut a release soon. The only thing that bothers me is that project refers to skin which refers to project : we do have SNAPSHOT cross-references. I may have some intermediary state where project will point to an unexisting skin 1.0.3 version - but that should be for a few minutes. Thanks !
[jira] [Updated] (DIRSERVER-2077) Provide tools to migrate the config or the data between releases
[ https://issues.apache.org/jira/browse/DIRSERVER-2077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny updated DIRSERVER-2077: - Fix Version/s: (was: 2.0.0-M22) 2.0.0-M23 > Provide tools to migrate the config or the data between releases > > > Key: DIRSERVER-2077 > URL: https://issues.apache.org/jira/browse/DIRSERVER-2077 > Project: Directory ApacheDS > Issue Type: Task >Affects Versions: 2.0.0-M20 >Reporter: Emmanuel Lecharny >Priority: Critical > Fix For: 2.0.0-M23 > > > We have been lazy in the past, by not provided tools to migrate from one > version to the other, simply because they were milestones. > There are three things we need to migrate : > - configuration > - schemas > - data > for each of those data, we have to provide a tool that helps the migration > from one version to the next one. > Ideally, this should be cumulative : ie, migrating from N to, say, N+3 should > migrate those data from N to N+1, then N+1 to N+2 and finally N+2 to N+3 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DIRSERVER-2077) Provide tools to migrate the config or the data between releases
[ https://issues.apache.org/jira/browse/DIRSERVER-2077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny updated DIRSERVER-2077: - Fix Version/s: (was: 2.0.0-M21) 2.0.0-M22 > Provide tools to migrate the config or the data between releases > > > Key: DIRSERVER-2077 > URL: https://issues.apache.org/jira/browse/DIRSERVER-2077 > Project: Directory ApacheDS > Issue Type: Task >Affects Versions: 2.0.0-M20 >Reporter: Emmanuel Lecharny >Priority: Critical > Fix For: 2.0.0-M22 > > > We have been lazy in the past, by not provided tools to migrate from one > version to the other, simply because they were milestones. > There are three things we need to migrate : > - configuration > - schemas > - data > for each of those data, we have to provide a tool that helps the migration > from one version to the next one. > Ideally, this should be cumulative : ie, migrating from N to, say, N+3 should > migrate those data from N to N+1, then N+1 to N+2 and finally N+2 to N+3 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (DIRSERVER-2077) Provide tools to migrate the config or the data between releases
Emmanuel Lecharny created DIRSERVER-2077: Summary: Provide tools to migrate the config or the data between releases Key: DIRSERVER-2077 URL: https://issues.apache.org/jira/browse/DIRSERVER-2077 Project: Directory ApacheDS Issue Type: Task Affects Versions: 2.0.0-M20 Reporter: Emmanuel Lecharny Priority: Critical Fix For: 2.0.0-M21 We have been lazy in the past, by not provided tools to migrate from one version to the other, simply because they were milestones. There are three things we need to migrate : - configuration - schemas - data for each of those data, we have to provide a tool that helps the migration from one version to the next one. Ideally, this should be cumulative : ie, migrating from N to, say, N+3 should migrate those data from N to N+1, then N+1 to N+2 and finally N+2 to N+3 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Preparing some releases
Absolutely ! Le dimanche 25 janvier 2015, Zheng, Kai kai.zh...@intel.com a écrit : KRB : 55 I guess these are rather new from Kerby project, right ? Regards, Kai *From:* Emmanuel Lecharny [mailto:elecha...@apache.org javascript:_e(%7B%7D,'cvml','elecha...@apache.org');] *Sent:* Sunday, January 25, 2015 2:22 AM *To:* Apache Directory Developers List *Subject:* Re: Preparing some releases No urgency. I have myself a lot on my plate, and some updates to the apacheds config plugin, and i'll take a week off in one week. I'm just informing committers about the idea of a coming release. Le vendredi 23 janvier 2015, Stefan Seelmann m...@stefan-seelmann.de javascript:_e(%7B%7D,'cvml','m...@stefan-seelmann.de'); a écrit : On 01/22/2015 02:12 PM, Emmanuel Lécharny wrote: Hi guys ! Thanks to the great effort Stefan has put on Studio, we are probably close to cut a release, as soon as we are sure we can do it with the Tycho migration. But in order to be able to release Studio, we need to release ApacheDS too. I had a look at the various projects we are dealing with at Directory, and all in all, we do have 527 opened jiras ... ApacheDS : 283 Studio : 107 KRB : 55 Fortress : 25 API : 25 DIR : 20 Mavibot : 10 eSCIMo : 2 Stduio requires fresh version of the API, Mavibot and ApacheDS. It's probablky time to start a bug parade for those projects, and cut a release of each of them. Thanks Emmanuel for the proposal, yes let's try to fix some bugs. For Studio I already opened some issues required for the next release, there is some work to do. I won't have much time before end of next week to work on Studio. Kind Regards, Stefan -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
Re: Preparing some releases
No urgency. I have myself a lot on my plate, and some updates to the apacheds config plugin, and i'll take a week off in one week. I'm just informing committers about the idea of a coming release. Le vendredi 23 janvier 2015, Stefan Seelmann m...@stefan-seelmann.de a écrit : On 01/22/2015 02:12 PM, Emmanuel Lécharny wrote: Hi guys ! Thanks to the great effort Stefan has put on Studio, we are probably close to cut a release, as soon as we are sure we can do it with the Tycho migration. But in order to be able to release Studio, we need to release ApacheDS too. I had a look at the various projects we are dealing with at Directory, and all in all, we do have 527 opened jiras ... ApacheDS : 283 Studio : 107 KRB : 55 Fortress : 25 API : 25 DIR : 20 Mavibot : 10 eSCIMo : 2 Stduio requires fresh version of the API, Mavibot and ApacheDS. It's probablky time to start a bug parade for those projects, and cut a release of each of them. Thanks Emmanuel for the proposal, yes let's try to fix some bugs. For Studio I already opened some issues required for the next release, there is some work to do. I won't have much time before end of next week to work on Studio. Kind Regards, Stefan -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
RE: Preparing some releases
KRB : 55 I guess these are rather new from Kerby project, right ? Regards, Kai From: Emmanuel Lecharny [mailto:elecha...@apache.org] Sent: Sunday, January 25, 2015 2:22 AM To: Apache Directory Developers List Subject: Re: Preparing some releases No urgency. I have myself a lot on my plate, and some updates to the apacheds config plugin, and i'll take a week off in one week. I'm just informing committers about the idea of a coming release. Le vendredi 23 janvier 2015, Stefan Seelmann m...@stefan-seelmann.demailto:m...@stefan-seelmann.de a écrit : On 01/22/2015 02:12 PM, Emmanuel Lécharny wrote: Hi guys ! Thanks to the great effort Stefan has put on Studio, we are probably close to cut a release, as soon as we are sure we can do it with the Tycho migration. But in order to be able to release Studio, we need to release ApacheDS too. I had a look at the various projects we are dealing with at Directory, and all in all, we do have 527 opened jiras ... ApacheDS : 283 Studio : 107 KRB : 55 Fortress : 25 API : 25 DIR : 20 Mavibot : 10 eSCIMo : 2 Stduio requires fresh version of the API, Mavibot and ApacheDS. It's probablky time to start a bug parade for those projects, and cut a release of each of them. Thanks Emmanuel for the proposal, yes let's try to fix some bugs. For Studio I already opened some issues required for the next release, there is some work to do. I won't have much time before end of next week to work on Studio. Kind Regards, Stefan -- Regards, Cordialement, Emmanuel Lécharny www.iktek.comhttp://www.iktek.com
Re: Preparing some releases
On 01/22/2015 02:12 PM, Emmanuel Lécharny wrote: Hi guys ! Thanks to the great effort Stefan has put on Studio, we are probably close to cut a release, as soon as we are sure we can do it with the Tycho migration. But in order to be able to release Studio, we need to release ApacheDS too. I had a look at the various projects we are dealing with at Directory, and all in all, we do have 527 opened jiras ... ApacheDS : 283 Studio : 107 KRB : 55 Fortress : 25 API : 25 DIR : 20 Mavibot : 10 eSCIMo : 2 Stduio requires fresh version of the API, Mavibot and ApacheDS. It's probablky time to start a bug parade for those projects, and cut a release of each of them. Thanks Emmanuel for the proposal, yes let's try to fix some bugs. For Studio I already opened some issues required for the next release, there is some work to do. I won't have much time before end of next week to work on Studio. Kind Regards, Stefan
Preparing some releases
Hi guys ! Thanks to the great effort Stefan has put on Studio, we are probably close to cut a release, as soon as we are sure we can do it with the Tycho migration. But in order to be able to release Studio, we need to release ApacheDS too. I had a look at the various projects we are dealing with at Directory, and all in all, we do have 527 opened jiras ... ApacheDS : 283 Studio : 107 KRB : 55 Fortress : 25 API : 25 DIR : 20 Mavibot : 10 eSCIMo : 2 Stduio requires fresh version of the API, Mavibot and ApacheDS. It's probablky time to start a bug parade for those projects, and cut a release of each of them.
IMPORTANT : we have to comply with the new Infra policy regarding releases...
Hi guys, I discovered lately that releases (source releases) *must* be pushed via svnpubsub : https://dist.apache.org/repos/dist/release/. Everything that was stored on /www/www.apache.org/dist/ will not be supported anymore (to be confirmed). That means we have to review our release process, but more important, we also have to change the way we release Studio : currently, we push binaries for each platform, which is not correct. Dist is only supposed to store source tarballs. We may ask for the binaries to be stored somewhere else. I will ask infra about the right way to do that. Thanks ! -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
[jira] [Closed] (DIRSHARED-129) Push shared-i18n-1.0.0-M5 artifact to Apache releases repository
[ https://issues.apache.org/jira/browse/DIRSHARED-129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny closed DIRSHARED-129. --- Push shared-i18n-1.0.0-M5 artifact to Apache releases repository Key: DIRSHARED-129 URL: https://issues.apache.org/jira/browse/DIRSHARED-129 Project: Directory Shared Issue Type: Task Reporter: Aleksander Adamowski ApacheDS server snapshots have started using shared-* artifacts version 1.0.0-M5 through the new parent POM from 22 June: https://repository.apache.org/content/repositories/snapshots/org/apache/directory/server/apacheds-parent/1.5.8-SNAPSHOT/apacheds-parent-1.5.8-20110622.155135-270.pom The POM specifies: !-- Set versions for depending projects -- org.apache.directory.shared.version1.0.0-M5/org.apache.directory.shared.version However, the 1.0.0-M5 version has not been released to the Apache releases Maven repository: https://repository.apache.org/content/repositories/releases/org/apache/directory/shared/shared-i18n/ despite the fact that shared snapshots have moved on to 1.0.0-M6-SNAPSHOT version: https://repository.apache.org/content/repositories/snapshots/org/apache/directory/shared/shared-i18n/1.0.0-M6-SNAPSHOT/ This broke the build for anything dependent on apacheds server snapshots: The following artifacts could not be resolved: org.apache.directory.shared:shared-i18n:jar:1.0.0-M5, org.apache.directory.shared:shared-ldap-extras-aci:jar:1.0.0-M5, org.apache.directory.shared:shared-ldap-extras-trigger:jar:1.0.0-M5, org.apache.directory.shared:shared-ldap-extras-util:jar:1.0.0-M5, org.apache.directory.shared:shared-asn1-ber:jar:1.0.0-M5, org.apache.directory.shared:shared-asn1-api:jar:1.0.0-M5, org.apache.directory.shared:shared-ldap-extras-sp:jar:1.0.0-M5, org.apache.directory.shared:shared-ldap-codec-core:jar:1.0.0-M5, org.apache.directory.shared:shared-ldap-extras-codec:jar:1.0.0-M5, org.apache.directory.shared:shared-ldap-model:jar:1.0.0-M5, org.apache.directory.shared:shared-util:jar:1.0.0-M5, org.apache.directory.shared:shared-ldap-client-api:jar:1.0.0-M5, org.apache.directory.shared:shared-dsml-engine:jar:1.0.0-M5, org.apache.directory.shared:shared-ldap-schema-data:jar:1.0.0-M5: Could not find artifact org.apache.directory.shared:shared-i18n:jar:1.0.0-M5 Please, release shared 1.0.0-M5 artifacts to the official Apache releases repo ASAP. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DIRSHARED-129) Push shared-i18n-1.0.0-M5 artifact to Apache releases repository
[ https://issues.apache.org/jira/browse/DIRSHARED-129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13056730#comment-13056730 ] Aleksander Adamowski commented on DIRSHARED-129: Thanks for the hint, version 2.0.0-M1 works fine and I finally have no SNAPSHOT dependencies :) Push shared-i18n-1.0.0-M5 artifact to Apache releases repository Key: DIRSHARED-129 URL: https://issues.apache.org/jira/browse/DIRSHARED-129 Project: Directory Shared Issue Type: Task Reporter: Aleksander Adamowski ApacheDS server snapshots have started using shared-* artifacts version 1.0.0-M5 through the new parent POM from 22 June: https://repository.apache.org/content/repositories/snapshots/org/apache/directory/server/apacheds-parent/1.5.8-SNAPSHOT/apacheds-parent-1.5.8-20110622.155135-270.pom The POM specifies: !-- Set versions for depending projects -- org.apache.directory.shared.version1.0.0-M5/org.apache.directory.shared.version However, the 1.0.0-M5 version has not been released to the Apache releases Maven repository: https://repository.apache.org/content/repositories/releases/org/apache/directory/shared/shared-i18n/ despite the fact that shared snapshots have moved on to 1.0.0-M6-SNAPSHOT version: https://repository.apache.org/content/repositories/snapshots/org/apache/directory/shared/shared-i18n/1.0.0-M6-SNAPSHOT/ This broke the build for anything dependent on apacheds server snapshots: The following artifacts could not be resolved: org.apache.directory.shared:shared-i18n:jar:1.0.0-M5, org.apache.directory.shared:shared-ldap-extras-aci:jar:1.0.0-M5, org.apache.directory.shared:shared-ldap-extras-trigger:jar:1.0.0-M5, org.apache.directory.shared:shared-ldap-extras-util:jar:1.0.0-M5, org.apache.directory.shared:shared-asn1-ber:jar:1.0.0-M5, org.apache.directory.shared:shared-asn1-api:jar:1.0.0-M5, org.apache.directory.shared:shared-ldap-extras-sp:jar:1.0.0-M5, org.apache.directory.shared:shared-ldap-codec-core:jar:1.0.0-M5, org.apache.directory.shared:shared-ldap-extras-codec:jar:1.0.0-M5, org.apache.directory.shared:shared-ldap-model:jar:1.0.0-M5, org.apache.directory.shared:shared-util:jar:1.0.0-M5, org.apache.directory.shared:shared-ldap-client-api:jar:1.0.0-M5, org.apache.directory.shared:shared-dsml-engine:jar:1.0.0-M5, org.apache.directory.shared:shared-ldap-schema-data:jar:1.0.0-M5: Could not find artifact org.apache.directory.shared:shared-i18n:jar:1 .0.0-M5 Please, release shared 1.0.0-M5 artifacts to the official Apache releases repo ASAP. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DIRSHARED-129) Push shared-i18n-1.0.0-M5 artifact to Apache releases repository
[ https://issues.apache.org/jira/browse/DIRSHARED-129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13056740#comment-13056740 ] Pierre-Arnaud Marcelot commented on DIRSHARED-129: -- Great! Happy to hear that. Push shared-i18n-1.0.0-M5 artifact to Apache releases repository Key: DIRSHARED-129 URL: https://issues.apache.org/jira/browse/DIRSHARED-129 Project: Directory Shared Issue Type: Task Reporter: Aleksander Adamowski ApacheDS server snapshots have started using shared-* artifacts version 1.0.0-M5 through the new parent POM from 22 June: https://repository.apache.org/content/repositories/snapshots/org/apache/directory/server/apacheds-parent/1.5.8-SNAPSHOT/apacheds-parent-1.5.8-20110622.155135-270.pom The POM specifies: !-- Set versions for depending projects -- org.apache.directory.shared.version1.0.0-M5/org.apache.directory.shared.version However, the 1.0.0-M5 version has not been released to the Apache releases Maven repository: https://repository.apache.org/content/repositories/releases/org/apache/directory/shared/shared-i18n/ despite the fact that shared snapshots have moved on to 1.0.0-M6-SNAPSHOT version: https://repository.apache.org/content/repositories/snapshots/org/apache/directory/shared/shared-i18n/1.0.0-M6-SNAPSHOT/ This broke the build for anything dependent on apacheds server snapshots: The following artifacts could not be resolved: org.apache.directory.shared:shared-i18n:jar:1.0.0-M5, org.apache.directory.shared:shared-ldap-extras-aci:jar:1.0.0-M5, org.apache.directory.shared:shared-ldap-extras-trigger:jar:1.0.0-M5, org.apache.directory.shared:shared-ldap-extras-util:jar:1.0.0-M5, org.apache.directory.shared:shared-asn1-ber:jar:1.0.0-M5, org.apache.directory.shared:shared-asn1-api:jar:1.0.0-M5, org.apache.directory.shared:shared-ldap-extras-sp:jar:1.0.0-M5, org.apache.directory.shared:shared-ldap-codec-core:jar:1.0.0-M5, org.apache.directory.shared:shared-ldap-extras-codec:jar:1.0.0-M5, org.apache.directory.shared:shared-ldap-model:jar:1.0.0-M5, org.apache.directory.shared:shared-util:jar:1.0.0-M5, org.apache.directory.shared:shared-ldap-client-api:jar:1.0.0-M5, org.apache.directory.shared:shared-dsml-engine:jar:1.0.0-M5, org.apache.directory.shared:shared-ldap-schema-data:jar:1.0.0-M5: Could not find artifact org.apache.directory.shared:shared-i18n:jar:1 .0.0-M5 Please, release shared 1.0.0-M5 artifacts to the official Apache releases repo ASAP. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DIRSHARED-129) Push shared-i18n-1.0.0-M5 artifact to Apache releases repository
[ https://issues.apache.org/jira/browse/DIRSHARED-129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13054254#comment-13054254 ] Emmanuel Lecharny commented on DIRSHARED-129: - Fair enough. I *think* this was a mistake somewhere during the release process. I have no idea how this happened, but it's not intentional. Push shared-i18n-1.0.0-M5 artifact to Apache releases repository Key: DIRSHARED-129 URL: https://issues.apache.org/jira/browse/DIRSHARED-129 Project: Directory Shared Issue Type: Task Reporter: Aleksander Adamowski ApacheDS server snapshots have started using shared-* artifacts version 1.0.0-M5 through the new parent POM from 22 June: https://repository.apache.org/content/repositories/snapshots/org/apache/directory/server/apacheds-parent/1.5.8-SNAPSHOT/apacheds-parent-1.5.8-20110622.155135-270.pom The POM specifies: !-- Set versions for depending projects -- org.apache.directory.shared.version1.0.0-M5/org.apache.directory.shared.version However, the 1.0.0-M5 version has not been released to the Apache releases Maven repository: https://repository.apache.org/content/repositories/releases/org/apache/directory/shared/shared-i18n/ despite the fact that shared snapshots have moved on to 1.0.0-M6-SNAPSHOT version: https://repository.apache.org/content/repositories/snapshots/org/apache/directory/shared/shared-i18n/1.0.0-M6-SNAPSHOT/ This broke the build for anything dependent on apacheds server snapshots: The following artifacts could not be resolved: org.apache.directory.shared:shared-i18n:jar:1.0.0-M5, org.apache.directory.shared:shared-ldap-extras-aci:jar:1.0.0-M5, org.apache.directory.shared:shared-ldap-extras-trigger:jar:1.0.0-M5, org.apache.directory.shared:shared-ldap-extras-util:jar:1.0.0-M5, org.apache.directory.shared:shared-asn1-ber:jar:1.0.0-M5, org.apache.directory.shared:shared-asn1-api:jar:1.0.0-M5, org.apache.directory.shared:shared-ldap-extras-sp:jar:1.0.0-M5, org.apache.directory.shared:shared-ldap-codec-core:jar:1.0.0-M5, org.apache.directory.shared:shared-ldap-extras-codec:jar:1.0.0-M5, org.apache.directory.shared:shared-ldap-model:jar:1.0.0-M5, org.apache.directory.shared:shared-util:jar:1.0.0-M5, org.apache.directory.shared:shared-ldap-client-api:jar:1.0.0-M5, org.apache.directory.shared:shared-dsml-engine:jar:1.0.0-M5, org.apache.directory.shared:shared-ldap-schema-data:jar:1.0.0-M5: Could not find artifact org.apache.directory.shared:shared-i18n:jar:1 .0.0-M5 Please, release shared 1.0.0-M5 artifacts to the official Apache releases repo ASAP. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DIRSHARED-129) Push shared-i18n-1.0.0-M5 artifact to Apache releases repository
[ https://issues.apache.org/jira/browse/DIRSHARED-129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13054261#comment-13054261 ] Pierre-Arnaud Marcelot commented on DIRSHARED-129: -- There's no mistake anywhere. The move to version 1.0.0-M5 was mandatory to cut the release, have a tagged version of the code in SVN and the installers ready for the release vote Our Jenkins/Continuum tasks were probably run between the short period of time the build stayed with version 1.0.0-M5 (less than a day from the commit logs). That said, how about depending on 1.0.0-M6-SNAPSHOT since you were depending on 1.5.8-SNAPSHOT ? 1.5.8-SNAPSHOT won't evolve anymore now... Push shared-i18n-1.0.0-M5 artifact to Apache releases repository Key: DIRSHARED-129 URL: https://issues.apache.org/jira/browse/DIRSHARED-129 Project: Directory Shared Issue Type: Task Reporter: Aleksander Adamowski ApacheDS server snapshots have started using shared-* artifacts version 1.0.0-M5 through the new parent POM from 22 June: https://repository.apache.org/content/repositories/snapshots/org/apache/directory/server/apacheds-parent/1.5.8-SNAPSHOT/apacheds-parent-1.5.8-20110622.155135-270.pom The POM specifies: !-- Set versions for depending projects -- org.apache.directory.shared.version1.0.0-M5/org.apache.directory.shared.version However, the 1.0.0-M5 version has not been released to the Apache releases Maven repository: https://repository.apache.org/content/repositories/releases/org/apache/directory/shared/shared-i18n/ despite the fact that shared snapshots have moved on to 1.0.0-M6-SNAPSHOT version: https://repository.apache.org/content/repositories/snapshots/org/apache/directory/shared/shared-i18n/1.0.0-M6-SNAPSHOT/ This broke the build for anything dependent on apacheds server snapshots: The following artifacts could not be resolved: org.apache.directory.shared:shared-i18n:jar:1.0.0-M5, org.apache.directory.shared:shared-ldap-extras-aci:jar:1.0.0-M5, org.apache.directory.shared:shared-ldap-extras-trigger:jar:1.0.0-M5, org.apache.directory.shared:shared-ldap-extras-util:jar:1.0.0-M5, org.apache.directory.shared:shared-asn1-ber:jar:1.0.0-M5, org.apache.directory.shared:shared-asn1-api:jar:1.0.0-M5, org.apache.directory.shared:shared-ldap-extras-sp:jar:1.0.0-M5, org.apache.directory.shared:shared-ldap-codec-core:jar:1.0.0-M5, org.apache.directory.shared:shared-ldap-extras-codec:jar:1.0.0-M5, org.apache.directory.shared:shared-ldap-model:jar:1.0.0-M5, org.apache.directory.shared:shared-util:jar:1.0.0-M5, org.apache.directory.shared:shared-ldap-client-api:jar:1.0.0-M5, org.apache.directory.shared:shared-dsml-engine:jar:1.0.0-M5, org.apache.directory.shared:shared-ldap-schema-data:jar:1.0.0-M5: Could not find artifact org.apache.directory.shared:shared-i18n:jar:1 .0.0-M5 Please, release shared 1.0.0-M5 artifacts to the official Apache releases repo ASAP. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (DIRSHARED-129) Push shared-i18n-1.0.0-M5 artifact to Apache releases repository
[ https://issues.apache.org/jira/browse/DIRSHARED-129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13054261#comment-13054261 ] Pierre-Arnaud Marcelot edited comment on DIRSHARED-129 at 6/24/11 6:39 AM: --- There's no mistake anywhere. The move to version 1.0.0-M5 was mandatory to cut the release, have a tagged version of the code in SVN and the installers ready for the release vote Our Jenkins/Continuum tasks were probably run between the short period of time the build stayed with version 1.0.0-M5 (less than a day from the commit logs). That said, how about depending on 2.0.0-M2-SNAPSHOT for ApacheDS since you were depending on 1.5.8-SNAPSHOT ? 1.5.8-SNAPSHOT won't evolve anymore now... was (Author: pamarcelot): There's no mistake anywhere. The move to version 1.0.0-M5 was mandatory to cut the release, have a tagged version of the code in SVN and the installers ready for the release vote Our Jenkins/Continuum tasks were probably run between the short period of time the build stayed with version 1.0.0-M5 (less than a day from the commit logs). That said, how about depending on 1.0.0-M6-SNAPSHOT since you were depending on 1.5.8-SNAPSHOT ? 1.5.8-SNAPSHOT won't evolve anymore now... Push shared-i18n-1.0.0-M5 artifact to Apache releases repository Key: DIRSHARED-129 URL: https://issues.apache.org/jira/browse/DIRSHARED-129 Project: Directory Shared Issue Type: Task Reporter: Aleksander Adamowski ApacheDS server snapshots have started using shared-* artifacts version 1.0.0-M5 through the new parent POM from 22 June: https://repository.apache.org/content/repositories/snapshots/org/apache/directory/server/apacheds-parent/1.5.8-SNAPSHOT/apacheds-parent-1.5.8-20110622.155135-270.pom The POM specifies: !-- Set versions for depending projects -- org.apache.directory.shared.version1.0.0-M5/org.apache.directory.shared.version However, the 1.0.0-M5 version has not been released to the Apache releases Maven repository: https://repository.apache.org/content/repositories/releases/org/apache/directory/shared/shared-i18n/ despite the fact that shared snapshots have moved on to 1.0.0-M6-SNAPSHOT version: https://repository.apache.org/content/repositories/snapshots/org/apache/directory/shared/shared-i18n/1.0.0-M6-SNAPSHOT/ This broke the build for anything dependent on apacheds server snapshots: The following artifacts could not be resolved: org.apache.directory.shared:shared-i18n:jar:1.0.0-M5, org.apache.directory.shared:shared-ldap-extras-aci:jar:1.0.0-M5, org.apache.directory.shared:shared-ldap-extras-trigger:jar:1.0.0-M5, org.apache.directory.shared:shared-ldap-extras-util:jar:1.0.0-M5, org.apache.directory.shared:shared-asn1-ber:jar:1.0.0-M5, org.apache.directory.shared:shared-asn1-api:jar:1.0.0-M5, org.apache.directory.shared:shared-ldap-extras-sp:jar:1.0.0-M5, org.apache.directory.shared:shared-ldap-codec-core:jar:1.0.0-M5, org.apache.directory.shared:shared-ldap-extras-codec:jar:1.0.0-M5, org.apache.directory.shared:shared-ldap-model:jar:1.0.0-M5, org.apache.directory.shared:shared-util:jar:1.0.0-M5, org.apache.directory.shared:shared-ldap-client-api:jar:1.0.0-M5, org.apache.directory.shared:shared-dsml-engine:jar:1.0.0-M5, org.apache.directory.shared:shared-ldap-schema-data:jar:1.0.0-M5: Could not find artifact org.apache.directory.shared:shared-i18n:jar:1 .0.0-M5 Please, release shared 1.0.0-M5 artifacts to the official Apache releases repo ASAP. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (DIRSHARED-129) Push shared-i18n-1.0.0-M5 artifact to Apache releases repository
Push shared-i18n-1.0.0-M5 artifact to Apache releases repository Key: DIRSHARED-129 URL: https://issues.apache.org/jira/browse/DIRSHARED-129 Project: Directory Shared Issue Type: Task Reporter: Aleksander Adamowski ApacheDS server snapshots have started using shared-* artifacts version 1.0.0-M5 through the new parent POM from 22 June: https://repository.apache.org/content/repositories/snapshots/org/apache/directory/server/apacheds-parent/1.5.8-SNAPSHOT/apacheds-parent-1.5.8-20110622.155135-270.pom The POM specifies: !-- Set versions for depending projects -- org.apache.directory.shared.version1.0.0-M5/org.apache.directory.shared.version However, the 1.0.0-M5 version has not been released to the Apache releases Maven repository: https://repository.apache.org/content/repositories/releases/org/apache/directory/shared/shared-i18n/ despite the fact that shared snapshots have moved on to 1.0.0-M6-SNAPSHOT version: https://repository.apache.org/content/repositories/snapshots/org/apache/directory/shared/shared-i18n/1.0.0-M6-SNAPSHOT/ This broke the build for anything dependent on apacheds server snapshots: The following artifacts could not be resolved: org.apache.directory.shared:shared-i18n:jar:1.0.0-M5, org.apache.directory.shared:shared-ldap-extras-aci:jar:1.0.0-M5, org.apache.directory.shared:shared-ldap-extras-trigger:jar:1.0.0-M5, org.apache.directory.shared:shared-ldap-extras-util:jar:1.0.0-M5, org.apache.directory.shared:shared-asn1-ber:jar:1.0.0-M5, org.apache.directory.shared:shared-asn1-api:jar:1.0.0-M5, org.apache.directory.shared:shared-ldap-extras-sp:jar:1.0.0-M5, org.apache.directory.shared:shared-ldap-codec-core:jar:1.0.0-M5, org.apache.directory.shared:shared-ldap-extras-codec:jar:1.0.0-M5, org.apache.directory.shared:shared-ldap-model:jar:1.0.0-M5, org.apache.directory.shared:shared-util:jar:1.0.0-M5, org.apache.directory.shared:shared-ldap-client-api:jar:1.0.0-M5, org.apache.directory.shared:shared-dsml-engine:jar:1.0.0-M5, org.apache.directory.shared:shared-ldap-schema-data:jar:1.0.0-M5: Could not find artifact org.apache.directory.shared:shared-i18n:jar:1.0 .0-M5 Please, release shared 1.0.0-M5 artifacts to the official Apache releases repo ASAP. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (DIRSHARED-129) Push shared-i18n-1.0.0-M5 artifact to Apache releases repository
[ https://issues.apache.org/jira/browse/DIRSHARED-129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny resolved DIRSHARED-129. - Resolution: Won't Fix We can't release anything until the vote is closed, and until it's a positive vote. The end of the vote period will be on saturday. Until then the apacheds pom in trunks is now pojnting on 1.0.0-M6-SNAPSHOT, not on 1.0.0-M5. You should get the project from trunks-with-dependencies, and build it completely, in order to get the righteous jars locally. Push shared-i18n-1.0.0-M5 artifact to Apache releases repository Key: DIRSHARED-129 URL: https://issues.apache.org/jira/browse/DIRSHARED-129 Project: Directory Shared Issue Type: Task Reporter: Aleksander Adamowski ApacheDS server snapshots have started using shared-* artifacts version 1.0.0-M5 through the new parent POM from 22 June: https://repository.apache.org/content/repositories/snapshots/org/apache/directory/server/apacheds-parent/1.5.8-SNAPSHOT/apacheds-parent-1.5.8-20110622.155135-270.pom The POM specifies: !-- Set versions for depending projects -- org.apache.directory.shared.version1.0.0-M5/org.apache.directory.shared.version However, the 1.0.0-M5 version has not been released to the Apache releases Maven repository: https://repository.apache.org/content/repositories/releases/org/apache/directory/shared/shared-i18n/ despite the fact that shared snapshots have moved on to 1.0.0-M6-SNAPSHOT version: https://repository.apache.org/content/repositories/snapshots/org/apache/directory/shared/shared-i18n/1.0.0-M6-SNAPSHOT/ This broke the build for anything dependent on apacheds server snapshots: The following artifacts could not be resolved: org.apache.directory.shared:shared-i18n:jar:1.0.0-M5, org.apache.directory.shared:shared-ldap-extras-aci:jar:1.0.0-M5, org.apache.directory.shared:shared-ldap-extras-trigger:jar:1.0.0-M5, org.apache.directory.shared:shared-ldap-extras-util:jar:1.0.0-M5, org.apache.directory.shared:shared-asn1-ber:jar:1.0.0-M5, org.apache.directory.shared:shared-asn1-api:jar:1.0.0-M5, org.apache.directory.shared:shared-ldap-extras-sp:jar:1.0.0-M5, org.apache.directory.shared:shared-ldap-codec-core:jar:1.0.0-M5, org.apache.directory.shared:shared-ldap-extras-codec:jar:1.0.0-M5, org.apache.directory.shared:shared-ldap-model:jar:1.0.0-M5, org.apache.directory.shared:shared-util:jar:1.0.0-M5, org.apache.directory.shared:shared-ldap-client-api:jar:1.0.0-M5, org.apache.directory.shared:shared-dsml-engine:jar:1.0.0-M5, org.apache.directory.shared:shared-ldap-schema-data:jar:1.0.0-M5: Could not find artifact org.apache.directory.shared:shared-i18n:jar:1 .0.0-M5 Please, release shared 1.0.0-M5 artifacts to the official Apache releases repo ASAP. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DIRSHARED-129) Push shared-i18n-1.0.0-M5 artifact to Apache releases repository
[ https://issues.apache.org/jira/browse/DIRSHARED-129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13054183#comment-13054183 ] Aleksander Adamowski commented on DIRSHARED-129: Then how about not referencing artifacts that aren't released yet (https://repository.apache.org/content/repositories/snapshots/org/apache/directory/server/apacheds-parent/1.5.8-SNAPSHOT/apacheds-parent-1.5.8-20110622.155135-270.pom shows the smoking gun)? Push shared-i18n-1.0.0-M5 artifact to Apache releases repository Key: DIRSHARED-129 URL: https://issues.apache.org/jira/browse/DIRSHARED-129 Project: Directory Shared Issue Type: Task Reporter: Aleksander Adamowski ApacheDS server snapshots have started using shared-* artifacts version 1.0.0-M5 through the new parent POM from 22 June: https://repository.apache.org/content/repositories/snapshots/org/apache/directory/server/apacheds-parent/1.5.8-SNAPSHOT/apacheds-parent-1.5.8-20110622.155135-270.pom The POM specifies: !-- Set versions for depending projects -- org.apache.directory.shared.version1.0.0-M5/org.apache.directory.shared.version However, the 1.0.0-M5 version has not been released to the Apache releases Maven repository: https://repository.apache.org/content/repositories/releases/org/apache/directory/shared/shared-i18n/ despite the fact that shared snapshots have moved on to 1.0.0-M6-SNAPSHOT version: https://repository.apache.org/content/repositories/snapshots/org/apache/directory/shared/shared-i18n/1.0.0-M6-SNAPSHOT/ This broke the build for anything dependent on apacheds server snapshots: The following artifacts could not be resolved: org.apache.directory.shared:shared-i18n:jar:1.0.0-M5, org.apache.directory.shared:shared-ldap-extras-aci:jar:1.0.0-M5, org.apache.directory.shared:shared-ldap-extras-trigger:jar:1.0.0-M5, org.apache.directory.shared:shared-ldap-extras-util:jar:1.0.0-M5, org.apache.directory.shared:shared-asn1-ber:jar:1.0.0-M5, org.apache.directory.shared:shared-asn1-api:jar:1.0.0-M5, org.apache.directory.shared:shared-ldap-extras-sp:jar:1.0.0-M5, org.apache.directory.shared:shared-ldap-codec-core:jar:1.0.0-M5, org.apache.directory.shared:shared-ldap-extras-codec:jar:1.0.0-M5, org.apache.directory.shared:shared-ldap-model:jar:1.0.0-M5, org.apache.directory.shared:shared-util:jar:1.0.0-M5, org.apache.directory.shared:shared-ldap-client-api:jar:1.0.0-M5, org.apache.directory.shared:shared-dsml-engine:jar:1.0.0-M5, org.apache.directory.shared:shared-ldap-schema-data:jar:1.0.0-M5: Could not find artifact org.apache.directory.shared:shared-i18n:jar:1 .0.0-M5 Please, release shared 1.0.0-M5 artifacts to the official Apache releases repo ASAP. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [DISCUSS] [Release Scheme] Contract/Policy with users for releases
On 5 janv. 2011, at 20:32, Alex Karasulu wrote:
On Wed, Jan 5, 2011 at 9:16 PM, Jesse McConnell jesse.mcconn...@gmail.com
wrote:
Since you have eclipse plugins you ought to
build those with maven + tycho and have a similar and sane versioning
system.
I talked with Pierre about it. As a side point because of the way the build
in Studio is setup, we're unable at this point to take advantage of IDE
refactoring since dependencies are on bundle jars rather than on projects
themselves. Do you know if using Maven + Tycho will help with this specific
problem?
I'm asking this because it might spare some work for us when we refactor
shared which Studio depends on.
when I am working on the jetty wtp plugin I am able to have all 3
plugins open and refactor between them, I just let m2eclipse import
and do the right thing
the combination of m2eclipse + maven3 + tycho is quite nice
Ahh cool. PAM, and Seelman is this something you might want to try or leave
out for later? I just cringe at the thought of your having to manually update
Studio again after we reorg shared.
Hi Alex, Jesse,
The situation is a little more complicated actually as we have a three level
story here.
Let me recap the situation...
Some functionalities of Studio plugins require that we use/extend classes of
some Shared and ApacheDS project modules.
Unfortunately, those Shared and ApacheDS project modules are not OSGI (or
Eclipse) bundles (yet?).
In order to solve that problem and to be able to use them in our plugins, we
created a specific Eclipse plugin for each required Shared and ApacheDS
dependency.
I named such a plugin as a Library Plugin, opposed to our Studio Code
Plugins.
A Library Plugin simply embeds the jar file of the corresponding Shared or
ApacheDS project module and sets a proper MANIFEST.MF file with the correct
OSGI and Eclipse instructions (Bundle-SymbolicName, Export-Package,
Require-Bundle, etc.).
In the end, in your Eclipse workspace, you find yourself having two projects
for a single original module:
- that original module with the source code ('shared-ldap' for example)
- the associated library plugin, based on a constructed (snapshot) jar file of
that original module ('org.apache.directory.shared.ldap' for example)
Now, when you refactor the source code of the original module, unfortunately,
the link between that module and the final Studio Code Plugin is lost for
Eclipse, because of the use of the jar file in the associated Library Plugin
between the two.
Then the modifications applied on the original module are not applied to the
Studio Code Plugin.
I'm not sure Tycho can help us solve this issue, but it does, I'd be happy to
update our Studio build to use it...
Thoughts?
Regards,
Pierre-Arnaud
Re: [DISCUSS] [Release Scheme] Contract/Policy with users for releases
my recommendation would be to reach out to the tycho guys for a bit of
advice on this...I suspect the thing to do is to make the original
artifacts also osgi bundles, it really isn't that hard with the felix
maven bundle plugin, but there might be another way they could
recommend doing it
jesse
--
jesse mcconnell
jesse.mcconn...@gmail.com
On Tue, Jan 11, 2011 at 09:29, Pierre-Arnaud Marcelot p...@marcelot.net wrote:
On 5 janv. 2011, at 20:32, Alex Karasulu wrote:
On Wed, Jan 5, 2011 at 9:16 PM, Jesse McConnell jesse.mcconn...@gmail.com
wrote:
Since you have eclipse plugins you ought to
build those with maven + tycho and have a similar and sane versioning
system.
I talked with Pierre about it. As a side point because of the way the
build
in Studio is setup, we're unable at this point to take advantage of IDE
refactoring since dependencies are on bundle jars rather than on
projects
themselves. Do you know if using Maven + Tycho will help with this
specific
problem?
I'm asking this because it might spare some work for us when we refactor
shared which Studio depends on.
when I am working on the jetty wtp plugin I am able to have all 3
plugins open and refactor between them, I just let m2eclipse import
and do the right thing
the combination of m2eclipse + maven3 + tycho is quite nice
Ahh cool. PAM, and Seelman is this something you might want to try or leave
out for later? I just cringe at the thought of your having to manually
update Studio again after we reorg shared.
Hi Alex, Jesse,
The situation is a little more complicated actually as we have a three level
story here.
Let me recap the situation...
Some functionalities of Studio plugins require that we use/extend classes of
some Shared and ApacheDS project modules.
Unfortunately, those Shared and ApacheDS project modules are not OSGI (or
Eclipse) bundles (yet?).
In order to solve that problem and to be able to use them in our plugins, we
created a specific Eclipse plugin for each required Shared and ApacheDS
dependency.
I named such a plugin as a Library Plugin, opposed to our Studio Code
Plugins.
A Library Plugin simply embeds the jar file of the corresponding Shared or
ApacheDS project module and sets a proper MANIFEST.MF file with the correct
OSGI and Eclipse instructions (Bundle-SymbolicName, Export-Package,
Require-Bundle, etc.).
In the end, in your Eclipse workspace, you find yourself having two projects
for a single original module:
- that original module with the source code ('shared-ldap' for example)
- the associated library plugin, based on a constructed (snapshot) jar file
of that original module ('org.apache.directory.shared.ldap' for example)
Now, when you refactor the source code of the original module,
unfortunately, the link between that module and the final Studio Code
Plugin is lost for Eclipse, because of the use of the jar file in the
associated Library Plugin between the two.
Then the modifications applied on the original module are not applied to the
Studio Code Plugin.
I'm not sure Tycho can help us solve this issue, but it does, I'd be happy
to update our Studio build to use it...
Thoughts?
Regards,
Pierre-Arnaud
Re: [DISCUSS] [Release Scheme] Contract/Policy with users for releases
Yeah, making the original artifacts OSGI bundles would be the ideal solution.
It may also be the easiest one (moving our current build to Tycho might not be
trivial).
I'll try to evaluate Tycho more in depth later this month and ask the Tycho
guys about it.
Thanks,
Pierre-Arnaud
On 11 janv. 2011, at 16:42, Jesse McConnell wrote:
my recommendation would be to reach out to the tycho guys for a bit of
advice on this...I suspect the thing to do is to make the original
artifacts also osgi bundles, it really isn't that hard with the felix
maven bundle plugin, but there might be another way they could
recommend doing it
jesse
--
jesse mcconnell
jesse.mcconn...@gmail.com
On Tue, Jan 11, 2011 at 09:29, Pierre-Arnaud Marcelot p...@marcelot.net
wrote:
On 5 janv. 2011, at 20:32, Alex Karasulu wrote:
On Wed, Jan 5, 2011 at 9:16 PM, Jesse McConnell jesse.mcconn...@gmail.com
wrote:
Since you have eclipse plugins you ought to
build those with maven + tycho and have a similar and sane versioning
system.
I talked with Pierre about it. As a side point because of the way the
build
in Studio is setup, we're unable at this point to take advantage of IDE
refactoring since dependencies are on bundle jars rather than on
projects
themselves. Do you know if using Maven + Tycho will help with this
specific
problem?
I'm asking this because it might spare some work for us when we refactor
shared which Studio depends on.
when I am working on the jetty wtp plugin I am able to have all 3
plugins open and refactor between them, I just let m2eclipse import
and do the right thing
the combination of m2eclipse + maven3 + tycho is quite nice
Ahh cool. PAM, and Seelman is this something you might want to try or leave
out for later? I just cringe at the thought of your having to manually
update Studio again after we reorg shared.
Hi Alex, Jesse,
The situation is a little more complicated actually as we have a three level
story here.
Let me recap the situation...
Some functionalities of Studio plugins require that we use/extend classes of
some Shared and ApacheDS project modules.
Unfortunately, those Shared and ApacheDS project modules are not OSGI (or
Eclipse) bundles (yet?).
In order to solve that problem and to be able to use them in our plugins, we
created a specific Eclipse plugin for each required Shared and ApacheDS
dependency.
I named such a plugin as a Library Plugin, opposed to our Studio Code
Plugins.
A Library Plugin simply embeds the jar file of the corresponding Shared or
ApacheDS project module and sets a proper MANIFEST.MF file with the correct
OSGI and Eclipse instructions (Bundle-SymbolicName, Export-Package,
Require-Bundle, etc.).
In the end, in your Eclipse workspace, you find yourself having two projects
for a single original module:
- that original module with the source code ('shared-ldap' for example)
- the associated library plugin, based on a constructed (snapshot) jar file
of that original module ('org.apache.directory.shared.ldap' for example)
Now, when you refactor the source code of the original module,
unfortunately, the link between that module and the final Studio Code
Plugin is lost for Eclipse, because of the use of the jar file in the
associated Library Plugin between the two.
Then the modifications applied on the original module are not applied to the
Studio Code Plugin.
I'm not sure Tycho can help us solve this issue, but it does, I'd be happy
to update our Studio build to use it...
Thoughts?
Regards,
Pierre-Arnaud
Re: [DISCUSS] [Release Scheme] Contract/Policy with users for releases
On Tue, Jan 11, 2011 at 5:29 PM, Pierre-Arnaud Marcelot
p...@marcelot.netwrote:
On 5 janv. 2011, at 20:32, Alex Karasulu wrote:
On Wed, Jan 5, 2011 at 9:16 PM, Jesse McConnell jesse.mcconn...@gmail.com
wrote:
Since you have eclipse plugins you ought to
build those with maven + tycho and have a similar and sane versioning
system.
I talked with Pierre about it. As a side point because of the way the
build
in Studio is setup, we're unable at this point to take advantage of IDE
refactoring since dependencies are on bundle jars rather than on
projects
themselves. Do you know if using Maven + Tycho will help with this
specific
problem?
I'm asking this because it might spare some work for us when we refactor
shared which Studio depends on.
when I am working on the jetty wtp plugin I am able to have all 3
plugins open and refactor between them, I just let m2eclipse import
and do the right thing
the combination of m2eclipse + maven3 + tycho is quite nice
Ahh cool. PAM, and Seelman is this something you might want to try or leave
out for later? I just cringe at the thought of your having to manually
update Studio again after we reorg shared.
Hi Alex, Jesse,
The situation is a little more complicated actually as we have a three
level story here.
Let me recap the situation...
Some functionalities of Studio plugins require that we use/extend classes
of some Shared and ApacheDS project modules.
Unfortunately, those Shared and ApacheDS project modules are not OSGI (or
Eclipse) bundles (yet?).
Perhaps we can just convert them into bundles for now without any further
functionality.
In order to solve that problem and to be able to use them in our plugins,
we created a specific Eclipse plugin for each required Shared and ApacheDS
dependency.
I named such a plugin as a Library Plugin, opposed to our Studio Code
Plugins.
A Library Plugin simply embeds the jar file of the corresponding Shared
or ApacheDS project module and sets a proper MANIFEST.MF file with the
correct OSGI and Eclipse instructions (Bundle-SymbolicName, Export-Package,
Require-Bundle, etc.).
In the end, in your Eclipse workspace, you find yourself having two
projects for a single original module:
- that original module with the source code ('shared-ldap' for example)
- the associated library plugin, based on a constructed (snapshot) jar file
of that original module ('org.apache.directory.shared.ldap' for example)
Now, when you refactor the source code of the original module,
unfortunately, the link between that module and the final Studio Code
Plugin is lost for Eclipse, because of the use of the jar file in the
associated Library Plugin between the two.
Then the modifications applied on the original module are not applied to
the Studio Code Plugin.
I'm not sure Tycho can help us solve this issue, but it does, I'd be happy
to update our Studio build to use it...
Thoughts?
--
Alex Karasulu
My Blog :: http://www.jroller.com/akarasulu/
Apache Directory Server :: http://directory.apache.org
Apache MINA :: http://mina.apache.org
To set up a meeting with me: http://tungle.me/AlexKarasulu
Re: [DISCUSS] [Release Scheme] Contract/Policy with users for releases
On Wed, Jan 12, 2011 at 12:02 AM, Alex Karasulu akaras...@apache.org wrote: The situation is a little more complicated actually as we have a three level story here. Let me recap the situation... Some functionalities of Studio plugins require that we use/extend classes of some Shared and ApacheDS project modules. Unfortunately, those Shared and ApacheDS project modules are not OSGI (or Eclipse) bundles (yet?). Perhaps we can just convert them into bundles for now without any further functionality. We still have split packages, not in shared, but for example in apacheds-core and apacheds-core-api. Kind Regards, Stefan
Re: [DISCUSS] [Release Scheme] Contract/Policy with users for releases
On Wed, Jan 12, 2011 at 1:15 AM, Stefan Seelmann seelm...@apache.orgwrote: On Wed, Jan 12, 2011 at 12:02 AM, Alex Karasulu akaras...@apache.org wrote: The situation is a little more complicated actually as we have a three level story here. Let me recap the situation... Some functionalities of Studio plugins require that we use/extend classes of some Shared and ApacheDS project modules. Unfortunately, those Shared and ApacheDS project modules are not OSGI (or Eclipse) bundles (yet?). Perhaps we can just convert them into bundles for now without any further functionality. We still have split packages, not in shared, but for example in apacheds-core and apacheds-core-api. Yep. We also have them in shared between the schema and ldap modules. But I think they can be remedied pretty easily. Once Emmanuel is done and merged back in I can go to town on this and the refactoring. I don't know if merging my branch is really worth it at this point. -- Alex Karasulu My Blog :: http://www.jroller.com/akarasulu/ Apache Directory Server :: http://directory.apache.org Apache MINA :: http://mina.apache.org To set up a meeting with me: http://tungle.me/AlexKarasulu
Re: [DISCUSS] [Release Scheme] Contract/Policy with users for releases
I would get the Database Format and Configuration out of the equation. It's up to us to provide tools to migrate from one format to the other. Don't get me wrong : when I say that configuration is out of the equation, I mean that the configuration can change, not its format (ie switching from XML to DIT is possible between to major releases, not between two minor releases). Will this be transparent to the user? Meaning can he just upgrade the software and the migration will occur without any change in their workflow, or anything noticeable in performance, wait time on startup? More specifically: (1) Does the user have to run a tool to migrate from one version to the next ? Definitively, yes. I think the database format must be stable between micro (bugfix) and minor (feature enhancement) releases. For major releases it is acceptable to change the format and to provide a migration tool. Please keep in mind that the current JDBM format is not final yet. We introduced the RDN index for fast moddn operation, but still have the oneLevel, subLevel, and alias indices that are not updated in O(1). Kind Regards, Stefan
Re: [DISCUSS] [Release Scheme] Contract/Policy with users for releases
On Thu, Jan 6, 2011 at 12:42 PM, Stefan Seelmann seelm...@apache.orgwrote: I would get the Database Format and Configuration out of the equation. It's up to us to provide tools to migrate from one format to the other. Don't get me wrong : when I say that configuration is out of the equation, I mean that the configuration can change, not its format (ie switching from XML to DIT is possible between to major releases, not between two minor releases). Will this be transparent to the user? Meaning can he just upgrade the software and the migration will occur without any change in their workflow, or anything noticeable in performance, wait time on startup? More specifically: (1) Does the user have to run a tool to migrate from one version to the next ? Definitively, yes. I think the database format must be stable between micro (bugfix) and minor (feature enhancement) releases. For major releases it is acceptable to change the format and to provide a migration tool. This is exactly what I am trying to get consensus on. The DB format impacts compatibility and so it's something we must consider based on our versioning scheme. But with this milestone approach we only have to lock in the format when we reach the RC stage. Please keep in mind that the current JDBM format is not final yet. We introduced the RDN index for fast moddn operation, but still have the oneLevel, subLevel, and alias indices that are not updated in O(1). Good point. Yet these indices present a different problem entirely, actually it's only the subLevel index which is an issue. Quickly without diverting from this thread's central point let me jot down some immediate thoughts. History Background --- The DN index that was replaced with an RDN index gave us O(1) moddn operation speed. By not having to update all DN indices, due to a single RDN component index entry update we gained the speed (also stability/atomicity) advantage. The same does not apply to subLevel which maps the IDs of ancestors entries to descendants. The oneLevel index is not a worry (still an O(1) operation) since a moddn impacting a parent child relationship is a single update. Remaining Potential Performance Problem - Serious performance problems and issues with atomicity may still result from the subLevel index with moddn operations since this can impact millions of index entries. Unfortunately, unlike the RDN index/DN index technique, we don't have the same simple solution. Once the ancestor, to descendent relationship is broken with a moddn, these index entries must be updated. -- Alex Karasulu My Blog :: http://www.jroller.com/akarasulu/ Apache Directory Server :: http://directory.apache.org Apache MINA :: http://mina.apache.org To set up a meeting with me: http://tungle.me/AlexKarasulu
Re: [DISCUSS] [Release Scheme] Contract/Policy with users for releases
On 1/6/11 2:15 PM, Alex Karasulu wrote: On Thu, Jan 6, 2011 at 12:42 PM, Stefan Seelmannseelm...@apache.orgwrote: I would get the Database Format and Configuration out of the equation. It's up to us to provide tools to migrate from one format to the other. Don't get me wrong : when I say that configuration is out of the equation, I mean that the configuration can change, not its format (ie switching from XML to DIT is possible between to major releases, not between two minor releases). Will this be transparent to the user? Meaning can he just upgrade the software and the migration will occur without any change in their workflow, or anything noticeable in performance, wait time on startup? More specifically: (1) Does the user have to run a tool to migrate from one version to the next ? Definitively, yes. I think the database format must be stable between micro (bugfix) and minor (feature enhancement) releases. For major releases it is acceptable to change the format and to provide a migration tool. This is exactly what I am trying to get consensus on. The DB format impacts compatibility and so it's something we must consider based on our versioning scheme. But with this milestone approach we only have to lock in the format when we reach the RC stage. I think we have now reached a consensus. Can we formally switch to this scheme ? Is a vote necessary ? I don't know, but may be a report on a separate thread, plus an update on the web site could help. I know that those long mails with many things being discussed are hard to follow. A short mail stating we are switching to the eclipse version scheme would help here. -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
Re: [DISCUSS] [Release Scheme] Contract/Policy with users for releases
Sent from my iPhone On Jan 6, 2011, at 4:46 PM, Emmanuel Lecharny elecha...@gmail.com wrote: On 1/6/11 2:15 PM, Alex Karasulu wrote: On Thu, Jan 6, 2011 at 12:42 PM, Stefan Seelmannseelm...@apache.orgwrote: I would get the Database Format and Configuration out of the equation. It's up to us to provide tools to migrate from one format to the other. Don't get me wrong : when I say that configuration is out of the equation, I mean that the configuration can change, not its format (ie switching from XML to DIT is possible between to major releases, not between two minor releases). Will this be transparent to the user? Meaning can he just upgrade the software and the migration will occur without any change in their workflow, or anything noticeable in performance, wait time on startup? More specifically: (1) Does the user have to run a tool to migrate from one version to the next ? Definitively, yes. I think the database format must be stable between micro (bugfix) and minor (feature enhancement) releases. For major releases it is acceptable to change the format and to provide a migration tool. This is exactly what I am trying to get consensus on. The DB format impacts compatibility and so it's something we must consider based on our versioning scheme. But with this milestone approach we only have to lock in the format when we reach the RC stage. I think we have now reached a consensus. Can we formally switch to this scheme ? Is a vote necessary ? I don't know, but may be a report on a separate thread, plus an update on the web site could help. We can just sound off approval and announce or be more official with a vote: your call. I know that those long mails with many things being discussed are hard to follow. A short mail stating we are switching to the eclipse version scheme would help here. -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
[DISCUSS] [Release Scheme] Contract/Policy with users for releases
Hi all, Let's start off with basics by discussing what our contracts are WRT API's, and releases with our users. We can throw out the past focusing on the future to save time since 2.0 will effectively be a new era. This 2.0 release I'm gathering is the first stable, serious, enterprise ready major release of ApacheDS. 1.0 was kind of a toy considering all it's faults and shortcomings so the two situations are not completely the same. We have to select a release scheme. Based on the scheme we select, we have to adhere to the rules of that scheme. This is like picking what our contract with users of the server will be for release compatibility. So when considering compatibility we have to consider several things besides just APIs and SPIs: o Database Format o Schema o Replication Mechanism o Configuration o API Compatibility o Plugins - We have pseudo plugins like Partitions, Interceptors and Handlers that users can alter which involve SPIs. So based the scheme we select we have to define policies for these interfaces. I am calling anything that is exposed to the users as interfaces like DB format for example. We have the following choices for schemes: 1. Milestone Scheme (Eclipse) 2. Traditional major.minor.micro Scheme 3. maj.min.mic with Odd Numbered Versions for Development Releases (Old Linux Kernel) 4. Modern Linux Versioning Scheme Se let's start off talking about which scheme we like best and why along with pros and cons taking into account realistically how we work. Regards, -- Alex Karasulu My Blog :: http://www.jroller.com/akarasulu/ Apache Directory Server :: http://directory.apache.org Apache MINA :: http://mina.apache.org To set up a meeting with me: http://tungle.me/AlexKarasulu
Re: [DISCUSS] [Release Scheme] Contract/Policy with users for releases
On Wed, Jan 5, 2011 at 7:49 PM, Alex Karasulu akaras...@apache.org wrote: Hi all, Let's start off with basics by discussing what our contracts are WRT API's, and releases with our users. We can throw out the past focusing on the future to save time since 2.0 will effectively be a new era. This 2.0 release I'm gathering is the first stable, serious, enterprise ready major release of ApacheDS. 1.0 was kind of a toy considering all it's faults and shortcomings so the two situations are not completely the same. We have to select a release scheme. Based on the scheme we select, we have to adhere to the rules of that scheme. This is like picking what our contract with users of the server will be for release compatibility. So when considering compatibility we have to consider several things besides just APIs and SPIs: o Database Format o Schema o Replication Mechanism o Configuration o API Compatibility o Plugins - We have pseudo plugins like Partitions, Interceptors and Handlers that users can alter which involve SPIs. So based the scheme we select we have to define policies for these interfaces. I am calling anything that is exposed to the users as interfaces like DB format for example. We have the following choices for schemes: 1. Milestone Scheme (Eclipse) 2. Traditional major.minor.micro Scheme 3. maj.min.mic with Odd Numbered Versions for Development Releases (Old Linux Kernel) 4. Modern Linux Versioning Scheme Se let's start off talking about which scheme we like best and why along with pros and cons taking into account realistically how we work. There are many more schemes out there to choose from. Feel free to add to this list below. -- Alex Karasulu My Blog :: http://www.jroller.com/akarasulu/ Apache Directory Server :: http://directory.apache.org Apache MINA :: http://mina.apache.org To set up a meeting with me: http://tungle.me/AlexKarasulu
Re: [DISCUSS] [Release Scheme] Contract/Policy with users for releases
1. Milestone Scheme (Eclipse) to further explain that one, those are just the public versions that people consume...under the hood all of the bundles follow the osgi versioning convention of major.minor.bugfix.qualifier so it looks like 7.2.2.v20101205 or some variation there of. if you guys are targeting osgi at any point then I would recommend you just stick with that scheme, similar to how we do versioning in jetty which works pretty well. Since you have eclipse plugins you ought to build those with maven + tycho and have a similar and sane versioning system. building with maven the -SNAPSHOT is turned into the qualifier so we just go with 7.3.0-SNAPSHOT and so on til a release and then we go with v'year'month'day...we use the v so that it sorts correct with things like 7.3.0.RC0, etc.. cheers, jesse -- jesse mcconnell jesse.mcconn...@gmail.com On Wed, Jan 5, 2011 at 11:51, Alex Karasulu akaras...@apache.org wrote: On Wed, Jan 5, 2011 at 7:49 PM, Alex Karasulu akaras...@apache.org wrote: Hi all, Let's start off with basics by discussing what our contracts are WRT API's, and releases with our users. We can throw out the past focusing on the future to save time since 2.0 will effectively be a new era. This 2.0 release I'm gathering is the first stable, serious, enterprise ready major release of ApacheDS. 1.0 was kind of a toy considering all it's faults and shortcomings so the two situations are not completely the same. We have to select a release scheme. Based on the scheme we select, we have to adhere to the rules of that scheme. This is like picking what our contract with users of the server will be for release compatibility. So when considering compatibility we have to consider several things besides just APIs and SPIs: o Database Format o Schema o Replication Mechanism o Configuration o API Compatibility o Plugins - We have pseudo plugins like Partitions, Interceptors and Handlers that users can alter which involve SPIs. So based the scheme we select we have to define policies for these interfaces. I am calling anything that is exposed to the users as interfaces like DB format for example. We have the following choices for schemes: 1. Milestone Scheme (Eclipse) 2. Traditional major.minor.micro Scheme 3. maj.min.mic with Odd Numbered Versions for Development Releases (Old Linux Kernel) 4. Modern Linux Versioning Scheme Se let's start off talking about which scheme we like best and why along with pros and cons taking into account realistically how we work. There are many more schemes out there to choose from. Feel free to add to this list below. -- Alex Karasulu My Blog :: http://www.jroller.com/akarasulu/ Apache Directory Server :: http://directory.apache.org Apache MINA :: http://mina.apache.org To set up a meeting with me: http://tungle.me/AlexKarasulu
Re: [DISCUSS] [Release Scheme] Contract/Policy with users for releases
On 1/5/11 6:49 PM, Alex Karasulu wrote: Hi all, Let's start off with basics by discussing what our contracts are WRT API's, and releases with our users. We can throw out the past focusing on the future to save time since 2.0 will effectively be a new era. This 2.0 release I'm gathering is the first stable, serious, enterprise ready major release of ApacheDS. 1.0 was kind of a toy considering all it's faults and shortcomings so the two situations are not completely the same. We have to select a release scheme. Based on the scheme we select, we have to adhere to the rules of that scheme. This is like picking what our contract with users of the server will be for release compatibility. So when considering compatibility we have to consider several things besides just APIs and SPIs: o Database Format o Schema o Replication Mechanism o Configuration o API Compatibility o Plugins - We have pseudo plugins like Partitions, Interceptors and Handlers that users can alter which involve SPIs. I would get the Database Format and Configuration out of the equation. It's up to us to provide tools to migrate from one format to the other. Don't get me wrong : when I say that configuration is out of the equation, I mean that the configuration can change, not its format (ie switching from XML to DIT is possible between to major releases, not between two minor releases). So based the scheme we select we have to define policies for these interfaces. I am calling anything that is exposed to the users as interfaces like DB format for example. We have the following choices for schemes: 1. Milestone Scheme (Eclipse) 2. Traditional major.minor.micro Scheme 3. maj.min.mic with Odd Numbered Versions for Development Releases (Old Linux Kernel) 4. Modern Linux Versioning Scheme Se let's start off talking about which scheme we like best and why along with pros and cons taking into account realistically how we work. Eclipse uses Milestone to express the fact that they are targeting a major release, and each milestone is one step toward this major release. A milestone can include new features, or API refactoring. Milestone are not exclusive to any other version scheme. There are also some exotic schemes out there like maj.min.mic-alpha/beta/NNN : not anymore frequently use those days. IMO, they are more like milestones It's mainly a question of personal preference here, the idea is to avoid bikeshed painting debates. My preference goes to : - maj.min.mic where mic are for bug fixes, min are for features additions (and potentially minor API changes) and maj are for large refactoring. - using Milestone works well when combined with this scheme, for pre-major. - when all the features have been added, RC can be issued So to summarize : 1.0.0 - 1.0.1 - 1.0.2... at any point, we can branch, if some new feature is added or if some minor API refactoring is absolutely needed : 1.1.0 - 1.1.1 - 1.1.2 ... When preparing a 2.0.0 : 2.0-M1 - 2.0-M2 - ... 2.0-M5 When feature completion and API stabilization is reached : 2.0-M5 - 2.0-RC1 - 2.0-RC2 ... When RC have been stabilized and tested, then we can release a major : 2.0-RC5 - 2.0.0 and back to the beginning. Regards, -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
Re: [DISCUSS] [Release Scheme] Contract/Policy with users for releases
On Wed, Jan 5, 2011 at 8:06 PM, Jesse McConnell jesse.mcconn...@gmail.comwrote: 1. Milestone Scheme (Eclipse) to further explain that one, those are just the public versions that people consume...under the hood all of the bundles follow the osgi versioning convention of major.minor.bugfix.qualifier so it looks like 7.2.2.v20101205 or some variation there of. I like this a lot. This way there's a product release version yet all component bundles can be versioned separately. This way their releases can occur independently of the product to allow for updates. This sounds more granular to me. Different component bundles will change at different rates and to allow this in a manageable way is wonderful. if you guys are targeting osgi at any point then I would recommend you just stick with that scheme, similar to how we do versioning in jetty which works pretty well. OSGi is something we've been considering for the past 7 years :-). However it's definitely not something we're going to do for the 2.0 server release. I would however like to make shared libraries into bundles for the following reasons: (1) Helps think better about dependencies interfaces and implementations with public and private classes (exported verse bundle private). This will help us set solid boundaries around API's. (2) ApacheDS 3.0 work can be begun to leverage OSGi without having to mess around with the shared and ldap-api artifacts. The less we touch after releasing 1.0 versions the better. The goal is not to have to manage multiple versions of an API as Emm mentioned. Since you have eclipse plugins you ought to build those with maven + tycho and have a similar and sane versioning system. I talked with Pierre about it. As a side point because of the way the build in Studio is setup, we're unable at this point to take advantage of IDE refactoring since dependencies are on bundle jars rather than on projects themselves. Do you know if using Maven + Tycho will help with this specific problem? I'm asking this because it might spare some work for us when we refactor shared which Studio depends on. building with maven the -SNAPSHOT is turned into the qualifier so we just go with 7.3.0-SNAPSHOT and so on til a release and then we go with v'year'month'day...we use the v so that it sorts correct with things like 7.3.0.RC0, etc.. Thanks for the input. For the record I too think #1 is the best option for us going forward. On Wed, Jan 5, 2011 at 11:51, Alex Karasulu akaras...@apache.org wrote: On Wed, Jan 5, 2011 at 7:49 PM, Alex Karasulu akaras...@apache.org wrote: Hi all, Let's start off with basics by discussing what our contracts are WRT API's, and releases with our users. We can throw out the past focusing on the future to save time since 2.0 will effectively be a new era. This 2.0 release I'm gathering is the first stable, serious, enterprise ready major release of ApacheDS. 1.0 was kind of a toy considering all it's faults and shortcomings so the two situations are not completely the same. We have to select a release scheme. Based on the scheme we select, we have to adhere to the rules of that scheme. This is like picking what our contract with users of the server will be for release compatibility. So when considering compatibility we have to consider several things besides just APIs and SPIs: o Database Format o Schema o Replication Mechanism o Configuration o API Compatibility o Plugins - We have pseudo plugins like Partitions, Interceptors and Handlers that users can alter which involve SPIs. So based the scheme we select we have to define policies for these interfaces. I am calling anything that is exposed to the users as interfaces like DB format for example. We have the following choices for schemes: 1. Milestone Scheme (Eclipse) 2. Traditional major.minor.micro Scheme 3. maj.min.mic with Odd Numbered Versions for Development Releases (Old Linux Kernel) 4. Modern Linux Versioning Scheme Se let's start off talking about which scheme we like best and why along with pros and cons taking into account realistically how we work. There are many more schemes out there to choose from. Feel free to add to this list below. -- Alex Karasulu My Blog :: http://www.jroller.com/akarasulu/ Apache Directory Server :: http://directory.apache.org Apache MINA :: http://mina.apache.org To set up a meeting with me: http://tungle.me/AlexKarasulu -- Alex Karasulu My Blog :: http://www.jroller.com/akarasulu/ Apache Directory Server :: http://directory.apache.org Apache MINA :: http://mina.apache.org To set up a meeting with me: http://tungle.me/AlexKarasulu
Re: [DISCUSS] [Release Scheme] Contract/Policy with users for releases
Since you have eclipse plugins you ought to build those with maven + tycho and have a similar and sane versioning system. I talked with Pierre about it. As a side point because of the way the build in Studio is setup, we're unable at this point to take advantage of IDE refactoring since dependencies are on bundle jars rather than on projects themselves. Do you know if using Maven + Tycho will help with this specific problem? I'm asking this because it might spare some work for us when we refactor shared which Studio depends on. when I am working on the jetty wtp plugin I am able to have all 3 plugins open and refactor between them, I just let m2eclipse import and do the right thing the combination of m2eclipse + maven3 + tycho is quite nice cheers, jesse
Re: [DISCUSS] [Release Scheme] Contract/Policy with users for releases
On Wed, Jan 5, 2011 at 8:13 PM, Emmanuel Lecharny elecha...@gmail.comwrote: On 1/5/11 6:49 PM, Alex Karasulu wrote: Hi all, Let's start off with basics by discussing what our contracts are WRT API's, and releases with our users. We can throw out the past focusing on the future to save time since 2.0 will effectively be a new era. This 2.0 release I'm gathering is the first stable, serious, enterprise ready major release of ApacheDS. 1.0 was kind of a toy considering all it's faults and shortcomings so the two situations are not completely the same. We have to select a release scheme. Based on the scheme we select, we have to adhere to the rules of that scheme. This is like picking what our contract with users of the server will be for release compatibility. So when considering compatibility we have to consider several things besides just APIs and SPIs: o Database Format o Schema o Replication Mechanism o Configuration o API Compatibility o Plugins - We have pseudo plugins like Partitions, Interceptors and Handlers that users can alter which involve SPIs. I would get the Database Format and Configuration out of the equation. It's up to us to provide tools to migrate from one format to the other. Don't get me wrong : when I say that configuration is out of the equation, I mean that the configuration can change, not its format (ie switching from XML to DIT is possible between to major releases, not between two minor releases). Will this be transparent to the user? Meaning can he just upgrade the software and the migration will occur without any change in their workflow, or anything noticeable in performance, wait time on startup? More specifically: (1) Does the user have to run a tool to migrate from one version to the next ? (2) If a user has 100 Million entries and there's a migration operation running with this take say a few hours to start up the server? So based the scheme we select we have to define policies for these interfaces. I am calling anything that is exposed to the users as interfaces like DB format for example. We have the following choices for schemes: 1. Milestone Scheme (Eclipse) 2. Traditional major.minor.micro Scheme 3. maj.min.mic with Odd Numbered Versions for Development Releases (Old Linux Kernel) 4. Modern Linux Versioning Scheme Se let's start off talking about which scheme we like best and why along with pros and cons taking into account realistically how we work. Eclipse uses Milestone to express the fact that they are targeting a major release, and each milestone is one step toward this major release. A milestone can include new features, or API refactoring. OK so don't separate development features into different branches. I think this is better as well since this stable verses dev branch thing did not work so well for us in the past. People are very familiar with this model as well so there's less to explain. Plus eventually when we introduce OSGi into the picture this will serve very handy as Jesse pointed out. Milestone are not exclusive to any other version scheme. There are also some exotic schemes out there like maj.min.mic-alpha/beta/NNN : not anymore frequently use those days. IMO, they are more like milestones +1 It's mainly a question of personal preference here, the idea is to avoid bikeshed painting debates. +1 My preference goes to : - maj.min.mic where mic are for bug fixes, min are for features additions (and potentially minor API changes) and maj are for large refactoring. This is the case for this scheme for the components of the project. - using Milestone works well when combined with this scheme, for pre-major. This is the case for this scheme for the public product version which is a group of components, bundles. - when all the features have been added, RC can be issued If we do this can we just follow what Eclipse does exactly instead of adding our own customization. It's just nice to reference their way and not have to document anything extra. If this RC thing is part of their scheme then lets use it. So to summarize : 1.0.0 - 1.0.1 - 1.0.2... at any point, we can branch, if some new feature is added or if some minor API refactoring is absolutely needed : 1.1.0 - 1.1.1 - 1.1.2 ... When preparing a 2.0.0 : 2.0-M1 - 2.0-M2 - ... 2.0-M5 When feature completion and API stabilization is reached : 2.0-M5 - 2.0-RC1 - 2.0-RC2 ... When RC have been stabilized and tested, then we can release a major : 2.0-RC5 - 2.0.0 and back to the beginning. Hmmm OK I see now the switch from M* to RC* : it's the barrier for stopping new features and API changes. OK I like it but is this what these guys do in eclipse? -- Alex Karasulu My Blog :: http://www.jroller.com/akarasulu/ Apache Directory Server :: http://directory.apache.org Apache MINA :: http://mina.apache.org To set up a meeting with me: http://tungle.me/AlexKarasulu
Re: [DISCUSS] [Release Scheme] Contract/Policy with users for releases
On Wed, Jan 5, 2011 at 9:16 PM, Jesse McConnell jesse.mcconn...@gmail.comwrote: Since you have eclipse plugins you ought to build those with maven + tycho and have a similar and sane versioning system. I talked with Pierre about it. As a side point because of the way the build in Studio is setup, we're unable at this point to take advantage of IDE refactoring since dependencies are on bundle jars rather than on projects themselves. Do you know if using Maven + Tycho will help with this specific problem? I'm asking this because it might spare some work for us when we refactor shared which Studio depends on. when I am working on the jetty wtp plugin I am able to have all 3 plugins open and refactor between them, I just let m2eclipse import and do the right thing the combination of m2eclipse + maven3 + tycho is quite nice Ahh cool. PAM, and Seelman is this something you might want to try or leave out for later? I just cringe at the thought of your having to manually update Studio again after we reorg shared. -- Alex Karasulu My Blog :: http://www.jroller.com/akarasulu/ Apache Directory Server :: http://directory.apache.org Apache MINA :: http://mina.apache.org To set up a meeting with me: http://tungle.me/AlexKarasulu
Re: [DISCUSS] [Release Scheme] Contract/Policy with users for releases
On 1/5/11 8:08 PM, Alex Karasulu wrote: On Wed, Jan 5, 2011 at 8:06 PM, Jesse McConnell jesse.mcconn...@gmail.comwrote: 1. Milestone Scheme (Eclipse) to further explain that one, those are just the public versions that people consume...under the hood all of the bundles follow the osgi versioning convention of major.minor.bugfix.qualifier so it looks like 7.2.2.v20101205 or some variation there of. I like this a lot. This way there's a product release version yet all component bundles can be versioned separately. This way their releases can occur independently of the product to allow for updates. This sounds more granular to me. Different component bundles will change at different rates and to allow this in a manageable way is wonderful. +1 too. I'm not convinced about the need to have those vDate stuff, but it does not cost anything, so I buy it. if you guys are targeting osgi at any point then I would recommend you just stick with that scheme, similar to how we do versioning in jetty which works pretty well. OSGi is something we've been considering for the past 7 years :-). However it's definitely not something we're going to do for the 2.0 server release. If we go for miletsones (ie 2.0-Mx), then I have no problem to try to get OSGi injected. It may postpone the 2.0-GA release, but frankly, I don't think it will cost a lot. Add to this that many OSGi aware peeps are ready to give an hands here. Something to think about, IMO. building with maven the -SNAPSHOT is turned into the qualifier so we just go with 7.3.0-SNAPSHOT and so on til a release and then we go with v'year'month'day...we use the v so that it sorts correct with things like 7.3.0.RC0, etc.. Thanks for the input. For the record I too think #1 is the best option for us going forward. Question : how do we propagate the 7.3.0-xxyz versions ? Right now, releasing is a damn complex process which costs us one week (well, let's say 4 days if everything goes fine, vote included). Or is this just equivalent to a nightly build ? -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
Re: [DISCUSS] [Release Scheme] Contract/Policy with users for releases
On Wed, Jan 5, 2011 at 10:15 PM, Emmanuel Lecharny elecha...@gmail.comwrote: On 1/5/11 8:08 PM, Alex Karasulu wrote: On Wed, Jan 5, 2011 at 8:06 PM, Jesse McConnell jesse.mcconn...@gmail.comwrote: 1. Milestone Scheme (Eclipse) to further explain that one, those are just the public versions that people consume...under the hood all of the bundles follow the osgi versioning convention of major.minor.bugfix.qualifier so it looks like 7.2.2.v20101205 or some variation there of. I like this a lot. This way there's a product release version yet all component bundles can be versioned separately. This way their releases can occur independently of the product to allow for updates. This sounds more granular to me. Different component bundles will change at different rates and to allow this in a manageable way is wonderful. +1 too. I'm not convinced about the need to have those vDate stuff, but it does not cost anything, so I buy it. +1 if you guys are targeting osgi at any point then I would recommend you just stick with that scheme, similar to how we do versioning in jetty which works pretty well. OSGi is something we've been considering for the past 7 years :-). However it's definitely not something we're going to do for the 2.0 server release. If we go for miletsones (ie 2.0-Mx), then I have no problem to try to get OSGi injected. It may postpone the 2.0-GA release, but frankly, I don't think it will cost a lot. Add to this that many OSGi aware peeps are ready to give an hands here. +1 then let's just do a 2.0-M1 release. This is great and gets users used to the new scheme. Plus we can modify the API without flipping out - the contract is clear to users, things will change. And you get the 2.0 advancing feeling that might help get more adoption into the picture. I'm liking this a lot! building with maven the -SNAPSHOT is turned into the qualifier so we just go with 7.3.0-SNAPSHOT and so on til a release and then we go with v'year'month'day...we use the v so that it sorts correct with things like 7.3.0.RC0, etc.. Thanks for the input. For the record I too think #1 is the best option for us going forward. Question : how do we propagate the 7.3.0-xxyz versions ? Right now, releasing is a damn complex process which costs us one week (well, let's say 4 days if everything goes fine, vote included). Or is this just equivalent to a nightly build ? I really have to read this eclipse link you put up. I've never released the Eclipse way. Off the cuff with common sense I am thinking we have for example 2.0.0-M1-cmajor.cminor.cmicro for each component where the, cmajor = component major version, cminor = component minor version, and cmicro = component micro version Adjusting this in our build is easy I think. We can play with it down the line if the others agree with this new scheme. -- Alex Karasulu My Blog :: http://www.jroller.com/akarasulu/ Apache Directory Server :: http://directory.apache.org Apache MINA :: http://mina.apache.org To set up a meeting with me: http://tungle.me/AlexKarasulu
Re: [DISCUSS] [Release Scheme] Contract/Policy with users for releases
On Wed, Jan 5, 2011 at 10:06 PM, Emmanuel Lécharny elecha...@apache.orgwrote: On 1/5/11 8:17 PM, Alex Karasulu wrote: On Wed, Jan 5, 2011 at 8:13 PM, Emmanuel Lecharnyelecha...@gmail.com wrote: On 1/5/11 6:49 PM, Alex Karasulu wrote: So when considering compatibility we have to consider several things besides just APIs and SPIs: o Database Format o Schema o Replication Mechanism o Configuration o API Compatibility o Plugins - We have pseudo plugins like Partitions, Interceptors and Handlers that users can alter which involve SPIs. I would get the Database Format and Configuration out of the equation. It's up to us to provide tools to migrate from one format to the other. Don't get me wrong : when I say that configuration is out of the equation, I mean that the configuration can change, not its format (ie switching from XML to DIT is possible between to major releases, not between two minor releases). Will this be transparent to the user? Meaning can he just upgrade the software and the migration will occur without any change in their workflow, or anything noticeable in performance, wait time on startup? More specifically: (1) Does the user have to run a tool to migrate from one version to the next ? Definitively, yes. This is a bit worrisome to me but I cannot figure out why yet. Something in my gut that I have not translated into real consequences yet. I can see advantages with such a tool which allows us to change these formats and configurations. But the disadvantage is the one off of having to figure out if you need the tool with every minor or micro release. It's yet another one off and the tool make take a day to run depending on how big the DIB is. However with modularity and OSGi these points become less problematic. If this is set as the policy then this tool must always be provided. Those who push this as the way then need to be held responsible for providing the tool when needed. That sort of goes against the community dynamic: it's going to be a must do for those accepting the policy. So for those who want it, it should be provided by them on demand before any release takes place. That's kind of harsh. Instead if we respect the DB format and just release with the right versioning schemes then we should be OK. If compatibility breaks then a major release can be done and tools can still be provided to migrate optionally without requirement. See my point here? (2) If a user has 100 Million entries and there's a migration operation running with this take say a few hours to start up the server? This should be a low level tool, so it should act on the Backend interface level Yeah but it can still take days depending on the DB size but should not be an issue with 90% of our users. -- Alex Karasulu My Blog :: http://www.jroller.com/akarasulu/ Apache Directory Server :: http://directory.apache.org Apache MINA :: http://mina.apache.org To set up a meeting with me: http://tungle.me/AlexKarasulu
Re: [DISCUSS] [Release Scheme] Contract/Policy with users for releases
On 1/5/11 9:49 PM, Alex Karasulu wrote: On Wed, Jan 5, 2011 at 10:06 PM, Emmanuel Lécharnyelecha...@apache.orgwrote: On 1/5/11 8:17 PM, Alex Karasulu wrote: On Wed, Jan 5, 2011 at 8:13 PM, Emmanuel Lecharnyelecha...@gmail.com wrote: On 1/5/11 6:49 PM, Alex Karasulu wrote: So when considering compatibility we have to consider several things besides just APIs and SPIs: o Database Format o Schema o Replication Mechanism o Configuration o API Compatibility o Plugins - We have pseudo plugins like Partitions, Interceptors and Handlers that users can alter which involve SPIs. I would get the Database Format and Configuration out of the equation. It's up to us to provide tools to migrate from one format to the other. Don't get me wrong : when I say that configuration is out of the equation, I mean that the configuration can change, not its format (ie switching from XML to DIT is possible between to major releases, not between two minor releases). Will this be transparent to the user? Meaning can he just upgrade the software and the migration will occur without any change in their workflow, or anything noticeable in performance, wait time on startup? More specifically: (1) Does the user have to run a tool to migrate from one version to the next ? Definitively, yes. This is a bit worrisome to me but I cannot figure out why yet. Something in my gut that I have not translated into real consequences yet. I can see advantages with such a tool which allows us to change these formats and configurations. But the disadvantage is the one off of having to figure out if you need the tool with every minor or micro release. It's yet another one off and the tool make take a day to run depending on how big the DIB is. We are not likely to change those DB formats often. We did it 3 times in 6 years, and it was for some major refactoring, I can't foresee any small modification that could be needed soon. However, I do think that at some point, this might be necessary to ofter such a tool. It's too easy to rely on our user to get their data exported and reimported using a LDIF file, as it has some consequence : the operational attributes will be modified. However with modularity and OSGi these points become less problematic. If this is set as the policy then this tool must always be provided. Those who push this as the way then need to be held responsible for providing the tool when needed. That sort of goes against the community dynamic: it's going to be a must do for those accepting the policy. Same opinion here. So for those who want it, it should be provided by them on demand before any release takes place. That's kind of harsh. Instead if we respect the DB format and just release with the right versioning schemes then we should be OK. If compatibility breaks then a major release can be done and tools can still be provided to migrate optionally without requirement. See my point here? yes. But again, such a modification is not likely to happen, is not part of the contract, and can be manage if we provide a migration tool. It's quite a common practice in the industry, and should not be a burden. It should even not require a major release, IMO. (2) If a user has 100 Million entries and there's a migration operation running with this take say a few hours to start up the server? This should be a low level tool, so it should act on the Backend interface level Yeah but it can still take days depending on the DB size but should not be an issue with 90% of our users. The day we have a user with 100 million entries, trust me, we will have other issues than just dealing with the migration of its database :) -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
Re: [DISCUSS] [Release Scheme] Contract/Policy with users for releases
On Wed, Jan 5, 2011 at 11:18 PM, Emmanuel Lécharny elecha...@apache.orgwrote: On 1/5/11 9:49 PM, Alex Karasulu wrote: On Wed, Jan 5, 2011 at 10:06 PM, Emmanuel Lécharnyelecha...@apache.org wrote: On 1/5/11 8:17 PM, Alex Karasulu wrote: On Wed, Jan 5, 2011 at 8:13 PM, Emmanuel Lecharnyelecha...@gmail.com wrote: On 1/5/11 6:49 PM, Alex Karasulu wrote: So when considering compatibility we have to consider several things besides just APIs and SPIs: o Database Format o Schema o Replication Mechanism o Configuration o API Compatibility o Plugins - We have pseudo plugins like Partitions, Interceptors and Handlers that users can alter which involve SPIs. I would get the Database Format and Configuration out of the equation. It's up to us to provide tools to migrate from one format to the other. Don't get me wrong : when I say that configuration is out of the equation, I mean that the configuration can change, not its format (ie switching from XML to DIT is possible between to major releases, not between two minor releases). Will this be transparent to the user? Meaning can he just upgrade the software and the migration will occur without any change in their workflow, or anything noticeable in performance, wait time on startup? More specifically: (1) Does the user have to run a tool to migrate from one version to the next ? Definitively, yes. This is a bit worrisome to me but I cannot figure out why yet. Something in my gut that I have not translated into real consequences yet. I can see advantages with such a tool which allows us to change these formats and configurations. But the disadvantage is the one off of having to figure out if you need the tool with every minor or micro release. It's yet another one off and the tool make take a day to run depending on how big the DIB is. We are not likely to change those DB formats often. We did it 3 times in 6 years, and it was for some major refactoring, I can't foresee any small modification that could be needed soon. Yes that's probably the case especially after a GA and when we go MVCC that might alter the DB format, however MVCC would be another major release in itself. However, I do think that at some point, this might be necessary to ofter such a tool. It's too easy to rely on our user to get their data exported and reimported using a LDIF file, as it has some consequence : the operational attributes will be modified. If this is a low level partition tool then there might be ways around loosing things like timestamps and modifiers. However with modularity and OSGi these points become less problematic. If this is set as the policy then this tool must always be provided. Those who push this as the way then need to be held responsible for providing the tool when needed. That sort of goes against the community dynamic: it's going to be a must do for those accepting the policy. Same opinion here. So for those who want it, it should be provided by them on demand before any release takes place. That's kind of harsh. Instead if we respect the DB format and just release with the right versioning schemes then we should be OK. If compatibility breaks then a major release can be done and tools can still be provided to migrate optionally without requirement. See my point here? yes. But again, such a modification is not likely to happen, is not part of the contract, and can be manage if we provide a migration tool. It's quite a common practice in the industry, and should not be a burden. It should even not require a major release, IMO. I think it's debatable - again it's the contract with users. If this is going to be a project conducted with professionalism these kinds of policies are just as important to follow as test coverage or feature design. 2.0 is being targeted for the enterprise with the features put into it so things need to be tight. We can't be relaxed about shifting database formats and configurations between point releases. (2) If a user has 100 Million entries and there's a migration operation running with this take say a few hours to start up the server? This should be a low level tool, so it should act on the Backend interface level Yeah but it can still take days depending on the DB size but should not be an issue with 90% of our users. The day we have a user with 100 million entries, trust me, we will have other issues than just dealing with the migration of its database :) It does not matter if we have other issues, that's besides the point. Regardless of other possible issues it will take about 2 days to migrate and that's a long time. Why also bother building tools if we follow some conventions? -- Alex Karasulu My Blog :: http://www.jroller.com/akarasulu/ Apache Directory Server :: http://directory.apache.org Apache MINA :: http://mina.apache.org To set up a meeting with me: http://tungle.me
Re: [DISCUSS] [Release Scheme] Contract/Policy with users for releases
On 1/6/11 12:27 AM, Alex Karasulu wrote: On Wed, Jan 5, 2011 at 11:18 PM, Emmanuel Lécharnyelecha...@apache.orgwrote: The day we have a user with 100 million entries, trust me, we will have other issues than just dealing with the migration of its database :) It does not matter if we have other issues, that's besides the point. Regardless of other possible issues it will take about 2 days to migrate and that's a long time. Why also bother building tools if we follow some conventions? What I mean here is that we are unlikely to change the backend format anytime soon, and if we do so, except if it's marginal but mandatory (to fix a bug), then I'd rather vote a major version. -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
Re: [CONF] Apache Directory Development Guide to Directory Releases
P Sent from my iPhone On Oct 11, 2010, at 10:24 AM, conflue...@apache.org wrote: Guide to Directory Releases Page edited by Stefan Seelmann Changes (2) ... h2. Releasing Directory Projects and Making Release Announcements |Releasing Shared|[Releasing Skins|[Releasing Skins]| |Releasing Shared|[Releasing Shared]| |Releasing Daemon|[Releasing Daemon]| ... |Releasing ApacheDS Manuals|[Releasing ApacheDS Manuals]| |Releasing Studio|[Releasing Studio]| |Releasing Studio|[Releasing Studio Maven Plugin|[Releasing Studio Maven Plugin]| |Releases Announcements|[Release Announcements]| ... Full Content Introduction Releasing Apache Directory Projects can be involved. This release guide will walk you through the process first by preparing your maven and gpg configuration then by leading you through the release of various subprojects at Directory. There may be a few things you'll need to setup before you can release. This release guide is geared to work off of a UNIX based system that has gpg installed. If you're using Windows then I feel for you . We use Maven version 2.2.1 and JDK 1.6.0 to build all Directory subrojects even if they run on JDK 1.5. Maven Settings You'll need a settings section for the Nexus and people.apache.org servers with a password or a path to the SSH key used. Here's what my settings.xml file in ~/.m2 looks like: settings servers !-- To publish a snapshot of some part of Maven -- server idapache.snapshots.https/id usernameusername/username password/password /server !-- To publish a website using Maven -- server idapache.directory/id usernameusername/username privateKey/Users/username/.ssh/id_rsa/privateKey filePermissions664/filePermissions directoryPermissions775/directoryPermissions /server !-- To stage a release of some part of Maven -- server idapache.releases.https/id usernameusername/username password/password /server /servers profiles profile idapache-release/id properties gpg.passphrase/gpg.passphrase /properties /profile /profiles /settings Just replace your username, passwords and paths. Note that the username and password is your Apache LDAP account. You'll need to provide the passphrase in the settings.xml to access the gpg secret key installed on your host. This is due to a bug with the passphrase prompt in the maven-gpg-plugin. So unfortunately we must provide the passphrase in the settings.xml file in clear text. This should change in the future when this bug is fixed. Note that this passphrase is put into the release profile which we activate to properly sign and release the artifacts and poms via the release plugin. GPG Key All subprojects are configured to deploy signatures for the artifacts uploaded to the repository. The gpg plugin will check use the default gpg key for the user deploying the project with the release:perform directive of the release plugin. This will prompt you for the passphrase for the default key. If you do not have one setup the build will fail. You can generate and upload a PGP key to a PGP keyserver using the following commands: gpg --gen-key gpg --fingerprint gpg --keyserver subkeys.pgp.net --send-keys your key's id from last command Make sure to have created the .pgpkey in your p.a.o/~ directory and to have added your public key to the KEYS file. See also http://people.apache.org/~henkp/repo/faq.html#4 Releasing Directory Projects and Making Release Announcements Releasing Skins Releasing Skins Releasing Shared Releasing Shared Releasing Daemon Releasing Daemon Releasing ApacheDSReleasing ApacheDS Releasing ApacheDS ManualsReleasing ApacheDS Manuals Releasing Studio Releasing Studio Releasing Studio Maven Plugin Releasing Studio Maven Plugin Releases AnnouncementsRelease Announcements Promoted by third party (update information may need to be sent) ProjectReference Contact StudioOpen Source Rich client platform (RCP) applications n...@eclipse.org Change Notification Preferences View Online | View Changes
Re: [VOTE][RESULTS] Switching to Apache's Nexus repository infrastructure for next releases of the Directory project
Hi, The Jira issue has been resolved. Now, we NEED to deploy everything using Nexus and DO NOT deploy anything at the old location on people.apache.org. Thanks, Pierre-Arnaud On 26 mars 2010, at 10:19, Pierre-Arnaud Marcelot wrote: FYI, now that Apache DS is released, I opened a Jira for our move to Nexus. https://issues.apache.org/jira/browse/INFRA-2574 Regards, Pierre-Arnaud On 16 mars 2010, at 11:12, Pierre-Arnaud Marcelot wrote: The vote has been approved. Here are the results: 5 +1 votes: - Felix Knecht - Emmanuel Lécharny - Kiran Ayyagari - Pierre-Arnaud Marcelot - Stefan Seelmann 1 ±0 abstention vote: - Alex Karasulu No -1 vote. The next step in the process to move to the Nexus infrastructure is now to create a Jira as sub-task of INFRA-1896 [1]. Shall I wait for the ongoing vote of the release of Apache DS 1.5.6 to be closed and the artifacts released before asking to move to Nexus ? WDYT ? Regards, Pierre-Arnaud [1] - https://issues.apache.org/jira/browse/INFRA-1896 On 12 mars 2010, at 13:32, Pierre-Arnaud Marcelot wrote: Hi Stefan and Emmanuel, As you've started to +1 the idea, maybe it would be better to start a real formal vote. So here it is. [ ] +1 - Let's switch to Apache's Nexus repository infrastructure for the next releases of the Directory project [ ] ±0 - Abstain [ ] -1 - Let's keep our current deployment mechanism on people.apache.org Vote is opened for 72 hours. Thanks, Pierre-Arnaud On 12 mars 2010, at 07:45, Stefan Seelmann wrote: I use Nexus in my current project as repository and it works very well. So my +1 for that step. Kind Regards, Stefan On 12 mars 2010, at 09:38, Emmanuel Lecharny wrote: +1 too. If it offers a better support for our releases, I don't see why we should not switch.
Re: [VOTE][RESULTS] Switching to Apache's Nexus repository infrastructure for next releases of the Directory project
Hi, Just to let you know that I did a little test this morning. I deployed artifacts from a testing project with multiple sub-projects. Everything went fine and I was able to deploy the artifacts on Nexus. Once on Nexus, I had the choice to drop the deployed artifacts or promote them to the main repository. I dropped them since they were only here for testing purposes. We are currenlty finishing the work on the 1.5.3 release of Studio and will probably be ready to propose a vote today. We will use the Nexus for voting this release and we'll update the release documentation once the process is completely validated. Regards, Pierre-Arnaud On 29 mars 2010, at 09:36, Pierre-Arnaud Marcelot wrote: Hi, The Jira issue has been resolved. Now, we NEED to deploy everything using Nexus and DO NOT deploy anything at the old location on people.apache.org. Thanks, Pierre-Arnaud On 26 mars 2010, at 10:19, Pierre-Arnaud Marcelot wrote: FYI, now that Apache DS is released, I opened a Jira for our move to Nexus. https://issues.apache.org/jira/browse/INFRA-2574 Regards, Pierre-Arnaud On 16 mars 2010, at 11:12, Pierre-Arnaud Marcelot wrote: The vote has been approved. Here are the results: 5 +1 votes: - Felix Knecht - Emmanuel Lécharny - Kiran Ayyagari - Pierre-Arnaud Marcelot - Stefan Seelmann 1 ±0 abstention vote: - Alex Karasulu No -1 vote. The next step in the process to move to the Nexus infrastructure is now to create a Jira as sub-task of INFRA-1896 [1]. Shall I wait for the ongoing vote of the release of Apache DS 1.5.6 to be closed and the artifacts released before asking to move to Nexus ? WDYT ? Regards, Pierre-Arnaud [1] - https://issues.apache.org/jira/browse/INFRA-1896 On 12 mars 2010, at 13:32, Pierre-Arnaud Marcelot wrote: Hi Stefan and Emmanuel, As you've started to +1 the idea, maybe it would be better to start a real formal vote. So here it is. [ ] +1 - Let's switch to Apache's Nexus repository infrastructure for the next releases of the Directory project [ ] ±0 - Abstain [ ] -1 - Let's keep our current deployment mechanism on people.apache.org Vote is opened for 72 hours. Thanks, Pierre-Arnaud On 12 mars 2010, at 07:45, Stefan Seelmann wrote: I use Nexus in my current project as repository and it works very well. So my +1 for that step. Kind Regards, Stefan On 12 mars 2010, at 09:38, Emmanuel Lecharny wrote: +1 too. If it offers a better support for our releases, I don't see why we should not switch.
Re: [VOTE][RESULTS] Switching to Apache's Nexus repository infrastructure for next releases of the Directory project
Hi Pierre, On Mon, Mar 29, 2010 at 3:11 PM, Pierre-Arnaud Marcelot p...@marcelot.netwrote: Hi, Just to let you know that I did a little test this morning. I deployed artifacts from a testing project with multiple sub-projects. Everything went fine and I was able to deploy the artifacts on Nexus. Once on Nexus, I had the choice to drop the deployed artifacts or promote them to the main repository. I dropped them since they were only here for testing purposes. We are currenlty finishing the work on the 1.5.3 release of Studio and will probably be ready to propose a vote today. We will use the Nexus for voting this release and we'll update the release documentation once the process is completely validated. Is there some documentation in existence for this and/or can we update our deployment wiki page to show people how to deploy using nexus. If anything maybe we can add a link etc. Just asking cuz I want to be able to use this later but don't have the brain cycles now to figure it out. Regards, Alex On 29 mars 2010, at 09:36, Pierre-Arnaud Marcelot wrote: Hi, The Jira issue has been resolved. Now, we NEED to deploy everything using Nexus and DO NOT deploy anything at the old location on people.apache.org. Thanks, Pierre-Arnaud On 26 mars 2010, at 10:19, Pierre-Arnaud Marcelot wrote: FYI, now that Apache DS is released, I opened a Jira for our move to Nexus. https://issues.apache.org/jira/browse/INFRA-2574 Regards, Pierre-Arnaud On 16 mars 2010, at 11:12, Pierre-Arnaud Marcelot wrote: The vote has been approved. Here are the results: 5 +1 votes: - Felix Knecht - Emmanuel Lécharny - Kiran Ayyagari - Pierre-Arnaud Marcelot - Stefan Seelmann 1 ±0 abstention vote: - Alex Karasulu No -1 vote. The next step in the process to move to the Nexus infrastructure is now to create a Jira as sub-task of INFRA-1896 [1]. Shall I wait for the ongoing vote of the release of Apache DS 1.5.6 to be closed and the artifacts released before asking to move to Nexus ? WDYT ? Regards, Pierre-Arnaud [1] - https://issues.apache.org/jira/browse/INFRA-1896 On 12 mars 2010, at 13:32, Pierre-Arnaud Marcelot wrote: Hi Stefan and Emmanuel, As you've started to +1 the idea, maybe it would be better to start a real formal vote. So here it is. [ ] +1 - Let's switch to Apache's Nexus repository infrastructure for the next releases of the Directory project [ ] ±0 - Abstain [ ] -1 - Let's keep our current deployment mechanism on people.apache.org Vote is opened for 72 hours. Thanks, Pierre-Arnaud On 12 mars 2010, at 07:45, Stefan Seelmann wrote: I use Nexus in my current project as repository and it works very well. So my +1 for that step. Kind Regards, Stefan On 12 mars 2010, at 09:38, Emmanuel Lecharny wrote: +1 too. If it offers a better support for our releases, I don't see why we should not switch. -- Alex Karasulu My Blog :: http://www.jroller.com/akarasulu/ Apache Directory Server :: http://directory.apache.org Apache MINA :: http://mina.apache.org To set up a meeting with me: http://tungle.me/AlexKarasulu
Re: [VOTE][RESULTS] Switching to Apache's Nexus repository infrastructure for next releases of the Directory project
Just realized I didn't send the link with the release vote and verification scripts. http://markmail.org/thread/dobcq3pajdlr2h2s http://markmail.org/thread/dobcq3pajdlr2h2sChris -- Chris Custine FUSESource :: http://fusesource.com My Blog :: http://blog.organicelement.com Apache ServiceMix :: http://servicemix.apache.org Apache Felix :: http://felix.apache.org Apache Directory Server :: http://directory.apache.org On Mon, Mar 29, 2010 at 9:59 AM, Chris Custine chris.cust...@gmail.comwrote: Hi Guys, We are using Nexus Staging for Felix and ServiceMix (have been for about 6 months) so I have attached some links below that might help. FWIW, this really simplifies staging, voting, and moving to maven central to the point where its a no-brainer. You won't be disappointed! http://felix.apache.org/site/release-management-nexus.html http://www.sonatype.com/books/nexus-book/reference/staging.html Also, we have developed a script to download the numbered staging repo and verify signatures etc, of the artifacts. You should check out this recent vote email for Karaf for the svn link to the staging script, and then you can modify it to suit you. BTW, one thing people overlook is that since the staging repo is a full maven repo with just your release artifacts in it, you can add it to your settings.xml or a test project and try to use it in a project, just make sure you use a temporary maven.repo.local setting or clea out your default repo if you cancel the build and stage another vote! Hope this helps! Chris http://www.sonatype.com/books/nexus-book/reference/staging.html -- Chris Custine FUSESource :: http://fusesource.com My Blog :: http://blog.organicelement.com Apache ServiceMix :: http://servicemix.apache.org Apache Felix :: http://felix.apache.org Apache Directory Server :: http://directory.apache.org On Mon, Mar 29, 2010 at 9:29 AM, Alex Karasulu akaras...@gmail.comwrote: Hi Pierre, On Mon, Mar 29, 2010 at 3:11 PM, Pierre-Arnaud Marcelot p...@marcelot.netwrote: Hi, Just to let you know that I did a little test this morning. I deployed artifacts from a testing project with multiple sub-projects. Everything went fine and I was able to deploy the artifacts on Nexus. Once on Nexus, I had the choice to drop the deployed artifacts or promote them to the main repository. I dropped them since they were only here for testing purposes. We are currenlty finishing the work on the 1.5.3 release of Studio and will probably be ready to propose a vote today. We will use the Nexus for voting this release and we'll update the release documentation once the process is completely validated. Is there some documentation in existence for this and/or can we update our deployment wiki page to show people how to deploy using nexus. If anything maybe we can add a link etc. Just asking cuz I want to be able to use this later but don't have the brain cycles now to figure it out. Regards, Alex On 29 mars 2010, at 09:36, Pierre-Arnaud Marcelot wrote: Hi, The Jira issue has been resolved. Now, we NEED to deploy everything using Nexus and DO NOT deploy anything at the old location on people.apache.org. Thanks, Pierre-Arnaud On 26 mars 2010, at 10:19, Pierre-Arnaud Marcelot wrote: FYI, now that Apache DS is released, I opened a Jira for our move to Nexus. https://issues.apache.org/jira/browse/INFRA-2574 Regards, Pierre-Arnaud On 16 mars 2010, at 11:12, Pierre-Arnaud Marcelot wrote: The vote has been approved. Here are the results: 5 +1 votes: - Felix Knecht - Emmanuel Lécharny - Kiran Ayyagari - Pierre-Arnaud Marcelot - Stefan Seelmann 1 ±0 abstention vote: - Alex Karasulu No -1 vote. The next step in the process to move to the Nexus infrastructure is now to create a Jira as sub-task of INFRA-1896 [1]. Shall I wait for the ongoing vote of the release of Apache DS 1.5.6 to be closed and the artifacts released before asking to move to Nexus ? WDYT ? Regards, Pierre-Arnaud [1] - https://issues.apache.org/jira/browse/INFRA-1896 On 12 mars 2010, at 13:32, Pierre-Arnaud Marcelot wrote: Hi Stefan and Emmanuel, As you've started to +1 the idea, maybe it would be better to start a real formal vote. So here it is. [ ] +1 - Let's switch to Apache's Nexus repository infrastructure for the next releases of the Directory project [ ] ±0 - Abstain [ ] -1 - Let's keep our current deployment mechanism on people.apache.org Vote is opened for 72 hours. Thanks, Pierre-Arnaud On 12 mars 2010, at 07:45, Stefan Seelmann wrote: I use Nexus in my current project as repository and it works very well. So my +1 for that step. Kind Regards, Stefan On 12 mars 2010, at 09:38, Emmanuel Lecharny wrote: +1 too. If it offers a better support for our releases, I don't see why we should not switch. -- Alex Karasulu My
Re: [VOTE][RESULTS] Switching to Apache's Nexus repository infrastructure for next releases of the Directory project
Thanks Chris, These are links I came across when evaluating the move to Nexus. Let me add another one (pretty similar to the Felix release management process): http://maven.apache.org/developers/release/apache-release.html This link is the recommended path for releasing Maven based projects at Apache. Regards, Pierre-Arnaud On 29 mars 2010, at 21:38, Chris Custine wrote: Just realized I didn't send the link with the release vote and verification scripts. http://markmail.org/thread/dobcq3pajdlr2h2s Chris -- Chris Custine FUSESource :: http://fusesource.com My Blog :: http://blog.organicelement.com Apache ServiceMix :: http://servicemix.apache.org Apache Felix :: http://felix.apache.org Apache Directory Server :: http://directory.apache.org On Mon, Mar 29, 2010 at 9:59 AM, Chris Custine chris.cust...@gmail.com wrote: Hi Guys, We are using Nexus Staging for Felix and ServiceMix (have been for about 6 months) so I have attached some links below that might help. FWIW, this really simplifies staging, voting, and moving to maven central to the point where its a no-brainer. You won't be disappointed! http://felix.apache.org/site/release-management-nexus.html http://www.sonatype.com/books/nexus-book/reference/staging.html Also, we have developed a script to download the numbered staging repo and verify signatures etc, of the artifacts. You should check out this recent vote email for Karaf for the svn link to the staging script, and then you can modify it to suit you. BTW, one thing people overlook is that since the staging repo is a full maven repo with just your release artifacts in it, you can add it to your settings.xml or a test project and try to use it in a project, just make sure you use a temporary maven.repo.local setting or clea out your default repo if you cancel the build and stage another vote! Hope this helps! Chris -- Chris Custine FUSESource :: http://fusesource.com My Blog :: http://blog.organicelement.com Apache ServiceMix :: http://servicemix.apache.org Apache Felix :: http://felix.apache.org Apache Directory Server :: http://directory.apache.org On Mon, Mar 29, 2010 at 9:29 AM, Alex Karasulu akaras...@gmail.com wrote: Hi Pierre, On Mon, Mar 29, 2010 at 3:11 PM, Pierre-Arnaud Marcelot p...@marcelot.net wrote: Hi, Just to let you know that I did a little test this morning. I deployed artifacts from a testing project with multiple sub-projects. Everything went fine and I was able to deploy the artifacts on Nexus. Once on Nexus, I had the choice to drop the deployed artifacts or promote them to the main repository. I dropped them since they were only here for testing purposes. We are currenlty finishing the work on the 1.5.3 release of Studio and will probably be ready to propose a vote today. We will use the Nexus for voting this release and we'll update the release documentation once the process is completely validated. Is there some documentation in existence for this and/or can we update our deployment wiki page to show people how to deploy using nexus. If anything maybe we can add a link etc. Just asking cuz I want to be able to use this later but don't have the brain cycles now to figure it out. Regards, Alex On 29 mars 2010, at 09:36, Pierre-Arnaud Marcelot wrote: Hi, The Jira issue has been resolved. Now, we NEED to deploy everything using Nexus and DO NOT deploy anything at the old location on people.apache.org. Thanks, Pierre-Arnaud On 26 mars 2010, at 10:19, Pierre-Arnaud Marcelot wrote: FYI, now that Apache DS is released, I opened a Jira for our move to Nexus. https://issues.apache.org/jira/browse/INFRA-2574 Regards, Pierre-Arnaud On 16 mars 2010, at 11:12, Pierre-Arnaud Marcelot wrote: The vote has been approved. Here are the results: 5 +1 votes: - Felix Knecht - Emmanuel Lécharny - Kiran Ayyagari - Pierre-Arnaud Marcelot - Stefan Seelmann 1 ±0 abstention vote: - Alex Karasulu No -1 vote. The next step in the process to move to the Nexus infrastructure is now to create a Jira as sub-task of INFRA-1896 [1]. Shall I wait for the ongoing vote of the release of Apache DS 1.5.6 to be closed and the artifacts released before asking to move to Nexus ? WDYT ? Regards, Pierre-Arnaud [1] - https://issues.apache.org/jira/browse/INFRA-1896 On 12 mars 2010, at 13:32, Pierre-Arnaud Marcelot wrote: Hi Stefan and Emmanuel, As you've started to +1 the idea, maybe it would be better to start a real formal vote. So here it is. [ ] +1 - Let's switch to Apache's Nexus repository infrastructure for the next releases of the Directory project [ ] ±0 - Abstain [ ] -1 - Let's keep our current deployment mechanism on people.apache.org Vote is opened for 72 hours. Thanks, Pierre-Arnaud On 12 mars 2010, at 07:45, Stefan
Re: [VOTE][RESULTS] Switching to Apache's Nexus repository infrastructure for next releases of the Directory project
FYI, now that Apache DS is released, I opened a Jira for our move to Nexus. https://issues.apache.org/jira/browse/INFRA-2574 Regards, Pierre-Arnaud On 16 mars 2010, at 11:12, Pierre-Arnaud Marcelot wrote: The vote has been approved. Here are the results: 5 +1 votes: - Felix Knecht - Emmanuel Lécharny - Kiran Ayyagari - Pierre-Arnaud Marcelot - Stefan Seelmann 1 ±0 abstention vote: - Alex Karasulu No -1 vote. The next step in the process to move to the Nexus infrastructure is now to create a Jira as sub-task of INFRA-1896 [1]. Shall I wait for the ongoing vote of the release of Apache DS 1.5.6 to be closed and the artifacts released before asking to move to Nexus ? WDYT ? Regards, Pierre-Arnaud [1] - https://issues.apache.org/jira/browse/INFRA-1896 On 12 mars 2010, at 13:32, Pierre-Arnaud Marcelot wrote: Hi Stefan and Emmanuel, As you've started to +1 the idea, maybe it would be better to start a real formal vote. So here it is. [ ] +1 - Let's switch to Apache's Nexus repository infrastructure for the next releases of the Directory project [ ] ±0 - Abstain [ ] -1 - Let's keep our current deployment mechanism on people.apache.org Vote is opened for 72 hours. Thanks, Pierre-Arnaud On 12 mars 2010, at 07:45, Stefan Seelmann wrote: I use Nexus in my current project as repository and it works very well. So my +1 for that step. Kind Regards, Stefan On 12 mars 2010, at 09:38, Emmanuel Lecharny wrote: +1 too. If it offers a better support for our releases, I don't see why we should not switch.
Re: [VOTE] Switching to Apache's Nexus repository infrastructure for next releases of the Directory project
The vote is now closed. Results will follow. Regards, Pierre-Arnaud On 15 mars 2010, at 11:33, Stefan Seelmann wrote: [X] +1 - Let's switch to Apache's Nexus repository infrastructure for the next releases of the Directory project
[VOTE][RESULTS] Switching to Apache's Nexus repository infrastructure for next releases of the Directory project
The vote has been approved. Here are the results: 5 +1 votes: - Felix Knecht - Emmanuel Lécharny - Kiran Ayyagari - Pierre-Arnaud Marcelot - Stefan Seelmann 1 ±0 abstention vote: - Alex Karasulu No -1 vote. The next step in the process to move to the Nexus infrastructure is now to create a Jira as sub-task of INFRA-1896 [1]. Shall I wait for the ongoing vote of the release of Apache DS 1.5.6 to be closed and the artifacts released before asking to move to Nexus ? WDYT ? Regards, Pierre-Arnaud [1] - https://issues.apache.org/jira/browse/INFRA-1896 On 12 mars 2010, at 13:32, Pierre-Arnaud Marcelot wrote: Hi Stefan and Emmanuel, As you've started to +1 the idea, maybe it would be better to start a real formal vote. So here it is. [ ] +1 - Let's switch to Apache's Nexus repository infrastructure for the next releases of the Directory project [ ] ±0 - Abstain [ ] -1 - Let's keep our current deployment mechanism on people.apache.org Vote is opened for 72 hours. Thanks, Pierre-Arnaud On 12 mars 2010, at 07:45, Stefan Seelmann wrote: I use Nexus in my current project as repository and it works very well. So my +1 for that step. Kind Regards, Stefan On 12 mars 2010, at 09:38, Emmanuel Lecharny wrote: +1 too. If it offers a better support for our releases, I don't see why we should not switch.
Re: [VOTE] Switching to Apache's Nexus repository infrastructure for next releases of the Directory project
[X] +1 - Let's switch to Apache's Nexus repository infrastructure for the next releases of the Directory project
Re: [VOTE] Switching to Apache's Nexus repository infrastructure for next releases of the Directory project
[X] +1 - Let's switch to Apache's Nexus repository infrastructure for the next releases of the Directory project
Re: Considering the Nexus repository infrastructure for our future releases?
On 3/12/10 7:45 AM, Stefan Seelmann wrote: I use Nexus in my current project as repository and it works very well. So my +1 for that step. +1 too. If it offers a better support for our releases, I don't see why we should not switch. -- Regards, Cordialement, Emmanuel Lécharny www.nextury.com
Re: Considering the Nexus repository infrastructure for our future releases?
Hi Felix, I'm not really sure yet, but I'm afraid this won't work for the deployment of the generated documentation. Maybe we should ask the infra guys about that. However, I think a good workaround could be to have the documentation in a dedicated (empty) local repository that you can then zip/tar.gz. You could upload that archive (zip/tar.gz file) on people.apache.org and unarchive it to the final location from there. WDYT? Regards, Pierre-Arnaud On 11 mars 2010, at 21:04, Felix Knecht wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/11/10 18:41, Pierre-Arnaud Marcelot wrote: Hi everyone, I'd like to propose that we use Apache's Nexus repository infrastructure to release our future versions on Maven repositories. It's used by a large number of Maven based Apache projects now, and it's the recommended way of uploading releases to Maven Repositories, as described on the Releasing A Maven Project Guide [1]. I think we've reach the limit with deployments on people.apache.org... My last deployment of Studio for version 1.5.2 took more than four hours (!!). I talked with Chris Custine on that subject and we would probably have a much better performance with Nexus. It also have pretty neat features like stagging that would allow us to upload artifacts and approve (or deny) them later, which could be interesting when voting a release. However, there's seem to be one drawback in the fact that once the project is moved to Nexus, deployment on people.apache.org are disabled. All deployments must be done on Nexus. More information on this on this at INFRA-1896 [2]. I would really like that we discuss that all together and maybe we could launch a vote to move to Nexus after this discussion. WDYT? I think that's the way to go. Does there also exists a possibility to deploy at least generated release documentation? Felix Thanks, Pierre-Arnaud [1] - http://maven.apache.org/developers/release/apache-release.html [2] - https://issues.apache.org/jira/browse/INFRA-1896 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuZTOsACgkQ2lZVCB08qHExdACgrH6QmuFnTht0S7y4eaXweQxW tfkAoKV7bhdyTmuyV6zImFjLXmaCC4e7 =pew2 -END PGP SIGNATURE-
[VOTE] Switching to Apache's Nexus repository infrastructure for next releases of the Directory project
Hi Stefan and Emmanuel, As you've started to +1 the idea, maybe it would be better to start a real formal vote. So here it is. [ ] +1 - Let's switch to Apache's Nexus repository infrastructure for the next releases of the Directory project [ ] ±0 - Abstain [ ] -1 - Let's keep our current deployment mechanism on people.apache.org Vote is opened for 72 hours. Thanks, Pierre-Arnaud On 12 mars 2010, at 07:45, Stefan Seelmann wrote: I use Nexus in my current project as repository and it works very well. So my +1 for that step. Kind Regards, Stefan On 12 mars 2010, at 09:38, Emmanuel Lecharny wrote: +1 too. If it offers a better support for our releases, I don't see why we should not switch.
Re: Considering the Nexus repository infrastructure for our future releases?
Am 12.03.2010 13:25, schrieb Pierre-Arnaud Marcelot: Hi Felix, I'm not really sure yet, but I'm afraid this won't work for the deployment of the generated documentation. Maybe we should ask the infra guys about that. However, I think a good workaround could be to have the documentation in a dedicated (empty) local repository that you can then zip/tar.gz. You could upload that archive (zip/tar.gz file) on people.apache.org and unarchive it to the final location from there. WDYT? So we keep the keep it as is. After building a release we build the documentation and deploy it to p.a.o manually. That's also ok. Regards Felix
Re: [VOTE] Switching to Apache's Nexus repository infrastructure for next releases of the Directory project
[X ] +1 - Let's switch to Apache's Nexus repository infrastructure for the next releases of the Directory project Felix
