Re: [dali-dev] CVS reorg

[David M Williams <david_williams@xxxxxxxxxx>]

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. 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=297398

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. 

Thanks, 
  







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


Neil


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:

http://wiki.eclipse.org/Dali_Project/Weekly_Meeting/August_20_2010

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.

Neil



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: 
    org.eclipse.jpt.jaxb.core 
has been added, and an existing plugin: 
    org.eclipse.jpt.eclipselink.jaxb.core.schemagen 
has been renamed to: 
    org.eclipse.jpt.jaxb.eclipselink.core.schemagen 

Those and the existing plugins: 
    org.eclipse.jpt.jaxb.ui 
    org.eclipse.jpt.jaxb.core.schemagen 
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@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dali-dev



_______________________________________________
dali-dev mailing list
dali-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dali-dev




_______________________________________________
dali-dev mailing list
dali-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dali-dev

_______________________________________________
dali-dev mailing list
dali-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dali-dev