On 3/10/07, James Mitchell [EMAIL PROTECTED] wrote:
After nearly a 1 year hiatus to work on a JSF gig, my client has
decided not to continue down the JSF route, and on a personal note, I
couldn't be happier. I really hope JSF 1.2 does for JSF what EJB3/
JPA did for EJB2. I have not been having
On 3/10/07, James Mitchell [EMAIL PROTECTED] wrote:
That said, I would look at the portlet support, but I'm probably the
least qualified to work on that. If you still have no one to
volunteer, I can look at it next week.
At this point, the next step is to migrate it to a plugin, as Musachy
Musachy,
since the said patch was done to TextUtil, bamboo isn't any longer
complaining about weird characters. The last build complaining is
http://opensource.bamboo.atlassian.com/browse/STRUTS-MAIN-203
Since
http://opensource.bamboo.atlassian.com/browse/STRUTS-MAIN-204 the only
complaints
Updating symbolic links isn't on the S2 distribution punchlist
* http://struts.apache.org/2.0.6/docs/creating-and-signing-a-distribution.html
which means I haven't been doing it. (This list really, really,
really, is exactly what I've been doing; no more, no less.)
It also means that I don't
what's my failure means?
[INFO] Surefire report directory:
D:\mvntest\tutorial\target\surefire-reports
org.apache.maven.surefire.booter.SurefireExecutionException: Unable to
create te
st class 'tutorial.HelloWorldActionTest'; nested exception is
java.lang.ClassNot
FoundException:
The project Struts 2 SVN - Main Build has the following 1 change by 1 author:
*husted* made the following changes at 10:31 AM, 11 March 2007
Comment:
WW-1781 - Set DevMode to false for example applications. Remove other redundant
or obsolete settings. Conform indentation n struts-default.xml.
The project Struts 2 SVN - Main Build has the following 1 change by 1 author:
*husted* made the following changes at 10:51 AM, 11 March 2007
Comment:
WW-1707 Apply consistent naming for the interceptors in struts-default.xml per
report by Philip Luppens. Update example applications to use new
I amended the log entry for this commit to point to our online copy of
the prior history.
svn propset --revprop -r 514083 svn:log WW-1607 Separate dojo-related tags into their own
plugin. For prior history see
http://svn.apache.org/viewvc?view=revrevision=514082
*
On 3/11/07, Ted Husted [EMAIL PROTECTED] wrote:
Updating symbolic links isn't on the S2 distribution punchlist
*
http://struts.apache.org/2.0.6/docs/creating-and-signing-a-distribution.html
which means I haven't been doing it. (This list really, really,
really, is exactly what I've been
On 3/11/07, Martin Cooper [EMAIL PROTECTED] wrote:
Now we are specifically being told to *not*
create symbolic links! In fact, the instructions seem to indicate that the
'current' links probably shouldn't be created any more.
Thanks, Martin. Let's delete them, then... one less step in the
This has gone on long enough - there will be no more commits until the build
has been fixed. Currently, I'm seeing compilation problems in the tiles
plugin and 22 tests broken due to the consistent naming commit. Until the
build has been fixed and all tests pass, only commits that address these
I may have broken some of them this morning by removing
struts.properties from the apps. I'm looking now.
-Ted.
On 3/11/07, Don Brown [EMAIL PROTECTED] wrote:
This has gone on long enough - there will be no more commits until the build
has been fixed. Currently, I'm seeing compilation
Ok, I believe I fixed all the build problems for trunk and 2.0.x. Bamboo is
having some problem accessing the SVN server, so it'll be a bit before it
can confirm the build, but everything is working on my box. I created a
plan for 2.0.x, so expect to see notifications once Bamboo is working
Thanks, Don. It's good to be back on track again.
I'd also suggest that if the build or tests is broken when you want to
commit something, and you don't see how to fix it, go ahead and roll
back the last commit, so that it does build, and then commit your own
changes. Otherwise, we end up with
I'm having trouble obtaining a clean checkout of the Struts2 head. SVN
complains:
Astruts2\core\src\site\resources\tags\ajax\datetimepicker.html
svn: In directory 'struts2\core\src\site\resources\tags\ajax'
svn: Can't copy 'struts2\core\src\site\resources\tags\ajax\.svn\tmp\text-base\ta
Same here, there are 2 files with the same name...
[EMAIL PROTECTED] ~/svn/struts]$ svn info https://svn.apache.org/repos/
asf/struts/struts2/trunk/core/src/site/resources/tags/ajax/
tabbedPanel.html
Path: tabbedPanel.html
Name: tabbedPanel.html
URL:
And here's the difference...
[EMAIL PROTECTED] ~/svn/struts]$ svn diff https://svn.apache.org/repos/
asf/struts/struts2/trunk/core/src/site/resources/tags/ajax/
tabbedpanel.html https://svn.apache.org/repos/asf/struts/struts2/
trunk/core/src/site/resources/tags/ajax/tabbedPanel.html
Index:
Something broke with the tabbedPanel/tabbedpanel
renaming; case-sensitivity issue w/ the old files
still being in the repo?
--- Ted Husted [EMAIL PROTECTED] wrote:
I'm having trouble obtaining a clean checkout of the
Struts2 head. SVN
complains:
A
I believe that these are generated Javadoc files that we checkin for
the benefit of the snippet plugin. So, the answer would be to build it
and find out, except that I can't a checkout to build :)
-Ted.
On 3/11/07, James Mitchell [EMAIL PROTECTED] wrote:
And here's the difference...
[EMAIL
On 3/11/07, James Mitchell [EMAIL PROTECTED] wrote:
So, which is the right one?
The outer folder has a tabbedPanel, so I'm going to delete the other
one from Ajax subdirectory in the repository.
-Ted.
-
To unsubscribe,
On 3/11/07, Ted Husted [EMAIL PROTECTED] wrote:
I believe that these are generated Javadoc files that we checkin for
the benefit of the snippet plugin. So, the answer would be to build it
and find out, except that I can't a checkout to build :)
I deleted tabbedpanel.html, which had less
Why is struts-annotations under struts/maven if it is required in
core and dojo.
I'm sure I missed that discussion.
--
James Mitchell
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL
On 3/11/07, James Mitchell [EMAIL PROTECTED] wrote:
Why is struts-annotations under struts/maven if it is required in
core and dojo.
I'm sure I missed that discussion.
Yes. Check the archives. :) It's apparently not Struts 2 specific.
Also, like the master pom, it has to be released prior
There is an open issue to rename tabbedPanel to tabbedpanel, I think it
even was in the commit comments, so I probably didn't delete the old one
(tabbedPanel), and I'm on linux so it wouln't be a problem for me and I
didn't notice.
musachy
On 3/11/07, Wendy Smoak [EMAIL PROTECTED] wrote:
On
By the way, I've been making changes to it that I wouldn't be comfortable
getting together with the 2.0 branch.
musachy
On 3/11/07, Wendy Smoak [EMAIL PROTECTED] wrote:
On 3/11/07, James Mitchell [EMAIL PROTECTED] wrote:
Why is struts-annotations under struts/maven if it is required in
Jim, if you do find the discussion, can you please create a wiki
page or something for it?
It's still not clear to me why it needs to be released separately. The
justification for the archetypes almost makes sense, but creating a
separate distribution for Struts Annotations still seems like busy
On 3/11/07, Musachy Barroso [EMAIL PROTECTED] wrote:
By the way, I've been making changes to it that I wouldn't be comfortable
getting together with the 2.0 branch.
Then maybe we should bump SA to a 1.1.0-SNAPSHOT. Otherwise, things
could get sticky if for some reason we need to bring a new SA
On 3/11/07, Ted Husted [EMAIL PROTECTED] wrote:
It's still not clear to me why it needs to be released separately. The
justification for the archetypes almost makes sense, but creating a
separate distribution for Struts Annotations still seems like busy
work.
No one objects to releasing the
On 3/11/07, Ted Husted [EMAIL PROTECTED] wrote:
No one objects to releasing the struts-master pom, and it's the same
situation.
And, I don't understand why we do that either (which is why I've never
voted on the Struts pom).
-Ted.
On 3/11/07, Ted Husted [EMAIL PROTECTED] wrote:
On 3/11/07, Wendy Smoak [EMAIL PROTECTED] wrote:
On 3/11/07, Ted Husted [EMAIL PROTECTED] wrote:
It's still not clear to me why it needs to be released separately. The
justification for the archetypes almost makes sense, but creating a
On 3/11/07, Ted Husted [EMAIL PROTECTED] wrote:
On 3/11/07, Ted Husted [EMAIL PROTECTED] wrote:
No one objects to releasing the struts-master pom, and it's the same
situation.
And, I don't understand why we do that either (which is why I've never
voted on the Struts pom).
The POM needs
On 3/11/07, Martin Cooper [EMAIL PROTECTED] wrote:
The POM needs to be published to the standard Maven repo, so that it's there
as a versioned dependency that can be relied upon by other parts of the
project.
Do we have multiple parts for Struts 2?
We tried subprojects for Struts 1, and
For Struts 2, we decided not to make plugins separate subprojects.
Why can't POM, Archetype, and Annotation be on the same build tree
with Core and Plugins?
I believe Don said Plug-ins could be used in other projects...
theoretically even Struts 1. So it's technically a separate project with
On 3/11/07, Ted Husted [EMAIL PROTECTED] wrote:
Unfortunately, until we start using Maven to do releases,
I don't know what that means. What else would we need to do?
Some variation on mvn release:prepare and mvn release:perform with
-P whatever-profiles-struts2-needs and probably a few
On 3/11/07, Paul Benedict [EMAIL PROTECTED] wrote:
I believe Don said Plug-ins could be used in other projects...
theoretically even Struts 1. So it's technically a separate project with
its own build cycle.
Unless and until an actual community forms around Struts Annotations
and other people
On 3/11/07, Martin Cooper [EMAIL PROTECTED] wrote:
Unless I'm missing something, it's because we want to be able to release
some pieces (e.g. plugins) without requiring a corresponding release of
'core'. If a plugin depends on an updated version of struts-annotations (or
whatever), it shouldn't
Annotations was originally setup as a separate JAR with an independent
version so as to encourage reuse. However, until other product
indicate an interest in using Annotaitons and participating in its
development, managing a separate release process provides no tangible
benefit. Therefore, it's
On 3/11/07, Ted Husted [EMAIL PROTECTED] wrote:
Annotations was originally setup as a separate JAR with an independent
version so as to encourage reuse. However, until other product
indicate an interest in using Annotaitons and participating in its
development, managing a separate release
38 matches
Mail list logo
