Re: [macker-user] Evaluation questions

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

Sorry for the slow response, Pablo.

Unfortunately, there's no way in Macker to match multiple  
subexpressions in a regexp to extract the package name. The best you  
can do is match on the class name.

Try something like this:

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

It won't detect all errors correctly if you have multiple DAO classes  
with the same name in different packages.

It sounds like you may have figured this out yourself! If so, yes,  
you're on the right track.

BTW, I noticed that the example code I sent you before was  
unnecessarily complex. This rule does not require a foreach:

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

The foreach is only necessary when you have to extract the class name  
and apply it in multiple places in the same access rule.

Cheers,

Paul


On Sep 16, 2008, at 1:07 PM, Pablo Mosquera Saenz wrote:

> Hi Paul, I have **DaoImpl and **Dao in diferent packages
>
> For example
>
> package test.dao.MyDao
> package test.dao.impl.MyDaoImpl
>
>
> How do I capture the names separatly?
>
> By the way, its the only opensource tool I have seen that let me  
> make this kind of things. Its great. Why you dont continue with it?
>
>
> Thanks
>
> 2008/9/16 Paul Cantrell <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/
>>
>
>
> -------------------------------------------------------------------------
> 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/