[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [dali-dev] CVS reorg

I mentioned it in last weeks' status meeting, but will mention to this list also ...

care is needed in nesting features. This causes a very tight coupling of the features that might not be warranted. It can cause complications when doing updates, or when adopters "mix" the features in slightly different ways.

And I say that knowing that we do it wrong in many other places in WTP. I actually have a plan item to "flatten" some of our other feature hierarchies.

If the goal is to make things easier for end users when installing from a p2 repository, then maybe we can do more with nested categories. But I think we should have one feature "include" another only when there is a very strong relationship between them, where they pretty much both have to be built and distributed together. The best example is probably how an SDK feature really should include its corresponding code-only feature.

Also, we can make things very easy for users at install time just by distributing/installing them all and requiring no choice from user. But then, we should also do more the "capabilities" so users (or adopters) could "turn off" some of the functionality, if they didn't want to see it "clutter" up their UI.

So, I don't know the right answer (if there is one) but just wanted to encourage plenty of discussion, thought, and community feedback before getting too far along in any specific plans to nest.


From:        Neil Hauge <neil.hauge@xxxxxxxxxx>
To:        dali-dev@xxxxxxxxxxx
Date:        09/29/2010 06:02 PM
Subject:        Re: [dali-dev] CVS reorg
Sent by:        dali-dev-bounces@xxxxxxxxxxx

Currently EclipseLink can be used as an all in one, or specific bundles can be used to make a more customized install.  So you can just get one or the other, although I think the typical case is to still use the eclipselink.jar.

We also have 2 consumers for our packaging, which includes users and adopters.  We have adopter requirements to allow for easy removal of JAXB related functionality (as well as EclipseLink related functionality), so at this level we will need to have a separate feature for JAXB functionality.  We could have layered features to provide better package options for users.  Something like:

Dali JPA Feature
-> Dali JPA Generic Feature
-> Dali JPA EclipseLink Feature

Dali JAXB Feature
-> Dali JAXB Generic Feature
-> Dali JAXB EclipseLink MOXy Feature


On 9/29/2010 2:50 PM, Brian Vosburgh wrote:

I guess it depends on what a user typically wants:
Would s/he want to pick our EclipseLink "product" and it comes with everything?
I guess this would depend some on how EclipseLink itself is packaged? Can you
get just EclipseLink JPA? Just EclipseLink JAXB? If you can't, then it would
make no sense for us to break up our EclipseLink support. (?) I don't have
strong feelings (yet :) ), but it just seems like this is a reversion of what
we just did; or am I confused? I can't remember how exactly we changed
the package names then.... (And the old packages were not archived on
CVS. Or I can't find them.)

On 09/29/10 14:08, Neil Hauge wrote:

We discussed this briefly this morning (unfortunate that you had a conflict) .  The best documentation of this I could find was in these notes:


Not much related to o.e.jpt.eclipselink there, but thinking about it now, it seems that the 2 main distinctions in our code base will be ORM and OXM (JPA and JAXB).  Generic or EclipseLink seems like a secondary distinction, below the two base components, but we can discuss further here and/or tomorrow morning.


On 9/29/2010 1:29 PM, Brian Vosburgh wrote:

I thought we discussed a while back that all the EclipseLink code would be under
o.e.jpt.eclipselink and not spread across various other branches. It almost feels like
this is doing just the opposite of what we did as a result of that discussion?

On 09/29/10 10:40, Paul Fullbright wrote:

 A new plugin:
has been added, and an existing plugin:
has been renamed to:

Those and the existing plugins:
have been added under a new "jaxb" component under org.eclipse.jpa in CVS.

The existing jaxb plugins under the "jpa" component have been replaced with stub projects.

dali-dev mailing list

dali-dev mailing list

dali-dev mailing list

dali-dev mailing list