Re: [macker-user] Evaluation questions

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

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/
>