forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Crossley <>
Subject Re: content of release [was: Re: review list of scheduled issues for 0.8 release]
Date Mon, 27 Nov 2006 08:46:06 GMT
Ross Gardler wrote:
> David Crossley wrote:
> >Ross Gardler wrote:
> >>Tim Williams wrote:
> >>>David Crossley wrote:
> >>>>[about Eclipse plugin tool ...]
> >>>>It adds more fat to our release download. I suppose
> >>>>that is why it was added to the roadmap.
> >>>I don't remember if this was ever addressed or not but I recall one of
> >>>the "issues" with forrest that came up with some of our users was the
> >>>"largeness" of the download.  To ease some of that, what are thoughts
> >>>on removing (from the release):
> >>>
> >>>- /etc (100K)
> >>>- /main/java (140K)
> >>>- /site-author  (2.89M)
> >
> >One reason for including this is so that they have local docs.
> >This also enables people to easily tweak and send a patch. Hmmpf.
> >Another reason is probably so that we release the source.
> >Perhaps we should release a separate "docs" package.
> It should be fairly easy to have a compromise position. For example, can 
> we separate the 0.8 docs and release them, leaving the 0.6 and 0.7 docs 
> online only. Similarly we can trim the plugin docs.

Not easily.

> I'm not sure what impact this will have on the size of the download but 
> it must be significant given that all together is 2.89M by Tims 
> evaluation above.
> >>>- /tools/forrestbot (865K)
> >
> >That is a necessary tool. IMO should still be included
> >or it should be released as a separate package.
> +0
> >>>- /tools/eclipse (431K)
> >
> >Not sure how you calculate those numbers. I get 17Mb.
> >IMO this should not be included.
> +0
> >>>- /tools/logos (2M) (don't know what these do, so just a guess here)
> >
> >There is a thread in the dev archives from me about this.
> >IMO should not be included.
> +0
> >We also have stuff in whiteboard to consider.
> Whiteboard should be a separate download.

Why all of it? Is that all targetted at users and ready
for them? The Forrest PMC would need to vote on its release
as a package.

> >>>Some are to get rid of some release weight and others are to avoid
> >>>some confusion (e.g. why are you shipping .java files with a release).
> >
> >What we released in the past is a combined source/binary release.
> >The idea was that they would have everything required to
> >dive in and tweak things.
> >
> >Why are *.java included? AFAIK we release open source
> >software, so we include our source. The pre-built binary
> >forrest.jar is included for convenience to users.
> +1 for including the source (including docs since this is a pretty good 
> example of a major content object)
> >>I would like to see the binary distribution only include Forrest core 
> >>and the necessary tools. No plugins, no whiteboard, no forestbot, no 
> >>eclipse etc.
> I agree to all that *except* we should include source. In this I am 
> assuming that the trimmed sources (see above comments about docs) will 
> bring the size down a fair amount. If the source package is large then 
> I'd not object to separate source/binary releases.
> Having said all this the real problem with our size is the jars we 
> bundle not Forrest itself, these account for 40Mb according to "du -h 
> lib" trimming a further 1 or two meg by dropping source is kind of 
> irrelevant most people will have a brew during download whether it is 
> 42Mb or 44Mb.

Sounds like a task for Ivy. We also have some duplicate jars
at various other places in our SVN.

> >Does the following make sense to have separate combined
> >source/binary packages?
> >
> >* "apache-forrest-core" which includes everything under "main"
> >and "bin" and "tools/ant" and "tools/jetty" and includes a
> >pre-built forrest.jar file.
> >Does it also need the plugin descriptors?
> Plugin descriptors are retrieved from the web if not available locally 
> (needs testing in case my memory is playing tricks on me).

Probably should include them in the release so that their
first experience can be offline.

> >* "apache-forrest-forrestbot" includes its source and a pre-built binary.
> >
> >* "apache-forrest-plugins" includes all plugins (both core and
> >whiteboard) at the time of the "core" release, plus pre-built
> >binaries for those plugins that need it.
> OK
> >>Plugins are auto downloaded on the first run anyway (we should provide a 
> >>separate plugins package though).
> >
> >Actually we have some problems with the way we have been
> >"releasing" plugins. Basically the PMC needs to vote on every
> >package that is intended for use beyond the developers.
> >
> >Not sure in which thread we should discuss this aspect. It was
> >raised once before here:
> >
> >and see the notes at
> There is an issue for this somewhere (I think) - can't search now, 
> working with offline email - sorry.

Would someone please find this.

> >Also the plugins should be on the mirror system, rather than
> >being provided from w.a.o website. Not sure how we can fix that.
> >Probably don't need to do this immediately, but certainly
> >before Forrest gets too many users.
> Assuming descriptors are retrieved from the web then we can make this 
> change later since the descriptor will say where to download from.
> However, we should really be using something like Ivy to manage our 
> plugin downloads and therefore do away with our "proprietary" 
> descriptors (not a 0.8 issue)

That sounds great.

> >>The src release should still include eveything.
> >
> >Are you still wanting that? It would be huge.
> Everything except whiteboard?

What about my proposal above to have combined binary/source
release (like we do now) except only have separate packages
of specific parts, i.e. not everything.


> >By the way, i don't have the time to follow through on this.
> >I can help, but i cannot be the main man.
> Similarly, I'm not likely to find the time to trim 0.8. Of course, I'm 
> willing to give my opinion on things, but given I have no time you won't 
> see any +/-1's from me on these issues. However, I will assist with 
> building, signing, testing release distributions once they are ready.
> Ross

View raw message