That would kick ass...
Still, I think we should become Maven contributors and extend Maven to
do this.
Adrian Brock wrote:
The problem I don't see addressed (and the main reason why I started
the jbossbuild prototype) is to have a top level which includes
multiple projects.
e.g. I wanted people to be able to do something like:
<build>
<component name="JBossAS" download="binary" quality="LastGoodTests">
<component name="EJB3" download="source"/>
</component>
<component name="Seam" download="source"/>
</build>
This would checkout the last binaries for JBossAS that passed the
testsuite (except EJB3 which is latest source) and also Seam.
You would then be able to build a Seam environment with just the
EJB3 and Seam sources.
i.e. the developer only has to worry about the problems with the
stuff he is working on, rather than figuring out why something
unrelated doesn't compile/work.
Instead, the jbossbuild project morphed into a mechanism to
download thirdparty binaries with buildmagic still used for
the main build.
On Thu, 2006-02-09 at 10:40, Scott M Stark wrote:
So after listening to the Maven2 webinar yesterday and talking with
Ryan, Ruel and Steve E as a lead, I don't see a good reason why we
shouldn't look to using maven2 as the core of the jbossbuild. The two
outstanding proof of concept issues I asked Ruel to look at are:
1. Source in the repository. A goal we have had is to be able to pull
down the source for a dependent component as part of a depdency
relationship. Maven2 has a weak notion of this but not one to the point
of actually being able to build the component artifacts from the
respository source.
2. Being able to create a plugin that does the equivalent of the
org.jboss.ant.util.graph.ComponentRefGraphLicenseVisitor which generates
the thirdparty-licenses.xml info.
Once its clear these can be done I don't have a reason to not move
jbossas to maven. If there are project leads that have not gone through
the webinar and thought about how your project could use maven its time
to do so. I'm still open to why maven should not be used, but given how
Ruel has been able to interact well with the maven community and lack of
progress on a custom jbossbuild, its going to be an uphill battle.
Although we can hack the existing project structure into maven,
switching seems like a good time to address inconsistencies in terms of
project structure to allow for better definition of project structure
such that unit tests, docs, and poorly maintained artifacts such as
thirdparty licenses and notices are just handled by build plugins.
Once we decide to jump off the maven2 cliff, defining this needs to be
the priority so that projects can move as desired, and qa can do the
work to move a project if needed.
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Scott Stark
VP Architecture & Technology
JBoss Inc.
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642
_______________________________________________
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
--
Bill Burke
Chief Architect
JBoss Inc.
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
