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
>>>>>>
>>>>
>>>>
>>
>
>
