The main releases of our application are currently the projects. This consists of approx 2900 .p's (of which 600 are generated) and approx 2100 .i's.
I probably could break this up somewhat, but have not yet had any need. Working sets combined with eclipses resource cache work fabulously for fast searches across the code base.
Now with OE11.2 I am having a look at implementing REST for our current soap web services. After adding the required project facets and adding the rest annotation to one source I got to the point where I could map verbs.
The verb mapper is choking on the numer of sources and requiring several minutes for any attempt to bring up the list of mappable resources.
That smells buggy, but got me thinking again about what should a project be?
That smells buggy, but got me thinking again about what should a project
be?
>
For what it's worth, that's a great question. And you can add the meta-question: what should a workspace be? an application, a version of an app, a phase of the SDLC (ie dev, QA, production) or something else?
I tend to split my apps by layer (or function): so UI, BL and Data access all have their own projects. Furthermore, an app may be built on generic/framework code so you may get 2 projects for each layer: one for the app and one for the foundation/support/framework/sdk/whatever code.
But with the starting with BPM and the Mobile stuff, there's further scope to split the UI code (say) by client too. I don't have a clear answer for myself yet, and am interested in hearing your thoughts too.
-- peter
As soon as you mentioned started splitting up an application into multiple projects I instantly felt a need for grouping of projects, the workspace could actually fill this need quite nicely (I've managed to block multiple workspaces out so far).
Mapping projects to application layers, could be useful. This could then result in something that very much matches the division between the pls we deploy:
- user interface (generic renderer for webclient and web ui)
- business logic (coded + generated data layer)
- entity properties
- web services (soap) (generated)
- common includes (this obviously is not a pl)
It nearly seems logical.. Looking at our application we have multiple modules, finance, project, etc that could warrant a further split up of their business logic, properties and web services. On the other hand they could also be the projects instead of the layers - which is we have structured our directory structure. The layer division does feel more appealing though, I have previously also considered applying the layering to our directory structure because it feels more right.