RE: [Daytrader] Converting to Maven 2
-Original Message-
From: Matt Hogstrom [mailto:[EMAIL PROTECTED]
Sent: vendredi 21 octobre 2005 06:54
To: dev@geronimo.apache.org
Subject: Re: [Daytrader] Converting to Maven 2
I was referring to updating the artifacts themselves like daytrader-
plan.xml,
application.xml, etc.
Oh ok. The first step is to create a maven project that is used to create a
Geronimo distribution, say daytrader/applications/geronimo (or
daytrader/applications/business as in business layer). In the future
you'll also need a daytrader/applications/database project to do the same
for the database.
Actually I've sent an email yesterday to the Maven dev list to propose some
conventions for J2EE projects (see http://tinyurl.com/75z9q). My idea is to
run this by the community and use it for making the m2 build for daytrader.
This is what I'll cover in the book in the J2EE chapter.
Once you have that daytrader/applications/geronimo(or business) project you
can do the following in maven1:
- have dependencies on all artifacts referenced in the plan in the
project.xml file
- generate the plan files by transforming them into JSL files and iterate
over the dependencies to find out the full name with the version.
Or
- have dependencies on all artifacts referenced in the plan in the
project.xml file
- use Ant filter tokens (@@) in your plans
- use some custom maven.xml code to do the iteration over the dependencies
to find out the names an define the filters in maven.xml. Then copy the
files using filtering = on.
Thanks
-Vincent
-Original Message-
From: Matt Hogstrom [mailto:[EMAIL PROTECTED]
Sent: jeudi 20 octobre 2005 21:25
To: dev@geronimo.apache.org
Subject: Re: [Daytrader] Converting to Maven 2
Vincent,
I'll update the tree structure per your original note in terms of src
placement,
etc. One thing that we still need to do is update some of the
deployment
plans
and internal references to the artifacts (like the EJB jar). They are
currently
hardcoded with 1.0-SNAPSHOT as a suffix. I think David mentioned we
could
fix
this with Velocity but I haven't looked at that yet. Thoughts are
welcome.
Sure I can help. ATM all project.xml are using 1.0-SNAPSHOT (except
the
top level one which is using 1.0). I think they need to be aligned.
However I'm note sure I understand what you're saying.
If you want them all to use the parent's version simply do not define a
currentVersion tag in any project except the top level one (the one
that
they all depend on) and then use ${pom.currentVersion} in all
dependencies.
The only issue with this is when you deploy artifacts to a remote Maven
repo
(say ibiblio). Maven will not resolve the ${pom.currentVersion}
expression
and thus if some tools reads the POM from the remote repo they won't be
able
to figure out the version. This is true for example for the repo
converter
which runs on ibiblio and converts m1 POMs to m2. It'll keep
${pom.currentVersion} references, which has no meaning in m2. Thus if
someone using m2 then depends on your artifact, his project will fail to
build because m2 will fail to resolve ${pom.currentVersion}...
My suggestion is to keep the version in all dependencies for now. Just
make
them all the same. You need to decide whether you want 1.0 or 1.0-
SNAPSHOT.
Are there going to be releases of the daytrader app? If so, better to
use
1.0-SNAPSHOT everywhere and move to 1.0 when releasing. Then change them
all
to 1.1-SNAPSHOT.
I don't understand your point about velocity though.
thanks for helping out in this effort :)
[snip]
Thanks
-Vincent
Re: [Daytrader] Converting to Maven 2
Vincent, I'll update the tree structure per your original note in terms of src placement, etc. One thing that we still need to do is update some of the deployment plans and internal references to the artifacts (like the EJB jar). They are currently hardcoded with 1.0-SNAPSHOT as a suffix. I think David mentioned we could fix this with Velocity but I haven't looked at that yet. Thoughts are welcome. thanks for helping out in this effort :) Matt Vincent Massol wrote: Hi David, -Original Message- From: David Jencks [mailto:[EMAIL PROTECTED] Sent: mercredi 19 octobre 2005 20:20 To: dev@geronimo.apache.org Subject: Re: [Daytrader] Converting to Maven 2 [snip] - automated functional testing Do you have some way to do this outside a j2ee server? If not, what does this mean? Yes, this is white box testing from outside. I'm planning to do this with Cargo (which supports several containers). - automated deployment to Geronimo or other container(s) (using Cargo) Does cargo support jsr-88 yet? Actually yes it does! :-) This is how I'm planning to automate hot-deployment to Geronimo. This feature is in Cargo 0.7 (not released yet). - ability to build for different target environments What does this mean? IIUC the ear is supposed to be portable, and the deployment plan is not included in the ear. Two things here: - yes it seems the EAR in Geronimo is portable with the deployment plan being outside of the EAR. However this is not the case for other containers. Also, there is still the deployment step which is environment-dependent: it may not be the same plan to deploy for a development environment and for a production one (for example you may want to use port 8080 in development and port 80 in production, or better you may want to deploy on a single server in development and on a cluster node in production, etc). - the build will not consist only in building the J2EE archives but also in the configuration files, database files, etc, which may be environment-dependent. I also know projects which do development using a container and deploy on another one... (not that this is a good practice!). - distribution of a packaged zip containing not only the EAR but also the container's configuration. This is to version control the container's config files and make the app executable and separated from the container's install. I'm not sure what you mean. We have a couple of possibly relevant capabilities of which I will mention the maven 1 plugin to install a geronimo instance and do stuff like start/stop it, deploy/undeploy apps, etc. Imagine a build that spans the full development lifecycle. What I've done in the past is automate everything till the pre-production step. This means I'm able to take the source code and build and deploy everything to the target platforms. This includes container configuration files (I don't enough about Geronimo yet but for WebLogic this means a domain configuration with all the files that go there; for jboss that means a server configuration directory, etc). The idea is that what is delivered is a zip representing a directory with everything set up in the right place there so that the container can be started in-place in that directory. The container config files are still located where the container is installed but its configuration is located in our directory. This allows redelivering easily the part that we want to store in our SCM. Maybe this does not apply to recent containers like Geronimo and maybe Geronimo is flexible enough so that a full container config can be set up from remotely. This is a strategy I have been applying between 2002 and 2004. It may be that since 2005 containers are configurable enough not to require this anymore? Here's a question: is it possible for example to remotely configure the number of threads used by the ejb or servlet containers? Is it possible to remotely control the location where logs files will go, etc? In any case, there's still the need to not only package the J2EE modules but also the configuration files (whether those files are installed locally or through remote access). This makes up a distribution which can then be installed manually by, say, a production team or through Maven (by using deploy/undeploy stuff as you mention above). - automate the database setup This would be great. I think we need a generic solution for this Agreed, although it'll have to be per-database type (unless someone comes up with a generic API in the same manner as Cargo does for containers ;-)). I'll do the derby one as it seems there are already some derby script for the Daytrader app. - possibly convert some of the daytrader app to use xdoclet to demonstrate how it works with Maven2 After thinking this through, I think I'm going to work in my own repo. This is the easiest and fastest solution for me. Once I have finished, I can then offer this full m2 build to the Geronimo project
RE: [Daytrader] Converting to Maven 2
-Original Message-
From: Matt Hogstrom [mailto:[EMAIL PROTECTED]
Sent: jeudi 20 octobre 2005 21:25
To: dev@geronimo.apache.org
Subject: Re: [Daytrader] Converting to Maven 2
Vincent,
I'll update the tree structure per your original note in terms of src
placement,
etc. One thing that we still need to do is update some of the deployment
plans
and internal references to the artifacts (like the EJB jar). They are
currently
hardcoded with 1.0-SNAPSHOT as a suffix. I think David mentioned we could
fix
this with Velocity but I haven't looked at that yet. Thoughts are
welcome.
Sure I can help. ATM all project.xml are using 1.0-SNAPSHOT (except the
top level one which is using 1.0). I think they need to be aligned.
However I'm note sure I understand what you're saying.
If you want them all to use the parent's version simply do not define a
currentVersion tag in any project except the top level one (the one that
they all depend on) and then use ${pom.currentVersion} in all dependencies.
The only issue with this is when you deploy artifacts to a remote Maven repo
(say ibiblio). Maven will not resolve the ${pom.currentVersion} expression
and thus if some tools reads the POM from the remote repo they won't be able
to figure out the version. This is true for example for the repo converter
which runs on ibiblio and converts m1 POMs to m2. It'll keep
${pom.currentVersion} references, which has no meaning in m2. Thus if
someone using m2 then depends on your artifact, his project will fail to
build because m2 will fail to resolve ${pom.currentVersion}...
My suggestion is to keep the version in all dependencies for now. Just make
them all the same. You need to decide whether you want 1.0 or 1.0-SNAPSHOT.
Are there going to be releases of the daytrader app? If so, better to use
1.0-SNAPSHOT everywhere and move to 1.0 when releasing. Then change them all
to 1.1-SNAPSHOT.
I don't understand your point about velocity though.
thanks for helping out in this effort :)
[snip]
Thanks
-Vincent
Re: [Daytrader] Converting to Maven 2
I was referring to updating the artifacts themselves like daytrader-plan.xml,
application.xml, etc.
Vincent Massol wrote:
-Original Message-
From: Matt Hogstrom [mailto:[EMAIL PROTECTED]
Sent: jeudi 20 octobre 2005 21:25
To: dev@geronimo.apache.org
Subject: Re: [Daytrader] Converting to Maven 2
Vincent,
I'll update the tree structure per your original note in terms of src
placement,
etc. One thing that we still need to do is update some of the deployment
plans
and internal references to the artifacts (like the EJB jar). They are
currently
hardcoded with 1.0-SNAPSHOT as a suffix. I think David mentioned we could
fix
this with Velocity but I haven't looked at that yet. Thoughts are
welcome.
Sure I can help. ATM all project.xml are using 1.0-SNAPSHOT (except the
top level one which is using 1.0). I think they need to be aligned.
However I'm note sure I understand what you're saying.
If you want them all to use the parent's version simply do not define a
currentVersion tag in any project except the top level one (the one that
they all depend on) and then use ${pom.currentVersion} in all dependencies.
The only issue with this is when you deploy artifacts to a remote Maven repo
(say ibiblio). Maven will not resolve the ${pom.currentVersion} expression
and thus if some tools reads the POM from the remote repo they won't be able
to figure out the version. This is true for example for the repo converter
which runs on ibiblio and converts m1 POMs to m2. It'll keep
${pom.currentVersion} references, which has no meaning in m2. Thus if
someone using m2 then depends on your artifact, his project will fail to
build because m2 will fail to resolve ${pom.currentVersion}...
My suggestion is to keep the version in all dependencies for now. Just make
them all the same. You need to decide whether you want 1.0 or 1.0-SNAPSHOT.
Are there going to be releases of the daytrader app? If so, better to use
1.0-SNAPSHOT everywhere and move to 1.0 when releasing. Then change them all
to 1.1-SNAPSHOT.
I don't understand your point about velocity though.
thanks for helping out in this effort :)
[snip]
Thanks
-Vincent
Re: [Daytrader] Converting to Maven 2
I would prefer daytrader working with maven 1.02 for a little while, till we convert the core geronimo code to Maven 2. Or we can provide a way to switch to build daytrader easily between maven 1.02 and 2? --- Matt Hogstrom [EMAIL PROTECTED] wrote: Go ahead and open a JIRA and post the patches and I'll take a look at the changes we need to make. I think most folks are of the mind to go for M2 after we get V1.0 out the door (hopefully later this year) Vincent Massol wrote: -Original Message- From: Matt Hogstrom [mailto:[EMAIL PROTECTED] Sent: mardi 18 octobre 2005 15:43 To: Vincent Massol Subject: Re: [Daytrader] Converting to Maven 2 Vincent, This is great. UI'd be happy to pull your changes into the sandbox. One question I have is the compatibility with maven 1. Is it possible to commit your changes and folks that are still using maven 1 would be able to build? Sure. I've been careful not to break the Maven 1 build. Also, m1 and m2 can coexist pacifically so there shouldn't be problems. The only issue is supporting both builds over time which is a bit tiresome. I'd suggest switching to a pure Maven 2 build whenever possible (maybe when Geronimo switches to Maven 2). If that is the case then I say let's move forward with the migration. Great. How do you want to proceed? Others? I think you meant to reply to everyone, so I'm cc-ing the Geronimo list... :-) Thanks -Vincent Vincent Massol wrote: Hi, I have discussed offline with Matt (a month or so back) who told me he'd be interested in porting the daytrader application to Maven 2. I'd like to help. My incentive is that I'd like to feature the daytrader application in a book chapter I'm writing (Maven 2 book). I've started modifying the daytrader build on my machine to make it comply with Maven 2 directory structure. I've kept the maven 1 build working. Basically here are the steps I've done: - moved all sources in src/main/java - moved all resources in src/main/resources - removed all tests (as they were not real tests - they were just fake tests probably generated by the genapp plugin) - removed some other genapp files (App.java, etc) - removed the core module which consists only in a genapp generated project - have the ear application.xml file generated by the ear plugin - fixed some project.xml stuff (like renaming id into artifactId, etc) - some other minor stuff (indentation fixes, etc) Is that ok to be committed? I'd like to know if you're still interested in doing this Maven 2 migration. If so how would you like to do it: a/ directly on the trunk in sandbox/daytrader b/ in a branch c/ somewhere else. I could leave your build code untouched and do all the migration in a separate SVN for the book. I think a/ should be the best option. Should I open a JIRA issue for this? How easy would it be possible for me to get commit access, etc? The next steps I'd like to perform are: - discuss with you about reorganizing the full directory structure to incorporate more things in the build: packaging, deployment, functional tests, etc. - create the m2 pom.xml files - write automated functional tests Thanks -Vincent thanks, Lin __ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com
Re: [Daytrader] Converting to Maven 2
They can live concurrently, since they are differnt files (pom.xml vs project.xml/maven.xml). This should have no impact as long as the directpry structures remain the same. Jeff Lin Sun wrote: I would prefer daytrader working with maven 1.02 for a little while, till we convert the core geronimo code to Maven 2. Or we can provide a way to switch to build daytrader easily between maven 1.02 and 2? --- Matt Hogstrom [EMAIL PROTECTED] wrote: Go ahead and open a JIRA and post the patches and I'll take a look at the changes we need to make. I think most folks are of the mind to go for M2 after we get V1.0 out the door (hopefully later this year) Vincent Massol wrote: -Original Message- From: Matt Hogstrom [mailto:[EMAIL PROTECTED] Sent: mardi 18 octobre 2005 15:43 To: Vincent Massol Subject: Re: [Daytrader] Converting to Maven 2 Vincent, This is great. UI'd be happy to pull your changes into the sandbox. One question I have is the compatibility with maven 1. Is it possible to commit your changes and folks that are still using maven 1 would be able to build? Sure. I've been careful not to break the Maven 1 build. Also, m1 and m2 can coexist pacifically so there shouldn't be problems. The only issue is supporting both builds over time which is a bit tiresome. I'd suggest switching to a pure Maven 2 build whenever possible (maybe when Geronimo switches to Maven 2). If that is the case then I say let's move forward with the migration. Great. How do you want to proceed? Others? I think you meant to reply to everyone, so I'm cc-ing the Geronimo list... :-) Thanks -Vincent Vincent Massol wrote: Hi, I have discussed offline with Matt (a month or so back) who told me he'd be interested in porting the daytrader application to Maven 2. I'd like to help. My incentive is that I'd like to feature the daytrader application in a book chapter I'm writing (Maven 2 book). I've started modifying the daytrader build on my machine to make it comply with Maven 2 directory structure. I've kept the maven 1 build working. Basically here are the steps I've done: - moved all sources in src/main/java - moved all resources in src/main/resources - removed all tests (as they were not real tests - they were just fake tests probably generated by the genapp plugin) - removed some other genapp files (App.java, etc) - removed the core module which consists only in a genapp generated project - have the ear application.xml file generated by the ear plugin - fixed some project.xml stuff (like renaming id into artifactId, etc) - some other minor stuff (indentation fixes, etc) Is that ok to be committed? I'd like to know if you're still interested in doing this Maven 2 migration. If so how would you like to do it: a/ directly on the trunk in sandbox/daytrader b/ in a branch c/ somewhere else. I could leave your build code untouched and do all the migration in a separate SVN for the book. I think a/ should be the best option. Should I open a JIRA issue for this? How easy would it be possible for me to get commit access, etc? The next steps I'd like to perform are: - discuss with you about reorganizing the full directory structure to incorporate more things in the build: packaging, deployment, functional tests, etc. - create the m2 pom.xml files - write automated functional tests Thanks -Vincent thanks, Lin __ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com
RE: [Daytrader] Converting to Maven 2
-Original Message- From: Jeff Genender [mailto:[EMAIL PROTECTED] Sent: mercredi 19 octobre 2005 16:53 To: dev@geronimo.apache.org Subject: Re: [Daytrader] Converting to Maven 2 They can live concurrently, since they are differnt files (pom.xml vs project.xml/maven.xml). This should have no impact as long as the directpry structures remain the same. Currently, the daytrader build doesn't do much. It just builds an EAR. I'd like to convert to build to do more: - automated functional testing - automated deployment to Geronimo or other container(s) (using Cargo) - ability to build for different target environments - distribution of a packaged zip containing not only the EAR but also the container's configuration. This is to version control the container's config files and make the app executable and separated from the container's install. - automate the database setup - possibly convert some of the daytrader app to use xdoclet to demonstrate how it works with Maven2 After thinking this through, I think I'm going to work in my own repo. This is the easiest and fastest solution for me. Once I have finished, I can then offer this full m2 build to the Geronimo project and you can decide to do whatever you want with it. I won't be touching much of the daytrader source files so it shouldn't be that hard to incorporate afterwards. Thanks -Vincent Lin Sun wrote: I would prefer daytrader working with maven 1.02 for a little while, till we convert the core geronimo code to Maven 2. Or we can provide a way to switch to build daytrader easily between maven 1.02 and 2? --- Matt Hogstrom [EMAIL PROTECTED] wrote: Go ahead and open a JIRA and post the patches and I'll take a look at the changes we need to make. I think most folks are of the mind to go for M2 after we get V1.0 out the door (hopefully later this year) Vincent Massol wrote: -Original Message- From: Matt Hogstrom [mailto:[EMAIL PROTECTED] Sent: mardi 18 octobre 2005 15:43 To: Vincent Massol Subject: Re: [Daytrader] Converting to Maven 2 Vincent, This is great. UI'd be happy to pull your changes into the sandbox. One question I have is the compatibility with maven 1. Is it possible to commit your changes and folks that are still using maven 1 would be able to build? Sure. I've been careful not to break the Maven 1 build. Also, m1 and m2 can coexist pacifically so there shouldn't be problems. The only issue is supporting both builds over time which is a bit tiresome. I'd suggest switching to a pure Maven 2 build whenever possible (maybe when Geronimo switches to Maven 2). If that is the case then I say let's move forward with the migration. Great. How do you want to proceed? Others? I think you meant to reply to everyone, so I'm cc-ing the Geronimo list... :-) Thanks -Vincent Vincent Massol wrote: Hi, I have discussed offline with Matt (a month or so back) who told me he'd be interested in porting the daytrader application to Maven 2. I'd like to help. My incentive is that I'd like to feature the daytrader application in a book chapter I'm writing (Maven 2 book). I've started modifying the daytrader build on my machine to make it comply with Maven 2 directory structure. I've kept the maven 1 build working. Basically here are the steps I've done: - moved all sources in src/main/java - moved all resources in src/main/resources - removed all tests (as they were not real tests - they were just fake tests probably generated by the genapp plugin) - removed some other genapp files (App.java, etc) - removed the core module which consists only in a genapp generated project - have the ear application.xml file generated by the ear plugin - fixed some project.xml stuff (like renaming id into artifactId, etc) - some other minor stuff (indentation fixes, etc) Is that ok to be committed? I'd like to know if you're still interested in doing this Maven 2 migration. If so how would you like to do it: a/ directly on the trunk in sandbox/daytrader b/ in a branch c/ somewhere else. I could leave your build code untouched and do all the migration in a separate SVN for the book. I think a/ should be the best option. Should I open a JIRA issue for this? How easy would it be possible for me to get commit access, etc? The next steps I'd like to perform are: - discuss with you about reorganizing the full directory structure to incorporate more things in the build: packaging, deployment, functional tests, etc. - create the m2 pom.xml files - write automated functional tests Thanks -Vincent
Re: [Daytrader] Converting to Maven 2
On Oct 19, 2005, at 9:49 AM, Vincent Massol wrote: -Original Message- From: Jeff Genender [mailto:[EMAIL PROTECTED] Sent: mercredi 19 octobre 2005 16:53 To: dev@geronimo.apache.org Subject: Re: [Daytrader] Converting to Maven 2 They can live concurrently, since they are differnt files (pom.xml vs project.xml/maven.xml). This should have no impact as long as the directpry structures remain the same. Currently, the daytrader build doesn't do much. It just builds an EAR. I'd like to convert to build to do more: - automated functional testing Do you have some way to do this outside a j2ee server? If not, what does this mean? - automated deployment to Geronimo or other container(s) (using Cargo) Does cargo support jsr-88 yet? - ability to build for different target environments What does this mean? IIUC the ear is supposed to be portable, and the deployment plan is not included in the ear. - distribution of a packaged zip containing not only the EAR but also the container's configuration. This is to version control the container's config files and make the app executable and separated from the container's install. I'm not sure what you mean. We have a couple of possibly relevant capabilities of which I will mention the maven 1 plugin to install a geronimo instance and do stuff like start/stop it, deploy/undeploy apps, etc. - automate the database setup This would be great. I think we need a generic solution for this - possibly convert some of the daytrader app to use xdoclet to demonstrate how it works with Maven2 After thinking this through, I think I'm going to work in my own repo. This is the easiest and fastest solution for me. Once I have finished, I can then offer this full m2 build to the Geronimo project and you can decide to do whatever you want with it. I won't be touching much of the daytrader source files so it shouldn't be that hard to incorporate afterwards. I think this is great, and would like to know more about what you are up to. Please keep us informed! thanks david jencks
[Daytrader] Converting to Maven 2
Hi, I have discussed offline with Matt (a month or so back) who told me he'd be interested in porting the daytrader application to Maven 2. I'd like to help. My incentive is that I'd like to feature the daytrader application in a book chapter I'm writing (Maven 2 book). I've started modifying the daytrader build on my machine to make it comply with Maven 2 directory structure. I've kept the maven 1 build working. Basically here are the steps I've done: - moved all sources in src/main/java - moved all resources in src/main/resources - removed all tests (as they were not real tests - they were just fake tests probably generated by the genapp plugin) - removed some other genapp files (App.java, etc) - removed the core module which consists only in a genapp generated project - have the ear application.xml file generated by the ear plugin - fixed some project.xml stuff (like renaming id into artifactId, etc) - some other minor stuff (indentation fixes, etc) Is that ok to be committed? I'd like to know if you're still interested in doing this Maven 2 migration. If so how would you like to do it: a/ directly on the trunk in sandbox/daytrader b/ in a branch c/ somewhere else. I could leave your build code untouched and do all the migration in a separate SVN for the book. I think a/ should be the best option. Should I open a JIRA issue for this? How easy would it be possible for me to get commit access, etc? The next steps I'd like to perform are: - discuss with you about reorganizing the full directory structure to incorporate more things in the build: packaging, deployment, functional tests, etc. - create the m2 pom.xml files - write automated functional tests Thanks -Vincent
RE: [Daytrader] Converting to Maven 2
-Original Message- From: Matt Hogstrom [mailto:[EMAIL PROTECTED] Sent: mardi 18 octobre 2005 15:43 To: Vincent Massol Subject: Re: [Daytrader] Converting to Maven 2 Vincent, This is great. UI'd be happy to pull your changes into the sandbox. One question I have is the compatibility with maven 1. Is it possible to commit your changes and folks that are still using maven 1 would be able to build? Sure. I've been careful not to break the Maven 1 build. Also, m1 and m2 can coexist pacifically so there shouldn't be problems. The only issue is supporting both builds over time which is a bit tiresome. I'd suggest switching to a pure Maven 2 build whenever possible (maybe when Geronimo switches to Maven 2). If that is the case then I say let's move forward with the migration. Great. How do you want to proceed? Others? I think you meant to reply to everyone, so I'm cc-ing the Geronimo list... :-) Thanks -Vincent Vincent Massol wrote: Hi, I have discussed offline with Matt (a month or so back) who told me he'd be interested in porting the daytrader application to Maven 2. I'd like to help. My incentive is that I'd like to feature the daytrader application in a book chapter I'm writing (Maven 2 book). I've started modifying the daytrader build on my machine to make it comply with Maven 2 directory structure. I've kept the maven 1 build working. Basically here are the steps I've done: - moved all sources in src/main/java - moved all resources in src/main/resources - removed all tests (as they were not real tests - they were just fake tests probably generated by the genapp plugin) - removed some other genapp files (App.java, etc) - removed the core module which consists only in a genapp generated project - have the ear application.xml file generated by the ear plugin - fixed some project.xml stuff (like renaming id into artifactId, etc) - some other minor stuff (indentation fixes, etc) Is that ok to be committed? I'd like to know if you're still interested in doing this Maven 2 migration. If so how would you like to do it: a/ directly on the trunk in sandbox/daytrader b/ in a branch c/ somewhere else. I could leave your build code untouched and do all the migration in a separate SVN for the book. I think a/ should be the best option. Should I open a JIRA issue for this? How easy would it be possible for me to get commit access, etc? The next steps I'd like to perform are: - discuss with you about reorganizing the full directory structure to incorporate more things in the build: packaging, deployment, functional tests, etc. - create the m2 pom.xml files - write automated functional tests Thanks -Vincent
Re: [Daytrader] Converting to Maven 2
Go ahead and open a JIRA and post the patches and I'll take a look at the changes we need to make. I think most folks are of the mind to go for M2 after we get V1.0 out the door (hopefully later this year) Vincent Massol wrote: -Original Message- From: Matt Hogstrom [mailto:[EMAIL PROTECTED] Sent: mardi 18 octobre 2005 15:43 To: Vincent Massol Subject: Re: [Daytrader] Converting to Maven 2 Vincent, This is great. UI'd be happy to pull your changes into the sandbox. One question I have is the compatibility with maven 1. Is it possible to commit your changes and folks that are still using maven 1 would be able to build? Sure. I've been careful not to break the Maven 1 build. Also, m1 and m2 can coexist pacifically so there shouldn't be problems. The only issue is supporting both builds over time which is a bit tiresome. I'd suggest switching to a pure Maven 2 build whenever possible (maybe when Geronimo switches to Maven 2). If that is the case then I say let's move forward with the migration. Great. How do you want to proceed? Others? I think you meant to reply to everyone, so I'm cc-ing the Geronimo list... :-) Thanks -Vincent Vincent Massol wrote: Hi, I have discussed offline with Matt (a month or so back) who told me he'd be interested in porting the daytrader application to Maven 2. I'd like to help. My incentive is that I'd like to feature the daytrader application in a book chapter I'm writing (Maven 2 book). I've started modifying the daytrader build on my machine to make it comply with Maven 2 directory structure. I've kept the maven 1 build working. Basically here are the steps I've done: - moved all sources in src/main/java - moved all resources in src/main/resources - removed all tests (as they were not real tests - they were just fake tests probably generated by the genapp plugin) - removed some other genapp files (App.java, etc) - removed the core module which consists only in a genapp generated project - have the ear application.xml file generated by the ear plugin - fixed some project.xml stuff (like renaming id into artifactId, etc) - some other minor stuff (indentation fixes, etc) Is that ok to be committed? I'd like to know if you're still interested in doing this Maven 2 migration. If so how would you like to do it: a/ directly on the trunk in sandbox/daytrader b/ in a branch c/ somewhere else. I could leave your build code untouched and do all the migration in a separate SVN for the book. I think a/ should be the best option. Should I open a JIRA issue for this? How easy would it be possible for me to get commit access, etc? The next steps I'd like to perform are: - discuss with you about reorganizing the full directory structure to incorporate more things in the build: packaging, deployment, functional tests, etc. - create the m2 pom.xml files - write automated functional tests Thanks -Vincent
