Copying from a separate thread....cause I thought I had deleted this
thread -- doh!
----
After thinking about this a little more, would it make sense to test
this under our svn so that the commit msgs are sent as usual and we
can keep an eye things. The term 'subversion shelves' comes to mind
[0].
I remember as Wendy (and others?) were working on the one over in the
test repository, there was no way to know (other than updating from
svn) what was changing. A simple mail filter will eliminate the
commit msgs if people consider it spam.
Your thoughts?
[0] http://blogs.vertigosoftware.com/teamsystem/archive/2006/01/18/
Shelving_and_Branching.aspx
--
James Mitchell
On Apr 20, 2006, at 10:58 AM, James Mitchell wrote:
We should probably do this over in a test repository and make sure
it will do what we want. Similar to what was done for MyFaces and
Action1.
Your thoughts?
--
James Mitchell
On Apr 19, 2006, at 10:35 PM, Sean Schofield wrote:
I'd love to see Shale move to M2. I'll try to help with the limited
Maven knowledge that I have gleaned from the MyFaces experience. I'd
recommend starting out with a proposed hierarchy and set of
artifiacts
as a starting point. See if we can get the basics squared away first
before sweating the javadocs.
Sean
On 4/15/06, Craig McClanahan <[EMAIL PROTECTED]> wrote:
On 4/15/06, Brett Porter <[EMAIL PROTECTED]> wrote:
are the apis with the other javadoc going to be in a separate
module?
This should make it easy to produce javadoc from there, and then
go on
to produce the aggregated javadoc for the others.
Ideally not. It's already going to be painful to split up the
core-library
package (which now produces several JAR files) into separate
modules solely
because Maven likes one artifact per module.
Shale publishes information on API stability (
http://struts.apache.org/struts-shale/api-stability.html) that
also includes
a column describing who should be using the APIs in each package ...
application developers or those wanting to extend the framework.
That is
the basis on which I would want to split the javadocs, but they
would also
be based on combining back together all the application-related
APIs and all
the framework-related APIs back together again.
- Brett
Craig
On 4/16/06, Wendy Smoak <[EMAIL PROTECTED]> wrote:
On 4/15/06, James Mitchell <[EMAIL PROTECTED]> wrote:
Craig wrote
I'll want to experiment with ways to get combined javadocs
out of
these artifacts (although probably two sets ...
Can we do this with custom assemblies?
Without trying it, I don't think so, because it's more than just
copying files around. The Javadoc tool needs to create the
frames and
indexes so that everything is linked together.
I think it will need two <reportSet>s, so the Javadoc plugin runs
twice with different configuration. Maybe something like this,
which
runs both the regular Javadoc doclet and the UMLGraph one:
http://wiki.wsmoak.net/cgi-bin/wiki.pl?UMLGraph
And here's a link to some work that I did last year, which
includes
pom.xml files and a script to rearrange Shale into Maven 2's
preferred
structure. I stopped in late November, so it doesn't include
Shale
Tiger or anything after that.
http://wiki.wsmoak.net/cgi-bin/wiki.pl?ShaleMaven2#build
--
Wendy
------------------------------------------------------------------
---
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-------------------------------------------------------------------
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
