Jeremy Hughes wrote:
On 24 March 2010 14:19, zoe slattery <[email protected]> wrote:
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
Is aries-release the same as the apache-release profile except the
runOnlyAtExecutionRoot flag change?
Yes
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.
by this I take it that you mean add a profile called aries-release
(that you used above) to the Aries parent pom rather than modifying
anything in the Apache 7 pom
(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 forcing people to checkout and build Aries in order to
run the samples. Assembling their own platform is possibly even more
distasteful because it is not automated.
The objective here is to create a platform which we know works for
users to quickly get something running. Something else this will
achieve is if they were to do more complex things - like Joe was
suggesting earlier - they always have a fallback that works.
So I'm +1 to (a). I will bring start a discussion on
[email protected] about why this flag is set in the Apache pom and
if there's a known way of overriding it.
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
