Re: [RANT] This Maven thing is killing us....
Carlos Sanchez wrote: Yes you can, it's not the best way to do it but you can, by adding explicitly the dependency with the versoin you want to your pom. In the very worst case you have to add all transitive deendencies to your pom, like in Maven 1. That is so impractical as to be nonsensical. Our Configuration Management folks require that all projects use the same dependencies from the top to the bottom. For example, we build our base set of frameworks with one multiproject build, then a higher level of frameworks, and then finally the product itself. Each of these must be built and unit tested with the same third party jars. Furthermore, the product can consist of a war and one or more ejb's which may all be packaged in an ear. These must also all have all the same versions of the jars. The solution you propose makes that tedious, error prone, and would require our CM folks to manually inspect every pom to insure nothing is done improperly. At least with Maven 1 we can have a build.properties that all projects share. In our case, the ideal solution in Maven 2 would be to have a master pom with nothing in it but a dependencyManagement section (with something like override=true set as an attribute) that all our projects would reference. Ralph
Re: [RANT] This Maven thing is killing us....
Brett Porter wrote: The first thing I'd suggest is for those having problems to try another mirror. I know requiring everyone to do that is a pain and not a long term solution, but I'd like to see how much that reduces the problem. I'm not sure if the following problem has already been mentioned in this thread as somehow my mail client messed up :( We experience problems like the build is working on one machine while not on another one. The reason for this is changing poms on the public repository! M2 does not recognize when a pom is changed on the repository, so once you have a pom for a dependency it's never updated. If now someone builds before the update he has the old version while someone who builds after the update for the first time, gets the new version. And this is exactly the reason why on some machines our build works (they have the new version of a dependency which brings in other transitive dependencies). It took us some time to recognize this as one of the main problems. Obviously, a pom in a public repository should never change, but as there are faulty poms out there, these need to be fixed. So its very likely that this will still happen in the future. So it would be good if m2 could detect changes in the pom and then update the local version. This would at least solve most of our problems. I'm still thinking that adding a switch turn off transitive dependency handling would be a nice think as then you really control what you get without adding excludes all over the place. And it seems that m2 is trying to get poms for snapshots even in offline mode (haven't checked if this is filed as a bug already) and more important it downloads snapshot versions from the repository although a newer version of the snapshot is in the local repository. And the interesting thing is, that although a version has been downloaded, the local one is later on used. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [RANT] This Maven thing is killing us....
Brett Porter wrote: It depends on how you use them as to the best solution here. I assume that they are customised for cocoon, so they shouldn't be considered to be the same as the original. In that case, I'd suggest you release them under your own groupID (maybe org.apache.cocoon.thirdparty) so that they don't conflict (bearing in mind that someone will transitively receive both that and the original if they are both used). I'm assuming this isn't the case as you are only bundling these modified versions into a distributable app, not as part of a reusable component? Hope this helps, Brett Actually, I'm not exactly sure why non-released jars are currently included, but I'm almost certain that in most cases it is not because it is customized for Cocoon. In looking in our latest 2.1.9 release (which isn't built with Maven) I see that jcs, chaperon, jackrabbit, deli, dojo, jing, joost, myfaces, poi, wsrp4j, xmldb and xreporter were all included in the release from some interim version that is probably unknown to those projects. I suspect for many of them this was done because they included critical fixes. Since Cocoon contains so many third party jars we would either have to make releases knowing that some things are broken or never put out a release. However, your point about naming them o.a.c.thirdparty is well taken (at least by me). A complaint I frequently have had is that it is often difficult to locate the exact source that was used to create the jar. Sometimes they are named with the svn revision with makes it easy. Sometimes they have a datestamp, which isn't necessarily guaranteed to get you the exact source, and sometimes they have a name like wsrp4j-shared-0.3-dev.jar (wsrp4j is in inclubator and I don't believe it has ever done a release, but this version number is really bad since there is no tag in svn matching 0.3-dev that I can see). In wsrp4j's case, I'm fairly sure Cocoon's usage of it is considered experimental - it gives users a way to have early access to it for experimentation purposes. Ralph
Re: [RANT] This Maven thing is killing us....
Thanks Carsten. The first part was certainly already discussed (so you can see it in the mail archives). It'd be good if you could file bugs for the last 3 things and we can schedule them for upcoming releases. - Brett On 5/07/2006 4:45 PM, Carsten Ziegeler wrote: Brett Porter wrote: The first thing I'd suggest is for those having problems to try another mirror. I know requiring everyone to do that is a pain and not a long term solution, but I'd like to see how much that reduces the problem. I'm not sure if the following problem has already been mentioned in this thread as somehow my mail client messed up :( We experience problems like the build is working on one machine while not on another one. The reason for this is changing poms on the public repository! M2 does not recognize when a pom is changed on the repository, so once you have a pom for a dependency it's never updated. If now someone builds before the update he has the old version while someone who builds after the update for the first time, gets the new version. And this is exactly the reason why on some machines our build works (they have the new version of a dependency which brings in other transitive dependencies). It took us some time to recognize this as one of the main problems. Obviously, a pom in a public repository should never change, but as there are faulty poms out there, these need to be fixed. So its very likely that this will still happen in the future. So it would be good if m2 could detect changes in the pom and then update the local version. This would at least solve most of our problems. I'm still thinking that adding a switch turn off transitive dependency handling would be a nice think as then you really control what you get without adding excludes all over the place. And it seems that m2 is trying to get poms for snapshots even in offline mode (haven't checked if this is filed as a bug already) and more important it downloads snapshot versions from the repository although a newer version of the snapshot is in the local repository. And the interesting thing is, that although a version has been downloaded, the local one is later on used. Carsten -- Brett Porter [EMAIL PROTECTED] Apache Maven - http://maven.apache.org/ Better Builds with Maven - http://library.mergere.com/
Re: [RANT] This Maven thing is killing us....
Hi Ralph,
You've got a general versioning problem here, and you'll find the answer
to how do I do this with Maven? will be more straightforward once
considering the question of how you should generally deal with them. As
you've said, this is already a problem for you as you don't know where
they really came from.
Ignoring Maven for a moment, there's a couple of questions I'd consider
(bear in mind I'm not a Cocoon user so I may be misunderstanding how
they eventually get used):
- how would a user that used one of these dependencies themselves in
addition to that Cocoon component select which version of the dependency
to use? Would they use the Cocoon-supplied one, one they select, or both?
- are the changes Cocoon specific? Will you always be using a custom
release, or will you pick up the next release when it is available?
There are a couple of options for addressing this use case in Maven.
- include the JARs in SVN, and reference it as an additional repository
file://localhost/${basedir}/extra-jar-repo
- host your own repository of these artifacts (this is basically
equivalent to the above and probably easier to work with, and could be
accommodated in a general ASF repository of such things, once taking
into account the licensing guidelines)
- ask projects to do a beta/point release for you (it should be easy to
make a case for this if the version you are using is both stable and
contains critical fixes)
- fork the code (taking into consideration licensing guidelines)
either temporarily or permanently in your own repository (ie
http://svnbook.red-bean.com/nightly/en/svn.advanced.vendorbr.html). Make
it part of your build, and do the custom group ID thing. We really need
the provides functionality planned for Maven 2.1 to make this feasible
if it is intended to be a drop in replacement of the original JAR (so
that you don't get duplicates in the dependency chain), but it can
certainly work.
BTW, I also think we need specific support for this type of artifact (it
is essentially a vendor release), and it is under consideration for
Maven 2.1.
Your point about never being a Cocoon release while waiting for
dependencies to release is something I'm familiar with and there's
definitely a need for this. However, is it possible to reduce the impact
of it by being able to release individual components at different times
so that they can track the release cycles of their dependencies? This
sounds very similar to the scenario of Maven plugins, where it works
quite successfully.
HTH,
Brett
On 5/07/2006 4:49 PM, Ralph Goers wrote:
Brett Porter wrote:
It depends on how you use them as to the best solution here. I assume
that they are customised for cocoon, so they shouldn't be considered
to be the same as the original. In that case, I'd suggest you release
them under your own groupID (maybe org.apache.cocoon.thirdparty) so
that they don't conflict (bearing in mind that someone will
transitively receive both that and the original if they are both
used). I'm assuming this isn't the case as you are only bundling these
modified versions into a distributable app, not as part of a reusable
component?
Hope this helps,
Brett
Actually, I'm not exactly sure why non-released jars are currently
included, but I'm almost certain that in most cases it is not because it
is customized for Cocoon. In looking in our latest 2.1.9 release (which
isn't built with Maven) I see that jcs, chaperon, jackrabbit, deli,
dojo, jing, joost, myfaces, poi, wsrp4j, xmldb and xreporter were all
included in the release from some interim version that is probably
unknown to those projects. I suspect for many of them this was done
because they included critical fixes. Since Cocoon contains so many
third party jars we would either have to make releases knowing that some
things are broken or never put out a release.
However, your point about naming them o.a.c.thirdparty is well taken (at
least by me). A complaint I frequently have had is that it is often
difficult to locate the exact source that was used to create the jar.
Sometimes they are named with the svn revision with makes it easy.
Sometimes they have a datestamp, which isn't necessarily guaranteed to
get you the exact source, and sometimes they have a name like
wsrp4j-shared-0.3-dev.jar (wsrp4j is in inclubator and I don't believe
it has ever done a release, but this version number is really bad since
there is no tag in svn matching 0.3-dev that I can see). In wsrp4j's
case, I'm fairly sure Cocoon's usage of it is considered experimental -
it gives users a way to have early access to it for experimentation
purposes.
Ralph
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Brett Porter [EMAIL PROTECTED]
Apache Maven - http://maven.apache.org/
Better Builds with Maven - http://library.mergere.com/
Re: [RANT] This Maven thing is killing us....
On 7/5/06, Ralph Goers [EMAIL PROTECTED] wrote: Carlos Sanchez wrote: Yes you can, it's not the best way to do it but you can, by adding explicitly the dependency with the versoin you want to your pom. In the very worst case you have to add all transitive deendencies to your pom, like in Maven 1. That is so impractical as to be nonsensical. Our Configuration Management folks require that all projects use the same dependencies from the top to the bottom. For example, we build our base set of frameworks with one multiproject build, then a higher level of frameworks, and then finally the product itself. Each of these must be built and unit tested with the same third party jars. Furthermore, the product can consist of a war and one or more ejb's which may all be packaged in an ear. These must also all have all the same versions of the jars. The solution you propose makes that tedious, error prone, and would require our CM folks to manually inspect every pom to insure nothing is done improperly. At least with Maven 1 we can have a build.properties that all projects share. In our case, the ideal solution in Maven 2 would be to have a master pom with nothing in it but a dependencyManagement section (with something like override=true set as an attribute) that all our projects would reference. so... you can do it. In m1 anybody can override the build.properties as in m2 they can put a different version. i'm not saying it's the right solution but while is not implemented you can still do it. There's a limited number of hours in the day to do all the things we want to do ;) Ralph -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride
Re: [RANT] This Maven thing is killing us....
Carlos Sanchez wrote: so... you can do it. In m1 anybody can override the build.properties as in m2 they can put a different version. Pardon me for going on and on about this, but the reality is that, at least in my organization, anybody cannot override the build.properties. When our CM team gets a release they will use the correct build.properties and your project damn well better build with it. If a new or upgraded third party jar is required it has to be explicitly called out in the release documentation. i'm not saying it's the right solution but while is not implemented you can still do it. There's a limited number of hours in the day to do all the things we want to do ;) This part I understand! ;-) Ralph
RE: [RANT] This Maven thing is killing us....
I made some noise a few months ago about the repository poms. There are 3 or 4 issues currently in JIRA regarding this. I also agree that it is an issue. http://jira.codehaus.org/browse/MNG-1954 Ruel Loehr JBoss QA -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 04, 2006 10:13 AM To: Maven Developers List Cc: dev@cocoon.apache.org Subject: Re: [RANT] This Maven thing is killing us On 4/07/2006 9:34 PM, Torsten Curdt wrote: I agree that the whole maven2 situation is currently far less than just acceptable ...but TBH I am not sure the maven team is (or was?) really aware of all the problems we have. Not until you forwarded a message (and thanks for doing so). We don't really have the bandwidth to follow along with everyone that is converting builds... Maybe we can get a statement on the maven self-update and unreliable-messed-up-repository situation. From what it sounds they are working on it. So let's not work this out in our little cocoon corner but let's hear what they have to say. I think we all recognise there are some issues, particularly with ibiblio dropping out consistently, and also issues with transitivity and versioning that have been raised on the [EMAIL PROTECTED] thread. I'm not sure what messed up repository issues you are having, but would like to hear about it. I know this stuff needs a good hard looking at, but I don't believe there is anything insurmountable here. - Brett -- Brett Porter [EMAIL PROTECTED] Apache Maven - http://maven.apache.org/ Better Builds with Maven - http://library.mergere.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.9.9/382 - Release Date: 7/4/2006 -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.9.9/382 - Release Date: 7/4/2006
Re: [RANT] This Maven thing is killing us....
Ralph Goers wrote: Carlos Sanchez wrote: Yes you can, it's not the best way to do it but you can, by adding explicitly the dependency with the versoin you want to your pom. In the very worst case you have to add all transitive deendencies to your pom, like in Maven 1. That is so impractical as to be nonsensical. Our Configuration Management folks require that all projects use the same dependencies from the top to the bottom. For example, we build our base set of frameworks with one multiproject build, then a higher level of frameworks, and then finally the product itself. Each of these must be built and unit tested with the same third party jars. Furthermore, the product can consist of a war and one or more ejb's which may all be packaged in an ear. These must also all have all the same versions of the jars. The solution you propose makes that tedious, error prone, and would require our CM folks to manually inspect every pom to insure nothing is done improperly. At least with Maven 1 we can have a build.properties that all projects share. In our case, the ideal solution in Maven 2 would be to have a master pom with nothing in it but a dependencyManagement section (with something like override=true set as an attribute) that all our projects would reference. FYI, using the maven tasks in ant, I create my own pom files based on the values in a shared properties file. The poms are then fed in to the tasks and used to publish the artifacts themselves. This lets me do two things -have a single library.properties file to control the version of things -have developer-specific build.properties driven overrides of versions, and know that those versions get picked up everywhere. This isn't a perfect process, as it is fairly verbose, but it does ensure consistency. It would be easier with a task that did both the pom file creation and path setup in one go. I run the tasks with verbose=true so I get to see what is happening w.r.t dependency inference, something like this: ready-to-declare-classpaths: core-libraries: unspecified:unspecified:jar:0.0 (selected) commons-lang:commons-lang:jar:2.1 (selected) commons-logging:commons-logging:jar:1.0.4 (selected) log4j:log4j:jar:1.2.6 (selected) log4j:log4j:jar:1.2.6 (removed - nearer found: 1.2.13) log4j:log4j:jar:1.2.13 (selected) smartfrog-modules-classpath: unspecified:unspecified:jar:0.0 (selected) org.smartfrog:sf-cdl:jar:3.08.steve-private (selected) [m2:libraries] [INFO] snapshot org.ggf:cddlm:ggf16-SNAPSHOT: checking for updates from remote org.ggf:cddlm:jar:ggf16-SNAPSHOT (selected) commons-logging:commons-logging-api:jar:1.0.4 (selected) org.smartfrog:sf-xml:jar:3.08.steve-private (selected) xerces:xmlParserAPIs:jar:2.6.2 (selected) xerces:xercesImpl:jar:2.6.2 (selected) xom:xom:jar:1.1 (selected) xom:xom:jar:1.0b3 (removed - causes a cycle in the graph) jaxen:jaxen:jar:1.1-beta-8 (selected) org.smartfrog:sf-www:jar:3.08.steve-private (selected) org.smartfrog:sf-m32:jar:3.08.steve-private (selected) commons-httpclient:commons-httpclient:jar:3.0 (selected) commons-codec:commons-codec:jar:1.2 (selected) servletapi:servletapi:jar:2.3 (selected) xerces:xmlParserAPIs:jar:2.6.2 (selected) xom:xom:jar:1.1 (selected) xom:xom:jar:1.0b3 (removed - causes a cycle in the graph) jaxen:jaxen:jar:1.1-beta-8 (selected) xerces:xercesImpl:jar:2.6.2 (selected) org.smartfrog:sf-jetty:jar:3.08.steve-private (selected) org.smartfrog:sf-loggingservices:jar:3.08.steve-private (selected) org.smartfrog:smartfrog:jar:3.08.steve-private (selected) log4j:log4j:jar:1.2.13 (selected) org.smartfrog:sf-xml:jar:3.08.steve-private (selected) smartfrog-core-classpath: unspecified:unspecified:jar:0.0 (selected) org.smartfrog:smartfrog:jar:3.08.steve-private (selected) org.smartfrog:sfServices:jar:3.08.steve-private (selected) jetty-classpath: unspecified:unspecified:jar:0.0 (selected) jetty:jetty:jar:4.2.24 (selected) servletapi:servletapi:jar:2.3 (selected) declare-compile.classpath: declare-exec.classpath: smartfrog-testharness-classpath: unspecified:unspecified:jar:0.0 (selected) org.smartfrog:sf-testharness:jar:3.08.steve-private (selected) unspecified:unspecified:jar:0.0 (selected) org.smartfrog:sf-testharness:jar:3.08.steve-private (selected) junit:junit:jar:3.8.1 (selected) Everything with steve-private is tagged as a release for me only; built locally and never saved up to the net. I am just using the local cache as a way of sharing artifacts. One problem with this (ant-centric, obviously) approach is that I'm building up multiple graphs of dependencies, and the version logic only works in the scope of one graph, but ant lets me merge them. In an ideal world, you'd have the ability to merge two dependency graphs and have the resolution thing kick in again. I suppose if I had a separate pom for each path I
Re: RE: [RANT] This Maven thing is killing us....
On 7/4/06, Torsten Curdt [EMAIL PROTECTED] wrote: ...I would be good to summarize all the pain points and post them over in maven land... Agreed. I'm a bit drowning in stuff since I got back for ApacheCon, will try to summarize but if someone else has more time, please go for it. -Bertrand
Re: RE: [RANT] This Maven thing is killing us....
Sorry, for the cross-post ...but it seems we need a dialog here somehow. We now have two threads on two different mailing lists/communities that really should talk to each other. I propose to commit again all JARs into, say, cocoon/trunk/m2repo and then tell Maven at build time to use that directory in the checkout area as first repository server in the search list. So where is the big difference? For every fresh checkout you download the jars from subversion. Guys I have no solution at hand but let's not throw out the baby with the bath water. I would be good to summarize all the pain points and post them over in maven land. The pain being so bad that we are (somehow) considering going back to ant should be alarming enough. Another point seems to be forgotten in this discussion so far - the legal aspects of distributing jars. Does the ASF want to re-distribute 3rd party jars? Plus: based on a chat Sylvain and me had with Cliff during ApacheCon it seems we could have blocks providing bridging code to LGPL ...as long as we do not provide the jar and the block is optional. (Sylvain, did I summarize that correctly?) I agree that the whole maven2 situation is currently far less than just acceptable ...but TBH I am not sure the maven team is (or was?) really aware of all the problems we have. Maybe we can get a statement on the maven self-update and unreliable-messed-up-repository situation. From what it sounds they are working on it. So let's not work this out in our little cocoon corner but let's hear what they have to say. cheers -- Torsten
Re: [RANT] This Maven thing is killing us....
Torsten Curdt wrote: Another point seems to be forgotten in this discussion so far - the legal aspects of distributing jars. Does the ASF want to re-distribute 3rd party jars? Plus: based on a chat Sylvain and me had with Cliff during ApacheCon it seems we could have blocks providing bridging code to LGPL ...as long as we do not provide the jar and the block is optional. (Sylvain, did I summarize that correctly?) Yes. What Cliff said (warning: nothing official here!) is that we may allow _optional_ dependencies of ASF software on LGPL code. This is legally possible if we consider the LGPL dependency to be part of the environment of our software, i.e. a prerequisite for users that want to use these optional features. This consideration about environment is what allows commercial software to be built on the GPL'ed Linux operating system. However, to be legally clean, this requires the build system to be able to handle these prerequisites by not automatically downloading them from a remote repository. In simple words, that will require people to manually place the LGPL'ed jars in the equivalent of lib/local in Cocoon 2.1. Sylvain -- Sylvain Wallez - http://bluxte.net
Re: [RANT] This Maven thing is killing us....
Torsten Curdt wrote: Sorry, for the cross-post ...but it seems we need a dialog here somehow. We now have two threads on two different mailing lists/communities that really should talk to each other. I propose to commit again all JARs into, say, cocoon/trunk/m2repo and then tell Maven at build time to use that directory in the checkout area as first repository server in the search list. So where is the big difference? For every fresh checkout you download the jars from subversion. Guys I have no solution at hand but let's not throw out the baby with the bath water. I would be good to summarize all the pain points and post them over in maven land. The pain being so bad that we are (somehow) considering going back to ant should be alarming enough. Actually, speaking on behalf of the ant team, can I extend a big (tentative) welcome back :) Another point seems to be forgotten in this discussion so far - the legal aspects of distributing jars. Does the ASF want to re-distribute 3rd party jars? Plus: based on a chat Sylvain and me had with Cliff during ApacheCon it seems we could have blocks providing bridging code to LGPL ...as long as we do not provide the jar and the block is optional. (Sylvain, did I summarize that correctly?) There is always the option of a public yet locked down repository with the sun jars and/or the other external dependencies. Working on a sourceforge repo, we keep extra stuff under SCM, and have the dependency logic look there first. you could even have an SCM-managed repo on sourceforge or codehaus for this other stuff, though it would be a somewhat public admission that the main repository has failed. I agree that the whole maven2 situation is currently far less than just acceptable ...but TBH I am not sure the maven team is (or was?) really aware of all the problems we have. Maybe we can get a statement on the maven self-update and unreliable-messed-up-repository situation. From what it sounds they are working on it. So let's not work this out in our little cocoon corner but let's hear what they have to say. In a way, many of the stuff in M2 is experimental; a build tool that effectively encodes beliefs about how a project should be structured and delivered, focusing on component-based development instead of application dev. I also think its time to look at how well some of the experiment is working. Personally, I always experience a bit of fear when adding a new dependency to a project. the repository stuff, and estimate a couple of hours to get every addition stable, primarily by building up a good exclusion list. M2, and m2:libraries in ant, has changed the nature of the problem, from what versions of what things do I need with this? to how much of this stuff do I really need? and why are my junit tests not compiling with an error about assertTrue not being known, the latter seguing into where is junit3.7 coming from?. Its a form of progress, but still painful. Similarly, keeping a repository cache under SCM does at least give you a structured layout for storing multiple versions of stuff under SCM, with flick-of-a-switch access to new versions. It just adds an extra step pom creation/fixup to the process. Is it worse than before? Better? Or just, well, different? and if things are either worse or not as good as they could be, what can be changed? One underlying cause seems to be pom quality. Open source software dev is a vast collection of loosely coupled projects, and what we get in the repository in terms of metadata matches this model. Each project produces artifacts that match their immediate needs, with POM files that appear to work at the time of publishing. Maven then caches those and freezes that metadata forever, even if it turns out that the metadata was wrong. There's far better coherence within Gump, where the metadata is effectively maintained more by the gump team themselves than by the individual projects. Question is, what to do about it? And if the m2 repository was an attempt to leave the problems of the M1 repository behind, has it worked? -steve
Re: RE: [RANT] This Maven thing is killing us....
The repository is as good as the users/projects make it. There's no difference at all with using ant and including the wrong jars, maybe the problem is that how to fix it in maven is not as easy as in ant. If project A says it depends on B 1.0 and C says it depends on B 1.1, there's a conflict in Maven, Ant and anything you want to use, the difference is that Maven tries to do it for you, but you still can override that behaviour. Right now we are in a good position with a huge number of users trying and testing the metadata in the repository, and forcing projects to support maven by providing good data. On 7/4/06, Torsten Curdt [EMAIL PROTECTED] wrote: Sorry, for the cross-post ...but it seems we need a dialog here somehow. We now have two threads on two different mailing lists/communities that really should talk to each other. I propose to commit again all JARs into, say, cocoon/trunk/m2repo and then tell Maven at build time to use that directory in the checkout area as first repository server in the search list. So where is the big difference? For every fresh checkout you download the jars from subversion. Guys I have no solution at hand but let's not throw out the baby with the bath water. I would be good to summarize all the pain points and post them over in maven land. The pain being so bad that we are (somehow) considering going back to ant should be alarming enough. Another point seems to be forgotten in this discussion so far - the legal aspects of distributing jars. Does the ASF want to re-distribute 3rd party jars? Plus: based on a chat Sylvain and me had with Cliff during ApacheCon it seems we could have blocks providing bridging code to LGPL ...as long as we do not provide the jar and the block is optional. (Sylvain, did I summarize that correctly?) I agree that the whole maven2 situation is currently far less than just acceptable ...but TBH I am not sure the maven team is (or was?) really aware of all the problems we have. Maybe we can get a statement on the maven self-update and unreliable-messed-up-repository situation. From what it sounds they are working on it. So let's not work this out in our little cocoon corner but let's hear what they have to say. cheers -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride
Re: [RANT] This Maven thing is killing us....
Carlos Sanchez wrote: The repository is as good as the users/projects make it. There's no difference at all with using ant and including the wrong jars, maybe the problem is that how to fix it in maven is not as easy as in ant. If project A says it depends on B 1.0 and C says it depends on B 1.1, there's a conflict in Maven, Ant and anything you want to use, the difference is that Maven tries to do it for you, but you still can override that behaviour. It seems to me that the difference in ant, the duty to set up your classpath belongs to the project alone, so you, the build.xml author are the only one who can make a mess of your CP. However, on any system with transitive dependencies, you are ceding control of your classpath to other programs out there. Even if you think you know exactly what the dependency graph of your app is, an update to a new version of any your dependencies can pull in new metadata, with a new set of dependencies, and potentially a new classpath. This is not a maven-specific problem; anything that supports transitive dependency logic can suffer from it. Gump and Ivy could, though in both cases the descriptors tend to be hand-written tuned to not exhibit the problem. (in gump most projects dont export dependencies, as the default is compile-time-only). Right now we are in a good position with a huge number of users trying and testing the metadata in the repository, and forcing projects to support maven by providing good data. That still assumes that transitive dependencies are a good thing, and that perfect metadata is achievable. I'm not sure about either of those. I also think they're straying dangerously close to one of the big software engineering tar-pits: versioning. -steve
Re: [RANT] This Maven thing is killing us....
On 4/07/2006 9:34 PM, Torsten Curdt wrote: I agree that the whole maven2 situation is currently far less than just acceptable ...but TBH I am not sure the maven team is (or was?) really aware of all the problems we have. Not until you forwarded a message (and thanks for doing so). We don't really have the bandwidth to follow along with everyone that is converting builds... Maybe we can get a statement on the maven self-update and unreliable-messed-up-repository situation. From what it sounds they are working on it. So let's not work this out in our little cocoon corner but let's hear what they have to say. I think we all recognise there are some issues, particularly with ibiblio dropping out consistently, and also issues with transitivity and versioning that have been raised on the [EMAIL PROTECTED] thread. I'm not sure what messed up repository issues you are having, but would like to hear about it. I know this stuff needs a good hard looking at, but I don't believe there is anything insurmountable here. - Brett -- Brett Porter [EMAIL PROTECTED] Apache Maven - http://maven.apache.org/ Better Builds with Maven - http://library.mergere.com/
Re: [RANT] This Maven thing is killing us....
On Tuesday 04 July 2006 20:53, Carlos Sanchez wrote: If project A says it depends on B 1.0 and C says it depends on B 1.1, there's a conflict in Maven, Ant and anything you want to use, the difference is that Maven tries to do it for you, but you still can override that behaviour. Well, since Cocoon is going for OSGi, this does not need to be a problem per se. However, Maven currently doesn't support the CP resolution needed in complex OSGi builds (such as Eclipse itself). There are people investigating what would be needed, but no promises have been made so far. One main issue is that OSGi is not concerned over versioning of the jars, but versioning of the packages (normal Java packages for the uninitiated). More exactly, the jar is essentially just a delivery container of the packages, and the resulting classpath may be a subset of a jar and mixed in with packages from another version of the same jar. For the record; Ant is not capable of handling this perfectly either. Also; Very often it is not need for OSGi development. Cheers Niclas
Re: [RANT] This Maven thing is killing us....
Carlos Sanchez wrote: If project A says it depends on B 1.0 and C says it depends on B 1.1, there's a conflict in Maven, Ant and anything you want to use, the difference is that Maven tries to do it for you, but you still can override that behaviour. Actually, you can't in Maven 2 - at least not in any rational manner - until http://jira.codehaus.org/browse/MNG-1577 is addressed. The good news is that there is a strong desire to move to Maven 2 in my organization, so I may be given some time soon to do something about this. However, this isn't even the biggest problem that has been hampering the Cocoon community. It is that there seems to be at best a 50% chance of getting a Maven 2 based Cocoon build to work due to dependencies failing to download from repositories. Cocoon also consistently uses snapshot versions of some of its dependencies. While this isn't desirable, it is a fact of life. From Cocoon's perspective we really need to treat them like they are a private release - i.e. they weren't formally released from wherever they came from, but we don't want to have to download them at every build since they will never change. Ralph
Re: [RANT] This Maven thing is killing us....
On 7/4/06, Ralph Goers [EMAIL PROTECTED] wrote: Carlos Sanchez wrote: If project A says it depends on B 1.0 and C says it depends on B 1.1, there's a conflict in Maven, Ant and anything you want to use, the difference is that Maven tries to do it for you, but you still can override that behaviour. Actually, you can't in Maven 2 - at least not in any rational manner - until http://jira.codehaus.org/browse/MNG-1577 is addressed. The good news is that there is a strong desire to move to Maven 2 in my organization, so I may be given some time soon to do something about this. Yes you can, it's not the best way to do it but you can, by adding explicitly the dependency with the versoin you want to your pom. In the very worst case you have to add all transitive deendencies to your pom, like in Maven 1. However, this isn't even the biggest problem that has been hampering the Cocoon community. It is that there seems to be at best a 50% chance of getting a Maven 2 based Cocoon build to work due to dependencies failing to download from repositories. Cocoon also consistently uses snapshot versions of some of its dependencies. While this isn't desirable, it is a fact of life. From Cocoon's perspective we really need to treat them like they are a private release - i.e. they weren't formally released from wherever they came from, but we don't want to have to download them at every build since they will never change. You can publish that releases under your groupId, anything you want, you can't force things to happen under other groupIds. If the other projects don't want to make a release it doesn't matter if you use maven or anything else. Ralph - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride
Re: [RANT] This Maven thing is killing us....
Ralph, Thanks for this, it's very helpful. On 5/07/2006 6:59 AM, Ralph Goers wrote: However, this isn't even the biggest problem that has been hampering the Cocoon community. It is that there seems to be at best a 50% chance of getting a Maven 2 based Cocoon build to work due to dependencies failing to download from repositories. Cocoon also consistently uses snapshot versions of some of its dependencies. While this isn't desirable, it is a fact of life. From Cocoon's perspective we really need to treat them like they are a private release - i.e. they weren't formally released from wherever they came from, but we don't want to have to download them at every build since they will never change. The first thing I'd suggest is for those having problems to try another mirror. I know requiring everyone to do that is a pain and not a long term solution, but I'd like to see how much that reduces the problem. Regarding private releases, this is entirely possible just by giving them a version that isn't in the form of a snapshot. eg. if it is jetty 6.0-SNAPSHOT, use 6.0-cocoon-1, 6.0-cocoon-2. We'd considered this on the asf repository list: http://mail-archives.apache.org/mod_mbox/www-repository/200606.mbox/[EMAIL PROTECTED] However, this changes the use case a bit, since it considered those only to be needed for development and full releases would be released against full releases of their dependencies. It depends on how you use them as to the best solution here. I assume that they are customised for cocoon, so they shouldn't be considered to be the same as the original. In that case, I'd suggest you release them under your own groupID (maybe org.apache.cocoon.thirdparty) so that they don't conflict (bearing in mind that someone will transitively receive both that and the original if they are both used). I'm assuming this isn't the case as you are only bundling these modified versions into a distributable app, not as part of a reusable component? Hope this helps, Brett -- Brett Porter [EMAIL PROTECTED] Apache Maven - http://maven.apache.org/ Better Builds with Maven - http://library.mergere.com/
Re: [RANT] This Maven thing is killing us....
From: Ralph Goers [EMAIL PROTECTED] 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....
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....
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....
Why not keep the MVN repo in the Cocoon SVN repository like we used to do with the lib directory? That would allow close control of updates only by committers, and with a MVN file repo pointing to the user's Cocoon checkout, builds remain stable between SVN updates. Sure that requires again 100+ MB downloads from SVN. But that seems more stable than downloading 20 MB from SVN only and then 80+ MB from shakey MVN servers. Cheers, Alfred. -Original Message- From: Upayavira [mailto:[EMAIL PROTECTED] Sent: Montag, 3. Juli 2006 10:42 To: dev@cocoon.apache.org Subject: Re: [RANT] This Maven thing is killing us 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 mny 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 This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please notify the sender urgently and then immediately delete the message and any copies of it from your system. Please also immediately destroy any hardcopies of the message. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. The sender's company reserves the right to monitor all e-mail communications through their networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of the sender's company.
Re: [RANT] This Maven thing is killing us....
Hi Alfred, see the previous mail by Upayavira : 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. Simone Nathaniel Alfred wrote: Why not keep the MVN repo in the Cocoon SVN repository like we used to do with the lib directory? That would allow close control of updates only by committers, and with a MVN file repo pointing to the user's Cocoon checkout, builds remain stable between SVN updates. Sure that requires again 100+ MB downloads from SVN. But that seems more stable than downloading 20 MB from SVN only and then 80+ MB from shakey MVN servers. Cheers, Alfred. -Original Message- From: Upayavira [mailto:[EMAIL PROTECTED] Sent: Montag, 3. Juli 2006 10:42 To: dev@cocoon.apache.org Subject: Re: [RANT] This Maven thing is killing us 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 mny 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 This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please notify the sender urgently and then immediately delete the message and any copies of it from your system. Please also immediately destroy any hardcopies of the message. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. The sender's company reserves the right to monitor all e-mail communications through their networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of the sender's company. -- Simone Gianni
RE: [RANT] This Maven thing is killing us....
Either I am really thick here, or we talk about different things. I don't want to use the Apache SVN server as MVN repository. I propose to commit again all JARs into, say, cocoon/trunk/m2repo and then tell Maven at build time to use that directory in the checkout area as first repository server in the search list. cocoon/trunk/pom.xml: repositories repository idcocoon-private/id nameCocoon private Maven repository/name urlfile:/my/path/to/m2repo/url /repository repository idcentral/id nameMaven central repository/name urlhttp://ibiblio.org/maven2/url /repository ... /repositories I am a Maven newbie that I don't know whether file: repositories are actually supported. A relative locator would even be nicer. The Internet repositories can still be used for thoses JARs for which the are legal reasons not to store them on ASF servers. I don't see, how storing some 100 jarfiles totaling 100 MB like it is now for 2.1 should endanger the SVN infrastructure, if it is used on the SVN checkouts and commits. The drawback is of course that one has to checkout the whole thing even for building a mini-subset of Cocoon blocks. But that is something to worry about when the blocks a-la-carte actually works. Until then a reliable build system is much more important. Cheers, Alfred. -Original Message- From: Simone Gianni [mailto:[EMAIL PROTECTED] Sent: Montag, 3. Juli 2006 11:27 To: dev@cocoon.apache.org Subject: Re: [RANT] This Maven thing is killing us Hi Alfred, see the previous mail by Upayavira : 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. Simone Nathaniel Alfred wrote: Why not keep the MVN repo in the Cocoon SVN repository like we used to do with the lib directory? That would allow close control of updates only by committers, and with a MVN file repo pointing to the user's Cocoon checkout, builds remain stable between SVN updates. Sure that requires again 100+ MB downloads from SVN. But that seems more stable than downloading 20 MB from SVN only and then 80+ MB from shakey MVN servers. Cheers, Alfred. -Original Message- From: Upayavira [mailto:[EMAIL PROTECTED] Sent: Montag, 3. Juli 2006 10:42 To: dev@cocoon.apache.org Subject: Re: [RANT] This Maven thing is killing us 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 mny 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 This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please notify the sender urgently and then immediately delete the message and any copies of it from your system. Please also immediately destroy any hardcopies of the message. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. The sender's company reserves the right to monitor all e-mail communications through their networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of the sender's company. -- Simone Gianni
Re: [RANT] This Maven thing is killing us....
Hi Alfred, ok, now and with a MVN file repo pointing to the user's Cocoon checkout is clear to me, sorry my mistake :) We evaluated this opportunity while thinking how to package Dojo. One of the solutions was exactly making a local repo, and putting there this dependency (and eventually the others) that cannot be found on public repositories. Main disadvantages regarding non mavenized libraries are : 1) We still need to mavenize them. 2) We will then publish artifacts which are not usable if not doing a complete checkout of the project. Anyway a local maven repo that resides in SVN with only needed dependencies, already mavenized and taken from ibiblio, is an option (or the default option?). It's not just a question of having a reliable build system, simply in many companies they have a lifecycle for their applications that steps thru test, integration etc.. and quite often this servers are not connected to internet, so building cocoon on those machines would be simply impossibile. With the local checkedout repo solution it's like having a lib dir, just a matter of checking out cocoon, moving it to the target server, and then build with maven as usual. Also, this would not interfere with artifacts published on ibiblio, since they will still have a dependency to the X artifact, and the local repo wouls be only configured in the main cocoon pom.xml, so used only when a complete checkout has been made. Simone Nathaniel Alfred wrote: Either I am really thick here, or we talk about different things. I don't want to use the Apache SVN server as MVN repository. I propose to commit again all JARs into, say, cocoon/trunk/m2repo and then tell Maven at build time to use that directory in the checkout area as first repository server in the search list. cocoon/trunk/pom.xml: repositories repository idcocoon-private/id nameCocoon private Maven repository/name urlfile:/my/path/to/m2repo/url /repository repository idcentral/id nameMaven central repository/name urlhttp://ibiblio.org/maven2/url /repository ... /repositories I am a Maven newbie that I don't know whether file: repositories are actually supported. A relative locator would even be nicer. The Internet repositories can still be used for thoses JARs for which the are legal reasons not to store them on ASF servers. I don't see, how storing some 100 jarfiles totaling 100 MB like it is now for 2.1 should endanger the SVN infrastructure, if it is used on the SVN checkouts and commits. The drawback is of course that one has to checkout the whole thing even for building a mini-subset of Cocoon blocks. But that is something to worry about when the blocks a-la-carte actually works. Until then a reliable build system is much more important. Cheers, Alfred. -Original Message- From: Simone Gianni [mailto:[EMAIL PROTECTED] Sent: Montag, 3. Juli 2006 11:27 To: dev@cocoon.apache.org Subject: Re: [RANT] This Maven thing is killing us Hi Alfred, see the previous mail by Upayavira : 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. Simone Nathaniel Alfred wrote: Why not keep the MVN repo in the Cocoon SVN repository like we used to do with the lib directory? That would allow close control of updates only by committers, and with a MVN file repo pointing to the user's Cocoon checkout, builds remain stable between SVN updates. Sure that requires again 100+ MB downloads from SVN. But that seems more stable than downloading 20 MB from SVN only and then 80+ MB from shakey MVN servers. Cheers, Alfred. -Original Message- From: Upayavira [mailto:[EMAIL PROTECTED] Sent: Montag, 3. Juli 2006 10:42 To: dev@cocoon.apache.org Subject: Re: [RANT] This Maven thing is killing us 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 mny 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....
On Jun 30, 2006, at 12:58 PM, Bertrand Delacretaz wrote: It's Friday, I'm tired and a bit depressed after losing about two more hours unsuccessfully trying to add OJB to the dependencies of the bricks-archetype example I'm working on (would have needed all of six minutes to do this with our old ant build). It's Monday, and I'm starting to miss the complexity of the ant build process. In short in trying to keep up to date with trunk I've lost any chance I had of making progress for at least a few hours from where I was at the end of last week. Something that very rarely happened while I was keeping up to date with the 2.1.X branch, or even trunk a year ago. The whole of todays progress and errors can be found below. I love maven. I love the whole idea of it. We use it here for our other, non-cocoon, java projects. It is in theory perfect for cocoon and it's massively complex dependancies. However, the lack of progress I've been making it getting to the point where I can write code for an application against 2.2 is disheartening. I only have a few more days I can keep trying to get started with 2.2 before I go back and use 2.1.9 for this project. The fact that Bertrand hasn't been able to get this working either worries me. The ant build scripts and setup used in his example application form the basis of our own cocoon build system here. They can be frustrating sometimes of course, but they, and the monolithic cocoon build, do work. Another part of my frustration I'm sure comes from simply not knowing how to fix things to get them working anymore, but any change leads to that. My real worry with that is... does anyone? Is someone using the mavenised cocoon build system today not to just build cocoon, but an application that creates a war that can be deployed in a web container? Hopefully, Gavin Cocoon 2.2 Day 3 Today has not begun well. Having updated my local checkout of cocoon's trunk, and run mvn clean install, the application that was working at the end of last week no longer even starts. A large number of spring warnings: [INFO] XmlBeanDefinitionReader - Loading XML bean definitions from resource loaded from byte array [INFO] DefaultNamespaceHandlerResolver - Ignoring handler [org.springframework.scripting.config.LangNamespaceHandler]: class not found [INFO] DefaultNamespaceHandlerResolver - Ignoring handler [org.springframework.ejb.config.JeeNamespaceHandler]: class not found [INFO] DefaultNamespaceHandlerResolver - Ignoring handler [org.springframework.transaction.config.TxNamespaceHandler]: class not found [INFO] XmlBeanDefinitionReader - Loading XML bean definitions from URL [file:/Users/gcarothers/Documents/Programing/toc-manager/target/ toc-manager/WEB-INF/spring/cocoon-core-applicationContext.xml] [INFO] DefaultNamespaceHandlerResolver - Ignoring handler [org.springframework.scripting.config.LangNamespaceHandler]: class not found [INFO] DefaultNamespaceHandlerResolver - Ignoring handler [org.springframework.ejb.config.JeeNamespaceHandler]: class not found [INFO] DefaultNamespaceHandlerResolver - Ignoring handler [org.springframework.transaction.config.TxNamespaceHandler]: class not found [INFO] XmlBeanDefinitionReader - Loading XML bean definitions from URL [file:/Users/gcarothers/Documents/Programing/toc-manager/src/main/ resources/META-INF/spring/demo-application-context.xml] [INFO] DefaultNamespaceHandlerResolver - Ignoring handler [org.springframework.scripting.config.LangNamespaceHandler]: class not found [INFO] DefaultNamespaceHandlerResolver - Ignoring handler [org.springframework.ejb.config.JeeNamespaceHandler]: class not found [INFO] DefaultNamespaceHandlerResolver - Ignoring handler [org.springframework.transaction.config.TxNamespaceHandler]: class not found and ending with: java.lang.NoSuchMethodError: org.apache.cocoon.core.CoreUtil.getRootLogger()Lorg/apache/avalon/ framework/logger/Logger; at org.apache.cocoon.servlet.CocoonServlet.init (CocoonServlet.java:126) From the mailing lists I know there were large changes to the Servlet for cocoon. Which I assume is the reason I can't find a CocoonServlet.java file anywhere in the source tree. So, I guess even after rerunning mvn install my local repository must have an old copy of the code somewhere, no idea what else might cause this. rm -rf .m2/repository/ Of course I now have to download all the dependencies and even basic maven plugins again. There should be a better way. Back in the cocoon source directory: mvn install -Dmaven.test.skip=true Need to run this 6 or 7 times to get all the plugins from: central (http://repo1.maven.org/maven2), apache.snapshots (http://svn.apache.org/maven-snapshot-repository), snapshots (http://snapshots.maven.codehaus.org/maven2) I will point out that we can't blame ibiblio for those. Two of them are from my understanding hosted by Apache. Another N times to get all
Re: [RANT] This Maven thing is killing us....
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 3 Jul 2006, Simone Gianni wrote: It's not just a question of having a reliable build system, simply in many companies they have a lifecycle for their applications that steps thru test, integration etc.. and quite often this servers are not connected to internet, so building cocoon on those machines would be simply impossibile. With the local checkedout repo solution it's like having a lib dir, just a matter of checking out cocoon, moving it to the target server, and then build with maven as usual. Ahem.. I think you missunderstud the M10N we've done for 2.2. A Cocoon user don't build it's Cocoon apps from Cocoon sources anymore. Instead it gets an M2 Cocoon archetype, build its app in there (this includes a root sitemap, something you wouldn't really touch in 2.1 because of the predefined components in there!) build a war file (which already containes all jars the app needs) and ship that to your test, intergration and production servers. What this discussion is looking for is a solution for us Cocoon developers (and those who want to check it before final release). In the end Cocoon 2.2 users shouldn't have the need to check out the sources anymore. Thus a solution with a M2 repository in our Cocoon SVN repository isn't going in the right direction for our users just for us Developers. Ciao Giacomo - -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.4 (GNU/Linux) iD8DBQFEqWWfLNdJvZjjVZARAlh0AJ44VC1mtL+lvMwKZ34V5Af5xkUqrACgw2ys IaXRszac3DbKg9z8kl52tLw= =n4va -END PGP SIGNATURE-
Re: [RANT] This Maven thing is killing us....
Gavin Carothers wrote:
rm -rf .m2/repository/
Of course I now have to download all the dependencies and even basic
maven plugins again. There should be a better way.
What about rm -rf .m2/repository/org/apache/cocoon?
--
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....
... yes, indeed that would have been a much smarter thing to do. I
leave this is a happy lesson for everyone else following me, and
myself next time this happens.
Cheers,
Gavin
On Jul 3, 2006, at 3:27 PM, Reinhard Poetz wrote:
Gavin Carothers wrote:
rm -rf .m2/repository/
Of course I now have to download all the dependencies and even
basic maven plugins again. There should be a better way.
What about rm -rf .m2/repository/org/apache/cocoon?
--
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....
Gavin Carothers wrote: mvn install -Dmaven.test.skip=true Need to run this 6 or 7 times to get all the plugins from: central (http://repo1.maven.org/maven2), apache.snapshots (http://svn.apache.org/maven-snapshot-repository), snapshots (http://snapshots.maven.codehaus.org/maven2) I will point out that we can't blame ibiblio for those. Two of them are from my understanding hosted by Apache. PING ibiblio.org (152.2.210.80): 56 data bytes PING repo1.maven.org (152.2.210.80): 56 data bytes repo1 is just an alias for maven central. Have you configured a mirror before doing a build ? still downloading more jars about 2 hours after having started the process... starting to think of a way to shell script the restart of mvn install. What machine are you building on? Limited internet connection perhaps? Thanks for testing this out, your feedback is highly appreciated! Jorg
Re: [RANT] This Maven thing is killing us....
On Jul 3, 2006, at 4:10 PM, Jorg Heymans wrote: Gavin Carothers wrote: mvn install -Dmaven.test.skip=true Need to run this 6 or 7 times to get all the plugins from: central (http://repo1.maven.org/maven2), apache.snapshots (http://svn.apache.org/maven-snapshot-repository), snapshots (http://snapshots.maven.codehaus.org/maven2) I will point out that we can't blame ibiblio for those. Two of them are from my understanding hosted by Apache. PING ibiblio.org (152.2.210.80): 56 data bytes PING repo1.maven.org (152.2.210.80): 56 data bytes repo1 is just an alias for maven central. Dope, so it is. Have you configured a mirror before doing a build ? Tried two, had the same issues as main. Tried lsu and .net mirrors. I'm the US. I think if I'm going to keep doing this I'm just going to need to setup a mirror locally for the company, cause none of the other people here are going to keep trying :) still downloading more jars about 2 hours after having started the process... starting to think of a way to shell script the restart of mvn install. What machine are you building on? Limited internet connection perhaps? Sadly no, T3 and wireless 3mbit connection. Thanks for testing this out, your feedback is highly appreciated! I'll keep it up as long as I can. Cheers, Gavin
Re: [RANT] This Maven thing is killing us....
Gavin Carothers wrote: Tried two, had the same issues as main. Tried lsu and .net mirrors. I'm the US. I think if I'm going to keep doing this I'm just going to need to setup a mirror locally for the company, cause none of the other people here are going to keep trying :) Consider also maven-proxy [1] or proximity [2], a must for any company using maven IMO. What machine are you building on? Limited internet connection perhaps? Sadly no, T3 and wireless 3mbit connection. I'm assuming you read [3] , perhaps using a european mirror works better for you? I couldn't find a complete list of all mirrors, so i'm assuming you'll have to do with one of these. HTH Jorg [1] http://maven-proxy.codehaus.org/ [2] http://proximity.abstracthorizon.org/ [3] http://maven.apache.org/guides/mini/guide-mirror-settings.html
Re: [RANT] This Maven thing is killing us....
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....
Ralph Goers wrote:
Bertrand Delacretaz wrote:
On 7/1/06, Ralph Goers [EMAIL PROTECTED] 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....
Reinhard Poetz wrote: Ralph Goers wrote: Bertrand Delacretaz wrote: On 7/1/06, Ralph Goers [EMAIL PROTECTED] 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....
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
Re: [RANT] This Maven thing is killing us....
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 [EMAIL PROTECTED] 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....
Bertrand Delacretaz wrote: About OJB, basically the poms that I found at ibiblio did not help much. then we should ping the ojb folks and ask them to come up with proper poms. But this is the last of many problems that have prevented us from making serious progress this week. See my answer to Carsten for some ideas that might help us work with better repositories. I understand there have been many problems but until someone tells me something more specific about every one of these there is nothing i can do to help. Jorg
Re: [RANT] This Maven thing is killing us....
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....
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....
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....
On 7/2/06, Sylvain Wallez [EMAIL PROTECTED] 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....
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 [EMAIL PROTECTED] Cheers Niclas
Re: [RANT] This Maven thing is killing us....
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....
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 mny 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....
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....
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, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [RANT] This Maven thing is killing us....
On 7/1/06, Carsten Ziegeler [EMAIL PROTECTED] 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....
On 6/30/06, Jorg Heymans [EMAIL PROTECTED] wrote: ...Please don't, details please About OJB, basically the poms that I found at ibiblio did not help much. But this is the last of many problems that have prevented us from making serious progress this week. See my answer to Carsten for some ideas that might help us work with better repositories. -Bertrand
Re: [RANT] This Maven thing is killing us....
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, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [RANT] This Maven thing is killing us....
On 7/1/06, Carsten Ziegeler [EMAIL PROTECTED] 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....
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....
On 7/1/06, Ralph Goers [EMAIL PROTECTED] 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....
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....
Bertrand Delacretaz wrote: On 7/1/06, Ralph Goers [EMAIL PROTECTED] 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....
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....
Bertrand Delacretaz wrote: It's Friday, I'm tired and a bit depressed after losing about two more hours unsuccessfully trying to add OJB to the dependencies of the bricks-archetype example I'm working on (would have needed all of six minutes to do this with our old ant build). I'll spare you the details on that one Please don't, details please. Jorg
