FWIW, I've added to the latest maven bundle plugin a goal that can be used to transform a string into a correct osgi version. The goal is now run automatically in the aries build and you can use the aries.osgi.version.clean property to obtain the correct syntax corresponding to the maven version.
On Wed, Mar 3, 2010 at 18:48, Joe Bohn <[email protected]> wrote: > Sorry, I thought I replied to this yesterday but see that I didn't. > > > Jeremy Hughes wrote: > >> On 2 March 2010 19:30, Joe Bohn <[email protected]> wrote: >> >>> Thanks David. >>> >>> After I sent my last note I recalled another place in AriesTrader with >>> hard-coded versions. The APPLICATION.MF files used for the two EBAs >>> that >>> are generated includes the bundle version - which is a little different >>> than >>> the maven version. Where the maven version is currently >>> 1.0.0-incubating-SNAPSHOT the bundle version generated using the >>> maven-bundle-plugin is 1.0.0.incubating-SNAPSHOT to conform to the OSGi >>> version scheme. >>> >> >> Are you saying we couldn't quite generate the APPLICATION.MF using >> resource filtering because the ${version} will be >> 1.0.0-incubating-SNAPSHOT instead of 1.0.0.incubating-SNAPSHOT? >> > > Not necessarily. It's just that we'll need to keep the different format in > mind. > > > >> There are two things which might make this a moot point: >>> 1) If the eba-maven-plugin is enhanced to generate the APPLICATION.MF >>> then >>> we can use that to resolve the issue. >>> >> >> Yes I agree eba-maven-plugin should pull the same trick as the >> maven-bundle-plugin to ensure version numbers fit with the OSGi spec >> (whatever the logic for that conversion is). >> > > Yes. > > > >> 2) Even though this is an issue with SNAPSHOTs I imagine it isn't an >>> issue >>> with a non-snapshot release because it won't container the "-XXX" >>> qualification. >>> >> >> I think it'll continue to be an issue while we are using the -incubating >> suffix. >> > > Agreed. I wasn't sure if we were releasing 0.1 or 0.1-incubating. > > > >> Optionally, I could also just omit the APPLICATION.MF altogether from the >>> AriesTrader EBAs since I understand that it is not required. That might >>> be >>> quickest fix for now. >>> >> >> Do all the AriesTrader .eba files contain, by value, all the bundles >> they need? And, is that set transitively closed? If so then you >> certainly could remove the APPLICATION.MF. Or is it using the OBR >> resolver integration code to pull in bundles from a repository? >> > > At the moment the eba includes the complete set of bundles by value. > However, I'm not sure if that will always be the case (or even if it will be > the case in all environments for some of the dependencies, such as slf4j). > I'll experiment a bit. > > > >> Joe >>> >>> David Jencks wrote: >>> >>>> On Mar 2, 2010, at 10:33 AM, Joe Bohn wrote: >>>> >>>> I agree that we should make a global change to 0.1-incubating-SNAPSHOT >>>>> first. Why wouldn't we just do that now? >>>>> >>>> I started doing some experiments here... >>>> >>>> running >>>> mvn versions:set -DnewVersion=0.1-incubating-SNAPSHOT >>>> >>>> in root and parent upgrades everything maven knows about just fine. >>>> However there's (1) mentioned below and also a hardcoded version in two >>>> blueprint-itests. >>>> >>>> According to >>>> >>>> http://wiki.ops4j.org/display/paxexam/Configuration+using+Maven+Plugin >>>> >>>> we should be able to replace the hardcoded versions with >>>> .versionAsInProject() >>>> >>>> if we run the maven-paxexam-plugin on the project. However I can't get >>>> it >>>> to work yet. >>>> >>>>> Just a heads-up on some other issues related to versions in samples. >>>>> There are two potential problems that I am aware of: >>>>> >>>>> 1) For both Blog-Sample and AriesTrader there are hard-coded version >>>>> references in the Equinox assembly config.ini file which are used to >>>>> specify >>>>> the bundle jars that are to be started for the assembly. Naturally, the >>>>> versions of the aries bundles in this file won't be updated by the >>>>> maven-release-plugin. I'm not sure of a good solution for this beyond >>>>> just >>>>> manually changing the config.ini files prior to creating a release >>>>> candidate. >>>>> >>>> I think we might be able to work around this by putting the config.ini >>>> files in src/main/resources/filtered-resources and defining a bunch of >>>> properties in an appropriate pom and using them for the version imports >>>> of >>>> the aries subproject dependencyManagement imports in the samples root >>>> pom. >>>> I haven't tried this yet... >>>> >>>> 2) I think there is still an unresolved issue related to Blog-Sample >>>>> and >>>>> how we might be able to demonstrate a bundle upgrade scenario. I'm >>>>> not >>>>> sure if this capability is included yet in Blog-Sample - so it might >>>>> still >>>>> be a non-issue at the moment. However, we had some discussion on this >>>>> a >>>>> week ago or so related to how we might be able to include multiple >>>>> versions >>>>> of components in the sample so that an upgrade scenario could be >>>>> demonstrated. If that is still a goal for the 0.1 release we will need >>>>> to >>>>> come up with some solution. >>>>> >>>> no ideas from me on this one :-) >>>> >>>> thanks >>>> david jencks >>>> >>>> Joe >>>>> >>>>> >>>>> David Jencks wrote: >>>>> >>>>>> I think everything is ok.... I think (at least with dryRun=true) that >>>>>> the release plugin builds the project first as-is and checks that >>>>>> signing >>>>>> etc works. >>>>>> I added autoVersionSubmodules=true in the root parent pom which will >>>>>> make things work more smoothly :-) >>>>>> I really recommend changing the version to 0.1-incubating-SNAPSHOT >>>>>> first, I'm happy to do this if you want. >>>>>> thanks >>>>>> david jencks >>>>>> On Mar 2, 2010, at 9:14 AM, Jeremy Hughes wrote: >>>>>> >>>>>>> scratch that. I'm working thru this: >>>>>>> http://maven.apache.org/developers/release/apache-release.html as >>>>>>> there's several steps I haven't done. >>>>>>> >>>>>>> On 2 March 2010 16:17, Jeremy Hughes <[email protected]> wrote: >>>>>>> >>>>>>>> On 2 March 2010 02:28, David Jencks <[email protected]> wrote: >>>>>>>> >>>>>>>>> I've done most of what I think is needed for aries to be basically >>>>>>>>> releasable. There are some bits left and possibly stuff I've >>>>>>>>> missed. >>>>>>>>> >>>>>>>>> 1. legal file review. There are a bunch of NOTICE files that claim >>>>>>>>> that >>>>>>>>> work from osgi is included. Really? license and notice files are >>>>>>>>> supposed >>>>>>>>> to apply to what is actually in an artifact or checkout. Are some >>>>>>>>> of >>>>>>>>> our >>>>>>>>> source files copied from an osgi source? Also all the legal files >>>>>>>>> that end >>>>>>>>> up in binary artifacts need to be checked. Also we need to run the >>>>>>>>> rat >>>>>>>>> plugin: this should be configured in the default pom. Not sure if >>>>>>>>> I >>>>>>>>> will >>>>>>>>> get to this. >>>>>>>>> >>>>>>>>> 2. actually using the eba-maven-plugn. I'm not entirely sure how >>>>>>>>> to >>>>>>>>> make >>>>>>>>> sure that an eba is working so I didn't mess with this. I think >>>>>>>>> the >>>>>>>>> plugin >>>>>>>>> itself is working well enough to use though. >>>>>>>>> >>>>>>>>> 2. ordering dependencies and dependency management. I find it >>>>>>>>> convenient to >>>>>>>>> have these alphabetized so I can find what I'm looking for, but I >>>>>>>>> haven't >>>>>>>>> done this in most poms. I'm not sure why there isn't a usable tool >>>>>>>>> for >>>>>>>>> doing this but I haven't found one. Dull but useful... >>>>>>>>> >>>>>>>>> 3. It would probably be a really good idea to run mvn >>>>>>>>> dependency:analyze and >>>>>>>>> look carefully at the results. The results from this can require >>>>>>>>> interpretation so its best if someone who is very familiar with how >>>>>>>>> the code >>>>>>>>> works does this. >>>>>>>>> >>>>>>>>> 4. before a release all snapshots need to be resolved to released >>>>>>>>> versions. >>>>>>>>> I don't know if there are any snapshots. >>>>>>>>> >>>>>>>>> To summarize what I've tried to do: >>>>>>>>> >>>>>>>>> 1. default-parent has dependency management for the basic osgi >>>>>>>>> dependencies >>>>>>>>> that all projects are pretty sure to use including the pax stuff >>>>>>>>> used >>>>>>>>> mostly >>>>>>>>> for testing. >>>>>>>>> >>>>>>>>> 2. each subproject has legal files in its checkout root >>>>>>>>> >>>>>>>>> 3. each subproject has an scm element in its pom, but no others do. >>>>>>>>> >>>>>>>>> 4. each subproject has dependency management for everything >>>>>>>>> included >>>>>>>>> in it. >>>>>>>>> In addition, it has its subprojects listed in dependency >>>>>>>>> management. >>>>>>>>> (this >>>>>>>>> is bent slightly for the samples). This means that >>>>>>>>> (a) modules in a subproject don't need to include versions for use >>>>>>>>> of >>>>>>>>> other >>>>>>>>> modules >>>>>>>>> (b) you can get dependency management for all the modules in a >>>>>>>>> subproject >>>>>>>>> by depending on the subproject pom with scope import. (see the >>>>>>>>> samples pom >>>>>>>>> for an example). >>>>>>>>> >>>>>>>>> 5. As a result of (4), modules don't have any versions in any >>>>>>>>> dependency >>>>>>>>> elements. >>>>>>>>> >>>>>>>>> Release is going to involve... >>>>>>>>> >>>>>>>>> releasing the parent >>>>>>>>> >>>>>>>> In trunk/parent I tried: >>>>>>>> >>>>>>>> mvn -DdryRun=true release:prepare -Papache-release >>>>>>>> >>>>>>>> Providing 0.1-incubating for the release version >>>>>>>> Defaulting to parent-0.1-incubating for the SCM release tag >>>>>>>> Defaulting to 0.2-incubating-SNAPSHOT for the new development >>>>>>>> version >>>>>>>> >>>>>>>> then when it builds the 'Top Parent POM' it outputs this: >>>>>>>> >>>>>>>> [INFO] [INFO] >>>>>>>> >>>>>>>> ------------------------------------------------------------------------ >>>>>>>> [INFO] [INFO] Building Aries :: Top Parent POM >>>>>>>> [INFO] [INFO] task-segment: [clean, verify] >>>>>>>> [INFO] [INFO] >>>>>>>> >>>>>>>> ------------------------------------------------------------------------ >>>>>>>> [INFO] [INFO] [clean:clean] >>>>>>>> [INFO] [INFO] Setting property: classpath.resource.loader.class => >>>>>>>> 'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'. >>>>>>>> [INFO] [INFO] Setting property: velocimacro.messages.on => 'false'. >>>>>>>> [INFO] [INFO] Setting property: resource.loader => 'classpath'. >>>>>>>> [INFO] [INFO] Setting property: resource.manager.logwhenfound => >>>>>>>> 'false'. >>>>>>>> [INFO] [INFO] [remote-resources:process {execution: default}] >>>>>>>> [INFO] [INFO] [site:attach-descriptor] >>>>>>>> [INFO] [INFO] [assembly:single {execution: source-release-assembly}] >>>>>>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/ already added, >>>>>>>> skipping >>>>>>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/LICENSE already >>>>>>>> added, >>>>>>>> skipping >>>>>>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/NOTICE already added, >>>>>>>> skipping >>>>>>>> [INFO] [INFO] Building zip: >>>>>>>> >>>>>>>> >>>>>>>> C:\cygwin\home\hughesj\oss\aries\trunk\parent\target\parent-1.0.0-incubating-SNAPSHOT-source-release.zip >>>>>>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/ already added, >>>>>>>> skipping >>>>>>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/LICENSE already >>>>>>>> added, >>>>>>>> skipping >>>>>>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/NOTICE already added, >>>>>>>> skipping >>>>>>>> [INFO] [INFO] Preparing source:jar >>>>>>>> [INFO] [WARNING] Removing: jar from forked lifecycle, to prevent >>>>>>>> recursive invocation. >>>>>>>> [INFO] [INFO] No goals needed for project - skipping >>>>>>>> [INFO] [INFO] [source:jar {execution: attach-sources}] >>>>>>>> [INFO] [INFO] [javadoc:jar {execution: attach-javadocs}] >>>>>>>> [INFO] [INFO] Not executing Javadoc as the project is not a Java >>>>>>>> classpath-capable package >>>>>>>> [INFO] [INFO] [gpg:sign {execution: default}] >>>>>>>> >>>>>>>> so it seems to be outputting 1.0.0 artifacts still. Any ideas? >>>>>>>> >>>>>>>> Then stops at the gpg stage. I thought it would prompt me for my key >>>>>>>> passphrase at this point. Do I need gpg-agent to be running? >>>>>>>> >>>>>>>> updating the parent version wherever it is used (all subproject >>>>>>>>> parents) >>>>>>>>> >>>>>>>>> releasing the subprojects in an appropriate order and updating >>>>>>>>> their >>>>>>>>> versions wherever they are used. >>>>>>>>> >>>>>>>>> It might be worthwhile changing the pom version to >>>>>>>>> 0.1-incubating-SNAPSHOT >>>>>>>>> (or something similar, 0.0-incubating-SNAPSHOT?) before doing this >>>>>>>>> because >>>>>>>>> then the versions plugin can be used to update use of a subproject >>>>>>>>> to >>>>>>>>> the >>>>>>>>> newly released version of what it uses. Going from >>>>>>>>> 1.0.0-incubating-SNAPSHOT to 0.1-incubating won't allow this. >>>>>>>>> >>>>>>>>> As noted in the "root" pom, don't try to release the root pom and >>>>>>>>> don't try >>>>>>>>> release everything at once from the root pom. >>>>>>>>> >>>>>>>>> thanks >>>>>>>>> david jencks >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Feb 24, 2010, at 11:55 PM, David Jencks wrote: >>>>>>>>> >>>>>>>>> I started looking into cleaning up the build, and of course it is >>>>>>>>>> taking >>>>>>>>>> longer than I expected. >>>>>>>>>> >>>>>>>>>> I'm seriously hampered by failing tests in a fresh checkout. >>>>>>>>>> >>>>>>>>>> There are some projects in application that stop compiling if you >>>>>>>>>> alphabetize the dependencies. It looks like osgi 3 artifacts are >>>>>>>>>> getting on >>>>>>>>>> the maven classpath before osgi 4.2 artifacts. Adding exclusions >>>>>>>>>> to >>>>>>>>>> the >>>>>>>>>> dependencies seems to fix it if you can figure out where the out >>>>>>>>>> of >>>>>>>>>> date >>>>>>>>>> jars are coming from. >>>>>>>>>> >>>>>>>>>> The build is already much closer to a multi-release model than a >>>>>>>>>> single >>>>>>>>>> release model. >>>>>>>>>> >>>>>>>>>> I've diffed what I have so far and attached it to ARIES-173. It >>>>>>>>>> includes >>>>>>>>>> scm info and a lot of version corrections. Due to the failing >>>>>>>>>> tests >>>>>>>>>> I'm not >>>>>>>>>> too comfortable committing it. >>>>>>>>>> >>>>>>>>>> Is anyone else seeing test failures locally? >>>>>>>>>> >>>>>>>>>> thanks >>>>>>>>>> david jencks >>>>>>>>>> >>>>>>>>>> On Feb 24, 2010, at 1:50 PM, Lin Sun wrote: >>>>>>>>>> >>>>>>>>>> Hi David, >>>>>>>>>>> >>>>>>>>>>> It 'd be great if you are willing to fix these build issues, >>>>>>>>>>> since >>>>>>>>>>> you >>>>>>>>>>> just went through a big release in Geronimo. :) >>>>>>>>>>> >>>>>>>>>>> I know the maven release plugin isn't friendly to use some cases, >>>>>>>>>>> so >>>>>>>>>>> it is best we get these resolved to make our release process a >>>>>>>>>>> bit >>>>>>>>>>> easier. >>>>>>>>>>> >>>>>>>>>>> EBA plugin would be a very nice add-on, if it comes in time with >>>>>>>>>>> the >>>>>>>>>>> release. >>>>>>>>>>> >>>>>>>>>>> Thanks >>>>>>>>>>> >>>>>>>>>>> Lin >>>>>>>>>>> On Tue, Feb 23, 2010 at 8:56 PM, David Jencks >>>>>>>>>>> <[email protected]> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> I would like to understand the problems you see better, but I do >>>>>>>>>>>>> not >>>>>>>>>>>>> have >>>>>>>>>>>>> the maven background you guys have, any chance you could >>>>>>>>>>>>> explain >>>>>>>>>>>>> what >>>>>>>>>>>>> the >>>>>>>>>>>>> problems are, why they are problems and the solution at some >>>>>>>>>>>>> point? >>>>>>>>>>>>> >>>>>>>>>>>> The biggest immediate problem is that without correct svn info >>>>>>>>>>>> you >>>>>>>>>>>> can't >>>>>>>>>>>> do >>>>>>>>>>>> a release with the release plugin. I'm pretty sure the way its >>>>>>>>>>>> set up >>>>>>>>>>>> now, >>>>>>>>>>>> when you try, the tag will be under maven's apache pom, not >>>>>>>>>>>> aries. >>>>>>>>>>>> (you'll >>>>>>>>>>>> fail unless you happen to be a maven committer too). You >>>>>>>>>>>> definitely >>>>>>>>>>>> don't >>>>>>>>>>>> want to try to do a release without the release plugin. >>>>>>>>>>>> >>>>>>>>>>>> Organizationally there's no way that for instance blueprint, >>>>>>>>>>>> application, >>>>>>>>>>>> and samples should always be released in synchrony. Any time >>>>>>>>>>>> two >>>>>>>>>>>> of >>>>>>>>>>>> them >>>>>>>>>>>> happen to be ready for release at the same time it will be >>>>>>>>>>>> purely >>>>>>>>>>>> accidental. Right now everyone wants to get a milestone out the >>>>>>>>>>>> door, >>>>>>>>>>>> but >>>>>>>>>>>> looking at the different projects their state of completion is >>>>>>>>>>>> pretty >>>>>>>>>>>> much >>>>>>>>>>>> wildly different. A decision to release all of them at once is >>>>>>>>>>>> not >>>>>>>>>>>> based in >>>>>>>>>>>> any way on them being equally complete. I'm suggesting that >>>>>>>>>>>> since >>>>>>>>>>>> build >>>>>>>>>>>> fixes are needed anyway, why not set up a maintainable structure >>>>>>>>>>>> that >>>>>>>>>>>> will >>>>>>>>>>>> continue to work beyond this publicity release. The benefit to >>>>>>>>>>>> users is >>>>>>>>>>>> that aries will be able to release bits in a timely fashion; >>>>>>>>>>>> otherwise >>>>>>>>>>>> the >>>>>>>>>>>> entire project will never be in a releasable state at once. (I'm >>>>>>>>>>>> only >>>>>>>>>>>> exaggerating a little bit :-) >>>>>>>>>>>> >>>>>>>>>>>> What got me looking at this at all is what look like wild >>>>>>>>>>>> gyrations that >>>>>>>>>>>> don't really use maven properly to get an .eba (or some >>>>>>>>>>>> artifact) >>>>>>>>>>>> out >>>>>>>>>>>> the >>>>>>>>>>>> door. This might be ok for one release but (a) I think this can >>>>>>>>>>>> be done >>>>>>>>>>>> directly with the assembly plugin short term and (b) an >>>>>>>>>>>> eba-maven-plugin >>>>>>>>>>>> seems like the obvious more long term solution. >>>>>>>>>>>> >>>>>>>>>>>> I'm willing to fix the build and probably work on an eba plugin, >>>>>>>>>>>> but >>>>>>>>>>>> want to >>>>>>>>>>>> be sure this is ok with everyone first. >>>>>>>>>>>> >>>>>>>>>>>> thanks >>>>>>>>>>>> david jencks >>>>>>>>>>>> >>>>>>>>>>>> Thanks >>>>>>>>>>>>> Alasdair >>>>>>>>>>>>> >>>>>>>>>>>>> On 23 Feb 2010, at 18:18, David Jencks <[email protected] >>>>>>>>>>>>> > >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> This discussion got me worried enough to take a look at the >>>>>>>>>>>>>> aries >>>>>>>>>>>>>> build. >>>>>>>>>>>>>> Now I'm even more worried. >>>>>>>>>>>>>> >>>>>>>>>>>>>> While it might feel good to try to push out a release as fast >>>>>>>>>>>>>> as >>>>>>>>>>>>>> possible >>>>>>>>>>>>>> I'd prefer to see a sustainable build system in place first. >>>>>>>>>>>>>> So >>>>>>>>>>>>>> far >>>>>>>>>>>>>> it >>>>>>>>>>>>>> looks to me as if aries is going to be a bunch of loosely >>>>>>>>>>>>>> coupled >>>>>>>>>>>>>> subprojects. Building them all at once is not going to work >>>>>>>>>>>>>> for >>>>>>>>>>>>>> long. >>>>>>>>>>>>>> I >>>>>>>>>>>>>> think we should recognize that and put that in the build >>>>>>>>>>>>>> system >>>>>>>>>>>>>> now. >>>>>>>>>>>>>> To me >>>>>>>>>>>>>> this means: >>>>>>>>>>>>>> >>>>>>>>>>>>>> 1. a parent pom that isn't at the root of the svn trunk. >>>>>>>>>>>>>> 2. each subproject has pom info sufficient so it can be >>>>>>>>>>>>>> released >>>>>>>>>>>>>> (mostly >>>>>>>>>>>>>> svn info) (right now this is completely missing everywhere as >>>>>>>>>>>>>> far as >>>>>>>>>>>>>> I can >>>>>>>>>>>>>> see, which will result in ares getting tagged into svn as part >>>>>>>>>>>>>> of the >>>>>>>>>>>>>> apache >>>>>>>>>>>>>> pom) >>>>>>>>>>>>>> >>>>>>>>>>>>>> We can still have a "fake" pom that builds everything, but it >>>>>>>>>>>>>> won't be >>>>>>>>>>>>>> part of any release procedure. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Having separately released subprojects does not prevent having >>>>>>>>>>>>>> a >>>>>>>>>>>>>> single >>>>>>>>>>>>>> vote on all the releases. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I'd suggest a few other pom tweaks such as using resources and >>>>>>>>>>>>>> filtered-resources to distinguish when filtering is called >>>>>>>>>>>>>> for. >>>>>>>>>>>>>> >>>>>>>>>>>>>> In addition relevant to this particular bit of the thread, we >>>>>>>>>>>>>> need an >>>>>>>>>>>>>> eba-maven-plugin to assemble ebas. Getting this into a first >>>>>>>>>>>>>> release >>>>>>>>>>>>>> would >>>>>>>>>>>>>> be a great idea IMO. >>>>>>>>>>>>>> >>>>>>>>>>>>>> If there's general agreement I can spend some time playing >>>>>>>>>>>>>> with >>>>>>>>>>>>>> the >>>>>>>>>>>>>> build >>>>>>>>>>>>>> and possibly working on the eba plugin. >>>>>>>>>>>>>> >>>>>>>>>>>>>> thoughts? >>>>>>>>>>>>>> >>>>>>>>>>>>>> thanks >>>>>>>>>>>>>> david jencks >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Feb 22, 2010, at 2:01 PM, Joe Bohn wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Jeremy Hughes wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 19 February 2010 13:09, Joe Bohn <[email protected]> >>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I'd also like to see us release the sample applications but >>>>>>>>>>>>>>>>> I >>>>>>>>>>>>>>>>> think >>>>>>>>>>>>>>>>> there is >>>>>>>>>>>>>>>>> at least one complication. Both Blog Sample and >>>>>>>>>>>>>>>>> AriesTrader >>>>>>>>>>>>>>>>> generate >>>>>>>>>>>>>>>>> EBAs >>>>>>>>>>>>>>>>> using different techniques - but both leverage the >>>>>>>>>>>>>>>>> maven-antrun-plugin >>>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>> finally produce a file of type "eba". >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I realised the .eba file generated in the blog-assembly >>>>>>>>>>>>>>>> module >>>>>>>>>>>>>>>> wasn't >>>>>>>>>>>>>>>> being pushed into my local repo. I've made some changes to >>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>> pom.xml >>>>>>>>>>>>>>>> in ARIES-198 to fix this. So now it uses antrun to create >>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>> .eba >>>>>>>>>>>>>>>> artifact and the build-helper-maven-plugin to push the >>>>>>>>>>>>>>>> artifact to >>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>> local repo. I needed to add NOTICE and LICENSE files to the >>>>>>>>>>>>>>>> .eba for >>>>>>>>>>>>>>>> the ianal plugin in the verify phase to succeed. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I've not used the build-helper-maven-plugin before. Do you >>>>>>>>>>>>>>> know if >>>>>>>>>>>>>>> it >>>>>>>>>>>>>>> will work with the maven-release-plugin to push the eba >>>>>>>>>>>>>>> artifacts >>>>>>>>>>>>>>> when we do >>>>>>>>>>>>>>> a release? If so, then I should look at using the same >>>>>>>>>>>>>>> mechanism for >>>>>>>>>>>>>>> AriesTrader. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I think the result is that the eba will not be available in >>>>>>>>>>>>>>>>> a >>>>>>>>>>>>>>>>> maven >>>>>>>>>>>>>>>>> repository. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> One of the differences is that AriesTrader first generates >>>>>>>>>>>>>>>>> a >>>>>>>>>>>>>>>>> jar >>>>>>>>>>>>>>>>> using >>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>> maven-assembly-plugin and then copies this to an eba. The >>>>>>>>>>>>>>>>> jar will >>>>>>>>>>>>>>>>> be >>>>>>>>>>>>>>>>> managed by maven and IIUC it should be deployable as an >>>>>>>>>>>>>>>>> "application" >>>>>>>>>>>>>>>>> even >>>>>>>>>>>>>>>>> with an extension of "jar" rather than "eba". If that is >>>>>>>>>>>>>>>>> correct >>>>>>>>>>>>>>>>> then >>>>>>>>>>>>>>>>> perhaps delivery of an application jar is an acceptable >>>>>>>>>>>>>>>>> approach >>>>>>>>>>>>>>>>> for >>>>>>>>>>>>>>>>> the 1st >>>>>>>>>>>>>>>>> release. Unfortunately I haven't actually setup my equinox >>>>>>>>>>>>>>>>> assembly >>>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>> deploy the eba yet - it still deploys all of the individual >>>>>>>>>>>>>>>>> bundles. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Using the maven-assembly-plugin likely the preferred >>>>>>>>>>>>>>>> approach >>>>>>>>>>>>>>>> long >>>>>>>>>>>>>>>> term. Perhaps we could copy the artifact to .eba and use the >>>>>>>>>>>>>>>> build-helper-maven-plugin to remove the .jar artifact from >>>>>>>>>>>>>>>> maven >>>>>>>>>>>>>>>> control and add the .eba one? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I can give this a try for AriesTrader. If it doesn't work >>>>>>>>>>>>>>> out >>>>>>>>>>>>>>> - is >>>>>>>>>>>>>>> there anything wrong with the approach I mentioned earlier of >>>>>>>>>>>>>>> just >>>>>>>>>>>>>>> using the >>>>>>>>>>>>>>> jar artifacts rather than the eba artifacts? Will the >>>>>>>>>>>>>>> current >>>>>>>>>>>>>>> application >>>>>>>>>>>>>>> support only look at *.eba archives? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Joe >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Guillaume Nodet wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I'd like to see at least those included: >>>>>>>>>>>>>>>>>> * blueprint >>>>>>>>>>>>>>>>>> * jmx >>>>>>>>>>>>>>>>>> * jndi >>>>>>>>>>>>>>>>>> * transaction >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I don't think applications are really usable yet and I >>>>>>>>>>>>>>>>>> haven't >>>>>>>>>>>>>>>>>> really >>>>>>>>>>>>>>>>>> looked at JPA yet, so can't tell about it. >>>>>>>>>>>>>>>>>> The transaction component is functional and we've been >>>>>>>>>>>>>>>>>> using >>>>>>>>>>>>>>>>>> it >>>>>>>>>>>>>>>>>> mostly >>>>>>>>>>>>>>>>>> unchanged since a long time in ServiceMix. >>>>>>>>>>>>>>>>>> Do you have any particular concerns with it ? (I'm not >>>>>>>>>>>>>>>>>> talking >>>>>>>>>>>>>>>>>> about >>>>>>>>>>>>>>>>>> declarative transactions for blueprint, note). >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On Fri, Feb 19, 2010 at 04:19, Joe Bohn < >>>>>>>>>>>>>>>>>> [email protected]> >>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Thanks for the response (even while on vacation!) ... and >>>>>>>>>>>>>>>>>>> for >>>>>>>>>>>>>>>>>>> volunteering >>>>>>>>>>>>>>>>>>> to be the release manager. Your response helps me get a >>>>>>>>>>>>>>>>>>> better >>>>>>>>>>>>>>>>>>> picture >>>>>>>>>>>>>>>>>>> of >>>>>>>>>>>>>>>>>>> the plans. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I was really just interested in the general objectives >>>>>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>>>> timing >>>>>>>>>>>>>>>>>>> since >>>>>>>>>>>>>>>>>>> it >>>>>>>>>>>>>>>>>>> hadn't been discussed yet. To get the release out in Feb >>>>>>>>>>>>>>>>>>> means >>>>>>>>>>>>>>>>>>> it >>>>>>>>>>>>>>>>>>> will >>>>>>>>>>>>>>>>>>> be >>>>>>>>>>>>>>>>>>> delivered next week. I'm afraid the hill might be a >>>>>>>>>>>>>>>>>>> little >>>>>>>>>>>>>>>>>>> too >>>>>>>>>>>>>>>>>>> steep to >>>>>>>>>>>>>>>>>>> climb that quickly but I'm happy to be proven wrong. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> The more communication the better. It's important to get >>>>>>>>>>>>>>>>>>> everybody >>>>>>>>>>>>>>>>>>> thinking >>>>>>>>>>>>>>>>>>> and planning along the same lines (or understand quickly >>>>>>>>>>>>>>>>>>> if >>>>>>>>>>>>>>>>>>> there >>>>>>>>>>>>>>>>>>> are any >>>>>>>>>>>>>>>>>>> differences of opinion). Knowing that you are thinking >>>>>>>>>>>>>>>>>>> of >>>>>>>>>>>>>>>>>>> creating >>>>>>>>>>>>>>>>>>> a >>>>>>>>>>>>>>>>>>> release candidate next week means that we should be >>>>>>>>>>>>>>>>>>> getting >>>>>>>>>>>>>>>>>>> more >>>>>>>>>>>>>>>>>>> restrictive >>>>>>>>>>>>>>>>>>> on new content to avoid any unpleasant surprises. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I don't have any strong opinions on what should be in or >>>>>>>>>>>>>>>>>>> out - >>>>>>>>>>>>>>>>>>> but >>>>>>>>>>>>>>>>>>> in >>>>>>>>>>>>>>>>>>> general it doesn't make sense to release things that >>>>>>>>>>>>>>>>>>> aren't >>>>>>>>>>>>>>>>>>> functional. >>>>>>>>>>>>>>>>>>> At >>>>>>>>>>>>>>>>>>> the moment I'm not sure what those are - but I suspect >>>>>>>>>>>>>>>>>>> not >>>>>>>>>>>>>>>>>>> all of >>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>> components are fully functional yet (for example >>>>>>>>>>>>>>>>>>> transaction). >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Best Regards, >>>>>>>>>>>>>>>>>>> Joe >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Jeremy Hughes wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Hi Joe, sorry I started setting myself up tuesday but am >>>>>>>>>>>>>>>>>>>> now out >>>>>>>>>>>>>>>>>>>> on >>>>>>>>>>>>>>>>>>>> vacation until monday. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Personally, I think the 0.1 release should serve to get >>>>>>>>>>>>>>>>>>>> what we >>>>>>>>>>>>>>>>>>>> have >>>>>>>>>>>>>>>>>>>> right now in the respectable form the ASF requires. So >>>>>>>>>>>>>>>>>>>> 'must >>>>>>>>>>>>>>>>>>>> haves' >>>>>>>>>>>>>>>>>>>> are to get the build in the right shape to create the >>>>>>>>>>>>>>>>>>>> distribution >>>>>>>>>>>>>>>>>>>> files that are acceptable to the IPMC. I think each main >>>>>>>>>>>>>>>>>>>> area of >>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>> code deserves at least a README to describe what's >>>>>>>>>>>>>>>>>>>> possible. >>>>>>>>>>>>>>>>>>>> Since >>>>>>>>>>>>>>>>>>>> this is the first release there are likely a few >>>>>>>>>>>>>>>>>>>> unknowns >>>>>>>>>>>>>>>>>>>> - >>>>>>>>>>>>>>>>>>>> w.r.t >>>>>>>>>>>>>>>>>>>> timing I hope/expect to get the release out this in feb. >>>>>>>>>>>>>>>>>>>> If >>>>>>>>>>>>>>>>>>>> there >>>>>>>>>>>>>>>>>>>> are >>>>>>>>>>>>>>>>>>>> particular JIRAs or other issues you feel should be >>>>>>>>>>>>>>>>>>>> included >>>>>>>>>>>>>>>>>>>> please >>>>>>>>>>>>>>>>>>>> say. I'd like to rename the current JIRA version 1.0 to >>>>>>>>>>>>>>>>>>>> 0.1 and >>>>>>>>>>>>>>>>>>>> target >>>>>>>>>>>>>>>>>>>> issues for 0.1 appropriately and issues not for 0.1 to >>>>>>>>>>>>>>>>>>>> target a >>>>>>>>>>>>>>>>>>>> new >>>>>>>>>>>>>>>>>>>> 0.2 version. WDYT? >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Cheers, >>>>>>>>>>>>>>>>>>>> Jeremy >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On 18 February 2010 15:39, Joe Bohn <[email protected]> >>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Jeremy, >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> What are your current thoughts and goals regarding the >>>>>>>>>>>>>>>>>>>>> release >>>>>>>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>>>>>> potential >>>>>>>>>>>>>>>>>>>>> target dates? >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> I think it would be good if you could summarize your >>>>>>>>>>>>>>>>>>>>> thoughts >>>>>>>>>>>>>>>>>>>>> in >>>>>>>>>>>>>>>>>>>>> an >>>>>>>>>>>>>>>>>>>>> email >>>>>>>>>>>>>>>>>>>>> or >>>>>>>>>>>>>>>>>>>>> perhaps on a page in the wiki that we can keep updated >>>>>>>>>>>>>>>>>>>>> as >>>>>>>>>>>>>>>>>>>>> we >>>>>>>>>>>>>>>>>>>>> make >>>>>>>>>>>>>>>>>>>>> progress. >>>>>>>>>>>>>>>>>>>>> Of particular interest would be the content that we >>>>>>>>>>>>>>>>>>>>> would >>>>>>>>>>>>>>>>>>>>> like >>>>>>>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>>>>>> see >>>>>>>>>>>>>>>>>>>>> in >>>>>>>>>>>>>>>>>>>>> the first release (clarifying what we consider "must >>>>>>>>>>>>>>>>>>>>> have" from >>>>>>>>>>>>>>>>>>>>> "nice >>>>>>>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>>>>>> have"), the current status of that content, target >>>>>>>>>>>>>>>>>>>>> dates >>>>>>>>>>>>>>>>>>>>> for >>>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>> release, >>>>>>>>>>>>>>>>>>>>> and the process that we plan to use to generate the >>>>>>>>>>>>>>>>>>>>> release. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>> Joe >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Jeremy Hughes wrote: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> On 12 February 2010 09:39, Guillaume Nodet >>>>>>>>>>>>>>>>>>>>>> <[email protected]> >>>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Great, thanks a lot. Let us know if you need any >>>>>>>>>>>>>>>>>>>>>>> help. >>>>>>>>>>>>>>>>>>>>>>> I guess if you take some notes, it would be >>>>>>>>>>>>>>>>>>>>>>> interesting >>>>>>>>>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>>>>>>>> put >>>>>>>>>>>>>>>>>>>>>>> those >>>>>>>>>>>>>>>>>>>>>>> on the wiki. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Certainly will. It's been a while since I did one and >>>>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>> process >>>>>>>>>>>>>>>>>>>>>> has >>>>>>>>>>>>>>>>>>>>>> changed quite a bit :-) >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> On Fri, Feb 12, 2010 at 10:32, Jeremy Hughes >>>>>>>>>>>>>>>>>>>>>>> <[email protected]> >>>>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Hi Kevan, thanks. I volunteer to be release manager. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Jeremy >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> On 11 February 2010 16:38, Kevan Miller >>>>>>>>>>>>>>>>>>>>>>>> <[email protected]> >>>>>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Sounds like the consensus is for a release with all >>>>>>>>>>>>>>>>>>>>>>>>> components >>>>>>>>>>>>>>>>>>>>>>>>> at a >>>>>>>>>>>>>>>>>>>>>>>>> 0.1 >>>>>>>>>>>>>>>>>>>>>>>>> version number. Best to start with a simple >>>>>>>>>>>>>>>>>>>>>>>>> versioning >>>>>>>>>>>>>>>>>>>>>>>>> scheme, >>>>>>>>>>>>>>>>>>>>>>>>> IMO. >>>>>>>>>>>>>>>>>>>>>>>>> Personally, I don't view a 0.1 blueprint release as >>>>>>>>>>>>>>>>>>>>>>>>> an >>>>>>>>>>>>>>>>>>>>>>>>> issue. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Showing the ability to generate an Apache release >>>>>>>>>>>>>>>>>>>>>>>>> is >>>>>>>>>>>>>>>>>>>>>>>>> an >>>>>>>>>>>>>>>>>>>>>>>>> important >>>>>>>>>>>>>>>>>>>>>>>>> step >>>>>>>>>>>>>>>>>>>>>>>>> for the community. Would definitely like to see >>>>>>>>>>>>>>>>>>>>>>>>> this >>>>>>>>>>>>>>>>>>>>>>>>> happen... >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> We'll need a release manager. Any volunteers? >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> --kevan >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>>>>> Cheers, >>>>>>>>>>>>>>>>>>>>>>> Guillaume Nodet >>>>>>>>>>>>>>>>>>>>>>> ------------------------ >>>>>>>>>>>>>>>>>>>>>>> Blog: http://gnodet.blogspot.com/ >>>>>>>>>>>>>>>>>>>>>>> ------------------------ >>>>>>>>>>>>>>>>>>>>>>> Open Source SOA >>>>>>>>>>>>>>>>>>>>>>> http://fusesource.com >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>>> Joe >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>> Joe >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>> Joe >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> Joe >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>> >>>>> -- >>>>> Joe >>>>> >>>> >>>> >>> -- >>> Joe >>> >>> >> > > -- > Joe > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
