Red Hat, Sun finally buddy up on Java

[Ramon F Herrera]

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

 

[Lew]

One can't help but wonder whether the next step is the integration of
NetBeans into Eclipse...

Gods, I hope not!

 

[Mark Space]

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.

 

[Ramon F Herrera]

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

 

[Lew]

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.

 

[Owen Jacobson]

"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.

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.

 

[Hunter Gratzner]

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.

 

[Andrew Thompson]

...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.aspx/java-general/200711/1

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

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

 

[Guest]

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