Re: Article
On Thu, Mar 13, 2008 at 9:45 AM, Jim Cushing [EMAIL PROTECTED] wrote: P.S. By rather poor designs features of Struts 1, I refer primarily to choice of making Actions singletons, which required a separate ActionForm bean. As I've read the history of Struts 1, WebWork, and Struts 2, much of it written by the members of this list, I see that they've acknowledge the drawbacks of that approach and have learned from it. By no means did I mean to disparage the Struts 1 team. The nature of software is that it gets better with time as we refine our designs. That said, it's interesting that the Spring MVC team decided not to learn from, and instead repeat, this mistake. It's useful to remember that decisions like this (for any framework) were not made in a vacuum. Instead, they were influenced by the technology available at the time. In the case at hand, Struts 1 was designed in the days when JDK 1.1 was the predominant platform, and object creation/GC was so expensive that anyone who profligately creates lots of objects per request (the way that many modern frameworks do it) would have been considered patently insane :-). After that point, and especially for a framework that achieved the popularity that Struts 1 did, backwards compatibility for existing applications became a pretty strong motivation not to change something this fundamental lightly. Note, for example, that servlets are *still* singletons, even ten years later. Craig McClanahan On Mar 13, 2008, at 12:33 PM, Jim Cushing wrote: I'm but a humble Struts 2 user (and a Spring MVC critic), so forgive me for lurking on this list (it's a great way for me to follow the progress). I posted two comments to that blog (search for jimothy) that I think sum up Spring MVC vs. Struts 2 from a mindshare perspective. I'd be interested to hear how those in the thick of Struts 2 development feel about this. On Mar 12, 2008, at 11:41 AM, James Mitchell wrote: Interesting read... http://www.oreillynet.com/onjava/blog/2008/03/spring_mvc_javafx_google_web_t.html -- James Mitchell - 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] - 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: [s2] Proposal: Rest Plugin
On 10/21/07, Don Brown [EMAIL PROTECTED] wrote:
On 10/22/07, Martin Cooper [EMAIL PROTECTED] wrote:
On 10/21/07, Don Brown [EMAIL PROTECTED] wrote:
[...]
Which reminds me, this plugin is targeted towards HTML-based web apps
that want to expose their information in machine-readable ways (XML
and JSON),
I presume you mean DOM-based apps; some of us don't use HTML any more. ;-)
HTML = text format that you want to manually generate using jsp,
velocity, or freemarker
What happens when different clients want different representations?
This is one of the places where Rails does a pretty nice job, using
the respond_to method to let the controller choose which
representation to produce, based on some combination of (a) what did
the client ask for (via a content type header or a format suffix on
the URL), and (b) what representations are available in the app.
On the other hand, when combined with a plugin like
make_resourceful[1] , a Rails controller supporting simple things like
CRUD operations, with multiple representations, can be incredibly
concise. (Rails lets you define multiple related actions in a single
controller, so this is all in one class.) The domain of interest in
this example is the posts on a blog system.
class PostController ApplicationController
make_resourceful do
actions :all
publish :xml, :json, :yaml,
attributes = [ :id, :title, :body,
{ :comments = [ :id, :author, :body ] }
]
end;
end;
That's the whole controller (without make_resourceful it'd be about
100 lines of code) ... but it allows you to select any of XML, JSON,
or YAML (a text format for hierarchical data commonly used in Rails
config files, but not restricted to Ruby). Adding HTML as an output
option is one more entry on the publish line (plus writing the
corresponding views in your favorite template language). And this
controller automatically maps *all* of the following (think of them as
context relative) URLs to the specified controller actions, which
perform the specified tasks:
# POST /posts -- create a new post and return status 201 plus a
Location header with the
# appropriate URL to access the newly created post instance
def create ... end
# DELETE /posts/xxx -- delete the post row with key xxx
def delete ... end
# GET /posts/xxx/edit -- create an HTML entry form for the post with
key xxx; the
# resulting PUT will call the update() action. Only used for HTML
representation
# (in earlier edge rails, this was ;edit instead of /edit)
def edit ... end
# GET /posts -- return an HTML table or a data structure in the
requested format
def index ... end
# GET /posts/new -- create an HTML entry form for a new post
instance; the resulting
# POST will trigger the create() action. Only used for HTML representation
# (prior to edge rails, this was ;new instead of /new)
def new ... end
# GET /posts/xxx -- return HTML details or data representation of
post with key xxx
def show ... end
# PUT /posts/xxx -- update the post row with key xxx from parameters
in this request
def update ... end
Several notes are important to understand if you're not familiar with
Rails REST support:
* With make_resourceful, you don't actually write the above methods at
all -- they
are generated at runtime. The source code above is what the
developer writes (plus any
HTML views). Can you write a complete CRUD web service with
Struts2, supporting
multiple representations, in nine lines of code (minus HTML views)?
* Without make_resourceful, there's a Rails generator that will
actually generate all
this code -- but you end up with ~100 lines per controller, with a
pattern that is repeated
in every controller with only a few details being different. That's
not optimal, which is
why a plugin like this got created. It won't be part of Rails 2.0
core (the Rails core
developers have a similar allergy to a bloated core that the Struts2
developers have),
but it's readily available.
* You can add additional actions that are related, and this is not
uncommon for special
purpose requests that don't strictly conform to CRUD operations but
share the same
requirements for data acquisition.
* For index and show, the client requests the representation they
want, either via an
accept header specifying the content type, or adding .xml,
.json, or .yml to the URL.
* A client of a RESTful web service will never need the edit or
new actions ... it will
simply interact directly with update or create appropriately.
* The Rails helper methods for form based HTML input have workarounds
for the fact
that browsers do not actually know how to do a PUT or DELETE (except
in an Ajax
callback). This kind of thing could easily be implemented in the
server side view
representation, but it'll be specific to whatever templating
technology you like.
* Note that the controller's
Re: Has the WebWork rebranding to Struts2 been a failure?
On 6/23/07, Martin Gilday [EMAIL PROTECTED] wrote: [snip] The stats that Ted posted suggest that I have nothing to worry about anyway. Maybe we are just not as vocal about it. I'm assuming those stats only include direct downloads and not the central Maven repo where many people may be pulling it from? Not only is it just direct downloads ... it is just direct downloads from Apache's server only, and does not include downloads from any of the mirrors (which is where well behaved folks *should* be getting their downloads). Or, obviously, from the Maven repositories. As recently as three weeks ago, I was talking to some people who have whole consultancies still built around Struts 1, for old and new projects, that are doing just fine, thank you. You can sneer all you want about how Struts 1 doesn't measure up to your 2007 sensibilities ... but it's still very widely popular six years after version 1.0 was released :-). Craig McClanahan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: s1 - 1.x Future Issues
On 2/19/07, Paul Benedict [EMAIL PROTECTED] wrote: The purpose of the Road Map is to assign issues to a release. Since Future is not a version or a release -- but just a grouping of issues for the future -- it has little use, and the way we use it tells me we're using the Road Map wrongly. Now, I believe that's the case, but I am not going to fight this issue too strongly because it is not critical to anything. I'll go back and look at the archives, but there's nothing wrong with re-examining past decisions. I haven't seen other JIRA projects slating things into a Future version -- and probably because it's not a version. Paul For what it's worth, we're using a TBD version identifier in Shale for the same concept that Future seems intended for in Struts ... to track things that are real issues (either bugs or RFEs), but for which no one has yet stepped up and said I want to deal with this for a particular release. This is different from Unscheduled (the default state when a new issue is created), because it has to be looked at and assigned, instead of being closed as Will Not Fix or Not A Problem immediately. An issue tracking system should (IMHO) be useful for more than just roadmaps and release notes. Let's say you hear from an enthusiastic user who wants to contribute to the project, but doesn't have a specific idea on where to start. Where do you send him or her to get some ideas? For Shale, I've got a simple answer[1]. Wouldn't Struts like to have the same ability? Craig [1] https://issues.apache.org/struts/secure/IssueNavigator.jspa?reset=truemode=hidesorter/order=DESCsorter/field=priorityresolution=-1pid=10130fixfor=21773 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts Release Process (again) (was [VOTE] Struts 2.0.5 Quality)
On 2/6/07, Don Brown [EMAIL PROTECTED] wrote: Well, two comments here. First, how many beta releases do we need before it is time for a GA? I think we've been at beta quality since 2.0.1 and, yes, it has been helpful to weed out issues, but now with several large applications running Struts 2 and no significant issues in JIRA, I think we are ready for GA. The second is a general comment about this new release process. I think you are right that we'll have to agree to disagree here, cause I've always disliked this idea of doing a release then voting on it later. If we are taking that backwards-looking approach even farther and basically automatically giving releases a beta label until some undetermined future date when we vote again, then I really must object. I can understand the value of a test build and vote a few days after to ensure that the release process went off smoothly and all the important bits are in there. I may not particularly like it, but I agree it is necessary. What I find disturbing is that we would make a habit of waiting till weeks/months after the fact to label it GA. If the release is built, we test it and find nothing wrong, I think we should label it GA and move on. If bugs are found after the fact, then let's roll another release. I'm concerned that the backwards-looking way of thinking will result in a project that very rarely gets anything out to its users. I think open source projects work best when they release early and often, even if they may find bugs in it later on. And before the comment is made that test builds or even beta releases _are_ following the release early/often pattern, it certainly isn't true for what I'd argue that is the majority of developers who can't touch a product without the GA label. I really hope we can find a productive balance between the need for stability and need to keep the project moving at a healthy pace. Let's not fall into the Struts 1 trap of being overly conservative, but instead get out quality releases quickly and often. Isn't a feature of the current release practice that you could vote a particular x.y.z release as beta now, but later hold another vote to upgrade it to GA status later (i.e. without requiring another release)? Don's success with it is great ... but that is only one data point. Having 10-50 people report back success would seem to mean it's time to go back and give that release a better report card. Don Craig Ted Husted wrote: We might have to agree to disagree. I believe a beta vote is warranted when someone believes the code is ready for testing outside of the development group. Personally, I am not in favor of passing a set of bits straight to GA without a beta cycle, especially when a release series hasn't seen a GA release yet. The term General Availability should mean that we feel it is ready for us by the general public, not just that we were able to use it ourselves. Of course, other PMC members may have different viewpoints. Remember, voting beta now is not the final disposition. It simply means that we can announce the release to the user list and encourage wider testing. If the reports come back joyful, then we can decide to apply the GA stamp. In the meantime, we can continue to roll new releases. I'd be happy to run one every week or two, so long as there is something to put into the notes :) -Ted. On 2/6/07, Don Brown [EMAIL PROTECTED] wrote: I disagree; you shouldn't vote beta just because you haven't ran the code in production. A beta vote should be reserved for the case where you don't believe the quality is at the level of a GA release, and there should be specific issues you can point to that you feel need to be resolved first. If you have downloaded the release, ran it through whatever tests you deem appropriate, and it passes with flying colors, then a GA vote is warranted. Don Ted Husted wrote: Beta is also an option :) On 2/6/07, Ian Roughley [EMAIL PROTECTED] wrote: +0 for GA. I have some testing code that looks good, but no production code that has been converted. /Ian - 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: Struts Release Process (again) (was [VOTE] Struts 2.0.5 Quality)
On 2/6/07, Don Brown [EMAIL PROTECTED] wrote: Alexandru Popescu wrote: I see two clear stages: - a product that is ready from developers point of view - a product that gets its users acceptance An OSS project can take the same approach or not, and this is up to its management. However, I feel that a project that would like to be widely used cannot be labeled as released version without the user acceptance. I understand Don's concern about how these steps should be managed, but I think this is not a very complex process: - developer's ready version: beta - (after a scheduled period during which only fixes go in if necessary): GA. I would love it if we actually did this. Unfortunately, we don't do the second step, which is to have a scheduled period that allows fixes to go in if necessary. What we actually do is freeze the code in a test build, and put that through an undetermined period after which it may be reassessed. If any problems are found after the build, the whole process starts again. What this results in is a project that very, very rarely releases a GA release because issues are always found after the test build. If you don't believe me, look how often we put GA releases out with Struts 1 and that was with a code base that rarely saw any significant development/features. Imagine how long it would take us to get out a release on a very active project... That is definitely one of the lessons to be learned from the Struts 1.xexperience. Here's how we're applying that lesson in Shale land. The recent 1.0.4 release is the first one we felt had a snowball's chance at being voted GA quality, so as soon as we cut that release we also branched (SHALE_1_0_X), with the rule that only bugfixes (including non-invasive bugfixes backported from the trunk) would be committed here. The trunk was then opened for further new feature development (as well as bugfixes). Right now, it is tentatively labelled as 1.1.0-SNAPSHOT, but that could easily become 2.0.0-SNAPSHOT if we wanted to do major non-backwards-compatible changes. The net effect is that Struts could: * Create a branch totally focused on stabilization and bugfixes ... the only *point* is to create a GA-quality branch based on the current feature set. If 2.0.5 does not cut the mustard, just fix the reported bugs and try again (weeks instead of years later). * Avoid slowing down new feature development ... it continues on the trunk. * If 2.05 (say) got voted GA but a security vulnerability or critical bug were later discovered, an updated version could be turned around VERY quickly on the branch. Just fix the bad problems and release it. You don't have to worry about stabilizing all the new features that might have been added on the trunk, because they won't be present on the branch. (The MyFaces folks are currently paying the same price we paid in 1.x, because they are intermixing new features and bugfixes on the trunk -- hopefully they will learn the same lesson.) Branches are our friends. The fact that we didn't leverage them is the biggest thing we did wrong in Struts 1.x development, IMHO. I hope that the Struts 2 process can improve based on lessons learned from that experience. Don Craig
Re: [VOTE] Tiles TLP
On 12/2/06, David H. DeWolf [EMAIL PROTECTED] wrote: [X] +1 = Yes, let's ask the board to establish the Tiles TLP Craig
Re: [VOTE] Tiles PMC Chair
On 12/2/06, David H. DeWolf [EMAIL PROTECTED] wrote: [X] Greg Reddin (greddin) Craig
Re: [tiles2] Tiles TLP and Dimensions incubation
On 12/1/06, Antonio Petrelli [EMAIL PROTECTED] wrote: Hello! I want you to know that I have contacted the original developer (and copyright owner) of Dimensions, and he said that he is available for the code donation. So my question is: should we process Dimensions incubation after Tiles has estabilished as a TLP, or should we do it at the same time? Let me know your thoughts. I suspect the most expeditious path is to process the two items separately. The existing Tiles code can simply be transferred to a new TLP, because it's all clearly Apache code. The Dimensions code is going to have to go through the Incubator -- even though its likely that this can go very quickly, there is no reason to mess up the progress of the Tiles TLP proposal by trying to do them together. Thank you Antonio Craig
Re: [PROPOSAL] Tiles TLP
On 11/30/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 11/30/06, Antonio Petrelli [EMAIL PROTECTED] wrote: David H. DeWolf ha scritto: 2) Decide on a PMC Chair - who is interested? As I can see from this question, then you probably you're not interested :-) Or are you? I'd like to see Greg or David as Tiles PMC Chair. +1 on either. (It doesn't have to be forever... I noticed in the board meeting minutes that one project is changing chairs every 1-2 years, which might be something to consider.) Craig or Martin, can you comment on what's actually involved and how much time it takes? Current Board policy is that new TLPs report once a month for the first three months, then quarterly thereafter. You can see the range of reports that different TLPs provide in the public board meeting minutes. In practice, it doesn't take long -- it's not like release notes that need to track every little detail. The Board primarily wants to hear about the community aspects, and any issues that the TLP wants to bring to the Board's attention. The two things I know of are sending board reports (monthly for a while, then quarterly), and requesting accounts and granting karma for new committers. Anything else? As Ted mentions, any PMC member can do the account requests. Karma grants ( i.e. adjusting the SVN permissions) is currently a PMC chair function (it's editing and checking in a config file, so no big effort involved), but that's probably negotiable. Also, as with Ted, I'm also a PMC chair already so it'd be best to have someone else be the chair here. But, of course, I'll definitely help out as needed. -- Wendy Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Updated Tiles Graduation Proposal
On 11/28/06, Greg Reddin [EMAIL PROTECTED] wrote: Since we've failed to build consensus, I've published a versioned snapshot that will have to suffice for 2.0.2 and I will begin to drive the effort for TLP :( - it's not my preference but it will have to work. Hang on, slow down just a bit :-) Before we jump off the TLP cliff let's make sure we know all the options and have consensus from everybody involved. As a historical note, the ASF Board really doesn't like umbrella projects, and has actively encouraged the graduation mania we've seen out of Jakarta over the last couple of years. Here's the viable choices as I see them: 1) Jakarta Web Components Subproject - What components will make up this list? Who all needs to be involved in the discussion? 2) Apache Web Components TLP - What components will make up this list? Who needs to be involved in the discussion? What's the process to proceed? 3) Apache Tiles TLP - Seems we could do this here and now and submit a proposal to the board. Who else should we bring into the discussion? I'd be happy to be involved in #3 ... either #1 or #2 seems like a built in scenario for wishy washy boundary discussions, plus scope creep. For example, how do you define web component in such a way that Struts itself would not qualify? If that were OK, how do you decide when a web component should itself graduate? Writing code is much more fun than writing umbrella project charter documents :-). Craig Options that have been discussed and rejected: 1) Struts subproject - Struts does not need to become an umbrella. 2) Jakarta Commons component - Tiles is more of a framework than most of the components under commons. Several people have voiced their objection to this approach. 3) Struts2 Tiles Plugin - Removes the standalone nature of Tiles. So... of the three viable options, let's discuss and decide where to go from here. Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Message resources from database
On 11/21/06, Ted Husted [EMAIL PROTECTED] wrote: Is JPAMailreaderDao part of this * http://sourceforge.net/project/showfiles.php?group_id=49385package_id=149742 or is it a Shale thing? The mailreader-jpa[1] shale thing :-) is actually independent of Shale, in the same way that mailreader-dao has been independent of Struts. The contents are a persistence.xml file and the corresponding JPA entity classes. It's perfectly reasonable to consider using it in a Struts example, if you want. -T. Craig [1] http://svn.apache.org/viewvc/shale/framework/trunk/shale-apps/mailreader-jpa/
Re: svn commit: r472338 - in /struts/maven/trunk/struts2-archetype-starter/src/main/resources: META-INF/archetype.xml archetype-resources/src/main/webapp/WEB-INF/decorators/main.ftl archetype-resource
On 11/8/06, tm jee [EMAIL PROTECTED] wrote: Does this need a servlet mapping? I don't think so. It just expose the servlet instance itself such that ServletConfig etc. could be obtained . This I think is needed when using a jsp taglib in freemarker You're correct ... a servlet mapping is not required, if all you are after is the load on startup behavior of the container calling init() at startup time, but you do not want this servlet to process any requests. With the current generation servlet APIs, you'd more likely do this sort of thing in a ServletContextListener, but I imagine this design predates that. rgds. Craig
Re: [Struts-Faces] possible Bug in FormRenderer
On 10/26/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hey, two things. a) is this the right place to ask questions on Struts-Faces, or where ? It's the right place for dev type questions ... the Struts User list for user type questions :-). if so b) the demos of struts faces show a portal which uses links (done w/ JSF-components) to navigate to a tiles pages, which finally contains a s:form based formular. that is the key... ActionForm/Action on the java side and JSF comp.s on the page side. Every thing works. A form-submit sends a req. to the action So far so good... When I am converting one of my own apps w/ struts-faces I'd like to stay with html:link for linking to form pages (that are using s:form). But ... In other words, you want to use the Struts html:link tag in a form surrounded by the JSF s:form component? That's very likely not going to work reliably. You should stick to one technology or the other for all of your view tier tags on any particular page -- either the Struts HTML tags or the appropriate JSF component tags. You are only scratching the surface of a lot of problems that will show up trying to mix them. Craig since that is a GET request the form renders html like form name=fooForm action=/blub/tilesMasterLayout.do ... (only when using GET / html:link) so ... a submit causes a 404. Not wondering :) When I use firebug to change the action attr value to /blub/tilesMasterLayout.faces every thing works. Action is called. The action() method in FormRenderer returns in the wrong szenario a .do URL I think it is not to bad to check agains a struts pattern in that URL and replace that .do (if needed) with the jsf pattern (like .faces or add /faces/) I think this is valid, because the form renders already fine, which ensures you are inside the FacesContext ... If you all agree, I'd like to provide the patch for that. Greetz, Matt -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: [S2] Spring 2 for Struts 2?
On 10/14/06, Martin Cooper [EMAIL PROTECTED] wrote: On 10/13/06, Ted Husted [EMAIL PROTECTED] wrote: Since the reports are that Spring 2 works just fine with Struts 2, why don't we bite the bullet and update our dependencies? Other than a shiny new version number, what will this buy us? I don't have any objections per se, but we should have good reasons for changing our dependencies. A major functional reason is that Spring 2 finally understands about scopes, making it *much* easier to integrate with web frameworks. But the point earlier in this thread about making sure S2 still works with Spring 1.x is still well taken. -- Martin Cooper Craig -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tiles2] Tiles controllers (WAS: Re: [tiles2] Some words about proposed changes)
On 10/6/06, Antonio Petrelli [EMAIL PROTECTED] wrote: Greg Reddin ha scritto: Here's what I envision for the controller: I don't think it would really be used to change the destination of the response. I don't see the controller as being analogous to a Struts action even though it could be used in that way. If I wanted the controller to be used as a controller in the MVC sense of the word (IOW to select a destination) I'd want it to return something like actions do in Struts, WebWork, and JSF. I've always used the controller like a JSP tag. I use it to implement code that needs to reside in the view layer (or code that needs to be called from the view layer) and as a way to keep from writing scriptlet code in my JSPs. Uh I see, I think it's time to resurrect controllers (I think it's needed only in the TLD). Now what about their name? Possible names could be: * Controller for the class (or maybe TilesController) - controllerClass and controllerUrl for tag attributes * ViewPreparer (or TilesPreparer) for the class - preparerClass and preparerUrl and for the tag attribute (thanks Nathan!); * TilesPreprocessor - preprocessorClass, preprocessorUrl (this is what I suggest). Two similar concepts in other places might provide fodder for names: * In WW/Sttruts2 the corresponding concept is the Preparable interface ... it might be nice to use the same name if the concept applies directly. If that might be too confusing, then Preparer would likely be better (although it is a bit awkward to pronounce). * In Shale, the corresponding concept is the prerender() method of the ViewController interface. That name was chosen to set the connotation that get the data I'm going to need to render this view is what code should actually go here. Craig
Re: [tiles2] Some words about proposed changes
On 10/5/06, Nathan Bubna [EMAIL PROTECTED] wrote: I think controllers should stay, but the name should be changed. Call them ViewPreparers or something... I would agree. The useful thing you can do here is prepare the data needed to do the subsquent rendering. It is called *after* the controller has already dispatched and chosen which view to render. Craig On 10/5/06, Greg Reddin [EMAIL PROTECTED] wrote: On Oct 5, 2006, at 9:53 AM, Antonio Petrelli wrote: * The controllers were added to allows stand alone use of tiles to be able to do some kind of computation associated to the tiles. When used with Struts, there is a redundancy (with the use of actions), but when used alone, the controller mechanism is very useful to separate view rendering from controller business The problem with Tiles controllers is that the controller is not able to choose between different destination pages. It misses an important part of a controller: the dispatcher. But using a normal url as a template (or tile :-) ) it can do both calling the model and dispatching. If you download the latest version from SVN, there is a test with a simple servlet that includes a (fixed for the moment) JSP page. And I think that including a Controller in a View layer technology is not a good idea. Here's what I envision for the controller: I don't think it would really be used to change the destination of the response. I don't see the controller as being analogous to a Struts action even though it could be used in that way. If I wanted the controller to be used as a controller in the MVC sense of the word (IOW to select a destination) I'd want it to return something like actions do in Struts, WebWork, and JSF. I've always used the controller like a JSP tag. I use it to implement code that needs to reside in the view layer (or code that needs to be called from the view layer) and as a way to keep from writing scriptlet code in my JSPs. It just so happens that the controller API gives you indirect access to the request and response objects so you could use them to include or forward or write directly to the response and all the other stuff you can do there. But I'd not recommend the controller be used in this way. I would use the controller to manipulate the TilesContext and the JSP contexts, but not to actually do anything with regards to changing the destination. In today's world if I was writing a Struts app with Tiles I would try to use JSTL, EL, custom tags, (or in JSF, action listeners, etc). to do things I did in the past with controllers. But I can still see circumstances where I might want a controller instead. Think about this: Tiles can be used for page composition outside of any MVC framework. In that sense it's kind of like a portlet container. (In fact I think that's how Cedric envisioned it before JSR-168 came about). So you can compose pages out of JSP fragments and populate each fragment with a controller that is executed before the fragment is processed and included. I actually have written a couple of small webapps that use Tiles in this way and see it as a powerful feature. I think we should retain the controller for Tiles definitions (not sure about the insert tag). I also think we should document the fact that you can get yourself into all kinds of trouble by making improper use of the request and response APIs from within the controller. Thoughts? Greg - 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: Rollover scope for Struts 1.3.x
On 9/15/06, Michael Jouravlev [EMAIL PROTECTED] wrote: On 9/14/06, Craig McClanahan [EMAIL PROTECTED] wrote: In Shale, the closest analog to this is Dialog scope, and we're building the concept of a scope instance per window/frame, independent of what that window/frame is actually doing. I believe this requires usage of Javascript? So you would have listeners when a window is created and closed, right? I want to have a solution that works without Javascript. Currently this doesn't take any JavaScript ... but note the code I'm talking about here is currently in the Shale sandbox if you want to look further at it. It will get merged back into the main codebase later. The basic idea is we rely on the fact that JSF saves and restores the component state for us, so it uses a PhaseListener to store away the conversation id as part of the component tree (when the page is rendered), and restore the corresponding state (when the subsequent postback occurs). In our case, it just exposes the dialog context for the conversation on the current view as a request scope attribute ... I don't personally see a use case for registering listeners on that conversation, but I suppose it could be done. If you don't have JSF doing the save/restore component tree stuff, you'd likely have to store the conversation id in some other way (cookie, hidden variable, URL parameter), but you could still accomplish the same thing without any client side JavaScript. Michael. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Rollover scope for Struts 1.3.x
On 9/15/06, Michael Jouravlev [EMAIL PROTECTED] wrote: On 9/15/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 9/15/06, Michael Jouravlev [EMAIL PROTECTED] wrote: On 9/14/06, Craig McClanahan [EMAIL PROTECTED] wrote: In Shale, the closest analog to this is Dialog scope, and we're building the concept of a scope instance per window/frame, independent of what that window/frame is actually doing. I believe this requires usage of Javascript? So you would have listeners when a window is created and closed, right? I want to have a solution that works without Javascript. Currently this doesn't take any JavaScript ... but note the code I'm talking about here is currently in the Shale sandbox if you want to look further at it. It will get merged back into the main codebase later. The basic idea is we rely on the fact that JSF saves and restores the component state for us, so it uses a PhaseListener to store away the conversation id as part of the component tree (when the page is rendered), and restore the corresponding state (when the subsequent postback occurs). In our case, it just exposes the dialog context for the conversation on the current view as a request scope attribute ... I don't personally see a use case for registering listeners on that conversation, but I suppose it could be done. Does the above mean that the server does not get notified when a window is closed? So the session (or wherever the dialog context is stored) is not cleaned up immediately when a window is closed? That is correct at the moment. Notification on window close would require javascript, right? Do you have to use timer for removing unneeded dialog contexts? Or have you opted for something else? We don't have a timer at the moment, but that's a good idea. How do you bind an ID to a window? Of course you can stick it into a link, but what if I open a link that is not intended for a new window, with open in a new window command from a browser? I will not get a window ID, right? There's three different ways that a window can receive a dialog id: * JSF navigation result that begins with a particular prefix * Programmatic call in an event handler (analogous to an Action.execute() method in Struts) * Special request parameter on the URL that says please assign me a new dialog id for dialog x. If none of the above occurs, the new window will not be associated with any dialog id. The third alternative was specifically designed for popups -- the theory is that you'd manufacture the URL that will be used to create the window to include the appropriate dialog name. This approach also allows an additional cability that you can associate the dialog context of the popup window with the dialog context of the parent window that created it. This lets you use JSF expressions to pull data out of the main window and into the popup (at the start of the dialog) and push updated data back at the end -- even if the user has more than one window open running the main dialog. Cookies... I have to look again at how cookies work, but I always thought that all cookies are shared by all browser windows, so I cannot have one cookie assigned to one window, and another cookie assigned to another window. You're right ... that's not going to be a useful option. I should check the source code, but I would appreciate a high-level two-liner before digging in :-) The best overview is on the website[1], but the basic idea is that dialogs are modelled as a state machine composed of intermixed view states (a JSF page that is displayed and then returns a String outcome from the postback call to the action method), action states (JSF method expression call to an arbitrary method, that returns a String), or subdialogs. Transitions between states are driven by the the logical outcome strings. As I mentioned, the code inside shale-core today doesn't do all of this stuff. The shale-dialog2 module in the sandbox is an abstraction of the programmatic interface to the facilities described above, with two implementations on different state machines ... one that is effectively equivalent to the legacy code currently in shale-core, and another that uses Commons SCXML under the covers. (Although this stuff is agnostic about the state machine to be used, it is *not* agnostic about whether JSF is there ... the functionality that drives everything is a custom JSF phase listener and navigation handler combination.) Craig [1] http://shale.apache.org/features-dialog-manager.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Rollover scope for Struts 1.3.x
On 9/14/06, Michael Jouravlev [EMAIL PROTECTED] wrote: Anyone wants to share their thoughts on rollover scope? http://wiki.apache.org/struts/RolloverScope I was thinking on using Stripes approach, but I don't like to mange URLs. Also, Stripes uses a timer to remove unused rollover scopes, this does not seem very straightforward to me, from a user's point of view. A user opens two windows then bam! in two minutes their content is gone. Rollover is an OK term for this ... consider also something like carryover. I agree that two minutes is a bit short, but I could see some benefit in having *some* sort of a timeout be possible. So I decided to go with the simplest implementation possible. It does not allow to open several windows with the same-typed actionform, but it is easy to understand and it works predictably. This seems like the kind of thing that works predictably from the POV of a developer, but not so much from the POV of a user. What do you mean, I can't have two windows open on the same page, but looking at different data -- but it works when I have two windows on different pages?. In Shale, the closest analog to this is Dialog scope, and we're building the concept of a scope instance per window/frame, independent of what that window/frame is actually doing. We get the benefit that JSF is already saving state information per view, so there's no need for the page author to explicitly reference an identifier per window ... but the same concept could be simulated pretty easily with a special view identifier tag that mapped to a particular instance of rollover scope state information. Michael. Craig
Re: [s2] Action ! Method syntax (was Freemarker transform name)
On 8/25/06, Frank W. Zammetti [EMAIL PROTECTED] wrote: It's interesting that no one says DispatchAction in 1.x is a security flaw... doesn't that give you exactly the same thing just with a different call semantic? I guess we should quick drop Dispatch-type Actions for everyones' safety!! ;) LOL The security concern isn't actually around the action execution methods themselves -- as has been pointed out, the whole *purpose* of these methods is to be called by mapping from a URL. Instead, it's around other public methods (perhaps on non-action classes) that happen to have the same parameter signature as your action methods, which enables calls to methods that were not intended to be actions. You can indeed shoot yourself in the foot in this manner even with DispatchAction if you are not careful, although the potential for mischief is somewhat smaller because you can't necessarily point at any arbitrary bean ... only the ones your actions are mapped to. I'm quite interested in how this gets resolved, because Shale Remoting has a similar sort of vulnerabiilty (you can map to arbitrary methods for invoking it's notion of an action), and it gets dinged for this being a security vulnerability as well. I'd like to resolve it in a manner that is conceptually similar to what Struts does, if feasible. Craig
Re: [Fwd: [jira] Updated: (STR-2864) Add actionId attribute to action mapping]
On 8/25/06, Paul Benedict [EMAIL PROTECTED] wrote: From the comments on the issue, it looks like Craig has some reservations about this idea. You might want to add a comment to the issue linking to the relevant mailing list thread(s) from November '05. Craig commented on the issue itself, but Martin must have answered on the mailing list. Have their concerns been addressed? I will add that to the bug report. Yes, those concerns have been addressed because the approach is different then the original idea. (The patch itself has some noise, reordering import statements. Consider committing that separately so it doesn't distract from the actual changes.) Sorry about the re-ordering. I didn't think that would matter because imports come and go as I tried different things. But I guess it does matter. Commits are on a whole file basis, right? So I would have to fix those ordering before committing? FWIW, my concerns about this have become less important in the last ten months, due to the fact that I'm focused on Shale now much more than Struts. It's the active committers on Struts you really need to be concerned with. That being said, I agree with Wendy's advice that cosmetic changes (such as reordering imports) should be segregated into individual commits. Besides the fact that they will almost never engenender discussion (so just do it makes sense as a personal policy), it also makes the review of potentially controversial functional changes much easier, because you don't get distracted by all the cosmetic-change details. Paul Craig
Re: 1.3.x: Action Aliasing
On 8/23/06, Paul Benedict [EMAIL PROTECTED] wrote: Ted Husted wrote: Use action-id then. The point is that moniker alias is going to cause confusion, since it already means something entirely different within the Struts 2 community. Right now attributes are squarely mapped to properties. Java does not allow dashes in a property name, so what is a workaround? One way to deal with this would be to provide your own BeanInfo class that defined a property named action-id with the getter and setter methods that you want to use. That way, the JavaBeans introspection logic would use your setter method, instead of not recognizing this as a property. But that's likely to be too painful for this kind of use. The other approach, if you're using something like Digester (which is true at least for S1) to parse the config file, is to define an explicit rule that calls the right setter if there is an attribute with a specified name. Craig
Re: Test
Yep. Craig On 8/22/06, Paul Benedict [EMAIL PROTECTED] wrote: This is a test. Can anyone read this? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JIRA - Closing Releases
On 8/19/06, Paul Benedict [EMAIL PROTECTED] wrote: I am pleased to announce that Struts 0.5 in JIRA has been released :) Sniff, sniff, ... we're *so* proud :-). And they say those Struts developers never actually get around to releasing things :-). hehe. Everything looks good! I will release the other versions now up to 1.3.4 so our JIRA roadmap looks up to date. Thanks Paul. Paul Craig - How low will we go? Check out Yahoo! Messenger's low PC-to-Phone call rates.
Re: Reg Struts-Shale
On 8/3/06, Jeevan Kumar Kade [EMAIL PROTECTED] wrote: Hi, Is there is major differeence between Struts-Shale framework and JSF. Please, categorize and differentiate on this. Shale has moved to its own top level Apache project with its own mailing lists[1] ... this would be a good question for the user list there. But, in short, Shale is a framework that extends JSF and adds additional functionality and ease of use. The basic features are listed on the Shale web site[2]. Thanks in Advance Jeevan Kumar Craig [1] http://shale.apache.org/mail-lists.html [2] http://shale.apache.org/
Re: [s2] Sping WebFlow Integration
On 7/26/06, Alexandru Popescu [EMAIL PROTECTED] wrote: What is SWF? I might have missed this acro :-[. SWF == Spring Web Flow http://opensource.atlassian.com/confluence/spring/display/WEBFLOW/Home ./alex Craig
Re: Distribution Directories
On 7/16/06, Ted Husted [EMAIL PROTECTED] wrote: Otherwise, it's tagged, rolled, and uploaded. +1 on the 1.3.5 bits. A couple of notes below that I don't consider fatal to the release: * The all release (currently 40mb) is not really scalable to large numbers of sample apps, due to the duplication of dependency jars across the apps. It might be worth considering a different release strategy for sample apps for 2.x, but that is not really relevant here. * The #1 struts-faces example app has embedded the storyboard stuff for the standard Struts mail reader app, which should really be updated for the differences with JSF (or simply deleted for now) * The JAR files in the lib directory of the all distribution do not include the X-* source and target extension settings that are typical for recent Jakarta Commons releases (although Build-Jdk conveys some of that information). -Ted. Craig
Re: Distribution Directories
On 7/16/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 7/16/06, Wendy Smoak [EMAIL PROTECTED] wrote: Both distributionManagement/repository and distributionManagement/snapshotRepository are pointed to the same place (people.apache.org/maven-snapshot-repository) Just to avoid confusion: right now on minotaur, /www/cvs.apache.org is symlinked to /www/people.apache.org . We should switch everything over to people.a.o eventually, but for the moment it doesn't matter. I can't guarantee that it's universal, but this *has* matterred for me in a couple of cases ... particularly in trying to do builds of things like MyFaces that have POMs pointing at a Maven repository on cvs.apache.org. I get timeouts on the Maven dependency downloads from this hostname, while they work fine from people.apache.org. I'd recommend that we at least get the names correct in our own POMs before posting the release. Craig -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Distribution Directories
On 7/16/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 7/16/06, Craig McClanahan [EMAIL PROTECTED] wrote: I can't guarantee that it's universal, but this *has* matterred for me in a couple of cases ... particularly in trying to do builds of things like MyFaces that have POMs pointing at a Maven repository on cvs.apache.org . I get timeouts on the Maven dependency downloads from this hostname, while they work fine from people.apache.org. There is a redirect in place from http://cvs.apache.org/maven-snapshot-repository to http://people.apache.org/maven-snapshot-repository. Do you only have trouble when you're behind a proxy? Previously, it was failing either with or without a proxy. Just tried it again, though, and it's working now ... so it might have been a transient issue. I'd recommend that we at least get the names correct in our own POMs before posting the release. The Struts 1 parent pom does use people.apache.org in the repository/url, so it should be fine for downloads. I was talking about deployment, where scp'ing something to /www/cvs.apache.org or /www/people.apache.org is one and the same. That (distributionManagement) is defined in the struts-master pom, and can be fixed next time around in v4. That also affects where Maven looks for dependencies, if you are *using* Struts 1.3.5, right? But as long as it doesn't mess anything up, I agree it can wait for v4. -- Wendy Craig
Proposed Board Report
As part of our transition to an Apache top level project (TLP), we are obligated to submit a report to the ASF Board every month for the first three months, then quarterly thereafter. Here's what I am proposing to send for July, which needs to be forwarded in a couple days. (I'll also create a pmc subdirectory in the repository to archive these things, since there is nothing non-public we need to worry about). Comments? === Apache Shale Board Report for July 2006 === Overview Per the Apache Board resolution at the June 2006 meeting, Apache Shale was created as a top level project. This is the first of the every month for the first three months status reports to the Board on activities within the project. All of the initial root and infrastructure requests have been completed. We are still de-tangling a few loose ends (wiki and JIRA instance shared with the Struts project), but these are not considered to be urgent. PMC and Committer Changes - None. Current Development Activities -- As the creation of Shale as a TLP was coming to fruition, we had nearly completed a migration to a Maven2 based build environment. This work has been substantially completed, and Shale is now completely M2 based for its build infrastructure. Nightly builds are still currently hosted on my (Craig's) home desktop, but steps are underway to migrate this to a Continuum instance on Apache infrastructure. We have initiated a contest to pick an official logo for the Apache Shale project -- details are at http://wiki.apache.org/shale/LogoContest. The entries so far have ranged from humorous to compelling ... it will be interesting to pick a final winner. Current release activities are focused on a 1.0.3 release, which is still likely to be considered beta quality (due to dependence on unreleased components, plus some outstanding bugs), but which has been requested by some downstream users to avoid their need to depend on snapshots. Submitted by, Craig McClanahan
Re: Proposed Board Report
On 7/16/06, Ted Husted [EMAIL PROTECTED] wrote: Did you mean to send this to the Shale dev@, Craig? Yep ... sorry for the noise :-) Craig On 7/17/06, Craig McClanahan [EMAIL PROTECTED] wrote: As part of our transition to an Apache top level project (TLP), we are obligated to submit a report to the ASF Board every month for the first three months, then quarterly thereafter. Here's what I am proposing to send for July, which needs to be forwarded in a couple days. (I'll also create a pmc subdirectory in the repository to archive these things, since there is nothing non-public we need to worry about). Comments? === Apache Shale Board Report for July 2006 === Overview Per the Apache Board resolution at the June 2006 meeting, Apache Shale was created as a top level project. This is the first of the every month for the first three months status reports to the Board on activities within the project. All of the initial root and infrastructure requests have been completed. We are still de-tangling a few loose ends (wiki and JIRA instance shared with the Struts project), but these are not considered to be urgent. PMC and Committer Changes - None. Current Development Activities -- As the creation of Shale as a TLP was coming to fruition, we had nearly completed a migration to a Maven2 based build environment. This work has been substantially completed, and Shale is now completely M2 based for its build infrastructure. Nightly builds are still currently hosted on my (Craig's) home desktop, but steps are underway to migrate this to a Continuum instance on Apache infrastructure. We have initiated a contest to pick an official logo for the Apache Shale project -- details are at http://wiki.apache.org/shale/LogoContest . The entries so far have ranged from humorous to compelling ... it will be interesting to pick a final winner. Current release activities are focused on a 1.0.3 release, which is still likely to be considered beta quality (due to dependence on unreleased components, plus some outstanding bugs), but which has been requested by some downstream users to avoid their need to depend on snapshots. Submitted by, Craig McClanahan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Would like to remove Ant build from Struts 2
On 7/10/06, Jason Carreira [EMAIL PROTECTED] wrote: +1 for this I'm surprised Maven can't build a source distribution with a bundled standard ant build with maven dependency ant task calls. I'd think this would be a common need. A lot of Jakarta Commons projects deal with this sort of thing by having a developer run mvn ant:ant to create a build.xml that (in theory at least) replicates the functionality of the current Maven build environment, and then check that in. It seems to work fairly well on simple single module projects like your typical Commons library ... but I've never tried it in something as complicated as our build systems. Craig The one case I wouldn't mind seeing an Ant build is in the source distribution. Many times, I'm downloading source distros, and have to make some change, but 'm on a network where I don't have connectivity to the outside world. If we could make a source distro that was completely self-contained, complete with an Ant build, I'd be fine with that. Don - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=36712messageID=72369#72369 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANNOUNCE][SHALE] Apache Shale Top Level Project Is Now Up And Running
You might have seen the recent announcement that Apache Shale, originally developed as part of the Apache Struts project, has been approved as an Apache top level project of its own. This message is an announcement that the project resources are now completely set up (thanks to the prompt attention of the Apache infrastructure team), and ready for use: Project Web Site: http://shale.apache.org/ Project Wiki Site: http://wiki.apache.org/shale/ Mailing List Information / Subscription / Archive Links: http://shale.apache.org/mail-lists.html Nightly Builds: http://people.apache.org/builds/shale/ On the web site, you will notice that there is, as of yet, no logo for the project. In fact, we would really like two images -- one for the web site logo, and a Powered By Shale logo that can optionally be included by web applications built with Shale. As someone who can barely draw a rectangle with straight lines, this seems like the perfect opportunity to get the community involved in a design ... so we're going to have a logo contest. Read about it on our wiki page, and submit your creative ideas there: http://wiki.apache.org/shale/LogoContest then, join the Shale User mailing list and root for your favorites. Craig McClanahan
Re: Sharing code between versions (was [jira] Created: (STR-2898) Rename Struts Action 1 to Struts 1)
On 7/6/06, Don Brown [EMAIL PROTECTED] wrote: I'd be fine with a shared module, as long as releases could be quicker and easier. As I've previously mentioned, Struts releases are really a pain due to lack of committer support and a broken release process, and I certainly don't want to put a roadblock in the path of a stable Struts 2.0 release. For one or two shared classes, I'd agree with Don that it's not worth the pain. If you anticipate 20+ shared classes, it starts to get more interesting (but still a bunch of work). Don Craig Craig McClanahan wrote: On 7/5/06, Don Brown [EMAIL PROTECTED] wrote: Good question. Here are the options of the top of my head: - Jakarta Commons project - Put it in Struts 1.x, since Struts 2 will probably have 1 has a dep for migration code - Create new Struts Commons - Just have two copies of the code FWIW, the MyFaces folks have gone through the same sort of discussion recently, trying to decide whether/how to share code between the JSF implementation and the component classes. The hardest part of the whole thing is actually synchronizing releases of the helper classes, since both framework versions would have dependencies on the common stuff. They ended up with a variation of the third approach -- a shared module in the MyFaces repository that both things could depend on. Craig To be honest, I lean towards the last option, unless the code is large enough to warrant the first. For example, Struts 1 has WildcardHelper, but so does XWork 2.0 (used by Struts 2) and it all came from Cocoon. Cocoon recently rewrote the class, so I'll need to bring over the changes into those two new projects. Sure, that is a bit of work, but not in comparison to starting a new project just for that class. Don Paul Benedict wrote: A thought occured to me today. If we ever want to share code between struts 1 and struts 2c (ie: locale resolution), having the org.apache.struts package structure being the neutral place makes sense, with action (1.x) and action2 (2.x) being specific implementations. Well, not that the renaming is done, I think we have no normal way of sharing code across packages. Thoughts? -- Paul Ted Husted [EMAIL PROTECTED] wrote: On 7/1/06, Don Brown (JIRA) wrote: Rename Struts Action 1 to Struts 1 If we are using struts1 and struts2 for the repository folders (which is fine with me), why are we using 1.x and 2.0 for the website folders? * http://struts.apache.org/1.x/ * http://struts.apache.org/2.0/ In the view of convention over configuration, I feel we we should work toward using a consistent set of conventions across tools. If there is not a technical reason why we need to use symbols, I'd like to use struts1 and struts2 for the website folders. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Want to be your own boss? Learn how on Yahoo! Small Business. - 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: Sharing code between versions (was [jira] Created: (STR-2898) Rename Struts Action 1 to Struts 1)
On 7/5/06, Don Brown [EMAIL PROTECTED] wrote: Good question. Here are the options of the top of my head: - Jakarta Commons project - Put it in Struts 1.x, since Struts 2 will probably have 1 has a dep for migration code - Create new Struts Commons - Just have two copies of the code FWIW, the MyFaces folks have gone through the same sort of discussion recently, trying to decide whether/how to share code between the JSF implementation and the component classes. The hardest part of the whole thing is actually synchronizing releases of the helper classes, since both framework versions would have dependencies on the common stuff. They ended up with a variation of the third approach -- a shared module in the MyFaces repository that both things could depend on. Craig To be honest, I lean towards the last option, unless the code is large enough to warrant the first. For example, Struts 1 has WildcardHelper, but so does XWork 2.0 (used by Struts 2) and it all came from Cocoon. Cocoon recently rewrote the class, so I'll need to bring over the changes into those two new projects. Sure, that is a bit of work, but not in comparison to starting a new project just for that class. Don Paul Benedict wrote: A thought occured to me today. If we ever want to share code between struts 1 and struts 2c (ie: locale resolution), having the org.apache.struts package structure being the neutral place makes sense, with action (1.x) and action2 (2.x) being specific implementations. Well, not that the renaming is done, I think we have no normal way of sharing code across packages. Thoughts? -- Paul Ted Husted [EMAIL PROTECTED] wrote: On 7/1/06, Don Brown (JIRA) wrote: Rename Struts Action 1 to Struts 1 If we are using struts1 and struts2 for the repository folders (which is fine with me), why are we using 1.x and 2.0 for the website folders? * http://struts.apache.org/1.x/ * http://struts.apache.org/2.0/ In the view of convention over configuration, I feel we we should work toward using a consistent set of conventions across tools. If there is not a technical reason why we need to use symbols, I'd like to use struts1 and struts2 for the website folders. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Want to be your own boss? Learn how on Yahoo! Small Business. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[shale] Genericizing Cargo-Based Integration Tests
The CargoTestSetup class that you added to the test framework (was this Wendy's first commit of Java code? :-) nicely leverages the fact that Cargo will figure out which container to use based on system properties (specifically cargo.container.id). However, the way that this class is being used in Tomcat5xWelcomeTestCase in the shale-blank application is definitely not container-agnostic, because it presumes to use Tomcat 5.x. I'd like to write our tests so that they dynamically adapt to whatever Cargo Container the user has selected in their ~/.m2/settings.xml file. So, the question is, does the following strategy make sense? * Set up default cargo properties in the POM for a particular application (defauting to tomcat5x makes sense). * Allow the user to override these by setting up their favorite container in ~/.m2/settings.xml (presumes that user settings override POM settings) * Change the shale-blank tests to not bother trying to pass through any Tomcat specific properties -- instead, they should assume that all the required cargo.* propertes have been set up by the surrounding environment already. If this works out, it will make sense to replicate this model in the other apps that have integration tests, as well as into the archetype(s) for new applications. Craig
Re: [PROPOSAL] Rename Struts Action as Struts
On 6/28/06, Martin Cooper [EMAIL PROTECTED] wrote: On 6/28/06, Don Brown [EMAIL PROTECTED] wrote: Ted Husted wrote: Though, there's no reason why we couldn't use repos/asf/struts/struts1 repos/asf/struts/struts2 Or repos/asf/struts/framework repos/asf/struts/framework2 I like struts1/struts2. Yep, I do too. It's simple and straighforward - the best way to minimise confusion and make it obvious what goes where. +1. If we're not going to go with codename identifiers (although I'm personally partial to that ... all the Creator releases have had shark-themed names :-), then struts1/struts2 makes a lot of sense. The generational theme resonates, and encourages the correct amount of forethought before making substantively backwards incompatible changes. -- Martin Cooper Craig
Re: Live DTDs
On 6/26/06, James Mitchell [EMAIL PROTECTED] wrote: So, if this became a Maven 2 plugin, would anyone have a problem with us adding it to the nightly build? +1 from me if the necessary stuff is available in Maven repositories. -- James Mitchell Craig On Jun 26, 2006, at 12:32 AM, Craig McClanahan wrote: On 6/25/06, James Mitchell [EMAIL PROTECTED] wrote: Sounds like something we could run nightly from the zone. Yes, it could ... but if we care about it, this really needs to be part of the standard build process somehow. Personally, I find the existing DTDs themselves (which are *very* thoroughly commented) to be quite readable on their own, and they are already available both online and as part of the build -- so having the indexed version is a nice-to-have, not a mission critical feature, IMHO. -- James Mitchell Craig On Jun 26, 2006, at 12:19 AM, Wendy Smoak wrote: On 6/25/06, Paul Benedict [EMAIL PROTECTED] wrote: Didn't you say you didn't want to support the live dtd? My browsers can never show a DTD, it seems; they try always parse it as XML which fails of course. So that's why I recommend a plain- text version of it online. No, I said that currently I'm the only one who has volunteered to keep the LiveDTD docs updated. If someone else will help, then I'd feel more comfortable about making those links more prominent on the website. It's not hard, but it is outside of the Maven 2 website build. Having a plain text version under s.a.o/struts-action is fine, it just needs to happen at build time, not as something that gets checked into svn. Try binding an execution of the antrun plugin in action/ pom.xml, that's the only thing I've found that will copy files in a Maven build. There should be an example in the webapp poms, I know we copy the source into the webapps with antrun. Another option is switching to DTD Doc, which is Java so it shouldn't be too hard to write a m2 plugin for it. That looks like it requires modifications to the source DTDs, though. -- Wendy - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Live DTDs
On 6/25/06, James Mitchell [EMAIL PROTECTED] wrote: Sounds like something we could run nightly from the zone. Yes, it could ... but if we care about it, this really needs to be part of the standard build process somehow. Personally, I find the existing DTDs themselves (which are *very* thoroughly commented) to be quite readable on their own, and they are already available both online and as part of the build -- so having the indexed version is a nice-to-have, not a mission critical feature, IMHO. -- James Mitchell Craig On Jun 26, 2006, at 12:19 AM, Wendy Smoak wrote: On 6/25/06, Paul Benedict [EMAIL PROTECTED] wrote: Didn't you say you didn't want to support the live dtd? My browsers can never show a DTD, it seems; they try always parse it as XML which fails of course. So that's why I recommend a plain- text version of it online. No, I said that currently I'm the only one who has volunteered to keep the LiveDTD docs updated. If someone else will help, then I'd feel more comfortable about making those links more prominent on the website. It's not hard, but it is outside of the Maven 2 website build. Having a plain text version under s.a.o/struts-action is fine, it just needs to happen at build time, not as something that gets checked into svn. Try binding an execution of the antrun plugin in action/pom.xml, that's the only thing I've found that will copy files in a Maven build. There should be an example in the webapp poms, I know we copy the source into the webapps with antrun. Another option is switching to DTD Doc, which is Java so it shouldn't be too hard to write a m2 plugin for it. That looks like it requires modifications to the source DTDs, though. -- Wendy - 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: Does Struts really need two frameworks? (long)
). You won't hear any whining about the fundamentals from me of SAF2 -- although I reserve the right to comment on the details :-) But, for new developers, I prefer to think of action-oriented frameworks as been there, done that. The understanding of O-O concepts, and the willingness to code things in configuration files (I *hope* you guys are thinking about annotations for things like Preparable :-) you need to really leverage all the cool stuff that SAF2 includes is far too limiting for my vision of what Java as a platform needs to do in the future. I want to focus on attracting a much larger audience of developers who are *not* O-O professionals, whose idea of code reuse is cut-n-paste, and who might actually prefer to use tools (SAF2's fundamental architecture is pretty much untoolable, even if someone were motivated to spend the effort to build tooling around it). For the O-O bigots around this mailing list, I can take comfort in the fact that the audience I'm interested in is *many times* the size of the audience that will actually appreciate the technical elegance in SAF2. Or, if you want it all in one sentence: for new developers, I would much prefer to compete with SAF2 than to cooperate with it. If that means a (hopefully amicable) divorce, then so be it. SAF2 is a much better (technical) approach to the problems that Struts 1.x targeted, but the world has moved beyond those problems. I'm no longer interested in playing on that particular playground. Craig McClanahan On 6/20/06, Don Brown [EMAIL PROTECTED] wrote: As Shale and Action zero in on their first GA release, I don't think it is too late to ask the question, Does Struts really need two frameworks? We have been putting out the message, two frameworks, one community, for almost a year now, but I still sense a lot of confusion and even rejection from the Struts community. The problem is for our whole history, Struts was a single framework, what you went to if you wanted to structure your web application according to Model2 principles. Our attempts to turn Struts into an umbrella project, I feel, have failed. Struts Action 2 is seen, by some, as a simple rebranding of WebWork 2, and to be honest, it really is at this stage. Struts Shale is seen as non-sequitur, milking the Struts brand name. While these opinions are most extremely expressed by our more radical members, they are also held to some degree by some very smart, sensible people [1]. From a Struts committer perspective, Wendy made a good point to me the other day saying that Struts lacks the single purpose or vision of most Open Source projects. Despite our recent attempts to find common ground, Shale and Action are still positioned as competing frameworks with no overlap. This division leads to conflicts that suck the joy out of Open Source development. Recently, Struts Action 2 unified the programming models of action-based and component-based development by allowing the developer to adopt an action-based approach for an application, yet use JSF components and abilities where needed. We have always said the desired end state would be to return Struts into a unified framework, and I think we should jump on this chance now. I propose Struts return to its roots as a unified framework through building on three libraries to make JSF and pure Servlet/JSP development easier. Namely, I propose the Struts project to be the following subprojects, each with their own release cycle: - Framework: Struts 2 - Libraries: Struts Action, Shale and Struts Tags Struts would be the single framework the world would see. It would contain support for Action-based, JSF-based, and hybrid applications. Its documentation would promote the Struts Action controller as the preferred entry point, even if only to be used for AJAX services. Its JSF library, Struts Shale, however, could be used with a regular FacesServlet. JSF components and Struts Tags would be equals when describing how to tackle the View of an application. Struts Action would be the core library driving Struts 2, replace Struts 1.x. This library would be everything now known as Struts Action 2, but without the UI components. We would aim for a solid Action-based library independent of the view, much like Action 1.x. When we talked about what an Action JSR would look like, this would be it. Struts Shale would be repositioned as a library, which I think is a better fit. A framework to me is a comprehensive, one-stop-shop solution to create an application. A library is a collection of independent features that can be used in piecemeal. Therefore, I think a library is a better definition for Shale's collection of JSF extensions. While Struts Action would definitely support Shale, it would continue to be able to be used with pure JSF applications. Struts Tags would be the WebWork UI components, a library of re-usable, stateless tags that can be used in Velocity, Freemarker, or JSP. They would include
Re: Does Struts really need two frameworks? (long)
Comments interspersed. On 6/21/06, Don Brown [EMAIL PROTECTED] wrote: Craig, thanks for your honesty and candor. I know this is a delicate topic, and I appreciate you approaching the topic openly. LIkewise ... I may have sounded a bit grumpy in my response, but I don't ascribe any malicious intent to your proposal. A couple of clarifications: 1. I'm not proposing Shale _ever_ depend on Action 2, only that they should work well together. In fact, I mean to start including Shale in Action 2's web examples. In principle, that should work already for some things like ViewController, (but, if I read the current navigation handler right, you're not delegating so the dialog facility of Shale will not operate correctly at the moment). Proof is in the pudding of course, by actually writing such a sample app. 2. In a pure JSF environment, don't you think there is value in using an Action 2 controller to handle things like JSON/XML remote services? I'm finding more and more my Struts Actions return JSON rather than HTML. This is how I see us working together even if you don't use Action 2's JSF support. Two separate thoughts on this: * Technically, having an Action2 type handler for these things is certainly feasible, but not required. Shale Remoting does the same sorts of things for resource access, and supports dynamically mapping dynamic requests to an arbitrary method on a managed bean (i.e. it gets instantiated on demand and dependency injected), using standard JSF facilities, already. And it takes zero configuration if you like the default mapping algorithm. (Adding xwork interceptor chains around the call to the dynamic handler methods will be an easy add-on to this, for those who like that approach to providing services to the handler.) * Philosophically, a framework built around JSF should encourage the developer to use facilities that are already there, so he or she will not need to learn new concepts. That's why Shale does things like using method binding expressions to configure actions in the dialog subsystem ... binding an asynchronous callback is done exactly the same as binding a submit button to an action method (execute() in action framework terminology). Nothing new to learn. Leverages the managed beans facility exactly the same way. Easily usable by a JSF component itself that wants to encapsulate AJAX behavior or by client side JavaScript provided by the application. 3. Overlap areas like navigation, validation, messages, etc., are only waiting on attention to be resolved. When using the Action 2 navigation, it is my intention that the default configuration removes overlap as much as possible. You'd use Action 2 navigation rather than the NavigationHandler. Validations could be defined in the page or could automatically be created from existing Action 2 validations (XML or annotations), similarly to how Seam creates validations from annotations. Messages integration is easily resolved by creating a backing bean that provides messages using Action 2 apis. I fully believe it is possible to merge Action 2 and JSF into a web application in a seamless manner. There is a lot of space for implementing common frameworks we can share for doing things like validation -- for example, at JavaOne we talked a bit about a Commons Validator 2.0 that could derive validation rules from annotations. But, at the end of the day, you still need different mechanisms to embed the particular annotations into the UI toolkit you're using (the UI tags in SAF, or the component tags in JSF). For navigation, you'd use Action 2 navigation rather than navigation handler means that you're giving up on the tools around for JSF navigation, and forcing a beginner that is reading a JSF book to ignore that chapter and learn something different. We'll want to look at how the existing SAF2 navigation handler can delegate for scenarios where the developer wants to use JSF navigation for some namespaces. It's definitely possible to merge Action 2 and JSF in an application -- you've already done that. That's a tremendous benefit for the migration use cases, or those that just want to sprinkle some components without migrating. For a new application, though, I don't care for the result, because it adds complexity (over pure JSF based solutions), and requires deveopers to deal with additional concepts and configuration files, without enough corresonding benefits to make it worth it (IMHO, of course). I guess what I'm saying is you could view this overlap in a negative or positive light. I think the Struts project should put forth a preferred approach, used in our quickstarts and tutorials. However, that doesn't mean that we should force developers into our way of thinking. Having options isn't necessarily bad. At this point, I really don't see a valid either/or framework approach debate: - If your application needs to be built by tool-dependent programmers, pure JSF
Re: Does Struts really need two frameworks? (long)
On 6/21/06, Don Brown [EMAIL PROTECTED] wrote: I'm suggesting something bigger: Struts 2.0. This release will come with SAF2, Shale, Tags, and maybe Action 1.x for legacy reasons. We would continue to develop SAF2, Shale, and Tags, but the world would just need to see Struts 2.0. Its documentation will tie the projects together and provide coherent advice on how to write a simple application (using Action 2 and either Action 2 tags or JSF) to when to use what library where. This release would be the one-stop-shop for users wanting to use the latest Struts has to offer. It goes back to Struts' roots as a single solution for web development needs. Would you anticipate the bundling would just be the latest and greatest released version of each piece or some sort of coordinated simultaneous releases? The latter doesn't sound feasible, given our track record with getting things out quickly even by themselves :-). Don Craig Ted Husted wrote: On 6/21/06, Don Brown [EMAIL PROTECTED] wrote: And this is why Shale needs to continue, and I'd argue, continue to exist as part of the larger Struts community, and a step further, under a larger Struts 2.0 product. I think despite providing multiple alternatives and solutions, there is a common narrative we can weave to create a unified Struts project. So, in addition to including the Action 1.3 JARs in the SAF 2.0 release, essentially, you are suggesting that we also include the Shale 1.x JARs in the same distribution, so that anyone obtaining SAF2 can use Action 1, Action 2, and/or Shale 1? -Ted. - 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: Continnum Is Up
On 6/19/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 6/14/06, James Mitchell [EMAIL PROTECTED] wrote: Yes. There is a wiki page for this as well. http://wiki.apache.org/struts/StrutsContinuum It's a work in progress, and I'm about to head out, but I'd like to ask Wendy a few questions wrt pom, parent-pom, snapshot vs. released, etc, etc. Back in a bit. That was a few days ago. :) Craig, are you ready to get Shale set up on Continuum? I am. Shale's trunk is now the Maven2 build, as you are well aware :-), so it should be ready to go. I assume you'd like to get out of the nightly builds business, and have them run from the zone. That would be great. I've also cut-n-pasted below the shell script I'm currently experimenting with ... it updates the snapshot repository as well as posting all the nightly build artifacts (the output is piped to a date-stamped HTML page): #!/bin/sh # == # buildShaleNightlyMaven -- Shale Nightly Builds (with Maven) # == # == # Setup # == export BUILD_HOME=/home/craigmcc/Build export CLASSPATH=. export TSTAMP=`date +%Y%m%d` echo \html\ echo \head\ echo \title\Shale Nightly Build \(with Maven\) For $TSTAMP\/title\ echo \/head\ echo \body\ echo \h1\Shale Nightly Build \(with Maven\) For $TSTAMP\/h1\ # == # Update From Subversion Repository # == echo \h2\Update From Subversion Repository\/h2\ cd $BUILD_HOME/struts/current/shale echo \pre\ svn update echo \/pre\ # == # Build and Deploy Framework Artifaces # == echo \h2\Build and Deploy Framework Artifacts\/h2\ cd $BUILD_HOME/struts/current/shale echo \pre\ mvn clean site install deploy cd shale-apps mvn deploy -N cd .. cd shale-dist mvn assembly:assembly scp target/assembly/out/shale-framework-*.tar.gz \ [EMAIL PROTECTED] :/www/cvs.apache.org/builds/struts/maven2/shale/shale-framework-$TSTAMP.tar.gz scp target/assembly/out/shale-framework-*.zip \ [EMAIL PROTECTED] :/www/cvs.apache.org/builds/struts/maven2/shale/shale-framework-$TSTAMP.zip cd .. echo \/pre\ # == # Build and Deploy Sample Application Artifacts # == echo \h2\Build and Deploy Sample Application Artifacts\/h2\ cd $BUILD_HOME/struts/current/shale/shale-apps export APPS=shale-blank shale-clay-usecases shale-mailreader export APPS=$APPS shale-sql-browser shale-usecases for APP in $APPS; do cd $APP echo \h3\Processing sample application $APP\/h3\ echo \pre\ mvn clean install deploy assembly:assembly scp target/$APP-*.tar.gz \ [EMAIL PROTECTED] :/www/cvs.apache.org/builds/struts/maven2/shale/$APP-$TSTAMP.tar.gz scp target/$APP-*.zip \ [EMAIL PROTECTED] :/www/cvs.apache.org/builds/struts/maven2/shale/$APP-$TSTAMP.zip echo \/pre\ cd .. done # == # Finish Up # == echo \h2\Job Completed\/h2\ echo \/body\ echo \/html\ In another thread, I think Sean mentioned it's ready to start adding things. Cool ... if you guys want to set me up as a user no the zone machine as well (preferably with user id craigmcc) I can help out directly as well. I started to update the Shale site yesterday, but I need to know where the nightly builds/snapshots are going to be so I can link to them. As you can see from the script above, I started putting them in /www/cvs.apache.org/builds/struts/maven2/shale, figuring we could do parallel updates for action into /www/cvs.apache.org/builds/struts/maven2/action and so on. Thanks, -- Wendy Craig
Re: [all] Struts Nightly builds [was Re: Continnum Is Up]
On 6/19/06, James Mitchell [EMAIL PROTECTED] wrote: Wonderful timing, I was just about to start a new thread wrt getting the nightlies back online. And so I'll move my thoughts here. So, with the mini hackathon out of the way, and our new buddy MrStruts taking care of the continuous integration for us (ok, he isn't doing much right now, but he is there and ready to roll), I'd like to turn at least some of my attention to getting the nightlies back online. Sorry if this was already discussed/decided on a different thread, I'm behind on every list I am currently subscribed to, except [EMAIL PROTECTED] I plan to have MrStruts do full nightly builds using a similar nightly script to the one I was using for many months with the Maven 1 built nightlies. I'm in the process (as I type this) of creating the necessary build scripts to produce nightly artifacts of Struts Action 1 (1.2.x and 1.3.x), Struts Action 2, and Shale. Currently, we publish the nightlies here: http://people.apache.org/builds/struts/ ...and I see Craig has begun publishing Shale nightlies to this spot: http://people.apache.org/builds/struts/maven2/shale/ So, on that note, I'll begin publishing Action 1 and 2 nightlies in a (almost) similar fashion. Craig, I've already zapped the 'maven' directory, can we: 1. remove the extra directory 'maven2' and just have p.a.o/builds/ struts/shale (requires you to change your scp script)? 2. rm -fr 'nightly' from the same dir? Not a problem ... I'll switch for tonight's build. Indeed, I hadn't announced the destination until we had a chance to coordinate across the various builds. I published my shell script from before this change in an earlier response to Wendy's questions ... it's four simple substitutions. So, (high level) we would have: http://people.apache.org/builds/struts/shale http://people.apache.org/builds/struts/action1/1.2.x/ http://people.apache.org/builds/struts/action1/1.3.x/ http://people.apache.org/builds/struts/action2 http://people.apache.org/builds/struts/tiles (eventually) ...and each directory (Maven 2 built) would have a directory for the particular module, which would have the current jar, war, or zip, and 6 days prior. How does this sound? Sounds good, but I've got some additional thoughts that I would like to see us implement consistently. * In addition to publishing artifacts in this directory, I'm also updating the snapshots for all the poms and jars. That way, people who like to live dangerously :-) and have dependencies on the HEAD code effectively get daily updates, without having to manually check out the sources and rebuild them. * I succumbed to my historical habits :-) and produced both .zip and .tar.gz versions of the artifacts. I'd be open to publishing only in zip format since it's pretty universal, and we don't particularly care about file permissions in what we publish (i.e. no executables to worry about). * I'm really happy with the way that the assemblies constructed by the Shale build scripts (both for the framework itself, and for each individual sample app) are themselves buildable if you have Maven2 installed. This kind of thing will encourage others to get on the bandwagon (listen to me, the latecomer :-), even if they don't want to try to download and build the framework itself from Subversion. I'd like to see this approach implemented consistently across our artifacts. * I'm not so happy with the lukewarm support Maven2 currently offers for integration testing. Wendy got inspired by some comments on the user mailling list for Maven, though, and created a nice workaround in the poms for the Shale sample apps. If you do something like: mvn install -Pitest then you can run the system integration tests built into the same project, rather than having to set up a parallel project for those tests. Shale's integration tests happen to be built with HtmlUnit, but it should be equally feasible to use Canoo or whatever else you like. We're also leveraging the Cargo plugin to even start and stop your favorite container for you. Craig Wendy wrote: That was a few days ago. :) Yes, I know, I never got back to this. Sorry, it's been a heck of a month this week ;) My questions would have been about the POM changes that Sean eluded to during our mini hackathon. I could be wrong, but I thought he said there would be an issue with something we needed and it not being published yet and that may or may not have stemmed from a private conversation you may or may not have had over IM. Sorry, the details are still a little cloudy. Forget about it for now, I'm sure if it's a problem we'll know as soon as we begin adding more projects to Continuum. -- James Mitchell On Jun 19, 2006, at 9:20 PM, Wendy Smoak wrote: On 6/14/06, James Mitchell [EMAIL PROTECTED] wrote: Yes. There is a wiki page for this as well. http://wiki.apache.org/struts/StrutsContinuum It's a work in progress, and I'm
Re: Continnum Is Up
On 6/19/06, James Mitchell [EMAIL PROTECTED] wrote: Done. Password set to cryptic default and will be mailed to your privately. What address would you to receive it on? [EMAIL PROTECTED] ?? Yep. Thanks. -- James Mitchell Craig On Jun 20, 2006, at 12:54 AM, Craig McClanahan wrote: Cool ... if you guys want to set me up as a user no the zone machine as well (preferably with user id craigmcc) I can help out directly as well. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [shale] Maven Reorganization Status and a request for help
On 6/15/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 6/15/06, Craig McClanahan [EMAIL PROTECTED] wrote: That did it. Thanks. Except for the file permissions... when you have a minute, can you log in and fix them? Done. And if anyone knows how to convince it to set the group writeable bit when you scp files up, I'd love to know. (Yes, my umask is set to 002. That doesn't help-- it only masks off the world writeable bit, it doesn't add the group writeable bit.) That's strange ... mine is too. And it did the right thing on deploying everything in the framework space. Maven deploy plugin bug? By the way, you've got a least one set of permissions to change as well ... org/apache/struts/shale/struts-archetype-shale-blank/1.0-SNAPSHOT/ -- Wendy Craig
Re: [shale] Maven Reorganization Status and a request for help
On 6/15/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 6/15/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 6/15/06, Craig McClanahan [EMAIL PROTECTED] wrote: That did it. Thanks. Except for the file permissions... when you have a minute, can you log in and fix them? Done. And if anyone knows how to convince it to set the group writeable bit when you scp files up, I'd love to know. (Yes, my umask is set to 002. That doesn't help-- it only masks off the world writeable bit, it doesn't add the group writeable bit.) That's strange ... mine is too. And it did the right thing on deploying everything in the framework space. Maven deploy plugin bug? Further info ... it didn't get the shale-parent POM correct either. Maybe it is something specific to deploying things with a packaging setting of pom. Craig By the way, you've got a least one set of permissions to change as well ... org/apache/struts/shale/struts-archetype-shale-blank/1.0-SNAPSHOT/ -- Wendy Craig
Re: [shale] Maven Reorganization Status and a request for help
On 6/15/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 6/15/06, Craig McClanahan [EMAIL PROTECTED] wrote: Further info ... it didn't get the shale-parent POM correct either. Maybe it is something specific to deploying things with a packaging setting of pom. Are you still talking about permissions, or is there something wrong with the content? Sorry ... it is still the permissions. They were set to 622 instead of 662 on the shale-parent POM, which was uploaded as part of my deploy of the overall framework. I knew I'd seen this somewhere. In settings.xml, lets try server/filePermissions and server/directoryPermissions. * http://maven.apache.org/maven-settings/settings.html That seems worthwhile playing with. I presume these are Unix-format settings. Thanks for picking this up and finishing it. And to James and Sean and Gary (and anyone else I've forgotten) for all the help. Definitely a team effort. -- Wendy Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [shale] Maven Reorganization Status and a request for help
On 6/15/06, Craig McClanahan [EMAIL PROTECTED] wrote: I knew I'd seen this somewhere. In settings.xml, lets try server/filePermissions and server/directoryPermissions. * http://maven.apache.org/maven-settings/settings.html That seems worthwhile playing with. I presume these are Unix-format settings. Hmm ... from my experiements it now gets the directory settings right (775) but not the file settings (I wanted 664 but it does 644). This is when I tried mvn deploy -N in the shale-apps subdirectory. Craig
Re: [action2] action2 snapshot build
I'm somewhat a noob in training by Wendy and Sean :-), but here's my thoughts. On 6/15/06, tm jee [EMAIL PROTECTED] wrote: Hi guys, Got some questions :- 1] When is action2's snapshot in maven repository updated? Is it on a daily basis? Snapshots are updated only when a developer (or perhaps some nightly script) executes mvn deploy. 2] In Continuum, is it posible for user to download a particular successful build, say for example build 15 of action2? Need a Continuum guru to answer that one. 3] If a user wants to get a copy of action2 snapshot, but doesn't have maven installed, is there a website where he could download the jar from? The repository itself is just a website full of static files, so it would be possible to figure out the correct URLs for the snapshot JARs and publish those. For Shale, in addition to publishing the snapshot JARs themselves, we've got an assembly goal that includes all the dependency JARs in the Shale framework snapshot (see shale-dist/src/main/assembly/dist.xml in the mvn_reorg branch, soon to be moved to the Shale trunk), and I'd imagine the action2 snapshots would want to do the same thing, so it's a matter of pointing at one particular directory to download one particular file from. Another option (I haven't tried this, but I've seen simpler projects like Commons libraries use it) would be to generate an Ant build.xml file that is (theoretically) equivalent to what Maven would do for you: mvn ant:ant Several of the commons projects periodically generate such a build.xml and check it in to Subversion, providing a convenient mechanism for Ant based customers to build the snapshot from source. But, I've become an M2 convert, so I'm not planning to do this for Shale unless users ask for it :-). Thanks in advance. rgds Craig
Re: [action2] action2 snapshot build
On 6/16/06, tm jee [EMAIL PROTECTED] wrote: I'm somewhat a noob in training by Wendy and Sean :-), but here's my thoughts. You are just being humble Craig. :-) About Maven (which I see I neglected to mention :-), I'm still learning along with everyone else. Thx for the info Craig. Snapshots are updated only when a developer (or perhaps some nightly script) executes mvn deploy. I am wondering would it be possible to have some nightly script that runs mvn deploy automatically. That way one could just grab the latest jar that passed the test succesfully for testing purposes. That would be a good idea. I thought about doing that for Shale once we switch the Maven build over to the trunk ... let me see if I can set up to do the SAF2 (and maybe even SAF1?) builds with deployment of the snapshots every night. Craig Just like opensymphony's xwork nightly build at http://maven.opensymphony.com/opensymphony/jars/ - Original Message From: Craig McClanahan [EMAIL PROTECTED] To: Struts Developers List dev@struts.apache.org; tm jee [EMAIL PROTECTED] Sent: Friday, 16 June, 2006 3:15:18 PM Subject: Re: [action2] action2 snapshot build I'm somewhat a noob in training by Wendy and Sean :-), but here's my thoughts. On 6/15/06, tm jee [EMAIL PROTECTED] wrote: Hi guys, Got some questions :- 1] When is action2's snapshot in maven repository updated? Is it on a daily basis? Snapshots are updated only when a developer (or perhaps some nightly script) executes mvn deploy. 2] In Continuum, is it posible for user to download a particular successful build, say for example build 15 of action2? Need a Continuum guru to answer that one. 3] If a user wants to get a copy of action2 snapshot, but doesn't have maven installed, is there a website where he could download the jar from? The repository itself is just a website full of static files, so it would be possible to figure out the correct URLs for the snapshot JARs and publish those. For Shale, in addition to publishing the snapshot JARs themselves, we've got an assembly goal that includes all the dependency JARs in the Shale framework snapshot (see shale-dist/src/main/assembly/dist.xml in the mvn_reorg branch, soon to be moved to the Shale trunk), and I'd imagine the action2 snapshots would want to do the same thing, so it's a matter of pointing at one particular directory to download one particular file from. Another option (I haven't tried this, but I've seen simpler projects like Commons libraries use it) would be to generate an Ant build.xml file that is (theoretically) equivalent to what Maven would do for you: mvn ant:ant Several of the commons projects periodically generate such a build.xml and check it in to Subversion, providing a convenient mechanism for Ant based customers to build the snapshot from source. But, I've become an M2 convert, so I'm not planning to do this for Shale unless users ask for it :-). Thanks in advance. rgds Craig
[Shale][PROPOSAL] Cut over to Maven2 based source tree
As you undoubtedly know if you receive the Struts SVN commit messages :-), we've been busily setting up a Maven2 based build environment for Shale, to replace the original Ant based environment. This work has been done on a branch (mvn_reorg). I think It's now to the point where I'd like to make this the trunk, and get back to fixing bugs and implementing RFEs. What say ye? If there's no objections, my plan is to copy the current trunk to a pre-maven branch as is, then copy the mvn_reorg to the regular trunk. I'd like to do this by tomorrow (Saturday June 17) evening, Pacific time, so we can start addressing the backlog of issues. NOTE - there are known issues with the website pages that the Maven2 build process creates. We need to fix those too, but I don't think that should hold up making this the trunk for future Shale builds. Thoughts? Craig
Re: [action2] action2 snapshot build
On 6/16/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 6/16/06, tm jee [EMAIL PROTECTED] wrote: I'm somewhat a noob in training by Wendy and Sean :-), but here's my thoughts. You are just being humble Craig. :-) About Maven (which I see I neglected to mention :-), I'm still learning along with everyone else. Thx for the info Craig. Snapshots are updated only when a developer (or perhaps some nightly script) executes mvn deploy. I am wondering would it be possible to have some nightly script that runs mvn deploy automatically. That way one could just grab the latest jar that passed the test succesfully for testing purposes. That would be a good idea. I thought about doing that for Shale once we switch the Maven build over to the trunk ... let me see if I can set up to do the SAF2 (and maybe even SAF1?) builds with deployment of the snapshots every night. While looking into this, I noticed that the pom.xml for action2 still has two references to http://cvs.apache.org that need to be switched to http://people.apache.org. Mind if I go ahead and change them? Craig Craig Just like opensymphony's xwork nightly build at http://maven.opensymphony.com/opensymphony/jars/ - Original Message From: Craig McClanahan [EMAIL PROTECTED] To: Struts Developers List dev@struts.apache.org; tm jee [EMAIL PROTECTED] Sent: Friday, 16 June, 2006 3:15:18 PM Subject: Re: [action2] action2 snapshot build I'm somewhat a noob in training by Wendy and Sean :-), but here's my thoughts. On 6/15/06, tm jee [EMAIL PROTECTED] wrote: Hi guys, Got some questions :- 1] When is action2's snapshot in maven repository updated? Is it on a daily basis? Snapshots are updated only when a developer (or perhaps some nightly script) executes mvn deploy. 2] In Continuum, is it posible for user to download a particular successful build, say for example build 15 of action2? Need a Continuum guru to answer that one. 3] If a user wants to get a copy of action2 snapshot, but doesn't have maven installed, is there a website where he could download the jar from? The repository itself is just a website full of static files, so it would be possible to figure out the correct URLs for the snapshot JARs and publish those. For Shale, in addition to publishing the snapshot JARs themselves, we've got an assembly goal that includes all the dependency JARs in the Shale framework snapshot (see shale-dist/src/main/assembly/dist.xml in the mvn_reorg branch, soon to be moved to the Shale trunk), and I'd imagine the action2 snapshots would want to do the same thing, so it's a matter of pointing at one particular directory to download one particular file from. Another option (I haven't tried this, but I've seen simpler projects like Commons libraries use it) would be to generate an Ant build.xml file that is (theoretically) equivalent to what Maven would do for you: mvn ant:ant Several of the commons projects periodically generate such a build.xmland check it in to Subversion, providing a convenient mechanism for Ant based customers to build the snapshot from source. But, I've become an M2 convert, so I'm not planning to do this for Shale unless users ask for it :-). Thanks in advance. rgds Craig
Re: [Shale][PROPOSAL] Cut over to Maven2 based source tree
On 6/16/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 6/16/06, Craig McClanahan [EMAIL PROTECTED] wrote: I think It's now to the point where I'd like to make this the trunk, and get back to fixing bugs and implementing RFEs. What say ye? If there's no objections, my plan is to copy the current trunk to a pre-maven branch as is, then copy the mvn_reorg to the regular trunk. I'd like to do this by tomorrow (Saturday June 17) evening, Pacific time, so we can start addressing the backlog of issues. +1 on the general idea, but I would just: svn mv shale/trunk shale/tags/SHALE_PRE_MAVEN2 svn mv shale/branches/mvn_reorg shale/trunk (Done remotely, as no one is likely to have all the tags and branches checked out.) That's pretty much what I had in mind, except shale/branches/SHALE_PRE_MAVEN2. The thinking was that we might still have to update the website out of the old tree, until all the wrinkles are ironed out in the new tree. As for branches versus tags, that is basically just a convention anyway ... Subversion treats them identically. I don't think we need either a branch for the pre-Maven code (just a tag) or to keep a copy of what is now mvn_reorg in branches. Maybe there were some implied deletes in your original plan. :) Agree that we don't need to keep any separate copy of the mvn_reorg branch. -- Wendy Craig
Re: [shale] framework questions
On 6/15/06, stephan opitz [EMAIL PROTECTED] wrote: hello, shale has a lot of new features: View Controller: Backing bean for JSP with predefined events Validations: Client- and service-side validations JNDI: JSP access to properties in web.xml Dialog Manager: Web wizards (workflows) driven by XML configuration files Application Manager: An application-level controller to intercept all HTTP requests AJAX: A server-side service for AJAX support Spring, Tiles, and Clay framework integration and reusable views Test: Mock objects and base classes for JUnit-based tests 1. is the clay framework completely new developed? Clay was pretty much an original effort, primarily developed by Gary vanMatre, but you could also say it was inspired by the Facelets project at java.net, plus the way that Tapestry encourages users to develop pages with static HTML and separate component definitions. 2. is it possible to rebuilt the power of shale with existing frameworks (using the base jsf)? Yes, but an important part of Shale's power (and simplicity) comes from the fact that it presumes JSF is present, and uses JSF's controller architecture. The typical approach to integrating JSF into existing frameworks has been to use JSF's visual components, but not try to use its controller. IMHO, this leaves you with a more complicated application architecture, wth redundant implementations of basic features like navigation, validation, and conversion. On the other hand, you might also take a look at how Struts Action Framework 2 (the upcoming work to merge in the WebWork framework and create a next generation action oriented framework) attempts to meld the SAF/WW and JSF controller capabilities together. Very powerful, but (for at least some use cases), pretty complex. stephan Craig
[shale] Maven Reorganization Status and a request for help
Thanks to incredible support from Wendy, James, Gary, et. al., it looks like we've got a viable organization of the repository for Shale in the mvn_reorg branch. There's work to be done yet on the generated website, but the basic architecture seems sound. But there is one more thing I'd like to do before we move this over to the trunk ... have some more people download and validate the artifacts that the build process creates. To that end, I have uploaded snapshots to my home directory on people.apache.org(see URLs in the footnotes), and would like to ask for some volunteers to perform the following tests (plus any others that strike your fancy). An interesting question is how we make it possible to do step 4 (build the sample apps from source) without doing step 2 (build the framework from source). I presume that means we'd need to publish the shale-parent and shale-apps-parent POMs as snapshots, since a side effect of Step 2 would be to install the poms in your local repository. I know we'd need to publish the parent POMs as part of a normal release, but is that also the an acceptable process for snapshots? (1) Download and unpack the framework artifact[1]: Can I get to the Shale jar files (and all their dependencies) in the lib directory? Are any dependencies missing (probably have to use these to build an app to check that)? (NOTE - building shale-designtime.jar is currently commented out because it needs a bit more work before the code actually runs successfully). Can I examine the source code for the various framework modules (shale-clay, shale-core, shale-designtime, shale-dist, shale-remoting, shale-spring, shale-test, shale-tiger, shale-tiles)? Can I open the docs/index.html page and see the framework web site? (There will be lots of broken links and stuff inside, so don't worry too much about those at the moment) (2) Rebuild framework artifact from the sources: Assuming you have Maven 2.0.4 installed, you should be able to reproduce the artifact (in an environment where there are no previously installed Shale artifacts in your Maven2 repository) by executing: * cd directory-containing-unpacked-framework-artifact * mvn clean site * cd shale-dst * mvn assembly:assembly (3) Download and unpack the sample applications[2][3][4][5][6]: For each sampe app, you should be able to: * Download the artifact and unpack it * Examine the source code for that particular sample in the src' directory * Examine the sample app website in the site subdirectory (again, expect broken stuff, but I'm primarily interested in the packaging at this point). * Deploy the web application in the dist directory on Tomcat 5.5 or equivalent, with no deployment errors (I haven't validated that all the functionality is still correct yet, so I'd be interested in any problems you encounter there too). (4) Rebuild sample applications from sources: For each sample app, you should be able to reproduce it (assuming you've done Step 2 above ... see earlier discussion) by executing: * cd shale-x * mvn clean site assembly:assembly Thanks for your help in debugging the Maven2 builds for Shale! Craig [1] http://people.apache.org/~craigmcc/mvn_reorg/shale-framework-1.0.3-SNAPSHOT.zip http://people.apache.org/%7Ecraigmcc/mvn_reorg/shale-framework-1.0.3-SNAPSHOT.zip [2] http://people.apache.org/~craigmcc/mvn_reorg/shale-blank-dist.ziphttp://people.apache.org/%7Ecraigmcc/mvn_reorg/shale-blank-dist.zip [3] http://people.apache.org/~craigmcc/mvn_reorg/shale-clay-usecases-dist.ziphttp://people.apache.org/%7Ecraigmcc/mvn_reorg/shale-clay-usecases-dist.zip [4] http://people.apache.org/~craigmcc/mvn_reorg/shale-mailreader-dist.ziphttp://people.apache.org/%7Ecraigmcc/mvn_reorg/shale-mailreader-dist.zip [5] http://people.apache.org/~craigmcc/mvn_reorg/shale-sql-browser-dist.ziphttp://people.apache.org/%7Ecraigmcc/mvn_reorg/shale-sql-browser-dist.zip [6] http://people.apache.org/~craigmcc/mvn_reorg/shale-usecases-dist.ziphttp://people.apache.org/%7Ecraigmcc/mvn_reorg/shale-usecases-dist.zip
Re: [shale] Maven Reorganization Status and a request for help
On 6/15/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 6/15/06, Craig McClanahan [EMAIL PROTECTED] wrote: An interesting question is how we make it possible to do step 4 (build the sample apps from source) without doing step 2 (build the framework from source). I presume that means we'd need to publish the shale-parent and shale-apps-parent POMs as snapshots, since a side effect of Step 2 would be to install the poms in your local repository. I know we'd need to publish the parent POMs as part of a normal release, but is that also the an acceptable process for snapshots? Cool. Yes, and 'mvn deploy' will do it. Since the version numbers have -SNAPSHOT, Maven will choose the distributionManagement/snapshotRepository (inherited from struts-parent) and publish the artifacts there. (It should be people.apache.org/maven-snapshot-repository, it might need to be changed from cvs.a.o.) It's already set correctly. Then 'step 4' will work (without having done 'step 2') by retrieving the artifacts from a repositories/repository, one of which has the same snapshot repo URL. I deployed the framework JARs (and shale-parent POM) ... but it's still missing the shale-apps-parent POM. Can I deploy just that without deploying the applications themseves? That would work, but seems wasteful of space on the server. -- Wendy Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [shale] Maven Reorganization Status and a request for help
On 6/15/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 6/15/06, Craig McClanahan [EMAIL PROTECTED] wrote: I deployed the framework JARs (and shale-parent POM) ... but it's still missing the shale-apps-parent POM. Can I deploy just that without deploying the applications themseves? That would work, but seems wasteful of space on the server. mvn deploy -N (non-recursive) That did it. Thanks. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Craig
Re: svn commit: r414249 - /struts/action2/trunk/core/src/main/java/org/apache/struts/action2/components/GenericUIBean.java
On 6/14/06, Don Brown [EMAIL PROTECTED] wrote: That makes sense too. I guess the big draw for everything a JIRA ticket is it is easier to create the release notes. If you are just fixing a typo, that probably wouldn't go in the release notes anyways. That's exactly the standard I like to use to decide whether to file an issue or not. In general, fixing typos or improving Javadocs doesn't really rise to that level of attention. On the other hand, I'd prefer that pretty much all changes to the actual code would be documented by an issue (unless, perhaps, you are just fixing something you broke in a previous checkin against an issue :-). Don Craig Sean Schofield wrote: Going back to my point about overkill. If you have a complicated problem that cannot be summarized in a sentence or two, yes, then definitely a JIRA issue is in order. But if its a bug that was not reported by anyone and it was introduced in the current release cycle (say a tweak to a Maven POM) putting the info in JIRA is overkill. The *first* place I check when I want to understand a file change is the SVN logs. If there is a JIRA ref there then I go to JIRA. Usually the one line comment is sufficent for me to understand why the change was made. Again, if its in reference to a bug that has already been reported obviously you use JIRA. Also for any kind of major change (even if introduced in the current cycle) then JIRA is also appropriate. Sean On 6/14/06, Ted Husted [EMAIL PROTECTED] wrote: We have a ticket up for the current round of documentation updates [WW-1340] so you can use that. -Ted. On 6/14/06, tm jee [EMAIL PROTECTED] wrote: Okie dokie. Thx for the reminder. Do we need to create a jira issue even if its just changing some javadoc, like typo or snippet id is wrongly assigned etc.? regards. - Original Message From: Don Brown [EMAIL PROTECTED] To: dev@struts.apache.org Sent: Thursday, 15 June, 2006 1:16:48 AM Subject: Re: svn commit: r414249 - /struts/action2/trunk/core/src/main/java/org/apache/struts/action2/components/GenericUIBean.java Don't forget to associate a JIRA ticket with each commit to make it easier to track changes in a release... :) Thanks, Don [EMAIL PROTECTED] wrote: Author: tmjee Date: Wed Jun 14 06:48:08 2006 New Revision: 414249 URL: http://svn.apache.org/viewvc?rev=414249view=rev Log: - added javadoc snippet to reflect the fact that if JSP template is being used, it should resides in the webapp not the classpath as JSP is not capable of being picked up from classpath unlike Freemarker or Velocity see http://forums.opensymphony.com/thread.jspa?threadID=33869tstart=0 Modified: struts/action2/trunk/core/src/main/java/org/apache/struts/action2/components/GenericUIBean.java Modified: struts/action2/trunk/core/src/main/java/org/apache/struts/action2/components/GenericUIBean.java URL: http://svn.apache.org/viewvc/struts/action2/trunk/core/src/main/java/org/apache/struts/action2/components/GenericUIBean.java?rev=414249r1=414248r2=414249view=diff == --- struts/action2/trunk/core/src/main/java/org/apache/struts/action2/components/GenericUIBean.java (original) +++ struts/action2/trunk/core/src/main/java/org/apache/struts/action2/components/GenericUIBean.java Wed Jun 14 06:48:08 2006 @@ -47,6 +47,7 @@ * * * @a2.tag name=component tld-body-content=JSP tld-tag-class=org.apache.struts.action2.views.jsp.ui.ComponentTag * description=Render a custom ui widget - 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] - 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: [shale] download
On 6/12/06, Nagy Tibor [EMAIL PROTECTED] wrote: Dear DevTeam, We are at arvato systems Hungary, wanted to tryout SHALE framework, but none of the binary zip file was found in the given access path: http://people.apache.org/builds/struts/nightly/struts-shale/ The directory is empty, and we don't know how to get the beta. Can you help us with a working binary? At the moment, nightly build creation is disabled because we are in the midst of converting the process of building Shale from Ant to Maven2. This process is nearing completion, at which point we will re-enable creating nightly builds of Shale. In the short term, it is necessary to build Shale from sources, as described on the website[1]. Craig [1] http://struts.apache.org/struts-shale/building.html Best wishes, Tibor Nagy - arvato systems Hungary Kft. H-1038 Budapest Ráby Mátyás u. 26. Telefon: (36-1) 453-4100 Fax: (36-1) 453-4101
Re: [shale] Maven 2 profile activation
On 6/12/06, Wendy Smoak [EMAIL PROTECTED] wrote: On [EMAIL PROTECTED], Roland Asmann pointed out that a profile can be activated if a certain property is *not* present. We now have the MyFaces profile is active if the 'jsf' property is not set. The JSF RI profile is activated with -Djsf=ri on the command line. Using -Pmyfaces and -Pjsfri still works. Profiles can always be activated by their ids. Be sure to 'mvn clean' when you switch implementations, or the webapps will have both myfaces and the RI in WEB-INF/lib. (I think Maven 2.1 will better handle the concept of 'This jar provides an implementation of xyz specification' during dependency resolution.) With defaultGoal=install in the pom, you can now simply execute 'mvn' from the top of the branch, and it should work. Cool idea. So, I tried mvn clean then mvn -Pjsf=ri from the top of the branch. The sample apps are still packaged with the MyFaces API and IMPL jars (see my comment on SHALE-179). -- Wendy Craig
Re: [shale] Maven 2 profile activation
On 6/12/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 6/12/06, Wendy Smoak [EMAIL PROTECTED] wrote: We now have the MyFaces profile is active if the 'jsf' property is not set. The JSF RI profile is activated with -Djsf=ri on the command line. Note that this is -D for a system property (not -P for a profile id). D'oh ... not enough coffee to tell the difference between a D and a P. Using -Pmyfaces and -Pjsfri still works. Profiles can always be activated by their ids. But this part isn't true -- you'll end up with *both* MyFaces and the RI if you do 'mvn -Pjsfri'. I'll add properties to the other profiles tonight, and we'll switch to only using -D to avoid confusion. That makes sense. -- Wendy Craig
[Shale] Nightly Builds Resumed
For those of you following Shale, you've probably noticed that there have not been any nightly builds available for the past few weeks. This was due to a combination of circumstances, but the primary reason is we've been focusing on migrating the build environment from Ant-based scripts to use Maven2 instead. When completed, it will be *much* easier to build Shale, or applications based on Shale. However, in the mean time, I'm pleased to announce that creation of nightly builds for Shale have been restored. You can get the 20060612 version from: http://people.apache.org/builds/struts/nightly/struts-shale/ NOTES: * The Shale website currently has a bad link to this page (it points at cvs.apache.org). That will be fixed soon. In the mean time, use the link above. * When the conversion to Maven2 is complete, the organization of the artifacts published as nightly builds (as well as the organization of Shale releases as well) will be changed. Watch here for an announcement of the date that this goes into effect for the nightly builds. Craig McClanahan
Re: [shale] Maven 2 profile activation
On 6/12/06, Gary VanMatre [EMAIL PROTECTED] wrote: I was looking at the shale-usecaes build under the mvn_reorg branch and it looks like the war is bring everything but the kitchen sink as a dependency. The WEB-INF/lib contains the RI, myfaces, freemarker, struts, ant, and a couple versions of velocity. It it picking this up from cargo or parent project dependencies? Did you do a clean recently? A bunch of stuff has changed, and that'll be the only way to get good results, including just MyFaces (if you do mvn clean install) and just the RI (if you do mvn -Djsf=ri clean install). There was also a ton of stuff being inherited from the Spring 1.2.2 POMs ... updating the dependency to 1.2.5 cleared up a lot of that. Gary Craig -- Original message -- From: Craig McClanahan [EMAIL PROTECTED] On 6/12/06, Wendy Smoak wrote: On 6/12/06, Wendy Smoak wrote: We now have the MyFaces profile is active if the 'jsf' property is not set. The JSF RI profile is activated with -Djsf=ri on the command line. Note that this is -D for a system property (not -P for a profile id). D'oh ... not enough coffee to tell the difference between a D and a P. Using -Pmyfaces and -Pjsfri still works. Profiles can always be activated by their ids. But this part isn't true -- you'll end up with *both* MyFaces and the RI if you do 'mvn -Pjsfri'. I'll add properties to the other profiles tonight, and we'll switch to only using -D to avoid confusion. That makes sense. -- Wendy Craig
Re: svn commit: r413781 - /struts/shale/branches/mvn_reorg/shale-dist/src/assemble/dist.xml
On 6/12/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 6/12/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: craigmcc Date: Mon Jun 12 18:40:30 2006 New Revision: 413781 URL: http://svn.apache.org/viewvc?rev=413781view=rev Log: Add filesets for the rest of the top-level framework modules (but comment out the one for shale-designtime ... I still need to do cleanup work on that module). Issue -- it copies all the sources, but the only shale-*.jar included is the one for core. Also, add an Apache license at the top of the assembly configuration file. Thanks. :) To make it pick up the rest of the jars, add them as dependencies in pom.xml. Only shale-core is listed right now. Thanks ... noticed they were missing from the pom.xml right after this commit ... see the next one. -- Wendy Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Shale] Nightly Builds Resumed
On 6/12/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 6/12/06, Craig McClanahan [EMAIL PROTECTED] wrote: For maximum user benefit, it's nice to ship sample apps ready to run, with all their dependent jars included. But with four apps already, that would mean lots of jar files duplicated -- which would really bloat an all-in-one download. For the Ant based builds, I took the tack of creating several kinds of artifacts: * A zip of the framework itself (library jars, sources, javadocs) * A zip of the dependencies (which Maven will eliminate the need for I think 'jars without dependencies' is possible. Asking for the dependencies, but not the jar they came from, might be more difficult. Could the second one be a library distribution of Shale + dependencies? Right now we're creating the framework distro with all the Shale jars + the dependencies ... that seems like the most convenient packaging for a non-Maven user, and the size is currently just over 9mb, which shouldn't be any big deal. (Interestingly, the Shale part of that is 400k ... it's nice to not have to implement everything JSF already provides :-). So I don't really see a need for a separate dependencies-only distro. * A war file for each example (ideally with a buildable source module and javadocs for the application classes included inside). It's usually WEB-INF/src for the sources, but I haven't seen Javadocs in a .war file. WEB-INF/apidocs? (There's an example of copying the sources in Struts Action, probably in apps/pom.xml.) The other way we could do this would be build a src/main/assembly directory for each webapp, and package sources/javadocs/war file with the POM in the expected place (top level directory). It's marginally more complicated for someone to have to extract the WAR, but the project would look like an out-of-the-box Maven module. -- Wendy Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [shale] Maven 2 profile activation
On 6/12/06, Gary VanMatre [EMAIL PROTECTED] wrote: I had to wack my m2 shale repos and then rebuild all of the libraries. That was the was the ticket. I'm having trouble building shale-test. Is anyone seeing this error? [INFO] [compiler:compile] Compiling 34 source files to c:\shale2\mvn_reorg\shale-test\target\classes [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure c:\shale2\mvn_reorg\shale-test\src\main\java\org\apache\shale\test\mock\MockServ letContext.java:[53,7] org.apache.shale.test.mock.MockServletContext is not abst ract and does not override abstract method getContextPath() in javax.servlet.Ser vletContext Hmm ... getContextPath() was added to the Servlet API in 2.4, so you'd get an error like this if you compiled against the 2.4 version of the API. We don't explicitly specify a version in the test framework's POM, so for me (and I'd guess for Wendy too) it's picking up a 2.3 version of the servlet API. Since Shale as a whole depends on Servlet 2.4, I'm going to go through all the POMs and make sure we're explicit about the version number ... and also clean up any problems that this causes (including this one). Look for a commit later this evening. Craig -- Original message -- From: Craig McClanahan [EMAIL PROTECTED] On 6/12/06, Gary VanMatre wrote: I was looking at the shale-usecaes build under the mvn_reorg branch and it looks like the war is bring everything but the kitchen sink as a dependency. The WEB-INF/lib contains the RI, myfaces, freemarker, struts, ant, and a couple versions of velocity. It it picking this up from cargo or parent project dependencies? Did you do a clean recently? A bunch of stuff has changed, and that'll be the only way to get good results, including just MyFaces (if you do mvn clean install) and just the RI (if you do mvn -Djsf=ri clean install). There was also a ton of stuff being inherited from the Spring 1.2.2 POMs ... updating the dependency to 1.2.5 cleared up a lot of that. Gary Craig -- Original message -- From: Craig McClanahan On 6/12/06, Wendy Smoak wrote: On 6/12/06, Wendy Smoak wrote: We now have the MyFaces profile is active if the 'jsf' property is not set. The JSF RI profile is activated with -Djsf=ri on the command line. Note that this is -D for a system property (not -P for a profile id). D'oh ... not enough coffee to tell the difference between a D and a P. Using -Pmyfaces and -Pjsfri still works. Profiles can always be activated by their ids. But this part isn't true -- you'll end up with *both* MyFaces and the RI if you do 'mvn -Pjsfri'. I'll add properties to the other profiles tonight, and we'll switch to only using -D to avoid confusion. That makes sense. -- Wendy Craig
Re: [shale] Maven 2 profile activation
On 6/12/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 6/12/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 6/12/06, Gary VanMatre [EMAIL PROTECTED] wrote: I had to wack my m2 shale repos and then rebuild all of the libraries. That was the was the ticket. I'm having trouble building shale-test. Is anyone seeing this error? [INFO] [compiler:compile] Compiling 34 source files to c:\shale2\mvn_reorg\shale-test\target\classes [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure c:\shale2\mvn_reorg\shale-test\src\main\java\org\apache\shale\test\mock\MockServ letContext.java:[53,7] org.apache.shale.test.mock.MockServletContextis not abst ract and does not override abstract method getContextPath() in javax.servlet.Ser vletContext Hmm ... getContextPath() was added to the Servlet API in 2.4, so you'd get an error like this if you compiled against the 2.4 version of the API. We don't explicitly specify a version in the test framework's POM, so for me (and I'd guess for Wendy too) it's picking up a 2.3 version of the servlet API. Off by one? I think the getContextPath() method was added in Servlet 2.5, and both of us are correctly compiling against 2.4. Yep ... it was indeed added in 2.5. Since Shale as a whole depends on Servlet 2.4, I'm going to go through all the POMs and make sure we're explicit about the version number ... and also clean up any problems that this causes (including this one). Look for a commit later this evening. The dependencyManagement section of the shale-parent pom controls the version number, and it has 2.4. It does not need to be specified in each pom. The only way I can reproduce this error is to add version2.5/version to the servlet-api dependency in shale-test/pom.xml. I'm trying to reduce redundancy by removing the javax.servlet:servlet-apiand javax.servlet:jsp-api dependencies inside the subordinate modules, since they are declared in shale-parent ... but that causes compile errors indicating that no API classes are getting added to the classpath. Shouldn't the subordinate POMs be inheriting this dependency from shale-parent? Gary, can you make sure you've updated everything, or try this with a fresh checkout, and let us know if it still happens? I think you have an updated shale-test pom, but an old shale-parent pom. Indeed, you'd have to execute mvn clean install from the parent directory to insure that the new parent POM gets installed first. -- Wendy Craig
Re: [shale] Maven 2 profile activation
On 6/12/06, Craig McClanahan [EMAIL PROTECTED] wrote: I'm trying to reduce redundancy by removing the javax.servlet:servlet-apiand javax.servlet:jsp-api dependencies inside the subordinate modules, since they are declared in shale-parent ... but that causes compile errors indicating that no API classes are getting added to the classpath. Shouldn't the subordinate POMs be inheriting this dependency from shale-parent? Never mind ... dependencyManagement in the parent POM is essentially templates for picking version numbers ... it doesn't behave the same as dependencies at the top level. Should we think about declaring dependencies in the shale-parent POM instead, for the stuff that is guaranteed to be common (servlet-api, jsp-api, etc.)? (It would still have to be legal, for example, for a particular webapp to declare dependency on Servlet 2.5 even if the parent says use 2.4.) Craig Gary, can you make sure you've updated everything, or try this with a fresh checkout, and let us know if it still happens? I think you have an updated shale-test pom, but an old shale-parent pom. Indeed, you'd have to execute mvn clean install from the parent directory to insure that the new parent POM gets installed first. -- Wendy Craig
Tracing Maven2 Transitive Dependencies
I'm working on the Maven2 build for the shale-usecases example (on the mvn_reorg branch). Currently, the application buids, but it fails on some XML parsing errors when you deploy it. In turn, this happens because xml-apis-1.0.b2.jar and xercesImpl-2.2.1.jar are getting picked up as dependencies that need to be included in the war. Now, the challenge is to identify where they are coming from so they can be excluded. I've tried Wendy's suggestion of using -X on the mvn execution, which gives a pretty copious amount of output ... and still doesn't make it clear from which POM the dependency is actually getting inherited. Is there some mechanism in Maven2 that just lists out the dependency tree, so you can figure stuff like this out easily? Craig
Re: Tracing Maven2 Transitive Dependencies
On 6/10/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 6/10/06, Wendy Smoak [EMAIL PROTECTED] wrote: You get rid of them by adding a dependency in the webapp pom marked provided or optional. Maven constructs a dependency graph and uses the closest definition. Missed a word there. :) You _can_ get rid of them this way, though excludes are more correct. Actually, I was thinking of the provided approach ... and I can even rationalize it :-). Shale requires a JDK 1.4 or later environment, which includes (among other things) a built-in XML parser. Therefore, marking these two dependencies as provided would make sense. Probably in the shale-parent POM (or possibly the one for apps, since we have control over the dependency declarations in the core libraries). -- Wendy Craig
Re: svn commit: r413252 - in /struts/shale/branches/mvn_reorg/shale-apps: ./ shale-usecases/src/systest/org/apache/shale/usecases/systest/ shale-usecases/src/test/java/org/apache/shale/usecases/systes
On 6/10/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 6/9/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Also, need to review the heavy baggage that including shale-spring as a dependency (and transitively the dependencies that Spring defines) brings to the table. Spring 1.2.5 looks like the first version that has its dependencies marked 'optional' in the poms. I'm having trouble with 'mvn site' throwing a NPE due to the exclusion in the shale-spring pom. The easiest thing to do is just change Shale's dependency to a later version. We can document that it actually works with 1.2.2+, and anyone who wants a different version can add it to his own project's pom. That works for me ... I'll give it a try. -- Wendy Craig
Re: Maven 2 website documentation editing
Several notes and a mystery below. On 6/10/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 6/10/06, Wendy Smoak [EMAIL PROTECTED] wrote: You can also stage the entire site locally with: 'mvn site:stage' It defaults to target/staging, or you can specify -DstagingDirectory=/path/to/tempdir Strange. The default is to put target/staging under each module, which isn't any more useful than the separate target/site directories that 'mvn site' builds. With -DstagingDirectory=/path/to/tempdir, though, it puts the entire site together, just as it will be on the server. So use that. :) Don't forget to add -Pmyfaces as well ... the site generation seems to want to compile everything again, and some of the compiles will fail without either -Pmyfaces or -Pjsfri being explicity listed (most likely a Maven issue). Mystery: This runs for me on my Linux desktop, but on my Windows XP laptop I get Required goal not found: site:stage ... it's as if Maven doesn't know that this goal exists. It is Maven 2.0.4 in both cases. Do I need to do something special to make it recognize this? Issues: * Can I blame Wendy (who got the site build to work) for the many thousands of Checkstyle errors we need to wade through? :-) Nah ... that'd be shooting the messenger. But it is a good opportunity to tweak the rules we're asking it to enforce. * The JxrReport plugin seemed to fail on every module, looking for a pom.xml in the directory above the mvn_reorg root. Shouldn't it be obeying the parent declarations in the POMs? * Even though I used the -DstagingDirectory approach, the javadocs for the modules aren't correctly linked from the website home page. That's probably because those links are done manually. * On the Project Summary page, the description seems to come from the struts parent POM (and I think I've seen this text still in some of the generated MANIFEST.MF files too). Can we make it come from the Shale parent instead? * The Dependencies and Dependency Convergence reports address my earlier question about a hierarchical chain of dependencies, although the links on the latter page are all broken. But it pointed me to a version mismatch problem that's already been fixed. * The Source Repository page doesn't have any information ... we'll want to fill in the appropriate POM stuff for that. * The project reports for each module don't seem to be linked into the overall site anywhere. Should they be? -- Wendy Craig
Re: Maven 2 website documentation editing
On 6/10/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 6/10/06, Craig McClanahan [EMAIL PROTECTED] wrote: Don't forget to add -Pmyfaces as well ... the site generation seems to want to compile everything again, and some of the compiles will fail without either -Pmyfaces or -Pjsfri being explicity listed (most likely a Maven issue). I have a question out on [EMAIL PROTECTED] to see how to get exactly one of those activated, with a default. Mystery: This runs for me on my Linux desktop, but on my Windows XP laptop I get Required goal not found: site:stage ... it's as if Maven doesn't know that this goal exists. It is Maven 2.0.4 in both cases. Do I need to do something special to make it recognize this? Old site plugin? Try -U on the command line to make it update, or rm -rf $M2_REPO/org/apache/maven/plugins/maven-site-plugin so it will download again. The -U switch worked. Hmm, does that mean Maven treats snapshot plugins different from snapshot dependencies? * Even though I used the -DstagingDirectory approach, the javadocs for the modules aren't correctly linked from the website home page. That's probably because those links are done manually. I don't think it will automatically add links to sub-project Javadoc, but see below. * On the Project Summary page, the description seems to come from the struts parent POM (and I think I've seen this text still in some of the generated MANIFEST.MF files too). Can we make it come from the Shale parent instead? Is there one? Add a description to the shale-parent pom and it should override the inherited one. Keep in mind that the jar plugin uses description as the Specification-Title. There's an issue open, we're arguing that it should use name instead and give us back the multi-line description. I'll do that with description for now, but I'm on your side about using name for the manifest. * The Dependencies and Dependency Convergence reports address my earlier question about a hierarchical chain of dependencies, although the links on the latter page are all broken. But it pointed me to a version mismatch problem that's already been fixed. I think I've seen that mentioned on the Maven user list, there's probably an issue open. OK. * The project reports for each module don't seem to be linked into the overall site anywhere. Should they be? I'm not sure what you mean, can you give an example of what you want it to do? Just as one example ... as the site generation was occurring, I saw it create checkstyle reports for each module. But I can't seem to find them anywhere on the generated site. I would imagine we should also be able to see all the other module-specific reports. Everything is moving towards aggregation, but not all of it works yet. As with Maven 1, you can override the default page that gets generated, so for example in Struts Action we have src/site/apidocs/index.xml for this: http://struts.apache.org/struts-action/apidocs/index.html We'll clearly want an aggregated site, but I'm wondering if focusing on the assembly stuff might not be more urgent, so we can resurrect the nightly builds. Those have a timeout on the server, and I'm getting pinged from a couple of users that it looks like the project is not progressing since those are not being generated. -- Wendy Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [shale] Maven, Cargo and integration testing
On 6/7/06, Wendy Smoak [EMAIL PROTECTED] wrote: The Shale Blank app is now set up to run its integration tests. http://svn.apache.org/viewvc?rev=412639view=rev The includes/excludes are working (thanks David!) and we're using the Cargo Java API to start and stop Tomcat. (Yesterday's experiment with the Cargo plugin didn't work out, the inherited config from the shale-apps parent pom was causing it to try to start Tomcat twice.) Surefire is bound to the 'test' phase by default, so it runs then with **/systest/** excluded. There is an additional execution of Surefire bound to the integration-test phase, where it runs only the integration tests. Craig, can you please try 'mvn install -Pmyfaces,itest' from shale-blank (or above) and let me know if this does what you want? (You'll either need 'cargo.tomcat5x.home' configured in settings.xml, or with -D on the command line.) That works really slick ... thanks! This app has only one test so it doesn't matter too much, but usually the code to start and stop the container goes in a TestSetup class. I put it directly in the test case to keep things as simple as possible at first. I've seen that convention, but have a question for you ... since the unit tests for webapps built from these examples are going to use the mock objects in the Shale Test Framework anyway, what would you think of having a convenience abstract base class in shale-test (probably a subclass of AbstractHtmlUnitTestCase) that embedded the container startup/shutdown stuff? It would likely need some system properties to specify the container id (default to tomcat5x) and the WAR to be tested, but this approach would save having to construct a customized TestSetup class in every webapp project. Craig Thanks, -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [SAF2] Tossing an idea around: PDFResult
On 6/6/06, Martin Cooper [EMAIL PROTECTED] wrote: On 6/6/06, Frank W. Zammetti [EMAIL PROTECTED] wrote: Martin Cooper wrote: No. FOP = whatever. I consider anything -- PDF to be out of scope / too specialised here. Ah, ok, gotcha, I understand now :) PDF generation is a fairly common thing to do from a webapp though, no? No, not really. At least, not compared to things like SSO, LDAP authentication, access control, distributed sessions, persistence, and a lot of other things Struts doesn't bake in. I know I've had to do it plenty... WW has always been, from what I've seen, a framework that tried to have a wider scope than Struts did... for example, built-in support for DWR and Dojo, built-in support for continuations, integration with Quartz and JasperReports... all of this could be argued is out of scope for a web framework, couldn't it? Sure it could. And I might well argue that way, for some of those examples. I don't see PDF generation, *assuming it's a somewhat limited capability*, to be too specialized. I do. Sorry, but it's just not in the same league as other much more common cases. I didn't make it clear in my previous comment ... but I totally agree with Martin that actually *building* an anything-PDF converter as part of Struts is out of scope. But that's a different thing from providing a PdfResult interface that has a strategy pattern plugin to configure an adapter for your favorite PDF generation tool ... perhaps with an example application that has an implementation for one particular PDF generation library (i.e. the implementation itself is a demo, not part of the core of Struts). That kind of approach would be perfectly reasonable to me. As would some eventual commitment for the Struts project to support some small number of adapters to particular PDF generation libraries where we had committers willing to maintain the adapters in response to API changes in the underlying generators. Frank, does that difference in viewpoint help you see the scoping issue here? -- Martin Cooper Craig
Re: Maven2 and Functional/Integration Tests
On 6/5/06, Brett Porter [EMAIL PROTECTED] wrote: On 06/06/06, Craig McClanahan [EMAIL PROTECTED] wrote: Maven2 needs to support integration testing as a first class notion in the architecture of what you envision a project to be. It may not have been clear enough, but that's exactly what I meant in my last email. I thought this is what the wiki page discussed - if you think something is missing there, let me know. Somehow I missed the correct issue I was thinking of, MNG-1381, so I've linked that now instead. I'm just trying to consolidate this. I can assure you it is the issue you are thinking of - sorry for the confusion, re-reading I see MNG-591 is a specific use case of integration testing and not very helpful. It's not just webapps .. you've got the same sort of issue with EJBs, or web services, or anything that gets deployed in a container. Unit tests just don't give you the confidence you need that the application will actually work. I've seen too many cases where all the unit tests on a webapp all pass with flying colors, but it throws an HTTP 500 on the welcome page because of a stupid coding error in the JSP page that wasnt' tested with the unit tests. Yes, I'm well aware of that. What's needed is a complete additional test environment, with its own lifecycle, and its own classpath (i.e. dependencies tagged to this scope so you only load things like HttpUnit or HtmlUnit here). If integration tests exist, they should be part of the default mvn install processing, just like unit tests are, unless it is explicitly disabled. Don't pretend that there is only one kind of test!!! Again, what I was getting at. This was discussed at length on the Maven dev list and is summarised on the wiki page. Otherwise, you guys are not being serious about trying to encouraging best practices in build environments :-(. Of course we are. Added some comments on the wiki page. - Brett Craig
Re: [shale] Best practice for unit testing Tag class?
On 6/6/06, Sean Schofield [EMAIL PROTECTED] wrote: Is there a recommended practice for testing out my JSP Tag classes? Is this even desirable? I'm thinking that its nice to verify that values and value bindings are being set properly. Maybe we could add something to shale-test that could combine the mock stuff with a real tag? I'm still working through the test project so maybe there is an obvious solution that I have missed ... Actually, there isn't any support for this in the test framework at the moment ... that would make a really good enhancement. We'll probably need to provide mock objects for all the JSP API stuff, and probably some helpers that emulate the tag lifecycle alternatives, since it's a little more complex than the JSF lifecycle. Sean Craig
Re: [SAF2] Tossing an idea around: PDFResult
On 6/6/06, Martin Cooper [EMAIL PROTECTED] wrote: On 6/6/06, Frank W. Zammetti [EMAIL PROTECTED] wrote: Martin Cooper wrote: I agree that this doesn't sound like something that should happen here. Your saying that in terms of the custom XML wrapper around iText/PDFBox/whatever, right? Yes. I.e., going the FOP direction is a different story, right? No. FOP = whatever. I consider anything -- PDF to be out of scope / too specialised here. To be a bit pedantic, I think you mean *building* an anything-PDF container is out of scope, not *using* one (or more), right? -- Martin Cooper Craig
Maven2 and Functional/Integration Tests
If I'm reading 'Better Builds With Maven correctly, it seems that the recommended practice for functional or system integration tests for webapps (i.e. where you deploy the app to a server and then execute HTTP requests and examine the result) is to build a separate functional-tests module per webapp. Yuck. Is that the only way to do it? I was spoiled in my previous build.xml scripts to be able to run ant install systest on a webapp module and have it deploy my app plus execute the integration tests immediately, with the tests themselves being in a separate source directory (my convention was src/systest) in the same project. Thoughts? Craig
Re: Maven2 and Functional/Integration Tests
On 6/5/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 6/5/06, Craig McClanahan [EMAIL PROTECTED] wrote: If I'm reading 'Better Builds With Maven correctly, it seems that the recommended practice for functional or system integration tests for webapps (i.e. where you deploy the app to a server and then execute HTTP requests and examine the result) is to build a separate functional-tests module per webapp. Yuck. Is that the only way to do it? I was spoiled in my previous build.xml scripts to be able to run ant install systest on a webapp module and have it deploy my app plus execute the integration tests immediately, with the tests themselves being in a separate source directory (my convention was src/systest) in the same project. Although Maven 2.0 has build lifecycle phases for both 'test' and 'integration-test', it doesn't seem to handle doing both of them in the same module. Surefire looks at the build/testSourceDirectory to find the test sources -- there is no integrationTestSourceDirectory, and no way that I'm aware of to have two executions of Surefire in the same module that use different source directories. There's some information on the StrutsMaintenanceMaven wiki page, including a link to a page on the Maven wiki where integration testing strategies are being worked out: http://docs.codehaus.org/display/MAVEN/best+practices+-+testing+strategies For a while it seemed like Vincent was going to be allowed to make some changes in Maven 2.0, but nothing has happened recently, and one of the issues linked to from that wiki page is marked 'fix for 2.1.1'. For Struts Action, all of the integration tests live in action/integration/apps-it, and the plugin executions are wrapped in a profile so they don't run unless you use -Pperform-itest. I agree that having the tests in a separate module isn't ideal, but I think we'll have to live with it for a while. BTW, here's the TestSetup class that uses Cargo to start Tomcat and deploy the apps: http://svn.apache.org/repos/asf/struts/action/trunk/integration/apps-it/src/test/java/org/apache/struts/apps/Tomcat5xTestSetup.java I'll do my part[1] to encourage positive change in this regard. -- Wendy Craig [1] http://jira.codehaus.org/browse/MNG-2344
Re: Maven2 and Functional/Integration Tests
On 6/5/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 6/5/06, Brett Porter [EMAIL PROTECTED] wrote: It *should* still be possible to achieve what you want currently (I thought Vincent's chapter discussed that, but I don't might be mistaken). It may take some effort, though, and I'm not sure of any existing examples. The 'integration-test' phase was meant to be a general hook to facilitate this where possible. The problem I keep running into is that there is only one build/testSourceDirectory, and there is no profile/build/testSourceDirectory in the model. If that existed, it seems like you could get another execution of Surefire using a second source directory. That's the key problem, and that's why the duplicate closing is going to neglect what I'm interested in. Maven2 needs to support integration testing as a first class notion in the architecture of what you envision a project to be. It's not just webapps .. you've got the same sort of issue with EJBs, or web services, or anything that gets deployed in a container. Unit tests just don't give you the confidence you need that the application will actually work. I've seen too many cases where all the unit tests on a webapp all pass with flying colors, but it throws an HTTP 500 on the welcome page because of a stupid coding error in the JSP page that wasnt' tested with the unit tests. What's needed is a complete additional test environment, with its own lifecycle, and its own classpath (i.e. dependencies tagged to this scope so you only load things like HttpUnit or HtmlUnit here). If integration tests exist, they should be part of the default mvn install processing, just like unit tests are, unless it is explicitly disabled. Don't pretend that there is only one kind of test!!! Otherwise, you guys are not being serious about trying to encouraging best practices in build environments :-(. Craig PS: (I'm going to paste the above comments into the bug report as well, so Maven folks who aren't subscribed here will see them.) You're hinting that it's possible, though... what am I missing? -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [shale] Maven 2 build -- Help Wanted
On 6/1/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 6/1/06, James Mitchell [EMAIL PROTECTED] wrote: Ok, so I had some time this morning to help. I started looking at the apps to see what I could do to get them up to Maven2 par. I created a struts-shale-apps-parent (pom.xml under apps/) and added it as a module of struts-shale-parent. I then created struts-shale-apps-sql-browser (pom.xml under apps/sql- browser) and that almost works fine. With respect to 1.4 vs 1.5 for compilation, I'm not sure what all is going on with profile/activation inheritance and all, but even with this: Thanks. :) The 1.5 profile should be automatically activated if you're compiling with JDK 1.5. You shouldn't have to put anything on the command line. Is that not working? profile activation jdk1.5/jdk - /activation modules moduletiger/module /modules /profile -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Updated status -- we now can successfully compile all of the following modules using the new Maven build: shale-clay, shale-core, shale-remoting, shale-spring, shale-tiles, shale-tiger, shale-test However, the following modules still have unit test failures: * shale-clay: It looks like the component definitions for the standard JSF components are not getting recognized. Gary, could you take a look at these? * shale-tiger: The ant version of the tests builds a mock web application directory structure under target/test-webapp that is used to exercise the configuration loading classes. It doesn't look like we can emulate this by simply copying resources, because it assembles some things out of compiled classes. Is there a plugin where we can escape out to an actual Ant script when the tests are compiled? If so, it would be pretty easy to copy just the test:webapp target stuff from the original build. The POM will also need to pass the basedir property, if it doesn't already. I'll be working out the details on the last remaining top-level module (shale-designtime) late this evening. In the mean time, I'm going to comment it out of the parent POM because this module will always require some special processes at build time, and is not required for anything else. That will allow us to start hacking on the Shale sample apps once the test failure issues above are addressed. Craig
Re: [shale] Maven 2 build -- Help Wanted
More updated status on shale-clay: On 6/3/06, Craig McClanahan [EMAIL PROTECTED] wrote: However, the following modules still have unit test failures: * shale-clay: It looks like the component definitions for the standard JSF components are not getting recognized. Gary, could you take a look at these? There were some more resources fixes that needed to get added to the runtime JAR. That fixed everything except to assertion failures in ClayAmalgamTestCase, which I have temporarily commented out with FIXME notes. These will need to be reviewed more carefully by Gary. But, with these two assertions commented out, the Mavenized version of shale-clay passes all its unit tests. By the way, Gary, I think you might have the order of arguments incorrect on your assert calls. It should be assertEquals(label, expected value, actual value) but it looks like the latter two are reversed, at least in these two tests. The order doesn't affect whether the test will pass or fail, but it does make the resulting exception message more difficult to understand. Craig
Re: Maven Reorg (Was -- Re: [shale] Maven 2 build -- Help Wanted)
On 6/1/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 6/1/06, James Mitchell [EMAIL PROTECTED] wrote: Are you able to run the tiger tests? No. I got to the part in build.xml where it says Set up 'web application' for unit tests and decided that maven.test.skip=true would do for now. :) Craig, can you explain the testing strategy for shale-tiger? It's supposed to be similar to core-lbrary, in that the src/test directory will contain a bunch of JUnit tests. Since the module requires 1.5, the tests will as well, but other than that it should not be anything special. Craig -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven Reorg (Was -- Re: [shale] Maven 2 build -- Help Wanted)
On 6/1/06, James Mitchell [EMAIL PROTECTED] wrote: Also, what's the deal with designtime? I briefly remember some discussion on it in this thread and was just wondering what the final result was. Will the binaries be made available via Maven repo? Or do we have to download creator and manually install the jars locally? I'm working on the public avaiability of this (we announced at JavaOne that Creator will be open sourced ... finalizing the planning now, but it's more likely to be months than weeks or days). In the mean time, I'll create a cheat sheet for how to copy the necessary JARs out of a downloaded Creator 2 (or Creator 2 Update 1) install and put them locally into your repository. -- James Mitchell Craig
Re: Maven Reorg (Was -- Re: [shale] Maven 2 build -- Help Wanted)
On 6/1/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 6/1/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 6/1/06, James Mitchell [EMAIL PROTECTED] wrote: Are you able to run the tiger tests? No. I got to the part in build.xml where it says Set up 'web application' for unit tests and decided that maven.test.skip=true would do for now. :) Craig, can you explain the testing strategy for shale-tiger? It's supposed to be similar to core-lbrary, in that the src/test directory will contain a bunch of JUnit tests. Since the module requires 1.5, the tests will as well, but other than that it should not be anything special. OK, that's only half the story ... and the same thing will apply to use-cases (and potentially all of the other webapps when we get there). There are potentially two sets of tests. * src/test in the original repository contains JUnit unit tests that run standalone on the classes in the webapp's src/java directory. * src/systest in the original repository contains JUnit tests, but they (a) presume that the webapp has been deployed, and (b) use HtmlUnit to exercise the actual application and examine the returned HTML pages for correct output. I think of these as system integration tests rather than unit tests, but vastly prefer HtmlUnit based tests like this to something built with Cactus. Much simpler. We don't necessarily have to solve the systest issues tonight, but that'll probably bear some thought since the same principle would apply to any webapp in the repository (and, ideally, any user-defined webapp created via the archetype mechanisms). Craig Craig
Re: Maven Reorg (Was -- Re: [shale] Maven 2 build -- Help Wanted)
On 6/1/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 6/1/06, Craig McClanahan [EMAIL PROTECTED] wrote: Works for me now as well, with your latest patches. But shouldn't it also work without the -Pmyfaces because it's got activeByDefault set? I think so, too. :/ In addition there was some strangeness (discussed on [EMAIL PROTECTED]) with being able to deacivate an active-by-default profile. So I'm not yet sure how that part is going to work. I would hope they end up with a reasonable policy like if there is a -P option on the command line, activate only the profiles specified there; otherwise activate the active by default profile(s). Craig By the way (if you beat me to it), the sql-browser example app also requires JDK 1.5 (an the tiger library). Shale Tiger isn't building just yet, working on that now... -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven Reorg (Was -- Re: [shale] Maven 2 build -- Help Wanted)
On 6/1/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 6/1/06, Craig McClanahan [EMAIL PROTECTED] wrote: Found the one on the Maven website[1] and added the appropriate entries. But now, when I try to run mvn clean test -Pjsfri the following bad things happen: * There's an obsolete jsf-api artifact on ibiblio -- can we specify a priority ordering somehow? Not that I'm aware of. But ibiblio only has a pom for 1.1, so it shouldn't cause a problem if we're using version 1.1_02. If you mean the 'invalid pom' warnings, that's because java.net is a Maven 1 repo. * It fails to download the jsf-impl (but that could be my proxy not liking https -- investigating. After I added the repository and changed the version number, 'mvn clean install -Pjsfri' in core-library ran with no problems here. Me too when I disconnected from my VPN network (and commented out the appropriate proxy stuff). I've used https proxies for other things (including SVN commits to Apache), so it's likely to still be something with Maven ... but that's an issue that can wait for a night's sleep. -- Wendy Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven Reorg (Was -- Re: [shale] Maven 2 build -- Help Wanted)
On 6/1/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 6/1/06, James Mitchell [EMAIL PROTECTED] wrote: Sorry, I meant with Maven 2. I get a few test failures, even after correcting the missing .xml files from test. So did I. The tests fail with Maven2, so I looked at tiger/build.xml to see what might be missing. In build,xml, the 'test' target depends on 'test:webapp' which constructs a web application directory structure that I assume the tests depend on. Yes, they do ... Tiger needs to be able to parse the faces-config.xml files defined by the webapp just like the JSF runtime does, so I needed to be able to simulate a webapp directory structure for that in the unit tests. Note that the Ant scripts pass a basedir system property pointing at where the deployed webapp directory structure is -- we'll need to do something equivalent or change the tests to presume where the resources actually end up. Craig It might be as simple as arranging that into src/test/resources so it will be available for the m2 tests. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven Reorg (Was -- Re: [shale] Maven 2 build -- Help Wanted)
On 6/1/06, Wendy Smoak [EMAIL PROTECTED] wrote: And with that, I think I'm done for the night. Thanks for all the help! Likewise ... and thanks to James as well. -- Wendy Craig
Re: Maven Reorg (Was -- Re: [shale] Maven 2 build -- Help Wanted)
On 6/2/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 6/2/06, Sean Schofield [EMAIL PROTECTED] wrote: We should rename core-library to shale-core. It saves a lot on maven/continuum headaches if the name of the dir matches the name of the artifact. We did not do this in MyFaces (for some valid reasons) but its a definite inconvenience. I haven't checked the other artifacts but that suggestion holds for those as well. +1 for shale-core, shale-test, shale-clay, etc., as directory names matching the artifactIds. +1 as well (convention over configuration strikes again :-). For the apps, I see a really long artifactId for the sql browser app, and would rather have it match the name of the war file: shale-sql-browser. That makes sense. And the name is also the default for the context path, right? Thanks, -- Wendy Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven Reorg (Was -- Re: [shale] Maven 2 build -- Help Wanted)
On 6/2/06, Wendy Smoak [EMAIL PROTECTED] wrote: Oops... wrong button! On 6/2/06, Sean Schofield [EMAIL PROTECTED] wrote: +1 for shale-core, shale-test, shale-clay, etc., as directory names matching the artifactIds. Done The list of modules in the parent pom needs to be changed to match. I'm working on this one ... but it raises two questions. * I presume we don't have to list the individual applications themseves in the shale-parent-pom file, because things get processed hierarchically? * When I try a build (like mvn test intall -Pmyfaces) from within one of the subdirectories (like shale-core), it tries to download struts-shale-parent-1.0.3-SNAPSHOT.pom (i.e. the file I'm modifying) from ibiblio. Shouldn't we be installing the local copy of the parent POM so it'll pick up all the most recent changes? Craig Are you suggesting changing the artifact id and then the name of the module to match it? If so +1 from me. Yes, for all the apps. I'll do it later (or tomorrow) if no one beats me to it. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r410977 - in /struts/shale/branches/mvn_reorg: core-library/src/conf/ core-library/src/designtime/ core-library/src/java/ core-library/src/main/ core-library/src/main/java/ core-librar
On 6/1/06, James Mitchell [EMAIL PROTECTED] wrote: There were a couple of commits to shale between when mvn_reorg was copied and this commit. Without looking over this file by file, I hope we aren't losing anything. I'm watching closely on the commits I'm doing, and I imagine Gary will do the same. I plan to duplicate the necessary changes once the under construction dust settes down a bit :-). Also, what's the status of the reorg? Are we supposed to still help out in the test repo? Or in mvn_reorg? Or in shale/trunk? Once Sean is done with the initial updates, we'll want to test i mvn_reorg. After we're satisfied with that, and catch up on pending commits, we'll move mvn_reorg back to the trunk and proceed from there. -- James Mitchell Craig On Jun 1, 2006, at 6:16 PM, [EMAIL PROTECTED] wrote: Author: schof Date: Thu Jun 1 15:16:48 2006 New Revision: 410977 URL: http://svn.apache.org/viewvc?rev=410977view=rev Log: committed changes in Wendy's original shale-reorg-core-01.sh script Added: struts/shale/branches/mvn_reorg/core-library/src/main/ struts/shale/branches/mvn_reorg/core-library/src/main/java/ - copied from r410974, struts/shale/branches/mvn_reorg/core- library/src/java/ struts/shale/branches/mvn_reorg/core-library/src/main/resources/ - copied from r410974, struts/shale/branches/mvn_reorg/core- library/src/conf/ struts/shale/branches/mvn_reorg/core-library/src/site/ struts/shale/branches/mvn_reorg/core-library/src/site/site.xml - copied unchanged from r410974, struts/shale/branches/ mvn_reorg/core-library/xdocs/navigation.xml struts/shale/branches/mvn_reorg/core-library/src/site/xdoc/ - copied from r410974, struts/shale/branches/mvn_reorg/core- library/xdocs/ struts/shale/branches/mvn_reorg/core-library/src/site/xdoc/xdocs/ - copied from r410974, struts/shale/branches/mvn_reorg/core- library/xdocs/ struts/shale/branches/mvn_reorg/core-library/src/test/java/ struts/shale/branches/mvn_reorg/core-library/src/test/java/org/ - copied from r410974, struts/shale/branches/mvn_reorg/core- library/src/test/org/ struts/shale/branches/mvn_reorg/designtime/src/ struts/shale/branches/mvn_reorg/designtime/src/main/ struts/shale/branches/mvn_reorg/designtime/src/main/java/ - copied from r410974, struts/shale/branches/mvn_reorg/core- library/src/designtime/ struts/shale/branches/mvn_reorg/spring/src/ struts/shale/branches/mvn_reorg/spring/src/main/ struts/shale/branches/mvn_reorg/spring/src/main/java/ struts/shale/branches/mvn_reorg/spring/src/main/java/org/ struts/shale/branches/mvn_reorg/spring/src/main/java/org/apache/ struts/shale/branches/mvn_reorg/spring/src/main/java/org/apache/ shale/ struts/shale/branches/mvn_reorg/spring/src/main/java/org/apache/ shale/spring/ - copied from r410974, struts/shale/branches/mvn_reorg/core- library/src/java/org/apache/shale/spring/ struts/shale/branches/mvn_reorg/spring/src/main/resources/ struts/shale/branches/mvn_reorg/spring/src/main/resources/META- INF/ struts/shale/branches/mvn_reorg/spring/src/main/resources/META- INF/faces-config.xml - copied unchanged from r410974, struts/shale/branches/ mvn_reorg/core-library/src/java/org/apache/shale/spring/faces- config.xml struts/shale/branches/mvn_reorg/tiles/src/ struts/shale/branches/mvn_reorg/tiles/src/main/ struts/shale/branches/mvn_reorg/tiles/src/main/java/ struts/shale/branches/mvn_reorg/tiles/src/main/java/org/ struts/shale/branches/mvn_reorg/tiles/src/main/java/org/apache/ struts/shale/branches/mvn_reorg/tiles/src/main/java/org/apache/ shale/ struts/shale/branches/mvn_reorg/tiles/src/main/java/org/apache/ shale/tiles/ - copied from r410974, struts/shale/branches/mvn_reorg/core- library/src/java/org/apache/shale/tiles/ struts/shale/branches/mvn_reorg/tiles/src/main/resources/ struts/shale/branches/mvn_reorg/tiles/src/main/resources/META-INF/ struts/shale/branches/mvn_reorg/tiles/src/main/resources/META- INF/faces-config.xml - copied unchanged from r410974, struts/shale/branches/ mvn_reorg/core-library/src/java/org/apache/shale/tiles/faces- config.xml Removed: struts/shale/branches/mvn_reorg/core-library/src/conf/ struts/shale/branches/mvn_reorg/core-library/src/designtime/ struts/shale/branches/mvn_reorg/core-library/src/java/ struts/shale/branches/mvn_reorg/core-library/src/main/java/org/ apache/shale/spring/ struts/shale/branches/mvn_reorg/core-library/src/main/java/org/ apache/shale/tiles/ struts/shale/branches/mvn_reorg/core-library/src/site/xdoc/ navigation.xml struts/shale/branches/mvn_reorg/core-library/src/site/xdoc/ xdocs/navigation.xml struts/shale/branches/mvn_reorg/core-library/src/test/org/ struts/shale/branches/mvn_reorg/core-library/xdocs/
Re: Maven Reorg (Was -- Re: [shale] Maven 2 build -- Help Wanted)
On 6/1/06, Sean Schofield [EMAIL PROTECTED] wrote: I ran all but the tiger script. There are a ton of errors still in the core tests but we're making progress. One problem seems to be with AbstractJsfTestCase and a null pointer when referencing the servletContext variable from a subclass. My guess is that there is a missing configuration resource. @Craig: Any ideas? Try running mvn -Pmyfaces test and then examine the output in target. All of the necessary resource files shoudl be in the classes or test-classes dirs. If not, then we missed something. I'll pull the mvn_reorg stuff and check this out. Sean Craig On 6/1/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 6/1/06, Sean Schofield [EMAIL PROTECTED] wrote: So I can run svn move foo/bar foo/buzz locally and then commit foo? This is the same as svn move https://foo.com/foo/bar https://foo.com/foo/buzz? Yes, exactly the same. The advantage is that you can do multiple commands locally, preview the results, and then commit all the changes at once. There are some limits, occasionally Subversion will complain that you need to commit before executing some command that you're trying to do. (Which is why that first script is separate.) Whatever is easier for you, though, it ends up being the same when you're done. -- Wendy - 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: Maven Reorg (Was -- Re: [shale] Maven 2 build -- Help Wanted)
On 6/1/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 6/1/06, Sean Schofield [EMAIL PROTECTED] wrote: I ran all but the tiger script. There are a ton of errors still in the core tests but we're making progress. One problem seems to be with AbstractJsfTestCase and a null pointer when referencing the servletContext variable from a subclass. My guess is that there is a missing configuration resource. @Craig: Any ideas? Try running mvn -Pmyfaces test and then examine the output in target. All of the necessary resource files shoudl be in the classes or test-classes dirs. If not, then we missed something. I'll pull the mvn_reorg stuff and check this out. @Sean/@Wendy: Is there any way to teach Maven to use an HTTP proxy when it does it's dependency downloads, like you can tell Subversion to? I spend most of my time connected to Sun's VPN network, and right now I have to disconnect from that to do the Maven stuff -- not fatal, but it's sure a pain. Sean Craig Craig On 6/1/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 6/1/06, Sean Schofield [EMAIL PROTECTED] wrote: So I can run svn move foo/bar foo/buzz locally and then commit foo? This is the same as svn move https://foo.com/foo/bar https://foo.com/foo/buzz? Yes, exactly the same. The advantage is that you can do multiple commands locally, preview the results, and then commit all the changes at once. There are some limits, occasionally Subversion will complain that you need to commit before executing some command that you're trying to do. (Which is why that first script is separate.) Whatever is easier for you, though, it ends up being the same when you're done. -- Wendy - 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: Maven Reorg (Was -- Re: [shale] Maven 2 build -- Help Wanted)
On 6/1/06, James Mitchell [EMAIL PROTECTED] wrote: Is this what you need? http://maven.apache.org/guides/mini/guide-proxies.html Yes! Thanks ... but it leads to a stupid newbie question ... where's the user settings file go? :-) -- James Mitchell Craig On Jun 2, 2006, at 12:31 AM, Craig McClanahan wrote: On 6/1/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 6/1/06, Sean Schofield [EMAIL PROTECTED] wrote: I ran all but the tiger script. There are a ton of errors still in the core tests but we're making progress. One problem seems to be with AbstractJsfTestCase and a null pointer when referencing the servletContext variable from a subclass. My guess is that there is a missing configuration resource. @Craig: Any ideas? Try running mvn -Pmyfaces test and then examine the output in target. All of the necessary resource files shoudl be in the classes or test-classes dirs. If not, then we missed something. I'll pull the mvn_reorg stuff and check this out. @Sean/@Wendy: Is there any way to teach Maven to use an HTTP proxy when it does it's dependency downloads, like you can tell Subversion to? I spend most of my time connected to Sun's VPN network, and right now I have to disconnect from that to do the Maven stuff -- not fatal, but it's sure a pain. Sean Craig Craig On 6/1/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 6/1/06, Sean Schofield [EMAIL PROTECTED] wrote: So I can run svn move foo/bar foo/buzz locally and then commit foo? This is the same as svn move https://foo.com/foo/bar https://foo.com/foo/buzz? Yes, exactly the same. The advantage is that you can do multiple commands locally, preview the results, and then commit all the changes at once. There are some limits, occasionally Subversion will complain that you need to commit before executing some command that you're trying to do. (Which is why that first script is separate.) Whatever is easier for you, though, it ends up being the same when you're done. -- Wendy - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven Reorg (Was -- Re: [shale] Maven 2 build -- Help Wanted)
On 6/1/06, James Mitchell [EMAIL PROTECTED] wrote: I keep mine here: ~/.m2/settings.xml That did the trick ... thanks James! -- James Mitchell Craig On Jun 2, 2006, at 12:38 AM, Craig McClanahan wrote: On 6/1/06, James Mitchell [EMAIL PROTECTED] wrote: Is this what you need? http://maven.apache.org/guides/mini/guide-proxies.html Yes! Thanks ... but it leads to a stupid newbie question ... where's the user settings file go? :-) -- James Mitchell Craig On Jun 2, 2006, at 12:31 AM, Craig McClanahan wrote: On 6/1/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 6/1/06, Sean Schofield [EMAIL PROTECTED] wrote: I ran all but the tiger script. There are a ton of errors still in the core tests but we're making progress. One problem seems to be with AbstractJsfTestCase and a null pointer when referencing the servletContext variable from a subclass. My guess is that there is a missing configuration resource. @Craig: Any ideas? Try running mvn -Pmyfaces test and then examine the output in target. All of the necessary resource files shoudl be in the classes or test-classes dirs. If not, then we missed something. I'll pull the mvn_reorg stuff and check this out. @Sean/@Wendy: Is there any way to teach Maven to use an HTTP proxy when it does it's dependency downloads, like you can tell Subversion to? I spend most of my time connected to Sun's VPN network, and right now I have to disconnect from that to do the Maven stuff -- not fatal, but it's sure a pain. Sean Craig Craig On 6/1/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 6/1/06, Sean Schofield [EMAIL PROTECTED] wrote: So I can run svn move foo/bar foo/buzz locally and then commit foo? This is the same as svn move https://foo.com/foo/bar https://foo.com/foo/buzz? Yes, exactly the same. The advantage is that you can do multiple commands locally, preview the results, and then commit all the changes at once. There are some limits, occasionally Subversion will complain that you need to commit before executing some command that you're trying to do. (Which is why that first script is separate.) Whatever is easier for you, though, it ends up being the same when you're done. -- Wendy - 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] - 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: Maven Reorg (Was -- Re: [shale] Maven 2 build -- Help Wanted)
On 6/1/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 6/1/06, Sean Schofield [EMAIL PROTECTED] wrote: I ran all but the tiger script. There are a ton of errors still in the core tests but we're making progress. Core library builds and all the tests pass: mvn clean install -Pmyfaces Works for me now as well, with your latest patches. But shouldn't it also work without the -Pmyfaces because it's got activeByDefault set? By the way (if you beat me to it), the sql-browser example app also requires JDK 1.5 (an the tiger library). Craig It was a combination of a missing 'documentRoot' system property, and not having all of the non-Java resources in the right place in the jar file. The Ant build also copies messages.properties - message_en.properties, which isn't in the Maven build yet. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
