Re: [macker-user] Evaluation questions
Brought to you by:
barredijkstra,
melquiades
Menu
▾
▴
Re: [macker-user] Evaluation questions
|
From: Pablo M. S. <pab...@gm...> - 2008-09-19 02:03:27
|
I cant make it work. What should I change?
Regards
2008/9/16 Pablo Mosquera Saenz <pab...@gm...>
> 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/
>>
>
>
|
