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
--
xxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss Inc.
xxxxxxxxxxxxxxxxxxxxxxxx
-------------------------------------------------------
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
