I sort of suspected that that was the case.
For me, I don't use forums (it's a pull vs push thing) and strangely,
the ww traffic doesn't seem to be coming to our dev list anymore (at
least I thought it used to). Something must have happened when I
wasn't looking.
--
James Mitchell
O
James,
for xwork the same lists as for webwork are used...
[EMAIL PROTECTED]
[EMAIL PROTECTED]
hth,
Rainer
> Is there a XWork User or Dev mailing list? I have only found
> [EMAIL PROTECTED]
>
> --
> James Mitchell
>
>
>
>
> On Mar 30, 2006, at 4:20 PM, Ted Husted wrote:
>
>> On 3/30/06, Gabe <[
Is there a XWork User or Dev mailing list? I have only found
[EMAIL PROTECTED]
--
James Mitchell
On Mar 30, 2006, at 4:20 PM, Ted Husted wrote:
On 3/30/06, Gabe <[EMAIL PROTECTED]> wrote:
Don,
I was refering to phase I really, whether the starting point is
Webwork or Webwork + XWork
el stuff I wanted, so I was free to try
new ideas much quicker.
Don
Thanks,
Gabe
- Original Message
From: Don Brown <[EMAIL PROTECTED]>
To: Struts Developers List
Sent: Thursday, March 30, 2006 12:22:01 AM
Subject: Re: [Struts Ti] XWork?
Gabe wrote:
I wanted to answer these two
On 3/30/06, Gabe <[EMAIL PROTECTED]> wrote:
>
> Don,
>
> I was refering to phase I really, whether the starting point is Webwork or
> Webwork + XWork.
I think Don is saying that it would be helpful to see a concrete
proposal from the XWork developers that outlines what they would like
to do. Once
the XWork dependancy from the Ti prototype or
that you included WW in addition to XWork?
Thanks,
Gabe
- Original Message
From: Don Brown <[EMAIL PROTECTED]>
To: Struts Developers List
Sent: Thursday, March 30, 2006 12:22:01 AM
Subject: Re: [Struts Ti] XWork?
Gabe wrote:
> I wanted
At 11:07 AM -0800 3/30/06, Don Brown wrote:
Sure, a custom ActionInvocation instance could even invoke a Struts
Action as is. The question is how you handle ActionForms. Do you
implement the Struts request processing chain as Interceptors? Add
an Interceptor that calls a chain? Action 2 alr
Sure, a custom ActionInvocation instance could even invoke a Struts Action as is. The question is how you handle
ActionForms. Do you implement the Struts request processing chain as Interceptors? Add an Interceptor that calls a
chain? Action 2 already has the DefaultWorkflowInterceptor which
Well what I've been toying with is two things the first isn't directly
related but might be of interest.
At the SpringExperience there were some discussions about integrating
SpringWebflow into webwork and I started playing with some code. What I
ended up with was a weird WebFlowAction that could
The code is in sandbox/ti/phase1/jars/legacy I believe, although I recently started moving it to sandbox/action2/legacy,
but got stuck trying to make a Maven 2 build work. The code is still in an exploratory stage, but there is conversion
code to turn Action 2 objects into Action 1 equivalences,
At 8:55 AM -0800 3/30/06, Don Brown wrote:
Are you talking about running Struts 1.x actions inside Action 2?
If so, that is something that has been started in the sandbox, but
not fully developed. I'd like to hear more.
Don:
where is this, exactly? and if you have the time, what's the
stat
On what framework would this solution you are describing run? Are you talking about running Struts 1.x actions inside
Action 2? If so, that is something that has been started in the sandbox, but not fully developed. I'd like to hear more.
Don
Eric Molitor wrote:
This may be a dumb suggestio
This may be a dumb suggestion but why not implement a lightweight action
class that's in StrutsAction and then if a user chooses they can use the
full support of XWork. I'm not sure where you draw the line (you'd probably
want validation) but I cant see why you couldn't implement a few of the
inter
To add to that, Patrick and I were collaborating on "phase 2" type
features before we even thought of merging projects. After that
brainstorming session, I started talking to Patrick about one of the
ideas that came out of the conversion, like devMode, and Patrick
implemented it in WebWork. H
That's exactly what I had in mind, thanks for the reference. I see the
source of the confusion (phase I vs. II as you say). At least now I can
point people that ask me to the right place :)
Frank
Ted Husted wrote:
I think we're all still working off the original proposal.
* http://wiki.apa
I think we're all still working off the original proposal.
* http://wiki.apache.org/struts/StrutsTi
Don is simply referring to "phase 2", while most of us are still
focused on "phase 1".
-Ted.
On 3/30/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
> Don, I think this is totally at odds with a
On 3/30/06, Don Brown <[EMAIL PROTECTED]> wrote:
> Ted threw out the idea to WebWork for their team to merge forces and work on
> Ti
Well, Patrick mentioned in the "Web alignment group" that WebWork
would like to join forces with another project, and we went from
there. We discussed with Jason an
;ll let other XWork/WebWork folks weigh in on the XWork issue, I
want to quickly make the point that this equation is incorrect. The
original vision of Struts Action 2.0 started as Struts Ti. It was a
collaboration of Beehive, WebWork, and Struts folks looking to write a
simplified, Action 2 f
folks weigh in on the XWork issue, I
want to quickly make the point that this equation is incorrect. The
original vision of Struts Action 2.0 started as Struts Ti. It was a
collaboration of Beehive, WebWork, and Struts folks looking to write a
simplified, Action 2 framework that leverage
On 3/25/06, Ted Husted <[EMAIL PROTECTED]> wrote:
>
> On 3/25/06, Gabe <[EMAIL PROTECTED]> wrote:
> > I'm sure I could come up with more reasons, but this is a good start to
> this discussion.
>
> I don't think anyone would have a problem with this, Gabe. It's just a
> matter of whether we need to
On Wed, Mar 29, 2006 at 06:03:56PM -0800, Gabe wrote:
>
> I wanted to answer these two comments by Ted. Whether to bring XWork is a
> very important decision to make ASAP, because it is about how we define
> Struts Action 2.0.
>
> Struts Action 2.0 = Webwork
>
> - or -
>
> Struts Action 2.0 =
From: Ted Husted <[EMAIL PROTECTED]>
To: Struts Developers List
Sent: Saturday, March 25, 2006 5:22:47 PM
Subject: Re: [Struts Ti] XWork?
On 3/25/06, Gabe <[EMAIL PROTECTED]> wrote:
I'm sure I could come up with more reasons, but this is a good start to this
discussion.
I don&#
- Original Message
From: Ted Husted <[EMAIL PROTECTED]>
To: Struts Developers List
Sent: Saturday, March 25, 2006 5:22:47 PM
Subject: Re: [Struts Ti] XWork?
On 3/25/06, Gabe <[EMAIL PROTECTED]> wrote:
> I'm sure I could come up with more reasons, but this is
On 3/25/06, Gabe <[EMAIL PROTECTED]> wrote:
> I'm sure I could come up with more reasons, but this is a good start to this
> discussion.
I don't think anyone would have a problem with this, Gabe. It's just a
matter of whether we need to bring XWork and WebWork through
simultaneously, or whether w
ether XWork should be moved over with Webwork to Apache and be
merged as part of Struts Ti. I am in favor of XWork being merged with Webwork
and it all being part of Struts Ti, where perhaps there are two jar files and
two package roots, say strutsti.web and strutsti.core, for example.
My reason
On 12/22/05, Ted Husted <[EMAIL PROTECTED]> wrote:
>
> > * Pass WebWork "2.3-Dev" through the incubator and into the Struts
> repository
>
> Actually, all we have do is make a "snapshot available for review",
> which I expect can be a tarball at Open Symphony.
It would probably be a good idea to
> * Pass WebWork "2.3-Dev" through the incubator and into the Struts repository
Actually, all we have do is make a "snapshot available for review",
which I expect can be a tarball at Open Symphony. So, if the codebase
is kosher, we can file the checklist, and bring the codebase directly
into the S
On 12/21/05, Michael Jouravlev <[EMAIL PROTECTED]> wrote:
> I thought that you guys wanted simply to rename WebWork 2.x to Struts
> 2.0 (along with package renaming), and to add stuff from Ti later in
> the mix. I guess I got it all wrong ;-)
Well, nothing is ever simple :)
There are some LGPL de
Cool. Yeah, I'm not suggesting we don't have a sandbox or anything, I
just want us to get the phrase "Struts Ti" out of the mouths of people
outside of the development community. Sounds like we're all in
agreement.
On 12/21/05, Craig McClanahan <[EMAIL PROTECTED]>
I thought that you guys wanted simply to rename WebWork 2.x to Struts
2.0 (along with package renaming), and to add stuff from Ti later in
the mix. I guess I got it all wrong ;-)
Michael.
-
To unsubscribe, e-mail: [EMAIL PROTECTE
truts framework (Struts Shale and Struts Action, right?),
> I propose that from this day forth we shun the name "Ti".
>
> Instead, we agree to make what was Struts Ti phase 1 effectively
> Struts Action 2.0. This is no different from what Don is suggesting.
> On top of
ork in it, including some of Don's rapid development stuff and
Rich's Beehive integration, and I think we'll most likely want to pull
pieces of that into Action 2.0 as we go along.
Instead, we agree to make what was Struts Ti phase 1 effectively
> Struts Action 2.0. This is no differ
th we shun the name "Ti".
Instead, we agree to make what was Struts Ti phase 1 effectively
Struts Action 2.0. This is no different from what Don is suggesting.
On top of that I recommend we agree that Struts Ti phase 2 (flow,
annotation, Rails-style development, etc) be henceforth known as
St
Thank you everyone for your quick feedback. Based on the various
comments and discussions, I'd like to revise my proposal:
1. Rename Struts Ti phase 1 to Struts Action 2.0
- Will contain WebWork, Struts migration tools, commons-chain
integration, and other small improvements
2. Leave
At 12:10 PM -0800 12/21/05, Don Brown wrote:
The package name follows the Shale and really Jakarta convention
where the TLP (Struts and Jakarta respectively) isn't included in
the package name. As for there being "one true Struts 2.0", I
believe that idea has gone by the wayside. It might be
in agreement is Struts has two separate but
> >equal frameworks - Action and Shale. To avoid further confusion, I
> >propose we rename Struts Ti to Struts Action 2.0 Proposal, while
> >keeping the Ti as the code name. I think we should be clear that Ti
> >is not
ApacheCon this year, there is a lot of
confusion as to what Struts is and where it is going. The story that
I think we are all in agreement is Struts has two separate but equal
frameworks - Action and Shale. To avoid further confusion, I propose
we rename Struts Ti to Struts Action 2.0 Proposal, w
further confusion, I
propose we rename Struts Ti to Struts Action 2.0 Proposal, while
keeping the Ti as the code name. I think we should be clear that Ti
is not some "third" framework, but a candidate for Action 2.0.
This proposal involves:
- Renaming the package from org.ap
ks - Action and Shale. To avoid further confusion, I propose we
> rename Struts Ti to Struts Action 2.0 Proposal, while keeping the Ti as
> the code name. I think we should be clear that Ti is not some "third"
> framework, but a candidate for Action 2.0.
>
> This pr
truts 2.0? And if at
some point it gets dropped for something else, then simply call THAT
something else Struts 2.0.
The WebWork merger, Struts Ti as I understand it, is the future of Action
at this point, right? It's no longer a proposal, is it?
--
Frank W. Zammetti
Founder and Chief
As we discovered further at ApacheCon this year, there is a lot of
confusion as to what Struts is and where it is going. The story that I
think we are all in agreement is Struts has two separate but equal
frameworks - Action and Shale. To avoid further confusion, I propose we
rename Struts
Yes, that is what I hope to achieve shortly.
--
James Mitchell
Software Engineer / Open Source Evangelist
Consulting / Mentoring / Freelance
EdgeTech, Inc.
http://www.edgetechservices.net/
678.910.8017
AIM: jmitchtx
Yahoo: jmitchtx
MSN: [EMAIL PROTECTED]
Skype: callto://jmitchtx
On Sep 6
This means that if you're running 1.4 you can still do a build from the
root? Nice! :)
James Mitchell wrote:
Sounds good to me.
I have a plan for how I'll instrument the build to be 1.4/1.5 aware
and behave accordingly. I just haven't put it down in bits yet ;) I
hope to get to that s
Sounds good to me.
I have a plan for how I'll instrument the build to be 1.4/1.5 aware
and behave accordingly. I just haven't put it down in bits yet ;) I
hope to get to that soon though since it seems to be holding up some
of the other tasks I'm on.
Thanks
--
James Mitchell
Software
Sorry for the delay on this thread... just catching up now. Currently
the minimum in the non-Java5 code is 1.4, although we never discussed
it. I think supporting 1.3 would be really hard, but it's something we
should establish.
Currently, the 'samples' .war is Java5 (annotation)-based, but
I'm documenting the build process and I thought I'd take a stab at
figuring out how to have our build conditionally ignore anything that
requires 1.5 if they are using 1.4 or less.
What is the minimum? I've just been assuming 1.4.
Everything (.WARs) in Ti require 1.5. Is that supposed to b
That's what I'd like to make sure we understand and document. I'll
have some time later today, so I'll put together a proposal for said
'build documentation', which will likely be the beginnings of the
Maven docs. Probably ought to keep on the wiki for now though.
--
James Mitchell
Soft
Sounds good from my point of view. :)
As to a structure for the distribution, would it simply be something like:
docs
lib
samples
java5
java1.4
tools
README, etc.
?
Rich
James Mitchell wrote:
My plan would be to publish the nightlies here:
http://svn.apache.org/
My plan would be to publish the nightlies here:
http://svn.apache.org/builds/struts/maven/trunk/nightly/struts-sandbox/
...under a new directory 'ti'
Does that sound ok?
--
James Mitchell
Software Engineer / Open Source Evangelist
Consulting / Mentoring / Freelance
EdgeTech, Inc.
http://www.ed
First, I just want to mention that I've never been involved in a project
where anyone's given so much thought/attention to the build from the
ground up. Thank you -- it's a pleasure! Much nicer than rewriting the
build a few months down the road.
I definitely support getting nightlies out th
I think it would be a good idea for us to discuss and decide on the
layout and build processes. The build process needs to be documented
end to end. We should identify the artifacts created, when and why
it is created. More than the simple comments that I put in
maven.xml. I will volunt
Hi all,
I've added a patch
(http://issues.apache.org/bugzilla/show_bug.cgi?id=36454) for a sample
that demonstrates using JSF as the view layer for a Ti app. It's a
straight port of the Beehive/JSF sample. It doesn't necessarily show
off JSF (or JSF best practices), but it does demonstrate
On 8/31/05, Don Brown <[EMAIL PROTECTED]> wrote:
>
> Very interesting. Do you have any examples/tutorials of this anywhere
> accessible?
That's where the OverDrive/Nexus stuff is going, but, lately, the volunteer
hours have been going into Struts Classic :)
I'm doing some major refactoring
es files which Struts
classes currently have to bootstrap themselves.
Until I see it, I won't argue very hard for using Spring as the
message resolver, but I am finding it handy inside my own
applications. Are there any places in Struts Ti where XWork's
message facilities are being use
hich Struts classes currently
have to bootstrap themselves.
Until I see it, I won't argue very hard for using Spring as the message
resolver, but I am finding it handy inside my own applications. Are
there any places in Struts Ti where XWork's message facilities are being
used?
Joe
--
ly have to bootstrap themselves.
Until I see it, I won't argue very hard for using Spring as the
message resolver, but I am finding it handy inside my own
applications. Are there any places in Struts Ti where XWork's
message facilities are being used?
Joe
--
Joe Germuska
[EMAIL PROTECTED]
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
likely to support a mixture of
struts-specified along with user-specified configuration with a minimum
of headache. (The most documentation I've found about this concept is
at
http://www.springframework.org/docs/api/org/springframework/beans/factory/access/SingletonBeanFactoryLocator.html)
If S
Craig McClanahan wrote:
On 8/31/05, Rich Feit <[EMAIL PROTECTED]> wrote:
Using JSF is actually what convinced me that having the context on
ThreadLocal is a great thing. It really cleans up the APIs. (Nice job
BTW :) ). Our ActionContext will give us something similar... but I do
wonder ab
documentation I've found about
this concept is at
http://www.springframework.org/docs/api/org/springframework/beans/factory/access/SingletonBeanFactoryLocator.html)
If Struts Ti used this with a servlet init parameter whose name was
the root BeanFactory, then a user could add his own
beanR
On 8/31/05, Rich Feit <[EMAIL PROTECTED]> wrote:
>
>
> Using JSF is actually what convinced me that having the context on
> ThreadLocal is a great thing. It really cleans up the APIs. (Nice job
> BTW :) ). Our ActionContext will give us something similar... but I do
> wonder about "internal" attr
Very interesting. Do you have any examples/tutorials of this anywhere
accessible?
Don
Ted Husted wrote:
(Mouse slipped)
On 8/31/05, Ted Husted <[EMAIL PROTECTED]> wrote:
We also do things like create base data-access commands that know how to
run iBATIS
-Ted.
We also do things lik
Hmm...I like the idea of combining the configurations from a maintenance point of view, but on the other hand, the flow
chain can get lost, particularly when the number of commands are in a minority. Separating also has the benefit, in our
case anyways, of having the chain stay generic, but Spri
(Mouse slipped)
On 8/31/05, Ted Husted <[EMAIL PROTECTED]> wrote:
>
>
> We also do things like create base data-access commands that know how to
> run iBATIS
>
> -Ted.
>
>
We also do things like create base data-access commands that know how to run
iBATIS queries. If a data-access command
On 8/31/05, Don Brown <[EMAIL PROTECTED]> wrote:
>
> You might also be interested in the Spring and Chain integration piece I
> wrote for Ti.
We just load the Commands and Chains with Spring, along with everything
else, and don't bother with a separate catalog.
It started out ugly, but if y
Don Brown wrote:
Craig McClanahan wrote:
On 8/31/05, Rich Feit <[EMAIL PROTECTED]> wrote:
I actually agree that a single bean is better than a lot of separate
values under various keys. In Beehive we put most of our request-scoped
values onto a request wrapper -- this turned out to have be
Passing in a context CoR style lets it be used in other contexts, not
planed for originaly, and lets you make chains not designed for.
.V
Don Brown wrote:
Still, I'm not convinced everything
can/should fall under one Context. For example, XWork has a
ValidationContext which I think we shoul
Craig McClanahan wrote:
On 8/31/05, Rich Feit <[EMAIL PROTECTED]> wrote:
I actually agree that a single bean is better than a lot of separate
values under various keys. In Beehive we put most of our request-scoped
values onto a request wrapper -- this turned out to have better
performance
Ted Husted wrote:
I'd suggest showing how to hook up to iBATIS or HIbernate in an example
application, and then deciding if TI needs to create yet-another DAO
framework.
Many iBATIS user s have stopped using the iBATIS DAO framework, since they
find using a dependency-injection framework, l
Craig McClanahan wrote:
On 8/31/05, Rich Feit <[EMAIL PROTECTED]> wrote:
I actually agree that a single bean is better than a lot of separate
values under various keys. In Beehive we put most of our request-scoped
values onto a request wrapper -- this turned out to have better
performance than
On 8/31/05, Rich Feit <[EMAIL PROTECTED]> wrote:
>
> I actually agree that a single bean is better than a lot of separate
> values under various keys. In Beehive we put most of our request-scoped
> values onto a request wrapper -- this turned out to have better
> performance than doing the attribu
I actually agree that a single bean is better than a lot of separate
values under various keys. In Beehive we put most of our request-scoped
values onto a request wrapper -- this turned out to have better
performance than doing the attribute lookup all over the place. But
it's a similar idea.
At 9:40 AM -0400 8/31/05, Ted Husted wrote:
On 8/31/05, Joe Germuska <[EMAIL PROTECTED]> wrote:
My design preference for things like this (as is playing out in
Struts 1.3) is to define a single scoped bean which can contain any
references like this, so as to sharply minimize the need for
co
On 8/31/05, Joe Germuska <[EMAIL PROTECTED]> wrote:
>
> My design preference for things like this (as is playing out in
> Struts 1.3) is to define a single scoped bean which can contain any
> references like this, so as to sharply minimize the need for
> constants like this. If you do that, then y
ping framework, Derby or HSQL, and perhaps
> Middlegen. However, those would only be included in this kit, and not part
> of Struts Ti core, as we want to support
> multiple business and DAO strategies and frameworks.
>
> Don
>
I'd suggest showing how to hook up to iBAT
My design preference for things like this (as is playing out in
Struts 1.3) is to define a single scoped bean which can contain any
references like this, so as to sharply minimize the need for
constants like this. If you do that, then you're down to a single
constant to use to retrieve that be
Ok, I finished bringing over the wiki pages we used when first
conceiving Struts Ti. Note, they are a reflection of past discussions
and not necessarily the current direction or implementation. I think
this wiki will provide a good starting point for writing down our
current thoughts and
It's transitional -- not necessarily for back-compat. I should have
commented it as such. In Beehive, we were using these four constants
that Struts defined for storing errors, exceptions, locale, etc. I
think it's something we need to work out -- do we want to keep storing
these things in a
So, while working on the shale build, I'm multitasking over to Ti and
looking through some of the code there.
The first thing that strikes me as odd is o.a.t.Globals.
I mean, I thought one of the goals was to completely abstract any
underlying api (servlet/portlet). Am I misunderstanding th
At this point I think Don's original proposal
(http://www.mail-archive.com/dev@struts.apache.org/msg10521.html ) is
still the best. Anyone have any other resources to add?
Rich
James Mitchell wrote:
Can you give us some suggested reading tips (websites, articles,
blogs) that will help the
Don Brown wrote:
James Mitchell wrote:
Sounds good.
The layout was hard to work with (example/WEB-INF/src/) so instead
of fighting with Maven, I just added that to the excludes property
(for now). I can work around the layout if that's a deal breaker,
but rather than add the addition
No problem. I just need to be spoon fed right now since I don't grep
ti yet.
Thanks for putting up with all the newb questions.
--
James Mitchell
Software Engineer / Open Source Evangelist
Consulting / Mentoring / Freelance
EdgeTech, Inc.
http://www.edgetechservices.net/
678.910.8017
AIM: j
On 8/30/05, James Mitchell <[EMAIL PROTECTED]> wrote:
>
> Sounds good.
>
> The layout was hard to work with (example/WEB-INF/src/) so instead of
> fighting with Maven, I just added that to the excludes property (for
> now). I can work around the layout if that's a deal breaker, but
> rather than
James Mitchell wrote:
Sounds good.
The layout was hard to work with (example/WEB-INF/src/) so instead of
fighting with Maven, I just added that to the excludes property (for
now). I can work around the layout if that's a deal breaker, but
rather than add the additional effort, it's just b
Re: [builds] Re: Struts Ti
>
>
> That was actually on the end of one of the last emails I sent.
>
> I fully intend to get make a nightly available before the end
> of today.
>
> --
> James Mitchell
> Software Engineer / Open Source Evangelist
> Consulting
[mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 30, 2005 5:02 AM
To: Struts Developers List
Subject: Re: Struts Ti
Currently, you can cd into core and run 'maven jar' using Java 1.4.
Building the entire project (including the 'java5' module)
requires Java
5. Does that sound
Can you give us some suggested reading tips (websites, articles,
blogs) that will help the Ti newbie fill in the gaps on what Ti is
all about? (beehive/webwork/xwork/???)
--
James Mitchell
Software Engineer / Open Source Evangelist
Consulting / Mentoring / Freelance
EdgeTech, Inc.
http://www
Will you guys add Ti to nightly builds?
just looked at svn.a.o and saw not archive there.
Thanks,
Matthias
> -Original Message-
> From: Rich Feit [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, August 30, 2005 5:02 AM
> To: Struts Developers List
> Subject: Re: Struts Ti
&g
Sounds good.
The layout was hard to work with (example/WEB-INF/src/) so instead of
fighting with Maven, I just added that to the excludes property (for
now). I can work around the layout if that's a deal breaker, but
rather than add the additional effort, it's just better use of our
time
Actually, you were right the first time. I've been working on one, but
it hasn't been ready for public use, however, with the Beehive patch,
I'll probably have to redo it anyways :) This should probably be put
along side Rich's page flow examples.
Don
James Mitchell wrote:
s/mailreader/bl
s/mailreader/blank
--
James Mitchell
Software Engineer / Open Source Evangelist
Consulting / Mentoring / Freelance
EdgeTech, Inc.
http://www.edgetechservices.net/
678.910.8017
AIM: jmitchtx
Yahoo: jmitchtx
MSN: [EMAIL PROTECTED]
Skype: callto://jmitchtx
On Aug 30, 2005, at 2:10 AM, James
Another quick question.
What is "example" application supposed to do? Is this supposed to be
the beginnings of a mailreader?
--
James Mitchell
Software Engineer / Open Source Evangelist
Consulting / Mentoring / Freelance
EdgeTech, Inc.
http://www.edgetechservices.net/
678.910.8017
AIM: jmi
Works for me too.
--
Martin Cooper
On 8/29/05, Rich Feit <[EMAIL PROTECTED]> wrote:
>
> Sounds great to me, actually. It's cleaner in general.
>
> Rich
>
> Don Brown wrote:
>
> > Doesn't matter to me as long as it works :)
> >
> > Don
> >
> > James Mitchell wrote:
> >
> >> Ok, I've hit a bit
Sounds great to me, actually. It's cleaner in general.
Rich
Don Brown wrote:
Doesn't matter to me as long as it works :)
Don
James Mitchell wrote:
Ok, I've hit a bit of a snag...
In Maven-utopia, the project layout would support multiple JAR and
WAR artifacts by nesting then 1 level de
Doesn't matter to me as long as it works :)
Don
James Mitchell wrote:
Ok, I've hit a bit of a snag...
In Maven-utopia, the project layout would support multiple JAR and
WAR artifacts by nesting then 1 level deeper than we currently have
them.
So, we need:
struts/sandbox/ti
project.xm
Ok, I've hit a bit of a snag...
In Maven-utopia, the project layout would support multiple JAR and
WAR artifacts by nesting then 1 level deeper than we currently have
them.
So, we need:
struts/sandbox/ti
project.xml
maven.xml
project.properties
jars/
core/
java5/
wars
Currently, you can cd into core and run 'maven jar' using Java 1.4.
Building the entire project (including the 'java5' module) requires Java
5. Does that sound reasonable? The two modules do currently build to
separate jars.
Currently the 'samples' module (webapp) is written against the
an
Craig McClanahan wrote:
On 8/29/05, Don Brown <[EMAIL PROTECTED]> wrote:
* Why "Ti"? What does that mean?
Titanium. I enjoy ultralight backpacking so titanium is near and dear
to my heart as an incredibly strong, very lightweight material used in
core gear that replaced much heavier counte
On 8/29/05, Don Brown <[EMAIL PROTECTED]> wrote:
> * Why "Ti"? What does that mean?
>
> Titanium. I enjoy ultralight backpacking so titanium is near and dear
> to my heart as an incredibly strong, very lightweight material used in
> core gear that replaced much heavier counterparts - the "struts"
That looks about right. It should be possible to run Ti, using xjavadoc
tags instead of Java 5 annotations, on Java 1.4. I'd imagine the java5
directory would build into a separate jar or perhaps only be added to a
core jar when not labeled as the Java 1.4 version:
Java 1.4 version - ti-cor
Ok, so other than "requires 1.5 to build, and 1.4 to run" via maven
prop "maven.compile.source=1.4", what else do I need to do?
I guess what I'm trying to ask is, what do we want to support?
- 1.5 required to:
- build from svn checkout
- build from nightly src distribution
- build fro
1 - 100 of 131 matches
Mail list logo
