You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@empire-db.apache.org by Rainer Döbele <do...@esteam.de> on 2008/11/28 22:52:09 UTC
Empire-db and Empire-Struts2-ext distribution with Maven support
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
AW: Empire-db and Empire-Struts2-ext distribution with Maven support
Posted by Jörg Reiher <re...@esteam.de>.
Hi Francis,
If you have the time, then I'd prefer the "Big Bang".
In addition to the already mentioned advantages of Maven (no dependencies in the svn, easier access for Maven users) this would also ease the pain of packaging a new release for Non-Maven-users, cause Maven can generate the tar.gz/zip and all the md5/sha/asc files automatically.
Till now I couldn't find a way to create all this without jumping through some console scripts.
So I'd propose that you provide a zip file with the "mavenized" structure that we can put in the empire-db svn.
If this is too much of a hazzle for now, then step 1 (providing Maven dependencies for empire-db / empire-struts-ext) + 1.5 (adapt only WebSample to Maven style and use the Maven dependencies of step 1) would be an option.
So far,
Greetings
Jörg
> -----Ursprüngliche Nachricht-----
> Von: Francis De Brabandere [mailto:francisdb@gmail.com]
> Gesendet: Samstag, 29. November 2008 11:55
> An: empire-db-dev@incubator.apache.org
> 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 <do...@esteam.de>
> 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.
Re: Empire-db and Empire-Struts2-ext distribution with Maven support
Posted by Martijn Dashorst <ma...@gmail.com>.
You fail to see what Maven is: it is not a build tool, it is a
distribution mechanism. You don't typically distribute a zip file with
a maven build inside, you distribute your project through maven. You
distribute your empire-db jars through the maven repository, you
distribute your source through maven and you distribute your javadoc
through maven, and you build a source/binary distribution for those
that don't use maven, with maven.
A maven pom inside the distribution is only beneficial for those that
want to build themselves from source, but the vast majority just wants
to get started with the product and not go on a jar hunt, or have to
manually install jars into their own maven repository.
To put things in perspective: with Wicket the vast majority of our
users obtain Wicket through maven. I might even say 70%-80%.
Therefore I agree with Francis that the main build should be based on
maven, not the distribution.
Martijn
On Wed, Dec 3, 2008 at 10:24 AM, Rainer Döbele <do...@esteam.de> wrote:
> 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 <do...@esteam.de> 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 <do...@esteam.de>
>> 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.
>
--
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.3.4 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
Re: Empire-db and Empire-Struts2-ext distribution with Maven support
Posted by Rainer Döbele <do...@esteam.de>.
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 <do...@esteam.de> 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 <do...@esteam.de>
> 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.
Re: Empire-db and Empire-Struts2-ext distribution with Maven support
Posted by Francis De Brabandere <fr...@gmail.com>.
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 <do...@esteam.de> 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 <do...@esteam.de> 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.
Re: Empire-db and Empire-Struts2-ext distribution with Maven support
Posted by Rainer Döbele <do...@esteam.de>.
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 <do...@esteam.de> 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.
Re: Empire-db and Empire-Struts2-ext distribution with Maven support
Posted by Francis De Brabandere <fr...@gmail.com>.
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 <do...@esteam.de> 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.