myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Marinschek <martin.marinsc...@gmail.com>
Subject Re: [proosal] Changes to sandbox
Date Mon, 26 Sep 2005 20:26:09 GMT
One more reason against the one-for-all tld file:

imagine we get in the tobago, adffaces, etc. subprojects - what if
they both include a tag named xxx...

If we lump all the tld files together (and if we follow our reasoning
so far, we should include those subprojects in the common tld file as
well, not only sandbox and tomahawk), then we might get name
conflicts. Not a promising outlook!

Thing is I rethought about leaving the sandbox components in the
sandbox tld, and this is not promising, either... Welcome maintenance
nightmare!

@Sylvain, wouldn't it be easy to do a search-replace from sbx: to t:
to convert your projects from sandbox to tomahawk? That's just one
call in your IDE, right?

regards,

Martin


On 9/26/05, Korhonen, Kalle <kkorhone@cisco.com> wrote:
> +1 and amen to that. IMHO, sandbox is a separate component lib not yet
> part of MyFaces, if you want to use, include its lib and declare a
> separate TLD. If you don't want to do that, wait till the components are
> accepted as part of official MyFaces.
>
> My 2 cents,
> Kalle
>
> > -----Original Message-----
> > From: Sean Schofield [mailto:sean.schofield@gmail.com]
> > Sent: Monday, September 26, 2005 12:28 PM
> > To: MyFaces Development
> > Subject: Re: [proosal] Changes to sandbox
> >
> > Let's make sure we are on the same page here (some stuff I
> > read in Sylvain's reply leads me to believe we are
> > interpreting Martin's suggestion differently.)
> >
> > Here is a new proposal ...
> >
> > 1.) Remove any reference to sandbox from myfaces-all.jar.
> > Zero traces of sandbox in myfaces-all.jar.  This means no
> > faces-config, no TLD (including the all TLD) and no class files.
> >
> > 2.) Include sandbox.jar in both the nightly and release
> > builds.  This means that there will be no more
> > "-Dskip.sandbox=true" and that the sandbox directories will
> > always be available when building.  The sandbox.jar will
> > contain its own TLD and class files.
> >
> > That's how I understood Martin's proposal.  Either way this
> > is what I am proposing now.  I am prepared to compromise by
> > including sandbox stuff in the distro but my position is that
> > it should not be part of all and that we shouldn't sandbox
> > stuff in with the TLD or faces-config.xml for tomahawk.
> >
> > sean
> >
> > On 9/26/05, Sylvain Vieujot <svieujot@apache.org> wrote:
> > >  One more thing about those TLDs.
> > >
> > >  I find that having one big tld for each project is quite
> > bad, as it's
> > > hard to read and to maintain. It also promotes commit
> > conflicts when 2
> > > developer are working concurrently on different components.
> > >  Maybe a better approach would be to have tld snipsets in each
> > > component's directory, and to generate each tld in the
> > build process.
> > >
> > >  Any thoughts about this ?
> > >
> > >  Sylvain.
> > >
> > >
> > >  On Mon, 2005-09-26 at 14:57 -0400, Sylvain Vieujot wrote:
> > >
> > >  I too think it makes sens to release the sandbox into the
> > myfaces-all.jar.
> > >
> > >  But if we do that, then this jar needs to contain a
> > faces-config.xml
> > > that merges the ones from tomahawk & from the sandbox (build file,
> > > merge-sandbox target).
> > >  The process for merging the faces-config.xml files & the tld is
> > > basically the same. That's why I think of it as a logical step.
> > >  I don't see how removing it will improve the code.
> > >  I didn't knew we would keep the tld fragments in the sandbox's tld
> > > once they are promoted to tomahawk, and that was the main
> > idea behind
> > > the "all tld".
> > >  But, are we sure it's the good solution to keep old components
> > > forever in the sanbox tld. It'll be increasingly hard to
> > maintain and
> > > to keep synchronized with the one of tomahawk.
> > >  So, I prefer the path of having an all in one tld, but to clearly
> > > mark it as unstable as it contains sandbox's components.
> > >
> > >  Sylvain.
> > >
> > >  On Mon, 2005-09-26 at 12:12 -0600, Bill Dudney wrote:
> > >  I like this approach too. sandbox.jar is separate but part of the
> > > release.
> > >
> > > I'm equally OK with putting the sandbox stuff into the myfaces-
> > > all.jar with a separate tld (i.e. don't do the 'all' tld).
> > Users wont
> > > be confused because its in a separate tld.
> > >
> > > I don't agree that its a lazy/not lazy thing, its just
> > simpler to have
> > > one jar file with the whole thing instead of multiple.
> > >
> > > TTFN,
> > >
> > > -bd-
> > >
> > > On Sep 26, 2005, at 11:57 AM, Sean Schofield wrote:
> > >
> > > >> Issue 2: making an exception for sandbox in the build:
> > > >>
> > > >> @Sean: Still, I think we shouldn't make an exception to
> > the build
> > > >> for the sandbox.jar when releasing - I'd say we just
> > release it as
> > > >> well, clearly indicating that this is experimental stuff.
> > > >>
> > > >
> > > > I might be persuaded to accept this route. It would certainly be
> > > > easier (we wouldn't have to worry about skipping the sandbox.)
> > > >
> > > > So we would get rid of myfaces all TLD and *not* include
> > sandbox in
> > > > myfaces-all.jar right? Everything would be in sandbox.jar
> > and thar
> > > > jar would be available in both the nightly and release builds?
> > > >
> > > > Is that what you are proposing?
> > > >
> > > > sean
> > > >
> > >
> > >
> > >
> >
>


--

http://www.irian.at
Your JSF powerhouse -
JSF Trainings in English and German

Mime
View raw message