Thread: [macker-user] Evaluation questions
Brought to you by:
barredijkstra,
melquiades
Menu
▾
▴
macker-user
|
From: Pablo M. S. <pab...@gm...> - 2008-09-05 11:02:12
|
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 |
|
From: Paul C. <can...@po...> - 2008-09-08 16:52:30
|
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/ |
|
From: Pablo M. S. <pab...@gm...> - 2008-09-09 14:25:13
|
Thanks Paul. I will try to make it work in my project. First, I will give you some tips of the project Im developing an architectural SOA solution (as a framework) using spring, hibernate, jsf, sso,... and I have defined some base classes. I want to check that other projects developed with this solution are using the rules defined. My first problem: I downloaded macker. Im using ant 1.6.5, jdk 1.5. Do you know if I would have any problem using JDK 1.5 and macker? To integrate macker in one application, I only have to make the build file to target "macker" http://innig.net/macker/guide/ant.html 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/ > |
|
From: Pablo M. S. <pab...@gm...> - 2008-09-15 12:00:42
|
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/
>
|
|
From: Paul C. <can...@po...> - 2008-09-16 08:31:04
|
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/
>
|
|
From: Pablo M. S. <pab...@gm...> - 2008-09-22 07:53:45
|
Hi Paul, Im still trying to define the rules and have some problems
<foreach var="dao" class="(**Dao)Impl">
<pattern name="dao-impl" class="${dao}Impl"/>
<access-rule>
<message>**DaoImpl debe extender BaseDao</message>
<deny>
<from>
<include pattern="dao-impl"/>
<exclude filter="subtype-of"
class="${base}.framework.core.dao.impl.BaseDao"/>
</from>
<to class="java.lang.Object"/>
</deny>
</access-rule>
My first question is that if I deny to class "java.lang.Object" what happens
if the class have references to other classes. For example
I have this class and have a lot of references to other classes:
import java.util.ArrayList;
import java.util.Calendar;
import java.util.Collection;
import java.util.ListIterator;
import java.util.Map;
import java.util.Properties;
import org.hibernate.FetchMode;
import org.hibernate.Session;
import org.hibernate.criterion.DetachedCriteria;
import org.hibernate.criterion.Restrictions;
import framework.core.dao.impl.BaseDao;
import framework.core.domain.MasterTablePojo;
import framework.core.domain.RoleMasterTablePojo;
import framework.core.domain.id.RoleMasterTableIdPojo;
import framework.core.dto.MasterTableDto;
import framework.core.dto.PagedDto;
import framework.core.util.exception.DataBaseException;
import framework.infrastructure.dao.MasterTableDao;
public class MasterTableDaoImpl extends BaseDao implements MasterTableDao {
All this references are going to break the rule?
I would test if this happens but have another problem. When I execute macker
with this rule, I have this output:
(other rules checking)
....
....
[macker] (dao: prueba.dao.impl.seminarioDao)
[macker] (11 errors)
[macker] Macker rules checking failed
macker-report:
[echo] Macker report:
C:\pruebaSeminarioService\report\macker-report.html
BUILD SUCCESSFUL
Total time: 3 seconds
C:\pruebaSemina
rioService>
and the report shows for this rule
dao: prueba.dao.impl.seminarioDao
If I change the rule definition with
<include pattern="dao-impl"/>
<exclude filter="subtype-of"
class="${base}.framework.core.dao.impl.BaseDao"/>
<exclude filter="subtype-of"
class="prueba.dao.impl.seminarioDao"/>
I can execute macker but the output...
dao: prueba.dao.impl.seminarioDao
error
**DaoImpl debe extender BaseDao
From:prueba.dao.seminarioDao To:java.lang.Object
error
**DaoImpl debe extender BaseDao
From:prueba.dto.impl.mensajeDtoImpl To:java.lang.Object
error
**DaoImpl debe extender BaseDao
From:prueba.dto.mensajeDto To:java.lang.Object
error
**DaoImpl debe extender BaseDao
From:prueba.pojo.seminarioPojo To:java.lang.Object
error
**DaoImpl debe extender BaseDao
From:prueba.service.impl.pruebaServiceImpl To:java.lang.Object
error
**DaoImpl debe extender BaseDao
From:prueba.service.pruebaService To:java.lang.Object
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/
>
|
|
From: Pablo M. S. <pab...@gm...> - 2008-09-16 08:35:03
|
The solution you gave me for the Exception works great. I apply it to my
interfaces
<access-rule severity="error">
<message>La capa SERVICE sólo pueden lanzar excepciones de tipo
ServiceException</message>
<deny>
<from pattern="serviceInterface" />
<to pattern="exception" />
<allow>
<to>
<include
class="${base}.framework.core.util.exception.ServiceException"/>
</to>
</allow>
</deny>
</access-rule>
<access-rule severity="error">
<message>La capa DAO sólo pueden lanzar excepciones de tipo
DataBaseException</message>
<deny>
<from pattern="daoInterface" />
<to pattern="exception" />
<allow>
<to>
<include
class="${base}.framework.core.util.exception.DataBaseException"/>
</to>
</allow>
</deny>
</access-rule>
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/
>
|
|
From: Paul C. <can...@po...> - 2008-09-16 10:29:21
|
Looks great.
Man, I really wish I had time / funding to work on another version of
Macker. A few new features could make this much simpler.
P
On Sep 16, 2008, at 10:34 AM, Pablo Mosquera Saenz wrote:
> The solution you gave me for the Exception works great. I apply it
> to my interfaces
>
> <access-rule severity="error">
> <message>La capa SERVICE sólo pueden lanzar excepciones
> de tipo ServiceException</message>
> <deny>
> <from pattern="serviceInterface" />
> <to pattern="exception" />
> <allow>
> <to>
> <include class="$
> {base}.framework.core.util.exception.ServiceException"/>
> </to>
> </allow>
> </deny>
> </access-rule>
>
> <access-rule severity="error">
> <message>La capa DAO sólo pueden lanzar excepciones de
> tipo DataBaseException</message>
> <deny>
> <from pattern="daoInterface" />
> <to pattern="exception" />
> <allow>
> <to>
> <include class="$
> {base}.framework.core.util.exception.DataBaseException"/>
> </to>
> </allow>
> </deny>
> </access-rule>
>
>
> 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/
|
|
From: Pablo M. S. <pab...@gm...> - 2008-09-16 11:07:18
|
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/
>
|
|
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/
>>
>
>
|
|
From: Paul C. <can...@po...> - 2008-09-23 14:24:35
|
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/
|
|
From: Pablo M. S. <pab...@gm...> - 2008-09-23 14:51:43
|
Thanks Paul, I have now all my rules working
2008/9/23 Paul Cantrell <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/
>
>
>
> -------------------------------------------------------------------------
> 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/
>
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X