Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Red Hat, Sun finally buddy up on Java

Reply
Thread Tools

Red Hat, Sun finally buddy up on Java

 
 
Ramon F Herrera
Guest
Posts: n/a
 
      11-06-2007
One can't help but wonder whether the next step is the integration of
NetBeans into Eclipse...

"Sun Microsystems' move to make its core Java software a true open-
source project may still be a project in its early stages, but on
Monday the effort produced some concrete results: a partnership with
long-time holdout Red Hat."

[...]

http://www.news.com/8301-13580_3-9811395-39.html

-RFH

 
Reply With Quote
 
 
 
 
Lew
Guest
Posts: n/a
 
      11-06-2007
Ramon F Herrera wrote:
> One can't help but wonder whether the next step is the integration of
> NetBeans into Eclipse...


Gods, I hope not!

--
Lew
 
Reply With Quote
 
 
 
 
Mark Space
Guest
Posts: n/a
 
      11-06-2007
Ramon F Herrera wrote:
> One can't help but wonder whether the next step is the integration of
> NetBeans into Eclipse...


I doubt it. This move is centered on the server space. More likely
you'd see a merger of JBoss and Glassfish, or at least a feature swap.
(But even a merger of those, I don't see as very likely.) I don't see
anything that points at one side giving up their desktop IDE.

 
Reply With Quote
 
Ramon F Herrera
Guest
Posts: n/a
 
      11-06-2007
On Nov 5, 11:11 pm, Mark Space <(E-Mail Removed)> wrote:
> Ramon F Herrera wrote:
> > One can't help but wonder whether the next step is the integration of
> > NetBeans into Eclipse...

>
> I doubt it. This move is centered on the server space. More likely
> you'd see a merger of JBoss and Glassfish, or at least a feature swap.
> (But even a merger of those, I don't see as very likely.) I don't see
> anything that points at one side giving up their desktop IDE.


Mark & Lew:

Perhaps a solution to keep everyone happy would be for the NetBeans
team to follow on Borland/CodeGear's footsteps? NetGear would be able
to contribute and impart their own kind on magic to an Eclipse base.

Competition is extremely important, and I would be very worried to see
Eclipse swallowing everybody else, the way they did with JBuilder.

The one item in my wish list is that all Java IDE providers:

- Had a common directory and file structure for projects
- Allowed me to easily keep all the *.java files in a separate
directory, accessible by all the IDEs that I use.

As long as we have these annoying and counterproductive
incompatibilities -such as a *.form file that can only be read by the
original creating IDE- many developers are going the Microsoft route.

-Ramon


 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      11-06-2007
Ramon F Herrera wrote:
> The one item in my wish list is that all Java IDE providers:
>
> - Had a common directory and file structure for projects


NetBeans sets up projects by menu choice according to the Sun Java Blueprints
standard or the Apache Tomcat standard. Eclipse likewise follows the standard
layouts for various types of Java projects. Other than the defaults for the
names of certain non-deployed directories, which are easily changed in the
options, the two create the same directory structures.

The IDE-specific directories, such as "nbproject/" for NetBeans, aren't even
portable within their own IDE, I've found. So much of the specific workspace
is bound up in them. Likewise with the "workspace/" directories in Eclipse.
Oh, the project files transfer, but somehow you just never can change the
build or packaging. OTOH, when you create a new IDE-specific project tree for
each workspace, NB or Eclipse, then you can filter that out when you transfer
the project around. Ant is your friend, and it don't need your stinkin'
project dirs. That's how you get true portability.

Mind you, NB uses Ant for its project management files, so it really is
portable. Uhh, except that their Ant files are structured the way they like,
and pull in all this stuff you might not necessarily need for your production
builds, say. So even though Ant uses your build files portably, your build
files might not be portable. So, you leave the IDE project files out, too,
even build.xml, and use your own build.xml for test and production builds, and
you do not transfer the IDE build.xml between workspaces.

> - Allowed me to easily keep all the *.java files in a separate
> directory, accessible by all the IDEs that I use.


I have never had trouble accessing the Java source directory, always distinct
from deployment directories, disk-specific project information, doc
directories and other source trees such as SQL, for the same project equally
well from NetBeans and Eclipse. It's always a separate directory, and both
products read it just fine, without any strain on my part.

They also keep their build and deployment directories separate.

The fault, dear Brutus, lies not in our IDEs, but in ourselves.

--
Lew
 
Reply With Quote
 
Owen Jacobson
Guest
Posts: n/a
 
      11-06-2007
"Finally"? Redhat was the only distro with a functional java package
(rather than the binary installer) for a long time. Sun and Redhat
have been playing nicey-nice with each other for ages, relative to the
linux community at large.

On Nov 5, 7:41 pm, Ramon F Herrera <(E-Mail Removed)> wrote:
> On Nov 5, 11:11 pm, Mark Space <(E-Mail Removed)> wrote:
>
> > Ramon F Herrera wrote:
> > > One can't help but wonder whether the next step is the integration of
> > > NetBeans into Eclipse...

>
> > I doubt it. This move is centered on the server space. More likely
> > you'd see a merger of JBoss and Glassfish, or at least a feature swap.
> > (But even a merger of those, I don't see as very likely.) I don't see
> > anything that points at one side giving up their desktop IDE.

>
> Mark & Lew:
>
> Perhaps a solution to keep everyone happy would be for the NetBeans
> team to follow on Borland/CodeGear's footsteps? NetGear would be able
> to contribute and impart their own kind on magic to an Eclipse base.
>
> Competition is extremely important, and I would be very worried to see
> Eclipse swallowing everybody else, the way they did with JBuilder.
>
> The one item in my wish list is that all Java IDE providers:
>
> - Had a common directory and file structure for projects
> - Allowed me to easily keep all the *.java files in a separate
> directory, accessible by all the IDEs that I use.


*dons asbestos undergarments*

People who voluntarily store critical parts of their source (like GUI
layouts) in such a way that only one tool can possibly build it are
creating their own problem, regardless of language.

*removes asbestos undergarments*

For myself, I've solved both of these issues with Apache Maven, which
is capable of generating projects for several IDEs from a common
codebase and project file. The process for getting a working eclipse
environment for the projects I'm working on right now is:
1. check out.
2. mvn eclipse:eclipse
3. Eclipse/Import/Existing Projects

I found plugins for IDEA and Netbeans project generation, too.

Rather than impose a specific standard source layout on every single
tool[0], we should probably demand simpler, better-documented formats
for project metadata and clearer conceptual mappings between tool-
specific concepts (like Netbeans' "modules") and standard concepts
(like "JAR").

[0] I expect to be burned at the stake by other maven users for
uttering that sentence.

 
Reply With Quote
 
Hunter Gratzner
Guest
Posts: n/a
 
      11-06-2007
On Nov 6, 3:07 am, Ramon F Herrera <(E-Mail Removed)> wrote:
> One can't help but wonder whether the next step is the integration of
> NetBeans into Eclipse...


Nothing to wonder about. This is about IcedTea, RedHat's fork of
OpenJDK. RedHat forked this (claiming it is no fork) because Sun made
it impossible to contribute back to OpenJDK in bulk. IcedTea merged
parts of Classpath into OpenJDK to get an unencumbered, clean free
software Java. These changes couldn't be put back into OpenJDK,
because Sun had wrapped OpenJDK in a bunch of red tape. Only
individuals, singing a contributor agreement, could get stuff into
OpenJDK. Now RH got a corporate contributor agreement. So RH can now
put IcedTea changes back into OpenJDK. This is Sun's venue to finally
get Classpath code into OpenJDK. Sun is very cautious about code
contributed to any of their open source projects, fearing poisoning
with non-free code. Now they have someone (RedHat) signing for that
code and taking responsibility.

Further, RedHat couldn't call the result from IcedTea Java, because
Java is a Sun trademark and Sun requires that a product called Java
has passed Sun's compatibility test. Now RedHat has got a license for
that compatibility test. It is easy to guess what they'll try to do
with that test: Making IcedTea the predominant OpenJDK-based free-
software Java implementation/distribution on Linux.

 
Reply With Quote
 
Andrew Thompson
Guest
Posts: n/a
 
      11-06-2007
Lew wrote:
>...Ant is your friend, and it don't need your stinkin'
>project dirs. That's how you get true portability.


As a big fan of Ant and the portability it provides, I just
cannot resist adding a 'Right On!' at this moment.

So..

Right On!

--
Andrew Thompson
http://www.athompson.info/andrew/

Message posted via JavaKB.com
http://www.javakb.com/Uwe/Forums.asp...neral/200711/1

 
Reply With Quote
 
=?ISO-8859-1?Q?Arne_Vajh=F8j?=
Guest
Posts: n/a
 
      11-07-2007
Hunter Gratzner wrote:
> Nothing to wonder about. This is about IcedTea, RedHat's fork of
> OpenJDK. RedHat forked this (claiming it is no fork) because Sun made
> it impossible to contribute back to OpenJDK in bulk. IcedTea merged
> parts of Classpath into OpenJDK to get an unencumbered, clean free
> software Java. These changes couldn't be put back into OpenJDK,
> because Sun had wrapped OpenJDK in a bunch of red tape. Only
> individuals, singing a contributor agreement, could get stuff into
> OpenJDK. Now RH got a corporate contributor agreement. So RH can now
> put IcedTea changes back into OpenJDK. This is Sun's venue to finally
> get Classpath code into OpenJDK. Sun is very cautious about code
> contributed to any of their open source projects, fearing poisoning
> with non-free code. Now they have someone (RedHat) signing for that
> code and taking responsibility.


SUN is not the only one with strict contribution policies.

Apache example:
http://harmony.apache.org/auth_cont_quest.html
http://www.apache.org/licenses/icla.txt
http://www.apache.org/licenses/cla-corporate.txt

Arne
 
Reply With Quote
 
=?UTF-8?B?QXJuZSBWYWpow7hq?=
Guest
Posts: n/a
 
      11-07-2007
Lew wrote:
> Ramon F Herrera wrote:
>> One can't help but wonder whether the next step is the integration of
>> NetBeans into Eclipse...

>
> Gods, I hope not!


Me neither.

And I prefer Eclipse over NetBeans anyday.

But an Eclipse monopoly on Java IDE would be a very bad
thing for its future evolution.

Arne
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Try...Catch...Finally not firing finally? David Lozzi ASP .Net 12 05-11-2007 12:41 AM
Sun Updates Sun Java Availability Suite, Adds Sun Cluster Advanced Edition for Oracle Real Application Clusters Deployments technology_post@yahoo.com Java 0 04-05-2006 04:29 AM
fs: Detroit Red Wings, Red Alert - Hockeytown 3 sonof3m DVD Video 0 12-17-2004 12:59 AM
Diff of Sun Java System AppServer vs. SunONE Server vs. Sun Java System Web Server ? Ulf Meinhardt Java 0 11-11-2004 09:40 PM
Datawrite Red (V3) Red - DVD-R's Alex B Computer Support 3 07-16-2004 12:08 AM



Advertisments