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? > > 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 >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> > >
