jrefactory-developers — Discussions among people actively developing software for JRefactory

[Jrefactory-developers] Status of JRefactory

[Johannes M. <jma...@no...>]

Hi,

what is the status of JRefactory? Is anybody still working on improving 
it?

I've made an extension for the pretty printer that I would like to 
contribute, and I've also run into a few problems that I might be able to 
fix.

Regards
 	Johannes

[Jrefactory-developers] JRefactory on Gump

[Adam J. <aj...@mr...>]

Hey folks,

I was just looking at some Gump failures,and wondered if you were interested
in this.

http://brutus.apache.org/gump/public/jrefactory/jrefactory-pretty/gump_work/build_jrefactory_jrefactory-pretty.html

pretty:
    [javac] Compiling 2 source files to
/usr/local/gump/public/workspace/jrefactory/ant.build/classes
    [javac]
/usr/local/gump/public/workspace/jrefactory/src/org/acm/seguin/summary/load/
SwingLoadStatus.java:115: cannot resolve symbol
    [javac] symbol  : method setAlwaysOnTop (boolean)
    [javac] location: class org.acm.seguin.summary.load.SwingLoadStatus
    [javac]            setAlwaysOnTop(true);
    [javac]            ^
    [javac] Note: Some input files use or override a deprecated API.
    [javac] Note: Recompile with -deprecation for details.
    [javac] 1 errorDid something change underneath you, or is this
internal?regardsAdam

[Jrefactory-developers] jrefactory building again on gump

[<an...@an...>]

Thanks JRefactoriers, particularly Mike concerning the changes you have 
committed
which make jrefactory build again on Gump.

I am wondering whether JRe...@la... is in fact the 
same as jre...@li....

I have also noticed that your mail list does not seem to be archived any 
where, and I am not getting what I am sending to your list,
even though I am subscribed to it,.

Cheers,

Antoine

[1] cvs update : 
http://lsd.student.utwente.nl/gump/jrefactory/gump_work/update_jrefactory.html
[2] project results 
http://lsd.student.utwente.nl/gump/jrefactory/jrefactory.html

[Jrefactory-developers] build of jrefactory

[<an...@an...>]

Hi Jrefactoriers,

I am not sure whether you are aware of it : your project is built with gump,
or more exactly gump tries to build it.

See this URL :

http://lsd.student.utwente.nl/gump/jrefactory/jrefactory.html

/data3/gump/jrefactory/src/org/acm/seguin/pmd/jaxen/DocumentNavigator.java:193: 
parseXPath(java.lang.String) in 
org.acm.seguin.pmd.jaxen.DocumentNavigator cannot implement 
parseXPath(java.lang.String) in org.jaxen.Navigator; overridden method 
does not throw org.saxpath.SAXPathException
   [javac]     public XPath parseXPath(String arg0) throws 
SAXPathException {
   [javac]                  ^
   [javac] Note: Some input files use or override a deprecated API.
   [javac] Note: Recompile with -deprecation for details.
   [javac] 1 error

BUILD FAILED
/data3/gump/jrefactory/build.xml:371: Compile failed; see the compiler 
error output for details.
    at org.apache.tools.ant.taskdefs.Javac.compile(Javac.java:938)
    at org.apache.tools.ant.taskdefs.Javac.execute(Javac.java:758)


Saxpath has been integrated into jaxen, and I guess that 
org.jaxen.Navigator API has changed.

Can you adapt to all these changes.

Also gump has a feature called "nagging". nagging means that an 
automatic email gets sent when your project fails to build.

Can I set up gump to nag you ?

Thanks in advance, and cheers from Walldorf.

Antoine

[Jrefactory-developers] More problems building from CVS

[Robert C. <rob...@or...>]

Any ideas?  It looks like AbstractTextNodeViewer is missing.

-- Rob

[Ant log]

D:\projects\JRefactory>ant
Buildfile: build.xml

optional_packages:
Java2D Direct3D usage disabled by J2D_D3D env

prepare:

make.version:
     [echo] D:\projects\JRefactory/src
     [java] D:\projects\JRefactory/src/org/acm/seguin/JRefactoryVersion.java
     [java]
op=D:\projects\JRefactory\src\org\acm\seguin\JRefactoryVersion.java

compile:
    [javac] Compiling 30 source files to
D:\projects\JRefactory\ant.build\classe
s
    [javac]
D:\projects\JRefactory\src\org\acm\seguin\ide\jbuilder\JRefactory.ja
va:76: org.acm.seguin.ide.jbuilder.JRefactory is not abstract and does not
overr
ide abstract method getFile(java.awt.Frame,java.lang.Object) in
org.acm.seguin.i
de.common.IDEInterface
    [javac] public class JRefactory extends JPanel implements IDEInterface {
    [javac]        ^
    [javac]
D:\projects\JRefactory\src\org\acm\seguin\ide\jbuilder\JRefactory.ja
va:911: cannot resolve symbol
    [javac] symbol  : class AbstractTextNodeViewer
    [javac] location: class org.acm.seguin.ide.jbuilder.JRefactory
    [javac]         AbstractTextNodeViewer sourceViewer =
    [javac]         ^
    [javac]
D:\projects\JRefactory\src\org\acm\seguin\ide\jbuilder\JRefactory.ja
va:912: cannot resolve symbol
    [javac] symbol  : class AbstractTextNodeViewer
    [javac] location: class org.acm.seguin.ide.jbuilder.JRefactory
    [javac]                 (AbstractTextNodeViewer)
browser.getViewerOfType(act
ive, AbstractTextNodeViewer.class);
    [javac]                  ^
    [javac]
D:\projects\JRefactory\src\org\acm\seguin\ide\jbuilder\JRefactory.ja
va:912: cannot resolve symbol
    [javac] symbol  : class AbstractTextNodeViewer
    [javac] location: class org.acm.seguin.ide.jbuilder.JRefactory
    [javac]                 (AbstractTextNodeViewer)
browser.getViewerOfType(act
ive, AbstractTextNodeViewer.class);
    [javac]
     ^
    [javac]
D:\projects\JRefactory\src\org\acm\seguin\ide\jbuilder\JRefactory.ja
va:913: cannot resolve symbol
    [javac] symbol  : class EditorPane
    [javac] location: class org.acm.seguin.ide.jbuilder.JRefactory
    [javac]         EditorPane editor = sourceViewer.getEditor();
    [javac]         ^
    [javac]
D:\projects\JRefactory\src\org\acm\seguin\ide\jbuilder\JRefactory.ja
va:914: cannot resolve symbol
    [javac] symbol  : variable EditorPane
    [javac] location: class org.acm.seguin.ide.jbuilder.JRefactory
    [javac]         editor.gotoPosition(value, 1, false,
EditorPane.CENTER_ALWAY
S);
    [javac]                                              ^
    [javac]
D:\projects\JRefactory\src\org\acm\seguin\ide\jbuilder\JRefactory.ja
va:927: cannot resolve symbol
    [javac] symbol  : class ReadOnlyException
    [javac] location: class org.acm.seguin.ide.jbuilder.JRefactory
    [javac]             } catch (ReadOnlyException roe) {
    [javac]                      ^
    [javac]
D:\projects\JRefactory\src\org\acm\seguin\ide\jbuilder\JRefactory.ja
va:955: inconvertible types
    [javac] found   : com.borland.primetime.vfs.Buffer
    [javac] required: com.borland.primetime.node.Node
    [javac]         Node active = (Node)buffer;
    [javac]                             ^
    [javac]
D:\projects\JRefactory\src\org\acm\seguin\ide\jbuilder\JRefactory.ja
va:972: inconvertible types
    [javac] found   : com.borland.primetime.vfs.Buffer
    [javac] required: com.borland.primetime.node.Node
    [javac]         Node active = (Node)buffer;
    [javac]                             ^
    [javac]
D:\projects\JRefactory\src\org\acm\seguin\ide\jbuilder\JRefactory.ja
va:977: cannot resolve symbol
    [javac] symbol  : class AbstractTextNodeViewer
    [javac] location: class org.acm.seguin.ide.jbuilder.JRefactory
    [javac]         AbstractTextNodeViewer sourceViewer =
    [javac]         ^
    [javac]
D:\projects\JRefactory\src\org\acm\seguin\ide\jbuilder\JRefactory.ja
va:978: cannot resolve symbol
    [javac] symbol  : class AbstractTextNodeViewer
    [javac] location: class org.acm.seguin.ide.jbuilder.JRefactory
    [javac]                 (AbstractTextNodeViewer)
((Browser)view).getViewerOf
Type(active, AbstractTextNodeViewer.class);
    [javac]                  ^
    [javac]
D:\projects\JRefactory\src\org\acm\seguin\ide\jbuilder\JRefactory.ja
va:978: cannot resolve symbol
    [javac] symbol  : class AbstractTextNodeViewer
    [javac] location: class org.acm.seguin.ide.jbuilder.JRefactory
    [javac]                 (AbstractTextNodeViewer)
((Browser)view).getViewerOf
Type(active, AbstractTextNodeViewer.class);
    [javac]
             ^
    [javac]
D:\projects\JRefactory\src\org\acm\seguin\ide\jbuilder\JRefactory.ja
va:983: cannot resolve symbol
    [javac] symbol  : class EditorPane
    [javac] location: class org.acm.seguin.ide.jbuilder.JRefactory
    [javac]         EditorPane editor = sourceViewer.getEditor();
    [javac]         ^
    [javac]
D:\projects\JRefactory\src\org\acm\seguin\ide\jbuilder\JRefactory.ja
va:999: cannot resolve symbol
    [javac] symbol  : class AbstractTextNodeViewer
    [javac] location: class org.acm.seguin.ide.jbuilder.JRefactory
    [javac]         AbstractTextNodeViewer sourceViewer =
    [javac]         ^
    [javac]
D:\projects\JRefactory\src\org\acm\seguin\ide\jbuilder\JRefactory.ja
va:1000: cannot resolve symbol
    [javac] symbol  : class AbstractTextNodeViewer
    [javac] location: class org.acm.seguin.ide.jbuilder.JRefactory
    [javac]                 (AbstractTextNodeViewer)
((Browser)view).getViewerOf
Type((Node)buffer, AbstractTextNodeViewer.class);
    [javac]                  ^
    [javac]
D:\projects\JRefactory\src\org\acm\seguin\ide\jbuilder\JRefactory.ja
va:1000: cannot resolve symbol
    [javac] symbol  : class AbstractTextNodeViewer
    [javac] location: class org.acm.seguin.ide.jbuilder.JRefactory
    [javac]                 (AbstractTextNodeViewer)
((Browser)view).getViewerOf
Type((Node)buffer, AbstractTextNodeViewer.class);
    [javac]
                   ^
    [javac]
D:\projects\JRefactory\src\org\acm\seguin\ide\jbuilder\JRefactory.ja
va:1001: cannot resolve symbol
    [javac] symbol  : class EditorPane
    [javac] location: class org.acm.seguin.ide.jbuilder.JRefactory
    [javac]         EditorPane editor = sourceViewer.getEditor();
    [javac]         ^
    [javac]
D:\projects\JRefactory\src\org\acm\seguin\ide\jbuilder\JRefactory.ja
va:1012: cannot resolve symbol
    [javac] symbol  : class JavaFileNode
    [javac] location: class org.acm.seguin.ide.jbuilder.JRefactory
    [javac]         return (buffer instanceof JavaFileNode);
    [javac]                                   ^
    [javac]
D:\projects\JRefactory\src\org\acm\seguin\ide\standalone\JRefactory.
java:75: org.acm.seguin.ide.standalone.JRefactory is not abstract and does
not o
verride abstract method getFile(java.awt.Frame,java.lang.Object) in
org.acm.segu
in.ide.common.IDEInterface
    [javac] public class JRefactory extends JPanel implements IDEInterface {
    [javac]        ^
    [javac] 19 errors

BUILD FAILED
file:D:/projects/JRefactory/build.xml:372: Compile failed; see the compiler
erro
r output for details.

[Jrefactory-developers] Problems building from CVS

[Robert C. <rob...@or...>]

Any ideas: Here's the error I'm getting.

Thanks,

Rob


----------------------------------------------------------------------------
----------

Buildfile: build.xml

make.version:
     [echo] D:\projects\JRefactory/src
     [java] D:\projects\JRefactory/src/org/acm/seguin/JRefactoryVersion.java
     [java]
op=D:\projects\JRefactory\src\org\acm\seguin\JRefactoryVersion.java

compile:
    [javac] Compiling 703 source files to
D:\projects\JRefactory\ant.build\classes
    [javac]
D:\projects\JRefactory\src\org\acm\seguin\parser\ast\AccessNode.java:622:
isJavaDocRequired(java.lang.String,net.sourceforge.jrefactory.ast.ModifierHo
lder) in org.acm.seguin.pretty.ForceJavadocComments cannot be applied to
(java.lang.String,org.acm.seguin.parser.ast.AccessNode)
    [javac]         return fjc.isJavaDocRequired(type, this);
    [javac]                   ^
    [javac]
D:\projects\JRefactory\src\org\acm\seguin\parser\ast\ASTMethodDeclaration.ja
va:117: cannot resolve symbol
    [javac] symbol  : constructor MethodAnalyzer
(org.acm.seguin.parser.ast.ASTMethodDeclaration,org.acm.seguin.pretty.JavaDo
cableImpl)
    [javac] location: class org.acm.seguin.pretty.ai.MethodAnalyzer
    [javac]             MethodAnalyzer ai = new MethodAnalyzer(this, jdi);
    [javac]                                     ^
    [javac] 2 errors

BUILD FAILED
file:D:/projects/JRefactory/build.xml:372: Compile failed; see the compiler
error output for details.

[Jrefactory-developers] JRefactory 2.7.04

[Mike A. <Mi...@la...>]

Announcing:

A new version of JRefactory that mainly enhances the UML diagrams, 
though there are several other minor fixes, for a full list of the 
changes set the release notes: 
(http://www.ladyshot.demon.co.uk/releasenotes.html).

[Source code]
http://www.ladyshot.demon.co.uk/jrefactory-2.7.04-code.zip

[Binary]
http://www.ladyshot.demon.co.uk/jrefactory-2.7.04-binary.zip

I now have developer access to the JRefactory SourceForge CVS repository 
(thanks Chris), so future releases will be via SourceForge.

--
Mike Atkinson

[Jrefactory-developers] JRefactory 2.7.03

[Mike A. <Mi...@la...>]

Announcing:

A new version of JRefactory (used by JavaStyle) that fixes some bugs and 
now parses the JDK 1.5 new language features correctly (I think!). A 
full list of changes is available in the release note 
(http://www.ladyshot.demon.co.uk/csr-releasenotes.html).

[Source code]
http://www.ladyshot.demon.co.uk/jrefactory-2.7.03-code.zip

[Binary]
http://www.ladyshot.demon.co.uk/jrefactory-2.7.03-binary.zip

I believe I have fixed all reported bugs in the pretty printing part of 
JRefactory, if you know of any more please report them.

[I have tried to contact Chris Seguin in various ways, but so far 
without success (if you see this Chris please contact me). My changes 
are at present under 5% of the total. ]

[Jrefactory-developers] new version of JRefactory

[Mike A. <Mi...@la...>]

I have updated JRefactory to prettyprint generics (variance is 
implemented), enums, static imports, new style loops and attributes. As 
Variance is experimental, and the way attributes will be implemented has 
not been released yet, both these features must be considered 
EXPERIMENTAL. Luckily I could add them to the pretty printer without 
messing up any other feature.

            -------------------------------

Also fixed a few bugs:
JRefactory bugs:
    574070 Error pretty print (EOF on comment)
    583264 else.start.line bug
    605626 Pretty break code by removing wrong {}
    616419 Selective word wrap for JavaDoc
    641473 PrettyPrinter adds @param in wrong place
    679496 PP removes spaces in HTML in JavaDoc.
    693745 Array initializer indent carries over to rest of code.
    703771 static public/private initializations create compiler error
    722293 surprise.return=param is broken (think this
           is fixed but have no test case)

JEdit bugs:
    549394 JavaStyle Neverending Work
    551481 JavaStyle javadoc comment error
    570143 JavaStyle wrong indentation
    692442 JavaStyle doesn't space out "switch" keyword properly
    728002 JavaStyle Doesn't handle // comments inside /* */

There is one JRefactory pretty printing bug left:
    693738 Header re-inserted when imports re-ordered, I've
           partly fixed it.
/*
* header
*/
import java.util.*;
import java.sql.*;

becomes after prett yprinting:

import java.sql.*;
/*
* header
*/
import java.util.*;

It is not obvious that this is a bug (should the header stay with the 
java.util import or should it stay at the top of the list of imports?), 
or how to fix it.

            -------------------------------

The new JRefactory can be found at 
http://www.ladyshot.demon.co.uk/jrefactory-2.7.01.zip and the files 
modified from JRefactory 2.6.40 at 
http://www.ladyshot.demon.co.uk/files-2.7.01.zip

For JEdit users jrefactory.jar may be placed in the .jEdit/jars 
directory (rename the original one first) and you can then pretty print 
the new JDK 1.5 language features, for example:

            -------------------------------

Example class using enums and generics:

public class Test3 {

    public enum Quarks { up, down, top, bottom, charm, strange }

    public enum Coin {
        penny(1), nickel(5), dime(10), quarter(25);
          Coin(int value) { this.value = value; }
          private final int value;
          public int value() { return value; }
    }

    public class CoinTest {
        public void CoinTest() {
            X:  // fixed ":" after labels
            for (Iterator<Coin> i = Coin.VALUES.iterator(); i.hasNext(); ) {
                Coin c = i.next();
                System.out.println(c + ": \t"+ c.value() +"c \t" + 
color(c));
            }
        }
          private enum CoinColor { copper, nickel, silver }
          private static CoinColor color(Coin c) {
            if (c == null)
                throw new NullPointerException();
              switch(c) {
              case Coin.penny:
                return CoinColor.copper;
              case Coin.nickel:
                return CoinColor.nickel;
              case Coin.dime:
                return CoinColor.silver;
              case Coin.quarter:
                return CoinColor.silver;
            }
              throw new AssertionError("Unknown coin: " + c);
        }
    }
      public static void bar(Object[] x) {
        for (Object o : x) {
            System.out.println(o);
        }
    }


    public static void main(String[] argv) {
        CoinTest();
        bar( 1,"a",'z');
    }

}

            -------------------------------

Mike Atkinson

[Jrefactory-developers] [Fwd: Maven/Checkstyle and JRefactory and source properties]

[Jason v. Z. <ja...@ze...>]

-- 
jvz.

Jason van Zyl
ja...@ap...
http://tambora.zenplex.org

In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
  
  -- Jacques Ellul, The Technological Society

[Jrefactory-developers] Prety Print & modifier order

[Jesse S. <je...@cr...>]

The current implementation of JRefactory sorts the modifier keywords in
an order that is inconsistent with the recommendations in the JLS


<!-- Snip --> 
http://java.sun.com/docs/books/jls/second_edition/html/classes.doc.html#21613

ClassModifier: one of public protected private
		 abstract static final strictfp


 If two or more class modifiers appear in a class declaration, then it
is customary, though not required, that they appear in the order
consistent with that shown above in the production for ClassModifier
<!-- snip -->

I have logged this as bug #527036

I have modified the toString() method in
org.acm.seguin.pretty.ModifierHolder so that I get the correct order.
There are 3 keywords that I can't account for:

Explicit
Interface
Strict 

I'm pretty sure Interface can be removed, I have tested my changes on
source with interface declarations & it works fine without it. What
about the other keywords, I can't find a reference to them in the JLS
(or anywhere else for that matter).

I will send a patch as soon as I get an answer about the other keywords.


-- 
 Jesse Stockall			|	Tel: 1+ 613.599.2441 ext. 243
 CRYPTOCard Corporation		|	Fax: 1+ 613.599.2442	 	
 Suite 304, 300 March Rd.	|	email: je...@cr...
 Ottawa, ON, Canada K2K 2E2	|	web: www.cryptocard.com 
---------------------------------------------------------------------

[Jrefactory-developers] Enhancement discussion: Pretty Printer support for comments for blocks of constants

[Carsten H. <ca...@pi...>]

Hi Developers,

I like jrefactory and took the challenge to dig into the code to add
some pieces :-)
I'm currently trying to add support for one comment in front of a bulk
of constant java definitions.
Background: When dealing with external software or defintions of file
formats etc.
i't common to have a bulk of constants which must be defined in the java
language.
The documention of the constants can in most cases being reduced to
something like


/**
   * lot's of constants according to spec XY
    */
public final static int ....
public final static String ...
etc.

So I would like them to stay that way when applying the pretty printer.
I did some programming in the pretty printer and have only one piece
missing:

The position of statements is not stored in the tree, so I would like
to generate a new JavaParser via JavaCC to add some specials ("startPos"
or "startToken"
and "endPos" or "endToken" to the FieldDeclaration rule to check for
immediately following constant field definitions.

Is there a better way? (What purpose have the specials like "semicolon"
which are
always null for me???)
I should I deal with the changes, should I send them to this list, or to
the bug tracking
as I did a few minuts ago?

Ciao,
    Carsten (alph)

--
  Carsten Heyl                          ca...@pi...
  Pixelboxx GmbH                        http://www.pixelboxx.de/
  Ostenhellweg 56-58                    Tel.:   +49 231 53 46 30
D-44135 Dortmund                        Mobile: +49 174 31 83 608

[Jrefactory-developers] Enhancement discussion: Pretty Printer support for comments for blocks of constants

[Carsten H. <ca...@pi...>]

Hi Developers,

I like jrefactory and took the challenge to dig into the code to add
some pieces :-)
I'm currently trying to add support for one comment in front of a bulk
of constant java definitions.
Background: When dealing with external software or defintions of file
formats etc.
i't common to have a bulk of constants which must be defined in the java
language.
The documention of the constants can in most cases being reduced to
something like


/**
   * lot's of constants according to spec XY
    */
public final static int ....
public final static String ...
etc.

So I would like them to stay that way when applying the pretty printer.
I did some programming in the pretty printer and have only one piece
missing:

The position of statements is not stored in the tree, so I would like
to generate a new JavaParser via JavaCC to add some specials ("startPos"
or "startToken"
and "endPos" or "endToken" to the FieldDeclaration rule to check for
immediately following constant field definitions.

Is there a better way? (What purpose have the specials like "semicolon"
which are
always null for me???)
I should I deal with the changes, should I send them to this list, or to
the bug tracking
as I did a few minuts ago?

Ciao,
    Carsten (alph)

--
  Carsten Heyl                          ca...@pi...
  Pixelboxx GmbH                        http://www.pixelboxx.de/
  Ostenhellweg 56-58                    Tel.:   +49 231 53 46 30
D-44135 Dortmund                        Mobile: +49 174 31 83 608

[Jrefactory-developers] jrefayctory v. 2.6.31 - problems with command line interface

[Klemme, R. m. <rob...@my...>]

hi chris,

i installed the current version and noticed this: the behavior of the
command-line version changed significantly and - i'm afraid -
inconsistently.  when invoking with a single file name given, the =
output is
sent to the console instead of into the file.  moreover, when giving
multiple file names only the first one is processed at all.  if =
provided
with a directory name, the files are changed themselves like before.  =
when
setting the property "pretty.printer.backup.ext" to some value and then
invoking with file names then there is a backup file which is identical =
to
the original - which is pretty much useless in the case that the =
original
was not modified.  :-)  and i could not find any documentation in the
commandline.txt...

i'm sorry, that i am coming along with such a long list, but maybe =
there is
single cause for this, which may be easily fixed.

regards

	robert


--=20
Robert Klemme
software engineer
------------------------------------------------------------------------=
----
----
myview technologies GmbH & Co. KG
Riemekestra=DFe 160 ~ 33106 Paderborn ~ Germany
www.myview.de mailto:rob...@my...
Fon: +49-5251-69090-321 Fax: +49-5251-69090-399
------------------------------------------------------------------------=
----
----
The information transmitted is only intended for the person or entity =
to
which
it is adressed. It may contain confidential and/or privileged material. =
Any
review, forwarding, distribution or any other action related to this
information
by persons or entities other  than the intended addressee is =
prohibited. If
you
receive this by mistake, please contact the addresser and delete the
material
from any computer.

[Jrefactory-developers] [PATCH] infloop in VariableSummary.queryFieldSummary

[Paul K. <pau...@me...>]

I think I found a bug.  The while loop never updates currentType, and so
never terminates.  My best guess at the intended behavior is to climb the
inheritence heirarchy looking for the field.  A fix is attached, although
I'm not sure how well this fares in the case of multiple inheritence.

PFK

[Jrefactory-developers] [PATCH supercede] invalid manifest [was: Missing files]

[Paul K. <pau...@me...>]

Oops.  I put the section break in the wrong place.  Please disreagard the
previous patch.

[Jrefactory-developers] [PATCH] invalid manifest [was: Missing files]

[Paul K. <pau...@me...>]

> Oops.  They should be there now.

Thanks for that.  I understand about vacations.

I can now compile, but when ant tries to jar, it fails with

jar:
Manifest is invalid: The attribute "Created-By" may not occur more than once
in the same section

BUILD FAILED

Invalid Manifest: C:\src\jrefactory\src\meta-inf\refactory.mf

I didn't have this problem last time I built, but I've since upgraded ant
from 1.3 to 1.4.

The problem seems to be that the Netbeans section of refactory.mf has no
Name attribute to mark the beginning of the section, so that everything up
to "Name: org.acm.seguin.ide.cafe.CafeSetup" is considered to be part of the
main section.

The attached patch solves the problem.

[Jrefactory-developers] Missing files

[Chris S. <chr...@ya...>]

Oops.  They should be there now.

Sorry for the delay.  I went on vacation last week,
and I'm just now catching up on my e-mail.

Chris

__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/

[Jrefactory-developers] missing files in CVS

[Paul K. <pau...@me...>]

I can't compile CVS because org.acm.seguin.pretty.sort.MultipleOrdering is
referencing two classes that haven't been checked in: FinalOrder and
AlphabeticalOrder.

RE: [Jrefactory-developers] Structure for TopLevelOrdering

[<ze...@te...>]

OK, I'll send you list of changes.
I will make other requests for import features, too.

> Hi,
> 
> If it were me, I would create two subclasses.  One for
> alphabetical sorting of import statements and one for
> the import grouping sorter that you are proposing. 
> I'd use JRefactory to push down the behavior that is
> different into the alphabetical top level ordering.
> 
> Then for the import grouping top level sorter, I'd
> pass in the arguments that control the sort.
> 
> Then I would make PrintData have a factory method to
> create either an alphabetical top level sort or an
> import group top level sort.  PrintData would have
> variables in it that would be loaded by default from
> the pretty.settings file.  These would be set up in
> the PrintData(OutputStream) constructor.  I'd also add
> a method to override those variables, so that they
> could be unit tested.
> 
> Finally, I'd add a method in
> org.acm.seguin.pretty.TestPrettyPrintFile to store
> those variables and pass them through to the PrintData
> object.
> 
> And of course I'd add some unit tests into
> TestPrettyPrinter.java.
> 
> At least, that is how I would do it.
> 
> 

[Jrefactory-developers] Structure for TopLevelOrdering

[Chris S. <chr...@ya...>]

Hi,

If it were me, I would create two subclasses.  One for
alphabetical sorting of import statements and one for
the import grouping sorter that you are proposing. 
I'd use JRefactory to push down the behavior that is
different into the alphabetical top level ordering.

Then for the import grouping top level sorter, I'd
pass in the arguments that control the sort.

Then I would make PrintData have a factory method to
create either an alphabetical top level sort or an
import group top level sort.  PrintData would have
variables in it that would be loaded by default from
the pretty.settings file.  These would be set up in
the PrintData(OutputStream) constructor.  I'd also add
a method to override those variables, so that they
could be unit tested.

Finally, I'd add a method in
org.acm.seguin.pretty.TestPrettyPrintFile to store
those variables and pass them through to the PrintData
object.

And of course I'd add some unit tests into
TestPrettyPrinter.java.

At least, that is how I would do it.

Chris

__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/

[Jrefactory-developers] Re: Ideas for JRefactory

[Zeljko T. <ze...@te...>]

Hi,

I have some questions how to implement this in the spirit of the rest of the project:

What's the best way to get property data inside TopLevelOrdering? Should I get it with
FileSettings pretty = FileSettings.getSettings("Refactory", "pretty");

What's the best way to current class name inside TopLevelOrdering? Should I pass it to constructor? How can I get it, from parse tree?

Thanks!

I sent a copy to developer list, maybe that's the better place to continue discussion.

> I
>> made one of the changes - smart import sort, but I
>> need some info from you to finish it. I need name of
>> the processed class in
>> org.acm.seguin.pretty.sort.TopLevelOrdering. What's
>> the best way to pass it there?
>
>I've been putting the values like that in the
>pretty.settings file.  Then I have the
>org.acm.seguin.pretty.PrintData object read the values
>from there.
>
>By placing them in the file, I get the default
>behavior.  By getting them from PrintData, it allows
>me to unit test the feature because I can override the
>defaults from pretty.settings.
>
>> I also need following properties in configuration
>> file. Please let me know are names O.K.
>> 
>> Packages that come in front. User may select which
>> packages will come first. Default is java and javax.
>> import.sort.important = java, javax
>> 
>> Should we put classes in the same tree on the end?
>> Number represents minimum number of package levels
>> representing "neighborhood" node. 2 means that
>> org.apache doesn't represent friendly package (only
>> one match, "org"), but everything starting with
>> org.seguin does.
>> import.sort.neighborhood=2
>> 
>> Example (our class is
>> org.seguin.pkg2.subpkg.MyClass):
>> 
>> import java.util.Vector;                            
>>    // java comes first, alphabetically sorted
>> import java.sql.SqlException;
>> import javax.servlet.Request;                   //
>> javax comes second. End of "important" packages.
>> 
>> import hr.aeris.Data;                           //
>> all other packages
>> import org.apache.Something;                    
>> import uk.watcom.SomeClass;
>> 
>> import org.seguin.pkg1.SomeClass;               //
>> Neighborhood. This import matches 2 levels
>> ("org.seguin")
>> import org.seguin.pkg2.SomeOtherClass;          //
>> This import matches 3 levels ("org.seguin.pkg2")
>> 
>> If we set neighborhood to 1:
>> 
>> import java.util.Vector;                            
>>    // java comes first, alphabetically sorted
>> import java.sql.SqlException;
>> import javax.servlet.Request;                   //
>> javax comes second. End of "important" packages.
>> 
>> import hr.aeris.Data;                           //
>> all other packages
>> import uk.watcom.SomeClass;
>> 
>> import org.apache.Something;                    //
>> all orgs represent neighborhood
>> import org.seguin.pkg1.SomeClass;               
>> import org.seguin.pkg2.SomeOtherClass;          
>> 
>> If we remove "important":
>> 
>> import hr.aeris.Data;                           //
>> all other packages
>> import java.util.Vector;                            
>>    
>> import java.sql.SqlException;
>> import javax.servlet.Request;                   
>> import uk.watcom.SomeClass;                     
>> 
>> import org.apache.Something;                    //
>> all orgs represent neighborhood
>> import org.seguin.pkg1.SomeClass;               
>> import org.seguin.pkg2.SomeOtherClass;          
>> 
>> Plain sort:
>> 
>> import hr.aeris.Data;
>> import java.util.Vector;                            
>>    
>> import java.sql.SqlException;
>> import javax.servlet.Request;                   
>> import org.apache.Something;
>> import org.seguin.pkg1.SomeClass;               
>> import org.seguin.pkg2.SomeOtherClass;          
>> import uk.watcom.SomeClass;                     
>
>This looks great.  I approve the names.  :-)  If you
>send me the code, I'll dump it into build 2.6.25.
>
>Thanks!!!!
>
>Chris


	Zeljko
____________________________________
"My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." 
- Indira Gandhi

[Jrefactory-developers] Re: Ideas for JRefactory

[Zeljko T. <ae...@os...>]

Hi,

I have some questions how to implement this in the spirit of the rest of the project:

What's the best way to get property data inside TopLevelOrdering? Should I get it with
FileSettings pretty = FileSettings.getSettings("Refactory", "pretty");

What's the best way to current class name inside TopLevelOrdering? Should I pass it to constructor? How can I get it, from parse tree?

Thanks!

I sent a copy to developer list, maybe that's the better place to continue discussion.

> I
>> made one of the changes - smart import sort, but I
>> need some info from you to finish it. I need name of
>> the processed class in
>> org.acm.seguin.pretty.sort.TopLevelOrdering. What's
>> the best way to pass it there?
>
>I've been putting the values like that in the
>pretty.settings file.  Then I have the
>org.acm.seguin.pretty.PrintData object read the values
>from there.
>
>By placing them in the file, I get the default
>behavior.  By getting them from PrintData, it allows
>me to unit test the feature because I can override the
>defaults from pretty.settings.
>
>> I also need following properties in configuration
>> file. Please let me know are names O.K.
>> 
>> Packages that come in front. User may select which
>> packages will come first. Default is java and javax.
>> import.sort.important = java, javax
>> 
>> Should we put classes in the same tree on the end?
>> Number represents minimum number of package levels
>> representing "neighborhood" node. 2 means that
>> org.apache doesn't represent friendly package (only
>> one match, "org"), but everything starting with
>> org.seguin does.
>> import.sort.neighborhood=2
>> 
>> Example (our class is
>> org.seguin.pkg2.subpkg.MyClass):
>> 
>> import java.util.Vector;                            
>>    // java comes first, alphabetically sorted
>> import java.sql.SqlException;
>> import javax.servlet.Request;                   //
>> javax comes second. End of "important" packages.
>> 
>> import hr.aeris.Data;                           //
>> all other packages
>> import org.apache.Something;                    
>> import uk.watcom.SomeClass;
>> 
>> import org.seguin.pkg1.SomeClass;               //
>> Neighborhood. This import matches 2 levels
>> ("org.seguin")
>> import org.seguin.pkg2.SomeOtherClass;          //
>> This import matches 3 levels ("org.seguin.pkg2")
>> 
>> If we set neighborhood to 1:
>> 
>> import java.util.Vector;                            
>>    // java comes first, alphabetically sorted
>> import java.sql.SqlException;
>> import javax.servlet.Request;                   //
>> javax comes second. End of "important" packages.
>> 
>> import hr.aeris.Data;                           //
>> all other packages
>> import uk.watcom.SomeClass;
>> 
>> import org.apache.Something;                    //
>> all orgs represent neighborhood
>> import org.seguin.pkg1.SomeClass;               
>> import org.seguin.pkg2.SomeOtherClass;          
>> 
>> If we remove "important":
>> 
>> import hr.aeris.Data;                           //
>> all other packages
>> import java.util.Vector;                            
>>    
>> import java.sql.SqlException;
>> import javax.servlet.Request;                   
>> import uk.watcom.SomeClass;                     
>> 
>> import org.apache.Something;                    //
>> all orgs represent neighborhood
>> import org.seguin.pkg1.SomeClass;               
>> import org.seguin.pkg2.SomeOtherClass;          
>> 
>> Plain sort:
>> 
>> import hr.aeris.Data;
>> import java.util.Vector;                            
>>    
>> import java.sql.SqlException;
>> import javax.servlet.Request;                   
>> import org.apache.Something;
>> import org.seguin.pkg1.SomeClass;               
>> import org.seguin.pkg2.SomeOtherClass;          
>> import uk.watcom.SomeClass;                     
>
>This looks great.  I approve the names.  :-)  If you
>send me the code, I'll dump it into build 2.6.25.
>
>Thanks!!!!
>
>Chris


	Zeljko
____________________________________
"My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." 
- Indira Gandhi