ok, sent a request to add you to [EMAIL PROTECTED]
--Manfred
On 12/17/07, simon [EMAIL PROTECTED] wrote:
Hi,
I'd like to publish an updated website. However I am not currently a
member of the myfaces unix group on people.apache.org, aka minotaur.
If it is ok with the PMC, could you please
yes, myfaces-build-tools is a much better name
--Manfred
On 12/16/07, Bruno Aranda [EMAIL PROTECTED] wrote:
+1 About the naming, though, this seems to be more myfaces-build-tools
than myfaces-dev-tools, because as far as I understand, this artifacts
are used during the build, not for just
Leonardo,
Sorry for answering so late. I had to go through a two weeks backlog
in my inbox. And two weeks means a huge load when subscribed to
MyFaces lists... ;-)
Anyway, to give you as much help as possible I started a new wiki page
at the Vienna Hackthon:
I personally like the APT format.
However
+1 on both formats (the author chooses)
--Manfred
On 12/15/07, Andrew Robinson [EMAIL PROTECTED] wrote:
+1 on apt
-1 on xdoc
APT is *much* easier to write.
Why do we have to choose one? As long as the author is writing
documentation, we should be
+1
--Manfred
On 12/15/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
Hi,
I think, I'll use http://slf4j.org/ for the logger in commons.
What do you think about that ?
-M
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions:
This is the formal vote for the new myfaces master POM version 4.
You can find the signed release candidate at [1].
Please vote
+1 if you reviewed the new master pom version 4 and think we can use it
-1 if you found a flaw or potential problem with the new master pom
Thanks,
--Manfred
[1]
I also fiddled with the site a few weeks ago... and got stuck. ;-)
Well here is the outcome of my fiddling:
http://people.apache.org/~manolito/myfaces-site/
Notice the collapsible menu items. I made them uncollapsed for this
example, but they should be collapsed on the main page (like on the
.
Regards,
Simon
Manfred Geiler [EMAIL PROTECTED] schrieb:
yes, fine!
please consider the following structure:
myfaces-jsfcommons
| myfaces-jsfcommons-api
| myfaces-jsfcommons-impl
| myfaces-jsfcommons-sandbox
(we must avoid the name myfaces-commons
Oh no! Seems like we are going round in circles... :-(
WHAT is the FOCUS of a jsfcommons project?!
Do we really want component like stuff like converters and validators there?
Didn't we discuss this already?
I thought we agreed on not starting yet another jsf component lib.
What is wrong with
Hmpf
Last time the discussion ended with some open issues.
I think it's all about naming. That's the main reason for different
views and opinions I think.
To gain a common view on things I try to subsume without giving names first.
The stuff we have (or plan to have) and we need places for are:
On 11/29/07, Mario Ivankovits [EMAIL PROTECTED] wrote:
Hi!
that would easy the debugging as well.
why? If you have both sources for api and impl jar in your IDE there
is no difference.
It IS. You have to know at which class to set a breakpoint. Even if you
see a shared class, you
/artifactId
version1.2.0/version
/dependency
What could be the problem ?
Thx
Manfred Geiler wrote:
no, it exactly says what it does:
org.apache.myfaces.RENDER_VIEWSTATE_ID=true is the default and renders
the hidden input id attribute.
Setting it to false solves
yes, fine!
please consider the following structure:
myfaces-jsfcommons
| myfaces-jsfcommons-api
| myfaces-jsfcommons-impl
| myfaces-jsfcommons-sandbox
(we must avoid the name myfaces-commons for there was once a project
with that name - see maven repo!)
api = the classes
Yes, I thought about a config param as well. But I wanted to make it
not too sophisticated and to introduce another piece for config hell.
However, I can live with the config param as long as it defaults to true.
BTW, I like the name STRICT_XHTML_LINKS
What do others think?
--Manfred
On Nov
[
https://issues.apache.org/jira/browse/MYFACES-1774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12544732
]
Manfred Geiler commented on MYFACES-1774:
-
We should introduce a config param as suggested by Mario:
http
The Myfaces PMC is proud to announce a new addition to our community.
Please welcome Leonardo Uribe as the newest MyFaces committer.
Leonardo has provided countless patches to Jira issues, and is very
active on the mailing lists as well.
@Leonardo: Please add yourself to the Master-POM at
URL: https://issues.apache.org/jira/browse/MYFACES-1774
Project: MyFaces Core
Issue Type: Bug
Components: General, JSR-127, JSR-252
Affects Versions: 1.2.0, 1.1.5
Reporter: Manfred Geiler
Assignee: Manfred Geiler
Priority: Minor
Please have a look at
http://issues.apache.org/jira/browse/MYFACES-1774
Do you think there is a problem with generally rendering amp; instead of ?
Issues with old browsers perhaps?
Thanks,
Manfred
+1
--Manfred
On 11/21/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
This is the official vote for the acceptance of Oracle's donation of
translated messages ([1]) for the Apache MyFaces Trinidad component library.
Please note that - since the codebase is small enough and it makes only
Versions: 1.0.0-SNAPSHOT
Reporter: Manfred Geiler
Assignee: Scott O'Bryan
Fix For: 1.0.0-SNAPSHOT
Portlet Bridge should switch to new MyFaces Master POM:
groupId=org.apache.myfaces
artifactId=myfaces
version=3-SNAPSHOT in the meantime (2 has some
with an exotic browser, he/she should
derive his own LinkRenderer and overwrite this behaviour.
--Manfred
On Nov 21, 2007 5:05 PM, Mike Kienenberger [EMAIL PROTECTED] wrote:
For html, I think we should continue to render .
For xhtml, we should render amp;
On Nov 21, 2007 7:37 AM, Manfred Geiler
Forgot to assign the Workflow Scheme. Provide Patch is available now.
--Manfred
On Nov 16, 2007 9:52 PM, Scott O'Bryan [EMAIL PROTECTED] wrote:
Don't know. Anyway, I'll go ahead and take a look at it. It'll
probably be Monday before I get back to you.
Simon Lessard (JIRA) wrote:
[
I use straight html input tags for my form based login pages.
Why do you need h:input* for this? Because of skinning?
Rather than adding an intrusive name attribute I suggest to launch
two new components tc:inputFormBasedUsername and
tc:inputFormBasedPassword. The form based login is a very
[
https://issues.apache.org/jira/browse/MYFACES-1700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Manfred Geiler resolved MYFACES-1700.
-
Resolution: Fixed
Fix Version/s: 1.1.6-SNAPSHOT
Assignee: Manfred
Good question! ;-)
At least these params SHOULD be documented in the MyfacesConfig class
to have them ready in the javadoc.
Well, they aren't. So, Simon could you please open a jira issue for this?
Thanks,
Manfred
On Nov 19, 2007 5:17 PM, Simon Kitching [EMAIL PROTECTED] wrote:
Manfred
using Tomcat 5.5. inside of JBoss 4.0.2.
Reporter: Marcus Beyer
Assignee: Manfred Geiler
Fix For: 1.1.6-SNAPSHOT
On pages with more than one h:form, each one generates an element which has
always the same id, which is invalid HTML.
Looks like
On Nov 19, 2007 5:40 PM, Sochor Zdeněk [EMAIL PROTECTED] wrote:
Hi,
Manfred Geiler (JIRA) napsal(a):
Therefore I added a (MyFaces specific) config parameter:
org.apache.myfaces.RENDER_VIEWSTATE_ID
The default value is false for backwards compatibility.
I think this name is misleading
Bernd
Manfred Geiler schrieb:
MyFaces Master pom v2 had some flaws, so I released a new version.
You can find the (new) signed release candidate at [1].
I need at least three +1 votes to be able to distribute it to the
public maven repo.
Please vote
+1
FYI
I have added the portlet-bridge project to our continuum builds.
So from now on we have automatic snapshots at
http://people.apache.org/repo/m2-snapshot-repository/org/apache/myfaces/portlet-bridge/
I have also added the site-deploy. So, the site should be built and
deployed automatically
ok, I will do a karma request. stay tuned.
On Nov 15, 2007 11:14 PM, Scott O'Bryan [EMAIL PROTECTED] wrote:
Along with this, if it's okay for me to deploy this site, it doesn't
look like I'm in the myfaces group on minotaur. How do I go about
getting that changed?
Scott
Scott O'Bryan
Versions: 1.0.0-SNAPSHOT
Reporter: Manfred Geiler
Portlet Bridge should switch to new MyFaces Master POM:
groupId=org.apache.myfaces
artifactId=myfaces
version=3-SNAPSHOT in the meantime (2 has some flaws)
and switch to version 3 as soon as it is released.
--Manfred
--
This message
Already online:
http://myfaces.apache.org/portlet-bridge/
Link on main page will follow (just added it)
--Manfred
On Nov 16, 2007 10:32 AM, Manfred Geiler [EMAIL PROTECTED] wrote:
FYI
I have added the portlet-bridge project to our continuum builds.
So from now on we have automatic
Yes, I hope I can spend some time at the end of the week.
I will setup the initial maven dirs and stuff. I will also add the
sandbox we spoke about.
So, hopefully, next week we will have some space that wants to get
filled with cool Java lines...
--Manfred
On Nov 13, 2007 7:27 PM, Mario
It should be save to delete the site distribution from the master pom, now.
Thank you!
When will the myfaces master pom version 3 available?
we need another vote. middle of upcoming week should work.
--Manfred
Regards
Bernd
Manfred Geiler schrieb:
@maven gurus:
FYI: I
Oh no. That was my fault!
Was too eager with my continuum setup. There was a job that did a
site:deploy for the master pom.
Well, minotaur.apache.org/www/myfaces.apache.org seems ok again.
Thanks, Bernd (?)
Now we have to wait for the mirrors rsync :-(
--Manfred
On 11/8/07, Steve Rees
website is fixed. Thanks to Bernd and Mario!
pfffhhh
I owe another beer...
;-)
--Manfred
On 11/9/07, Manfred Geiler [EMAIL PROTECTED] wrote:
Oh no. That was my fault!
Was too eager with my continuum setup. There was a job that did a
site:deploy for the master pom.
Well
@maven gurus:
FYI: I just removed the site url from the distributionManagement in
the master pom. Having the root of our site distribution folder in the
common master is dangerous - as todays website breakdown showed. ;-)
(To justify myself, this is no new flaw, it was in the old master pom as
Versions: 1.1.6, 1.1.5
Reporter: Manfred Geiler
Assignee: Manfred Geiler
Fix For: 1.1.7-SNAPSHOT
- background attribute not allowed for td
- img without alt attribute
--
This message is automatically generated by JIRA.
-
You can reply to this email to add
don't know what VMBUILD is...
however, I readded trinidad to our continuum server and it builds ok.
And if someone could tell me where the trinidad jsf1.2 trunk is, I
will add that one as well.
--Manfred
On 11/5/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
Trinidad is building on
Issue Type: Bug
Affects Versions: 1.2.0, 1.1.5, 1.1.4, 1.1.3
Reporter: Manfred Geiler
Priority: Minor
id attributes with square brackets are not allowed according to W3C strict html
or xhtml
the forceId feature should render foo.idx instead of foo[idx
: MyFaces Core
Issue Type: Improvement
Components: General
Reporter: Manfred Geiler
Priority: Minor
According to dtd (html and xhtml) a tbody must not be empty. it must at least
have one tr which must at least have one td.
And in xhtml each table must
[
https://issues.apache.org/jira/browse/MYFACES-1764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12541064
]
Manfred Geiler commented on MYFACES-1764:
-
Did some tests with Firefox 2.0.0.9 and IE 6.
Looks ok and http
[
https://issues.apache.org/jira/browse/MYFACES-1764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Manfred Geiler updated MYFACES-1764:
Resolution: Fixed
Fix Version/s: 1.2.1-SNAPSHOT
1.1.6-SNAPSHOT
[
https://issues.apache.org/jira/browse/MYFACES-1764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Manfred Geiler updated MYFACES-1764:
Status: Patch Available (was: Open)
always render trtd if a datatable has no rows
I have no real problem with the look of our current wiki.
But I like the lookfeel of cwiki. So, if someone volunteers for setting up
and converting I am
+1
--Manfred
On 11/7/07, Cagatay Civici [EMAIL PROTECTED] wrote:
As a fan of cwiki, +1 for sure. The wiki converter seems to be handy.
On
So, you where faster than I. ;-)
(I'm currently trying to restore all continuum builds)
--Manfred
On Nov 7, 2007 7:08 PM, Paul McMahan [EMAIL PROTECTED] wrote:
I deployed the 1.2.1-SNAPSHOT core api and impl jars to the ASF
snapshot repo using mvn deploy.
Best wishes,
Paul
On Nov 7,
There is a number of strange users on our continuum server.
They all have names like ma144zda and emails like now963 at
gmail.com[EMAIL PROTECTED]
and are all unvalidated.
Looks like a *very funny* attack try.
I'm going to delete them.
--Manfred
FYI
I just relocated the shared branch 3_0_1 (ie. current JSF 1.2 branch of
shared) from
http://svn.apache.org/repos/asf/myfaces/shared/branches/3_0_1/
to
http://svn.apache.org/repos/asf/myfaces/shared/trunk_3.0.x/
The old location was rather confusing. It was not clear that 3_0_1 is the
Yeah, that's my next step.
Give me one more minute...
;-)
--Manfred
On Nov 7, 2007 10:16 PM, Bernd Bohmann [EMAIL PROTECTED] wrote:
Hello Manfred,
should be done for
myfaces/core/branches/1_2_1
too?
Regards
Bernd
Manfred Geiler schrieb:
FYI
I just relocated the shared
Anyone an idea why it wants to use maven-source-plugin:2.0.4-SNAPSHOT ?
--Manfred
On Nov 7, 0007 11:51 PM, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
Online report :
http://myfaces.zones.apache.org:8080/continuum/buildResult.action?buildId=1768projectId=46
Build statistics:
State:
All continnum snapshots should be working again!
--Manfred
On Nov 5, 2007 8:44 AM, Martin Marinschek [EMAIL PROTECTED]
wrote:
Hi all, maven-buffs,
our snapshots are available under daily builds again, but not in the
maven snapshot repository. Only project that works is - guess it -
Sorry, forgot the FYI mail yesterday!
The 1_2_1 trunk(!) was relocated from core/branches to core/trunk_1.2.x
(as was discussed earlier)
--Manfred
On 11/8/07, Andrew Robinson [EMAIL PROTECTED] wrote:
Where did the 1_2_1 branch go? Should the change for the pom.xml now
go in 1_2_0?
On
FYI
I relocated the core branch 1_2_1 (ie. current JSF 1.2 core branch) from
http://svn.apache.org/repos/asf/myfaces/core/branches/1_2_1/
to
http://svn.apache.org/repos/asf/myfaces/core/trunk_1.2.x/
The old location was rather confusing. It was not clear that 1_2_1 is
the current working
+1
BTW, don't forget to use the new myfaces master POM ;-)
--Manfred
On 11/6/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
Hi,
what are you guys thinking about doing a 1.0.4 release ?
Some patches made it into 1.0.4, so I'd like to move forward w/ a new
release.
Once 1.0.4 is
[
https://issues.apache.org/jira/browse/TRINIDAD-99?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Manfred Geiler resolved TRINIDAD-99.
Resolution: Duplicate
TRINIDAD-801
Change Parent Pom to MyFaces instead of Apache
Affects Versions: 1.0.4-core, 1.2.4-core
Reporter: Manfred Geiler
parent
groupIdorg.apache/groupId
artifactIdapache/artifactId
version4/version
/parent
should be replaced by
parent
groupIdorg.apache.myfaces/groupId
artifactIdmyfaces/artifactId
) --
Still an issue? Sounds like a maven bug.
--Manfred
On 11/6/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
please file a blocker issue :-)
On 11/6/07, Manfred Geiler [EMAIL PROTECTED] wrote:
+1
BTW, don't forget to use the new myfaces master POM ;-)
--Manfred
On 11/6
PROTECTED] wrote:
+0
Sorry I'm completely swamped this week, but I don't want you to feel
totally ignore again!
On Nov 5, 2007 6:37 AM, Bernd Bohmann [EMAIL PROTECTED]
wrote:
Ok
Manfred Geiler schrieb:
On 11/5/07, Bernd Bohmann [EMAIL PROTECTED] wrote:
I would
[
https://issues.apache.org/jira/browse/TRINIDAD-801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12540428
]
Manfred Geiler commented on TRINIDAD-801:
-
today or tomorrow - depends on mirrors...
Trinidad should use
FYI.
There is a nice new archive for our lists:
http://users.myfaces.markmail.org/
http://dev.myfaces.markmail.org/
(see email from Jason Hunter below)
--Manfred
(A forwarded email from Jason Hunter)
For the last few months I've been working on a new project: a web
site for interacting with
://people.apache.org/builds/myfaces/m2-staging-repository/org/apache/myfaces/myfaces/2/
On 10/31/07, Manfred Geiler [EMAIL PROTECTED] wrote:
This is the official vote for the release of our new MyFaces Master-POM.
The current myfaces-master POM has some flaws as was discussed in [1].
I already have tested
On 11/5/07, Bernd Bohmann [EMAIL PROTECTED] wrote:
I would suggest following changes for the next version:
remove
maven-compiler-plugin
maven-checkstyle-plugin
maven-pmd-plugin
I think these plugins should be configured by the subprojects.
Hmm, generally we have two options regarding
+1
Regarding dependencies:
We should be careful about dependencies in jsfcommons. Right.
The Joda converter would be a candidate for an *optional* compile
dependency.
--Manfred
On 10/31/07, Cagatay Civici [EMAIL PROTECTED] wrote:
Although it'll create a dependency, Joda is great:) so +1.
On 10/31/07, Mario Ivankovits [EMAIL PROTECTED] wrote:
Hi!
I have a suggestion that would solve this (and the naming as well):
Let's start a new MLP* called MyFaces JSF Commons
which is itself an umbrella project for two artifacts** called
MyFaces JSF Commons Utils and MyFaces JSF
On 10/31/07, Mario Ivankovits [EMAIL PROTECTED] wrote:
Hi!
which is itself an umbrella project for two artifacts** called
MyFaces JSF Commons Utils and MyFaces JSF Commons Components
I suggest that I prepare an initial setup, and check it in, so that
there is some concrete
This is the official vote for the release of our new MyFaces Master-POM.
The current myfaces-master POM has some flaws as was discussed in [1].
I already have tested a complete build of core and tomahawk with the new master.
I have NOT tested Trinidad and Tobago yet (both currently do not
depend
.
Regards,
Volker
2007/10/31, Manfred Geiler [EMAIL PROTECTED]:
Since there where some discussions about what should be in this new
project
and what not:
Renderkit independent components yes/no? Only static utils, convenient
base
classes?
I have a suggestion that would solve
, Volker Weber [EMAIL PROTECTED] wrote:
What is the problem having a taglib in the jar?
2007/10/31, Manfred Geiler [EMAIL PROTECTED]:
On 10/31/07, Mario Ivankovits [EMAIL PROTECTED] wrote:
Hi!
which is itself an umbrella project for two artifacts**
called
MyFaces JSF
As a less-intrusive (but less useful IMO) change, myfaces-shared dir
branches/3_0_1 could at least be renamed branches/3_trunk and
myfaces-code dir branches/1_2_1 be renamed branches/1_2_trunk. Otherwise
once these branches are released, every developer needs to use svn switch
to move to
Last time I tested the (normal) dialogs with Firefox the popups worked
but weren't really modal (I was able to click into the opening
windows). In IE they worked and were modal, but the performance of
greying out the opening page was bad.
On the other side the lightweight dialogs worked nice.
On 10/30/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
On 10/30/07, Manfred Geiler [EMAIL PROTECTED] wrote:
Last time I tested the (normal) dialogs with Firefox the popups worked
but weren't really modal (I was able to click into the opening
windows). In IE they worked and were modal
On 10/28/07, Mario Ivankovits [EMAIL PROTECTED] wrote:
Hi!
1. Clear separation of API and IMPL (at least on package level, better
by separate artifacts). Mind that the idea behind these commons
classes is that many other projects use them - and therefore depend on
them. So a clear and
Is an empty file (0 bytes) equal to no file (ie. null)?
is the same as
Is an empty String (length 0) equal to no String (ie. null)?
Technically the answer is no for both questions.
Well the pragmatical (and only reasonable) answer to the second
question is yes in the JSF spec (comp. required for
David,
Yes, attaching your goodies as attachment to a jira issue will be fine.
Thanks in advance,
Manfred
Hi ,
While working in my projects i had developed a good collection of static
utility methods for navigation handling, scope handling, resource
loading handling, message handling and
Matze,
What about providing a standard tr:validateNonEmptyFile Vaidator.
This would make everybody happy, right?
lg,
Manfred
On 10/29/07, Andrew Robinson [EMAIL PROTECTED] wrote:
Strong -1 on this
0 byte files are very valid, especially on a unix based platform.
There are many times that a
Our current MyFaces site artifact is named myfaces:
[..]
groupIdorg.apache.myfaces/groupId
artifactIdmyfaces/artifactId
version1.0.0-SNAPSHOT/version
packagingpom/packaging
nameMyFaces Site/name
[..]
I would like to rename this artifact to org.apache.myfaces:myfaces-site.
Reason: I
+1
But to avoid common design mistakes I propose some additional
issues/prerequisites:
1. Clear separation of API and IMPL (at least on package level, better
by separate artifacts). Mind that the idea behind these commons
classes is that many other projects use them - and therefore depend on
Proposal for a MyFaces maven master pom refactoring.
The current maven master pom for MyFaces has some flaws:
1. Not used by all MyFaces (sub)projects.
Currently Tobago has no parent pom and Trinidad uses
org.apache:apache:4 directly.
2. Located in the maven folder (i.e.
Mario, is it ok to remove the fusion folder from our myfaces svn root?
-Manfred
On 10/27/07, Wendy Smoak [EMAIL PROTECTED] wrote:
On 10/27/07, Manfred Geiler [EMAIL PROTECTED] wrote:
Proposal for a MyFaces maven master pom refactoring.
The current maven master pom for MyFaces has some flaws:
1. Not used by all MyFaces (sub)projects.
Currently Tobago has no parent
Wendy, I think this repo info in our myfaces master is redundant:
repository
releases
enabledfalse/enabled
/releases
snapshots
enabledtrue/enabled
/snapshots
idapache.snapshots/id
I can do it on Thursday.
Matthias, if you are able to spend some time earlier, then: please, thanks.
-Manfred
On 10/23/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
Yeah, let Manfred do it.
If he is to busy, I'll do it...
-M
On 10/22/07, Scott O'Bryan [EMAIL PROTECTED] wrote:
So who
Sorry, too late, Martin... :-(
On 10/19/07, Martin Marinschek [EMAIL PROTECTED] wrote:
You can surely take portlet-bridge - I like Ponte better, however...
regards,
Martin
On 10/19/07, Manfred Geiler [EMAIL PROTECTED] wrote:
Done.
Scott, could you please doublecheck the new project
-Mike-
Manfred Geiler wrote:
Done.
BTW, I remember a discussion about the Jira key JSR301. Reason for
the discussion was that it's no ideal name, because there might be a
time after jsr 301...
Well, renaming a Jira key is not possible.
What I could do is create a knew
The following extension is defined in the myfaces master pom:
extension
groupIdorg.apache.myfaces.maven/groupId
artifactIdbuild-tools/artifactId
version1.0.7-SNAPSHOT/version
/extension
My question: Is it necessary for tobago
Wessendorf wrote:
I like MFPB
On 10/18/07, Manfred Geiler [EMAIL PROTECTED] wrote:
Done.
BTW, I remember a discussion about the Jira key JSR301. Reason for
the discussion was that it's no ideal name, because there might be a
time after jsr 301...
Well, renaming a Jira key
: 861076b6accc3728a3e36d4c240cf28f
Regards,
Manfred Geiler
[1] http://jcp.org/en/jsr/detail?id=301
[2] http://incubator.apache.org/ip-clearance/index.html
[3] http://incubator.apache.org/ip-clearance/jsr-301-ri.html
[4] https://issues.apache.org/jira/browse/MYFACES-1664
+1
On 10/15/07, Manfred Geiler [EMAIL PROTECTED] wrote:
This is the official vote for the acceptance of Oracle's donation of
the JSR-301 [1] reference implementation code as a new MyFaces sub
module. Please note that - since the codebase is small enough and
there are no new committers
Scott,
I just added you to the Jira group myfaces-contributors. You should
now be able to assign, change and close issues.
Anyone else who needs such permissions?
--Manfred
On 10/4/07, Scott O'Bryan [EMAIL PROTECTED] wrote:
Hey guys,
Good news!! I got permission to change the copyrights on
the initial committers to the project?
Thanks,
Scott O'Bryan
Lawrence Mandel wrote:
Manfred,
You need to build the site (run build.xml in the Site project) and then
run svn update on people.apache.org to pull the changes from SVN into the
public site.
Lawrence
Manfred Geiler
I like the Exceptions section in the Geronimo Coding standards very much.
We should have these rules in our conventions as well. Hope they are
open source... ;-)
There is just one issue I would not recommend due to personal experience:
Abbreviations and Acronyms should *always* appear in
+1
Did some tests with the lightweight dialog framework. Looks great.
--Manfred
On 9/26/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
Hi,
I was running the needed tasks to get the 1.0.3 release of the Apache
MyFaces Trinidad CORE out. The artifacts are deployed to my private
Apache
* Which PMC will be responsible for the code: Apache MyFaces
* Into which existing project/module: Apache MyFaces
* Officer or member managing donation: Manfred Geiler (?)
Completed tasks are shown by the completion date (-MM-dd).
Identify the codebase
dateitem
Well done, Martin.
Thanks for taking the time to counter at full length.
--Manfred
On 9/15/07, Martin Marinschek [EMAIL PROTECTED] wrote:
Isn't it nice to read something like this? This blog made my day, see
my comments.
http://icoloma.blogspot.com/2006/10/myfaces-emperor-has-no-clothes.html
+1
The infos on the wiki diary for the last release should be up to date
and helpful - hopefully
--Manfred
On 9/11/07, Mario Ivankovits [EMAIL PROTECTED] wrote:
Hi!
For the Orchestra release I have to release shared first.
Any objections to start the process?
Ciao,
Mario
--
I committed the ip-clearance under the name jsr-301-ri.xml 3 days ago.
But it did not show up yet. Perhaps we have to ping someone to rebuild
the incubator site?
--Manfred
On 9/1/07, Martin Marinschek [EMAIL PROTECTED] wrote:
Yes, but I think the ruling says that the commit needs to be done by
I committed a new ip-clearance document a few days ago:
https://svn.apache.org/repos/asf/incubator/public/trunk/site-author/ip-clearance/jsr-301-ri.xml
Well, it does not show up yet on the
http://incubator.apache.org/ip-clearance/ page.
Is the incubator site automatically rebuilt periodically?
projects that implement the same JSR, for example Cayenne
and OpenJPA. Third, what happens when down the road JSF Portlet
Bridge 2.0 becomes JSR456?
On 9/3/07, Manfred Geiler [EMAIL PROTECTED] wrote:
done.
Project: MyFaces Portlet Bridge
Key: JSR301
URL: http://myfaces.apache.org/jsr301
Should be able to add a new jira project myself.
What I need first:
- name: MyFaces JSR-301 sounds very technical :( Is MyFaces
Portlet Bridge ok?
- key: JSR301, PBRIDGE, ...?
- url: http://myfaces.apache.org/jsr301/ ?
- a project lead ?
--Manfred
On 9/3/07, Matthias Wessendorf [EMAIL
[EMAIL PROTECTED] wrote:
Hi Manfred,
;)
take MyFaces Portlet Bridge!
I wrongly assumed there could be more than one key, but hey, why would
they say key to it then? - take JSR301
regards,
Martin
On 9/3/07, Manfred Geiler [EMAIL PROTECTED] wrote:
yes to all suggestions is funny.
I
101 - 200 of 694 matches
Mail list logo
