Re: [macker-user] Evaluation questions

[Paul C. <can...@po...>]

Yes, your rules file is very good! You definitely have the right idea.

> All classes of type *DaoImpl must extend BaseDao and implement their  
> own interface (FooDaoImpl must implement FooDao for example)

You can do this, though it's a bit messy. In order to say "X must be  
true for all Y," set up an access rule that denies references from Y  
minus X to java.lang.Object. So your case would look like this:

     <!-- warning: untested code! -->
     <foreach var="dao" class="(**Dao)Impl">
         <pattern name="dao-impl" class="${dao}Impl"/>

         <access-rule>
             <message>DaoImpls must extend BaseDao</message>
             <deny>
                 <from>
                     <include pattern="dao-impl"/>
                     <exclude filter="subtype-of"  
class="foo.bar.BaseDao"/>
                 </from>
                 <to class="java.lang.Object"/>
             </deny>
         </access-rule>

         <access-rule>
             <message>DaoImpls must implement the corresponding  
interface</message>
             <deny>
                 <from>
                     <include pattern="dao-impl"/>
                     <exclude filter="subtype-of" class="${dao}"/>
                 </from>
                 <to class="java.lang.Object"/>
             </deny>
         </access-rule>
     </foreach>

If the FooDao interface and FooDaoImpl are in different packages,  
you'll need to capture the class and package name separately in the  
foreach. Let me know if you need help w/that.

Cheers,


Paul


On Sep 15, 2008, at 7:00 AM, Pablo Mosquera Saenz wrote:

> Hi Paul, I want some advice for my rules definition. Could you  
> please tell me if Im going in the right way?
>
> I want to define some rules:
>
> Base patterns
>
>          <var name="base" value="es.xunta.cptopt" />
>
>         <pattern name="java-api" class="java*.**" />
>         <pattern name="exception" class="**Exception" />
>         <pattern name="service-layer" class="${base}.**.service.**" />
>         <pattern name="dto-layer" class="${base}.**.dto.**" />
>         <pattern name="pojo-layer" class="${base}.**.pojo.**" />
>         <pattern name="dao-layer" class="${base}.**.dao.**" />
>         <pattern name="bundle-layer" class="${base}.**.bundle.**" />
>         <pattern name="hibernate-layer" class="org.hibernate.**" />
>         <pattern name="bb-layer" class="$ 
> {base}.**.view.impl.**.*BB*" />
>
>         <pattern name="bbData" class="$ 
> {base}.**.view.impl.**.*Data" />
>
>         <pattern name="daoInterface" pattern="dao-layer">
>             <exclude class="${base}.**.dao.impl"/>
>         </pattern>
>         <pattern name="serviceInterface" pattern="service-layer">
>             <exclude class="${base}.**.service.impl"/>
>         </pattern>
>         <pattern name="dtoInterface" pattern="dto-layer">
>             <exclude class="${base}.**.dto.impl"/>
>         </pattern>
>
>
> Only DAO and POJO layer classes can access to hibernate layer classes
>
> <access-rule severity="error">
>             <message>Solo la capa DAO y POJO pueden acceder a la  
> capa HIBERNATE</message>
>             <deny>
>                 <to pattern="hibernate-layer" />
>                 <allow>
>                     <from pattern="dao-layer" />
>                     <from pattern="pojo-layer" />
>                 </allow>
>             </deny>
>         </access-rule>
>
> All classes of type *DaoImpl must extend BaseDao and implement their  
> own interface (FooDaoImpl must implement FooDao for example)
>
> Don´t know how this can be reached
>
> All SERVICE layer classes must access DAO layer classes through DAO  
> interfaces
>
> Can it be done this?
>
>
> Thanks
>
>
> 2008/9/8 Paul Cantrell <can...@po...>
> These are possible:
>
>> all classes of type *DaoImpl must extend BaseDao and implement  
>> their own interface (FooDaoImpl must implement FooDao for example)
>> all classes of type *ServiceImpl cant use *POJO classes
>> All classes of type *ServiceImpl can use *Dao but not *DaoImpl
>
> These are not quite possible:
>
>> all methods defined in *Service and *ServiceImpl can only throw  
>> ServiceException
>> all methods defined in *Dao and *DaoImpl can only throw  
>> DataBaseException
>
>
> The current version of Macker cannot distinguish between "throws"  
> and "uses." So you could write rules of the form "all methods in  
> *Dao and *DaoImpl cannot use any subclass of Exception except  
> DataBaseException," but that would cover throwing and catching.
>
> You can still probably do what you want. In an interface, "uses" can  
> only mean "throws." If you made that rule apply only to the  
> interfaces, it would prevent any API methods from throwing  
> exceptions other than DataBaseException — and the implementing  
> classes could therefore also only throw those exceptions.
>
> Cheers,
>
> Paul
>
>
> On Sep 5, 2008, at 6:02 AM, Pablo Mosquera Saenz wrote:
>
>>
>> Hi, Im looking for a tool to make that gives me some way to  
>> evaluate my architecture.
>>
>> The kind of rules I want to define are:
>>
>> all classes of type *DaoImpl must extend BaseDao and implement  
>> their own interface (FooDaoImpl must implement FooDao for example)
>> all classes of type *ServiceImpl cant use *POJO classes
>> All classes of type *ServiceImpl can use *Dao but not *DaoImpl
>> all methods defined in *Service and *ServiceImpl can only throw  
>> ServiceException
>> all methods defined in *Dao and *DaoImpl can only throw  
>> DataBaseException
>>
>> Can macker do this?
>>
>> Thanks in advance
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's  
>> challenge
>> Build the coolest Linux based applications with Moblin SDK & win  
>> great prizes
>> Grand prize is a trip for two to an Open Source event anywhere in  
>> the world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/_______________________________________________
>> Macker-user mailing list
>> Mac...@li...
>> https://lists.sourceforge.net/lists/listinfo/macker-user
>>
>> Macker home page: http://innig.net/macker/
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's  
> challenge
> Build the coolest Linux based applications with Moblin SDK & win  
> great prizes
> Grand prize is a trip for two to an Open Source event anywhere in  
> the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Macker-user mailing list
> Mac...@li...
> https://lists.sourceforge.net/lists/listinfo/macker-user
>
> Macker home page: http://innig.net/macker/
>