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]
