Details
-
Type:
Task
-
Status:
Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 1.0.0
-
Fix Version/s: 1.1.0
-
Component/s: None
-
Labels:None
-
Number of attachments :
Description
In 1.0 is not easy use Trails without hibernate, or to remove a dependency or to replace the default security implementation with a custom implementation due to the high coupling level. To decouple I propose to modularize Trails as follows:
- trails-core: the 1.0 core but without any hibernate dependency.
- trails-hibernate: all the hibernate related code including the our Tapestry components with Hibernate dependencies.
- trails-security: all the security and Acegi related code.
- trails-test: includes the base classes for testing custom components and custom pages.
I guess I do not understand the need to couple
>trails-hibernate: all the hibernate related code including the our Tapestry >components with Hibernate dependencies.
Why cannot the tapestry components remain segregated in their own separate library?
Certainly they are usable in such a fashion? No?
Why are we adding on a new library?
I am trying to think about reduced confusion. If the tapestry components are packagable then they should remain segregated as such and used as such. For what personal purpose is this for and the likelihood of such usage to occur ? Commercially?
What are the advantages/disadvantages of the coupling? Or is it a hack? No offense I am just trying to get clarification.
Please advise/justify.