I agree that its time for Shale to find a new home. I actually think
that living here in the Struts project is holding Shale back more then
its helping at this point. I also feel that Shale is still a little
ahead of its time. JSF is still gaining acceptance and Shale builds
on JSF.
Imagine
@Sean or anyone who knows,
Can we do nightlies with Continuum? I didn't think that was
possible, but I seem to remember some discussion about it somewhere.
Yes its definitely possible. See the myfaces continuum[1] for
details. The nightly part was a group effort so I can't speak to all
of
Clean checkout and build works like a charm. I will try to take a
look and see what else needs doing.
Sean
On 6/18/06, Sean Schofield [EMAIL PROTECTED] wrote:
I see I am too late to add my +1. Thanks for the work Craig. I will
try and test this on Monday.
Sean
ps. The continuum server
I see I am too late to add my +1. Thanks for the work Craig. I will
try and test this on Monday.
Sean
ps. The continuum server is just sitting idly. We could start adding
projects to it now if we wanted.
On 6/16/06, James Mitchell [EMAIL PROTECTED] wrote:
+1 -- Everything looks great.
--
Do we need to create a jira issue even if its just changing some javadoc, like
typo or snippet id is wrongly assigned etc.?
IMO that's overkill.
Sean
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands,
Craig,
James and I are going to attempt to setup the Shale continuum server
on Wednesday. Should we try to setup the publishing of Shale
nightlies as well?
Sean
On 6/12/06, Craig McClanahan [EMAIL PROTECTED] wrote:
For those of you following Shale, you've probably noticed that there have
not
That would be awesome! But I wouldn't bother setting up the Ant based
builds, though; the focus should be on getting the Maven based things to
work. A wrinkle is you might have to be a bit adaptable on the assembly
stuff, as we're not quite done creating that. And, that actually raises a
it on my calendar.
--
James Mitchell
On Jun 5, 2006, at 11:22 PM, Sean Schofield wrote:
I'd say set up our own continuum instance in the struts zone. It
wasn't too difficult to do for MyFaces. This way we have complete
control and reliability. Eventually we may want to auto deploy
examples
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
I'd say set up our own continuum instance in the struts zone. It
wasn't too difficult to do for MyFaces. This way we have complete
control and reliability. Eventually we may want to auto deploy
examples to the zone as well. There is much more flexability this
way.
My plate is fairly full but
Everything (including bug fixes) should be going in the mvn_reorg
branch. Ignore the test repo from now on.
Sean
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
Suggestion:
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
+1 for shale-core, shale-test, shale-clay, etc., as directory names
matching the artifactIds.
Done
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.
Are you suggesting changing the artifact id
* I presume we don't have to list the individual applications themseves in
the
shale-parent-pom file, because things get processed hierarchically?
Not sure what you mean by this. If you mean shale/pom.xml and including:
modules
moduleshale-clay/module
I set up a new branch[1] for performing the maven reorg for shale as
we discussed in the other thread. For now lets reorg everything as if
we are using a single trunk for all of the shale modules. It will
be easier to reorg this way for now and if we decide to break them out
we can do that
don't.
Sean
On 6/1/06, Wendy Smoak [EMAIL PROTECTED] wrote:
On 6/1/06, Sean Schofield [EMAIL PROTECTED] wrote:
The next step is to replicate all of the changes Wendy made using her
script. I need to leave the office for a few hours but if nobody does
this while I'm gone I will see what I
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.
Sean
On 6/1/06, Wendy Smoak [EMAIL PROTECTED] wrote:
On 6/1/06, Sean Schofield
You once explained how you worked around something similar in MyFaces,
any advice for this one?
Change the dependency in core-library to be a *released* version of shale-test.
Wendy
Sean
-
To unsubscribe, e-mail: [EMAIL
@Craig:
Is there any special reason for a designtime dir? Can these be
compiled with the source in src/main/java? If not, we can deviate
from m2 defaults and specify this additional source directory but
maven is happier if you stick with its standard layout.
Sean
On 5/30/06, Sean Schofield
I guess things depend on how often you envision the two modules
changing in the future. If test is more likely to change, you can
make the core ref in test be the
On 5/31/06, Wendy Smoak [EMAIL PROTECTED] wrote:
On 5/31/06, Sean Schofield [EMAIL PROTECTED] wrote:
You once explained how you
, Sean Schofield [EMAIL PROTECTED] wrote:
Is there any special reason for a designtime dir?
Can these be compiled with the source in src/main/java?
It's a separate artifact in the Ant build (shale-designtime.jar) so
it's a separate module in the Maven project structure. Is that what
you were
PS.
core-library tests are now compiling although there are several failures
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Why a sub-project of core? It's a separate, optional jar, like
shale-tiger. I think it belongs in shale/designtime as its own
module.
I agree ... and, if I understood you correctly, switching to a Maven build
will require not only this, but also splitting up core into separate modules
for
I can see a reason to have Clay and Test Framework on separate trunks,
but I'm not so sure that spring and tiles really need a separate
release cycle from core.
Well if we don't split out tiles and spring, whenever you release a
new core, you are going to release a new spring and tiles jar
? I wasn't sure if you needed to make a new copy in
light of Craig's dependency solution.
Sean
On 5/31/06, Sean Schofield [EMAIL PROTECTED] wrote:
I can see a reason to have Clay and Test Framework on separate trunks,
but I'm not so sure that spring and tiles really need a separate
release cycle
I'm lost, though, with what you did in designtime. First you
suggested separate trunks for everything, and now you want designtime
(but not spring or tiles) underneath core?
Well design time is inherently linked to core. It makes no sense to
release one without the other. With shale-test,
Using main works for me if we want to go this way.
I would stay away from main b/c we have src/main/java when following
the maven convention. I would suggest core (again if we go this way.)
But, does apps really belong underneath main (I can see the logic on the
rest of them)? And, do we
Sean, why don't you go ahead and check in what you've got, and don't
worry too much about recording the commands it took to get there
exactly. With the test repo as a reference, we'll be able to figure
it out.
I don't want to lose momentum, and it's easier to discuss the project
structure when
I basically do not have internet access while onsite at my newest
client.
Are they Amish?
James Mitchell
Sean
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
I checked in some minor fixes to the core POM. I added a dependency
(test scope) to shale-test. There are still missing source files in
the core library. I think src/designtime also needs to be moved to
src/main in the m2 reorg.
Sean
On 5/27/06, Wendy Smoak [EMAIL PROTECTED] wrote:
I've made
MyFaces has a continuum server setup in our zone. The newest version
of continuum seems to work quite nice and email notification can be
limited to failure only if you don't want the high traffic.
Sean
On 5/30/06, Wendy Smoak [EMAIL PROTECTED] wrote:
On 5/26/06, Martin Cooper [EMAIL
+1
On 5/3/06, Wendy Smoak [EMAIL PROTECTED] wrote:
We need to release version 2 of the struts-parent pom:
* http://svn.apache.org/repos/asf/struts/maven/trunk/pom/pom.xml
This is the parent pom from which struts-action-parent inherits, and
it needs to be released prior to the Struts Action
[
http://issues.apache.org/struts/browse/SHALE-48?page=comments#action_37197 ]
sean schofield commented on SHALE-48:
-
This issue hasn't really been fixed. Its was resolved as Later in bugzilla.
Its still a pretty bug. I think we should reopen
So you are suggesting Tiles be decoupled from Struts Action and Shale
so that it can be compiled independent of these modules? Definite +1
and this was my impression all along as well.
As for top level project, I agree that Tiles probably belongs here but
I'm not opposed. For me the main thing
Should we just make the bare minimum changes to get Tiles
out of the sandbox or is it worth it to do major surgery?
+1
Tiles is pretty mature and I don't sense a lot of interest in
perfecting it. It would be nice to have it stand on its own
(dependency wise) but I'm not volunteering. Tiles
Don,
I've been off the list for a while now but can you explain why this is
a completely separate JIRA instance from the other ASF projects? Why
not use the existing one at http://issues.apache.org/jira?
+1 (as always) for migrating to JIRA. I find Bugzilla to be
unbearable compared to JIRA.
to
have their own JIRA project, and helps
isolate problems so that one instance won't bring all projects down.
It also made the migration of existing WebWork tickets much easier, if not
even possible.
Don
Sean Schofield wrote:
Don,
I've been off the list for a while now but can you
Ideally not. It's already going to be painful to split up the core-library
package (which now produces several JAR files) into separate modules solely
because Maven likes one artifact per module.
Shale publishes information on API stability (
I'd love to see Shale move to M2. I'll try to help with the limited
Maven knowledge that I have gleaned from the MyFaces experience. I'd
recommend starting out with a proposed hierarchy and set of artifiacts
as a starting point. See if we can get the basics squared away first
before sweating
[Moving this aspect of the discussion from myfaces to struts list ...]
On 4/7/06, Jacob Hookom [EMAIL PROTECTED] wrote:
Covered here a bit:
http://weblogs.java.net/blog/jhook/archive/2006/03/the_new_servlet_1.html
@Jacob:
Great blog entry!
@ Struts Dev:
I recommend you check this out.
Agreed. I handled this in scripting by adding an element to each dependency
declaration marking it as optional or not.
I used this new element to create the release notes (combined with
changes.xml) as well as create website docs.
Perhaps we could do something similar in Maven 2.
Maven2
But does MyFaces depend on Tomahawk components at compile time? This is
the circular link that has me concerned.
No, that part is different. Its a one-way dependency. I guess there
is nothing that Maven2 can do for you then.
Don
Sean
Meanwhile, it was also deployed to
cvs.apache.org/maven-snapshot-repository, so the repository element
in the struts-action-parent pom will allow Maven to pick it up from
there. Once it shows up on ibiblio, I'll remove it from the snapshot
repo.
Does that actually work? I figured Maven
On MyFaces we took a vote on version 1.0 of our master pom. For
version 1.0.1 I put it in the apache maven repo directory and planned
to take a vote before publishing to ibiblio. Apparently it got
published anyways so we ended up releasing without voting.
I think for something as trivial as a
+1 for master poms for the committers, etc. It works well on MyFaces.
Sean
On 4/8/06, Wendy Smoak [EMAIL PROTECTED] wrote:
On 4/8/06, Patrick Lightbody [EMAIL PROTECTED] wrote:
There has been a semi-working build for maven 2 included with WebWork
for a few months, but I'd like to make
Alpha and beta releases on ibiblio (for maven purposes) works for me.
Final releases on the ASF mirror network.
Sean
On 3/28/06, Craig McClanahan [EMAIL PROTECTED] wrote:
On 3/27/06, Wendy Smoak [EMAIL PROTECTED] wrote:
On 3/26/06, Craig McClanahan [EMAIL PROTECTED] wrote:
It was
+1 (non binding) for Alpha
On 3/23/06, Gary VanMatre [EMAIL PROTECTED] wrote:
+1 for Alpha as well. Outside of the one known issue with the sql-browser
application, it looks good. Nice work Wendy.
Gary
-- Original message --
From: Wendy Smoak [EMAIL PROTECTED]
On 2/18/06, Craig McClanahan [EMAIL PROTECTED] wrote:
On 2/18/06, Sean Schofield [EMAIL PROTECTED] wrote:
I believe the problem I was not running the entire test suite of
myfaces tests in my IDE. When I ran them in Maven, I believe an
earlier test was calling the get method
of the MyFaces tests to use it!
On 2/17/06, Sean Schofield [EMAIL PROTECTED] wrote:
Yeah I was thinking that maven is relying on the jars and since there
is a config file in there the myfaces render kit is getting loaded
instead.
I will check into it. Thanks.
Sean
On 2/17/06, Craig McClanahan [EMAIL
I am trying to use the mock stuff in my app. The test works fine in
my IDE (1.4.2_04-b05) but does not run in maven (1.4.2_08-b03.)
Specifically, the class cast exception is on line 131:
renderKit = (MockRenderKit)
renderKitFactory.getRenderKit(null,
I'm attaching my test case. Its a test for the latest MyFaces trunk code.
/*
* Copyright 2006 The Apache Software Foundation.
*
* Licensed under the Apache License, Version 2.0 (the License);
* you may not use this file except in compliance with the License.
* You may obtain a copy of the
:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
On 2/17/06, Craig McClanahan [EMAIL PROTECTED] wrote:
On 2/17/06, Sean Schofield [EMAIL PROTECTED] wrote:
I'm attaching my test case. Its a test for the latest
That is weird.
On 2/16/06, Craig McClanahan [EMAIL PROTECTED] wrote:
Thanks Ryan. Interesting that the mis-typed version actually worked in both
1.1 implementations :-).
Craig
On 2/16/06, Ryan Lubke [EMAIL PROTECTED] wrote:
Index: sql-browser/src/web/query.jsp
Yeah I was thinking that maven is relying on the jars and since there
is a config file in there the myfaces render kit is getting loaded
instead.
I will check into it. Thanks.
Sean
On 2/17/06, Craig McClanahan [EMAIL PROTECTED] wrote:
On 2/17/06, Sean Schofield [EMAIL PROTECTED] wrote
Wendy,
With m2 wouldn't you just give this a scope of test?
Sean
On 1/26/06, Wendy Smoak [EMAIL PROTECTED] wrote:
On 1/26/06, Craig McClanahan [EMAIL PROTECTED] wrote:
I can see why these two have to be declared, since the Shale code directly
depends on them. But HtmlUnit itself ships
I know it seems weird but once you get used to it its not that bad ;-)
On 1/25/06, Wendy Smoak [EMAIL PROTECTED] wrote:
On 1/25/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: mrdon
Date: Wed Jan 25 17:25:11 2006
New Revision: 372389
URL:
Trust me, you didn't miss anything. The things discussed offlist, as I do
with yourself, Martin and others are almost always unrelated to decision
making. I'm glad I was able to help Wendy and others get up to speed with
what I had done so far with Maven, and since then she has far surpassed
The problem with chat is that not everyone is available to participate
at the designated time that people decide to have a chat. As I
mentioned earlier, there are timezone differences and day job
commitments that make it difficult for everyone to participate in a
discussion simultaneously.
So by
Once the chat transcript is posted, people can reply to it
asynchronously, like anything else. Back when we were setting up
Maven, James and Wendy mentioned that had a few chats while getting
everything configured. If they were chatting in a place that was
automatically transcripted, some of
I agree with Ted about the importance of mailing lists. Mailing lists
are the Apache Way. The only time I have used off-llist
communication is during an infrastructure move where we needed to
rapidly complete several steps in a short period of time. Even then
the basic outline of work was
IMHO, it sounds like Jive is not up to the task of managing an
ASF-style dev list. Any decent mailreader can filter mails into
whatever folders we find convenient, creating the personal equivalent
of five or six separate lists, if that's what someone wants.
GMail also has *excellent* search
Time to catch up with my Struts emails ... I haven't looked at Shale
Tiger yet so I can't comment on that part.
As for the dialogs, I prefer XML configuration similar to what we
already have. Our dialogs are pretty complicated and its hard to
imagine the more sophisticated aspects of Shale
* (Optional) alternative dynamic execution mapping to execute a Commons
Chain command
(essentially equivalent to the current functionality, and/or a tie-in to
Struts Action Framework 1.3.x
type processing logic).
David has some good points about Chain being a bit of overkill. I
didn't
[X ] Alpha
[ ] Beta
[ ] General Availability (GA)
Non binding ...
On 12/23/05, Wendy Smoak [EMAIL PROTECTED] wrote:
On 12/5/05, Craig McClanahan [EMAIL PROTECTED] wrote:
Once you have had a chance to assess to quality of this build, please
respond with a vote on the quality:
[X] Alpha
Logon Dialog
* After clicking into the logon dialog accidentally and pressing back
to return to the menu without logging in, an HTTP Status 500 error is
exposed, compelling a restart of the application.
--
javax.servlet.ServletException: Position[dialogName=Log
On,stateName=Logon
Rich,
It was nice meeting you at Apache Con. Welcome to the team.
sean
On 12/19/05, Matthias Wessendorf [EMAIL PROTECTED] wrote:
Welcome Rich,
good news on that!
;)
Greetings,
Matthias
-Original Message-
From: Don Brown [mailto:[EMAIL PROTECTED]
Sent: Sunday, December 18,
FYI Dakota Jack is a troll. Please don't encourage him, even if you
agree with his position.
sean
On 12/16/05, Patrick Lightbody [EMAIL PROTECTED] wrote:
This sounds familiar :)
I definitely would recommend changing the slides and title of the
presentation. Just yesterday I ran in to this:
I think my favorites are just managing the import statements,
identifying unused members, and precompiling the code as I work. It's
now very rare for me to run a make and have it fail.
Yes I forgot to mention precompiling. That is a HUGE benefit. That
will save you several hours over the
What is a classpath?
Are you going to be at Apache Con? If so we can get together over
dinner and I can explain it to you ;-)
Niall
sean
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL
Please keep in mind that there are still a good number of people who do
not use an IDE at all.
Why on earth would you someone do such a thing? Seriously. I'd like
to know :-)
Frank W. Zammetti
sean
-
To unsubscribe,
targeted usages, I can't imagine being in any of them all day.
Frank
Greg Reddin wrote:
On Dec 9, 2005, at 8:02 AM, Sean Schofield wrote:
Please keep in mind that there are still a good number of people who do
not use an IDE at all.
Why on earth would you someone do such a thing
There are plenty of way to debug. But what if you need to test Java 6
features BEFORE it's set in stone?
(Like I tried it, reported a bug w/ JDIC and Sun fixed it).
Does Java 6 work in your IDE?
That's a pretty specialized case. I haven't tried it but I don't see
why not. Most IDE's allow
I think a jsf-commons project would be nice. Craig's suggestions
certainly make for good candidates. There are a few in MyFaces that
would definitely be appropriate as well.
For MyFaces the plan is to rename the share subproject to commons
and to start releasing it as its own jar. In the
I haven't forgotten this. I probably won't get to testing until after
ApacheCon. Its going to be a mad dash to get my work done before
then.
sean
On 12/5/05, Craig McClanahan [EMAIL PROTECTED] wrote:
After completing the required steps in the Struts Shale 1.0.0 release plan:
We also create an artificial milestone called Future that we assign
things that are of the wish-list variety. We always schedule it after
all of the other versions so that it doesn't bog down the roadmap displays.
Same here. We use TBD.
-Paul
sean
I can't believe how much you like to punish yourself! Is anyone else
helping you with this massive effort? I'd offer to help but my
workload is at about 250% capacity right now.
When things stablize I'll take things for a spin in Shale.
sean
On 12/1/05, Greg Reddin [EMAIL PROTECTED] wrote:
I
+1
On 12/1/05, Laurie Harper [EMAIL PROTECTED] wrote:
+1 (non-binding)
L.
Craig McClanahan wrote:
All of the outstanding issues have been accounted for -- it's time to
release the initial test build of Shale! Given the amount of time since the
1.0.0 release plan was first proposed,
+1 for JIRA. I was going to suggest it right off the bat when the
WebWorks merger was proposed but I decided to hold back since nobody
seemed to like the suggestion the last time I made it ;-)
Martin is right about the SVN integration. You get some nice linkage
between issues and SVN revisions
I have a few thoughts on this and I will try to avoid the Which
framework is better? discussion.
Change is inevitable. Struts (as you know and use it today) will
eventually become obsolete. Nobody can say when the last meaningful
Struts 1.x application will be written but that day will
?
sean
On 11/28/05, Ted Husted [EMAIL PROTECTED] wrote:
On 11/27/05, Sean Schofield [EMAIL PROTECTED] wrote:
I agree that release candidates can be helpful with checking packaging
errors (and testing against TCK which is not an issue in this case.)
That's true, Sean, but what you may
Tags, not branches. We don't create a branch until we know we need it.
Yes but branches allow you to work out the kinks of your upcoming
release without introducing new bugs with the nightly fixes and new
features. I was suggesting that as a way to speed up the release
process.
Martin Cooper
I guess here is where I'm wondering why we need a framework to accomplish
this at all, given what JSF already provides? Consider something like this,
using JSP syntax:
h:panelGrid ... rendered=#{
securityChecks.managerOfAppropriateDepartment}
... components to conditionally
Yould can probably implement your own NavigationHandler. Check out
the DialogNavigationHandler in Shale. It implements custom navigation
handling on top of the JSF standard. You could try something similar.
sean
On 11/28/05, Laurie Harper [EMAIL PROTECTED] wrote:
Craig McClanahan wrote:
On
The purpose for a release candidate in this case is it's the first time ...
and we've already caught some packaging errors that need to be cleaned up.
Shale will follow the (overlapping and not always consistent) guidelines
posted on the Struts and Jakarta Commons web sites about x.y.z
In my Shale dialog I a single required field called foo. There is
also a command link with an action listner (no action method binding.)
The command link has the immediate attribute set to true (its only
purpose is to empty the foo component.
When I click the link the action listener resets the
[snip]
* When an immediate action (not actionListener) is used, the JSF runtime
calls FacesContext.responseComplete() to bypass validations and
model updates. That doesn't happen with an action listener unless you
do it for yourself.
I was not aware of the distinction. That explains why it
If a file was moved by someone else while you were working on it, I
think the best thing to do is a clean checkout in a separate dir.
Then copy the file change to the new dir and revert the change in the
old dir. Then remove the new dir and resume in the original dir after
you update.
Make
Gary,
I agree that EJB can be overkill in some instances. I wanted to use
transactions in my COR solution so I did some cool stuff with
commons-chain. I used the Filter object (extends Command) which
guarantees that its postprocess method will be called if its execute
method is called. I
I was hoping for some feedback on this design approach ..
I have a dialog with several different screens. One of the screens is
using inputSuggestAjax (a MyFaces - Tomahawk component.) The list of
choices that backs this input component is quite large (approx 8,000
choices.) I was hoping to
[snip]
I take it this is to avoid keeping the list around when you don't need it (
i.e. you're not on the view containing the Ajax component)? I presumeit must
be relatively cheap to populate the overall list in the first place?
Yes that is the point. Its cheap enugh to create it for each
Those are cool. You might also want to consider the tlddoc that we
are using in MyFaces [0]. Its pretty sweet. Also, when did everyone
star using the [n] footnote notation in their emails. Seems like a
few months ago this convention started becoming really popular. Its
growing on me ;-)
sean
You mentioned the action method in your previous email, I presume you
were refering to the DialogNavigationHandler's action method? That
would potentially tie behavior specific to this dialog (clearing some
backing bean) to the generic dialog processing, which would make that
approach far
Ah yes that is it. Maven does this for you? Interesting ...
sean
On 11/14/05, Wendy Smoak [EMAIL PROTECTED] wrote:
On 11/14/05, Sean Schofield [EMAIL PROTECTED] wrote:
Those are cool. You might also want to consider the tlddoc that we
are using in MyFaces [0]. Its pretty sweet.
You
Yeah Martin mentioned the same thing.
sean
On 11/10/05, Craig McClanahan [EMAIL PROTECTED] wrote:
On 11/8/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
+
+ h4 id=gvanmatreSean Schofield -- Committer/h4
+
You might want to consider adjusting the id value, lest you fall prey to
I know this conversation was over a week ago but I finally had some
time to get back to my mailing list backlog... (see inline comments
below)
How is this different from just encapsulating your setup logic into an
action method, and then calling it as the first state of the dialog
explicitly?
Rahul,
These are interesting use cases. I'm not sure that there is an easy
solution to these problems though. The back button and browser
cacheing are handy for the end user but certainly a PITA for
developers!
One option would be to use the Token Pattern (See Core J2EE
Patterns). Shale has
I am trying to get up to speed with the new Maven2 builds. I can't
build the site right now b/c I get an erroror about missing mojo
resources.
I am running 'mvn install' from the site's build dir.
TIA,
sean
-
To unsubscribe,
building ok. (Thank goodness I have
not lost mojo after all.)
sean
On 11/8/05, Wendy Smoak [EMAIL PROTECTED] wrote:
On 11/8/05, Sean Schofield [EMAIL PROTECTED] wrote:
I am trying to get up to speed with the new Maven2 builds. I can't
build the site right now b/c I get an erroror about
Actually I still need a little more help. 'maven site' generates new
xdocs but does not transform to HTML. Is there another maven command
to build the HTML? Are you guys using forrest or some other form of
xdocs?
TIA,
sean
On 11/8/05, Sean Schofield [EMAIL PROTECTED] wrote:
Maven 1.0.2
Ok its working now. I am trying to follow the golden rule of building
the site before checking in. You never know when you have
accidentally messed up an xdoc somewhere.
sean
On 11/8/05, Wendy Smoak [EMAIL PROTECTED] wrote:
On 11/8/05, Sean Schofield [EMAIL PROTECTED] wrote:
Actually I
1 - 100 of 216 matches
Mail list logo
