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.
Joe
Zoe
I appreciate this might be disruptive, but IMO it's best to have (what
I think is necessary) disruption done sooner rather than later.
Please do comment on this proposal - I've tried to mark the changes
with 'TODO' to help.
Thanks,
Jeremy
--
Joe
