On Fri, 21 Jan 2011 08:13:22 -0200, Andreas Andreou <[email protected]>
wrote:
On another note, i'm not sure why tapestry-upload needs a separate
subproject (one can manually exclude commons-fileupload)
Agreed.
In the user messages case, what really caught my eye was the plan for js
integration of it. While that makes total sense, it also ties the core
even more to prototype (while as i said above i'd strive for the opposite
direction). Of course it's always easy to talk and contribute no code
(and i haven't) but
the plan's for this to change.
From this angle, a separate project would be a better idea IMHO.
Another issue about separate subprojects is separate releases (and
versions). As i understand it, most devs are against this -
We could do a vote for this. I really don't know who prefers what in this
case.
but it also feels this
kills one of the benefits of separate projects. Does anyone see any
value in making this work?
As the number of modules grow, having synchronized releases would need a
lot of effort. In addition, it makes it harder for having new modules in
alpha or beta states. For example, I plan to create a Tapestry transaction
management module, but it would be written slowly, as I won't have much
free time this year. Having synchronized release would almost oblige me to
develop it elsewhere and just add it to the Tapestry project when it had
its first stable release.
How about building something like an appstore for components/projects?
What do you mean by appstore? Sell and buy modules? Or just one place
which provides a search for them? As far as I can remember, there was one
for T4.
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, Ars Machina Tecnologia da Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
