ADF Faces & BC: Best pratices for project layout

[Wes Fang]

Season greetings my fellow JDevelopers!

Our software group has been working with ADF for around 5 years and
through the years we have accumulated a good amount of knowledge
working with JDeveloper and ADF. Much of our current application
structure has been resurrected in the early days of JDeveloper 10
where there were more samples codes floating around then there were
"best pratice" documentation. I understand this is a subjective topic
and varies site to site, but I believe there is a set of common
practices our group has started to identify as critical to
streamlining a development process(reusable decorated ui components,
modular common biz logic, team development with svn, continuous
integration/build, etc..). One of our development goals is to minimize
dependency between each engineer as everyone is responsible for both
client and middle layer implementation without losing coding
consistency. After speaking with a couple of the aces at the last
openworld, I understand much of our anticipated architectural
requirements are met with JDeveloper 11(with the introduction of
templates, declarative components, bounded task flows, etc..) but due
to time constraints on upcoming deliverables we are still about an
year away before moving on with that new release. The following is a
little bit about our group/application.

JDeveloper version: 10.1.3.4
Number of developers: 7
Developer responsibilties: Build both faces & bc code

We have two applications currently in deployment.
1.A flavor of Steve Muench's dynamic jdbc credentials login module
2.Core ADF Faces & BC application

In our Core ADF Faces application, we have the following structure:

OurApplication
-OurApplicationLib (Common framework files)
-OurApplicationModel (BC project)
-src/org/ourapp/module1
-src/org/ourapp/module2
…
-OurApplicationView (Faces project)
public_html/ourapp/module1
public_html/ourapp/module2
…
src/org/ourapp/backing/module1
src/org/ourapp/backing/module2
…
src/org/ourapp/pageDefs/


Total Number of Application Modules: 15 (Including one
RootApplicationModule which references module specific AMs)
Total Number View Objects: 171
Total Number of Entities: 58
Total Number of BC Files: 1734
Total Number of JSPs: 246
Total Number of pageDefs: 236
Total Number of navigation cases in faces-config.xml: 127
Total Number of application files: 4183
Total application size: 180megs

Are there any other ways to divide up this application? Ie: module
specific projects with seperate faces-config files/databindings? If
so, how can these files be "hooked" together? A couple of the aces
has recommended that we should separate all the entity files into its
own project which make sense. Also, we are looking into the maven
builds which should remove those pesky model.jpr files that constantly
gets “touched”. I would to love hear how other groups are organizing
their application and anything else they would like to share as a ADF
best pratices.

Also feel free to update the following thread on the jdeveloper
forums:
http://forums.oracle.com/forums/thread.jspa?threadID=841321&stqc=true

Cheers,
Wes

[Jean-Marc]

We try to keep it as simple as possible and make sure we can maintain
as we grow.
We size each application/project to one or two developers +
Subversion, we use one Common application/project holding all common
classes, one Main application/project to act as our backbone
application from where our "sub-apps" or modules are called.
We have a OID group for each module for high-level access control.
Each module is sized for one or two developer.
If we had a very big one, we will most probably split it in more apps/
projects.

Each project is deployed in a separate instance unless we have an apps
made of more than one module in which case we deploy the apps in a teh
same logical instance.
We don't mind rewriting BCs, VOs etc.. per project if necessary, it
brings independency to the apps and ease maintenance.

[Chris Muir]

Wes, a few links hopefully relevant to your discussion:
:
1) Using multiple faces-config.xml files in JSF
http://one-size-doesnt-fit-all.blogspot.com/2007/01/using-multiple-faces-configxml-files-in.html

2) Using multiple DataBindings.cpx files in JDev 11g
http://one-size-doesnt-fit-all.blogspot.com/2008/06/using-multiple-databindingscpx-files-in.html

3) A general chat about files that cause team development headaches in
JDev 10g on the OTN forums, including the "touched" project files:
http://forums.oracle.com/forums/thread.jspa?forumID=83&threadID=637335

Simon Haslam also has a Business Components/ViewController standards
document that the group contributed to for the 2008 OOW that may shed
some further highlights on application composition, though it is JDev
11g specific. You can post Simon directly from this group.

Cheers,

CM.

[Simon Haslam]

> Simon Haslam also has a Business Components/ViewController standards
> document that the group contributed to for the 2008 OOW that may shed
> some further highlights on application composition, though it is JDev
> 11g specific.

It's on the Wiki now here:
http://wiki.oracle.com/page/ADF+Coding+Standards

Wes - thanks for your comments earlier - if you have any suggestions
or comments on the coding standards please post suggestions/comments
on this discussion thread:
http://groups.google.com/group/adf-methodology/browse_thread/thread/422fe5c42ae933ba?hl=en#


Simon

[Sandra Muller]

Instead of splitting up into several JDeveloper projects, I recommend
using Working Sets (see http://blogs.oracle.com/jheadstart/2008/10/jdeveloper_11g_working_sets_ho.html
) for creating subsets within a project. Then you don't have the
complexities of gathering files from multiple projects into one WAR
file, but you can still develop while seeing only a relevant subset of
all the project files.

Hope this helps,
Sandra

[Chris Muir]

Hi Sandra,

Taking your idea on board, you're therefore advocating one uber (read:
large) application at each site, rather than split into many separate
applications?

Obviously a bug-bear for developers in earlier releases of JDev with
large applications was the slow down/performance issues within the IDE
working with the amount of files, and this is what 11g's working sets
overcomes, correct? Can you give us any indication how far has Oracle
stress tested this? Should we see less memory used by JDev using
working sets?

This leads on to asking your expert opinion when/where do you think it
appropriate to use the new 11g ADF Library facility?

Regards,

CM.

[Todd]

We are starting in on the development of a new application using JDev
11g and after reading several of the discussions, I'd like to see if
I'm understanding the latest thinking about how to structure
applications in JDev 11g.

[I seem unable to post this to some of the older topics, so I'm adding
this here (not sure if this is how it is supposed to be done)].

I've tried to synthesize what I understand from the Coding Standards
topics in this Group as well as what is available on the Wiki.

I got a bit confused by the Example Project Structure on the wiki
(http://wiki.oracle.com/page/ADF+Coding+Standards), but maybe I'm just
getting the terminology mixed up in my head. That diagram seems to
show each task flow as something other that a JDev Application
Workspace.

I also want to better understand how reuse occurs using libraries, so
I tried to add those below as well.

Basically, everything is broken down into JDev Application Workspaces,
then jarred up and reused.

Am I on the right track with the following layout for a new
Application?

-------------------------------------------------------------------------------------------
Master JDev Application Workspace (i.e., the final Application)
- Common_JDev _Lib_JAR
- Taskflow1_JDev _Lib_JAR
- Taskflow2_JDev _Lib_JAR
- Taskflow3_JDev _Lib_JAR
- Taskflow4_JDev _Lib_JAR
- Model JDev project
- ViewController JDev project

Common JDev Application Workspace --> reuse as Common_JDev _Lib_JAR
- Framework_JAR (include in Common_JDev _Lib_JAR)
- Model JDev project (EOs, AOs, lookup VOs, shared AMs, but not task
flows)

Framework JDev Application Workspace --> reuse as Framework_JAR
- Generic JDev project
- Testing JDev project

Taskflow1 Application Workspace --> reuse as Taskflow1_JDev _Lib_JAR
- Common_JDev _Lib_JAR
- Model JDev project (VOs, EOs?, AMs)
- ViewController JDev project

Taskflow2 Application Workspace --> reuse as Taskflow2_JDev _Lib_JAR
- Common_JDev _Lib_JAR
- Model JDev project (VOs, EOs?, AMs)
- ViewController JDev project

Taskflow3 Application Workspace --> reuse as Taskflow3_JDev _Lib_JAR
- Common_JDev _Lib_JAR
- Model JDev project (VOs, EOs?, AMs)
- ViewController JDev project

Taskflow4 Application Workspace --> reuse as Taskflow4_JDev _Lib_JAR
- Common_JDev _Lib_JAR
- Model JDev project (VOs, EOs?, AMs)
- ViewController JDev project

. . .

Taskflows as needed

To complete the final Application as shown above would require 7 JDev
Application Workspaces.

[Chris Muir]

Hi Todd

Great summary! :-)

You're right, the original standards document needs some work. It was
an online collaboration from this group before Oracle OpenWorld 08,
and summarised by Simon who had the challenge of bringing all our
ideas together. Simon did a great job, but we still have some work to
do. (long handed way of saying your mileage may vary ;-) You're
summary will help us get there!

Couple of things I'd like to note:

1) Please remember the standards doc is a proposed structure. Many of
us are in the process of building 11g applications given it's recent
release, so experience will tell if the proposals are a good idea.
Hopefully the Oracle staff on this group can point us in the right
direction (hint hint).

2) As per Sandra's post to this thread, a different approach is just 1
large application using Working Sets to hide detail. I'm going to
guess at this stage, that both approaches are theoritically valid, but
just have different advantages and disadvantages which may or may not
suit different sites and/or application types. For example I believe
"remote task flows" would not be appropriate for the 1 large
application approach, it would be suited to the approach you've now
fully described. However the downside of the multi-application
approach is library and dependency management and more.

(Why did I say theoritically? Both working sets and managed ADF
libraries are new JDev 11g features and we may find after building new
apps that one or the other has bugs in the IDE that make them
unusuable).

On taking on your summary, couple points I'd like to make:

1) As you've correctly identified, it's not clear if the EOs go in the
TaskFlow applications. I believe our conclusion was if you wanted to
make fully contained & complete task flows (say your a vendor selling
software parts), or possibly if you're using remote task flows, EOs
should go in the task flow application. This has the advantage you
can give someone the task flow app, they don't need anything more to
run it (well, besides the common app). Disadvantage is you may end up
with the same EO specified multiple times in different task flow
applications, avoiding the EO reuse facilities.

As such if reuse is key for EOs, then they should probably all go in
the common app, to be reused by all the taskflow apps.

2) Typically only 1 AM per TaskFlow, not AMs. And as you've correctly
identified shared AMs should probably go in the common app.

3) Also in your common app, page templates, skins, and possibly (just
not sure) declarative components (these can be JARed for ADF Libraries
too).

4) You will also end up in a situation where 1 task flow app consumes
another, it wont necessarily be used by the master app.

5) What's an AO?

One of the reasons I like this approach is it gets programmers off
working on their small part of the app without interferring with each
other. One of the reasons to be wary of this approach is it allows
programmers to work in their small part of the app without talking to
each other!

I suspect library & dependency management will become a bugbear in the
longterm with this approach, but in turn I suspect that's the usual
trade off that we see in computing where flexibility breeds
complexity. With this in mind I'd probably be suggesting JDev
beginners to start with the 1 large app approach, but on moving to
their 2nd project start looking at the multi-task-flow-app approach.
At that stage some research into how to manage your builds could save
lots of effort later.

With the multi-task-flow app approach, it would be probably prudant to
build a very simple 1 master app, 1 common app, and 2 task flow app
prototype, to walk through all the issues.

I hope to be going down this line myself very soon. I know myself and
others on this group would be interested in hearing your further
questions, as well as successes and failures (hopefully successes).

Cheerio,

CM.

[Sandra Muller]

In response to Chris' earlier questions:

On Jan 6, 1:13 pm, Chris Muir <chriscm...@gmail.com> wrote:
> Hi Sandra,
>
> Taking your idea on board, you're therefore advocating one uber (read:
> large) application at each site, rather than split into many separate
> applications?

Yes, at least for the parts that you want to deploy together in one
WAR file. If you want to have multiple separate WAR files, then I'd
use one JDev application per WAR file. To be more specific, this
applies mainly to ViewController projects. In my opinion it is too
much overhead to try and split up ViewController projects if you want
to deploy them as a single WAR, but for Model projects there is no
problem in splitting it up into multiple libraries.

> Obviously a bug-bear for developers in earlier releases of JDev with
> large applications was the slow down/performance issues within the IDE
> working with the amount of files, and this is what 11g's working sets
> overcomes, correct?

In 10g there was a performance issue with having multiple faces-config
files in one ViewController project, for which you can find a
workaround in http://blogs.oracle.com/jheadstart/2007/11/speeding_up_jdeveloper_1013.html#faces-configs
, but Working Sets did not overcome that issue. I wrote
http://blogs.oracle.com/jheadstart/2006/09/jdeveloper_1013_tip_sharing_wo.html
when using working sets in the same application where we had the
multiple faces-configs, and we still needed the workaround for the
performance issue.

However, in 11g, when using ADF Controller, you typically have
multiple adfc-config files instead of faces-config files, and they do
not have that kind of performance issues.

> Can you give us any indication how far has Oracle
> stress tested this? Should we see less memory used by JDev using
> working sets?

I don't know about stress tests, but I have used working sets myself
in 10g and am using it now in 11g, and the main benefit to me is the
overview in the navigator: I see less folders and files and therefore
can find the file I need more quickly. I have not paid attention to
the memory used, but I can imagine that it is more efficient.

I have noticed that in 11g, the working sets are not able to include
just a single Business Component, if you include a single component
you get the whole package (folder) in which that Business Component is
located. So it would help if you have separate ADF BC packages for the
business components you want to have in separate working sets.

> This leads on to asking your expert opinion when/where do you think it
> appropriate to use the new 11g ADF Library facility?

You can certainly use libraries for Business Components. On the other
hand, for ADF BC, the (10g style) jar file approach works just as well
as an ADF Library, and is easier to automate using Ant or Maven. I
have not looked at packaging task flows in ADF Libraries yet, I think
that for reusable task flows ADF Libraries will also be appropriate.

Hope this helps,
Sandra

[Nathalie Roman]

Hi Sandra,

I was wondering how a development team can shift from a 10g
application to an 11g application in this context?
If the team already has followed the guidelines regarding packaging of
the ADF BC application and now wants to use all the capabilities of
the 11g applications.

How could you then use the existing investments to migrate to an 11G
application using the above proposed actions?

For example when talking about deployment and war- or ear-files. If
you're using a deployment plan to package your appliction propely,
would this be a common approach in 11g as well. Because in 11g we're
moving forward to the MDS-like approach which makes me wonder how an
existing customer, development team can benefit from the new features
without needing to refactor, repackage the application first.

Kind regards,
Nathalie

On Jan 8, 9:26 am, Sandra Muller <sandra.mul...@oracle.com> wrote:
> In response to Chris' earlier questions:
>
> On Jan 6, 1:13 pm, Chris Muir <chriscm...@gmail.com> wrote:
>
> > Hi Sandra,
>
> > Taking your idea on board, you're therefore advocating one uber (read:
> > large) application at each site, rather than split into many separate
> > applications?
>
> Yes, at least for the parts that you want to deploy together in one
> WAR file. If you want to have multiple separate WAR files, then I'd
> use one JDev application per WAR file. To be more specific, this
> applies mainly to ViewController projects. In my opinion it is too
> much overhead to try and split up ViewController projects if you want
> to deploy them as a single WAR, but for Model projects there is no
> problem in splitting it up into multiple libraries.
>
> > Obviously a bug-bear for developers in earlier releases of JDev with
> > large applications was the slow down/performance issues within the IDE
> > working with the amount of files, and this is what 11g's working sets
> > overcomes, correct?
>
> In 10g there was a performance issue with having multiple faces-config
> files in one ViewController project, for which you can find a

> workaround inhttp://blogs.oracle.com/jheadstart/2007/11/speeding_up_jdeveloper_101...
> , but Working Sets did not overcome that issue. I wrotehttp://blogs.oracle.com/jheadstart/2006/09/jdeveloper_1013_tip_sharin...

[Todd]

Chris,

'AO' stands for [Entity] Association Object. I borrowed this from the
OAF guidelines that were available on metalink (per a previous
posting). As already noted, it may be easier to just keep the default
Fk name that JDev creates from the schema.

I appreciate your input -- we're going to go ahead with the multi-app-
workspace approach and take your advice of doing this on a small
scale.

I'll report back on our findings.

-Todd

[Sandra Muller]

There is documentation about the approach recommended by the
JHeadstart Team, which is basically one ViewController per application
combined with optionally multiple Model proejcts. You can find the
documentation in the JHeadstart Developer's Guide at
http://download.oracle.com/consulting/jhsdevguide1013.pdf . Even
though it was written for JDeveloper 10.1.3, most still applies in
11g.

Have a look at the following sections:
* 2.2. Setting up Structure of JDeveloper Workspace
* 2.4. Defining Java Package Structure and Other Naming Conventions
(also covers ADF BC)
* 3. Creating ADF Business Components, which among others recommends
which default ADF BC names should be changed.

Hope this helps,
Sandra

[Susan Duncan]

Hi All,

Part of the decision as to how to use projects and applications is
also influenced by your SCM approach. If you are using something like
SVN and the copy-modify-merge approach rather than the lock-modify-
unlock approach then your issues are going to be different. When I
took a straw poll at my SCM session at OW I was surprised at how many
groups are using lock-modify-unlock. The reasons were also varied,
from historical to binary files to products being used.

In the JDeveloper engineering group we use both our internal system
and SVN in a copy-modify-merge environment with continuous
integration. We also use one large application with many, many
projects. Because features tend to be primarily worked on by different
engineers we try to keep merge conflicts (and build breakages) to a
minimum - and of course it's not just the SCM system and process that
is important but the communication between engineers. At the end of
the day any process is only as good as the people that use it.

I created a document on working with SVN that is on OTN. I want and
need to continue to work and evolve it as we get more feedback from
customers (that's you) and it looks to me like the experience that you
are gathering here is going to produce a much better set of practices
than I can, alone.

- Susan

On Jan 9, 8:33 am, Sandra Muller <sandra.mul...@oracle.com> wrote:
> There is documentation about the approach recommended by the
> JHeadstart Team, which is basically one ViewController per application
> combined with optionally multiple Model proejcts. You can find the

> documentation in the JHeadstart Developer's Guide athttp://download.oracle.com/consulting/jhsdevguide1013.pdf. Even

[Sandra Muller]

On Jan 9, 9:33 am, Sandra Muller <sandra.mul...@oracle.com> wrote:
> Even though it was written for JDeveloper 10.1.3, most still applies in
> 11g.

On second thought, this might not be completely true. Using ADF
Libraries it has become easier to split up a ViewController project.
You keep one ViewController project for the WAR/EAR file, and others
create ADF Libraries that are used in the main ViewController project.

Hope this helps,
Sandra

[Chris Muir]

Following up on your last point Sandra, if we consider the model
project alone, it does look like JDev 11g's ADF Libraries changes how
we construct the app, though not much. To quote a section from the
JHeadstart ADF Dev Guide you referred earlier:

"Reasons to create multiple Model projects include:

• A layer of entity objects and/or view objects, and associated
business rules will be used by multiple applications. In such a
situation it makes sense to create a separate Model project for these
entity objects (in a separate workspace if you like), create a Jar
file of this model project which can then be imported into your
application-specific Model project so you can create view objects on
top of these entity objects. Note that the entity objects can only be
changed in the owning Model project, not in the project in which they
are imported."

...if you look at the good summary of the ADF Methodology Group
project standards that Todd came up with earlier in this thread, it
proposes a similar thing:

Framework JDev Application Workspace --> reuse as Framework_JAR
- Generic JDev project
- Testing JDev project

Common JDev Application Workspace --> reuse as Common_JDev _Lib_JAR
- Framework_JAR (include in Common_JDev _Lib_JAR)
- Model JDev project (EOs, AOs, lookup VOs, shared AMs, but not task
flows)

Taskflow1 Application Workspace --> reuse as Taskflow1_JDev _Lib_JAR
- Common_JDev _Lib_JAR
- Model JDev project (VOs, EOs?, AMs)
- ViewController JDev project

Taskflow2 Application Workspace --> reuse as Taskflow2_JDev _Lib_JAR
- Common_JDev _Lib_JAR
- Model JDev project (VOs, EOs?, AMs)
- ViewController JDev project

etc

... the finally the Master JDev Application Workspace (i.e., the final

Application)
- Common_JDev _Lib_JAR
- Taskflow1_JDev _Lib_JAR
- Taskflow2_JDev _Lib_JAR
- Taskflow3_JDev _Lib_JAR
- Taskflow4_JDev _Lib_JAR
- Model JDev project
- ViewController JDev project

...I guess one key different between the JHeadstart recommendation and
what we're proposing, is under JDev 11g it's up to each task flow and
the master jdev app to override the model components that come from
the Common_JDev _Lib_JAR.


If we go onto consider the ViewController project, to quote another
section from the JHeadstart guide:

"We do not recommend to create multiple ViewController projects. The
application needs to be deployed as one web application (.war file),
and creating multiple ViewController projects will create duplicates
of files that will complicate the deployment process."

...I'd like to add another important reason for one ViewController
project is it's incredibly hard to share state across several
ViewController applications. The introduction of task flow URL
parameters will make this easier in JDev11g, but not as easy as having
everything embedded in the 1 app. Of course the negative on this (in
my uninformed opinion) would be you'll end up with at runtime with one
massive application running in your application server, with all the
usual resourcing issues.

Cheers,

CM.

[Soyer, Muhammed A.]

Hi All,
We are trying to decide how to layout our application and a little confused. We are planning to use ADF libraries extensively.
We made it more granular and separated the EO and AM projects , we put each in different workspaces and re-used them as ADF libraries. We re-use the AM ADF libraries in taskflow projects.
The biggest difference in our approach is we don't have silos of artifacts as it is proposed in the previous approach.

This is what we think so far

I need inputs from others about the applicability of this approach..

Thanks

Framework JDev Application Workspace --> reuse as Framework_JAR
- Generic JDev project
- Testing JDev project

Common JDev Application Workspace --> reuse as Common_JDev _Lib_JAR
- Framework_JAR (include in Common_JDev _Lib_JAR)
- Model JDev project (EOs, AOs, lookup VOs, shared AMs, but not task
flows)

EO stands for Entity Object

EO1 Application Workspace --> reuse as EO1_JDev _Lib_JAR
- Common_JDev _Lib_JAR
- Model JDev project EO

EO2 Application Workspace --> reuse as EO2_JDev _Lib_JAR
- Common_JDev _Lib_JAR
- Model JDev project EO

AM stands for Application Module

AM1 Application Workspace --> reuse as AM1_JDev _Lib_JAR
- Common_JDev _Lib_JAR
- EO1_JDev _Lib_JAR, EO2_JDev _Lib_JAR
- Model JDev project VO,AM

AM2 Application Workspace --> reuse as AM2_JDev _Lib_JAR
- Common_JDev _Lib_JAR
- EO1_JDev _Lib_JAR, EO2_JDev _Lib_JAR
- Model JDev project VO,AM

Taskflow1 Application Workspace --> reuse as Taskflow1_JDev _Lib_JAR
- Common_JDev _Lib_JAR

- AM1_JDev _Lib_JAR,(If required AM2_JDev _Lib_JAR)

- ViewController JDev project

Taskflow2 Application Workspace --> reuse as Taskflow2_JDev _Lib_JAR
- Common_JDev _Lib_JAR

- AM2_JDev _Lib_JAR, (If required AM1_JDev _Lib_JAR)

- ViewController JDev project

etc

... the finally the Master JDev Application Workspace (i.e., the final
Application)
- Common_JDev _Lib_JAR
- Taskflow1_JDev _Lib_JAR
- Taskflow2_JDev _Lib_JAR
- Taskflow3_JDev _Lib_JAR
- Taskflow4_JDev _Lib_JAR
- Model JDev project
- ViewController JDev project

-----Original Message-----
From: adf-met...@googlegroups.com [mailto:adf-met...@googlegroups.com] On Behalf Of Chris Muir
Sent: Thursday, January 15, 2009 1:20 AM
To: ADF Methodology
Subject: Re: ADF Faces & BC: Best pratices for project layout


Following up on your last point Sandra, if we consider the model
project alone, it does look like JDev 11g's ADF Libraries changes how
we construct the app, though not much. To quote a section from the
JHeadstart ADF Dev Guide you referred earlier:

"Reasons to create multiple Model projects include:

* A layer of entity objects and/or view objects, and associated

[Chris Muir]

Hi Muhammed

I've been reading your approach today. Can I seek some clarifications
please?

1) The individual EO workspaces such as EO1_JDev _Lib_JAR - will these
be grouped by logical unit of work (ie. raise purchase order) or
subsystem (ie. procurement)?

2) What's the purpose of each AM1 Application Workspace (I note AM1
and AM2) having exactly the same EO workspaces (ie. EO1, EO2 etc)?
Presumably you meant only if required here?

3) If #2 is only as required, what situation do you see a single AM
Application Workspace requiring 2 EO workspaces? Would it be where
you need EO instance 1 form EO1 workspace and EO instance 2 from EO2
workspace? Wouldn't that EO instance be a candidate for moving into
the common workspace.

Remember there is an argument that all EOs be pushed to the Common
workspace anyway.

If I'm understanding your approach correctly, I think the main issue I
see is a multiplication of library dependencies. What I'm not clear
on is the specific advantage you're trying to harness here and what
use case you see this advantage being important for.

Maybe if you've some more time, you can spell out your ideas and
people in the group can comment.

Enjoy your weekend.

Regards,

CM.

[Soyer, Muhammed A.]

Hi Chris,

Actually we were working on the layout and we decided to change it.. It became more closer to your questions' directions now.

Our application is a big application and we are more than 40 developers so we are trying to make the project layout as granular as possible to ease source code management and merging issues.

Here is what we have now ...

Framework JDev Application Workspace --> reuse as Framework_JAR
- Generic JDev project
- Testing JDev project

Common JDev Application Workspace --> reuse as Common_JDev _Lib_JAR
- Framework_JAR (include in Common_JDev _Lib_JAR)
- Model JDev project (EOs, AOs, lookup VOs, shared AMs, but not task
flows)

Model Layer================
---------------------------

Model Application Workspace
Model Project 1 -( Logical Unit ex: Reservation) -> reuse as Model1_JDev_Lib_JAR
- Common_JDev_Lib_JAR
- Model JDev Project EO,VO,AM

Model Project 2 -( Logical Unit ex: Rates) -> reuse as Model2_JDev_Lib_JAR
- Common_JDev_Lib_JAR
- Model JDev Project EO,VO,AM


View Layer================
--------------------------

ViewWorkSpace1 (Reservation) Application Workspace

Taskflow1 Project (Create Reservation) --> Reuse as ViewWorkSpace1_Taskflow1JDev_Lib_JAR
- Common_JDev_Lib_JAR
- Model1_JDev_Lib_JAR, Model2_JDev_Lib_JAR, ViewWorkSpace2_Taskflow2JDev_Lib_JAR
- ViewController JDev project

Taskflow2 Project (Reservation Preferences) --> Reuse as ViewWorkSpace1_Taskflow2JDev_Lib_JAR
- Common_JDev_Lib_JAR
- Model1_JDev_Lib_JAR, Model2_JDev_Lib_JAR , Model(N)_JDev_Lib_JAR ...
- ViewController JDev project



ViewWorkSpace2 (Rates) Application Workspace

Taskflow1 Project (Create Rate) --> Reuse as ViewWorkSpace2_Taskflow1JDev_Lib_JAR
- Common_JDev_Lib_JAR
- Model2_JDev_Lib_JAR, Model(N)_JDev_Lib_JAR ...
- ViewController JDev project

Taskflow2 Project (Rate Details) --> Reuse as ViewWorkSpace2_Taskflow2JDev_Lib_JAR
- Common_JDev_Lib_JAR
- Model2_JDev_Lib_JAR, Model(N)_JDev_Lib_JAR ...

- ViewController JDev project

etc

... the finally the Master JDev Application Workspace (i.e., the final
Application)
- Common_JDev_Lib_JAR
- Taskflow1_JDev_Lib_JAR
- Taskflow2_JDev_Lib_JAR
- Taskflow3_JDev_Lib_JAR
- Taskflow4_JDev_Lib_JAR
- Model JDev project
- ViewController JDev project

-----Original Message-----
From: adf-met...@googlegroups.com [mailto:adf-met...@googlegroups.com] On Behalf Of Chris Muir