Now if it was a tool focussed on dependency management (like Ivy) it would have solved the real problem: snapshots. So let's do an example: - as trunk -> ejb3-core-0.1-SNAPSHOT -> ejb3-interceptors-0.13-0-SNAPSHOT -> aop-2.1-SNAPSHOT (for the example) If I happen to deploy a new snapshot of aop, it'll break AS build. Why: ejb3-core is not compatible and Maven blindly loads it up. This is not possible in Ivy, it's snapshot repository looks like: - as trunk -> ejb3-core-0.1-20080421 -> ejb3-interceptors-0.13.0-20080421 -> aop-2.1-20080420. If I happen to deploy a new snapshot of aop you get and I run a nightly build on ejb3 you get: - as trunk -> ejb3-core-0.1-20080421 -> ejb3-interceptors-0.13.0-20080421 -> aop-2.1-20080420 - ejb3-interceptors-0.13-0-20080422 -> aop-2.1-20080422 Since ejb3-core didn't properly build there is no new snapshot for it and AS build is unaffected. Combine this with unit tests and you got a pretty stable setup.

Paul Gier wrote: > Carlo de Wolf wrote: > >> >> Now if it was a tool focussed on dependency management (like Ivy) it >> would have solved the real problem: snapshots. So let's do an example: >> - as trunk -> ejb3-core-0.1-SNAPSHOT -> >> ejb3-interceptors-0.13-0-SNAPSHOT -> aop-2.1-SNAPSHOT (for the example) >> If I happen to deploy a new snapshot of aop, it'll break AS build. >> Why: ejb3-core is not compatible and Maven blindly loads it up. This >> is not possible in Ivy, it's snapshot repository looks like: >> - as trunk -> ejb3-core-0.1-20080421 -> >> ejb3-interceptors-0.13.0-20080421 -> aop-2.1-20080420. >> If I happen to deploy a new snapshot of aop you get and I run a >> nightly build on ejb3 you get: >> - as trunk -> ejb3-core-0.1-20080421 -> >> ejb3-interceptors-0.13.0-20080421 -> aop-2.1-20080420 >> - ejb3-interceptors-0.13-0-20080422 -> aop-2.1-20080422 >> Since ejb3-core didn't properly build there is no new snapshot for it >> and AS build is unaffected. >> Combine this with unit tests and you got a pretty stable setup. >> > > We can do this using maven also. If you want to tie the build to a > specific snapshot, just put the full snapshot version in the > dependency. So for example, ejb3-interceptors you could put version > "0.13.0-20080417.210958-18". And maven will keep using that snapshot > build until you change the dependency. The -SNAPSHOT convention is > just for convenience if you just want to build with the latest until a > release comes out. It must be automated. Whenever someone does a mvn deploy, the pom.xml should be replaced by one not containing any snapshots, but only full versions.

On Mon, Apr 21, 2008 at 8:47 PM, Paul Gier <pgier(a)redhat.com&gt; wrote: > Just so it's clear what you are asking for, you want dependencies with > (-SNAPSHOT) to be replaced with the specific snapshot version > (-timstamp-build) during deployment? I could probably add this as an option > to the deploy plugin, but I don't know if this would solve the problem. > You do sound really fanboyish Paul, I am afraid ... Obviously, with enough scripting and development efforts, you could turn an Ant script into a proper dependency management system. However, the point of the tool is to provide a ready to use solution that fits our needs. Maven fails badly at that. Carlo forgot the non existent error reporting (or maybe that's for part 2). Do you have a solution for that too ? Personally, I would encourage Ovidiu to send a patch for his dependency system, and I'd do everything I can [assuming it does actually work, of course - realistically, as my influence is quite limited, that wouldn't be much, but it's a start ;) ] to get it included in AS 5 as a replacement for Maven. Rémy _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development

Ovidiu Feodorov wrote: > > Thank you, Rémy > > The system I am talking about I delegates the build tasks to ant, > feeding it with the appropriate dependency information. In this > respect, your build can be as simple as "ant", no need for maven > commands. Awesome. This is exactly how it should be. The whole idea of limiting a project to 5 build commands is flawed. Using "profiles" to solve this limitation is also flawed (and confusing). How does your system compare to Ivy (besides support for native code integration)? Do you have any plans to support pulling from maven2 repos as a stop-gap?

> In order to implement this, the dependency manager recursively walks > the dependency tree and detects the transitive closure of your > project's dependencies, "flattens" the dependency tree, and in its > current implementation, it just bails out with a loud error message > when it detects a version conflict. It doesn't try to "guess" > anything, even that heuristics can be optionally plugged in (I am > personally afraid of heuristics, they have a habit of yielding > unexpected results, so I won't encourage that) > > Here's the manual: http://fragma.sourceforge.net/FragmaUserGuide.pdf Do you have any more information on how the Java integration works (or is planned to work)? These sections are empty in the manual.

> As I said before, my proposal is to use it to configure a small > peripheral project, and if conclusions prove to be positive, decide > what to do from there, in case you guys decide to go this route. I have to say, I really like the idea of having a build system that can be adjusted to fit our needs, as opposed to changing our needs to fit the build system (maven).

Thank you, Rémy The system I am talking about I delegates the build tasks to ant, feeding it with the appropriate dependency information. In this respect, your build can be as simple as "ant", no need for maven commands. In order to implement this, the dependency manager recursively walks the dependency tree and detects the transitive closure of your project's dependencies, "flattens" the dependency tree, and in its current implementation, it just bails out with a loud error message when it detects a version conflict. It doesn't try to "guess" anything, even that heuristics can be optionally plugged in (I am personally afraid of heuristics, they have a habit of yielding unexpected results, so I won't encourage that) Here's the manual: http://fragma.sourceforge.net/FragmaUserGuide.pdf As I said before, my proposal is to use it to configure a small peripheral project, and if conclusions prove to be positive, decide what to do from there, in case you guys decide to go this route.

David M. Lloyd wrote: > > I'm willing try this out on Remoting 3 (which is the very definition > of a small peripheral project). My only requirements are: > > 1) the build has to work exactly as it does now (it's purely ant at > the moment, and works just fine, though some of the deps are > downloaded from the Maven part of the repository) That's doable. I need to add support for a Maven repository, which I wanted to do anyway, but as a short term solution, we can use this kind of repository: http://repository.novaordis.org/ Something like this can be set up in ten minutes, and it can be a placeholder until Maven repository support is ready. > 2) none of my time required :) Though I'm willing to answer questions > about the build > > http://www.jboss.org/jbossremoting/ Well, that's fine in what I am concerned. I don't expect much work to go into this. You need to clear this with your managers, though, remember that I am not JBoss anymore ...

David M. Lloyd wrote: > Nah. Just send me a patch and a list of files to upload ;-) And of > course you have to assign the copyright and so forth - I assume > there's still a contributor agreement with your name on it lying about > somewhere. OK, but before proceeding, could please look up the contributor assignment and send it to me? I would like to review what exactly is in there.

For example I consider a NPE of an exception without any context bad

On Tue, Apr 22, 2008 at 1:44 PM, Carlo de Wolf <cdewolf(a)redhat.com&gt; wrote: > Why does it fail? > We now have a working ant script (because it's the same one as with > buildmagic) and dependencies being resolved by Maven. I say the target has > been achieved. Last friday, it couldn't get me the proper version of a JAR (jboss-vfs.jar), for whatever reason (I don't want to know the reason, really). It also maintains two repositories, which sounds bad to me. Why keep arguing about the obvious ?

Carlo de Wolf wrote: > Paul Gier wrote: >> We can do this using maven also. If you want to tie the build to a >> specific snapshot, just put the full snapshot version in the >> dependency. So for example, ejb3-interceptors you could put version >> "0.13.0-20080417.210958-18". And maven will keep using that snapshot >> build until you change the dependency. The -SNAPSHOT convention is >> just for convenience if you just want to build with the latest until >> a release comes out. > > It must be automated. Whenever someone does a mvn deploy, the pom.xml > should be replaced by one not containing any snapshots, but only full > versions. > Just so it's clear what you are asking for, you want dependencies with (-SNAPSHOT) to be replaced with the specific snapshot version (-timstamp-build) during deployment? I could probably add this as an option to the deploy plugin, but I don't know if this would solve the problem. Just as an example, let's say you deploy an ejb3 module that has a dependency on jboss-aop. You deploy and it resolves to aop snapshot build 9. The app server has a dependency on the current aop snapshot (2.0-SNAPSHOT) and they both point to build 9 so all is fine. Then aop deploys a new snapshot (build number 10). The app server depends on aop (-SNAPSHOT) so it gets the new version. Now the app server wants build 10, but ejb3 wants snapshot version 9. The app server IMO should win because the direct dependency should take priority over the transitive ejb dependency. To solve this issue you would still have to change the app server dependency to tie it to the specific snapshot of aop.

I will, however, add to the list of Maven2 Gripes an issue I encountered last week:

Jason T. Greene wrote: > I think your list would be smaller if you just listed what maven does right ;) > Maybe. :) But for the time being we're pretty deep into Mavenization of the AS, and most of the complaining I've seen is due to: * Improper comprehension of Maven's behaviour * Refusal to invest some time into learning a new technology

Carlo de Wolf wrote: > Paul Gier wrote: >> Carlo de Wolf wrote: >> >>> >>> Now if it was a tool focussed on dependency management (like Ivy) it >>> would have solved the real problem: snapshots. So let's do an example: >>> - as trunk -> ejb3-core-0.1-SNAPSHOT -> >>> ejb3-interceptors-0.13-0-SNAPSHOT -> aop-2.1-SNAPSHOT (for the example) >>> If I happen to deploy a new snapshot of aop, it'll break AS build. >>> Why: ejb3-core is not compatible and Maven blindly loads it up. This >>> is not possible in Ivy, it's snapshot repository looks like: >>> - as trunk -> ejb3-core-0.1-20080421 -> >>> ejb3-interceptors-0.13.0-20080421 -> aop-2.1-20080420. >>> If I happen to deploy a new snapshot of aop you get and I run a >>> nightly build on ejb3 you get: >>> - as trunk -> ejb3-core-0.1-20080421 -> >>> ejb3-interceptors-0.13.0-20080421 -> aop-2.1-20080420 >>> - ejb3-interceptors-0.13-0-20080422 -> aop-2.1-20080422 >>> Since ejb3-core didn't properly build there is no new snapshot for it >>> and AS build is unaffected. >>> Combine this with unit tests and you got a pretty stable setup. >>> >> >> We can do this using maven also. If you want to tie the build to a >> specific snapshot, just put the full snapshot version in the >> dependency. So for example, ejb3-interceptors you could put version >> "0.13.0-20080417.210958-18". And maven will keep using that snapshot >> build until you change the dependency. The -SNAPSHOT convention is >> just for convenience if you just want to build with the latest until a >> release comes out. > > It must be automated. Whenever someone does a mvn deploy, the pom.xml > should be replaced by one not containing any snapshots, but only full > versions. > Just so it's clear what you are asking for, you want dependencies with (-SNAPSHOT) to be replaced with the specific snapshot version (-timstamp-build) during deployment? I could probably add this as an option to the deploy plugin, but I don't know if this would solve the problem.

Just as an example, let's say you deploy an ejb3 module that has a dependency on jboss-aop. You deploy and it resolves to aop snapshot build 9. The app server has a dependency on the current aop snapshot (2.0-SNAPSHOT) and they both point to build 9 so all is fine. Then aop deploys a new snapshot (build number 10). The app server depends on aop (-SNAPSHOT) so it gets the new version. Now the app server wants build 10, but ejb3 wants snapshot version 9. The app server IMO should win because the direct dependency should take priority over the transitive ejb dependency. To solve this issue you would still have to change the app server dependency to tie it to the specific snapshot of aop. _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development

My mistake, we're mixing two issues here: - stability of the build - reproducibility of the build I completely agree that any real release must be reproducible, but is it feasible to do release for every little nitbit? I say no. > People need to stop being lazy and create proper releases. > > SNAPSHOTS are only useful when you want to know whether a new release > will work another project. > > e.g. before I release the next version of jboss-vfs, I create a SNAPSHOT > in my *local* repository and update the jbossas build to use it. > If it works, I do a proper release (NOT a mvn deploy of the SNAPSHOT) > for others to use. That's really bad. So if it works on your machine, it's gold? (We know it is, but that's not good enough on my machine. ;-) ) We must have a stable integration build on a QA machine before we can declare something releasable.

This is going to be a long post, so grab a cup of coffee. Let me start with the fact that I'm biased against Maven and before any Maven hater starts cheering, don't. I still think we should use Maven to it's full advantage (whatever that may be). I don't think calling Maven an abomination and a piece of crap is not a valid reason to ditch it. We need to form a well informed opinion on it. Let's start with the goal of Maven and how we apply it. "Maven is a software project management and comprehension tool. [...] Maven can manage a project's build, reporting and documentation from a central piece of information." Our application of Maven is just to use it for dependency management. So the complete Maven scope extends well beyond our requirements. This is all fine if the requirement is properly met and if the tool limits itself to that scope. Problem 1 then appears: Maven is 'opinionated software'. In other words convention is prioritized over configuration. Given that Maven goes beyond scope and thus start mandating certain conventions outside the 'dependency management' area it starts to suck. I want be in control of the build process and Maven to do dependencies. (We've attained that goal in AS build, so we're stopping there.) But now we get a declarative build process in which I have to describe my project and press a 'I'm Feeling Lucky' button to see the result. On to the second problem: the implementation of dependency management in Maven. It looks fine on paper, but again it has a notion of being 'opinionated' and thus you're not in control. The version of dependencies you specify in the pom.xml are advisements (WTF!). In actuality Maven picks a semi random (okay I'm exaggerating a bit) version instead of informing you that you're an idiot for mixing bad stuff. Version ranges might help in this area by being more than just advisements. Now if it was a tool focussed on dependency management (like Ivy) it would have solved the real problem: snapshots. So let's do an example: - as trunk -> ejb3-core-0.1-SNAPSHOT -> ejb3-interceptors-0.13-0-SNAPSHOT -> aop-2.1-SNAPSHOT (for the example) If I happen to deploy a new snapshot of aop, it'll break AS build. Why: ejb3-core is not compatible and Maven blindly loads it up. This is not possible in Ivy, it's snapshot repository looks like: - as trunk -> ejb3-core-0.1-20080421 -> ejb3-interceptors-0.13.0-20080421 -> aop-2.1-20080420. If I happen to deploy a new snapshot of aop you get and I run a nightly build on ejb3 you get: - as trunk -> ejb3-core-0.1-20080421 -> ejb3-interceptors-0.13.0-20080421 -> aop-2.1-20080420 - ejb3-interceptors-0.13-0-20080422 -> aop-2.1-20080422 Since ejb3-core didn't properly build there is no new snapshot for it and AS build is unaffected. Combine this with unit tests and you got a pretty stable setup. So at the end of the day we're not yet there with Maven: 1. It has crummy implementation of snapshots that needs to be fixed; 2. It must have proper conflict resolution; So let's first make JBoss a shining example of how to do a mega project with Maven. After that we can really do a well informed 'Why Maven sucks (part 2)'. Carlo _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development