Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Archived » Faceted Project Framework » What's broken in natures?
What's broken in natures? [message #2207] Fri, 24 October 2008 16:00 Go to next message
Lawrence Mandel is currently offline Lawrence Mandel
Messages: 486
Registered: July 2009
Senior Member
Hi Kosta,

As you know, I've been using WTP and the faceted project framework since
its inception. I read the project proposal. I agree that it's hacky at
best to require users to edit the .project file manually to manage
natures. One thing that I'm still not clear on is what are the limitations
of project natures that require a new project facet artifact? Put another
way, why not simply create a good UI for manipulating project natures?

Lawrence
Re: What's broken in natures? [message #2239 is a reply to message #2207] Fri, 24 October 2008 18:35 Go to previous messageGo to next message
Konstantin Komissarchik is currently offline Konstantin Komissarchik
Messages: 923
Registered: July 2009
Senior Member
Good question!

Natures are extremely simple. The original use case for natures is to
basically serve as a flag modeling something akin to a project type. The
good UI that you speak of for adding and removing natures would need a lot
more information and callable behaviors than is provided by the natures
API. The limitations make sense since the natures API was written with
simple use cases in mind and natures were not intended to be
fully-described and self-supporting.

Let's look at one API as an example. The IProjectNature interface has
configure() and deconfigure() methods that nature authors get to
implement. These methods get called when a nature is added to or removed
from a project. Notice how those methods take no parameters. That means it
is not possible to pass in a configuration object that would let the user
have input as these actions take place. So what, you say. We've solved
that problem before. We will just create IProjectNature2 with variants of
those two methods capable of taking parameters. Problem solved. Not quite.
The issue is that there are many natures already implemented in various
Eclipse projects and commercial products. For years nature authors have
been working around this API limitation. The most common work-around is to
move most of the interesting code outside these two methods. In the case
of the configure() method all of this code is embedded in various project
creation wizards and "Enable function X" menu actions. The configure()
implementations themselves typically are not sufficient to properly
configure the project and often rely on stuff happening prior to the
nature getting added. For the most part, the deconfigure() methods are
implemented as no-ops. Since there is no UI for the user to remove a
nature, why bother with implementing this method?

In short, the biggest obstacle to making it possible for users to add and
remove natures are the existing nature implementations. Practically every
nature out there would be broken behaviorally if UI for adding and
removing natures was introduced.

Ok. So we need a more gradual phased-in approach that doesn't give
everyone in the Eclipse Community a massive coronary. Enter facets. We
started from scratch and designed the facets API together with UI for
adding and removing them. The framework evolved over the years to cover a
lot of different use cases that adopters brought to the table. Since
making a project faceted is controlled by a flag (a nature, actually), the
project wizard owner get to opt-in when they are ready. Part of the opt-in
process is gathering all of the code that strewn about in various wizards
and actions and writing a facet based on that code. It often make sense to
retain any existing natures for backwards compatibility, but facets would
now control adding and removing them.

The pattern of wrapping a facet around a nature is particularly important
when you consider the case of an Eclipse Project re-using another
Project's functionality. We need a solution for enabling a downstream
Project to transition to facets while the upstream Project is not ready
yet and continues using natures. The original example of this is WTP's
re-use of JDT's java nature for various WTP projects like Dynamic Web
Project. It was necessary for WTP to move forward with creating faceted
projects without depending on JDT adopting the same approach and making
requisite changes to it's code base. The facets architecture allowed us in
WTP to implement a java facet on our own that wraps JDT's java nature.
JDT's Java Project (as well as all the other projects that re-use java
nature) continue to work as before while WTP users start benefiting from
the richer experience provided by facets. If JDT ever decided to adopt
facets, the implementation of the java facet can move to JDT. For now, it
will live in the JDT Enablement component of this Project.

In short, the approach taken is to enable gradual and controlled adoption
without asking everyone in the community to jump at the same time. :)

I hope this answered your question.

- Konstantin
Re: What's broken in natures? [message #2298 is a reply to message #2239] Mon, 27 October 2008 14:31 Go to previous messageGo to next message
Lawrence Mandel is currently offline Lawrence Mandel
Messages: 486
Registered: July 2009
Senior Member
Kosta,

Thank you for the detailed response. I especially appreciate the history,
which provides a good justification for an alternate framework.

I have another question on a different topic. I've seen a number of users
have trouble with not being able to change the Java facet even though
they've updated the required Java version on their project. Will efforts
be made for the Java faceted UI (and others like it) to understand the
existing Java settings and automatically update the selected facets as
required? Perhaps this question is more appropriate for a bug...

Lawrence
Java facet handling of compiler level prefs changes [message #2329 is a reply to message #2298] Tue, 28 October 2008 13:37 Go to previous messageGo to next message
Konstantin Komissarchik is currently offline Konstantin Komissarchik
Messages: 923
Registered: July 2009
Senior Member
Lawrence wrote:

> I've seen a number of users have trouble with not being able to change the
> Java facet even though they've updated the required Java version on their
> project. Will efforts be made for the Java faceted UI (and others like it)
> to understand the existing Java settings and automatically update the
> selected facets as required? Perhaps this question is more appropriate for a
> bug...

I would definitely be interested in hearing more about these scenarios
that you witnessed. Java facet already contributes a validator that checks
for the situation where java facet version doesn't match java compiler
level. If a mismatch is detected, an error is added to the problems view:

Java compiler level does not match the version of the install Java project
facet.

Two quick fixes are provided:

Change Java project facet version to Java 1.4
Change Java compiler level to 1.6

In the above example I created a project and manually changed the compiler
level from 1.4 to 1.6.
Re: Java facet handling of compiler level prefs changes [message #2625 is a reply to message #2329] Wed, 31 December 2008 21:58 Go to previous messageGo to next message
Gary is currently offline Gary
Messages: 10
Registered: July 2009
Junior Member
Happy New Year!!!


FYI: I am using Eclipse v3.4.1 (Ganymede). I am working in a Dynamic Web
Project. When I change the Java project facet to 1.4, I get the error:

"Dynamic Web Module 2.5 requires Java 5.0 or newer"

.... so it looks like the solution mentioned does not work in the Ganymede.

Is this still a bug?

Thank you
Gary
Re: Java facet handling of compiler level prefs changes [message #2653 is a reply to message #2625] Fri, 02 January 2009 17:15 Go to previous message
Gary is currently offline Gary
Messages: 10
Registered: July 2009
Junior Member
Never mind... I figured this out. I had to set the JRE in the "Runtime
Environment" window to JRE 6 in my Geronimo v2.1 installation. I was able
to do this while in Eclipse

Thank you
Gary
Re: What's broken in natures? [message #571354 is a reply to message #2207] Fri, 24 October 2008 18:35 Go to previous message
Konstantin Komissarchik is currently offline Konstantin Komissarchik
Messages: 923
Registered: July 2009
Senior Member
Good question!

Natures are extremely simple. The original use case for natures is to
basically serve as a flag modeling something akin to a project type. The
good UI that you speak of for adding and removing natures would need a lot
more information and callable behaviors than is provided by the natures
API. The limitations make sense since the natures API was written with
simple use cases in mind and natures were not intended to be
fully-described and self-supporting.

Let's look at one API as an example. The IProjectNature interface has
configure() and deconfigure() methods that nature authors get to
implement. These methods get called when a nature is added to or removed
from a project. Notice how those methods take no parameters. That means it
is not possible to pass in a configuration object that would let the user
have input as these actions take place. So what, you say. We've solved
that problem before. We will just create IProjectNature2 with variants of
those two methods capable of taking parameters. Problem solved. Not quite.
The issue is that there are many natures already implemented in various
Eclipse projects and commercial products. For years nature authors have
been working around this API limitation. The most common work-around is to
move most of the interesting code outside these two methods. In the case
of the configure() method all of this code is embedded in various project
creation wizards and "Enable function X" menu actions. The configure()
implementations themselves typically are not sufficient to properly
configure the project and often rely on stuff happening prior to the
nature getting added. For the most part, the deconfigure() methods are
implemented as no-ops. Since there is no UI for the user to remove a
nature, why bother with implementing this method?

In short, the biggest obstacle to making it possible for users to add and
remove natures are the existing nature implementations. Practically every
nature out there would be broken behaviorally if UI for adding and
removing natures was introduced.

Ok. So we need a more gradual phased-in approach that doesn't give
everyone in the Eclipse Community a massive coronary. Enter facets. We
started from scratch and designed the facets API together with UI for
adding and removing them. The framework evolved over the years to cover a
lot of different use cases that adopters brought to the table. Since
making a project faceted is controlled by a flag (a nature, actually), the
project wizard owner get to opt-in when they are ready. Part of the opt-in
process is gathering all of the code that strewn about in various wizards
and actions and writing a facet based on that code. It often make sense to
retain any existing natures for backwards compatibility, but facets would
now control adding and removing them.

The pattern of wrapping a facet around a nature is particularly important
when you consider the case of an Eclipse Project re-using another
Project's functionality. We need a solution for enabling a downstream
Project to transition to facets while the upstream Project is not ready
yet and continues using natures. The original example of this is WTP's
re-use of JDT's java nature for various WTP projects like Dynamic Web
Project. It was necessary for WTP to move forward with creating faceted
projects without depending on JDT adopting the same approach and making
requisite changes to it's code base. The facets architecture allowed us in
WTP to implement a java facet on our own that wraps JDT's java nature.
JDT's Java Project (as well as all the other projects that re-use java
nature) continue to work as before while WTP users start benefiting from
the richer experience provided by facets. If JDT ever decided to adopt
facets, the implementation of the java facet can move to JDT. For now, it
will live in the JDT Enablement component of this Project.

In short, the approach taken is to enable gradual and controlled adoption
without asking everyone in the community to jump at the same time. :)

I hope this answered your question.

- Konstantin
Re: What's broken in natures? [message #571410 is a reply to message #2239] Mon, 27 October 2008 14:31 Go to previous message
Lawrence Mandel is currently offline Lawrence Mandel
Messages: 486
Registered: July 2009
Senior Member
Kosta,

Thank you for the detailed response. I especially appreciate the history,
which provides a good justification for an alternate framework.

I have another question on a different topic. I've seen a number of users
have trouble with not being able to change the Java facet even though
they've updated the required Java version on their project. Will efforts
be made for the Java faceted UI (and others like it) to understand the
existing Java settings and automatically update the selected facets as
required? Perhaps this question is more appropriate for a bug...

Lawrence
Java facet handling of compiler level prefs changes [message #571432 is a reply to message #2298] Tue, 28 October 2008 13:37 Go to previous message
Konstantin Komissarchik is currently offline Konstantin Komissarchik
Messages: 923
Registered: July 2009
Senior Member
Lawrence wrote:

> I've seen a number of users have trouble with not being able to change the
> Java facet even though they've updated the required Java version on their
> project. Will efforts be made for the Java faceted UI (and others like it)
> to understand the existing Java settings and automatically update the
> selected facets as required? Perhaps this question is more appropriate for a
> bug...

I would definitely be interested in hearing more about these scenarios
that you witnessed. Java facet already contributes a validator that checks
for the situation where java facet version doesn't match java compiler
level. If a mismatch is detected, an error is added to the problems view:

Java compiler level does not match the version of the install Java project
facet.

Two quick fixes are provided:

Change Java project facet version to Java 1.4
Change Java compiler level to 1.6

In the above example I created a project and manually changed the compiler
level from 1.4 to 1.6.
Re: Java facet handling of compiler level prefs changes [message #571759 is a reply to message #2329] Wed, 31 December 2008 21:58 Go to previous message
Gary is currently offline Gary
Messages: 10
Registered: July 2009
Junior Member
Happy New Year!!!


FYI: I am using Eclipse v3.4.1 (Ganymede). I am working in a Dynamic Web
Project. When I change the Java project facet to 1.4, I get the error:

"Dynamic Web Module 2.5 requires Java 5.0 or newer"

.... so it looks like the solution mentioned does not work in the Ganymede.

Is this still a bug?

Thank you
Gary
Re: Java facet handling of compiler level prefs changes [message #571789 is a reply to message #2625] Fri, 02 January 2009 17:15 Go to previous message
Gary is currently offline Gary
Messages: 10
Registered: July 2009
Junior Member
Never mind... I figured this out. I had to set the JRE in the "Runtime
Environment" window to JRE 6 in my Geronimo v2.1 installation. I was able
to do this while in Eclipse

Thank you
Gary
Previous Topic:Faceted Project Framework Creation Review
Next Topic:WTP Transition Plan
Goto Forum:
  


Current Time: Thu Apr 17 08:45:13 EDT 2014

Powered by FUDForum. Page generated in 0.19028 seconds