Mailing-List: contact aries-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: aries-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: local policy)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Message-Id:From:To:In-Reply-To:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Date:References:X-Mailer;
  b=uEFnA0VuZj22X4Vvhc2JC9xYHA5mbjYCs+cZ4umdMO63D8ZnmrlHukbKP0qbEpR63ukVIrzV5sHsssPeo2EE03ibXzfh6wNMFbtfit9M4Tmwa3DOGVAvNMSMNdxtDdryfEp6fFv1rnCcXLkzgjmpi093RsJV/3Bz8adSy0Ktz3E=
  ;
Message-Id: <01B2D137-72CB-46E0-BBF3-2C2B929CF5CF@yahoo.com>
From: David Jencks <david_jencks@yahoo.com>
To: aries-dev@incubator.apache.org
In-Reply-To: <345578341002261449i29060ffej7f74ec494992bc7d@mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Subject: Re: eba-maven-plugin
Date: Fri, 26 Feb 2010 16:35:58 -0800
References: <5ABEEE7F-59F5-4A6B-A7D5-EF4652B6AC7D@yahoo.com>
 <9ABF3BA9-1D72-4CC1-B88E-47D32B6FF26E@yahoo.com> <4B87F4E9.4000502@gmail.com>
 <adbf02b11002260910i58279f8eh83011f9f99cb93a6@mail.gmail.com>
 <345578341002261011y575d1efei9dbe507a786b806f@mail.gmail.com>
 <38C8F29F-E08F-4738-8616-000532542DFB@yahoo.com>
 <345578341002261356s66307723h81ed79635496b607@mail.gmail.com>
 <F19E63F4-A041-43E2-B01B-83F88F942A3B@yahoo.com>
 <345578341002261449i29060ffej7f74ec494992bc7d@mail.gmail.com>


On Feb 26, 2010, at 2:49 PM, Graham Charters wrote:

> Hi David,
>
> The zip plugin I've been working from had a flag to exclude the maven
> goo.  I've changed the default so it's not added automatically, but it
> should be simple enough to switch it back on through configuration.
>
> The main reason I think we won't want transitive dependencies by
> default is because we're expecting to provision these through a bundle
> repository.  I do think we'll want the option to include them in the
> eba, I just don't think it should be the default.  I think it does
> make sense for them to be included by default for war and ear.

OK, after thinking about this some more I'm about 75% convinced you  
are right.

I added a flag for this, set to false by default.

I think it does all the things you asked for now.  I guess the next  
step would be generating the application.mf automatically.  The  
samples on the aries website and in svn don't look like the manifests  
I'm used to seeing with fixed line lengths and wrapping in the middle  
of words, are they supposed to?

thanks
david jencks

>
> Regards, Graham.
>
> On 26 February 2010 22:41, David Jencks <david_jencks@yahoo.com>  
> wrote:
>>
>> On Feb 26, 2010, at 1:56 PM, Graham Charters wrote:
>>
>>> Hi David,  I didn't intend to take it over - sorry.  What I have so
>>> far is pretty basic, so there's plenty more to do.  I've been trying
>>> to create one for a little while and had a number of false starts.
>>> Your approach and Jeremy's discovery of the maven-zip-plugin  
>>> helped me
>>> see how it might be done.  Thanks
>>>
>>> I was definitely not intending to create anything new/different  
>>> unless
>>> it needs to be because the .eba format/usage justifies it.  I think
>>> the transitive dependencies fall into this category, as does the
>>> MANIFEST.MF.
>>
>> I looked at the war and ear plugins and it looks to me as if they  
>> are using
>> the same transitive dependency strategy as the rar plugin, i.e.  
>> including
>> non-optional transitive dependencies.  That's certainly what I'd  
>> expect and
>> what I think is most convenient.
>>
>> I didn't realize the MANIFEST.MF was unnecessary.  I think using a
>> ZipArchiver instead of a JarArchiver will be necessary, as the zip  
>> plugin
>> does.  We'll have to configure the zip archiver a bit more....
>>
>> I'll look into if/how to exclude the maven goo.  Personally I like  
>> having it
>> as it tells a lot about where the artifact came from and what it is.
>>
>> thanks
>> david jencks
>>
>>
>>>
>>> Regards, Graham.
>>>
>>> On 26 February 2010 18:34, David Jencks <david_jencks@yahoo.com>  
>>> wrote:
>>>>
>>>> OK, plugin is all yours.  I really hope you don't invent some new
>>>> conventions for dependency handling that are different from what  
>>>> all the
>>>> other maven packaging plugins do. I just copied what the rar  
>>>> plugin does,
>>>> I
>>>> haven't checked whether it is consistent with the war and ear  
>>>> plugins.
>>>>
>>>> good luck
>>>> david jencks
>>>>
>>>> On Feb 26, 2010, at 10:11 AM, Graham Charters wrote:
>>>>
>>>>> Thanks Joe/Jeremy.  Irrespective of this, I think the default
>>>>> behaviour should be to not include transitive dependencies.
>>>>> Unfortunately, I've failed in tidying up what i've done and  
>>>>> getting
>>>>> the plugin tests clean.  They make assumptions about things like
>>>>> source directory and manifest.mf being part of the plugin and in  
>>>>> the
>>>>> zip based version, they're not.  I'll hopefully get this sorted  
>>>>> over
>>>>> the weekend.
>>>>>
>>>>> Regards, Graham.
>>>>>
>>>>> On 26 February 2010 17:10, Jeremy Hughes <hughesj@apache.org>  
>>>>> wrote:
>>>>>>
>>>>>> On 26 February 2010 16:20, Joe Bohn <joebohn@gmail.com> wrote:
>>>>>>>
>>>>>>> It looks like there are changes afoot to this plugin but just  
>>>>>>> thought
>>>>>>> I'd
>>>>>>> confirm that it produces something equivalent to what I was  
>>>>>>> producing
>>>>>>> for
>>>>>>> AriesTrader and the result works equally as well.
>>>>>>>
>>>>>>> I think the transitive dependencies referenced by Graham can  
>>>>>>> be fixed
>>>>>>> if
>>>>>>> the
>>>>>>> blog sample is updated to specify a scope of provided on the
>>>>>>> dependencies.
>>>>>>>  For AriesTrader I use that scope for all external  
>>>>>>> dependencies and I
>>>>>>> didn't
>>>>>>> have any unexpected dependencies included in the EBA generated  
>>>>>>> for
>>>>>>> AriesTrader.
>>>>>>
>>>>>> One of those dependencies was derby which wasn't marked with a  
>>>>>> scope
>>>>>> so has picked up the default 'compile' scope. Scope of provided  
>>>>>> will
>>>>>> make the classes available on the compile classpath which isn't  
>>>>>> even
>>>>>> needed. The scope would need to be 'test' if there was actually  
>>>>>> a test
>>>>>> case! So I think we can just remove the dependency of derby (in  
>>>>>> this
>>>>>> case).
>>>>>>
>>>>>>>
>>>>>>> Joe
>>>>>>>
>>>>>>>
>>>>>>> David Jencks wrote:
>>>>>>>>
>>>>>>>> I think it works.... contents look similar to what was  
>>>>>>>> generated
>>>>>>>> previously.  I attached a patch to ARIES-120 for ariestrader- 
>>>>>>>> all-eba
>>>>>>>> in
>>>>>>>> case
>>>>>>>> anyone wants to take a closer look or try deploying it.
>>>>>>>>
>>>>>>>> thanks
>>>>>>>> david jencks
>>>>>>>>
>>>>>>>> On Feb 25, 2010, at 6:25 PM, David Jencks wrote:
>>>>>>>>
>>>>>>>>> I adapted the maven-rar-plugin to do what I think an
>>>>>>>>> eba-maven-plugin
>>>>>>>>> ought to do and put it under application.  Right now it's  
>>>>>>>>> not tied
>>>>>>>>> into the
>>>>>>>>> build.  It may need to move elsewhere in the tree to make it  
>>>>>>>>> easier
>>>>>>>>> to
>>>>>>>>> use
>>>>>>>>> in aries itself, building and using plugins in the same  
>>>>>>>>> build can be
>>>>>>>>> tricky.
>>>>>>>>>
>>>>>>>>> So far you need to write the application.mf yourself and put  
>>>>>>>>> it in
>>>>>>>>> the
>>>>>>>>> source project under src/main/eba/META-INF/application.mf
>>>>>>>>>
>>>>>>>>> To use it your project needs to have
>>>>>>>>>
>>>>>>>>> <packaging>eba</packaging>
>>>>>>>>>
>>>>>>>>> and configure the plugin with
>>>>>>>>>
>>>>>>>>>  <build>
>>>>>>>>>     <plugins>
>>>>>>>>>         <plugin>
>>>>>>>>>             <groupId>org.apache.aries.application</groupId>
>>>>>>>>>             <artifactId>eba-maven-plugin</artifactId>
>>>>>>>>>             <version>1.0.0-incubating-SNAPSHOT</version>
>>>>>>>>>             <extensions>true</extensions>
>>>>>>>>>             <configuration>
>>>>>>>>>                 <includeJar>false</includeJar>
>>>>>>>>>             </configuration>
>>>>>>>>>         </plugin>
>>>>>>>>>     </plugins>
>>>>>>>>>  </build>
>>>>>>>>>
>>>>>>>>> Note the very required extensions element.
>>>>>>>>> By default it builds a jar from the java files in the  
>>>>>>>>> project and
>>>>>>>>> installs it in the eba.  The above configures it not to do  
>>>>>>>>> that.
>>>>>>>>>
>>>>>>>>> I haven't tried this on a real eba yet... if  anyone can try  
>>>>>>>>> that
>>>>>>>>> and
>>>>>>>>> see
>>>>>>>>> if the results work that would be great.  I'll probably try  
>>>>>>>>> tomorrow
>>>>>>>>> if no
>>>>>>>>> one gets there first.
>>>>>>>>>
>>>>>>>>> thanks
>>>>>>>>> david jencks
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Joe
>>>>>>>
>>>>>>
>>>>
>>>>
>>
>>