Hi Jeremy - just to add a couple more bits of information inline
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?
Assembly plugin would be the ideal way. Does setting
runOnlyAtExecutionRoot to false work? It seems the default for this is
false anyway, but maybe something in a parent / grandparent pom etc is
setting it to true.
This: <runOnlyAtExecutionRoot>true</runOnlyAtExecutionRoot> is set in
the Apacche7pom. Use of a profile (in this case the Apache7pom) will
override any local settings, so if we have project poms that explictly
set <runOnlyAtExecutionRoot>false</runOnlyAtExecutionRoot> they are
simply ignored.
Thus - the only way that I can find to generate a zip/tar from something
that is not the execution root is to take a copy of the apache-release
profile from the Apache7pom, remove the line
<runOnlyAtExecutionRoot>true</runOnlyAtExecutionRoot>, paste it into a
pom.xml (I tried samples) and rename it to 'aries-release'. I can then
create artifacts using the assembly plugin which are treated as part of
the release using:
mvn install -Paries-release
Just FYI - I tried:
mvn install -Papache-release -DrunOnlyAtExecutionRoot=false
hoping that an explicit command line flag would override the 'true'
setting. It doesn't.
Summary: Right now I can't see a way to release samples that are easy to
run AND use the Apache7pom release profile. I wish there was a way
around this but at the moment I think we are looking at:
(a) Release samples which people can run without having to checkout and
build the whole of Aries and use a modified Apache7 release profile.
(b) Use the Apache7 release profile and make people who want to run our
samples either assemble their own platform, or checkout and build Aries.
I don't like either option much so would like to hear from anyone who
has a better solution.
Zoe
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.
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
