Hi Arnaud, I know that i can use a time-stamped version of a dependency, which is a great feature. But how do i know in which timestamped version, a given issue in JIRA has been fixed in?
Also, reading the "Guide to Testing Development Versions of Plugins", i come across the following: "Note: This is not recommended as an everyday or in production practice!" "Note: These last two techniques mean that every plugin will be updated to the latest snapshot version. Finer grained control will be available in future versions." This leads me to the conclusion, that i should never use this in production. Am I not getting something here? If indeed it is recommended practice, to use timestamped snapshot versions of plugins in production environments, could somebody write a guide to doing this, or perhaps update some of the existing guides on repository management? Best regards Simon Kepp Nielsen, Configurations Manager PFA Pension, Teknisk Arkitektur Mobile: +45 30 52 77 07 E-mail: [EMAIL PROTECTED] PFA Pension Sundkrogsgade 4 DK-2100 Copenhagen OE Disclaimer This message is for the designated recipient only and may contain confidential or privileged information. If you have received the message in error, please notify the sender by replying the e-mail and delete the message without copying or disclosing. -----Oprindelig meddelelse----- Fra: Arnaud HERITIER [mailto:[EMAIL PROTECTED] Sendt: 30. august 2006 22:57 Til: Maven Users List Emne: Re: [POLL] Why switch to Maven? You're right but I would like to add that when we deploy a snapshot we also deploy a timestamp version of the plugin ([1] is an example for m1). This timestamp can be used temporaly and will not be modified. But I agree that it doesn't resolve our lake of releases.... Arnaud [1] http://people.apache.org/repo/m1-snapshot-repository/maven/plugins/?C=M;O=D On 8/30/06, Simon Kepp Nielsen <[EMAIL PROTECTED]> wrote: > > I think this answer is one of the common problems with Maven. I don't > mean to pound on Emmanuel, who's doing a great job, but just point out > a very common problem in many open source projects. > > The fact that a feature is available in a snapshot version or in the > trunk doesn't help the user that much. Unless the feature is actually > released, it doesn't do much good. My experience with Maven (and > particularly the > plugins) is, that errors are often fixed quite fast after they are reported. > But from then, it can be quite a long time (often months), until the > fix is actually released. In that period, everybody affected by the > bug has to use snapshot versions, or build the plugin themselves. > Snapshot versions are not great if you are trying to run a stable > build environment, and building everything yourself from the trunk, > means living on the bleeding eddge, with lots of snapshot dependencies. > > I think a good solution to the problem would be more frequent > milestone builds (both core and plugins), and a publicly available > road map, giving people a good indication of when they can expect to see what > released. > > > Best regards > > Simon Kepp Nielsen, Configurations Manager PFA Pension, Teknisk > Arkitektur > Mobile: +45 30 52 77 07 > E-mail: [EMAIL PROTECTED] > > > PFA Pension > Sundkrogsgade 4 > DK-2100 Copenhagen OE > > Disclaimer > This message is for the designated recipient only and may contain > confidential or privileged information. If you have received the > message in error, please notify the sender by replying the e-mail and > delete the message without copying or disclosing. > > > > -----Oprindelig meddelelse----- > Fra: Emmanuel Venisse [mailto:[EMAIL PROTECTED] > Sendt: 30. august 2006 11:43 > Til: Maven Users List > Emne: Re: [POLL] Why switch to Maven? > > > > Jan Vissers a écrit : > >>> Maven's key strength is to say "don't worry about trying to build > >>> a jar / war / ear / sync with eclipse / autorun tests / publish > >>> javadocs / etc / etc, because I already know how to do that, you > >>> go and do what you do best, work on the primary code". > > > > I would like this approach very much, but... > > have you tried to publish javadocs/jxr/surefire/pmd... etc for a > > multimodule project in an aggregated fashion? > > It's implemented in snapshot version of javadocs/jxr plugins > > Emmanuel > > > > >> On Wed, August 30, 2006 7:37 am, Jan Vissers wrote: > >> > >>> I'm reading a lot of "we need about x weeks to convert to maven", > >>> "the learning curve is steep", "it is messy but it works", "if it > >>> cannot be done we can use ant"... > >>> > >>> More and more I'm getting the feeling that ANT still isn't such a > >>> bad idea for building software. You can do a lot of the convention > >>> over configuration stuff for your own projects with ant and things > >>> like macrodef, subant and antlib. For dependency management we're > >>> currently using Ivy - which is pretty descent. What's more the > >>> reporting just works, even aggregated > >>> (pmd,jdepend,junit,checkstyle,cobertura,javadoc,changelog,javacnss). > >>> > >>> Can somebody tell me what the main reason would be for changing > >>> from ANT to Maven? > >>> I'm starting to get serious doubts. > >> I recently got involved in a project whose build system uses ant + > >> ivy, and to sum it up: what an inefficient mess. > >> > >> Within themselves, ant and ivy are worthy tools, that perform their > >> tasks well. The real problem is that once developers get hold of > >> them, things quickly go pear shaped. > >> > >> The key biggest problem with the ant + ivy combo is the fact that > >> developing the build system is a secondary concern, the primary > >> concern being developing the software itself. This causes numerous > >> problems, > >> including: > >> > >> - ant scripts are often half finished. > >> > >> In this project, nobody bothered to take advantage of incremental > builds. > >> Any attempt to build, will build clean - a huge time waster. > >> > >> - ant scripts are almost always riddled with hard coded paths, and > >> developer specific customisations. > >> > >> In this project, that means that every developer has to set up > >> their development environment the same way as the other developers, > >> which may seem perfectly acceptable to some, until you realise that > >> developers don't just work on one project. > >> > >> This makes it difficult / impossible to introduce continuous > >> integration techniques, despite this particular project desperately > needing it. > >> > >> - ant scripts are often riddled with relative paths to other > >> projects, where it is assumed a sister project is checked out. > >> > >> Again, this prevents continuous integration from being possible. > >> > >> - ivy dependencies are often set up by developers who fiddle until > >> they work. > >> > >> In this project, the eclipse jars were removed from their plugins, > >> had their version numbers removed, and dumped into one big ivy > >> dependency called "eclipse". There is no way of knowing what jar > >> offers what functionality, because the jars are called sac.jar, > core.jar, etc. > >> > >> Upgrading the jars (to take advantage of a bugfix, for example) in > >> this project is very impractical. > >> > >> To sum up the above: > >> > >> Giving developers the power to "do what they want", simply means > >> that developers are given the power to do something badly, or not at all. > >> > >> Build systems are always secondary to the primary code, and do not > >> receive proper attention from developers, and this wastes copious > >> amounts of time, and therefore money. > >> > >> Maven's key strength is to say "don't worry about trying to build a > >> jar / war / ear / sync with eclipse / autorun tests / publish > >> javadocs / etc / etc, because I already know how to do that, you go > >> and do what you do best, work on the primary code". > >> > >> Regards, > >> Graham > >> -- > >> > >> > >> > > > > > > > > -------------------------------------------------------------------- > > - To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
