Martijn Dashorst wrote:
I've been working on the release and have come to a last point: how to
package stuff.
The default src assembly is IMO moot: it packages each project without
context. It seems to me that a zip containing the sources for all
projects is better, as it makes it one package as a whole
The default bin assembly doesn't include jar dependencies so our users
have to download all the dependencies themselves.
You can do this with the <dependencySets> stuff in the assembly
descriptor though.
<dependencySets>
<dependencySet>
<outputDirectory>/lib</outputDirectory>
<unpack>false</unpack>
</dependencySet>
</dependencySets>
I don't know how this should behave, to be honest. Most libraries
package their dependencies if the licensing allows that. Wicket doesn't
have that many dependencies, so I don't see that this is a bad option.
The only issue with that is that if we provide a single TGZ for the
whole release then it's not obvious which dependencies belong to which
project. The examples project, in particular, has a bunch of extra
dependencies. I guess we can document this somewhere, suggest people use
Maven, or come up with some way to package things as lib/wicket/,
lib/wicket-extensions/, etc.
The sites generate for the most part in the jdk-1.4 section. They
still require a site.xml (and I included for most a index.apt which
has an incubation disclaimer). The site.xml is needed otherwise the
maven site plugin doesn't use our skin.
Yeah. Are the site.xml files the same for every project? If so, we might
be able to set it up to use the same one for all the projects, using
something like <configuration><templateFile>${user.dir}/src/site.xml
(where user.dir is the system property for the current working
directory). This would break running the site plug-in from the
subdirectories, but people won't be doing that, will they?
I've reinstated the profiles, but with a twist: now if someone runs
maven using a JDK-1.4 it will only build the JDK-1.4 modules.
Otherwise all projects are built (including the JDK-1.4). You'd get
errors if you try to build the JDK-1.5 modules using a 1.4 java
version, but I'd rather avoid those as well.
Makes sense.
In the root pom we need to define where the snapshots and distribution
repository live. I set them to my p.a.o. (people.apache.org) account,
but I don't think that the root pom should have that information. I'd
rather have the directory/deployment url be in my local settings.xml
file. Then everyone can be the release manager.
Yeah, we should use properties for these, I guess. Unless actually
having these hardcoded will be useful, as you'll be able to tell where a
particular release was deployed to in a way you wouldn't with random
properties.
TODO:
- decide the final assembly formats
Presumably both zip and tgz. I wonder if we should split it into two
assemblies - one for JDK 1.4 and one for JDK 1.5? I think I vote for
some kind of grouping rather than providing 10 zips to download.
- fix jdk-1.5 sites, and the multi-module site build (links between
projects don't work)
Hmmm. You should be able to link to things in the site.xml using:
<menu ref="parent"/>
And:
<menu ref="modules"/>
Doesn't this work?
- see if maven release plugin is a good fit (doubt that)
Yeah, me too. We want to tag both jdk-1.4 and jdk-1.5 at the same time,
under a single tag. This doesn't fit with the mvn4, mvn5 build process.
Al
