Re: Feedback on iProjects - good, bad and ugly

Thanks, Mark - memory jogged here, as well - I've not replied yet, as I forgot my reasons from years ago.

I did not go far with i projects because of the single-library thing. I've been used to true SCMs like Turnover and Aldon and Imlementer - dependencies are managed thoroughly there.

IIRC when at a place that was using Rational Team Concert, it seems that those tasks connected nicely to RDi and it used i Projects internally - but memory fails.

Anyone who already has an SCM would have little use for i Projects, but I'm willing to hear differently.

Vern

On 4/24/2017 12:37 PM, Mark Murphy/STAR BASE Consulting Inc. wrote:

This has jogged my memory, particularly point 5. I was creating a project for each development task, and that worked fine until I was working on two tasks simultaneously. The problem there was the single compile.clle. My solution was to create a source file for it named for the project, problem solved. Everything was good with just a little extra work until I ran into a task that required me to work on source from multiple libraries. Now I needed multiple projects for the task and I had to remember to push and compile them together, and sometimes in the correct order for everything to work out. This became more effort, and no one wanted to go through all that effort just to use the i project, so it was abandoned. A fully featured automated build process would make this a ton more palatable. And being able to rename compile.clle would help as well.

Mark Murphy
Atlas Data Systems
mmurphy@xxxxxxxxxxxxxxx


-----"Edmund Reinhardt" <edmund.reinhardt@xxxxxxxxxx> wrote: -----
To: wdsci-l@xxxxxxxxxxxx
From: "Edmund Reinhardt" <edmund.reinhardt@xxxxxxxxxx>
Date: 04/24/2017 11:37AM
Subject: [WDSCI-L] Feedback on iProjects - good, bad and ugly



I really appreciate all the feedback. You guys are awesome!

Some of what I have learned.

1) Need a keyboard shortcut to push and build.
- this should be easy
- I am thinking if optionally Automatically pushing and building a project
on the save of a file is a good idea.

2) Easier way to populate the i Projects from the i Project Navigator (From
RSE seems to work well)
- Buck, you might want to check out the "Show Remote Objects" item from the
context menu in the i Project Navigator. Not only does this give you a
complete view including the compiled objects, but you can also right click
on Remote members and add them to your i Project with a simple action.

3) Improved build mechanism
- Simple compiles seem to work, If people are aware of RPGLEINC they can
avoid compiling their copy files.
- ILE is tricky for i Projects to guess correctly because it is not obvious
= we would need some additional metadata in the project to remember what
binds to what and with what compile/bind options
= we could possibly populate this from the existing compiled objects

4) IFS is missing
- I hope everyone has tried using the Remote Reconciler on any project.
You can use specialize Python/HTML/Java projects and get all of the extra
Eclipse tooling for those. Or if you just want to work with RPG/CL, you
can create a General project. Eric Simpson has detailed instructions here
http://ibm.biz/rdi_reconcile_ifs
See section 2.4 in http://ibm.biz/rdi_git for step by step instructions in
how to team share with Git.
This is discussed on slide 37ff in http://ibm.biz/rd_whatsnew_9511

5) More than 1 library in the same i Project
= I am sorry but this is the current design assumption of the architecture
of i Projects. You simply have to create multiple projects, one for each
library. (Or you can have more than one per library, dealing with disjoint
subsets).
- having multiple projects can actually be an advantage, allowing a smaller
scope and context for your changes.

Once again, I really appreciate everyone who took the time to give us this
useful feedback.

Edmund