You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by anita kulshreshtha <a_...@yahoo.com> on 2006/06/29 15:44:51 UTC
M2 Issues and Actions
Hi All,
The M2 build work is continuing. Dain just updated the openejb
trunk. Now we will be using openEJB 2.2
(http://issues.apache.org/jira/browse/GERONIMO-2152).
The assembly plugin is under construction. Here are the issues facing
us. I am also reproducing the suggested remedies for some of these.
1. xmlbeans-maven-plugin and xbean pom -
The issue is described here
http://issues.apache.org/jira/browse/GERONIMO-2082
David Jencks has submitted the patches and has been working with the
xmlbeans team. See
http://www.nabble.com/Unable-to-build-using-m2-tf1846875.html#a5041106
2. Spec Jars -
The geronimo spec jars need to be published along with the poms.
This was supposed to happen soon after the 1.1 release.
3. openejb - The openejb build should use geronimo jars that come from
o.a.g groupId. Hence it is necessary to build openejb. Until now v_2.1
was used, now we are switching to 2.2. We should publish snapshots of
these jars too. This will obviate the need for building openejb.
4. Maven does not allow building a plugin and a module if the module
uses the plugin in the same build. As a result the first time build is
a 3 step process. Jason suggested "IMO we should have a completely
separate tree for our build support tools. And once the plugins are
stable we release them, until they are stable we make regular snaps, so
that the main tree(s) can just build w/o having to worry about building
plugins first."
We should start publishing SNAPSHOTs ASAP to solve this problem,
This is very user friendly. Once we have assembled our first full
server, we can start thinking of reorganizing the source tree.
5. checking out openejb - In M1 we could define goals like m:co, it is
not possible to do this in M2. There is no way to specify executions in
the top level pom that are not inherited by the children. And we must
resort to checking out each module and building it! Currently we ask
the user to use svn command to checkout openejb. The other solution is
have the 'support tool tree' which will provide commands for checking
out openejb. If the latest openejb snapshots are always available, we
can eliminate openejb from our build.
We will be documenting any new issues here
http://cwiki.apache.org/confluence/display/geronimo/Building+Geronimo+with+Maven+2
thanks for your patience!
Thanks
Anita
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: M2 Issues and Actions
Posted by anita kulshreshtha <a_...@yahoo.com>.
--- Bill Dudney <bd...@apache.org> wrote:
> Hi Anita,
>
> So where are we to get openejb from now?
>
> https://svn.codehaus.org/openejb/trunk/openejb2/
>
> If so I'd be glad to update the wiki page.
We should update the wiki to use this location as soon as openejb
build starts working again.
Thanks
Anita
>
> TTFN,
>
>
>
> Bill Dudney
> MyFaces - http://myfaces.apache.org
> Cayenne - http://incubator.apache.org/projects/cayenne.html
>
>
>
> On Jun 29, 2006, at 7:44 AM, anita kulshreshtha wrote:
>
> > Hi All,
> > The M2 build work is continuing. Dain just updated the openejb
> > trunk. Now we will be using openEJB 2.2
> > (http://issues.apache.org/jira/browse/GERONIMO-2152).
> > The assembly plugin is under construction. Here are the issues
> facing
> > us. I am also reproducing the suggested remedies for some of these.
> >
> > 1. xmlbeans-maven-plugin and xbean pom -
> > The issue is described here
> > http://issues.apache.org/jira/browse/GERONIMO-2082
> > David Jencks has submitted the patches and has been working with
>
> > the
> > xmlbeans team. See
> >
>
http://www.nabble.com/Unable-to-build-using-m2-tf1846875.html#a5041106
> >
> > 2. Spec Jars -
> > The geronimo spec jars need to be published along with the poms.
> > This was supposed to happen soon after the 1.1 release.
> >
> > 3. openejb - The openejb build should use geronimo jars that come
> from
> > o.a.g groupId. Hence it is necessary to build openejb. Until now
> v_2.1
> > was used, now we are switching to 2.2. We should publish snapshots
> of
> > these jars too. This will obviate the need for building openejb.
> >
> > 4. Maven does not allow building a plugin and a module if the
> module
> > uses the plugin in the same build. As a result the first time build
> is
> > a 3 step process. Jason suggested "IMO we should have a completely
> > separate tree for our build support tools. And once the plugins
> are
> > stable we release them, until they are stable we make regular
> > snaps, so
> > that the main tree(s) can just build w/o having to worry about
> > building
> > plugins first."
> > We should start publishing SNAPSHOTs ASAP to solve this
> problem,
> > This is very user friendly. Once we have assembled our first full
> > server, we can start thinking of reorganizing the source tree.
> > 5. checking out openejb - In M1 we could define goals like m:co, it
> is
> > not possible to do this in M2. There is no way to specify
> > executions in
> > the top level pom that are not inherited by the children. And we
> must
> > resort to checking out each module and building it! Currently we
> ask
> > the user to use svn command to checkout openejb. The other solution
> is
> > have the 'support tool tree' which will provide commands for
> checking
> > out openejb. If the latest openejb snapshots are always available,
> we
> > can eliminate openejb from our build.
> > We will be documenting any new issues here
> > http://cwiki.apache.org/confluence/display/geronimo/Building
> > +Geronimo+with+Maven+2
> > thanks for your patience!
> >
> > Thanks
> > Anita
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam? Yahoo! Mail has the best spam protection around
> > http://mail.yahoo.com
>
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: M2 Issues and Actions
Posted by Bill Dudney <bd...@apache.org>.
Hi Anita,
So where are we to get openejb from now?
https://svn.codehaus.org/openejb/trunk/openejb2/
If so I'd be glad to update the wiki page.
TTFN,
Bill Dudney
MyFaces - http://myfaces.apache.org
Cayenne - http://incubator.apache.org/projects/cayenne.html
On Jun 29, 2006, at 7:44 AM, anita kulshreshtha wrote:
> Hi All,
> The M2 build work is continuing. Dain just updated the openejb
> trunk. Now we will be using openEJB 2.2
> (http://issues.apache.org/jira/browse/GERONIMO-2152).
> The assembly plugin is under construction. Here are the issues facing
> us. I am also reproducing the suggested remedies for some of these.
>
> 1. xmlbeans-maven-plugin and xbean pom -
> The issue is described here
> http://issues.apache.org/jira/browse/GERONIMO-2082
> David Jencks has submitted the patches and has been working with
> the
> xmlbeans team. See
> http://www.nabble.com/Unable-to-build-using-m2-tf1846875.html#a5041106
>
> 2. Spec Jars -
> The geronimo spec jars need to be published along with the poms.
> This was supposed to happen soon after the 1.1 release.
>
> 3. openejb - The openejb build should use geronimo jars that come from
> o.a.g groupId. Hence it is necessary to build openejb. Until now v_2.1
> was used, now we are switching to 2.2. We should publish snapshots of
> these jars too. This will obviate the need for building openejb.
>
> 4. Maven does not allow building a plugin and a module if the module
> uses the plugin in the same build. As a result the first time build is
> a 3 step process. Jason suggested "IMO we should have a completely
> separate tree for our build support tools. And once the plugins are
> stable we release them, until they are stable we make regular
> snaps, so
> that the main tree(s) can just build w/o having to worry about
> building
> plugins first."
> We should start publishing SNAPSHOTs ASAP to solve this problem,
> This is very user friendly. Once we have assembled our first full
> server, we can start thinking of reorganizing the source tree.
> 5. checking out openejb - In M1 we could define goals like m:co, it is
> not possible to do this in M2. There is no way to specify
> executions in
> the top level pom that are not inherited by the children. And we must
> resort to checking out each module and building it! Currently we ask
> the user to use svn command to checkout openejb. The other solution is
> have the 'support tool tree' which will provide commands for checking
> out openejb. If the latest openejb snapshots are always available, we
> can eliminate openejb from our build.
> We will be documenting any new issues here
> http://cwiki.apache.org/confluence/display/geronimo/Building
> +Geronimo+with+Maven+2
> thanks for your patience!
>
> Thanks
> Anita
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
Re: M2 Issues and Actions
Posted by Jason Dillon <ja...@planet57.com>.
I see your point. Thanks for the explanation.
--jason
On Jul 1, 2006, at 2:31 PM, Alan D. Cabrera wrote:
> I am adamantly against pulling in code from a CodeHaus repository
> when I do a co from an ASF repo. Do I understand the proposed
> behavior correctly?
>
>
> Regards,
> Alan
>
> Jason Dillon wrote:
>> I'd just like to know why you are really, really against it?
>>
>> I don't like it, but as a short-term solution I think it is okay.
>>
>> But, hopefully we will have openejb snaps deployed to a repo soon
>> so we won't need to do this.
>>
>> --jason
>>
>>
>> On Jun 30, 2006, at 7:56 AM, Alan D. Cabrera wrote:
>>
>>> As I mentioned in a previous thread. I am really, really,
>>> against this. I'm happy to discuss this further.
>>>
>>>
>>> Regards,
>>> Alan
>>>
>>> Bill Dudney wrote:
>>>> Hi Jacek,
>>>>
>>>> Yep just edit the svn:externals property on geronimo and you are
>>>> done :-)
>>>>
>>>> TTFN,
>>>>
>>>>
>>>> Bill Dudney
>>>> MyFaces - http://myfaces.apache.org
>>>> Cayenne - http://incubator.apache.org/projects/cayenne.html
>>>>
>>>>
>>>>
>>>> On Jun 29, 2006, at 3:40 PM, Jacek Laskowski wrote:
>>>>
>>>>> On 6/29/06, Jason Dillon <ja...@planet57.com> wrote:
>>>>>> Using svn:externals is probably the easiest way to the the
>>>>>> openejb
>>>>>> sources included for use in a m2 build w/o needing the user to
>>>>>> run
>>>>>> `maven -o m:co` or run `svn co ...` directly yo pull the
>>>>>> sources for
>>>>>> the build.
>>>>>>
>>>>>> I think this is the best short-term solution to the openejb
>>>>>> integration issue. I would like to stress that we should
>>>>>> eventually
>>>>>> try to remove this source-level dependency for out long-term
>>>>>> direction.
>>>>>
>>>>> Am I right that it's as simple as executing
>>>>>
>>>>> $ svn propget svn:externals geronimo
>>>>> openejb https://svn.codehaus.org/openejb/trunk/openejb2
>>>>>
>>>>> ?
>>>>>
>>>>> That seems to be an interim yet elegant solution. It's a bug
>>>>> fix so no
>>>>> need to RTC it.
>>>>>
>>>>>> --jason
>>>>>
>>>>> Jacek
>>>>>
>>>>> --
>>>>> Jacek Laskowski
>>>>> http://www.laskowski.net.pl
>>>>
>>>
>>
>
Re: M2 Issues and Actions
Posted by Jacek Laskowski <ja...@laskowski.net.pl>.
On 7/1/06, Alan D. Cabrera <li...@toolazydogs.com> wrote:
> I am adamantly against pulling in code from a CodeHaus repository when I do
> a co from an ASF repo. Do I understand the proposed behavior correctly?
You're right. I didn't think about it this way - they're two separate
(legal) entities and we shouldn't do that. Happily, it's no longer an
issue since OpenEJB jars are updated and the build works like a charm.
> Alan
Jacek
--
Jacek Laskowski
http://www.laskowski.net.pl
Re: M2 Issues and Actions
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
I am adamantly against pulling in code from a CodeHaus repository when I
do a co from an ASF repo. Do I understand the proposed behavior correctly?
Regards,
Alan
Jason Dillon wrote:
> I'd just like to know why you are really, really against it?
>
> I don't like it, but as a short-term solution I think it is okay.
>
> But, hopefully we will have openejb snaps deployed to a repo soon so
> we won't need to do this.
>
> --jason
>
>
> On Jun 30, 2006, at 7:56 AM, Alan D. Cabrera wrote:
>
>> As I mentioned in a previous thread. I am really, really, against
>> this. I'm happy to discuss this further.
>>
>>
>> Regards,
>> Alan
>>
>> Bill Dudney wrote:
>>> Hi Jacek,
>>>
>>> Yep just edit the svn:externals property on geronimo and you are
>>> done :-)
>>>
>>> TTFN,
>>>
>>>
>>> Bill Dudney
>>> MyFaces - http://myfaces.apache.org
>>> Cayenne - http://incubator.apache.org/projects/cayenne.html
>>>
>>>
>>>
>>> On Jun 29, 2006, at 3:40 PM, Jacek Laskowski wrote:
>>>
>>>> On 6/29/06, Jason Dillon <jason@planet57.com
>>>> <ma...@planet57.com>> wrote:
>>>>> Using svn:externals is probably the easiest way to the the openejb
>>>>> sources included for use in a m2 build w/o needing the user to run
>>>>> `maven -o m:co` or run `svn co ...` directly yo pull the sources for
>>>>> the build.
>>>>>
>>>>> I think this is the best short-term solution to the openejb
>>>>> integration issue. I would like to stress that we should eventually
>>>>> try to remove this source-level dependency for out long-term
>>>>> direction.
>>>>
>>>> Am I right that it's as simple as executing
>>>>
>>>> $ svn propget svn:externals geronimo
>>>> openejb https://svn.codehaus.org/openejb/trunk/openejb2
>>>>
>>>> ?
>>>>
>>>> That seems to be an interim yet elegant solution. It's a bug fix so no
>>>> need to RTC it.
>>>>
>>>>> --jason
>>>>
>>>> Jacek
>>>>
>>>> --
>>>> Jacek Laskowski
>>>> http://www.laskowski.net.pl
>>>
>>
>
Re: M2 Issues and Actions
Posted by Jason Dillon <ja...@planet57.com>.
I'd just like to know why you are really, really against it?
I don't like it, but as a short-term solution I think it is okay.
But, hopefully we will have openejb snaps deployed to a repo soon so
we won't need to do this.
--jason
On Jun 30, 2006, at 7:56 AM, Alan D. Cabrera wrote:
> As I mentioned in a previous thread. I am really, really, against
> this. I'm happy to discuss this further.
>
>
> Regards,
> Alan
>
> Bill Dudney wrote:
>> Hi Jacek,
>>
>> Yep just edit the svn:externals property on geronimo and you are
>> done :-)
>>
>> TTFN,
>>
>>
>> Bill Dudney
>> MyFaces - http://myfaces.apache.org
>> Cayenne - http://incubator.apache.org/projects/cayenne.html
>>
>>
>>
>> On Jun 29, 2006, at 3:40 PM, Jacek Laskowski wrote:
>>
>>> On 6/29/06, Jason Dillon <ja...@planet57.com> wrote:
>>>> Using svn:externals is probably the easiest way to the the openejb
>>>> sources included for use in a m2 build w/o needing the user to run
>>>> `maven -o m:co` or run `svn co ...` directly yo pull the sources
>>>> for
>>>> the build.
>>>>
>>>> I think this is the best short-term solution to the openejb
>>>> integration issue. I would like to stress that we should
>>>> eventually
>>>> try to remove this source-level dependency for out long-term
>>>> direction.
>>>
>>> Am I right that it's as simple as executing
>>>
>>> $ svn propget svn:externals geronimo
>>> openejb https://svn.codehaus.org/openejb/trunk/openejb2
>>>
>>> ?
>>>
>>> That seems to be an interim yet elegant solution. It's a bug fix
>>> so no
>>> need to RTC it.
>>>
>>>> --jason
>>>
>>> Jacek
>>>
>>> --
>>> Jacek Laskowski
>>> http://www.laskowski.net.pl
>>
>
Re: M2 Issues and Actions
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
As I mentioned in a previous thread. I am really, really, against
this. I'm happy to discuss this further.
Regards,
Alan
Bill Dudney wrote:
> Hi Jacek,
>
> Yep just edit the svn:externals property on geronimo and you are done :-)
>
> TTFN,
>
>
> Bill Dudney
> MyFaces - http://myfaces.apache.org
> Cayenne - http://incubator.apache.org/projects/cayenne.html
>
>
>
> On Jun 29, 2006, at 3:40 PM, Jacek Laskowski wrote:
>
>> On 6/29/06, Jason Dillon <jason@planet57.com
>> <ma...@planet57.com>> wrote:
>>> Using svn:externals is probably the easiest way to the the openejb
>>> sources included for use in a m2 build w/o needing the user to run
>>> `maven -o m:co` or run `svn co ...` directly yo pull the sources for
>>> the build.
>>>
>>> I think this is the best short-term solution to the openejb
>>> integration issue. I would like to stress that we should eventually
>>> try to remove this source-level dependency for out long-term direction.
>>
>> Am I right that it's as simple as executing
>>
>> $ svn propget svn:externals geronimo
>> openejb https://svn.codehaus.org/openejb/trunk/openejb2
>>
>> ?
>>
>> That seems to be an interim yet elegant solution. It's a bug fix so no
>> need to RTC it.
>>
>>> --jason
>>
>> Jacek
>>
>> --
>> Jacek Laskowski
>> http://www.laskowski.net.pl
>
Re: M2 Issues and Actions
Posted by Bill Dudney <bd...@apache.org>.
Hi Jacek,
Yep just edit the svn:externals property on geronimo and you are
done :-)
TTFN,
Bill Dudney
MyFaces - http://myfaces.apache.org
Cayenne - http://incubator.apache.org/projects/cayenne.html
On Jun 29, 2006, at 3:40 PM, Jacek Laskowski wrote:
> On 6/29/06, Jason Dillon <ja...@planet57.com> wrote:
>> Using svn:externals is probably the easiest way to the the openejb
>> sources included for use in a m2 build w/o needing the user to run
>> `maven -o m:co` or run `svn co ...` directly yo pull the sources for
>> the build.
>>
>> I think this is the best short-term solution to the openejb
>> integration issue. I would like to stress that we should eventually
>> try to remove this source-level dependency for out long-term
>> direction.
>
> Am I right that it's as simple as executing
>
> $ svn propget svn:externals geronimo
> openejb https://svn.codehaus.org/openejb/trunk/openejb2
>
> ?
>
> That seems to be an interim yet elegant solution. It's a bug fix so no
> need to RTC it.
>
>> --jason
>
> Jacek
>
> --
> Jacek Laskowski
> http://www.laskowski.net.pl
Re: M2 Issues and Actions
Posted by Jacek Laskowski <ja...@laskowski.net.pl>.
On 6/29/06, Jason Dillon <ja...@planet57.com> wrote:
> Using svn:externals is probably the easiest way to the the openejb
> sources included for use in a m2 build w/o needing the user to run
> `maven -o m:co` or run `svn co ...` directly yo pull the sources for
> the build.
>
> I think this is the best short-term solution to the openejb
> integration issue. I would like to stress that we should eventually
> try to remove this source-level dependency for out long-term direction.
Am I right that it's as simple as executing
$ svn propget svn:externals geronimo
openejb https://svn.codehaus.org/openejb/trunk/openejb2
?
That seems to be an interim yet elegant solution. It's a bug fix so no
need to RTC it.
> --jason
Jacek
--
Jacek Laskowski
http://www.laskowski.net.pl
Re: M2 Issues and Actions
Posted by Jason Dillon <ja...@planet57.com>.
Using svn:externals is probably the easiest way to the the openejb
sources included for use in a m2 build w/o needing the user to run
`maven -o m:co` or run `svn co ...` directly yo pull the sources for
the build.
I think this is the best short-term solution to the openejb
integration issue. I would like to stress that we should eventually
try to remove this source-level dependency for out long-term direction.
--jason
On Jun 29, 2006, at 12:30 PM, Bill Dudney wrote:
>> Or use svn:externals ( http://svnbook.red-bean.com/nightly/en/svn-
>> book.html#svn.advanced.externals ) to force SVN to check out the
>> openejb tree when Geronimo is checked out. Would need to have
>> users svn up in the openejb tree from time to time though, as last
>> I checked svn:externals are ignored when the local working space
>> is updated.
>
> just fyi, 'svn checkout' will update through an external but 'svn
> checkin' will not. We use them on myfaces, they work well.
>
> TTFN,
>
> Bill Dudney
> MyFaces - http://myfaces.apache.org
> Cayenne - http://incubator.apache.org/projects/cayenne.html
>
>
Re: M2 Issues and Actions
Posted by Bill Dudney <bd...@apache.org>.
> Or use svn:externals ( http://svnbook.red-bean.com/nightly/en/svn-
> book.html#svn.advanced.externals ) to force SVN to check out the
> openejb tree when Geronimo is checked out. Would need to have
> users svn up in the openejb tree from time to time though, as last
> I checked svn:externals are ignored when the local working space is
> updated.
just fyi, 'svn checkout' will update through an external but 'svn
checkin' will not. We use them on myfaces, they work well.
TTFN,
Bill Dudney
MyFaces - http://myfaces.apache.org
Cayenne - http://incubator.apache.org/projects/cayenne.html
Re: M2 Issues and Actions
Posted by Jacek Laskowski <ja...@laskowski.net.pl>.
On 6/30/06, Jason Dillon <ja...@planet57.com> wrote:
> BUT the point that I was making was that Maven must resolve the
> plugin before the build commences... that means that the plugin must
> exist in a repository (or cache) already, and that is the version
> that will be used for the current build cycle... NOT the plugin that
> will be compiled and installed as part of the current build.
>
> Therefor the current build will always use the version of the plugin
> that was built BEFORE the build started, NOT the version that is
> actually getting built.
I have never thought about it, but it sounds *utterly* possible!
Astonishing! I'm so surprised that I couldn't resist and ask a
question about it in the Maven user mailing list. I'm awaiting their
response hoping there's an elegant solution to it (not a workaround).
There must be a solution.
> --jason
Jacek
--
Jacek Laskowski
http://www.laskowski.net.pl
Re: M2 Issues and Actions
Posted by Jacek Laskowski <ja...@laskowski.net.pl>.
On 7/3/06, anita kulshreshtha <a_...@yahoo.com> wrote:
> I ran a test. A totally bogus plugin will not work, but a plugin
> with correctly defined component.xml will work. Maven indeed uses the
> plugin that was built (see the message below). If we want to use
> SNAPSHOT versions for the plugin, we can create a skeletal dummy plugin
> (s) and publish it. And the build will work like charm with just 'mvn'!
> If we want to use numbered versions like M1, we need multi step
> build. Whenever the version is changed we will have to use 'mvn' more
> than once to get a full build.
Hi Anita,
How does it apply to what Jason's working on in GERONIMO-2161? I think
Jason has provided us a good solution for the issue - his latest patch
http://issues.apache.org/jira/browse/GERONIMO-2161 should do the
trick. I couldn't test it out as it blew out with
Error assembling WAR: Deployment descriptor:
c:\oss\GERONIMO-2082-2161\applications\demo\target\demo-1.2-SNAPSHOT\WEB-INF\web.xml
does not exist.
which seemed to me was not strictly related to the issue in question.
(I've just noticed there's a brand new patch - on to testing it out)
> Anita
Jacek
--
Jacek Laskowski
http://www.laskowski.net.pl
Re: M2 Issues and Actions
Posted by Jason Dillon <ja...@planet57.com>.
Sure, I was going to add that, as well as update the README.txt...
pending approval of the changes.
That script would just facilitate the multi-stage build... and is not
intended to be a replacement for invoking mvn directly.
BUT, we can use build[.bat] to provide users with a one command
method to execute a full build.
--jason
On Jul 1, 2006, at 2:58 AM, Aaron Mulder wrote:
> Call me crazy, but cant we have a build.bat and build.sh in the root
> directory that executes the multi-stage builds (modules, plugins,
> OpenEJB if present, apps, assemblies, etc.)?
>
> Thanks,
> Aaron
>
> On 6/30/06, Jason Dillon <ja...@planet57.com> wrote:
>> I also think we need another pre-stage that will build a few tiny
>> extensions used by the other stages. Specifically a test-config
>> module that sets up a common log4j.properties that is used by all
>> tests. When we get a site build running then we also will need
>> something similar for clover and checkstyle and other plugins.
>>
>> NOTE: This can be a pre-stage or can be the start of the separate
>> build-support (or whatever we call it) tree, which will contain the
>> standalone plugins and other modules that our builds need to
>> function.
>>
>> --jason
>>
>>
>> > So, my proposed build procedure:
>> >
>> > build modules + plugins
>> > go somewhere else and build openejb
>> > build apps + configs + assemblies
>> >
>> > The proposal of using snapshots of openejb from a repo prevents you
>> > from doing a clean build and finding out that in fact you created a
>> > problem in either openejb or configs/assembly.
>> >
>> > This 3 step process will prevent us from interspersing the modules
>> > and configs builds which might be highly desirable to make our
>> > dependency tracking the same as the maven dependency tracking.
>> > Cant get everything :-(
>> >
>> > thanks
>> > david jencks
>> >
>> >>
>> >> --jason
>> >>
>> >>
>> >
>>
>>
Re: M2 Issues and Actions
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
Call me crazy, but cant we have a build.bat and build.sh in the root
directory that executes the multi-stage builds (modules, plugins,
OpenEJB if present, apps, assemblies, etc.)?
Thanks,
Aaron
On 6/30/06, Jason Dillon <ja...@planet57.com> wrote:
> I also think we need another pre-stage that will build a few tiny
> extensions used by the other stages. Specifically a test-config
> module that sets up a common log4j.properties that is used by all
> tests. When we get a site build running then we also will need
> something similar for clover and checkstyle and other plugins.
>
> NOTE: This can be a pre-stage or can be the start of the separate
> build-support (or whatever we call it) tree, which will contain the
> standalone plugins and other modules that our builds need to function.
>
> --jason
>
>
> > So, my proposed build procedure:
> >
> > build modules + plugins
> > go somewhere else and build openejb
> > build apps + configs + assemblies
> >
> > The proposal of using snapshots of openejb from a repo prevents you
> > from doing a clean build and finding out that in fact you created a
> > problem in either openejb or configs/assembly.
> >
> > This 3 step process will prevent us from interspersing the modules
> > and configs builds which might be highly desirable to make our
> > dependency tracking the same as the maven dependency tracking.
> > Cant get everything :-(
> >
> > thanks
> > david jencks
> >
> >>
> >> --jason
> >>
> >>
> >
>
>
Re: M2 Issues and Actions
Posted by Jason Dillon <ja...@planet57.com>.
I also think we need another pre-stage that will build a few tiny
extensions used by the other stages. Specifically a test-config
module that sets up a common log4j.properties that is used by all
tests. When we get a site build running then we also will need
something similar for clover and checkstyle and other plugins.
NOTE: This can be a pre-stage or can be the start of the separate
build-support (or whatever we call it) tree, which will contain the
standalone plugins and other modules that our builds need to function.
--jason
> So, my proposed build procedure:
>
> build modules + plugins
> go somewhere else and build openejb
> build apps + configs + assemblies
>
> The proposal of using snapshots of openejb from a repo prevents you
> from doing a clean build and finding out that in fact you created a
> problem in either openejb or configs/assembly.
>
> This 3 step process will prevent us from interspersing the modules
> and configs builds which might be highly desirable to make our
> dependency tracking the same as the maven dependency tracking.
> Cant get everything :-(
>
> thanks
> david jencks
>
>>
>> --jason
>>
>>
>
Re: M2 Issues and Actions
Posted by Jason Dillon <ja...@planet57.com>.
>> BUT the point that I was making was that Maven must resolve the
>> plugin before the build commences... that means that the plugin
>> must exist in a repository (or cache) already, and that is the
>> version that will be used for the current build cycle... NOT the
>> plugin that will be compiled and installed as part of the current
>> build.
>
> The point I've been trying to make is that this feature of maven is
> a showstopper for use of maven in any framework type project. We
> can work around it, but it's a ridiculous limitation in maven.
> Yes, I should take it up with the maven team, but that takes time
> and energy, both of which are in short supply for me right now.
But you know that w/m1 that building the plugin and then using it in
the same build is also a massive hack.
> Since the packaging plugin is a way of running some g. core code
> from maven, not having it use the just built core code in a build
> makes me extremely uneasy. I would prefer to split the build up
> into segments that must be run separately.
We maybe able to write a plugin to help facilitate these segments if
nothing already exists... allowing one command to build, and under
the covers it runs a set of m2 builds.
> Since I am the only person who want to have a complete build of all
> the stuff that depends on geronimo and goes into the assemblies
> (I'm referring to building openejb as part of the g build), this
> really shouldn't annoy anyone.
>
> So, my proposed build procedure:
>
> build modules + plugins
> go somewhere else and build openejb
> build apps + configs + assemblies
I like this sans the openejb bits... though if you want to build
openejb like this I don't see that it is a problem as long as it is
optional.
> The proposal of using snapshots of openejb from a repo prevents you
> from doing a clean build and finding out that in fact you created a
> problem in either openejb or configs/assembly.
Not sure what you mean... :-(
--jason
Re: M2 Issues and Actions
Posted by David Jencks <da...@yahoo.com>.
On Jun 30, 2006, at 11:00 AM, Jason Dillon wrote:
>>> While this may work most of the time, it is not ideal as when making
>>> changes to plugins, users will be mystified when those changes are
>>> not used on the first build.
>>
>> This is not true. The plugin is *not* used before it is built. The
>> problem is that maven does not even start the build until it has
>> downloaded all the plugins. Even a dummy plugin would work.
>
> Um... it is completely true. I am aware that the plugin is not
> used before it is built.
>
> BUT the point that I was making was that Maven must resolve the
> plugin before the build commences... that means that the plugin
> must exist in a repository (or cache) already, and that is the
> version that will be used for the current build cycle... NOT the
> plugin that will be compiled and installed as part of the current
> build.
The point I've been trying to make is that this feature of maven is a
showstopper for use of maven in any framework type project. We can
work around it, but it's a ridiculous limitation in maven. Yes, I
should take it up with the maven team, but that takes time and
energy, both of which are in short supply for me right now.
>
> Therefor the current build will always use the version of the
> plugin that was built BEFORE the build started, NOT the version
> that is actually getting built.
>
> This is why I suggested that the plugin either be part of another
> project (detached from the main build) or as part of a bootstrap
> phase that is executed before the main build cycle.
Since the packaging plugin is a way of running some g. core code from
maven, not having it use the just built core code in a build makes me
extremely uneasy. I would prefer to split the build up into segments
that must be run separately. Since I am the only person who want to
have a complete build of all the stuff that depends on geronimo and
goes into the assemblies (I'm referring to building openejb as part
of the g build), this really shouldn't annoy anyone.
So, my proposed build procedure:
build modules + plugins
go somewhere else and build openejb
build apps + configs + assemblies
The proposal of using snapshots of openejb from a repo prevents you
from doing a clean build and finding out that in fact you created a
problem in either openejb or configs/assembly.
This 3 step process will prevent us from interspersing the modules
and configs builds which might be highly desirable to make our
dependency tracking the same as the maven dependency tracking. Cant
get everything :-(
thanks
david jencks
>
> --jason
>
>
Re: M2 Issues and Actions
Posted by Jason Dillon <ja...@planet57.com>.
FYI... issue opened to fix the problem using extensions here:
http://jira.codehaus.org/browse/MNG-1911
And you were right... m2 will reload the plugin :-)
--jason
On Jul 3, 2006, at 3:26 PM, anita kulshreshtha wrote:
> I used our project. Here are the steps -
> 1. add a print statements to say PackageBuilderShellMojo.
> 2. To make this test go faster comment out modules, applications from
> the parent pom.
> 3. use mvn clean install
> The .m2 Repo already has a packaging plugin with version 1.2.0. So
> maven happily builds. After the plugin is built, the configs are
> built.
> That is when the "reloading plugin container ...." message appears.
> You
> should see the message you added to the packaging plugin. The message
> should appear in all the configs except may be gbean-deployer. The
> gbean-delpoyer config is a special case, you must make sure that the
> new statement is executed.
>
> Thanks
> Anita
>
>
> --- Jason Dillon <ja...@planet57.com> wrote:
>
>> Do you have an simple example project that implements the build and
>> use of the plugin in the same cycle that I can peek at?
>>
>> --jason
>>
>>
>> On Jul 3, 2006, at 5:59 AM, anita kulshreshtha wrote:
>>
>>> inline..
>>>
>>> --- Jason Dillon <ja...@planet57.com> wrote:
>>>
>>>>>> While this may work most of the time, it is not ideal as when
>>>> making
>>>>>> changes to plugins, users will be mystified when those changes
>> are
>>>>>> not used on the first build.
>>>>>
>>>>> This is not true. The plugin is *not* used before it is built.
>>>> The
>>>>> problem is that maven does not even start the build until it has
>>>>> downloaded all the plugins. Even a dummy plugin would work.
>>>>
>>>> Um... it is completely true. I am aware that the plugin is not
>> used
>>>>
>>>> before it is built.
>>>>
>>>> BUT the point that I was making was that Maven must resolve the
>>>> plugin before the build commences... that means that the plugin
>> must
>>>>
>>>> exist in a repository (or cache) already, and that is the version
>>>> that will be used for the current build cycle... NOT the plugin
>> that
>>>>
>>>> will be compiled and installed as part of the current build.
>>>>
>>>> Therefor the current build will always use the version of the
>> plugin
>>>>
>>>> that was built BEFORE the build started, NOT the version that is
>>>> actually getting built.
>>>
>>> I ran a test. A totally bogus plugin will not work, but a
>> plugin
>>> with correctly defined component.xml will work. Maven indeed uses
>> the
>>> plugin that was built (see the message below). If we want to use
>>> SNAPSHOT versions for the plugin, we can create a skeletal dummy
>>> plugin
>>> (s) and publish it. And the build will work like charm with just
>>> 'mvn'!
>>> If we want to use numbered versions like M1, we need multi step
>>> build. Whenever the version is changed we will have to use 'mvn'
>> more
>>> than once to get a full build.
>>>
>>> Thanks
>>> Anita
>>>
>>> m
>>> [INFO]
>>>
>>
> ----------------------------------------------------------------------
>>
>>> ------
>>> [INFO] Building Geronimo Configuration for performing service
>>> deployments
>>> [INFO] task-segment: [clean, install]
>>> [INFO]
>>>
>>
> ----------------------------------------------------------------------
>>
>>> ------
>>> [INFO] Reloading plugin container for:
>>> org.apache.geronimo.plugins:geronimo-packaging-plugin. The pl
>>> ugin artifact has changed.
>>> [INFO] [clean:clean]
>>> [INFO] Deleting directory
>>>
>> D:\anita\geronimo\geronimo-1.2\configs\geronimo-gbean-deployer\target
>>> [INFO] Deleting directory
>>> D:\anita\geronimo\geronimo-1.2\configs\geronimo-gbean-deployer
>>> \target\clas
>>> ses
>>> [INFO] Deleting directory
>>> D:\anita\geronimo\geronimo-1.2\configs\geronimo-gbean-deployer
>>> \target\test
>>> -classes
>>>>
>>>> This is why I suggested that the plugin either be part of another
>>>> project (detached from the main build) or as part of a bootstrap
>>>> phase that is executed before the main build cycle.
>>>>
>>>> --jason
>>>>
>>>>
>>>>
>>>
>>>
>>> __________________________________________________
>>> Do You Yahoo!?
>>> Tired of spam? Yahoo! Mail has the best spam protection around
>>> http://mail.yahoo.com
>>
>>
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
Re: M2 Issues and Actions
Posted by anita kulshreshtha <a_...@yahoo.com>.
I used our project. Here are the steps -
1. add a print statements to say PackageBuilderShellMojo.
2. To make this test go faster comment out modules, applications from
the parent pom.
3. use mvn clean install
The .m2 Repo already has a packaging plugin with version 1.2.0. So
maven happily builds. After the plugin is built, the configs are built.
That is when the "reloading plugin container ...." message appears. You
should see the message you added to the packaging plugin. The message
should appear in all the configs except may be gbean-deployer. The
gbean-delpoyer config is a special case, you must make sure that the
new statement is executed.
Thanks
Anita
--- Jason Dillon <ja...@planet57.com> wrote:
> Do you have an simple example project that implements the build and
> use of the plugin in the same cycle that I can peek at?
>
> --jason
>
>
> On Jul 3, 2006, at 5:59 AM, anita kulshreshtha wrote:
>
> > inline..
> >
> > --- Jason Dillon <ja...@planet57.com> wrote:
> >
> >>>> While this may work most of the time, it is not ideal as when
> >> making
> >>>> changes to plugins, users will be mystified when those changes
> are
> >>>> not used on the first build.
> >>>
> >>> This is not true. The plugin is *not* used before it is built.
> >> The
> >>> problem is that maven does not even start the build until it has
> >>> downloaded all the plugins. Even a dummy plugin would work.
> >>
> >> Um... it is completely true. I am aware that the plugin is not
> used
> >>
> >> before it is built.
> >>
> >> BUT the point that I was making was that Maven must resolve the
> >> plugin before the build commences... that means that the plugin
> must
> >>
> >> exist in a repository (or cache) already, and that is the version
> >> that will be used for the current build cycle... NOT the plugin
> that
> >>
> >> will be compiled and installed as part of the current build.
> >>
> >> Therefor the current build will always use the version of the
> plugin
> >>
> >> that was built BEFORE the build started, NOT the version that is
> >> actually getting built.
> >
> > I ran a test. A totally bogus plugin will not work, but a
> plugin
> > with correctly defined component.xml will work. Maven indeed uses
> the
> > plugin that was built (see the message below). If we want to use
> > SNAPSHOT versions for the plugin, we can create a skeletal dummy
> > plugin
> > (s) and publish it. And the build will work like charm with just
> > 'mvn'!
> > If we want to use numbered versions like M1, we need multi step
> > build. Whenever the version is changed we will have to use 'mvn'
> more
> > than once to get a full build.
> >
> > Thanks
> > Anita
> >
> > m
> > [INFO]
> >
>
----------------------------------------------------------------------
>
> > ------
> > [INFO] Building Geronimo Configuration for performing service
> > deployments
> > [INFO] task-segment: [clean, install]
> > [INFO]
> >
>
----------------------------------------------------------------------
>
> > ------
> > [INFO] Reloading plugin container for:
> > org.apache.geronimo.plugins:geronimo-packaging-plugin. The pl
> > ugin artifact has changed.
> > [INFO] [clean:clean]
> > [INFO] Deleting directory
> >
> D:\anita\geronimo\geronimo-1.2\configs\geronimo-gbean-deployer\target
> > [INFO] Deleting directory
> > D:\anita\geronimo\geronimo-1.2\configs\geronimo-gbean-deployer
> > \target\clas
> > ses
> > [INFO] Deleting directory
> > D:\anita\geronimo\geronimo-1.2\configs\geronimo-gbean-deployer
> > \target\test
> > -classes
> >>
> >> This is why I suggested that the plugin either be part of another
> >> project (detached from the main build) or as part of a bootstrap
> >> phase that is executed before the main build cycle.
> >>
> >> --jason
> >>
> >>
> >>
> >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam? Yahoo! Mail has the best spam protection around
> > http://mail.yahoo.com
>
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: M2 Issues and Actions
Posted by Jason Dillon <ja...@planet57.com>.
Do you have an simple example project that implements the build and
use of the plugin in the same cycle that I can peek at?
--jason
On Jul 3, 2006, at 5:59 AM, anita kulshreshtha wrote:
> inline..
>
> --- Jason Dillon <ja...@planet57.com> wrote:
>
>>>> While this may work most of the time, it is not ideal as when
>> making
>>>> changes to plugins, users will be mystified when those changes are
>>>> not used on the first build.
>>>
>>> This is not true. The plugin is *not* used before it is built.
>> The
>>> problem is that maven does not even start the build until it has
>>> downloaded all the plugins. Even a dummy plugin would work.
>>
>> Um... it is completely true. I am aware that the plugin is not used
>>
>> before it is built.
>>
>> BUT the point that I was making was that Maven must resolve the
>> plugin before the build commences... that means that the plugin must
>>
>> exist in a repository (or cache) already, and that is the version
>> that will be used for the current build cycle... NOT the plugin that
>>
>> will be compiled and installed as part of the current build.
>>
>> Therefor the current build will always use the version of the plugin
>>
>> that was built BEFORE the build started, NOT the version that is
>> actually getting built.
>
> I ran a test. A totally bogus plugin will not work, but a plugin
> with correctly defined component.xml will work. Maven indeed uses the
> plugin that was built (see the message below). If we want to use
> SNAPSHOT versions for the plugin, we can create a skeletal dummy
> plugin
> (s) and publish it. And the build will work like charm with just
> 'mvn'!
> If we want to use numbered versions like M1, we need multi step
> build. Whenever the version is changed we will have to use 'mvn' more
> than once to get a full build.
>
> Thanks
> Anita
>
> m
> [INFO]
> ----------------------------------------------------------------------
> ------
> [INFO] Building Geronimo Configuration for performing service
> deployments
> [INFO] task-segment: [clean, install]
> [INFO]
> ----------------------------------------------------------------------
> ------
> [INFO] Reloading plugin container for:
> org.apache.geronimo.plugins:geronimo-packaging-plugin. The pl
> ugin artifact has changed.
> [INFO] [clean:clean]
> [INFO] Deleting directory
> D:\anita\geronimo\geronimo-1.2\configs\geronimo-gbean-deployer\target
> [INFO] Deleting directory
> D:\anita\geronimo\geronimo-1.2\configs\geronimo-gbean-deployer
> \target\clas
> ses
> [INFO] Deleting directory
> D:\anita\geronimo\geronimo-1.2\configs\geronimo-gbean-deployer
> \target\test
> -classes
>>
>> This is why I suggested that the plugin either be part of another
>> project (detached from the main build) or as part of a bootstrap
>> phase that is executed before the main build cycle.
>>
>> --jason
>>
>>
>>
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
Re: M2 Issues and Actions
Posted by Jason Dillon <ja...@planet57.com>.
Did want happens when you `mvn clean` after a clean check out and
have an empty repository?
--jason
On Jul 3, 2006, at 5:59 AM, anita kulshreshtha wrote:
> inline..
>
> --- Jason Dillon <ja...@planet57.com> wrote:
>
>>>> While this may work most of the time, it is not ideal as when
>> making
>>>> changes to plugins, users will be mystified when those changes are
>>>> not used on the first build.
>>>
>>> This is not true. The plugin is *not* used before it is built.
>> The
>>> problem is that maven does not even start the build until it has
>>> downloaded all the plugins. Even a dummy plugin would work.
>>
>> Um... it is completely true. I am aware that the plugin is not used
>>
>> before it is built.
>>
>> BUT the point that I was making was that Maven must resolve the
>> plugin before the build commences... that means that the plugin must
>>
>> exist in a repository (or cache) already, and that is the version
>> that will be used for the current build cycle... NOT the plugin that
>>
>> will be compiled and installed as part of the current build.
>>
>> Therefor the current build will always use the version of the plugin
>>
>> that was built BEFORE the build started, NOT the version that is
>> actually getting built.
>
> I ran a test. A totally bogus plugin will not work, but a plugin
> with correctly defined component.xml will work. Maven indeed uses the
> plugin that was built (see the message below). If we want to use
> SNAPSHOT versions for the plugin, we can create a skeletal dummy
> plugin
> (s) and publish it. And the build will work like charm with just
> 'mvn'!
> If we want to use numbered versions like M1, we need multi step
> build. Whenever the version is changed we will have to use 'mvn' more
> than once to get a full build.
>
> Thanks
> Anita
>
> m
> [INFO]
> ----------------------------------------------------------------------
> ------
> [INFO] Building Geronimo Configuration for performing service
> deployments
> [INFO] task-segment: [clean, install]
> [INFO]
> ----------------------------------------------------------------------
> ------
> [INFO] Reloading plugin container for:
> org.apache.geronimo.plugins:geronimo-packaging-plugin. The pl
> ugin artifact has changed.
> [INFO] [clean:clean]
> [INFO] Deleting directory
> D:\anita\geronimo\geronimo-1.2\configs\geronimo-gbean-deployer\target
> [INFO] Deleting directory
> D:\anita\geronimo\geronimo-1.2\configs\geronimo-gbean-deployer
> \target\clas
> ses
> [INFO] Deleting directory
> D:\anita\geronimo\geronimo-1.2\configs\geronimo-gbean-deployer
> \target\test
> -classes
>>
>> This is why I suggested that the plugin either be part of another
>> project (detached from the main build) or as part of a bootstrap
>> phase that is executed before the main build cycle.
>>
>> --jason
>>
>>
>>
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
Re: M2 Issues and Actions
Posted by anita kulshreshtha <a_...@yahoo.com>.
inline..
--- Jason Dillon <ja...@planet57.com> wrote:
> >> While this may work most of the time, it is not ideal as when
> making
> >> changes to plugins, users will be mystified when those changes are
> >> not used on the first build.
> >
> > This is not true. The plugin is *not* used before it is built.
> The
> > problem is that maven does not even start the build until it has
> > downloaded all the plugins. Even a dummy plugin would work.
>
> Um... it is completely true. I am aware that the plugin is not used
>
> before it is built.
>
> BUT the point that I was making was that Maven must resolve the
> plugin before the build commences... that means that the plugin must
>
> exist in a repository (or cache) already, and that is the version
> that will be used for the current build cycle... NOT the plugin that
>
> will be compiled and installed as part of the current build.
>
> Therefor the current build will always use the version of the plugin
>
> that was built BEFORE the build started, NOT the version that is
> actually getting built.
I ran a test. A totally bogus plugin will not work, but a plugin
with correctly defined component.xml will work. Maven indeed uses the
plugin that was built (see the message below). If we want to use
SNAPSHOT versions for the plugin, we can create a skeletal dummy plugin
(s) and publish it. And the build will work like charm with just 'mvn'!
If we want to use numbered versions like M1, we need multi step
build. Whenever the version is changed we will have to use 'mvn' more
than once to get a full build.
Thanks
Anita
m
[INFO]
----------------------------------------------------------------------------
[INFO] Building Geronimo Configuration for performing service
deployments
[INFO] task-segment: [clean, install]
[INFO]
----------------------------------------------------------------------------
[INFO] Reloading plugin container for:
org.apache.geronimo.plugins:geronimo-packaging-plugin. The pl
ugin artifact has changed.
[INFO] [clean:clean]
[INFO] Deleting directory
D:\anita\geronimo\geronimo-1.2\configs\geronimo-gbean-deployer\target
[INFO] Deleting directory
D:\anita\geronimo\geronimo-1.2\configs\geronimo-gbean-deployer\target\clas
ses
[INFO] Deleting directory
D:\anita\geronimo\geronimo-1.2\configs\geronimo-gbean-deployer\target\test
-classes
>
> This is why I suggested that the plugin either be part of another
> project (detached from the main build) or as part of a bootstrap
> phase that is executed before the main build cycle.
>
> --jason
>
>
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: M2 Issues and Actions
Posted by Jason Dillon <ja...@planet57.com>.
>> While this may work most of the time, it is not ideal as when making
>> changes to plugins, users will be mystified when those changes are
>> not used on the first build.
>
> This is not true. The plugin is *not* used before it is built. The
> problem is that maven does not even start the build until it has
> downloaded all the plugins. Even a dummy plugin would work.
Um... it is completely true. I am aware that the plugin is not used
before it is built.
BUT the point that I was making was that Maven must resolve the
plugin before the build commences... that means that the plugin must
exist in a repository (or cache) already, and that is the version
that will be used for the current build cycle... NOT the plugin that
will be compiled and installed as part of the current build.
Therefor the current build will always use the version of the plugin
that was built BEFORE the build started, NOT the version that is
actually getting built.
This is why I suggested that the plugin either be part of another
project (detached from the main build) or as part of a bootstrap
phase that is executed before the main build cycle.
--jason
Re: M2 Issues and Actions
Posted by anita kulshreshtha <a_...@yahoo.com>.
inline..
--- Jason Dillon <ja...@planet57.com> wrote:
> > 2. Spec Jars -
> > The geronimo spec jars need to be published along with the poms.
> > This was supposed to happen soon after the 1.1 release.
And it has happened. Thanks!
>
> Are there any issues with this?
>
> Does this have any relation to the proposed reorg of the specs into
> multiple trunks?
>
>
> > 4. Maven does not allow building a plugin and a module if the
> module
> > uses the plugin in the same build. As a result the first time build
> is
> > a 3 step process. Jason suggested "IMO we should have a completely
> > separate tree for our build support tools. And once the plugins
> are
> > stable we release them, until they are stable we make regular
> > snaps, so
> > that the main tree(s) can just build w/o having to worry about
> > building
> > plugins first."
>
> I'm not sure how easy this is going to be...
>
> We many need to introduce a bootstrap phase to build a few modules
> and a plugin or two and then run through the full build.
>
> Not terribly ideal IMO, but probably the easiest way to get the m2
> build functional in the least amount of time. I hope that we can
> eventually eliminate the need for the bootstrap, but from what I
> understand so far this is not going to be something we can do easily
>
> in a short amount of time (defs not with the RTC muck).
>
>
> > We should start publishing SNAPSHOTs ASAP to solve this
> problem,
> > This is very user friendly. Once we have assembled our first full
> > server, we can start thinking of reorganizing the source tree.
>
> While this may work most of the time, it is not ideal as when making
>
> changes to plugins, users will be mystified when those changes are
> not used on the first build.
This is not true. The plugin is *not* used before it is built. The
problem is that maven does not even start the build until it has
downloaded all the plugins. Even a dummy plugin would work.
>
> I'd prefer to minimize the utilization of remote maven
> repositories... not increase them. IMO remote repository is growing
>
> to become more and more of a build anit-pattern.
>
>
> > 5. checking out openejb - In M1 we could define goals like m:co, it
> is
> > not possible to do this in M2. There is no way to specify
> > executions in
> > the top level pom that are not inherited by the children. And we
> must
> > resort to checking out each module and building it!
>
> There are a few more options here. A module that exists to solely
> check out openejb and then run the openejb build as a part of our
> build. This can be easily facilitated with antrun and some well
> placed dependencies.
>
> Or use svn:externals ( http://svnbook.red-bean.com/nightly/en/svn-
> book.html#svn.advanced.externals ) to force SVN to check out the
> openejb tree when Geronimo is checked out. Would need to have users
>
> svn up in the openejb tree from time to time though, as last I
> checked svn:externals are ignored when the local working space is
> updated.
Jacek is working on this. Thanks Jacek!
>
>
> > Currently we ask the user to use svn command to checkout openejb.
>
> What are those exact commands that we ask them to use?
http://cwiki.apache.org/confluence/display/GMOxDEV/Building+Apache+Geronimo+with+Maven+2
Thanks
Anita
>
> --jason
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: M2 Issues and Actions
Posted by Jason Dillon <ja...@planet57.com>.
> 2. Spec Jars -
> The geronimo spec jars need to be published along with the poms.
> This was supposed to happen soon after the 1.1 release.
Are there any issues with this?
Does this have any relation to the proposed reorg of the specs into
multiple trunks?
> 4. Maven does not allow building a plugin and a module if the module
> uses the plugin in the same build. As a result the first time build is
> a 3 step process. Jason suggested "IMO we should have a completely
> separate tree for our build support tools. And once the plugins are
> stable we release them, until they are stable we make regular
> snaps, so
> that the main tree(s) can just build w/o having to worry about
> building
> plugins first."
I'm not sure how easy this is going to be...
We many need to introduce a bootstrap phase to build a few modules
and a plugin or two and then run through the full build.
Not terribly ideal IMO, but probably the easiest way to get the m2
build functional in the least amount of time. I hope that we can
eventually eliminate the need for the bootstrap, but from what I
understand so far this is not going to be something we can do easily
in a short amount of time (defs not with the RTC muck).
> We should start publishing SNAPSHOTs ASAP to solve this problem,
> This is very user friendly. Once we have assembled our first full
> server, we can start thinking of reorganizing the source tree.
While this may work most of the time, it is not ideal as when making
changes to plugins, users will be mystified when those changes are
not used on the first build.
I'd prefer to minimize the utilization of remote maven
repositories... not increase them. IMO remote repository is growing
to become more and more of a build anit-pattern.
> 5. checking out openejb - In M1 we could define goals like m:co, it is
> not possible to do this in M2. There is no way to specify
> executions in
> the top level pom that are not inherited by the children. And we must
> resort to checking out each module and building it!
There are a few more options here. A module that exists to solely
check out openejb and then run the openejb build as a part of our
build. This can be easily facilitated with antrun and some well
placed dependencies.
Or use svn:externals ( http://svnbook.red-bean.com/nightly/en/svn-
book.html#svn.advanced.externals ) to force SVN to check out the
openejb tree when Geronimo is checked out. Would need to have users
svn up in the openejb tree from time to time though, as last I
checked svn:externals are ignored when the local working space is
updated.
> Currently we ask the user to use svn command to checkout openejb.
What are those exact commands that we ask them to use?
--jason
Re: M2 Issues and Actions
Posted by anita kulshreshtha <a_...@yahoo.com>.
Correction inline..
--- anita kulshreshtha <a_...@yahoo.com> wrote:
> Hi All,
> The M2 build work is continuing. Dain just updated the openejb
> trunk. Now we will be using openEJB 2.2
> http://issues.apache.org/jira/browse/GERONIMO-2152.
> The assembly plugin is under construction. Here are the issues facing
> us. I am also reproducing the suggested remedies for some of these.
>
>
> 1. xmlbeans-maven-plugin and xbean pom -
> The issue is described here
> http://issues.apache.org/jira/browse/GERONIMO-2082
> David Jencks has submitted the patches and has been working with
> the
> xmlbeans team. See
>
http://www.nabble.com/Unable-to-build-using-m2-tf1846875.html#a5041106
The correct link is -
http://www.nabble.com/Re%3A-Unable-to-build-using-m2-p5069519.html
>
>
> 2. Spec Jars -
> The geronimo spec jars need to be published along with the poms.
> This was supposed to happen soon after the 1.1 release.
>
> 3. openejb - The openejb build should use geronimo jars that come
> from
> o.a.g groupId. Hence it is necessary to build openejb. Until now
> v_2.1
> was used, now we are switching to 2.2. We should publish snapshots of
> these jars too. This will obviate the need for building openejb.
>
> 4. Maven does not allow building a plugin and a module if the
> module
> uses the plugin in the same build. As a result the first time build
> is
> a 3 step process. Jason suggested "IMO we should have a completely
> separate tree for our build support tools. And once the plugins are
> stable we release them, until they are stable we make regular snaps,
> so
> that the main tree(s) can just build w/o having to worry about
> building
> plugins first."
> We should start publishing SNAPSHOTs ASAP to solve this problem,
> This is very user friendly. Once we have assembled our first full
> server, we can start thinking of reorganizing the source tree.
> 5. checking out openejb - In M1 we could define goals like m:co, it
> is
> not possible to do this in M2. There is no way to specify executions
> in
> the top level pom that are not inherited by the children. And we must
> resort to checking out each module and building it! Currently we ask
> the user to use svn command to checkout openejb. The other solution
> is
> have the 'support tool tree' which will provide commands for checking
> out openejb. If the latest openejb snapshots are always available, we
> can eliminate openejb from our build.
> We will be documenting any new issues here
>
http://cwiki.apache.org/confluence/display/geronimo/Building+Geronimo+with+Maven+2
> thanks for your patience!
>
> Thanks
> Anita
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com