Re: Jira rights to set an issue to 'resolved'
Just fixed that. Mark, you are now in the myfaces-committers jira group. --Manfred On Sat, Feb 5, 2011 at 20:31, Gerhard wrote: > maybe you aren't listed as committer (in jira). > @workflow: > +1 > regards, > gerhard > > http://www.irian.at > > Your JSF powerhouse - > JSF Consulting, Development and > Courses in English and German > > Professional Support for Apache MyFaces > > > > 2011/2/5 Mark Struberg >> >> Hi! >> >> I have (hopefully) resolved MYFACES-3024 but I cannot set it to 'resolved' >> with our new Jira. >> >> How does our new workflow look like? >> open -> resolved -> fixed (via bulk after a release) ? >> >> LieGrue, >> strub >> >> >> > >
Re: [VOTE] use of jul or commons logging on myfaces core 2.0
+1 for JUL On Tue, Oct 6, 2009 at 17:02, Matthias Wessendorf wrote: > +1 for JUL > > On Sat, Oct 3, 2009 at 10:41 AM, Jan-Kees van Andel > wrote: >> +1 for JUL. >> >> Jan-Kees van Andel >> >> >> 2009/10/1 Mike Kienenberger : >>> +1 for jul -- it's not ideal, but it's the standard and doesn't >>> require any dependencies. >>> >>> On Thu, Oct 1, 2009 at 12:22 PM, Grant Smith wrote: +1 java.util.logging.Logger On Thu, Oct 1, 2009 at 9:14 AM, Michael Concini wrote: > +1 for JUL > > Antonio Petrelli wrote: >> >> 2009/10/1 Werner Punz : >> Why don't you consider using SLF4J? Probably it is the same question asked over and over again, but I try anyway :-D >>> >>> That would be a dependency replacement with another. >>> Just my personal opinion regarding SLF4J >>> >> >> Don't bother, I noticed that there is a bridge with which you can use >> JUL messages with SLF4J: >> http://www.slf4j.org/legacy.html >> For a "library" like MyFaces makes perfectly sense. >> >> Antonio >> >> > > -- Grant Smith >>> >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf >
Re: jira organisation question regarding myfaces-extensions
+1 On Fri, Aug 14, 2009 at 20:58, Gerhard Petracek wrote: > hi, > > i was told that independent releases of the different subprojects wouldn't > be possible. > it seems that this information isn't correct. however, the much more > interesting part is that the constellation at trinidad is ok because these > parts belong together. that's not the case with myfaces extensions. since we > don't expect that much subprojects i think we should continue to have a jira > project for each extension project. > > furthermore, it would get a bit confusing to have one jira project and a lot > of components which don't belong together. > > if we keep the current structure, we have: > jira project: EXTVAL > component: Core > component: Property Validation > component: Bean Validation > component: Generic Support > component: Trinidad Support > > and e.g.: > jira project: EXTSCRIPT > component: Core > component: Groovy > component: [other scripting language] > > so it's a clear separation... if there are no major concerns about it, i > think we should keep it as it is. > > regards, > gerhard > > http://www.irian.at > > Your JSF powerhouse - > JSF Consulting, Development and > Courses in English and German > > Professional Support for Apache MyFaces > > > > 2009/8/14 Matthias Wessendorf >> >> On Fri, Aug 14, 2009 at 11:04 AM, Werner Punz >> wrote: >> > Werner Punz schrieb: >> >> >> >> Hello everyone while I am preparing my initial commit I noticed >> >> following. >> >> We have a subproject for extension-extval but nothing more in this >> >> regard. >> >> Which means since I cannot open my own subproject in jira I am somehow >> >> blocked. >> >> >> >> Wouldnt it be better to have the project itself reside under extensions >> >> and then have different modules for extval, groovy etc.? >> >> >> >> >> > Ok Gerhard just gave me the explanation, it has something to do with the >> > release management. >> >> I think that in Trinidad it pretty much works well. We have plugin >> releases >> and core releases. With different release notes. Not sure what he means. >> Perhaps he could jump in ?! >> >> > >> > Anyway Manfred, Matthias, can anyone of you open an extensions-groovy >> > jira >> > subprojekt for me? >> > >> > Werner >> > >> > >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf > >
Re: MyFaces Core + Trinidad + Facelets in OSGi container
+1 would be great thanks, Manfred 2009/7/9 Felix Röthenbacher : > Hi > > I recently made some modifications to MyFaces Core and MyFaces Trinidad > to get it running in an OSGi container (Equinox) together with Facelets. > > I wonder if there is any interest in adding bundle metadata to MyFaces > Core and Trinidad to make them runnable in an OSGi environment? If so, > I could finalize my modifications and submit a patch with the necessary > changes. > > Basically, the changes include: > > - adding bundle information in MANIFEST.MF (uses Maven bundle plugin) > - assure that classes and resources are loaded with proper class loaders > > The changes to MyFaces core are minor, e.g. adding a bundle activator > and small modifications to ClassUtil for class loading. > > Modifications to Trinidad comprise a systematic use of ClassLoaderUtils to > load classes and resources. Currently, often > Thread.currentThread.getContextClassLoader() is used directly, which doesn't > work well in an OSGi environment. > > WDYT? > > - Felix >
Re: [VOTE] SVN structure change (was: Re: [MyFaces CORE] SVN layout (was: Re: [source control] git and the ASF ...))
+1 thanks leonardo --Manfred On Thu, Jul 9, 2009 at 04:24, Leonardo Uribe wrote: > Hi > > Myfaces core 1.2.7 and 1.1.7 were released. So we can close this vote and > make the necessary changes. Just to note it, after reading all previous > emails the suggested layout is this: > > /trunk -> 2.0 > /branches/1.1.x > /branches/1.2.x > > If no objections I'll do the necessary changes on svn (note that to do this > change we need to update nightly build configuration and I can't help with > that). > > regards > > Leonardo Uribe > > > 2009/5/28 Simon Lessard >> >> +1 >> >> On Thu, May 28, 2009 at 2:23 AM, Matthias Wessendorf >> wrote: >>> >>> sure! >>> >>> On Thu, May 28, 2009 at 6:34 AM, Leonardo Uribe wrote: >>> > +1, but just a small suggestion. Right now I'm running the necessary >>> > steps >>> > for release myfaces core 1.2.7, core 1.1.7, so I would like if it is >>> > possible to delay this change after the release. >>> > >>> > regards >>> > >>> > Leonardo Uribe >>> > >>> > 2009/5/27 Cagatay Civici >>> >> >>> >> +1 for sure >>> >> >>> >> On Wed, May 27, 2009 at 8:53 AM, Bruno Aranda >>> >> wrote: >>> >>> >>> >>> +1 sounds good to me >>> >>> >>> >>> 2009/5/27 Matthias Wessendorf : >>> >>> > so, there are no objections in making the MyFaces 2.0 efforts >>> >>> > become >>> >>> > trunk ? >>> >>> > >>> >>> > -Matthias >>> >>> > >>> >>> > On Fri, May 22, 2009 at 9:10 PM, Bernd Bohmann >>> >>> > wrote: >>> >>> >> Hello, >>> >>> >> >>> >>> >> +1 >>> >>> >> >>> >>> >> I would prefer >>> >>> >> >>> >>> >> /trunk -> 2.0 >>> >>> >> /branches/myfaces-1.1.x >>> >>> >> /branches/myfaces-1.2.x >>> >>> >> >>> >>> >> because we are not using cvs anymore >>> >>> >> >>> >>> >> and the path already contains >>> >>> >> >>> >>> >> http://svn.apache.org/repos/asf/myfaces/core/ >>> >>> >> >>> >>> >> maybe we can omit the 'myfaces' in the branch name. >>> >>> >> >>> >>> >> Regards >>> >>> >> >>> >>> >> Bernd >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> >> On Fri, May 22, 2009 at 5:27 PM, Matthias Wessendorf >>> >>> >> wrote: >>> >>> >>> actually, I agree with Bernd. >>> >>> >>> >>> >>> >>> For the following layout: >>> >>> >>> >>> >>> >>> /trunk -> 2.0 >>> >>> >>> /branches/myfaces_1_1_x >>> >>> >>> /branches/myfaces_1_2_x >>> >>> >>> >>> >>> >>> Two reasons for way making 2.0 trunk: >>> >>> >>> -most current development is on-going in 2.0 (new spec) >>> >>> >>> -most commits are going to the 2.0 branch (so, let's make it >>> >>> >>> trunk) >>> >>> >>> >>> >>> >>> >>> >>> >>> So, I am +1 on the above "svn layout" >>> >>> >>> >>> >>> >>> >>> >>> >>> -Matthias >>> >>> >>> >>> >>> >>> >>> >>> >>> On Sat, May 16, 2009 at 1:04 PM, Matthias Wessendorf >>> >>> >>> wrote: >>> >>> from Bernd, on a different thread: >>> >>> >>> >>> Hello, >>> >>> >>> >>> I would suggest following layout >>> >>> >>> >>> 1.1.x branch/1.1.x >>> >>> 1.2.x branch/1.2.x >>> >>> 2.0.x trunk >>> >>> >>> >>> because the 2.0.x version is in development the other branches >>> >>> are >>> >>> only in bugfix state. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Fri, May 15, 2009 at 1:13 PM, Werner Punz >>> >>> >>> >>> wrote: >>> >>> > Matthias Wessendorf schrieb: >>> >>> >> >>> >>> >> Hi, >>> >>> >> ... >>> >>> >>> >>> >>> >>> Ok, I filed this: >>> >>> >>> https://issues.apache.org/jira/browse/INFRA-2053 >>> >>> >>> >>> >>> >>> maybe we should also think about making the JSF 1.1.x stuff a >>> >>> >>> branch ... >>> >>> >>> (since we already work on 2.0.x) >>> >>> >> >>> >>> >> what do people think if the 1.2 stuff becomes "trunk" >>> >>> >> And the following efforts are on a branch: >>> >>> >> -2.0.x >>> >>> >> -1.1.x >>> >>> >> >>> >>> > +1 >>> >>> > >>> >>> > >>> >>> >>> >>> >>> >>> >>> >>> -- >>> >>> 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 >>> >>> >>> >>> >>> >> >>> >>> > >>> >>> > >>> >>> > >>> >>> > -- >>> >>> > 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 >> > >
Re: Caching the result of an EL expression evaluation with in a life cycle
A standard EL expression evaluator cannot and MUST never cache results.
Imagine the following expression:
#{someBean.nextCounterValue}>
The app developer would not be very happy if EL caches that result, right?
So caching can only be a matter for the model.
OR: you write your own custom ELResolver that somehow "knows" which
values to cache and which it should not cache. Perhaps by inspecting
the annotations of your getters? I could imagine a custom @Cacheable
annotation for that purpose.
However, there is no magic config param. Sorry.
--Manfred
On Fri, Jun 26, 2009 at 03:36, Sam Witty wrote:
>
> If you have the following code:
>
> #{someBean.user.firstName}>
> #{someBean.user.lastName}>
> #{someBean.user.age}">
>
> and if SomeBean.user() is a call to the db then every one of the above
> expressions will cause a trip to the db. Of course to get around this one
> simply has to cache the value of user from the db (the first time) and then
> return the cached value instead of going to the db again.
>
> This is all well and good... however, I find myself writing a lot of this
> type of caching code in various places. It would seem that a much elegant
> solution would be to have the EL expression evaluator cache the result of an
> expression within a life cycle avoiding the need for every JSF developer to
> sprinkle caching code all over the place.
>
> Then again there maybe something out there that does this already (magical
> config param?) I just could not find anything.
>
> Thanks
> -Sam
> --
> View this message in context:
> http://www.nabble.com/Caching-the-result-of-an-EL-expression-evaluation-with-in-a-life-cycle-tp24213650p24213650.html
> Sent from the My Faces - Dev mailing list archive at Nabble.com.
>
>
Re: JSF 'blockinput' component
Yep, GPL might be a problem. Easiest think might be to switch to ASF-license prior to donating this bit. Thanks, Manfred On Thu, Jun 18, 2009 at 15:46, Cagatay Civici wrote: > Looks nice but not sure about the license. > > On Thu, Jun 18, 2009 at 8:44 AM, Roger Laenen > wrote: >> >> Hello, >> >> I've made a custom facelets component that simulates 'cell/block based' >> input like you find on official input forms. >> This type of input field can be useful in some specific situations. We use >> it for a bankaccount field with specific formatting and validation. >> You can find binaries and svn-trunk on http://code.google.com/p/blockinput >> An example app is also included. >> >> I thought it would maybe be interesting for inclusion in tomahawk. >> If there is any interest, let me know. >> >> grtz, >> >> Roger. >> > >
Re: [VOTE] jul instead of commons-logging
+0.5 I like SLF4J as well, but I won't get in the way of JUL. Never used JUL myself, so I don't know for sure if there might be any hidden quirks. ;-) --Manfred On Tue, Jun 9, 2009 at 20:32, Gerhard Petracek wrote: > hi, > > short description: > this first vote is about the switch from commons-logging (cl) to > java.util.logging (jul). > it's a binding vote for the next releases of all myfaces libs which are > currently using commons-logging. > so e.g. trinidad isn't affected. details are available at [1] > > if there won't be a majority, we will open a second vote (switch from > commons-logging to slf4j). > > > [ ] +1 for replacing cl with jul > [ ] +0 > [ ] -1 for keeping cl or to force a second vote for slf4j as replacement > > > regards, > gerhard > > [1] http://www.nabble.com/slf4j-and-myfaces-td23890255.html
Re: slf4j and myfaces
On Sat, Jun 6, 2009 at 08:33, Mario Ivankovits wrote:
> But why not use java.util.logging then at all. There is an example [1] which
> shows how to reroute it to any other logging impl.
hmm, insteresting. might be a way.
there is even a ready-to-use slf4j bridge handler for JUL
(http://www.slf4j.org/api/org/slf4j/bridge/SLF4JBridgeHandler.html)
that does exactly the same.
The downside is, you need an init call during startup of your app.
> This too will remove the need of any logging dependency then.
>
> Look, with slf4j you will end with three dependencies.
>
> * the slf4j api
> * the commons-logging to slf4j bridge (for all the other libraries your app
> is going to use and which still are using commons-logging)
> * the slf4j impl (an since the impl itself provides nothing than the bridge,
> you need the logging impl to)
>
> If you are going to use java.util.logging - which is a pain to setup, but
> sufficient for many use-cases - these are three (up to four) dependencies too
> much - just for logging!
Actually we would have just one single compile time dependency to the
slf4j api in MyFaces (instead of the JCL dep. we have now).
The rest is configuration stuff (runtime dependencies), the user deals
with in his app. It just depends on the actual logging impl he wants.
> I think, this will not be a bad move - and moves us completely out of line of
> this question once and for all I think.
>
> The java.util.logging api itself provides the same possibilities than we have
> today in our libraries - just different namings.
There are two pros of slf4j I did not mention yet:
1. parameterized messages, which make it possible to omit those ugly
"if (logger.isDebugEnabled()) {..." conditions, without performance
issue: see http://www.slf4j.org/faq.html#logging_performance
2. it's no longer possible to forget the log message by writing
"logger.error(exc)" instead of "logger.error("an error has occured",
exc)". This is because the slf4j api is strict and only allows a
String (and not an Object) as first argument.
However, I'm starting to like the idea of using JUL and kicking out
any logging dependency (and future discussions). What I'm not sure is
if the "JUL to other logging impl bridge" is multiple application
friendly. What happens if the JUL root handler is replaced (thats what
these bridges seem to do). Does this influence the servlet container
logging and other apps as well?
--Manfred
>
> Ciao,
> Mario
>
> [1] http://wiki.apache.org/myfaces/Trinidad_and_Common_Logging
>
> -Ursprüngliche Nachricht-
> Von: Mario Ivankovits [mailto:ma...@ops.co.at]
> Gesendet: Samstag, 06. Juni 2009 08:08
> An: 'MyFaces Development'
> Betreff: AW: slf4j and myfaces
>
> Sorry, for top-posting, but Outlook makes it too hard to do it right ;-)
>
> Well, yet another configuration option for configuring our logging facade
> (yes, you are right, it is a facade) is for sure also not a good option.
>
> As a last note to this discussion I'd like to say, that not dealing with the
> class loader issue does not mean that the webapp-reloading-memory-leak has
> been addressed in some way.
>
> Anyway, if you think it (slf4j) is a good way to go, I'll not stand in
> between :-)
>
> Ciao,
> Mario
>
> -Ursprüngliche Nachricht-
> Von: Manfred Geiler [mailto:manfred.gei...@gmail.com]
> Gesendet: Freitag, 05. Juni 2009 20:50
> An: MyFaces Development
> Betreff: Re: slf4j and myfaces
>
> On Fri, Jun 5, 2009 at 19:49, Mario Ivankovits wrote:
>> Hi!
>>
>> Could one please eloberate a little bit more in detail what the pros are of
>> slf4j?
>
> Pros:
> No class loader ambiguousness (as you mentioned)
> You get what you define (especially when using maven):
> compile-dependency to slf4j-api
> runtime-dependency to slf4j-adapter of YOUR choice
> --> that's it!
>
> No wild guessing like with JCL: Use Log4j if it is anywhere in the
> (web container) classpath, else use Java logging... What, if I want to
> use Java logging although there is Log4j in the classpath?!
> "Someone dropped a log4j.jar in the tomcat/lib folder. Oh no, not again..."
> Yes, I know commons-logging.properties solves this, but that's
> awful... (BTW, I hate properties files in the root package namespace!)
>
>
>> Notice, I switched to it in our company project - but always using the
>> commons-logging api and just used the slf4j-over-cl wrapper. This is
>> something wich is possible for each and ever user of myfaces already, just
>> by adjusting the depencendcies correctly.
>
> Guess, you meant the jcl-over-slf4j.jar bridge, right? That's the part
> that reroutes JCL call
Re: slf4j and myfaces
On Fri, Jun 5, 2009 at 19:49, Mario Ivankovits wrote: > Hi! > > Could one please eloberate a little bit more in detail what the pros are of > slf4j? Pros: No class loader ambiguousness (as you mentioned) You get what you define (especially when using maven): compile-dependency to slf4j-api runtime-dependency to slf4j-adapter of YOUR choice --> that's it! No wild guessing like with JCL: Use Log4j if it is anywhere in the (web container) classpath, else use Java logging... What, if I want to use Java logging although there is Log4j in the classpath?! "Someone dropped a log4j.jar in the tomcat/lib folder. Oh no, not again..." Yes, I know commons-logging.properties solves this, but that's awful... (BTW, I hate properties files in the root package namespace!) > Notice, I switched to it in our company project - but always using the > commons-logging api and just used the slf4j-over-cl wrapper. This is > something wich is possible for each and ever user of myfaces already, just > by adjusting the depencendcies correctly. Guess, you meant the jcl-over-slf4j.jar bridge, right? That's the part that reroutes JCL calls to the slf4j API. Yes, that is a possible solution, but keep in mind that this is kind of a hack. It is actually a reimplementation of the JCL API (namespace) that routes all calls to SLF4J. It's meant as runtime solution for legacy libs. Using it as compile time dependency might be a shortcut, but my feeling says it's not the nicest solution. > Lately I even switched to my own logging wrapper, but this is another story. > In the end, everything still uses the cl API which is proven to work fine. > (I created the org.apache.commons.logging package structure with my own > classes - which for sure is not possible for myfaces!). yet another logging wrapper WHY do so many people feel they must write such a thing? JCL and slf4j ARE ready-to-use logging wrappers. So??? > I still think, that using the cl api is the best we can do for our users. If > they then use cl as implementation - and if this is considered "good" - is > another story, but nothing WE should anticipate. They CAN use JCL if myfaces uses slf4j. They just define a slf4j-jcl-x.x.x.jar runtime-dependency and everything is fine. > As far as I can say the cl api is rock solid, just the class-loader stuff is > a pain. But (again AFAIK), slf4j does not solve it, it just does not deal > with it. slf4j DOES solve the problem by avoiding highly sophisticated classloader magic! > Before we start using any other logging api I'd suggest to build our own > thin myfaces-logging wrapper where one then can easily plug in log4j, cl, > jul (java utils ogging) or whatever - we do not even have to provide any > other impl than for jul. yet another logging wrapper... (see above) How would you implement such a pluggable wrapper? Yet another (mandatory) config parameter. System property? Servlet context param? Come on! What about this: looking for existing well-known logging implementations and define some priority rules... Dejavu. See the problem? > As a plus, this then will remove a dependency - a dependency to any logging > framework - which - in terms of dependencies can be considered as a "good" > thing, no? You buy this "good" thing by re-implementing SLF4J and/or JCL. Serious. I cannot imagine a "wrapper" (actually a "facade", right?) implementation that is versatile for the developers and pluggable for the users and has less source code than any of the well-known logging facade APIs (slf4j and jcl). They both are actually meant to heal the java world from proprietary "yet another logging facades/wrappers"! +1 for using SLF4J as logging facade for future MyFaces developments (JSF 2.0, ...) +0 for replacing JCL by SLF4J for all existing code (if someone is volunteering to do the job I have no problem with that...) --Manfred
Re: License question
On Wed, Jun 3, 2009 at 15:49, Matthias Wessendorf wrote: > On Tue, Jun 2, 2009 at 5:57 PM, Cagatay Civici > wrote: >> Hi guys, >> >> I've question regarding licensing. >> >> For a side open source project(PrimeFaces), I needed access to package >> private StateWriter class and as a hack I added com.sun.facelets package to >> the project. That way I got the access for that class. >> >> Does anyone see a legal issue here? > > no, why ? > you just fake the package in order to get more "to see" Hmm. Don't think it's _that_ easy. For instance the "java." and "javax." namespaces are reserved and must not be used by any (official) product that does not implement the regarding JCR. However. I am not a lawer and I have no idea if that also applies to "hacks" and I do not know if there is a precendent about using a foreign reserved domain name as java namespace. My feeling is, that it is ok for the hack. But I'm not totally sure. --Manfred
[jira] Commented: (ORCHESTRA-40) A transaction token component inspired by the struts transaction processor
[ https://issues.apache.org/jira/browse/ORCHESTRA-40?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12706086#action_12706086 ] Manfred Geiler commented on ORCHESTRA-40: - The LOG.error should be replaced by a LOG.debug in the TransactionTokenPhaseListener. (looks like a debugging remainder) > A transaction token component inspired by the struts transaction processor > -- > > Key: ORCHESTRA-40 > URL: https://issues.apache.org/jira/browse/ORCHESTRA-40 > Project: MyFaces Orchestra > Issue Type: New Feature > Components: Conversation >Affects Versions: 1.3.1 >Reporter: Bernd Bohmann >Assignee: Simon Kitching > Attachments: > ORCHESTRA-40-CacheControl+TransactionToken-before-restore-View2.patch, > ORCHESTRA-40-CacheControl+TransactionTokenListener-after-restore-View3.patch, > ORCHESTRA-40-CacheControl.patch, ORCHESTRA-40-TransactionToken.patch > > > A transactionToken Component for orchestra inspired by the struts transaction > processor. > The transaction token is to be used for enforcing a single request for a > particular transaction. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ORCHESTRA-40) A transaction token component inspired by the struts transaction processor
[ https://issues.apache.org/jira/browse/ORCHESTRA-40?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12705595#action_12705595 ] Manfred Geiler commented on ORCHESTRA-40: - MANAGED_BEAN_NAME = "org.apache.myfaces.orchestra.TransactionToken" is suboptimal because dots are (officially) not allowed within a managed bean name. Only underscores, letters and digits are allowed according to jsf spec. > A transaction token component inspired by the struts transaction processor > -- > > Key: ORCHESTRA-40 > URL: https://issues.apache.org/jira/browse/ORCHESTRA-40 > Project: MyFaces Orchestra > Issue Type: New Feature > Components: Conversation >Affects Versions: 1.3.1 >Reporter: Bernd Bohmann >Assignee: Simon Kitching > Attachments: > ORCHESTRA-40-CacheControl+TransactionToken-before-restore-View2.patch, > ORCHESTRA-40-CacheControl+TransactionTokenListener-after-restore-View3.patch, > ORCHESTRA-40-CacheControl.patch, ORCHESTRA-40-TransactionToken.patch > > > A transactionToken Component for orchestra inspired by the struts transaction > processor. > The transaction token is to be used for enforcing a single request for a > particular transaction. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Connect my committer account to jira
done. Ganesh, Alexander, Michael, you are all three now member of the jira group "myfaces committers" --Manfred On Fri, May 1, 2009 at 12:03, Matthias Wessendorf wrote: > Hello Manfred, > > can you do the jira-update for all the three new committers ? > :-) > > Thanks! > Matthias > > On Fri, May 1, 2009 at 11:47 AM, Ganesh wrote: >> Hi, >> >> How do I connect my jira account (ganesh.jung) to my committer account >> (ganesh)? I want to assingn jira tasks to myself which isn't possible with >> my current jira account. >> >> Best Regards, >> Ganesh >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf >
Re: Jira account for developers
yeah, of course. Jan-Kees, you were not in the "myfaces-committers" group on Jira. I fixed that. @all, FYI: There are actually 4 myfaces related groups on Jira. The permissions are equal to the standard roles that are used by almost all Apache projects: myfaces-administrators ... people allowed to manage Jira groups/permissions myfaces-contributors ... contributors and committer candidates (allowed to edit issues) myfaces-committers ... committers (additionally allowed to delete issues and comments) myfaces-pmc ... PMC members --Manfred On Wed, Apr 15, 2009 at 22:49, Matthias Wessendorf wrote: > Hey Manfred, > > do you know if this is fixable via the JIRA configurations ? > > -Matthias > > On Wed, Apr 15, 2009 at 8:24 PM, Jan-Kees van Andel > wrote: >> Hi, >> >> Last week I've committed the fix for a Jira issue, but I can't resolve >> the issue, because my Jira account seems to be separated from my >> Apache account. >> Am I missing the needed roles in Jira? >> >> I authenticate on Jira using my Apache username/email address. >> >> Someone knows the answer? It would definitely make work easier. ;-) >> >> Thanks, >> Jan-Kees >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf >
Re: CI server support / setup (was Fwd: Buildbot at Apache, and a new builds mailing list.)
+1 for moving to new infrastructure --Manfred On Wed, Apr 15, 2009 at 10:02, Matthias Wessendorf wrote: > Hi, > > attached is an announcement that there is now a nice "support" for CI servers. > I'd like to move the myfaces (sub) projects to this new infrastructure. > > What do folks think about that ? I mean in the past our own zone > somewhat worked, > but the server had also every now and than its hick-ups. > > so, I am +1 in moving forward to the new Buildbot. > > what do folks think about it ? > > -Matthias > > > -- Forwarded message -- > From: Gavin > Date: Sat, Apr 11, 2009 at 11:15 AM > Subject: Buildbot at Apache, and a new builds mailing list. > To: p...@apache.org > > > Hi All, > > This is a heads-up that Buildbot CI server is now available for projects > use. > > Some projects that have been used for testing Buildbot here at the ASF can > be seen at http://ci.apache.org. > I have a development installation at > http://build01.16degrees.com.au:8020/waterfall where I have been testing > many more projects (about 20 including the Buildbot project itself). > > Any new or existing project that wants to add Buildbot to their arsenal of > tools to help them build,test,snapshot,deploy,etc can create an issue on the > Infrastructure Issue Tracker : > > https://issues.apache.org/jira/browse/INFRA/component/12312782 > > There has been a new mailing list created specifically for all our CI > servers (Buildbot, Hudson, Continuum) - bui...@apache.org - sign up at > builds-subscr...@apache.org . > > I made use of our infra blog and posted a short note about it at > > https://blogs.apache.org/infra/entry/new_mailing_list_for_ci > > So, any requests to make use of any of the build servers are made to the > appropriate Jira component on the Infra Issue Tracker. All discussions > regarding them should be directed to the bui...@apache.org list from now on. > > Thanks, and see you there! > > Gav... > > > - > To unsubscribe, e-mail: private-unsubscr...@incubator.apache.org > For additional commands, e-mail: private-h...@incubator.apache.org > > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf >
[jira] Created: (MYFACES-2154) mobile internet explorer version 6.12 issue
mobile internet explorer version 6.12 issue
---
Key: MYFACES-2154
URL: https://issues.apache.org/jira/browse/MYFACES-2154
Project: MyFaces Core
Issue Type: Improvement
Components: General
Environment: mobile internet explorer version 6.12
MyFaces v???
Reporter: Manfred Geiler
Tobias Bräuer reported the following issue:
Hello,
There is a problem with mobile internet explorer version 6.12 and
myfaces. The browser sends a "Accept:
application/vnd.wap.mms-message;*/*". We solved that problem by adding
the following code in the class
org.apache.myfaces.shared_impl.renderkit.html.HtmlRendererUtils at
line 1619. If used with tomahawk, the same fix is needed there.
I have no idea how your community process works, but feel free to add
the code to your repository.
if (contentTypeListString == null) {
FacesContext context = FacesContext.getCurrentInstance();
if (context != null) {
contentTypeListString = (String)
context.getExternalContext()
.getRequestHeaderMap().get("Accept");
// There is a windows mobile IE client (6.12)
sending
// "application/vnd.wap.mms-message;*/*"
// This is a workaround ...
if (contentTypeListString
.startsWith("application/vnd.wap.mms-message;*/*")) {
contentTypeListString = "*/*";
}
}
if (contentTypeListString == null) {
if (log.isDebugEnabled())
log
.debug("No content type
list given, creating
HtmlResponseWriterImpl with default content type.");
contentTypeListString = HTML_CONTENT_TYPE;
}
}
Cheers,
Tobias Bräuer
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-2154) mobile internet explorer version 6.12 issue
[
https://issues.apache.org/jira/browse/MYFACES-2154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Manfred Geiler updated MYFACES-2154:
Status: Patch Available (was: Open)
> mobile internet explorer version 6.12 issue
> ---
>
> Key: MYFACES-2154
> URL: https://issues.apache.org/jira/browse/MYFACES-2154
> Project: MyFaces Core
> Issue Type: Improvement
> Components: General
> Environment: mobile internet explorer version 6.12
> MyFaces v???
> Reporter: Manfred Geiler
>
> Tobias Bräuer reported the following issue:
> Hello,
> There is a problem with mobile internet explorer version 6.12 and
> myfaces. The browser sends a "Accept:
> application/vnd.wap.mms-message;*/*". We solved that problem by adding
> the following code in the class
> org.apache.myfaces.shared_impl.renderkit.html.HtmlRendererUtils at
> line 1619. If used with tomahawk, the same fix is needed there.
> I have no idea how your community process works, but feel free to add
> the code to your repository.
>if (contentTypeListString == null) {
>FacesContext context =
> FacesContext.getCurrentInstance();
>if (context != null) {
>contentTypeListString = (String)
> context.getExternalContext()
>
> .getRequestHeaderMap().get("Accept");
>// There is a windows mobile IE client (6.12)
> sending
>// "application/vnd.wap.mms-message;*/*"
>// This is a workaround ...
>if (contentTypeListString
>
> .startsWith("application/vnd.wap.mms-message;*/*")) {
>contentTypeListString = "*/*";
>}
>}
>if (contentTypeListString == null) {
>if (log.isDebugEnabled())
>log
>.debug("No content
> type list given, creating
> HtmlResponseWriterImpl with default content type.");
>contentTypeListString = HTML_CONTENT_TYPE;
>}
>}
> Cheers,
> Tobias Bräuer
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Project File Encoding for the MyFaces Source
good idea. except for properties files. they MUST be in ISO 8859-1 character encoding! (see http://java.sun.com/j2se/1.5.0/docs/api/java/util/Properties.html) therefore: please take care of the resource bundle files when you change encoding. --Manfred On Tue, Feb 10, 2009 at 19:47, Bernd Bohmann wrote: > Hello, > > could we define a default file encoding for the MyFaces Project? > > I would suggest UTF-8. > > And add following property to the poms: > > UTF-8 > > See: > > http://docs.codehaus.org/display/MAVENUSER/POM+Element+for+Source+File+Encoding > > > Regards > > Bernd >
[Travel Assistance] Applications for ApacheCon EU 2009 - Now Open
FYI -- Forwarded message -- From: Tony Stevenson To: travel-assista...@apache.org Date: Fri, 23 Jan 2009 13:28:19 + Subject: [Travel Assistance] Applications for ApacheCon EU 2009 - Now Open The Travel Assistance Committee is now accepting applications for those wanting to attend ApacheCon EU 2009 between the 23rd and 27th March 2009 in Amsterdam. The Travel Assistance Committee is looking for people who would like to be able to attend ApacheCon EU 2009 who need some financial support in order to get there. There are very few places available and the criteria is high, that aside applications are open to all open source developers who feel that their attendance would benefit themselves, their project(s), the ASF or open source in general. Financial assistance is available for travel, accommodation and entrance fees either in full or in part, depending on circumstances. It is intended that all our ApacheCon events are covered, so it may be prudent for those in the United States or Asia to wait until an event closer to them comes up - you are all welcome to apply for ApacheCon EU of course, but there must be compelling reasons for you to attend an event further away that your home location for your application to be considered above those closer to the event location. More information can be found on the main Apache website at http://www.apache.org/travel/index.html - where you will also find a link to the online application form. Time is very tight for this event, so applications are open now and will end on the 4th February 2009 - to give enough time for travel arrangements to be made. Good luck to all those that apply. Regards, The Travel Assistance Committee -- -- Tony Stevenson t...@pc-tony.com // pct...@apache.org // pct...@freenode.net http://blog.pc-tony.com/ 1024D/51047D66 ECAF DC55 C608 5E82 0B5E 3359 C9C7 924E 5104 7D66 --
Re: [VOTE] Support new JSR for the Portlet 2.0 Bidge for JavaServer Faces 1.2
+1 --Manfred On Tue, Jan 20, 2009 at 22:04, Scott O'Bryan wrote: > Hey community, > > Oracle is trying to open up a new JSR for the Portlet 2.0 Bridge. > Originally this was part of the JSR-301 but there was a slight > misunderstanding of the intentions of the specs regarding release dates. To > make a long story short, instead of doing both the specifications for > Portlet 1.0 and 2.0 as part of the JSR, it's being split up. The Project > lead will be Michael Freedman who is a MyFaces committer and has been very > active on the Apache MyFaces Portlet Bridge project and he was also the > spec-lead for the JSR-301. The Apache implementations of these > specifications are being written as the eventual R.I.'s for the bridge > projects. > > In any case, should Apache MyFaces put its vote in for the formation of this > JSR? Understand that this is not a vote for a project or spec, just to > allow the JCP to start a JSR to support this project. I have gotten word > from Apache that this can be done if a community decides to support it. > Since the Apache MyFaces Portlet Bridge is being developed as the eventual > R.I. and Oracle has been very open to aiding the OpenSource development of > this bridge here at Apache, I think it's a good opportunity for us to > support the JCP and, in particular, the Portlet Bridge Projects. > > Vote: > > [ ] +1 to support the formation of a new JSR for the Portlet Bridge 2.0 > [ ] +0 don't really care, it's just a silly green checkmark on the ballot > [ ] -1 don't put the green checkmark on the ballot, Apache shouldn't support > the JCP > > Thanks, > Scott O'Bryan >
Re: [ExtVal] logo proposal
+1 On Sun, Dec 14, 2008 at 16:48, Gerhard Petracek wrote: > hello, > > we have a final proposal for the extval logo [1]. > > please send your opinions. > > > [ ] +1 for: i like the logo > [ ] +0 for: i like a different version of the logo > [ ] -1 for: i don't like the logo > > thanks, > gerhard > > [1] http://os890.blogspot.com/2008/12/myfaces-extval-logo-proposal.html > > -- > > http://www.irian.at > > Your JSF powerhouse - > JSF Consulting, Development and > Courses in English and German > > Professional Support for Apache MyFaces >
Re: MyFaces Commons does not have a JIRA entry
ok, done. created the MFCOMMONS Jira Project together with all the components (myfaces-converters, myfaces-validators, myfaces-commons-utils, ...) --Manfred On Mon, Nov 24, 2008 at 12:10 PM, Gerhard Petracek <[EMAIL PROTECTED]> wrote: > +1 > > regards, > gerhard > > > > 2008/11/24 Cagatay Civici <[EMAIL PROTECTED]> >> >> MFCOMMONS is fine for me as well >> >> On Mon, Nov 24, 2008 at 10:36 AM, Manfred Geiler <[EMAIL PROTECTED]> >> wrote: >>> >>> any other comments on this? >>> if not I will create the "MFCOMMONS" in a few minutes. >>> --Manfred >>> >>> On Mon, Nov 24, 2008 at 3:15 AM, Hazem Saleh <[EMAIL PROTECTED]> wrote: >>> > MFCOMMONS is nice for me. >>> > >>> > On Sun, Nov 23, 2008 at 11:41 PM, Manfred Geiler <[EMAIL PROTECTED]> >>> > wrote: >>> >> >>> >> I can do it. I am adding the new Jira project tomorrow. >>> >> However, first of all we need a unique short name (the Jira key) for >>> >> it. >>> >> Some proposals are: >>> >> 1 MFCOMMONS >>> >> 2 MCOMMONS >>> >> 3 MYFACESCOMMONS >>> >> 4 COMMONS >>> >> >>> >> 3 is too long I think >>> >> 4 though unique might be misleading --> Apache Commons ! >>> >> >>> >> --Manfred >>> >> >>> >> >>> >> On Sun, Nov 23, 2008 at 11:17 AM, Matthias Wessendorf >>> >> <[EMAIL PROTECTED]> wrote: >>> >> > Let's fix that >>> >> > >>> >> > Sent from my iPod. >>> >> > Am 23.11.2008 um 00:42 schrieb "Leonardo Uribe" <[EMAIL PROTECTED]>: >>> >> > >>> >> > Hi >>> >> > >>> >> > Unfortunately no. I can do almost everything but not create projects >>> >> > on >>> >> > JIRA. And I don't know who can do it. >>> >> > >>> >> > regards >>> >> > >>> >> > Leonardo Uribe >>> >> > >>> >> > On Sat, Nov 22, 2008 at 2:17 PM, Matthias Wessendorf >>> >> > <[EMAIL PROTECTED]> >>> >> > wrote: >>> >> >> >>> >> >> Are you an admin on jira, leo? >>> >> >> >>> >> >> Sent from my iPod. >>> >> >> Am 22.11.2008 um 20:12 schrieb "Leonardo Uribe" <[EMAIL PROTECTED]>: >>> >> >> >>> >> >> >>> >> >> >>> >> >> On Sat, Nov 22, 2008 at 12:22 PM, Leonardo Uribe <[EMAIL PROTECTED]> >>> >> >> wrote: >>> >> >>> >>> >> >>> >>> >> >>> On Sat, Nov 22, 2008 at 11:46 AM, Hazem Saleh <[EMAIL PROTECTED]> >>> >> >>> wrote: >>> >> >>>> >>> >> >>>> Hello Team, >>> >> >>>> >>> >> >>>> Can any body please add MyFaces Commons to the MyFaces >>> >> >>>> subprojects in >>> >> >>>> JIRA. >>> >> >>>> I wish to create an issue on Commons but could not find an entry. >>> >> >>>> Thanks all! >>> >> >>> >>> >> >>> I did it yesterday. >>> >> >> >>> >> >> Sorry, a misunderstanding. I added the common components module but >>> >> >> still >>> >> >> we need the JIRA entry. >>> >> >> >>> >> >> regards >>> >> >> >>> >> >> Leonardo Uribe >>> >> >>> >>> >> >>> regards >>> >> >>> >>> >> >>> Leonardo Uribe >>> >> >>> >>> >> >>>> >>> >> >>>> -- >>> >> >>>> Hazem Ahmed Saleh Ahmed >>> >> >>>> >>> >> >>>> Author of (The Definitive Guide to Apache MyFaces and Facelets): >>> >> >>>> >>> >> >>>> >>> >> >>>> >>> >> >>>> http://www.amazon.com/Definitive-Guide-Apache-MyFaces-Facelets/dp/1590597370 >>> >> >>>> >>> >> >>>> Web blog: http://www.jroller.com/page/HazemBlog >>> >> >>>> >>> >> >>>> [Web 2.0] Google Maps Integration with JSF: >>> >> >>>> http://code.google.com/p/gmaps4jsf/ >>> >> >>>> http://www.theserverside.com/news/thread.tss?thread_id=51250 >>> >> >>> >>> >> >> >>> >> > >>> >> > >>> > >>> > >>> > >>> > -- >>> > Hazem Ahmed Saleh Ahmed >>> > >>> > Author of (The Definitive Guide to Apache MyFaces and Facelets): >>> > >>> > http://www.amazon.com/Definitive-Guide-Apache-MyFaces-Facelets/dp/1590597370 >>> > >>> > Web blog: http://www.jroller.com/page/HazemBlog >>> > >>> > [Web 2.0] Google Maps Integration with JSF: >>> > http://code.google.com/p/gmaps4jsf/ >>> > http://www.theserverside.com/news/thread.tss?thread_id=51250 >>> > >> > > > > -- > > http://www.irian.at > > Your JSF powerhouse - > JSF Consulting, Development and > Courses in English and German > > Professional Support for Apache MyFaces >
Re: MyFaces Commons does not have a JIRA entry
any other comments on this? if not I will create the "MFCOMMONS" in a few minutes. --Manfred On Mon, Nov 24, 2008 at 3:15 AM, Hazem Saleh <[EMAIL PROTECTED]> wrote: > MFCOMMONS is nice for me. > > On Sun, Nov 23, 2008 at 11:41 PM, Manfred Geiler <[EMAIL PROTECTED]> > wrote: >> >> I can do it. I am adding the new Jira project tomorrow. >> However, first of all we need a unique short name (the Jira key) for it. >> Some proposals are: >> 1 MFCOMMONS >> 2 MCOMMONS >> 3 MYFACESCOMMONS >> 4 COMMONS >> >> 3 is too long I think >> 4 though unique might be misleading --> Apache Commons ! >> >> --Manfred >> >> >> On Sun, Nov 23, 2008 at 11:17 AM, Matthias Wessendorf >> <[EMAIL PROTECTED]> wrote: >> > Let's fix that >> > >> > Sent from my iPod. >> > Am 23.11.2008 um 00:42 schrieb "Leonardo Uribe" <[EMAIL PROTECTED]>: >> > >> > Hi >> > >> > Unfortunately no. I can do almost everything but not create projects on >> > JIRA. And I don't know who can do it. >> > >> > regards >> > >> > Leonardo Uribe >> > >> > On Sat, Nov 22, 2008 at 2:17 PM, Matthias Wessendorf >> > <[EMAIL PROTECTED]> >> > wrote: >> >> >> >> Are you an admin on jira, leo? >> >> >> >> Sent from my iPod. >> >> Am 22.11.2008 um 20:12 schrieb "Leonardo Uribe" <[EMAIL PROTECTED]>: >> >> >> >> >> >> >> >> On Sat, Nov 22, 2008 at 12:22 PM, Leonardo Uribe <[EMAIL PROTECTED]> >> >> wrote: >> >>> >> >>> >> >>> On Sat, Nov 22, 2008 at 11:46 AM, Hazem Saleh <[EMAIL PROTECTED]> >> >>> wrote: >> >>>> >> >>>> Hello Team, >> >>>> >> >>>> Can any body please add MyFaces Commons to the MyFaces subprojects in >> >>>> JIRA. >> >>>> I wish to create an issue on Commons but could not find an entry. >> >>>> Thanks all! >> >>> >> >>> I did it yesterday. >> >> >> >> Sorry, a misunderstanding. I added the common components module but >> >> still >> >> we need the JIRA entry. >> >> >> >> regards >> >> >> >> Leonardo Uribe >> >>> >> >>> regards >> >>> >> >>> Leonardo Uribe >> >>> >> >>>> >> >>>> -- >> >>>> Hazem Ahmed Saleh Ahmed >> >>>> >> >>>> Author of (The Definitive Guide to Apache MyFaces and Facelets): >> >>>> >> >>>> >> >>>> http://www.amazon.com/Definitive-Guide-Apache-MyFaces-Facelets/dp/1590597370 >> >>>> >> >>>> Web blog: http://www.jroller.com/page/HazemBlog >> >>>> >> >>>> [Web 2.0] Google Maps Integration with JSF: >> >>>> http://code.google.com/p/gmaps4jsf/ >> >>>> http://www.theserverside.com/news/thread.tss?thread_id=51250 >> >>> >> >> >> > >> > > > > > -- > Hazem Ahmed Saleh Ahmed > > Author of (The Definitive Guide to Apache MyFaces and Facelets): > http://www.amazon.com/Definitive-Guide-Apache-MyFaces-Facelets/dp/1590597370 > > Web blog: http://www.jroller.com/page/HazemBlog > > [Web 2.0] Google Maps Integration with JSF: > http://code.google.com/p/gmaps4jsf/ > http://www.theserverside.com/news/thread.tss?thread_id=51250 >
Re: MyFaces Commons does not have a JIRA entry
I can do it. I am adding the new Jira project tomorrow. However, first of all we need a unique short name (the Jira key) for it. Some proposals are: 1 MFCOMMONS 2 MCOMMONS 3 MYFACESCOMMONS 4 COMMONS 3 is too long I think 4 though unique might be misleading --> Apache Commons ! --Manfred On Sun, Nov 23, 2008 at 11:17 AM, Matthias Wessendorf <[EMAIL PROTECTED]> wrote: > Let's fix that > > Sent from my iPod. > Am 23.11.2008 um 00:42 schrieb "Leonardo Uribe" <[EMAIL PROTECTED]>: > > Hi > > Unfortunately no. I can do almost everything but not create projects on > JIRA. And I don't know who can do it. > > regards > > Leonardo Uribe > > On Sat, Nov 22, 2008 at 2:17 PM, Matthias Wessendorf <[EMAIL PROTECTED]> > wrote: >> >> Are you an admin on jira, leo? >> >> Sent from my iPod. >> Am 22.11.2008 um 20:12 schrieb "Leonardo Uribe" <[EMAIL PROTECTED]>: >> >> >> >> On Sat, Nov 22, 2008 at 12:22 PM, Leonardo Uribe <[EMAIL PROTECTED]> wrote: >>> >>> >>> On Sat, Nov 22, 2008 at 11:46 AM, Hazem Saleh <[EMAIL PROTECTED]> wrote: Hello Team, Can any body please add MyFaces Commons to the MyFaces subprojects in JIRA. I wish to create an issue on Commons but could not find an entry. Thanks all! >>> >>> I did it yesterday. >> >> Sorry, a misunderstanding. I added the common components module but still >> we need the JIRA entry. >> >> regards >> >> Leonardo Uribe >>> >>> regards >>> >>> Leonardo Uribe >>> -- Hazem Ahmed Saleh Ahmed Author of (The Definitive Guide to Apache MyFaces and Facelets): http://www.amazon.com/Definitive-Guide-Apache-MyFaces-Facelets/dp/1590597370 Web blog: http://www.jroller.com/page/HazemBlog [Web 2.0] Google Maps Integration with JSF: http://code.google.com/p/gmaps4jsf/ http://www.theserverside.com/news/thread.tss?thread_id=51250 >>> >> > >
New MyFaces PMC chair
Please welcome our new MyFaces PMC chair Matthias Wessendorf! As some of you already might know, I had decided to step down as the chair. The MyFaces PMC members then voted for Matthias Wessendorf as the successor and yesterday the board approved the change. Matthias, thanks for beeing up to that job. I personally have great confidence in you and wish you all the best for guiding us into the JSF 2.0 era. Regards, Manfred Geiler
Re: [VOTE] Release of Trinidad 1.2.10
+1 On Fri, Nov 14, 2008 at 9:15 AM, Thomas Spiegl <[EMAIL PROTECTED]> wrote: > +1 > > On Thu, Nov 13, 2008 at 7:06 PM, Grant Smith <[EMAIL PROTECTED]> wrote: >> +1 >> >> On Thu, Nov 13, 2008 at 6:28 AM, Gerhard Petracek >> <[EMAIL PROTECTED]> wrote: >>> >>> hello paul, >>> >>> the jira link is [1] e.g. [2] >>> >>> regards, >>> gerhard >>> >>> [1] >>> http://issues.apache.org/jira/secure/ConfigureReleaseNote.jspa?projectId=12310661 >>> [2] >>> http://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12313342&styleName=Html&projectId=12310661&Create=Create >>> >>> >>> >>> 2008/11/13 Matthias Wessendorf <[EMAIL PROTECTED]> On Thu, Nov 13, 2008 at 3:12 PM, Paul Spencer <[EMAIL PROTECTED]> wrote: > Where can I find the proposed release notes? usually all these myfaces projects provide that after a release. You can do a jira search on your own -M > > BTW: I will not be able to look at the artifacts until this evening, > Eastern > Standard Time, at the earliest. > > Paul Spencer > > Matthias Wessendorf wrote: >> >> Hi, >> >> I was running the needed tasks to get the 1.2.10 release of the Apache >> MyFaces Trinidad CORE out. The artifacts are deployed to my private >> Apache account ([1]). >> >> Please take a look at the "1.2.10" artifacts and vote >> >> >> [ ] +1 for community members who have reviewed the bits >> [ ] +0 >> [ ] -1 for fatal flaws that should cause these bits not to be >> released, >> and why.. >> >> >> Thanks, >> Matthias >> >> [1] http://people.apache.org/~matzew/trinidad1210/ >> > > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf >>> >>> >>> >>> -- >>> >>> http://www.irian.at >>> >>> Your JSF powerhouse - >>> JSF Consulting, Development and >>> Courses in English and German >>> >>> Professional Support for Apache MyFaces >> >> >> >> -- >> Grant Smith >> >> >
Re: [VOTE] Release of Trinidad 1.0.10
+1 On Fri, Nov 14, 2008 at 9:15 AM, Thomas Spiegl <[EMAIL PROTECTED]> wrote: > +1 > > On Thu, Nov 13, 2008 at 7:06 PM, Grant Smith <[EMAIL PROTECTED]> wrote: >> +1 >> >> On Thu, Nov 13, 2008 at 7:40 AM, <[EMAIL PROTECTED]> wrote: >>> >>> +1 >>> >>> ..no noticeable negative side effects :) >>> >>> Best wishes >>> Wolfgang >>> >>> >>> >>> "Matthias Wessendorf" <[EMAIL PROTECTED]> >>> Gesendet von: [EMAIL PROTECTED] >>> >>> 13.11.2008 09:19 >>> >>> Bitte antworten an >>> "MyFaces Development" >>> An >>> "MyFaces Development" >>> Kopie >>> Thema >>> [VOTE] Release of Trinidad 1.0.10 >>> >>> >>> >>> >>> Hi, >>> >>> I was running the needed tasks to get the 1.0.10 release of the Apache >>> MyFaces Trinidad CORE out. The artifacts are deployed to my private >>> Apache account ([1]). >>> >>> Please take a look at the "1.0.10" artifacts and vote >>> >>> >>> [ ] +1 for community members who have reviewed the bits >>> [ ] +0 >>> [ ] -1 for fatal flaws that should cause these bits not to be released, >>> and why.. >>> >>> >>> Thanks, >>> Matthias >>> >>> [1] http://people.apache.org/~matzew/trinidad1010/ >>> >>> -- >>> Matthias Wessendorf >>> >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> twitter: http://twitter.com/mwessendorf >>> >> >> >> >> -- >> Grant Smith >> >> >
Re: Impl compile time dependency to Shared
since classes are copied into the myfaces-impl jar, there should not be any dependency at all. but, to force maven to build myfaces-shared-impl first there should be a fake "provided" dependency. AFAIR this was the case. I wonder if someone has modified/added this dependency lately? --Manfred On Wed, Nov 12, 2008 at 4:27 PM, Bruno Aranda <[EMAIL PROTECTED]> wrote: > If it is not the case, the myfaces-shared-impl should be marked as > 'optional' in the impl pom.xml? > > Bruno > > 2008/11/12 Cagatay Civici <[EMAIL PROTECTED]> >> >> When I add myfaces-imp 1.2.5 to my pom as a dependency, >> myfaces-shared-impl-3.0.5.jar also implicitly added to the classpath. >> >> It is a problem for myfaces users since now we have the same classes added >> twice to the classpath. >> >> Cagatay > >
Re: [release] signing assembly artifacts
AFAIR the gpg maven plugin worked well. And I think there is a certain profile you just have to activate when launching the release build. --Manfred On Wed, Nov 12, 2008 at 11:29 AM, Matthias Wessendorf <[EMAIL PROTECTED]> wrote: > Hi, > > I wonder if one of the myfaces projects has a *scriptlet* (or > something like that), included in the build to do a gpg-signing of the > assembly artifacts ? > I have currently a Phyton (from Scott O'Bryan) that does the work for me. > > Any hint would be appreciated. > > Thx, > Matthias > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf >
[Announce] Call For Papers opens for ApacheCon US 2009
If you have only 30 seconds to read this; Join us in celebrating the ASF's 10th Anniversary at ApacheCon! The Call for Papers is now open for ApacheCon US 2009, taking place 2-6 November in Oakland, California. Proposals are being accepted at http://us.apachecon.com/c/acus2009/cfp/ and can be revised at anytime until the submissions closing deadline of 28 February 2009. In addition, sponsorship opportunities for both ApacheCon EU 2009/Amsterdam and ApacheCon US 2009/Oakland are available. Please contact Delia Frees at [EMAIL PROTECTED] for further information. Please, read on... *** ApacheCon Celebrates the ASF's 10th Anniversary in Oakland, California, 2-6 November 2009 Call for Papers Opens for ApacheCon US 2009 The Apache Software Foundation (ASF) invites submissions to its official user and developer conference, taking place 2-6 November 2009 at the Oakland Convention Center and Marriott Hotel. ApacheCon serves as a forum for showcasing the ASF's latest projects, members, and community initiatives. Offering unparalleled educational opportunities, ApacheCon's presentations, hands-on trainings, and sessions address key technology, development, business/community, and licensing issues in Open Source. The wide range of activities offered at ApacheCon promotes the exchange of ideas amongst ASF Members, committers, innovators, developers, vendors, and users interested in the future of Open Source technology. The conference program includes peer-reviewed sessions, trainings/workshops, and select invited keynote presentations and speakers. Conference Themes and Topics Building on ten years of success, ApacheCon returns to the Bay Area for the 10th anniversary of the Apache Software Foundation. Comprising some of the most active and recognized developers in the Open Source community, ApacheCon provides an influential platform for dialogue between Open Source developers and users, traversing a wide range of ideas, expertise, and personalities. ApacheCon welcomes submissions across many fields, geographic locations, and areas of development. The breadth of the Apache community lends itself to conference content that is somewhat loosely-structured, with common themes of interest addressing groundbreaking technologies and emerging trends, best practices (from development to deployment), case studies and lessons learned (tips, tools, and tricks). In addition, ApacheCon will continue to offer its highly popular, two-day intensive trainings; certifications of completion will be distributed to those who fulfill all the training requirements. Topics appropriate for submission are manifold, and may include but are not restricted to: Apache HTTP server (installation, configuration, migration, and more); ASF-wide projects (including Lucene, Hadoop, Jackrabbit, and Maven); Scripting languages and dynamic content (such as Java, Perl, Python, Ruby, XSL, and PHP); Security and e-commerce (performance tuning, load balancing and high availability); New technologies (including broader initiatives such as Web Services and Web 2.0); ASF-Incubated projects (such as Sling, UIMA, and Shindig); and Business/Community issues (Open Source driven business models, open development, enterprise adoption, and more). Submission Guidelines Submissions must include; – Session title - Speaker name - Speaker biography - Session description - Format and duration - Audience expertise level Full details are available online on the CFP page at [WWW] http://us.apachecon.com/c/acus2009/cfp/ Types of Presentations; - Trainings/Workshops - General Sessions - Case Studies/Industry Profiles - Corporate Showcases & Demonstrations - Fast Feather (short) sessions - Birds of a Feather discussions - Invited Keynotes/Panels/Speakers Pre-Conference Trainings/Workshops Held on the first two days of the conference (2-3 November 2009), ApacheCon trainings are available at a registration fee beyond the regular conference fee. Proposals may be submitted for half-day (3 hours), full-day (6 hours), or two-day (12 hours) training sessions. These proposed tutorials should be aimed at providing in-depth, hands-on development experience or related continuing education. Training submissions are welcome at beginner, intermediate, and expert levels. General Sessions include presentations on practical development applications, insight into high-interest projects, best practices and key advances, overcoming implementation challenges, and industry innovations. Especially welcome are submissions that extend participants' understanding the role of ASF projects and their influence on the Open Source community at large. General Sessions are scheduled for 50 minutes and are accessible to all conference delegates. Case Study/Industry Profile Practitioners are invited to submit presentations that focus on how implementing particular ASF technologies led to improved products/solutions, service offerings, changes in work practices, among other successes. Proposals
Re: Incorrect versions for MyFaces on http://www.apache.org/licenses/exports/
As a first step I updated the version number in the Classification Matrix from 2.0 to 1.1.2 (please wait for mirrors). Well, as far as I understand we should rather specify the various MyFaces sub projects with their version number. Please give me more information about cryptography in all the MyFaces projects. Especially Trinidad, Tobago, Orchestra, Commons Thanks for your help, Manfred On Fri, Oct 31, 2008 at 7:15 PM, Mike Kienenberger <[EMAIL PROTECTED]> wrote: > Manfred, > > You still need to take action on this. > > Nothing has changed on this issue except the url. It's been 18 months. > Since the code is in myfaces-shared, I'm guessing it affects both > MyFaces Core and Tomahawk. There's some other stuff in Tomahawk now > that might qualify it too, but I haven't evaluated it. > > On Tue, Feb 20, 2007 at 10:52 PM, Mike Kienenberger <[EMAIL PROTECTED]> wrote: >> Does this help? >> >> #Generated by Maven >> #Thu Apr 13 14:18:08 EDT 2006 >> version=2.0.0 >> groupId=org.apache.myfaces.shared >> artifactId=myfaces-shared-impl >> >> So perhaps the change that needs to be made is to have it say >> "myfaces-shared 2.0" rather than simply "2.0"? >> >> http://www.apache.org/licenses/exports/ >> >> On 2/20/07, Dennis Byrne <[EMAIL PROTECTED]> wrote: >>> >>> I'm not sure why 2.0 is there. Perhaps I was thinking the version of the >>> shared lib. Anyone know which version of the shared lib we had when >>> encryption was brought in? >>> >>> Dennis Byrne >>> >>> >>> On 2/20/07, Mike Kienenberger <[EMAIL PROTECTED]> wrote: >>> > Manfred, >>> > >>> > The crypto page contains the incorrect version numbers for MyFaces. >>> > >>> > Apache MyFaces Project >>> > Product NameVersionsECCNControlled Source >>> > Apache MyFaces development 5D002 ASF >>> > 2.0 and later 5D002 ASF >>> > >>> > I'm not sure where "2.0" came into this, but we started allowing >>> > cryptography as of Myfaces version 1.1.2. See >>> > http://issues.apache.org/jira/browse/MYFACES-742 for >>> details. >>> > >>> > As pmc-chair, you should have the karma to update this page according >>> > the instructions at this url: >>> > >>> > http://www.apache.org/dev/crypto.html#sources >>> > >>> >>> >>> >>> -- >>> Dennis Byrne >> >
[OT] ApacheCon live video streaming available; keynotes and Apache 101 are free
Can't make ApacheCon this week in New Orleans? You can still watch all
the keynotes, Apache 101 sessions, and system administration track in
live video streams:
http://streaming.linux-magazin.de/en/program_apacheconus08.htm?ann
Keynotes and the Apache 101 lunchtime sessions are free; the full
sysadmin track, including httpd performance, security, and server stack
administration talks are available for a fee.
Keynotes include:
- David Recordon, Six Apart (Wednesday 09:30)
"Learning from Apache to create Open Specifications"
- Shahani Markus Weerawarana, Ph.D. (Thursday 11:30)
"Standing on the Shoulders of Giants"
- Sam Ramji, Microsoft (Friday 11:30)
"struct.new("future", :open, :microsoft)"
Reminder: New Orleans is CST or UTC/GMT -6 hours.
Advance notice: ApacheCon EU 2009 returns to Amsterdam, 23-27 March. We
had a great response to our CFP and look forward to announcing the
schedule in the next month.
---
--
Lars Eilebrecht - V.P., Conference Planning
[EMAIL PROTECTED] - http://www.us.apachecon.com
Re: new sandbox component proposal - s:globalId obsoletes "forceId"
sounds good!
+1
--Manfred
On Fri, Oct 24, 2008 at 2:12 PM, Simon Kitching <[EMAIL PROTECTED]> wrote:
> Hi All,
>
> I've always hated the "forceId" feature of tomahawk for two reasons:
> (a) it makes it dangerous to compose pages using facelets templating,
> jsp:include or similar
> (b) it only works for tomahawk components
>
> There is nothing that can be done about (a); any "flattening" of the id
> is dangerous. But sometimes it is just necessary.
>
> It is possible to do something about (b) though. JSF1.2 adds method
> UIComponentBase.getContainerClientId. A trivial component can therefore
> be written that prevents any prefix being applied to the ids of its
> child components:
>
>
># clientId = "mysubview1:btn1"
>
>
> # clientId="btn2"
># clientId="img1"
>
>
>
> The implementation is trivial:
>
> public class GlobalId extends UIComponentBase implements NamingContainer
> {
>private final static String COMPONENT_FAMILY = "oamc.GlobalId";
>
>public String getFamily()
>{
>return COMPONENT_FAMILY;
>}
>
>public String getContainerClientId(FacesContext facesContext)
>{
>return null;
>}
> }
>
> Note that this component would only work for JSF1.2 or later (though it
> will compile fine with JSF1.1).
>
> Would this be useful or not?
>
> Regards,
> Simon
>
> --
> -- Emails in "mixed" posting style will be ignored
> -- (http://en.wikipedia.org/wiki/Posting_style)
>
>
Re: JIRA: project entry needed for sandbox
>> This also demands a project site under >> "http://myfaces.apache.org/commons"; and a Commons logo of course. Any >> volunteers? ;-) Just saw that there IS already a site under http://myfaces.apache.org/commons/ Cool! What's just missing is the menu entry on the main MyFaces page. --Manfred
Re: JIRA: project entry needed for sandbox
On Tue, Oct 14, 2008 at 9:40 PM, Matthias Wessendorf <[EMAIL PROTECTED]> wrote:
> On Tue, Oct 14, 2008 at 9:33 PM, Manfred Geiler <[EMAIL PROTECTED]> wrote:
>> But Sandbox IS a part of Tomahawk and not a single project, so I do
>> not see the problem here.
>> Sandbox issues SHOULD be filed using TOMAHAWK and - of course - the
>> regarding component ("SubForm", "PPRPanelGroup", ...).
>>
>> -1 for a new Jira project(!)
>
> for tomahawk, right ?
> +1 on that
you mean +1 for my -1 ?
Wow!
:-)
That's like:
"I am against being in favor"
or:
"I am in favor of being against"
Which is actually the same. Is it? Hmm. Very philosophical... :-)
--Manfred
Re: JIRA: project entry needed for sandbox
On Tue, Oct 14, 2008 at 5:35 PM, Volker Weber <[EMAIL PROTECTED]> wrote: > Hi, > > 2008/10/14 Simon Kitching <[EMAIL PROTECTED]>: >> Any JIRA admins here? >> >> There currently is no JIRA project defined for the myfaces sandbox. It >> appears that people have simply been using TOMAHAWK to file bugs against. >> But as recent releases has used a jira report as the "release notes" this is >> causing confusion. > > a Myfaces-Commons is also missing. Other than "Tomahawk Sandbox" the "MyFaces Commons" is a standalone project under the MyFaces umbrella. So a Jira project makes sense here. This also demands a project site under "http://myfaces.apache.org/commons"; and a Commons logo of course. Any volunteers? ;-) If everyone is ok with it, I will create the Jira project for "MyFaces Commons" with the Jira-ID "MFCOMMONS". --Manfred
Re: JIRA: project entry needed for sandbox
But Sandbox IS a part of Tomahawk and not a single project, so I do
not see the problem here.
Sandbox issues SHOULD be filed using TOMAHAWK and - of course - the
regarding component ("SubForm", "PPRPanelGroup", ...).
-1 for a new Jira project(!)
--Manfred
On Tue, Oct 14, 2008 at 4:06 PM, Simon Kitching <[EMAIL PROTECTED]> wrote:
> Any JIRA admins here?
>
> There currently is no JIRA project defined for the myfaces sandbox. It
> appears that people have simply been using TOMAHAWK to file bugs against.
> But as recent releases has used a jira report as the "release notes" this is
> causing confusion.
>
> Can someone please create it? The name SANDBOX is already taken, so perhaps
> "MF-SANDBOX" or similar could be used.
>
> Perhaps we should file a jira issue to create the new project? :-)
>
>
Re: Handling component rendered state during postback
My understanding of attributes with a value binding is, that the EL expressions must ALWAYS be evaluated dynamically and must never be cached. The same applies for the "rendered" attribute. There is (should be) no special handling IMHO. Regarding "ugly problems" and performance issues: My feeling is, that both can be avoided by having a well designed model. Please give us an example, Simon, if you cannot agree. --Manfred On Tue, Aug 5, 2008 at 4:27 PM, Simon Kitching <[EMAIL PROTECTED]> wrote: > Hi, > > A question on the user list reminded me of something I've been puzzled about > for quite a while. > > Does the JSF spec actually say that "rendered" EL expressions should be > re-evaluated during postback? That's what MyFaces currently does, but it > seems to me that the true/false state should really be part of the > component's saved state and the restored value simply used during postback > (and recalculated in render phase). > > Does anyone know why in the current myfaces implementation each component > recomputes its "rendered" state during postback by using its EL expression > rather than using a value cached from the render phase? > > Using a cached value would avoid some ugly problems with EL expressions > being called before updateModel, as well as being a significant performance > boost (rendered property tends to get queried several times during > postback). > > Regards, Simon > >
[OT] Travel Assistance to ApacheCon US 2008 - 3 days to apply!
The Travel Assistance Committee is taking in applications for those wanting to attend ApacheCon US 2008 between the 3rd and 7th November 2008 in New Orleans. The Travel Assistance Committee is looking for people who would like to be able to attend ApacheCon US 2008 who need some financial support in order to get there. There are VERY few places available and the criteria is high, that aside applications are open to all open source developers who feel that their attendance would benefit themselves, their project(s), the ASF and open source in general. Financial assistance is available for flights, accommodation and entrance fees either in full or in part, depending on circumstances. It is intended that all our ApacheCon events are covered, so it may be prudent for those in Europe and or Asia to wait until an event closer to them comes up - you are all welcome to apply for ApacheCon US of course, but there must be compelling reasons for you to attend an event further away that your home location for your application to be considered above those closer to the event location. More information can be found on the main Apache website at http://www.apache.org/travel/index.html - where you will also find a link to the application form and details for submitting. Time is very tight for this event, so applications are open now and will end on the 2nd October 2008 - to give enough time for travel arrangements to be made. Good luck to all those that will apply. Regards, The Travel Assistance Committee
Re: Make dev@ private?
-1 for permissions change for dev@ +1 for a clearer description any native speaker volunteering? --Manfred On Thu, Sep 4, 2008 at 6:54 PM, Simon Lessard <[EMAIL PROTECTED]> wrote: > -1 > > However, it's true that Apache product users often consider themselves > developer and thus post on the developer forum even when their question > should really be on the user list. We could probably reduce such occurrences > a little by adding a clearer explanation of the purpose of each list on the > mailing page. > > > Regards, > > ~ Simon > > On Thu, Sep 4, 2008 at 12:12 PM, Paul Spencer <[EMAIL PROTECTED]> wrote: >> >> Andrew, >> >> The dev@ mailing list is described on the Jakarts site[1] as: >> The "Developer" lists where you can send questions and comments about >> the actual software source code and general "development" types of >> questions. >> >> Making the developer list private is extreme and I would resist this >> change. Their are many productive discussion on the developer list that >> include non-committers or non-pmc members. >> >> Are the posting to the developer list because the question is not answered >> on the user list? If so, then lets address this problem first. If not, >> then should the response to an user@ post on the dev@ list be something like >> "You have posted this to the wrong list, please repost this on the user@ >> list" >> >> The dev@ mailing list is described on the Jakarts site[1] as: >> The "Developer" lists where you can send questions and comments about >> the actual software source code and general "development" types of >> questions. >> >> Making the developer list private is extreme. Their are many discussion >> on the developer list that include non-committers or non-pmc members. >> >> >> Paul Spencer >> >> [1]http://jakarta.apache.org/site/mail.html >> >> >> Andrew Robinson wrote: >>> >>> Is it possible to make dev@ a private mailing list, so only commiters >>> and people that PMCs decide should have access to post are allowed to >>> send emails to this list? That way we can reduce the accidental >>> posting to dev@ instead of [EMAIL PROTECTED] >>> >>> -Andrew >>> >> > >
Re: [VOTE] release of myfaces core 1.2.4
+0 thanks Leonardo! --Manfred On Wed, Aug 27, 2008 at 8:07 PM, Leonardo Uribe <[EMAIL PROTECTED]> wrote: > Hi, > > I was running the needed tasks to get the 1.2.4 release of Apache > MyFaces core out. > > The artifacts passed all TCK test. > > Please note that this vote concerns all of the following parts: > 1. Maven artifact group "org.apache.myfaces.shared" v3.0.4 [1] > 2. Maven artifact group "org.apache.myfaces.core" v1.2.4 [1] > > The artifacts are deployed to my private Apache account ([1] and [3] for > binary and source packages). > > The release notes could be found at [4]. > > Also the clirr test does not show binary incompatibilities with myfaces-api. > > Please take a look at the "1.2.4" artifacts and vote! > > Please note: This vote is "majority approval" with a minimum of three > +1 votes (see [3]). > > > [ ] +1 for community members who have reviewed the bits > [ ] +0 > [ ] -1 for fatal flaws that should cause these bits not to be released, > and why.. > > > Thanks, > Leonardo Uribe > > [1] http://people.apache.org/~lu4242/myfaces124 > [2] http://www.apache.org/foundation/voting.html#ReleaseVotes > [3] http://people.apache.org/~lu4242/myfaces124binsrc > [4] > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600&styleName=Html&version=12313378 > -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: Jira configuration ? (was Fwd: [Trinidad] Missing issue in 1.0.8)
Ok, re-enabled the "fix version" on the edit screen.
--Manfred
On Thu, Aug 21, 2008 at 10:50 AM, Matthias Wessendorf <[EMAIL PROTECTED]> wrote:
> On Thu, Aug 21, 2008 at 10:42 AM, Volker Weber <[EMAIL PROTECTED]> wrote:
>> Hi,
>>
>> isn't the fixVersion field needed for unresolved issues to prepare the
>> roadmap?
>
> yes. I think the main point is, that actually bug-filers abuse the field.
> They understand it as a "wish list", like "you have to fix my bug in
> version 'yesterday'" :)
>
> -Matthias
>
>>
>>
>> Regards,
>>Volker
>>
>> 2008/8/21 Manfred Geiler <[EMAIL PROTECTED]>:
>>> The "Fix version" field is still there on the "Resolve Issue" page!
>>> That is where it belongs to. Right?
>>>
>>> But: I see that there are 964 issues (in all MyFaces projects) with
>>> Status "Resolved" that have no "Fix Version". Which is weird!
>>>
>>> What I COULD do is (re)enable the "fix version" on the Edit Screen.
>>> But I CANNOT restrict it to committers only. There is no way in Jira
>>> AFAIK.
>>>
>>> What I suggest:
>>> - Leave it that way. Fix versions normally set during resolve workflow.
>>> - Fix missing fix versions by doing bulk operations ("Fix version" is
>>> editable there)
>>>
>>> Thoughts?
>>>
>>> --Manfred
>>>
>>>
>>>
>>>
>>>
>>> On Thu, Aug 21, 2008 at 10:11 AM, Bernd Bohmann
>>> <[EMAIL PROTECTED]> wrote:
>>>> Hello Manfred,
>>>>
>>>> how can I edit the fix version field, now?
>>>>
>>>> I would like to prepare the tobago-1.0.18 release.
>>>>
>>>> Can you revert the MyFaces Screen configuration for Tobago.
>>>>
>>>> Regards
>>>>
>>>> Bernd
>>>>
>>>> Manfred Geiler schrieb:
>>>>> The Jira permissions settings cannot be adjusted on field level.
>>>>> As a workaround I added a new "MyFaces Screen" configuration to Jira.
>>>>> With this configuration the "Fix version" field should no longer show
>>>>> up on the "Edit" screen.
>>>>> I activated this scheme for Trinidad.
>>>>> Please check it out. If ok, I will activate this scheme for all other
>>>>> MyFaces projects as well.
>>>>>
>>>>> --Manfred
>>>>>
>>>>>
>>>>> On Tue, Aug 5, 2008 at 10:27 PM, Matthias Wessendorf <[EMAIL PROTECTED]>
>>>>> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> we had the discussion already in the past.
>>>>>> I'd love to see that the fix-version/s is not! editable by filers.
>>>>>>
>>>>>> Greetings,
>>>>>> Matthias
>>>>>>
>>>>>>
>>>>>> -- Forwarded message --
>>>>>> From: Rottstock, Sven <[EMAIL PROTECTED]>
>>>>>> Date: Tue, Aug 5, 2008 at 10:35 AM
>>>>>> Subject: [Trinidad] Missing issue in 1.0.8
>>>>>> To: dev@myfaces.apache.org
>>>>>>
>>>>>>
>>>>>> Hi Devs,
>>>>>>
>>>>>> i have seen that the patch of TRINIDAD-1010 was not included in the
>>>>>> 1.0.8 release but was listed in the release notes. Is there anything
>>>>>> wrong with it or was the patch only forgotten to submit?
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Sven
>>>>>>
>>>>>>
>>>>>
>>>
>>
>>
>>
>> --
>> inexso - information exchange solutions GmbH
>> Bismarckstraße 13 | 26122 Oldenburg
>> Tel.: +49 441 4082 356 |
>> FAX: +49 441 4082 355 | www.inexso.de
>>
>
>
>
> --
> Matthias Wessendorf
>
> Need JSF and Web 2.0?
> http://code.google.com/p/facesgoodies
>
> further stuff:
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> mail: matzew-at-apache-dot-org
Re: Jira configuration ? (was Fwd: [Trinidad] Missing issue in 1.0.8)
The "Fix version" field is still there on the "Resolve Issue" page!
That is where it belongs to. Right?
But: I see that there are 964 issues (in all MyFaces projects) with
Status "Resolved" that have no "Fix Version". Which is weird!
What I COULD do is (re)enable the "fix version" on the Edit Screen.
But I CANNOT restrict it to committers only. There is no way in Jira
AFAIK.
What I suggest:
- Leave it that way. Fix versions normally set during resolve workflow.
- Fix missing fix versions by doing bulk operations ("Fix version" is
editable there)
Thoughts?
--Manfred
On Thu, Aug 21, 2008 at 10:11 AM, Bernd Bohmann
<[EMAIL PROTECTED]> wrote:
> Hello Manfred,
>
> how can I edit the fix version field, now?
>
> I would like to prepare the tobago-1.0.18 release.
>
> Can you revert the MyFaces Screen configuration for Tobago.
>
> Regards
>
> Bernd
>
> Manfred Geiler schrieb:
>> The Jira permissions settings cannot be adjusted on field level.
>> As a workaround I added a new "MyFaces Screen" configuration to Jira.
>> With this configuration the "Fix version" field should no longer show
>> up on the "Edit" screen.
>> I activated this scheme for Trinidad.
>> Please check it out. If ok, I will activate this scheme for all other
>> MyFaces projects as well.
>>
>> --Manfred
>>
>>
>> On Tue, Aug 5, 2008 at 10:27 PM, Matthias Wessendorf <[EMAIL PROTECTED]>
>> wrote:
>>> Hi,
>>>
>>> we had the discussion already in the past.
>>> I'd love to see that the fix-version/s is not! editable by filers.
>>>
>>> Greetings,
>>> Matthias
>>>
>>>
>>> -- Forwarded message --
>>> From: Rottstock, Sven <[EMAIL PROTECTED]>
>>> Date: Tue, Aug 5, 2008 at 10:35 AM
>>> Subject: [Trinidad] Missing issue in 1.0.8
>>> To: dev@myfaces.apache.org
>>>
>>>
>>> Hi Devs,
>>>
>>> i have seen that the patch of TRINIDAD-1010 was not included in the
>>> 1.0.8 release but was listed in the release notes. Is there anything
>>> wrong with it or was the patch only forgotten to submit?
>>>
>>> Regards,
>>>
>>> Sven
>>>
>>>
>>
Re: svn commit: r686525 - /myfaces/core/tags/1_1_6/
Hmm, long time ago since I wrote this "diary" Cannot remember the exact reason. Maybe the idea was it to have the branch available for a quick fix. i.e. to do a quick 1.1.7 when a security flaw arises and the trunk is already unstable due to other changes and cannot be used for the release. We once had that situation because of a javascript injection vulnerability that was detected shortly after the release. Of course you could always achieve this by copying the tag to the branches folder on demand later. But since SVN copies are only pointers this is no big problem IMO. So I'd rather keep the tradition. However, feel free to adopt the release process. --Manfred On Mon, Aug 18, 2008 at 9:07 PM, Leonardo Uribe <[EMAIL PROTECTED]> wrote: > > > On Mon, Aug 18, 2008 at 11:38 AM, simon <[EMAIL PROTECTED]> wrote: >> >> On Sat, 2008-08-16 at 17:19 +, [EMAIL PROTECTED] wrote: >> > Author: lu4242 >> > Date: Sat Aug 16 10:19:13 2008 >> > New Revision: 686525 >> > >> > URL: http://svn.apache.org/viewvc?rev=686525&view=rev >> > Log: >> > Copy from branch to trunk for release procedure >> > >> > Added: >> > myfaces/core/tags/1_1_6/ >> > - copied from r686524, myfaces/core/branches/1_1_6/ >> > >> >> Just a very minor question: why copy instead of move? >> Presumably you'll need to now delete that branch... >> > > Really is a procedure copied from 1.1.5. See: > > http://wiki.apache.org/myfaces/CoreRelease115 > > But I don't know the specific reason about let the branch and the tag. > > regards > > Leonardo Uribe >
Re: Continuum environment upgrade
+1 for option (1) Already ran through recreating config myself some months ago. Simon, thanks for taking this over! Please be careful with the automatic site build. I once managed to destroy the myfaces site with continuum, which was then screwed up half a day because of mirror delays. Remember? ;-) --Manfred On Mon, Aug 18, 2008 at 2:04 PM, Simon Kitching <[EMAIL PROTECTED]> wrote: > Hi All, > > I managed to get continuum-1.1 installed and running on > myfaces.zones.apache.org, and also to get the user accounts loaded into the > new instance. > > However I just cannot get the existing build configuration to load. The load > appears to go ok, but continuum just fails to restart afterwards. > > So the options are: > (1) go with new installation, and recreate the project config > (2) move to using the central server at vmbuild.apache.org (which will mean > creating all new user accounts, as well as manually recreating the project > config) > (3) leave myfaces on continuum-1.1-beta-2 forever > (4) someone else can have a try > > Personally, I'm happy with (1). Adding the projects again is only an hour's > work or so. > > I think that we work our install hard enough to justify using a separate > server rather than a central one. > > Opinions? > > Regards, > Simon > > -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [Idea] reCAPTCHA JSF component
On Thu, Aug 14, 2008 at 10:13 PM, Mike Kienenberger <[EMAIL PROTECTED]> wrote: > I think what Manfred is suggesting is that we implement a reCAPTCHA > component specifically rather than captcha in general. For those > people who want to secure their applications and promote digital book > scan correcting at the same time :-) yes, exactly. > On 8/14/08, Hazem Saleh <[EMAIL PROTECTED]> wrote: >> Hi Manfred, >> >> I already implemented one >> http://myfaces.apache.org/tomahawk/tagdoc/t_captcha.html >> :). of course I know we already have a captcha comp. ;-) perhaps it's possible to add the "reCAPTCHA" functionality as a feature to the existing component? --Manfred
[Idea] reCAPTCHA JSF component
Just came across the http://recaptcha.net/ website and wondered if anyone is willing to develop (and contribute) a reCAPTCHA JSF component for Tomahawk? >From the website: "reCAPTCHA is a free CAPTCHA service that helps to digitize books. A CAPTCHA is a program that can tell whether its user is a human or a computer. You've probably seen them — colorful images with distorted text at the bottom of Web registration forms. CAPTCHAs are used by many websites to prevent abuse from "bots," or automated programs usually written to generate spam. No computer program can read distorted text as well as humans can, so bots cannot navigate sites protected by CAPTCHAs." Shouldn't be that difficult. There are already some implementations for different languages/systems but none yet for JSF: http://recaptcha.net/resources.html So, when beijing08 bores you - this is your opportunity! ;-) --Manfred
Re: [VOTE] Release of Portlet Bridge Master POM v2
+1 On Thu, Aug 14, 2008 at 11:46 AM, Scott O'Bryan <[EMAIL PROTECTED]> wrote: > Hi, > > I'm trying to release the MyFaces Portlet Bridge Master POM v2. This pom > file was created in order to support the latest portlet-bridge project's > website as well as the multiple open code lines needed for this project > going forward. This file manages the commonalities between all of the > Portlet Bridge projects and is derived off of the MyFaces Master POM v. 6. > > I was running the needed tasks to get the v2 release of the Apache MyFaces > Portlet Bridge Master pom out. The artifacts are deployed to my private > Apache account ([1]). > > Please take a look at the "portlet-bridge-master-pom-1" artifacts and vote > > > [ ] +1 for community members who have reviewed the bits > [ ] +0 > [ ] -1 for fatal flaws that should cause these bits not to be released, > and why.. > > > Thanks, > Scott > > [1] > http://people.apache.org/~sobryan/portlet-bridge/portlet-bridge-master-pom-2/ > -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [VOTE] release of myfaces core 1.1.6
+0 (unfortunately stuck in my day job - no time for testing - but appreciating the new release) Thanks Leonardo! --Manfred On Tue, Aug 12, 2008 at 11:11 PM, Leonardo Uribe <[EMAIL PROTECTED]> wrote: > Hi, > > I was running the needed tasks to get the 1.1.6 release of Apache > MyFaces core out. > > The artifacts passed all TCK test. > > It also passes maven clirr test (mvn clirr:check -DcomparsionVersion=1.1.5). > > Please note that this vote concerns all of the following parts: > 1. Maven artifact group "org.apache.myfaces.shared" v2.0.8 [1] > 2. Maven artifact group "org.apache.myfaces.core" v1.1.6 [1] > > The artifacts are deployed to my private Apache account ([1] and [3] for > binary and source packages). > > The release notes could be found at [4]. > > Also the clirr test does not show binary incompatibilities with myfaces-api. > > Please take a look at the "1.1.6" artifacts and vote! > > Please note: This vote is "majority approval" with a minimum of three > +1 votes (see [3]). > > > [ ] +1 for community members who have reviewed the bits > [ ] +0 > [ ] -1 for fatal flaws that should cause these bits not to be released, > and why.. > > > Thanks, > Leonardo Uribe > > [1] http://people.apache.org/~lu4242/myfaces116 > [2] http://www.apache.org/foundation/voting.html#ReleaseVotes > [3] http://people.apache.org/~lu4242/myfaces116binsrc > [4] > https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12312312&styleName=Html&projectId=10600 > -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: Jira configuration ? (was Fwd: [Trinidad] Missing issue in 1.0.8)
The Jira permissions settings cannot be adjusted on field level. As a workaround I added a new "MyFaces Screen" configuration to Jira. With this configuration the "Fix version" field should no longer show up on the "Edit" screen. I activated this scheme for Trinidad. Please check it out. If ok, I will activate this scheme for all other MyFaces projects as well. --Manfred On Tue, Aug 5, 2008 at 10:27 PM, Matthias Wessendorf <[EMAIL PROTECTED]> wrote: > Hi, > > we had the discussion already in the past. > I'd love to see that the fix-version/s is not! editable by filers. > > Greetings, > Matthias > > > -- Forwarded message -- > From: Rottstock, Sven <[EMAIL PROTECTED]> > Date: Tue, Aug 5, 2008 at 10:35 AM > Subject: [Trinidad] Missing issue in 1.0.8 > To: dev@myfaces.apache.org > > > Hi Devs, > > i have seen that the patch of TRINIDAD-1010 was not included in the > 1.0.8 release but was listed in the release notes. Is there anything > wrong with it or was the patch only forgotten to submit? > > Regards, > > Sven > >
[jira] Updated: (MYFACES-152) ResponseWriter.endDocument() abuse breaks ADF Faces
[ https://issues.apache.org/jira/browse/MYFACES-152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Geiler updated MYFACES-152: --- Status: Patch Available (was: Reopened) > ResponseWriter.endDocument() abuse breaks ADF Faces > --- > > Key: MYFACES-152 > URL: https://issues.apache.org/jira/browse/MYFACES-152 > Project: MyFaces Core > Issue Type: Bug > Components: General >Affects Versions: 1.0.9m9 >Reporter: Adam Winer >Assignee: Bruno Aranda >Priority: Critical > > I've been shown some problems lately with MyFaces 1.0.9 and ADF Faces. > The problems specifically trace to MyFaces's use of > ResponseWriter.endDocument() to output Javascript. Since ADF Faces > runs with its own RenderKit (and therefore its own ResponseWriter), > this Javascript is getting dropped and not written. > I'd recommend (both as JSF EG guy and ADF Faces guy) that this MyFaces > code be moved *out* of ResponseWriter.endDocument(). Specifically: > - ResponseWriter.endDocument() is not guaranteed to be called before > the close of or even the close of , and therefore this > script cannot be safely output at this point. It's quite likely that > changes in JSF 1.2 will essentially guarantee that endDocument() is > not called until the close of all output. > - This is not really the intent of ResponseWriter.endDocument(). In > HTML, it should be a no-op. It's there for more bizarre scenarios > like a ResponseWriter outputting a SOAP envelope around a response. > - It's breaking ADF Faces. :) > A significantly cleaner way to output needed Javascript is to add it > as needed from the Renderers that require it (using a request-scoped > attribute to track if its been added already). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-152) ResponseWriter.endDocument() abuse breaks ADF Faces
[ https://issues.apache.org/jira/browse/MYFACES-152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Geiler updated MYFACES-152: --- Status: Open (was: Patch Available) > ResponseWriter.endDocument() abuse breaks ADF Faces > --- > > Key: MYFACES-152 > URL: https://issues.apache.org/jira/browse/MYFACES-152 > Project: MyFaces Core > Issue Type: Bug > Components: General >Affects Versions: 1.0.9m9 >Reporter: Adam Winer >Assignee: Bruno Aranda >Priority: Critical > > I've been shown some problems lately with MyFaces 1.0.9 and ADF Faces. > The problems specifically trace to MyFaces's use of > ResponseWriter.endDocument() to output Javascript. Since ADF Faces > runs with its own RenderKit (and therefore its own ResponseWriter), > this Javascript is getting dropped and not written. > I'd recommend (both as JSF EG guy and ADF Faces guy) that this MyFaces > code be moved *out* of ResponseWriter.endDocument(). Specifically: > - ResponseWriter.endDocument() is not guaranteed to be called before > the close of or even the close of , and therefore this > script cannot be safely output at this point. It's quite likely that > changes in JSF 1.2 will essentially guarantee that endDocument() is > not called until the close of all output. > - This is not really the intent of ResponseWriter.endDocument(). In > HTML, it should be a no-op. It's there for more bizarre scenarios > like a ResponseWriter outputting a SOAP envelope around a response. > - It's breaking ADF Faces. :) > A significantly cleaner way to output needed Javascript is to add it > as needed from the Renderers that require it (using a request-scoped > attribute to track if its been added already). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: commons logging again
I have used SLF4J for some time now in a number of projects and did
not have any (serious) problem yet.
The biggest problem was that some classes where not serializable. So
when used in web apps that store objects with loggers in session or
client this was an issue of course. But this was fixed in the latest
stable release.
What I like about SLF4J is the clear separation of the API for
compiletime/runtime and the log implementation specific stub libraries
for runtime only. When using with Maven you can have clean
dependencies:
1. define a *compile* dep to slf4j-api for all your modules
2. define a *test* dep to slf4j-log4j12 to log unit testing output with Log4J
3. define a *runtime* dep to slf4j-log4j12 for the webapp module to
log with Log4J
4. define a *runtime* dep to jcl-over-slf4j to reroute third-party
lib's JCL logging over SLF4J
So, if (for some reason) you want to switch over from Log4J to
JDK-Logging all you need to do is replace the runtime dep to
slf4j-log4j12 (number 3) by a dependency to slf4j-jdk14.
Another nice feature of SLF4J is the chance to get rid of those ugly
"if(logger.isDebugEnabled()) {" lines by using parameterized messages
(see http://www.slf4j.org/faq.html#logging_performance)
--Manfred
On 7/14/08, Werner Punz <[EMAIL PROTECTED]> wrote:
> Ok I just saw that the slf4j people provide a thin api layer
> which replaces the commons logging if needed.
>
> Then probably replacing commons logging is a non issue.
> I just was raising this issue again, due to the problems i read
> about log4j especially in combination with was and other big irons
> which drop their own classloaders, and due to the fact that I feel
> it is generally a bad idea for a low level library to have too many
> dependencies into other libs.
>
> Werner
>
>
>
> [EMAIL PROTECTED] schrieb:
>> Werner Punz schrieb:
>>> Hello everyone, we have been using commons-logging the past years.
>>> I am not sure if it is a good idea,
>>> first of all java has a decent logging api, which would allow us to
>>> eliminate the logging dependency.
>> Using a logging API built into the JDK does feel tempting.
>>
>> However before doing this, have a look at the number of alternative
>> implementations of the API.
>> * The one built into the JDK sucks. badly.
>> * There is one that is built into Tomcat (JULI) but that is not
>> available as a standalone lib.
>> * The SLF4J project provides "jcl-over-slf4j". I haven't used this
>> myself, but presume that it needs to be in the system classpath to work
>> (one of the major issues with the java.util.logging design). So I'm not
>> sure how that would interact with Tomcat's JULI logging. See:
>> http://slf4j.org/api/org/slf4j/bridge/SLF4JBridgeHandler.html
>>
>> I'm not aware of any other implementations.
>>
>> And I'm not at all sure whether it is possible for different webapps
>> running in the same container to have different logging configuration.
>> It would be ugly to force a solution on users where all logging from all
>> their webapps ends up mixed together in the same output file. So I would
>> suggest analysing things carefully before moving to java.util.logging.
>>
>> I have the feeling that java.util.logging was designed by Sun JDK
>> implementers to help debugging JDK (java.*) code. For that purpose it
>> works fine. Using it from application code seems far less useful..
>>
>>> Secondly,I have not looked into the code yet, but there are a load
>>> of references that commons logging has problems due to messing around
>>> with the classloader.
>> That's an ancient issue. There have been zero issues related to this
>> reported since the 1.1 commons release.
>>
>>> Projects like Tapestry already have moved away towards SLF4J which
>>> apparently is better.
>> "apparently" doesn't sound like a terribly convincing reason to me to
>> move from one log wrapper to another.
>>>
>>> Whats your opinion should we keep the commons logging
>>> references?
>> Despite being a commons-logging developer, I don't care what
>> implementation is used. But AFAIK we do have a working solution now; I'd
>> like to be sure that whatever we move towards
>> (a) actually does work (java.util.logging), and
>> (b) brings benefits that are worth the effort of converting over (slf4j)
>>
>>
>> Regards,
>> Simon
>>
>>
>
>
--
http://www.irian.at
Your JSF powerhouse - JSF Consulting,
Development and Courses in English and
German
Professional Support for Apache MyFaces
Re: 百分百营销软件网发送的测试信息。
Sorry guys, I hit the wrong button in my mail app when browsing 200 moderate mails after coming back from vacation... Time for a coffee! ;-) --Manfred On 7/27/08, 百分百营销软件网 <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] > [EMAIL PROTECTED] > [EMAIL PROTECTED] > [EMAIL PROTECTED] -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [VOTE] release checkstyle module v1, release myfaces-master-pom v6
+1 release checkstyle +1 release master pom --Manfred On Wed, Jul 9, 2008 at 9:51 PM, simon <[EMAIL PROTECTED]> wrote: > Hi, > > (1) > I'd like to make a first release of the new checkstyle module. The > release candidate has been put in a branch here: > http://svn.apache.org/repos/asf/ >myfaces/myfaces-build-tools/branches/ > prepare-checkstyle-rules-1/ > which will be moved to the tags dir if the vote passes. > > The release artifacts can be found in the staging repo at: > http://people.apache.org/builds/myfaces/m2-staging-repository/ > org/apache/myfaces/buildtools/checkstyle-rules/1 > > Note that making this release does not affect any existing code; only > projects that are configured to actually use it are affected. > > (2) > I'd like to make a new release of the myfaces-master-pom module. The > release candidate has been put in a branch here: > http://svn.apache.org/repos/asf/ >myfaces/myfaces-master-pom/branches/ > prepare-myfaces-6/ > which will be moved to the tags dir if the vote passes. > > The release artifacts can be found in the staging repo at: > http://people.apache.org/builds/myfaces/m2-staging-repository/ >org/apache/myfaces/myfaces/6/ > > Note that making this release does not affect any existing code; only > projects that are configured to actually use it are affected. > > The previous (-5) release was based on svn revision 613141. Changes > since last release are: > * new developers bhuemer, sobryan, ctoth > * fix pmc status for imario > * tweaks to mailing list urls > * checkstyle stuff > > Regards, Simon > > > > [ ] release checkstyle > [ ] release master pom > > -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [Build] philosophy behind the myfaces build ?
What matthias ment was, that we should rather have no myfaces-inter-subproject-snapshot-dependencies. I second that. The trunk of a MyFaces sub-project should always depend on release versions of other projects UNLESS there is a good reason for having a dependency to a snapshot. What reasons are there? 1. the other project has a new feature we depend on and has not yet released 2. there is no release yet of the other project 3. ...more? In all cases the snapshot dependency should be a temporary option and as soon as the other is released we should switch to release dependency (again). --Manfred On Mon, Jun 16, 2008 at 8:55 AM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Matthias Wessendorf schrieb: >> Hi, >> >> when doing a checkout of myfaces, pretty much everything is build. >> Fine. >> Except Trinidad and Tobago. No problem with that. >> >> But, when just updating a single svn-folder, like tomahawk, there is a very >> high chance that the build pretty much fails. Why? because it depends >> on snapshots that are build via the "master myfaces" build. >> >> In this case I am refering to the myfaces-builder plugin. >> >> Isn't is kinda annoying that you always have to build all? >> Just b/c of a snapshot dependency? >> At least to me. >> >> Why not "testing" the builder-snapshot in a branch (like >> tomahawk-move-to-builder-branch). >> Do a builder release, once stable. And update trunk. (I am only using >> builder-plug as an example). >> >> That's what we do for Trinidad. It doesn't depend on a snapshot >> plugin, so it is easy (and >> straightforward) to build it. >> >> Not sure why there is this, build the world first philosophy :-) >> >> What do you think ? >> >> > Add the following to ~/.m2/settings.xml. Then add "-Papachesnap" when > building a project. > > This allows maven to download stuff published to the snapshot > repository. Which is kind of useful when building snapshot projects :-) > > > > > apachesnap > > > apache.org > Maven Snapshots > http://people.apache.org/repo/m2-snapshot-repository > >false > > >true > > > > > > apache.org > Maven Plugin Snapshots > http://people.apache.org/repo/m2-snapshot-repository > >false > > >true > > > > > > > > Regards, > Simon > > -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: cleaning up whitespace in source files
Simon, Do you have a number? How many files do have tab characters? I think (b - fix them) would be the better solution. But only if that does not change every second file. --Manfred On Wed, Jul 2, 2008 at 7:28 PM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Hi All, > > In the new checkstyle rules file I enabled checks for tab characters, as the > myfaces convention is (AFAIK) to use 4 spaces, not tabs. However the > checkstyle report points out a lot of files containing tabs. > > It's no big deal, but do we want to: > (a) disable the checkstyle rule and ignore tabs or > (b) fix them? > > Tabs are a minor nuisance when viewing the source as some tools render 4 > spaces, some 8. > > I've written a simple shellscript that can clean this up very easily, and am > happy to do so. The script also removes trailing whitespace from lines, of > which we also appear to have quite a lot. > > But doing this will create some large commit messages and make comparing > files with past versions noisier. It can also cause svn conflicts if people > have modified files they have not yet committed, unless they run the cleanup > script against their own working dir before doing svn update. > > So, option (a) or (b)? > > Regards, Simon > > -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: Checkstyle rules
+1 (yes, change the myfaces-master-pom ...) --Manfred On Mon, Jun 30, 2008 at 11:28 PM, simon <[EMAIL PROTECTED]> wrote: > Hi, > > As I mentioned a few weeks ago, I'd like to clean up the way we do our > checkstyle rule checking. Right now we point the maven-checkstyle-report > plugin directly at a file in the svn repository. > > Using svn directly does have the benefit of simplicity, and allows us to > update the rules easily. However it has the following disadvantages: > * prevents us from changing our repository layout without breaking old > releases. > * changing the rules changes the report generated when rebuilding old > releases > * cannot build maven site without network access to svn repo. > > The alternative is to create a maven artifact containing the checkstyle > rules and deploy it to the repository. Then this artifact can be used by > the report plugin. This fixes all of the above. The only real > disadvantage is that to update the checkstyle rules we need to release a > new version of the rules artifact, then update the master pom. That's no > big deal though. > > I have already checked in a checkstyle module here: > http://svn.apache.org/repos/asf/myfaces/myfaces-build-tools/trunk/other/checkstyle-rules/ > > The original checkstyle rules file had almost every check commented out; > in this module I have enabled the checks I think are reasonable. Note > that this module also holds tobago checkstyle rules, although I have no > idea whether the tobago team want to use this or not; this is mostly to > demonstrate that separate checkstyle rules *can* be in the same > checkstyle artifact if it is desired. Or can be overridden in a project, > just by redefining the maven-checkstyle-plugin configuration. > > The patch below to the myfaces-master-pom would then switch over to > using this new module. Note that the checkstyle plugin is now configured > in not . Using makes no > sense if we then reference the plugin in the reporting section of the > same pom. > > Could you please indicate: > [+1] yes, change the myfaces-master-pom to use checkstyle rules > artifact > [-1] no, leave things alone and remove the new checkstyle artifact > > If people are happy with this, I will update the master pom, leave it to > settle in for a week or so, then call a vote to make a release of both > the rules artifact and a new master pom. > > Thanks, > Simon > > > Index: pom.xml > === > --- pom.xml (revision 660720) > +++ pom.xml (working copy) > @@ -639,6 +639,20 @@ > > install > > + > + > +maven-checkstyle-plugin > +2.2 > + > + > +org.apache.myfaces.buildtools > +checkstyle-rules > +1-SNAPSHOT > + > + > + > + > + > > - > http://svn.apache.org/repos/asf/myfaces/myfaces-master-pom/trunk/checkstyle/default/myfaces-checks.xml > - > http://svn.apache.org/repos/asf/myfaces/myfaces-master-pom/trunk/checkstyle/default/myfaces-header.txt > + > default/myfaces-checks.xml > + > default/myfaces-header.txt > > > > > -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
[jira] Commented: (TOMAHAWK-1291) t:graphicImage doesnot generate XHTML complaint code
[ https://issues.apache.org/jira/browse/TOMAHAWK-1291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12609182#action_12609182 ] Manfred Geiler commented on TOMAHAWK-1291: -- +1 for a strict (but sweet-tempered) behaviour that means: - log a nag warning - render a non-empty alt attribute with a "meaningful" default text if the developer omits the attribute (or provides an empty one) > t:graphicImage doesnot generate XHTML complaint code > > > Key: TOMAHAWK-1291 > URL: https://issues.apache.org/jira/browse/TOMAHAWK-1291 > Project: MyFaces Tomahawk > Issue Type: Bug >Affects Versions: 1.1.7-SNAPSHOT >Reporter: Hazem Saleh >Assignee: Hazem Saleh > Fix For: 1.1.7-SNAPSHOT > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Time for an Orchestra 1.2 release?
+1 --Manfred On Tue, Jun 24, 2008 at 5:45 PM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Hi All, > > I'm about to start working on a new Orchestra feature (basic "dialog > support"). > > It therefore seems a good idea to get an Orchestra release out before I > start messing with the trunk. In particular, there are two bugs which are > fixed in trunk and would be good to have in an official release: > * ORCHESTRA-21 Issue with weird urls (esp. ones created by Trinidad) > * ORCHESTRA-23 (locking bug, triggered by ajax or double-click) > > There are also a couple of minor enhancements, but not much has really > happened since the 1.1 release. > > As always, there is more we *could* do; there are a couple of open bug > issues. But none of them are simple to tackle, so I'd rather get 1.2 out now > and tackle the other issues (esp. portlets) at some later time. > > I've created a release branch in svn, and taken out a few things that are > not completely baked in trunk. The resulting code is binary compatible with > 1.1 except in one minor case that I don't think we need to worry about. But > see the RELEASE-NOTES.txt file for details. > > Unless there are any objections, I'll create an RC in the next few days. > > Cheers, > Simon > > > > > > -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: checkstyle rules
yeah +1 AFAIR, that crazy workaround was done by me. Pointing to svn is really ugly, yes. I did it as a quick fix of something even more ugly. Don't remember exactly what it was. I think something like pointing to a relative path that only existed when checking out the whole current project with the externals... Great if there is a clean maven like way to fix this. Thanks Simon. --Manfred On Sun, Jun 15, 2008 at 5:47 PM, simon <[EMAIL PROTECTED]> wrote: > Hi, > > Currently the myfaces master pom checkstyle configuration points > directly at our subversion repository: > > > org.apache.maven.plugins > maven-checkstyle-plugin > 2.1 > > > > > http://svn.apache.org/repos/asf/myfaces/ > myfaces-master-pom/trunk/checkstyle/ >default/myfaces-checks.xml > > > http://svn.apache.org/repos/asf/myfaces/ > myfaces-master-pom/trunk/checkstyle/ > default/myfaces-header.txt > > > > > The comment is mine, having discovered that the old and completely > obsolete directory > http://svn.apache.org/repos/asf/myfaces/maven/trunk/ > cannot be deleted because older releases of the master pom like this > one: > http://svn.apache.org/repos/asf/myfaces/ > myfaces-master-pom/tags/myfaces-5/pom.xml > point to > http://svn.apache.org/repos/asf/myfaces/maven/trunk/ > build-tools/src/main/resources/config/myfaces-checks.xml > > > I would like to fix this crazy setup by following the "multimodule > setup" as described here: > > http://maven.apache.org/plugins/maven-checkstyle-plugin/examples/multi-module-config.html > > This means creating a new project under myfaces-build-tools that > contains our checkstyle rules, then following a normal release cycle for > it. > > An alternative I tried was to use "svn peg revisions" to try to point to > a file in a specific version of the svn repo but that doesn't seem to > work via the svn web interface, just with the svn commandline tool. And > anyway it still leaves us needing internet connectivity to run > checkstyle. > > Are there any objections? If not, I'll try to implement that later this > week. > > Regards, > Simon > >
Re: [VOTE] promoting the subform component to Tomahawk
+1 On Mon, Jun 9, 2008 at 5:54 PM, Hazem Saleh <[EMAIL PROTECTED]> wrote: > Hi Team, > > I wish to promote this subForm component to the next Tomahawk release. > > [+1] for agreeing with promoting the component to the next Tomahawk release. > [-1] for disagreeing with promoting the component to the next Tomahawk > release. > > > Thanks all very much! > > -- > Hazem Ahmed Saleh Ahmed > http://www.jroller.com/page/HazemBlog -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [tomahawk] Add automatically generated tomahawk.taglib.xml (facelet taglib) to tomahawk using myfaces-builder-plugin
+1 On Wed, Jun 4, 2008 at 9:17 PM, Leonardo Uribe <[EMAIL PROTECTED]> wrote: > Hi > > Is there any objections about do this and solve TOMAHAWK-1146? I don't know > if there is any arguments about do not do this. Trinidad has its own > handler, so I think there is no problem. This mail is only to be sure of > this fact. > > regards > > Leonardo Uribe > -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [VOTE] myfaces-extensions as a new myfaces sub-project
+1 On Mon, Jun 2, 2008 at 8:52 AM, Gerhard Petracek <[EMAIL PROTECTED]> wrote: > hello, > > we discussed whether or not we should start a new myfaces sub-project > (details at: [1] and [2]). > > name: > myfaces-extensions > > description: > place for small innovative projects (which are beyond the current "std. > mechanisms" of jsf) > currently these small projects are: aspect-el, sev-en and scripting > > so - after the positive response let's vote! > (there will be a separated discussion + vote concerning the names.) > > --- > [ ] +1 for: myfaces-extensions should become a myfaces sub-project > [ ] +0 > [ ] -1 for: myfaces-extensions shouldn't become a myfaces sub-project > --- > > regards, > gerhard > > [1] > http://www.nabble.com/-PROPOSAL--myfaces-extensions-to17466179.html#a17466179 > [2] http://www.nabble.com/Re%3A--PROPOSAL--myfaces-extensions-p17474665.html > > -- > > http://www.irian.at > > Your JSF powerhouse - > JSF Consulting, Development and > Courses in English and German > > Professional Support for Apache MyFaces -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
[COMMUNITY] MyFaces += Hazem Saleh
The Myfaces PMC is proud to announce a new addition to our community. Please welcome Hazem Saleh as the newest MyFaces committer! Hazem is an active member of the myfaces community, he contributed some cool components like captcha, password strength and provided many patches. He is also involved in the Apache Myfaces and Facelets book. @Hazem: Please add yourself to the Master-POM at https://svn.apache.org/repos/asf/myfaces/myfaces-master-pom/trunk/pom.xml --Manfred
Re: myfaces groovy support
Cool thing, Werner. Congrats! --Manfred On Tue, May 13, 2008 at 7:45 AM, Werner Punz <[EMAIL PROTECTED]> wrote: > Hello everyone > > I just wanted to give notification that I took a small break from my > components project which is still on track and that I am working on myfaces > groovy support. > > I got the first artefacts already reloading, and a first code will > be made available by the end of the week, early next week. > > (For the Sun guys reading, thanks a lot you gave me the final push to do > it, although I did many things differently than you did) > > Ok what will be done: > First of all I replaced all the factories with my own ones > to enable the entire system, I also had to write my own context listener > to handle the classloader issues. > (We really need a change in the spec here to enable scripting properly - > Ed?) > > > Secondly once the factories were in place I added proxy generation code > wherever needed to enable reloading proxies. > > > Third, a classloader which forks into the groovy system to load the groovy > code. > The groovy code also has its own reloading weaving code added to enable > reloading of groovy files on the groovy side of things (the woven aop > reloading code is lost on the java side however if you just deliver classes > instead of objects, my first approach was a try to enable everything on the > java side) > > So what do we get > Reloading for most artefacts (probably on method level if things work out > the way I intend them to be (For certain artefacts > there are contracts you have to program in on the groovy side to enable > this - aka expose the private properties some artefacts have otherwise > a on method reloading will not be possible). > > Maybe and this is a big maybe, if I can get it up and running (I want to > replace code on the fly) reloading of methods on groovy classes loaded by > groovy over the new classloader. > Again this is a big if, I have not prototyped this fully yet, but it should > be possible. > The idea is, once you load an in groovy object over the classloader > it should be possible to change its methods on the fly via the meta > programming capabilities of groovy. > > Ok first code around friday or early next week. After that I will start > further discussions. > > And again, thanks to Ryan and Ed for finally pushing me towards it > (indirectly by doing it). > > I also have to admit I have had a look at some parts of the code to check > how you guys solved some problems I have been facing - especially the > dreaded classloader issues and weaving issues. > (I did most of the stuff differently though due to the different approach I > am doing, of a mixed groovy/java infrastructure to enable some things not > reachable from the java side that easily, also I did not want to change the > core code, I wanted to have it more as an extension). > > If you want to have a look at the code upfront > before next week, send me a private mail, I just do not want to post > it yet because it still is not done enough for a public post. > Especially the init code I am still very unhappy with. > > > > Werner > > -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [Commons] Library Dependencies
+1 for removing any (transient) dependency to commons-logging And for logging that myfaces-commons-util classes wanna do themselves I strongly suggest SLF4J! --Manfred On Thu, Apr 24, 2008 at 8:16 PM, Scott O'Bryan <[EMAIL PROTECTED]> wrote: > Hey guys, > > At the risk of getting hit with tomatoes and all kinds of rotten fruit, I > would like to ask about some of the dependencies for the MyFaces Commons > projects. IMO the MyFaces commons projects should not carry around an > unnecessary amount of dependencies. "Provided" dependencies are one thing, > but in general I think that dependencies on the JSF and Servlet should be > just about the extent of it for most libraries. > > Currently the myfaces-commons-util's has a runtime dependency on the Apache > Commons Logger. This means that if I'm using the renderkit and the R.I. I > have to also include the logger in my libraries. I would like to remove > this dependency and either use J2EE logging or standard java logging. > Better yet, we might be able to beef up the contract on the utilities to > throw exceptions and let logging be handled by the parent application. > > Does anyone concur? If not, please don't throw any tomatoes at me. :) > > Scott > -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [ANNOUNCE] "AspectEL" code donation
Incubation is definitely not necessary. The bits of code that you can download at http://people.apache.org/~manolito/aspectel-1.0-SNAPSHOT.zip where built from scratch. The Aspect stuff that Gerald mentioned is not this library. He used a slightly different proprietary implementation. But the idea and concept where the same. AspectEL could be seen as a donation by a single MyFaces committer (= me). Don't think that we need an IP clearance in that case. So, should we start a voting then? --Manfred On Fri, Mar 28, 2008 at 3:56 PM, Matthias Wessendorf <[EMAIL PROTECTED]> wrote: > Hi Manfred, > > sounds good. > I strongly doubt, that an incubation of the library is required ;-) > Not sure if we even need the much smaller process of the software > grant / ip clearance. > (Like we did with the portal bridge). > > I saw your presentation and like the main idea behind it, so I'll > give you my +1 for a "myfaces aspect el" subproject. > > -Matthias > > > > > On Fri, Mar 28, 2008 at 2:44 PM, Manfred Geiler <[EMAIL PROTECTED]> wrote: > > Hi all, > > > > As some of you already know (at least those who attended the JSFDays08 > > conference) I wrote a small goody project called "AspectEL" that I > > would like to donate to the MyFaces community. > > > > To give you an idea what it is about, here is the abstract of my > > presentation called "Lightweight AOP with JSF": > > Dealing with entities and domain objects in your JSF views and backing > > beans is sometimes unnecessarily complicated. Aspect oriented > > programming would be a much more elegant way to add GUI specific logic > > directly to your entity classes rather than writing backing bean > > methods for all these GUI tasks. Real highly sophisticated AOP > > solutions might be overkill here and could make things even more > > complicated. This sessions shows you a surprisingly easy way of adding > > certain GUI aspects to your objects while dealing with them from > > within the presentation layer. > > > > Or in the words of a canvasser: > > "AspectEL gives OOP back to your JSF managed beans" > > :-) > > > > You could also have a look at the slides [1] for more details about the > theory. > > > > If you are interested, please have a look at the source code and the > > example application at [2]. > > Just drop the example war into your Tomcat 5.x and manage your > > favorite beer brands. ;-) > > > > Please give me feedback. > > If there is enough interest I will start a discussion/vote thread > > about adding AspectEL as a new MyFaces sub project. > > > > Regards, > > Manfred > > > > [1] > http://conference.irian.at/slidesvideo/pdfs/13_Th_14_Lightweight_AOP_with_JSF.pdf > > [2] http://people.apache.org/~manolito/aspectel-1.0-SNAPSHOT.zip > > > > > > -- > Matthias Wessendorf > > further stuff: > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > mail: matzew-at-apache-dot-org > -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: JspStateManagerImpl into shared?
Mario, you are not alone in hating the shared concept. ;-) This is exactly where the "myfaces-commons-xxx" library comes into play, I often mentioned before. What we need is a module, that 1) has a super stable API 2) is used (ie. shared) by the myfaces core(!) as well as other myfaces projects 3) may be used by the experienced JSF app developer who wants to write his own StateManager or ELResolver or some other pluggable/replaceable JSF thingy (ie. all the things you can replace via faces-config.xml) Problem here again is the name of such a lib: "myfaces-commons-base"? "myfaces-commons-core"? "myfaces-commons-super"? "myfaces-commons-commons"? ;-) The name MUST reflect the fact that this jar is a very basic lib all other JSF stuff depends on. It is no place where we swiftly drop some nice and convenient utils stuff and the API is nothing to play around with. I think that if we find a good name and define some strict rules we could move most (or all?) stuff from myfaces-shared to this lib. And perhaps even get rid of shard in the long run! Of course, some well-known issues pop up immediately: which JSF-Spec - 1.1 and 1.2 or only 1.2? What about JSF 2.0? Thoughts? --Manfred On Tue, Apr 1, 2008 at 9:31 PM, Mario Ivankovits <[EMAIL PROTECTED]> wrote: > Hi! > > Just to reiterate: I hate shared! ;-) > > Seriously, it seems that Orchestra has to implement a StateManager which > holds the view state in the conversationContext instead of the session. > At the moment it seems that large portions of JspStateManagerImpl can be > reused, but requires to copy it over into Orchestra. > > With slight refactoring of JspStateManagerImpl it should be possible to > just replace the actual storing/loading stuff. > > Does this qualify to move JspStateManagerImpl into shared? Or should I > better copy the source over? > > Ciao, > Mario > > -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: MarkMail link adjustment
Jason, Thanks for the info. @dev, I adjusted all markmail links in the myfaces-master-pom accordingly. --Manfred On Tue, Apr 1, 2008 at 8:45 AM, Jason Hunter <[EMAIL PROTECTED]> wrote: > Hi Manfred, > > I wanted to let you know that on MarkMail we've setup "list home pages" > at URLs like /list/. I'm hoping you can adjust the MyFaces > per-list archive links on http://myfaces.apache.org/mail-lists.html to > point at these pages instead of using the multi-subdomains. > > Before: http://users.myfaces.markmail.org/ > > After: http://markmail.org/list/org.apache.myfaces.users > > The list home page URLs are more elegant and (we think) will help us > some with Google that doesn't like sites having thousands of subdomains > that seem to point at the same content. > > The list pages are pretty basic right now. We're going to make these > pages sexy in the future with list metadata and everything, but for now > we want to get people pointing at the right pages and phase out the > multiple subdomain hack. > > Hopefully this is an easy fix for you. We see lots of referrals from > the MyFaces links! > > (Please let me know if you're not the right person to contact about this.) > > -jh- >
Fwd: tomahawk tree2 suggestion
Hi Andor,
I'm cc-ing your mail to the myfaces dev list (the place where such
issues are discussed) and kindly ask you to subscribe to that list.
See http://myfaces.apache.org/mail-lists.html for infos.
Regards,
Manfred
-- Forwarded message --
From: Andor Greißl <[EMAIL PROTECTED]>
Date: Sat, Mar 29, 2008 at 8:18 PM
Subject: tomahawk tree2 suggestion
To: [EMAIL PROTECTED]
Hello Mr Geiler,
since I don't know whom I should contact about a suggestion for the
tree2 component, you became the first person I'll write.
After looking at the generated html of the tree2 component I wondered
why it wasn't using css, this would be a nice feature
since my first - try tree component took about 10 kbytes to transfer
it it had just two nodes and about 4 children.
Experimenting just a little with css (I'm not the css guru, I would
say I know what its good for...) -
thre resulting html code was about six times smaller
Here is what I did
1) take a look at the generated code for ONLY ONE child in the first node
as you can see the image links are very long and even duplicated
KontoauszŸge
2) play around with css to get the same results
#myfaces-tree2 table {border: 0;}
#myfaces_tree2 td.lt {width: 19px; height: 100%; background-image:
url(".../12068063/tree2.HtmlTreeRenderer/images/line-trunk.gif")}
#myfaces_tree2 td.ll {width: 19px; height: 100%; background-image:
url(".../12068063/tree2.HtmlTreeRenderer/images/line-last.gif")}
#myfaces_tree2 td.lm {width: 19px; height: 100%; background-image:
url(".../12068063/tree2.HtmlTreeRenderer/images/line-middle.gif")}
#myfaces_tree2 td.sp {width: 19px; height: 100%; background-image:
url(".../12068063/tree2.HtmlTreeRenderer/images/spacer.gif")}
#myfaces_tree2 td.nmlm {width: 19px; height: 100%; background-image:
url(".../12068063/tree2.HtmlTreeRenderer/images/nav-minus-line-middle.gif")}
#myfaces_tree2 td.nmlp {width: 19px; height: 100%; background-image:
url(".../12068063/tree2.HtmlTreeRenderer/images/nav-plus-line-middle.gif")}
#myfaces_tree2 a.document {height: 100%; padding-left: 18px;
background: url(../img/document.png) no-repeat left top;}
#myfaces_tree2 td.nodefolder {height: 100%; padding-left: 18px;
background: url(../img/yellow-folder-open.png) no-repeat left top;}
Now the code of the tree with ALL THE NODES (javascript calls and ids
removed...)
Admin
Users
Customers
User
J010002
J030047
F030112
I think this could be a nice enhancement to the tree2, I even made a
version that uses no tables just ol/li/span elements. The code above
was generatd within a jsf backing bean.
Ok, maybe you like to read on - Ive created nice components that have
an annotation based functionality. Maybe this could fit into the
myfaces implementation
(it's about auto generating tables and forms from annotated beans).
I'm looking forward to hearing from you soon,
Best regards
Andor Greissl
[ANNOUNCE] "AspectEL" code donation
Hi all, As some of you already know (at least those who attended the JSFDays08 conference) I wrote a small goody project called "AspectEL" that I would like to donate to the MyFaces community. To give you an idea what it is about, here is the abstract of my presentation called "Lightweight AOP with JSF": Dealing with entities and domain objects in your JSF views and backing beans is sometimes unnecessarily complicated. Aspect oriented programming would be a much more elegant way to add GUI specific logic directly to your entity classes rather than writing backing bean methods for all these GUI tasks. Real highly sophisticated AOP solutions might be overkill here and could make things even more complicated. This sessions shows you a surprisingly easy way of adding certain GUI aspects to your objects while dealing with them from within the presentation layer. Or in the words of a canvasser: "AspectEL gives OOP back to your JSF managed beans" :-) You could also have a look at the slides [1] for more details about the theory. If you are interested, please have a look at the source code and the example application at [2]. Just drop the example war into your Tomcat 5.x and manage your favorite beer brands. ;-) Please give me feedback. If there is enough interest I will start a discussion/vote thread about adding AspectEL as a new MyFaces sub project. Regards, Manfred [1] http://conference.irian.at/slidesvideo/pdfs/13_Th_14_Lightweight_AOP_with_JSF.pdf [2] http://people.apache.org/~manolito/aspectel-1.0-SNAPSHOT.zip
Re: [orchestra] plans
yes, +1 on moving dynaform to sandbox. the annotation stuff seems stable and there are many people out there who would like it to see this dings in the official maven repo. --Manfred On Wed, Mar 5, 2008 at 8:59 AM, Mario Ivankovits <[EMAIL PROTECTED]> wrote: > Hi! > > >> > 2) release of orchestra-core15-1.0 > >> > >> We're working on it, but there's quite a lot of effort still needed. It > >> all works (and is being used in production) but needs a lot of polishing > >> before a stable API can be declared. Probably a couple of months away.. > >> > > Really months? What do you plan to change/polish? > > > As it is now, probably yes. The dynaForm stuff is really a hughe > code-base needing some thoughts to being sure having a stable api. > > What we can think of moving the dynaForm stuff into the Orchestra > sandbox. Then core15 should be a no-brainer for a release. > This might make sense as thoughts are to merge the dynaForm stuff with > another project. I'll kick off a discussion about it soon. > > Ciao, > Mario > > -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: The MyFaces Sandbox CAPTCHA component is released :)
cool component - thanks! --Manfred On Fri, Feb 29, 2008 at 6:15 PM, Hazem Saleh <[EMAIL PROTECTED]> wrote: > Hi Guys, > > Iam pleased to tell you that I finally finished developing the CAPTCHA > component. > > We can now have a CAPTCHA by just writing: > > This would generates a captcha with a random text image then set the > generated text > in the session attribute "mySessionKey". > > I hope that you all like the new Apache MyFaces sandbox CAPTCHA component > :). > Here is the patch link: > https://issues.apache.org/jira/browse/TOMAHAWK-1207 > > Later, I will include the component documentation patch. > BTW, I would like to thank Zubin wadia, Martin Marinschek, Thomas speigl for > encouraging > me developing this component. > > I really like all the Apache MyFaces community. > Thanks to all of you. > -- > Hazem Ahmed Saleh Ahmed > http://www.jroller.com/HazemBlog -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [continuum] AAARGH! (was: svn commit: r628196 - /myfaces/myfaces-master-pom/trunk/pom.xml)
On Mon, Feb 25, 2008 at 7:43 PM, Scott O'Bryan <[EMAIL PROTECTED]> wrote: > Sigh... I'm sorry about that Manfred. I should have been more > careful. It was a simple change, but apparently it was a simple change > with a typo... Yeah, no problem. As I said before, my anger was at Continuum not at you. But as we have learned: always look at the bright side. Now, I actually learned how to start/stop/install/upgrade continuum. Hooray! :-) --Manfred > > Anyway, thanks for the information and the upgrade... ;-) > > Scott > > > > Manfred Geiler wrote: > > Scott, your faulty master pom commit ( instead of > > ) cost me half a day. > > > > How come? > > - Continuum did no longer build the master pom correctly > >--> your fault > > - The continuum messages (see [1]) where totally misleading > >--> NOT your fault of course ;-) > > - Since I could not determine the cause (clearing working dir or > > restarting continuum did not work) I decided to upgrade to continuum > > 1.1 final - due anyway > >--> MY fault! > > - I was able to install the new version but migrating the data from > > 1.1-beta2 to 1.1 was a total flop - although I tried hard, believe me! > > (see http://wiki.apache.org/myfaces/Continuum_Build for details) > > - So I stepped back to continuum 1.1-beta2 > > - I removed the build definition for the myfaces master > > - I was not able to create a new build definition > > - Now the continuum exceptions luckily lead me to the actual cause > > > > @Scott > > Please note: > > I'm NOT posting this publicly to dev@ to blame you. > > Yes, I'm angry. But not because of your mistake (could happen) but > > because of Continuum. > > And I want to prevent others form stepping into the same traps. ;-) > > > > @All > > What should we do regarding Continuum builds? > > Anyone volunteering to migrate all build definitions and users manually? > > > > --Manfred > > > > > > [1] > > > > > Build Error: > > > > > org.codehaus.plexus.taskqueue.execution.TaskExecutionException: Error > > executing action 'update-project-from-working-directory' > >at > org.apache.maven.continuum.buildcontroller.DefaultBuildController.performAction(DefaultBuildController.java:432) > >at > org.apache.maven.continuum.buildcontroller.DefaultBuildController.build(DefaultBuildController.java:137) > >at > org.apache.maven.continuum.buildcontroller.BuildProjectTaskExecutor.executeTask(BuildProjectTaskExecutor.java:50) > >at > org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable$1.run(ThreadedTaskQueueExecutor.java:116) > >at > edu.emory.mathcs.backport.java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:442) > >at > edu.emory.mathcs.backport.java.util.concurrent.FutureTask.run(FutureTask.java:176) > >at > edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665) > >at > edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690) > >at java.lang.Thread.run(Thread.java:595) > > Caused by: > org.apache.maven.continuum.execution.ContinuumBuildExecutorException: > > Error while mapping metadata:add.project.project.building.error > > add.project.unknown.error > > > >at > org.apache.maven.continuum.execution.maven.m2.MavenTwoBuildExecutor.updateProjectFromCheckOut(MavenTwoBuildExecutor.java:159) > >at > org.apache.maven.continuum.core.action.UpdateProjectFromWorkingDirectoryContinuumAction.execute(UpdateProjectFromWorkingDirectoryContinuumAction.java:75) > >at > org.apache.maven.continuum.buildcontroller.DefaultBuildController.performAction(DefaultBuildController.java:406) > >... 8 more > > > > > > > > [2] > > -- Forwarded message -- > > From: <[EMAIL PROTECTED]> > > Date: Fri, Feb 15, 2008 at 11:58 PM > > Subject: svn commit: r628196 - /myfaces/myfaces-master-pom/trunk/pom.xml > > To: [EMAIL PROTECTED] > > > > > > Author: sobryan > > Date: Fri Feb 15 14:58:57 2008 > > New Revision: 628196 > > > > URL: http://svn.apache.org/viewvc?rev=628196&view=rev > > Log: >
[continuum] AAARGH! (was: svn commit: r628196 - /myfaces/myfaces-master-pom/trunk/pom.xml)
Scott, your faulty master pom commit ( instead of ) cost me half a day. How come? - Continuum did no longer build the master pom correctly --> your fault - The continuum messages (see [1]) where totally misleading --> NOT your fault of course ;-) - Since I could not determine the cause (clearing working dir or restarting continuum did not work) I decided to upgrade to continuum 1.1 final - due anyway --> MY fault! - I was able to install the new version but migrating the data from 1.1-beta2 to 1.1 was a total flop - although I tried hard, believe me! (see http://wiki.apache.org/myfaces/Continuum_Build for details) - So I stepped back to continuum 1.1-beta2 - I removed the build definition for the myfaces master - I was not able to create a new build definition - Now the continuum exceptions luckily lead me to the actual cause @Scott Please note: I'm NOT posting this publicly to dev@ to blame you. Yes, I'm angry. But not because of your mistake (could happen) but because of Continuum. And I want to prevent others form stepping into the same traps. ;-) @All What should we do regarding Continuum builds? Anyone volunteering to migrate all build definitions and users manually? --Manfred [1] Build Error: org.codehaus.plexus.taskqueue.execution.TaskExecutionException: Error executing action 'update-project-from-working-directory' at org.apache.maven.continuum.buildcontroller.DefaultBuildController.performAction(DefaultBuildController.java:432) at org.apache.maven.continuum.buildcontroller.DefaultBuildController.build(DefaultBuildController.java:137) at org.apache.maven.continuum.buildcontroller.BuildProjectTaskExecutor.executeTask(BuildProjectTaskExecutor.java:50) at org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable$1.run(ThreadedTaskQueueExecutor.java:116) at edu.emory.mathcs.backport.java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:442) at edu.emory.mathcs.backport.java.util.concurrent.FutureTask.run(FutureTask.java:176) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690) at java.lang.Thread.run(Thread.java:595) Caused by: org.apache.maven.continuum.execution.ContinuumBuildExecutorException: Error while mapping metadata:add.project.project.building.error add.project.unknown.error at org.apache.maven.continuum.execution.maven.m2.MavenTwoBuildExecutor.updateProjectFromCheckOut(MavenTwoBuildExecutor.java:159) at org.apache.maven.continuum.core.action.UpdateProjectFromWorkingDirectoryContinuumAction.execute(UpdateProjectFromWorkingDirectoryContinuumAction.java:75) at org.apache.maven.continuum.buildcontroller.DefaultBuildController.performAction(DefaultBuildController.java:406) ... 8 more [2] -- Forwarded message -- From: <[EMAIL PROTECTED]> Date: Fri, Feb 15, 2008 at 11:58 PM Subject: svn commit: r628196 - /myfaces/myfaces-master-pom/trunk/pom.xml To: [EMAIL PROTECTED] Author: sobryan Date: Fri Feb 15 14:58:57 2008 New Revision: 628196 URL: http://svn.apache.org/viewvc?rev=628196&view=rev Log: Added myself as a developer to MyFaces... Modified: myfaces/myfaces-master-pom/trunk/pom.xml Modified: myfaces/myfaces-master-pom/trunk/pom.xml URL: http://svn.apache.org/viewvc/myfaces/myfaces-master-pom/trunk/pom.xml?rev=628196&r1=628195&r2=628196&view=diff == --- myfaces/myfaces-master-pom/trunk/pom.xml (original) +++ myfaces/myfaces-master-pom/trunk/pom.xml Fri Feb 15 14:58:57 2008 @@ -205,6 +205,19 @@ +1 +sobryan +Scott O'Bryan +[EMAIL PROTECTED] +Oracle, U.S.A +http://www.oracle.com + +Portlet Bridge Project Lead +JSR-301 JSF Portlet Bridge EG Member +Portlet Guru + +-7 + + schof Sean Schofield [EMAIL PROTECTED]
[continuum] upgrading
??? Is somebody logged in as mrmaven and killing my processes? --Manfred -- Forwarded message -- From: Manfred Geiler <[EMAIL PROTECTED]> Date: Mon, Feb 25, 2008 at 1:54 PM Subject: [continuum] upgrading To: MyFaces Development FYI MyFaces Continuum is currently down for maintainance. Trying to upgrade to 1.1 final --Manfred -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
[continuum] upgrading
FYI MyFaces Continuum is currently down for maintainance. Trying to upgrade to 1.1 final --Manfred
Re: MyFaces API and IMPL docs 404.
Deleting it seems not so easy. There is still some update cron job running with user "schof". Right? This are the properties of the file in /www/myfaces.apache.org 85847169 8 -rw-rw-r-- 1 schof myfaces 7397 Feb 17 21:34 javadoc.html So it seems that it gets updated/copied on a regular basis. Where is this script and from where does it update/copy the files? Thanks, Manfred On Feb 20, 2008 12:12 PM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Hi Manfred, > > No, that page > > http://myfaces.apache.org/javadoc.html > > is just a leftover. It should not exist, and can be deleted. The maven > website deploy stuff doesn't delete old obsolete stuff when a new site > is deployed. I guess google indexed it when it was once valid, and now > people are finding it :-( > > The thread that Matthias refers to is about something a bit different. > There should be no javadoc.html page at the top level of the site, as > this just does not make sense with the large number of myfaces projects > that now exist. But there should be (and are) javadoc index pages under > core11 and core12 directories - and possibly tomahawk directory (TODO). > > Regards, > Simon > > Matthias Wessendorf schrieb: > > > Hi > > > > On Feb 20, 2008 10:39 AM, Manfred Geiler <[EMAIL PROTECTED]> wrote: > > > >> Simon, is http://myfaces.apache.org/javadoc.html an official page? > >> Google search says that there is no external link to that page. > >> > > > > it was... and we talked about that already in this thread ([1]). > > This page was also linked to tagdocs. > > > > -Matthias > > > > [1] http://www.mail-archive.com/dev@myfaces.apache.org/msg29331.html > > > > > >> Should we get rid of it or is there a quick way to fix this? > >> > >> Thanks, > >> Manfred > >> > >> > >> > >> -- Forwarded message -- > >> From: <[EMAIL PROTECTED]> > >> Date: Feb 20, 2008 7:25 AM > >> Subject: MyFaces API and IMPL docs 404. > >> To: [EMAIL PROTECTED] > >> > >> > >> > >> > >> > >> > >> Hi, > >> > >> > >> > >> Wasn't sure whom to inform. > >> > >> > >> > >> http://myfaces.apache.org/javadoc.html > >> > >> > >> > >> getting 404s for the API and IMPL docs. > >> > >> > >> > >> Thanks > >> > >> Rohit. > >> > > > > > > -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [VOTE] Move Portlet-Bridge trunk
+1 --Manfred On Feb 19, 2008 11:49 PM, Scott O'Bryan <[EMAIL PROTECTED]> wrote: > Over the next few days I'm going to be moving in my changes to support > multiple bridges. As a fist step, I need to move the current trunk at > https://svn.apache.org/repos/asf/myfaces/portlet-bridge/trunk to > https://svn.apache.org/repos/asf/myfaces/portlet-bridge/core/trunk [1]. > This will allow me to add a folder for a master pom and the main page of > the website. > > This will require developers currently working on the trunk to "switch" > their working copies to use the new location and we will also loose some > history. > > Given these effects, please vote: > > +1 Yes, moving it is okay > 0 Don't care > -1 No, do not move it.. Provide reasons and alternatives. > > Thanks, > Scott > > > [1] https://issues.apache.org/jira/browse/PORTLETBRIDGE-26 > -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Fwd: MyFaces API and IMPL docs 404.
Simon, is http://myfaces.apache.org/javadoc.html an official page? Google search says that there is no external link to that page. Should we get rid of it or is there a quick way to fix this? Thanks, Manfred -- Forwarded message -- From: <[EMAIL PROTECTED]> Date: Feb 20, 2008 7:25 AM Subject: MyFaces API and IMPL docs 404. To: [EMAIL PROTECTED] Hi, Wasn't sure whom to inform. http://myfaces.apache.org/javadoc.html getting 404s for the API and IMPL docs. Thanks Rohit. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: Can I be added to Admin role on portlet-bridge jira
The portlet bridge project role assigments where a total mess. I fixed them and also added you to the "myfaces-administrators" group. Scott, please try again. --Manfred On Feb 18, 2008 9:22 PM, Scott O'Bryan <[EMAIL PROTECTED]> wrote: > Hey guys, > > For some reason I do not have administrative rights to the > Portlet-Bridge role on Jira. Can someone add me to that role please? > I'm trying to create the release notes for the alpha release we just did > and I can't seem to. :) > > Thanks, > Scott >
Re: [Jira] Question about "Fix Version" field
Yes, and this is only possible by taking away the "Resolve Issues" permission for reporters (="issue-filers") which would also forbid the reporter to reopen an issue. Question is: do we want this. My feeling is: no, because: In a "perfect world" :-) the reporter downloads the "fix version" release as soon as it is out and tests his issue with this new release. In case the fix did not really fix the issue in question, the reporter changes the jira issue to "reopened" and sets the fix version field to "unknown". This is the idea behind this permission, I think. --Manfred On Feb 6, 2008 12:31 PM, Matthias Wessendorf <[EMAIL PROTECTED]> wrote: > > On Feb 6, 2008 12:29 PM, Antonio Petrelli <[EMAIL PROTECTED]> wrote: > > 2008/2/6, Matthias Wessendorf <[EMAIL PROTECTED]>: > > > but the "Fix version/s" should > > > be only for the committer, when closing. > > > > > > Not only when closing. It can be used to schedule tickets. At Struts and > > Tiles we use this technique very frequently: at least it is useful to > > schedule on a branch or on the trunk. > > yeah, I was unclear. > let's say it this way: > -an issue-filer (a non-committer) should not be able to edit this field. > > -M > > > > > Antonio > > > > > > > > -- > > Matthias Wessendorf > > further stuff: > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > mail: matzew-at-apache-dot-org > -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [Jira] Question about "Fix Version" field
Matze, This is a (hardcoded?) Jira feature. There is one special issue permission in Jira that controls who is allowed to assign a fix version: "Resolve Issues (Ability to resolve and reopen issues. This includes the ability to set a fix version.)" Since it is necessary for the reporter to be able to reopen issues, this permission is assigned to the reporter role in the Standard Permission Scheme that MyFaces uses. --Manfred On Feb 6, 2008 10:49 AM, Matthias Wessendorf <[EMAIL PROTECTED]> wrote: > our jira instance has these fields (and more...): > > Fix Version/s: > Affects Version/s: > > Both are editable by the bug filer. > The "Affects Version/s:" makes sense, since they need to identify the > broken version. > > Now, I have problems in understanding the "Fix Version/s" field. > > I understand it this way: > -a committer fixed the problem and marks the fixed version is this field. > If this is correct, why should we leave it editable by the filer ? > > Or is it more a "I wish to have a fix for version blah" ? > If so, not sure if that really works well in OS culture. > > Would be great if someone could help me :-) > > -Matthias > > > -- > Matthias Wessendorf > > further stuff: > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > mail: matzew-at-apache-dot-org > -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [orchestra] rename scope "flash" to "access"
"access" says exactly what it does. keeps the conversation active as long as it is accessed - ie. as long as any bean in this conversation is used during the next request. --Manfred On Jan 29, 2008 9:32 PM, Kito D. Mann <[EMAIL PROTECTED]> wrote: > Hmmm... I agree that "flash" can be misleading, but "access" doesn't seem > very descriptive to me. I think "page" or "view" might be more appropriate. > > ~~~ > Kito D. Mann - Author, JavaServer Faces in Action > http://www.virtua.com - JSF/Java EE consulting, training, and mentoring > http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info > > > > > > -Original Message- > > From: Simon Kitching [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, January 29, 2008 3:00 AM > > To: dev@myfaces.apache.org > > Subject: [orchestra] rename scope "flash" to "access" > > > > Hi All, > > > > Currently in orchestra there are two types of conversation scope: > > "manual" and "flash". With "manual", a conversation must be explicitly > > ended via either a call to the Orchestra API, or use of a jsf tag. With > > "flash", the conversation is automatically ended when a request cycle > > ends and no object in the conversation was accessed. > > > > Some people have noted that other libraries use the term "flash scope" > > for a somewhat different purpose. I therefore propose changing the name > > to "access scope". > > > > This change will mean renaming about 6 classes, updating the examples > > and updating the website documentation. > > > > I intend to keep backwards compatibility with 1.0 to the level where > > normal Spring configuration files still work unaltered (and will test > > this by making sure the existing orchestra examples work unaltered, > > before I update them to show the "new" config). > > > > However for classes which would only be used by people deriving their > > own custom scope-managers, etc., I don't currently plan to keep full > > binary compatibility. > > > > Are there any objections? > > > > Regards, > > Simon > > -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [orchestra] rename scope "flash" to "access"
yes, good idea +1 I like the name "access scope" and also experienced people who use the term "flash scope" for usage. --Manfred On Jan 29, 2008 8:59 AM, Simon Kitching <[EMAIL PROTECTED]> wrote: > Hi All, > > Currently in orchestra there are two types of conversation scope: "manual" > and "flash". With "manual", a conversation must be explicitly ended via > either a call to the Orchestra API, or use of a jsf tag. With "flash", the > conversation is automatically ended when a request cycle ends and no object > in the conversation was accessed. > > Some people have noted that other libraries use the term "flash scope" for a > somewhat different purpose. I therefore propose changing the name to "access > scope". > > This change will mean renaming about 6 classes, updating the examples and > updating the website documentation. > > I intend to keep backwards compatibility with 1.0 to the level where normal > Spring configuration files still work unaltered (and will test this by making > sure the existing orchestra examples work unaltered, before I update them to > show the "new" config). > > However for classes which would only be used by people deriving their own > custom scope-managers, etc., I don't currently plan to keep full binary > compatibility. > > Are there any objections? > > Regards, > Simon > -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
[COMMUNITY] MyFaces += Bernhard Huemer
The Myfaces PMC is proud to announce a new addition to our community. Please welcome Bernhard Huemer as the newest MyFaces committer. Bernhard Huemer has been providing several patches (including a very tricky EL-bug) and has also been very active on the mailing-list. @Bernhard: Please add yourself to the Master-POM at https://svn.apache.org/repos/asf/myfaces/myfaces-master-pom/trunk/pom.xml --Manfred
Re: [MyFaces 1.2.1] question on trunk and tag
Yes, I agree with Matthias and partly take back what I said in my former mail. Normal release process is something like this: 1. copy current trunk to a branch(!) 2. make changes that are necesssary for the release but should not be on the trunk on this branch (particularly changing snapshot dependencies to non snapshot dependencies) 3. do the release:prepare thing on the branch 4. this automatically creates the release tag 5. now is the proper time to merge back the version increment(s) to the trunk Question is, how the "1_2_1_RC" tag was actually created. The name does not look like a maven release plugin auto created tag. --Manfred On Jan 20, 2008 11:41 PM, Matthias Wessendorf <[EMAIL PROTECTED]> wrote: > Hi, > > I don't know why it is a TAG. > TAG means (to me) something "more" serious/final. > and... that all 1.2.1 related fixes go into that as well. > New "features" not. > > That's why I asked, why is trunk still 1.2.1 (and not 1.22) > > -M > > > On Jan 20, 2008 1:29 PM, Manfred Geiler <[EMAIL PROTECTED]> wrote: > > On Jan 20, 2008 6:50 PM, Matthias Wessendorf <[EMAIL PROTECTED]> wrote: > > > Hi, > > > > > > 2) > > > The trunk says 1.2.1-SNAPSHOT. > > > In case we use the above mentioned TAG, shouldn't it say 1.2.2-SNAPSHOT > > > already? > > > > No, I think 1.2.1-SNAPSHOT on trunk is ok as long as there is no release. > > > > The "1_2_1_RC" (normally) is a working copy branch(!) that is used to > > prepare the release without disturbing concurrent development. > > BTW, why is "1_2_1_RC" a tag? It should be a branch of course. > > > > Leaving the version on trunk unchanged gives the release manager the > > chance to throw away this working copy branch and start over with a > > new copy from the trunk. > > > > "textbook example": > > As soon as the release is out, all important fixes and changes on this > > branch (including the pom updates to "1.2.2-SNAPSHOT") will be merged > > back to the trunk. > > > > --Manfred > > > > > > > -- > Matthias Wessendorf > > further stuff: > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > mail: matzew-at-apache-dot-org > -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [MyFaces 1.2.1] question on trunk and tag
On Jan 20, 2008 6:50 PM, Matthias Wessendorf <[EMAIL PROTECTED]> wrote: > Hi, > > 2) > The trunk says 1.2.1-SNAPSHOT. > In case we use the above mentioned TAG, shouldn't it say 1.2.2-SNAPSHOT > already? No, I think 1.2.1-SNAPSHOT on trunk is ok as long as there is no release. The "1_2_1_RC" (normally) is a working copy branch(!) that is used to prepare the release without disturbing concurrent development. BTW, why is "1_2_1_RC" a tag? It should be a branch of course. Leaving the version on trunk unchanged gives the release manager the chance to throw away this working copy branch and start over with a new copy from the trunk. "textbook example": As soon as the release is out, all important fixes and changes on this branch (including the pom updates to "1.2.2-SNAPSHOT") will be merged back to the trunk. --Manfred
Myfaces commons utils
Just had a look at the new commons-utils module and found the class "TagUtils". Please forgive me for saying it directly: This piece of code is horrible! It seems to be a mixture of various static methods without any direct relation to "Tags". Looks like a huge graveyard for quick and dirty static code pieces. Having in mind a stable API (this is what we intended with these commons jars - right?) I must say we SHOULD get rid of this code and/or refactor it to several separate utils classes. Each one of them having a clear and certain scope. WDYT? --Manfred
Re: [VOTE] MyFaces Master pom v5
here is my own +1 We got 4 positive votes. I hereby formally close this poll. --Manfred On Jan 18, 2008 2:51 PM, Bruno Aranda <[EMAIL PROTECTED]> wrote: > +1 > > > On 18/01/2008, Martin Marinschek <[EMAIL PROTECTED]> wrote: > > +1, > > > > regards, > > > > Martin > > > > On 1/18/08, Simon Kitching <[EMAIL PROTECTED]> wrote: > > > Manfred Geiler <[EMAIL PROTECTED]> schrieb: > > > > This is the formal vote for the new myfaces master POM version 5. > > > > > > > > You can find the signed release candidate at [1]. > > > > > > > > Please vote > > > > +1 if you reviewed the new master pom version and think we can use it > > > > -1 if you found a flaw or potential problem with the new master pom > > > > > > +1 (non-binding). > > > > > > > > > -- > > > > http://www.irian.at > > > > Your JSF powerhouse - > > JSF Consulting, Development and > > Courses in English and German > > > > Professional Support for Apache MyFaces > > > -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: MyFaces Build Tools
ok, I will start the myfaces-master-pom release process right now --Manfred On Jan 18, 2008 12:59 PM, Simon Kitching <[EMAIL PROTECTED]> wrote: > Matthias Wessendorf <[EMAIL PROTECTED]> schrieb: > > Hi, > > > > I ported some "Trinidad fixes" over to the build-tools. > > > > I also think it might be the case where we want to release the bits, > > to get them into usage. > > > > I think they are stable (since just created out to Trinidad), so we > > might want go with a 1.0.0 instead > > of something like 1.0.0-alpha > > > > What do you think? > > Sounds good to me. I'd love to see these released, and 1.0.0 sounds > reasonable as the code is already known to work. > > However at the moment, myfaces-plugin-parent depends on the > myfaces-master-pom version 4. IMO it would be nice to get > myfaces-master-pom:5 released first, then used by the build plugins. > > The trunk version of myfaces-master has: > (1) a new developer (gerhard) > (2) updated plugin versions > (3) versions defined for a bunch of plugins that had no version defined > previously (ie not reproducable builds) > > Sorry, but I cannot offer to help with releasing the master, as I am rather > overloaded at the moment... > > Regards, > Simon > -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
[VOTE] MyFaces Master pom v5
This is the formal vote for the new myfaces master POM version 5. You can find the signed release candidate at [1]. Please vote +1 if you reviewed the new master pom version and think we can use it -1 if you found a flaw or potential problem with the new master pom Thanks, --Manfred [1] http://people.apache.org/builds/myfaces/m2-staging-repository/org/apache/myfaces/myfaces/5/
[COMMUNITY] MyFaces += Gerhard Petracek
The Myfaces PMC is proud to announce a new addition to our community. Please welcome Gerhard Petracek as the newest MyFaces committer. Gerhard has been very active on the mailing lists and has provided several patches for the Trinidad components. He also cares about up-to-date wiki pages. @Gerhard: Please add yourself to the Master-POM at https://svn.apache.org/repos/asf/myfaces/myfaces-master-pom/trunk/pom.xml --Manfred
Re: UIInput.resetValue()
On Jan 15, 2008 4:16 PM, Matthias Wessendorf <[EMAIL PROTECTED]> wrote: > We here can only talk... The spec itself is made behind closed doors ;-) Not really "closed" "ajar" would be a better word: at least everyone is allowed to comment on early drafts ;-) --Manfred
Re: UIInput.resetValue()
Why not use the last "if" alone?
if (component instanceof EditableValueHolder)
{
EditableValueHolder holder = (EditableValueHolder)component;
holder.setValue(null);
holder.setSubmittedValue(null);
holder.setLocalValueSet(false);
holder.setValid(true);
}
Every UIInput is an EditableValueHolder and the UIXEditable as well, right?
This code fragement could also be candidate for a
"EditableValueHolderUtils" class in the MyFaces Commons.
--Manfred
On Jan 15, 2008 3:47 PM, Simon Lessard <[EMAIL PROTECTED]> wrote:
> Although I'm -1 also because of backward compatibility, I also felt that it
> should have been added to the interface to start with as it simplifies many
> loops used for reseting EditableValueHolder of the whole tree. You cannot
> use instanceof UIInput for those as Trinidad input components, for example,
> does not extends UIInput, but do implement EditableValueHolder so the loop's
> body has to look like:
>
> if (component instanceof UIXEditable)
> {
> ((UIXEditable)component).resetValue();
> }
> else if (component instanceof UIInput)
> {
> ((UIInput)component).resetValue();
> }
> else if (component instanceof EditableValueHolder)
> {
> EditableValueHolder holder = (EditableValueHolder)component;
> holder.setValue(null);
> holder.setSubmittedValue(null);
>holder.setLocalValueSet(false);
> holder.setValid(true);
> }
>
>
> Maybe a good compromise would be to alter UIViewRoot to add a
> resetAllEditableValueHolderValues method.
>
>
> Regards,
>
> ~ Simon
>
>
>
> On Jan 15, 2008 3:19 AM, Manfred Geiler <[EMAIL PROTECTED]> wrote:
> > -1
> > Sorry, I cannot agree.
> >
> > The API doc of resetValue() tells you why:
> > "Convenience method to reset [..]"
> >
> > A "utility like" method for convenience like this one does not belong
> > to an interface. It does not add any behavioural function.
> > UIInput is not an interface but a (base) class, so it is ok to have
> > such a method there.
> >
> > Matze, do you have any concrete use case that could confirm your POV?
> >
> > --Manfred
> >
> >
> >
> >
> >
> > On Jan 15, 2008 7:22 AM, Matthias Wessendorf <[EMAIL PROTECTED]> wrote:
> > > Hi,
> > >
> > > the resetValue() method was added directly to UIinput, instead to a
> > > proper interface (EditableValueHolder).
> > > I guess this was done, to not break impls of that interface.
> > > IMO this is wrong and should (at least in JSF2) be part of the
> > > EditableValueHolder interface.
> > >
> > > Since JSF2 will bring much more new bits, such an "enhancement" on the
> > > interface might be valueable.
> > >
> > > What is your take on that ?
> > >
> > > -Matthias
> > >
> > > --
> > > Matthias Wessendorf
> > >
> > > further stuff:
> > > blog: http://matthiaswessendorf.wordpress.com/
> > > sessions: http://www.slideshare.net/mwessendorf
> > > mail: matzew-at-apache-dot-org
> > >
> >
[jira] Created: (MYFACES-1803) elements should be rendered for better WAI support
elements should be rendered for better WAI support - Key: MYFACES-1803 URL: https://issues.apache.org/jira/browse/MYFACES-1803 Project: MyFaces Core Issue Type: Improvement Components: General Affects Versions: 1.2.0, 1.1.5 Reporter: Manfred Geiler Assignee: Manfred Geiler Priority: Minor According to the "Web Accessibility Initiative (WAI)" guidelines (http://www.w3.org/WAI/) for every
Re: UIInput.resetValue()
-1 Sorry, I cannot agree. The API doc of resetValue() tells you why: "Convenience method to reset [..]" A "utility like" method for convenience like this one does not belong to an interface. It does not add any behavioural function. UIInput is not an interface but a (base) class, so it is ok to have such a method there. Matze, do you have any concrete use case that could confirm your POV? --Manfred On Jan 15, 2008 7:22 AM, Matthias Wessendorf <[EMAIL PROTECTED]> wrote: > Hi, > > the resetValue() method was added directly to UIinput, instead to a > proper interface (EditableValueHolder). > I guess this was done, to not break impls of that interface. > IMO this is wrong and should (at least in JSF2) be part of the > EditableValueHolder interface. > > Since JSF2 will bring much more new bits, such an "enhancement" on the > interface might be valueable. > > What is your take on that ? > > -Matthias > > -- > Matthias Wessendorf > > further stuff: > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > mail: matzew-at-apache-dot-org >
Re: Master pom and pmd plugin
I could live with (3) --Manfred On Jan 14, 2008 11:55 AM, Simon Kitching <[EMAIL PROTECTED]> wrote: > Hi All, > > Currently the master pom (5-SNAPSHOT) defines the pmd plugin in the reporting > section. Unfortunately it appears that while most maven report plugins are > smart enough not to generate any output if they have no input files, pmd does > not do this. As a result, every "project" module (which is just generating a > site) gets pointless CMD and PMD reports (which causes the creation of a > whole "project reports" menu to hold them). > > Solution (1) is to just take this definition out of the master pom, and have > modules that want pmd/cmd reports define the plugin. > > Solution (2) is for each "project" module to disable these reports by > defining an empty reportSet. Note that the child modules need to then > re-enable the reportSet which means repeating all of the config for that > plugin anyway. However when/if the pmd plugin is fixed it is slightly easier > to then go back to defining it just in the parent. > > Solution (3) is to live with these pointless "project reports" menus > containing pointless cmd/pmd report pages until/if the plugin is fixed. > > I'm in favour of (1) myself, although (2) is also possible (I have just done > this for core12 module a few minutes ago). > > What would you prefer? > > Regards, > Simon >
