openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Prud'hommeaux <mprud...@apache.org>
Subject Re: Artifact names
Date Wed, 25 Apr 2007 18:25:14 GMT

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 <michael.d.dick@gmail.com> wrote:
>>> On 4/24/07, Phill Moran <pjmoran@rogers.com> 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:plinskey@bea.com]
>>> > 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:ekoneil@gmail.com]
>>> > > 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 <mprudhom@apache.org> 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:ekoneil@gmail.com]
>>> > > > >> 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 <michael.d.dick@gmail.com>
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 <dain@iq80.com>
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 users@maven.apache.org
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:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>


Mime
View raw message