Hi Francis, yes, when I mentioned the two steps my intention was to first mavenize the distribution and later the svn repository.
What I still don't see is why it would be easier to make the distribution if we convert the svn repo first. Also I don't see why any of your work would ever be lost. The releas scripts would be changed and every new release will be built according to this (I could do that). For me, the distribution does not have to contain any kind of reference to the svn repository. The distribution has three main purposes: 1. Supply the binaries and the source for debugging 2. Provide example application that show how to work with the distribution 3. Build the binaries from the source. For Point 1 and 2 I don't think we need a svn history. Even for Point 3 I personally don't feel the need for a history. The distribution is for end-users and not really for people who want to work on the project itself. Also we need to address the fact, that the way the projects are set up in Eclipse differs between internal development and distribution. For example: The DBSample contains all required jars in the classpath whereas in our internal development it contains a reference to the Empire-db Eclipse project and other sub-projects. Nobody wants you to put in work that will later be lost - but as I said I don't see why that would be. It's certainly a lot more work and stress to convert the whole svn repo now in one go. I just feel that if we start moving around files in svn now, we might face serious problems with working on the project - which we as Maven novices could find hard to solve ourselves. But if we have a mavenized distribution first, we could all get familiar with it and then go for the big bang later. This is my personal point of view. But we're a community and everyone should give their opinion. Before we end up having an endless discussion however, we should start reaching a agreement on what to do. Now it's all down to the point whether to mavenize the distribution only for a start or go for the big bang and modify the svn. I would still prefer modifying the distribution first and do the rest later. Again: What exactly would be the disadvantage of that why would we find it harder to modify the svn later? Rainer Francis De Brabandere wrote: > > Jürg, Rainer, > > As Jürg suggested, big bang is the easiest way to get everything ready > for maven. If I understand correctly you suggest I start with a svn > trunk checkout (or the distribution), start moving stuff around and > mavenize it until is possible to build the distribution zip. All svn > history will be lost if you just check that version in... Won't that > be a problem? And you'll have to stop coding during that time? > > Rainer, I still don't see why you want the distribution mavenized and > not the code repository? > > I really think this should be done by somebody inside the project with > access to subversion. It is going to be a lot more work if I do this > locally and afterwards you guys try to merge the whole thing... > > Am I correct to understand that the team is afraid of messing up the > ant build by moving files in svn? Last time I merged a project to > maven I started by moving files around (in small steps) towards the > maven layout, and while doing that I updated the build file(s). When > everything was correctly in place I then just added the pom files and > configured the maven build. At that point we had 2 operational build > systems. Maybe that's an easier way for you guys to move to maven? > > It's just that I don't want to put time and effort in all the > migration work to see it being lost afterwards. Have you asked other > maven users (Martijn?) what they think about all this? > > Francis > > On Mon, Dec 1, 2008 at 6:58 PM, Rainer Döbele <[EMAIL PROTECTED]> wrote: > > Hi Francis, > > > > Sorry for not being able to reply earlier. > > Please also apologize if I am unable to understand you or express myself. > > > > If I understand it right, the first thing to do is to create artefacts > for both empire-db-2.0.4.jar and empire-struts3-ext-1.0.4.jar and put them > in a Maven repository so that people can use it in their projects. This > would be the first thing to do, right? > > > > Next, we need to supply a file for download to the user (zip or tar.gz). > This is what I call 'the distribution'. It should contain the following: > > - Apache License files, the readme and the changelog > > - a lib directory containing the distribution jar's (e.g. empire-db- > 2.0.4.jar) - with or without dependencies. > > - a src folder containing the project source, the examples, and the > necessary pom.xml files required to build the Eclipse projects for both > building the empire jars and the example applications. > > For every new Release there will be one distribution file for each of > the two projects. > > > > My idea is, that you restructure the current distribution so that it is > structured similar to e.g. the Maven distribution > (http://apache.imsam.info/wicket/1.4-rc1/apache-wicket-1.4-rc1.zip ) and > send the whole thing back to me. I will then make sure, that for our next > release the distribution will look like this. > > > > I understand you, you would rather recommend leaving the current > distribution as it is and just add the pom.xml files for building the > project and for building the examples. > > > > So the only thing we're still not clear about, is what the distribution > file should look like. > > > > Do you agree with that? > > > > Regards > > Rainer > > > > Francis De Brabandere wrote: > >> Betreff: Re: Empire-db and Empire-Struts2-ext distribution with Maven > >> support > >> > >> Rainer, > >> > >> I'm still not sure we are talking about the same things as you keep > >> mentioning the 'distribution'... In the maven world your distribution > >> is uploading artifacts to a maven repository. So for maven users you > >> want to set up that repository. There is no need to change anything in > >> the current distribution layout/files. I would only create a pom file > >> for each artifact and upload that that together with the jar, src jar > >> and doc jar to a repository. (this will however take time on every > >> release and we want to keep this period short and go to step 2 [full > >> maven build] as fast as possible) > >> > >> The only remaining thing I need here is the *direct* dependencies for > >> the struts2 ext. > >> > >> [step 2] > >> Now if we talk about the source repo (subversion) and you want to > >> migrate the project to maven the repository should be restructured > >> (like wicket). As an option you may want to keep the ant build > >> available (update the build.xml). Once this is taken care of we can > >> define the "distribution" in the maven build and from then on maven > >> will generate the distribution file (that can be used by non-maven > >> users). > >> see this file for an example distribution configuration: > >> http://svn.apache.org/repos/asf/wicket/trunk/wicket-assembly-all.xml > >> > >> I hope I made myself clear this time :-) > >> > >> Regards, > >> > >> Francis > >> > >> > >> On Fri, Nov 28, 2008 at 10:52 PM, Rainer Döbele <[EMAIL PROTECTED]> > wrote: > >> > Hi Francis, > >> > > >> > do whatever needs to be done for step 1. > >> > > >> > As fas as the distribution layout is concerned I was having a look at > >> other Apache projects and how they do it. > >> > Take e.g. Apache Wicket > >> (http://www.apache.org/dyn/closer.cgi/wicket/1.4-rc1) or Apache CXF > >> (http://cxf.apache.org/download.html) > >> > > >> > We should structure our distribution in a similar fashion so that it > >> best fits Maven. > >> > But if you think that we can leave our layout and just add the pom- > files > >> that's fine by me. > >> > > >> > I know that the dependencies are not supplied with the Apache Wicket > and > >> Apache CXF distribtions but are fechted by Maven. > >> > The question is, can we still provide the jars in order to allow a > >> simple ant build and leave Maven as an option? > >> > > >> > Whatever you do, it should be a good solutions that give the user an > >> adavantage over the existing approach. > >> > Let me know if I can be of any help. > >> > > >> > Regards > >> > Rainer > >> > > >> > P.S. Are you working a lot with databases and have you used Empire-db > so > >> far? > >> > > >> > > >> > Francis De Brabandere wrote: > >> >> Re: Information about the empire-struts2-ext distribution > >> >> > >> >> Rainer, > >> >> > >> >> Thanks for the info but I don't think we are talking about the same > >> thing. > >> >> Let's think about what a maven user would like from the empire-db > >> project. > >> >> > >> >> As a maven user you declare dependencies to other artifacts (jar's) > to > >> >> have them fetched on build/eclipse project setup time. So what you > >> >> gain is not having to download a distribution or whatever is used to > >> >> build the library you want to use. All you do is define where the > >> >> dependencies' artifacts are located (if not in the central repo) and > >> >> which they are. What you are talking about is that the user can > >> >> download the "distribution" and build it including samples using > >> >> maven. I don't see any value in that, I want to *build my* project > >> >> using maven and *use your* library without too much > >> >> configuration/setup. > >> >> > >> >> So what are the steps to provide empire as dependency in maven: > >> >> > >> >> - Create main jar, source jar, and javadoc jar > >> >> - Define pom for empire (including definitions of the dependencies) > >> >> - upload everything to a (temporary) repo that the users can define > in > >> >> their project setup. > >> >> > >> >> And these steps should be performed for the struts 2 ext as well. > >> >> > >> >> Now for dependencies definitions, maven has a system of transitive > >> >> dependencies, dependencies of dependencies. For example if we take > the > >> >> pom for struts2-core: > >> >> http://www.mvnrepository.com/artifact/org.apache.struts/struts2- > >> core/2.1.2 > >> >> you can see that this artifact depends on a lot of other artifacts. > >> >> That was why I was asking you to let me know what the *real* > >> >> dependencies are for empire struts2. There is no direct dependency > for > >> >> ognl I suppose, this is a struts2 dependency, not a empire struts2 > ext > >> >> one. > >> >> > >> >> The point is that preparing all the above is easily done when empire > >> >> is using using maven for its own build. And that would be step 2. > Once > >> >> the maven repo is set up we could also transform the DBWebSample to > a > >> >> maven build (as step 1.5) so that the example can be run using maven. > >> >> > >> >> Summary: set up a (temp) maven repo + transform sample to maven as > >> >> test, or move the whole empire build to maven (big bang) > >> >> > >> >> Regards, > >> >> > >> >> Francis > >> > > >> > > >> > >> > >> > >> -- > >> http://www.somatik.be > >> Microsoft gives you windows, Linux gives you the whole house. > > > > > > -- > http://www.somatik.be > Microsoft gives you windows, Linux gives you the whole house.
