On 1/31/07, Dale Newfield <[EMAIL PROTECTED]> wrote:
Matt Raible wrote:
> On 1/31/07, *Dale Newfield* wrote:
> I guess that means you intend to continue supporting the old ant based
> tool even after your fancy-schmancy maven one is finished?
>
> Yes, IMO - there's no reason to discontinue a successful product. ;-)
>
> Do you agree?
I do, but it seems the general nature of software that once the authors
find a shiny new toy, spending time back-porting updates to the old
version becomes a drag, and eventually doesn't happen.
You're right, eventually it won't happen. The reason we've done the
things we did in AppFuse 2.x is based on user (and our own)
experiences. We simply thinks it's a better and easier way to develop
applications with AppFuse. Of course we're going to encourage folks
to use it!
> However, I don't plan on upgrading AppFuse 1.x to Java 5, annotations, etc.
There are definitely gray areas here--some back ports are worth the
effort but others are not? Struts2 is a java5 product. Do you plan on
putting in a struts2 module (in addition to/instead of webwork) in
AppFuse1? Do you use the java4 or java5 version of struts2 in that? If
the latter, then really isn't it just a matter of adding generics into
the templates to get the java5 based tool? You've got to draw the line
somewhere...
Since we only have a few point releases left in 1.9.x, my hope is to
support it with its current features until we hit 1.9.9. That being
said, there's something we can probably do for those
we-can't-use-Maven folks.
1. Create a tutorial that shows how to "Build Your Own AppFuse".
Because everything is modular and well-structured in Subversion, it
should be easy to build your own stack - with source and such. If
there's enough interested, we could create an version of AppFuse that
uses Ant. However, if folks are simply using it because "I tried
Maven and it sucked", I believe we can fix that problem.
2. Running "mvn ant:ant" will create Ant files for you - but I don't
know if they support multi-module projects.
If we do support Ant in the future, we'll still use a dependency
downloading mechanism like Ivy or Maven's Ant Tasks. One thing I
think is possible (but I haven't tried) is distributing AppFuse with a
"lib" directory that Maven looks in for dependencies. I've also
thought about distributing my local repo after building AppFuse.
Users could download, extract and be able to work immediately offline.
It's a bunch of work to keep backporting everything, but it's also lots
of work to backport some things and not others, and can get quite
confusing. If you go this route I bet you will eventually freeze the
versions of certain components in AppFuse1... (for example, to java4?)
I don't know if this is possible, but I'd expect an easier solution
would be to use AppFuse2 to generate a fully expanded codebase, and then
manually add the build scripts and package as an AppFuse1-like tool that
can be run completely with ant. Of course, what the appgen replacement
looks like will definitely impact the feasibility of an approach like this.
That's what I'm thinking. There might be some "please use mvn for
this", but I don't think it would be too bad. Why the resistence to
Maven? I think we're solving most of the issues that folks have with
it. I've certainly enjoyed developing the AppFuse 2.x tutorials a lot
more than 1.x tutorials. ;-)
Matt
-Dale
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
http://raibledesigns.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
