incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Juan Pablo Santos Rodríguez <juanpablo.san...@gmail.com>
Subject Re: trunk going multimodule?
Date Mon, 27 May 2013 15:02:57 GMT
[snip]
I was using config/dev to refer to internal team project files external
users don't wish to be concerned with.  (I also placed OldChangeLog and
wanted to put the .rdf file there too.)  If you prefer, as an alternative,
CXF uses a non-Mavenized /etc folder:
http://svn.apache.org/viewvc/cxf/trunk/etc/ allowing you to separate out
Eclipse and IDEA code configuration files and other internal team files.
[/snip]

More than being under src/main/config, I was referring to the module, as
those files are application-wide, but I suppose jspwiki-war is ok anyway,
as there isn't a real need to know where the file is. Just
opening/importing/whatever in Eclipse should be enough.


>  - some autogenerated files still appear on ./jspwiki-war: rss.rdf and
>> tests/build/webtests (also happens at current trunk)
>>
>
> I didn't realize rss.rdf was autogenerated.  Nothing should be appearing
> in the "tests" folder on the new 2.9.2 branch (unless it's the keysigning
> stuff which I haven't looked into), I nuked that folder and saw to it that
> everything would go under target instead: target/ant-dist and
> target/ant-webtests.
>
>
tests/build/webtests contained a log file (ContainerLog.txt or something
similar), didn't look into it b/c it was just too late. But both look easy
to solve.


>
> Sounds good, and your multimodule work looks *very* nice and clean from
> what I've seen so far--and you created a very helpful mvn_cheat-sheet:
> http://svn.apache.org/viewvc/**incubator/jspwiki/trunk/mvn_**
> cheat-sheet.txt?view=markup<http://svn.apache.org/viewvc/incubator/jspwiki/trunk/mvn_cheat-sheet.txt?view=markup>.
> Please let us know what's left before we can do the joyous deletion of the
> build.xml file.  I'm so happy we've Mavenized--this will make our project
> look more modern externally as well as provide more beneficial growth for
> those volunteering time on it.
>

parent pom is missing artifact checksums (through install plugin, most
probably through a "dist" profile), we have to switch to mvn sonar:sonar @
builds.a.o/jenkins, container auth IT modules are missing, the dist module
and Apache Nexus integration are missing. But I don't think that any of
those are blockers for removing the build.xml. To be on the safe side, IMO
right now, everything not related to the dist target (dependencies
download, webtests) can be removed from build.xml.


br,
juan pablo

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message