jandockx / ppwcode-recovered-from-google-code

Automatically exported from code.google.com/p/ppwcode
Apache License 2.0
0 stars 0 forks source link

dependency problem with checkstyle #111

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
Checkstyle uses a template to find license headers. Which license header we 
want, depends on 
the particular project, and thus cannot be defined in the general 
maven2-library-parent-pom.

For ppwcode, this is an Apache License v2 notice. This is set in the ppwcode 
child of the library-
parent-pom, ppwcode-library-parent-pom, via a property (which is used in 
library-parent-
pom).

The actual file that we refer to there is distributed in the licensetemplates 
artifact.

To find this file in that artifact, the checkstyle plugin needs to be defined 
with a dependency on 
that artifact. BUT THIS IS DONE IN library-parent-pom!! In other words, in 
library-parent-pom 
we already fix which artifact to use for the header templates. As a 
consequence, child projects 
that do not use the Apache License v2 license are f*cked. The use of the 
property for the file 
name gives a wrong sense if decoupling.

This must be fixed in some way.

BTW: the header check is the last real problem in the checkstyle definition 
(Issue109). So does all 
this make really sense?

Original issue reported on code.google.com by jandockx on 25 Jul 2008 at 11:09

GoogleCodeExporter commented 9 years ago
the idea is that _all_ license templates are in the licensetemplate artifact.  
That's why the dependency is in the top level project.  It is idea that every 
project overrides the ppwcode.checkstyle.headerLocation property (which is 
empty in 
library-parent-pom, and is defined in ppwcode-library-parent-pom, which is used 
for 
all googlecode projects).  This does enforce each project to use a header 
though. 

Original comment by Tom.Mah...@gmail.com on 26 Jul 2008 at 4:01

GoogleCodeExporter commented 9 years ago
See also Issue112

Original comment by jandockx on 27 Jul 2008 at 9:32

GoogleCodeExporter commented 9 years ago
In that case we should try to parametrize the artifact used, so that users 
could use there own artifact, and use 
our artifact as default. 2 reasons:

* our artifact will not be complete; it can become more complete over time, 
adding headers for different kinds of 
licenses, but it never will be really complete
* non-open-source projects will have a proprietary license of clients; we 
cannot add all those

Original comment by jandockx on 27 Jul 2008 at 9:36

GoogleCodeExporter commented 9 years ago
See Issue109

Original comment by jandockx on 27 Jul 2008 at 9:43

GoogleCodeExporter commented 9 years ago
this should not hold back a first release

Original comment by jandockx on 28 Jul 2008 at 9:36