On 17 Dec 06, at 1:58 PM 17 Dec 06, Fabrizio Giustina wrote:
On 12/17/06, Jason van Zyl <[EMAIL PROTECTED]> wrote:
Fabrizio,
When the release is ready to be made can I actually perform the
release?
Sure, no problem for me. Btw I already used the new remote-resources
and gpg stuff to deploy 4 releases in maven shared and everything
worked well. The only note is that I actually ran the gpg:sign goal
manually without including it into the pom, so that I was able to test
it before committing a modified (released) pom. I also manually
deleted the unnecessary sha and md5 for signatures.
IMHO it should be better to include everything we use for releases
(javadoc and sources generation, gpg signing) in the default build
process, using everything also for snapshots: it may look overkilling
to sign snapshots too but I think it's better to keep snapshot/release
deploys as aligned as possible...
Absolutely, that's the plan. It's all in a profile now for testing.
the deploy of snapshots also helps
in testing that everything is ok, and for new developers could be a
little bit scary to have something that you can properly only use for
releases.
What I plan on doing for voting is an actual release to a staging
repository. If it's crap then we do it again, and when it's good we
merge the stage with the real repository. I'm am trying this for the
first time with a Geronimo release and I will do it with the maven-
eclipse-plugin as well.
Another note about the eclipse plugin: at the moment the plugin
installs a test version to the local repository during tests and I saw
such version also deployed to the remote snapshot repo once. Please
check that this doesn't happen when doing a release, I was planning to
do a release:prepare and then deploy the release building it from the
tag with tests disabled to be sure that it doesn't happen in the worst
moment...
That's not good, that shouldn't be in tests. What is doing that
because that's really bad.
No real repository whether local or remote can be tampered with for
testing that is just an extremely bad practice.
Jason.
fabrizio
I would like to keep testing the new tools and move toward
having the release be made by one machine. The more releases I can do
to test this the better. I will document everything (Joakim and I
have started) and then it should be no problem for anyone to do it
for future releases.
jason.
On 16 Dec 06, at 2:59 PM 16 Dec 06, Fabrizio Giustina wrote:
> Dependencies used by the maven-eclipse-plugin have been released
and a
> stable revision for a vote has been set.
>
> I'd like to restart a vote based on:
> - svn rev. 487861
> - snapshot deployed at
> http://people.apache.org/repo/m2-snapshot-repository/org/apache/
> maven/plugins/maven-eclipse-plugin/2.3-SNAPSHOT/maven-eclipse-
> plugin-2.3-20061216.195001-12.jar
> - documentation already updated at
> http://maven.apache.org/plugins/maven-eclipse-plugin/
> - changelog available at
> http://jira.codehaus.org/browse/MECLIPSE?
> report=com.atlassian.jira.plugin.system.project:roadmap-panel
>
> this release contains several bugfixes and new features, especially
> related to eclipse plugin development. Lots of issues/enhancement
> requests are still open, but users need a release before going on.
>
>
> Vote is open for 72h
>
> My +1,
> Fabrizio
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
