On 27 February 2010 22:49, David Jencks <[email protected]> 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 <[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 >>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>> >>> > >
