james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Burrell Donkin" <robertburrelldon...@gmail.com>
Subject Re: [JSieve] pom's in stage
Date Tue, 09 Oct 2007 19:45:45 GMT
On 10/9/07, Stefano Bagnara <apache@bago.org> wrote:
> Robert Burrell Donkin ha scritto:
> > On 10/8/07, Stefano Bagnara <apache@bago.org> wrote:
> >> Robert Burrell Donkin ha scritto:
> >>> On 10/8/07, Stefano Bagnara <apache@bago.org> wrote:
> >>>> The alternative is still the #3 from the original post:
> >>>>> 3) change the dependencies groupdIds/artifactIds for the "problematic"
> >>>>> artifacts and move them to the new folders. Alter the pom to declare
> >>>>> this new dependencies. E.g: move javax.mail/jars/mail-1.4.jar to
> >>>>> org.apache.james.dep/jars/mail-1.4.jar or something similar. Even
if we
> >>>>> don't put there the poms mvn will work creating a "standard" pom
with no
> >>>>> dependencies and will deploy to the local repository our own "artifacts"
> >>>>> without clashing with official poms/artifacts from central. This
is make
> >>>>> the offline build to work without placing bad stuff in the local
> >>>>> repository but we will declare dependencies on artifacts not existing
on
> >>>>> central.
> >>>> opinions?
> >>> #3 introduces bad meta-data into the maven repository
> >> No, I proposed #3 because it does not put bad meta-data in the
> >> repository. It only put there "custom" data. We should only take care to
> >> use our own groupIds and no build will be corrupted by our poms.
> >> Let's say we add "jsieve" or "james" to the groupId, we can be sure no
> >> one else will have references to this artifacts.
> >
> > bad meta-data is bad meta-data - whether it's published in the apache
> > repository or not
>
> Maybe this depends on the definition of bad metadata. IMHO what is bad
> is some metadata that could break something because it is not complete
> or different from the right metadata.

unless JAMES plans to re-release the dependencies, the dependencies
are completely fictional. tools such as maven and ivy which depend on
good meta-data will be broken by fictional dependencies.

it is possible that substituting new poms may introduce obscure issues
with maven but the risk is low whereas using fictional ids is
gauranteed to break dependency management tools.

> Here I propose to create our own metadata for the very purpose to create
> something we have the license to redistribute.
>
> The original issue is that we have no license to redistribute that poms,
> right? I say let's create our own poms, and doing so we should not reuse
> groupIds already used by third party projects that didn't grant us the
> needed licensing.
>
> The concrete plan is (replace "org.apache.james.3rdparty" with what you
> prefer):
> rename stage/javax.mail to stage/org.apache.james.3rdparty and then
> alter the pom from:
>     <dependency>
>       <groupId>javax.mail</groupId>
>       <artifactId>mail</artifactId>
>       <version>1.4</version>
>     </dependency>
> to
>     <dependency>
>       <groupId>org.apache.james.3rdparty</groupId>
>       <artifactId>mail</artifactId>
>       <version>1.4</version>
>     </dependency>
>
> At this point we can decide whether to create pom.xml for this
> groupId/artifactId. If we don't provide one maven will create a basic
> one for us.

but this breaks tools (including maven) that rely on the meta-data being correct

> >> IMHO the only drawback is that we cannot publish our "jsieve" pom in the
> >> maven repository because we have dependencies on artifacts that are not
> >> in the repository. But this already happens for james and mailets jars,
> >> so I don't think this is a big issue. If we want to publish jsieve in a
> >> maven repository we'll have to fix many other problems, first (or to
> >> avoid declaring the dependencies).
> >
> > i'm confused: which issues in particular?
>
> That james-2.3.1.jar, mailet-2.3.jar and mailet-api-2.3.jar are not
> present in a maven repository (and it is not just a matter of addning a
> pom and publish them because our ant build didn't add NOTICE/LICENSE to
> that jars as we didn't plan to redistribute them outside from our main
> zip/tar.gz releases).
> So we already declared dependencies on artifacts not existing in the
> repositories (our own james server/mailet jars), #3 would simply add
> some new artifacts that is only found in the local stage folder.

yes

but i'm still confused about what would be required than just adding
NOTICE/LICENSE to the jars before they could be published in the maven
repository

> >>> what would maven do if we just removed all the pom's from the local repository?
> >> If we remove the poms and leave the jars under existing
> >> groupId/jars/artifactId-version.jar scheme then it will try to lookup
> >> the poms online, if it finds the pom it download it, otherwise it
> >> creates simple poms with no dependencies (they contains artifactId,
> >> groupId and version). This maven-generated poms are the ones that could
> >> break any other project depending on the same artifacts and building
> >> against the same local repository
> >
> > by local respository do you mean the stage directory or ~/.mvn (or
> > whatever the path is)?
> >
> > - robert
>
> the local repository is ~/.m2/repository.
>
> when maven look for an artifact it looks in the local repository
> (~/.m2/repository). If the artifact is not there, yet, then it starts
> looking in the remote repositories. We "hacked" our poms so that we add
> a "stage folder" that is a "remote repository" for maven but is local to
> our project and is checked out with the sources. This is clearly an
> hack, because this break some basic maven rule, but this was the only
> solution to satisfy the JAMES PMC/AFS policies wrt m2 based releases.
> If someone changed his mind about this topic please speak now, otherwise
> I think we'll have to stick to that decision.
> So when maven will need the org.apache.james:mailet-api:jar:2.3 artifact
> it find it in the stage/org.apache.james/jars/mailet-api-2.3.jar file
> and then also looks for stage/org.apache.james/poms/mailet-api-2.3.pom.
> If it does not find the pom it will first lookup any other remote
> repository for the pom and if not found will create a basic pom like
> this one:
> <project>
>   <modelVersion>4.0.0</modelVersion>
>   <groupId>org.apache.james</groupId>
>   <artifactId>mailet-api</artifactId>
>   <version>2.3</version>
> </project>
> (as you can see this is only a different representation of the maven
> artifact identifier)
>
> I think the only "bad" pom is the one having the same groupId/artifactId
> of an already publicly available pom but not declaring the same things
> (declare no dependencies or different dependencies).
> We can create as many new poms as we like under the groupIds we like and
> they are not "bad metadata". They simply are redundant/alternative
> metadata.

this is bad meta-data - there are releases with those ids

> Unfortunately we already accepted poms without license in
> central and now we need a fix for this.

the pom licensing needs fixing centrally in any case

> The only thing we should care
> about is to use a groupId that do not clash with possible 3rd party
> groupIds (following maven convention we should use org.apache as we
> control that domain).

maven is one tool amongst many that rely on this meta-data being
correct. altering these ids is gaurateed to create bad meta-data.

- robert

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Mime
View raw message