aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From zoe slattery <>
Subject Re: Aries release - the shape of repo org/apache/aries
Date Wed, 24 Mar 2010 14:19:23 GMT
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
>>>> 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.

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

View raw message