You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@taverna.apache.org by alaninmcr <al...@googlemail.com> on 2015/01/21 14:41:53 UTC
Taverna language (SCUFL2) poms
Hello everybody,
Just to say that I am having to change the SCUFL2 poms a little to
ensure they compile with Java 1.7 not 1.4 :)
The apache rat plugin is complaining a lot about the licensing, but as
far as I know we cannot start to change the licensing until we have the
sign over from Manchester.
Alan
Re: Taverna language (SCUFL2) poms
Posted by alaninmcr <al...@googlemail.com>.
What should happen with org.purl.wf4ever.robundle.* packages? Is
org.apache.taverna.robundle.* reasonable?
Alan
Re: Taverna language (SCUFL2) poms
Posted by alaninmcr <al...@googlemail.com>.
I have updated the package names and also increased the version number
to 0.16.1-incubating-SNAPSHOT so that any code referencing the old
packages in 0.15.1-incubating-SNAPSHOT should still work.
I did not change org.purl.wf4ever.wfdesc.scufl2, but probably will.
Now I think we are just waiting for the lawyers to do their stuff.
Alan
Re: Taverna language (SCUFL2) poms
Posted by alaninmcr <al...@googlemail.com>.
On 21/01/2015 14:29, Dmitry wrote:
> Great,
>
> Will this be the standard pattern in packages?
> For instance:
> net.sf.taverna.wsdl.parser -> org.apache.taverna.wsdl.parser
I think that should be the default mapping - unless people object.
> There are also many components that have "t2" in the package.
> Will they pass into "t3"?
> IMHO it is better to remove the version from packages.
Agreed. So net.sf.taverna.t2.workflowmodel would become
org.apache.taverna.workflowmodel . The versioning is in the version of
the artifact not in the name of the package.
> Cheers,
>
> Dmitry
Alan
Re: Taverna language (SCUFL2) poms
Posted by Stian Soiland-Reyes <so...@cs.manchester.ac.uk>.
Agree for combining - but at least taverna-robundle I would hope to be
a separate bundle as it is already used in non-Taverna projects who
don't deal with scufl2 or databundles.
databundle on the other hand requires scufl2-api (it has a
set/getWorkflow() method), and all the validators should be inside
-api - they have no strange dependencies.
The t2flow parser is standard Java JAXB and can be included in -api.
The -rdfxml should probably be called -wfbundle and is quite essential
- so probably that as well.
There is not much left then - it's arguably not very OSGi like with a
bloated *-api (we would have to be more careful with the version
number), but then again scufl2 is meant to be used "on the outside" -
so ending up with a minimum amount of JARs in this particular
repository is probably good.
We should trim down taverna-scufl2-wfdesc - it currently depends on
OpenRDF Elmo and an outdated Sesame version (big Maven job to upgrade
as they have so MANY modules) - but its use can probably be achieved
with Jena's codegen instead (create constants from OWL) - we already
use Jena for parsing the RO Bundle manifest. I would not merge in
scufl2-wfdesc yet because of that.
Over time we should not need to expose the Jena dependency, as we can
expose the generic commons-rdf interfaces instead (for annotations)
and then probably can use its light-weight RDF support bound with
JSON-LD Java - but that is probably two years ahead in time and
requires a few weeks of night-time-hacking. :) (Not to mention
getting Commons-RDF and Apache Commons RDF to sort itself out
community-wise.. I am trying!)
On 22 January 2015 at 10:57, alaninmcr <al...@googlemail.com> wrote:
> On 21/01/2015 22:20, Stian Soiland-Reyes wrote:
>
> [snip]
>
>> Do however keep in mind that in OSGi one package must live in a single
>> jar/maven module. Subpackages can be elsewhere however (e.g. split
>> org.example and org.example.impl is good), and of course you are allowed
>> to
>> have more that one package per jar (but if there's a lot, this looks a bit
>> odd again).
>
>
> We need to think about how many bundles should be expected for Taverna
> language. At the moment we get a lot of small bundles e.g. one for Baclava.
>
> I think some of these bundles could/should be combined, possibly even having
> just one bundle for Taverna language support.
>
> [snip]
>
> Alan
--
Stian Soiland-Reyes, eScience Lab
School of Computer Science
The University of Manchester
http://soiland-reyes.com/stian/work/ http://orcid.org/0000-0001-9842-9718
Re: Taverna language (SCUFL2) poms
Posted by Christian Brenninkmeijer <br...@cs.man.ac.uk>.
As a general rule we should consider a single bundle and a single (or
few) package names when the code will always be release under a single
version number.
So if two bundles or packages must always upgrade together why are they
two and not one?
This does not apply to org.example(API) and org.example.impl as there is
no bump the version of org.example(API) just because org.example.impl
has changed.
Christian
On 22/01/2015 10:57, alaninmcr wrote:
> On 21/01/2015 22:20, Stian Soiland-Reyes wrote:
>
> [snip]
>
>> Do however keep in mind that in OSGi one package must live in a single
>> jar/maven module. Subpackages can be elsewhere however (e.g. split
>> org.example and org.example.impl is good), and of course you are
>> allowed to
>> have more that one package per jar (but if there's a lot, this looks
>> a bit
>> odd again).
>
> We need to think about how many bundles should be expected for Taverna
> language. At the moment we get a lot of small bundles e.g. one for
> Baclava.
>
> I think some of these bundles could/should be combined, possibly even
> having just one bundle for Taverna language support.
>
> [snip]
>
> Alan
Re: Taverna language (SCUFL2) poms
Posted by alaninmcr <al...@googlemail.com>.
On 21/01/2015 22:20, Stian Soiland-Reyes wrote:
[snip]
> Do however keep in mind that in OSGi one package must live in a single
> jar/maven module. Subpackages can be elsewhere however (e.g. split
> org.example and org.example.impl is good), and of course you are allowed to
> have more that one package per jar (but if there's a lot, this looks a bit
> odd again).
We need to think about how many bundles should be expected for Taverna
language. At the moment we get a lot of small bundles e.g. one for Baclava.
I think some of these bundles could/should be combined, possibly even
having just one bundle for Taverna language support.
[snip]
Alan
Re: Taverna language (SCUFL2) poms
Posted by Stian Soiland-Reyes <st...@apache.org>.
In principle I agree with your suggestions of package renaming, go ahead! I
had not got round to it.
I would only do renames at the incubator-* repositories, e.g. not in
taverna-commons-activities yet, as Java packages are reflected as file
renames.
(And the remaining repos are yet to be created with proper merges of their
multiple origins.. Sorry for my delays. )
Yes, I would hope to get rid of intermediate package names that don't mean
much and just add hierarchies for hierarchies sake. So for example
org.apache.taverna.scufl2.t2flow should do - all of scufl2 is not that
large and should not need a large amount of packages.
The workbench is on the other side large, but also there the current
packages and modules are overly specific, e.g. a single UI component might
have five subpackages with three classes each.
Do however keep in mind that in OSGi one package must live in a single
jar/maven module. Subpackages can be elsewhere however (e.g. split
org.example and org.example.impl is good), and of course you are allowed to
have more that one package per jar (but if there's a lot, this looks a bit
odd again).
just in case someone got this idea - I don't see a need to force the
package to match the last bit of the groupId, something like
org.apache.taverna.language.scufl2.api is too long IMHO. It also means
future inflexibility in moving packages between groupIds/git repositories -
e.g. org.apache.taverna.component could at some point move into the engine
rather than be a plugin, without breaking anything at runtime on an OSGi
level.
I think the wf4ever etc ones should go in just as you say, e.g.
org.apache.taverna.robundle - the indication is just because I was managed
by that project at the time - but its in use several places in Taverna now
and we will have to maintain it anyway.
You can disable the rat checks in the maven parent somehow, perhaps we only
want it enabled for the -Papache-release profile or run it manually before
a release? It shouldn't need to stop snapshot builds - not yet. Sorry for
adding this prematurely -
Betting on the IP clearance I was hoping we could prepare releases of
taverna-language and taverna-osgi this month - at least to RC level so the
mentors can have a field day ;-)
On 21 Jan 2015 15:30, "Dmitry" <re...@list.ru> wrote:
> Great,
>
> Will this be the standard pattern in packages?
> For instance:
> net.sf.taverna.wsdl.parser -> org.apache.taverna.wsdl.parser
>
> There are also many components that have "t2" in the package.
> Will they pass into "t3"?
> IMHO it is better to remove the version from packages.
>
> Cheers,
>
> Dmitry
>
> On 1/21/2015 3:13 PM, alaninmcr wrote:
>
>> Hello again,
>>
>> Just to say that the Taverna language on incubator is now building OK.
>>
>> Before the license changes, we can still do the package re-naming. I
>> suggest that:
>>
>> uk.org.taverna.{fred} -> org.apache.taverna.{fred} and
>> net.sf.taverna.t2.{fred} -> org.apache.taverna.{fred}
>>
>> This would mean, for example, that
>>
>> uk.org.taverna.scufl2.translator.t2flow becomes
>> org.apache.taverna.scufl2.translator.t2flow
>>
>> Any objections?
>>
>> Alan
>> .
>>
>>
>
Re: Taverna language (SCUFL2) poms
Posted by Stian Soiland-Reyes <st...@apache.org>.
On 22 January 2015 at 19:17, Stian Soiland-Reyes <st...@apache.org> wrote:
> Looks great for a first go (perhaps org.apache.taverna.scufl2.wfdesc ?).
Done.
--
Stian Soiland-Reyes
Apache Taverna (incubating)
http://orcid.org/0000-0001-9842-9718
Fwd: Taverna language (SCUFL2) poms
Posted by Stian Soiland-Reyes <st...@apache.org>.
Great job with renaming! I think this is how we would do it for the
others. Compile well (w/ -Drat.skip=true) *)
Looks great for a first go (perhaps org.apache.taverna.scufl2.wfdesc ?).
Are we OK to break forward compatibility and later release a new major
version of scufl2 where we flatten out scufl2.api.io.structure and so
on?
Perhaps large packages like scufl2.api.ports still makes sense (it
has 19 classes which all end in *Port)
AbstractDepthPort.java
AbstractGranularDepthPort.java
ActivityPort.java
DepthPort.java
GranularDepthPort.java
InputActivityPort.java
InputPort.java
InputProcessorPort.java
InputWorkflowPort.java
OutputActivityPort.java
OutputPort.java
OutputProcessorPort.java
OutputWorkflowPort.java
package-info.java
Port.java
ProcessorPort.java
ReceiverPort.java
SenderPort.java
WorkflowPort.java
scufl2.api.activity on the other hand only contains
Activity.java
what is a good enough granularity here? Leave most of it as it is?
There are larger issues ahead..
Example of taverna-language javadocs (before Alan's rename):
http://taverna.incubator.apache.org/javadoc/taverna-language/
...Trying to update that for org.apache.taver.a* over SVN from
Schiphol airport is not working particularly fast... :-/
*) With Open JDK 8 it fails for:
Tests run: 38, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 2.079
sec <<< FAILURE! - in org.apache.taverna.robundle.TestBundles
mimeTypePosition(org.apache.taverna.robundle.TestBundles) Time
elapsed: 0.036 sec <<< FAILURE!
org.junit.internal.ArrayComparisonFailure: arrays first differed at
element [8]; expected:<97> but was:<85>
at org.junit.internal.ComparisonCriteria.arrayEquals(ComparisonCriteria.java:50)
at org.junit.Assert.internalArrayEquals(Assert.java:473)
at org.junit.Assert.assertArrayEquals(Assert.java:294)
at org.junit.Assert.assertArrayEquals(Assert.java:305)
at org.apache.taverna.robundle.TestBundles.mimeTypePosition(TestBundles.java:189)
which is not a good sign - it indicates it was unable to write the
mimetype file correctly. A new JDK 8 bug..?
On 22 January 2015 at 11:07, alaninmcr <al...@googlemail.com> wrote:
> The package names (as of this second) are:
>
> org.apache.taverna.databundle
> org.apache.taverna.baclava
> org.apache.taverna.baclava.factory
> org.apache.taverna.baclava.iterator
> org.apache.taverna.baclava.lsid
> org.apache.taverna.robundle
> org.apache.taverna.robundle.fs
> org.apache.taverna.robundle.manifest
> org.apache.taverna.robundle.manifest.combine
> org.apache.taverna.robundle.odf
> org.apache.taverna.robundle.utils
> org.apache.taverna.scufl2.annotation
> org.apache.taverna.scufl2.api
> org.apache.taverna.scufl2.api.activity
> org.apache.taverna.scufl2.api.common
> org.apache.taverna.scufl2.api.configurations
> org.apache.taverna.scufl2.api.container
> org.apache.taverna.scufl2.api.core
> org.apache.taverna.scufl2.api.impl -- A very strange package name
> org.apache.taverna.scufl2.api.io
> org.apache.taverna.scufl2.api.io.structure
> org.apache.taverna.scufl2.api.iterationstrategy
> org.apache.taverna.scufl2.api.port
> org.apache.taverna.scufl2.api.profiles
> org.apache.taverna.scufl2.api.reference
> org.apache.taverna.scufl2.rdfxml
> org.apache.taverna.scufl2.rdfxml.impl
> org.apache.taverna.scufl2.translator.scufl
> org.apache.taverna.scufl2.translator.scufl.processorelement
> org.apache.taverna.scufl2.translator.t2flow
> org.apache.taverna.scufl2.translator.t2flow.defaultactivities
> org.apache.taverna.scufl2.translator.t2flow.defaultdispatchstack
> org.apache.taverna.scufl2.translator.t2flow.t23activities
> org.apache.taverna.scufl2.ucfpackage
> org.apache.taverna.scufl2.ucfpackage.impl.odfdom.pkg
> org.apache.taverna.scufl2.ucfpackage.impl.odfdom.pkg.manifest
> org.apache.taverna.scufl2.validation
> org.apache.taverna.scufl2.validation.correctness
> org.apache.taverna.scufl2.validation.correctness.report
> org.apache.taverna.scufl2.validation.structural
> org.apache.taverna.scufl2.validation.structural.report
>
> org.purl.wf4ever.wfdesc.scufl2 -- which I will probably change
>
> Alan
--
Stian Soiland-Reyes
Apache Taverna (incubating)
http://orcid.org/0000-0001-9842-9718
Re: Taverna language (SCUFL2) poms
Posted by Stian Soiland-Reyes <so...@cs.manchester.ac.uk>.
Just to be sure, I briefly checked that the history is preserved in
git across the package renames.
Note that you have to use the --follow flag to follow a particular
file through renames - which worked:
stain@biggie-utopic:~/src/taverna-incubator/incubator-taverna-language/taverna-scufl2-api$
git log --follow
src/main/java/org/apache/taverna/scufl2/api/package-info.java
commit f56be0247ad2507207094644f87b57e867c6bf13
Author: Alan R Williams <al...@manchester.ac.uk>
Date: Wed Jan 21 17:13:54 2015 +0000
Renamed packages to be org.apache.taverna
commit 15a13b30042c3d8ff3dcc2bfdf524e595ffd0f56
Author: Stian Soiland-Reyes <st...@apache.org>
Date: Mon Jan 12 21:23:55 2015 +0000
Apache headers
commit 0dcc39e5d646c24d37e9ffc783ef2942510101f2
Author: Stian Soiland-Reyes <so...@cs.manchester.ac.uk>
Date: Thu Dec 18 22:49:07 2014 -0600
scufl2-* -> taverna-scufl2-*
commit f705bf46d99993dd33b42b37cee6a600ac28c89a
Author: Stian Soiland-Reyes <st...@soiland-reyes.com>
Date: Tue Apr 23 16:25:26 2013 +0100
Javadoc update
commit 28cfe03001b403481413e1a81738c4763773049a
Author: david@mygrid.org.uk
<da...@bf327186-88b3-11dd-a302-d386e5130c1c>
Date: Thu Mar 31 10:06:06 2011 +0000
Added javadoc.
git-svn-id:
https://taverna.googlecode.com/svn/unsorted/scufl2/trunk@12848
bf327186-88b3-11dd-a302-d386e5130c1c
(..)
commit 74065c7e2d20baee7b9e89bac300b9555a03b02a
Author: Stian Soiland-Reyes <st...@soiland-reyes.com>
Date: Mon Jul 12 17:58:04 2010 +0100
schema generation
As you see this follows through package rename, through headers,
merging from separate git repositories, and back through SVN - and
magically starting in git before SVN (!).
On 22 January 2015 at 11:07, alaninmcr <al...@googlemail.com> wrote:
> The package names (as of this second) are:
>
> org.apache.taverna.databundle
> org.apache.taverna.baclava
> org.apache.taverna.baclava.factory
> org.apache.taverna.baclava.iterator
> org.apache.taverna.baclava.lsid
> org.apache.taverna.robundle
> org.apache.taverna.robundle.fs
> org.apache.taverna.robundle.manifest
> org.apache.taverna.robundle.manifest.combine
> org.apache.taverna.robundle.odf
> org.apache.taverna.robundle.utils
> org.apache.taverna.scufl2.annotation
> org.apache.taverna.scufl2.api
> org.apache.taverna.scufl2.api.activity
> org.apache.taverna.scufl2.api.common
> org.apache.taverna.scufl2.api.configurations
> org.apache.taverna.scufl2.api.container
> org.apache.taverna.scufl2.api.core
> org.apache.taverna.scufl2.api.impl -- A very strange package name
> org.apache.taverna.scufl2.api.io
> org.apache.taverna.scufl2.api.io.structure
> org.apache.taverna.scufl2.api.iterationstrategy
> org.apache.taverna.scufl2.api.port
> org.apache.taverna.scufl2.api.profiles
> org.apache.taverna.scufl2.api.reference
> org.apache.taverna.scufl2.rdfxml
> org.apache.taverna.scufl2.rdfxml.impl
> org.apache.taverna.scufl2.translator.scufl
> org.apache.taverna.scufl2.translator.scufl.processorelement
> org.apache.taverna.scufl2.translator.t2flow
> org.apache.taverna.scufl2.translator.t2flow.defaultactivities
> org.apache.taverna.scufl2.translator.t2flow.defaultdispatchstack
> org.apache.taverna.scufl2.translator.t2flow.t23activities
> org.apache.taverna.scufl2.ucfpackage
> org.apache.taverna.scufl2.ucfpackage.impl.odfdom.pkg
> org.apache.taverna.scufl2.ucfpackage.impl.odfdom.pkg.manifest
> org.apache.taverna.scufl2.validation
> org.apache.taverna.scufl2.validation.correctness
> org.apache.taverna.scufl2.validation.correctness.report
> org.apache.taverna.scufl2.validation.structural
> org.apache.taverna.scufl2.validation.structural.report
>
> org.purl.wf4ever.wfdesc.scufl2 -- which I will probably change
>
> Alan
--
Stian Soiland-Reyes, eScience Lab
School of Computer Science
The University of Manchester
http://soiland-reyes.com/stian/work/ http://orcid.org/0000-0001-9842-9718
Re: Taverna language (SCUFL2) poms
Posted by alaninmcr <al...@googlemail.com>.
The package names (as of this second) are:
org.apache.taverna.databundle
org.apache.taverna.baclava
org.apache.taverna.baclava.factory
org.apache.taverna.baclava.iterator
org.apache.taverna.baclava.lsid
org.apache.taverna.robundle
org.apache.taverna.robundle.fs
org.apache.taverna.robundle.manifest
org.apache.taverna.robundle.manifest.combine
org.apache.taverna.robundle.odf
org.apache.taverna.robundle.utils
org.apache.taverna.scufl2.annotation
org.apache.taverna.scufl2.api
org.apache.taverna.scufl2.api.activity
org.apache.taverna.scufl2.api.common
org.apache.taverna.scufl2.api.configurations
org.apache.taverna.scufl2.api.container
org.apache.taverna.scufl2.api.core
org.apache.taverna.scufl2.api.impl -- A very strange package name
org.apache.taverna.scufl2.api.io
org.apache.taverna.scufl2.api.io.structure
org.apache.taverna.scufl2.api.iterationstrategy
org.apache.taverna.scufl2.api.port
org.apache.taverna.scufl2.api.profiles
org.apache.taverna.scufl2.api.reference
org.apache.taverna.scufl2.rdfxml
org.apache.taverna.scufl2.rdfxml.impl
org.apache.taverna.scufl2.translator.scufl
org.apache.taverna.scufl2.translator.scufl.processorelement
org.apache.taverna.scufl2.translator.t2flow
org.apache.taverna.scufl2.translator.t2flow.defaultactivities
org.apache.taverna.scufl2.translator.t2flow.defaultdispatchstack
org.apache.taverna.scufl2.translator.t2flow.t23activities
org.apache.taverna.scufl2.ucfpackage
org.apache.taverna.scufl2.ucfpackage.impl.odfdom.pkg
org.apache.taverna.scufl2.ucfpackage.impl.odfdom.pkg.manifest
org.apache.taverna.scufl2.validation
org.apache.taverna.scufl2.validation.correctness
org.apache.taverna.scufl2.validation.correctness.report
org.apache.taverna.scufl2.validation.structural
org.apache.taverna.scufl2.validation.structural.report
org.purl.wf4ever.wfdesc.scufl2 -- which I will probably change
Alan
Re: Taverna language (SCUFL2) poms
Posted by Stian Soiland-Reyes <st...@apache.org>.
Agree to remove any trace of "t2". Not sure why we even introduced this as
pre-2.0 didn't even use net.sf.taverna.
I think at the time we saw t2 as an internal brand name for anything new
that was not just moved across, like baclava.
My feeling is that org.apache.taverna.wsdl.parser is good as long as there
are other things under wsdl (even if in another jar, e.g.
org.apache.taverna.wsdl.activity ) . An intermediate package with a lonely
child is on the other hand a bit silly.
Others might disagree - and I guess we could fight over the ordering? ;)
On 21 Jan 2015 15:30, "Dmitry" <re...@list.ru> wrote:
> Great,
>
> Will this be the standard pattern in packages?
> For instance:
> net.sf.taverna.wsdl.parser -> org.apache.taverna.wsdl.parser
>
> There are also many components that have "t2" in the package.
> Will they pass into "t3"?
> IMHO it is better to remove the version from packages.
>
> Cheers,
>
> Dmitry
>
> On 1/21/2015 3:13 PM, alaninmcr wrote:
>
>> Hello again,
>>
>> Just to say that the Taverna language on incubator is now building OK.
>>
>> Before the license changes, we can still do the package re-naming. I
>> suggest that:
>>
>> uk.org.taverna.{fred} -> org.apache.taverna.{fred} and
>> net.sf.taverna.t2.{fred} -> org.apache.taverna.{fred}
>>
>> This would mean, for example, that
>>
>> uk.org.taverna.scufl2.translator.t2flow becomes
>> org.apache.taverna.scufl2.translator.t2flow
>>
>> Any objections?
>>
>> Alan
>> .
>>
>>
>
Re: Taverna language (SCUFL2) poms
Posted by Dmitry <re...@list.ru>.
Great,
Will this be the standard pattern in packages?
For instance:
net.sf.taverna.wsdl.parser -> org.apache.taverna.wsdl.parser
There are also many components that have "t2" in the package.
Will they pass into "t3"?
IMHO it is better to remove the version from packages.
Cheers,
Dmitry
On 1/21/2015 3:13 PM, alaninmcr wrote:
> Hello again,
>
> Just to say that the Taverna language on incubator is now building OK.
>
> Before the license changes, we can still do the package re-naming. I
> suggest that:
>
> uk.org.taverna.{fred} -> org.apache.taverna.{fred} and
> net.sf.taverna.t2.{fred} -> org.apache.taverna.{fred}
>
> This would mean, for example, that
>
> uk.org.taverna.scufl2.translator.t2flow becomes
> org.apache.taverna.scufl2.translator.t2flow
>
> Any objections?
>
> Alan
> .
>
Re: Taverna language (SCUFL2) poms
Posted by alaninmcr <al...@googlemail.com>.
Hello again,
Just to say that the Taverna language on incubator is now building OK.
Before the license changes, we can still do the package re-naming. I
suggest that:
uk.org.taverna.{fred} -> org.apache.taverna.{fred} and
net.sf.taverna.t2.{fred} -> org.apache.taverna.{fred}
This would mean, for example, that
uk.org.taverna.scufl2.translator.t2flow becomes
org.apache.taverna.scufl2.translator.t2flow
Any objections?
Alan
Rat was Re: Taverna language (SCUFL2) poms
Posted by alaninmcr <al...@googlemail.com>.
On 21/01/2015 16:36, Ian Dunlop wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hello,
>
> I got 76 non conforming licences for the command line alone. How do
> you switch off the rat check? I see there is a rat.skip parameter but
> how do you add this to 'mvn install'
I also found (via the creadur active that) using the verify goal will
get fewer complaints than just apache-rat:check .
> Cheers,
>
> Ian
Alan
Re: Taverna language (SCUFL2) poms
Posted by Ian Dunlop <ia...@manchester.ac.uk>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello,
I got 76 non conforming licences for the command line alone. How do
you switch off the rat check? I see there is a rat.skip parameter but
how do you add this to 'mvn install'
Cheers,
Ian
On 21/01/15 13:41, alaninmcr wrote:
> Hello everybody,
>
> Just to say that I am having to change the SCUFL2 poms a little to
> ensure they compile with Java 1.7 not 1.4 :)
>
> The apache rat plugin is complaining a lot about the licensing, but
> as far as I know we cannot start to change the licensing until we
> have the sign over from Manchester.
>
> Alan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJUv9UvAAoJEPK45GBX+Cy5k8kIALgfJO7RfOToy/1bx0FjQDUX
Sc3F9Ks2IgNrB7knW4IxIdG1fcz5Knwa2flVbiTL5fFRxpMusFfUtc/PyuoJCJ1+
lk2AMp0HjCJxogDgB08/rpVLCuby0nJ1qj1PXa+Ax1IocTXCTPNSNbOmZTszZhrC
7Kvb6WK0CUbVU4pSUfkFs450sF5Y/Is2LMvLwb0FieZYXdccK3+uFAo8MFkGefp5
fUBrqONNQ4yZr0Y/GHzWukMB2/pWow+XE3s9Vhjy+qo9kmAl29KFodYIzCYzj1JA
P+DwPAERkgTn7B6xNdrn0wDroBfR5alP7cnDrr9Y8USw0yhzWOZgplp1uqVgLNA=
=mTsV
-----END PGP SIGNATURE-----