You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Martijn Dashorst <ma...@gmail.com> on 2007/03/13 13:59:06 UTC
Release 1.3 - status
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.
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.
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.
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.
TODO:
- decide the final assembly formats
- fix jdk-1.5 sites, and the multi-module site build (links between
projects don't work)
- see if maven release plugin is a good fit (doubt that)
- see why people get errors building our new structure
Martijn
--
Learn Wicket at ApacheCon Europe: http://apachecon.com
Join the wicket community at irc.freenode.net: ##wicket
Wicket 1.2.5 will keep your server alive. Download Wicket now!
http://wicketframework.org
Re: Release 1.3 - status
Posted by Martijn Dashorst <ma...@gmail.com>.
The warnings have been resolved, and the META-INF directory of each
jar file will now include the LICENSE, NOTICE and DISCLAIMER file
(incubator disclaimer).
I suggest that everyone upgrades their maven to 2.0.5 to prevent conflicts.
Martijn
On 3/13/07, Martijn Dashorst <ma...@gmail.com> 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.
>
> 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.
>
> 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.
>
> 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.
>
> TODO:
> - decide the final assembly formats
> - fix jdk-1.5 sites, and the multi-module site build (links between
> projects don't work)
> - see if maven release plugin is a good fit (doubt that)
> - see why people get errors building our new structure
>
> Martijn
>
> --
> Learn Wicket at ApacheCon Europe: http://apachecon.com
> Join the wicket community at irc.freenode.net: ##wicket
> Wicket 1.2.5 will keep your server alive. Download Wicket now!
> http://wicketframework.org
>
--
Learn Wicket at ApacheCon Europe: http://apachecon.com
Join the wicket community at irc.freenode.net: ##wicket
Wicket 1.2.5 will keep your server alive. Download Wicket now!
http://wicketframework.org
Re: Release 1.3 - status
Posted by Gwyn Evans <gw...@gmail.com>.
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 <wi...@almaw.com> 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
Re: Release 1.3 - status
Posted by Al Maw <wi...@almaw.com>.
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