Yes, it helps, as does Daniel Kulp's message. You don't need to proxy your
inhouse repo, but you can just to simplify things.
My issue is that I'm at a university, where I don't have a developer
intranet for my team, so my inhouse repo is accessed via sshext for access
control reasons.
If my VPN were smarter I could use Apache's access control mechanisms to
restrict access to the team, but it's pretty limited.
If access control were easier to delegate I maybe could use Shibboleth or
something. (I manage Shibboleth for our campus.)
-K
On 5/25/06 5:11 PM, "ben short" <[EMAIL PROTECTED]> wrote:
> Well you wouldnt.
>
> The proxy is used to cache ( and persist ) the dependancies that are
> hosted on the remote maven repos, like codehaus and ibilo. The means
> that your developers have access to the dependacies at a high speed,
> after they have been downloaded by the proxy.
>
> Now an inhouse repositry would be seperate. In this you would store
> all the jar that you produce and want to share between your
> development team.
>
> Does that help?
>
> Ben
>
> On 5/25/06, Kathryn Huxtable <[EMAIL PROTECTED]> wrote:
>> Of course, one answer leads to another question... ;-)
>>
>> Why bother proxying inhouse repositories? I don't see the logic there.
>>
>> -K
>>
>>
>> On 5/25/06 4:58 PM, "Kathryn Huxtable" <[EMAIL PROTECTED]> wrote:
>>
>>> In that case, I'll stick with the webapp. Thanks much! -K
>>>
>>>
>>> On 5/25/06 4:56 PM, "ben short" <[EMAIL PROTECTED]> wrote:
>>>
>>>> Kathryn
>>>>
>>>> The idea is to have one proxy per organisation. That way if all the
>>>> programmers need spring as a dependancy, the proxy only downloads it
>>>> once, when the first programmer tries to build their project. the next
>>>> programmer gets the dependancy from the proxy, making it much faster.
>>>>
>>>> Ben
>>>>
>>>>
>>>> On 5/25/06, Kathryn Huxtable <[EMAIL PROTECTED]> wrote:
>>>>> Thanks, that worked.
>>>>>
>>>>> Is the general opinion that each developer should set up maven-proxy on
>>>>> their own machine, or have one proxy site for an organization? If it's on
>>>>> my
>>>>> local machine I can use standalone.
>>>>>
>>>>> -K
>>>>>
>>>>>
>>>>> On 5/25/06 2:36 PM, "ben short" <[EMAIL PROTECTED]> wrote:
>>>>>
>>>>>> Kathryn.
>>>>>>
>>>>>> You need to add the following to your settings.xml.
>>>>>>
>>>>>> <mirror>
>>>>>> <mirrorOf>central</mirrorOf>
>>>>>> <name>Internal Mirror</name>
>>>>>> <url>http://url.to.your.proxy</url>
>>>>>> <id>local-proxy</id>
>>>>>> </mirror>
>>>>>>
>>>>>> When you rum mvn on your local machine it will go to your proxy for
>>>>>> the plugins and dependancies it needs. If the proxy doesnt have the
>>>>>> requested jars it will try and get them from ibiblio, codehaus or
>>>>>> other remote repositries.
>>>>>>
>>>>>> Ben
>>>>>>
>>>>>> On 5/25/06, Kathryn Huxtable <[EMAIL PROTECTED]> wrote:
>>>>>>> Okay, I'll bite. I just set up maven-proxy-webapp (my team doesn't have
>>>>>>> control over the firewall settings for our web servers, so I need to
>>>>>>> have
>>>>>>> this on 80/443).
>>>>>>>
>>>>>>> I copied a maven-proxy-config.properties file from somewhere and edited
>>>>>>> the
>>>>>>> WEB_ROOT to be my local locations.
>>>>>>>
>>>>>>> What now?
>>>>>>>
>>>>>>> What do I change in settings.xml and pom.xml to make this work?
>>>>>>>
>>>>>>> And how do I populate the proxy with jars so that the next time codehaus
>>>>>>> or
>>>>>>> ibiblio is down I can get work done?
>>>>>>>
>>>>>>> -K
>>>>>>>
>>>>>>>
>>>>>>> On 5/25/06 11:51 AM, "dan tran" <[EMAIL PROTECTED]> wrote:
>>>>>>>
>>>>>>>> Chas, i feel your pains, so here a list of my own recommendations:
>>>>>>>>
>>>>>>>> 1. Get a maven-proxy in place, so when a central repo is down, you
>>>>>>>> can
>>>>>>>> switch to
>>>>>>>> a another mirror without user notice. Set up maven-proxy is not
>>>>>>>> that
>>>>>>>> hard ;-)
>>>>>>>> check out archive list for all maven-proxy discussion. Feel
>>>>>>>> free
>>>>>>>> to
>>>>>>>> ping us for help
>>>>>>>>
>>>>>>>> 2. Dont use snapshot, cut a release yourself. I fetch the source
>>>>>>>> and
>>>>>>>> post fix the version
>>>>>>>> with svn revision number. For example, if I need a feature/bug
>>>>>>>> fix
>>>>>>>> in maven-assembly-plugin
>>>>>>>> version 2.2-snapshot, then I build 2.2-${svn.revision} and
>>>>>>>> deploy
>>>>>>>> to
>>>>>>>> your
>>>>>>>> internal repository that can serve by maven-proxy.
>>>>>>>>
>>>>>>>> 3. Use pluginManagement to specify all plugins that used by your
>>>>>>>> project'poms.
>>>>>>>> This get your team's build much faster since it does not have to
>>>>>>>> go
>>>>>>>> to maven-proxy to look
>>>>>>>> for daily update.
>>>>>>>>
>>>>>>>> This settup will prevent most of maven's uncertainties that others and
>>>>>>>> I
>>>>>>>> have gone thru
>>>>>>>>
>>>>>>>> Hope it helps
>>>>>>>>
>>>>>>>> -D
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 5/25/06, Chas Douglass <[EMAIL PROTECTED]> wrote:
>>>>>>>>>
>>>>>>>>> I really liked the idea of Maven2 when I heard about it, and when a
>>>>>>>>> fellow developer used it successfully to build a small library for me,
>>>>>>>>> I
>>>>>>>>> thought it was time to jump in.
>>>>>>>>>
>>>>>>>>> Three weeks later I have managed to accomplish very little on my
>>>>>>>>> project, and I've converted four simple Ant build files into 7 Maven
>>>>>>>>> pom.xml's that, by and large, don't work.
>>>>>>>>>
>>>>>>>>> THE IMPLEMENTATION PROBLEMS
>>>>>>>>> To advertise Maven 2 as "stable" is, I believe, a disservice to
>>>>>>>>> developers. In my experience with it, "early beta" would be a kind
>>>>>>>>> description.
>>>>>>>>>
>>>>>>>>> After struggling for the first week with broken links and dead-ends on
>>>>>>>>> the web pages, I subscribed to the users list and found out there is a
>>>>>>>>> "secret" book that documents much of Maven (ok, it's not really
>>>>>>>>> secret,
>>>>>>>>> but should I really have to subscribe to a mailing list to find out
>>>>>>>>> there is more documentation?).
>>>>>>>>>
>>>>>>>>> Of course, the secret book also documents features that aren't
>>>>>>>>> released
>>>>>>>>> yet (wagon is what bit me). Perhaps that's why it's secret.
>>>>>>>>>
>>>>>>>>> So now I'm using a "stable" product (incorporating several unreleased
>>>>>>>>> and poorly documented snapshots) and what happens? New releases of a
>>>>>>>>> number of modules come out and everything breaks! Have I specified a
>>>>>>>>> release where I shouldn't have? Have I NOT specified a release where
>>>>>>>>> I
>>>>>>>>> SHOULD have? Based on the limited traffic of the problem on the
>>>>>>>>> user's
>>>>>>>>> list, I can only conclude that most people that use Maven are building
>>>>>>>>> the plugins/modules and that very few people actually use it to build
>>>>>>>>> applications.
>>>>>>>>>
>>>>>>>>> THE DESIGN PROBLEMS
>>>>>>>>> But my real beef comes to design decisions that I think needs some
>>>>>>>>> serious consideration.
>>>>>>>>>
>>>>>>>>> MAVEN HIDES TOO MUCH.
>>>>>>>>>
>>>>>>>>> It really is nice advertising to say "Look! This 12 line pom.xml
>>>>>>>>> builds
>>>>>>>>> this huge project". But that's only if you happen to want to do
>>>>>>>>> EXACTLY
>>>>>>>>> that ONE thing (which seems to be: build a Maven plugin). The real
>>>>>>>>> world is more complicated. And as soon as I want to get more
>>>>>>>>> complicated, Maven obliges me by getting WAY more complicated. Most
>>>>>>>>> of
>>>>>>>>> this complication is due to, I believe, hiding too much from me.
>>>>>>>>>
>>>>>>>>> Why is it that I'm expected, as a developer, to be able to download
>>>>>>>>> and
>>>>>>>>> compile snapshots of plugins that aren't released yet (the jnlp
>>>>>>>>> plugin),
>>>>>>>>> but I'm not expected to understand a FULL LIFE CYCLE build file?
>>>>>>>>>
>>>>>>>>> You have this wonderful archetype mechanism, why don't you use it to
>>>>>>>>> make a pom.xml that actually includes information for everything it
>>>>>>>>> does? This would be self-documenting to developers. Isn't the target
>>>>>>>>> audience developers?
>>>>>>>>>
>>>>>>>>> I believe Maven is hiding the actual build structure, and that that is
>>>>>>>>> a
>>>>>>>>> bad thing.
>>>>>>>>>
>>>>>>>>> I have used a number of open source projects where the configuration
>>>>>>>>> file is used to document the product! It is MUCH more enlightening to
>>>>>>>>> see a comment with a commented-out section than, well, nothing.
>>>>>>>>>
>>>>>>>>> An example: I use Java 1.5. The Maven default is 1.4. Can I simply
>>>>>>>>> search for "1.4" in the pom.xml and change it to "1.5". Nooooo. I
>>>>>>>>> have
>>>>>>>>> to research which plugin actually sets this value, how it sets this
>>>>>>>>> value, and add 9 lines to my pom.xml (assuming I did not yet have any
>>>>>>>>> plugins configuration).
>>>>>>>>>
>>>>>>>>> THE CENTRAL REPOSITORY PROBLEM
>>>>>>>>> I think the second major design problem is the central repository. As
>>>>>>>>> evidenced by the hardware failure at codehaus.org, this is a
>>>>>>>>> single-point-of-failure that is simply unacceptable in real world
>>>>>>>>> build
>>>>>>>>> situations.
>>>>>>>>>
>>>>>>>>> Not only does it represent a single-point-of-failure, it's not frozen.
>>>>>>>>> I could never see my company using Maven unless we set up our own
>>>>>>>>> version of the repository, and probably only if we used it
>>>>>>>>> exclusively,
>>>>>>>>> since we require complete build reproducibility. Relying on an
>>>>>>>>> external
>>>>>>>>> organization to not make "secret" updates (as has been recently
>>>>>>>>> discussed) is simply unacceptable. I haven't tried to set up a
>>>>>>>>> "central" repository, but from scanning messages on the user's list,
>>>>>>>>> it
>>>>>>>>> sounds somewhat less than well defined.
>>>>>>>>>
>>>>>>>>> Personally (for open-source projects), I can probably use it, but
>>>>>>>>> there
>>>>>>>>> is going to be a nagging suspicion when something breaks.
>>>>>>>>>
>>>>>>>>> So, for small users it represents a roadblock when the repository is
>>>>>>>>> unavailable, and for large users it represents a reproducibility
>>>>>>>>> problem.
>>>>>>>>>
>>>>>>>>> CONCLUSION:
>>>>>>>>> I think Maven is just "not ready for prime time". I really want to
>>>>>>>>> like
>>>>>>>>> it. I think there are some great ideas, and clearly some really smart
>>>>>>>>> people working on it.
>>>>>>>>>
>>>>>>>>> I hope this rant can be taken constructively. I want projects like
>>>>>>>>> this
>>>>>>>>> to succeed, I really do.
>>>>>>>>>
>>>>>>>>> And, please, I understand I'm one person. This is MY view of
>>>>>>>>> attempting
>>>>>>>>> to use Maven to build MY projects. Perhaps I'm just not the target
>>>>>>>>> audience. Perhaps I'm just out in left field. Perhaps I've just
>>>>>>>>> missed
>>>>>>>>> the point completely.
>>>>>>>>>
>>>>>>>>> Chas Douglass
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>>>>>>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>>>>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>>>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
