You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Wendy Smoak <ws...@gmail.com> on 2006/04/15 17:14:56 UTC
[shale] Maven 2 build (was Re: [action1] Which webapp dtds to include in struts-core.jar?)
On 4/14/06, Craig McClanahan <cr...@apache.org> wrote:
> Separately, I'm ready (gulp!) to start moving Shale towards Maven2, and it's
> recommended soure directory organizations ... as long as you
> have-a-clue-about-Maven gurus promise to stand by my side and help :-).
Of course. :)
> I
> had a question about the "resources" directories in the organization
> recommended by Maven. Does that include resource bundles for localization
> (which are normally placed somewhere in the "src/java" hierarchy currently),
> or is it just for "configuration" files?
Maven's recommended directory structure is src/main/java for .java
files, and src/main/resources for everything else. With that, no
configuration is necessary.
http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html
If you prefer to keep .properties files in with the source code, it
takes some <resource> sections in the pom to get them included in the
jar. Example:
http://svn.apache.org/repos/asf/struts/action/trunk/core/pom.xml
> It shouldn't be too hard to remodel the existing organization and update the
> relevant Ant build.xml files, as a move towards forwards compatibility with
> the recommended structure.
...
> But it makes a lot of sense to
> migrate the internal organization of the Shale source repositories now, to
> make the ultimate conversion easier. Anyone else who wants to help in this
> is, of course, welcome to have at it.
The major change is splitting core-library into multiple modules, one per jar.
Are you planning to keep the Ant build after Maven 2 is in place?
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [shale] Maven 2 build (was Re: [action1] Which webapp dtds to include in struts-core.jar?)
Posted by Sean Schofield <se...@gmail.com>.
> 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.
With MyFaces we ran into a similar problem (at least it sounds
similar.) We have one subproject for the JSF implementation but two
artifacts (myfaces-api.jar and myfaces-impl.jar.)
So we have core/pom.xml, core/api/pom.xml and core/impl/pom.xml. The
top level pom has the version, scm, and issue management sections but
it basically serves as a placeholder for the two modles: api and impl.
For our release builds (and nightly builds), we want a single zip file
for both jar files. So we have a little bit of custom maven magic to
pull this off.
Checkout the core and try:
svn clean install -Pgenerate-assembly
Then change to the assembly dir and do:
mvn assembly:assembly
We don't merge the javadocs and each module gets its own section in
the website. This is hard to avoid with maven but in our case the
javadoc split is actually desirable and makes things easier to
navigate.
Sean
> Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [shale] Maven 2 build (was Re: [action1] Which webapp dtds to include in struts-core.jar?)
Posted by James Mitchell <jm...@apache.org>.
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 <cr...@apache.org> wrote:
>>> On 4/15/06, Brett Porter <br...@gmail.com> 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 <ws...@gmail.com> wrote:
>>>>> On 4/15/06, James Mitchell <jm...@apache.org> 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: dev-unsubscribe@struts.apache.org
>>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>>
>>>>>
>>>>
>>>> -------------------------------------------------------------------
>>>> --
>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>
>>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [shale] Maven 2 build (was Re: [action1] Which webapp dtds to include in struts-core.jar?)
Posted by James Mitchell <jm...@apache.org>.
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 <cr...@apache.org> wrote:
>> On 4/15/06, Brett Porter <br...@gmail.com> 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 <ws...@gmail.com> wrote:
>>>> On 4/15/06, James Mitchell <jm...@apache.org> 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: dev-unsubscribe@struts.apache.org
>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>
>>>>
>>>
>>> --------------------------------------------------------------------
>>> -
>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>
>>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [shale] Maven 2 build (was Re: [action1] Which webapp dtds to include in struts-core.jar?)
Posted by Sean Schofield <se...@gmail.com>.
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 <cr...@apache.org> wrote:
> On 4/15/06, Brett Porter <br...@gmail.com> 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 <ws...@gmail.com> wrote:
> > > On 4/15/06, James Mitchell <jm...@apache.org> 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: dev-unsubscribe@struts.apache.org
> > > For additional commands, e-mail: dev-help@struts.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [shale] Maven 2 build (was Re: [action1] Which webapp dtds to include in struts-core.jar?)
Posted by Craig McClanahan <cr...@apache.org>.
On 4/15/06, Brett Porter <br...@gmail.com> 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 <ws...@gmail.com> wrote:
> > On 4/15/06, James Mitchell <jm...@apache.org> 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: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
Re: [shale] Maven 2 build (was Re: [action1] Which webapp dtds to include in struts-core.jar?)
Posted by Brett Porter <br...@gmail.com>.
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.
- Brett
On 4/16/06, Wendy Smoak <ws...@gmail.com> wrote:
> On 4/15/06, James Mitchell <jm...@apache.org> 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: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [shale] Maven 2 build (was Re: [action1] Which webapp dtds to include in struts-core.jar?)
Posted by Wendy Smoak <ws...@gmail.com>.
On 4/15/06, James Mitchell <jm...@apache.org> 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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [shale] Maven 2 build (was Re: [action1] Which webapp dtds to include in struts-core.jar?)
Posted by James Mitchell <jm...@apache.org>.
>
> I'll want to experiment with ways to get combined javadocs out of
> these
> artifacts (although probably two sets ... I got a suggestion to
> split the
> APIs that are interesting to application developers from the
> "internal" APIs
> for those extending the framework, and would like to produce two
> sets of
> javadocs with their appropriate packages.
Can we do this with custom assemblies?
--
James Mitchell
On Apr 15, 2006, at 11:35 AM, Craig McClanahan wrote:
> On 4/15/06, Wendy Smoak <ws...@gmail.com> wrote:
>>
>> On 4/14/06, Craig McClanahan <cr...@apache.org> wrote:
>>
>>> Separately, I'm ready (gulp!) to start moving Shale towards
>>> Maven2, and
>> it's
>>> recommended soure directory organizations ... as long as you
>>> have-a-clue-about-Maven gurus promise to stand by my side and
>>> help :-).
>>
>> Of course. :)
>>
>>> I
>>> had a question about the "resources" directories in the organization
>>> recommended by Maven. Does that include resource bundles for
>> localization
>>> (which are normally placed somewhere in the "src/java" hierarchy
>> currently),
>>> or is it just for "configuration" files?
>>
>> Maven's recommended directory structure is src/main/java for .java
>> files, and src/main/resources for everything else. With that, no
>> configuration is necessary.
>>
>>
>> http://maven.apache.org/guides/introduction/introduction-to-the-
>> standard-directory-layout.html
>>
>> If you prefer to keep .properties files in with the source code, it
>> takes some <resource> sections in the pom to get them included in the
>> jar. Example:
>> http://svn.apache.org/repos/asf/struts/action/trunk/core/pom.xml
>>
>>> It shouldn't be too hard to remodel the existing organization and
>>> update
>> the
>>> relevant Ant build.xml files, as a move towards forwards
>>> compatibility
>> with
>>> the recommended structure.
>> ...
>>> But it makes a lot of sense to
>>> migrate the internal organization of the Shale source
>>> repositories now,
>> to
>>> make the ultimate conversion easier. Anyone else who wants to
>>> help in
>> this
>>> is, of course, welcome to have at it.
>>
>> The major change is splitting core-library into multiple modules,
>> one per
>> jar.
>
>
> Which is the reason I've been resisting so far ... :-)
>
> I'll want to experiment with ways to get combined javadocs out of
> these
> artifacts (although probably two sets ... I got a suggestion to
> split the
> APIs that are interesting to application developers from the
> "internal" APIs
> for those extending the framework, and would like to produce two
> sets of
> javadocs with their appropriate packages.
>
> Are you planning to keep the Ant build after Maven 2 is in place?
>
>
> Ideally, no ... it's hard enough to keep one build environment in
> sync with
> reality. But we'll probably need some user feedback before
> decomissioning
> the Ant scripts.
>
> --
>> Wendy
>
>
> Craig
>
>
> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
SV: [shale] Maven 2 build (was Re: [action1] Which webapp dtds to
include in struts-core.jar?)
Posted by Hermod Opstvedt <he...@opstvedt.com>.
Hei
Wise move - Maven 2 is much preferred for many reasons. However there might
be some pitfalls with respect to dependencies - Their availability is so and
so for now, but getting better every day.
Hermod
-----Opprinnelig melding-----
Fra: craigmcc@gmail.com [mailto:craigmcc@gmail.com] På vegne av Craig
McClanahan
Sendt: 15. april 2006 17:35
Til: Struts Developers List
Emne: Re: [shale] Maven 2 build (was Re: [action1] Which webapp dtds to
include in struts-core.jar?)
On 4/15/06, Wendy Smoak <ws...@gmail.com> wrote:
>
> On 4/14/06, Craig McClanahan <cr...@apache.org> wrote:
>
> > Separately, I'm ready (gulp!) to start moving Shale towards Maven2, and
> it's
> > recommended soure directory organizations ... as long as you
> > have-a-clue-about-Maven gurus promise to stand by my side and help :-).
>
> Of course. :)
>
> > I
> > had a question about the "resources" directories in the organization
> > recommended by Maven. Does that include resource bundles for
> localization
> > (which are normally placed somewhere in the "src/java" hierarchy
> currently),
> > or is it just for "configuration" files?
>
> Maven's recommended directory structure is src/main/java for .java
> files, and src/main/resources for everything else. With that, no
> configuration is necessary.
>
>
>
http://maven.apache.org/guides/introduction/introduction-to-the-standard-dir
ectory-layout.html
>
> If you prefer to keep .properties files in with the source code, it
> takes some <resource> sections in the pom to get them included in the
> jar. Example:
> http://svn.apache.org/repos/asf/struts/action/trunk/core/pom.xml
>
> > It shouldn't be too hard to remodel the existing organization and update
> the
> > relevant Ant build.xml files, as a move towards forwards compatibility
> with
> > the recommended structure.
> ...
> > But it makes a lot of sense to
> > migrate the internal organization of the Shale source repositories now,
> to
> > make the ultimate conversion easier. Anyone else who wants to help in
> this
> > is, of course, welcome to have at it.
>
> The major change is splitting core-library into multiple modules, one per
> jar.
Which is the reason I've been resisting so far ... :-)
I'll want to experiment with ways to get combined javadocs out of these
artifacts (although probably two sets ... I got a suggestion to split the
APIs that are interesting to application developers from the "internal" APIs
for those extending the framework, and would like to produce two sets of
javadocs with their appropriate packages.
Are you planning to keep the Ant build after Maven 2 is in place?
Ideally, no ... it's hard enough to keep one build environment in sync with
reality. But we'll probably need some user feedback before decomissioning
the Ant scripts.
--
> Wendy
Craig
---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [shale] Maven 2 build (was Re: [action1] Which webapp dtds to include in struts-core.jar?)
Posted by Craig McClanahan <cr...@apache.org>.
On 4/15/06, Wendy Smoak <ws...@gmail.com> wrote:
>
> On 4/14/06, Craig McClanahan <cr...@apache.org> wrote:
>
> > Separately, I'm ready (gulp!) to start moving Shale towards Maven2, and
> it's
> > recommended soure directory organizations ... as long as you
> > have-a-clue-about-Maven gurus promise to stand by my side and help :-).
>
> Of course. :)
>
> > I
> > had a question about the "resources" directories in the organization
> > recommended by Maven. Does that include resource bundles for
> localization
> > (which are normally placed somewhere in the "src/java" hierarchy
> currently),
> > or is it just for "configuration" files?
>
> Maven's recommended directory structure is src/main/java for .java
> files, and src/main/resources for everything else. With that, no
> configuration is necessary.
>
>
> http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html
>
> If you prefer to keep .properties files in with the source code, it
> takes some <resource> sections in the pom to get them included in the
> jar. Example:
> http://svn.apache.org/repos/asf/struts/action/trunk/core/pom.xml
>
> > It shouldn't be too hard to remodel the existing organization and update
> the
> > relevant Ant build.xml files, as a move towards forwards compatibility
> with
> > the recommended structure.
> ...
> > But it makes a lot of sense to
> > migrate the internal organization of the Shale source repositories now,
> to
> > make the ultimate conversion easier. Anyone else who wants to help in
> this
> > is, of course, welcome to have at it.
>
> The major change is splitting core-library into multiple modules, one per
> jar.
Which is the reason I've been resisting so far ... :-)
I'll want to experiment with ways to get combined javadocs out of these
artifacts (although probably two sets ... I got a suggestion to split the
APIs that are interesting to application developers from the "internal" APIs
for those extending the framework, and would like to produce two sets of
javadocs with their appropriate packages.
Are you planning to keep the Ant build after Maven 2 is in place?
Ideally, no ... it's hard enough to keep one build environment in sync with
reality. But we'll probably need some user feedback before decomissioning
the Ant scripts.
--
> Wendy
Craig
---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>