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
> >
> > 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_0Although 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
> >
> >
>
>
> ------------------------------------------------------------------------------
> 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
