Does anyone happen to know if there is a way to override the
<repository> part of the <distributionManagement> section of the
pom.xml? If we were able to do that, we could keep the individual jar
artifacts deployed to the http://people.apache.org/repo/m2-snapshot-
repository/org/apache/openjpa/ (so people can reference the
individual artifacts as usual), but upload the artifacts from the
openjpa-project sub-pom to a separate location?
On Apr 25, 2007, at 10:29 AM, Craig L Russell wrote:
> +1 to all that.
>
> What JDO does is publish the non-maven artifacts to the dist/db
> directory (JDO is a db sub-project) and there is a script that
> allows us to use the mirrors to let folks get the binary or source
> download. And we publish the maven artifacts so that a user can
> just write a pom and five lines of code later maven will download
> the dependency tree. Sweet.
>
> Craig
>
> On Apr 25, 2007, at 7:07 AM, Eddie O'Neil wrote:
>
>> While in incubation, the best place for non-Maven downloads is here:
>>
>> http://people.apache.org/dist/incubator/
>>
>> Once out of incubation, the right place is here:
>>
>> http://www.apache.org/dist/
>>
>> which ties an artifact into the mirroring system. Then, there's a
>> particular way to format the project's download page in order to list
>> all of the mirrors as download options for that artifact a la:
>>
>> http://struts.apache.org/download.cgi
>>
>> Eddie
>>
>>
>> On 4/25/07, Michael Dick <[EMAIL PROTECTED]> wrote:
>>> On 4/24/07, Phill Moran <[EMAIL PROTECTED]> wrote:
>>> >
>>> > I don't think you want the tarball in maven. Personally I would
>>> not look
>>> > for it
>>> > there or go searching my local repo to open and get examples,
>>> docs etc.
>>> > Can we
>>> > keep the tarball on OpenJPA and the minimal compile an
>>> execution jar on
>>> > Maven.
>>> > Keep in mind that this jar is replicated on maven, corp repo
>>> then local
>>> > repo - a
>>> > lot of wasted space if not absolutely necessary.
>>> >
>>> > Phill
>>>
>>>
>>> I agree, if we put the tarball in a different location then we
>>> should remove
>>> it from the maven repository at the same time. It shouldn't be
>>> too tricky to
>>> separate the tarball generation from the normal build processing
>>> (in which
>>> case maven won't deploy the tarball).
>>>
>>> Assuming this is the right way to go, where would be put the
>>> tarball?
>>>
>>> -----Original Message-----
>>> > From: Patrick Linskey [mailto:[EMAIL PROTECTED]
>>> > Sent: April 24, 2007 10:49 PM
>>> > To: open-jpa-dev@incubator.apache.org
>>> > Subject: RE: Artifact names
>>> >
>>> > > Personally, I think both are valuable as they serve
>>> different needs
>>> > > for different development environments.
>>> >
>>> > I agree completely. Just wondering if we should be publishing
>>> the tarball
>>> > via
>>> > mvn.
>>> >
>>> -Patrick
>>> >
>>> > --
>>> > Patrick Linskey
>>> > BEA Systems, Inc.
>>> >
>>> ____________________________________________________________________
>>> ___
>>> > Notice: This email message, together with any attachments, may
>>> contain
>>> > information of BEA Systems, Inc., its subsidiaries and
>>> affiliated
>>> > entities, that may be confidential, proprietary,
>>> copyrighted and/or
>>> > legally
>>> > privileged, and is intended solely for the use of the
>>> individual or entity
>>> > named
>>> > in this message. If you are not the intended recipient, and
>>> have received
>>> > this
>>> > message in error, please immediately return this by email and
>>> then delete
>>> > it.
>>> >
>>> > > -----Original Message-----
>>> > > From: Eddie O'Neil [mailto:[EMAIL PROTECTED]
>>> > > Sent: Tuesday, April 24, 2007 7:41 PM
>>> > > To: open-jpa-dev@incubator.apache.org
>>> > > Subject: Re: Artifact names
>>> > >
>>> > >
>>> > > It's a fair question -- if you want people to be able to sync
>>> > > dependencies from Maven directly into their projects via pom.xml
>>> > > references, then the Maven repository is the way to go.
>>> > >
>>> > > If you want to distribute a single package that contains
>>> everything
>>> > > (binaries, docs, samples, etc) needed to get started with
>>> OpenJPA and
>>> > > doesn't require the user to use the Maven project model, then
>>> the
>>> > > source / binary zip archives are the way to go.
>>> > >
>>> > > Personally, I think both are valuable as they serve
>>> different needs
>>> > > for different development environments.
>>> > >
>>> > > Eddie
>>> > >
>>> > >
>>> > > On 4/24/07, Marc Prud'hommeaux <[EMAIL PROTECTED]> wrote:
>>> > > >
>>> > > > On Apr 24, 2007, at 7:27 PM, Patrick Linskey wrote:
>>> > > >
>>> > > > > Hmm. I wonder if we're really using Maven repositories
>>> correctly.
>>> > > > > Do we
>>> > > > > need our dist to be in Maven at all?
>>> > > >
>>> > > > We don't need to. It was just easy to set up that way.
>>> > > >
>>> > > >
>>> > > > > I do think that we should have something that's easy to
>>> depend on
>>> > > > > that pulls in the openjpa-persistence-jdbc module,
>>> without making
>>> > > > > people have to know about that level of modularity detail.
>>> > > >
>>> > > > Why can't they just depend on openjpa-all? That brings
>>> > > everything in...
>>> > > >
>>> > > >
>>> > > >
>>> > > > > -Patrick
>>> > > > >
>>> > > > > --
>>> > > > > Patrick Linskey
>>> > > > > BEA Systems, Inc.
>>> > > > >
>>> > >
>>> ____________________________________________________________________
>>> > > > > __
>>> > > > > _
>>> > > > > Notice: This email message, together with any
>>> attachments, may
>>> > > > > contain information of BEA Systems, Inc., its
>>> > > subsidiaries and
>>> > > > > affiliated entities, that may be confidential,
>>> proprietary,
>>> > > > > copyrighted and/or legally privileged, and is intended
>>> solely for
>>> > > > > the use of the individual or entity named in this
>>> message. If you
>>> > > > > are not the intended recipient, and have received this
>>> message in
>>> > > > > error, please immediately return this by email and then
>>> delete it.
>>> > > > >
>>> > > > >> -----Original Message-----
>>> > > > >> From: Eddie O'Neil [mailto:[EMAIL PROTECTED]
>>> > > > >> Sent: Tuesday, April 24, 2007 7:05 PM
>>> > > > >> To: open-jpa-dev@incubator.apache.org
>>> > > > >> Subject: Re: Artifact names
>>> > > > >>
>>> > > > >>
>>> > > > >> +1 -- I'd prefer to have the binary / source uber-
>>> archives
>>> > > > >> outside of the Maven repro, though that's more due to
>>> convention
>>> > > > >> than anything else.
>>> > > > >>
>>> > > > >> I agree that it's not worth worrying about this for
>>> 0.9.7.
>>> > > > >>
>>> > > > >> Cheers,
>>> > > > >> Eddie
>>> > > > >>
>>> > > > >>
>>> > > > >> On 4/24/07, Michael Dick <[EMAIL PROTECTED]> wrote:
>>> > > > >>> I'm finally getting back to this thread, sorry for the
>>> delay.
>>> > > > >>>
>>> > > > >>> I got a similar answer from the maven mailing list.
>>> > > Their stance
>>> > > > >>> is that the maven repository is for artifacts which are
>>> used by
>>> > > > >>> maven, which wouldn't be the same as a final
>>> destination for our
>>> > > > >> distribution.
>>> > > > >>>
>>> > > > >>> I'm in favor of moving the source and binary archives to a
>>> > > > >> different
>>> > > > >>> location, if there's a good spot available to us. Does
>>> > > > >> anyone object
>>> > > > >>> to putting the releases somewhere outside of a maven
>>> repository?
>>> > > > >>>
>>> > > > >>> I don't think this is urgent for the 0.9.7 release
>>> since we
>>> > > > >> can't get
>>> > > > >>> rid of the ugly -project names now, but it might be
>>> > > nice to have a
>>> > > > >>> solution for when OpenJPA graduates.
>>> > > > >>>
>>> > > > >>> On 4/12/07, Dain Sundstrom <[EMAIL PROTECTED]> wrote:
>>> > > > >>>>
>>> > > > >>>> In Geronimo, we publish to the maven repo as maven likes,
>>> > > > >> but when
>>> > > > >>>> we publish to the apache distribution mirrors (for
>>> website
>>> > > > >>>> downloads), we name the files as we like.
>>> > > > >>>>
>>> > > > >>>> -dain
>>> > > > >>>>
>>> > > > >>>> On Apr 11, 2007, at 8:34 AM, Michael Dick wrote:
>>> > > > >>>>
>>> > > > >>>>> Hi,
>>> > > > >>>>>
>>> > > > >>>>> I'm hitting a bit of a snag with the staging
>>> repository for
>>> > > > >>>>> release 0.9.7.
>>> > > > >>>>> Recently we made changes to remove -project from our
>>> > > > >> the zip file
>>> > > > >>>>> names. The problem is that the maven install and
>>> deploy goals
>>> > > > >>>>> ignore the names we provide and generate their own
>>> names (
>>> > > > >>>>> openjpa-project-0.9.7-incubating-xxx.zip).
>>> > > > >>>>>
>>> > > > >>>>> I searched through the [EMAIL PROTECTED] mailing
>>> list
>>> > > > >>>>> archives and it turns out this is a fairly common
>>> problem -
>>> > > > >>>>> usually resulting in a response of "working as
>>> > > > >> designed". Here's
>>> > > > >>>>> an example
>>> > > > >>>>> http://www.nabble.com/Installation-and-deployment-
>>> > > > >>>>> tf1449780s177.html#a3916784
>>> > > > >>>>>
>>> > > > >>>>> Does anyone vehemently object to putting -project
>>> > > back into the
>>> > > > >>>>> names for the 0.9.7 release?
>>> > > > >>>>>
>>> > > > >>>>> The only other way I know of to fix the names that
>>> > > get deployed
>>> > > > >>>>> would be to change the artifactId in the pom files
>>> (basically
>>> > > > >>>>> switch openjpa with openjpa-project). Switching the
>>> > > names will
>>> > > > >>>>> impact anyone who has a dependency on the base
>>> > > openjpa project.
>>> > > > >>>>> They'll have to update the version number anyway, but
>>> it will
>>> > > > >>>>> still be a little confusing if they used to depend on
>>> > > > >>>>> openjpa-0.9.6 and now they depend on openjpa-
>>> project-0.9.7.
>>> > > > >>>>>
>>> > > > >>>>> Thanks,
>>> > > > >>>>>
>>> > > > >>>>> --
>>> > > > >>>>> -Michael Dick
>>> > > > >>>>
>>> > > > >>>>
>>> > > > >>>
>>> > > > >>>
>>> > > > >>> --
>>> > > > >>> -Michael Dick
>>> > > > >>>
>>> > > > >>
>>> > > > >
>>> > > > > Notice: This email message, together with any
>>> attachments, may
>>> > > > > contain information of BEA Systems, Inc., its
>>> > > subsidiaries and
>>> > > > > affiliated entities, that may be confidential,
>>> proprietary,
>>> > > > > copyrighted and/or legally privileged, and is intended
>>> > > solely for
>>> > > > > the use of the individual or entity named in this
>>> message. If you
>>> > > > > are not the intended recipient, and have received this
>>> message in
>>> > > > > error, please immediately return this by email and then
>>> delete it.
>>> > > >
>>> > > >
>>> > >
>>> >
>>> > Notice: This email message, together with any attachments, may
>>> contain
>>> > information of BEA Systems, Inc., its subsidiaries and
>>> affiliated
>>> > entities, that may be confidential, proprietary,
>>> copyrighted and/or
>>> > legally
>>> > privileged, and is intended solely for the use of the
>>> individual or entity
>>> > named
>>> > in this message. If you are not the intended recipient, and
>>> have received
>>> > this
>>> > message in error, please immediately return this by email and
>>> then delete
>>> > it.
>>> >
>>> >
>>>
>>>
>>> --
>>> -Michael Dick
>>>
>
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:[EMAIL PROTECTED]
> P.S. A good JDO? O, Gasp!
>
