I actually meant scpexe. "I was just testing you," as my ex-father in law
would say when I made an error.
-K
On 5/25/06 5:45 PM, "ben short" <[EMAIL PROTECTED]> wrote:
> Yes you use the maven-proxy to serve the internal repository.
>
> What do you mean my sshext?
>
> Ben
>
> On 5/25/06, Kathryn Huxtable <[EMAIL PROTECTED]> wrote:
>> 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]
>>
>>
>
> ---------------------------------------------------------------------
> 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]
