No worries; happy to help with the little changes.
Ta,
Greg
==========
"Sent from Ye Olde mobile device. Forgive my fat fingers and their typos."
p: +61 7 3295 1187, m: 0403 674 810, e: [email protected]
On Oct 20, 2011 10:32 PM, "Chris Wilper" <[email protected]> wrote:
> 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
>
>
------------------------------------------------------------------------------
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
