Mailing-List: contact aries-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: aries-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of zoe.slattery@googlemail.com
 designates 209.85.218.226 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=googlemail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject:references
         :in-reply-to:content-type:content-transfer-encoding;
        b=J0o+W4tmuOrdY0GNhYJo991CxvhqvG/gLPD7Nr3Nbs9zXvVxG9PE2ddmpczqqEu0Jw
         h6yy+O3f4BxEzpFEaeTSTKFm50js++Qx0sg8qTJztx/d5f1uqGyKInIGffhC6Gr8j0fi
         qSTxjgHalaav57514oMiYiNw/V1cCUyzeusJY=
Message-ID: <4BAA1F6B.2040502@gmail.com>
Date: Wed, 24 Mar 2010 14:19:23 +0000
From: zoe slattery <zoe.slattery@googlemail.com>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: aries-dev@incubator.apache.org
Subject: Re: Aries release - the shape of repo org/apache/aries
References: <adbf02b11003080556i68fd066bwa3f0cc32dc0ca1cb@mail.gmail.com>
 	<4B951F1C.3050101@gmail.com> <4B9DB155.9030407@gmail.com>
 	<4BA8F223.6030909@gmail.com>
 <adbf02b11003240511i4f3b227duf7f00f26bb80eb03@mail.gmail.com>
In-Reply-To: <adbf02b11003240511i4f3b227duf7f00f26bb80eb03@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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