I was joking na ;-)
IMO I think Ant is legacy and that folks should have a Maven install
next to their Ant anyways. IMO the extra effort to support both is
significant (even for little examples). It is not hard to obtain or
install Maven.
I'd like to see the Ant legacy go away eventually, but for now I will
just leave it alone.
BTW, the examples right now are all creating artifacts w/o versions to
be compatible with the Ant builds. This is confusing to Maven folk...
that expect outputs to be standard. finalName should be avoided in
99% of all modules to keep things consistent.
IMO this is one of the *huge* beefits of Maven, is that out of the box
it makes highly standardized builds from a highly standardized build
tree structure. While it s possible to change that, it will confuse
people and add more maintenance to the build.
The uberflexibledoanythingyouwant style which Ant tends to promote are
the exact opposite. While you can go out of your way to build
standard outputs and use a standard tree, you have to craft a lot of
that by hand, and more often then not folks diverge and end up with
something custom anyways.
These days I think folks are much more used to having Maven-based
systems. So a README.txt saying fetch Maven 2.x and then running mvn
install, should not be that more difficult than one saying fetch Ant
1.x and run build all.
I do not see the value in keeping around a mvn build and an ant
build... should we include a GNU Makefile too for folks who have not
yet adopted Ant or Maven? Configure scripts to detect Java in non-
standard locations or allow i to be configured? My guess is no....
:-\
--jason
On Jul 29, 2009, at 10:07 PM, Baram, Eliezer wrote:
Ant build calling maven assumes that there is a maven installed and
configure on the user machine. Assumption that we can not take for
ant users.
-----Original Message-----
From: Jason Dillon [mailto:[email protected]] On Behalf Of
Jason Dillon
Sent: Tuesday, July 28, 2009 8:49 PM
To: [email protected]
Subject: Re: [discuss] Wink 0.1 updated proposal
On Jul 28, 2009, at 8:24 PM, Baram, Eliezer wrote:
Hi
The thought behind this format of release was to support both Maven
users and ant users. Maven users can use the examples' poms, and for
Ant users we bring build.xmls and all the third parties.
Should just have the ant build call the mvn build :-P
--jason
The wink-server and the wink-client are located under the dist/
components folder while a collaborate jar of all the components is
located under dist.
It might be that the collaborate jar and the fact that the server,
client, etc jars are a little hidden is confusing. I think we can
omit the collaborate jar and move all the component one level up.
Will this make the release more understandable?
--Eli
-----Original Message-----
From: Jason Dillon [mailto:[email protected]] On Behalf Of
Jason Dillon
Sent: Tuesday, July 28, 2009 3:29 PM
To: [email protected]
Subject: Re: [discuss] Wink 0.1 updated proposal
The release outputs for Wink currently boggle my mind, coming from a
Maven standpoint I don't really understand what is intended to be in
the release and what is not. The ant-based release muck confuses me
even more as I don't see things like wink-client or wink-server jars.
Is this really how we want to release wink?
--jason
On Jul 21, 2009, at 12:48 PM, Nicholas L Gallardo wrote:
In the interest of getting a Wink 0.1 out as soon as possible,
here's an
updated proposal for the release.
None of the issues currently marked for 0.1 are show stoppers.
Let's move
those issues to 0.2 and cut a 0.1 release with what we have today
(with one
exception, addressed below).
If my proposal for a 6-week release interval is accepted, then we
can just
wrap all of the remaining issues in the next few weeks and they'd be
available soon in the Wink-0.2 release.
It looks like we have agreement on disabling x-http-method-override
by
default in WINK-76 (https://issues.apache.org/jira/browse/WINK-76).
We
should just flip that switch and close it out for Wink 0.1 so that
we're
consistent across all releases.
Thoughts?
-Nick
Nicholas Gallardo
WebSphere - REST & WebServices Development
[email protected]
Phone: 512-286-6258
Building: 903 / 5G-016
