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
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 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
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.
, and call putIfAbsent without locking the app map
Gab
Blake Sullivan wrote:
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
Gang -
I am hoping to pick this up where Matt left off and see if I can
provide a solution. There are two problems that I am hoping to
address:
1. High contrast content: Skin styles or icons may need to be tweaked
for users who require high contrast-friendly content. In some cases
it may also
On Thu, Feb 14, 2008 at 3:24 PM, Jeanne Waldman
[EMAIL PROTECTED] wrote:
This sounds good.
I prefer accessibility-profile rather than user-profile because that
sounds too generic.
Sure, I'll go with accessibility rather than user unless I hear
any strong objections.
In this example:
Gang -
As part of the fix for TRINIDAD-822, I am proposing to add a new
getAccessibilityProfile() API to RequestContext (and now that I think
about it, to RenderingContext as well). Both RequestContext and
RenderingContext are abstract. In order to avoid breaking any
existing implementations
Thanks Matthias. Just wanted to make sure people were cool with this
approach. If anyone has concerns, please let us know.
Andy
Hey Scott -
On Feb 19, 2008 2:11 PM, Scott O'Bryan [EMAIL PROTECTED] wrote:
Hey Andy, why does RequestContext need this method? Is this something
that's will change on a per-request basis?
The plan is for the accessibility profile to be a sibling to the
existing RequestContext accessibility
Hi Andrew -
Thanks for bringing this over to email...
On Wed, Feb 20, 2008 at 11:31 AM, Andrew Robinson
[EMAIL PROTECTED] wrote:
I still think that a custom DOCTYPE should be provided. With XHTML, to
be completely specification compliant, the HTML page ought to pass DTD
validation. This
Hi -
The behavior that you describe is coming from an optimization in
Trinidad's HtmlResponseWriter, which detects and strips attribute-less
span elements. I believe this optimization dates back to Oracle UIX.
IIRC in certain scenarios we were ending up with multiple nested
attribute-less spans
Hey Gab, Jon -
On 3/10/08, Gabrielle Crawford [EMAIL PROTECTED] wrote:
However these kind of style rules are unreliable. Our html is an
implementation detail, and can change, meaning it could be a span today,
a div tomorrow
Good point... My interpretation of Jon's concern is that the
Hey All -
The concern with exposing a public component-level tabIndex attribute
has always been that this opens up the potential for way more problems
than it solves. The problem with HTML tabIndex attribute is that once
you set one positive tabIndex value, in order to ensure that the tab
So if I have a log in form, the tab indexes would probably be:
user name: 1
password: 2
submit: 3
And then everything else would not have one. This way all the
template components would be tabbed, just not first.
In this particular use case it sounds like you actually like the
Blake, Andrew -
I preferred to wait until we had a good set
of concrete focus management use cases.
This was my main question after reading the Andrew's wiki page - I
want to be sure to understand the use cases that we are trying to
address before moving forward with a solution. Many use
Gang -
Just a heads up that I finally managed to get around to submitting a
patch for TRINIDAD-822. The solution is pretty much along the lines
that we discussed in this email thread. I did decide to go with enum
properties on the AccessibilityProfile API rather than booleans,
though I cheated
Hey Matthias, Andrew -
On Sun, Apr 6, 2008 at 7:07 AM, Matthias Wessendorf [EMAIL PROTECTED] wrote:
On Sun, Apr 6, 2008 at 12:05 AM, Andrew Robinson
[EMAIL PROTECTED] wrote:
When doing the panelBorderLayout enhancement, I had my first real
opportunity to work on those xss files. I can't
BTW, I didn't see any open Trinidad issues relating to this, so I
decided to go ahead and log a few new issues to track some of the work
that needs to be done. See:
TRINIDAD-1041 Support locale-specific styles
TRINIDAD-1042 Support (browser) version-specific styles
TRINIDAD-1043 Convert legacy
Hi Cristi
On Sun, Apr 6, 2008 at 3:09 PM, Cristi Toth [EMAIL PROTECTED] wrote:
Hi,
The issue TRINIDAD-1042 duplicates TRINIDAD-799 (which is not assigned to
skinning, but to components)
Ah, okay, thanks. I only scanned the skinning issues - didn't see 799.
Andrew originally had these
On Thu, Apr 10, 2008 at 1:36 PM, Andrew Robinson
[EMAIL PROTECTED] wrote:
+1 for:
- removing most final modifiers
- going from private to protected on most renderer methods
Not sure how much my opinion counts, since I am a new face around
here, but I am -1 on blindly removing most final
Hi Andrew -
On Thu, Apr 10, 2008 at 4:36 PM, Andrew Robinson
[EMAIL PROTECTED] wrote:
I wasn't suggesting blind removal.
Okay. The use of the word most gave me that impression. :-)
IMO final should rarely ever be used, for open source it almost never does
anyone any good.
Final should be
Hey Martin (and all) -
It seems to me that what this comes down to is how we view classes in
trinidadinternal. There are a range of possible views here:
1. These classes are entirely private/off-limits, and if you want to
extend one of these tough luck. No love for you. Go away.
2. These
Hey Andrew -
I think we are getting closer together, but not exactly there yet. :-)
On Fri, Apr 11, 2008 at 10:10 AM, Andrew Robinson
[EMAIL PROTECTED] wrote:
As someone who has experience in attempting to use Trinidad, I think
#3 is a requirement for short term usage and #2 as the goal.
I
On Mon, Apr 14, 2008 at 5:56 PM, Blake Sullivan
[EMAIL PROTECTED] wrote:
In English, it is usually ivory tower, but, if you think that I'm evil,
ebony tower might be more approriate.
Blake == Saruman?
;-)
Andy
On Thu, Apr 17, 2008 at 11:00 AM, Andrew Robinson
[EMAIL PROTECTED] wrote:
I would like to have:
1) Major and Major.Minor support
2) A syntax that is already supported by CSS @ styles in at least one
browser or as close as we can come
3) Range, greater than and less than if possible
On Thu, Apr 17, 2008 at 9:21 PM, Andrew Robinson
[EMAIL PROTECTED] wrote:
I'll be happy either way, but I think I now bend to the below
explanation of 5 == 5.0 from Jeanne's reasoning
FWIW, I actually agree with Jeanne's first opinion. :-)
That is, I think of 5 as 5.*. 5.0 as 5.0.*, etc.
On Fri, Apr 18, 2008 at 6:15 PM, Blake Sullivan
[EMAIL PROTECTED] wrote:
OK, how about
option 5)
I like option 5.
Andy
Folks -
I would like to enhance Trinidad's Agent mechanism to
recognize/support iPhone user agents. We've got a couple of options
for how to surface the iPhone agent, so wanted to run this by the
community.
1. Add a pda type for webkit.
Currently, desktop Safari is identified as follows:
Thanks All!
I have logged the following issue to track this requirement:
https://issues.apache.org/jira/browse/TRINIDAD-1232
And have provided a patch.
BTW, I decided to go with PLATFORM_IPHONE/OS_IPHONE rather than
PLATFORM_IPHONEOS/OS_IPHONEOS.
Andy
On Sun, Sep 14, 2008 at 3:48 PM, Stephen Friedrich
[EMAIL PROTECTED] wrote:
My understanding is that if CACHE_VIEW_ROOT, then the complete tree of
components is directly (without converting to byte[], serialization or
such)
in the session.
Just wanted to note that the cached view root is
Gang -
As discussed in the following issue:
http://issues.apache.org/jira/browse/TRINIDAD-1488
I need the ability to apply ChangeManager component changes to a
specific component subtree (within a NamingContainer) as opposed to
the entire view. The goal is to be able to apply ChangeManager
Quick follow up...
I have been going back and forth between UIComponent and
NamingContainer for the type for the root parameter. After
discussing this offline with Blake, I believe that specifying
NamingContainer is the better way to go. This makes the contract more
explicit and allows us to
Hey Matthias -
I like org.apache.myfaces.trinidad.
Just out of curiosity I sent email to the EG to see what other folks
have done. I don't think we need to wait for that info, but I will
pass along any responses.
Andy
Thanks for logging the spec issue Matthias. I agree that this was
just overlooked in the spec. Should be easy to correct next time
around.
Andy
,
Andy
-- Forwarded message --
From: Andy Schwartz andy.g.schwa...@gmail.com
Date: Wed, Jan 13, 2010 at 10:25 AM
Subject: FaceletViewHandlingStrategy: cloneWithWriter() results in
duplicate ResponseWriters
To: d...@javaserverfaces.dev.java.net
Gang -
While looking into Trinidad
Hey, great, thanks for looking at this Leonardo!
Note that it is possible that this does not impact the
Ajax/PartialResponseWriter case, since that might use a different code
path for response writer creation. Might want to take a closer look
at the renderView() implementations in:
-
Just wanted to mention that I have logged this issue here:
https://issues.apache.org/jira/browse/MYFACES-2500
Issue 2500. Pretty cool! :-)
Andy
A few more updates on this:
- I have uploaded a proposed fix to MYFACES-2500.
- I have checked in the corresponding fix to Mojarra.
- I have logged TRINIDAD-1709 to track some Trinidad clean up that we
can do once we've got the fix available in both MyFaces and Mojarra.
Andy
Hi Werner -
On Fri, Feb 12, 2010 at 2:28 AM, Werner Punz werner.p...@gmail.com wrote:
Werner Punz schrieb:
Ok I shot over the top a little bit early, the problem with file input is
that you cannot cover it within the bounds of XHR at all you have to revert
to an iframe transport.
Yep. I
One thing that is interesting about this that Matthias didn't mention
is that the problem only repros when running against MyFaces - ie.
same test case works okay when using -Djsf=ri. I haven't had time to
investigate yet, but will try to do so if Max or Andrew (who are
actively working on the
Leonardo -
Thanks for this detailed analysis - lots of good information here.
I've been meaning to follow up on this for some time now. Better late
than never I guess. :-)
My thoughts inline below...
On 3/17/10 9:10 PM, Leonardo Uribe wrote:
Actually the event publishing conditions of
Hey Leonardo -
Thanks for giving this a go and for sharing your findings! I am still
hopeful that we can make something along these lines work. I will try
to take a look at your patch to see if I have any ideas. (Though have
other things I need to take care of first - so may be a few days
On 5/22/10 9:36 PM, Leonardo Uribe wrote:
Hi
After some attempts I was able to make it work ( see
MYFACES-2638-6_5.patch ).
Great!
I think I'll delay a little bit myfaces core 2.0.1 release, because
this solution has enought importance to be included. Definitively, the
way to go is use
Gang -
I attempted to send this earlier today from my work account but it
didn't seem to make it through. Re-sending from gmail (with one minor
correction). Hopefully I'll have better luck this time. :-)
(Apologies if we end up with multiple copies of this...)
On 5/26/10 1:27 AM, Martin
On 5/26/10 12:49 PM, Andy Schwartz wrote:
Unless someone understands why the implementation is inconsistent
across these two cases, I think that we should align the
implementations. Note that given the bug that Max logged (against
Mojarra):
https://javaserverfaces.dev.java.net/issues
On 5/26/10 1:27 AM, Martin Marinschek wrote:
Hi Andy,
my 2cents (isn´t worth much in this discussion if I don´t look any
deeper into this ;)
Given that ui:decorate is a non-trimming ui:composition, why would these
behave differently with respect to interaction with the TemplateClient? I
Hey Kito -
On Tue, Jul 13, 2010 at 12:30 PM, Kito Mann kito.m...@virtua.com wrote:
Keep in mind that whatever workarounds are required for Shale Test will
likely be required for MyFaces Test as well,
In this particular case, MyFaces Test already has the workaround. We
are running into
Gang -
Blake implemented client id caching back in March (r921628 on
trinidad-1.2.x). However, this behavior was intentionally left
disabled by default in order to allow testing to occur before we turn
this on. I would like to propose that we now enable this
functionality by default. This
On Wed, Aug 11, 2010 at 8:50 AM, Matthias Wessendorf mat...@apache.org wrote:
small comment. For the JSF2 version, should we log a warning in case the
ProjectStage is PRODUCTION, but the CLIENT_ID_CACHING prop is OFF/DEBUG ?
Nice idea Matthias! I'll fix up my patch to include this.
Andy
New version of the patch uploaded here:
https://issues.apache.org/jira/secure/attachment/12451819/trinidad-1669-take2.patch
Includes Matthias' suggestion of logging a warning when client id
caching is disabled in production mode.
Andy
Any other comments/concerns? If not, is there anything else that
needs to happen process-wise before moving forward on with this
change?
Andy
Great, thanks Matthias!
Andy
On Wed, Aug 25, 2010 at 11:10 AM, Jakob Korherr jakob.korh...@gmail.com wrote:
If it is an implementation problem and can be circumvent in any way, I would
contact the Glassfish and Tomcat developers about this ;)
+1. I pinged Kin-man as a heads up on this...
Andy
Gang -
Kin-man opened the following issue to track this on the GF/UEL side:
https://uel.dev.java.net/issues/show_bug.cgi?id=19
Andy
Not sure how much weight my non-committer vote holds, but +1 from me. :-)
BTW, I noticed that there is an older, unrelated 2.0.0-beta-1 branch
from last year:
http://svn.apache.org/repos/asf/myfaces/trinidad/branches/2.0.0-beta-1
Does this branch contain any meaningful history? If not,
Gang -
Recently I have spent some time testing ADF Faces (and Trinidad)
against MyFaces trunk with the goal of certifying that ADF Faces works
well when running on top of MyFaces 2.0. (Up till now our 2.0 testing
has been focused on Mojarra.) As part of my MyFaces testing I have
found a small
Hi Martin -
I was worried about this case as well when we were working on the
Ajax/ClientBehavior APIs. Many Trinidad/ADF Faces components use
similar markup to what you describe.
To support this case, we added the ClientBehaviorContext.getSourceId() API:
On Wed, Jan 19, 2011 at 8:49 AM, Matthias Wessendorf mat...@apache.org wrote:
Your input is always appreciated
Great, thanks Matthias!
Discussing stuff (like how to solve the items) should be done on this
list (dev@).
Sounds good.
In case that input of the EG is required, just post the
Completely agree with Jakob's comments and wanted to add one
suggestion. The best way to identify other similar problems would be
to re-compile against the jsf-api.jar only (not jsf-impl.jar). Better
yet, if you tweak your build along these lines, you'll avoid the risk
of introducing accidental
On Fri, Jan 28, 2011 at 4:08 PM, MAX STARETS max.star...@oracle.com wrote:
I just submitted a fix, so barring any new issues we do not have to require
that partial state saving be disabled.
Awesome, thanks for fixing this Max!
Wanted to mention that I suspect that we may have some more subtle
Woohoo! Thanks all for the vote of confidence. I am honored to be
part of the Apache MyFaces community!
(Having some issues with getting my first commit in. Will see if I
have better luck from home. If not, will follow up with infra folks.)
Andy
Thanks again all!
BTW, finally managed to get my first commit in:
http://svn.apache.org/viewvc?view=revisionrevision=1066976
Looking forward to more interesting contributions in the future. :-)
Andy
Gang -
Back in June of last year on the jsr-314-open mailing list, there was
discussion on the need for a tree visit hint to indicate that
iterating components (like UIData) should not iterate during the
visit. At that point it was too late to add a new VisitHint enum
value to the 2.0.x
Decided to break this up into 2 issues:
MYFACES-3036 Support SKIP_ITERATION FacesContext property
MYFACES-3037 Children of iterating components receive multiple
PostRestoreStateEvents
A solution for the first issue would make fixing the second issue very easy.
Andy
On Tue, Feb 8, 2011 at 4:28 PM, Martin Marinschek
mmarinsc...@apache.org wrote:
certainly needs to be fixed on this side of the fence as well ;)
Looks like Leonardo has already checked in fixes for both of my
issues. That was fast. :-)
Thanks Leonardo!
Andy
Gang -
I was somewhat hoping to get a fix in for this issue soon:
https://issues.apache.org/jira/browse/TRINIDAD-2030
Unfortunately, I am out of the office today/tomorrow. Any chance we
can hold off on firing up the release just a bit to give me a chance
to get this in?
Andy
I have uploaded a patch for TRINIDAD-2030. If nobody objects, I would
like to include this fix in the proposed beta release.
Andy
Wanted to add my congratulations, as I sit here while my wife attempts
to put a very fussy 5 month old down for the night. :-) Best wishes
Werner!
Andy
On Sun, Feb 13, 2011 at 9:46 PM, Scott O'Bryan darkar...@gmail.com wrote:
We're waiting for you Andy.. :D
Woops. Sorry!
what's the JIRA #?
https://issues.apache.org/jira/browse/TRINIDAD-2030
Also, are your committer rights all set up? If so, go ahead and test
and commit. If not, then
Scott, Jan-Kees -
Thanks for the pointers! Was able to commit after switching over to
https (d'oh!):
http://svn.apache.org/viewvc?view=revisionrevision=1070523
Andy
Gang -
I would like to add a new base class for ChangeManager wrapper classes
to extend as discussed here:
https://issues.apache.org/jira/browse/TRINIDAD-2055
I have attached an implementation to the issue:
https://issues.apache.org/jira/secure/attachment/12473198/ChangeManagerWrapper.java
Hi Prakash -
On Wed, Mar 9, 2011 at 6:56 PM, Prakash Udupa prakash.ud...@oracle.com wrote:
How does the wrapper help any more?.
Let's take a closer look at the use case that I am hoping to address...
I want to write a ChangeManager implementation that:
1. Delegates all of the real work to
Thanks for the review Pavitra. I too was debating whether to follow
the FacesWrapper approach. In the end I leaned towards keeping the
get*Wrapper method protected, since I couldn't think of any non-hacky
reason for exposing this publicly.
On Wed, Mar 9, 2011 at 6:13 PM, Blake Sullivan
Gang -
I would like to add a utility method for locating the nearest
non-flattening ancestor component, as discussed here:
https://issues.apache.org/jira/browse/TRINIDAD-2056
And shown in this patch:
https://issues.apache.org/jira/secure/attachment/12473314/trinidad-2056.patch
Any comments?
I am thinking that I will roll with my current approach since we can
always transparently implement FacesWrapper later if we decide that
this is an important thing to do. If anyone thinks that it is
important to do this now, please let me know!
Thanks,
Andy
Hi Bernd -
I am a bit hesitant about the names as well. Three possible options:
1. completeNoopResponse()/completeScriptResponse()/completeRedirectResponse().
2. renderNoopResponse()/renderScriptResponse()/renderRedirectResponse().
3.
Btw - another variant would be to drop the Response suffix from the method
names.
Andy
On Mar 13, 2011, at 10:48 AM, Andy Schwartz andy.g.schwa...@gmail.com wrote:
Hi Bernd -
I am a bit hesitant about the names as well. Three possible options:
1. completeNoopResponse
Hi Yuan -
On Mon, Mar 14, 2011 at 3:10 AM, Yuan Gao yuan@oracle.com wrote:
I like your comments. As for the names, how about
renderNoopAndCompleteResponse()?
That's definitely the clearest of the names that we have discussed. :-)
If we go with render, I can see three options:
1.
+1. Thanks for putting this together Scott!
Andy
Gang -
Looking back at the EG emails, I realize now that I dropped the ball
on making sure that my proposed changes actually made it into the
spec.
Here was my original email (Metadata complete jar files) from
Septeber 3, 2009:
Gang -
Section 11.5.1 of the spec defines the following
On Thu, Mar 24, 2011 at 6:06 PM, Leonardo Uribe lu4...@gmail.com wrote:
I have created these issues:
http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-952
Thank you Leonardo!
Although we are in between JSRs now, I sent mail to the old
jsr-314-open list to see whether we can address this
Just wanted to send a heads up that I've got some tree visiting
related issues that I would like to get into the next release as well:
TRINIDAD-2078 SKIP_ITERATION forces visit of non-rendered components
TRINIDAD-2081 UIXShowOne SKIP_UNRENDERED implementation does not match
renderer logic
And,
Thanks Blake, looks good. I have committed the latest version of your patch.
Andy
I think it is time to propose a new axiom relating to boolean
properties. I would name it after Blake, who first called this truth
to my attention:
Blake's Axiom of Boolean Properties: You will regret making your
property a boolean.
:-)
In this particular case, I am thinking about the UIData
Gang -
Earlier today Jason Lee noticed ran into problems with the Trinidad
component showcase demo. The demo comes up, but the Browse
Components accordion is non-functional. Interestingly, the
standalone tr:panelAccordion demo under trinidad-demo works okay.
Wanted to ping the list to see
Logged the following issue to track this:
https://issues.apache.org/jira/browse/TRINIDAD-2129
Andy
Hey Scott -
It is not marked as a blocker, though think it would be good to take a
look at this one before we release:
https://issues.apache.org/jira/browse/TRINIDAD-2129
Andy
On Tue, Aug 16, 2011 at 5:44 PM, Scott O'Bryan darkar...@gmail.com wrote:
Awesome Max.. Thanks for the quick turn around.
+1. Thanks Max!
Andy
Gang -
I would like to backport my fix for this Trinidad issue:
https://issues.apache.org/jira/browse/TRINIDAD-2130
To Trinidad 1.2.x.
One minor hiccup: my patch uses the
ExternalContext.getRequestScheme() API, which was introduced in JSF
2.0.
To abstract away this dependency, I would like
On Tue, Sep 27, 2011 at 4:42 PM, Scott O'Bryan darkar...@gmail.com wrote:
I like it...
Great, thanks for the review Scott!
For backward compatibility we'll want this implemented
in 2.0 as well but it can just call the native function under the
covers...
Yep. I'll take care of that as
Gang -
I recently got wind of the following web framework performance talk
that was presented at JavaOne:
https://oracleus.wingateweb.com/published/oracleus2011/sessions/24122/S24122_234496.pdf
I did not attend, but based on the slides it looks like the presenters
did an very
Gang -
For this newly logged issue:
TRINIDAD-2215 String - Accessibility enum API
https://issues.apache.org/jira/browse/TRINIDAD-2215
I would like to add a new valueOfAlias() method to
RequestContext.Accessibility, as shown here:
Thanks for the comments guys.
On Mon, Feb 13, 2012 at 11:51 PM, Blake Sullivan
blake.sulli...@oracle.com wrote:
Overloaded how?
The other question is that we want to be able to go from the
displayName-Enum
Actually, this is the only question. :-)
We've already got an accessor - the
On Tue, Feb 14, 2012 at 11:33 AM, Blake Sullivan
blake.sulli...@oracle.com wrote:
I would go with valueOfDisplayName(). I would actually add a displayName()
as well, just like we have name().
Sounds good, will do.
I am not a fan of assuming that
toString() == displayName()
Er... two
On Tue, Feb 14, 2012 at 12:57 PM, Blake Sullivan
blake.sulli...@oracle.com wrote:
It is actually the second of these, so everything is good.
Yep. If it were the first, I wouldn't need my bonus valueOfx method.
In any case, new version of the patch uploaded here:
On Tue, Feb 14, 2012 at 12:51 PM, Blake Sullivan
blake.sulli...@oracle.com wrote:
I prefer #1. If the caller really cares about what she gets, she can call
the explicit method.
Sounds reasonable. Will leave toString() behavior undocumented.
Andy
+1
Andy
On Feb 22, 2012, at 12:18 AM, Scott O'Bryan darkar...@gmail.com wrote:
Hi Everyone,
I was running the tasks needed to get the Trinidad 2.0.1 release out and now
I need a vote as to whether everything looks good or not. I have committed
most of the most recent submitted patches
+1.
Thanks for putting this together Scott.
Andy
On Feb 24, 2012, at 12:30 PM, Scott O'Bryan darkar...@gmail.com wrote:
Hi Everyone,
I was running the tasks needed to get the Trinidad 2.0.1 release out and now
I need a vote as to whether everything looks good or not. I have committed
Any thoughts on why we are seeing this failure? The cause seems to be
a missing pom:
org.sonatype.aether.transfer.ArtifactNotFoundException: Could not find
artifact org.apache.myfaces.trinidadbuild:maven-xrts-plugin:pom:2.0.8-SNAPSHOT
Though I see the pom here:
1 - 100 of 268 matches
Mail list logo
