On Mon, Mar 31, 2008 at 8:48 PM, Robert Burrell Donkin <[EMAIL PROTECTED]> wrote: > > On Mon, Mar 31, 2008 at 7:53 PM, Stefano Bagnara <[EMAIL PROTECTED]> wrote: > > Robert Burrell Donkin ha scritto: > > > On Mon, Mar 31, 2008 at 2:05 PM, Stefano Bagnara <[EMAIL PROTECTED]> > wrote: > > > > >> >> The funny thing is that all of this thread is about a "stupid" pom > that > > >> >> even my father could write as is if I explain him the pom > > >> >> semantic+syntax and I tell him to describe junit-3.8.1.jar. This > is what > > >> >> scare me: the fact that we don't have a clear way to rewrite this > > >> >> f***ing xml from scratch and release jSPF-0.9.7. > > > > > > under US copyright law, only the expression and not the facts would > > > have been copyrightable. if it were me, i would have simply created a > > > clean room implementation and been done with it. > > > > > > or just deleted the pom altogether > > > > My main concern is being diligent in not creating further problems to > > maven users, so I would like to avoid the creation of metadata different > > from the one published in central. > > > > This mean that I would not like to create a new junit.pom with the same > > groupId/artifactId but with different data (in this very specific case > > the pom we can create from scratch is almost identical to the original > > one so we could even take this way). > > > > Also, removing the pom means that maven tries to download it but if it > > is disconnected or it is ran in offline mode then it will create an > > "empty" pom including only the artifactId/groupId/version stuff. Again > > this would be different but for this very specific case (junit.pom) it > > would work. > > > > In both case the risk is that we place a different junit.pom: if some > > other m2 based project used by our users depends on license data, > > description or other stuff declared in the junit.pom we are likely to > > break their build. > > IMHO this is a maven issue: it should really mark any poms it creates > and then download replacements once on line again > > > > Another "hack" could be renaming junit-3.8.1.jar to myjunit-3.8.1.jar or > > junit-3.8.1-custom.jar, declare our dependency on that specific jar and > > declare a dependency exclusion for every other depedency depending on > > junit. This would place a custom artifact in the build process/local > > repository but would not break other builds. (something tells me we > > already made this analysis for jsieve, before you found the alternative > > solution). > > > > Maybe we should ask to maven lists what is better to do (IIRC I already > > asked this in past, receiving no answers...). > > why not just use an ant script for offline builds?
+1 the website generation aspect excluded, I don't get it why removing maven is not already discussed as an obvious option here. if we find that maven causes us non-technical problems - and this thread is definitively proving this - , we are free to not use it. I downloaded the 0.9.5er source distribution today and it does not build with ant, only maven. it downloads a ridiculous large number of jars for very little effect. I remember that I +1'ed maven usage for building the site. but (hereby also answering a prev question asked on this thread) the rest should work with ant and offline, please. :-) Thanks, Bernd PS: the website links downloadunstable.cgi and points to a beta build. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
