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

Re: [macker-user] Maven and macker plugin working??

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

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.bindPluginToLifecy 
> cle(DefaultLifecycleExecutor.java :1292)
>         at  
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.constructLifecycle 
> Mappings(DefaultLifecycleExecutor.java:1058)
>         at  
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal 
> (DefaultLifecycleExecutor.java :529)
>         at  
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHand 
> leFailures(DefaultLifecycleExecutor.java:309)
>         at  
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegment 
> s (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/

[macker-user] Maven and macker plugin working??

[copernic J. <cop...@gm...>]

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

[macker-user] OT: Invitation to participate in research project

[Ben A. <ben...@st...>]

Hello there

I would greatly appreciate a small amount of your time to assist with
my doctoral research at The University of Newcastle. The research
concerns open source licensing and we're seeking developers working on
Java projects. The research is supervised, ethics-approved, anonymous
and results will be freely available. Participation will also provide a
custom licensing report for your project. To learn more, please visit:

   http://licensing-research.newcastle.edu.au

Thanks for reading this email, and I hope you'll consider participating.

Best regards
Ben Alex

(My apologies for being off-topic; this list will not be emailed again)

Re: [macker-user] macker maven

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

I haven't tried it myself, but word is that it works fine. Seems like  
it should be easier to set up, but then again, if you already have a  
setup working for you....

Cheers,

Paul


On Feb 19, 2007, at 11:40 AM, Sebastian Dietrich wrote:

> What do you think of http://maven-plugins.sourceforge.net/maven- 
> macker-plugin/index.html
> Is it worth going for it or should I stick to macker via ant via  
> maven?
>
> Thanks,
> Sebastian
_________________________________________________________________
Piano music podcast: http://inthehands.com
Other interesting stuff: http://innig.net

Re: [macker-user] always accessing a package via its interface

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

First you need to come up with a pattern that separates the  
interfaces from the implementation classes. If all of your "interface  
classes" are, in fact, interfaces, you could write a rule like this:

    <pattern name="foo" class="my.app.foo.**"/>

    <pattern name="foo-api" pattern="foo">
       <include filter="interface"/>
    </pattern>

Or if you want to include both interfaces and abstract classes:

    <pattern name="foo-api" pattern="foo">
       <include filter="interface"/>
       <include filter="abstract-class"/>
    </pattern>

Or if you separate the implementation classes by naming convention:

    <pattern name="foo-api" pattern="foo">
       <exclude class="**Impl"/>
    </pattern>

Once you have a "foo-api" pattern that separates out the API from the  
implementation, you just need this rule:

    <access-rule>
        <deny>
           <to pattern="foo"/>  <!-- Deny all access to foo... -->
        </deny>
        <allow>
           <to pattern="foo-api"/> <!-- ...except to its API -->
        </allow>
        <allow>
           <from pattern="foo"/> <!-- ...or from within the package -->
        </allow>
    <access-rule>

(Warning: these examples are untested.)

Hope that helps! More details here:

     http://innig.net/macker/guide/

Cheers,

Paul


On Feb 19, 2007, at 11:35 AM, Sebastian Dietrich wrote:
> Hi!
>
> I wonder how I could define that a given package has always to be  
> accessed via its defined interface classes/interfaces.
> Right now I don't see a way other than defining it for each access  
> rule.
>
> Thanks,
> Sebastian

_________________________________________________________________
Piano music podcast: http://inthehands.com
Other interesting stuff: http://innig.net

[macker-user] macker maven

[Sebastian D. <Seb...@an...>]

What do you think of
http://maven-plugins.sourceforge.net/maven-macker-plugin/index.html
Is it worth going for it or should I stick to macker via ant via maven?
=20
Thanks,
Sebastian

[macker-user] always accessing a package via its interface

[Sebastian D. <Seb...@an...>]

Hi!
=20
I wonder how I could define that a given package has always to be
accessed via its defined interface classes/interfaces.
Right now I don't see a way other than defining it for each access rule.
=20
Thanks,
Sebastian

Re: [macker-user] detecting explicit instantiation of certain classes

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

Alex =97

You are correct that there is no way to do this currently with =20
Macker. Sorry!

It is exactly what the planned reference type differentiation feature =20=

is meant to accomplish. That feature will first differentiate only =20
method signature usages (e.g. class is returned from a method vs. =20
class is a method parameter), but will then move on to how classes =20
are used within a method body. So it will be a while, but it is in =20
the pipeline.

Cheers,

Paul

On Dec 22, 2006, at 2:35 PM, Alex Chapman wrote:

> The documentation shows how I can make a rule to identify references
> from one set of classes to another. But I'm trying to just find cases
> where one set of classes explicitly instantiates (with "new") classes
> from another set of packages. The documentation does say that being
> able to distinguish between different types of references might be
> available at some point, but I'm wondering if anyone has worked out a
> regex with Macker that can do this.
>  http://innig.net/macker/guide/accessrule.html
>
> Thanks,
>
> Alex
>
> ----------------------------------------------------------------------=20=

> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to =20
> share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?=20
> page=3Djoin.php&p=3Dsourceforge&CID=3DDEVDEV
> _______________________________________________
> Macker-user mailing list
> Mac...@li...
> https://lists.sourceforge.net/lists/listinfo/macker-user
>
> Macker home page: http://innig.net/macker/

_________________________________________________________________
Piano music podcast: http://inthehands.com
Other interesting stuff: http://innig.net

[macker-user] detecting explicit instantiation of certain classes

[Alex C. <ac...@bu...>]

The documentation shows how I can make a rule to identify references
from one set of classes to another. But I'm trying to just find cases
where one set of classes explicitly instantiates (with "new") classes
from another set of packages. The documentation does say that being
able to distinguish between different types of references might be
available at some point, but I'm wondering if anyone has worked out a
regex with Macker that can do this.
 http://innig.net/macker/guide/accessrule.html

Thanks,

Alex

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

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

Hi Alex

My impression with Macker is that it is designed to describe and check 
relationships between Classes using the implement, extend, and import 
relationships that classes have with each other. Macker does not seem to 
analyze specific call relationships between classes. (Anybody, please 
correct me if I am wrong with this).

The rules that you described require the concept of a call to a 
constructor / static factory method between classes which is not supported 
by Macker.

However, it seems if you change yor package structure a bit, you can use 
Macker to enforce your rule: If you move the DAO interfaces in their own 
subpackages, e.g. parallel to the package with the DAO implementations, 
you can define a rule that basically express the following: "It is a 
violation to use a DAO Implementation class from anywhere in the 
application with the exception of the DAOFactory". However, it would be ok 
to access the DAO interfaces from anywhere in the application.

This means that your entire application code should always refer to the 
interfaces of an DAO, never its instance. The only entity in your code 
that  may know about the DAO instances is the DAOFactory class. So, it 
would be feasible to rotate out the DAO implementations, updating the 
factory and be done with a persistence change.


How can you achieve what you want to achieve in the case in which you 
cannot change the package structure?

I tried something similar during an analysis of a large system and wanted 
to check similar small design issues as well as large scale issues. For 
the large-scale issues I was able to use Macker. For the smaller design 
issues I decided to create static aspects in AspectJ 5 to define 
appropriate join points and use the static compiler checker feature of the 
AspectJ 5 compiler to report violations as warnings or errors during the 
compilation process. This works well but there are some issues for very 
large projects.

An alternative approach is the use of Inversion of Control (IoC). With 
this design approach, DAOs would be injected into the application code by 
an external framework (e.g. Spring or an programmatic IoC approache). This 
means that the developer does not need to think about creating DAO 
instances or even call the factory for that matter. The creation and 
injection is done by the IoC  framework itself and all the DAO 
implementations can be defined in an external file. Since the application 
code would only be allowed to refer to the interface of the DAO , we can 
use the same method as described above to enforce the correct use of DAOs.

If you have any questions related to the three approaches above, please 
feel free to contact me directly. I think this may be amore of an offline 
discussion.

Regards,

Michael




mac...@li... 
Sent by: mac...@li...
03/21/2006 11:35 PM
Please respond to
mac...@li...


To
mac...@li...
cc

Subject
Macker-user digest, Vol 1 #35 - 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. factory pattern violation recognition (Alex Greif)

--__--__--

Message: 1
Date: Tue, 21 Mar 2006 09:30:00 +0100
From: "Alex Greif" <ale...@gm...>
To: mac...@li...
Subject: [macker-user] factory pattern violation recognition

Hi,

first of all, thanks for "macker"! We use it and it hels a lot!

now to my question:
beside checking architecture layer violations we want to use macker to
check factory pattern violations. In out persistence layer we want
that everybody gets a dao instance through the DAOFactory and nobody
should create a new DAO Instance with "new".

In other words, inside a dao class it is allowed to access the
DAOFactory and dao interfaces but not to instanciate and directly
access dao classes.

beneath is my rule declaration. I made these patterns:
- dao classes
- daoFactory
- dao interfaces

Then I prohibit to access dao classes and exclude the factory and the
interfaces.

My problem is that dao classes which are "OK", and follow the rules
are still reported from macker.
I disassambled the class file of this "fine" dao, and saw that there
is still an import statement, that imports the other dao.
Does that mean that the line
OtherDAO otherdao =3D DAOFactory.getInstance().getOtherDAO();
has the class declaration of OtherDAO in the constant pool, so that
macker reports it as a violation?

Is there a way to check this factory pattern violation with macker?

thanks,
ALex


    =09<pattern name=3D"pt_server_persistenz_dao_class">
    =09=09<include class=3D"${star_server_persistenz}.dao.**.DAO*" />
    =09=09<exclude class=3D"${star_server_persistenz}.dao.DAOFactory" />
    =09</pattern>
    =09<pattern name=3D"pt_server_persistenz_daoFactory"
class=3D"${star_server_persistenz}.dao.DAOFactory" />
    =09<pattern name=3D"pt_server_persistenz_dao_ifc"
class=3D"${star_server_persistenz}.dao.*Interface" />



        <access-rule>
        =09<message>DAOs d=FCrfen DAOs nicht direkt aufrufen, sondern nur
=FCber DAOFactory</message>
            <deny>
            =09<from pattern=3D"pt_server_persistenz_dao_class"/>
            =09<to>
            =09=09<include pattern=3D"pt_server_persistenz_dao_class"/>
            =09=09<exclude pattern=3D"pt_server_persistenz_daoFactory"/>
            =09=09<exclude pattern=3D"pt_server_persistenz_dao_ifc"/>
                </to>
            </deny>
        </access-rule>



--__--__--

_______________________________________________
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] factory pattern violation recognition

[Alex G. <ale...@gm...>]

Hi,

first of all, thanks for "macker"! We use it and it hels a lot!

now to my question:
beside checking architecture layer violations we want to use macker to
check factory pattern violations. In out persistence layer we want
that everybody gets a dao instance through the DAOFactory and nobody
should create a new DAO Instance with "new".

In other words, inside a dao class it is allowed to access the
DAOFactory and dao interfaces but not to instanciate and directly
access dao classes.

beneath is my rule declaration. I made these patterns:
- dao classes
- daoFactory
- dao interfaces

Then I prohibit to access dao classes and exclude the factory and the
interfaces.

My problem is that dao classes which are "OK", and follow the rules
are still reported from macker.
I disassambled the class file of this "fine" dao, and saw that there
is still an import statement, that imports the other dao.
Does that mean that the line
OtherDAO otherdao =3D DAOFactory.getInstance().getOtherDAO();
has the class declaration of OtherDAO in the constant pool, so that
macker reports it as a violation?

Is there a way to check this factory pattern violation with macker?

thanks,
ALex


    =09<pattern name=3D"pt_server_persistenz_dao_class">
    =09=09<include class=3D"${star_server_persistenz}.dao.**.DAO*" />
    =09=09<exclude class=3D"${star_server_persistenz}.dao.DAOFactory" />
    =09</pattern>
    =09<pattern name=3D"pt_server_persistenz_daoFactory"
class=3D"${star_server_persistenz}.dao.DAOFactory" />
    =09<pattern name=3D"pt_server_persistenz_dao_ifc"
class=3D"${star_server_persistenz}.dao.*Interface" />



        <access-rule>
        =09<message>DAOs d=FCrfen DAOs nicht direkt aufrufen, sondern nur
=FCber DAOFactory</message>
            <deny>
            =09<from pattern=3D"pt_server_persistenz_dao_class"/>
            =09<to>
            =09=09<include pattern=3D"pt_server_persistenz_dao_class"/>
            =09=09<exclude pattern=3D"pt_server_persistenz_daoFactory"/>
            =09=09<exclude pattern=3D"pt_server_persistenz_dao_ifc"/>
                </to>
            </deny>
        </access-rule>

Re: [macker-user] Macker's Rules

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

Hi Sofi. Macker deals more with the structure of compiled class  
files, so something like "lines per method" isn't in there. If you're  
interested in analyzing dependencies between classes, then you're in  
business.

It sounds like you probably want something that operates on source  
code, not compiled classes.

Cheers,

Paul


On Mar 6, 2006, at 4:23 AM, Sophie Le Normand wrote:

> Hi,
> I'm a student and I have to develop a source code analyser in Java.  
> I don't know yet if I would use an existing tool or if I would  
> develop an analyser from scratch.
> I'm searching the rules that are already implemented in Macker and  
> the defined thresholds (for example the maximal number of lines  
> allowed in a method) but my research have been vain.
> So, if you can give me to find this information, it would be a  
> great help.
> Thanks
> Sofi
>
> _________________________________________________________________
> FREE pop-up blocking with the new MSN Toolbar - get it now! http:// 
> toolbar.msn.click-url.com/go/onm00200415ave/direct/01/
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting  
> language
> that extends applications into web and mobile media. Attend the  
> live webcast
> and join the prime developer group breaking into this new coding  
> territory!
> http://sel.as-us.falkag.net/sel? 
> cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> Macker-user mailing list
> Mac...@li...
> https://lists.sourceforge.net/lists/listinfo/macker-user
>
> Macker home page: http://innig.net/macker/
>

_________________________________________________________________
Piano music podcast: http://inthehands.com
Other interesting stuff: http://innig.net

[macker-user] Macker's Rules

[Sophie Le N. <sof...@ms...>]

Hi,
I'm a student and I have to develop a source code analyser in Java. I don't 
know yet if I would use an existing tool or if I would develop an analyser 
from scratch.
I'm searching the rules that are already implemented in Macker and the 
defined thresholds (for example the maximal number of lines allowed in a 
method) but my research have been vain.
So, if you can give me to find this information, it would be a great help.
Thanks
Sofi

_________________________________________________________________
FREE pop-up blocking with the new MSN Toolbar - get it now! 
http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/

Re: [macker-user] Improvements suggestions

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

Vlad --

An Eclipse plugin would be welcome. Different people have talked  
about it, but to my knowledge, nobody's done anything about it. It's  
not in the main dev pipeline, so feel free to give it a go!

Cheers,

Paul


On Feb 23, 2006, at 6:32 AM, Vlad Dumitrescu wrote:

> Hi!
>
> I've recently found Macker, and think it's a great tool.
>
> I saw that development recently started anew, and also moved on to  
> Eclipse. I would like to suggest that beside having an Ant task,  
> make it available as an Eclipse builder.
>
> I might give it a try myself (if I find the time), but I thought  
> I'd check first if this is already planned or in the pipeline.
>
> best regards,
> Vlad
>

_________________________________________________________________
Piano music podcast: http://inthehands.com
Other interesting stuff: http://innig.net

[macker-user] Improvements suggestions

[Vlad D. <vla...@ho...>]

Hi!
 
I've recently found Macker, and think it's a great tool. 
 
I saw that development recently started anew, and also moved on to Eclipse.
I would like to suggest that beside having an Ant task, make it available as
an Eclipse builder. 
 
I might give it a try myself (if I find the time), but I thought I'd check
first if this is already planned or in the pipeline. 
 
best regards,
Vlad
 

[macker-user] svn migration

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

Sourceforge is beta testing Subversion support, and Macker is  
participating in the beta test. In theory, the migration is happening  
right now.

This shouldn't affect most people; however, if you've been working  
"bleeding edge" off of CVS, you'll need to switch over to Subversion.  
Future changes will not show up in CVS.

I'm very pleased that we'll be getting to use Subversion. It's a  
great tool, a rare piece of really elegant feature design -- it  
accomplishes every useful part of CVS's functionality (and then some)  
with a far smaller and more comprehensible feature set. I recommend  
learning about it if you haven't yet!

Yes, this does mean that I'm gearing up to work on long-overdue  
Macker 0.5. Those interested in discussing it as it evolves should  
subscribe to the developer list.

Cheers,

Paul

_________________________________________________________________
Piano music podcast: http://inthehands.com
Other interesting stuff: http://innig.net

Re: [macker-user] primary classes: can i also include jar files?

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

You can't read primary classes directly from a jar. You can, however,  
use Ant to expand the jar in question into a temp directory under  
build -- which will give you a bunch of .class files -- then include  
those files as primary classes in the normal way.

This should solve your problem.

Cheers,

Paul


On Dec 22, 2005, at 11:26 AM, Michael Sassin wrote:

> Hi
>
> I want to analyze the dependencies between libraries that are  
> contained in jar files with the help of Macker rules.
>
> I tried to set the primary classes to include also jar files but  
> this appear not to work.
>
> Can I add classes in jar file as primary classes or is this  
> currently not supported.
>
> Michael

_________________________________________________________________
Piano music podcast: http://inthehands.com
Other interesting stuff: http://innig.net

[macker-user] primary classes: can i also include jar files?

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

Hi

I want to analyze the dependencies between libraries that are contained in 
jar files with the help of Macker rules.

I tried to set the primary classes to include also jar files but this 
appear not to work.

Can I add classes in jar file as primary classes or is this currently not 
supported.

Michael

Re: [macker-user] naming convention for classes implementing an interface

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

Hello again, Etienne!

There is currently no good way of doing this. One of those features  
in the queue is to allow rules of the form "everything that matches X  
must / must not match Y," which is what you need.

If there is a specific IFoo you want to write a rule for, you can do  
this (icky, but I believe it works):

         <access-rule>
             <deny>
                 <from>
                     <include filter="subtype-of" class="IFoo"/>
                     <exclude class="**.*FooImpl"/>
                 </from>
                 <to class="void"/>
             </deny>
         </access-rule>

If, however, you want this rule to apply generically to every IFoo,  
IBar, and IBaz (with FooImpl, BarImpl, and BazImpl respectively),  
you're out of luck.

Hope this helps, at least a little....

BTW, if anybody on the list feels like making a donation to push the  
next version of Macker into more active development, I certainly  
wouldn't object.

Cheers,

Paul


On Dec 2, 2005, at 5:28 PM, Etienne Studer wrote:

> Hi Paul
>
> How can I define a rule that says:
>
> all implementations of interface IFoo must match a class name  
> '.*FooImpl'
>
> Your kind help would be once again very much appreciated!!
>
> --Etienne
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through  
> log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD  
> SPLUNK!
> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> _______________________________________________
> Macker-user mailing list
> Mac...@li...
> https://lists.sourceforge.net/lists/listinfo/macker-user
>
> Macker home page: http://innig.net/macker/
>

_________________________________________________________________
Piano music podcast: http://inthehands.com
Other interesting stuff: http://innig.net

[macker-user] naming convention for classes implementing an interface

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

Hi Paul

How can I define a rule that says:

all implementations of interface IFoo must match a class name '.*FooImpl'

Your kind help would be once again very much appreciated!!

--Etienne

[macker-user] expendability of Macker definition files

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

Hi

We started to use Macker in conjunctions with other tools that we wrote 
ourselves such as a tool that generates a Spreadsheet with a Design 
Structure Matrix (DSM) visualizing all legal and illegal dependencies 
based on the Macker rule definition and Macker report files.

As we made progress, we realized that we would like to add some additional 
data in the report (I think my colleague already contacted you about 
adding the pattern information per class that contains a violation. in the 
report file) and the rule definition files.

For example, we would like to include a sequence attribute in the 
"pattern" tag to define layering levels and subsystems that we would use 
in our own DSM tool to generate an appropriate representation. Currently, 
we need to keep the information in a separate file which is still 
manageable but somewhat cumbersome and prone to inconsistencies.

Is there a way to add additional attributes in Macker tags such as 
"pattern"? So far, I do not see a way of doing this. Maybe an undocumented 
attribute I could use for now?

If such a feature is not currently available, would it be possible to 
change the XML processing in the future to allow the definition of new 
attributes that are ignored by Macker but that could be exploited by other 
tools? This way we could create a Meta Model for architecture dependencies 
based on the existing structure and do not have to use external files or 
additional XSL processing.

Michael

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

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

> Do you post a message about new macker releases on this list?

Yes, including betas.

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

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

Hi Paul

I tried the second approach you listed and so far it looks good. Macker 
successfully detected a violation!

Thanks for all your help on this! And looking forward to the next Macker 
release ;-)

Do you post a message about new macker releases on this list?

--Etienne



Paul Cantrell wrote:
> There's not really an elegant way to do this. It's one of the  features 
> on my list.
> 
> There is a way -- it's just a little klugy:
> 
>         <access-rule>
>             <deny>
>                 <from>
>                     <include filter="subtype-of" class="Alpha">
>                         <include filter="subtype-of" class="Beta"/>
>                     </include>
>                 </from>
>             </deny>
>         </access-rule>
> 
> The problem with that way of doing it is that you get a *bunch* of  
> errors, one for every class that the offending one references! You  can 
> also do this:
> 
>         <access-rule>
>             <deny>
>                 <from>
>                     <include filter="subtype-of" class="Alpha">
>                         <include filter="subtype-of" class="Beta"/>
>                     </include>
>                 </from>
>                 <to class="void"/>
>             </deny>
>         </access-rule>
> 
> However, I'm not 100% sure that every class is *guaranteed* to  
> reference the primitive type void, so it's conceivable that this  might 
> miss one....
> 
> In any case, either way is just a hack until I get the next version  of 
> Macker out the door.
> 
> Cheers,
> 
> Paul
> 
> 
> On Oct 19, 2005, at 11:18 AM, Etienne Studer wrote:
> 
>> Hi Paul
>>
>> Thanks!
>>
>> How can I transform this into a rule that says 'Don't implement  
>> interface Alpha AND interface Beta at the same time'. Basically,  
>> every class may implement interface Alpha or interface Beta, but no  
>> class must implement interface Alpha AND interface Beta at the same  
>> time. I want to detect such "violations".
>>
>> I'm sorry that I don't manage to come up with the complete access- 
>> rule myself... Maybe Paul knows howto...
>>
>> --Etienne
>>
>>
>> Paul Cantrell wrote:
>>
>>> 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!
>>>>
>>> -------------------------------------------------------
>>> This SF.Net email is sponsored by:
>>> Power Architecture Resource Center: Free content, downloads,  
>>> discussions,
>>> and more. http://solutions.newsforge.com/ibmarch.tmpl
>>> _______________________________________________
>>> 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:
> Power Architecture Resource Center: Free content, downloads, discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> Macker-user mailing list
> Mac...@li...
> https://lists.sourceforge.net/lists/listinfo/macker-user
> 
> Macker home page: http://innig.net/macker/
> 

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

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

There's not really an elegant way to do this. It's one of the  
features on my list.

There is a way -- it's just a little klugy:

         <access-rule>
             <deny>
                 <from>
                     <include filter="subtype-of" class="Alpha">
                         <include filter="subtype-of" class="Beta"/>
                     </include>
                 </from>
             </deny>
         </access-rule>

The problem with that way of doing it is that you get a *bunch* of  
errors, one for every class that the offending one references! You  
can also do this:

         <access-rule>
             <deny>
                 <from>
                     <include filter="subtype-of" class="Alpha">
                         <include filter="subtype-of" class="Beta"/>
                     </include>
                 </from>
                 <to class="void"/>
             </deny>
         </access-rule>

However, I'm not 100% sure that every class is *guaranteed* to  
reference the primitive type void, so it's conceivable that this  
might miss one....

In any case, either way is just a hack until I get the next version  
of Macker out the door.

Cheers,

Paul


On Oct 19, 2005, at 11:18 AM, Etienne Studer wrote:

> Hi Paul
>
> Thanks!
>
> How can I transform this into a rule that says 'Don't implement  
> interface Alpha AND interface Beta at the same time'. Basically,  
> every class may implement interface Alpha or interface Beta, but no  
> class must implement interface Alpha AND interface Beta at the same  
> time. I want to detect such "violations".
>
> I'm sorry that I don't manage to come up with the complete access- 
> rule myself... Maybe Paul knows howto...
>
> --Etienne
>
>
> Paul Cantrell wrote:
>
>> 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!
>>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by:
>> Power Architecture Resource Center: Free content, downloads,  
>> discussions,
>> and more. http://solutions.newsforge.com/ibmarch.tmpl
>> _______________________________________________
>> Macker-user mailing list
>> Mac...@li...
>> https://lists.sourceforge.net/lists/listinfo/macker-user
>> Macker home page: http://innig.net/macker/
>>
>
>

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

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

Hi Paul

Thanks!

How can I transform this into a rule that says 'Don't implement 
interface Alpha AND interface Beta at the same time'. Basically, every 
class may implement interface Alpha or interface Beta, but no class must 
implement interface Alpha AND interface Beta at the same time. I want to 
detect such "violations".

I'm sorry that I don't manage to come up with the complete access-rule 
myself... Maybe Paul knows howto...

--Etienne


Paul Cantrell wrote:
> 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!
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads, discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> Macker-user mailing list
> Mac...@li...
> https://lists.sourceforge.net/lists/listinfo/macker-user
> 
> Macker home page: http://innig.net/macker/
>