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
