Are there any news on this topic? It reads like there are missing parts that
need to be implemented before moving into trunk.
How to help out? Is there anything one can do to speed things up?
Piero
Am Montag 25 August 2008 15:19:45 schrieb Musachy Barroso:
It wasn't technically a vote
The multiple unknown handler feature needs to be implemented. Yesterday I
started changing this patch:
http://jira.opensymphony.com/browse/XW-640
Because it uses some static helper classes, to use beans that are injected.
The plan was to wait until 2.2 to move this into trunk, but I was based on
]
--
View this message in context:
http://www.nabble.com/-VOTE--Bring-Convention-plugin-into-trunk-and-deprecate-Zero-Config-tp17222798p19282043.html
Sent from the Struts - Dev mailing list archive at Nabble.com
So what was the outcome of the vote - is this moving into trunk?
--
View this message in context:
http://www.nabble.com/-VOTE--Bring-Convention-plugin-into-trunk-and-deprecate-Zero-Config-tp17222798p19143586.html
Sent from the Struts - Dev mailing list archive at Nabble.com
, Aug 25, 2008 at 9:10 AM, alvins [EMAIL PROTECTED] wrote:
So what was the outcome of the vote - is this moving into trunk?
--
View this message in context:
http://www.nabble.com/-VOTE--Bring-Convention-plugin-into-trunk-and-deprecate-Zero-Config-tp17222798p19143586.html
Sent from the Struts
Am Dienstag, 15. Juli 2008 16:43:22 schrieb Piero Sartini:
Then the classes that match the actionPackages
(named packages like com.my.package) will be queued for processing,
as well as classes whose package matches one of the locators
(action, actions, etc). If you name your packages using
Am Dienstag, 15. Juli 2008 03:53:26 schrieb Musachy Barroso:
The jars excluded from the scan will never have actions, like
freemarker, velocity, jdk jars, etc. You can completely disable the
scanning of jar files, and the plugin will scan only the specified
packages, wouldn't that cover the
Am Dienstag, 15. Juli 2008 09:44:52 schrieb Piero Sartini:
The modules may be deployed in their own JAR file. If we disable global
scanning they would be ignored, right?
JARScanning of course, not global scanning.
-
To
yes, the locators. We could have an option like a jar locators which
would limit the jars scanned, it would be really easy to implement
with the URLSets.
This could be a solution, but I can't imagine how to find a restriction that
is useful We had to enforce a naming scheme on the
the important code is this PackageBasedActionConfigBuilder:findActions:
ClassFinder finder = new ClassFinder(getClassLoader(),
buildUrlSet().getUrls(), true);
// named packages
if (actionPackages != null) {
for (String
Then the classes that match the actionPackages
(named packages like com.my.package) will be queued for processing,
as well as classes whose package matches one of the locators
(action, actions, etc). If you name your packages using
actionPackages, the plugin will find the classes in them.
Yes, the wiki needs to be updated, I think the most common use case
will be that people will have their actions in their classes folder,
instead of jar files, so I changed it, but we can talk about it.
musachy
On Tue, Jul 15, 2008 at 10:43 AM, Piero Sartini [EMAIL PROTECTED] wrote:
Then the
I did use Toplink Essentials and in its jar there is a package
called persistence.antlr.actions. So the locators matched. Don't know why
it comes to an error, but I think it is the same reason Brian excluded
hibernate and some other packages by default.
Yes, that could be tricky, yet the
Am Freitag, 23. Mai 2008 05:51:39 schrieb Musachy Barroso:
Yes I had a similar problem, and is not jdbc specific, it's just
convention scanning too much, I can't really remember what my problem
was, but convention was scanning the whole classpath. Anyway,
that's why I added
I opened WW-2576 some time ago.
After looking at the source I came to the conclusion that the convention
plugin is designed to exclude a whole bunch of packages from classpath
scanning. For my feeling that is not the best way to go because you can never
be sure what is on your classpath.
Musachy Barroso wrote:
WW-2667 is fixed on trunk. Has anybody taken a look at the multiple
unknown handlers proposal? I have the code ready to go but I am still
waiting for some confirmation :)
Hi Musachy, I think the proposal is fine. The use of multiple unknown
handlers will be rare.
Yes, that option is totally viable now that they can co-exist(assuming
that multiple unknown handlers are supported). One drawback it has, is
that for new users of the plugin, it would be confusing to have 2 sets
of similar annotations. The other problem would be the documentation,
we don't have
Musachy Barroso wrote:
Yes, that option is totally viable now that they can co-exist(assuming
that multiple unknown handlers are supported). One drawback it has, is
that for new users of the plugin, it would be confusing to have 2 sets
of similar annotations. The other problem would be the
WW-2667 is fixed on trunk. Has anybody taken a look at the multiple
unknown handlers proposal? I have the code ready to go but I am still
waiting for some confirmation :)
musachy
On Wed, Jun 4, 2008 at 5:30 PM, Musachy Barroso [EMAIL PROTECTED] wrote:
I created a proposal page on the wiki for
Hi Musachy,
Just letting you know I just moved a large rest-plugin app from an old
2.1.3-snapshot to the current head to try things out...and it still
works :-)
Here's what I had to do:
- added codebehind as a direct dependency for the application (for
now) as it was removed as a
Thanks for the testing :)
I added the dependency to rest-showcase to make build again. I also
added a note to the 2.1.1 release notes.
musachy
On Fri, Jun 6, 2008 at 10:24 AM, Jeromy Evans
[EMAIL PROTECTED] wrote:
Hi Musachy,
Just letting you know I just moved a large rest-plugin app from an
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
View this message in context:
http://www.nabble.com/-VOTE--Bring-Convention-plugin-into-trunk-and-deprecate-Zero-Config-tp17222798p17397185.html
Sent from the Struts - Dev mailing list
--Bring-Convention-plugin-into-trunk-and-deprecate-Zero-Config-tp17222798p17698364.html
Sent from the Struts - Dev mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail
Here is yet another idea, this one assumes that multiple
UnknowHandler(s) can be stacked (which I am prototyping). If we modify
ControllerClasspathPackageProvider, so it delegates to an instance of
ClasspathPackageProvider instead of extending it, and using reflection
for the delegation of those
Some small changes would be needed to Codebehind, adding a few
configuration parameters, which REST now sets by overwriting the base
class. But we should do this anyway.
musachy
On Wed, Jun 4, 2008 at 9:25 AM, Musachy Barroso [EMAIL PROTECTED] wrote:
Here is yet another idea, this one assumes
I created a proposal page on the wiki for this:
http://cwiki.apache.org/confluence/display/S2WIKI/Convention%2CCodebehind+and+REST+2.3
I also opened a ticket for fixing the depenency between
REST-Codebehind, which I don't see why it should exists:
https://issues.apache.org/struts/browse/WW-2667
Don's point is a valid one, but I also hope that he agrees that its a good
thing to somehow combine REST and Convention. I am not so sure that
changing how Struts fundamentally works so that we can include more and
competing plugins at runtime is a good thing. It is that type of confusion
: [EMAIL PROTECTED]
--
View this message in context:
http://www.nabble.com/-VOTE--Bring-Convention-plugin-into-trunk-and-deprecate-Zero-Config-tp17222798p17603378.html
Sent from the Struts - Dev mailing list archive at Nabble.com
? Pink Floyd
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
View this message in context:
http://www.nabble.com/-VOTE--Bring-Convention-plugin-into-trunk-and-deprecate-Zero
]
For additional commands, e-mail: [EMAIL PROTECTED]
--
View this message in context:
http://www.nabble.com/-VOTE--Bring-Convention-plugin-into-trunk-and-deprecate-Zero-Config-tp17222798p17576647.html
Sent from the Struts - Dev mailing list archive at Nabble.com
anyway,
i am not follow the REST feature
but i can see the ZeroConfig/CodeBehind/SmartURL/JSON vs current REST
is a smiliar but different world
anyone can share what should we do for this case?
i think this is good for us that investing our time, to know, which
one is depreciated and which one
The only conflict between codebehind and convention is on the
UnknownHandler. If struts would support multiple UnknownHandler(s),
like it supports multiple PackageProvider(s), we wouldn't have a
problem at all, and they could be able to co-exist without knowing
anything about each other. Given a
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
View this message in context:
http://www.nabble.com/-VOTE--Bring-Convention-plugin-into-trunk-and-deprecate-Zero-Config-tp17222798p17576647.html
Sent from the Struts - Dev mailing list
]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
View this message in context:
http://www.nabble.com/-VOTE--Bring-Convention-plugin-into-trunk-and-deprecate-Zero-Config-tp17222798p17522443.html
Sent from
://www.nabble.com/-VOTE--Bring-Convention-plugin-into-trunk-and-deprecate-Zero-Config-tp17222798p17522443.html
Sent from the Struts - Dev mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional
]
For additional commands, e-mail: [EMAIL PROTECTED]
--
View this message in context:
http://www.nabble.com/-VOTE--Bring-Convention-plugin-into-trunk-and-deprecate-Zero-Config-tp17222798p17522443.html
Sent from the Struts - Dev mailing list archive at Nabble.com
] To:
dev@struts.apache.org Subject: Re: [VOTE] Bring Convention plugin into trunk
and deprecate Zero Config On Fri, May 30, 2008 at 7:56 AM, Musachy Barroso
[EMAIL PROTECTED] wrote: Sounds like a plan but we don't have the
votes yet :) I think this is where I chime in (again) and claim
On Thu, May 29, 2008 at 7:21 AM, dusty [EMAIL PROTECTED] wrote:
So lets do it and consolidate all of the configuration automation into
Convention. We can get the new Convention and REST in 2.1.3-SNAPSHOT and
then update the Codebehind page that its being absorbed into Convention.
I say the
Why don't we get codebehind and rest together and make a
codebehind-rest-legacy.jar project. And make REST just depend on
convention, wouldn't that keep backward compatibility while allowing
us to move forward with REST+Convention?
musachy
On Fri, May 30, 2008 at 9:39 PM, Don Brown [EMAIL
]
--
View this message in context:
http://www.nabble.com/-VOTE--Bring-Convention-plugin-into-trunk-and-deprecate-Zero-Config-tp17222798p17522443.html
Sent from the Struts - Dev mailing list archive at Nabble.com.
-
To unsubscribe, e
in context:
http://www.nabble.com/-VOTE--Bring-Convention-plugin-into-trunk-and-deprecate-Zero-Config-tp17222798p17397185.html
Sent from the Struts - Dev mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED
The plugin will scan the entire classpath, but that's not to large of an
issue and pretty fast (considering). The issue is when it starts loading
classes into the perm space to determine if the class is in fact an Action
or not. This is the part where your perm space can become full and then
The scanning doesn't have anything to do with the location of the JSP files.
It is entirely based on the set of package locators and exclude packages. It
uses the classpath scanning mechanism that simply opens all the JAR files
and looks at them. It only loads a class into the JVM if it is in
You are right and I am confused with another problem, if your action is:
action -actions.MyCoolAction (@ResultPath(/))
result - /my-cool.ftl
what you get is a bunch of (with different jars)
SEVERE: Unable to scan [C:\Program
Files\apache-tomcat-6.0.16\lib\catalina.jar] for resources
Hmm...this should really be another thread, but there is a much better
solution for classpath scanning - xbean-finder. It is a small library
used by OpenEJB and Geronimo, three classes, that scans the classpath,
but uses a technique that doesn't require the class to be loaded into
memory. As a
Does this vote have a conclusion? Does the discussion merit a wiki page so
we can keep this thread for the vote itself?
Paul
On Tue, May 27, 2008 at 9:18 AM, Musachy Barroso [EMAIL PROTECTED] wrote:
You are right and I am confused with another problem, if your action is:
action -
The blockers were:
1. Support REST
2. Support Codebehind
We agreed on #1, and it should be working (more testing would be
nice). We haven't got to an agreement on #2 yet.
musachy
On Tue, May 27, 2008 at 7:27 PM, Paul Benedict [EMAIL PROTECTED] wrote:
Does this vote have a conclusion? Does the
I will check it out. Is this something that another plugin could use
or core itself?
musachy
On Tue, May 27, 2008 at 7:24 PM, Don Brown [EMAIL PROTECTED] wrote:
Hmm...this should really be another thread, but there is a much better
solution for classpath scanning - xbean-finder. It is a small
My vote is we bring the classes into XWork to replace the existing
classpath scanner.
Don
On Wed, May 28, 2008 at 10:04 AM, Musachy Barroso [EMAIL PROTECTED] wrote:
I will check it out. Is this something that another plugin could use
or core itself?
musachy
On Tue, May 27, 2008 at 7:24 PM,
It depends on ASM
musachy
On Tue, May 27, 2008 at 8:07 PM, Don Brown [EMAIL PROTECTED] wrote:
My vote is we bring the classes into XWork to replace the existing
classpath scanner.
Don
On Wed, May 28, 2008 at 10:04 AM, Musachy Barroso [EMAIL PROTECTED] wrote:
I will check it out. Is this
That's not a problem, particularly if we jarjar the dependency in the xwork jar.
Don
On Wed, May 28, 2008 at 10:12 AM, Musachy Barroso [EMAIL PROTECTED] wrote:
It depends on ASM
musachy
On Tue, May 27, 2008 at 8:07 PM, Don Brown [EMAIL PROTECTED] wrote:
My vote is we bring the classes into
Yes I had a similar problem, and is not jdbc specific, it's just
convention scanning too much, I can't really remember what my problem
was, but convention was scanning the whole classpath.
I remember what it was, because the jsps in rest-showcase where under
the root of webapp, I added
-Convention-plugin-into-trunk-and-deprecate-Zero-Config-tp17222798p17397185.html
Sent from the Struts - Dev mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL
]
--
View this message in context:
http://www.nabble.com/-VOTE--Bring-Convention-plugin-into-trunk-and-deprecate-Zero-Config-tp17222798p17397185.html
Sent from the Struts - Dev mailing list archive at Nabble.com
-Convention-plugin-into-trunk-and-deprecate-Zero-Config-tp17222798p17417559.html
Sent from the Struts - Dev mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
First off, Hi.. My name is Dusty Pearce and I am long time webwork user.
How do I pronounce your name? In my head its something like
Moose-atch-ee
Pretty close (outlook always wants to fix it and suggests Mustache ) :)
With that out of the way, I feel like I am missing something
PROTECTED]
--
View this message in context:
http://www.nabble.com/-VOTE--Bring-Convention-plugin-into-trunk-and-deprecate-Zero-Config-tp17222798p17397185.html
Sent from the Struts - Dev mailing list archive at Nabble.com
I don't think XML vs annotations is a correct split for a plugin. It would
be a split on unrelated features.
In that case then REST should continue to be in it's own plugin. I
don't know where Paul gets those ideas :).
I am trying to figure out what this means! :-) Sounds humorous.
Paul
[EMAIL PROTECTED]
Sent: Thursday, May 15, 2008 7:48 PM
To: Struts Developers List dev@struts.apache.org
Subject: Re: [VOTE] Bring Convention plugin into trunk and deprecate Zero
Config
Indeed :). I don't see why we shouldn't.
musachy
On Thu, May 15, 2008 at 5:37 PM, Paul Benedict [EMAIL
Jeromy Evans wrote:
I wouldn't rush into this decision.
Users of the REST plugin require @Namespace, @Result, etc
annotations. Creating a duplicate set of annotations with the same
purpose is not sensible.
It's appropriate that the REST plugin has a dependency on the plugin
that
My head is spinning now :). Can you use REST with Xml Conf?
musachy
On Fri, May 16, 2008 at 2:30 AM, Jeromy Evans
[EMAIL PROTECTED] wrote:
Jeromy Evans wrote:
I wouldn't rush into this decision.
Users of the REST plugin require @Namespace, @Result, etc annotations.
Creating a duplicate
that?
--
From: Musachy Barroso [EMAIL PROTECTED]
Sent: Thursday, May 15, 2008 7:48 PM
To: Struts Developers List dev@struts.apache.org
Subject: Re: [VOTE] Bring Convention plugin into trunk and deprecate Zero
Config
Indeed :). I don't see why we shouldn't.
musachy
On Thu, May
As far as I can see the only dependency between REST and Codebehind is
this class:
http://svn.apache.org/viewvc/struts/struts2/trunk/plugins/rest/src/main/java/org/apache/struts2/rest/ControllerClasspathPackageProvider.java?view=markup
which all it does is use Codebehind to detect actions that
I think it also depends on the unknown mapping handler in Codebehind. The
class takes care of determining the jsp to use when nothing is specified in
the configurations.
bean type=com.opensymphony.xwork2.UnknownHandler
class=org.apache.struts2.codebehind.CodebehindUnknownHandler /
On Fri, May
On Fri, May 16, 2008 at 10:50 AM, Musachy Barroso [EMAIL PROTECTED] wrote:
As far as I can see the only dependency between REST and Codebehind is
this class:
Not really, but so far some people think we should support it on
others think it is a bad idea.
musachy
On Fri, May 16, 2008 at 2:01 PM, Martin Cooper [EMAIL PROTECTED] wrote:
On Fri, May 16, 2008 at 10:50 AM, Musachy Barroso [EMAIL PROTECTED] wrote:
As far as I can see the only dependency
Well, votes can be just talk sometimes If someone wants to branch and
write a combination plugin or fix the dependency in another way, go for it.
Nothing wrong with experimental branches -- in fact Maven does this
constantly.
Paul
On Fri, May 16, 2008 at 1:05 PM, Musachy Barroso [EMAIL
On Fri, May 16, 2008 at 11:05 AM, Musachy Barroso [EMAIL PROTECTED] wrote:
Not really, but so far some people think we should support it on
others think it is a bad idea.
Right. But my point is that building consensus, while it may take longer,
provides a better basis on which to move forward
Sounds good Musachy.
Musachy Barroso wrote:
As far as I can see the only dependency between REST and Codebehind is
this class:
http://svn.apache.org/viewvc/struts/struts2/trunk/plugins/rest/src/main/java/org/apache/struts2/rest/ControllerClasspathPackageProvider.java?view=markup
which all it
What I meant is that with some effort, instead of the convention plugin
providing both Configuration and Mapping/Invocation is could be split
into two: a plugin that provides config via annotation and a plugin that
provides mapping invocation conventions. If that were the case then
What I meant is that with some effort, instead of the convention plugin
providing both Configuration and Mapping/Invocation is could be split into
two: a plugin that provides config via annotation and a plugin that provides
mapping invocation conventions. If that were the case then
understand what each one does ;).
Al.
- Original Message - From: Bob Tiernay [EMAIL PROTECTED]
To: Struts Developers List dev@struts.apache.org
Sent: Wednesday, May 14, 2008 8:43 PM
Subject: RE: [VOTE] Bring Convention plugin into trunk and deprecate Zero
Config
+1
I think
List dev@struts.apache.org
Sent: Thursday, May 15, 2008 2:21 PM
Subject: Re: [VOTE] Bring Convention plugin into trunk and deprecate Zero
Config
I don't think there is any page that compares them, quick overview:
Code-behind: Provides default mappings for pages without actions,
default results
2:21 PM
Subject: Re: [VOTE] Bring Convention plugin into trunk and deprecate Zero
Config
I don't think there is any page that compares them, quick overview:
Code-behind: Provides default mappings for pages without actions,
default results (finds templates based on action name and result
Looking at the rest plugin, something doesn't feel right. Doesn't the
dependency between REST and Codebehind looks wrong? From
http://struts.apache.org/2.x/docs/plugins.html
Plugins are not loaded in any particular order. Plugins should not
have dependencies on each other. A plugin may depend on
It appears you're making the argument for combining these plugins. :-) +1 to
that.
Paul
On Thu, May 15, 2008 at 4:20 PM, Musachy Barroso [EMAIL PROTECTED] wrote:
Looking at the rest plugin, something doesn't feel right. Doesn't the
dependency between REST and Codebehind looks wrong? From
Indeed :). I don't see why we shouldn't.
musachy
On Thu, May 15, 2008 at 5:37 PM, Paul Benedict [EMAIL PROTECTED] wrote:
It appears you're making the argument for combining these plugins. :-) +1 to
that.
Paul
On Thu, May 15, 2008 at 4:20 PM, Musachy Barroso [EMAIL PROTECTED] wrote:
that?
--
From: Musachy Barroso [EMAIL PROTECTED]
Sent: Thursday, May 15, 2008 7:48 PM
To: Struts Developers List dev@struts.apache.org
Subject: Re: [VOTE] Bring Convention plugin into trunk and deprecate Zero
Config
Indeed :). I don't see why we shouldn't.
musachy
On Thu, May 15, 2008 at 5:37
: Re: [VOTE] Bring Convention plugin into trunk and deprecate Zero
Config
Indeed :). I don't see why we shouldn't.
musachy
On Thu, May 15, 2008 at 5:37 PM, Paul Benedict [EMAIL PROTECTED]
wrote:
It appears you're making the argument for combining these plugins. :-) +1
to
that.
Paul
Has any work been done to support existing zero config applications
with this new plugin? If not, I'd kinda consider that a blocker (-1)
because a sufficiently flexible configuration system should be able to
support multiple conventions. Also, someone will have to sign up to
convert the REST
I've spoken to quiet a few people that are already using zero-config in
production. I understand that it was always experimental, but it was
also solid and now used. I'd have to agree with Don (even though my
vote is now non-binding) and vote +0 if the existing zero-config
features are
+0
Personally, I'd like to see the the CodeBehind, Zero-Config, Convention and
Rest plugins better integrated and the overlap reduced. Right now there are
multiple ways to skin the same cat and that can be confusing to new and
experienced users alike. The question they will likely have is: Which
I haven't tested the latest Convention plugin yet so I can't vote yet,
but I'd probably give a [-1] because I don't like the options provided.
I support moving Convention plugin from the sandbox to become the
recommended convention for new users, replacing ZeroConfig and CodeBehind.
However, I
I reaffirm my -1. Since there is overlap between the three plugins, I
suggest either a new plugin is created that merges all their respective
features, or one of the existing plugins should absorb the others.
Paul
On Wed, May 14, 2008 at 9:05 AM, Jeromy Evans
[EMAIL PROTECTED] wrote:
I
I will take a look at the migration of the REST plugin. But I don't
see the point of supporting codebehind from convention, as they are
separate plugins, users can choose any one they like, we are just
saying that convention is the recommended one, and there won't be
more development on
FWIW, I am also against the name convention plugin. Conventions change
over time, and I don't think any one plugin should be the convention. I'd
like to have a name that explains the intent behind the convention. That's
why names like Zero Config or REST are much more affable.
Paul
On Wed, May
It turns out that making codebehind work from convention is quite easy
(DI FTW!), but again, I think this would be a bad choice.
musachy
On Wed, May 14, 2008 at 11:18 AM, Musachy Barroso [EMAIL PROTECTED] wrote:
I will take a look at the migration of the REST plugin. But I don't
see the point
+1
Here are the goals of this plugin. Any movement to integrate plugins and
make all things compatible (which I gracefully disagree with) MUST
satisfy these goals:
- Simple API that is fixed and will not change anytime soon
- Usable with absolutely no configuration or annotations
-
We all agree on updating the REST plugin, but we can't do that until
Convention lands on trunk. If we are divided on the topic of
Convention supporting Codebehind vs keeping them as stand alone
plugins, should we then vote on that?
musachy
On Wed, May 14, 2008 at 12:46 PM, Brian Pontarelli
@struts.apache.org Subject: [VOTE] Bring Convention plugin into trunk and
deprecate Zero Config With the addition of @IntereceptorRefs to the
Convention plugin, it is now possible to do most of the action mapping using
annotations. Also having 2 plugins to do the same thing is really confusing
for users
: Bob Tiernay [EMAIL PROTECTED]
To: Struts Developers List dev@struts.apache.org
Sent: Wednesday, May 14, 2008 8:43 PM
Subject: RE: [VOTE] Bring Convention plugin into trunk and deprecate Zero
Config
+1
I think that this plugin is of great worth to every day development. I
would like to echo
With the addition of @IntereceptorRefs to the Convention plugin, it is
now possible to do most of the action mapping using annotations. Also
having 2 plugins to do the same thing is really confusing for users,
so we should deprecate Zero Config (good thing is that it was always
experimental).
If
+1
On Tue, May 13, 2008 at 9:39 PM, Musachy Barroso [EMAIL PROTECTED] wrote:
With the addition of @IntereceptorRefs to the Convention plugin, it is
now possible to do most of the action mapping using annotations. Also
having 2 plugins to do the same thing is really confusing for users,
so
-1. Move the features of Convention into Zero Config.
On Tue, May 13, 2008 at 10:56 PM, Matt Raible [EMAIL PROTECTED] wrote:
+1
On Tue, May 13, 2008 at 9:39 PM, Musachy Barroso [EMAIL PROTECTED]
wrote:
With the addition of @IntereceptorRefs to the Convention plugin, it is
now possible
+1
2008/5/14 Musachy Barroso [EMAIL PROTECTED]:
With the addition of @IntereceptorRefs to the Convention plugin, it is
now possible to do most of the action mapping using annotations. Also
having 2 plugins to do the same thing is really confusing for users,
so we should deprecate Zero Config
95 matches
Mail list logo
