release to be out - which hopefully can happen during the next days.Thanks,Manfred
On 4/13/06, Manfred Geiler [EMAIL PROTECTED] wrote:
Werner,Look at the component classes. Everything between the BEGIN and END GENERATED CODE markers was generated by a Velocity template from the according component
On 4/13/06, Werner Punz [EMAIL PROTECTED] wrote:
Manfred Geiler schrieb: Werner, Look at the component classes. Everything between the BEGIN and END GENERATED CODE markers was generated by a Velocity template from the according component xml files.
In a few minutes I will checkin the reborn
What about Mario's fix 2 hours ago? (see Jira)ManfredOn 4/13/06, Sean Schofield [EMAIL PROTECTED]
wrote:This issue still isn't fixed.Please review my latest JIRA comments
on the proposed solution.This issue is our top priority right now.SeanOn 4/12/06, Sean Schofield [EMAIL PROTECTED] wrote: BTW,
On 4/12/06, Gert Vanthienen [EMAIL PROTECTED] wrote:
L.S.,Yesterday I attached a patch to issue TOMAHAWK-36 in JIRA, butapparently JIRA doesn't send notifications when you attach a file, soI'll just repeat the question in the comment of this issue here directly.
The patch file contains
Ok, I just spent a few minutes and found the old codegenerator on the attic.Will try to integrate it into current maven structure.Please stay tuned!Thanks,Manfred
On 4/12/06, Gert Vanthienen [EMAIL PROTECTED] wrote:
Manfred Geiler wrote: ... The code generation for common component methods
TortoiseSVN has this right mouse button support for moving and copying as well. Right click and drag shows a popup with a bunch of options (Move, copy, ...)ManfredOn 3/30/06,
Mike Kienenberger [EMAIL PROTECTED] wrote:
On 3/29/06, Dennis Byrne [EMAIL PROTECTED] wrote: If you drag it from one
+1ManfredOn 4/10/06, Bernd Bohmann [EMAIL PROTECTED] wrote:
Hello,the svn move is still pending.See http://issues.apache.org/jira/browse/INFRA-769.But I would like to move the Tobago site to MyFaces.
I would suggest the url myfaces.apache.org/tobago.Any objections?RegardsBernd--Dipl.-Ing. Bernd
FYI:The latest maven-idea-plugin source build works fine with MyFaces.See http://wiki.apache.org/myfaces/JetBrains_IntelliJ_IDEA for detailed instructions.
Manfred
Will be there and can tell you some stories about MyFaces history.ManfredOn 4/7/06, Stan Silvert
[EMAIL PROTECTED] wrote:
In addition to the dinner, it sounded like there was interest
in a MyFaces "Committers and Contributors" meeting.
Please let me know if you are coming and if
The idea is to render the text in HTML as the user would expect even
if he is no HTML expert. Therefore we address the special HTML
whitespace handling here:
* successive spaces are rendered as nbsp;
* line breaks are rendered as br/
This is also the difference between write and writeText as I
Bernd et al.,
Since Maven 2.0.3 has better Wagon support now. Is there a chance to
get rid of our custom wagon-maven-plugin?
Manfred
-- Forwarded message --
From: John Casey [EMAIL PROTECTED]
Date: Mar 29, 2006 2:03 AM
Subject: [ANN] Maven 2.0.3 Release
To: announce@apache.org
+1
Manfred
On 3/10/06, Stan Silvert [EMAIL PROTECTED] wrote:
In addition to dinner, what do you guys think of having a more serious
meeting for committers and other contributors? Since we have grown so much,
I think it would be a great opportunity to do some
organizational/informational
On 3/10/06, Mario Ivankovits [EMAIL PROTECTED] wrote:
No one?
I just want to collect what should be done to make shared clean:
I think the following should be moved to tomahawk:
JavascriptUtils
DummyForm*
MyfacesConfig
What else?
I see a problem with moving DummyForm out,
:
On 3/1/06, Manfred Geiler [EMAIL PROTECTED] wrote:
On 3/1/06, John Fallows [EMAIL PROTECTED] wrote:
We need to define the meaning of with more caution.
Terms for future commons utils and helpers:
* stable API
+1. :-)
* downward compatibility within major version
Currently the base classes for the command* tags (in shared) implement
the functionality of dummyForm, this is why its not needed to have the
overloaded renderer stuff and why it works with h: and t:
Sorry for being slow-witted.
There is no difference. If the user overwrites the Link- or
On 3/10/06, Mario Ivankovits [EMAIL PROTECTED] wrote:
Hi!
Currently the base classes for the command* tags (in shared) implement
the functionality of dummyForm, this is why its not needed to have the
overloaded renderer stuff and why it works with h: and t:
Sorry for being
Ok, just added the initial committers to the proposal.
http://wiki.apache.org/myfaces/adfproposal
Manfred
On 3/9/06, Martin Marinschek [EMAIL PROTECTED] wrote:
Definitely, yes.
Sorry for the omission.
We'll update that.
regards,
Martin
On 3/9/06, Justin Erenkrantz [EMAIL PROTECTED]
Mario,
As mentioned earlier, yes, there is some pain with the new shared
structure. But my feeling is that most of the pain is due to the fact
that we have to break with some (bad) habits.
Please think of the two libs shared_impl and shared_tomahawk as two
*different* things. This affects
On 3/9/06, Werner Punz [EMAIL PROTECTED] wrote:
Mario Ivankovits schrieb:
And - IMHO the killer, the shared is not interoperable, means it cant
put stuff in the request and use it again if called from another package
as they are different classes - different package names.
See my other
On 3/9/06, Simon Kitching [EMAIL PROTECTED] wrote:
On Thu, 2006-03-09 at 09:58 +0100, Werner Punz wrote:
Mario Ivankovits schrieb:
Hi!
Its again me ... somewhat angry, so sorry *g* I CANT SET A
BREAKPOINT IN SHARED ANY MORE - or I have to do it twice in shared_impl
and
On 3/9/06, Werner Punz [EMAIL PROTECTED] wrote:
Manfred Geiler schrieb:
On 3/9/06, Werner Punz [EMAIL PROTECTED] wrote:
Mario Ivankovits schrieb:
And - IMHO the killer, the shared is not interoperable, means it cant
put stuff in the request and use it again if called from another
On 3/9/06, Mario Ivankovits [EMAIL PROTECTED] wrote:
DummyForm was a special feature of MyFaces, that was wrongly put into
the implementation - it should have been put into tomahawk, where it
belongs to.
Right?
No, DummyForm is a *feature* of the MyFaces impl. There is nothing in
the
Yes and the DummyForm feature *can* be used with any JSF impl - at
least theoretically ;-). But if people want to use this feature (ie.
having commandlinks without an enclosing form) they should do so by
relying on tomahawk not on the myfaces impl.
Manfred
On 3/9/06, Mike Kienenberger [EMAIL
(Eclipse-centric) point of view.
And as he points out, if there's an issue revealed by this change,
then it's a real dependency issue between tomahawk and Impl that needs
to be fixed rather than re-hidden.
On 3/9/06, Manfred Geiler [EMAIL PROTECTED] wrote:
Mario,
As mentioned earlier
Yes, I agree.
We apparently made the false assumption that shared is already stable
enough to freeze and start releasing. Mario is right I think. Perhaps
we should postpone the release process and work in trunk until we
really have a stable state.
Manfred
On 3/9/06, Mario Ivankovits [EMAIL
Count me in, too.
Looking forward to meeting you all again.
Regards,
Manfred
On 3/9/06, Martin Marinschek [EMAIL PROTECTED] wrote:
Add one more.
regards,
Martin
On 3/9/06, Kito D. Mann [EMAIL PROTECTED] wrote:
You can definitely count me in :-).
+1
Everything that is not in spec (ie MyFaces Extensions) and not needed
by impl should be moved to tomahawk IMO. This way shared module will
slim down. The less we have in shared the less we have dependencies
between impl, shared and tomahawk. And the less will be the pain
with our new project
I think moving to tomahawk is ok by now.
Manfred
On 3/3/06, Mario Ivankovits [EMAIL PROTECTED] wrote:
Hi!
BTW, shouldnt it be easily possible to get rid of the dependency to
ServletExternalContextImpl?
Its used just to set a session attribute, no?
I think you are correct. If you
I recommend adding the *-sources.jar files instead of the target dirs
for the reasons mentioned earlier in another thread (jar sources
read-only, target dirs volatile, ...)
Can some of the eclipse gurus please try that out and revise the wiki
instructions accordingly?
Thanks,
Manfred
On
On 3/1/06, John Fallows [EMAIL PROTECTED] wrote:
On 2/24/06, Manfred Geiler [EMAIL PROTECTED] wrote:
On 2/23/06, Mike Kienenberger [EMAIL PROTECTED] wrote:
On 2/22/06, Sean Schofield [EMAIL PROTECTED] wrote:
In response to #1 I would say we do not need to be in the business
information, run Maven with the -e switch
[INFO]
-
I made some progress on the merge but I will need to resolve this
before I can check in.
Sean
On 2/28/06, Manfred Geiler [EMAIL PROTECTED] wrote:
Ok, I did some
Added according otherArchives elements to POMs but archives do not show up.
Perhaps some Maven guru could have a closer look?
Thanks,
Manfred
On 2/15/06, Jesse Alexander (KBSA 21) [EMAIL PROTECTED] wrote:
The new website has links to the mailing list-archives that are not
searchable.
At
Any Maven guru listening?
To be able to build a fully functionable idea project after our
massive refactoring we need the new features of the idea plugin beta
2.
Q1: What is the quickest way to bring idea-plugin-2.0-beta-2-SNAPSHOT
into the http://cvs.apache.org/maven-snapshot-repository ?
Q2:
can continue to make changes
there.
Sean
On 2/26/06, Manfred Geiler [EMAIL PROTECTED] wrote:
Step 3 is now done as well.
Well, some examples already work but unfortunately not all.
I think most of the problems are related to ExtensionsFilter and/or
expression evaluation
process that would be nice.
Sean
On 2/28/06, Manfred Geiler [EMAIL PROTECTED] wrote:
Hmm, perhaps the ../src/main/java (relative path) in the ant task
does not work when run with continuum? Perhaps we should move ant task
to an external build.xml and set the basedir explicitly. Will try
Step 1 of refactoring is done.
That means: All commons classes have been copied to the shared module
and are now in package org.apache.myfaces.shared.*. This was done in
shared trunk(!) and core and tomahawk branches 1_1_2.
Step 2 is pending (Hope I can finish it today):
That is: Deriving two
First two (of three) steps of commons--shared refactoring is done:
Step 1: All former commons classes have been copied to a new shared
module and have been refactored to package
org.apache.myfaces.shared.*
Step 2: An intermediate myfaces-shared-impl-2.0.0-SNAPSHOT.jar is now
built automatically.
)
Thanks,
Manfred
On 2/26/06, Manfred Geiler [EMAIL PROTECTED] wrote:
First two (of three) steps of commons--shared refactoring is done:
Step 1: All former commons classes have been copied to a new shared
module and have been refactored to package
org.apache.myfaces.shared.*
Step 2
On 2/23/06, Mike Kienenberger [EMAIL PROTECTED] wrote:
On 2/22/06, Sean Schofield [EMAIL PROTECTED] wrote:
In response to #1 I would say we do not need to be in the business of
ensuring developers can rely on our public API's. From my perspective
we are in the business of providing a JSF
I recollected all the issues, ideas, and feedback and tried to
summarize them (from my personal POV):
==
Here is a management summary of what we could/should end with:
* A myfaces-shared project, housing all MyFaces-specific classes
shared between impl and
On 2/23/06, Sean Schofield [EMAIL PROTECTED] wrote:
* myfaces-shared will have sub-modules that represent the custom
dependency libs with private namespace for each MyFaces subproject
that needs shared classes (only impl and tomahawk so far). All (=both)
artifacts will automatically be
On 2/21/06, John Fallows [EMAIL PROTECTED] wrote:
Folks,
There seems to be increasing discussion lately regarding MyFaces Commons and
how it relates to both MyFaces Core and MyFaces Tomahawk.
Adding Tobago and ADF Faces to the discussion makes it even more critical
that we come up with a
Hi all,
Some more investigations and thinking led me to the following conclusion:
Key to all that confusion (me beeing the most concerned ;-) and to our
divergent points of view regarding commons release policy,
auto-repackaging (aka inlining), etc. is the mixture in the type of
classes we
Sean,
is there an important reason for not having these svn macros?
Manfred
On 2/22/06, Apache Wiki [EMAIL PROTECTED] wrote:
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Myfaces Wiki for
change notification.
The following page has been changed by schof:
track of who last
modified etc. In fact, SVN tells you who last modified what line (svn
blame). A while back I seem to recall us deciding that since SVN is
keeeping track of all of this there was no need to keep up the
practice.
Sean
On 2/22/06, Manfred Geiler [EMAIL PROTECTED] wrote
Once our refactoring of commons classes into namespace
org.apache.myfaces.commons.* is done we can easily change namespace
for inlining by doing String search and replace on source level:
replace org.apache.myfaces.commons by
org.apache.myfaces.impl-commons (or alike)
I already have a working
The issue that John raises that interests me is the future inclusion
of Tobago and ADF. There may be code that could be shared between
these two projects and Tomahawk that has nothing to do with impl. So
essentially we are talking about another core for components.
A perfect candidate for
Versions: 1.1.2-SNAPSHOT
Reporter: Manfred Geiler
Assigned to: Dennis Byrne
In a multi-threaded environment or when using multiple webapps within one
container this is subject to fail.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact
Stan,
The PortletUtil class currently only works with the MyFaces
implementation, right?
Therefore I think we should move it to impl source root to make this
clear for the end user.
Any objections to this?
Manfred
problems ?
On 2/22/06, Manfred Geiler [EMAIL PROTECTED] wrote:
Stan,
The PortletUtil class currently only works with the MyFaces
implementation, right?
Therefore I think we should move it to impl source root to make this
clear for the end user.
Any objections
On 2/21/06, Martin Marinschek [EMAIL PROTECTED] wrote:
Hmmm
ok - I just have seen many proposals coming in via general. Never mind!
Have you got any feedback on the proposal so far?
Njet.
-Manfred
regards,
Martin
On 2/20/06, Manfred Geiler [EMAIL PROTECTED] wrote:
Martin
+1 for dependency on commons-logging 1.0.4
BTW, Stan (Silvert), how do you solve these logging issues in JBoss?
AFAIK, JBoss has only one central log4j configuration. However, is
there a way to config logging per eapp or webapp? If yes, how does
JBoss address those issues with shared classes?
we carefully document and explain this on the
website and include instructions and considerations for those building
with maven or using myfaces implementation in their J2EE containers.
Sean
On 2/18/06, Manfred Geiler [EMAIL PROTECTED] wrote:
As Martin already has mentioned, I'm more
dependency. If it doesn't perhaps we could put our
energies into helping them resolve this. In the meantime, I think my
proposed workaround would be better.
Sean
On 2/21/06, Manfred Geiler [EMAIL PROTECTED] wrote:
On 2/20/06, Sean Schofield [EMAIL PROTECTED] wrote:
Wow that seems really
[ http://issues.apache.org/jira/browse/MYFACES-750?page=all ]
Manfred Geiler resolved MYFACES-750:
Fix Version: Nightly
Resolution: Fixed
Actually implemented a slightly different solution than was suggested. But
synchronized is the right
this to [EMAIL PROTECTED]
regards,
Martin
On 2/19/06, Manfred Geiler [EMAIL PROTECTED] wrote:
Dear Incubator PMC,
We, the sponsoring members listed below, ask that you accept the
following proposal for a new project at Apache, an effort centered on
providing web application developers
On 2/19/06, Simon Kitching [EMAIL PROTECTED] wrote:
On Sun, 2006-02-19 at 00:46 +, [EMAIL PROTECTED] wrote:
Author: mmarinschek
Date: Sat Feb 18 16:46:18 2006
New Revision: 378805
URL: http://svn.apache.org/viewcvs?rev=378805view=rev
Log:
minor changes in application-factory,
feel safe about using commons to build their components.
On 2/17/06, Manfred Geiler [EMAIL PROTECTED] wrote:
Well it's a package refactoring. So, each dependend (or using) class
in impl and tomahawk must be aligned as well. I'm feeling much warmer
when doing this within my IDE, which
Ok, here is my 0.02 although I strongly agree with Martin that there a
many many many other questions and issues to solve, that deserve our
energy and work mania more than this underscore thingy.
* I have heard two real pro arguments from Adam that need not (but
could!) help other people read
Hi all,
Sean already posted some thoughts recently. I know we should bring out
our next release first, but meanwhile we could have some thoughts
about future JIRA structure and version management.
Here is a short roundup of what we have:
MyFaces (sub-)projects on the site:
API
Impl
Commons
On 2/17/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
to
org.apache.myfaces.commons.*
yes, why not.
I'm not sure at all if this is a good idea. Probably not ;-)
Just wanted to know what others think.
hehe, was just thinking the same
What about tomahawk ?
o.a.m.custom.* -
pps. Use svn move to do this so we don't lose our history
Does anyone know if IntelliJ does svn move behind the scenes when
moving (refactoring) classes?
Thanks,
Manfred
I would like to add the following to the myfaces-master pom:
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-compiler-plugin/artifactId
configuration
source1.3/source
target1.3/target
The current release policy causes headache for Martin and confusion for me. ;-)
Just looked at the tomahawk 1.1.2 branch. It depends on commons 1.1.3-SNAPSHOT.
Shouldn't the tomahawk freeze depend on commons 1.1.2 instead?!
The longer I think about it, the more I'm really sure that the only
.
Regards,
Arvid
Manfred Geiler wrote:
pps. Use svn move to do this so we don't lose our history
Does anyone know if IntelliJ does svn move behind the scenes when
moving (refactoring) classes?
Thanks,
Manfred
--
http://www.irian.at
Your
On 2/17/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
I am with you Matthias ;-) I prefer to use 'this'...
expect, you are using vi ... :-))
on a monochrom display...
:-)
Manfred
Cool!
I still have my Sinclair ZX81 in the attic.
Can you give me the right compiler directives?
:-)
Manfred
On 2/17/06, Bruno Aranda [EMAIL PROTECTED] wrote:
I work with my Spectrum ZX80, which runs pretty smooth ;-)
On 2/17/06, Manfred Geiler [EMAIL PROTECTED] wrote:
On 2/17/06, Matthias
On 2/17/06, Sean Schofield [EMAIL PROTECTED] wrote:
After talking with Martin and Manfred I've come to realize the issue
here. I now propose the following approach to releasing the core.
This approach also applies to tomoahawk (just replace the word 'core'
with 'tomahawk'.)
1.) branch
And at some future point, we'll probably also incorporate a
repackaging step into one of these (I'd suggest core, probably) to
give the two commons versions different namespaces.
That's what I'm attracted at more and more, too. ;-)
Manfred
-1.1.3.jar
WEB-INF/lib/myfaces-impl-1.1.2.jar
WEB-INF/lib/myfaces-tomahawk-1.1.3.jar
Not good!
Ergo: We must release all 3 modules in sync.
Manfred
On 2/17/06, Manfred Geiler [EMAIL PROTECTED] wrote:
And at some future point, we'll probably also incorporate a
repackaging step into one
Yes, true.
I should have said: And that's why I still have the opinion that we
cannot do other than
release all three at the same time - as soon as we release a new
commons version.
Thanks for pointing this out, Bruno.
Manfred
On 2/17/06, Bruno Aranda [EMAIL PROTECTED] wrote:
Maybe releasing
Ok, I will now fix all the tomahawk dependencies and do some tests.
Stay tuned.
Manfred
On 2/15/06, Dennis Byrne [EMAIL PROTECTED] wrote:
How would we check if someone accidentally made a mistake and accessed
impl in tomahawk?
This has happened at least once but it was fixed, so +1 .
Schofield [EMAIL PROTECTED] wrote:
I think the dependencies are already the way we want them.
Sean
On 2/16/06, Manfred Geiler [EMAIL PROTECTED] wrote:
Ok, I will now fix all the tomahawk dependencies and do some tests.
Stay tuned.
Manfred
On 2/15/06, Dennis Byrne [EMAIL PROTECTED
depend on the core. There's no harm
there (I think.)
Sean
On 2/16/06, Sean Schofield [EMAIL PROTECTED] wrote:
Wait a sec. The examples are different. We *want* those to depend on
tomahawk and we want the dependencies to be included in the WAR.
Sean
On 2/16/06, Manfred Geiler
. tomahawk-sandbox: added a TODO comment (there are compile time
dependencies on myfaces-impl that have to get fixed)
5. tomahawk-sandbox-examples: changed myfaces-impl dependency from
compile to runtime
Manfred
On 2/16/06, Manfred Geiler [EMAIL PROTECTED] wrote:
No, we don't want examples to depend
Just updated the wiki page - before Craig changes his mind ;-)
Manfred
On 2/15/06, Omar Tazi [EMAIL PROTECTED] wrote:
Craig, thanks for volunteering I think you would be an awesome mentor,
could you please add your name to this page:
http://wiki.apache.org/myfaces/adfproposal
Thanks.
Not opposed, of course, but we did not have an official vote by the
Sponsor (i.e. the MyFaces PMC) yet. The vote will be public (on dev
list), but only MyFaces PMC members will have binding votes, of
course. Stay tuned please.
Once we have enough +1 and (hopefully) no binding -1, we can send it
to
MyFaces PMC members,
Please vote for the acceptance of ADF Faces as a candiate for
Incubation. On positive vote (no binding -1 within 72 hours) I will
send a proposal for Podling status to the Incubator PMC.
Attached is a snapshot of the proposal.
Regards,
Manfred Geiler
And here is my
+1 for Candidate status
Manfred
On 2/15/06, Manfred Geiler [EMAIL PROTECTED] wrote:
MyFaces PMC members,
Please vote for the acceptance of ADF Faces as a candiate for
Incubation. On positive vote (no binding -1 within 72 hours) I will
send a proposal for Podling status
A matter of taste I think.
I personally like the public modifier for interface methods. Although
it is redundant information it makes reading classes (and interfaces
which are classes as well) easier. When I have a quick glance on the
methods of a variable's class (i.e. by jumping to the method
What about the optional attribute in the dependency. Would that
solve the problem?
Manfred
On 2/15/06, Sean Schofield [EMAIL PROTECTED] wrote:
Why has myfaces-impl and myfaces-api the scope provided?
Is the myfaces-impl and myfaces-api installed on the container?
The normal user would
a tomahawk
dependency.
FWIW we will probably all want this in our personal projects since we
use the MyFaces implementation. But for other users this is not the
case. So I say make the user specify the core dependencies explicity.
Sean
On 2/15/06, Manfred Geiler [EMAIL PROTECTED] wrote:
What
I agree. Let's do homework first.
And for all itchy guys: Let's start a wiki page with the 1.2 roadmap
as Sean suggested.
Manfred
On 2/15/06, Sean Schofield [EMAIL PROTECTED] wrote:
I'm also not very itchy for JSF 1.2. I too will be looking at
facelets on my next JSF project or using the RI.
Something like this should do it:
plugin
artifactIdmaven-antrun-plugin/artifactId
executions
execution
phasegenerate-sources/phase
configuration
tasks
xslt basedir=src/main/tld
Just did a complete new build. With success.
ibiblio and repo1 seem to be very slow from time to time.
Please give it a retry.
Manfred
On 2/14/06, Dennis Byrne [EMAIL PROTECTED] wrote:
Is anyone else getting this?
[INFO] Failed to resolve artifact.
GroupId: org.apache.myfaces.core
On 2/14/06, Sean Schofield [EMAIL PROTECTED] wrote:
Q1. Regarding the maven sub-project: Why do build-tools and master-pom
have no parent relationship to the maven-project pom?
There is nothing that needs to really be shared between the two. More
importantly, since every other subproject
Q7. AFAIK the scm config is not needed within sub-modules. Maven
calculates the right SVN URLs. So, any objections against removing scm
config from core/api, core/impl, tomahawk/core etc. ?
Yes I object. It won't work. This only works if your artifacts have
the same name as your
Maven likes poms.
And so do I - but too much of them make me dizzy ;-)
I don't think you are going to be able to do much
better but I'd be happy to see it! When you think about it, there
really are a bunch of artifacts in our project and each artifact
*must* have a pom. The artifacts
version is the better and easier solution. Thanks, Sean.
Manfred
Regards
Bernd
Manfred Geiler schrieb:
Yes, I agree with Martin.
Perhaps a better way would be to patch the release plugin so that it
accepts SNAPSHOTs. Since I have dived into maven this week for a
rather complex
to
build proper binaries if one of the plugins that is part of the build
process is subject to change. So, no good idea to release with any
dependency on a SNAPSHOT artifact - be it plugin or not.
Sorry for beeing slow-witted. :-)
Manfred
On 2/13/06, Manfred Geiler [EMAIL PROTECTED] wrote:
On 2
+1 for real subproject, no objections
Manfred
On 2/12/06, Bernd Bohmann [EMAIL PROTECTED] wrote:
Hello,
after completing all tasks for the incubation of Tobago only the
sign-off is missing. At this point we want to know if someone has
objections against leaving the incubator and becoming a
Ok, here we go:
http://incubator.apache.org/incubation/Process_Description.html
This one should work:
Champion: Manfred Geiler (as vice-president I'm an _officer_ of the ASF)
Sponsor: MyFaces
Mentor: James Holmes (no need to be a member AFAIU)
Next steps:
1. official Vote on the MyFaces PMC
undertaken by a permanent member of the Apache
Software Foundation )
[1] http://incubator.apache.org/incubation/Roles_and_Responsibilities.html
[2] http://incubator.apache.org/incubation/Process_Description.html
-Matthias
On 2/13/06, Manfred Geiler [EMAIL PROTECTED] wrote:
Ok, here we go
Yes, I agree with Martin.
Perhaps a better way would be to patch the release plugin so that it
accepts SNAPSHOTs. Since I have dived into maven this week for a
rather complex project at my company, I'm no longer a total maven
newby. Hope I can afford some time next week to bring in my new
Sean, thanks very much. Looks great.
I will try to spend a few hours next week to replace some of the blah
blah pages... ;-)
Manfred
On 2/11/06, Sean Schofield [EMAIL PROTECTED] wrote:
The new website is up (with many broken links and omissions.)
Continuum should be publishing on the hour but
Please welcome our new MyFaces PMC members
Mike Kienenberger
and
Bruno Aranda!
Mike and Bruno have both been well known MyFaces contributors and
committers for some time and helped out on many places within the
MyFaces world. Therefore last week there was a vote to invite them to
the PMC and
+1
Manfred
On 2/7/06, Martin Marinschek [EMAIL PROTECTED] wrote:
Ok - as for me, we can go with this. Everything else can be discussed
on the incubator mailing list.
regards,
Martin
On 2/7/06, Jonas Jacobi [EMAIL PROTECTED] wrote:
Updated the Wiki page.
Jonas
Jonas Jacobi
Such questions to the users list, please.
Thanks,
Manfred
2006/2/5, Tom Butler [EMAIL PROTECTED]:
Is it possible to return to the same position within a datascroller after
leaving the page and returning (i.e., datatable displays a large result set;
user has scrolled through the data and is
@Martin/@Manfred
Can you make sure that '[EMAIL PROTECTED]' is allowed
to send to the dev list?
Done.
Manfred
No, nothing in moderation so far. Neither dev nor commits.
Manfred
2006/2/6, Sean Schofield [EMAIL PROTECTED]:
I did a test and the success email did not seem to make it to the
list. Is it in moderation?
sean
On 2/6/06, Manfred Geiler [EMAIL PROTECTED] wrote:
@Martin/@Manfred
401 - 500 of 694 matches
Mail list logo
