I'm glad that I could be of some help.
--
Cristi Toth
-
Codebeat
www.codebeat.ro
On Jan 30, 2008 12:52 AM, Frank Nimphius [EMAIL PROTECTED] wrote:
Cristi,
thanks for the pointer to the beach.css. I found a clue that got me going
with
af|tree::node-icon:folder
Frank
Hi,
I see Leonard is currently doing a lot of work on something called tomahawk
1.2, which surprised me a little.
I have checked the mail archives, and see some discussions happening around
june 2007 regarding having a version of tomahawk specifically for JSF1.2.
But since then, we have
I think that Leonardo is working on generating the components classes
tlds, facelet-taglibs with the maven-faces-plugin - I'm pretty sure
this makes sense.
As this will then mean there is a switch to either use JSF1.2 or 1.1
in the generation (hopefully this will work) both 1.1.7 and a 1.2
based
Hi,
On Jan 30, 2008 9:53 AM, Simon Kitching [EMAIL PROTECTED] wrote:
Hi,
I see Leonard is currently doing a lot of work on something called tomahawk
1.2, which surprised me a little.
I have checked the mail archives, and see some discussions happening around
june 2007 regarding having a
[
https://issues.apache.org/jira/browse/MYFACES-1225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12563912#action_12563912
]
Simon Kitching commented on MYFACES-1225:
-
It looks to me like Dennis has got the
Hi,
As being the guy who has created the tomahawk 1.2 branch and spent a lot of
time with it, upgrading to 1.2 is not an easy task because as Simon
mentioned the code is old and crusty.
I agree that non rendering stuff should be moved to commons, I've some
candidates on my own from sandbox and
If tomahawk is going to be split into pieces, then it really does not make
sense to completely change the build approach. It currently works, so let's
just stay with what is already there.
Regards, Simon
Martin Marinschek [EMAIL PROTECTED] schrieb:
I think that Leonardo is working on
Can you open an issue in the issue-tracker of MyFaces? I have already
prepared a fix, and will commit it this evening.
regards,
Martin
On 1/30/08, Val Blant [EMAIL PROTECTED] wrote:
The log shows that the configs are read twice:
[2008-01-29 18:43:55,145] INFO
For me, it would be important that this new build-system could
generate 1.1.7 and 1.2 - Leonardo, would this be possible?
regards,
Martin
On 1/30/08, Simon Kitching [EMAIL PROTECTED] wrote:
Hi,
Well, the first question to ask is: what do we want to release in the near
future?
I think the
I think if something simplifies the maintenance of tomahawk I welcome
it. Moving stuff to commons and all that is an early idea and I have
not read specific plans about how we could do that, who could do that,
so I guess it will take a while to go. In the meanwhile, if we can
just remove some of
[
https://issues.apache.org/jira/browse/TOMAHAWK-1184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gunther Schmidl updated TOMAHAWK-1184:
--
Status: Open (was: Patch Available)
Vertical Week Divider incorrectly rendered in
[
https://issues.apache.org/jira/browse/TOMAHAWK-1184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gunther Schmidl updated TOMAHAWK-1184:
--
Status: Patch Available (was: Open)
Vertical Week Divider incorrectly rendered in
Hello Volker,
it's like a chicken egg problem.
Nobody would test the new tree in the sandbox until it's released.
I think the new tree should more public available. We should try to get
more feedback.
I would like to include the sandbox in the nightly build, now. We can
revisit this decision
Include sanbox in nightly build
---
Key: TOBAGO-610
URL: https://issues.apache.org/jira/browse/TOBAGO-610
Project: MyFaces Tobago
Issue Type: Improvement
Affects Versions: 1.0.14
Reporter: Bernd
Hi,
Well, the first question to ask is: what do we want to release in the near
future?
I think the next Tomahawk release should be 1.1.7, containing bugfixes and a
few promotions from sandbox. It should not contain radical refactoring of the
build process.
In the longer term, I believe we
Vertical Week Divider incorrectly rendered in IE
Key: TOMAHAWK-1184
URL: https://issues.apache.org/jira/browse/TOMAHAWK-1184
Project: MyFaces Tomahawk
Issue Type: Bug
Components:
[
https://issues.apache.org/jira/browse/MYFACES-1225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12563972#action_12563972
]
Paul Pogonyshev commented on MYFACES-1225:
--
Yes, indeed. However, I checked out
Hi!
The Myfaces PMC is proud to announce a new addition to our community.
Please welcome Bernhard Huemer as the newest MyFaces committer.
Welcome Bernhard !
---
Mario
Ciao,
Mario
[
https://issues.apache.org/jira/browse/MYFACES-1225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12563984#action_12563984
]
Simon Kitching commented on MYFACES-1225:
-
Hmm. Did you mean method
[
https://issues.apache.org/jira/browse/TRINIDAD-915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matthias Weßendorf resolved TRINIDAD-915.
-
Resolution: Fixed
Fix Version/s: 1.2.6-core
Simplify???
This code generation stuff does make code more *consistent* between the various
bits (taglib, faces-config, java) but definitely does not make it simpler to
work with. IMO, it introduces a whole new set of concepts that will make it
harder for new developers to get into this code.
[
https://issues.apache.org/jira/browse/TOMAHAWK-1184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12563994#action_12563994
]
Zdenek Sochor commented on TOMAHAWK-1184:
-
Hi,
this is just another IE bug :(
[
https://issues.apache.org/jira/browse/TOMAHAWK-1184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12563988#action_12563988
]
Simon Kitching commented on TOMAHAWK-1184:
--
Hmm..this issue is exactly the
[
https://issues.apache.org/jira/browse/MYFACES-1225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12563986#action_12563986
]
Paul Pogonyshev commented on MYFACES-1225:
--
Thank you, now I see that
Hi!
This code generation stuff does make code more *consistent* between the
various bits (taglib, faces-config, java) but definitely does not make it
simpler to work with. IMO, it introduces a whole new set of concepts that
will make it harder for new developers to get into this code.
I
[
https://issues.apache.org/jira/browse/TOMAHAWK-1184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12563995#action_12563995
]
gschmidl edited comment on TOMAHAWK-1184 at 1/30/08 4:19 AM:
Hi,
Are there any emails/design-docs available on why the trinidad build system
(now myfaces-faces-plugin) was designed as it was?
Currently, it uses xml configuration files plus java template files to
generate java classes for components. It also then generates java source for
jsp taglib
On Jan 30, 2008 1:39 PM, Simon Kitching [EMAIL PROTECTED] wrote:
Hi,
Are there any emails/design-docs available on why the trinidad build system
(now myfaces-faces-plugin) was designed as it was?
don't think so;
it started as an ant-task, became a maven1 plugin; and now it is a
maven2
Hi Matthias,
yep.
-xml configuration == mini faces-config files
-templates == in order to override some *defaults* (like when you
want to do something special inside the validate() for InputFile,
provide a template, which is a real Java class)
-it generates the real UIComponent java file as
On Jan 30, 2008 1:59 PM, Martin Marinschek [EMAIL PROTECTED] wrote:
Hi Mario,
your second suggestion sounds viable for me - not for the API
components, as those cannot change their inheritance, but for the
tomahawk and MyFaces impl components, this should be doable (and a
very good idea)
Hi Mario,
your second suggestion sounds viable for me - not for the API
components, as those cannot change their inheritance, but for the
tomahawk and MyFaces impl components, this should be doable (and a
very good idea) indeed.
@why Trinidad doesn't work with annotations: how would you then
Hi,
On Jan 30, 2008 1:53 PM, Mario Ivankovits [EMAIL PROTECTED] wrote:
Hi Matthias,
yep.
-xml configuration == mini faces-config files
-templates == in order to override some *defaults* (like when you
want to do something special inside the validate() for InputFile,
provide a template,
[
https://issues.apache.org/jira/browse/TRINIDAD-928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12564010#action_12564010
]
Matthias Weßendorf commented on TRINIDAD-928:
-
trinidad-skin.xml belongs to
Leonardo,
can you investigate into the suggestion by Mario - I think this will
be even better (and easier to achieve) then generating the components
into the source-tree, as the old MyFaces component generator did.
@Everyone: we had a generator once, you remember? It is not in use
anymore cause
Martin Marinschek [EMAIL PROTECTED] schrieb:
Leonardo,
can you investigate into the suggestion by Mario - I think this will
be even better (and easier to achieve) then generating the components
into the source-tree, as the old MyFaces component generator did.
I'm not quite sure what is
Paul Spencer [EMAIL PROTECTED] schrieb:
I am very invested in Tomahawk. I agree we need to simplify things, but
we MUST maintain Tomahawk. If we do not, then who will use ANY of the
MyFaces component libraries if we let libraries die.
Absolutely nobody is suggesting that Tomahawk
I am very invested in Tomahawk. I agree we need to simplify things, but
we MUST maintain Tomahawk. If we do not, then who will use ANY of the
MyFaces component libraries if we let libraries die.
Paul Spencer
Martin Marinschek wrote:
Simon,
is your conclusion then that Tomahawk should
Hi Simon!
First, my intention was/is to find a solution. I don't think that we
manage to create an all new generator stuff. We had plenty of time in
the past to make this thing fly, but failed.
So, while I'd really support your idea about a annotation driven
generator, I don't think that we will
Hi all,
Mario Ivankovits napsal(a):
Hi Simon!
First, my intention was/is to find a solution. I don't think that we
manage to create an all new generator stuff. We had plenty of time in
the past to make this thing fly, but failed.
I was probably last to play with old generator (in Tomahawk
Mario Ivankovits [EMAIL PROTECTED] schrieb:
Hi Simon!
First, my intention was/is to find a solution. I don't think that we
manage to create an all new generator stuff. We had plenty of time in
the past to make this thing fly, but failed.
Only two attempts have been made. And the fact
Hi all,
today i tried to build whole MyFaces 1.1 + Tomahawk after ages.
I started by new SVN checkout (myfaces-current), but something is going
wrong :(
Using JDK 1.4 + Maven2 on Win XP, clean install goals.
Error i got is (in Tomahawk Core project):
[INFO] Using default encoding to copy
Hey All -
It seems to me that the proposed API is a result of two more
fundamental deficiencies:
1. The servlet spec is lame and does not state that ServletContext
implementations must ensure thread-safe access to attributes.
2. ServletContext implementations are lame and have not switched from
Sochor Zdeněk [EMAIL PROTECTED] schrieb:
Hi all,
Sochor Zdeněk napsal(a):
Hi all,
today i tried to build whole MyFaces 1.1 + Tomahawk after ages.
I started by new SVN checkout (myfaces-current), but something is
going wrong :(
Using JDK 1.4 + Maven2 on Win XP, clean install
Hi all,
Sochor Zdeněk napsal(a):
Hi all,
today i tried to build whole MyFaces 1.1 + Tomahawk after ages.
I started by new SVN checkout (myfaces-current), but something is
going wrong :(
Using JDK 1.4 + Maven2 on Win XP, clean install goals.
Error i got is (in Tomahawk Core project):
Hi Matthias -
well, the JCP (true for 99% of the specs) is slow;
and I am sure, the EG will find some reasons to not make changes...
:-)
In that case here is an alternate approach:
1. Keep using the application map.
2. Log bugs against any servlet implementations that are stuck in
Hey Andy,
On Jan 30, 2008 5:20 PM, Andy Schwartz [EMAIL PROTECTED] wrote:
Hi Matthias -
well, the JCP (true for 99% of the specs) is slow;
and I am sure, the EG will find some reasons to not make changes...
:-)
In that case here is an alternate approach:
1. Keep using the application
Java 5.0 method in schedule's renderer
--
Key: TOMAHAWK-1186
URL: https://issues.apache.org/jira/browse/TOMAHAWK-1186
Project: MyFaces Tomahawk
Issue Type: Bug
Components: Schedule
Affects
Andy Schwartz wrote:
Hey All -
It seems to me that the proposed API is a result of two more
fundamental deficiencies:
1. The servlet spec is lame and does not state that ServletContext
implementations must ensure thread-safe access to attributes.
This one I'm not worried about, because I
My thoughts:
1. Release 1.1.7 with moving some of the non-render components from
sandbox (I think the PPR would be better in a new library personally)
2. (Rest are post 1.1.7) move any components that work with any render
kit, and are graphical into a new project (or make this
Build failure when using JDK 1.4
Key: TOMAHAWK-1185
URL: https://issues.apache.org/jira/browse/TOMAHAWK-1185
Project: MyFaces Tomahawk
Issue Type: Bug
Affects Versions: 1.1.7-SNAPSHOT
Hi folks,
I am planing to start the release procedure of Tinidad 1.x.6 during
the next week.
I plan to spent the end of next / the following weekend on it.
Is someone of you planing to provide code, that should make it into
the 1.x.6 release?
Or are the open issues with patches that should make
[
https://issues.apache.org/jira/browse/TOMAHAWK-1186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Mahoney resolved TOMAHAWK-1186.
-
Resolution: Fixed
Fix Version/s: 1.1.7-SNAPSHOT
Fix commited
Java 5.0 method
Martin, the jira issue is here:
https://issues.apache.org/jira/browse/MYFACES-1812
Val
Martin Marinschek wrote:
Can you open an issue in the issue-tracker of MyFaces? I have already
prepared a fix, and will commit it this evening.
regards,
Martin
On 1/30/08, Val Blant [EMAIL
On Jan 30, 2008 7:16 PM, Leonardo Uribe [EMAIL PROTECTED] wrote:
we could add a runtime dependency to commons
and the t:validateEmail tag points to the TAG-CLASS from commons
(no double code )
Yes, This is my intention. For avoid generation on tomahawk I use
These are my thoughts and my personal opinions on the subject
myfaces-faces-plugin generates 4 things:
component classes
tag classes
faces-config.xml
tld
Synchronize the generation of all this stuff with annotations is very
hard!. For each component we need one file. If this file is an
abstract
On Jan 30, 2008 7:18 PM, Leonardo Uribe [EMAIL PROTECTED] wrote:
looks like Tobago and Tomahawk might be interested in
sharing a dojo-based common jar ?
We can use the same as with validators:
component-class-excludedtrue/component-class-excluded
tag-class-excludedtrue/tag-class-excluded
On Jan 30, 2008 8:03 PM, Leonardo Uribe [EMAIL PROTECTED] wrote:
These are my thoughts and my personal opinions on the subject
myfaces-faces-plugin generates 4 things:
component classes
tag classes
faces-config.xml
tld
and facelets taglib
Synchronize the generation of all this stuff
Leonardo Uribe schrieb:
For sure, I thought we can generate the stuff and then commit the
generated files, so no need to regenerate for each build, just when
something in the component config changed.
Yep, this just works nicely if we go the abstract component route, no?
else you'll lose all
To summarize:
The objective is to look if we can generate component, tag,
faces-config and facelets files using
a better approach than the actual behavior of myfaces-faces plugin.
The full idea could be this:
- Create an abstract component class that contains all info.
- Create some files
Don't forget that components are just one of the items generated. It is not
wise to make any architectural changes w/o considering all of the artifacts
the plug-in generates.
On Jan 30, 2008 12:34 PM, Leonardo Uribe [EMAIL PROTECTED] wrote:
To summarize:
The objective is to look if we can
Hi Leonardo,
I am of a contrary opinion to Matthias on the checkin issue - if it
helps the developer, the generated source-code can and should be
checked in. However, it is necessary that the files are re-generated
on every build (so we do not get out of sync between file and
configuration).
I
P.S.: I would not use _both_ annotations and the xml-configuration
file. xml-configuration is enough in this case.
regards,
Martin
Hi,
On Jan 30, 2008 8:46 PM, Martin Marinschek [EMAIL PROTECTED] wrote:
Hi Leonardo,
I am of a contrary opinion to Matthias on the checkin issue - if it
helps the developer, the generated source-code can and should be
checked in. However, it is necessary that the files are re-generated
on
Hi!
1) we do an abstract component base class, very clean, however, it
will not work for MyFaces-AP
I personally think we can go with option 1 only - there are not so
many API classes, and changes in the API are not ocurring too often.
+1
I have no problems if this does not work with the API
On Jan 30, 2008 8:48 PM, Martin Marinschek [EMAIL PROTECTED] wrote:
P.S.: I would not use _both_ annotations and the xml-configuration
file. xml-configuration is enough in this case.
the XML is nice.
It is used to generate the stupid compoents and it transforms the
faces-config,
with tons of
On Jan 30, 2008 2:48 PM, Martin Marinschek [EMAIL PROTECTED] wrote:
P.S.: I would not use _both_ annotations and the xml-configuration
file. xml-configuration is enough in this case.
IMO an annotation that covers all that information makes the class
much much more
un-readable.
XML is not that
1) we do an abstract component base class, very clean, however, it
will not work for MyFaces-AP
I personally think we can go with option 1 only - there are not so
many API classes, and changes in the API are not ocurring too often.
I have tested it in some cases in tomahawk, and works good.
I am with Matthias as whether to checkin in generated files or not. My
personal experience tells that adding generated files under subversion
makes the project more difficult to maintain, because you have to be
even more aware of how the code generation works. For instance, you
have to remove
-1 for a dummy abstract parent class. The resultant OO structure is not
clean. I would rather see a cleaner way to merge the template with the
generated code.
On Jan 30, 2008 1:04 PM, Leonardo Uribe [EMAIL PROTECTED] wrote:
1) we do an abstract component base class, very clean, however, it
And one thing about templates, you only need to deal with exceptions,
right? Most of the components don't need them,
Cheers,
Bruno
On 30/01/2008, Leonardo Uribe [EMAIL PROTECTED] wrote:
1) we do an abstract component base class, very clean, however, it
will not work for MyFaces-AP
I
Hey Blake -
On Jan 30, 2008 11:52 AM, Blake Sullivan [EMAIL PROTECTED] wrote:
This is more of an issue, however the other problem is that the
ServletContext and Session still don't expose the atomic operations of
ConcurrentMap. Neither do they document what object they do lock on.
Without
On Jan 30, 2008 9:06 PM, Bruno Aranda [EMAIL PROTECTED] wrote:
I am with Matthias as whether to checkin in generated files or not. My
personal experience tells that adding generated files under subversion
makes the project more difficult to maintain, because you have to be
even more aware of
Hi Andrew,
On 1/30/08, Andrew Robinson [EMAIL PROTECTED] wrote:
-1 for a dummy abstract parent class. The resultant OO structure is not
clean. I would rather see a cleaner way to merge the template with the
generated code.
ok - then please suggest one. This is all about finding a clean way,
Hi!
ok - then please suggest one. This is all about finding a clean way,
and we are at this point as we haven't found another clean way to do
it so far.
I had a quick chat about this topic with Matthias and I think now I
understood a little bit better what the thought how to work with the
Andy Schwartz wrote:
Hey Blake -
On Jan 30, 2008 11:52 AM, Blake Sullivan [EMAIL PROTECTED] wrote:
This is more of an issue, however the other problem is that the
ServletContext and Session still don't expose the atomic operations of
ConcurrentMap. Neither do they document what object
To make more clear this point about when we should add additional code on
component class, I will take some examples from my experience using
myfaces-faces-plugin for tomahawk. There is some situations where you have
to add custom code like this:
This is the code of
Hey Blake -
On Jan 30, 2008 3:57 PM, Blake Sullivan [EMAIL PROTECTED] wrote:
I believe that we do want to do this, but we can hold off until we have
concrete needs unless the synchronization is actually killing our
performance on the Servlet Container implementations that we need to run on.
[
https://issues.apache.org/jira/browse/PORTLETBRIDGE-19?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Freedman updated PORTLETBRIDGE-19:
--
Resolution: Fixed
Status: Resolved (was: Patch Available)
Leonardo Uribe schrieb:
Not have code completion and other features on the IDE is a low price
for we have with templates.
Not that I would like to veto at this point (which I am not able to do,
for sure), but:
We already gave up some comfort with having the shared stuff. You know,
you can
Andy Schwartz wrote:
Hey Blake -
On Jan 30, 2008 3:57 PM, Blake Sullivan [EMAIL PROTECTED] wrote:
I believe that we do want to do this, but we can hold off until we have
concrete needs unless the synchronization is actually killing our
performance on the Servlet Container implementations
Trinidad view about how to develop components is that if we have some code
that could be in renderer we have to put in the renderer. But the practice
says that there are some situations when we need to write custom code on
component class.
you can override things, by providing a template,
Hey Mario,
On Jan 30, 2008 10:33 PM, Mario Ivankovits [EMAIL PROTECTED] wrote:
Leonardo Uribe schrieb:
Not have code completion and other features on the IDE is a low price
for we have with templates.
Not that I would like to veto at this point (which I am not able to do,
for sure), but:
[
https://issues.apache.org/jira/browse/TRINIDAD-757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12564193#action_12564193
]
Matt Cooper commented on TRINIDAD-757:
--
Note Andrew logged an RI bug against
Sorry that this email is long, but it is a sensitive issue, so please read
on.
https://issues.apache.org/jira/browse/TRINIDAD-757
was reported because the behavior of the code did not match the JavaDoc
description.
Thread: http://tinyurl.com/373smc
At that time, it was decided by others that
My proposal:
To simplify let me use my:foo that should be used to create
MyFooComponent.java. I want to customize the broadcast method of this
component.
One alternative (my choice), as already mentioned is to have the plugin add
code to the class. Instead of using something like:
/* START
On Wed, 2008-01-30 at 16:11 -0500, Leonardo Uribe wrote:
One useful example of why templates are better than abstract classes
is this:
This is the code of
src/main/java-templates/org/apache/myfaces/custom/buffer/BufferTemplate.java
public class Buffer extends UIComponentBase{
{
Hi Simon,
I thnk that so far we all agree that:
* the old approach of files with ==do not edit this bit== sucks. It is
inelegant and people *do* edit that bit.
* having artificial generated parent classes sucks; it distorts the true
hierarchy and simply cannot be applied to the API classes.
FYI, to parse java source, it looks like there are many utils:
http://java-source.net/open-source/parser-generators
On Jan 30, 2008 3:41 PM, Andrew Robinson [EMAIL PROTECTED]
wrote:
My proposal:
To simplify let me use my:foo that should be used to create
MyFooComponent.java. I want to
Hi Andrew,
On Wed, Jan 30, 2008 at 11:41 PM, Andrew Robinson
[EMAIL PROTECTED] wrote:
My proposal:
To simplify let me use my:foo that should be used to create
MyFooComponent.java. I want to customize the broadcast method of this
component.
One alternative (my choice), as already
Here is another:
http://ws.apache.org/jaxme/js/jparser.html
I think you get the drift...
On Jan 30, 2008 4:00 PM, Andrew Robinson [EMAIL PROTECTED]
wrote:
FYI, to parse java source, it looks like there are many utils:
http://java-source.net/open-source/parser-generators
On Jan 30, 2008
Hi Leonardo,
If you want forceId feature works, you need to override getClientId(),and
if you want to use visibleOnUserRole property, you need to override
isRendered(). And also if you want that the component implements some
interfaces you need to specify this on the template.
In this
Ok, I understand.
* generating source into the src/main/java tree sucks, because it is
hard to tell generated code apart from non-generated stuff.
* generating source into the target tree sucks a bit, because you need
to explicitly add it to an IDE
So we agree that the option that sucks less is
[
https://issues.apache.org/jira/browse/MYFACES-1812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12564217#action_12564217
]
Martin Marinschek commented on MYFACES-1812:
I need to add: I'm not sure
[
https://issues.apache.org/jira/browse/MYFACES-1812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Marinschek resolved MYFACES-1812.
Resolution: Fixed
Fix Version/s: 1.2.3-SNAPSHOT
P.S.: can you please test
Hi Leonardo,
* generating source into the src/main/java tree sucks, because it is
hard to tell generated code apart from non-generated stuff.
* generating source into the target tree sucks a bit, because you need
to explicitly add it to an IDE
So we agree that the option that sucks less is
Hello,
I'm just wondering what version of the maven-eclipse- or the
maven-idea-plugin you're using because I've never had problems with the
maven-faces-plugin generating source in the target tree. mvn
eclipse:eclipse or mvn idea:idea configures the project properly at
least for me as I don't
[
https://issues.apache.org/jira/browse/TRINIDAD-880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Graeme Steyn reopened TRINIDAD-880:
---
Please refer to the previous comment. The fix does not work for the sample in
Trinidad
Just had some offline feedback, and would like to revise my proposed change
as I support the feedback.
New proposal:
For every multiple colon prefix:
- If the current component is a naming container, use the parent
naming container
- Otherwise, find the parent of the current NC
Hello,
On 01/31/2008 +0100,
Martin Marinschek [EMAIL PROTECTED] wrote:
Hi Bernhard,
On Thu, Jan 31, 2008 at 12:54 AM, Bernhard Huemer
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote:
Hello,
I'm just wondering what version of the maven-eclipse- or the
maven-idea-plugin you're
[
https://issues.apache.org/jira/browse/TRINIDAD-918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sandy Schaffner updated TRINIDAD-918:
-
Status: Patch Available (was: Open)
Create an oracle skin in Trinidad that looks
1 - 100 of 119 matches
Mail list logo
