-
1. Re: Reinstate the top level build project
kconner Apr 3, 2007 5:58 PM (in response to adrian.brock)I have split the root pom into an aggregator (the new root) and a parent for inheritance. The parent pom is now specified in the build project.
Your projects will need to be updated from the root in order to pull in these changes. -
2. Re: Reinstate the top level build project
adrian.brock Apr 4, 2007 7:40 AM (in response to adrian.brock)"Kevin.Conner@jboss.com" wrote:
I have split the root pom into an aggregator (the new root) and a parent for inheritance.
That pom in the root still can't be updated/downloaded through eclipse or IDEA.
There is nowhere for them to put it.
What we really want anyway is multiple aggregator projects
so we can build the different possible releases of the microcontainer
1) Vanilla
2) MC + AOP
3) OSGi standalone
etc. -
3. Re: Reinstate the top level build project
kconner Apr 4, 2007 7:47 AM (in response to adrian.brock)In general you wouldn't need to update that one as all it specifies is the modules to include. Only if this list changes would it require updating.
Building multiple releases are probably better suited to profiles and/or assemblies and not multiple aggregators. -
4. Re: Reinstate the top level build project
alesj Apr 4, 2007 7:50 AM (in response to adrian.brock)"adrian@jboss.org" wrote:
What we really want anyway is multiple aggregator projects
so we can build the different possible releases of the microcontainer
1) Vanilla
2) MC + AOP
3) OSGi standalone
etc.
Linked: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=105285 -
5. Re: Reinstate the top level build project
adrian.brock Apr 4, 2007 8:10 AM (in response to adrian.brock)"Kevin.Conner@jboss.com" wrote:
In general you wouldn't need to update that one as all it specifies is the modules to include. Only if this list changes would it require updating.
But you at least need to check it out in the first place, unless you are going to build
each project individually. This goes back to the eclipse.psf stuff.
Basically, we only have command line support for getting the full microcontainer build
at the moment. -
6. Re: Reinstate the top level build project
kconner Apr 4, 2007 10:38 AM (in response to adrian.brock)"adrian@jboss.org" wrote:
But you at least need to check it out in the first place, unless you are going to build each project individually. This goes back to the eclipse.psf stuff.
But as I tried to say before, this is something than can be 'fixed' using subversion.
We can create separate locations in the repository which are responsible for checking out all the required folders, no need for eclipse.psf. -
7. Re: Reinstate the top level build project
adrian.brock Apr 4, 2007 11:06 AM (in response to adrian.brock)And as I explained before, if I'm working with eclipse, I want to use the features
the IDE provides.
Not shell out to a command line and find some magic incantation I need to download
and run (if I even trust such a script without reading it first :-).
Aside:
"I" is generic, meaning a normal user, not necessarily me.
One of the first things I open everyday is an xterm. :-)
In my case, the issue is the "multiple steps" when it should be:
file/import/eclipse-project-set <url-to-eclipse.psf>
job done.
My other issue is the currently redundant eclipse workspace I have to create
which is yet another set of manual steps :-(
Multiply the "multiple steps" for every project I work with on JBoss and
it is going to be a real pain next time I re-install my laptop to recreate my work environments. -
8. Re: Reinstate the top level build project
alesj Apr 4, 2007 11:11 AM (in response to adrian.brock)"adrian@jboss.org" wrote:
And as I explained before, if I'm working with eclipse
When finding a simple solution, don't forget us, humble IDEA users. ;-) -
9. Re: Reinstate the top level build project
kconner Apr 4, 2007 11:16 AM (in response to adrian.brock)Which is why I have been suggesting two things
- use subversion to partition the projects so that all IDEs can take advantage of it
- modify the maven build so that it creates the workspace
At present your suggestion will only ever work on eclipse and there are a number of people who do not use eclipse. If we start pushing this back into a generic jboss project then we can start having this generated automatically and support other IDEs at the same time.
We could even extend this to include any formatting/code verification rules.
Deployment could then become simply
- mvn co https://svn.jboss.org/repos/jbossas/projects/microcontainer/trunk/view/standalone
- mvn -PbuildEclipseWorkspace
- run eclipse
(or something similar) -
10. Re: Reinstate the top level build project
kconner Apr 4, 2007 11:18 AM (in response to adrian.brock)"alesj" wrote:
When finding a simple solution, don't forget us, humble IDEA users. ;-)
rofl. I believe there is a plugin to generate the IDEA setup as well :-) -
11. Re: Reinstate the top level build project
adrian.brock Apr 4, 2007 11:27 AM (in response to adrian.brock)"Kevin.Conner@jboss.com" wrote:
Deployment could then become simply
- mvn co https://svn.jboss.org/repos/jbossas/projects/microcontainer/trunk/view/standalone
- mvn -PbuildEclipseWorkspace
- run eclipse
(or something similar)
It's funny, but when I did the jbossbuild prototype (some ant plugins that made
the build declaritive), this was almost exactly how I had it working.
The steps were:
mkdir microcontainer
cd microcontainer
svn co https://svn.jboss.org/repos/jbossas/projects/microcontainer/trunk/build
svn co https://svn.jboss.org/repos/jbossas/trunk/tools
ant
Which would then internally
1) Spot your environment doesn't exist and download the rest (either from svn or the
repository), including creating ide files on the fly
2) Refork itself and do the main build
Sadly, I didn't have time to finish it, but that part did work. -
12. Re: Reinstate the top level build project
adrian.brock Apr 4, 2007 11:32 AM (in response to adrian.brock)"adrian@jboss.org" wrote:
1) Spot your environment doesn't exist and download the rest (either from svn or the
repository), including creating ide files on the fly
2) Refork itself and do the main build
You could also do a step zero which was to add a local.properties
to choose which of the project's dependencies you wanted as binary
and which as development source snaphots.
e.g. Imagine being able to develop jboss transactions and jboss appserver in the
same workspace using one main build file to rebuild everything.
e.g.2. Only rebuilding the jca project in the appserver, using the snapshot binaries
from the repository for the rest, instead of recompiling the whole thing all the time :-)