You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@gump.apache.org by "Mark R. Diggory" <md...@latte.harvard.edu> on 2004/05/14 14:48:01 UTC
Re: [collections] new snapshot to ibiblio
At this point I'm not sure what is correct. I only know that the efforts
up to this point are to enable gump to use maven to accomplish a nightly
build of a mavenized project, in which case you have an opportunity to
control some of the dependencies when your project is integrated via the
same mechanisms Maven is providing to you on the command line.
I'm not 100% sure of this so I'm cross posting to the gump list to see
if they agree with me on this subject. They may disagree entirely, in
which case I am in error.
Also, I'm not sure why you would want to fix your dependency to a
specific snapshot release date when you the latest snapshot may be
available to you via Gump/Maven. If you needed to rely on a specific
version of a dependency, it would in my opinion, be a major release of
that jar and not a dated snapshot.
What I am saying is that you either base your development on the
bleeding edge (SNAPSHOT) or a stable release (x.x), not on a possibly
outdated and unstable dated or nightly build. This is what we are trying
to break away from by getting the nightlies off of ibiblio and into a
separate Repository.
-Mark
Mario Ivankovits wrote:
> Mark R. Diggory wrote:
>
>> Ideally, the gump nightly build would also be of the dependency in the
>> Apache case. If this was impossible, you could place the jar somewhere
>> local for the gump build and point the project.properties to it using
>> the jar override mechanism in Maven.
>>
>> http://maven.apache.org/reference/user-guide.html#Overriding_Stated_Dependencies
>>
>
>
> I thought i have understood GUMP - it seems not.
>
> My impression was, GUMP always use the cvs-head to build the
> dependencies - and fixing the dependency to a given release is not the
> intention of GUMP.
>
> The best i can do is to build a snapshot of the required dependency and
> put it to the apache repository and let GUMP automatically use the
> nightlies.
>
> Isnt it correct that way?
>
> -- Mario
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: Gump Repository (was [collections] new snapshot to ibiblio)
Posted by Stephen McConnell <mc...@apache.org>.
Adam R. B. Jack wrote:
> "Stephen McConnell" <mc...@apache.org> wrote:
>
>
>>>http://brutus.apache.org/gump/public/repolist.txt
>>>
>>>Right now (without metadata changes for Gump, but I know they are going
>
> to
>
>>>be needed) we have projectName (not moduleName) = groupId, jar ID =
>>>artefactId. This works ok for many, I believe.
>>
>>Of the 97 Avalon related projects i9n Gump almost all produce artifacts
>>where the current projectName != groupId. The jar ID and artifactId are
>>however largely consistent.
>
>
> Thanks for the review, I kinda expected to have to add a groupId to the
> metadata, probably at the module level (that can be overridden at the
> project level, if needed). I haven't thought about it enough to propose
> anything yet though (and was kinda hoping to combine it with <jar repository
> information, for the product, to kill a few birds at once. I've done some
> work to match a jar repository like a CVS or SVN one.)
>
> BTW: Would moduleName have been a better match for groupId than projectName?
> I could default the above to one of these two.
Within the avalon projects we generally have:
gump-project-name == maven-artifact-id
But its not 100% consistent. Modules could be repackaged to match
maven-group-id, but keep in mind that this would result in a large
number of groups - for example, this would generate separate groups for
avalon-framework, avalon-logging, avalon-repository, avalon-meta,
avalon-util, merlin, etc., etc.
But yes - module name is probably a better bet.
The ability to declare the module under a gump project definition would
be easy to incorporate. Some work would still be needed to breakout
gump projects with multiple artifacts into one gump project per artifact
and an aggregating project where necessary (e.g. avalon-framework should
be separated into avalon-framework-api, avalon-framework-impl and
avalon-framework recast as an aggregation of the two).
Cheers, Stephen.
--
|---------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org |
|---------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: Gump Repository (was [collections] new snapshot to ibiblio)
Posted by "Adam R. B. Jack" <aj...@trysybase.com>.
"Stephen McConnell" <mc...@apache.org> wrote:
> > http://brutus.apache.org/gump/public/repolist.txt
> >
> > Right now (without metadata changes for Gump, but I know they are going
to
> > be needed) we have projectName (not moduleName) = groupId, jar ID =
> > artefactId. This works ok for many, I believe.
>
> Of the 97 Avalon related projects i9n Gump almost all produce artifacts
> where the current projectName != groupId. The jar ID and artifactId are
> however largely consistent.
Thanks for the review, I kinda expected to have to add a groupId to the
metadata, probably at the module level (that can be overridden at the
project level, if needed). I haven't thought about it enough to propose
anything yet though (and was kinda hoping to combine it with <jar repository
information, for the product, to kill a few birds at once. I've done some
work to match a jar repository like a CVS or SVN one.)
BTW: Would moduleName have been a better match for groupId than projectName?
I could default the above to one of these two.
regards
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: Gump Repository (was [collections] new snapshot to ibiblio)
Posted by Stephen McConnell <mc...@apache.org>.
Adam R. B. Jack wrote:
>>Definity seeing the contents of this would help me make more informed
>>recommendations concerning the repository structure. I can live without
>>the MD5's at the moment
>
>
> Actually, I find it was configured to be not public (i.e. not under the HTTP
> path).
>
> I've done a find -print to here:
>
> http://brutus.apache.org/gump/public/repolist.txt
>
> Right now (without metadata changes for Gump, but I know they are going to
> be needed) we have projectName (not moduleName) = groupId, jar ID =
> artefactId. This works ok for many, I believe.
Of the 97 Avalon related projects i9n Gump almost all produce artifacts
where the current projectName != groupId. The jar ID and artifactId are
however largely consistent.
Cheers, Steve.
--
|---------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org |
|---------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Gump Repository (was [collections] new snapshot to ibiblio)
Posted by "Adam R. B. Jack" <aj...@trysybase.com>.
> Definity seeing the contents of this would help me make more informed
> recommendations concerning the repository structure. I can live without
> the MD5's at the moment
Actually, I find it was configured to be not public (i.e. not under the HTTP
path).
I've done a find -print to here:
http://brutus.apache.org/gump/public/repolist.txt
Right now (without metadata changes for Gump, but I know they are going to
be needed) we have projectName (not moduleName) = groupId, jar ID =
artefactId. This works ok for many, I believe.
FWIIW: This is modelled more after Maven-style than ASF style right now.
Also, we are (here) respecting <redistributable (so things are not present).
http://gump.apache.org/metadata/project.html#redistributable
My intention/hope is to use a tool (e.g. Depot) to publish these to an
ASF-style repository, with MD5s, and have a complete list (even if somehow
private/locked-down from redistribution).
regards,
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: [collections] new snapshot to ibiblio
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
Adam,
Definity seeing the contents of this would help me make more informed
recommendations concerning the repository structure. I can live without
the MD5's at the moment
Adam R. B. Jack wrote:
>>Actually we don't differ at all. Once we have support for "last good
>>builds" or something similar in Gump, they can certainly live in a
>>ASF-format repository. And if pushing the created jars into
>>repository structure helps with anything we do, then go for it.
>>
>>
>
>Actually, it does it today although somehow I dorked it up with directory
>synchronization for Forrest pages. The jars are written to a repository (not
>guaranteed ASF-format yet, and with no .MD5s yet) but then the run 'tidies'
>that up (deleting it). I'll fix that, and made the repository available for
>review.
>
>
>
>>My "Gump doesn't use any repository" means "right now".
>>
>>
>
>Ah, ok, understood. Thanks.
>
>regards
>
>Adam
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>
Re: [collections] new snapshot to ibiblio
Posted by "Adam R. B. Jack" <aj...@trysybase.com>.
> Actually we don't differ at all. Once we have support for "last good
> builds" or something similar in Gump, they can certainly live in a
> ASF-format repository. And if pushing the created jars into
> repository structure helps with anything we do, then go for it.
Actually, it does it today although somehow I dorked it up with directory
synchronization for Forrest pages. The jars are written to a repository (not
guaranteed ASF-format yet, and with no .MD5s yet) but then the run 'tidies'
that up (deleting it). I'll fix that, and made the repository available for
review.
> My "Gump doesn't use any repository" means "right now".
Ah, ok, understood. Thanks.
regards
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [collections] new snapshot to ibiblio
Posted by Stefan Bodewig <bo...@apache.org>.
On Fri, 14 May 2004, Adam R. B. Jack <aj...@trysybase.com> wrote:
> I differ slightly from Stefan here, although I think we agree in
> principle.
Actually we don't differ at all. Once we have support for "last good
builds" or something similar in Gump, they can certainly live in a
ASF-format repository. And if pushing the created jars into
repository structure helps with anything we do, then go for it.
My "Gump doesn't use any repository" means "right now".
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [collections] new snapshot to ibiblio
Posted by "Adam R. B. Jack" <aj...@trysybase.com>.
> At this point I'm not sure what is correct. I only know that the efforts
> up to this point are to enable gump to use maven to accomplish a nightly
> build of a mavenized project, in which case you have an opportunity to
> control some of the dependencies when your project is integrated via the
> same mechanisms Maven is providing to you on the command line.
Gump currently invokes Maven providing it with jar overrides from Gump
produced jars (it also sets it 'offiline', to ensure control). So, for me,
the question becomes -- what jars does Gump use (see below).
> Also, I'm not sure why you would want to fix your dependency to a
> specific snapshot release date when you the latest snapshot may be
> available to you via Gump/Maven. If you needed to rely on a specific
> version of a dependency, it would in my opinion, be a major release of
> that jar and not a dated snapshot.
We've been discussing cases where we try to pick 'the very latest that
works', in cases where CVS HEAD doesn't work. (Trying to get 600 or so
projects all to work correctly at one point (allowing for real world API
shifts, aka progess/clean-up) is like star alignment ... not seen in many
folks lifetimes. ;-) As such, I could (personally) see a dated snapshot
available to be used.
> What I am saying is that you either base your development on the
> bleeding edge (SNAPSHOT) or a stable release (x.x), not on a possibly
> outdated and unstable dated or nightly build. This is what we are trying
> to break away from by getting the nightlies off of ibiblio and into a
> separate Repository.
I differ slightly from Stefan here, although I think we agree in principle.
I think that Gump ought maintain an ASF-format repository (probably closed
only to Gump, or those who know it is Gumped) so that it can go and gather
'the very latest that works'. I could see that we could try to automate
this, and/or we could cooperate with humans (via metadata) to give a hint.
regards,
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [collections] new snapshot to ibiblio
Posted by "Adam R. B. Jack" <aj...@trysybase.com>.
> At this point I'm not sure what is correct. I only know that the efforts
> up to this point are to enable gump to use maven to accomplish a nightly
> build of a mavenized project, in which case you have an opportunity to
> control some of the dependencies when your project is integrated via the
> same mechanisms Maven is providing to you on the command line.
Gump currently invokes Maven providing it with jar overrides from Gump
produced jars (it also sets it 'offiline', to ensure control). So, for me,
the question becomes -- what jars does Gump use (see below).
> Also, I'm not sure why you would want to fix your dependency to a
> specific snapshot release date when you the latest snapshot may be
> available to you via Gump/Maven. If you needed to rely on a specific
> version of a dependency, it would in my opinion, be a major release of
> that jar and not a dated snapshot.
We've been discussing cases where we try to pick 'the very latest that
works', in cases where CVS HEAD doesn't work. (Trying to get 600 or so
projects all to work correctly at one point (allowing for real world API
shifts, aka progess/clean-up) is like star alignment ... not seen in many
folks lifetimes. ;-) As such, I could (personally) see a dated snapshot
available to be used.
> What I am saying is that you either base your development on the
> bleeding edge (SNAPSHOT) or a stable release (x.x), not on a possibly
> outdated and unstable dated or nightly build. This is what we are trying
> to break away from by getting the nightlies off of ibiblio and into a
> separate Repository.
I differ slightly from Stefan here, although I think we agree in principle.
I think that Gump ought maintain an ASF-format repository (probably closed
only to Gump, or those who know it is Gumped) so that it can go and gather
'the very latest that works'. I could see that we could try to automate
this, and/or we could cooperate with humans (via metadata) to give a hint.
regards,
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org