Joe Bohn wrote:
zoe slattery wrote:
2) Sample 'assemblies'. At the moment most of the samples have a
'platform assembly' project which copies all the jars required to
run the sample into a target directory and provides some minimal
configuration. I think it might be a good idea to package the
platforms as tar and/or zip files and make them available along
with the sample jars. I think the right way to do this is probably
(I'd like advice on this, I'm definitely not a Maven expert) to
change the platform assembly projects to use the maven assembly
plugin to create zip/tar files. I'll raise a JIRA as a sub task of
173 if you think this is the right thing to do.
Creating the zip/tar is certainly one possible solution. If we
decide to go that route then the first mechanism that comes to my
mind is the maven-assembly-plugin (but I'm no maven expert
either). I'm not opposed to building the zip/tar of the platform
assemblies - but I wonder if it is really necessary.
I am beginning to think it probably isn't possible :-).
I spent some time trying to work out how to generate a platform zip
for the blog sample. Generating the zip using the assembly plugin is
straightforward enough but I ran into problems when the
apache-release process checks the licenses. I think it's checking for
META-INF/LICENCE inside every jar in the zip. Of course it doesn't
find them for equinox platform jars - so it chokes.
A better plan would be to make a standalone-assembly project that
will create a zip that just has a pom.xml (the same as the one in the
the blog-assembly project) and the platform configuration files
(configuration/config.ini). The zip could be extracted into say /tmp,
then 'mvn install' should create the whole platform as long as the
user have maven and java installed. I have this working perfectly. To
create the zip I run:
mvn install -Papache-release
from within the standalone-assembly project, the zip file is created
and installed in .m2/repository. Great.
However - this won't work as part of build of the full tree, the
problem is:
[INFO] [assembly:single {execution: source-release-assembly}]
[INFO] Skipping the assembly in this project because it's not the
Execution Root
so, the zip file will never be built.
Is there another way to do this? Or am I missing something obvious?
If not I think we just have to say that people who want to run the
samples have to check out and build Aries - this seems less than
ideal to me. My standalone-assembly project is not checked in, I can
do so if anyone else wants to look at this.
A few things come to mind here:
1) Back before we had the eba-maven-plugin I had a rather complicated
scheme to create my EBAs. I went through a lot of hoops to create the
appropriate *.eba and but it involved ant and wasn't pushed to the
repo - so I used the build-helper-maven-plugin to push it out the
maven repo. I wonder if this will work for this scenario.
2) Geronimo does something very similar in their build. They generate
a set of geronimo assemblies in zip and tar.gz using a custom plugin -
geronimo-maven-plugin. It might be a bit strange but we could
potentially use that plugin or perhaps copy it, strip all that we
don't care about and keep just what we need.
3) I've been told that Karaf does something similar for their
assemblies - not sure what they use but it might be worth a look.
I had a look at (1) and couldn't find a way that it helped. (2) and (3)
sound interesting - we can't be the only project trying to do something
like this.
I checked in my additional project (under the blog sample) - it does
work if we don't use the apache-release profile but I feel there must be
better ways...
Zoe
