ide 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
>
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
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
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
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.
xts in ldapbrowser with
> M16, previous releases are OK.
>
>
> Key: DIRSTUDIO-1271
> URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1271
>
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]
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]
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
ing Contexts in ldapbrowser with
> M16, previous releases are OK.
>
>
> Key: DIRSTUDIO-1271
> URL: https://issues.apache.org/jira/bro
xts in ldapbrowser with
> M16, previous releases are OK.
>
>
> Key: DIRSTUDIO-1271
> URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1271
>
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
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
ion
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.
rties.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.
>
>
>
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
ide tools to migrate the config or the data between releases
>
>
> Key: DIRSERVER-2077
> URL: https://issues.apache.org/jira/browse/DIRSERVER-2077
> Project: Directory ApacheD
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
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
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
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.
een releases
>
>
> Key: DIRSERVER-2077
> URL: https://issues.apache.org/jira/browse/DIRSERVER-2077
> Project: Directory ApacheDS
> Issue Type: Task
>
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
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
>
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
ide tools to migrate the config or the data between releases
>
>
> Key: DIRSERVER-2077
> URL: https://issues.apache.org/jira/browse/DIRSERVER-2077
> Project: Directory ApacheD
ide tools to migrate the config or the data between releases
>
>
> Key: DIRSERVER-2077
> URL: https://issues.apache.org/jira/browse/DIRSERVER-2077
> Project: Directory ApacheD
://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
: 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://is
{{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
>
>
&g
5efbf30220e8c7c61b1d} 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: DIRS
}} 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
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
>
>
>
ata between releases
>
>
> Key: DIRSERVER-2077
> URL: https://issues.apache.org/jira/browse/DIRSERVER-2077
> Project: Directory ApacheDS
> Issue Type: Task
>Aff
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
>
>
>
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
>
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
>
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
>
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
> -
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/j
ols to migrate the config or the data between releases
>
>
> Key: DIRSERVER-2077
> URL: https://issues.apache.org/jira/browse/DIRSERVER-2077
> Project: Directory ApacheDS
>
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
ide tools to migrate the config or the data between releases
>
>
> Key: DIRSERVER-2077
> URL: https://issues.apache.org/jira/browse/DIRSERVER-2077
> Project: Directory ApacheD
ide tools to migrate the config or the data between releases
>
>
> Key: DIRSERVER-2077
> URL: https://issues.apache.org/jira/browse/DIRSERVER-2077
> Project: Directory ApacheD
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
');]
*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
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
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
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.
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
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
[
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
, 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
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
* 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
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
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
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
.
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
, 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
, 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
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
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
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
[X] +1 - Let's switch to Apache's Nexus repository infrastructure for the
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
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
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
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
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
[X ] +1 - Let's switch to Apache's Nexus repository infrastructure for
the next releases of the Directory project
Felix
1 - 100 of 144 matches
Mail list logo
