Steve Appling wrote:
Adam Murdoch wrote:
Steve Appling wrote:
Please don't rush to release 0.8 if there are items that still
aren't ready. I have a few concerns:
I think we need a couple more days as well.
* The javadoc for gradle-core still fails.
I would put this low on the priority list. I don't think we care
about this for the release, relative to the other items on this list.
I think it would be bad to release all of this new functionality
without anyone being able to use the documentation for it. The
javadoc is (should be) a very useful reference.
Absolutely. We generate the javadoc for the release using :javadoc,
which generates the combined docs for all projects, rather than using
:gradle-core:javadoc.
Having said that, it's bad form to have broken tasks in the build. I'll
try to fix it before the release. I'd rather :gradle-code:javadoc didn't
exist, as we don't care about its output. I might 'fix' it by disabling it.
* The userguide needs to build under windows.
The html userguide does. We don't release from windows, so I would
put this low on the list.
I am mainly concerned about this because I think it may be an
indicator of some underlying memory management problems. I know that I
have had to wrestle with combinations of Xmx and permgen sizes almost
each time I make a change. It does not seem that Gradle should be
such a large and complicated project to require the memory we do. I
worry about the scalability if we can't build ourself well.
Quite possibly. I will try to have a look in the next couple of days.
* We still need some userguide content for Source Sets.
Absolutely. It's on its way.
* Source Set language checking - I still don't know how to check to
see what types of source (java, groovy, scala) are in a source set.
This is keeping me from making a simple change.
As mentioned in another email, you shouldn't need to. And if you do,
you would use the same mechanism you've always used, ie has the
java/groovy/scala plugin been applied to the project?
I will just check the plugin (for some reason I didn't get that other
email until this morning), but it seems somehow wrong. Testing the
use of the plugin seems disconnected from using the source set
properties. I think I should be able to check for the validity of the
source set members as well at some point.
Absolutely. It's a matter of priorities at this stage. I think its more
important to end up with a solution where most people don't need to care
about what's been applied. And for those that do care, I think we have
an acceptable, if not ideal, solution by checking which plugins have
been applied to the project.
* I think we need time to digest (and exercise) source sets before
the release. This is a big change and I don't feel like I
understand it well enough to use it before the documentation is
done. While I have a lot of confidence in the quality of Adam's
work, I think a change of this scope could use some feedback based
on real use. After it is documented and I understand it, I'll be
glad to try to apply it on our system and give some of that feedback.
I think the whole point of doing the release is to get feedback. I
wouldn't hold off the release for this, but if you have feedback
beforehand, then we can incorporate it before the release.
I don't feel that I have enough understanding of source sets to
provide the feedback now - and I don't know that I will get that until
the documentation is done.
I guess that's some feedback right there.
Perhaps the Gradle community has a different view of releases than I
am used to. I am used to having significant changes like this
exercised by a group of core users (often through an alpha or preview
release). A preview release should have enough documentation so that
people can exercise the new features, but the implementation itself is
more open to change. A more "real" public release will cause larger
groups of people to update their builds to accommodate incompatible
changes and will make other changes due to feedback more painful.
I'm not sure that it is such a high impact change. If you're following
the convention, you won't need to do anything. Given the limited options
for configuring the project layout in 0.7, there's a simple
transformation for converting this configuration to 0.8.
So far, we've been relying on people using trunk to give feedback.
Source sets have been in trunk for over a month now, and we've been
using them for Gradle's build for about 3 weeks. That feels like enough
time to shake it out.
I guess at some point we will start doing preview releases. I'm not sure
how we figure out when it's worth the effort to do so. Certainly by the
time we get to 1.0.
* Small GUI changes. We have a handful of small changes to help
clean up the GUI that I hope to apply tomorrow.
I guess you have a few days to apply this.
* Listener Management - John has been working on making a listener
manager that we need to get our Team City plugin working. We would
love to have this in 0.8. I think this will be ready in a day or so
as well.
I will apply this soon.
I helped John find some issues with this and I can apply it if you
have no objections.
No objections. John's changes look good.
Adam
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
