You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Carsten Ziegeler <cz...@apache.org> on 2006/07/01 11:51:47 UTC
Re: [RANT] This Maven thing is killing us....
I totally agree with Bertrand that using m2 really sucked up a lot of
our time which we could have better used on real development.
Especially the unpredictable results and the not reproduciable builds
are imho a real problem. You build today, it works, you build tomorrow
and it does not. And this occurs on some machines even if nothing has
changed and even if you build in offline mode! Which is really really
strange.
Now, m2 is theoretically a very good tool :) It seems that most problems
occur because of weak poms in the repositories we are using and that
people are updating poms in the repositories without changing the
version number. In addition we have problems with snapshots we are
depending on as they are not available in public repositories.
I really would like to avoid switching to another build system being
this ant or whatever because we invested a lot of time and energy into
the m2 build and we now have some nice maven plugins for deployment and
so on.
Without thinking about the bandwidth problem this might create, but what
about settings up a Cocoon M2 repository where we host all our
dependencies and this is the default repository you're using when you're
developing with Cocoon.
I'm not sure if this is a good idea, because of bandwidth and perhaps
legal issues and it might create confusion when it comes to find out
what's the difference between a version hosted in our repository and the
one hosted on the official one is.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: [RANT] This Maven thing is killing us....
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Saturday 01 July 2006 20:41, Bertrand Delacretaz wrote:
> -Use our own/ASF repository, managed in SVN
Our own Stefano Mazzocchi has recently suggested this, and AFAICT work has
been started.
The idea is to have both "release" and "snapshot" repos operating on ASF
infrastructure, and replicated to the download mirrors. Have not followed the
progress on this though. Check the archive for repository@a.o
Cheers
Niclas
Re: [RANT] This Maven thing is killing us....
Posted by Jorg Heymans <jh...@domek.be>.
Sylvain Wallez wrote:
> And this actually endangers these other projects by forbidding their
> developers from concentrating on actual productive work. Cocoon with all
> its dependencies is certainly an extreme use case for Maven compared to
> all others, and broken builds led some of Cocoon's major contributors to
> not even try 2.2 for months. And now we're wondering if users will even
> be able to build Cocoon if they dare to download it. The project is in
> danger.
If more people find that maven2 is largely responsible for Cocoon's
current impasse then we should take this very serious and really
consider switching back to Ant.
> I discussed with several people from other projects at ApacheCon and
> they all report the same kind of problems: non-repeatability of builds.
> It works one day, but not the day after without anything having changed.
This whole idea of 'my build failed and i didn't change anything' is
just not sustainable anymore with maven2 connecting to a relatively
volatile repo with thousands of artifacts. People should realize that
poms can get updated, corrected, broken, moved, deleted without prior
warning. Admitted this is less true for releases but very true for
snapshots.
> Maven has gained a lot of mindshare because everybody's talking about
Maven2 does a bit more than Ant, this should be clear by now to most
people. Whether we need this 'bit more' or not was perhaps not
considered enough when we voted to switch to maven2.
> it. Does everybody talk about their Ant build system? No, because it
> just works.
... or because they haven't released anything in over a year. Depends on
how you look at it i guess.
Regards
Jorg
Re: [RANT] This Maven thing is killing us....
Posted by Ralph Goers <Ra...@dslextreme.com>.
Andrew Stevens wrote:
>
> From what I've heard on the list so far, though, the Maven build is a
> long way from working correctly. Until it does, I'm not wasting my
> time trying to look at Cocoon 2.2, I'm sticking with the 2.1.x branch.
>
> I can't recall seeing lots of bug reports in JIRA saying "the Ant
> build mechanism sucks". On the other hand, there's nearly 90 open
> issues for the forms block. Draw your own conclusions as to what
> users think needs fixing and what works well enough... Then go and do
> whatever is best technically, since what do users know anyway? :-)
> We'll catch up again and learn the new ways once it's done and
> working. But in the meantime don't be surprised at the lack of
> feedback; you haven't yet convinced us it's worth the pain.
>
Well, I could buy into this except for one little thing. Like almost all
the other committers, I'm a user too. I wouldn't be interested in a
Maven build if I didn't think it was going to simplify my life.
Ralph
Re: [RANT] This Maven thing is killing us....
Posted by Andrew Stevens <at...@hotmail.com>.
>From: Ralph Goers <Ra...@dslextreme.com>
>Date: Sun, 02 Jul 2006 21:16:47 -0700
>
>Tim Williams wrote:
>>The "If it ain't broke, don't fix it" Principle. Ant has just worked
>>in the past, I wasn't around or probably smart enough to understand
>>why the move to maven but I can say from a user perspective it "don't
>>work". I'm over at forrest and, for learning purposes, like to
>>maintain a buildable trunk of Cocoon. That has been impossible since
>>the move to maven. I obviously understand that progress happens in
>>the face of this principle, but there are some cases where it should
>>be respected.
>Actually, this is a good point. It was broken and the move to Maven was
>(and is) an attempt to fix it. Requiring a source download of Cocoon and
>for end user's to perform their own configuration and build was (and still
>is) seen as unacceptable by many of us.
Personally, as a user, I've never had a problem with this. It's no harder
than running the build script for our own application. Besides, I may want
to apply the odd patch from JIRA that's not been applied yet in SVN before I
build it. With Maven I've then got to mess around managing a local
repository for the patched version.
>Furthermore, every Maven "customer" has their own way of creating their own
>Cocoon-based webapp because there just isn't a good standard way of doing
>it with Ant. Maven, when it works correctly, will fix this.
>From what I've heard on the list so far, though, the Maven build is a long
way from working correctly. Until it does, I'm not wasting my time trying
to look at Cocoon 2.2, I'm sticking with the 2.1.x branch.
I can't recall seeing lots of bug reports in JIRA saying "the Ant build
mechanism sucks". On the other hand, there's nearly 90 open issues for the
forms block. Draw your own conclusions as to what users think needs fixing
and what works well enough... Then go and do whatever is best technically,
since what do users know anyway? :-) We'll catch up again and learn the new
ways once it's done and working. But in the meantime don't be surprised at
the lack of feedback; you haven't yet convinced us it's worth the pain.
Andrew.
Re: [RANT] This Maven thing is killing us....
Posted by Ralph Goers <Ra...@dslextreme.com>.
Tim Williams wrote:
> The "If it ain't broke, don't fix it" Principle. Ant has just worked
> in the past, I wasn't around or probably smart enough to understand
> why the move to maven but I can say from a user perspective it "don't
> work". I'm over at forrest and, for learning purposes, like to
> maintain a buildable trunk of Cocoon. That has been impossible since
> the move to maven. I obviously understand that progress happens in
> the face of this principle, but there are some cases where it should
> be respected.
Actually, this is a good point. It was broken and the move to Maven was
(and is) an attempt to fix it. Requiring a source download of Cocoon
and for end user's to perform their own configuration and build was (and
still is) seen as unacceptable by many of us. Furthermore, every Maven
"customer" has their own way of creating their own Cocoon-based webapp
because there just isn't a good standard way of doing it with Ant.
Maven, when it works correctly, will fix this.
Ralph
Re: [RANT] This Maven thing is killing us....
Posted by Sylvain Wallez <sy...@apache.org>.
Tim Williams wrote:
> On a side note, I use the Cocoon code to learn forrest internals and
> that task has even been increasingly more difficult since the
> directory restructoring, which seems random at best.
>
> As you proceed with this discussion, I hope you'll appreciate that
> there are indirect/non-cocooners who are effected by the decisions you
> make... Anyway, just another perspective...
The feedback of people that aren't in everyday's action fire is *really*
important.
Sylvain
--
Sylvain Wallez - http://bluxte.net
Re: [RANT] This Maven thing is killing us....
Posted by Tim Williams <wi...@gmail.com>.
On 7/2/06, Sylvain Wallez <sy...@apache.org> wrote:
> Carsten Ziegeler wrote:
>
> > Now, m2 is theoretically a very good tool :)
>
> Stefano principle: you need good ideas and bad code to grow a community.
I like this Stefano guy more and more every day, as I have a tendency
towards both of these things, with a heavier weighting on the later;)
> The application of this principle in Maven is different than usual, as
> it forces other projects (and not only its own developers) to endure the
> consequences of its bugs.
>
> And this actually endangers these other projects by forbidding their
> developers from concentrating on actual productive work. Cocoon with all
> its dependencies is certainly an extreme use case for Maven compared to
> all others, and broken builds led some of Cocoon's major contributors to
> not even try 2.2 for months. And now we're wondering if users will even
> be able to build Cocoon if they dare to download it. The project is in
> danger.
>
> I discussed with several people from other projects at ApacheCon and
> they all report the same kind of problems: non-repeatability of builds.
> It works one day, but not the day after without anything having changed.
>
> Maven has gained a lot of mindshare because everybody's talking about
> it. Does everybody talk about their Ant build system? No, because it
> just works.
Given Mr. Mazzocchi's principle above, I'll take this opportunity to
introduce a principle from the American South (at least I think that's
where it's from)... anyway...
The "If it ain't broke, don't fix it" Principle. Ant has just worked
in the past, I wasn't around or probably smart enough to understand
why the move to maven but I can say from a user perspective it "don't
work". I'm over at forrest and, for learning purposes, like to
maintain a buildable trunk of Cocoon. That has been impossible since
the move to maven. I obviously understand that progress happens in
the face of this principle, but there are some cases where it should
be respected.
On a side note, I use the Cocoon code to learn forrest internals and
that task has even been increasingly more difficult since the
directory restructoring, which seems random at best.
As you proceed with this discussion, I hope you'll appreciate that
there are indirect/non-cocooners who are effected by the decisions you
make... Anyway, just another perspective...
And, thanks too:)
--tim
Re: [RANT] This Maven thing is killing us....
Posted by Sylvain Wallez <sy...@apache.org>.
Carsten Ziegeler wrote:
> Now, m2 is theoretically a very good tool :)
Stefano principle: you need good ideas and bad code to grow a community.
The application of this principle in Maven is different than usual, as
it forces other projects (and not only its own developers) to endure the
consequences of its bugs.
And this actually endangers these other projects by forbidding their
developers from concentrating on actual productive work. Cocoon with all
its dependencies is certainly an extreme use case for Maven compared to
all others, and broken builds led some of Cocoon's major contributors to
not even try 2.2 for months. And now we're wondering if users will even
be able to build Cocoon if they dare to download it. The project is in
danger.
I discussed with several people from other projects at ApacheCon and
they all report the same kind of problems: non-repeatability of builds.
It works one day, but not the day after without anything having changed.
Maven has gained a lot of mindshare because everybody's talking about
it. Does everybody talk about their Ant build system? No, because it
just works.
Sylvain
--
Sylvain Wallez - http://bluxte.net
Re: [RANT] This Maven thing is killing us....
Posted by Reinhard Poetz <re...@apache.org>.
Ralph Goers wrote:
> We've been using Maven 1 successfully for a couple of years. We want to
> upgrade to Maven 2 but can't until I (or someone) fixes
> http://jira.codehaus.org/browse/MNG-1577.
> <http://jira.codehaus.org/browse/MNG-1577> However, I suspect that we
> would be having the same problems as the Cocoon builds are currently
> experiencing if we were always trying to go to an external repository.
Within your company network you always have the option of running your own Maven
proxy repository. This way you don't rely on public repos anymore because the
first person that adds some dependency automatically puts this into the proxy
repo when trying out his change.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
___________________________________________________________
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de
Re: [RANT] This Maven thing is killing us....
Posted by Ralph Goers <Ra...@dslextreme.com>.
Reinhard Poetz wrote:
> Ralph Goers wrote:
>>
>>
>> Bertrand Delacretaz wrote:
>>
>>> On 7/1/06, Ralph Goers <Ra...@dslextreme.com> wrote:
>>>
>>>> ...I know in my case our Configuration Management folks have come
>>>> to love
>>>> Maven and the repository concept as it gives them total control over
>>>> when the third party components are updated....
>>>
>>>
>>> But they carefully manage their own repository, right?
>>>
>>> I think the problems come mostly when relying on public repositories.
>>>
>>> -Bertrand
>>
>> Absolutely, true. So our goal should be to make it easy for them to
>> build their own private repository. Unfortunately, this is really
>> something Maven should be providing, not Cocoon. For example, it
>> would be great to go to the main Cocoon directory and run "mvn
>> repository:build" and have all the artifacts copied to the internal
>> repository (if you have permission of course).
>
> ??? you already get your private repo which is called local
> repository. Just wondering why you're proposing this as I know that
> you know how Maven works ...
>
> If you and your company don't want to rely on a public repo, then use
> the Maven proxy repository.
I've never heard of a proxy repository. I'll look into it. Instead, we
have a private repository that is manually constructed. Actually, we
have two. The first is managed by developers and artifacts are added as
needed by pretty much anybody - this is where the proxy could work. The
second is managed by our Configuration Management team. Stuff can only
be put there by them and that will only happen if our release turnover
document specifically identifies it.
Ralph
Re: [RANT] This Maven thing is killing us....
Posted by Reinhard Poetz <re...@apache.org>.
Ralph Goers wrote:
>
>
> Bertrand Delacretaz wrote:
>
>> On 7/1/06, Ralph Goers <Ra...@dslextreme.com> wrote:
>>
>>> ...I know in my case our Configuration Management folks have come to
>>> love
>>> Maven and the repository concept as it gives them total control over
>>> when the third party components are updated....
>>
>>
>> But they carefully manage their own repository, right?
>>
>> I think the problems come mostly when relying on public repositories.
>>
>> -Bertrand
>
> Absolutely, true. So our goal should be to make it easy for them to
> build their own private repository. Unfortunately, this is really
> something Maven should be providing, not Cocoon. For example, it would
> be great to go to the main Cocoon directory and run "mvn
> repository:build" and have all the artifacts copied to the internal
> repository (if you have permission of course).
??? you already get your private repo which is called local repository. Just
wondering why you're proposing this as I know that you know how Maven works ...
If you and your company don't want to rely on a public repo, then use the Maven
proxy repository.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
___________________________________________________________
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: [RANT] This Maven thing is killing us....
Posted by Ralph Goers <Ra...@dslextreme.com>.
Bertrand Delacretaz wrote:
> On 7/1/06, Ralph Goers <Ra...@dslextreme.com> wrote:
>
>> ...I know in my case our Configuration Management folks have come to
>> love
>> Maven and the repository concept as it gives them total control over
>> when the third party components are updated....
>
> But they carefully manage their own repository, right?
>
> I think the problems come mostly when relying on public repositories.
>
> -Bertrand
Absolutely, true. So our goal should be to make it easy for them to
build their own private repository. Unfortunately, this is really
something Maven should be providing, not Cocoon. For example, it would
be great to go to the main Cocoon directory and run "mvn
repository:build" and have all the artifacts copied to the internal
repository (if you have permission of course).
Ralph
Re: [RANT] This Maven thing is killing us....
Posted by Bertrand Delacretaz <bd...@apache.org>.
On 7/1/06, Ralph Goers <Ra...@dslextreme.com> wrote:
> ...I know in my case our Configuration Management folks have come to love
> Maven and the repository concept as it gives them total control over
> when the third party components are updated....
But they carefully manage their own repository, right?
I think the problems come mostly when relying on public repositories.
-Bertrand
Re: [RANT] This Maven thing is killing us....
Posted by Ralph Goers <Ra...@dslextreme.com>.
We've been using Maven 1 successfully for a couple of years. We want to
upgrade to Maven 2 but can't until I (or someone) fixes
http://jira.codehaus.org/browse/MNG-1577.
<http://jira.codehaus.org/browse/MNG-1577> However, I suspect that we
would be having the same problems as the Cocoon builds are currently
experiencing if we were always trying to go to an external repository.
I've even seen this with our local repository if the web server is
having problems.
Rather than packaging a "lib" directory, it would make more sense to me
if we had a downloadable maven repository that contains only what is
needed to build Cocoon. This could then be used to set up the internal
repository. Unfortunately, this doesn't solve all the problems as every
time some new component is required the internal repository doesn't
automatically get updated.
I know in my case our Configuration Management folks have come to love
Maven and the repository concept as it gives them total control over
when the third party components are updated.
Ralph
Carsten Ziegeler wrote:
> Bertrand Delacretaz wrote:
>
>> -Allow Cocoon users to add their own jars to the build in the old way
>> (lib directory), without forcing them to use Maven for that
>>
>>
> I think this is the most interesting point. We could try to push maven
> to allow this...would be fun to see what they think. Seriously, I think
> if this would be possible with m2, things would be much easier.
> And we could add all ours libs this way and forget about the m2
> dependency stuff for now.
>
> In addition I think we should force the m2 people to make transitive
> dependency optional. I tried this once but never succeeded.
>
> Carsten
>
>
Re: [RANT] This Maven thing is killing us....
Posted by Ralph Goers <Ra...@dslextreme.com>.
Bertrand Delacretaz wrote:
> I didn't realize it before this week, but if we don't allow this we
> force our users to put all of their dependencies in Maven.
>
> OTOH, if people can add their own jars in the plain old way, they
> benefit from the M18n of Cocoon (assuming it works...) without having
> to learn much about it. The suits would say "win-win" at this point.
>
> -Bertrand
Not really. I'd put money down that user's will go crazy trying to
figure out why the jar they put in the lib directory isn't being used -
or why Cocoon doesn't run properly because it is being used. With a
multi-project framework/product like Cocoon you need to insure that
everything gets built with the same versions and that is what gets used
at runtime. Unfortunately, Maven 2 doesn't really provide a good way to
do that yet (Maven 1 does though). Remember, ideally the end user will
build a single block with a pom.xml. It will depend on some Cocoon
blocks (i.e. a pom.xml with transitive dependencies and a jar) and
perhaps some other things. So when all these parts get put together
they need to have been built with the same stuff or nothing is
guaranteed to work correctly.
Ralph
Re: [RANT] This Maven thing is killing us....
Posted by Jorg Heymans <jh...@domek.be>.
Simone Gianni wrote:
> I don't know if what I've done is a good work or not, I will commit it
> in a single revision so that it's easy to roll back it in case I made
> mistakes.
If you're unsure you can send me the patch and i'll have a look at it.
Otherwise just commit and we'll deal with things afterwards :)
> Things I find more annoying in maven are the following :
> - If it fails a download, it simply abort the build, every network
> application knows that a temporary problem on a network can happen, and
> I think maven should try to redownload the file a couple of times (using
> range download would be cool too) before simply giving up. It's so
> simple to implement, and would solve so many problems, that I really
> cannot understand why it's not there anymore.
totally agree.
> - There is no GUI support (if you know any please point them out) since
> mavenide for eclipse is only for maven 1.0.
>
http://maven.apache.org/eclipse-plugin.html , never used it though.
Jorg
Re: [RANT] This Maven thing is killing us....
Posted by Simone Gianni <s....@thebug.it>.
Hi all,
after a weekend of fights, I managed to have all projects (yes, all the
blocks) loaded in eclipse with only 4 errors, which are actually not
real errors. This involved the following operations :
- Adding some dependencies in pom.xml files, in particular :
... Some blocks didn't included junit
... Many blocks didn't have a dependency to core
... A couple of blocks needed many more dependencies (osgi, spring,
avalon, servlet api etc..)
- Changing some packages : we had some
src/java/<somethinghere>/org/apache... folders (mocks mainly) that are
not accepted in maven since it searches for src/main/java/org/apache...
- The eclipse maven plugin quite often does not add the dependency to
core in the eclipse project, althought it's there in the pom.xml file.
- The eclipse maven plugin quite often adds a duplicate dependency to
core, since in the pom there are two dependencies one of which is marked
for tests only.
I don't know if what I've done is a good work or not, I will commit it
in a single revision so that it's easy to roll back it in case I made
mistakes.
In general, my opinion is that :
- Yes, public repositories are a problem, having some control over it
would be useful.
- Yes, we should find a way to add jars not mavenizing stuff from other
projects (see my previous mail about dojo).
- No, we should not move away from maven, at least not for 2.2, because
that would mean not only throw away a lot of work, but also because
maven is a good idea and is an apache product and I think we should
cooperate with the maven team to achieve our common goals.
Things I find more annoying in maven are the following :
- If it fails a download, it simply abort the build, every network
application knows that a temporary problem on a network can happen, and
I think maven should try to redownload the file a couple of times (using
range download would be cool too) before simply giving up. It's so
simple to implement, and would solve so many problems, that I really
cannot understand why it's not there anymore.
- Negative caching : I'm tired of seeing 20 HTTP requests go out
searching for the spring 2.0 RC1 poms which simply does not exist, Maven
should cache negative response to avoid this waste of time.
- Caching in general : there are many similar technologies out there
(linux distros for example, portage for gentoo and dpackage for
debian/ubuntu), and they all relay on having a local copy of the
repository metadata. This greatly improves performances, since
connections to the server are made only to fetch actual payload (jars)
and not to verify if a file is there. Ibiblio currently list 609
"packages" (nothing compared to the thousands of any linux distro), even
only listing existing artifacts in a string form would result in a text
file with a few thousand lines, which zipped would not exceed a few
hundred KB, and would avoid all those useless HTTP requests on the
servers to see if something is there or not. Again, this is so simple
and so effective that I really don't understand why maven team decided
for the current obsolete approach that linux distros dropped years ago.
- There is no GUI support (if you know any please point them out) since
mavenide for eclipse is only for maven 1.0.
Why don't we prepare a mail for the maven team explaining them our
concerns about maven and asking for solutions to our biggest problems?
Simone
--
Simone Gianni
Re: [RANT] This Maven thing is killing us....
Posted by Bertrand Delacretaz <bd...@apache.org>.
On 7/1/06, Carsten Ziegeler <cz...@apache.org> wrote:
> ....Bertrand Delacretaz wrote:
> > -Allow Cocoon users to add their own jars to the build in the old way
> > (lib directory), without forcing them to use Maven for that
> >
> I think this is the most interesting point. We could try to push maven
> to allow this...would be fun to see what they think...
I didn't realize it before this week, but if we don't allow this we
force our users to put all of their dependencies in Maven.
OTOH, if people can add their own jars in the plain old way, they
benefit from the M18n of Cocoon (assuming it works...) without having
to learn much about it. The suits would say "win-win" at this point.
-Bertrand
Re: [RANT] This Maven thing is killing us....
Posted by Carsten Ziegeler <cz...@apache.org>.
Bertrand Delacretaz wrote:
> -Allow Cocoon users to add their own jars to the build in the old way
> (lib directory), without forcing them to use Maven for that
>
I think this is the most interesting point. We could try to push maven
to allow this...would be fun to see what they think. Seriously, I think
if this would be possible with m2, things would be much easier.
And we could add all ours libs this way and forget about the m2
dependency stuff for now.
In addition I think we should force the m2 people to make transitive
dependency optional. I tried this once but never succeeded.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: [RANT] This Maven thing is killing us....
Posted by Jorg Heymans <jh...@domek.be>.
Bertrand Delacretaz wrote:
> -Use our own/ASF repository, managed in SVN
>
> -Make this the default repository, using ASF mirrors (might need some
> changes to Maven IIUC), and using a snapshot repository in second
> priority
i suggest you join repository@a.o and discuss this there.
> -Find a way to have Maven check the integrity of all downloaded jars,
> md5 or something
maven does this already.
Jorg
Re: [RANT] This Maven thing is killing us....
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
On 7/1/06, Carsten Ziegeler <cz...@apache.org> wrote:
> ...what
> about settings up a Cocoon M2 repository where we host all our
> dependencies and this is the default repository you're using when you're
> developing with Cocoon...
Without knowing much about how Maven works today, my impression is
that the best thing might be to have the ASF run its own repository
(IIUC it is not the case now), under strict version control, mirrored,
etc.
I am travelling now and will be mostly offline until Monday, but here
are some additional thoughts about a possible solution:
-Use our own/ASF repository, managed in SVN
-Make this the default repository, using ASF mirrors (might need some
changes to Maven IIUC), and using a snapshot repository in second
priority
-Find a way to have Maven check the integrity of all downloaded jars,
md5 or something
-Allow Cocoon users to add their own jars to the build in the old way
(lib directory), without forcing them to use Maven for that
Just some random thoughts at this point...
-Bertrand
Re: [RANT] This Maven thing is killing us....
Posted by Upayavira <uv...@odoko.co.uk>.
Simone Gianni wrote:
>
> Niclas Hedhman wrote:
>
>> What happens *if* Mergere runs out of juice and flip the switch off?
>>
>>
> IIUC, maven repos are nothing more than HTTP servers, and SVN is
> accessible thru HTTP, so we can create a folder named "repository" in
> our svn repo, copy the folders of artifacts we need from ibiblio, and
> have complete control over it. This is technically possible (and would
> also solve maaaaaaaany other problems), but does not solve the legal
> stuff maven repos solve about redistributing others work.
A good idea, but I can't see any way in which infrastructure would allow
this.
That is because it would prevent any useful partitioning of resources.
Maven is likely to become a resource hog, and could easily bring SVN
down to its knees. Much better that it only be the MVN repo that goes
down at such a time, and not our SVN repo too.
Upayavira
Re: [RANT] This Maven thing is killing us....
Posted by Simone Gianni <s....@thebug.it>.
Niclas Hedhman wrote:
>What happens *if* Mergere runs out of juice and flip the switch off?
>
>
IIUC, maven repos are nothing more than HTTP servers, and SVN is
accessible thru HTTP, so we can create a folder named "repository" in
our svn repo, copy the folders of artifacts we need from ibiblio, and
have complete control over it. This is technically possible (and would
also solve maaaaaaaany other problems), but does not solve the legal
stuff maven repos solve about redistributing others work.
Simone
--
Simone Gianni
Re: [RANT] This Maven thing is killing us....
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Monday 03 July 2006 01:29, Jorg Heymans wrote:
> I just spoke to Jason, he mentioned that ibiblio will go away soon.
>
That statement actually worries me quite a lot. AFAIU, the "central" repo is
going to Mergere (a VC funded company) sponsored host(s). And this/these
host(s) have to me shown to be VERY fragile. Often requests fails, even with
the standard browser.
What happens *if* Mergere runs out of juice and flip the switch off?
Cheers
Niclas
Re: [RANT] This Maven thing is killing us....
Posted by Jorg Heymans <jh...@domek.be>.
Carsten Ziegeler wrote:
> Especially the unpredictable results and the not reproduciable builds
> are imho a real problem. You build today, it works, you build tomorrow
> and it does not. And this occurs on some machines even if nothing has
> changed and even if you build in offline mode! Which is really really
> strange.
>
> Now, m2 is theoretically a very good tool :) It seems that most problems
> occur because of weak poms in the repositories we are using and that
> people are updating poms in the repositories without changing the
> version number. In addition we have problems with snapshots we are
> depending on as they are not available in public repositories.
>
it helps to zap your local repo every now and then. There is no way as
of yet to force maven to redownload poms it has already (MNG-1258). Poms
*are* being updated without version number increment even though they
shouldn't.
> Without thinking about the bandwidth problem this might create, but what
> about settings up a Cocoon M2 repository where we host all our
> dependencies and this is the default repository you're using when you're
> developing with Cocoon.
> I'm not sure if this is a good idea, because of bandwidth and perhaps
> legal issues and it might create confusion when it comes to find out
> what's the difference between a version hosted in our repository and the
> one hosted on the official one is.
I just spoke to Jason, he mentioned that ibiblio will go away soon.
If we decide to host our own repo then we should do so *only* for
bandwith and connectivity reasons. Not with the goal of managing our own
version of other projects' poms.
Jorg