imo we should analyze which modules would make sense as stand-alone modules. if there are 2+ of them, we should really think about such a modularization. we might get new users who just use some of the stand-alone modules instead of using something completely different (e.g. because they don't like to use trinidad as a whole).
i'm fine with starting a new thread. regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/7/21 Matthias Wessendorf <[email protected]> > On Wed, Jul 21, 2010 at 2:51 PM, Gerhard Petracek > <[email protected]> wrote: > > hi, > > an optional trinidad-support module for codi, orchestra,... could use the > > special events of trinidad. -> these trinidad-support modules would have > a > > dependency to trinidad (and not the other way round). if users don't use > the > > support module for trinidad, the std. behavior of these frameworks would > be > > used as fallback. > > I am fine with that, in parallel. At least CODI sounds interesting (for > me). > > > i'm not talking about one jar file. > > internally we would have several modules (e.g. a stand-alone skinning > > module). > > -> we can release the fine grained modules as well as trinidad-api and > > trinidad-impl. > > (we would need special modules just for packaging trinidad-api and > > trinidad-impl jar files via the shade plugin of maven.) > > -> some users would use the fine grained modules and the rest continues > to > > use trinidad-api and trinidad-impl (like today). > > hrm, is that really needed? > Not sure that there is a lot of benefit from it, beside the extra work... > On other subprojects, like CODI itself, it does make sense, since it > is more modular. > > heck, this is a different topic, let's discuss that on a different > (->new) thread :) > > -Matthias > > > regards, > > gerhard > > http://www.irian.at > > > > Your JSF powerhouse - > > JSF Consulting, Development and > > Courses in English and German > > > > Professional Support for Apache MyFaces > > > > > > 2010/7/21 Matthias Wessendorf <[email protected]> > >> > >> On Wed, Jul 21, 2010 at 2:02 PM, Gerhard Petracek > >> <[email protected]> wrote: > >> > hi mark, > >> > nobody said that it would harm (at least i'm not aware of technical > >> > issues). > >> > (maybe some people would use it even though they shouldn't - e.g. > >> > because > >> > they have an alternative which should be used in their application/s.) > >> > furthermore, i agree with martin - most projects are using (or will > use) > >> > one > >> > of the mentioned frameworks. > >> > >> a lot != most :) > >> > >> > the questions are: > >> > who would use this feature? > >> > - new projects? i don't think so. > >> > >> possible.. > >> > >> > - existing projects? > >> > >> yes, why not? > >> > >> > would they upgrade to a new version of trinidad just for using this > >> > feature? > >> > >> pretty soon, I hope end of July, there will be a new release > (2.0.0-beta), > >> since > >> the JSF2 and also its (jsf2) ajax bridge is kinda stable, now > >> > >> > maybe it's the right time to discuss our plans for the future of > >> > trinidad. > >> > >> I know that - at least my goal - is finishing on the JSF 2.0 uptake. > >> not sure if I am too thrilled about forcing hard dependencies to > >> CDI/Spring > >> > >> but I said before, that we could layout an *independent* API for > something > >> like window/event systems and let submodules implement with APIs they > >> want, > >> e.g. CDI or more heavy-weight: Spring > >> > >> > (at least if we should use the maven shade plugin for modularizing > >> > trinidad. > >> > in such a case we could also provide an all-in-one package via special > >> > modules. so users won't see any difference, if they prefer the > existing > >> > monolithic package.) > >> > >> for runtime dependency its is trinidad-api and trinidad-impl; > >> wanna pack that into one jar? > >> > >> > regards, > >> > gerhard > >> > http://www.irian.at > >> > > >> > Your JSF powerhouse - > >> > JSF Consulting, Development and > >> > Courses in English and German > >> > > >> > Professional Support for Apache MyFaces > >> > > >> > > >> > 2010/7/21 Mark Struberg <[email protected]> > >> >> > >> >> Hmm difficult topic. > >> >> > >> >> Please allow me a few questions: > >> >> > >> >> a.) Trinidad components would still work with using either Orchestra > >> >> conversations or CODI? > >> >> b) You are not relying on other components or the users using your > >> >> conversation > >> >> stuff if they don't like? > >> >> c) if the user doesn't make use of this feature, it will not pollute > >> >> the > >> >> viewRoot or cause heavy performance hits? > >> >> > >> >> If all this is ok, then there is imo no argument against adding it to > >> >> Trinidad. > >> >> This doesn't mean I like it either, but it doesn't hurt at least ;) > >> >> > >> >> LieGrue, > >> >> strub > >> >> > >> >> > >> >> > > >> >> >From: Gerhard Petracek <[email protected]> > >> >> >To: MyFaces Development <[email protected]> > >> >> >Sent: Wed, July 21, 2010 10:16:23 AM > >> >> >Subject: Re: [Trinidad][api]TRINIDAD-1857 Add a Map associated with > >> >> > each > >> >> > window > >> >> > > >> >> >or tab that the user is interacting with > >> >> > > >> >> >i agree with martin. > >> >> > > >> >> > > >> >> >regards, > >> >> >gerhard > >> >> > > >> >> >http://www.irian.at > >> >> > > >> >> >Your JSF powerhouse - > >> >> >JSF Consulting, Development and > >> >> >Courses in English and German > >> >> > > >> >> >Professional Support for Apache MyFaces > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> >2010/7/21 Martin Marinschek <[email protected]> > >> >> > > >> >> >Hi Matthias, > >> >> >> > >> >> >> > >> >> >>> Not everybody is using CDI and/or Spring. > >> >> >> > >> >> >>well, in the real world and a little while in the future, there is > >> >> >> not > >> >> >>many people who will not have one of these frameworks in their > >> >> >>applications. > >> >> >> > >> >> >> > >> >> >>> I think, on long term we may want one clean and independent API, > >> >> >>> where > >> >> >>> all these projects offer an implementation for a window/event > >> >> >>> system: > >> >> >>> -CODI > >> >> >>> -Orchestra > >> >> >>> -Trinidad > >> >> >>> -etc > >> >> >>> > >> >> >>> However, right now, Trinidad has the base already and adding a > new > >> >> >>> toolset to the belt feels kinda wrong. > >> >> >>> Again +1 on this to be inside of Trinidad. > >> >> >>> > >> >> >>> This does not mean that we could work on a better future version > of > >> >> >>> a > >> >> >>> more unified API, for this. Right? > >> >> >> > >> >> >>yes, this is what we could and what we should. Why not take this > >> >> >>addition as a reason to do this right now? If we don´t take such > >> >> >>additions as a reason to do this, what else will be our reason? > >> >> >> > >> >> >>best regards, > >> >> >> > >> >> >>Martin > >> >> >> > >> >> >>-- > >> >> >> > >> >> >> > >> >> >>http://www.irian.at > >> >> >> > >> >> >>Your JSF powerhouse - > >> >> >>JSF Consulting, Development and > >> >> >>Courses in English and German > >> >> >> > >> >> >>Professional Support for Apache MyFaces > >> >> >> > >> >> > > >> >> > >> >> > >> >> > >> > > >> > > >> > >> > >> > >> -- > >> Matthias Wessendorf > >> > >> blog: http://matthiaswessendorf.wordpress.com/ > >> sessions: http://www.slideshare.net/mwessendorf > >> twitter: http://twitter.com/mwessendorf > > > > > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf >
