You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@turbine.apache.org by "Jeffrey D. Brekke" <jb...@brekke.org> on 2003/06/08 11:37:14 UTC
Re: Getting our jar dependencies there.
>>>>> On Sun, 8 Jun 2003 10:30:57 +0000 (UTC), "Henning P. Schmiedehausen" <hp...@intermeta.de> said:
[SNIPPED]
> "As maven already supports multiple remote repositories: Would it
> make sense that we set up a small, Turbine-related repository where
> we can put all the jars that are needed to build the HEAD ourselves
> and simply tell developers, that they must use
> maven.repo.remote =
> http://www.ibiblio.org/maven/,http://jakarta.apache.org/turbine/repo
> so that the HEAD can be built reliably without having to wait for
> the upload people to catch up?"
> "If it does not make sense, why not?"
Sounds reasonable. The only drawback I see is the possiblity of a
competing repo that will just confuse developers. "Now, I can't find
it on the ibiblio one, check the turbine one, the avalon one, the
jakarta one, etc."
Another idea: maybe we could get one or two more Turbine developers
with access for uploading jars to ibiblio? I have access, but have
been on vacation for a while now, just getting back into swing.
> This would mean that developers have to work on their
> build.properties for compiling Turbine (Unfortunately, while you can
> configure most anything in the POM, there is no way that I can see
> to tell maven in the POM to look into another remote repository. Too
> bad).
Doesn't it also work when put into the project.properties? I'd double
check, but HEAD isn't building for me right now.
--
=====================================================================
Jeffrey D. Brekke jbrekke@wi.rr.com
Wisconsin, USA brekke@apache.org
ekkerbj@yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Getting our jar dependencies there.
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
jbrekke@wi.rr.com (Jeffrey D. Brekke) writes:
>> jar-developer controlled distribution mechanism. This however is IMHO
>> much beyond the scale of the maven project. Maven would basically be
>> the user of such a distribution mechanism.
>Very good ideas. There was talk about separating the repository stuff
>out so other projects could use it, but it is currently cooking in
>maven-new I guess.
As I said, this is IMHO not really part of maven. Maven would be an
user of this. Same could be an ant task or a simple command line tool.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
Java, perl, Solaris, Linux, xSP Consulting, Web Services
freelance consultant -- Jakarta Turbine Development -- hero for hire
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Getting our jar dependencies there.
Posted by "Jeffrey D. Brekke" <jb...@wi.rr.com>.
"Henning P. Schmiedehausen" <hp...@intermeta.de> writes:
[SNIPPED]
> Was is needed is either some sort of "automated push" which might work
> for released jars but fails with arbitrary snapshot versions of
> non-released jars or an "automated pull" where a jar developer puts a
> new version into some designated area on his project web site and the
> ibiblio repository is configured to check it maybe once an hour and
> upload it.
>
> The central repository idea would have been good if it would have
> taken the "peer-to-peer" approach: Let ibiblio be a "reference server"
> only and let the various jar projects just register with it and keep
> their release versions local. Then if a developer wants to download a
> jar, maven asks ibiblio which in turn returns the canonical download
> location for a jar and/or project. This would make it possible for
> developers to keep their jars under control. Add some mirroring
> mechanism where ibiblio would pick up the jars and buffer them locally
> and a signature mechanism which ensures that no rogue versions can
> creep into the system and you get a scalable, self-healing,
> jar-developer controlled distribution mechanism. This however is IMHO
> much beyond the scale of the maven project. Maven would basically be
> the user of such a distribution mechanism.
Very good ideas. There was talk about separating the repository stuff
out so other projects could use it, but it is currently cooking in
maven-new I guess.
--
=====================================================================
Jeffrey D. Brekke jbrekke@wi.rr.com
Wisconsin, USA brekke@apache.org
ekkerbj@yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Getting our jar dependencies there.
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
jbrekke@brekke.org (Jeffrey D. Brekke) writes:
>Sounds reasonable. The only drawback I see is the possiblity of a
>competing repo that will just confuse developers. "Now, I can't find
>it on the ibiblio one, check the turbine one, the avalon one, the
>jakarta one, etc."
Quinton suggested putting this into the project properties, which does
sound reasonable. BTW: I don't understand the arbitrary split between
project.xml and project.properties. I would have added a <properties>
section to the POM and put all this stuff there. Well...
>Another idea: maybe we could get one or two more Turbine developers
>with access for uploading jars to ibiblio? I have access, but have
>been on vacation for a while now, just getting back into swing.
This simply shifts the problem. Now you don't have to reach a maven guy
but the 'right' Turbine guy. Consider this multiplied by 100 projects
and you'll see that this simply doesn't scale.
Was is needed is either some sort of "automated push" which might work
for released jars but fails with arbitrary snapshot versions of
non-released jars or an "automated pull" where a jar developer puts a
new version into some designated area on his project web site and the
ibiblio repository is configured to check it maybe once an hour and
upload it.
The central repository idea would have been good if it would have
taken the "peer-to-peer" approach: Let ibiblio be a "reference server"
only and let the various jar projects just register with it and keep
their release versions local. Then if a developer wants to download a
jar, maven asks ibiblio which in turn returns the canonical download
location for a jar and/or project. This would make it possible for
developers to keep their jars under control. Add some mirroring
mechanism where ibiblio would pick up the jars and buffer them locally
and a signature mechanism which ensures that no rogue versions can
creep into the system and you get a scalable, self-healing,
jar-developer controlled distribution mechanism. This however is IMHO
much beyond the scale of the maven project. Maven would basically be
the user of such a distribution mechanism.
Hm. Sounds like a thesis work to get programmed. Any takers?
Regards
Henning
>> This would mean that developers have to work on their
>> build.properties for compiling Turbine (Unfortunately, while you can
>> configure most anything in the POM, there is no way that I can see
>> to tell maven in the POM to look into another remote repository. Too
>> bad).
>Doesn't it also work when put into the project.properties? I'd double
>check, but HEAD isn't building for me right now.
>--
>=====================================================================
>Jeffrey D. Brekke jbrekke@wi.rr.com
>Wisconsin, USA brekke@apache.org
> ekkerbj@yahoo.com
>---------------------------------------------------------------------
>To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
Java, perl, Solaris, Linux, xSP Consulting, Web Services
freelance consultant -- Jakarta Turbine Development -- hero for hire
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Getting our jar dependencies there.
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
jbrekke@wi.rr.com (Jeffrey D. Brekke) writes:
>> Nah. You would just shift it. Consider a year ago. The most active
>> developers at that time were people like JvZ or Jon Stevens. Both have
>> left Turbine development completely. And it still won't help you if
>> these folks are on holidays or unavailable.
>>
>> It is a band aid, that would help a little, though, so I'm +0 on that.
>I guess I didn't see this as much different than a Turbine repo. Would
>you want to give everyone access to upload to the Turbine repo?
Every Turbine committer, yes. Basically, same access access as the web
pages on jakarta.apache.org (where it would be located) or the CVS,
working on the idea that changes in this repo will be driven by
reflected changes in the CVS (the project.xml file).
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
Java, perl, Solaris, Linux, xSP Consulting, Web Services
freelance consultant -- Jakarta Turbine Development -- hero for hire
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Getting our jar dependencies there.
Posted by "Jeffrey D. Brekke" <jb...@wi.rr.com>.
"Henning P. Schmiedehausen" <hp...@intermeta.de> writes:
> "Quinton McCombs" <qm...@nequalsone.com> writes:
>
>>+1
>
>>I like this idea much better. I think that if two of the active developers
>>could get access, this problem would go away completely.
>
> Nah. You would just shift it. Consider a year ago. The most active
> developers at that time were people like JvZ or Jon Stevens. Both have
> left Turbine development completely. And it still won't help you if
> these folks are on holidays or unavailable.
>
> It is a band aid, that would help a little, though, so I'm +0 on that.
I guess I didn't see this as much different than a Turbine repo. Would
you want to give everyone access to upload to the Turbine repo?
--
=====================================================================
Jeffrey D. Brekke jbrekke@wi.rr.com
Wisconsin, USA brekke@apache.org
ekkerbj@yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Getting our jar dependencies there.
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
"Quinton McCombs" <qm...@nequalsone.com> writes:
>+1
>I like this idea much better. I think that if two of the active developers
>could get access, this problem would go away completely.
Nah. You would just shift it. Consider a year ago. The most active
developers at that time were people like JvZ or Jon Stevens. Both have
left Turbine development completely. And it still won't help you if
these folks are on holidays or unavailable.
It is a band aid, that would help a little, though, so I'm +0 on that.
Regards
Henning
>> > This would mean that developers have to work on their
>> build.properties
>> > for compiling Turbine (Unfortunately, while you can configure most
>> > anything in the POM, there is no way that I can see to tell
>> maven in
>> > the POM to look into another remote repository. Too bad).
>>
>> Doesn't it also work when put into the project.properties?
>> I'd double check, but HEAD isn't building for me right now.
>Yes, project.properties works just fine.
>>
>> --
>> =====================================================================
>> Jeffrey D. Brekke jbrekke@wi.rr.com
>> Wisconsin, USA brekke@apache.org
>> ekkerbj@yahoo.com
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
>>
>>
>>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
Java, perl, Solaris, Linux, xSP Consulting, Web Services
freelance consultant -- Jakarta Turbine Development -- hero for hire
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
RE: Getting our jar dependencies there.
Posted by Quinton McCombs <qm...@nequalsone.com>.
> -----Original Message-----
> From: Jeffrey D. Brekke [mailto:jbrekke@brekke.org]
> Sent: Sunday, June 08, 2003 4:37 AM
> To: Turbine Developers List
> Cc: hps@intermeta.de
> Subject: Re: Getting our jar dependencies there.
>
>
> >>>>> On Sun, 8 Jun 2003 10:30:57 +0000 (UTC), "Henning P.
> >>>>> Schmiedehausen" <hp...@intermeta.de> said:
>
> [SNIPPED]
>
> > "As maven already supports multiple remote repositories:
> Would it make
> > sense that we set up a small, Turbine-related repository
> where we can
> > put all the jars that are needed to build the HEAD ourselves and
> > simply tell developers, that they must use
>
> > maven.repo.remote =
> > http://www.ibiblio.org/maven/,http://jakarta.apache.org/turbine/repo
>
> > so that the HEAD can be built reliably without having to
> wait for the
> > upload people to catch up?"
>
> > "If it does not make sense, why not?"
>
> Sounds reasonable. The only drawback I see is the possiblity
> of a competing repo that will just confuse developers. "Now,
> I can't find it on the ibiblio one, check the turbine one,
> the avalon one, the jakarta one, etc."
>
> Another idea: maybe we could get one or two more Turbine
> developers with access for uploading jars to ibiblio? I have
> access, but have been on vacation for a while now, just
> getting back into swing.
+1
I like this idea much better. I think that if two of the active developers
could get access, this problem would go away completely.
> > This would mean that developers have to work on their
> build.properties
> > for compiling Turbine (Unfortunately, while you can configure most
> > anything in the POM, there is no way that I can see to tell
> maven in
> > the POM to look into another remote repository. Too bad).
>
> Doesn't it also work when put into the project.properties?
> I'd double check, but HEAD isn't building for me right now.
Yes, project.properties works just fine.
>
> --
> =====================================================================
> Jeffrey D. Brekke jbrekke@wi.rr.com
> Wisconsin, USA brekke@apache.org
> ekkerbj@yahoo.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org