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.
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 [EMAIL
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
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
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
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
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
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
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
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
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
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 dev@struts.apache.org
Sent: Thursday, March 30, 2006 12:22:01 AM
Subject: Re: [Struts Ti] XWork?
Gabe wrote:
I wanted to answer these two
Message
From: Ted Husted [EMAIL PROTECTED]
To: Struts Developers List dev@struts.apache.org
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
@struts.apache.org
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't think anyone would have a problem with this, Gabe. It's just a
matter
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 = Webwork
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 bring XWork
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 leveraged
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 leveraged the strengths of each
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 and
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 lot
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.
*
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. He
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 reasons
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 we
* 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
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 bring in the
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
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 Software Architect
Omnytex Technologies
http
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.apache.ti
, 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, while keeping the
Ti
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 some third framework, but a candidate for Action 2.0.
This proposal involves
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
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 Ti
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
Struts Action 2.x
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 different from what Don is suggesting.
On top of that I recommend we agree that Struts Ti
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 that I recommend we agree that Struts Ti phase 2 (flow,
annotation, Rails
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
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] wrote:
On 12/21/05, Patrick
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
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
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
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
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
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
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
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.
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:
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
, we have talked about including
some sort of DAO framework for a starter's kit
or something along those lines. That'd probably include a simple SQL
mapping framework, Derby or HSQL, and perhaps
Middlegen. However, those would only be included in this kit, and not part
of Struts Ti core
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 you're
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
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
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 attribute
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
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,
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
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
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
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 you
(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 object
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
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 like
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 attributes --
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
beanRefFactory.xml file in /WEB-INF
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
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 Struts Ti used
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
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
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 Germuska
[EMAIL
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 in
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:
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
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:
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
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
Currently, you can
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.
[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 reasonable? The two
-Original Message-
From: Rich Feit [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
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
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 add the
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:
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
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
As per http://osteele.com/archives/2004/08/web-mvc
I now think if a frameworks is client side rendering (Ajax, JDNC, ...)
it can't be mixed w/ a server side rednering framework, you can be
strong in one or the other (and then rig it for the other).
--
thx,
.V
Broadband interface (RIA) +
On 8/29/05, netsql [EMAIL PROTECTED] wrote:
As per http://osteele.com/archives/2004/08/web-mvc
I now think if a frameworks is client side rendering (Ajax, JDNC, ...)
it can't be mixed w/ a server side rednering framework, you can be
strong in one or the other (and then rig it for the other).
Well the article kind of says that only domain model/dao is on the server.
And MVC is on the client. And that makes sense. So in your example, if
the client requests the XML, then it's RiA. Your's might not be a good
example.
Ajax is a perfect example. Idea was that Ti would do
2.
One of the goals with Struts Ti is to make it simple to implement
server-side handling for rich applications, whether they use AJAX, AJAJ or
whatever. We're not going to write the client side framework - that's what
folks like the Dojo team do best - but we aim to provide the best means
the first response to that article, labelled
Marc's Voice. He gets much closer to the truth when he says The other
thing to note about Model N is that the server side is very similar to Model
2.
One of the goals with Struts Ti is to make it simple to implement
server-side handling for rich
wrong. ;-) Check out the first response to that article, labelled
Marc's Voice. He gets much closer to the truth when he says The other
thing to note about Model N is that the server side is very similar to Model
2.
One of the goals with Struts Ti is to make it simple to implement
server-side
, and the decoding, dispatching and serialising are all things that a
framework like Struts Ti can provide you with.
--
Martin Cooper
What else should be on the server?
If UI (View) is on the client, C (controller has to be there).
.V
Martin Cooper wrote:
That article does indeed indicate
that a
framework like Struts Ti can provide you with.
--
thx,
.V
Broadband interface (RIA) + mail box safety = Roomity.com
http://roomity.com/demo.jsp
*Your* clubs, no sign up to read, ad supported; try broadband internet.
cell: 917 825 3035 in DFW
email: netsql at roomity.com
for a starter's kit
or something along those lines. That'd probably include a simple SQL mapping 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
Ok, so I'm working on the Maven build scripts, and I have a couple
questions.
* Why Ti? What does that mean?
* Why is there a java5 dir? I see ti interface, but why not just
put it under core?
--
James Mitchell
Software Engineer / Open Source Evangelist
Consulting / Mentoring /
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 from
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 of my
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
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
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
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
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 of a snag...
In
1 - 100 of 117 matches
Mail list logo
