Structuring a large Liferay portlet project
We are starting some work on a large a portlet development work using Liferay and I am finding it difficult to structure this project in terms of various portlets we are creating. We are not sure which way should we structure our project. We have distributed development team across world开发者_运维技巧 and we are using git as our version repository. We are using Spring Portlet MVC for developing portlets and using service builder for service layer.
I can think about these 3 approaches.
Create a New Portlet project for each portlet
- Keeping each portlet in a separate portlet project can be easy and fast in development since I can have developers independently working on them.
- This may become pain in cases when portlets use common code. So there can be lot of proliferation of same type of code in different portlets.
- This may go out of control since we will have many war files and each add to runtime cost of us.
Logically separate portlets into number of portlet projects
- This will reduce the number of portlet projects and lot of code can be reused.
- Some control can be placed in such structure.
Create just one portlet project with all portlets
- This will be most complicated to manage for distributed developer team.
- Most of common code can be reused.
- Enforcing consistency can be easier in this.
Mix of 1 and 2 (Based on my discussion with Dirk in comments below) This approach needs to be mix of 1 and 2 I guess.
- I would want to give each developer a independent portlet dev env along with some guidelines on common components.
- This way they have more control on their portlet code and only focus on portlet specific code.
- At the same time common code may need to have more control since multiple people may modify it.
I would like to know your expert opinion if you have already created liferay projects/portlets and what approach you chose. Keeping these things in mind
- How do you control the portlet development when there are multiple portlets being developed by variety of developers.
- What are pros/cons of any of the above approaches above mentioned.
- If none of the above mentioned approaches are good please mention the best approach to this you can think of.
Thanks for reading
Adding just something to Dirk's answer, my rule of thumb is to have portlets with a similar maintenance cycle in the same project - e.g. if you update one of them you typically update all of them, because they make an application, presenting the same data through different UIs. This is basically your option 2.
Other than that you nailed the options quite good - the answer is "in the middle". Balance separation with app-server overhead. Use the rule of thumb above and you're set.
With regards to development environments: Every developer should work on their own environment, however, through version control they can - of course - work on the same projects.
I think it pretty much depends on what kind of project you are actually building. Are the portlets you are talking about portlets in the sense of encapsulated functionality and will be used as such (i.e. as portlet in Liferay finally)? Those should be put in different projects in my opinion if their functionality of those is disjoint and they don't depend on eachother.
If you have a core of functionality (e.g. persistence layer and associated logic or other business logic) you should definitely reuse this in as much as possible. Thus, I don't think (1) is a good solution and this common logic should be grouped in a seperate project for instance and the portlets themselves depend on this.
As a general approach: what would be the problem to let the developers all have access to all (or most) projects? The common code could be reused by all portlets and still everyone would have to only work on his/her part.
精彩评论