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 <[email protected]> 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 <[email protected]> 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 <[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 >>>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>> >>>> >> >
