Re: M2 Issues and Actions
FYI... issue opened to fix the problem using extensions here: http://jira.codehaus.org/browse/MNG-1911 And you were right... m2 will reload the plugin :-) --jason On Jul 3, 2006, at 3:26 PM, anita kulshreshtha wrote: I used our project. Here are the steps - 1. add a print statements to say PackageBuilderShellMojo. 2. To make this test go faster comment out modules, applications from the parent pom. 3. use mvn clean install The .m2 Repo already has a packaging plugin with version 1.2.0. So maven happily builds. After the plugin is built, the configs are built. That is when the "reloading plugin container " message appears. You should see the message you added to the packaging plugin. The message should appear in all the configs except may be gbean-deployer. The gbean-delpoyer config is a special case, you must make sure that the new statement is executed. Thanks Anita --- Jason Dillon <[EMAIL PROTECTED]> wrote: Do you have an simple example project that implements the build and use of the plugin in the same cycle that I can peek at? --jason On Jul 3, 2006, at 5:59 AM, anita kulshreshtha wrote: inline.. --- Jason Dillon <[EMAIL PROTECTED]> wrote: While this may work most of the time, it is not ideal as when making changes to plugins, users will be mystified when those changes are not used on the first build. This is not true. The plugin is *not* used before it is built. The problem is that maven does not even start the build until it has downloaded all the plugins. Even a dummy plugin would work. Um... it is completely true. I am aware that the plugin is not used before it is built. BUT the point that I was making was that Maven must resolve the plugin before the build commences... that means that the plugin must exist in a repository (or cache) already, and that is the version that will be used for the current build cycle... NOT the plugin that will be compiled and installed as part of the current build. Therefor the current build will always use the version of the plugin that was built BEFORE the build started, NOT the version that is actually getting built. I ran a test. A totally bogus plugin will not work, but a plugin with correctly defined component.xml will work. Maven indeed uses the plugin that was built (see the message below). If we want to use SNAPSHOT versions for the plugin, we can create a skeletal dummy plugin (s) and publish it. And the build will work like charm with just 'mvn'! If we want to use numbered versions like M1, we need multi step build. Whenever the version is changed we will have to use 'mvn' more than once to get a full build. Thanks Anita m [INFO] -- -- [INFO] Building Geronimo Configuration for performing service deployments [INFO]task-segment: [clean, install] [INFO] -- -- [INFO] Reloading plugin container for: org.apache.geronimo.plugins:geronimo-packaging-plugin. The pl ugin artifact has changed. [INFO] [clean:clean] [INFO] Deleting directory D:\anita\geronimo\geronimo-1.2\configs\geronimo-gbean-deployer\target [INFO] Deleting directory D:\anita\geronimo\geronimo-1.2\configs\geronimo-gbean-deployer \target\clas ses [INFO] Deleting directory D:\anita\geronimo\geronimo-1.2\configs\geronimo-gbean-deployer \target\test -classes This is why I suggested that the plugin either be part of another project (detached from the main build) or as part of a bootstrap phase that is executed before the main build cycle. --jason __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: M2 Issues and Actions
I used our project. Here are the steps - 1. add a print statements to say PackageBuilderShellMojo. 2. To make this test go faster comment out modules, applications from the parent pom. 3. use mvn clean install The .m2 Repo already has a packaging plugin with version 1.2.0. So maven happily builds. After the plugin is built, the configs are built. That is when the "reloading plugin container " message appears. You should see the message you added to the packaging plugin. The message should appear in all the configs except may be gbean-deployer. The gbean-delpoyer config is a special case, you must make sure that the new statement is executed. Thanks Anita --- Jason Dillon <[EMAIL PROTECTED]> wrote: > Do you have an simple example project that implements the build and > use of the plugin in the same cycle that I can peek at? > > --jason > > > On Jul 3, 2006, at 5:59 AM, anita kulshreshtha wrote: > > > inline.. > > > > --- Jason Dillon <[EMAIL PROTECTED]> wrote: > > > While this may work most of the time, it is not ideal as when > >> making > changes to plugins, users will be mystified when those changes > are > not used on the first build. > >>> > >>>This is not true. The plugin is *not* used before it is built. > >> The > >>> problem is that maven does not even start the build until it has > >>> downloaded all the plugins. Even a dummy plugin would work. > >> > >> Um... it is completely true. I am aware that the plugin is not > used > >> > >> before it is built. > >> > >> BUT the point that I was making was that Maven must resolve the > >> plugin before the build commences... that means that the plugin > must > >> > >> exist in a repository (or cache) already, and that is the version > >> that will be used for the current build cycle... NOT the plugin > that > >> > >> will be compiled and installed as part of the current build. > >> > >> Therefor the current build will always use the version of the > plugin > >> > >> that was built BEFORE the build started, NOT the version that is > >> actually getting built. > > > > I ran a test. A totally bogus plugin will not work, but a > plugin > > with correctly defined component.xml will work. Maven indeed uses > the > > plugin that was built (see the message below). If we want to use > > SNAPSHOT versions for the plugin, we can create a skeletal dummy > > plugin > > (s) and publish it. And the build will work like charm with just > > 'mvn'! > > If we want to use numbered versions like M1, we need multi step > > build. Whenever the version is changed we will have to use 'mvn' > more > > than once to get a full build. > > > > Thanks > > Anita > > > > m > > [INFO] > > > -- > > > -- > > [INFO] Building Geronimo Configuration for performing service > > deployments > > [INFO]task-segment: [clean, install] > > [INFO] > > > -- > > > -- > > [INFO] Reloading plugin container for: > > org.apache.geronimo.plugins:geronimo-packaging-plugin. The pl > > ugin artifact has changed. > > [INFO] [clean:clean] > > [INFO] Deleting directory > > > D:\anita\geronimo\geronimo-1.2\configs\geronimo-gbean-deployer\target > > [INFO] Deleting directory > > D:\anita\geronimo\geronimo-1.2\configs\geronimo-gbean-deployer > > \target\clas > > ses > > [INFO] Deleting directory > > D:\anita\geronimo\geronimo-1.2\configs\geronimo-gbean-deployer > > \target\test > > -classes > >> > >> This is why I suggested that the plugin either be part of another > >> project (detached from the main build) or as part of a bootstrap > >> phase that is executed before the main build cycle. > >> > >> --jason > >> > >> > >> > > > > > > __ > > Do You Yahoo!? > > Tired of spam? Yahoo! Mail has the best spam protection around > > http://mail.yahoo.com > > __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: M2 Issues and Actions
Did want happens when you `mvn clean` after a clean check out and have an empty repository? --jason On Jul 3, 2006, at 5:59 AM, anita kulshreshtha wrote: inline.. --- Jason Dillon <[EMAIL PROTECTED]> wrote: While this may work most of the time, it is not ideal as when making changes to plugins, users will be mystified when those changes are not used on the first build. This is not true. The plugin is *not* used before it is built. The problem is that maven does not even start the build until it has downloaded all the plugins. Even a dummy plugin would work. Um... it is completely true. I am aware that the plugin is not used before it is built. BUT the point that I was making was that Maven must resolve the plugin before the build commences... that means that the plugin must exist in a repository (or cache) already, and that is the version that will be used for the current build cycle... NOT the plugin that will be compiled and installed as part of the current build. Therefor the current build will always use the version of the plugin that was built BEFORE the build started, NOT the version that is actually getting built. I ran a test. A totally bogus plugin will not work, but a plugin with correctly defined component.xml will work. Maven indeed uses the plugin that was built (see the message below). If we want to use SNAPSHOT versions for the plugin, we can create a skeletal dummy plugin (s) and publish it. And the build will work like charm with just 'mvn'! If we want to use numbered versions like M1, we need multi step build. Whenever the version is changed we will have to use 'mvn' more than once to get a full build. Thanks Anita m [INFO] -- -- [INFO] Building Geronimo Configuration for performing service deployments [INFO]task-segment: [clean, install] [INFO] -- -- [INFO] Reloading plugin container for: org.apache.geronimo.plugins:geronimo-packaging-plugin. The pl ugin artifact has changed. [INFO] [clean:clean] [INFO] Deleting directory D:\anita\geronimo\geronimo-1.2\configs\geronimo-gbean-deployer\target [INFO] Deleting directory D:\anita\geronimo\geronimo-1.2\configs\geronimo-gbean-deployer \target\clas ses [INFO] Deleting directory D:\anita\geronimo\geronimo-1.2\configs\geronimo-gbean-deployer \target\test -classes This is why I suggested that the plugin either be part of another project (detached from the main build) or as part of a bootstrap phase that is executed before the main build cycle. --jason __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: M2 Issues and Actions
Do you have an simple example project that implements the build and use of the plugin in the same cycle that I can peek at? --jason On Jul 3, 2006, at 5:59 AM, anita kulshreshtha wrote: inline.. --- Jason Dillon <[EMAIL PROTECTED]> wrote: While this may work most of the time, it is not ideal as when making changes to plugins, users will be mystified when those changes are not used on the first build. This is not true. The plugin is *not* used before it is built. The problem is that maven does not even start the build until it has downloaded all the plugins. Even a dummy plugin would work. Um... it is completely true. I am aware that the plugin is not used before it is built. BUT the point that I was making was that Maven must resolve the plugin before the build commences... that means that the plugin must exist in a repository (or cache) already, and that is the version that will be used for the current build cycle... NOT the plugin that will be compiled and installed as part of the current build. Therefor the current build will always use the version of the plugin that was built BEFORE the build started, NOT the version that is actually getting built. I ran a test. A totally bogus plugin will not work, but a plugin with correctly defined component.xml will work. Maven indeed uses the plugin that was built (see the message below). If we want to use SNAPSHOT versions for the plugin, we can create a skeletal dummy plugin (s) and publish it. And the build will work like charm with just 'mvn'! If we want to use numbered versions like M1, we need multi step build. Whenever the version is changed we will have to use 'mvn' more than once to get a full build. Thanks Anita m [INFO] -- -- [INFO] Building Geronimo Configuration for performing service deployments [INFO]task-segment: [clean, install] [INFO] -- -- [INFO] Reloading plugin container for: org.apache.geronimo.plugins:geronimo-packaging-plugin. The pl ugin artifact has changed. [INFO] [clean:clean] [INFO] Deleting directory D:\anita\geronimo\geronimo-1.2\configs\geronimo-gbean-deployer\target [INFO] Deleting directory D:\anita\geronimo\geronimo-1.2\configs\geronimo-gbean-deployer \target\clas ses [INFO] Deleting directory D:\anita\geronimo\geronimo-1.2\configs\geronimo-gbean-deployer \target\test -classes This is why I suggested that the plugin either be part of another project (detached from the main build) or as part of a bootstrap phase that is executed before the main build cycle. --jason __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: M2 Issues and Actions
On 7/3/06, anita kulshreshtha <[EMAIL PROTECTED]> wrote: I ran a test. A totally bogus plugin will not work, but a plugin with correctly defined component.xml will work. Maven indeed uses the plugin that was built (see the message below). If we want to use SNAPSHOT versions for the plugin, we can create a skeletal dummy plugin (s) and publish it. And the build will work like charm with just 'mvn'! If we want to use numbered versions like M1, we need multi step build. Whenever the version is changed we will have to use 'mvn' more than once to get a full build. Hi Anita, How does it apply to what Jason's working on in GERONIMO-2161? I think Jason has provided us a good solution for the issue - his latest patch http://issues.apache.org/jira/browse/GERONIMO-2161 should do the trick. I couldn't test it out as it blew out with Error assembling WAR: Deployment descriptor: c:\oss\GERONIMO-2082-2161\applications\demo\target\demo-1.2-SNAPSHOT\WEB-INF\web.xml does not exist. which seemed to me was not strictly related to the issue in question. (I've just noticed there's a brand new patch - on to testing it out) Anita Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: M2 Issues and Actions
inline.. --- Jason Dillon <[EMAIL PROTECTED]> wrote: > >> While this may work most of the time, it is not ideal as when > making > >> changes to plugins, users will be mystified when those changes are > >> not used on the first build. > > > >This is not true. The plugin is *not* used before it is built. > The > > problem is that maven does not even start the build until it has > > downloaded all the plugins. Even a dummy plugin would work. > > Um... it is completely true. I am aware that the plugin is not used > > before it is built. > > BUT the point that I was making was that Maven must resolve the > plugin before the build commences... that means that the plugin must > > exist in a repository (or cache) already, and that is the version > that will be used for the current build cycle... NOT the plugin that > > will be compiled and installed as part of the current build. > > Therefor the current build will always use the version of the plugin > > that was built BEFORE the build started, NOT the version that is > actually getting built. I ran a test. A totally bogus plugin will not work, but a plugin with correctly defined component.xml will work. Maven indeed uses the plugin that was built (see the message below). If we want to use SNAPSHOT versions for the plugin, we can create a skeletal dummy plugin (s) and publish it. And the build will work like charm with just 'mvn'! If we want to use numbered versions like M1, we need multi step build. Whenever the version is changed we will have to use 'mvn' more than once to get a full build. Thanks Anita m [INFO] [INFO] Building Geronimo Configuration for performing service deployments [INFO]task-segment: [clean, install] [INFO] [INFO] Reloading plugin container for: org.apache.geronimo.plugins:geronimo-packaging-plugin. The pl ugin artifact has changed. [INFO] [clean:clean] [INFO] Deleting directory D:\anita\geronimo\geronimo-1.2\configs\geronimo-gbean-deployer\target [INFO] Deleting directory D:\anita\geronimo\geronimo-1.2\configs\geronimo-gbean-deployer\target\clas ses [INFO] Deleting directory D:\anita\geronimo\geronimo-1.2\configs\geronimo-gbean-deployer\target\test -classes > > This is why I suggested that the plugin either be part of another > project (detached from the main build) or as part of a bootstrap > phase that is executed before the main build cycle. > > --jason > > > __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: M2 Issues and Actions
I see your point. Thanks for the explanation.--jasonOn Jul 1, 2006, at 2:31 PM, Alan D. Cabrera wrote: I am adamantly against pulling in code from a CodeHaus repository when I do a co from an ASF repo. Do I understand the proposed behavior correctly? Regards, Alan Jason Dillon wrote: I'd just like to know why you are really, really against it? I don't like it, but as a short-term solution I think it is okay. But, hopefully we will have openejb snaps deployed to a repo soon so we won't need to do this. --jason On Jun 30, 2006, at 7:56 AM, Alan D. Cabrera wrote: As I mentioned in a previous thread. I am really, really, against this. I'm happy to discuss this further. Regards, Alan Bill Dudney wrote:Hi Jacek, Yep just edit the svn:externals property on geronimo and you are done :-) TTFN, Bill Dudney MyFaces - http://myfaces.apache.org Cayenne - http://incubator.apache.org/projects/cayenne.html On Jun 29, 2006, at 3:40 PM, Jacek Laskowski wrote:On 6/29/06, Jason Dillon <[EMAIL PROTECTED]> wrote: Using svn:externals is probably the easiest way to the the openejb sources included for use in a m2 build w/o needing the user to run `maven -o m:co` or run `svn co ...` directly yo pull the sources for the build. I think this is the best short-term solution to the openejb integration issue. I would like to stress that we should eventually try to remove this source-level dependency for out long-term direction.Am I right that it's as simple as executing$ svn propget svn:externals geronimoopenejb https://svn.codehaus.org/openejb/trunk/openejb2?That seems to be an interim yet elegant solution. It's a bug fix so noneed to RTC it. --jasonJacek-- Jacek Laskowskihttp://www.laskowski.net.pl
Re: M2 Issues and Actions
On 7/1/06, Alan D. Cabrera <[EMAIL PROTECTED]> wrote: I am adamantly against pulling in code from a CodeHaus repository when I do a co from an ASF repo. Do I understand the proposed behavior correctly? You're right. I didn't think about it this way - they're two separate (legal) entities and we shouldn't do that. Happily, it's no longer an issue since OpenEJB jars are updated and the build works like a charm. Alan Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: M2 Issues and Actions
I am adamantly against pulling in code from a CodeHaus repository when I do a co from an ASF repo. Do I understand the proposed behavior correctly? Regards, Alan Jason Dillon wrote: I'd just like to know why you are really, really against it? I don't like it, but as a short-term solution I think it is okay. But, hopefully we will have openejb snaps deployed to a repo soon so we won't need to do this. --jason On Jun 30, 2006, at 7:56 AM, Alan D. Cabrera wrote: As I mentioned in a previous thread. I am really, really, against this. I'm happy to discuss this further. Regards, Alan Bill Dudney wrote: Hi Jacek, Yep just edit the svn:externals property on geronimo and you are done :-) TTFN, Bill Dudney MyFaces - http://myfaces.apache.org Cayenne - http://incubator.apache.org/projects/cayenne.html On Jun 29, 2006, at 3:40 PM, Jacek Laskowski wrote: On 6/29/06, Jason Dillon <[EMAIL PROTECTED]> wrote: Using svn:externals is probably the easiest way to the the openejb sources included for use in a m2 build w/o needing the user to run `maven -o m:co` or run `svn co ...` directly yo pull the sources for the build. I think this is the best short-term solution to the openejb integration issue. I would like to stress that we should eventually try to remove this source-level dependency for out long-term direction. Am I right that it's as simple as executing $ svn propget svn:externals geronimo openejb https://svn.codehaus.org/openejb/trunk/openejb2 ? That seems to be an interim yet elegant solution. It's a bug fix so no need to RTC it. --jason Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: M2 Issues and Actions
On 6/30/06, Jason Dillon <[EMAIL PROTECTED]> wrote: BUT the point that I was making was that Maven must resolve the plugin before the build commences... that means that the plugin must exist in a repository (or cache) already, and that is the version that will be used for the current build cycle... NOT the plugin that will be compiled and installed as part of the current build. Therefor the current build will always use the version of the plugin that was built BEFORE the build started, NOT the version that is actually getting built. I have never thought about it, but it sounds *utterly* possible! Astonishing! I'm so surprised that I couldn't resist and ask a question about it in the Maven user mailing list. I'm awaiting their response hoping there's an elegant solution to it (not a workaround). There must be a solution. --jason Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: M2 Issues and Actions
Sure, I was going to add that, as well as update the README.txt... pending approval of the changes. That script would just facilitate the multi-stage build... and is not intended to be a replacement for invoking mvn directly. BUT, we can use build[.bat] to provide users with a one command method to execute a full build. --jason On Jul 1, 2006, at 2:58 AM, Aaron Mulder wrote: Call me crazy, but cant we have a build.bat and build.sh in the root directory that executes the multi-stage builds (modules, plugins, OpenEJB if present, apps, assemblies, etc.)? Thanks, Aaron On 6/30/06, Jason Dillon <[EMAIL PROTECTED]> wrote: I also think we need another pre-stage that will build a few tiny extensions used by the other stages. Specifically a test-config module that sets up a common log4j.properties that is used by all tests. When we get a site build running then we also will need something similar for clover and checkstyle and other plugins. NOTE: This can be a pre-stage or can be the start of the separate build-support (or whatever we call it) tree, which will contain the standalone plugins and other modules that our builds need to function. --jason > So, my proposed build procedure: > > build modules + plugins > go somewhere else and build openejb > build apps + configs + assemblies > > The proposal of using snapshots of openejb from a repo prevents you > from doing a clean build and finding out that in fact you created a > problem in either openejb or configs/assembly. > > This 3 step process will prevent us from interspersing the modules > and configs builds which might be highly desirable to make our > dependency tracking the same as the maven dependency tracking. > Cant get everything :-( > > thanks > david jencks > >> >> --jason >> >> >
Re: M2 Issues and Actions
Call me crazy, but cant we have a build.bat and build.sh in the root directory that executes the multi-stage builds (modules, plugins, OpenEJB if present, apps, assemblies, etc.)? Thanks, Aaron On 6/30/06, Jason Dillon <[EMAIL PROTECTED]> wrote: I also think we need another pre-stage that will build a few tiny extensions used by the other stages. Specifically a test-config module that sets up a common log4j.properties that is used by all tests. When we get a site build running then we also will need something similar for clover and checkstyle and other plugins. NOTE: This can be a pre-stage or can be the start of the separate build-support (or whatever we call it) tree, which will contain the standalone plugins and other modules that our builds need to function. --jason > So, my proposed build procedure: > > build modules + plugins > go somewhere else and build openejb > build apps + configs + assemblies > > The proposal of using snapshots of openejb from a repo prevents you > from doing a clean build and finding out that in fact you created a > problem in either openejb or configs/assembly. > > This 3 step process will prevent us from interspersing the modules > and configs builds which might be highly desirable to make our > dependency tracking the same as the maven dependency tracking. > Cant get everything :-( > > thanks > david jencks > >> >> --jason >> >> >
Re: openejb publishing restored (was Re: M2 Issues and Actions - svn:externals workaround)
You aren't paying attention to what I said. Only openejb uses g bits in it, the others can all be built with no g parts present. So, if I change something in g, I know I didn't break anything except maybe openejb. So, I want to be able to check really easily by having one build that includes everything that depends on g stuff and gets into our assembled server. Oh... my bad... minor dyslexia always causes me problems. It is possible to make a build like that. And as I have said before I can help you make that a reality... after we have finished with the main m2 build. Which I think is only really pending the xmlbeans and assembly fixes until it is useable... so hopefully we will have m2 functional soon! --jason
Re: openejb publishing restored (was Re: M2 Issues and Actions - svn:externals workaround)
On Jun 30, 2006, at 3:27 PM, Jason Dillon wrote: It's very good, but it doesn't help with my desire to be able to build g + all the stuff that depends on g that goes into g in one step. since this isn't possible right now entirely in m2 anyway due to the plugin issues I think I'll have to be satisfied with a script that runs m2 in several places. Thats gotta be one crazy script... commons-lang, log4j, openejb, tranql, specs, commons-cli, commons-lang, commons-collections, howl, derby, . You aren't paying attention to what I said. Only openejb uses g bits in it, the others can all be built with no g parts present. So, if I change something in g, I know I didn't break anything except maybe openejb. So, I want to be able to check really easily by having one build that includes everything that depends on g stuff and gets into our assembled server. thanks david jencks I don't think that it is feasible to even attempt a system that will build everything in one swoop. Anyways, I know that is not what you meant. I think we can provide support for building a bunch of stuff at once for peeps like you who want that, but I do not believe that should be the default that everyone needs to use to get a functional server. David, once m2 is functional I can help to make a build that will get you want you want while keeping the default build relatively simplified. --jason
Re: openejb publishing restored (was Re: M2 Issues and Actions - svn:externals workaround)
It's very good, but it doesn't help with my desire to be able to build g + all the stuff that depends on g that goes into g in one step. since this isn't possible right now entirely in m2 anyway due to the plugin issues I think I'll have to be satisfied with a script that runs m2 in several places. Thats gotta be one crazy script... commons-lang, log4j, openejb, tranql, specs, commons-cli, commons-lang, commons-collections, howl, derby, . I don't think that it is feasible to even attempt a system that will build everything in one swoop. Anyways, I know that is not what you meant. I think we can provide support for building a bunch of stuff at once for peeps like you who want that, but I do not believe that should be the default that everyone needs to use to get a functional server. David, once m2 is functional I can help to make a build that will get you want you want while keeping the default build relatively simplified. --jason
Re: openejb publishing restored (was Re: M2 Issues and Actions - svn:externals workaround)
We should remove the openejb/modules from the G root pom.xml. Once some of the other issues are sorted I can put together an all-in- one-special-build for those folks that want to build openejb+tranql+G all at once. --jason On Jun 30, 2006, at 3:09 PM, David Blevins wrote: Ok, Jason and I got it working on gbuild. Jars are pushed to codehaus via webdav *and* I up'ed the frequency to every half hour. So... Current openejb jars *will* be available with in (0-30 min + build time) of any commit to openejb. Does that seem reasonable to everyone? David Jencks, do you think this is good? -David On Jun 30, 2006, at 11:14 AM, David Blevins wrote: Built and published the latest jars from my mac. For reference it's simply: Finder -> Go -> Connect to Server Use "https://dav.codehaus.org/dist/openejb/"; for the Server Address. Good idea to click the "+" button to add it to your favorites. Anyway, working on getting a similar setup on gbuild. -David On Jun 29, 2006, at 3:35 PM, Jason Dillon wrote: FYI, I'm working with David Blevins now to try and get the OpenEJB jars published... and once published then the defautl build will not need these sources. But for folks that want to build G and OpenEJB in one swoop we can setup a super-build that does this. But, right now still working on how to get Continuum to publish jars to the Codehaus' WebDAV... --jason On Jun 29, 2006, at 3:20 PM, Jacek Laskowski wrote: On 6/30/06, David Jencks <[EMAIL PROTECTED]> wrote: > Note http rather than https. I hope someone who actually knows will speak up, but I thought https worked fine for non-committers whereas http did not work for committers. If true I would suggest https rather than http. AFAIUI, you won't be able to work with the openejb checkout as if it was a regular checkout. It's only for non-committers' convenience to let them build Geronimo using M2. OpenEJB committers will have to remove their own copy of OpenEJB from within Geronimo and work with it outside Geronimo local source directory. Thus, I chose http which is faster. david jencks Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: openejb publishing restored (was Re: M2 Issues and Actions - svn:externals workaround)
On Jun 30, 2006, at 3:09 PM, David Blevins wrote: Ok, Jason and I got it working on gbuild. Jars are pushed to codehaus via webdav *and* I up'ed the frequency to every half hour. So... Current openejb jars *will* be available with in (0-30 min + build time) of any commit to openejb. Does that seem reasonable to everyone? David Jencks, do you think this is good? It's very good, but it doesn't help with my desire to be able to build g + all the stuff that depends on g that goes into g in one step. since this isn't possible right now entirely in m2 anyway due to the plugin issues I think I'll have to be satisfied with a script that runs m2 in several places. thanks david jencks -David On Jun 30, 2006, at 11:14 AM, David Blevins wrote: Built and published the latest jars from my mac. For reference it's simply: Finder -> Go -> Connect to Server Use "https://dav.codehaus.org/dist/openejb/"; for the Server Address. Good idea to click the "+" button to add it to your favorites. Anyway, working on getting a similar setup on gbuild. -David On Jun 29, 2006, at 3:35 PM, Jason Dillon wrote: FYI, I'm working with David Blevins now to try and get the OpenEJB jars published... and once published then the defautl build will not need these sources. But for folks that want to build G and OpenEJB in one swoop we can setup a super-build that does this. But, right now still working on how to get Continuum to publish jars to the Codehaus' WebDAV... --jason On Jun 29, 2006, at 3:20 PM, Jacek Laskowski wrote: On 6/30/06, David Jencks <[EMAIL PROTECTED]> wrote: > Note http rather than https. I hope someone who actually knows will speak up, but I thought https worked fine for non-committers whereas http did not work for committers. If true I would suggest https rather than http. AFAIUI, you won't be able to work with the openejb checkout as if it was a regular checkout. It's only for non-committers' convenience to let them build Geronimo using M2. OpenEJB committers will have to remove their own copy of OpenEJB from within Geronimo and work with it outside Geronimo local source directory. Thus, I chose http which is faster. david jencks Jacek -- Jacek Laskowski http://www.laskowski.net.pl
openejb publishing restored (was Re: M2 Issues and Actions - svn:externals workaround)
Ok, Jason and I got it working on gbuild. Jars are pushed to codehaus via webdav *and* I up'ed the frequency to every half hour. So... Current openejb jars *will* be available with in (0-30 min + build time) of any commit to openejb. Does that seem reasonable to everyone? David Jencks, do you think this is good? -David On Jun 30, 2006, at 11:14 AM, David Blevins wrote: Built and published the latest jars from my mac. For reference it's simply: Finder -> Go -> Connect to Server Use "https://dav.codehaus.org/dist/openejb/"; for the Server Address. Good idea to click the "+" button to add it to your favorites. Anyway, working on getting a similar setup on gbuild. -David On Jun 29, 2006, at 3:35 PM, Jason Dillon wrote: FYI, I'm working with David Blevins now to try and get the OpenEJB jars published... and once published then the defautl build will not need these sources. But for folks that want to build G and OpenEJB in one swoop we can setup a super-build that does this. But, right now still working on how to get Continuum to publish jars to the Codehaus' WebDAV... --jason On Jun 29, 2006, at 3:20 PM, Jacek Laskowski wrote: On 6/30/06, David Jencks <[EMAIL PROTECTED]> wrote: > Note http rather than https. I hope someone who actually knows will speak up, but I thought https worked fine for non-committers whereas http did not work for committers. If true I would suggest https rather than http. AFAIUI, you won't be able to work with the openejb checkout as if it was a regular checkout. It's only for non-committers' convenience to let them build Geronimo using M2. OpenEJB committers will have to remove their own copy of OpenEJB from within Geronimo and work with it outside Geronimo local source directory. Thus, I chose http which is faster. david jencks Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: M2 Issues and Actions - svn:externals workaround
Oh, sorry... What version of openejb did you just deploy to the codehaus dist repo? --jason On Jun 30, 2006, at 12:07 PM, David Blevins wrote: The latest version? Sorry i didn't get what you mean :) -David On Jun 30, 2006, at 12:00 PM, Jason Dillon wrote: What is the version that we should be using? --jason On Jun 30, 2006, at 11:14 AM, David Blevins wrote: Built and published the latest jars from my mac. For reference it's simply: Finder -> Go -> Connect to Server Use "https://dav.codehaus.org/dist/openejb/"; for the Server Address. Good idea to click the "+" button to add it to your favorites. Anyway, working on getting a similar setup on gbuild. -David
Re: M2 Issues and Actions - svn:externals workaround
The latest version? Sorry i didn't get what you mean :) -David On Jun 30, 2006, at 12:00 PM, Jason Dillon wrote: What is the version that we should be using? --jason On Jun 30, 2006, at 11:14 AM, David Blevins wrote: Built and published the latest jars from my mac. For reference it's simply: Finder -> Go -> Connect to Server Use "https://dav.codehaus.org/dist/openejb/"; for the Server Address. Good idea to click the "+" button to add it to your favorites. Anyway, working on getting a similar setup on gbuild. -David
Re: M2 Issues and Actions - svn:externals workaround
What is the version that we should be using? --jason On Jun 30, 2006, at 11:14 AM, David Blevins wrote: Built and published the latest jars from my mac. For reference it's simply: Finder -> Go -> Connect to Server Use "https://dav.codehaus.org/dist/openejb/"; for the Server Address. Good idea to click the "+" button to add it to your favorites. Anyway, working on getting a similar setup on gbuild. -David
Re: M2 Issues and Actions
I also think we need another pre-stage that will build a few tiny extensions used by the other stages. Specifically a test-config module that sets up a common log4j.properties that is used by all tests. When we get a site build running then we also will need something similar for clover and checkstyle and other plugins. NOTE: This can be a pre-stage or can be the start of the separate build-support (or whatever we call it) tree, which will contain the standalone plugins and other modules that our builds need to function. --jason So, my proposed build procedure: build modules + plugins go somewhere else and build openejb build apps + configs + assemblies The proposal of using snapshots of openejb from a repo prevents you from doing a clean build and finding out that in fact you created a problem in either openejb or configs/assembly. This 3 step process will prevent us from interspersing the modules and configs builds which might be highly desirable to make our dependency tracking the same as the maven dependency tracking. Cant get everything :-( thanks david jencks --jason
Re: M2 Issues and Actions
BUT the point that I was making was that Maven must resolve the plugin before the build commences... that means that the plugin must exist in a repository (or cache) already, and that is the version that will be used for the current build cycle... NOT the plugin that will be compiled and installed as part of the current build. The point I've been trying to make is that this feature of maven is a showstopper for use of maven in any framework type project. We can work around it, but it's a ridiculous limitation in maven. Yes, I should take it up with the maven team, but that takes time and energy, both of which are in short supply for me right now. But you know that w/m1 that building the plugin and then using it in the same build is also a massive hack. Since the packaging plugin is a way of running some g. core code from maven, not having it use the just built core code in a build makes me extremely uneasy. I would prefer to split the build up into segments that must be run separately. We maybe able to write a plugin to help facilitate these segments if nothing already exists... allowing one command to build, and under the covers it runs a set of m2 builds. Since I am the only person who want to have a complete build of all the stuff that depends on geronimo and goes into the assemblies (I'm referring to building openejb as part of the g build), this really shouldn't annoy anyone. So, my proposed build procedure: build modules + plugins go somewhere else and build openejb build apps + configs + assemblies I like this sans the openejb bits... though if you want to build openejb like this I don't see that it is a problem as long as it is optional. The proposal of using snapshots of openejb from a repo prevents you from doing a clean build and finding out that in fact you created a problem in either openejb or configs/assembly. Not sure what you mean... :-( --jason
Re: M2 Issues and Actions - svn:externals workaround
I think it supposed to... since this will give your writable access to that share. --jason On Jun 30, 2006, at 11:38 AM, Prasad Kashyap wrote: The link tries to authenticate me :-( Cheers Prasad On 6/30/06, David Blevins <[EMAIL PROTECTED]> wrote: Built and published the latest jars from my mac. For reference it's simply: Finder -> Go -> Connect to Server Use "https://dav.codehaus.org/dist/openejb/"; for the Server Address. Good idea to click the "+" button to add it to your favorites. Anyway, working on getting a similar setup on gbuild. -David On Jun 29, 2006, at 3:35 PM, Jason Dillon wrote: > FYI, I'm working with David Blevins now to try and get the OpenEJB > jars published... and once published then the defautl build will > not need these sources. But for folks that want to build G and > OpenEJB in one swoop we can setup a super-build that does this. > > But, right now still working on how to get Continuum to publish > jars to the Codehaus' WebDAV... > > --jason > > > On Jun 29, 2006, at 3:20 PM, Jacek Laskowski wrote: > >> On 6/30/06, David Jencks <[EMAIL PROTECTED]> wrote: >> >>> > Note http rather than https. >>> >>> I hope someone who actually knows will speak up, but I thought https >>> worked fine for non-committers whereas http did not work for >>> committers. If true I would suggest https rather than http. >> >> AFAIUI, you won't be able to work with the openejb checkout as if it >> was a regular checkout. It's only for non-committers' convenience to >> let them build Geronimo using M2. OpenEJB committers will have to >> remove their own copy of OpenEJB from within Geronimo and work >> with it >> outside Geronimo local source directory. Thus, I chose http which is >> faster. >> >>> david jencks >> >> Jacek >> >> -- >> Jacek Laskowski >> http://www.laskowski.net.pl >
Re: M2 Issues and Actions - svn:externals workaround
The link tries to authenticate me :-( Cheers Prasad On 6/30/06, David Blevins <[EMAIL PROTECTED]> wrote: Built and published the latest jars from my mac. For reference it's simply: Finder -> Go -> Connect to Server Use "https://dav.codehaus.org/dist/openejb/"; for the Server Address. Good idea to click the "+" button to add it to your favorites. Anyway, working on getting a similar setup on gbuild. -David On Jun 29, 2006, at 3:35 PM, Jason Dillon wrote: > FYI, I'm working with David Blevins now to try and get the OpenEJB > jars published... and once published then the defautl build will > not need these sources. But for folks that want to build G and > OpenEJB in one swoop we can setup a super-build that does this. > > But, right now still working on how to get Continuum to publish > jars to the Codehaus' WebDAV... > > --jason > > > On Jun 29, 2006, at 3:20 PM, Jacek Laskowski wrote: > >> On 6/30/06, David Jencks <[EMAIL PROTECTED]> wrote: >> >>> > Note http rather than https. >>> >>> I hope someone who actually knows will speak up, but I thought https >>> worked fine for non-committers whereas http did not work for >>> committers. If true I would suggest https rather than http. >> >> AFAIUI, you won't be able to work with the openejb checkout as if it >> was a regular checkout. It's only for non-committers' convenience to >> let them build Geronimo using M2. OpenEJB committers will have to >> remove their own copy of OpenEJB from within Geronimo and work >> with it >> outside Geronimo local source directory. Thus, I chose http which is >> faster. >> >>> david jencks >> >> Jacek >> >> -- >> Jacek Laskowski >> http://www.laskowski.net.pl >
Re: M2 Issues and Actions
On Jun 30, 2006, at 11:00 AM, Jason Dillon wrote: While this may work most of the time, it is not ideal as when making changes to plugins, users will be mystified when those changes are not used on the first build. This is not true. The plugin is *not* used before it is built. The problem is that maven does not even start the build until it has downloaded all the plugins. Even a dummy plugin would work. Um... it is completely true. I am aware that the plugin is not used before it is built. BUT the point that I was making was that Maven must resolve the plugin before the build commences... that means that the plugin must exist in a repository (or cache) already, and that is the version that will be used for the current build cycle... NOT the plugin that will be compiled and installed as part of the current build. The point I've been trying to make is that this feature of maven is a showstopper for use of maven in any framework type project. We can work around it, but it's a ridiculous limitation in maven. Yes, I should take it up with the maven team, but that takes time and energy, both of which are in short supply for me right now. Therefor the current build will always use the version of the plugin that was built BEFORE the build started, NOT the version that is actually getting built. This is why I suggested that the plugin either be part of another project (detached from the main build) or as part of a bootstrap phase that is executed before the main build cycle. Since the packaging plugin is a way of running some g. core code from maven, not having it use the just built core code in a build makes me extremely uneasy. I would prefer to split the build up into segments that must be run separately. Since I am the only person who want to have a complete build of all the stuff that depends on geronimo and goes into the assemblies (I'm referring to building openejb as part of the g build), this really shouldn't annoy anyone. So, my proposed build procedure: build modules + plugins go somewhere else and build openejb build apps + configs + assemblies The proposal of using snapshots of openejb from a repo prevents you from doing a clean build and finding out that in fact you created a problem in either openejb or configs/assembly. This 3 step process will prevent us from interspersing the modules and configs builds which might be highly desirable to make our dependency tracking the same as the maven dependency tracking. Cant get everything :-( thanks david jencks --jason
Re: M2 Issues and Actions - svn:externals workaround
Built and published the latest jars from my mac. For reference it's simply: Finder -> Go -> Connect to Server Use "https://dav.codehaus.org/dist/openejb/"; for the Server Address. Good idea to click the "+" button to add it to your favorites. Anyway, working on getting a similar setup on gbuild. -David On Jun 29, 2006, at 3:35 PM, Jason Dillon wrote: FYI, I'm working with David Blevins now to try and get the OpenEJB jars published... and once published then the defautl build will not need these sources. But for folks that want to build G and OpenEJB in one swoop we can setup a super-build that does this. But, right now still working on how to get Continuum to publish jars to the Codehaus' WebDAV... --jason On Jun 29, 2006, at 3:20 PM, Jacek Laskowski wrote: On 6/30/06, David Jencks <[EMAIL PROTECTED]> wrote: > Note http rather than https. I hope someone who actually knows will speak up, but I thought https worked fine for non-committers whereas http did not work for committers. If true I would suggest https rather than http. AFAIUI, you won't be able to work with the openejb checkout as if it was a regular checkout. It's only for non-committers' convenience to let them build Geronimo using M2. OpenEJB committers will have to remove their own copy of OpenEJB from within Geronimo and work with it outside Geronimo local source directory. Thus, I chose http which is faster. david jencks Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: M2 Issues and Actions
While this may work most of the time, it is not ideal as when making changes to plugins, users will be mystified when those changes are not used on the first build. This is not true. The plugin is *not* used before it is built. The problem is that maven does not even start the build until it has downloaded all the plugins. Even a dummy plugin would work. Um... it is completely true. I am aware that the plugin is not used before it is built. BUT the point that I was making was that Maven must resolve the plugin before the build commences... that means that the plugin must exist in a repository (or cache) already, and that is the version that will be used for the current build cycle... NOT the plugin that will be compiled and installed as part of the current build. Therefor the current build will always use the version of the plugin that was built BEFORE the build started, NOT the version that is actually getting built. This is why I suggested that the plugin either be part of another project (detached from the main build) or as part of a bootstrap phase that is executed before the main build cycle. --jason
Re: M2 Issues and Actions
I'd just like to know why you are really, really against it?I don't like it, but as a short-term solution I think it is okay.But, hopefully we will have openejb snaps deployed to a repo soon so we won't need to do this.--jasonOn Jun 30, 2006, at 7:56 AM, Alan D. Cabrera wrote: As I mentioned in a previous thread. I am really, really, against this. I'm happy to discuss this further. Regards, Alan Bill Dudney wrote: Hi Jacek, Yep just edit the svn:externals property on geronimo and you are done :-) TTFN, Bill Dudney MyFaces - http://myfaces.apache.org Cayenne - http://incubator.apache.org/projects/cayenne.html On Jun 29, 2006, at 3:40 PM, Jacek Laskowski wrote:On 6/29/06, Jason Dillon <[EMAIL PROTECTED]> wrote: Using svn:externals is probably the easiest way to the the openejb sources included for use in a m2 build w/o needing the user to run `maven -o m:co` or run `svn co ...` directly yo pull the sources for the build. I think this is the best short-term solution to the openejb integration issue. I would like to stress that we should eventually try to remove this source-level dependency for out long-term direction.Am I right that it's as simple as executing$ svn propget svn:externals geronimoopenejb https://svn.codehaus.org/openejb/trunk/openejb2?That seems to be an interim yet elegant solution. It's a bug fix so noneed to RTC it. --jasonJacek-- Jacek Laskowskihttp://www.laskowski.net.pl
Re: M2 Issues and Actions - svn:externals workaround
I was very uncomfortable w/ the proposed change. Curious, how so? * * * Maybe later today we will have jars published... assuming that we have wrangled the webdav config on the continuum box. --jason
Re: M2 Issues and Actions
As I mentioned in a previous thread. I am really, really, against this. I'm happy to discuss this further. Regards, Alan Bill Dudney wrote: Hi Jacek, Yep just edit the svn:externals property on geronimo and you are done :-) TTFN, Bill Dudney MyFaces - http://myfaces.apache.org Cayenne - http://incubator.apache.org/projects/cayenne.html On Jun 29, 2006, at 3:40 PM, Jacek Laskowski wrote: On 6/29/06, Jason Dillon <[EMAIL PROTECTED]> wrote: Using svn:externals is probably the easiest way to the the openejb sources included for use in a m2 build w/o needing the user to run `maven -o m:co` or run `svn co ...` directly yo pull the sources for the build. I think this is the best short-term solution to the openejb integration issue. I would like to stress that we should eventually try to remove this source-level dependency for out long-term direction. Am I right that it's as simple as executing $ svn propget svn:externals geronimo openejb https://svn.codehaus.org/openejb/trunk/openejb2 ? That seems to be an interim yet elegant solution. It's a bug fix so no need to RTC it. --jason Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: M2 Issues and Actions - svn:externals workaround
This is good news. I was very uncomfortable w/ the proposed change. Regards, Alan Jason Dillon wrote: FYI, I'm working with David Blevins now to try and get the OpenEJB jars published... and once published then the defautl build will not need these sources. But for folks that want to build G and OpenEJB in one swoop we can setup a super-build that does this. But, right now still working on how to get Continuum to publish jars to the Codehaus' WebDAV... --jason On Jun 29, 2006, at 3:20 PM, Jacek Laskowski wrote: On 6/30/06, David Jencks <[EMAIL PROTECTED]> wrote: > Note http rather than https. I hope someone who actually knows will speak up, but I thought https worked fine for non-committers whereas http did not work for committers. If true I would suggest https rather than http. AFAIUI, you won't be able to work with the openejb checkout as if it was a regular checkout. It's only for non-committers' convenience to let them build Geronimo using M2. OpenEJB committers will have to remove their own copy of OpenEJB from within Geronimo and work with it outside Geronimo local source directory. Thus, I chose http which is faster. david jencks Jacek --Jacek Laskowski http://www.laskowski.net.pl
Re: M2 Issues and Actions
inline.. --- Jason Dillon <[EMAIL PROTECTED]> wrote: > > 2. Spec Jars - > >The geronimo spec jars need to be published along with the poms. > > This was supposed to happen soon after the 1.1 release. And it has happened. Thanks! > > Are there any issues with this? > > Does this have any relation to the proposed reorg of the specs into > multiple trunks? > > > > 4. Maven does not allow building a plugin and a module if the > module > > uses the plugin in the same build. As a result the first time build > is > > a 3 step process. Jason suggested "IMO we should have a completely > > separate tree for our build support tools. And once the plugins > are > > stable we release them, until they are stable we make regular > > snaps, so > > that the main tree(s) can just build w/o having to worry about > > building > > plugins first." > > I'm not sure how easy this is going to be... > > We many need to introduce a bootstrap phase to build a few modules > and a plugin or two and then run through the full build. > > Not terribly ideal IMO, but probably the easiest way to get the m2 > build functional in the least amount of time. I hope that we can > eventually eliminate the need for the bootstrap, but from what I > understand so far this is not going to be something we can do easily > > in a short amount of time (defs not with the RTC muck). > > > > We should start publishing SNAPSHOTs ASAP to solve this > problem, > > This is very user friendly. Once we have assembled our first full > > server, we can start thinking of reorganizing the source tree. > > While this may work most of the time, it is not ideal as when making > > changes to plugins, users will be mystified when those changes are > not used on the first build. This is not true. The plugin is *not* used before it is built. The problem is that maven does not even start the build until it has downloaded all the plugins. Even a dummy plugin would work. > > I'd prefer to minimize the utilization of remote maven > repositories... not increase them. IMO remote repository is growing > > to become more and more of a build anit-pattern. > > > > 5. checking out openejb - In M1 we could define goals like m:co, it > is > > not possible to do this in M2. There is no way to specify > > executions in > > the top level pom that are not inherited by the children. And we > must > > resort to checking out each module and building it! > > There are a few more options here. A module that exists to solely > check out openejb and then run the openejb build as a part of our > build. This can be easily facilitated with antrun and some well > placed dependencies. > > Or use svn:externals ( http://svnbook.red-bean.com/nightly/en/svn- > book.html#svn.advanced.externals ) to force SVN to check out the > openejb tree when Geronimo is checked out. Would need to have users > > svn up in the openejb tree from time to time though, as last I > checked svn:externals are ignored when the local working space is > updated. Jacek is working on this. Thanks Jacek! > > > > Currently we ask the user to use svn command to checkout openejb. > > What are those exact commands that we ask them to use? http://cwiki.apache.org/confluence/display/GMOxDEV/Building+Apache+Geronimo+with+Maven+2 Thanks Anita > > --jason > __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: M2 Issues and Actions - svn:externals workaround
On 6/30/06, David Jencks <[EMAIL PROTECTED]> wrote: I don't understand your reasoning. maven m:co checks out using https and IIUC works for both committers and non-committers, and as a committer I can use that checkout as my working openejb copy. What is the advantage of preventing me from doing that? What harm would using https do to non-committers? None, but I thought that svn:externals would mark the checked-out sources of OpenEJB as not-committable, i.e. no local modification could be committed. As Bill has explained, it's not true when you're in the openejb directory that wouldn't be any different than they're now. The only difference is that you wouldn't be able to commit your changes from the parent directory of the openejb dir (which is possible now). All in all, I was mistaken in my reasoning and am very grateful for your patience :-) On the other hand, Jason and Dave are working on publishing the updated jars to codehaus.org and it seems that it will likely turn out we won't have to introduce the change. david jencks Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: M2 Issues and Actions - svn:externals workaround
On Jun 29, 2006, at 3:20 PM, Jacek Laskowski wrote: On 6/30/06, David Jencks <[EMAIL PROTECTED]> wrote: > Note http rather than https. I hope someone who actually knows will speak up, but I thought https worked fine for non-committers whereas http did not work for committers. If true I would suggest https rather than http. AFAIUI, you won't be able to work with the openejb checkout as if it was a regular checkout. It's only for non-committers' convenience to let them build Geronimo using M2. OpenEJB committers will have to remove their own copy of OpenEJB from within Geronimo and work with it outside Geronimo local source directory. Thus, I chose http which is faster. I don't understand your reasoning. maven m:co checks out using https and IIUC works for both committers and non-committers, and as a committer I can use that checkout as my working openejb copy. What is the advantage of preventing me from doing that? What harm would using https do to non-committers? thanks david jencks david jencks Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: M2 Issues and Actions - svn:externals workaround
Hi All,If we do http;svn ci from within the openejb tree (i.e geronimo/openejb) won't workif we do https;an openejb committer can edit the code in the openejb tree (within the geronimo tree) and do an svn ci and it would commit.in any event 'svn ci' from the root of the geronimo tree would ignore openejb.HTH, Bill DudneyMyFaces - http://myfaces.apache.orgCayenne - http://incubator.apache.org/projects/cayenne.htmlOn Jun 29, 2006, at 4:20 PM, Jacek Laskowski wrote:On 6/30/06, David Jencks <[EMAIL PROTECTED]> wrote: > Note http rather than https.I hope someone who actually knows will speak up, but I thought httpsworked fine for non-committers whereas http did not work forcommitters. If true I would suggest https rather than http. AFAIUI, you won't be able to work with the openejb checkout as if itwas a regular checkout. It's only for non-committers' convenience tolet them build Geronimo using M2. OpenEJB committers will have toremove their own copy of OpenEJB from within Geronimo and work with itoutside Geronimo local source directory. Thus, I chose http which isfaster. david jencks Jacek-- Jacek Laskowskihttp://www.laskowski.net.pl
Re: M2 Issues and Actions - svn:externals workaround
FYI, I'm working with David Blevins now to try and get the OpenEJB jars published... and once published then the defautl build will not need these sources. But for folks that want to build G and OpenEJB in one swoop we can setup a super-build that does this. But, right now still working on how to get Continuum to publish jars to the Codehaus' WebDAV... --jason On Jun 29, 2006, at 3:20 PM, Jacek Laskowski wrote: On 6/30/06, David Jencks <[EMAIL PROTECTED]> wrote: > Note http rather than https. I hope someone who actually knows will speak up, but I thought https worked fine for non-committers whereas http did not work for committers. If true I would suggest https rather than http. AFAIUI, you won't be able to work with the openejb checkout as if it was a regular checkout. It's only for non-committers' convenience to let them build Geronimo using M2. OpenEJB committers will have to remove their own copy of OpenEJB from within Geronimo and work with it outside Geronimo local source directory. Thus, I chose http which is faster. david jencks Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: M2 Issues and Actions - svn:externals workaround
On 6/30/06, David Jencks <[EMAIL PROTECTED]> wrote: > Note http rather than https. I hope someone who actually knows will speak up, but I thought https worked fine for non-committers whereas http did not work for committers. If true I would suggest https rather than http. AFAIUI, you won't be able to work with the openejb checkout as if it was a regular checkout. It's only for non-committers' convenience to let them build Geronimo using M2. OpenEJB committers will have to remove their own copy of OpenEJB from within Geronimo and work with it outside Geronimo local source directory. Thus, I chose http which is faster. david jencks Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: M2 Issues and Actions - svn:externals workaround
On Jun 29, 2006, at 3:02 PM, Jacek Laskowski wrote: Hi, It's been said (http://www.nabble.com/M2-Issues-and-Actions- tf1867589.html) that svn:externals would help us working around the following issue: 3. openejb - The openejb build should use geronimo jars that come from o.a.g groupId. Hence it is necessary to build openejb. Until now v_2.1 was used, now we are switching to 2.2. We should publish snapshots of these jars too. This will obviate the need for building openejb. I'm going to introduce a necessary change in 24 hours unless someone objects. The change is as follows: $ svn propget svn:externals geronimo openejb http://svn.codehaus.org/openejb/trunk/openejb2 Note http rather than https. I hope someone who actually knows will speak up, but I thought https worked fine for non-committers whereas http did not work for committers. If true I would suggest https rather than http. thanks david jencks The clock is ticking...See you in 24 hours. Here's the document about svn:externals property - http://svnbook.red-bean.com/en/1.0/ch07s03.html. I'll create a JIRA issue for it once it's pass. Each and every day gives me something new and today wasn't different ;-) Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: M2 Issues and Actions
Hi Jacek,Yep just edit the svn:externals property on geronimo and you are done :-)TTFN, Bill DudneyMyFaces - http://myfaces.apache.orgCayenne - http://incubator.apache.org/projects/cayenne.html On Jun 29, 2006, at 3:40 PM, Jacek Laskowski wrote:On 6/29/06, Jason Dillon <[EMAIL PROTECTED]> wrote: Using svn:externals is probably the easiest way to the the openejbsources included for use in a m2 build w/o needing the user to run`maven -o m:co` or run `svn co ...` directly yo pull the sources forthe build.I think this is the best short-term solution to the openejbintegration issue. I would like to stress that we should eventuallytry to remove this source-level dependency for out long-term direction. Am I right that it's as simple as executing$ svn propget svn:externals geronimoopenejb https://svn.codehaus.org/openejb/trunk/openejb2?That seems to be an interim yet elegant solution. It's a bug fix so noneed to RTC it. --jason Jacek-- Jacek Laskowskihttp://www.laskowski.net.pl
Re: M2 Issues and Actions
On 6/29/06, Jason Dillon <[EMAIL PROTECTED]> wrote: Using svn:externals is probably the easiest way to the the openejb sources included for use in a m2 build w/o needing the user to run `maven -o m:co` or run `svn co ...` directly yo pull the sources for the build. I think this is the best short-term solution to the openejb integration issue. I would like to stress that we should eventually try to remove this source-level dependency for out long-term direction. Am I right that it's as simple as executing $ svn propget svn:externals geronimo openejb https://svn.codehaus.org/openejb/trunk/openejb2 ? That seems to be an interim yet elegant solution. It's a bug fix so no need to RTC it. --jason Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: M2 Issues and Actions
Using svn:externals is probably the easiest way to the the openejb sources included for use in a m2 build w/o needing the user to run `maven -o m:co` or run `svn co ...` directly yo pull the sources for the build. I think this is the best short-term solution to the openejb integration issue. I would like to stress that we should eventually try to remove this source-level dependency for out long-term direction. --jason On Jun 29, 2006, at 12:30 PM, Bill Dudney wrote: Or use svn:externals ( http://svnbook.red-bean.com/nightly/en/svn- book.html#svn.advanced.externals ) to force SVN to check out the openejb tree when Geronimo is checked out. Would need to have users svn up in the openejb tree from time to time though, as last I checked svn:externals are ignored when the local working space is updated. just fyi, 'svn checkout' will update through an external but 'svn checkin' will not. We use them on myfaces, they work well. TTFN, Bill Dudney MyFaces - http://myfaces.apache.org Cayenne - http://incubator.apache.org/projects/cayenne.html
Re: M2 Issues and Actions
Or use svn:externals ( http://svnbook.red-bean.com/nightly/en/svn- book.html#svn.advanced.externals ) to force SVN to check out the openejb tree when Geronimo is checked out. Would need to have users svn up in the openejb tree from time to time though, as last I checked svn:externals are ignored when the local working space is updated. just fyi, 'svn checkout' will update through an external but 'svn checkin' will not. We use them on myfaces, they work well. TTFN, Bill Dudney MyFaces - http://myfaces.apache.org Cayenne - http://incubator.apache.org/projects/cayenne.html
Re: M2 Issues and Actions
2. Spec Jars - The geronimo spec jars need to be published along with the poms. This was supposed to happen soon after the 1.1 release. Are there any issues with this? Does this have any relation to the proposed reorg of the specs into multiple trunks? 4. Maven does not allow building a plugin and a module if the module uses the plugin in the same build. As a result the first time build is a 3 step process. Jason suggested "IMO we should have a completely separate tree for our build support tools. And once the plugins are stable we release them, until they are stable we make regular snaps, so that the main tree(s) can just build w/o having to worry about building plugins first." I'm not sure how easy this is going to be... We many need to introduce a bootstrap phase to build a few modules and a plugin or two and then run through the full build. Not terribly ideal IMO, but probably the easiest way to get the m2 build functional in the least amount of time. I hope that we can eventually eliminate the need for the bootstrap, but from what I understand so far this is not going to be something we can do easily in a short amount of time (defs not with the RTC muck). We should start publishing SNAPSHOTs ASAP to solve this problem, This is very user friendly. Once we have assembled our first full server, we can start thinking of reorganizing the source tree. While this may work most of the time, it is not ideal as when making changes to plugins, users will be mystified when those changes are not used on the first build. I'd prefer to minimize the utilization of remote maven repositories... not increase them. IMO remote repository is growing to become more and more of a build anit-pattern. 5. checking out openejb - In M1 we could define goals like m:co, it is not possible to do this in M2. There is no way to specify executions in the top level pom that are not inherited by the children. And we must resort to checking out each module and building it! There are a few more options here. A module that exists to solely check out openejb and then run the openejb build as a part of our build. This can be easily facilitated with antrun and some well placed dependencies. Or use svn:externals ( http://svnbook.red-bean.com/nightly/en/svn- book.html#svn.advanced.externals ) to force SVN to check out the openejb tree when Geronimo is checked out. Would need to have users svn up in the openejb tree from time to time though, as last I checked svn:externals are ignored when the local working space is updated. Currently we ask the user to use svn command to checkout openejb. What are those exact commands that we ask them to use? --jason
Re: M2 Issues and Actions
--- Bill Dudney <[EMAIL PROTECTED]> wrote: > Hi Anita, > > So where are we to get openejb from now? > > https://svn.codehaus.org/openejb/trunk/openejb2/ > > If so I'd be glad to update the wiki page. We should update the wiki to use this location as soon as openejb build starts working again. Thanks Anita > > TTFN, > > > > Bill Dudney > MyFaces - http://myfaces.apache.org > Cayenne - http://incubator.apache.org/projects/cayenne.html > > > > On Jun 29, 2006, at 7:44 AM, anita kulshreshtha wrote: > > > Hi All, > >The M2 build work is continuing. Dain just updated the openejb > > trunk. Now we will be using openEJB 2.2 > > (http://issues.apache.org/jira/browse/GERONIMO-2152). > > The assembly plugin is under construction. Here are the issues > facing > > us. I am also reproducing the suggested remedies for some of these. > > > > 1. xmlbeans-maven-plugin and xbean pom - > > The issue is described here > > http://issues.apache.org/jira/browse/GERONIMO-2082 > >David Jencks has submitted the patches and has been working with > > > the > > xmlbeans team. See > > > http://www.nabble.com/Unable-to-build-using-m2-tf1846875.html#a5041106 > > > > 2. Spec Jars - > >The geronimo spec jars need to be published along with the poms. > > This was supposed to happen soon after the 1.1 release. > > > > 3. openejb - The openejb build should use geronimo jars that come > from > > o.a.g groupId. Hence it is necessary to build openejb. Until now > v_2.1 > > was used, now we are switching to 2.2. We should publish snapshots > of > > these jars too. This will obviate the need for building openejb. > > > > 4. Maven does not allow building a plugin and a module if the > module > > uses the plugin in the same build. As a result the first time build > is > > a 3 step process. Jason suggested "IMO we should have a completely > > separate tree for our build support tools. And once the plugins > are > > stable we release them, until they are stable we make regular > > snaps, so > > that the main tree(s) can just build w/o having to worry about > > building > > plugins first." > > We should start publishing SNAPSHOTs ASAP to solve this > problem, > > This is very user friendly. Once we have assembled our first full > > server, we can start thinking of reorganizing the source tree. > > 5. checking out openejb - In M1 we could define goals like m:co, it > is > > not possible to do this in M2. There is no way to specify > > executions in > > the top level pom that are not inherited by the children. And we > must > > resort to checking out each module and building it! Currently we > ask > > the user to use svn command to checkout openejb. The other solution > is > > have the 'support tool tree' which will provide commands for > checking > > out openejb. If the latest openejb snapshots are always available, > we > > can eliminate openejb from our build. > > We will be documenting any new issues here > > http://cwiki.apache.org/confluence/display/geronimo/Building > > +Geronimo+with+Maven+2 > > thanks for your patience! > > > > Thanks > > Anita > > > > __ > > Do You Yahoo!? > > Tired of spam? Yahoo! Mail has the best spam protection around > > http://mail.yahoo.com > > __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: M2 Issues and Actions
Correction inline.. --- anita kulshreshtha <[EMAIL PROTECTED]> wrote: > Hi All, >The M2 build work is continuing. Dain just updated the openejb > trunk. Now we will be using openEJB 2.2 > http://issues.apache.org/jira/browse/GERONIMO-2152. > The assembly plugin is under construction. Here are the issues facing > us. I am also reproducing the suggested remedies for some of these. > > > 1. xmlbeans-maven-plugin and xbean pom - > The issue is described here > http://issues.apache.org/jira/browse/GERONIMO-2082 >David Jencks has submitted the patches and has been working with > the > xmlbeans team. See > http://www.nabble.com/Unable-to-build-using-m2-tf1846875.html#a5041106 The correct link is - http://www.nabble.com/Re%3A-Unable-to-build-using-m2-p5069519.html > > > 2. Spec Jars - >The geronimo spec jars need to be published along with the poms. > This was supposed to happen soon after the 1.1 release. > > 3. openejb - The openejb build should use geronimo jars that come > from > o.a.g groupId. Hence it is necessary to build openejb. Until now > v_2.1 > was used, now we are switching to 2.2. We should publish snapshots of > these jars too. This will obviate the need for building openejb. > > 4. Maven does not allow building a plugin and a module if the > module > uses the plugin in the same build. As a result the first time build > is > a 3 step process. Jason suggested "IMO we should have a completely > separate tree for our build support tools. And once the plugins are > stable we release them, until they are stable we make regular snaps, > so > that the main tree(s) can just build w/o having to worry about > building > plugins first." > We should start publishing SNAPSHOTs ASAP to solve this problem, > This is very user friendly. Once we have assembled our first full > server, we can start thinking of reorganizing the source tree. > 5. checking out openejb - In M1 we could define goals like m:co, it > is > not possible to do this in M2. There is no way to specify executions > in > the top level pom that are not inherited by the children. And we must > resort to checking out each module and building it! Currently we ask > the user to use svn command to checkout openejb. The other solution > is > have the 'support tool tree' which will provide commands for checking > out openejb. If the latest openejb snapshots are always available, we > can eliminate openejb from our build. > We will be documenting any new issues here > http://cwiki.apache.org/confluence/display/geronimo/Building+Geronimo+with+Maven+2 > thanks for your patience! > > Thanks > Anita > > __ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: M2 Issues and Actions
Hi Anita,So where are we to get openejb from now?https://svn.codehaus.org/openejb/trunk/openejb2/If so I'd be glad to update the wiki page.TTFN, Bill DudneyMyFaces - http://myfaces.apache.orgCayenne - http://incubator.apache.org/projects/cayenne.html On Jun 29, 2006, at 7:44 AM, anita kulshreshtha wrote:Hi All, The M2 build work is continuing. Dain just updated the openejbtrunk. Now we will be using openEJB 2.2(http://issues.apache.org/jira/browse/GERONIMO-2152).The assembly plugin is under construction. Here are the issues facingus. I am also reproducing the suggested remedies for some of these. 1. xmlbeans-maven-plugin and xbean pom - The issue is described herehttp://issues.apache.org/jira/browse/GERONIMO-2082 David Jencks has submitted the patches and has been working with thexmlbeans team. Seehttp://www.nabble.com/Unable-to-build-using-m2-tf1846875.html#a5041106 2. Spec Jars - The geronimo spec jars need to be published along with the poms.This was supposed to happen soon after the 1.1 release.3. openejb - The openejb build should use geronimo jars that come fromo.a.g groupId. Hence it is necessary to build openejb. Until now v_2.1was used, now we are switching to 2.2. We should publish snapshots ofthese jars too. This will obviate the need for building openejb.4. Maven does not allow building a plugin and a module if the moduleuses the plugin in the same build. As a result the first time build isa 3 step process. Jason suggested "IMO we should have a completelyseparate tree for our build support tools. And once the plugins arestable we release them, until they are stable we make regular snaps, sothat the main tree(s) can just build w/o having to worry about buildingplugins first." We should start publishing SNAPSHOTs ASAP to solve this problem,This is very user friendly. Once we have assembled our first fullserver, we can start thinking of reorganizing the source tree. 5. checking out openejb - In M1 we could define goals like m:co, it isnot possible to do this in M2. There is no way to specify executions inthe top level pom that are not inherited by the children. And we mustresort to checking out each module and building it! Currently we askthe user to use svn command to checkout openejb. The other solution ishave the 'support tool tree' which will provide commands for checkingout openejb. If the latest openejb snapshots are always available, wecan eliminate openejb from our build. We will be documenting any new issues here http://cwiki.apache.org/confluence/display/geronimo/Building+Geronimo+with+Maven+2 thanks for your patience!ThanksAnita__Do You Yahoo!?Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
