I'm using a stock download of 2.0.3.
Oh how I dream of finding the missing manual for Maven 2 command line
options :(
--
James Mitchell
On Apr 6, 2006, at 1:25 AM, Wendy Smoak wrote:
On 4/5/06, James Mitchell <[EMAIL PROTECTED]> wrote:
I was pleasantly surprised (after making my chan
On 4/5/06, James Mitchell <[EMAIL PROTECTED]> wrote:
> I was pleasantly surprised (after making my changes to the 4 or 5
> tests in core) to run 'mvn install' in struts/action/build/ and see
> the reactor kick off and fully build/test/install all/some of SAF.
> Same for compile, test, and a few ot
On 4/5/06, James Mitchell <[EMAIL PROTECTED]> wrote:
> Why 2.0.4? Building from source?!? Jeez! At least I'm not _that_
> bad ;)
Because 2.0.3 had some serious regressions, and it was just as easy to
grab the 2.0.4 release candidate as to go back to 2.0.2. It's the
plugins I'm building from so
Why 2.0.4? Building from source?!? Jeez! At least I'm not _that_
bad ;)
I'm more inclined to work on a Maven 2 build and just remove whatever
is in our way (e.g. failing tests, bad reports due to incomplete
plugins, etc) to get to a distributable release.
What do you think?
--
James Mi
That is probably what we would have done if we hadn't had to deal
with the {subproject}/build having to be svn:externals-ized into each
one.
I was pleasantly surprised (after making my changes to the 4 or 5
tests in core) to run 'mvn install' in struts/action/build/ and see
the reactor ki
On 4/5/06, James Mitchell <[EMAIL PROTECTED]> wrote:
> Notice the console outputs "FAILURE !!", which make it pretty easy to
> spot ;)
I notice it, I'm just not seeing it here. FWIW, I'm using a snapshot
of Maven 2.0.4 and quite a few plugins built from source. Maven 2 is
still a work in progre
Before my changes, they fail for me on maven 1, when instrumented for
jcoverage (which is the case for the 'dist' target) and maven 2 when
run normally (mvn install).
Maven 1
---
...
...
[junit] Running org.apache.struts.action.TestActionRedirect
[junit] Tests run: 5, Failures:
On 4/5/06, James Mitchell <[EMAIL PROTECTED]> wrote:
> Also, I'm about to start another thread related to our build...it is
> (more or less) notes as I go through the various project.xml,
> pom.xml, etc, etc for each of the pieces of the action1 puzzle.
What do you think about moving the build fi
On 4/5/06, Don Brown <[EMAIL PROTECTED]> wrote:
> Weird, so your Maven thinks that the tests fail? The tests pass for me, for
> the core module anyways.
The tests don't fail for me, either. They're just noisy with stack traces.
Don, 'maven nightly' continues to work fine here. I deleted
org.
James Mitchell wrote:
Funny you should mention this now. About 10 minutes ago I (locally)
commented the failing tests out (actually, I put 'no' in front of the
failing testFoo methods, so it looks like 'notestFoo') so I could 'mvn
eclipse:eclipse' core, taglib, and extras.
I'm not sure why t
Funny you should mention this now. About 10 minutes ago I (locally)
commented the failing tests out (actually, I put 'no' in front of the
failing testFoo methods, so it looks like 'notestFoo') so I could
'mvn eclipse:eclipse' core, taglib, and extras.
I'm not sure why the output of the tes
The "nightly" maven goal isn't working for me. It doesn't seem to be correctly executing the jar:install goal, causing
other artifact builds to fail due to missing dependencies. Perhaps someone seems something I'm missing from this
snippet from a nightly build:
+--
.current is now .gone and so now I just need to fix the good one to
actually work correctly and we'll have our nightlies back.
--
James Mitchell
On Apr 4, 2006, at 1:01 PM, James Mitchell wrote:
I believe the .current one is an older copy. I'll clean that up
shortly.
--
James Mitchell
I believe the .current one is an older copy. I'll clean that up
shortly.
--
James Mitchell
On Apr 3, 2006, at 6:26 PM, Wendy Smoak wrote:
On 4/3/06, James Mitchell <[EMAIL PROTECTED]> wrote:
The 'actual' shell script that gets run nightly via cron is not under
svn. Since we run nightli
On 4/3/06, James Mitchell <[EMAIL PROTECTED]> wrote:
> The 'actual' shell script that gets run nightly via cron is not under
> svn. Since we run nightlies on our zone, it is merely a copy of the
> one under svn and as changes come in, I review and then update my
> copy. It's probably an unnecessa
James Mitchell wrote:
Once we iron out action1 directories, I'll get that back online, but I'd
like to wait till the dust settles before I pick up incubator/action2
nightly builds.
If you are referring to the webwork2 incubated code, the only question mark in my mind relating to the build is
The 'actual' shell script that gets run nightly via cron is not under
svn. Since we run nightlies on our zone, it is merely a copy of the
one under svn and as changes come in, I review and then update my
copy. It's probably an unnecessary level of security, but as long as
my name and ASF
On 4/3/06, Don Brown <[EMAIL PROTECTED]> wrote:
> Also, I'm hoping the nightly build scripts will be unaffected, although
> I'd kinda be surprised. Let me know any way I can help fix them, if
> they are indeed broken.
It looks like Craig's are okay, but not the Maven-built ones. I made
a change
To add to that, I'll update the website to reflect the changes as soon
as they are all done. The only major one pending is the scripting move,
which I want to give a day or two to get any possible feedback.
Also, I'm hoping the nightly build scripts will be unaffected, although
I'd kinda be s
To summarize the reorganization, (thanks, Don!) the 'current'
svn:externals definition now contains:
action, scripting, sandbox, shale, tiles and site.
(I believe Don will also be moving scripting underneath action at some point.)
Action builds several jars: struts-core, struts-extras,
strut
On 4/1/06, Don Brown <[EMAIL PROTECTED]> wrote:
> I don't think anything. If you are happy with it, I can make the
> changes tomorrow.
The structure in the test repo looks fine to me.
> I'd like to get a test release for Struts Action by
> Sunday, even if it isn't a voted on one. I'm aiming fo
Wendy Smoak wrote:
Did you get what's in the test repo to build for you? It ('maven
nightly') works fine for me.
I wasn't able to get it working at work. I'll try again tomorrow from
this computer.
* http://svn.apache.org/repos/test/action1
What else needs to be done?
I don't think
On 3/31/06, Don Brown <[EMAIL PROTECTED]> wrote:
> Oh, one other thing - what about tiles? I noticed tiles has its own build
> now, so can I then assume it is standalone?
The Struts Tiles build is separate. I did that when I changed the
groupId, in anticipation of this reorg. However, struts-
Ok, moving to struts-action. I tried changing paths, but the jars still aren't installing themselves, making it so only
action will build. I'll keep trying, but I have this suspicion that you could fix this in about 5 minutes when you get
home :)
Overall, I'm happy with the way it looks and s
On 3/31/06, Don Brown <[EMAIL PROTECTED]> wrote:
> I suppose the directory could be called 'action', but it seems
> kinda silly to have 'action/trunk/action'. 'core' seems to be
> what other projects like Cocoon, MyFaces, Shale, etc., are using,
I'm fine with 'core', as long as the directory na
On 3/31/06, Wendy Smoak <[EMAIL PROTECTED]> wrote:
> Is it going to be struts-core.jar, then? It seems confusing to have a
> directory called 'core' build an artifact called 'struts-action'.
{sees Don svn mv core/* ../ in r151397}
No, that's not what I meant. I was only commenting on the name
Wendy Smoak wrote:
Is it going to be struts-core.jar, then? It seems confusing to have a
directory called 'core' build an artifact called 'struts-action'.
I suppose the directory could be called 'action', but it seems kinda silly to have 'action/trunk/action'. 'core' seems
to be what other p
On 3/31/06, Don Brown <[EMAIL PROTECTED]> wrote:
> Ok, you asked for it... :) I put my first cut at
> https://svn.apache.org/repos/test/action1 I moved the subprojects under
> action1, action as core, and adjusted the builds so that they all shared the
> same version.
Oh, sure, do it now whi
On 3/31/06, Ted Husted <[EMAIL PROTECTED]> wrote:
> If Hubert did have time to drop the plug-in now, that would be a
> reasonable first step. Then, we can integrate into a 1.4 DTD, if
> that's what we want to do. We did the same sort of thing with opt-in
> Cancel Handling. We "patched" 1.2 and then
On 3/31/06, Ted Husted <[EMAIL PROTECTED]> wrote:
> If Hubert did have time to drop the plug-in now, that would be a
> reasonable first step. Then, we can integrate into a 1.4 DTD, if
> that's what we want to do. We did the same sort of thing with opt-in
> Cancel Handling. We "patched" 1.2 and then
On 3/31/06, Michael Jouravlev <[EMAIL PROTECTED]> wrote:
> I think integrating FormDef into struts-config is a good thing, and
> this can be legitimately done right now, when version changes from 1.2
> to 1.3. It will not be possible later unless 1.4 will be released. But
> if Hubert prefers having
Look at it this way - all this work has to be done whether we release a stable 1.3 now or after formdef. We might as
well get it done now, then we always could release again right afterwards. If this Maven build is as magical as Wendy
and James say it is ;), we shouldn't have a problem.
Don
Wendy Smoak wrote:
There were no objections to your proposed reorganization, so IMO the
thing to do is try it and see what happens. Preferably in the test
repo. :) We don't need history for this, so svn export/svn import
should do it. (https://svn.apache.org/repos/test) If not, maybe Sean
can
Don, despite that I myself feel that new release is in order, I think
that waiting a few more weeks and having a bigger bang so to speak
would be more beneficial. It is like releasing WinME instead of
Win95OSR2 while the work on Win2K is still in progress.
I think integrating FormDef into struts-c
On 3/31/06, Ted Husted <[EMAIL PROTECTED]> wrote:
> On 3/31/06, Michael Jouravlev <[EMAIL PROTECTED]> wrote:
> > There is another related product, StrutsLive! .
>
> Do you mean this StrutsLive!, Michael?
>
> * https://strutslive.dev.java.net/
Yes. I played with it, seems quite comprehensive. For a
On 3/31/06, Don Brown <[EMAIL PROTECTED]> wrote:
> It isn't the jars I'm talking about, it is the multiple release
> processes: the plan, the checklists, the voting, the testing. I'd much
> rather do it once on a large project than 6 times on small ones.
>
> As for the risk of being held up, I th
On 3/31/06, Michael Jouravlev <[EMAIL PROTECTED]> wrote:
> There is another related product, StrutsLive! .
Do you mean this StrutsLive!, Michael?
* https://strutslive.dev.java.net/
-T.
-
To unsubscribe, e-mail: [EMAIL PROTECTED
Agreed, I'd like to get a 1.3 release out first in the next week or so. Will the FormDef code be integrated into the
code base, or would it be a new module with its own build?
Don
Hubert Rabago wrote:
While I would be very much willing to bring FormDef in, I wouldn't
want to hold up a 1.3 GA
While I would be very much willing to bring FormDef in, I wouldn't
want to hold up a 1.3 GA release because of it. This would take at
least a few more weeks. For one thing, FormDef doesn't have methods
that work with ActionContext yet, and Commands as Actions is one of
the biggest new features of
On 3/31/06, Ted Husted <[EMAIL PROTECTED]> wrote:
> I don't even know that we need a 1.3.1 build yet.
1.3.1 has EventActionDispatcher while 1.3.0 doesn't. I don't know
about other features. This may cause misunderstanding during upgrade,
since 1.2.9 contains EventActionDispatcher as well so 1.3.0
On 3/31/06, Don Brown <[EMAIL PROTECTED]> wrote:
> I guess what I'm saying is I'm willing to be the release manager for
> 1.3.1, but I'm looking to do as little work as possible :)
I'm just saying the infrastructure we have now for Action 1.3 doesn't
prevent anyone from doing a single plan that co
Ted Husted wrote:
On 3/31/06, Don Brown <[EMAIL PROTECTED]> wrote:
Bottom line, the fewer subprojects and even "modules", the quicker a GA
release will happen and the easier the project will be to manage.
Having done the release both ways, I don't see that multiple JARs is a
problem. The work
On 3/31/06, James Mitchell <[EMAIL PROTECTED]> wrote:
> I also want to ask how everyone feels about our current build
> process. Are you using Ant, Maven 1 or Maven 2?
I used Maven 1 for the 1.3.0 builds, and it worked just fine.
> At this point we should probably take a vote and finalize a pla
On Mar 31, 2006, at 7:33 AM, James Mitchell wrote:
I also want to ask how everyone feels about our current build
process. Are you using Ant, Maven 1 or Maven 2?
Mostly Maven 1. I'm trying to move towards Maven 2, but for some
reason I can't get the tests to run for M2 (with Standalone Ti
On Mar 31, 2006, at 1:10 AM, Don Brown wrote:
Ok, as I understand the current system, we'd need a GA release of
all the subprojects, including Action 1, in order to declare a GA
1.3 release.
How much work does those involved think this will be? If a bit,
I'm thinking it might be easier i
On 3/31/06, Don Brown <[EMAIL PROTECTED]> wrote:
> Bottom line, the fewer subprojects and even "modules", the quicker a GA
> release will happen and the easier the project will be to manage.
Having done the release both ways, I don't see that multiple JARs is a
problem. The work of creating a rele
On 3/31/06, Don Brown <[EMAIL PROTECTED]> wrote:
> We are _way_ overdue on this release and I'm now hearing some literally
> don't think it will _ever_ be finished, and worse, that we don't care.
Historically, we run 18 to 24 months between stable releases. Even the
initial release, when we had a
I'm not aware of any additional work that needs to be done.
AFAIK, it's just a matter of calling for a quality vote.
In my own case, my work schedule isn't leaving me much discretionary
time, and so I must leave it to someone else to call for the quality
vote and complete the release.
If someone
Ok, as I understand the current system, we'd need a GA release of all
the subprojects, including Action 1, in order to declare a GA 1.3 release.
How much work does those involved think this will be? If a bit, I'm
thinking it might be easier in the long run to go ahead, consolidate the
subproj
49 matches
Mail list logo
