sorting imports
What is the proper customization to get imports sorted alphabetically with no grouping and no blank lines between imports? Currently I have: jde import auto sort t jde import auto sort function jde-import-sort jde import reverse sort group nil jde import sorted groups "alphabetic order" jde import group function jde-import-group-of jde import group of rules ^javax?\. jde import default group name none jde import insert group names none I was unable to find any documentation beyond the lisp help functions. Suggestions? Thanks, -- Robert
Excluding specific jars from classpath
Troy Daniels writes: > While answering a question about classpaths, > At 10:51 AM 4/3/2004 +0200, Petter Måhlén wrote: > > > >What you should do is something like this: > > > >1. M-x customize-variable RET jde-global-classpath RET > >2. Add the directories/jars that you want, one in each list entry (note that > >if you add a directory, JDE will pick up any jars in that directory > >automatically) > > Is there a way to exclude a particular jar when JDE does this? In our > project, we have a jars directory that contains all of the jars we > use. Our build script also creates a jar here with all the classes from > our project. I'd like to exclude that jar for several reasons. > > 1. Some of the classes in it might be out of date if I've compiled a file > in JDE without rerunning out build script. > 2. If the beanshell is running and the project jar is in it's classpath, > our build script fails because it's unable to delete the jar file, since > it's in use. This results in me repeatedly exiting and restarting the > beanshell. > > If this can't be done, I'll try to modify the appropriate function to add > it as an option. > Hi Troy, I don't think there is provision for excluding jar files. I encourage you to submit a patch to do this. Regards, Paul
Excluding specific jars from classpath
While answering a question about classpaths, At 10:51 AM 4/3/2004 +0200, Petter Måhlén wrote: What you should do is something like this: 1. M-x customize-variable RET jde-global-classpath RET 2. Add the directories/jars that you want, one in each list entry (note that if you add a directory, JDE will pick up any jars in that directory automatically) Is there a way to exclude a particular jar when JDE does this? In our project, we have a jars directory that contains all of the jars we use. Our build script also creates a jar here with all the classes from our project. I'd like to exclude that jar for several reasons. 1. Some of the classes in it might be out of date if I've compiled a file in JDE without rerunning out build script. 2. If the beanshell is running and the project jar is in it's classpath, our build script fails because it's unable to delete the jar file, since it's in use. This results in me repeatedly exiting and restarting the beanshell. If this can't be done, I'll try to modify the appropriate function to add it as an option. Troy Troy Daniels [EMAIL PROTECTED] 781-273-3388 x218
Re: Roadmap for Java 1.5 support ?
Hi, [...] >> AFAIK David (Ponce) has checked in a new wisent java-grammar which >> has full(!) Java 1.5 support - i do not know if this is contained >> in the released beta2 - It is :-) This grammar (still experimental) should fully parse Java 1.5 code. To use it in place of the "standard" semantic Java 1.4 grammar add this to your .emacs file: ;; Setup CEDET (load (expand-file-name "/common/cedet") nil t) [...] ;; Use the full Java 1.5 grammar to parse Java files (autoload 'wisent-java-default-setup "wisent-java" "Hook run to setup Semantic in `java-mode'." nil nil) Enjoy! David
Re: Roadmap for Java 1.5 support ?
Klaus,
Thanks for the advice, I'll try to draw the very latest version of
semantic package, and check again (I noticed a couple of other strange
behaviors).
I was just observing some end-user visible effect, something that any
ECB user could have observed on similar Java 1.5 code. This does not
mean that ECB is the "guilty" layer!!!
Bye
/Hervé
Berndl, Klaus wrote:
Hervé Bitteur wrote:
Klaus,
On the 2 following methods, I noticed an inconsistent behavior:
// First method
public void setVerticalLag (VerticalLag vLag)
{
this.vLag = vLag;
}
// Second method
public VerticalLag getVerticalLag ()
{
return vLag;
}
The former is correctly flagged as a public method (according to the
small icon in the hierarchical display), while the latter is flagged
as a package private method.
I just tried this with using your latest ECB version (2.23).
Of course, I can survive this ...
This is not a matter of ECB but its a matter of the semantic-package. ECB is
just an ontop-displayor for the parsing-results of the semantic-package.
if semantic supports parsing a grammar then ECB does it autom. too if semantic
doesn't it ECB doesn't ist too.
AFAIK David (Ponce) has checked in a new wisent java-grammar which has full(!)
Java 1.5 support - i do not know if this is contained in the released beta2 -
but at least when you use the newest CVS-cedet you should get it. You can ask
for this in the cedet-mailing-list!
Klaus
--
Email : [EMAIL PROTECTED]
Hervé BITTEUR Office : +33 1.34.03.01.12
EMEA IT Architect Mobile : +33 6.86.49.04.14
__ Fax: +33 1.34.03.03.06
/ __// / // \
_\_ \/ / // / / SUN Microsystems FRANCE
\___/\__//_/_/ 13, avenue Morane Saulnier
Microsystems 78142 Vélizy cedex France
RE: Roadmap for Java 1.5 support ?
Hervé Bitteur wrote:
> Klaus,
>
> On the 2 following methods, I noticed an inconsistent behavior:
>
> // First method
> public void setVerticalLag (VerticalLag vLag)
> {
> this.vLag = vLag;
> }
>
> // Second method
> public VerticalLag getVerticalLag ()
> {
> return vLag;
> }
>
> The former is correctly flagged as a public method (according to the
> small icon in the hierarchical display), while the latter is flagged
> as a package private method.
>
> I just tried this with using your latest ECB version (2.23).
>
> Of course, I can survive this ...
This is not a matter of ECB but its a matter of the semantic-package. ECB is
just an ontop-displayor for the parsing-results of the semantic-package.
if semantic supports parsing a grammar then ECB does it autom. too if semantic
doesn't it ECB doesn't ist too.
AFAIK David (Ponce) has checked in a new wisent java-grammar which has full(!)
Java 1.5 support - i do not know if this is contained in the released beta2 -
but at least when you use the newest CVS-cedet you should get it. You can ask
for this in the cedet-mailing-list!
Klaus
Re: Roadmap for Java 1.5 support ?
Klaus,
On the 2 following methods, I noticed an inconsistent behavior:
// First method
public void setVerticalLag (VerticalLag vLag)
{
this.vLag = vLag;
}
// Second method
public VerticalLag getVerticalLag ()
{
return vLag;
}
The former is correctly flagged as a public method (according to the
small icon in the hierarchical display), while the latter is flagged as
a package private method.
I just tried this with using your latest ECB version (2.23).
Of course, I can survive this ...
Bye,
/Hervé
Berndl, Klaus wrote:
Hervé Bitteur wrote:
Hello,
I've switched to Java 1.5 beta for more than one month now. I just
made the bare minimum in terms of modifications in JDEE lisp files,
since I'm not at all a Lisp expert.
I can keep on using JDEE as my favorite development environment, since
browsing, text editing, compiling, running, ant builds, ... are OK.
But of course I lack full support for:
- Syntax highlighting
- Jalopy formatting
- ECB
what is missed in ECB concerning supporting Java 1.5?
- (perhaps debug, but I don't use it with JDEE anyway)
Switching a whole Java application to Java 1.5, taking full advantage
of its new features such as generics, is not something you can easily
undo. So now I'm on the 1.5 side and I stay there :-)
My question is thus about your roadmap for upgrading this nice
environment to a full support of Java 1.5.
ECB and JDEE are independent from each other
Klaus
--
Email : [EMAIL PROTECTED]
Hervé BITTEUR Office : +33 1.34.03.01.12
EMEA IT Architect Mobile : +33 6.86.49.04.14
__ Fax: +33 1.34.03.03.06
/ __// / // \
_\_ \/ / // / / SUN Microsystems FRANCE
\___/\__//_/_/ 13, avenue Morane Saulnier
Microsystems 78142 Vélizy cedex France
RE: Roadmap for Java 1.5 support ?
Hervé Bitteur wrote: > Hello, > > I've switched to Java 1.5 beta for more than one month now. I just > made the bare minimum in terms of modifications in JDEE lisp files, > since I'm not at all a Lisp expert. > > I can keep on using JDEE as my favorite development environment, since > browsing, text editing, compiling, running, ant builds, ... are OK. > > But of course I lack full support for: > - Syntax highlighting > - Jalopy formatting > - ECB what is missed in ECB concerning supporting Java 1.5? > - (perhaps debug, but I don't use it with JDEE anyway) > > Switching a whole Java application to Java 1.5, taking full advantage > of its new features such as generics, is not something you can easily > undo. So now I'm on the 1.5 side and I stay there :-) > > My question is thus about your roadmap for upgrading this nice > environment to a full support of Java 1.5. ECB and JDEE are independent from each other Klaus
Roadmap for Java 1.5 support ?
Hello,
I've switched to Java 1.5 beta for more than one month now. I just made
the bare minimum in terms of modifications in JDEE lisp files, since I'm
not at all a Lisp expert.
I can keep on using JDEE as my favorite development environment, since
browsing, text editing, compiling, running, ant builds, ... are OK.
But of course I lack full support for:
- Syntax highlighting
- Jalopy formatting
- ECB
- (perhaps debug, but I don't use it with JDEE anyway)
Switching a whole Java application to Java 1.5, taking full advantage of
its new features such as generics, is not something you can easily undo.
So now I'm on the 1.5 side and I stay there :-)
My question is thus about your roadmap for upgrading this nice
environment to a full support of Java 1.5.
Thanks for any info,
/Hervé
--
Email : [EMAIL PROTECTED]
Hervé BITTEUR Office : +33 1.34.03.01.12
EMEA IT Architect Mobile : +33 6.86.49.04.14
__ Fax: +33 1.34.03.03.06
/ __// / // \
_\_ \/ / // / / SUN Microsystems FRANCE
\___/\__//_/_/ 13, avenue Morane Saulnier
Microsystems 78142 Vélizy cedex France
