Hey Florian,
sorry for not answering earlier, busy spring days :)
As also Florent pointed out, I agree we should not by any means slow
down the release process we finally getting closer to.
Build.xml is good enough for now, and thanks a lot for having put it
together.
Still, there are some improvements I'd like to work on, described below:
On May 11, 2010, at 10:34 AM, Florian Müller wrote:
Hi Gabriele,
I have tried and failed. Maybe it's just my lack of Maven knowledge.
An OpenCMIS release does not strictly follow the Maven pattern.
There are several exceptions like fetching documentation for a HTTP
server and bundling specific files from different Maven modules into
one release package.
I've heard feelings similar to yours about Maven in the past, and I
guess I was one of those lucky ones who actually got it to work (tough
in the early times) and can't live anymore without it :)
And latest Maven versions, especially if properly used in conjunction
with repository managers (like Nexus @ Apache [1]), really make code
and docs release a charm.
Personally, I prefer a 500 line build.xml that is relatively easy to
understand and to change to a lot of magic XML fragments scattered
across 16 pom.xmls.
I think that the point is understanding the requirements for our build/
doc process and in due time linearize it. We should probably discuss
this on a separate, broader thread.
For now, even for this release, I'd still like at least to make JARs/
ZIPs/POMs available on the Apache Maven Repo [1]? I think we
definitely should, for the vast maven developers community and for the
framework/embeddable nature of this project.
I'm willing to take care of this according to the standard ASF Maven
release policies [2]: maybe for now just adding an embedded 'mvn
deploy' in your build.xml would do.
WDYT?
But maybe it's just my ignorance. If there is a simple Maven
solution, we should go with Maven.
I'm happy to spend some time, if you guys are interested, in creating/
working on some Jira improvements for the next release on this topic.
Baseline a maven release comprises few lines of maven-release-plugin
config [3], maven-site configs [4], and, as we want custom packages,
assembly plugin [5] configurations (which BTW IIUC we already use?)
As a sidenote that might be interesting, as I got fed up even of
repeating this little exercise in the past, I contributed to an open
source "community" superPOM, called Calm [6], which preconfigures
release/docs for you.
If you agree, I could branch and POC there the usage of:
- mvn release
- mvn site (maybe in conjunction with confluence doxia features [7],
as we best decide to use them)
- mvn assembly
- maybe using maven calm
Let me know if you think it's worth, and I'd be happy to start a more
detailed discussion on a new email thread.
HTH!
Ciao,
Gabriele
[1] https://repository.apache.org/index.html
[2] http://maven.apache.org/developers/release/apache-release.html
[3] http://maven.apache.org/plugins/maven-release-plugin/
[4 http://maven.apache.org/guides/mini/guide-site.html
[5] http://maven.apache.org/plugins/maven-assembly-plugin/assembly.html
[6] http://code.google.com/p/maven-calm/
[7]
http://mail-archives.apache.org/mod_mbox/incubator-chemistry-dev/201005.mbox/%3c56c255f88c54014e92512ed3e7848f9404b57...@mucxgc1.opentext.net%3e
Florian
-----Original Message-----
From: Gabriele Columbro [mailto:colum...@gmail.com]
Sent: Dienstag, 11. Mai 2010 10:17
To: chemistry-dev@incubator.apache.org
Subject: Re: OpenCMIS release proposal
Hey guys,
just a question out of the blue: is the usage of the maven-release-
plugin [1] been discussed at all?
Having a mvn project, I can hardly see the reason why we should use a
build.xml to do so.
Stiil, don't want to stop this release going, but I'm definitely
willing to help out and document the mvn release process for the next
release,
as using ant for this seems a bit of a stretch.
What do you guys think?
Ciao!
Gab
[1] http://maven.apache.org/plugins/maven-release-plugin/introduction.html
On May 10, 2010, at 4:34 PM, Florian Müller wrote:
Hi all,
Here is a proposal how an OpenCMIS release could look like: [1]
The script that generates these files is in the OpenCMIS SVN branch
in the release-tools directory. It does not create branches and tags
in SVN yet. It only produces the release packages.
The main release package is the source package ([2]/[3]). Only this
packages contains the documentation. All other packages are just
convenience packages with binaries.
I'm currently compiling a release documentation. A first draft is
already in the Wiki but I need a few more days to finish it.
WDYT?
Cheers,
Florian
[1] http://people.apache.org/~fmui/opencmis/
[2]
http://people.apache.org/~fmui/opencmis/chemistry-opencmis-0.1-incubating-RC0.1-source.zip
[3]
http://people.apache.org/~fmui/opencmis/chemistry-opencmis-0.1-incubating-RC0.1-source.tar.gz
--
Eng. Gabriele Columbro
Alfresco Software, Ltd.
M: +31 (0)627 565 103
P: +39 320 161 28 46
D: +44 (0)1628 876 654
Skype: gabrielecolumbro
Blog: http://www.mindthegab.com
--
Eng. Gabriele Columbro
Alfresco Software, Ltd.
M: +31 (0)627 565 103
P: +39 320 161 28 46
D: +44 (0)1628 876 654
Skype: gabrielecolumbro
Blog: http://www.mindthegab.com
Twitter: http://twitter.com/mindthegabz
