On 2019-01-16 15:46, dgersic wrote:
>
> We've batted this around before, but it doesn't seem like git support in
> Designer is going to happen any time soon. What would it actually take
> to do this without official support?
>
> I've worked with several revision control systems. In the end, what they
> care about most is files. We have files, they're stored under the
> workspace directory.
>
> Would it be sufficient to create a git repository, and shove the
> workspace in to it so that it can be managed using git's tools? Sure, it
> wouldn't be as pretty and nice as doing this in Designer itself, but
> would it work? If not, why not?
>
> I think the basics of it might work.
>
>
Hello
We are using Bitbucket (which is using git) manually outside of Designer
and have done so for almost a year.

So far we haven't had any issues I'm aware of.



--
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.

alekz wrote:

> We are using Bitbucket (which is using git) manually outside of Designer and
> have done so for almost a year.
>
> So far we haven't had any issues I'm aware of.

I would expect this to work just fine as long as you always commit/update the
whole project.

But as soon as you commit - say - an newly added driver only, Designer applies
some logic to find all references to that driver (e.g. in driverset, package
catalog etc.) and commits those as well. I think Designer will also not only
look at complete files but must have to work on it's contents, too. E.g. you
add to new drivers to a project, both using the same package. Now when you only
commit one of those drivers, the package installed on both holds a reference to
both drivers but would only have to be committed in a version that references
only one of them (until you also commit the second driver). This mess should
have been avoided in the first place by choosing an appropriate file model on
disk (if that was possible at all).

At least that's how I imagine the underlying problem of adding git support (or
even only bringing the SVN client plugin up to date).

While we've all been after this for a while, I have a hard time talking
myself into believing there is improvement if the whole project, or even
workspace, is tossed into Git. This is nothing better than any other
filesystem backup mechanism, except that maybe it's easier for us to
control. Any backup would probably need to have Designer closed for
safety, and any restore would definitely need Designer closed to read the
new workspace data. There is no way to do meaningful diffs, or merges, or
anything like that.

As always, I think Designer needs a couple things:

1. The ability to export objects to the filesystem. Driver object get a
file, each policy object gets a file, some files work for the UserApp
mess, and so on.

2. Hopefully obvious, Designer needs to be able to import from that same
place.

3. Ideally Designer learns how to interact with Git, and manages commits
within there directly, but if not at least using Git to commit changes,
view differences, and the with #1 above would be possible.

4. Pipe dream: make it possible for deployment to happen on the IDM box,
maybe with headless Designer, so outside access could be blocked.

IDM is an interesting tool from a source code point of view because the
running code is ONLY ever in eDirectory, which is completely different
from Designer in how it stores files, what it does, etc. With other
software projects, IDM included (internally, not as a product we use),
development happens in a tool like Eclipse (Designer for us) and a
finished product is built on a server, pulling those changes in from
something like Git (or older wanna-be Git systems). The IDE does not push
the latest code into some server and then run it, yet that is how Designer
works with IDM. It has its copy, the IDM engine has its copy, and
sometimes we keep other black-box copies in SVN.

For the record, it is nice being able to make changes lives without
restarting eDirectory, or rebuilding drivers, or accessing servers
directly, but because we ONLY have this model, we lose the benefits of the
other model, which is where everybody else works with plain old text
files, representing logical code things (Java files, properties files,
resource files) and we have corresponding logical code things (driver
objects, policy objects, mapping table objects), but no corresponding
functionality.

--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.

If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.

ab;2493764 wrote:
While we've all been after this for a while, I have a hard time talking
myself into believing there is improvement if the whole project, or even
workspace, is tossed into Git. This is nothing better than any other
filesystem backup mechanism, except that maybe it's easier for us to
control. Any backup would probably need to have Designer closed for
safety, and any restore would definitely need Designer closed to read the
new workspace data. There is no way to do meaningful diffs, or merges, or
anything like that.

As always, I think Designer needs a couple things:

1. The ability to export objects to the filesystem. Driver object get a
file, each policy object gets a file, some files work for the UserApp
mess, and so on.

2. Hopefully obvious, Designer needs to be able to import from that same
place.

3. Ideally Designer learns how to interact with Git, and manages commits
within there directly, but if not at least using Git to commit changes,
view differences, and the with #1 above would be possible.

4. Pipe dream: make it possible for deployment to happen on the IDM box,
maybe with headless Designer, so outside access could be blocked.

IDM is an interesting tool from a source code point of view because the
running code is ONLY ever in eDirectory, which is completely different
from Designer in how it stores files, what it does, etc. With other
software projects, IDM included (internally, not as a product we use),
development happens in a tool like Eclipse (Designer for us) and a
finished product is built on a server, pulling those changes in from
something like Git (or older wanna-be Git systems). The IDE does not push
the latest code into some server and then run it, yet that is how Designer
works with IDM. It has its copy, the IDM engine has its copy, and
sometimes we keep other black-box copies in SVN.

For the record, it is nice being able to make changes lives without
restarting eDirectory, or rebuilding drivers, or accessing servers
directly, but because we ONLY have this model, we lose the benefits of the
other model, which is where everybody else works with plain old text
files, representing logical code things (Java files, properties files,
resource files) and we have corresponding logical code things (driver
objects, policy objects, mapping table objects), but no corresponding
functionality.

--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.

If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.

The chief benefit I see to using git (or SVN or insert your preferred system here) is the storing comments along with the changes. So if I need to know when Foo changed from doing Bar to doing Baz, I can have a reasonable look at what that change entailed, what other changes went with it, and what has changed since. I can't easily revert that change without addressing the side effects.

1. Everything is already files in the file system. We call them a Designer "project". But you can wander around the undocumented and fairly opaque directory structure looking at the files. It's all there somewhere.

2. Designer can export the whole mess to an archive. And it can import that archive. So to some degree, this is also already done.

As far as I can tell, #1 and #2 together indicate that copying the relevant stuff out of a project directory and in to another project directory is almost kinda all Designer actually needs. I haven't looked in to the link from the workspace to the individual projects within. That may be a hurdle, to get Designer to see a newly (git imported) project.

3. Yeah, this is what we want. It's been on the list of things to do, someday, for about 10 years now. At this point, I don't expect to see it happen, and I'm kinda tired of waiting for it. It took d*mn near forever to get SVN support, and even longer to get it to the point where it actually worked, and mostly didn't suck. They've been hemming and hawing about git support ever since.

4. Would be cool. Would be interesting. Depends on #3. At this point, I expect the heat death of the universe to happen first.

ab wrote:

> IDM is an interesting tool from a source code point of view because the
> running code is ONLY ever in eDirectory, which is completely different
> from Designer in how it stores files, what it does, etc. With other
> software projects, IDM included (internally, not as a product we use),
> development happens in a tool like Eclipse (Designer for us) and a
> finished product is built on a server, pulling those changes in from
> something like Git (or older wanna-be Git systems). The IDE does not push
> the latest code into some server and then run it, yet that is how Designer
> works with IDM. It has its copy, the IDM engine has its copy, and
> sometimes we keep other black-box copies in SVN.

That's an interesting approach. The production IDM servers could always pull
the "master" branch and build/deploy/run it as current state of the whole
system. Individual driver developments or bug fixes etc would always occur in
their own branches and could be pulled by dev and test server. Once an item has
been developed for testing, it's development branch could be merged into a "QA"
branch running on a test server, and once approved for production, merged into
master.

I'd really like to do this with git and not svn because of the MUCH better
branching/merging/pull requests capabilities etc. though...

ab wrote:

> As always, I think Designer needs a couple things:
>
> 1. The ability to export objects to the filesystem. Driver object get a
> file, each policy object gets a file, some files work for the UserApp
> mess, and so on.
>
> 2. Hopefully obvious, Designer needs to be able to import from that same
> place.

Isn't that what we have in the project folder already?

--
http://www.is4it.de/en/solution/identity-access-management/

(If you find this post helpful, please click on the star below.)

On 01/16/2019 10:32 AM, Lothar Haeger wrote:
> ab wrote:
>
>> As always, I think Designer needs a couple things:
>>
>> 1. The ability to export objects to the filesystem. Driver object get a
>> file, each policy object gets a file, some files work for the UserApp
>> mess, and so on.
>>
>> 2. Hopefully obvious, Designer needs to be able to import from that same
>> place.
>
> Isn't that what we have in the project folder already?

No, I mean proper files with just the objects we need. I want the driver
config export files, but then I want things broken down more since we do
not want one file for every driver, with other objects included in them,
we (I) just want eDirectory objects in files.

I think what I want is something kind of like
workspaceDirectory/projectDirectory/Model/Project, and maybe (but maybe
not) the EdirOrphan directory too. I have not delved into this much, but
this is an initial rambling.

Ideally I want the Outline view in Designer, and I want everything in that
outline view (every eDir object) to have an XML file structured/formatted
like we expect to find in a driver config export. If I change a driver
config object's trace settings, those go in the driver config object file.
If I modify a policy's rules, those go in the policy's files. If I link
in a new policy, that goes in the appropriate channel's (or maybe driver
object's for Input or Output Transformation Policyset changes) files.
When I change a workflow, that goes in some breakdown of workflow files.
When I change an e-mail template, a file for that e-mail template.

Yes, Git is the only option when compared with SVN because, well, it's the
21st century. SVN does a fine job in some cases, but it just doesn't fit
as well with how people work compared to Git, and its inability to branch
and merge properly is horrific.

--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.

If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.

On 01/16/2019 10:34 AM, dgersic wrote:
>
> The chief benefit I see to using git (or SVN or insert your preferred
> system here) is the storing comments along with the changes. So if I
> need to know when Foo changed from doing Bar to doing Baz, I can have a
> reasonable look at what that change entailed, what other changes went
> with it, and what has changed since. I can't easily revert that change
> without addressing the side effects.

Agreed, and also these systems store specific changes. In changing one
rule from matching "foo" to "bar", I changed, and it tracked, one line of
code, and I can see that difference to understand exactly what the commit
message is describing. Binary (non-text) files are not code, and a bunch
of the project directory is binary crap changing all the time, so using
anything to version-control that is a non-starter for me. Sure, have a
backup, whether the project or workspace or a compressed archive, but
that's not version control as much as disaster recovery. If ever merge or
commit uses your disaster recovery system, you have too many disasters to
get work done, and something is probably built incorrectly.

> 1. Everything is already files in the file system. We call them a
> Designer "project". But you can wander around the undocumented and
> fairly opaque directory structure looking at the files. It's all there
> somewhere.

Yes, but I don't need the cruft; I need my code, just my code, and of
course that means links among objects (policyset points to policies,
etc.). I also need the files to have meaningful names somehow Maybe a
filesystem directory structure which matches, to some extent, the IDM
directory structure (not the whole directory, just the IDM bits like we
have in the Outline view).

> 2. Designer can export the whole mess to an archive. And it can import
> that archive. So to some degree, this is also already done.

Yes, and completely useless for version control, so not done. When you
commit a change, I do not want to lose (or at least close) all of my work
just to view it.

> As far as I can tell, #1 and #2 together indicate that copying the
> relevant stuff out of a project directory and in to another project
> directory is almost kinda all Designer actually needs. I haven't looked
> in to the link from the workspace to the individual projects within.
> That may be a hurdle, to get Designer to see a newly (git imported)
> project.

I think this is missing the point. If we want to backup and restore
projects, we can do that now, and that's been possible since Designer
first came out. We need standard version control functionality with some
focus on IDM, and in my mind that means objects in the directory are
represented in files, structured in directories like their containers,
linked via XML metadata if needed, and able to be checked in with only
differences tracked, as is normal for every other bit of code on the planet.

> 3. Yeah, this is what we want. It's been on the list of things to do,
> someday, for about 10 years now. At this point, I don't expect to see it
> happen, and I'm kinda tired of waiting for it. It took d*mn near forever
> to get SVN support, and even longer to get it to the point where it
> actually worked, and mostly didn't suck. They've been hemming and hawing
> about git support ever since.

Doing this would also naturally lead to fixes on the code promotion
problem. Have a branch for prod, one for QA, one for test, and a release
branch. Develop feature branches, merge into test, when done move into
release. When done with that, merge up into QA, then later into Prod.
Clean movement of code up the line, and that could all still be in
Designer (skipping the #4 idea), or headless Designer could make the #4
part happen.

Yes, it's a bit of work, but without any feedback from anybody
authoritative, I can only presume other priorities take the time to even
start investigating if it really is hard, or if, with the right people,
it's a week's work.

Considering the Compare/Deploy functionality already knows how to work
with XML and specific objects, I think this is easier than it may seem,
however simplistic that view I may have. If the Compare/Deploy
functionality was used to now Compare/Deploy with the filesystem, and the
filesystem was basically the Outline view (plus UserApp cruft), that would
be pretty good. Build in automatic committing, pushing, and pulling, and
you're done.

--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.

If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.

ab wrote:

> I think what I want is something kind of like
> workspaceDirectory/projectDirectory/Model/Project, and maybe (but maybe
> not) the EdirOrphan directory too. I have not delved into this much, but
> this is an initial rambling.
>
> Ideally I want the Outline view in Designer, and I want everything in that
> outline view (every eDir object) to have an XML file structured/formatted
> like we expect to find in a driver config export. If I change a driver
> config object's trace settings, those go in the driver config object file.
> If I modify a policy's rules, those go in the policy's files. If I link
> in a new policy, that goes in the appropriate channel's (or maybe driver
> object's for Input or Output Transformation Policyset changes) files.

The file/folder structure under EdirOrphan is already quite that, IIRC.

For example, in one project I find in Model/EdirOrphan a file called
DAO2WEXA.DriverSet_ describing a driverset object in XML syntax. The folder
Model/EdirOrphan/DAO2WEXA then contains files named LFODMXZA.Driver_ and
LFODMXZA_8CYQAFJH_DirXML-ConfigValues.xml which describe a certain driver in
XML (plus LFODMXZA_icon.gif). The folder Model/EdirOrphan/DAO2WEXA/LFODMXZA
then contains objects named C8DNX0RQ.Subscriber_ and YGVG2OIO.Publisher_
describing... well, you get the picture.

If file names were more descriptive working with external git would be easier,
but the real challenge is to keep the refereneces that are stored all over the
place consistent for each revision that gets committed.

Not a problem as long as you check in the whole project but a real challenge
when several people work on the same project on different drivers. That is the
key point where IDM differs a lot from traditional software projects: when I
build e.g. Apache Studio from source, I always build the whole thing, not just
one Plugin or feature of a plugin. And only if is compiles to the very end, I
get a running product. And there's just one source code repository to build
from. With IDM 3 developers may share the same project while another two work
with their own. So three projects exist and it all comes together in the live
system. It would be a lot easier if there was only one single Designer project
for each IDM environment everyone involved would be required to work with. Only
that designer could not handle such a project for any non-trivial environment
because of it's size... :-(


--
http://www.is4it.de/en/solution/identity-access-management/

(If you find this post helpful, please click on the star below.)

On 01/16/2019 11:53 AM, Lothar Haeger wrote:
> ab wrote:
>
>> I think what I want is something kind of like
>> workspaceDirectory/projectDirectory/Model/Project, and maybe (but maybe
>> not) the EdirOrphan directory too. I have not delved into this much, but
>> this is an initial rambling.
>>
>> Ideally I want the Outline view in Designer, and I want everything in that
>> outline view (every eDir object) to have an XML file structured/formatted
>> like we expect to find in a driver config export. If I change a driver
>> config object's trace settings, those go in the driver config object file.
>> If I modify a policy's rules, those go in the policy's files. If I link
>> in a new policy, that goes in the appropriate channel's (or maybe driver
>> object's for Input or Output Transformation Policyset changes) files.
>
> The file/folder structure under EdirOrphan is already quite that, IIRC.
>
> For example, in one project I find in Model/EdirOrphan a file called
> DAO2WEXA.DriverSet_ describing a driverset object in XML syntax. The folder
> Model/EdirOrphan/DAO2WEXA then contains files named LFODMXZA.Driver_ and
> LFODMXZA_8CYQAFJH_DirXML-ConfigValues.xml which describe a certain driver in
> XML (plus LFODMXZA_icon.gif). The folder Model/EdirOrphan/DAO2WEXA/LFODMXZA
> then contains objects named C8DNX0RQ.Subscriber_ and YGVG2OIO.Publisher_
> describing... well, you get the picture.

It's something, yes, though why there are GIF files in there I cannot
figure out (I know some of them are the driver icons, but those should be
attributes on objects, not separate files; just leave it in the XML like
the driver config export does). The names are an issue, but I would think
keeping the names like they are in the directory, rather than looking like
they may be GUID-related, may be feasible.

> If file names were more descriptive working with external git would be easier,
> but the real challenge is to keep the refereneces that are stored all over the
> place consistent for each revision that gets committed.
>
> Not a problem as long as you check in the whole project but a real challenge
> when several people work on the same project on different drivers. That is the
> key point where IDM differs a lot from traditional software projects: when I
> build e.g. Apache Studio from source, I always build the whole thing, not just
> one Plugin or feature of a plugin. And only if is compiles to the very end, I
> get a running product. And there's just one source code repository to build
> from. With IDM 3 developers may share the same project while another two work
> with their own. So three projects exist and it all comes together in the live
> system. It would be a lot easier if there was only one single Designer project
> for each IDM environment everyone involved would be required to work with. Only
> that designer could not handle such a project for any non-trivial environment
> because of it's size... :-(

I'm not sure I agree here, but admittedly I didn't write Designer.

Git repositories, by definition, are complete repositories. This differs
wildly with older things like SVN which allow you to "checkout" a portion
of the code, modify it, and check it back into the only real repository,
the one on a server somewhere else. Git instead only works if you have
the full repository, and then you modify some part of it and check that
in, and Git handles the merging when necessary.

Because everybody has everything, references are either there and
complete, or not there at all, or should be anyway. If I delete a policy
in Designer, that not only deletes the object (and queues a delete to
eDirectory the next time I deploy) but it also deletes any policysets
pointing to that object . When i then commit, both the references all
over, and the object itself, go away. When somebody else commits code,
either it dealt with that object or its references, or it did not. If
not, the merge is fine; if so, the you have a merge conflict, and manual
intervention happens, but at least it's done BEFORE the commit actually
goes to what we may label "upstream".

The result of this is I think, as with every project out there, using Git
helps a lot more because it deals with the whole repository, not just some
fragment which, in isolation, may be just fine, but when considered as a
critical part of everything, may be broken by something completely
unexpected. Designer needs to work in this way, not in the old way which
worked with SVN. Learning Git, with a mindset trained by SVN, was hard,
and it wasn't until I stopped thinking about SVN's way of doing things
that Git became intuitive, and i was able to use it well (or at least much
better; I'm no expert).

--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.

If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.

ab;2493778 wrote:
On 01/16/2019 10:34 AM, dgersic wrote:
>
> The chief benefit I see to using git (or SVN or insert your preferred
> system here) is the storing comments along with the changes. So if I
> need to know when Foo changed from doing Bar to doing Baz, I can have a
> reasonable look at what that change entailed, what other changes went
> with it, and what has changed since. I can't easily revert that change
> without addressing the side effects.

Agreed, and also these systems store specific changes. In changing one
rule from matching "foo" to "bar", I changed, and it tracked, one line of
code, and I can see that difference to understand exactly what the commit
message is describing. Binary (non-text) files are not code, and a bunch
of the project directory is binary **** changing all the time, so using
anything to version-control that is a non-starter for me. Sure, have a
backup, whether the project or workspace or a compressed archive, but
that's not version control as much as disaster recovery. If ever merge or
commit uses your disaster recovery system, you have too many disasters to
get work done, and something is probably built incorrectly.

> 1. Everything is already files in the file system. We call them a
> Designer "project". But you can wander around the undocumented and
> fairly opaque directory structure looking at the files. It's all there
> somewhere.

Yes, but I don't need the cruft; I need my code, just my code, and of
course that means links among objects (policyset points to policies,
etc.). I also need the files to have meaningful names somehow Maybe a
filesystem directory structure which matches, to some extent, the IDM
directory structure (not the whole directory, just the IDM bits like we
have in the Outline view).

> 2. Designer can export the whole mess to an archive. And it can import
> that archive. So to some degree, this is also already done.

Yes, and completely useless for version control, so not done. When you
commit a change, I do not want to lose (or at least close) all of my work
just to view it.

> As far as I can tell, #1 and #2 together indicate that copying the
> relevant stuff out of a project directory and in to another project
> directory is almost kinda all Designer actually needs. I haven't looked
> in to the link from the workspace to the individual projects within.
> That may be a hurdle, to get Designer to see a newly (git imported)
> project.

I think this is missing the point. If we want to backup and restore
projects, we can do that now, and that's been possible since Designer
first came out. We need standard version control functionality with some
focus on IDM, and in my mind that means objects in the directory are
represented in files, structured in directories like their containers,
linked via XML metadata if needed, and able to be checked in with only
differences tracked, as is normal for every other bit of code on the planet.

> 3. Yeah, this is what we want. It's been on the list of things to do,
> someday, for about 10 years now. At this point, I don't expect to see it
> happen, and I'm kinda tired of waiting for it. It took d*mn near forever
> to get SVN support, and even longer to get it to the point where it
> actually worked, and mostly didn't suck. They've been hemming and hawing
> about git support ever since.

Doing this would also naturally lead to fixes on the code promotion
problem. Have a branch for prod, one for QA, one for test, and a release
branch. Develop feature branches, merge into test, when done move into
release. When done with that, merge up into QA, then later into Prod.
Clean movement of code up the line, and that could all still be in
Designer (skipping the #4 idea), or headless Designer could make the #4
part happen.

Yes, it's a bit of work, but without any feedback from anybody
authoritative, I can only presume other priorities take the time to even
start investigating if it really is hard, or if, with the right people,
it's a week's work.

Considering the Compare/Deploy functionality already knows how to work
with XML and specific objects, I think this is easier than it may seem,
however simplistic that view I may have. If the Compare/Deploy
functionality was used to now Compare/Deploy with the filesystem, and the
filesystem was basically the Outline view (plus UserApp cruft), that would
be pretty good. Build in automatic committing, pushing, and pulling, and
you're done.

--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.

If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.

I completely agree, but while you're asking for all of that, you might as well request a unicorn to go with it. Unless you have some magic way to get prioritization on building all of this, you're kinda stuck with "no, it doesn't do that". I'm thinking that something might be better than nothing, at least until unicorns start getting delivered.

lhaeger;2493780 wrote:
ab wrote:

> I think what I want is something kind of like
> workspaceDirectory/projectDirectory/Model/Project, and maybe (but maybe
> not) the EdirOrphan directory too. I have not delved into this much, but
> this is an initial rambling.
>
> Ideally I want the Outline view in Designer, and I want everything in that
> outline view (every eDir object) to have an XML file structured/formatted
> like we expect to find in a driver config export. If I change a driver
> config object's trace settings, those go in the driver config object file.
> If I modify a policy's rules, those go in the policy's files. If I link
> in a new policy, that goes in the appropriate channel's (or maybe driver
> object's for Input or Output Transformation Policyset changes) files.

The file/folder structure under EdirOrphan is already quite that, IIRC.

For example, in one project I find in Model/EdirOrphan a file called
DAO2WEXA.DriverSet_ describing a driverset object in XML syntax. The folder
Model/EdirOrphan/DAO2WEXA then contains files named LFODMXZA.Driver_ and
LFODMXZA_8CYQAFJH_DirXML-ConfigValues.xml which describe a certain driver in
XML (plus LFODMXZA_icon.gif). The folder Model/EdirOrphan/DAO2WEXA/LFODMXZA
then contains objects named C8DNX0RQ.Subscriber_ and YGVG2OIO.Publisher_
describing... well, you get the picture.

If file names were more descriptive working with external git would be easier,
but the real challenge is to keep the refereneces that are stored all over the
place consistent for each revision that gets committed.

Not a problem as long as you check in the whole project but a real challenge
when several people work on the same project on different drivers. That is the
key point where IDM differs a lot from traditional software projects: when I
build e.g. Apache Studio from source, I always build the whole thing, not just
one Plugin or feature of a plugin. And only if is compiles to the very end, I
get a running product. And there's just one source code repository to build
from. With IDM 3 developers may share the same project while another two work
with their own. So three projects exist and it all comes together in the live
system. It would be a lot easier if there was only one single Designer project
for each IDM environment everyone involved would be required to work with. Only
that designer could not handle such a project for any non-trivial environment
because of it's size... :-(


--
http://www.is4it.de/en/solution/identity-access-management/

(If you find this post helpful, please click on the star below.)

This is a different but related problem. Having multiple people working on the same project is difficult, at best. It would be ideal to use git to manage the branch/merge problem with multiple developers, but I think that's beyond the current design of what's on disk and what we know about it.

lhaeger;2493780 wrote:
ab wrote:

> I think what I want is something kind of like
> workspaceDirectory/projectDirectory/Model/Project, and maybe (but maybe
> not) the EdirOrphan directory too. I have not delved into this much, but
> this is an initial rambling.
>
> Ideally I want the Outline view in Designer, and I want everything in that
> outline view (every eDir object) to have an XML file structured/formatted
> like we expect to find in a driver config export. If I change a driver
> config object's trace settings, those go in the driver config object file.
> If I modify a policy's rules, those go in the policy's files. If I link
> in a new policy, that goes in the appropriate channel's (or maybe driver
> object's for Input or Output Transformation Policyset changes) files.

The file/folder structure under EdirOrphan is already quite that, IIRC.

For example, in one project I find in Model/EdirOrphan a file called
DAO2WEXA.DriverSet_ describing a driverset object in XML syntax. The folder
Model/EdirOrphan/DAO2WEXA then contains files named LFODMXZA.Driver_ and
LFODMXZA_8CYQAFJH_DirXML-ConfigValues.xml which describe a certain driver in
XML (plus LFODMXZA_icon.gif). The folder Model/EdirOrphan/DAO2WEXA/LFODMXZA
then contains objects named C8DNX0RQ.Subscriber_ and YGVG2OIO.Publisher_
describing... well, you get the picture.

If file names were more descriptive working with external git would be easier,
but the real challenge is to keep the refereneces that are stored all over the
place consistent for each revision that gets committed.

Not a problem as long as you check in the whole project but a real challenge
when several people work on the same project on different drivers. That is the
key point where IDM differs a lot from traditional software projects: when I
build e.g. Apache Studio from source, I always build the whole thing, not just
one Plugin or feature of a plugin. And only if is compiles to the very end, I
get a running product. And there's just one source code repository to build
from. With IDM 3 developers may share the same project while another two work
with their own. So three projects exist and it all comes together in the live
system. It would be a lot easier if there was only one single Designer project
for each IDM environment everyone involved would be required to work with. Only
that designer could not handle such a project for any non-trivial environment
because of it's size... :-(


--
http://www.is4it.de/en/solution/identity-access-management/

(If you find this post helpful, please click on the star below.)

This is a different but related problem. Having multiple people working on the same project is difficult, at best. It would be ideal to use git to manage the branch/merge problem with multiple developers, but I think that's beyond the current design of what's on disk and what we know about it.