macker-user Mailing List for Macker
Brought to you by:
barredijkstra,
melquiades
You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
(4) |
Sep
(1) |
Oct
|
Nov
(1) |
Dec
(2) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
(4) |
Feb
|
Mar
(2) |
Apr
(3) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2005 |
Jan
|
Feb
(1) |
Mar
(5) |
Apr
(1) |
May
(4) |
Jun
(1) |
Jul
|
Aug
|
Sep
(2) |
Oct
(7) |
Nov
(1) |
Dec
(4) |
2006 |
Jan
(1) |
Feb
(2) |
Mar
(4) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(2) |
2007 |
Jan
|
Feb
(4) |
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
(4) |
Sep
(3) |
Oct
(2) |
Nov
|
Dec
|
2008 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(12) |
Oct
|
Nov
|
Dec
(1) |
2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
2010 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Guy D. <guy...@al...> - 2015-07-22 17:47:20
|
Everyone, has anyone of you successfully ran Macker version 1.0.3 because we are moving to Java 8? Currently we are using Macker v0.4.2 via Ant targets. Problem that I encounter with Macker version 1.0.3, Macker cannot find a variable that I define as part of my <ruleset> as shown here: <ruleset name="Modularity (Class Loading of Realtime Implementation)"> <var name="module-base" value="com.mycompany.client.gui.realtime"/> ... Thanks Guy |
From: Michael S. <sw....@ve...> - 2010-03-27 19:23:44
|
Martin I have been using Macker for a while and have always used so far Ant to drive Macker. The Macker Ant plug-in takes over the responsibility of adding all class files in folders and subfolders. To my knowledge (also after reviewing the Macker source code) the command line interface requires you to add each individual class explicitly which is what you are observing as well. My recommendation is to set up the Ant file since this is the most convenient way of adding all files in folders and subfolders. Michael On Mar 26, 2010, at 4:55 PM, Martin McBride wrote: > I have just started using macker. > > There doesn't seem to be a way to point macker at a folder structure and have it analyse every class file in the hierarchy - have I missed something? I am using the command line interface from Windows. Perhaps the program is mainly intended as an Ant task, but I am not using Ant. > > Classycle supports folder trees with class and jar files - it seems a fairly natural thing to want to do. > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Macker-user mailing list > Mac...@li... > https://lists.sourceforge.net/lists/listinfo/macker-user > > Macker home page: http://innig.net/macker/ |
From: Martin M. <mcb...@gm...> - 2010-03-26 20:56:05
|
I have just started using macker. There doesn't seem to be a way to point macker at a folder structure and have it analyse every class file in the hierarchy - have I missed something? I am using the command line interface from Windows. Perhaps the program is mainly intended as an Ant task, but I am not using Ant. Classycle supports folder trees with class and jar files - it seems a fairly natural thing to want to do. |
From: Jayasree V. <Jay...@ig...> - 2009-09-17 06:33:52
|
Hey, I found the examples ranging from basic to regular expressions, but it did not clear the doubts I have. Can you please demonstrate, as to where the java class and the .class file should be stored? How to create a simple build.xml and macker.xml.The description of the directory structure of macker installation will be useful too. Any help will be appreciated. Regards, Jayasree Veliyath ____________________________________________________________________________________________________________________________________ Systems Associate|iNode|iGATE Global Solutions Limited|Office:+91-80-41044681|Jay...@ig...<mailto:Jay...@ig...> |158-162 & 165-170,EPIP Phase II, Whitefield, Bangalore-560066,India|Website: www.igate.com<http://www.igate.com/>| ____________________________________________________________________________________________________________________________________ iGATE is Ranked No. 1 in DQ-IDC best IT employer survey and Ranked No.2 by Business Today-Mercer Human Resource Consulting-TNS in a cross industry survey of Best Companies to work for in India ----------------------------------------------------------------DISCLAIMER--------------------------------------------------------- Information transmitted by this EMAIL is proprietary to iGATE Group of Companies and is intended for use only by the individual or entity to whom it is addressed and may contain information that is privileged, confidential, or exempt from disclosure under applicable law. If you are not the intended recipient of this EMAIL immediately notify the sender at iGATE or mai...@ig... and delete this EMAIL including any attachments |
From: <pro...@gm...> - 2008-12-29 15:45:52
|
I get the following when running the tests using ant. What is the cause of this failure? [junit] Testcase: RecordingTest "success" took 0.672 sec [junit] Caused an ERROR [junit] compile failed (result code 1) [junit] java.lang.Exception: compile failed (result code 1) [junit] at net.innig.macker.recording.RecordingTest.buildTestClasses(Un nown Source) [junit] at net.innig.macker.recording.RecordingTest.build(Unknown Sourc ) [junit] at net.innig.macker.recording.RecordingTest.run(Unknown Source) BUILD FAILED C:\dev\macker\build.xml:211: Test net.innig.macker.recording.RecordingTest fail |
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/ > |
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-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-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: 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: 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 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 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-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: 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: 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-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-02-18 05:43:12
|
Enrique — For this sort of purpose, you're better off with a tool like JDepend. Macker doesn't do metrics, only rules checking. You could build such a statistics tool on top of Macker if you wanted to, but Macker itself doesn't do this sort of this. Cheers, Paul On Feb 14, 2008, at 7:27 AM, Enrique Hernández Hernández wrote: > Hello! > > I need to get some statistics about my code like: > - Number of interfaces > - Number of classes than extends from a class in my architecture > - Number of EJB’s > - …. > > I can use reflection in order to get the superclass and interfaces > of my class and use this information to know what kind of class is > it, but I want to know if I can get this information with macker. > I try with this rule file (because I think that the message only > appears if the class is an interface): > <macker> > <ruleset name="interface"> > <pattern name="interface" filter="interface"/> > <message>interface</message> > </ruleset> > </macker> > > But I get a message from any class of my code. > > I need the result in a xml file like this: > <macker-report> > <timestamp>Thu Feb 14 14:30:39 CET 2008</timestamp> > <ruleset name="interface"> > <message-rule severity="info"> > <message>es.infodesa.Interface</message> > </message-rule> > </ruleset> > </macker-report> > > Best regards > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/_______________________________________________ > Macker-user mailing list > Mac...@li... > https://lists.sourceforge.net/lists/listinfo/macker-user > > Macker home page: http://innig.net/macker/ |
From: Enrique H. H. <ehe...@in...> - 2008-02-14 13:32:11
|
Hello! I need to get some statistics about my code like: - Number of interfaces - Number of classes than extends from a class in my architecture - Number of EJB's - .... I can use reflection in order to get the superclass and interfaces of my class and use this information to know what kind of class is it, but I want to know if I can get this information with macker. I try with this rule file (because I think that the message only appears if the class is an interface): <macker> <ruleset name="interface"> <pattern name="interface" filter="interface"/> <message>interface</message> </ruleset> </macker> But I get a message from any class of my code. I need the result in a xml file like this: <macker-report> <timestamp>Thu Feb 14 14:30:39 CET 2008</timestamp> <ruleset name="interface"> <message-rule severity="info"> <message>es.infodesa.Interface</message> </message-rule> </ruleset> </macker-report> Best regards |
From: Paul C. <can...@po...> - 2007-10-16 16:53:29
|
Hello Stephane. The jars referenced by your code must in Macker's classpath when it runs. I'm not sure how the maven task sets up Macker's classpath, but apparently this jar is not finding it in there. Does it work for you with Ant? Can you try that as a simple diagnostic? Cheers, Paul On Oct 10, 2007, at 9:11 AM, COUTANT Stephane RD-BIZZ-GRE wrote: > Hi, > > I'm puzzled, your Coding convention example > http://innig.net/macker/example/conventions/src/macker.xml fails on my > small projet. > I have an interface that happens to import the JPA > javax.persistence.EntityExistsException. The exception class > actually is > provided in the classpath. The project does compile. > But when I add macker check to maven compilation phase, i have an > IncompleteClassInfoException, hinting the EntityExistsException file > could not be found in the classpath. > As i run it, i echo the classpath used, i can see the corresponding > persistence-api-1.0.jar is there... > I there any issue regarding exception classes or is it a standard > classpath problem? > > Best regards. > > ---------------------------------------------------------------------- > --- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a > browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Macker-user mailing list > Mac...@li... > https://lists.sourceforge.net/lists/listinfo/macker-user > > Macker home page: http://innig.net/macker/ > |
From: COUTANT S. RD-BIZZ-G. <ste...@or...> - 2007-10-10 14:12:09
|
Hi,=20 I'm puzzled, your Coding convention example http://innig.net/macker/example/conventions/src/macker.xml fails on my small projet.=20 I have an interface that happens to import the JPA javax.persistence.EntityExistsException. The exception class actually is provided in the classpath. The project does compile. But when I add macker check to maven compilation phase, i have an IncompleteClassInfoException, hinting the EntityExistsException file could not be found in the classpath. As i run it, i echo the classpath used, i can see the corresponding persistence-api-1.0.jar is there... I there any issue regarding exception classes or is it a standard classpath problem? Best regards. |
From: Paul C. <can...@po...> - 2007-09-25 19:50:40
|
Hi, Jeremy. The misunderstanding is the meaning of the access-rule. The Macker guide mentions that: > When the first item in [a pattern] is an include, everything starts > out excluded; conversely, when the first item is an exclude, > everything starts out included. ...and similarly, when the first item in an access-rule is "deny", everything starts out allowed; when it is "allow," everything starts out denied. In order words, every access rule starts out with an implicit element that either allows or denies everything. So your access rule: <access-rule> <allow> <from pattern="patternWorld3" /> <to class="java.**" /> </allow> </access-rule> ...is equivalent to: <access-rule> <deny> <!-- implicit rule --> <from class="**" /> <to class="**" /> </deny> <allow> <from pattern="patternWorld3" /> <to class="java.**" /> </allow> </access-rule> ...which means that the only dependencies in the universe that are allowed are from patternWorld3 to java.**. The rule will fail on any class not matched by patternWorld3, no matter what it does. Does that make any sense? To say, "if the class matches patternWorld3, it may only access java.**", do this: <access-rule> <deny> <from pattern="patternWorld3" /> </deny> <allow> <to class="java.**" /> </allow> </access-rule> Here that implicit first rule allows everything, because the first explicit rule is a deny. We then deny everything from patternWorld3, then allow back in the references we want. There are numerous other ways to do it. This is probably the most straightforward. In general, it is unusual for access rules to start with an <allow> element. Not necessarily bad, but unusual that it's really what you want. Incidentally, I'm adding SweetXML support to the next version of Macker, which would let you optionally write the above as: access-rule deny from pattern="patternWorld3" allow to class="java.**" Cheers, Paul On Sep 25, 2007, at 10:23 AM, copernic Jeremy wrote: > Hi all, > I am facing a strange behaviour with Macker. > > I have a project containing three PrintHelloWorld classes: > - PrintHelloWorld1 > - PrintHelloWorld2 > - PrintHelloWorld3 > > My macker.xml rules file contain a pattern that only includes my > PrintHelloWorld3 class. And I only have one access-rule that state > that the classes contained by my pattern "patternWorld3" has to > only access the "java.**" classes. > > So my macker.xml file looks like that: > > > <macker> > <ruleset name="Simple example"> > <pattern name="patternWorld3"> > <include class="PrintHelloWorld"/> > </pattern> > > <access-rule> > <allow> > <from pattern="patternWorld3" /> > <to class="java.**" /> > </allow> > </access-rule> > </ruleset> > </macker> > > The problem is that when I check the rules with the command ant > macker , Macker tells me that the other classes (PrintHelloWorld1 > and PrintHelloWorld2) , that aren't supposed to be included in the > pattern "patternWorld3", are also violating my access-rule. > > This is the trace I get: > > macker: > [macker] > [macker] (Checking ruleset: Simple example ...) > [macker] > [macker] Illegal reference > [macker] from PrintHelloWorld > [macker] to void > [macker] > [macker] Illegal reference > [macker] from PrintHelloWorld2 > [macker] to java.io.PrintStream > [macker] > [macker] Illegal reference > [macker] from PrintHelloWorld2 > [macker] to java.lang.Object > [macker] > [macker] Illegal reference > [macker] from PrintHelloWorld2 > [macker] to java.lang.String > [macker] > [macker] Illegal reference > [macker] from PrintHelloWorld2 > [macker] to java.lang.System > [macker] > [macker] Illegal reference > [macker] from PrintHelloWorld2 > [macker] to void > [macker] > [macker] Illegal reference > [macker] from PrintHelloWorld3 > [macker] to java.io.PrintStream > [macker] > [macker] Illegal reference > [macker] from PrintHelloWorld3 > [macker] to java.lang.Object > [macker] > [macker] Illegal reference > [macker] from PrintHelloWorld3 > [macker] to java.lang.String > [macker] > [macker] Illegal reference > [macker] from PrintHelloWorld3 > [macker] to java.lang.System > [macker] > [macker] Illegal reference > [macker] from PrintHelloWorld3 > [macker] to void > [macker] > [macker] (11 errors) > [macker] > [macker] Macker rules checking failed > > BUILD FAILED > > This is strange because I thought that normally I only should get > errors from PrintHelloWorld3, defined my the pattern. > The <allow> rule tag doesn't seems to take into consideration my > pattern and in fact apply the rule checking on all of the primary > classes (PrintHelloWorld1, PrintHelloWorld2 and PrintHelloWorld3). > The only way to currently bypass that issue is to use a subset on > the patternWorld3 so by adding this line to the macker.xml file: > > <subset pattern="patternWorld3"/> > > then I get the what I was looking for: > > macker: > [macker] > [macker] (Checking ruleset: Simple example ...) > [macker] > [macker] Illegal reference > [macker] from PrintHelloWorld > [macker] to void > [macker] > [macker] (1 error) > [macker] > [macker] Macker rules checking failed > > BUILD FAILED > > > Why is my patternWorld3 isn't consider without a subset tag in my > allow statement? > Have I understood wrongly the semantic of the <allow> tag, or the > pattern? > > thanks in advance, > > Cheers, > Jeremy > > > ---------------------------------------------------------------------- > --- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Macker-user mailing list > Mac...@li... > https://lists.sourceforge.net/lists/listinfo/macker-user > > Macker home page: http://innig.net/macker/ |
From: copernic J. <cop...@gm...> - 2007-09-25 15:23:22
|
Hi all, I am facing a strange behaviour with Macker. I have a project containing three PrintHelloWorld classes: - PrintHelloWorld1 - PrintHelloWorld2 - PrintHelloWorld3 My macker.xml rules file contain a pattern that only includes my PrintHelloWorld3 class. And I only have one access-rule that state that the classes contained by my pattern "patternWorld3" has to only access the "java.**" classes. So my macker.xml file looks like that: <macker> <ruleset name="Simple example"> <pattern name="patternWorld3"> <include class="PrintHelloWorld"/> </pattern> <access-rule> <allow> <from pattern="patternWorld3" /> <to class="java.**" /> </allow> </access-rule> </ruleset> </macker> The problem is that when I check the rules with the command ant macker , Macker tells me that the other classes (PrintHelloWorld1 and PrintHelloWorld2) , that aren't supposed to be included in the pattern "patternWorld3", are also violating my access-rule. This is the trace I get: macker: [macker] [macker] (Checking ruleset: Simple example ...) [macker] [macker] Illegal reference [macker] from PrintHelloWorld [macker] to void [macker] [macker] Illegal reference [macker] from PrintHelloWorld2 [macker] to java.io.PrintStream [macker] [macker] Illegal reference [macker] from PrintHelloWorld2 [macker] to java.lang.Object [macker] [macker] Illegal reference [macker] from PrintHelloWorld2 [macker] to java.lang.String [macker] [macker] Illegal reference [macker] from PrintHelloWorld2 [macker] to java.lang.System [macker] [macker] Illegal reference [macker] from PrintHelloWorld2 [macker] to void [macker] [macker] Illegal reference [macker] from PrintHelloWorld3 [macker] to java.io.PrintStream [macker] [macker] Illegal reference [macker] from PrintHelloWorld3 [macker] to java.lang.Object [macker] [macker] Illegal reference [macker] from PrintHelloWorld3 [macker] to java.lang.String [macker] [macker] Illegal reference [macker] from PrintHelloWorld3 [macker] to java.lang.System [macker] [macker] Illegal reference [macker] from PrintHelloWorld3 [macker] to void [macker] [macker] (11 errors) [macker] [macker] Macker rules checking failed BUILD FAILED This is strange because I thought that normally I only should get errors from PrintHelloWorld3, defined my the pattern. The <allow> rule tag doesn't seems to take into consideration my pattern and in fact apply the rule checking on all of the primary classes (PrintHelloWorld1, PrintHelloWorld2 and PrintHelloWorld3). The only way to currently bypass that issue is to use a subset on the patternWorld3 so by adding this line to the macker.xml file: <subset pattern="patternWorld3"/> then I get the what I was looking for: macker: [macker] [macker] (Checking ruleset: Simple example ...) [macker] [macker] Illegal reference [macker] from PrintHelloWorld [macker] to void [macker] [macker] (1 error) [macker] [macker] Macker rules checking failed BUILD FAILED Why is my patternWorld3 isn't consider without a subset tag in my allow statement? Have I understood wrongly the semantic of the <allow> tag, or the pattern? thanks in advance, Cheers, Jeremy |
From: Paul C. <can...@po...> - 2007-08-06 20:36:29
|
Yes, agreed, that would be a much nicer way to do it. I'll add it as a feature request. The Macker Maven plugin was developed by a kind volunteer, and is maintained separately. Perhaps we can fold it in with the next release. You are also more than welcome to take a crack at this improvement! Macker uses its own specialized regex syntax, designed to work well with class names. It is more like a UNIX shell wildcards than anything else, but it's basically its own beast: http://innig.net/macker/guide/regex.html Cheers, Paul On Aug 6, 2007, at 11:17 AM, copernic Jeremy wrote: > Hello Paul, > > Thanks for your help, in fact I just found a link explaining how to > use Macker with Maven 2 through the maven-antrun-plugin. > http://docs.codehaus.org/display/MAVENUSER/Running+Macker+with+Maven+2 > It works fine for now but I must admit that I would prefer using a > full maven-macker-plugin without any ant tasks and build.xml files. > I think it could be great if we could define all the macker.xml's > rules directly into the pom.xml of the maven project, or simply > specify the location of the macker.xml file like the JettyConfig > file style. Something like that: > > <plugin> > <groupId>maven-plugins</groupId> > <artifactId>maven-macker-plugin</artifactId> > <version>0.4.2</version> > <configuration> > <mackerConfig>${basedir}src/test/ > macker.xml</mackerConfig> > </configuration> > > > </plugin> > > or > > > <plugin> > <groupId>maven-plugins</groupId> > <artifactId>maven-macker-plugin</artifactId> > <version>0.4.2</version> > <configuration> > <rulesets> > <ruleSet> > <accessRule> > <from>myClass</from> > <to>someJavaClass</to> > </accessRule> > </ruleSet> > </ruleSets> > ..... > </configuration> > > > </plugin> > > Maybe someday, someone who knows well Macker and the development of > maven plugins could try release one like that?! > > Now one last question, from what is the regex syntaxe of Macker > based on? Apache like or is it more Java Regex? > > Thanks again. > > regards, > > Jeremy > > > > > On 8/6/07, Paul Cantrell <can...@po... > wrote: > I believe that Sourceforge says that there is "no version > available" because the binary is hosted in the maven repository. > > I'm not much familiar with the Maven plugin, but I know that people > used it successfully in the past. I wonder if it was only for Maven > 1...? I'll try to dig up the name of the fellow who wrote the maven > plugin, and see if he knows more about what your problem might be. > > Cheers, > > Paul > > > On Aug 3, 2007, at 4:42 AM, copernic Jeremy wrote: > >> Hi all, >> I am looking for the maven-macker-plugin, if there is one of course! >> Indeed, the project website seems to say that there are no version >> available yet: http://maven-plugins.sourceforge.net/maven-macker- >> plugin/downloads.html >> I have been googling the web for a few hour now but I only found >> this version on repo1: http://repo1.maven.org/maven2/maven-plugins/ >> maven-macker-plugin/ >> Unfortunatly I can't figure out how to use it in my project >> pom.xml. When I try this in my pom.xml I get the following error: >> >> The pom.xml : >> >> <project> >> .... >> <build> >> <plugins> >> .... >> >> <plugin> >> <groupId>maven-plugins</groupId> >> <artifactId>maven-macker-plugin</artifactId> >> <version>0.4.2</version> >> >> <executions> >> <execution> >> <goals> >> <goal> macker</goal> >> </goals> >> </execution> >> </executions> >> </plugin> >> .... >> </plugins> >> </build> >> .... >> </project> >> >> >> The error trace: >> >> ERROR]FATAL ERROR >> [INFO]--------------------------------------------------------------- >> --------- >> [INFO]The PluginDescriptor for the plugin maven-plugins:maven- >> macker-plugin was not found >> [INFO]--------------------------------------------------------------- >> --------- >> [INFO]Trace >> java.lang.IllegalStateException : The PluginDescriptor for the >> plugin maven-plugins:maven-macker-plugin was not found >> >> at org.apache.maven.plugin.DefaultPluginManager.addPlugin >> (DefaultPluginManager.java :294) >> at >> org.apache.maven.plugin.DefaultPluginManager.verifyVersionedPlugin >> (DefaultPluginManager.java:198) >> at >> org.apache.maven.plugin.DefaultPluginManager.verifyPlugin >> (DefaultPluginManager.java:163) >> at >> org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin >> (DefaultLifecycleExecutor.java :1328) >> at >> org.apache.maven.lifecycle.DefaultLifecycleExecutor.bindPluginToLifec >> ycle(DefaultLifecycleExecutor.java :1292) >> at >> org.apache.maven.lifecycle.DefaultLifecycleExecutor.constructLifecycl >> eMappings (DefaultLifecycleExecutor.java:1058) >> at >> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal >> (DefaultLifecycleExecutor.java :529) >> at >> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan >> dleFailures (DefaultLifecycleExecutor.java:309) >> at >> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen >> ts (DefaultLifecycleExecutor.java:276) >> at >> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute >> (DefaultLifecycleExecutor.java:143) >> at org.apache.maven.DefaultMaven.doExecute >> (DefaultMaven.java:393) >> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java: >> 182) >> at org.apache.maven.embedder.MavenEmbedder.execute >> (MavenEmbedder.java:760) >> at >> org.codehaus.mevenide.netbeans.execute.MavenJavaExecutor.run >> (MavenJavaExecutor.java:257) >> at org.netbeans.core.execution.RunClassThread.run >> (RunClassThread.java:131) >> [INFO]--------------------------------------------------------------- >> --------- >> >> It seems that there might be a problem with a descriptor file but >> how can i resolve that? >> >> Regards, >> Jeremy >> --------------------------------------------------------------------- >> ---- >> This SF.net email is sponsored by: Splunk Inc. >> Still grepping through log files to find problems? Stop. >> Now Search log events and configuration files using AJAX and a >> browser. >> Download your FREE copy of Splunk now >> http://get.splunk.com/ >> _______________________________________________ >> 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: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a > browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > 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: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a > browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Macker-user mailing list > Mac...@li... > https://lists.sourceforge.net/lists/listinfo/macker-user > > Macker home page: http://innig.net/macker/ |
From: copernic J. <cop...@gm...> - 2007-08-06 16:17:51
|
Hello Paul, Thanks for your help, in fact I just found a link explaining how to use Macker with Maven 2 through the maven-antrun-plugin. http://docs.codehaus.org/display/MAVENUSER/Running+Macker+with+Maven+2 It works fine for now but I must admit that I would prefer using a full maven-macker-plugin without any ant tasks and build.xml files. I think it could be great if we could define all the macker.xml's rules directly into the pom.xml of the maven project, or simply specify the location of the macker.xml file like the JettyConfig file style. Something like that: <plugin> <groupId>maven-plugins</groupId> <artifactId>maven-macker-plugin</artifactId> <version>0.4.2</version> <configuration> <mackerConfig>${basedir}src/test/macker.xml</mackerConfig> </configuration> </plugin> or <plugin> <groupId>maven-plugins</groupId> <artifactId>maven-macker-plugin</artifactId> <version>0.4.2</version> <configuration> <rulesets> <ruleSet> <accessRule> <from>myClass</from> <to>someJavaClass</to> </accessRule> </ruleSet> </ruleSets> ..... </configuration> </plugin> Maybe someday, someone who knows well Macker and the development of maven plugins could try release one like that?! Now one last question, from what is the regex syntaxe of Macker based on? Apache like or is it more Java Regex? Thanks again. regards, Jeremy On 8/6/07, Paul Cantrell <can...@po...> wrote: > > I believe that Sourceforge says that there is "no version available" > because the binary is hosted in the maven repository. > > I'm not much familiar with the Maven plugin, but I know that people used > it successfully in the past. I wonder if it was only for Maven 1...? I'll > try to dig up the name of the fellow who wrote the maven plugin, and see if > he knows more about what your problem might be. > > Cheers, > > Paul > > > On Aug 3, 2007, at 4:42 AM, copernic Jeremy wrote: > > Hi all, > I am looking for the maven-macker-plugin, if there is one of course! > Indeed, the project website seems to say that there are no version > available yet: > http://maven-plugins.sourceforge.net/maven-macker-plugin/downloads.html > I have been googling the web for a few hour now but I only found this > version on repo1: > http://repo1.maven.org/maven2/maven-plugins/maven-macker-plugin/ > Unfortunatly I can't figure out how to use it in my project pom.xml. When > I try this in my pom.xml I get the following error: > > The pom.xml: > > <project> > .... > <build> > <plugins> > .... > > <plugin> > <groupId>maven-plugins</groupId> > <artifactId>maven-macker-plugin</artifactId> > <version>0.4.2</version> > > <executions> > <execution> > <goals> > <goal> macker</goal> > </goals> > </execution> > </executions> > </plugin> > .... > </plugins> > </build> > .... > </project> > > > The error trace: > > ERROR]FATAL ERROR > > [INFO]------------------------------------------------------------------------ > [INFO]The PluginDescriptor for the plugin > maven-plugins:maven-macker-plugin was not found > [INFO]------------------------------------------------------------------------ > > [INFO]Trace > java.lang.IllegalStateException: The PluginDescriptor for the plugin > maven-plugins:maven-macker-plugin was not found > > at org.apache.maven.plugin.DefaultPluginManager.addPlugin( > DefaultPluginManager.java :294) > at > org.apache.maven.plugin.DefaultPluginManager.verifyVersionedPlugin( > DefaultPluginManager.java:198) > at org.apache.maven.plugin.DefaultPluginManager.verifyPlugin( > DefaultPluginManager.java:163) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin( > DefaultLifecycleExecutor.java:1328) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.bindPluginToLifecycle( > DefaultLifecycleExecutor.java :1292) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.constructLifecycleMappings > (DefaultLifecycleExecutor.java:1058) > at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal > (DefaultLifecycleExecutor.java :529) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures > (DefaultLifecycleExecutor.java:309) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments ( > DefaultLifecycleExecutor.java:276) > at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute( > DefaultLifecycleExecutor.java:143) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:393) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:182) > at org.apache.maven.embedder.MavenEmbedder.execute( > MavenEmbedder.java:760) > at org.codehaus.mevenide.netbeans.execute.MavenJavaExecutor.run ( > MavenJavaExecutor.java:257) > at org.netbeans.core.execution.RunClassThread.run( > RunClassThread.java:131) > > [INFO]------------------------------------------------------------------------ > > It seems that there might be a problem with a descriptor file but how can > i resolve that? > > Regards, > Jeremy > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> > http://get.splunk.com/_______________________________________________ > 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: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Macker-user mailing list > Mac...@li... > https://lists.sourceforge.net/lists/listinfo/macker-user > > Macker home page: http://innig.net/macker/ > |