Re: Checkstyle plugin 2.8 release?
Great, thanks Olivier. Just back from holiday so apologies for the delay. I'll push the release now. Cheers, Mark On 16 October 2011 17:37, Olivier Lamy ol...@apache.org wrote: Mark, I don't know if you follow commits logs but you have karma back :-) Let me know if you want to push the release. 2011/10/14 Mark Hobson markhob...@gmail.com: That'd be great, thanks Olivier! Mark On 14 October 2011 08:26, Olivier Lamy ol...@apache.org wrote: Hello, I can probably do that around middle next week. Ping me if I miss :-) 2011/10/13 Mark Hobson markhob...@gmail.com: Hi, I need to use maven-checkstyle-plugin 2.7 for the checkstyle upgrade but am being blocked by MCHECKSTYLE-159. This is fixed in trunk and there are no further unresolved issues targeting 2.8, so any objections to performing a release? Next question is would someone mind doing it? :) I'm happy to but have appeared to have dropped into emeritus status again, so would have to get reinstated first. Cheers, Mark - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Olivier Lamy Talend : http://talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Olivier Lamy Talend : http://talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[VOTE] Release Maven Checkstyle Plugin version 2.8
Hi, We solved 2 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11127version=17520 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11127status=1 Staging repo: https://repository.apache.org/content/repositories/maven-091/ Staging site: http://maven.apache.org/plugins/maven-checkstyle-plugin-2.8/plugins/maven-checkstyle-plugin/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Cheers, Mark - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven and JigSaw thoughts
On 10/22/2011 05:00 AM, Mark Struberg wrote:
there is atm a strict 1:1 between a Modul and a ClassLoader.
This would not be true for the special case of JDK modules (what is now rt.jar + tools.jar); probably TBD whether user modules will be permitted to share class loaders
for ease of migration of legacy apps. But in general, yes, each module would be associated with its own loader at runtime.
modules which need multiple classloaders (like EARs) or a specific deployment
task (like WARs)
As far as I know, Java EE is not supported by the current Jigsaw work.
A Module is a JAR.
Actually a true Jigsaw module would be a *.jmod file - a new format capable of good compression and other advantages. There is also support for creating legacy *.jar
files for use in premodular JVMs (just as an OSGi bundle can be used in degraded form without a container).
Thus also the notion of an 'attached artifact' is completely missing. If you
need such a thing, you would need to stuff it into a jar and access it via
getResource().
Probably true, though this is already more or less the case at runtime: a premodular app cannot use attached artifacts at runtime (without embedding Maven code). At least
the common case of System.loadLibrary would work more smoothly with a jmod (no need to extract to a temporary file).
On a related topic, it seems unclear how creation of modules from a Maven project should work. Suppose packagingjmod/packaging. Should ${finalName}.jmod be the
primary and only artifact? But then a legacy packagingjar/packaging project will not be able to consume this module's classes in flat classpath mode, which would be
a huge obstacle to adoption. Should ${finalName}.jar be the primary artifact with ${finalName}.jmod (*) a secondary artifact (**)? This would permit interoperability with
jar-packaging projects but seems clumsy because the primary artifact would not be used at runtime in a module-aware app.
And should dependency artifact(s) be resolved to ${basedir}/target/classes/ inside a reactor build? Jigsaw should have support for exploded modules so this would be
fine for compiling, and for running (e.g. in Surefire) most Java code; but not for testing code using JNI, unless the Surefire plugin can be taught to set
$LD_LIBRARY_PATH / %Path% (***) intelligently.
What we could do is to populate the local jigsaw repo on mvn install. Or even
provide a mechanism to do a mvn jigsaw:deploy for upstream jigsaw module repos.
Jigsaw already has a (prototype) repository connector which can read Maven
repositories, so this might be unnecessary for most users.
As the dependency resolution is built into the java runtime, we don't need to
do anything for resolving jigsaw modules.
This is actually the main problem as I see it: Jigsaw's javac expects src/main/java/module-info.java to have the exact list of Java dependencies (the -classpath argument
is illegal in modular mode), which means that any part of Maven other than maven-compiler-plugin which needs to know the list of dependencies is going to be out of luck.
Possible solutions:
1. Signal an error at build time if module-info.java is out of synch with
pom.xml, and force the user to maintain both. Yuck.
2. Create target/generated-sources/jigsaw/module-info.java from pom.xml before calling javac. Not clear if this can work; and some module information (e.g. list of
exported classes) would then have to be encoded somewhere in pom.xml (compare maven-bundle-plugin's configuration), which is not great.
3. Force Maven core to load (at least some) dependency information from
module-info.java. I understand Tycho does something like this already.
Of course we could provide something like resolving
dependencies from an upstream jigsaw repo if those artifacts are not present in
the local maven repo.
And/or provide a batch tool to create a Maven 2-format mirror of a Jigsaw repo.
[later]
the dependency matching (what happens if you have 2 transitive dependencies
with different versions, version ranges, etc) must not happen at runtime
Final version resolution would happen at install time. Note that Jigsaw's decisions would not match Maven's in all scenarios; it might prefer the newest available version
of a contentious dependency rather than the version closest to the top-level module of the app.
(*) Perhaps ${finalName}-something.jmod. It is not obvious from Maven's limited documentation whether a secondary artifact must have a classifier. nbm-maven-plugin
(analogous in many ways to Jigsaw) creates secondary ${finalName}.nbm artifacts with no classifier, but this seems to cause subtle problems, especially in Maven Indexer.
(**) -Pdeployment could add *.deb and other native variants.
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
How to set src-folder correctly
Hi. We are using maven for own project types. However the source folders (src/main/java and src/test/java) are not the same since we are not using java. To let some plugins work correctly we need to ovrwrite them with the correct folders. For know we created a small goal that will be executed early. It will overwrite the source folders directly. It works but I don't feel it is the correct way. Do you recommend another way, for example some hint in components.xml I did not see yet? How do we tell maven that the source folders for our own packaging are not the java ones? If having an early goal setting the source folders programtically, what goal should we choose? The validate goal is the first one and so the best one to set the new source folders but it is focused of validation of the project and not focused on hack project pom to fit the best needs. Greetings Martin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
