Can't correct the type of a variable after a refactor

[RMMM]

I'm new to NetBeans and I've been taken by surprise by the rather frequent bugs
I've run into. For instance, ...

I did some refactoring operations in NetBeans to change the package of some class files.
After I did this, NetBeans left one variable with an incorrect type that refers to the
old package name. It is:

private java.util.List<com.newvyy.yeladmins.Users> list;

com.newvyy.yeladmins is wrong here. That's the old package name. Since this is in a
class file inside the new package and Users resides in the same package, this should
just be:

private java.util.List<Users> list;

However, NetBeans won't let me edit this. In fact, nothing I've tried has allowed me
to correct this. Nor will NetBeans undo the package change refactor.

Should I just open the file in a text editor and fix it outside of the NetBeans environment?

[Peter B. West]

RMMM wrote:

> I'm new to NetBeans and I've been taken by surprise by the rather frequent
> bugs
> I've run into. For instance, ...
>
> I did some refactoring operations in NetBeans to change the package of some
> class files.
> After I did this, NetBeans left one variable with an incorrect type that
> refers to the
> old package name. It is:
>
> private java.util.List<com.newvyy.yeladmins.Users> list;
>
> com.newvyy.yeladmins is wrong here. That's the old package name. Since this
> is in a
> class file inside the new package and Users resides in the same package,
> this should
> just be:
>
> private java.util.List<Users> list;
>
> However, NetBeans won't let me edit this. In fact, nothing I've tried has
> allowed me
> to correct this. Nor will NetBeans undo the package change refactor.
>
> Should I just open the file in a text editor and fix it outside of the
> NetBeans environment?
>

I'm puzzled by "won't let me edit this." Is it within the guarded area
of a Matisse GUI project?

--
Peter B. West <http://cv.pbw.id.au/>
Folio <http://defoe.sourceforge.net/folio/>

[RMMM]

Peter B. West wrote:

I'm puzzled by "won't let me edit this." Is it within the guarded area
of a Matisse GUI project?

It's generated code in an ordinary java code pane, in a gray area.
NetBeans generated this code, but the problem is that it generated
the wrong code.

[Peter B. West]

RMMM wrote:

>
> Peter B. West wrote:
>>
>> I'm puzzled by "won't let me edit this." Is it within the guarded area
>> of a Matisse GUI project?
>>
>>
>
> It's generated code in an ordinary java code pane, in a gray area.
> NetBeans generated this code, but the problem is that it generated
> the wrong code.

You can change the value outside NB, but if its a guarded block, it may
cause other problems. What did you do to get NB to generate the code.
Got a screen shot of the code in the editor?

--
Peter B. West <http://cv.pbw.id.au/>
Folio <http://defoe.sourceforge.net/folio/>

[RMMM]

Peter B. West wrote:

You can change the value outside NB, but if its a guarded block, it may
cause other problems. What did you do to get NB to generate the code.
Got a screen shot of the code in the editor?

I visited the class files I wanted to move to the new package one by one. In each such
class file, I right clicked on the canvas, and chose Refactor > Move... from the pop up menu.
Then in the resulting "Move class" dialog, I specified the new package name. After
I was done doing this, the project wouldn't build. There were a number of errors that
NB introduced in this process. I was able to fix all of them except this one.

At this point, I'm torn about whether it's worth continuing with NB. Granted, I was able
to create the initial project in a few minutes that probably would have taken hours
by hand. And Granted, I've just started, so I might not yet have the hang of this. But
the frequency of bugs in NB has taken me by surprise, and I find it very worrisome that
I could end up at some critical moment in a project with a situation where NB introduces
some show stopping error in the code and stubbornly refuses to let me fix it.

I can see the potential for a lot of productivity gains from NB, but the immaturity worries
me. How do most NB users deal with this level of unreliability in a tool that's so crucial to
their work?

[Peter B. West]

RMMM wrote:

>
> I visited the class files I wanted to move to the new package one by one. In
> each such
> class file, I right clicked on the canvas, and chose Refactor > Move... from
> the pop up menu.
> Then in the resulting "Move class" dialog, I specified the new package name.
> After
> I was done doing this, the project wouldn't build. There were a number of
> errors that
> NB introduced in this process. I was able to fix all of them except this
> one.
>
> At this point, I'm torn about whether it's worth continuing with NB.
> Granted, I was able
> to create the initial project in a few minutes that probably would have
> taken hours
> by hand. And Granted, I've just started, so I might not yet have the hang of
> this. But
> the frequency of bugs in NB has taken me by surprise, and I find it very
> worrisome that
> I could end up at some critical moment in a project with a situation where
> NB introduces
> some show stopping error in the code and stubbornly refuses to let me fix
> it.
>
> I can see the potential for a lot of productivity gains from NB, but the
> immaturity worries
> me. How do most NB users deal with this level of unreliability in a tool
> that's so crucial to
> their work?

There's been much discussion about the issue of quality and reliability
lately. People decide for themselves whether the benefits outweigh the
risks.

It's a Matisse GUI that you're building, which explains why you can't
modify the code. I don't now whether the form file that accompanied the
source file contains any references to package names, but that would be
  the only risk you run from changing the package by hand outside NB.

Maybe you should wait for some advice on this from an experienced
Matisse user.

It would also be a good idea to visit the bug database and check for an
existing bug.

--
Peter B. West <http://cv.pbw.id.au/>
Folio <http://defoe.sourceforge.net/folio/>

[Kurt Olsen-3]

Folks, the issue Peter is raising is also one I've encountered. In my
opinion the details of what and how are irrelevant.
I can't refactor using Netbeans 6.1 or 6.5m1 either. I mean sometimes it
works, but when it involves refactoring across the .java, .form, and
.properties - more often than not it forgets something, making a hash of
the code. This then propagates into the Palette, your other forms.
So, I've been using eclipse for the refactoring.

Those of us asking for higher standards upon release do not seem to be
able to get this message across.
Consider the round-trip I went through.

Created desktop application, with ejb3/persistence unit support provided
by the given ToplinkEssentials.
After a bit I noticed that every form using the database, had a bit of
code that created an EntityManager.
First the line of code creates the Factory, then gives you an entity
manager. Each form creates the Factory.
That alone blows a whole lot of database code right out of the water.
Kiss goodbye to cacheing for example.
I didn't notice that right away however.....

I go on and enable JavaWebstart - it would indeed be create if I could
create a DesktopApplication with database and webstart support.
I found that ToplinkEssentials didn't work from a webstart application.
Tried for a couple of days...it was a no go.

I added hibernate, I did it myself because I couldn't find 'integrated
hibernate' support. I'd have to get plugins, add user libraries etc. etc.
Forget it, I just found all the jars myself, stuck them in my lib folder
and totally bypassed netbeans.

Now I have database, and webstart .... great....time to pass the
netbeans build script onto my Hudson build engine.
I found that the netbeans build script couldn't be run externally, I had
to cobble-together several fixes...it only took a couple of days.
By this time I'd found numerous other 'coding and useability' issues in
netbeans so had also started using eclipse on the code, especially
for modifying the netbeans build script. I just the eclipse ant editor.
But now I'm maintaining two sets of project meta-data when I
thought originally 'the only IDE you need' would suffice.

As the project gained weight, the code-editor interruptions, code that
indicates its broken when its not....it got even worse.
So, nobody tried to do a round-trip to production mode with the
'DesktopApplication' - don't tell me I was the first to try that?

This codebase is in bad-shape, and there really is no gilding the lily
here. The denial factor on this users-group seems somewhat high in this
regard.
I'm beginning to have some hope however, if we continue to discuss the
big-picture, and not individual bug reports I believe some real progress
can be made.

I've been thinking about something else too...As regards the legal
implications involved in 'open-source' vs. the advertising seen on sites
such as eclipse and netbeans. Consider the following scenario, which
could certainly happen:

A project manager makes the decision to use the open-source IDE-X - The
developers all download the 'release' versions and begin writing their
code. Then, as the project gains weight the bugs in IDE-X begin to
surface. They surface somewhat early in the project, but the timelines
slip, a deadline or two is missed, and the decision is made to abandon
IDE-X in favor of another. The team loses more time in the transition -
the design of the software might have to change in order to adapt to the
new IDE....eventually the project fails and the project manager is fired.

The project manager then sues the organization behind IDE-X claiming
false advertising. The project manager documents places in the code that
demonstrate clearly that IDE-X does not in fact do what the advertising
says it will do. The argument the project managers lawyer would make, is
that being 'open-source' does not exclude its parent organization from
false-advertising. Especially when  when clear benefits to the parent
organization(s)  can be shown as the result of the attracting developers
by saying anything they please.

We all know that mission-critical software is being written with
open-source IDE's - A big enough organization, which has a software
project failure than can be clearly linked to IDE bugs, when the web
site is offering up extravagant claims, and psuedo-scientific white
papers may very will prevail, and win damages.

Food for thought,
Kurt Olsen













Peter B. West wrote:

> RMMM wrote:
>>
>> I visited the class files I wanted to move to the new package one by
>> one. In
>> each such class file, I right clicked on the canvas, and chose
>> Refactor > Move... from
>> the pop up menu.
>> Then in the resulting "Move class" dialog, I specified the new
>> package name.
>> After
>> I was done doing this, the project wouldn't build. There were a
>> number of
>> errors that
>> NB introduced in this process. I was able to fix all of them except this
>> one.
>>
>> At this point, I'm torn about whether it's worth continuing with NB.
>> Granted, I was able
>> to create the initial project in a few minutes that probably would have
>> taken hours
>> by hand. And Granted, I've just started, so I might not yet have the
>> hang of
>> this. But the frequency of bugs in NB has taken me by surprise, and I
>> find it very
>> worrisome that
>> I could end up at some critical moment in a project with a situation
>> where
>> NB introduces
>> some show stopping error in the code and stubbornly refuses to let me
>> fix
>> it.
>>
>> I can see the potential for a lot of productivity gains from NB, but the
>> immaturity worries
>> me. How do most NB users deal with this level of unreliability in a tool
>> that's so crucial to
>> their work?
>
> There's been much discussion about the issue of quality and
> reliability lately. People decide for themselves whether the benefits
> outweigh the risks.
>
> It's a Matisse GUI that you're building, which explains why you can't
> modify the code. I don't now whether the form file that accompanied
> the source file contains any references to package names, but that
> would be  the only risk you run from changing the package by hand
> outside NB.
>
> Maybe you should wait for some advice on this from an experienced
> Matisse user.
>
> It would also be a good idea to visit the bug database and check for
> an existing bug.
>

[Peter B. West]

Kurt Olsen wrote:
....
> I can't refactor using Netbeans 6.1 or 6.5m1 either. I mean sometimes it
> works, but when it involves refactoring across the .java, .form, and
> .properties - more often than not it forgets something, making a hash of
> the code. This then propagates into the Palette, your other forms.
> So, I've been using eclipse for the refactoring.
>
> Those of us asking for higher standards upon release do not seem to be
> able to get this message across.
....
>
> This codebase is in bad-shape, and there really is no gilding the lily
> here. The denial factor on this users-group seems somewhat high in this
> regard.
> I'm beginning to have some hope however, if we continue to discuss the
> big-picture, and not individual bug reports I believe some real progress
> can be made.
....
> Food for thought,
> Kurt Olsen

I've been a user of NB since I switched my own codebase to Java 5, early
in the life of 1.5. At that time, and for some considerable time
afterwards, the only freely available IDE with 1.5 support was NetBeans.
That's when I became devoted to NB. Maybe someone here can tell me how
long it took for 1.5 support to stabilise on Eclipse - a long time, anyway.

I've been an NB user and supporter ever since, and a Sun supporter for
longer still. I couldn't understand the vitriol heaped on Sun from the
OS community, when the only reason open source developers could compete
in many areas was because of Java. I still don't understand, and I'm
still grateful to Sun for that.

That's the good news.

Sun has been in the trenches for many years now, and IBM would be just
as happy to write the obituary as MS. There is a lot of stuff around
about the demise of Java, and the rise of dynamic languages, and this
kind of buzz actually has an effect on people and corporations. So I
understand the push to get Ruby, JS, Python and co supported on the IDE.

However, like many others who have been posting, I think some of the
fundamentals have been overlooked along the way. I'd like to know how
this has happened, because unless the reasons are understood, the
remedies will be hard find.

I don't read books about programming; I just keep plugging on in the
same old quirky way. It's getting harder as I get older, I have to say.
But, from the first programming job I ever had until today, the greatest
drain on my productivity has been management.

I'm a devotee of open source software for a number of reasons. Price is
one. But more important is the model of software development. Yes, I
know that there is a lot of corporate involvement in OSS. But it seems
to me that the great white hope (please don't take offence) of software
is that first class popular software can be brought to "market" by teams
of developers designing, coding, testing and revising amongst
themselves, with feedback from their users. The key to this is the
responsibility taken by each and every member for the quality of the work.

Yes, there are plenty of dead codebases out there, mine amongst them.
But, remarkably, there are plenty that are alive and well to show the
power of ownership an commitment by the guys who are deciding what needs
to be written, and writing it.

Why this rant? I think that this connection has been lost in the NB
development team, if it was ever there. If I find out about a bug in my
code, especially one that is impacting users, I won't be doing anything
else until I fix it. It's my code, it's my bug, I'll fix it. In a
close-knit team, "my" code can become "our" code, with no shortage of
volunteers to fix it. That's a large part of the success of
developer-owned software.

And that's a running sore in corporate-owned software. Nobody owns the
emotional property.

So, do the NB developers own the code, or are they just doing the next
task they're assigned?
--
Peter B. West <http://cv.pbw.id.au/>
Folio <http://defoe.sourceforge.net/folio/>

[Carl Swan-2]

What RMMM is describing looks like code that was entered the code tab of GUI editor such as Custom Creation Code or Pre-init Code. This code is injected into the guarded blocks by NetBeans when the form XML file is parsed and is probably treated as string literals and is not affected by refactoring. I have had problems with custom component initialization and refactoring before. Refactoring does not support GUI form files well.

Carl


--
Carl Swan
InDepth Engineering

On Sun, Jul 20, 2008 at 2:29 AM, Peter B. West <lists@...> wrote:

RMMM wrote:

I visited the class files I wanted to move to the new package one by one. In
each such class file, I right clicked on the canvas, and chose Refactor > Move... from
the pop up menu.
Then in the resulting "Move class" dialog, I specified the new package name.
After
I was done doing this, the project wouldn't build. There were a number of
errors that
NB introduced in this process. I was able to fix all of them except this
one.

At this point, I'm torn about whether it's worth continuing with NB.
Granted, I was able
to create the initial project in a few minutes that probably would have
taken hours
by hand. And Granted, I've just started, so I might not yet have the hang of
this. But the frequency of bugs in NB has taken me by surprise, and I find it very
worrisome that
I could end up at some critical moment in a project with a situation where
NB introduces
some show stopping error in the code and stubbornly refuses to let me fix
it.

I can see the potential for a lot of productivity gains from NB, but the
immaturity worries
me. How do most NB users deal with this level of unreliability in a tool
that's so crucial to
their work?

There's been much discussion about the issue of quality and reliability lately. People decide for themselves whether the benefits outweigh the risks.

It's a Matisse GUI that you're building, which explains why you can't modify the code. I don't now whether the form file that accompanied the source file contains any references to package names, but that would be  the only risk you run from changing the package by hand outside NB.

Maybe you should wait for some advice on this from an experienced Matisse user.

It would also be a good idea to visit the bug database and check for an existing bug.

--
Peter B. West <http://cv.pbw.id.au/>
Folio <http://defoe.sourceforge.net/folio/>

[Oddvard M]

Hi,

 

I have done the renaming of packages before and without any problems. NOT matisse GUI files though, but regular source packages. This note offers no solution to the below mentioned constraint but more on how NB offers you refactoring and the power of it.

 

To rename a package and all references to it in a project simply do this:

 

1. Select the package in 'Project View -> Source Packages'.

2. Right click and select 'Refractor -> Rename'

 

All files in source package are corrected and all references (imports, variable names etc) are corrected globally in project.

 

Oddvard

-----Original Message-----
From: Carl Swan [mailto:carl.swan@...]
Sent: Sunday, July 20, 2008 6:11 PM
To: nbusers@...
Subject: Re: [nbusers] Can't correct the type of a variable after a refactor

What RMMM is describing looks like code that was entered the code tab of GUI editor such as Custom Creation Code or Pre-init Code. This code is injected into the guarded blocks by NetBeans when the form XML file is parsed and is probably treated as string literals and is not affected by refactoring. I have had problems with custom component initialization and refactoring before. Refactoring does not support GUI form files well.

Carl


--
Carl Swan
InDepth Engineering

On Sun, Jul 20, 2008 at 2:29 AM, Peter B. West <lists@...> wrote:

RMMM wrote:

I visited the class files I wanted to move to the new package one by one. In
each such class file, I right clicked on the canvas, and chose Refactor > Move... from
the pop up menu.
Then in the resulting "Move class" dialog, I specified the new package name.
After
I was done doing this, the project wouldn't build. There were a number of
errors that
NB introduced in this process. I was able to fix all of them except this
one.

At this point, I'm torn about whether it's worth continuing with NB.
Granted, I was able
to create the initial project in a few minutes that probably would have
taken hours
by hand. And Granted, I've just started, so I might not yet have the hang of
this. But the frequency of bugs in NB has taken me by surprise, and I find it very
worrisome that
I could end up at some critical moment in a project with a situation where
NB introduces
some show stopping error in the code and stubbornly refuses to let me fix
it.

I can see the potential for a lot of productivity gains from NB, but the
immaturity worries
me. How do most NB users deal with this level of unreliability in a tool
that's so crucial to
their work?

There's been much discussion about the issue of quality and reliability lately. People decide for themselves whether the benefits outweigh the risks.

It's a Matisse GUI that you're building, which explains why you can't modify the code. I don't now whether the form file that accompanied the source file contains any references to package names, but that would be  the only risk you run from changing the package by hand outside NB.

Maybe you should wait for some advice on this from an experienced Matisse user.

It would also be a good idea to visit the bug database and check for an existing bug.

--
Peter B. West <http://cv.pbw.id.au/>
Folio <http://defoe.sourceforge.net/folio/>

[Oddvard M]

Dear Kurt,

You maybe disagree with me here, but my personal opinion is that Mr. Murphy is an optimist..:-)

AND LAWYERS WILL NOT GET INTO HEAVEN..BUT WILL BE REBORN AS PROGRAMMERS AND WORK AS PROJECT MANAGERS...he he

Oddvard

-----Original Message-----
From: Kurt Olsen [mailto:kolsen@...]
Sent: Sunday, July 20, 2008 9:24 AM
To: nbusers@...
Subject: Re: [nbusers] QA-Can't correct the type of a variable after a
refactor


Folks, the issue Peter is raising is also one I've encountered. In my
opinion the details of what and how are irrelevant.
I can't refactor using Netbeans 6.1 or 6.5m1 either. I mean sometimes it
works, but when it involves refactoring across the .java, .form, and
.properties - more often than not it forgets something, making a hash of
the code. This then propagates into the Palette, your other forms.
So, I've been using eclipse for the refactoring.

Those of us asking for higher standards upon release do not seem to be
able to get this message across.
Consider the round-trip I went through.

Created desktop application, with ejb3/persistence unit support provided
by the given ToplinkEssentials.
After a bit I noticed that every form using the database, had a bit of
code that created an EntityManager.
First the line of code creates the Factory, then gives you an entity
manager. Each form creates the Factory.
That alone blows a whole lot of database code right out of the water.
Kiss goodbye to cacheing for example.
I didn't notice that right away however.....

I go on and enable JavaWebstart - it would indeed be create if I could
create a DesktopApplication with database and webstart support.
I found that ToplinkEssentials didn't work from a webstart application.
Tried for a couple of days...it was a no go.

I added hibernate, I did it myself because I couldn't find 'integrated
hibernate' support. I'd have to get plugins, add user libraries etc. etc.
Forget it, I just found all the jars myself, stuck them in my lib folder
and totally bypassed netbeans.

Now I have database, and webstart .... great....time to pass the
netbeans build script onto my Hudson build engine.
I found that the netbeans build script couldn't be run externally, I had
to cobble-together several fixes...it only took a couple of days.
By this time I'd found numerous other 'coding and useability' issues in
netbeans so had also started using eclipse on the code, especially
for modifying the netbeans build script. I just the eclipse ant editor.
But now I'm maintaining two sets of project meta-data when I
thought originally 'the only IDE you need' would suffice.

As the project gained weight, the code-editor interruptions, code that
indicates its broken when its not....it got even worse.
So, nobody tried to do a round-trip to production mode with the
'DesktopApplication' - don't tell me I was the first to try that?

This codebase is in bad-shape, and there really is no gilding the lily
here. The denial factor on this users-group seems somewhat high in this
regard.
I'm beginning to have some hope however, if we continue to discuss the
big-picture, and not individual bug reports I believe some real progress
can be made.

I've been thinking about something else too...As regards the legal
implications involved in 'open-source' vs. the advertising seen on sites
such as eclipse and netbeans. Consider the following scenario, which
could certainly happen:

A project manager makes the decision to use the open-source IDE-X - The
developers all download the 'release' versions and begin writing their
code. Then, as the project gains weight the bugs in IDE-X begin to
surface. They surface somewhat early in the project, but the timelines
slip, a deadline or two is missed, and the decision is made to abandon
IDE-X in favor of another. The team loses more time in the transition -
the design of the software might have to change in order to adapt to the
new IDE....eventually the project fails and the project manager is fired.

The project manager then sues the organization behind IDE-X claiming
false advertising. The project manager documents places in the code that
demonstrate clearly that IDE-X does not in fact do what the advertising
says it will do. The argument the project managers lawyer would make, is
that being 'open-source' does not exclude its parent organization from
false-advertising. Especially when  when clear benefits to the parent
organization(s)  can be shown as the result of the attracting developers
by saying anything they please.

We all know that mission-critical software is being written with
open-source IDE's - A big enough organization, which has a software
project failure than can be clearly linked to IDE bugs, when the web
site is offering up extravagant claims, and psuedo-scientific white
papers may very will prevail, and win damages.

Food for thought,
Kurt Olsen













Peter B. West wrote:

> RMMM wrote:
>>
>> I visited the class files I wanted to move to the new package one by
>> one. In
>> each such class file, I right clicked on the canvas, and chose
>> Refactor > Move... from
>> the pop up menu.
>> Then in the resulting "Move class" dialog, I specified the new
>> package name.
>> After
>> I was done doing this, the project wouldn't build. There were a
>> number of
>> errors that
>> NB introduced in this process. I was able to fix all of them except this
>> one.
>>
>> At this point, I'm torn about whether it's worth continuing with NB.
>> Granted, I was able
>> to create the initial project in a few minutes that probably would have
>> taken hours
>> by hand. And Granted, I've just started, so I might not yet have the
>> hang of
>> this. But the frequency of bugs in NB has taken me by surprise, and I
>> find it very
>> worrisome that
>> I could end up at some critical moment in a project with a situation
>> where
>> NB introduces
>> some show stopping error in the code and stubbornly refuses to let me
>> fix
>> it.
>>
>> I can see the potential for a lot of productivity gains from NB, but the
>> immaturity worries
>> me. How do most NB users deal with this level of unreliability in a tool
>> that's so crucial to
>> their work?
>
> There's been much discussion about the issue of quality and
> reliability lately. People decide for themselves whether the benefits
> outweigh the risks.
>
> It's a Matisse GUI that you're building, which explains why you can't
> modify the code. I don't now whether the form file that accompanied
> the source file contains any references to package names, but that
> would be  the only risk you run from changing the package by hand
> outside NB.
>
> Maybe you should wait for some advice on this from an experienced
> Matisse user.
>
> It would also be a good idea to visit the bug database and check for
> an existing bug.
>

[Kurt Olsen-3]

Hah!
Oddvard Myrnes wrote:

> Dear Kurt,
>
> You maybe disagree with me here, but my personal opinion is that Mr. Murphy is an optimist..:-)
>
> AND LAWYERS WILL NOT GET INTO HEAVEN..BUT WILL BE REBORN AS PROGRAMMERS AND WORK AS PROJECT MANAGERS...he he
>
> Oddvard
>
> -----Original Message-----
> From: Kurt Olsen [mailto:kolsen@...]
> Sent: Sunday, July 20, 2008 9:24 AM
> To: nbusers@...
> Subject: Re: [nbusers] QA-Can't correct the type of a variable after a
> refactor
>
>
> Folks, the issue Peter is raising is also one I've encountered. In my
> opinion the details of what and how are irrelevant.
> I can't refactor using Netbeans 6.1 or 6.5m1 either. I mean sometimes it
> works, but when it involves refactoring across the .java, .form, and
> .properties - more often than not it forgets something, making a hash of
> the code. This then propagates into the Palette, your other forms.
> So, I've been using eclipse for the refactoring.
>
> Those of us asking for higher standards upon release do not seem to be
> able to get this message across.
> Consider the round-trip I went through.
>
> Created desktop application, with ejb3/persistence unit support provided
> by the given ToplinkEssentials.
> After a bit I noticed that every form using the database, had a bit of
> code that created an EntityManager.
> First the line of code creates the Factory, then gives you an entity
> manager. Each form creates the Factory.
> That alone blows a whole lot of database code right out of the water.
> Kiss goodbye to cacheing for example.
> I didn't notice that right away however.....
>
> I go on and enable JavaWebstart - it would indeed be create if I could
> create a DesktopApplication with database and webstart support.
> I found that ToplinkEssentials didn't work from a webstart application.
> Tried for a couple of days...it was a no go.
>
> I added hibernate, I did it myself because I couldn't find 'integrated
> hibernate' support. I'd have to get plugins, add user libraries etc. etc.
> Forget it, I just found all the jars myself, stuck them in my lib folder
> and totally bypassed netbeans.
>
> Now I have database, and webstart .... great....time to pass the
> netbeans build script onto my Hudson build engine.
> I found that the netbeans build script couldn't be run externally, I had
> to cobble-together several fixes...it only took a couple of days.
> By this time I'd found numerous other 'coding and useability' issues in
> netbeans so had also started using eclipse on the code, especially
> for modifying the netbeans build script. I just the eclipse ant editor.
> But now I'm maintaining two sets of project meta-data when I
> thought originally 'the only IDE you need' would suffice.
>
> As the project gained weight, the code-editor interruptions, code that
> indicates its broken when its not....it got even worse.
> So, nobody tried to do a round-trip to production mode with the
> 'DesktopApplication' - don't tell me I was the first to try that?
>
> This codebase is in bad-shape, and there really is no gilding the lily
> here. The denial factor on this users-group seems somewhat high in this
> regard.
> I'm beginning to have some hope however, if we continue to discuss the
> big-picture, and not individual bug reports I believe some real progress
> can be made.
>
> I've been thinking about something else too...As regards the legal
> implications involved in 'open-source' vs. the advertising seen on sites
> such as eclipse and netbeans. Consider the following scenario, which
> could certainly happen:
>
> A project manager makes the decision to use the open-source IDE-X - The
> developers all download the 'release' versions and begin writing their
> code. Then, as the project gains weight the bugs in IDE-X begin to
> surface. They surface somewhat early in the project, but the timelines
> slip, a deadline or two is missed, and the decision is made to abandon
> IDE-X in favor of another. The team loses more time in the transition -
> the design of the software might have to change in order to adapt to the
> new IDE....eventually the project fails and the project manager is fired.
>
> The project manager then sues the organization behind IDE-X claiming
> false advertising. The project manager documents places in the code that
> demonstrate clearly that IDE-X does not in fact do what the advertising
> says it will do. The argument the project managers lawyer would make, is
> that being 'open-source' does not exclude its parent organization from
> false-advertising. Especially when  when clear benefits to the parent
> organization(s)  can be shown as the result of the attracting developers
> by saying anything they please.
>
> We all know that mission-critical software is being written with
> open-source IDE's - A big enough organization, which has a software
> project failure than can be clearly linked to IDE bugs, when the web
> site is offering up extravagant claims, and psuedo-scientific white
> papers may very will prevail, and win damages.
>
> Food for thought,
> Kurt Olsen
>
>
>
>
>
>
>
>
>
>
>
>
>
> Peter B. West wrote:
>  
>> RMMM wrote:
>>    
>>> I visited the class files I wanted to move to the new package one by
>>> one. In
>>> each such class file, I right clicked on the canvas, and chose
>>> Refactor > Move... from
>>> the pop up menu.
>>> Then in the resulting "Move class" dialog, I specified the new
>>> package name.
>>> After
>>> I was done doing this, the project wouldn't build. There were a
>>> number of
>>> errors that
>>> NB introduced in this process. I was able to fix all of them except this
>>> one.
>>>
>>> At this point, I'm torn about whether it's worth continuing with NB.
>>> Granted, I was able
>>> to create the initial project in a few minutes that probably would have
>>> taken hours
>>> by hand. And Granted, I've just started, so I might not yet have the
>>> hang of
>>> this. But the frequency of bugs in NB has taken me by surprise, and I
>>> find it very
>>> worrisome that
>>> I could end up at some critical moment in a project with a situation
>>> where
>>> NB introduces
>>> some show stopping error in the code and stubbornly refuses to let me
>>> fix
>>> it.
>>>
>>> I can see the potential for a lot of productivity gains from NB, but the
>>> immaturity worries
>>> me. How do most NB users deal with this level of unreliability in a tool
>>> that's so crucial to
>>> their work?
>>>      
>> There's been much discussion about the issue of quality and
>> reliability lately. People decide for themselves whether the benefits
>> outweigh the risks.
>>
>> It's a Matisse GUI that you're building, which explains why you can't
>> modify the code. I don't now whether the form file that accompanied
>> the source file contains any references to package names, but that
>> would be  the only risk you run from changing the package by hand
>> outside NB.
>>
>> Maybe you should wait for some advice on this from an experienced
>> Matisse user.
>>
>> It would also be a good idea to visit the bug database and check for
>> an existing bug.
>>
>>    
>
>
>  

[Oddvard M]

Kurt,

Thanks for the pinter to the YOUNG page. It saved me a lot of time..

Oddvard :-)

-----Original Message-----
From: Kurt Olsen [mailto:kolsen@...]
Sent: Monday, July 21, 2008 7:47 AM
To: nbusers@...
Subject: Re: [nbusers] QA-Can't correct the type of a variable after a
refactor


Hah!
Oddvard Myrnes wrote:

> Dear Kurt,
>
> You maybe disagree with me here, but my personal opinion is that Mr. Murphy is an optimist..:-)
>
> AND LAWYERS WILL NOT GET INTO HEAVEN..BUT WILL BE REBORN AS PROGRAMMERS AND WORK AS PROJECT MANAGERS...he he
>
> Oddvard
>
> -----Original Message-----
> From: Kurt Olsen [mailto:kolsen@...]
> Sent: Sunday, July 20, 2008 9:24 AM
> To: nbusers@...
> Subject: Re: [nbusers] QA-Can't correct the type of a variable after a
> refactor
>
>
> Folks, the issue Peter is raising is also one I've encountered. In my
> opinion the details of what and how are irrelevant.
> I can't refactor using Netbeans 6.1 or 6.5m1 either. I mean sometimes it
> works, but when it involves refactoring across the .java, .form, and
> .properties - more often than not it forgets something, making a hash of
> the code. This then propagates into the Palette, your other forms.
> So, I've been using eclipse for the refactoring.
>
> Those of us asking for higher standards upon release do not seem to be
> able to get this message across.
> Consider the round-trip I went through.
>
> Created desktop application, with ejb3/persistence unit support provided
> by the given ToplinkEssentials.
> After a bit I noticed that every form using the database, had a bit of
> code that created an EntityManager.
> First the line of code creates the Factory, then gives you an entity
> manager. Each form creates the Factory.
> That alone blows a whole lot of database code right out of the water.
> Kiss goodbye to cacheing for example.
> I didn't notice that right away however.....
>
> I go on and enable JavaWebstart - it would indeed be create if I could
> create a DesktopApplication with database and webstart support.
> I found that ToplinkEssentials didn't work from a webstart application.
> Tried for a couple of days...it was a no go.
>
> I added hibernate, I did it myself because I couldn't find 'integrated
> hibernate' support. I'd have to get plugins, add user libraries etc. etc.
> Forget it, I just found all the jars myself, stuck them in my lib folder
> and totally bypassed netbeans.
>
> Now I have database, and webstart .... great....time to pass the
> netbeans build script onto my Hudson build engine.
> I found that the netbeans build script couldn't be run externally, I had
> to cobble-together several fixes...it only took a couple of days.
> By this time I'd found numerous other 'coding and useability' issues in
> netbeans so had also started using eclipse on the code, especially
> for modifying the netbeans build script. I just the eclipse ant editor.
> But now I'm maintaining two sets of project meta-data when I
> thought originally 'the only IDE you need' would suffice.
>
> As the project gained weight, the code-editor interruptions, code that
> indicates its broken when its not....it got even worse.
> So, nobody tried to do a round-trip to production mode with the
> 'DesktopApplication' - don't tell me I was the first to try that?
>
> This codebase is in bad-shape, and there really is no gilding the lily
> here. The denial factor on this users-group seems somewhat high in this
> regard.
> I'm beginning to have some hope however, if we continue to discuss the
> big-picture, and not individual bug reports I believe some real progress
> can be made.
>
> I've been thinking about something else too...As regards the legal
> implications involved in 'open-source' vs. the advertising seen on sites
> such as eclipse and netbeans. Consider the following scenario, which
> could certainly happen:
>
> A project manager makes the decision to use the open-source IDE-X - The
> developers all download the 'release' versions and begin writing their
> code. Then, as the project gains weight the bugs in IDE-X begin to
> surface. They surface somewhat early in the project, but the timelines
> slip, a deadline or two is missed, and the decision is made to abandon
> IDE-X in favor of another. The team loses more time in the transition -
> the design of the software might have to change in order to adapt to the
> new IDE....eventually the project fails and the project manager is fired.
>
> The project manager then sues the organization behind IDE-X claiming
> false advertising. The project manager documents places in the code that
> demonstrate clearly that IDE-X does not in fact do what the advertising
> says it will do. The argument the project managers lawyer would make, is
> that being 'open-source' does not exclude its parent organization from
> false-advertising. Especially when  when clear benefits to the parent
> organization(s)  can be shown as the result of the attracting developers
> by saying anything they please.
>
> We all know that mission-critical software is being written with
> open-source IDE's - A big enough organization, which has a software
> project failure than can be clearly linked to IDE bugs, when the web
> site is offering up extravagant claims, and psuedo-scientific white
> papers may very will prevail, and win damages.
>
> Food for thought,
> Kurt Olsen
>
>
>
>
>
>
>
>
>
>
>
>
>
> Peter B. West wrote:
>  
>> RMMM wrote:
>>    
>>> I visited the class files I wanted to move to the new package one by
>>> one. In
>>> each such class file, I right clicked on the canvas, and chose
>>> Refactor > Move... from
>>> the pop up menu.
>>> Then in the resulting "Move class" dialog, I specified the new
>>> package name.
>>> After
>>> I was done doing this, the project wouldn't build. There were a
>>> number of
>>> errors that
>>> NB introduced in this process. I was able to fix all of them except this
>>> one.
>>>
>>> At this point, I'm torn about whether it's worth continuing with NB.
>>> Granted, I was able
>>> to create the initial project in a few minutes that probably would have
>>> taken hours
>>> by hand. And Granted, I've just started, so I might not yet have the
>>> hang of
>>> this. But the frequency of bugs in NB has taken me by surprise, and I
>>> find it very
>>> worrisome that
>>> I could end up at some critical moment in a project with a situation
>>> where
>>> NB introduces
>>> some show stopping error in the code and stubbornly refuses to let me
>>> fix
>>> it.
>>>
>>> I can see the potential for a lot of productivity gains from NB, but the
>>> immaturity worries
>>> me. How do most NB users deal with this level of unreliability in a tool
>>> that's so crucial to
>>> their work?
>>>      
>> There's been much discussion about the issue of quality and
>> reliability lately. People decide for themselves whether the benefits
>> outweigh the risks.
>>
>> It's a Matisse GUI that you're building, which explains why you can't
>> modify the code. I don't now whether the form file that accompanied
>> the source file contains any references to package names, but that
>> would be  the only risk you run from changing the package by hand
>> outside NB.
>>
>> Maybe you should wait for some advice on this from an experienced
>> Matisse user.
>>
>> It would also be a good idea to visit the bug database and check for
>> an existing bug.
>>
>>    
>
>
>