Hi Harald,
sounds reasonable to me. I'm +1 this way the prepare actually does
prepare what is being released :)
regards, Achim
2012/6/4 Harald Wellmann :
> With the current Pax Exam milestone release, I had an issue that could
> likely be addressed in the master POM:
>
> The release:perform goal
With the current Pax Exam milestone release, I had an issue that could
likely be addressed in the master POM:
The release:perform goal failed with the javadoc plugin complaining
about a missing javax.faces class (which I never use directly), so I had
to squash the staging repository, delete th
hi,
a) I'm fine with either, I guess the old ones have been good enough :)
b) I'm fine with this too
c) I'm not sure about this, I'd rather push the tag during the
release:prepare phase. One might still remove the tag
if it doesn't work out :)
besides c) which is basically just a personal favo
OK, I've updated and pushed everything according to your concerns.
Only things opened are:
a) using the (older) versions from the parent plugin instead of
possibly newer versions
b) the default version tag name
c) don't push by default (and therefore also required the -DconnectionUrl param)
Any o
Hey,
On Mon, May 28, 2012 at 6:53 PM, Harald Wellmann
wrote:
> some remarks and questions:
>
> - Deleting plugins.javadoc.version leaves a dangling reference in the
> reporting section.
This shouldn't happen since the version is from the sonatype parent
(but I'll check).
>
> - Deleting the java
Hi Andi,
some remarks and questions:
- Deleting plugins.javadoc.version leaves a dangling reference in the
reporting section.
- Deleting the javadoc plugin from the POM effectively downgrades
the plugin from 2.8 to 2.7 used in the OSS parent POM. Don't think we
want to go back, do we? The l
+1
regards, Achim
Am 28.05.2012 15:19, schrieb Andreas Pieber:
> If there are no further comments on my changes I'll merge them by
> tomorrow midday into the master and cut a 3.0.0 release of the ops4j
> master.
>
> Kind regards,
> Andreas
>
> On Thu, May 24, 2012 at 9:46 AM, Andreas Pieber wrot
If there are no further comments on my changes I'll merge them by
tomorrow midday into the master and cut a 3.0.0 release of the ops4j
master.
Kind regards,
Andreas
On Thu, May 24, 2012 at 9:46 AM, Andreas Pieber wrote:
> using org.ops4j.master 3.0.0 will fix this all; only thing required
> then
using org.ops4j.master 3.0.0 will fix this all; only thing required
then is the permission to push to oss.sonatype.org (org.ops4j).
Kind regards,
Andreas
On Thu, May 24, 2012 at 9:40 AM, Guillaume Nodet wrote:
> I'd like something which doesn't need permissions on ops4j because it
> always fail
I've pushed my ideas to [1].
Basically all you need to do for a snapshot release in your project is a
"mvn install deploy"
and to release your project is
"mvn release:prepare release:perform -DconnectionUrl=scm:git:file://$`pwd`"
Once the push to m2 had been successfully simply do a
"git push
I'd like something which doesn't need permissions on ops4j because it
always fail for me.
I kinda have to rely on an even more manual process using
https://gist.github.com/808620
Or maybe that problem can be fixed somehow but I don't know how.
On Tue, May 15, 2012 at 3:18 PM, Andreas Pieber wrote
Another addition here: After looking at it again I'm curious if we
really need to push our snapshots to
http://oss.sonatype.org/content/repositories/ops4j-snapshots/ instead
of https://oss.sonatype.org/content/repositories/snapshots/ where all
snapshots of all other sonatype using projects are loc
TBH I think this is nothing we could really fix in the root. This one
is rather a conceptional problem someone cooked up. We should rather
deploy EVERYTHING by default in the release profile. There could be
(optionally) additional profiles which e.g. skip the itests, but this
shouldn't be the defau
Typically remote tags are created automatically (or will once I'm
finished) doing mvn release:prepare release:perform (well, they'll be
pushed asap they're created locally). This behavior though has one big
disadvantage. Assume that you've missed anything in the release
process (e.g. your uploaded
One more thing:
We need to take care of extra stuff in special profiles.
E.g. Pax Exam has an itest profile for integration tests which should
not be pushed to Maven Central, But that means that the POM versions of
the itest projects don't get updated automatically by the Maven Release
plugin
+1
...but don't forget to update
http://team.ops4j.org/wiki/display/ops4j/Releasing :-)
Am 15.05.2012 15:18, schrieb Andreas Pieber:
mvn release:prepare release:perform (add this for local tags
-DconnectionUrl=scm:git:file://`pwd`)
Can you explain? I'd say you always want remote tags and
Same here: KISS!
+1
Good move, Andy!
On Tue, May 15, 2012 at 4:00 PM, Achim Nierbeck wrote:
> I'm in strong favor of KISS, therefore +1 :)
>
> 2012/5/15 Andreas Pieber :
> > Hey guys,
> >
> > Formerly, as we not relied on maven central, but rather on our own
> > repositories we had a lot of rel
I'm in strong favor of KISS, therefore +1 :)
2012/5/15 Andreas Pieber :
> Hey guys,
>
> Formerly, as we not relied on maven central, but rather on our own
> repositories we had a lot of release profiles. This is no longer
> required since everything goes to central now. I would like to change
> th
18 matches
Mail list logo
