Ok, it looks like the sync of 3.5 artifacts to central was a success.
Accordingly, I've merged and pushed the pom changes to master and updated
the release process doc so we'll start doing this regularly now.
Thanks again for hacking down the weeds on this, Greg.
- Chris
On Wed, Oct 19, 2011 at 5:58 AM, Mark Diggory <[email protected]> wrote:
> This is great to see happening :-)
>
> Mark
>
>
> On Wednesday, October 19, 2011, Greg Pendlebury <[email protected]>
> wrote:
> > Cool, I shall try a full release later today then.
> >
> > Ta,
> > Greg
> >
> > On 19 October 2011 13:55, Chris Wilper <[email protected]> wrote:
> >
> > Thanks for the details. I've re-organized the issue I pointed to
> > earlier into some manageable sub-tasks, at least one of which I think
> > we can get done for 3.6 -- starting to deploy all artifacts to central
> > via sonatype as part of the release process:
> >
> > https://jira.duraspace.org/browse/FCREPO-1014
> >
> > I also folded your pom changes into my working copy to test what you
> > did, and was able to successfully deploy 3.6-SNAPSHOT to sonatype.
> >
> > I'm generally happy with the approach you've used, and I fully support
> > your pushing your 3.5 artifacts to central under the org.fcrepo
> > artifactid. Once you've done that and requested the central sync for
> > org.fcrepo, we can start doing it as a matter of course.
> >
> > - Chris
> >
> > On Tue, Oct 18, 2011 at 6:16 PM, Greg Pendlebury
> > <[email protected]> wrote:
> >> Thanks Chris,
> >>
> >> Yes they were just POM changes. Just the new parent as you noted:
> >> <parent>
> >> <groupId>org.sonatype.oss</groupId>
> >> <artifactId>oss-parent</artifactId>
> >> <version>7</version>
> >> </parent>
> >>
> >> And a new build profile (copied and modified from the existing one) to
> >> isolate the changes to one location and prevent them from triggering
> under
> >> the wrong circumstances... not that that would be a problem, it's just
> >> source JARs and javadoc JARs being built. The delay involved in building
> >> them was why I isolated them:
> >> <profile>
> >> <id>sonatype-release</id>
> >> <build>
> >> <plugins>
> >> <!-- sign each artifact with a pgp key -->
> >> <plugin>
> >> <groupId>org.apache.maven.plugins</groupId>
> >> <artifactId>maven-gpg-plugin</artifactId>
> >> <executions>
> >> <execution>
> >> <id>sign-artifacts</id>
> >> <phase>verify</phase>
> >> <goals>
> >> <goal>sign</goal>
> >> </goals>
> >> </execution>
> >> </executions>
> >> </plugin>
> >>
> >> <!-- Generate javadoc JARs -->
> >> <plugin>
> >> <groupId>org.apache.maven.plugins</groupId>
> >> <artifactId>maven-javadoc-plugin</artifactId>
> >> <version>2.6.1</version>
> >> <executions>
> >> <execution>
> >> <id>attach-javadocs</id>
> >> <goals>
> >> <goal>jar</goal>
> >> </goals>
> >> </execution>
> >> </executions>
> >> </plugin>
> >>
> >> <!-- Generate source JARs -->
> >> <plugin>
> >> <groupId>org.apache.maven.plugins</groupId>
> >> <artifactId>maven-source-plugin</artifactId>
> >> <executions>
> >> <execution>
> >> <id>attach-sources</id>
> >> <goals>
> >> <goal>jar</goal>
> >> </goals>
> >> </execution>
> >> </executions>
> >> </plugin>
> >>
> >> </plugins>
> >> </build>
> >> </profile>
> >>
> >> Then run:
> >> mvn clean
> >> mvn -P sonatype-release deploy
> >>
> >> This leaves them (after closing the repo) sitting in the staging
> repository
> >> already linked, and I can build using them from there until they finish
> >> public inspection and get properly released to Central.
> >>
> >> So if you're generally happy with this I will release them then. I have
> no
> >> urgency as long as I can develop against the staging repo, so I'm happy
> to
> >> wait a couple of days if anyone wants to check them.
> >>
> >> Ta,
> >> Greg
> >
>
> --
> [image: @mire Inc.]
> *Mark Diggory*
> *2888 Loker Avenue East, Suite 305, Carlsbad, CA. 92010*
> *Esperantolaan 4, Heverlee 3001, Belgium*
> http://www.atmire.com
>
>
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2d-oct
> _______________________________________________
> Fedora-commons-developers mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
>
>
------------------------------------------------------------------------------
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Ciosco Self-Assessment and learn
about Cisco certifications, training, and career opportunities.
http://p.sf.net/sfu/cisco-dev2dev
_______________________________________________
Fedora-commons-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
