Rant (very long)

[Chas Douglass <ch...@gmail.com>]

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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Rant (very long)

[Jeff Jensen <je...@upstairstechnology.com>]

Your experience is not singular.  Try Maven 1; many of us still use it while M2
is hardened and more plugins completed.


Quoting Chas Douglass <ch...@gmail.com>:

> 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: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>




---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Rant (very long)

[Arnaud Bailly <ab...@achilleus.net>]

Hi to all, 
I feel compelled to add my 50 cents advice to this thread :-)

I could have written chas's mail some months ago, when I began
switching my projects from maven1 to maven2 (2.0.1 at that time),
feeling overwhelmed by the complexity of taming the beast and
frustrated by the fragmentation and the scarcity of the
documentation. 

The arrival of mergere's book is definitely a  great move towards
widespread adoption and clear understanding of maven2's features and I
too am a bit surprised that advertisement about it should be quite
"secretive". There may be unknown constraints but it would be really
useful to include a link on maven's site first page. So the lack of
documentation is becoming less of a problem than before.

I now use maven for all my projects, whether small or big. I have
setup an internal repository for my former employer, together with
https access and private certificates, projects/customer specific
repositories, a maven proxy and a continuum driven integrated build
process. We used it to work on a large project (and with off-shore
devlopment) and were very happy with some features of maven2 that
would have been difficult to implement with m1 or ant:
 - the multi projects features are very easy to setup,
 - settings.xml and profiles are really great for cleanly customizing
 partr of a build acording to the environment,
 - creation of (simple) archetypes is easy, and this helps when you
 need to break a project into many similar small projects (features or
 screens),
 - the repository mechanism and the version mangement is tricky to
 understand (and I think there are things I do not yet fully master)
 but works fine and you have complete control over what is downloaded
 and how,
 - and most importantly, creating custom plugins is childplay when
 compared with maven1 and those stupid jelly scripts (forgive me if
 you happen to be a jelly contributor but I think the mere idea of
 creating a script language in XML is silly ;-) ). 

As for the problems, here is what I still find annoying:
 - the cobertura plugin, only alternative to clover plugin is still a
 bit difficult to use. And unit testing without code coverage is like
 shooting in the dark. This is the plugin I missed more,
 - central repository is an important issue, at least when new
 features are added to your build. May be a distributed scheme,
 something along the lines of ptp systems would be nice,
 - I did not use the releas plugin yet but it seems a bit "touchy".

All in all, I find maven2 is a great project and an improvement over
other build systems I am aware of (make, ant and maven1). I would find
difficult now to undertake java projects without it (I would rather
give up eclipse if given the choice !) although I miss good
documentation. 

regards,
-- 
OQube < software engineering \ génie logiciel >
Arnaud Bailly, Dr.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Rant (very long)

[Brad O'Hearne <br...@neurofire.com>]

Chas,

For what its worth, a couple of months ago I posted similar sentiments, 
and so I second your thoughts here. I didn't really go through a list of 
the issues I faced -- I focussed primarily on the documentation. The 
Megere documentation is a significant improvement, though I also 
recognize the curiousity of it seemingly existing separate from the 
project documentation.

I am using Maven 2 successfully, with maven-proxy in place, and it works 
fairly well, but I do dread issues that come up in our work that require 
variations to pom.xml configuration, as there's never any telling how 
long it will take to resolve an issue.

I appreciate you being brave enough to post your thoughts. I welcome 
them, and share your sentiments. But I've kind of backed off on any real 
discussion of this, as I realize that not everyone grasps or agrees with 
the irony of the requirement to dig into source code to merely use an 
OSS library. Once you cross that threshold and get involved directly 
with source code, it turns a major advantage of OSS (time/licensing 
cost) into merely a shell-game, where the development cost is shifted 
from coding and having complete architectural control to reading someone 
else's code and having no architectural control. I just think its a 
pity, because Maven is obviously the product of a lot of hard work, and 
such work shouldn't be marginalized. Without going into a diatribe here, 
it seems that everyone would tend to agree with the notion of 
"interface-based programming", the general tenant being that integration 
points in applications be defined via well-defined, clean interfaces. 
However, it seems that this principle is completely ignored from a 
customer/product standpoint -- the "interface" in this relationship is 
the clear definition of the use of the product, so leaving this 
interface unattended to basically obfuscates great functionality behind 
a convoluted interface.

Its perfectly fine if others see it differently -- I'd guess most 
probably do. Its just as I reflect on the curve incurred to convert to 
maven, it was more steep and unexpected than originally thought, not 
because of complexity, but more because of the hunt for answers, and 
subsequent trial and error And additionally, I'm getting similar 
feedback from others I know who are attempting to use Maven.

But again, the Megere book, though I haven't been able to read it all 
yet, it looks to be a really good resource.

Brad

Chas Douglass 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: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Rant (very long)

[Wojciech Gdela <el...@poczta.onet.pl>]

Hello,

Your first two points proves that Chas is right. Maven 2 is not stable
(and lacks documentation), I agree with this. But it is still a great
tool and I hope it will be improved in the near future.

> 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

-- 
Best regards,
Wojciech Gdela.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Maven-proxy (was Re: Rant (very long))

[Tamás Cservenák <t....@gmail.com>]

Inhouse repo, if you look at Proximity is very important to achieve stable
and controlled build environment.

If you have some company level (reaches through more separate projects)
some-utility.jar, how will you spread it amongst developers? How will you
achieve if some-utility.jar is updated, to update all developer environment
too?

Will everybody issue "maven install:install-file"? They could :)

Publish it on the inhouse repo and done. Every developer will acess your
artifact as they access for example log4j.

See here
https://is-micro.myip.hu/projects/ismicro-commons/proximity/

~t~

On 5/26/06, Kathryn Huxtable <kh...@ku.edu> wrote:
>
> Of course, one answer leads to another question... ;-)
>
> Why bother proxying inhouse repositories? I don't see the logic there.
>
> -K
>

Re: Maven-proxy (was Re: Rant (very long))

[Trygve Laugstøl <tr...@apache.org>]

Kevin Galligan wrote:
> Just had a crazy thought about the "external organization making secret
> changes" issue.  If the issue is with snapshot builds I guess I don't have
> much for you there (other than the above, of course).  However if the
> concern is simply that you don't know that what's in the repository hasn't
> changed, I had a wacky idea.
> 
> Maybe we write a plugin that does the following.  When you set up a new
> project or change an existing project's dependencies, you need to run that
> plugin.  Something like:
> 
> mvn depend-check:build
> 
> It'll go through non-snapshot dependencies and build a datafile that 
> keeps a
> hash of each of the artifacts.  Keep that in the root directory next to the
> 'pom.xml' file, and more importantly, keep it in source control.
> 
> Attach the plugin to the build, although the goal would be like
> 'depend-check:check'.  This plugin would consult with the datafile built
> earlier and check that each local artifact matched what was used originally
> for the build.  If something doesn't match, you'll get an error and an
> aborted build.

This has been asked before and would be a very useful plugin for some.

It should also be fairly easy to implement and I'm sure it would be 
accepted into the Mojo sandbox.

--
Trygve

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Maven-proxy (was Re: Rant (very long))

[Kevin Galligan <kg...@gmail.com>]

Just had a crazy thought about the "external organization making secret
changes" issue.  If the issue is with snapshot builds I guess I don't have
much for you there (other than the above, of course).  However if the
concern is simply that you don't know that what's in the repository hasn't
changed, I had a wacky idea.

Maybe we write a plugin that does the following.  When you set up a new
project or change an existing project's dependencies, you need to run that
plugin.  Something like:

mvn depend-check:build

It'll go through non-snapshot dependencies and build a datafile that keeps a
hash of each of the artifacts.  Keep that in the root directory next to the
'pom.xml' file, and more importantly, keep it in source control.

Attach the plugin to the build, although the goal would be like
'depend-check:check'.  This plugin would consult with the datafile built
earlier and check that each local artifact matched what was used originally
for the build.  If something doesn't match, you'll get an error and an
aborted build.

I mean, personally, I'm not awake at night worried that struts 1.2.9 is
different than it was 3 months ago, but I understand from where your concern
comes.

Of course, I'm exhausted, so maybe my idea is impratical or whatever, but I
think it would serve as a decent sanity check.  if just knowing that
something is not right isn't enough, maybe as part of the release or deploy
plugins you can optionally stuff a copy of all artifacts somewhere.

As to maven being bleeding edge and being quirky, I'd agree.  However, at
this point I wouldn't start a new project without it.  And, believe me, I'm
the first guy to scream "Emporer's New Clothes" when people get overly
excited about some hyped new thing.

I'm sure I've convinced you ;)

On 5/26/06, Kathryn Huxtable <kh...@ku.edu> wrote:
>
> Uh, I guess so. ;-) I did mean "he".
>
> Sorry, I was up late last night playing Civilization IV. (I really need to
> lock my Dell up in a drawer.) I shouldn't touch a keyboard lest I break
> something.
>
> -K, off to bed
>
>
> On 5/25/06 6:40 PM, "Lee Meador" <le...@leemeador.com> wrote:
>
> > Uh .. when HE made an error. Is that another test?
> >
> > On 5/25/06, Kathryn Huxtable <kh...@ku.edu> wrote:
> >>
> >> 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" <be...@benshort.co.uk> 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 <kh...@ku.edu> 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" <be...@benshort.co.uk> 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 <kh...@ku.edu> 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" <kh...@ku.edu> wrote:
> >>>>>>
> >>>>>>> In that case, I'll stick with the webapp. Thanks much! -K
> >>>>>>>
> >>>>>>>
> >>>>>>> On 5/25/06 4:56 PM, "ben short" <be...@benshort.co.uk> 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 <kh...@ku.edu> 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" <be...@benshort.co.uk> 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 <kh...@ku.edu> 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" <da...@gmail.com> 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 <ch...@gmail.com> 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: users-unsubscribe@maven.apache.org
> >>>>>>>>>>>> For additional commands, e-mail: users-help@maven.apache.org
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >> ---------------------------------------------------------------------
> >>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >>>>>>>>>>> For additional commands, e-mail: users-help@maven.apache.org
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >> ---------------------------------------------------------------------
> >>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >>>>>>>>>> For additional commands, e-mail: users-help@maven.apache.org
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >> ---------------------------------------------------------------------
> >>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >>>>>>>>> For additional commands, e-mail: users-help@maven.apache.org
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >> ---------------------------------------------------------------------
> >>>>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >>>>>>>> For additional commands, e-mail: users-help@maven.apache.org
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >> ---------------------------------------------------------------------
> >>>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >>>>>>> For additional commands, e-mail: users-help@maven.apache.org
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> ---------------------------------------------------------------------
> >>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >>>>>> For additional commands, e-mail: users-help@maven.apache.org
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >>>>> For additional commands, e-mail: users-help@maven.apache.org
> >>>>>
> >>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >>>> For additional commands, e-mail: users-help@maven.apache.org
> >>>>
> >>>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >>> For additional commands, e-mail: users-help@maven.apache.org
> >>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: users-help@maven.apache.org
> >>
> >>
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>

Re: Maven-proxy (was Re: Rant (very long))

[Kathryn Huxtable <kh...@ku.edu>]

Uh, I guess so. ;-) I did mean "he".

Sorry, I was up late last night playing Civilization IV. (I really need to
lock my Dell up in a drawer.) I shouldn't touch a keyboard lest I break
something.

-K, off to bed


On 5/25/06 6:40 PM, "Lee Meador" <le...@leemeador.com> wrote:

> Uh .. when HE made an error. Is that another test?
> 
> On 5/25/06, Kathryn Huxtable <kh...@ku.edu> wrote:
>> 
>> 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" <be...@benshort.co.uk> 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 <kh...@ku.edu> 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" <be...@benshort.co.uk> 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 <kh...@ku.edu> 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" <kh...@ku.edu> wrote:
>>>>>> 
>>>>>>> In that case, I'll stick with the webapp. Thanks much! -K
>>>>>>> 
>>>>>>> 
>>>>>>> On 5/25/06 4:56 PM, "ben short" <be...@benshort.co.uk> 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 <kh...@ku.edu> 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" <be...@benshort.co.uk> 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 <kh...@ku.edu> 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" <da...@gmail.com> 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 <ch...@gmail.com> 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: users-unsubscribe@maven.apache.org
>>>>>>>>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>> ---------------------------------------------------------------------
>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>>>>>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>>>>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>>>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>> 
>>>>>> 
>>>>> 
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>> 
>>>> 
>>>> 
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>> 
>>>> 
>>> 
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>> 
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>> 
>> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Maven-proxy (was Re: Rant (very long))

[Lee Meador <le...@leemeador.com>]

Uh .. when HE made an error. Is that another test?

On 5/25/06, Kathryn Huxtable <kh...@ku.edu> wrote:
>
> 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" <be...@benshort.co.uk> 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 <kh...@ku.edu> 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" <be...@benshort.co.uk> 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 <kh...@ku.edu> 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" <kh...@ku.edu> wrote:
> >>>>
> >>>>> In that case, I'll stick with the webapp. Thanks much! -K
> >>>>>
> >>>>>
> >>>>> On 5/25/06 4:56 PM, "ben short" <be...@benshort.co.uk> 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 <kh...@ku.edu> 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" <be...@benshort.co.uk> 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 <kh...@ku.edu> 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" <da...@gmail.com> 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 <ch...@gmail.com> 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: users-unsubscribe@maven.apache.org
> >>>>>>>>>>> For additional commands, e-mail: users-help@maven.apache.org
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> ---------------------------------------------------------------------
> >>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >>>>>>>>> For additional commands, e-mail: users-help@maven.apache.org
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> ---------------------------------------------------------------------
> >>>>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >>>>>>>> For additional commands, e-mail: users-help@maven.apache.org
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> ---------------------------------------------------------------------
> >>>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >>>>>>> For additional commands, e-mail: users-help@maven.apache.org
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> ---------------------------------------------------------------------
> >>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >>>>>> For additional commands, e-mail: users-help@maven.apache.org
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >>>>> For additional commands, e-mail: users-help@maven.apache.org
> >>>>>
> >>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >>>> For additional commands, e-mail: users-help@maven.apache.org
> >>>>
> >>>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >>> For additional commands, e-mail: users-help@maven.apache.org
> >>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: users-help@maven.apache.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>


-- 
-- Lee Meador
Sent from gmail. My real email address is lee@leemeador.com

Re: Maven-proxy (was Re: Rant (very long))

[Kathryn Huxtable <kh...@ku.edu>]

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" <be...@benshort.co.uk> 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 <kh...@ku.edu> 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" <be...@benshort.co.uk> 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 <kh...@ku.edu> 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" <kh...@ku.edu> wrote:
>>>> 
>>>>> In that case, I'll stick with the webapp. Thanks much! -K
>>>>> 
>>>>> 
>>>>> On 5/25/06 4:56 PM, "ben short" <be...@benshort.co.uk> 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 <kh...@ku.edu> 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" <be...@benshort.co.uk> 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 <kh...@ku.edu> 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" <da...@gmail.com> 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 <ch...@gmail.com> 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: users-unsubscribe@maven.apache.org
>>>>>>>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>>>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>> 
>>>>> 
>>>>> 
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>> 
>>>> 
>>>> 
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>> 
>>>> 
>>> 
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>> 
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>> 
>> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Maven-proxy (was Re: Rant (very long))

[ben short <be...@benshort.co.uk>]

Yes you use the maven-proxy to serve the internal repository.

What do you mean my sshext?

Ben

On 5/25/06, Kathryn Huxtable <kh...@ku.edu> 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" <be...@benshort.co.uk> 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 <kh...@ku.edu> 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" <kh...@ku.edu> wrote:
> >>
> >>> In that case, I'll stick with the webapp. Thanks much! -K
> >>>
> >>>
> >>> On 5/25/06 4:56 PM, "ben short" <be...@benshort.co.uk> 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 <kh...@ku.edu> 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" <be...@benshort.co.uk> 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 <kh...@ku.edu> 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" <da...@gmail.com> 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 <ch...@gmail.com> 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: users-unsubscribe@maven.apache.org
> >>>>>>>>> For additional commands, e-mail: users-help@maven.apache.org
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> ---------------------------------------------------------------------
> >>>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >>>>>>> For additional commands, e-mail: users-help@maven.apache.org
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>> ---------------------------------------------------------------------
> >>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >>>>>> For additional commands, e-mail: users-help@maven.apache.org
> >>>>>>
> >>>>>
> >>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >>>>> For additional commands, e-mail: users-help@maven.apache.org
> >>>>>
> >>>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >>>> For additional commands, e-mail: users-help@maven.apache.org
> >>>>
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >>> For additional commands, e-mail: users-help@maven.apache.org
> >>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: users-help@maven.apache.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Maven-proxy (was Re: Rant (very long))

[Tamás Cservenák <t....@gmail.com>]

I think it help.

The good thing about two existing known maven-proxies (codehaus maven-proxy
and Proximity) is that they're actually 2in1 solutions. They are NOT
strictly a proxy as a HTTP proxy. The are just ABLE to behave like http
proxy (or the logic that drives them is similar to HTTP proxy).

They are also fully functional when it comes to repository hosting too. And
you have extras: fast searching, access management, etc.

My practice with Proximity is following:

define proxied repo for central, codehaus, etc...
define LOCAL (so not proxied reposes) like inhouse, etc.

Proxy storages are handled ONLY BY Proximity.
And PUBLISH local proxy storages using standard ways (ftp, sftp, sambe,
nfs...) and make your developers DEPLOY onto them using Maven2 itself! In
case of a commercial project, it should be right in the superpom where is
the deployment area, etc...

In our house, we use JDS2* with well defined paths and URLs. On POM creation
a developer knowing the project ID of project (this ID is used in paths,
URLs, mailing list names, etc something like SourceForge project id) can
write complete POM almost out of his head.

And it's easier to maintain (one application in company does proxying and
hosting) - one backup - one thing less to worry.

Some WIKI scratch that tries to define JDS2 and what it should be.
https://is-micro.myip.hu/trac/ismicro-jds2

~t~

On 5/26/06, ben short <be...@benshort.co.uk> 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
>

Re: Maven-proxy (was Re: Rant (very long))

[Kathryn Huxtable <kh...@ku.edu>]

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" <be...@benshort.co.uk> 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 <kh...@ku.edu> 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" <kh...@ku.edu> wrote:
>> 
>>> In that case, I'll stick with the webapp. Thanks much! -K
>>> 
>>> 
>>> On 5/25/06 4:56 PM, "ben short" <be...@benshort.co.uk> 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 <kh...@ku.edu> 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" <be...@benshort.co.uk> 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 <kh...@ku.edu> 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" <da...@gmail.com> 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 <ch...@gmail.com> 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: users-unsubscribe@maven.apache.org
>>>>>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>>>>> 
>>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>> 
>>>>> 
>>>>> 
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>> 
>>>>> 
>>>> 
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>> 
>>> 
>>> 
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>> 
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>> 
>> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Maven-proxy (was Re: Rant (very long))

[ben short <be...@benshort.co.uk>]

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 <kh...@ku.edu> 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" <kh...@ku.edu> wrote:
>
> > In that case, I'll stick with the webapp. Thanks much! -K
> >
> >
> > On 5/25/06 4:56 PM, "ben short" <be...@benshort.co.uk> 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 <kh...@ku.edu> 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" <be...@benshort.co.uk> 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 <kh...@ku.edu> 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" <da...@gmail.com> 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 <ch...@gmail.com> 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: users-unsubscribe@maven.apache.org
> >>>>>>> For additional commands, e-mail: users-help@maven.apache.org
> >>>>>>>
> >>>>>>>
> >>>>>
> >>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >>>>> For additional commands, e-mail: users-help@maven.apache.org
> >>>>>
> >>>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >>>> For additional commands, e-mail: users-help@maven.apache.org
> >>>>
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >>> For additional commands, e-mail: users-help@maven.apache.org
> >>>
> >>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: users-help@maven.apache.org
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Maven-proxy (was Re: Rant (very long))

[Daniel Kulp <da...@iona.com>]

Well,  we actually use maven-proxy to host the inhouse repository.  
Basically, we have it configured with repo.local.store pointing to the 
actual repository dir and repo.list empty.   Thus, it just serves up 
what's in the dir.

The main reason we did that was for the search capabilities.   A developer 
can point at the repository URL and execute a search.   Works quite well 
when it gets large.    Keeps people from having to log into the machine 
and running a "find".   It also means the "UI" is exactly the same for 
the proxied content as the non-proxied content.

That said, we DO use maven-proxies at our other remote sites to proxy the 
inhouse repository.   That's just a performance enhancement though.   The 
VPN between the sites isn't always very good.

Enjoy!
Dan



On Thursday 25 May 2006 18:01, Kathryn Huxtable 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" <kh...@ku.edu> wrote:
> > In that case, I'll stick with the webapp. Thanks much! -K
> >
> > On 5/25/06 4:56 PM, "ben short" <be...@benshort.co.uk> 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 <kh...@ku.edu> 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" <be...@benshort.co.uk> 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 <kh...@ku.edu> 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" <da...@gmail.com> 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 <ch...@gmail.com> 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:
> >>>>>>> users-unsubscribe@maven.apache.org For additional commands,
> >>>>>>> e-mail: users-help@maven.apache.org
> >>>>>
> >>>>> -----------------------------------------------------------------
> >>>>>---- To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >>>>> For additional commands, e-mail: users-help@maven.apache.org
> >>>>
> >>>> ------------------------------------------------------------------
> >>>>--- To unsubscribe, e-mail: users-unsubscribe@maven.apache.org For
> >>>> additional commands, e-mail: users-help@maven.apache.org
> >>>
> >>> -------------------------------------------------------------------
> >>>-- To unsubscribe, e-mail: users-unsubscribe@maven.apache.org For
> >>> additional commands, e-mail: users-help@maven.apache.org
> >>
> >> --------------------------------------------------------------------
> >>- To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: users-help@maven.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org

-- 
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727  C: 508-380-7194
daniel.kulp@iona.com

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Maven-proxy (was Re: Rant (very long))

[Kathryn Huxtable <kh...@ku.edu>]

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" <kh...@ku.edu> wrote:

> In that case, I'll stick with the webapp. Thanks much! -K
> 
> 
> On 5/25/06 4:56 PM, "ben short" <be...@benshort.co.uk> 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 <kh...@ku.edu> 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" <be...@benshort.co.uk> 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 <kh...@ku.edu> 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" <da...@gmail.com> 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 <ch...@gmail.com> 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: users-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>>> 
>>>>>>> 
>>>>> 
>>>>> 
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>> 
>>>>> 
>>>> 
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>> 
>>> 
>>> 
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>> 
>>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Rant (very long)

[Kathryn Huxtable <kh...@ku.edu>]

In that case, I'll stick with the webapp. Thanks much! -K


On 5/25/06 4:56 PM, "ben short" <be...@benshort.co.uk> 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 <kh...@ku.edu> 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" <be...@benshort.co.uk> 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 <kh...@ku.edu> 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" <da...@gmail.com> 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 <ch...@gmail.com> 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: users-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>> 
>>>>>> 
>>>> 
>>>> 
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>> 
>>>> 
>>> 
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>> 
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>> 
>> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Rant (very long)

[ben short <be...@benshort.co.uk>]

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 <kh...@ku.edu> 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" <be...@benshort.co.uk> 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 <kh...@ku.edu> 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" <da...@gmail.com> 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 <ch...@gmail.com> 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: users-unsubscribe@maven.apache.org
> >>>> For additional commands, e-mail: users-help@maven.apache.org
> >>>>
> >>>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: users-help@maven.apache.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Rant (very long)

[Brad O'Hearne <br...@neurofire.com>]

I'll add this one wrinkle -- I happen to use maven (and maven-proxy) at 
two (soon to be three) different organizations, and as such, I configure 
no mirrors in my settings.xml, but instead define my proxies in the 
pom.xml files with the specific projects, as each project hits a proxy 
at a completely different organization.

Brad

ben short 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 <kh...@ku.edu> 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" <da...@gmail.com> 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 <ch...@gmail.com> 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: users-unsubscribe@maven.apache.org
>> >> For additional commands, e-mail: users-help@maven.apache.org
>> >>
>> >>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Rant (very long)

[Kathryn Huxtable <kh...@ku.edu>]

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" <be...@benshort.co.uk> 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 <kh...@ku.edu> 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" <da...@gmail.com> 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 <ch...@gmail.com> 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: users-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>> 
>>>> 
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>> 
>> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Rant (very long)

[ben short <be...@benshort.co.uk>]

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 <kh...@ku.edu> 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" <da...@gmail.com> 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 <ch...@gmail.com> 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: users-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: users-help@maven.apache.org
> >>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Rant (very long)

[Franz Fehringer <fe...@isogmbh.de>]

Hello Ben,

I can access https://jaxb.dev.java.net/jaxb-maven2-plugin with my 
browsers (IE6 and Firefox 1.5) but not with Maven2.
My problem is described in detail in the mail below.
I also opened MNG-2305 for it.

Best regards

Franz

Only the first proxy is considered it seems.
If i exchange the two proxies (https first http second) the http 
connects start to fail.
How do i configure i proxy for both http amd https?

Greetings

Franz

Franz Fehringer schrieb: Hello,

We use the same proxy host and port both for http and https.
With Maven 2.0.4 i am able to dynamically download plugins over http but 
not over https.
In the latter case i get

Caused by: java.net.ConnectException: Connection timed out: connect
        at java.net.PlainSocketImpl.socketConnect(Native Method)
        at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333)
        at 
java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195)
        at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182)
        at java.net.Socket.connect(Socket.java:507)
        at java.net.Socket.connect(Socket.java:457)
        at sun.net.NetworkClient.doConnect(NetworkClient.java:157)
        at sun.net.www.http.HttpClient.openServer(HttpClient.java:365)
        at sun.net.www.http.HttpClient.openServer(HttpClient.java:477)
        at 
sun.net.www.protocol.https.HttpsClient.<init>(HttpsClient.java:278)
        at sun.net.www.protocol.https.HttpsClient.New(HttpsClient.java:335)

The file to be downloaded is
Downloading: 
https://maven-repository.dev.java.net/repository/com.sun.xml.bind/poms/jaxb-impl-2.0.pom*
*and my .m2/settings reads

<settings>
  <localRepository>//winpc229/supply/Maven2/Repository</localRepository>
  <proxies>
    <proxy>
      <active>true</active>
      <protocol>http</protocol>
      <host>proxy</host>
      <port>81</port>
    </proxy>
    <proxy>
      <active>true</active>
      <protocol>https</protocol>
      <host>proxy</host>
      <port>81</port>
    </proxy>
  </proxies>
</settings>

What is the problem and how can it be resolved?

ben short schrieb:
> Franz,
>
> So you have a firewall between you and the internet. Assuming that you
> can access the https repo's from your browser i see no reason why
> Maven wont be able to.
>
> Ben
>
> On 5/26/06, Franz Fehringer <fe...@isogmbh.de> wrote:
>>
>>  I asked this before and now try again.
>>  Can Maven2 access https repositories from behind a proxy/firewall?
>>
>>  Greetings
>>
>>  Franz
>>
>>  Kathryn Huxtable schrieb:
>>  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" <da...@gmail.com> 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 <ch...@gmail.com> 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: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>

Re: Rant (very long)

[ben short <be...@benshort.co.uk>]

Franz,

So you have a firewall between you and the internet. Assuming that you
can access the https repo's from your browser i see no reason why
Maven wont be able to.

Ben

On 5/26/06, Franz Fehringer <fe...@isogmbh.de> wrote:
>
>  I asked this before and now try again.
>  Can Maven2 access https repositories from behind a proxy/firewall?
>
>  Greetings
>
>  Franz
>
>  Kathryn Huxtable schrieb:
>  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" <da...@gmail.com> 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 <ch...@gmail.com> 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: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Rant (very long)

[Franz Fehringer <fe...@isogmbh.de>]

Thanks, i stumbled over this page before, but unfortunately it does not 
solve my problem.

With settings.xml as follows

<settings>
  <localRepository>//winpc229/supply/Maven2/Repository</localRepository>
  <proxies>
    <proxy>
      <active>true</active>
      <protocol>http</protocol>
      <host>proxy</host>
      <port>81</port>
    </proxy>
    <proxy>
      <active>true</active>
      <protocol>https</protocol>
      <host>proxy</host>
      <port>81</port>
    </proxy>
  </proxies>
</settings>

i cannot access the https repository 
https://maven-repository.dev.java.net/repository
If i reverse the order of the proxies (https first http second) i cannot 
access the
central repository any more (this time http protocol).
I opened MNG-2305 about this.

Greetings

Franz

Trygve Laugst�l schrieb:
> Franz Fehringer wrote:
>> I asked this before and now try again.
>> Can Maven2 access https repositories from behind a proxy/firewall?
>
> 1) Browse to http://maven.apache.org
> 2) Press "documentation"
> 3) Seach for "prox" and click on: 
> http://maven.apache.org/guides/mini/guide-proxies.html
>
> -- 
> Trygve
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>

Re: Rant (very long)

[Trygve Laugstøl <tr...@apache.org>]

Franz Fehringer wrote:
> I asked this before and now try again.
> Can Maven2 access https repositories from behind a proxy/firewall?

1) Browse to http://maven.apache.org
2) Press "documentation"
3) Seach for "prox" and click on: 
http://maven.apache.org/guides/mini/guide-proxies.html

--
Trygve

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Rant (very long)

[Franz Fehringer <fe...@isogmbh.de>]

I asked this before and now try again.
Can Maven2 access https repositories from behind a proxy/firewall?

Greetings

Franz

Kathryn Huxtable schrieb:
> 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" <da...@gmail.com> 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 <ch...@gmail.com> 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: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
>>>       
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
>   

Re: Rant (very long)

[Kathryn Huxtable <kh...@ku.edu>]

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" <da...@gmail.com> 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 <ch...@gmail.com> 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: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>> 
>> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Rant (very long)

[dan tran <da...@gmail.com>]

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 <ch...@gmail.com> 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: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>

Re: Rant (very long)

[David Smiley <ds...@mitre.org>]

On 2006-05-25 12:23:02 -0400, Chas Douglass <ch...@gmail.com> said:

> 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.

Yeah, that PDF book "Better Builds with Maven" is a must.  The 
maven.org website does have information, a fair amount actually, but 
seems so disorganized.

> 
> 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.

It would be neat if you could execute some maven command and it would 
"freeze" the plugins that you are using to the current versions when 
you run the command.  So in other words, it would modify a pom to 
specify versions for plugins.  Another idea would be for each maven 
release to specify the plugin versions used that are involved in the 
build lifecycle.  (and that version must be fixed, not a range and not 
a snapshot).

> 
> THE DESIGN PROBLEMS
> But my real beef comes to design decisions that I think needs some 
> serious consideration.
> 
> 			MAVEN HIDES TOO MUCH.

Respectfully... I disagree with you Chas.  I like that Maven hides 
stuff.  It hides stuff that is boilerplate and is the same.... or at 
least *should* be the same across projects if you want a consistent 
build environment -- which I appreciate.  It's annoying to go to an ant 
based project and then have to read the build script to know how it is 
built.  With maven, it's uniform.  If you want an ant based build to do 
something you didn't write in the build.xml... you have to write it.  
With maven, you get it for free (assuming defaults and an existing 
plugin that does what you want -- likely).

Of course... I think that if a system like maven is going to hide 
boilerplate stuff from us developers and operate on defaults, then, it 
is very important that there is clear documentation on what is hidden.  
The documentation for maven isn't so hot, unfortunately.  It would also 
be useful if the output of maven (perhaps with a command line flag) 
could more clearly indicate what it is doing and why.

> 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.

If maven came with specified versions (not ranges or snapshots) of 
build lifecycle oriented plugins, I don't think the central repository 
issue would be the problem that it is now.

> 
> 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

~ David Smiley



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Rant (very long)

[Jeff Mutonho <ej...@gmail.com>]

On 5/26/06, Jorg Heymans <jo...@gmail.com> wrote:
> On 5/25/06, Chas Douglass <ch...@gmail.com> wrote:
>
> 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?).
>
>
> +1, the book should be mentioned somewhere prominently on the maven website.

+1


-- 


Jeff  Mutonho

GoogleTalk : ejbengine
Skype        : ejbengine
Registered Linux user number 366042

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Rant (very long)

[Jorg Heymans <jo...@gmail.com>]

On 5/25/06, Chas Douglass <ch...@gmail.com> wrote:

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?).


+1, the book should be mentioned somewhere prominently on the maven website.

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.


As others mentioned you can specify the exact versions of plugins to be
used, and if you are using snapshots you can configure the pluginRepository
where it's retrieved from to __never__ search for updates.

>
>
> 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?


http://maven.apache.org/ref/current/maven-model/maven.html

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.


This is called "configuration by exception". Some developers actually enjoy
sifting through hundreds of properties to tweak, others don't. It's a matter
of preference really. I for one expect things to initially work out of the
box, and after things get more complicated i'll start looking where and how
to tweak, not the other way around.


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.


+1, many ppl got hosed during last week's outage of codehaus.


> 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.


-1. maven is ready, but it depends just how you define 'prime time'.

You clearly have a very good understanding of how build tools should work in
a project. I suggest you try to stick around a bit longer and learn how to
bend maven2 to your advantage.

HTH
Jorg