Re: [macker-user] Evaluation questions
Brought to you by:
barredijkstra,
melquiades
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/ >> > > |