+1
toplevelprojectname-sublevelprojectname.jar is a good suggestion!
Eventually we should rename myfaces-all.jar to
myfaces-api-impl-tomahawk.jar as well, so as to ensure users know what
is in there ;)
regards,
Martin
On 9/27/05, Manfred Geiler [EMAIL PROTECTED] wrote:
I totally agree with
ROTFL
2005/9/27, Martin Marinschek [EMAIL PROTECTED]:
Eventually we should rename myfaces-all.jar to
myfaces-api-impl-tomahawk.jar as well, so as to ensure users know what
is in there ;)
--
Mathias
-Original Message-
I don't see how excluding sandbox stuff from myfaces-all.jar will take
anything away from our users. If you want to use the sandbox stuff
you just need two jars: myfaces-all.jar and sandbox.jar.
-/Original Message-
true
-Original Message-
I like
Hello Sean,
It's not a question of laziness.
As said before, having one common jar is very useful when you develop a component there, and when it's moved in production later.
I don't agree excluding it just because there was an unfortunate bug that hasn't been fixed in time for an important
You're right, this is how it is right now :
urihttp://myfaces.apache.org/tomahawk/uri, with recommended prefix t: for Tomahawk
urihttp://myfaces.apache.org/sandbox/uri, with recommended prefix s: for Sandbox
urihttp://myfaces.apache.org/all/uri, with recommended prefix x: for All components
And the generation of the myfaces-all TLD is confusing for several
reasons. This adds yet another way to reference a tomahawk component
from the already dizzying array of choices.
So tomahawk can be referenced using:
http://myfaces.apache.org/extensions
http://myfaces.apache.org/tomahawk
ff
Issue 1: creating a one tld comprises them all tld file:
@Sylvain: Sean is right here! we can keep the sandbox component in the
sandbox tld, but move it over to tomahawk.
So you won't have any issues with moving the components over, right?
Issue 2: making an exception for sandbox in the build:
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
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
It also seems ok to me, I think that it is a good consensus and having
the tld separated is enough to me...
Bruno
2005/9/26, Bill Dudney [EMAIL PROTECTED]:
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
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
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
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
+1 on the proposal as outlined by Sean here.
I don't agree that its that important to get sandbox out of myfaces-
all people would know the difference with a separate tld but I'm also
fine with leaving it as a separate jar file.
TTFN,
-bd-
On Sep 26, 2005, at 1:28 PM, Sean Schofield
Bill,
We need to get it it out of myfaces-all.jar if we don't want to mix
the faces-config.xml with tomahawk and sandbox stuff (which IMO we
don't want to do.)
sean
On 9/26/05, Bill Dudney [EMAIL PROTECTED] wrote:
+1 on the proposal as outlined by Sean here.
I don't agree that its that
-
From: Sean Schofield [mailto:[EMAIL PROTECTED]
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
Sean,
If you strongly believe in this, couldn't we have 2 dist-all ?
One that would drop the sandbox stuffs, and another one (whatever the name) that would be just a copy of the current one.
I don't want to get in the way of the release process, but I still believe that this all in one jar
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
,
Kalle
-Original Message-
From: Sean Schofield [mailto:[EMAIL PROTECTED]]
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
Sylvain,
We wouldn't keep things in sandbox forever. I was just making the
point that you could download the latest myfaces version and still use
whatever version of sandbox you are using in your
development/production system.
You eventually have to do the search and replace as Martin is saying
I agree.
On Mon, 2005-09-26 at 14:47 -0600, Bill Dudney wrote:
Martin's point seals it for me.
Lets keep sandbox, tobago separate. The last thing we want is
clashing tag names :-)
I am also against a 'special target'. I'd prefer if we could address
this during the move to maven2
OK thanks for the compromise Sylvain. I will start tweaking the build
file shortly.
sean
On 9/26/05, Sylvain Vieujot [EMAIL PROTECTED] wrote:
I agree.
On Mon, 2005-09-26 at 14:47 -0600, Bill Dudney wrote:
Martin's point seals it for me.
Lets keep sandbox, tobago separate. The last
On 9/26/05, Sylvain Vieujot [EMAIL PROTECTED] wrote:
You're right, this is how it is right now :
urihttp://myfaces.apache.org/tomahawk/uri, with recommended prefix t: for Tomahawk
urihttp://myfaces.apache.org/sandbox/uri, with recommended prefix s: for Sandbox
Well,
we came from this merging approach, and decided differently now.
the question is - do a a merge of faces-config.xml - or force the
users to have myfaces-all.jar and sandbox.jar in his library
directory.
The second option seems to be more simple!
regards,
Martin
On 9/27/05, Craig
On 9/26/05, Martin Marinschek [EMAIL PROTECTED] wrote:
Well,we came from this merging approach, and decided differently now.the question is - do a a merge of faces-config.xml - or force theusers to have myfaces-all.jar and sandbox.jar in his librarydirectory.
The second option seems to be more
That approach makes sense if you decide not to include the sandbox
components. But, my basic advice still stands ... if you ever *do* combine
two component tag libraries into a single JAR file, go ahead and merge the
faces-config.xml entries, but *don't* combine the TLDs. That only creates
On 9/26/05, Sean Schofield [EMAIL PROTECTED] wrote:
That approach makes sense if you decide not to include the sandbox components.But, my basic advice still stands ... if you ever *do* combine two component tag libraries into a single JAR file, go ahead and merge the
faces-config.xml entries, but
I don't see how excluding sandbox stuff from myfaces-all.jar will take
anything away from our users. If you want to use the sandbox stuff
you just need two jars: myfaces-all.jar and sandbox.jar.
Putting everything in myfaces-all.jar just allows you to be lazy and
use one jar and one TLD. That
+1!
regards,
Martin
On 9/23/05, Manfred Geiler [EMAIL PROTECTED] wrote:
+1
Manfred
2005/9/23, Sean Schofield [EMAIL PROTECTED]:
Apparently there is a problem with faces-config.xml in myfaces-all.jar
of the current release. All of this confusion seems to be coming from
the fact that
As for the relases, you're right.
But I also see great value still having a single jar with everything.
I allows seamless migration from the sandbox to tomahawk.
As such, it allows us to really test the sandbox.
Otherwise, I'm afraid the components in the sandbox will be really less used and
I agree that maybe we should exclude the sandbox by default. Other
than that, I disagree. I don't see any real advantage of mixing the
sandbox stuff into the other jars. I think it should be kept separate
and for those who want to use sandbox stuff before its released, just
add the extra
I am not sure about that... if you do it too easy people will begin to
use sandbox components in their production applications, and sandbox
components are unstable by nature. It is better to promote a sandbox
component to tomahawk once is mature, so people can use it in their
applications. IMO,
I'm not talking about shipping this in the releases, but for those that use the head, I think it's a good think as it'll improve the code of the sandbox.
And those that'll use it will do it knowingly.
So, I don't see this as a risk. Rather as a very useful option for the developers and
Apparently there is a problem with faces-config.xml in myfaces-all.jar
of the current release. All of this confusion seems to be coming from
the fact that sandbox is in myfaces-all.jar in the nighlty but not the
release. We have the -Dskip.sandbox option and a bunch of other hacks
in the build
Agreed,
-bd-
On Sep 23, 2005, at 11:20 AM, Sean Schofield wrote:
Apparently there is a problem with faces-config.xml in myfaces-all.jar
of the current release. All of this confusion seems to be coming from
the fact that sandbox is in myfaces-all.jar in the nighlty but not the
release. We
sure!
+1 on that.
thanks for catching this Sean!
-Matthias
On 9/23/05, Sean Schofield [EMAIL PROTECTED] wrote:
Apparently there is a problem with faces-config.xml in myfaces-all.jar
of the current release. All of this confusion seems to be coming from
the fact that sandbox is in
From Sean sent directly to me:
@Bill,
About the branch you created, was it off the trunk or the 1_1_0 tag?
On 9/23/05, Matthias Wessendorf [EMAIL PROTECTED] wrote:
sure!
+1 on that.
thanks for catching this Sean!
-Matthias
On 9/23/05, Sean Schofield [EMAIL PROTECTED] wrote:
+1
Manfred
2005/9/23, Sean Schofield [EMAIL PROTECTED]:
Apparently there is a problem with faces-config.xml in myfaces-all.jar
of the current release. All of this confusion seems to be coming from
the fact that sandbox is in myfaces-all.jar in the nighlty but not the
release. We have the
39 matches
Mail list logo
