macker-user — Questions, request for help, and feature discussions

Re: [macker-user] detect class that implements 2 interfaces

[Paul C. <can...@po...>]

Oops! I realize I forgot to post my reply to Etienne to the list! Sorry.

Just use nested includes:

     <include filter="subtype-of" class="Alpha">
         <include filter="subtype-of" class="Beta" />
     </include>

Read the docs -- nested includes make a boolean AND:

     http://innig.net/macker/guide/pattern.html#nesting

Michael -- I'm not sure your approach below actually works. Perhaps  
you meant that last pattern to read as follows:

     <pattern name="classes-implementing-Alpha-and-Beta">
         <include filter="subtype-of" class="Alpha" />
         <include filter="subtype-of" class="Beta" />
         <exclude pattern="classes-implementing-only-Alpha" />
         <exclude pattern="classes-implementing-only-Beta" />
     </pattern>

Regardless, nesting is a *far* simpler way to do this.

Cheers,

Paul


On Oct 19, 2005, at 9:34 AM, Michael Sassin wrote:

> Hi
>
> I found a solution for this a while back that is clunky but will  
> work. Underlying the idea is that if you have tow sets A and B and  
> want to now the set of A AND B you can write this also as
>
>         A AND B = (A+B) - ( (A - B) + (B-A)
>
> The operations "-" and "+" relate to exclude and include operations  
> in Macker. So, as a result you can express your problem as
>
> <pattern name="classes-implementing-only-Alpha">
>         <include filter="subtype-of" class="Alpha" />
>         <exclude filter="subtype-of" class="Beta" />
> </pattern>
>
> <pattern name="classes-implementing-only-Beta">
>         <include filter="subtype-of" class="Beta" />
>         <exclude filter="subtype-of" class="Alpha" />
> </pattern>
>
> <pattern name="classes-implementing-only-Beta">
>         <include filter="subtype-of" class="Alpha" />
>         <include filter="subtype-of" class="Beta" />
>         <include pattern="classes-implementing-only-Alpha" />
>         <include pattern="classes-implementing-only-Beta" />
> </pattern>
>
> Michael

On Oct 18, 2005, at 10:12 PM, Etienne Studer wrote:
> Hi
>
> What kind of macker rule do I have to write to detect all classes  
> that implement interface Alpha AND interface Beta.
>
> For example,
>
> class X implements Alpha, Beta {
>   ...
> }
>
> Thanks for any help.
>
> --Etienne
>
> P.S. Btw, macker is awesome and we couldn't be without it anymore!

[macker-user] Re: Macker-user digest, Vol 1 #25 - 1 msg

[Michael S. <MS...@in...>]

Hi

I found a solution for this a while back that is clunky but will work. 
Underlying the idea is that if you have tow sets A and B and want to now 
the set of A AND B you can write this also as 

        A AND B = (A+B) - ( (A - B) + (B-A)

The operations "-" and "+" relate to exclude and include operations in 
Macker. So, as a result you can express your problem as 

<pattern name="classes-implementing-only-Alpha">
        <include filter="subtype-of" class="Alpha" />
        <exclude filter="subtype-of" class="Beta" />
</pattern>

<pattern name="classes-implementing-only-Beta">
        <include filter="subtype-of" class="Beta" />
        <exclude filter="subtype-of" class="Alpha" />
</pattern>

<pattern name="classes-implementing-only-Beta">
        <include filter="subtype-of" class="Alpha" />
        <include filter="subtype-of" class="Beta" />
        <include pattern="classes-implementing-only-Alpha" />
        <include pattern="classes-implementing-only-Beta" />
</pattern>

Michael




mac...@li... 
Sent by: mac...@li...
10/18/2005 11:38 PM
Please respond to
mac...@li...


To
mac...@li...
cc

Subject
Macker-user digest, Vol 1 #25 - 1 msg






Send Macker-user mailing list submissions to
                 mac...@li...

To subscribe or unsubscribe via the World Wide Web, visit
                 https://lists.sourceforge.net/lists/listinfo/macker-user
or, via email, send a message with subject or body 'help' to
                 mac...@li...

You can reach the person managing the list at
                 mac...@li...

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Macker-user digest..."


Today's Topics:

   1. detect class that implements 2 interfaces (Etienne Studer)

--__--__--

Message: 1
Date: Tue, 18 Oct 2005 20:12:46 -0700
From: Etienne Studer <eti...@ca...>
To: mac...@li...
Subject: [macker-user] detect class that implements 2 interfaces

Hi

What kind of macker rule do I have to write to detect all classes that 
implement interface Alpha AND interface Beta.

For example,

class X implements Alpha, Beta {
   ...
}

Thanks for any help.

--Etienne

P.S. Btw, macker is awesome and we couldn't be without it anymore!



--__--__--

_______________________________________________
Macker-user mailing list
Mac...@li...
https://lists.sourceforge.net/lists/listinfo/macker-user

Macker home page: http://innig.net/macker/

End of Macker-user Digest

[macker-user] detect class that implements 2 interfaces

[Etienne S. <eti...@ca...>]

Hi

What kind of macker rule do I have to write to detect all classes that 
implement interface Alpha AND interface Beta.

For example,

class X implements Alpha, Beta {
   ...
}

Thanks for any help.

--Etienne

P.S. Btw, macker is awesome and we couldn't be without it anymore!

Re: [macker-user] debugging patterns

[Paul C. <can...@po...>]

Yes: use the verbose option in the Macker Ant task:

     <macker verbose="true" ...>

Macker will dump the usage graph, e.g.:

     Macker (verbose mode enabled)
     9 primary classes
     32 total classes
     73 references
     Classes used by net.innig.macker.example.conventions.AlphaTree:
         java.lang.String
         java.util.Set
         java.util.TreeSet
         net.innig.macker.example.conventions.AlphaTree
         net.innig.macker.example.conventions.StringTree
         VOID

It will then dump the parsed tree for each pattern, and show the  
matching classes:

     matching (include net.innig.macker.rule.filter.PrimaryFilter 
$1@d71e34 + (include net.innig.macker.rule.filter.InterfaceFilter 
$1@9652dd + net.innig.macker.rule.filter.AccessFilter$1@ffeaea))
         net.innig.macker.example.conventions.BrokenApi
         net.innig.macker.example.conventions.Tree

It's a lot of junk to wade through, but it may be of use. I suggest  
piping ant to a file when you do this.

Cheers,

Paul


On Sep 21, 2005, at 10:25 PM, Daniel Spangler wrote:

> Is there a flag or debugging level that can be turned on that will
> print out the classes/interfaces that match a given pattern?
>
> Daniel

[macker-user] debugging patterns

[Daniel S. <dan...@gm...>]

Is there a flag or debugging level that can be turned on that will
print out the classes/interfaces that match a given pattern?

Daniel

[macker-user] Maven plugin

[Nascif Abousalh-N. <Nas...@sa...>]

Any news on the release schedule for the Maven plugin?

[macker-user] Re: Is Macker still maintained ? Is there JDK1.5 support?

[M C <mor...@ya...>]

> Macker is still used. It doesn't get many updates,
> mostly because it  
> is simple and doesn't receive many bug reports or
> enhancement  
> requests.  But yes, people are using it.
> 
> I am currently starting work on the next release of
> Macker.  It will  
> run under JDK 1.5 only (though it will still check
> classes compiled  
> for previous JDKs), and will include more
> sophistaced rule expressions.
> 
> The current release of Macker will likely work with
> 1.5 classes,  
> because the 1.5 changes are mostly in the form of
> extra class file  
> tags, which Macker will just ignore ... though I
> haven't tried it  
> myself.  Perhaps I should!
> 
> Cheers,
> 
> Paul

Great news. I will try out Macker once the 1.5 version
is out! IMO, with the code being as complete and
errorfree as you report, you may want to give it a
"1.0" version istead of only "0.4" which sends a
different message. 

BTW: Eclipse 3.1 now also have some features for
specifying access rules. However they appear to be
more limited that Macker and I do not think they are
suppored from ANT scripts.

Cheers,
Morten Christensen

[macker-user] My (good) experience with Macker

[Doron R. <do...@sc...>]

I am using Macker since December 2003, with 105 updates to the Macker =
script since then (the Macker script is at =
http://www.rajwan.org/macker/macker.xml, but it is not a good example of =
how to write such scripts).

I've setup a daemon machine, which runs 24x7, and checks all check-ins =
to Perforce VCS on-line. When it finds a problem in the submission, it =
sends a popup message to the one who submitted that changelist, and a =
warning email to the rest of ~30 developers. When the problem is =
removed, a relaxation email is sent. Basically, this daemon checks =
compilation errors, module dependencies errors, and some more.

Over time, we've implemented a quite complex module relationship (see =
the image at http://www.rajwan.org/macker/modules.gif, which was =
generated by http://www.graphviz.org/). In the diagram, each box is a =
module and each line is an allowed import. Breaking things into modules =
helps providing a higher quality, well designed and easy to maintain =
software to our customers. It also enables us to have different =
installer and life cycle to our two main products (see the dashed =
boxes).

Programmers are lazy. They always try to find the shortest path to their =
daily goal, without any thought about next week's goal. A rule checking =
tool forces them to set things correctly, with core separated from GUI, =
with encapsulating concepts correctly, and so. When this tool runs =
on-line, and everyone gets a notification, it makes them try even =
harder...

I would even go further: in few cases a deep architecture changes were =
initiated by a problem detected by Macker.

Of course, module dependencies has many forms, e.g., text messages, =
related actions, reflective method invocation, and much more. Macker =
checks the most basic dependency -- imports. But, it proved to be enough =
for automatic detection of 99% of the problems. Finding that last 1% is =
tricky, and we normally fail to detect it until it breaks something.

Switching to JDK 1.5 was easy. Macker worked w/o any change, and even =
found some new errors. This is due to the fact that, in JDK 1.1 to 1.4, =
using 'SomeClassName.class' class literal is just a proxy to some =
compiler-generated static method, and in JDK 1.5 it is a true class =
reference.

Macker is a great tool already, but there are few improvements I would =
like to see. For example, I do not allow programmers to catch Errors, or =
Throwables, but I have no good method to enforce it today. I would like =
to have the ability to find all methods that are using catch for =
anything which is not an Exception or derived of it.

Thanks for providing us such a tool,
  Doron.


__________________________

Doron Rajwan
Chief Software Architect
tel.   +972-9-961-1525  ext. 215=20
fax.  +972-9-956-7958
mbl.  +972-50-951-2349
SCHEMA
Maximizing  Network  Efficiency
w w w . s c h e m a . c o m



This email and any files transmitted with it are confidential and =
intended =20
solely for the use of the individual or entity to whom they are =
addressed.=20
If you have received this email in error please notify us immediately =
and =20
delete this communication.

[macker-user] Including external files

[Paul C. <can...@po...>]

A Macker user wrote in to ask if there's a way to include shared  
pattern definitions between rules files.  (Hi Michael!)  There is,  
though it's a bit ugly: use XML external entities.

Create a file -- say "my-patterns.xml" -- next to your rules file.   
Put your shared patterns / rules / whatever in it:

     <var name="basepkg" value="net.innig.macker" />

     <pattern name="macker" class="${basepkg}.**" />

     ..etc..

Then change your rules file so that it starts like this:

     <?xml version="1.0" encoding="UTF-8"?>

     <!DOCTYPE macker PUBLIC
         "-//innig//DTD Macker 0.2//EN"
         "http://innig.net/macker/dtd/macker-0.4.dtd" [

       <!ENTITY myPatterns SYSTEM "my-patterns.xml">
       <!-- you can add more entity declarations here -->

     ]>

     <macker>
     ...etc...

Finally, at the point in your rules file where you want to include  
the shared patterns, do this:

         &myPatterns;

This plops my-patterns.xml straight into your document at that  
location, sort of like an #include in C.

Not pretty, but it does work.  I'm open to suggestions for a simple  
include facility to replace this.

Paul


_________________________________________________________________

"Prediction is hard, especially of the future."  -- Niels Bohr

Re: [macker-user] Is Macker still maintained ? Is there JDK1.5 support ?

[Paul C. <can...@po...>]

Hi Morten. I noticed your email went unanswered for ages -- sorry  
about that!

Macker is still used. It doesn't get many updates, mostly because it  
is simple and doesn't receive many bug reports or enhancement  
requests.  But yes, people are using it.

I am currently starting work on the next release of Macker.  It will  
run under JDK 1.5 only (though it will still check classes compiled  
for previous JDKs), and will include more sophistaced rule expressions.

The current release of Macker will likely work with 1.5 classes,  
because the 1.5 changes are mostly in the form of extra class file  
tags, which Macker will just ignore ... though I haven't tried it  
myself.  Perhaps I should!

Cheers,

Paul


On Apr 2, 2005, at 8:08 AM, M C wrote:

> Hi All,
>
> I just found macker by accident. Sounds very nice! I
> like the idea of being able to specify ANT deny rules
> between classes/packages! Cool!
>
> I was going to try it out but then I saw it is years
> since the last version (long before JDK 1.5 Tiger -
> Tiger has some important changes in the class format
> that may be important for tools like Macker).
>
> This situation makes be worry about the support for
> JDK 1.5 and continued maintance if I find bugs. -Both
> very important for me.
>
> I hope somebody is still reading this list and can
> give me some info on the status of Macker and JDK1.5
> support?
>
> Cheers,
> Morten Christensen
>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real  
> users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Macker-user mailing list
> Mac...@li...
> https://lists.sourceforge.net/lists/listinfo/macker-user
>
> Macker home page: http://innig.net/macker/
>
>

_________________________________________________________________

"Prediction is hard, especially of the future."  -- Niels Bohr

[macker-user] Is Macker still maintained ? Is there JDK1.5 support ?

[M C <mor...@ya...>]

Hi All,

I just found macker by accident. Sounds very nice! I
like the idea of being able to specify ANT deny rules
between classes/packages! Cool! 

I was going to try it out but then I saw it is years
since the last version (long before JDK 1.5 Tiger -
Tiger has some important changes in the class format
that may be important for tools like Macker).

This situation makes be worry about the support for
JDK 1.5 and continued maintance if I find bugs. -Both
very important for me.

I hope somebody is still reading this list and can
give me some info on the status of Macker and JDK1.5
support?

Cheers,
Morten Christensen

Re: [macker-user] Feature request: Allow to include jar files

[Paul C. <can...@po...>]

Hi Etienne. I'm not really clear on what you're asking.

> It would be great if one could add jar files to the macker classpath 
> to be investigated.

Macker will only check for illegal references *from* exploded class 
files.  If for some reason you want to check references from classes in 
a jar, use ant to temporarily expand the jar so Macker can see the 
class files.

But then your example seems to be about *excluding* jar classes, not 
*including* them...?

> When I used the subtype-of feature, macker tried to investigate 
> library classes that I am using in my code. But the library I use is 
> in a jar file and not in a exploded class file folder.

Macker will never give an error like "class X in your library jar 
cannot reference Y" ... but it will give an error like "your class Z, a 
subclass of library class X, cannot reference Y."

> Or is there a way to say that no classes in package x.y.z should be 
> investigated? I could then add my libraries to this exclude path.

You can limit which packages are checked in all kinds of ways.  See the 
user guide.

Perhaps if you can explain you question more specifically, or in a 
different way, your question will be clearer.

Paul

[macker-user] Feature request: Allow to include jar files

[Etienne S. <eti...@ca...>]

Hi

It would be great if one could add jar files to the macker classpath to 
be investigated.

Example:
When I used the subtype-of feature, macker tried to investigate library 
classes that I am using in my code. But the library I use is in a jar 
file and not in a exploded class file folder.

Or is there a way to say that no classes in package x.y.z should be 
investigated? I could then add my libraries to this exclude path.

Thanks for any feedback.

--Etienne

[Fwd: Re: [macker-user] Never implement interface but only abstract class]

[Etienne S. <eti...@ca...>]

Hi Paul

I tried it out. It works great!

Thanks.

--Etienne



Paul Cantrell wrote:
> Hello Etienne!
> 
> It's a touch convoluted, but I think something like this rule would do 
> the trick:
> 
>                 <deny>
>                     <from filter="subtype-of" class="IFoo" />
>                     <to class="IFoo" />
>         <allow>
>                         <from filter="subtype-of" class="AbstractFoo" />
>         </allow>
>                 </deny>
> 
> Untested (sorry); give it a whirl and let me know how it works.
> 
> Cheers,
> 
> Paul
> 
> 
> On Feb 28, 2005, at 10:04 AM, Etienne Studer wrote:
> 
>> Hi
>>
>> I just started using Macker. It's great - straight-forward to use and 
>> very helpful!
>>
>> Can I described the following rule with Macker (if so, how?):
>>
>> "No class may implement interface IFoo directly. Classes must only 
>> extend the abstract class AbstractFoo which implements IFoo already. 
>> The one exception is the class AbstractFoo itself."
>>
>> That would be great. Any help is appreciated!
>>
>> --Etienne
>>
>>
>> -------------------------------------------------------
>> SF email is sponsored by - The IT Product Guide
>> Read honest & candid reviews on hundreds of IT Products from real users.
>> Discover which products truly live up to the hype. Start reading now.
>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>> _______________________________________________
>> Macker-user mailing list
>> Mac...@li...
>> https://lists.sourceforge.net/lists/listinfo/macker-user
>>
>> Macker home page: http://innig.net/macker/
>>
>>
> _________________________________________________________________
> 
> "Prediction is hard, especially of the future."  -- Niels Bohr
> 
> 
> 

Re: [macker-user] Never implement interface but only abstract class

[Etienne S. <et...@st...>]

Hi Paul

Thanks. I'll try it out and let you know!

--Etienne



Paul Cantrell wrote:
> Hello Etienne!
> 
> It's a touch convoluted, but I think something like this rule would do 
> the trick:
> 
>                 <deny>
>                     <from filter="subtype-of" class="IFoo" />
>                     <to class="IFoo" />
>         <allow>
>                         <from filter="subtype-of" class="AbstractFoo" />
>         </allow>
>                 </deny>
> 
> Untested (sorry); give it a whirl and let me know how it works.
> 
> Cheers,
> 
> Paul
> 
> 
> On Feb 28, 2005, at 10:04 AM, Etienne Studer wrote:
> 
>> Hi
>>
>> I just started using Macker. It's great - straight-forward to use and 
>> very helpful!
>>
>> Can I described the following rule with Macker (if so, how?):
>>
>> "No class may implement interface IFoo directly. Classes must only 
>> extend the abstract class AbstractFoo which implements IFoo already. 
>> The one exception is the class AbstractFoo itself."
>>
>> That would be great. Any help is appreciated!
>>
>> --Etienne
>>
>>
>> -------------------------------------------------------
>> SF email is sponsored by - The IT Product Guide
>> Read honest & candid reviews on hundreds of IT Products from real users.
>> Discover which products truly live up to the hype. Start reading now.
>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>> _______________________________________________
>> Macker-user mailing list
>> Mac...@li...
>> https://lists.sourceforge.net/lists/listinfo/macker-user
>>
>> Macker home page: http://innig.net/macker/
>>
>>
> _________________________________________________________________
> 
> "Prediction is hard, especially of the future."  -- Niels Bohr
> 
> 
> 

Re: [macker-user] Never implement interface but only abstract class

[Paul C. <can...@po...>]

Hello Etienne!

It's a touch convoluted, but I think something like this rule would do 
the trick:

                 <deny>
                 	<from filter="subtype-of" class="IFoo" />
                 	<to class="IFoo" />
		<allow>
	                	<from filter="subtype-of" class="AbstractFoo" />
		</allow>
                 </deny>

Untested (sorry); give it a whirl and let me know how it works.

Cheers,

Paul


On Feb 28, 2005, at 10:04 AM, Etienne Studer wrote:

> Hi
>
> I just started using Macker. It's great - straight-forward to use and 
> very helpful!
>
> Can I described the following rule with Macker (if so, how?):
>
> "No class may implement interface IFoo directly. Classes must only 
> extend the abstract class AbstractFoo which implements IFoo already. 
> The one exception is the class AbstractFoo itself."
>
> That would be great. Any help is appreciated!
>
> --Etienne
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real 
> users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Macker-user mailing list
> Mac...@li...
> https://lists.sourceforge.net/lists/listinfo/macker-user
>
> Macker home page: http://innig.net/macker/
>
>
_________________________________________________________________

"Prediction is hard, especially of the future."  -- Niels Bohr

[macker-user] Never implement interface but only abstract class

[Etienne S. <et...@st...>]

Hi

I just started using Macker. It's great - straight-forward to use and 
very helpful!

Can I described the following rule with Macker (if so, how?):

"No class may implement interface IFoo directly. Classes must only 
extend the abstract class AbstractFoo which implements IFoo already. The 
one exception is the class AbstractFoo itself."

That would be great. Any help is appreciated!

--Etienne

[macker-user] FASD project: Online survey launched

[<ben...@id...>]

Dear Open Source developer

I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate.
You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it.

With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development.


With many thanks for your participation,
Benno Luthiger


PS:
The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/.
We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_en.html for registration to this mailing list.

_______________________________________________________________________

Benno Luthiger
Swiss Federal Institute of Technology Zurich
8092 Zurich

Mail: benno.luthiger(at)id.ethz.ch
_______________________________________________________________________

Re: [macker-user] allow and nested allow

[Florent Z. <fza...@fr...>]

Paul Cantrell wrote:
> 
> Hope this helps clarify!
> 
> In practice, you'll rarely need to write patterns this complex, I hope....
> 

Hello Paul,

Many Thanks for this fast and illustrated answer. Now I can say I fully
understand (I hope so ;)

May I suggest to include such an example in macker's guide ?

Keep on doing such a good job with this tool.

Florent

Re: [macker-user] allow and nested allow

[Paul C. <can...@po...>]

Bienvenue, Florent.  Good question.  The difference is that the nested "allow"
applies only as an exception to the outer "deny".  If you have only one "deny",
there is no difference.

However, if you set up a more complex rule, there is a difference.  For example,
this would allow a reference from "factory" to "inside-sensitive" ...

   <deny><to pattern="inside" /></deny>
   <deny><to pattern="inside-sensitive" /></deny>
   <allow><from pattern="inside" /></allow>
   <allow><from pattern="factory" /></allow>

..but this would *not*:

   <deny>
     <to pattern="inside" />
     <allow><from pattern="inside" /></allow>
     <allow><from pattern="factory" /></allow>
   </deny>
   <deny>
     <to pattern="inside-sensitive" />
     <allow><from pattern="inside" /></allow>
   </deny>

Here are the nested and non-nested forms mixed (this is equivalent to the second
example above):

   <deny>
     <to pattern="inside" />
     <allow><from pattern="factory" /></allow>
   </deny>
   <deny>
     <to pattern="inside-sensitive" />
   </deny>
   <allow><from pattern="inside" /></allow>

Hope this helps clarify!

In practice, you'll rarely need to write patterns this complex, I hope....

Cheers,

Paul


Quoting Florent Zara <fza...@fr...>:
> Hello,
> 
> First, thank you for your tool. It's quite usefull. But after plying at
> bit with it, I have the following question:
> 
> What is the pratical difference between "allow" at the same level as
> "deny" and "allow" nested inside a "deny" ? I've read the documentation
> that says it theorically behaves somehow like include/exclude, but in
> practice, I've run the modularity exemple with both and I have exactly
> the same results. here is the modified part:
> <access-rule>
>   <message>${from} must access the ${module} module through its
> API</message>
>   <deny>
>     <to pattern="inside" />
>     <allow><from pattern="inside" /></allow>
>     <allow><from pattern="factory" /></allow>
>   </deny>
> </access-rule>
> 
> May you give me more precision on that issue ?
> 
> Thanks in advance
> 
> Florent
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Macker-user mailing list
> Mac...@li...
> https://lists.sourceforge.net/lists/listinfo/macker-user
> 
> Macker home page: http://innig.net/macker/

[macker-user] allow and nested allow

[Florent Z. <fza...@fr...>]

Hello,

First, thank you for your tool. It's quite usefull. But after plying at
bit with it, I have the following question:

What is the pratical difference between "allow" at the same level as
"deny" and "allow" nested inside a "deny" ? I've read the documentation
that says it theorically behaves somehow like include/exclude, but in
practice, I've run the modularity exemple with both and I have exactly
the same results. here is the modified part:
<access-rule>
  <message>${from} must access the ${module} module through its
API</message>
  <deny>
    <to pattern="inside" />
    <allow><from pattern="inside" /></allow>
    <allow><from pattern="factory" /></allow>
  </deny>
</access-rule>

May you give me more precision on that issue ?

Thanks in advance

Florent

Re: [macker-user] command line execution help

[Paul C. <can...@po...>]

> I'm trying to execute Macker from the command line, to get
> familiar with it and determine whether to start using it. There
> are no instructions on how to execute it from the command line.

Sorry about that.  The only help available is just running it from the 
command line with no args, but I grant that's not much help.

> How do I tell it the location of all of the classes to be
> included in the analysis? Do I have to list each file
> individually, a directory, or what?

You must either list each file individually -- here's an example using 
bash --

	macker -r myrules.xml $(find build/classes -name '*.class')

-- or you can specify the name a file containing the file with each 
class (each on a separate line, IIRC):

	find build/classes -name '*.class' > myclasses.txt
	macker -r myrules.xml @myclasses.txt

Hope that helps!

Cheers,

Paul

[macker-user] command line execution help

[Peter H. <pjh...@ya...>]

I'm trying to execute Macker from the command line, to get
familiar with it and determine whether to start using it. There
are no instructions on how to execute it from the command line.

How do I tell it the location of all of the classes to be
included in the analysis? Do I have to list each file
individually, a directory, or what? 

__________________________________
Do you Yahoo!?
Yahoo! Search - Find what you’re looking for faster
http://search.yahoo.com

Re: [macker-user] Catching exceptions

[Paul C. <can...@po...>]

The behavior you want is called "filtering by reference type", and will=20=

be implemented in either version 0.5 or version 0.6.

Paul


On Dec 26, 2003, at 2:26 AM, Doron Rajwan wrote:

> I want to prevent everyone from catchingAssertionError.
>
> =A0
>
> The problem is, that each:
>
> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 assert a > b;
>
> Is actually:
>
> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 If (!(a>b))
>
> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0 throw new =
AssertionError();
>
> So, everyone uses AssertionError.
>
> =A0
>
> Thus, my question is:can you add a filter that will match only =93catch=94=
=20
> usage, and nothing else? =A0I do not care if they throw it, create it,=20=

> take it, copy it, store it in variables, and so. I just do not want=20
> anyone to catch Errors / Throwables and so.
>
> =A0
>
> Thanks,
>
> =A0 Doron.
>
> =A0
>
> =A0
>
> _______________________________________________
>
> Doron Rajwan,do...@ra...,www.rajwan.org
>
> 13 Odem street,Rishon Le-Zion,Israel
>
> Home:=A0=A0 03-9512348=A0 [+972-(3)-9512348]
>
> Cell:=A0=A0 064-887732=A0 [+972-(64)-887732]
>
> =A0

Re: [macker-user] legacy code problem

[Paul C. <can...@po...>]

Michael --

Unless there's some consistency to the packaging or naming of your 
legacy classes, I'm afraid there's no better way.

How do you distinguish the legacy classes yourself?  Are they in a 
separate source tree?

Paul


On Dec 31, 2003, at 9:36 AM, Michael Davidovich wrote:

> Hi,
>
> I am new to this group, so please bare with me and my questions if  by 
> some
> occasion this question/s have been already asked.
>
> Now to the point, we are in the midst of the architectural changes in 
> the
> existing code. I decided to enforce new architecture with Macker, but I
> don't want the old code to pop up as problem (we will deal with it 
> offline);
> I only want to monitor that new code is aligned with guidelines. what 
> I need
> is some kind of "suppress" feature.
> I did something like this using <exclude>, but I had to exclude ~ 500 
> legacy
> files, after doing this my ant macker task takes indefinitely.
>
> Is there another way?
>
> thanks.
>
> Michael.