date:20061121

Re: Releasing Tiles (was: Re: [s2] 2.0.2 release this weekend)

2006-11-21 Thread Martin Cooper

On 11/21/06, David H. DeWolf <[EMAIL PROTECTED]> wrote:

Wendy Smoak wrote:
> On 11/20/06, David H. DeWolf <[EMAIL PROTECTED]> wrote:
>> How about getting an initial tiles release out so that the 2.0.2 tiles
>> plugin can rely upon it instead of a snapshot? It would probably only
be
>> 'alpha' quality at this point, but the same snapshot logic that you
>> described below applies to it.
>>
>> I'll do the release (prior to the weekend), if someone that's done one
>> before will help me through it.
>
> Tiles 2 is in the sandbox, and sandbox projects are not allowed to do
> releases.  Choosing a particular snapshot for Struts 2 to depend on is
> all we can do, unless we change the rules.

Ok, thanks for clarifying.

>
> If Tiles is ready to graduate, then we need to decide where it's going
> to live.  Top level?  Over at Jakarta, or wasn't there some sort of
> 'web components' project being started?
>

Are these the only two options?  My fear with both of them (a top level
project or the 'seed' project for a new web components project at
jakarta) would be lack of community due to the fact that there seem to
be just a few active committers interested in tiles right now.  Jakarta
would be an option, though their recent trend seems to be graduating
projects to TLP - not accepting new projects.

Is it possible for tiles2 to 'graduate' into a full struts project
(sibling of struts1 and struts2) until it gains a little more momentum?
  The idea would be to allow tiles to leverage the
participation/oversight   that's allready here?  This seems to make
sense since I would guess that the vast majority of tiles users are
using it in conjunction with one version of struts or another.

I actually think this would make a great deal of sense as an interim step
for Tiles. While the long term goal would be for Tiles to move away from
home and find its own place to live, letting it spend its adolescence here
seems appropriate. ;-) It does seem a little drastic to say that the choice
is to stay in the sandbox or leave entirely.

Also, what warrants graduation from the sandbox?  A we assuming the same

requirements as graduating a project from the incubator?  My assessment
at this point is that tiles has come a long way and is ready to be
pushed out to the masses in order to allow them to play.  I'd like to
'release early/release often'.

Well, we don't have a process as formal as that of the Incubator, but I
suppose along the same general lines. A demonstration of activity and
community is sufficient, and I believe Tiles has done that. Really, the
sandbox has been used to "contain" projects that might not go anywhere, and
Tiles is well beyond that now. So, I'd say graduating makes sense.

--
Martin Cooper

Thoughts?

David

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [tiles2] Usefulness of entity resolver in DigesterDefinitionsReader

2006-11-21 Thread Antonio Petrelli


Hi David!

David H. DeWolf ha scritto:

Which registrations are you referring to?


In DigesterDefinitionsReader there is the "registrations" field 
(currenly it contains only one registration), used to initialize the 
digester in the constructor.


I was on the road - without a connection - this weekend and was unable 
to successfully startup the tiles-test app without it (IOException, 
connection refused to struts.apache.org), so I'm assuming the answer 
is no.  That said, I saw that you upgraded the dtd's to 2.0 this 
weekend, so perhaps you did something in that commit that I missed 
that would have taken care of this problem.


You're right, some configuration files still referred to 1.1 version of 
the DTD, so I modified them all, reopening (and re-resolving) SB-30 
issue. Probably you got this problem because JUnit tests failed, and 
therefore the package wasn't built.


To test if the registrations are enough, I disconnected the network 
cable (ehm... don't try this at home :-) ) and it worked.


Ciao
Antonio


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Proposal] Struts 2 Result Selectors

2006-11-21 Thread Ted Husted


OK, do you remember how the WW-1393 feature works, or where we test it?

-Ted.

On 11/21/06, Don Brown <[EMAIL PROTECTED]> wrote:

Nope, that's something different.  Perhaps I didn't open up a ticket on
that, and just referred the commit to the struts one.

Don

Ted Husted wrote:
> Would it be XW-440?
>
> * http://jira.opensymphony.com/browse/XW-440
>
> -T.
>
> On 11/21/06, Don Brown <[EMAIL PROTECTED]> wrote:
>> I'd say result selectors and WW-1393 are different.  WW-1393 has been
>> implemented, but result selectors have not, AFAIK.  I don't remember the
>> XWork ticket, off-hand, but the change involved DefaultActionInvocation
>> I believe.
>>
>> Don
>>
>> Ted Husted wrote:
>> > Is "Result Selectors" what was covered by WW-1393?
>> >
>> > * http://issues.apache.org/struts/browse/WW-1393
>> >
>> > Or, was that a different feature?
>> >
>> > Our WW-1393 says it was handled on the XWork end, but doesn't cite a
>> > ticket. I don't know what we actually did.
>> >
>> > Did we
>> >
>> > * Implement result selectors?
>> >
>> > * Implement " Returning Result directly"?
>> >
>> > Or, are they the same thing?
>> >
>> > -Ted.
>> >
>> > On 10/30/06, Don Brown <[EMAIL PROTECTED]> wrote:
>> >> I really, really, like this idea, especially since it doesn't
>> introduce
>> >> any new syntax or complications for the 90% of users that don't need
>> >> this.  The more we can keep Struts/XWork to simple, internal
>> components,
>> >> the easier it will be to worth with both as a user and as a
>> developer.
>> >>
>> >> This would make a nice plugin with default result types for common
>> >> situations.
>> >>
>> >> Don
>> >>
>> >> Ted Husted wrote:
>> >> > On 10/26/06, Don Brown <[EMAIL PROTECTED]> wrote:
>> >> >> Then, each result selector is given a chance to select a single
>> >> String.
>> >> >> If a result has when="modern-browser,partial-html",
>> >> >> the each selector will be given a chance to return its "when"
>> >> token, and
>> >> >> xwork will match them together as AND.
>> >> >
>> >> > Or, with wildcards ...
>> >> >
>> >> >  
>> >> > 
>> >> > 
>> >> >
>> >> >
>> >> >> type="selector">/{1}{result-code}{role}{agent}.jsp
>> >> >
>> >> >/{1}-error.jsp
>> >> >
>> >> > 
>> >> >
>> >> > Each "matcher" could add a named token into the context, like
>> >> > "-manager". The selector result could then resolve the wildcard
>> path
>> >> > and delegate to another Result, like the default ServletDispatcher
>> >> > Result. The matchers might not inject a token, if it was the
>> default
>> >> > or didn't apply for some reason.
>> >> >
>> >> > So, an application using this strategy might have pages named like.
>> >> >
>> >> > * ViewFoo.jsp
>> >> > * ViewFoo-netscape4.jsp
>> >> > * ViewFoo-manager.jsp
>> >> > * ViewFoo-manager-netscape4.jsp
>> >> > * ViewFoo-failure.jsp
>> >> >
>> >> > Of course, this strategy presupposes using something like
>> SiteMesh or
>> >> > Tiles to provide the standard layout, so that each "page" can just
>> >> > focus on it's own content.
>> >> >
>> >> > -T.
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
HTH, Ted.
* http://www.husted.com/struts/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [s2] 2.0.2 release this weekend

2006-11-21 Thread Ted Husted

On 11/21/06, Alexandru Popescu <[EMAIL PROTECTED]> wrote:

Don, I agree with you that a release should be scheduled sometime very
soon. However, at this moment due to the latest changes I would
suggest the following process:

1/ tag all dependencies (XWork2, Tiles2, Guice, CodeBehind etc.)

I'd agree that a stable release of XWork2 is key. If the not for the
dependency on a XWork beta, we might be voting Struts 2.01 GA right
now, and wonderng whether to declare the HEAD Struts 2.1 :)

We should keep in mind that we only announced the Struts 2.0.1 beta
two weeks ago. AFAIK,  there are no major issues witth the 2.0.1 beta,
and we should continue to encourage the general public to review the
2.0.1 beta.

The people working on Tiles2 are gearing up for some sort of release,
maybe even this weekend. But, since we distribute Tiles as a plugin,
so we could still mark Core GA and leave the Tiles plugin at beta.
Right now, all the plugins, including Tiles2 and Codebehind, are
tagged and released along with Core.

The Guide code was imported into XWork as the "inject" package, so
Guice is not a yet-another dependency. (Yeah!)

2/ make a release of the external dependencies (XWork2, Tiles2, Guice)

+1 as to XWork (not that I have an XWork vote). Tiles 2 might be
happening anyway. As mentioned, Guice is not applicable.

3/ document the new things

Actually, the newest things are documented (thanks Don!). :)

The problem is that, as PMC member, I don't know whether the new
features have been deployed outside of our test applications.

Even in our own applications, we haven't fully leveraged the "new
things" yet, or even all the changes to "old things -- though I'm
working in that direction, and I'll continue to update the release
notes as I go.

4/ make an alpha to be tested/played with at least the committers

It would be helpful if committers, and other members of the dev@
community, would test and play with the HEAD. If we have a problem
with dev@ subscribers not being able to build the HEAD, we need to
address that problem directly.

What works best for me is to update and build XWork2 first (from the
command line), and then do the same for Struts2. (Again, from the
command line.) It takes a moment, but it eliminates more surprises,
and there's always other stuff to do in another window (like this!).

5/ only after these push a beta/ga

Before voting something a beta or GA, I believe it's important that
the PMC members be using the build in our own work. We should be at
least one step ahead of the general public. When we vote a build GA,
it should be because we are already using it in production ourselves,
so we *know* it works. IMHO, the time to talk about voting a build
beta or GA is when we ourselves have already deployed the bits, and
our own users have found them joyful.

-Ted.

How does this sound to you?

./alex
--
.w( the_mindstorm )p.

On 11/21/06, Ted Husted <[EMAIL PROTECTED]> wrote:
> My best vote right now would be Alpha.
>
> I'm trying to get up to speed with all the recent changes, but I
> wouldn't want to put something out there for other people to use until
> I"ve actually used it myself.
>
> -Ted.
>
>
> On 11/20/06, Don Brown <[EMAIL PROTECTED]> wrote:
> > We really, really, really need to get a release out there, even if was
> > determined to be beta.  The snapshot system is unpredictable and
> > confusing for potential users, and really, users shouldn't be using them
> > anyways as they aren't "official" struts releases.
> >
> > Any showstoppers to a likely beta release?
> >
> > Don
> >
> > PS. I just deployed the snapshots off trunk to maven
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

--
HTH, Ted.
* http://www.husted.com/struts/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [s2] IDEA - JFreeChart Dependencies

2006-11-21 Thread Ted Husted

On 11/21/06, Ted Husted <[EMAIL PROTECTED]> wrote:

On 11/21/06, Rahul Akolkar <[EMAIL PROTECTED]> wrote:
> The dependency s for jfree groupId dependencies seem to be off here:
>
> 
http://svn.apache.org/repos/asf/struts/struts2/trunk/plugins/jfreechart/pom.xml
>
> -Rahul

Yes, that's seems to be the culprit. Sharp eye, as always, Rahul.

Fixed in r477875

Incidentally, you can change the JFreeChart folder and run mvn
idea:idea from there, to just rebuild the JFreeChart IDEA module.

It used to be that we had to add -Doverwrite=true for it to replace
the IDEA project, but lately it seems to be replacing everything, even
without the overwrite setting.

-Ted.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [s2] IDEA - JFreeChart Dependencies

2006-11-21 Thread Rene Gielen


Rahul,

this was it, yes :)
Fixed now, see
https://issues.apache.org/struts/browse/WW-1518

Regards,
Rene

Rahul Akolkar schrieb:

On 11/21/06, Rene Gielen <[EMAIL PROTECTED]> wrote:

Hmm, just had a closer look into the output of
$ mvn idea:idea -P all
Looks like there's the problem...




[WARNING] An error occurred during dependency resolution of the
following artifact:

 org.apache.struts:struts2-jfreechart-plugin2.0.2-SNAPSHOT

Caused by: Missing:
--
1) jfree:jfreechart:jar:[1.0.0,)

   Try downloading the file manually from the project website.

   Then, install it using the command:
   mvn install:install-file -DgroupId=jfree -DartifactId=jfreechart \
   -Dversion=[1.0.0,) -Dpackaging=jar -Dfile=/path/to/file

   Path to dependency:
 1) 
org.apache.struts:struts2-jfreechart-plugin:jar:2.0.2-SNAPSHOT

 2) jfree:jfreechart:jar:[1.0.0,)

2) jfree:jcommon:jar:[1.0.0,)

   Try downloading the file manually from the project website.

   Then, install it using the command:
   mvn install:install-file -DgroupId=jfree -DartifactId=jcommon \
   -Dversion=[1.0.0,) -Dpackaging=jar -Dfile=/path/to/file

   Path to dependency:
 1) 
org.apache.struts:struts2-jfreechart-plugin:jar:2.0.2-SNAPSHOT

 2) jfree:jcommon:jar:[1.0.0,)

--
2 required artifacts are missing.




The dependency s for jfree groupId dependencies seem to be off 
here:


http://svn.apache.org/repos/asf/struts/struts2/trunk/plugins/jfreechart/pom.xml 



-Rahul

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Dispatcher

2006-11-21 Thread Don Brown

Yeah, we probably should extract an interface out of the Dispatcher
class. For now, you can subclass Dispatcher and point Struts 2 to it by
subclassing the FilterDispatcher and override the createDispatcher method.

Don

Tarek Nabil wrote:

I've been going through the documentation and the source and trying to
understand the architecture of Struts 2.

In the documentation for the createDispatcher method in
FilterDispatcher, it says

Create a default [EMAIL PROTECTED] Dispatcher} that subclasses can
override
with a custom Dispatcher, if needed.

But when checking out the Dispatcher class, it seems that it does not
implement any interface. How can one go about implementing a different
Dispatcher if there's no defined interface? Or is there something that
I'm missing?

Thanks,
Tarek Nabil
DISCLAIMER
This email and any files transmitted with it are confidential and contain privileged or copyright
information. If you are not the intended recipient you must not copy, distribute or use this email

or the information contained in it for any purpose other than to notify us of
the receipt thereof.
If you have received this message in error, please notify the sender
immediately, and delete this
email from your system.

Please note that e-mails are susceptible to change.The sender shall not be
liable for the improper
or incomplete transmission of the information contained in this
communication,nor for any delay in
its receipt or damage to your system.The sender does not guarantee that this
material is free from
viruses or any other defects although due care has been taken to minimise the
risk.
**

1 2 >

1 - 100 of 116 matches

Mail list logo