On 16 April 2013 17:25, Mark Eggers <its_toas...@yahoo.com> wrote: > Comments in-line, and some of the original trimmed . . . > > > On 4/16/2013 8:54 AM, Stephen Connolly wrote: > >> On 16 April 2013 16:19, Mark Eggers <its_toas...@yahoo.com> wrote: >> >> On 4/16/2013 2:31 AM, Richard Vowles wrote: >>> >>> what needs concatenating? there isnt much designed to be anti-modular >>>> these >>>> days. >>>> >>>> >>> Some properties files. I could possibly remove the properties files issue >>> by either having the developers hand craft them for each project, or >>> design >>> a new modular configuration system. The first is error-prone, and the >>> second will take a bit of time. >>> >>> I suppose an ant task would work as well, but since I'm trying to replace >>> ant I would like to avoid falling back on it. >>> >>> >> I would not decry using antrun to work around a (hopefully) temporary >> issue. >> >> If it proves too difficult to move to a new modular configuration system, >> then I would look to replace that antrun with a plugin that does the >> merging for me, perhaps even defining a new packaging type so that I can >> just go <packaging>eggers-war</**packaging> >> >> > I'll have to investigate a new packaging type. I'm more or less a Maven > newcomer, so that will take a little bit of effort. I am in huge favor of > keeping the pom.xml file as simple and easily understood as possible. > > > If I do come up with a new modular configuration system, e.g. using >> ClassLoader.getResources(path) rather that ClassLoader.getResource(path) >> and then just effectively concatenating all the .properties files within >> the app, then the antrun will just go away. >> > > I'll definitely try that. I'm mostly a systems architect, but I seem to be > getting pulled into build and development issues these days. The change > should be minor, and will definitely result in a more clearly decoupled > modular system. > > Then the only issue becomes naming conventions so that there are no file > name collisions.
Ahh no... ClassLoader.getResources(path) returns an enumeration of all the resources with that path... you actually want the collisions and then your just load each in app and merge using logic defined in app... i.e. the best of all, you change no code and the app just works ;-) > > > >> Having antrun there is a good tool to mark the fact that you have >> technical >> debt that will need to be repaid. When you are leaving technical debt the >> keys thing to remember are that: >> >> 1. it should be clear and obvious that it is technical debt >> 2. it should be as small as possible >> >> A *simple* antrun execution that removes the need for a complex workaround >> that might need to be unwound anyway is much better technical debt to >> leave >> for later... OTOH if it is a complex antrun execution then that would not >> be good technical debt to leave for later >> >> >> > This may be simple. I'll need to gather all of the files of a certain > name, concatenate them, and place them in build/site (ie., before the > packaging takes place). This way both the IDE and the resulting WAR file > will have access to the result. > > I like the idea of a simple marker that indicates a technical debt. It > looks like a good way to identify 'code smell' which needs to be addressed. > > Thanks again . . . > > > /mde/ > > On Apr 16, 2013 6:56 PM, "Mark Eggers" <its_toas...@yahoo.com> wrote: >>> >>>> >>>> Hi, >>>> >>>>> >>>>> I'm fairly new to Maven, and I'm trying to meet the following >>>>> requirements. >>>>> >>>>> 1. A web site consisting of multiple components, some optional >>>>> 2. Optional components each have some configuration files >>>>> 3. If multiple optional components are present, the configuration files >>>>> should be concatenated >>>>> >>>>> My first pass using WAR overlays and the shade plugin worked, in that >>>>> the >>>>> resulting site.war had all the right components. However, target/site >>>>> did >>>>> not contain the concatenated files created by the shade plugin. This >>>>> prevented target/site being run from within an IDE. >>>>> >>>>> If I thought about it for a minute, that's pretty obvious since the >>>>> shade >>>>> plugin is executed during the package part of the lifecycle. >>>>> >>>>> What I came up with is the following: >>>>> >>>>> 1. Create a multi-module project >>>>> 2. One module collects all of the components that require use of the >>>>> shade plugin >>>>> 3. The second module is the actual site, and depends on the >>>>> "collections" module >>>>> 4. Use the WAR plugin overlay, plus exclusions, plus the shade plugin >>>>> to create an intermediate WAR in the collections module >>>>> 5. Overlay that intermediate WAR on the final site >>>>> >>>>> This works except that I now have an extra artifact that is only used >>>>> during the build. I can run target/site from the IDE (great for >>>>> debugging) >>>>> and site.war looks as it should. >>>>> >>>>> Other than the fact that this works, is this the proper "Maven way"? >>>>> The >>>>> extra artifact (an artifact of the build process as it were) feels a >>>>> little >>>>> odd. >>>>> >>>>> . . . . just my two cents >>>>> /mde/ >>>>> >>>> > > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: > users-unsubscribe@maven.**apache.org<users-unsubscr...@maven.apache.org> > For additional commands, e-mail: users-h...@maven.apache.org > >
