macker-developer — Developer discussion around implementation issues

[macker-developer] Macker licensing relaxation

[<fra...@ar...>]

Hello developers,

first of all thanks for this great tool.

Would it be possible to license it more relaxed? From your FAQ it states:

Macker is available under the GPL. This license allows you to freely use 
and redistribute Macker, and to bundle it with other software.
If you make changes to Macker or extend it, and you choose to distribute 
those changes, you must license them under the GPL. It would be marvelous 
if you submit your patches back to the Macker project for possible 
inclusion in future versions.

This is IMO not correct, because just linking to it would cause my 
software to be GPL. From the GPL2 it states:

A system incorporating a GPL-covered program is an extended version of 
that program. The GPL says that any extended version of the program must 
be released under the GPL if it is released at all. This is for two 
reasons: to make sure that users who get the software get the freedom they 
should have, and to encourage people to give back improvements that they 
make.

So now it depends upon the understanding of "incorporating", but I'd 
sooner go the safe way an may kindly ask if it woul be possible to change 
to Apache License or provide it as alternative license.

Kind regards

Frank Jakop

[macker-developer] Continued Macker development and Macker 0.5

[Barre D. <bar...@us...>]

Since last week the development on Macker has been picked up again,
accompanied with new developers.
Through this mail I would like to indicate that the Macker project
from this point on will again be actively maintained and expanded.

* The Team
Paul Cantrell has created an excellent tool called Macker and but has,
unfortunately, not been able to spent much time on it lately; in
response I have offered to continue Macker development on sourceforge
which Paul has agreed to.
Jasper de Vries also joined the macker project as a commiter.

* Macker 0.4
Currently Macker is written with Java 1.4 and Ant as target platforms,
supported with the codehaus project macker-maven-plugin by Wayne Fay.
The plan is to keep the 0.4 version of Macker on the same target
platform and only provide major bugfixes on the release.

* Macker 0.5
In the meanwhile a 0.5 version of Macker will be worked on with a few
things planned so far:
- moving to a more plugable design for connectors, possibly
integrating the codehaus macker-maven-plugin project into the core
release
- full support for Java 1.5 and 1.6
- review on the external API and accompanying documentation so
plug-in/connector development is simplified where needed

* Macker 0.5 and backwards compatibility
No major configuration changes are planned for 0.5 to maintain full
backwards compatibility (in terms of configuration).
There also aren't any major functional changes planned besides the
ones mentioned above. This doesn't mean that no new functionality will
 be included in 0.5; please post a feature request in the tracker or
one of the mailing-lists so it can be considered for the next release.
Patches/diffs with the functionality implemented are more then welcome
as well. ;-)
Due to the potential impact of the changes on the API, we're not
maintaining backwards compatibility on the contracts of public
classes.

* Website
Since innig.net is the personal website for Paul Cantrell, the Macker
website will, in time, move to macker.sourceforge.net.
I will post to both the developer and user mailing-lists when there is
a concrete date set for the move.
As a sidenote, the package naming will not reflect these changes and
will stay net.innig.macker.*.


With kinds regards,

Barre Dijkstra
bar...@us...

Re: [macker-developer] Test Driven Development

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

No, I implemented it using something you might call "function test =20
second" =E2=80=94 I fiddle around, prototyping a feature until I like =
the =20
user experience. I then write a high-level test or set of tests for =20
that feature, which test end results (functional test) and not all =20
the details inside (unit test). In the case of Macker, such a test =20
consists of source code, rules file, and expected output. I then =20
change the code until the test works.

I have used TDD on many projects in the past. It can work well, if =20
the tests are good, although it's not my personal preference. I like =20
prototyping first. I feel like TDD locks me too much into feature =20
checklists (it raises the cost of change early in the cycle), whereas =20=

prototyping first lets me focus on user experience and fluidly rework =20=

features as needed.

Cheers, P


On Sep 23, 2007, at 4:28 AM, Przemys=C5=82aw Szkudlarek wrote:

> Hello
>
> Did you create Macker using Test Driven Development?
>
> Definition from wikipedia.org: "Test-Driven Development (TDD) is a =20
> software development technique that involves repeatedly first =20
> writing a test case and then implementing only the code necessary =20
> to pass the test"
>
> Best regards,
> Przemek
>
> ----------------------------------------------------------------------=20=

> ---
> 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-developer mailing list
> Mac...@li...
> https://lists.sourceforge.net/lists/listinfo/macker-developer
>
> Macker home page: http://innig.net/macker/
>

[macker-developer] =?utf-8?q?Test_Driven_Development?=

[<mu...@o2...>]

Hello=20

Did=20you=20create=20Macker=20using=20Test=20Driven=20Development?=20

Definition=20from=20wikipedia.org:=20"Test-Driven=20Development=20(TDD)=20=
is=20a=20software=20development=20technique=20that=20involves=20repeatedl=
y=20first=20writing=20a=20test=20case=20and=20then=20implementing=20only=20=
the=20code=20necessary=20to=20pass=20the=20test"=20
=20
Best=20regards,
Przemek

[macker-developer] 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-developer] Part boundary regex question

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

Andriy -- You're entirely correct about how the regexps work. It  
should be documented; I'll put this on my todo list.

Cheers,

Paul

On Jun 10, 2005, at 12:45 PM, Andriy Palamarchuk wrote:

> Hi Paul,
>   I was having trouble dealing with packages because
> of nested classes. Had to look in the code,
> specifically MackerRegex class. It seems that Macker
> notation for part boundary (".") matches both - inner
> class specification ("$" string) and package boundary
> ("." string). Also, it seems that Macker has separate
> special notations for package boundary ("/" notation)
> and inner class name ("$").
>
> Is this correct?
> Right now documentation only describes "." notation.
> Could you please update the docs and include
> description of other notations as well?
> It is pity to not being able to use existing features.
>
> Thank you for a nice tool.
> Andriy
>
>
> PS my previous message is sitting somewhere in your
> approval queue :-) Check it out. Finally decided to
> subscribe so I won't bother you.
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: NEC IT Guy Games.  How far can  
> you shotput
> a projector? How fast can you ride your desk chair down the office  
> luge track?
> If you want to score the big prize, get to know the little guy.
> Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
> _______________________________________________
> Macker-developer mailing list
> Mac...@li...
> https://lists.sourceforge.net/lists/listinfo/macker-developer
>
> Macker home page: http://innig.net/macker/
>
>

_________________________________________________________________

"After hearing ten thousand explanations, a fool is no wiser.
  But an intelligent person needs only two thousand five hundred."
                                                    -- Mahabharata

[macker-developer] Part boundary regex question

[Andriy P. <ap...@ya...>]

Hi Paul,
  I was having trouble dealing with packages because
of nested classes. Had to look in the code,
specifically MackerRegex class. It seems that Macker
notation for part boundary (".") matches both - inner
class specification ("$" string) and package boundary
("." string). Also, it seems that Macker has separate
special notations for package boundary ("/" notation)
and inner class name ("$"). 

Is this correct?
Right now documentation only describes "." notation.
Could you please update the docs and include
description of other notations as well?
It is pity to not being able to use existing features.

Thank you for a nice tool.
Andriy


PS my previous message is sitting somewhere in your
approval queue :-) Check it out. Finally decided to
subscribe so I won't bother you.

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: [macker-developer] Patch to help running in a forked JVM under Ant

[Ross B. <ro...@ce...>]

Hi Paul,

Attached is an updated patch. It includes the original changes, as well
as a simple performance improvement - the Ant task no longer calls
macker.addClass()if we are going to fork the JVM.  

This patch should also be closer to macker's coding style - it took me a
while to get used to it!

Once it has enough memory, macker's performance is fine for my
purposes.  To run 20 rules over 7000+ classes takes only about 90
seconds (on a P4 with enough RAM to avoid swapping). I've added macker
as a precursor to a unit test suite that takes about 30 minutes to run,
so that 90 seconds is barely noticeable. 

Ross.
 

On Mon, 2003-11-17 at 16:32, Paul Cantrell wrote:
> Ross --
> 
> Thanks a bundle!  Looks like a great patch.  I should find some time to 
> apply it this week.
> 
> I know that Macker doesn't scale to very large projects all that well.  
> I can make some guesses about where the memory is going, but it would 
> be nice to do some serious profiling and find out for sure.  I've never 
> given it any serious optimization attention, so perhaps now is the 
> time....  Does anybody on the list have profiling tools / expertise?
> 
> Just out of curiosity, how large is the project you're running it on -- 
> how many classes?
> 
> Thanks again for the patch.
> 
> Cheers,
> 
> Paul
> 
> 
> On Saturday, November 15, 2003, at 10:58  PM, Ross Burnett wrote:
> 
> > Hi,
> >
> > Congratulations & many thanks for Macker, it is a useful tool to have!
> >
> > After experimenting with it for a while I'm now integrating it an Ant
> > build environment, and in doing so I've found a couple of issues:
> >
> > 1. Macker slows to a crawl as its memory usage approaches the JVM's 
> > max.
> > In other ant tasks (eg. javadoc) this is normally solved by forking off
> > a new JVM with a large maximum memory. While macker supports forking, 
> > it
> > doesn't provide a way to set the max memory for the new JVM.
> >
> > (I realise I can increase the memory of the original Ant JVM using
> > something like ANT_OPTS=-Xmx256M, but I prefer to keep the Ant
> > environment as standard as possible: the less developers have to alter
> > the better)
> >
> > 2. When forking a new JVM, the macker ant task adds the name of every
> > class file as an argument to the new process. This fails with a largish
> > number of classes, presumably due to the command line being too long.
> >
> > Attached is a patch that aims to solve these issues by doing the
> > following simple things:
> >
> > a. Adding an optional 'maxmemory' attribute to the macker ant task so
> > that the max memory of the forked JVM can be specified.
> >
> > b. Adding support for an indirect input file to macker. A command line
> > argument of the form '@file' means that each line in 'file' identifies 
> > a
> > class file to process.
> >
> > c. Updating the macker ant task so that when forking a new JVM it 
> > passes
> > the list of class files via a temporary @file, rather than listing them
> > all on the command line.
> >
> > The patch was made against the CVS sources as at Sun Nov 16 04:44:14 
> > UTC
> > 2003, using 'cvs diff -b -c'.  Please let me know if I should submit 
> > the
> > proposed changes in some other way.
> >
> > Regards,
> >
> > Ross Burnett 
> 

Re: [macker-developer] Patch to help running in a forked JVM under Ant

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

Ross --

Thanks a bundle!  Looks like a great patch.  I should find some time to 
apply it this week.

I know that Macker doesn't scale to very large projects all that well.  
I can make some guesses about where the memory is going, but it would 
be nice to do some serious profiling and find out for sure.  I've never 
given it any serious optimization attention, so perhaps now is the 
time....  Does anybody on the list have profiling tools / expertise?

Just out of curiosity, how large is the project you're running it on -- 
how many classes?

Thanks again for the patch.

Cheers,

Paul


On Saturday, November 15, 2003, at 10:58  PM, Ross Burnett wrote:

> Hi,
>
> Congratulations & many thanks for Macker, it is a useful tool to have!
>
> After experimenting with it for a while I'm now integrating it an Ant
> build environment, and in doing so I've found a couple of issues:
>
> 1. Macker slows to a crawl as its memory usage approaches the JVM's 
> max.
> In other ant tasks (eg. javadoc) this is normally solved by forking off
> a new JVM with a large maximum memory. While macker supports forking, 
> it
> doesn't provide a way to set the max memory for the new JVM.
>
> (I realise I can increase the memory of the original Ant JVM using
> something like ANT_OPTS=-Xmx256M, but I prefer to keep the Ant
> environment as standard as possible: the less developers have to alter
> the better)
>
> 2. When forking a new JVM, the macker ant task adds the name of every
> class file as an argument to the new process. This fails with a largish
> number of classes, presumably due to the command line being too long.
>
> Attached is a patch that aims to solve these issues by doing the
> following simple things:
>
> a. Adding an optional 'maxmemory' attribute to the macker ant task so
> that the max memory of the forked JVM can be specified.
>
> b. Adding support for an indirect input file to macker. A command line
> argument of the form '@file' means that each line in 'file' identifies 
> a
> class file to process.
>
> c. Updating the macker ant task so that when forking a new JVM it 
> passes
> the list of class files via a temporary @file, rather than listing them
> all on the command line.
>
> The patch was made against the CVS sources as at Sun Nov 16 04:44:14 
> UTC
> 2003, using 'cvs diff -b -c'.  Please let me know if I should submit 
> the
> proposed changes in some other way.
>
> Regards,
>
> Ross Burnett 

[macker-developer] Patch to help running in a forked JVM under Ant

[Ross B. <ro...@ce...>]

Hi,

Congratulations & many thanks for Macker, it is a useful tool to have!

After experimenting with it for a while I'm now integrating it an Ant
build environment, and in doing so I've found a couple of issues:

1. Macker slows to a crawl as its memory usage approaches the JVM's max.
In other ant tasks (eg. javadoc) this is normally solved by forking off
a new JVM with a large maximum memory. While macker supports forking, it
doesn't provide a way to set the max memory for the new JVM. 

(I realise I can increase the memory of the original Ant JVM using
something like ANT_OPTS=-Xmx256M, but I prefer to keep the Ant
environment as standard as possible: the less developers have to alter
the better)

2. When forking a new JVM, the macker ant task adds the name of every
class file as an argument to the new process. This fails with a largish
number of classes, presumably due to the command line being too long. 

Attached is a patch that aims to solve these issues by doing the
following simple things:

a. Adding an optional 'maxmemory' attribute to the macker ant task so
that the max memory of the forked JVM can be specified.

b. Adding support for an indirect input file to macker. A command line
argument of the form '@file' means that each line in 'file' identifies a
class file to process.

c. Updating the macker ant task so that when forking a new JVM it passes
the list of class files via a temporary @file, rather than listing them
all on the command line.

The patch was made against the CVS sources as at Sun Nov 16 04:44:14 UTC
2003, using 'cvs diff -b -c'.  Please let me know if I should submit the
proposed changes in some other way.  

Regards,

Ross Burnett <ro...@ce...>

[macker-developer] Macker 0.4.2 released

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

Version 0.4.2 adds a small but significant feature: Macker can now 
generate HTML reports, allowing Macker to function well in an automated 
build (a la AntHill / Cruise Control).  You can generate other types of 
reports as well by writing your own XSLT.  Reports are generated by a 
new Ant task.

Download:
     http://sourceforge.net/project/showfiles.php?group_id=55296

Documentation on the new report feature:
     http://innig.net/macker/guide/report.html

A sample HTML report:
     http://innig.net/macker/guide/report-example/macker-report.html

List of changes in 0.4:
     http://innig.net/macker/whatsnew.html

[macker-developer] Two Macker dev tasks

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

I have two open development tasks for the next dot release of Macker:

(1) I'd like to report line numbers for errors in the rules XML file.  
I have some code snippets from the JDOM mailing list which explain how 
to attach file name and line numbers to JDOM elements, so this 
shouldn't be too difficult a task -- it's just a matter of wiring 
things up.

(2) I need a unit test harness for the Ant task, similar to the 
existing test harness for rules files (or perhaps based on it).  This 
is a little more involved: somebody needs to figure out how to invoke 
Ant with an XML fragment from Java, then parse and run XML Ant task 
tests.

If anybody is interested in taking on either of these tasks, let me 
know, and I'll share some more detailed thoughts and requirements.

Paul

[macker-developer] Macker 0.4.1: an important bug fix

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

Wouldn't you know it -- a mere three hours after posting the release of  
0.4, I found a fairly serious bug, and had to release a patch right  
away.  Fortunately, it took nearly 24 hours for my original annoucement  
to appear on the JDOM list (wake up, Sourceforge!), and the patch was  
probably already available by the time most of you went to download the  
new version.  Still, I though I'd make a second annoucement just in  
case.

The bug was pretty serious: having a <foreach> anywhere in your rules  
file would cause the build to fail, even if there were no rule  
violations.  Yikes!  I've updated the regression tests to catch this.

I'm curious: is anybody out there actually using Macker?  I never got  
any feedback at all on any of the 0.4 betas....

The bug:
      
https://sourceforge.net/tracker/ 
index.php?func=detail&aid=794536&group_id=55296&atid=476503

Download:
     http://sourceforge.net/project/showfiles.php?group_id=55296

Cheers,

Paul

[macker-developer] Macker 0.4 released

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

A mad Sunday dash of coding has Macker 0.4 out the door.  The 
distribution is available on sourceforge, and the online guide is now 
updated to reflect 0.4.  I fixed a whole bunch of bugs today, but on 
the off chance that you find more, please let me know about them!

Download:
     http://sourceforge.net/project/showfiles.php?group_id=55296

Summary of changes:
     http://innig.net/macker/whatsnew.html

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

Thanks to those who helped out with this release!
    http://innig.net/macker/thanks.html

Cheers,

Paul

[macker-developer] Macker 0.4b1 now available

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

I've completed the first beta of version 0.4.  Please download it, and 
start those bug reports coming!

What's new in 0.4:

     http://innig.net/macker/whatsnew.html

Download page:

     http://sourceforge.net/project/showfiles.php?group_id=55296

I don't have acknowledgements for those of you who sent in patches yet 
-- apologies -- I'll be sure to include you in the full release!

Cheers,

Paul

[macker-developer] XML reporting

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

A beta-ish version of the oft-requested XML reporting is now checked 
into cvs.  I worked off of the patch Scott Sayles posted, with a few 
changes and additions (most notably, it uses JDOM to generate the XML).

You can try it out by specifying the option:
	
	xmlReportFile="foo.xml"

...on the <macker> tag in your Ant script, or by using:

	-o foo.xml

...from the command line.  Post suggestions to the list.

Cheers,

Paul

[macker-developer] XMLReportListener

[Scott S. <ss...@fg...>]

My apologies for not getting to this sooner, but I've been on vacation.

Attached is a patch file containing the changes made to the Macker main
class and the source file for XMLReportListener.

It was a quick hack but it works.  Essentially, I had to create and 
maintain a BufferedWriter and XMLReportListener outside of the rule set 
checking loop in the check method in Macker.  I've also added a new 
command line parameter -w|--writetofile that will tell Macker to 
generate the xml report in a file named macker-report.xml.  The output 
file can be configured programmatically.

Here's a sample of the XML:
===========================================
<macker-report>
    <rule-set name="no domain in swingclient">
    </rule-set>
    <rule-set name="no PAL in swingclient">
        <acess-violation>
            <description>Illegal reference
  from com.fgm.tracker.swingclient.SearchCriteriaDialog
    to com.fgm.pal.QueryCriterion</description>
            <from>com.fgm.tracker.swingclient.SearchCriteriaDialog</from>
            <to>com.fgm.pal.QueryCriterion</to>
        </acess-violation>
        <acess-violation>
            <description>Illegal reference
  from com.fgm.tracker.swingclient.SearchCriterionPanel
    to com.fgm.pal.QueryCriterion</description>
            <from>com.fgm.tracker.swingclient.SearchCriterionPanel</from>
            <to>com.fgm.pal.QueryCriterion</to>
        </acess-violation>
    </rule-set>
    <rule-set name="no domain in domainapi">
    </rule-set>
</macker-report>
======================================


Let me know what you think.

Scott

Re: [macker-developer] Adding ruleViolationProperty and errorProperty to Macker Ant Task

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

Xandy --

Sounds like a very good idea to me.  I've logged it as a feature  
request:

http://sourceforge.net/tracker/ 
index.php?func=detail&aid=758578&group_id=55296&atid=476506

The most obvious way to handle a forked JVM is through exit codes,  
though that's not necessarily the best.  We might consider setting  
different properties for the different severity levels: something like  
macker.error, macker.warning, macker.info, and then macker.exception or  
macker.failure for rules syntax, etc.  The property names should  
respect Ant conventions and precedent from the JUnit task, and should  
be easy to use in Ant-style conditionals.

If anybody implements this, I'll welcome the patch.

Paul


On Saturday, June 21, 2003, at 03:43  PM, Xandy Johnson wrote:

> I'd like to see the Macker Ant Task have the ability to set Ant
> properties both on error conditions and on rule violations.  This would
> be very much like the failureProperty and errorProperty of the JUnit  
> Ant
> Task.  The errorProperty would be set if there is some error condition
> other than rule violations (e.g. a malformed rule) and the
> ruleViolationProperty would be set if there are rule violations.  A Use
> Case for such a feature is sending email only if there are problems.
>
> I spent a few minutes starting this, but that was over a week ago.   
> I've
> attached the trivial patch of what I had so far.  I'm not even sure of
> its state.  The main thing I don't know how to do is to handle the case
> of a forked JVM.  I wish I had the time to see this through, but I'm
> falling further and further behind on my "real" tasks at work and I'm
> not sure when I'd get to this.  I'd really appreciate if someone else
> would take the idea and run with it.
>
> Thanks,
> Xandy
> <ruleViolationProperty.patch><mime-attachment>

[macker-developer] Adding ruleViolationProperty and errorProperty to Macker Ant Task

[Xandy J. <xa...@fg...>]

I'd like to see the Macker Ant Task have the ability to set Ant
properties both on error conditions and on rule violations.  This would
be very much like the failureProperty and errorProperty of the JUnit Ant
Task.  The errorProperty would be set if there is some error condition
other than rule violations (e.g. a malformed rule) and the
ruleViolationProperty would be set if there are rule violations.  A Use
Case for such a feature is sending email only if there are problems.

I spent a few minutes starting this, but that was over a week ago.  I've
attached the trivial patch of what I had so far.  I'm not even sure of
its state.  The main thing I don't know how to do is to handle the case
of a forked JVM.  I wish I had the time to see this through, but I'm
falling further and further behind on my "real" tasks at work and I'm
not sure when I'd get to this.  I'd really appreciate if someone else
would take the idea and run with it.

Thanks,
Xandy

[macker-developer] First post!

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

(-1, Redundant)

[macker-developer] First post!

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

(-1, Testing)