Re: Geronimo Repository (was Re: Unable to build using m2)
Ooops... I got trim happy. This was a reply to Matt. --jason On Jul 1, 2006, at 2:05 PM, Alan D. Cabrera wrote: Jason, who are you replying to? You accidentally cut out the person's name. Regards, Alan Jason Dillon wrote: I agree with your comments but I also recognize that it is a slippery slope. Who is responsible for tracking the changes and lobbying the other groups? My limited experience tells me that this will likely end up being a set of forked code from other projects that will be very difficult to manage. for instance...say a quick change is made to XMLBeans and it get's put into our "local" copy. 4 months later the XMLBeans folks have not done anything with the patch and now after discussing it further decide that it doens't fit with their direction. During that time Geronimo has relied on the patch and changing direction is going to be painful. I would expect that most of the localized changes would be to pom's only and to install the correct version of the dependency in a repository for our build to work. While I think that we may need to have a few cases where some code is required to change, but in order for that to work, there must be someone who is actively working with the external community to get the changes in. Otherwise, as you suggested it would turn into a private fork... and IMO that is not acceptable. I believe that it would be the responsibility of the developer who introduces the new version of the dependency to create a JIRA (in our project) to manage the state of the dependency... AND be active about getting the changes introduced in the target communities codebase. Peer review will also be used to help ensure that we keep things moving smoothly. Like, if a custom version of a dependency exists for months and months and goes no where, then we need to react and either help the developer get the changes moved or reevaluate the need for those changes, etc. I realize this is a worse case scenario but we had a similar situation with the Axis guys in cutting a 1.4 release for us. It took about 6 months and I think was only done because David Blevins was made a committer. Um, did it take 6 months because he was a committer? Meaning it would have taken more than 6 months if he was not? Yikes! In order to consider this it would be great if you could flush out the different scenarios as you see them and how we would handle them. I'm not the most administrative person on the planet and what you are proposing sounds great and scare the heck out of me at the same time ;-0 Well... I'm not sure I know of all of the scenarios, but mostly I do not see that we will have custom forked versions of others work in our repository, though on some occasions yes, we will... but only for a very limited and controlled period. For example, I have been using the RetroTranslator m2 plugin in GShell for many weeks now. I have been very active about creating patches for the Mojo team, getting changes needed into this plugin so that it can be more useful. But, it takes the Mojo team time (some times a long time) to pull in those changes... or as is the current case, to publish the plugin with those changes already accepted and committed. So we have already gotten the code in the target communities codebase... but it is taking a long time to get a new release (or SNAPSHOT) pushed out to a repo so that we can actually use it. This is where our repository comes in. We publish a SNAPSHOT of the plugin to our repository so that we can continue to move forward using the plugin, and in the background keep on the Mojo peeps to get the thing official. * * * There is also the other-side of the repository, which is to allow builds to be reproducible in future months, years. To have 100% build reproducibility we need to have much more control over the repository which dependencies are pulled from. The reliance on so many external repositories is a build anti- pattern and make is very difficult (some times impossible) to ensure that builds will just work in future days, months, years. Machines crash, data gets lost, which we have recently seen and suffered from. Having a repository that is controlled by the same system as our sources will generally mean that at any point in time when when have a valid scm codebase, then we also have the valid dependencies. Then when the Codehaus disks die again, or a worm eats thought all of Ibiblio, then we can still function and continue to work. * * * I believe that both of these reasons (staging w/external groups and build reproduction and isolation from external failure) warrant the creation of an internal SVN-backed repository that exists solely for the use by Geronimo, and its child projects. --jason
Re: Geronimo Repository (was Re: Unable to build using m2)
Jason, who are you replying to? You accidentally cut out the person's name. Regards, Alan Jason Dillon wrote: I agree with your comments but I also recognize that it is a slippery slope. Who is responsible for tracking the changes and lobbying the other groups? My limited experience tells me that this will likely end up being a set of forked code from other projects that will be very difficult to manage. for instance...say a quick change is made to XMLBeans and it get's put into our "local" copy. 4 months later the XMLBeans folks have not done anything with the patch and now after discussing it further decide that it doens't fit with their direction. During that time Geronimo has relied on the patch and changing direction is going to be painful. I would expect that most of the localized changes would be to pom's only and to install the correct version of the dependency in a repository for our build to work. While I think that we may need to have a few cases where some code is required to change, but in order for that to work, there must be someone who is actively working with the external community to get the changes in. Otherwise, as you suggested it would turn into a private fork... and IMO that is not acceptable. I believe that it would be the responsibility of the developer who introduces the new version of the dependency to create a JIRA (in our project) to manage the state of the dependency... AND be active about getting the changes introduced in the target communities codebase. Peer review will also be used to help ensure that we keep things moving smoothly. Like, if a custom version of a dependency exists for months and months and goes no where, then we need to react and either help the developer get the changes moved or reevaluate the need for those changes, etc. I realize this is a worse case scenario but we had a similar situation with the Axis guys in cutting a 1.4 release for us. It took about 6 months and I think was only done because David Blevins was made a committer. Um, did it take 6 months because he was a committer? Meaning it would have taken more than 6 months if he was not? Yikes! In order to consider this it would be great if you could flush out the different scenarios as you see them and how we would handle them. I'm not the most administrative person on the planet and what you are proposing sounds great and scare the heck out of me at the same time ;-0 Well... I'm not sure I know of all of the scenarios, but mostly I do not see that we will have custom forked versions of others work in our repository, though on some occasions yes, we will... but only for a very limited and controlled period. For example, I have been using the RetroTranslator m2 plugin in GShell for many weeks now. I have been very active about creating patches for the Mojo team, getting changes needed into this plugin so that it can be more useful. But, it takes the Mojo team time (some times a long time) to pull in those changes... or as is the current case, to publish the plugin with those changes already accepted and committed. So we have already gotten the code in the target communities codebase... but it is taking a long time to get a new release (or SNAPSHOT) pushed out to a repo so that we can actually use it. This is where our repository comes in. We publish a SNAPSHOT of the plugin to our repository so that we can continue to move forward using the plugin, and in the background keep on the Mojo peeps to get the thing official. * * * There is also the other-side of the repository, which is to allow builds to be reproducible in future months, years. To have 100% build reproducibility we need to have much more control over the repository which dependencies are pulled from. The reliance on so many external repositories is a build anti-pattern and make is very difficult (some times impossible) to ensure that builds will just work in future days, months, years. Machines crash, data gets lost, which we have recently seen and suffered from. Having a repository that is controlled by the same system as our sources will generally mean that at any point in time when when have a valid scm codebase, then we also have the valid dependencies. Then when the Codehaus disks die again, or a worm eats thought all of Ibiblio, then we can still function and continue to work. * * * I believe that both of these reasons (staging w/external groups and build reproduction and isolation from external failure) warrant the creation of an internal SVN-backed repository that exists solely for the use by Geronimo, and its child projects. --jason
Geronimo Repository (was Re: Unable to build using m2)
I agree with your comments but I also recognize that it is a slippery slope. Who is responsible for tracking the changes and lobbying the other groups? My limited experience tells me that this will likely end up being a set of forked code from other projects that will be very difficult to manage. for instance...say a quick change is made to XMLBeans and it get's put into our "local" copy. 4 months later the XMLBeans folks have not done anything with the patch and now after discussing it further decide that it doens't fit with their direction. During that time Geronimo has relied on the patch and changing direction is going to be painful. I would expect that most of the localized changes would be to pom's only and to install the correct version of the dependency in a repository for our build to work. While I think that we may need to have a few cases where some code is required to change, but in order for that to work, there must be someone who is actively working with the external community to get the changes in. Otherwise, as you suggested it would turn into a private fork... and IMO that is not acceptable. I believe that it would be the responsibility of the developer who introduces the new version of the dependency to create a JIRA (in our project) to manage the state of the dependency... AND be active about getting the changes introduced in the target communities codebase. Peer review will also be used to help ensure that we keep things moving smoothly. Like, if a custom version of a dependency exists for months and months and goes no where, then we need to react and either help the developer get the changes moved or reevaluate the need for those changes, etc. I realize this is a worse case scenario but we had a similar situation with the Axis guys in cutting a 1.4 release for us. It took about 6 months and I think was only done because David Blevins was made a committer. Um, did it take 6 months because he was a committer? Meaning it would have taken more than 6 months if he was not? Yikes! In order to consider this it would be great if you could flush out the different scenarios as you see them and how we would handle them. I'm not the most administrative person on the planet and what you are proposing sounds great and scare the heck out of me at the same time ;-0 Well... I'm not sure I know of all of the scenarios, but mostly I do not see that we will have custom forked versions of others work in our repository, though on some occasions yes, we will... but only for a very limited and controlled period. For example, I have been using the RetroTranslator m2 plugin in GShell for many weeks now. I have been very active about creating patches for the Mojo team, getting changes needed into this plugin so that it can be more useful. But, it takes the Mojo team time (some times a long time) to pull in those changes... or as is the current case, to publish the plugin with those changes already accepted and committed. So we have already gotten the code in the target communities codebase... but it is taking a long time to get a new release (or SNAPSHOT) pushed out to a repo so that we can actually use it. This is where our repository comes in. We publish a SNAPSHOT of the plugin to our repository so that we can continue to move forward using the plugin, and in the background keep on the Mojo peeps to get the thing official. * * * There is also the other-side of the repository, which is to allow builds to be reproducible in future months, years. To have 100% build reproducibility we need to have much more control over the repository which dependencies are pulled from. The reliance on so many external repositories is a build anti-pattern and make is very difficult (some times impossible) to ensure that builds will just work in future days, months, years. Machines crash, data gets lost, which we have recently seen and suffered from. Having a repository that is controlled by the same system as our sources will generally mean that at any point in time when when have a valid scm codebase, then we also have the valid dependencies. Then when the Codehaus disks die again, or a worm eats thought all of Ibiblio, then we can still function and continue to work. * * * I believe that both of these reasons (staging w/external groups and build reproduction and isolation from external failure) warrant the creation of an internal SVN-backed repository that exists solely for the use by Geronimo, and its child projects. --jason
Re: Unable to build using m2
Jason Dillon wrote: Urg... this is another thing about Maven that really bothers me... we are SO completely dependent on other projects for our own project to succeed. This would not be a problem if we had our own repo that we had complete ownership of. We could fix any poms and install fixed plugins. How would we get these fixes back into the community? I worry that having our own repo would make it harder to assure that we are using generally available versions of other projects, and make it harder to contribute our fixes back to those projects. For instance, it took me some time to get an m2 build of howl working and find out how to get it published, but the result is IMO much better for both howl and us than if we simply said "we'll just stick a pom for howl in our private repo". We could use JIRA to manage any customizations that we have been forced to make to get _our_ build working, and then work with the external groups to merge the changes and ultimately get sync'd up with more official drops. BUT, I still believe that it is in our communities best interest to maintain our own repository. And... the build would be completely repeatable. Chances are that in a year or two, if anyone tries to build anything with Maven off of an old branch it will fail miserably. IMO this is not acceptable. Future build failures should only result from someone trashing the supposedly permanent ibiblio repo. As far as your other points, any time we decide to use software written by some other community, we are depending on them to do some work for us. I think we need to adopt a process that assures our contributions to their project in fact get back to their project in a timely fashion. I agree completely. What I am suggesting is that we use our own repo to facilitate this process while letting our project move forward. The alternative is that we must work in lock step with every other community... where a trivial change to a pom takes weeks to get implemented and pushed. I really don't like to have to go and check out a bunch of external tools or libraries and then go step by step, configure and build them... and hope like heck that their builds work all of the time, and pray that Maven does not freak-out halfway through a long build due to a missing dependency or repository timeout... just to get the right bits in place to maybe get our build moving forward, Seems to me the alternative is to not use anyone elses code, which I find unacceptable. I don't believe that not using thirdparty code is an option. We just need to find and implement a better way of dealing with them. I do believe that for a large project like Geronimo, that the central remote repository model breaks down and is not very functional for current builds or for repeatable builds of older code. I surely don't have all the answers, but I'd prefer that anything we adopt doesn't result in our having all sorts of private changes that are not accepted by projects we use. I do not believe that this will be the case. The repo would mostly exist to support the longevity of our builds and for short-term fixes while we wait the term and lobby external groups to get changes pushed back into their community. So, some kind of geronimo repo that has a subset of publically available stuff is ok with me, but putting private patches that aren't from the originating project seems like asking for trouble. I agree, though as mentioned above, some artifacts may be custom in the short-term. For example, we could "fix" the xmlbeans artifacts and poms, deploy them to our repo and then track the progress of integrating them back into the main xmlbeans community with JIRA. This is a case where we have a private version in the repo, but it will only live there (with a specialized version of course) until the time is passed when the xmlbeans team can work in the changes. "In theory there is no difference in theory and practice. In practice there is." I agree with your comments but I also recognize that it is a slippery slope. Who is responsible for tracking the changes and lobbying the other groups? My limited experience tells me that this will likely end up being a set of forked code from other projects that will be very difficult to manage. for instance...say a quick change is made to XMLBeans and it get's put into our "local" copy. 4 months later the XMLBeans folks have not done anything with the patch and now after discussing it further decide that it doens't fit with their direction. During that time Geronimo has relied on the patch and changing direction is going to be painful. I realize this is a worse case scenario but we had a similar situation with the Axis guys in cutting a 1.4 release for us. It took about 6 months and I think was only done because David Blevins was made a committer. In order to consider this it would be great if you could flush
Re: Unable to build using m2
OK, so lets be clear, we have no dependency from modules on plugins, In m2-speak every project that has children, those sub-projects are called modules. More reason to move to m2 sooner rather than later, so we can do away with the modules/ directory, which is an artifact of the original m1 build structure. It needs to be removed. the problem is that maven 2 is really even more broken with plugin support than even maven 1. Has anyone discussed this problem with them? is there a maven jira? I do not believe that the m2 plugin system is broken. I think that they way that plugins were put together for m1 was broken and that is what should be fixed. --jason
Re: Unable to build using m2
Urg... this is another thing about Maven that really bothers me... we are SO completely dependent on other projects for our own project to succeed. This would not be a problem if we had our own repo that we had complete ownership of. We could fix any poms and install fixed plugins. How would we get these fixes back into the community? I worry that having our own repo would make it harder to assure that we are using generally available versions of other projects, and make it harder to contribute our fixes back to those projects. For instance, it took me some time to get an m2 build of howl working and find out how to get it published, but the result is IMO much better for both howl and us than if we simply said "we'll just stick a pom for howl in our private repo". We could use JIRA to manage any customizations that we have been forced to make to get _our_ build working, and then work with the external groups to merge the changes and ultimately get sync'd up with more official drops. BUT, I still believe that it is in our communities best interest to maintain our own repository. And... the build would be completely repeatable. Chances are that in a year or two, if anyone tries to build anything with Maven off of an old branch it will fail miserably. IMO this is not acceptable. Future build failures should only result from someone trashing the supposedly permanent ibiblio repo. As far as your other points, any time we decide to use software written by some other community, we are depending on them to do some work for us. I think we need to adopt a process that assures our contributions to their project in fact get back to their project in a timely fashion. I agree completely. What I am suggesting is that we use our own repo to facilitate this process while letting our project move forward. The alternative is that we must work in lock step with every other community... where a trivial change to a pom takes weeks to get implemented and pushed. I really don't like to have to go and check out a bunch of external tools or libraries and then go step by step, configure and build them... and hope like heck that their builds work all of the time, and pray that Maven does not freak-out halfway through a long build due to a missing dependency or repository timeout... just to get the right bits in place to maybe get our build moving forward, Seems to me the alternative is to not use anyone elses code, which I find unacceptable. I don't believe that not using thirdparty code is an option. We just need to find and implement a better way of dealing with them. I do believe that for a large project like Geronimo, that the central remote repository model breaks down and is not very functional for current builds or for repeatable builds of older code. I surely don't have all the answers, but I'd prefer that anything we adopt doesn't result in our having all sorts of private changes that are not accepted by projects we use. I do not believe that this will be the case. The repo would mostly exist to support the longevity of our builds and for short-term fixes while we wait the term and lobby external groups to get changes pushed back into their community. So, some kind of geronimo repo that has a subset of publically available stuff is ok with me, but putting private patches that aren't from the originating project seems like asking for trouble. I agree, though as mentioned above, some artifacts may be custom in the short-term. For example, we could "fix" the xmlbeans artifacts and poms, deploy them to our repo and then track the progress of integrating them back into the main xmlbeans community with JIRA. This is a case where we have a private version in the repo, but it will only live there (with a specialized version of course) until the time is passed when the xmlbeans team can work in the changes. --jason
Re: Unable to build using m2
On Jun 27, 2006, at 2:28 PM, Jason Dillon wrote: Drop the `cd modules` Build from the top-level. OK, so lets be clear, we have no dependency from modules on plugins, the problem is that maven 2 is really even more broken with plugin support than even maven 1. Has anyone discussed this problem with them? is there a maven jira? thanks david jencks --jason On Jun 27, 2006, at 2:13 PM, David Jencks wrote: Can you guys provide some details? I can't reproduce this. There is certainly not supposed to be any dependency of a module on any m2 plugin. rm -rf ~/.m2/repository/org/apache/geronimo/plugins/ cd modules/ mvn -o clean install -Dmaven.test.skip=true ... [INFO] BUILD SUCCESSFUL [INFO] - --- [INFO] Total time: 9 minutes [INFO] Finished at: Tue Jun 27 14:10:10 PDT 2006 [INFO] Final Memory: 22M/45M [INFO] - --- thanks david jencks On Jun 27, 2006, at 1:45 PM, Jacek Laskowski wrote: On 6/27/06, Bill Dudney <[EMAIL PROTECTED]> wrote: Hi Prasad, AFAIKT the m2-plugins depend on the modules/deploy but the modules build depends on the m2-plugins so even though the cycle is not called out it appears to exist. That reflects my sentiments as well :-) Is anyone able to do a clean build from the top with m2? Nope. I've been unable to do so since a week or so. Bill Dudney Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: Unable to build using m2
On Jun 27, 2006, at 2:15 PM, Jason Dillon wrote: Any idea where the stax:stax-api:1.1.1-dev comes from? The root pom states that stax:stax-api:1.0 should be used... but the errors with the xmlbeans plugin all state 1.1.1-dev. I've filed a bunch of bugs all over the place and the current status is: -- I'm working with the xmlbeans team to publish correct poms for xmlbeans 2.0.0-1, 2.1.0-1, and 2.2.0. This will take a while, but apparently won't conflict with the maven evangelism rules (my first attempt revealed that the evangelism instructions had no relationship to the actual process the maven team uses) How long is a while? don't know, I think I understand the dependencies properly, but I'd like to come up with plausible non-minimal poms for them. Urg... this is another thing about Maven that really bothers me... we are SO completely dependent on other projects for our own project to succeed. This would not be a problem if we had our own repo that we had complete ownership of. We could fix any poms and install fixed plugins. How would we get these fixes back into the community? I worry that having our own repo would make it harder to assure that we are using generally available versions of other projects, and make it harder to contribute our fixes back to those projects. For instance, it took me some time to get an m2 build of howl working and find out how to get it published, but the result is IMO much better for both howl and us than if we simply said "we'll just stick a pom for howl in our private repo". And... the build would be completely repeatable. Chances are that in a year or two, if anyone tries to build anything with Maven off of an old branch it will fail miserably. IMO this is not acceptable. Future build failures should only result from someone trashing the supposedly permanent ibiblio repo. As far as your other points, any time we decide to use software written by some other community, we are depending on them to do some work for us. I think we need to adopt a process that assures our contributions to their project in fact get back to their project in a timely fashion. -- The maven xmlbeans plugin has had a couple fixes applied, but whether a snapshot is publically available is not clear to me. I strongly recommend building the xmlbeans plugin from source. IIRC this will eliminate the need for the bogus stax dependencies. Here's the latest relevant jira: http://jira.codehaus.org/browse/ MXMLBEANS-20?page=all After all the fixes are in we should not need any dependencies on stax-api and the bogus dependencies on stax can be removed. I really don't like to have to go and check out a bunch of external tools or libraries and then go step by step, configure and build them... and hope like heck that their builds work all of the time, and pray that Maven does not freak-out halfway through a long build due to a missing dependency or repository timeout... just to get the right bits in place to maybe get our build moving forward, Seems to me the alternative is to not use anyone elses code, which I find unacceptable. This is a nightmare IMO. I remember a certain nightmarish build way back in the day that needed a bit of magic... in comparison to our build, that nightmare was the sweetest of dreams. * * * The more I think about it the more it appears thats something major is going to need to be done to really fix things... I surely don't have all the answers, but I'd prefer that anything we adopt doesn't result in our having all sorts of private changes that are not accepted by projects we use. So, some kind of geronimo repo that has a subset of publically available stuff is ok with me, but putting private patches that aren't from the originating project seems like asking for trouble. thanks david jencks --jason
Re: Unable to build using m2
This is what I was trying to do as well. Regards, Alan Jason Dillon wrote: Drop the `cd modules` Build from the top-level. --jason On Jun 27, 2006, at 2:13 PM, David Jencks wrote: Can you guys provide some details? I can't reproduce this. There is certainly not supposed to be any dependency of a module on any m2 plugin. rm -rf ~/.m2/repository/org/apache/geronimo/plugins/ cd modules/ mvn -o clean install -Dmaven.test.skip=true ... [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 9 minutes [INFO] Finished at: Tue Jun 27 14:10:10 PDT 2006 [INFO] Final Memory: 22M/45M [INFO] thanks david jencks On Jun 27, 2006, at 1:45 PM, Jacek Laskowski wrote: On 6/27/06, Bill Dudney <[EMAIL PROTECTED]> wrote: Hi Prasad, AFAIKT the m2-plugins depend on the modules/deploy but the modules build depends on the m2-plugins so even though the cycle is not called out it appears to exist. That reflects my sentiments as well :-) Is anyone able to do a clean build from the top with m2? Nope. I've been unable to do so since a week or so. Bill Dudney Jacek --Jacek Laskowski http://www.laskowski.net.pl
Re: Unable to build using m2
On 6/28/06, David Blevins <[EMAIL PROTECTED]> wrote: Snapshots are never synched to ibiblio, not sure if you meant to imply that. Right. I was mistaken saying they were. The point was that I did nothing to upload them to the places they could have been downloaded. Thanks! -David Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: Unable to build using m2
One question. I was under the assumption that we would publish 1.2-SNAPSHOT to M2 repos and no longer to M1 repos. I don't recall seeing this discussion so if someone can help an old man remember :) anita kulshreshtha wrote: Did they get published to an m1 repo under a groupId o.a.g? Maven-one-plugin generates these jars and poms. Thanks Anita --- David Blevins <[EMAIL PROTECTED]> wrote: On Jun 27, 2006, at 1:41 PM, Jacek Laskowski wrote: On 6/27/06, anita kulshreshtha <[EMAIL PROTECTED]> wrote: Alan, When Jacek was coordinating the m2 build, the snapshots were continuously published. Any missing geronimo jar or pom was available from the repo. The same must be done for the plugin. I am not sure how this was done. I think he had the karma to push the jars to the repo. Thus I call myself lucky. I wasn't doing anything but checking the patches into the repo. You can push jars to the repo via the asf link, i.e. saving them in a proper directory on people.apache.org that is sync'ed with iBiblio. Snapshots are never synched to ibiblio, not sure if you meant to imply that. -David __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Unable to build using m2
Did they get published to an m1 repo under a groupId o.a.g? Maven-one-plugin generates these jars and poms. Thanks Anita --- David Blevins <[EMAIL PROTECTED]> wrote: > On Jun 27, 2006, at 1:41 PM, Jacek Laskowski wrote: > > > On 6/27/06, anita kulshreshtha <[EMAIL PROTECTED]> wrote: > >> Alan, > >> When Jacek was coordinating the m2 build, the snapshots were > >> continuously published. Any missing geronimo jar or pom was > available > >> from the repo. The same must be done for the plugin. I am not sure > > >> how > >> this was done. I think he had the karma to push the jars to the > repo. > > > > Thus I call myself lucky. I wasn't doing anything but checking the > > patches into the repo. You can push jars to the repo via the asf > link, > > i.e. saving them in a proper directory on people.apache.org that is > > sync'ed with iBiblio. > > Snapshots are never synched to ibiblio, not sure if you meant to > imply that. > > -David > > __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Unable to build using m2
Alright, alright. Stop whining already :-) :-) Now somebody please apply the patch in http://issues.apache.org/jira/browse/GERONIMO-2157. We can then build trunk from top down with 1 single command. I still can't find anything in the modules that depends on the geronimo-plugins. I cleaned out the o.a.g.* in the maven.local.repo and built from top. Modules build first successfully. Cheers Prasad On 6/27/06, David Blevins <[EMAIL PROTECTED]> wrote: On Jun 27, 2006, at 1:41 PM, Jacek Laskowski wrote: > On 6/27/06, anita kulshreshtha <[EMAIL PROTECTED]> wrote: >> Alan, >> When Jacek was coordinating the m2 build, the snapshots were >> continuously published. Any missing geronimo jar or pom was available >> from the repo. The same must be done for the plugin. I am not sure >> how >> this was done. I think he had the karma to push the jars to the repo. > > Thus I call myself lucky. I wasn't doing anything but checking the > patches into the repo. You can push jars to the repo via the asf link, > i.e. saving them in a proper directory on people.apache.org that is > sync'ed with iBiblio. Snapshots are never synched to ibiblio, not sure if you meant to imply that. -David
Re: Unable to build using m2
On Jun 27, 2006, at 1:41 PM, Jacek Laskowski wrote: On 6/27/06, anita kulshreshtha <[EMAIL PROTECTED]> wrote: Alan, When Jacek was coordinating the m2 build, the snapshots were continuously published. Any missing geronimo jar or pom was available from the repo. The same must be done for the plugin. I am not sure how this was done. I think he had the karma to push the jars to the repo. Thus I call myself lucky. I wasn't doing anything but checking the patches into the repo. You can push jars to the repo via the asf link, i.e. saving them in a proper directory on people.apache.org that is sync'ed with iBiblio. Snapshots are never synched to ibiblio, not sure if you meant to imply that. -David
Re: Unable to build using m2
On Jun 27, 2006, at 9:26 AM, David Jencks wrote: On Jun 26, 2006, at 8:41 PM, Jason Dillon wrote: Probably... But is it really needed to build the sever? yes, how else would it have ejb support? Obviously openejb is not required to build anything in "modules" as the build is supposed to proceed specs modules m2-plugins openejb apps configs assembly I haven't tried a top level build, maybe there are some bugs in it. Maybe after jason's proposed splitting of modules into smaller more focussed pieces we can release some kind of core geronimo jars and they will be stable enough so it is plausible to release openejb on a separate schedule. Maybe openejb3 won't use any geronimo classes and we'll have an openejb integration in geronimo. These are giant changes far larger than the m2 conversion. Until we do something along those lines, I don't understand why we'd assure that no builds ever worked by taking openejb out of the build. I agree largely with what you're saying sans the perspective that the build is guaranteed to break if one doesn't build openejb during a geronimo build. I might politely point out you're succumbing to frustration and exaggerating the issue. With continuum building and publishing snapshots of geronimo and openejb as they are updated in svn, failed geronimo builds due to old openejb jars is an uncommon problem. The only current issue in that regard is that since codehaus went down and came up with new infra, we haven't worked out how to publish any codehaus jars (tranql, openejb), hence people as of recent are having issues with both of those. That needs to get fixed. But concretely, the problem is solvable within a tolerance of an hour or so by continuously publishing the projects. It could be solved with zero tolerance for failure if the person committing the change published new openejb snapshots. -David thanks david jencks --jason On Jun 26, 2006, at 8:33 PM, Prasad Kashyap wrote: Maybe 'coz we built it with "new2" before ? Not sure. Cheers Prasad On 6/26/06, Jason Dillon <[EMAIL PROTECTED]> wrote: Why is openejb included in "our" build at all? --jason On Jun 26, 2006, at 8:25 PM, Prasad Kashyap wrote: > These are the problems I encountered, encountering. > > openejb: > > 1. openejb/modules/pom.xml specified dependency on > tranql-1.3-SNAPSHOT. That version of tranql doesn'tr exist. Think it > should use 1.4-SNAPSHOT. It should also add dist.codehaus.org into > it's > > 2. openejb/modules/pom.xml specified dependency on > geronimo-spec:geronimo-spec-corba:1.0-SNAPSHOT which again doesn't > exist. It should specify version 2.3-rc4. > > 3. openejb/modules/pom.xml specified dependency on > org.codehaus.org:xmlbeans-maven-plugin:2.0.3-SNAPSHOT. Don't know > where that version is deployed. Maybe that will fix the > xmlbeans:xmlbeans-jsr173-api:jar:2.0-dev exclusion. If only we can > find that repo. Changed it 2.0 and built it successfully. > > 4. unable to build configs/openejb-deployer. > Caused by: org.apache.geronimo.kernel.config.InvalidConfigException: > Error starting configuration gbean > org.apache.geronimo.configs/openejb-deployer/1.2-SNAPSHOT/car > > Cheers > Prasad > > On 6/26/06, Prasad Kashyap <[EMAIL PROTECTED]> wrote: >> http://www.mail-archive.com/[email protected]/ msg25378.html >> >> On 6/26/06, Jason Dillon <[EMAIL PROTECTED]> wrote: >> > What the heck is up with the xmlbeans plugin? >> > >> > I keep getting this from the top-level: >> > >> > >> > [INFO] >> > >> --- -- >> --- >> > [ERROR] BUILD ERROR >> > [INFO] >> > >> --- -- >> --- >> > [INFO] Failed to resolve artifact. >> > >> > Missing: >> > -- >> > 1) xmlbeans:xmlbeans-jsr173-api:jar:2.0-dev >> > >> >Try downloading the file manually from the project website. >> > >> >Then, install it using the command: >> >mvn install:install-file -DgroupId=xmlbeans - >> > DartifactId=xmlbeans-jsr173-api \ >> >-Dversion=2.0-dev -Dpackaging=jar -Dfile=/path/ to/file >> > >> >Path to dependency: >> > 1) org.apache.geronimo.modules:geronimo-j2ee- >> builder:jar:1.2- >> > SNAPSHOT >> > 2) stax:stax:jar:1.1.1-dev >> > 3) xmlbeans:xmlbeans-jsr173-api:jar:2.0-dev >> > >> > -- >> > 1 required artifact is missing. >> > >> > for artifact: >> >org.apache.geronimo.modules:geronimo-j2ee-builder:jar:1.2- >> SNAPSHOT >> > >> > from the specified remote repositories: >> >central (http://repo1.maven.org/maven2), >> >codehaus-dist (http://dist.codehaus.org), >> >Apache CVS (http://people.apache.org/maven-snapshot- repository), >> >maven1-ibiblio (http://www.ibiblio.org/maven), >> >snapshots (http://snapshots.maven.codehaus.org/maven2), >> >apache-cvs (http://cvs.apache.org/reposito
Re: Unable to build using m2
I have done the same, deleted o/a/g/pluigns and was able to build rev 415213 using - cd modules mvn -o clean install maven.test.skip=true Thanks Anita --- David Jencks <[EMAIL PROTECTED]> wrote: > Can you guys provide some details? I can't reproduce this. There is > > certainly not supposed to be any dependency of a module on any m2 > plugin. > > rm -rf ~/.m2/repository/org/apache/geronimo/plugins/ > cd modules/ > mvn -o clean install -Dmaven.test.skip=true > > ... > > [INFO] BUILD SUCCESSFUL > [INFO] > > [INFO] Total time: 9 minutes > [INFO] Finished at: Tue Jun 27 14:10:10 PDT 2006 > [INFO] Final Memory: 22M/45M > [INFO] > > > thanks > david jencks > > > On Jun 27, 2006, at 1:45 PM, Jacek Laskowski wrote: > > > On 6/27/06, Bill Dudney <[EMAIL PROTECTED]> wrote: > >> Hi Prasad, > >> > >> AFAIKT the m2-plugins depend on the modules/deploy but the modules > >> build depends on the m2-plugins so even though the cycle is not > >> called out it appears to exist. > > > > That reflects my sentiments as well :-) > > > >> Is anyone able to do a clean build from the top with m2? > > > > Nope. I've been unable to do so since a week or so. > > > >> Bill Dudney > > > > Jacek > > > > -- > > Jacek Laskowski > > http://www.laskowski.net.pl > > __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Unable to build using m2
Drop the `cd modules` Build from the top-level. --jason On Jun 27, 2006, at 2:13 PM, David Jencks wrote: Can you guys provide some details? I can't reproduce this. There is certainly not supposed to be any dependency of a module on any m2 plugin. rm -rf ~/.m2/repository/org/apache/geronimo/plugins/ cd modules/ mvn -o clean install -Dmaven.test.skip=true ... [INFO] BUILD SUCCESSFUL [INFO] -- -- [INFO] Total time: 9 minutes [INFO] Finished at: Tue Jun 27 14:10:10 PDT 2006 [INFO] Final Memory: 22M/45M [INFO] -- -- thanks david jencks On Jun 27, 2006, at 1:45 PM, Jacek Laskowski wrote: On 6/27/06, Bill Dudney <[EMAIL PROTECTED]> wrote: Hi Prasad, AFAIKT the m2-plugins depend on the modules/deploy but the modules build depends on the m2-plugins so even though the cycle is not called out it appears to exist. That reflects my sentiments as well :-) Is anyone able to do a clean build from the top with m2? Nope. I've been unable to do so since a week or so. Bill Dudney Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: Unable to build using m2
This is classic chicken and egg... having G depend on G plugins that also depend on G for the plugin to be built. This might have worked before in m1, but so far I have not been able to get a plugin built and then used in the same build cycle with m2. this was allegedly one of the advantages of m2, it was nearly impossible in m1. Need to get some clarification from the Maven team, but from what I have seen and tried... building plugins and modules that use those plugins in the same cycle is not possible. And, with m1 it is only barely possible with some rather massive hacks. Both are a bad idea... and can be fixed by properly segmenting the build and separating build concerns. What parts of the build need these plugins? packaging plugin >> configs assembly plugin >> assembly deployment plugin (any chance any one else will vote or should I give up?) >> integration tests. Is it just the config modules? If so then we may need to split the build into two chunks, one that builds the modules and plugins, and then another than builds the configs and assemblies. Doesn't the listing of subprojects in top level pom.xml do this? Negative. When m2 starts up it will scan all modules that are configured and then scan its dependencies, and then continue to process build dependencies (plugins, extensions, etc). If a module depends on a plugin that does not exist in the repository it will cause the build to fail... even if the module to build that plugin is included on the build path. There is another fly lurking ready to get into the ointment, it's possible that we may eventually want to intersperse jar and car (currently confusingly named modules and configs) builds in order to completely align our dependency tracking with maven's dependency tracking. Then we could use the poms instead of our own files. Not sure what you mean by this could you explain a bit further? --jason
Re: Unable to build using m2
The problem is I and others can't get things to build. Our stuff should build out of the box w/ a simple mvn install I am 100% behind this philosophy of builds. --jason
Re: Unable to build using m2
Any idea where the stax:stax-api:1.1.1-dev comes from? The root pom states that stax:stax-api:1.0 should be used... but the errors with the xmlbeans plugin all state 1.1.1-dev. I've filed a bunch of bugs all over the place and the current status is: -- I'm working with the xmlbeans team to publish correct poms for xmlbeans 2.0.0-1, 2.1.0-1, and 2.2.0. This will take a while, but apparently won't conflict with the maven evangelism rules (my first attempt revealed that the evangelism instructions had no relationship to the actual process the maven team uses) How long is a while? Urg... this is another thing about Maven that really bothers me... we are SO completely dependent on other projects for our own project to succeed. This would not be a problem if we had our own repo that we had complete ownership of. We could fix any poms and install fixed plugins. And... the build would be completely repeatable. Chances are that in a year or two, if anyone tries to build anything with Maven off of an old branch it will fail miserably. IMO this is not acceptable. -- The maven xmlbeans plugin has had a couple fixes applied, but whether a snapshot is publically available is not clear to me. I strongly recommend building the xmlbeans plugin from source. IIRC this will eliminate the need for the bogus stax dependencies. Here's the latest relevant jira: http://jira.codehaus.org/browse/ MXMLBEANS-20?page=all After all the fixes are in we should not need any dependencies on stax-api and the bogus dependencies on stax can be removed. I really don't like to have to go and check out a bunch of external tools or libraries and then go step by step, configure and build them... and hope like heck that their builds work all of the time, and pray that Maven does not freak-out halfway through a long build due to a missing dependency or repository timeout... just to get the right bits in place to maybe get our build moving forward, This is a nightmare IMO. I remember a certain nightmarish build way back in the day that needed a bit of magic... in comparison to our build, that nightmare was the sweetest of dreams. * * * The more I think about it the more it appears thats something major is going to need to be done to really fix things... --jason
Re: Unable to build using m2
Can you guys provide some details? I can't reproduce this. There is certainly not supposed to be any dependency of a module on any m2 plugin. rm -rf ~/.m2/repository/org/apache/geronimo/plugins/ cd modules/ mvn -o clean install -Dmaven.test.skip=true ... [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 9 minutes [INFO] Finished at: Tue Jun 27 14:10:10 PDT 2006 [INFO] Final Memory: 22M/45M [INFO] thanks david jencks On Jun 27, 2006, at 1:45 PM, Jacek Laskowski wrote: On 6/27/06, Bill Dudney <[EMAIL PROTECTED]> wrote: Hi Prasad, AFAIKT the m2-plugins depend on the modules/deploy but the modules build depends on the m2-plugins so even though the cycle is not called out it appears to exist. That reflects my sentiments as well :-) Is anyone able to do a clean build from the top with m2? Nope. I've been unable to do so since a week or so. Bill Dudney Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: Unable to build using m2
On Jun 27, 2006, at 1:59 PM, Jason Dillon wrote: It's clear to me that we need to break out our plugins build and get the plugins published ASAP. I asked this in another thread, what will it take to get this published? I don't think that it's too much trouble, just an RTC to break the plugin out and then we just start publishing the snapshots. We can shoot for a plugin release around the time of G v1.2.0> This is totally not clear to me. All our plugins are going to depend heavily on geronimo code, why would we try to publish them separately or before the artifacts they depend on are published? This is classic chicken and egg... having G depend on G plugins that also depend on G for the plugin to be built. This might have worked before in m1, but so far I have not been able to get a plugin built and then used in the same build cycle with m2. this was allegedly one of the advantages of m2, it was nearly impossible in m1. What parts of the build need these plugins? packaging plugin >> configs assembly plugin >> assembly deployment plugin (any chance any one else will vote or should I give up?) >> integration tests. Is it just the config modules? If so then we may need to split the build into two chunks, one that builds the modules and plugins, and then another than builds the configs and assemblies. Doesn't the listing of subprojects in top level pom.xml do this? We are much better off now than we were with m1 where the dependency plugin required some g. classes and was used to build g. modules. There is another fly lurking ready to get into the ointment, it's possible that we may eventually want to intersperse jar and car (currently confusingly named modules and configs) builds in order to completely align our dependency tracking with maven's dependency tracking. Then we could use the poms instead of our own files. thanks david jencks --jason
Re: Unable to build using m2
But is it really needed to build the sever? yes, how else would it have ejb support? Are there no binary versions of OpenEJB that we integrate with? If not, how can we get to that point... Or we need to check in the OpenEJB tree to our project... and/or use a SVN property to force the OpenEJB sources to check out when G is checked out... but I think that would only be a short-term solution, as I believe that we need binaries to integrate with. Having to build dependent projects as prerequisites for G to build is adding extra complexity and increasing the chances that the build will break. I haven't tried a top level build, maybe there are some bugs in it. Is this the norm? For developers to not run top-level builds? Maybe after jason's proposed splitting of modules into smaller more focussed pieces we can release some kind of core geronimo jars and they will be stable enough so it is plausible to release openejb on a separate schedule. Maybe openejb3 won't use any geronimo classes and we'll have an openejb integration in geronimo. Oh... what does OpenEJB need from G to build? This is another chicken and egg... :-( These are giant changes far larger than the m2 conversion. Until we do something along those lines, I don't understand why we'd assure that no builds ever worked by taking openejb out of the build. I did not realize that OpenEJB was so closely coupled to the Geronimo code-base. Can someone quickly explain what parts of G OpenEJB is dependent upon? Thanks, --jason
Re: Unable to build using m2
It's clear to me that we need to break out our plugins build and get the plugins published ASAP. I asked this in another thread, what will it take to get this published? I don't think that it's too much trouble, just an RTC to break the plugin out and then we just start publishing the snapshots. We can shoot for a plugin release around the time of G v1.2.0> This is totally not clear to me. All our plugins are going to depend heavily on geronimo code, why would we try to publish them separately or before the artifacts they depend on are published? This is classic chicken and egg... having G depend on G plugins that also depend on G for the plugin to be built. This might have worked before in m1, but so far I have not been able to get a plugin built and then used in the same build cycle with m2. What parts of the build need these plugins? Is it just the config modules? If so then we may need to split the build into two chunks, one that builds the modules and plugins, and then another than builds the configs and assemblies. --jason
Re: Unable to build using m2
On 6/27/06, Bill Dudney <[EMAIL PROTECTED]> wrote: Hi Prasad, AFAIKT the m2-plugins depend on the modules/deploy but the modules build depends on the m2-plugins so even though the cycle is not called out it appears to exist. That reflects my sentiments as well :-) Is anyone able to do a clean build from the top with m2? Nope. I've been unable to do so since a week or so. Bill Dudney Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: Unable to build using m2
On 6/27/06, anita kulshreshtha <[EMAIL PROTECTED]> wrote: Alan, When Jacek was coordinating the m2 build, the snapshots were continuously published. Any missing geronimo jar or pom was available from the repo. The same must be done for the plugin. I am not sure how this was done. I think he had the karma to push the jars to the repo. Thus I call myself lucky. I wasn't doing anything but checking the patches into the repo. You can push jars to the repo via the asf link, i.e. saving them in a proper directory on people.apache.org that is sync'ed with iBiblio. Anita Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: Unable to build using m2
David Jencks has raised some concerns. Let's iron them out first but, we don't need an RTC vote to publish snapshots of already checked in code. Regards, Alan anita kulshreshtha wrote: Alan, When Jacek was coordinating the m2 build, the snapshots were continuously published. Any missing geronimo jar or pom was available from the repo. The same must be done for the plugin. I am not sure how this was done. I think he had the karma to push the jars to the repo. For now it will be enough to publish the plugin(s) and change the version to SNAPSHOT as suggested by Jason. Is an RTC required? Thanks Anita --- "Alan D. Cabrera" <[EMAIL PROTECTED]> wrote: It's clear to me that we need to break out our plugins build and get the plugins published ASAP. I asked this in another thread, what will it take to get this published? I don't think that it's too much trouble, just an RTC to break the plugin out and then we just start publishing the snapshots. We can shoot for a plugin release around the time of G v1.2.0> Regards, Alan Jason Dillon wrote: 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. --jason On Jun 26, 2006, at 1:05 PM, Prasad Kashyap wrote: Alan, You'd have to build the geronimo-packaging-plugin manually first. It's under geronimo/m2-plugins cd geronimo/m2-plugins mvn clean mvn -N mvn Cheers Prasad On 6/25/06, Alan D. Cabrera <[EMAIL PROTECTED]> wrote: I get this error: Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.geronimo.plugins -DartifactId=geronimo-packaging-plugin \ -Dversion=1.2.0 -Dpackaging=maven-plugin -Dfile=/path/to/file org.apache.geronimo.plugins:geronimo-packaging-plugin:maven-plugin:1.2.0 from the specified remote repositories: central (http://repo1.maven.org/maven2), codehaus-dist (http://dist.codehaus.org/mojo/m2-snapshots), snapshots (http://snapshots.maven.codehaus.org/maven2) org.apache.geronimo.plugins:geronimo-packaging-plugin:maven-plugin:1.2.0 from the specified remote repositories: central (http://repo1.maven.org/maven2), codehaus-dist (http://dist.codehaus.org/mojo/m2-snapshots), snapshots (http://snapshots.maven.codehaus.org/maven2) Regards, Alan __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Unable to build using m2
David Jencks wrote: On Jun 26, 2006, at 9:17 PM, Alan D. Cabrera wrote: It's clear to me that we need to break out our plugins build and get the plugins published ASAP. I asked this in another thread, what will it take to get this published? I don't think that it's too much trouble, just an RTC to break the plugin out and then we just start publishing the snapshots. We can shoot for a plugin release around the time of G v1.2.0> This is totally not clear to me. All our plugins are going to depend heavily on geronimo code, why would we try to publish them separately or before the artifacts they depend on are published? Since we ditched the dependency plugin for the m2 build all the plugins can be built after all the modules. I really fail to see any problem in this and dont see how publishing the plugins now could cause anything but total build breakage. The problem is I and others can't get things to build. Our stuff should build out of the box w/ a simple mvn install Maybe others have a different opinion. I am not intransigent on this. Regards, Alan
Re: Unable to build using m2
On Jun 26, 2006, at 8:41 PM, Jason Dillon wrote: Any idea where the stax:stax-api:1.1.1-dev comes from? The root pom states that stax:stax-api:1.0 should be used... but the errors with the xmlbeans plugin all state 1.1.1-dev. I've filed a bunch of bugs all over the place and the current status is: -- I'm working with the xmlbeans team to publish correct poms for xmlbeans 2.0.0-1, 2.1.0-1, and 2.2.0. This will take a while, but apparently won't conflict with the maven evangelism rules (my first attempt revealed that the evangelism instructions had no relationship to the actual process the maven team uses) -- The maven xmlbeans plugin has had a couple fixes applied, but whether a snapshot is publically available is not clear to me. I strongly recommend building the xmlbeans plugin from source. IIRC this will eliminate the need for the bogus stax dependencies. Here's the latest relevant jira: http://jira.codehaus.org/browse/ MXMLBEANS-20?page=all After all the fixes are in we should not need any dependencies on stax-api and the bogus dependencies on stax can be removed. thanks david jencks --jason On Jun 26, 2006, at 8:25 PM, Prasad Kashyap wrote: These are the problems I encountered, encountering. openejb: 1. openejb/modules/pom.xml specified dependency on tranql-1.3-SNAPSHOT. That version of tranql doesn'tr exist. Think it should use 1.4-SNAPSHOT. It should also add dist.codehaus.org into it's 2. openejb/modules/pom.xml specified dependency on geronimo-spec:geronimo-spec-corba:1.0-SNAPSHOT which again doesn't exist. It should specify version 2.3-rc4. 3. openejb/modules/pom.xml specified dependency on org.codehaus.org:xmlbeans-maven-plugin:2.0.3-SNAPSHOT. Don't know where that version is deployed. Maybe that will fix the xmlbeans:xmlbeans-jsr173-api:jar:2.0-dev exclusion. If only we can find that repo. Changed it 2.0 and built it successfully. 4. unable to build configs/openejb-deployer. Caused by: org.apache.geronimo.kernel.config.InvalidConfigException: Error starting configuration gbean org.apache.geronimo.configs/openejb-deployer/1.2-SNAPSHOT/car Cheers Prasad On 6/26/06, Prasad Kashyap <[EMAIL PROTECTED]> wrote: http://www.mail-archive.com/[email protected]/msg25378.html On 6/26/06, Jason Dillon <[EMAIL PROTECTED]> wrote: > What the heck is up with the xmlbeans plugin? > > I keep getting this from the top-level: > > > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Failed to resolve artifact. > > Missing: > -- > 1) xmlbeans:xmlbeans-jsr173-api:jar:2.0-dev > >Try downloading the file manually from the project website. > >Then, install it using the command: >mvn install:install-file -DgroupId=xmlbeans - > DartifactId=xmlbeans-jsr173-api \ >-Dversion=2.0-dev -Dpackaging=jar -Dfile=/path/to/file > >Path to dependency: > 1) org.apache.geronimo.modules:geronimo-j2ee- builder:jar:1.2- > SNAPSHOT > 2) stax:stax:jar:1.1.1-dev > 3) xmlbeans:xmlbeans-jsr173-api:jar:2.0-dev > > -- > 1 required artifact is missing. > > for artifact: >org.apache.geronimo.modules:geronimo-j2ee-builder:jar:1.2- SNAPSHOT > > from the specified remote repositories: >central (http://repo1.maven.org/maven2), >codehaus-dist (http://dist.codehaus.org), >Apache CVS (http://people.apache.org/maven-snapshot- repository), >maven1-ibiblio (http://www.ibiblio.org/maven), >snapshots (http://snapshots.maven.codehaus.org/maven2), >apache-cvs (http://cvs.apache.org/repository) > > > > > But when I build from the directory it is fine and then the top- level > will continue. Something is horked... not sure why though... > > Where did this jsr plugin come from? > > --jason > > > On Jun 26, 2006, at 1:05 PM, Prasad Kashyap wrote: > > > Alan, > > > > You'd have to build the geronimo-packaging-plugin manually first. It's > > under geronimo/m2-plugins > > > > cd geronimo/m2-plugins > > mvn clean > > mvn -N > > mvn > > > > Cheers > > Prasad > > > > On 6/25/06, Alan D. Cabrera <[EMAIL PROTECTED]> wrote: > >> I get this error: > >> > >> Try downloading the file manually from the project website. > >> > >> Then, install it using the command: > >> mvn install:install-file - DgroupId=org.apache.geronimo.plugins > >> -DartifactId=geronimo-packaging-plugin \ > >> -Dversion=1.2.0 -Dpackaging=maven-plugin -Dfile=/ path/to/file > >> > >> > >> org.apache.geronimo.plugins:geronimo-packaging-plugin:maven- > >> plugin:1.2.0 > >> > >> from the specified remote repositories: > >> central (http://repo1.maven.org/maven2), > >> codehaus-dist (http://dist.codehaus.org/mojo/m2-snapshots), > >> snapshots (http://snapshots.maven.codehaus.org/maven2) > >> > >> org.apache.geronimo.plugins:geronimo-packaging-plugin:
Re: Unable to build using m2
On Jun 26, 2006, at 8:41 PM, Jason Dillon wrote: Probably... But is it really needed to build the sever? yes, how else would it have ejb support? Obviously openejb is not required to build anything in "modules" as the build is supposed to proceed specs modules m2-plugins openejb apps configs assembly I haven't tried a top level build, maybe there are some bugs in it. Maybe after jason's proposed splitting of modules into smaller more focussed pieces we can release some kind of core geronimo jars and they will be stable enough so it is plausible to release openejb on a separate schedule. Maybe openejb3 won't use any geronimo classes and we'll have an openejb integration in geronimo. These are giant changes far larger than the m2 conversion. Until we do something along those lines, I don't understand why we'd assure that no builds ever worked by taking openejb out of the build. thanks david jencks --jason On Jun 26, 2006, at 8:33 PM, Prasad Kashyap wrote: Maybe 'coz we built it with "new2" before ? Not sure. Cheers Prasad On 6/26/06, Jason Dillon <[EMAIL PROTECTED]> wrote: Why is openejb included in "our" build at all? --jason On Jun 26, 2006, at 8:25 PM, Prasad Kashyap wrote: > These are the problems I encountered, encountering. > > openejb: > > 1. openejb/modules/pom.xml specified dependency on > tranql-1.3-SNAPSHOT. That version of tranql doesn'tr exist. Think it > should use 1.4-SNAPSHOT. It should also add dist.codehaus.org into > it's > > 2. openejb/modules/pom.xml specified dependency on > geronimo-spec:geronimo-spec-corba:1.0-SNAPSHOT which again doesn't > exist. It should specify version 2.3-rc4. > > 3. openejb/modules/pom.xml specified dependency on > org.codehaus.org:xmlbeans-maven-plugin:2.0.3-SNAPSHOT. Don't know > where that version is deployed. Maybe that will fix the > xmlbeans:xmlbeans-jsr173-api:jar:2.0-dev exclusion. If only we can > find that repo. Changed it 2.0 and built it successfully. > > 4. unable to build configs/openejb-deployer. > Caused by: org.apache.geronimo.kernel.config.InvalidConfigException: > Error starting configuration gbean > org.apache.geronimo.configs/openejb-deployer/1.2-SNAPSHOT/car > > Cheers > Prasad > > On 6/26/06, Prasad Kashyap <[EMAIL PROTECTED]> wrote: >> http://www.mail-archive.com/[email protected]/msg25378.html >> >> On 6/26/06, Jason Dillon <[EMAIL PROTECTED]> wrote: >> > What the heck is up with the xmlbeans plugin? >> > >> > I keep getting this from the top-level: >> > >> > >> > [INFO] >> > >> - >> --- >> > [ERROR] BUILD ERROR >> > [INFO] >> > >> - >> --- >> > [INFO] Failed to resolve artifact. >> > >> > Missing: >> > -- >> > 1) xmlbeans:xmlbeans-jsr173-api:jar:2.0-dev >> > >> >Try downloading the file manually from the project website. >> > >> >Then, install it using the command: >> >mvn install:install-file -DgroupId=xmlbeans - >> > DartifactId=xmlbeans-jsr173-api \ >> >-Dversion=2.0-dev -Dpackaging=jar -Dfile=/path/to/ file >> > >> >Path to dependency: >> > 1) org.apache.geronimo.modules:geronimo-j2ee- >> builder:jar:1.2- >> > SNAPSHOT >> > 2) stax:stax:jar:1.1.1-dev >> > 3) xmlbeans:xmlbeans-jsr173-api:jar:2.0-dev >> > >> > -- >> > 1 required artifact is missing. >> > >> > for artifact: >> >org.apache.geronimo.modules:geronimo-j2ee-builder:jar:1.2- >> SNAPSHOT >> > >> > from the specified remote repositories: >> >central (http://repo1.maven.org/maven2), >> >codehaus-dist (http://dist.codehaus.org), >> >Apache CVS (http://people.apache.org/maven-snapshot- repository), >> >maven1-ibiblio (http://www.ibiblio.org/maven), >> >snapshots (http://snapshots.maven.codehaus.org/maven2), >> >apache-cvs (http://cvs.apache.org/repository) >> > >> > >> > >> > >> > But when I build from the directory it is fine and then the top- >> level >> > will continue. Something is horked... not sure why though... >> > >> > Where did this jsr plugin come from? >> > >> > --jason >> > >> > >> > On Jun 26, 2006, at 1:05 PM, Prasad Kashyap wrote: >> > >> > > Alan, >> > > >> > > You'd have to build the geronimo-packaging-plugin manually >> first. It's >> > > under geronimo/m2-plugins >> > > >> > > cd geronimo/m2-plugins >> > > mvn clean >> > > mvn -N >> > > mvn >> > > >> > > Cheers >> > > Prasad >> > > >> > > On 6/25/06, Alan D. Cabrera <[EMAIL PROTECTED]> wrote: >> > >> I get this error: >> > >> >> > >> Try downloading the file manually from the project website. >> > >> >> > >> Then, install it using the command: >> > >> mvn install:install-file - >> DgroupId=org.apache.geronimo.plugins >> > >> -DartifactId=geronimo-packaging-plugin \ >> > >> -Dversion=1.2.0 -Dpackaging=maven-plugin -Dfile=/ path/ >> to/file >> > >> >> > >> >> > >> o
Re: Unable to build using m2
On Jun 26, 2006, at 9:17 PM, Alan D. Cabrera wrote: It's clear to me that we need to break out our plugins build and get the plugins published ASAP. I asked this in another thread, what will it take to get this published? I don't think that it's too much trouble, just an RTC to break the plugin out and then we just start publishing the snapshots. We can shoot for a plugin release around the time of G v1.2.0> This is totally not clear to me. All our plugins are going to depend heavily on geronimo code, why would we try to publish them separately or before the artifacts they depend on are published? Since we ditched the dependency plugin for the m2 build all the plugins can be built after all the modules. I really fail to see any problem in this and dont see how publishing the plugins now could cause anything but total build breakage. thanks david jencks Regards, Alan Jason Dillon wrote: 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. --jason On Jun 26, 2006, at 1:05 PM, Prasad Kashyap wrote: Alan, You'd have to build the geronimo-packaging-plugin manually first. It's under geronimo/m2-plugins cd geronimo/m2-plugins mvn clean mvn -N mvn Cheers Prasad On 6/25/06, Alan D. Cabrera <[EMAIL PROTECTED]> wrote: I get this error: Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.geronimo.plugins -DartifactId=geronimo-packaging-plugin \ -Dversion=1.2.0 -Dpackaging=maven-plugin -Dfile=/path/to/ file org.apache.geronimo.plugins:geronimo-packaging-plugin:maven- plugin:1.2.0 from the specified remote repositories: central (http://repo1.maven.org/maven2), codehaus-dist (http://dist.codehaus.org/mojo/m2-snapshots), snapshots (http://snapshots.maven.codehaus.org/maven2) org.apache.geronimo.plugins:geronimo-packaging-plugin:maven- plugin:1.2.0 from the specified remote repositories: central (http://repo1.maven.org/maven2), codehaus-dist (http://dist.codehaus.org/mojo/m2-snapshots), snapshots (http://snapshots.maven.codehaus.org/maven2) Regards, Alan
Re: Unable to build using m2
Alan, When Jacek was coordinating the m2 build, the snapshots were continuously published. Any missing geronimo jar or pom was available from the repo. The same must be done for the plugin. I am not sure how this was done. I think he had the karma to push the jars to the repo. For now it will be enough to publish the plugin(s) and change the version to SNAPSHOT as suggested by Jason. Is an RTC required? Thanks Anita --- "Alan D. Cabrera" <[EMAIL PROTECTED]> wrote: > It's clear to me that we need to break out our plugins build and get > the > plugins published ASAP. I asked this in another thread, what will it > > take to get this published? I don't think that it's too much > trouble, > just an RTC to break the plugin out and then we just start publishing > > the snapshots. We can shoot for a plugin release around the time of > G > v1.2.0> > > > Regards, > Alan > > Jason Dillon wrote: > > 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. > > > > --jason > > > > > > On Jun 26, 2006, at 1:05 PM, Prasad Kashyap wrote: > > > >> Alan, > >> > >> You'd have to build the geronimo-packaging-plugin manually first. > It's > >> under geronimo/m2-plugins > >> > >> cd geronimo/m2-plugins > >> mvn clean > >> mvn -N > >> mvn > >> > >> Cheers > >> Prasad > >> > >> On 6/25/06, Alan D. Cabrera <[EMAIL PROTECTED]> wrote: > >>> I get this error: > >>> > >>> Try downloading the file manually from the project website. > >>> > >>> Then, install it using the command: > >>> mvn install:install-file > -DgroupId=org.apache.geronimo.plugins > >>> -DartifactId=geronimo-packaging-plugin \ > >>> -Dversion=1.2.0 -Dpackaging=maven-plugin > -Dfile=/path/to/file > >>> > >>> > >>> > >>> > org.apache.geronimo.plugins:geronimo-packaging-plugin:maven-plugin:1.2.0 > > >>> > >>> > >>> from the specified remote repositories: > >>> central (http://repo1.maven.org/maven2), > >>> codehaus-dist (http://dist.codehaus.org/mojo/m2-snapshots), > >>> snapshots (http://snapshots.maven.codehaus.org/maven2) > >>> > >>> > >>> > org.apache.geronimo.plugins:geronimo-packaging-plugin:maven-plugin:1.2.0 > > >>> > >>> > >>> from the specified remote repositories: > >>> central (http://repo1.maven.org/maven2), > >>> codehaus-dist (http://dist.codehaus.org/mojo/m2-snapshots), > >>> snapshots (http://snapshots.maven.codehaus.org/maven2) > >>> > >>> > >>> > >>> Regards, > >>> Alan > >>> > >>> > >>> > > > > __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Unable to build using m2
Hi Prasad, AFAIKT the m2-plugins depend on the modules/deploy but the modules build depends on the m2-plugins so even though the cycle is not called out it appears to exist. Is anyone able to do a clean build from the top with m2? Thanks, Bill Dudney MyFaces - http://myfaces.apache.org Cayenne - http://incubator.apache.org/projects/cayenne.html On Jun 26, 2006, at 7:46 PM, Prasad Kashyap wrote: I'm sorry but I'm confused about this main build and the plugins build. I thought they are all one single build like we did in m1 with all the new(xx). This is how the build order is specified in the geronimo/pom.xml modules m2-plugins applications openejb/modules configs assemblies There's no cyclical dependency there. Jason, as for the , I tried that. It didn't help. Also, the default value of is ../pom.xml anyways. Cheers Prasad On 6/26/06, Jason Dillon <[EMAIL PROTECTED]> wrote: FYI, seems that you need to build trunk first (probably until it fails with a missing plugin), then build the plugins, then rebuild trunk. Just building m2-plugins pukes with: [INFO] - --- [ERROR] BUILD ERROR [INFO] - --- [INFO] Failed to resolve artifact. Missing: -- 1) org.apache.geronimo.modules:geronimo-deploy-tool:jar:1.2-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.geronimo.modules -DartifactId=geronimo-deploy-tool \ -Dversion=1.2-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/ file Path to dependency: 1) org.apache.geronimo.plugins:geronimo-packaging- plugin:maven-plugin:1.2.0 2) org.apache.geronimo.modules:geronimo-deploy-tool:jar:1.2- SNAPSHOT 2) org.apache.geronimo.modules:geronimo-kernel:jar:1.2-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.geronimo.modules -DartifactId=geronimo-kernel \ -Dversion=1.2-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/ file Path to dependency: 1) org.apache.geronimo.plugins:geronimo-packaging- plugin:maven-plugin:1.2.0 2) org.apache.geronimo.modules:geronimo-kernel:jar:1.2- SNAPSHOT 3) org.apache.geronimo.modules:geronimo-service-builder:jar:1.2- SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.geronimo.modules -DartifactId=geronimo-service-builder \ -Dversion=1.2-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/ file Path to dependency: 1) org.apache.geronimo.plugins:geronimo-packaging- plugin:maven-plugin:1.2.0 2) org.apache.geronimo.modules:geronimo-service-builder:jar: 1.2-SNAPSHOT 4) org.apache.geronimo.modules:geronimo-system:jar:1.2-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.geronimo.modules -DartifactId=geronimo-system \ -Dversion=1.2-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/ file Path to dependency: 1) org.apache.geronimo.plugins:geronimo-packaging- plugin:maven-plugin:1.2.0 2) org.apache.geronimo.modules:geronimo-system:jar:1.2- SNAPSHOT -- 4 required artifacts are missing. for artifact: org.apache.geronimo.plugins:geronimo-packaging-plugin:maven- plugin: 1.2.0 from the specified remote repositories: central (http://repo1.maven.org/maven2), codehaus-dist (http://dist.codehaus.org), Apache CVS (http://people.apache.org/maven-snapshot-repository), maven1-ibiblio (http://www.ibiblio.org/maven), snapshots (http://snapshots.maven.codehaus.org/maven2), apache-cvs (http://cvs.apache.org/repository) Looks like bad news... if the main build needs the plugin, and the plugin needs the main build, and m2 won't let it all run/build at the same time due to its plugin resolution fluff. May need to provide a bootstrap, which builds a few select modules, then the entire system... but that is not very friendly either. * * * Also, start adding ../pom.xml to the parent element, so that you can skip the mvn -N install bits. --jason On Jun 26, 2006, at 1:05 PM, Prasad Kashyap wrote: > Alan, > > You'd have to build the geronimo-packaging-plugin manually first. It's > under geronimo/m2-plugins > > cd geronimo/m2-plugins > mvn clean > mvn -N > mvn > > Cheers > Prasad > > On 6/25/06, Alan D. Cabrera <[EMAIL PROTECTED]> wrote: >> I get this error: >> >> Try downloading the file manually from the project website. >> >> Then, install it using the command: >> mvn install:install-file -DgroupId=org.apache.geronimo.plugins >> -DartifactId=geronimo-packaging-plugin
Re: Unable to build using m2
Jason Dillon wrote: Why does it fail the first time? This seems fishy too... I'm rebuild again to see what it does, but that is painfully slow... If we really do depend on a development version of the plugin, then we should either... Lobby to get the plugin released or Checkin and manage our own version of that plugin The later is not ideal, but in an open-source world that we live in, sometimes that is the only option as we need stability and can not always rely on other groups to provide that for us. * * * Also, on a side note, we should explicitly list the versions of maven and mojo plugins that we use. I have run into problems many many times when these teams release new versions of the plugins which effectively break the build. It is _nice_ that Maven can download the latest and greatest release of artifacts... but since those latest versions might behave differently that the project is configured to use... it will just end up breaking things. So, don't buy into the "magic" be explicit and tell Maven what version to use. Seems sensible to me to be explicit as it would also increase the likelihood that builds are repeatable years down the track. John --jason On Jun 26, 2006, at 8:13 PM, Prasad Kashyap wrote: http://www.mail-archive.com/[email protected]/msg25378.html On 6/26/06, Jason Dillon <[EMAIL PROTECTED]> wrote: What the heck is up with the xmlbeans plugin? I keep getting this from the top-level: [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Missing: -- 1) xmlbeans:xmlbeans-jsr173-api:jar:2.0-dev Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=xmlbeans - DartifactId=xmlbeans-jsr173-api \ -Dversion=2.0-dev -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.geronimo.modules:geronimo-j2ee-builder:jar:1.2- SNAPSHOT 2) stax:stax:jar:1.1.1-dev 3) xmlbeans:xmlbeans-jsr173-api:jar:2.0-dev -- 1 required artifact is missing. for artifact: org.apache.geronimo.modules:geronimo-j2ee-builder:jar:1.2-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2), codehaus-dist (http://dist.codehaus.org), Apache CVS (http://people.apache.org/maven-snapshot-repository), maven1-ibiblio (http://www.ibiblio.org/maven), snapshots (http://snapshots.maven.codehaus.org/maven2), apache-cvs (http://cvs.apache.org/repository) But when I build from the directory it is fine and then the top-level will continue. Something is horked... not sure why though... Where did this jsr plugin come from? --jason On Jun 26, 2006, at 1:05 PM, Prasad Kashyap wrote: > Alan, > > You'd have to build the geronimo-packaging-plugin manually first. It's > under geronimo/m2-plugins > > cd geronimo/m2-plugins > mvn clean > mvn -N > mvn > > Cheers > Prasad > > On 6/25/06, Alan D. Cabrera <[EMAIL PROTECTED]> wrote: >> I get this error: >> >> Try downloading the file manually from the project website. >> >> Then, install it using the command: >> mvn install:install-file -DgroupId=org.apache.geronimo.plugins >> -DartifactId=geronimo-packaging-plugin \ >> -Dversion=1.2.0 -Dpackaging=maven-plugin -Dfile=/path/to/file >> >> >> org.apache.geronimo.plugins:geronimo-packaging-plugin:maven- >> plugin:1.2.0 >> >> from the specified remote repositories: >> central (http://repo1.maven.org/maven2), >> codehaus-dist (http://dist.codehaus.org/mojo/m2-snapshots), >> snapshots (http://snapshots.maven.codehaus.org/maven2) >> >> org.apache.geronimo.plugins:geronimo-packaging-plugin:maven- >> plugin:1.2.0 >> >> from the specified remote repositories: >> central (http://repo1.maven.org/maven2), >> codehaus-dist (http://dist.codehaus.org/mojo/m2-snapshots), >> snapshots (http://snapshots.maven.codehaus.org/maven2) >> >> >> >> Regards, >> Alan >> >> >>
Re: Unable to build using m2
FYI.. This may be related to http://issues.apache.org/jira/browse/GERONIMO-2082 John Jason Dillon wrote: Any idea where the stax:stax-api:1.1.1-dev comes from? The root pom states that stax:stax-api:1.0 should be used... but the errors with the xmlbeans plugin all state 1.1.1-dev. --jason On Jun 26, 2006, at 8:25 PM, Prasad Kashyap wrote: These are the problems I encountered, encountering. openejb: 1. openejb/modules/pom.xml specified dependency on tranql-1.3-SNAPSHOT. That version of tranql doesn'tr exist. Think it should use 1.4-SNAPSHOT. It should also add dist.codehaus.org into it's 2. openejb/modules/pom.xml specified dependency on geronimo-spec:geronimo-spec-corba:1.0-SNAPSHOT which again doesn't exist. It should specify version 2.3-rc4. 3. openejb/modules/pom.xml specified dependency on org.codehaus.org:xmlbeans-maven-plugin:2.0.3-SNAPSHOT. Don't know where that version is deployed. Maybe that will fix the xmlbeans:xmlbeans-jsr173-api:jar:2.0-dev exclusion. If only we can find that repo. Changed it 2.0 and built it successfully. 4. unable to build configs/openejb-deployer. Caused by: org.apache.geronimo.kernel.config.InvalidConfigException: Error starting configuration gbean org.apache.geronimo.configs/openejb-deployer/1.2-SNAPSHOT/car Cheers Prasad On 6/26/06, Prasad Kashyap <[EMAIL PROTECTED]> wrote: http://www.mail-archive.com/[email protected]/msg25378.html On 6/26/06, Jason Dillon <[EMAIL PROTECTED]> wrote: > What the heck is up with the xmlbeans plugin? > > I keep getting this from the top-level: > > > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Failed to resolve artifact. > > Missing: > -- > 1) xmlbeans:xmlbeans-jsr173-api:jar:2.0-dev > >Try downloading the file manually from the project website. > >Then, install it using the command: >mvn install:install-file -DgroupId=xmlbeans - > DartifactId=xmlbeans-jsr173-api \ >-Dversion=2.0-dev -Dpackaging=jar -Dfile=/path/to/file > >Path to dependency: > 1) org.apache.geronimo.modules:geronimo-j2ee-builder:jar:1.2- > SNAPSHOT > 2) stax:stax:jar:1.1.1-dev > 3) xmlbeans:xmlbeans-jsr173-api:jar:2.0-dev > > -- > 1 required artifact is missing. > > for artifact: >org.apache.geronimo.modules:geronimo-j2ee-builder:jar:1.2-SNAPSHOT > > from the specified remote repositories: >central (http://repo1.maven.org/maven2), >codehaus-dist (http://dist.codehaus.org), >Apache CVS (http://people.apache.org/maven-snapshot-repository), >maven1-ibiblio (http://www.ibiblio.org/maven), >snapshots (http://snapshots.maven.codehaus.org/maven2), >apache-cvs (http://cvs.apache.org/repository) > > > > > But when I build from the directory it is fine and then the top-level > will continue. Something is horked... not sure why though... > > Where did this jsr plugin come from? > > --jason > > > On Jun 26, 2006, at 1:05 PM, Prasad Kashyap wrote: > > > Alan, > > > > You'd have to build the geronimo-packaging-plugin manually first. It's > > under geronimo/m2-plugins > > > > cd geronimo/m2-plugins > > mvn clean > > mvn -N > > mvn > > > > Cheers > > Prasad > > > > On 6/25/06, Alan D. Cabrera <[EMAIL PROTECTED]> wrote: > >> I get this error: > >> > >> Try downloading the file manually from the project website. > >> > >> Then, install it using the command: > >> mvn install:install-file -DgroupId=org.apache.geronimo.plugins > >> -DartifactId=geronimo-packaging-plugin \ > >> -Dversion=1.2.0 -Dpackaging=maven-plugin -Dfile=/path/to/file > >> > >> > >> org.apache.geronimo.plugins:geronimo-packaging-plugin:maven- > >> plugin:1.2.0 > >> > >> from the specified remote repositories: > >> central (http://repo1.maven.org/maven2), > >> codehaus-dist (http://dist.codehaus.org/mojo/m2-snapshots), > >> snapshots (http://snapshots.maven.codehaus.org/maven2) > >> > >> org.apache.geronimo.plugins:geronimo-packaging-plugin:maven- > >> plugin:1.2.0 > >> > >> from the specified remote repositories: > >> central (http://repo1.maven.org/maven2), > >> codehaus-dist (http://dist.codehaus.org/mojo/m2-snapshots), > >> snapshots (http://snapshots.maven.codehaus.org/maven2) > >> > >> > >> > >> Regards, > >> Alan > >> > >> > >> > >
Re: Unable to build using m2
OMG, this xmlbeans plugin is really whacked... need to fix that. Sucks, that you have to do this to build: while true; do mvn install done Anyone know any details about this 2.0-dev xmlbeans plugin? --jason On Jun 26, 2006, at 8:13 PM, Prasad Kashyap wrote: http://www.mail-archive.com/[email protected]/msg25378.html On 6/26/06, Jason Dillon <[EMAIL PROTECTED]> wrote: What the heck is up with the xmlbeans plugin? I keep getting this from the top-level: [INFO] - --- [ERROR] BUILD ERROR [INFO] - --- [INFO] Failed to resolve artifact. Missing: -- 1) xmlbeans:xmlbeans-jsr173-api:jar:2.0-dev Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=xmlbeans - DartifactId=xmlbeans-jsr173-api \ -Dversion=2.0-dev -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.geronimo.modules:geronimo-j2ee-builder:jar: 1.2- SNAPSHOT 2) stax:stax:jar:1.1.1-dev 3) xmlbeans:xmlbeans-jsr173-api:jar:2.0-dev -- 1 required artifact is missing. for artifact: org.apache.geronimo.modules:geronimo-j2ee-builder:jar:1.2-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2), codehaus-dist (http://dist.codehaus.org), Apache CVS (http://people.apache.org/maven-snapshot-repository), maven1-ibiblio (http://www.ibiblio.org/maven), snapshots (http://snapshots.maven.codehaus.org/maven2), apache-cvs (http://cvs.apache.org/repository) But when I build from the directory it is fine and then the top-level will continue. Something is horked... not sure why though... Where did this jsr plugin come from? --jason On Jun 26, 2006, at 1:05 PM, Prasad Kashyap wrote: > Alan, > > You'd have to build the geronimo-packaging-plugin manually first. It's > under geronimo/m2-plugins > > cd geronimo/m2-plugins > mvn clean > mvn -N > mvn > > Cheers > Prasad > > On 6/25/06, Alan D. Cabrera <[EMAIL PROTECTED]> wrote: >> I get this error: >> >> Try downloading the file manually from the project website. >> >> Then, install it using the command: >> mvn install:install-file -DgroupId=org.apache.geronimo.plugins >> -DartifactId=geronimo-packaging-plugin \ >> -Dversion=1.2.0 -Dpackaging=maven-plugin -Dfile=/path/ to/file >> >> >> org.apache.geronimo.plugins:geronimo-packaging-plugin:maven- >> plugin:1.2.0 >> >> from the specified remote repositories: >> central (http://repo1.maven.org/maven2), >> codehaus-dist (http://dist.codehaus.org/mojo/m2-snapshots), >> snapshots (http://snapshots.maven.codehaus.org/maven2) >> >> org.apache.geronimo.plugins:geronimo-packaging-plugin:maven- >> plugin:1.2.0 >> >> from the specified remote repositories: >> central (http://repo1.maven.org/maven2), >> codehaus-dist (http://dist.codehaus.org/mojo/m2-snapshots), >> snapshots (http://snapshots.maven.codehaus.org/maven2) >> >> >> >> Regards, >> Alan >> >> >>
Re: Unable to build using m2
Are there *any good reasons* why it should be in the build? If not... then lets remove it. --jason On Jun 26, 2006, at 9:13 PM, Alan D. Cabrera wrote: IMO, it should not be in our build at all. Regards, Alan Jason Dillon wrote: Why is openejb included in "our" build at all? --jason On Jun 26, 2006, at 8:25 PM, Prasad Kashyap wrote: These are the problems I encountered, encountering. openejb: 1. openejb/modules/pom.xml specified dependency on tranql-1.3-SNAPSHOT. That version of tranql doesn'tr exist. Think it should use 1.4-SNAPSHOT. It should also add dist.codehaus.org into it's 2. openejb/modules/pom.xml specified dependency on geronimo-spec:geronimo-spec-corba:1.0-SNAPSHOT which again doesn't exist. It should specify version 2.3-rc4. 3. openejb/modules/pom.xml specified dependency on org.codehaus.org:xmlbeans-maven-plugin:2.0.3-SNAPSHOT. Don't know where that version is deployed. Maybe that will fix the xmlbeans:xmlbeans-jsr173-api:jar:2.0-dev exclusion. If only we can find that repo. Changed it 2.0 and built it successfully. 4. unable to build configs/openejb-deployer. Caused by: org.apache.geronimo.kernel.config.InvalidConfigException: Error starting configuration gbean org.apache.geronimo.configs/openejb-deployer/1.2-SNAPSHOT/car Cheers Prasad On 6/26/06, Prasad Kashyap <[EMAIL PROTECTED]> wrote: http://www.mail-archive.com/[email protected]/msg25378.html On 6/26/06, Jason Dillon <[EMAIL PROTECTED]> wrote: > What the heck is up with the xmlbeans plugin? > > I keep getting this from the top-level: > > > [INFO] > --- - > [ERROR] BUILD ERROR > [INFO] > --- - > [INFO] Failed to resolve artifact. > > Missing: > -- > 1) xmlbeans:xmlbeans-jsr173-api:jar:2.0-dev > >Try downloading the file manually from the project website. > >Then, install it using the command: >mvn install:install-file -DgroupId=xmlbeans - > DartifactId=xmlbeans-jsr173-api \ >-Dversion=2.0-dev -Dpackaging=jar -Dfile=/path/to/file > >Path to dependency: > 1) org.apache.geronimo.modules:geronimo-j2ee- builder:jar:1.2- > SNAPSHOT > 2) stax:stax:jar:1.1.1-dev > 3) xmlbeans:xmlbeans-jsr173-api:jar:2.0-dev > > -- > 1 required artifact is missing. > > for artifact: >org.apache.geronimo.modules:geronimo-j2ee-builder:jar:1.2- SNAPSHOT > > from the specified remote repositories: >central (http://repo1.maven.org/maven2), >codehaus-dist (http://dist.codehaus.org), >Apache CVS (http://people.apache.org/maven-snapshot- repository), >maven1-ibiblio (http://www.ibiblio.org/maven), >snapshots (http://snapshots.maven.codehaus.org/maven2), >apache-cvs (http://cvs.apache.org/repository) > > > > > But when I build from the directory it is fine and then the top-level > will continue. Something is horked... not sure why though... > > Where did this jsr plugin come from? > > --jason > > > On Jun 26, 2006, at 1:05 PM, Prasad Kashyap wrote: > > > Alan, > > > > You'd have to build the geronimo-packaging-plugin manually first. It's > > under geronimo/m2-plugins > > > > cd geronimo/m2-plugins > > mvn clean > > mvn -N > > mvn > > > > Cheers > > Prasad > > > > On 6/25/06, Alan D. Cabrera <[EMAIL PROTECTED]> wrote: > >> I get this error: > >> > >> Try downloading the file manually from the project website. > >> > >> Then, install it using the command: > >> mvn install:install-file - DgroupId=org.apache.geronimo.plugins > >> -DartifactId=geronimo-packaging-plugin \ > >> -Dversion=1.2.0 -Dpackaging=maven-plugin -Dfile=/ path/to/file > >> > >> > >> org.apache.geronimo.plugins:geronimo-packaging-plugin:maven- > >> plugin:1.2.0 > >> > >> from the specified remote repositories: > >> central (http://repo1.maven.org/maven2), > >> codehaus-dist (http://dist.codehaus.org/mojo/m2-snapshots), > >> snapshots (http://snapshots.maven.codehaus.org/maven2) > >> > >> org.apache.geronimo.plugins:geronimo-packaging-plugin:maven- > >> plugin:1.2.0 > >> > >> from the specified remote repositories: > >> central (http://repo1.maven.org/maven2), > >> codehaus-dist (http://dist.codehaus.org/mojo/m2-snapshots), > >> snapshots (http://snapshots.maven.codehaus.org/maven2) > >> > >> > >> > >> Regards, > >> Alan > >> > >> > >> > >
Re: Unable to build using m2
It's clear to me that we need to break out our plugins build and get the plugins published ASAP. I asked this in another thread, what will it take to get this published? I don't think that it's too much trouble, just an RTC to break the plugin out and then we just start publishing the snapshots. We can shoot for a plugin release around the time of G v1.2.0> Regards, Alan Jason Dillon wrote: 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. --jason On Jun 26, 2006, at 1:05 PM, Prasad Kashyap wrote: Alan, You'd have to build the geronimo-packaging-plugin manually first. It's under geronimo/m2-plugins cd geronimo/m2-plugins mvn clean mvn -N mvn Cheers Prasad On 6/25/06, Alan D. Cabrera <[EMAIL PROTECTED]> wrote: I get this error: Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.geronimo.plugins -DartifactId=geronimo-packaging-plugin \ -Dversion=1.2.0 -Dpackaging=maven-plugin -Dfile=/path/to/file org.apache.geronimo.plugins:geronimo-packaging-plugin:maven-plugin:1.2.0 from the specified remote repositories: central (http://repo1.maven.org/maven2), codehaus-dist (http://dist.codehaus.org/mojo/m2-snapshots), snapshots (http://snapshots.maven.codehaus.org/maven2) org.apache.geronimo.plugins:geronimo-packaging-plugin:maven-plugin:1.2.0 from the specified remote repositories: central (http://repo1.maven.org/maven2), codehaus-dist (http://dist.codehaus.org/mojo/m2-snapshots), snapshots (http://snapshots.maven.codehaus.org/maven2) Regards, Alan
Re: Unable to build using m2
IMO, it should not be in our build at all. Regards, Alan Jason Dillon wrote: Why is openejb included in "our" build at all? --jason On Jun 26, 2006, at 8:25 PM, Prasad Kashyap wrote: These are the problems I encountered, encountering. openejb: 1. openejb/modules/pom.xml specified dependency on tranql-1.3-SNAPSHOT. That version of tranql doesn'tr exist. Think it should use 1.4-SNAPSHOT. It should also add dist.codehaus.org into it's 2. openejb/modules/pom.xml specified dependency on geronimo-spec:geronimo-spec-corba:1.0-SNAPSHOT which again doesn't exist. It should specify version 2.3-rc4. 3. openejb/modules/pom.xml specified dependency on org.codehaus.org:xmlbeans-maven-plugin:2.0.3-SNAPSHOT. Don't know where that version is deployed. Maybe that will fix the xmlbeans:xmlbeans-jsr173-api:jar:2.0-dev exclusion. If only we can find that repo. Changed it 2.0 and built it successfully. 4. unable to build configs/openejb-deployer. Caused by: org.apache.geronimo.kernel.config.InvalidConfigException: Error starting configuration gbean org.apache.geronimo.configs/openejb-deployer/1.2-SNAPSHOT/car Cheers Prasad On 6/26/06, Prasad Kashyap <[EMAIL PROTECTED]> wrote: http://www.mail-archive.com/[email protected]/msg25378.html On 6/26/06, Jason Dillon <[EMAIL PROTECTED]> wrote: > What the heck is up with the xmlbeans plugin? > > I keep getting this from the top-level: > > > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Failed to resolve artifact. > > Missing: > -- > 1) xmlbeans:xmlbeans-jsr173-api:jar:2.0-dev > >Try downloading the file manually from the project website. > >Then, install it using the command: >mvn install:install-file -DgroupId=xmlbeans - > DartifactId=xmlbeans-jsr173-api \ >-Dversion=2.0-dev -Dpackaging=jar -Dfile=/path/to/file > >Path to dependency: > 1) org.apache.geronimo.modules:geronimo-j2ee-builder:jar:1.2- > SNAPSHOT > 2) stax:stax:jar:1.1.1-dev > 3) xmlbeans:xmlbeans-jsr173-api:jar:2.0-dev > > -- > 1 required artifact is missing. > > for artifact: >org.apache.geronimo.modules:geronimo-j2ee-builder:jar:1.2-SNAPSHOT > > from the specified remote repositories: >central (http://repo1.maven.org/maven2), >codehaus-dist (http://dist.codehaus.org), >Apache CVS (http://people.apache.org/maven-snapshot-repository), >maven1-ibiblio (http://www.ibiblio.org/maven), >snapshots (http://snapshots.maven.codehaus.org/maven2), >apache-cvs (http://cvs.apache.org/repository) > > > > > But when I build from the directory it is fine and then the top-level > will continue. Something is horked... not sure why though... > > Where did this jsr plugin come from? > > --jason > > > On Jun 26, 2006, at 1:05 PM, Prasad Kashyap wrote: > > > Alan, > > > > You'd have to build the geronimo-packaging-plugin manually first. It's > > under geronimo/m2-plugins > > > > cd geronimo/m2-plugins > > mvn clean > > mvn -N > > mvn > > > > Cheers > > Prasad > > > > On 6/25/06, Alan D. Cabrera <[EMAIL PROTECTED]> wrote: > >> I get this error: > >> > >> Try downloading the file manually from the project website. > >> > >> Then, install it using the command: > >> mvn install:install-file -DgroupId=org.apache.geronimo.plugins > >> -DartifactId=geronimo-packaging-plugin \ > >> -Dversion=1.2.0 -Dpackaging=maven-plugin -Dfile=/path/to/file > >> > >> > >> org.apache.geronimo.plugins:geronimo-packaging-plugin:maven- > >> plugin:1.2.0 > >> > >> from the specified remote repositories: > >> central (http://repo1.maven.org/maven2), > >> codehaus-dist (http://dist.codehaus.org/mojo/m2-snapshots), > >> snapshots (http://snapshots.maven.codehaus.org/maven2) > >> > >> org.apache.geronimo.plugins:geronimo-packaging-plugin:maven- > >> plugin:1.2.0 > >> > >> from the specified remote repositories: > >> central (http://repo1.maven.org/maven2), > >> codehaus-dist (http://dist.codehaus.org/mojo/m2-snapshots), > >> snapshots (http://snapshots.maven.codehaus.org/maven2) > >> > >> > >> > >> Regards, > >> Alan > >> > >> > >> > >
Re: Unable to build using m2
Probably... But is it really needed to build the sever? --jason On Jun 26, 2006, at 8:33 PM, Prasad Kashyap wrote: Maybe 'coz we built it with "new2" before ? Not sure. Cheers Prasad On 6/26/06, Jason Dillon <[EMAIL PROTECTED]> wrote: Why is openejb included in "our" build at all? --jason On Jun 26, 2006, at 8:25 PM, Prasad Kashyap wrote: > These are the problems I encountered, encountering. > > openejb: > > 1. openejb/modules/pom.xml specified dependency on > tranql-1.3-SNAPSHOT. That version of tranql doesn'tr exist. Think it > should use 1.4-SNAPSHOT. It should also add dist.codehaus.org into > it's > > 2. openejb/modules/pom.xml specified dependency on > geronimo-spec:geronimo-spec-corba:1.0-SNAPSHOT which again doesn't > exist. It should specify version 2.3-rc4. > > 3. openejb/modules/pom.xml specified dependency on > org.codehaus.org:xmlbeans-maven-plugin:2.0.3-SNAPSHOT. Don't know > where that version is deployed. Maybe that will fix the > xmlbeans:xmlbeans-jsr173-api:jar:2.0-dev exclusion. If only we can > find that repo. Changed it 2.0 and built it successfully. > > 4. unable to build configs/openejb-deployer. > Caused by: org.apache.geronimo.kernel.config.InvalidConfigException: > Error starting configuration gbean > org.apache.geronimo.configs/openejb-deployer/1.2-SNAPSHOT/car > > Cheers > Prasad > > On 6/26/06, Prasad Kashyap <[EMAIL PROTECTED]> wrote: >> http://www.mail-archive.com/[email protected]/msg25378.html >> >> On 6/26/06, Jason Dillon <[EMAIL PROTECTED]> wrote: >> > What the heck is up with the xmlbeans plugin? >> > >> > I keep getting this from the top-level: >> > >> > >> > [INFO] >> > >> - >> --- >> > [ERROR] BUILD ERROR >> > [INFO] >> > >> - >> --- >> > [INFO] Failed to resolve artifact. >> > >> > Missing: >> > -- >> > 1) xmlbeans:xmlbeans-jsr173-api:jar:2.0-dev >> > >> >Try downloading the file manually from the project website. >> > >> >Then, install it using the command: >> >mvn install:install-file -DgroupId=xmlbeans - >> > DartifactId=xmlbeans-jsr173-api \ >> >-Dversion=2.0-dev -Dpackaging=jar -Dfile=/path/to/ file >> > >> >Path to dependency: >> > 1) org.apache.geronimo.modules:geronimo-j2ee- >> builder:jar:1.2- >> > SNAPSHOT >> > 2) stax:stax:jar:1.1.1-dev >> > 3) xmlbeans:xmlbeans-jsr173-api:jar:2.0-dev >> > >> > -- >> > 1 required artifact is missing. >> > >> > for artifact: >> >org.apache.geronimo.modules:geronimo-j2ee-builder:jar:1.2- >> SNAPSHOT >> > >> > from the specified remote repositories: >> >central (http://repo1.maven.org/maven2), >> >codehaus-dist (http://dist.codehaus.org), >> >Apache CVS (http://people.apache.org/maven-snapshot- repository), >> >maven1-ibiblio (http://www.ibiblio.org/maven), >> >snapshots (http://snapshots.maven.codehaus.org/maven2), >> >apache-cvs (http://cvs.apache.org/repository) >> > >> > >> > >> > >> > But when I build from the directory it is fine and then the top- >> level >> > will continue. Something is horked... not sure why though... >> > >> > Where did this jsr plugin come from? >> > >> > --jason >> > >> > >> > On Jun 26, 2006, at 1:05 PM, Prasad Kashyap wrote: >> > >> > > Alan, >> > > >> > > You'd have to build the geronimo-packaging-plugin manually >> first. It's >> > > under geronimo/m2-plugins >> > > >> > > cd geronimo/m2-plugins >> > > mvn clean >> > > mvn -N >> > > mvn >> > > >> > > Cheers >> > > Prasad >> > > >> > > On 6/25/06, Alan D. Cabrera <[EMAIL PROTECTED]> wrote: >> > >> I get this error: >> > >> >> > >> Try downloading the file manually from the project website. >> > >> >> > >> Then, install it using the command: >> > >> mvn install:install-file - >> DgroupId=org.apache.geronimo.plugins >> > >> -DartifactId=geronimo-packaging-plugin \ >> > >> -Dversion=1.2.0 -Dpackaging=maven-plugin -Dfile=/ path/ >> to/file >> > >> >> > >> >> > >> org.apache.geronimo.plugins:geronimo-packaging- plugin:maven- >> > >> plugin:1.2.0 >> > >> >> > >> from the specified remote repositories: >> > >> central (http://repo1.maven.org/maven2), >> > >> codehaus-dist (http://dist.codehaus.org/mojo/m2-snapshots), >> > >> snapshots (http://snapshots.maven.codehaus.org/maven2) >> > >> >> > >> org.apache.geronimo.plugins:geronimo-packaging- plugin:maven- >> > >> plugin:1.2.0 >> > >> >> > >> from the specified remote repositories: >> > >> central (http://repo1.maven.org/maven2), >> > >> codehaus-dist (http://dist.codehaus.org/mojo/m2-snapshots), >> > >> snapshots (http://snapshots.maven.codehaus.org/maven2) >> > >> >> > >> >> > >> >> > >> Regards, >> > >> Alan >> > >> >> > >> >> > >> >> > >> > >>
Re: Unable to build using m2
Any idea where the stax:stax-api:1.1.1-dev comes from? The root pom states that stax:stax-api:1.0 should be used... but the errors with the xmlbeans plugin all state 1.1.1-dev. --jason On Jun 26, 2006, at 8:25 PM, Prasad Kashyap wrote: These are the problems I encountered, encountering. openejb: 1. openejb/modules/pom.xml specified dependency on tranql-1.3-SNAPSHOT. That version of tranql doesn'tr exist. Think it should use 1.4-SNAPSHOT. It should also add dist.codehaus.org into it's 2. openejb/modules/pom.xml specified dependency on geronimo-spec:geronimo-spec-corba:1.0-SNAPSHOT which again doesn't exist. It should specify version 2.3-rc4. 3. openejb/modules/pom.xml specified dependency on org.codehaus.org:xmlbeans-maven-plugin:2.0.3-SNAPSHOT. Don't know where that version is deployed. Maybe that will fix the xmlbeans:xmlbeans-jsr173-api:jar:2.0-dev exclusion. If only we can find that repo. Changed it 2.0 and built it successfully. 4. unable to build configs/openejb-deployer. Caused by: org.apache.geronimo.kernel.config.InvalidConfigException: Error starting configuration gbean org.apache.geronimo.configs/openejb-deployer/1.2-SNAPSHOT/car Cheers Prasad On 6/26/06, Prasad Kashyap <[EMAIL PROTECTED]> wrote: http://www.mail-archive.com/[email protected]/msg25378.html On 6/26/06, Jason Dillon <[EMAIL PROTECTED]> wrote: > What the heck is up with the xmlbeans plugin? > > I keep getting this from the top-level: > > > [INFO] > - --- > [ERROR] BUILD ERROR > [INFO] > - --- > [INFO] Failed to resolve artifact. > > Missing: > -- > 1) xmlbeans:xmlbeans-jsr173-api:jar:2.0-dev > >Try downloading the file manually from the project website. > >Then, install it using the command: >mvn install:install-file -DgroupId=xmlbeans - > DartifactId=xmlbeans-jsr173-api \ >-Dversion=2.0-dev -Dpackaging=jar -Dfile=/path/to/file > >Path to dependency: > 1) org.apache.geronimo.modules:geronimo-j2ee- builder:jar:1.2- > SNAPSHOT > 2) stax:stax:jar:1.1.1-dev > 3) xmlbeans:xmlbeans-jsr173-api:jar:2.0-dev > > -- > 1 required artifact is missing. > > for artifact: >org.apache.geronimo.modules:geronimo-j2ee-builder:jar:1.2- SNAPSHOT > > from the specified remote repositories: >central (http://repo1.maven.org/maven2), >codehaus-dist (http://dist.codehaus.org), >Apache CVS (http://people.apache.org/maven-snapshot-repository), >maven1-ibiblio (http://www.ibiblio.org/maven), >snapshots (http://snapshots.maven.codehaus.org/maven2), >apache-cvs (http://cvs.apache.org/repository) > > > > > But when I build from the directory it is fine and then the top- level > will continue. Something is horked... not sure why though... > > Where did this jsr plugin come from? > > --jason > > > On Jun 26, 2006, at 1:05 PM, Prasad Kashyap wrote: > > > Alan, > > > > You'd have to build the geronimo-packaging-plugin manually first. It's > > under geronimo/m2-plugins > > > > cd geronimo/m2-plugins > > mvn clean > > mvn -N > > mvn > > > > Cheers > > Prasad > > > > On 6/25/06, Alan D. Cabrera <[EMAIL PROTECTED]> wrote: > >> I get this error: > >> > >> Try downloading the file manually from the project website. > >> > >> Then, install it using the command: > >> mvn install:install-file - DgroupId=org.apache.geronimo.plugins > >> -DartifactId=geronimo-packaging-plugin \ > >> -Dversion=1.2.0 -Dpackaging=maven-plugin -Dfile=/path/ to/file > >> > >> > >> org.apache.geronimo.plugins:geronimo-packaging-plugin:maven- > >> plugin:1.2.0 > >> > >> from the specified remote repositories: > >> central (http://repo1.maven.org/maven2), > >> codehaus-dist (http://dist.codehaus.org/mojo/m2-snapshots), > >> snapshots (http://snapshots.maven.codehaus.org/maven2) > >> > >> org.apache.geronimo.plugins:geronimo-packaging-plugin:maven- > >> plugin:1.2.0 > >> > >> from the specified remote repositories: > >> central (http://repo1.maven.org/maven2), > >> codehaus-dist (http://dist.codehaus.org/mojo/m2-snapshots), > >> snapshots (http://snapshots.maven.codehaus.org/maven2) > >> > >> > >> > >> Regards, > >> Alan > >> > >> > >> > >
Re: Unable to build using m2
Maybe 'coz we built it with "new2" before ? Not sure. Cheers Prasad On 6/26/06, Jason Dillon <[EMAIL PROTECTED]> wrote: Why is openejb included in "our" build at all? --jason On Jun 26, 2006, at 8:25 PM, Prasad Kashyap wrote: > These are the problems I encountered, encountering. > > openejb: > > 1. openejb/modules/pom.xml specified dependency on > tranql-1.3-SNAPSHOT. That version of tranql doesn'tr exist. Think it > should use 1.4-SNAPSHOT. It should also add dist.codehaus.org into > it's > > 2. openejb/modules/pom.xml specified dependency on > geronimo-spec:geronimo-spec-corba:1.0-SNAPSHOT which again doesn't > exist. It should specify version 2.3-rc4. > > 3. openejb/modules/pom.xml specified dependency on > org.codehaus.org:xmlbeans-maven-plugin:2.0.3-SNAPSHOT. Don't know > where that version is deployed. Maybe that will fix the > xmlbeans:xmlbeans-jsr173-api:jar:2.0-dev exclusion. If only we can > find that repo. Changed it 2.0 and built it successfully. > > 4. unable to build configs/openejb-deployer. > Caused by: org.apache.geronimo.kernel.config.InvalidConfigException: > Error starting configuration gbean > org.apache.geronimo.configs/openejb-deployer/1.2-SNAPSHOT/car > > Cheers > Prasad > > On 6/26/06, Prasad Kashyap <[EMAIL PROTECTED]> wrote: >> http://www.mail-archive.com/[email protected]/msg25378.html >> >> On 6/26/06, Jason Dillon <[EMAIL PROTECTED]> wrote: >> > What the heck is up with the xmlbeans plugin? >> > >> > I keep getting this from the top-level: >> > >> > >> > [INFO] >> > >> - >> --- >> > [ERROR] BUILD ERROR >> > [INFO] >> > >> - >> --- >> > [INFO] Failed to resolve artifact. >> > >> > Missing: >> > -- >> > 1) xmlbeans:xmlbeans-jsr173-api:jar:2.0-dev >> > >> >Try downloading the file manually from the project website. >> > >> >Then, install it using the command: >> >mvn install:install-file -DgroupId=xmlbeans - >> > DartifactId=xmlbeans-jsr173-api \ >> >-Dversion=2.0-dev -Dpackaging=jar -Dfile=/path/to/file >> > >> >Path to dependency: >> > 1) org.apache.geronimo.modules:geronimo-j2ee- >> builder:jar:1.2- >> > SNAPSHOT >> > 2) stax:stax:jar:1.1.1-dev >> > 3) xmlbeans:xmlbeans-jsr173-api:jar:2.0-dev >> > >> > -- >> > 1 required artifact is missing. >> > >> > for artifact: >> >org.apache.geronimo.modules:geronimo-j2ee-builder:jar:1.2- >> SNAPSHOT >> > >> > from the specified remote repositories: >> >central (http://repo1.maven.org/maven2), >> >codehaus-dist (http://dist.codehaus.org), >> >Apache CVS (http://people.apache.org/maven-snapshot-repository), >> >maven1-ibiblio (http://www.ibiblio.org/maven), >> >snapshots (http://snapshots.maven.codehaus.org/maven2), >> >apache-cvs (http://cvs.apache.org/repository) >> > >> > >> > >> > >> > But when I build from the directory it is fine and then the top- >> level >> > will continue. Something is horked... not sure why though... >> > >> > Where did this jsr plugin come from? >> > >> > --jason >> > >> > >> > On Jun 26, 2006, at 1:05 PM, Prasad Kashyap wrote: >> > >> > > Alan, >> > > >> > > You'd have to build the geronimo-packaging-plugin manually >> first. It's >> > > under geronimo/m2-plugins >> > > >> > > cd geronimo/m2-plugins >> > > mvn clean >> > > mvn -N >> > > mvn >> > > >> > > Cheers >> > > Prasad >> > > >> > > On 6/25/06, Alan D. Cabrera <[EMAIL PROTECTED]> wrote: >> > >> I get this error: >> > >> >> > >> Try downloading the file manually from the project website. >> > >> >> > >> Then, install it using the command: >> > >> mvn install:install-file - >> DgroupId=org.apache.geronimo.plugins >> > >> -DartifactId=geronimo-packaging-plugin \ >> > >> -Dversion=1.2.0 -Dpackaging=maven-plugin -Dfile=/path/ >> to/file >> > >> >> > >> >> > >> org.apache.geronimo.plugins:geronimo-packaging-plugin:maven- >> > >> plugin:1.2.0 >> > >> >> > >> from the specified remote repositories: >> > >> central (http://repo1.maven.org/maven2), >> > >> codehaus-dist (http://dist.codehaus.org/mojo/m2-snapshots), >> > >> snapshots (http://snapshots.maven.codehaus.org/maven2) >> > >> >> > >> org.apache.geronimo.plugins:geronimo-packaging-plugin:maven- >> > >> plugin:1.2.0 >> > >> >> > >> from the specified remote repositories: >> > >> central (http://repo1.maven.org/maven2), >> > >> codehaus-dist (http://dist.codehaus.org/mojo/m2-snapshots), >> > >> snapshots (http://snapshots.maven.codehaus.org/maven2) >> > >> >> > >> >> > >> >> > >> Regards, >> > >> Alan >> > >> >> > >> >> > >> >> > >> > >>
Re: Unable to build using m2
Why is openejb included in "our" build at all? --jason On Jun 26, 2006, at 8:25 PM, Prasad Kashyap wrote: These are the problems I encountered, encountering. openejb: 1. openejb/modules/pom.xml specified dependency on tranql-1.3-SNAPSHOT. That version of tranql doesn'tr exist. Think it should use 1.4-SNAPSHOT. It should also add dist.codehaus.org into it's 2. openejb/modules/pom.xml specified dependency on geronimo-spec:geronimo-spec-corba:1.0-SNAPSHOT which again doesn't exist. It should specify version 2.3-rc4. 3. openejb/modules/pom.xml specified dependency on org.codehaus.org:xmlbeans-maven-plugin:2.0.3-SNAPSHOT. Don't know where that version is deployed. Maybe that will fix the xmlbeans:xmlbeans-jsr173-api:jar:2.0-dev exclusion. If only we can find that repo. Changed it 2.0 and built it successfully. 4. unable to build configs/openejb-deployer. Caused by: org.apache.geronimo.kernel.config.InvalidConfigException: Error starting configuration gbean org.apache.geronimo.configs/openejb-deployer/1.2-SNAPSHOT/car Cheers Prasad On 6/26/06, Prasad Kashyap <[EMAIL PROTECTED]> wrote: http://www.mail-archive.com/[email protected]/msg25378.html On 6/26/06, Jason Dillon <[EMAIL PROTECTED]> wrote: > What the heck is up with the xmlbeans plugin? > > I keep getting this from the top-level: > > > [INFO] > - --- > [ERROR] BUILD ERROR > [INFO] > - --- > [INFO] Failed to resolve artifact. > > Missing: > -- > 1) xmlbeans:xmlbeans-jsr173-api:jar:2.0-dev > >Try downloading the file manually from the project website. > >Then, install it using the command: >mvn install:install-file -DgroupId=xmlbeans - > DartifactId=xmlbeans-jsr173-api \ >-Dversion=2.0-dev -Dpackaging=jar -Dfile=/path/to/file > >Path to dependency: > 1) org.apache.geronimo.modules:geronimo-j2ee- builder:jar:1.2- > SNAPSHOT > 2) stax:stax:jar:1.1.1-dev > 3) xmlbeans:xmlbeans-jsr173-api:jar:2.0-dev > > -- > 1 required artifact is missing. > > for artifact: >org.apache.geronimo.modules:geronimo-j2ee-builder:jar:1.2- SNAPSHOT > > from the specified remote repositories: >central (http://repo1.maven.org/maven2), >codehaus-dist (http://dist.codehaus.org), >Apache CVS (http://people.apache.org/maven-snapshot-repository), >maven1-ibiblio (http://www.ibiblio.org/maven), >snapshots (http://snapshots.maven.codehaus.org/maven2), >apache-cvs (http://cvs.apache.org/repository) > > > > > But when I build from the directory it is fine and then the top- level > will continue. Something is horked... not sure why though... > > Where did this jsr plugin come from? > > --jason > > > On Jun 26, 2006, at 1:05 PM, Prasad Kashyap wrote: > > > Alan, > > > > You'd have to build the geronimo-packaging-plugin manually first. It's > > under geronimo/m2-plugins > > > > cd geronimo/m2-plugins > > mvn clean > > mvn -N > > mvn > > > > Cheers > > Prasad > > > > On 6/25/06, Alan D. Cabrera <[EMAIL PROTECTED]> wrote: > >> I get this error: > >> > >> Try downloading the file manually from the project website. > >> > >> Then, install it using the command: > >> mvn install:install-file - DgroupId=org.apache.geronimo.plugins > >> -DartifactId=geronimo-packaging-plugin \ > >> -Dversion=1.2.0 -Dpackaging=maven-plugin -Dfile=/path/ to/file > >> > >> > >> org.apache.geronimo.plugins:geronimo-packaging-plugin:maven- > >> plugin:1.2.0 > >> > >> from the specified remote repositories: > >> central (http://repo1.maven.org/maven2), > >> codehaus-dist (http://dist.codehaus.org/mojo/m2-snapshots), > >> snapshots (http://snapshots.maven.codehaus.org/maven2) > >> > >> org.apache.geronimo.plugins:geronimo-packaging-plugin:maven- > >> plugin:1.2.0 > >> > >> from the specified remote repositories: > >> central (http://repo1.maven.org/maven2), > >> codehaus-dist (http://dist.codehaus.org/mojo/m2-snapshots), > >> snapshots (http://snapshots.maven.codehaus.org/maven2) > >> > >> > >> > >> Regards, > >> Alan > >> > >> > >> > >
Re: Unable to build using m2
These are the problems I encountered, encountering. openejb: 1. openejb/modules/pom.xml specified dependency on tranql-1.3-SNAPSHOT. That version of tranql doesn'tr exist. Think it should use 1.4-SNAPSHOT. It should also add dist.codehaus.org into it's 2. openejb/modules/pom.xml specified dependency on geronimo-spec:geronimo-spec-corba:1.0-SNAPSHOT which again doesn't exist. It should specify version 2.3-rc4. 3. openejb/modules/pom.xml specified dependency on org.codehaus.org:xmlbeans-maven-plugin:2.0.3-SNAPSHOT. Don't know where that version is deployed. Maybe that will fix the xmlbeans:xmlbeans-jsr173-api:jar:2.0-dev exclusion. If only we can find that repo. Changed it 2.0 and built it successfully. 4. unable to build configs/openejb-deployer. Caused by: org.apache.geronimo.kernel.config.InvalidConfigException: Error starting configuration gbean org.apache.geronimo.configs/openejb-deployer/1.2-SNAPSHOT/car Cheers Prasad On 6/26/06, Prasad Kashyap <[EMAIL PROTECTED]> wrote: http://www.mail-archive.com/[email protected]/msg25378.html On 6/26/06, Jason Dillon <[EMAIL PROTECTED]> wrote: > What the heck is up with the xmlbeans plugin? > > I keep getting this from the top-level: > > > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Failed to resolve artifact. > > Missing: > -- > 1) xmlbeans:xmlbeans-jsr173-api:jar:2.0-dev > >Try downloading the file manually from the project website. > >Then, install it using the command: >mvn install:install-file -DgroupId=xmlbeans - > DartifactId=xmlbeans-jsr173-api \ >-Dversion=2.0-dev -Dpackaging=jar -Dfile=/path/to/file > >Path to dependency: > 1) org.apache.geronimo.modules:geronimo-j2ee-builder:jar:1.2- > SNAPSHOT > 2) stax:stax:jar:1.1.1-dev > 3) xmlbeans:xmlbeans-jsr173-api:jar:2.0-dev > > -- > 1 required artifact is missing. > > for artifact: >org.apache.geronimo.modules:geronimo-j2ee-builder:jar:1.2-SNAPSHOT > > from the specified remote repositories: >central (http://repo1.maven.org/maven2), >codehaus-dist (http://dist.codehaus.org), >Apache CVS (http://people.apache.org/maven-snapshot-repository), >maven1-ibiblio (http://www.ibiblio.org/maven), >snapshots (http://snapshots.maven.codehaus.org/maven2), >apache-cvs (http://cvs.apache.org/repository) > > > > > But when I build from the directory it is fine and then the top-level > will continue. Something is horked... not sure why though... > > Where did this jsr plugin come from? > > --jason > > > On Jun 26, 2006, at 1:05 PM, Prasad Kashyap wrote: > > > Alan, > > > > You'd have to build the geronimo-packaging-plugin manually first. It's > > under geronimo/m2-plugins > > > > cd geronimo/m2-plugins > > mvn clean > > mvn -N > > mvn > > > > Cheers > > Prasad > > > > On 6/25/06, Alan D. Cabrera <[EMAIL PROTECTED]> wrote: > >> I get this error: > >> > >> Try downloading the file manually from the project website. > >> > >> Then, install it using the command: > >> mvn install:install-file -DgroupId=org.apache.geronimo.plugins > >> -DartifactId=geronimo-packaging-plugin \ > >> -Dversion=1.2.0 -Dpackaging=maven-plugin -Dfile=/path/to/file > >> > >> > >> org.apache.geronimo.plugins:geronimo-packaging-plugin:maven- > >> plugin:1.2.0 > >> > >> from the specified remote repositories: > >> central (http://repo1.maven.org/maven2), > >> codehaus-dist (http://dist.codehaus.org/mojo/m2-snapshots), > >> snapshots (http://snapshots.maven.codehaus.org/maven2) > >> > >> org.apache.geronimo.plugins:geronimo-packaging-plugin:maven- > >> plugin:1.2.0 > >> > >> from the specified remote repositories: > >> central (http://repo1.maven.org/maven2), > >> codehaus-dist (http://dist.codehaus.org/mojo/m2-snapshots), > >> snapshots (http://snapshots.maven.codehaus.org/maven2) > >> > >> > >> > >> Regards, > >> Alan > >> > >> > >> > >
Re: Unable to build using m2
Why does it fail the first time? This seems fishy too... I'm rebuild again to see what it does, but that is painfully slow... If we really do depend on a development version of the plugin, then we should either... Lobby to get the plugin released or Checkin and manage our own version of that plugin The later is not ideal, but in an open-source world that we live in, sometimes that is the only option as we need stability and can not always rely on other groups to provide that for us. * * * Also, on a side note, we should explicitly list the versions of maven and mojo plugins that we use. I have run into problems many many times when these teams release new versions of the plugins which effectively break the build. It is _nice_ that Maven can download the latest and greatest release of artifacts... but since those latest versions might behave differently that the project is configured to use... it will just end up breaking things. So, don't buy into the "magic" be explicit and tell Maven what version to use. --jason On Jun 26, 2006, at 8:13 PM, Prasad Kashyap wrote: http://www.mail-archive.com/[email protected]/msg25378.html On 6/26/06, Jason Dillon <[EMAIL PROTECTED]> wrote: What the heck is up with the xmlbeans plugin? I keep getting this from the top-level: [INFO] - --- [ERROR] BUILD ERROR [INFO] - --- [INFO] Failed to resolve artifact. Missing: -- 1) xmlbeans:xmlbeans-jsr173-api:jar:2.0-dev Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=xmlbeans - DartifactId=xmlbeans-jsr173-api \ -Dversion=2.0-dev -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.geronimo.modules:geronimo-j2ee-builder:jar: 1.2- SNAPSHOT 2) stax:stax:jar:1.1.1-dev 3) xmlbeans:xmlbeans-jsr173-api:jar:2.0-dev -- 1 required artifact is missing. for artifact: org.apache.geronimo.modules:geronimo-j2ee-builder:jar:1.2-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2), codehaus-dist (http://dist.codehaus.org), Apache CVS (http://people.apache.org/maven-snapshot-repository), maven1-ibiblio (http://www.ibiblio.org/maven), snapshots (http://snapshots.maven.codehaus.org/maven2), apache-cvs (http://cvs.apache.org/repository) But when I build from the directory it is fine and then the top-level will continue. Something is horked... not sure why though... Where did this jsr plugin come from? --jason On Jun 26, 2006, at 1:05 PM, Prasad Kashyap wrote: > Alan, > > You'd have to build the geronimo-packaging-plugin manually first. It's > under geronimo/m2-plugins > > cd geronimo/m2-plugins > mvn clean > mvn -N > mvn > > Cheers > Prasad > > On 6/25/06, Alan D. Cabrera <[EMAIL PROTECTED]> wrote: >> I get this error: >> >> Try downloading the file manually from the project website. >> >> Then, install it using the command: >> mvn install:install-file -DgroupId=org.apache.geronimo.plugins >> -DartifactId=geronimo-packaging-plugin \ >> -Dversion=1.2.0 -Dpackaging=maven-plugin -Dfile=/path/ to/file >> >> >> org.apache.geronimo.plugins:geronimo-packaging-plugin:maven- >> plugin:1.2.0 >> >> from the specified remote repositories: >> central (http://repo1.maven.org/maven2), >> codehaus-dist (http://dist.codehaus.org/mojo/m2-snapshots), >> snapshots (http://snapshots.maven.codehaus.org/maven2) >> >> org.apache.geronimo.plugins:geronimo-packaging-plugin:maven- >> plugin:1.2.0 >> >> from the specified remote repositories: >> central (http://repo1.maven.org/maven2), >> codehaus-dist (http://dist.codehaus.org/mojo/m2-snapshots), >> snapshots (http://snapshots.maven.codehaus.org/maven2) >> >> >> >> Regards, >> Alan >> >> >>
Re: Unable to build using m2
I'm really, REALLY, glad you have taken an interest in m2 migration :-) Your experience with other such migrations can surely help us. Alright so now you can guide us. :-) I need a buildable server too ;-) So we shall hardcode the parent in all pom.xml and remove the . element for that project itself. That should help us do a single build w/o the -N. Yup, each module should define the project/parent/version and only the root pom.xml should define project/version. Leave mgmnt of this number to the release process, don't try to fix it with properties now, since it just doesn't work like that in m2 yet. What else would u advise ? Well, I'm still assessing what the state of the m2 conversion is. Offhand I can think of a few things that we should do: Create some helper modules to carry build configuration. Specifically, we should create a new module that contains a simple Log4j configuration that can be shared by all modules. IMO, the default build should not spit out tons of output when running tests. It should capture all output into target/test.log and if needed allow the developer to enable system.out with a property setting. This is easily done be creating a new module that contains the shared log4j.properties and then hook it up as a default extension to the build. But, to do this, the module needs to be built separately and downloaded. Not a big deal really, but something needs to be done to setup/facilitate its build. I recommend that we setup a peer tree that holds build support modules. Starting out with the logging- config module... but there are also other reasons to have these support modules, especially as we add more and more projects that need to share the same basic configuration. I also think that we should remove any unneeded properties in the root pom. I mentioned the reasoning before... basically less is more. This file is going to get more and more complicated, no reason to inflate that with unneeded properties. Drop and configured modules that are not checked in to the tree (ie. modules/openejb). If this is really needed then it should be checked in. * * * Other thoughts are more about future reorganization of the tree. I think we may want to split up the tree as it exists now into a few smaller chunks that represent more functional areas. For example, I'd like to have all of the core modules grouped up, so that I could just build everything needed to just get the very basics up. Then another group for all of the J2EE support, and then another for thirdparty vendor support, etc. We should be willing to reorganize the tree after we get the basic build going, to facilitate separation of concerns from a component level... meaning that if I am only interested in building the bare server, then I should not need to bother with all of the other j2EE and 3rdparty stuff. But all of this will come in time. I think that once the m2 build it functional that we should reorganize right away into functional groups of modules. If I notice anything that I think is a bit "crazy" I will be sure to post it to the list. --jason
Re: Unable to build using m2
http://www.mail-archive.com/[email protected]/msg25378.html On 6/26/06, Jason Dillon <[EMAIL PROTECTED]> wrote: What the heck is up with the xmlbeans plugin? I keep getting this from the top-level: [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Missing: -- 1) xmlbeans:xmlbeans-jsr173-api:jar:2.0-dev Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=xmlbeans - DartifactId=xmlbeans-jsr173-api \ -Dversion=2.0-dev -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.geronimo.modules:geronimo-j2ee-builder:jar:1.2- SNAPSHOT 2) stax:stax:jar:1.1.1-dev 3) xmlbeans:xmlbeans-jsr173-api:jar:2.0-dev -- 1 required artifact is missing. for artifact: org.apache.geronimo.modules:geronimo-j2ee-builder:jar:1.2-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2), codehaus-dist (http://dist.codehaus.org), Apache CVS (http://people.apache.org/maven-snapshot-repository), maven1-ibiblio (http://www.ibiblio.org/maven), snapshots (http://snapshots.maven.codehaus.org/maven2), apache-cvs (http://cvs.apache.org/repository) But when I build from the directory it is fine and then the top-level will continue. Something is horked... not sure why though... Where did this jsr plugin come from? --jason On Jun 26, 2006, at 1:05 PM, Prasad Kashyap wrote: > Alan, > > You'd have to build the geronimo-packaging-plugin manually first. It's > under geronimo/m2-plugins > > cd geronimo/m2-plugins > mvn clean > mvn -N > mvn > > Cheers > Prasad > > On 6/25/06, Alan D. Cabrera <[EMAIL PROTECTED]> wrote: >> I get this error: >> >> Try downloading the file manually from the project website. >> >> Then, install it using the command: >> mvn install:install-file -DgroupId=org.apache.geronimo.plugins >> -DartifactId=geronimo-packaging-plugin \ >> -Dversion=1.2.0 -Dpackaging=maven-plugin -Dfile=/path/to/file >> >> >> org.apache.geronimo.plugins:geronimo-packaging-plugin:maven- >> plugin:1.2.0 >> >> from the specified remote repositories: >> central (http://repo1.maven.org/maven2), >> codehaus-dist (http://dist.codehaus.org/mojo/m2-snapshots), >> snapshots (http://snapshots.maven.codehaus.org/maven2) >> >> org.apache.geronimo.plugins:geronimo-packaging-plugin:maven- >> plugin:1.2.0 >> >> from the specified remote repositories: >> central (http://repo1.maven.org/maven2), >> codehaus-dist (http://dist.codehaus.org/mojo/m2-snapshots), >> snapshots (http://snapshots.maven.codehaus.org/maven2) >> >> >> >> Regards, >> Alan >> >> >>
Re: Unable to build using m2
What the heck is up with the xmlbeans plugin? I keep getting this from the top-level: [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Missing: -- 1) xmlbeans:xmlbeans-jsr173-api:jar:2.0-dev Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=xmlbeans - DartifactId=xmlbeans-jsr173-api \ -Dversion=2.0-dev -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.geronimo.modules:geronimo-j2ee-builder:jar:1.2- SNAPSHOT 2) stax:stax:jar:1.1.1-dev 3) xmlbeans:xmlbeans-jsr173-api:jar:2.0-dev -- 1 required artifact is missing. for artifact: org.apache.geronimo.modules:geronimo-j2ee-builder:jar:1.2-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2), codehaus-dist (http://dist.codehaus.org), Apache CVS (http://people.apache.org/maven-snapshot-repository), maven1-ibiblio (http://www.ibiblio.org/maven), snapshots (http://snapshots.maven.codehaus.org/maven2), apache-cvs (http://cvs.apache.org/repository) But when I build from the directory it is fine and then the top-level will continue. Something is horked... not sure why though... Where did this jsr plugin come from? --jason On Jun 26, 2006, at 1:05 PM, Prasad Kashyap wrote: Alan, You'd have to build the geronimo-packaging-plugin manually first. It's under geronimo/m2-plugins cd geronimo/m2-plugins mvn clean mvn -N mvn Cheers Prasad On 6/25/06, Alan D. Cabrera <[EMAIL PROTECTED]> wrote: I get this error: Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.geronimo.plugins -DartifactId=geronimo-packaging-plugin \ -Dversion=1.2.0 -Dpackaging=maven-plugin -Dfile=/path/to/file org.apache.geronimo.plugins:geronimo-packaging-plugin:maven- plugin:1.2.0 from the specified remote repositories: central (http://repo1.maven.org/maven2), codehaus-dist (http://dist.codehaus.org/mojo/m2-snapshots), snapshots (http://snapshots.maven.codehaus.org/maven2) org.apache.geronimo.plugins:geronimo-packaging-plugin:maven- plugin:1.2.0 from the specified remote repositories: central (http://repo1.maven.org/maven2), codehaus-dist (http://dist.codehaus.org/mojo/m2-snapshots), snapshots (http://snapshots.maven.codehaus.org/maven2) Regards, Alan
Re: Unable to build using m2
Jason, I'm really, REALLY, glad you have taken an interest in m2 migration :-) Your experience with other such migrations can surely help us. Alright so now you can guide us. So we shall hardcode the parent in all pom.xml and remove the . element for that project itself. That should help us do a single build w/o the -N. What else would u advise ? Thanx Prasad On 6/26/06, Jason Dillon <[EMAIL PROTECTED]> wrote: I don't see what the problem is. Is this just about putting the version in the parent element? I don't really like that it has to be there, but I am okay with it and using the release plugin to manage that value, which is the main benefit of the release plugin IMO. Or am I missing something? I've recently converted a number of large m1 projects to using m2 and have run into very little issues. Most are related to use of custom jelly, requiring new mojos which is not a big issue. Others being due to projects dependent on those mojos, and keeping them under a separate lifecycle, and expecting that users will download them not build them. So the top-level pom.xml just says 1.2-SNAPSHOT and then all children have ...1.2-SNAPSHOT. This works very well to *build* and is only a slight pain when releasing, but as I mentioned the release plugin handles this. I would obviously rather that it inspect the relativePath first... up until it finds a version and if the parent is not available then pull from the repo... but that isn't gonna happen any time soonish for us to benefit from. IMO, we need to adapt to how m2 works now and then grow with it as we get features/bugs fixed and implemented. --jason On Jun 26, 2006, at 7:21 PM, Prasad Kashyap wrote: > Yes, that's the ideal situation and we very much desire it. But here's > what's preventing us > > http://issues.apache.org/jira/browse/GERONIMO-1755#action_12371755 > http://jira.codehaus.org/browse/MNG-624 > > Cheers > Prasad > > On 6/26/06, Jason Dillon <[EMAIL PROTECTED]> wrote: >> So what to do about openejb? >> >> Build fails: >> >> >> Bliss:~/ws/apache/geronimo/trunk jason$ mvn >> [INFO] Scanning for projects... >> [INFO] >> - >> --- >> [ERROR] FATAL ERROR >> [INFO] >> - >> --- >> [INFO] Error building POM (may not be this project's POM). >> >> >> Project ID: unknown >> >> Reason: Could not find the model file '/Users/jason/ws/apache/ >> geronimo/trunk/openejb/modules/pom.xml'. >> >> >> [INFO] >> - >> --- >> [INFO] Trace >> org.apache.maven.reactor.MavenExecutionException: Could not find the >> model file '/Users/jason/ws/apache/geronimo/trunk/openejb/modules/ >> pom.xml'. >> at org.apache.maven.DefaultMaven.getProjects >> (DefaultMaven.java:365) >> at org.apache.maven.DefaultMaven.doExecute >> (DefaultMaven.java: >> 278) >> at org.apache.maven.DefaultMaven.execute >> (DefaultMaven.java:115) >> at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native >> Method) >> at sun.reflect.NativeMethodAccessorImpl.invoke >> (NativeMethodAccessorImpl.java:39) >> at sun.reflect.DelegatingMethodAccessorImpl.invoke >> (DelegatingMethodAccessorImpl.java:25) >> at java.lang.reflect.Method.invoke(Method.java:324) >> at org.codehaus.classworlds.Launcher.launchEnhanced >> (Launcher.java:315) >> at org.codehaus.classworlds.Launcher.launch(Launcher.java: >> 255) >> at org.codehaus.classworlds.Launcher.mainWithExitCode >> (Launcher.java:430) >> at org.codehaus.classworlds.Launcher.main(Launcher.java:375) >> Caused by: org.apache.maven.project.ProjectBuildingException: Could >> not find the model file '/Users/jason/ws/apache/geronimo/trunk/ >> openejb/modules/pom.xml'. >> at >> org.apache.maven.project.DefaultMavenProjectBuilder.readModel >> (DefaultMavenProjectBuilder.java:1274) >> at >> org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFi >> leI >> nternal(DefaultMavenProjectBuilder.java:414) >> at org.apache.maven.project.DefaultMavenProjectBuilder.build >> (DefaultMavenProjectBuilder.java:192) >> at org.apache.maven.DefaultMaven.getProject >> (DefaultMaven.java:515) >> at org.apache.maven.DefaultMaven.collectProjects >> (DefaultMaven.java:447) >> at org.apache.maven.DefaultMaven.collectProjects >> (DefaultMaven.java:491) >> at org.apache.maven.DefaultMaven.getProjects >> (DefaultMaven.java:351) >> ... 11 more >> Caused by: java.io.FileNotFoundException: /Users/jason/ws/apache/ >> geronimo/trunk/openejb/modules/pom.xml (No such file or directory) >> at java.io.FileInputStream.open(Native Method) >> at java.io.FileInputStream.(FileInputStream.java:106) >> at java.io.FileReader.(
Re: Unable to build using m2
I don't see what the problem is. Is this just about putting the version in the parent element? I don't really like that it has to be there, but I am okay with it and using the release plugin to manage that value, which is the main benefit of the release plugin IMO. Or am I missing something? I've recently converted a number of large m1 projects to using m2 and have run into very little issues. Most are related to use of custom jelly, requiring new mojos which is not a big issue. Others being due to projects dependent on those mojos, and keeping them under a separate lifecycle, and expecting that users will download them not build them. So the top-level pom.xml just says 1.2-SNAPSHOT and then all children have ...1.2-SNAPSHOTversion>. This works very well to *build* and is only a slight pain when releasing, but as I mentioned the release plugin handles this. I would obviously rather that it inspect the relativePath first... up until it finds a version and if the parent is not available then pull from the repo... but that isn't gonna happen any time soonish for us to benefit from. IMO, we need to adapt to how m2 works now and then grow with it as we get features/bugs fixed and implemented. --jason On Jun 26, 2006, at 7:21 PM, Prasad Kashyap wrote: Yes, that's the ideal situation and we very much desire it. But here's what's preventing us http://issues.apache.org/jira/browse/GERONIMO-1755#action_12371755 http://jira.codehaus.org/browse/MNG-624 Cheers Prasad On 6/26/06, Jason Dillon <[EMAIL PROTECTED]> wrote: So what to do about openejb? Build fails: Bliss:~/ws/apache/geronimo/trunk jason$ mvn [INFO] Scanning for projects... [INFO] - --- [ERROR] FATAL ERROR [INFO] - --- [INFO] Error building POM (may not be this project's POM). Project ID: unknown Reason: Could not find the model file '/Users/jason/ws/apache/ geronimo/trunk/openejb/modules/pom.xml'. [INFO] - --- [INFO] Trace org.apache.maven.reactor.MavenExecutionException: Could not find the model file '/Users/jason/ws/apache/geronimo/trunk/openejb/modules/ pom.xml'. at org.apache.maven.DefaultMaven.getProjects (DefaultMaven.java:365) at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java: 278) at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.codehaus.classworlds.Launcher.launchEnhanced (Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java: 255) at org.codehaus.classworlds.Launcher.mainWithExitCode (Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.project.ProjectBuildingException: Could not find the model file '/Users/jason/ws/apache/geronimo/trunk/ openejb/modules/pom.xml'. at org.apache.maven.project.DefaultMavenProjectBuilder.readModel (DefaultMavenProjectBuilder.java:1274) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFi leI nternal(DefaultMavenProjectBuilder.java:414) at org.apache.maven.project.DefaultMavenProjectBuilder.build (DefaultMavenProjectBuilder.java:192) at org.apache.maven.DefaultMaven.getProject (DefaultMaven.java:515) at org.apache.maven.DefaultMaven.collectProjects (DefaultMaven.java:447) at org.apache.maven.DefaultMaven.collectProjects (DefaultMaven.java:491) at org.apache.maven.DefaultMaven.getProjects (DefaultMaven.java:351) ... 11 more Caused by: java.io.FileNotFoundException: /Users/jason/ws/apache/ geronimo/trunk/openejb/modules/pom.xml (No such file or directory) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.(FileInputStream.java:106) at java.io.FileReader.(FileReader.java:55) at org.apache.maven.project.DefaultMavenProjectBuilder.readModel (DefaultMavenProjectBuilder.java:1269) ... 17 more [INFO] - --- [INFO] Total time: 33 seconds [INFO] Finished at: Mon Jun 26 18:30:25 PDT 2006 [INFO] Final Memory: 7M/14M [INFO] - --- Do I need to check something else out? If so... WHY? Or do I need to pass some-other configuration? If so... WHY? I've said this before and will say it again (and again)...
Re: Unable to build using m2
Yes, that's the ideal situation and we very much desire it. But here's what's preventing us http://issues.apache.org/jira/browse/GERONIMO-1755#action_12371755 http://jira.codehaus.org/browse/MNG-624 Cheers Prasad On 6/26/06, Jason Dillon <[EMAIL PROTECTED]> wrote: So what to do about openejb? Build fails: Bliss:~/ws/apache/geronimo/trunk jason$ mvn [INFO] Scanning for projects... [INFO] [ERROR] FATAL ERROR [INFO] [INFO] Error building POM (may not be this project's POM). Project ID: unknown Reason: Could not find the model file '/Users/jason/ws/apache/ geronimo/trunk/openejb/modules/pom.xml'. [INFO] [INFO] Trace org.apache.maven.reactor.MavenExecutionException: Could not find the model file '/Users/jason/ws/apache/geronimo/trunk/openejb/modules/ pom.xml'. at org.apache.maven.DefaultMaven.getProjects (DefaultMaven.java:365) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java: 278) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.codehaus.classworlds.Launcher.launchEnhanced (Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode (Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.project.ProjectBuildingException: Could not find the model file '/Users/jason/ws/apache/geronimo/trunk/ openejb/modules/pom.xml'. at org.apache.maven.project.DefaultMavenProjectBuilder.readModel (DefaultMavenProjectBuilder.java:1274) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileI nternal(DefaultMavenProjectBuilder.java:414) at org.apache.maven.project.DefaultMavenProjectBuilder.build (DefaultMavenProjectBuilder.java:192) at org.apache.maven.DefaultMaven.getProject (DefaultMaven.java:515) at org.apache.maven.DefaultMaven.collectProjects (DefaultMaven.java:447) at org.apache.maven.DefaultMaven.collectProjects (DefaultMaven.java:491) at org.apache.maven.DefaultMaven.getProjects (DefaultMaven.java:351) ... 11 more Caused by: java.io.FileNotFoundException: /Users/jason/ws/apache/ geronimo/trunk/openejb/modules/pom.xml (No such file or directory) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.(FileInputStream.java:106) at java.io.FileReader.(FileReader.java:55) at org.apache.maven.project.DefaultMavenProjectBuilder.readModel (DefaultMavenProjectBuilder.java:1269) ... 17 more [INFO] [INFO] Total time: 33 seconds [INFO] Finished at: Mon Jun 26 18:30:25 PDT 2006 [INFO] Final Memory: 7M/14M [INFO] Do I need to check something else out? If so... WHY? Or do I need to pass some-other configuration? If so... WHY? I've said this before and will say it again (and again)... I should be able to: 1) svn co .../geronimo/trunk 2) mvn install ... 3) start the server The only assumption made is that Maven 2.0 is installed and that JAVA_HOME (or the equiv on OS X) is setup correctly. If there are more than 3 steps to go from src to server, then something is wrong... and should be fixed. * * * Its been months since I have been able to actually build G... I'd recommend that people periodically blow away your repository cache so that you get really clean builds. Often m2 problems will only start to show up when a clean repo is used... :-( --jason On Jun 26, 2006, at 6:46 PM, Prasad Kashyap wrote: > I'm sorry but I'm confused about this main build and the plugins > build. I thought they are all one single build like we did in m1 with > all the new(xx). > > This is how the build order is specified in the geronimo/pom.xml > > > modules > m2-plugins > applications > openejb/modules > configs > assemblies > > > There's no cyclical dependency there. > > > Jason, as for the , I tried that. It didn't help. Also, > the default value of is ../pom.xml anyways. > > Cheers > Prasad > > > > > On 6/26/06, Jason Dillon <[EMAIL PROTECTED]> wrote: >> FYI, seems that you need to build trunk first (probably until it >> fails with a missing plugin), then build the plugins, t
Re: Unable to build using m2
FYI... if I comment the openejb/modules and `mvn install` I get: [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Plugin could not be found - check that the goal name is correct: Unable to download the artifact from any repository Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.geronimo.plugins - DartifactId=geronimo-packaging-plug in \ -Dversion=1.2.0 -Dpackaging=maven-plugin -Dfile=/path/to/file org.apache.geronimo.plugins:geronimo-packaging-plugin:maven-plugin: 1.2.0 from the specified remote repositories: central (http://repo1.maven.org/maven2), codehaus-dist (http://dist.codehaus.org/mojo/m2-snapshots), snapshots (http://snapshots.maven.codehaus.org/maven2) org.apache.geronimo.plugins:geronimo-packaging-plugin:maven-plugin: 1.2.0 from the specified remote repositories: central (http://repo1.maven.org/maven2), codehaus-dist (http://dist.codehaus.org/mojo/m2-snapshots), snapshots (http://snapshots.maven.codehaus.org/maven2) I'm also a little bit mystified as to why we are managing versions of modules that we build with properties in each module. There should be one tag in the top-level module, and all children omit this tag and pick it up be inheritance. The added properties and tag configuration is just adding extra complexity to the build with no reason. I understand that some of this might be legacy picked up from exp using m1, but m2 is a different beast and IMO we should drop any of the m1-isms whenever possible/prudent. Also, why is the main-build using 1.2-SNAPSHOT and the plugin is 1.2.0? This all seems kinda fishy to me. And, I don't see any reason why the root pom needs to define properties and then use those properties for each and every dependency in the dependencyManagement section. I believe that when a version number is used more than once, say for the spring jars that it is easier/better to manage a single property that is used by all of the dependencies. But to force all dependencies to use these properties when the property is used in only one place is added overhead which means more complex and fragile builds when configuration changes. --jason On Jun 26, 2006, at 6:46 PM, Prasad Kashyap wrote: I'm sorry but I'm confused about this main build and the plugins build. I thought they are all one single build like we did in m1 with all the new(xx). This is how the build order is specified in the geronimo/pom.xml modules m2-plugins applications openejb/modules configs assemblies There's no cyclical dependency there. Jason, as for the , I tried that. It didn't help. Also, the default value of is ../pom.xml anyways. Cheers Prasad On 6/26/06, Jason Dillon <[EMAIL PROTECTED]> wrote: FYI, seems that you need to build trunk first (probably until it fails with a missing plugin), then build the plugins, then rebuild trunk. Just building m2-plugins pukes with: [INFO] - --- [ERROR] BUILD ERROR [INFO] - --- [INFO] Failed to resolve artifact. Missing: -- 1) org.apache.geronimo.modules:geronimo-deploy-tool:jar:1.2-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.geronimo.modules -DartifactId=geronimo-deploy-tool \ -Dversion=1.2-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/ file Path to dependency: 1) org.apache.geronimo.plugins:geronimo-packaging- plugin:maven-plugin:1.2.0 2) org.apache.geronimo.modules:geronimo-deploy-tool:jar:1.2- SNAPSHOT 2) org.apache.geronimo.modules:geronimo-kernel:jar:1.2-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.geronimo.modules -DartifactId=geronimo-kernel \ -Dversion=1.2-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/ file Path to dependency: 1) org.apache.geronimo.plugins:geronimo-packaging- plugin:maven-plugin:1.2.0 2) org.apache.geronimo.modules:geronimo-kernel:jar:1.2- SNAPSHOT 3) org.apache.geronimo.modules:geronimo-service-builder:jar:1.2- SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.geronimo.modules -DartifactId=geronimo-service-builder \ -Dversion=1.2-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/ file Path to dependency: 1) org.apache.geronimo.plugins:geronimo-packaging- plugin:maven-plugin:1.2.0 2)
Re: Unable to build using m2
So what to do about openejb? Build fails: Bliss:~/ws/apache/geronimo/trunk jason$ mvn [INFO] Scanning for projects... [INFO] [ERROR] FATAL ERROR [INFO] [INFO] Error building POM (may not be this project's POM). Project ID: unknown Reason: Could not find the model file '/Users/jason/ws/apache/ geronimo/trunk/openejb/modules/pom.xml'. [INFO] [INFO] Trace org.apache.maven.reactor.MavenExecutionException: Could not find the model file '/Users/jason/ws/apache/geronimo/trunk/openejb/modules/ pom.xml'. at org.apache.maven.DefaultMaven.getProjects (DefaultMaven.java:365) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java: 278) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.codehaus.classworlds.Launcher.launchEnhanced (Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode (Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.project.ProjectBuildingException: Could not find the model file '/Users/jason/ws/apache/geronimo/trunk/ openejb/modules/pom.xml'. at org.apache.maven.project.DefaultMavenProjectBuilder.readModel (DefaultMavenProjectBuilder.java:1274) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileI nternal(DefaultMavenProjectBuilder.java:414) at org.apache.maven.project.DefaultMavenProjectBuilder.build (DefaultMavenProjectBuilder.java:192) at org.apache.maven.DefaultMaven.getProject (DefaultMaven.java:515) at org.apache.maven.DefaultMaven.collectProjects (DefaultMaven.java:447) at org.apache.maven.DefaultMaven.collectProjects (DefaultMaven.java:491) at org.apache.maven.DefaultMaven.getProjects (DefaultMaven.java:351) ... 11 more Caused by: java.io.FileNotFoundException: /Users/jason/ws/apache/ geronimo/trunk/openejb/modules/pom.xml (No such file or directory) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.(FileInputStream.java:106) at java.io.FileReader.(FileReader.java:55) at org.apache.maven.project.DefaultMavenProjectBuilder.readModel (DefaultMavenProjectBuilder.java:1269) ... 17 more [INFO] [INFO] Total time: 33 seconds [INFO] Finished at: Mon Jun 26 18:30:25 PDT 2006 [INFO] Final Memory: 7M/14M [INFO] Do I need to check something else out? If so... WHY? Or do I need to pass some-other configuration? If so... WHY? I've said this before and will say it again (and again)... I should be able to: 1) svn co .../geronimo/trunk 2) mvn install ... 3) start the server The only assumption made is that Maven 2.0 is installed and that JAVA_HOME (or the equiv on OS X) is setup correctly. If there are more than 3 steps to go from src to server, then something is wrong... and should be fixed. * * * Its been months since I have been able to actually build G... I'd recommend that people periodically blow away your repository cache so that you get really clean builds. Often m2 problems will only start to show up when a clean repo is used... :-( --jason On Jun 26, 2006, at 6:46 PM, Prasad Kashyap wrote: I'm sorry but I'm confused about this main build and the plugins build. I thought they are all one single build like we did in m1 with all the new(xx). This is how the build order is specified in the geronimo/pom.xml modules m2-plugins applications openejb/modules configs assemblies There's no cyclical dependency there. Jason, as for the , I tried that. It didn't help. Also, the default value of is ../pom.xml anyways. Cheers Prasad On 6/26/06, Jason Dillon <[EMAIL PROTECTED]> wrote: FYI, seems that you need to build trunk first (probably until it fails with a missing plugin), then build the plugins, then rebuild trunk. Just building m2-plugins pukes with: [INFO] - --- [ERROR] BUILD ERROR [INFO] - --- [INFO] Failed to resolve artifact. Mis
Re: Unable to build using m2
Jason, as for the , I tried that. It didn't help. Also, the default value of is ../pom.xml anyways. There are a few cases when this will not work, a bug in m2 code AFAIK. Better to make it explicit IMO. --jason
Re: Unable to build using m2
I'm sorry but I'm confused about this main build and the plugins build. I thought they are all one single build like we did in m1 with all the new(xx). This is how the build order is specified in the geronimo/pom.xml modules m2-plugins applications openejb/modules configs assemblies There's no cyclical dependency there. Jason, as for the , I tried that. It didn't help. Also, the default value of is ../pom.xml anyways. Cheers Prasad On 6/26/06, Jason Dillon <[EMAIL PROTECTED]> wrote: FYI, seems that you need to build trunk first (probably until it fails with a missing plugin), then build the plugins, then rebuild trunk. Just building m2-plugins pukes with: [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Missing: -- 1) org.apache.geronimo.modules:geronimo-deploy-tool:jar:1.2-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.geronimo.modules -DartifactId=geronimo-deploy-tool \ -Dversion=1.2-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.geronimo.plugins:geronimo-packaging- plugin:maven-plugin:1.2.0 2) org.apache.geronimo.modules:geronimo-deploy-tool:jar:1.2- SNAPSHOT 2) org.apache.geronimo.modules:geronimo-kernel:jar:1.2-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.geronimo.modules -DartifactId=geronimo-kernel \ -Dversion=1.2-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.geronimo.plugins:geronimo-packaging- plugin:maven-plugin:1.2.0 2) org.apache.geronimo.modules:geronimo-kernel:jar:1.2-SNAPSHOT 3) org.apache.geronimo.modules:geronimo-service-builder:jar:1.2-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.geronimo.modules -DartifactId=geronimo-service-builder \ -Dversion=1.2-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.geronimo.plugins:geronimo-packaging- plugin:maven-plugin:1.2.0 2) org.apache.geronimo.modules:geronimo-service-builder:jar: 1.2-SNAPSHOT 4) org.apache.geronimo.modules:geronimo-system:jar:1.2-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.geronimo.modules -DartifactId=geronimo-system \ -Dversion=1.2-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.geronimo.plugins:geronimo-packaging- plugin:maven-plugin:1.2.0 2) org.apache.geronimo.modules:geronimo-system:jar:1.2-SNAPSHOT -- 4 required artifacts are missing. for artifact: org.apache.geronimo.plugins:geronimo-packaging-plugin:maven-plugin: 1.2.0 from the specified remote repositories: central (http://repo1.maven.org/maven2), codehaus-dist (http://dist.codehaus.org), Apache CVS (http://people.apache.org/maven-snapshot-repository), maven1-ibiblio (http://www.ibiblio.org/maven), snapshots (http://snapshots.maven.codehaus.org/maven2), apache-cvs (http://cvs.apache.org/repository) Looks like bad news... if the main build needs the plugin, and the plugin needs the main build, and m2 won't let it all run/build at the same time due to its plugin resolution fluff. May need to provide a bootstrap, which builds a few select modules, then the entire system... but that is not very friendly either. * * * Also, start adding ../pom.xml to the parent element, so that you can skip the mvn -N install bits. --jason On Jun 26, 2006, at 1:05 PM, Prasad Kashyap wrote: > Alan, > > You'd have to build the geronimo-packaging-plugin manually first. It's > under geronimo/m2-plugins > > cd geronimo/m2-plugins > mvn clean > mvn -N > mvn > > Cheers > Prasad > > On 6/25/06, Alan D. Cabrera <[EMAIL PROTECTED]> wrote: >> I get this error: >> >> Try downloading the file manually from the project website. >> >> Then, install it using the command: >> mvn install:install-file -DgroupId=org.apache.geronimo.plugins >> -DartifactId=geronimo-packaging-plugin \ >> -Dversion=1.2.0 -Dpackaging=maven-plugin -Dfile=/path/to/file >> >> >> org.apache.geronimo.plugins:geronimo-packaging-plugin:maven- >> plugin:1.2.0 >> >> from the specified remote repositories: >> central (http://repo1.maven.org/maven2), >> codehaus-dist (http://dist.codehaus.org/mojo/m2-snapshots), >> snapshots (http://snapshots.maven.codehaus.org/maven2) >> >> org.apache.geronimo.plugins:geronimo-packaging-plugin:ma
Re: Unable to build using m2
FYI, seems that you need to build trunk first (probably until it fails with a missing plugin), then build the plugins, then rebuild trunk. Just building m2-plugins pukes with: [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Missing: -- 1) org.apache.geronimo.modules:geronimo-deploy-tool:jar:1.2-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.geronimo.modules -DartifactId=geronimo-deploy-tool \ -Dversion=1.2-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.geronimo.plugins:geronimo-packaging- plugin:maven-plugin:1.2.0 2) org.apache.geronimo.modules:geronimo-deploy-tool:jar:1.2- SNAPSHOT 2) org.apache.geronimo.modules:geronimo-kernel:jar:1.2-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.geronimo.modules -DartifactId=geronimo-kernel \ -Dversion=1.2-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.geronimo.plugins:geronimo-packaging- plugin:maven-plugin:1.2.0 2) org.apache.geronimo.modules:geronimo-kernel:jar:1.2-SNAPSHOT 3) org.apache.geronimo.modules:geronimo-service-builder:jar:1.2-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.geronimo.modules -DartifactId=geronimo-service-builder \ -Dversion=1.2-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.geronimo.plugins:geronimo-packaging- plugin:maven-plugin:1.2.0 2) org.apache.geronimo.modules:geronimo-service-builder:jar: 1.2-SNAPSHOT 4) org.apache.geronimo.modules:geronimo-system:jar:1.2-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.geronimo.modules -DartifactId=geronimo-system \ -Dversion=1.2-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.geronimo.plugins:geronimo-packaging- plugin:maven-plugin:1.2.0 2) org.apache.geronimo.modules:geronimo-system:jar:1.2-SNAPSHOT -- 4 required artifacts are missing. for artifact: org.apache.geronimo.plugins:geronimo-packaging-plugin:maven-plugin: 1.2.0 from the specified remote repositories: central (http://repo1.maven.org/maven2), codehaus-dist (http://dist.codehaus.org), Apache CVS (http://people.apache.org/maven-snapshot-repository), maven1-ibiblio (http://www.ibiblio.org/maven), snapshots (http://snapshots.maven.codehaus.org/maven2), apache-cvs (http://cvs.apache.org/repository) Looks like bad news... if the main build needs the plugin, and the plugin needs the main build, and m2 won't let it all run/build at the same time due to its plugin resolution fluff. May need to provide a bootstrap, which builds a few select modules, then the entire system... but that is not very friendly either. * * * Also, start adding ../pom.xml to the parent element, so that you can skip the mvn -N install bits. --jason On Jun 26, 2006, at 1:05 PM, Prasad Kashyap wrote: Alan, You'd have to build the geronimo-packaging-plugin manually first. It's under geronimo/m2-plugins cd geronimo/m2-plugins mvn clean mvn -N mvn Cheers Prasad On 6/25/06, Alan D. Cabrera <[EMAIL PROTECTED]> wrote: I get this error: Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.geronimo.plugins -DartifactId=geronimo-packaging-plugin \ -Dversion=1.2.0 -Dpackaging=maven-plugin -Dfile=/path/to/file org.apache.geronimo.plugins:geronimo-packaging-plugin:maven- plugin:1.2.0 from the specified remote repositories: central (http://repo1.maven.org/maven2), codehaus-dist (http://dist.codehaus.org/mojo/m2-snapshots), snapshots (http://snapshots.maven.codehaus.org/maven2) org.apache.geronimo.plugins:geronimo-packaging-plugin:maven- plugin:1.2.0 from the specified remote repositories: central (http://repo1.maven.org/maven2), codehaus-dist (http://dist.codehaus.org/mojo/m2-snapshots), snapshots (http://snapshots.maven.codehaus.org/maven2) Regards, Alan
Re: Unable to build using m2
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. --jason On Jun 26, 2006, at 1:05 PM, Prasad Kashyap wrote: Alan, You'd have to build the geronimo-packaging-plugin manually first. It's under geronimo/m2-plugins cd geronimo/m2-plugins mvn clean mvn -N mvn Cheers Prasad On 6/25/06, Alan D. Cabrera <[EMAIL PROTECTED]> wrote: I get this error: Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.geronimo.plugins -DartifactId=geronimo-packaging-plugin \ -Dversion=1.2.0 -Dpackaging=maven-plugin -Dfile=/path/to/file org.apache.geronimo.plugins:geronimo-packaging-plugin:maven- plugin:1.2.0 from the specified remote repositories: central (http://repo1.maven.org/maven2), codehaus-dist (http://dist.codehaus.org/mojo/m2-snapshots), snapshots (http://snapshots.maven.codehaus.org/maven2) org.apache.geronimo.plugins:geronimo-packaging-plugin:maven- plugin:1.2.0 from the specified remote repositories: central (http://repo1.maven.org/maven2), codehaus-dist (http://dist.codehaus.org/mojo/m2-snapshots), snapshots (http://snapshots.maven.codehaus.org/maven2) Regards, Alan
Re: Unable to build using m2
Alan, You'd have to build the geronimo-packaging-plugin manually first. It's under geronimo/m2-plugins cd geronimo/m2-plugins mvn clean mvn -N mvn Cheers Prasad On 6/25/06, Alan D. Cabrera <[EMAIL PROTECTED]> wrote: I get this error: Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.geronimo.plugins -DartifactId=geronimo-packaging-plugin \ -Dversion=1.2.0 -Dpackaging=maven-plugin -Dfile=/path/to/file org.apache.geronimo.plugins:geronimo-packaging-plugin:maven-plugin:1.2.0 from the specified remote repositories: central (http://repo1.maven.org/maven2), codehaus-dist (http://dist.codehaus.org/mojo/m2-snapshots), snapshots (http://snapshots.maven.codehaus.org/maven2) org.apache.geronimo.plugins:geronimo-packaging-plugin:maven-plugin:1.2.0 from the specified remote repositories: central (http://repo1.maven.org/maven2), codehaus-dist (http://dist.codehaus.org/mojo/m2-snapshots), snapshots (http://snapshots.maven.codehaus.org/maven2) Regards, Alan
