Without being 100% sure about what you're aiming for, this is what I'm
doing in one of my projects, which might help?
pom.xml:
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<configuration>
<outputDirectory>target/release</outputDirectory>
<descriptors>
<descriptor>assembly.xml</descriptor>
</descriptors>
</configuration>
</plugin>
assembly.xml:
<assembly>
<id>bin</id>
<formats>
<format>zip</format>
</formats>
<fileSets>
<fileSet>
<directory>src\main\artifacts</directory>
<outputDirectory></outputDirectory>
</fileSet>
<fileSet>
<directory>target</directory>
<outputDirectory>lib</outputDirectory>
<includes>
<include>*.jar</include>
</includes>
</fileSet>
</fileSets>
<dependencySets>
<dependencySet>
<outputDirectory>lib</outputDirectory>
<excludes>
<exclude>Siemens:PaymentPlugin</exclude>
<exclude>Siemens:jacorb</exclude>
<exclude>avalon-framework:avalon-framework</exclude>
<exclude>avalon:avalon-logkit</exclude>
</excludes>
</dependencySet>
</dependencySets>
</assembly>
/Gwyn
On 13/03/07, Al Maw <[EMAIL PROTECTED]> wrote:
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
--
Download Wicket 1.2.5 now! - http://wicketframework.org
