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 <[email protected]> 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 <[email protected]> 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 <[email protected]> wrote: >>>>> >>>>> On 26 February 2010 16:20, Joe Bohn <[email protected]> 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 >>>>>> >>>>> >>> >>> > >
