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
On 18 October 2011 21:44, Chris Wilper <[email protected]> wrote:
> Greg,
>
> There's been a long-standing desire (but not so much time) to start
> hosting all the org.fcrepo artifacts at Sonatype, and eventually sync
> to central[1]. One of the assumptions we've had (I've had) about
> Sonatype hosting is that they've become a lot more strict about
> non-central dependencies. So it's seemed like an arduous process to
> get all our dependencies in order beforehand, which is why it hasn't
> happened yet.
>
> If that's not the case, then personally, I'd be happy with you
> publishing your build of the 3.5 artifacts to central under the
> org.fcrepo groupId as long as they're digitally signed by you (which
> it looks like they are) and you didn't make any non-pom changes to the
> code before doing your build (I assume that's true?). Until we start
> doing it as part of the release process, it seems like that's going to
> make your life (and other developers' lives) easier.
>
> Btw, I noticed the sonatype-oss-parent change in the root pom. Were
> there other changes that allowed to you build and upload all the
> artifacts via mvn, or did you manually build and upload them? If the
> former, can you describe what you did? The sooner we can integrate
> automatic publishing of our artifacts to central with our release
> process, the better.
>
> Thanks,
> Chris
>
> [1] https://jira.duraspace.org/browse/FCREPO-825
>
> On Tue, Oct 18, 2011 at 12:20 AM, Greg Pendlebury
> <[email protected]> wrote:
> > For my testing today I released the artifacts to a Sonatype staging
> > repository:
> > https://oss.sonatype.org/content/repositories/orgfcrepo-409/org/fcrepo/
> >
> > So far things seem to be going ok for my testing, and I'm currently
> coding
> > against this. Are there any objections to be synching this with Central?
> The
> > alternative is I could release them under our own group ID, but I'd
> prefer
> > to use the correct 'org.fcrepo' GID unless there are objections.
> >
> > Ta,
> > Greg
> >
> > On 18 October 2011 08:48, Greg Pendlebury <[email protected]>
> wrote:
> >>
> >> Thanks for the reply Edwin,
> >>
> >> I was more thinking of the artifact from inside the codebase:
> >> <groupId>org.fcrepo</groupId>
> >> <artifactId>fcrepo-client</artifactId>
> >> <version>3.5</version>
> >>
> >> Or this one:
> >> <groupId>org.fcrepo</groupId>
> >> <artifactId>fcrepo-client-admin</artifactId>
> >> <version>3.5</version>
> >>
> >> Unfortunately I've never heard of the 'com.mediashelf' version, but I
> >> don't lurk in the Fedora community very often. How does it differ from
> the
> >> client in the 'core' code?
> >>
> >> Maven Central does not require all dependencies to also be hosted there
> >> (although it is their preference), as per
> >>
> https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide
> >>
> >> I'm of the opinion that is far better to start getting something into
> >> Maven Central and work on the dependencies later then to hold everything
> >> outside and make it hard to get to... but of course that is just my
> little
> >> old opinion.
> >>
> >> If this is the only hold up is there any objection to me pushing the
> v3.5
> >> artifacts into Central? The POMs look like they are well fleshed out and
> >> ready to go.
> >>
> >> Ta,
> >> Greg
> >>
> >> On 18 October 2011 02:38, Edwin Shin <[email protected]> wrote:
> >>>
> >>> Greg,
> >>>
> >>> Pardon my jet-lag, I had assumed you were talking about the
> fedora-client
> >>> library at https://github.com/mediashelf/fedora-client
> >>>
> >>> On 16 Oct 2011, at 8:55 PM, Greg Pendlebury wrote:
> >>>
> >>> > Hello again,
> >>> >
> >>> > I started looking at later versions today. I've currently got v3.3,
> >>> > v3.3.1, v3.4.2 and v3.5 all running happily on my laptop. Some
> testing
> >>> > various permutations of compatibility makes me tentatively confident
> I can
> >>> > get the functionality required just from using the latest v3.5
> client.
> >>> >
> >>> > I may be blind however, because I can't seem to find the Maven
> >>> > artifacts anywhere. From the project's root POM I expected they might
> be
> >>> > somewhere in the Duraspace repo:
> >>> > https://m2.duraspace.org/content/repositories/releases/org/fcrepo/
> >>> >
> >>> > But there are no fedora artifacts there that I can see. I also can't
> >>> > see any under Maven central ('fedora-common', 'fcrepo' isn't there at
> all):
> >>> > http://search.maven.org/#browse|-924277200
> >>> >
> >>> > There is a ticket for fedora to synch with central under
> 'org.fcrepo':
> >>> > https://issues.sonatype.org/browse/OSSRH-307 but no artifacts.. are
> they
> >>> > hosted anywhere?
> >>> >
> >>> > Ta,
> >>> > Greg
> >>> >
> >>> > On 14 July 2011 09:25, Greg Pendlebury <[email protected]>
> >>> > wrote:
> >>> > Hey All,
> >>> >
> >>> > I'm trying to get the Fedora Client available as a Maven dependency
> for
> >>> > our software to make use of in talking to Fedora repositories.
> >>> >
> >>> > The first version I was looking for was v2.2.4, which uses the old
> ant
> >>> > builds. I've built a bundle as per:
> >>> > http://code.google.com/p/redbox-mint/wiki/BuildingFedoraClient
> >>> >
> >>> > and it is available here:
> >>> >
> http://code.google.com/p/redbox-mint/downloads/detail?name=fcrepo-client-2.2.4-bundle.jar
> >>> >
> >>> > But wanted to check on a few thing:
> >>> > • I can't upload this to Sonatype since I'm not a member of
> your
> >>> > community (as per: https://issues.sonatype.org/browse/OSSRH-1942).
> >>> > • Does anyone object to me building in this way? Or the
> contents
> >>> > of the POM (such as your dev details, which I grabbed from the
> wiki/web
> >>> > where I could find them)?
> >>> > • Are the GAV details correct? I originally went for
> >>> > org.fedora-commons:fedora-client:2.2.4, but after looking at later
> versions
> >>> > (see below) I switched to org.fcrepo:fcrepo-client:2.2.4 - Is there
> any
> >>> > preference?
> >>> > • Can either A) someone with authority upload this bundle for
> me?
> >>> > or B) allow me access (presumably via Sonatype) to upload?
> >>> >
> >>> > Next I moved on to v3.3.1, which one of our clients has indicated
> they
> >>> > will soon be migrating to. I haven't started on this one yet, so some
> of
> >>> > these questions will just be me trying to sort out some confusion:
> >>> > • The src.zip link from here is broken:
> >>> > http://www.fedora-commons.org/software/repository/v_3_3_0 Although I
> did
> >>> > look around and find:
> >>> > http://sourceforge.net/projects/fedora-commons/files/fedora/3.3/
> >>> > • The location above had only a jar file listed for v3.3.1 and
> >>> > seemed to relate only to the server (I didn't try using it though). I
> assume
> >>> > this is not big deal and the client is compatible?
> >>> > • After grabbing the v3.3 source I was happy to note the Maven
> >>> > build and adjusted my 2.2.4 GAV to match, but the build process fails
> since
> >>> > it appears the fedora-commons.org maven repository is defunct.
> >>> > • I can't find any publicly available artifacts in either Maven
> >>> > Central or the Duraspace repo that match the GAV details from the
> v3.3 POMs,
> >>> > are these available somewhere?
> >>> > • Failing this I thought I could either go through the pain of
> >>> > building up all the v3.3 dependencies and releasing them (ouch), or
> move to
> >>> > the current versions and pray they are compatible for a v3.3.1
> server... any
> >>> > advice on the more likely route to success?
> >>> > Apologies for the wall of text in this post, but I'm mainly looking
> for
> >>> > information/authorization. I'm happy to do any/all dev work involved
> if it
> >>> > falls in line with community expectations.
> >>> >
> >>> > Ta,
> >>> > Greg
> >>> >
> >>> >
> >>> >
> ------------------------------------------------------------------------------
> >>> > 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
> >>>
> >>>
> >>>
> >>>
> ------------------------------------------------------------------------------
> >>> 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
> >>
> >
> >
> >
> ------------------------------------------------------------------------------
> > 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
> >
> >
>
>
> ------------------------------------------------------------------------------
> 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
>
------------------------------------------------------------------------------
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
