Portal Development via NWDI / massive ShowStoppers
we are just evaluating to use the NWDI for our internal portal application development. I have come across several issues I would consider as massive showstoppers, and as far as I have read within this forum, others sometimes have come across the same issues without a solution - or just are not doing that intensive portal development we do (and so are not aware how massive some issues can be).
Anyhow, I'm relatively new to this combination, and it may be (I would be glad) that I'm overlooking something (or many things ).
(a) Creating a DC of type Portal Application Module does not offer the direct deployment into the DEV defined in the track (in addition, it has a bug which doesn't even allow the PAR deployment, see Problems deploying Portal Application Module DC - for which I just opened an OSS message). Even it the PAR deployment would work, I cannot see any advantages using this kind of DC within the whole NWDI (see problem (c) as explicit disadvantage; I think using for example DTR solely (or CVS) would be the preferrable in this case).
(b) Creating a DC of type Portal Application Standalone doesn't offer the deployment of the PAR into a local system (when choosing Export PAR, such a DC / project isn't offered as project to choose - from which a PAR should be created / eventually deployed). But we definitely want to use local dev systems, that cannot be discussed - and this is also a strategy SAP officially suggests! But I see no way to reach this (and it is not acceptable to manually deploy the PAR from the temp dir...).
(c) Even if (a)/(b) would work "better" - the main problem remaining are the missing standard portal applications, which are not delivered as DCs within a SCA. I know the paper "Develop with NWDI using External Libraries - with EP Example" - BUT: That cannot be seriously expected to go that way for portal applications which are more than a "Hello World".
Example: Without NWDI / the DC concept, we develop a portal application which makes use of let's say 15 public libraries, to be found within let's say 10 standard portal applications. We know the classes (for example KM, Navigation, PCD etc pp), and the way to use it is very fast: Type the class - NWDS cannot resolve it. Right clickt, use ClassLocator, choose implementation - bingo, the class path is extended, everything compiles. And before deployment, we check the .classpath file to collect all portal applications used and type these into the SharingReference. Even if this works fast, it would be relatively easy to develop a plugin which automates this task. So in the end, we are talking about some seconds(!) (or in hard cases up to 5 minutes) to resolve all dependencies.
And now imagine this within the NWDI scenario - that means the work (a) to detect which portal applications are used (this still can / probably must be done using classlocator to get the sources compiled locally), (b) to create external libraries for each portal applications (this has only to be done "once", but for almost 400 apps...?!?! 8-( ), (c) to choose the DCs via UI used in this DC for a successful build?!?! Hey - that's the blank horror.
So I come to the question again: Do I overlook something essential or is it just the simple truth that NWDI cannot be used seriously for daily portal development tasks (we are a company doing more or less solely portal development, and that always means "much, much deeper than HelloWorld"; the scenario described is the standard case).
Thanks in advance for each feedback