I think that basically we all know that your approach would be the
best, John. It is just a matter of getting it to work automatically.
Is there any chance to do so?
regards,
Martin
On 11/2/05, John Fallows <[EMAIL PROTECTED]> wrote:
> On 11/2/05, Sean Schofield <[EMAIL PROTECTED]> wrote:
> > >
On 11/2/05, Sean Schofield <[EMAIL PROTECTED]> wrote:
> Agreed. However, the reason is out of date because the projects are now> separated (as they should be).Separating the projects makes it easier for someone to use Tomahawkstuff with the RI. So that is a major plus.
I'm glad we agree on this
> Agreed. However, the reason is out of date because the projects are now
> separated (as they should be).
Separating the projects makes it easier for someone to use Tomahawk
stuff with the RI. So that is a major plus. I don't think it makes
our reasoning out of date because the same group of
On 10/25/05, Sean Schofield <[EMAIL PROTECTED]> wrote:
I don't think we will enjoy keeping some 100+ classes in sync acrosstwo different packages. Nor will I think that users who try to supplya patch who enjoy this. We couldn't use svn externals either b/c thefiles need to have different package
I don't think we will enjoy keeping some 100+ classes in sync across
two different packages. Nor will I think that users who try to supply
a patch who enjoy this. We couldn't use svn externals either b/c the
files need to have different package statements.
The whole point of the shared code is t
@Manfred:
putting the shared classes in the endorsed directory is not the final
solution - it would mean that those classes are taken up for the
implementation as well.
You might need a different version for the implementation and for tomahawk!
regards,
Martin
On 10/25/05, John Fallows <[EMAIL
Hey Sean,
On 10/24/05, Sean Schofield <[EMAIL PROTECTED]> wrote:
> I agree the shared classes is the most important issue to focus on. I
> also agree -1 on repackaging them. We would live to regret that
> decision.
Your current position is clear, but not your rationale. Can you
please elabotat
Unfortunately that is not so easy either. I cannot go into details
about the testing process due to a Nondisclosure Agreement that was
signed. So you will not be able to look at it and we can discuss the
contents of the test.
Sorry but ASF does not control the TCK, Sun does, and so we need to
pl
Indeed, I have no idea.
But just because it is so complicated, we should make an effort to automate it.
Where can we find the test? This discussion would probably be more fruitful if I had any idea what I was talking about. Like this, if feels like work ;-).
On 24 Oct 2005, at 9:19, Martin Mari
Manfred,
I agree the shared classes is the most important issue to focus on. I
also agree -1 on repackaging them. We would live to regret that
decision.
I agree that changing what's in the endorsed lib dir would fix the
problem and ultimately when users have a problem with JBoss, etc. they
go t
Hi all,
This thread is a little bit overloaded with issues and suggestions in
the meantime. So I do not want to make thinks worse and only pick out
the (IMO) most important point, that really has a major impact on
future releases: the shared classes repackage issue.
Regarding shared classes: One id
> Ok, so maybe this is the thread for these comments I have sitting on
> for some time.
> _Please_ don't be offended, we _do_ appreciate the work and the results
> of the MyFaces contributors and the whole community.
>
> But you definitely have a release problem.
>
> 3 anecdotal examples: the ages
> However, since there is duplication, then upgrading either of these
> (Runtime / Tomahawk) in a deployed environment independently would
> cause the shared classes to be upgraded as well, for both of the
> projects. This assumes the classpath is setup to place the newest JAR
> last, which might
@Jan:
automate JSF compatibility tests: I severly doubt this will be
automatable. You don't know how complicated this thing is to be run
even manually ;)
regards,
Martin
On 10/23/05, ir. ing. Jan Dockx <[EMAIL PROTECTED]> wrote:
>
> On 23 Oct 2005, at 3:58, John Fallows wrote:
>
> > On 10/22/05
It is both intuitive and automatic.
you take build/build.xml and call the target dist-all. That's it.
Anyways, it would be great if someone starts introducing Maven - then
we can compare and finally decide which one is better. The thing is
that none of us has too much experience with Maven so far
On 23 Oct 2005, at 3:58, John Fallows wrote:
On 10/22/05, ir. ing. Jan Dockx <[EMAIL PROTECTED]> wrote:
Here are some humble suggestions from our experience:
[…]
3) Automate the release procedure; use maven
Yes, I know this was discussed 3 months ago. But it is clear that the
release procedu
On 10/22/05, ir. ing. Jan Dockx <[EMAIL PROTECTED]> wrote:
> Here are some humble suggestions from our experience:
>
>
> 1) Split the release schedules for the different parts
>
> myfaces-api, myfaces-impl, and indeed, myfaces-shared, and tomahawk,
> need to be on different release tracks, and have
On 10/22/05, Martin Marinschek <[EMAIL PROTECTED]> wrote:
> It is a realistic scenario if you think about JBoss including MyFaces
> (the implementation) 1.1.0 as a standard somewhere in the server - and
> you want to upgrade to 1.1.1 in your webapp for the newest and best in
> the tomahawk componen
Ok, so maybe this is the thread for these comments I have sitting on for some time.
_Please_ don't be offended, we _do_ appreciate the work and the results of the MyFaces contributors and the whole community.
But you definitely have a release problem.
3 anecdotal examples: the ages it took from 1
It is a realistic scenario if you think about JBoss including MyFaces
(the implementation) 1.1.0 as a standard somewhere in the server - and
you want to upgrade to 1.1.1 in your webapp for the newest and best in
the tomahawk components.
regards,
Martin
On 10/22/05, Keijo Nurmes <[EMAIL PROTECTED
Granted but is it a realistic scenario?
Does someone want to deploy in same container for example
myfaces-api.jar 1.1.0
myfaces-impl.jar 1.1.0
tomahawk.jar 1.1.1
would't it be safer just compile custom build from sources.
I dont know, newer happened to me.
It just seemed the most natur
It's not quite the same.
with John's approach, you can use the tomahawk library in whatever
version with whatever version of the implementation you would like to
use. Partticularly, the shared library can co-exist in two different
versions peacefully.
With Keijo's approach, you are locked in to _
hear hear! (or is it here here? ;-) )
On 22 Oct 2005, at 12:51, Keijo Nurmes wrote:
Greetings to everyone.
There is also a third choice . One could separate shared code to its own jar . (myfaces-shared.jar)
In that way users can decide what to use.
a) All in one
myfaces-all.jar (Contains to
Greetings to everyone.
There is also a third choice . One could separate shared code to its
own jar . (myfaces-shared.jar)
In that way users can decide what to use.
a) All in one
myfaces-all.jar (Contains tomahawk, impl, api, shared and optionally
sandbox)
b) Separated pure myfaces
myf
Hi Everyone,
On 10/19/05, Martin Marinschek <[EMAIL PROTECTED]> wrote:
> Well, if we could do b) somewhat automatically, this would be great.
>
> John Fallows had proposed something like this for the shared classes
> of Apache MyFaces - to make sure that Tomahawk and the impl always use
> the corr
In my non-committer-therefore-not-really-relevant-opinion,
EscapeUtils.escapeJavaScript() is a useful method,
and it's reasonable to debate whether that is a good
reason for a dependency; but EqualsBuilder and
HashCodeBuilder are massively lame, and adding a
dependency on commons-lang to get *them
Werner Punz wrote:
The main problem I see is if there is some kind of version interface
break, you
could end up with two different incompatible versions.
How do the commons people handle that.
I recently had a very similar situation, I ended up giving the
commons-http with all its dependencies (
Sean Schofield wrote:
>>@Sean: how come you say we did avoid a dependency on commons-lang for
>>that long? I didn't have the feeling that we where trying to achieve
>>this, correct me if I am wrong...
>
>
> Well its just the less jars the better that's all. As Werner says
> though commons-lang i
age should be updated to reflect that we need to
have commons-lang-2.1.jar.
- Brendan
-Original Message-
From: Sean Schofield [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 18, 2005 10:08 PM
To: MyFaces Development
Subject: Re: RC3: dependency on commons-lang
I agree with Bill on that o
> @Sean: how come you say we did avoid a dependency on commons-lang for
> that long? I didn't have the feeling that we where trying to achieve
> this, correct me if I am wrong...
Well its just the less jars the better that's all. As Werner says
though commons-lang is pretty standard. I use it in
Well, if we could do b) somewhat automatically, this would be great.
John Fallows had proposed something like this for the shared classes
of Apache MyFaces - to make sure that Tomahawk and the impl always use
the correct implementation of the shared classes.
John - I think this is the time at whi
Simon Kitching wrote:
> Hi guys,
>
> Well, you should check out some of the email discussions held on
> commons-dev about this. The general conclusion was that even commons
> components should avoid dependencies on other commons components where
> feasable.
>
Well commons are absolute base libs,
Hi Simon,
I thought we were happy to get away from the copy-and-paste paradigma
of reusing code - as you pointed out, there are now three classes used
of commons-lang.
What happens if a bug-fix is introduced in these classes, am I
supposed to go through the source code once more and copy them ove
Hi guys,
Well, you should check out some of the email discussions held on
commons-dev about this. The general conclusion was that even commons
components should avoid dependencies on other commons components where
feasable.
Obviously copying large chunks of another library isn't a good idea.
I agree with Bill on that one. I was suprised to see that this
dependency had been introduced (after we had avoided it for so long)
but I don't think its a big deal.
sean
On 10/18/05, Bill Dudney <[EMAIL PROTECTED]> wrote:
> I respectfully disagree, there is no way I want us copying
> functional
I respectfully disagree, there is no way I want us copying
functionality from commons-lang into myfaces.
-bd-
On Oct 18, 2005, at 6:47 PM, Simon Kitching wrote:
Hi,
Class org.apache.myfaces.custom.calendar.HtmlCalendarRenderer.java
has had a dependency on commons-lang added. This means th
Hi,
Class org.apache.myfaces.custom.calendar.HtmlCalendarRenderer.java has
had a dependency on commons-lang added. This means that my app which
previously worked fine now fails with a NoClassDefFoundError.
The dependency was introduced by r289859 (mmarinschek) on 2005-09-18.
I would recommen
37 matches
Mail list logo
