You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@aries.apache.org by David Jencks <da...@yahoo.com> on 2010/02/26 03:25:20 UTC
eba-maven-plugin
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
Re: eba-maven-plugin
Posted by Graham Charters <gc...@googlemail.com>.
I have a modified version of the maven-zip-plugin that addresses the
three issues I mentioned in my earlier note. I'll check it in later
today.
Regards, Graham.
On 26 February 2010 12:07, Graham Charters <gc...@googlemail.com> wrote:
> I'm thinking that might address some of the problems I raised. I'll
> give it a go and see where it gets us.
>
> Regards, Graham.
>
> On 26 February 2010 10:37, Jeremy Hughes <hu...@apache.org> wrote:
>> On 26 February 2010 09:23, Graham Charters <gc...@googlemail.com> wrote:
>>> Hi David,
>>>
>>> Thanks for this!
>>>
>>> I created an EBA project for the blog sample. The pom is shown below.
>>> In general it seems to work, but I have a few niggles (number 2 is
>>> the only show-stopper for me):
>>>
>>> 1. Because this is based on a jar archive, the plugin generates a
>>> MANIFEST.MF. An eba is just a zip and does not need nor use the
>>> MANIFEST.MF.
>>
>> Perhaps this maven plugin would be a better starting point:
>> http://people.apache.org/~olamy/snapshots/maven-zip-plugin/
>>
>>> 2. My eba archive ended up containing two transitive dependencies
>>> (derby and servlet-api). How can I prevent these from going into the
>>> archive?
>>> 3. The archive also contained pom.properties and pom.xml files in
>>> META-INF/maven/org.apache.aries.samples/blog-sample-eba. Is there any
>>> way to stop these going in?
>>>
>>> Thanks again!
>>>
>>> Regards, Graham.
>>>
>>> <groupId>org.apache.aries.samples</groupId>
>>> <version>1.0.0-incubating-SNAPSHOT</version>
>>> <artifactId>blog-sample-eba</artifactId>
>>> <name>Apache Aries blog sample EBA</name>
>>> <packaging>eba</packaging>
>>> <parent>
>>> <groupId>org.apache.aries.samples</groupId>
>>> <artifactId>samples</artifactId>
>>> <version>1.0.0-incubating-SNAPSHOT</version>
>>> </parent>
>>> <dependencies>
>>> <dependency>
>>> <groupId>org.apache.aries.samples</groupId>
>>> <artifactId>blog-api</artifactId>
>>> <version>1.0.0</version>
>>> </dependency>
>>> <dependency>
>>> <groupId>org.apache.aries.samples</groupId>
>>> <artifactId>blog-servlet</artifactId>
>>> <version>1.0.0</version>
>>> </dependency>
>>> <dependency>
>>> <groupId>org.apache.aries.samples</groupId>
>>> <artifactId>blog</artifactId>
>>> <version>1.0.0</version>
>>> </dependency>
>>> <dependency>
>>> <groupId>org.apache.aries.samples</groupId>
>>> <artifactId>blog-persistence</artifactId>
>>> <version>1.0.0</version>
>>> </dependency>
>>> </dependencies>
>>>
>>> <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>
>>>
>>> On 26 February 2010 09:13, Jeremy Hughes <hu...@apache.org> wrote:
>>>> Thanks I'll try it out!
>>>>
>>>> On 26 February 2010 09:07, David Jencks <da...@yahoo.com> 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
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
Re: eba-maven-plugin
Posted by Graham Charters <gc...@googlemail.com>.
I'm thinking that might address some of the problems I raised. I'll
give it a go and see where it gets us.
Regards, Graham.
On 26 February 2010 10:37, Jeremy Hughes <hu...@apache.org> wrote:
> On 26 February 2010 09:23, Graham Charters <gc...@googlemail.com> wrote:
>> Hi David,
>>
>> Thanks for this!
>>
>> I created an EBA project for the blog sample. The pom is shown below.
>> In general it seems to work, but I have a few niggles (number 2 is
>> the only show-stopper for me):
>>
>> 1. Because this is based on a jar archive, the plugin generates a
>> MANIFEST.MF. An eba is just a zip and does not need nor use the
>> MANIFEST.MF.
>
> Perhaps this maven plugin would be a better starting point:
> http://people.apache.org/~olamy/snapshots/maven-zip-plugin/
>
>> 2. My eba archive ended up containing two transitive dependencies
>> (derby and servlet-api). How can I prevent these from going into the
>> archive?
>> 3. The archive also contained pom.properties and pom.xml files in
>> META-INF/maven/org.apache.aries.samples/blog-sample-eba. Is there any
>> way to stop these going in?
>>
>> Thanks again!
>>
>> Regards, Graham.
>>
>> <groupId>org.apache.aries.samples</groupId>
>> <version>1.0.0-incubating-SNAPSHOT</version>
>> <artifactId>blog-sample-eba</artifactId>
>> <name>Apache Aries blog sample EBA</name>
>> <packaging>eba</packaging>
>> <parent>
>> <groupId>org.apache.aries.samples</groupId>
>> <artifactId>samples</artifactId>
>> <version>1.0.0-incubating-SNAPSHOT</version>
>> </parent>
>> <dependencies>
>> <dependency>
>> <groupId>org.apache.aries.samples</groupId>
>> <artifactId>blog-api</artifactId>
>> <version>1.0.0</version>
>> </dependency>
>> <dependency>
>> <groupId>org.apache.aries.samples</groupId>
>> <artifactId>blog-servlet</artifactId>
>> <version>1.0.0</version>
>> </dependency>
>> <dependency>
>> <groupId>org.apache.aries.samples</groupId>
>> <artifactId>blog</artifactId>
>> <version>1.0.0</version>
>> </dependency>
>> <dependency>
>> <groupId>org.apache.aries.samples</groupId>
>> <artifactId>blog-persistence</artifactId>
>> <version>1.0.0</version>
>> </dependency>
>> </dependencies>
>>
>> <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>
>>
>> On 26 February 2010 09:13, Jeremy Hughes <hu...@apache.org> wrote:
>>> Thanks I'll try it out!
>>>
>>> On 26 February 2010 09:07, David Jencks <da...@yahoo.com> 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
>>>>>
>>>>
>>>>
>>>
>>
>
Re: eba-maven-plugin
Posted by Jeremy Hughes <hu...@apache.org>.
On 26 February 2010 09:23, Graham Charters <gc...@googlemail.com> wrote:
> Hi David,
>
> Thanks for this!
>
> I created an EBA project for the blog sample. The pom is shown below.
> In general it seems to work, but I have a few niggles (number 2 is
> the only show-stopper for me):
>
> 1. Because this is based on a jar archive, the plugin generates a
> MANIFEST.MF. An eba is just a zip and does not need nor use the
> MANIFEST.MF.
Perhaps this maven plugin would be a better starting point:
http://people.apache.org/~olamy/snapshots/maven-zip-plugin/
> 2. My eba archive ended up containing two transitive dependencies
> (derby and servlet-api). How can I prevent these from going into the
> archive?
> 3. The archive also contained pom.properties and pom.xml files in
> META-INF/maven/org.apache.aries.samples/blog-sample-eba. Is there any
> way to stop these going in?
>
> Thanks again!
>
> Regards, Graham.
>
> <groupId>org.apache.aries.samples</groupId>
> <version>1.0.0-incubating-SNAPSHOT</version>
> <artifactId>blog-sample-eba</artifactId>
> <name>Apache Aries blog sample EBA</name>
> <packaging>eba</packaging>
> <parent>
> <groupId>org.apache.aries.samples</groupId>
> <artifactId>samples</artifactId>
> <version>1.0.0-incubating-SNAPSHOT</version>
> </parent>
> <dependencies>
> <dependency>
> <groupId>org.apache.aries.samples</groupId>
> <artifactId>blog-api</artifactId>
> <version>1.0.0</version>
> </dependency>
> <dependency>
> <groupId>org.apache.aries.samples</groupId>
> <artifactId>blog-servlet</artifactId>
> <version>1.0.0</version>
> </dependency>
> <dependency>
> <groupId>org.apache.aries.samples</groupId>
> <artifactId>blog</artifactId>
> <version>1.0.0</version>
> </dependency>
> <dependency>
> <groupId>org.apache.aries.samples</groupId>
> <artifactId>blog-persistence</artifactId>
> <version>1.0.0</version>
> </dependency>
> </dependencies>
>
> <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>
>
> On 26 February 2010 09:13, Jeremy Hughes <hu...@apache.org> wrote:
>> Thanks I'll try it out!
>>
>> On 26 February 2010 09:07, David Jencks <da...@yahoo.com> 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
>>>>
>>>
>>>
>>
>
Re: eba-maven-plugin
Posted by Graham Charters <gc...@googlemail.com>.
Hi David,
Thanks for this!
I created an EBA project for the blog sample. The pom is shown below.
In general it seems to work, but I have a few niggles (number 2 is
the only show-stopper for me):
1. Because this is based on a jar archive, the plugin generates a
MANIFEST.MF. An eba is just a zip and does not need nor use the
MANIFEST.MF.
2. My eba archive ended up containing two transitive dependencies
(derby and servlet-api). How can I prevent these from going into the
archive?
3. The archive also contained pom.properties and pom.xml files in
META-INF/maven/org.apache.aries.samples/blog-sample-eba. Is there any
way to stop these going in?
Thanks again!
Regards, Graham.
<groupId>org.apache.aries.samples</groupId>
<version>1.0.0-incubating-SNAPSHOT</version>
<artifactId>blog-sample-eba</artifactId>
<name>Apache Aries blog sample EBA</name>
<packaging>eba</packaging>
<parent>
<groupId>org.apache.aries.samples</groupId>
<artifactId>samples</artifactId>
<version>1.0.0-incubating-SNAPSHOT</version>
</parent>
<dependencies>
<dependency>
<groupId>org.apache.aries.samples</groupId>
<artifactId>blog-api</artifactId>
<version>1.0.0</version>
</dependency>
<dependency>
<groupId>org.apache.aries.samples</groupId>
<artifactId>blog-servlet</artifactId>
<version>1.0.0</version>
</dependency>
<dependency>
<groupId>org.apache.aries.samples</groupId>
<artifactId>blog</artifactId>
<version>1.0.0</version>
</dependency>
<dependency>
<groupId>org.apache.aries.samples</groupId>
<artifactId>blog-persistence</artifactId>
<version>1.0.0</version>
</dependency>
</dependencies>
<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>
On 26 February 2010 09:13, Jeremy Hughes <hu...@apache.org> wrote:
> Thanks I'll try it out!
>
> On 26 February 2010 09:07, David Jencks <da...@yahoo.com> 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
>>>
>>
>>
>
Re: eba-maven-plugin
Posted by Jeremy Hughes <hu...@apache.org>.
Thanks I'll try it out!
On 26 February 2010 09:07, David Jencks <da...@yahoo.com> 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
>>
>
>
Re: eba-maven-plugin
Posted by Graham Charters <gc...@googlemail.com>.
On 27 February 2010 22:49, David Jencks <da...@yahoo.com> wrote:
>
> On Feb 27, 2010, at 1:38 PM, Graham Charters wrote:
>
>> Thanks, David, looks great! My only minor comment would be the
>> default for including the maven goo is true, but if that's the same
>> default as for similar plug-ins, then perhaps we should leave it
>> as-is.
>
> Including it is definitely the default for other packaging plugins.
>
>>
>> Are you thinking of doing the manifest generation? If not, I might
>> have a crack at it this week.
>
> I wouldn't mind working on it but should probably get back to making
> geronimo work :-) So, go ahead, let me know if you'd like any help.
>
Thanks, Dave, I'll give it a go. May well be taking you up on the
help offer :-)
> Where it is now in svn is going to cause problems with any attempt to use
> the eba-maven-plugin inside application such as for itests so I am planning
> to move it to a top-level subproject today or tommorrow.
>
> thanks
> david jencks
>
>>
>> Regards, Graham.
>>
>> On 27 February 2010 09:26, Alasdair Nottingham <no...@apache.org> wrote:
>>>
>>> The application.mf does follow the manifest format with line wrapping and
>>> so
>>> on, but we have our own parsing code to remove the stupid 76 byte line
>>> length restriction.
>>>
>>> Alasdair
>>>
>>> On 27 Feb 2010, at 00:35, David Jencks <da...@yahoo.com> wrote:
>>>
>>>>
>>>> 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 <da...@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 <da...@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 <hu...@apache.org>
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> On 26 February 2010 16:20, Joe Bohn <jo...@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
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>
>
>
Re: eba-maven-plugin
Posted by David Jencks <da...@yahoo.com>.
On Feb 27, 2010, at 1:38 PM, Graham Charters wrote:
> Thanks, David, looks great! My only minor comment would be the
> default for including the maven goo is true, but if that's the same
> default as for similar plug-ins, then perhaps we should leave it
> as-is.
Including it is definitely the default for other packaging plugins.
>
> Are you thinking of doing the manifest generation? If not, I might
> have a crack at it this week.
I wouldn't mind working on it but should probably get back to making
geronimo work :-) So, go ahead, let me know if you'd like any help.
Where it is now in svn is going to cause problems with any attempt to
use the eba-maven-plugin inside application such as for itests so I am
planning to move it to a top-level subproject today or tommorrow.
thanks
david jencks
>
> Regards, Graham.
>
> On 27 February 2010 09:26, Alasdair Nottingham <no...@apache.org> wrote:
>> The application.mf does follow the manifest format with line
>> wrapping and so
>> on, but we have our own parsing code to remove the stupid 76 byte
>> line
>> length restriction.
>>
>> Alasdair
>>
>> On 27 Feb 2010, at 00:35, David Jencks <da...@yahoo.com>
>> wrote:
>>
>>>
>>> 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 <da...@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
>>>>>> <da...@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 <hu...@apache.org>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> On 26 February 2010 16:20, Joe Bohn <jo...@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
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>
>>
Re: eba-maven-plugin
Posted by Graham Charters <gc...@googlemail.com>.
Thanks, David, looks great! My only minor comment would be the
default for including the maven goo is true, but if that's the same
default as for similar plug-ins, then perhaps we should leave it
as-is.
Are you thinking of doing the manifest generation? If not, I might
have a crack at it this week.
Regards, Graham.
On 27 February 2010 09:26, Alasdair Nottingham <no...@apache.org> wrote:
> The application.mf does follow the manifest format with line wrapping and so
> on, but we have our own parsing code to remove the stupid 76 byte line
> length restriction.
>
> Alasdair
>
> On 27 Feb 2010, at 00:35, David Jencks <da...@yahoo.com> wrote:
>
>>
>> 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 <da...@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 <da...@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 <hu...@apache.org> wrote:
>>>>>>>>
>>>>>>>> On 26 February 2010 16:20, Joe Bohn <jo...@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
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>
>
Re: eba-maven-plugin
Posted by Alasdair Nottingham <no...@apache.org>.
The application.mf does follow the manifest format with line wrapping
and so on, but we have our own parsing code to remove the stupid 76
byte line length restriction.
Alasdair
On 27 Feb 2010, at 00:35, David Jencks <da...@yahoo.com> wrote:
>
> 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 <da...@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 <da...@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 <hu...@apache.org>
>>>>>> wrote:
>>>>>>>
>>>>>>> On 26 February 2010 16:20, Joe Bohn <jo...@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
>>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>
>>>
>
Re: eba-maven-plugin
Posted by David Jencks <da...@yahoo.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 <da...@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 <da...@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 <hu...@apache.org>
>>>>> wrote:
>>>>>>
>>>>>> On 26 February 2010 16:20, Joe Bohn <jo...@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
>>>>>>>
>>>>>>
>>>>
>>>>
>>
>>
Re: eba-maven-plugin
Posted by Graham Charters <gc...@googlemail.com>.
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.
Regards, Graham.
On 26 February 2010 22:41, David Jencks <da...@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 <da...@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 <hu...@apache.org> wrote:
>>>>>
>>>>> On 26 February 2010 16:20, Joe Bohn <jo...@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
>>>>>>
>>>>>
>>>
>>>
>
>
Re: eba-maven-plugin
Posted by David Jencks <da...@yahoo.com>.
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 <da...@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 <hu...@apache.org> wrote:
>>>>
>>>> On 26 February 2010 16:20, Joe Bohn <jo...@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
>>>>>
>>>>
>>
>>
Re: eba-maven-plugin
Posted by Graham Charters <gc...@googlemail.com>.
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.
Regards, Graham.
On 26 February 2010 18:34, David Jencks <da...@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 <hu...@apache.org> wrote:
>>>
>>> On 26 February 2010 16:20, Joe Bohn <jo...@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
>>>>
>>>
>
>
Re: eba-maven-plugin
Posted by David Jencks <da...@yahoo.com>.
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 <hu...@apache.org> wrote:
>> On 26 February 2010 16:20, Joe Bohn <jo...@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
>>>
>>
Re: eba-maven-plugin
Posted by Graham Charters <gc...@googlemail.com>.
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 <hu...@apache.org> wrote:
> On 26 February 2010 16:20, Joe Bohn <jo...@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
>>
>
Re: eba-maven-plugin
Posted by Jeremy Hughes <hu...@apache.org>.
On 26 February 2010 16:20, Joe Bohn <jo...@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
>
Re: eba-maven-plugin
Posted by Joe Bohn <jo...@gmail.com>.
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.
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
Re: eba-maven-plugin
Posted by David Jencks <da...@yahoo.com>.
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
>